Re: parrot crash...

I'm still seeing both bugs, with a cvs update, make realclean; perl Configure.pl, make. (if I do a cvs diff in my repo, the only changed files are tcl related.) What other intel do you need to help duplicate the bugs? FWIW, I do see that Mitchell's program is not segfaulting, so while my "shor

Re: [perl #27962] [PATCH] bad error message for split.

Will Coleda <[EMAIL PROTECTED]> wrote: > Here's an untested patch to fix the split op's warning. Thanks, applied. 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 li

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

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

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 testTestFail

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.)

[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. # 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 cr

[perl #27966] [BUG] PerlHash/_dumper interaction

# New Ticket Created by Will Coleda # Please include the string: [perl #27966] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27966 > .sub main .param pmc argv $S0 = argv[1] $I2 = $S0 $P2 = new PerlHash

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_P

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

[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. # 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 ===

[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. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27961 > All~ The subject says it all. Matt Index: src/register.c ===

[perl #27959] [PATCH] Tcl update

# New Ticket Created by Will Coleda # Please include the string: [perl #27959] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27959 > With the thought that anything more frequent than "every six months" is good, here's

Re: Ulterior Reference Counting for DoD?

"Butler, Gerald" <[EMAIL PROTECTED]> writes: > 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 ;^) You only d

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 inmids

Re: Safety and security

At 11:35 PM +0200 3/25/04, Jarkko Hietaniemi wrote: 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){}' Which, if the interpreter's running with quotas, will be caught wh

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

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 PROT

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 C, > C, and other macro definitions, or (more usefully

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 o

MMD vtable functions in bytecode

So, I'm doing these, because I need 'em, and we might as well get the things in now. For the record, these things will be called as functions (not methods), with three parameters, so the signature looks like: .pcc_sub thingie prototyped .param pmc left .param pmc right .param

Re: [PATCH] single item stack chunks

Dan Sugalski <[EMAIL PROTECTED]> wrote: > 2) The stack entry has to look something like: > struct { > struct IntStackFrame *prev; > INTVAL Registers[REGSPERFRAME]; > } IntStackFrame; Ok, now we "something like" that: typedef struct Stack_Chunk { pobj_t obj; int

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 C, C, and other macro definitions, or (more usefully) have hooks in the compiler to catch and validate

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 enamor

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 threadi

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 a

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

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 who

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 pro

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 g

Re: Exception bug?

Ok. if I change that line, the program no longer infinite loops. However, argv is still trounced. On Thursday, March 25, 2004, at 02:59 AM, Leopold Toetsch wrote: Will Coleda <[EMAIL PROTECTED]> wrote: Is there a bug in my code? Yes. invokecc P2 Your are destroying the callers return conti

Re: Ulterior Reference Counting for DoD?

On 25/03/2004, at 9:01 PM, Leopold Toetsch wrote: [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi guys, Two-line summary: * gives as good performance as the best generational garbage collectors today, with All these gen

Re: Ulterior Reference Counting for DoD?

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi guys, > > Two-line summary: > * gives as good performance as the best generational garbage > collectors today, with All these generational collectors don't work with Par

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 certif

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

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://...

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

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: [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

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.

$PConfig{'i_pthread'}

Hello, Tell me please where $PConfig{'i_pthread'} is defined? I want use this paramet into t/pmc/threads.t for detect that parrot has being built with thread on NetBSD. Nick.

Re: Load paths

On Thu 25 Mar 2004 07:42, Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote: > Larry Wall wrote: > > > On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: > > : I'd like to propose the following optimisation: > > : if an attempt is made to load anything over the network > > : (without cry

Re: Exception bug?

Will Coleda <[EMAIL PROTECTED]> wrote: > Is there a bug in my code? Yes. >invokecc P2 Your are destroying the callers return continuation here. invoke P2 does it. leo

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