[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)
+++ t/src/io.t (working copy)
@@ -585,8 +585,6 @@
###
-SKIP: {
-skip (fdopen does not handle illegal modes correct, 1);
c_output_is($main . 'CODE', 'OUTPUT', PIO_fdopen);
static opcode_t*
the_test(Interp *interpreter,
@@ -620,7 +618,6 @@
CODE
done
OUTPUT
-}
###
Index: io/io.c
===
--- io/io.c (revision 7981)
+++ io/io.c (working copy)
@@ -730,6 +730,8 @@
}
flags = PIO_parse_open_flags(sflags);
+if (!flags) return NULL;
+
io = PIO_fdopen_down(interpreter, layer, fd, flags);
/* io could be null here but we still have to
* to create a PMC for the caller, no PMCNULL here
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 mean we can retire RT ticket #31681 ? Also, I tried to close ticket # 35052 ( PGE doesn't link ), but apparently I lack sufficient knowledge or magic bits to accomplish that. Any help on this would be appreciated. Pm
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 Leo. Does this mean we can retire RT ticket #31681 ? Yep. I've set it to resolved. Also, I tried to close ticket # 35052 ( PGE doesn't link ), but apparently I lack sufficient knowledge or magic bits to accomplish that. Any help on this would be appreciated. There used to be a closed status. Dunno. Pm leo
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 = Parrot_locate_runtime_file( ... PARROT_RUNTIME_FT_PBC) else = IMCC_compile_file = imcc_compile_file = Parrot_locate_runtime_file( ... PARROT_RUNTIME_FT_SOURCE) In Parrot_locate_runtime_file() there is no special case for these file types, they go along with the include paths, which isn't quite right. Therefore we'd need another default search path for these two file kinds. Takers wanted. -Scott leo
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 every error, but it was decided that wasn't the cleanest way. If you look at the revision history of io.c, revision 4673, I commented: Bug fixes. We should not be returning NULL for io PMCs, that generates an exception now.. A PMC should be returned with a NULL ParrotIO * for valid eof/bool tests. As this was 2003, I honestly don't remember all of the discussion. There might be a record of it between Dan and me in the archives, however, chances are it was on IRC. -Melvin At 07:44 AM 5/5/2005, Leopold Toetsch wrote: 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: 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 change? Adrian
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. -jeff leo
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 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. -jeff leo
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 particular reason for the change? Everything else in Test::Builder is this_style not thisstyle. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
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 it in memory:
$ ./pugs -BParrot -e 'say The answer is: { 7 * 6 }'
The answer is: 42
In light of this, I'd like to commit to Parrot tree, helping
on cleaning up the embedding API, the installation process
(e.g. to get the neccessary headers in place), etc.
Thanks!
/Autrijus/
pgp15KvlTv36Y.pgp
Description: PGP signature
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.
Seems reasonable to me. I have a short program now based on
Parrot::Vtable that dumps out really naive functions.
void init_pmc(PMC* initializer)
becomes:
void Parrot_PMC_init_pmc( Parrot_INTERP interp, Parrot_PMC pmc,
Parrot_PMC initializer )
{
void retval;
PARROT_CALLIN_START( interp );
retval = VTABLE_init_pmc( interp, pmc, initializer );
PARROT_CALLIN_END( interp );
return retval;
}
I'll make it keep the other functions in extend.c and see what happens.
Should we be regularising the C wrappers to have the same names as the
vtable entries?
Seems reasonable to me.
ie s/Parrot_PMC_get_intval_intkey/Parrot_PMC_get_integer_keyed_int/
and similarly for quite a few other functions in extend.c?
I can make a patch that does this if it's valuable.
-- c
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
