MasterDuke just throwing a thought out there, what would people think about an option to contains() to make it case-insensitive? 00:19
Zoffix MasterDuke, -1 from me on account we already have .match for that. 00:23
m: "Hello, World".match(:i, 'hello').say 00:24
camelia rakudo-moar 2dd0dd: OUTPUT«Nil␤»
Zoffix or do we...
s: 'foo', 'match'
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2dd0...tr.pm#L417
Zoffix ah
m: "Hello, World".match(rx:i/'hello'/).say
camelia rakudo-moar 2dd0dd: OUTPUT«｢Hello｣␤»
MasterDuke hm, it isn't in the docs 00:25
Zoffix Yeah, github.com/perl6/doc/issues/919
MasterDuke, and lizmat++ is currently rewamping it, so I wouldn't doc it until she's done polishing it 00:26
So to me .contains('xxx') means "contains this exact thing". Once we start going into fuzzy matches, .match is a good tool. 00:27
s: '', 'contains'
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2dd0...ol.pm#L145
Zoffix s: 'x', 'contains'
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2dd0...ol.pm#L145
Zoffix s: 'x', 'contains', \('x')
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2dd0...tr.pm#L115
Zoffix and it's just a couple of nqp ops. 00:28
MasterDuke well, it woudn't be many more ops, just adding something like: nqp::if($case-insensitive,nqp::isne_i(nqp::index(nqp::lc($!value),nqp::lc(nqp::getattr($needle,Str,'$!value')),0),-1 )),... 00:36
Zoffix I'd go with another multi, but my -1 is based on the fact that there's already a method for what you want. We'd be just converting one to another. Why not add :ignoremark next? 00:38
In an alternate universe, I'd just have one method in total: .matches() 00:39
MasterDuke i share a similar sentiment, but we do also optimize for common cases 00:40
Zoffix with case insensitivity, it no longer `.contains` a thing, it `.match`es the $needle case-insensitively :)
MasterDuke i'm just thinking that a case-insenstive contains() is a pretty common thing people want to do 00:41
arguable not as frequently as a case-sensitive contains(), so maybe it shouldn't be added
but it would be interesting to see the code that people have written already 00:42
Zoffix m: dd 'FooBar'.lc.contains: 'foobar'
camelia rakudo-moar 2dd0dd: OUTPUT«Bool::True␤»
Zoffix m: dd 'FooBar'.fc.contains: 'foobar'.fc
camelia rakudo-moar 2dd0dd: OUTPUT«Bool::True␤»
Zoffix Prolly same typing as the extra arguments
MasterDuke 'FooBar'.icontains: 'foobar' is shorter 00:43
Zoffix oh god :)
MasterDuke 'FooBar'.contains: 'foobar', :i is shorter
Zoffix I know Larry says we took nothing from PHP, but I say we should. The ridiculous name proliferation. 00:44
errr
I mean, we should learn a lesson ^_^
So I guess Larry is right, we take nothing 00:45
MasterDuke, my view on things like this: it's easy to add things, but nearly impossible to remove. The more things you have the more bugs you have, the larger is your maintenance burder, and the harder it is for people to learn and understand the language. 00:46
ShimmerFairy If you want case-insensitive comparisons, you should be using .fc already. (I'd argue the :i for regexes exist because it's basically the Regex lang's .fc :P)
Zoffix MasterDuke, and I obtained this view after writing thousands of lines of code for Perl 5's App::ZofCMS, where each plugin can be called in a whole bunch of different ways "just cause someone might find it easier" and I ended up with miles of docs and hairy interface. 00:47
m: use Test; is-deeply NaN, NaN;
camelia rakudo-moar 2dd0dd: OUTPUT«not ok 1 - ␤␤# Failed test at <tmp> line 1␤# expected: NaN␤# got: NaN␤»
Zoffix ^ there's an easy fix for that, but I decided not to add it. More code to maintain. Possibility of adding more bugs. Etc. There's already a way to do such a test. 00:48
AlexDaniel Zoffix: sure, you are right. But I don't think this argument works well here. TIMTOWTDI? ;) 00:49
ShimmerFairy Zoffix: you could also argue that there's nothing to fix there; of course NaN isn't NaN, not even deeply! :)
MasterDuke i'm just thinking there's probably lots of /:i 'text' / and $foo.fc.contains($bar.fc) floating around
Zoffix m: [].^find_method('splice').candidates.elems.say
camelia rakudo-moar 2dd0dd: OUTPUT«31␤»
AlexDaniel /o\
that's different 00:50
Zoffix ^ and another victim of adding all sorts of arguments.
MasterDuke or as ShimmerFairy pointed out, even worse there's probably lots of $foo.lc.contains($bar.lc)
Zoffix That's not different.
Someone said "hey, let's make Whatever mean end of list".
Then someone said "hey, let's make it take a Callable too, maybe there's lots of [].splice: sub {...}(...)" 00:51
ShimmerFairy
.oO(some verbs are bound to have dozens of meanings; cf. English)
 00:52
AlexDaniel one more named arg to guide people away from accidentally using .lc for case insensetive comparisons does not sound like a bad idea at all.
Zoffix So we can slowly grow .contains to do the same thing as .match and write pages of code and miles of docs and at the end we'll have two confusing methods that do nearly the same thing and a dozen candidates 'cause we optimized the hell out of it, to maintain the original performance of .contains
Zoffix & # Starcraft o/ 00:53
AlexDaniel well, whatever. Just don't accidentally turn perl 6 into python please :)
ShimmerFairy I personally think adding case-insensitivity to .contains shouldn't be necessary.
AlexDaniel: just one use Python; and it's already too late!! 00:54
MasterDuke ShimmerFairy: what do you mean "shouldn't be necessary"?
people should always be explicit about their comparison you mean? 00:56
ShimmerFairy MasterDuke: I'm just not convinced it's necessary. If you want to handle your strings case-insensitively, you should be using .fc already (or an /:i .../ regex if you prefer)
that is, I don't see people often getting to .contains and thinking "gee, if only it would compare things ignoring case", because "ignoring case" is a problem you likely needed to solve already :) 00:58
Also, typing .fc isn't really bad at all, and it keeps the case problem separate from the "find this" problem, among other string operations. 00:59
MasterDuke well, i did in fact happen to think pretty much exactly that a couple minutes ago
i agree that .fc isn't really all that bad 01:00
but you have to do it twice (i.e., $str.fc and $needle.fc) compared to once in (hypothetical) contains 01:01
ShimmerFairy Another idea is to have some kind of IStr module or something that gives people an inherently case-insensitive string. Now you don't have to make a bunch of different methods concern themselves with some kind of :i switch! :)
MasterDuke now that's a fun idea
ShimmerFairy That IStr idea, in my mind, would be similar to NFC, NFD, etc. strings, in that it's a better solution than making everything handle :nfc or :nfkd adverbs. 01:02
Zoffix Thinking more of it, the .splice is the perfect case study for the effects of "featuritis". Because starting from the point where [some] combination of Int:D|Whatever|Callable for arguments was conceived, the candidate list first grew due to optimizations, then it grew again due to bugs with candidates that caused infinihangs, and the last growth spurt was due to inconsistency in the interface where it was easier to add a couple of extra 01:07
candidates than try and explain all of the acceptable permutations of arguments.
And alongside .contains you have .starts-with and .ends-with. So if you're adding something to .contains, you have to think of those two, or you'll have users accidentally sticking an :i to .starts-with and it would be silently ignored.
m: 'foo'.match('foo').say 01:08
camelia rakudo-moar 2dd0dd: OUTPUT«｢foo｣␤»
Zoffix .tell lizmat something for you to consider in your .match rework: adding an `:i` (case-insensitive) to .match() so it could be easily used with Str matchers, like: m: 'foo'.match('foo').say. See discussion about it adding such a thing to .contains() in irclog.perlgeek.de/perl6-dev/2016-...i_13414077 but IMO it's .match that has all the bells and whistles, so maybe it's OK to add such a bell to it. 01:10
yoleaux2 Zoffix: I'll pass your message to lizmat.
Zoffix s: 'foo', 'match', \('foo') 01:11
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2dd0...tr.pm#L417
MasterDuke that's a good idea also/instead 01:12
Zoffix And then we get it for free in .subst/.subst-mutate too, 'cause they use .match under the hood 01:14
gfldex m: my \li = <a b c>; for my li {} 01:39
camelia rakudo-moar 2dd0dd: OUTPUT«===SORRY!===␤No compile-time value for li␤»
gfldex ^^^ wee bit LTA. It's a redeclaration and we tend to complain as such. 01:40
ShimmerFairy m: my li; 02:03
camelia rakudo-moar 2dd0dd: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Malformed my (did you mean to declare a sigilless \li or $li?)␤at <tmp>:1␤------> my li⏏;␤»
ShimmerFairy gfldex: ^^^ that shouldn't work in general, though the message is still a wee bit LTA :)
japhb .ask jnthn Does OO::Monitors still need to be 'no precompilation'? It tends to be used deep enough in module use trees that the infectiousness of 'no precompilation' is brutal for startup times. 03:14
yoleaux2 japhb: I'll pass your message to jnthn.
[Tux] This is Rakudo version 2016.10-7-g2dd0ddb built on MoarVM version 2016.10-5-g3f1ef57 06:18
csv-ip5xs 3.379
test 15.840
test-t 7.019
csv-parser 17.279
bartolin_ .tell Zoffix wrt NaN**0 returning 1 there was RT #124450 07:33
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124450
yoleaux2 bartolin_: I'll pass your message to Zoffix.
FROGGS jnthn: hi, I'm trying to implement &.a:(Int --> Str) - gist.github.com/FROGGS/b49225ac2e4...a12f2600b9 08:45
jnthn: and now I'm asking... what should it do in the end? 08:46
I think it should:
a) attach the signature as a trait
b) which means we can use it for nativecall
c) which will mean that if you assign a codeblock/subroutine reference to it, then its signature gets checked 08:47
right?
jnthn FROGGS: Well, c alone would be achievable by having it added as if it were a where clause 08:53
yoleaux2 03:14Z <japhb> jnthn: Does OO::Monitors still need to be 'no precompilation'? It tends to be used deep enough in module use trees that the infectiousness of 'no precompilation' is brutal for startup times.
jnthn FROGGS: But that doesn't answer the introspection question 08:54
FROGGS jnthn: maybe I should look at what params do?
jnthn Yeah, but I think they "cheat" in some way 08:55
If we want this to generalize nicely, then it's probably best to handle it in metaspace
FROGGS m: sub foo(&a:(Int --> Str)) { say &a }; foo(-> Num { })
camelia rakudo-moar 2dd0dd: OUTPUT«Constraint type check failed for parameter '&a'␤ in sub foo at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
FROGGS m: sub foo(&a:(Int --> Str)) { say &a }; foo(-> Int --> Str { }) 08:56
camelia rakudo-moar 2dd0dd: OUTPUT«-> Int $ --> Str { #`(Block|80443168) ... }␤»
jnthn m: my &a:(Int --> Str) = sub (Int $x --> Str) {}
camelia rakudo-moar 2dd0dd: OUTPUT«===SORRY!=== Error while compiling <tmp>␤You can't adverb &a␤at <tmp>:1␤------> my &a:(Int --> Str)⏏ = sub (Int $x --> Str) {}␤»
jnthn Oops :) 08:57
FROGGS :o)
it does not bail out using my patch, but it does not do anything with &a yet 08:58
jnthn m: subset Callable of :(Int --> Str)
camelia rakudo-moar 2dd0dd: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Malformed trait␤at <tmp>:1␤------> subset Callable of⏏ :(Int --> Str)␤»
jnthn gah, not enough coffee
FROGGS heh
jnthn m: subset Thingy of Callable where :(Int --> Str)
camelia ( no output )
jnthn m: subset Thingy of Callable where :(Int --> Str); say Thingy.^refineee
camelia rakudo-moar 2dd0dd: OUTPUT«No such method 'refineee' for invocant of type 'Perl6::Metamodel::SubsetHOW'␤ in block <unit> at <tmp> line 1␤␤»
jnthn m: subset Thingy of Callable where :(Int --> Str); say Thingy.^refinee
camelia rakudo-moar 2dd0dd: OUTPUT«(Callable)␤»
jnthn m: subset Thingy of Callable where :(Int --> Str); say Thingy.^refinement
camelia rakudo-moar 2dd0dd: OUTPUT«-> ;; $_ { #`(Block|51432080) ... }␤»
FROGGS ahh 08:59
jnthn Yeah, it compiles it into a Block
that presumably smart-matches
m: subset Thingy of Callable where 42; say Thingy.^refinement
camelia rakudo-moar 2dd0dd: OUTPUT«-> ;; $_ { #`(Block|80755656) ... }␤»
jnthn Always, it seems
FROGGS m: subset Thingy of Callable where :(Int --> Str); say :(Int --> Str) ~~ Thingy
camelia rakudo-moar 2dd0dd: OUTPUT«False␤»
jnthn A Signature isn't Callable 09:00
m: subset Thingy of Callable where :(Int --> Str); say sub (Int --> Str {} ~~ Thingy
camelia rakudo-moar 2dd0dd: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Missing block␤at <tmp>:1␤------> re :(Int --> Str); say sub (Int --> Str ⏏{} ~~ Thingy␤»
jnthn m: subset Thingy of Callable where :(Int --> Str); say sub (Int --> Str) {} ~~ Thingy
camelia rakudo-moar 2dd0dd: OUTPUT«False␤»
FROGGS m: subset Thingy of Callable where :(Int --> Str); sub foo(Thingy $a) { say $a }; foo(-> Int --> Str { })
camelia rakudo-moar 2dd0dd: OUTPUT«Constraint type check failed for parameter '$a'␤ in sub foo at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
jnthn hmm, what's up with that... 09:01
m: say -> Int --> Str { } ~~ :(Int --> Str)
camelia rakudo-moar 2dd0dd: OUTPUT«False␤»
jnthn m: say (-> Int --> Str { }).signature ~~ :(Int --> Str) 09:02
camelia rakudo-moar 2dd0dd: OUTPUT«True␤»
FROGGS ahh
jnthn Hm, maybe I'm misremembering the smartmatch table. Or maybe Rakudo is ;)
One way to go, though, might be to have a subclass of SubsetHOW like SignatureCheckHOW or something 09:04
And it has a .signature property
And then we can distinguish things that were actually written using the &.a:(...) style forms
.HOW ~~ Metamodel::SignatureHOW or so 09:05
(on the type)
FROGGS yeah
jnthn That would generalize nicely over vars/attrs/params 09:06
.tell japhb I haven't knowingly fixed that...agree it'd be nice to deal with. 09:12
yoleaux2 jnthn: I'll pass your message to japhb.
|Tux| Test::META misses the fact that the test suite itself now depends on Test::META : it shall either be added to META6.json of explicitely be ignored when not available 09:24
Oops. When I make travis require Test::META, travis fails: s3.amazonaws.com/archive.travis-ci...91/log.txt 09:57
Zoffix bartolin_, interesting.... And Perl 5 does give a NaN for NaN**0.... That leaves the 1**NaN case. Is that also IEEE? Perl 5 gives 1 10:06
yoleaux2 07:33Z <bartolin_> Zoffix: wrt NaN**0 returning 1 there was RT #124450
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124450
timotimo perl6 doesn't give a namn. 10:07
Zoffix ? 10:09
timotimo just a pun
lizmat . 10:54
yoleaux2 01:10Z <Zoffix> lizmat: something for you to consider in your .match rework: adding an `:i` (case-insensitive) to .match() so it could be easily used with Str matchers, like: m: 'foo'.match('foo').say. See discussion about it adding such a thing to .contains() in irclog.perlgeek.de/perl6-dev/2016-...i_13414077 but IMO it's .match that has all the bells and whistles, so maybe it's OK to add such a bell to it.
lizmat m: 'foo'.match('foo').say 10:55
camelia rakudo-moar 2dd0dd: OUTPUT«｢foo｣␤»
Zoffix So it'd be like... m: 'Foo'.match(:i, 'foo').say; and it'd match Foo 11:00
s: 'foo', 'match', \('foo') 11:02
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/2dd0...tr.pm#L417
timotimo don't forget to also allow :m 11:03
iBakeCake m: say sqrt ∞ 12:21
camelia rakudo-moar 2dd0dd: OUTPUT«Inf␤»
iBakeCake m: say 1/sqrt ∞
camelia rakudo-moar 2dd0dd: OUTPUT«0␤»
iBakeCake pown (x, 0) is 1 for any x (even a zero, quiet NaN, or infinity) 12:22
pow (+1, y) is 1 for any y (even a quiet NaN)
That's straight from 2008 IEEE 754, so I'm rejecting rt.perl.org/Public/Bug/Display.html?id=129894
s/pown/pow/ # too 12:25
.oO( p0wned )
dalek ast: a8381de | (Zoffix Znet)++ | S02-types/num.t:
Remove fudge and test nummy 1**NaN NaN**0

Remove fudge for RT#129894[^1], as it was rejected.
2008 IEEE 754, section "9.2.1 Special values" explicitly states:
   pow (x, ±0) is 1 for any x (even a zero, quiet NaN, or infinity)
   pow (+1, y) is 1 for any y (even a quiet NaN)
Test that behaviour for infix:<**>(num, num)
feb9a69 | (Zoffix Znet)++ | S02-types/num.t: Fix typoed operator in tests' description		 12:32
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129894
iBakeCake m: say log 0 12:47
camelia rakudo-moar 2dd0dd: OUTPUT«-Inf␤»
iBakeCake From IEEE I see that should be a DivideByZero exception :\
.oO( Math is hard; let's go shopping )
 12:48
Apparently that was already a bug in 2008 that was fixed :) rt.perl.org/Ticket/Display.html?id=60490 12:51
ilmari m: say log -0e0 12:56
camelia rakudo-moar 2dd0dd: OUTPUT«-Inf␤»
iBakeCake It all comes down to nqp::log_n() eventually 12:57
for natives too
m: say atanh 1 13:11
camelia rakudo-moar 2dd0dd: OUTPUT«Attempt to divide 2 by zero using /␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake hehehe :) 13:12
.tell Zoffix check the atanh 1 shows up on RT 13:29
yoleaux2 iBakeCake: I'll pass your message to Zoffix.
lizmat m: my $a = ":i foo"; say "FOO" ~~ m/$a/ # how can make this work ? 13:39
camelia rakudo-moar 2dd0dd: OUTPUT«False␤»
iBakeCake m: my $a = ":i foo"; say "FOO" ~~ m/<$a>/ 13:40
camelia rakudo-moar 2dd0dd: OUTPUT«｢FOO｣␤»
lizmat aha... ok, thanks
jnthn injection alert :) 13:44
lizmat yeah, and that :-)
jnthn: so what do you think about allowing Str.match(Str:D :i,:s,and friends) ? 13:45
iBakeCake Of note, such additions will also become available in subst/subst-mutate, because options get propagated to Str.match 13:47
jnthn lizmat: :i and :m sound sensible at least 13:49
lizmat ok, will look at it further then 13:50
iBakeCake: fwiw, I think subst/subst-mutate need a re-factor in and of themselces
themselves, but that's for later :-)
iBakeCake m: acotanh 0 13:52
camelia rakudo-moar 2dd0dd: OUTPUT«WARNINGS for <tmp>:␤Useless use of "acotanh 0" in expression "acotanh 0" in sink context (line 1)␤Attempt to divide 1 by zero using /␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake Hmmm.. There's a whole ton of these, with LTA errors. 13:53
I was thinking of adding 'nuther candidates for throwing good errors.
m: multi acotanh (0) { 'throw zero' }; say acotanh 0; say acotanh 1 13:54
camelia rakudo-moar 2dd0dd: OUTPUT«throw zero␤Attempt to divide 2 by zero using /␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake m: &acotanh.candidates».signatures.say 13:55
camelia rakudo-moar 2dd0dd: OUTPUT«No such method 'signatures' for invocant of type 'Sub'␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake Fine! Be that way.
m: &acotanh.candidates.».signature.say 13:56
camelia rakudo-moar 2dd0dd: OUTPUT«((Numeric \x) (Cool \x) (num $x --> num))␤»
iBakeCake weird my multi isn't being called :/
m: multi foo (Numeric \x) { 'here' }; multi foo (Cool \x) { 'there' }; multi foo (num $x --> num) { 'and here' }; multi foo (0) { 'correct!' }; say foo 0 13:57
camelia rakudo-moar 2dd0dd: OUTPUT«correct!␤»
iBakeCake dafuq 13:58
Oh, acotanh 1 also throws :P
m: multi acotanh (0) { 'throw zero' }; say acotanh 0; say acotanh 2
camelia rakudo-moar 2dd0dd: OUTPUT«throw zero␤0.549306144334055␤»
iBakeCake So basically all the bad cases would have multies like that. 13:59
Maybe not worth it. There's a gazillion of trig functions like that in Complex and Num... lots of extra candidates 14:00
lizmat m: say "1234567890".match(/./,:nth(1,2,-3,7)) # do we consider this correct behaviour? 14:08
camelia rakudo-moar 2dd0dd: OUTPUT«(｢1｣ ｢2｣ ｢7｣)␤»
lizmat if not, what should it be? throw on the -3 ?
ilmari m: say "1234567890".match(/./,:nth(1,2,7,7)) 14:09
camelia rakudo-moar 2dd0dd: OUTPUT«(｢1｣ ｢2｣ ｢7｣)␤»
ilmari m: say "1234567890".match(/./,:nth(1,2,-4,7))
camelia rakudo-moar 2dd0dd: OUTPUT«(｢1｣ ｢2｣ ｢7｣)␤»
iBakeCake m: say "1234567890".match(/./,:nth(1,2,-4,700000)) 14:10
camelia rakudo-moar 2dd0dd: OUTPUT«()␤»
iBakeCake thinks throwing is good
It fails to match for nth that aren't in there, and negatives will never succeed a match, so user probably didn't mean for them to be in the list 14:11
m: say "1234567890".match(/./,:nth(1,2,-4,∞,NaN)) 14:12
camelia rakudo-moar 2dd0dd: OUTPUT«()␤»
iBakeCake hmm
ilmari m: say "1234567890".match(/./,:nth(*)) 14:13
camelia rakudo-moar 2dd0dd: OUTPUT«｢0｣␤»
ilmari m: say "1234567890".match(/./,:nth(*-1))
camelia rakudo-moar 2dd0dd: OUTPUT«｢9｣␤»
iBakeCake m: say "1234567890".match(/./,:nth(π)) 14:14
camelia rakudo-moar 2dd0dd: OUTPUT«False␤»
iBakeCake m: say "1234567890".match(/./,:nth(π, τ))
camelia rakudo-moar 2dd0dd: OUTPUT«()␤»
timotimo a QA tester comes into a bar. orders π drinks ...
iBakeCake m: say (^20)[π, τ, *-1, 700000] 14:15
camelia rakudo-moar 2dd0dd: OUTPUT«Index out of range. Is: 700000, should be in 0..19␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake m: say (^20)[π, τ, *-1, 19]
camelia rakudo-moar 2dd0dd: OUTPUT«(3 6 19 19)␤»
iBakeCake m: say (^20)[-1, π, τ, *-1, 19]
camelia rakudo-moar 2dd0dd: OUTPUT«Index out of range. Is: -1, should be in 0..19␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake Maybe there can be parallels drawn to this? To how we treat indexes in an array? 14:16
And so just return empty list if any of nth is negative, just as asking for too many nth gives empty list. And non-ints get thought of as ints? 14:17
m: say "1234567890".match(/./,:nth(' ', ' 2', '5')) 14:19
camelia rakudo-moar 2dd0dd: OUTPUT«Attempt to retrieve before :1st match -- :nth( )␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake oh 14:20
m: say "1234567890".match(/./,:nth(-1, ' 2', '5'))
camelia rakudo-moar 2dd0dd: OUTPUT«Attempt to retrieve before :1st match -- :nth(-1)␤ in block <unit> at <tmp> line 1␤␤»
perlpilot I can deal with non-Int converting to Int, but returning nothing if any is negative seems a little much.
iBakeCake lizmat: ^ looks like there's already an exeption in there
iBakeCake recalls the "monotoically increasing" convo 14:22
m: say "1234567890".match(/./,:nth(1,4,3))
camelia rakudo-moar 2dd0dd: OUTPUT«(｢1｣ ｢4｣)␤»
iBakeCake "<TimToady> simply ignoring the non-monotonic values is LTA though" irclog.perlgeek.de/perl6-dev/2016-...i_13385159 14:24
So the <= 0 will fall under whatever mechanism doesn't ignore non-monotonic values and if it's the first in the list, you get the above exception
m: say "1234567890".match(/./,:nth(-1)); CATCH { default { .^name.say } } 14:25
camelia rakudo-moar 2dd0dd: OUTPUT«X::AdHoc␤»
iBakeCake bah
iBakeCake &
lizmat fwiw, I'm about to allow for non-monotonic index values, as there is little extra effort invlved 14:42
(apart from the bike-shedding here :-) 14:43
iBakeCake So for nqp::log_n we just bind to VM functions and it's them that return -Inf
lizmat: then probably throwing on <= 0 items, same as happens when they're in the first position seems sensible to me. 14:44
java.lang.Math.log(0) gives -Inf
m: use NativeCall; sub log(num64 -->num64) is native {}; say log 0e0
camelia rakudo-moar 2dd0dd: OUTPUT«-Inf␤»
iBakeCake So I guess I'm reading the wrong IEEE standard
iBakeCake shrugs
ilmari m: use NativeCall sub logf(num32 --> num32) is native {}; say logf 0e0 14:45
camelia rakudo-moar 2dd0dd: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Can't use unknown trait 'is native' in a sub+{callable[num32]} declaration.␤at <tmp>:1␤ expecting any of:␤ rw raw hidden-from-backtrace hidden-from-USAGE␤ pure default DEPRECATED inl…»
ilmari m: use NativeCall; sub logf(num32 --> num32) is native {}; say logf 0e0
camelia rakudo-moar 2dd0dd: OUTPUT«-Inf␤»
lizmat m: m: say "1234567890".match(/./,:x(110)) # another inconsistency I think 14:46
camelia rakudo-moar 2dd0dd: OUTPUT«()␤»
lizmat m: m: say "1234567890".match(/./,:x(1..110)) # another inconsistency I think 14:47
camelia rakudo-moar 2dd0dd: OUTPUT«(｢1｣ ｢2｣ ｢3｣ ｢4｣ ｢5｣ ｢6｣ ｢7｣ ｢8｣ ｢9｣ ｢0｣)␤»
lizmat m: m: say "1234567890".match(/./,:nth(1..110)) # another inconsistency I think
camelia rakudo-moar 2dd0dd: OUTPUT«()␤»
lizmat so, if :x gets a Range, it's supposed to take the Range.max
jnthn lizmat: If you can make non-monotonic work easily, then I guess that means you're sticking the matches into an array and then slicing, rather than handing them back each time you hit a matching index? 14:49
It's meant to work the latter way
(e.g. it should be O(1) memory, not O(n))
lizmat ok, so it was really decided it should work that way?
jnthn It's a bit annoying that despite TimToady and I trying to explain this to you, you jsut call it bikeshedding. :/
I thought TimToady was pretty clear it should work that way? 14:50
lizmat ok, well, I wasn't sure how to read the "is LTA enough" message from TimToady
jnthn Ah
I think that indicated a warning (or maybe exception) was in order if you provided a non-mononotic list 14:51
lizmat your message received loud and clear
jnthn (With a suggestion to :g and then index
)
lizmat++
jnthn-- # grumpy, all day configuring darn logging :P
lizmat well, I will not try to further reunify slicing in general and handling .match
iBakeCake OK. I should've read further. Section 7.3 Division by zero 14:52
jnthn Yeah, I don't think slicing is the right way to handle it.
iBakeCake says log(0) DivByZero is signaled with -Inf
So we're right. Perl 5 is wrong and Python is wrong and probably other langs that I didn't test are also wrong :)
jnthn We did during GLR disucss introducing a method on Seq that lets you pick off things monotonically
iBakeCake recloses the ticket
jnthn But I don't *think* we added one
So there *is* a unification to be had 14:53
Just not with slicing
dalek kudo/nom: 8a72a40 | lizmat++ | src/core/Rakudo/Internals.pm:
Introduce Rakudo::Internals.SeqUsingIndexIterator

Create a Seq from a Seq and an iterator supplying index values. Originally created as part of the Str.match refactor work, but turned out to be not needed as part of that. So for now, this will sit here until we start looking at slicing of (multidim) arrays again. Or be removed should it turn out not to be needed after all.		 15:00
japhb jnthn: Do you happen to remember *why* OO::Monitors needed 'no precompilation' in the first place? 15:04
timotimo maybe because of EXPORTHOW in general? 15:07
jnthn japhb: I think it might have been a serialization bug involving locks 15:08
Though I thought I fixed something in that space at some point
japhb Oooh, so perhaps it already *is* fixed. 15:17
jnthn It may be. 15:21
iBakeCake I guess most of math functions can be marked as `is pure`? Is that of benefit or are they constant folded as it is already? 15:45
japhb jnthn: Is there a test that will catch it? (I'm fine with running the test in a big loop, I am just wondering if there was even a *flaky* test that exposed the problem.)
jnthn japhb: I think it was a very reliable failure 15:49
japhb: As in, serialization error
japhb Ah, OK 15:52
dalek ast: 938b644 | cpin++ | S03-metaops/reduce.t:
Tests for non-numeric argument to reduce ([+] 'hello')

RT#128757: rt.perl.org/Public/Bug/Display.html?id=128757		 15:54
ast: c37911b | (Aleks-Daniel Jakimenko-Aleksejev)++ | S03-metaops/reduce.t:
Merge pull request #172 from cpin/RT128757

Tests for non-numeric argument to reduce ([+] 'hello')
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128757
lizmat afk& 15:58
dalek ast: c4c96b2 | (Zoffix Znet)++ | S02-types/num.t:
[coverage] Cover nummy log() and ceiling()

om-num-num-num-num		 16:15
japhb Zoffix++ xx $lots # Coverage testing, and fixing the gaps found by same 16:28
iBakeCake m: say atanh 1 16:53
camelia rakudo-moar 8a72a4: OUTPUT«Attempt to divide 2 by zero using /␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake That actually looks to be a bug
IEEE says if |arg| = inf, produce DivideByZero exception and the section for that exception says default is infinity, signed with the sign of the arg 16:54
m: say atanh -1 # and it works right for this
camelia rakudo-moar 8a72a4: OUTPUT«-Inf␤»
iBakeCake has a suspicion he will end up the entire 70 pages of that standard... 16:55
reading too
m: use NativeCall; sub atanh(int64 --> int64) is native {}; say atanh -1 16:57
camelia rakudo-moar 8a72a4: OUTPUT«8␤»
iBakeCake Well, that sorta looks like infinity
😂m: use NativeCall; sub atanh(num64 --> num64) is native {}; say atanh 1e0 16:58
m: use NativeCall; sub atanh(num64 --> num64) is native {}; say atanh 1e0
camelia rakudo-moar 8a72a4: OUTPUT«Inf␤»
iBakeCake It almost like we need to throw DivideByZero for Perl 6 versions and do the +/-Inf for the native versions. 17:00
iBakeCake will read the standard from cover to cover
m: say 0/0 17:03
camelia rakudo-moar 8a72a4: OUTPUT«Attempt to divide by zero using div␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake m: say 0e0/0e0
camelia rakudo-moar 8a72a4: OUTPUT«Attempt to divide by zero using /␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
iBakeCake ZOFVM: Files=1198, Tests=130033, 134 wallclock secs (21.29 usr 3.16 sys + 2364.99 cusr 202.39 csys = 2591.83 CPU) 17:39
w00t.. we passed 130K of primary tests in stresstest :) 17:40
(there are way more than that in reality; since subtests count as just one test)
dalek rakudo/nom: 906719c | (Zoffix Znet)++ | src/core/Num.pm: 17:42
rakudo/nom: Make atanh(1) return Inf instead of throwing
rakudo/nom:
rakudo/nom: The 2008 IEEE 754[^1] section 9.2, states atanh(x) with |x| = ∞ is a divideByZero
rakudo/nom: exception. In section 9.1.1, it states this is indicated by a function, which then is
rakudo/nom: to return ∞. And section 7.3 describes the default value of divideByZero as ∞.
rakudo/nom:
rakudo/nom: The speculation[^2] states "floating-point modes do not throw exceptions but rather
rakudo/nom: propagate ∞ and NaN," and in fact, atan(-1) does return a -∞. Furthermore, the
rakudo/nom: following languages and tools almost universally give a ∞ for atan(1):
rakudo/nom: R: ∞; Rust: ∞; C: ∞; Ruby: ∞; Perl 5: ∞; WolframAlpha: ∞; Python: math domain error
rakudo/nom:
rakudo/nom: [1] www.csee.umbc.edu/~tsimo1/CMSC455/I...4-2008.pdf
rakudo/nom: [2] design.perl6.org/S02.html#Infinity_and_NaN
iBakeCake github.com/rakudo/rakudo/commit/90...ec90ebe425
Zoffix 21:10
yoleaux2 13:29Z <iBakeCake> Zoffix: check the atanh 1 shows up on RT
Zoffix Well, it didn't, for some strange reason :/
(doesn't matter anymore)
dalek kudo/callsite_flags_sso: c963899 | timotimo++ | src/vm/moar/ops/ (2 files):
use new small-size-optimized callsite representation
 22:19
japhb .tell jnthn Sadly, OO::Monitors still fails without 'no precompilation'. When I comment it out and run `perl6 -I lib t/precomp.t` I immediately get: Missing serialize REPR function for REPR SCRef (SCRef) 23:03
yoleaux2 japhb: I'll pass your message to jnthn.
dalek p: 1173a6e | MasterDuke17++ | docs/ops.markdown:
Add documentation for nqp::fc
 23:19
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2016/10/17/...ease-time/ 23:31
it's been a long day 23:32
good night, #perl6-dev!
Zoffix lizmat++ ehehe. I did wonder what the "answer" was last week. Nice one :) 23:53

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!