| 00:08:26 | * | xet7 quit (Remote host closed the connection) |
| 00:09:58 | * | xet7 joined #nim |
| 00:43:33 | * | xtr00 quit (Ping timeout: 256 seconds) |
| 00:46:21 | * | xtr00 joined #nim |
| 02:49:58 | * | Ekho- is now known as Ekho |
| 05:23:53 | FromDiscord | <davidvfx07> Making C bindings for Nim is easy with Futhark etc, but wrappers that make those libraries Nimmy are a manual pain. Has anyone taken a series attempt at getting some LLM to parse through raw bindings and generate a nice Nimmy wrapper? |
| 05:24:12 | FromDiscord | <davidvfx07> (edit) "series" => "serious" | "seriousattempt at getting some LLM to parse through raw bindings and generate a nice Nimmy wrapper? ... " added "That would be awesome" |
| 05:26:12 | FromDiscord | <davidvfx07> I've tried before, but I'm a sucker for running local, and I could only run a 30b param model on my 24GB VRAM, so not only was it not very accurate but it never really could write Nim. If the scope is broadened and we call in the big dogs (Gemini, Claude, etc) is this feasible? |
| 05:27:30 | FromDiscord | <davidvfx07> If it can be mechanized enough, it can all be abstracted into a simple tool that can do this automatically, with just a style prompt or something for a functional feel, macro heavy feel, object oriented feel, etc |
| 07:11:14 | * | mronetwo quit (Server closed connection) |
| 07:11:23 | * | mronetwo joined #nim |
| 08:19:34 | * | gshumway quit (Server closed connection) |
| 08:20:20 | * | gshumway joined #nim |
| 09:17:31 | FromDiscord | <spotlightkid> @davidvfx07\: yes, there are several people that have posted about developing APIs for binding with the help of LLMLs on the Nim forum. Just go through the latest few dozens of topics there and look through announcements for new projects and you'll find them.↵One example\: https://forum.nim-lang.org/t/13394 |
| 10:25:24 | * | dv^_^ quit (Server closed connection) |
| 10:25:55 | * | dv^_^ joined #nim |
| 10:46:03 | * | beholders_eye joined #nim |
| 11:04:38 | * | beholders_eye quit (Ping timeout: 256 seconds) |
| 11:13:44 | * | void09_ quit (Server closed connection) |
| 11:13:59 | * | void09 joined #nim |
| 11:34:34 | * | Freneticks quit (Server closed connection) |
| 11:34:44 | * | Freneticks joined #nim |
| 12:37:36 | * | beholders_eye joined #nim |
| 13:12:54 | * | nisstyre quit (Server closed connection) |
| 13:13:13 | * | nisstyre joined #nim |
| 13:28:10 | FromDiscord | <__jont__> In reply to @davidvfx07 "If it can be": I think I would be most comfortable building a private "raw" Nim API in Futhark and mirroring a nicer, more idiomatically Nim as the wrapper's public API. ↵↵The second part I might trust to a LLM but C wrappers can be finicky and Futhark is genuinely the best tool for doing this |
| 13:31:41 | FromDiscord | <__jont__> If all the pieces are already there I feel as though a LLM with sufficient exposure to Nim could figure it out, but to hold the context of the wrapped C library in addition to the Nim side would probably be too much for it to handle |
| 13:33:06 | Amun-Ra | getting LLM to do programing job? hell nah |
| 13:33:39 | FromDiscord | <__jont__> Yeah I wouldn't, it just seems like they wanted to get a LLM to do this |
| 13:33:41 | FromDiscord | <swrge> In reply to @__jont__ "If all the pieces": This almost never works though |
| 13:36:54 | FromDiscord | <swrge> Usually to Nimify futhark code it's pretty straightforward, create a context type and wrap the futhark types so they support destructor and use the context type when needed. It gets harder when you need to account for things such as callbacks and data with complicated lifetimes |
| 13:37:42 | FromDiscord | <swrge> Also you cannot wrap some things such as c macros and static inline functions |
| 13:46:08 | * | beholders_eye quit (Ping timeout: 256 seconds) |
| 13:54:07 | * | beholders_eye joined #nim |
| 14:10:30 | * | beholders_eye quit (Ping timeout: 256 seconds) |
| 16:03:26 | FromDiscord | <davidvfx07> In reply to @__jont__ "I think I would": Yeah, this is what I was thinking |
| 16:04:14 | FromDiscord | <davidvfx07> In reply to @swrge "Usually to Nimify futhark": That's the scary part, specifically destructors and getting it to play nice with mm |
| 16:04:32 | FromDiscord | <davidvfx07> (edit) "specifically" => "especially" |
| 16:06:00 | FromDiscord | <lainlaylie> i want to see llm wrangle curl multi into a asyncdispatch/chronos async api |
| 16:06:40 | FromDiscord | <swrge> In reply to @davidvfx07 "That's the scary part,": As long as the library you're using promises to not hold onto the memory and extend its lifetime for some reason then it's actually easy... |
| 16:08:36 | FromDiscord | <swrge> A lot of the time libraries push memory management on you so it's a straightforward `lib_destroy_ressource()` wrapped as a `=destroy` call |
| 16:09:32 | FromDiscord | <swrge> Now I do agree it's more complicated once that promise either doesn't exist or isn't held |
| 16:11:19 | FromDiscord | <davidvfx07> Oh, I see what you're saying. That's a good point. I'm not that familiar with C in general, but I'd assume that gets more complicated when the library becomes more abstract, and the structure of it per say would need to be held in Nim for it to not randomly free things still in use. I couldn't say for sure tho |
| 16:11:43 | FromDiscord | <davidvfx07> (edit) "held" => "recreated" |
| 16:12:48 | FromDiscord | <davidvfx07> Ive been debating learning Rust over sticking with Nim, and I guess this is a weak spot for Nim. Since the ecosystem is small, and you need external libraries, you not only rely on them being rock solid but also properly binding and wrapping them |
| 16:18:52 | FromDiscord | <swrge> In reply to @davidvfx07 "Oh, I see what": you cannot "randomly free things" in Nim due to the fact destructors are deterministic. It's literally the same thing as Rust's `Drop` Trait so you'll have to do the same thing in the rust side as well |
| 16:19:29 | FromDiscord | <swrge> I think you cannot get as easy as Nim when it comes to interop except maybe Zig |
| 16:20:27 | FromDiscord | <swrge> And yeah Nim's ecosystem is small. This is a weakness but you can also view it as an opportunity to be a pioneer and contribute to the ecosystem as well 😊 |
| 16:21:02 | FromDiscord | <davidvfx07> In reply to @swrge "you cannot "randomly free": I know what you mean, but I'm talking about Nim misunderstanding that something relies on something in a library, and freeing things it sees go out of scope when the library still needs that thing. It would mean recreating the structure and dependency tree in Nim for it to properly hold onto things. I think that's a thing you need on top of the raw cal for call bindings, correct me if I |
| 16:22:57 | FromDiscord | <davidvfx07> (edit) "In reply to @swrge "you cannot "randomly free": I know what you mean, but I'm talking about Nim misunderstanding that something relies on something in" => "sent" | "library, and freeing things it sees go out of scope when the library still needs that thing. It would mean recreating the structure and dependency tree in Nim for it to properly hold onto things. I think that's a thing you need on top of the raw cal for call bind |
| 16:30:02 | FromDiscord | <swrge> sent a long message, see https://pasty.ee/UpjKpeXq |
| 16:30:10 | FromDiscord | <swrge> (edit) "https://pasty.ee/HTzVyqtF" => "https://pasty.ee/tZBJNttA" |
| 16:32:52 | FromDiscord | <swrge> For example in Rust I have a custom fork of `libmdbx-rs` that I use for an application of mine and I edited it to wrap a new API that came in `libmdbx`. You have a `Cursor` that you create from a `Transaction` that you create from a `Database`... All of which you can straightforwardly create and free using `Drop` |
| 16:34:00 | FromDiscord | <swrge> Imo this tends to be the easiest part of wrapping a library due to how C and destructor based memory management works |
| 16:34:27 | FromDiscord | <swrge> The hardest part is to integrate them well with the rest of the languages feature... |
| 16:35:32 | FromDiscord | <davidvfx07> Hmm. So (most) C libraries have some way to hint if you're able to free something, and we just add it to the destructor in Nim so that if the library says we're good to go it frees it? You mentioned like if the pointer is nil, which I don't quite understand because how could an address disappear, but that's on me lol I gotta get more into that. |
| 16:36:26 | FromDiscord | <davidvfx07> What ur saying at a higher level makes sense, I guess it depends on the library, but strictly logically there must be some safety rails in large c libraries even tho it's just c |
| 16:36:40 | FromDiscord | <davidvfx07> (edit) "c" => "c. Again, no real experience tho" |
| 16:37:20 | FromDiscord | <davidvfx07> (edit) "c." => "c like u say." |
| 16:37:33 | FromDiscord | <davidvfx07> (edit) "What ur saying at a higher level makes sense, I guess it depends on the library, but strictly logically there must be some safety rails in large c libraries even tho it's just c like u say. Again, no real experience tho ... " added "lol" |
| 16:38:12 | FromDiscord | <swrge> It's just a check you can do to protect agaisnt calling `=destroy` multiple times which happens if you have multiple instances of the same ressource |
| 16:38:48 | FromDiscord | <swrge> Usually you free the pointer and set it to nil to avoid having dangling pointers around |
| 16:39:22 | FromDiscord | <davidvfx07> Ohh I see, on the Nim side ur saying? |
| 16:39:52 | FromDiscord | <swrge> It's up to you as the library wrapper to do due diligence of what happens when you free a ressource... The library may set it as NULL or not.. |
| 16:40:19 | FromDiscord | <swrge> (edit) "It's up to you as the library wrapper to do due diligence of ... what" added "seeing" |
| 16:41:32 | FromDiscord | <swrge> > if you're able to free something, and we just add it to the destructor in Nim so that if the library says we're good to go it frees it?↵Yes. It depends on the library of course |
| 16:43:01 | FromDiscord | <swrge> At least I sure hope you easily can. C have such a strong issue with memory that libraries have adopted many idioms to make it as easy to use without causing issues |
| 16:44:29 | FromDiscord | <swrge> You may or may not need to interact with libraries that precede such idioms, may you have the patience and wits to get through theses if you ever happen to stumble onto one of these... |
| 16:44:51 | FromDiscord | <swrge> (edit) "these..." => "them ..." |
| 16:44:58 | FromDiscord | <davidvfx07> sent a long message, see https://pasty.ee/YDhqvhvh |
| 16:46:13 | FromDiscord | <swrge> In reply to @davidvfx07 "Okay. Do C libraries": In my experiences only the slightly more complicated have those hints, most of the times it's actually just "alloc, use, free" |
| 16:47:34 | FromDiscord | <swrge> If you have a library with those hints they are doing funny things with the ressource, for example you might have a library that uses reference counting and the "hint" is just checking if the ressource count is at 0 |
| 16:47:48 | FromDiscord | <swrge> (edit) "ressource" => "referencd" |
| 16:47:56 | FromDiscord | <davidvfx07> Oh wow I didn't know thats a thing that's so interesting |
| 16:48:48 | FromDiscord | <swrge> Well it's more like C++ that does that |
| 16:49:22 | FromDiscord | <swrge> I haven't seen any C libraries doing this, since there's no scope based destruction to decrement the count |
| 16:51:14 | FromDiscord | <swrge> But the pointer can be held somewhere and the library manages it itself, in which case you just do what the library tells you to do, in most cases call a function to the library to tell it you dont need it anymore and it can do whatever it wants with it |
| 16:51:21 | FromDiscord | <swrge> So it's still actually easy |
| 16:51:27 | FromDiscord | <davidvfx07> sent a long message, see https://pasty.ee/cUnMaKBO |
| 16:52:03 | FromDiscord | <davidvfx07> (edit) "https://pasty.ee/wKYGmjtN" => "https://pasty.ee/ULxeYtTr" |
| 16:52:29 | FromDiscord | <davidvfx07> Like if a C library has callbacks I guess is an example |
| 16:52:38 | FromDiscord | <swrge> What do you mean by "isolated memory wise"? |
| 16:52:42 | FromDiscord | <davidvfx07> (edit) "is" => "as" |
| 16:53:51 | FromDiscord | <davidvfx07> In reply to @swrge "What do you mean": That the library only ever gives out memory it no longer relies on or mutates, so the user or Nim's mm has total freedom with that memory as opposed to returning an address to some variable it then still has control over |
| 16:54:36 | FromDiscord | <davidvfx07> Or being given a variable from the user (Nim) that it expects to exist but then is freed by Nim cause it goes out of scope technically |
| 16:55:17 | FromDiscord | <davidvfx07> In that case the wrapper needs to properly define the structure of the library so Nim knows not to free things or to not free things it gives the library, like for callbacks |
| 16:55:32 | FromDiscord | <davidvfx07> (edit) "In that case the wrapper needs to properly define the structure of the library so Nim knows not to free things ... or" added "it gets" |
| 16:56:13 | FromDiscord | <davidvfx07> If Nim made a callback function but then saw it go out of scope it may free it, but the C library, in use somewhere else, still needs that callback to exist |
| 16:56:40 | FromDiscord | <davidvfx07> This is sorta speculation tho I could be totally wrong |
| 17:16:14 | FromDiscord | <swrge> sent a long message, see https://pasty.ee/wLcKQVcd |
| 17:17:56 | FromDiscord | <swrge> So basically most of the time it's get a ressource, pass said ressource to one or multiple c functions, when done call free on the ressource |
| 17:18:35 | FromDiscord | <swrge> Thus, use destructors to automate managing the ressource 👍 |
| 17:26:14 | FromDiscord | <swrge> In reply to @davidvfx07 "So I guess the": > you'd need to represent the structure of the C in Nim so it knows when it's allowed to free things,↵Not at all, opaque pointers suffice to free ressources and the library worries about how to actually free it, you just need to call the `free_this_ressource()` function. Don't worry about the "when can I free this thing" but more about "what I can do with this thing" which is the whole thing th |
| 17:27:49 | FromDiscord | <davidvfx07> Oh I see. Wow that clarifies a lot, thanks. I'll look more into how C libs are structured. |
| 18:11:54 | * | beholders_eye joined #nim |
| 18:16:25 | * | beholders_eye quit (Ping timeout: 256 seconds) |
| 19:59:27 | FromDiscord | <123017335> Yo, been following the convo, super interesting stuff around Nim bindings and memory handling. ↵I’ve actually done a bunch of cross language interop work and built wrappers that keep things clean with proper destructors and GC refs.↵If anyone’s planning to push this idea further, like automating Nim wrappers or making something production grade, I’d be down to collaborate. Been doing full-stack and blockchain dev for years, |
| 20:14:45 | FromDiscord | <davidvfx07> That's super cool. Personally I'm not very knowledgeable when it comes to memory management, I've never really delved into c or cpp, but it would be so cool to get something like this running reliably. I'm assuming that this project assumes some llm backend to generate friendly wrappers with proper destructors and gc refs? |
| 20:14:56 | FromDiscord | <ieltan> (surge here) well as far as automating wrapper goes, futhark is the state of the art. What I would really appreciate is showcasing the customization you can do with it like renaming symbols, overriding types, etc.. |
| 20:15:08 | FromDiscord | <ieltan> (edit) "wrapper" => "wrapping" |
| 20:15:32 | FromDiscord | <ieltan> I've already done and know those things but for the community that would be very valuable |
| 20:16:02 | FromDiscord | <ieltan> Maybe AI can help but I don't know how |
| 20:17:09 | FromDiscord | <davidvfx07> In reply to @ieltan "(surge here) well as": I've always spoken about Futhark as creating bindings while the manual public side as wrappers. I don't know if these are real terms but there is a disconnect between raw bindings that just convert the C declarations into Nim so to speak and a Nim feeling wrapper on top of it. Is that a valid take? |
| 20:17:25 | FromDiscord | <ieltan> I imagine read the library docs to see how it's API work and generate a Nimified interface on top of the raw low level futhark generated one |
| 20:17:33 | FromDiscord | <ieltan> (edit) "I imagine ... read" added "the AI would" |
| 20:17:44 | FromDiscord | <davidvfx07> In reply to @ieltan "I imagine the AI": That's what I was thinking. That doable no? |
| 20:17:51 | FromDiscord | <davidvfx07> (edit) "That" => "Thats" |
| 20:18:54 | FromDiscord | <davidvfx07> A lot of it is just aesthetics, but it also needs to keep to the functionality of the original library and also handle destructors etc properly, so I guess it becomes a lot more reliant on the llm than would be realistic to assume it can do (maybe) |
| 20:18:58 | FromDiscord | <ieltan> In reply to @davidvfx07 "I've always spoken about": Futhark creates a low-level binding and you hand write the high level binding. The nim library as a whole is a "wrapper" of another library |
| 20:19:51 | FromDiscord | <ieltan> The terms as far as I know are interchangeable but don't quote me on that |
| 20:21:46 | FromDiscord | <davidvfx07> I guess yeah |
| 20:22:31 | FromDiscord | <ieltan> In reply to @davidvfx07 "A lot of it": Ehhh yeah, it's not just aesthetics per say. The thing needs to feel natural to use and "idiomatic" |
| 20:23:43 | FromDiscord | <davidvfx07> Good point. I wonder if it would be helpful to somehow fine-tune a model for Nim specifically. I tried to make a RAG database at some point with a whole bunch of name documentation to try to get it to understand how to use Nim, but I was never able to get it to work right |
| 20:24:00 | FromDiscord | <davidvfx07> I don't have my finger on the pulse on this whole llm stuff, I bet it's doable though |
| 20:24:09 | FromDiscord | <davidvfx07> (edit) "this" => "the" |
| 20:24:19 | FromDiscord | <ieltan> In reply to @davidvfx07 "Good point. I wonder": I don't know 🙂 |
| 20:41:52 | * | beholders_eye joined #nim |
| 21:13:27 | * | beholders_eye quit (Ping timeout: 260 seconds) |
| 21:15:06 | * | beholders_eye joined #nim |
| 21:20:24 | * | bgupta quit (Server closed connection) |
| 21:20:32 | * | bgupta joined #nim |
| 22:06:29 | * | beholders_eye quit (Ping timeout: 256 seconds) |
| 23:16:55 | * | radicalned joined #nim |