[00:13] *** MasterDuke joined
[00:45] <wayland> As in "alternatives to MoarVM"?  

[00:46] <wayland> I'm not attached to the JVM, but I'd like to see Raku run in the browser :).  

[01:02] *** rmv left
[01:42] *** MasterDuke left
[01:44] *** hulk joined
[01:44] *** kylese left
[01:53] *** MasterDuke joined
[02:01] <[Coke]> Unfortunately I think the JS backend is in a worse state than the JVM

[02:12] *** rmv joined
[02:12] *** rmv left
[02:12] *** rmv joined
[02:15] *** hulk left
[02:15] *** kylese joined
[02:16] *** rmv left
[02:36] *** MasterDuke left
[02:46] <disbot> <simon_sibl> Raku in the browser could be great indeed

[02:50] *** rmv joined
[02:50] <ugexe> like im ok if some other backend shows up that passes the spec test. but given how far off the other existing backends are, let alone their viability for running ecosystem code, the tech debt isn't worth it

[02:52] *** silug left
[02:52] *** silug joined
[02:54] *** rmv left
[03:27] <wayland> I'm OK if they don't work now, as long as we're not ruling them out for the future.  

[03:58] *** dgl joined
[03:59] *** dgl left
[04:00] *** rmv joined
[04:00] *** rmv left
[04:00] *** rmv joined
[04:06] *** rmv left
[05:15] *** hurufu joined
[06:46] *** merp left
[06:47] *** hwj joined
[06:48] *** merp joined
[06:55] *** rmv joined
[06:55] *** rmv left
[06:55] *** rmv joined
[06:56] *** Sgeo left
[07:00] *** rmv left
[07:57] *** dakkar joined
[08:16] <disbot> <melezhik.> o/

[09:04] *** Pixi` joined
[09:06] *** rmv joined
[09:06] *** rmv left
[09:06] *** rmv joined
[09:07] *** wayland76 joined
[09:07] *** wayland left
[09:08] *** Pixi left
[09:10] *** rmv left
[09:24] <Voldenet> browser raku is an interesting project which would be very limited due to platform constraints

[09:27] <Voldenet> because of the limitations I think it's actually more ambitious than pure binary

[09:29] <Voldenet> it would have to somehow emulate threads and locks with condition variables for instance

[09:31] <wayland76> Would we be better rewriting it to use WASM?  

[09:33] <dakkar> for threads, you have web workers

[09:33] <Voldenet> webworkers are closer to separate processes

[09:33] <dakkar> true

[09:33] <Voldenet> and yes, you could emulate threads with that

[09:34] <disbot> <simon_sibl> I was actually wondering once raku++ is fully compliant, how easy it would be to target wasm

[09:35] <Voldenet> I can't even imagine hosting a Cro webserver inside a browser, it sounds impossible

[09:36] <dakkar> I'm pretty sure a browser can't open a listening socket

[09:36] <Voldenet> I think it can't connect to pure tcp too

[09:37] <dakkar> although https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers seems to imply a Service Worker can serve resources to a "client" in the same browser context?

[09:38] <dakkar> ridiculous idea: don't duplicate your rendering in raku and js, ship half your Cro application to the browser instead!

[09:38] <Voldenet> service workers are entirely different use case – once service worker is installed, it can ignore server being down and host resources anyway

[09:38] <Voldenet> it's for offline mode mostly

[09:38] <dakkar> so it can pretend to be the server!

[09:39] <dakkar> (if it weren't clear, I'm not serious)

[09:39] <Voldenet> :>

[09:40] <Voldenet> though it's the closest you can get for Cro, I guess

[10:15] <wayland76> One thing I'd be interested in shipping in WASM is the data-oriented programming stuff I'm working on.  My experience with frontend is that it involves a lot of a) transforming data into other data, and b) wiring events to things.  Both of these (but especially the first) are things that Data-Oriented Programming is trying to solve.  

[10:17] <wayland76> Just discovered: "Web browsers prevent WebAssembly code from directly manipulating the Document Object Model. Wasm code must defer to JavaScript for this" (Wikipedia).  If that's the case, that does away with half my use case.  

[10:18] <timo> yeah you always have to have some kind of wrapper that moves data back and forth between wasm world and DOM world

[10:44] <Voldenet> it's one postMessage away, you could actually have Channel impl for this kind of thing

[10:52] <timo> true, you just need to ideally have a protocol someone else came up with that defines what goes through that channel so you don't reinvent the wheel there

[10:55] <SmokeMachine> I just read about raku++! That's amazing! I have a question: when running it on the browser, how do we do something like `EVAL :lang<JavaScript>, "..."` as we did with rakudo.js? (https://github.com/FCO/MemoizedDOM/blob/c813568e14398a4343ad1255298e44d5677b06c3/examples/todo/todo.p6#L3-L4)

[10:58] <timo> if you can get it into the browser by compiling it to wasm, then you would have to communicate back and forth between the browser's javascript engine and rakupp inside the wasm sandbox using the "postMessage" thing Voldenet just mentioned

[10:58] <SmokeMachine> That is used on this raku code running in the browser: https://fco.github.io/MemoizedDOM/todo6.html

[10:59] <timo> or alternatively, just compile v8 to wasm as well inside the same blob, then also run the javascript inside the wasm sandbox. but then the javascript also has to go through postMessage to reach the DOM

[11:01] <SmokeMachine> (but that takes too long to compile... I'm thinking on how couls I port that to raku++)

[11:02] <timo> if you're okay with an implementation that's not 100% current roast passing, just use perlito6 or rakudo-js

[11:04] <lizmat> I think we dropped the js backend a while ago ?

[11:04] <SmokeMachine> I think I'm ok with that... that implementation is using rakudo-js from 8 years ago... 

[11:07] *** dakkar left
[11:07] *** dakkar joined
[11:11] <timo> you just check out commits from long ago. if you're lucky you can get the npm packages from back then as well and you won't need to change anything to get it to compile

[11:21] <SmokeMachine> Sorry, I don't get it... it is compiling, it is compiling on the browser, but it takes too long. I was thinking on using raku++js to compile it faster (I don't want to pre-compile it because I like to look at the source code of the page and see raku on the browser)

[11:28] <Voldenet> raku++ is really work in progress

[11:30] <Voldenet> it reimplements the compiler, so it has very arcane bugs

[11:31] <Voldenet> let's wait until most of the roast works

[11:33] <Voldenet> m: say [+] 6..9 Z- 1..4 # on rakupp it's 10

[11:33] <camelia> rakudo-moar 5eaeac377: OUTPUT: «20␤»

[12:26] *** sergot left
[13:11] <[Coke]> lizmat - i think the guts of the backend are still there, part of NQP - I just don't think we're building it anywhere.

[13:14] * [Coke] finds a checkout of nqp on his IRC box so old it's using master.

[13:15] <[Coke]> yah, I still see js in there.

[13:18] <[Coke]> https://github.com/perlconference/tprc-2026-gsp/wiki/Links-To-Slides

[13:18] <[Coke]> From the US TPRC that just happened. I see Util's slides are linked.

[13:47] *** Guest4 joined
[13:52] <[Coke]> ... Trying to be stricter about typing. There's no way other than a junction to say Seq|Positional ?

[13:53] <[Coke]> ah, was looking at wrong typegraph. Iterable, aye?

[14:07] *** dg left
[14:37] *** hwj left
[14:52] *** Guest4 left
[15:02] *** rmv joined
[15:02] *** rmv left
[15:02] *** rmv joined
[15:06] *** rmv left
[15:13] <Voldenet> nope, Iterable is not Positional and Positional is not Iterable, junction it is

[15:13] <Voldenet> m: my $x where * ~~ Positional|Iterable = {}; # works

[15:13] <camelia> rakudo-moar 5eaeac377: ( no output )

[15:13] <Voldenet> m: my $x where * ~~ Positional = {}; # doesn't work

[15:13] <camelia> rakudo-moar 5eaeac377: OUTPUT: «Type check failed in assignment to $x; expected <anon> but got Hash ({})␤  in block <unit> at <tmp> line 1␤␤»

[15:13] <Voldenet> m: my $x where * ~~ Iterable = Blob.new; # doesn't work

[15:13] <camelia> rakudo-moar 5eaeac377: OUTPUT: «Type check failed in assignment to $x; expected <anon> but got Blob (Blob.new())␤  in block <unit> at <tmp> line 1␤␤»

[15:13] <Voldenet> m: my $x where * ~~ Positional = Blob.new; # works

[15:13] <camelia> rakudo-moar 5eaeac377: ( no output )

[15:15] <Voldenet> m: my $x where Positional|Iterable = {}; # even better

[15:15] <camelia> rakudo-moar 5eaeac377: ( no output )

[15:17] <SmokeMachine> but most of implementations of Positional does Iterable, no?

[15:18] <SmokeMachine> m: say Array ~~ Iterable; say List ~~ Iterable

[15:18] <camelia> rakudo-moar 5eaeac377: OUTPUT: «True␤True␤»

[15:20] <Voldenet> yes but Type system doesn't give you that guarantee

[15:20] <Voldenet> m: class MyList does Positional { }; my Positional $x = X.new; # boo

[15:20] <camelia> rakudo-moar 5eaeac377: OUTPUT: «You cannot create an instance of this type (X)␤  in block <unit> at <tmp> line 1␤␤»

[15:21] <Voldenet> m: sub Y(Iterable) { }; sub X(Positional $x) { Y($x) }; # meaning this

[15:21] <camelia> rakudo-moar 5eaeac377: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Calling Y(Positional) will never work with declared signature (Iterable)␤at <tmp>:1␤------> Y(Iterable) { }; sub X(Positional $x) { <HERE>Y($x) }; # meaning this␤»

[15:24] <Voldenet> but that makes me wonder why Positional is not Iterable

[15:24] <SmokeMachine> Voldenet: yes, sure... I was just meaning that if you wanted only Array and List, that could be a solution...

[15:25] <Voldenet> I mean, Blob is perfectly iterable

[15:34] <Voldenet> So iterable in fact, that NFC and Blob are iterated perfectly in for

[15:34] <Voldenet> yet they are not Iterable

[15:35] <[Coke]> Iterable actually works here.

[15:45] *** hwj joined
[15:59] *** hwj left
[16:12] *** johnjay left
[16:20] <disbot> <melezhik.> https://news.ycombinator.com/item?id=48917772

[16:25] *** kelt0m left
[16:27] *** kelt0m joined
[16:32] *** dakkar left
[17:24] *** rmv joined
[17:29] *** rmv left
[18:41] *** hwj joined
[19:28] *** Pixi` left
[19:29] *** Pixi joined
[19:41] *** rmv joined
[19:41] *** rmv left
[19:41] *** rmv joined
[20:04] *** hwj left
[21:18] *** rmv left
[21:36] *** rmv joined
[21:36] *** rmv left
[21:36] *** rmv joined
[21:50] *** hurufu left
[22:08] *** leppard joined
[22:16] *** dg joined
[22:40] *** Sgeo joined