Joshua Hoblitt via RT wrote:
>>[doughera - Thu Oct 06 07:21:15 2005]:
>>
>>I think this bug can be closed. I just got those tests to pass on
>>Sparc/Solaris 8 with gcc -m64 -mcpu=v9. (Mind you lots of other tests
>>fail, but that's a separate problem.)
>>
>>
>>
>
>
> Jarrko,
>
> Are you OK w
On Thu, 6 Oct 2005, Joshua Hoblitt wrote:
> On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote:
> > > Jarkko,
> > >
> > > I never got a response from anyone. How would you feel about closing
> > > this bug?
> >
> > I don't think it can be closed until at least another big-
On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote:
> -J
>
>
>
>
> >>>
> >>
> >
> > Jarkko,
> >
> > I never got a response from anyone. How would you feel about closing
> > this bug?
>
> I don't think it can be closed until at least another big-endi
-J
>>>
>>
>
> Jarkko,
>
> I never got a response from anyone. How would you feel about closing
> this bug?
I don't think it can be closed until at least another big-endian 64-bit
platform (like IRIX 64 is/was) has been used to verify that things work.
> -J
>
>
>
Does anyone has access to an IRIX machine?
-J
--
On Thu, Sep 22, 2005 at 07:37:44PM +0300, Jarkko Hietaniemi wrote:
>
> >
> > Jarkko,
> >
> > Are there still outstanding issues on IRIX? AFAIK nobody else has been
> > building parrot on that platform.
>
> Unfortunately I no more have access t
>
> Jarkko,
>
> Are there still outstanding issues on IRIX? AFAIK nobody else has been
> building parrot on that platform.
Unfortunately I no more have access to that platform.
> -J
>
>
>
>
The packfile.c.pat and pf_items.c.pat address the byteswapping, the
dod.c patch was
needed in irix only (dbx showed the pool->mem_pool being zero, I don't
know whether
there's something deeper that my patch hides, but I was not about to
start debugging DOD--
There must be some other problem.
the
Jarkko Hietaniemi wrote:
The attached patch brings things if not to perfection at least quite
close.
Great. Thanks for your time having a look at that.
Applied. Works - i386 can successfully process all these PBCs.
I have tested
the patch and the included pbc files in:
- little-endian 64-bit tr
On Thu, 26 Feb 2004, Leopold Toetsch wrote:
> Andrew Dougherty <[EMAIL PROTECTED]> wrote:
> > Solaris/SPARC/Sun cc, longsize=4:
>
> > # PackFile_unpack: Not a Parrot PackFile!
> > # Magic number was [0x20a54100] not [0x013155a1]
>
> Does it work now?
Yes, great! Thanks.
>
> > And, just
At 10:13 AM -0500 2/26/04, Andrew Dougherty wrote:
In a somewhat similar vein, a challenge is emerging on the
Linux/UltraSPARC front. Under Debian's current 'unstable' and 'testing'
distributions, for example, you end up with the following types:
iv=long, intvalsize=8, intsize=4, opcode_t=long
Andrew Dougherty <[EMAIL PROTECTED]> wrote:
> perl Configure.pl
> will automatically pick up this broken configuration.
Yep. We have to cleanup here. Ages ago we did need a proper perl for
generating the pack formats. Now we just need any perl that runs the
config scripts. Parrot types sho
Andrew Dougherty <[EMAIL PROTECTED]> wrote:
> Solaris/SPARC/Sun cc, longsize=4:
> # PackFile_unpack: Not a Parrot PackFile!
> # Magic number was [0x20a54100] not [0x013155a1]
Does it work now?
> And, just to round out the report, on x86 with long-long opcodes,
... is broken ;)
> (what
At 03:56 PM 2/24/2004 -0500, Andrew Dougherty wrote:
On Tue, 24 Feb 2004, Jarkko Hietaniemi wrote:
>
> PackFile_unpack: Not a Parrot PackFile!
> Magic number was [0x4c524550] not [0x013155a1]
> Parrot VM: Can't unpack packfile t/native_pbc/integer_1.pbc.
> error:imcc:main: Packfile loading failed
T
On Tue, 24 Feb 2004, Jarkko Hietaniemi wrote:
> I am unfortunately running out of time to look more into the matter of
> bytecode reading being broken in Alpha. However, here are some notes
> for those who want to try, as of src/byteorder.c 1.20 and
> src/packfile.c 1.142. First of all note that
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> I followed up on the perlbug thread on this but so far it hasn't
> showed up in p6i, so here's a manual resend.
I've checked is some changes in the meantime, comments below inline.
> (3a) Why is fetch_op_mixed() reading in 8 bytes at a time when the
I followed up on the perlbug thread on this but so far it hasn't
showed up in p6i, so here's a manual resend.
--- cut here ---
I am unfortunately running out of time to look more into the matter of
bytecode reading being broken in Alpha. However, here are some notes
for those who want to try, as
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #27003]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=27003 >
From a freshly rsynced copy in tru64/alpha (*):
$ ./parrot t/native_pbc/intege
17 matches
Mail list logo
