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 scalar?
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 other
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;
$foo =
Dan Sugalski
[EMAIL
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
object
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 reason to suspect
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 assigned
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
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 subject.
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
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 like
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
13 matches
Mail list logo
