Parrot v0.0.9 code freeze
Steve Fink
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
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
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
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
> I'm looking at the Tru64 problem.
Yay! Thank you.
Steve Fink
> 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
> 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
> 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
>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