- Glasgow-haskell-users

Binary library
by Amanda Clare 20 Nov '01

20 Nov '01

Does Malcolm's Binary library exist for ghc? If not, is there a standard way (ie using Haskell that works on any compiler) to dump a data structure into a file that another program or part of the same program can then pick up and read (cf "serialize" in Java)? I'm reluctant to go with a solution that's compiler-specific. Amanda

1 0

RE: not naming modules Main
by Simon Marlow 20 Nov '01

20 Nov '01

> Coming up with proposals is always much more difficult that simply > complaining about something. Here is a proposal which seems > reasonable to me (and implementable): > > Allow any module to have a main function. When you compile (with > ghc), and you say, for example: > % ghc --make Foo.hs -o Foo > then it looks in Foo.hs for the main function (regardless of > whether the name of the module appearing in Foo.hs is Main or > Foo). As I never use ghc without the --make option, I'm not sure > how this would roll over when not using it. Perhaps there could > be an option like: > % ghc Foo.hs Bar.hs FooBar.hs -o Foo -main-in Foo.hs > or something where you can specify which module has the main you > want to use. > > Then, say you have two modules, Foo.hs (containing module Foo) > and Bar.hs (containing module Bar), both with main functions, > suppose Foo is the one from which the desire main function comes, > you can always "import Bar hiding (main)". While we could do doubt implement this, I'm not sure the benefits are compelling enough. As Simon points out, you can always do your testing in GHCi which doesn't care whether you have a Main module or not. Furthermore this would be an extension to Haskell which isn't supported by the other compilers, so its usefulness is limited. Would anyone else find this useful? Cheers, Simon

1 0

RE: Posix.sync
by Simon Marlow 20 Nov '01

20 Nov '01

> > > Rather than patching the Posix library to include stuff like > > > O_SYNC, I'd like to see a Haskell binding to the Single > > > UNIX (aka Unix98) instead - it subsumes the > > > POSIX.1 APIs (and you can get at the specs without having > > > to pay the extortionate rates that IEEE charges). Feel free > > > to contribute such a binding! > > > > I'm afraid I will not. There is pretty huge number of > > functions to bind, and I'm afraid to miss some. Then I'm not > > wery good Haskeller. > > > > Moreover, I could not see the Single Unix features in the > > linux-2.2 (at least that nice O_DSYNC flag). Maybe they are > > presented in 2.4, but I have no plan to use it. > > AFAIK no OS implements all of the Single Unix specification. > Nevertheless, I think, Sigbjorn is right. Ideally, we > should have a binding for Single Unix and on any particular > OS, you will have a subset of it available (that's the same > situation as you have with any other programming language). > > As is pointed out in the open(2) man page, O_SYNC, O_DSYNC, > and O_RSYNC are synonymous in Linux 2.2. In 2.4, at least > with some file systems (eg, XFS) you can choose which > behaviour O_SYNC should have. I'd like to see a full SUS binding too. I also think that POSIX is a useful subset, because as Manuel says nobody implements the full SUS but pretty much everyone implements full POSIX (not always with the same semantics though :-). So my preferred solution would be a Unix library, from which Posix re-exports a subset. I started rewriting GHC's Posix library a while back - I got about half way though, and I'll get back onto it when I turn my attention to the new libraries again. I've kept all the suggestions from people on the lists regarding the Posix interface, and I'll put together a proposal for the new interface at some point. Discussion about the interface should probably move to libraries(a)haskell.org. Cheers, Simon

1 0

Posix.sync
by Max A . K . 20 Nov '01

20 Nov '01

Hello. What about include O_SYNC flag in the Posix.OpenFileFlag? Max.

3 4

RE: Strange fatal error
by Julian Seward (Intl Vendor) 19 Nov '01

19 Nov '01

We fixed some obscure GC-related bugs in 5.02. The fixes are in 5.02.1. When you try it with 5.02.1, does the problem still happen? J -----Original Message----- From: Andre W B Furtado [mailto:awfurtado@uol.com.br] Sent: Tuesday, November 13, 2001 7:41 PM To: glasgow-haskell-users(a)haskell.org Cc: hopengl(a)haskell.org Subject: Strange fatal error 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

2 1

GHC-5.02(.1) InstallShield for Windows
by Andre W B Furtado 18 Nov '01

18 Nov '01

I just would like to report that, if you have GHC-5.02 installed and want to install GHC-5.02.1 (under Windows), you'll need to uninstall GHC-5.02 first, otherwise the InstallShield for GHC-5.02.1 won't work as expected. Is this a bug? -- Andre

1 0

ghc-5.02 refuses to open a device file
by Max A . K . 16 Nov '01

16 Nov '01

I guess it's a [mis]feature, since 5.00 worked, but can hardly imagine anybody could need it. ======= Prelude> h<-IO.openFile "/dev/zero" IO.ReadMode *** Exception: unsupported operation Action: openFile Reason: unknown file type File: /dev/rtf0 Prelude> Leaving GHCi. max@max$cat /dev/zero <C-C> ======= Max.

1 0

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