On Fri, 2008-05-16 at 17:27 -0400, Ryan Newton wrote: > I've got a large R6RS project. I'm having problems with compile- > stale and also with trying to build my libraries incrementally using > explicit dependencies represented in a makefile. (I can elaborate on > that if anyone is curious.)
FWIW, I currently have 77 *.sls files comprising ~22500 LOC on a 64 bit AMD, Linux Fedora I am using -flat1 when building Larceny itself. My current "main" program loads 86 files, 56 files in my rl3 namespace, the rest in rnrs and err5rs. At this moment ~5 files and < 1000 lines of code are not pre-compiled. All files load in err5rs mode in < 5 secs. Adding -stopcopy appears to slow the load down slightly, maybe taking a sec or two longer. I haven't tried creating a heap because of extensive FFI use in the code and I've been assuming (maybe erroneously that there is an outstanding bug regarding heaps with FFI). I have experienced some compile-stale-library fragility as well. Once I noticed compile-stale-library was compiling rnrs files in the Larceny R6Rs library directory. Somehow I'd touched a file in there. After doing a larceny:compile-r6rs-runtime that issue cleared up a lot of problems cleared up. When necessary I do a rm $(find rl3 -name "*.slfasl") when I see "Client was expanded against a different build of this library" and do a fresh compile-stale-libraries which successfully completes. This fresh compile via compile-stale-libraries takes 3 mins 15 secs on a 2 GHZ machine. Regarding R6RS bloat. I rigorously use (only (...) ...) on R6RS library imports. Don't know if this makes a difference however. One bug/issue in compile-stale-libraries is if emacs leaves a #myfile.sls# dropping file. I don't recall exactly the error but the stale library compile blows up if one of those files exists. _______________________________________________ Larceny-users mailing list [email protected] https://lists.ccs.neu.edu/bin/listinfo/larceny-users
