This patch seems to have slipped by in the post New Year's haze. It
updates Parrot's version of Test::More to 0.41 and makes Parrot::Test
use Test::Builder instead of doing Evil things to Test::More.
Less Evil is Good.
http:[EMAIL PROTECTED]/msg07760.html
--
Michael G. Schwern <[EMAIL PRO
Simon Cozens:
# This is my new toy. It's not perfect. I know what's lacking and I know
# how to fix it, but time is always against us. You don't need any
# documentation, you're intelligent people. Feed some code to
# Perl6::Tokeniser::toke, and it'll give you an array.
#
# Parser coming soon.
Wo
I just committed a change to the code that moves the registers into
the interpreter structure rather than accessing the things indirectly
as we were before. Pushes and pops are a little slower as there are
memcpys involved now, but register access itself should be faster as
there's one fewer l
I just committed the fix for that Dan, disregard.
-Melvin
>Checking some things by compiling and running another small C program (this
>could take a while):
>
> Building ./testparrotsizes.cfrom testparrotsizes_c.in...
>In file included from include/parrot/string.h:18,
>
Enjoy. :)
-Melvin
Checking some things by compiling and running another small C program (this
could take a while):
Building ./testparrotsizes.cfrom testparrotsizes_c.in...
In file included from include/parrot/string.h:18,
from include/parrot/parrot.h:85,
This is my new toy. It's not perfect. I know what's lacking and I know
how to fix it, but time is always against us. You don't need any
documentation, you're intelligent people. Feed some code to
Perl6::Tokeniser::toke, and it'll give you an array.
Parser coming soon.
--
"It's God. No, not Ri
On Sun, Jan 27, 2002 at 03:44:07PM -0800, Peter Scott wrote:
> Count me among the crazed whales/mad dolphins/whatever you were referring
> to. It would make it easier to explain to beginners the rules for calling
> functions by eliminating a qualification ("You can leave empty parens off
> onl
At 01:16 PM 1/26/02 -0700, Tom Christiansen wrote:
>There is another way to resolve the ambiguity of foo meaning either
>"foo" or foo() depending on current subroutine visibility. This
>would also extend then to issue of $hash{foo} meaning either
>$hash{foo()} or $hash{"foo"}. Just use parens.
Melvin Smith wrote in perl6-language:
>>
>>Besides no one has commented on Steve Fink's (I think it was him) idea
>>to store the result of the most recently executed conditional in $?. I
>>kinda like that idea myself. It makes mnemonic sense.
>
> I like the $? idea, and it could probably be optim
Looking at this url:
http://tinderbox.perl.org/tinderbox/showbuilds.cgi?tree=parrot&hours=8&legend=
0
I see that somebody is compiling Parrot (current cvs) on Mac OS X 10.1.
I am running 10.1.2 Server, with Apple's second patch. This is the most
recent flavor of OS X. I'm kind of distr
> Damian> @result = {block}^.(@data);
>
> But "hyperdot sort hyperdot" doesn't roll off the tongue as easy as
> "map sort map"!
H. You could always overload binary - to implement the sort.
Then it would be:
hyper dot dash dot
Otherwise known in Morse circles as:
hy
> On 1/27/02 9:57 AM, Simon Cozens wrote:
> > I can't help thinking that requiring quotes will
> > make it all nice and consistent, and completely
> > zap all these edge cases.
>
> Well, it'll sure make the subset of Perl programmers
> who have always quoted hash subscripts anyway (like
> me - us
> "Damian" == Damian <[EMAIL PROTECTED]> writes:
Damian> @result = {block}^.(@data);
But "hyperdot sort hyperdot" doesn't roll off the tongue as easy as
"map sort map"!
:-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://w
On 1/27/02 9:57 AM, Simon Cozens wrote:
> I can't help thinking that requiring quotes will make it all nice and
> consistent, and completely zap all these edge cases.
Well, it'll sure make the subset of Perl programmers who have always quoted
hash subscripts anyway (like me--usually with single q
On Sat, Jan 26, 2002 at 10:33:54AM -0800, Peter Scott wrote:
> Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it
> won't be because of the "no barewords" rule. If there were such a rule, I
> presume you'd also apply it to the LHS of =>?
It's only a bareword when the parse
On Sat, Jan 26, 2002 at 10:45:02PM +, Simon Cozens wrote:
> On Sat, Jan 26, 2002 at 10:17:12PM +, Nicholas Clark wrote:
> > But I can't see a way to tell gcc that we want to do this and locally
> > no warnings 'cast-qual'; (if you see what I mean)
> > There don't seem to be pragmata to do
Hi,
This is already handled in Perl 5 - which I guess will have
an influence on Perl 6. I doubt Larry is going to force
everyone to quote the hash subscripts (are you Larry? :)
Let a newish (6 < now < 12 months) non professional
(unemployed student ;) Perl programmer, like myself, look
at how h
17 matches
Mail list logo
