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

[Gabor Szabo]

It has biten me so let's make sure invalid --gc options are not allowed.


Index: lib/Parrot/Configure/Options.pm
===
--- lib/Parrot/Configure/Options.pm (revision 20963)
+++ lib/Parrot/Configure/Options.pm (working copy)
@@ -48,6 +48,9 @@
 }
 $data->{$key} = $value;
 }
+if ($data->{gc} and $data->{gc} !~ /^(gc|libc|malloc|malloc-trace)$/) {
+croak "Invalid value for 'gc' argument.\nType perl
Configure.pl --help to see available values";
+}
 if (@short_circuits_seen) {
 # run all the short circuits
 foreach my $sc (@short_circuits_seen) {

Re: Build Farm

[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:
http://www.szabgab.com/blog/2007/07/1183825266.html

I liked it very much though I have some issues that I think should be
improved there too.

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.

I am quite in favor of having something like the PostgreSQL build farm
integrated with TAP::Parser and possibly Smolder and adding some other
features as well. So I'd be glad to participate in your project and help
making sure that the all the needs of the Parrot team are
addressed.

Gabor



On 8/30/07, David Fetter <[EMAIL PROTECTED]> wrote:
> Folks,
>
> I'm working on generalizing PostgreSQL's buildfarm code
> , an automated build and test system, and
> of course I thought of Parrot.
>
> The requirements are very light:
>
> * Disk space for the source code and build
> * Connectivity to the internet via HTTP or HTTPS
> * Some way (cron, e.g.) to run jobs regularly
> * Some way to get regular updates to one or more branches of the
>   source code
>
> Would people here be interested in running clients on various
> architectures, OSs, compilers, etc.?  What kinds of things would you
> like to see in a status overview page like this one:
>   How about in
> detailed build reports?
>
> Cheers,
> David.
> --
> David Fetter <[EMAIL PROTECTED]> http://fetter.org/
> phone: +1 415 235 3778AIM: dfetter666
>   Skype: davidfetter
>
> Remember to vote!
> Consider donating to PostgreSQL: http://www.postgresql.org/about/donate
>


-- 
Gabor Szabo
http://www.szabgab.com/

Re: [perl #45099] [TODO] Remove Parse::RecDescent from 'trunk'

[Bernhard Schmalhofer]

James Keenan via RT schrieb:
It looks like nobody, besides the devel tool 
./languages/m4/tools/frozen2yaml.pl, uses

Parse::RecDescent.

Does anybody mind if I remove it from trunk?



I have no objection.  It's included in Bundle::Parrot 
(http://search.cpan.org/dist/Bundle-Parrot/Parrot.pm), so it's not like 
we're banishing it.
  

The point is, if nobody is using it, than it can and should be banished.
So Parser::RecDescent, and possibly other Modules, can be removed from 
Bundle::Parrot

as well.


Regards,
 Bernhard

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

[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. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=45101 >


In the examples/tutorial directory there is a large number of PIR examples.
It would be nice have tests for them.
t/examples/pir.t suggests a possible way of doing this.

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

[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 anything  
  > in Test::Simple v0.70 that we need for Parrot that couldn't have been  
  > found in 0.54 or 0.62?

  > What is there to prevent us from configuring Bundle::Parrot as  
  > specifying *minimum* versions of modules rather than the *latest*  
  > versions thereof?

Dependencies and bundles are orthogonal concepts. One usually
specifies dependencies in the {Makefile,Build}.PL.

* if you install a Bundle, do not complain, (just don't use it instead)

* DO complain, if a distribution does not specify all of its dependencies

Bundles contain goodies. Or they are used as a workaround when
dependency declarations do not work for some reason.

-- 
andreas

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

[James E Keenan]

Gabor Szabo wrote:

It has biten me so let's make sure invalid --gc options are not allowed.


Index: lib/Parrot/Configure/Options.pm
===
--- lib/Parrot/Configure/Options.pm (revision 20963)
+++ lib/Parrot/Configure/Options.pm (working copy)
@@ -48,6 +48,9 @@
 }
 $data->{$key} = $value;
 }
+if ($data->{gc} and $data->{gc} !~ /^(gc|libc|malloc|malloc-trace)$/) {
+croak "Invalid value for 'gc' argument.\nType perl
Configure.pl --help to see available values";
+}
 if (@short_circuits_seen) {
 # run all the short circuits
 foreach my $sc (@short_circuits_seen) {


Gabor,

While I appreciate the intent of your patch, it's not focused where it 
needs to be.


lib/Parrot/Configure/Options.pm's sole purpose is to provide 
functionality needed for processing of command-line options by both 
Configure.pl and tools/dev/reconfigure.pl.  It has nothing to do with 
deciding whether a user-supplied *value* for a particular option is 
valid or not.  The validity of a user-supplied value for an option must 
be determined by the particular configuration step in which that 
option's value is consulted.


I would recommend that you reformulate your patch as follows:

1.  Change the description of the --gc option provided in 
lib/Parrot/Configure/Options/Conf.pm's print_help() subroutine.  This is 
the usage message for Configure.pl.  That description currently occurs 
on lines 175-176 of that package.


2.  Modify config/auto/gc.pm to have configuration step auto::gc fail if 
any invalid option is provided.  (I did a quick grep on config/ and this 
is the only place I saw the 'gc' option handled -- but I might have 
gotten confused by the many instances of 'gcc'.)  A statement along the 
lines of 'return unless $gc =~ /list|of|valid|options/;' around line 62 
of that package would probably be the way to go.


Thank you very much.
Jim Keenan

Re: Build Farm

[James E Keenan]

Gabor Szabo wrote:

Hi David,

if non of the core Parrot developers answer you then let me,
the newcomer do so.



David,

To second what Gabor said:  I think this would be an excellent project 
for other newcomers to the Parrot project, particularly those whose 
skills primarily lie in Perl 5.  I would encourage those newcomers to 
contact you guys to see how they can help with both the evaluation of 
different approaches to smoke testing and the development of a proposal 
for a particular approach.


Jim Keenan

[perl #44997] Failure in t/configure/029-option_or_data.t

[James Keenan via RT]

Andy (and anybody else who's following this ticket),

Can you please copy the 4 files attached to a sandbox for trunk and run
them (e.g., perl Configure.pl --test=configure)?

In my first attempt to write tests for Andy Lester's option_or_data()
function I figured it would be best to work with the same option he was
using that method for:  'cc'.  But, as Andy Dougherty has demonstrated,
that runs into complications with a package like
config/init/hints/solaris.pm which has callbacks.

But for testing purposes we can use *any* Parrot command-line option
which has the same name as a key in the Parrot::Configure object's {c}
structure.  So in revamping the tests I figured I'd test an option which
is determined much earlier in the configuration process and is much
simpler:  --bindir.

Please let me know if these tests pass on all OSes.  Thank you very much.

kid51



030-option_or_data.t
Description: Binary data


027-option_or_data.t
Description: Binary data


028-option_or_data.t
Description: Binary data


029-option_or_data.t
Description: Binary data

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

[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 of the modules you have works, and they're lower
than what Bundle::Parrot lists, then change them. :)

Shawn

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

[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 that works. If you find that
whatever versions of the modules you have works, and they're lower
than what Bundle::Parrot lists, then change them. :)


That can lead to subtle flaws when a version got bumped because of a  
single platform fix or other voodoo.




Shawn





PGP.sig
Description: This is a digitally signed message part

Re: TAP::Harness

[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 like each one of them is building-up a list of tests 
in code (either with array declarations, globs, etc -- and affected by 
various environment vars and/or switches.)

Other than sorting-out all of that, it's a simple matter of subclassing 
TAP::Harness and overriding a few methods such as _get_parser_args().

At least, I think that will do it.

--Eric
-- 
"Left to themselves, things tend to go from bad to worse."
--Murphy's Corollary
---
http://scratchcomputing.com
---

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

[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. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=45109 >


In languages/lisp/system.pir there are 4 unused PMCs declared.
Removing one of them breaks Lisp.

Here  is an example session:

[EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ svn diff
Index: system.pir
===
--- system.pir  (Revision 20981)
+++ system.pir  (Arbeitskopie)
@@ -24,7 +24,6 @@
 .local pmc dummy_1
 .local pmc dummy_2
 .local pmc dummy_3
-.local pmc dummy_4

 _init_reader_macros( package )

[EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ ../../parrot 
lisp.pbc t/arithmetics_1.l
wrong number of arguments to %GET-OBJECT-ATTRIBUTE
current instr.: '_error' pc 2065 (read.pir:194)
called from Sub '_get_object_attr' pc 7321 (system.pir:12)
called from Sub '_setq' pc 14048 (cl.pir:941)
called from Sub '_load' pc 7021 (system.pir:436)
called from Sub '_common_lisp' pc 17015 (lisp.pir:77)
[EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ uname -a
Linux clou 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC 2007 i686 GNU/Linux
[EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ cat /etc/issue
Ubuntu 7.04 \n \l

[EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ 


My guess is that this is GC-related, but I haven't verified or falsified 
that yet.

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

[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 actually.
It seems the beer from YAPC::EU still have not fully settled down..


> On Sep 1, 2007, at 12:35 PM, Gabor Szabo wrote:
>
> > Thanks for the pointers, I was not sure where to add this.
> >
> > On 9/1/07, James E Keenan <[EMAIL PROTECTED]> wrote:
> >> 2.  Modify config/auto/gc.pm to have configuration step auto::gc
> >> fail if
> >> any invalid option is provided.  (I did a quick grep on config/
> >> and this
> >> is the only place I saw the 'gc' option handled -- but I might have
> >> gotten confused by the many instances of 'gcc'.)  A statement
> >> along the
> >> lines of 'return unless $gc =~ /list|of|valid|options/;' around
> >> line 62
> >> of that package would probably be the way to go.
> >
> > The problem is that if I place a return;  in the function you
> > recommended
> > the configuration process displays a small error message, then
> > a bigger unrelated one (at least unrelated from the point of view
> > of the
> > user running it) , creates the Makefile and exit()s with exit value 0
> > meaning success.
> > It also suggests to type in 'make' to build Parrot.
> >
> > Even if I croak() in that function, the same happens.
> >
>
> I understand your point -- but it's a much larger point than the
> permissible values for the --gc option.  Read on.
>
> > IMHO if a user supplies an invalid option (to --gc or any other
> > parameter)
> > an appropriate error message should be printed, the configuration
> > process
> > should be halted and exit() should indicate failure.
>
> All of the (currently) 58 Parrot configuration steps are set up to
> return undef on failure.  But Parrot::Configure::runsteps() is set up
> as a harness that reports failures in individual steps/tasks but
> nonetheless tries to keep going forward.  It does nothing with the
> return value of a particular step.
>
> #
> sub runsteps {
>  my $conf = shift;
>
>  my $n = 0;# step number
>  my ( $verbose, $verbose_step, $ask ) =
>  $conf->options->get( qw( verbose verbose-step ask ) );
>
>  foreach my $task ( $conf->steps ) {
>  $n++;
>  $conf->_run_this_step( {
>  task=> $task,
>  verbose => $verbose,
>  verbose_step=> $verbose_step,
>  ask => $ask,
>  n   => $n,
>  } );
>  }
>  return 1;
> }
> #
>
> Whether that's what it ideally *should* be doing is a valid
> question.  But in the refactoring/testing work I've been doing on it
> in recent months, I've viewed it as my mandate to preserve its
> current functioning unless there's a strong consensus that change is
> needed.
>
> Some might argue, "If you're foolish enough to continue on to 'make'
> when your configuration process is spewing error messages, you get
> what you deserve."  That's in effect what happens now.
>
> Another alternative would be to note whether any of the configuration
> steps fails, then change the message which
> Parrot::Configure::Messages::print_conclusion() prints after all the
> configuration steps complete.

At this point I really don't want to get involved any deeper in the development
and I am sure you will clean this up later so I'll try to send a patch according
to what you 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 any other fully automated smoke test suite to make sure we won't go on
when the configuration step fails.

Gabor

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

[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' ) {
 $gc = 'gc';
 $conf->data->set(
 TEMP_gc_c => <<"EOF",
@@ -116,7 +116,11 @@
 TEMP_gc_o => "\$(SRC_DIR)/gc/resources\$(O)",
 gc_flag   => '',
 );
-}
+} else {
+print STDERR "Inavlid value '$gc' for the --gc option\n";
+return;
+}
+
 print(" ($gc) ") if $conf->options->get('verbose');

 return $self;

Storable: Cannot restore overloading

[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 line 197.
Cannot restore overloading on HASH(0x82e23d4) (package 
Parrot::Pmc2c::Emitter) at lib/Storable.pm (autosplit into 
lib/auto/Storable/_retrieve.al) line 323, at 
/usr/src/parrot/tools/build/dynpmc.pl line 200
make[1]: *** [all] Error 255
make[1]: Leaving directory `/usr/src/parrot/src/dynpmc'
make: *** [dynpmc.dummy] Error 2

This is after "make realclean" and updating to revision 20991, using
Perl 5.8.1, which includes Storable 2.08.  All the *.dump files do seem
to be getting regenerated.  (The "using Storable.pm ..." output line is
something I added to see which version was getting loaded.)

   If the solution is to upgrade this package, then perhaps the "All you
need is Perl 5.8.0 or later ..." statement in docs/gettingstarted.pod
should be qualified a bit.

   TIA,

-- Bob Rogers
   http://rgrjr.dyndns.org/

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

[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 true path
> 
> 512   for (ins2 = ins->next; ins2; ins2 = ins2->next) {
...
> Event freed_arg: Pointer "ins2" freed by function "subst_ins" [model]
> Also see events: [alias][use_after_free]
> 
> 536   subst_ins(unit, ins2, tmp, 1);

There's "Also see events: [freed_arg][use_after_free]" and there's a
line saying "Event freed_arg: ..."

Then there's "Also see events: [alias][use_after_free]" and a line
saying "Event alias: ..."

This makes we wonder if there's any line saying "Event use_after_free:
..." in the report?

Thanks,
Ron

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

[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 any other fully automated smoke test suite to make sure we won't  
go on

when the configuration step fails.



While I personally have no big problem with the current setup, Gabor  
raises an interesting point.


Could we get some discussion of the pros and cons of different  
alternatives?


-- Should Configure.pl die when one of its steps fail?
-- Should it not die, but exit with a nonzero exit code?
-- Should it not die, but trigger a different message on STDOUT?
-- Or is the current setup, on balance, best suited for our needs?

kid51

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

[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.