[racket-dev] Things we could move out of the core

On Thu, Jun 27, 2013 at 11:06 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> One fairly clear thing is that the mzlib manual can move into the
> compatibility-lib.

I agree.

> We could move the mzlib-specific files from (the collection) tests/racket
> into a new tests/mzlib and put that into the compatibility-lib.
>
> But that probably requires actual adjustments because tests/racket is
> load-based ...
>
> Probably all of the mzlib-specific tests could be made to run in a #lang
> context without too much trouble, tho.

I don't feel 100% confident mucking with the tests/racket
infrastructure, and I don't know how worth it this would be.

BTW, you have some commented-out tests in racket/private/contract that
`(require mzlib/contract)`.

Sam


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