Re: [perl #27904] [PATCH] stack items 2
Jonathan Worthington [EMAIL PROTECTED] wrote: Hi, This is a no-go for places where sizeof(INTVAL) is the same as sizeof(FLOATVAL). I know. It'll be replaced RSN. Jonathan leo
ops2c
I'm trying to write some documentation for the ops2c system at the moment and have a question. In Parrot::OpsFile::read_ops() a Parrot::Op's type is set to 'inline' or 'function', yet in Parrot::Op type is expected to be 'auto' or 'manual'. Auto ops have a 'goto NEXT()' appended to their code. In src/op.h there is a comment which notes that op type is unused. Can anyone summarize the history/future of this? Mike
Re: [perl #27904] [PATCH] stack items 2
Dan Sugalski [EMAIL PROTECTED] wrote: Right. That's why the stack frames have to be garbage collected--only the DOD knows when one's truly not used any more. Done (again). leo
Re: $PConfig{'i_pthread'}
Nick Kostirya [EMAIL PROTECTED] wrote:
Hello,
Tell me please where $PConfig{'i_pthread'} is defined?
It's missing in our config system. Wanted.
Nick.
leo
Re: Safety and security
[EMAIL PROTECTED] (Dan Sugalski) writes: At 5:48 PM -0500 3/23/04, Joe Schaefer wrote: [...] IMO, the advantage would be that parrot apps will have a better idea of what security model is appropriate. Well... maybe. Parrot apps don't get a whole lot of say here--this is more on the order of OS level security. Not that it makes a huge difference, of course. To be specific, I was thinking about embedded parrot apps like mod_perl, where it might be nice to enforce a security policy on a per-vhost (virtual server) basis. That isn't something all parrot apps would benefit from, of course. -- Joe Schaefer
Re: Load paths
Dan wrote: At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. Don't reinvent the wheel here. Obviously what should be return is an URI. If we start off only supporting file://... okay, but eventually we should support full over-the-net URI's (http:, https:, ftp:, etc.). -- Mark Biggar [EMAIL PROTECTED]
Re: Load paths
Larry Wall [EMAIL PROTECTED] writes: On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : just system(rm -rf /;halt) Sorry, that won't work correctly, since the rm will remove the halt program. Not necessarily. There's a chance it will remove 'rm' and 'rmdir' before 'halt'. (I tried it once, the famous rm -fr /, and was very disappointed how soon the process ended since it quickly removed rm and rmdir...) -- Johan
Re: Safety and security
[EMAIL PROTECTED] wrote: It can be safe. Normally, PCC works by certifying the code during compilation, and attaching the machine-checkable certificate with the resulting compiled code (be that bytecode, machine code or whatever). During runtime, a certificate checker then validates the certificate against the provided compiled code, to assure that what the certificate says it's true. Oh. In that case, the fact that it's proof carrying is just a particular case of signed code. I think that's a solved problem in parrot, at least from a design-of-bytecode perspective. It may have become unsolved recently, though. I thought proof-carrying code contained a proof, not a certificate. (The difference is that a proof is verifiably true -- that is, it's givens match reality, and each step is valid. OTOH, a certificate is something that we have to use judgment to decide of we want to trust or not.) The main requirement is that Parrot permits some sort of 'hooks', so that 1. during compilation, a certificate of proof can be generated and attached with the bytecode, and 2. before evaluation of the code, a certificate checker has to validate the certificate against the code, and also that 3. Parrot's bytecode format must allow such a certificate to be stored with the bytecode. I think we're done with step 3, but not 1 and 2. If you are directly eval'ing an arbitrary string, then yes, you have to generate the proof when you compile that string to PBC. But you can also provide a program/subroutine/etc as PBC with a certificate already attached. Note that in the common case, there are no eval STRINGs (at runtime), and thus all you have to do is prove that you don't eval STRING, which should be a much easier proposition. Back to reality. I understand that many of Parrot's features would be difficult to prove, but I'm not sure it's fundamentally any more difficult than most OO languages. AFAIK (although I don't know that much :), the Java VM has been proved secure to a large extent. I suspect most code that wants to be provable will attempt to prove that it does not use those features, rather then prove that it uses them safely. (As pointed out in a deleted bit of the grandparent post, this may consist of proving that it has a bit set in the header that says that it shouldn't be allowed to eval string, which is easy to prove, since it's a verifiable given.) -=- James Mastros
Re: $PConfig{'i_pthread'}
Tell me please where $PConfig{'i_pthread'} is defined?
It's missing in our config system. Wanted.
Oh, looks like I said it wrong.
I do have package Parrot::Config :-).
Please let me know at which moment $PConfig{'i_pthread'} value is set and
where in the code I can find it.
Use of grep gave me nothing.
Nick.
Nick.
leo
Re: Ulterior Reference Counting for DoD?
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 25/03/2004, at 9:01 PM, Leopold Toetsch wrote: All these generational collectors don't work with Parrot objects. We guarantee that objects don't move around. Oh, I didn't see a mention of this in a PDD. What's the reason for why you provide such a guarantee? Just curious. PMCs are passed on to (external) C code. When inmidst of C code the PMC moves around things break horribly--as they now break with the copying collector when you do: char *c = string-strstart; ... GC runs e.g. triggered by string_compare ... do something with c leo
Re: Safety and security
At 1:06 PM -0500 3/24/04, Joe Schaefer wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: At 5:48 PM -0500 3/23/04, Joe Schaefer wrote: [...] IMO, the advantage would be that parrot apps will have a better idea of what security model is appropriate. Well... maybe. Parrot apps don't get a whole lot of say here--this is more on the order of OS level security. Not that it makes a huge difference, of course. To be specific, I was thinking about embedded parrot apps like mod_perl, where it might be nice to enforce a security policy on a per-vhost (virtual server) basis. That isn't something all parrot apps would benefit from, of course. Ah, *that* is a different matter altogether. I'm planning an alternate mechanism for that, though it may be a bit much--rather than restricting the dangerous things we make sure all the dangerous things can be delegated to the embedder. So file manipulation, mass memory allocation/deallocation, and real low-level signal handling, for example, all get punted to the embedder, who can then do whatever they want. This means that when we go read some data from a file we call, say, Parrot_read, which for the base parrot'll be just read, while for an embedded parrot it may call some Apache thunking layer or something instead. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Exception bug?
Will Coleda [EMAIL PROTECTED] wrote: Ok. if I change that line, the program no longer infinite loops. However, argv is still trounced. Ah sorry, I did miss that in your first post. First, exceptions are really very experimental, especially when they resume. Anyway, the PerlArray (in P5) is destroyed by calling the exception handler. it has to be restored like so: .sub __default_handler P2 = P5[_invoke_cc] P5 = P5[_P5] invoke P2 .end You migh also use P4 instead of P2 or code will break, if you start using objects. There is still an issue with above handler - the sub entry code saves the return continuation into P16 - the handler is treated as a normal sub. Here is a better version: emit __default_handler: set P4, P5[_invoke_cc] set P5, P5[_P5] invoke P4 .eom leo
Re: $PConfig{'i_pthread'}
Nick Kostirya [EMAIL PROTECTED] wrote:
Tell me please where $PConfig{'i_pthread'} is defined?
It's missing in our config system. Wanted.
Oh, looks like I said it wrong.
I do have package Parrot::Config :-).
Please let me know at which moment $PConfig{'i_pthread'} value is set and
where in the code I can find it.
Use of grep gave me nothing.
Its not set and not used:
$ find lib -type f | xargs grep i_thr
$ find config -type f | xargs grep i_thr
You might have got an entry from your perl5, which is of no use for
Parrot.
There is no PConfig option that some threading library is available. We
need such a PConfig entry. E.g.:
PConfig{threadlib} = 'pthreads.linuxthreads'
PConfig{threadlib} = 'pthreads.NPTL'
PConfig{threadlib} = 'Win32'
or such
Nick.
leo
Re: $PConfig{'i_pthread'}
You might have got an entry from your perl5, which is of no use for
Parrot.
Thank you.
I see!
It's config/auto/headers.pl have
for (keys %Config) {
next unless /^i_/;
Configure::Data-set($mapping{$_}||$_, $Config{$_});
}
There is no PConfig option that some threading library is available. We
need such a PConfig entry. E.g.:
PConfig{threadlib} = 'pthreads.linuxthreads'
PConfig{threadlib} = 'pthreads.NPTL'
PConfig{threadlib} = 'Win32'
or such
Nick.
leo
Dependency cleanup in generated makefile
I've fixed up the dependency problem in the makefile generation that was getting in the way of multithreaded makes. Shouldn't cause any problems, but it never hurts to double-check these things elsewhere. Also, as I've been poking around in the make code, I'm finding myself less and less enamored of what's in there. There's far too much dependency information embedded in make syntax, and not nearly enough metainformation about what needs doing. This is going to make generalizing things and replacing make a pain, and it's definitely going to cause us problems as we have more and more platform-specific build tweaking that needs to be done. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safety and security
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more usefully) have hooks
in the compiler to catch and validate those bits of code before
running them. Doesn't do you much good to disallow
eval 'system rm -rf /';
at run time if you don't also catch
BEGIN { system rm -rf /; }
at compile time...
(Sorry if I'm just pointing out the obvious.)
Larry
Re: Safety and security
Larry Wall wrote in perl.perl6.internals :
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more usefully) have hooks
in the compiler to catch and validate those bits of code before
running them. Doesn't do you much good to disallow
eval 'system rm -rf /';
at run time if you don't also catch
BEGIN { system rm -rf /; }
at compile time...
That's mostly what Perl 5's Safe is doing. Hence my previous comment.
The major flaw with this approach is that it's probably not going to
prevent
eval 'while(1){}'
or
eval '$x = take this! x 1_000_000'
or my personal favourite, the always funny
eval 'CORE::dump()'
unless you set up a very restrictive set of allowed ops.
(in each case, you abuse system resources: CPU, memory or ability to
send a signal. I don't know how to put restrictions on all of these
in the general case...)
RE: Ulterior Reference Counting for DoD?
How do you make the copy/move of the object from one location in memory and the update of the pointer to the pointer ATOMIC? If you don't, it doesn't matter how many layers of indirection you have, it will still be a problem ;^) -Original Message- From: Piers Cawley [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 2:17 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Ulterior Reference Counting for DoD? Leopold Toetsch [EMAIL PROTECTED] writes: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 25/03/2004, at 9:01 PM, Leopold Toetsch wrote: All these generational collectors don't work with Parrot objects. We guarantee that objects don't move around. Oh, I didn't see a mention of this in a PDD. What's the reason for why you provide such a guarantee? Just curious. PMCs are passed on to (external) C code. When inmidst of C code the PMC moves around things break horribly--as they now break with the copying collector when you do: char *c = string-strstart; ... GC runs e.g. triggered by string_compare ... do something with c I know it's extra indirection, but maybe we should be passing pointers to pointers rather than plain pointers to C functions. It could be a win if that gets us faster GC... The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Safety and security
Rafael Garcia-Suarez wrote:
prevent
eval 'while(1){}'
or
eval '$x = take this! x 1_000_000'
Or hog both (for a small while):
eval 'while([EMAIL PROTECTED],0){}'
or my personal favourite, the always funny
eval 'CORE::dump()'
unless you set up a very restrictive set of allowed ops
(in each case, you abuse system resources: CPU, memory or ability to
send a signal. I don't know how to put restrictions on all of these
in the general case...)
Re: Ulterior Reference Counting for DoD?
Gerald Butler [EMAIL PROTECTED] wrote: [ message history rearranged - please don toppost - I hope that got the right levels of indentation ] From: Piers Cawley [mailto:[EMAIL PROTECTED] Leopold Toetsch [EMAIL PROTECTED] writes: PMCs are passed on to (external) C code. When inmidst of C code the PMC moves around things break horribly--as they now break with the copying collector when you do: I know it's extra indirection, but maybe we should be passing pointers to pointers rather than plain pointers to C functions. It could be a win if that gets us faster GC... That *if* is the problem. And it depends on the number of active and dead objects and possibly multiple other factors. Normally mark and sweep collection is faster, there is no overhead like write barriers, but you can of course construct benchmarks that reverse the result. You can construct benchmarks for everything :) And please note that all these GC papers (at least these what I have read) are focused on JVM, which is a stack machine. I don't know, if there is much difference, when it comes to GC, but anyway we don't have any numbers that indicate a generational (or incremental or refcounting or combined) scheme could be faster. Translating some of these JVM spec benchs to PIR could show some numbers but I didn't have a look at these programs and I don't know, how complex they are. How do you make the copy/move of the object from one location in memory and the update of the pointer to the pointer ATOMIC? If you don't, it doesn't matter how many layers of indirection you have, it will still be a problem This is only relevant for incremetal collectors running in the background. The double indirection could look like (AFAIK) pmc-pool_pointer-pmc_memory All code only sees the pmc pointer. During generational GC the pool_pointer and its memory is moved into an area where the pool of old generation isn't scanned for dead objects during each DOD run. The win is, that you are only going through the short lived objects pool mosts of the time. This would of course mean that each PMC operation has it's indirection penalty: pmc-pool_pointer-vtable-do_something(interp, pmc-pool_pointer-cache.int_val, ... Incremental and/or background collectors additionally have to track each object's pointer changes (e.g. a PMC reference now points to a different PMC, or all changes to aggregate members) This all imposes a considerable overhead, which isn't faster normally. leo [ and please hide that mess behind a signature if possible ] The information contained
[perl #27961] [PATCH] removes two compiler warnings in src/register.c
# New Ticket Created by Matt Fowles
# Please include the string: [perl #27961]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27961
All~
The subject says it all.
Matt
Index: src/register.c
===
RCS file: /cvs/public/parrot/src/register.c,v
retrieving revision 1.45
diff -u -r1.45 register.c
--- src/register.c 25 Mar 2004 09:23:01 - 1.45
+++ src/register.c 26 Mar 2004 03:42:04 -
@@ -117,7 +117,7 @@
{
UINTVAL j;
for ( ; ; chunk = chunk-prev) {
-struct PRegFrame *pf = STACK_DATAP(chunk);
+struct PRegFrame *pf = (struct PRegFrame *)STACK_DATAP(chunk);
pobject_lives(interpreter, (PObj*)chunk);
if (chunk == chunk-prev || chunk-free_p)
@@ -147,7 +147,7 @@
{
UINTVAL j;
for ( ; ; chunk = chunk-prev) {
-struct SRegFrame *sf = STACK_DATAP(chunk);
+struct SRegFrame *sf = (struct SRegFrame *)STACK_DATAP(chunk);
pobject_lives(interpreter, (PObj*)chunk);
if (chunk == chunk-prev || chunk-free_p)
[perl #27962] [PATCH] bad error message for split.
# New Ticket Created by Will Coleda # Please include the string: [perl #27962] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27962 Here's an untested patch to fix the split op's warning. Index: ops/string.ops === RCS file: /cvs/public/parrot/ops/string.ops,v retrieving revision 1.15 diff -r1.15 string.ops 690c690 internal_exception(1, Unimplemented join by regex); --- internal_exception(1, Unimplemented split by regex); -- Will Coke Coledawill at coleda dot com
Re: [perl #27962] [PATCH] bad error message for split.
Would a patch be accepted that let split work on non empty strings (not treated as REs) as a stopgap until RE support? On Thursday, March 25, 2004, at 10:51 PM, Will Coleda (via RT) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #27962] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27962 Here's an untested patch to fix the split op's warning. Index: ops/string.ops === RCS file: /cvs/public/parrot/ops/string.ops,v retrieving revision 1.15 diff -r1.15 string.ops 690c690 internal_exception(1, Unimplemented join by regex); --- internal_exception(1, Unimplemented split by regex); -- Will Coke Coledawill at coleda dot com -- Will Coke Coledawill at coleda dot com
parrot crash...
I knew I should have updated to cvs latest before issuing a tcl
release. =)
(go ahead and apply that patch, I'll get things fixed as soon as I can.)
If I run a very short tcl program, ala:
set a(b) whee
puts -
I get a crash in parrot, ala:
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0007
Thread 0 Crashed:
#0 0x0002d310 in pobject_lives (dod.c:179)
#1 0x001067ec in mark_pmc_register_stack (register.c:126)
#2 0x0010f294 in mark_context (sub.c:103)
#3 0x001a8c6c in Parrot_Continuation_mark (continuation.c:54)
#4 0x0002e38c in mark_special (dod.c:115)
#5 0x0002d358 in pobject_lives (dod.c:211)
#6 0x0002de74 in trace_mem_block (dod.c:889)
#7 0x001946f4 in trace_system_stack (cpu_dep.c:119)
#8 0x001946ac in trace_system_areas (cpu_dep.c:99)
#9 0x0002d578 in trace_active_PMCs (dod.c:300)
#10 0x0002e04c in Parrot_do_dod_run (dod.c:1028)
#11 0x0010aef0 in more_traceable_objects (smallobject.c:111)
#12 0x0010b028 in get_free_object (smallobject.c:177)
#13 0xef0c in get_free_pmc (headers.c:53)
#14 0x00029ca0 in get_new_pmc_header (pmc.c:104)
#15 0x00029fd0 in pmc_new_noinit (pmc.c:208)
#16 0x0003af64 in Parrot_newsub_p_ic_ic (core_ops.c:508)
#17 0x00111ddc in runops_slow_core (runops_cores.c:146)
#18 0xaa10 in runops_int (interpreter.c:838)
#19 0xaad8 in runops_ex (interpreter.c:865)
#20 0xad04 in runops (interpreter.c:941)
#21 0xea20 in Parrot_runcode (embed.c:693)
#22 0x378c in main (main.c:559)
#23 0x1d60 in _start (crt.c:267)
#24 0x1be0 in start
Thread 1:
#0 0x9003e9a8 in semaphore_wait_signal_trap
#1 0x9003e7c4 in _pthread_cond_wait
#2 0x0019a988 in queue_wait (tsq.c:319)
#3 0x00108c24 in event_thread (events.c:905)
#4 0x90020c28 in _pthread_body
Thread 2:
#0 0x9002568c in select
#1 0x001085a0 in io_thread (events.c:647)
#2 0x90020c28 in _pthread_body
The crash is fragile - doesn't happen if you change the puts to puts
{}, or delete the second line entirely.
I'll try to find a smaller test case.
--
Will Coke Coledawill at coleda
dot com
[perl #27969] [BUG] ParrotIO crash
# New Ticket Created by Will Coleda # Please include the string: [perl #27969] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27969 This rather dodgy bit of code .sub main $S0 = read $P1, 1 end .end Causes a crash, instead of raising an exception. Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x Thread 0 Crashed: #0 0x00024808 in PIO_read (io.c:911) #1 0x0004b188 in Parrot_read_s_p_ic (core_ops.c:369) #2 0x00111ddc in runops_slow_core (runops_cores.c:146) #3 0xaa10 in runops_int (interpreter.c:838) #4 0xaad8 in runops_ex (interpreter.c:865) #5 0xad04 in runops (interpreter.c:941) #6 0xea20 in Parrot_runcode (embed.c:693) #7 0x378c in main (main.c:559) #8 0x1d60 in _start (crt.c:267) #9 0x1be0 in start Thread 1: #0 0x9003e9a8 in semaphore_wait_signal_trap #1 0x9003e7c4 in _pthread_cond_wait #2 0x0019a988 in queue_wait (tsq.c:319) #3 0x00108c24 in event_thread (events.c:905) #4 0x90020c28 in _pthread_body Thread 2: #0 0x9002568c in select #1 0x001085a0 in io_thread (events.c:647) #2 0x90020c28 in _pthread_body -- Will Coke Coledawill at coleda dot com
Re: parrot crash...
Ah. this appears to be the same stack trace already noted by: Mitchell
N Charity
On Thursday, March 25, 2004, at 11:56 PM, Will Coleda wrote:
I knew I should have updated to cvs latest before issuing a tcl
release. =)
(go ahead and apply that patch, I'll get things fixed as soon as I
can.)
If I run a very short tcl program, ala:
set a(b) whee
puts -
I get a crash in parrot, ala:
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0007
Thread 0 Crashed:
#0 0x0002d310 in pobject_lives (dod.c:179)
#1 0x001067ec in mark_pmc_register_stack (register.c:126)
#2 0x0010f294 in mark_context (sub.c:103)
#3 0x001a8c6c in Parrot_Continuation_mark (continuation.c:54)
#4 0x0002e38c in mark_special (dod.c:115)
#5 0x0002d358 in pobject_lives (dod.c:211)
#6 0x0002de74 in trace_mem_block (dod.c:889)
#7 0x001946f4 in trace_system_stack (cpu_dep.c:119)
#8 0x001946ac in trace_system_areas (cpu_dep.c:99)
#9 0x0002d578 in trace_active_PMCs (dod.c:300)
#10 0x0002e04c in Parrot_do_dod_run (dod.c:1028)
#11 0x0010aef0 in more_traceable_objects (smallobject.c:111)
#12 0x0010b028 in get_free_object (smallobject.c:177)
#13 0xef0c in get_free_pmc (headers.c:53)
#14 0x00029ca0 in get_new_pmc_header (pmc.c:104)
#15 0x00029fd0 in pmc_new_noinit (pmc.c:208)
#16 0x0003af64 in Parrot_newsub_p_ic_ic (core_ops.c:508)
#17 0x00111ddc in runops_slow_core (runops_cores.c:146)
#18 0xaa10 in runops_int (interpreter.c:838)
#19 0xaad8 in runops_ex (interpreter.c:865)
#20 0xad04 in runops (interpreter.c:941)
#21 0xea20 in Parrot_runcode (embed.c:693)
#22 0x378c in main (main.c:559)
#23 0x1d60 in _start (crt.c:267)
#24 0x1be0 in start
Thread 1:
#0 0x9003e9a8 in semaphore_wait_signal_trap
#1 0x9003e7c4 in _pthread_cond_wait
#2 0x0019a988 in queue_wait (tsq.c:319)
#3 0x00108c24 in event_thread (events.c:905)
#4 0x90020c28 in _pthread_body
Thread 2:
#0 0x9002568c in select
#1 0x001085a0 in io_thread (events.c:647)
#2 0x90020c28 in _pthread_body
The crash is fragile - doesn't happen if you change the puts to puts
{}, or delete the second line entirely.
I'll try to find a smaller test case.
--
Will Coke Coledawill at coleda
dot com
--
Will Coke Coledawill at coleda
dot com
ParrotUnit
Here's version 0.01 of ParrotUnit, my port of the xUnit testing framework to Parrot. It allows you to write your tests for parrot applications using object oriented parrot. Untar it in your parrot directory then do $ parrot t/test.imc 1..3 ok 1 testTemplateMethod ok 2 testTestFailure ok 3 testTestCount and away you go. Right now you have to do a largish amount by hand because Parrot lacks the reflective capabilities needed to do automatic generation of TestSuites etc, and I've yet to come up with a good set of 'assert_*' methods, but what's there is usable (and splendidly undocumented). Enjoy. parrotunit-0.01.tar.gz Description: Binary data
Re: [perl #27961] [PATCH] removes two compiler warnings in src/register.c
Matt Fowles [EMAIL PROTECTED] wrote: The subject says it all. Matt Thanks, applied. leo
Re: [perl #27959] [PATCH] Tcl update
Will Coleda (via RT) wrote: One patch with changes: Doesn't apply: patching file languages/tcl/lib/commands/array.imc Reversed (or previously applied) patch detected! Assume -R? [n] $ grep ^Index tcl_20030325.patch | grep array Index: languages/tcl/lib/commands/array.imc Index: languages/tcl/lib/commands/array.imc leo
Re: parrot crash...
Will Coleda [EMAIL PROTECTED] wrote: I knew I should have updated to cvs latest before issuing a tcl release. =) ... and before sending bug reports ;) The hash/_dumper interaction bug vanished ... $ parrot hash-bug.imc 1000 | tail -3 998 = undef, 999 = undef } ... as very likely the bug below: #3 0x001a8c6c in Parrot_Continuation_mark (continuation.c:54) leo
