01:39 kylese left 01:40 kylese joined 02:15 kylese left, kylese joined 02:23 silug left 02:27 silug joined 03:06 silug left 03:12 silug joined 03:19 oodani left, oodani joined 03:59 wayland76 joined 04:38 ShimmerFairy left 04:55 atcroft joined 05:53 hurufu joined 06:11 wayland76 left, wayland76 joined 06:12 hurufu left 06:32 hurufu joined 06:55 wayland76 left 07:01 samebchase left 07:41 ShimmerFairy joined 08:02 tejr left 08:03 snonux left 08:14 tejr joined 08:37 human-blip left 08:39 human-blip joined 08:41 snonux joined 09:02 timo left 09:27 wayland76 joined 09:41 Sgeo left 09:53 belluzj joined
ab5tract SmokeMachine: it works for me without issue in Firefox on Manjaro 11:10
also: very cool!! 11:32
SmokeMachine ab5tract: thanks 11:39
12:06 Geth joined 12:11 silug left
ab5tract SmokeMachine: so am I looking at a MoarVM/Rakudo that is running on wasm?? 12:11
12:12 lizmat_ left, lizmat joined
SmokeMachine ab5tract: that's using the old version of rakudo.js that was used on 6pad and on webperl6... I just stole that code when I was working on MemoizedDOM (8 years ago). At some point it stopped working in some browsers... recently I asked AI to make it work on every browser again. It did... but I have no idea what it did... (I wasn't very confident it would work so I did not pay much attention)... 12:15
I really would like to use a newer version of rakudo.js... 12:16
lizmat just a thought: perhaps a more modern approach could be to directly convert a RakuAST tree to JS ? 12:18
12:18 silug joined
lizmat and for some subset of Raku, you might not actually need to implement all of Raku to get a viable JS version ? 12:19
Voldenet for some things new js features could be used, like `await` needs generator functions 12:30
a lot of raku could be translated into js directly 12:31
through rakuast
but some things like grammars may need a lot of work 12:34
schedulers are natively implemented, locks and semaphores could be reduced to no-op 12:37
and .cue could become simply setImmediate
overall transpiling into js sounds doable, but every function would need to be `async` and accept dynamic context object, which means that every call would need copy an object 12:41
so the call model would make the code look hideous and likely slow 12:45
lizmat I guess that's what plagued rakudo.js to begin with 12:49
I'm a bit out of touch with "modern" JS, but is the need for the dynamic context object a result of being async? 12:50
Voldenet no
lizmat so why would it need to be async?
Voldenet dynamic context just needs an object in browsers and passing it around
everything would need to be async because every function can have `await` in it
in js function can't suspend its execution
unless it's async 12:51
lizmat ah, and the await could be un a dynamic context
Voldenet those are two separate things, but related to call conventions
lizmat so if "a" calls "b" which is async, then "a" would need to be async as well ?
Voldenet which'd build `async function(…)` because of `await everywhere`
yes
lizmat yuck I guess that's why Raku is better :-) 12:52
Voldenet and dynamic would need `function(ctx, …)` everywhere
interesting thing is that nodejs has asynchronous context tracking
so that ctx is kind of automatic, but it's not built into browsers 12:53
lizmat TIL
Voldenet AsyncLocalStorage looks almost exactly like dynamic vars in raku 12:54
the only difference is that you run storage with context variable set, e.g. `dynVar.run(42, () => { await thing() }); async function thing() { console.log(dynVar.getStore()); }` 12:57
I've thought and functions and methods in js could emit, instead of function, an object with call tree 13:06
if code can be provably not call any await (and its children are not) it could be non-awaitable, speeding it up by a lot 13:07
not calling, even
same with dynamic variables
13:08 wayland76 left, wayland joined, johnjay left
Voldenet customized method resolution is needed anyway, because js doesn't have it 13:08
which could be resolved in compile time or runtime: `multi sub foo {}; foo(42, "bar");` `const foo = new Multi("foo"); foo[Raku.Int.TypeId][Raku.Str.TypeId][Raku.CallMe.TypeId](…);` 13:14
after thinking a bit, I can only imagine transpiled runtime becoming extremely slow
because there's a lot of dynvars used (makes the whole dynamic tree unoptimizable) and multi calls 13:17
so raku-to-js transpiler would need to monomorphize a lot of things and do some hacks that'd only clone dynamic context when called method needs it 13:19
maybe some speshlog guided optimization would be nice, e.g. `const multiFoo = …; function foo() { if(arguments[0].TypeId == Raku.Int.TypeId …) foo_Int_Str.apply(this, arguments); multi.call(…) );` 13:22
(though this used as dynamic call context would make method calls awkward, idk) 13:23
it could, instead of hash, generate methods group hash, then use type ids to access it, e.g. `foo.fn_142_458.apply`, there's plenty of fun to be had here 13:26
with that a piece of precompiled code (like rakuast compiler) could even become fast 13:27
and in dynamic case get a string from some lookup
`foo[foo.dynamicCall(arguments).internalName].call` 13:28
ab5tract oh that's an interesting perspective indeed 13:30
Voldenet s/method group hash/method group class/ I mean 13:31
13:44 timo joined
SmokeMachine There are 2 new "games" on fco.github.io/Raku-Playground/ if anyone is interested... 13:53
14:07 belluzj left
ab5tract SmokeMachine: kawaii 14:18
but I did `move-forward xx 3` and camelia moved to the block that has a diamond .. but she didn't collect the diamond 14:19
SmokeMachine You need to call `collect-gem` to collect it 14:25
ab5tract: 👆 14:35
14:49 hurufu left 15:15 belluzj joined 15:16 belluzj left
Voldenet hm I wonder why is that but things like `quotes and constructs` evaluate instantly but games take a while 15:44
16:10 apogee_ntv left 16:22 apogee_ntv joined 16:59 Guest94 joined, Guest94 left
ab5tract Hey all Comma/raku-intellij-plugin fans (and former fans): a new release is imminent that should fix a whole heap of issues you were very likely experiencing. 18:07
For one, it will be actually usable in 2026.1 ;)
but it goes much further than that
lizmat
.oO( blog post ? )
 18:13
18:49 hurufu joined 18:54 hvxgr left 19:13 hvxgr joined
ab5tract not in time for the weekly, I think 19:23
hmmm,tail -f $LOG_FILE | raku -ne doesn't appear to survive truncations of $LOG_FILE 19:47
19:49 Sgeo joined
ab5tract and of course then it starts acting fine directly after I sent that 19:58
Voldenet isn't tail attached to old descriptor still 20:05
tail -F is what you want 20:06
may be* 20:07
ab5tract I'll give that a try, thanks 20:29
20:53 guifa_ left 20:54 guifa joined 21:45 hurufu left 21:50 guifa_ joined, guifa left 22:58 wayland left 23:47 wayland76 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!