On Mon, Aug 29, 2005 at 15:12:44 +0200, TSa wrote:
> HaloO,
>
> Yuval Kogman wrote:
> >On Mon, Aug 29, 2005 at 13:12:37 +0200, TSa wrote:
> >>Sorry, I believe everything is an operator---or actually operators
> >>are Code subtypes with syntactic sugar. But some operators are usually
> >>not dispat
> [EMAIL PROTECTED] - Fr 12. Aug 2005, 10:14:32]:
>
> Greetings.
> My name is Daniel, and I apparently have a problem building Parrot on
> my
> Windows XP in a DOS shell. I am using MinGW's gcc version, and the
> configuration went through just fine, but when I typed "make", it
> seemed to
> go t
Will Coleda wrote:
But it looks like the PMC args are getting *switched* somehow. looking
at the stack trace below starting just before the tailcall:
I've now located the problem, but I can't fix it right now. It is a bit
non-trivial. The bug isn't related to tailcalls at all, which mislead
HaloO Larry,
you wrote:
: >we need only provide an alternate comparison to
: >the constructor, and the set itself needn't remember it. On the
: >other hand, hashes behaving like mutable sets need to remember their
: >comparison operator if it is not the default.
:
: The slot accessor paradigma
HaloO,
Damian Conway wrote:
I think that's an appalling idea. <<>> is *vastly* more valuable as
interpolated word list.
I agree.
If you *have* to propose manuthreading, go with the previous proposal
and use >><< instead. The argument that the angles should point to the
operator is spurious.
HaloO,
Ingo Blechschmidt wrote:
But there is a problem with the ordinary assignment form:
($head, @tail) = foo();
If the LHS is an ordinary list (i.e., if we don't use help from the
grammar/macros),
What is a 'ordinary List' to you? I thought (,) constructs a Lazy list?
then the @tail
HaloO,
Yuval Kogman wrote:
IMHO definately autovivify
* @foo[$idx] := $var;
my @bar = @foo;
$var= $new_var;
# @foo[$idx] and $var are now $new_var, but @bar is unchanged, right?
Yes, I agree. But we do need a way in the middle. Right now we have:
@bar := @foo; # arr
On Mon, Aug 29, 2005 at 13:12:37 +0200, TSa wrote:
> Sorry, I believe everything is an operator---or actually operators
> are Code subtypes with syntactic sugar. But some operators are usually
> not dispatched because the type system manages to produce the same
> effect as a real dispatch. But tha
On Sat, Aug 27, 2005 at 08:19:00PM +0200, Ingo Blechschmidt wrote:
: But there is a problem with the ordinary assignment form:
:
: ($head, @tail) = foo();
:
: If the LHS is an ordinary list (i.e., if we don't use help from the
: grammar/macros), then the @tail would get flattened before it re
HaloO,
Damian Conway wrote:
Just a meta-point...one thing we really do need to be careful of is not
ending up with 17 different "equality" operators (like certain languages
I shall refrain from naming). So far we're contemplating:
=:=
~~
==
eq
eqv
equals
Do we really
On Wed, Aug 24, 2005 at 16:57:30 +1000, Damian Conway wrote:
This is what the operators mean to me:
> =:=
The right side and the left are the same thing, in the sense that:
$x =:= $y; # if this is true
$x.mutating_method; # and one side is changed
$x =:= $y; # the
On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote:
> HaloO,
>
> Damian Conway wrote:
> >Just a meta-point...one thing we really do need to be careful of is not
> >ending up with 17 different "equality" operators (like certain languages I
> >shall refrain from naming). So far we're
> >contemplat
HaloO,
Yuval Kogman wrote:
On Mon, Aug 29, 2005 at 13:12:37 +0200, TSa wrote:
Sorry, I believe everything is an operator---or actually operators
are Code subtypes with syntactic sugar. But some operators are usually
not dispatched because the type system manages to produce the same
effect as
Next big issue with tcl in leo-ctx5 seems to be PGE's glob (A quick
check shows no tests for glob, which is probably why this fell
through the cracks.) Below, find a short PIR snippet that
demonstrates the problem. in trunk, it prints:
: 0
But in leo-ctx5, it prints:
src/nci.c:63: failed
On Aug 29, 2005, at 19:28, Will Coleda wrote:
Next big issue with tcl in leo-ctx5 seems to be PGE's glob (A quick
check shows no tests for glob, which is probably why this fell through
the cracks.) Below, find a short PIR snippet that demonstrates the
problem. in trunk, it prints:
751
I've looked over over the diffs between trunk and leo-ctx5, and here
are my notes.
{{ OVERALL }}
A significant improvement. Good work, y'all.
{{ USER-VISIBLE }}
* optional parameter interface: ":opt_count" -> ":opt_flag"
+ As some of you may recall, ":opt_count" semantics don't work if
I've written a new O1 optimization, branch_reorg(). It does the following:
1. Finds an unconditional jump (ie branch)
2. If its target instruction is not reachable by falling through from
the previous block (ie preceded by an unconditional jump)
3. All instructions from the target ins to the next
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #37021]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37021 >
Recently a couple of new language implementations have arrived in the
'languag
18 matches
Mail list logo
