[racket-dev] proposal: `data' collection

> 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 <eli at 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.degabrielle at acm.org
Telephone +44 (0)20 85670911
Mobile        +44 (0)79 85189045
http://www.degabrielle.name/stephen