> 1. collect evidence that size matters to anyone out there besides you
I'm happy to be a datapoint
Size matters to me for three reasons;
- startup time is significantly slowed on my (early 2010) MacBook pro
given all the packages :
- I disable all but the minimum to run on my ASus 701 4g which sold to
a few schools in Australia and the uk - I know schools outreach is a
part of your teachscheme mission, but don't know if netbooks are in
the us schools
The extra tools seem to significantly add to build-from-source time on
the default settings.
(I know it can be disabled, but I wonder if any potential developers
get turned off)
S.
On Thursday, July 8, 2010, Eli Barzilay <e...@barzilay.org> wrote:
> On Jul 8, Matthias Felleisen wrote:
>> This sounds like we should give up on stratification.
>
> That was my first thought when I saw that mess: give up also on
> distributing smaller packages, and dump the current distributions that
> are used as sanity checks. (Given that I usually end up in long
> threads that are a result of breaking these dependencies, I'd
> certainly like that.)
>
> But I still think that giving up on any organization will only make
> things worse, and I don't want that to happen.
>
>
>> On Jul 7, 2010, at 5:21 PM, Eli Barzilay wrote:
>>
>> > On Jul 6, Petey Aldous wrote:
>> >> That would be interesting and it would not be terribly difficult to
>> >> instrument setup-plt to do it.
>> >
>> > There's no reason to do that -- the data is all there in the dep
>> > files. It just needs to be trimmed for the collection name instead of
>> > the full paths.
>> >
>> > I'm attaching a file with a list of all toplevel collections and a has
>> > table that maps collection names to what they depend on. I tried to
>> > visualize this with graphviz in a number of ways -- and there was
>> > nothing that producing a graph that would make sense. I then wrote
>> > some code and there's two groups of collections -- one huge ball of
>> > code that is all inter-dependent, and then a bunch of collections that
>> > are nearly free of dependency problems. The only problem in the
>> > latter group is teachpacks and deinprogramm which form a cycle.
>> >
>> > So, the unproblematic set of collects is:
>> >
>> > 2htdp, afm, algol60, combinator-parser, datalog, defaults,
>> > embedded-gui, eopl, frtime, gui-debugger, guibuilder, handin-client,
>> > handin-server, hierlist, honu, lazy, macro-debugger, make, mysterx,
>> > mzcom, plai, plot, preprocessor, racklog, redex, repo-time-stamp,
>> > schemeunit, sgl, sirmail, slatex, srpersist, swindle,
>> > test-box-recovery, tex2page, waterworld, games, tests, meta
>> >
>> > it would work fine to install them one by one in this order, except
>> > for {teachpack, deinprogramm} which are their own set.
>> >
>> > The problematic set of collects is:
>> >
>> > racket, at-exp, browser, compiler, config, drracket, drscheme,
>> > dynext, errortrace, ffi, file, framework, graphics, help, htdp,
>> > html, icons, lang, launcher, mred, mrlib, mzlib, mzscheme, net,
>> > openssl, parser-tools, planet, profile, r5rs, r6rs, rackunit, raco,
>> > reader, readline, rnrs, s-exp, scheme, scribble, scribblings,
>> > scriblib, setup, slideshow, srfi, stepper, string-constants, syntax,
>> > syntax-color, test-engine, texpict, trace, typed, typed-scheme,
>> > unstable, version, web-server, wxme, xml
>> >
>> > <deps.rktd>
>
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://barzilay.org/ Maze is Life!
> _________________________________________________
> For list-related administrative tasks:
> http://lists.racket-lang.org/listinfo/dev
>
--
--
Stephen De Gabrielle
stephen.degabrie...@acm.org
Telephone +44 (0)20 85670911
Mobile +44 (0)79 85189045
http://www.degabrielle.name/stephen
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
