Re: [perl #33963] read and readline opcodes don't mix

2005-01-28 Thread Leopold Toetsch
Matt Diephouse [EMAIL PROTECTED] wrote: $S0 = readline $P0 print $S0 $S1 = read $P0, 3 Mixing readline and read isn't really a good idea. Did you try to turn on/off buffering before changing read modes? See PIO.setbuf(). leo

Re: [perl #33962] readline returns one too many lines

2005-01-28 Thread Leopold Toetsch
Matt Diephouse [EMAIL PROTECTED] wrote: The readline opcode returns too many lines. Compare the following pir with `wc -l`. unless file goto END $S0 = readline file It needs (currently) a test for an empty string: unless $S0 goto END I didn't look at the code, if EOF is set

Re: [perl #33963] read and readline opcodes don't mix

2005-01-28 Thread Matt Diephouse
On Fri, 28 Jan 2005 09:53:01 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Diephouse [EMAIL PROTECTED] wrote: $S0 = readline $P0 print $S0 $S1 = read $P0, 3 Mixing readline and read isn't really a good idea. Did you try to turn on/off buffering before changing read

Re: [perl #33962] readline returns one too many lines

2005-01-28 Thread Matt Diephouse
On Fri, 28 Jan 2005 09:49:06 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Diephouse [EMAIL PROTECTED] wrote: The readline opcode returns too many lines. Compare the following pir with `wc -l`. unless file goto END $S0 = readline file It needs (currently) a test

lib/Make.pm obsolete?

2005-01-28 Thread Matt Diephouse
Is there any reason to keep lib/Make.pm around? It was used by make.pl, but that was deleted more than a year ago. Grepping the parrot directory returns no occurrences of 'use Make;'. If it is deleted, #15988 (Make.pl might load the wrong Make.pm) can be closed. -- matt diephouse

Re: Calling conventions, invocations, and suchlike things

2005-01-28 Thread Dan Sugalski
At 5:04 PM -0500 1/18/05, Sam Ruby wrote: Dan Sugalski wrote: Hi folks. Welcome back! Parrot's got the interesting, and somewhat unfortunate, requirement of having to allow all subroutines behave as methods and all methods behave as subroutines. (This is a perl 5 thing, but we have to make it

Re: Calling conventions, invocations, and suchlike things

2005-01-28 Thread Sam Ruby
Dan Sugalski wrote: At 5:04 PM -0500 1/18/05, Sam Ruby wrote: Dan Sugalski wrote: Hi folks. Welcome back! Parrot's got the interesting, and somewhat unfortunate, requirement of having to allow all subroutines behave as methods and all methods behave as subroutines. (This is a perl 5 thing, but

Re: Calling conventions, invocations, and suchlike things

2005-01-28 Thread Sam Ruby
Luke Palmer wrote: Sam Ruby writes: Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like: $P0 = find_method Parrot_string, find # Elided check for failed lookup and fallback to attribute fetch $P1 =

Re: Calling conventions, invocations, and suchlike things

2005-01-28 Thread Luke Palmer
Sam Ruby writes: Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like: $P0 = find_method Parrot_string, find # Elided check for failed lookup and fallback to attribute fetch $P1 =

Re: Calling conventions, invocations, and suchlike things

2005-01-28 Thread Sam Ruby
Sam Ruby wrote: Now, what should the code for function f look like? The only reasonable answer is something along the lines of: getattribute $P0, P5, 'find' I doubt that. All languages have different semantics, and we can't implement them all, because they are conflicting. You, as a compiler