Parrot 0.0.9 is spreading its wings

2002-12-19 Thread Steve Fink
I grabbed a snapshot of parrot tonight -- er..., Wednesday night PST -- and ran it through the basic test suite (make fulltest). I have uploaded it to my CPAN account and plan to announce it tomorrow (Thursday) unless someone comes up with any showstoppers. Note that there *are* still tinderbox fa

Parrot 0.0.9 status

2002-11-18 Thread Steve Fink
The basic status is that lots of people, many of them coincidentally named Leopold Toetsch, have been fixing zillions of things and implementing a number of new features. Nearly everything needed for 0.0.9 has happened, and a lot else besides. I personally have been busy with my day job, shipping

Re: Parrot 0.0.9

2002-11-04 Thread Juergen Boemmels
Dan Sugalski <[EMAIL PROTECTED]> writes: [...] > No, it doesn't. It needs to preallocate a few entries in the TOC at > the start of the chunk, but that's it. Not that much waste, even if > some of the metadata's in the TOC. > > > The point is to have a file format that does what we need it > to

RE: Parrot 0.0.9

2002-10-29 Thread Brent Dax
brian wheeler: # Is this really necessary? Seems like a chicken-and-egg # thing: to know which chuck the directory is in, you need to # read the directory. # However, since you've defined that the first chunk (0) is # always the directory, there's really no need to have it in # the directory

RE: Parrot 0.0.9

2002-10-29 Thread brian wheeler
On Tue, 2002-10-29 at 11:48, Brent Dax wrote: > [EMAIL PROTECTED]: > # > Well, on thinking a bit about this, there's no reason that > # we have to > # > worry--it's perfectly OK for us to declare, unconditionally, that > # > segment 0 is always bytecode, 1 line number info, and so on, with > #

Re: Parrot 0.0.9

2002-10-29 Thread Dan Sugalski
At 11:46 AM +0100 10/29/02, Juergen Boemmels wrote: Dan Sugalski <[EMAIL PROTECTED]> writes: Well, on thinking a bit about this, there's no reason that we have to worry--it's perfectly OK for us to declare, unconditionally, that segment 0 is always bytecode, 1 line number info, and so on, wit

RE: Parrot 0.0.9

2002-10-29 Thread Brent Dax
[EMAIL PROTECTED]: # > Well, on thinking a bit about this, there's no reason that # we have to # > worry--it's perfectly OK for us to declare, unconditionally, that # > segment 0 is always bytecode, 1 line number info, and so on, with # > everything after position X (for some value of X) left u

Re: Parrot 0.0.9

2002-10-29 Thread Juergen Boemmels
Dan Sugalski <[EMAIL PROTECTED]> writes: > Well, on thinking a bit about this, there's no reason that we have to > worry--it's perfectly OK for us to declare, unconditionally, that > segment 0 is always bytecode, 1 line number info, and so on, with > everything after position X (for some value of

RE: Parrot 0.0.9

2002-10-28 Thread Dan Sugalski
At 10:44 PM -0700 10/25/02, Brent Dax wrote: I was thinking in terms of what TYPE: stores; it seems you were thinking about how you identify a particular segment. Yeah, you can probably get away with just numbering the segments, although that might slow things down a bit when you're looking for a

Re: Parrot 0.0.9

2002-10-28 Thread Juergen Boemmels
"Brent Dax" <[EMAIL PROTECTED]> writes: > Dan Sugalski: > # Huh? No, you misunderstand. Each chunk of the bytecode has a separate > # TOC for stuff like this. The full identifier would be > # file/chunk/entry, which should be reasonably guaranteed to be unique. > # When the compiler's emitting

Re: Parrot 0.0.9

2002-10-26 Thread Gopal V
If memory serves me right, Dan Sugalski wrote: > Huh? No, you misunderstand. Each chunk of the bytecode has a separate > TOC for stuff like this. The full identifier would be > file/chunk/entry, which should be reasonably guaranteed to be unique. > When the compiler's emitting code to reference

RE: Parrot 0.0.9

2002-10-25 Thread Brent Dax
Dan Sugalski: # Huh? No, you misunderstand. Each chunk of the bytecode has a separate # TOC for stuff like this. The full identifier would be # file/chunk/entry, which should be reasonably guaranteed to be unique. # When the compiler's emitting code to reference a piece of binary data # (which

Re: Parrot 0.0.9

2002-10-25 Thread Dan Sugalski
At 9:13 AM +1000 10/26/02, Rhys Weatherley wrote: Dan Sugalski wrote: ># Instead, lets just give an entry number. We can have arbitrary data ># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having ># names attached. > >What happens if two tools (say, a custom debugger and the

Re: Parrot 0.0.9

2002-10-25 Thread Rhys Weatherley
Dan Sugalski wrote: > ># Instead, lets just give an entry number. We can have arbitrary data > ># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having > ># names attached. > > > >What happens if two tools (say, a custom debugger and the Perl compiler) > >both use the same segment num

Re: Parrot 0.0.9

2002-10-25 Thread Dan Sugalski
At 12:23 PM +0200 10/25/02, Juergen Boemmels wrote: Leopold Toetsch <[EMAIL PROTECTED]> writes: [imcc...] >>>* Bytecode format > ... We could use existing ELF tools to, at the very least, > provide test result verification. This is an argument. If we get e.g. bsr fixup at load time done

RE: Parrot 0.0.9

2002-10-25 Thread Dan Sugalski
At 12:30 PM -0700 10/25/02, Brent Dax wrote: Dan Sugalski: # I'm thinking something else, actually. Names made perfect sense # except for encoding info and duplication. We can put limits on the # name encoding if we want, but... really, who cares? It's only useful # for introspection purposes and

RE: Parrot 0.0.9

2002-10-25 Thread Brent Dax
Dan Sugalski: # I'm thinking something else, actually. Names made perfect sense # except for encoding info and duplication. We can put limits on the # name encoding if we want, but... really, who cares? It's only useful # for introspection purposes and while that's certainly important, I'm # no

Re: Parrot 0.0.9

2002-10-25 Thread Dan Sugalski
At 5:28 PM +0200 10/24/02, Juergen Boemmels wrote: Dan Sugalski <[EMAIL PROTECTED]> writes: >The ability to embed arbitrary data in a pbc file under a >named section. This data needs to be readable by the program >when it runs, but is otherwise ignored by the rest of Parrot. Right, good ca

Re: Parrot 0.0.9

2002-10-25 Thread Juergen Boemmels
Leopold Toetsch <[EMAIL PROTECTED]> writes: [imcc...] > >>>* Bytecode format > > > > ... We could use existing ELF tools to, at the very least, > > provide test result verification. > > > This is an argument. If we get e.g. bsr fixup at load time done by the > elf loader, it would be nice. >

Re: Parrot 0.0.9

2002-10-25 Thread Leopold Toetsch
Steve Fink wrote: On Oct-24, Leopold Toetsch wrote: ... is there anything perl-specific about PerlInt? PerlNum? This depends. The PerlScalars change there types on demand. add PerlInt, PerlInt, PerlNum changes the type of the LHS to a PerlNum. Other languages might prefer to round the

Re: [CVS ci] datatypes (was: Parrot 0.0.9)

2002-10-25 Thread Leopold Toetsch
Steve Fink wrote: On Oct-24, Leopold Toetsch wrote: Thanks! It's a little scary how fast you are. This depends on the RL work I've waiting to be done. The more is in the queue (especially putting invoices together for the revenue office), the more I'll code parrot stuff ;-) leo

Re: Parrot 0.0.9

2002-10-25 Thread Leopold Toetsch
Steve Fink wrote: On Oct-23, Leopold Toetsch wrote: we could look at usage patterns and finally decide, what to do. (Who could extend the assembler?) Sounds good to me. But it does suggest a question -- are there any compelling reasons to preserve the separate assembler? Macros, currentl

Re: Parrot 0.0.9

2002-10-25 Thread Steve Fink
On Oct-24, Leopold Toetsch wrote: > Steve Fink wrote: > > > >... If not, then just > >renaming it to Undef seems best. > > I had a closer look at it. Just renaming doesn't: PerlUndef is derived > from PerlInt, which provides major funtionality for it. > > If this syllable "Perl" is really a p

Re: [CVS ci] datatypes (was: Parrot 0.0.9)

2002-10-25 Thread Steve Fink
On Oct-24, Leopold Toetsch wrote: > Steve Fink wrote: > > > - the various unions should probably be coalesced into one > > I did check in my datatypes patch. > - all? native and other data types are summarized in datatypes.h > - hash and list use the same enums now > - datatype.c has currently 2

Re: Parrot 0.0.9

2002-10-24 Thread Steve Fink
On Oct-23, Leopold Toetsch wrote: > Steve Fink wrote: > > >I suppose I ought to try to wrap up a release one of these days. > > > > - Artificial goal: I want the list of pending patches to be smaller > >than one screenfull before I release. Fortunately, I have a large > >screen. > > I

Re: Parrot 0.0.9

2002-10-24 Thread Juergen Boemmels
Dan Sugalski <[EMAIL PROTECTED]> writes: > >The ability to embed arbitrary data in a pbc file under a > >named section. This data needs to be readable by the program > >when it runs, but is otherwise ignored by the rest of Parrot. > > Right, good call. This'll make perl's named embedded filehand

Re: Parrot 0.0.9

2002-10-24 Thread Leopold Toetsch
Steve Fink wrote: ... If not, then just renaming it to Undef seems best. I had a closer look at it. Just renaming doesn't: PerlUndef is derived from PerlInt, which provides major funtionality for it. If this syllable "Perl" is really a problem, I will reorganize them again i a more hierar

Re: Parrot 0.0.9

2002-10-24 Thread Andy Dougherty
On Thu, 24 Oct 2002, Leopold Toetsch wrote: > Andy Dougherty wrote: > > > Types: > > iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8, > > ptrsize=4, ptr_alignment=4 byteorder=87654321, > The INTVAL2PTR and PTR2INTVAL macros should take care of such a > con

Re: Parrot 0.0.9

2002-10-24 Thread Leopold Toetsch
Steve Fink wrote: On Oct-23, Dan Sugalski wrote: It'd probably be a good idea for us to have a generic undef.pmc for undefined usage. Yes, that's what I was saying. Sorry the comment was vague -- all I meant was that general Parrot PMCs should not be creating Perl-specific PMCs. I agree co

[CVS ci] datatypes (was: Parrot 0.0.9)

2002-10-24 Thread Leopold Toetsch
Steve Fink wrote: - the various unions should probably be coalesced into one I did check in my datatypes patch. - all? native and other data types are summarized in datatypes.h - hash and list use the same enums now - datatype.c has currently 2 functions to retrieve types per name/enum (con

Re: Parrot 0.0.9

2002-10-24 Thread Leopold Toetsch
Steve Fink wrote: Prerequisites for 0.0.9 release --- * Reclaim the tinderbox! On one machine I suddenly have additionally: Failed Test Status Wstat Total Fail Failed List of failed ---

Re: Parrot 0.0.9

2002-10-24 Thread Leopold Toetsch
Andy Dougherty wrote: Types: iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8, ptrsize=4, ptr_alignment=4 byteorder=87654321, The INTVAL2PTR and PTR2INTVAL macros should take care of such a configuration. Though I'm not to sure, if we can get rid of all th

Re: Parrot 0.0.9

2002-10-23 Thread Steve Fink
On Oct-23, Dan Sugalski wrote: > At 7:41 PM +0200 10/23/02, Leopold Toetsch wrote: > >>Possible (feature/architectural) goals for 0.0.9 > >> > >>* PMC cleanup > >> - Leo did a huge amount of work on this, but there are a few things > >> left: > >>

RE: Parrot 0.0.9

2002-10-23 Thread Brent Dax
Steve Fink: # - requires sprintf* to work on PPC. (Brent -- what's the status?) Dan said that he would give me an account on a PPC machine so I could debug this, but that hasn't happened yet. # * Exceptions # - I haven't been paying much attention to developments on this, # alth

Re: Parrot 0.0.9

2002-10-23 Thread Dan Sugalski
At 7:43 AM +1000 10/24/02, Rhys Weatherley wrote: Steve Fink wrote: - Stratospheric rehydrocalibration amplifiers for the .NET people (er... or something; I can't remember what they needed) The ability to embed arbitrary data in a pbc file under a named section. This data needs to

Re: Parrot 0.0.9

2002-10-23 Thread Rhys Weatherley
Steve Fink wrote: > - Stratospheric rehydrocalibration amplifiers for the .NET people > (er... or something; I can't remember what they needed) The ability to embed arbitrary data in a pbc file under a named section. This data needs to be readable by the program when it runs, but is ot

Re: Parrot 0.0.9

2002-10-23 Thread Dan Sugalski
At 7:41 PM +0200 10/23/02, Leopold Toetsch wrote: Possible (feature/architectural) goals for 0.0.9 * PMC cleanup - Leo did a huge amount of work on this, but there are a few things left: - array.pmc still autocreates something called "PerlUndef"

Re: Parrot 0.0.9

2002-10-23 Thread Andy Dougherty
On Wed, 23 Oct 2002, Steve Fink wrote: > I suppose I ought to try to wrap up a release one of these days. I've > been thinking about the possibilities, but I'm not sure about the > current state of a couple of things. And what I'd most like to see > right now is some stabilization. So I'll list my

Re: Parrot 0.0.9

2002-10-23 Thread Tom Hughes
In message <[EMAIL PROTECTED]> Steve Fink <[EMAIL PROTECTED]> wrote: > * Keyed access > - Another discussion that's gone over my head. Leo has a scheme to > dramatically reduce the number of instructions, at the cost of > requiring a couple of opcodes for keyed accesses; Dan sa

Re: Parrot 0.0.9

2002-10-23 Thread Leopold Toetsch
Steve Fink wrote: I suppose I ought to try to wrap up a release one of these days. - Artificial goal: I want the list of pending patches to be smaller than one screenfull before I release. Fortunately, I have a large screen. I did set 2 of them to "Applied". I'll wade through my

Parrot 0.0.9

2002-10-23 Thread Steve Fink
I suppose I ought to try to wrap up a release one of these days. I've been thinking about the possibilities, but I'm not sure about the current state of a couple of things. And what I'd most like to see right now is some stabilization. So I'll list my current thinking: Prerequisites for 0.0.9 rele

Re: Steps toward parrot 0.0.9 and beyond

2002-10-11 Thread Steve Fink
On Thu, Oct 03, 2002 at 09:12:03AM +0200, Leopold Toetsch wrote: > I did post 3 major proposals for the next big changes in parrot > internals - but I'm lacking somehow final answers on these. > > There seems to be a general consens to do these changes though. > > So here is a summary of the ne

Steps toward parrot 0.0.9 and beyond

2002-10-02 Thread Leopold Toetsch
I did post 3 major proposals for the next big changes in parrot internals - but I'm lacking somehow final answers on these. There seems to be a general consens to do these changes though. So here is a summary of the next changes to parrot: 1) restructure class dependencies (s. #17352, #173