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
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
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
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
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
> #
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
[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
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
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
"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
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
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
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
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
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
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
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
---
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
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:
> >>
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
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
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
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"
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
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
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
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
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
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
43 matches
Mail list logo