Jonathan: You took this RT some time back. Could you give us an update
on its status? (It's the oldest outstanding RT.)
Thank you very much.
kid51
James Keenan via RT wrote:
Jonathan: You took this RT some time back. Could you give us an update
on its status? (It's the oldest outstanding RT.)
Resolved; PDD13 specified doing it a Different Way and that bit of PDD13
is one of the bits I've gotten around to implementing too, so this is
On Sun Mar 16 10:34:00 2008, [EMAIL PROTECTED] wrote:
Resolved; PDD13 specified doing it a Different Way and that bit of PDD13
is one of the bits I've gotten around to implementing too, so this is
fixed in both spec and implementation.
Resolving our oldest ticket! Thanks, Jonathan.
On Tue, Sep 27, 2005 at 01:49:52PM -0700, Chip Salzenberg wrote:
On Mon, Sep 26, 2005 at 03:29:52PM -1000, Joshua Hoblitt wrote:
An updated patch is attached.
All OK now with me, thanks.
The ASCII art of the 'padding' was wrong. A corrected patch is
attached.
-J
--
Index:
On Sun, Sep 25, 2005 at 09:43:15PM -0700, Chip Salzenberg wrote:
On Sun, Sep 25, 2005 at 10:04:16AM -1000, Joshua Hoblitt wrote:
* The magic number is no longer an opcode outside the header. It is
now an 8 byte magic string at the the beginning of the header.
I should think four
Joshua Hoblitt [EMAIL PROTECTED] wrote:
An updated patch is attached.
Looks good. Provided there's no further issues brought up with it, I'll put
it on my to implement list and do it when I'm doing the changes relating
to the PASM/PIR debug segment (bytecode format changes are a pain, so
On Mon, Sep 26, 2005 at 03:29:52PM -1000, Joshua Hoblitt wrote:
An updated patch is attached.
All OK now with me, thanks.
--
Chip Salzenberg [EMAIL PROTECTED]
Jonathan,
Chip gave an official OK via irc.
^conner chip, Jonathan said that he'd try to do it as part of his changes and
commit the doc patch when he's done
chip ^conner: Oh, that's a good plan
-J
--
On Tue, Sep 27, 2005 at 12:13:06PM +0100, Jonathan Worthington wrote:
Joshua Hoblitt [EMAIL
On Thu, Sep 22, 2005 at 12:07:48PM -0400, Matt Fowles wrote:
Mark Biggar writes:
d) use a magic number that can also be used as the byte order indicator.
I have seen architectures that swap byte ordering for 8 byte things
(like doubles) but not 4 byte things. So that gives 3 options
On Sun, Sep 25, 2005 at 12:24:52PM -0700, Chip Salzenberg via RT wrote:
I think the right answer is to use a magic string rather than a
magic number.
Leo and I been discussing this on #parrot and we've come to the same
conclusion. Attached is a possible patch for parrotbyte.pod that
implements
On Sun, Sep 25, 2005 at 10:04:16AM -1000, Joshua Hoblitt wrote:
* Expands the header to be 32 bytes in size.
OK
* The magic number is no longer an opcode outside the header. It is
now an 8 byte magic string at the the beginning of the header.
I should think four would do, but no
On Thu, Sep 22, 2005 at 05:00:11PM +0100, Jonathan Worthington wrote:
Interesting, thanks - they make some good suggestions there. Our current
magic number is 13155a1 - I'm unsure of the rationale behind it, but
there may be a reason. If we're going to change the packfile format, we
may
On Wed, Sep 21, 2005 at 11:44:17AM +0100, Jonathan Worthington wrote:
Joshua Hoblitt via RT [EMAIL PROTECTED] wrote:
[jhoblitt - Mon Sep 19 22:28:00 2005]:
[EMAIL PROTECTED] - Sun Sep 22 07:13:56 2002]:
If you're going to check the magic after the wordsize and bytecode, you
might as
Joshua Hoblitt wrote:
a) live with it
b) change the magic number to be two identical bytes so the byte
ordering doesn't matter
c) shrink the magic number to be a single byte
d) use a magic number that can also be used as the byte order indicator.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Roger Browne [EMAIL PROTECTED] wrote:
If you do tweak the signature for the packfile format, I suggest you
take a leaf out of the PNG specification and ensure that the signature
will robustly detect common errors such as byte order transpositions,
CRLF-to-newline mappings (e.g. when binary files
Jonathan~
On 9/22/05, Jonathan Worthington [EMAIL PROTECTED] wrote:
Roger Browne [EMAIL PROTECTED] wrote:
If you do tweak the signature for the packfile format, I suggest you
take a leaf out of the PNG specification and ensure that the signature
will robustly detect common errors such as
Joshua Hoblitt via RT [EMAIL PROTECTED] wrote:
[jhoblitt - Mon Sep 19 22:28:00 2005]:
[EMAIL PROTECTED] - Sun Sep 22 07:13:56 2002]:
The point of having a validifiable magic number at the start
of a bytecode file is to avoid this sort of thing:
% ../../parrot -j mops.pasm
simon:
If you're going to check the magic after the wordsize and bytecode, you
might as well get rid of it altogether.
...
Jonathan:
...Change the packfile format, or code around the current way
If you do tweak the signature for the packfile format, I suggest you
take a leaf out of the PNG
On Wed, 2005-09-21 at 11:44 +0100, Jonathan Worthington wrote:
but I can cause a segfault from random input on x86.
--
$ ./parrot -j docs/running.pod
Segmentation fault
This is a Bad Thing and needs fixing. I'll see what I can find - I don't
even see a segfault or any other error
# New Ticket Created by Simon Cozens
# Please include the string: [perl #17490]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17490
The point of having a validifiable magic number at the start
of a bytecode file is
20 matches
Mail list logo
