Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Right, for typed variables. Most variables (i.e. anything you
> declared with a plain "my $foo" or "our @bar") are untyped and can
> change their types as needed.
>
> If you did:
>
> my $foo;
> $foo = Dog.new();
> $foo = FireHydrant.new();
On Thu, 14 Feb 2002, Dave Mitchell wrote:
> > $foo would first be a Dog, then a FireHydrant. When it changed to a
> > FireHydrant the previous contents would get blown away.
>
> Hmmm - how do we distinguish between a plain scalar that is temporarily
> typed, and a 'proper' permanently-typed scala
Alex Gough <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Feb 2002, Dave Mitchell wrote:
> > > $foo would first be a Dog, then a FireHydrant. When it changed to a
> > > FireHydrant the previous contents would get blown away.
> >
> > Hmmm - how do we distinguish between a plain scalar that is temporarily
On Thu, Feb 14, 2002 at 02:10:20PM +, Dave Mitchell wrote:
> 2. If so, how do we distinguish between two PMCs, both of whose
> vtable pointers currently point to the 'Dog' vtable, but one of whom has
> been delared as type Dog and so should never have it's vatble pointer
> updated, and the oth
At 11:46 AM + 2/14/02, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> Right, for typed variables. Most variables (i.e. anything you
>> declared with a plain "my $foo" or "our @bar") are untyped and can
>> change their types as needed.
>>
>> If you did:
>>
>> my $foo;
Dan Sugalski
<[EMAIL PROTECTE
On Thu, 14 Feb 2002, Melvin Smith wrote:
> >my Dog $spot = Dog.new("waggly tail");
> >$spot = Cat.new();
>
> In this case all types are known at compile time. Why would
> we relegate this to a runtime vtable check or bit flag?
There's no reason to suspect that Dog::new will actually return a Dog
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> There's a flag in the flags field to mark the PMC as a permanent type
> or not. It's insufficient for "Type X or child of X" things, though.
>
> >Or to put it another way, is the type of a PMC determined purely by
> >it's current vtable pointer, and if s
At 3:48 PM + 2/14/02, Alex Gough wrote:
>On Thu, 14 Feb 2002, Melvin Smith wrote:
>
>> >my Dog $spot = Dog.new("waggly tail");
>> >$spot = Cat.new();
>>
>> In this case all types are known at compile time. Why would
>> we relegate this to a runtime vtable check or bit flag?
>
>There's no r
Alex Gough
At 3:53 PM + 2/14/02, Dave Mitchell wrote:
>My outstanding niggle is when a typed variable is undef. I guess we
>need a generic Perl_Undef_But_Typed vtable type, which behaves mostly
>like the PerlUndef type, but saves a pointer to its 'real' vtable in
>self->data or whatever. When it's assign
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 3:53 PM + 2/14/02, Dave Mitchell wrote:
> >My outstanding niggle is when a typed variable is undef. I guess we
> >need a generic Perl_Undef_But_Typed vtable type, which behaves mostly
> >like the PerlUndef type, but saves a pointer to its 'real' vta
On Wed, Feb 13, 2002 at 10:43:38PM -0500, 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
> c
The "librep" virtual machine uses a technique taken from Forth
engines called "indirect threading". That's not threading as in
"multithreading" or "pthreads"... You'll have to read about it for
yourselves, since I've not the knowledge, time, or the inclination to
write a long essay on the s
Is this annoying, or helpful? This is one thing that turned up in a
google search for "librep forth engine".
http://www.technomagi.com/links/design.html>
--
mailto: (Karl M. Hegbloom) [EMAIL PROTECTED]
Free the Software http://www.debian.org/social_contract
http://www.microsharp.com
ph
Okay, I've checked in the final bits needed to do memory allocations
and such within Parrot. Here's the scoop.
For memory you need to allocate from the system, use
mem_sys_allocate. Takes a size, returns a void pointer to the
allocated memory. Free it up with mem_sys_free, or it leaks. To
res
If you choose to accept it, is to dig out the computed goto and
switch runops cores from the archives, dust 'em off and get them up
to snuff with the current sources.
Takers, anone?
--
Dan
--"it's like this"-
At 12:21 AM -0500 2/13/02, Josh Wilmes wrote:
>I've tweaked the "lint" target somewhat and fixed a few of the things it
>finds. Attaching the patch as well as the current lint output.
Applied, thanks.
--
Dan
--"it's l
This gets it very close to building on tcc, with just key.c causing
problems due to some KEY_PAIR* / KEY_PAIR** mixups. My brain can't quite
wrap around what's going on there :)
This patch fixes a few places where duplicate variable names and invalid
return values were occurring in the pmc's
This patch removes unnecessary function pointer conversions (which have
undefined behavior in ANSI C). This gets rid of several warnings encountered
with the lcc compiler and isolates our function pointer misbehavior to
only the jit code.
--Josh
Index: core.ops
=
20 matches
Mail list logo
