Re: [racket-dev] Things we could move out of the core
At Sun, 30 Jun 2013 18:10:52 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 11:25 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: So, I think option 2 is right for now, and we should eventually spend cycles on really getting `mzscheme' out of the core. Ok, I'll focus on that. I'm mostly done with this now. Progress in this pull request: https://github.com/plt/racket/pull/377 The most important commit is the one entitled Remove most uses of `mzscheme` in the core (I'm changing the sha1 on rebases). This is great - thanks! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On Fri, Jun 28, 2013 at 11:25 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: So, I think option 2 is right for now, and we should eventually spend cycles on really getting `mzscheme' out of the core. Ok, I'll focus on that. I'm mostly done with this now. Progress in this pull request: https://github.com/plt/racket/pull/377 The most important commit is the one entitled Remove most uses of `mzscheme` in the core (I'm changing the sha1 on rebases). Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
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? I've now created another pull request that does this, here: https://github.com/plt/racket/pull/377 There's one remaining question. The `make-base-namespace` procedure provided by `mzscheme` attaches the `mzscheme` module. But this pull request removes that module, so it can't be attached or required in this code. The alternatives are: 1. Just attach/require `scheme/mzscheme`. Slightly incompatible in some corner cases. 2. Don't remove `mzscheme` from the core. 3. Remove `make*-namespace` from `scheme/mzscheme` and implement them in the `mzscheme` collection in the `mzscheme` package. I'm currently leaning toward 3 but I'd appreciate anyone else's thoughts. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote: 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? I've now created another pull request that does this, here: https://github.com/plt/racket/pull/377 There's one remaining question. The `make-base-namespace` procedure provided by `mzscheme` attaches the `mzscheme` module. But this pull request removes that module, so it can't be attached or required in this code. The alternatives are: 1. Just attach/require `scheme/mzscheme`. Slightly incompatible in some corner cases. 2. Don't remove `mzscheme` from the core. 3. Remove `make*-namespace` from `scheme/mzscheme` and implement them in the `mzscheme` collection in the `mzscheme` package. I'm currently leaning toward 3 but I'd appreciate anyone else's thoughts. Is there some reason that `scheme/mzscheme' can't move to the mzscheme package (along with `racket/private/stxmz-body')? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote: 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? I've now created another pull request that does this, here: https://github.com/plt/racket/pull/377 There's one remaining question. The `make-base-namespace` procedure provided by `mzscheme` attaches the `mzscheme` module. But this pull request removes that module, so it can't be attached or required in this code. The alternatives are: 1. Just attach/require `scheme/mzscheme`. Slightly incompatible in some corner cases. 2. Don't remove `mzscheme` from the core. 3. Remove `make*-namespace` from `scheme/mzscheme` and implement them in the `mzscheme` collection in the `mzscheme` package. I'm currently leaning toward 3 but I'd appreciate anyone else's thoughts. Is there some reason that `scheme/mzscheme' can't move to the mzscheme package (along with `racket/private/stxmz-body')? Because large portions of the core are written in the `mzscheme` language (or `scheme/mzscheme`, after my patch), some of which feature evaluating code in mzscheme-like namespaces. If we can somehow get around the latter problem, then the former is a Small Matter of Programming, but it'll take a little while. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote: 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? I've now created another pull request that does this, here: https://github.com/plt/racket/pull/377 There's one remaining question. The `make-base-namespace` procedure provided by `mzscheme` attaches the `mzscheme` module. But this pull request removes that module, so it can't be attached or required in this code. The alternatives are: 1. Just attach/require `scheme/mzscheme`. Slightly incompatible in some corner cases. 2. Don't remove `mzscheme` from the core. 3. Remove `make*-namespace` from `scheme/mzscheme` and implement them in the `mzscheme` collection in the `mzscheme` package. I'm currently leaning toward 3 but I'd appreciate anyone else's thoughts. Is there some reason that `scheme/mzscheme' can't move to the mzscheme package (along with `racket/private/stxmz-body')? Because large portions of the core are written in the `mzscheme` language (or `scheme/mzscheme`, after my patch), some of which feature evaluating code in mzscheme-like namespaces. If we can somehow get around the latter problem, then the former is a Small Matter of Programming, but it'll take a little while. Ah --- I had not actually looked at 9587a2f. I guess I'm confused on the goal, since I don't see changing `mzscheme' to `scheme/mzscheme' as a step forward. Can you say more about the intent of changing `mzscheme' to `scheme/mzscheme'? Meanwhile, I worry that options 1 and 3 can create subtle and confusing bugs/incompatibilities. (I've spent a lot of time on problems that happened due to accidentally choosing similar options in the past.) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote: 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? I've now created another pull request that does this, here: https://github.com/plt/racket/pull/377 There's one remaining question. The `make-base-namespace` procedure provided by `mzscheme` attaches the `mzscheme` module. But this pull request removes that module, so it can't be attached or required in this code. The alternatives are: 1. Just attach/require `scheme/mzscheme`. Slightly incompatible in some corner cases. 2. Don't remove `mzscheme` from the core. 3. Remove `make*-namespace` from `scheme/mzscheme` and implement them in the `mzscheme` collection in the `mzscheme` package. I'm currently leaning toward 3 but I'd appreciate anyone else's thoughts. Is there some reason that `scheme/mzscheme' can't move to the mzscheme package (along with `racket/private/stxmz-body')? Because large portions of the core are written in the `mzscheme` language (or `scheme/mzscheme`, after my patch), some of which feature evaluating code in mzscheme-like namespaces. If we can somehow get around the latter problem, then the former is a Small Matter of Programming, but it'll take a little while. Ah --- I had not actually looked at 9587a2f. I guess I'm confused on the goal, since I don't see changing `mzscheme' to `scheme/mzscheme' as a step forward. Can you say more about the intent of changing `mzscheme' to `scheme/mzscheme'? The intent is to reduce the API surface area provided by the core. Note that `scheme/mzscheme` is not a documented API. Thus, moving the `mzscheme` language and collection would require anyone who depended on them to explicitly depend on another package. At some later point, we finish implementing the core without using `scheme/mzscheme`, move the actual implementation of `mzscheme` to the `mzscheme` package, without any compatibility problems. Meanwhile, I worry that options 1 and 3 can create subtle and confusing bugs/incompatibilities. (I've spent a lot of time on problems that happened due to accidentally choosing similar options in the past.) (1) definitely has the potential for subtle bugs. I believe that (3) is semantics preserving *except* insofar as some part of the core was using the `mzscheme` namespace creation functions, and would thus work differently. However, there are only two places in the core that use `make-namespace` from `mzscheme`. They are (a) the `setup/unpack` code using `eval` that you plan to remove and (b) a part of `compiler/private/xform.rkt` for loading precompiled headers. I don't know what the latter does, or if changing it to use a Racket namespace would have the potential to introduce bugs. But yes, there's definitely a worry about subtle bugs here. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
At Fri, 28 Jun 2013 17:43:42 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote: 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? I've now created another pull request that does this, here: https://github.com/plt/racket/pull/377 There's one remaining question. The `make-base-namespace` procedure provided by `mzscheme` attaches the `mzscheme` module. But this pull request removes that module, so it can't be attached or required in this code. The alternatives are: 1. Just attach/require `scheme/mzscheme`. Slightly incompatible in some corner cases. 2. Don't remove `mzscheme` from the core. 3. Remove `make*-namespace` from `scheme/mzscheme` and implement them in the `mzscheme` collection in the `mzscheme` package. I'm currently leaning toward 3 but I'd appreciate anyone else's thoughts. Is there some reason that `scheme/mzscheme' can't move to the mzscheme package (along with `racket/private/stxmz-body')? Because large portions of the core are written in the `mzscheme` language (or `scheme/mzscheme`, after my patch), some of which feature evaluating code in mzscheme-like namespaces. If we can somehow get around the latter problem, then the former is a Small Matter of Programming, but it'll take a little while. Ah --- I had not actually looked at 9587a2f. I guess I'm confused on the goal, since I don't see changing `mzscheme' to `scheme/mzscheme' as a step forward. Can you say more about the intent of changing `mzscheme' to `scheme/mzscheme'? The intent is to reduce the API surface area provided by the core. Note that `scheme/mzscheme` is not a documented API. Thus, moving the `mzscheme` language and collection would require anyone who depended on them to explicitly depend on another package. At some later point, we finish implementing the core without using `scheme/mzscheme`, move the actual implementation of `mzscheme` to the `mzscheme` package, without any compatibility problems. I see what you mean, but it feels wrong to me that `scheme/mzscheme' exists and isn't documented. I'd prefer to work toward getting it in the right package and documented. Meanwhile, I worry that options 1 and 3 can create subtle and confusing bugs/incompatibilities. (I've spent a lot of time on problems that happened due to accidentally choosing similar options in the past.) (1) definitely has the potential for subtle bugs. I believe that (3) is semantics preserving *except* insofar as some part of the core was using the `mzscheme` namespace creation functions, and would thus work differently. However, there are only two places in the core that use `make-namespace` from `mzscheme`. They are (a) the `setup/unpack` code using `eval` that you plan to remove and (b) a part of `compiler/private/xform.rkt` for loading precompiled headers. I don't know what the latter does, or if changing it to use a Racket namespace would have the potential to introduce bugs. But yes, there's definitely a worry about subtle bugs here. There's also the issue that `scheme/mzscheme' introduces an `for-syntax' import of `scheme/mzscheme', and not a `for-syntax' import of `mzscheme', so `make-base-namespace' would disappear from phase 1 in `mzscheme' --- if I'm following correctly. So, I think option 2 is right for now, and we should eventually spend cycles on really getting `mzscheme' out of the core. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On Fri, Jun 28, 2013 at 6:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 17:43:42 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote: 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? I've now created another pull request that does this, here: https://github.com/plt/racket/pull/377 There's one remaining question. The `make-base-namespace` procedure provided by `mzscheme` attaches the `mzscheme` module. But this pull request removes that module, so it can't be attached or required in this code. The alternatives are: 1. Just attach/require `scheme/mzscheme`. Slightly incompatible in some corner cases. 2. Don't remove `mzscheme` from the core. 3. Remove `make*-namespace` from `scheme/mzscheme` and implement them in the `mzscheme` collection in the `mzscheme` package. I'm currently leaning toward 3 but I'd appreciate anyone else's thoughts. Is there some reason that `scheme/mzscheme' can't move to the mzscheme package (along with `racket/private/stxmz-body')? Because large portions of the core are written in the `mzscheme` language (or `scheme/mzscheme`, after my patch), some of which feature evaluating code in mzscheme-like namespaces. If we can somehow get around the latter problem, then the former is a Small Matter of Programming, but it'll take a little while. Ah --- I had not actually looked at 9587a2f. I guess I'm confused on the goal, since I don't see changing `mzscheme' to `scheme/mzscheme' as a step forward. Can you say more about the intent of changing `mzscheme' to `scheme/mzscheme'? The intent is to reduce the API surface area provided by the core. Note that `scheme/mzscheme` is not a documented API. Thus, moving the `mzscheme` language and collection would require anyone who depended on them to explicitly depend on another package. At some later point, we finish implementing the core without using `scheme/mzscheme`, move the actual implementation of `mzscheme` to the `mzscheme` package, without any compatibility problems. I see what you mean, but it feels wrong to me that `scheme/mzscheme' exists and isn't documented. I'd prefer to work toward getting it in the right package and documented. Do you see an advantage to documenting it, over just having `mzscheme` documented (and perhaps moving `scheme/mzscheme` to `racket/private`)? Meanwhile, I worry that options 1 and 3 can create subtle and confusing bugs/incompatibilities. (I've spent a lot of time on problems that happened due to accidentally choosing similar options in the past.) (1) definitely has the potential for subtle bugs. I believe that (3) is semantics preserving *except* insofar as some part of the core was using the `mzscheme` namespace creation functions, and would thus work differently. However, there are only two places in the core that use `make-namespace` from `mzscheme`. They are (a) the `setup/unpack` code using `eval` that you plan to remove and (b) a part of `compiler/private/xform.rkt` for loading precompiled headers. I don't know what the latter does, or if changing it to use a Racket namespace would have the potential to introduce bugs. But yes, there's definitely a worry about subtle bugs here. There's also the issue that `scheme/mzscheme' introduces an `for-syntax' import of `scheme/mzscheme', and not a `for-syntax' import of `mzscheme', so `make-base-namespace' would disappear from phase 1 in `mzscheme' --- if I'm following correctly. I don't follow this. As far as I can tell, neither `mzscheme` nor `scheme/mzscheme` introduce `for-syntax` imports of anything. So, I think option 2 is right for now, and we should eventually spend cycles on really getting `mzscheme' out of the core. Ok, I'll focus on that. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
At Fri, 28 Jun 2013 23:25:22 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 6:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 17:43:42 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote: On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote: 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? I've now created another pull request that does this, here: https://github.com/plt/racket/pull/377 There's one remaining question. The `make-base-namespace` procedure provided by `mzscheme` attaches the `mzscheme` module. But this pull request removes that module, so it can't be attached or required in this code. The alternatives are: 1. Just attach/require `scheme/mzscheme`. Slightly incompatible in some corner cases. 2. Don't remove `mzscheme` from the core. 3. Remove `make*-namespace` from `scheme/mzscheme` and implement them in the `mzscheme` collection in the `mzscheme` package. I'm currently leaning toward 3 but I'd appreciate anyone else's thoughts. Is there some reason that `scheme/mzscheme' can't move to the mzscheme package (along with `racket/private/stxmz-body')? Because large portions of the core are written in the `mzscheme` language (or `scheme/mzscheme`, after my patch), some of which feature evaluating code in mzscheme-like namespaces. If we can somehow get around the latter problem, then the former is a Small Matter of Programming, but it'll take a little while. Ah --- I had not actually looked at 9587a2f. I guess I'm confused on the goal, since I don't see changing `mzscheme' to `scheme/mzscheme' as a step forward. Can you say more about the intent of changing `mzscheme' to `scheme/mzscheme'? The intent is to reduce the API surface area provided by the core. Note that `scheme/mzscheme` is not a documented API. Thus, moving the `mzscheme` language and collection would require anyone who depended on them to explicitly depend on another package. At some later point, we finish implementing the core without using `scheme/mzscheme`, move the actual implementation of `mzscheme` to the `mzscheme` package, without any compatibility problems. I see what you mean, but it feels wrong to me that `scheme/mzscheme' exists and isn't documented. I'd prefer to work toward getting it in the right package and documented. Do you see an advantage to documenting it, over just having `mzscheme` documented (and perhaps moving `scheme/mzscheme` to `racket/private`)? No, I agree with your suggestion (I think) that just having `mzscheme' would be better. There's also the issue that `scheme/mzscheme' introduces an `for-syntax' import of `scheme/mzscheme', and not a `for-syntax' import of `mzscheme', so `make-base-namespace' would disappear from phase 1 in `mzscheme' --- if I'm following correctly. I don't follow this. As far as I can tell, neither `mzscheme` nor `scheme/mzscheme` introduce `for-syntax` imports of anything. The `#%module-begin' of `mzscheme' introduces `(#%require (for-syntax scheme/mzscheme))' into the module body --- a leftover from the days before phase-1 exports were supported. Changing the introduced `require' from `scheme/mzscheme' to `mzscheme' should be ok, as far as I can tell. We just don't want to accidentally change the bindings that are imported by that `require'. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
This all looks right to me. At Wed, 26 Jun 2013 17:38:49 -0500, Robby Findler 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.edujavascript:; 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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On Thu, Jun 27, 2013 at 9:02 AM, Matthew Flatt mfl...@cs.utah.edu wrote: This all looks right to me. Any thoughts on `mzlib/unit200` or `mzlib/compile`? Sam At Wed, 26 Jun 2013 17:38:49 -0500, Robby Findler 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.edujavascript:; 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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
At Thu, 27 Jun 2013 09:04:46 -0400, Sam Tobin-Hochstadt wrote: On Thu, Jun 27, 2013 at 9:02 AM, Matthew Flatt mfl...@cs.utah.edu wrote: This all looks right to me. Any thoughts on `mzlib/unit200` or `mzlib/compile`? I imagine fixing them later by * moving the useful part of `mzlib/compile' and putting a compatibility `mzlib/compile' into compatbility-lib; * revising `file/gzip' to not use `mzlib/unit200'; and * dropping support for arbitrary unpack code in .plt files (and instead just pattern match on the only `unit' expression form that is ever used in practice). Sam At Wed, 26 Jun 2013 17:38:49 -0500, Robby Findler 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.edujavascript:; 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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On Thu, Jun 27, 2013 at 9:11 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 27 Jun 2013 09:04:46 -0400, Sam Tobin-Hochstadt wrote: On Thu, Jun 27, 2013 at 9:02 AM, Matthew Flatt mfl...@cs.utah.edu wrote: This all looks right to me. Any thoughts on `mzlib/unit200` or `mzlib/compile`? I imagine fixing them later by * moving the useful part of `mzlib/compile' and putting a compatibility `mzlib/compile' into compatbility-lib; * revising `file/gzip' to not use `mzlib/unit200'; and * dropping support for arbitrary unpack code in .plt files (and instead just pattern match on the only `unit' expression form that is ever used in practice). Do you plan to do this before the next release? This brings up a larger question -- what kind of backwards-compatibility commitment do we plan to make for the contents of the core, vs packages that need to be installed? I can imagine a few possibilities: (1) anything shipped with the core is still shipped with the core in later releases, (2) code in the core may migrate to packages that clients will need to add as dependencies, or possibly other solutions. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
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 javascript:; 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.edujavascript:; 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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: use _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: use _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
One fairly clear thing is that the mzlib manual can move into the compatibility-lib. 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. 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
Re: [racket-dev] Things we could move out of the core
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
Re: [racket-dev] Things we could move out of the core
On Thu, Jun 27, 2013 at 10:08 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: 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)`. I know. Is that a problem? Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On Thu, Jun 27, 2013 at 11:12 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Jun 27, 2013 at 10:08 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: 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)`. I know. Is that a problem? No, I wouldn't think so. Just wondering if you had intended to update them. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
As far as I can tell they are up to date. Robby On Friday, June 28, 2013, Sam Tobin-Hochstadt wrote: On Thu, Jun 27, 2013 at 11:12 PM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: On Thu, Jun 27, 2013 at 10:08 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edujavascript:; wrote: On Thu, Jun 27, 2013 at 11:06 PM, Robby Findler ro...@eecs.northwestern.edu javascript:; 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)`. I know. Is that a problem? No, I wouldn't think so. Just wondering if you had intended to update them. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
(BTW, there's a file/private/octree-quantize which should move to where file/gif is.) An hour ago, Robby Findler wrote: The sandbox, IMO, is a nice standalone library the does not need to be in the core. (Ditto for errortrace.) I like the definition of the core as minimum stuff to get pkgs running and we should be picky about what goes in -- even to the point of rewriting some code to move other stuff out. This doesn't make sense if things at such a small size turn to packages. It's true that a package is a unit of utility for end users, but it's also a unit of developement. IMO there are far better things to move out -- things that are bigger (in size and complexity) like (on a brief scan) contracts, gui, match, places, units, json, planet, xml, net, help.[*] Think of someone deploying a game on a phone: would they be happy with your rationale influencing their app's size? I think that errortrace has been one of the biggest offenders in terms of bad bugs of many varieties -- and moving it out won't help. (And if I were doing a game on a phone I'd worry about any of the above much more, btw.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On Wed, Jun 26, 2013 at 6:36 AM, Eli Barzilay e...@barzilay.org wrote: An hour ago, Robby Findler wrote: The sandbox, IMO, is a nice standalone library the does not need to be in the core. (Ditto for errortrace.) I like the definition of the core as minimum stuff to get pkgs running and we should be picky about what goes in -- even to the point of rewriting some code to move other stuff out. This doesn't make sense if things at such a small size turn to packages. It's true that a package is a unit of utility for end users, but it's also a unit of developement. IMO there are far better things to move out -- things that are bigger (in size and complexity) like (on a brief scan) contracts, gui, match, places, units, json, planet, xml, net, help.[*] `racket/gui` just contains `racket/gui/dynamic`. The `help` collection has 72 lines of code. `racket/match`, `racket/unit`, and `racket/contract` are widely used in the core, as is `syntax-parse`, another big library. We could decide to move them out, but that would be a big change in coding style and a massive rewrite of a lot of code. `planet` is closely tied to the internals of the setup system. We might wish this wasn't the case, but I doubt that it's worth disentangling. The package system uses `net`, of course. Places are used by `raco setup`. Perhaps distributed places could be moved -- I don't know how intertwined they are. `xml` is used by `planet` (for checking that some info.rkt fields are properly xexprs), `db` (not actually used, I think), and `compiler` (for managing plists when creating bundles on OS X). `json` is used by `db` (for handling JSON in Postgres) and `pkg` (for contacting GitHub). For these two, if you wanted to write the patch to make them removable, that would be great, but it looks like it would be hard. Think of someone deploying a game on a phone: would they be happy with your rationale influencing their app's size? I think that errortrace has been one of the biggest offenders in terms of bad bugs of many varieties -- and moving it out won't help. (And if I were doing a game on a phone I'd worry about any of the above much more, btw.) I think library that has lots of bugs and mostly only Matthew ever knows how to fix is a strong candidate for _not_ being in the core. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
In general I agree with Robby on the definition of the core as minimum stuff to get pkgs running and we should be picky about what goes in. BUT, as a small addendum, I think the idea of sandboxing is so fundamental, I'd rather see the idea (not necessarily the current implementation) become a part of the core. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
What does being so fundamental have to do with being in the core vs being in a package? We should not confuse putting things in packages with making them second-class concepts. We can put racket/sandbox in a package without necessarily making it any less fundamental to Racket. Carl Eastlund On Wed, Jun 26, 2013 at 8:46 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: In general I agree with Robby on the definition of the core as minimum stuff to get pkgs running and we should be picky about what goes in. BUT, as a small addendum, I think the idea of sandboxing is so fundamental, I'd rather see the idea (not necessarily the current implementation) become a part of the core. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
Fundamental to me is Robby's necessary to install packages. One day we may wish to offer sandboxing for the installation of packages. On Jun 26, 2013, at 8:51 AM, Carl Eastlund wrote: What does being so fundamental have to do with being in the core vs being in a package? We should not confuse putting things in packages with making them second-class concepts. We can put racket/sandbox in a package without necessarily making it any less fundamental to Racket. Carl Eastlund On Wed, Jun 26, 2013 at 8:46 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: In general I agree with Robby on the definition of the core as minimum stuff to get pkgs running and we should be picky about what goes in. BUT, as a small addendum, I think the idea of sandboxing is so fundamental, I'd rather see the idea (not necessarily the current implementation) become a part of the core. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
Lots of things that are fundamental in the sense I think you mean are not in the core: documentation, types, eventspaces. The building blocks of sandboxing, such as custodians and security guards and inspectors, are in the core. Sam On Jun 26, 2013 8:47 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: In general I agree with Robby on the definition of the core as minimum stuff to get pkgs running and we should be picky about what goes in. BUT, as a small addendum, I think the idea of sandboxing is so fundamental, I'd rather see the idea (not necessarily the current implementation) become a part of the core. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On 06/26/2013 02:32 PM, Sam Tobin-Hochstadt wrote: [...] Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. I have a branch where I've split db into the base code and sqlite3 driver, which stays in racket/lib/collects/db, and the other drivers and utils, which move to a package. After the split, the core db code would no longer depend on srfi/19 or json. It doesn't depend on xml now. (The xml and json collections were mentioned earlier in the thread.) The branch isn't quite ready to merge because I might need to update lazy-require to work across packages. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
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.edujavascript:; 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: `errortrace-lib`, `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, `sandbox-lib`, `data-lib`, `rackunit`. The `help` collection moved to `scribble/lib`. Where there isn't a new documentation package, libraries are mostly documented in `unstable` or `racket-doc`. Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On 2013-06-25 16:32:28 -0400, Sam Tobin-Hochstadt wrote:
- mzlib/{pconvert, class100, serialize, thread, transcr}
According to the 5.3 release announcement, class100 is set to be removed
by the August release, so maybe we can just remove it entirely now.
Cheers,
Asumu
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
At Tue, 25 Jun 2013 16:32:28 -0400, Sam Tobin-Hochstadt 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:
- racket/sandbox and the rest of the sandbox code
- data/{union-find, interval-map, splay-tree, skip-list, order, gvector, heap}
- srfi/4
- unstable/{options, contract}
- errortrace (once sandbox is removed)
- compatibility/*
- mzlib/{pconvert, class100, serialize, thread, transcr}
- a bunch of other parts of mzlib that are just reprovides
The following are libraries that could be removed with (I believe)
small changes to the rest of the core:
- rackunit
- srfi/13
- mzlib/unit200 (maybe, this might be hard)
- mzlib/kw
If this seems like a good idea to people, I'm happy to go ahead and
start doing the work.
That seems like a good idea to me.
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
Two.5 notes:
* IMO the sandbox and errortrace should stay in -- even if they're not
needed, they are both intimately tied to the core so there wouldn't
be any benefit from moving them to a package.
* I think that it makes sense to move compatibility into its own
package, and move the mzlib stuff into that same package.
* Maybe the same for data?
9 hours ago, Sam Tobin-Hochstadt 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:
- racket/sandbox and the rest of the sandbox code
- data/{union-find, interval-map, splay-tree, skip-list, order, gvector, heap}
- srfi/4
- unstable/{options, contract}
- errortrace (once sandbox is removed)
- compatibility/*
- mzlib/{pconvert, class100, serialize, thread, transcr}
- a bunch of other parts of mzlib that are just reprovides
The following are libraries that could be removed with (I believe)
small changes to the rest of the core:
- rackunit
- srfi/13
- mzlib/unit200 (maybe, this might be hard)
- mzlib/kw
If this seems like a good idea to people, I'm happy to go ahead and
start doing the work.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_
Racket Developers list:
http://lists.racket-lang.org/dev
