🦋 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.

Powered by Cro and the Raku® Programming Language.

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

Thank you!