--- Piers Cawley <[EMAIL PROTECTED]> wrote:
> new P10, .PerlHash
> new P1, .PerlString
> set P1, "Bar"
> new P2, .Key
> set P2, P1
Oops! should be assign!
This is one of the reasons I think code like
$P0 = new PerlString
$P0 = "foo"
should be illegal. If people were forc
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'
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
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
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
> 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 ex
> 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.
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.
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
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 th
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
st
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 place...
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
13 matches
Mail list logo
