Re: [racket-dev] single-collection packages
Much better indeed, but maybe there is still some redundancy left with the `setup-collects' option? http://docs.racket-lang.org/pkg/metadata.html Laurent On Tue, Jun 25, 2013 at 11:08 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: +1 On Jun 25, 2013, at 4:27 PM, Sam Tobin-Hochstadt wrote: On Tue, Jun 25, 2013 at 4:24 PM, Matthew Flatt mfl...@cs.utah.edu wrote: So, I think it's better to define `collection': [snip] I think this is a definite improvement. 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] single-collection packages
(looks like I'm misunderstanding this option. Forget about it.) On Wed, Jun 26, 2013 at 10:30 AM, Laurent laurent.ors...@gmail.com wrote: Much better indeed, but maybe there is still some redundancy left with the `setup-collects' option? http://docs.racket-lang.org/pkg/metadata.html Laurent On Tue, Jun 25, 2013 at 11:08 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: +1 On Jun 25, 2013, at 4:27 PM, Sam Tobin-Hochstadt wrote: On Tue, Jun 25, 2013 at 4:24 PM, Matthew Flatt mfl...@cs.utah.edu wrote: So, I think it's better to define `collection': [snip] I think this is a definite improvement. 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
(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
[racket-dev] Diagnosing traverse-block errors in scribble
I'm still stuck on the traverse-block problems I posted about a week ago, but hopefully this is a simpler question to answer than my one from last week. I keep getting an error traverse-block-block: no block computed for traverse-block, and am trying to understand how to interpret this. Does it mean too many or too few (lambda (get set) ...) wrappers around the block that I'm to build inside traverse-block? As I understand traverse-block, the number of (lambda (get set) ...) wrappers is what helps stage the passes. So if I want to generate data in the first pass, I need one lambda, but to use that in second pass I need two lambdas. Is that the right intuition? thanks, Kathi _ 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
