[PATCH] make PIO_fdopen return NULL on incorrect flags

This patch makes PIO_fdopen return NULL when you give it flags it doesn't understand. I gathered that this was the correct behavior from the test that I untodid. Luke Index: t/src/io.t === --- t/src/io.t (revision 7981) +++

runtime/parrot/library

Is there some reason that runtime/parrot/library isn't in the list of search paths for both include_paths and dynext_paths? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]

Re: object/method tailcalls ?

On Tue, May 03, 2005 at 04:26:52PM +0200, Leopold Toetsch wrote: Bob Rogers wrote: How about extending .return to cover these: .return foo(x, ...) # tail function call .return o.foo(x, ...) # tail method call Done - rev 7959. Excellent, thanks Leo. Does this

Re: object/method tailcalls ?

Patrick R. Michaud wrote: On Tue, May 03, 2005 at 04:26:52PM +0200, Leopold Toetsch wrote: Bob Rogers wrote: How about extending .return to cover these: .return foo(x, ...) # tail function call .return o.foo(x, ...) # tail method call Done - rev 7959. Excellent, thanks

Re: runtime/parrot/library

Jonathan Scott Duff [EMAIL PROTECTED] wrote: Is there some reason that runtime/parrot/library isn't in the list of search paths for both include_paths and dynext_paths? No. We have: load_bytecode = Parrot_load_bytecode *.pbc = PackFile_append.pbc = Parrot_readbc =

Re: [PATCH] make PIO_fdopen return NULL on incorrect flags

Luke Palmer [EMAIL PROTECTED] wrote: This patch makes PIO_fdopen return NULL when you give it flags it doesn't understand. I gathered that this was the correct behavior from the test that I untodid. Luke Thanks, applied. leo

Re: [PATCH] make PIO_fdopen return NULL on incorrect flags

Actually no, from the PIO routines you should return a PMC that has a null handle, or that was my original intent. I think I was considering changing new_io_pmc() to return something like ParrotUndef in that case but never did. The very first version of the IO routines actually did return NULL for

Re: Test::Builder change BAILOUT - BAIL_OUT

On 3 May 2005, at 23:36, Michael G Schwern wrote: Test::Simple/More/Builder 0.61 will introduce a change to Test::Builder whereby the BAILOUT() method becomes BAIL_OUT(). Additionally Test::More finally features a BAIL_OUT() function. [snip] Just out of curiosity - any particular reason for the

Re: embedding initialization

Jeff Horwitz wrote: i'm neck deep in writing the IMC eval code for pugs. ... ... but i imagine there's a more elegant solution out there. t/src/compiler.t has now all the steps to run a PIR code string from C. It's not elegant though, because there are no APIs, but it should make things running.

Re: embedding initialization

excellent! now i can get rid of that silly no-op bytecode i've been using. thanks for the quick turnaround, leo. -jeff On Thu, 5 May 2005, Leopold Toetsch wrote: Jeff Horwitz wrote: i'm neck deep in writing the IMC eval code for pugs. ... ... but i imagine there's a more elegant

Re: Test::Builder change BAILOUT - BAIL_OUT

On Thu, May 05, 2005 at 12:24:34PM +0100, Adrian Howard wrote: Test::Simple/More/Builder 0.61 will introduce a change to Test::Builder whereby the BAILOUT() method becomes BAIL_OUT(). Additionally Test::More finally features a BAIL_OUT() function. [snip] Just out of curiosity - any

Commitership inquiry

Hey. Leo suggested to me on #parrot to drop a note on p6i, asking about obtaining the committer to the Parrot tree. As some of you know, Pugs can now evaluate PIR via an embedded Parrot interpreter: $ ./pugs -e 'eval_parrotprint 42!\n' 42! as well as compiling Perl 6 to PIR, evaluating

Re: Commitership inquiry

Autrijus Tang wrote: Hey. Leo suggested to me on #parrot to drop a note on p6i, asking about obtaining the committer to the Parrot tree. $ ./pugs -BParrot -e 'say Autrijus should have commit privs' Autrijus should have commit privs leo

Re: should push (etc) be available via extend.h ?

On Tue, 2005-05-03 at 22:36 +0100, Nicholas Clark wrote: I don't know what the list of appropriate functions to wrap is. I assume that Leo/Chip can make a definitive criteria, but I'm guessing that it could be most vtable methods except for the MMD ones, given what Leo has already said.

Re: Favicon.ico for http://www.parrotcode.org

I noticed that the favicon.ico for http://www.parrotcode.org is a Camel. Can we have a Parrot for that, in order to do the many non-Perl Parrot based languages justice? Good idea. I've put one in place. If someone wants to make a nicer one, I won't kick and scream too much. -R