Sean O'Rourke wrote:
> On Tue, 17 Sep 2002, Leopold Toetsch wrote:
>>Yes of course. What once was in "default.pmc" will be "scalar.pmc",
>>where all scalar like classes can inherit from.
> And from which perlarray.pmc, perlhash.pmc, and (probably) a whole host of
> other types that need scalar
# New Ticket Created by John Williams
# Please include the string: [perl #17397]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17397 >
The attached patch makes assignment hyper operators (^+= etc) work in the
perl6 compil
On 17 Sep 2002, Juergen Boemmels wrote:
> You do something like push_pad implicitly in the Sub class, but
> without a corresponding op in core.ops, when you invoke the Sub.
> You also get the current lexical scope implicitly at Sub creation
> time. This may be intentional so that the bytecode cant
On Tue, 17 Sep 2002, Leopold Toetsch wrote:
> ... and the default.pmc will catch any abuse of adding a "Sub" to an int
> and throw an exception.
Right. The current default.pmc non-error implementation of get_integer
(returning cache.int_val) is wrong, and should go away.
> > ... IMHO once a cla
Sean O'Rourke wrote:
> On Mon, 16 Sep 2002, Leopold Toetsch wrote:
>
>
>>Sean O'Rourke wrote:
>>...it should inherit from some basic_scalar.pmc, that
>>implements this for scalars. default.pmc is no more this default scalar
>>type, it's a "invalid.pmc".
>>Aggregates and Sub's and so on, don't
"Sean O'Rourke" <[EMAIL PROTECTED]> writes:
> > At the moment I try to use this to get functions working in Scheme. I
> > have something, that is somewhat working in gdb, but not ready yet.
>
> Maybe we need a "pad pumpkin" to avoid these kinds of race conditions.
My actual implementation is a
