Re: parrotbug working...
Robert Spier wrote: The mails are indeed sent to parrotbug, parrotstatus-ok and parrotstatus-nok (at parrotcode.org) for resp. bug reports, ok reports or nok reports. And since I don't think those addresses are set up... Not yet. I'm nudging Ask regularly about this. But what should those addresses do when receiving a message? - parrotbug: should open a RT ticket? - status-ok: ? - status-nok: should open a RT ticket? Other things? Anyone (Robert? :-) ) knows what [EMAIL PROTECTED] do? Jerome -- [EMAIL PROTECTED]
[perl #27414] tests failing on powerpc JIT
# New Ticket Created by Arcady Goldmints # Please include the string: [perl #27414] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27414 A few tests are failing with JIT on powerpc linux, even though everything works perfectly fine without JIT. The tests in question are t/op/integer.t 1 and 33, and t/op/stacks.t 1-5. These seem to have in common the fact that they use all of the integer registers I0-I31, and this causes parrot -j to segfault. Arcady Summary of my parrot 0.1.0 configuration: configdate='Thu Mar 4 12:15:25 2004' Platform: osname=linux, archname=powerpc-linux-thread-multi jitcapable=1, jitarchname=ppc-linux, jitosname=LINUX, jitcpuarch=ppc execcapable=1 perl=/usr/bin/perl Compiler: cc='cc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN +-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-ldl -lm -lpthread -lcrypt' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=4321, nv=double, numvalsize=8, doublesize=8
[perl #27418] object __init bug: end op does not work
# New Ticket Created by Jens Rieks # Please include the string: [perl #27418] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27418 Hi, the attached pasm code prints : A : error! instead of only A as expected. jens newclass P0, Foo newsub P0, .Sub, _end store_global Foo, __init, P0 find_type I0, Foo new P0, I0 print error!\n end _end: print A\n end
Re: parrotbug working...
Jerome Quelin wrote in perl.perl6.internals : But what should those addresses do when receiving a message? - parrotbug: should open a RT ticket? - status-ok: ? - status-nok: should open a RT ticket? Excuse me from stepping in, but I don't see why three adresses are necessary. From my (limited) knowledge of RT, I thing that the parrot bug address could create a ticket in the parrot queue, or add the mail body to the appropriate ticket if the subject contains [perl #X] -- then, it could close the ticket automatically if the subject matches an OK report.
Re: [perl #27418] object __init bug: end op does not work
Jens Rieks [EMAIL PROTECTED] wrote: the attached pasm code prints : A : error! instead of only A as expected. The __init code is run in its own run loop. This may (as in your example) have an end opcode, which is just the same as invoke P1, i.e. a return from the __init subroutine. So this is a feature. jens leo
Re: [perl #27391] parrot -t crash
Jens Rieks [EMAIL PROTECTED] wrote: Hi, The following code crashes parrot if run with -t (trace). It seems to be due to an unused .param, see line marked with XXX. The unused param doesn't harm. The problem is memory corruption very likely due to the PIO_printf code inside trace.c (or string code called from that). The extra line just lets more of these functions be called. $ parrot -tG crash.imc runs fine. jens leo
Re: [perl #27391] parrot -t crash
Jens Rieks [EMAIL PROTECTED] wrote: Hi, The following code crashes parrot if run with -t (trace). Some more notes: - it happens with or w/o ARENA_DOD_FLAGS - it happens with the copying GC or with --gc=libc - it does not happen with DOD/GC disabled - I did not find any breakage in e.g. examples/benchmarks/*.pasm - it could be related to objects - currently only your crash.imc and oo1.pasm are failing The segfault is normally related to the string_header pool: at src/smallobject.c:270 270 pool-free_list = *(void **)ptr; The corrupted free_list looks like these: (gdb) p ptr $8 = (void *) 0x3200 (gdb) p ptr $9 = (void *) 0x3300 (gdb) p ptr $11 = (void *) 0x3d303100 Could be some numbers from the trace. leo
Re: [DOCS] Documentation tools
On Mar 4, 2004, at 7:50 PM, Robert Spier wrote: IMHO, the releases better include everything necessary to build the application, within reason. Consistency and simplicity counts for a lot. Why create headaches we don't need? within reason. Thats where we're way off right now. Let's keep a bit of perspective here. The non-Parrot:: contents of lib accounts for only 4.6% of the non-ICU content (and only 1.5% if you count ICU in the total size). It's difficult to see that as unreasonable, or as bloat. JEff
Re: [perl #27414] tests failing on powerpc JIT
On Mar 4, 2004, at 2:48 PM, Arcady Goldmints (via RT) wrote: A few tests are failing with JIT on powerpc linux, even though everything works perfectly fine without JIT. The tests in question are t/op/integer.t 1 and 33, and t/op/stacks.t 1-5. These seem to have in common the fact that they use all of the integer registers I0-I31, and this causes parrot -j to segfault. This is probably because ppc linux uses slightly different calling conventions that Mac OS X, and I believe reserves r2 as a TOC pointer, and jit is probably stomping on that. In jit/ppc/jit_emit.h, try setting: #define INT_REGISTERS_TO_MAP 23 and taking r2 out of the intval_map[INT_REGISTERS_TO_MAP] section (both of these are near the bottom of the file). This is already being done for AIX (but defining PARROT_EXEC_OS_AIX would probably cause more problems, so try making just these two changes, and see if it works then). JEff
cygwin
Did Somebody try to assemble parrot on CygWin? I tried... perl configure.pl - ok make - and error ocured: gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lcrypt blib/lib/libparrot.a(io_unix.o)(.text+0x8f7): In function `PIO_sockaddr_in': /inst/parrot/io/io_unix.c:626: undefined reference to `_inet_pton' collect2: ld returned 1 exit status make: *** [parrot.exe] Error 1 What is the problem? With best wishes, Dmitry Nikolayev
Freezing strings?
I figure it's about time for Parrot programs to be able to look at Parrot's configuration, so I'm trying to implement a library equivalent to Parrot::Config. My current thoughts on implementation involve three elements: 1. A Configure step that writes and executes a Parrot program. Said program builds up a PerlHash of options and freezes it to disk. 2. Said frozen hash, stored in (e.g.) Flibrary/config.fpmc. 3. A small chunk of code in (e.g.) Flibrary/config.imc which reads the frozen hash from disk and re-creates it. This would guarantee that you're seeing the configuration info for the current system, even if you moved a bytecode file with config.imc compiled into it. Unfortunately, I'm being stopped before I can even start. The following code prints foo= on my Debian server: new P0, .PerlString set P0, foo freeze S0, P0 thaw P1, S0 print P0 print = print P1 print \n end If I freeze a hash, the keys are preserved, but string values are lost. Integer values are kept; float values all come out as 0.0 (plus or minus about eight zeros). Ft/pmc/freeze.t doesn't test freezing and thawing strings or floats. Is this because the functionality hasn't been implemented yet? A cursory examination of Fsrc/pmc_freeze.c suggests that it should be working, but I may well be missing something. If it's just some busywork, such as copying some code into PerlString and tweaking it, I can probably do it, but I've been out of the loop for a while, so anything particularly involved is likely beyond me. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: cygwin
Dmitry Nikolayev wrote: Did Somebody try to assemble parrot on CygWin? I tried... perl configure.pl - ok You'll need to use: perl Configure.pl --define=inet_aton make - and error ocured: gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lcrypt blib/lib/libparrot.a(io_unix.o)(.text+0x8f7): In function `PIO_sockaddr_in': /inst/parrot/io/io_unix.c:626: undefined reference to `_inet_pton' collect2: ld returned 1 exit status make: *** [parrot.exe] Error 1 What is the problem? With best wishes, Dmitry Nikolayev
Compile-time undefined sub detection
On the basis of what is known so far, will p6 be able to detect undefined subs at compile time? Regards, Nigel.
Re: Compile-time undefined sub detection
On Thu, Mar 04, 2004 at 11:04:38PM +, Nigel Sandever wrote: : On the basis of what is known so far, will p6 be able to detect : undefined subs at compile time? In theory, yes, if you ask it to check in a CHECK block, and if you're willing for the check to assume that no eval or INIT block is going to supply the missing sub before it's actually called, and that no run-time code is going to alias the sub into one of your namespaces where it'll be visible to call, and that no AUTOLOAD in scope will be willing to emulate it. (But then, all that's true of Perl 5 right now as well...) Larry
Re: Compile-time undefined sub detection
Larry Wall wrote in perl.perl6.language : In theory, yes, if you ask it to check in a CHECK block, and if you're willing for the check to assume that no eval or INIT block is going to supply the missing sub before it's actually called, and that no run-time code is going to alias the sub into one of your namespaces where it'll be visible to call, and that no AUTOLOAD in scope will be willing to emulate it. (But then, all that's true of Perl 5 right now as well...) While we're at it. Is there some precise definition of the CHECK/INIT blocks for perl 6 right now ? In perl 5 those blocks are executed at the transition between the compilation and the execution phase *of the main program*. This is convenient for some purposes (the O and B::* modules) and inconvient for others (Attribute::Handlers, etc. etc.). It's not feasible to modify this for Backwards Compatibility Reasons; how will Perl 6 handle this ? is there going to be a CHECK-by-compilation-unit kind of block ?
Re: Compile-time undefined sub detection
On Fri, Mar 05, 2004 at 01:57:40PM -, Rafael Garcia-Suarez wrote:
: While we're at it. Is there some precise definition of the CHECK/INIT
: blocks for perl 6 right now ?
Yes, the same precise definition as anything else we haven't defined yet:
That works exactly the same as in Perl 5, until we change our minds. :-)
: In perl 5 those blocks are executed at the
: transition between the compilation and the execution phase *of the main
: program*. This is convenient for some purposes (the O and B::* modules)
: and inconvient for others (Attribute::Handlers, etc. etc.).
Hmm, well, I think it's a problem with Attribute::Handlers only because
that interface binds too late by default. Perl 6 traits will run at
BEGIN time by default. (Though you can define actions at trait time
that don't run till a later phase.) Can you elaborate on the etc. etc.?
: It's not
: feasible to modify this for Backwards Compatibility Reasons; how will
: Perl 6 handle this ? is there going to be a CHECK-by-compilation-unit
: kind of block ?
The link phase is still controlled by the main compilation pulling
in other modules, so CHECK still has the same semantics for the main
program, at least. And for consistency (especially with Perl 5),
a CHECK block from a separately compiled module probably should wait
till end of link time to run. Particularly since we have modules
that specifically create a CHECK knowing it runs at the end of the
main compilation.
So if we divide the CHECK notion up, you are correct that it's the
end-of-the-compilation-unit check that needs a new name. That might
be convenient, though redundant, since you can always run something at
the end of the compilation by putting a BEGIN block down at the bottom.
That BEGIN wouldn't know that it's the last thing, and can't guarantee
that it's the last thing if someone inserts more code after it, but
that doesn't stop you from putting stuff into the BEGIN block that
knows it's the last thing, and putting a comment afterwards saying
# Put no code here. Put it before the preceding BEGIN
On the other hand, there are things that the compiler probably has
to think about at the end of the compilation unit, and you might want
to do something after that. For example, given the way that subs
can forward-ref a declaration they haven't seen yet, we might want
to figure out at that time what signature to apply to a mysterious
call like:
foo(@bar, @baz)
So your final BEGIN would be ignorant of that decision unless it had
some way to force it. But if we're going to provide an interface to
let BEGIN tell the compiler to finish up, that's just as complicated
as providing a different kind of block that lets the compiler finish
up explicitly.
So I guess the question boils down to, what shall we name it?
UNBEGIN
POSTCOMP
PRELINK
COMPCHECK
UNITCHECK
Actually, I could see an argument for REDUCE, which runs after the
current block is reduced in the grammar. Which, if put at file-scope
level, comes out to running after the file is reduced, kinda sorta,
though to get the right semantics we'd have to consider not just the
grammatical reduction, but all the action routines triggered as part
of the reduction.
So that might also give us a way to capture control after a sub is
compiled, for instance. Or at least, its closure block... Hmm.
BEGIN blocks work fine for that, probably better, since the reduction
of the entire sub can happen, not just the block associated with
the sub. So nevermind about REDUCE. It seems to be an ill-formed
notion, since multiple reductions happen before your entire sub is
defined.
Which takes us back to something like UNITCHECK. Let's see:
my @x will unitcheck { .stuff() };
I guess that works as a verb.
So unless someone talks me out of it, we now have
my @x will begin {...} # at BEGIN time
my @x will unitcheck {...} # at UNITCHECK time
my @x will check {...} # at CHECK time
my @x will init {...} # at INIT time
my @x will pre {...}# at PRE time (return boolean for DBC)
my @x will enter {...} # at ENTER time (block entry)
my @x will leave {...} # at LEAVE time (block exit)
my @x will post {...} # at POST time (return boolean for DBC)
my @x will end {...}# at END time
state @x will first {...} # at FIRST time (first time through)
has @.x will build {...}# at BUILD time (object init time)
But most of you don't officially know about that last one yet.
Few more days... :-)
Larry
Re: Compile-time undefined sub detection
Larry Wall wrote in perl.perl6.language :
: In perl 5 those blocks are executed at the
: transition between the compilation and the execution phase *of the main
: program*. This is convenient for some purposes (the O and B::* modules)
: and inconvient for others (Attribute::Handlers, etc. etc.).
Hmm, well, I think it's a problem with Attribute::Handlers only because
that interface binds too late by default. Perl 6 traits will run at
BEGIN time by default. (Though you can define actions at trait time
that don't run till a later phase.) Can you elaborate on the etc. etc.?
Of course :) the main problem is not that CHECK blocks are executed
late (just at the end of the compilation phase); it's that they're
executed too early, notably in some persistent environment, notably
mod_perl (or mod_parrot in the future.) When you have a virtual machine,
you'll end up including modules at run time, because the main
compilation phase becomes less important. Thus CHECK blocks become
worthless, code-reusability-wise.
The link phase is still controlled by the main compilation pulling
in other modules, so CHECK still has the same semantics for the main
program, at least. And for consistency (especially with Perl 5),
a CHECK block from a separately compiled module probably should wait
till end of link time to run. Particularly since we have modules
that specifically create a CHECK knowing it runs at the end of the
main compilation.
But, as I was saying, modules have no control on what the end of the
compilation is; notably, they've no control on whether it's still
finished.
my @x will unitcheck {...}# at UNITCHECK time
your next mission is now to put something like this in Perl 5...
Re: Compile-time undefined sub detection
On Fri, Mar 05, 2004 at 06:45:58PM -, Rafael Garcia-Suarez wrote: : Of course :) the main problem is not that CHECK blocks are executed : late (just at the end of the compilation phase); it's that they're : executed too early, notably in some persistent environment, notably : mod_perl (or mod_parrot in the future.) When you have a virtual machine, : you'll end up including modules at run time, because the main : compilation phase becomes less important. Thus CHECK blocks become : worthless, code-reusability-wise. Possibly a CHECK block that is compiled after end of main compilation should translate itself to a UNITCHECK. But maybe it should be an error. But it's also possible that CHECK should mean unit check, and there should be an explicit MAINCHECK for delegating checks to the main compilation. In that case, only in the main compilation would CHECK and MAINCHECK mean the same thing. (And since MAINCHECK is explicitly requesting a check at the end of main, a late MAINCHECK should probably be considered an error. (But by that argument, a late CHECK should probably fail under the current naming scheme.)) Anybody got opinions on the naming of these beasts? Certainly *not* renaming CHECK is more compatible with Perl 5. And I kinda got fond of UNITCHECK in the last hour or so. :-) Larry
Re: Compile-time undefined sub detection
Larry Wall wrote in perl.perl6.language : Possibly a CHECK block that is compiled after end of main compilation should translate itself to a UNITCHECK. But maybe it should be an error. But it's also possible that CHECK should mean unit check, and there should be an explicit MAINCHECK for delegating checks to the main compilation. In that case, only in the main compilation would CHECK and MAINCHECK mean the same thing. (And since MAINCHECK is explicitly requesting a check at the end of main, a late MAINCHECK should probably be considered an error. (But by that argument, a late CHECK should probably fail under the current naming scheme.)) Anybody got opinions on the naming of these beasts? Certainly *not* renaming CHECK is more compatible with Perl 5. And I kinda got fond of UNITCHECK in the last hour or so. :-) I think I like CHECK and MAINCHECK. (and MAINCHECK being an error after the main compilation phase.) Lots of people who use CHECK (for some value of lots -- let's say, Damian and a few others) actually mean UNITCHECK. MAINCHECK is mainly useful for the O compiler backend, which is part of the perl core anyway, thus without any backward-compatility constraint. (I'd like to have opinions about PAR as well.) So I think changing the meaning of CHECK in Perl 5 is feasible. (and I know it would be welcomed by the mod_perl crowd.)
Re: Compile-time undefined sub detection
Larry wrote: Anybody got opinions on the naming of these beasts? Certainly *not* renaming CHECK is more compatible with Perl 5. I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with Perl 5 and with software engineering jargon. And because MAINCHECK is *ugly*. ;-) So ugly that, if we go the other way and do change CHECK's behaviour, then the new postlinkage phase should be something else: like POSTLINK or PREINIT or INTEGRATE. And I kinda got fond of UNITCHECK in the last hour or so. :-) Well, that counts in its favour too. ;-) Does that imply a UNITEND as well? Damian
Re: Compile-time undefined sub detection
On Sat, Mar 06, 2004 at 08:47:25AM +1100, Damian Conway wrote: : Does that imply a UNITEND as well? Why would you want to unite North Dakota? And how would it differ from END? You can't predict when the last time a module is going to get used... Larry
Re: Compile-time undefined sub detection
Larry Wall wrote: On Fri, Mar 05, 2004 at 06:45:58PM -, Rafael Garcia-Suarez wrote: : Of course :) the main problem is not that CHECK blocks are executed : late (just at the end of the compilation phase); it's that they're : executed too early, notably in some persistent environment, notably : mod_perl (or mod_parrot in the future.) When you have a virtual machine, : you'll end up including modules at run time, because the main : compilation phase becomes less important. Thus CHECK blocks become : worthless, code-reusability-wise. Possibly a CHECK block that is compiled after end of main compilation should translate itself to a UNITCHECK. But maybe it should be an error. But it's also possible that CHECK should mean unit check, and there should be an explicit MAINCHECK for delegating checks to the main compilation. In that case, only in the main compilation would CHECK and MAINCHECK mean the same thing. (And since MAINCHECK is explicitly requesting a check at the end of main, a late MAINCHECK should probably be considered an error. (But by that argument, a late CHECK should probably fail under the current naming scheme.)) Anybody got opinions on the naming of these beasts? Certainly *not* renaming CHECK is more compatible with Perl 5. And I kinda got fond of UNITCHECK in the last hour or so. :-) Larry Given the fact that use of these blocks are overall quite rare, and potentially very confusing to the casual perl hacker who encounters one of them, I propose a rather different tact: BEGIN = EXECUTE_ON_PARSE CHECK = EXECUTE_AFTER_COMPILE and EXECUTE_AFTER_UNIT_COMPILE INIT = EXECUTE_INITIALIZATION END = EXECUTE_ON_EXIT This also has the advantage of being able to reserve all subs with name EXECUTE_.* for compiler/interpreter special sub like these, so we could add more of them come perl 6.8 w/o much issue. -- Rod
Re: Compile-time undefined sub detection
Damian Conway wrote in perl.perl6.language : I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with Perl 5 and with software engineering jargon. As far as Perl 5 is concerned, it appears that most people who write CHECK mean UNITCHECK. Including you :) And because MAINCHECK is *ugly*. ;-) I can't disagree. So ugly that, if we go the other way and do change CHECK's behaviour, then the new postlinkage phase should be something else: like POSTLINK or PREINIT or INTEGRATE. But INTEGRATE is even more ugly.
Re: Compile-time undefined sub detection
Larry asked: And how would it differ from END? Like CHECKs, ENDs execute in reverse order. Which generally means that main END executes before module ENDs (unless we're careful to put our main END before our module loads -- which is subtle and counterintuitive). Sometimes it would be handy to be able to mark some cleanup code so that it executes before main's END, regardless of how early main's END is declared. You can't predict when the last time a module is going to get used... I'm not suggesting you need to. I'm saying that, just as all UNITCHECKs are guaranteed to run before any main CHECK, we might want a UNITEND that's guaranteed to execute before any main END. Damian
Re: Compile-time undefined sub detection
On Fri, Mar 05, 2004 at 04:17:12PM -0600, Rod Adams wrote: Given the fact that use of these blocks are overall quite rare, and potentially very confusing to the casual perl hacker who encounters one of them, I propose a rather different tact: BEGIN = EXECUTE_ON_PARSE CHECK = EXECUTE_AFTER_COMPILE and EXECUTE_AFTER_UNIT_COMPILE INIT = EXECUTE_INITIALIZATION END = EXECUTE_ON_EXIT This also has the advantage of being able to reserve all subs with name EXECUTE_.* for compiler/interpreter special sub like these, so we could add more of them come perl 6.8 w/o much issue. I'm not sure I agree with your actual proposal, but I certainly agree with the spirit of it. When I first saw UNITEND I had to double take to make sure I read it correctly. I propose that if we use multi-word block names, that they have an underscore between the words to be slightly more readable. (I hate underscores, but I hate LONGCAPSWORDS more) -Scott -- Jonathan Scott Duff Division of Nearshore Research [EMAIL PROTECTED] Senior Systems Analyst II
Re: cygwin
Thank you! All is ok, but when "make test" - errors occuring(attached to this message) After this errors testing continues(some tests have "okay" 100%) And then it hands-up on: t/src/extendok 11/13 Is it ok for cygwin? - Original Message - From: TJ Anthony To: Dmitry Nikolayev Cc: p6i List Sent: Saturday, March 06, 2004 4:51 AM Subject: Re: cygwin Dmitry Nikolayev wrote:Did Somebody try to assemble parrot on CygWin?I tried... perl configure.pl - okYou'll need to use:perl Configure.pl --define=inet_atonmake - and error ocured:gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lcrypt blib/lib/libparrot.a(io_unix.o)(.text+0x8f7): In function `PIO_sockaddr_in':/inst/parrot/io/io_unix.c:626: undefined reference to `_inet_pton'collect2: ld returned 1 exit statusmake: *** [parrot.exe] Error 1What is the problem?With best wishes,Dmitry Nikolayev attachment: parrot.jpg
Re: cygwin
Thank you! All is ok, but when "make test" - errors occuring(attached to this message) After this errors testing continues(some tests have "okay" 100%) And then it hands-up on: t/src/extendok 11/13 Is it ok for cygwin? - Original Message - From: TJ Anthony To: Dmitry Nikolayev Cc: p6i List Sent: Saturday, March 06, 2004 4:51 AM Subject: Re: cygwin Dmitry Nikolayev wrote:Did Somebody try to assemble parrot on CygWin?I tried... perl configure.pl - okYou'll need to use:perl Configure.pl --define=inet_atonmake - and error ocured:gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lcrypt blib/lib/libparrot.a(io_unix.o)(.text+0x8f7): In function `PIO_sockaddr_in':/inst/parrot/io/io_unix.c:626: undefined reference to `_inet_pton'collect2: ld returned 1 exit statusmake: *** [parrot.exe] Error 1What is the problem?With best wishes,Dmitry Nikolayev attachment: parrot.jpg
Re: [DOCS] Documentation tools
within reason. Thats where we're way off right now. Let's keep a bit of perspective here. The non-Parrot:: contents of lib accounts for only 4.6% of the non-ICU content (and only 1.5% if you count ICU in the total size). It's difficult to see that as unreasonable, or as bloat. The problem isn't today. It's the trend and next month, when someone decides they need to add some other module, and has a precedent to follow. Then, suddenly we end up with 30 different modules included in our distribution, each one changed slightly from the CPAN one. Dual-lifed modules that live with perl5 are hard enough. -R
Re: Freezing strings?
Brent Dax Royal-Gordon [EMAIL PROTECTED] wrote: Ft/pmc/freeze.t doesn't test freezing and thawing strings or floats. Is this because the functionality hasn't been implemented yet? Exactly. Sould be simple though. Please have a look at classes/perlint.pmc (or such) that implement the freeze/thaw vtables. If it's just some busywork, such as copying some code into PerlString and tweaking it, I can probably do it, but I've been out of the loop for a while, so anything particularly involved is likely beyond me. The interfaces are all there. It *should* just be: - cut'n paste code from perlint - s/_integer/_string/ for (push, shift) and s/int_val/str_val/ For debugging you could set FREEZE_ASCII in pmc_freeze.c albeit its not saving the whole information. leo
RE: Compile-time undefined sub detection
You can't predict when the last time a module is going to get used...
I'm not suggesting you need to. I'm saying that, just as all
UNITCHECKs are
guaranteed to run before any main CHECK, we might want a UNITEND that's
guaranteed to execute before any main END.
Perhaps this is one of those places where properties can help. Instead of
having BEFORE, REALLY_BEFORE, NO_I_MEAN_REALLY_BEFORE, DONE, MOSTLY_DONE,
PARTIALLY_DONE, WELL_DONE, DONE_AND_PROCESS_SPACE_ALMOST_RECLAIMED, etc., we
could simply use some ordering properties:
# Each broad class of upcased block is an execution group. The entries
# in each execution group are not guaranteed to run in any particular order,
# and in fact may run in parallel on a multithreaded perl.
#
# However, blocks in the same source file are guaranteed to run in order of
# occurrence. (Since they're catenated, basically.)
#
# Thus, all BEGIN blocks in a file are effectively catenated and added to
# an overall BEGIN execution group. All the separate BEGIN entries have
# the same initial priority(10), so they will run in whatever order suits
# the P6 runtime.
#
# The Cgo property introduces changes to the execution group and/or
# priority of the block in question. (Note that different priorities may
# be attached to different blocks within the same file. Doing so creates
# separate execution bundles, and breaks any guarantees about order of
# execution.)
#
package OtherPackage;
BEGIN will go first {
print first!;
}
package SomePackage;
BEGIN will go after OtherPackage::BEGIN {
print Second!;
}
END will go priority 5 {
print End block with early priority;
}
package ThirdPackage;
END will go group BEGIN before SomePackage::BEGIN {
print I feel really out of place!;
}
Comment?
=Austin
