Here's an update on my quest to find something to profile my code
with and a couple very basic questions about PhpEd.

The candidates:

PHPEdit 0.8 (open source)
Wasted a lot of time on this. Couldn't quite get the debug to work
and the documentation for that is not written yet, so I eventually
gave up.

Zend Studio 3.0
For some odd reason much of my code just doesn't work right using
their PHP, even though it's about the same version as others that do
work and the code has never been picky about that. This is a problem
just using a browser - IDE not involved. After much trial and error
and comparing php.ini and httpd.conf files I decided it must have
something to do with using their php .dll files. To be continued...

PhpEd 3.2.1 eval (NuSphere)
Read on...

Q1: Can I evaluate profiling effectively?

I'm mostly doing all this so I can get some profiling done. I
already have a nice editor and CVS, so I'm disappointed to read in
the forum that the trial version "shows only first ten lines". Is
there any point to my going further?

Q2: Project setup?

It looks like I have to have all the files involved in the program
under one directory. This is a problem. I have several files that I
use as an infrastructure for what I think of as several separate
projects (let's call those 'applications' for now). On the server
these files are kept over in cgi-bin/ and used by more than one
application. I currently manage the infrastructure files and each
set of application files as separate projects (for CVS purposes
etc). Following the instructions for adding files to a project
physically copied the files to the workspace directory - not at all
expected. I thought 'adding files to a project' would mean adding
them to a list of files for the debugger to be aware of. It would be
chaos to have copies of all those files in each application's
workspace.

Am I wrong about any of this? Have any suggestions?

SteveB

I think that having first 10 lines shown would allow you to see how it works. On the other hand it's limited evaluation version and can't be used for working effectively. I'm not sure I got the idea of "effective evaluation" .
Anyways, believe it or not this is the first php profiler and works well since August 2001.


Yes, you understand it right. All files are expected to be on a local directory and beneath. On the other hand, it doesn't mean that directories on the remote site you debug with are making the same tree as local ones. I mean that some directories can be mapped to different remote directories and be assigned with different URLs, for example. See Mapping tab in the project settings dialog.
Please note that it works for debugger only, and leaves one quite negative effect with publishing. PhpED maps directories 1:1 when performs uploading (publishing) or downloading files using webdav or ftp.
You certainly may create different projects in one workspace and have them mapped to appropriate remote directories.

'adding files to a project' - it's just an atavism. You'd consider your projects as quite dynamical things. Simply by changing project Root Directory you can change all the content. For example, if you already have a directory where you keep all your php files, you'd only point phped out where it would work.

I've worked out that I can get around the requirement to have all files physically reside under the project directory by using a shortcut to refer to where the library files really are, thus I won't have to duplicate them into every project that uses them.

I'm able to debug and step through and look at variables etc. Great! There are still things I don't understand:

1. Some relative paths to files needed to be made absolute before I could get the whole program to run. Why would this be different from when I just use a browser to run the code?

2. The output window shows almost nothing compared to what one sees in a browser. Something I read elsewhere hints that that is normal, and that I can "debug from the browser" though it's not clear to me how I do that. In most cases I don't need to see the output while I'm debugging but if it's possible I'd like to know how. FYI: I'm using "HTTP mode (SRV local WEB server)", I have "Run in external browser" checked, and if I use phpEd's F9 to run the program I see the browser window twitch a bit when the run starts and again when it stops, but no output there. I tried adding a line to my code setting $DBGSESSID='0@clienthost:7869' (some idea I got from a forum posting).

3. Profiler. I realize the trial version only shows ten lines. Fine. Why does it show me every single line of code though (well, up the first ten of them anyway). Is there a way to get timings for function calls only? I don't see any.

Thanks - getting closer,
SteveB

Could you send me a sample code that would replicate the problem ?


If looks quite strange. Do you use DBG 2.14.9 (or higher) on the server side ? Does it show anything in your case if you step through the code using sinlge step [F7] ?


Sure, you may group results by functions and by modules and subsequently you'll see timings for functions and for modules. See appropriate buttons in the profiler window. Yet there is still the same limitation.
If those 10 lines are not from any function you won't see any functions other than ::main().

I've been doing all these tests and getting a bit muddled trying to keep it all straight so this morning I uninstalled phpED and then reinstalled it (to D:\phpED by the way). Details later but first...

GOOD NEWS: If I put DebugBreak() in my script I can run it from the browser and the debugging works great. My experiment with shortcuts mentioned in an earlier post actually did NOT work but adding to Apache's include_path did the trick.

BAD NEWS: When I try to run the same page from inside phpED I get the debug session timeout message which says to verify settings for local debugger mode.

Here's a condensed account of how I got to where I am now after much reading of forum posts.

The standard install leaves my existing Apache/php installation alone and has it's own php installed under D:\phpED\php (presumably the built in server uses it). That php's php.ini is in D:\phpED\php. I altered my existing php.ini to load and enable the proper debugger dll for my version of php and added the lines for which hosts and ports to use. In Tools-Settings-Debugger I set path to php.ini to point to my php.ini. I've done the telnet test to verify comuncation with the Listener and that worked. In Project Properties' Mapping section I've set Root URL to http://<myHostname>/ and Remote root directory set to D:/www/

I must be very close at this point. What's left?

Not actually needed. This is for your own convenience, just in case if you wish to open a php.ini file in the editor.... Anyway, this setting does not affect anything.


It's the problem. If you want to work with Apache or any other WEB server, other than bundled SRV, regardless of locally or remotely, you have to set REMOTE HTTP mode. In case if your web server runs on the
local machine, you may want to set your project directory setting to point to apache DocumentRoot directory, and have project RemoteRoot to point to the same location.

That worked pretty well.