Re: [racket-dev] Parallel Build of Collects

2010-07-02 Thread Robby Findler
I'm getting this: [ro...@penghu] ~/git/plt/collects$ raco setup -u /Users/robby/git/exp/plt/bin/raco setup: unknown switch: -u Robby On Fri, Jul 2, 2010 at 3:44 PM, Kevin Tew wrote: > raco setup -u will build collects in parallel, using all the cores your > machine has. > rack setup -u -j X ie

Re: [racket-dev] Parallel Build of Collects

2010-07-02 Thread Matthew Flatt
I suggested that Kevin let others try parallel mode for a day or two before making it the default. At Fri, 2 Jul 2010 19:38:55 -0500, Robby Findler wrote: > That sounds right to me too. > > Robby > > On Fri, Jul 2, 2010 at 4:47 PM, Matthias Felleisen > wrote: > > > > Why don't you use make par

Re: [racket-dev] Parallel Build of Collects

2010-07-02 Thread Robby Findler
That sounds right to me too. Robby On Fri, Jul 2, 2010 at 4:47 PM, Matthias Felleisen wrote: > > Why don't you use make parallel setup the standard? > > > > On Jul 2, 2010, at 4:44 PM, Kevin Tew wrote: > >> raco setup -u will build collects in parallel, using all the cores your >> machine has.

Re: [racket-dev] Parallel Build of Collects

2010-07-02 Thread Robby Findler
Great! Robby On Fri, Jul 2, 2010 at 3:44 PM, Kevin Tew wrote: > raco setup -u will build collects in parallel, using all the cores your > machine has. > rack setup -u -j X ie (-j 2) can be used to throttle parallel build to only > use X cores. > > Parallel build is currently done by spawning wor

Re: [racket-dev] Parallel Build of Collects

2010-07-02 Thread Matthias Felleisen
Why don't you use make parallel setup the standard? On Jul 2, 2010, at 4:44 PM, Kevin Tew wrote: > raco setup -u will build collects in parallel, using all the cores your > machine has. > rack setup -u -j X ie (-j 2) can be used to throttle parallel build to only > use X cores. > > Paralle

[racket-dev] Parallel Build of Collects

2010-07-02 Thread Kevin Tew
raco setup -u will build collects in parallel, using all the cores your machine has. rack setup -u -j X ie (-j 2) can be used to throttle parallel build to only use X cores. Parallel build is currently done by spawning worker processes and communicating over pipes. Building scribble documentat

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Ryan Culpepper
On 07/02/2010 11:50 AM, Eli Barzilay wrote: > On Jul 2, Matthias Felleisen wrote: > > [...] >> I think this really gets at the questions, >> >> what is the purpose of a collect? >> >> Even if we ignore the distribution idea, it should concern us that >> we don't have a concise answer for that

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Matthias Felleisen
On Jul 2, 2010, at 1:50 PM, Eli Barzilay wrote: > In both of these cases, > I think that the *proper* way to tackle the changes is to move code > between packages (even if it keeps the same owner) -- *not* to create > the connections and leave the code where it is. This is good software engineer

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Eli Barzilay
On Jul 2, Matthias Felleisen wrote: > 1. Size matters even if it doesn't really matter. Seeing these >numbers makes it clear that our download will be called a >behemoth and an ms style colossus. We all know that in the end, >this number is irrelevant. PLT comes with a lot of extra stu

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Stephen De Gabrielle
On the abundance of riches; On Friday, July 2, 2010, Matthias Felleisen wrote: > > 1. Size matters even if it doesn't really matter. Seeing these numbers makes > it clear that our download will be called a behemoth and an ms style > colossus. We all know that in the end, this number is irreleva

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Matthias Felleisen
1. Size matters even if it doesn't really matter. Seeing these numbers makes it clear that our download will be called a behemoth and an ms style colossus. We all know that in the end, this number is irrelevant. PLT comes with a lot of extra stuff and that stuff is useful. But among the hacker

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Eli Barzilay
On Jul 2, Robby Findler wrote: > > Did you forget java and gcc? Here's a few more: winooski:~ eli> rpm -q --queryformat '%{SIZE} %{NAME}\n' tcl perl ghc js python ruby lua plt-scheme gcc-java gcc kawa guile bigloo | sort -n 595769 lua 962834 js 1441553 ghc 1679403 ruby 3318547 guile 3669827 t

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Robby Findler
On Fri, Jul 2, 2010 at 9:22 AM, Eli Barzilay wrote: > On Jul  2, Robby Findler wrote: >> Those numbers seem pretty small in today's disk sizes, > > Obviously -- but the issue is not diskspace. > > And Jay McCarthy wrote: >> I feel like I routinely download programs and dev environments where >> th

[racket-dev] git.racket-lang.org

2010-07-02 Thread Eli Barzilay
The git.racket-lang.org pages are also recketified now. Hopefully there are no width problems with it now. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Eli Barzilay
On Jul 2, Robby Findler wrote: > Those numbers seem pretty small in today's disk sizes, Obviously -- but the issue is not diskspace. And Jay McCarthy wrote: > I feel like I routinely download programs and dev environments where > the distribution is over 100MBs. winooski:~/mail eli> rpm -q --

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Jay McCarthy
On Fri, Jul 2, 2010 at 5:17 AM, Robby Findler wrote: > Those numbers seem pretty small in today's disk sizes, but I do agree > that there is value in being able to divide up the distribution and to > be able to stratify things so we can better keep track of our > dependencies. I feel like I routi

Re: [racket-dev] proposal: `data' collection

2010-07-02 Thread Robby Findler
Those numbers seem pretty small in today's disk sizes, but I do agree that there is value in being able to divide up the distribution and to be able to stratify things so we can better keep track of our dependencies. (BTW, just a random question: have you thought about trying to visualize the colle