[00:05] <[Coke]> any idea why htop is showng a process taking <3% of CPU, but activity monitor is showing 85%? I only have 8 cores. [00:05] <[Coke]> (so it's not just "off by factor of # of cores" [00:11] <[Coke]> ah, brew htop issue. workaround,run via sudo [00:31] *** apogee_ntv left [00:33] *** apogee_ntv joined [01:12] *** apogee_ntv left [01:14] *** apogee_ntv joined [01:28] *** sibl joined [01:32] *** kylese left [01:32] *** kylese joined [01:58] *** apogee_ntv left [02:15] *** kylese left [02:15] *** kylese joined [02:20] I dont know much about VM programming but let's say someone decide to write their implementation for the moarvm in Zig, how likely would it helps with performance and supporting more targets for Raku ? [02:21] (I say Zig because I enjoy it, I could have said Rust but because of the whole "rewrite it in Rust" I try to avoid naming it xD) [02:21] (but mostly because Zig goes out of its way to support a lot of targets and do nice optimizations, and the new Io interface is pretty amazing) [02:26] *** vasko4535586 left [02:32] *** sibl left [02:33] *** sibl joined [02:39] *** vasko4535586 joined [03:01] *** topnep left [03:02] *** topnep joined [03:09] *** hurufu joined [03:50] *** lichtkind__ joined [03:53] *** lichtkind_ left [03:59] re performance it's going to be very similar if you use clang to compile it [04:00] …if your code is the same of course – if you redesign how it works internally then in theory it could always become faster [04:04] *** hurufu left [04:05] in practice however, I'd expect rewrite to be slower unless you know of some specific issue(s) you'd address in which case it'd be thanks to the rewrite and not because of zig/rust/whatever [04:09] *** shots____fired left [04:24] isnt it easier to write more performant code in Zig ? I know many C projects avoid concurrency because its a nightmare to manage, while in Zig its much easier, same for the memory management [04:25] mostly about comfort I would say, C can do what all of those languages do, but it's harder to do it well/confidantly since it's a really simple language [04:27] *** hurufu joined [04:31] that moarvm in C has been heavily optimized already and writing jit compiler with gc is actually quite difficult to write in any language [04:32] *** kylese left [04:35] *** kylese joined [04:40] it wouldn't help for supporting more targets though, because in the end you need to use dynasm or something similar to produce machine code out of moarvm bytecode [04:59] *** Inline left [05:53] *** sibl left [05:54] *** sibl joined [06:24] *** sibl left [06:24] *** sibl joined [06:35] *** merp left [06:37] *** merp joined [06:47] *** Sgeo left [06:49] *** Sgeo joined [06:59] *** Sgeo left [07:05] *** sibl left [07:11] *** merp left [07:17] *** sibl joined [07:28] *** Inline joined [07:34] *** merp joined [07:40] *** peder joined [08:38] *** sibl left [08:38] *** sibl joined [08:47] *** sibl left [09:18] *** topnep left [09:24] *** topnep joined [09:28] *** sibl joined [09:33] *** apogee_ntv joined [09:46] *** apogee_ntv left [09:47] *** apogee_ntv joined [09:55] *** sibl left [11:01] antononcube: I would like to publicly declare that I am enjoying some vibecoding. Like, really enjoying it. Since you were one of the earliest LLM boosters, I thought you might like to know ;) [11:03] simon_sibl: there are some things that I do think Zig could provide benefits. For example all of those different implementations of hashes could be used so that the "normal" case (< 100 keys) could use a specialized low-volume hash implmentation [11:05] funny, I am (finally) stepping into LLMs --- some cautious, some full on vibe --- guess I am not a bleeding edge guy (and likewise, kudos to Anton) [11:06] I am using Claude on the command line - how about you? - do you have any feel for how good your LLM is for Raku code (vs less niche languages?) [11:06] I'm using Claude Code at the moment. Yesterday I was using the Google web chat, but that gets a bit unwieldy after a while [11:07] Both have done a surprisingly good job, with maybe a slight edge to Claude [11:07] Claude already taught me something I didn't know. [11:08] yeah - it's kind of patchy imo - some things I could do easily it gets stuck and never resolves - but other things it does in 5 mins something I simply have no clue how to start [11:08] or rather, hadn't realized [11:09] m: my @f = do .&[+]: 5 for [^6]; dd @f [11:09] rakudo-moar abf53a606: OUTPUT: «[5, 6, 7, 8, 9, 10]␤» [11:10] postfix 'for' is high enough precedence to allow you to use colon-style method calls :D [11:11] that's scary [11:18] That's a bit of a contrived example, but yeah. I haven't fully formed a culinary opinion on that but it did exactly what I asked (essentially "You are an experienced Raku developer who is not afraid to surprise with bold syntax choices") [11:19] Combine that with an instruction to use colon-based method calls and we get a TIL :) [11:20] great prompt! I will steal immediately [11:21] I just finished this https://slangify.org/tutorial (the prompts are in err "Prompts" section) [11:23] zef install . --deps-only perhaps ? [11:28] *** topnep left [11:30] *** topnep joined [12:08] *** apogee_ntv left [12:09] *** apogee_ntv joined [12:21] *** apogee_ntv left [12:22] *** apogee_ntv joined [13:32] It is required now in many job interviews. And indispensible when dealing with constantly changing interfaces. (Say, byOpenAI or Google, of their LLM-related services.) [13:34] *** topnep left [13:36] *** topnep joined [13:58] simon_sib: I would consider Zig as essentially a C with better syntax. It's probably nicer to work with, but fundamentally its technical strengths and weaknesses are the same as C. [14:11] I somewhat doubt Rust would be a sensible choice though. VMs, especially JITing VMs, are just too dirty. I suspect you'd end up with so many unsafe sections that you might as well write it in something else. But I might be wrong on that. [14:17] @librasteve In principle, you can include the grammar itself in normalization prompt(s). Some LLMs have APIs that take can take grammars as arguments in order to filter/test their generations (before giving the final result.) [14:19] I am not sure what is the speed or price "penalty" for using that approach with the most popular LLMs. [14:19] in this case, I was asking the LLM to define a Grammar and then to build a parser / checker and then to use it to constrain the output [14:23] thanks for the feedback - I have been working rather in a vacuum on slangify.org in order to get my own thoughts in line (and as a learning vehicle for me) ... at the moment its kind of a 2 pronged approach with raku-for-prediction ... slangify is there for folks to get started with DSLs (and to explain how they can help LLM workflows informally), r-f-p imo is "more serious" content that is more thorough and innovative for [14:23] leading edge LLM workflows and users [14:26] I would really like to feature some of your LLM / DSL work on slangify.org - hopefully as one of the worked examples here https://slangify.org/examples (need to replace HTTP::Grammar for example as I cannot get that to work in the playground) - so needs to be quite short [14:26] any suggestions? [14:29] *** abraxxa joined [14:39] *** apogee_ntv left [14:41] *** apogee_ntv joined [14:47] @librasteve I think the ideas I have might not fit the example-try-out workflow on that page. [14:50] Two main ideas: - Making small grammars based on existing large(er) grammars. E.g., parsing of: - Natural language date specs - Geographical from-to statements or queries - Using DSL examples via LLMs [15:01] *** simcop2387 left [15:03] *** simcop2387 joined [15:04] *** apogee_ntv left [15:07] *** apogee_ntv joined [15:13] *** apogee_ntv left [15:14] *** apogee_ntv joined [15:27] El_Che: MoarVM 2026.05.1 is out [15:27] *** foxfromabyss joined [15:29] @antononcube okay … perhaps these examples are too mickey mouse … maybe better to dedicate a page to LLM::xxx eg natural language? [15:31] you are welcome to propose an outline of course … or i can try to showcase that and you can review…? [15:34] *** ntv joined [15:35] *** apogee_ntv left [15:38] *** Inline left [15:40] *** topnep left [15:41] *** topnep joined [15:45] *** ntv left [15:46] *** apogee_ntv joined [15:51] librasteve: Finally clicked your link. Beautiful! [15:51] *** apogee_ntv left [15:52] *** apogee_ntv joined [15:53] leont: another way to phrase what I said earlier is that Zig's standard library is of the batteries included variety. I can't say for sure what size-determinant hash backends would do for performance without testing it out, but at least in Zig that testing is theoretically very straightforward [15:54] thank you! its very much a work in progress - and very happy to get ideas and contributions - the general thrust is to showcase Raku as the best way to do DSLs (and to make a case for DSLs as a way to improve DSL workflows) so for example when someone Googles "I wanna make a DSL to constrain my LLM outputs" then this site is in the search results [16:26] *** apogee_ntv left [16:45] *** bobv joined [16:59] *** apogee_ntv joined [17:00] *** Inline joined [17:25] *** abraxxa left [17:26] *** simcop2387 left [17:43] *** belluzj joined [17:44] *** bobv left [18:37] *** foxfromabyss left [18:47] *** simcop2387 joined [18:50] *** hurufu left [20:13] *** belluzj left [20:45] *** simcop2387 left [20:45] *** simcop2387_ joined [20:47] *** simcop2387_ is now known as simcop2387 [21:09] *** Sgeo joined [22:10] *** Geth left [22:10] *** Geth joined [22:11] *** Geth left [22:11] *** Geth joined [23:38] *** Sgeo left