NuSphere Forums Forum Index
NuSphere Forums
Reply to topic
Some issues I noticed during evaluation/trial


Joined: 09 Dec 2003
Posts: 92
Reply with quote
Hello everyone,

I've been testing PhpED for a couple of days now. I've been using Macromedia Homesite for several years now and have always been missing the convenience and help in debugging an IDE can/should provide. Seems as if PhpED could make it as our new development platform. Good work!

Still there are some bugs or issues I'd like to discuss, maybe helping other people in evaluating the software. Unfortunately, I cannot describe all of them as precisely as I would like to. I've been using PhpED 3.2.1 Build 3239 eval on WinXP with a remote linux server (Debian, PHP4.1.2, PhpED-supplied DBG extension).

1. When debugging, PhpED tends to open a lot of files in an not always comprehensible manner. Sometimes it seems as if every file which is included by a script is opened, also if you don't "step into" it. This clutters up the file tab - debugging a more complex application gives me about 15 or 20 open files after just two or three requests.

2. I get an "Unexpected Error: Access violation at address 003B4EB1 in module 'phpED.exe'. Read of address 00000040." quite often. This seems to be somehow related to debugging and hitting files that have not yet been opened. You can ignore the error and continue working, however this causes PhpED to miss some of your requests, i. e. you need to reload files in the browser serveral times before PhpED intercepts one of the requests for debugging. Additionally, breakpoints are missed at random after that and the IDE stops on the first line of a script when debugging, even if told not to do so. After restarting the IDE everything works fine again, at least until the error pops up again.

3. When debugging, small blue dots are shown left of the code. However it seems as if not all of these marked lines are valid positions for breakpoints. Especially the lines marked with an * seem not to be valid breakpoints, although suggested.

function foo() { // *
if (true)
print 'foo'; // *
} // *

4. Starting a debug session (F9) with an external browser feels slow, it always takes a few seconds for the window to come up. This is much longer than the browser startup time. What might be the cause for that? I'm sitting right next to the maching running the Apache server.

5. The @ character is not working on German keyboards, this is a known issue.

6. I'm using the PEAR::DB classes in my application. When debugging, I always end up in one of the PEAR files after script execution (more precisely, in PEAR::_PEAR_call_destructors()). This is annoying, as I'll have to switch back to the file I've been editing before after each run. I think that after the debugger has finished, you should be at the same position in your code as you've been when you started it.

7. Is it possible to debug remote files accessible via FTP only (not Samba), using the remote server and not copying everything to local? How to specify the appropriate mapping? It seems as if PhPED was missing a "local file" then.

Thanks a lot for the support,
mp.
View user's profileFind all posts by mpSend private message


Joined: 09 Dec 2003
Posts: 92
Reply with quote
Concerning #1:

It seems as if PhpED tries to open every file directly requested by the browser plus the file where script execution ends. It might miss one of them, but reloading the corresponding frame/page will, hm, "work" Crying or Very sad.

E. g. I start debugging by calling a login form, which is posted to a login script; the browser is redirected to a frameset containing three frames. Now after that I have (without having set breakpoints, without "stopping on the first line after run", without stepping through the code!) six open files. PEAR.php is one of them, having focus as the _PEAR_call_destructors method has been called last. (This explains issue #6 above?) One of the frame scripts is "missing" (I don't want to see it at all Wink), but reloading the frame pops it up. That makes a total of seven windows before I even reached the interesting part of the code Sad .

Concerning #7:
This is a FAQ and - if I get it right - not possible. I'd like to be able to debug files on a remote (production) server not running samba. Copying everything to local first is too expensive.

Also if you just want to edit the file (not running the debugger), you will have to make a local copy, edit that and publish it afterwards. You cannot edit files "purely remote", as it would be possible at least with Homesite.

mp
View user's profileFind all posts by mpSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 8334
Reply with quote
Concerning #7:
You don't need all the files be copied locally, but the files being debugged only.

Anyway, it's a normal practice when all files are kept and edited locally and sent to the web during a kind of sync. Especially if you use source-control system, you have no other choise Smile .

Concernint #1:
It happens if you have frameset only. In order to debug such stuff you should add DBGSESSID argument to one of the scripts listed in FRAMESET and run frameset itself without debugger.
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 09 Dec 2003
Posts: 92
Reply with quote
ad #1

Well, where's the point opening all those directly requested files if you don't "stop on the first line" and don't step into them?

That does not apply to framesets only, PhpED will open all files your browser requests?

This relates to #6 as it always opens the file where execution ends and leaves that one focussed. So you can't just change some lines, reload the file in the browser, switch back and continue; you will have to press Ctrl-F4 first to return to your position in code Smile

mp
View user's profileFind all posts by mpSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 8334
Reply with quote
Quote:
Well, where's the point opening all those directly requested files if you don't "stop on the first line" and don't step into them?

Would you show a sample script that replicates the problem ?
As far as I know PhpED does not open anything by its own intents Smile
It opens only files where you step in.

Quote:
That does not apply to framesets only, PhpED will open all files your browser requests?

Problem with Framesets has no relation to the above.
If you open a frameset, IE (or whatsoever browser) open all frames using independent HTTP connections and if you have DBGSESSID session cookie enabled, all they will get debug requests and therefore multiple debug sessions will attempt to start. PHPED 3.2 IDE can not handle more than just one debug session at a time.

Quote:
This relates to #6 as it always opens the file where execution ends and leaves that one focussed. So you can't just change some lines, reload the file in the browser, switch back and continue; you will have to press Ctrl-F4 first to return to your position in code

Agreed. It's not too convenient to have last executed file opened at the end of debug session.
But why don't you use navigation bar ? It would bring you back to the original point easily.
Also, don't forget you can set "Default file to run" in the project settings.
While you have it set, you don't need to switch to anything.
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 09 Dec 2003
Posts: 92
Reply with quote
Ddmitrie,

I really appreciate the support you're providing and the time you spend answering posts in this forum.

Quote:
Would you show a sample script that replicates the problem ?

Try the following three scripts. Create a project for them, set test.php as the default file to run. "Close all files" and run the scripts in an external browser window by pressing F9 (don't set any breakpoints and make sure to disable "stop on first line after run"). Click the submit button in "test.php", and you'll get "Hello world". At least my PhpED installation has all three files open after that - even without using frames.

Code:

test.php --
<html>
<body>
<form method="post" action="test2.php">
<input type="submit">
</form>
</body>
</html>

test2.php--
<?php
Header("Location: test3.php");
?>

test3.php--
<?php
print "Hello World\n";
?>


Quote:
If you open a frameset, IE (or whatsoever browser) open all frames using independent HTTP connections and if you have DBGSESSID session cookie enabled, all they will get debug requests and therefore multiple debug sessions will attempt to start. PHPED 3.2 IDE can not handle more than just one debug session at a time.

Assumed I've got a frameset, loading two php scripts. Now I'll set breakpoints in both of them. Reloading the frameset will miss the breakpoints in one of the two scripts, as the browser uses different connections? Which one will be missed is probably not predictable?

Quote:
Agreed. It's not too convenient to have last executed file opened at the end of debug session.
But why don't you use navigation bar ? It would bring you back to the original point easily.

It's a matter of convenience. I would like to edit the code, press Ctrl-S to save it; switch to the browser; reload the frame or window; Alt-Tab to switch back to PhpED and continue working.

Otherwise, you'll have to remember the file name Wink, find it in the tab. Especially difficult if a dozen of files has been opened by the debugger and "your" file scrolled out of sight. Besides that, you might have a couple of files with the same name (index.php...) Then you probably won't find the right one as fast as you can press Ctrl-F4 Wink.
View user's profileFind all posts by mpSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 8334
Reply with quote
Your help is great and I highly appreciate it.
All the issues are addressed in phped 3.3 with dbg-2.16.3. Now you can debug frameset(s) easily Smile


Last edited by dmitri on Thu Feb 12, 2004 8:48 am; edited 1 time in total
View user's profileFind all posts by dmitriSend private messageVisit poster's website
Some issues I noticed during evaluation/trial
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 5 Hours  
Page 1 of 1  

  
  
 Reply to topic