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
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:
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)
[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 up
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, with
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
#
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 code to
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
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 did set 2 of
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-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 problem, I
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-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
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.
OTOH fixup
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 call.
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
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 by
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 number for
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 Perl
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:
- array.pmc still
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
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
---
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
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
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
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
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 filehandles
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
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 says that
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
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
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
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
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,
#
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 next
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,
36 matches
Mail list logo
