šŸ¦‹ 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.
00:00 reportable6 left 00:01 reportable6 joined 01:26 japhb left 01:31 japhb joined 01:36 japhb left 01:48 japhb joined 05:39 shareable6 left, statisfiable6 left, benchable6 left, squashable6 left, reportable6 left, nativecallable6 left, sourceable6 left, unicodable6 left, committable6 left, tellable6 left, bloatable6 left, evalable6 left, bisectable6 left, greppable6 left, quotable6 left, releasable6 left, coverable6 left, notable6 left, linkable6 left, evalable6 joined 05:40 benchable6 joined, tellable6 joined, squashable6 joined, shareable6 joined, sourceable6 joined, greppable6 joined, committable6 joined 05:41 bloatable6 joined, quotable6 joined, coverable6 joined, unicodable6 joined, reportable6 joined, linkable6 joined 05:42 statisfiable6 joined, nativecallable6 joined
SmokeMachine \o/ I was missing that .do for a very long time!!! 05:42
05:42 releasable6 joined, notable6 joined, bisectable6 joined 05:50 initrd joined 06:00 reportable6 left, initrd left
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
06:03 reportable6 joined, japhb left
SmokeMachine Even this message ^^ I can see tellableā€™s answer, but not my messageā€¦ 06:04
06:04 japhb joined
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
06:08 initrd joined
SmokeMachine Should we close this then? github.com/Raku/problem-solving/issues/122 06:21
06:43 japhb left 06:44 japhb left, japhb joined 09:19 initrd left
Nemokosch Why is .&{} not enough? 10:06
10:40 linkable6 left, evalable6 left, evalable6 joined 10:43 linkable6 joined
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?
10:57 codesections left, codesections joined
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?
11:04 Xliff joined 12:00 reportable6 left 12:03 reportable6 joined
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
12:36 Guest10 joined 12:37 Guest10 left, Guest10 joined, Guest10 is now known as XliffMac
Geth rakudo/main: b8488d24d3 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add adverb handling to RakuAST::QuotedRegex .raku/deparsing
 13:14
13:26 XliffMac left
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
13:52 ab5tract joined, ab5tract left 13:59 Guest10 joined 14:00 Guest10 left 14:02 Guest10 joined, Guest10 is now known as XliffMac 14:14 XliffMac left 14:34 jacob_c left 14:36 Guest10 joined
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.
14:58 jacob_c joined
Xliff Note parallel time increase of over 900 seconds. 14:58
from the 27th of last month, which was ~1400 seconds.
14:59 Xliff left
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
15:03 Guest10 left 15:05 Xliff joined
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.
15:13 jacob_c left 17:55 Xliff left 18:00 reportable6 left, reportable6 joined 18:26 jacob_c joined 18:33 jacob_c left 19:28 codesections left 19:46 guifa_ joined 19:49 guifa left
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!