PMC's
Hi. Some questions I got when start looking to PMC's: - Is there planned a set PMC? If not, a parrot application can't create it's own PMC? - There are PMC examples other than the test suite? Thanks for the good work ;) Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: Tasks for the interested
(I don't have the original msg in my mbox, so I'm jumping in here...) The following is from the Tcl bytecode compiler [1] FAQ: Why doesn't Tcl use the Java bytecodes? I [2] had originally hoped to use Java bytecodes because they have a mature design and because Java is widely available. I chose to use my own Tcl-specific bytecodes because I was concerned that using the Java virtual machine would be too slow or take too much memory. The basic problem is the semantic mismatch between Java bytecodes and Tcl. Consider the Tcl set command. Tcl variables behave very differently than Java variables. I can't use a Java instruction like astore (store object reference in local variable) to store a Tcl value into a Tcl variable since it doesn't handle by itself such Tcl details as variable traces, unset, or global. The best I could do would be to translate a Tcl set command into a sequence of several Java instructions that did the appropriate checks. Unfortunately, the number of Java instructions to implement each Tcl command would make the compiled program too big. A more realistic scheme is to generate Java bytecodes that call one or more Java methods to do the actual work for each Tcl command. With this number of Java method calls, acceptable performance will depend on using a Java JIT (bytecode-to-machine code) compiler. With Java JIT compilers becoming more widely available this might be realistic. One possibility would be to translate the relatively high-level Tcl bytecodes into Java bytecodes. However, there is another problem with using Java bytecodes. Much of the interesting code in Tcl/Tk and its extensions is in C. Java code can call native methods implemented in C, and vice-versa, but this is awkward, not portable, and the capability is disabled in Netscape (and many other Java implementations) for safety reasons. [1] http://www.tcl.tk/doc/compiler.html [2] Author credit on the document is [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: Perl 6 grammar progress?
For some reason I feel really, really bad saying this -- in fact, I'm warming up the flog right now -- but, um, maybe Damian should write it? __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: [Patch] typeof op
At 1:49 PM -0500 6/29/02, brian wheeler wrote: This patch implements a typeof op which returns the integer type or string type of a PMC. Applied, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stack performance issue
At 6:59 PM +0100 6/30/02, Tom Hughes wrote: There is a performance issue in the stack code, which the attached patch attempts to address. [Snip] Some figures from my test programs, running on a K6-200 linux box. The test programs push and pop 65536 times with the first column being when that loop doesn't cross a chunk boundary and the second being when it does cross a chunk boundary: No overflow Overflow Integer stack, before patch 0.065505s 16.589480s Integer stack, after patch 0.062732s 0.068460s Generic stack, before patch 0.161202s 5.475367s Generic stack, after patch 0.166938s 0.168390s Yowtch! Go for it, though please make some comments in the code to the effect that the pointer to the next (unused) chunk should be invalidated if things get marked COW. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stack performance issue
At 06:59 PM 6/30/2002 +0100, Tom Hughes wrote: of the ARM procedure call standard. The solution there is to always keep one chunk in reserve - when you move back out of a chunk you don't free it. Instead you wait until you move back another chunk and then free the chunk after the one that has just emptied. You might want to modify register stacks too. I currently have a band-aid on it that just doesn't free stack chunks which works in all but the weirdest cases. -Melvin
Re: Perl 6 grammar progress?
--
On Sun, 30 Jun 2002 21:09:40
Sean O'Rourke wrote:
On Sun, 30 Jun 2002, Ashley Winters wrote:
I don't know how the grammars are going, and I'm not fit to write one
myself,
Hey, neither am I, but that hasn't stopped me from taking a stab or two,
figuring that through pain comes fitness. The attempt has certainly given
me a much better understanding of Perl (both 5 and 6) than I had before as
a mere user. If there's anyone else out there with the time for and
interest in working on a Parse::RecDescent grammar, feel free to speak up.
but I wrote a list of variables I'll try to parse using any
grammars which go by. Are all of these legal? I suppose that's more of
a -language question.
Cc'd accordingly.
# need more tests for ${}, I'm not evil enough for it
${foo};
Neither am I, but we might as well throw in {foo}, %{foo}, {foo}, maybe
even $*{foo} (global symbolic reference?).
# Also, there are globals to consider
[...]
And the wonderous *@$*foo (flattened dereferenced global $foo?).
# off the subject, but lets make sure $foo.. is parsed correctly
$foo..1;
$foo..[1];
$.foo..{1};
Color me slow, but are these even legal? What does an anonymous list
constructor do on the LHS of a range operator? I suppose it could just be
one example of something that is always true, but could it possibly be
useful other than by the perversity of overloading ..? And would the
second require whitespace before the '{' to be parsed as a closure/block?
foo{1}; # I ass_u_me {} [] and () can be overloaded?
Blech! Even if it's legal, this seems like it should be a mandatory smack
upside the head. If we allow this, someone will overload {} to do hash
slices on %foo, and we'll be right back to Perl 5 ;).
foo(1);
foo();
Strange overloading again, or am I missing something? If we allow
subscripting and calling to be overloaded on variables with any kind of
sigil, what's the point of having sigils at all?
foo{1}; # foo is unary here
Is this a hash subscript on a no-argument function returning a hash, or a
block passed to foo(block), or a malformed hash constructor being passed
to foo(%hash)? I vote for the first, because I thought blocks' and
hashes' opening brackets always needed preceding whitespace (or at least
/(?!\w){/).
foo.(); # Is this { foo() }() or foo()? I would vote former
aka foo()()? Sick...
# As a final sanity check, lets chain these things
.proc[$*PID].ps.{RSS};
== {.proc()[$*PID].ps().{RSS}}, right?
proc.[$*PID].ps().{RSS};
== {proc().[$*PID].ps().{RSS}}? Or is that '[]' overloaded on a '.'
operator on 'proc'? In either case, we may have to do a sick amount of
look-ahead and guess-work to figure out whether the leading '' is a sigil
or a dereference. Which has higher precedence: prefix '' or infix '.'?
You might also want to add a couple of directly-chained subscriptings,
e.g.
foo[1]{2}(3)[4..6].
/s,
sufferer at the fickle hands of PerlQt.
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Perl 6 grammar progress?
On Sunday 30 June 2002 09:09 pm, Sean O'Rourke wrote:
On Sun, 30 Jun 2002, Ashley Winters wrote:
I don't know how the grammars are going, and I'm not fit to write one
myself,
Hey, neither am I, but that hasn't stopped me from taking a stab or two,
figuring that through pain comes fitness. The attempt has certainly given
me a much better understanding of Perl (both 5 and 6) than I had before as
a mere user. If there's anyone else out there with the time for and
interest in working on a Parse::RecDescent grammar, feel free to speak up.
I don't want to do it in Parse::RecDescent, I want to do it in
Parse::FastDescent! Too bad it's not written yet... Damian?
Neither am I, but we might as well throw in {foo}, %{foo}, {foo}, maybe
even $*{foo} (global symbolic reference?).
$*{foo} was in there, at least. I'm still not quite diabolical to come up with
the really screw-your-parser-up kind of stuff. ${}} and such come to mind,
assuming that's legal.
Also, where does $() come in? Is statement scalarification ever useful outside
a string?
# Also, there are globals to consider
[...]
And the wonderous *@$*foo (flattened dereferenced global $foo?).
I didn't do any sigil stacking at all in there, just context characters. I
don't think there will be much sigil stacking, if any, beyond just stacking
$'s to dereference scalar refs.
# off the subject, but lets make sure $foo.. is parsed correctly
$foo..1;
$foo..[1];
$.foo..{1};
Color me slow, but are these even legal? What does an anonymous list
constructor do on the LHS of a range operator? I suppose it could just be
one example of something that is always true, but could it possibly be
useful other than by the perversity of overloading ..? And would the
second require whitespace before the '{' to be parsed as a closure/block?
Well, perhaps PDL will have a reason to overload .. that way. There's no
reason for the parser to choke on it by default - the compiler certainly
should, though.
As for .{}, that's an interesting thing to ponder. From the apocalypse, it
says a { found where an operator is expected without preceding whitespace
would be considered a subscript. Since '.' or '..' is the operator, the next
brace would *normally* start a hash constructor or sub. I would guess '.'
forces the next opening brace to start a subscript, but without the
whitespace rule.
$foo . { $x + 10 }# really means $foo{$x + 10};
Or maybe using binary . in this fashion is Bad?
foo{1}; # I ass_u_me {} [] and () can be overloaded?
Blech! Even if it's legal, this seems like it should be a mandatory smack
upside the head. If we allow this, someone will overload {} to do hash
slices on %foo, and we'll be right back to Perl 5 ;).
Well it's unambiguous, so I expect someone out there will try to be funky.
foo(1);
foo();
Strange overloading again, or am I missing something? If we allow
subscripting and calling to be overloaded on variables with any kind of
sigil, what's the point of having sigils at all?
There isn't much of a 'point' anymore except overlapping variable names. I
would guess the p52p6 translator could do something silly like this:
#!/usr/bin/perl5
x = (500..800);
$y = $x[rand($#x)];
#!/usr/bin/perl6
$x_array := x_array;
x_array = (500..800);
$y_scalar = $x_array[rand($x_array.length)];
The Highlander RFC (009) suggested making x %x and x all mean $x, and Larry
liked the idea in general, but he wanted to keep them separate because people
were used to it that way. Since $foo can be subscripted in all ways, I can
see how other people might want to subscript % as well. If someone were
particularly perverted, they could make subscripts on foo have reflective
consequences. *shrug*
foo{1}; # foo is unary here
Is this a hash subscript on a no-argument function returning a hash, or a
block passed to foo(block), or a malformed hash constructor being passed
to foo(%hash)? I vote for the first, because I thought blocks' and
hashes' opening brackets always needed preceding whitespace (or at least
/(?!\w){/).
I would guess:
foo{1} = ${ foo() }{1}
foo.{1} = ${ foo() }{1}
foo {1} = foo(sub {1});
foo {a = 1} = foo(hash(a = 1));
foo.(); # Is this { foo() }() or foo()? I would vote former
aka foo()()? Sick...
Hey, it has to mean something.
# As a final sanity check, lets chain these things
.proc[$*PID].ps.{RSS};
== {.proc()[$*PID].ps().{RSS}}, right?
Depends on if .member means {.member()}. I thought .member accesses the
actual data, and .member is the accessor function.
== .proc[$*PID].ps().{RSS}
or .proc().[$*PID].ps().{RSS} via accessor
proc.[$*PID].ps().{RSS};
== {proc().[$*PID].ps().{RSS}}? Or is that '[]' overloaded on a '.'
operator on 'proc'? In either case, we may have to do a sick amount of
look-ahead and guess-work to figure out whether the leading '' is a sigil
or a dereference. Which has higher precedence:
Re: [PATCH] perlarray strange behaviour
Josef Höök wrote: i found some strange behaviour in perlarray.pmc Consider this code: new P0, .PerlArray, 2 # P0[2] set P0, 2, 1 # P0[2] = 1 set P0, -4, 1 # P0[-4] = 1 # Above runs some strange code: # ix += SELF-cache.int_val # where ix is our key # in our case: # ix = -4 + 2 , ix is now -2 # lets se if we have anything at key -2 set I0, P0, -2 print I0 print \n end It runs strange code because it depends upon partially-deprecated code. Try 'set P0[2], 1' and 'set I0,P0[-2]'... I also note that P0[-4] should likely throw an exception when we are able to test for exceptions. The deprecated code should probably be removed, although I imagine we'll find a new use for them later on. Catching up on a week's worth of email here... -- Jeff [EMAIL PROTECTED]
