November 2001 - Glasgow-haskell-users

FreeBSD/x86 package of 5.02.1 available
by Simon Marlow 15 Nov '01

15 Nov '01

FreeBSD/x86 packages of 5.02.1 are up on haskell.org. There's a native package: http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1.tgz the port it was built from http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-i386-unknown-freebsd-p ort.tar.gz and a standard .tar.gz package http://www.haskell.org/ghc/dist/5.02.1/ghc-5.02.1-i386-unknown-freebsd.t ar.gz Cheers, Simon

1 0

RE: ghc --make + #include directories
by Simon Marlow 14 Nov '01

14 Nov '01

> Simon Marlow wrote: > > > What's wrong with just saying -I<dir> whenever you say -i<dir>? > > This seems to work but for more complicated combinations the > two options have slightly > different formats. For example, if I have several > directories separated by colons, and > end the list with a superfluous colon (which arises naturally > enough when the path is > auto-computed) I get messages like: Ok, that's a bug. In the meantime, you'll have to remove the trailing colon. Cheers, Simon

1 0

RE: ghc --make + #include directories
by Simon Marlow 14 Nov '01

14 Nov '01

> Thanks to ghc --make it is now common to compile files from a > different directory. > This creates a new problem, in that if a file starts with a > {-# include <c-header.h> #-} > directive, ghc will try to find c-header.h in the current > directory, not in the directory > containing the source file. So we need a way of changing the > gcc include path during > compilation of .hc files to include the directory containing > the source file. What's wrong with just saying -I<dir> whenever you say -i<dir>? Cheers, Simon

2 1

ghc --make + #include directories
by George Russell 14 Nov '01

14 Nov '01

Thanks to ghc --make it is now common to compile files from a different directory. This creates a new problem, in that if a file starts with a {-# include <c-header.h> #-} directive, ghc will try to find c-header.h in the current directory, not in the directory containing the source file. So we need a way of changing the gcc include path during compilation of .hc files to include the directory containing the source file.

1 0

RE: Input Processing Loops in Haskell
by Simon Marlow 14 Nov '01

14 Nov '01

> On Tue, Nov 13, 2001 at 05:02:54PM -0000, Simon Marlow wrote: > > > > You can paraphrase this in Haskell, in the IO monad, like this: > > > > loop = do { > > a <- get_input; > > if (a == gET_OUT) then return () else loop; > > } > > > I follow, but I've never seen brackets used in Haskell code. Are they > included for clarity, or do they have syntactic value? Is > this the same > as > > loop = do > a <- get_input > if (a == GET_OUT) then return () else loop > > ? Yes, it's the same. Some people prefer to use the explicit punctuation; personally I use whatever looks more readable for the code I'm writing, which in most cases means I use layout for small functions but punctuation for large chunks of code where it's hard to see which bits line up. Cheers, Simon

1 0

ANNOUNCE: linkchk-0.02 released
by Jens-Ulrik Petersen 14 Nov '01

14 Nov '01

Happy to announce linkchk version 0.02 is out. >From the NEWS file: * width of window is now fixed * new options to set: ** window width ** host to be pinged ** interface * checks ifconfig to see if interface is up * use implicit parameters for command-line options The tarball and i386 rpm are now available on: http://www.01.246.ne.jp/~juhp/haskell/linkchk/ linkchk is also on freshmeat.net. Enjoy, Jens

1 0

Strange fatal error
by Andre W B Furtado 13 Nov '01

13 Nov '01

Can anyone explain me the following error? fatal error: scavenge: unimplemented/strange closure type 0 @ 08C03FD0 (this happened with a program that reads and do some manipulations in a 3MB bitmap file, using HOpenGL-1.01 and GHC-5.02 under Windows 98 + Cygwin) Thanks, -- Andre

1 0

RE: Input Processing Loops in Haskell
by Simon Marlow 13 Nov '01

13 Nov '01

> I apologize if this is a bit off-topic -- I'm asking it here because > if what I want to do is possible, it may only be possible with ghc > extensions, as opposed to vanilla Haskell...... > > In many types of applications, it's common to have a loop which > loops infinitely, of at least until some condition is met. For > example, in C-like syntax: > > for (;;;) { > a = get_input(); > if (a == GET_OUT) break; > do_comthing(); > } You can paraphrase this in Haskell, in the IO monad, like this: loop = do { a <- get_input; if (a == gET_OUT) then return () else loop; } In GHC this won't grow any stack each time around the loop, even with optimisation off. It depends on the actual implementation of the IO monad, but I imagine the other Haskell implementations will also have this property. Cheers, Simon

3 3

RE: profiling behavior
by Simon Marlow 13 Nov '01

13 Nov '01

> > > If module A imports B, and if B was compiled without the > > > profiling options > > > (but A was), is the final program expected to abort (illegal > > > operation or > > > something like that)? If it is, why? > > > > You must compile (and link) the whole program with -prof, > because that > > option changes certain fundamental properties of the > virtual machine. > > If you link modules compiled in different ways, the behaviour is > > unspecified ;-) > > Then I ask: if I have a compiled version of a Haskell > binding/API/(something > like that), without the profiling options, will I have to > hack the source > code of this binding/API/(something like that) and compile it again to > enable profiling, even though I want to profile a part of a > program that > doesn't make any call to the binding/API/(something like > that) functions? Yes. In order to compile your program with profiling, you also need versions of all the libraries compiled for profiling (which is why you get two versions of all the packages shipped with GHC). Cheers, Simon

1 0

RE: Sockets on Solaris
by Simon Marlow 13 Nov '01

13 Nov '01

> I'm having trouble using the Socket module on > Solaris. > > The following program: > > import System > import Socket > import IO > > main = > do > d <- connectTo "localhost" (PortNumber 80) > hPutStr d "GET / HTTP/1.0\n\n" > hFlush d > c <- (hGetContents d) > putStr c > > > fails with: > > Fail: invalid argument > Action: getSocketOption > Reason: Invalid argument It turns out there is still a problem with SocketPrim.getSocketOpt (which is used indirectly by Socket.connectTo) which shows up on Solaris. It'll be fixed in 5.02.2. Cheers, Simon

1 0