Leopold Toetsch [EMAIL PROTECTED] writes:
Togos [EMAIL PROTECTED] wrote:
Should aggregate PMCs (like PerlHash) be able to take
PMCs as keys? I mean so that:
$P0 = $P1[$P2]
Just use a Key PMC for $P2.
$P2 = new Key
$P2 = key_string
...
So, just for fun I added the following
Piers Cawley [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
Just use a Key PMC for $P2.
So, just for fun I added the following test to t/pmc/perlhash.t:
new P10, .PerlHash
new P1, .PerlString
set P1, Bar
new P2, .Key
set P2, P1
^^^
Cset Px,
After a long hiatus, I decided to try to compile parrot on Solaris 8,
using the Sun-supplied tools. Alas, I met with failure no matter
which way I turned. Here's the summary of what I found:
1. Configure.pl issues some uninitialized warnings:
Moving platform files into
At 10:23 AM +0200 5/28/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
If you want to go back to a frame pointer style of register stack
access, that's doable, but that's the way it was in the beginning and
the performance penalties in normal code outweighed the savings in
At 9:50 AM +0200 6/3/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 9:51 AM +0200 6/2/04, Leopold Toetsch wrote:
- don't load extensions at compile time, so that dynamic PMCs have to be
created with
$I0 = find_type Foo
$P0 = new $I0
Option two here would be the
At 12:54 AM -0400 6/3/04, Benjamin K. Stuhl wrote:
(with one major caveat: if the _vtable_ functions try to use the
PMC's address as an index into some data structure, things will go
wrong since the PMC the base vtable functions get no longer has the
same address as the logical PMC; if external
All~
Perhaps I am missing something in this discussion, but wouldn't it be
possible to have the vtable within a PMC be layered rather than the PMC
itself. This would allow the data portion of PMC's to remain in a fixed
location, while allowing new vtable layers to be
All~
Perhaps I am missing something in this discussion, but wouldn't it be
possible to have the vtable within a PMC be layered rather than the PMC
itself. This would allow the data portion of PMC's to remain in a fixed
location, while allowing new vtable layers to be pushed/popped. If
At 12:54 AM -0400 6/3/04, Benjamin K. Stuhl wrote:
(with one major caveat: if the _vtable_ functions try to use the
PMC's address as an index into some data structure, things will go
wrong since the PMC the base vtable functions get no longer has the
same address as the logical PMC; if external
Dan Sugalski [EMAIL PROTECTED] wrote:
Why don't we wait a bit? I should be done with the second draft of
the events/IO spec today, and we can go from there.
return ETOOMANYOPENENDSANDPENDINGSPECS; /* :) */
leo
Dan Sugalski [EMAIL PROTECTED] wrote:
... Threads or not, the single-threaded case is going to
be the common case for parrot, and it's mildly faster in general.
That and the overhead to just test the scheme (in the absence of RL code)
are really good arguments to keep the status quo :)
leo
At 3:01 PM -0400 6/4/04, Matt Fowles wrote:
All~
Perhaps I am missing something in this discussion, but wouldn't it
be possible to have the vtable within a PMC be layered rather than
the PMC itself.
There are two problems with that (though I did think about it for a while):
1) It means that each
At 11:00 PM +0200 6/4/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Why don't we wait a bit? I should be done with the second draft of
the events/IO spec today, and we can go from there.
return ETOOMANYOPENENDSANDPENDINGSPECS; /* :) */
Way, *way* too many... :)
Sorry, work's
I started using Test::Inline, and I have two related comments. (I hope
this is the right place to bring them up.)
1. I don't think that pod2test should do anything more than the minimum
to construct a valid test script. Anything else that is useful
should be part of the standard Test::
14 matches
Mail list logo
