Melvin Smith <[EMAIL PROTECTED]> wrote:
> Another option is to use quotes for symbols with sigils,
And we have to cope with unicode finally. So I'd vote for that
alternative. *But* as code normally comes out of a compiler and there
may be many different compilers, we can't deal with arbitrary sym
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Hi,
> with a non-english locale I get a failure of test 11 in syn/file.t.
Thanks, applied. With an eval block around to silent perl, if no locale
is set:
warning: Setting locale failed.
perl: warning: Please check that your locale settings:
Jonathan Worthington writes:
> I would go with the idea of having a sigil that is placed before all local
> variables, and another (different!) sigil for registers (of the IMCC-handled
> type). Anything without one of those is a direct register access. Or a
> syntax error. Clean, simple rules.
On Wed, 11 Feb 2004 15:04:53 -0500, Matt Fowles
<[EMAIL PROTECTED]> wrote:
>All~
>
>I don't like the leading C<.> option, what about having a leading _ for
I don't care. Really, I don't care. I kinda like $, but I don't care.
I currently get by just with $[I.N.S.P]nnn symbolic temporaries
because
Hi,
> I don't like the leading C<.> option, what about having a leading _ for
> temporaries instead and allowing any non-space, non-operator character
> in symbol names, so _$foo would be a valid temp. This has the advantage
> of not conflicting with symbolic registers.
>
But could it potentially
All~
I don't like the leading C<.> option, what about having a leading _ for
temporaries instead and allowing any non-space, non-operator character
in symbol names, so _$foo would be a valid temp. This has the advantage
of not conflicting with symbolic registers.
The other option is to force
RFD = Request For Discussion ;)
Much discussion has been made on IRC concerning
symbol names.
The request, mainly, is for imcc to handle sigil characters
from other languages which basically equates to exposing
a lot to imcc from the high-level language. I won't
argue how much of that is good or b
Am Mittwoch, 11. Februar 2004 13:38 schrieb Jens Rieks:
> Here is the latest version of the _dumper() function.
> A test file is attached to my the next mail.
Here is it :-)
Again: I have no idea in what directory it should go.
> Changes:
> - PerlHash keys are now sorted
> (It makes it possible
Here is the latest version of the _dumper() function.
A test file is attached to my the next mail.
Changes:
- PerlHash keys are now sorted
(It makes it possible to write more simple tests.)
- no init method call is needed anymore
Just .include "library/dumper.imc" at the end of you program, and
Jens Rieks (via RT) wrote:
# New Ticket Created by Jens Rieks
# Please include the string: [perl #26547]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=26547 >
The output string is in english, but the expected one is in g
Am Mittwoch, 11. Februar 2004 13:11 schrieb Jens Rieks:
> Here is a PIR implementation of a simple _sort() function.
> A test is attached to my the next mail.
Here is "sort.t", where should it go?
jens
#! perl -w
use strict;
use Parrot::Test tests => 6;
output_is(<<'CODE', <<'OUT', "sorting
Here is a PIR implementation of a simple _sort() function.
A test is attached to my the next mail.
jens
=head1 TITLE
library/sort.imc - simple sort algorithm implemented in PIR
=head1 SYNOPSIS
...
_sort( array_pmc )
...
.include "library/sort.imc"
=head1 DESC
# New Ticket Created by Jens Rieks
# Please include the string: [perl #26547]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=26547 >
The output string is in english, but the expected one is in german.
This is the only fa
Chromatic <[EMAIL PROTECTED]> wrote:
> The recent Visual C++ warnings cleanup patch appears to have broken the
> compile on other platforms. Here's a patch that fixes things for me.
Oops, yes - hanks, applied.
leo
14 matches
Mail list logo
