[plt-scheme] collection not found error at startup

Putting what Eli is trying to say another way: we support CGC, but
only in order to actually build 3m and if some poor desperate soul
needs it for some specialized, likely very technical reason. If some
non-trivial slice of our users were using CGC when 3m was available,
it really would not be right for them to think they're using a
complete version of PLT Scheme.

Robby

On Sun, Jun 29, 2008 at 6:29 PM, Eli Barzilay <eli at barzilay.org> wrote:
> 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!
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>