This issue should now be fixed in r32597 so that PGE::Match objects
correctly return an ObjectRef and assigns properly into scalar types.
Also, in order to help diagnose such issues in the future, I've added a
.PARROT method to rakudo that can be used to better diagnose what is
happening internall
Are duplicate values in any/all/none junctions expected to "collapse"
such that each value becomes unique? For example, should
any(1,2,2,1,2,3,2) internally reduce to the equivalent of
any(1, 2, 3)? Or is this something that is left to individual
implementations to decide?
Presumably the values
Patrick R. Michaud wrote:
Are duplicate values in any/all/none junctions expected to "collapse"
such that each value becomes unique? For example, should
any(1,2,2,1,2,3,2) internally reduce to the equivalent of
any(1, 2, 3)? Or is this something that is left to individual
implementations to d
HaloO,
Patrick R. Michaud wrote:
Presumably the values of a one() junction do not collapse in
this way, otherwise we could easily lose the fact that
a value occurs more than once:
my $a = (one(1,2,3) % 2 == 1);
Do I understand your question right, that you want the return
of == to be fals
> According to Synopsis 2, under "Immutable types", a Junction is a "Set with
> additional behaviors". This implies to me a Junction consists just of
> distinct unordered values. A Junction is not a Bag and it doesn't matter
> that we lose the fact that a value occurred more than once in the argu
On Thu, Nov 13, 2008 at 2:24 PM, TSa <[EMAIL PROTECTED]> wrote:
> Do I understand your question right, that you want the return
> of == to be false because there is a one(1,0,1) junction? As
> Duncan points out junctions are immutable values and as such
> the % autothreads but the resulting values
HaloO,
Leon Timmermans wrote:
Still that doesn't solve the problem of his code example. If my
understanding of the synopses is correct, operations on junctions
generate a new junction, so `one(1,2,3) % 2 == 1` will collapse to
one(1 % 2 == 1, 2 % 2 == 1, 3 % 2 == 1), which is one(true, false,
tr
Attached is a very simple patch that solves the problem, but I've only
tested lightly.
ternary.patch
Description: Binary data
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #60510]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60510 >
t/spec/S29-conversions/ord_and_chr.rakudo fails with:
t/spec/S29-conversions/ord
# New Ticket Created by Bruce Stockwell
# Please include the string: [perl #60512]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60512 >
This is a rewrite of t/names.t from a perl test to a PIR test
names.t | 63 ++
Author: coke
Date: Thu Nov 13 07:24:58 2008
New Revision: 32615
Modified:
trunk/docs/pdds/pdd19_pir.pod
Log:
RT #45859; remove last docu-reference.
Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #60506]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60506 >
for a few days now t/pmc/pmc.t fails with a segfault in the third test:
$ ./parrot t/pmc
On Thu, Nov 13, 2008 at 02:55:06PM +0100, Leon Timmermans wrote:
> On Thu, Nov 13, 2008 at 2:24 PM, TSa <[EMAIL PROTECTED]> wrote:
> > Pm wrote:
> > > Presumably the values of a one() junction do not collapse in
> > > this way, otherwise we could easily lose the fact that
> > > a value occurs more
HaloO,
Leon Timmermans wrote:
But of what use would one() if it were to use those semantics? It
would be essentially the same as any(), and it would definitely not
DWIM.
So you want one(1,1,2,3) to compare equal to 2 or 3 and exclude 1
because it is in the junction twice. That could be accompl
HaloO,
Patrick R. Michaud wrote:
I expect that $a will become one(True, False, True). $a doesn't
collapse to a non-Junction False until it is used in a boolean context.
My proposal is a different unification behavior in one() junctions.
my $a = one(1,2,3) % 2 == 1;
--> my $a = o
On Wed Nov 12 23:00:38 2008, chrisdolan wrote:
> Attached is a very simple patch that solves the problem, but I've only
> tested lightly.
I am truly impressed -- this particular approach to solving the problem
never occurred to me.
Patch applied (r32618), thanks!
Pm
On Wed Nov 12 23:00:38 2008, chrisdolan wrote:
> Attached is a very simple patch that solves the problem, but I've only
> tested lightly.
I am truly impressed -- this particular approach to solving the problem
never occurred to me.
Patch applied (r32618), thanks!
Pm
HaloO,
reading the "Collapsing Junction states" thread I wondered
how eqv and === handle junctions. I would expect
all(1,2) === all(1,2)
to evaluate to True and not expand to
1 === 1 && 1 === 2 && 2 === 1 && 2 === 2
which is False. OTOH,
2 === any(1,2,3)
should be False because 2.W
HaloO,
Patrick R. Michaud wrote:
By way of illustration, contrast the two assignments at
the end of the following code:
my @x = ;
my @y;
@y[1] = @x, 'c';
@y[1,2,3] = @x, 'c';
The second assignment would seem to clearly be a list
assignment, leaving @y with (undef, 'a', 'b', 'c
On Thu, Nov 13, 2008 at 05:02:56PM +0100, TSa wrote:
> HaloO,
>
> Patrick R. Michaud wrote:
>> I expect that $a will become one(True, False, True). $a doesn't
>> collapse to a non-Junction False until it is used in a boolean context.
>
> My proposal is a different unification behavior in one() jun
On Thu, Nov 13, 2008 at 05:37:21PM +0100, TSa wrote:
> HaloO,
>
> reading the "Collapsing Junction states" thread I wondered
> how eqv and === handle junctions. I would expect
>
>all(1,2) === all(1,2)
>
> to evaluate to True and not expand to
>
>1 === 1 && 1 === 2 && 2 === 1 && 2 === 2
>
>
On Thu, Nov 13, 2008 at 09:40:19AM -0800, Larry Wall wrote:
> On Thu, Nov 13, 2008 at 05:02:56PM +0100, TSa wrote:
> > Patrick R. Michaud wrote:
> >> I expect that $a will become one(True, False, True). $a doesn't
> >> collapse to a non-Junction False until it is used in a boolean context.
> >
> >
After getting confirmation from p6l...
Applied in r32625, thanks!
Pm
On Wed, Nov 12, 2008 at 03:35:08PM -0800, [EMAIL PROTECTED] (via RT) wrote:
> t/spec/S29-conversions/ord_and_chr.rakudo fails with:
>
> t/spec/S29-conversions/ord_and_chr.rakudo (Wstat: 10 Tests: 170 Failed: 0)
> Parse errors: Bad plan. You planned 240 tests but ran 170.
>
> However, it runs
On Thu, Nov 13, 2008 at 07:40:52AM -0800, Will Coleda via RT wrote:
> > I probably just need to remove the methods from the code,
> > see what breaks, and fix what breaks. I'll try to do that this
> > weekend before the release. If it doesn't happen then, we can
> > do it immediately following th
Can this ticket be closed?
Pm
On Thursday 13 November 2008 13:54:36 James Keenan via RT wrote:
> At r32625, I am observing this on Darwin/PPC -- but it passes on
> Linux/i386. Darwin below.
Is the backtrace the same as the one Moritz posted?
-- c
Patrick R. Michaud via RT wrote:
> Can this ticket be closed?
I'd say we stall it until the :trig tag export works for the
trigonometric functions.
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
On Wed Nov 12 08:07:43 2008, pmichaud wrote:
> On Tue, Nov 11, 2008 at 08:43:09AM -0800, Carl Mäsak wrote:
> > rakudo: for "foo\nbar\nbaz".split( /\n ** 2..*/ ) { say
> > .trans([ /\s+/ => " " ]) }
> > rakudo 32543: OUTPUT[too few arguments passed (2) - 3 params
> > expectedâ¤current instr.: '_blo
--- On Thu, 13/11/08, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Again, this is all with r32625, YMMV with other revisions
> (and please
> report whatever other clues you may find).
Ah, sorry. I should have known better :)
r32580
$ uname -a
Darwin curtis-poes-computer-2.local 9.5.1 Darwin
On Thu, Nov 13, 2008 at 5:31 PM, Ovid
<[EMAIL PROTECTED]>wrote:
> Now this test passes (r32629), but the Perl 6 test suite is still failing.
> Now, however, I can't tell which test fails.
Seems like the summary report should at least include counts of passed vs
failed tests. I assume the resul
I retract the previous comment. It was based on the file sent by Ovid; when
I run make spectest myself, I get more informative output. In my case, 2 of
the declaration-order tests are what's failing:
Failed Test Stat Wstat Total Fail List of Failed
--
On Thu, Nov 13, 2008 at 06:03:09PM -0500, Mark J. Reed wrote:
>
> It would also help if the actual test output weren't overrun with "Use of
> uninitialized value". Is that the result of bad tests or bad harness?
In some cases it's bad tests -- i.e., tests that are using
values of undef when the
On Thu, Nov 13, 2008 at 06:03:09PM -0500, Mark J. Reed wrote:
> Now this test passes (r32629), but the Perl 6 test suite is still failing.
> Now, however, I can't tell which test fails.
>
> Seems like the summary report should at least include counts of passed vs
> failed tests. I assume
S06:2362 says:
You can get the current routine name by calling C<&?ROUTINE.name>.
(The outermost routine at a file-scoped compilation unit is always
named C<&MAIN> in the file's package.)
Is this the same MAIN that is described later in
"Declaring a MAIN subroutine"? It seems like t
On Monday 03 November 2008 09:38:11 Andy Dougherty wrote:
> > 3. 1 of the tests appears to fail depending on how the OS initial-
> > cases 'Inf'. Again, could this be addressed in a hints file?
>
> This too is a long-standing problem: See [perl #19183]. It stalled
> pending a decision on wheth
Larry Wall wrote:
It seems simpler to say that one() produces bags rather than sets.
If we don't make other modifications to the language then this would mean that a
Junction is defined over a union type, "Set|Bag with additional behaviors",
depending on what operator constructed it.
Now ma
Darren Duncan wrote:
Larry Wall wrote:
It seems simpler to say that one() produces bags rather than sets.
If we don't make other modifications to the language then this would
mean that a Junction is defined over a union type, "Set|Bag with
additional behaviors", depending on what operator co
--- On Thu, 13/11/08, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> Failed Test Stat Wstat Total Fail
> List of Failed
> ---
Will Coleda via RT wrote:
This appears to be the only .pragma; should we leave a placeholder or
just remove .pragma entirely when we remove this particular one?
Nuke it.
Allison
Martin D Kealey wrote:
What about keeping track of where the exception was originally created?
If we have lazy exceptions, then knowing where the fault they represent was
detected is probably more important than were (exactly) it was triggered.
Or does this all amount to the same thing? Is an
Larry Wall wrote:
> eqv and === autothread just like any other comparisons. If you really
> want to compare the contents of two junctions, you have to use the
> results of some magical .eigenmumble method to return the contents
> as a non-junction. Possibly stringification will be sufficient, if
Andrew Whitworth via RT wrote:
On Tue Apr 22 10:05:57 2008, [EMAIL PROTECTED] wrote:
We've been kicking around the idea of removing new_from_string for a
while, but the pushback is always that it's useful to be able to create
a new PMC with some initialization data, without first creating a PMC
On Sunday 19 October 2008 14:02:58 Klaas-Jan Stol wrote:
> when running code as this:
> .sub main :immediate
> load_bytecode "foo.pir"
> .end
>
> (assuming you have a file 'foo.pir'), IMCC can't handle this.
>
> This is because in pbc.c, a global structure called 'globals' is used to
> allow the
Andrew Whitworth via RT wrote:
1) Rename this ticket to something more descriptive
2) Rename seatbelts.pod to something more descriptive, like
/docs/dev/C_Functions.pod or something.
3) Expand that documentation to include more cases (ARGIN, ARGMOD,
ARGOUT, all the *_NULLOK variants of those, et
On Monday 27 October 2008 09:14:32 Will Coleda wrote:
> While trying to duplicate the tcl segfault in PIR, I was able to
> generate PIR that reliably segfaulted; except it turned out it was
> segfaulting a different way:
>
> .sub '__onload' :immediate
> load_bytecode 'TGE.pbc'
> push_eh cl
46 matches
Mail list logo
