On Mon, Dec 3, 2012 at 9:17 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > > I have tried the install-plain make target and it is indeed much > > smaller, but it compiles/installs very little -- no raco, and > > apparently very little byte-compiling, because the racket REPL takes > > an age to load -- so it's basically unworkable. > > > > Is there a reasonable in-between option? > > Not yet. We are working on a new package system, and we expect that > things currently in the distribution will gradually migrate out as > packages. More generally, we expect that it will be easier to have an > in-between point as we more carefully sort out dependencies.
Very neat. I have thought about just resolving dependencies at compile-time when the user pushes the racket application, but I think having the REPL available in the remote environment is really handy, so I want to have a usable but fairly stripped down racket install available. > > In particular, I'm thinking about crawling through the submitted > > racket source and finding all (require) forms as to evaluate them > > up-front at submission time: because running programs do not have a > > persistant file system, not doing this would result in every freshly > > started program downloading from PLaneT over and over, and, if PLaneT > > were to go down, no non-trivial racket program could start up > > successfully. > > The `raco exe' tool does this sort of thing, and its > `write-module-bundle' function may be what you want. > > The `raco demod' tool is even more aggressive --- it flattens a module > graph into one module --- but it doesn't seem to have a documented API. Does raco pkg install also do this (this is why I started looking again)? I've thought to make the contract with the build-pack user to have a valid PLaneT directory/file structure. The general way this works is that when code is pushed via Git that some programs run to validate the push and then a compile step pulls in dependencies and emits artifacts. Of moderate relation: I'm also having some issues with the compiler being incredibly slow and memory consuming. Part of that can be solved by doing less (per the subject of this thread), but I'm a little bit concerned about the 2GB of RES pages that are consumed by a raco setup run as well as its voracious use of CPU time. Again, some of these problems can be blunted quite a bit by doing less, so it's probably not strictly a blocker, just a little bit irksome. -- fdr ____________________ Racket Users list: http://lists.racket-lang.org/users
