| 22 May 2024 |
 raitobezarius | can i unsee | 21:21:40 |
|  quartz joined the room. | 21:52:31 |
 @irenes:matrix.org | LMAO I didn't know that was public | 22:07:16 |
| @irenes:matrix.org | I continue to adore it | 22:07:20 |
|  temmie_nya joined the room. | 23:21:37 |
| 23 May 2024 |
 delroth | how much do people here care about Nix native plugins (plugin-files = foo.so)? the whole way they rely on static initializers is really a pretty terrible API (for many reasons) and I'm already looking at changing that API internally in Lix because it's very broken with static builds | 19:50:17 |
 K900 | Yeet it | 19:50:49 |
| K900 | I've only ever seen it used for absolutely disgusting things | 19:51:05 |
| delroth | (basically: my goal is to get rid of RegisterPrimOp, RegisterStoreImplementation, RegisterCommand, and RegisterStoreImplementation internally in Lix in favor of something which doesn't rely on static initializers, like a simple "void r() { RegisterStore1(); RegisterStore2(); ... } | 19:53:28 |
| delroth | * (basically: my goal is to get rid of RegisterPrimOp, RegisterStoreImplementation, RegisterCommand, and RegisterStoreImplementation internally in Lix in favor of something which doesn't rely on static initializers, like a simple "void RegisterAllStores() { RegisterStore1(); RegisterStore2(); ... }" | 19:53:35 |
| delroth | * (basically: my goal is to get rid of RegisterPrimOp, RegisterStoreImplementation, RegisterCommand, and RegisterStoreImplementation internally in Lix in favor of something which doesn't rely on static initializers, like a simple "void RegisterAllStores() { RegisterStore1(); RegisterStore2(); ... }") | 19:53:38 |
 puck | iirc nix has some kind of non-static-init method | 19:53:49 |
| puck | yeah, void nix_plugin_entry(void) | 19:54:06 |
| puck | we should cherry-pick dc0f7d8 | 19:54:43 |
 -> @n:rab.lol | In reply to @delroth:delroth.net
how much do people here care about Nix native plugins (plugin-files = foo.so)? the whole way they rely on static initializers is really a pretty terrible API (for many reasons) and I'm already looking at changing that API internally in Lix because it's very broken with static builds Native plugins were a mistake | 19:55:08 |
| delroth | I mean, they don't have a very high cost to support from an implementation perspective, so I understand the reasoning that leads people to adding support for them | 19:55:57 |
| -> @n:rab.lol | Personally I’d be down for down the line having something like WASM handle fetcher code or some scripting lang or something | 19:56:07 |
| -> @n:rab.lol | But shared libs as plugins are always not a great experience at best | 19:56:41 |
 Qyriad | I would really rather not yeet plugins but rather make them way more well-behaved | 22:43:59 |
|  glitch joined the room. | 22:49:53 |
 FireFly | the only use of them I'm aware of is nix-doc, and well, | 22:54:04 |
 Lunaphied | In reply to @puck:puck.moe
iirc nix has some kind of non-static-init method This was added for C API no? | 22:54:06 |
| puck | yes, but it works for C++ too | 22:54:42 |
| glitch set a profile picture. | 22:55:28 |
| Lunaphied | Yeah I'm just verifying that was part of the C API work | 23:00:23 |
| 24 May 2024 |
|  aktaboot joined the room. | 19:06:40 |
|  Federico Damián Schonborn changed their profile picture. | 21:27:39 |
|  jopejoe1 joined the room. | 22:53:24 |
| 25 May 2024 |
|  Thorn joined the room. | 07:43:22 |
 julia | just bumping this gerrit change here; might not ending up working on it tonight, but been waiting on some advice on how to do tests regarding e.g. a store returning a bad store path etc, because I can't see any existing tests doing it / can't parse how the existing store mock tests work | 07:56:42 |
