October 2001 - Glasgow-haskell-users

Re: IO concurrency
by Max A . K . 11 Oct '01

11 Oct '01

On Thu, Oct 11, 2001 at 01:28:39PM +0200, Volker Stolz wrote: > In local.glasgow-haskell-users, you wrote: >>> interact hIn = do >>> line <- hGetLine hIn >>> numIn <- handleToInt {-made from handleToFd & fdToInt-} >>> -- threadWaitRead numIn {-3-} > > Why should uncommenting -3- help when it happens *after* the > hGetLine? It doesn't. It helps if going before. My fault. I pasted to the msg somehow edited code, so the additional lines and comments was not checked. > Is your Tcl-app printing out "click" or "click\n", i.e. > with the additional linefeed? Command 'puts "click"' makes implicit line brake, so yes, "click\n" > Did you try disabling blocking entirely? I tried. No effect, as expected. Max.

1 0

Problem linking a COM DLL
by Lehti, Patrick 11 Oct '01

11 Oct '01

I am still trying to build a Haskell COM component with GHC 5.02 and HDirect (from http://www.galconn.com/~sof/hdirect-0.18-src.tar.gz) I have a problem linking the DLL, I always get 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 I am calling ghc with this command: >ghc --mk-dll -o QuiPeX.dll Main.o ParseAndRender.o ParseAndRenderProxy.o ParseAndRenderProxy_stub.o ComDllMain.o dll_stub.o ComDllMain_stub.o -optdll--def -optdllParseAndRender.def -fglasgow-exts -syslib com -package text By the way, the same error occurs when trying to build the comserv example! Can anybody help me with that? Patrick

1 0

No type lib generated by hdirect
by Lehti, Patrick 10 Oct '01

10 Oct '01

I am trying to build a Haskell COM component with HDirect (from http://www.galconn.com/~sof/hdirect-0.18-src.tar.gz) and "ghc 5.02". I have problems generating the type library: it is simply not created. Even the comserv example is not working because of the same problem. Could that be a bug in that HDirect version? Patrick

2 2

posix library for Windows?
by Dean Herington 10 Oct '01

10 Oct '01

Is the posix library (-package posix) supposed to be supported on Windows? If not (as I expect to have confirmed), what are the alternatives for process control on Windows? Dean

1 0

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 10 Oct '01

10 Oct '01

At 2001-10-10 01:19, I wrote: > foreign import "foo" raw_foo :: Ptr () -> IO (Ptr ()); > > foo :: Ptr SomeLinkedList -> IO (ConstPtr Char); > foo = importFunction raw_foo; Actually I don't need to convert the pointers, do I? If I have (Storable SomeLinkedList), I can just declare foreign import "foo" foo :: Ptr SomeLinkedList -> IO (Ptr Char); and it should work. The only thing that's missing is a ConstPtr type... -- Ashley Yakeley, Seattle WA

1 0

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 10 Oct '01

10 Oct '01

At 2001-09-23 23:54, I wrote: >As you point out, there are restrictions >on just what existing C functions you can bind to. If your function looks >like this: > > const char* foo (struct SomeLinkedList*); > >...you have no choice but to write 'impedance-matching' code for that >function. On second thought, I wonder if this is really true? It seems possible to declare a "raw" import and then use Haskell to adapt: foreign import "foo" raw_foo :: Ptr () -> IO (Ptr ()); foo :: Ptr SomeLinkedList -> IO (ConstPtr Char); foo = importFunction raw_foo; instance Storable SomeLinkedList where { ... }; Of course you'd need a suitable definition of importFunction: class ConvertValueToRaw t r | t -> r where { importValue :: r -> t; exportValue :: t -> r; }; class ConvertFunctionToRaw t r | t -> r where { importFunction :: r -> t; }; instance (ConvertValueToRaw tv rv) => ConvertFunctionToRaw (IO tv) (IO rv) where { importFunction rawF = do { rv <- rawF; return (importValue rv); }; }; instance (ConvertFunctionToRaw tb rb,ConvertValueToRaw ta ra) => ConvertFunctionToRaw (ta -> tb) (ra -> rb) where { importFunction rawF ta = importFunction (rawF (exportValue ta)); }; instance ConvertValueToRaw (Ptr a) (Ptr ()) where { importValue = castPtr; exportValue = castPtr; }; instance ConvertValueToRaw Word8 Word8 where { importValue = id; exportValue = id; }; etc. -- Ashley Yakeley, Seattle WA

1 0

IO concurrency
by Max A . K . 10 Oct '01

10 Oct '01

Hello. Playing with GHC, I met some oddity. Consider the example: > import IO > import Concurrent > import Posix > import PosixIO > > main = do > (fdIn, fdIn_send) <- createPipe > hIn_send <- fdToHandle fdIn_send > hIn <- fdToHandle fdIn > -- The "waiter" is a simple tk/tcl script which > -- prints "click" anytime I click a button. > runProcess "./waiter" [] Nothing Nothing > Nothing (Just hIn_send) Nothing > -- hSetBuffering hIn LineBuffering {-2-} > -- hSetBuffering stdin LineBuffering > forkIO(interact stdin) > -- forkIO(interact hIn) {-1-} > main_cycle > where > interact hIn = do > line <- hGetLine hIn > numIn <- handleToInt {-made from handleToFd & fdToInt-} > -- threadWaitRead numIn {-3-} > putStrLn line > interact hIn > main_cycle = do > putStrLn "tick" > threadDelay 1000000 > main_cycle The example works OK. It prints "tick" once a second and dups my input as I type it. But, when I uncomment the line {-1-} to handle input from child as well, everything is hanged on this read operation. Uncommenting the {-3-} line helps, but, first, I'm not sure it is a right way and, second, the matter is still unclear - what is the reason of such difference? Uncommenting the {-2-} lines doesn't help. I thing the reason is in some inner properties of the handlers, but have no idea in which one. Max.

1 1

ghc 5.02 and Solaris ld
by Akop Pogosian 10 Oct '01

10 Oct '01

$ grep 'ld.*-x' `find . -name Makefile` ./ghc-5.02/ghc/lib/std/Makefile: ld -r -x -o $@ $(GHCI_LIBOBJS) ./ghc-5.02/ghc/lib/std/Makefile: ld -r -x -o HSstd1.o $(filter Prel%, $(GHCI_LIBOBJS)) ./ghc-5.02/ghc/lib/std/Makefile: ld -r -x -o HSstd2.o $(filter-out Prel%, $(GHCI_LIBOBJS)) ./ghc-5.02/hslibs/win32/Makefile: ld -r -x -o HSwin321.o $(filter Win32M% Win32N% Win32R% Win32W%, \ ./ghc-5.02/hslibs/win32/Makefile: ld -r -x -o HSwin322.o $(filter-out Win32M% Win32N% Win32R% Win32W%, \ It looks like ghc makefiles assume that I am using GNU ld. The -x option does not exist in Solaris version of ld. Is this just a bug or ghc was not meant to be linked with other versions of ld? Just wondering, I could always use GNU ld instead (its just not the first thing on my PATH) According to the SunOS ld manual '-z redlocsym' seems to do what -x does. -z redlocsym Eliminates all local symbols except for the SECT symbols from the symbol table SHT_SYMTAB. All relocations that refer to local symbols will be updated to refer to the corresponding SECT sym- bol. So, I'll try to edit the makefiles accordingly and see what happens. --akop

1 0

Re: HOpengl on Ghc 5.02
by cwitty＠newtonlabs.com 09 Oct '01

09 Oct '01

Nicolas <Nicolas.Oury(a)ens-lyon.fr> writes: > Hi there, > Sorry for this stupid question: > Is there a distrib of a HOpenGl package working with ghc 5.02. I tried > the CVS but don't manage to make it work (ghc 5.03 panic). > Can someone help me? I got HOpenGL to work without trouble. On September 29, I checked out the ghc-5-02 branch from CVS, configured it with --enable-hopengl, and built and installed it. (I actually built a Debian package, using the Debian packager's build scripts.) I doubt if it matters, but I'm using HOpenGL with gtk+hs and gtkglarea instead of Glut. Carl Witty

1 0

RE: ghc-pkg
by Simon Marlow 09 Oct '01

09 Oct '01

> Additionally, ghc --make lacks (AFAIK) several useful > features found in > other make tools (although not all in the same tool...): > > 1. The ability to distingush directories containing source > code to be > compiled from directories containing previously compiled code > (hmake has the flags -P and -i, hbcmake has -i and -I). (I guess > you could use -package-conf as a cumbersome substitute, though.) > > 2. The ability to specify compiler flags for individual modules > without putting them in the source code. (Some flags > are 'static' > and can not be put in the source code.) > 3. The ability to compile several modules in parallel, on a > multi-processor machine, or a network of workstations. > 4. The ability to automatically invoke program generators > (e.g. happy)... > 5. A graphical user interface. All valid arguments, of course. But in --make's favour, it *is* much faster than individual compiles. In a little test I did today, ghc --make beats hmake/nhc98 on a reasonably sized program (nofib/real/anna). I timed both with -H32m and no optimisation, ghc --make compiled it in 48 seconds compared to 51 seconds for hmake/nhc98. On small individual modules, nhc98 wins hands down though. Ok, so speed isn't everything, and I hear the arguments you enumerated above. Most of these can be achieved through extra compiler support, and the last one (a make GUI) should actually be easier with GHC once we get around to specifying the compiler's programmatic API more precisely. Cheers, Simon

2 1