Re: Stacks, stacks, stacks (And frames)

2002-06-12 Thread Piers Cawley

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

2002-06-12 Thread Josef Höök



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

2002-06-12 Thread Dan Sugalski

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]

2002-06-12 Thread Jason Gloudon


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

2002-06-12 Thread Robert Eaglestone

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]

2002-06-12 Thread Daniel Grunblatt


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

2002-06-12 Thread Melvin Smith

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

2002-06-12 Thread Dan Sugalski

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

2002-06-12 Thread Tom Hughes

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.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/




Re: Dynaloading

2002-06-12 Thread Dan Sugalski

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

2002-06-12 Thread Daniel Grunblatt

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

2002-06-12 Thread Jason Gloudon

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

2002-06-12 Thread Melvin Smith

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