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
==
--- trunk/do
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:
>
> socke
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 C opcode:
> > +
> > + addattribute cs, 'a', .DATATYPE_INT
> > + addattribute cs, 'b', .DATATYPE_CHAR
>
> Certainl
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 n
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.eleme
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 t
Jonathan Scott Duff wrote:
To be on the safe side, method (and function) names *should* be quoted. I
don't think that this is inconsistent.
Is there a reason that you would want to conflate method names and
variables used as a method name? If not, why not change the syntax
slightly so that me
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
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
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
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 meth
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 a
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 sen
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 discuss
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 way
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.{ab
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
METHOD INTVAL get_allocated_size() {
return PMC_int_val2(SELF); /* or whatever */
}
great, exactly what I needed
thanks
karl
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, bu
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 i
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 metho
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 ob
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
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.
24 matches
Mail list logo