ugexe m: my $o = 42; say $oo 01:12
camelia ===SORRY!=== Error while compiling <tmp>
Variable '$oo' is not declared. Perhaps you forgot a 'sub' if this was
intended to be part of a signature?
at <tmp>:1
------> my $o = 42; say <HERE>$oo
ugexe m: my $oo = 42; say $ooo 01:13
camelia ===SORRY!=== Error while compiling <tmp>
Variable '$ooo' is not declared. Did you mean '$oo'?
at <tmp>:1
------> my $oo = 42; say <HERE>$ooo
ugexe kind of odd those errors have different suggestions
gist.github.com/ugexe/de3ead91b4b1...0834b254a9 - i wrote a program that generates 1 million conditionals. i was originally wanting to do 4 billion since andreasjhkarlsson.github.io//jekyl...ments.html is what was leading me to try, but the precompilation of the generated library ran by the generated script is taking forever at just 1 02:34
million conditionals
03:00 kjp left 03:01 kjp joined 03:03 kjp left, kjp joined
ugexe 1 million conditionals has been (presumably) precompiling for 40 minutes so far 03:13
ab5tract Xliff: are you running blead in production? It’s making me nervous just thinking about it 07:57
[Tux] Rakudo v2024.10-48-g24a1cdbbb (v6.d) on MoarVM 2024.10-27-gc3629fb7e
csv-ip5xs0.254 - 0.260
csv-ip5xs-201.081 - 1.084
csv-parser1.515 - 1.523
csv-test-xs-200.142 - 0.142
test1.885 - 1.887
test-t0.395 - 0.400
test-t --race0.260 - 0.267
test-t-204.731 - 4.806
test-t-20 --race1.161 - 1.178
 07:59
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
Geth rakudo/main: 7 commits pushed by (Patrick Böker)++ 08:03
patrickb lizmat: ab5tract: Can one of you have a quick look at: github.com/rakudo/rakudo/pull/5700...aff8db96e7 This is untodoing a few passing rakuast tests. I find it a bit unexpected that they should start passing. 08:04
With that PR merged, we are now passing the rakudo tests on Windows again. Yay!
ab5tract Awesome! 08:07
This one feels suspicious to me github.com/rakudo/rakudo/pull/5700...779af3ee64
Geth roast: d57047f66e | (Patrick Böker)++ | S32-io/IO-Socket-INET.t
Test mixed bin/no bin access in IO::Socket
roast: 3032bcf423 | (Patrick Böker)++ (committed using GitHub Web editor) | S32-io/IO-Socket-INET.t
Merge pull request #857 from patrickbkr/test-io-socket-mixed-access

Test mixed bin/no bin access in IO::Socket
ab5tract But since is-run is not publicly available, the idea that there could be a difference in how platforms handle :out<> vs :out(‘’) is less serious 08:11
patrickb ab5tract: There was a compile time warning saying that <> is an empty list, not a list with the empty string. 08:16
It worked with <> as well, just that pesky warning. 08:17
ab5tract On Windows, or everywhere? If the latter than I guess somehow the warning got swallowed or otherwise went unnoticed when I added the test
If we ever want to polish is-run for general audiences, maybe using :!err would be even cleaner 08:18
I like that :err(*) works (or maybe I’m glossing over warnings there too, hmm) 08:19
patrickb It's on Windows, yes.- 08:21
ab5tract Ok, that at least explains how I didn’t notice it. It’s not a big deal, since is-run is internal for now. Otherwise I would suggest we (further) alter things to work with uniformly rather than alter the test itself 08:23
patrickb I believe this: github.com/rakudo/rakudo/blob/main....nqp#L1591 is the warning I saw. 08:24
ab5tract .o( would an EVAL bot running on Windows add any utility? Maybe it could shadow all evals and report any differences in output… ) 08:25
patrickb I wonder why that didn't trigger on Linux.
ab5tract Yeah, now I’m more worried about that aspect :) 08:26
Okay, back to poking at your actual question 08:27
patrickb: well, I have no clue what happened but all of those examples are passing without RAKUDO_RAKUAST on macOS for me 08:41
patrickb What I can say: the rakuast tests did not run on the CI up until yesterday. That at least explains why nobody noticed. 08:44
ab5tract Ah, was it not included in the `make test` target? 08:46
Anyway, I think that commit is 100% good to go. 08:47
m: dd uclc => *.uc ~ *.lc; Q| dd lcuc => *.lc ~ *.uc |.AST.EVAL 08:49
camelia :uclc(WhateverCode.new)
:lcuc(.lc ~ *.uc)
ab5tract not sure why `*.lc` is becoming `.lc`there, but otherwise I'm pretty proud of having added that patch :) 08:50
patrickb ab5tract: it was in make test, but the CI called `prove` directly. And that by default only looks at files with the .t extension. 08:53
The rakuast tests have .rakutest.
ab5tract ahhh
09:52 sena_kun joined 10:10 sena_kun left
Geth nqp/main: 09807b7dd0 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get Windows long path fixes
 10:15
rakudo/main: c632dd7749 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get Windows long path fixes
 10:32
lizmat patrickb: t/spec/S32-io/dir.t started to fail for me :-(
7, 10 failed
patrickb I'll look 10:33
It's this: github.com/MoarVM/MoarVM/pull/1745...1597874453 10:48
I'll just need to find the place where that . / .. processing happens make the change.
Geth rakudo: patrickbkr++ created pull request #5701:
Fix `dir` to give "." and ".." again		 12:31
patrickb There you go. 12:32
lizmat patrickb: looks ok, waiting for CI results :-) 12:35
Geth rakudo: patrickbkr++ created pull request #5702:
Fix tests on Win/cl/debug, make runner resilient to long paths		 12:37
nqp: patrickbkr++ created pull request #832:
Deal with long paths in moar runner		 12:38
rakudo/main: b1c4062415 | (Patrick Böker)++ (committed using GitHub Web editor) | src/core.c/Rakudo/Iterator.rakumod
Fix `dir` to give "." and ".." again

Now that Moar does not give "." and ".." for dirs anymore, we need to put it in ourselves, just as we do for the JVM.		 13:01
nqp/main: bea7fbb404 | (Patrick Böker)++ | src/vm/moar/runner/main.c
Deal with long paths in moar runner
 13:17
nqp/main: 38161c4f20 | (Patrick Böker)++ (committed using GitHub Web editor) | src/vm/moar/runner/main.c
Merge pull request #832 from patrickbkr/win-long-path-runner

Deal with long paths in moar runner
rakudo/main: 3b2fb62ad4 | (Patrick Böker)++ | t/04-nativecall/CompileTestLib.rakumod
Fix nativecall tests on Windows/cl/enabled debugging
 13:36
rakudo/main: 61ee2fdfb4 | (Patrick Böker)++ | src/vm/moar/runner/main.c
Deal with long paths in moar runner
rakudo/main: 461b81f794 | (Patrick Böker)++ (committed using GitHub Web editor) | 2 files
Merge pull request #5702 from patrickbkr/win-long-paths

Fix tests on Win/cl/debug, make runner resilient to long paths
lizmat patrickb: odd, 61ee2fdfb4 doesn't cause a re-compilation, it probably should ? 13:40
linkable6 (2024-11-27) github.com/rakudo/rakudo/commit/61ee2fdfb4 Deal with long paths in moar runner
patrickb You mean a re-run of the CI? 13:46
lizmat no, after a pull, a "make install" did not re-compile rakudo at all
effectively making the change in src/vm/moar/runner/main.c unnoticed ? 13:47
patrickb That it's not recompiling all of rakudo is expected. That it's not even recreating the executables is unexpected. 13:48
lizmat ok, then sorry for the noise 13:50
yeah, it did mention: +++ Compilinginst-rakudo and friends 13:51
so I guess it did DTRT
14:46 librasteve_ joined
timo i never run with --silent-build %) 15:34
15:42 donaldh left 15:43 donaldh joined
patrickb timo: Now that the RTL issue on Windows is solved, can we merge #5642? That's a pretty epic PR that would give us tremendously faster Windows tests, pretty test results to look at and (because it disables Win_JVM) finally a ✅ again. 15:46
ugexe it would be nice if that PR could be rebased into more comprehensible commits 15:49
patrickb All the gems are hidden in there. Just needs a thorough rebase -i removing all the debug cruft and squashing the rest into a few commits. 15:51
At least that's my understanding. :) Awaiting timos opinion on this. 15:52
timo if you want to do that work, that's okay. i would just squash the branch into a single commit and keep the old branch around for documentation reasons or to look back at the Fun Times i have had? 15:54
patrickb timo: If the windows stuff is still too much of an annoyance to you, I can take over. But a quick "yes, there are no blockers it actually makes sense to merge would be great."
timo oh, yeah, i'm not aware of blockers, but i haven't touched it in a while and don't remember very accurately 15:56
patrickb Want me to take over?
timo i would appreciate it :) 15:57
maybe i should have ported the "find powershell thingie very fast" thing over to the main branch long ago already
and also to moarvm's CI
patrickb Cool! I'll do so. It's nice to harvest the did-something-great-feel without all the untreated-sewage part. :-P 15:58
timo hahaha 15:59
man i got so enraged ...
ugexe i left my 1 million line program precompiling overnight but i think not much happened when my laptop went to sleep since htop shows the TIME+ as only 3.5 hours
timo i'm analysing it a little bit
ugexe its still precompiling though
timo looks like there is a big amount of work by the GC, and i looked at some hashes that we're gc-mark-ing and there's a humongous one with integer keys which i expect are CUIDs of blocks we're creating 16:00
ugexe are you talking about the for-loop one or the if-elsif-else one? 16:01
timo the if-elsif-else one 16:03
if you're cool with attaching gdb to the process i can show you how to have a look where in the source it's currently at with parsing 16:04
ugexe i'm attached with lldb 16:07
timo what does the memory usage look like on your end? i've made a change to the source and it's reached 2.5 gig already
ah, ok, i'm not fully familiar with the lldb syntax, but you would want to set a breakpoint in nqp_nfa_run
ooooh 16:11
hello below-quadratic-growth-of-arrays my old friend
not sure it's actually responsible for a big part of the run time, maybe not 16:13
ugexe gist.github.com/ugexe/156bbfe4e6f3...fcca74961f this is what my memory usage looks like 16:16
timo i'm not sure what i'm seeing here. why is so much memory allocated in a region called "IOAccelerator"? 16:19
can you get an output of how much the process has spent swapping stuff in and out? like, are the swapped-out bits of memory mostly dormant, or is it swapping back and forth over and over?
ugexe i'm largely surprised by the 32gb used in virtual memory and only 1gb of resident memory 16:24
timo when i set a breakpoint to any of the nfa functions that are interesting and continue, gdb spikes to 100% cpu usage and doesn't react to trying to ctrl-c it, wtf
oh, could be mimalloc doing that? is mimalloc actually in use in your case? just some virtual memory tricks perhaps? 16:25
hahaha oh shit :D 16:26
i think it's the string pretty-printer being pointed at the huge-ass source string and just trying to transfer a huge amount of memory from the client memory to its own? 16:27
and it's not reacting to ctrl-c while custom python code is running?
well, i can turn that off, so that's good
so you're on macos, right? 16:29
oh, the virtual size is actually virtual + swapped, so it's not virtual memory tricks, it's almost all real memory 16:58
LOL i was debug-printing stuff in the string pretty printer code and was getting "could not locate compile-time value for symbol" and i was so confused, until i realized that that's the content of the string, not an error from gdb to my python code 17:20
lizmat reminds me if a prank I pulled in the DOS days 17:38
put a file called "secret.txt" on somebody's startup disketter
with as contents: "Access denied" :-)
Geth App-MoarVM-Debug: slid1amo2n3e4++ created pull request #21:
Run Rakudo from inside the script		 17:48
timo ehehehe 17:50
19:01 sena_kun joined
Geth rakudo/lower-bound-for-revision-gating: 8def6255f0 | ab5tract++ | 3 files
Add lower-bounding for the revision-gated trait

This adds a finishing touch to revision gating: the ability to use revision gating to evolve methods that otherwise have the exact same signature.
The is done by adding the trait to the candidate that is to be replaced: ... (23 more lines)		 19:54
rakudo: usev6++ created pull request #5704:
Type second param of proto for Stash::ASSIGN-KEY		 20:14
rakudo/lower-bound-for-revision-gating: c49f878cd0 | ab5tract++ | 3 files
Add lower-bounding for the revision-gated trait

This adds a finishing touch to revision gating: the ability to use revision gating to evolve methods that otherwise have the exact same signature.
The is done by adding the trait to the candidate that is to be replaced: ... (23 more lines)		 20:16
Xliff ab5tract: Um. TMI? 20:50
ab5tract Sorry, I don’t get it 20:51
Xliff ab5tract: Good! You'll sleep better! 20:52
timo: No, I do not have an AMD Zen. This is 13th Gen Intel(R) Core(TM) i9-13900K
ab5tract Why would someone in the community making sideways comments that they refuse to explain help me sleep better? 20:53
Now I’m just left wondering what I’ve written that led you to react that way 20:54
patrickb Possibly "too much information". And then glad you didn't get it (i.e. wasn't meant to be snarky, but was in retrospect). I personally like long commit messages. 20:59
Xliff ab5tract: You mentioned something about blead in production, recently. I was trying to assuage your fears withouth actually touching on them. 21:00
ab5tract I didn’t write the robot that can’t handle a force pushed
*push 21:01
Text is hard yall 21:07
I expect I can come off as fairly cranky at times, so I want to take a moment to say how much I appreciate everyone here 21:08
(Was that TMI? ;) 21:10
Xliff Nope. 21:18
And it's in tune with the season. We're glad you're here, ab5tract!
ab5tract ❤️‍🔥 21:19
Geth rakudo: patrickbkr++ created pull request #5705:
Reimagine Azure CI		 22:14
22:22 sena_kun left
Geth rakudo/azure_improvements_squashed: ea4f39e754 | (Timo Paulssen)++ (committed by Patrick Böker) | 2 files
Reimagine Azure CI

  - Prettier output (using the JUnit test result formatter)
  - Restructure making better use of parameters
  - Disable OOMing Win_JMV
  - Speed up CI on Windows by working around the compiler search
  - More granular output using `echo` commands
  - add a nodelay & blocking spec test run
  - persist build artifacts
  - Speed up testing by running tests in parallel		 22:28
rakudo: patrickbkr++ created pull request #5706:
Reimagine Azure CI		 22:29
rakudo/azure_improvements_squashed: fc6ad5c3de | (Timo Paulssen)++ (committed by Patrick Böker) | 2 files
Reimagine Azure CI

  - Prettier output (using the JUnit test result formatter)
  - Restructure making better use of parameters
  - Disable OOMing Win_JMV
  - Speed up CI on Windows by working around the compiler search
  - More granular output using `echo` commands
  - add a nodelay & blocking spec test run
  - persist build artifacts
  - Speed up testing by running tests in parallel		 22:35
rakudo/azure_improvements_squashed: d7fbf904a1 | (Patrick Böker)++ | azure-pipelines.yml
Fixup perms
 22:51
rakudo/azure_improvements_squashed: 394545f95f | (Patrick Böker)++ | azure-pipelines.yml
More perm fixes
 23:06

Powered by Cro and the Raku® Programming Language.

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

Thank you!