02:57 arkiuat left 03:05 arkiuat joined 03:10 arkiuat left 03:14 arkiuat joined 05:28 arkiuat left 12:02 librasteve_ joined 14:56 arkiuat joined
arkiuat it occurs to me that since `mod` has been broken for years, and this has been openly discussed for the last two months without any sign of anyone prioritizing a fix for it (instead we've been trying to attain consensus on what the fix should look like), shouldn't we mention that in the doc for `mod`? 16:40
nemokosch I always come back to the point that mod is derived from div and therefore if there is anything to change, div should change first 16:45
arkiuat I mean, if I end up trying to submit a rakudo PR to fix it myself, I'd want to update the doc to say that it was broken (and maybe exactly how) after release 2024.02
might as well do that now
nemokosch its documentation is also outdated for sure
arkiuat yeah, but I'm just talking about documentation of an existing bug. Not about changing code, and nothing to do with `div` whatsoever
nemokosch it has everything to do with div because it literally calls div 16:46
arkiuat I'd want to update the doc BEFORE trying to write a rakudo PR, certainly. So I may as well do it now, right?
nemokosch we are not talking about a coincidence, one can predict this behavior
arkiuat yes, but I'm talking about documenting an existing but that was introduced without modifying div.
Why are you derailing?
nemokosch it's not a "bug"
arkiuat s/but/bug/
nemokosch it's a perfectly deterministic consequence 16:47
arkiuat yes, but it's not what i'm talking about. Why are you pretending otherwise/
nemokosch we may dislike it but it's simply not true that it "doesn't do what it's supposed to"
lizmat so you're saying it *is* doing what it is supposed to ? 16:48
or do we have a different definition of "bug" ?
arkiuat not only an existing bug, but a bug that has been in the release for about two years now
that certainly ought to be documented, right?
nemokosch again, it's not a bug
arkiuat nemokosch, the theme you are taking up is not appropriate to this channel. It belongs elsewhere, probably on #raku. This is #raku-doc 16:49
lizmat well, it's 2 to 1 at least here, who are saying it *is* a bug
nemokosch would you bother to listen
arkiuat if you want to argue that mod is not buggy, please do it on #raku or #raku-dev or somewhere other than #raku-doc 16:50
nemokosch wait for me to finish
or at least don't draw conclusions from something that you have pre-decided
arkiuat the problematic behavior of `mod` was introduced without modifying `div` at all.
you are off-topic
nemokosch the documentation of div is wrong, that's for a fact 16:51
arkiuat okay, please stick to that point then.
nemokosch mod is defined as a - (a div b) * b
mod works as defined
arkiuat defined where? by whom? by S03?
nemokosch both by that and the sources
arkiuat what's wrong with the documentation of div exactly? 16:52
nemokosch the signature
lizmat multi infix:<div>(Int(), Int() --> Int:D)
nemokosch now, one may want to add, kind of like a trap, that from these rules, it currently follows that 10 mod 1.9 is -9 and all that
lizmat would be more correct, ondeed 16:53
nemokosch but saying that "there is a bug in mod" or "mod is broken" is just bad marketing for no tangible benefit or understanding as to what is going on
lizmat "mod is defined as a - (a div b) * b" where is that the case, in the code? 16:54
nemokosch github.com/rakudo/rakudo/blob/8587...kumod#L144
arkiuat S03 specifically stipulates that both mod and div should fail if the types of their two arguments differ 16:55
so 10 mod 1.9 should be an error 16:56
lizmat arkiuat: agree
nemokosch that certainly doesn't happen though
while 10 mod 1.9 === 10 - (10 div 1.9) * 1.9 does happen, it's in the sources fair and square 16:57
lizmat and the sources could be wrong
arkiuat only since it was decided to make the source and roast deviate from S03, two years ago
nemokosch they could be but the documentation is not really the place to say that, especially with regards to this identity
it's really overboard 16:58
arkiuat 10 % 1.9 == 0.5
okay, fine, let's attain consensus that that 2024.02 implementation is incorrect, first, THEN attain consensus on how to fix it, and only THEN document it.
I concede that you were not off-topic, sorry. 16:59
nemokosch or like let's be practical about it: say that the documentation were to include "mod has been buggy for two years"
the logical question is: "if you know it's buggy, why not fix it?" where is the bug in mod, and where is the fix? 17:00
arkiuat the point is that there was a breaking change in mod's behavior that was silently introduced two years ago.
people who developed code relying on the earlier behavior would have unexplained breaks introduced
nemokosch correct me if I'm wrong but I think mod also outright refused the arguments that are now creating problems 17:01
so exactly the same situation in this regard as div
arkiuat yes, and some code might *rely* on that being an error. 17:02
and yes, now I see your point about div too, finally
nemokosch yes, that's for sure, it was a breaking change 17:03
and that breaking change is causing the uglier results when calling mod, that's also true 17:04
but at the same time, that's not mod's fault, is my point
arkiuat right, but the doc is unsatisfactory at this point, and that unsatisfactoriness likewise has been in place for two years now. 17:07
nemokosch well, that's also true :\
it's kind of a cripple situation, it's not caused by ignorance, the issue is well understood 17:08
arkiuat so what should be done to patch up the doc in the meantime, because that's easier to do first 17:09
?
nemokosch well, the way I would go about it is 17:10
say you want to add like a "trap" remark to mod, in the spirit of 10 mod 1.9 == -9
lizmat FWIW, I think the documentation is correct, and the implementation should be made to match the documentation 17:11
nemokosch I would still attach a short explanation that this is because of the truncating behavior of div under the hood
and then the signature of div should still change, plus a note about the same truncating behavior
lizmat no, because as with mod, div should just accept Ints (in its various forms) 17:12
nemokosch if the behavior were to be reverted pre-2024.02, I would open the same issue as I did in 2022, except with Numeric in the title 17:13
because I still think rejecting '5' div '3' is wrong
lizmat I could live with a Int(Str) coercion 17:14
nemokosch doesn't that accidentally pick up '5.4' or something like that? 17:15
I wouldn't know by heart
lizmat m: sub a(Int(Str) $a) { dd $a }; a "3.14" # yeah
camelia 3
lizmat *sigh*
nemokosch I'd say Numeric(Str) and then only have an overload for Int 17:16
so other numeric coercions will eventually fail just like back then
shimmerfairy I don't know what the original complaint is exactly, but div to my understanding has always been about doing integer-only division (or in other words, the C / operator with perhaps a different choice in result rounding). So it only accepting Ints makes sense to me. 17:17
lizmat yeah, thinking about this some more, I think the choices really are: Int:D or Int()
nemokosch my objection is that Raku does a lot of juggling to get to numbers, in particular you can just call gcd or lcm on strings 17:18
it feels very odd that div just decides to be the odd-one-out
lizmat fwiw, I've just removed the "multi sub infix:<div>($a, $b --> Int:D)" from core to see whether any test would break 17:19
and the answer is: no
nemokosch for reference, this is what gcd does: github.com/rakudo/rakudo/blob/8587...kumod#L273 17:20
shimmerfairy Yeah, I tried "3" + "7" just now and it surprisingly worked. I think consistency would be good, though I'd rather there weren't magic string->int conversions instead. (Can't recall the last time I relied on that, if ever.)
nemokosch .Numeric.Int... Int-eresting
I'd imagine it's quite common in the Raku-verse because at the end of the day, this is the organic Perl heritage 17:21
[Coke] I wouldn't link to any problem solving bugs from the docs. We had discussed ages ago about linking to rakudo bugs - and I agree there if a bug is critical, it might be worth mentioning, but as a general matter, we shouldn't be linking to the bugs from the docs.
It's fine to have a raku/doc issue open that points to a rakudo, spec, PS bug that says "when this is resolved, let's make sure the docs are up to date" 17:22
there are so many open tickets, I wouldn't prioritize fixing something that we think has a good probability of changing. Once our # of open bugs goes down, then we can try to be more proactive and keep things up to date.
shimmerfairy Yeah, it's almost certainly one of those "too late to change" things, but I feel any programming language or adjacent system that lets you treat strings as numbers implicitly is just begging for trouble. (At least for operations like == they have non-coercing equivalents.) 17:23
[Coke] In the meantime, I would like to keep focusing on the tickets in the next milestone (and we can discuss what goes in a milestone or not), or things that are easy wins.
shimmer: I wonder if a mode that avoided Cool and was therefore more strict about types would be better in some metric. 17:24
nemokosch the strong/weak typing discussions I think are interesting but 1. certainly don't belong here 2. the inertia is indeed huge
[Coke] But that seems a very big mod (and we have so much other stuff in the queue) 17:25
nemokosch "things for v6.h"
😄
shimmerfairy That wouldn't be a bad idea at first glance. Finally we can use strict; once again! (But yeah, definitely a bigger idea that's a bit too soon to discuss today.) 17:28
lizmat I think we need to get back to why "div" and "mod" actually exist, next to "/" and "%" 17:29
nemokosch for div, I think the answer is (for at least 13 years): fast integer division is useful 17:30
lizmat dinner& 17:31
nemokosch 6 div 3 is quite a bit faster than 6 / 3
shimmerfairy I don't think I've ever used mod, but div is convenient for divisions where you only want an integer answer. Any scenario where you'd use / in C or C++ and not feel compelled to cast an argument to floating point, basically. 17:32
nemokosch 5 div 3 is probably even more faster than (5/3).floor (hope I got it right) 17:33
17:35 arkiuat left
anyway, I feel a bit awkward that we are bombing the doc chat now 17:35
shimmerfairy If I could magically make one change to div and mod and not have it cause problems with old code, I'd change them to return the same answers as C/C++, essentially truncating instead of rounding. The logic behind this is that it makes it easier to do math where you need to agree with what some piece of C code is doing. That would of course ruin things for people who liked the rounding those operators currently do. 17:36
(Perhaps an argument for an adverb, e.g. -5 div 2 :c) 17:37
nemokosch as far as the docs go, I think Coke pretty much made the call 17:39
[Coke] speaking of milestones, bumped all the 2025 tickets to Q1 2026. 17:41
nemokosch looking at github.com/Raku/doc/issues/4042 for example 17:43
it links to docs.raku.org/language/objects#:~:...%20runtime which then says
"Method names can be resolved at runtime with the ."" operator (...)" 17:44
but there is no ."" operator entry
I don't even know how I would look it up
right, Steve even points this out in the comment 17:45
more or less
17:46 arkiuat joined
[Coke] anything related to search functionality should be on doc-website, not doc. (unless it's just "add an index entry so we *can* search it" 17:46
if it's "search doesn't work to find this thing that is in the docs already", that's usually a website issue. 17:47
nemokosch yeah no, I don't think it exists 17:48
that's just usually harder to confirm
[Coke] mmm. 17:50
17:50 arkiuat left
[Coke] btw, here's everyone who has a branch in raku/doc - if your name is on the list, please let me know if we can delete any of them: 17:50
gist.github.com/coke/79f44c657a37b...70a9f1ca4a
Interesting that I'm on the list 3 different ways. 17:52
edited to show dates and branches. 17:53
lizmat is there an easy way to see whether these branches would conflict with the main branch now ? 17:55
[Coke] You can list all branches that are already merged easily. I don't think there's an easy way to see if there are merge conflicts without doing it. 17:56
Last time I tried to do some cleanup here I would try to do the rebase locally, and if that worked, force push it back and defer the decision to keep the branch or not 17:57
removed no-faded-camelia 17:58
OH - that list includes branches I cloned once but are now removed from upstream... cleaning up that list... 17:59
fixed 18:01
Geth doc/main: 8dc98e7297 | (Elizabeth Mattijsen)++ | 8 files
All CX:: packages are classes and not roles
 18:03
[Coke] That should have been catchable by the signature xt test (but wasn't) 18:05
looks like most of those are from JJ in 2019.
lizmat looks like updated-modules-setup isn't merged yet 18:17
Geth doc: coke++ created pull request #4765:
Update modules setup for zef | fez		 18:20
18:20 arkiuat joined
[Coke] I can try to get it merged, you OK with that? 18:21
lizmat yup
lizmat-lose-compose also isn't merged it seems
[Coke] Just created a PR to track it
lizmat pretty sure there must already be a PR for it
otherwise I don't create branches :-)
[Coke] it wasn't on the list of PRs. 18:22
Might have been closed at some point, that's possible.
list of *open* PRs.
lizmat rakuast-links doesn't appear to have been merged? 18:24
18:25 arkiuat left
lizmat ok, removed all of "my" branches that I think could be removed 18:26
[Coke] ah, probably easier to do updated-modules-setup by hand at this point.
lizmat++
lizmat: I think update-modules is actually outdated after the last rewrite of doc/Language/distributions/uploading.rakudoc 18:29
lizmat then by all means, kill it with fire! :-)
18:35 arkiuat joined
Geth doc/lizmat-lose-compose: 38785fd1a8 | (Elizabeth Mattijsen)++ (committed by Will Coleda) | doc/Language/phasers.rakudoc
Lose mention of COMPOSE phaser

Associated with github.com/rakudo/rakudo/pull/5193
Note: there are *NO* tests for the COMPOSE phaser		 18:39
doc: coke++ created pull request #4766:
Lose mention of COMPOSE phaser
doc/main: 03ebc96a21 | (Will Coleda)++ (committed using GitHub Web editor) | doc/Language/phasers.rakudoc
Lose mention of COMPOSE phaser (#4766)

Associated with github.com/rakudo/rakudo/pull/5193
Note: there are *NO* tests for the COMPOSE phaser
Co-authored-by: Elizabeth Mattijsen <liz@raku.rocks>
nemokosch github.com/Raku/doc/issues/4042 if you agree with the comment, you could assign this to me 18:42
Geth ¦ doc: coke assigned to 2colours Issue Missing Entry for A."$m"() github.com/Raku/doc/issues/4042 18:43
[Coke] All yours!
Geth doc/main: bb4981c8af | (Will Coleda)++ | t/22-links-not-links.rakutest
Add test to avoid non linked URLs.
 18:51
[Coke] lizmat: saved rakuast-links, thanks, forgot I wrote that. 18:52
Geth ¦ doc: coke self-assigned Prefer time zone or timezone? github.com/Raku/doc/issues/4741 18:55
doc/main: 94f523554e | (Will Coleda)++ | 5 files
Add "timezone" as our preferred variant

  * Fix all instances in the docs
  * Closes #4741		 18:57
nemokosch with github.com/Raku/doc/issues/4058 - I feel that we've been eyeballing this issue for a long time but it's not clear what to do. It's more of a terminology issue. 19:03
Geth ¦ doc: coke self-assigned Clarify idiomatic use of CATCH github.com/Raku/doc/issues/3810 19:04
¦ doc: coke self-unassigned Clarify idiomatic use of CATCH github.com/Raku/doc/issues/3810
¦ doc: coke unassigned from Altai-man Issue "Test" module is documented as a type github.com/Raku/doc/issues/3686 19:05
[Coke] arkiuat: do you think github.com/Raku/doc/issues/3439 is still needed or did we resolve that under a different PR? 19:06
arkiuat: were you the one working on routine/sub cleanup? 19:10
We also have github.com/Raku/doc/issues/2308 from the archives.
arkiuat [Coke]: wayland's rewrite did a lot to address 3439, but I'd have to give the issue a good reread while looking over the new material (and it's mostly just rearrangement) from wayland before I could say that the issue should be closed 19:15
and yes, I was working on the routine/sub cleanup, but we should put at least one of those issues as a near-term milestone if we want me to keep working on it. 19:16
there's a lot: it might make more sense to make separate issues on that point for each of the larger classes so we could milestone them one at a time (Mu is done, I think, but there's still Any and Cool and several others that need that kind of work) 19:17
nemokosch re evaluation model - I'm starting to think that precedence and associativity is simply not about "evaluation order of the operands" 19:18
precedence and associativity is about knowing what the operands of a certain operation even are 19:20
1 + 2 - 2 * 3 it's not that you have to calculate 2 * 3 == 6 earlier than 1 + 2 == 3, nothing says that 19:22
it's that you know it at all that your subtraction has operands 1 + 2 and 2 * 3
arkiuat I still think that issue 4058 is badly in need of renaming. The discussion has moved the issue pretty far from what the current title suggests 19:24
I'm reading through 3439 right now 19:26
Geth ¦ doc: coke self-assigned Right-hand side of *what*? github.com/Raku/doc/issues/2116 19:27
[Coke] arkiuat: I'm ok if you rename it 19:40
arkiuat yeah, I suggested a very long name, but I think condensing that down to something that will fit in one line should be left to someone who is more involved in that issue 19:49
it's in my comment on the issue, which is currently the latest
[Coke] I shortened it immensely 19:50
arkiuat [Coke]++ 19:54
also, after my reread, I think 3439 can be closed. They're talking about CPAN where any contemporary raising of that issue would be talking about zef instead 19:58
if someone needs more and better tutorial on how to publish a module, I think it would be more productive for them to make a new issue afresh. There's not much value from keeping that snippet of history attached to it 19:59
so I'm thinkin about changing the title of github.com/Raku/doc/issues/4560 back to make it Mu-specific and closing it. I still have 2308 assigned to me, and that's Cool specific 20:01
[Coke] OK 20:02
arkiuat If I still think I should work on the sub/method/routine cleanup in Any before Cool, I can create an issue for Any and we can milestone that.W
renamed 4560 while stating criteria for me to close it next time I get back to it. since 2308 is open and assigned to me, I'll wait to create a sub/method/routine labeling issue for class Any at the time I get back to working on that 20:08
I'm going to milestone 4560 since I think it's almost closable 20:16
nemokosch added a comment to 4058 that might makes it actionable, the tldr is the last paragraph 20:17
arkiuat nemokosch, sorry, but I'm struggling to parse "I don't know if "evaluation order" as such we already have at all as a topic" 20:25
what does that mean?
nemokosch is there any place where the docs write about "evalutation order in Raku" or such? 20:26
arkiuat might be clearer to edit it to say it that way then
nemokosch other than that poor sentence that imo tried to be about precedence and associativity rather than "evaluation order"
alright 20:27
okay, I changed the sentence, hopefully for the better 😛 20:52
20:56 arkiuat left 21:13 arkiuat joined
arkiuat that is somewhat clearer now, thanks 21:21

Powered by Cro and the Raku® Programming Language.

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

Thank you!