Parrot v0.0.9 code freeze

0 views
Skip to first unread message

Steve Fink

unread,
Dec 10, 2002, 4:45:20 PM12/10/02
to perl6-i...@perl.org
Heads up. The weather report indicates a feature freeze on Sat
2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to
a release on Wed 2002-Dec-18. So if you have any feature changes that
you want to get into 0.0.9 (and it isn't too destabilizing), please
commit them before Saturday.

Sometime between now and then, I'll compile a list of changes since
0.0.8.

This release will go out even if the tinderbox isn't completely green,
because I don't want to delay it any further, but I would greatly
appreciate any improvements in that area. Feel free to use
http://foxglove.dnsalias.org/parrot/ to get a snapshot view of what
tests are failing.

Tanton Gibbs

unread,
Dec 10, 2002, 7:13:49 PM12/10/02
to perl6-i...@perl.org
I'm looking at the Tru64 problem.

The manifest problem is trivial:
languages/jako/docs/jako.pod needs to be added to the MANIFEST

The multiarray problem only occurs if you turn on --gc-debug...still looking
at it

Tanton

Tanton Gibbs

unread,
Dec 11, 2002, 7:18:27 AM12/11/02
to Tanton Gibbs, perl6-i...@perl.org
I'm still not sure what the problem is...but if you turn --gc-debug off,
then the
array diminsions are correct...e.g., 10 for the first dimension. Therefore,
the calculation
of the array index is performed correctly. However, with --gc-debug on, the
array dimension
is correct for the first dimension (0,0 - 0,20) as well as the first element
of the first dimension...(1,0). But it is wrong for all of the others. It
becomes 1 instead of 10. I have no clue yet why...still looking into it.
However, all tests pass on Tru64 if --gc-debug is off.

Simon Glover

unread,
Dec 11, 2002, 2:29:42 PM12/11/02
to Tanton Gibbs, perl6-i...@perl.org

On Tue, 10 Dec 2002, Tanton Gibbs wrote:

> I'm looking at the Tru64 problem.
>
> The manifest problem is trivial:
> languages/jako/docs/jako.pod needs to be added to the MANIFEST

Implicit patch applied, thanks.

Simon


Steve Fink

unread,
Dec 11, 2002, 11:35:13 PM12/11/02
to Tanton Gibbs, perl6-i...@perl.org
On Dec-10, Tanton Gibbs wrote:
> I'm looking at the Tru64 problem.

Yay! Thank you.

Steve Fink

unread,
Dec 11, 2002, 11:45:12 PM12/11/02
to Tanton Gibbs, perl6-i...@perl.org
On Dec-11, Tanton Gibbs wrote:
> I'm still not sure what the problem is...but if you turn --gc-debug
> off, then the array diminsions are correct...e.g., 10 for the first
> dimension. Therefore, the calculation of the array index is
> performed correctly. However, with --gc-debug on, the array
> dimension is correct for the first dimension (0,0 - 0,20) as well as
> the first element of the first dimension...(1,0). But it is wrong
> for all of the others. It becomes 1 instead of 10. I have no clue
> yet why...still looking into it. However, all tests pass on Tru64 if
> --gc-debug is off.

Are the Tru64 registers scanned for live PMCs/Buffers? I don't know
what things would typically get missed that way, but it's a known
problem for most architectures (or was until recently? What's the
status on this?)

Does Tru64 have hardware breakpoints? They're nice for this sort of
thing -- find a value that eventually becomes incorrect, take the
address of it at a point when it is still correct, then watch what it
points to:

(gdb) p interpreter->ctx.pmc_reg.registers[0]->cache.int_val
$6 = 1
(gdb) p &interpreter->ctx.pmc_reg.registers[0]->cache.int_val
$7 = (INTVAL *) 0x810c904
(gdb) watch *$7
Hardware watchpoint 2: *$7
(gdb) continue
.
.
.

Except that the garbage collector tends to move stuff around, which
can defeat this scheme.

I doubt any of this was useful, but just in case...

Tanton Gibbs

unread,
Dec 12, 2002, 3:23:28 AM12/12/02
to Steve Fink, perl6-i...@perl.org
> Are the Tru64 registers scanned for live PMCs/Buffers? I don't know
> what things would typically get missed that way, but it's a known
> problem for most architectures (or was until recently? What's the
> status on this?)

I don't know if they are or not. How could you tell?

> Does Tru64 have hardware breakpoints? They're nice for this sort of
> thing -- find a value that eventually becomes incorrect, take the
> address of it at a point when it is still correct, then watch what it
> points to:
>
> (gdb) p interpreter->ctx.pmc_reg.registers[0]->cache.int_val
> $6 = 1
> (gdb) p &interpreter->ctx.pmc_reg.registers[0]->cache.int_val
> $7 = (INTVAL *) 0x810c904
> (gdb) watch *$7
> Hardware watchpoint 2: *$7
> (gdb) continue
> .

I'll try this on the weekend...I'm moving today and won't have internet
until tomorrow. But I'll give it a shot and see.

Tanton

Juergen Boemmels

unread,
Dec 12, 2002, 10:51:32 AM12/12/02
to Steve Fink, perl6-i...@perl.org
Steve Fink <st...@fink.com> writes:

> Heads up. The weather report indicates a feature freeze on Sat
> 2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to
> a release on Wed 2002-Dec-18. So if you have any feature changes that
> you want to get into 0.0.9 (and it isn't too destabilizing), please
> commit them before Saturday.

Is it possible to put patch #18379 in?
This patch brings languages scheme in the direction of a functional
language. It shouldn't break anything, because its only a scheme ->
pasm translation.

bye
b.
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47

Dan Sugalski

unread,
Dec 12, 2002, 11:01:37 AM12/12/02
to Juergen Boemmels, Steve Fink, perl6-i...@perl.org
At 4:51 PM +0100 12/12/02, Juergen Boemmels wrote:
>Steve Fink <st...@fink.com> writes:
>
>> Heads up. The weather report indicates a feature freeze on Sat
>> 2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to
>> a release on Wed 2002-Dec-18. So if you have any feature changes that
>> you want to get into 0.0.9 (and it isn't too destabilizing), please
>> commit them before Saturday.
>
>Is it possible to put patch #18379 in?
>This patch brings languages scheme in the direction of a functional
>language. It shouldn't break anything, because its only a scheme ->
>pasm translation.

It's in.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Reply all
Reply to author
Forward
0 new messages