hugs ffi - question thats been bugging me for some time
In docs/ffi-notes.txt, I find the following: ------------------------------------------------------------ o foreign export static is not implemented. You can code around this by writing: foreign import dynamic foo_dynamic :: Addr -> (A -> B -> C) foreign label foo_addr :: Addr foo = foo_dynamic foo_addr instead of: foreign import foo :: A -> B -> C ------------------------------------------------------------------------- Does anyone understand what this is saying? I can't grok it. The work around presented here seems to have nothing to do with foriegn export static. It looks like a workaround to not having foreign IMPORT static. (Which we of course dont need a workaround for :)). Is something extremely tricky going on or am i just dense? Anyway, just curious, I have not had any trouble working around by passing pointers to the C-side using foreign export dynamic. I have just wondered about this for a long long time :)
The ffi specification changed after this documentation was written. What we used to call foreign export dynamic is now called foreign import wrapper. It made sense at the time but I won't even try to explain it because the new terminology makes much more sense. I'm in the process of bringing the ffi into line with the current spec. -- Alastair Reid Reid Consulting (UK) Ltd
"R" == R Legere
writes: In docs/ffi-notes.txt, I find the following: ------------------------------------------------------------ o foreign export static is not implemented.
You can code around this by writing:
foreign import dynamic foo_dynamic :: Addr -> (A -> B -> C) foreign label foo_addr :: Addr foo = foo_dynamic foo_addr
instead of:
foreign import foo :: A -> B -> C ------------------------------------------------------------------------- Does anyone understand what this is saying? I can't grok it. The work around presented here seems to have nothing to do with foriegn export static. It looks like a workaround to not having foreign IMPORT static. (Which we of course dont need a workaround for :)). Is something extremely tricky going on or am i just dense?
Anyway, just curious, I have not had any trouble working around by passing pointers to the C-side using foreign export dynamic. I have just wondered about this for a long long time :)
On windows, hugs +G (or ffihugs +G, not sure) links and compiles using microsoft tools ("cl"). It used to just generate the stubs, and leave it to you to do the rest. This way is smoother, but does depend on owning visual studio. This is a non-issue for me, since I do have visual studio, but how would you proceed using the borland tools or cygwin or some other free tools? Do you have to build hugs using those tools to get it to work? Or are these just not supported? (Hey, you can't support everything, I can understand that !) On a related question, where can I find source to the win32 libs and the hugs graphics library for windows? I browsed CVS for a while, but couldn't find them there. Cheers, and thanks Ron
On windows, hugs +G (or ffihugs +G, not sure) links and compiles using microsoft tools ("cl"). It used to just generate the stubs, and leave it to you to do the rest. This way is smoother, but does depend on owning visual studio.
I changed it because it let me centralize the unpleasant task of configuring and building ffi code instead of many individual library maintainers having to figure it out and maintain it themselves.
This is a non-issue for me, since I do have visual studio, but how would you proceed using the borland tools or cygwin or some other free tools? Do you have to build hugs using those tools to get it to work?
That would be the simplest option. I believe it works with cygwin. [It used to work with Borland too but I think it's about 5 years since it was tested last.] If we wanted to let users override the choice of compiler, there's a bunch of options: 1) Provide a flag which means 'generate the code but don't compile and link it'. This would make Hugs behave the way it did this summer. 2) Provide a mechanism (command line option or environment variable) to override the C compiler invocation string at runtime. The configuration string is in config.h[.in] and looks like this: /* C compiler invocation use to build a dynamically loadable library. * Typical value: "gcc -shared" * Must evaluate to a literal C string. */ #define MKDLL_CMD "gcc -shared" 3) Some kind of dynamic test determines which compiler is used. I'm not at all keen on this - just bug reports and bugs waiting to happen. Both options are pretty easy. I think the second option would fit best with some kind of GHC/NHC-like package mechanism (which I think I'd like to add to Hugs).
Or are [borland tools or cygwin] just not supported?
I'd love to add support for other compilers to Hugs (both on Windows and on other platforms). If you or anyone else is in a position to test new configure options, start by tweaking hugs98/src/config.h to try out new flags. Once you find something that works, mail it to me and I'll make the appropriate changes to hugs98/src/configure.in. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
Well, option 1) seems reasonable, but then I suppose you have to document how to link things up anyway.. so perhaps that argues for option 2? Anyway, will have to try building on cygwin and see what happens, I will let you know:) Ron
Or are these just not supported? (Hey, you can't support everything, I can understand that !)
I wanted to reply to this separately because I think the answer is important. Our goal is for Hugs to work on as many platforms as possible. If Hugs doesn't work on your machine using the OS and C compiler of your choice, please work with us to fix this. Hugs is already pretty portable (after the first dozen or so platforms, it's pretty easy to add another) so usually all it takes is a few good bug reports and you'll be up and running. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
Forget part II of my question. The source is in hslibs on cvs. I knew that, once. Duh. Ron
participants (3)
-
Alastair Reid -
Alastair Reid -
R. Legere