00:08 Voldenet left 00:35 Voldenet joined 01:02 kjp left 01:04 kjp joined 01:06 kjp left 01:07 kjp joined 01:22 Voldenet left 01:32 Voldenet joined
releasable6 Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
09:07 sena_kun joined 09:47 [Coke] left 11:43 [Coke] joined
[Coke] oops. my trying to build raku on my windows laptop left me without a working raku. Just went to run something that I forgot I wrote in raku, boom. 13:44
lizmat I get that a lot :-) 13:45
the hourly REA harvester is then the victim
patrickb rakubrew to the rescue? 13:47
lizmat nah, I usually nuke the install dir and start from scratch
[Coke] I should have separate "I'm using raku" builds from "I'm building raku" builds, but I don't on my windows box, either. 13:48
... and since I successfully built moar we've bumped the revisions so it's too old. The perils of living at HEAD 13:49
lizmat yup :-)
[Coke] tries rakubrew on powershell to see if that separation works. 14:00
patrickb [Coke]: If it doesn't work, I'd like to hear about it. Powershell is one of the shells I want to support in rakubrew. 14:30
[Coke] patrickb: so far so good. I haven't gotten to the point in the build where my manual build dies yet 14:35
powershell always surprises me when it works, I have so much experience with CMD being painful. :)
patrickb Did you know that you can register some existing folder with a build in it as a version in rakubrew? 14:36
I tend to have a 'build' version that points to the folder where I do development. 14:37
[Coke] yes.
nope. nothing magical about the rakubrew build on my box - can't build raku moar-2024.10
so, still need to fix the build process (or use the installer) 14:38
patrickb rakubrew download moar-2024.10 would at least give you something to continue working with...
[Coke] "already installed" except it isn't. 14:39
apparently it marked it as installed even though the build died?
ah. list shows BROKEN, but you still can't download over it. 14:40
patrickb Ah. Yeah. rakubrew nuke moar-2024.10 should solve that.
[Coke] ok - that was pretty painless for the download, thank you 14:42
patrickb 👍🏼 14:43
[Coke] raku --version is showing mojibake, even after running chhcp 65001
Geth MoarVM-Remote: slid1amo2n3e4++ created pull request #5:
Remove type constraint for breakpoint-to-event.		 14:44
nqp/main: b79283c5c2 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get patrickb's longjmp Windows fixes
 14:54
rakudo/main: b6a72ac4d7 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get patrickb's longjmp Windows fixes
 15:05
ugexe patrickb: i believe rakubrew mostly worked in powershell for me 15:49
i think maybe the logic to automatically do the init stuff didn't work though 15:50
patrickb ugexe: Did you notice that I finally managed to implement exec --with in v40?
Geth App-MoarVM-Debug: slid1amo2n3e4++ created pull request #17:
Fix incorrect argument coercion when setting a breakpoint.		 16:05
App-MoarVM-Debug/main: 4811a08e19 | slid1amo2n3e4++ (committed using GitHub Web editor) | lib/App/MoarVM/Debug.rakumod
Fix incorrect argument coercion when setting a breakpoint.

The Match object evaluates to True, even if there's no match, so we have to explicitly cast to Int first.		 16:07
App-MoarVM-Debug/main: af0cad40b8 | timo++ (committed using GitHub Web editor) | lib/App/MoarVM/Debug.rakumod
Merge pull request #17 from slid1amo2n3e4/patch-1

Fix incorrect argument coercion when setting a breakpoint.
ugexe patrickb: yeah I did, thanks 16:10
for anyone else that means the follow now works 16:11
$ rakubrew exec --with moar-2024.03 zef list --installed site vendor 2> /dev/null | rakubrew exec zef install -
to install all modules from 2024.03 rakudo to whatever the current rakudo set in rakubrew is
[Coke] anyone managing the mailing lists? 16:37
getting bounce messages.
Geth rakudo/main: d00d8497ec | ab5tract++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for successful use of adverbs on hashes with infixes

Added to avoid any regressions over #5685 (R#5685)		 18:29
linkable6 R#5685 [open]: github.com/rakudo/rakudo/issues/5685 [Fixed in RakuAST] You can't adverb &infix:<&&>
timo isn't that to spec? 18:30
ab5tract timo: is what to spec?
dying when a user tries to us an adverb with a hash in conjunction with an infix?
timo having to put parenthesis for the True && (%foo<a>:exists) case 18:31
ab5tract I doubt that is in spec
timo docs.raku.org/language/traps#Adver...precedence 18:32
ab5tract that's a trap, sure. doesn't mean it is specified 18:33
and even if it is, since we are capable of DWIM in RakuAST, I would argue against keeping less-capable behavior 18:34
Also, that documentation still applies in RakuAST 18:36
For my taste "Precedence issue with ! and :exists, perhaps you meant :!exists?" is a far cry from "You can't adverb &infix:<&&>" 18:40
timo ok i can't actually find any spec test that requires this, cool 18:41
i thought it was just a case of "what an adverb applies to seems kind of random if you don't know the rule" ... do i know the rule? nah :P 18:42
ab5tract :)
I think there have been some longstanding issues with adverbs going to the wrong places, though I don't have the tuits to dig through the open issues at the moment 18:44
R#5685 is surprising... 18:53
linkable6 R#5685 [open]: github.com/rakudo/rakudo/issues/5685 [Fixed in RakuAST] You can't adverb &infix:<&&>
ab5tract doh! R#5686 18:54
linkable6 R#5686 [open]: github.com/rakudo/rakudo/issues/5686 [junctions] Junctions don't autothread over negative operators
timo i wonder if the optimizer does that 18:57
oh that would be strange given it's a repl session with not literals? 18:58
oh, is that from implementing $a != $b as not($a == $b) and the not immediately collapses the junction because it's a boolean op 18:59
ab5tract ahhhh 19:10
yeah
that definitely explains it
now... does that mean the behavior is correct? 19:11
It's actually a bit surprising, seeming as how most other operators do autothread 19:12
I guess the idea is at "all" boolean context operators collapse the junction 19:13
Geth MoarVM-Remote/loaded_file_notifications: ef9743b73b | (Timo Paulssen)++ | lib/MoarVM/Remote.rakumod
Add get-filenames and filenames methods.

As of now, the caller should make sure to only call get-filenames once, and to have called get-filenames before expecting the filenames method to return values.
App-MoarVM-Debug/loaded_file_notifications: fa66665a23 | (Timo Paulssen)++ | lib/App/MoarVM/Debug.rakumod
New command: fns / filenames to list / search filenames
 19:14
timo i think it should be consistent, i.e. how the issue suggests it should be 19:15
the thing i pointed out as the likely source of the issue should count as an implementation detail i think 19:17
now i wonder what other fun stuff we can find when we combine metaoperators and autothreading
m: dd any(1,2,3) Z+ (5, 4, 3)
camelia (any(6, 7, 8),).Seq
timo m: dd any(1,2,3) Z+ any([5, 4, 3], [9, 8, 7], [1, 1, 1]) 19:18
camelia (any(any(4, 4, 4), any(5, 5, 5), any(6, 6, 6)),).Seq
timo m: my ($a, $b, $c); dd any($a, $b, $c) += 9; dd :$a, :$b, :$c
camelia Use of uninitialized value of type Any in numeric context
in block <unit> at <tmp> line 1
Use of uninitialized value of type Any in numeric context
in block <unit> at <tmp> line 1
Use of uninitialized value of type Any in numeric context…
timo hm, not what i expected there 19:19
m: my $a; $a += 5; dd $a
camelia $a = 5
timo not that i have an opinion on what would be correct for this admittedly exotic usage 19:20
Geth MoarVM-Remote: timo++ created pull request #6:
Add get-filenames and filenames methods.		 19:21
App-MoarVM-Debug: timo++ created pull request #18:
New command: fns / filenames to list / search filenames
ab5tract oh weird, I wouldn't have expected that either ... 19:29
Now I'm having trouble finding the precise mechanism of `!=`
the qast when using that doesn't contain any reference to `METAOP_NEGATE`
timo --target=ast or --target=optimize? and do we have a specific &infix:<!=> perhaps? 19:30
since != isn't != but really !==
ab5tract `!==` does bring up METAOP_NEGATE 19:31
timo hm, i seem to recall there was something slightly odd about junctions when it comes to negating stuff
ab5tract And I do see that there are `infix<!=>` candidates in Int and Num in core
*`infix:<!=>`, rather
`!~~` also collapses 19:32
timo github.com/Raku/old-issue-tracker/issues/1787 19:36
also github.com/rakudo/rakudo/issues/3748 and github.com/rakudo/rakudo/pull/3874 and github.com/Raku/problem-solving/issues/319 19:38
ab5tract timo: that's some excellent spelunking! 19:40
timo i found the link to that issue in the spec tests in S03-junctions/autothreading.t around line 290 19:42
and the others from there
I think i might be too tired to think about anything having more than zero negations in it 19:51
ab5tract :) 19:53
lizmat ah, that old chestnut :-( 19:54
ab5tract I hope you get some good rest timo, I’ve been running on fumes recently myself 20:49
.. what does this signature mean? github.com/rakudo/rakudo/blob/eab7...c.pm6#L290 20:55
lizmat 0 or 1 positional 20:56
don't care about the value, so don't bother to even bind it to a lexical
ab5tract Ok… that’s kind of what I thought it would mean 20:57
lizmat m: sub a($? { dd }; a; a 42
camelia ===SORRY!=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> sub a($? ⏏{ dd }; a; a 42
ab5tract But how you call an infix with 0 positionals
lizmat m: sub a($?) { dd }; a; a 42
camelia sub a($?)
sub a($?)
lizmat m: say [!=] ()
camelia True
lizmat m: say [!=] (42,) 20:58
camelia True
lizmat m: say [!=] (42,666)
camelia True
ab5tract That doesn’t even seem correct (the first one)
lizmat m: say [!=] (42,42)
camelia False
ab5tract Why support either?
lizmat because a meta-op can be presented with a 0 or 1 elem list 20:59
ab5tract ISTR that you were planning on adjusting some semantics related to this
I guess”this nothing” != “this other nothing” could be true 21:00
But I am not sure I like it
lizmat m: say [==] 21:01
camelia True
lizmat m: say [==] (42,(
camelia ===SORRY!=== Error while compiling <tmp>
Unable to parse expression in parenthesized expression; couldn't find final ')' (corresponding starter was at line 1)
at <tmp>:1
------> say [==] (42,(⏏<EOL>
lizmat m: say [==] (42,)
camelia True
ab5tract m: say [!==]
camelia True
ab5tract Don’t like that
lizmat hmmm you could argue it should be opposite
well.... pretty sure Larry had some ideas about that at the time
ab5tract It is this way for a reason, I understand that 21:02
But we ought to interrogate it when it means that
lizmat interrogate what ?
ab5tract m: dd [==] (any(1,2,3), any(1,2,3)) 21:03
camelia Bool::True
ab5tract Hmm
Whether we should allow infixes to do anything but fail when presented with < 2 arguments? 21:04
lizmat m: say [+]
camelia 0
lizmat m: say [+] (42,)
camelia 42
lizmat m: say [+] (42,666)
camelia 708
ab5tract I know we discussed this eegardeing left versus right precedence
Why do I want [+] 1 to succeed? 21:05
We have a prefix form for a single argument
Should the prefix succeed for 0 arguments?
lizmat because (1,) could be an array that was passed to us ?
ab5tract Well it can be handed back a failure 21:06
Not a “sure, that’s obviously True”
lizmat pretty sure that will break quite some spectests, let alone some ecosystem modules
ab5tract I remember you saying you were going to fix more or less this exact issue for left associative ops
lizmat that was something else with metaops I believe 21:07
I forget atm
ab5tract Me too :( 21:08
Anyway, the overall discussion is relative to junction METAOP_NEGATE not autothreading 21:09
I’m signing off for tonight though, sleep has been both chasing and eluding me
lizmat ack 21:18
sleep well! recharge! kick those bed bugs out!
22:34 lizmat left 23:00 sena_kun left
Geth roast: raiph++ created pull request #866:
s/`|w`/`?wb`/ (switch from Rakudo feature to Raku feature)		 23:16

Powered by Cro and the Raku® Programming Language.

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

Thank you!