SmokeMachine apogee_ntv: www.irccloud.com/pastebin/pvd3nprA/ 00:15
01:08 kylese left 01:09 kylese joined 02:15 kylese left, kylese joined 02:22 sibl joined 02:31 sibl left 02:42 sibl joined 02:50 vasko4535586 left 02:54 annamalai joined 02:55 vasko4535586 joined 03:29 Aedil joined 03:36 sibl left 04:37 manu_ joined, eseyman left, manu_ is now known as eseyman 05:35 erooke_ is now known as erooke 05:40 erooke left, erooke joined 06:35 Sgeo left 07:07 peder joined 07:14 itaipu left
disbot4 <librasteve> news.ycombinator.com/item?id=48145622 <<< i just submitted the new slangify site to HN … some timely comments would help push it to the front page if you are feeling chatty 07:33
apogee_ntv SmokeMachine: Thats the expected response, I dont provide prebuilt binaries for Intel MacOS 09:17
If you run that brew command also under x86 it should work though 09:18
librasteve: imo we should try to work out when most people are on and do HN posts in that time window, could give us a good shot of hitting front page more often? 09:30
tellable6 apogee_ntv, I'll pass your message to librasteve_
apogee_ntv librasteve github.com/m-doughty/Template-Jinj...akumod#L46 does this count as a good grammar? I dont use them much. 09:46
09:59 Aedil left 10:00 Aedil joined
apogee_ntv I will try to add an x64 build for mac for Notcurses::Native but I'm not sure how successful it will be, Github is deprecating intel mac runners so I'll probably have to do it via rosetta, very cursed 10:03
El_Che apogee_ntv: is it worth the trouble. Rosetta 2 is also being removed 10:24
tellable6 2026-05-10T13:41:55Z #raku <[Coke]> el_che - hey, can you help resurrect the docker builds on raku/blin?
2026-05-10T13:42:56Z #raku <[Coke]> el_che they've been dead for about 6 years now.
apogee_ntv El_Che: The runners will exist for a long time, it's worth to support Intel macs imo
El_Che [Coke]: I'll try to squeeze some time
apogee_ntv Not to support SmokeMachine's cursed Rosetta-on-M1 setup explicitly :D
El_Che apogee_ntv: ok, if you have the motivation, cool 10:25
apogee_ntv I would like Selkie to target all notcurses supported platforms ideally
We will see how much motivation I have :D
El_Che well, if it does not constraint the rest of targets, why not
apogee_ntv It shouldn't, it will be a separate binary package. It already *works* it just needs a manual compile step on older hardware. 10:26
But thats telling potential end users to download a C compile chain and compile notcurses & ffmpeg
To run a Raku application 10:27
El_Che macOS 26 is rumoured to be the last MacOS supporting Intel. So doing astrology/easy math, the intel macs could get security updates until somewhere 2028 (apple supports 3 macos releases) 10:28
so, yes, in that case, it's worth it
macos 26 (2025) + 3 years
apogee_ntv Yeah I dont think Intel Macs actually get security updates any more, it's more I know there are people still using them 10:29
El_Che that's tricky 10:30
depending on how technical they are
apogee_ntv Actual support for Intel was last in Big Sur IIRC (MacOS 11) 10:31
tbh my actual advice to anyone on that hardware is install Linux but I know not everyone does
El_Che yeah, I went another route with my linux packages because you can keep upgrading. I don't build for unsupported version of distros 10:38
apogee_ntv I don't on Linux, I think I go back to Ubuntu LTS glibc, anything before that is a manual compile. It's just this is a whole class of hardware. 10:44
And I'm trying to build a framework so broad support is an adoption factor
El_Che apogee_ntv: different target 10:46
I do rakudo OS packages, not libs 10:47
apogee_ntv Yeah if I was doing this for devs I'd just say compile it
But the infra affects end users who might not be technical
tbrowder is anyone using claude outside a virtual host? 12:22
disbot4 <librasteve> tbrowder - i use claude (both the macos app and via the terminal) on my local machine - I have told it to never make changes outside of a specific directory and i am pretty sure that it is asking me for anything else (eg sometimes i let it curl my http:localhost for web dev) 12:24
<librasteve> i am playing with openspec atm
El_Che agentic mode is pretty risky 12:39
apogee_ntv I run kimi k2.6 locally on my own hardware in agentic mode 12:41
tbrowder hm, i read about other users with concerns such as those of El_Che. i think i'll keep on with ChatGPT as i'm using it. thanks all. 12:49
El_Che tbrowder: use podman or something like it to contain it
tbrowder thnx, but i've not grokked using containers routinely 13:01
[Coke] anyone have a sample showing rakudoc on both a routine definition and then also on the parameter list? if I prefix the function with #|() it shows up in raku-doc. if I add #=foo after a parameter - it shows up TWICE in the --doc output 13:03
gist.github.com/coke/ea0a24bfbfb2b...a544033480 13:09
El_Che [Coke]: I am very swamped atm, but it would be interesting to know what the plans are with blin. Make it work again, rewrite, optimize, etc? 13:16
[Coke] It's working now. It has bugs. We dallied with sparrow, but that didn't seem to land. I am spending time trying to get blin more functional. 13:18
El_Che and architectural things like "it only works on amd64"? 13:26
[Coke] ... what/ 13:27
?
[Coke] double checks his vm.
I'm running it on an x86_64 box in the cloud. 13:29
El_Che it was in the doc somewhere
I mean will it test arm64 failures?
(now possible with github runners)
[Coke] the issue with doing it github - you're checking a single module at at a single raku release for that, right? 13:33
blin doesn't have to be the only thing, but it is a little unique.
El_Che no, it depends as long as you don't hit the time limit 13:34
but we can try to add external runners
that may be further away 13:35
just thinking aloud
ugexe i dont really forsee arm64 things breaking after-the-fact
El_Che so, in your view testing on the main platform should suffice 13:36
[Coke] and blin depends on whateverable's "mothership" of prebuilt binaries. We could expand that to have pre-built for other arches.
I would love to have a blin run on other OSes, also.
ugexe what i mean is if there are any arm64 specific issues in rakudo, those aren't likely to regress once they are fixed. same for any platform specific thing really
El_Che i see
ugexe s/platform/arch/ 13:38
13:43 itaipu joined 14:20 brabo left
[Coke] .seen finanalyst 14:55
tellable6 [Coke], I saw finanalyst 2026-04-02T18:04:46Z in #raku-dev: <finanalyst> [Coke]: ping
[Coke] heh
15:30 [Coke] left 15:33 [Coke] joined 15:57 annamalai left 16:56 abraxxa joined 17:12 abraxxa left 17:25 abraxxa joined 17:58 annamalai joined 18:14 annamalai left 18:15 annamalai joined 18:21 coleman left 18:24 coleman joined 18:26 Sgeo joined 18:47 belluzj joined 18:53 abraxxa left 18:55 abraxxa joined 18:59 ShimmerFairy left 19:00 ShimmerFairy joined 19:20 belluzj left
disbot4 <melezhik.> m: "hello" ~~ /[ "he" "ll" "oooo" ]/ 19:36
<melezhik.> m: say "hello" ~~ /[ "he" "ll" "oooo" ]/ 19:37
19:39 abraxxa left, abraxxa1 joined
[Coke] m: 3.say 21:12
evalable6 3
[Coke] not working across the bridge, I guess
apogee_ntv This Github action is becoming an eldritch horror. 21:55
ugexe i dunno if your windows arm64 ci test is doing what you think 22:06
i would bet you are building x86 rakudo on it
22:30 abraxxa1 left 23:47 human-blip left