japhb
.oO( "Good night, Westley. Good work. Sleep well. I'll most likely kill you in the morning." )
 00:13
MasterDuke currently Signature.$!count == Inf when there's a slurpy. however, that requires $!count to be a Mu in BOOTSTRAP.nqp because it could be an Int or a Num later. any reason we couldn't have it == -1 when there's a slurpy? 01:04
it would require a bunch of changes in code, but it looks like the only spectest that would break is "is (-> *@a { }).count, Inf, 'slurpy positional causes infinite count'; #OK not used" 01:05
viki likes Inf since it represents what the actual .count is 01:28
MasterDuke sure, and it's not like we're going to get a 10% performance improvement, but you also can't do anything with the Inf. using -1 could have almost the exact same meaning as a representation (i.e., so many args the count has overflowed) 01:35
viki What do you mean? You can compare against Inf like you would against a 4 or a 1. Having a -1 would require all user code to special-case against slurpies 01:38
m: say [1, 2, 3] <= Inf
camelia rakudo-moar a1fcee: OUTPUT«True␤»
viki there's no "almost" same meaning with Inf. It's exactly accurate. With -1 you're introducing a convention
MasterDuke well, i wonder how much user code is actually checking the .count of signatures? 01:41
viki IMO that doesn't even matter. A design decision shouldn't be made for minor performance gains and design shouldn't have special cases just because X and not X+1 users use that feature at this moment in time. 01:46
Which spectest is that Inf in? 6.c-errata or master?
MasterDuke master
S06-signature/arity.t
i'm not pronouncing anything definite, but in general i don't think a "clever" design decision has to be kept (and paid for in (unmeasured so far) minor performance loss) if after 10+ years it turns out nobody is using it 01:49
and yeah, i was wondering about those also
viki fair nuf 01:50
MasterDuke not the most perfect of arguments, but a 'git grep "\.count.*Inf"' in moritz's perl6-all-modules returned nothing relevant 01:55
viki What about just .count? 01:56
I'm imagining cases like if $sig.count > 1 { this thing can take more than one arg.... } type of stuff 01:57
Or if .count <= 1. I think we even have such a thing in core, for meta ops
And such comparisons work naturally with an Inf, but special-casing it to -1 would break them. 01:58
MasterDuke there are a lot of .count, but none of them look like they're on a signature
viki In fact, IMO it'd make more sense to use (2**64-1) or whatever as a value, rather than -1 :)
MasterDuke oh, it would definitely require a bunch of changes in core
viki goes to bed 01:59
\o
MasterDuke later...
viki But, since the Inf is in 6.c-errata we can't change it. It's our promise to the users. 02:00
MasterDuke that's something i don't actually understand thoroughly, the difference between master, 6.c-errata, etc. 02:01
fyi, there doesn't appear to be any comparisons that couldn't be relatively easily changed (i.e., no .count <= 0 to be worked around). mostly comparisons to 1 or Inf 02:05
viki Just in core. Considering the feature is already in use in core, "no one uses it anyway" is a poor argument. But my -1 on it is purely from logical point that -1 is directly opposite of reality a slurpy represents and any comparisons require specialcasing and if a programmer doesn't remember to do that specialcasing, they have a bug in their code. 02:08
6.c roast is THE Perl 6 Language Version 6.c specification. We promise to users any release claiming to do 6.c passes that entire test suite. That's in theory, in practice tests have bugs or are outright wrong. Such cases are corrected in 6.c-errata branch. So it's still a 6.c language spec, sans errors. As for master, my view on it is that it's a work in progress to be eventually turned into a 6.d. It 02:13
represents the decisions we've made so far for how the compiler should work. It doesn't include any changes that would break 6.c, since the release must pass both master and 6.c-errata, but IMO as far as *changes* go, master is much more maleable, since we did not promise to users that all compilers will pass master at whatever state it is during the release. That leads to 6.d, and I'm fuzzy on the
details, but as I understand it, we *can* make changes that would not pass a 6.c spectest, but I'm unsure what severety is acceptable. I doubt many users would be happy if we make too drastic a change on each major release.
MasterDuke well, '.count == Inf' in core is trivially changed to '.count == -1', so i personally wouldn't weight that too highly. and i doubt there's much userland code dealing with the .count of signatures. but i am sensitive to not breaking promises
mostly playing devil's advocate here 02:14
wanting to be thoroughly persuaded either way
viki We have a list for 6.d changes too: github.com/perl6/specs/blob/master/v6d.pod 02:16
japhb Inf is as true as it can be, given the limited size of computers, whereas -1 is a lie. It feels to me like C language thinking applied to a language that (at least where numbers are concerned) is decidedly un-C-like.
viki .count == Inf to me represents reality and works with > and < comparators. .count == -1 looks nonsensical, requires special knowledge, and opens a door for bugs. So far the only reasoning FOR -1 that I read is it would give us an unknown and likely tiny speed improvement. so *shrug* :) 02:17
japhb Part of the Perl 6 philosophy is to torture the implementor on behalf of the user, not the other way around (as very many languages do).
viki Yeah, it does remind me of C too. :) 02:18
viki & # finally going to bed
japhb Good night, $user. :-)
MasterDuke i am pretty much completely in favor of keeping it as is, but i think the discussion has been useful as far as bringing up solid arguments instead of just "this is the way it's always been" 02:25
in nqp, is there any difference between 'my $hash := nqp::hash()' and 'my %hash := nqp::hash()'? 04:19
[Tux] This is Rakudo version 2016.10-74-ga1fceeb built on MoarVM version 2016.10-15-g715e39a 06:21
csv-ip5xs 3.143
test 14.854
test-t 6.778 06:22
csv-parser 17.335
Not by much, but this *is* a new low :) $ grep ' 6\.[0-7]' speed.log 06:23
2016-09-12 17:26:41 test-t 6.787
2016-09-15 13:10:01 test-t 6.796
2016-10-27 08:19:32 test-t 6.778
lizmat Files=1150, Tests=53692, 209 wallclock secs (12.54 usr 3.87 sys + 1278.46 cusr 120.72 csys = 1415.59 CPU) # also a new low for me :-) 06:34
arnsholt MasterDuke: Anbsolutely no difference! 07:03
(Also, note that "my %hash" does the same thing as too) 07:04
Also identical, "my @hash := nqp::hash()"
O:)
timotimo don't forget that a %!foo will require you to := nqp::hash() or := {} if the class you're in has a BUILD 07:05
arnsholt Oh, didn't know that! 07:08
timotimo i ran into that a few days ago. only cost me like five minutes, though 07:13
arnsholt Yeah, I guess it wouldn't be the hardest thing to debug in NQP =) 07:17
timotimo yep 07:18
i've been interested in the serialized blob recently 07:20
dalek p: a6d6c2b | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Fix the returning of natives by a try block that catches an exception.
 09:04
p: 07ad89c | (Pawel Murias)++ | t/nqp/044-try-catch.t:
Test getting int and str return values from a try block that throws an exception.
kudo/nom: 5ac593e | lizmat++ | src/core/Regex.pm:
Make ~~ /foo/ and ~~ Regex:D work the same

Spotted by labster++ . So, '"foo" ~~ /foo/' returns the Match object and sets $/, whereas 'my $a = rx/foo/; "foo" ~~ $a' only returned True and did not set $/.		 10:59
lizmat causes some spectest breakage, but the tests are too specific
dalek kudo/js: 35ed92b | (Pawel Murias)++ | src/vm/js/Perl6/Ops.nqp:
[js] Implement nqp::p6trialbind.
 11:01
ast: 40b8c3e | lizmat++ | S03-operators/relational.t:
Make chained regex test less specific

To fix test breakage by 5ac593e
ast/6.c-errata: 7525842 | lizmat++ | S03-operators/relational.t:
Make chained regex test less specific

To fix test breakage by 5ac593e		 11:04
kudo/nom: 05b65d0 | lizmat++ | src/core/Regex.pm:
Make ~~ /foo/ a bit faster

2% for successful matches, 6% for failed matches.		 12:18
gfldex is rakudo meant to understand BOMs? I'm asking because of seriot.ch/parsing_json.html 12:25
lizmat gfldex: I think that's on the list of things to fix with the encoding / decoding refactor, jnthn probably knows more 12:29
jnthn The UTF-8 encoding certainly recognizes and strips the BOM 12:37
dalek kudo/nom: e4dc8b6 | lizmat++ | src/core/Regex.pm:
Make <foo bar baz> ~~ /foo/ about 2x faster

  - rewrite using nqp ops
  - don't create Match object until we found a match
  - no need to -return- on succesful match		 12:45
viki :o 12:49
lizmat++
gfldex jnthn: should it understand Little-endian UTF-16 Unicode text, with no line terminators ? 13:41
jnthn Seems that the utf16 decoder knows about those: github.com/MoarVM/MoarVM/blob/e3ce...tf16.c#L31 13:43
Though I note it doesn't seem to have implemented the decode stream interface
gfldex it says "Malformed UTF-8" for raw.githubusercontent.com/nst/JSON...h_BOM.json 13:44
jnthn We don't auto-detect which encoding to use based on BOM 13:46
ilmari for JSON you can even detect the encoding without a BOM, since the first character must be ascii ({, [, ", , 0-9)) 13:57
(or ascii whitespace)
japhb jnthn: Did you bump versions after your OO::Monitors fixes? My home machine was failing to install OO::Monitors last night, and this morning I realized it may be because my home build script is less aggressive and doesn't try to force master/master/nom. 14:11
jnthn japhb: Ah, no 14:12
dalek ast: a3f26de | (Zoffix Znet)++ | S02-types/infinity.t:
Toss redundant test

The -Inf.Int tests are redundant, since prefix:<-> is lower precedence than postfix:<.> and so the result of the .Int exception will be the same and there's no reason to test it.		 14:25
japhb m: say Inf.chars; say -Inf.chars; 14:47
camelia rakudo-moar e4dc8b: OUTPUT«3␤4␤»
japhb Zoffix: Are you sure about that redundancy and relative precedence? ^^
viki japhb: yes. The above is a bug soon to be fixed 14:48
japhb Ah, so you want to treat -Inf as -(Inf) and not as a token of its own
viki m: say Inf.chars; say -∞.chars;
camelia rakudo-moar e4dc8b: OUTPUT«3␤-3␤»
japhb Regardless of that, isn't the spirit of the test to make sure that (-Inf).Int is handled correctly, and thus the fix is to insert said parens, rather than delete the test? 14:49
dalek ast: 3cc848d | (Zoffix Znet)++ | S02-types/infinity.t:
Revert "Toss redundant test"

This reverts commit a3f26deb881d5a25c3cb8d5ce87261a21a71b5d2.
Test to be rewritten with parens to create negative Infs		 14:57
ast: 9ce67f1 | (Zoffix Znet)++ | S02-types/infinity.t:
Test (-Inf).Int throwage

  japhb++
MasterDuke_ re the Signature.$!count discussion from yesterday. what about making the private $!count attribute an int, but the .count method still return a num? 18:04
so github.com/rakudo/rakudo/blob/nom/...ure.pm#L87 will instead be something like: $!count >= 0 ?? $!count !! Inf 18:05
viki What do we gain from that? 18:08
I mean from int $count
MasterDuke_ something that can be more easily optimized than a Mu 18:10
[Coke] is this for something that's already been identified as something that needs optimizing? 18:12
(I missed the beginning of the discussion on this)
MasterDuke_ [Coke]: i've been continuing to "clean up" BOOTSTRAP.nqp 18:13
[Coke] ah, ok.
MasterDuke_ so along with converting BOOTSTRAPATTRs to Attributes, i'm also trying to make the types more specific where possible 18:14
i.e., some things are Mu and i think they could be a native or something else more specific 18:15
and it just seems a little crazy to use a Mu for something where the range of values that are probably ever seen could fit in a uint8 (aside from the fact that Inf is also valid) 18:21
viki ZOFVM: Files=1198, Tests=130088, 131 wallclock secs (19.85 usr 2.90 sys + 2302.94 cusr 201.64 csys = 2527.33 CPU)
dalek kudo/throw-list-contains: fed556f | (Zoffix Znet)++ | src/core/List.pm:
Make List.contains throw

Due to non-obvious behaviour of the method (it stringifies the list first), make the method throw.		 18:23
timotimo not sure if i like that ^
viki timotimo: yeah, I made a branch and a PR to get feedback on the proposal: github.com/rakudo/rakudo/pull/907
perlpilot Is fixing .contains() not an option? 18:27
timotimo it's not broken 18:28
just not always what you'd expect
nine s/not always/practically never/
perlpilot that sounds like "broken" to me :)
timotimo .. we could rename it to strcontains :P 18:31
perlpilot In absence of a "real" fix for List.contains, making it fail seems like a reasonably conservative thing to do. IMHO. 18:35
nine If anyone really, really means strcontains, the workaround is trivial: $list.Str.contains($foo) 18:37
AlexDaniel viki++, good one 18:43
[Coke] we have a history in six of not using the same method name to do different things. 18:44
viki perlpilot: fixing it would result in method of the same name doing completely different things for different objects, which felt iffy
MasterDuke_ or ~$list.contains($foo)
timotimo MasterDuke_: precedence 18:45
AlexDaniel ummmm, what?
[Coke] (I don't particularly have a problem with it)
viki MasterDuke_: wouldn't that stringify the result?
[Coke] (and I think I mean routine name, not method name)
MasterDuke_ not sure about the precedence, but ~($list).contains($foo) should do it, right?
viki No 18:46
(~$list).contains($foo)
AlexDaniel m: my @list = ‘a’, ‘bb’; say @list.contains(‘a b’)
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
AlexDaniel m: my @list = ‘a’, ‘bb’; say ~@list.contains(‘a b’)
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
AlexDaniel m: my @list = ‘a’, ‘bb’; say ~(@list).contains(‘a b’)
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
AlexDaniel m: my @list = ‘a’, ‘bb’; say ~(@list) .contains(‘a b’)
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
jnthn How much breaks if we remove contains from Cool?
AlexDaniel m: my @list = ‘a’, ‘bb’; say (~@list).contains(‘a b’)
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
AlexDaniel wait, I'm doing something completely wrong :)
jnthn is not too fond of implementations that exist simply to throw... 18:47
MasterDuke_ m: say ~(^9).contains("2 3")
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
AlexDaniel well it already stringifies everything, so no point in trying 18:48
MasterDuke_ yeah, i kind of meant as a workaround like nine said, assuming the PR (or something similar) gets merged 18:49
viki m: say ~bag().contains: 42 18:50
camelia rakudo-moar e4dc8b: OUTPUT«No such method 'contains' for invocant of type 'Bag'␤ in block <unit> at <tmp> line 1␤␤»
viki m: say (~bag()).contains: 42
camelia rakudo-moar e4dc8b: OUTPUT«False␤»
viki 1 sec, I'll say 18:51
m: say ~bag() .contains: 42 18:54
camelia rakudo-moar e4dc8b: OUTPUT«False␤»
MasterDuke_ m: my @a = <1 z 3 y 5>; say @a[@a.index("z")] 18:56
camelia rakudo-moar e4dc8b: OUTPUT«3␤»
MasterDuke_ ^^^ another possible source of confusion
AlexDaniel :D 18:57
MasterDuke_ if someone thought .index was similar to .grep (i.e., return the index in the array where the thing was found)
viki What does it actually do? 18:58
m: say (0..100).index(5)
camelia rakudo-moar e4dc8b: OUTPUT«10␤»
viki :/
MasterDuke_ pos in string
viki oh boy
jnthn: only a couple of tests in t/spec/S32-str/contains.t that call .contains() on an Int 18:59
MasterDuke_ github.com/rakudo/rakudo/blob/nom/...ol.pm#L160
self.Str.index($needle) 19:00
viki jnthn: and they're present in 6.c-errata too: github.com/perl6/roast/blob/6.c-er....t#L25-L34
jnthn OK. Might be worth keeping in mind as an option. 19:05
viki wouldn't want to break 6.c-errata. 19:08
m: "fooBARber" ~~ /<[A..Z]>+/; $/.contains('BAR').say 19:09
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
viki m: say (1..10).contains: "2 3" 19:12
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
viki Imma close the PR. There's no consensus on it and it'd need same solution for Range and .index() which is too messy 19:13
MasterDuke_ and .rindex, .starts-with, .ends-with, .indices, .substr-eq 19:15
but i'd be curious for TimToady's thoughts
viki
.oO( where's a DWIM there's a WAT )
 19:16
Make another class, like Cool with those methods... Call it Smart 19:22
For 𝗦tringy 𝗠ethods that 𝗔ctually do the 𝗥ight 𝗧hing ^_^
or Nerd... for Not Entirely Right DWIMM :") 19:27
AlexDaniel viki: perhaps open a ticket for that instead 19:29
who knows, maybe @LARRY thinks that getting rid of such footgun is worth the trouble
viki I'm not a fan of tickets. It would just rot among the other 1,400. Especially since not everyone agrees that anything is broken at all. 19:42
masak viki: that's true. the best way of making something happen is to do it. 20:00
viki masak, indeed. And after the discussion, the only viable solution I see is splitting Cool, which IMO isn't a worthy pursuit just to avoid a wat. :) 20:06
ugexe m: my @a = [90..100]; say @a.contains("98 99"); say @a>>.contains("98 99") 20:14
camelia rakudo-moar e4dc8b: OUTPUT«True␤[False False False False False False False False False False False]␤»
gfldex there is .flip and .reverse, and there is .contains and .??? 20:30
IMHO there is a lack of thought by the design departement 20:31
also, if .contains throws so should .flip 20:32
perlpilot more like "lack of focus on this particular bit of the design" than "lack of thought" 20:36
viki Design department? :) 20:37
gfldex i still have hopes :)
AlexDaniel gfldex: .contains and .first? 🤷 20:56
whenever I had to do that kind of thing I always used any, I think 20:57
nine Good news is that INIT phasers do indeed run even when we load a precompiled module. Bad news is that I'm probably gonna have to runtime generate an INIT phaser into Inline::Perl5's users. And that doesn't exactly sound like a walk in the park. 21:07
perlpilot m: my @a = <a b c d >; say so @a.starts-with("a b"); say so @a.ends-with("c d"); 21:18
camelia rakudo-moar e4dc8b: OUTPUT«True␤True␤»
perlpilot Also a little surprising 21:19
jnthn nine: If doing that, might just be worth putting in a general mechanism for phaser export 21:20
nine: I mean, we already have EXPORTHOW for meta-objects; could do EXPORTPHASER for those :P
lizmat fwiw, re .contains, .index, .starts-with, .ends-with: the underlying issues is really that Lists are Cool 21:46
so why are they Cool in the first place ?
*issue 21:47
gfldex m: sub can-substr(Cool $c){ $c.substr(1,2).say }; can-substr(<a b c>); 21:51
camelia rakudo-moar e4dc8b: OUTPUT« b␤»
AlexDaniel gfldex: what point are you trying to make? 21:52
gfldex m: substr(<a b c>, 1, 2).say;
camelia rakudo-moar e4dc8b: OUTPUT« b␤»
dalek kudo/nom: 8c35481 | lizmat++ | src/Perl6/Metamodel/BOOTSTRAP.nqp:
Fix comment
 21:53
gfldex if List stops to be Cool, there will be a disconnection between the coerciness of substr and .substr
and there are plenty of such pairs of subs and methods
AlexDaniel but why should substr(<a b c, 1, 2) work at all? 21:54
>*
s: &infix:<+>, \(2, 5)
SourceBaby AlexDaniel, Sauce is at github.com/rakudo/rakudo/blob/e4dc...nt.pm#L245
AlexDaniel s: &infix:<+>, \(<a b c>, 5)
SourceBaby AlexDaniel, Sauce is at github.com/rakudo/rakudo/blob/e4dc...ic.pm#L186
gfldex because in a dynamic language you have to care about getting your types right. If you don't care about types, things will just work. For a wide range of values for work. 21:55
AlexDaniel and by “work” what do you mean?
m: substr(<a b c>, 1, 2).say;
camelia rakudo-moar e4dc8b: OUTPUT« b␤»
AlexDaniel < > does not get you strings, not even close 21:56
well it does, but…
lizmat well, making List Any breaks the build quite early :-)
jnthn I think it simply boils down to: with each operation you need to know what type it's going to coerce to if that's not what it gets. That runs deep in Perl (5 and 6). 21:57
It's perhaps a bit unfortunate that we added contains/start-with/ends-with.
gfldex m: say so <a b c>.starts-with('a'); 21:58
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
jnthn Since matching against /$foo/, /^ $foo/ and /$foo $/ are unambiguously about strings.
gfldex it will work in quite a lot of cases, but may break for others. The bother could be in the realm of a linter. 21:59
AlexDaniel m: say 42.starts-with(‘4’)
camelia rakudo-moar e4dc8b: OUTPUT«True␤»
gfldex and if it should start with '4' depends on the intention of the programmer. Sadly Rakudo can't read minds yet. 22:00
AlexDaniel my point was that starts-with and friends are not just about strings, they are fine for numbers too 22:02
gfldex Perl 6 does not support copy constructors for implicit coercion like C++ does. That's why we need Cool.
jnthn Having operations in the language consistently coerce things to the type they want is, IMO, preferable to them overloading the same word with different meanings, anyway. But no approach is without its ways for people to trip over. 22:03
So contains/starts-with/ends-with consistently being about strings is fine. You learn that once, and you know what they're going to do whenever you see them. 22:04
gfldex i think .contains is fine as it is. It's one of the things you have to learn when you use Perl 6. And given it's a fairly common pattern to have methods that coerce to some type, it's not a large burden on the user. 22:05
jnthn Indeed, I don't think you could get very far in Perl 6 without realizing that it works in that way.
gfldex You may want to print that bold in books tho. :->
jnthn For example, all the list-y methods treat non-Iterable things as a 1-item list.
It's better to be consistent in this approach than to introduce discontinuities because somebody might be confused about what the units .contains is referring to are. 22:07
We've even gone so far as having substr and subbuf, and we'll likely end up with subuni too for the same reason.
lizmat m: say <a b c d e>.index("e") # .index also 22:08
camelia rakudo-moar e4dc8b: OUTPUT«8␤»
jnthn Indeed
lizmat m: say <a b c d e>.rindex("e") # and its counterpart .rindex 22:09
camelia rakudo-moar e4dc8b: OUTPUT«8␤»
jnthn JavaScript has .indexOf on both Array and String.
And they do different things.
Meaning you have to know what type of data you'll have to know the semantics.
Which is unpredictable even after you learn the language well. :) 22:11
So I'd say we're in a better place. 22:12
AlexDaniel yea, that's bad. And we don't do it, it's good, I agree. Instead we print wrong results that are far from being useful at all, even if you know what these results mean.

Powered by Cro and the Raku® Programming Language.

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

Thank you!