After waiting four hours for the libraries to compile on my woefully underpowered machine, I gave up and tried to use the libraries from: http://repetae.net/john/computer/jhc/libs/ I copied both files into my jhc dir, and then: stefan@stefans:/usr/local/src/jhc$ ./jhc -L. -flint -v test/HelloWorld.hs jhc -L. -flint -v test/HelloWorld.hs Compiling ["test/HelloWorld.hs"] Loading libraries: ["base","haskell98"] Loading library: "base-1.0" @ "./base-1.0.hl" Loading library ./base-1.0.hl failed due to missing dependencies stefan@stefans:/usr/local/src/jhc$ Also, augustss on #haskell said that he was unable to use jhc because "the precompiled libraries were incompatible with my jhc somehow". Is this a known problem? (not being able to use precompiled libs) Stefan
On Sun, Feb 04, 2007 at 04:45:05PM -0800, Stefan O'Rear wrote:
After waiting four hours for the libraries to compile on my woefully underpowered machine, I gave up and tried to use the libraries from:
http://repetae.net/john/computer/jhc/libs/
I copied both files into my jhc dir, and then:
stefan@stefans:/usr/local/src/jhc$ ./jhc -L. -flint -v test/HelloWorld.hs jhc -L. -flint -v test/HelloWorld.hs Compiling ["test/HelloWorld.hs"] Loading libraries: ["base","haskell98"] Loading library: "base-1.0" @ "./base-1.0.hl" Loading library ./base-1.0.hl failed due to missing dependencies stefan@stefans:/usr/local/src/jhc$
Also, augustss on #haskell said that he was unable to use jhc because "the precompiled libraries were incompatible with my jhc somehow".
Is this a known problem? (not being able to use precompiled libs)
In general, I try to keep the libraries compatable with the last 'tagged' version of the repository, if that is not the case, then I need to fix it. It very well might be broken at the moment, as I recently switched to using the new Data.Binary serialization library and using zlib for compression, so in any case, rather than using the libraries, you can compile with --noauto -Llib/base -Llib/haskell98 to use the source files for the library directly. this is generally recommended for development of jhc anyway. I'll update the libraries on the site in any case. The use of the new Data.Binary has been great, some of the repurcusions of the change havn't quite settled yet. John -- John Meacham - ⑆repetae.net⑆john⑈
On Sun, Feb 04, 2007 at 08:12:28PM -0800, John Meacham wrote:
In general, I try to keep the libraries compatable with the last 'tagged' version of the repository, if that is not the case, then I need to fix it. It very well might be broken at the moment, as I recently switched to using the new Data.Binary serialization library and using zlib for compression, so
Nice to know. I didn't get that impression from the libraries page - it might be a good idea to add a note "the libraries are intended for use with the latest tag".
in any case, rather than using the libraries, you can compile with
--noauto -Llib/base -Llib/haskell98 to use the source files for the library directly. this is generally recommended for development of jhc anyway.
That doesn't seem to work. stefan@stefans:/usr/local/src/jhc$ ./jhc --noauto -Llib/base -Llib/haskell98 -flint -v test/HelloWorld.hs jhc --noauto -Llib/base -Llib/haskell98 -flint -v test/HelloWorld.hs Compiling ["test/HelloWorld.hs"] Loading libraries: [] Found dependency: test/HelloWorld.hs at test/HelloWorld.hs Error: Module not found: Jhc.Prim stefan@stefans:/usr/local/src/jhc$ Adding -Llib/jhc does not help, nor does find . -name *.ho -delete. I suppose I should also mention that when I ^C'd and restarted the library build (to change RTS options - turns out I don't have enough RAM to build the libraries without +RTS -c, and even with it's a tight squeeze), Jhc found existing .ho files, skipped most of the messages, ground for a few minutes, and bombed out with a Handle-misuse related error (which I unfortunately cannot remember). Is this another known infelicity? Thanks for the attention. Stefan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan O'Rear wrote:
(to change RTS options - turns out I don't have enough RAM to build the libraries without +RTS -c, and even with it's a tight squeeze)
How much RAM is this amount that worked as a "tight squeeze" for you? That is, I'd like some numbers for how much memory jhc needs (One time I tried this and didn't have enough memory on my current computer; I don't remember if I knew to try +RTS -c) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFyjYBHgcxvIWYTTURAuklAJwJ84Vk13zO5punZGhCIH1z6cy4kwCgh8Lw XVZh90lk65I86guEplJyKQ0= =et1v -----END PGP SIGNATURE-----
On Wed, Feb 07, 2007 at 03:26:42PM -0500, Isaac Dupree wrote:
Stefan O'Rear wrote:
(to change RTS options - turns out I don't have enough RAM to build the libraries without +RTS -c, and even with it's a tight squeeze)
How much RAM is this amount that worked as a "tight squeeze" for you? That is, I'd like some numbers for how much memory jhc needs (One time I tried this and didn't have enough memory on my current computer; I don't remember if I knew to try +RTS -c)
384 MB. by which I mean Jhc stayed above 5% cpu the whole time. (Jhc's VIRT stayed around 495MB). also my limited patience has prevented me from seeing the whole-program optimization phase ... Jhc is unusably (read: untestably if/when I break something) slow on my obsolete computer. My first hacking target will be some kind of -fsymbol-at-a-time use less ram option :) Stefan
On Wed, Feb 07, 2007 at 03:35:50PM -0800, Stefan O'Rear wrote:
On Wed, Feb 07, 2007 at 03:26:42PM -0500, Isaac Dupree wrote:
Stefan O'Rear wrote:
(to change RTS options - turns out I don't have enough RAM to build the libraries without +RTS -c, and even with it's a tight squeeze)
How much RAM is this amount that worked as a "tight squeeze" for you? That is, I'd like some numbers for how much memory jhc needs (One time I tried this and didn't have enough memory on my current computer; I don't remember if I knew to try +RTS -c)
384 MB.
by which I mean Jhc stayed above 5% cpu the whole time. (Jhc's VIRT stayed around 495MB).
also my limited patience has prevented me from seeing the whole-program optimization phase ...
Jhc is unusably (read: untestably if/when I break something) slow on my obsolete computer. My first hacking target will be some kind of -fsymbol-at-a-time use less ram option :)
once the libraries are built, then things go much smoother. I have basically done very little work on optimizing jhc's memory usage other than not doing anything blatently silly (I hope). There is most likely a lot of room for improvement and probably some low-hanging fruit that can be done easily with a little profiling. There are also some obvious things that could be done, like storing the dependency graph in the binary file, so I need not go through everything and calculate free variables again on loading, or having a separate section that doesn't need to be loaded for functions that we know are so big they will never be inlined. coming up with a unified annotation to store strictness,cpr, and eta information and serializing it rather than recalculating it would also be a big win. (I am working on this actually) John -- John Meacham - ⑆repetae.net⑆john⑈
On Thu, Feb 08, 2007 at 04:28:42PM -0800, John Meacham wrote:
once the libraries are built, then things go much smoother. I have basically done very little work on optimizing jhc's memory usage other than not doing anything blatently silly (I hope). There is most likely a lot of room for improvement and probably some low-hanging fruit that can be done easily with a little profiling.
Nice to know. I look forward to seeing the new prebuilt libs (unpulling to each tag after early Dec failed to find a jhc that accepts the current ones :( ) Thanks for all the information. Stefan
On Sun, Feb 04, 2007 at 08:35:23PM -0800, Stefan O'Rear wrote:
On Sun, Feb 04, 2007 at 08:12:28PM -0800, John Meacham wrote:
In general, I try to keep the libraries compatable with the last 'tagged' version of the repository, if that is not the case, then I need to fix it. It very well might be broken at the moment, as I recently switched to using the new Data.Binary serialization library and using zlib for compression, so
Nice to know. I didn't get that impression from the libraries page - it might be a good idea to add a note "the libraries are intended for use with the latest tag".
in general, it isn't an issue unless I am actively changing the library format. I am in the progress of migrating to the new Data.Binary so have been modifying the format.
stefan@stefans:/usr/local/src/jhc$ ./jhc --noauto -Llib/base -Llib/haskell98 -flint -v test/HelloWorld.hs jhc --noauto -Llib/base -Llib/haskell98 -flint -v test/HelloWorld.hs Compiling ["test/HelloWorld.hs"] Loading libraries: [] Found dependency: test/HelloWorld.hs at test/HelloWorld.hs Error: Module not found: Jhc.Prim stefan@stefans:/usr/local/src/jhc$
Adding -Llib/jhc does not help, nor does find . -name *.ho -delete.
oh. silly me I meant --noauto -ilib/base -ilib/haskell98 sorry about that.
I suppose I should also mention that when I ^C'd and restarted the library build (to change RTS options - turns out I don't have enough RAM to build the libraries without +RTS -c, and even with it's a tight squeeze), Jhc found existing .ho files, skipped most of the messages, ground for a few minutes, and bombed out with a Handle-misuse related error (which I unfortunately cannot remember).
Yeah, the handle misuse error is an annoying bug where ghc will close the stdout handle before the exception handler has a chance to say what went wrong.
Is this another known infelicity?
Could be. I'll investigate. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (3)
-
Isaac Dupree -
John Meacham -
Stefan O'Rear