Re: Announce: Rakudo Perl 6 development release #20 (PDX)
2009/8/20 Kyle Hasselbacher kyl...@gmail.com: On behalf of the Rakudo development team, I'm pleased to announce the August 2009 development release of Rakudo Perl #20 PDX. Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. The tarball for the August 2009 release is available from http://github.com/rakudo/rakudo/downloads . As usual, binaries for Windows are available on http://parrotwin32.sourceforge.net/ , including the latest Parrot release and many other languages. Without the following patch, perl6 dynops cannot link on Windows (with ICU) : --- a/build/Makefile.in +++ b/build/Makefile.in @@ -38,7 +38,7 @@ OPS2C= $(PERL) $(PARROT_TOOLS_DIR)/build/ops2c.pl PMC2C= $(PERL) $(PARROT_TOOLS_DIR)/build/pmc2c.pl PMC2C_INCLUDES = --include src/pmc --include $(PARROT_SRC_DIR) --include $(PARROT_SRC_DIR)/pmc CINCLUDES= -I$(PARROT_INCLUDE_DIR) -I$(PARROT_INCLUDE_DIR)/pmc -LINKARGS = $(LDFLAGS) $(LD_LOAD_FLAGS) $(LIBPARROT) @libs@ +LINKARGS = $(LDFLAGS) $(LD_LOAD_FLAGS) $(LIBPARROT) @libs@ @icu_shared@ # rakudo directories DYNEXT_DIR = dynext Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we continue to recommend that people wanting to use or work with Rakudo obtain the latest source directly from the main repository at github. More details are available at http://rakudo.org/how-to-get-rakudo . Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. August 2009 is code named PDX for the Portland Perl Mongers. PDX.pm has been home to several Rakudo contributors (chromatic, Allison Randal, and more) and PDX.pm has held meetings that have produced feature and bugfix patches for Rakudo. Beginning with this release, Rakudo Perl builds from an installed Parrot instead of using Parrot's build tree. This release of Rakudo requires Parrot 1.5.0. For the latest information on building and using Rakudo Perl, see the README file section titled Building and invoking Rakudo. (Quick note: the --gen-parrot option still automatically downloads and builds Parrot as before, if you prefer that approach.) Also, unlike previous versions of Rakudo Perl, the perl6 (or perl6.exe) executables only work when invoked from the Rakudo root directory until a make install is performed. Running make install will install Rakudo and its libraries into the Parrot installation that was used to build it, and then the executables will work when invoked from any directory. Some of the specific major changes and improvements occuring with this release include: * Rakudo is now passing 12,369 spectests, an increase of 493 passing tests since the July 2009 release. With this release Rakudo is now passing 69.98% of the available spectest suite. * We now have a much cleaner traits implementation. Many of the Perl 6 built-in traits are now implemented in Perl 6, and user-defined traits can now be defined and applied to classes and roles. * The 'hides' trait on classes can make one class hide another. * Many not-yet-implemented operators and features now provide more helpful error messages instead of simply producing parse errors. * The ROADMAP has been substantially updated and includes some details regarding the Rakudo Star release [2]. * Embedded comments now require backticks (Perl 6 specification change). Since the Perl 6 specification is still in flux, some deprecated features will be removed from Rakudo. Prominently among those are: * '=$handle' is deprecated in favor of '$handle.get' (one line) and '$handle.lines' (all lines). * 'int $obj' is deprecated in favor of '$obj.Int'. The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode. The next release of Rakudo (#21) is scheduled for September 17, 2009. A list of the other planned release dates and codenames for 2009 is available in the docs/release_guide.pod file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. Have fun! References: [1] Parrot, http://parrot.org/ [2] Rakudo Star, http://use.perl.org/~pmichaud/journal/39411
Re: Announce: Rakudo Perl 6 development release #20 (PDX)
2009/8/20 Kyle Hasselbacher kyl...@gmail.com: Beginning with this release, Rakudo Perl builds from an installed Parrot instead of using Parrot's build tree. This release of Rakudo requires Parrot 1.5.0. For the latest information on building and using Rakudo Perl, see the README file section titled Building and invoking Rakudo. (Quick note: the --gen-parrot option still automatically downloads and builds Parrot as before, if you prefer that approach.) Okay, so I will try to package this version now. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: Custom object constructors
Kevan Benson wrote: Should there not be a way to define object constructors with custom signatures that can be usefully invoked like a normal constructor? Currently, defining a BUILD method for a class with a specific signature doesn't seem to allow for the object to be invoked by new with that signature and be correctly passed to the right BUILD method. It seems a whole chain of new - bless - BUILDALL - BUILD would need to be defined with specific signatures just to get a custom constructor. No. It's enough to write a method .new that calls bless, which in turn calls BUILDALL (which re-dispatches to BUILD) (sorry if I got the order wrong in that IRC conversation). Let's assume we define default new() method with signature (*...@p, *%n) that passes positional arguments to BUILD as BUILD(|@p, |%n), then we might not be able to call BUILD submethods from superclasses (because they don't expect any positional parameters), so you basically loose compatibility with any super classes by introducing positional parameters. Not a good idea. It seems much more sane as it is now, that is to modify only the signature of new new() methods, not of BUILD methods. Cheers, Moritz
Re: Custom object constructors
Moritz Lenz wrote: Kevan Benson wrote: Should there not be a way to define object constructors with custom signatures that can be usefully invoked like a normal constructor? Currently, defining a BUILD method for a class with a specific signature doesn't seem to allow for the object to be invoked by new with that signature and be correctly passed to the right BUILD method. It seems a whole chain of new - bless - BUILDALL - BUILD would need to be defined with specific signatures just to get a custom constructor. No. It's enough to write a method .new that calls bless, which in turn calls BUILDALL (which re-dispatches to BUILD) (sorry if I got the order wrong in that IRC conversation). Let's assume we define default new() method with signature (*...@p, *%n) that passes positional arguments to BUILD as BUILD(|@p, |%n), then we might not be able to call BUILD submethods from superclasses (because they don't expect any positional parameters), so you basically loose compatibility with any super classes by introducing positional parameters. Not a good idea. It seems much more sane as it is now, that is to modify only the signature of new new() methods, not of BUILD methods. Okay, I can accept that. Most of my objections seemed to stem from misunderstanding what can be done in .new (or stated more succinctly, what can be done *easily* in .new). I was under the impression that since it was before bless, operations like calling methods on the object might be harder to do, but it's nothing that can't be worked around. That said, I submit that it's a very confusing part of the language as defined currently, and I haven't seen a very thorough explanation of the purpose of each method in the chain the instantiates a new object. S12 touches upon them slightly, but not in enough detail that I was able to work out where I should be adding code to appropriately make alternate constructors. -- -Kevan Benson -A-1 Networks
Re: Custom object constructors
On Thu, Aug 20, 2009 at 10:44 PM, Kevan Benson kben...@a-1networks.comwrote: That said, I submit that it's a very confusing part of the language as defined currently, and I haven't seen a very thorough explanation of the purpose of each method in the chain the instantiates a new object. S12 touches upon them slightly, but not in enough detail that I was able to work out where I should be adding code to appropriately make alternate constructors. Now that you apparently understand it, do you have a suggestion on how S12 might be phrased differently? I must admit that I don't quite grasp the concepts here yet, so an alternate wording might help others as well. Thanks for bringing the question up. -- Jan
Invitation: P6 Hackathon @ Sat Aug 29 2pm – 4pm (p erl6-langu...@perl.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20090829T19Z DTEND:20090829T21Z DTSTAMP:20090820T151226Z ORGANIZER;CN=Art Schmidt:mailto:fri...@gmail.com UID:qt61sce1nod31kssr0ppu45...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;cn=fri...@gmail.com;X-NUM-GUESTS=0:mailto:fri...@gmail.com ATTENDEE;CUTYPE=GAIA_GROUP;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=dallas...@googlegroups.com;X-NUM-GUESTS=0:mailto:dallas...@googlegr oups.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=perl6-langu...@perl.org;X-NUM-GUESTS=0:mailto:perl6-langu...@perl.o rg CLASS:PRIVATE CREATED:20090819T032243Z DESCRIPTION:See the following for our tentative plan for the hackathon:\nht tp://s1n.dyndns.org/index.php/2009/08/13/perl-6-mini-hackathon/\nAny other ideas are quite welcome\, this is the first time we've done something like this\, so we won't claim to be experts or anything like that :-)\n\nThere w ill be free wifi and coffee.\n\nNote: we are including perl6l because this is the first time we've done something like this. We won't be emailing tha t list again so please join our mailing list (dallas...@googlegroups.com).\ n\nHopefully see you there!!\n-fREW\nView your event at http://www.google.c om/calendar/event?action=VIEWeid=cXQ2MXNjZTFub2QzMWtzc3IwcHB1NDU3b2cgcGVyb DYtbGFuZ3VhZ2VAcGVybC5vcmctok=MTYjZnJpb3V4QGdtYWlsLmNvbTc1NDgyYzgyZmJhZmNm OGJiYWZkMWVlZDFlNzgyNmUwMGFiODVjMTgctz=America%2FChicagohl=en. LAST-MODIFIED:20090820T151220Z LOCATION:Bottom floor of Borders on 75 Bethany SEQUENCE:0 STATUS:CONFIRMED SUMMARY:P6 Hackathon TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite.ics Description: application/ics
Re: Custom object constructors
Jan Ingvoldstad wrote:
On Thu, Aug 20, 2009 at 10:44 PM, Kevan Benson kben...@a-1networks.comwrote:
That said, I submit that it's a very confusing part of the language as
defined currently, and I haven't seen a very thorough explanation of the
purpose of each method in the chain the instantiates a new object. S12
touches upon them slightly, but not in enough detail that I was able to work
out where I should be adding code to appropriately make alternate
constructors.
Now that you apparently understand it, do you have a suggestion on how S12
might be phrased differently?
I must admit that I don't quite grasp the concepts here yet, so an alternate
wording might help others as well.
Thanks for bringing the question up.
Unfortunately I'm not at all confident I do understand it all, but I'll
explain how I think it works and people more knowledgeable than me will
hopefully step in and explain where I'm wrong. Maybe out of this we can
get some consensus on what needs to be added WRT object constructors in S12.
The creation sequence looks something like this:
.new(args) {
my $self = .bless(class, {
.BUILDALL(class, args) {
# in reverse MRO
for (@parent) { .BUILD(class, args) }
.BUILD(class, args)
}
}
Note: Actually, I believe the current .BUILD is actually called as part
of the call to all parent .BUILD methods in Rakudo. At least that's
what I'm able to infer from the parrot code for Rakudo objects at
src/classes/Object.pir starting at line 272 (thanks japhb!).
.new - Handles the actual call to .new from code, define other
submethods/methods for this if you want to create alternate
constructors. You should normalize all paramaters to named values
before calling .bless. S12 implies that any .new you write (or a
constructor of any other name you define) must call .bless.
.bless - See S12
(http://perlcabal.org/syn/S12.html#Construction_and_Initialization) for
more info, but this is responsible for actually creating the object
(unless .CREATE called before and opaque object passed) and calling the
BUILD routines.
.BUILDALL - If it's still valid, http://dev.perl.org/perl6/rfc/189.html
seems to cover the expected behavior of this.
.BUILD - Used for object initialization, assigning passed named values
(pairs) to object attributes if they match, or doing something more
complex to initialize the object correctly based on supplied data.
Some things to be wary of or that I'm still hazy on:
What sort of calling syntax can be used in .new since the object isn't
yet blessed? Or since .new encapsulates .bless (right?), I guess you
can call normally AFTER the bless.
.new happens before calling parent constructors, .BUILD happens after,
so .new possibly won't have access to some default attributes as defined
by parent classes/roles.
Theoretically you could define a custom constructor, normalize data,
call the regular .new constructor, and post process on the object
returned before returning it yourself, I think.
--
-Kevan Benson
-A-1 Networks
MMD bug or what?
Hi there,
I `m looking into MMD, example:
multi t (@a) {1}
multi t (Array $a) {2}
multi t (Positional $a) {3}
multi t (Positional[Array] $a) {4}
say t(a b c)
1
say t(Array.new)
2
my $foo does Positional; say t($foo)
1
my @a; say t(@a)
2
I am expected some sort of ambiguous there.
Thank you!
Ihrd
patch for t/spec/s06-multi/type-based.t
Hi there,
trivial patch in attach.
(11:47:29 AM) ihrd: it type-based.t we have
(11:47:50 AM) ihrd: multi foo (@bar) { Array ~ join(', ', @bar) }
(11:48:24 AM) ihrd: and is(foo(@array), 'Array foo, bar, baz',
'dispatched to the Array sub');
(11:48:47 AM) Jonathan Worthington: nod
(11:49:07 AM) ihrd: I am not quite sure, but it looks wrong for my now
...
(11:50:10 AM) Jonathan Worthington: Yeah, the comment is probably a bit off.
(11:50:12 AM) Jonathan Worthington: Yeah
(11:50:18 AM) Jonathan Worthington: Feel free to tweak it to say
Positional not Array.
(11:50:43 AM) Jonathan Worthington: Positional is more accurate there. :-)
Ihrd
Index: type-based.t
===
--- type-based.t (revision 28042)
+++ type-based.t (working copy)
@@ -13,8 +13,8 @@
multi foo (Bool $bar) { Bool ~ $bar }
multi foo (Regex $bar) { Regex ~ WHAT( $bar ) } # since Rule's don't stringify
multi foo (Sub $bar) { Sub ~ $bar() }
-multi foo (@bar) { Array ~ join(', ', @bar) }
-multi foo (%bar) { Hash ~ join(', ', %bar.keys.sort) }
+multi foo (@bar) { Positioanl ~ join(', ', @bar) }
+multi foo (%bar) { Associative ~ join(', ', %bar.keys.sort) }
multi foo (IO $fh) { IO }
is(foo('test'), 'Str test', 'dispatched to the Str sub');
@@ -27,10 +27,10 @@
is(foo(sub { 'baz' }), 'Sub baz', 'dispatched to the Sub sub');
my @array = ('foo', 'bar', 'baz');
-is(foo(@array), 'Array foo, bar, baz', 'dispatched to the Array sub');
+is(foo(@array), 'Positional foo, bar, baz', 'dispatched to the Positional sub');
my %hash = ('foo' = 1, 'bar' = 2, 'baz' = 3);
-is(foo(%hash), 'Hash bar, baz, foo', 'dispatched to the Hash sub');
+is(foo(%hash), 'Associative bar, baz, foo', 'dispatched to the Associative sub');
is(foo($*ERR), 'IO', 'dispatched to the IO sub');
Re: $*CWD and chdir()
On Wed, 19 Aug 2009, Timothy S. Nelson wrote:
..but Perl is more magic than bash :). Seriously, I can see both
sides of the argument, and I'm leaning towards the $*CWD = chdir idea (as an
option if people want to use it), but I realise that a lot of people are
leaning the other way. So I'll argue for it, but don't care if I lose :).
I want both.
I can have both. Or in fact all three:
$*CWD = foo;# exception -- $*CWD isn't writable
use Cwd :fake;
$*CWD = foo;# OK, faking it
use Cwd :chdir;
$*CWD = q/tmp; # OK, same as {chdir /tmp}
I wonder if this is becoming the new Perl mantra use lexically scoped
pragmata.
perl6 -MCwd=fake ... # legacy behaviour
-Martin
