[perl #125026] [REGEX] Test in S05-modifier/counted-match.t fails: .match with adverb :nth(2, 4 ... *)
These tests were changed with https://github.com/perl6/roast/commit/9a266114ab (and they are passing now). I'm closing this ticket as 'resolved'.
[perl #125815] [JVM] :nth(-666) is intended to die, but it does not
All the tests fudged with this ticket number are passing now: https://github.com/perl6/roast/commit/8d39a9b0c86c21901824716398f74b3ab4016733 I'm closing this ticket as 'resolved'.
[perl #129956] [BUG] Inconsistent behavior of .Int
Actually, this is a better version, since it takes care to not consider, say,
4.4 as a Int:
given quietly val prompt('int: ') || NaN {
when Int { say "you just entered the integer $_"; }
default { say "that was totally not an integer" }
}
On Tue Oct 25 10:15:56 2016, c...@zoffix.com wrote:
> Thanks for the report,
>
> First to clarify: Nil.Int is *not* an error as you state, it's a
> warning and you can suppress it with `quietly` block. A numeric Nil is
> 0, which is what you get in return.
>
> As for the problem you're trying to solve, you can use the following
> code. If a Nil is returned from
> prompt(), the `//` operator will change it to a `NaN`. Attempting to
> coerce a NaN to a Nil is a Failure,
> and so the `when Int` block won't match it.
>
> given (prompt('int: ')//'NaN').Int {
>when Int { say "you just entered the integer $_" }
>default { say "that was totally not an integer" }
> }
>
> There's also val() routine: https://docs.perl6.org/routine/val with a
> caveat that an empty string is 0.
>
> With that said, there's no bug here, so I'm rejecting the ticket.
>
> Thanks,
> ZZ
>
>
> On Mon Oct 24 08:19:21 2016, jkra...@mark17.net wrote:
> > For most (all I've tested) types the method .Int works pretty much
> > the
> > same and as I'd expect: it either returns an Int or, if not possible
> > because the invocant can't be converted to Int in a useful way or the
> > invocant is not defined, it throws an exception. However Cool and
> > classes that inherit from it and don't override the .Int method
> > (namely
> > Nil) behave differently in a potential harmful way: instead of
> > throwing
> > an exception, .Int here prints an error and returns 0. The problem
> > with
> > this is a) I can't check if a problem occured with try/CATCH, b) I
> > can't
> > check if the conversion succeeded by checking the return value, since
> > 0
> > is a valid and defined Int and c) it's very inconsistent with other
> > types and makes me have to write extra checks prior to calling .Int.
> > Random example:
> >
> >
> > given try prompt('int: ').Int {
> > when Int { say "you just entered the integer $_" }
> > default { say "that was totally not an integer" }
> > }
> >
> >
> > This would normally allow me to prompt for a number and easily check
> > if
> > the input indeed was a valid number. The only problem is Nil
> > (returned
> > by prompt in case of EOF), which becomes 0, which is rather
> > unexpected
> > behavior in my opinion.
> >
> > Also finally, since .Int on Nil/Cool:U is already printing an error,
> > I
> > think it's obvious that calling .Int on them indeed *is* an error, so
> > instead of printing that but continuing normally by returning 0 it
> > should actually behave like there was an error, i.e. throw and
> > exception
> > so the programmer can deal with it using regular control flow
> > (try/CATCH) and not make guesses about whether the invocant contained
> > some value that was successfully converted to 0 or if the conversion
> > failed.
[perl #129956] [BUG] Inconsistent behavior of .Int
Thanks for the report,
First to clarify: Nil.Int is *not* an error as you state, it's a warning and
you can suppress it with `quietly` block. A numeric Nil is 0, which is what you
get in return.
As for the problem you're trying to solve, you can use the following code. If a
Nil is returned from
prompt(), the `//` operator will change it to a `NaN`. Attempting to coerce a
NaN to a Nil is a Failure,
and so the `when Int` block won't match it.
given (prompt('int: ')//'NaN').Int {
when Int { say "you just entered the integer $_" }
default { say "that was totally not an integer" }
}
There's also val() routine: https://docs.perl6.org/routine/val with a caveat
that an empty string is 0.
With that said, there's no bug here, so I'm rejecting the ticket.
Thanks,
ZZ
On Mon Oct 24 08:19:21 2016, jkra...@mark17.net wrote:
> For most (all I've tested) types the method .Int works pretty much the
> same and as I'd expect: it either returns an Int or, if not possible
> because the invocant can't be converted to Int in a useful way or the
> invocant is not defined, it throws an exception. However Cool and
> classes that inherit from it and don't override the .Int method (namely
> Nil) behave differently in a potential harmful way: instead of throwing
> an exception, .Int here prints an error and returns 0. The problem with
> this is a) I can't check if a problem occured with try/CATCH, b) I can't
> check if the conversion succeeded by checking the return value, since 0
> is a valid and defined Int and c) it's very inconsistent with other
> types and makes me have to write extra checks prior to calling .Int.
> Random example:
>
>
> given try prompt('int: ').Int {
> when Int { say "you just entered the integer $_" }
> default { say "that was totally not an integer" }
> }
>
>
> This would normally allow me to prompt for a number and easily check if
> the input indeed was a valid number. The only problem is Nil (returned
> by prompt in case of EOF), which becomes 0, which is rather unexpected
> behavior in my opinion.
>
> Also finally, since .Int on Nil/Cool:U is already printing an error, I
> think it's obvious that calling .Int on them indeed *is* an error, so
> instead of printing that but continuing normally by returning 0 it
> should actually behave like there was an error, i.e. throw and exception
> so the programmer can deal with it using regular control flow
> (try/CATCH) and not make guesses about whether the invocant contained
> some value that was successfully converted to 0 or if the conversion
> failed.
[perl #127305] EXPORT ignored when unit module/package is used
In a conversation about this issue on IRC channel #perl6 on 25 Oct 2016 starting at approx 06:24, module authors and users express concern about modules polluting the user's namespace. Several main desires IMHO: User: 1. Selective import by object name(s) or tag(s). 2. Selective import by excluding object name(s) or tag(s) [perlpilot]. Author: 1. Tagging or otherwise marking subs to enable the user desires above. 2. Enable multiple export tags to better organize export categories.
