Re: Stacks, stacks, stacks (And frames)
Uri Guttman <[EMAIL PROTECTED]> writes: >> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> We'll find out with A6 whether we do coroutines and continuations as > DS> part of the core perl. If not, well, python does the first and ruby > DS> the second, so it's all good in there. > > on the last perl cruise, i had a nice talk with larry about language > level async i/o and continuations and related stuff. i don't know his > final decisions but we worked on ideas that would support those features > with similar API's and he seemed to like it. so i would bet that > continuations and coroutines will be in perl6. but i wouldn't bet > larry's life on it. :) > > so my take is to make the stacks support them. Plus, languages like Ruby and scheme have continuations in them, and we would like to see those languages hosted on Parrot at some point. -- 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: [Patch] other mathematical operations
On Tue, 11 Jun 2002, Dan Sugalski wrote: > At 1:07 PM +0200 6/11/02, =?latin1?Q?Josef_H=F6=F6k?= wrote: > > > >I've added Gcd and factorial to core.ops, as attachement. > >Dan is this something you want? > >I also have "least common multiple" and "binomial" implementation > >waiting. If you want them i can can make a patch > > I like it, but I think I'd prefer it be in a separate ops file. > Math.ops, perhaps. > -- > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk > Ok il build a math.ops file and include least common multiple and others.. /josef
Dynaloading
Okay, I've been putting this off way too long. Here's what we're doing to load in shared libraries: loadlib Sx, Sy Where Sx is the fully qualified name of the library we're loading, and Sy is the name of the routine that we're invoking once we load the library. This should be the *only* routine the library exports. The exported name should be the MD5 checksum of a string that represents the actual routine name we're looking for. This, I think, should be specified somewhere external to the library, in some sort of metadata file, I think. (Not sure, I'm waffling here. But we need this to be unique) Anyway, for right now, loadlib should do what we need. Oh, and we need to uncomment and make work the PMC registry code in global_setup.c, so we can look up PMC classes by name. Can't be making the assembler know about everything forever... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl@gloudon.com: [PATCH] packfile reading]
Could someone apply this ? - Forwarded message from Jason Gloudon <[EMAIL PROTECTED]> - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk Delivered-To: mailing list [EMAIL PROTECTED] Date: Mon, 10 Jun 2002 19:33:56 -0400 From: Jason Gloudon <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [PATCH] packfile reading User-Agent: Mutt/1.3.25i This fixes the problem with reading .pbc files on win32. Someone may want to write the code to do something useful with the results of stat() when mmap() is not being used. Index: assemble.pl === RCS file: /cvs/public/parrot/assemble.pl,v retrieving revision 1.66 diff -u -r1.66 assemble.pl --- assemble.pl 10 Jun 2002 05:40:06 - 1.66 +++ assemble.pl 10 Jun 2002 23:24:45 - @@ -813,6 +813,7 @@ close FILE; } else { + binmode STDOUT; print $bytecode; } Index: embed.c === RCS file: /cvs/public/parrot/embed.c,v retrieving revision 1.26 diff -u -r1.26 embed.c --- embed.c 8 Jun 2002 03:38:45 - 1.26 +++ embed.c 10 Jun 2002 23:24:45 - @@ -110,6 +110,7 @@ INTVAL read_result; program_code = (char *)malloc(program_size + 1024); +program_size = 0; if (NULL == program_code) { fprintf(stderr, "Parrot VM: Could not allocate buffer to read packfile from PIO.\n"); - End forwarded message - -- Jason
Re: [Patch] other mathematical operations
Jeff wrote: >How are we going to get people to write recursive subroutines if we have >a factorial operator? :) > [snip] sub offTopic { Have you seen Arc's factorial? The "short way" is really weird: (rec zero 1 * 1-) But then, the long way is still a bit odd to me, a non-LISPer: (rfn fact (x) (if (zero x) 1 (* x (fact (1- x) } -Rob
Re: [perl@gloudon.com: [PATCH] packfile reading]
On Wed, 12 Jun 2002, Jason Gloudon wrote: > > Could someone apply this ? > > - Forwarded message from Jason Gloudon <[EMAIL PROTECTED]> - > > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Precedence: bulk > Delivered-To: mailing list [EMAIL PROTECTED] > Date: Mon, 10 Jun 2002 19:33:56 -0400 > From: Jason Gloudon <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [PATCH] packfile reading > User-Agent: Mutt/1.3.25i > > > This fixes the problem with reading .pbc files on win32. Someone may want to > write the code to do something useful with the results of stat() when mmap() is > not being used. > Applied, thanks.
Re: Dynaloading
At 04:55 AM 6/12/2002 -0400, Dan Sugalski wrote: > loadlib Sx, Sy > >Where Sx is the fully qualified name of the library we're loading, and Sy >is the name of the routine that we're invoking once we load the library. >This should be the *only* routine the library exports. > >The exported name should be the MD5 checksum of a string that represents >the actual routine name we're looking for. This, I think, should be >specified somewhere external to the library, in some sort of metadata >file, I think. (Not sure, I'm waffling here. But we need this to be unique) What is MD5 checksum buying us over a sufficiently mangled name? We are only worried about uniquness, right? I was hoping we could do extensions without needing a pre-processor to get away from the current XS mess. Why not something plain-text like: P6M_init__ -Melvin
Re: Dynaloading
At 11:23 AM -0400 6/12/02, Melvin Smith wrote: >At 04:55 AM 6/12/2002 -0400, Dan Sugalski wrote: >> loadlib Sx, Sy >> >>Where Sx is the fully qualified name of the library we're loading, >>and Sy is the name of the routine that we're invoking once we load >>the library. This should be the *only* routine the library exports. >> >>The exported name should be the MD5 checksum of a string that >>represents the actual routine name we're looking for. This, I >>think, should be specified somewhere external to the library, in >>some sort of metadata file, I think. (Not sure, I'm waffling here. >>But we need this to be unique) > >What is MD5 checksum buying us over a sufficiently mangled name? >We are only worried about uniquness, right? I was hoping we could do >extensions without needing a pre-processor to get away from the current XS >mess. Why not something plain-text like: It's length, too. We need to keep the name under 32 characters. If we're wedging module/author/version into the name (for extension it's reasonable) it's tough to keep them under that limit. Easier to not bother and just MD5 the thing by default. OTOH, we can set this as a standard and, if we use metadata, read the real name from the metadata file. Which might be something shorter, you never know. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dynaloading
In messageDan Sugalski <[EMAIL PROTECTED]> wrote: > The exported name should be the MD5 checksum of a string that > represents the actual routine name we're looking for. This, I think, > should be specified somewhere external to the library, in some sort > of metadata file, I think. (Not sure, I'm waffling here. But we need > this to be unique) Why does it need to be unique if it's not going to be linked against anything? If you're just finding the name with dlsym() or equivalent then you can just use the same name in all the libraries and it won't clash. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: Dynaloading
At 7:21 PM +0100 6/12/02, Tom Hughes wrote: >In message> Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> The exported name should be the MD5 checksum of a string that >> represents the actual routine name we're looking for. This, I think, >> should be specified somewhere external to the library, in some sort >> of metadata file, I think. (Not sure, I'm waffling here. But we need >> this to be unique) > >Why does it need to be unique if it's not going to be linked >against anything? If you're just finding the name with dlsym() or >equivalent then you can just use the same name in all the libraries >and it won't clash. I'm pretty sure this'll run us into problems in some places. I'm trying to dig up some details at the moment. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Exceptions sample
Can you let me know if the way I think about exceptions is ok? Thanks, Daniel Grunblatt. set I0,0 set I8,10 try # User exception catch !WRONG_NUMBERS, PRINT_WRONG # Trying to catch an exception that was already catched. catch !NOT_SUCH_FILE, NEVER_MADE_IT print "step 1" bsr DIV end_try # For machine generated code this should not be a problem and makes my life easier. # Catching an exception that (may be) was thrown but not catched. catch !NOT_OK, NK NEVER_MADE_IT: print "not here" end DIV: try # Predefined exception catch !DIVISION_BY_ZERO, RETHROW # The default handler dies, so I just wrap it. catch !NOT_SUCH_FILE, DISCARD print "step #2" div I1,I8,I0 open P1,"doesn't exists","<" end_try ret DISCARD: print "step #4" ret RETHROW: print "step #3" throw !NOT_OK throw !WRONG_NUMBERS ret NK: print "step #5" end
Re: [netlabs #702] BASIC causes sevg's in parrot
On Tue, Jun 11, 2002 at 12:04:19PM -, Clinton A. Pierce wrote: > # New Ticket Created by "Clinton A. Pierce" > # Please include the string: [netlabs #702] > # in the subject line of all future correspondence about this issue. > # http://bugs6.perl.org/rt2/Ticket/Display.html?id=702 > > > > To reproduce, sync with CVS, build, run "basic.pl" -- that's all. This > version of BASIC is unchanged since it last worked The problem was with my last stack patch. During DOD the control stack chunks have to be walked now, since their contents are allocated using buffers. -- Jason Index: resources.c === RCS file: /cvs/public/parrot/resources.c,v retrieving revision 1.63 diff -u -r1.63 resources.c --- resources.c 12 Jun 2002 22:58:29 - 1.63 +++ resources.c 13 Jun 2002 00:44:42 - @@ -428,7 +428,7 @@ } } -/* Finally the general stack */ +/* Now the general stack */ start_stack = cur_stack = interpreter->user_stack; chunks_traced = 0; /* The general stack's circular, so we need to be careful */ @@ -442,6 +442,19 @@ buffer_lives((Buffer *)entry[i].entry.string_val); } } +} + +chunks_traced++; +cur_stack = cur_stack->prev; +} + + /* Finally the control stack frames must be marked live */ +start_stack = cur_stack = interpreter->control_stack; +chunks_traced = 0; +/* This stack, like the general stack is circular */ +while (cur_stack && ((start_stack != cur_stack) || (chunks_traced == 0))) { +if(cur_stack->buffer){ +buffer_lives(cur_stack->buffer); } chunks_traced++;
Re: [netlabs #702] BASIC causes sevg's in parrot
At 09:03 PM 6/12/2002 -0400, Jason Gloudon wrote: >On Tue, Jun 11, 2002 at 12:04:19PM -, Clinton A. Pierce wrote: > > # New Ticket Created by "Clinton A. Pierce" > > # Please include the string: [netlabs #702] > > # in the subject line of all future correspondence about this issue. > > # http://bugs6.perl.org/rt2/Ticket/Display.html?id=702 > > > > > > > To reproduce, sync with CVS, build, run "basic.pl" -- that's all. This > > version of BASIC is unchanged since it last worked > >The problem was with my last stack patch. During DOD the control stack chunks >have to be walked now, since their contents are allocated using buffers. Applied. -Melvin