One fairly clear thing is that the mzlib manual can move into the compatibility-lib.<div><br></div><div>We could move the mzlib-specific files from (the collection) tests/racket into a new tests/mzlib and put that into the compatibility-lib.</div>
<div><br></div><div>But that probably requires actual adjustments because tests/racket is load-based ...</div><div><br></div><div>Probably all of the mzlib-specific tests could be made to run in a #lang context without too much trouble, tho.</div>
<div><br></div><div>Robby<br><br>On Thursday, June 27, 2013, Sam Tobin-Hochstadt wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've kept tests and docs where they are, because I don't know what, if<br>
any, plans Matthew might already have about splitting those. I'm<br>
happy to follow such plans as needed.<br>
<br>
Sam<br>
<br>
On Thu, Jun 27, 2013 at 10:48 PM, Robby Findler<br>
<<a>robby@eecs.northwestern.edu</a>> wrote:<br>
> Is there a plan for moving the mzlib tests and docs from pkgs/racket-lib to<br>
> pkgs/compatibility-lib? (I didn't move the mzlib/contract ones yet because I<br>
> wasn't sure what to do. I can do stuff, tho, if you're not already.)<br>
><br>
> Robby<br>
><br>
> On Thursday, June 27, 2013, Sam Tobin-Hochstadt wrote:<br>
>><br>
>> Yes, since `scheme/mzscheme` is the same language for the (many) parts<br>
>> of the core that need it. There are a number of other small bits that<br>
>> I'll do as well.<br>
>><br>
>> On Thu, Jun 27, 2013 at 8:45 PM, Robby Findler<br>
>> <<a>robby@eecs.northwestern.edu</a>> wrote:<br>
>> > Did you consider moving "#lang mzscheme" out as well?<br>
>> ><br>
>> > Robby<br>
>> ><br>
>> ><br>
>> > On Thursday, June 27, 2013, Sam Tobin-Hochstadt wrote:<br>
>> >><br>
>> >> I've now pushed this set of changes, which pass all the racket tests<br>
>> >> and build the whole system cleanly. I think the next steps are:<br>
>> >><br>
>> >> - Robby is going to move mzlib/contract.<br>
>> >> - Matthew is going to modify mzlib/compiler and mzlib/unit200.<br>
>> >> - Ryan is working on shrinking the db collection.<br>
>> >> - I posted about shrinking the `pkg` collection and working toward<br>
>> >> removing parts of the `net` collection.<br>
>> >><br>
>> >> There are also some parts of some collections that aren't needed. Much<br>
>> >> of `openssl` could go if `pkg` was split. The decompiler and<br>
>> >> demodularizer could potentially be moved out. Perhaps distributed<br>
>> >> places could move.<br>
>> >><br>
>> >> Other things to would, in my estimation, be much harder, and would<br>
>> >> probably be things that are part of `#lang racket`, like the class or<br>
>> >> unit systems or `match`, or things that are deeply intertwined with<br>
>> >> `raco setup`, like planet.<br>
>> >><br>
>> >> Sam<br>
>> >><br>
>> >> On Wed, Jun 26, 2013 at 6:38 PM, Robby Findler<br>
>> >> <<a>robby@eecs.northwestern.edu</a>> wrote:<br>
>> >> > I can move mzlib/contract after you get done with other stuff.<br>
>> >> ><br>
>> >> > Robby<br>
>> >> ><br>
>> >> ><br>
>> >> > On Wednesday, June 26, 2013, Sam Tobin-Hochstadt wrote:<br>
>> >> >><br>
>> >> >> On Tue, Jun 25, 2013 at 4:32 PM, Sam Tobin-Hochstadt<br>
>> >> >> <<a>samth@ccs.neu.edu</a>><br>
>> >> >> wrote:<br>
>> >> >> > While moving some files around between packages, I realized that<br>
>> >> >> > there<br>
>> >> >> > are a number of things that could be moved out of the core and<br>
>> >> >> > into<br>
>> >> >> > packages. Here's a partial list of things that I think are not<br>
>> >> >> > needed<br>
>> >> >> > at all by the rest of the core:<br>
>> >> >><br>
>> >> >> I've now done the first step of this work. You can see the results<br>
>> >> >> here: <a href="https://github.com/plt/racket/pull/373" target="_blank">https://github.com/plt/racket/pull/373</a><br>
>> >> >><br>
>> >> >> This works to the degree that the core still compiles. No other<br>
>> >> >> testing has happened yet -- that's the next step. A number of<br>
>> >> >> packages<br>
>> >> >> will need additional dependencies.<br>
>> >> >><br>
>> >> >> I'd like to get feedback on exactly how this is organized. In<br>
>> >> >> particular, a bunch of things are now in a `compatibility-lib`<br>
>> >> >> collection:<br>
>> >> >><br>
>> >> >> * almost all of `mzlib`<br>
>> >> >> * `compatibility/*`<br>
>> >> >> * `racket/mpair` and `racket/mlist`<br>
>> >> >><br>
>> >> >> There's also the following new packages: `e</blockquote></div>