00:47 SEric left 00:55 Aedil left 03:27 apogee_ntv left 03:29 apogee_ntv joined 04:12 Aedil joined 05:59 cryosis left 06:42 apac joined 07:05 lichtkind joined 07:08 apac left 07:24 swaggboi left 07:32 abraxxa joined 07:37 abraxxa1 joined 07:40 abraxxa left 07:43 Sgeo left 07:48 bolangi left 08:04 ACfromTX left 08:15 dakkar joined 08:18 ACfromTX joined 08:49 acidsys left 09:02 acidsys joined 09:49 melezhik joined 10:17 abraxxa joined 10:19 ACfromTX left 10:20 abraxxa1 left 10:23 ACfromTX joined 10:34 abraxxa2 joined 10:35 abraxxa3 joined 10:36 abraxxa left 10:38 abraxxa2 left 10:40 abraxxa joined 10:41 abraxxa1 joined 10:42 abraxxa3 left 10:45 abraxxa left 11:14 Guest75 joined 11:20 Guest75 left 12:18 melezhik left 12:20 ACfromTX left 12:34 ACfromTX joined 12:37 apac joined
melezhik. Concat CSV files using Sparky plugin - gist.github.com/melezhik/96ce5fe84...00693076fe 12:38
13:00 ACfromTX left 13:14 ACfromTX joined 13:58 maylay left, maylay joined 14:05 Sgeo joined 14:23 ACfromTX left 14:28 apac left 14:32 abraxxa1 left 14:37 ACfromTX joined 14:42 apac joined 14:46 ACfromTX left 15:01 ACfromTX joined 15:37 abraxxa-home joined 15:38 abraxxa-home left 15:39 abraxxa-home joined 16:03 cm_ joined, cm left, cm_ is now known as cm 16:04 melezhik joined, apac left
[Coke] ^^ should that use tmpdir instead of /tmp 16:24
er, $*TMPDIR
m: say $*TMPDIR 16:25
camelia "/tmp".IO
[Coke] (locally I get "/var/folders/6v/fwvrwcyd74v8s1wg_2l4_y1r0000gp/T/".IO)
16:35 apac joined, dakkar left 16:54 human-blip left 16:56 human-blip joined 17:17 apac left 17:35 ACfromTX left 17:42 apac joined 17:48 ACfromTX joined 18:02 ACfromTX left 18:03 vasko joined 18:13 melezhik left, ACfromTX joined 18:48 abraxxa-home left 19:00 vrurg_ left 19:02 vrurg joined 19:03 abraxxa-home joined 19:26 abraxxa-home left 20:35 apac left, disbot1 left 21:01 Aedil left
[Coke] anyone know if centos has an "heir"? github.com/rakudo/star/issues/214 21:42
ds7832 Hey folks, do you think Raku would be a good choice for a daemon that monitors electricity prices, makes them available to other programs, and may also itself issue control commands for things ranging from BOINC to a washing machine? Different countries/zones/providers have vastly varying APIs and formats for price data, so Raku's expressivity and power are a huge argument in its favour. Plus I'm just growing to love it. The 22:10
thing that's making me hesitate is that it'd be nice if the software ran also on cheap/small/integrated/older hardware. Do you think Raku would be a decent choice in this regard? Would it run, say, on a Raspi 3, Raspi 2, or Raspi Zero? I'm also interested in any other thoughts you have.
Voldenet at some point I was about to test whether raku would compile on cheap arm SoC 22:13
leont I'm pretty sure it compiles, I'm not sure if it JITs on such a system
Voldenet memory requirements for runtime are pretty high
iirc raku uses luajit so probably there is 22:14
though the biggest problem for cheap SoC would be ram requirements, I'd simply check if it works on target minimal hardware 22:15
out of good parts performance is going to be quite not an issue thanks to `react whenever` blocks from various sources 22:18
thanks to that every probe could work in one thread reducing needs for locking and making codebase trivial
regarding compatibility, I'd check if all libs are ootb supported github.com/MoarVM/MoarVM/tree/main/3rdparty 22:21
ds7832 Another possibility would be to use Raku more or less just for glue code. But I suspect it has some baseline RAM requirement -- should I expect this already to be high by SoC standards? 22:24
Voldenet typical run is around that > 0.16user 0.04system 0:00.21elapsed 97%CPU (0avgtext+0avgdata 134584maxresident)k 22:25
I remember that not even loading grammars and using precompiled moarvm bytecode could optimize this further, but that'd require low-level nqp hacking 22:26
Geth docker: 8c213b2fb8 | AntonOks++ | 4 files
Bump to 2025.08.1 [skip workflow]
 22:27
Voldenet At some point rakuast will become "the only" raku grammar so it'll probably be less memory-hungry 22:28
But is even 200MB a lot in terms of modern rpis? I don't think so
rpi 1A (released 12 years ago) had around 256MB 22:29
while it's possible to use raku for glue code I wouldn't do that here, because of reactivity 22:33
yes, it's possible to use threads, processes and synchronize everything through channels, but it'd add a lot of overhead IMO 22:34
ds7832 Already sounds good in total. I wasn't yet so aware of Raku's reactivity capabilities, but they would of course be especially useful. 22:35
I think I might just write the thing in Raku, which should already cover a majority of the interesting machines today let alone a few years down the road. 22:41
Even more so since insofar the goal is to make use of unused computation power. 22:42
Voldenet for example I like how trivial it is to listen to multiple sockets on one thread easily 22:46
> raku -e 'react { for 5000..5010 -> $port { whenever IO::Socket::Async.bind-udp("127.1", $port) { whenever .Supply -> $packet { say "port $port: $packet" } } } }'
probably no language could get it shorter
maybe nodejs since it's single-threaded by design 22:48
ds7832 that does look lovely. In my use case, I don't think I'll be listening on web sockets; it'll rather be periodical requests, and then working with whatever they respond. Could reactive programming also have a role to play here? 22:49
Voldenet yes, you can define multiple per-interval processes in such loop as well 22:50
with something like `react { whenever Supply.interval(1) { .say }; whenever Supply.interval(.3) { .say } }` etc. 22:51
and you can make a loops with it too, for every probe: `react { for (1..10).map(* / 10) -> $time { whenever Supply.interval($time) { ($time, $_).say }}; }` 22:55
s/a loops/loops/
ds7832 I think I may do something like update some variables whenever a request-response turned back (new) data. And have another loop running that just works with whatever the current values are. This should be especially fitting to handle several sources of data, e.g. also an additional thermostat, right? 22:58
Voldenet Yeah, it's perfect fit for that 22:59
ds7832 Then I've made my decision :) 23:00
The primary source to learn about these things is the docs page docs.raku.org/language/concurrency#react , right? 23:01
Voldenet Yes, maybe also raku irc logs, reddit, SO and github.com/Raku/roast 23:02
some LLMs (not chatgpt) are decent at understanding raku 23:03
chatgpt notably always gives me the code that doesn't work, idk what's up with that
ds7832 Thanks a lot! 23:06
I have to go to bed now, I think tomorrow I'll dig into things :)
23:08 lichtkind left 23:14 kaskal left 23:25 itaipu left 23:31 itaipu joined 23:43 itaipu left 23:46 itaipu joined 23:50 bolangi 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!