At 7:42 AM + 12/22/05, Luke Palmer wrote:
Recently, I believe we decided that {} should, as a special case, be
an empty hash rather than a do-nothing code, because that's more
common.
However, what do we do about:
while $x-- && some_condition($x) {}
Here, while is being passed a hash,
On Wed, Dec 21, 2005 at 01:34:39PM -0800, Joe McMahon wrote:
> print < 1..1
> not ok 1 ... failed once
> not ok 1 ... failed twice
> ok 1 ... worked
> EOS
> Obviously, you can wrap up the actual test in a retry loop/function,
> but this doesn't match up with the simplicity of Test::More and rel
Hi Nick,
Nick Glencross via RT wrote:
Yes, there's a problem building dynclasses on cygwin. [I think that there
are a few related calls logged]
One quick hack to complete the build is to type 'echo all: >
src/dynclasses/Makefile' after running Configure.pl.
Many thanks. I shall do that in
Test::Harness doesn't mind if you don't have numbers on your tests
(not sure if this is by design or just by implementation) so this
"test script"
print "ok a hello\n";
print "not ok b hello\n";
print "1..2\n";
Gives
t/aFAILED test 2
Failed 1/2 tests, 50.00% okay
Failed Test Stat Wst
Guys,
I'd like to revive this patch which I posted a while back, but has
needed bringing up to date due to subsequent changes.
It has a few key intentions:
* Makes libparrot.so a 'first class citizen'
* Allows the installed version of parrot and its utilities to be
either shared or static
HaloO,
Larry Wall wrote:
And replying to the thread in general, I'm not in favor of stricter
default rules on undef, because I want to preserve the fail-soft
aspects of Perl 5.
Also replying to the thread in general, I feel that undef as a
language concept mixes too many usefull concept into a
HaloO,
Luke Palmer wrote:
Recently, I believe we decided that {} should, as a special case, be
an empty hash rather than a do-nothing code, because that's more
common.
Ups, is that distinction needed eagerly? Wouldn't the return value
of a do-nothing code return a value that when coerced into
Luke Palmer skribis 2005-12-22 7:42 (+):
> Recently, I believe we decided that {} should, as a special case, be
> an empty hash rather than a do-nothing code, because that's more
> common.
I think it should be both.
my $foo = {};
$foo(); # It was a sub
my $foo = {};
$foo =
On Thu, 22 Dec 2005, TSa wrote:
Luke Palmer wrote:
Recently, I believe we decided that {} should, as a special case, be
an empty hash rather than a do-nothing code, because that's more
common.
Hmmm, OTOH a hash is a special kind of function, so it may also be
convenient to think of { item
On Thu, 22 Dec 2005, Juerd wrote:
while $x-- && some_condition($x) {}
Here, while is being passed a hash
Why? Doesn't while's signature specifically prescribe a sub there, and
if it does, then wouldn't it be just a bit too silly to stick to {}
being a hash?
Well, as hinted in my other ma
On Thu, 22 Dec 2005, Darren Duncan wrote:
On a separate but related matter, I'm in the position of wanting to do
something unusual, which is create a data file format whose content is
executable perl code that defines a data structure, a hash of whatever.
Kind of like how XML works except tha
This is not a substantial issue regarding Perl 6, but is more a minor
feature curiosity/meditation. It was inspired some time ago by this PM
node:
http://perlmonks.org/?node_id=509310
I was wondering if in addition to push(), pop() etc. there could be be
rot() and roll() methods that would ac
Luke Palmer wrote:
> However, what do we do about:
>
> while $x-- && some_condition($x) {}
>
> Here, while is being passed a hash, not a do-nothing code. Should we
> force people to write:
>
> while $x-- && some_condition($x) {;}
Do we still have a yada yada yada? Could it be used to d
In Perl 5 C is quite natural for iterating over lists and arrays.
C is preferred for filehandles. With lazy evaluation this
difference has been eliminated in Perl 6 so that while still TMTOWTDI
(TAEMWTDI!) this kind of iterations will be more consistent.
But in Perl 5 to "navigate" complex str
HaloO,
Juerd wrote:
I think it should be both.
So do I.
my $foo = {};
$foo(); # It was a sub
The postfix () is valid syntax irrespective of the former
assignment, right?
my $foo = {};
$foo = 1; # It was a hash
Would you expect the second line to work witout the firs
On Thu, Dec 22, 2005 at 12:51:39PM +, Nick Glencross wrote:
> I'd like to revive this patch which I posted a while back, but has
> needed bringing up to date due to subsequent changes.
Thanks for your great work, Nick!
> I'd initially appreciate some feedback, and particularly reports of
>
On Thu, Dec 22, 2005 at 04:47:21PM +0100, Michele Dondi wrote:
> This is not a substantial issue regarding Perl 6, but is more a minor
> feature curiosity/meditation. It was inspired some time ago by this PM
> node:
>
> http://perlmonks.org/?node_id=509310
>
> I was wondering if in addition to
TSa skribis 2005-12-22 17:27 (+0100):
> >$foo(); # It was a sub
> The postfix () is valid syntax irrespective of the former
> assignment, right?
Valid syntax, sure, but it doesn't necessarily do something terribly
useful.
>
> >my $foo = {};
> >$foo = 1; # It was a hash
> Would you
On 12/22/05, Florian Ragwitz <[EMAIL PROTECTED]> wrote:
>
> On Thu, Dec 22, 2005 at 12:51:39PM +, Nick Glencross wrote:
> > I'd like to revive this patch which I posted a while back, but has
> > needed bringing up to date due to subsequent changes.
>
> Thanks for your great work, Nick!
>
> > I'
Tuesday, December 20, 2005, 8:09:32 PM, François PERRAD wrote:
> At 11:53 16/12/2005 +0100, you wrote:
>>I can think of two ways to fix this:
>>
>>- Hide every env access behind the platform stuff. That is, add
>>something like Parrot_environ.
> For me, this way sounds better.
> The platform/env
jerry gay wrote:
> compiling either with msvc 6.0 or 7.1 on win32, parrot behaves
> differently wrt 0 vs -0 depending on whether optmizations are enabled.
> nmake realclean && svn up && configure.pl && nmake smoke
> ## passes tests, which expect 0 and not -0
> nmake realclean && svn up && config
At 3:40 PM +0100 12/22/05, Michele Dondi wrote:
On Thu, 22 Dec 2005, Darren Duncan wrote:
On a separate but related matter, I'm in the position of wanting to
do something unusual, which is create a data file format whose
content is executable perl code that defines a data structure, a
hash of
> -Original Message-
> From: Austin Frank [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 22, 2005 10:58 AM
> To: Luke Palmer
> Cc: perl6language,
> Subject: Re: Problem with dwimmery
> Do we still have a yada yada yada? Could it be used to differentiate
> between the two cases?
>
Short version: uncomment lines 86-87, patch follows. I was hoping I
wouldn't need them, but I was wrong. This has been tested, and should
produce the correct output now.
--- mandelbrot.pir 2005-12-22 11:51:15.0 -0500
+++ mandelbrot-new.pir 2005-12-22 11:51:07.0 -0500
@@ -83,8
Luke Palmer wrote:
> Recently, I believe we decided that {} should, as a special case, be
> an empty hash rather than a do-nothing code, because that's more
> common.
>
> However, what do we do about:
>
>while $x-- && some_condition($x) {}
>
> Here, while is being passed a hash, not a do-nothin
On Thu, Dec 22, 2005 at 02:53:39PM +0100, TSa wrote:
> HaloO,
>
> Luke Palmer wrote:
> >Recently, I believe we decided that {} should, as a special case, be
> >an empty hash rather than a do-nothing code, because that's more
> >common.
>
> Ups, is that distinction needed eagerly? Wouldn't the ret
On Thu, Dec 22, 2005 at 02:00:49PM +0100, TSa wrote:
> HaloO,
>
> Larry Wall wrote:
> >but you do not want your rocket control software
> >throwing unexpected exceptions just because one of your engine
> >temperature sensors went haywire. That's a good way to lose a rocket.
>
> But then again y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 22, 2005, at 3:17 PM, peter baylies wrote:
Short version: uncomment lines 86-87, patch follows. I was hoping I
wouldn't need them, but I was wrong. This has been tested, and should
produce the correct output now.
--- mandelbrot.pir 200
On 12/22/05, Michele Dondi
> Please do not ask me what I have in mind, for I'm
> not really sure.
Well, @Larry has been researching attribute grammars for a month or
two now, which are an efficient (programmer-wise, not necessarily
processor-wise) method for specifying computations over trees. Th
29 matches
Mail list logo
