On Mon, 11 Dec 2017 20:30:18 -0800, c...@zoffix.com wrote:
> The form with space wasn't implemented.
>
> It is now: https://github.com/rakudo/rakudo/commit/c0f99a393b
Never mind. Decided to revert that form (
https://github.com/rakudo/rakudo/commit/2f955d55e3 )
The `:()` form is actually a Si
On Mon, 11 Dec 2017 20:30:18 -0800, c...@zoffix.com wrote:
> The form with space wasn't implemented.
>
> It is now: https://github.com/rakudo/rakudo/commit/c0f99a393b
Never mind. Decided to revert that form (
https://github.com/rakudo/rakudo/commit/2f955d55e3 )
The `:()` form is actually a Si
On Sat, 02 Dec 2017 05:19:45 -0800, alex.jakime...@gmail.com wrote:
> Yeah. It was resolved here I think: (2014-12-08)
> https://github.com/rakudo/rakudo/commit/fbc87d2a6bbfc4899b0740119ac8696cc27f1f59
>
> ｢testneeded｣
>
> On 2014-12-09 04:54:08, r...@hoelz.ro wrote:
> > On Sun Dec 07 07:41:52 20
On Sat, 02 Dec 2017 05:19:45 -0800, alex.jakime...@gmail.com wrote:
> Yeah. It was resolved here I think: (2014-12-08)
> https://github.com/rakudo/rakudo/commit/fbc87d2a6bbfc4899b0740119ac8696cc27f1f59
>
> ｢testneeded｣
>
> On 2014-12-09 04:54:08, r...@hoelz.ro wrote:
> > On Sun Dec 07 07:41:52 20
On 2017-12-11 5:21 PM, Sean McAfee wrote:
Well, /any/ function or operator that returns a boolean /could/ return a Failure
instead of (or in addition to) False to provide additional information to those
who want it, but if the condition is not really a Failure, wouldn't that be
misleading? Like
On Mon, Dec 11, 2017 at 3:01 PM, wrote:
>
> On 2017-12-11 12:22 PM, Sean McAfee wrote:
>
>> Well, not really. I don't think x %% 0 should return a Failure at all.
>>
>
> Is there a particular problem the current implementation fails to solve?
> In boolean
> context `x %% 0` *is* equivalent to Fa
# New Ticket Created by Timothy Smith
# Please include the string: [perl #132570]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132570 >
Save make-testcase.sh in /tmp, and:
rm -rf ./invalid-typename-bug; sh make-testcase.sh
On 2017-12-11 12:22 PM, Sean McAfee wrote:
Well, not really. I don't think x %% 0 should return a Failure at all.
Is there a particular problem the current implementation fails to
solve? In boolean
context `x %% 0` *is* equivalent to False. The Failure carries
additional information
to th
You might want to look at this discussion:
http://www.perlmonks.org/?node_id=87384
by the way it seems like the Intel enginners agree with Perl 6 semantics: a
modulo operation with MOD is undefined if the divisor is zero, with IDIV,
the instruction used by modern gcc, it is an exception (interrup
not what you think:
module operator in % in perl6 is defined as $b - $a * floor($b / $a)
On Mon, Dec 11, 2017 at 10:37 PM, Sean McAfee wrote:
> On Mon, Dec 11, 2017 at 12:56 PM, Darren Duncan
> wrote:
>
>> On 2017-12-11 12:22 PM, Sean McAfee wrote:
>>
>>> Well, not really. I don't think x %%
On Mon, Dec 11, 2017 at 12:56 PM, Darren Duncan
wrote:
> On 2017-12-11 12:22 PM, Sean McAfee wrote:
>
>> Well, not really. I don't think x %% 0 should return a Failure at all.
>>
>> 1 / 0 is an expression which can evaluate to no sensible value, so it
>> makes
>> sense to fail there. By the que
Putting aside the edge case of what to do when the divisor is zero, which could
also be tested for prior to attempting to call the operator:
An "is evenly divisible by" operator is an immensely useful one to have built-in
to the language; not only is "x %% y" much more direct to the real questi
I think that this stems from a confusion between the divisibility problem
in integer number (on a ring) and the divisibility problem resolved by the
perl6 %% operator.
Personally I think that %% is useless while the former is useful and
missing. But I have nothing against useless operators
On Mon
On 2017-12-11 12:22 PM, Sean McAfee wrote:
Well, not really. I don't think x %% 0 should return a Failure at all.
1 / 0 is an expression which can evaluate to no sensible value, so it makes
sense to fail there. By the question "Is one divisible by zero?" has the simple
answer "No."
I strongl
On Mon, Dec 11, 2017 at 1:52 AM, Elizabeth Mattijsen wrote:
> > On 11 Dec 2017, at 04:42, Sean McAfee wrote:
> > The docs say a %% b is True if a % b is 0, so the error is as-designed,
> at least. But mightn't it make more sense for %% to just return False when
> given a second zero operand? A
Closing this ticket in favor of this one:
https://github.com/rakudo/rakudo/issues/1304
On 2017-12-01 11:03:43, alex.jakime...@gmail.com wrote:
> Still failing (2017.11, HEAD(5929887))
>
> On 2014-07-31 13:05:19, david.warring wrote:
> > I've added some fudged tests to S03-operators/relational.t. A
Tests: https://github.com/perl6/roast/commit/786472ae43
Tests: https://github.com/rakudo/rakudo/commit/20d67a3d4d
Tests: https://github.com/rakudo/rakudo/commit/20d67a3d4d
On Mon, 23 Oct 2017 05:28:04 -0700, c...@zoffix.com wrote:
> This code produces an LTA error:
>
> my %days := SetHash.new: Date.today … Date.new: '2030-04-02';
> %days ∖= %days.grep: *.key.day-of-week > 5;
>
> First, the error reads "Cannot modify an immutable SetHash" which is
> confusing,
> sin
On Mon, 23 Oct 2017 05:28:04 -0700, c...@zoffix.com wrote:
> This code produces an LTA error:
>
> my %days := SetHash.new: Date.today … Date.new: '2030-04-02';
> %days ∖= %days.grep: *.key.day-of-week > 5;
>
> First, the error reads "Cannot modify an immutable SetHash" which is
> confusing,
> sin
On Fri, 29 Sep 2017 09:07:40 -0700, c...@zoffix.com wrote:
> - Seq.skip mutates the invocant:
No longer. It now consumes the iterator, which aligns the behaviour with
Any.skip.
Fixed by lizmat++ in https://github.com/rakudo/rakudo/commit/854c10c27e
Tests: https://github.com/perl6/roast/commit/49
On Fri, 29 Sep 2017 09:07:40 -0700, c...@zoffix.com wrote:
> - Seq.skip mutates the invocant:
No longer. It now consumes the iterator, which aligns the behaviour with
Any.skip.
Fixed by lizmat++ in https://github.com/rakudo/rakudo/commit/854c10c27e
Tests: https://github.com/perl6/roast/commit/49
Recommend merging with RT 125398 - "no strict temp does not autcreate hashes
and hash elements"
Also seems fixed by e5b49ce and could be expected to share same cause of
"...the underlying issue is that the default value of container descriptors
created automatically with “no strict” are Mu rath
Fixed in
https://github.com/rakudo/rakudo/commit/2cd266fe08aa386b180dda14c15659c360623c99
Tests in
https://github.com/perl6/roast/commit/3ae26405385d5e496b401326e3252294b8a5785b
and
https://github.com/perl6/roast/commit/bc48eed6849cbbb873320052cb78a6e57b9c4a2a
tbrowder++
On 2015-11-26 11:33:47,
> On 11 Dec 2017, at 04:42, Sean McAfee wrote:
>
> I think of %% as being Perl 6's is-divisible-by operator, so I was a little
> surprised to discover this behavior:
>
> > 1 %% 0
> Attempt to divide 1 by zero using infix:<%%>
> in block at line 1
>
> The docs say a %% b is True if a % b i
26 matches
Mail list logo
