Re: Programs not running

On Jan 5, 2013, at 8:52 AM, tamouse mailing lists wrote:

> On Sat, Jan 5, 2013 at 12:48 AM, Karl DeSaulniers <[email protected] 
> > wrote:
>> On Jan 4, 2013, at 8:00 PM, tamouse mailing lists wrote:
>>> On Fri, Jan 4, 2013 at 6:09 PM, Matt Pelmear <[email protected]>  
>>> wrote:
>>>> On 01/04/2013 01:40 PM, tamouse mailing lists wrote:
>>>>> One should be able to solve parsing problems without resorting  
>>>>> to using
>>>>> a
>>>>> web server. Every time I save a php file, I have my editor set  
>>>>> to run it
>>>>> through php -l. Saves lots of angst when I get to the web  
>>>>> testing stage.
>>>>
>>>> This is a good idea in general. It's also a good trick to check  
>>>> for this
>>>> problem from the command line when suspecting a parse problem.  
>>>> Most IDEs
>>>> will make parse errors very obvious while you are editing the  
>>>> file, too.
>>>> Unfortunately not all members of any given development team can  
>>>> be relied
>>>> upon to test things in this way before committing ;)
>>>
>>> Committing a syntax error which breaks integration is a HUGE HUGE NO
>>> NO. Such a person would likely be cast from a dev team, or relegated
>>> to some more benign task.
>>
>> For those of us who have no idea of what you speak,
>> can you elaborate so as we don't make that mistake?
>> Or are you just talking about submitting a file to production without
>> testing it?
>
> Not necessarily directly to production, but the beginning of the
> stream that will take something from development, through testing,
> staging, and finally into production. The initial point where you
> merge things is generally shared by all developers on a project, and
> to break it means you are breaking things for everyone on your team.
>
> Note this applies to mulitperson projects; if you do this to yourself
> on your solo project, not so much of a problem.
>
>> I personally have not used command line. It is new to me, but sounds
>> integral.
>> Where can one study its use?
>
> You can start with:
>
> http://php.net/manual/en/features.commandline.php
>
> As for telling your editor to pass the file through php -l, that's
> something that is extremely editor specific. I can tell how it's done
> in Emacs, TextMate and Sublime Text 2, but naught else. Using a
> full-fledged IDE such as Eclipse or PHPStorm will automatigically flag
> syntax problems.
>
> -- 
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Oh, ok. Then I was not as lost on the subject as I thought.
Being a solo worker who is seeking a job with a team,
I thought I may be missing something and would not want
to be cut from the team for my lack of knowledge on the subject.

I personally do what you all have been saying in response to Ethan's  
posts.
If I hit a snag or have a problem and no error code, I go through and  
remove functions
until I come to the one that is causing the problem. This is a little  
lengthily of a process,
but has proven the best method for me an my lack of php experience.
Unfortunately, I do not know or have experience using any php editing  
IDEs, my code is written in Adobe GoLive... lol
Does have syntax coloring, but about as good as Text edit or note pad  
when it comes to debugging.
Basically the same as hand coding.. actually that's what it is.. :)

Thank you for your response and the link on command line. I will take  
a look.

Best,


Karl DeSaulniers
Design Drumm
http://designdrumm.com


-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php