[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
(so it's not just "off by factor of # of cores"
ah, brew htop issue. workaround,run via sudo 00:11
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, kylese joined 01:58 apogee_ntv left 02:15 kylese left, kylese joined
disbot4 <simon_sibl> 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:20
<simon_sibl> (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
<simon_sibl> (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
Voldenet re performance it's going to be very similar if you use clang to compile it 03:59
…if your code is the same of course – if you redesign how it works internally then in theory it could always become faster 04:00
04:04 hurufu left
Voldenet 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:05
04:09 shots____fired left
disbot4 <simon_sibl> 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:24
<simon_sibl> 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:25
04:27 hurufu joined
Voldenet 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:31
04:32 kylese left 04:35 kylese joined
Voldenet 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:40
04:59 Inline left 05:53 sibl left 05:54 sibl joined 06:24 sibl left, 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, 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
ab5tract 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:01
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:03
disbot4 <librasteve> 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:05
<librasteve> 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
ab5tract 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
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.
disbot4 <librasteve> 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
ab5tract or rather, hadn't realized
m: my @f = do .&[+]: 5 for [^6]; dd @f 11:09
camelia [5, 6, 7, 8, 9, 10]
ab5tract postfix 'for' is high enough precedence to allow you to use colon-style method calls :D 11:10
disbot4 <librasteve> that's scary 11:11
ab5tract 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:18
Combine that with an instruction to use colon-based method calls and we get a TIL :) 11:19
disbot4 <librasteve> great prompt! I will steal immediately 11:20
<librasteve> I just finished this slangify.org/tutorial (the prompts are in err "Prompts" section) 11:21
lizmat zef install . --deps-only perhaps ? 11:23
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
disbot4 <antononcube> 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:32
13:34 topnep left 13:36 topnep joined
leont 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. 13:58
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:11
disbot4 <antononcube> @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:17
<antononcube> I am not sure what is the speed or price "penalty" for using that approach with the most popular LLMs. 14:19
<librasteve> 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
<librasteve> 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
<librasteve> I would really like to feature some of your LLM / DSL work on slangify.org - hopefully as one of the worked examples here 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
<librasteve> any suggestions?
14:29 abraxxa joined 14:39 apogee_ntv left 14:41 apogee_ntv joined
disbot4 <antononcube> @librasteve I think the ideas I have might not fit the example-try-out workflow on that page. 14:47
<antononcube> 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 14:50
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
lizmat El_Che: MoarVM 2026.05.1 is out 15:27
15:27 foxfromabyss joined
disbot4 <librasteve> @antononcube okay … perhaps these examples are too mickey mouse … maybe better to dedicate a page to LLM::xxx eg natural language? 15:29
<librasteve> you are welcome to propose an outline of course … or i can try to showcase that and you can review…? 15:31
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
ab5tract librasteve: Finally clicked your link. Beautiful! 15:51
15:51 apogee_ntv left 15:52 apogee_ntv joined
ab5tract 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:53
disbot4 <librasteve> 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 15:54
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, simcop2387_ joined 20:47 simcop2387_ is now known as simcop2387 21:09 Sgeo joined 22:10 Geth left, Geth joined 22:11 Geth left, Geth joined 23:38 Sgeo 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!