🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
00:02 constxqt_ left 00:18 constxqt_ joined 00:23 constxqt_ left 01:03 maylay left 01:37 maylay joined 02:33 jpn left 02:34 kylese left, hulk joined 03:15 hulk left, kylese joined 03:42 Sgeo_ joined, Sgeo left 06:51 epony left 06:58 epony joined 07:13 Xliff_ left
Voldenet What I meant is that the construction where you apply functors to a monad and the following types are going to be missing or unhelpful 08:00
making the whole construction not as useful as it is in haskell for instance 08:01
08:14 epony left 08:35 dano joined 09:20 jpn joined
dano Can Raku be used for simple 2D games? I mean does it have the library ecosystem for 2D graphics? 09:28
patrickb dano: raku.land/zef:jjatria/Pop 09:33
dano: github.com/vushu/raylib-raku 09:35
dano Thanks, that looks great 09:42
10:30 jpn left 10:33 jpn joined 10:46 sena_kun joined 10:57 jpn left 10:59 sena_kun left 11:00 sena_kun joined 11:15 jpn joined 11:20 jpn left 11:58 Sgeo_ left
Voldenet iirc there's this problem with native threads running raku code in raylib 12:02
nemokosch is there? 12:07
Voldenet yeah 12:24
> MoarVM panic: native callback ran on thread (139909579511552) unknown to MoarVM 12:25
that's what happens if you run pthread_start from C code with mvm callback
nemokosch sounds like MoarVM's problem to me 12:26
frankly, at this point half of Raku-related stuff should be a taboo for me because it just saddens me 12:27
Voldenet example 0x0.st/H67q.raku 12:33
It's not a moarvm problem that there's no thread context
that code would likely not fully work either way 12:35
but the native error would be a blocker either way 12:37
nemokosch > This issue can be fixed once and for all by teaching MoarVM to not die when an unknown thread is seen, but instead set up the management datastructure for it and then happily proceed. This is simply Not Yet Implemented. Jnthn, the MoarVM architect has confirmed that this the way to do it and it shouldn't be terribly difficult to do. (For some value of terrible.) 12:39
sounds like the problem of the M word indeed 12:40
Voldenet > github.com/MoarVM/MoarVM/blob/main...all.h#L146 12:56
naive implementation could simply do MVM_tc_create and MVM_set_running_threads_context here
but then… wouldn't it be leaky? 12:58
I'm suspecting it'd be more complicated, since the whole memory management of native threads would need to be more explicit for the native call libraries 13:00
.vushu I think nativecall must support value types soon, it’s way too much hassle to even make the bindings manually, since you must dive into c-land to make things play nice with rakunative call which isn’t ergonomic at all. 13:13
lizmat so, what would be needed to support that? 13:21
.vushu an expert in nativecall/moarvm 😄, which implements a trait: is value-type or something alike. 13:31
Voldenet it's partially supported 13:37
via HAS 13:38
nemokosch yes but that's not enough for function signatures 13:39
Voldenet but it should probably be is value-type trait
nemokosch long story short: the runtime should be good at something; anything
if it's not fast, if it's not super stable or portable, it should at least have unrivalled bindings 13:40
Voldenet but it's being fast to some degree now 13:44
it's certainly orders of magnitude faster than 5 years ago
melezhik Hi @nemokosch , if I understand your question correctly, I guess you can run any code before updating a folder with scm files - gist.github.com/melezhik/58aa12a4f...ff677e70b8
nemokosch definitely not
it has been stagnating for the most part 13:45
@melezhik hi, I think this is indeed what I'm trying to do somewhere along the lines. I take I could execute any script before git-scm? 13:46
melezhik Sure
technically speaking sparky only triggers a build upon a new commit arrives , it’s up to you what to do with that 13:47
Voldenet steady improvements don't lie, 2s is way slower than 400ms tux.nl/Talks/CSV6/speed.log
nemokosch bruh... so you absolutely missed when he replaced the rig? XD 13:48
is that the big improvement?
Voldenet sure it's an optimization 13:49
hardware one
nemokosch XDDD
give me a break
Voldenet though if value-type and native threads problem was sorted out, it'd be a breeze to use any library 13:51
without silly wrappers
lizmat it feels like this should be either a problem-solving issue, or a problem-solving discussion 14:10
because I would be very much in favor of simplifying NativeCall use
antononcube @nemokosch "I think the andthen chaining is still very much superior to feeds" -- "Extraordinary claims require extraordinary evidence." 🙂 14:20
@dano You can play chess using Raku and an LLM account. 14:21
@dano Well... sort of. I hope I will finish the demo on that soon... 14:22
nemokosch who is dano? 14:26
antononcube Not sure -- there is/was a question yesterday about 2D gaming in / with Raku by @dano. 14:27
nemokosch oh gotcha 14:28
antononcube @nemokosch I plan to be mean to you. Let me find the relevant message or yours... 14:29
14:33 epony joined
Never mind, I will self-censore... 14:33
14:34 constxqt_ joined
nemokosch Xd 14:34
antononcube Back to 2D gaming -- I think it is not that hard to have a reasonably good looking framework for (2D) board games via LLMs. One just have to gather are few "good prompts" and make nice visualizations. (Say, with JavaScript.) 14:36
14:36 jpn joined 14:39 epony left 14:41 jpn left 15:11 jpn joined 15:16 jpn left 15:50 epony joined
guifa to me the big difference between andthen and feeds is (a) andthens are unidirectional (left to right) where as feeds can go either way (although I guess if andthen is ==> maybe with would be <== lol) and eventually feeds are supposed to be autothreadable although they aren't currently so implemented 16:17
nemokosch @melezhik gist.github.com/2colours/5a4eade3b...a6db09d193 with this exact sparky.yaml file, I still get "marked as a flapper and skipped from scheduling", despite that it's reported as a part of the config 16:22
melezhik @nemokosch this should be placed to global sparky.yaml file. Not project based 16:23
nemokosch pfff
guifa tonyo you around today at all to try a fez back end debug session?
nemokosch what is a "global sparky.yaml file"?
antononcube I am going bring up again a question I asked ≈10 months ago: Are there any guides, tips, rules, for Raku packages with large supporting data? 16:35
For example, a package named "Data::Geographics" would have contry data and city data. The country data includes population, GDP, birth rate, geometric shape, etc. The city data includes population, Geo-coordinates, etc. As minimum, I see that package to be at least 10MB with all the data, say, in CSV format. 16:38
Any ideas about making the supporting data "smaller" or handled better package-wise would be appreciated. Any "example" packages with similar mission would be great too. 16:40
17:08 jpn joined 17:13 jpn left 17:50 jpn joined
melezhik @nemokosch I mean sparky.yaml placed into home directory 18:32
nemokosch okay, trying that
melezhik In the documentation it’s referred as ~/sparky.yaml 18:34
++
Please restart sparkyd after you’ve changed the file 18:35
nemokosch sure, thank you
melezhik Welcome )) 18:36
19:27 jpn left 19:47 AlexDaniel joined 19:52 releasable6 left, shareable6 left, benchable6 left, sourceable6 left, bisectable6 left, committable6 left 19:54 greppable6 joined 19:55 bisectable6 joined, sourceable6 joined, coverable6 joined, linkable6 joined, unicodable6 joined, quotable6 joined, notable6 joined, bloatable6 joined 19:56 nativecallable6 joined, evalable6 joined, benchable6 joined 19:57 shareable6 joined, releasable6 joined, committable6 joined, tellable6 joined 20:16 jpn joined 20:26 jpn left 20:32 constxqt_ left 21:18 jpn joined 21:19 Sgeo joined 21:23 jpn left 21:34 justache left 21:36 justache joined 21:50 constxqt_ joined 21:59 constxqt_ left 22:03 jpn joined 22:08 jpn left 22:16 jpn joined 22:21 jpn left 22:33 jpn joined 22:39 jpn left 22:54 sena_kun left 23:18 jpn joined 23:22 jpn 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!