[racket-dev] another Planet2 Express memo
Good news, everyone! I've improved the top-level makefile in a way that probably breaks your existing repo checkout. Then again, there's a chance that things will appear to work for now, delaying problems until sometime later. To avoid problems, delete racket/lib/links.rktd and racket/lib/pkgs. Read on if you care about the details. The default `make' target now recognizes the `PKGS' definition to select a set of packages from the pkgs directory to be linked for development mode. This lets you create a development-mode build using less than the full set of packages. For example, make PKGS=gui-lib creates a build that links only the package gui-lib and its dependencies. Formerly, since all packages from pkgs were always linked, `make' could update each existing link based on whether its package was still in place. That strategy doesn't work as well when only a subset of packages are meant to be installed and `PKGS' or dependencies can change --- especially when you install your own installation-wide links for other packages (e.g., sirmail, in my case). The new strategy is to keep all links installed by `make' in a separate installed-package database. When you run `make', it puts the database of package links in racket/lib/devel-pkgs, and it writes racket/etc/config.rktd to add suitable search paths. When you re-run `make', it throws away the old directory and recreates the set of links. Any other packages or links that you install in normal installation-wide mode are unaffected. When you run `raco pkg show' after a clean build, you'll see something like this: /racket/lib/devel-pkgs: Package[*=auto] ChecksumSource at-exp-lib* #f (link /pkgs/racket-pkgs/at-exp-lib) compatibility-lib* #f (link /pkgs/compatibility-lib) data-lib*#f (link /pkgs/data-lib) draw-lib*#f (link /pkgs/draw-pkgs/draw-lib) ... Installation-wide: [none] User-specific, all-version: [none] User-specific, version-specific (5.3.900.2): [none] which shows that the links are installed in a /racket/lib/devel-pkgs scope. If you start from an old build, then you're going to see something more like this: /racket/lib/devel-pkgs: Package[*=auto] ChecksumSource at-exp-lib* #f (link /pkgs/racket-pkgs/at-exp-lib) compatibility-lib* #f (link /pkgs/compatibility-lib) data-lib*#f (link /pkgs/data-lib) draw-lib*#f (link /pkgs/draw-pkgs/draw-lib) ... Installation-wide: at-exp-lib #f (link /pkgs/racket-pkgs/at-exp-lib) compatibility-lib#f (link /pkgs/compatibility-lib) data-lib #f (link /pkgs/data-lib) draw-lib #f (link /pkgs/draw-pkgs/draw-lib) User-specific, all-version: [none] User-specific, version-specific (5.3.900.2): [none] which shows that many packages are links in two different scopes. The Installation-wide scope takes precedence --- and that's fine until package move around long enough that the installation-scope links go bad, since they aren't updated anymore by `make'. So, remove all of the Installation-wide links, probably by deleting the file and directory as suggested near the top of this message. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] another Planet2 Express memo
A few minutes ago, Matthew Flatt wrote: To avoid problems, delete racket/lib/links.rktd and racket/lib/pkgs. [...] Quick note: a useful thing to know for such cases is git clean -dX -f which will make git remove all files that are ignored. Since the .gitignore files are all setup to list built stuff, it should leave you in a clean state with no pre-built stuff. It will not delete new files that are not ignored, so if there are new source files they will be kept. -- ((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] why raco exe gives a data file in SunOS?
I reported this bug here: http://bugs.racket-lang.org/query/?cmd=view%20audit-traildatabase=defaultpr=13852return_url=http%3A%2F%2Fbugs.racket-lang.org%2Fquery%2F%3Fdatabase%3Ddefault%3Bdebug%3D%3Bcmd%3Dsubmit%2520query%3BState%3Dany%3Bignoreclosed%3DIgnore%2520Closed%3BSynopsis%3Draco%2520exe%3Bmultitext%3D%3Bcolumns%3DState%3Bcolumns%3DSynopsis%3Bcolumns%3DCategory%3Bcolumns%3DLast-Modified%3Bcolumns%3DRelease%3Bsortby%3DNumber I use OpenIndiana rather than Oracle Solaris. Thanks. _ 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
[racket-dev] sgl collection
Is anybody maintaining the sgl (OpenGL) collection? I notice from the doc that it supports OpenGL 1.5; the current version appears to be 4.3 (although popular textbooks seem to use 3.x). Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
