Implementing Nickle
Not sure if this has been flagged up here or not yet, but it looks interesting: http://nickle.org/implement/html For non-local jumps caused by break, continue and return statements, Nickle automatically builds a continuation if necessary to ensure that intervening twixt blocks are executed appropriately. This is statically decidable because all of the possible twixt blocks are statically visible from the source statement and the compiler inserts appropriate Unwind instructions which count the number of nesting catch/twixt blocks. The continuation data structure is shared with threads, twixts and catches. Continuations contain the instruction pointer, frame pointer, stack, catches and twixts. Threads contain additional scheduling state. Twixts contain additional instruction pointers that point to the start of the enter and leave blocks. Catches are labeled with the exception they catch. Continuations are directly embedded in these other structures to reduce memory allocator overhead and pointer dereferencing in the interpreter Nickle seems a pretty funky language. Might be a good match for Parrot. -- DYSFUNCTION: The Only Consistent Feature of All of Your Dissatisfying Relationships is You. http://www.despair.com
Re: [PATCH] Add IMCC tests to make test (Revised)
Leopold Toetsch [EMAIL PROTECTED] writes: Andy Bussey [EMAIL PROTECTED] wrote: Here's a revised patch to add the IMCC tests to 'make test' and 'make fulltest' - this time patched against root.in. Thanks, applied. t/syn/file.t relies on . being in path (in the 3 system(imcc...) calls), so make test fails for me (and for some of the tinderboxen, it seems). -- Lars Balker Rasmussen Consult::Perl
Re: set vs. assign, continued: 'add' vs. 'add!'
Benjamin Goldberg wrote:
Brent Dax wrote:
TOGoS:
# When I say in IMCC:
#
# $P0 = $P1 + $P2
#
# , I expect it to create a new value and store it in
# $P0, not give me a segfault because I didn't say
#
# $P0 = new figure out what the heck type
# $P0 is supposed to be based
# on the types of $P1 and $P2
#
# first.
Then your expectations are wrong.
I think you may be losing sight of the fact that most users will *never*
interact with PASM or PIL directly. Most users will have a
parser/compiler/optimizer between them and PIL--one that was written,
tested and debugged by experts. The few people who work with raw
assembly or IL should know what they're doing. While I have no problem
with IMCC-time warnings about constructs like this (Use of
uninitialized register $P0 in add), I don't think we should coddle the
user at this level.
Moreover, there really isn't any way to do what you want to do here.
There is no way for the add opcode to intuit what type should be put
into $P0.
Noone is saying that the add opcode *should* try to intuit that -- he's
trying to say that there should be two versions of the add opcode, one
of which uses assign semantics, and the other of which uses set
semantics.
That's ultimately the host language's decision, not Parrot's,
and the host language may have complicated rules to decide it.
It would be the host language's decision about which opcode to use.
I suppose that if one writes:
$P0 = $P1 + $P2
, then it might be parrot's (imcc's) decision about which opcode to
compile it to... but of course, the host language can avoid that
ambiguity by writing it out explicitly, as add_set( $P0, $P1, $P2 ) or
add_assign( $P0, $P1, $P2 ). Or perhaps, require some pragma
indicating to imcc that all $Px = $Py + $Pz should use the add or assign
versions of the ops.
Hmm... I just thought of something. Since 'set' semantics can be easily
simulated when we have only ops for 'assign' semantics, maybe imcc
itself could do this for us.
That is, by default,
$P0 = $P1 + $P2
will be translated by imcc into
add $P0, $P1, $P2
but, if some command is given to imcc, then it will be translated into
new $P0, .PerlUndef
add $P0, $P1, $P2
Or, instead of PerlUndef, the command to change to set semantics would
indicate what to put into $P0 prior to using it as the target of an add
(so we can initialize $P0 with any of PerlInt, PerlNum, BigInt,
BigFloat, BigRat, ContinuedFraction, etc.)
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: there's no undef!
Michal Wallace wrote:
Uh-oh. I just went to implement del x
and there's no op to remove a variable
from a lexical pad! :)
Why would you want to remove a variable from a lexical pad?
Surely the right thing to do would be to create a new pad (scope),
then add your 'x' variable which you plan to 'delete' in the future,
then when you want to delete that variable, pop off that pad.
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: set vs. assign, continued: 'add' vs. 'add!'
Benjamin Goldberg writes:
Hmm... I just thought of something. Since 'set' semantics can be easily
simulated when we have only ops for 'assign' semantics, maybe imcc
itself could do this for us.
That is, by default,
$P0 = $P1 + $P2
will be translated by imcc into
add $P0, $P1, $P2
but, if some command is given to imcc, then it will be translated into
new $P0, .PerlUndef
add $P0, $P1, $P2
Or, instead of PerlUndef, the command to change to set semantics would
indicate what to put into $P0 prior to using it as the target of an add
(so we can initialize $P0 with any of PerlInt, PerlNum, BigInt,
BigFloat, BigRat, ContinuedFraction, etc.)
Hmm, I wonder whether this is the right approach. What about operator
overloading? Let's say Python overloads + (can it do that?) and passes
that variable to Perl. If Perl creates a .PerlUndef and assigns to it,
you lose the overloaded semantics.
I don't know... I think using vtable multimethods would be the best way
to go wrt these things.
Luke
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Calling parrot from C?
Togos wrote:
--- Sean O'Rourke [EMAIL PROTECTED] wrote:
Luke Palmer [EMAIL PROTECTED]
writes:
How does one call a parrot Sub from
C and get the
I'd vote for stuffing args into the
interpreter, calling the sub's invoke()
method, then digging through the registers
to pull out the return values (see e.g.
Parrot_pop_argv in method_util.c, which
may be outdated). Then again, it would be
_your_ pain, not mine ;).
The Parrot-C interface could simply come with
some wrapper functions that would do this for
you. I suppose this could be done with a couple
printf/scanf-like functions, except they would
work with pcc parameters instead of strings.
Would that be a printf-like to put args onto the stack, with the format
string being the subroutine's prototype, and a scanf-like to get return
values from the stack, with the format string being the return context?
If we didn't have NCI, using these two functions in the other order (to
get the arguments passed in, then to return values) might be useful for
functions which want to be called from Parrot.
Hmm... even with the existance of NCI, doing that might be useful --
having a function process it's arguments itself, rather than having NCI
do it, might be more efficient.
Oh, and maybe this idea could probably replace pxs.c?
(This would probably tie in to the subroutine
signatures discussed in 'calling conventions,
variable-length parameter lists'.)
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Timely Destruction: An efficient, complete solution
Luke Palmer wrote: Here comes that ever-reincarnating thread again, sorry. This is a proposal for an efficient solution to the timely destruction problem, which doesn't use refcounting, and fits in to the current scheme pretty well. It is based on the fact that 90% of the time (or more), all objects needing timely destruction will be found live. It uses a priority method to try to find these objects quickly, and ceases if it does. This behavior is only carried out if the DOD was invoked by Csweep 0. There is an external list of objects needing timely destruction, which is not walked by DOD. Each object has a DOD_high_priority_FLAG. Each time an impatient object is created, its high_priority_FLAG is set. As everything is walked, if an object with this flag set is encountered, whichever thing referenced it also gets the flag set[1]. The DOD queue has two segments: high_priority and low_priority. high_priority is always drained and processed first. All this, I understand so far. When this portion of the queue is completely drained, the external list of impatient objects is checked. If every object has been marked live, DOD terminates This, I don't understand. Why do we stop DoD here? Shouldn't we try and free up some of the non-impatient objects? [insert sound of gears turning] OIC... if this is only for sweep 0, then we haven't really *asked* to try and free up the impatient objects; we've only asked to free up those objects needing timely destruction. (and GC is not allowed to run, because that would result in a lot of wrongly murdered objects). I don't understand this, though. Why would GC murder something, if that something has been marked as live? Or do you mean, if we stoped DoD in the middle, then obviously don't follow it with the GC that normally follows a DOD. That makes sense, though I think that skipping GC after an *incomplete* DOD is a sufficiently obvious thing that it needn't be mentioned ;) If there are dead objects in that list, DOD continues and does a full sweep. When you say, DOD continues, I assume you mean that we now drain the low priority queue. I assume that it's *this* part of the DOD, when, if we now encounter something with a high_priority flag set, we set the high_priority flag of the object which can reach it. (Certainly not when we're draining the high priority queue: all the things doing the reaching there already have the high_priority flag set on them). When an impatient object is destructed, it might be good to reset all high_priority_FLAGs, except for other impatient objects, so there is nothing being walked at high priority that doesn't deserve it. Or, set a global (per-interpreter) flag indicating that an impatient object has been destructed, and all high_priority_FLAGs need to be reset at the beginning of the next DoD run. That's it. The first few times Csweep 0 is run, it will take just as long as Csweep 1, but the priorities will propogate down to things in the root set, and it will begin to speed up. And the algorithmic complexity never exceeds that of a regular sweep[2]. I do see a potential problem: Suppose that a highly visible PMC (one reachable through lots of objects) is able to reach a PMC needing timely destruction, and then a sweep 0 is done, and afterwards that highly visible PMC changes so it no longer can reach the object needing timely destruction. It still has it's high_priority flag set, and this will propogate into the many things which will reach it, eventually going into the root set. And the more things which (incorrectly) end up in the high priority queue instead of the low priority queue, the closer it's speed will be to a regular sweep. I can think of a workaround, but it would cost more memory. Specifically, make the priority an actual number, which decreases with the distance away from an object needing timely destruction (e.g., one less than the max of the priorities of the objects we can reach). If an object needs timely destruction, it's priority is fixed at MAX_INT. PMCs which used to be able to reach things needing timely destruction, but no longer can, will thus no longer have high priorities. An advantage of this is that if an object needing timely destruction is destructed, then we no longer need to clear the priorities of all PMCs; most of the priorities (the ones leading to other objects needing timely destruction) are still good, and the priorities going to the destructed PMc will eventually decrease. An improvment that can be made, if numeric priorities are used, would be to make the high priority queue into an actual priority queue. Although the algorithmic complexity will be higher than that of a regular sweep, the objects needing timely destruction will be reached faster, since the search is directed straight at them. For any scheme (yours scheme, my suggested modification, or anything else), a potential improvment to the speed of
Re: set vs. assign, continued: 'add' vs. 'add!'
Luke Palmer wrote:
Benjamin Goldberg writes:
Hmm... I just thought of something. Since 'set' semantics can be
easily simulated when we have only ops for 'assign' semantics, maybe
imcc itself could do this for us.
That is, by default,
$P0 = $P1 + $P2
will be translated by imcc into
add $P0, $P1, $P2
but, if some command is given to imcc, then it will be translated into
new $P0, .PerlUndef
add $P0, $P1, $P2
Or, instead of PerlUndef, the command to change to set semantics would
indicate what to put into $P0 prior to using it as the target of an
add (so we can initialize $P0 with any of PerlInt, PerlNum, BigInt,
BigFloat, BigRat, ContinuedFraction, etc.)
Hmm, I wonder whether this is the right approach. What about operator
overloading? Let's say Python overloads + (can it do that?) and passes
that variable to Perl. If Perl creates a .PerlUndef and assigns to it,
you lose the overloaded semantics.
Eh? I would think that if Python overloads +, then that means it's
creating a PMC with a vtable-add different from a normal addition
operation. If we assign that pmc to a pmc which was PerlUndef, then
the vtable (pointer) gets assigned, too. Doesn't it?
Unless you mean, let's say Python makes a pmc with an unusual vtable,
and overloads vtable-add in such a way that it expects it's target to
be a something pmc, but instead, we pass in a PerlUndef. If
vtable-add doesn't bother checking that the target isn't the right
type, then it's broken. It should either throw an exception if it's not
what's wanted, or else mutate/promote that PerlUndef to the right type.
I don't know... I think using vtable multimethods would be the best way
to go wrt these things.
Umm, I didn't think that I was suggesting something else -- I was
suggesting merely that imcc can be told to produce to pretend that +, -,
and other mathematical operations have set semantics, and have it
produce parrot ops to support that pretense. Within parrot, the add
op would still be the same as it always has been (merely calling the
vtable-add method). And I'm not suggesting that the vtables be
changed. The only difference would be, *if* that command had been given
to imcc, then any add op in the bytecode, which had originally been
spelled as + in the pir code, would be preceded by a new op (put
there by imcc).
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: there's no undef!
On Sun, 17 Aug 2003, Benjamin Goldberg wrote: Michal Wallace wrote: Uh-oh. I just went to implement del x and there's no op to remove a variable from a lexical pad! :) Why would you want to remove a variable from a lexical pad? Surely the right thing to do would be to create a new pad (scope), then add your 'x' variable which you plan to 'delete' in the future, then when you want to delete that variable, pop off that pad. Hmm. Do you mean if for stmt in block: if stmt.type == undef: flag_as_going_to_delet(stmt.varname) So I can create a new pad when it's assigned? It can't be a simple pop though, can it? #!/usr/bin/perl $x = cat; $y = pop $x?; undef $x; print x = $x \n; print y = $y \n; Because here, $x has to be defined before $y, so I'd have to delete the -2nd scope. Unless the code was smart enough to work out that y is in -2 and x is in -1... In any case, what does it buy me? it seems like a lot of work when there's already a delete_keyed op, and leo just made an implementation for pads. :) I guess in perl it's not bad, since that's the whole point of undef, you can just $x = PerlUndef it... But in python, this throws a NameError: x = 1 del x x So the easiest thing to me is just to translate del x as remove this from the current pad. Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: set vs. assign, continued: 'add' vs. 'add!'
On Sun, 17 Aug 2003, Luke Palmer wrote: Benjamin Goldberg writes: Hmm... I just thought of something. Since 'set' semantics can be easily simulated when we have only ops for 'assign' semantics, maybe imcc itself could do this for us. That is, by default, $P0 = $P1 + $P2 will be translated by imcc into add $P0, $P1, $P2 but, if some command is given to imcc, then it will be translated into new $P0, .PerlUndef add $P0, $P1, $P2 Or, instead of PerlUndef, the command to change to set semantics would indicate what to put into $P0 prior to using it as the target of an add (so we can initialize $P0 with any of PerlInt, PerlNum, BigInt, BigFloat, BigRat, ContinuedFraction, etc.) Hmm, I wonder whether this is the right approach. What about operator overloading? Let's say Python overloads + (can it do that?) and passes that variable to Perl. If Perl creates a .PerlUndef and assigns to it, you lose the overloaded semantics. Sure, you can do that in python: class Add: ...def __add__(self, other): ...print we don't need no steenkin, other ... x = Add() x + 1 we don't need no steenkin 1 But if you know the types of the objects, it makes sense to do the change Benjamin is talking about. So this probably ought to be done at the AST code generation level. Leo sent me a patch that does some basic type inference in pirate and figures out when not to generate the extra PerlUndef. It's in the method binaryExpression. (It's just not used yet because at the time it wasn't compatible with the way I was handling expressions; I've been trying to get my code to work his way, but didn't go back and check whether it worked yet.) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: there's no undef!
Michal Wallace wrote:
On Sun, 17 Aug 2003, Benjamin Goldberg wrote:
Michal Wallace wrote:
Uh-oh. I just went to implement del x
and there's no op to remove a variable
from a lexical pad! :)
Why would you want to remove a variable from a lexical pad?
Surely the right thing to do would be to create a new pad (scope),
then add your 'x' variable which you plan to 'delete' in the future,
then when you want to delete that variable, pop off that pad.
Hmm. Do you mean
if for stmt in block:
if stmt.type == undef:
flag_as_going_to_delet(stmt.varname)
So I can create a new pad when it's assigned?
Right. You'd create a new pad just before the for, and put stmt
into it. After the for loop ends, you pop off that pad.
It can't be a simple pop though, can it?
Why not?
#!/usr/bin/perl
$x = cat;
$y = pop $x?;
undef $x;
print x = $x \n;
print y = $y \n;
Because here, $x has to be defined before $y, so
I'd have to delete the -2nd scope. Unless the
code was smart enough to work out that y is in
-2 and x is in -1...
These are dynamic variables here; could you give an example of what
you're trying to do with lexicals (my variables)? And remember, undef
doesn't get rid of a variable; it merely stores an undef value into it.
I mean, consider:
#!/usr/bin/perl
use strict;
{ my $x = cat;
{ my $y = pop $x;
# $x and $y are both in scope.
undef $x;
# $x and $y are still both in scope.
$x = 2; # no error here!
} # $y goes out of scope.
$x = 42; # ok.
$y = 6*9; # but this is an error.
} # $x goes out of scope now.
$x = 13; # this is an error.
__END__
There's no way, in this program, for $x to be out of scope while $y is
in scope.
In any case, what does it buy me? it seems like a
lot of work when there's already a delete_keyed
op, and leo just made an implementation for pads. :)
I guess in perl it's not bad, since that's the
whole point of undef, you can just $x = PerlUndef
it... But in python, this throws a NameError:
x = 1
del x
x
So the easiest thing to me is just to translate
del x as remove this from the current pad.
Maybe. But, what happens with:
x = 1
y = lambda: x
del x
z = y()
Does/should this also throw a NameError?
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: there's no undef!
On Mon, 18 Aug 2003, Benjamin Goldberg wrote:
Hmm. Do you mean
if for stmt in block:
if stmt.type == undef:
flag_as_going_to_delet(stmt.varname)
So I can create a new pad when it's assigned?
Right. You'd create a new pad just before the for, and put stmt
into it. After the for loop ends, you pop off that pad.
It can't be a simple pop though, can it?
Why not?
Because in my examples, I don't see how you know
it's the topmost lexical pad.
These are dynamic variables here; could you give an example of what
you're trying to do with lexicals (my variables)?
Sure.
It does the exact same thing if you put my in front of each variable:
#!/usr/bin/perl
my $x = cat;
my $y = pop $x?;
undef $x;
print x = $x \n;
print y = $y \n;
And remember, undef doesn't get rid of a variable; it merely stores
an undef value into it.
But it has the same effect as getting rid of the variable,
since a variable that doesn't exist also returns undef. :)
I mean, consider:
#!/usr/bin/perl
use strict;
{ my $x = cat;
{ my $y = pop $x;
# $x and $y are both in scope.
undef $x;
# $x and $y are still both in scope.
$x = 2; # no error here!
} # $y goes out of scope.
$x = 42; # ok.
$y = 6*9; # but this is an error.
} # $x goes out of scope now.
$x = 13; # this is an error.
__END__
There's no way, in this program, for $x to be out of scope while $y is
in scope.
Yes, but this is just normal lexical scoping behavior.
I'm already doing the same thing for python.
You say that in perl, undef $x means $x = PerlUndef, which
is fine. But in python, that's not the case. del x gets
rid of the variable, so that the next find_lex should throw
a NameError. I don't see the point in creating an extra
lexical scope for every variable that gets deleted.
And that's not what you're telling me anyway.
In your innermost block, you're telling me that on the
python equivalent of the undef $x line i should be
popping off a lexical pad in python. I'm saying
that's not the case. I should be removing x from the
lexical pad. If perl does the same thing, then you
get the same behavior as undef x, because an unfound
lexical in perl just returns PerlUndef anyway.
x = 1
del x
x
So the easiest thing to me is just to translate
del x as remove this from the current pad.
Maybe. But, what happens with:
x = 1
y = lambda: x
del x
z = y()
Does/should this also throw a NameError?
Looks like it:
x = 1
y = lambda : x
del x
z = y()
Traceback (most recent call last):
File stdin, line 1, in ?
File stdin, line 1, in lambda
NameError: global name 'x' is not defined
Anyway, the short answer is I'm happy with the
solution I've got now. It's easy and it does
what I expect. But I'll happily change it if
you send me a patch. :)
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-
contact: [EMAIL PROTECTED]
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--
Re: Testing for valid path names in CPAN distributions
Andrew savige wrote in perl.qa : Running variants of: tar tzf perl-5.8.0.tar.gz | perl -lne'print if tr|-_./a-zA-Z0-9||c' suggests only [-_./a-zA-Z0-9] are valid characters in a path name. Then I noticed 'perldoc perlport' lists the portable filename characters as defined by ANSI C and various other restrictions. What is the length limit of each path name component? What is the length limit of file extensions? I heard YAML changed from .yaml to .yml, for instance, yet Perl itself has many files with long extensions -- runtime.porting, for example. Also, don't ever include files that differ only by case. In the perl source distribution, Porting/check83.pl checks that filenames are friendly to 8.3 filesystems. What you want is probably more complex : a test to see if a *set* of filenames is portable. It'd be nice to have a standard test for valid portable path names. Does such a test exist? I noticed Archive::Any has is_impolite() and is_naughty() but didn't see any checks for basic path name validity. BTW, is Archive::Any a dead camel?
Some warnings
I decide to lay out warnings I get while building Parrot. this might be Leo's property: packfile.c(1225) : warning C4700: local variable 'num_segs' used without having been initialized And this, to learn from Simon, is Brent's one spf_render.c(578) : warning C4761: integral size mismatch in argument; conversion supplied It seems like yet another Leo's warnings imclexer.c(2264) : warning C4273: 'isatty' : inconsistent dll linkage. dllexport assumed. Umm ... I am at a loss to say who is the author of this one cfg.c(514) : warning C4761: integral size mismatch in argument; conversion supplied One more unidentified warning: parser_util.c(219) : warning C4090: '=' : different 'const' qualifiers That's all.
Re: keyed vtables
Dan Sugalski [EMAIL PROTECTED] wrote: At 6:06 PM +0200 8/16/03, Leopold Toetsch wrote: How long does it take to compile core_ops_cg.c with 60 times the opcode, we now have? We'll only have double the number of ops (since we did decide, ages ago, that if one PMC in an all-PMC operation was accessed via key that they all would) so it's not a factor of 60 explosion. To handle all cases with one additional opcode per operation means, that we only have the general form with a Key PMC per argument. This requires the construction of keys (even NULL keys?) for each argument. Constructing these keys (albeit at load time) isn't free. Where we now have an optimized keyed_int opocde, the 3-key variant needs a full PMC key, just holding an immediate constant. To handle all permutations of keyed/non-keyed, each of these vtables has to check, if the associated argument key is NULL or not, which further slows things down. ... Even if it was, I'm not worried about the time to compile parrot. That's something that happens once, for any installation, so the compile time's generally irrelevant. Yeah, it's a problem for us, but we can deal. This generally irrelevant is going to hit me 20 times a day (or, if we have the opcode explosion, a cron job is compiling Parrot during the night - once) Can you provide an 8-way eServer 325 with plenty of RAM or some such for developers? What aboud cache locality? This won't generally be an issue--either the functions get used a lot, What is the general usage of these ops? Where do you see this big advantage of bloating the core? What about final executable size (with speciall respect to embbeding Parrot in some small devices)? That's definitely an issue, yes. This is something that someone looking to embed parrot into small devices may want to look at chopping out. 2 variants of our classes and ops? One with and one without multi-keyed? Who is getting to manage that? The only difference of my proposal and the mulit-keyed variants are 3 additional opcodes, which doesn't really count - we have a really fast opcode dispatch: And semantic differences--don't forget those. A keyed add vtable doesn't help to provide more semantics. The set vs assign thread applies here too. On the contrary: to provide all semantics you would need add_set_p_k_p_k_p_k and add_assign_p_k_p_k_p_k and possibly add_clone_p_k_p_k_p_k. leo
Re: getprop and find_lex?
Michal Wallace [EMAIL PROTECTED] wrote: I expected getprop to behave like find_lex and throw an exception if the property doesn't exist, but it doesn't: Cfind_global returns a PerlUndef on failure, which isn't what I would expect (compared to Cfind_lex) either. leo
Timely Destruction: An efficient, complete solution
Here comes that ever-reincarnating thread again, sorry. This is a proposal for an efficient solution to the timely destruction problem, which doesn't use refcounting, and fits in to the current scheme pretty well. It is based on the fact that 90% of the time (or more), all objects needing timely destruction will be found live. It uses a priority method to try to find these objects quickly, and ceases if it does. This behavior is only carried out if the DOD was invoked by Csweep 0. There is an external list of objects needing timely destruction, which is not walked by DOD. Each object has a DOD_high_priority_FLAG. Each time an impatient object is created, its high_priority_FLAG is set. As everything is walked, if an object with this flag set is encountered, whichever thing referenced it also gets the flag set[1]. The DOD queue has two segments: high_priority and low_priority. high_priority is always drained and processed first. When this portion of the queue is completely drained, the external list of impatient objects is checked. If every object has been marked live, DOD terminates (and GC is not allowed to run, because that would result in a lot of wrongly murdered objects). If there are dead objects in that list, DOD continues and does a full sweep. When an impatient object is destructed, it might be good to reset all high_priority_FLAGs, except for other impatient objects, so there is nothing being walked at high priority that doesn't deserve it. That's it. The first few times Csweep 0 is run, it will take just as long as Csweep 1, but the priorities will propogate down to things in the root set, and it will begin to speed up. And the algorithmic complexity never exceeds that of a regular sweep[2]. Luke [1] This probably has to be done when the object is enqueued, not dequeued. I don't know whether this impacts performance significantly. See [2]. [2] Although a single cycle of the algorithm becomes more complex, so it will slow things down a little when it's not doing any good. But at the expense of a little templating, these checks could be eliminated when the sweep wasn't triggered by Csweep 0.
Re: [perl #23276][PATCH] Prefixing #define names
Vladimir Lipskiy [EMAIL PROTECTED] wrote: This patches touches 22 files and deals with -DHAVE_COMPUTED_GOTO -DHAS_JIT -DGC_IS_MALLOC Doesn't compile. Its seems to be the #ifdef vs #if issue. leo
[perl #23346] [PATCH] docs/running.pod: command line arguments
# New Ticket Created by Kenneth A Graves # Please include the string: [perl #23346] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23346 I was trying to figure out how to access argv from within parrot code, and didn't see anything in the docs. So I started thinking about how to implement it, only to stumble over the appropriate bit of embed.c. It's already there. Now that I know it's there, I can find appropriate clues in docs/debugging.pod and languages/imcc/docs/running.pod. I think a more explicit mention in docs/running.pod would be good, hence the patch below. Should the word argv be explicitly mentioned, or is command line arguments clear enough? --kag -- attachment 1 -- url: http://rt.perl.org/rt2/attach/62889/46287/02e16c/running.patch --- running.pod.~1.15.~ 2003-08-12 11:00:03.0 -0400 +++ running.pod 2003-08-16 23:05:06.0 -0400 @@ -27,6 +27,14 @@ This creates a bytecode file called Cfoo.pbc, but does not execute it. +Any command line arguments from the filename on are passed into +the program in PMC register P0. For the invocation: + + parrot foo.pbc --foo_arg process_me.foo + +P0 would have three string elements: Cfoo.pbc, C--foo_arg, and +Cprocess_me.foo. + Cparrot has four different opcode dispatchers: normal, computed goto, prederef, and JIT. The default mode is normal, or computed goto if that is supported by your compiler (gcc supports it). You may pass
Re: set vs. assign, continued: 'add' vs. 'add!'
Dan Sugalski wrote: No. It isn't, and JITting doesn't have anything to do with this. The issue is expressable semantics, and in languages with active data (which encompasses a number of the languages we're interested in, icluding perl, python, and ruby) not allowing direct access to members of an aggregate makes doing things with that aggregate both slower and far more convoluted in a number of ways. Would you please give an example of active data and why one needs the keyed ops to deal with it? I for one am too heavily entenched in static languages and do not honestly know. Matt
[PATCH] Deprecated compiler flag on MS Windows w/ ActiveState perl
Hi! I'm using a current MS compiler (Version 13.10.3077) and ActiveState Perl 5.8.0 (Build 806) to compile parrot. The compiler warns about c1 : warning C4349: /Gf is deprecated and will not be supported in future versions of Visual C++; remove /Gf or use /GF instead which is specified by ActiveState Perl $perl -V:ccflags ccflags='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX'; The attached patch replaces /Gf with /GF for compiler versions = 13. Ron mswin_hints.patch Description: Attached file: mswin_hints.patch
[PATCH] imcc vim syntax file
FWIW, here's my personal imcc syntax highlighting file for vim. I've
found it very useful in reading imc code (but then, I'm very attached
to my syntax highlighting).
I'm still not sure how to add new files with cvs diff, so I used a
normal diff against /dev/null.
Enjoy,
Luke
--- /dev/null 1969-12-31 17:00:00.0 -0700
+++ editor/imc.vim.in 2003-08-17 08:42:24.0 -0600
@@ -0,0 +1,71 @@
+ Vim syntax file
+ Language:Parrot IMCC
+ Maintainer: Luke Palmer [EMAIL PROTECTED]
+ Last Change: 2003 Jun 4
+
+ For version 5.x: Clear all syntax items
+ For version 6.x: Quit when a syntax file was already loaded
+ if version 600
+ syntax clear
+ elseif exists(b:current_syntax)
+ finish
+ endif
+
+syntax clear
+
+syn keyword imcTypeint float string
+syn keyword imcPMC Array Boolean Compiler Continuation Coroutine CSub
+syn keyword imcPMC Eval IntList Iterator Key ManagedStruct MultiArray
+syn keyword imcPMC NCI PerlArray PerlHash PerlInt PerlNum PerlString
+syn keyword imcPMC PerlUndef Pointer Scratchpad Sub UnManagedStruct
+
+syn keyword imcOp call goto if unless global clone addr
+
+syn match imcDirective /\.\(sub\|end\|emit\|eom\)/
+syn match imcDirective /\.\(local\|sym\|const\)/
+syn match imcDirective /\.\(namespace\|endnamespace\)/
+syn match imcDirective /\.\(param\|result\|arg\|return\)/
+syn match imcDirective /\.\(include|pcc_begin|pcc_end\)/
+syn keyword imcDirectivenon_prototyped prototyped
+
+syn match imcComment/#.*/
+syn match imcLabel /[A-Za-z0-9_]\+:/he=e-1
+syn match imcRegister /[INPS]\([12][0-9]\|3[01]\|[0-9]\)/
+syn match imcDollarRegister /\$[INPS][0-9]\+/
+syn match imcNumber /[0-9]\+\(\.[0-9]*\([Ee]-\?[0-9]\+\)\?\)\?/
+syn match imcNumber /0x[0-9a-fA-F]\+/
+syn match imcNumber /0b[01]\+/
+syn match imcWord /[A-Za-z_][A-Za-z0-9_]*/
+
+syn region imcString start=// skip=/\\/ end=//
+syn region imcString start=/'/ end=/'/
+
+ Define the default highlighting.
+ For version 5.7 and earlier: only when not done already
+ For version 5.8 and later: only when an item doesn't have highlighting yet
+if version = 508 || !exists(did_pasm_syntax_inits)
+ if version 508
+let did_pasm_syntax_inits = 1
+command -nargs=+ HiLink hi link args
+ else
+command -nargs=+ HiLink hi def link args
+ endif
+
+ HiLink imcWordNormal
+ HiLink imcComment Comment
+ HiLink imcLabel Label
+ HiLink imcRegisterIdentifier
+ HiLink imcDollarRegister Identifier
+ HiLink imcTypeType
+ HiLink imcPMC Type
+ HiLink imcString String
+ HiLink imcNumber Number
+ HiLink imcDirective Macro
+ HiLink imcOp Conditional
+
+ delcommand HiLink
+endif
+
+let b:current_syntax = imc
+
+ Ops -- dynamically generated from ops2vim.pl
--- /dev/null 1969-12-31 17:00:00.0 -0700
+++ editor/ops2vim.pl 2003-08-17 08:30:56.0 -0600
@@ -0,0 +1,17 @@
+#!/usr/bin/perl
+
+my $cline = my $prefix = 'syn keyword imcOp';
+
+my %seen;
+
+while () {
+if (/\bop \s+ (\w+) \s* \(/x) {
+next if $seen{$1}++;
+if (length($1) + length($cline) 72) {
+print $cline\n;
+$cline = $prefix;
+}
+$cline .= $1;
+}
+}
+print $cline\n;
--- /dev/null 1969-12-31 17:00:00.0 -0700
+++ editor/Makefile 2003-08-17 08:51:31.0 -0600
@@ -0,0 +1,5 @@
+all: imc.vim
+
+imc.vim: imc.vim.in ../*.ops
+ cp -f imc.vim.in imc.vim
+ perl ops2vim.pl ../*.ops imc.vim
POW (Parrot On Win32) Available
Hi, A little while back I said I'd start making regular binary builds of Parrot for those on Win32 who don't want to or can't compile Parrot for whatever reason. I've finally found the time to sort this out, and my first attempt is available. You can download it at:- http://www.jwcs.net/developers/perl/pow/download/pow-0.0.10-2003-08-16.zip I've also put up a couple of pages on the web about it at:- http://www.jwcs.net/developers/perl/pow/ From which you can always find links to the very latest distribution. FYI, JWCS.NET Ltd is my company, and we're more than happy to provide the disk space, bandwidth and so on to host this download and its related pages. I hope this helps someone out there, and would love to hear any feedback on this so I can improve future distributions Take care, Jonathan
Re: keyed vtables
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: And semantic differences--don't forget those. A keyed add vtable doesn't help to provide more semantics. The set vs assign thread applies here too. On the contrary: to provide all semantics you would need add_set_p_k_p_k_p_k and add_assign_p_k_p_k_p_k and possibly add_clone_p_k_p_k_p_k. If I'm on target, what Dan's trying to avoid is having to create magic proxy objects for autovivification. If this is all we want out of keyed ops, then we can get it more cheaply by only adding keyed variants for the _out_ parameters of each op. That way the standard get_*_keyed ops can either return NULL, return a new PMC without insertion, or insert and return a new PMC for read parameters, while the *_pk_*_* ops can do the right thing with respect to autovivification. No temporary keys or null keys need be created. I think this covers the semantics. Beyond that, it's just a matter of performance -- extra opcodes vs. extra ops -- that we can fight out in the benchmark arena. /s
bug with parrot -O2
I haven't looked into this at ALL, but I was curious about the IMCC optimization flags: [~/pirate]: ./pirate.py -d weightless.py weightless.imc [~/pirate]: parrot weightless.imc ended with: L 450 total time: 23 [~/pirate]: parrot -O=1 weightless.imc ended with: L 450 total time: 22 [~/pirate]: parrot -O=2 weightless.imc get_pmc_keyed() not implemented in class 'PerlInt' Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: [perl #23346] [PATCH] docs/running.pod: command line arguments
Kenneth A Graves (via RT) [EMAIL PROTECTED] writes: Should the word argv be explicitly mentioned, or is command line arguments clear enough? Thanks, applied (w/ mention of argv). /s
Re: [PATCH] imcc vim syntax file
Luke Palmer [EMAIL PROTECTED] writes: FWIW, here's my personal imcc syntax highlighting file for vim. I've found it very useful in reading imc code (but then, I'm very attached to my syntax highlighting). Auto-generated editor configuration? Cool... I'm still not sure how to add new files with cvs diff, so I used a normal diff against /dev/null. `-N' Applied, /s
Re: bug with parrot -O2
Michal Wallace [EMAIL PROTECTED] wrote: I haven't looked into this at ALL, but I was curious about the IMCC optimization flags: Its barely tested and in an early stage. Anyway -O2c works. Sincerely, Michal J Wallace leo
