cvs commit: nhc98/src/prelude/FFI CTypes.h CTypes.hs CTypesExtra.hs
panne 2004/06/12 16:24:28 PDT Modified files: src/prelude/FFI CTypes.hs CTypesExtra.hs Added files: src/prelude/FFI CTypes.h Log: * Changed CPtrdiff, CWchar, and CSigAtomic into INTEGRAL_TYPES * Same for CSize, CClock, and CTime. Note the type => newtype change here * Factored out the macro hacks Note that this implies some mysterious changes to some include/...hi files, but lacking some information I'm totally unable to track the necessary changes here. Some help is needed, the best I could manage was: Cannot find constructor for newtype: InfoData 92 NHC.FFI.CPtrdiff IEnone 92 (DataNewType False []) This happened after copying the generated FFI.hi plus adding finalizerFree to it and compiling some code (= OpenGL package) containing "fromIntegral foo" where foo has the type CPtrdiff. Revision Changes Path 1.5 +1 -148 nhc98/src/prelude/FFI/CTypes.hs 1.3 +12 -10 nhc98/src/prelude/FFI/CTypesExtra.hs
Sven Panne wrote:
[...] Some help is needed, the best I could manage was:
Cannot find constructor for newtype: InfoData 92 NHC.FFI.CPtrdiff IEnone 92 (DataNewType False []) [...]
FYI: I just gave CInt a try, but it didn't work, either: Cannot find constructor for newtype: InfoData 77 NHC.FFI.CInt IEnone 77 (DataNewType False []) In a nutshell: Some help would be appreciated to get nhc98's CTypes (a.k.a. Foreign.C.Types) in line with the FFI report (everything is a newtype + has the required instances). Cheers, S.
Sven Panne
Cannot find constructor for newtype: InfoData 92 NHC.FFI.CPtrdiff IEnone 92 (DataNewType False [])
Cannot find constructor for newtype: InfoData 77 NHC.FFI.CInt IEnone 77 (DataNewType False [])
OK, I've just checked in a new version of include/NHC/FFI.hi, copied directly from the build tree (src/prelude/FFI/FFI.hi) incorporating your recent changes. You will need to ensure that the 'base' library package gets re-built using this new interface: rm targets/`harch`/libraries rm -r targets/`harch`/obj/libraries/base make libraries If it still doesn't work, then it is possible that your application code is importing, re-exporting, then re-importing CPtrdiff() and CInt() abstract, i.e. without their constructors. That can confuse nhc98, which needs the definition info to appear in the interface file, in order to determine what the real underlying type is. This is probably a bug, but one that is not easy to fix without introducing other bugs. The workaround is to mention the constructors on import/export, viz, CInt(..). Regards, Malcolm
Malcolm Wallace wrote:
[...] If it still doesn't work, then it is possible that your application code is importing, re-exporting, then re-importing CPtrdiff() and CInt() abstract, i.e. without their constructors. [...]
Murphy strikes again: Of course I stumble across exactly this bug in nhc98. >:-( I guess I can work around this, but fixing this would be nice. It makes the usage of the FFI with nhc98 a bit hard and surprising from time to time. Int8, Int16, ... seem to be handled magically different, BTW. Cheers, S.
Sven Panne
Murphy strikes again: Of course I stumble across exactly this bug in nhc98. I guess I can work around this, but fixing this would be nice. It makes the usage of the FFI with nhc98 a bit hard and surprising from time to time.
Yes, it would be nice to fix.
Int8, Int16, ... seem to be handled magically different, BTW.
They are defined as data Int8 data Int16 etc, that is, as algebraic datatypes with no definition. Hence operations on them can only be defined primitively in the runtime system. Regards, Malcolm
Cannot find constructor for newtype: InfoData 92 NHC.FFI.CPtrdiff IEnone 92 (DataNewType False [])
Cannot find constructor for newtype: InfoData 77 NHC.FFI.CInt IEnone 77 (DataNewType False [])
If it still doesn't work, then it is possible that your application code is importing, re-exporting, then re-importing CPtrdiff() and CInt() abstract, i.e. without their constructors. That can confuse nhc98, which needs the definition info to appear in the interface file, in order to determine what the real underlying type is. This is probably a bug, but one that is not easy to fix without introducing other bugs. The workaround is to mention the constructors on import/export, viz, CInt(..).
OK, I think I have fixed this bug. It should now be possible to export a newtype abstractly, and the real underlying type will still be visible to the importing module, so the FFI can use it. Sven, would you like to revert some of the workarounds you introduced in libraries recently, to see if it really works now? Regards, Malcolm
Malcolm Wallace wrote:
[...] Sven, would you like to revert some of the workarounds you introduced in libraries recently, to see if it really works now?
Things definitely improved, but there is still a buglet:
panne 2004/06/20 13:19:02 PDT
Modified files: libraries/GLUT/Graphics/UI/GLUT Overlay.hs Log: Improved nhc98-specific hack a bit: It still seems necessary to see the underlying type for a newtype FFI argument, only the need for its constructor has gone.
Revision Changes Path 1.11 +2 -4 fptools/libraries/GLUT/Graphics/UI/GLUT/Overlay.hs _______________________________________________ Cvs-libraries mailing list Cvs-libraries@haskell.org http://www.haskell.org/mailman/listinfo/cvs-libraries
participants (3)
-
Malcolm Wallace -
Sven Panne -
Sven Panne