You'll be glad to know that I'm going to let the repository recover for a couple of days while I hang out with my family. This also means I probably won't be able to fix anything I've broken for a couple of days so let's hope I didn't break anything too badly. Top items on my agenda when I get back to it are: - Making sure that the wrapper and dynamic import forms work The code is there - just need to check it works. - Test, test, test Sigbjorn promised to whack on it with HDirect generated code. Sounds like a great stress test. I should try building HGL using --target ffi. - Add something to the test suite. Has to be written so that the tests pass if ffi is disabled or not implemented. - Further contemplation of how to invoke the ffi generation and how/whether that should invoke the C compiler The current story is that hugs +G will generate a fresh .c file and link it to get a .so file for every .hs file it loads which contains ffi code. This will not look so clever when people install their code in read-only directories. - Autoconfiscation Mostly porting/stealing code from the GHC autoconf stuff. Code most needing fixed are HsFFI.h and the function compileAndLink in ffi.c - More libraries (CError, CTypes, ...) Would be easier if we had the hierarchial modules up and running since the GHC versions are close to what we want. Hmmm, didn't Sigbjorn commit a script to suck the tree over? - Finish the implementation of foreign export. The difficult thing about foreign export is that you can export a function at a more specific type than its Haskell type. For example: foreign export ccall "plus_Int" (+) :: Int -> Int -> Int The way to do this is to treat it as though the user had written: plus_Int :: Int -> Int -> Int plus_Int = (+) foreign export ccall plus_Int :: Int -> Int -> Int My problem is that I am completely baffled by the typechecker - I can't figure out how to do this. (Help with typeForeignExport in type.c very welcome.) (I'd feel bad about the length of this list of undone things if I didn't feel that the ffi is much closer to being usable than it was before I started.) I'm not sure how fast I'll get through this list though - I'm supposed to be choosing and booking a wedding venue and I did hardly any real paying work this week. So if anyone feels like claiming some of these tasks as their own, I'd be one happy Haggis. -- Alastair ps There's some longer term goals like: - Stripping the Hugs-specific code out of GreenCard - Removing any primitives that can be implemented by the ffi - Cleaning up internal naming schemes in Hugs. Hugs still talks about MallocPtrs - terminology that died at least 5 years ago. Addr is gone too. - differentiate between primitives (could be associated with any module) and foreign functions (associated with a very particular module). Take the opportunity to cleanup registerPrims which is pretty gross. But these can wait until the new ffi has proved itself.
Here's the current status of the Hugs ffi code:
- Making sure that the wrapper and dynamic import forms work
Done.
- Test, test, test
Sigbjorn tested it a bit on Win32.
I should try building HGL using --target ffi.
Works.
- Add something to the test suite.
Testsuite in place. Could do with testing marshalling/unmarshalling of each individual type (especially the types subject to promotion in C).
Has to be written so that the tests pass if ffi is disabled or not implemented.
Nothing done on that front. Static linking should just be a question of dusting off the code in plugins.c
- Further contemplation of how to invoke the ffi generation and how/whether that should invoke the C compiler
The current story is that hugs +G will generate a fresh .c file and link it to get a .so file for every .hs file it loads which contains ffi code. This will not look so clever when people install their code in read-only directories.
hugs +G only generates code for files mentioned on the command line. The plan is that libraries supply a Makefile or script which does a bottom-up traversal of the module graph running hugs +G on each module containing foreign code. It would also specify any extra linking arguments like -lm, -lX11, cbits/Storable.c, -DDEBUG, etc. using the +L flag I'm now wondering whether hugs +G should be replaced by a separate program like runhugs.
- Autoconfiscation
Code most needing fixed are HsFFI.h and the function compileAndLink in ffi.c
Sigbjorn modified ffi.c:compileAndLink to work on Windows with the MS Visual C compiler. Autoconfing the code to compile and link the generated code is the biggest thing on my list at the moment. I want this question to be resolved by Hugs because otherwise it has to be tackled by everyone writing an ffi'd program. Option1 is to avoid the issue using libtool - but it is GPLd and I had some bad experiences when I tried to use it many years ago. Option2 is to key off the compiler and linker type (gcc, msvc, etc) and the OS type (linux, windows, MacOS X, etc). Not keen on this since it tends to create brittle code that needs continual maintenance. Option 3 (preferred but lots of work) is to do that classic autoconf thing of trying every option which we've ever heard of until we find one that works. That is, I write a small program which tries to do dynamic loading and I try compiling it with -shared, -bundle, -Z+q and everything else we can think of until we find a way that loads correctly. (While we're at it, we might as well detect whether or not to add leading underscores to names too - a bit less fragile than the current test which approaches the problem indirectly.)
Mostly porting/stealing code from the GHC autoconf stuff.
I stole the code but haven't yet started using it in HsFFI.h or configuring the libraries (i.e., CTypes.hs).
- More libraries (CError, CTypes, ...)
I put in just enough of this to run tests. I see these as temporary placeholders until we switch to using the hierarchial modules so I'm trying to minimise how much work I put into these.
- Finish the implementation of foreign export.
No progress. I'm tempted to do the NHC thing and require you to use a monomorphic type. People wanting to write portable code can easily do the translation that Hugs should be doing for you. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
participants (1)
-
Alastair Reid