On Thu, Nov 15, 2001 at 01:05:49PM -0500, Michael L Maraist wrote:
I know it's dangerous to compare hardware to a VM, but the required
equivalent would be to not tear down ANY scoping, and additionally, the
definition of a subroutine would have to preallocate ALL scopes before-hand.
I
-Original Message-
From: Jeff [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 15, 2001 10:53 PM
To: [EMAIL PROTECTED]
Subject: autoconf for parrot, but not quite what you think.
That will mainly involve changing markers in the source files that
currently look like '${foo}' to
As a last sort of alternative. I had invisioned PMC's has having separate
vtables for each of the many different types of operations. Meaning, that
a
scalar-int would be separate from a scalar-string-num, etc. Since it seems
that we're not currently doing this, it would require 8 times as
On Thu, Nov 15, 2001 at 08:18:32PM +, Simon Cozens wrote:
I'm under the impression that the signature of the add method should be
void foo (interpreter, destination, left, right)
Shouldn't the above be more like:
P1-vtable-vtable_funcs[VTABLE_ADD + P2-vtable-num_type](i,
To be honest, I'm a bit unhappy about all this:
runops_t0p0b1_core,
runops_t0p1b0_core,
runops_t0p1b1_core,
runops_t1p0b0_core,
runops_t1p0b1_core,
runops_t1p1b0_core,
runops_t1p1b1_core
My feeling is that you get a fast runops core for normal use and
a slow runops core which does
On Fri, Nov 16, 2001 at 03:32:06PM +0100, Paolo Molaro wrote:
And there is someone working on python
support in the mono compiler, too.
I know, I've just seen. Wouldn't it be really wonderful, Paolo, if
someone wrote some Perl bindings for it as well? :)
--
I did write and prove correct a
I sat down with Dan yesterday and finally got my head around his idea of
the multiple forms of some of the vtable methods. Unfortunately, this
kinda interrupts what I was doing implementing Perl scalar PMCs. :)
Anyway, instead of having an array of five different ways to add things
together,
On Fri, Nov 16, 2001 at 03:40:57PM +, Simon Cozens wrote:
Hurrah!
--
Jason
Simon --
To be honest, I'm a bit unhappy about all this:
runops_t0p0b1_core,
runops_t0p1b0_core,
runops_t0p1b1_core,
runops_t1p0b0_core,
runops_t1p0b1_core,
runops_t1p1b0_core,
runops_t1p1b1_core
I don't blame you. Its an interim solution with a bigger idea
behind it
On Fri, Nov 16, 2001 at 10:45:34AM -0500, Jason Gloudon wrote:
Hurrah!
Thank you! And for my next trick, implementing PMCs...
Oh, Dan sneaked in an interesting patch yesterday, which allows you
to create interpreters and run code in them on the fly. See
t/interp.t for an example.
--
Do not
From: Michael G Schwern [EMAIL PROTECTED]
On Thu, Nov 15, 2001 at 05:49:34PM -0800, John Rudd wrote:
That way you could choose to impliment Smalltalk or C++ style
protections (public, private, protected, etc)
Last I checked Smalltalk had no privacy protection.
So, for Smalltalk type
On Fri, Nov 16, 2001 at 07:26:37AM -0800, John Rudd wrote:
Smalltalk doesn't give you any privacy options, but it does dictate a
certain degree of privacy. Smalltalk is big on information hiding as
part of the whole OOP is an extension of Abstract Data Typing concept.
1) Methods are always
On Fri, 16 Nov 2001, Jason Gloudon wrote:
On Thu, Nov 15, 2001 at 01:05:49PM -0500, Michael L Maraist wrote:
I know it's dangerous to compare hardware to a VM, but the required
equivalent would be to not tear down ANY scoping, and additionally, the
definition of a subroutine would
On 11/16/01 Simon Cozens wrote:
On Fri, Nov 16, 2001 at 03:32:06PM +0100, Paolo Molaro wrote:
And there is someone working on python
support in the mono compiler, too.
I know, I've just seen. Wouldn't it be really wonderful, Paolo, if
someone wrote some Perl bindings for it as well? :)
Dan Sugalski writes:
: At 06:52 PM 11/15/2001 +, Simon Cozens wrote:
: I've hit upon quite a major problem with implementing
: Perl scalar PMCs. The problem is that the code is just
: too damned ugly for words.
:
: Remember that PMCs have a data area which is a void
: pointer; I'm connecting
On Thu, 15 Nov 2001, James Mastros wrote:
Hey all.
This implements a platforms system similar to what we were discussing
earlier: each interface is a sepperate file, independent of the others, the
hints file specifies what interfaces we use. This does create a large
number of files, but
On Thu, 15 Nov 2001, James Mastros wrote:
Hey all.
This implements a platforms system similar to what we were discussing
earlier: each interface is a sepperate file, independent of the others, the
hints file specifies what interfaces we use. This does create a large
number of files, but
On Fri, Nov 16, 2001 at 09:59:23AM -0800, Larry Wall wrote:
I think that as soon as the concept of a cache starts producing bit flags
and unions and cascaded if/then/elses, it's probably a bad concept.
It doesn't; once I've finished the reworking, then a PMC that has a
PerlInteger vtable will
Since we don't have any documentation on what the vtable methods are and
do, I can assume that nothing is fixed in stone. Hence, I'm unilaterally
declaring that -new, which used to be a constructor, is being renamed
-init, and is now an initializer. PMCs should be constructed through
the pmc_new
On Fri, Nov 16, 2001 at 09:49:45PM +, Simon Cozens wrote:
declaring that -new, which used to be a constructor, is being renamed
-init
Now watch with great amusement as Simon makes the object initializer,
Parrot_PerlInt_init, collide with the class initializer, Parrot_PerlInt_init!
Parrot
20 matches
Mail list logo
