One mans quest for a PHP IDE for Linux.

Justin Koivisto, obviously a huge fan of Alan Hale, wrote:
>
> define('DEBUG',TRUE); (or define('DEBUG',FALSE); when not debugging)
> if($DEBUG){

ObNitpick: just DEBUG not $DEBUG

But if I were you I wouldn't bother trying to convince someone already
set in their ways. You and I like using debug statements, and he prefers
using external tools. I just hope I never have to take over maintenance
for any of his code.

/joe
--
Erika digs on GTJETSKI, and then gurgles ccv("Inappropriate!");. The poon
is green. Jim Greenlee must take Yunis! Scott Hughes mentally beckons Steve
Simonsen, and then yells laov("Recursive post!"); in gtpj!!

André Næss wrote:
> Understanding profilers and debuggers is part of the profession. They are
> tools you need to know if you want to be a good programmer, and they are
> quite easy to understand.

Then I, my friend, am not a good programmer. ;)

--
Justin Koivisto - spam@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

While thinking about how cool John Deadver was, Andre Nass blurted:
>
> Understanding profilers and debuggers is part of the profession. They are
> tools you need to know if you want to be a good programmer, and they are
> quite easy to understand.

Understanding debuggers might lead some people not to use them.

/joe
--
Git.general is overclocked. Solomon Peachy wishes to be as cool as
Dramatech. In Eighth Street West, a parser from spacegirl will go to Dr.
Esque.

Justin Koivisto:

>>>This is going to sound a little strange, but why not just stick a
>>>constant into your script that causes output of technical data along
>>>with the html ?
>>
>> Because that means you have to actually *write* all the code to output
>> technical data. The extra lines make the code less readable and less
>> maintainable. They lie dormant 99% of the time. They simply don't belong
>> there.
>
> Extra lines don't necessarily make the code less readable... It depends
> on how you go about it and if you have comments stating what they are for.
>
> For instance, if you have custom catch/throw methods, why remove them?
> You'll just have to add them back in later if you need to debug again.
> For that matter, any dubugging code can be handled correctly... If done
> correctly, you can have readable code that makes sense and still have
> the debugging code there when you need it.
>
> Something similar (over simplified for example) would be:
>
> at top of script (or in common included file):
> define('DEBUG',TRUE); (or define('DEBUG',FALSE); when not debugging)
>
> Then you'd have (using MetaBase for instance):
> <?php
> $result=$metabase->Query($query);
> if(!$result){
> // something went wrong
> if($DEBUG){
> // if in debug mode, display information
> echo $metabase->Error();
> }else{
> // handle the failure for production server
> }
> }else{
> // query success, continue processing
> }
> ?>
>
> What's so unreadable about that? Make perfect sense to me, and it's
> still clean.

I did not say unreadable. I said less readable. The more code, the harder it
is to get an overview of the code, it's as simple as that. The effect is
probably not that big, but when debuggers are available, there is simply no
reason not to use them!

Of course, proper error handling is important, and in your example I would
probably have some sort of logging mechanism so that I can respond to
errors as quickly as possible. But that's a different issue.

I believe that in a perfect world, the code would be purely "happy-day", not
a single error handler in sight. The error handling code would be put in a
separate "layer". Keeping the program logic and error handling separate in
this manner would make it much easier to understand and use the code. I
don't know if it's feasible to do though :) Maybe it's a subject for a
Masters thesis, but I'm in the middle of one already.

>> Profilers and debuggers are extremely valuable tools.
>
> Only if you know how to use them correctly. Putting something like that
> into just anybody's hands could prove problematic...

Understanding profilers and debuggers is part of the profession. They are
tools you need to know if you want to be a good programmer, and they are
quite easy to understand.

André Næss

Hastur Batato:

> Justin Koivisto, obviously a huge fan of Alan Hale, wrote:
>>
>> define('DEBUG',TRUE); (or define('DEBUG',FALSE); when not debugging)
>> if($DEBUG){
>
> ObNitpick: just DEBUG not $DEBUG
>
> But if I were you I wouldn't bother trying to convince someone already
> set in their ways. You and I like using debug statements, and he prefers
> using external tools. I just hope I never have to take over maintenance
> for any of his code.

And I naturally hope I don't have to take over maintenance for your code,
ridden as it would be of debug statements. ;)

André Næss

KWrite :D

all i use for Linux Development


Parag0n

"apchar" <apchar@yahoo.com> wrote in message
news:295c858.0311060033.6091155f@posting.google.co m...
> I'm sitting here staring at my favorite poster. It's a photo of a ship
> that hit a reef and sunk long ago but still has its ass-end sticking
> out of the water. The caption reads "It may be that your sole purpose
> in life is to serve as a warning to others." (checkout despair.com for
> more of these jewels.) That's how I feel right now after spending (or
> rather EXpending) the entire day looking for a PHP IDE for my
> mandrake linux box. All I wanted was an editor with highlighting that
> would let me set breakpoints, step through my code, and watch
> variables change ("... and memories of Turbo-Basic danced in their
> heads.")
>
> In a shameless effort to garner sympathy while warning others before
> they take this journey, I thought I'd share my findings from the
> field:
>
> PHP plugin to eclipse:
> cost: free.
> relevant URLs: http://www.eclipse.org ,
> http://phpeclipse.sourceforge.net/
> Documentation: plenty for eclipse. none for the plugin.
> Did it work?: almost.
> Although the install directions were wrong, they weren't so wrong that
> I couldn't figure out what to do. Afterwards I was able to start a PHP
> project and edit a PHP file but I couldn't run it much less debug it.
> All I got were error messages when I tried either. Another brain-dead
> editor I dont need. Too bad since eclipse works fine for Java. Someday
> this might be a viable option.
>
> PHP-DBG with DDD (whilst in my BVDs):
> relevant URLs: http://dd.cron.ru/dbg/ ,
> http://www.gnu.org/software/ddd/
> cost: free
> Documentation: lots for ddd. none for php-dbg.
> Did it work?: no
> There's a lovely screen shot on the dbg website of dbg working within
> ddd. That was as close as I got to seeing these two play together. DDD
> just did not know dbg was out there and I dont see any docs on how to
> hook them up. The good news is that both were available as RPMs so it
> didn't take long to find out this wouldn't work.
>
> PHPmole:
> relevant URLs: http://www.akbkhome.com/
> cost:free
> Documentation: sparse. incoherent.
> Did it work?: Hell no.
> This was the one I wasted the most hours on. It requires scads of php
> plugins and libraries. Each of which has their own prerequisites and
> idiosyncracies. Even after successfully installing them, phpmole still
> insisted that some weren't there. After hours of finagling I finally
> got it running enough that I could edit a file but when I hit "Run" it
> swiftly crashed every damn time. Argh!!
>
> PHPed:
> relevant URLs: http://www.phped.com
> cost: $300 after 30 day trial period
> Documentation: lots.
> Did it work?: mostly
> This is a commercial product by NuSphere. No trouble installing it. It
> has a decent looking GUI. While not exactly intuitively obvious it
> didn't take long to figure out how to edit a file, run, and debug it.
> For some reason it started Mozilla and it appears to spawn Apache to
> actually run the code rather than feeding it to an internal engine.
> This is an annoying overkill and inexcusable for a $300 package. It
> also means it has one fatal flaw: you cant stop an infinte loop. If
> you're sloppy (and I am, or I wouldn't need an IDE) and create an
> infinite loop (which I managed to do in just a blurb of test code) and
> hit RUN you're stuck watching the scroll bar in the output window
> shrink and shrink and shrink as you're code runs off into never-never
> land. The STOP button wont stop it. The PAUSE button wont pause it.
> You're only option is to quit PHPed, fire up an xterm, run top, seek
> out the offending php job (it's not hard to find, it's consuming 96%
> of the cpu), and kill it. This is not a good feature. Once the 30 day
> trial expires it supposedly stops working altogther. So PHPed is not a
> viable option for an impoverished grad student looking to get off
> cheap (as a rule I wont buy any software that costs more than my car.)
>
> Zend Studio:
> relevant URLs: http://www.zend.com
> cost: free 21 day evaluation, $200 or crippleware after that
> documentation: lots.
> Did it work?: yes
> Another commercial product. No trouble installing. Nice looking GUI
> though it manages to look cluttered and a little emaciated at the
> same time. Again, though not exactly intuitively obvious to the
> uninitiated, it was not too hard to get started, edit a file, run, and
> debug it. For 21 days you get to play with the full version. After
> that you can pony up $200 or live with the 'personal version' that
> disables a few frivolous functions nobody uses anyway like Print. Oh
> well, I can always cut and paste into kwrite. Another feature that
> stops working after 21 days is the profiler. But since I dont know
> what that is and the odds are I wont get that far in 3 weeks I suppose
> I'll never miss it. As long as I can set breakpoints, step through the
> code, and watch variables I'll be happy.
>
> Sorry to say it, but the open source movement that gave me this great
> OS has not produced a decent PHP IDE yet. It's worth keeping an eye on
> the eclipse php plugin and the ddd DBG plugin. But for now, if you're
> looking to get off cheap, the crippled Zend studio is the best option
> I've found.
> Apchar.