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
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
在 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
> -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
> -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
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
..
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
===
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
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
# 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 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
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
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
==
--
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
==
{ 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.
>
> ..
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
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
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
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.
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
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
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
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
$
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 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 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
{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 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.
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 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
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 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
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/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
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 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
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 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
-- 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
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...
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?
Just noticed this on line 474: "Variables with native types does not
support undefinedness"
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
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 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
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.
#
# 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
# 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 #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
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
first merge done. yeah baby
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
52 matches
Mail list logo
