develooper Front page | perl.perl5.porters | Postings from July 2003

*VERSION 2* Notes p5p BOF

Thread Next
Elizabeth Mattijsen
July 29, 2003 03:14
*VERSION 2* Notes p5p BOF
Message ID:
These are the minutes of the p5p BOF that was held on Saturday 27th 
of July in Paris.  We started around 2 pm.  We left the place around 

The following people were there and/or participated in one form or 
another (in no particular order):

   Hugo van der Sanden
   Jarkko Hietaniemi
   Elaine Hietaniemi Ashton
   Elizabeth Mattijsen
   Rafael Garcia-Suarez
   H Merijn Brand
   Tim Bunce
   Stas Bekman
   Arthur Bergman
   Nicholas Clark
   Jos Boumans
   Richard Clamp
   Leopold Toetsch
   Dan Sugalski
   Mark Fowler
   Geoff Avery
   James Duncan
   Stephane Peyrard

As the place was very dark and at one point it was a coming and going 
of a lot of people, I may have missed one or more people.  If you are 
one of these people, I hope you understand: you were there and saw 
how organized things were  ;-)

The first part of the meeting was more of a general discussion, of 
which no minutes were kept.  Fortunately Rafael put up a blackboard 
and an agenda was made.  In the end it contained the following points:

- Project Management
    - CPAN
- Ponie
- New modules (?)
- Distributions
- COW on 5.10
- Open bugs
- 5.00504
- 5.6.2
- 5.8.1

Many questions were asked, and many did not get a definitive answer. 
If there is no answer to a question mentioned in these minutes, it 
means there either was no definitive answer, or no consensus was 
reache, or I missed it.  If it is the last case, please let us know 
what you think the answer was.

Initial discussion point was Ponie because Leo had to leave early.

Most of  Arthur's work is SV to PMC conversion, other work (mostly to 
be done by Rafael) is Perl opcode to Parrot opcode conversion.  Do we 
have to support B:: in Ponie?   General consensus seems to be: no. 
Leo says it's probably easy to do from Parrot.  The Devel:: modules 
may need work, and we can live with that.

Peep optimilization should become optional.  Cleanup of op.c to allow 
separation of optional optimizations is already part of the plan for 
5.10. Various other types of optimization were discussed, most of 
them related to current Perl internals.  Ponie will be able to do 
optimizations that IMCC will not be able to do, so Ponie should do 

Rafael explained his ideas about getting hints to get working, some 
of which would happen at compile time and some of them at runtime. 
Several types of annotation were discussed.

Why is a subroutine entry slow?  Why is a goto slow?  It seems that 
too many stacks are involved.

What about GLOB's?  Would you need them in Ponie?  Arthur thinks you 
need them because there can be references to GLOB's.  Maybe GLOB's 
could become a hash or an array internally, probably with a special 
"glob" PMC.

The only way to optimize register usage in Parrot is by using 
pragma's, or compile time directives.

What about metadata such as line numbers, is that going to be in Ponie?  Yes.

People that use B:: modules will need to get help to migrate to Ponie.

Will it be possible to run Ponie under mod_perl.  It's all about 
performance, so putting things in an API will probably slow down 
stuff.  It seems to make sense to force using the cleaner mod_perl 
2.X to be able to run Ponie.


Distriutions for 5.10 are dead. (Different sizes, different targets. 
Minimal Perl, Standard Perl, Full Perl, Perl for ISP's.)  Or are they?

What needs to be done?:
- determine what is needed for a minimal
- changes to the build system to allow for different distributions
- social issues, how to prevent confusion?

Mostly legwork, but it needs a lot of legwork.  Jos Boumans says 
he'll look into it, with help from Nicholas Clark.  Biggest problem 
are dependencies.  Maybe this can be solved with a lot of Bundles on 
CPAN, possibly dynamically generated ones as well.

There are 2 variations the small(est) distribution: one of which is 
effectively the Perl kernel..  The distribution mailing list 
( should become alive again.  Someone other than 
Hugo will be needed to pull this off as Hugo does not have time for 


Dual life modules should maybe be owned by a "PERL" CPAN ID, only one 
person would have control over this ID

For many modules you want to  be able to "automagically" download a 
specific version from CPAN for specific Perls.  A newer version of a 
module might not necessarily work on an old(er) Perl.  So when CPAN 
tells you there is a newer version, it may still not be a good idea 
to download.

We need better meta-data for modules on CPAN.  And possibly index by 
module, rather than by author.  There's a lot of information kept on 
modules on CPAN that you cannot get any before installing the module. 
That needs to be changed.

Hugo: will be the on 5.10.  He also mentioned 
that 5.8.10 will have Module::Build and Inline.

Andreas does not have time to do much work on PAUSE, but Autrijus has 
been starting to fix some of the problems (with TPF grants in some 
cases). More stuff will need to be done, and perhaps we can get 
further grants for Autrijus or someone else to do that.

What about different versions of modules that need different 
underlying libraries?

The problem is going to be getting worse with different versions of 
mod_perl, Perl5, Ponie, Perl6, Parrot, so a solution to this problem 
is going to be needed real soon.

Whatever gets done, it _should_ remain "automatic" for the user, so 
that CPAN just does "the right thing", depending on version of Perl, 
modules installed, OS, etc.

Many current problems could already be solved by adding an option 
when uploading a module to PAUSE to instruct PAUSE _not_ to index the 

We need someone to "own" this problem,. possibly with a fund from 
TPF.  Should be discussed at the CPAN meeting in October, probably 
before that also.  Also the feature of the "role" account (a role 
identity linked to a group of other PAUSE accounts, the intention 
being that PAUSE would report uploads as coming from the role 
account, but audit trail by the real underlying account) should be 

Stas volunteers to Jarkko to provide META.yml that will mark all 
dual-life CPAN modules bundled in the core as "private", so they 
won't be indexed by PAUSE.


The question is which COW?

COW should speed up several regex stuff, backreferences, and so on. 
There was a patch for that in 5.7.3, didn't make it to 5.8.0, and 
will not make it to 5.8.1 either.

There seems to be one place in source that copies scalars (before: 
sv_setsv(), now sv_setsv_flags() ).  Just for plain string scalars. 
This is where Nick's COW work was done.  (Nick was just going too 
fast for me to copy what was said)

COW on perlbench is not slower or faster, the results are inconclusive.

SpamAssassin seems to be a better benchmark, it does a lot of work. 
Spec::CPU seems to contain a lot of nice benchmarks.  Only within an 
interpreter , and uses IO::Stringy so that it is not IO-bound.

Another approach for COW with threads:  Replace the arena's with 
C-array's.  You allow bodies to be shared.  Copy only the array and 
mark everything as COW when starting a new thread.  This needs some 
type of 2nd type of refcount.  The COWcount goes to the body, the 
heads are not involved.  The number variables seem to be magic in 
that they don't have a body.

Leo said stuff to Arthur and Nick, about reusing string headers in 
COW in Parrot.

Arthur won't be able to continue to work on this new COW 
optimization, as he'll be working on Ponie.  He'll write up what he 
did so far and then Nick (or someone else) should continue with it.

Project management

Hugo is not happy with PerForce, is not open source and "normal" 
users can't sync.  Therefore it would be nice to move to Subversion.

According to Greg Stein, Subversion seems to be stable for at least 2 
years already..

Subversion however seesms to lack the capability of a 3way merge, or 
does it?.  But Arthur says it is stuill not stable as he got 

Rafael fears scalability problems with Subversion.  Parrot is using 
CVS, and Dan doesn't like it.

Arthur will be using Subversion for regulare updates of Perl in the 
future, so that might get the bugs out.  There's going to be a 
Subversion repository at

Tim: Ponie will be using Subversion and the results of that will tell us more.

Jarkko: read all of the CVS archives from

(OT: Project management via the modules mailing list) Autriijus Tang 
will be releasing an updated version of RT, based on work for the 
taiwanese governemt.we need more people on modules mailing list

The modules mailing list should probably feed into (a) RT, with 
functionality added that namespaces will get approved after X amount 
of time unless someone objects.  This to avoid the deafening silence 
that currently happens if no one is against allowing the namespace.

Open bugs

The following issues were mentioned:

There a lot of open bugs that aren't really bugs

All doc bugs have been assigned to Casey by Arthur

Unresponded-to bugs are the most emberrassing. Howver, there's about 
a manmonth work just responding to unresponded bugs.  Nick will try 
to close all of the unresponded bugs that aren't bugs.

There are bugs known to specific p5pers that aren't reported because 
they need to fix it themselves.  They should be reported nonetheless, 
to be able to keep track of them and in the small chance that there 
_will_ be someone else who will be able to fix the bug.

There are posisblities to smoking on obscure systems.  Someone should 
make use of them.

A reponse to the bug reporter is needed if there is no way for p5p to 
verify the problem.

A type of triage seems to be needed, some type of excalation system. 
In the future, only escalated bugs in RT will get sent to p5p.  If 
something is not reacted to in X days, it gets sent to p5p anyway.

We need a "database" of people knowledgeable on different systems / 
versions.  These will be contacted when a p5per feels the specific 
knowledge is needed to fix the bug.

There are many people that want to contribute in fixing bugs, we 
simply need to provide an easy way for these people to contribute in 
the "simple" legwork. Richard will lead the effort to get people to 
handle bugs.


Some work has been done.  Main goal is compiling under new GCC's.and 
nothing else.

Chip seems to be happy to let someone else apply patches for 5.00504

Nick will use Arthur's help to merge patches from other systems


It's more important to release 5.6.2 than Sarathy to be able to fix 
all his bugs

A lot of bugs in 5.6.X are fixed in the ActiveState release and not 
in the general release.  This needs to be fixed.

Sarathy may have the wrong impression that nobody cares about 5.6.X 
anymore.  Many people do!

Sarathy may be too busy to do this. Rafael says he'd be happy to give 
it a go as long as there are only small patches


Randomized hash keys will be the default in 5.8.1, even though the 
problems it might bring.  A good interface will need to be made for 
mod_perl.  Jarkko and Stas will figure this out.

Defined-or (//=) will not be default in 5.8.1, as it breaks some // 
idiom.  Patches will be on Merijn's CPAN directory to add //= to 
5.8.X.  Jarkko will put defined-or in the "upcoming features" in 

Arthur tested RC2 a lot and found only a few problem

Jarkko will ask on p5p to have all the people that told him of bugs 
on the YAPC::Europe, to tell it to him (or on p5p) again.

Last bits:

After this a discussion followed about creating a special (dummy) 
version of on CPAN, so that module authors of modules 
that can also be used < perl 5.6, can simply put "use warnings;" in 
their code and add a dependency to  When CPAN(PLUS) then 
installs a module in such an older Perl, the dependency will then 
simply get the dummy version from CPAN.  In the end it was decided to 
not do this, as all of the ramifications were not clear and it should 
maybe be left to the time when there is more meta-data available 
about modules on CPAN.

Since we managed to get the room for the meeting for free, TPF kindly 
invited us to use the money they had earmarked to pay for that to 
contribute towards the cost of the dinner instead.  Thank you.


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About