At 11:16 PM -0600 8/16/06, David Green wrote:
On 8/15/06, Darren Duncan wrote:
At 2:51 PM -0600 8/15/06, David Green wrote:
[...]
You are right, but we have both Seq and Array types, so depending
which one you use, you want either the === or eqv operators to do
what you want. There is no rea
first merge done. yeah baby
At 15:48 15/08/2006 -0700, chromatic wrote:
Here's a proposed patch that seems to work okay for me on Linux. It's not
great or beautiful, mostly because of the Makefile hackery. It's a starting
point though. I suspect Windows might complain.
I try it on Win2000 with MinGW.
1) ExtUtils::PkgCo
# New Ticket Created by Nuno Carvalho
# Please include the string: [perl #40160]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40160 >
Good afternoon,
After some more discussion on #parrot I've rewrote a very simple
tes
# New Ticket Created by Amir E. Aharoni
# Please include the string: [perl #40162]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40162 >
Hi,
It's my first patch,
I hope that it's not a terrible mistake,
And I hope that th
# New Ticket Created by Nuno Carvalho
# Please include the string: [perl #40187]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40187 >
Good morning,
After some more discussion on #parrot I've rewrote a very simple
test
Hi
Ignore & close this one i guess, everyone thought this mail was lost.
./smash
On 8/17/06, via RT Nuno Carvalho <[EMAIL PROTECTED]> wrote:
# New Ticket Created by Nuno Carvalho
# Please include the string: [perl #40160]
# in the subject line of all future correspondence about this issue.
#
On 8/16/06, Agent Zhang <[EMAIL PROTECTED]> wrote:
On 8/17/06, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> Where can I find a pod2html that groks the p6 version of POD? I want
> to format my fresh-from-svn copies of the doc...
>
...
And there're also an online HTML version of the Perl 6 Spec
On 8/17/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
Generally speaking, the direct use of === is more for specialized
purposes, somewhat like the direct use of =:= is. If one can't tell
the difference between === and eqv, they most likely want snapshot
semantics anyway, and so might as well for
On Thu, Aug 17, 2006 at 01:22:11AM -0700, Nuno Carvalho wrote:
> After some more discussion on #parrot I've rewrote a very simple
> test file to evaluate some very simple PGE grammars. [...]
Applied, thanks!
Pm
Just noticed this on line 474: "Variables with native types does not
support undefinedness"
S02 states that there is no ".length" method on Str's (or for cumulative
element length of Arrays); you have to ask explicitly for the units you
want to count . But then it goes on to define the StrPos and StrLen
types, which are unit-agnostic. So why not have a .length that returns
a StrLen?
S03, lines 418-420: "[cmp] always returns C,
C, or C (which numerify to -1, 0, or +1)."
Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
which case it would be clearer to put them in respective order above...
-- Original message --
From: "Reed, Mark (TBS)" <[EMAIL PROTECTED]>
> S03, lines 418-420: "[cmp] always returns C,
> C, or C (which numerify to -1, 0, or +1)."
>
> Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
> which case it would be cl
On 8/17/06, Darren Duncan wrote:
At 11:16 PM -0600 8/16/06, David Green wrote:
I just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to
[1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case
(regardless of Seq vs. Array -- I didn't t
On 8/17/06, Reed, Mark (TBS) wrote:
S03, lines 418-420: "[cmp] always returns C,
C, or C (which numerify to -1, 0, or +1)."
Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
which case it would be clearer to put them in respective order above...
Maybe you could view it e
On Thu, Aug 17, 2006 at 11:27:21AM -0600, David Green wrote:
: However, what I'm wondering is whether Order::Same is "but true" and
: the others "but false"? (Which makes cmp in boolean context the same
: as eqv, but it seems to make sense that way.)
We should not be encouraging people to use c
I don't know if I've made this clear, but over the last few years I've
been treating "but True" and "but False" as design smells. They're
fine as a workaround for dire circumstances and uncooperative types,
but you'll not find me designing very many of the core interfaces to
use them, or other run
On 8/16/06, David Green wrote:
$a=[1, 2, [EMAIL PROTECTED];
$c=[1, 2, [EMAIL PROTECTED];
$d=[1, 2, [EMAIL PROTECTED];
$a =:= $c; #false, different variables
$a === $c; #true, same elements make up $a and $c
$a eqv $c; #true, same elements therefore
On Thu, Aug 17, 2006 at 12:18:55PM -0600, David Green wrote:
: So perhaps what I'm looking for is more syntactic
: sugar for easily traversing nested data
: structures in different ways.
Quoth S03:
If that's not enough flexibility, there is also an C function
that can be passed addition
On 8/17/06, David Green <[EMAIL PROTECTED]> wrote:
>$a=[1, 2, [EMAIL PROTECTED];
>$c=[1, 2, [EMAIL PROTECTED];
>$d=[1, 2, [EMAIL PROTECTED];
>
>So $a, $c, and $d may all have the same *value*
>(or "snapshot", when evaluated all the way down
>through nesting and references), i.e. they
Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
>
> The None class serves no useful (portable) purpose and it should be
> removed, especially from the public interface of Hash.
I've started fixing that. I'll do that in small steps, as there are some build
and test errors. The main p
On Thu, Aug 17, 2006 at 09:12:07PM +0200, Leopold Toetsch wrote:
> A releated change:
>
> $S0 = hsh['no_such_key']
>
> used to return an empty STRING*, it'll soon return a NULL STRING*.
Just a note (to copy from irc #parrot) -- this will cause a number
of things in PGE and perl6 to break, as
David Green wrote:
No, look at the example I've been using. Two arrays (1, 2, [EMAIL PROTECTED]) and (1,
2, [EMAIL PROTECTED]) clearly have different (unevaluated) contents. "eqv" only tells
me whether they have the same value (when @x and @y are evaluated).
That's a different question --
On Thu, Aug 17, 2006 at 12:13:30PM -0700, Leopold Toetsch via RT wrote:
> Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
> > The None class serves no useful (portable) purpose and it should be
> > removed, especially from the public interface of Hash.
>
> I've started fixing that.
{DESIGNER ALERT - Allison, what think?}
On Thu, Aug 17, 2006 at 12:31:11PM -0700, Patrick R. Michaud via RT wrote:
> I rely on the "return empty string" behavior. In particular, changing it
> to return NULL will mean in many places that I will have to replace
> single-line key lookups
>
> $S
On 8/17/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
How about a 'default' opcode that provides a value instead of null? It
would work for strings and PMCs. Something like:
$S0 = default hsh['key'], ''
or
$P0 = new .Undef
...
$P1 = default hsh['key1'], $P0
$P1 = d
On Thu, Aug 17, 2006 at 12:55:54PM -0700, Chip Salzenberg wrote:
> {DESIGNER ALERT - Allison, what think?}
>
> On Thu, Aug 17, 2006 at 12:31:11PM -0700, Patrick R. Michaud via RT wrote:
> > I rely on the "return empty string" behavior. In particular, changing it
> > to return NULL will mean in ma
On Thu, Aug 17, 2006 at 01:11:00PM -0700, jerry gay wrote:
> On 8/17/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > $S0 = default hsh['key'], ''
> >[...]
> > $P0 = new .Undef
> > $P1 = default hsh['key1'], $P0
> > $P1 = default hsh['key2'], $P0
> > ...
> >
> >It would work w
On 8/17/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
There might be a cognitive dissonance here with "err", since
C in pasm/pir is testing for null, while C in
perl6 tests for definedness. While it doesn't much matter
for strings in the examples above, it might make a difference for
$
Am Donnerstag, 17. August 2006 21:50 schrieb Chip Salzenberg:
> > Folks, please check your usage of testing for existing hash keys.
>
> Well, we (core hackers) changing the interface out from underneath them, so
> if their code breaks, we should fix it up, if we can. Code outside the svn
> tree (e
Am Donnerstag, 17. August 2006 21:55 schrieb Chip Salzenberg:
> > $S0 = hsh['key']
> >
> > with
> >
> > $S0 = hsh['key']
> > unless null $S0 goto label
> > $S0 = ''
> > label:
>
> Indeed. I think we can reduce the pain of dealing with this to the point
> where you'll hardly feel
I was just reading through S12, and it doesn't seem to ever actually
state that the default invocant name is "self". (Is it self? Or is
it $?SELF, which doesn't appear at all?) S12 mentions declaring an
explicit invocant with : in the method signature, and that it's
optional; and then later on
On Fri, Aug 18, 2006 at 12:17:58AM +0200, Leopold Toetsch wrote:
> A lot of src/string string_ operations are capable of dealing with NULL
> strings currently [1]. *But* that's AFAIK specificied nowhere, and might just
> be an accident, i.e. an extra (unneeded/unwanted) check for A NULL argument.
Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
> The None class serves no useful (portable) purpose and it should be
> removed, especially from the public interface of Hash.
... and the None class is gone.
As mentioned:
$S0 = hsh['no_such_key']
is unchanged and returns ''
and
Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
> The None class serves no useful (portable) purpose and it should be
> removed, especially from the public interface of Hash.
This ticket could be closed, but replying to rt would reopen it - please check
subjects and recipients in th
{ not replying to the ticket }
On Fri, Aug 18, 2006 at 01:10:07AM +0200, Leopold Toetsch wrote:
> Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
> > The None class serves no useful (portable) purpose and it should be
> > removed, especially from the public interface of Hash.
>
> ..
Author: larry
Date: Thu Aug 17 16:08:34 2006
New Revision: 3
Modified:
doc/trunk/design/syn/S04.pod
Log:
Some leave simplifications.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod
Author: larry
Date: Thu Aug 17 16:39:38 2006
New Revision: 5
Modified:
doc/trunk/design/syn/S06.pod
Log:
More old use of multiple invocant terminology changed to longnames.
Added mechanism for both short and long switch names.
Modified: doc/trunk/design/syn/S06.pod
==
Author: larry
Date: Thu Aug 17 16:45:20 2006
New Revision: 6
Modified:
doc/trunk/design/syn/S12.pod
Log:
Added explicit mention of "self" by suggestion of markjreed++.
Modified: doc/trunk/design/syn/S12.pod
==
--
On Thu, Aug 17, 2006 at 12:00:17AM -0700, Darren Duncan wrote:
> As a lead-in, I should say that Synopsis 3 has a good and complete
> explanation of these matters and has had it for several weeks, in my
> opinion.
>
> Since you are wanting to compare two mutable Array, just use the eqv
> operat
On 8/16/06, Larry Wall <[EMAIL PROTECTED]> wrote:
: Is the output 01234 or 12345?
I'd say 01234 on the theory that the 3-arg loop is really saying:
$n = 0;
while $n < 5 {
NEXT { ++$n }
NEXT { print $n }
}
and also on the theory that block exiting blocks always run i
# New Ticket Created by Nuno Carvalho
# Please include the string: [perl #40191]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40191 >
Hi all,
After some suggestions made by particle on #parrot here's the patch to
impleme
On Thursday 17 August 2006 00:28, Francois PERRAD wrote:
> I try it on Win2000 with MinGW.
> 1) ExtUtils::PkgConfig is a wrapper over pkg-config, and pkg-config is not
> available on Windows
Okay, that's a problem. It's actually a big problem, for two reasons.
First, linking against libparrot r
Quoth [EMAIL PROTECTED] ("Mark J. Reed"):
> On 8/17/06, David Green <[EMAIL PROTECTED]> wrote:
> > >$a=[1, 2, [EMAIL PROTECTED];
> > >$c=[1, 2, [EMAIL PROTECTED];
> > >$d=[1, 2, [EMAIL PROTECTED];
> > >
> > >So $a, $c, and $d may all have the same *value*
> > >(or "snapshot", when eval
Hi there,
Here's a patch for Build.PL that should avoid most of the pkg_config troubles
on platforms that don't have it. I still don't quite know what to do on
Windows when installing from outside of the Parrot tree.
-- c
=== MANIFEST
===
Chip Salzenberg wrote:
How about a 'default' opcode that provides a value instead of null? It
would work for strings and PMCs. Something like:
$S0 = default hsh['key'], ''
or
$P0 = new .Undef
...
$P1 = default hsh['key1'], $P0
$P1 = default hsh['key2'], $P0
..
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 17, 2006 8:44 PM
> To: Perl6 Language List
> Subject: Re: NEXT and the general loop statement
> Wasn't NEXT supposed to do something tricky, such as being mutually
> exclusive with LAST? I remembe
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 17, 2006 8:44 PM
> To: Perl6 Language List
>
> Wasn't NEXT supposed to do something tricky, such as being mutually
> exclusive with LAST? I remember a debate some time ago where some
> complained
在 2006/8/18 上午 3:31 時，Ben Morrow 寫到：
Just to make sure I've got all this straight:
=:= compares names
=== compares containers
eqv compares values
=:= evaluates both sides as lvalue -- that's VAR() -- and compare
them with ===.
=== evaluates both sides as rvalue and, for containe
On Thu, Aug 17, 2006 at 11:45:06PM -0400, Joe Gottman wrote:
> > -Original Message-
> > From: Luke Palmer [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, August 17, 2006 8:44 PM
> > To: Perl6 Language List
> >
> > Wasn't NEXT supposed to do something tricky, such as being mutually
> > exclus
At 12:58 16/08/2006 -0700, jerry gay wrote:
On 8/15/06, chromatic <[EMAIL PROTECTED]> wrote:
Here's a proposed patch that seems to work okay for me on Linux. It's not
great or beautiful, mostly because of the Makefile hackery. It's a starting
point though. I suspect Windows might complain.
w
52 matches
Mail list logo
