00:16 Sgeo joined
Voldenet hm, TEMP block is actually an interesting concept 00:27
m: my $next = 0; sub next { my $curr = $next++; if @*temps[0] { @*temps.push({ $next = $curr }) }; $curr }; my @*temps; say next(); say next(); say next(); if True { my @*temps; @*temps[0] = sub{}; say next(); @*temps[0] = Nil; say next(); say next(); for @*temps { .() if .so } }; next(); say next(); # example from Temporization design docs
camelia 0
1
2
3
4
5
4
Voldenet m: my $next = 0; sub next { my $curr = $next++; if @*temps[0] { @*temps.push({ $next = $curr }) }; $curr }; my @*temps; say next(); say next(); say next(); if True { my @*temps; @*temps[0] = sub{}; say next(); @*temps[0] = Nil; say next(); say next(); for @*temps { .() if .so } }; say next(); say next(); # example from Temporization design docs 00:28
camelia 0
1
2
3
4
5
3
4
00:34 kst joined
Voldenet basically the consuming code sets itself up as "temporization scope", runs some code, then completes the scope using given block 00:35
so the restoration can be explicitly described - it's a lot more than "let/temp" because it is possible to restore the state file to its previous state for example 00:38
and if I understand correctly, the scope can be as deep as needed with a lot of restore procedures
01:00 sibl joined 01:13 ds7832 left, ds7832 joined 01:22 ds7832 left 02:15 derpydoo joined 02:45 kylese left 02:46 kylese joined 02:57 arkiuat left 03:00 sibl left 03:01 sibl joined 03:05 arkiuat joined 03:10 arkiuat left 03:14 arkiuat joined 03:15 kylese left, kylese joined 03:22 sibl left, sibl joined 04:07 lichtkind joined 04:09 lichtkind_ left 05:19 human_blip left 05:20 human_blip joined 05:28 arkiuat left 06:17 Aedil joined 06:30 atcroft left 06:31 atcroft joined 06:41 constxd left 06:43 constxd joined 07:39 derpydoo left 07:50 Sgeo left 08:24 sibl left 08:26 sibl joined 09:09 dakkar joined 10:08 sibl left 11:57 sergot left 12:02 librasteve_ joined 12:36 oodani left 12:37 oodani joined
[Coke] TPRC 2026 will be in Greenville, SC, USA on June 26th-28th (25th-29th for the ambitious). tprc.us/ 13:31
I am not currently considering attending. 13:32
(it's the same venue as last year)
lizmat sadly, I would have to recommend not attending unless you're a white US citizen :-( 13:35
[Coke] Oh, certainly wouldn't expect anyone to come from abroad. :| 13:40
FWIW, the surrounding area was nice enough, good food, the venue was fine for the size of attendence. 13:41
El_Che lizmat: we're at the stage that being white does not protect you from fascism 13:53
tellable6 2026-01-24T19:29:04Z #raku-dev <jdv> El_Che the 2026.01 release happened
El_Che ah damn
will roll it
nemokosch something something "be the change" something 14:35
14:56 arkiuat joined 15:21 Sgeo joined
lizmat El_Che: true 15:22
15:31 oodani left 15:36 oodani joined
El_Che pkgs build fine,but cloudsmiths need to create opensuse lea 16 repo 15:47
they do it quickly normally
lizmat El_Che++ 15:53
aruniecrisps Perhaps we could have a separate Raku meetup? 16:07
Even if it's virtual
lizmat well, there's this Sat meeting wrt to problem solving issues
aruniecrisps Ah I won't be able to attend that one 16:08
nemokosch anyway, even without organizing a formal-ish meetup, there can be conference calls or talking on discord voice chat 16:14
just like there is also the Raku Study Group 16:15
not always Raku, not always study, it's more of an informal computer science gathering of a bunch of people on Zoom
that's basically the virtual successor of the San Francisco Perlmongers meetup 16:16
lizmat weekly: hackaday.com/2026/02/03/ysgrifennu...-in-welsh/ 16:20
notable6 lizmat, Noted! (weekly)
17:10 hvxgr left 17:25 hvxgr joined 17:35 arkiuat left 17:38 dakkar left
[Coke] do folks on non raku projects ever go through and clean up stale branches? 17:42
17:46 arkiuat joined 17:50 arkiuat left
antononcube They should. 17:50
[Coke] Yes, but *do* they. :) 17:51
I had a $dayjob once with 100s of repos and some with 1000s of branches because of a permission issue on PR closing. 17:52
and I made a stink to get them cleaned up, and no one seemed to care. :)
antononcube I really don't know. The other two package repositories I (semi-)frequently submit packages to are completely left to the users/submitters. (PyPI.org and Wolfram Paclet Repository.)
Or, I see. 17:53
Hmm... In the companies I work(ed) for the developer take care of this. But branches might be kept "for posterity" and refer to historical advancement. 17:54
nemokosch I also don't like stale branches, too obsessive 17:56
if my PR's don't get merged for a long time (can easily be years in the FOSS world), eventually I close them 17:57
different topic: did you know that this works?
lizmat yeah, but closing them doesn't necessarily mean the branch is removed
nemokosch m: my $test = "Int"; 12.3."$test".say;
lizmat m: my $test = "Int"; 12.3."$test".say; 17:58
camelia ===SORRY!=== Error while compiling <tmp>
Quoted method name requires parenthesized arguments. If you meant to concatenate two strings, use '~'.
at <tmp>:1
------> my $test = "Int"; 12.3."$test"<HERE>.say;
nemokosch oops, discord might have swallowed the backslash
add a backslash after the interpolated string
lizmat m: my $test = "Int"; 12.3."$test"\.say;
camelia 12
nemokosch that was meant to be the peculiarity
lizmat m: my $test = "Int"; 12.3."$test"().say; 17:59
camelia 12
nemokosch it's not obvious to me why the backslash works
lizmat you need to indicate it's a method call.... either by () or apparently \
nemokosch I mean, from the grammar it's expected but why is the grammar like that?
lizmat m: dd 42\.Str
camelia "42"
lizmat seems to work basically always ? 18:00
nemokosch could be but is there some sort of story behind it?
it seems quite obscure
18:20 arkiuat joined 18:25 arkiuat left 18:35 arkiuat joined
arkiuat I added a comment to issue 504 re the introduction of Cool behavior to div and mod that apparently inspired the 2024.02 "breakage" github.com/Raku/problem-solving/is...3855636822 19:20
nemokosch please note that the performance argument applies at the actual division itself, not the coercions 19:26
if you have inputs '5' and '3' and you want to integer divide them, you have to coerce either way, with any operation
the question is just who does it
arkiuat right, but if the div and the mod are inside a tight loop, you want to make sure the conversion is done before the loop is entered. 19:27
So makes no sense to have div and mod do the coercion
nemokosch what I reckon none of us know is what the cost of the dispatch is
I can't see an outcome where we don't have multi dispatch at all
arkiuat the point is that div and mod are obvious exceptions to many general rules, otherwise they wouldn't exist: we'd just use / and % for everything instead
nemokosch it makes a difference, though, what rules they are exceptions for, and why 19:28
and in my opinion the performance argument is not sufficiently backed for the coercion
if you can say for sure that merely adding a coercive candidate next to a plain Int candidate has a large overhead, that would be an argument 19:29
but I don't think any of us could tell that offhand
arkiuat it might not be sufficiently backed if there were a way to coerce Str that map to Ints without also truncating Str that map to Reals that aren't Int
lizmat "So makes no sense to have div and mod do the coercion" I think that's the reason TimToady originally suggested that there'd be no coercion
nemokosch I think there is a whole lot of speculation here 19:30
lizmat so you'd know as soon as possible that you were doing it wrong
arkiuat S03 says that div and mod don't coerce. It doesn't spell out the reasons why, but I think the burden of proof is one those who would relax that stipulation, not the other way around. I don't think your case has been made.
lizmat, yes, exactly
lizmat knowing TimToady's C and bash background, I think that's a bit more than speculation
nemokosch arkuiat: even if S03 gives no argument?
arkiuat nemokosch, yes. 19:31
nemokosch I think compared to that it's quite a fair argument that gcd and lcm also work like this
if this is good behavior for them, why not for div?
arkiuat not a reason to relax a stipulation that was made quite specifically
nemokosch with no reason given, though 19:32
lizmat Converts both arguments to an integral type and then finds the largest integer
that both arguments are evenly divisible by, and returns that integer.
arkiuat if anything, that might be a reason to think that perhaps they just overlooked making a similar stipulation for gcd and lcm
nemokosch they are equally likely
arkiuat I don't think so
nemokosch but now we are just arbitrarily speculating in one direction
lizmat well, there's the fact that gcd and lcm are not really simple machine ops
afaik
nemokosch let's instead do a measurement at least 19:33
arkiuat nemokosch, please do the measurement.
that would be putting the burden of proof where it belongs
nemokosch I don't think anybody should get the upper hand in mere speculations
arkiuat and then figure out a way to convert Str to Int that doesn't also incidentally Strs that encode Reals that aren't Ints
incidentally truncate, that is
nemokosch after all, I didn't imply that a coercive overload would make div too slow (compared to the pre-2024.02 case) 19:34
arkiuat I'm afraid that's the pot calling the kettle black, nemokosch. The change in 2024.02 relaxing S03's stipulations was made on the basis of speculations that were never adequately supported by testing and evidence.
nemokosch I think it is a definite difference that I have at least something we can tell for a fact 19:35
arkiuat lizmat, good point
furthermore, the change in 2024.02 wasn't treated as a breaking change when it fact it broke any code out there (apparently not in published modules because Blin accepted the change) that relied on div and mod raising errors where now they just coerce 19:36
nemokosch also, I agree that perhaps random commits of breaking changes shouldn't go upstream; I never suggested that 19:37
but if we are to decide on something, don't hastily decide based on mere speculations
arkiuat what's done is done, but I thought you were arguing against undoing it
I think it's the initial doing that was done hastily
nemokosch I think even undoing it might be better than the current situation but I wouldn't accept it as a permanent, informed design decision 19:38
it really isn't that, after all
arkiuat the permanent informed design decision is in S03.
we can change, but we need to have very good reasons for doing so. Currently, I don't see any such reasons. 19:39
nemokosch no, it's not there and you know that: you point out there is no reasoning given, and it's not implemented for more than a decade
arkiuat providing the convenience of Cool for two operators that are obvious exceptions to other similar general expectations isn't such a reason, for instance
nemokosch if we can agree on the primary facts, why can't we even agree on the secondary, direct conclusions?
arkiuat whether or not reasoning was added to an already very long spec document has nothign to do with it. It's still a record of the design decision that was made. 19:40
obviously they edited anything out that wasn't directly relevant to providing guidance for writing the initial roast tests 19:41
nemokosch also, Cool has virtually nothing to do with this, for what it's worth
arkiuat I'm just invoking Cool as shorthand for the idea that div and mod should accept s
Str args
nemokosch so what is your principle? backwards compatibility? we have already broken that for years 19:42
also, backwards compatibility imo would still allow for considerations for the future
what I'm gathering is that for you, if something is just, say, 10% better than it used to be, that's not enough 19:43
but then what is in the other side of the scale? 19:44
arkiuat I don't know why you're pretending confusion about the principles that I'm arguing from. I think I've laid them out pretty clearly both here and in comments in issue 504
nemokosch but those are already answered 19:45
arkiuat 10% better? I don't even use mod at all anymore, because there's no point to it. I just use % and .floor instead. It's 100% worse
nemokosch for what it's worth, I think we see literally no point to mod 19:46
unlike div, it's not a common operation
arkiuat If you want to abolish div and mod, then argue for that directly.
But given that they do exist, I think they should behave as specified in S03. 19:47
nemokosch "I don't know why you're pretending"
div and mod are two different cases: div is useful, mod not really
I have never said otherwise
arkiuat I found mod useful, that's why I was distressed when I discovered that it wasn't behaving as specified and stopped using it. 19:48
nemokosch what benefit did it have over just using % ?
arkiuat This was like five months ago, and it's irrelevant 19:50
a stated design decision was overturned carelessly for bad reasons.
nemokosch it's not irrelevant, this was a clear chance to say something that I can understand and acknowledge
it was a chance for the discussion to move forward in a constructive way
arkiuat I'm sorry you can't understand and acknowledge the *relevant* points that I've already made 19:51
You are familiar with the term "derailing", are you not?
nemokosch I could understand them hopefully and I didn't find them convincing
anyway, would you please refrain from steering this in a personal direction? 19:52
arkiuat I'd be happy to do so if you would address the points that I've actually made. 19:53
nemokosch which point do you consider unaddressed?
no idea what changed but now, with company VPN turned on (šŸ˜¬) I could submit a comment 20:21
hooray
20:31 Aedil left
aruniecrisps question, is COERCE still the modern raku standard or is it not? 20:34
lizmat it is, but most of the documentation still lives in vrurg's blog posts :-(
aruniecrisps how do i go ahead and help with adding that documentation to the raku site? 20:35
nemokosch actually, I noticed something very strange
% does use mod_i for integers that fit
/ doesn't do anything similar 20:36
is it possible that % and mod are actually closer in performance than / and div? 20:37
lizmat aruniecrisps by converting vrurg's blog posts into documentation pod ?
nemokosch % seems to outright slightly beat mod.... 20:40
okay, I did it stupid but still, % barely loses to mod 20:42
oh right, / doesn't do this because it's not allowed to 20:45
to be frank, / might be so slow that even $a %% $b ?? $a div $b !! $a / $b might be a win on average 20:47
lizmat please gist the code and the benchmarks you've seen 20:48
nemokosch is Rakudo v2025.12 good enough? 20:50
lizmat yes
20:56 arkiuat left
nemokosch gist.github.com/2colours/99d514f8f...38eb62ca3f 21:09
the results to push certainly have an influence on the runtime because mod can come out faster than div what it's derived of 21:12
21:13 arkiuat joined
arkiuat cool! now I wonder what the same benchmark would look like for 2024.01 21:45
nemokosch this might be your lucky day 21:49
updated 21:55
okay, great... everything got faster for no apparent reason 21:56
at the very least the numbers are relative to each other
I'm inclined to say these are the same numbers with a margin of error 21:59
anyway, point in case: the tendencies between the operators are the same
22:29 oodani left 22:30 oodani joined
"everything got faster" - probably I connected the charger some time between the two measurements; I could update all of them to plugged if you wish 22:32

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!