cvs commit: hugs98/src HsFFI.h Makefile.in builtin.c machdep.c storage.c storage.h
reid 2003/03/14 03:59:38 PST Modified files: src HsFFI.h Makefile.in builtin.c machdep.c storage.c storage.h Log: Removed support for HugsAPI1-3, left support for 4, 5 and '0' Revision Changes Path 1.12 +27 -41 hugs98/src/HsFFI.h 1.46 +1 -1 hugs98/src/Makefile.in 1.52 +28 -121 hugs98/src/builtin.c 1.84 +5 -47 hugs98/src/machdep.c 1.69 +2 -78 hugs98/src/storage.c 1.54 +3 -146 hugs98/src/storage.h
ok. There's quite a bit of HugsAPI2 code still being used and
distributed. My preference is that support for it stayed around.
--sigbjorn
----- Original Message -----
From: "Alastair Reid"
reid 2003/03/14 03:59:38 PST
Modified files: src HsFFI.h Makefile.in builtin.c machdep.c storage.c storage.h Log: Removed support for HugsAPI1-3, left support for 4, 5 and '0'
Revision Changes Path 1.12 +27 -41 hugs98/src/HsFFI.h 1.46 +1 -1 hugs98/src/Makefile.in 1.52 +28 -121 hugs98/src/builtin.c 1.84 +5 -47 hugs98/src/machdep.c 1.69 +2 -78 hugs98/src/storage.c 1.54 +3 -146 hugs98/src/storage.h _______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
ok. There's quite a bit of HugsAPI2 code still being used and distributed. My preference is that support for it stayed around.
Really? Where? How much? Does it work with the new hierarchial libraries and with yesterday's CVS copy of Hugs (i.e., did it work before my commit)? Since it is GreenCard generated code, can we just recompile it using the ffi target instead of the Hugs target? Does this code rely on any other features of Hugs that we might like to change? How long should we keep support for it around? HugsAPI2 has been deprecated since 2000/12/13. Is it still likely to be around come the time of the next Hugs release? Couldn't you have mentioned this on one of the occasions when I said I was planning to remove all GreenCard support (as distinct from ffi support) from Hugs? -- Alastair
"Alastair Reid"
ok. There's quite a bit of HugsAPI2 code still being used and distributed. My preference is that support for it stayed around.
Really? Where? How much?
Win32 library. SOE. HDirect generated COM client code + libraries. GC, as released, will output HugsAPI3 decls. HDirect outputs HugsAPI2. So, pretty much any code generated by either tool that's out there.
Does it work with the new hierarchial libraries and with yesterday's CVS copy of Hugs (i.e., did it work before my commit)?
The only thing I've got access to now is the Win32 library, which works fine (well, sometime ago I had to go through it and use 'fromIntegral' throughout to do sized Int/Word conversions, as Int and Word dropped support for a bunch of conversion functions.) There's little cost in supporting it, hence my suggestion. I wouldn't mind simply having needPrims() treat 2&3 just like 4. --sigbjorn
Sigbjorn:
Win32 library. SOE. HDirect generated COM client code + libraries. GC, as released, will output HugsAPI3 decls. HDirect outputs HugsAPI2.
I'd really like to kill off these dependencies so that we're just supporting one API and we know what we're free to change, what we have to test and so that we only have to support one API. So, I killed the Hugs backend for GreenCard since the ffi backend provides the same functionality. The CVS copy of HDirect uses API4 so it isn't affected by this commit but I'd like you to delete that backend anyway and have people switch over to the ffi backend. Win32 and SOE are known to build fine with the ffi backend so all we have to do is update documentation and do a fresh release. (I've got some pending changes for a new SOE release anyway.) So the only things left are previously generated HDirect COM code and any other previously generated GreenCard code. Is there that much? Is it that hard to regenerate? Will it still exist next time we do a Hugs release? Sigbjorn:
There's little cost in supporting it, hence my suggestion.
I'd like to make a serious effort to kill all the dependencies on the old code. If we reckon this isn't enough, I'm happy to revert the code and come back to this in a year or so and try again. You're right that it's not much code but there's a lot of cruft in Hugs and this seems like an easy place to start cutting.
I wouldn't mind simply having needPrims() treat 2&3 just like 4.
I'm not sure if that works - I made some changes in how Floats and Doubles are handled when I switched over to handling the ffi. -- Alastair
participants (3)
-
Alastair Reid -
Alastair Reid -
Sigbjorn Finne