[racket-dev] A grab-bag of issues

At Fri, 5 Jul 2013 10:58:39 -0500, Robby Findler wrote:
> On Thu, Jul 4, 2013 at 12:05 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 
> > At Thu, 4 Jul 2013 12:52:10 -0400, Sam Tobin-Hochstadt wrote:
> > > All of these are about packages/the new repository organization.
> > >
> > > 0. I think we should have a new `#lang info` for info.rkt files --
> > > `setup/infotab` seems pretty arbitrary.   I'll do this if no one
> > > objects.
> >
> > That sounds fine to me.
> >
> > > 1. Builds treat too much as core. Specifically, `raco setup`
> > > pre-builds some things single threaded, but too many:
> >
> > Yes. This is probably not too difficult to fix, but I haven't gotten to
> > it.
> >  <http://lists.racket-lang.org/dev>
> >
> 
> I had a quick look at this: the relevant code is these two lines (885 and
> 886 in setup-unit.rkt):
> 
>           (for/fold ([gcs 0]) ([cc (in-list (collection->ccs (list
> (string->path "racket"))))])
>             (compile-cc cc 0)))
> 
>  I'm not sure of the right fix tho. I think we can either
> 
> a) do nothing (since it causes no harm and you won't see this problem
> unless you are in a slightly strange situation of running the top-level
> makefile but already having the pkg links setup (I think))
> 
> b) delete these two lines (since I think they are there only to make the
> parallel performance better, but that can be made better by just making
> 'racket' collections go first in parallel mode (I think))
> 
> c) try to filter our non-collection-path 'racket's, something like this:
> 
>           (define (path-is-inside? candidate-parent candidate-child)
>             (not (equal? (find-relative-path candidate-parent
> candidate-child)
>                          candidate-child)))
>           (for/fold ([gcs 0]) ([cc (in-list (collection->ccs (list
> (string->path "racket"))))])
>             (when (for/or ([cp (current-library-collections-paths)])
> (path-inside? cp (cc-name)))
>               (compile-cc cc 0)))
> 
> I guess b) is best, but I thought I'd check.

I think option (b) performed significantly worse back when Kevin tried
it, but it's possible that things have changed. Did you try it, yet?

I was going to aim for something like option (c), but hopefully with a
simpler implementation.