Expose static nim library to DLL

2023-02-28 Thread PMunch
Did some testing and it was the `const` creating the issue. I did some minor fixes of Futhark so you should now be able to just `require "futhark >= 0.9.0"` in your nimble file and use `-d:nodeclguards`. Not quite sure why your types have an appended `union` to them, for me this doesn't happen.

Expose static nim library to DLL

2023-02-28 Thread PMunch
Hmm, it's strange that you're getting these issues. If I where to guess though Nim doesn't like union types in `const`. Try defining them as `let` like I did and see if that helps. And as of LOC I'm not surprised at all. Futhark, much like Nim itself, isn't made to make readable code. All those

Expose static nim library to DLL

2023-02-27 Thread konsumer
Ok, that worked, but the binding is still off. If I run this it outputs an empty image: import pntr var canvas = new_image(80, 80) draw_circle(canvas, 40, 40, 30, RED) discard save_image(canvas, "demo.png") Run I did color-defs like you did:

Expose static nim library to DLL

2023-02-27 Thread PMunch
You should use `sysPath` instead of `path` for any system libraries (like stdlib.h) as per the [basic usage](https://github.com/PMunch/futhark#basic-usage) section of the documentation. The difference is that `path` will try to wrap everything and make it available for you in Nim, which can cau

Expose static nim library to DLL

2023-02-27 Thread xeamcopz
I don't have time to respond right now, but since we posted so close to each other I just wanted to make sure you saw my last message.

Expose static nim library to DLL

2023-02-25 Thread konsumer
I came back to trying to use futhark on mac. I solved my original issue (installing/running it) with: ln -s "$(xcode-select --print-path)/usr/lib/libclang.dylib" /usr/local/lib/libclang.dylib Run But it still doesn't work for me. I took your pntr wrapper code above, a

Expose static nim library to DLL

2023-02-21 Thread PMunch
> There should be only 1 load/unload (when the core is initialized and > deinitialized by host) and the whole DLL is wiped in the process, so I think > maybe the libretro host kind of takes care of that, but I could be > misunderstanding. The problem is that when a dynamic library is unloaded t

Expose static nim library to DLL

2023-02-20 Thread konsumer
> using LD_LIBRARY_PATH every time you want to use Futhark you should look at > setting up your library path correctly, or symlink libclang.dynlib into your > library path. Ah! Yes, this makes sense. > Let me know if this works and then we can improve the installation section. I am itching to

Expose static nim library to DLL

2023-02-20 Thread PMunch
Good to hear you got Futhark installed! I realise that `--passL` would be required for the install, what that does is essentially tell your compiler where `libclang` is found so it can link against it. However when you run it the already compiled `opir` tool is failing to find the dynamic librar

Expose static nim library to DLL

2023-02-19 Thread konsumer
I think I have followed your advice. In libretro.nim header: type retro_video_refresh_t* = proc(data:ptr UncheckedArray[cuint], width:cuint, height:cuint, pitch:csize_t):void {.cdecl.} Run In core code: proc NimMain() {.cdecl, importc.} var buf

Expose static nim library to DLL

2023-02-19 Thread konsumer
OMG, getting futhark installed was easy when I just did this: nimble install futhark --passL:"\"-L$(xcode-select --print-path)/usr/lib\"" Run The final suggestion in the thread did not work, though: nimble install futhark --passL:'"-L$(xcode-select --prin

Expose static nim library to DLL

2023-02-19 Thread konsumer
This is really helpful. I will take a closer look, and try to get Futhark working. I appreciate all the time spent and help you have provided.

Expose static nim library to DLL

2023-02-19 Thread PMunch
I don't have time to respond right now, but since we posted so close to each other I just wanted to make sure you saw my last message. I wrote a short article on dynamic libraries in Nim

Expose static nim library to DLL

2023-02-19 Thread PMunch
There was another post today about dynamic libraries in Nim, so I decided to write a bit more about it:

Expose static nim library to DLL

2023-02-19 Thread konsumer
> It's compatible with the C code, and you can still assign to the uint32 as > you would expect from C. Nice! Yeh, I figured it was how it auto-generated the wrapper. Makes sense. > I'm writing an article on wrapping libraries with Futhark at the moment Awesome. Yeh, don't take it like me sayin

Expose static nim library to DLL

2023-02-19 Thread PMunch
> I am not sure what is going on with RED though, that seems very different > than the original code, but I'm sure it makes sense, if I look at what > Futhark outputted. In the C code it's a union between a uint32 and a struct with four uint8 fields as you say. Nim doesn't have anonymous struct

Expose static nim library to DLL

2023-02-19 Thread sls1005
> I think there is some other problem. Don't know. But I saw you've added `{.cdecl.}` to the type definitions in the example, so I think you can re-enable the GC and see if segfaults are gone.

Expose static nim library to DLL

2023-02-19 Thread konsumer
I think I had the path wrong before, but I still get the same error with ls /Library/Developer/CommandLineTools/usr/lib/ arclibtapi.dylib arch_tool libxcrun.dylib clang sourcekitd.framework libIndexStor

Expose static nim library to DLL

2023-02-18 Thread konsumer
Ok, it appears it's in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libclang.dylib Run I will play with Futhark. I like what you did with pntr, which is a friend's graphics lib that is still in flux, so it's probly going to c

Expose static nim library to DLL

2023-02-18 Thread PMunch
> That lclang issue talks about how to fix it on ubuntu, and is fairly involved > (not sure why a system-installed library should need all that) so it doesn't > really help me on mac. I have no /usr/lib/llvm-*, for example. Well it's just a matter of figuring out where libclang installed the fil

Expose static nim library to DLL

2023-02-18 Thread konsumer
> Poked around a bit (and added a forwarding feature to Futhark) and got > everything working I appreciate it! > The Futhark install issue with -lclang is simply because it isn't able to > find libclang, That lclang issue talks about how to fix it on ubuntu, and is fairly involved (not sure w

Expose static nim library to DLL

2023-02-18 Thread PMunch
Oh and by the way, when things "seem to work" and C is involved that doesn't really mean much. Before I made Futhark I wrote applications that ran for days before crashing out of nowhere because my bindings where ever so slightly incorrect. You can get a binding to the point where everything see

Expose static nim library to DLL

2023-02-18 Thread PMunch
The Futhark install issue with `-lclang` is simply because it isn't able to find libclang, this issue goes into a bit more detail: . To build `nimrtl` you need to be in the folder where the program lives, which is in Nim sources. But for ARC/ORC you

Expose static nim library to DLL

2023-02-18 Thread sls1005
What I tried to explain is that you have to mark the callback itself as `cdecl` if you want to accept a C function pointer as argument. For example: proc retro_set_video_refresh*(cb: proc(data:array[1280, int32], width:cuint, height:cuint, pitch:csize_t):void {.cdecl.}) {.cdecl,exp

Expose static nim library to DLL

2023-02-17 Thread konsumer
I hear that, and will use it, but it seems to work the same either way, and without `--mm:none` it segfaults.

Expose static nim library to DLL

2023-02-17 Thread sls1005
`{.stdcall.}` should only be used when the C form of the functions are also marked as `__stdcall`. Otherwise use `cdecl` (meaning the function has the same calling conversion as a C function) or `noconv` (meaning it does not have a explicit calling conversion). A calling conversion is like a pro

Expose static nim library to DLL

2023-02-17 Thread konsumer
`--mm:none` gets it not segfaulting, but is probly very much the wrong way to do it. I will experiment with it to see if I can actually use those callbacks.

Expose static nim library to DLL

2023-02-17 Thread konsumer
I ended up making a more minimal example [here](https://github.com/konsumer/libretro-nim) that might help others that want to make a libretro core in nim, once I get it all worked out. I added all the types and consts that I could figure out (and commented things I could not) and it seems to co

Expose static nim library to DLL

2023-02-17 Thread konsumer
Hmm, now I am back in C-dep-hell. I can otherwise build things fine on my mac. nimble install futhark ... ld: library not found for -lclang clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: execution of an external program fai

Expose static nim library to DLL

2023-02-17 Thread PMunch
When you run code that uses Futhark it will say which path it stored the results to. It's in the nimcache folder. But be aware that it might be hard to read. If you look in the documentation you can see that there are some flags to make the output more human readable.

Expose static nim library to DLL

2023-02-17 Thread konsumer
> that's why I wrote Futhark > You might also be interested in the genny > library, genny seems really good for my original usecase (wrap a couple nim functions for C) and futhark seems good for wrapping a C api for nim, but now I am dug into figuring this out in just nim, since I like how all

Expose static nim library to DLL

2023-02-17 Thread auxym
You might also be interested in the genny library, especially if you need to generate a header file for your exported Nim procs.

Expose static nim library to DLL

2023-02-17 Thread PMunch
Just trying passing it through Futhark with: import futhark importc: path "." "libretro.h" Run And right of the bat I can see that they use cdecl, and for example the type `retro_environment_t` returns a bool and not `void` like you have it in your

Expose static nim library to DLL

2023-02-17 Thread PMunch
Looks about right, assuming that your C wrapping is correct. It's easy to mess up in subtle ways, that's why I wrote Futhark, to get away from having to painstakingly match up every single procedure and type and ensure that the alignment, packing, calling conventions etc. all match up. The call

Expose static nim library to DLL

2023-02-17 Thread konsumer
Futhark looks really cool. I have already done the complicated part I was avoiding (translating all the functions & structs in a libretro plugin to nim) so I am not sure I want to auto-wrap it, at this point. I am happy with the way it's setup and it seems to run well, other than the one thing I

Expose static nim library to DLL

2023-02-17 Thread PMunch
This is pretty much exactly the use-case I had when developing Futhark. Essentially I was writing a dynamic library for Unbound, both DLL and so generated from the same source. The way it works is fairly simple, I have an `importc` block (from Futhark) which loads all the C headers from Unbound

Expose static nim library to DLL

2023-02-16 Thread konsumer
I will try that but I'm not sure I understand this part: > or mark the C functions as __stdcall if you prefer that. You mean where I tell C about the nim functions, or something else? As a possibly better way, I ended up trying to solve it the other way around, by implementing all the functions

Expose static nim library to DLL

2023-02-16 Thread sls1005
Try using `cdecl` or `noconv` instead of `stdcall`, or mark the C functions as `__stdcall` if you prefer that.

Expose static nim library to DLL

2023-02-16 Thread konsumer
Hi, I am kinda new to nim. I am trying to make a libretro core that uses nim. For those that are not familiar, the format of a retro-core is a DLL with a ton of specially-named exports. I started with [this example](https://github.com/libretro/libretro-samples/tree/master/video/software/renderi