On Thu, Jun 27, 2013 at 11:06 PM, Robby Findler <ro...@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 >> <ro...@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 >> >> <ro...@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 >> >> >> <ro...@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 >> >> >> >> <sa...@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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
