Step by Step Debugger

[Rock*Star]

I will soon be using this tool. But I am very excited about it and wanted to post a link to a flash demo so that others could see it. I will post a how to, for webERP, once I get that far.

http://www.nusphere.com/flash_files/dbg-...aller.html

Larry
St Louis, MO

[phil]

Look forward to hearing how it goes....

[Rock*Star]

This does work. The environment that I used was xampp on windows for apache and mysql. I have Windows 7 on this laptop. So weberp is under there in htdocs c:\xampp\htdocs\weberp. After the NuSphere install you can create a new project which I saved within where it wanted to save these "ppj" files and I pointed the source documents to htdocs. I chose run webserver on "my laptop" and took most defaults. There was an initial error prompt about not finding some file that it needed, but it offered to fix it, and it did.

By opening the project and pointing to the C:\xampp\htdocs\webERP\index.php as the start point I was able to step through "everything". You can even set breakpoints so that the code will run and stop right before an area that you need to look closely at.

If you have never used a debugger in your programming career then you will be quite surprised. All of your variable values are listed and with every step you take through the debugger you can see the values change real time.

[opto]

if I understand the NuSphere website correctly, you will have to pay for it. You can get similiar functionality in netbeans for free. I think also in PDT, although I never used that.

[terryp]

Free Open Source Alternatives for PHP debugging :

There are a few, here is one :-
http://developers.blog.box.com/2007/06/2...-on-linux/

<start quotation>
How to Debug PHP with Vim and XDebug on Linux

By Sam Ghods, Vice President of Technology

Here is the scenario: You have multiple developers logged into a Linux server which is running Apache and PHP using Vim to write PHP code. They’re using error_log and echo statements to debug their code. It takes forever, it’s tedious and can result in bugs from forgotten debug statements. You stare enviously at .NET programmers with fancy debuggers (while you snicker knowing that you edit 10x faster with Vim anyways). But still, you know there has to be a better way. There is. Here’s how it works. You’re coding away in vim. You hit F5; Vim waits for a connection from the PHP server. You refresh the PHP page you’re working on. It attempts to contact Vim — connection successful. You are launched into a debugging session right inside Vim. You can step into, over, and out of statements, eval statements, get all variables in context, get and set properties, remove and set breakpoints, all on the fly. Finally, some real programming tools.
The environment: Vim

First, we need to make sure vim is compiled correctly. Type :version in your Vim and check the features section. If you have +python and +signs, you’re good to go. Skip ahead to the next section. Otherwise, you need to compile from source. On Linux, download and untar the source code, and open up src/feature.h. You need to comment out the conditional statements around the +signs feature. In Vim 7.1, it looks like this:
1 /* * +signs Allow signs to be displayed to the left of text lines. * Adds the "ign" command. */ #if defined(FEAT_BIG) || defined(FEAT_SUN_WORKSHOP) || defined(FEAT_NETBEANS_INTG) # define FEAT_SIGNS # if ((defined(FEAT_GUI_MOTIF) || defined(FEAT_GUI_ATHENA)) &amp;&amp; defined(HAVE_X11_XPM_H)) || defined(FEAT_GUI_GTK) || (defined(WIN32) &amp;&amp; defined(FEAT_GUI)) # define FEAT_SIGN_ICONS # endif #endif

You need to comment out both if statements and their respective endif’s, so it looks like this:
1 /* * +signs Allow signs to be displayed to the left of text lines. * Adds the "ign" command. */ /*#if defined(FEAT_BIG) || defined(FEAT_SUN_WORKSHOP) || defined(FEAT_NETBEANS_INTG)*/ # define FEAT_SIGNS /*# if ((defined(FEAT_GUI_MOTIF) || defined(FEAT_GUI_ATHENA)) &amp;&amp; defined(HAVE_X11_XPM_H)) || defined(FEAT_GUI_GTK) || (defined(WIN32) &amp;&amp; defined(FEAT_GUI))*/ # define FEAT_SIGN_ICONS /*# endif #endif*/

then cd back to the top source directory and run:
1 ./configure --enable-pythoninterp

If on a 64-bit system or a system with a strange python installation, you may have to add --with-python-config-dir=/usr/lib64/python2.3/config to the configure string. If the configure script can’t find the config directory it will say so in the script output, but the configure won’t explicitly fail — so you have to be sure that all the python stuff is OK. After configuration, do
1 make &amp;&amp; make install

to install your newly python’d vim.
The client: Debugger.vim (and Debugger.py)

Now that vim is ready, download the DBGp client script. Extract the two files (debugger.vim and debugger.py) to your vim plugin directory or your .vim home directory. In Vim 7.1 compiled on Linux, the default load-for-everyone plugin location is /usr/local/share/vim/vim71/plugin/, so you would put both files in that directory. Try to run vim — if you get no errors, everything should be good. If you get an error, double check :version to make sure +python and +signs are there. If they are, post a comment here with the vi error you get. If they aren’t, the vim compilation/installation didn’t work — go back and try it again. Now your debugging client is ready. Now let’s setup the server.
The server (engine): XDebug

Download XDebug. Download the source, compile the .so and add the following lines to your php.ini:
1 [Zend] zend_extension = /full/path/to/xdebug.so xdebug.remote_enable = 1 xdebug.remote_port = 9000 xdebug.remote_host = localhost

Open a file in your browser which outputs <?php phpinfo(); ?> to make sure xdebug is loaded.

Now, with your site being example.com, go to http://example.com/index.php?XDEBUG_SESSION_START=1. This will set a cookie in your browser which expires in 1 hour which tells the PHP XDebug module to try to make a connection every time a page loads to a debugging client which is listening on port 9000. The cool thing is that if it can’t make a connection, it just keeps loading the page, so there’s no issue just leaving the cookie on. Now go back to vim and press F5. You should see a message like “waiting for a new connection on port 9000 for 5 seconds…” at the bottom of the screen. You have five seconds to now refresh the PHP page. This will create a connection between the debugger and client. Now you’re debugging. Follow the instructions in the Help window to step into, over and out of code. Press F5 to run the code until a breakpoint (which you can set using :Bp).
But what if I have multiple developers on the same machine?

No problem. Simply set g:debuggerPort in each developer’s .vimrc to get the client listening on a different port. So if you wanted one developer to connect on 9001 instead of the standard 9000, you would add this line to their .vimrc:
1 let g:debuggerPort = 9001

Getting the server to connect on a different port is a little trickier. You need to set a custom php.ini value (xdebug.remote_port) for each user. It works best if you’re using VirtualHost’s in Apache. Just add the following line to the VirtualHost section of your httpd.conf:
1 php_value xdebug.remote_port 9001

Now restart Apache and if you use that VirtualHost and that vi user, then they should connect successfully.
That’s about it

Please post any questions or suggestions you may have. I hope this helps a few of you out there who want debugging tools but don’t want to give up Vim editing. Also be sure to post any alternate methods, or any patches or improvements to the remote PHP debugger vim script, and I’ll be sure to incorporate them. [Note: This is the first in a series of posts we'll be doing along the lines of tutorials, tools we've developed, tech commentary, and so on. Please feel free to subscribe, as well as leave any comments, thoughts or suggestions below so we can be sure to improve with each article! Thanks!]
<end quotation>

Cheers
Terry

[phil]

I find geany - a lowish footprint syntax highlighting editor and echo statements work just fine... I've only used vi in desperation over ssh.

[terryp]

I find geany - a lowish footprint syntax highlighting editor and echo statements work just fine... I've only used vi in desperation over ssh.

I only use vi in desperation over ssh myself

The editor I use is Gvim, which is a nice GUI front end to vi, with all the configuration options anyone would ever need.

Anything that works for vi, works for Gvim.

---

I find geany - a lowish footprint syntax highlighting editor and echo statements work just fine... I've only used vi in desperation over ssh.

I just installed Geany to check it out, .... and I like it, which is unusual as Gvim owns my mind and soul, and as a result, I normally shun IDE's.

However Geany uses GTK (my all personal preference), is light and has lots of nice features, including documentation, compilation error window, terminal window etc.

If I ever used a IDE, Geany would be at the top of my list I think.

[dalescott]

What is the best setup for single step debugging today?

~2014'ish I setup nebeans and xdebug using xampp on windows, and I think with xdebug runnng remotely in a virtualbox FreeBSD vm (on windows). However that was two laptops ago and I need to setup a new dev environment from scratch.

What is the best dev setup today? Preferably free and cross platform Windows and Linux (Mint/Ubuntu). Still netbeans? Is the "new" PHP built-in execution used for debugging now instead of xdebug? (and fwiw, my webERP demo runs on bare metal FreeBSD using Apache and mod_php - real old school ;-) )

[clod]

I recommend to try CodeLobster IDE - http://www.codelobster.com

[bigpower10]

I'm very happy with Netbeans/xDebug on my Ubuntu LAMP stack. I loved the old Zend studio before it moved to Eclipse, and PHPEdit before that. Never seen CodeLobster before, but a brief look reminded me of what I loved about the old Zend studio, I might take a look...