Nim is a compiled, garbage-collected systems programming language which has an excellent productivity/performance ratio. Nim's design focuses on efficiency, expressiveness, elegance (in the order of priority).
<FromDiscord> <ajusa> I found https://github.com/arnetheduck/nbindgen, thought I had seen it before. Guess I'll try it, unless someone has a better way of doing this
<FromDiscord> <sealmove> why don't we have a
split() proc that takes a string as separator?
<reversem3> I'm looking at this doc https://nim-lang.org/docs/xmltree.html#kind%2CXmlNode how do you actually extract instead of having to add elements
<FromDiscord> <sealmove> In reply to @รєคɭ๓๏שє "why don't we have": oh we do
<FromDiscord> <haxscramper> In reply to @reversem3 "I'm looking at this":
node.tag() https://nim-lang.org/docs/xmltree.html#tag%2CXmlNode
<FromDiscord> <haxscramper> !eval import std/[xmlparser, xmltree]; echo parseXml("<a>b</a>").tag()
<NimBot> a
<FromDiscord> <haxscramper> Or
loadXml for file in your case
<FromDiscord> <haxscramper> In reply to @ajusa "are there any examples": I'm not aware of any other approach for interfacing nim and rust rather than via C interop (and I suppose this is the only way it could work). You should try
nbindgen as it would probably automate a lot of boilerplate actions that might be the cause for "whole bunch of errors"
<FromDiscord> <haxscramper> I.e. most likely this is all caused by some misconfiguration where some "very important rust header" is missing when importing to nim
<FromDiscord> <haxscramper> Or vice-versa
<FromDiscord> <ajusa> sent a code paste, see https://play.nim-lang.org/#ix=2WEM
<FromDiscord> <exelotl> I emit the vtables in the same module where they're declared, but I {.importc.} the pointer to the vtable which is emitted in a helper module that gets imported last of all once the names of all the vtables are known
<FromDiscord> <haxscramper> In reply to @ajusa "Alright, yeah I just": You have to statically list with some rust runtime library in order to resolve this reference
<FromDiscord> <haxscramper> E.g.
-passl:-lsomerustlib I think.
<FromDiscord> <ajusa>
libdl.so and libpthread.so.? I'll try that, found those being referenced in a post online
<FromDiscord> <konsumlamm> no, though that's the default behaviour now on devel
<FromDiscord> <konsumlamm> or already? idk
<FromDiscord> <konsumlamm> i mean, it really depends on your type, there is no general answer
<FromDiscord> <exelotl> In reply to @exelotl "I emit the vtables": ideally I'd emit the vtable itself in the helper module, but idk if it's possible to declare an
extern function with an unknown signature in C 😅
<reversem3> To find children in xml node it says proc child(n: XmlNode; name: string): XmlNode , why do I need a name " xml.child()
<reversem3> * To find children in xml node it says proc child(n: XmlNode; name: string): XmlNode , why do I need a name " would it be just xmlFile.child() ?
<FromDiscord> <willyboar> gitter bridge down?
<FromDiscord> <haxscramper> That way it could be adapted to any input source without having to go through some templating format first
<FromDiscord> <jtiai> Probably providing some default templating could be useful.
@haxscramper I think I prefer an app rather than a lib
<FromDiscord> <haxscramper> I'm talking about keeping IR clean and accessible to external users, not about implementing it as a library instead of an application. But considering you want to use moustache/scf we are probably thinking about different implementation routes so
<FromDiscord> <clyybber> In reply to @exelotl "yooo the helper module": nice to hear!
<FromDiscord> <clyybber> We could map {.nodecl, importc.} with an export to that behaviour maybe
<FromDiscord> <clyybber> so that it would get replicated automatically for each module that imports it
but I suppose is easy to implement