Dan Sugalski <[EMAIL PROTECTED]> wrote:
> #2 is what you get with normal assignment. $foo = $bar, for example.
> $foo's assign vtable method is called with $bar as a parameter. $foo
> figures out what it should do--if it's a tied variable of some sort
> it should perform its assign action. (Thi
> my Complex $c = 3+4i;
> my $plain = 1.1;
> $plain = $c;
This might be even more "Complex" than that - what if Complex can be
reduced? Should it? for instance:
my Complex $c = 3+4i;
my Complex $d = 4i;
my $plain = $c / $d;
Does $plain get promoted, or does the result from the division get demo
Dan wrote:
>Yep, I've seen their plans. It's less an issue for us, at least as
>far as globals are concerned, since we'll be doing that with
>lexicals. (Python not having lexicals, after all) Globals are a bit
>more interesting, since bytecode-loaded modules can't guarantee
>global positions, sin
At 2:55 PM -0500 2/12/02, Clark C . Evans wrote:
>Abstract
>
> This proposal puts forth an extensible mechanism for the
> adaptation of an object to a context where a specific type, class,
> interface, or other protocol is expected.
I like the proposal, and I think it's dead-on in ide
At 10:48 AM + 2/13/02, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> #2 is what you get with normal assignment. $foo = $bar, for example.
>> $foo's assign vtable method is called with $bar as a parameter. $foo
>> figures out what it should do--if it's a tied variable of s
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >So in the following:
> >
> >my Complex $c = 3+4i;
> >my $plain = 1.1;
> >$plain = $c;
> >
> >I presume that $plain ends up as type Complex (with value 3+4i)?
>
> Yup.
>
> >If so, how does $plain know how to "morph itself into the RHS's type"?
>
> The g
At 7:16 AM -0800 2/13/02, Wizard wrote:
> > my Complex $c = 3+4i;
>> my $plain = 1.1;
>> $plain = $c;
>
>This might be even more "Complex" than that - what if Complex can be
>reduced? Should it? for instance:
>
>my Complex $c = 3+4i;
>my Complex $d = 4i;
>my $plain = $c / $d;
>
>Does $plain get
At 3:05 PM +0100 2/13/02, Angel Faus wrote:
>Dan wrote:
>>Yep, I've seen their plans. It's less an issue for us, at least as
>>far as globals are concerned, since we'll be doing that with
>>lexicals. (Python not having lexicals, after all) Globals are a bit
>>more interesting, since bytecode-loade
Dan Sugalski wrote:
> >my Complex $c = 3+4i;
> >my Complex $d = 4i;
> >my $plain = $c / $d;
> >
> >Does $plain get promoted, or does the result from the division
> get demoted?
>
> Since $plain's not a fixed scalar type, it should be whatever the
> division of $c and $d produces, presumably a comp
At 03:43 PM 02-13-2002 +, Dave Mitchell you wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > >So in the following:
> > >
> > >my Complex $c = 3+4i;
> > >my $plain = 1.1;
> > >$plain = $c;
> > >
> > >I presume that $plain ends up as type Complex (with value 3+4i)?
> >
> > Yup.
> >
> > >If so
At 11:12 AM -0500 2/13/02, Buddha Buck wrote:
>At 03:43 PM 02-13-2002 +, Dave Mitchell you wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> >So in the following:
>>> >
>>> >my Complex $c = 3+4i;
>>> >my $plain = 1.1;
>>> >$plain = $c;
>>> >
>>> >I presume that $plain ends up as type
At 3:43 PM + 2/13/02, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> >So in the following:
>> >
>> >my Complex $c = 3+4i;
>> >my $plain = 1.1;
>> >$plain = $c;
>> >
>> >I presume that $plain ends up as type Complex (with value 3+4i)?
>>
>> Yup.
>>
>> >If so, how does
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Simon Cozens) wrote:
> It's a pretty simple concept. We need to assign one PMC to another.
> We'll have to do it all the time:
>
> $a = $b;
>
> $a and $b are both PMCs, and we need to set the value of one to the
> value of the other, so le
> continue to pass. Also a shed load of comments.
Thats something we could definitely use more of.
-Melvin
The type changes in struct Packfile break the pointer math used in a few places
to calculate the address of the end of the loaded byte code. This causes
segfaults in build_asm in jit.c when using -j. It also breaks the bounds
checking on opcode address in runops_slow_core.
The patch adds the nece
At 10:43 PM -0500 2/13/02, Jason Gloudon wrote:
>The type changes in struct Packfile break the pointer math used in a
>few places
>to calculate the address of the end of the loaded byte code. This causes
>segfaults in build_asm in jit.c when using -j. It also breaks the bounds
>checking on opcode
16 matches
Mail list logo
