[Coke] wonder if nrpoc-1 would be better 00:14
timo i'm not sure what the use case is for -Mno-remote-debugging 03:01
lizmat ok, perhaps, but having "use no-remote-debugging" in production code does? 09:33
10:35 sena_kun joined
timo that has the use case of making me very angry and smash my keyboard against the furniture 13:25
[Coke] *sigh* Looks like trying to use more of the VM has just made the whole re-run much slower. 14:17
m: say 728/2248
camelia 0.323843
[Coke] gist.github.com/coke/0fd5b8c4e72f5...50c9ac09f1 - some notes about Blin. Please feel free to comment here or there. 15:02
timo i would like to bring up once again nine's suggestion to utilise the open build service for smoking the ecosystem 15:23
[Coke] How would that work? 15:44
have every module author for the 2300 or so modules set something up for their module, and then test it against non-released versions of rakudo?
Or are you suggesting a different use case from the one Blin is trying to solve?
It reads to me like OBS would be great for generating distros of rakudo itself. 15:59
timo and all the modules too
and in the process, test them against pre-release builds of rakudo
[Coke] One of the things blin does is compare current results against previous results. 16:02
timo ok, then blin becomes a tool that pulls logs from the obs and looks at them, instead of having to run everything
or it could use the results from obs as a data source to determine what needs to be done, in terms of bisecting and whatnot 16:03
[Coke] Can one programmatically add a package to build? 16:04
timo the open build service has a CLI tool that, aiui, can do anything you wand 16:05
want
[Coke] any idea who owns software.opensuse.org/package/rakudo ? 16:11
timo build.opensuse.org/request/show/1176479 i believe it's nine 16:12
[Coke] Looks like the last build there is from 2024.04 16:13
added some "what would we have to do in OBS to get to Blin parity" to that gist. One thing: who would own the packages we create for the 2300 modules? what if the user already has one setup? What if we set it up and someone reports issues on it? 16:26
timo i believe we would make a "rakudo blin" "Factory" that is essentially an entire namespace for ourselves 16:28
there's already a "Factory" for different opensuse releases, for different centos releases, for different distros like the very first entry in the list of projects, AlmaLinux 16:29
so i imagine there may be a Krita package in OpenSUSE owned by person A, a Krita package in AlmaLinux by person B, a Krita package in CentOS owned by person C, and they don't conflict
[Coke] ok. added the factory note 16:30
and it looks like each build requires commits to create and perhaps approval from an admin on build.opensuse.org?) 16:31
(for rakudo)
timo i imagine that's a per-factory setting 16:32
[Coke] So would we have our own copy of rakudo as well? is it less restrictive if we never publish a release from it? (so we could do multiple builds of pre-release)?
timo tbh i'm not entirely sure what puts a "rakudo" into that list of packages you found on software.opensuse.org/package/rakudo 16:33
build.opensuse.org/project/show/ho...kr:raku-ci would you look at this :) 16:35
[Coke] I just searched for "rakudo" 16:37
and that was the first hit.
timo ok this page here build.opensuse.org/repositories/ho...-ci/moarvm has a little section called "Publish Flag"
that's possibly what controls if a rakudo would show up on the opensuse software page for a package of that name
since we probably don't want the packages of rakudo we build for blin purposes to be offered to end users, even if they have to click through two layers of "unsupported and experimental" warnings first 16:39
[Coke] patrickb: would a opensuse version of blin live under your ci project?
Geth rakudo/main: f532214288 | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod
Make .trans(Str => Str) 5% to 10% faster

Make tight loops all NQP
Part of work on #5488		 16:54
patrickb not sure I understand the question fully. nine is building rakudo packages which end up in opensuse. 17:02
timo the question is about building packages that are pre-release versions of rakudo 17:03
since blin happens before a release. these versions should not be offered to users
specifically, should we be using the raku-ci "project" on the open build service for this? 17:04
oh, and is there a difference between factory and project?
patrickb The rakudo ci bot (given it's currently running) is building every commit.
But the intention with the RCB has never been to produce packages (though it's a nice side-effect). 17:05
No idea about factory vs project
Also blin is building the entire ecosystem, while RCB is only building & testing most, nqp & rakudo 17:06
timo right. we would like to use OBS to do the compiling and testing part for a blin run 17:08
patrickb of modules or rakudo? 17:27
timo primarily modules, but why not also rakudo 17:28
[Coke] Note: we have several folks suggesting OBS as a potential replacement for what blin is doing, I'm trying to find out how feasible that is. 17:29
patrickb: Yes. we'd have to setup packages for each module, likely, and have them built against certain non-release commits, 17:32
patrickb I guess we could do that. 17:35
[Coke] afk
Geth ¦ problem-solving: timo assigned to codesections Issue Design a command language for interactive commandline / TUI rakudo-moarvm debugger github.com/Raku/problem-solving/issues/456 17:53
timo patrickb: i would like you in particular to also chime in on this one ^
patrickb Thanks for pulling me in. I'll mull over this. 18:02
Geth ¦ problem-solving: lizmat unassigned from codesections Issue Design a command language for interactive commandline / TUI rakudo-moarvm debugger github.com/Raku/problem-solving/issues/456 18:03
timo especially how the language in question could either "still be useful when using TUI" or "enhance, or be enhanced by, the TUI" 18:05
jdv lizmat: changelogs are up 18:42
[Coke]: ^ 18:43
lizmat jdv: I always forget the URL :-( 18:46
timo is a release happening right now? 18:49
lizmat no, a trial run 18:51
timo phew
so i still have a moment to get some stuff into moarvm?
lizmat I think so: [Coke] jdv ? 18:53
timo well, this commit is only in the debugserver, so it should not have an impact on any modules or something like that 18:57
i would really like to get some of the remote protocol changes in, but perhaps it's better to wait another month? 18:58
lizmat I think remote protocol changes (especially if they are additions) are ok at any time 19:01
as long as it doesn't break Comma ?
timo it might be a good idea to let them simmer a bit before letting them out of the oven 19:07
Geth rakudo/main: e0c25da214 | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod
Make .trans(/ foo / => ...) 1.5x as fast

The same for any .trans(Iterable:D) cases.
The slowdown was caused by the Pair:D candidate redirecting to the slow path (if the key and value were not both Str:D) that had a
  *@changes signature by wrapping the Pair in a List.
... (6 more lines)		 19:11
ab5tract Lucky Comma should be reasonably easy to adapt 19:40
Hmm, maybe not as simple as all that… I though that there was a Raku script in between 19:45
timo nah it directly speaks the MessagePack-over-TCP protocol to moar 19:48
ab5tract Indeed 19:51
The use of MessagePack should be a bit of a simplifier 19:52
timo right, makes it easy on the java side to ignore unknown keys and such
jdv no, sorry. no release of any kind today. just prepping early. 20:21
the changelogs are on the gh wikis of moarvm and rakudo
the release is planned for next saturday, the 14th. 20:22
but aa we're <= to a week before it would be good to avoid any non-trivial changes, as usual. 20:23
*as
Geth roast: ae29b2e13d | (Christian Bartolomäus)++ | S02-types/int-uint.t
[JVM] Don't run some non-working tests

This is a bit unusual, because the text aren't fudged as "todo", but are simply not run. I wanted to leave the test setup mostly unchanged. I think that the places are easy enough to spot once overflow for native types fully works on the JVM backend.		 20:32
[Coke] yah, this run is just slower. :| 20:59
m: say 1009/2248
camelia 0.448843
Geth roast: acb121f2e2 | (Christian Bartolomäus)++ | 3 files
[JVM] Unfudge some tests that no longer die
 21:29
rakudo/main: e4e2269434 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | src/Perl6/Optimizer.nqp
[JVM] Decont Routine object when looking for attribute (#5708)

Without this running running S32-list/skip.t from roast failed with a RuntimeException:
   No such attribute '@!dispatchees' for this object
... (6 more lines)		 21:33
jdv [Coke]: how long has it been running to get half way through? 22:21
[Coke] ... it doesn't tell you. :) one sec, checking htop 22:34
36h24m 22:35
and it's not even half way. :(
Probably still some contention 22:36
jdv uh, somethings wrong 22:40
timo no timestamped logs?
jdv at least in october, i could do it in under 9h
are you using an underpowered box?:) 22:41
[Coke] azure.microsoft.com/en-us/blog/int...e-vm-size/ - Standard_B8ms 22:51
... so probably. 22:52
I picked the beefiest of the crappy ones, I think. :) 23:00
switching to mething that isn't burst. 23:05
*something
(i had picked based on estimated monthly cost, but if it's going to take 4x as long to run, that math is suspect. :) 23:08
restarting 23:11
23:11 sena_kun left
jdv i just use my year old cheap amd lenovo laptop. 16 core, 16gb ram... 23:16
yeah, maybe "more":)
[Coke] ok, trying a *new* size... 23:23
ok, that's a little better. 23:28
running a load of about 11 on an 8 core box that is more for constant CPU usage instead of bursty 23:29
just have to be really sure to shut it off when I'm done with it. :)
interesting, it's saying out of 2247 in this run. we lose a module in the last hour? 23:34
m: say 128/2247 23:36
camelia 0.056965
[Coke] m: say 100/5.67 * 11
camelia 194.003527
[Coke] that seems like a better start, anyway. 23:37
m: say 100/5.7 * 11 / 60 23:38
camelia 3.216374

Powered by Cro and the Raku® Programming Language.

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

Thank you!