ab5tract I wonder if there is some sort of prize available for such intrepid code as can trigger buffer overflows on the JVM 00:00
furthermore, is this an underlying JVM change that made otherwise excellent NQP code fail 00:01
Or is this an underlying JVM change that surfaced an ugly truth in the NQP implementation 00:02
Tune in next week on ONLY THE KEPT PROMISE WILL EVER KNOW (tm) 00:03
00:51 MasterDuke joined
MasterDuke jdv++ 00:51
timo: amazing find on that jvm stuff. i was trying to make the jvm backend's runNFA faster by porting old moarvm optimizations, but that blows everything i was trying out of the water 00:52
ab5tract, patrickb: i think the best long-term direction for the jvm backend is the truffle work pmurias started. it was showing *great* promise, but i didn't understand it well enough to continue it myself when he didn't have the time 00:54
but i think it could give moarvm a run for its money, and enable near-seamless use of other languages libraries/modules/packages 00:55
Geth rakudo/main: e1a77dc34d | (Daniel Green)++ | 3 files
Use binding for all sub aliases

Using assignment doesn't cause a segfault if you multi the alias name anymore (what 998a1ef fixed in the past), but might as well make them all consistent.		 00:57
rakudo/main: 361cf23106 | MasterDuke17++ (committed using GitHub Web editor) | 3 files
Merge pull request #5631 from MasterDuke17/use_binding_for_all_aliases

Use binding for all sub aliases
02:49 MasterDuke left 06:49 sena_kun joined 07:04 dawids joined 07:08 dawids left 07:24 sena_kun left 07:39 finanalyst joined
nine ab5tract: still looks good 08:00
Geth nqp/main: 63731d9083 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for latest MasterDuke++ tweaks
 08:20
rakudo/main: bd85145ee8 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for latest MasterDuke++ MoarVM tweaks
 08:41
09:00 finanalyst left
Geth ¦ rakudo: lizmat self-assigned [rakuast-highlight] problems with =finish github.com/rakudo/rakudo/issues/5633 11:04
rakudo/main: c2c8d7a013 | ab5tract++ | 14 files
[6.e] Provide `is revision-gated("6.x")` trait

This trait is primarily intended for allowing multi candidates to be considered for dispatch only when the caller's compiler version is above a certain revision.
By applying the trait to the proto at its minimum compatible ... (15 more lines)		 11:12
rakudo/main: 778c7a63d2 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: last statement in ::CompUnit is not in sink context

because there's nothing to sink to. This effectively ensures that the last statement in a ::CompUnit will have a closing semi-colon.		 12:04
patrickb Master Duke: I agree that Truffle is the strategically best way forward for the JVM backend. Still I believe that Inline ::* is the better option for integrating different ecosystems. I think language ports to other VMs will always suffer from subtle incompatibilities. Inline::* sidesteps that issue entirely. 14:04
Also I've never seen stuff similar to I::* in any other language. I::P5 is simply amazing. 14:08
ab5tract I do wonder about how tricky it will be to hook into the JVM using NativeCall. There are a few missing pieces in current NativeCall that make it even straightforward libraries like raylib tricky to fully wrap. 15:35
I don’t intend to be discouraging in any way, I think Inline::Java would be an incredible thing to see 15:36
[Coke] Is there a guide on implementing an Inline other than "Read ::P5"? 15:40
I also think .NET would get us some converts as well.
(and might be easier than nqp.NET) 15:41
ab5tract [Coke]: it's definitely the reference implementation by which everything else must be built 16:34
as it more or less defines the expectations of an Inline:: module 16:35
so, that is to say, no there is no such guide
17:40 guest555 joined
Geth rakudo/main: 46d219b4c0 | (Timo Paulssen)++ | src/vm/moar/ops/perl6_ops.c
spell out MVMROOT macro for now for compatibility

Moar just changed the macro definition, with this change we don't need to tiptoe around required revisions and bumpings and such.		 17:51
lizmat timo: a simple recompile yields a broken raku installation, at least for me 18:06
lizmat nukes the install dir 18:07
and runs Configure again
timo uhhhh ok let me see 18:09
how broken exactly is it? 18:10
lizmat % raku
zsh: killed raku
timo i can "make test" just fine
ah
Geth rakudo/main: e94758306b | (Timo Paulssen)++ | src/vm/moar/ops/perl6_ops.c
Fix copy-pasto from previous commit
 18:12
timo sorry for the noise
thanks for catching it so quickly
lizmat % raku 18:19
zsh: killed raku
lizmat nukes install again
timo any chance you could get me a stack trace? 18:21
lizmat alas, no
timo can you "lldb raku" then "run" or something?
lizmat I've gotten so used to crashes after rebuilding core setting, that I don't spend any time on it anymore, I just nuke everything 18:22
I think you should be able to reproduced by checking out 778c7a63d2
linkable6 (2024-08-30) github.com/rakudo/rakudo/commit/778c7a63d2 RakuAST: last statement in ::CompUnit is not in sink context
lizmat then build from there (with Configure.pl) 18:23
then advance to 46d219b4c0
linkable6 (2024-08-30) github.com/rakudo/rakudo/commit/46d219b4c0 spell out MVMROOT macro for now for compatibility
lizmat and run "make install"
timo ok, i'm using --gen-moar and currently building nqp 18:25
by "build from there" you also mean "make" right?
lizmat perl Configure.pl --gen-moar --make-install; actually 18:26
timo ok 18:27
well, 46d219b4c0 was wrong and e94758306b should be fixed compared to that 18:28
linkable6 (2024-08-30) github.com/rakudo/rakudo/commit/46d219b4c0 spell out MVMROOT macro for now for compatibility
(2024-08-30) github.com/rakudo/rakudo/commit/e94758306b Fix copy-pasto from previous commit
timo i followed the steps you gave me and am currently running "make spectest" and getting lots of "ok" 18:32
lizmat ok, how is "raku" in your path ?
timo ./install/bin/raku -e 'say "hi"'; that lies under /tmp/tmp.suz2KelKdL/rakudo/ 18:33
lizmat ok, how is "raku" in your PATH :-)
timo that's from ~/raku/prefix/bin/raku and it's also happy 18:34
lizmat I don't have a ~/raku ? 18:35
timo yeah that's mine
i made a clean clone of raku, nqp, and moarvm under /tmp/blah and used Configure.pl --gen-moar there
to make sure that even if my ~/raku/ stuff has any changes you don't have, it doesn't cause trouble wtih reproducing the crash 18:36
lizmat /Users/liz/Github/rakudo/install/bin is in my path 18:37
timo my $PATH raku has Rakudo™ v2024.08-6-g778c7a63d / MoarVM version 2024.08-6-gf2dcdcae0. and my freshly made raku has Rakudo™ v2024.08-6-g778c7a63d / MoarVM version 2024.08-5-g2b5dcaee9.
lizmat well, then I give up :-(
timo but you can build a raku that runs after cleaning your install from the newest rakudo commit? 18:38
rakudo's CI is happy with the latest commit, including the macos job
lizmat yeah, that's my point: that's why I nuke install and build from scratch, just like CI does 18:39
timo oh
one of these days i need to come visit you again maybe we can figure it out when sitting at the same table 18:40
lizmat sounds like a plan to me :-)
it is mightily annoying to the point I've all but automated installing zef and all the modules that I need, so that it only takes 2 minutes or so and no interventionn 18:41
timo right
18:49 sena_kun joined
ab5tract I recently discovered that rakubrew can point the shim towards a local checkout 18:54
The only caveat is that I need to incorporate make install into my ‘make-rakudo’ shell function (which I still haven’t done, but easy enough)
19:00 guest555 left
Geth rakudo/raku-ast-compiler-shorter-LTM: 81d43af66e | (Timo Paulssen)++ | tools/build/raku-ast-compiler.nqp
drastically speed up raku-ast-compiler.nqp

Terminating the LTM immediately after opening paren, bracket, or brace prevents the NFA from running all the way to the end of the file whenever it encounters an nqp-code token. This makes nqp-m finish the raku-ast-compiler in 4 seconds instead of 1600, and moar is a bit faster, too (but already plenty fast)		 19:07
rakudo: timo++ created pull request #5635:
drastically speed up raku-ast-compiler.nqp		 19:08
timo the push was just a rebase on latest main. now there's a pull request to go with it
coolroot is now merged inside moarvm \o/ 19:13
Geth nqp/main: c450b5b96d | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for Timo's MVMROOT changes
 19:20
rakudo/main: 23da1ce118 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump Nqp for Timo's MoarVM MVMROOT changes
 19:31
lizmat hmmmm make test / spectest are ok 19:36
but now the REA harvester is broken
% raku -e 'use Ecosystem::Archive::Update' 19:37
zsh: segmentation fault raku -e 'use Ecosystem::Archive::Update
gist.github.com/lizmat/afa393276e2...d88c0512ef 19:39
ab5tract We do kind of need blin-as-a-service, eh? 19:44
not an automated CI/CD, but a big red button to press once and a while
lizmat if you mean jdv ? 19:48
looks like the zef installation problem was caused by a borked Staging module, fixed now 19:49
ab5tract lizmat: no, I do not mean jdv should be considered blin-as-a-service :) 19:57
I'm saying that it was two and a half pains in the butt to get blin running on my laptop
It would be infinitely better to have the option to, for example, kick off a blin run based on the new MVMROOT changes 19:58
that "anyone" could initiate, with ease and minimal fuss
that way we might get additional data points on what is broken and how 19:59
lizmat sadly, I don't know of such a button :-(
ab5tract there's got to be some kind of at-will pipeline option in github 20:02
I'll look into it
It would be interesting just to find out what it costs to do a blin on azure 20:03
patrickb ab5tract: Re raylib vs NativeCall, that's just because moar currently doesn't accept externally spawned threads. Incidentally fixing that is also on my to-do list (though way above) :-D 20:06
If it interests someone, I have my to-do list on the webs: boekernet.de/~patrick/finger.txt 20:08
[Coke] (blin on azure) I could give that a shot. I had been using azure to test some windows stuff ocassionally, but setting up a linux vm for blin should be triviail) 20:10
ab5tract [Coke]: that would be awesome 20:12
I'd even cover the costs of running it, assuming we can put a cap on it to ensure that we never go above $x/month 20:13
patrickb: ah, yeah there is that part indeed! For some reason I recall there being another really annoying thing to try and work around that was more API related, but I admit at the moment it completely escapes me 20:14
patrickb Non pointer structs is impossible to do ATM iirc 20:15
ab5tract that's a big one, yeah
ISTR nine had some ideas for a big NativeCall refresh that would cover that and some other issues 20:16
one step at a time, I guess :)
I wonder what macros might add to the binding story, if anything
[Coke] is ubuntu a reasonable choice for blin? 20:18
(any 64bit linux, seems)
ab5tract one second, let me see what I was using locally
[Coke] Apparently I was using debian/bookworm-slim as an image 20:19
which indicates that ubuntu would indeed be a fine fit
patrickb: `my $image = image-text('*', 32, $white);` <--- snowfall simulator is stuck in ASCII 20:20
I couldn't get the cascade of function calls required to use unicode to work correctly. I have a feeling that it's the struct issue you mentioned.. 20:21
[Coke] The estimated cost isn't worth complaining about at this point, let me see if I can get something started. 20:23
ab5tract [Coke]: awesome! 20:26
patrickb: it is indeed... the Font struct does not seemed to be referenced via pointer in raylib 20:27
curse me and my lack of knowledge in this domain.. I would love to be able to fix this
[Coke]: regarding cost, I believe blin took something like 8-12 hours on (a docker image) on my M2 20:28
but let's see how it goes 20:29
[Coke] I couldn't get it to even run on docker on my m2. :) 20:30
patrickb ab5tract: Can't do everything at once. One thing after the other. I for one will work on the debugger for the next few months at least. Then the next thing. :-)
ab5tract patrickb: I hear that indeed 20:31
patrickb On that note, I'm still searching for a good name. ladybug is sadly taken.
ab5tract which is why I'm bemoaning my lack of ABI skillz :)
[Coke] installing build tools but heading afk for a bit. Keeping pinging me, I'll get it setup.
ab5tract [Coke]: regarding that, github.com/ab5tract/Blin/commit/d9...3627458a4b
[Coke] ... ok, on to building rakudo 20:32
patrickb Currently I'm pondering "rad" the RAku Debugger. Unsure if that word is too overloaded already though.
ab5tract [Coke]: the most relevant non-arm64 thing in there is the `single-revision` stuff: this is more or a less a must-have for the concept of the Big Red Blin Button 20:33
patrickb: I knew a Radmila once, and she was a lovely person. Always thought it was a cool name too 20:34
(re: single-revision -- it allows you to specify a commit that isn't necessarily merged yet) 20:35
&sleep \o 20:40
22:17 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!