Re: [perl #17490] Magic is useless unless verifiable.
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 would do, but no matter. It's so 'large' because of an idea 'borrowed' from the PNG spec. One or more of the bytes 0 & 4-7 are likely to be damaged by common transport encoding errors. I've changed my proposal to explicitly note this. > > * Bytes 20 through 31 are now padding so the core.op fingerprint can > > be expanded in the future. > > Marvy. Important note: All those bytes *must* be zeros in the current > implementation. See below. That was already in my proposal but I've changed the wording to include I. > > * Do we need to keep the Opcode Type? It's not clear to me what it's used > > for. > > > >+--+--+--+--+ > >| Opcode Type (Perl = 0x5045524c) | > >+--+--+--+--+ > > I don't think it's useful. A pbc file is Parrot byte code; if Parrot > learns to translate .NET, Python, or JVM files, it'll read them in > their native formats. Sounds reasonable. It's been dumped. > > > * Does it make sense to use a fix size header? The offset of the first > > segment could be calculated by multiplying an "offset byte" and the > > wordsize. > > We don't have to decide that. A fixed size header now does not > foreclose the possiblity that byte #31 will be that "how many more > words should be considered part of the header" feature you suggest. Fair enough. An updated patch is attached. -J -- Index: docs/parrotbyte.pod === --- docs/parrotbyte.pod (revision 9235) +++ docs/parrotbyte.pod (working copy) @@ -7,8 +7,33 @@ =head1 Format of the Parrot bytecode +Parrot's bytecode format consists of a small endian neutral header region +followed by a series of segments. ALL words (non-bytes) following the header +are are stored in native order, unless otherwise specified. + +=head1 PBC Header + +The PBC header is a fixed 32 bytes in length. Header values are all encoded as +either a single byte or a string so that it can be parsed without having to +consider the endianness of the data. + 0 1 2 3 +--+--+--+--+ + | 0xfe 0x50 0x42 0x43 | + +--+--+--+--+ + | 0x0d 0x0a 0x1a 0x0a | + +--+--+--+--+ + +The header begins with an eight byte I or I. +This is equivalent to the C strings C<\376PBC\r\n\032\n> (ASCII) and +C<\xfe\x50\x42\x43\x0d\x0a\x1a\x0a> sans the terminating C bytes. Bytes +0 and 4-7 are designed to catch common types of file corruption caused by +transport encoding mechanisms (for example, FTP ASCII transfers). This format +was inspired by the PNG Specification. Please see RFC 2083 for an explanation +of the advantages of this strategy. + + 8 9 10 11 + +--+--+--+--+ | Wordsize | Byteorder| Major | Minor | +--+--+--+--+ @@ -20,7 +45,7 @@ Byteorder currently supports two values: (0-Little Endian, 1-Big Endian) - 4 5 + 12 13 14 +--+--+--+--+ | INT size | FloatType| 10 Byte ... | +--+--+--+--+ @@ -29,26 +54,40 @@ | core.ops is here| +--+--+--+--+ -INT size (sizeof(INTVAL)) must be 4 or 8. FloatType 0 is IEEE 754 8 byte +INT size (C) must be 4 or 8. FloatType 0 is IEEE 754 8 byte double, FloatType 1 is i386 little endian 12 byte long double. - 16 + + 20 21 22 23 +--+--+--+--+ - | Parrot Magic = 0x 13155a1 | + | padding | +--+--+--+--+ - -Magic is stored in native byteorder. The loader uses the byteorder header to -convert the Magic to verify. More specifically, ALL words (non-bytes) in the -bytecode file are stored in native order, unless otherwise specified. - - 20* + | | +--+--+--+--+ - | Opcode Type (Perl = 0x5045524c) | + | | +--+--+--+--+ -The asterisk for the offset states, from here we have opcodes. The given -offsets are for 32 bit opcode types only. +Following the core.ops fingerprint, the header I be padded with C +bytes to be an overall 32 bytes in length. +All words following the header will be interpreted as Op codes. + +=head2 Magic Description + +The fol
[perl #22873] perldoc -U vs. perldoc -u
Does anyone have an old enough Perl to test if this is still an issue? -J --
[perl #37287] [TODO] pdb - don't die on exceptions
# New Ticket Created by Joshua Hoblitt # Please include the string: [perl #37287] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37287 > Subject: Re: [perl #22343] pdb + internal_exception = segfault Date: Wed, 21 Sep 2005 15:03:15 -0400 (EDT) To: Joshua Hoblitt via RT <[EMAIL PROTECTED]> From: Simon Glover <[EMAIL PROTECTED]> On Wed, 21 Sep 2005, Joshua Hoblitt via RT wrote: >> [EMAIL PROTECTED] - Tue May 27 19:30:39 2003]: >> >> >> Currently, if you're in the debugger, and do anything that causes an >> internal_exception call within the interpreter, you get a segfault. [Backtrace snipped] >> ...etc >> >> I think what's happening is that we're trying to destroy the >> interpreter >> that pdb itself is using, which will clearly cause bad things to >> happen. > > Does this bug still exist? > I've just tried this out with the current snapshot, and you no longer get a segfault. However, I'd still argue that the interaction between pdb and Parrot's exception code remains buggy, as hitting an internal exception call kills not only the currently executing code but also kills the whole pdb session. It would be more useful if it just dropped you back to the main pdb prompt. Whether this is worth fixing depends on the perceived usefulness of pdb, and so isn't my call -- I certainly have no time to work on it for the forseeable future. Regards, Simon
[perl #24682] [BUG] How to handle divide by zero?
Has handling of SIGFPE been 'well' resolved or is this a TODO item? -J
Re: [perl #22873] perldoc -U vs. perldoc -u
On Mon, Sep 26, 2005 at 08:43:41PM -0700, Joshua Hoblitt via RT wrote: > Does anyone have an old enough Perl to test if this is still an issue? > > -J > > -- parrot no longer supports perl 5.005 (from lib/Parrot/Revision.pm ) package Parrot::Revision; use strict; use 5.006; If I replace our with my ( and cross my fingers ) the configure finishes but warns .value for 'revision' in config/gen/config_pm/myconfig.in is undef at lib/Parrot/Configure/Step.pm line 237 I presume this is related to our -> my If I run make it fails as it can not find Pod::Usage. I can see a few Pod::* modules under lib so I presume policy is to add perl module depencies there and not to require the user to install them locally. Can someone add Pod::Usage under ./lib. Thanks Peter -- We have committed to authoritatively supply progressive data while continuing to seamlessly provide access to innovative catalysts for change to exceed customer expectations
Re: [perl #24177] [PATCH] Make Parrot dlcompat aware on OS X
Sorry I was on holiday. Yes this can be closed.
On 21 Sep 2005, at 09:45, Joshua Hoblitt via RT wrote:
[mikescott - Thu Oct 09 11:49:45 2003]:
If someone happens to have dlcompat
http://www.opendarwin.org/projects/dlcompat/
installed on OS X then the following patch will let Parrot be
aware of
this and use it.
The following changes are made:
config/auto/headers.pl
Add dlfcn.h to @extra_headers so it will be detected even if
dlcompat
has been installed after Perl.
config/gen/platform/darwin.c
Add conditional code for PARROT_HAS_HEADER_DLFCN.
config/init/hints/darwin.pl
Add values for libs and so.
dynext.c
Replace SO_EXTENSION with PARROT_DLL_EXTENSION which is already
defined in config.h.
nci_test.c
Remove #include because it is unused.
t/pmc/nci.t
Remove the $PConfig{jitcpuarch} eq 'i386' condition from the SKIP
conditional.
conf/gen/makefiles/root.in
Change libnci.so target to libnci and use $(SO).
Running
make libnci
perl t/harness --running-make-test --gc-debug t/pmc/nci.t
passes all tests with this patch applied.
Is this still an issue?
-J
Re: [RFC] Debug Segment, HLL Debug Segment And Source Segment
Rumour has it this thread got warnocked... ;-) My original task from leo was to sort out the PASM and PIR debug segment to handle multiple files. I thought I might try and sort out the HLL debug seg while I was on the job. From Roger's input and further discussion on IRC, it seems that we need something more clever for the HLL debug seg than the PASM/PIR one. So, I'll back off trying to deal with HLL debug for now (provided my supply of time goes on, I'll try and come back to that in the not too distant future) and implement something much like I spec'd for PASM and PIR, which only needs a simple debug segment with file and line number. "Roger Browne" <[EMAIL PROTECTED]> wrote: FORMAT PROPOSAL... Great! Anything that brings parrot closer to being able to report the HLL filename and line numbers is a good thing! Seems there will be a slighlty longer wait on this one now, but this is very much needed, I agree. SOURCE SEGMENTS ... the idea would seem to be that this segment can contain source code. I suspect the intention of it was to store the source code of high level languages rather than PASM or PIR. I don't think Parrot should care about what languages are in the source segments. If someone is writing directly in PASM or PIR, that can go in a source segment. If someone is writing in a high-level langauge, that can go in a source segment. If someone is writing data from which HLL code is generated by some utility (e.g. yacc, a UML tool, or a GUI designer), that data can go in a source segment too. Any kind of source code for which there exists some kind of debugging tool is a candidate to go into a source segment. This implies that there could be more than one source segment per .pbc file, and more than one source location for each opcode. It also implies that (eventually) parrot will have a way of knowing how to call all the candidate debuggers for a particular bytecode location (according to which source language the programmer wants to debug in). [Incidentally, source segments may also meet the needs of those who wish to distribute source with every application, without burdening those who just want to run the compiled code.] Pretty much agree with this. ... 2) Allowing for a reference into the source segment in place of a filename. Some development tools are still going to want the filename, even if there is a corresponding source segment in the .pbc file. I think it should be possible to include both. I was thinking of putting the filename in the source segment, so you could iterate over the source segments and get the filenames of the source files. So the filenames would be there. COMPATIBILITY This change is incompatible with the current debug segment format. But that's OK, we're still in development. Sure, but if we're going to change it, let's change it to something general that won't need to be changed again after version 1.0 is released. This is the argument that makes me think we hold off the HLL debug seg for a little while, until somebody (maybe myself) can come up with a design that meets the needs of HLLs better. This is something that Dan Sugalski mooted in his "WCB: Full bytecode metadata" blog entry: http://www.sidhe.org/~dan/blog/archives/000419.html I like the idea that each HLL can store whatever kind of metadata it wants. In particular, I'd like to have my Amber compiler put column numbers as well as line numbers into the .pbc file, and perhaps even information about which optimizations it has applied. Yeah, though we also have to consider how Parrot will know what metadata to show when an error occurs. I guess we need something per language that gets called along with a reference to the appropriate chunk of meta-data for the current location and knows how to render an error message for that language. Then just have a default way to dump the data when this is not supplied. Also need some thought with regard to how we can efficiently store such metadata in a packfile. 3) Still being space-efficient on disk Source segments should probably be compressed. There's a lot of repetition and whitespace in most source languages, so they tend to compress really well. Any reference into the source would be an offset into the uncompressed source (which would only need to be uncompressed during debugging runs). Hadn't thought of this...may be a good idea provided we can find a cheap to implement and free of legal issues compression algorithm. I'll admit now to not knowing a great deal about this kinda stuff. The opcode stream will contain one line number per bytecode instruction. You are proposing to use a chain of mappings to record the filename; why not use the same system for recording all kinds of metadata including line numbers? Sure, there's a small performance penalty - only during debugging runs - but there's a worthwhile space saving on disk (because typical HLLs produce a lot of bytecodes per line of source). HLLs d
Re: [perl #17490] Magic is useless unless verifiable.
"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 it's best to munge them together). Then I'll apply the doc patch at the same time as the implementation changes so they're kept in sync. Jonathan
Re: [perl #24682] [BUG] How to handle divide by zero?
On Sep 27, 2005, at 5:49, Joshua Hoblitt via RT wrote: Has handling of SIGFPE been 'well' resolved or is this a TODO item? SIGFPE with integer operations isn't portable and the discussion concluded in: explicit checks are better then relying on signals. I think it's resolved. -J leo
Re: [perl #22873] perldoc -U vs. perldoc -u
On Tue, Sep 27, 2005 at 01:43:02AM -1000, Joshua Hoblitt wrote: > On Tue, Sep 27, 2005 at 11:31:17AM +0100, Peter Sinnott wrote: > > On Mon, Sep 26, 2005 at 08:43:41PM -0700, Joshua Hoblitt via RT wrote: > > > Does anyone have an old enough Perl to test if this is still an issue? > > > > Prior to 5.6.0 and 'our' package variables had to be declared with the > 'vars' pragma. See `perldoc vars`. > It was only a very very half hearted attempt to get it to work. Lacking the revision variable will only become a problem if it gets as far as actually compiling some C code. > > If I run make it fails as it can not find Pod::Usage. > > I can see a few Pod::* modules under lib so I presume > > policy is to add perl module depencies there and not > > to require the user to install them locally. Can someone > > add Pod::Usage under ./lib. > > If you can make a convincing argument that 5.005xx should be supported > that is possible - but why? > I only ran it with 5.005 as that is what the bug contained. I could try saying at least as many people use 5.005 as Irix but I am not even convincing myself with that. > Cheers, > > -J > > -- -- We have committed to authoritatively supply progressive data while continuing to seamlessly provide access to innovative catalysts for change to exceed customer expectations
Re: [RFC] Debug Segment, HLL Debug Segment And Source Segment
Jonathan Worthington wrote: > ... My original task from leo > was to sort out the PASM and PIR debug segment to handle multiple files. > ... it seems that we need > something more clever for the HLL debug seg than the PASM/PIR one. So, I'll > back off trying to deal with HLL debug for now Fair enough! A small task undertaken is always better than a larger task warnocked. By the way (just to complicate things further) PIR files can include other PIR files using the ".include" directive, but the included filename and line numbers are not currently being processed. Regards, Roger Browne
PMCs in the dynclasses directory
The Amber compiler currently generates all its types as PIR objects, but I'm considering implementing the basic types as PMCs instead. If I do this, can I have the Amber PMCs included in the dynclasses directory of the Parrot distribution? (Assigning copyright to the Perl Foundation would not be a problem). Regards, Roger Browne
Re: [RFC] Debug Segment, HLL Debug Segment And Source Segment
"Roger Browne" <[EMAIL PROTECTED]> wrote: Jonathan Worthington wrote: ... My original task from leo was to sort out the PASM and PIR debug segment to handle multiple files. ... it seems that we need something more clever for the HLL debug seg than the PASM/PIR one. So, I'll back off trying to deal with HLL debug for now Fair enough! A small task undertaken is always better than a larger task warnocked. Yup, and as I've still much to learn about the Parrot codebase, a lighter learning curve for me. By the way (just to complicate things further) PIR files can include other PIR files using the ".include" directive, but the included filename and line numbers are not currently being processed. This along with the recent addition of pbc_merge are the main motivating factors for improving the PASM/PIR debug segment. Jonathan
Re: PMCs in the dynclasses directory
Roger Browne wrote: The Amber compiler currently generates all its types as PIR objects, but I'm considering implementing the basic types as PMCs instead. If I do this, can I have the Amber PMCs included in the dynclasses directory of the Parrot distribution? Have a look at languages/tcl/classes - it contains Tcl PMCs. We could do the same for languages/amber. (Assigning copyright to the Perl Foundation would not be a problem). Great. Regards, Roger Browne leo
Re: PMCs in the dynclasses directory
On Tue, 2005-09-27 at 15:11 +0200, Leopold Toetsch wrote: > Have a look at languages/tcl/classes - it contains Tcl PMCs. We could do > the same for languages/amber. Thanks - now I just need to learn to program in C :-) Roger
Re: [perl #22873] perldoc -U vs. perldoc -u
On Tue, 27 Sep 2005, Peter Sinnott wrote: > On Tue, Sep 27, 2005 at 01:43:02AM -1000, Joshua Hoblitt wrote: > > On Tue, Sep 27, 2005 at 11:31:17AM +0100, Peter Sinnott wrote: > > > On Mon, Sep 26, 2005 at 08:43:41PM -0700, Joshua Hoblitt via RT wrote: > > > > Does anyone have an old enough Perl to test if this is still an issue? > > > > > > Prior to 5.6.0 and 'our' package variables had to be declared with the > > 'vars' pragma. See `perldoc vars`. > > > > It was only a very very half hearted attempt to get it to work. > Lacking the revision variable will only become a problem if it gets > as far as actually compiling some C code. > > > > If I run make it fails as it can not find Pod::Usage. > > > I can see a few Pod::* modules under lib so I presume > > > policy is to add perl module depencies there and not > > > to require the user to install them locally. Can someone > > > add Pod::Usage under ./lib. > > > > If you can make a convincing argument that 5.005xx should be supported > > that is possible - but why? Parrot requires at least perl-5.6, and that's now documented in the README file. (See RT ticket perl #30095). -- Andy Dougherty [EMAIL PROTECTED]
Re: Branch Review
Chip Salzenberg wrote: Chip writes: * optional parameter interface: ":opt_count" -> ":opt_flag" So ":opt_count" should be replaced with ":opt_flag", which sets its target register to a boolean indicating whether the immediately preceding parameter was passed or not, rather than a count of optionals present. Done (r9254). The canonical sequence for passing optional args now is: .sub foo .param arg1 :optional .param int has_arg1 :opt_flag .param arg2 :optional .param int has_arg2 :opt_flag ... leo
Re: [perl #24682] [BUG] How to handle divide by zero?
Joshua Hoblitt wrote:
Were checks implemented or is this a TODO?
inline op div(inout INT, in INT) :base_core {
$1 /= $2;
goto NEXT();
}
-J
leo
Re: [perl #22873] perldoc -U vs. perldoc -u
On Tue, Sep 27, 2005 at 11:31:17AM +0100, Peter Sinnott wrote: > On Mon, Sep 26, 2005 at 08:43:41PM -0700, Joshua Hoblitt via RT wrote: > > Does anyone have an old enough Perl to test if this is still an issue? > > > > -J > > > > -- > > parrot no longer supports perl 5.005 The -U flag to perdoc should exist under 5.6.x. > If I replace our with my ( and cross my fingers ) the configure finishes but > warns > > .value for 'revision' in config/gen/config_pm/myconfig.in is undef at > lib/Parrot/Configure/Step.pm line 237 > > I presume this is related to our -> my Prior to 5.6.0 and 'our' package variables had to be declared with the 'vars' pragma. See `perldoc vars`. > If I run make it fails as it can not find Pod::Usage. > I can see a few Pod::* modules under lib so I presume > policy is to add perl module depencies there and not > to require the user to install them locally. Can someone > add Pod::Usage under ./lib. If you can make a convincing argument that 5.005xx should be supported that is possible - but why? Cheers, -J -- pgpgH07OTlkDb.pgp Description: PGP signature
Re: [perl #18319] [PATCH] Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
On Mon, 26 Sep 2005, Joshua Hoblitt via RT wrote: > > [jhoblitt - Tue Sep 20 02:20:48 2005]: > > > > > [doughera - Mon Nov 11 05:41:20 2002]: > > > > > > I've gotten no negative feedback (no positive either, but that's > > > normal) > > > so I propose that the following patch go in. > > > > Are there still linkage issue that need to be resolved or can this bug > > be closed? There still are linkage issues. However, someone did go through and apply bits and pieces of this patch, so it won't apply cleanly anymore. I don't know how to flag that in the RT system. Perhaps leave it "Open," or perhaps flag it as "Rejected" or "Stalled". -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #24682] [BUG] How to handle divide by zero?
On Tue, Sep 27, 2005 at 01:50:55PM +0200, Leopold Toetsch wrote: > > SIGFPE with integer operations isn't portable and the discussion > concluded in: > explicit checks are better then relying on signals. > > I think it's resolved. > Were checks implemented or is this a TODO? -J -- pgpQnoUAAr2w1.pgp Description: PGP signature
threads
hi all, Im interested to know how perl6/parrot implements threads. Im mainly interested as im writing a small vm of my own. Not a production vm like parrot, more for interest/curiosity etc. From the outset i decided i wanted the vm to provide its own threading mechanism i.e. not based on posix threads for example. My first plan was to have 2 native threads, one for execution of the main 'core' execution code the runtime if you like, the other thread was used to tell the execution code to swap threads. I thought i could synchronise these 2 using native semaphores. When it comes down to it a single op code takes a number of nastive instructions i.e. to execute an add insttuction i may have to do (say) 5 things. so I just check after each op code has been executed to see if the thread needs swapping out. That seems like a bad idea mainly due to speed/efficiency. Each thread is a top level object, so the stack, all stack pointers and register data etc resides in the thread, but i still cant have the execution engine swapping threads mid operation, so in my add example i still dont think i would want the execution engine swapping out a thread after 3 instructions, it would need to complete all 5. Its been a bit of a brick wall this, it seemed to be going quite well up to this point and i need to solve this before i can move on with lwm,(light weight machine). Any pointers, thoughts or comments are welcome. Cheers Dave
Re: PMCs in the dynclasses directory
I see no problem with this, but: I would encourage that any Amber specific PMCS instead go into languages/amber/classes, in an effort to keep classes/ and dynclasses/ restricted to the basic parrot types. (see languages/tcl and config/gen/makefiles/tcl.in) for examples on how to set this up. Regards! Roger Browne writes: The Amber compiler currently generates all its types as PIR objects, but I'm considering implementing the basic types as PMCs instead. If I do this, can I have the Amber PMCs included in the dynclasses directory of the Parrot distribution? (Assigning copyright to the Perl Foundation would not be a problem). Regards, Roger Browne
Re: PMCs in the dynclasses directory
Will Coleda apparently needs to actually read all of his mail in the morning before replying to it. ^_^ Will Coleda writes: I see no problem with this, but: I would encourage that any Amber specific PMCS instead go into languages/amber/classes, in an effort to keep classes/ and dynclasses/ restricted to the basic parrot types. (see languages/tcl and config/gen/makefiles/tcl.in) for examples on how to set this up. Regards! Roger Browne writes: The Amber compiler currently generates all its types as PIR objects, but I'm considering implementing the basic types as PMCs instead. If I do this, can I have the Amber PMCs included in the dynclasses directory of the Parrot distribution? (Assigning copyright to the Perl Foundation would not be a problem). Regards, Roger Browne
[perl #37293] [TODO] add tests for Data::Escape
# New Ticket Created by jerry gay # Please include the string: [perl #37293] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37293 > the Data::Escape library does not have a robust test file. more tests are required to document current behavior in preparation for a code rewrite. the test file is found at t/library/data_escape.t
Re: threads
On Sep 27, 2005, at 17:14, Dave Frost wrote: hi all, Im interested to know how perl6/parrot implements threads. *) based on OS threads *) one interpreter per thread *) STM for shared objects / atomicity Any pointers, thoughts or comments are welcome. Cheers Dave leo
Re: [perl #17490] Magic is useless unless verifiable.
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]>
Re: [perl #17490] Magic is useless unless verifiable.
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 ^conner: Oh, that's a good plan -J -- On Tue, Sep 27, 2005 at 12:13:06PM +0100, Jonathan Worthington wrote: > "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 it's best to munge them together). Then I'll apply the doc patch at the > same time as the implementation changes so they're kept in sync. > > Jonathan > pgp5O3V7mC9Ej.pgp Description: PGP signature
