On Mar 4, 2006, at 18:05, Nicolas Cannasse wrote:
-Cj does not produce different results than -j on the Win32 build of
Parrot. Is -Cj supported on this architecture ?
Yes, it should work. It might depend on, how fib is actually written in
PIR. As said this option is in a rather early state.
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Mmm - actually -C needs computed goto, which isn't supported by all C
compilers.
Including the one that I produce the Win32 builds that I believe were being
tested with (MS Visual C++). Shouldn't it give a "we don't have a computed
goto runcore" err
On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote:
> How do you verify that a print succeeded? Currently there's no way to
> know. Throwing an exception if a global flag is set would suffice and
I assumed that the lack of documentation of any return code meant that it
would return as
On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote:
> I don't think it's really been addressed, at least not recently, but
> what about IPv6? By the time perl6 becomes commonplace and used
> often(and thus, parrot), IPv6 will be common enough that problems could
> occur. Currently it
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
> What I need from you all is comments. What's missing? What's
> inaccurate? What's accurate for the current state of Parrot, but is
> something you always intended to write out later? What thoughts have
> you had on how the I/O
On Sun, Mar 05, 2006 at 18:34:26 +, Nicholas Clark wrote:
> On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote:
>
> > I don't think it's really been addressed, at least not recently, but
> > what about IPv6? By the time perl6 becomes commonplace and used
> > often(and thus, parrot)
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
=item *
C retrieves a single line from a stream into a string. Calling
C flags the stream as operating in line-buffer mode (see
C below). Lines are truncated at 64K.
Is there a fundamental need for a hard hard limit?
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
[It's worth considering making all the network I/O opcodes use a
consistent way of marking errors. At the moment, all return an integer
status code except for C, C, and C.]
IIRC the Linux kernel uses negative values as return c
On Mar 5, 2006, at 18:33, Jonathan Worthington wrote:
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Mmm - actually -C needs computed goto, which isn't supported by all C
compilers.
Including the one that I produce the Win32 builds that I believe were
being tested with (MS Visual C++). Shouldn
On Mar 5, 2006, at 20:11, Nicholas Clark wrote:
C flags the stream as operating in line-buffer mode (see
C below). Lines are truncated at 64K.
Is there a fundamental need for a hard hard limit?
There used to be a hard limit until about a year ago. This is of course
gone now.
leo
On Mar 5, 2006, at 1:46 PM, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
Should the network opcodes even be loaded as standard? C et al
aren't
actually that useful on Perl 5 without all the constants in the Socket
module,
so in practical terms a redes
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote:
>
> On Mar 5, 2006, at 1:46 PM, Nicholas Clark wrote:
>
> >On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
> >
> >Should the network opcodes even be loaded as standard? C et al
> >aren't
> >actually that useful on Perl
On Mar 5, 2006, at 3:46 PM, Nicholas Clark wrote:
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote:
A pasm include, such as the signal.pasm(even though signals don't work
yet), would suffice and is generated at compile time. Parsing .h
files
This way does the numeric values of
On Sunday 05 March 2006 11:46, Nicholas Clark wrote:
> On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
> [It's worth considering making all the network I/O opcodes use a
> consistent way of marking errors. At the moment, all return an integer
> status code except for C, C, a
Hi all,
A Segmentation fault occurs in the languages/lua/t/tables_3.pir.
This test is a simple table creation (with 1000 items) :
a = {}
for i=1,1000 do a[i] = i*2 end
print(a[9])
This problem started with revision 11586.
In the previous Lua PMC implementation (r11478),
15 matches
Mail list logo
