Re: [PATCH] Re: Arrays of PMCs
Steve Fink <[EMAIL PROTECTED]> writes: > On Mon, Apr 22, 2002 at 05:40:09PM +0100, Piers Cawley wrote: >> Does anyone have an idea of when we're going to see these? Or hashes >> of PMCs, I don't really care which... > > Well, we don't have hashes of anything. We already have arrays of > PMCs. You just can't get the PMCs out, only their integer or numeric > values. :-) > > True arrays of PMCs should probably be blocked on the whole keyed > thing. Keyed access is partially implemented, but there's way too much > manual code repetition at the moment, and the assembly syntax is > wrong: > > EVENTUAL CURRENT > set I0, P0[7] get_keyed I0, P0, 7 > set P0[7], I0 set_keyed P0, 7, I0 > set P0[0], P1[1]not possible > set I0, P0[P1] not possible -- I'm not even sure what this will do > set P1, P0[7] get_keyed P1, P0, 7 (requires the recently committed patch) > set P0[7], P1 set_keyed P0, 7, P1 (requires the recently committed patch) The last two are the only ones I need, and the first 'impossible' one can be worked 'round with: get_keyed P2, P1, 1 set_keyed P0, 0, P2 Which is vaguely annoying, but at least workable. > So far, I've just kind of thrown in more and more [sg]et_keyed > variants as they were needed. To continue in this grand tradition, > I've just committed a patch to allow getting and setting of the PMCs > in arrays. However, I'm not really sure how 'set P0[7], P1' is > supposed to behave. I just overwrite the whole P0[7] array slot, > discarding the previously held PMC. That's good enough for me in the short term. I doubt it's good enough long term though... > I don't remember the whole 'set P0, P1' discussion well enough to > venture an opinion on whether the previous occupant gets to have a > say in what happens. Nor me. > This code now works: > > # P0 is initialized to an array containing the command-line arguments > new P1, PerlArray > set_keyed P1, 0, P0 # set P1[0], P0 > get_keyed P31, P1, 0 # set P31, P1[0] > get_keyed S0, P31, 0 # set S0, P31[0] > print "Command name: " > print S0 > print "\n" > end Nice. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Using Parrot
On Tue, 2002-04-23 at 19:43, Dan Sugalski wrote: > At 6:19 PM +0100 4/19/02, Alberto Manuel Brandão Simões wrote: > >But, this e-mail is not to say this, but to request some kind of help. > >I'm used to check-out, compile and test parrot, looked at the language > >(well, a long time ago) and I'm needing to look to it again. The > >question is, what documents do you think I should read to start quickly > >using Parrot? PDD's, any pod from Parrot cvs tree... any other thing? > > Did you get sufficient information? If not, where have we left gaps? > I start reading documents about the parrot assembler itself. At the moment I'm trying to understand PMC's. My idea is that they are objects... but still doesn't understand how to use them. I think some more dedicated time and I'll get into it! Thanks for the interest. When I put some think on the air, I'll let you know. Thanks Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: Mutable vs immutable strings
I vote for mutable strings. Anything but immutable strings please! Java sucks as a string manipulation engine because of their immutable String class. The best GC and JIT in the world can't save it. High performance Java parsers generally write their own mutable string class for this very reason. Now the question is - do you want threadsafe strings or non-threadsafe strings? If you want threadsafe mutable strings with a shared string buffer you'll have to deal with mutex overhead even in the single threaded case and performance suffers. Either that or you must provide a sort of abstract string base class and have both a threadsafe string implementation and non-threadsafe string implementation. Lots to think about. __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
Re: [PATCH] Re: Arrays of PMCs
Steve Fink: > EVENTUAL CURRENT > set I0, P0[7] get_keyed I0, P0, 7 > set P0[7], I0 set_keyed P0, 7, I0 > set P0[0], P1[1]not possible > set I0, P0[P1] not possible -- I'm not even sure what this will do > set P1, P0[7] get_keyed P1, P0, 7 (requires the recently committed patch) > set P0[7], P1 set_keyed P0, 7, P1 (requires the recently committed patch) Bizarre. I'm sure I wrote an assembler which had this working. I wonder what happened to it. -- Oh my god! They killed Kennedy! -- edfromo
Re: x86 linux memory leak checker (and JIT ideas)
Methamphetamine/Speed is probably unhealthy for parrots. On 4/24/02 7:32 AM, "Nicholas Clark" <[EMAIL PROTECTED]> wrote: > On Wed, Apr 24, 2002 at 12:26:57PM +0100, Nicholas Clark wrote: >> Jarkko mailed this URL to p5p: >> >> http://developer.kde.org/~sewardj/ > > I'd not twigged, but the author (Julian Seward) is the author of bzip2. > > Another interesting thing he's written is http://www.cacheprof.org/ > [again, not tested this - just found the link] > > It's designed to emulate how algorithms interact with CPU caches, to let > you build better (and therefore faster) algorithms. > > Speed, I seem to remember, is something that parrot is in to. > > Nicholas Clark >
Re: Roadmap for Parrot
At 2:30 AM + 4/20/02, Chip Salzenberg wrote: >According to [EMAIL PROTECTED] (Dan Sugalski): >>At the moment, we don't have to support cascading lexical >>scratchpads--since we know at compile time which variables we're >>accessing and where they come from, we can install trampoline entries >>in the current scope's scratchpad and not have to search outward at >>runtime. > >Once you start down that path, forever will it dominate your closure >implementation. I suggest you do lexical scopes right from the start. That sounds like a good idea. :) What, in this context, is right? I'm kinda winging it. >Surely they're not that much harder than a trampoline Are they? No, but there are speed issues. With a trampoline (or just sticking the original PMC's pointer in) we don't have to do any back-lookups. Plus there's the issue of how injecting lexicals into caller's scopes are supposed to work. >PS: I'm back. }:-) Yay! -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Op changes
I've added set_addr, which gets the address of a label, like so: set_addr I3, FOO and fixed jump and jsr to actually work with absolute addresses. I think callcc might be coming soon. Be afraid, be very afraid... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Op changes
On Wed, Apr 24, 2002 at 12:49:27PM -0400, Dan Sugalski wrote: > I've added set_addr, which gets the address of a label, like so: > >set_addr I3, FOO Awww, you didn't call it lea? Now how am I supposed to feel superior to all the people who would have no clue what lea means? > I think callcc might be coming soon. Be afraid, be very afraid... Oh, I am. Though I'm still curious about what's supposed to be inside one of those subroutine context objects (not the continuation object; I'm really talking about plain ol' "call" here.)
Re: [CONFIGURE] New make.pl coming soon...
On Wed, Apr 24, 2002 at 03:10:55AM -0400, Jeff wrote: > In between attempting to get the new assembler up and running (currently > dealing with XS issues), Robert Spiers and I have come up with a new > make mechanism. XS? Is this a different assembler than Simon Cozen's? I assume so, since I've had his up and running for a while. Is this why his was never checked in? > The syntax may change, and the build mechanism has a ways to go (It's > simply running one step at a time in order, no parallelism or multiple > processes), but the basic idea so far seems sound. Without knowing too much about it, I still have to wonder what is wrong with cons? I thought it was a fully functional all-perl make replacement.
Re: x86 linux memory leak checker (and JIT ideas)
In message <[EMAIL PROTECTED]> Nicholas Clark <[EMAIL PROTECTED]> wrote: > Jarkko mailed this URL to p5p: > > http://developer.kde.org/~sewardj/ > > It describes a free (GPL) memory leak checker for x86 Linux > > 1: This may be of use for parrot hackers Which is why I mentioned it a week or two ago ;-) I also ran it over the test suite and fixed the only bug that it found at that time... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: Op changes
On Wed, 24 Apr 2002, Dan Sugalski wrote:
> I've added set_addr, which gets the address of a label, like so:
>
> set_addr I3, FOO
>
> and fixed jump and jsr to actually work with absolute addresses.
>
This generates a stack of warnings of the form:
core.ops:473: warning: assignment makes integer from pointer without a cast
core.ops:473: warning: assignment makes integer from pointer without a cast
core.ops:2704: warning: assignment makes pointer from integer without a cast
core.ops:2704: warning: assignment makes pointer from integer without a cast
core.ops:2717: warning: assignment makes pointer from integer without a cast
core.ops:2717: warning: assignment makes pointer from integer without a cast
etc. The first two are from set_addr, and can be fixed by casting to
INTVAL, as in the patch below; the others are coming from jump & jsr,
but I'm not sure how to fix them.
Simon
--- core.ops.oldWed Apr 24 15:07:05 2002
+++ core.opsWed Apr 24 15:22:03 2002
@@ -470,7 +470,7 @@
Sets register $1 to the current address plus the offset $2
inline op set_addr(out INT, in INT) {
- $1 = cur_opcode + $2;
+ $1 = (INTVAL) CUR_OPCODE + $2;
goto NEXT();
}
Re: Op changes
On Wed, Apr 24, 2002 at 03:22:57PM -0400, Simon Glover wrote:
>
> --- core.ops.old Wed Apr 24 15:07:05 2002
> +++ core.ops Wed Apr 24 15:22:03 2002
> @@ -470,7 +470,7 @@
> Sets register $1 to the current address plus the offset $2
>
> inline op set_addr(out INT, in INT) {
> - $1 = cur_opcode + $2;
> + $1 = (INTVAL) CUR_OPCODE + $2;
>goto NEXT();
> }
That doesn't look right. If cur_opcode is an opcode_t*, then
precedence says that this is
$1 = ( (INTVAL) CUR_OPCODE ) + $2
which means you're adding bytes instead of opcodes, and the offset
will be too small.
Re: Op changes
On Wed, 24 Apr 2002, Steve Fink wrote:
> On Wed, Apr 24, 2002 at 03:22:57PM -0400, Simon Glover wrote:
> >
> > --- core.ops.oldWed Apr 24 15:07:05 2002
> > +++ core.opsWed Apr 24 15:22:03 2002
> > @@ -470,7 +470,7 @@
> > Sets register $1 to the current address plus the offset $2
> >
> > inline op set_addr(out INT, in INT) {
> > - $1 = cur_opcode + $2;
> > + $1 = (INTVAL) CUR_OPCODE + $2;
> >goto NEXT();
> > }
>
> That doesn't look right. If cur_opcode is an opcode_t*, then
> precedence says that this is
>
> $1 = ( (INTVAL) CUR_OPCODE ) + $2
>
> which means you're adding bytes instead of opcodes, and the offset
> will be too small.
You're quite right - corrected patch below, plus a simple test case.
Simon
--- core.ops.oldWed Apr 24 15:07:05 2002
+++ core.opsWed Apr 24 16:03:31 2002
@@ -470,7 +470,7 @@
Sets register $1 to the current address plus the offset $2
inline op set_addr(out INT, in INT) {
- $1 = cur_opcode + $2;
+ $1 = (INTVAL) (CUR_OPCODE + $2);
goto NEXT();
}
--- t/op/basic.t.oldWed Apr 24 16:06:26 2002
+++ t/op/basic.tWed Apr 24 16:07:50 2002
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 7;
+use Parrot::Test tests => 8;
# It would be very embarrassing if these didn't work...
output_is(<<'CODE', '', "noop, end");
@@ -54,4 +54,16 @@
done
OUTPUT
+output_is(<<'CODE', <<'OUTPUT', "set_addr");
+ set_addr I1, FOO
+ jump I1
+ print "Jump failed\n"
+ end
+
+FOO: print "Jump succeeded\n"
+ end
+CODE
+Jump succeeded
+OUTPUT
+
1; # HONK
PATCHES
Folks, From now on, please every time you want to send a patch send it to [EMAIL PROTECTED] so that we can keep track of it and it doesn't get lost in space. Thanks. Daniel Grunblatt.
Re: Op changes [APPLIED]
At 4:10 PM -0400 4/24/02, Simon Glover wrote: > You're quite right - corrected patch below, plus a simple test case. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Regex and Matched Delimiters
Michael G Schwern wrote in perl.perl6.language : > On Tue, Apr 23, 2002 at 11:11:28PM -0500, Me wrote: >> Third, I was thinking that having perl 6 regexen have /s on >> by default would be easy for perl 5 coders to understand; >> not too hard to get used to; and have no negative effects >> for existing coders beyond getting used to the change. > > I'm jumping in the middle of a conversation here, but consider the > problem of .* matching newlines by default and greediness. > > /(foo.*)$/, /(foo.*)$/m and /(foo.*)$/s This is so old-fashioned. > when matching against something like "foo\nwiffle\nbarfoo\n" One matches the > last line. One matches the first line. And one matches all three lines. And by the way, there's the semantic unaccuracy of $ matching transparently newlines, combined with the obscure variants \z and \Z. This needs (IMHO) some reshaping. -- Rafael Garcia-Suarez I'll better skip() some releases until it is() ok() to use Test::More without() going insane(). Any more than I already am, that is(). -- Tels in the perl-qa mailing list
Re: [CONFIGURE] New make.pl coming soon...
>Without knowing too much about it, I still have to wonder what is >wrong with cons? I thought it was a fully functional all-perl make >replacement. One reason not to use cons is that we will have to port it to parrot/perl6 in order to become self hosting, another, is that it may not meet all of our needs, especially in trying to do everything for all platforms. One of the keys of the system Jeff has implemented is that it's 100% real perl code and real perl objects, not a language parsed with perl. This means you can do nifty things and write perl code to modify things in a natural way. Having said that, if you want to convert the current system to cons, and submit it, it might get us far enough along for now. But, also, having just implemented something very similar to what Jeff has put together for $DAYJOB, I think there is a lot of power in having your own system. -R
Re: [CONFIGURE] New make.pl coming soon...
On Wednesday, April 24, 2002, at 04:04 PM, Robert Spier wrote: > One of the keys of the system Jeff has implemented is that it's 100% > real perl code and real perl objects, not a language parsed with > perl. This means you can do nifty things and write perl code to > modify things in a natural way. This is true for cons as well. - Damien
