December 2001 - Glasgow-haskell-users

Combining Module Interfaces
by Ashley Yakeley 07 Dec '01

07 Dec '01

Is there a way to combine interfaces into a single file? If I have modules A and B, I want to create a module C with all the exported definitions of A and B such that I can compile against C.hi file without needing the A.hi and B.hi files. I tried this: module C (module A,module B) where { import A; import B; } ...but if I attempt to compile against C.hi using definitions from A and B, GHC complains if I don't have A.hi and B.hi. I want C.hi to contain everything that A.hi and B.hi do. -- Ashley Yakeley, Seattle WA

1 0

RealWorld?
by Koen Claessen 07 Dec '01

07 Dec '01

Hi, I want to use the functions: hGetBufBA :: Handle -> MutableByteArray RealWorld a -> Int -> IO Int hPutBufBA :: Handle -> MutableByteArray RealWorld a -> Int -> IO () But as soon as I mention their types, 'RealWorld' is not in scope. In what module is this defined? /Koen.

2 1

RE: Questions about sharing
by Simon Peyton-Jones 07 Dec '01

07 Dec '01

| Does the compiler keep a unique copy of expressions which | consist of just a single zero arity constructor (eg. | [],True,Nothing..) as a CAF which is referenced each time the | constructor appears in an expression Yes, it does. | The second is.. | If, following pattern matching, the matched pattern appears | in an expression, is it shared or duplicated.. e.g. (a:as) -> | f (a:as) Maybe I should write something like this.. | x@(a:as) -> f x | (I know that sometimes the type checker won't allow you to do this) The compiler will share it if you are using -O; but only if the type checker would also allow it. (The internal language is typed!) Simon

1 0

RE: Problems creating a DLL with ghc-5.02.1
by Lehti, Patrick 07 Dec '01

07 Dec '01

Cool, that works! But now no import library is created. I thought this done during creating the dll? Patrick -----Original Message----- From: Sigbjorn Finne [mailto:sof@galois.com] Sent: Donnerstag, 6. Dezember 2001 16:35 To: Lehti, Patrick Cc: glasgow-haskell-users(a)haskell.org Subject: Re: Problems creating a DLL with ghc-5.02.1 Yes, if you're willing to do the following: - only use the --mk-dll option when linking together object files & archives (i.e., don't try compile a Haskell source file and create its DLL during the same invocation of GHC). (Remembering to include the _stub.o files too when linking). - modify your package.conf file, editing the entry for the 'rts' package to instead of having a library_dirs equal to ["$libdir"], have it be ["$libdir", "$libdir/gcc-lib"] Alternatively, add the command-line option "-Lc:/ghc/ghc-5.02.1/gcc-lib" to your ghc-5.02.1 (where c:/ghc/ghc-5.02.1 is wherever you've got GHC installed). hth --sigbjorn ----- Original Message ----- From: "Lehti, Patrick " <Patrick.Lehti(a)softwareag.com> To: <glasgow-haskell-users(a)haskell.org> Sent: Thursday, December 06, 2001 06:04 Subject: Problems creating a DLL with ghc-5.02.1 > Hi, > > I tried to wrap a Haskell application in a DLL using ghc-5.02.1. But this is > not working, with cygwin in path I got this error message: > /usr/lib/mingw/libmingw32.a(gccmain.o)(.text+0x88):gccmain.c: multiple > definition of `__main' > /usr/lib/libm.a(ds00023.o)(.text+0x0): first defined here > > ... and without cygwin in path, it could not find "dllwrap" and "dlltool". > > Is there any solution for this problem? > > Patrick >

2 1

Problems creating a DLL with ghc-5.02.1
by Lehti, Patrick 06 Dec '01

06 Dec '01

Hi, I tried to wrap a Haskell application in a DLL using ghc-5.02.1. But this is not working, with cygwin in path I got this error message: /usr/lib/mingw/libmingw32.a(gccmain.o)(.text+0x88):gccmain.c: multiple definition of `__main' /usr/lib/libm.a(ds00023.o)(.text+0x0): first defined here ... and without cygwin in path, it could not find "dllwrap" and "dlltool". Is there any solution for this problem? Patrick

2 1

RE: Problems creating a DLL with ghc-5.02.1
by Simon Peyton-Jones 06 Dec '01

06 Dec '01

I know that Sigbjorn is working on this. We will do 5.02.2 in due course, but I'm not yet sure how dll-friendly is will be. I don't understand all the issues yet. Simon | -----Original Message----- | From: Lehti, Patrick [mailto:Patrick.Lehti@softwareag.com] | Sent: 06 December 2001 14:05 | To: 'glasgow-haskell-users(a)haskell.org' | Subject: Problems creating a DLL with ghc-5.02.1 | | | Hi, | | I tried to wrap a Haskell application in a DLL using | ghc-5.02.1. But this is not working, with cygwin in path I | got this error message: | /usr/lib/mingw/libmingw32.a(gccmain.o)(.text+0x88):gccmain.c: | multiple definition of `__main' | /usr/lib/libm.a(ds00023.o)(.text+0x0): first defined here | | ... and without cygwin in path, it could not find "dllwrap" | and "dlltool". | | Is there any solution for this problem? | | Patrick | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

Communicating with other programs (Win32)
by Jan de Wit 05 Dec '01

05 Dec '01

Hi all, In my free time, I'm writing a Go program in Haskell. Main platform is GHC and GHCi under Win32. It is coming along nicely: it has a GUI and the moves it comes up with are starting to make some sense. For testing (and maybe later training :) purposes I want it to be able to play against GnuGo (the strongest Open Source Go program) on its own. Currently, to get GnuGo to think up a move, I use something like (SGF is the standard way of outputting Go games): | do writeFile "in.sgf" (showAsSGF game) | let cmd = "echo quit > gnugo --quiet --infile in.sgf --color " ++ | (show computerColor) ++ | " --mode ascii > out.txt" | system cmd | result <- readFile "out.txt" | return (parseResultMove result) I think this both ugly and inefficient: for every move a new instance of GnuGo gets started and an SGF file is output! Instead, I want to start GnuGo only once per game and communicate with it like a human player would, by typing commands at it; or by using the Go Text Protocol which is specifically designed for computer-computer play. Does anybody here know a way - under Win32 - to start a process in the background and communicate with it via its stdin/stdout? I've poked around a bit in the Win32 library source, looking for an FFI interface to CreateProcess (the API function which does what I want) but found nothing. The Posix library looks like it should be up to the job, but unfortunately that isn't supported under Win32... (I'm not using Cygwin) Any help would be appreciated! Cheers, Jan de Wit

2 1

Re: [qforeign] CursesTest segfaults
by Marcin 'Qrczak' Kowalczyk 04 Dec '01

04 Dec '01

29 Nov 2001 18:12:08 +0900, Jens Petersen <juhp(a)01.246.ne.jp> pisze: > I built qforeign from cvs under Linux. Any idea why > tests/CursesTest segfaults? No idea - works for me now. ghc-5.03 ncurses-5.2 glibc-2.2.3 gmp-3.1.1 readline-4.2 -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

2 1

RE: GHC 5.02.1 on Mac OS X
by Simon Peyton-Jones 03 Dec '01

03 Dec '01

Sebastien Carlier [sebc(a)posse42.net] was at one time working on a MacOSX port, but I don't know how far he got. There was one other person too, but I can't lay my hands on appropriate email. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 02 December 2001 22:50 | To: Nicolas Oury; GHC List | Subject: Re: GHC 5.02.1 on Mac OS X | | | At 2001-12-02 14:39, Nicolas Oury wrote: | | >do you know if there is a port of gh 5.02.1 on MacOSX? | | The latest I know of is GHC 5.00.2. And even that is incomplete, it | doesn't seem to include a createAdjustor for 'foreign export dynamic' | functions (if you happen to need that, as I do). | | -- | Ashley Yakeley, Seattle WA | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

4 7

RE: ghc and hierarchical module names
by Simon Marlow 03 Dec '01

03 Dec '01

[ thread moved from glasgow-haskell-users(a)haskell.org to libraries(a)haskell.org ] > "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > You must give the full module name in the header, eg. > > > module A.B.C where > > This surprised me somewhat, and I must have missed any > discussion/rationale. Could you elaborate/point me at the relevant > information? The discussion was on libraries(a)haskell.org (take a look at the archives), and the motivation was to make the smallest change possible to Haskell itself. With the current proposal, no changes are required to the Haskell report except for the 1-character change required to the lexical syntax of module names. I agree that it might be useful to be able to abbreviate module names by leaving out an initial prefix, so that entire subtrees can be moved without changing the source code. However, there are reasons why this approach is not so nice: as you point out, this introduces a dependency between the source code and the external environment, such that the meaning of a program depends on the directory layout and options to the compiler (currently the meaning depends on just the source to the collection of modules constituting the program), and also there is an inconsistency in that you would declare a module as 'C' but import it as 'A.B.C'. Cheers, Simon

1 0