A note for test writers
Folks, Please always verify test results, don't use the Parrot output of the test as the expected output. If you are implementing a new feature, write the *test first*. Thanks, leo PS from r13305: @@ -1324,7 +1324,7 @@ set P2, 300 # .Integer set P3, 246.246 # .Float div P2, P2, P3 - eq P2, 1, EQ4 + .fp_eq( P2, 1.218293, EQ4) 300 / 246.246 just isn't 1 exactly
Parrot 0.4.5 Released!
On behalf of the Parrot team I'm proud to announce another monthly release of Parrot. I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages, see http://www.parrotcode.org/ for more information. Parrot 0.4.5 changes and news - unicode subroutine names - hierarchical class names finished including MMD support - new dotnet CLI to PIR translator - improved TGE code and compiler - APL: vector handling - new STM branch in the svn repository - the usual bugfixes and enhancements After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.4.5.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Parrot 0.4.4 Feather Released!
On behalf of the Parrot team I'm proud to announce another monthly release of Parrot. I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages, see http://www.parrotcode.org/ for more information. Parrot 0.4.4 changes and news - hierarchical class names - APL compiler - under development - understands simple vector ops, strings - demonstrates use of Unicode in Parrot - pgc, a compiler for rules and operator precedence parsers - Major redesign and improvements for PGE - compilers understand named parameter options - :ratchet option implemented to support non-backtracking quantifiers - TGE (tree grammar engine) for tree transformations - tgc, tree grammar compiler - perl6 compiler - support for many operators, lexical scalars, regex matches - new pheme (Parrot scheme) compiler After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.4.4.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Parrot 0.4.3 Cold Conure Released
On behalf of the Parrot team I'm proud to announce another monthly release of Parrot. I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages, see http://www.parrotcode.org/ for more information. Parrot 0.4.3 changes and news - namespaces partially implemented - rulec, Perl6 rule compiler - PGE improvements including return values for closure - parts of a Perl6 parser based on PGE - complex trigonometric methods - type of Sub PMC is now overridable by HLL - NetBSD support - many bug fixes and improvements After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.4.3.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Parrot 0.4.2 GPW Released!
On behalf of the Parrot team I'm proud to announce another 1.5 monthly release of Parrot. GPW is the German Perl Workshop, which will take place next week. I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages, see http://www.parrotcode.org/ for more information. Parrot 0.4.2 changes and news - improved PPC and x86 JIT support including JIT compilation of very simple PASM/PIR subroutines - preliminary libreadline support - better trace and debug features - pkgconfig support - META.yml to support proper indexing on CPAN - new opcode: hcf (in my_ops in dynamic op library) - new File pmc for file specific ops (is_dir, is_file, copy, rename...) - named arguments and parameters (both :named() and = syntaxes) - ongoing config improvements - tons of bug fixes and other small improvements - too much to list all After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.4.2.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Parrot 0.4.0 Luthor Released!
On behalf of the Parrot team I'm proud to announce another major release of Parrot. More than 530 svn checkins and 1000 added tests by numerous folks bump up the version to 0.4.0. I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages, see http://www.parrotcode.org/ for more information. Parrot 0.4.0 changes and news - New lexical handling and closure support including better introspection for caller and outer - PGE (Parrot Grammar Engine) provides now compilers for P6Rule, P6Grammar, P5Regexp, and Glob - ca. 1000 new tests including 800 for Perl5 regexp - Improved unicode charset and encoding support - Calling conventions for exception handlers - Punie (Perl 1) uses TGE (Tree Grammar Engine) to convert from PGE match objects to AST via two steps of tree transformation grammars - New languages: amber and lua - The usual code fixes, cleanup, and improvements, including an overhaul of the config and test framework After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.4.0.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Re: Perl 6 Summary for 2005-11-14 through 2005-11-21
On Nov 23, 2005, at 3:06, chromatic wrote: On Wed, 2005-11-23 at 01:39 +0100, Leopold Toetsch wrote: But my argument was: whenever you start introspecting a call frame, by almost whatever means, this will keep the call frame alive[1] (see Continuation or Closure). That is: timely destruction doesn't work for example... Destruction or finalization? We don't have these two separated yet, but it wouldn't matter. Both can only happen after the GC has decided that the object is unreferenced. That is, if I have a filehandle I really want to close at the end of a scope but I don't care when GC drags it into the void, will the close happen even if there's introspection somewhere? *If* introspection sets the life bit (increments refcount) of the refered item(s) then destruction/finalization can only happen, after that introspection object is also dead. It's the same as: when you store a filehandle into an array, the filehandle will be bound to the life period of that array. The problem now is that there isn't any guarantee that such an introspection PMC stays in that call frame, the function could just return it to the caller (or store it into globals) as any other PMC. Which implies that the whole call chain (with its contents) would have to be kept alive. -- c leo
Re: Perl 6 Summary for 2005-11-14 through 2005-11-21
On Nov 22, 2005, at 1:40, Matt Fowles wrote: Call Frame Access Chip began to pontificate about how one should access call frames. Chip suggested using a PMC, but Leo thought that would be too slow. No, not really. It'll be slower, yes. But my argument was: whenever you start introspecting a call frame, by almost whatever means, this will keep the call frame alive[1] (see Continuation or Closure). That is: timely destruction doesn't work for example and the introspection feature is adding another level of complexity that isn't needed per se, because 2 other solutions are already there (or at least implemented mostly). leo [1] a call frame PMC could be stored elsewhere and reused later, refering to then dead contents. Autrijus mentioned that this will need weak references to work properly.
Re: This week's summary
On Nov 15, 2005, at 17:24, The Perl 6 Summarizer wrote: The Perl 6 Summary for the fortnight ending 2005-11-13 string_bitwise_* Leo, it seems to boil down to a choice between throwing an exception or simply mashing everything together and marking the 'resulting bit mess' as binary. Warnock applies. I've today cleaned up the string_bitwise code a bit. These rules apply now: - usage of non-fixed_8 encoded strings in binary string ops throws an exception - else the result string has charset binary, fixed_8 encoded. Thanks again for your concise summaries, leo
Parrot 0.3.1 Wart Released
On behalf of the Parrot team I'm proud to announce the release of
Parrot 0.3.1. I'd like to thank all involved people as well as our
sponsors for supporting us.
What is Parrot?
Parrot is a virtual machine aimed at running Perl6 and other dynamic
languages.
Parrot 0.3.1 changes and news
- Variable sized register frames are finished. Each subroutine gets
the amount of registers that it actually needs. No more spilling.
- Vastly improved PGE (Parrot Grammar Engine) including shift-reduce,
precedence-based expression parser and support for matching of
bracketed text delimited by e.g. ()[]{}'
- uniccode character classification (is_upper ...)
- support for heredoc syntax in assembler
- improved examples, basic JSON support
- debian packaging support
- the usual improvements, bug fixes, and cleanup
- test count exceeds 3000
After some pause you can grab it from
http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.3.1.tar.gz.
As parrot is still in steady development we recommend that you
just get the latest and best from SVN by following the directions at
http://www.parrotcode.org/source.html
Turn your web browser towards http://www.parrotcode.org/ for more
information about Parrot, get involved, and:
Have fun!
leo
Re: Perl 6 Summary for 2005-09-26 through 2005-10-02
On Oct 5, 2005, at 1:17, Matt Fowles wrote: Here Doc in PIR Will Coleda revived a thread from February about PIR here doc syntax. Looks like the syntax is ok. Jonathan Worthington has already implemented here doc syntax. Data::Escape::String Dislikes Unicode Will noticed that Data::Escape::String doesn't work on Unicode strings. This is fixed. Calling Vtable Functions from PIR Roger Browne found he can no longer call vtable functions from PIR directly. Leo felt that it was no longer necessary, The 'Vtable' function actually was a MMD infix function (__add) - I should have mentioned this in the first place. 'is no longer necessary' isn't quite correct. Usually there is no need to call any of these builtins directly, as Parrot's MMD system handles operator overloading. And finally: the bug is fixed. Thanks for the summary, leo
Parrot 0.3.0 Alex Released!
On behalf of the Parrot team I'm proud to announce the release of Parrot 0.3.0. I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.3.0 changes and news - New calling conventions implemented: see PDD03 for details - Merge multiple Parrot bytecode (PBC) files into a singe PBC file - 'make smoke' target going beta - bc now supports if statements, comparison ops, prefix inc/dec - ParTcl adds [lassign], [switch] (partially); [expr] converted to a compiler - Many exciting doc updates, tests, and bugfixes, too numerous to mention After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.3.0.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Re: Perl 6 Summary for 2005-08-15 through 2005-08-22
On Aug 23, 2005, at 3:43, Matt Fowles wrote: Perl 6 Summary for 2005-08-15 through 2005-08-22 Java on Parrot I vote for Jot. That's already occupied by another language http://en.wikipedia.org/wiki/Iota_and_Jot. Perl 6 Language Type Inferencing in Perl 5 Autrijus (while discussing type inference in Perl 6) recalled that there was a google summer of code project on Type Inferencing in Perl 5. Gary Jackson, the summer coder, provide a more detailed description of his work. http://search.cpan.org/~bargle/Devel-TypeCheck-0.01/lib/Devel/ TypeCheck.pm Thanks for the summary, leo
Parrot 0.2.3 Serenity Released!
Parrot 0.2.3 Serenity Released! On behalf of the Parrot team I'm proud to announce another monthly release of Parrot and I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.2.3 changes and news - Dynamic classes now compile on Windows (including ParTcl) - New Super PMC allows easy access to superclass methods - Implement C3 method resolution order (just like Perl6 Python) - ParTcl has new PIR-based parser and passes more Tcl tests - added character class support in Globs to PGE - added language implementations of unlambda, Lazy-k - many bugfixes, including GC and memory leaks - the new calling scheme continued to evolve in branches/leo-ctx5 After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.2.3.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html
Parrot 0.2.2 Geeksunite Released!
Parrot 0.2.2 Geeksunite Released! On behalf of the Parrot team I'm proud to announce another monthly release of Parrot and I'd like to thank all involved people as well as our sponsors for supporting us. Please visit http://geeksunite.org and support Chip. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.2.2 changes and news - partial implementation of the new calling conventions PASM only, don't mix PIR foo() call syntax with the new scheme - grammar and rule support in PGE - the Parrot Grammar Engine - TCL passes 10% of the tcl test suite - the usual bugfixes and improvements After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.2.2.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Parrot 0.2.1 APW Released!
Parrot 0.2.1 APW Released! On behalf of the Parrot team I'm proud to announce another monthly release of Parrot and I'd like to thank all involved people as well as our sponsors for supporting us. The release name stands for Austrian Perl Workshop, which will take place on 9th and 10th of June in Vienna. It will have a french connection that is a live video stream to the French Perl Workshop happening at the same time. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.2.1 changes and news - better HLL support (short names for object attributes, and .HLL and n_operators pragmas) - string encoding and charset can now be set independently - experimental mmap IO layer for slurping files - distinct debug and trace flag settings - glob support in PGE - new character classification opcodes and interfaces After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.2.1.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Re: [PATCH] Fix 3 of the spawnw.t failures.
Nigel Sandever [EMAIL PROTECTED] wrote: Thanks, applied - r8263 Further thoughts on the questions in comments invited. Yeah. njs leo
Re: Object Numify/Stringify-ing to Unique values
Autrijus Tang [EMAIL PROTECTED] wrote: What does unboxed values return for their id, though? 3 =:= 3; # always true? 3.id ~~ 3.id; # ditto? Maybe true or not, that's highly implementation dependent. I'd not touch these internals: $ python Python 2.4 [...] id(2) == id(1+1) True id(200) == id(100+100) False hash(2) == hash(1+1) True hash(200) == hash(100+100) True id(-5)==id(-2-3) True id(-6)==id(-3-3) False Parrot could also cache small integers like Python does but it's by far too early to dig into that. If we want some interoperbility with Python dicts, hashing will not be done on ids but on the hash function of the type. Thanks, /Autrijus/ leo
[PROPOSAL] call syntax abstraction
array like now
params SS, S0, S1 # at least two string arguments
params S?SS, S0, S1, S2 # 1...3 string arguments
params IS, I20, S2 # 1st param as int, string
=head1 Implementation notes
=head2 Steps
=over 4
=item * The opcodes translate their arguments according to the current
calling conventions.
=item * PIRs call/return syntax shortcuts emit the new opcodes
=item * New Parrot API to access call related stuff replaces current explicit
register access
=item * convert existing PASM code to use new opcodes
=back
Abstraction finished.
=head2 Implementations details:
The new opcodes get some support by the ops-file compiler. The basic
layout is:
op args(inconst STR) {
// internal variable declarations
// user code
VA_SWITCH { // big loop and switch
case 'I': i = $N_I; // get Nth arg as INTVAL
break;
case 'i': i = $N_i; // get Nth arg as INTVAL constant
break;
case 'P': p = $N_P; // get Nth arg as PMC
break;
...
}
// user code
goto NEXT(2+N);
}
The VA_SWITCH is something like:
STRING *sig = $1;// internal variable declaration
size_t n, l;
char *p;
for (n = 0, p = sig-strstart, l = sig-strlen; n l; ++n, ++p) {
switch(*p) {
// case statements go here
}
}
The $N_I gets according to the IOpTrans/*.pm expanded to something
like:
IREG(2+n) aka REG_INT(cur_opcode[2+n])
similar to the current $1, $2, ...
=head1 AUTHOR
Leopold Toetsch
=head1 SEE ALSO
Fdocs/pdds/pdd03_calling_conventions.pod
Parrot 0.2.0 NLnet Released!
Parrot 0.2.0 NLnet Released! On behalf of the Parrot team I'm proud to announce the release of Parrot 0.2.0 and I'd like to thank all involved pepole as well as our sponsors for supporting us. It's a pleasure and honor for me to be able to advertise (after 0.1.0) the next leap release 0.2.0 with almost complete MMD support. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.2.0 changes and news * parrot repository is now under subversion * MMD (Multi Method Dispatch) refactored * new unary and infix opcodes that return new result PMCs * dynamic scalar PMCs inherit now almost all from Parrot core PMCs * more unification of PMCs and ParrotObjects * tailcalls for functions and methods * PGE (Parrot Grammar Engine) reworked * Pugs creates Parrot code and Pugs is a registered Parrot compiler * new languages/lisp * the usual bug fixes and improvements After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.2.0.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Re: reduce metaoperator
Larry Wall [EMAIL PROTECTED] wrote: It would be nice to have an easy-to-access What's this? interface that could be stitched into your favorite editor to identify what's under the cursor, or at least a command like: p6explain '[+]' s:p5/nice to have/absolutely necessary/ unless $self ~~ @larry; Could $EDITOR-p6explain use life information from the parser with the current context of the requested token? leo
Re: Sun Fortress and Perl 6
Autrijus Tang [EMAIL PROTECTED] wrote:
my sub get_book () of Hash of Array of Recipe {...}
my num @nums = Array of num.new(:shape(3;3;3));
Does Parrot's MMD carry this type information natively?
Neither of above. But:
multi sub foo(Int $a, Num $b) { ... }
aka
.sub foo @MULTI(Int, Num)
- creates a MultiSub PMC stored in the current namespace as foo
- stores the sub itself as [EMAIL PROTECTED]@Num and
- attaches that Sub PMC to the MultiSub
..., and Ponie can then
reuse the same name-mangling to call into Perl 6 subroutines.
Well, I presume that this could cover just the static case, which with
the absence of types in Perl5/Ponie, would make it impossible to call
multisubs.
Anyway Parrots MMD system depends on types. *If* the Perl6 compiler defines
above array as
cl = subclass FixedFloatArray, num_Array_shape_3_3_3
then this kind of array would be a distinct type. The other possiblity
is: we have one Multi_shaped_FloatArray, which takes an initializer with
the dimensions (see e.g. classes/multiarray.pmc) then all these shaped
num arrays would be one type, dispatching to the same routines.
Thanks,
/Autrijus/
leo
Re: alarm() and later()
Gaal Yahas [EMAIL PROTECTED] wrote: Two things popped up while implementing a demo version of alarm() today. 1. In perl5 and in most underlying libraries, alarm() has 1 second granularity 2. ..., in which you can pass an optional closure to alarm() I can't say anything about the actual Perl6 syntax, but Parrot provides sub-second resolution as well as alarm callbacks and of course multiple timers. leo
Re: How do I... tie hashes/arrays?
Larry Wall [EMAIL PROTECTED] wrote:
On Tue, Apr 19, 2005 at 02:02:41PM +, Ingo Blechschmidt wrote:
: # Possibility #2
: multi sub *postcircumfix:'[', ']'(TiedArray $self, $index) {
: # Body as above
: }
None of those are quite right, because you have to be prepared to deal
not only with slices, but with multiple dimensions of slices.
Then again the question arises, if all the possible indexed access isn't
clearer written as multi subs:
multi sub *postcircumfix:[ ](TiedArray $self, int $index) {...}
multi sub *postcircumfix:[ ](TiedArray $self, Int $index) {...}
multi sub *postcircumfix:[ ](TiedArray $self, Slice $index) {...}
multi sub *postcircumfix:[ ](TiedArray $self, MyDims $index) {...}
or with FETCH and STORE as distinct variants too, and r/w ...
That's the philosophy, anyway. It may yet turn out that proxying
completely fouls up the optimizer in this case. Sometimes a
cut-and-paste has the benefit of being concrete enough for the
optimizer to understand, whereas the abstraction is too, er, abstract.
Yep.
... However, that being
said, there's enough flexibility in the FETCH/STORE proxy that you
could defactor the identification code out to the various handlers
and get the same benefit.
Well, isn't the defactorized code just a bunch of multi subs?
Larry
leo
Re: nbsp in \s, ?ws and
Larry Wall [EMAIL PROTECTED] wrote: On Fri, Apr 15, 2005 at 11:44:03PM +0200, Juerd wrote: : Is there a ?ws-like thingy that is always \s+? Not currently, since \s+ is there. ?ws used to be that, but currently is defined as the magical whitespace matcher used by :words. : Do \s and ?ws match non-breaking whitespace, U+00A0? Yes. Yes, any Unicode whitespace, but you seem to have a different list than I do. Well there are three different whitespace lists. The Parrot program [1] below shows all, including space and blank. $ ./parrot ws.imc charuws ws jws sp bl U+0008 0 0 0 0 0 U+0009 1 1 0 1 1 U+000a 1 1 0 1 0 U+000b 1 1 0 1 0 U+000c 1 1 0 1 0 U+000d 1 1 0 1 0 U+0020 1 1 1 1 1 U+0085 1 1 0 1 0 U+00a0 1 0 1 1 1 U+1680 1 1 1 1 1 U+180e 1 1 1 1 1 U+2000 1 1 1 1 1 U+2001 1 1 1 1 1 U+2002 1 1 1 1 1 U+2003 1 1 1 1 1 U+2004 1 1 1 1 1 U+2005 1 1 1 1 1 U+2006 1 1 1 1 1 U+2007 1 0 1 1 1 U+2008 1 1 1 1 1 U+2009 1 1 1 1 1 U+200a 1 1 1 1 1 U+2028 1 1 1 1 0 U+2029 1 1 1 1 0 U+202f 1 0 1 1 1 U+205f 1 1 1 1 1 U+2060 0 0 0 0 0 U+3000 1 1 1 1 1 U+feff 0 0 0 0 0 So I make it: which seems to match Parrot_char_is_JavaSpaceChar leo [1] Needs some additions, which I'll ci in a minute, and the ICU lib installed. There isn't an interface for these functions yet, so they are looked up via dlsym(3) inside parrot itself. $ cat ws.imc .sub main @MAIN .local pmc chars, uws, ws, jws, sp, bl, nul, fmt .local int i, n, is, c chars = new ResizableIntegerArray push chars, 0x8 push chars, 0x9 push chars, 0xa push chars, 0xb push chars, 0xc push chars, 0xd push chars, 0x20 push chars, 0x85 push chars, 0xA0 push chars, 0x1680 push chars, 0x180e i = 0x2000 pl: push chars, i inc i if i = 0x200a goto pl push chars, 0x2028 push chars, 0x2029 push chars, 0x202f push chars, 0x205f push chars, 0x2060 push chars, 0x3000 push chars, 0xfeff null nul uws = dlfunc nul, Parrot_char_is_UWhiteSpace, IJI ws = dlfunc nul, Parrot_char_is_Whitespace, IJI jws = dlfunc nul, Parrot_char_is_JavaSpaceChar, IJI sp = dlfunc nul, Parrot_char_is_space, IJI bl = dlfunc nul, Parrot_char_is_blank, IJI n = elements chars i = 0 print char uws ws jws sp bl\n loop: fmt = new ResizableIntegerArray c = chars[i] push fmt, c is = uws(c) push fmt, is is = ws(c) push fmt, is is = jws(c) push fmt, is is = sp(c) push fmt, is is = bl(c) push fmt, is $S0 = sprintf U+%04x\t%d\t%d\t%d\t%d\t%d\n, fmt print $S0 inc i if i n goto loop .end
Re: identity tests and comparing two references
Larry Wall [EMAIL PROTECTED] wrote: : On Thu, 2005-03-31 at 23:46 -0800, Darren Duncan wrote: : : In P6, an object is a data-type. It's not a reference, and any member : payload is attached directly to the variable. Well, it's still a reference, but we try to smudge the distinction in P6. A reference as a Perl5 reference or just as a C pointer or a Parrot PMC? newclass cl, Foo # create new Foo class - 0 attributes $P0 = new Foo # make a new Foo instance $P1 = $P0 # both PMCs refer to the same object now $P1.meth()# same as $P0.meth() $P2 = clone $P0 # 2 distinct objects now $P3 = new Undef assign $P3, $P0 # same leo
Re: Auto generated methods (was Re:The S29 Functions Project)
Rod Adams [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
the method call in PIR can be written as:
d = x.cos() # normal method call
d = Float.cos(x) # class method, argument shifted down
d = P6Num.cos(x) # same
d = cos x # PIR opcode syntax [1]
cos d, x # PASM opcode syntax [1]
There'll be a table of such builtins with name, namespace, signature, so
that the current opcodes can be transparently replaced by methods.
This looks like it's taking
multi method Num::cos (Num|Str +$base) returns Num
and generating
multi sub cos (Num $x, Num|Str +$base) returns Num
No. The above lowlevel Ccos isn't aware of Cbase nor of C$_ and
nothing is autogenerated in Parrot. The Ccos is something like:
class __parrot_core::Float {
multi sub cos(Float x) returns Float ...
}
This is presumably inherited by Cclass P6Num (the Parrot PMC) and
bound to:
multi sub *cos(Num $x) returns Num
at the Perl6 level.
leo
Re: Auto generated methods (was Re:The S29 Functions Project)
Rod Adams [EMAIL PROTECTED] wrote:
While that's a nice feature to have in general, I feel better about
going ahead and predefining that the builtins are already members of
Num, Str, Array, Hash for the shear performance and documentation values
of it.
That's exactly the plan, when it comes to Parrot. I'd like to have a lot
of function-like opcodes factored out into classes/*.pmc as methods.
Given:
pmclass P6Num extends Float { # the P6Num isa(Float)
...
}
pmclass Float {
METHOD cos() { ... } # return cosine of Float SELF
the method call in PIR can be written as:
d = x.cos() # normal method call
d = Float.cos(x) # class method, argument shifted down
d = P6Num.cos(x) # same
d = cos x # PIR opcode syntax [1]
cos d, x # PASM opcode syntax [1]
There'll be a table of such builtins with name, namespace, signature, so
that the current opcodes can be transparently replaced by methods.
I'm not quite sure if the same scheme should apply to:
op cos(out NUM, in NUM)
i.e. to opcodes that take natural types. But eventually such opcodes can
be recompiled inline with the help of the JIT subsystem, so that there's
no function call overhead at all. For now they probably remain as
opcodes.
The other problem with case 5 is that the long name would be cos, not
cosNum, since the first parameter is optional. So you'd have to
expand the search beyond just the long name, which can get expensive.
The method lookup will be done just once per call site, it shouldn't
really matter.
-- Rod Adams.
leo
[1] PMC versions aren't implemented
Re: MMD as an object.
Bob Rogers [EMAIL PROTECTED] wrote:
From: Leopold Toetsch [EMAIL PROTECTED]
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
If yes, who is creating it: the Perl6 compiler emits code to do so or
it's up to Parrot to do the right thing?
FWIW, Common Lisp specifies a generic function [1] that collects all
methods defined for a given operation name. (In Perl/Parrot, the
generic function name for your examples would be the string foo; in
Lisp, it would be the symbol FOO in some package, but the practical
difference should be slight.) The important thing is that the GF has
all the information required to make method dispatch decisions.
That sounds exactly like the MultiSub object that gathers a candidate
list of all subroutines with the same short name.
... But on the other hand, the CL community has
more than 15 years of experience with MMD, so I wanted to be sure
everyone was aware of it.
Yeah, that's really helpful.
2) namespaces of (multi) subs.
A non-multi method is in the classes' namespace. In Parrot terms that's
currently:
%globals{\0class_name}{method_name}
I'm not quite sure, if the method hash shouldn't live inside the class.
Is naming at this level really important here?
Well, the short name of the multi sub has to be stored somewhere.
... The operation itself
needs a name (so that people can call it), and classes need class names
(maybe), but all methods are implicitly named by the combination of
operation plus argument signature.
Yes. That's the long name in Perl6 design documents.
... Which would seem to mean that,
unlike perl5, the package in which a multimethod is defined doesn't
matter; all that is captured by the argument signature.
Yep. You can define a multi sub anywhere.
... Or is it
possible to have more than one method with the identical signature? And
if so, what does that mean?
There can be identical signatures in different scopes. Within one scope,
I don't know.
The long name is therefore a list of class names, which suggests
that the single-dispatch naming above is backwards. Of course, I'm
probably out of my depth here . . .
The long name contains the signature. The short name is the bare
foo.
A multi method is similar, except that their can be more then one
with the same short name (which probably means that there has to be a
MultiSub object holding the long names)
I'm not sure it is meaningful to give a sub a short name,
You call it by the short name.
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
This sounds right to me. Or perhaps
%globals{foo} -- MultiSub{[foo, 'A', 'B'] = Sub, ...}
Yep, something like that.
just to belabor the point a bit.
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Is this really different? After all, the operation foo should be just
a string in either case.
Sure. But the string foo has to live in some namespace. But, it it's
not marked as global it's probably in either a package or a module, so
again it has it's namespace.
-- Bob Rogers
leo
Re: MMD as an object.
Rod Adams [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
Discussion seems to have went off into esoteric cases of locally
overriden dispatcher policies and what not.
I don't think it's as esoteric as you might think. Consider:
package Foo;
use MMD::Random;
our bar is MMD::Random is export(DEFAULT);
multi sub bar ($x) {...};
multi sub bar ($x) {...};
Note that they all have the same signature. The Manhattan policy would
complain about this, since it's looking for the closest parameter match.
The Random policy does not care. It's going to randomly pick any member
method for each call.
Ok. If you'd really need such random dispatch, it could be done like
this, when I interpret A12 correctly:
sub run_random_bar($x) {
my @meths = WALKMETH($x, :method('bar'));
my $meth = @meths[rand(@meths.elems)];
$meth($x);
}
or even with
my sub bar($x) {...} # same body as above
bar($x);
If you need an esoteric dispatcher roll your own :)
Since the main goal of treating multis as an object was to be able to
override the dispatch policy, I think how a user defined policy
interacts with different localities is very much on topic.
I don't think that the policy should be in the MultiSub object. You have
all methods and information to be able to do your own dispatch, if
needed. Your approach would very likely disable all possible
optimizations.
Anyway, that's far future.
What I'd like to know is more basic things:
Yes, still :-)
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
As for whether such a thing is visible at the Perl level, I think that
depends on if we allow user defined dispatch policies or not. If not,
it's just an introspection tool that could be addressed in other ways.
Don't think so. It's a problem of namespaces and how these multi subs
are managed. It touches Perl6 as well as Parrot.
Even without custom policies, p6c may decide to go the MultiSub object
route at the compiler level. But I can't speak to that, nor on the
Compiler - Parrot interaction.
It depends on what Parrot will get from the Perl6 compiler.
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
This can be seen as questioning how to keep track of what multi's are in
scope at any given point in time, because you must dispatch amongst all
the multi's visible, regardless of the differing scope.
Sure. But the dispatch scheme is described in A12. That is per se not
the problem.
However if you have multi's from a mix of different sources and scopes,
all with the same short name, which policy decides how to dispatch
amongst them at a given calling locality is very much at issue, and is
roughly where we are in the discussion.
Yes. The policy will be handled by a dispatcher object's dispatch
vtable, as far as I can currently see.
leo
Re: Junctions - feedback and desires
Rod Adams [EMAIL PROTECTED] wrote:
Well
if 10 $j 1 { ... }
if 10 $j { if $j 1 { ... }}
Could easily wind up with the same opcodes.
No. In the first case $j is evaluated just once. In the second case it's
evaluated twice.
leo
Re: MMD as an object.
Rod Adams [EMAIL PROTECTED] wrote: If I were to need a different policy for a given method .bar, I would likely create something called .bar much like your run_random_bar, which then dispatches amongst methods I name something like ._bar . I see some detractions to this approach: 1) Users wishing to add another multi to the mix must know that they have to make it a ._bar instead of a .bar. Not necessarily, AFAIK. You can define a lexical sub bar, which hides all outer multi subs. This bar can be used to dispatch to the multi subs. 2) What parameter signature do you give the wrapper method, so it does not clobber the arguments, yet still has them to pass on to the appropriate method? And at the same time, determine what signature the wrapper was called with, to determine who to dispatch to... Well, I presume, if you are writing such code, i.e. a bunch of mutli subs with the same signature, you are very well aware of what you are doing. So you'll know, how you call the dispatcher (and what funny effects you'll yield :) ... I hadn't said it before, but I had assumed the dispatch method of the MultiSub would have a signature of something like Str @types passed to it. I don't thing that the MultiSub does dispatch nor that it has a dispatch method. The MultiSub object is just a collection of multi Sub candidates for one of the scopes [lexical, package/module/class, global, builtin]. The current dispatcher has to collect a list of possible candidates from all the possible multis, and then decide, depending on the policy, which sub should actually be called. 3) It does not allow more than one sub with the same signature and short name to be in scope at the same time. That's mainly a Perl6 compiler problem. When the MultiSub is just a list of candidates, you can append whatever signature you like. There is no check for duplicates. It's only the dispatcher that will detect ambiguous signatures, if it cares about, like the default dispatcher. ... For instance, dispatching based on return type. Well, while there is a symmetry in call and return, when Parrot is concerned, dispatching on return types isn't easy, or better, it could just be done for the total static case, where all return results are known beforehand. For that case you could just call different subs in the first case. If the return type is just the runtime result, after the sub is run, you can do nothing in the dispatcher, which long before had called the sub. ... Or off of some user defined trait the different methods have. Or the most common case: on named arguments. A trait creates usually an anonymous subclass of the involved class and therefore has precedence over a not so specific class. MMD on named arguments isn't specified yet, or: ,--[ A12 ] | It is not likely that Perl 6.0.0 will support multiple dispatch on named | arguments, `- My understanding of the P6 Long Names is that if one creates a multi with the same parameter signature as a previously defined multi of same short name, it masks the previous one if in a tighter scope, or erases the previous if the same scope. As said, that's mainly a Perl6 compiler problem. The compiler can't emit two identical long names as one of these wouldn't be callabale then. The original thought was to have the policy take over the acceptance of new multi's into the MultiSub as well as taking over dispatch, thus allowing for such flexibilities. What policy is in effect, if you define somewhere a multi sub? I think, that can't work. And quite likely, the policy itself would not be in the MultiSub, but the MultiSub would have a reference to which policy it's using. No, I don't think so. The current (lexical) scope has the policy, according to A12. Some of the management issues I see that need addressing are: [ good questions for the compiler folks ] leo
Re: MMD as an object.
Rod Adams [EMAIL PROTECTED] wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short name.
Discussion seems to have went off into esoteric cases of locally
overriden dispatcher policies and what not.
What I'd like to know is more basic things:
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
If yes, who is creating it: the Perl6 compiler emits code to do so or
it's up to Parrot to do the right thing?
2) namespaces of (multi) subs.
A non-multi method is in the classes' namespace. In Parrot terms that's
currently:
%globals{\0class_name}{method_name}
I'm not quite sure, if the method hash shouldn't live inside the class.
A multi method is similar, except that their can be more then one
with the same short name (which probably means that there has to be a
MultiSub object holding the long names)
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Re: Argument Patterns
Luke Palmer [EMAIL PROTECTED] wrote: I think we should replace our multimethod system with a more general pattern matcher, a variadic multimethod system of sorts. Multimethods need to be variadic anyway, because we want pugs's quicksort example to work. I'd not say replace. The dispatcher will very likely be a Parrot PMC. The default dispatcher dispatches on types, matching variadic signatures should be possible too. All infix operators are multi subs. I can't imagine that we want to pay the penalty for simple operations like: $a = $b + $c to inspect the values of operands, constraints, rules and what not. [ dispatching on rules ] If the involved types need a more fancy dispatcher, their meta-class should say so. Luke leo
[RELEASE] Parrot 0.1.2 Phoenix Released!
On behalf of the Parrot team I'm proud to announce the release of Parrot 0.1.2. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.1.2 contains a lot of new stuff: - New string handling code. Strings now have charset and encoding - Parts of a generational garbage collector - Better Python support, separated into dynclasses - Parrot Grammar Engine - Improved test coverage and documentation - and a lot more After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.1.2.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from CVS by following the directions at http://dev.perl.org/cvs/. Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Re: How are types related to classes and roles?
Thomas Sandlaß [EMAIL PROTECTED] wrote: Am I missing something, but the only thing I've figured out so far is that Parrot uses ternary MMD for its builtin binary ops like ADD, MUL, OR, etc. actually binary, dispatch is based on (left, right) operands. They are ternary to prevent a final copy or conversion of the result to the target register. Where is the general MMD mechanism? No. The destination has currently to exist. But I'll very likely put in variants that create the destination. Currently a static 2-dimensional MMD table is used. This will be replaced by a dynamic lookup and caching. Will the Perl 6 MMD be directly implemented in Parrot or on top of it? I guess Parrot needs to do it for language interoperability, right? Yep. leo
Re: How are types related to classes and roles?
Thomas Sandlaß [EMAIL PROTECTED] wrote: The opcodes for 'callmethod_MMD_3_sig func' and 'callmethod_MMD_n func, n' are simply not there yet, right? No. The problem is that at function call time there is no indication that a MMD subroutine should be called. So Parrot will just do a full MMD search, if no other indication is there that it's just a plain subroutine. Another problem is language interoperbility. As e.g. python has no syntax for MMD, above opcodes would be useless - Python wouldn't be able to call any of the MMD builtins. leo
Re: Proposed vtable changes WRT method lookup
[ cc'ed p6l ] Matt Fowles wrote: Leo~ On Wed, 19 Jan 2005 10:02:26 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: But where does that PerlMMD PMC come from? Does the Perl6 compiler generate one somewhere? It is generated by the compiler. During compilation all of the different MMD functions will necessarily be parsed and compiled, when the first MMD function is compiled the compiler wil add a MMD PMC to the appropriate table. Each time a specialized version is compiled it will be added to the already created MMD PMC. Interesting. Where is this information coming from? Where can I read more about that? Finding the correct MMD function is always the same algorithm. Having that functionality in one place (the metaclass) is cleaner IMHO. No. It is not always the same algorithm. Perl 6 uses manhattan distance. Yes. I meant inside one class (HLL) system. Matt leo
Re: So long, and thanks for all the fish!
The Perl 6 Summarizer [EMAIL PROTECTED] wrote: I tried, I really did, but I'm afraid that I must raise the white flag ..- Dan, Leo and the rest of the p6i team have done fantastic work Thanks for the flowers and of course for all your precise summaries. ... But if any of you are thinking I could do that! then don't let me stop you -- there's an awful lot goes on on the lists, and there's a lot of interested people who don't have the time to keep up with them. A regular summary helps the interested but busy people get a grasp of how the Perl 6 project is getting on, and that can only be a good thing. Yep, so please, interested folks, sharpen your pencil ... -- Piers Cawley -- Former Perl 6 Summarizer Thanks again, and maybe ex-former any tine, leo
Parrot 0.1.1 Poicephalus Released!
On behalf of the Parrot team I'm proud to announce the Parrot 0.1.1 release. Parrot 0.1.1 is an intermediate release with tons of updates and fixes. - Python support: Parrot runs 4/7 of the pie-thon test suite - Better OS support: more platforms, compilers, OS functions - Improved PIR syntax for method calls and op= assignment - Dynamic loading reworked including a make install target - MMD - multi method dispatch for binary vtable methods - Library improvement and cleanup - BigInt, Complex, *Array, Slice, Enumerate, None PMC classes - IA64 and hppa JIT supprt - Tons of fixes, improvements, new tests, and documentation updates. A lot is unfinished and keeps changing. Nethertheless Parrot is stable and usable at the surface, while internals are moving. After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.1.1.tar.gz or just get the latest and best from CVS by following the directions at http://dev.perl.org/cvs/. Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Re: Synopsis 9 draft 1
Larry Wall [EMAIL PROTECTED] wrote: On Sat, Sep 04, 2004 at 09:47:29AM +0200, Leopold Toetsch wrote: : Honestly I don't see the point why all normal array usage should be : slowed down just for the sake of some rare usage patterns. Does it have to? Couldn't it have a different vtable? (Which argues that such a shape ought to be considered an parameterization of the implementation type. (Which argues that it should be of shape rather than is shape...).) A different vtable implies some kind of a derived class. The question is, if an of shape or is shape already causes a new class of arrayish objects. The question probably is: how much of this class code is done directly by Parrot. But given that shapes can be fully dynamic too my gut feeling is that some glue code will be in the Perl6 library. Larry leo
Re: Synopsis 9 draft 1
John Williams [EMAIL PROTECTED] wrote: What happens when the Pascal programmer declares my int @ints is shape(-10..10); Should that really all be in core? Why not let the user create his own derived array that does what she wants? Honestly I don't see the point why all normal array usage should be slowed down just for the sake of some rare usage patterns. ~ John Williams leo
Re: Synopsis 9 draft 1
Larry Wall [EMAIL PROTECTED] wrote: On Fri, Sep 03, 2004 at 11:41:05AM +0100, Tim Bunce wrote: : (I'm not (yet) familiar with Parrot's ManagedStruct and UnManagedStruct : types but there's probably valuable experience there.) Quite likely. Well, *ManagedStruct is already working pretty well. It is used to interface with C code that returns or takes structures of some natural types. It supports nested structures and pointers to these as well as arrays of items and a limited set of callback functions. See e.g. runtime/parrot/library/SDL* for a lot of such usage. Constructing such a struct takes a list of triples: - data type - optional array count of item - optional offset Alignment is calculated automatically, if offset is zero. Access to structure items is by index or by name, if the initializer list provides named items. Under the hood an exact image of the C structure is created. Larry leo
[Fwd: Newsletter from O'Reilly UG Program, July 9]]
[snipped except for essentials :) ] Book News New Releases ***Perl 6 and Parrot Essentials, 2nd Edition Publisher: O'Reilly ISBN: 059600737X Perl 6 and Parrot Essentials, 2nd Edition provides an insider's look at what's coming in the widely anticipated Perl 6. It uncovers groundbreaking new developments in Parrot, and the most revolutionary change in the language itself, Apocalypse 12 on objects. The book also expands coverage of Apocalypse 5 (regular expressions) and Apocalypse 6 (subroutines). This is the only book to reveal all the ingenious developments that will make Perl 6 more powerful and easier to use. http://www.oreilly.com/catalog/059600737X/index.html Chapter 10, Parrot Intermediate Representation, is available online: http://www.oreilly.com/catalog/059600737X/chapter/index.html
Re: This week's Summary
The Perl 6 Summarizer [EMAIL PROTECTED] wrote: Congratulations Ion, don't forget to send in a patch to the CREDITS file. $ grep -1 Ion CREDITS N: Ion Alexandru Morega D: string.pmc Thanks again for your summary, leo
Re: This fortnight's summary
The Perl 6 Summarizer wrote: PIO_unix_pipe() Leo's implemented a PIO_unix_pipe() method which allows you to run an external program and capture the results with a Parrot IO handle. He doctored the open opcode to use it pipe = open /bin/ls -l, -| While that's right regarding above syntax snippet, the credits for CPIO_unix_pipe() belong to Melvin Smith, who'd implemented it in the first place. I did just (as normal) make it more workable. Doctored is ok, though ;) leo - this is the usual thanks for your summariies, Piers, but ...
Re: Default program
Richard Nuttall [EMAIL PROTECTED] wrote:
On the DWIM principle, shouldn't Perl then just autoload the DWIM::AI
module and provide as output the script that they are intending to write ?
That needs of course some support in the inyards of Perl6, i.e. in
Parrot.
$ parrot
,--[ editor-session ]-
| .sub _main @MAIN
| print Hello, World!\n
| .end
| ~
| ~
| /Woenter
| cwParrotesc
| ZZ
`-
Hello, Parrot!
--- parrot/imcc/main.c Sun Mar 14 13:19:47 2004
+++ parrot-leo/imcc/main.c Thu Apr 1 14:08:13 2004
@@ -155,6 +155,8 @@
struct longopt_opt_info opt = LONGOPT_OPT_INFO_INIT;
int status;
if (*argc == 1) {
+run_pbc = 1;
+return autoload.imc;
usage(stderr);
exit(1);
}
$ cat autoload.imc
# autoload.imc
.sub autoload @MAIN
.param pmc argv
load_bytecode dwim_ai.imc
.local pmc conf_hash
conf_hash = _config()
.local string parrot
parrot = conf_hash[test_prog]
.local string cmd
cmd = parrot
cmd .= hello.imc
spawnw $I0, cmd
.end
.include library/config.imc
$ cat dwim_ai.imc
# DWIM::AI
.sub _ai @LOAD
.local pmc O
open O, hello.imc,
print O, .sub _main @MAIN\n
print O, \tprint \Hello, World!\\n\\n
print O, .end\n
close O
spawnw $I0, $EDITOR hello.imc
.end
R.
leo
Re: Default program
Leopold Toetsch [EMAIL PROTECTED] wrote: spawnw $I0, $EDITOR hello.imc .end That's of course suboptimal. Here is a better version: .local pmc env env = new Env .local string editor editor = env[EDITOR] # TODO: provide sensible default if not found, i.e. vim .local string cmd cmd = editor cmd .= hello.imc spawnw $I0, cmd .end leo
Parrot 0.1.0 Released
Parrot 0.1.0 Leaping Kakapo Released! The Parrot team proudly presents the Parrot 0.1.0 leap release. It provides some milestones like objects and multi-threading1[1] and supports many more platforms. After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.1.0.tar.gz or just get the latest and best from CVS by following the directions at http://dev.perl.org/cvs/. Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo [1] The list of changes includes: - Ladies and gentlemen, I give you... objects! - Huge documentation overhaul - More supported platforms, s. PLATFORMS - Basic thread support for pthread based architectures - Basic event handling for timers and signals including: - PASM callbacks for NCI (native C) functions. - Improved platform configuration - COW stacks now working, stacks code redone - Structure handling vastly improved - Random PMC and rand primitives - Better subroutine call syntax in PIR - Make PIR subroutines compliant with pdd03 - Improved profiling (DOD, GC timings) - Hash code improvements, incl. random key order support - Experimental freeze/thaw code for some PMC types - IO improvements for buffered layer and Win32 - String iterators - String bitwise vtables - Many new opcodes - Suppport for JIT, where malloced memory isn't executable - Priority DOD scheme for objects that need timely destruction - Improved byte code loading (e.g. onLoad functions) - Language updates: forth, Perl6/P6C, m4 - Libraries: Getopt_Long, SDL, Dumper, Sort - new JAPH examples - Unified imcc and parrot test handling - Many new tests (make test reports 1386 tests) - Numerous bug fixes
Re: This week's summary
Piers Cawley wrote: newsub and implicit registers [...] ops [...] that IMCC needed to track. Leo has a patch in his tree that deals with the issue. Sorry, my posting seems to have been misleading. The register tracking code is in the CVS tree. Thanks again for your summaries, leo
Re: This week's summary
Piers Cawley [EMAIL PROTECTED] wrote: Parrot Calling Convention Confusion ... -- I thought they were exactly the same as an unprototyped call, but you invoke the return continuation (P1) instead of P0, the other registers are set up exactly as if you were making an unprototyped function call. Unfortunately the call and return conventions are *not* symmetric - yet. S. Fdocs/ppds/pdd03_calling_conventions.pod. Thanks for the summary and servus, leo
Parrot 0.0.13 Screaming Pumpkin Released!
Parrot 0.0.13 Screaming Pumpkin Released! Your new Bluza[1] proudly presents Parrot 0.0.13 Halloween edition[2]. Proposed originally as a fun release it has a remarkable list of improvements, additions, and fixes[3]. While not really milestones are reached, many steps towards these are done. After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.0.13.tar.gz or just get the latest and best from CVS by following the directions at http://dev.perl.org/cvs/. Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo [1] Austrian dialect word for pumpkin with some aftermath of an head filled with water. [2] Version number fits nicely todays date - and we don't release by the dozen. [3] The list of changes includes: - The Big Move: Parrot source and build files rearranged into sub dirs - Build imcc as parrot - Objects more finished - Delegate vtable methods to byte code - Binary multi-method dispatching - Isa and does methods for PMCs - Call byte code from C - Start of extension interface - Experimental struct handling - Catch access to NULL PMCs - Experimental network socket interface code and opcodes - IO fixes and improvements - Dynamic opcode libraries - Fix-assigned opcode numbers - Argument flattening for function calls - More native call interface (NCI) signatures - Ncurses, postgres, and pcre interface libraries - Forth language is vastly improved - New tcl and urm languages - BSD and Win32 build improvements - Many new tests and fixes
Re: This week's Summary
Piers Cawley [EMAIL PROTECTED] wrote: Object Freezing [ ... ] ... The upshot is that we're doing it Dan's way; Glorious Leader continues to trump Pumpking Patchmonster. As this is a summary, abbove sentence is a summary as well. The reality is more complex. The final implementation will have parts from both POVs. Thanks again for your summaries, leo
Re: This week's summary
Piers Cawley [EMAIL PROTECTED] wrote: ... spending the morning of your 36th birthday Happy birthday to you and us. l - A full year has passed, hasn't it? - eo
Re: This week's Perl 6 Summary
Piers Cawley [EMAIL PROTECTED] wrote: Okay, okay, PONIE really stands for 'Perl On New Internal Engine'. That's that what they say. Actually it was: PONIEPONIE: Perl5 Obsoletes Nasty Internals Entirely: Parrot Occupies Numerous Interpreters Everywhere But that was to bulky. Or too many ponies, w/o any camels... [ quote of the week ] Dan: I'm really bad at reading my mails Leo: You should at least read *my* mails Everyone: Hear! Hear! (or words to that effect) s/read/please read/ - albeit the pronounciation of my above is ok ;-) Piers, thanks again for doing these summaries it was a great pleasure to meet you »in personam«, leo
Re: This week's summary
Piers Cawley [EMAIL PROTECTED] wrote: More CPS shenanigans I get the strong feeling that Leo Tötsch isn't entirely happy with the new Continuation Passing Style regime. No, I'm really happy with CPS. Restoring the whole context by invoke'ing the return continuation is a very elegant and efficient way to do it, not speaking from tail calls ... He's worried that the P6C tests break, ... albeit this is still an issue. Nobody answered, if we need another Sub class implementing the old invoke/ret scheme ... ... and that CPS subs are some 3 times slower for calling the sub. ... while this is solved. Jonathans patch that went in originally had this bad performance. But with separating the Sub/Continuation setup from the actual subroutine call (which amongst other things my patches did), performance is back again at the old level. In fact the current CPS implementation is faster then the old invoke/ret scheme. I estimate the final speed, when all needed context things are saved, to be about the same as invoke/ret w/o much context saving. Whee! My first anniversary! Congrats and thanks for your great summaries. leo
Re: Rules and hypotheticals: continuations versus callbacks
Matthijs van Duin wrote: Which system is likely to run faster on parrot? I would propose, estimate the ops you need and test it :) E.g. call a continuation 1e6 times and communicate state with one global (a lexical is probably the same speed, i.e. a hash lookup) $ cat a.pasm new P5, .PerlInt set P5, 100 store_global foo, P5 new P0, .Continuation set_addr I0, endcont set P0, I0 endcont: find_global P4, foo unless P4, done dec P4 # store_global foo, P4 --no need to store, P4 is a reflike thingy invoke done: print done\n end $ time imcc -P a.pasm done real0m0.881s $ imcc -p a.pasm done OPERATION PROFILE CODE OP FULL NAMECALLS TOTAL TIMEAVG TIME - - --- -- -- 0 end 10.010.01 40 set_addr_i_ic 10.010.01 66 set_p_i 10.010.01 67 set_p_ic10.040.04 226 unless_p_ic 1010.5950250.01 276 dec_p 1000.5999460.01 758 store_global_sc_p 10.060.06 760 find_global_p_sc 1011.0379220.01 786 new_p_ic20.110.05 819 invoke1000.9140630.01 883 print_sc10.0052990.005299 - - --- -- -- 114103.1522800.01 So you can estimate that the more heavy opcodes take about 1us, more light vtable functions are ~double that speed with the slow, profiling core. CGP (or JIT) is 3 - 4 times faster. -O3 compiled parrot, Athlon 800, i386/linux leo
Re: Rules and hypotheticals: continuations versus callbacks
Matthijs van Duin wrote: sweepoff# or bus error collectoff# or segmentation fault Please try : /* set this to 1 for tracing the system stack and processor registers */ #define TRACE_SYSTEM_AREAS 1 in dod.c (works for me). Though I don't know, if processor registers on PPC gets traced by this (it might not stand optimization if not). Code is not that deeply looked at, that we can savely turn off stack tracing yet. leo
Re: A6: Strict signature checking - was: Complex Parameter Types
Austin Hastings wrote: But what's the vision for p6? My expectation is that the type-checking stuff will be heavily used for: 1- Large scale projects. 2- CPAN modules. 3- speed When you are not on perl one liners, but maybe some inner tight loops of some algorithm or whatever, where speed does matter, we (the low level PASM folks :) have achieved a speed increase of x100 and more, on a now of course hand crafted assembler routine compared to $HLInterpLang. These are the margins that a good optimizer will be able to hopefully reach, which are for plain integers near or beyond gcc -O3 performance with the JIT runtime. When the flexibility of all the lanugage comes in, this is of course not possible, and the more of those features (caller, %MY, leave, exceptions) are used, the less, optimizations can be used. But for what is the type-checking stuff: for sure for better diagnostic messages and for performance, when needed. =Austin leo
Re: This week's Perl 6 Summary
Piers Cawley wrote: Coroutines end and DFG Nobody explained what DFG stands for. It's a commonly used TLA standing for Data Flow Graph, which accompanies the CFG (Control Flow Graph). Both are necessary for register allocation. leo
Re: Arrays: Default Values
Aaron Sherman wrote: On Tue, 2003-01-28 at 16:23, Leopold Toetsch wrote: Arrays (or hashes) don't grow on reading - never. But for less pure forms of reading: foo(@a[0]); auto-vivification will have to happen in some cases. e.g. if foo requires a lvalue parameter. A lvalue param is not strictly reading, but here has to happen something differently - yes: IMHO some sort of proxy could be passed here, saying: if you write to me, this will be at @a[0]. Or auto-vivify the entry. leo
Re: Arrays: Default Values
Dave Mitchell wrote:
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
IMHO some sort of proxy could be passed here, saying: if you write to
me, this will be at @a[0]. Or auto-vivify the entry.
This is what Perl 5 does at the moment:
$ perl5.8.0 -MDevel::Peek -e 'sub f{Dump($_[0])}; f($a[9])'
Ah, same idea ;-)
However, I think this is clumsy and overly complex; since Perl6 allows us
to declare parameters rw or whatever, I think it should always autovivify
unless we know the param is read-only (or in-only, or whatever the correct
terminology is).
It's probably not too complex, it's IMHO the same, what we would need to
implement the multi_keyed opcodes like:
@a[$x] = @b{$y} - @c[2;$i]
We can't implement all the opcodes per se, this would need ~64K ops, so
one of my proposals (some time ago) was, to split this operation in 3
keyed fetch ops and one plain subtraction. The LHS whould need - as I
can set it now - a very similar treatment like above's example.
To come back to the array example:
- when the sub param is ro, you said it, no autovifiy should happen
- for rw (the default?) there is always a chance, that no write will
occur, and for the case nothing gets written, we have a volatile PMC
(the proxy) collected with the next DOD run. With autovivification we
create an anchored value, that is more expensive.
A (of course) constructed example could check in a subroutine, if
one/some/all elements exist
sub e() {return exists shift;}
for ([EMAIL PROTECTED]) - $i { do_some($i) if e($a[$i]); }
# modulo syntax, operator and other errs :)
And, from DWIM POV, autovivification was not the clearest things in the
docs, when it could happen or not. I would just expect: when I don't set
this very elememt in this array, why is something there.
leo
Re: Arrays: Default Values
Jonathan Scott Duff wrote: The solution I advocate is to allow even primitive types to hold undef. Why do you then use a primitive type in the first place? IMHO: 1) primitive types are what they are - no undef, no attributes, just e.g. plain integers (or shorts or bits ...) 2) if you want to store additional information use a normal perl variable i.e. a parrot PMC. Why on earth would we want to take advantage of primitive types - when then people additionally want to tuck their birthdate on it? The array of 1e6 ints takes 1e6 words, the same array of PerlInts allocates ~10 times the memory and causes additional a lot of GC overhead. And finally, if you a need a few more bits of information for your IntArray[1e6], then wrap it into your own array class - we are speaking of perl here - or do we? -Scott leo
Re: Arrays: is computed
Michael Lazzaro wrote: [EMAIL PROTECTED] wrote: Shouldn't access to 'is computed' arrays be read-only? In general, I would hope that 90% of them would be, but it's been stated that it won't be a requirement. If you want such 'is computed' thingy, then tie it or wrap it in your own - IMHO. Everyone seems to need different things, so the simplest and by far the safest way is to make this explicit in your code. Hmm... real vs. fake undef... a difference between null-PMC and PMC-null, autofill with null-PMC, but assigning undef writes PMC-null... is that enough to make it work w/out speed penalty? Dan/Leopold? The array starts filled with zero's. A default value would mean, to fill each allocated array slot with a PerlUndef PMC (or a specific value respectively) which is expensive. On reading a NULL this gets converted to a new PerlUndef on the fly. I don't see, what more is necessary - and: my $val = @a[5] or $my_default; But making Cundef @a[n] and C@a[n] = undef do very different things, that's still scary. Powerful, but scary. People really, really want that, huh? This sould be really the same. But I could imagine to have something like @a.nullify(5); On Thursday, January 30, 2003, at 02:30 PM, Nicholas Clark wrote: I think there is a lot of scope for creating tied objects for all of this complex behaviour. Everyone has different ideas about what would be useful, Yep, exactly. Agreed. Very, very agreed. :-) DAMN, I want to start using this NOW. MikeL leo
Re: Spare brackets :-)
John Williams wrote:
I think you are still overlooking the autovivification behavior.
i.e. What is the difference between these:
1) $a{1234567} = 1;
2) $a[1234567] = 1;
Answer: #1 creates 1 element. #2 creates 1,234,567 elements!
Not currently: 2) does
- generate a sparse hole between old size and up to ~index
- generate one data chunk near index
- store the PerlInt at index
Reading non existent data in the hole generates then PerlUndef's on the fly.
~ John Williams
leo
Re: Arrays: Default Values
Austin Hastings wrote:
Another question: If you ask for a value and get it, does the array
grow? Or does that happen only on assignment? (
Arrays (or hashes) don't grow on reading - never.
And another anser from current low level (list.c classes/Array.pmc)
*Return value
*
*
*List get functions return a (void*) pointer to the location of the
*stored data. The caller has to extract the value from this
*pointer.
*
*For non existent data beyond the dimensions of the
*array a NULL pointer is returned.
*
*For non existing data inside sparse holes, a pointer (void*)-1
*is returned.
*The caller can decide to assume these data as undef or 0 or
*whatever is appropriate.
As the returned ptr is a PMC ** you/the class interface can do what is
appropriate:
if (ret == 0)
internal_exception(OUT_OF_BOUNDS, Array index out of bounds!\n);
/* XXX getting non existant value, exception or undef?
* current is for perlarray */
if (ret == (void*) -1)
value = undef(interp);
else {
value = *(PMC**) ret;
if (value == NULL) /* XXX same here */
value = undef(interp);
}
leo
Re: More Array Behaviors (Take 3)
Michael Lazzaro wrote: 2) There is NO platform-dependent maximum array size. If it's not a sparse array, you'll run out of memory long before you run out of indexes, but using bigints as indexes for sparse arrays is OK. Current: array size is limited to $arch's +INTVAL (2^31-1 / 2^63-1). Arrays get sparse by default if you set arrays elements with indices distance ~3K. IMHO if you need bigger indices use a hash. MikeL leo
Re: More Array Behaviors
Michael Lazzaro wrote:
I have some answers from current low level implementation.
2) As hinted above, is there a (platform-dependent) maximum addressable
array index, or do we promise to correctly handle all integers, even if
BigInt? (This might come into play for lazy/sparse arrays. Maybe.)
new P0, .PerlArray
set I0, 1
shl I0, I0, 31
dec I0
dec I0
set P0[I0], I0
set I1, P0[I0]
print I1
print \n
end
Current max index is 2^31-2 (for 32bitters). SIZE/RSS of above running
is 1152 (list.c can do sparse arrays). IMHO for bigger arrays use a 64
bit processor, and you can't fill them anyway ;-)
4) Optional array behavior. In addition to default values, it may be
possible to expose other details of array behavior, such that the user
has some flexibility in the implementation of a given array. Examples:
my @a is Array(
min_size = 50,# minimum reported size of this array
Just set @a[49]
resize = (1024), # internal blocksize (in indexes)
items per chunk, yes.
# by which array expands?
resize = { $_ * 2 }, # or via closure, based on current size?
Small arrays start extending by doubling chunk sizes, big arrays start
with maximum chunk sizes and don't grow chunks anymore. Closures or such
are for sure overkill and will slow it down.
exception = 1,# whether out-of-bounds addressing
This is default for Array.pm (PerlArray does auto resize).
MikeL
leo
Re: This week's Perl Summary
Damian Conway wrote: Piers Cawley wrote: Acknowledgements But, of course, modesty forebade him from thanking the tireless Perl 6 summarizer himself, for his sterling efforts wading through the morasses that are P6-language and P6-internals Remembering e.g. perl6 operator threads, brrr, I just can say ... Thank-you, Piers! me2 Damian leo
Re: Primitive Vs Object types
Larry Wall wrote: ... I can see ways of binding properties to a location without growing the location itself, but I think stuffing a junction of ints into a single location is somewhat problematical. We are still talking about native types - these with lowercase names in the docs? Why should they have runtime properties? (E2/A2 state, they have none) ... As for undef, it *could* just be a property, but for efficiency it would be nice to represent it in-band for those types that can so represent it, and it ought to be possible to tell the million bit array whether or not it is willing to store undef properties off to the side. We can argue whether the default should be yes or no... Adding properties to individual Cbits is a PITA as well as appending extra information, e.g undef. A CBIT array could start as a packed array of bits, adding runtime properties would promote this array to an array of PMCs, i.e. objects, which handle these properties. Larry leo
Re: Primitive Vs Object types
Michael Lazzaro wrote: On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. From A2 we have: Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. My interpretation: A CINT my start as as Cint as long as the compiler/optimizer doesn't see any attributes/tie/bless or whatever, that would need an object. If so, it promotes to an object. More important: how big is Cmy bool bit_ar is dim(1000,1000). It will be 10^6 / (sizeof(int) * CHAR_BIT) + list_overhead. leo
Re: Iterators [was: worth adding collections to the core language?]
Luke Palmer wrote: I wonder if things should have a more general interface than numerical indices. I've wanted linked lists in perl, and every time I do a splice on an array I cringe for speed reasons. Heh, we could use my linked array implementation. Or not. Please have a look at list.c, which is the engine for *Array classes. But I think we need a concept of iterators in the core. There were some patches floating around. Dunno what happened to them. Luke leo
Re: Perl 6 Summary for week ending 2002-09-15
Kay Röpke wrote: On Wednesday, Sep 18, 2002, at 17:42 Europe/Berlin, Piers Cawley wrote: IMCC / Mac OS X problem Have those patches committed, yet? I tried last night (instead of sleeping...;-)) but failed utterly. No, sorry. I'm still waiting for my imcc 0.0.9 patch to be checked in, where these fixes are included. If urgent you could follow the mentioned thread. There were all the pieces to get it running. Regards, Kay leo
Re: Perl 6 Summary for week ending 2002-09-15
Piers Cawley wrote: Happy birthday to me! Congratulations. ... by my turning 35 on the 15th 44 on 16th - yes Sept. and thanks for the kudos, leo
Re: Second try: Builtins
Aaron Sherman wrote:
Of these, about 30-50% will probably be pure Perl. Another small
percentage will be assembly wrappers that call a one-for-one parrot
function (e.g. exit). The rest will be a complex mix of Perl and
assembly (e.g. sprintf which is mostly Perl, but needs assembly for
low-level type conversion).
I'm just providing the necessary infrastructure inside imcc. The format
of current Builtin's will probably slightly change. I need the global
label (i.e. entry point) of the function for bsr fixup.
Sean did propose:
.extern sub_name _label
Plus something like (mine):
.sub sub_name {
saveall
.param PerlUndef Arg1
...
}
for PIR subs.
(Current imcc parses »ret« as end of sub, which we might change)
There is no real need to use PASM at all in the function, but imcc
(0.0.9) parses PASM instructions too.
BTW: are there any thoughts about PackFile_FixupTable?
leo
Re: First crack at Builtins.p6m
Brent Dax wrote:
Aaron Sherman:
sub abs($num is int){ return $num=0 ?? $num :: -$num }
^
I believe that should be (int $num).
and there is a »abs« in core.ops.
Anyway, before implementing a bunch of builtins, it should be organized
a little, where they should finally be stored.
The current Bultins.pm is not the place for it in the long run.
Builitins implemented in perl6 could go to a hierarchy of subdirs below
P6C/Buitins.
For builtins written as .imc or .pasm I'll do some sort of #include
mechanism in imcc. If they are stored as individual files in above
hierarchy or somewhere else should be discussed too. Actually they will
be bundled to some sort of runtime lib anyways.
my 2 ¢
leo
Re: Perl 6 Summary For Week Ending 2002-08-25
Piers Cawley wrote: ( a lot ;-) Thanks for this really informative summary. Must be a lot of work. ... Actually, Leopold was something of a patch monster this week, Of course, you missed all my private mails to Sean WRT imcc perl6 patches ;-) If I read his post right, Leopold Toetsch now has his native parrot assembler up and at least assembling the entire test suite into a runnable state (even if some of the tests then fail.) Work on this continues, but I think it's lovely. No I did post a small script, which uses the current infrastructure and runs all tests either native or shared by use of perl6. perl6 (= imcc, assemble.pl, pbc2c.pl, gcc, ...) (s. Warnock) Servus, leo
Re: Autovivi
Uri Guttman wrote:
[ CCs stripped ]
... what if you passed \$a{llama}{alpaca}? even as a read only param,
you could deref later through the ref in another sub that gets passed it
from this sub.
If I understand Dan's proposal (a05111b55b977c7a65606@[63.120.19.221])
for a change in the KEYed methods correctly, this would work, when
additionaly the KEY get's passed on with the PMC.
my %a;
func (%a{llama}{alpaca});
new P0, .PerlHash
new P1, .KEY
set P1[0], llama
set P1[1], alpaca # KEY chain P1{llama; alpaca}
setk? P0, P1# assoc KEY chain P1 to P0
save P0
bsr func
func ($h is rw) {
print $h;
$h = 'wooly';
}
func:
pushp
restore P0
print P0# get_p_keyed gets implicitly it's own KEY = undef
set P0, 'wooly' # set_p_keyed autovivs KEY (chain)
popp
ret
... but how to detect that at runtime is an issue.
If the PMC carrys it's KEY around, this should work.
uri
leo
Re: 'while {' in Perl 6
[EMAIL PROTECTED] wrote:
Question: if the compiler *doesn't* raise an error, what happens? How would
the following code be interpreted, even insanely? An endless loop perhaps?
while something() = $_ { ... }
Changing the closure to use »=« instead of »-« yields with current P6C:
Can't locate object method ctx_right via package P6C::pair at \
P6C/Addcontext.pm line 678.
So the pair syntax comes in, which is not much surprising, pair is very
high in precedence.
-Miko
leo
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
Sean O'Rourke wrote: -- languages/perl6 should work equally well with 5.005_03 and 5.6.1. s/should/does/ EOT ;-) /s leo
Re: of Mops, jit and perl6
Dan Sugalski wrote: At 10:44 AM +0200 7/28/02, Leopold Toetsch wrote: 2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend: (»make mops« in parrot root) Just out of curiosity, I presume the (rather abysmal) perl 6 numbers include time to generate the assembly and assemble it--have you tried running the generated code by itself as a test? (At the moment, the assembler's rather slow) No, these Mopsen are pure run time. As Sean alredy stated, code quality is to blame. Times for individual steps are: $ time perl6 --imc mops.p6 real0m1.794s user0m1.690s sys 0m0.100s $ time ../imcc/imcc mops.imc mops.pasm 327 lines compiled. Compiling assembly module mops.pasm real0m0.032s user0m0.020s sys 0m0.000s [lt@thu8:~/src/parrot-007/languages/perl6] $ time perl ../../assemble.pl mops.pasm mops.pbc real0m0.481s user0m0.470s sys 0m0.010s This adds up to 2.3s to get a perl6 program running. leo
Re: of Mops, jit and perl6
Dan Sugalski wrote: At 10:44 AM +0200 7/28/02, Leopold Toetsch wrote: 2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend: Just out of curiosity, I presume the (rather abysmal) perl 6 numbers After the bugfix in perlarray.pmc I can bring you new numbers, which are not that abysmal. Changing the while loop in mops.p6 to: $I4 = $I4 - $I3 # subI4, I4, I3 - while ($I40); # if I4, REDO + while ($I4); # if I4, REDO (which is more correct, comparing to e.g. mops.pl) $ time perl6 -Rj mops.p6 Iterations:100 Estimated ops: 200 Elapsed time: 1.032118 M op/s:1.937763 real0m3.357s user0m3.190s sys 0m0.150s We have already the same Mops as perl5, but additionaly 2.3 seconds overhead. Just running the byte code is as fast as perl5. Without jit, mops.p6 performs at 0.8 Mops. leo
perl6 driver
Hi all,
thanks to Sean, finally a perl6 driver arrived in CVS.
To further improve/clean up/enhance it, I would need the help of various
people, working on different parts of the parrot project.
Though I could try to write some patches, to address below mentioned
items, I think, people involved with the very topic will get it better
and faster ;-)
0) Overview
perl6 currently does:
- tokenizing parsing perl6 source (P6C/Parser ...)
- generate imcc byte code (P6C/IMCC ...) (.imc)
- call languages/imcc/imcc for generating assembler code (.pasm)
- call assamble.pl to produce byte code (.pbc)
- run parrot byte-code
or optionally
- compile byte code to executable (pbc2c, cc, ld)
- and run executable
planned is to call the optimizer too, though I don't know, if it is usable.
Perl6 passes appropriate command line options over to the programs and
captures STDERR to collect the output.
Currently it uses a lot of intermediate files for the various stages:
file.imc ... intermediate compiler code
file.pasm ... parrot assembler
file.pbc ... parrot byte code
file.c... opt. translated to c
file.o, file opt.
file.warn ... warnings
file.tree ... opt. parser tree
These files are currently not deleted, though such option will come
soon. Finally all file handling should optionally go through pipes.
1) configuration
lib/Parrot/Config.pm doesn't currently provide all the information for
perl6 running without hard coded settings.
It would need additionally:
- a path (or list of paths), where to find above programs
- a list of all objects, needed to compile a binary, currently
only $PConfig{pmc_classes_o} is there.
2) interface to programs
As perl6 calls all involved programs, they should obey to some common
interface.
- take input on STDIN or a file
- write output to STDOUT or file
- can handle a common subset of command line options:
-V --version (print version info to STDOUT and exit)
-h --help(print help info to STDOUT and exit)
- print usage info to STDERR if invoked wrongly.
Proposal:
-v --verbose (increase verbose level by one)
this clashes with perl5, keep it or leave it?
It currently informs about the stages run.
-w --warnings (enable warnings, or make it default enabled?)
-Dx --debug=x (enable debugging at various stages)
- other switches should (if possible) be compatible with
»man perlrun« aka »perldoc perlrun«.
Long options are always ok.
3) errors, warnings, diags and info messages
- should of course go to STDERR
- should have a string in it, stating clearly in which subpart of
the program the message originated.
- should have a string in it, stating the severity of the message
i.e. /error|warn|info|diag|debug/i
Perl6 will provide means to filter and print messages by level
(i.e. -w level) and by grepping them.
Perl programs could use a mechanism shown in Sean's P6C/Util.pm
(which will eventually make it into a standalone module)
Standalone programs should write similar diagnostic messages.
All programs should of course:
- return with exitcode 0 for success, or !0 for errors.
4) Platforms
I can test perl6 only on i386/linux, so patches from users of different
platforms are welcome.
5) individual issues/questions
- assemble.pl
How stable is the interface, may I »require« and call it's
methods directly?
Speaking from perl6 driver POV:
Does/will anyone need the feature to assemble multiple
.pasm files into one .pbc?
- optimizer.pl
If assemble.pl's methods my be called directly the optimzer could
be integrated.
Finally:
Patches, suggestions, ... welcome.
Thanks for reading til here,
leo
of Mops, jit and perl6
Hi all,
1) perl6 driver program arrived in CVS/languages/perl6
CAVEATS: it generates a lot of intermediate files:
($filename.{warn,imc,pbc,pasm[,c,o,tree,])
an may therefore clobber e.g. mops.c if you run
languages/perl6 perl6 -C ../../examples/mops/mops.p6
So please test it in a copy of your CVS tree.
NB: source is a mess, but I wanted a quick start to get it running.
Thanks to Sean, for prd-perl and many hints.
and finally: perl6 will currently run only in languages/perl6
2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend:
(»make mops« in parrot root)
[lt@thu8:~/src/parrot-007/examples/assembly]
$ ../../parrot mops.pbc
M op/s:18.270783
$ ../../parrot -j mops.pbc
M op/s:363.468516
$ ./mops
M op/s:196.355836
[lt@thu8:~/src/parrot-007/examples/mops]
$ ./mops
M op/s:366.106527
[lt@thu8:~/src/parrot-007/languages/perl6]
$ perl6 ../../examples/mops/mops.p6
Iterations:100
M op/s:0.303587
$ perl6 ../../examples/mops/mops.p6 -Rj # run jit
M op/s:1.148392
[lt@thu8:~/src/parrot-007/examples/mops]
$ perl mops.pl
Iterations:1000
M op/s:2.22
(Iteration count for mops.pl was reduced, patch sent)
Summary:
Program
Mops
perl5.005_03
2.2
perl6
0.3
perl6 jit 1.1
parrot interpreted 18
parrot compiled 200
parrot jit 363
plain c 366
Remarks:
- jit is a lot faster then compiled
- plain mops.c is only slightly faster the jit, i.e. 1%
- perl6-jit, albeit still totally unoptimized, doesn't compare too bad
to perl5
- mops is a silly test ;-)
3) jit detection was broken, patch is on the way to bugs-parrot.
Have fun,
leo
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
Nicholas Clark wrote: In October 2000 I believed that 5.005 maintenance *is* important for the acceptance of perl6, and I still do now: Some minutes ago I sent a first patch to Sean, to make it work on 5.005_03. One reason of failure is shown by the following snippet: $ cat t1 #!/usr/bin/perl -wl use strict; my $r = qr( [-+] )ox; my $t = '+1'; print $t =~ / \A(?-imxs:$r) /ox ? yes : no; print $t =~ / \A(?-ims:$r) /ox ? yes : no; $ perl t1 no yes The output is yes/yes on 5.6.1. (Code similar to the above matching is generated in Perlgrammar.pm, but there should be a workaround by giving up some readability) leo
