[plt-scheme] collection not found error at startup

On Jun 27, Ari Pollak wrote:
> On Fri, Jun 27, 2008 at 8:29 AM, Eli Barzilay <eli at barzilay.org> wrote:
> > * The problem seems to be that the debian package does its own
> >   division of the directories into what goes into the mzscheme
> >   package and what goes into the drscheme package.  We have a
> >   script that does that job and verifies that no dependencies are
> >   broken.  Another solution is to have a single plt-scheme
> >   distribution.
> 
> As far as I know, that script isn't public.

Not for any secrecy reasons -- it's just tied enough to our build
process that you won't be able to just run it.  I suggested in the
past to put the file lists somewhere, or just send them from time to
time.

But it's not a good idea either way.  I'm assuming that you start with
some source tarball -- so why not have the plt-scheme package and the
mzscheme package start from the sources that we provide for both of
these?


> > * IMPORTANT: the build should not use cgc -- it should use the default
> >   3m.  The cgc version of mzscheme can suffer from potential memory
> >   leaks, and this is especially important with long-running
> >   processes like a web-server (and my guess is that the mzscheme
> >   package is particularly popular for running servers).
> 
> Except that 3m doesn't build on architectures other than i386 and
> amd64 (and maybe powerpc),

I'm not aware of any compilation problems on other platforms, so I
find it unlikely that *no* platforms except for these two work.  If
you look at our builds, you'll see that it works on several others
(like an intel x86_64, and sparc-solaris), and there are also some
architectures that we don't have a machine to run builds on but I know
that things work fine (it even built fine on an ARM machine).


> so anyone running a server on another architecture is still going to
> have to use cgc. Special-casing the architectures that do happen to
> build with 3m is not something I really want to deal with.

The special casing should be done for architectures that don't build
with 3m, since there shouldn't be many of these (and like I said,
there shouldn't be any at all).  In any case, it's a *VERY* bad idea
to switch the build to cgc, like I said earlier.

* There are several known problems with using CGC, especially with
  servers and other long-running processes

* It's making drscheme (and other programs) perform worse since the 3m
  collector is faster

* There are features that are just not available for cgc, like
  drscheme's memory limits

* Finally, nobody else uses it, so you're making it is more possible
  that there will be a bug that we won't be able to catch because it
  involves the way the cgc works.

(Note: that "very" was intentionally starred and capitalized, and this
comment references it again.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!