BEGIN perl-5.9
h...@crypt.org
delightful and beautiful. I was a little stranger, which at
my entrance into the world was saluted and surrounded with
innumerable joys. My knowledge was divine.
-- Thomas Traherne, 'Centuries of Meditations'
The perl-5.9 development track will be starting soon, leading
to interim perl-5.9.x development releases and an eventual
perl-5.10.0 stable release.
What do you want to see changed in the 5.9 track? I spoke at TPC
about the prejudices I'll be bringing to the table, and I include
a brief synopsis below; keep in mind however that few things will
be rejected out of hand, that each proposal will be examined on
its own merits. However, expect the bar to be higher for proposals
likely to contradict the intentions described.
Stability: I do not feel that perl is missing any major features.
Speed: We've been slowly haemorrhaging speed ever since 5.0, often
for good reasons (such as Unicode support), but we need to try to
claw cycles back anywhere we can.
Size: The .tar.gz distribution is now up to 11MB, which makes access
to perl far from free to anyone paying by the minute for comms.
Offering a choice of p5p-blessed distributions is one possible
approach to mitigating this, but I want to avoid further ballooning
of the standard distribution.
Cleanliness: The core includes some significant examples of arcane
and illegible code. That causes bugs, and makes it difficult to
fix bugs or add new features. It also helps to put off potential
new porters.
Convergence: It would be helpful to add features that can ease the
transition to perl6.
Some proposals I'm already inclined to accept include:
- /me to rewrite large parts of the regexp engine to clean up the
code, fix longstanding bugs, and permit more control (eg by turning
of selected optimisations).
- introduction of Module::Build to replace MakeMaker
- possible introduction of CPANPLUS to replace CPAN.pm
- creation of perl6ish.pm to allow introduction of perl6 features
(including deprecations)
Other proposals that need further discussion include:
- define multiple distributions of perl, ranging from microperl
to borgperl, with varying degrees of blessing from p5p
- rework Unicode support within the SV to allow byte and utf8
variants of the PV to coexist, and to cache selected character
positions
- consider changing from perforce to subversion for source code
control, probably aiming for a changeover around Spring 2003
Champions for particular proposals are also sought.
Ego moriturus vos saluto,
Hugo
Rafael Garcia-Suarez
Quoting h...@crypt.org:
> Convergence: It would be helpful to add features that can ease the
> transition to perl6.
I've been thinking about a Perl 5 to Perl 6 translator lately.
This implies to have a perl parser of some sort.
For the moment I'm experimenting with a kludge that parses the
output of `perl -cDTp` to mimic perl's LALR parser. (Those who
are interested can check out my journal at use.perl --
http://use.perl.org/~rafael/journal/ ) Another way to achieve
this is to patch perl to allow pluggable parser backends (this
functionality being enabled by a non-default Configure switch.)
This is a non-trivial design problem. (Or perhaps this is total
nonsense.)
Another approach is a module B::DeparseToPerl6. To have something
really useful, we'll need to improve the O and B backends, and
thus add more info into the internal optree. (And why not
B::imcc ?)
It's probable that other (smarter) solutions exist. I don't
know if somebody has already studied the problem.
--
Rafael Garcia-Suarez
"Mr Bloom ate with relish the inner organs of beasts and fowls."
-- J. Joyce, Ulysses
Horsley Tom
I don't know if I'll have time to work on this myself, but
the way all the ifdefs are setup for large file support
need to be changed if I'm ever going to get largefiles
to work on PowerMAX OS.
Perl currently attempts to use macros to make the "normal"
types and functions really point at 64 bit versions by
redefining the names.
On PowerMAX if you define _LARGEFILE64_SOURCE, all the
64 bit interfaces become visible in the header files,
but all the old interfaces are still there as well.
When perl attempt to redefine the old interfaces, everything
perl does conflicts with the old interfaces in the header
files and it all goes to heck :-).
I'd like to see perl change all its references to file
types and routines to be something like perl_maybe64_off_t
then there will be no name conflicts and everything
should build OK. (better ideas for the unique prefix
part of the name are welcome :-).
H.Merijn Brand
> Ego moriturus vos saluto,
Ut desint vires, tamen est laudanda voluntas!
-- Ovidius
Welcome, and good luck. I'll assist you wherever possible
> Hugo
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smo...@perl.org
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Abhijit Menon-Sen
>
> - consider changing from perforce to subversion for source code
> control, probably aiming for a changeover around Spring 2003
Why?
- ams
Graham Barr
> On Tue 30 Jul 2002 14:20, h...@crypt.org wrote:
> > Ego moriturus vos saluto,
>
> Ut desint vires, tamen est laudanda voluntas!
> -- Ovidius
>
> Welcome, and good luck. I'll assist you wherever possible
Or did you mean
Yes master.
-- Thomas Renfield (Dracular: Dead and loving it)
Graham.
H.Merijn Brand
<knipmes>
Ja meneer, goed meneer. U wenst?
</knipmes>
Arthur Bergman
On tisdag, juli 30, 2002, at 02:59 , Rafael Garcia-Suarez wrote:
> Another approach is a module B::DeparseToPerl6. To have something
> really useful, we'll need to improve the O and B backends, and
> thus add more info into the internal optree. (And why not
> B::imcc ?)
>
I think the first stop should be just to embed parrot in perl and run
the opcodes using that.
Arthur
h...@crypt.org
:(cc:ing Damian just in case he wants to comment)
:
:Quoting h...@crypt.org:
:> Convergence: It would be helpful to add features that can ease the
:> transition to perl6.
:
:I've been thinking about a Perl 5 to Perl 6 translator lately.
Sounds interesting, but just in case it wasn't clear, that wasn't
what I was talking about in the quoted fragment: I was talking
about ways to allow people to write perl5 code in a perl6 style.
:Another way to achieve
:this is to patch perl to allow pluggable parser backends (this
:functionality being enabled by a non-default Configure switch.)
That sounds like a big, big change.
:Another approach is a module B::DeparseToPerl6. To have something
:really useful, we'll need to improve the O and B backends, and
:thus add more info into the internal optree. (And why not
:B::imcc ?)
Better O&B modules would always be nice.
Hugo
h...@crypt.org
As mentioned, I class this as a proposal that needs discussion.
In principle, I've always been concerned about making perl development
dependent on a non-open-source application such as perforce: I would
prefer any fruit of our efforts that might involve improvements to the
revision control system we use to be able to benefit others for free,
and I don't like running on my own machine(s) any code for which I don't
have the sources (on principle, for security, and for scratching itches).
In practice, I'm already aware of one thing that no-one seems to know
how to do with perforce without changing the source code - I'd like
the Changes file and the .patch file to be updated automatically with
the correct details as a part of committing each change, and this
doesn't seem to be possible since the change number is not finalised
until the point of commit.
Before now, it seems to me the open-source revision control systems
available were a long way from providing the facilities we wanted,
and so I can understand and respect the decision at the time to go
for perforce even though I disagree with it. However, if and when
such a system does become available I think it merits a serious look,
and all other things being equal I feel that perl should prefer the
open-source project to the closed-source project.
Chip has expressed an interest in writing a converter from perforce
to subversion, and Greg Stein (one of the lead developers for subversion)
has also expressed support. Subversion has recently had an alpha release
(but has been self-hosted for some 9 months without problems), and
planned timescales for the project include a beta in a couple of months
and a 1.0 release shortly thereafter.
The suggested timescale is intended to allow myself and others time
to familiarise ourselves with perforce and subversion, and to consider
how and how well our existing processes would translate to subversion,
before making any final decision on this.
If we decide we should make an attempt at changing over, I would hope
to have a period of running the two systems in parallel before making
the final break.
Hugo
Chromatic
> Size: The .tar.gz distribution is now up to 11MB, which makes access to perl
> far from free to anyone paying by the minute for comms. Offering a choice of
> p5p-blessed distributions is one possible approach to mitigating this, but I
> want to avoid further ballooning of the standard distribution.
> Cleanliness: The core includes some significant examples of arcane and
> illegible code. That causes bugs, and makes it difficult to fix bugs or add
> new features. It also helps to put off potential new porters.
> Convergence: It would be helpful to add features that can ease the transition
> to perl6.
Given adequate test coverage (we're getting there), it's possible that some
judicious refactorings can accomplish some of all three. The cleaner the
standard libraries, the easier it will be to port them to Perl 6.
Of course, there's plenty of handwaving in there, and massive refactorings
(even with good coverage) can be pretty scary from a stability standpoint.
I'm also interested in Rafael's idea of Opcodes -> Parrot. Being able to
disable the optimizer would help.
I'll keep going with the tests, and don't mind working on some of the
bitrottingest modules.
-- c
Iain Truskett
> On Tue, 30 Jul 2002 05:20:55 -0700, Hugo wrote:
[snip 'Size', 'Cleanliness', 'Convergence']
> I'm also interested in Rafael's idea of Opcodes -> Parrot. Being able
> to disable the optimizer would help.
> I'll keep going with the tests, and don't mind working on some of the
> bitrottingest modules.
On a similar note, is there a collection of standard benchmarking tests
around somewhere? Since one of the aims is speed, it would be useful to
have such a thing. It could help to see if some of the refactoring,
cleaning and converging gives significant performance penalties or
improvements.
Of course, penalties shouldn't always get in the way of clean code.
cheers,
--
Iain 'Spoon' Truskett. <http://eh.org/~koschei/>
Tim Bunce
>
> In practice, I'm already aware of one thing that no-one seems to know
> how to do with perforce without changing the source code - I'd like
> the Changes file and the .patch file to be updated automatically with
> the correct details as a part of committing each change, and this
> doesn't seem to be possible since the change number is not finalised
> until the point of commit.
The review daemon (or some process that listens to emails the review daemon
sends) can edit the change notes into the Changes file and submit it.
(Of course it needs to ignore it's own changes to the Chnages file :)
Tim.
Tim Bunce
> (even with good coverage) can be pretty scary from a stability standpoint.
>
> I'm also interested in Rafael's idea of Opcodes -> Parrot.
Yes. I think there's value in exploring all of
Opcodes -> Parrot (ie B::ParrotIMCC)
Opcodes -> perl6 (ie B::DeparsePerl6)
perl5 -> perl6 (probably not needed if B::DeparsePerl6 works)
perl6 parsing perl5 modules
Of those Opcodes -> Parrot is obviously the only practical one
at the moment.
> Being able to disable the optimizer would help.
Yes. Seems like $^H (PL_hints) would be a natural place for that.
A command like option could set the default and a pragma could set
it per-scope.
Tim.
Rafael Garcia-Suarez
>
> The review daemon (or some process that listens to emails the review daemon
> sends) can edit the change notes into the Changes file and submit it.
You mean this one : http://www.perforce.com/perforce/loadsupp.html#daemon ?
It is the one that sends mails to perl5-changes ?
There's a chapter on Daemons in the p4 docs :
http://www.perforce.com/perforce/doc.021/manuals/p4sag/06_scripting.html#1049168
They say :
Daemons can be used for almost any task that needs to occur when
Perforce metadata has changed. Unlike triggers, which are used
primarily for submission validation, daemons can also be used to
write information (that is, submit files) to a depot.
Elizabeth Mattijsen
>h...@crypt.org wrote:
>>Speed: ...
>>Size: ...
>>Cleanliness: ...
>Just to make it clear : do we agree that pseudo-hashes and
>5005threads will be removed in a near future ? perldelta
>says that pseudo-hashes will be removed in 5.10, and that
>5005threads are unsupported and deprecated.
I agree... ;=)
And possibly I think the emphasis should be on reducing memory footprint
for threaded applications even more than on speed. I just filed a perlbug
report (which didn't show up here yet) showing that you basically cannot
use shared arrays in a mod_perl environment because they leak like hell...
And guess what you usually use for inter-thread pipeline communication... ;-(
Liz
Rafael Garcia-Suarez
Geoffrey Young
> Convergence: It would be helpful to add features that can ease the
> transition to perl6.
along this line, I'd like to suggest something that I've wanted for a while.
perldoc -f no says
"See the L</use> function, which C<no> is the opposite of."
but no() doesn't exactly do that - at least in the way one might expect:
$ perl -e 'no mod_perl 2.0'
mod_perl version 2 required--this is only version 1.2701 at -e line 1.
I think it would make transitions much easier to have no() DWIM, particularly things such as
use 5.6.0; # I use 'our'
no 6.0; # but this was coded for perl 5, not perl 6
no mod_perl 2.0; # likewise for mod_perl for Apache 1.3
I've looked into implementing this myself but my C is, well, lacking. however, I'd be
willing to do the scut work (tests and other whatnot) for anyone interesting in spending
the time...
--Geoff
h...@crypt.org
:h...@crypt.org wrote:
:> Speed: ...
:>
:> Size: ...
:>
:> Cleanliness: ...
:
:Just to make it clear : do we agree that pseudo-hashes and
:5005threads will be removed in a near future ?
Yes.
:perldelta says that pseudo-hashes will be removed in 5.10, and that
:5005threads are unsupported and deprecated.
Hugo
Elizabeth Mattijsen
Would hijacking UNIVERSAL::no make it possible to do this in Perl?
Liz
h...@crypt.org
: >
: > Convergence: It would be helpful to add features that can ease the
: > transition to perl6.
:
:along this line, I'd like to suggest something that I've wanted for a while.
:no 6.0; # but this was coded for perl 5, not perl 6
I'm not convinced about this: perl6's job is to know whether it is
looking at perl5 or perl6 code, and DTRT.
:no mod_perl 2.0; # likewise for mod_perl for Apache 1.3
I'd sort of hope that this could do the same.
Hugo
James G Smith
>Would hijacking UNIVERSAL::no make it possible to do this in Perl?
I had no luck doing so with `use' so I doubt it can be done with
`no'. It's something done at compile-time and Perl 5 doesn't have a
good way to mark a sub as needing to be executed immediately (ASAP,
etc., as can be done, e.g., in Forth).
--
James Smith <JGS...@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
Graham Barr
> >no mod_perl 2.0; # likewise for mod_perl for Apache 1.3
> >
> >I've looked into implementing this myself but my C is, well,
> >lacking. however, I'd be willing to do the scut work (tests and other
> >whatnot) for anyone interesting in spending the time...
>
> Would hijacking UNIVERSAL::no make it possible to do this in Perl?
No. use and no are handled directly by the parser. There is no
sub or op call use or no. These two constructs are converted
into an optree that looks identical to
BEGIN { require module; module->VERSION($version); module->import(@list) }
Where the VERSION call is only made if a version is specified.
import is unimport for no instead of use
import/unimport is not called if the list has an explicit () for
the import list
So you would either have to change the code to call a method other than
VERSION for no, or still call VERSION, but add an extra argument to
change the comparison that VERSION does
Graham.
Elizabeth Mattijsen
>Elizabeth Mattijsen <l...@dijkmat.nl> wrote:
> >Would hijacking UNIVERSAL::no make it possible to do this in Perl?
>I had no luck doing so with `use' so I doubt it can be done with
>`no'. It's something done at compile-time and Perl 5 doesn't have a
>good way to mark a sub as needing to be executed immediately (ASAP,
>etc., as can be done, e.g., in Forth).
Too bad. But I guess it makes sense because the first "parameter" of
C<use> and C<no> can be a number. No way is Perl going to think the "use"
or "no" is a class method. Not to mention "use" and "no" are handled
specifically by the parser...
Liz
Geoffrey Young
h...@crypt.org wrote:
> Geoffrey Young <ge...@modperlcookbook.org> wrote:
> : >
> : > Convergence: It would be helpful to add features that can ease the
> : > transition to perl6.
> :
> :along this line, I'd like to suggest something that I've wanted for a while.
> [...]
> :no 6.0; # but this was coded for perl 5, not perl 6
>
> I'm not convinced about this: perl6's job is to know whether it is
> looking at perl5 or perl6 code, and DTRT.
ok, now that you mention it, leon told me this a while ago.
however, there may be some legitimacy to this outside of perl6. use()
currently assumes that the highest numerical version is always best,
but we know this isn't always true in real life. a legitimate use
could also be
use 5.6;
no 5.8; # I haven't (yet) fixed the bugs in my code that 5.8 exposes
I guess I also view 'use $perlversion' and 'use $module $version' to
be kinda the same in principle.
> :no mod_perl 2.0; # likewise for mod_perl for Apache 1.3
>
> I'd sort of hope that this could do the same.
this would be particularly useful, especially since modules on CPAN
are more likely to make changes which aren't back compatible than perl.
of course, you could always check $] or $foo::VERSION, and we've
gotten along quite well without these features for some time, but... :)
anyway, thanks for listening - it seems there's been a bit of
discussion already, which was the idea.
--Geoff
Nicholas Clark
> Rafael Garcia-Suarez <raphel.gar...@hexaflux.com> wrote:
> :h...@crypt.org wrote:
> :> Speed: ...
> :Just to make it clear : do we agree that pseudo-hashes and
> :5005threads will be removed in a near future ?
>
> Yes.
IIRC Schwern estimated a 15% speedup for hashes from removing the pseudo-hash
code.
Do we have a champion to re-implement class.pm (or whatever it was that uses
pseudo hashes internally to provide its functionality) ?
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
Tony Cook
> Do we have a champion to re-implement class.pm (or whatever it was that uses
> pseudo hashes internally to provide its functionality) ?
Perhaps:
http://search.cpan.org/search?dist=Class-PseudoHash
could do the job.
--
Tony
Dave Mitchell
> On Wed, 31 Jul 2002, Nicholas Clark wrote:
>
> > Do we have a champion to re-implement class.pm (or whatever it was that uses
> > pseudo hashes internally to provide its functionality) ?
I presume you mean fields.pm ?
Failing any other keen volunteers, I guess I should, since I use fixed
hashes in production code.
> Perhaps:
>
> http://search.cpan.org/search?dist=Class-PseudoHash
>
> could do the job.
This looks rather like something slow and horrible for people who
*really* want the pseudo-hash semantics. For 'use fields' compile- and
run-time checking, I though we were going to use the 'readonly' features
of hashes that were added a few months ago?
--
"Emacs isn't a bad OS once you get used to it.
It just lacks a decent editor."
Benjamin Goldberg
>
> On Wed, Jul 31, 2002 at 07:08:48PM +0100, h...@crypt.org wrote:
> > Rafael Garcia-Suarez <raphel.gar...@hexaflux.com> wrote:
> > :Just to make it clear : do we agree that pseudo-hashes and
> > :5005threads will be removed in a near future ?
> >
> > Yes.
>
> IIRC Schwern estimated a 15% speedup for hashes from removing the
> pseudo-hash code.
>
> Do we have a champion to re-implement class.pm (or whatever it was
> that uses pseudo hashes internally to provide its functionality) ?
Psuedo-hashes are used by fields.pm, in fields::new and fields::phash.
--
tr/`4/ /d, print "@{[map --$| ? ucfirst lc : lc, split]},\n" for
pack 'u', pack 'H*', 'ab5cf4021bafd28972030972b00a218eb9720000';
Nicholas Clark
> On Wed, Jul 31, 2002 at 11:37:11AM +1000, Iain Truskett wrote:
> > On a similar note, is there a collection of standard benchmarking tests
> > around somewhere? Since one of the aims is speed, it would be useful to
> > have such a thing. It could help to see if some of the refactoring,
> > cleaning and converging gives significant performance penalties or
> > improvements.
> These are long since lost to a job change and much-reduced use of perl.
> I had asked for more such programs on p5p, and met with no response.
>
> What I learned from those three programs was that perlbench was not
> a good predictor of the performance of those three programs.
I tried using installman as a benchmarking tool. It's big, parses text,
uses real OO modules, spends most of its time in the CPU crunching rather
than being IO bound, and it's not been written in an attempt to exercise
particular features to generate benchmark figures.
Oh, and as a side effect you get the manpages installed, and see if it
picks up any errors in the POD.
<aol>
> In other words, doing this is a good idea, and I hope somebody succeeds
> at it.
</aol>
But we all seem to think that it's hard to do well and hence don't start at
trying to do it.
Nicholas Clark
moo...@acm.org
> around somewhere? Since one of the aims is speed, it would be useful to
> have such a thing. It could help to see if some of the refactoring,
> cleaning and converging gives significant performance penalties or
> improvements.
A few years ago, I tried to do this. I had three real-world
programs with real data that I used regularly:
INN 1.4's daily report (an awk script fed through a2p and then mangled)
and three days of data from my news server.
Jeremy Nixon's Cleanfeed 0.95, and 10K of random articles from the
same server.
Another program that groveled through accounting files consisting of
fixed-length binary records, pulling out one byte and printing a histogram
of the values of that byte.
These are long since lost to a job change and much-reduced use of perl.
I had asked for more such programs on p5p, and met with no response.
What I learned from those three programs was that perlbench was not
a good predictor of the performance of those three programs.
In other words, doing this is a good idea, and I hope somebody succeeds
at it.
--
Ed Mooring (moo...@acm.org)
Tels
Moin,
>On Wed, Jul 31, 2002 at 11:37:11AM +1000, Iain Truskett wrote:
>> On a similar note, is there a collection of standard benchmarking tests
>> around somewhere? Since one of the aims is speed, it would be useful to
>> have such a thing. It could help to see if some of the refactoring,
>> cleaning and converging gives significant performance penalties or
>> improvements.
http://bloodgate.com/perl/benchmarks.html (llok at BigBench) is aimed at
creating a better benchmarking framework.
The idea is to separate the benchmarking code from the frame around it
(just like Benchmark.pm) AND to be able to group benchmarks together AND to
have different versions benched against each other.
For the future, I always wanted to separate the benchmark creation from the
reporting, but never had the time. Maybe I restart to work on this.
(This would allow to store benchmarks in a database (flat file really) and
then redo only these that you know have changed, for instance the new
version. The report could then cover all the benchmarks done so far.
Currently everything is run completely again, which takes quite some
time...Another advantage would be the ability to have different reports
(ASCII, HTML, PNGs, etc) or with different formattings)
It uses Benchmark.pm with all it's problems, but at least it does work
somehow. ;-)
I only did definitions for BigInt etc, but it is easy to do some for other
constructs.
I hope this helps,
Tels
- --
perl -MMath::String -e 'print \
Math::String->from_number("215960156869840440586892398248"),"\n"'
http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPUlriHcLPEOTuEwVAQEUGAf/T7KSAGOo4zSFiQzzdzt9Usl1li5Zt/Jn
QtpRq47yTIn5J58WpJn92fx5g4xQsICAOhGEzOU7LPyCkhVA4D2olxsEQlh0gOD6
YBoJDuqxzkPapHYc7fnYXZzAZTZIhyRRMuLyf136AdCbEzUMw20PH650kgdbcfPV
jiZ/MSk8wDvYBKAsIJcHFw8yP5t5ajxJcnAl2Z60NLrJwLnIZicoPYZhFZDHjDXA
086aiBlSgN21mIBELzwRcQwsvWv+MuyHjJcZ6ArEzxCIIh1LlSaKB+HfnEdmd+By
kZQaM/bdMI7CERg8E34CyeXPt0Sd9eCHMIfclUb06j8KTX5WBJgH4Q==
=r1PJ
-----END PGP SIGNATURE-----
Tels
Moin,
On 01-Aug-02 Tels carved into stone:
> -----BEGIN PGP SIGNED MESSAGE-----
Yes, I know to reply to myself is lame, but I am so excited:
:~/perl/math/BigBench-0.07> ./bb --code='$c->new("123")**45;' --tight
BigBench v0.08 (c) Copyright by Tels 2001. Have fun!
Thu Aug 1 19:17:08 2002 Reading templates from 'v1.60/'...done.
Got 5 templates.
Thu Aug 1 19:17:08 2002 Using code $c->new("123")**45;
Got 1 op in 1 group.
Each op will run for at least 2 seconds.
Results are scaled by factor 1 and rounded to 3 digits.
Results will be rounded to integer.
The benchmark will run for approximately 15 seconds.
[snip]
Thu Aug 1 19:17:23 2002 Numbers are absolute ops/s, scaled by factor 1.
| v0.01 v1.39 v1.45 v1.59 v1.60
--------+-------------------------------
bb | 399 198 207 1220 1160
bb: | 399 198 207 1220 1160
........|...............................
Thu Aug 1 19:17:23 2002 All done. Enjoy!
Oh, see, it even has a -e equivalent - I completely forgot this ;)
(Of course, it should set --terse when doing --code..)
The current version on my disk is v0.09 which I never got round to publish.
Here is the help:
BigBench v0.09 (c) Copyright by Tels 2001-2002. Have fun!
Usage : ./bb [options]
Options: --help print this screen and exit
--accuracy=digits round results to so many digits
--base=number print relative summary based on number
--code=sourcecode bench code snippet and ignore definitions
--definitons=file from where to read benchmark definitions
--duration=seconds run each op for at least this time
--nosummary don't print summary
--nointeger don't round results to integer
--nounlink don't unlink temporary files (for debug)
--path=libpath path to libraries used by templates
--runs=number run benchmark more than once (see --take)
--simulate=sr simulate results by using srand(sr)
--skew=factor scale reported numbers by factor
--take=run take lowest|average|highest|last
--templates=path path to templates to be used
--terse terse summary (unless --nosummary)
--tight more tight summary (smaller spacing)
Options may be abbreviated, their case does not matter.
Examples: ./bb --def=math.def --terse --skew=2.1 # better printable?
./bb --def=str.def --inc=math --duration=5 # really fine-grained
./bb --def=some.def --nosummary # detailed
./bb --def=some.def --terse --base=100 # simulate perlbench
./bb --code='"ababba" =~ /a+/;' # only this
./bb --runs=2 --take=last # cache, then bench
Anybody interested drop me a note and I will polish it up and publish it.
Cheer,
Tels
- --
perl -MMath::String -e 'print \
Math::String->from_number("215960156869840440586892398248"),"\n"'
http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPUlvMXcLPEOTuEwVAQEHCwf+Ii3zz2ITXRtV2lz2NLC1TpOAh6vBDLzp
S6FjsgT1aqT/j2dWBfJ/Xe1FCsZY1lNSx6NYgZhTgdZ0eK/VS/OV31MgQHEOJLZA
umakNe13Z9OfQ19ZS9E0m/+ICkgdTa1L9KVzOga/ae7TYcTlg3EeLjWNPBb4303e
BRP8qbrTcDyi/yS6KCqOcu7+KlaQOTQTyoo6sScaR4BIxxcpdhko1TZdHHgUR2Fk
Y7s9b1/mDzKO+tiFfQJXvidOFmIkvDGMmKLCCNwXK7WTtew4n6mVUx1Q74BoOXQW
nVfCRhkWjE1PDGvgj3xCSQq2vFkGeH8MQkYNuDjQiwbhVGdEqLMHfA==
=GkQy
-----END PGP SIGNATURE-----
Michael G Schwern
> IIRC Schwern estimated a 15% speedup for hashes from removing the pseudo-hash
> code.
Which was on PowerPC, which always seems to come out differently than x86.
I'll have an updated "rusty knife" patch for eliminating psuedohashes
shortly.
> Do we have a champion to re-implement class.pm (or whatever it was that uses
> pseudo hashes internally to provide its functionality) ?
fields.pm and base.pm. I'll do it. I already maintain the CPAN versions
and I know the restricted hash interface well. I think most of the fields
and base semantics can be done with restricted hashes, though Damian pointed
out key inheritance may be troublesome. There was also some mumbling about
a new version of Tie::SecureHash.
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Don't ask me lady, I live in beer.
Dave Mitchell
Randal L. Schwartz
Tim> perl5 -> perl6 (probably not needed if B::DeparsePerl6 works)
Unless perl5's parse tree is also preserving all comments, I think a
perl5 to perl6 source-to-source translator *does* have merit, in that
we can at least approximate the comment and POD locations and carry
them through.
This would make migration a slightly sweeter sour pill to swallow.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Elizabeth Mattijsen
> >>>>> "Tim" == Tim Bunce <Tim....@pobox.com> writes:
>Tim> perl5 -> perl6 (probably not needed if B::DeparsePerl6 works)
>Unless perl5's parse tree is also preserving all comments, I think a
>perl5 to perl6 source-to-source translator *does* have merit, in that
>we can at least approximate the comment and POD locations and carry
>them through.
I don't think Perl5's parse tree preserves comments. However, maybe this
could be fixed by having a special option with which the Perl5 parser
_would_ include comments as a special noop opcode. As well as the contents
of the DATA handle also (if nothing similar like that is going to be in
Perl6). At least then you wouldn't have to rebuild the Perl5 parser from
scratch...
Of course, normally you would only use this option when you're going to
migrate.
>This would make migration a slightly sweeter sour pill to swallow.
I agree a migration should leave comments and POD intact...
Liz
Rafael Garcia-Suarez
> At 03:19 PM 8/3/02 -0700, Randal L. Schwartz wrote:
> > >>>>> "Tim" == Tim Bunce <Tim....@pobox.com> writes:
> >Tim> perl5 -> perl6 (probably not needed if B::DeparsePerl6 works)
> >Unless perl5's parse tree is also preserving all comments, I think a
> >perl5 to perl6 source-to-source translator *does* have merit, in that
> >we can at least approximate the comment and POD locations and carry
> >them through.
>
> I don't think Perl5's parse tree preserves comments. However, maybe this
> could be fixed by having a special option with which the Perl5 parser
> _would_ include comments as a special noop opcode.
The Perl 5 parser has no knowledge at all about what's in the source file.
The tokenizer knows, but it doesn't construct the optree -- it only constructs
individual ops. And currently it's not clear where to put noop-comments ops
in the optree so they get deparsed at the right place. It's perhaps
better to keep the comments and pods somewhere in a table indexed by
line number. (except, of course, the comments in //x regexps that
are a special, simpler case.)
For the moment I see 4 possible approaches for the translator :
(warning : random ramblings follow)
* B::DeparsePerl6. With this approach we'll need to store a lot more info
in the optree than currently is. This is necessary to 1/ deparse correctly
all pragmas and BEGIN blocks 2/ get comments and pods 3/ preserve line
numbers (and don't try to reindent everything as B::Deparse currently does.)
This implies some amount of changes in the core. (NB. B::Deparse
knows how to get __DATA__, at least in simple cases.)
* A new 'use parser' pragma to allow pluggable parser backends (basically
a parser backend would be a bunch of callbacks to be called every time
yacc reduces.) Requires changes in the core, but not that much. Can be
disabled at perl's build-time.
Advantage : can be lexically scoped.
Drawbacks : writing a parser plugin will be non-trivial as it will be
needed to understand when and why the tokenizer generates fake tokens
or permutes tokens. Also, a special kludge will be needed to get PODs and
comments right.
* A evil hack (tm) : have a standalone program that parses the output of
"perl -cDTp" (debug traces of the tokenizer and of the parser.)
Needs no changes in the core (except perhaps in debug traces.)
You need a -DDEBUGGING perl to get it work. You can get the comments
but not the pods (currently.) Same drawbacks as with the 'use parser'
pragma. I'm currently working on this as a proof-of-concept, which,
practically, means that I'm digging in toke.c without writing a single
line of code.
* Rebuild a Perl 5 parser from scratch :
> At least then you wouldn't have to rebuild the Perl5 parser from
> scratch...
You can't parse Perl (in the general case) without having a perl interpreter,
because you need to execute BEGIN blocks. Rebuilding a Perl 5 parser
would be difficult and the resulting parser will not work in all cases.
And I don't even want to think about source filters...
(end of random ramblings...)
Andy Lester
>
> I agree a migration should leave comments and POD intact...
It's not even a question. I'm trying to imagine the circumstances under
which any user would run a program that ate their comments.
Perhaps B::Generate can still be useful. Maybe the foo.pl opcodes
and foo.p6 Parrot opcodes can be verified against each other after the
source-level conversion takes place? I know that I'd feel better about
it as a user.
xoxo,
Andy
--
'Andy Lester an...@petdance.com
Programmer/author petdance.com
Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&)
[unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
pdca...@bofh.org.uk
> >>>>> "Tim" == Tim Bunce <Tim....@pobox.com> writes:
>
> Tim> perl5 -> perl6 (probably not needed if B::DeparsePerl6 works)
>
> Unless perl5's parse tree is also preserving all comments, I think a
> perl5 to perl6 source-to-source translator *does* have merit, in that
> we can at least approximate the comment and POD locations and carry
> them through.
How much work would be involved in generating an 'unoptimized, and
instrumented, with comments in "magic" no ops' optree?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
pdca...@bofh.org.uk
> At 03:19 PM 8/3/02 -0700, Randal L. Schwartz wrote:
> > >>>>> "Tim" == Tim Bunce <Tim....@pobox.com> writes:
> >Tim> perl5 -> perl6 (probably not needed if B::DeparsePerl6
> >Tim> works)
> >Unless perl5's parse tree is also preserving all comments, I think
> >a perl5 to perl6 source-to-source translator *does* have merit, in
> >that we can at least approximate the comment and POD locations and
> >carry them through.
>
> I don't think Perl5's parse tree preserves comments. However, maybe
> this could be fixed by having a special option with which the Perl5
> parser _would_ include comments as a special noop opcode. As well
> as the contents of the DATA handle also (if nothing similar like
> that is going to be in Perl6). At least then you wouldn't have to
> rebuild the Perl5 parser from scratch...
>
>
> Of course, normally you would only use this option when you're going
> to migrate.
It'd be great for things like my refactoring browser project too. In
fact, it'd be utterly marvellous.
Arthur Bergman
On söndag, augusti 4, 2002, at 06:48 , pdca...@bofh.org.uk wrote:
>
> How much work would be involved in generating an 'unoptimized, and
> instrumented, with comments in "magic" no ops' optree?
>
>
I think it would be easier just to convert the source code then.
Arthur
Rafael Garcia-Suarez
> mer...@stonehenge.com (Randal L. Schwartz) writes:
> >
> > Unless perl5's parse tree is also preserving all comments, I think a
> > perl5 to perl6 source-to-source translator *does* have merit, in that
> > we can at least approximate the comment and POD locations and carry
> > them through.
>
> How much work would be involved in generating an 'unoptimized, and
> instrumented, with comments in "magic" no ops' optree?
I imagine that the last comment seen by the lexer can be optionally stored
in COPs (control flow ops) along the cop_line. That's an approximation,
but better than nothing. This may work for pods also.
Nick Ing-Simmons
>At 03:19 PM 8/3/02 -0700, Randal L. Schwartz wrote:
>> >>>>> "Tim" == Tim Bunce <Tim....@pobox.com> writes:
>>Tim> perl5 -> perl6 (probably not needed if B::DeparsePerl6 works)
>>Unless perl5's parse tree is also preserving all comments, I think a
>>perl5 to perl6 source-to-source translator *does* have merit, in that
>>we can at least approximate the comment and POD locations and carry
>>them through.
>
>I don't think Perl5's parse tree preserves comments. However, maybe this
>could be fixed by having a special option with which the Perl5 parser
>_would_ include comments as a special noop opcode. As well as the contents
>of the DATA handle also (if nothing similar like that is going to be in
>Perl6). At least then you wouldn't have to rebuild the Perl5 parser from
>scratch...
In case someone wants to try this - a word from someone that has
tried something similar (for Verilog <-> VHDL translation in hardware
design world). Do NOT try and do it in the _parser_ it makes a mess of
any LALR(1) type look-ahead when you have to look "past" comments.
It can be done in lexer if lexer keeps "pending comments" and
attaches them to the next item. This will of course be messier
in perl (# may not be a comment in s#foo#bar#).
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Nick Ing-Simmons
>
>For the moment I see 4 possible approaches for the translator :
>(warning : random ramblings follow)
>
>* B::DeparsePerl6. With this approach we'll need to store a lot more info
> in the optree than currently is. This is necessary to 1/ deparse correctly
> all pragmas and BEGIN blocks 2/ get comments and pods 3/ preserve line
> numbers (and don't try to reindent everything as B::Deparse currently does.)
> This implies some amount of changes in the core. (NB. B::Deparse
> knows how to get __DATA__, at least in simple cases.)
Given the info on line numbers a separate pass can go looking for pod
and comments and corelate them with the line numbers in the ops.
Rafael Garcia-Suarez
> Rafael Garcia-Suarez <rgarci...@free.fr> writes:
> >
> >* B::DeparsePerl6. With this approach we'll need to store a lot more info
> > in the optree than currently is. This is necessary to 1/ deparse correctly
> > all pragmas and BEGIN blocks 2/ get comments and pods 3/ preserve line
> > numbers (and don't try to reindent everything as B::Deparse currently does.)
> > This implies some amount of changes in the core. (NB. B::Deparse
> > knows how to get __DATA__, at least in simple cases.)
>
> Given the info on line numbers a separate pass can go looking for pod
> and comments and corelate them with the line numbers in the ops.
Currently B:: modules don't have access to the source.
And it may be difficult to extract a comment from a line without help
from the lexer :
s#foo#bar\#baz#; # comment
That's why I think it may be easier to have the lexer store the last
comment(s) somewhere and store them in COPs.
h...@crypt.org
:On Tue, 30 Jul 2002 05:20:55 -0700, hv wrote:
:> Size: [...]
:> Cleanliness: [...]
:> Convergence: [...]
:Given adequate test coverage (we're getting there), it's possible that some
:judicious refactorings can accomplish some of all three.
Yup. Suggestions and patches welcomed.
:Of course, there's plenty of handwaving in there, and massive refactorings
:(even with good coverage) can be pretty scary from a stability standpoint.
Now's the time - it'll be at least a year and maybe closer to two before
5.9 becomes 5.10. We can always revert if something doesn't work out.
:I'm also interested in Rafael's idea of Opcodes -> Parrot. Being able to
:disable the optimizer would help.
Yup, we need to clean up op.c a bit first - the optimisations are mixed in
with a lot of other mandatory bits, and cannot easily be separated out at
the moment. We'd probably also need to define it in terms of different
levels of optimisation - 'no optimisations' is a real heavy hammer, but
it doesn't need to be the only one we provide.
:I'll keep going with the tests, and don't mind working on some of the
:bitrottingest modules.
Cool. Do let us know when you're going to delve deeply into some stinking
pool of the morass, to avoid duplication of effort if nothing else.
Cheers,
Hugo