On Oct 24, 2005, at 0:07, Jonathan Worthington wrote:
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
op result_count(out INT)# TODO or some such
I'm guessing TODO means "it's not done yet"? But I was wondering,
would a more general solution not be to have an op that hands back the
On Oct 23, 2005, at 17:08, Nick Glencross (via RT) wrote:
Guys,
call_list.txt lists 'T' and 'L' as being prototypes for passing arrays
to nci functions, but no implementation exists in build_nativecall.pl.
This patch provides an implementation, as well as new tests.
I don't think that this i
On Oct 21, 2005, at 18:07, Will Coleda wrote:
There is now rudimentary support for converting parrot objects to JSON
strings.
+ # generate a JSON representation of a PMC.
+ $S0 = _json( $P0 )
$P0 = new .Array
$P0[0] = $P0
et al, yada yada, ...
Anyway. library/Data/Dumper.imc has the
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
On Oct 21, 2005, at 14:11, Roger Browne wrote:
From within a PIR sub or method, how can I detect how many return values
the caller is expecting?
I'm wondering how to implement a method that will return an error code
if its caller is prepared to rec
On Oct 22, 2005, at 10:28, Joshua Hoblitt (via RT) wrote:
All revs post r9519 are broken on amd64. r9519 builds OK.
This is an intermdiate step to more final code. I have more already in
the queue and will test it on the 'kua' machine too - greetings to
hawaii ;-) & thanks,
leo
On Oct 22, 2005, at 21:02, Bernhard Schmalhofer via RT wrote:
Using registers for passing command line options to a specific runcore
seem hazardous to me. Especially as a 'char *' is put where a 'STRING
*'
is expected.
Yep. This has always been a hack to pass the outfile along.
As Parrot_
# New Ticket Created by Nick Glencross
# Please include the string: [perl #37512]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37512 >
Guys,
call_list.txt lists 'T' and 'L' as being prototypes for passing arrays
to nci
On Oct 21, 2005, at 14:11, Roger Browne wrote:
From within a PIR sub or method, how can I detect how many return
values
the caller is expecting?
I'm wondering how to implement a method that will return an error code
if its caller is prepared to receive one, otherwise it will raise an
exceptio
