Build Status of CPAN modules from ActiveState

2004-10-02 Thread Gabor Szabo
On this page http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/Repository there are two links to the build status of various CPAN modules using 5.6 and 5.8 respoectively. http://ppm.ActiveState.com/BuildStatus/5.6.html http://ppm.ActiveState.com/BuildStatus/5.8.html Warning: They are

Re: Build Status of CPAN modules from ActiveState

2004-10-02 Thread Andy Lester
I wonder if there was already a way to get the collected data similarry to the one you can get from http://testers.cpan.org/ I suspect they'd be willing to share. I talked to some of the guys from ActiveState out at OSCON and discussed the status issues. Most notably, I want to know if one of

Re: Build Status of CPAN modules from ActiveState

2004-10-02 Thread Ovid
--- Gabor Szabo [EMAIL PROTECTED] wrote: On this page http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/Repository there are two links to the build status of various CPAN modules using 5.6 and 5.8 respoectively. [snip] The individual build results have their own separate files such as

Re: running Devel::Cover in mod_perl (1.3)

2004-10-02 Thread Kevin Scaldeferri
On Sep 21, 2004, at 1:30 PM, Kevin Scaldeferri wrote: So, I don't expect anyone to try to figure out this stack trace stuff, but I'm curious if other people have seen stability problems like this? Alternatively, if someone can tell me the exact logistics of how they get the coverage out in the

Re: running Devel::Cover in mod_perl (1.3)

2004-10-02 Thread Geoffrey Young
Kevin Scaldeferri wrote: On Sep 21, 2004, at 1:30 PM, Kevin Scaldeferri wrote: So, I don't expect anyone to try to figure out this stack trace stuff, but I'm curious if other people have seen stability problems like this? Alternatively, if someone can tell me the exact logistics of

Re: running Devel::Cover in mod_perl (1.3)

2004-10-02 Thread Geoffrey Young
if you haven't investigated Apache-Test yet, I would. our custom make target look like this: I forgot to add some A-T specific stuff :) t/conf/modperl_extra.pl: if ($ENV{HARNESS_PERL_SWITCHES}) { eval { require Devel::Cover; Devel::Cover-import('+ignore' = 't/response/',

Re: running Devel::Cover in mod_perl (1.3)

2004-10-02 Thread Paul Johnson
On Sat, Oct 02, 2004 at 11:20:05AM -0700, Kevin Scaldeferri wrote: On Sep 21, 2004, at 1:30 PM, Kevin Scaldeferri wrote: So, I don't expect anyone to try to figure out this stack trace stuff, but I'm curious if other people have seen stability problems like this? Alternatively, if

Re: running Devel::Cover in mod_perl (1.3)

2004-10-02 Thread Geoffrey Young
Kevin Scaldeferri wrote: On Oct 2, 2004, at 12:36 PM, Geoffrey Young wrote: we use Apache-Test, which starts the server, runs the tests, and shuts down the server again. When I last talked with you about Apache-Test, I seem to recall that you said that it was restricted to

Re: running Devel::Cover in mod_perl (1.3)

2004-10-02 Thread Geoffrey Young
[ Just before sending this I notice Geoff has recommended something better, but I'll send this too as another WTDI. ] cool :) I started to maintain Apache-Test skeletons, but I never quite got them up to speed. give me a few days and I'll roll a tarball with a test-cover target so that folks

Re: running Devel::Cover in mod_perl (1.3)

2004-10-02 Thread Kevin Scaldeferri
On Oct 2, 2004, at 12:36 PM, Geoffrey Young wrote: we use Apache-Test, which starts the server, runs the tests, and shuts down the server again. When I last talked with you about Apache-Test, I seem to recall that you said that it was restricted to running the tests serially. Is this still

Re: running Devel::Cover in mod_perl (1.3)

2004-10-02 Thread David Wheeler
On Oct 2, 2004, at 2:30 PM, Geoffrey Young wrote: I started to maintain Apache-Test skeletons, but I never quite got them up to speed. give me a few days and I'll roll a tarball with a test-cover target so that folks can have an entire working example of the way I would do it. Perhaps I should

Re: [pid-mode.el] cannot edit

2004-10-02 Thread Jerome Quelin
On 04/10/01 23:22 +0100, John Paul Wallington wrote: Jerome Quelin [EMAIL PROTECTED] writes: And the minibuffer tells me: Symbol's function definition is void: line-beginning-position I'm using xemacs 21.4.14 How about defining a compatibility alias if necessary like so: ---

Re: Threads on Cygwin

2004-10-02 Thread Leopold Toetsch
Joshua Gatcomb [EMAIL PROTECTED] wrote: PIO_OS_UNIX is the one defined and now parrot squawks Polly wanna Unix everytime I run it ;-) Now what? Fix the thread related IO bug? Seriously, I don't know yet, if the IO initialization is done correctly for threads. Currently each thread has its

Re: [perl #31725] [PATCH] non-branching compare opcodes - tests

2004-10-02 Thread Stephane Peiry
This patch adds tests for iscompare style ops (isgt, isge, isle, islt, iseq, isne) on integers, numbers and strings, in t/op/comp.t. Thanks, Stéphane PS.: maybe t/op/*.t could be reorganized so that test filenames match what is under ops/*.ops? and t/op would test only I, N, and S stuff,

Re: [perl #31726] [PATCH] non-branching compare opcodes - JIT

2004-10-02 Thread Stephane Peiry
These two patches add jit support for iscompare style ops (isgt, isge, isle, islt, iseq, isne) on integers for the sun/sparc platform. The jitted code follows this pattern: cmp %r2, %r3 bc,a next mov 1, %r1 mov 0, %r1 next: .. c

Re: [perl #31726] [PATCH] non-branching compare opcodes - JIT

2004-10-02 Thread Stephane Peiry
Sorry the previous core.jit patch for sun contained a typo. The correct patch file is attached here again. Thanks! Stephane On Sun, Sep 26, 2004 at 02:40:29AM -0700, Leopold Toetsch wrote: The integer and number variants of these opcodes could need JIT support. Index: jit/sun4/core.jit

[perl #31806] pio_registered_layers is a global

2004-10-02 Thread via RT
# New Ticket Created by Nicholas Clark # Please include the string: [perl #31806] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31806 --- osname= freebsd osvers= 5.2-beta arch= i386-freebsd cc= cc ---

[perl #31807] make install not portable

2004-10-02 Thread via RT
# New Ticket Created by Nicholas Clark # Please include the string: [perl #31807] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31807 --- osname= linux osvers= 2.6.8-1-686 arch= i386-linux-thread-multi cc=

Plain ole Hash

2004-10-02 Thread William Coleda
Are there any plans to make a Hash (as oppposed to a PerlHash, or an OrderedHash (which is really a PerlHash) ?

Re: [perl #31806] pio_registered_layers is a global

2004-10-02 Thread Jens Rieks
On Saturday 02 October 2004 15:19, Nicholas Clark wrote: # New Ticket Created by Nicholas Clark # Please include the string: [perl #31806] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31806 So I had a dig

Re: [perl #31806] pio_registered_layers is a global

2004-10-02 Thread Nicholas Clark
On Sat, Oct 02, 2004 at 04:51:09PM +0200, Jens Rieks wrote: Should be fixed. At least, no test fails on OpenBSD now. No tests fail on FreeBSD or OS X now. I'm not convinced that I want to close the bug, as I still don't think that the code is threadsafe, as there are globals accessed without

[CVS ci] --prefix

2004-10-02 Thread Nicholas Clark
I added a --prefix argument to Configure.pl, to set the installation prefix for make install. Previously make install seemed to work just fine, but you had to override PREFIX at make time, which isn't great. This way, parrot's configure build system behaves like that of most other open source

What is PAST?

2004-10-02 Thread Sam Ruby
Please forgive the newbie question, but I am trying to see if I can assess the current state of Python on Parrot to see if I can help in any way. I've jotted down some of what I have found so far here: http://www.intertwingly.net/blog/2004/10/02/Pyrate - Sam Ruby

Re: [perl #31806] pio_registered_layers is a global

2004-10-02 Thread Jens Rieks
On Saturday 02 October 2004 17:50, Nicholas Clark wrote: No tests fail on FreeBSD or OS X now. Great! I'm not convinced that I want to close the bug, as I still don't think that the code is threadsafe, as there are globals accessed without mutex protection. However, I don't know how parrot is

Re: [pid-mode.el] cannot edit

2004-10-02 Thread John Paul Wallington
Now it works, I can use spaces and returns. But while fontifying, I get: (5) (warning/warning) Error caught in `font-lock-pre-idle-hook': (invalid-regexp Invalid syntax designator) How about this fix: Index: pir-mode.el === RCS