- Glasgow-haskell-users

RE: ANNOUNCE: GHC version 5.04.2 released
by Simon Marlow 11 Dec '02

11 Dec '02

> Not sure what happened, but it seems however that > <http://haskell.org/ghc/> was reverted somehow, since it now > only talks about 5.04, there is no longer any mention of > 5.04.2. I moved things around a bit, and forgot to update a couple of links. The 'Download' link on the left contents pane has always pointed to the right place, though. Sorry for the confusion. Cheers, Simon

1 0

Why do not all Syntax elements have a SrcLoc?
by Reto Kramer 11 Dec '02

11 Dec '02

Is there a particular reason why only "top level" AST elements in the Language.Haskell.Syntax libarary have a SrcLoc attribute? It would be very handy for my application to be able to know the src location of each AST element and I was wondering if there was a deeper reason why that's not the case. Also I wonder if other would be interested in an extension that captured the start (line,column) as well as the end (line column) of AST elements (handy for rendering src). - Reto

1 0

Problems with main in a lib*.a. Is that a bug?
by Nicolas Oury 11 Dec '02

11 Dec '02

Hello, I am building a SDL binding on MacOS X (but the same problem should appears on Windows). It defines it's own main function in a libSDLmain.a. But I can't get ghc not to generate a main when linking with -lSDLmain, which is the option that is indicated to get the main function that make SDL usable. when I link write : ghc -o test Main.hs libSDLmain.a , ghc doesn't generate a main as it can see there is a main in libSDLmain. And my test programs works. but when I write ghc -o test Main.hs -lSDLmain, ghc creates its own main, and it doesn't work. The first solution is not convenient as the standard way of getting parameter is "sdl-config" which gives back the second types of argument. -no-hs-main don't change anything on this point. Is there a flag saying ghc not to generate a main? Cheers, Nicolas Oury

2 1

Proposals for changes to searching behaviour
by Simon Marlow 10 Dec '02

10 Dec '02

Hi Folks, Henrik Nillson & I have been discussing the current behaviour of GHC when searching for modules, particularly in combination with hierarchical modules, and have identified two ways in which things might be made more flexible. The current situation forces you to put sources in a directory hierarchy which mirrors the module hierarchy. While simple, this might be inconvenient, and will certainly be painful when the module hierarchy gets deeper. Also, the current situation seems to have caught people out more than once (perhaps that's a documentation problem, though). My own preference is for keeping things as simple as possible, so I'm generally in favour of the status quo - but we always value feedback from our users, so please let us know what you think. Anyway, here's the two suggestions: - The sources for a module A.B.C would be allowed to be placed in either A.B.C.hs or A/B/C.hs relative to one of the directories in the search path. Currently only A/B/C.hs is allowed. This is an easy change to make, and I believe Hugs already does it this way. - We could provide the ability to specify a module prefix to associate with a directory in the search path. For example, you could say that the directory '.' is associated with the module prefix "Graphics.Rendering.OpenGL" and avoid having to place your sources in the directory Graphics/Rendering/OpenGL. I'm not sure what syntax we'd use for this. Henrik suggested placing the module prefix in square brackets before the directory, eg. ghc -i '-i[Graphics.Rendering.OpenGL].' In contrast to the previous suggestion, this would actually save some trips to the OS when GHC is looking for files. Please let us know if either of these would make your life easier, or if there's anything else you'd like to see. Cheers, Simon

6 10

RE: Proposals for changes to searching behaviour
by Simon Marlow 10 Dec '02

10 Dec '02

> > > I'm not sure what syntax we'd use for this. Henrik suggested > > > placing the module prefix in square brackets before > the directory, > > > eg. > > > ghc -i '-i[Graphics.Rendering.OpenGL].' > > > > This seems a bit unpredictable to me; it means that you can > > have a whole bunch of unrelated modules sitting together in the > > same directory, and then confuse the user even more with obscure > > GHC commandline switches :). > > First, the point here is to reduce the number of assumptions > built into > a Haskell system about where sources live and what they are called. > The fewer assumptions that are made, the greater the likelyhood that > it will interoperate smoothly with other tools. Try to use the current > mapping from hierarchical module names to file names with the Make > VPATH mechanism for an example of what I mean. I've never quite managed to figure out what VPATH is for; one reason is that I've never got it to cooperate well with automatically-generated dependencies. If there's a specific restriction in GHC that prevents the use of VPATH, could you describe what it is? > > I'd argue that if you have a Graphics.Rendering.OpenGL module, > > you should make it 100% obvious that the module is in > > a Graphics.Rendering category; either putting it in a > > Graphics/Rendering directory or having > > a Graphics.Rendering.OpenGL.hs file makes this explicit. > > I see little merrit in having a Haskell system enforce such rules. It comes down to this: the Haskell system has to find files (normally interface files). Either these files are named according to a simple convention, or you have to tell the compiler more about where they live. You would rather we moved towards the latter position. There's a compromise (well sort of). If you don't need to use --make, then GHC will let you use whatever filenames you like for the sources; the only restriction is that it has to be able to find the interfaces, so you have to arrange they get placed where GHC can find them either by using the -ohi flag or by having the build system move them. Even if you do need to use --make or GHCi, then I think you can still specify all the source files on the command line. Actually, I've just tried this and it almost works. The interface files get put in the current directory and have all but the last component of the module name stripped off, which is fine as long as you don't have any other modules with the same last component. I think perhaps fixing this and documenting the behaviour would be a good step forward. Then would there be any reason to need the other extensions? Cheers, Simon

3 2

Options in hs files; Bug report?
by ketil＠ii.uib.no 10 Dec '02

10 Dec '02

I posted something on haskell@, but perhaps this is a better forum for possible bug reports (I didn't get any replies, at any rate). (Edited severely for brevity and relevance) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

-hidir separation of search/output paths
by Andre Pang 10 Dec '02

10 Dec '02

On Tue, Dec 10, 2002 at 10:15:58PM +1100, Andre Pang wrote: > Is it possible to modify the behaviour so that if --make > -no-hs-main is specified, GHC won't perform the link if it finds > a main function? Oops, one more request which I almost forgot: -hidir currently specifies both where to search for .hi files, and where to output hi files. It would be good to split up the two operations into two distinct options; e.g. use -hidir to search for interface files, and a new option such as -ohidir to specify where to output new interface files. This is very useful if you're trying to build stuff (with --make) outside of the source tree: you could write "-i$src/SomeLibrary" to tell GHC to find the .hs files in a directory named $src/SomeLibrary, "-hidir$build/SomeLibrary" to find the .hi files in a directory named $build/SomeLibrary, and "-ohidir ." to tell GHC to output any .hi files to the current directory Being able to build outside of the source directory (e.g. if you make a 'build' directory in the source tree, and do ../configure from there) is fairly common, and is also required for passing a 'make distcheck' if you use automake. Currently, if you use "-hidir ." to put interface files in the current directory, GHC will only search the current directory for hi files, so it keeps building stuff unnecessarily if you specify imports outside the current directory with "-i$src/SomeLibrary", since they get built to $build/SomeLibrary instead of the directory you're currently in. Another way of achieving the same thing without adding a new option would be to search the directories specified with -i for interface files as well as .hs files; that way, you could do "-i$src/SomeLibrary -i$build/SomeLibrary -hidir ." to perform the same thing as the above. (I hope that wasn't too confusing!) -- #ozone/algorithm <ozone(a)algorithm.com.au> - trust.in.love.to.save

1 0

RE: Libraries needing a main and ghci
by Simon Marlow 10 Dec '02

10 Dec '02

> I am doing a small binding to SDL lib. It needs on some platforms to > have a C main function. > > So I make a C main that call Haskell initialisation, Haskell > main and > call shutdownHaskell. > > It works fine with ghc. > > When linking with ghci I have an error : > > > ghci -package SDL > [...] > Loading package SDL ... linking ... not found: _shutdownHaskell Looks like a bug. Can you use shutdownHaskellAndExit() instead? Cheers, Simon

1 0

RE: Ticky-ticky profiling?
by Simon Peyton-Jones 10 Dec '02

10 Dec '02

You need to cd into fptools/libraries, and say 'make way=t'. (The "way" stuff is described in the building guide. Better still, set GhcLibWays=t to your build.mk file.) This will build a library tree with flag -ticky, which is what you need. You do need to build from source to do this. Simon | -----Original Message----- | From: Kirsten Chevalier [mailto:krc@uclink.berkeley.edu] | Sent: 09 December 2002 19:55 | To: glasgow-haskell-users(a)haskell.org | Subject: Ticky-ticky profiling? | | Hi, | I'm wondering what needs to be done in order to use ticky-ticky profiling -- | section 5.7 in the Users' Guide says: | | "To be able to use ticky-ticky profiling, you will need to have built | appropriate libraries and things when you made the system. See ?Customising | what libraries to build,? in the installation guide." | | but that section in the installation guide doesn't seem to exist. When I | try to compile programs with -ticky, I get lots of "Could not find interface | file" errors, so presumably I need to "build appropriate libraries and things". | If anyone could tell me what that specifically means, I'd appreciate it. | | Thanks, | Kirsten | | -- | Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Libraries needing a main and ghci
by Nicolas Oury 09 Dec '02

09 Dec '02

Hello, I am doing a small binding to SDL lib. It needs on some platforms to have a C main function. So I make a C main that call Haskell initialisation, Haskell main and call shutdownHaskell. It works fine with ghc. When linking with ghci I have an error : > ghci -package SDL [...] Loading package SDL ... linking ... not found: _shutdownHaskell What should I do? Thanks a lot, Cheers, Nicolas. PS: I use ghc 5.04.2

1 0