Deborah Ariel Pickett wrote:
While I like the glib "Arrays are variables that hold lists" explanation
that worked so well in Perl5, I think that Perl6 is introducing some
changes to this that make this less true.
Like what?
Well, like the builtin switch statement, which was what I wa
> From: Deborah Ariel Pickett <[EMAIL PROTECTED]>
> Date: Tue, 11 Feb 2003 11:15:13 +1100 (EST)
>
> In Perl6, where there seems to be even more of a blur between
> compile-time and runtime, I don't think it's always going to be possible
> (i.e., easy) to know where naming an array or providing an
> >While I like the glib "Arrays are variables that hold lists" explanation
> >that worked so well in Perl5, I think that Perl6 is introducing some
> >changes to this that make this less true.
> Like what?
Well, like the builtin switch statement, which was what I was trying to
show in my bad examp
Dunno where this 'from' line came from, but it says here:
[EMAIL PROTECTED] wrote:
:On Sun, Jan 12, 2003 at 10:24:23AM +0100, Leopold Toetsch wrote:
:all default to a machine dependent default. This default isn't documented
:explicitly, but I presume that on x86 it's the same as the x86 specific -m
On Sun, Jan 12, 2003 at 10:24:23AM +0100, Leopold Toetsch wrote:
> In perl.perl6.internals, you wrote:
> > --- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> >> * SLOW (same slow with register or odd aligned)
> >> * 0x818118a :sub0x8164cac,%ebx
> >> * 0x8181190 :jne0x818118a
>
Hi all.
The new CGP code causes compilation of interpreter.c to fail if
HAVE_COMPUTED_GOTO is undefined. This is because it references
Parrot_DynOp_core_cgp_0_0_9, which is defined in core_ops_cgp.h,
and the latter is only included when HAVE_COMPUTED_GOTO is defined. This
bug appears to be
>>Just to confuse things more, there is a question I have reguarding
>> multi-methods and inheritance.
>>
>>Consider class A defines foo() as a multi-method with 3 different
>> signatures
>>
>>If class B then sub-classes A and defines a method foo() does it
>>
>>1 override all foo() methods in A
>>
Jonathan Sillito <[EMAIL PROTECTED]> wrote:
> > From: Kevin Reid [mailto:[EMAIL PROTECTED]]
> >I've implemented what appears to be appropriate usage based on
> > examination of t/pmc/sub.t and core_ops.pod, but it is not exhibiting
> > proper closure behavior - all subs share the same state.
>
What is the recommended mechanism for reading data from stdin for a PASM application.
The readline operation is considered a hack and I would rather implement the correct
mechanism for reading data into stdin than use such a reviled operation. Thanks.
-bc
_
> -Original Message-
> From: Kevin Reid [mailto:[EMAIL PROTECTED]]
>
> 0. PDD 3 says:
>
> P1
>Holds the continuation for the caller, assuming this sub was
> called with callcc. Otherwise NULL.
>
>and implies a similar possible absence for P2. How does one ensure
> that
That makes sense. I'll patch the documentation to replace the inc examples with add
instructions.
Thanks Leo!
-bc
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (via RT) wrote:
>
>> I was not able to find the increment by NN operation implemented and did it.
>
>
>The 2 ope
Uri Guttman wrote:
>
> arrays are allocated and lists are on the stack. so arrays
> can have references to them but lists can't.
Apoc 2, RFC 175:
>
> scalar(list(1,2,3));
[...]
> scalar(array(1,2,3));
Which would imply one could take a reference to either.
> can anyone see any changes in p
Starting from here:
imcc -P mops.pbc 87 MOps
parrot -P mops.pbc 92 MOps
I tracked this down to an alignment issue of the prederefed code pointer.
So here is a memalign test. It needs possibly more work for other C
librarys, which have a different name for this function.
$ imcc -P mops.pas
[EMAIL PROTECTED] (via RT) wrote:
I was not able to find the increment by NN operation implemented and did it.
The 2 operand form of add does the same:
inline op add(inout INT, in INT) {
$1 += $2;
goto NEXT();
}
Thanks,
-bc
leo
14 matches
Mail list logo
