[perl #40410] Segfault in packfile code

2006-09-28 Thread [EMAIL PROTECTED] via RT
Hi, I've tracked the bug down some and ci'd a workaround for this tonight, with a comment that some more digging maybe is wanted in the future. But it solves the problem just fine at the moment. Jonathan

[svn:parrot-pdd] r14781 - trunk/docs/pdds/clip

2006-09-28 Thread leo
Author: leo Date: Thu Sep 28 01:39:18 2006 New Revision: 14781 Modified: trunk/docs/pdds/clip/pddXX_cstruct.pod Log: pddXX_cstruct - clarify a few items Modified: trunk/docs/pdds/clip/pddXX_cstruct.pod == ---

Re: socket related constants

2006-09-28 Thread Nicholas Clark
On Fri, Sep 08, 2006 at 12:38:39PM +0200, Leopold Toetsch wrote: Hi, typical socket ocde currently looks a bit unfriendly due to magic constants, e.g. socket sock, 2, 1, 6 # PF_INET, SOCK_STREAM, tcp I'd like to have symbolic constants for all that stuff: socket sock

Re: [svn:parrot-pdd] r14774 - in trunk: . docs/pdds/clip

2006-09-28 Thread Leopold Toetsch
Am Donnerstag, 28. September 2006 01:30 schrieb Jonathan Worthington: Hi, Some first thoughts that come to mind after reading leo's two proposals. +with new variants of the Caddattribute opcode: + + addattribute cs, 'a', .DATATYPE_INT + addattribute cs, 'b', .DATATYPE_CHAR

[HOWTO] call a method on a PMC in PIR

2006-09-28 Thread Karl Forner
I suppose that again it is a trivial question, but I did not manage to find the answer by myself in the documentation. So I want for example to call diretly the elements method on a FixedBooleanArray I tried pmc.elements() pmc.elements() pmc._elements() pmc.__elements() But it did not

Re: [HOWTO] call a method on a PMC in PIR

2006-09-28 Thread Leopold Toetsch
Am Donnerstag, 28. September 2006 12:47 schrieb Karl Forner: I suppose that again it is a trivial question, but I did not manage to find the answer by myself in the documentation. So I want for example to call diretly the elements method on a FixedBooleanArray I tried pmc.elements()

Re: socket related constants

2006-09-28 Thread Joshua Hoblitt
On Thu, Sep 28, 2006 at 09:36:13AM +0100, Nicholas Clark wrote: However, step 2 is easier for Perl because we're not trying to do portable bytecode. Some constants, (such as *most* of the socket constants, but I think not all) are defined in RFCs, so can be baked into bytecode at compile

Re: FYI compiling PIR function calls

2006-09-28 Thread chromatic
On Thursday 28 September 2006 11:25, Allison Randal wrote: Exactly, change the most common case (of a method call by bare name) to be the unmarked case, and use some additional marking on the less common case of calling a method by a string name or method object. I wouldn't use '$' to mark

Re: FYI compiling PIR function calls

2006-09-28 Thread Patrick R. Michaud
On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote: On Thursday 28 September 2006 11:25, Allison Randal wrote: obj.{bar}() # a string method name obj.{$S1}() I'm not sure what's meant by a string method name above, but I'd look at it as: .local string abc

Re: FYI compiling PIR function calls

2006-09-28 Thread chromatic
On Thursday 28 September 2006 12:42, Patrick R. Michaud wrote: To push a little more the other direction, is it possible for the compiler to detect symbol and method name conflicts?   It's only the collision that makes a case ambiguous, right? I don't think that the compiler always knows

Re: FYI compiling PIR function calls

2006-09-28 Thread Leopold Toetsch
Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud: I'm just quoting the relevant pieces here and add some comments below:     obj.'abc'()              # call 'abc' method of obj     obj.abc()                # always the same as above     obj.{abc}()              # call method

Re: FYI compiling PIR function calls

2006-09-28 Thread Allison Randal
Patrick R. Michaud wrote: On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote: On Thursday 28 September 2006 11:25, Allison Randal wrote: obj.{bar}() # a string method name obj.{$S1}() I'm not sure what's meant by a string method name above, but I'd look at it

Re: FYI compiling PIR function calls

2006-09-28 Thread Allison Randal
Leopold Toetsch wrote: Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud: obj.'abc'() # call 'abc' method of obj obj.abc()# always the same as above obj.{abc}() # call method indicated by abc symbol This makes a lot of

Draft of Bytecode PDD

2006-09-28 Thread Allison Randal
I just got off the phone with Jonathan Worthington. At YAPC::EU he agreed to draft a PDD for Parrot's bytecode file format. He has done a fantastic job. He's checking it in now, so everyone will have a chance to comment. The PDD incorporates a handful of important changes that have been

requirements gathering on mini transformation language

2006-09-28 Thread Allison Randal
I need a volunteer write up the requirements for a mini transformation language to use in the compiler tools. You wouldn't have to write up the specification for the language, just what features we need. This will help us plan what it's going to take to get from here to there, and give us a

Re: FYI compiling PIR function calls

2006-09-28 Thread Leopold Toetsch
Am Donnerstag, 28. September 2006 22:53 schrieb Allison Randal: Leopold Toetsch wrote: Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud: obj.'abc'() # call 'abc' method of obj obj.abc()# always the same as above obj.{abc}()

Re: requirements gathering on mini transformation language

2006-09-28 Thread Markus Triska
Allison Randal writes: mini transformation language to use in the compiler tools. For what purpose, roughly? I've some experience with rule-based peep-hole optimisations. If it's in that area, I volunteer. Best wishes, Markus Triska

Re: [HOWTO] call a method on a PMC in PIR

2006-09-28 Thread Karl Forner
METHOD INTVAL get_allocated_size() { return PMC_int_val2(SELF); /* or whatever */ } great, exactly what I needed thanks karl

Re: requirements gathering on mini transformation language

2006-09-28 Thread chromatic
On Thursday 28 September 2006 14:51, Markus Triska wrote: Allison Randal writes: mini transformation language to use in the compiler tools. For what purpose, roughly? I've some experience with rule-based peep-hole optimisations. If it's in that area, I volunteer. That's part of it, but

Bytecode PDD

2006-09-28 Thread Jonathan Worthington
Hi, I've checked in the proposed bytecode PDD and also most of the changes that I discussed with Allison earlier today. Feedback on it would be greatly appreciated. One of the areas that it would good to have some input on, even if it's just a yes, that's sane, is versioning. The current

Re: Re: FYI compiling PIR function calls

2006-09-28 Thread Matt Diephouse
Allison Randal [EMAIL PROTECTED] wrote: .local string abc obj.'abc'() # call 'abc' method of obj obj.abc()# always the same as above obj.{abc}() # call method indicated by abc symbol obj.{S0}() # call method

Re: FYI compiling PIR function calls

2006-09-28 Thread chromatic
On Thursday 28 September 2006 17:57, Matt Diephouse wrote: Why not handle this like we handle subroutines? That is, why don't we have a find_method opcode that returns a bound method? That simplifies parsing for IMCC and makes PIR a little simpler.     obj.'abc'() # call 'abc' method of obj  

[svn:parrot-pdd] r14785 - trunk/docs/pdds/clip

2006-09-28 Thread jonathan
Author: jonathan Date: Thu Sep 28 15:55:52 2006 New Revision: 14785 Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod Log: Add most of the changes resulting from discussion with Allison. Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod

[svn:parrot-pdd] r14784 - trunk/docs/pdds/clip

2006-09-28 Thread jonathan
Author: jonathan Date: Thu Sep 28 14:23:15 2006 New Revision: 14784 Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod Log: Add draft of the bytecode PDD. This is still missing some changes that need to be made following discussion with Allison, but gives the big picture of what is proposed.