ActiveState Community Site - Perl - Comments

What about mod_perl?

The ITsmith — Tue, 16 Sep 2008 00:05:20 +0100

How does one use Apache/mod_perl on Linux with ActiveState?

I use a number of applications, such as RT and Bricologe, that utilize mod_perl. Is there a way to configure Apache to utilize ActivePerl instead of the already installed Perl that comes with the distro?

Probably windows command

San — Mon, 18 Aug 2008 12:18:31 +0100

Probably windows command prompt don't like white space in file names unless you encase them in quotes, but talking to your database via command prompt is not very secure anyway. Can you not get the output from within your script using DBI?

I found that some of the

San — Mon, 18 Aug 2008 12:07:19 +0100

I found that some of the modules i wanted to use didn't work well in 64bit so even if you are using 64bit windows I would still recommend using Perl x86 (32bit) for maximum compatability.

Don't bother paying for IIS, Apache works very well and it's free ;)

Just another note on Ruby testing...

ericp — Sat, 09 Feb 2008 03:14:15 +0000

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 18:13:00 +0000

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 11:06:21 +0000

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 — Fri, 08 Feb 2008 04:52:15 +0000

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 22:43:18 +0000

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 17:55:39 +0000

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 15:20:41 +0000

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.

Reading output logs

Arctific — Wed, 31 Oct 2007 16:37:26 +0000

In UNIX I can run the following

$result = system("$sql_cmd > $output_file") ;
if(!open(SQL, " < $output_file ")) {
print "Error: output file not opened\n" ;
exit 1 ;
}
#
### Process file should happen here... but does not.
#

Why does this not work in Windows?
A) File exists.
B) Even a for loop trying to make successive open's does not work.
C) Files quoted well, all backslashes accounted for.

What can I do to make this $output_file visible to windows?

Best Wishes,

Don Turnblade
MS, CISSP