At Mon, 1 Jun 2009 08:58:46 -0500, Robby Findler wrote:
I think PLaneT does indeed work that way. Even worse, there is a bug
somewhere that causes CM to not compile package B (or C or D ...)
making things even worse. I got as far as figuring out that it was a
parameter that changed (I think it
Oh! Thanks. Talk about a wild goose chase.
So .. should planet be invoking setup-plt with flags that control the
documentation generation more carefully in order to speed up things?
Robby
On Wed, Jun 17, 2009 at 1:01 AM, Matthew Flattmfl...@cs.utah.edu wrote:
At Mon, 1 Jun 2009 08:58:46 -0500,
I haven't investigated, but I have a guess. When a planet package A
depends on another planet package B, then trying to compile A triggers
an install of B. As the docs for B build, the search and master index
are re-built, and that's where the time goes. Then the build of A
continues, and again
I think PLaneT does indeed work that way. Even worse, there is a bug
somewhere that causes CM to not compile package B (or C or D ...)
making things even worse. I got as far as figuring out that it was a
parameter that changed (I think it was the namespace?) that somehow
causes CM to disable
I have a fresh anecdote of practical impact of the slow documentation
crunching.
The first bit of code I try to run from the Snooze tutorial takes over 9
minutes on a fast computer, before it attempts to connect to the database.
It installs a lot of small PLaneT packages in these 9+ minutes,
Subjectively, it seems like the 4.x documentation has made builds and
PLaneT installs many times slower than with 3xx.
For me, optimizing these documentation updates is the improvement I'd
most like to see in PLT Scheme next.
Thanks,
Neil
--
http://www.neilvandyke.org/
On Fri, May 29, 2009 at 6:44 PM, Neil Van Dyke n...@neilvandyke.org wrote:
For me, optimizing these documentation updates is the improvement I'd most
like to see in PLT Scheme next.
Hear, hear.
_
For list-related administrative tasks:
