Re: [racket-dev] Diagnosing traverse-block errors in scribble
At Thu, 27 Jun 2013 05:18:32 -0700, Matthew Flatt wrote: At Wed, 26 Jun 2013 16:19:55 -0400, Kathi Fisler wrote: I keep getting an error traverse-block-block: no block computed for traverse-block, and am trying to understand how to interpret this. The error means that a particular traverse block was discovered for the first time after the traverse pass. I thought of another way to get the error: (traverse-block (letrec ([stuck (lambda (get set) stuck)]) stuck)) In this case, even when the `traverse-block' is seen at traverse time, it reaches a fixpoint without producing a block. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Diagnosing traverse-block errors in scribble
At Wed, 26 Jun 2013 16:19:55 -0400, Kathi Fisler wrote: 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? That's right. In the code you posted last week, (define (glossary) (traverse-block (lambda (get set) (traverse-block (lambda (get set) (define terms (get 'vocab-used '())) (para terms)) the `traverse-block' is are not useful. The inner `lambda' needs to be exposed directly to make it happen on the next iteration. At the end of this message is an example showing nested `lambda's. But I bet the path to solving your problem is to use the collect and resolve passes, instead. At Wed, 26 Jun 2013 16:19:55 -0400, Kathi Fisler wrote: I keep getting an error traverse-block-block: no block computed for traverse-block, and am trying to understand how to interpret this. The error means that a particular traverse block was discovered for the first time after the traverse pass. For example, if a `delayed-block' generates a `traverse-block', then it will trigger the error, because `delayed-block's are not triggered until the resolve pass: (delayed-block (lambda (r p ri) (traverse-block (lambda (get set) (para won't get here) Maybe you're using your glossary forms in something that delays until a resolve pass? But, then, I can't explain why you see the error only when using nested `lambda's in a `traverse-block'. If I'm on the right track, anyway, then for something like a glossary, you can probably use the collect and resolve passes, instead of the traverse pass. That way, your glossary construction will work nicely with other things that happen at the collect and resolve passes. #lang scribble/base @(require scribble/core) @(traverse-element (lambda (get set) ;; Not delayed, and so result is not ready, yet (get 'glossary not ready, yet))) @(traverse-element (lambda (get set) ;; Delayed until second traversal: (lambda (get set) (get 'glossary BROKEN @; Same thing, but with blocks: @(traverse-block (lambda (get set) ;; Not delayed: (para The glossary is (get 'glossary not ready, yet @(traverse-block (lambda (get set) ;; Delayed: (lambda (get set) (para The glossary is (get 'glossary BROKEN) @(traverse-block (lambda (get set) ;; Adding a `delayed-block' doesn't delay: (traverse-block (lambda (get set) (para The glossary is (get 'glossary not ready, yet)) @(traverse-block (lambda (get set) (set 'glossary ready) (para Here is the glossary.))) _ 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] `raco link', links.rktd, pkgs, and config.rktd
At Wed, 26 Jun 2013 01:04:13 -0400, Eli Barzilay wrote: 8 hours ago, Matthew Flatt wrote: The config.rktd file in etc can now specify a location for the installation-wide links.rktd file and pkgs installed-package directory (with its pkgs.rktd). On a clean build I get an empty etc directory -- explained by moving the files that were in it -- but is it now a bug, or is it a placeholder for an optional config file? (Would there be anything else there?) Yes, that's as intended. I think config.rktd is the only thing that is put in etc, now. Furthermore, config.rktd can provide a list of additional files/directories to search. This allows the main links.rktd and pkgs to act like /usr/lib things, while additional directories can act like /lib things. Can you explain this more? I don't see the connection. Sorry, I meant to write /usr/local/lib (instead of /usr/lib) and /usr/lib (instead of /lib). It that more clear? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Triggered a macro system internal error
I mean taints, not traits. At Thu, 27 Jun 2013 06:32:20 -0700, Matthew Flatt wrote: The problem was in the way that traits are managed for submodule expansion plus a problem with Typed Racket's trait arming of a module body (which was also my fault). I've pushed a repair. At Tue, 25 Jun 2013 10:05:28 -0400, Asumu Takikawa wrote: Hi all, I accidentally triggered what appears to be an internal error message from the macro expander (to do with syntax taints). Unfortunately, I have no idea how to come up with a narrow test case since it happens due to changing Typed Racket's `struct:` expansion. I've attached a short patch below that shows what's needed to trigger it though. Here's the interaction I get with the patch applied: $ racket -I typed/racket Welcome to Racket v5.3.900.1. - (struct: Foo ([x : Integer])) ; internal error: cannot copy taint armings from tainted source [,bt for ; context] Any ideas on how I can get a better test case? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `raco link', links.rktd, pkgs, and config.rktd
Two hours ago, Matthew Flatt wrote: At Wed, 26 Jun 2013 01:04:13 -0400, Eli Barzilay wrote: Furthermore, config.rktd can provide a list of additional files/directories to search. This allows the main links.rktd and pkgs to act like /usr/lib things, while additional directories can act like /lib things. Can you explain this more? I don't see the connection. Sorry, I meant to write /usr/local/lib (instead of /usr/lib) and /usr/lib (instead of /lib). It that more clear? Yeah, that's what I hoped you meant... -- ((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] Package management
The package system has a notion of auto packages, which are packages that were automatically installed to satisfy dependencies. Also, `raco pkg remove' supports an `--auto' flag for automatically removing auto packages that have no non-auto packages depending on them. So, instead of adding package roots, one possibility is: * Make `raco pkg show' show only non-auto packages by default. * Change the `pkg-links' Makefile target to install only links for packages needed by a particular package (which defaults to some sort of main-distribution package), and to install links forced by dependencies as auto. The second bullet is along a direction that things are moving, anyway. I think there will need to be some other refinements to auto mode. For example, if you have a package in auto mode and you try to install it, I think you get an already-installed error and the package stays in auto mode. But those are small changes, I think. Does this sound enough like what you had in mind? At Thu, 27 Jun 2013 12:53:59 -0400, Carl Eastlund wrote: I just ran raco pkg show on a fresh install, and its output is huge now. Of course, this is inevitable when we break the distribution up into many packages, but it makes the tool unmanageable for routine use. I'd like to propose a way around this, that would also solve some of my normal usability gripes with package managers. I propose we have package roots -- roots to the forest of package dependencies. These are the packages the user actually wants; every other installed package is pulled in as the dependencies to support these. Then raco pkg show can show just these packages, so in a fresh install we'd just see racket or racket+gui or whatever. We could add a flag to show everything, when necessary. This also gives us some room to automate removal of packages the user doesn't need. For instance, if I install package A which depends on B, C, and D, of course raco pkg install will install B, C, and D. If I remove package A, currently B, C, and D are going to stay unless I explicitly remove them, if I recall correctly. If we base our system on a set of root packages, then B, C, and D would be removable as soon as A is removed, if A was a root and the others were not. We could have raco pkg remove A remove them immediately, or we could have some explicit raco pkg cleanup to remove them. Whichever way we go, we could add a flag to raco pkg remove to swap behavior. This would make cleaning up a lot easier when a package has many dependencies. It would also mean upgrading a package whose dependencies have changed would allow the system to automatically clean up dependencies that aren't needed any more. I don't know how hard it would be to implement this, but I think it would make the package system much more usable to present 90% of the interactions solely in terms of the top-level packages the user cares about, and do all the cleanup of dependency packages silently in the background when possible. Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package management
That all sounds like exactly what I had in mind, with different (pretty much better) terminology. Carl Eastlund On Thu, Jun 27, 2013 at 3:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The package system has a notion of auto packages, which are packages that were automatically installed to satisfy dependencies. Also, `raco pkg remove' supports an `--auto' flag for automatically removing auto packages that have no non-auto packages depending on them. So, instead of adding package roots, one possibility is: * Make `raco pkg show' show only non-auto packages by default. * Change the `pkg-links' Makefile target to install only links for packages needed by a particular package (which defaults to some sort of main-distribution package), and to install links forced by dependencies as auto. The second bullet is along a direction that things are moving, anyway. I think there will need to be some other refinements to auto mode. For example, if you have a package in auto mode and you try to install it, I think you get an already-installed error and the package stays in auto mode. But those are small changes, I think. Does this sound enough like what you had in mind? At Thu, 27 Jun 2013 12:53:59 -0400, Carl Eastlund wrote: I just ran raco pkg show on a fresh install, and its output is huge now. Of course, this is inevitable when we break the distribution up into many packages, but it makes the tool unmanageable for routine use. I'd like to propose a way around this, that would also solve some of my normal usability gripes with package managers. I propose we have package roots -- roots to the forest of package dependencies. These are the packages the user actually wants; every other installed package is pulled in as the dependencies to support these. Then raco pkg show can show just these packages, so in a fresh install we'd just see racket or racket+gui or whatever. We could add a flag to show everything, when necessary. This also gives us some room to automate removal of packages the user doesn't need. For instance, if I install package A which depends on B, C, and D, of course raco pkg install will install B, C, and D. If I remove package A, currently B, C, and D are going to stay unless I explicitly remove them, if I recall correctly. If we base our system on a set of root packages, then B, C, and D would be removable as soon as A is removed, if A was a root and the others were not. We could have raco pkg remove A remove them immediately, or we could have some explicit raco pkg cleanup to remove them. Whichever way we go, we could add a flag to raco pkg remove to swap behavior. This would make cleaning up a lot easier when a package has many dependencies. It would also mean upgrading a package whose dependencies have changed would allow the system to automatically clean up dependencies that aren't needed any more. I don't know how hard it would be to implement this, but I think it would make the package system much more usable to present 90% of the interactions solely in terms of the top-level packages the user cares about, and do all the cleanup of dependency packages silently in the background when possible. Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package management
On Thu, Jun 27, 2013 at 3:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The package system has a notion of auto packages, which are packages that were automatically installed to satisfy dependencies. Also, `raco pkg remove' supports an `--auto' flag for automatically removing auto packages that have no non-auto packages depending on them. Note that this is also how the deb package manager (on Debian/Ubuntu/etc) works, so we have good precedent here. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package management
An hour and a half ago, Sam Tobin-Hochstadt wrote: On Thu, Jun 27, 2013 at 3:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The package system has a notion of auto packages, which are packages that were automatically installed to satisfy dependencies. Also, `raco pkg remove' supports an `--auto' flag for automatically removing auto packages that have no non-auto packages depending on them. Note that this is also how the deb package manager (on Debian/Ubuntu/etc) works, so we have good precedent here. I think that all distros do that for a number of years now. -- ((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
[racket-dev] Splitting the `pkg` implementation
As part of making the core of Racket smaller, I'd like to propose separating out part of the package system implementation. In particular, I'd like to make the core portion of the package collection not use the network. This would allow us to remove the `net` and `json` collections, something like 7500 lines of code, from the core. [1] I think, from looking at the code, that there are two major ways the network is used right now: (1) fetching packages named at remote locations, and (2) fetching the contents of the remote catalog. For (1), I think this should be made extensible. There should be an info.rkt field, named say `pkg-installer`, which specifies [2] a function like `package-source-name+type` and also a function like `stage-package/info` as well as a type. Then the relevant functions use `find-relvant-directories` to find all the extensions, and call them in order to see if they match. This would both allow parts of the current implementation to be taken out of the core (such as the GitHub-specific code) but allow people to extend the package manager with new ways of specifying packages, such as with git urls directly. For (2), the case is a littler harder. All the places I can find that use the network in this case are inside `catalog-dispatch`, and use `read-from-server` to talk to the network. I propose that `catalog-dispatch` pass `read-from-server` as an extra argument to the server callback, and only call the server callback if the `net/url` library is available. I'm not entirely happy with this test, though. Finally, there's a lot of url manipulation that doesn't use the network. I propose to move the portion of `net/url` that does this to a separate `net/url-struct` library, which would be re-provided by `net/url`. Sam [1] We could move (and I plan to) most of this either way -- the core doesn't depend on `net/imap`. [2] Probably by specifying a module path that would provide a few known names. _ 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] Splitting the `pkg` implementation
At Thu, 27 Jun 2013 18:28:50 -0400, Sam Tobin-Hochstadt wrote: As part of making the core of Racket smaller, I'd like to propose separating out part of the package system implementation. In particular, I'd like to make the core portion of the package collection not use the network. That's a different direction than I had imagined. I imagine that (in the future) people will clone just the core repo, build, and then use `raco pkg install' to install packages from other servers --- probably pre-built packages by default, but optionally (and more likely for a non-release version) from a source catalog server that points to GitHub repositories. More generally, the network seems to me the main way to get packages. The way that our repository's makefile sets up links (and therefore doesn't need the network) or otherwise locally constructs packages seems in contrast, like a relatively unusual way to install packages. This would allow us to remove the `net` and `json` collections, something like 7500 lines of code, from the core. [1] I think, from looking at the code, that there are two major ways the network is used right now: (1) fetching packages named at remote locations, and (2) fetching the contents of the remote catalog. For (1), I think this should be made extensible. There should be an info.rkt field, named say `pkg-installer`, which specifies [2] a function like `package-source-name+type` and also a function like `stage-package/info` as well as a type. Then the relevant functions use `find-relvant-directories` to find all the extensions, and call them in order to see if they match. This would both allow parts of the current implementation to be taken out of the core (such as the GitHub-specific code) but allow people to extend the package manager with new ways of specifying packages, such as with git urls directly. For (2), the case is a littler harder. All the places I can find that use the network in this case are inside `catalog-dispatch`, and use `read-from-server` to talk to the network. I propose that `catalog-dispatch` pass `read-from-server` as an extra argument to the server callback, and only call the server callback if the `net/url` library is available. I'm not entirely happy with this test, though. I like this idea for extensibility, but I worry that break the existing support down too finely will complicate a build process. If Github support isn't in the core, for example, then you need to install a package some other way to get GitHub support. That is, you need some sort of source-package catalog server that doesn't point to GitHub repositories --- at least for the packages needed to get GitHub support, and so on. Finally, there's a lot of url manipulation that doesn't use the network. I propose to move the portion of `net/url` that does this to a separate `net/url-struct` library, which would be re-provided by `net/url`. Sam [1] We could move (and I plan to) most of this either way -- the core doesn't depend on `net/imap`. [2] Probably by specifying a module path that would provide a few known names. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Splitting the `pkg` implementation
On Thu, Jun 27, 2013 at 7:04 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 27 Jun 2013 18:28:50 -0400, Sam Tobin-Hochstadt wrote: As part of making the core of Racket smaller, I'd like to propose separating out part of the package system implementation. In particular, I'd like to make the core portion of the package collection not use the network. That's a different direction than I had imagined. I imagine that (in the future) people will clone just the core repo, build, and then use `raco pkg install' to install packages from other servers --- probably pre-built packages by default, but optionally (and more likely for a non-release version) from a source catalog server that points to GitHub repositories. More generally, the network seems to me the main way to get packages. The way that our repository's makefile sets up links (and therefore doesn't need the network) or otherwise locally constructs packages seems in contrast, like a relatively unusual way to install packages. Ok, that clarifies things for me. I had imagined that the process would involve keeping something like the now-current build system around, but with fewer packages in the default repository, and some packages referenced via git submodules. However, I think what you propose sounds simpler and nicer, and it's definitely worth keeping `net/url` in the core to support that. I'll pursue the extensibility part separately, but probably not immediately. Sam _ 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] [plt] Push #27030: master branch updated
On 2013-06-27 22:21:23 -0400, as...@racket-lang.org wrote: 42b5cfe Asumu Takikawa as...@racket-lang.org 2013-06-27 22:17 : | Use racket/cmdline instead of mzlib/cmdline | | This should fix the build : This fixes the build on my machine, but there are several more files left over that have dependencies on `mzlib`. I don't know which are essential: * racket/src/worksp/gc2/make.rkt * racket/src/worksp/mzcom/xform.rkt * racket/src/racket/gc/upgrade.rkt * racket/src/mac/osx_appl.rkt Cheers, Asumu _ 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] [plt] Push #27030: master branch updated
On Thu, Jun 27, 2013 at 10:32 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-06-27 22:21:23 -0400, as...@racket-lang.org wrote: 42b5cfe Asumu Takikawa as...@racket-lang.org 2013-06-27 22:17 : | Use racket/cmdline instead of mzlib/cmdline | | This should fix the build : This fixes the build on my machine, but there are several more files left over that have dependencies on `mzlib`. I don't know which are essential: * racket/src/mac/osx_appl.rkt I just pushed a fix for this. * racket/src/racket/gc/upgrade.rkt I think my push fixes this, but I can't figure out how to run this program, or if it's referenced anywhere. * racket/src/worksp/gc2/make.rkt * racket/src/worksp/mzcom/xform.rkt These both depend on `mzlib/restart`, which is non-trivial. Matthew, should I just move that back and let you work that out? Are these files critical now? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27030: master branch updated
At Thu, 27 Jun 2013 23:18:48 -0400, Sam Tobin-Hochstadt wrote: * racket/src/worksp/gc2/make.rkt * racket/src/worksp/mzcom/xform.rkt These both depend on `mzlib/restart`, which is non-trivial. Matthew, should I just move that back and let you work that out? Are these files critical now? Yes and yes. Thanks! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27030: master branch updated
On Thu, Jun 27, 2013 at 11:22 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 27 Jun 2013 23:18:48 -0400, Sam Tobin-Hochstadt wrote: * racket/src/worksp/gc2/make.rkt * racket/src/worksp/mzcom/xform.rkt These both depend on `mzlib/restart`, which is non-trivial. Matthew, should I just move that back and let you work that out? Are these files critical now? Yes and yes. Now moved back. Sorry about that one. Is there something I could run to check that it's working? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27030: master branch updated
At Thu, 27 Jun 2013 23:41:22 -0400, Sam Tobin-Hochstadt wrote: On Thu, Jun 27, 2013 at 11:22 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 27 Jun 2013 23:18:48 -0400, Sam Tobin-Hochstadt wrote: * racket/src/worksp/gc2/make.rkt * racket/src/worksp/mzcom/xform.rkt These both depend on `mzlib/restart`, which is non-trivial. Matthew, should I just move that back and let you work that out? Are these files critical now? Yes and yes. Now moved back. Sorry about that one. Is there something I could run to check that it's working? Not easily, but I'll try a Windows build soon to make sure that it works. _ 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
