Perl 6 language and compiler development 2.0 | Logs at irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by moderator on 21 May 2018.
Geth nqp: jstuder-gh++ created pull request #449:
s:global/start/beginning/ in JVM slice methods		 00:40
01:09 llfourn joined
skids m: Any(:a) 01:32
camelia Cannot coerce to Any with named arguments
in block <unit> at <tmp> line 1
01:58 ilbot3 joined
moderator Perl 6 language and compiler development 2.0 | Logs at irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Zoffix k, plan B: `sub Rakudo-InternalSubs-DIVIDE_RATIONALS` 02:19
samcv working on the moarvm release now. on a vacation with my family but have some down time now :) luckily i've been working on tools to automate part of the release log 02:23
not all of it. but i have a script to try and categorize each commit so it should reduce the time a lot 02:24
Zoffix Hardcore :) Releasing while on vacation :) 02:26
samcv well i just had a Daiquiri so gonna do it :)
02:27 lizmat joined
samcv i mean i'm in a cabin in maryland atm, was in Washington DC for the previous 3 days. So now i actually don't have any plans and haven't been walking around washington dc all day 02:27
Zoffix nice 02:31
MasterDuke Zoffix: why not a just a sub in the existing Rakudo::Internals? 02:33
Zoffix MasterDuke: that's what I originally did but was getting the same error, so I assumed RI was too soon in the setting and created that second file, but still getting the error 02:35
MasterDuke huh 02:36
Zoffix m: FatRat.new(1, 2⁶4).Rat 02:48
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse expression in argument list; couldn't find final ')' (corresponding starter was at line 1)
at <tmp>:1
------> 3FatRat.new(1, 2⁶7⏏054).Rat
expecting any of:
in…
Zoffix m: FatRat.new(1, 2⁶⁴).Rat
camelia Cannot convert from FatRat to Rat because denominator is too big
in block <unit> at <tmp> line 1
Zoffix I guess this will now return a fattish Rat
$ ./perl6 -e 'my $a = 42; say $a/0' 03:13
Attempt to divide by zero when coercing Rational to Str
That's the error now, with ZeroDenominator role mixin
Wonder if that's confusing to newcomers who just see that code as dividing stuff and not a coercion or a Rational 03:14
damn, there's actually a spectest covering the error says something about the numerator github.com/perl6/roast/commit/4e63...851c2374c4 03:36
Maybe ZeroDenominator role can live with normalization. Gonna see where this path leads before merging this branch. 03:37
I mean, without normalization, so that 42/0 remains with 42 in numerator
m: m: use nqp; my \\nu = <1>; say nqp::box_i(nqp::islt_I(nqp::decont(nu), 0) ?? -1 !! nu ?? 1 !! 0, nu.WHAT) 03:44
camelia concatenate requires a concrete string, but got null
in block <unit> at <tmp> line 1
Zoffix *sigh* so now this is the issue with making Rational respect the types of given attributes when binding :/ 03:45
Geth ¦ rakudo: zoffixznet self-assigned Rational doesn't preserve types of nu/de github.com/rakudo/rakudo/issues/1855 03:56
Zoffix There's a way out, but it'll prolly be slow. Gonna ignore this for now. Filed as ^
Geth roast: 513da79cd0 | usev6++ | S11-compunit/compunit-dependencyspecification.t
[JVM] Fix typo in implementation name
 05:00
05:35 shareable6 joined 05:42 nativecallable6 joined, bloatable6 joined 05:43 quotable6 joined, coverable6 joined, releasable6 joined, greppable6 joined, reportable6 joined, bisectable6 joined, notable6 joined, committable6 joined, evalable6 joined, unicodable6 joined, benchable6 joined, statisfiable6 joined, squashable6 joined, undersightable6 joined, shareable6 joined
Geth rakudo: skids++ created pull request #1856:
Execute code in elided duplicate argument pair values		 06:37
07:17 robertle joined
|Tux| Rakudo version 2018.04.1-118-g2f4b2f428 - MoarVM version 2018.04.1-121-gd634d24cf
csv-ip5xs0.841 - 0.855
csv-ip5xs-208.607 - 8.629
csv-parser24.693 - 24.729
csv-test-xs-200.420 - 0.426
test8.757 - 8.909
test-t2.354 - 2.367
test-t --race1.000 - 1.050
test-t-2042.292 - 42.391
test-t-20 --race14.516 - 15.274
 08:04
08:06 shareable6 joined
lizmat Files=1239, Tests=76372, 322 wallclock secs (15.65 usr 5.57 sys + 2216.43 cusr 231.76 csys = 2469.41 CPU) 08:07
08:11 brrt joined 08:20 Kaiepi joined
AlexDaniel actually I can cut a release from any branch 08:33
similarly to how point releases are done
so for the next release I think that's what we should do?
this way we wouldn't have this typical “oh no release is happening stop your work because master is locked” issue 08:34
is there even any reason not to do that? Branches are so cheap 08:35
AlexDaniel unlocks master 08:40
Geth nqp: fc6441a192 | (Luis F. Uceta)++ | src/HLL/Compiler.nqp
Fix STDIN error for non-interactive REPL mode

Do not close STDIN it is the source of the program
Fixes github.com/rakudo/rakudo/issues/1824		 08:44
nqp: 68aa44de08 | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | src/HLL/Compiler.nqp
Merge pull request #447 from uzluisf/master

Fix STDIN error for non-interactive REPL mode
rakudo: a79de42904 | (Zoffix Znet)++ | 2 files
Fix premature .perl chopping in X::TypeCheck

Fixes github.com/rakudo/rakudo/issues/1848 R#1848
Before chopping .perl, check if object's .^name is part of it, and if it is, bump the chop length by the length of the .^name.
synopsebot R#1848 [closed]: github.com/rakudo/rakudo/issues/1848 X::TypeCheck chops off .perl too soon
rakudo: 75430ac9cb | (Tom Browder)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | src/Perl6/Pod.nqp
Fix for GH #1852: pod converts non-breaking space into normal space

Tests have been added for the fix.
synopsebot RAKUDO#1852 [open]: github.com/rakudo/rakudo/issues/1852 Pod convert non-breaking space into normal space.
rakudo: 26f0033427 | (Aleks-Daniel Jakimenko-Aleksejev)++ | 3 files
Merge branch 'post-release-2018.05'
AlexDaniel I'll simply cut the release from release/2018.05.
so please free to use master 08:45
Zoffix ↑ 08:47
hm I also wonder why we didn't do that before 08:50
I don't care from which branch the release is cut, my release sakefile doesn't care also
in the end the release branch is merged back to master anyway, so in the end it'll look the same… 08:51
… and now there's even less pressure on release managers to cut releases in time :P 08:54
09:30 TimToady joined
Geth rakudo: d1d31fd574 | (Elizabeth Mattijsen)++ | src/Perl6/Grammar.nqp
Make sure "use p5isms" also works for "rand"
 10:01
lizmat AlexDaniel: if you could cherry-pick that info the release branch, that would be brill
if not, then that's ok too
Geth rakudo/car-grant-unreduce: 7 commits pushed by (Aleks-Daniel Jakimenko-Aleksejev)++, (Tom Browder)++, (Elizabeth Mattijsen)++, (Zoffix Znet)++ 11:22
Zoffix Thanks. But I think I'll let it marinate in a branch for a bit. With the R#1855 issues and the error reporting for `my $a = 42; say $a/0` kinda up in the air. 11:24
synopsebot R#1855 [open]: github.com/rakudo/rakudo/issues/1855 [CaR Grant] Rational doesn't preserve types of nu/de
11:24 Zoffix left
AlexDaniel honestly I don't feel like adding any changes to the release branch, however small the change is 11:25
I've applied all possible checks to the last commit in the release branch, it is perfect, no need to risk it :) 11:26
m: say rand(5) 11:28
camelia 5===SORRY!5=== Error while compiling <tmp>
Unsupported use of rand(N); in Perl 6 please use N.rand for Num or (^N).pick for Int result
at <tmp>:1
------> 3say rand7⏏5(5)
AlexDaniel does it even work?
11:29 brrt joined
AlexDaniel lizmat: also, any tests? 11:30
brrt .
yoleaux 11:15Z <Zoffix> brrt: that didn't really answer my question. You complained we do in HLL what's better done as an op. I asked how to make an op. You reply you're not in favour of it. That makes me feel I should stick to doing things in HLL instead of ops. If some ops are better not done, then maybe it's something you should include in an op creation guide.
brrt .tell Zoffix noted 11:31
yoleaux brrt: I'll pass your message to Zoffix.
lizmat m: use p5ism; sub rand($a) { $a.rand }; say rand(42)
camelia ===SORRY!===
Could not find p5ism at line 1 in:
/home/camelia/.perl6
/home/camelia/rakudo-m-inst-1/share/perl6/site
/home/camelia/rakudo-m-inst-1/share/perl6/vendor
/home/camelia/rakudo-m-inst-1/share/perl6
CompUnit::Re…
lizmat m: use p5isms; sub rand($a) { $a.rand }; say rand(42) 11:32
camelia 17.42038367119953
brrt assumming Zoffix backlogs: I haven't gotten 'round to writing an implementing-an-op-guide
lizmat AlexDaniel: yeah it works
brrt maybe that should be something i should prioritize over JIT improvements
having said that, the original complaint was *not* about everything being an op that might possibly be, the original complaint was about 'y u not communicate this' 11:33
also, wasn't as much a complaint as an invitation to further communication
AlexDaniel lizmat: wait… isn't that pragma other way around? 11:34
brrt also, I reverse the right to be in favour of one kind of new opcode, and against another
:-)
AlexDaniel shouldnt it be “no p5isms” ?
lizmat "no p5isms" is the default
m: no p5isms; sub rand($a) { $a.rand }; say rand(42)
camelia 5===SORRY!5=== Error while compiling <tmp>
Unsupported use of rand(N); in Perl 6 please use N.rand for Num or (^N).pick for Int result
at <tmp>:1
------> 3isms; sub rand($a) { $a.rand }; say rand7⏏5(42)
lizmat which is exactly the problem: even though I have a sub in scope with the right signnature, it complains about not being supported
AlexDaniel is confused 11:35
lizmat use p5isms just takes away the check
m: no p5isms; say rand(42)
camelia 5===SORRY!5=== Error while compiling <tmp>
Unsupported use of rand(N); in Perl 6 please use N.rand for Num or (^N).pick for Int result
at <tmp>:1
------> 3no p5isms; say rand7⏏5(42)
lizmat m: use p5isms; say rand(42)
camelia 5===SORRY!5=== Error while compiling <tmp>
Calling rand(Int) will never work with signature of the proto (*%)
at <tmp>:1
------> 3use p5isms; say 7⏏5rand(42)
AlexDaniel am I the only one who can't make sense of it? 11:36
so if I don't want to be warned about p5isms, I have to say that I “use p5isms”??
lizmat yeah
because that will *allow* p5isms 11:37
otherwise it would have to be something like
no p5ism-warnings
no p5ism-errors
AlexDaniel: I guess we had the bikeshedding phase on this, but apparently not 11:38
so forget about my request for cherrypicking 11:39
lizmat needs to be afk for a few hours
AlexDaniel I remember Zoffix saying that the naming wasn't good, but other than that I can't recall any bikeshedding
as for the cherry-pick, I guess there may be other places where this pragma doesn't work yet, we'll squash all that for the next release 11:40
lizmat I remember Zoffix saying that it would also include C++ isms, which I fixed
it will now only not complain about p5isms 11:41
AlexDaniel hmm
lizmat m: use p5isms; new foo bar
camelia 5===SORRY!5=== Error while compiling <tmp>
Unsupported use of C++ constructor syntax; in Perl 6 please use method call syntax
at <tmp>:1
------> 3use p5isms; new foo 7⏏5bar
lizmat afk&
11:57 Ven`` joined
Ven`` o/! I was asked a few questions by a Unicode-savvy and I didn't know how to answer... Well, their first reproach was that we default to grapheme clusters for substr, whereas we try to be explicit everywhere else. Well, that's probably just a doc issue really. 12:00
The second is more troubling: the definition of a grapheme cluster changed in 2016, which means any substr is prone to breaking. : There are no guarantees of stability in the definition of grapheme cluster, so updating is likely to bring breaking changes. (apparently, swift is stuck with Unicode 8 for that reason: bugs.swift.org/browse/SR-375). 12:02
(well, for a slightly different reason than our substr changing its behavior, but still: the definition of a grapheme cluster changed and they don't want to break user code). 12:03
12:04 Zoffix joined, shareable6 joined
Zoffix brrt: then I have the answer for you. I don't communicate this because I don't understand the ops. And the couple of ops I did propose where dismissed as a bad idea. 12:06
As for `p5isms`. Isn't the name shortsighted anyway? Will we have a separate pragma to disable the C++'s error? 12:07
AlexDaniel Ven``: not sure I understand?
Ven``: any string is subject to unicode normalization
Zoffix And will it become `pfooisms` when Perl 5 releases a new major version?
AlexDaniel Ven``: and whenever a new unicode version is supported, it may add new characters and change normalization rules 12:08
Zoffix +1 to " honestly I don't feel like adding any changes to the release branch, however small the change is"
AlexDaniel ↑ there's probably an exception for security-related fixes, but I'll judge case by case 12:09
Zoffix m: say so /<[0-9]>/
camelia 5===SORRY!5=== Error while compiling <tmp>
Unsupported use of - as character range; in Perl 6 please use .. for range, for explicit - in character class, escape it or place it as the first or last thing
at <tmp>:1
------> 3say so /<[0-7⏏…
Zoffix m: use p5isms; say so /<[0-9]>/ 12:10
camelia ===SORRY!===
This representation (P6int) does not support attribute storage (for type BOOTInt)
Zoffix And this isn't a p5ism. Tons of languages use this syntax for char ranges in regexes.
AlexDaniel what about “use training-wheels;”? :)
Zoffix too long
But that's another thing too: I rather these errors were off by default 12:11
AlexDaniel Zoffix: we can change the default later
Zoffix
.oO( no hasles; )
 12:12
AlexDaniel Ven``: so what kind of code are we breaking exactly?
Ven`` AlexDaniel: The point is: it changes meaning of existing code.
Zoffix
.oO( use perl6-only-I'm-not-writing-Perl5-dammit )
Ven`` see on some older version: ideone.com/i5CJ8a – that now returns 2.
Kaiepi use handicap? 12:13
Zoffix c: 2015.12,HEAD say "🇺🇸🇺🇸".chars
committable6 Zoffix, ¦2015.12: «1␤» ¦HEAD(d1d31fd): «2␤»
Zoffix We had tons of such changes tho
AlexDaniel why was it 1? 12:14
that looks like a bug actually
Zoffix c: 2015.12,HEAD my Seq $s = "🇺🇸🇺🇸".comb
committable6 Zoffix, ¦2015.12,HEAD(d1d31fd): «»
Zoffix c: 2015.12,HEAD my Seq $s = "🇺🇸🇺🇸".comb: /./
committable6 Zoffix, ¦2015.12,HEAD(d1d31fd): «»
Ven`` AlexDaniel: because Unicode said so.
Zoffix c: 2016.12,HEAD my Seq $s = "🇺🇸🇺🇸".comb: /./
committable6 Zoffix, ¦2016.12: «Type check failed in assignment to $s; expected Seq but got List ($("🇺🇸🇺🇸",))␤ in block <unit> at /tmp/7oDRFfjEgg line 1␤␤ «exit code = 1»» ¦HEAD(d1d31fd): «»
Ven`` Regional Indicators are a set of 26 “letters” that you can combine in pairs to make the flags. The pairs are the country short codes in ISO something-something. So, the regional indicator U, followed by the regional indicator S, make up the United States flag. DE makes Germany, etc. In Unicode 8, the grapheme break rules were simply “do not break between regional indicators”. This makes USUSUS a single cluster, even though 12:15
Zoffix So just as .comb was clarified to return a Seq instead of List, so does Unicode support has been upgraded in recent compilers. 12:16
12:16 Zoffix left
AlexDaniel Zoffix: well, I guess the concern is that Unicode is changing all the time, but we won't be changing other things all the time 12:16
Ven`` I'm not sure i .comb changed its meaning because it was under-specified or because the behavior it provided was "faulty" (didn't account for some use case or w/e), but here it's jsut the standard changing. 12:17
.oO( use Unicode:ver<8>; )
Again, this can be marked as a doc issue. We just add "This uses grapheme indices, which are subject to changes whenever the Unicode version your Perl 6 impl. is updated" to substr and let people deal with the fallout... 12:18
AlexDaniel but as I said, that's not just about graphemes 12:19
you can have two separate single codepoint characters, or something similar
and in the next version they'll change into a single character
because normalization
or maybe not? 12:20
well actually it's correct, in a way
Ven`` AlexDaniel: I mean, I don't think any breakage is good. At the same time, you don't want to have to ascribe all your strings to a specific Unicode version... 12:28
AlexDaniel well, I don't really count that as breakage 12:31
you updated and now your strings are now normalized according to the latest standard…
if you highly depend on the exact way your strings are represented, maybe you shouldn't be using strings
maybe you need Bufs or something else
or utf8-c8 even 12:32
12:48 rmf1723 joined 12:55 Ven`` joined
rmf1723 Ftr, normalization never ever changes. 12:56
Stability guaranteed since Unicode 4.1
Ven`` AlexDaniel: ^^^ someone much more unisavvy than I am
AlexDaniel rmf1723: oh! 12:58
didn't know that!
rmf1723 Fwiw, I'm the one who brought this up with Ven; I'm working on C++ standardization of this stuff and have been looking around what other languages do 12:59
12:59 pmurias joined
AlexDaniel rmf1723: I stand corrected then :) 12:59
chansen_ AlexDaniel: www.unicode.org/policies/stability_...malization 13:02
rmf1723 And also to make it clear, the 2015 behavior (two US flags are one char) was correct in 2015 Unicode. So this wasn't a bug that got fixed 13:04
At least not in Perl6; it can be argued that it was a bug in the Unicode spec, but that's not relevant, I guess 13:05
AlexDaniel .tell samcv unicode related discussion: irclog.perlgeek.de/perl6-dev/2018-...i_16192660
yoleaux AlexDaniel: I'll pass your message to samcv.
rmf1723 Of 13:08
*oh I guess that's your local Unicode guru?
AlexDaniel yes
chansen_ Unicode 11 will bring better stabilization in segmentation for emojis, <www.unicode.org/L2/L2016/16315-hand...ji.pdf> 13:09
AlexDaniel I see 13:10
rmf1723 IIUC that proposal actually brings another breaking change :p 13:12
AlexDaniel rmf1723: fwiw if you spot any other issues, please file bug reports 13:13
buggable: uni
buggable: tag uni
buggable AlexDaniel, There are 25 tickets tagged with UNI; See fail.rakudo.party/t/UNI for details
AlexDaniel uh, that's the wrong issue tracker :) 13:14
github.com/rakudo/rakudo/issues?q=...abel%3AUNI
rmf1723 Will do. I'm adding Perl 6 to my list of implementations to look into. 13:15
AlexDaniel 🙌
AlexDaniel & 13:17
chansen_ rmf1723: Technically it's not a breaking change since GCB, SB and WB is auxiliary. Only LB is non-auxiliary. 13:22
Similar change was don in Unicode 9 for LB to "future proof" it. <www.unicode.org/reports/tr14/tr14-3...ations> 13:25
chansen_ s/don/done/
13:42 lucasb joined
rmf1723 But this future-proofing, which they adequately scare quote, isn't a stability guarantee; it's just making it ready for one kind of possible predicted future change. 13:48
So with this there is one set of changes that can and are likely be made in the future that won't break things; but there's nothing to say something else will. 13:49
13:51 Kaiepi joined
chansen_ True 13:51
14:00 PufferBot joined, Kaiepi joined
samcv Unicode grapheme break property standards be like: xkcd.com/927/ 14:01
yoleaux 13:05Z <AlexDaniel> samcv: unicode related discussion: irclog.perlgeek.de/perl6-dev/2018-...i_16192660
samcv s/competing standards/grapheme break rules/g 14:02
chansen_ I don't see the problem, segmentation (WB, SB, GCB) is not part of the Unicode standard, they are auxiliary (guidelines) and if a programming language want to make guarantees about stability outside Unicode thats fine, but there is no stability guarantee from Unicode. 14:28
It's worth noting that segmentation is a very complex and varies depending on script/language, which is also why Unicode 11 adds two empty property values and referees to CLDR. 14:40
15:12 skids joined 15:15 dogbert17 joined
dogbert17 ZOFFLOP: t/spec/S17-supply/syntax.t test #83 (hang) 15:16
samcv chansen_: i wouldn't say there is a problem either 15:17
rmf1723 chansen_: they *are* a part of the Unicode standard. 15:18
www.unicode.org/standard/standard.html
samcv that is also true yes
rmf1723 Formally, a version of the Unicode Standard is defined by an edition of the core specification, The Unicode Standard, together with the Code Charts, Unicode Standard Annexes and the Unicode Character Database.
(quote)
Segmentation is Annex #29 15:19
samcv and afaik if you don't process any new codepoints the grapheme breakage should stay the same, though don't quote me on that
rmf1723 samcv: no, it does not, because not only the *_Break properties change from version to version, but also the algorithm.
samcv and there's always the classical grapheme segmentation if you want something unchanging i suppose... though it's not all that useful nowdays if you are dealing with emoji and all other things people put in
rmf1723 samcv: a clear example is the way regional indicators worked in Unicode 8 vs 9. In Unicode 8, 🇺🇸🇺🇸 is a single grapheme cluster. In Unicode 9, it's two. No character properties changed between. 15:20
samcv ah i suppose you are right. they were added earlier
very true 15:21
though not sure if they were used much before that? i didn't read why they were originally added in the first place, only when i had to deal with the new grapheme break changes
rmf1723 Definitely not used much before Unicode... 7? 8? Not sure. They were added in 6.0 15:23
Anyway, chansen_ is right that there is no stability in segmentation, which is why got interested in how Perl6 deals with it. The only other mainstream language I know that defaults to breaking strings into grapheme clusters is Swift, and there they seemingly cornered themselves into Unicode 8 for fear of breaking changes. 15:26
chansen_ back 15:34
=)
samcv rmf1723: well atm we don't really attempt to fix that. though if there are issues in the future i could see us letting the user choose a unicode version? dunno. it could be doable i suppose. but atm it's not at the very top of the list 15:50
above that is planning to allow strings to be non-normalized and grapheme broken and by codepoint as a different string type
chansen_ Python includes two versions of UCD 3.2 (for RFC/IETF IDNA) and the most recent one. 15:53
I wouldn't recommend entertaining the idea of supporting multiple versions UCD. From a performance POV it wouldn't be sound ;) 15:54
samcv yeah i don't really like that idea too much. but i think being able to have codepoint based strings would be a way for us to address the problem for situations that matters 15:55
chansen_ Even if you went the same route as ICU with serialized Trie's there will be a performance cost. 15:56
samcv though mostly it'd be more annoying to maintain tbh
having to maintain all past versions...
chansen_ True 15:57
samcv though it could be doable. but i prefer not to prematurely try and solve problems that haven't yet arised and go for more objective ones :)
15:58 brrt joined
chansen_ I believe rakudo/MoarVM has other interesting optimizations in the pipeline before considering supporting multiple versions of UCD, like a proper lexicon data structure for Unicode character names. 16:01
rmf1723 The problem is that it's not just UCd 16:09
The algorithms change too, so there's also old code to maintain.
timotimo big test suites can keep us honest :) 16:10
rmf1723 You cannot use the new algorithms with an old UCD because that gives you neither the old behavior nor the new o e.
*one
16:24 lizmat joined
chansen_ True 16:27
Geth specs: b08407beaa | (Elizabeth Mattijsen)++ | S06-routines.pod
s/concatenated/appended/

Concatenation is generally used for strings only. Seems to me "appending" describes what happens better.		 16:29
16:53 robertle joined 16:56 lucasb joined
Kaiepi perl's on graphemes while ve v 18:00
touchpad's being finicky sorry
18:39 shareable6 joined
Geth rakudo: tbrowder++ created pull request #1857:
clean up code, expand space chars considered when normalizing text		 19:01
19:25 AlexDaniel joined 19:27 brrt joined 20:14 lucasb joined
lucasb skids: Can I bother you about the :nth(*-1) thing? 20:23
It seems you changed its behavior in a commit. Test were changed here github.com/perl6/roast/commit/e502...7e88dd6955
Do you remember with there was any discussion about it? 20:24
I didn't found any in the IRC logs of that day
s/with/if/ 20:27
m: say 'abc' ~~ m:nth()/\\w/ 20:38
camelia ()
lucasb m: say 'abc' ~~ m:nth/\\w/
camelia ｢a｣
lucasb IMO, those two should have the same result, no? 20:39
geekosaur anyone happen to notice commit messages to the list now get developer.github.com/changes/2018-...precation/ attached? 20:42
lizmat just noticed that on my recent specs change 20:55
skids lucasb: I'll look into that. It was a long time ago... 21:14
Hrm that :nth and :nth() is an interesting corner case: considered as a normal adverb, :nth.value is True and :nth().value is False. Really the first form is not idomatic, and it probably wouldn't be horrible to warn on it. 21:21
21:24 lucasb joined
lucasb Actually, :nth().value is the empty list, so $str ~~ m:nth()/pattern/ will always return an empty list, whether it matches or not. I think this is correct 21:32
since m:nth/pattern/ can be interpreted as m:nth(True)/pattern/, and this can be interpreted as m:nth(1)/pattern/, then I think it's correct also 21:33
I dunno why I mentioned them. Don't bother about them. They seem correct IMO 21:34
I'm just asking that the behavior of :nth(*-1) and :nth(*) be reconsidered. 21:35
IMO, :nth(*-1) should be the *last* occurrence, not the second to last 21:36
and, :nth(*) should be the same as :nth(1..*), not the last occurrence
I'm not saying that the 1-based-ness of this feature be changed. :nth(1) should still be the same as :1st, etc. 21:38
skids lucasb: At this point, I'm not sure whether or not the way the Whatever is handled now is even how I implemented way back then. 21:49
The general idea was that * is dwimmy and its behavior varies based on context. (you can even write user-defined * behavior) 21:52
lizmat m: sub a(Whatever) { say "whatever" }; a * 21:57
camelia whatever
lizmat m: sub a(*) { say "whatever" }; a * # unfortunately, * by itself is not DWIM in a signature 21:58
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> 3sub a(*7⏏5) { say "whatever" }; a * # unfortunat
skids Or in other words, :nth is not *supposed* to behave the same as []... most obviously because it is 1-based, but in general consistency with [] wasnt the goal. 21:59
So I guess what I'm saying I do see a distinction between Callable and Whatever... on a syntactic level the latter may be more dwimmy, and the distinction may be used by experienced coders who want to power past the dwim. 22:06
22:17 dct joined
Geth roast: tbrowder++ created pull request #430:
expand tests for non-breaking space handling		 22:32
22:33 Kaiepi joined
skids Hrm so how seriously do we procedurally deal with ways to violate MONKEY-SEE-NO-EVAL these days... I think there is still a gaping hole in .EVAL anyway, right? 23:15
It's nothing crazy, but I don't want to blurt it out on IRC if we have a process in place, even just nominally. 23:16

Powered by Cro and the Raku® Programming Language.

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

Thank you!