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
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
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
==
---
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
Aaron Sherman wrote:
I certainly hope not, as I agree with you! That's not the goal at all,
and in fact if that were a side effect, I would not want this to be
implemented. The idea of having types AT ALL for protos was something
that I threw in because it seemed to make sense at the end. The
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe that
declarative requirements should go on roles. And then packages could do
them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central
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
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()
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
HaloO,
Trey Harris wrote:
I would hate for Perl 6 to start using CAny or CWhatever in the
sort of ways that many languages abuse Object to get around the
restrictions of their type systems. I think that, as a rule, any
prototype encompassing all variants of a multi should not only
specify
Hi,
I have the following code:
class MyStupidString {
method repeatit(Str $string, Int $repeat) {
say $string xx $repeat;
my $add = $string xx $repeat;
say $add;
}
};
my $obj = MyStupidString.new;
$obj.repeatit(---,10);
Fagyal Csongor skribis 2006-09-28 15:11 (+0200):
say $string xx $repeat;
List context.
my $add = $string xx $repeat;
Item context, for a list repetition operator. Doesn't really make sense,
and I think a warning or error message would be more appropriate.
I
A. Pagaltzis wrote:
I have the following code:
class MyStupidString {
method repeatit(Str $string, Int $repeat) {
say $string xx $repeat;
my $add = $string xx $repeat;
say $add;
}
};
my $obj = MyStupidString.new;
TSa wrote:
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe
that declarative requirements should go on roles. And then packages
could do them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles
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
Aaron Sherman wrote:
TSa wrote:
Miroslav Silovic wrote:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bearer of type
information.
Type information is secondary to the proposal, but I'll run with what
you said.
This (the example, above)
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
Jonathan Lang wrote:
Aaron Sherman wrote:
TSa wrote:
Miroslav Silovic wrote:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bearer of type
information.
Type information is secondary to the proposal, but I'll run with what
you said.
This
Aaron Sherman wrote:
Jonathan Lang wrote:
Actually, it's a promise made by a package (not a class) to meet the
specification given by a role (which can, and in this case probably
does, reside in a separate file - quite likely one heavily laced with
POD).
That's a fine thing to want to do.
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
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
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
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
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
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
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
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}()
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, but
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
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
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
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.
Author: larry
Date: Thu Sep 28 18:53:32 2006
New Revision: 12485
Modified:
doc/trunk/design/syn/S03.pod
Log:
Extirpated machine-dependent definition of bit complement, noticed by audreyt++.
Modified: doc/trunk/design/syn/S03.pod
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
Actually, it's a promise made by a package (not a class) to meet the
specification given by a role (which can, and in this case probably
does, reside in a separate file - quite likely one heavily laced with
POD).
That's a fine
37 matches
Mail list logo
