RE: Ticky-ticky profiling?
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:[EMAIL PROTECTED]] | Sent: 09 December 2002 19:55 | To: [EMAIL PROTECTED] | 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 * [EMAIL PROTECTED] * Often in error, never in doubt | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Proposals for changes to searching behaviour
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Proposals for changes to searching behaviour
- 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. Good point, which should be cleared up. We don't intend GHC to have any knowledge of relative pathnames and the meaning of '.' or '..'. So the meaning of an import path [Graphics.Rendering.OpenGL]D would be simply this: when looking for a module's source/interface, if the module name is of the form Graphics.Rendering.OpenGL.M, then we look for D/M.hs. If it doesn't exist, we move on to the next entry in the search path. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Libraries needing a main and ghci
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-no-hs-main behaviour
On Tue, Dec 10, 2002 at 10:35:22AM -, Simon Marlow wrote: 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. While on the subject of GHC's build options, can we change the behaviour of -no-hs-main when it's used with --make? Currently, if you use --make and GHC finds a main function, it will attempt to link all the modules together to produce an executable -- even if you specify -no-hs-main. 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? -- #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
-hidir separation of search/output paths
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 [EMAIL PROTECTED] - trust.in.love.to.save ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Options in hs files; Bug report?
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
---BeginMessage---
[...]
Talking about warnings, it is probably patently stupid to put
{-# OPTIONS -fglasgow-exts -package lang #-}
at the top of my Main.lhs. But why does GHC (5.04-1) fail to find any
of my imports as a consequence? Bug?
---End Message---
--
If I haven't seen further, it is by standing in the footprints of giants
Re: Proposals for changes to searching behaviour
The suggested changes sound hard to understand and to implement consistently in all compilers. I lean towards leaving the spec as it is. IIRC, the current Hugs semantics is a complex balancing act intended to achieve backward compatability and implement module paths at the same time. I'd prefer to see everyone switch over to the new way so that we can drop old features. -- Alastair Reid ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problems with main in a lib*.a. Is that a bug?
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposals for changes to searching behaviour
Hi Simon, CC Glasgow-Haskell-Users 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. As long as one uses automatic variables in all commands, it seems to work fine. Well, I have at least not had any trouble in that particular respect, for what that is worth. One application of VPATH is to select between different sources depending on the platform. Sure, there are alternatives, but VPATH can be quite convenient, and if used properly, the overall source structure is quite clear and tidy. For example, the current (unfortunate) standard practice for dealing with StdDIS for GreenCard, is to bundle it with every library application/libray which has some GreenCard sources. If you want your app/library to work with more than one Haskell system, you need one StdDIS for each. Alastair Reids Xlib is a good example. It roughly has this structure: src Haskell system independent Haskell GreenCard sources ghc StdDIS.gc -- StdDIS for GHC hugs StdDIS.gc -- StdDIS for Hugs Ignore that there in an ideal world should not be any reason to to bundle StdDIS with apps/libs: this is just an example of a source file that is different for different Haskell systems. AS long as Haskell systems provides different features, there is always going to be a need for this kind of arrangement. One could imagine wanting a heavily optimized version of one module for GHC (using unboxed whatever etc.), as well as plain Haskell 98 sources for other systems, for example. If there's a specific restriction in GHC that prevents the use of VPATH, could you describe what it is? No real restriction. But consider what will happen if we try to use the above scheme for some module A.B.C.M1 which is part of a module A.B.C. If I have to use a directory hierarchy, I'd find it natural to organize the sources like this: (A) src A B C.hs C ghc M1.hs hugs M1.hs But instead, it seems as if I have to do it like this: (B) src A B C.hs ghc A B C M1.hs hugs A B C M1.hs I'm sorry, but as far as I'm concerned, this really is a mess. As an aside and an example of how different tool conventions can interfere, suppose our sources are under CVS control, and that we want to move things around a bit. Renaming files is bad enough in CVS, but changing the actual source hirarchy is really painful. All I really want is (C) src C.hs ghc C.M1.hs hugs C.M1.hs or possibly, if prefixes can't be dropped: (D) src A.B.C.hs ghc A.B.C.M1.hs hugs A.B.C.M2.hs I don't think it is unreasonable to want to organize sources in fashion (C) or (D). I'm currently using (A) by way of a different (manually implemented) mechanism thnan VPATH. That took quite some time to get right though, and even though I'm happy with the mechanism since it is quite general, using VPATH would have saved me some time. Now, as it turns out, GreenCard does not seem to support hierarchical modules at this point, so in the case of Xlib, it seems as if it's going to be necessary to make StdDIS a top-level module, with some kind of prefix naming convention to avoid clashes with other StdDISs. I.e. something like: src Graphics X Haskell system independent Haskell GreenCard sources ghc Graphics_X_StdDIS.gc -- StdDIS for GHC hugs Graphics_X_StdDIS.gc -- StdDIS for Hugs Am I the only one who find this kind of source organization totally unorgaized? 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. In principle, yes. But there are of course issues if one still want to use tools like Make. Powerful mechanisms like implicit rules pretty much assumes fairly straight-forward mappings between names of generated files and source files. 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
Re: Proposals for changes to searching behaviour
Hi Alastair! The suggested changes sound hard to understand and to implement consistently in all compilers. I lean towards leaving the spec as it is. I think they're pretty straightforward, actually. Coudl you elaborate on why it seems complicated to you? As to implementation, I can't imagine that it would be that difficult to get something reasonably consistent. After all, different compilers/ interpreters have managed to handle a language like Haskell98 with extensions in a fairly consitent manner. IIRC, the current Hugs semantics is a complex balancing act intended to achieve backward compatability and implement module paths at the same time. I'd prefer to see everyone switch over to the new way so that we can drop old features. Which way is the old and which is the new? I've noticed that Hugs looks fore.g. a module A.B.C in both A/B/C.hs and A.B.C.hs, which seems nice to me and is part of what we suggested. The only extra addition would be to associate prefixes with directories in the search path. Is that really complicated? 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: ANNOUNCE: GHC version 5.04.2 released
Manuel M T Chakravarty [EMAIL PROTECTED] writes: RPMs built on Red Hat 8.0 are now available from ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.04.2-1.i386.rpm Thank you very much. Just found them on haskell.org too (they're in http://haskell.org/ghc/dist/5.04.2/RedHat8.0/). 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. Jens ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
