Perhaps someone with a bit more familiarity with the Parrot IO subsystem
could give me some guidance here. I'm currently trying to get a new
'peek' opcode working, and I'm having difficulties getting the io_unix
layer implemented correctly.
As far as I know, I'd get a call down into the io_unix
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> The attached t/pmc/signal.t should send a SIGINT to a sleeping or
LT> looping PASM test. This basically works, but the test output looks a
LT> bit ugly:
LT> t/pmc/signal# No tests run!
LT> t/pmc/signal
Will Coleda wrote:
Well, that was festive. "I can reproduce that bug in 22 lines!"
Great.
The bug (and other reported curruptions) are definitely coming from the
COW logic in register.c. This is what happens:
Setting up the exception handler (which is a continuation) triggers COW
setting of th
On Sun, 2004-01-25 at 02:19, Leopold Toetsch wrote:
> s. t/pmc/orderedhash.t The initializer of the struct could look like:
>
> new P1, .OrderedHash
> set P1["a"], .DATATYPE_a
> set P1[1], 0
> set P1[2], 0
> set P1["b"], .DATATYPE_b
> set P1[4], 0
> set P1[5], 0
> new P2, .UnManag
On Jan 27, 2004, at 7:29 AM, Leopold Toetsch wrote:
getinterp P5
dlfunc P0, Nul, "Parrot_UnManagedStruct_get_pointer", "pIP"
...
This is unlimited self-inspection and self-modification :) With little
additions (nested structs) one could read/write all Parrot_Interp
internals (inc
Well, that was festive. "I can reproduce that bug in 22 lines!"
I expect the following code to print out a single colon (since
PerlUndef prints as the empty string) and a newline. Instead, I get:
:get_string() not implemented in class 'RetContinuation'
which shows that the PerlUndef I assigned
Leopold Toetsch writes:
> This is unlimited self-inspection and self-modification :) With little
> additions (nested structs) one could read/write all Parrot_Interp
> internals (including possible security bits) and not only registers like
> above. But current state is already sufficient to seri
The Perl 6 Summarizer wrote:
The costs of sharing
Leo Töposted a test program and some results for timing the difference
between using shared and unshared PMCs. ... Hopefully the benchmark will
get checked into examples/benchmarks as suggested by Luke earlier.
Done now.
$ time perl58
Hi,
On Tue, Jan 27, 2004 at 12:49:25PM -0500, Uri Guttman wrote:
> > "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> LT> The attached t/pmc/signal.t should send a SIGINT to a sleeping or
> LT> looping PASM test. This basically works, but the test output looks a
> LT> bit ugly:
>
Uri Guttman wrote:
"LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> The attached t/pmc/signal.t should send a SIGINT to a sleeping or
LT> looping PASM test. This basically works, but the test output looks a
Test::* can't handle output from forked children (it traps redirect
STDOUT in t
On Tue, Jan 27, 2004 at 12:49:25PM -0500, Uri Guttman wrote:
> Test::* can't handle output from forked children
Yes, the problem is the child process can't inform the parent of how many
tests it ran. The simplest way around this problem is to have the
parent account for any tests run in the chil
Pardon me, I am trudging through all this thread backlog and
have been trying not to post to add to the bandwidth.
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
An existence proof:
Java Collections are a standard Java library of common data structures
such as arrays and hashes. Collections are
At 10:40 +0100 1/28/04, Leopold Toetsch wrote:
The Perl 6 Summarizer wrote:
The costs of sharing
Leo Töposted a test program and some results for timing the difference
between using shared and unshared PMCs. ... Hopefully the benchmark will
get checked into examples/benchmarks as sug
chromatic wrote:
On Sun, 2004-01-25 at 02:19, Leopold Toetsch wrote:
s. t/pmc/orderedhash.t The initializer of the struct could look like:
new P1, .OrderedHash
set P1["a"], .DATATYPE_a
set P1[1], 0
set P1[2], 0
set P1["b"], .DATATYPE_b
set P1[4], 0
set P1[5], 0
new P2, .UnManagedStruct,
On Thu, 15 Jan 2004 23:00:53 -0800, Jeff Clites wrote:
> I think we shouldn't try to do any sort of cross-language unification.
> That is, if we some day have a Parrot version of Java, and in Perl6 code I
> want to reference a global created inside of some Java class I've loaded
> in, it would be c
15 matches
Mail list logo
