On Friday 14 March 2008 16:11:54 [EMAIL PROTECTED] wrote:
> Modified:
>trunk/src/embed.c
>
> Log:
> * src/embed.c:
>+ (Parrot_readbc): fread returns size_t, so change the decalaration
> of read_result to match.
As size_t is always positive, the conditional on line 431 can never be t
As a ref point, AppleScript 2.0 (not that I know if anyone wants to
port that to Parrot) "characters" are defined as Unicode "grapheme
clusters", e.g. the base grapheme and its diacriticals... Is that
similar to the concept of a Parrot_Rune?
On 3/14/08, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Fixes confirmed. c++ for the quick work.
Am Samstag, 8. März 2008 13:59 schrieb Simon Cozens:
> Hi folks,
> I think I've finished doing what I can with
> docs/pdds/draft/pdd28_character_sets.pod for the time being.
> Please have a look at it, and let me know if there's anything wrong,
> anything unclear, anything missing or an
On Wednesday 12 March 2008 23:38:46 [EMAIL PROTECTED] wrote:
> Author: duff
> Date: Wed Mar 12 23:38:44 2008
> New Revision: 26345
>
> Modified:
>trunk/languages/perl6/src/pmc/perl6str.pmc
>
> Log:
> [rakudo] rough cut implementation of auto-{increment,decrement} for
> Perl6Str
>
>
> Modified:
On Friday 14 March 2008 16:10:46 James Keenan wrote:
> Observed on i386-Linux at r 26369:
>
> $ prove -v t/codingstd/check_isxxx.t
> t/codingstd/check_isxxx..
> 1..1
> not ok 1 - isxxx() functions cast correctly
>
> # Failed test 'isxxx() functions cast correctly'
> # at t/codingstd/check_
On Fri, 14 Mar 2008 16:19:48 -0700
"James Keenan via RT" <[EMAIL PROTECTED]> wrote:
> Mark:
>
> This looks good to me. However, one of the tests being revised is
> currently failing, probably for different reasons. See:
> http://rt.perl.org/rt3/Ticket/Display.html?id=51750.
Thanks for the cod
On Friday 14 March 2008 16:19:49 James Keenan via RT wrote:
> This looks good to me. However, one of the tests being revised is
> currently failing, probably for different reasons. See:
> http://rt.perl.org/rt3/Ticket/Display.html?id=51750. I recommend
> holding off applying it to trunk until a
Mark:
This looks good to me. However, one of the tests being revised is
currently failing, probably for different reasons. See:
http://rt.perl.org/rt3/Ticket/Display.html?id=51750. I recommend
holding off applying it to trunk until after that bug is resolved --
which I suspect means holding of
From: chromatic <[EMAIL PROTECTED]>
Date: Fri, 14 Mar 2008 16:06:32 -0700
My manpage suggests that fread returns size_t, and that's part of C89 and
POSIX.1-2000, so go ahead and apply.
-- c
Thanks; done as r26370.
-- Bob
# New Ticket Created by James Keenan
# Please include the string: [perl #51750]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51750 >
Observed on i386-Linux at r 26369:
$ prove -v t/codingstd/check_isxxx.t
t/codingstd/che
On Friday 14 March 2008 15:57:44 Bob Rogers wrote:
>Parrot_readbc declares read_result as INTVAL, but assigns to it the
> result of fread, which (on my system) is declared to return a size_t.
> But later there is a check for a negative result, which makes no sense.
> Are there systems on which
Attached is where things stand on Linux as of r26369.
t/src/io..
1..20
ok 1 - hello world
ok 2 - write
ok 3 - file content
ok 4 - read
ok 5 - append
ok 6 - file content
ok 7 - readline
ok 8 - PIO_parse_open_flags
ok 9 - PIO_open
ok 10 - PIO_read
ok 11 - PIO_read larger file
ok 12 - PIO_read lar
Parrot_readbc declares read_result as INTVAL, but assigns to it the
result of fread, which (on my system) is declared to return a size_t.
But later there is a check for a negative result, which makes no sense.
Are there systems on which fread returns a signed value, or should the
declaration of
(Here follows various comments and opinions on PDD28 draft, written
while reading it)
As has been pointed out, the expression «A grapheme is our concept» is
not really clear. I think «The term "grapheme" in this document
defines a concept local to Parrot» or some such.
I'm not sure that UTF-16 ca
Did some housekeeping. 51028 was discussing a failure in exactly the
same test as 50776, so I merged the former into the latter. I added
references to two much older tickets -- both unresolved -- which are
concerned with failures in the same test file (though probably not
exactly the same test).
On Friday 14 March 2008 15:15:07 James Keenan via RT wrote:
> On Fri Mar 14 06:31:08 2008, [EMAIL PROTECTED] wrote:
> > ..\..\parrot.exe ..\..\compilers\tge\tgc.pir
> > --output=POST\Grammar_gen.p
> >
> > ir POST\Grammar.tg
> >
> > Parrot VM: PANIC: Null vtable used; did you add a new PMC
On Fri Mar 14 06:31:08 2008, [EMAIL PROTECTED] wrote:
> Visual Studio 2008, ActiveState Perl running configure.pl
>
>
>
> ..\..\parrot.exe ..\..\compilers\tge\tgc.pir
> --output=POST\Grammar_gen.p
>
> ir POST\Grammar.tg
>
> Parrot VM: PANIC: Null vtable used; did you add a new PMC?!
>
In article <[EMAIL PROTECTED]>, herbert breunung
<[EMAIL PROTECTED]> wrote:
> currently just used for compile time constants like $?LINE allright so
> far so good.
> but why not use that for all constants like
>
> my $?constant = 5;
The $? is telling us where the value came from, not that it's
Hi,
another milestone release of Parrot is coming up this Tuesday, March
18th. I'm proud to host
the release procedures this time.
All contributors are encouraged to look at their contributions from the
last month and
to add their bits to NEWS and CREDITS. Also updates to PLATFORMS and to
LA
# New Ticket Created by "Ted Neward"
# Please include the string: [perl #51732]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51732 >
Visual Studio 2008, ActiveState Perl running configure.pl
..\..\parrot.exe .
On Thu, Mar 13, 2008 at 5:46 AM, Simon Cozens <[EMAIL PROTECTED]> wrote:
> Simon Cozens wrote:
> > I think I've finished doing what I can with
> > docs/pdds/draft/pdd28_character_sets.pod for the time being.
> > Please have a look at it, and let me know if there's anything wrong,
> > an
> currently just used for compile time constants like $?LINE allright so
> far so good.
> but why not use that for all constants like
>
> my $?constant = 5;
Because then you'd have to change existing code if you find out that
constant was not so constant at all, and you'd like to have a variable
i
On Fri, Mar 14, 2008 at 7:18 AM, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> Even if we were to have a "constant" twigil, I dont much like "$?" for it.
> No mnemomic value. For the builtins, it's not the constancy but the fact
> that they let you quey the config...
> The case distinction wyou sug
[EMAIL PROTECTED] wrote:
currently just used for compile time constants like $?LINE allright so
far so good.
but why not use that for all constants like
my $?constant = 5;
Because then you'd have to change existing code if you find out that
constant was not so constant at all, and you'd l
Even if we were to have a "constant" twigil, I dont much like "$?" for
it. No mnemomic value. For the builtins, it's not the constancy but
the fact that they let you quey the config...
The case distinction wyou suggest orks just as well on the user side.
Make your constants capitalized and your
currently just used for compile time constants like $?LINE allright so
far so good.
but why not use that for all constants like
my $?constant = 5;
so it's compiletime (even late compiletime like in eval blocks) fix
binding to a value.
Because that variable comes from a different place
# New Ticket Created by Mark Glines
# Please include the string: [perl #51718]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51718 >
There's a lot of common code in the tests in these directories, for
looping across a bunc
28 matches
Mail list logo
