Re: ANN: C->Haskell 0.8.1
Thu, 15 Feb 2001 18:44:56 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> > 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?
Hmm, it works now. There are two files called C2HSConfig.hs (in
c2hs/lib and c2hs/toplevel). I don't know why the wrong one was
being imported.
> 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.)
Both are current versions from CVS, with version numbers as you say.
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.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Confused about enabling parallel ghc
> I installed ghc 4.08.2 binaries for sparc solaris (and those for intel > linux, too), then tried compiling a sample program (the fibonacci one > in the user guide) with ghc -parallel. The compiler complained: > > Could not find interface file for `Prelude' > in the directories ./*.hi >/u/trebla/lib/ghc-4.08.2/imports/lang/*.mp_hi > > /u/trebla/lib/ghc-4.08.2/imports/concurrent/*.mp_hi >/u/trebla/lib/ghc-4.08.2/imports/lang/*.mp_hi > > /u/trebla/lib/ghc-4.08.2/imports/concurrent/*.mp_hi >/u/trebla/lib/ghc-4.08.2/imports/std/*.mp_hi > > (and similarly for Parallel.) > > Does it mean I must build ghc myself from source? > > The user guide promises a lot of binary bundles such as par. Ever > since 4.0x, the ghc download page ceases to mention them. Where > are they? This just means that Parallel support isn't included in the binary bundle you have. In fact, parallel support is developed and distributed separately. Contact the GPH (Glasgow Parallel Haskell) folks for more information: http://www.cee.hw.ac.uk/~dsg/gph/ Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C->Haskell 0.8.1
15 Feb 2001 08:20:00 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> 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 * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Haskell threads & pipes & UNIX processes
[ moved to [EMAIL PROTECTED] ] > I need to compress the output of my Hakell program. To avoid > the creation > of huge files, I want to compress before writing by means of gzip or > bzip2. However, this seems to be quite involved. > > I decided to run the compressor with > > runProcess :: FilePath-- Command >-> [String]-- Arguments > -> Maybe [(String, String)]-- > Environment(Nothing -> Inherited) > -> Maybe FilePath -- Working > directory (Nothing -> inherited) > -> Maybe Handle-- stdin (Nothing > -> inherited) > -> Maybe Handle-- stdout (Nothing > -> inherited) > -> Maybe Handle-- stderr (Nothing > -> inherited) > -> IO () > > First I wanted to use Posix.createPipe to connect to the > compressor but > Posix.createPipe returns a Fd. So this does not fit. Aha, you want the (unadvertised) function PosixIO.fdToHandle :: Fd -> Handle > I ended up with using Posix.createNamedPipe. This creates a named pipe > that can be openend with IO.openFile (which again yields the > Handle needed > for runProcess). > > At this point, it turned out that the pipe has to be opened > for reading > before it can be opened for writing (ghc-4.08.1). This seems > to be a bug. > (In a shell, the order does not matter; the processes are suspended > as expected.) We've had some problems with named pipes - check the archives of glasgow-haskell-bugs. It seems certain operating systems disagree on the semantics of a non-blocking open of a named pipe. I don't recommend using named pipes if you want portable code. > Then, as expected, the problem occured that writing to the pipe and > compressing cannot be sequenced. If the producer is started first, the > producer blocks because there is no consumer. If the consumer > is started > first, the consumer blocks because there is no input. > > So I played around with threads. If both consumer and producer are > executed as threads, the program terminates immediately without any > output. There seems to be no need to start executing any of > the threads. In GHC, the main program terminates as soon as the main thread terminates. It doesn't wait for any child threads to terminate - if you want this behaviour, you can program it using MVars. We'll be happy to look at any of the other problems you mentioned: please some code demonstrating the problem to [EMAIL PROTECTED] Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C->Haskell 0.8.1
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote, > 15 Feb 2001 08:20:00 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> 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. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
