Re: [racket-dev] Package compatibility
On Sun, Jul 7, 2013 at 11:44 AM, Carl Eastlund wrote: > It seems to me our new package system runs into trouble if two people write > packages that use the same connection name. Let's say we have two packages, > alice-tree and bob-tree, both of which provide the collection > data/red-black-tree, but both provide different interfaces (perhaps similar > functionality with different naming conventions). It seems to me this is > not that unlikely to happen, but once it does, those two packages are > completely incompatible. They can never meaningfully be installed on the > same system, and if they are, the behavior of any code depending on either > becomes undefined. > > Have I got this right, or have I missed some detail? You are correct. > If this is right, how > concerned are we about this feature? The fact that packages are all spliced > into a single flat collection namespace of course leads to the possibility > of clashes like this, which can cause not just incompatibility between > alice-tree and bob-tree, but a complete schism wherein all code depending on > alice-tree at any level of indirection becomes completely disjoint from all > code depending on bob-tree at any level of indirection. I've seen this kind > of library incompatibility before, in the ACL2 "books", and I wrote a > dissertation to try to solve it. I hope we're not repeating their mistake, > but it seems like we have yet another flat namespace with no resolution > mechanism. Planet attempts to solve this problem technically by (a) having all collections be prefixed by / and (b) mandating a centralized server that enforces unique s and unique s per author. Since Racket packages don't have a mandated central server we can't enforce uniqueness like that. (i.e. even if we mandated the prefix by , there's no way to enforce unique package names across the universe without a central server.) Furthermore, bringing s in to the code would give us /internal linking/ which Racket packages are designed to avoid for other reasons. Since technical solutions to this problem are lacking, I/we/PLT (depending on the level of agreement with this idea) are trying to solve this problem socially by rewarding package authors (who list their packages on the PLT run server) with the ring system. Ring 1 packages can't conflict with each other and my desire is for only ring 1 and 0 packages to be listed in the DrRacket GUI. Ring 0 packages can't conflict with each other and must be "good" (have documentation, tests, etc). The goodie they get is that their packages will be tested with DrDr and we'll build their documentation and include it on the main site. Jay > Carl Eastlund > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27106: master branch updated
At Sun, 7 Jul 2013 13:42:22 -0400, Sam Tobin-Hochstadt wrote: > On Sun, Jul 7, 2013 at 1:26 PM, wrote: > > > > | Finally, `racket/base' provides the new function > > | `call-with-default-reading-parameterization', which is used to guard > > | various file `read's to make them consistent and avoid security holes. > > It looks like `call-with-default-reading-parameterization` allows > reading compiled code. This seems potentially worrying in the contexts > where we're reading various package-related files. Yes, that was supposed to be off. I'll fix it. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Package compatibility
It seems to me our new package system runs into trouble if two people write packages that use the same connection name. Let's say we have two packages, alice-tree and bob-tree, both of which provide the collection data/red-black-tree, but both provide different interfaces (perhaps similar functionality with different naming conventions). It seems to me this is not that unlikely to happen, but once it does, those two packages are completely incompatible. They can never meaningfully be installed on the same system, and if they are, the behavior of any code depending on either becomes undefined. Have I got this right, or have I missed some detail? If this is right, how concerned are we about this feature? The fact that packages are all spliced into a single flat collection namespace of course leads to the possibility of clashes like this, which can cause not just incompatibility between alice-tree and bob-tree, but a complete schism wherein all code depending on alice-tree at any level of indirection becomes completely disjoint from all code depending on bob-tree at any level of indirection. I've seen this kind of library incompatibility before, in the ACL2 "books", and I wrote a dissertation to try to solve it. I hope we're not repeating their mistake, but it seems like we have yet another flat namespace with no resolution mechanism. Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27106: master branch updated
On Sun, Jul 7, 2013 at 1:26 PM, wrote: > > | Finally, `racket/base' provides the new function > | `call-with-default-reading-parameterization', which is used to guard > | various file `read's to make them consistent and avoid security holes. It looks like `call-with-default-reading-parameterization` allows reading compiled code. This seems potentially worrying in the contexts where we're reading various package-related files. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What command should DrDr run by default?
The change I made was the minimum delta to make the tests run in DrDr, since the files already had a `main` submodule which ran the actual tests. Sam On Sun, Jul 7, 2013 at 4:42 AM, Robby Findler wrote: > Raco test runs the file if there is not test sub module. Fwiw. > > > On Saturday, July 6, 2013, Eli Barzilay wrote: >> >> It doesn't make much sense to use a test submodule in files that are >> intended to be (only) tests. >> >> >> Earlier today, Robby Findler wrote: >> > That's the plan. Thanks for fixing them. >> > >> > Robby >> > >> > >> > On Sat, Jul 6, 2013 at 8:47 AM, Sam Tobin-Hochstadt >> > wrote: >> > >> > I recently discovered that DrDr runs `raco test` by default on >> > files, >> > and has since February. However, the DrDr documentation says that it >> > runs `racket -t`. I discovered this because the change caused many >> > of >> > the `net` tests to no longer actually run; see >> > >> > >> > http://drdr.racket-lang.org/27042/pkgs/racket-pkgs/racket-test/tests/ >> > net/url.rkt >> > >> > which appears to be successful, even though running `racket` on that >> > file would have shown the error that I fixed in >> > https://github.com/plt/racket/commit/a4e529a816 . These tests are a >> > particularly bad case because they run all their tests in the `main` >> > submodule, and thus are *not* executed by `raco test`. If the plan >> > is >> > for everything to run with `raco test`, I'll fix these tests. But >> > what is the plan? >> >> -- >> ((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] What command should DrDr run by default?
Raco test runs the file if there is not test sub module. Fwiw. On Saturday, July 6, 2013, Eli Barzilay wrote: > It doesn't make much sense to use a test submodule in files that are > intended to be (only) tests. > > > Earlier today, Robby Findler wrote: > > That's the plan. Thanks for fixing them. > > > > Robby > > > > > > On Sat, Jul 6, 2013 at 8:47 AM, Sam Tobin-Hochstadt > > > > wrote: > > > > I recently discovered that DrDr runs `raco test` by default on files, > > and has since February. However, the DrDr documentation says that it > > runs `racket -t`. I discovered this because the change caused many > of > > the `net` tests to no longer actually run; see > > > > > http://drdr.racket-lang.org/27042/pkgs/racket-pkgs/racket-test/tests/ > > net/url.rkt > > > > which appears to be successful, even though running `racket` on that > > file would have shown the error that I fixed in > > https://github.com/plt/racket/commit/a4e529a816 . These tests are a > > particularly bad case because they run all their tests in the `main` > > submodule, and thus are *not* executed by `raco test`. If the plan is > > for everything to run with `raco test`, I'll fix these tests. But > > what is the plan? > > -- > ((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
