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

Sun, 11 Feb 2001 23:20:07 +1100, Manuel M. T. Chakravarty pisze:

...

I am pleased to announce the availability of version 0.8.1 of the interface generator C->Haskell.

Wow!

A problem: c2hs/gen/CInfo.lhs imports class Storable from module C2HSConfig, which does not export it.

Also, the compilation fails (on ghc-4.11): /usr/local/bin/ghc -c -syslib lang -syslib posix -O -recomp -fno-warn-incomplete-patterns -i. -fglasgow-exts C2HSMarsh.hs

C2HSMarsh.hs:43: Bad interface file: ./Ptr.hi does not exist

and similarly for other files. This is because there exists Ptr.hs in this directory - but it should not be taken from there, because the right version is in ghc's own libraries.

This is very strange, because I have tested this and it worked for me. In fact, if you look at the Makefile in the c2hs/lib/ directory, then you will see that the `depend' target moves these troublesome files into a subdirectory before compilation (called ghc411hackdir). Is it possible that you used the same build tree to compile with 4.08 first and then re-compile with 4.11? This won't work, because of the hack mentioned above. In fact, I think, this is a bug in ghc 4.11 - I have filled it as bug #131631 in the bug tracker. Cheers, Manuel

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

Mon, 12 Feb 2001 14:07:01 +1100, Manuel M. T. Chakravarty pisze:

...

In fact, if you look at the Makefile in the c2hs/lib/ directory, then you will see that the `depend' target moves these troublesome files into a subdirectory before compilation

So they will be downloaded each time from the CVS... Perhaps it would be better to store them under different names and make symlinks if needed?

They are only moved away in the build tree (where they are only sym links anyway). if you clean the whole tree and start again with configuration and build, you should be fine. Manuel

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

12 Feb 2001 14:48:09 GMT, Marcin 'Qrczak' Kowalczyk pisze:

...

It could be my fault: I ran ./configure before updating it with autoconf, and perhaps did not clean afterwards.

Ok, it was my fault. But the error in CInfo is still there.

That's strange. Could you try this with either the release of 0.8.2 that I put up yesterday or with the CVS version again? I don't have any trouble with CInfo with both 4.08 and 4.11.

And C2HS does not export most of cast*Ptr functions, freeHaskellFunPtr and newStablePtr, which leads to errors in compilig gtk+hs. And GtkCList (from the CVS version of gtk+hs) does not import C2HS but uses newStablePtr etc. And ghc version check in gtk+hs fails for 4.11.

As noted on the Web page, 0.8.1 didn't work with gtk+hs. You need c2hs 0.8.2 and the new version 0.10.2 of gtk+hs, which I released yesterday. (Alternatively, the versions of both packages in CVS should work, too.) Cheers, Manuel

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. 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. 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). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

Fri, 16 Feb 2001 18:42:08 +1100, Manuel M. T. Chakravarty pisze:

Now, everything should be checked in.

Seems OK, thanks. ghc411hack_dir does not work for me again: ghc -M in build/ghc4/chs/lib can't find NewStablePtr.hs (because there is only NewStablePtr.hs.in) and the whole 'make depend' there fails, without removing files conflicing with ghc' libraries. The failure of 'make depend' is ignored and finally 'make' there fails to compile C2HS.hs.

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 :-)

I've seen the hack, but on another box freshly installed ghc-4.08.2, c2hs from tarball and gtk+hs from tarball did not work (linker can't find rts_mkPtr). I must see if ghcRtsAux.c is compied at all there.

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.

ghc version check fails on 4.11 (it should be lexicographic comparison of version number components, not conjunction of independent comparisons). Checking for buggy readXXXOffAddr (for ghc-4.03..4.06) is now unnecessary as gtk+hs requires ghc-4.08.1 anyway. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

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

...

ghc411hack_dir does not work for me again:

Ah, I see: haven't run autoconf in c2hs subdirectory. Now it will hopefully work.

Automating the invocation fo autoconf is on the TODO list, but I didn't get around to it yet. Manuel

Mon, 19 Feb 2001 15:53:41 +1100, Manuel M. T. Chakravarty pisze:

Strange - meanwhile, I have put release 0.10.4 out. Among other things, it finally has an `install' target.

Thanks, everything compiles and mostly works. Examples still behave strangely: rngtest goes crazy when changing the number of digits, all rngtest's widgets are displayed with some black border unless the mouse cursor is over them, the scale in ih/examples/Counter does not work, threadtest does not work etc.

`castCCharToChar' and `castCharToCChar' should be sufficient here, right?

Yes. Same in C2HSDeprecated. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

Fri, 16 Feb 2001 18:42:08 +1100, Manuel M. T. Chakravarty pisze:

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.

They compile but they don't run correctly on ghc-4.11. It's because GMarsh.writeCharOffAddr does not simulate Addr.writeCharOffAddr when Char is wide, because instance Storable Char treats Char as wide. You need to cast to CChar, Word8, or Int8 (be careful with sign extension). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK