On Thu, Oct 16, 2003 at 01:46:30AM +0100, Simon Cozens wrote:
[EMAIL PROTECTED] (Larry Wall) writes:
But for the time being I'm tied to an IV pole
We got rid of those; they're PMC poles now.
Get well soon,
Ditto!
Dave.
--
Little fly, thy summer's play my thoughtless hand has
Stefan Lidman [EMAIL PROTECTED] writes:
Shannon Francis [EMAIL PROTECTED] writes:
[...]
Oh dear.
Asking a mailing list to do your homework for you is bad
enough. Asking a mailing list that has recently been quiet enough to
elicit jokes about it in the summaries is, well, we'll have to see
On 16 October 2003 05:47 Robert Spier wrote:
Yes. We've been thinking about this. It either needs stealing buildd
from Debian, having a box we don't mind destroying every so often, or
having a VMware virtual machine we can undo easily. What we need is
more free time ;-)
User Mode Linux
On Thu, Oct 16, 2003 at 11:12:53AM -0700, chromatic wrote:
On Thu, 2003-10-16 at 10:46, Ovid wrote:
I was browsing through the Perl core tests and I saw that some tests in the t/uni/
directory used
Test::More, but most other tests would explicitly 'print ok 1\n'.
Is this to reduce
On Thu, Oct 16, 2003 at 09:37:52AM +0100, Piers Cawley wrote:
Stefan Lidman [EMAIL PROTECTED] writes:
Shannon Francis [EMAIL PROTECTED] writes:
[...]
Oh dear.
Asking a mailing list to do your homework for you is bad
enough. Asking a mailing list that has recently been quiet enough
Paul Johnson wrote:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00326.html
I did wonder why it never made the summary.
On the bright side, all of these recent discussion has finally given me
reason to setup a procmail filter to sort out this list.
I was browsing through the Perl core tests and I saw that some tests in the t/uni/
directory used
Test::More, but most other tests would explicitly 'print ok 1\n'.
Is this to reduce the dependancy of the core tests on external modules (and if so, why
does t/uni/
not follow the convention) or
On Thu, 2003-10-16 at 10:46, Ovid wrote:
I was browsing through the Perl core tests and I saw that some tests in the t/uni/
directory used
Test::More, but most other tests would explicitly 'print ok 1\n'.
Is this to reduce the dependancy of the core tests on external modules (and if so,
Chromatic wrote in perl.qa :
Stuff in t/op mostly can't use Test or Test::More because those modules
rely on the features being tested. Most everything else can use
Test::More. Barring any Unicode-related fiascos (of which I am proudly
and blissfully unaware), they probably haven't been
At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Folks,
I've added in the infrastructure needed to implement fixed opcode numbers.
There's now a file ops.num that holds the opcode name/number pairs for all
ops with a fixed number.
I don't know yet, what
On Thu, Oct 16, 2003 at 05:40:30PM +0200, Leopold Toetsch wrote:
As JIT code is unrolled, it IMHO can only call the function core (or CGP
again) for loaded opcodes.
As is this would mean that the JIT can't JIT any opcodes that are brought
in by dynamically loaded classes, it would be pain for
On Thu, 16 Oct 2003, Nicholas Clark wrote:
On Thu, Oct 16, 2003 at 05:40:30PM +0200, Leopold Toetsch wrote:
As JIT code is unrolled, it IMHO can only call the function core (or CGP
again) for loaded opcodes.
As is this would mean that the JIT can't JIT any opcodes that are brought
in by
Leopold Toetsch [EMAIL PROTECTED] writes:
JüRgen BöMmels [EMAIL PROTECTED] wrote:
There are still some things to do:
- a global hash is still not totally right. It should be moved to the
interpreter structure
As Dan already outlined, macros should have some limited scope, probably
On Wed, 15 Oct 2003, Jeff Clites wrote:
My brain was in PMC == class mode when I wrote what I wrote above, but
now I need to rethink, since that's not a given (yet?).
Not a given ever. PMCs may have a backing namespace, and that namespace
may be a HLL class, but it might not.
The terminology
Okay, it's pretty obvious I need to rethink things a bit for objects. (I'd
have responded to everyone in turn, but I lost power last night and the
mail came in this morning in odd order) I'll get back to everyone on this
later on today.
Dan
Juergen Boemmels [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
The IMCC_INFO does not need to be part of the interpreter.
I don't like to have global state variables around. I don't know yet,
what happens if 2 interpreter threads both do eval()...
It will be replaced by
On Thu, 16 Oct 2003, Leopold Toetsch wrote:
Juergen Boemmels [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
The IMCC_INFO does not need to be part of the interpreter.
I don't like to have global state variables around. I don't know yet,
what happens if 2 interpreter
At 10:21 AM 10/16/2003 -0400, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Leopold Toetsch wrote:
Juergen Boemmels [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
The IMCC_INFO does not need to be part of the interpreter.
I don't like to have global state variables around.
Now all run cores[2] are able to execute dynoplibs/test.pasm [1].
This is currently done for all cores except the function (slow) core by
running the wrapper__ opcode, which calls the real function in the
parrot function core.
Cores with an address table for function dispatch (CGoto, CGP) get a
Melvin Smith [EMAIL PROTECTED] wrote:
I don't like the idea of IMCC becoming so tightly coupled with the
interpreter. I still wish to be able to build it standalone. Hopefully
we can keep this in mind going forward.
IMCC_INFO is a macro, easily changable. But building it standalone would
need
Folks,
I've added in the infrastructure needed to implement fixed opcode numbers.
There's now a file ops.num that holds the opcode name/number pairs for all
ops with a fixed number. Right now it's only got two entries (one of which
really ought to be redone) but I'd like to get all the extant
On Oct 16, 2003, at 7:21 AM, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Leopold Toetsch wrote:
Juergen Boemmels [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
The IMCC_INFO does not need to be part of the interpreter.
I don't like to have global state variables around. I don't
What should this code print?
newclass P1, Foo
instantiate P2, P1
isa I0, P2, Foo
print I0
print \n
end
How about this?
newclass P1, Foo
instantiate P2, P1
isa I0, P2, ParrotObject
print I0
print \n
end
(NB Both will segfault without
From mmd.pod:
=item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
Like Cmmd_dispatch_string, only it returns a FLOATVAL.
Wouldn't it be more sensible to call the function mmd_dispatch_floatval ?
Simon
On Thu, 16 Oct 2003, Simon Glover wrote:
From mmd.pod:
=item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
Like Cmmd_dispatch_string, only it returns a FLOATVAL.
Wouldn't it be more sensible to call the function mmd_dispatch_floatval ?
Yep. The terminology's mixed
On Thu, 16 Oct 2003, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Simon Glover wrote:
From mmd.pod:
=item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
Like Cmmd_dispatch_string, only it returns a FLOATVAL.
Wouldn't it be more sensible to call the function
On Oct 16, 2003, at 2:40 PM, Simon Glover wrote:
On Thu, 16 Oct 2003, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Simon Glover wrote:
From mmd.pod:
=item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
Like Cmmd_dispatch_string, only it returns a FLOATVAL.
Wouldn't it be more
On Thu, 16 Oct 2003, Jeff Clites wrote:
On Oct 16, 2003, at 2:40 PM, Simon Glover wrote:
On Thu, 16 Oct 2003, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Simon Glover wrote:
From mmd.pod:
=item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
Like
Dan Sugalski [EMAIL PROTECTED] wrote:
Folks,
I've added in the infrastructure needed to implement fixed opcode numbers.
There's now a file ops.num that holds the opcode name/number pairs for all
ops with a fixed number.
I don't know yet, what are the goals of this patch. There is not any
Nicholas Clark [EMAIL PROTECTED] wrote:
On Thu, Oct 16, 2003 at 05:40:30PM +0200, Leopold Toetsch wrote:
As JIT code is unrolled, it IMHO can only call the function core (or CGP
again) for loaded opcodes.
As is this would mean that the JIT can't JIT any opcodes that are brought
in by
Can someone explain to me the lexical pad stack and static nesting
depth?
I'm trying to write global for tcl, and trying to pull out a variable
from the outermost pad, and failing to find it. - I'm fairly certain
this is because I'm abusing new_pad and store_lex (always using 0
as the static
The goals are to assign permanent numbers to the opcodes. What the
numbers are is generally irrelevant, but they must be constant across
all systems for the lifetime of parrot.
At first glance, gut reaction, that seems really hard(tm) and
really limiting(tm)...
since there's going to be a
32 matches
Mail list logo
