cvs access?

Hi all, I have created a perl.org account in order to access the parakeet directory in cvs. My perl.org user name is "michel" (how'd I score that one?). Is this the right list to ask someone to give me the property credentials? TIA, -Michel

Re: Fwd: Re: Parrot BASIC

On Tue, 16 Nov 2004 21:59:39 +0100, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote: > (I've been trying a lot to implement a Lua compiler (version 5), but I'm > seriously stuck on generating code for assignments (it's not as simple > as it seems, but then again, I may be thinking in the wrong direction;

Re: Harness runs the sub, D::C says I haven't

Paul Johnson wrote: HARNESS_PERL_SWITCHES=-MDevel::Cover=-select,. make test The downside is that that will also give you coverage for every module you use, which is distracting and slow. Well this may be worthy of note, it still doesnt report coverage of a sub I know is being exercised. Now I tri

[perl #32466] [PATCH] Parrot m4 0.0.10 and "eval" changes

# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #32466] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32466 > Hi, this patch brings Parrot m4 to terms with recent "eval" changes. The com

Re: Continuations, basic blocks, loops and register allocation

Dan~ On Tue, 16 Nov 2004 16:24:06 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > We could, but it would be wrong. Hell, it's arguably wrong for return > continuations to do so, and it wouldn't be unreasonable to argue that > I and N register contents are guaranteed crud and required refetching.

Re: Harness runs the sub, D::C says I haven't

On Wed, Nov 17, 2004 at 08:33:54AM +1100, Leif Eriksen wrote: > Next I tried to see why D::C 0.50 didn't work. To do this I started with > a clean slate, ala 'echo y | cvs release -d monash.its && cvs co > monash.its' (blow away the source dir structure and recreate from CVS). > I then did the 'pe

parakeet broken?

i was starting to play with parakeet, but unfortunately it keeps dying on me. this is from a cvs checkout from today: 0> 4 4 + Null PMC access in get_pmc_keyed_int() and this: 0> func hello "hi!" println end 0> hello Null PMC access in push_pmc() any clues? thanks, -jeff

Re: Continuations, basic blocks, loops and register allocation

At 4:10 PM -0500 11/16/04, Matt Fowles wrote: Dan~ On Tue, 16 Nov 2004 15:54:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: At 3:39 PM -0500 11/16/04, Matt Fowles wrote: >Dan~ > > >On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: >> At 3:12 PM -0500 11/16/04, Ma

Re: Continuations, basic blocks, loops and register allocation

Dan~ On Tue, 16 Nov 2004 15:54:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 3:39 PM -0500 11/16/04, Matt Fowles wrote: > > > >Dan~ > > > > > >On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> At 3:12 PM -0500 11/16/04, Matt Fowles wrote: > >> > >> > >>

Re: Another issue with pdd03

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Jeff Clites <[EMAIL PROTECTED]> wrote: >> But that loops back to a previous proposal of mine: If they're not >> being preserved, and in fact need to be "synced" between caller and >> callee, then having these registers physically located in the >> inter

Re: Fwd: Re: Parrot BASIC

Joshua Gatcomb wrote: All, Please read Clinton's reply - especially the part about being blocked from the list for about a year. Cheers, Joshua Gatcomb a.k.a. Limbic~Region --- "Clinton A. Pierce" <[EMAIL PROTECTED]> wrote: Date: Tue, 16 Nov 2004 11:34:05 -0500 To: Joshua Gatcomb <[EMAIL PROTECT

Re: Continuations, basic blocks, loops and register allocation

At 3:39 PM -0500 11/16/04, Matt Fowles wrote: Dan~ On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: At 3:12 PM -0500 11/16/04, Matt Fowles wrote: >Dan~ > >On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: >> At 10:32 AM -0800 11/16/04, Jeff

Re: Continuations, basic blocks, loops and register allocation

Dan~ On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 3:12 PM -0500 11/16/04, Matt Fowles wrote: > > > >Dan~ > > > >On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> At 10:32 AM -0800 11/16/04, Jeff Clites wrote: > >> >The continu

Re: cvs commit: parrot/docs/pdds pdd03_calling_conventions.pod

At 9:16 PM +0100 11/16/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: +I if there are overflow parameters. Otherwise garbage +=item I0 + +=item I1-I4 I3 isn't always visible? Effectively it is, yes. > ... Fetching the return continuation +may be expensive, and

Re: Continuations, basic blocks, loops and register allocation

At 3:12 PM -0500 11/16/04, Matt Fowles wrote: Dan~ On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: At 10:32 AM -0800 11/16/04, Jeff Clites wrote: >The continuation preserves the frame (the mapping from logical >variables to their values), but not the values of those v

Re: cvs commit: parrot/docs/pdds pdd03_calling_conventions.pod

Dan Sugalski <[EMAIL PROTECTED]> wrote: > +I if there are overflow parameters. Otherwise garbage > +=item I0 > + > +=item I1-I4 I3 isn't always visible? > ... Fetching the return continuation > +may be expensive, and should only be done if truly necessary. Err, e.g. for returning fr

Re: Another issue with pdd03

Jeff Clites <[EMAIL PROTECTED]> wrote: > But that loops back to a previous proposal of mine: If they're not > being preserved, and in fact need to be "synced" between caller and > callee, then having these registers physically located in the > interpreter structure, rather than in the bp-reference

Re: Continuations, basic blocks, loops and register allocation

Dan~ On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 10:32 AM -0800 11/16/04, Jeff Clites wrote: > >The continuation preserves the frame (the mapping from logical > >variables to their values), but not the values of those variables at > >the time the continuation w

Re: Another issue with pdd03

Jeff Clites <[EMAIL PROTECTED]> wrote: [ PPC ABI ] > Not that parrot has to necessarily work this way, but it at least has > precedent, so it's not totally strange behavior. Sure it's neither strnge nor unsimilar. Except that the PPC ABI defines more preserved registers (r13..r31) assuming press

Re: Continuations, basic blocks, loops and register allocation

Jeff Clites <[EMAIL PROTECTED]> wrote: > sub B > { > a = 1 > foo() > print a > b = 2 > return b > } > If something called by foo() captures a continuation, and something > invokes it after B() returns, then there's a hidden branch, in effect, > from the return to the

Fwd: Re: Parrot BASIC

All, Please read Clinton's reply - especially the part about being blocked from the list for about a year. Cheers, Joshua Gatcomb a.k.a. Limbic~Region --- "Clinton A. Pierce" <[EMAIL PROTECTED]> wrote: > Date: Tue, 16 Nov 2004 11:34:05 -0500 > To: Joshua Gatcomb <[EMAIL PROTECTED]> > From: "Cli

Re: Continuations, basic blocks, loops and register allocation

At 10:32 AM -0800 11/16/04, Jeff Clites wrote: The continuation preserves the frame (the mapping from logical variables to their values), but not the values of those variables at the time the continuation was created. This is one of the fundamental properties of continuations, but it does throw

Re: Continuations, basic blocks, loops and register allocation

On Nov 16, 2004, at 10:03 AM, Matt Fowles wrote: Since both you and Leo are arguing against me here, it seems like that I am wrong, but I would like to figure out exactly why I am wrong so that I can correct my train of thought in the future. Here's a real example you can play with, if you have Rub

Re: [PROPOSAL] for a new calling scheme

Dan~ On Tue, 16 Nov 2004 13:14:00 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 1:11 PM -0500 11/16/04, Matt Fowles wrote: > > > >Dan~ > > > >On Tue, 16 Nov 2004 13:00:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> At 12:56 PM -0500 11/16/04, Matt Fowles wrote: > >> >At line 72,

Re: [PROPOSAL] for a new calling scheme

At 1:11 PM -0500 11/16/04, Matt Fowles wrote: Dan~ On Tue, 16 Nov 2004 13:00:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: At 12:56 PM -0500 11/16/04, Matt Fowles wrote: >At line 72, "Note that fact if a return continuation object is created >explicitly, rather than by an invocation op," wha

Re: [PROPOSAL] for a new calling scheme

Dan~ On Tue, 16 Nov 2004 13:00:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 12:56 PM -0500 11/16/04, Matt Fowles wrote: > >At line 72, "Note that fact if a return continuation object is created > >explicitly, rather than by an invocation op," what is the remainder of > >this sentence? >

Re: Continuations, basic blocks, loops and register allocation

Leo~ On Tue, 16 Nov 2004 18:32:07 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Matt Fowles wrote: > > > > I disagree with that analysis. Let us consider the actual effect of > > such an implementation. > > > > First iteration > > > > i = 0; > > foo(); #at this point a continuation create

Re: Continuations, basic blocks, loops and register allocation

On Nov 15, 2004, at 10:29 AM, Leopold Toetsch wrote: Jeff Clites <[EMAIL PROTECTED]> wrote: Picture this call stack: main --> A --> B --> C --> D --> E The call from D to E uses the "RESUMEABLE" label, and E stores the resulting continuation in a global, and everything up to main returns. Then,

Re: Another issue with pdd03

On Nov 14, 2004, at 9:32 AM, Leopold Toetsch wrote: Defining now that P5 has to be preserved in main, because it's a possible return result of foo() and therefore may be clobbered by foo() is meaning, that we have effectively just 16 registers per kind available for allocation around a function

Re: Another issue with pdd03

On Nov 15, 2004, at 12:38 AM, Leopold Toetsch wrote: Bill Coffman <[EMAIL PROTECTED]> wrote: [ pdd03 ] The way I read it, paragraph one implies that when you print P5 after calling foo(), you are expecting to get the return value. You didn't save and restore register P5, so you wanted foo() to do

Re: Continuations, basic blocks, loops and register allocation

Dan~ On Tue, 16 Nov 2004 12:29:19 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 11:52 AM -0500 11/16/04, Matt Fowles wrote: > > > >Leo~ > > > >On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> > >wrote: > >> > >> > >> Matt Fowles <[EMAIL PROTECTED]> wrote: > >> >

Re: [PROPOSAL] for a new calling scheme

At 12:56 PM -0500 11/16/04, Matt Fowles wrote: Dan~ On Tue, 16 Nov 2004 12:22:23 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: An updated PDD 03 is in the repository. It's clear on what the caller populates, what the callee sees, and what happens to all the different registers. At line 72, "No

Re: [PROPOSAL] for a new calling scheme

Dan~ On Tue, 16 Nov 2004 12:22:23 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > An updated PDD 03 is in the repository. It's > clear on what the caller populates, what the > callee sees, and what happens to all the > different registers. At line 72, "Note that fact if a return continuation ob

Re: Continuations, basic blocks, loops and register allocation

Matt Fowles wrote: I disagree with that analysis. Let us consider the actual effect of such an implementation. First iteration i = 0; foo(); #at this point a continuation created capturing i=0, promoted by Jens and stuff happens #eventually it is invoked, restoring i=0 i++; #i = 1 foo(); #at this

Re: [PROPOSAL] for a new calling scheme

At 5:11 PM +0100 11/16/04, Leopold Toetsch wrote: Stéphane Payrard <[EMAIL PROTECTED]> wrote: Probably, the timing of the proposition is wrong. I'd appreciate a discussion about the mentioned issues An updated PDD 03 is in the repository. It's clear on what the caller populates, what the callee

Re: Continuations, basic blocks, loops and register allocation

At 11:52 AM -0500 11/16/04, Matt Fowles wrote: Leo~ On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: Matt Fowles <[EMAIL PROTECTED]> wrote: > Leo~ > On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> i = 0 >> lp: >> foo(

Re: AIX PPC JIT warning

Adam Thomason <[EMAIL PROTECTED]> wrote: > I just cvs up'ed and upgraded to perl 5.8.5, and now parrot's make > testj matches make test (some unimplemented PMC method errors in > both... is this expected?). I don't know, which errors you got ;) Anyway, as of now JIT/PPC on OS X is passing all tes

Re: Continuations, basic blocks, loops and register allocation

Leo~ On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > > Matt Fowles <[EMAIL PROTECTED]> wrote: > > Leo~ > > > On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> > > wrote: > > >> i = 0 > >> lp: > >> foo() > >> inc i > >>

Re: IEEE 754 double floats

Another way is to count the bits, as in the following: .sub _main N1 = 1 N2 = 0.5 I0 = 0 REPEAT: I0 = I0 + 1 N2 = N2 / 2 N3 = N1 + N2 ne N1, N3, REPEAT print I0 print " bits precision\n" end .end On Wed, 17

Re: [PROPOSAL] for a new calling scheme

Stéphane Payrard <[EMAIL PROTECTED]> wrote: > Probably, the timing of the proposition is wrong. I'd appreciate a discussion about the mentioned issues, which are serious in my opinion. These issues have to be addressed, sooner or later. I didn't propose to make changes now, just the opposite. l

Re: [PROPOSAL] for a new calling scheme

At 4:49 PM +0100 11/16/04, Leopold Toetsch wrote: Dan Sugalski wrote: What part of "This stuff isn't going to change" hasn't been clear? Your sentence below answering Matt's question about dismissing my arguments lightly? There is quite a difference between "not change. Period" and "not change no

Re: [PROPOSAL] for a new calling scheme

Dan Sugalski wrote: What part of "This stuff isn't going to change" hasn't been clear? Your sentence below answering Matt's question about dismissing my arguments lightly? There is quite a difference between "not change. Period" and "not change now". At 2:15 PM -0500 11/8/04, Matt Fowles wrote:

Re: Continuations, basic blocks, loops and register allocation

Matt Fowles <[EMAIL PROTECTED]> wrote: > Leo~ > On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> i = 0 >> lp: >> foo() >> inc i >> if i < 10 goto lp > There is one thing I am not sure about here. The loop will work > correctly for each seperate

Re: [PROPOSAL] for a new calling scheme

On Tue, Nov 16, 2004 at 10:48:18AM -0500, Dan Sugalski wrote: > At 4:48 PM +0100 11/16/04, Stéphane Payrard wrote: > >Putting your architect hat, Dan, can you spell a policy in this matter? > > Sure. > > The calling conventions are fixed. They are not going to change > again. You are not answeri

Re: [PROPOSAL] for a new calling scheme

At 4:48 PM +0100 11/16/04, Stéphane Payrard wrote: Putting your architect hat, Dan, can you spell a policy in this matter? Sure. The calling conventions are fixed. They are not going to change again. -- Dan --it's like this

Re: [PROPOSAL] for a new calling scheme

On Tue, Nov 16, 2004 at 08:52:10AM -0500, Dan Sugalski wrote: > At 11:43 AM +0100 11/16/04, Leopold Toetsch wrote: > >Below inline/attached is a proposal for new calling conventions - > >for the archive as Dan doesn't like changes now, but I haven't to > >backup it, when its out ;) > > Alright,

Re: Continuations, basic blocks, loops and register allocation

Leo~ On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Matt Fowles <[EMAIL PROTECTED]> wrote: > > [ continuations should restore registers ] > > > I am sorry, but I don't understand what you are trying to say here. > > Would you mind rewording it for me? > > Imagi

Re: [PROPOSAL] for a new calling scheme

At 11:43 AM +0100 11/16/04, Leopold Toetsch wrote: Below inline/attached is a proposal for new calling conventions - for the archive as Dan doesn't like changes now, but I haven't to backup it, when its out ;) Alright, that does it. I am *tired* of this. I'm tired of the sniping, I'm tired of th

Re: IEEE 754 double floats

Adam Warner <[EMAIL PROTECTED]> wrote: > In other words sprintf is printing trailing garbage: Well, the underlaying architecture is defining the precision of floats. And due to the binary nature of the representation of floats they are mostly just and inprecise approximation of a given float valu

Re: IEEE 754 double floats

Hi Leopold Toetsch, >> PI is (very) approximately: > 3.1415906535896946927266526472521945834159851074218750 > ^ > 3.141592653589793238462643383279502884197169399375105820974944 > > You might probably want to run more iterations ;) And you'll never get > 60 digits out of l

Re: SDL: Locate shared libraries

Adam Warner wrote: Hello again, x86 Debian sid with the SDL libraries installed: In runtime/parrot/library/SDL.imc I replaced the respective loadlibs with: loadlib libsdl, 'libSDL-1.2.so.0' That's not a general solution, as it makes explicit system-dependent assumptions on filenames. I've add

Re: Threads, events, Win32, etc.

Gabe Schaffer <[EMAIL PROTECTED]> wrote: > On Mon, 15 Nov 2004 12:57:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> Gabe Schaffer <[EMAIL PROTECTED]> wrote: >> > * COND_WAIT takes a mutex because that's how pthreads works, but Win32 >> > condition variables (called "events") are kernel obj

Re: IEEE 754 double floats

Adam Warner <[EMAIL PROTECTED]> wrote: > On a windows binary I downloaded the precision is indeed double (~16 > decimal places). With my current Linux binary it's extreme (here's 60 > decimal places): > PI is (very) approximately: 3.1415906535896946927266526472521945834159851074218750

[PROPOSAL] for a new calling scheme

Below inline/attached is a proposal for new calling conventions - for the archive as Dan doesn't like changes now, but I haven't to backup it, when its out ;) A proposal for new calling conventions - for the archive as Dan doesn't like changes now, but I haven't to backup it, when its out ;) Cen

SDL: Locate shared libraries

Hello again, x86 Debian sid with the SDL libraries installed: libsdl-image1.2 1.2.3-5 image loading library for Simple DirectMedia Layer 1.2 libsdl-ttf2.0-0 2.0.6-5 ttf library for Simple DirectMedia Layer with FreeType libsdl1.2debian 1.2.7-10 Simple DirectMedia Layer libsdl1.2de

Re: Harness runs the sub, D::C says I haven't

Paul Johnson wrote: On Sat, Nov 13, 2004 at 12:33:01PM +1100, Leif Eriksen wrote: First, thanx so very much for responding so quickly... That was just to make up for the short delay here, and the much longer delay to your last mail to me ;-) Hey, we had a weekend in between, and its not

Re: IEEE 754 double floats

> This may be the long double version that I compiled :-) Note: I've rebuilt parrot-latest.tar.gz (I believe it was 2004-11-16_00) at default settings on Debian unstable 2.6.8.1 i686 GNU/Linux. I'm still printing floats that appear to be 128-bit precision! Regards, Adam

Re: Devel::Cover on Win32: Observations

Paul Johnson wrote: Normally they would not be covered by default, being core modules. Is it possible that your perl is in a different location from that with which the ppm was created? This was probably the case. I may even have downloaded the Devel::Cover which Crazy built against Perl 5.6 rat

RT Ticket Summary

Robert has provided me access to the RT command line tool, which I scripted around to generate this small report. I'd appreciate feedback on whether or not something like this would be useful (and suggestions for other things to report on are welcome.) If we can settle on a desired set of criteria

Re: Threads, events, Win32, etc.

On Mon, 15 Nov 2004 12:57:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Gabe Schaffer <[EMAIL PROTECTED]> wrote: > > * COND_WAIT takes a mutex because that's how pthreads works, but Win32 > > condition variables (called "events") are kernel objects that do not > > require any other object

Re: [perl #32450] [PATCH] core dump of japh16

Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > since a couple of days the example japh16 is dumping core on my Linux > machine. > It looks like there was a free on a NULL, when cleaning up packfile > segments. The attached patch checks wether there is a fixup table in the > seqment. > I'm not

Re: [perl #32421] Bug: segfault in imcc parsing bad if statement

Gopal V <[EMAIL PROTECTED]> wrote: >> Segfault in the lexer. Bad. >> >> 349 sprintf(label, "%s%d", yytext, >> frames->label); >> (gdb) p frames >> $1 = (struct macro_frame_t *) 0x0 > I didn't know how or why or what a frame is in this > context which is why this isn't a patch :)

Re: [perl #32434] [PATCH] Data/Dumper tidbits

Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > this patch adds support for the String PMC to Data/Dumper/Default.imc. It is > treated just like the PerlString PMC. Thanks, applied. leo

Re: Perl 6 Summary for 2004-11-08 through 2004-11-15

Matt Fowles wrote: string pinning Bernhard Schmalhofer wanted to pass the same C-string into to different external functions so that the first could do things to it that the second required. However, the solution that he found kept eating his string after the first invocation. Da

Re: IEEE 754 double floats

Hi Brent 'Dax' Royal-Gordon, >> option. Yet the Leibniz summation for PI >> >> still appears to be performing its calculations using single floats and >> continues to print 3.141591. > > Parrot usually uses double as its floating-point type. The problem is

Re: Continuations, basic blocks, loops and register allocation

Matt Fowles <[EMAIL PROTECTED]> wrote: [ continuations should restore registers ] > I am sorry, but I don't understand what you are trying to say here. > Would you mind rewording it for me? Imagine a simple loop: i = 0 lp: foo() inc i if i < 10 goto lp Looking at the loop cou