Hibernation
Hello everyone,
(Please correct me if this is the wrong list for my proposal.)
I was wonder if it would be possible / usefull to add a hibernation
functionality to the Perl 6 Language, possibly via a Module.
(but the core would have to provide the needed low level functions)
"Hibernate" would simply be a funny kind of fork.
The "child process" is not created instantly, instead the
user has to start the "child process" at a later time, using
some kind of binary image created at hibernation time.
The binary image should represent the interpreters
internal state and the compiled bytecode, as straight
as possible.
example:
if (my $binary = hibernate) {
print "Feelin sleepy... Good Night.";
save_to_disk($binary, "~/myscript.pl.sleeps");
exit;
} else {
print "Im awake !";
}
# perl myscript.pl
Feelin sleepy... Good Night.
# perl myscript.pl.sleeps
Im awake !
Of course, the delicate things like open file handles, permissions... would
have to be handled by a supporting Module.
Perhaps this is usefull for:
- Scripts that are run by crond. If there is a problem (i.e no database
connection),
they could simply hibernate and resume the next time they get called where
they left off.
- CGI Scripts could hibernate instead of exiting, when the request is done.
(goal: minimal overhead to restart even outside mod_perl)
And, a hole Session (many pages/one user) could be served with just one
perl scirpt,
hibernating between requests.
- of advanage if ever a hole OS is beeing written in Perl (hey, you never
know...)
- And of course it would be a nice challange ;-)
Perhaps not usefull at all.
Any toughts ?
Thomas
Configure.pl 2.0. and win32
Hi, All. Configure.pl 2.0 does not want run on Win32 (windows NT 4.0, AcrivStatPerl 5.6.1, VC 6). Prior version ask me: what linker I want use. This do not ask, and variable $ld is undefined (module parrot/lib/Parrot/Configure/Step.pm, sub cc_build). Best regards, Nick.
Re: Configure.pl 2.0. and win32
Nick Kostirya wrote: > Prior version ask me: what linker I want use. > This do not ask, and variable $ld is undefined (module > parrot/lib/Parrot/Configure/Step.pm, sub cc_build). Have you tried configure.pl --ask ? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
RE: Configure.pl 2.0. and win32
Nick Kostirya:
# Configure.pl 2.0 does not want run on Win32 (windows NT 4.0,
# AcrivStatPerl 5.6.1, VC 6). Prior version ask me: what linker
# I want use. This do not ask, and variable $ld is undefined
# (module parrot/lib/Parrot/Configure/Step.pm, sub cc_build).
Configure now doesn't ask questions by default. You can tell it to ask
questions by passing in the "--ask" switch on the command line. You can
also tell it the linker's name directly by passing in
"--ld=(linker-name)".
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
Re: Configure.pl 2.0. and win32
> Configure now doesn't ask questions by default. You can tell it to ask > questions by passing in the "--ask" switch on the command line. You can > also tell it the linker's name directly by passing in > "--ld=(linker-name)". Oh. Sorry to trouble you. It's inattention. Thank you very much. Nick
Half measures all round
(Please CC me on replies) I don't often express many opinions on Perl 6 these days, but I feel I have to warn people about what I see as a potential loss of direction. I'm becoming somewhat disillusioned with Perl 6 these days; sometimes because it's too radical, more often than not because it's not radical enough, and quite often because it's more than a year behind schedule and still slipping. But that last point is by the by; with three people now working full-time on it, I'm sure we can expect it any day now. What's really actually letting me down with it is the half-measures we're applying. We seem to be trying to please everyone, and it's not going to work; indeed, it's going to end up presenting a burden to the implementors. Let's take an example. One of the major points of Perl 6, and one of its major attractions for me, was that we finally put the backwards compatibility ghost to rest. We can do brave, new, exciting things, without worrying about needing to maintain obscure pieces of functionality. Yey! Except that we can't do that any more; we've constrained ourselves to faithfully regressing to Perl 5 when we see a "package" declaration. Why? Because we're scared. "package parses Perl 5" is a sop to people who don't want to program in Perl 6, and we're worried about losing those people. Maybe we've realised that we are going too far, and the new stuff doesn't look all that much like Perl 5, but we're not sufficiently committed to what we have to cut the umbilical cord. Are we going to innovate and improve Perl, no matter what the cost, or is this just a marketing exercise to draw in new users without scaring away the old ones? We have a wonderful new pattern matching language, with some really innovative ideas. It too is burdened by the beast of backwards compatibility. We're too worried about scaring people with change, so we provide these half-measure concessions to keep them happy. I feel like we're carrying around old luggage full of old and dirty clothes, and even when we pick up new suitcases and new clothes, we refuse to put down the old ones because they've been a part of our lives for so long. And so the burden gets heavier. The implementors have a tough enough job to do, dealing with a language which ended up being more difficult to parse and compile than Perl 5, not easier, and I suspect won't enjoy the extra baggage that's being forced upon them. So that's my warning: decide how innovative we're going to be. If we're really going to drive Perl forwards, let's not keep turning backwards, lest we end up as pillars of salt. If we're just giving Perl a spring clean, then maybe we've already gone too far. But let's not get stuck in the middle, doling out half measures all round. -- The dumb joke of the day is: "Call Microsoft. When the operator answers, "Microsoft, may I help you?" respond: "I can't understand you. You're breaking up."
Re: Hibernation
> The binary image should represent the interpreters
> internal state and the compiled bytecode, as straight
> as possible.
Internal state is a problem.
> example:
>
> if (my $binary = hibernate) {
> print "Feelin sleepy... Good Night.";
> save_to_disk($binary, "~/myscript.pl.sleeps");
> exit;
> } else {
> print "Im awake !";
> }
>
> # perl myscript.pl
> Feelin sleepy... Good Night.
>
> # perl myscript.pl.sleeps
> Im awake !
>
>
> Of course, the delicate things like open file handles, permissions... would
> have to be handled by a supporting Module.
And the problem:
An always executing process will have to look after all
the open filehandles, sockets etc. This really should
be a child process.
Scripts dependent on signals - you could hibernate the
script before it was due to catch a signal. Perl code
with signals are already painful to debug.
IMSOHO this is impossible to implement sucessfully, without
turning Perl into a non-portable, complex and slow language.
You could however, with whatever they now call 'use less memory'
when sleep (with more than a few seconds) get Perl to push
it's state onto disk and arrange for it to be swapped out of
disk several seconds before resuming. That seems pointless,
since that's what your operating system's memory management is
for.
Jonathan Paton
=
s''-//--/\\///|-\/\|--\--/-\-/\-//\-|/\\\|/\///|-\--',
s''/-\\\/|///|-|/|/--\--/--//\|\/\||/|/-/\\\-/\///|-\-\-',
y'|\/-'3210',$_=join qq\\,map{s|2|10|||s|3|11|||s|^|0|;$_}
m|.|g;map{print chr unpack'N',pack'B32','0'x24 .$_}/.{8}/g
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Perl 6 regex stuff
Folks, I've checked a draft copy of Apocalypse 5 into the repository. It'll get yanked once the final is released (and I think we may start checking in the final apocalypses and exegeses, but that's for later) but it's there now. Please note: This is so we can start writing the regex parser. It is *not* for design discussion as such (I'm not the person to talk to about that), and it really isn't for discussion on perl6-language (or elsewhere) since it *is* a draft. Close to final, but draft nonetheless. So, discretion please. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even Perl class: stemsystems.com/class teddy bears get drunk
[netlabs #666] Key arguments wrong way around in calls to set_pmc_keyed?
*** core.ops.~1.146.~ Tue Jun 4 11:55:32 2002 --- core.opsTue Jun 4 14:18:31 2002 *** *** 739,745 MAKE_KEY(key, $2, enum_key_int, int_val); ! $1->vtable->set_pmc_keyed(interpreter, $1, &key, $3, NULL); goto NEXT(); } --- 739,745 MAKE_KEY(key, $2, enum_key_int, int_val); ! $1->vtable->set_pmc_keyed(interpreter, $1, NULL, $3, &key); goto NEXT(); } *** *** 748,754 MAKE_KEY(key, $2, enum_key_num, num_val); ! $1->vtable->set_pmc_keyed(interpreter, $1, &key, $3, NULL); goto NEXT(); } --- 748,754 MAKE_KEY(key, $2, enum_key_num, num_val); ! $1->vtable->set_pmc_keyed(interpreter, $1, NULL, $3, &key); goto NEXT(); } *** *** 757,763 MAKE_KEY(key, $2, enum_key_string, struct_val); ! $1->vtable->set_pmc_keyed(interpreter, $1, &key, $3, NULL); goto NEXT(); } --- 757,763 MAKE_KEY(key, $2, enum_key_string, struct_val); ! $1->vtable->set_pmc_keyed(interpreter, $1, NULL, $3, &key); goto NEXT(); } *** *** 878,885 MAKE_KEY(src_key, $2, enum_key_pmc, pmc_val); MAKE_KEY(dest_key, $4, enum_key_pmc, pmc_val); $1->vtable->set_pmc_keyed(interpreter, ! $1, $2 ? &src_key : NULL, $3, $4 ? &dest_key : NULL); goto NEXT(); } --- 878,887 MAKE_KEY(src_key, $2, enum_key_pmc, pmc_val); MAKE_KEY(dest_key, $4, enum_key_pmc, pmc_val); + /* (Can someone independently verify that the keys are the right + way around here) */ $1->vtable->set_pmc_keyed(interpreter, ! $1, $4 ? &dest_key : NULL, $3, $2 ? &src_key : NULL); goto NEXT(); }
[netlabs #667] [PATCH] Assembler support for full opcode names.
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.60
diff -u -r1.60 assemble.pl
--- assemble.pl 3 Jun 2002 23:22:45 - 1.60
+++ assemble.pl 4 Jun 2002 13:56:25 -
@@ -662,6 +662,7 @@
my $temp = $_->[0];
$temp=~s/^(\w+)\s*//;
$_->[0] = [$1];
+my $extname;
while($temp ne '') {
$temp=~s/^\s*(,\s*)?//;
@@ -669,49 +670,49 @@
# Skip flying comments.
}
elsif($temp=~s/^($reg_re)//) {
-$_->[0][0] .= "_".lc(substr($1,0,1));
+$extname .= "_".lc(substr($1,0,1));
push @{$_->[0]}, [lc(substr($1,0,1)),$1];
}
elsif($temp=~s/^\[(S\d+)\]//) { # The only key register should be Sn
-$_->[0][0] .= "_s";
+$extname .= "_s";
push @{$_->[0]}, ['s',$1];
}
elsif($temp=~s/^($flt_re)//) {
-$_->[0][0] .= "_nc";
+$extname .= "_nc";
push @{$_->[0]}, $self->_numeric_constant($1);
}
elsif($temp=~s/^\[($str_re)\]//) {
-$_->[0][0] .= "_sc";
+$extname .= "_sc";
push @{$_->[0]}, $self->_string_constant($1);
}
elsif($temp=~s/^\[($bin_re)\]//) { # P3[0b11101]
my $val = $1;$val=~s/0b//;
-$_->[0][0] .= "_ic";
+$extname .= "_ic";
push @{$_->[0]}, ['ic',(strtol($val,2))[0]];
}
elsif($temp=~s/^\[($hex_re)\]//) { # P7[0x1234]
-$_->[0][0] .= "_ic";
+$extname .= "_ic";
push @{$_->[0]}, ['ic',(strtol($1,16))[0]];
}
elsif($temp=~s/^\[($dec_re)\]//) { # P14[3]
-$_->[0][0] .= "_ic";
+$extname .= "_ic";
push @{$_->[0]}, ['ic',0+$1];
}
elsif($temp=~s/^($bin_re)//) { # 0b1101
my $val = $1;$val=~s/0b//;
-$_->[0][0] .= "_ic";
+$extname .= "_ic";
push @{$_->[0]}, ['ic',(strtol($val,2))[0]];
}
elsif($temp=~s/^($hex_re)//) { # 0x12aF
-$_->[0][0] .= "_ic";
+$extname .= "_ic";
push @{$_->[0]}, ['ic',(strtol($1,16))[0]];
}
elsif($temp=~s/^($dec_re)//) { # -32
-$_->[0][0] .= "_ic";
+$extname .= "_ic";
push @{$_->[0]}, ['ic',0+$1];
}
elsif($temp=~s/^($str_re)//) { # "Hello World"
-$_->[0][0] .= "_sc";
+$extname .= "_sc";
push @{$_->[0]}, $self->_string_constant($1);
}
elsif($temp=~s/^($label_re)//) {
@@ -719,13 +720,16 @@
print STDERR "Couldn't find global label '$1' at line $_->[1].\n";
last;
}
-$_->[0][0] .= "_ic";
+$extname .= "_ic";
push @{$_->[0]}, ['label',$1];
}
else {
print STDERR "Couldn't parse argument '$temp' at line $_->[1].\n";
last;
}
+}
+if(not defined $self->{fullops}{$_->[0][0]}) {
+$_->[0][0] .= $extname;
}
$self->{line_to_pc}{$_->[1]}=$pc;
$pc += scalar @{$_->[0]};
Re: Half measures all round
On Tue, Jun 04, 2002 at 10:43:02AM +0100, Simon Cozens wrote: > (Please CC me on replies) > > I don't often express many opinions on Perl 6 these days, but I feel I have to > warn people about what I see as a potential loss of direction. > > I'm becoming somewhat disillusioned with Perl 6 these days; sometimes because > it's too radical, more often than not because it's not radical enough, and > quite often because it's more than a year behind schedule and still slipping. > But that last point is by the by; with three people now working full-time on > it, I'm sure we can expect it any day now. > > What's really actually letting me down with it is the half-measures we're > applying. We seem to be trying to please everyone, and it's not going to work; > indeed, it's going to end up presenting a burden to the implementors. > > Let's take an example. One of the major points of Perl 6, and one of its major > attractions for me, was that we finally put the backwards compatibility ghost > to rest. We can do brave, new, exciting things, without worrying about needing > to maintain obscure pieces of functionality. Yey! Except that we can't do that > any more; we've constrained ourselves to faithfully regressing to Perl 5 when > we see a "package" declaration. Why? Because we're scared. "package parses > Perl 5" is a sop to people who don't want to program in Perl 6, and we're > worried about losing those people. One word: CPAN. (Okay, that was three words.) It will be a long, long time before all the CPAN modules are rewritten in Perl 6. In the meantime, Perl 6 code has to be able to use Perl 5 modules, or it will be crippled, and probably stillborn. Having said that, I have real, real doubts that Perl 6 will ever be able to execute Perl 5 code natively. Its not just a case a writing a new parser and some P5-specific ops; P5 has so many special features, boundary conditions and pecularies, that to get P6 to execute P5 is a task equivalent to reimplementing P5 from scratch. I'm wondering if instead, we continue to maintain the P5 src tree, and embed P5 within P6 (embed in the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical than the alternatives. It also means that the P6 src doesn't have to be saddled with knowing (much) about P5. Eventually of course the P5 bit would have to be thrown away. Dave. -- "There's something wrong with our bloody ships today, Chatfield." Admiral Beatty at the Battle of Jutland, 31st May 1916.
Parrot IR 0.0.2
Cross-posted to p6l and cardinal. Parrot Intermediate Compiler (or Intermediate Representation) See parrot/languages/imcc Just another round of commits, supporting more directives and instructions. Correctly handling indexed use of strings ala: str[0] = "A" ch = str[0] Will have this working for the rest of the types soon, and still nudging Dan to allow keyed access with the Ix registers. Also added saveall/restoreall for easy subroutine writing until the compiler is smart enough to detect register usage and take care of it itself. Added the concat operator '.' for strings only, so as not to be confused with '+' $S1 = "Foo" . $S2 Finally added 'new' and 'end' end will now be implicitly inserted after the call to the first routine (lacking a .start directive), so you should put your main routine first. Fixed a couple of bugs in the register allocator to not graph color identifiers that were never used. Updated sample.imc. Did I mention its easier to write in IR than Parrot? :) -Melvin
Re: Half measures all round
Dave Mitchell: > > (Please CC me on replies) Actually, now I come to think of it, please don't CC on replies. One thing I really hated about Perl 6 was the number of people sniping from the sidelines providing no useful contribution. And now I've become one. Urgh. > One word: CPAN. I understand this argument, but it is bogus, and doesn't address my point. Either we're breaking backwards compatibility and doing something very new, or we're seeking to retain compatibility with the past. Which is it to be? Yes, there's a lot of legacy crap out there. Much of the important parts of it are XS, which we can't hope to support. (No, Dan, be realistic) So, let's go through the CPAN argument: * Allowing CPAN code to be run in Perl 6 tantamounts to legitimizing its use. * Legitimizing the legacy code means it'll never get ported to Perl 6 * Producing Perl 5 results in a Perl 6 world may not make much sense anyway. * Subtle differences between P5 usage and P6 usage would give module authors a support nightmare. * Some of those authors may not know about or want to support a Perl 6 use of their module anyway. (Thank you for your bug report, but it appears to be written in a different language.) * Digging a pit for module authors to fall into considered unfriendly. * It's still a backwards compatibility sop. Perl 4 libraries had to be rewritten for Perl 5. I don't see why Perl 5 libraries should escape. Anyway, I've done my Ancient Mariner bit now and given my warning. Be sure to cast off that albatross. -- Everything that can ever be invented has been invented - Charles H. Duell, Commisioner of U.S. Patents, 1899.
RE: Perl 6 regex stuff
Dan Sugalski:
# I've checked a draft copy of Apocalypse 5 into the repository. It'll
# get yanked once the final is released (and I think we may start
# checking in the final apocalypses and exegeses, but that's for later)
# but it's there now.
#
# Please note: This is so we can start writing the regex parser. It is
# *not* for design discussion as such (I'm not the person to talk to
# about that), and it really isn't for discussion on perl6-language (or
# elsewhere) since it *is* a draft. Close to final, but draft
# nonetheless. So, discretion please.
In that case, I have a half-written, untested bison/flex parser
attached. Have the appropriate amount of fun.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
regex6.y
Description: Binary data
regex6.l
Description: Binary data
RE: Half measures all round
Simon Cozens:
# I'm becoming somewhat disillusioned with Perl 6 these days;
# sometimes because it's too radical, more often than not
# because it's not radical enough, and quite often because it's
# more than a year behind schedule and still slipping. But that
# last point is by the by; with three people now working
# full-time on it, I'm sure we can expect it any day now.
It's actually starting to get a bit scary... ;^)
# What's really actually letting me down with it is the
# half-measures we're applying. We seem to be trying to please
# everyone, and it's not going to work; indeed, it's going to
# end up presenting a burden to the implementors.
#
# Let's take an example. One of the major points of Perl 6, and
# one of its major attractions for me, was that we finally put
# the backwards compatibility ghost to rest. We can do brave,
# new, exciting things, without worrying about needing to
# maintain obscure pieces of functionality. Yey! Except that we
# can't do that any more; we've constrained ourselves to
# faithfully regressing to Perl 5 when we see a "package"
# declaration. Why? Because we're scared. "package parses Perl
# 5" is a sop to people who don't want to program in Perl 6,
# and we're worried about losing those people.
Who says it's a bad thing to be scared, or that our fear isn't
justified? Fear is a survival instinct, and a relatively good one.
In this case, I think what happened is closer to "we saw a hook to bring
in backwards compatibility and used it". Unless I'm mistaken, the new
C and C keywords will probably have slightly different
meanings, so C was insufficient anyway. So we said, "OK, we're
changing this, and if we see it the old way we switch to Perl 5". I
don't think anyone's decided exactly what that means yet--we may load a
different rule set, set up some sort of source filter, or just cop out
and invoke p52p6. In any case, I think of it more as a convenience than
a major feature, and I suspect most Perl 6 users will agree with that
assessment.
# Maybe we've realised that we are going too far, and the new
# stuff doesn't look all that much like Perl 5, but we're not
# sufficiently committed to what we have to cut the umbilical
# cord. Are we going to innovate and improve Perl, no matter
# what the cost, or is this just a marketing exercise to draw
# in new users without scaring away the old ones?
#
# We have a wonderful new pattern matching language, with some
# really innovative ideas. It too is burdened by the beast of
# backwards compatibility. We're too worried about scaring
# people with change, so we provide these half-measure
# concessions to keep them happy.
Can you specify how? It looks to me like it's changed fairly
dramatically, but is still similar enough to be easy to adjust to.
# I feel like we're carrying around old luggage full of old and
# dirty clothes, and even when we pick up new suitcases and new
# clothes, we refuse to put down the old ones because they've
# been a part of our lives for so long. And so the burden gets
# heavier. The implementors have a tough enough job to do,
# dealing with a language which ended up being more difficult
# to parse and compile than Perl 5, not easier, and I suspect
# won't enjoy the extra baggage that's being forced upon them.
#
# So that's my warning: decide how innovative we're going to
# be. If we're really going to drive Perl forwards, let's not
# keep turning backwards, lest we end up as pillars of salt. If
# we're just giving Perl a spring clean, then maybe we've
# already gone too far. But let's not get stuck in the middle,
# doling out half measures all round.
Just because we're trying to make radical changes doesn't mean we can't
make a small sacrifice to the backwards-compatibility gods. After all,
it would be kinda nice if there were users besides p6* list members, and
I doubt it'll work without at least the small sacrifice of imperfect
emulation. (And I don't believe we're promising perfect emulation,
either--just "we'll try our best".)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
Re: Half measures all round
On 6/4/02 8:13 AM, "Simon Cozens" <[EMAIL PROTECTED]> claimed: > Yes, there's a lot of legacy crap out there. Much of the important parts of it > are XS, which we can't hope to support. (No, Dan, be realistic) So, let's go > through the CPAN argument: Personally, I'm still really jazzed about Perl 6, but I certainly see your point, Simon. As a CPAN contributor myself, I intend, once Perl 6 is delivered, to port my modules to Perl 6 (where appropriate -- Data::Types likely won't even be necessary anymore!), and leave the Perl 5 stuff to slowly die off. I think that if we can agree to forego backwards compatibility, we might also be in a better position to set up a CP6AN with much better quality control. All of the most important modules will be ported very quickly (e.g., the DBI), and a lot of the cruft will be left to die (at least from the Perl 6 perspective). And I like the idea that the designers mentioned on Use Perl the other day, that Perl 6 may not ship with any add-ons, and there would instead be development kits available. This will have the affect of establishing n packages that are officially endorsed by the planners/maintainers, but don't burden the distribution. So I guess I'm agreeing with you, Simon. I have no problem with thinking of Perl 6 as a completely new language, and will be happy to work in both P5 and P6 in parallel for a while. And if my Perl 5 modules don't work in Perl 6, I will be motivated to port them. Plenty of folks are still dedicated to Perl 5, and it will likely to continue moving forward for some time -- it may never die. And I think that's true regardless of whether Perl 6 supports Perl 5 or not. So it's okay by me to dump it. Lots of people will freak out, but many won't. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Half measures all round
On Tue, Jun 04, 2002 at 04:13:36PM +0100, Simon Cozens wrote: Hmm, June 4. Independence day, with an off by 1 error. Must be a C program involved somewhere. :-) In brief, I'm with Damien on this one. IMHO C++ is an ugly bastard of a programming language because they cut the cord ineffectively and much too late in the process. OOPerl is an ugly bastard of a language. We have the opportunity to clean that up; we should sieze it. As for CPAN . . . don't get me started. CPAN is a blessing, but has become a curse as well. It's contents need to be razed to the ground and better/more conistant rules set up for how to do installations into and out of the standard trees. If you think this is a bitch now, just wait until simultaneous per-author and per-version installation and invocation is allowed as Larry has promised. I have this horrible fear of perl module installations becoming a bowl of spagetti that's been run thru a blender and mixed with a packet of jello. Speaking as a 20+-year sysadmin, if CPAN is used for Perl6 with those new features and without a massive clean, I foresee a nightmare. We have said that perl5 will be *mostly* mechanically translatable into perl6. IMHO, that's close enough. Full backwards compatibility leads to paralysis or an even further expansion of the complexity and bizarreness that is all too often perl. We should draw the line on translation at a program that will translate p5 source to p6 source. We should not auto-compile it and tolerate it forever; that way lies madness. Sorry to be so pessistic and negative, but that's my story and I'm sticking to it.
Re: Half measures all round
On Tue, 4 Jun 2002, Simon Cozens wrote: : Dave Mitchell: : > > (Please CC me on replies) : : Actually, now I come to think of it, please don't CC on replies. One thing I : really hated about Perl 6 was the number of people sniping from the sidelines : providing no useful contribution. And now I've become one. Urgh. Don't stress. Whenever I see someone sniping from the sidelines, I take it as a clue that I haven't communicated well enough. : > One word: CPAN. : : I understand this argument, but it is bogus, and doesn't address my point. : Either we're breaking backwards compatibility and doing something very new, or : we're seeking to retain compatibility with the past. Which is it to be? Whenever someone asks "Which is it to be?", I always suspect they're setting up a false dichotomy. In this case, you're ignoring a very real engineering issue, which is migration strategy. Your question is posed in the eternal present tense, but this is a temporal issue. When they're building a new interchange on an interstate highway, they don't tear down the old one and then put up the new one. The traffic has to keep flowing. So over the course of time there will be various odd temporary roads that take you through and around the construction area, and you're always afraid the temporary scaffolding is going to come down on your head. But eventually the scaffolding does come down, and what's left is all concrete, and nobody remembers how the old road went. When DEC first invented the VAX, they put in an emulation of PDP-11 assembly language, because they knew it would take time for people to migrate. Eventually the emulation went away. Anyway, you seem to be saying that two features of Perl 5 scaffolding will ruin Perl 6. I think you haven't really thought about migration strategy long enough. : Yes, there's a lot of legacy crap out there. Much of the important parts of it : are XS, which we can't hope to support. (No, Dan, be realistic) So, let's go : through the CPAN argument: : : * Allowing CPAN code to be run in Perl 6 tantamounts to legitimizing its : use. In what sense does Perl 6 de-legitimize Perl 5 code? Perl 5 is as legitimate as it is. Perl 6 neither adds to nor takes anything away from that. Perl 6 may be better, but only if you have the Perl 6 code to run. We have to get there from here, and there has to be gentle but relentless pressure to migrate, but if Perl 6 really is better, that pressure will be there. Treating Perl 5 programs (and by extension, Perl 5 programmers) as illigitimate is not going to speed up the process. : * Legitimizing the legacy code means it'll never get ported to Perl 6 No, requiring everyone to translate everything all at once means nothing will get ported. Open source projects only know how to do things piecemeal. They don't know how to do things all at once. : * Producing Perl 5 results in a Perl 6 world may not make much sense : anyway. Don't understand what you're saying there. Data is data, and most results aren't either Perl 5 or Perl 6 results. They're just data. : * Subtle differences between P5 usage and P6 usage would give module : authors a support nightmare. Once you have a working P6 module, you can throw away the P5 module, or at least treat it as no-longer-supported. : * Some of those authors may not know about or want to support a Perl 6 : use of their module anyway. (Thank you for your bug report, but it : appears to be written in a different language.) Dinosaurs happen. But eventually they evolve into birds. : * Digging a pit for module authors to fall into considered unfriendly. Yeah, but we're using the extra dirt to raise a mountain for them to climb. The capacity for greater good always comes with the capacity for greater evil. : * It's still a backwards compatibility sop. Perl 4 libraries had to be : rewritten for Perl 5. I don't see why Perl 5 libraries should escape. Perl 5 libraries do have to be rewritten (or translated) for Perl 6. But that will only happen if Parrot can emulate Perl 5 long enough for people to climb each rung of the ladder one step at a time. Most people can't leap tall buildings in a single bound. Larry
Re: Half measures all round
Steve Simmons: > We have said that perl5 will be *mostly* mechanically translatable into > perl6. And we shall keep saying this until we believe that it is true? -- Hubris is when you really do have it, enough so only the gods slap you down. Pretentiousness is when you don't have it, and everyone slaps you down. Arrogance is somewhere in between. - Thorfinn
Re: Half measures all round
On Tue, Jun 04, 2002 at 05:40:08PM +0100, Simon Cozens wrote: > Steve Simmons: > > We have said that perl5 will be *mostly* mechanically translatable into > > perl6. > And we shall keep saying this until we believe that it is true? *grin* My apologies for using the wrong name, Simon. Doh! -- STEP 4: PRACTICE THE RULE OF THREE: If an e-mail thread has gone back and forth three times, it is time to pick up the phone. from the 12-Step Program for email addicts, http://www.time.com/time/columnist/taylor/article/0,9565,257188,00.html
Re: Half measures all round
On Tue, 4 Jun 2002, Simon Cozens wrote: : Steve Simmons: : > We have said that perl5 will be *mostly* mechanically translatable into : > perl6. : : And we shall keep saying this until we believe that it is true? No, we'll keep saying this until we make it true. Faith without works is dead. Larry
Re: Half measures all round
On Tue, 4 Jun 2002, Simon Cozens wrote: > Steve Simmons: > > We have said that perl5 will be *mostly* mechanically translatable into > > perl6. > > And we shall keep saying this until we believe that it is true? As a Perl user (the kind of guy who uses Perl at work for everything humanly possible), I personally don't have a use for backward compatibility at all. If there's a cool P5 module that I just *need* in P6, I'll port the thing myself. At work I will install the latest P5 and P6 at the same time. If I need P5 I'll use it, otherwise I'll use P6. I personally believe that getting P5 compatibility in Perl 6 is entirely possible, but I would never use it and I would perfer that the massive amount of work that would go into it, go into something else, like porting popular modules (like DBI, etc) or just plain working on the core language to make it all that it can be. Furthermore, *if* enough people could be motivated into creating such a compatibility layer (many people have noted the slowness at which development is happening now), I can't believe that it would be complete enough to rely on in a production system, but to be fair I may be underestimating the community in that respect. I think that compatibility is a goal that looks nice on paper, but as someone who's "in the trenches" I don't think it will be that useful to me. - D <[EMAIL PROTECTED]>
Re: 6PAN (was: Half measures all round)
On 6/4/02 12:22 PM, David Wheeler wrote: > I think that if we can agree to forego backwards compatibility, we might > also be in a better position to set up a CP6AN with much better quality > control. All of the most important modules will be ported very quickly > (e.g., the DBI), and a lot of the cruft will be left to die (at least from > the Perl 6 perspective). Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of this effort? Do we even have a vague idea of the requirements? Or does everyone think CPAN (and module distribution/installation in general) as it exists now it pretty much okay, and just needs some tweaks to work with Perl 6 code? I really hope that's not the case! :) In the spirit of Simon's desire to see "radical changes" when appropriate, I propose the following high-level goals for 6PAN (yes, that's my favorite of the bunch ;) 1. Multiple versions of the same module may be installed on a single system with no possibility of conflicts. That means no conflicts of any kind, whether it be in Perl code, XS-ish stuff, private shared libs, etc. 2. Module packaging, expansion, and installation only requires a working install of Perl 6 (unless the module contains non-Perl code, such as C, etc., in which case the appropriate tools for C builds need to be present: cc/gcc, ld, make, and so on). Requiring "make" and friends to install pure perl files is a legacy relic, IMO. 3. Module removal should be as easy as installation. I can think of many other worthy high-level goals, but these are the most important, IMO. And number one is by far the most important to me. A few natural extensions of it are: 1a. Modules may be "use"-ed in several ways (syntax ignored for now): # Note "...installed on this system" is implied at the end # of each of the following descriptions "Use the latest stable version of module Foo" (probably the default) "Use the latest version of module Foo" "Use the latest stable version of module Foo 1.xx" "Use the latest version of module Foo 1.xx" "Use module Foo 1.2" 1b. 6PAN modules comply with an informal contract to maintain backward-compatibility within all N.MM versions, where N is constant. In other words, incompatible API changes are only allowed by incrementing the "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. "backward-compatible"). 1c. Distinctions like "alpha", "beta", and "stable" need to be made according to some convention (a la $VERSION...perhaps $STATUS?) I don't think the implementation details are too hard to hash out (he says, optimistically... ;) But to meet these goals, they have to be thought about early on. Some of them even require hooks in the language proper (e.g. "use/require" extensions.) Thoughts? Or has this stuff already been hashed out elsewhere and I missed it? :) -John
Re: Half measures all round
On Tue, 4 Jun 2002, Dave Mitchell wrote: > Having said that, I have real, real doubts that Perl 6 will ever be able > to execute Perl 5 code natively. Its not just a case a writing a new > parser and some P5-specific ops; P5 has so many special features, boundary > conditions and pecularies, that to get P6 to execute P5 is a task > equivalent to reimplementing P5 from scratch. I'm wondering if instead, > we continue to maintain the P5 src tree, and embed P5 within P6 (embed in > the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical > than the alternatives. It also means that the P6 src doesn't have to be > saddled with knowing (much) about P5. Eventually of course the P5 bit > would have to be thrown away. That's exactly what I've been arguing for all along. Grr And that's why I see the "package" hack and the new :p5 modifier as having the weight of two features, not the weight of an entire re-implementation of Perl 5. It's really not that difficult to run two interpreters in the same process. I already made Perl and Java run together nicely. If anything the impedence mismatch between Perl 5 and Perl 6 will be even less. Scaffolding is supposed to be ugly. You wouldn't believe how ugly the transitional form between Perl 4 and Perl 5 was, when half the opcodes were interpreted by the old stacked interpreter, and half by the new stackless one. Larry
Re: Half measures all round
Larry Wall: > That's exactly what I've been arguing for all along. Grr Thank you. Now I'm somewhat less concerned. And that makes the implementation much easier. It was just when people were saying that the parser needed to be sufficiently flexible to parse both languages that I got the heeby-jeebies. -- Britain has football hooligans, Germany has neo-Nazis, and France has farmers. -The Times
Re: 6PAN (was: Half measures all round)
On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: > 1b. 6PAN modules comply with an informal contract to maintain > backward-compatibility within all N.MM versions, where N is constant. In > other words, incompatible API changes are only allowed by incrementing the > "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor > version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. > "backward-compatible"). This might be asking too much -- it's not very perlish, in the sense of TIMTOWTDI. It might make sense for DKs, but different people may want to use the conventions their comfortable with. Perl is there for you to create applications (and APIs) the way you want, not the way the gods demand. > Thoughts? Or has this stuff already been hashed out elsewhere and I missed > it? :) One thing I think is as important -- or perhaps more important -- is to enforce the presence of unit tests. There are a lot of modules on the CPAN that have no tests, and most of them suffer for it. It shouldn't be required that all tests pass, however. A statement showing what platforms they pass on and what platforms they don't at the top of the download page would be good enough. But the tests have got to be there. Regard, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Re: 6PAN (was: Half measures all round)
On 6/4/02 12:34 PM, Steve Simmons wrote: > As for CPAN . . . don't get me started. CPAN is a blessing, but has > become a curse as well. It's contents need to be razed to the ground > and better/more conistant rules set up for how to do installations > into and out of the standard trees. If you think this is a bitch now, > just wait until simultaneous per-author and per-version installation > and invocation is allowed as Larry has promised. Oh, so then this has been talked about before (surprise :) > I have this horrible fear of perl module installations becoming a bowl of > spagetti that's been run thru a blender and mixed with a packet of jello. > Speaking as a 20+-year sysadmin, if CPAN is used for Perl6 with those new > features and without a massive clean, I foresee a nightmare. I'm a big fan of the "framework" abstraction as seen I Mac OS X. All the big, ugly mess is neatly encapsulated in "atomic" directory structures whose internals are accessed only through a well-defined (and always backwards- compatible) API. The internal organization of these directories can change over time, and many versions of the format may coexist, since the manipulation API would understand them all. Moving modules around should be as simple as moving directories around. Similarly, removing (all versions of) a module should be as simple as "rm -rf dirname" Obviously I favor encapsulation-by-module, where each "module directory/framework/whatever" contains all installed versions of that module. I think that's a better (physical) arrangement than by-author, by-version, or by-origin. (Those distinctions can be made in the abstract through introspection.) The current Perl 5 module system of physically dividing up files by type and origin is ins?ane, IMO. We've got a single Perl 5 "module" installing files in 10 different, widely-separated directories. That's a very inconvenient physical layout, future fancy keep-track-of-what-I-installed-where RPM-like facilities or no. Arbitrary (physical) divisions are easy enough once the modules are individually encapsulated. I dream of seeing a Perl 6 @INC path (or equivalent) like: /usr/local/lib/perl6/core /usr/local/lib/perl6/site and that's it! One directory per "place to look for modules." -John
Re: 6PAN (was: Half measures all round)
On 6/4/02 1:11 PM, David Wheeler wrote: > On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: >> 1b. 6PAN modules comply with an informal contract to maintain >> backward-compatibility within all N.MM versions, where N is constant. In >> other words, incompatible API changes are only allowed by incrementing the >> "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor >> version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. >> "backward-compatible"). > > This might be asking too much -- it's not very perlish, in the sense of > TIMTOWTDI. It might make sense for DKs, but different people may want to use > the conventions their comfortable with. Perl is there for you to create > applications (and APIs) the way you want, not the way the gods demand. Well, there are already "suggested" conventions for version number formats. Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping ground for modules. Let the version numbering and API anarchists use SourceForge, I say! :) It's not like we're demanding EJB-like API rigidity. So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar() in 6PAN, for better or for worse. All I'm asking for is some small meaning behind version numbering. Is that so wrong? :) >> Thoughts? Or has this stuff already been hashed out elsewhere and I missed >> it? :) > > One thing I think is as important -- or perhaps more important -- is to > enforce the presence of unit tests. There are a lot of modules on the CPAN > that have no tests, and most of them suffer for it. Heh, I was going to suggest that new minor-version 6PAN submissions automatically have all the earlier minor-version test suites run against them before allowing them to go into the archive... :) -John
Re: Half measures all round
At 5:40 PM +0100 6/4/02, Simon Cozens wrote: >Steve Simmons: >> We have said that perl5 will be *mostly* mechanically translatable into >> perl6. > >And we shall keep saying this until we believe that it is true? Coming from the man who wrote part of a Python->Perl converter? >Hubris is when you really do have it, enough so only the gods slap you >down. Pretentiousness is when you don't have it, and everyone slaps >you down. Arrogance is somewhere in between. Interesting quote... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even Perl class: stemsystems.com/class teddy bears get drunk
Re: 6PAN (was: Half measures all round)
On Tue, 4 Jun 2002, John Siracusa wrote: : On 6/4/02 12:22 PM, David Wheeler wrote: : > I think that if we can agree to forego backwards compatibility, we might : > also be in a better position to set up a CP6AN with much better quality : > control. All of the most important modules will be ported very quickly : > (e.g., the DBI), and a lot of the cruft will be left to die (at least from : > the Perl 6 perspective). : : Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of : this effort? Do we even have a vague idea of the requirements? Or does : everyone think CPAN (and module distribution/installation in general) as it : exists now it pretty much okay, and just needs some tweaks to work with Perl : 6 code? I really hope that's not the case! :) I haven't gotten to that Apocalypse yet. :-) : In the spirit of Simon's desire to see "radical changes" when appropriate, I : propose the following high-level goals for 6PAN (yes, that's my favorite of : the bunch ;) : : 1. Multiple versions of the same module may be installed on a single system : with no possibility of conflicts. That means no conflicts of any kind, : whether it be in Perl code, XS-ish stuff, private shared libs, etc. Yes, I'm already on record that multiple installed versions will coexist peacably, certainly on disk, and to the extent that they can in memory. We can't stop two versions of a module from fighting over a shared resource, for instance. Two different database modules may have to figure out who really has the connection to the database engine, and who just thinks they have the connection. Possibly it would help to have package variables that are explicitly shared among different versions of the same package when they represent a shared object. : 2. Module packaging, expansion, and installation only requires a working : install of Perl 6 (unless the module contains non-Perl code, such as C, : etc., in which case the appropriate tools for C builds need to be present: : cc/gcc, ld, make, and so on). Requiring "make" and friends to install pure : perl files is a legacy relic, IMO. Certainly, though it's trivially easy to come up with something that's even uglier than make. Been done many times... : 3. Module removal should be as easy as installation. Fine. There ought to be something in the metadata that says, "This version of this module hasn't been used since 2017." Then you can clear out the deadwood easily. Course, disk space will be a little cheaper by then, so maybe we'll just hang onto everything forever. : I can think of many other worthy high-level goals, but these are the most : important, IMO. And number one is by far the most important to me. A few : natural extensions of it are: : : 1a. Modules may be "use"-ed in several ways (syntax ignored for now): : : # Note "...installed on this system" is implied at the end : # of each of the following descriptions : : "Use the latest stable version of module Foo" (probably the default) : "Use the latest version of module Foo" : "Use the latest stable version of module Foo 1.xx" : "Use the latest version of module Foo 1.xx" : "Use module Foo 1.2" Yes, there have to be ways of getting at modules by their long names, their short names, and various intermediate wildcard names. Perl 6 will have to keep track of which version you used, so when you use the short name, it knows which long name you really mean. : 1b. 6PAN modules comply with an informal contract to maintain : backward-compatibility within all N.MM versions, where N is constant. In : other words, incompatible API changes are only allowed by incrementing the : "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor : version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. : "backward-compatible"). Fine. We can separate out interface from implementation better in the language too. : 1c. Distinctions like "alpha", "beta", and "stable" need to be made : according to some convention (a la $VERSION...perhaps $STATUS?) Can probably burn that bridge when we get to it. : I don't think the implementation details are too hard to hash out (he says, : optimistically... ;) But to meet these goals, they have to be thought about : early on. Some of them even require hooks in the language proper (e.g. : "use/require" extensions.) Those are details, the like of which would be easy to determine at the last moment. But the underlying mechanisms have to be design in, yes. : Thoughts? Or has this stuff already been hashed out elsewhere and I missed : it? :) It's here and there. Some of it has been in my speeches, and some in the Apocalypses. Larry
Re: Half measures all round
On Tue, 4 Jun 2002 10:06:44 -0700 (PDT) Larry Wall <[EMAIL PROTECTED]> wrote: >It's really not that difficult to run two interpreters in the >same process. I already made Perl and Java run together nicely. Agree. >Scaffolding is supposed to be ugly. You wouldn't believe how ugly >the transitional form between Perl 4 and Perl 5 was, when half the The difference in software branches and highways is that software can be built completely off-site until it's reasonably functional, and then moved in on the back of a semi-trailer. There is no reason why we shouldn't produce a "Purely P6" virtual machine, parser, etc. first, then start building the scaffolding. -Melvin
Re: 6PAN (was: Half measures all round)
On 6/4/02 10:21 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: > Well, there are already "suggested" conventions for version number formats. > > Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping > ground for modules. Let the version numbering and API anarchists use > SourceForge, I say! :) It's not like we're demanding EJB-like API rigidity. > So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar() > in 6PAN, for better or for worse. All I'm asking for is some small meaning > behind version numbering. Is that so wrong? :) Okay, I'll buy that. And I think that suggested guidelines for compatibility between version numbers would be valuable, but I wouldn't think that we should enforce it. There may be good reasons to break backward compatibility in some cases. > Heh, I was going to suggest that new minor-version 6PAN submissions > automatically have all the earlier minor-version test suites run against > them before allowing them to go into the archive... :) Hmmm...perhaps as a warning: All regression tests not passed. Do you still want to upload this module? That'll stop the vast majority of offenders, and those who upload anyway will be more likely to have documented changes. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: 6PAN (was: Half measures all round)
On 6/4/02 1:26 PM, Larry Wall wrote: > : Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of > : this effort? Do we even have a vague idea of the requirements? Or does > : everyone think CPAN (and module distribution/installation in general) as it > : exists now it pretty much okay, and just needs some tweaks to work with Perl > : 6 code? I really hope that's not the case! :) > > I haven't gotten to that Apocalypse yet. :-) Is this where I get scared by the reference to the year "2017" later in your message? ;) > : 2. Module packaging, expansion, and installation only requires a working > : install of Perl 6 (unless the module contains non-Perl code, such as C, > : etc., in which case the appropriate tools for C builds need to be present: > : cc/gcc, ld, make, and so on). Requiring "make" and friends to install pure > : perl files is a legacy relic, IMO. > > Certainly, though it's trivially easy to come up with something that's even > uglier than make. Been done many times... I'm not really concerned about the syntax so much as the dependency on "something other than Perl" for simple modules. Along similar lines, platform-specific binary distributions should probably be an (automatically-generated during submission?) first class citizen in 6PAN for systems that don't have "anything but Perl" on them (no compiler, no make, no nothing) but still want to be able to install any 6PAN module... or, heck, for people who just don't want to be bothered with compiling. I guess there are OS/library version issues there, but I think you could hit 90% of the "common" target environments pretty easily, and it should be extensible to cover more exotic targets down the road (which is why it should be an automatic part of 6PAN and not manual :) > : 3. Module removal should be as easy as installation. > > Fine. There ought to be something in the metadata that says, "This version > of this module hasn't been used since 2017." Then you can clear out the > deadwood easily. Course, disk space will be a little cheaper by then, so > maybe we'll just hang onto everything forever. Obviously you meant to type "holographic cube" ;) > : 1c. Distinctions like "alpha", "beta", and "stable" need to be made > : according to some convention (a la $VERSION...perhaps $STATUS?) > > Can probably burn that bridge when we get to it. Well, to have use/require/etc. Support the "get me the latest-stable installed version" semantics as the default meaning, won't we need some standard way to define "stable" right off the bat? Or does "right off the bat" == "when we get to it"? Or does the absence of any $STATUS-like variable imply "stable"? (That last one seems Wall-ish, if not Perlish ;) -John
Re: 6PAN (was: Half measures all round)
--- Larry Wall <[EMAIL PROTECTED]> wrote: > : > : 1a. Modules may be "use"-ed in several ways (syntax ignored for > now): > : > : # Note "...installed on this system" is implied at the end > : # of each of the following descriptions > : > : "Use the latest stable version of module Foo" (probably the > default) > : "Use the latest version of module Foo" > : "Use the latest stable version of module Foo 1.xx" > : "Use the latest version of module Foo 1.xx" > : "Use module Foo 1.2" > > Yes, there have to be ways of getting at modules by their long names, > their > short names, and various intermediate wildcard names. Perl 6 will > have to > keep track of which version you used, so when you use the short name, > it > knows which long name you really mean. > > : 1c. Distinctions like "alpha", "beta", and "stable" need to be made > : according to some convention (a la $VERSION...perhaps $STATUS?) > > Can probably burn that bridge when we get to it. > Been done before: 3.1.3. Examples The following examples of font names are derived from the screen fonts shipped with the X Consortium distribution. Charter 12 pt ... -Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1 Charter Bold 12 pt ... -Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1 Charter Bold Italic 12 pt ... -Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1 Charter Italic 12 pt ... -Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1 Courier 8 pt ... -Adobe-Courier-Medium-R-Normal--8-80-75-75-M-50-ISO8859-1 Courier 10 pt ... -Adobe-Courier-Medium-R-Normal--10-100-75-75-M-60-ISO8859-1 Courier 12 pt ... -Adobe-Courier-Medium-R-Normal--12-120-75-75-M-70-ISO8859-1 Courier 24 pt ... -Adobe-Courier-Medium-R-Normal--24-240-75-75-M-150-ISO8859-1 Courier Bold 10 pt ... -Adobe-Courier-Bold-R-Normal--10-100-75-75-M-60-ISO8859-1 Courier Bold Oblique 10 pt ... -Adobe-Courier-Bold-O-Normal--10-100-75-75-M-60-ISO8859-1 __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 12:59:38PM -0400, John Siracusa wrote: > In the spirit of Simon's desire to see "radical changes" when appropriate, I > propose the following high-level goals for 6PAN . . . > 1. Multiple versions of the same module may be installed on a single system > with no possibility of conflicts. That means no conflicts of any kind, > whether it be in Perl code, XS-ish stuff, private shared libs, etc. Larry has stated this as a goal, and in this thread on Tue, Jun 04, 2002 at 10:26:22AM -0700, Larry Wall wrote: > Yes, I'm already on record that multiple installed versions will > coexist peacably, certainly on disk, and to the extent that they can > in memory. We can't stop two versions of a module from fighting over a > shared resource, for instance . . . And that's an issue that needs to be resolved -- modules are going to have to be able to test for each others state of being loaded and have some mechanisms to disambiguate and defer to each other. I won't go down the sytactic rathole of what *that* entails, just noting it as an issue. Back to John S: > : 2. Module packaging, expansion, and installation only requires a working > : install of Perl 6 (unless the module contains non-Perl code, such as C, > 3. Module removal should be as easy as installation. Yes, yes. > 1a. Modules may be "use"-ed in several ways (syntax ignored for now): I addressed a few of these in RFC78 and quite a few more in an as-yet unpublished rewrite of it; Larry mentioned a line or two of syntax in a recent email that's not terribly dissimilar. All the things you specify are relatively easy in the perl world. It's mapping them into filenames and directories that @INC can use that gets, er, interesting. However . . . > 1b. 6PAN modules comply with an informal contract to maintain > backward-compatibility within all N.MM versions, where N is constant. . . IMHO it should be a stated requirement, just as one needs a Makefile.PL. And while person's tweak is another persons incompatible blotch, we ultimately have to defer to `in the opinion of the author.' On Tue, Jun 04, 2002 at 10:11:40AM -0700, David Wheeler responds to Johns stuff above: > This might be asking too much -- it's not very perlish, in the sense of > TIMTOWTDI. It might make sense for DKs, but different people may want to use > the conventions their comfortable with. Perl is there for you to create > applications (and APIs) the way you want, not the way the gods demand. I must respectfully disagree. Perl has rules, and strict ones -- and more than just the syntax and the semantics. Anyone can *change* perls syntax, but they have to get buy-in from a fairly large and conservative community to get it incorporated into perl. Why should we not be as careful about 6PAN? We could take this a step further -- let CPAN be the perl equivelent of Sourceforge, but hold 6PAN to a higher standard. TIMTOWTDI. > One thing I think is as important -- or perhaps more important -- is to > enforce the presence of unit tests. There are a lot of modules on the CPAN > that have no tests, and most of them suffer for it. Yes, but . . . > It shouldn't be required that all tests pass, however. A statement showing > what platforms they pass on and what platforms they don't at the top of the > download page would be good enough. But the tests have got to be there. Actually, for 6PAN I think they should have to pass. And maybe we need a bug submission setup, and status checks, and . . . OK, OK, I'll stop now. They're nice ideas, but who bells the cat? The again, if Tim O'Reilly wants to fund me I'd be happy to do it. :-) On Tue, Jun 04, 2002 at 01:21:26PM -0400, John Siracusa wrote on the same thread: > Heh, I was going to suggest that new minor-version 6PAN submissions > automatically have all the earlier minor-version test suites run against > them before allowing them to go into the archive... :) Yep, that too. Which means . . . On Tue, Jun 04, 2002 at 10:57:15AM -0700, David Wheeler wrote: > On 6/4/02 10:21 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: > Hmmm...perhaps as a warning: > > All regression tests not passed. Do you still want to upload this module? s/Do you still want to upload this module?/Upload rejected./ On Tue, Jun 04, 2002 at 10:26:22AM -0700, Larry Wall wrote: > : 3. Module removal should be as easy as installation. > > Fine. There ought to be something in the metadata that says, "This version > of this module hasn't been used since 2017." Then you can clear out the > deadwood easily. Course, disk space will be a little cheaper by then, so > maybe we'll just hang onto everything forever. Nu? If you mean used in the sense of 'use foo', that would imply all running programs would have to write some sort of usage db, or touch a global file, or a lot of other things that I don't think are going to fly. > : 1c. Distinctions like "alpha", "beta", and "stable" need to be made > : according to some convention (a la
Re: [netlabs #634] GC Bench: Linked-list for free header list[APPLIED]
On 29 May 2002, Mike Lambert wrote: > # New Ticket Created by Mike Lambert > # Please include the string: [netlabs #634] > # in the subject line of all future correspondence about this issue. > # http://bugs6.perl.org/rt2/Ticket/Display.html?id=634 > > > > Peter recently submitted a patch to RT that uses a linked-list for free > headers. Here are before and after results: > > before after > gc_alloc_new 4.1559994.016 > gc_alloc_reuse16.574 12.648002 > gc_generations4.025 3.975001 > gc_header_new 3.686 3.986 > gc_header_reuse 5.5779994.175998 > gc_waves_headers 3.8150023.595999 > gc_waves_sizeable_data8.3830028.381999 > gc_waves_sizeable_hdrs5.668 5.396999 > > We win on the header-intensive stuff. Not sure why it would be slower on > the gc_header_new tests. My best guess is that we know are touching the > contents of the buffer header, which we weren't doing before. And when we > allocate a bunch of new headers, we have to explcitly free them all, which > involves touching the first pointer of every buffer in that memory, as > opposed to one pointer in the Parrot_allocated memory we used before. > > IMO, the gc_alloc_reuse and gc_header_reuse benchmarks more than > outweigh gc_header_new. > > The portion of Peter's patch to do just this change is included below. > > Mike Lambert > Applied, thanks.
Re: 6PAN (was: Half measures all round)
On 6/4/02 12:59 PM, "Steve Simmons" <[EMAIL PROTECTED]> claimed: >> It shouldn't be required that all tests pass, however. A statement showing >> what platforms they pass on and what platforms they don't at the top of the >> download page would be good enough. But the tests have got to be there. > > Actually, for 6PAN I think they should have to pass. And maybe we > need a bug submission setup, and status checks, and . . . OK, OK, I'll > stop now. They're nice ideas, but who bells the cat? The again, if > Tim O'Reilly wants to fund me I'd be happy to do it. :-) On what platform(s)? Who's going to pay for the test bed for every possible combination of perl version, OS, various libraries, etc., etc.? I think that *requiring* that all tests pass is unrealistic. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: 6PAN (was: Half measures all round)
On 6/4/02 3:59 PM, Steve Simmons wrote: >> : 1c. Distinctions like "alpha", "beta", and "stable" need to be made >> : according to some convention (a la $VERSION...perhaps $STATUS?) >> >> Can probably burn that bridge when we get to it. > > Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state. > An author could make a package available that was in that condition, > but it shouldn't be uploaded to 6PAN. Once one has that restrition, > $STATUS isn't really needed. The adventurous will upload the alpha > code from the author and install it into the 6PAN tree by specifying some > sort of `force' flag. Thereafter, our adventurere is on his own. Nah, I think it's useful to be able to upload "unstable" versions to 6PAN to get the widest possible audience of testers. It's a lot easier than hosting it on a web site or whatever--for both the developer and the users. Obviously the 6PAN shell would install "latest stable" by default, but interested parties could get a glimpse of the future if they wanted, and with no harm done to existing code. Also think about the ramp-up to the first stable release. Users may want to try out all the pre-stable versions because they're better than nothing, even if they understand that there I no "API contract" until the first stable release. > On Tue, Jun 04, 2002 at 11:13:53AM -0700, Austin Hastings wrote: >> The following examples of font names are derived from the screen fonts >> shipped with the X Consortium distribution. >> >> Charter 12 pt ... >> -Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1 >> Charter Bold 12 pt ... >> -Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1 >> Charter Bold Italic 12 pt ... >> -Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1 >> Charter Italic 12 pt ... >> -Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1 > . . . > > I was about to run screaming from the room until reading the item a bit > closer. No no, you should still run screaming :) > My current understanding (my hope) is that just saying > > use foo; > > always gets you the latest foo. With (potentially) many modules having > the same name and multiple authors/versions, the current complexity of > the perl /lib tree could increase to the third power. That gonna be > very disk-intensive for every frigging perl script that runs. See my earlier framework/bundle suggestion. I don't think it's that bad, disck-access-wise. > The current perl module tree is pretty difficult for the average day to > day scripter to comprehend. I'd go even further and say that it's so > complex as to be unmanagable. Encapsulating by module would make the structure pretty easy to understand, IMO. > In re putting everything for a given module into a given directory -- > it's a good thought, but I foresee problems with shared libraries > (.so files). With a gigantic module like the Tk:: core, you don't always > want multiple copies of each shared lib for each Tk:: version. It just > ain't gonna fly. Disk space and RAM are cheap and getting cheaper. Think about what you mean by "gigantic." Anyone who exhausts memory by running 150 different versions of the Tk module at once deserves what they get ;) > On the other hand, there's no reason that shared libs couldn't be stored in a > standard location and symlinked to. Yes there is: sanity! I think that's a foolish optimization. It makes things much too fragile. Stuff like that already drives me nuts in regular Unix OS/app installations. -John
Re: Half measures all round
On Tue, Jun 04, 2002 at 03:53:18PM +0100, Dave Mitchell wrote: > One word: CPAN. For what it's worth, I'm looking forward to porting my 50-odd modules to Perl 6. In a lot of cases, I'll finally be able to remove some awful hacks. -- This sig file temporarily out of order.
Re: Half measures all round
Schwern wrote: > For what it's worth, I'm looking forward to porting my 50-odd modules to > Perl 6. In a lot of cases, I'll finally be able to remove some awful hacks. And I'll be porting most of my 30 or so (not the Perl6:: ones, obviously). There. Nearly 3% of the CPAN ported in two fell swoops! ;-) Damian
RE: Half measures all round
Damian Conway:
# Schwern wrote:
#
# > For what it's worth, I'm looking forward to porting my
# 50-odd modules
# > to Perl 6. In a lot of cases, I'll finally be able to remove some
# > awful hacks.
#
# And I'll be porting most of my 30 or so (not the Perl6::
# ones, obviously).
#
# There. Nearly 3% of the CPAN ported in two fell swoops! ;-)
Why bother? You've already put P::RD and T::B effectively in the core!
;^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
Re: Half measures all round
On 6/4/02 4:08 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed: > Why bother? You've already put P::RD and T::B effectively in the core! > ;^) And Switch. And Next? And Q::S? Larry, have you decided on that one yet? :-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Half measures all round
Brent wrote: > # And I'll be porting most of my 30 or so (not the Perl6:: > # ones, obviously). > > Why bother? You've already put P::RD and T::B effectively in the core! Not to mention Switch and Attribute::Handlers and Class::Contract and Class::Multimethods and Filter::Simple and Inline::Files. And eventually maybe even NEXT and Text::Reform and Quantum::Superpositions. Yes, my cunning plan is revealed: Perl 6 is nothing but a plot to reduce the number of modules I have to maintain! ;-) Damian
Re: 6PAN (was: Half measures all round)
[This seems like a good time to post something that's been on my mind for some time.] SUMMARY The world needs a really easy CPAN client. Here's one design for such a thing. DETAILS A few brief philosphical points: 1) People like languages that have tons of built-in doohickeys. See PHP and Java. 2) Instead of a huge standard library, a really easy to use CPAN client allows programmers to have the world of modules almost as easily as built-in, and with the advantage of up-to-date-ness and quantity. 3) The current CPAN.pm isn't really easy to use. Now matter how simple it may seem to the Perl Guru community, inexperienced users find it intimidating to download CPAN modules. Remember: beginners end up ruling the world. See Microsoft. Solution: a simple program that is called from the command line. Here's a brief tour: Download and install a module from CPAN. Loading a module also automatically loads its dependencies. cpan load Date::EzDate The command above would ask the user if they want to install using the current directory as the root of library tree, and is also mentions that if they want to specify another dir they can use this command: cpan --lib ~/lib load Date::EzDate Update a module. cpan update Date::EzDate Don't download dependencies: cpan --dep 0 load Date::EzDate Update all currently installed modules: cpan update * Update a namespace: cpan update Date::* Get help on using cpan: cpan help No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate Get from a particular FTP server cpan --server cpan.idocs.com load Date::EzDate By default, progress messages are kept to a minimum. No more of those hundreds of lines of bewildering make messages. cpan --lib ~/perllib load Date::EzDate finding server downloading module determining dependencies downloading dependencies installing done Optional verbose mode cpan --verbose load Date::EzDate (hundreds of lines of lovely make messages) Request particular operating system compilation (e.g. Win32) (usually not needed explicitly because cpan.pl will know which compilation to ask for) cpan --compile win32 load Date::EzDate Indicate latest development vs. latest stable cpan --latest beta load Date::EzDate Remove a module cpan remove Date::EzDate - Other Misc CPAN Ideas - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... - Run-time dependencies: Dependencies can be indicated explicitly with something like this: use Dependency Date::Language::French; - CPAN conformity: All modules served from CPAN must meet certain specifications. They must include a version, POD, license statement, and probably other meta-info. The meta-info would be standardized so that the system could tell that the module conforms. - Automated load balancing: cpan.perl.org doesn't have to pay for the bandwidth of the whole world. cpan.pl should recognize a command from CPAN.org to redirect to another server. - 6pan.org: The domain name 6pan.org is available as of this writing. Larry, are you planning on saying "6PAN" enough to merit somebody registering 6pan.org?
Re: 6PAN (was: Half measures all round)
Hmm... I like it. It took me a good 6 months before I learned how to use CPAN. I don't see how your proposal is that different from: alias cpan='perl -MCPAN -e shell' But I get the idea. Someone (well, you've inspired me now, so I) could write a perl5 equivilent, because command line is quite nice. I'll see how it flies with my next class. More comments below. On Tue, 4 Jun 2002, Miko O'Sullivan wrote: > [This seems like a good time to post something that's been on my mind for > some time.] Sure. It's been pretty dull around here. > DETAILS > > A few brief philosphical points: > > 1) People like languages that have tons of built-in > doohickeys. See PHP and Java. See Perl 5 (though PHP and Java far exceed it, in doohickeys) > 2) Instead of a huge standard library, a really easy to use CPAN > client allows programmers to have the world of modules almost > as easily as built-in, and with the advantage of up-to-date-ness > and quantity. Indeed. And it should be _really_ easy to install to a different source tree and have Perl use it. I want more modules on systems I don't administrate, and asking for them is a pain. > The command above would ask the user if they want to install using the > current directory as the root of library tree, and is also mentions that if > they want to specify another dir they can use this command: > >cpan --lib ~/lib load Date::EzDate Hmm... yeah, I think that's as easy as library root's gonna get. I like C better than C, though. > Don't download dependencies: > >cpan --dep 0 load Date::EzDate So, what's the difference between --dep 2 and --dep 3? Is that depth or something? Or max number? > Update all currently installed modules: > >cpan update * Oh, if only shells could DWIM... Naturally this would do cpan update and then every file in the current directory. To remedy this you have to do some awful thing like: cpan update \* or cpan update '*' Maybe 'all' would serve the purpose better. > Update a namespace: > >cpan update Date::* I like that idea a lot. > Get help on using cpan: > >cpan help Err, howsabout the GNU way... cpan --help > No configuration files (.e.g .cpan) are necessary. However, you can use a > configuration file if you want tp indicate a .cpan-like file > >cpan --conf ~/.cpan load Date::EzDate What about no configuration file if ~/.6pan's not there, and ~/.6pan if it is. > By default, progress messages are kept to a minimum. No more of those > hundreds of lines of bewildering make messages. > >cpan --lib ~/perllib load Date::EzDate >finding server >downloading module >determining dependencies >downloading dependencies >installing >done We could just go with the idiomatic "don't say anything unless it's bad." I've developed a taste for that. Perhaps this is better for the default and you can enable quiet through ~/.6pan. > - > Other Misc CPAN Ideas > > - Authors don't need to indicate dependencies. CPAN figures it out from the > use's and require's. CPAN will not accept modules that depend on other > modules that aren't on CPAN. (Yes, there might be a chicken and egg problem > there, I'm sure we can find a solution.) This leads me to... What about version discrepancies? I guess that can come from the Cs. > - Automated load balancing: cpan.perl.org doesn't have to pay for the > bandwidth of the whole world. cpan.pl should recognize a command from > CPAN.org to redirect to another server. Definitely. I like on-6pan mirrors better than on-client mirrors. About the name 6PAN... I mean it reads well, but does it mean anything? The, er, 6 Perl Archive Network? RCPAN? Really Comprehensive Perl Archive Network? :) Or just PAN? I got nuthin'. Luke
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 10:48:06PM -0600, Luke Palmer wrote: > Hmm... I like it. It took me a good 6 months before I learned how to use > CPAN. I don't see how your proposal is that different from: > > alias cpan='perl -MCPAN -e shell' CPAN.pm already installs a cpan program for you that's exactly that. schwern@blackrider:/usr/local/src/CPAN/CPAN-1.61$ cat cpan #!/usr/bin/perl use CPAN; shell; As for the rest of the message, this all seems to already exist, in one form or another, in the CPAN shell or CPANPLUS shell. If you want to see a better CPAN shell, don't wait for Perl 6! Help the CPANPLUS folks out now! http://cpanplus.sourceforge.net/ > But I get the idea. Someone (well, you've inspired me now, so I) could > write a perl5 equivilent, because command line is quite nice. I'll see > how it flies with my next class. > > More comments below. > > On Tue, 4 Jun 2002, Miko O'Sullivan wrote: > > > [This seems like a good time to post something that's been on my mind for > > some time.] > > Sure. It's been pretty dull around here. > > > DETAILS > > > > A few brief philosphical points: > > > > 1) People like languages that have tons of built-in > > doohickeys. See PHP and Java. > > See Perl 5 (though PHP and Java far exceed it, in doohickeys) > > > 2) Instead of a huge standard library, a really easy to use CPAN > > client allows programmers to have the world of modules almost > > as easily as built-in, and with the advantage of up-to-date-ness > > and quantity. > > Indeed. And it should be _really_ easy to install to a different source > tree and have Perl use it. I want more modules on systems I don't > administrate, and asking for them is a pain. > > > The command above would ask the user if they want to install using the > > current directory as the root of library tree, and is also mentions that if > > they want to specify another dir they can use this command: > > > >cpan --lib ~/lib load Date::EzDate > > Hmm... yeah, I think that's as easy as library root's gonna get. I like > C better than C, though. -- This sig file temporarily out of order.
Re: 6PAN (was: Half measures all round)
On Tue, 4 Jun 2002, Luke Palmer wrote: > On Tue, 4 Jun 2002, Miko O'Sullivan wrote: > > > No configuration files (.e.g .cpan) are necessary. However, you can use a > > configuration file if you want tp indicate a .cpan-like file > > > >cpan --conf ~/.cpan load Date::EzDate > > What about no configuration file if ~/.6pan's not there, and ~/.6pan if it > is. Personally, I'd like it to: 1) work just fine without a config file, 2) if I specify one, it uses that, 3) if I don't specify one, but the default exists, it uses that 4) if it uses a config file (specified or default) it shows the full path to what it's using, so that I have a chance of detecting Trojans and typos if I'm paying attention (I don't need or want it to ask for confirmation, just show a message and maybe 'sleep 1' before continuing) > > - Authors don't need to indicate dependencies. CPAN figures it out from the > > use's and require's. CPAN will not accept modules that depend on other > > modules that aren't on CPAN. (Yes, there might be a chicken and egg problem > > there, I'm sure we can find a solution.) This leads me to... > Having it figure out the dependencies is definitely a major plus. As to how to solve the chicken-and-egg...just provide a way to upload multiple separate modules simultaneously. Dave
PATCH for Win32 lib/Parrot makefile woes
Fixes the problem where the toplevel makefile can't descend into lib/Parrot to do the build necessary for PackFile and friends. Also I think the single cd .. may potentially be a bug for other platforms as well. Apply this and re-run Configure.pl and all is well. --- config/gen/makefiles/root.in_oldTue Jun 04 15:45:49 2002 +++ config/gen/makefiles/root.inTue Jun 04 15:42:42 2002 @@ -408,7 +408,7 @@ #newasm : $(TEST_PROG) lib/Parrot/.dummy lib/Parrot/.dummy : - cd lib/Parrot && $(PERL) Makefile.PL && $(MAKE) && cd .. + cd lib && cd Parrot && $(PERL) Makefile.PL && $(MAKE) && cd .. && cd .. docs/.dummy : cd docs && $(MAKE) && cd ..
[RELEASE] Parrot 0.0.6 Leaves The Village
"Where am I?" "In the CPAN." "What do you want?" "Keyed acess." "Whose side are you on?" "That...would be telling. We want...keyed access." "You won't get it." "By hack or by crack... We will." "Who are you?" "The new pumpking." "Who is number 2?" "You are Version Six." "I am not a version, I am the final release!" [apologies to Patrick McGoohan] Welcome to version 0.0.6 of Parrot. Major changes in this release include a new assembler supporting the keyed access syntax, new macro syntax, new Configure scripts, a Parrot assembler written in Parrot, the C#-like language 'cola' with limited OOP support, and lots of new documentation. Some contributions include tetris.pasm and an implementation of LZW compression. As per usual, if you want to join in on the fun, start by downloading a copy of parrot-0.0.5 at CPAN at one of the following URLs (or a mirror): http://www.cpan.org/authors/id/J/JG/JGOFF/parrot_0.0.6.tgz http://www.cpan.org/src/parrot_0.0.6.tgz To get the latest CVS version: http://cvs.perl.org/ has the information you need. Once you've unpacked Parrot, build it as follows: perl Configure.pl make make test After you've done that, look at docs/parrot.pod to learn more about it. Discussion of Parrot takes place on the perl6-internals mailing list, and patches should be sent there as well. If you're not subscribed, look at: http://lists.perl.org/showlist.cgi?name=perl6-internals for tips on how to subscribe. CVS commit access is given out to developers who consistently submit good patches to the mailing list. Be Seeing You. -- Jeff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
