Re: ANN: C->Haskell 0.8.1

qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,

15 Feb 2001 08:20:00 GMT, Marcin 'Qrczak' Kowalczyk pisze:

...

Does C2HSDeprecated export newStablePtr and freeHaskellFunPtr? Currently it does not, but GtkCList assumes it does.

Does C2HS export castPtrToFunPtr? Currently it does not, but GMarsh assumes it does.

Now I see: these functions in module C2HS are present in the released c2hs-0.8.2, but not in the CVS. I guess you have not committed changes.

Oops, you are right, I did only partially commit my last changes. I am sorry for that. Now, everything should be checked in.

gtk+hs' examples which compile with the present interface don't link on ghc-4.08.2, because of the ghc's bug in handling newtypes in foreign exports which references rts_mkPtr. This is because you made Addr a type synonym for Ptr ().

It can be "fixed" without making Addr incompatible with Ptr (which I guess is needed because c2hs generates Addr and code uses Ptr) by something like this: module PtrHack where import qualified Addr newtype Addr a = Ptr Addr.Addr module C2HSSomething where import qualified PtrHack type Ptr = PtrHack.Addr type Addr = Ptr () This ensures that the "real" name of the Ptr type is Addr.

I'll try this hack for QForeign to see if it can reduce the amount of #ifdefs for broken compilers. It applies to newtypes in arguments and results of functions in foreign export and foreign export dynamic in ghc-4.08*.

It should be applied to CInt etc. too, to let them work there. I can provide my own CTypes for ghc-4.08*, but at least I will get rid of many of those stupid #ifdefs.

Unfortunately it does not help for Ptr in the result of foreign export dynamic (ghc-4.08) nor in the argument of foreign import dynamic (ghc-4.08*), where newtypes don't work. This means that gtk+hs does not compile on 4.08 because of Ptr () (spelled as Addr) in the result of foreign export dynamic.

I thought that I had fixed all this for Gtk+HS. (In fact, all Gtk+HS examples are running fine with GHC 4.08 on my machine.) Have a look at the file gtk+hs/gtk/ghcRtsAux.c. It defines rts_mkPtr in a somewhat nasty way, but it works :-) It's a bit like your hack, but on the C level. Maybe you forgot to run autoconf and ./configure after your last cvs update for Gtk+HS?

Here is which ghc versions are broken in which ways:

| newtypes work in foreign... | | | | export | export | import | import | | | stat.& dyn.| dynamic | stat.& dyn.| dynamic | label | | (function) | (pointer) | (function) | (pointer) | (pointer) | ------------+------------+-----------+------------+-----------+-----------+ ghc-4.08 | hacked | no | yes | no | no | ghc-4.08.1 | hacked | yes | yes | no | yes | ghc-4.08.2 | hacked | yes | yes | no | yes | ghc-4.11 | yes | yes | yes | yes | yes |

"Hacked" means that they work as long as the type name after expanding type synonyms is recognized by the rts (and there is no way to #include something in stubs I think).

Yes, I agree. I also tried to get something #include'ed in stubs, but failed. That would have been the easiest solution. Anyway, thanks for checking that stuff. Cheers, Manuel PS: With the current Gtk+HS source in CVS, all Gtk+HS examples as well as the iHaskell library and its three examples should now all work again. I tested it all on my machine.