- Glasgow-haskell-users

Readline version
by Frank Seaton Taylor 26 Oct '01

26 Oct '01

Good day folks. I've been having a bit of trouble compiling ghc5.02 from source on Solaris 2.6. The problem is that it can't find readline/readline.h which is not in a standard place since I had to compile readline myself. I've been messing around with various environment variables and configuration options, but have failed so far to communicate where this file is. I'm hoping someone can give me a suggestion. (I've reviewed the mailing list log and FAQ and have seen that readline is a problem on Solaris, but haven't seen anything that obviously is what I've been missing.) I hacked mk/config.mk to say GhcLibsWithReadline=YES, since I have libreadline.a and libtermcap.a in my LD_LIBRARY_PATH. That produced the aforementioned missing readline/readline.h. I tried CFLAGS=<blah> so that readline/readline.h should be visible but that didn't work either. One more thing, is there a particular version of readline I should be using? (I'm using 4.2) Thanks, ---Frank Seaton Taylor P.S. I'm a bit new at some of this stuff, so I may have misrepresented the situation. I'd be glad to clarify anything.

1 0

Re: ghc --make feature request
by cwitty＠newtonlabs.com 26 Oct '01

26 Oct '01

"Simon Marlow" <simonmar(a)microsoft.com> writes: > GHC actually has rather sophisticated recompilation checking which > goes beyond just checking whether the interface changed - it keeps > version information for each entity exported by a module and only > recompiles if any of the entities actually used by the module have > changed (this is described in the user's guide under the section on > recompilation checking). I've seen unexpected compiles using ghc --make. I've got a system with modules A, B, and C; A depends on B and B depends on C. I've seen the following sequence of events: I change C ghc --make A compiles C, B, and A I change A ghc --make A skips C and compiles B and A I don't know of any reason why it would have compiled B in the second case. If this is not a known bug, I can try to reproduce it and submit a formal bug report. Carl Witty

1 0

RE: Strictness Information (Was: ghc --make feature request)
by Simon Marlow 26 Oct '01

26 Oct '01

> On Friday 26 October 2001 14:41, Jan-Willem Maessen wrote: > > > You just need to change (for example) the > > strictness properties of the function, which can be very easy to do > > when making changes to your code. > > Is there a way to automatically discover the strictness of a > function? I > think it would be really usefull to have some kind of > extended :t command in > ghci which would do something like: > > main> :T foo > foo :: A (Strict) -> A (Strict) -> Bool > main> :T bar > bar :: a (Lazy) -> [a] (Lazy) -> [a] > > Perhaps this is possible already, and I just don't know about it. This may be possible for entities from compiled modules, but GHCi can't do strictness analysis for interpreted modules (due to quite boring reasons - the byte-code backend can't quite handle the output from some of the optimisation passes). That's an interesting suggestion anyway, we'll bear it in mind. Cheers, Simon

1 0

RE: ghc --make feature request
by Simon Marlow 26 Oct '01

26 Oct '01

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > GHC actually has rather sophisticated recompilation checking which > > goes beyond just checking whether the interface changed - it keeps > > version information for each entity exported by a module and only > > recompiles if any of the entities actually used by the module have > > changed (this is described in the user's guide under the section on > > recompilation checking). > > > > So the upshot is that what you're describing shouldn't > happen, and it > > may be a bug. Could you send us more info? > > Note that in GHC, the "version number" of a function can often change > for hard-to-spot reasons. You just need to change (for example) the > strictness properties of the function, which can be very easy to do > when making changes to your code. The compiler cares about (much) > more than just the types of imported objects. I tend to expect > recompiles whenever something depends on a function I've changed, even > if I don't think the changes were very significant. Good point. But I'd also like to add that these hard-to-spot reasons only apply when optimisation is turned on - otherwise the only way a function's version number may change is if its type changes. In GHCi, optimisation is never on so you shouldn't see any of these effects. Cheers, Simon

1 0

RE: ghc --make feature request
by Jan-Willem Maessen 26 Oct '01

26 Oct '01

"Simon Marlow" <simonmar(a)microsoft.com> writes: > GHC actually has rather sophisticated recompilation checking which > goes beyond just checking whether the interface changed - it keeps > version information for each entity exported by a module and only > recompiles if any of the entities actually used by the module have > changed (this is described in the user's guide under the section on > recompilation checking). > > So the upshot is that what you're describing shouldn't happen, and it > may be a bug. Could you send us more info? Note that in GHC, the "version number" of a function can often change for hard-to-spot reasons. You just need to change (for example) the strictness properties of the function, which can be very easy to do when making changes to your code. The compiler cares about (much) more than just the types of imported objects. I tend to expect recompiles whenever something depends on a function I've changed, even if I don't think the changes were very significant. -Jan-Willem Maessen

2 1

RE: ghc --make feature request
by Simon Marlow 26 Oct '01

26 Oct '01

> I just wanted to make a feature request to ghc --make (there seem to > have been a number of such...) > > I have a project currently consisting of 36 Haskell modules, and a > number of support modules for those. > > Naturally, compiling this takes quite some time (even for ghc --make) > especially considering that one of the modules is a happy-generated > parser. > > When I make a bug fix in one of the modules early in the dependancy > chain, this forces a recompile of all the modules above it, > even if the > modules interface hasn't changed. > > I would suggest that when ghc --make recompiles a module, it should > compare the new interface with the old one, and if they are the same, > doesn't force recompiliation of the modules that depend on it, but > merely change the time on those files without actually compiling. GHC actually has rather sophisticated recompilation checking which goes beyond just checking whether the interface changed - it keeps version information for each entity exported by a module and only recompiles if any of the entities actually used by the module have changed (this is described in the user's guide under the section on recompilation checking). So the upshot is that what you're describing shouldn't happen, and it may be a bug. Could you send us more info? Cheers, Simon

1 0

ghc --make feature request
by Martin Norbäck 26 Oct '01

26 Oct '01

I just wanted to make a feature request to ghc --make (there seem to have been a number of such...) I have a project currently consisting of 36 Haskell modules, and a number of support modules for those. Naturally, compiling this takes quite some time (even for ghc --make) especially considering that one of the modules is a happy-generated parser. When I make a bug fix in one of the modules early in the dependancy chain, this forces a recompile of all the modules above it, even if the modules interface hasn't changed. I would suggest that when ghc --make recompiles a module, it should compare the new interface with the old one, and if they are the same, doesn't force recompiliation of the modules that depend on it, but merely change the time on those files without actually compiling. Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped

1 0

RE: GHC Installation Location
by Ashley Yakeley 26 Oct '01

26 Oct '01

At 2001-10-25 03:18, Ashley Yakeley wrote: >>I've wondered at various times in the past whether there ought to be a >>link from /usr/local/includes/ghc to /usr/local/lib/ghc-5.02/includes. > >Won't help, my GHC is installed at /usr/lib/ghc-5.02/, exactly where the >Debian package put it. Actually I suppose this means I could write #include <ghc/Rts.h> At 2001-10-25 09:05, Mieszko Lis wrote: >I'm not sure this would be so good when you want to have two versions of ghc >installed on the same machine... Currently the Debian ghc5 package installs links such as /usr/bin/ghc using the 'alternatives' system. You'd just need to add a /usr/include/ghc one to that alternatives group. -- Ashley Yakeley, Seattle WA

2 1

Fwd: Can I install HOpenGL in Windows?
by Michael Weber 25 Oct '01

25 Oct '01

* Denver <denver_so(a)yahoo.com.au> [2001-10-26T01:25+1000]: > > Please help. I would like to use HOpenGL within Windows, so I wanted > to ask whether it was possible, and if it is, I would like to request > for help. Any help greatly appreciated. Hi! I'm sorry, I don't know much about the Windows port of GHC, but I'm sure the folks at glasgow-haskell-users(a)haskell.org can be of some help, or maybe the author of HOpenGL can step in... [Sven, AYT? =)] I'll do a Cc: to the list. To subscribe to any of the GHC mailing lists, please visit http://haskell.org/ghc/mailing-lists.html Cheers, Michael

1 0

Reading files via http or ftp
by Colin Paul Adams 25 Oct '01

25 Oct '01

Has anyone used the Socket library to read files specified via an http and/or ftp URL? -- Colin Paul Adams Preston Lancashire

1 0