🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
SmokeMachine \o/ I was missing that .do for a very long time!!! 05:42
SmokeMachine .ask lizmat sorry for interrupting, but I was searching for some of my old messages on irclogs, and I can find people answering me, but not my own messages… any reason for that? 06:02
tellable6 SmokeMachine, I'll pass your message to lizmat
SmokeMachine Even this message ^^ I can see tellable’s answer, but not my message… 06:04
SmokeMachine .tell sorry! My mistake! I was filtering out my nick for some reason… 06:05
tellable6 SmokeMachine, I cannot recognize this command. See wiki for some examples: github.com/Raku/whateverable/wiki/Tellable
SmokeMachine Should we close this then? github.com/Raku/problem-solving/issues/122 06:21
Nemokosch Why is .&{} not enough? 10:06
lizmat because .do returns the invocant always (something I missed initially) 10:55
tellable6 2023-03-19T06:02:54Z #raku-dev <SmokeMachine> lizmat sorry for interrupting, but I was searching for some of my old messages on irclogs, and I can find people answering me, but not my own messages… any reason for that?
Nemokosch Is this worthy of huffmanisation? 10:58
lizmat other languages seem to think so 10:59
Nemokosch Other languages don't have .&{}
Anyway, what other languages?
Geth rakudo/main: 18a5dab5e4 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Raku.pm6
RakuAST: convert large elsif into a dispatch table
12:29
lizmat Kotlin was the one mentioned to me: kotlinlang.org/api/latest/jvm/stdl...apply.html 12:31
but since we already have Supply.do with similar semantics, the name "do" was chosen
Geth rakudo/main: b8488d24d3 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add adverb handling to RakuAST::QuotedRegex .raku/deparsing
13:14
Geth rakudo/main: 83ed64e96d | (Elizabeth Mattijsen)++ | 8 files
RakuAST: make RakuAST::ColonPair::True|False take a positional

Rather than a named "key" parameter. There is only one parameter to specify, so make it a positional. Adapt actions, .raku, deparsing and testing accordingly.
13:44
Xliff Raku-GLib suite timing statistics for Raku 2023.02.191.g.837.a.2.eb.87 14:57
Total number of projects: 33 (503277 loc)
Total non-parallel compile times: 9102.240 (275.825 avg)
Total parallel compile times: 2279.930 (69.089 avg) 3.992x speedup
These are the timing values from last week.
Xliff Note parallel time increase of over 900 seconds. 14:58
from the 27th of last month, which was ~1400 seconds.
lizmat Xliff: fwiw, I don't see anything in the change log that immediately jumps out as a possible reason 15:02
tellable6 lizmat, I'll pass your message to Xliff
Xliff lizmat: Are you tracking chages at both the NQP and the MoarVM level? 15:07
lizmat I was just looking at the Rakudo log, true
Xliff Ah.
lizmat there was one bump for github.com/MoarVM/MoarVM/commit/6a...99244507d5 15:08
perhaps that affected the JIT ?
Xliff Anything is possible. A small change in something that affacts IO will greatly affect the timings. 15:10
The reason why parallel is so up and down is that it uses file as opposed to dir locking.
And as much as I try to stay off the machine when the parallel timings run, anything could jump up and create more chaos in the environment. 15:11
Still...really weird to see a jump of 900 seconds in a week.
I'll do this week's parallels in a minute.
SmokeMachine Nemokosch: but .&{} is not equivalent to .do({}). .do returns the original value, so, 42.do: { $!next = $_ + 1 }; would return 42 and store 43 on $!next… 20:11
tellable6 SmokeMachine, I'll pass your message to Nemokosch
Nemokosch But this is such a minor detail that I wouldn't introduce a language change for that. Where would this approach lead to? 20:13
ugexe One thing that comes to mind is it’s odd that .do and .&do would be different 20:28
I dunno if there even is a .&do though and I can’t check at the moment 20:29
vrurg m: $v = 42; say $v.&do(* + 2); 20:42
camelia ===SORRY!=== Error while compiling <tmp>
Variable '$v' is not declared. Perhaps you forgot a 'sub' if this was
intended to be part of a signature?
at <tmp>:1
------> <BOL>⏏$v = 42; say $v.&do(* + 2);
vrurg I don't see what would be the real use for such q .do. Besides, 20:46
Besides, `do {...}` has different semantics and that would be confusing. 20:47
If there is use for such method then we'd better follow Seq and name it snitch. 20:48
timo1 .o( like given but backwards ) 20:56
Nemokosch .&{}, andthen, given... 21:56
vrurg andthen has 'with' semantics. 22:02
I see why one would like to have something in a method call chain. So, it's rather a matter of naming the method.
*something like that 22:04
Nemokosch let's be honest. How often does anybody want to topicalize to something undefined? 22:39
and if somebody does want that, is something that looks like a chained method call, really the best idea to express it 22:40
anyway, if the only supposed difference to .&{} would be that the return value is always the object it's invoked upon, then please don't, for the social aspect. It's a very bad precedent of pushing extremely redundant interfaces into the core language. 22:42
vrurg self.first(&condition).snitch({ die "oops!" if bad-value($_) }).then.some.more.methods 22:53
lizmat I've closed the PR
docs.raku.org/routine/snitch.html does all of this already
vrurg Oh, my... I missed the non-Seq candidate of it. Of course! 22:55
BTW, I had a use for it not so long ago and felt pity of it being a Seq only. OK... :) 22:56
Nemokosch > self.first(&condition).snitch({ die "oops!" if bad-value($) }).then.some.more.methods couldn't this be completely complemented by .&{ die "oops!" if bad-value($); $_ }.then.some.more.methods ? 22:59
vrurg One would have to remember to add that $_ at the end. Besides, my personal opinion: it reduces code accuracy, adds extra noise to it. 23:12
Nemokosch I think this is a very slippery position. At the end of the day, every time there isn't something built-in for what one wants to do exactly, one needs to remember the exact code composition that does just that. Back to case of .&{} - there is nothing obscure, unexpected or structurally inconvenient (e.g no new syntactical unit added to the code) about adding $_ there, if that's what the author meant. And this is actually the 23:23
beauty of it: at the cost of setting the return value of a block (which is something people do all the time), different effects can be achieved using the same structure. It's only "noise" if we assume there is no choice to make.