Re: Build Farm

2007-09-01 Thread Gabor Szabo
Hi David, if non of the core Parrot developers answer you then let me, the newcomer do so. Recently I have been involved in a little research where I was looking at various automatic build and test smoking systems. Among others I looked at the PostgreSQL build farm as well. See my blog entries:

[perl #45101] [TODO] add t/examples/tutorial.t, which tests examples/tutorial/

2007-09-01 Thread via RT
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #45101] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45101 In the examples/tutorial directory there is a large number of PIR examples.

Re: [perl #45103] [TODO] Bundle::Parrot should require minimum version only

2007-09-01 Thread Andreas J. Koenig
On Fri, 31 Aug 2007 17:47:56 -0700, James Keenan (via RT) [EMAIL PROTECTED] said: In order to continue as a Parrot developer, do I really need to perform yet another upgrade of Module::Build or Pod::Simple (distros for which I have little use)? More to the point, is there

Re: [perl #45103] [TODO] Bundle::Parrot should require minimum version only

2007-09-01 Thread Sartak
On 8/31/07, via RT James Keenan [EMAIL PROTECTED] wrote: What is there to prevent us from configuring Bundle::Parrot as specifying *minimum* versions of modules rather than the *latest* versions thereof? It isn't easy to find the minimum version that works. If you find that whatever versions

Re: [perl #45103] [TODO] Bundle::Parrot should require minimum version only

2007-09-01 Thread Jesse Vincent
On Sep 1, 2007, at 12:19 PM, Sartak wrote: On 8/31/07, via RT James Keenan [EMAIL PROTECTED] wrote: What is there to prevent us from configuring Bundle::Parrot as specifying *minimum* versions of modules rather than the *latest* versions thereof? It isn't easy to find the minimum version

Re: TAP::Harness

2007-09-01 Thread Eric Wilhelm
# from Gabor Szabo # on Saturday 01 September 2007 01:35 am: Regarding Parrot, I think there was some discussion of moving it to use TAP::Harness and to use Smolder to collect the TAP based results. Indeed. We determined that the main task is refactoring all of the t/harness files. It looks

[perl #45109] [Lisp] Breakage when an unused PMC is removed

2007-09-01 Thread via RT
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #45109] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45109 In languages/lisp/system.pir there are 4 unused PMCs declared. Removing one

Re: [PATCH] don't allow invalid --gc options

2007-09-01 Thread Gabor Szabo
On 9/1/07, James E Keenan [EMAIL PROTECTED] wrote: (Gabor: You didn't cc: the list on this, so I'm replying directly to you. But I think the issues you are raising merit discussion on the list. So please feel free to copy what I write below to the list.) Sure, I meant to send it to the list

[PATCH] don't allow invalid --gc options (2nd try)

2007-09-01 Thread Gabor Szabo
Index: config/auto/gc.pm === --- config/auto/gc.pm (revision 20963) +++ config/auto/gc.pm (working copy) @@ -107,7 +107,7 @@ gc_flag = '-DGC_IS_MALLOC', ); } -else { +elsif ( $gc eq 'gc' ) {

Storable: Cannot restore overloading

2007-09-01 Thread Bob Rogers
Does this error mean that the version of Storable.pm I am using is too old? make -C src/dynpmc make[1]: Entering directory `/usr/src/parrot/src/dynpmc' using Storable.pm /usr/lib/perl5/5.8.1/i586-linux-thread-multi/Storable.pm at /usr/src/parrot/tools/build/dynpmc.pl

Re: [perl #44967] Using a freed variable (Coverity CID 98)

2007-09-01 Thread Ron Blaschke
Paul Cochrane wrote: I've had a chance to look at this and the implementation looks quite good to me. There's one thing that still bothers me. The snipped output is: Event alias: aliasing (ins)-next with ins2 Also see events: [freed_arg][use_after_free] At conditional (1): ins2 != 0 taking

What should Configure.pl do when one of its steps fail?

2007-09-01 Thread James E Keenan
On Sep 1, 2007, at 1:58 PM, Gabor Szabo wrote: One thing though, I think it would be really good if at least the exit code of the script would be something different from 0 when any of the steps failed. That will be very important when we try to integrate with the PG Build Farm or

[perl #44645] [PATCH] [NEW] Refactor configuration options processing

2007-09-01 Thread James Keenan via RT
A week has gone by since this patch was applied and it appears that, except for a few expected hiccups with 'make realclean', everyone made the transition okay. So I am closing the ticket.