[perl #124455] substr on compact array
3 tests here that need fixing or review:
my uint8 @buffer = ('A' .. 'Z').map({ .ord });
is(substr(@buffer, 0, 8), ord('A'), 'substr on compact array (1)');
is(substr(@buffer, 200, 8), ord('Z'), 'substr on compact array (2)');
is(
substr(@buffer, 0, 16),
sprintf('%08d%08d', ord('A'), ord('B')),
'substr on compacy array (3)'
);
yields:
# Failed test 'substr on compact array (1)'
# at t/spec/S02-types/compact.rakudo.moar line 14
# expected: '65'
# got: '65 66 67'
# Failed test 'substr on compact array (2)'
# at t/spec/S02-types/compact.rakudo.moar line 15
# expected: '90'
# got: (Failure)
# Failed test 'substr on compacy array (3)'
# at t/spec/S02-types/compact.rakudo.moar line 16
# expected: '00650066'
# got: '65 66 67 68 69 7'
--
Will Coke Coleda
[perl #125165] samemark NYI
# New Ticket Created by Will Coleda # Please include the string: [perl #125165] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=125165 from S32-setting-library/Str.pod some (old) tests in S32-str/samemark.t -- Will Coke Coleda
Re: Can a user cheat and call a class's private method?
On Mon, May 11, 2015 at 03:22:46PM -0700, Darren Duncan wrote: you can use trusts. Also having to do this may indicate bad code design. -- Darren Duncan I saw Moritz' and Carl's responses and I agree with the smell issue. Given that the code exists and needs testing, 'augment' seems preferable to 'trust'. 'augment' avoids the predeclaration issue and simplifies the test code by removing indirection. Is class finalization implemented? Searching the synopses, I found only a mention.
Re: Can a user cheat and call a class's private method?
On 2015-05-12 12:40 PM, R. Ransbottom wrote: On Mon, May 11, 2015 at 03:22:46PM -0700, Darren Duncan wrote: you can use trusts. Also having to do this may indicate bad code design. -- Darren Duncan I saw Moritz' and Carl's responses and I agree with the smell issue. Given that the code exists and needs testing, 'augment' seems preferable to 'trust'. 'augment' avoids the predeclaration issue and simplifies the test code by removing indirection. Is class finalization implemented? Searching the synopses, I found only a mention. The other question is whether your private need to be private. Generally speaking tests should only be against a public interface, and if you really need to test something private then maybe a refactoring of the thing being tested is in order. For example splitting it into multiple classes where what was private becomes the public API of a utility consumed by the other class. Any private routines you should be able to test sufficiently indirectly by way of public routines that use them, if the code is well organized. -- Darren Duncan
Re: Can a user cheat and call a class's private method?
Hi, On 05/12/2015 09:40 PM, R. Ransbottom wrote: On Mon, May 11, 2015 at 03:22:46PM -0700, Darren Duncan wrote: you can use trusts. Also having to do this may indicate bad code design. -- Darren Duncan I saw Moritz' and Carl's responses and I agree with the smell issue. Given that the code exists and needs testing, I'm curious, what's a case where private state of a class needs to be tested, and tests agains the public interface are not enough? In my experience, testing against private parts only makes the tests more brittle (that is, every implementation change causes test failures, even if the public interface is unchanged). Also, are you talking about an actual Perl 6 code base that needs testing, but that is too large for a refactoring? If yes, I'd be curious where such a beast exists. Is class finalization implemented? I don't think so. Cheers, Moritz
[perl #125161] [BUG] failure in launching promises in an array
# New Ticket Created by grond...@yahoo.fr
# Please include the string: [perl #125161]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=125161
Hi,
$ perl6 --version
This is perl6 version 2015.04-199-ge82920a built on MoarVM version
2015.04-62-g052aca0
$ perl6 -e 'perl6 -e 'my @p = map { start { my @a = [ rand xx 1_000 ];
@a } }, ^10; for @p { die oops unless .result }'
Amazingly enough, this fails undeterministically with various error
messages. Or sometimes it just die with oops (which is not good
either).
An example of failure is:
===SORRY!===
Cannot call prefix:--(Int); none of these signatures match:
(Mu:D \a is rw)
(Mu:U \a is rw)
(Bool:U \a is rw)
(Int:D $a is rw)
(int $a is rw)
(Num:D $a is rw)
(Num:U $a is rw)
(num $a is rw)
[perl #125155] [BUG] Blocks can't curry
# New Ticket Created by Justin DeVuyst
# Please include the string: [perl #125155]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=125155
This is a spin off from RT #77520.
There is a test in S06-currying/assuming-and-mmd.t
and here's an example:
[jdv@wieldy rakudo]$ perl6 -e 'say { $^x }.assuming(1).()'
Method 'assuming' not found for invocant of class 'Block'
in block unit at -e:1
[jdv@wieldy rakudo]$
[perl #62086] ~ in regexes shouldn't cause thrown exceptions
On Mon May 11 05:26:45 2015, pmichaud wrote: After discussion with jnthn at OSDC.no, here's what we propose: In the regex engine, the default FAILGOAL behavior should be to simply fail/backtrack. This would be the default behavior for (rakudo) Cursor as well. Grammars that wish to have the generate-an-exception behavior can override FAILGOAL to do so. The HLL::Grammar class (in NQP) will do this, meaning that Rakudo's grammar will still inherit/retain the throw-an-exception behavior. Part of our reasoning (which may be faulty) for this approach is that it's relatively easy to override FAILGOAL in a grammar but harder to do so for regexes that aren't in a grammar. In the latter case (regex), it's more likely that you want simple backtracking rather than the throw an error message, so that should be the default. This sounds very sane. +1
