GHC Crosscompile
Hi everybody: I would like to compile Haskell programs to run on Alpha architecture. As the target architecture is going to be simulated, I can't install GHC on an Alpha machine (because I don't have one). As most of you, I have got GHC installed and running on x86. Is there any way to cross-compile and generate Alpha code with my x86 compiler? Hope you can help me. Regards Cristian Perfumo ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RTS/Garbage Collector idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's often bothered me that there is unneeded duplication in the heap, if you do something the compiler doesn't manage to optimize like f [a,b,c,d] = Foo bar [a,b,c,d] or (reverse . reverse) or using () or Int(eger) or ... or Bool boxes in multiple places in your program that have the same value. A referentially transparent difference in your program could be the difference between constant memory usage and a memory leak (I think -- although this proposal/idea will not tie the knot for you or deal well with cyclic data structures at all, in fact). I was thinking, since we have a copying garbage collector that reassigns all pointers anyway, could we detect the identical heap objects and for each set of identical ones, have all thunks that pointed to any of them, now point to the single one that is created in the target space? This might not have much effect. (and seems likely to be slow and possibly have a complex interaction with parallel and/or incremental GC...) Maybe it should not be done on _every_ garbage collection. First to implement/try might be just detecting those duplicates so we have some idea how much effect such an optimization would even have. (any idea how easy/possible that is (or just what the answer is;)?) Examples: evaluated (543::Int) somewhere ends up pointing to the same (543# :: Int#) in the heap as another (543::Int) somewhere does. 8:8:2:3:[] 9:9:2:3:[] The []s become shared, then the 3:[]s, then the 2:3:[]s, ending 8:8:x 9:9:x where x is 2:3:[] 8:8:2:3:(*) 9:9:2:3:(*) where (*) is the *same* object, maybe an unevaluated thunk, maybe some list. After (*)'s creation, two different parts of code decided to construct their own lists with that as their tail. Eventually becomes: 8:8:x 9:9:x where x is 2:3:(*) Two thunks that merely have the same code shouldn't be combined because it could be the [1..] [1..] sharing memory-leak to the extreme! It would seem safe to combine thunks that only produce something small like an Int, but they can actually produce a complex Exception - so, no combining of thunks. (also... must be careful in this area of breaking the IO monad-sequencing(maybe?), but I think it's quite safe as long as only already-evaluated heap objects are combined) I wonder how this interacts with polymorphic (list-nil of different types), or with merely structurally equivalent, data (if they're identical, merging shouldn't ever be a problem! at least as long as no-one relies on something like if (unsafe pointer equality) then (same static type)...) Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdmJaHgcxvIWYTTURAjAhAJ9WHwzxuJPuqouol05K7+QHkT3IigCglOpw VtHCSxcy8E+w7OtCafU8pFM= =BqAi -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
cyclic import bug in 6.6.1
Dear GHC developers, I an half-stuck now due to the ghc-6.6.1 bug of `undefined reference' at the stage of linking the executable. I am almost sure that this is due to cyclic import. There already was cyclic import, and the whole program worked correct. Now, I have split one large module into two modules, and there appeared more cyclic imports. Now, it `makes' the package and does `install', but cannot link the executable for `main'. There are about 30 modules in the project, and 4-5 of them form a cycle by import. Please, whom I need to send the source archive to ? I can reduce this bug report project many times, but I suspect that in this particular case you can easily spot the place in the project as it is. Can you ? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RTS/Garbage Collector idea
Isaac Dupree wrote: I was thinking, since we have a copying garbage collector that reassigns all pointers anyway, could we detect the identical heap objects and for each set of identical ones, have all thunks that pointed to any of them, now point to the single one that is created in the target space? I think what you're proposing is often called hash consing, except that hash-consing is usually done at construction time, you want to do it at GC time. My take is it would only be worthwhile if there was a *lot* of sharing to be gained by doing it, and in most cases there wouldn't be. This is just a guess based on my experience poking around in the heap though - feel free to try it out and prove me wrong :-) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Crosscompile
Cristian Perfumo wrote: Hi everybody: I would like to compile Haskell programs to run on Alpha architecture. As the target architecture is going to be simulated, I can't install GHC on an Alpha machine (because I don't have one). As most of you, I have got GHC installed and running on x86. Is there any way to cross-compile and generate Alpha code with my x86 compiler? At the moment, no. You can build a compiler that will generate .hc files that can be compiled on the target; this is how we do bootstrapping on a new architecture, but it's not the same as cross-compiling all the way to an executable. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RTS/Garbage Collector idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Marlow wrote: I think what you're proposing is often called hash consing, except that hash-consing is usually done at construction time, you want to do it at GC time. My take is it would only be worthwhile if there was a *lot* of sharing to be gained by doing it, and in most cases there wouldn't be. Sounds likely. I wonder if there's a theoretical limit on the amount of memory wasted by not doing this (maybe some function of the amount of memory needed after such compaction?) This is just a guess based on my experience poking around in the heap though - feel free to try it out and prove me wrong :-) if I feel like it, which seems a bit unlikely - might be useful as a last-ditch garbage collection technique, but the process probably needs nontrivial amount of memory itself so maybe not :-) Issac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdowTHgcxvIWYTTURApAWAKCUmB/HR+NzRMMjqpIie2r79gojlACfQ0Wm ei5l3/1JvNphTeUMV5Wg2uI= =u8/0 -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Locating shared libraries
skaller wrote: On Fri, 2007-06-15 at 19:40 -0500, Spencer Janssen wrote: On Sat, 16 Jun 2007 08:21:50 +1000 skaller [EMAIL PROTECTED] wrote: One way to measure this is: if you removed GHC and applications, and there are (necessarily) no users of the remaining library package .. the library package shouldn't be in the global public place (/usr/lib+include etc). As I understand it, the entire point of this effort (shared libraries in GHC) is to allow dynamically linked Haskell executables. In this case, applications outside the GHC toolchain will in fact depend on these shared objects. As a concrete case, a binary darcs package could be a user of libghc66-base.so and libghc66-mtl.so -- with no dependencies on the GHC compiler package itself. Does this pass your litmus test? Yes, it passes the separability test. My darcs wouldn't run otherwise! And versioning the library filename as above is a good idea too. Felix adds _dynamic for shared libs and _static for static link archives to ensure the Linux linker doesn't get confused. However, the libs still aren't fully public if the interfaces are only private details of the GHC tool chain. Hmmm. Under the current system, darcs is linked statically so it is a self- contained executable. Under the proposed shared-library system versioning the shared libraries may pose a very big problem and I don't think it would pass your litmus test. As I mentioned previously, GHC is a fast-moving target and there are quite a few GHC- Haskell-based applications available that rely on different versions of the compiler. Here is an example: There are any number of GHC-Haskell-based programs, all built with different versions of GHC; GHC itself relies on some of these to build, such as Happy and Alex. (There are .rpm packages for Alex.) You already talked about the situation from there: several different programs relying on different versions of the shared libraries, located in /usr/local/lib--and they don't rely on just one library. As is, the GHC runtime system has more than a few base libraries, the minimum set of which is: HSrts HSbase HSbase_cbits With dynamically linked libraries on OS X, the convention was to have add the suffix _dyn, so we had: HSrts_dyn, HSbase_dyn and HSbase_cbits_dyn Now each GHC-Haskell-based program installer would search /usr/local/ lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall? The same thing you get on Windows when you have another program using a particular .DLL--the uninstall of that version of the library would fail but for unix systems _only_ if you also have another program using at while you are doing the uninstall. So if you did not break everything on each install, eventually you have a complete mess of different versions of GHC libraries in /usr/local/lib that may have no current use but at one time were used for several GHC-Haskell-based programs that have now been upgraded to use something different. Hopefully those who distributed the binary programs adopted a convention of using the full version of the library instead of symlinking libHSrts_dyn-6.6.1 to libHSrts_dyn, or as a user several of your older programs might break after a later one installed a new version of the library and symlinked that the new version... That is why I think your idea was good: put everything into distinct directories. Cheers, Pete ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Locating shared libraries
On Mon, Jun 18, 2007 at 11:56:57AM -0400, Peter Tanski wrote: Now each GHC-Haskell-based program installer would search /usr/local/ lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall? The same thing you get on Windows when you have another program using a particular .DLL--the uninstall of that version of the library would fail but for unix systems _only_ if you also have another program using at while you are doing the uninstall. So if you did not break everything on each install, eventually you have a complete mess of different versions of GHC libraries in /usr/local/lib that may have no current use but at one time were used for several GHC-Haskell-based programs that have now been upgraded to use something different. Hopefully those who distributed the binary programs adopted a convention of using the full version of the library instead of symlinking libHSrts_dyn-6.6.1 to libHSrts_dyn, or as a user several of your older programs might break after a later one installed a new version of the library and symlinked that the new version... That is why I think your idea was good: put everything into distinct directories. Debian's high level package manager will automatically garbage collect dependancies, such that every package on your system is either manually selected for install or a dependant of one. Thus there is no library leak problem. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Locating shared libraries
On Jun 18, 2007, at 6:06 PM, Stefan O'Rear wrote: On Mon, Jun 18, 2007 at 11:56:57AM -0400, Peter Tanski wrote: Now each GHC-Haskell-based program installer would search /usr/local/ lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall? ... That is why I think your idea was good: put everything into distinct directories. Debian's high level package manager will automatically garbage collect dependancies, such that every package on your system is either manually selected for install or a dependant of one. Thus there is no library leak problem. The Debian package system (I assume you are referring to apt, or maybe dpkg?) is very convenient (and relatively quick!). I don't know how well the BSD-style package systems garbage collect but I have not had any problems using port or fink--though sometimes they pull more dependancies than they need because installed programs outside their system are (wisely) not considered. Since my best machine is a Mac (PowerBook G4, 1.25GHz) the lost libraries become a problem as soon as I work independently of a package system. I expect the same would be true for anyone working independently. Some individual languages have their own package systems, such as Lisp's asdf; OCaml has GODI. Haskell is moving in that direction with Cabal but it is still more of a build system than anything else and in any case it would probably be better to keep with the system packaging setup, such as Debian's, for program distribution. That way GHC libraries may reside comfortably in the standard system directories but I am still a little querulous. I would rather all haskell libraries use the standard (OS X) DYLD_LIBRARY_PATH, though DYLD_FALLBACK_LIBRARY_PATH (putting things in $(home)/lib) might help for the haskell-universe. That may be the solution for programs, though it requires more work: Haskell would need packaging. On a related note, if anyone is interested, once we get an idea of where we want to put things I can modify the installer script to create an OS X pkg (using PackageMaker) for GHC binary distributions. At least that would make removal easier (using Desinstaller). The old 6.4.1 OS X application install was slick; I might redo that. Cheers, Pete ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Crosscompile
how portable are the .hc files? do they depend on some library that needs to be built for the target? Would they generate read only position independent object code (no writable global variables)? Thanks, Anatoly On 6/18/07, Simon Marlow [EMAIL PROTECTED] wrote: Cristian Perfumo wrote: Hi everybody: I would like to compile Haskell programs to run on Alpha architecture. As the target architecture is going to be simulated, I can't install GHC on an Alpha machine (because I don't have one). As most of you, I have got GHC installed and running on x86. Is there any way to cross-compile and generate Alpha code with my x86 compiler? At the moment, no. You can build a compiler that will generate .hc files that can be compiled on the target; this is how we do bootstrapping on a new architecture, but it's not the same as cross-compiling all the way to an executable. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Crosscompile
On Mon, Jun 18, 2007 at 05:49:29PM -0700, Anatoly Yakovenko wrote: how portable are the .hc files? do they depend on some library that needs to be built for the target? Would they generate read only position independent object code (no writable global variables)? Thanks, Anatoly You're probably better off just installing GHC/Alpha. (You do have a simulator!) It won't take as long as getting hc to work :) Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
