ActiveState Community Site - PHP - Comments

Comment out doc_root line in php.ini

troyt — Thu, 12 Jun 2008 13:48:55 -0700

It looks like doc_root setting in the php.ini bundled with Web Developer Suite 2.0 causes problems for the remote debugger. Comment out that line in c:\www\php5\debug\php.ini and it should work.

Thanks for bringing this to our attention! We'll create a bug for Komodo to handle this better and mention it in the release notes, but it's unlikely to be fixed in time for the 4.4 release.

Re: try latest Komodo (4.3.2)

osmosis — Tue, 10 Jun 2008 17:51:29 -0700

Thanks for the help Todd.

I'm using:

Komodo IDE, version 4.4.0-beta1, build 19400, platform win32-x86.
Built on Fri May 30 02:25:59 2008.

Web Developer Suite 2.0 which includes Apache 2.2 and PHP 5.2.5
http://sourceforge.net/projects/webdeveloper/

Preferences, PHP Language:

Interpreter: c:\www\php5\php.exe
php.ini: c:\www\php5\debug

I also tested with c:\www\php5\php-cgi.exe and received the same results.

the debug\php.ini was created during installation of Komodo. It's the default php.ini with the following prepended from Komodo:

; xdebug config added by Komodo
zend_extension_ts=C:\www\php5\ext\php_xdebug.dll
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_port=9000
cgi.force_redirect = 0

I verified that those parameters are commented out everywhere else in the php.ini file.

Choosing Debug -> Go/Continue:

I choose "Use the CGI interpreter"

I check "Simulate CGI Environment"

and I add the post values according to the debugging PHP tutorial / demo.

It works if I choose "Use the CLI interpreter", but then it doesn't allow me to specify the post variables.

The only thing I can think to add at this point (in case it helps) is a copy of the php.ini along with lists of extensions enabled in php.

Re: try latest Komodo (4.3.2)

ToddW — Tue, 10 Jun 2008 10:57:00 -0700

Can you try using Komodo 4.3.2 or the Komodo 4.4 beta:
http://downloads.activestate.com/Komodo/releases/

If that does not fix the problem, we'll need some additional details like:
* where did you download PHP from
* how are performing the CGI debugging (through Komodo's Debug - F5 command)
* which interpreter is set in your PHP language preferences

Thanks,
Todd

any other ideas?

osmosis — Mon, 09 Jun 2008 21:54:08 -0700

What else could be causing this? I've tried everything above with no luck.

Komodo 4.3 beta
PHP 5.2.5
Windows XP

The trial period ran out before I had a chance to test cgi debugging, so I installed the beta to extend my trial and finish testing things out...

Just another note on Ruby testing...

ericp — Fri, 08 Feb 2008 19:14:15 -0800

The Ruby test harness is actually a Test::Unit harness, but given our time
frame, and that I had only one place to locate it, it made more sense to
position it within Rake, instead of using it standalone.

Live I've been saying here, more harnesses will be on their way.

The Perl 'make test' harness analyzes your environment

ericp — Fri, 08 Feb 2008 10:13:00 -0800

On non-Windows platforms, it assumes make is called "make".
If it finds one in the path, it uses it. Otherwise it
doesn't run the tests.

On Windows, it first checks the path, but if no "nmake.exe"
is found that way, it looks in the registry for the location
of a Visual Studio installation, and finds nmake.exe that
way.

Note that if you're testing an XS library, and nmake wants
to rebuild part of it, you need to have the Visual C++
environment loaded when Komodo is launched.

Perl Test harness

CountZero — Fri, 08 Feb 2008 03:06:21 -0800

I see that the tests for a Perl project will be run by using the "make test" invocation.

As Windows users normally use the "nmake.exe" utility (which may or may not be in the PATH Windows looks at to find it), could you perhaps consider adding the possibility to choose the "make/nmake" utility to be used?

CountZero

Ruby testing tools

znmeb — Thu, 07 Feb 2008 20:52:15 -0800

Ruby has a very active set of developers that focus mostly on testing tools, behavior- and test-driven development. I can name some packages: rspec, heckle, flog, zentest, selenium, cerberus and rcov just popped into my head with little thought. I suspect the most commonly used test-driven development tool at the moment is still Test::Unit, but rspec is gaining ground quickly.

I think rake is the right "first step". It's the Ruby equivalent of Java's "ant" and Python's "scons". But that's really what it is -- a *build* tool, not a testing tool. The ones I listed above are the testing tools.

Speaking of new features migrating out of the generic command tool, one of the things I find myself wanting is the ability to associate a file type with an editor *other* than Komodo. For example, a lot of my projects have documents edited with the LyX LaTeX editor. Right now, for example, I have a little command box in the project that I can double-click on to open a specific document in LyX. I suppose I could go find the LyX icon and replace the little terminal symbol with it, and no one would be the wiser. :)

Again, we plan to add support for other harnesses

ericp — Thu, 07 Feb 2008 14:43:18 -0800

That would include Module::Build, but most of the CPAN modules I sampled
still use MakeMaker.

The kind of output that Devel::Cover generates doesn't fit as well
in the Komodo Test Plan Results window. However, ActiveState
does have a nice solution for pulling graphical information out
of Devel::Cover runs with version 7.1 of the Perl Dev Kit.

See http://www.activestate.com/Products/perl_dev_kit/fix.mhtml
for more information.

Roadmap for unit test support

ericp — Thu, 07 Feb 2008 09:55:39 -0800

For the alpha we're supporting one type of test harness for
each of the four languages listed above. The next step will be
to add support for more harnesses (and possibly more languages).

For Ruby the next step will most likely support running of
arbitrary tests based on Test::Unit, similar to the current
support for Python tests.

Can the command used for unit tests be changed?

znmeb — Thu, 07 Feb 2008 07:20:41 -0800

For Ruby, you have the unit tests defined by running "rake" and having the user specify the rest of the command line. If that's *all* it does, then it seems to me that it's only a shorthand for building a command widget to run Rake. The only difference is that in a unit test, I don't have to type the first word of the command line when I set it up, just the rest of it. Moreover, the way it's done now, I'm limited to using "rake" to run my tests.

What I think would be more convenient would be to either add an extra field to the dialog box for the user to select the test initiation command, or having the user specify the whole command line in the command line entry field you have now. That way, I could start my tests with "spec specs.rb", which is the way I normally do unit tests.

Todd, Your fix worked

brice — Tue, 24 Jul 2007 19:35:46 -0700

Todd,

Your fix worked perfectly. Thanks for the prompt response.

I assume this has made it's way into the beta -- which I look forward to participating in once I purchase the IDE. Komodo is, after all, a project worth supporting! ;)

~ Brice

Fort a more permanent fix

ToddW — Tue, 24 Jul 2007 14:32:00 -0700

Open up Komodo file:
<install_dir>/lib/mozilla/components/koInvokeInterpreters.py

At line 600, add another environment flag "SCRIPT_FILENAME" so it looks like:

env["SCRIPT_NAME"]=scriptName
env["SCRIPT_FILENAME"]=pathTranslated
env["REQUEST_METHOD"]=requestMethod

Restart komodo and your CGI scripts should debug properly.

Cheers,
Todd

Similar Experience

brice — Mon, 23 Jul 2007 21:56:57 -0700

I am having a similar experience under Archlinux (not Ubuntu) using Komodo 4.1.1, build 279677, platform linux-libcpp5-x86.

Regardless of the cgi.force_redirect setting, I get the 'No input file specified' message upon debugging with CGI Emulation. I see that the Debugger Configuration wizard sets cgi.force_redirect to 0 in its "copied" php.ini (along w/ the xdebug reference).

The only way I found around this issue was to manually set the SCRIPT_FILENAME as a CGI environment variable. Set this to the absolute path of the .php file to be debugged.

Screenshot: - http://farm2.static.flickr.com/1419/882417034_53018a8b16_o.png

Does anyone have other ideas for a fix?

Thanks,

~ Brice

This is because the Ubuntu

jeffg — Wed, 28 Feb 2007 16:25:00 -0800

This is because the Ubuntu PHP is set to discard the script file path and not set SCRIPT_FILENAME in the environment. I have yet to find a magic bullet for this issue when using Ubuntu's php build.

--
JeffG | Komodo IDE 4.0 | MacBook Pro OS X Intel / Ubuntu 6.10 i386