[racket] Goldilocks: install too big, install-plain too slow

On Mon, Dec 3, 2012 at 9:17 AM, Matthew Flatt <mflatt at 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