[racket-dev] Release for v6.0 is about to begin
The release process for v6.0 will begin in about a week. If you have any new features that you want in and are relatively close to being done, now is a good time to do that. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] `collection-path' Considered Brittle
While looking at Asumu's `raco-find-collection' package, Asumu and I noticed something about the `collection-path' function that made us uncomfortable. `collection-path' returns *a* path where the given collection is located. With the package system, there can now be *multiple* such paths. `collection-path' returns the first one (in alphabetical order of package name, at first glance). This means that installing a package that extends collection `foo' can break code that uses `(collection-path foo)'. For an example that's currently broken, what used to be an arrow in the macro stepper window is now a box with an X in it. The macro stepper looks for that arrow in the `icons' collection, which is now split between two packages. `collection-path' returns the path from the package that doesn't contain that arrow. A solution would be to provide a `collection-paths' function, that returns *all* the relevant paths, and add a big warning to the documentation of `collection-path'. A `collection-paths' function already exists in `pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt'. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `collection-path' Considered Brittle
collection-path is legacy and should generally be removed when you find it (I think I fixed two uses of it Saturday in fact). But hopefully you could use collection-file-path in most cases instead of a collections-path function. Robby On Mon, Nov 4, 2013 at 11:45 AM, Vincent St-Amour stamo...@ccs.neu.eduwrote: While looking at Asumu's `raco-find-collection' package, Asumu and I noticed something about the `collection-path' function that made us uncomfortable. `collection-path' returns *a* path where the given collection is located. With the package system, there can now be *multiple* such paths. `collection-path' returns the first one (in alphabetical order of package name, at first glance). This means that installing a package that extends collection `foo' can break code that uses `(collection-path foo)'. For an example that's currently broken, what used to be an arrow in the macro stepper window is now a box with an X in it. The macro stepper looks for that arrow in the `icons' collection, which is now split between two packages. `collection-path' returns the path from the package that doesn't contain that arrow. A solution would be to provide a `collection-paths' function, that returns *all* the relevant paths, and add a big warning to the documentation of `collection-path'. A `collection-paths' function already exists in `pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt'. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `collection-path' Considered Brittle
On 2013-11-04 11:49:44 -0600, Robby Findler wrote: collection-path is legacy and should generally be removed when you find it (I think I fixed two uses of it Saturday in fact). But hopefully you could use collection-file-path in most cases instead of a collections-path function. There are still some cases where you may want a `collection-paths` function instead though. For example, it would be useful for `raco-find-collection` so that when a user asks for `typed-racket`, it can pick a better default than the alphabetic ordering. (right now you have to ask for `typed-racket/core` to disambiguate, which corresponds to using `collection-file-path`) For my purposes, I could just copy+paste the code in the compiler-lib, but maybe it should be moved into the core? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `collection-path' Considered Brittle
At Mon, 4 Nov 2013 11:49:44 -0600, Robby Findler wrote: collection-path is legacy and should generally be removed when you find it (I think I fixed two uses of it Saturday in fact). The documentation does mention that `collection-file-path' is usually preferred, but it doesn't make it clear that `collection-path' is legacy. I'll think of a stronger wording. But hopefully you could use collection-file-path in most cases instead of a collections-path function. I pushed a fix for the macro stepper, using `collections-file-path'. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `collection-path' Considered Brittle
You should check out raco test for collection-paths: https://github.com/plt/racket/blob/master/pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt#L168 On Mon, Nov 4, 2013 at 12:56 PM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Mon, 4 Nov 2013 11:49:44 -0600, Robby Findler wrote: collection-path is legacy and should generally be removed when you find it (I think I fixed two uses of it Saturday in fact). The documentation does mention that `collection-file-path' is usually preferred, but it doesn't make it clear that `collection-path' is legacy. I'll think of a stronger wording. But hopefully you could use collection-file-path in most cases instead of a collections-path function. I pushed a fix for the macro stepper, using `collections-file-path'. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `collection-path' Considered Brittle
On Mon, Nov 4, 2013 at 1:56 PM, Vincent St-Amour stamo...@ccs.neu.eduwrote: At Mon, 4 Nov 2013 11:49:44 -0600, Robby Findler wrote: collection-path is legacy and should generally be removed when you find it (I think I fixed two uses of it Saturday in fact). The documentation does mention that `collection-file-path' is usually preferred, but it doesn't make it clear that `collection-path' is legacy. I'll think of a stronger wording. Thanks! Robby _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Slideshow package needs more splitting
I've been working on a package of different pict transformers/constructors I've made while giving slideshow presentations, with some pain. In particular, slideshow-lib pulls in the gui dependency, making documentation impossible. I had to just copy the code for slide-pict and fast-start from slideshow/play into my package, which I really hate doing. If at all possible, can we split the pict-only parts of slideshow-lib into a different collection, say slideshow-pict-lib or something? Or perhaps just add more to pict-pkgs? Thanks, -Ian _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Slideshow package needs more splitting
I think there might be some collection/pkg confusion here. Are you having trouble with a package level dependency or a collection level one? (The latter is the only kind that can lead to the documentation error you're talking about I believe.) Robby On Mon, Nov 4, 2013 at 4:51 PM, J. Ian Johnson i...@ccs.neu.edu wrote: I've been working on a package of different pict transformers/constructors I've made while giving slideshow presentations, with some pain. In particular, slideshow-lib pulls in the gui dependency, making documentation impossible. I had to just copy the code for slide-pict and fast-start from slideshow/play into my package, which I really hate doing. If at all possible, can we split the pict-only parts of slideshow-lib into a different collection, say slideshow-pict-lib or something? Or perhaps just add more to pict-pkgs? Thanks, -Ian _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Slideshow package needs more splitting
Mm, I believe it's collection-level. Perhaps if play.rkt were split into anim.rkt and play.rkt, where anim.rkt has all the non-gui code, and play.rkt has the gui code. Requiring slideshow/play in my library caused the doc failure. -Ian - Original Message - From: Robby Findler ro...@eecs.northwestern.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: dev dev@racket-lang.org Sent: Monday, November 4, 2013 5:58:36 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Slideshow package needs more splitting I think there might be some collection/pkg confusion here. Are you having trouble with a package level dependency or a collection level one? (The latter is the only kind that can lead to the documentation error you're talking about I believe.) Robby On Mon, Nov 4, 2013 at 4:51 PM, J. Ian Johnson i...@ccs.neu.edu wrote: I've been working on a package of different pict transformers/constructors I've made while giving slideshow presentations, with some pain. In particular, slideshow-lib pulls in the gui dependency, making documentation impossible. I had to just copy the code for slide-pict and fast-start from slideshow/play into my package, which I really hate doing. If at all possible, can we split the pict-only parts of slideshow-lib into a different collection, say slideshow-pict-lib or something? Or perhaps just add more to pict-pkgs? Thanks, -Ian _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Slideshow package needs more splitting
I guess probably everything except play, play-n, and animate-slide could be split out. Would that have helped you? Robby On Mon, Nov 4, 2013 at 5:14 PM, J. Ian Johnson i...@ccs.neu.edu wrote: Mm, I believe it's collection-level. Perhaps if play.rkt were split into anim.rkt and play.rkt, where anim.rkt has all the non-gui code, and play.rkt has the gui code. Requiring slideshow/play in my library caused the doc failure. -Ian - Original Message - From: Robby Findler ro...@eecs.northwestern.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: dev dev@racket-lang.org Sent: Monday, November 4, 2013 5:58:36 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Slideshow package needs more splitting I think there might be some collection/pkg confusion here. Are you having trouble with a package level dependency or a collection level one? (The latter is the only kind that can lead to the documentation error you're talking about I believe.) Robby On Mon, Nov 4, 2013 at 4:51 PM, J. Ian Johnson i...@ccs.neu.edu wrote: I've been working on a package of different pict transformers/constructors I've made while giving slideshow presentations, with some pain. In particular, slideshow-lib pulls in the gui dependency, making documentation impossible. I had to just copy the code for slide-pict and fast-start from slideshow/play into my package, which I really hate doing. If at all possible, can we split the pict-only parts of slideshow-lib into a different collection, say slideshow-pict-lib or something? Or perhaps just add more to pict-pkgs? Thanks, -Ian _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release for v6.0 is about to begin
Could you please make the regular expression syntax more elegant? To replace the with // or any other character as its boundary. Here is the example: #px/^\s*\/([^\/])\/\s*$/ === #px@^\s*/([^/])/\s*$@ === #px^\\s*/([^/])/\\s*$ Thank you in advance. On Tue, Nov 5, 2013 at 12:51 AM, Ryan Culpepper ry...@ccs.neu.edu wrote: The release process for v6.0 will begin in about a week. If you have any new features that you want in and are relatively close to being done, now is a good time to do that. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
