Hi,

I would like to buy a copy of a command Line DbgListener. I am currently using vim as my IDE and would like to integrate dbglistener with vim for my development. How do I proceed?

Thanks.

dbglistener is a library, not a separated executable as it might look like. It has its own API and should be invoked and used by an IDE which knows this API. It usesless for VIM. What you may think of to work from VIM is dbg-cli (dbg console front end) which is availabe for free. Although, I have never run dbg-cli from neither VIM nor any other application, but DDD debugger.

Thanks for your reply.


But dbg-cli doesn't have a listener and doesn't seem to work very well. i want to have a full fledged command line debugger tool for php and is ready to pay for it. Is there anyway i can proceed.

What i need is a commercial (free stuff wont do) php command line debugger. Full featured (It should have the listen feature).

Thanks again.

I second the need for a fully functional dbg-cli - one that I might be able to purchase - I too am having a lot of difficulty with dbg-cli, and feel that the lack of an equivalent (to phped) cli debugger really hurts the php community.

In fact, I'm not sure why the command line debugger is *separate* from php. Why isn't it bundled, like perl's? Activestate - and several other third-party vendors provide IDEs, but there is always the good old perl -d ... to be invoked from the command line.. Python is the same way too..

So why not make dbglistener and dbg-cli be supported by the php developers? They could port it to every platform in existence under the sun for you, and do tons of debugging for you, for free. After all, I think the only big market is for IDEs anyways...

Hi,
dbglistener.so.2 is the library, i guess. So is its api publicly available? If not what should i do to get access to it.

i have downloaded the evaluation copy of phped and it looks far better than the java based zend, but before commiting to it, i would like to know if i can get a decent command line debuggin tool when i buy phped.

Thanks in advance for your response.

You are right, but it is not Dimitri's fault it seems, since the dbg-cli is already open-source. The thing is, no php open source developer has felt the need enough to have a good debugger, which is why the project is languishing.

php people seem to be content with print - especially the open source ones.. Going through the net, i did not find an overwhelming demand for a php debugger, which is in fact why it doesn't exist.

Regards.

what's up ?
what do you mean under
???
it's getting fun
look at phped and see dbg acts as a fully functional debugger. Where IS the problem ? what does not exist ?

Here's stuff dumbed down for ya.

- Php lacks a FREE debugger (Unlike perl and python)

- It does't have a proper command line Debugger even in commercial IDEs.

So can we have dbg as a commandline Debugger in PhpEd? Do we have access to its API (AT least after we buy the whole suit?)

Thanks.

It still unclear what you want.
Dbg-cli is a freeware debugger console. See http://www.php-debugger.com/
What else do you need ?

DbgListener is a part of PHPEd which is commercial product available from http://www.nusphere.com/

what he wants is a commercial dbg-cli which *also* uses dbglistener.

You mentioned it yourself - dbg-cli doesn't handle post and you need to manually type in URLs to get it to work. It cannot do some basic things that phped can do, so therefore it isn't a viable substitute.

In other words, it doesn't have a dbglistener frontend. From my point of view, there are other drawbacks to dbglistener: not available on many platforms, and unable to be debugged.

Like I said, I'd be willing to purchase a command-line interface like this, but IMO it shouldn't be this way.. I think that if you dual-licensed dbglistener. as QT does, you'd get the best of both worlds - free for those who are doing non-profit stuff, paid for commercial environments, and lots of free porting/debugging thrown in.

dbglistener does not support POSTS too. HTTP/POST is what you run from the browser using <form method=post>. Alternatively you may add POST variable using phped run->parameters, in this case phped passes that value to IE for further processing anyways. Nothing really special. From my own point of view the matter is that dbglistener listens for incoming conections permanently while dbg-cli does it only when you run RUN command and does it for ~ 15 seconds only.

well, perhaps I've got something wrong here. I'm assuming with dbglistner that:

browser gets connection, dbg.so intercepts it
dbglistener picks up connection from browser
dbglistener forwards data stream to phped for processing.

Hence, when I say 'it supports POST', I'm assuming that by being able to run from the browser an appropriate PHP command, that phped will be able to pick up the effects on the php script from having a <form method=post> in the html.

And, if dbg-cli did the same thing as dbglistener, it would 'support POST', too.. ie: you are using the browser logic to do the hard work for you rather than cutting and pasting the information into a 'file' command.

Is this correct? Is there a fundamental way that dbglistener listens for connections as opposed to dbg-cli? Or could I simply change the 15 second timeout into an indefinite one in dbg-cli to get the effect that I want (ie: going through the browser to drive dbg-cli)?

(ps - I think I know what's going on with my timeout - I'm assuming that dbg-cli can be used to debug *standalone* applications, ie: that

dbg> file <file>
dbg> run

doesn't assume *anything* is running in the background, only that php is installed with dbg.so attached and that dbg-cli does the work for you. Is this correct? Or do I need to make a web browser spawn a php connection, or fire off a php script from another window?
)