Front page | perl.perl5.porters |
Postings from July 2003
*VERSION 2* Notes p5p BOF
From: Elizabeth Mattijsen
July 29, 2003 03:14
*VERSION 2* Notes p5p BOF
Message ID: firstname.lastname@example.org
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
Elaine Hietaniemi Ashton
H Merijn Brand
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
- New modules (?)
- COW on 5.10
- Open bugs
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
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
(email@example.com) 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
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: CPANPLUS.pm will be the CPAN.pm 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
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.
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
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 perl.org.
Tim: Ponie will be using Subversion and the results of that will tell us more.
Jarkko: read all of the CVS archives from perl.org
(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.
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
Some work has been done. Main goal is compiling under new GCC's.and
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.
After this a discussion followed about creating a special (dummy)
version of warnings.pm 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 warnings.pm. 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.
*VERSION 2* Notes p5p BOF
by Elizabeth Mattijsen