On Wed, Dec 20, 2006 at 10:24:55PM +, Smylers wrote:
: [EMAIL PROTECTED] writes:
:
: > New Revision: 13495
: >doc/trunk/design/syn/S12.pod
: >
: > +In addition to C, the special functions C,
: > +C, C, and C dispatch to the next
: > +candidate, possibly with a new argument list, and if th
I'm solicting Cage Cleaner tasks for the next Perl.com newsletter. What's at
the top of the list for someone to do with Perl skills, with C skills, and
with only a bit of spare time?
Offlist replies are fine, if you like.
-- c
Author: larry
Date: Wed Dec 20 18:42:50 2006
New Revision: 13497
Modified:
doc/trunk/design/syn/S03.pod
Log:
Made Range objects smarter about transforms.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design
On Wed, Dec 20, 2006 at 10:59:34PM +, Jonathan Worthington wrote:
> Leopold Toetsch wrote:
> >Am Mittwoch, 20. Dezember 2006 05:59 schrieb Will Coleda:
> >
> >>Are Hash and Array supposed to have different results on unset keys?
> >>
> >
> >The .Undefs returned by Arrays are IMHO and unfo
chromatic via RT did write:
garaud and I hope to have fixed this as of r16139, though he still has
some dynext and dynpmc failures on his FreeBSD 6.2-tobe box.
Can anyone still confirm?
I just synched to 16207, but the test suite produces the following:
Failed Test Stat Wstat
Leopold Toetsch wrote:
Am Mittwoch, 20. Dezember 2006 05:59 schrieb Will Coleda:
Are Hash and Array supposed to have different results on unset keys?
The .Undefs returned by Arrays are IMHO and unfortunate leftover of he early
PerlArrays. We've managed to change the return result of h
On Mon Dec 18 18:25:24 2006, jhi wrote:
> Two patches, the first is needed for parrot trunk to compile at all
> in Tru64, the second one is needed to dodge dozens of core dumps.
> There still are some, will take a closer look when I have more time,
> but least this way there is less wading in core
chromatic via RT did write:
garaud and I hope to have fixed this as of r16139, though he still has
some dynext and dynpmc failures on his FreeBSD 6.2-tobe box.
Can anyone still confirm?
Let me have a look and I'll get back to you.
David
--
"It's overkill of course, but you can never have too
Am Mittwoch, 20. Dezember 2006 20:24 schrieb Ron Blaschke:
> - The assertion seems to check that the lowest two bits of a function
> pointer are zero. Why's that?
That's a bigger hack to discern function from PMC pointers in that table. That
hack and the whole table needs to be replaced by a mor
[EMAIL PROTECTED] writes:
> New Revision: 13495
>doc/trunk/design/syn/S12.pod
>
> +In addition to C, the special functions C,
> +C, C, and C dispatch to the next
> +candidate, possibly with a new argument list, and if the "next"
> +variant is used, without returning:
> +
> +callsame;
On Wed, Dec 20, 2006 at 10:26:41AM -0600, Jonathan Rockway wrote:
: Ovid wrote:
: (reversed the message a bit)
: > is 'b', any('a' .. 'h'), 'junctions should work';
:
: This looks like a Test "bug"; it's doing something like:
:
:is 'b', 'a' # not ok
:is 'b', 'b' # ok
:is 'b', 'c' #
Whatever you were able to apply is fine.
On Dec 20, 2006, at 10:35 AM, Paul Cochrane via RT wrote:
On Tue Aug 29 19:03:44 2006, coke wrote:
The attached patch casts all the printfs arguments corresponding to
"%
p" to be (void *), to avoid compiler warnings.
However, the following tests fail
Ovid wrote:
(reversed the message a bit)
> is 'b', any('a' .. 'h'), 'junctions should work';
This looks like a Test "bug"; it's doing something like:
is 'b', 'a' # not ok
is 'b', 'b' # ok
is 'b', 'c' # not ok
...
If you write:
ok 'b' === any('a'..'h')
The result is one passing
chromatic wrote:
> On Wednesday 20 December 2006 11:24, Ron Blaschke wrote:
>
>> - The assertion seems to check that the lowest two bits of a function
>> pointer are zero. Why's that?
>
> Presumably because pointers need a specific alignment, so those two bits will
> always be zero on a raw poi
On Tue, Dec 19, 2006 at 04:30:08PM -0800, Allison Randal wrote:
> Nicholas Clark wrote:
> >
> >To seek clarification - having those as global settings for cperl isn't
> >likely to be an issue? Or having them in editor blocks?
>
> I meant globally.
Ah. There have been times when it would have been
On Wednesday 20 December 2006 11:24, Ron Blaschke wrote:
> - The assertion seems to check that the lowest two bits of a function
> pointer are zero. Why's that?
Presumably because pointers need a specific alignment, so those two bits will
always be zero on a raw pointer -- and thus, they're ava
Sorry to bring this up again, but I hope someone can help me with this.
I'm trying to compile Parrot on Windows XP / Visual C++ with assertions
enabled, that is, without C.
When running miniparrot I receive the following error:
Assertion failed: (PTR2UINTVAL(mmd_table[i].func_ptr) & 3) == 0, fil
Am Mittwoch, 20. Dezember 2006 05:59 schrieb Will Coleda:
> Are Hash and Array supposed to have different results on unset keys?
The .Undefs returned by Arrays are IMHO and unfortunate leftover of he early
PerlArrays. We've managed to change the return result of hashes to .Null, so
this should b
HaloO,
Larry Wall wrote:
Then we'd write our "done_by" role above as:
role Num-1.3-JRANDOM does STD:Num does Complex;
method re (--> STD:Num) { self }
method im (--> STD:Num) { 0.0 }
The first issue I see with this approach is that we get one
more contender for the plain name Comp
On Tue Aug 29 19:03:44 2006, coke wrote:
> The attached patch casts all the printfs arguments corresponding to
"%
> p" to be (void *), to avoid compiler warnings.
>
> However, the following tests fail after the change:
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---
20 matches
Mail list logo
