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
> ---
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
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
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
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, 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
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
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
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
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' #
[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;
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
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
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
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
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
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
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: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
20 matches
Mail list logo
