Proposals for changes to searching behaviour
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposals for changes to searching behaviour
On Mon, Dec 09, 2002 at 12:40:18PM -, Simon Marlow wrote: - 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. Please let us know if either of these would make your life easier, or if there's anything else you'd like to see. Since the problem is often that your program/library has a managable depth, but it is _located_ very deep in the hierarchy (eg. User.* modules if you have a long and complicated domain), then how about allowing A.B/C.hs for module A.B.C? Then you don't need to have a long, mostly empty dummy hierarchy. Lauri Alanko [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ./configure
when installing ghc and hugs under SuSE linux 8.1 I got configure: error: can not guess host type; you must specify one It worked after I added --host=i386-linux [ redirected to [EMAIL PROTECTED] ] What does config.guess return on your system? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ./configure
Simon Marlow wrote: when installing ghc and hugs under SuSE linux 8.1 I got configure: error: can not guess host type; you must specify one It worked after I added --host=i386-linux [ redirected to [EMAIL PROTECTED] ] What does config.guess return on your system? i686-pc-linux-gnu Christian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposals for changes to searching behaviour
Hi, 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. Actually, I suggested putting it *after*. But putting it before might be quite nice, actually. So credit where credit is due! /Henrik -- Henrik Nilsson Yale University Department of Computer Science [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposals for changes to searching behaviour
Hi Lauri, Since the problem is often that your program/library has a managable depth, but it is _located_ very deep in the hierarchy (eg. User.* modules if you have a long and complicated domain), then how about allowing A.B/C.hs for module A.B.C? Then you don't need to have a long, mostly empty dummy hierarchy. Simon M. and I thought about that, but felt that it was unnecessarily complicated since it would lead to the number of possible file names for a module growing exponentially with the number components in the module name. It would probably be possible to devise a recursive search algorithm to deal with this, but that would be significantly more complicated than what GHC currently does, and, worse, users would also have to be aware of the exact algorithm used. Probably not worth it. But note, that with the suggested approach, you can flatten the hierarchy as much or as little as you like, and you can call the top-level directory whatever you like, including A.B, since the compiler does not care about that name. /Henrik -- Henrik Nilsson Yale University Department of Computer Science [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ./configure
Simon Marlow wrote:
when installing ghc and hugs under SuSE linux 8.1 I got
configure: error: can not guess host type; you must specify one
It worked after I added --host=i386-linux
[ redirected to [EMAIL PROTECTED] ]
What does config.guess return on your system?
i686-pc-linux-gnu
That's strange, configure is supposed to emit the error only if
config.guess fails. The relevant bit of the configure script is:
case $host_alias in
NONE)
case $nonopt in
NONE)
if host_alias=`${CONFIG_SHELL-/bin/sh} $ac_config_guess`; then :
else { echo configure: error: can not guess host type; you must
specify one 12; exit 1; }
fi ;;
*) host_alias=$nonopt ;;
esac ;;
esac
Could you try adding echos in various places to determine what has gone
wrong? It might be something specific to whatever /bin/sh is on your
system, I suppose.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ./configure
Simon Marlow wrote: Simon Marlow wrote: when installing ghc and hugs under SuSE linux 8.1 I got configure: error: can not guess host type; you must specify one It worked after I added --host=i386-linux [ redirected to [EMAIL PROTECTED] ] What does config.guess return on your system? i686-pc-linux-gnu That's strange, configure is supposed to emit the error only if config.guess fails. maeder@davinci - ./config.guess ./config.guess: line 844: dummy-5901.c: Keine Berechtigung ./config.guess: line 1: dummy-5901.c: Keine Berechtigung ./config.guess: line 1105: dummy-5901.c: Keine Berechtigung ./config.guess: unable to guess system type This script, last modified 2001-07-09, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from [...] could this output be the source of my problem? (Meanwhile the owner of the ghc tree changed so I cannot really reproduce the situation.) Cheers Christian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ./configure
That's strange, configure is supposed to emit the error only if config.guess fails. maeder@davinci - ./config.guess ./config.guess: line 844: dummy-5901.c: Keine Berechtigung ./config.guess: line 1: dummy-5901.c: Keine Berechtigung ./config.guess: line 1105: dummy-5901.c: Keine Berechtigung ./config.guess: unable to guess system type Keine Berechtigung == No authorization (according to babel fish). You wouldn't perchance be trying to configure in a tree you don't have write access to, would you? This script, last modified 2001-07-09, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from [...] could this output be the source of my problem? (Meanwhile the owner of the ghc tree changed so I cannot really reproduce the situation.) Aha, I think my hunch was correct :-) Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ./configure
Simon Marlow wrote: That's strange, configure is supposed to emit the error only if config.guess fails. maeder@davinci - ./config.guess ./config.guess: line 844: dummy-5901.c: Keine Berechtigung ./config.guess: line 1: dummy-5901.c: Keine Berechtigung ./config.guess: line 1105: dummy-5901.c: Keine Berechtigung ./config.guess: unable to guess system type Keine Berechtigung == No authorization (according to babel fish). You wouldn't perchance be trying to configure in a tree you don't have write access to, would you? Yes, since ownership changed I don't have write permission. But I could reproduce the original output below (because the same problem occurred when installing hugs). Oddly, other users here get i686-pc-linu-gnu. maeder@davinci - ./config.guess ./config.guess: unable to guess system type This script, last modified 2001-07-09, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from ftp://ftp.gnu.org/pub/gnu/config/ If the version you run (./config.guess) is already up to date, please send the following data and any information you think might be pertinent to [EMAIL PROTECTED] in order to provide the needed information to handle your system. config.guess timestamp = 2001-07-09 uname -m = i686 uname -r = 2.4.19-4GB uname -s = Linux uname -v = #2 Mon Dec 9 11:21:22 CET 2002 /usr/bin/uname -p = /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = i686 /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = i686 UNAME_RELEASE = 2.4.19-4GB UNAME_SYSTEM = Linux UNAME_VERSION = #2 Mon Dec 9 11:21:22 CET 2002 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc -M
Folks, after using ghc --make happily in a project for a while I am switching to using Makefiles since I have a number of Main programs in the same directory that share a lot of modules. Now, since ghc -M does such a great job at gobbling up the dependencies, I wonder if it was not possible to extend its functionality a little bit so that it also determines the .o files that are required to link a Main program. I could imagine something like an -optdep-Main and then the program name. -Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposals for changes to searching behaviour
Hi Andre, I like this idea, especially if this is currently the way Hugs does it. It's great for smaller projects. Yes, we believe Hugs does allow A.B.C.hs as well as A/B/C.hs. Ultimately, I think it is actually going to quite important that the different Haskell tools provoide reasonably compatible ways of finding sources/libraries. That includes the mechanisms discussed here as well as a package mechanims. 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. Second, I don't think this particular example of command line syntax is that obscure. Being able to tell GHC (and ultimately, I would hope, other Haskell implementations), what part of the module hierarchy they can find along a certain search path seems quite natural to me. 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. When dealing with large systems possibly involving many different languages and tools, it is very hard to predict what kind of source structure that is going to be most suitable and most easy for someone to get familiar with. Ultimately, the person(s) implementing an application/library is/are the one(s) best qualified for making such decisions, and the tools should ideally support that (within reason), not get in the way. Furthermore, different people might have different opinions on what's obvious, or what's the best tradeoff betweem obviousness/conveniece. To put it another way -- is there a situation where you don't want to use either of the above two module naming schemes, and can justify having unrelated modules in an arbitrarily organised directory structure? Well, again, ultimately I think the application/libabry implementor(s) should gave the ultimate say as to how to organize his/her/their sources, and what files that are sufficiently related to be put in a single directory. One reason I don't particularly like the A/B/C scheme, is that my sources can end up being spread out over several directories just because of the names I happen to choose for the modules. If, say, a library consists of the top-level module A.B.C and a bunch of internal components A.B.C.M1, A.B.C.M2, etc., I can't see why I should not be allowed to put them all in one directory. Another reason is how it interacts with tools like Make. I've already mentioned the VPATH mechanism. Other make facilities like its (as well as the invoked shell's) wildcard support for file name matching also becomes much less useful. The reason I'm not quite happy with fully qualified file names, is that they could become inconveniently long, and that it still can make sense to use directories for part of the module hierarchy. I think the two suggestions (. as an alternative to /, and the possiblity to associate a search path with a module prefix) complement each other quite nicely, yielding a scheme which lets the implementors decide how to best organize their source code. /Henrik -- Henrik Nilsson Yale University Department of Computer Science [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ./configure
Keine Berechtigung == No authorization (according to babel fish). You wouldn't perchance be trying to configure in a tree you don't have write access to, would you? Yes, since ownership changed I don't have write permission. But I could reproduce the original output below (because the same problem occurred when installing hugs). Oddly, other users here get i686-pc-linu-gnu. config.guess tries to compile a small C program to find out whether the system is a.out or ELF, and which version of libc it has. If you don't have write access to the source tree, how were you intending to build the software? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc -M
Hi Peter, Now, since ghc -M does such a great job at gobbling up the dependencies, I wonder if it was not possible to extend its functionality a little bit so that it also determines the .o files that are required to link a Main program. I could imagine something like an -optdep-Main and then the program name. Could come in handy sometimes, perhaps, but maybe there are other ways? If it is the size of the resulting executables that prevents you from linking each main.o file with all the other .o files (except the main ones), couldn't you just put all the non-main .o files into an archive and then let the linker figure out what to link against what for you? Make has pretty much all rules for building archives in a good way built in, so this is easy to do. If it's mainly a matter of avoiding clashes between the different Main modules, it should, with a little bit of care, not be too hard to structure the makefile to deal with that. Regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposals for changes to searching behaviour
On Mon, Dec 09, 2002 at 12:03:10PM -0500, [EMAIL PROTECTED] wrote: If, say, a library consists of the top-level module A.B.C and a bunch of internal components A.B.C.M1, A.B.C.M2, etc., I can't see why I should not be allowed to put them all in one directory. I think that's the selling point for me. I'm now convinced it's a good idea. That being said, I wrote that message because I've been struggling with obscure build tools for the last few days, which work fine until they break -- then you're in for hours of pain. So I prefer to stick to fairly obvious, explicit ways of doing something, and I guess I saw Simon's second suggestion as another way to have more pain-inducing bizarre build schemes via make. (Of course, this relies on the developer wanting to invent bizarre Makefiles, but I've seen _plenty_ of Makefiles where I can't even _begin_ to work out how they work. That's my fear.) Another reason is how it interacts with tools like Make. I've already mentioned the VPATH mechanism. It's all bad once that VPATH word gets mentioned ;). -- #ozone/algorithm [EMAIL PROTECTED] - trust.in.love.to.save ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RuntimeLoader now works on Mac OS X
Thanks to the amazing work by Wolfgang Thaller on GHC for Mac OS X, it was trivial to port the RuntimeLoader to work on Mac OS X (or Darwin, if you want to be pedantic). The runtime loader enables a GHC program to load object files (.o) at runtime and load functions in them, much like how you can dlopen() a shared library on many Unixes. For more information on the runtime loader, see http://www.algorithm.com.au/wiki/hacking/haskell.ghc_runtime_loading It's been tested and verified with GHC 5.04.2 on Mac OS X, and GHC 5.04 on Linux. If it works on Windows (and there's a good chance it might), please let me know! -- #ozone/algorithm [EMAIL PROTECTED] - trust.in.love.to.save ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposals for changes to searching behaviour
It's all bad once that VPATH word gets mentioned ;). Granted! But other work-arounds can be even worse! And again, if an implementor for some reason thinks he or she could benefit from using a mechanism like VPATH, it's good if that's not too painful. /Henrik -- Henrik Nilsson Yale University Department of Computer Science [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Libraries needing a main and ghci
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposals for changes to searching behaviour
- 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. Sounds useful (provided all major implementations agree). Btw, there's another convention, of adding suffixes to indicate processing phases (e.g., Main.hs.cpp.gz.uue). Is that likely to lead to conflicts (perhaps Main.WWW.hs for pipe through runhugs then post on web site?-)? - 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].' Does that mean I can refer to X.hs as [Graphics.Rendering.OpenGL(.Graphics.Rendering.OpenGL)*/]X.hs ?-) Probably no problem with Haskell's explicit imports. In contrast to the previous suggestion, this would actually save some trips to the OS when GHC is looking for files. I'm not sure about the details of your first suggestion, but if you take it to permit all mixtures of .and /, such as A.B/C.hs (I assume at least A/B.C.hs is already permitted?), you can get rid of the second - e.g., simply make Graphics.Rendering.OpenGL a link to .. That way, directory trees could be compressed (even the middle sections of long paths) while providing visible documentation of those shortcuts. I'd prefer that to compiler options (and instead of shortcutting into ., I'd probably have one second layer of directories, with shortcuts from . into those, if only to avoid naming conflicts at the leaves of the tree..). Claus ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
