Re: [racket-dev] odd error message in race setup
Its an example from the distributed places docs. I'll remove it. Kevin On 03/08/2012 06:00 PM, Robby Findler wrote: I think that the issue probably does not predate Kevin's recent push (distributed places). If you'd like to audit the push security concerns, I'm sure that'd be welcome. Robby On Thu, Mar 8, 2012 at 5:32 PM, Neil Van Dyke wrote: Robby Findler wrote at 03/08/2012 05:45 PM: Looks like something is trying to ssh while building the docs? Can whoever figures this out let the list know, or email me privately? Thanks. If it turns out that a use of SSH made it into a *released* version of Racket source, I might have to take a look at it, regardless of how legitimate it is. (Looks like something is trying to SSH, and "localhost"'s fingerprint disagrees with user's SSH "known_hosts". So might have been going on for a while, quietly, and only noticed now because of the unusual situation of the fingerprint being different. And noticed because someone was paying attention to the "raco setup" logs (if that indeed "raco setup" process was the source, rather than some other process that just had a handle for the stdio/terminal). I don't "grep" an obvious use of SSH in the 5.2.1 sources I'm using right now.) -- http://www.neilvandyke.org/ _ 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] odd error message in race setup
I think that the issue probably does not predate Kevin's recent push (distributed places). If you'd like to audit the push security concerns, I'm sure that'd be welcome. Robby On Thu, Mar 8, 2012 at 5:32 PM, Neil Van Dyke wrote: > Robby Findler wrote at 03/08/2012 05:45 PM: > >> Looks like something is trying to ssh while building the docs? > > > Can whoever figures this out let the list know, or email me privately? > Thanks. > > If it turns out that a use of SSH made it into a *released* version of > Racket source, I might have to take a look at it, regardless of how > legitimate it is. > > (Looks like something is trying to SSH, and "localhost"'s fingerprint > disagrees with user's SSH "known_hosts". So might have been going on for a > while, quietly, and only noticed now because of the unusual situation of the > fingerprint being different. And noticed because someone was paying > attention to the "raco setup" logs (if that indeed "raco setup" process was > the source, rather than some other process that just had a handle for the > stdio/terminal). I don't "grep" an obvious use of SSH in the 5.2.1 sources > I'm using right now.) > > -- > http://www.neilvandyke.org/ > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] odd error message in race setup
Probably mere coincidence, but GitHub has disclosed a security vulnerability of their service, which was exploited to target Rails developers and unnamed others: https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation Neil Van Dyke wrote at 03/08/2012 06:32 PM: Robby Findler wrote at 03/08/2012 05:45 PM: Looks like something is trying to ssh while building the docs? Can whoever figures this out let the list know, or email me privately? Thanks. If it turns out that a use of SSH made it into a *released* version of Racket source, I might have to take a look at it, regardless of how legitimate it is. (Looks like something is trying to SSH, and "localhost"'s fingerprint disagrees with user's SSH "known_hosts". So might have been going on for a while, quietly, and only noticed now because of the unusual situation of the fingerprint being different. And noticed because someone was paying attention to the "raco setup" logs (if that indeed "raco setup" process was the source, rather than some other process that just had a handle for the stdio/terminal). I don't "grep" an obvious use of SSH in the 5.2.1 sources I'm using right now.) -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] odd error message in race setup
Robby Findler wrote at 03/08/2012 05:45 PM: Looks like something is trying to ssh while building the docs? Can whoever figures this out let the list know, or email me privately? Thanks. If it turns out that a use of SSH made it into a *released* version of Racket source, I might have to take a look at it, regardless of how legitimate it is. (Looks like something is trying to SSH, and "localhost"'s fingerprint disagrees with user's SSH "known_hosts". So might have been going on for a while, quietly, and only noticed now because of the unusual situation of the fingerprint being different. And noticed because someone was paying attention to the "raco setup" logs (if that indeed "raco setup" process was the source, rather than some other process that just had a handle for the stdio/terminal). I don't "grep" an obvious use of SSH in the 5.2.1 sources I'm using right now.) -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] odd error message in race setup
Looks like something is trying to ssh while building the docs? Kevin? Robby On Thu, Mar 8, 2012 at 4:41 PM, Matthias Felleisen wrote: > > I compiled Git head a couple of hours ago and in the middle of my race setup > run I found these: > >> raco setup: 1 running: readline/readline.scrbl >> raco setup: 1 running: redex/redex.scrbl >> raco setup: 0 running: scribblings/reference/reference.scrbl >> The authenticity of host 'localhost (::1)' can't be established. >> RSA key fingerprint is 8d:f6:8e:2e:51:61:e7:9a:68:9f:d8:1c:34:82:79:e6. >> Are you sure you want to continue connecting (yes/no)? raco setup: 0 >> running: scribblings/scheme/scheme.scrbl >> raco setup: 0 running: scribblings/scribble/scribble.scrbl >> raco setup: 0 running: graphics/scribblings/graphics.scrbl >> raco setup: 0 running: graphics/scribblings/turtles.scrbl > > >> raco setup: 1 rendering: plot/scribblings/plot.scrbl >> raco setup: 0 rendering: scribblings/reference/reference.scrbl >> The authenticity of host 'localhost (::1)' can't be established. >> RSA key fingerprint is 8d:f6:8e:2e:51:61:e7:9a:68:9f:d8:1c:34:82:79:e6. >> Are you sure you want to continue connecting (yes/no)? raco setup: 0 >> rendering: scribblings/scheme/scheme.scrbl >> raco setup: 1 rendering: scribblings/scribble/scribble.scrbl >> raco setup: 0 rendering: graphics/scribblings/graphics.scrbl >> raco setup: 0 rendering: graphics/scribblings/turtles.scrbl >> raco setup: 0 rendering: net/scribblings/net.scrbl >> raco setup: 1 rendering: trace/scribblings/trace.scrbl >> raco setup: 1 rendering: file/scribblings/file.scrbl >> raco setup: 0 rendering: deinprogramm/scribblings/deinprogramm.scrbl > > >> raco setup: 0 re-rendering: scribblings/reference/reference.scrbl >> raco setup: 1 re-rendering: scribblings/scheme/scheme.scrbl >> raco setup: 1 re-rendering: net/scribblings/net.scrbl >> The authenticity of host 'localhost (::1)' can't be established. >> RSA key fingerprint is 8d:f6:8e:2e:51:61:e7:9a:68:9f:d8:1c:34:82:79:e6. >> Are you sure you want to continue connecting (yes/no)? raco setup: --- >> installing collections --- >> raco setup: --- post-installing collections --- >> raco setup: post-installing: help >> raco setup: post-installing: mred >> raco setup: post-installing: mzcom > > > I have never seen this before. Some left-over debugging code? -- Matthias > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] odd error message in race setup
I compiled Git head a couple of hours ago and in the middle of my race setup run I found these: > raco setup: 1 running: readline/readline.scrbl > raco setup: 1 running: redex/redex.scrbl > raco setup: 0 running: scribblings/reference/reference.scrbl > The authenticity of host 'localhost (::1)' can't be established. > RSA key fingerprint is 8d:f6:8e:2e:51:61:e7:9a:68:9f:d8:1c:34:82:79:e6. > Are you sure you want to continue connecting (yes/no)? raco setup: 0 running: > scribblings/scheme/scheme.scrbl > raco setup: 0 running: scribblings/scribble/scribble.scrbl > raco setup: 0 running: graphics/scribblings/graphics.scrbl > raco setup: 0 running: graphics/scribblings/turtles.scrbl > raco setup: 1 rendering: plot/scribblings/plot.scrbl > raco setup: 0 rendering: scribblings/reference/reference.scrbl > The authenticity of host 'localhost (::1)' can't be established. > RSA key fingerprint is 8d:f6:8e:2e:51:61:e7:9a:68:9f:d8:1c:34:82:79:e6. > Are you sure you want to continue connecting (yes/no)? raco setup: 0 > rendering: scribblings/scheme/scheme.scrbl > raco setup: 1 rendering: scribblings/scribble/scribble.scrbl > raco setup: 0 rendering: graphics/scribblings/graphics.scrbl > raco setup: 0 rendering: graphics/scribblings/turtles.scrbl > raco setup: 0 rendering: net/scribblings/net.scrbl > raco setup: 1 rendering: trace/scribblings/trace.scrbl > raco setup: 1 rendering: file/scribblings/file.scrbl > raco setup: 0 rendering: deinprogramm/scribblings/deinprogramm.scrbl > raco setup: 0 re-rendering: scribblings/reference/reference.scrbl > raco setup: 1 re-rendering: scribblings/scheme/scheme.scrbl > raco setup: 1 re-rendering: net/scribblings/net.scrbl > The authenticity of host 'localhost (::1)' can't be established. > RSA key fingerprint is 8d:f6:8e:2e:51:61:e7:9a:68:9f:d8:1c:34:82:79:e6. > Are you sure you want to continue connecting (yes/no)? raco setup: --- > installing collections --- > raco setup: --- post-installing collections --- > raco setup: post-installing: help > raco setup: post-installing: mred > raco setup: post-installing: mzcom I have never seen this before. Some left-over debugging code? -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
Nice -- just what I wished for last spring. -- Matthias On Mar 8, 2012, at 3:39 PM, Jay McCarthy wrote: > One more thing, I anticipate that the 'main' module in my "test.rkt" > will be "raco test" and I would extend it to allow you to give a > directory that it will require (if present) all the "test" modules. > You could also have "Test" button in DrRacket. > > Jay > > On Thu, Mar 8, 2012 at 1:29 PM, Jay McCarthy wrote: >> I've made a test collecting macro. >> >> https://gist.github.com/2003201 >> >> "test.rkt" gives you 'define-test' >> >> (define-test id e ...) >> >> will create a module named 'test' that can see you local bindings >> (like module* #f) at the end of the module that contains all the code >> in "e ...". In addition, you get the (id e ...) form that adds the >> given expressions to the test module. >> >> I expect most uses will look like: >> >> (require racket/test) >> (define-test test (require rackunit)) >> >> >> >> (define f ...) >> (test ... f tests ...) >> >> >> >> (define g ...) >> (test ... g tests ...) >> >> Jay >> >> On Wed, Mar 7, 2012 at 12:07 PM, Jay McCarthy wrote: >>> I love it---especially for the test collecting macro. >>> >>> I will try to write it and report back. >>> >>> Jay >>> >>> On Wed, Mar 7, 2012 at 10:14 AM, Matthew Flatt wrote: I've added "submodules" to a version of Racket labeled v5.2.900.1 that's here: https://github.com/mflatt/submodules After we've sorted out any controversial parts of the design and after the documentation is complete, then I'll be ready to merge to the main Racket repo. Why Submodules? --- Using submodules, you can abstract (via macros) over a set of modules that have distinct dynamic extents and/or bytecode load times. You can also get a private communication channel (via binding) from a module to its submodules. Some uses: * When you run a module via `racket', if it has a `main' submodule, then the `main' module is instantiated --- but not the `main' submodules of any other modules used by the starting module. This protocol is implemented for `racket', but not yet for DrRacket. * Languages with separate read-time, configure-time, and run-time code can be defined in a single module, with the configure-time and read-time code in submodules. * A testing macro could collect test cases and put them into a separate `test' submodule', so that testing code is not run or even loaded when the module is used normally. * An improved `scribble/srcdoc' can expose documentation through a submodule instead of through re-expansion hacks. * If you want to export certain of a module's bindings only to when explicitly requested (i.e., not when the module is `require'd normally), you can export the bindings from a submodule, instead. When I first started talking about these problems last summer, I called the solution sketch "facets" or "modulets", but the design has evolved into "submodules". Nesting `module' Given the term "submodule", the first thing that you're likely to try will work as expected: #lang racket/base (module zoo racket/base (provide tiger) (define tiger "Tony")) (require 'zoo) tiger Within `module', a module path of the form `(quote id)' refers to the submodule `id', if any. If there's no such submodule, then `(quote id)' refers to an interactively declared module, as before. Submodules can be nested. To access a submodule from outside the enclosing module, use the `submod' module path form: #lang racket/base (module zoo racket/base (module monkey-house racket/base (provide monkey) (define monkey "Curious George")) (displayln "Ticket, please")) (require (submod 'zoo monkey-house)) monkey The 'zoo module path above is really a shorthand for `(submod "." zoo)', where "." means the enclosing module and `zoo' is its submodule. You could write `(submod "." zoo monkey-house)' in place of `(submod 'zoo monkey-house)'. Note that `zoo' and `monkey-house' are not bound as identifiers in the module above --- just like `module' doesn't add any top-level bindings. The namespace of modules remains separate from the namespace of variables and syntax. Along those lines, submodules are not explicitly exported, because they are implicitly public. When you run the above program, "Ticket, please" is *not* displayed. Unless a module `require's a submodule, instantiating the module does not instantiate the submodule. Similarly, instantiating a submodule >
Re: [racket-dev] The Clark XML tests & licensing
I just committed a fix to this. Jay On Thu, Mar 8, 2012 at 12:06 PM, Jay McCarthy wrote: > I think we should just use the system 'unzip', since we currently on > test on platforms that have it anyways. DrDr has unzip and my machines > do (I maintain XML.) > > I am also at fault for this, so I can fix it. > > Jay > > > On 3/8/12, Matthew Flatt wrote: >> We have a `file/zip' library for creating ".zip" files, but we need a >> `file/unzip' library. It should be fairly easy to implement in terms of >> `inflate'. Maybe there's an implementation on Planet already? >> >> Also, there's a limited `unzip' in "scribble/lncs/lang.rkt", because I >> needed it to automatically download and unpack the LNCS style file. >> That's possibly a useful starting point, if no other is available. >> >> At Thu, 8 Mar 2012 11:30:23 -0600, Robby Findler wrote: >>> Oh, but I see that this doesn't actually create the files. Probably >>> something needs to be added to the library. >>> >>> Sorry. >>> >>> Robby >>> >>> On Thu, Mar 8, 2012 at 11:29 AM, Robby Findler >>> wrote: >>> > I think you want 'inflate'. IIUC, .zip files contain 'pkzip'-format >>> > compressed stuff. >>> > >>> > Robby >>> > >>> > On Thu, Mar 8, 2012 at 11:26 AM, Sam Tobin-Hochstadt >>> > >>> wrote: >>> >> On Thu, Mar 8, 2012 at 11:52 AM, Robby Findler >>> >> wrote: >>> >>> Doesn't file/gunzip do that? >>> >> >>> >> From the documentation, that seems to be about files that use gzip, >>> >> not zip. I didn't think they were the same, but I don't know much >>> >> about this stuff. >>> >> >>> >> Trying it, it doesn't seem to work: >>> >> >>> >> -> (gunzip "xmltest.zip") >>> >> ; gnu-unzip: bad header [,bt for context] >>> >> >>> >> >>> >>> On Thu, Mar 8, 2012 at 9:39 AM, Sam Tobin-Hochstadt >>> >>> >>> wrote: >>> Summary: we are currently violating the license of James Clark's XML >>> test suite, and should fix this. >>> >>> Currently, the `tests/xml' directory [1] contains a comprehensive >>> collection tests for XML parsing from James Clark [2]. The >>> readme.html file [3] in that directory states the license of that >>> test >>> suite: >>> >>> Copyright (C) 1998 James Clark. All rights reserved. Permission is >>> granted to copy and modify this collection in any way for internal >>> use >>> within a company or organization. Permission is granted to >>> redistribute the file xmltest.zip containing this >>> collection to third parties provided that no modifications of any >>> kind >>> are made to this file. Note that permission to distribute the >>> collection in any other form is not granted. >>> >>> See in particular the last sentence. We're clearly violating this >>> license, since we distribute the unzipped collection. We need to fix >>> this. >>> >>> Fortunately, this should be easy to fix. We need to do the >>> following: >>> >>> 1. Remove the 'clark-tests' directory. >>> 2. Add the 'xmltest.zip' file. >>> 3. Unzip the file on-demand when running the tests. >>> >>> Currently, we don't have a Racket interface to unzip files. We could >>> use the command-line 'unzip' tool, or write such an interface., or >>> perhaps someone's already written one. >>> >>> [1] >>> https://github.com/plt/racket/tree/master/collects/tests/xml/clark-tests >>> [2] ftp://ftp.jclark.com/pub/xml/xmltest.zip >>> [3] >>> https://github.com/plt/racket/blob/master/collects/tests/xml/clark-tests/readme. >>> html >>> -- >>> sam th >>> sa...@ccs.neu.edu >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >>> >> >>> >> >>> >> >>> >> -- >>> >> sam th >>> >> sa...@ccs.neu.edu >>> >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >> >> _ >> 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 -- 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] submodules
At Thu, 8 Mar 2012 15:41:38 -0500, Asumu Takikawa wrote: > This sounds great! I haven't tried it out yet, but here are some > preliminary comments. > > On 2012-03-07 10:14:35 -0700, Matthew Flatt wrote: > > Submodules declared with `module' are declared locally while expanding > > a module body, which means that the submodules can be `require'd > > afterward by the enclosing module. This ordering means, however, that > > the submodule cannot `require' the enclosing module. > > > > [...] > > > > The `module*' form is like `module', but it can be used only for > > submodules, and it defers the submodule's expansion until after the > > enclosing module is otherwise expanded. As a result, a submodule using > > `module*' can `require' its enclosing module, while the enclosing > > module cannot require the submodule. > > It seems to me that `module*` maybe actually be the common case for > submodules because most of the time I would expect that you want to use > the bindings of the enclosing module. This seems true for unit tests, > driver modules, documentation (requiring for-template), and so on. > > Would it make sense to swap the `module` and `module*` forms? That's how it was at first, but I didn't like how (module m racket/base) (require 'm) was completely different at the top level and within a module. Although the correspondence between `module' at the top level and within a `module' is only approximate, it makes things much easier to explain. It's also easier to explain that `#f' is allowed as the language of a `module*', which is always a submodule, and `#f' is never allowed as the language of `module'. (In fact, there was no nested `module' until the last few hours before my post. I had `module*' as `module', and it was starting to look difficult to explain... Realizing that nearly everything was in place to support nested `module' in addition to `module*' was my biggest "aha!" moment.) > Another aspect of the syntax that I foresee being annoying is that each > module nesting adds an additional indentation level. On the other hand, I > don't see any good alternative for this. I only bring this up because > this was problematic enough in the past to invent the #lang shorthand. I don't think that explicit `module' or `module*' forms will be that common. Instead, I expect that they'll mostly be generated by macros, such as a `main' macro or Jay's `define-test' macro. But if they become common, or if we often want to re-export an external module via a submodule, then we should revisit this point. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
On Thu, Mar 8, 2012 at 1:41 PM, Asumu Takikawa wrote: > Maybe a pattern that could avoid this is to have something like > > #lang racket/main > #:main "driver.rkt" > #:tests "tests.rkt" > > which would bring in the given modules (in the filesystem) as > submodules. That way you could define submodules separately but still > package them together in order to follow any protocols for documentation > or unit testing that come about with submodules. Is that implementable > with submodules? Yes. I just tested this idea. You could expand to: include.rkt: #lang racket/base (define (f x) 1) (module* test #f (require racket/include) (include "include-tests.rkt")) include-tests.rkt: (require rackunit) (check-equal? (f 1) 1) (check-equal? (f 3) 2) Although I personally don't like it as much :) Jay -- 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] submodules
This sounds great! I haven't tried it out yet, but here are some preliminary comments. On 2012-03-07 10:14:35 -0700, Matthew Flatt wrote: > Submodules declared with `module' are declared locally while expanding > a module body, which means that the submodules can be `require'd > afterward by the enclosing module. This ordering means, however, that > the submodule cannot `require' the enclosing module. > > [...] > > The `module*' form is like `module', but it can be used only for > submodules, and it defers the submodule's expansion until after the > enclosing module is otherwise expanded. As a result, a submodule using > `module*' can `require' its enclosing module, while the enclosing > module cannot require the submodule. It seems to me that `module*` maybe actually be the common case for submodules because most of the time I would expect that you want to use the bindings of the enclosing module. This seems true for unit tests, driver modules, documentation (requiring for-template), and so on. Would it make sense to swap the `module` and `module*` forms? *** Another aspect of the syntax that I foresee being annoying is that each module nesting adds an additional indentation level. On the other hand, I don't see any good alternative for this. I only bring this up because this was problematic enough in the past to invent the #lang shorthand. Maybe a pattern that could avoid this is to have something like #lang racket/main #:main "driver.rkt" #:tests "tests.rkt" which would bring in the given modules (in the filesystem) as submodules. That way you could define submodules separately but still package them together in order to follow any protocols for documentation or unit testing that come about with submodules. Is that implementable with submodules? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
One more thing, I anticipate that the 'main' module in my "test.rkt" will be "raco test" and I would extend it to allow you to give a directory that it will require (if present) all the "test" modules. You could also have "Test" button in DrRacket. Jay On Thu, Mar 8, 2012 at 1:29 PM, Jay McCarthy wrote: > I've made a test collecting macro. > > https://gist.github.com/2003201 > > "test.rkt" gives you 'define-test' > > (define-test id e ...) > > will create a module named 'test' that can see you local bindings > (like module* #f) at the end of the module that contains all the code > in "e ...". In addition, you get the (id e ...) form that adds the > given expressions to the test module. > > I expect most uses will look like: > > (require racket/test) > (define-test test (require rackunit)) > > > > (define f ...) > (test ... f tests ...) > > > > (define g ...) > (test ... g tests ...) > > Jay > > On Wed, Mar 7, 2012 at 12:07 PM, Jay McCarthy wrote: >> I love it---especially for the test collecting macro. >> >> I will try to write it and report back. >> >> Jay >> >> On Wed, Mar 7, 2012 at 10:14 AM, Matthew Flatt wrote: >>> I've added "submodules" to a version of Racket labeled v5.2.900.1 >>> that's here: >>> >>> https://github.com/mflatt/submodules >>> >>> After we've sorted out any controversial parts of the design and after >>> the documentation is complete, then I'll be ready to merge to the main >>> Racket repo. >>> >>> >>> Why Submodules? >>> --- >>> >>> Using submodules, you can abstract (via macros) over a set of modules >>> that have distinct dynamic extents and/or bytecode load times. You can >>> also get a private communication channel (via binding) from a module >>> to its submodules. >>> >>> Some uses: >>> >>> * When you run a module via `racket', if it has a `main' submodule, >>> then the `main' module is instantiated --- but not the `main' >>> submodules of any other modules used by the starting module. This >>> protocol is implemented for `racket', but not yet for DrRacket. >>> >>> * Languages with separate read-time, configure-time, and run-time >>> code can be defined in a single module, with the configure-time and >>> read-time code in submodules. >>> >>> * A testing macro could collect test cases and put them into a >>> separate `test' submodule', so that testing code is not run or even >>> loaded when the module is used normally. >>> >>> * An improved `scribble/srcdoc' can expose documentation through a >>> submodule instead of through re-expansion hacks. >>> >>> * If you want to export certain of a module's bindings only to when >>> explicitly requested (i.e., not when the module is `require'd >>> normally), you can export the bindings from a submodule, instead. >>> >>> When I first started talking about these problems last summer, I >>> called the solution sketch "facets" or "modulets", but the design >>> has evolved into "submodules". >>> >>> >>> Nesting `module' >>> >>> >>> Given the term "submodule", the first thing that you're likely to try >>> will work as expected: >>> >>> #lang racket/base >>> >>> (module zoo racket/base >>> (provide tiger) >>> (define tiger "Tony")) >>> >>> (require 'zoo) >>> >>> tiger >>> >>> Within `module', a module path of the form `(quote id)' refers to the >>> submodule `id', if any. If there's no such submodule, then `(quote >>> id)' refers to an interactively declared module, as before. >>> >>> Submodules can be nested. To access a submodule from outside the >>> enclosing module, use the `submod' module path form: >>> >>> #lang racket/base >>> >>> (module zoo racket/base >>> (module monkey-house racket/base >>> (provide monkey) >>> (define monkey "Curious George")) >>> (displayln "Ticket, please")) >>> >>> (require (submod 'zoo monkey-house)) >>> >>> monkey >>> >>> The 'zoo module path above is really a shorthand for `(submod "." >>> zoo)', where "." means the enclosing module and `zoo' is its >>> submodule. You could write `(submod "." zoo monkey-house)' in >>> place of `(submod 'zoo monkey-house)'. >>> >>> Note that `zoo' and `monkey-house' are not bound as identifiers in the >>> module above --- just like `module' doesn't add any top-level >>> bindings. The namespace of modules remains separate from the namespace >>> of variables and syntax. Along those lines, submodules are not >>> explicitly exported, because they are implicitly public. >>> >>> When you run the above program, "Ticket, please" is *not* displayed. >>> Unless a module `require's a submodule, instantiating the module does >>> not instantiate the submodule. Similarly, instantiating a submodule >>> does not imply instantiating its enclosing module. >>> >>> Furthermore, if you compile the above example to bytecode and run it, >>> the bytecode for `zoo' is not loaded. Only the bytecode for the >>> top-level module and `monkey-house' is loaded. >>> >>> >>> Nesting `module*' >>> ---
Re: [racket-dev] submodules
I've made a test collecting macro. https://gist.github.com/2003201 "test.rkt" gives you 'define-test' (define-test id e ...) will create a module named 'test' that can see you local bindings (like module* #f) at the end of the module that contains all the code in "e ...". In addition, you get the (id e ...) form that adds the given expressions to the test module. I expect most uses will look like: (require racket/test) (define-test test (require rackunit)) (define f ...) (test ... f tests ...) (define g ...) (test ... g tests ...) Jay On Wed, Mar 7, 2012 at 12:07 PM, Jay McCarthy wrote: > I love it---especially for the test collecting macro. > > I will try to write it and report back. > > Jay > > On Wed, Mar 7, 2012 at 10:14 AM, Matthew Flatt wrote: >> I've added "submodules" to a version of Racket labeled v5.2.900.1 >> that's here: >> >> https://github.com/mflatt/submodules >> >> After we've sorted out any controversial parts of the design and after >> the documentation is complete, then I'll be ready to merge to the main >> Racket repo. >> >> >> Why Submodules? >> --- >> >> Using submodules, you can abstract (via macros) over a set of modules >> that have distinct dynamic extents and/or bytecode load times. You can >> also get a private communication channel (via binding) from a module >> to its submodules. >> >> Some uses: >> >> * When you run a module via `racket', if it has a `main' submodule, >> then the `main' module is instantiated --- but not the `main' >> submodules of any other modules used by the starting module. This >> protocol is implemented for `racket', but not yet for DrRacket. >> >> * Languages with separate read-time, configure-time, and run-time >> code can be defined in a single module, with the configure-time and >> read-time code in submodules. >> >> * A testing macro could collect test cases and put them into a >> separate `test' submodule', so that testing code is not run or even >> loaded when the module is used normally. >> >> * An improved `scribble/srcdoc' can expose documentation through a >> submodule instead of through re-expansion hacks. >> >> * If you want to export certain of a module's bindings only to when >> explicitly requested (i.e., not when the module is `require'd >> normally), you can export the bindings from a submodule, instead. >> >> When I first started talking about these problems last summer, I >> called the solution sketch "facets" or "modulets", but the design >> has evolved into "submodules". >> >> >> Nesting `module' >> >> >> Given the term "submodule", the first thing that you're likely to try >> will work as expected: >> >> #lang racket/base >> >> (module zoo racket/base >> (provide tiger) >> (define tiger "Tony")) >> >> (require 'zoo) >> >> tiger >> >> Within `module', a module path of the form `(quote id)' refers to the >> submodule `id', if any. If there's no such submodule, then `(quote >> id)' refers to an interactively declared module, as before. >> >> Submodules can be nested. To access a submodule from outside the >> enclosing module, use the `submod' module path form: >> >> #lang racket/base >> >> (module zoo racket/base >> (module monkey-house racket/base >> (provide monkey) >> (define monkey "Curious George")) >> (displayln "Ticket, please")) >> >> (require (submod 'zoo monkey-house)) >> >> monkey >> >> The 'zoo module path above is really a shorthand for `(submod "." >> zoo)', where "." means the enclosing module and `zoo' is its >> submodule. You could write `(submod "." zoo monkey-house)' in >> place of `(submod 'zoo monkey-house)'. >> >> Note that `zoo' and `monkey-house' are not bound as identifiers in the >> module above --- just like `module' doesn't add any top-level >> bindings. The namespace of modules remains separate from the namespace >> of variables and syntax. Along those lines, submodules are not >> explicitly exported, because they are implicitly public. >> >> When you run the above program, "Ticket, please" is *not* displayed. >> Unless a module `require's a submodule, instantiating the module does >> not instantiate the submodule. Similarly, instantiating a submodule >> does not imply instantiating its enclosing module. >> >> Furthermore, if you compile the above example to bytecode and run it, >> the bytecode for `zoo' is not loaded. Only the bytecode for the >> top-level module and `monkey-house' is loaded. >> >> >> Nesting `module*' >> - >> >> Submodules declared with `module' are declared locally while expanding >> a module body, which means that the submodules can be `require'd >> afterward by the enclosing module. This ordering means, however, that >> the submodule cannot `require' the enclosing module. The submodule >> also sees no bindings of the enclosing module; it starts with an empty >> lexical context. >> >> The `module*' form is like `module', but it can be used only for >> submodule
Re: [racket-dev] The Clark XML tests & licensing
I think we should just use the system 'unzip', since we currently on test on platforms that have it anyways. DrDr has unzip and my machines do (I maintain XML.) I am also at fault for this, so I can fix it. Jay On 3/8/12, Matthew Flatt wrote: > We have a `file/zip' library for creating ".zip" files, but we need a > `file/unzip' library. It should be fairly easy to implement in terms of > `inflate'. Maybe there's an implementation on Planet already? > > Also, there's a limited `unzip' in "scribble/lncs/lang.rkt", because I > needed it to automatically download and unpack the LNCS style file. > That's possibly a useful starting point, if no other is available. > > At Thu, 8 Mar 2012 11:30:23 -0600, Robby Findler wrote: >> Oh, but I see that this doesn't actually create the files. Probably >> something needs to be added to the library. >> >> Sorry. >> >> Robby >> >> On Thu, Mar 8, 2012 at 11:29 AM, Robby Findler >> wrote: >> > I think you want 'inflate'. IIUC, .zip files contain 'pkzip'-format >> > compressed stuff. >> > >> > Robby >> > >> > On Thu, Mar 8, 2012 at 11:26 AM, Sam Tobin-Hochstadt >> > >> wrote: >> >> On Thu, Mar 8, 2012 at 11:52 AM, Robby Findler >> >> wrote: >> >>> Doesn't file/gunzip do that? >> >> >> >> From the documentation, that seems to be about files that use gzip, >> >> not zip. I didn't think they were the same, but I don't know much >> >> about this stuff. >> >> >> >> Trying it, it doesn't seem to work: >> >> >> >> -> (gunzip "xmltest.zip") >> >> ; gnu-unzip: bad header [,bt for context] >> >> >> >> >> >>> On Thu, Mar 8, 2012 at 9:39 AM, Sam Tobin-Hochstadt >> >>> >> wrote: >> Summary: we are currently violating the license of James Clark's XML >> test suite, and should fix this. >> >> Currently, the `tests/xml' directory [1] contains a comprehensive >> collection tests for XML parsing from James Clark [2]. The >> readme.html file [3] in that directory states the license of that >> test >> suite: >> >> Copyright (C) 1998 James Clark. All rights reserved. Permission is >> granted to copy and modify this collection in any way for internal >> use >> within a company or organization. Permission is granted to >> redistribute the file xmltest.zip containing this >> collection to third parties provided that no modifications of any >> kind >> are made to this file. Note that permission to distribute the >> collection in any other form is not granted. >> >> See in particular the last sentence. We're clearly violating this >> license, since we distribute the unzipped collection. We need to fix >> this. >> >> Fortunately, this should be easy to fix. We need to do the >> following: >> >> 1. Remove the 'clark-tests' directory. >> 2. Add the 'xmltest.zip' file. >> 3. Unzip the file on-demand when running the tests. >> >> Currently, we don't have a Racket interface to unzip files. We could >> use the command-line 'unzip' tool, or write such an interface., or >> perhaps someone's already written one. >> >> [1] >> https://github.com/plt/racket/tree/master/collects/tests/xml/clark-tests >> [2] ftp://ftp.jclark.com/pub/xml/xmltest.zip >> [3] >> https://github.com/plt/racket/blob/master/collects/tests/xml/clark-tests/readme. >> html >> -- >> sam th >> sa...@ccs.neu.edu >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev >> >> >> >> >> >> >> >> -- >> >> sam th >> >> sa...@ccs.neu.edu >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > _ > 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] The Clark XML tests & licensing
We have a `file/zip' library for creating ".zip" files, but we need a `file/unzip' library. It should be fairly easy to implement in terms of `inflate'. Maybe there's an implementation on Planet already? Also, there's a limited `unzip' in "scribble/lncs/lang.rkt", because I needed it to automatically download and unpack the LNCS style file. That's possibly a useful starting point, if no other is available. At Thu, 8 Mar 2012 11:30:23 -0600, Robby Findler wrote: > Oh, but I see that this doesn't actually create the files. Probably > something needs to be added to the library. > > Sorry. > > Robby > > On Thu, Mar 8, 2012 at 11:29 AM, Robby Findler > wrote: > > I think you want 'inflate'. IIUC, .zip files contain 'pkzip'-format > > compressed stuff. > > > > Robby > > > > On Thu, Mar 8, 2012 at 11:26 AM, Sam Tobin-Hochstadt > wrote: > >> On Thu, Mar 8, 2012 at 11:52 AM, Robby Findler > >> wrote: > >>> Doesn't file/gunzip do that? > >> > >> From the documentation, that seems to be about files that use gzip, > >> not zip. I didn't think they were the same, but I don't know much > >> about this stuff. > >> > >> Trying it, it doesn't seem to work: > >> > >> -> (gunzip "xmltest.zip") > >> ; gnu-unzip: bad header [,bt for context] > >> > >> > >>> On Thu, Mar 8, 2012 at 9:39 AM, Sam Tobin-Hochstadt > wrote: > Summary: we are currently violating the license of James Clark's XML > test suite, and should fix this. > > Currently, the `tests/xml' directory [1] contains a comprehensive > collection tests for XML parsing from James Clark [2]. The > readme.html file [3] in that directory states the license of that test > suite: > > Copyright (C) 1998 James Clark. All rights reserved. Permission is > granted to copy and modify this collection in any way for internal use > within a company or organization. Permission is granted to > redistribute the file xmltest.zip containing this > collection to third parties provided that no modifications of any kind > are made to this file. Note that permission to distribute the > collection in any other form is not granted. > > See in particular the last sentence. We're clearly violating this > license, since we distribute the unzipped collection. We need to fix > this. > > Fortunately, this should be easy to fix. We need to do the following: > > 1. Remove the 'clark-tests' directory. > 2. Add the 'xmltest.zip' file. > 3. Unzip the file on-demand when running the tests. > > Currently, we don't have a Racket interface to unzip files. We could > use the command-line 'unzip' tool, or write such an interface., or > perhaps someone's already written one. > > [1] > https://github.com/plt/racket/tree/master/collects/tests/xml/clark-tests > [2] ftp://ftp.jclark.com/pub/xml/xmltest.zip > [3] > https://github.com/plt/racket/blob/master/collects/tests/xml/clark-tests/readme. > html > -- > sam th > sa...@ccs.neu.edu > _ > Racket Developers list: > http://lists.racket-lang.org/dev > >> > >> > >> > >> -- > >> sam th > >> sa...@ccs.neu.edu > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] The Clark XML tests & licensing
Oh, but I see that this doesn't actually create the files. Probably something needs to be added to the library. Sorry. Robby On Thu, Mar 8, 2012 at 11:29 AM, Robby Findler wrote: > I think you want 'inflate'. IIUC, .zip files contain 'pkzip'-format > compressed stuff. > > Robby > > On Thu, Mar 8, 2012 at 11:26 AM, Sam Tobin-Hochstadt > wrote: >> On Thu, Mar 8, 2012 at 11:52 AM, Robby Findler >> wrote: >>> Doesn't file/gunzip do that? >> >> From the documentation, that seems to be about files that use gzip, >> not zip. I didn't think they were the same, but I don't know much >> about this stuff. >> >> Trying it, it doesn't seem to work: >> >> -> (gunzip "xmltest.zip") >> ; gnu-unzip: bad header [,bt for context] >> >> >>> On Thu, Mar 8, 2012 at 9:39 AM, Sam Tobin-Hochstadt >>> wrote: Summary: we are currently violating the license of James Clark's XML test suite, and should fix this. Currently, the `tests/xml' directory [1] contains a comprehensive collection tests for XML parsing from James Clark [2]. The readme.html file [3] in that directory states the license of that test suite: Copyright (C) 1998 James Clark. All rights reserved. Permission is granted to copy and modify this collection in any way for internal use within a company or organization. Permission is granted to redistribute the file xmltest.zip containing this collection to third parties provided that no modifications of any kind are made to this file. Note that permission to distribute the collection in any other form is not granted. See in particular the last sentence. We're clearly violating this license, since we distribute the unzipped collection. We need to fix this. Fortunately, this should be easy to fix. We need to do the following: 1. Remove the 'clark-tests' directory. 2. Add the 'xmltest.zip' file. 3. Unzip the file on-demand when running the tests. Currently, we don't have a Racket interface to unzip files. We could use the command-line 'unzip' tool, or write such an interface., or perhaps someone's already written one. [1] https://github.com/plt/racket/tree/master/collects/tests/xml/clark-tests [2] ftp://ftp.jclark.com/pub/xml/xmltest.zip [3] https://github.com/plt/racket/blob/master/collects/tests/xml/clark-tests/readme.html -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev >> >> >> >> -- >> sam th >> sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] The Clark XML tests & licensing
I think you want 'inflate'. IIUC, .zip files contain 'pkzip'-format compressed stuff. Robby On Thu, Mar 8, 2012 at 11:26 AM, Sam Tobin-Hochstadt wrote: > On Thu, Mar 8, 2012 at 11:52 AM, Robby Findler > wrote: >> Doesn't file/gunzip do that? > > From the documentation, that seems to be about files that use gzip, > not zip. I didn't think they were the same, but I don't know much > about this stuff. > > Trying it, it doesn't seem to work: > > -> (gunzip "xmltest.zip") > ; gnu-unzip: bad header [,bt for context] > > >> On Thu, Mar 8, 2012 at 9:39 AM, Sam Tobin-Hochstadt >> wrote: >>> Summary: we are currently violating the license of James Clark's XML >>> test suite, and should fix this. >>> >>> Currently, the `tests/xml' directory [1] contains a comprehensive >>> collection tests for XML parsing from James Clark [2]. The >>> readme.html file [3] in that directory states the license of that test >>> suite: >>> >>> Copyright (C) 1998 James Clark. All rights reserved. Permission is >>> granted to copy and modify this collection in any way for internal use >>> within a company or organization. Permission is granted to >>> redistribute the file xmltest.zip containing this >>> collection to third parties provided that no modifications of any kind >>> are made to this file. Note that permission to distribute the >>> collection in any other form is not granted. >>> >>> See in particular the last sentence. We're clearly violating this >>> license, since we distribute the unzipped collection. We need to fix >>> this. >>> >>> Fortunately, this should be easy to fix. We need to do the following: >>> >>> 1. Remove the 'clark-tests' directory. >>> 2. Add the 'xmltest.zip' file. >>> 3. Unzip the file on-demand when running the tests. >>> >>> Currently, we don't have a Racket interface to unzip files. We could >>> use the command-line 'unzip' tool, or write such an interface., or >>> perhaps someone's already written one. >>> >>> [1] https://github.com/plt/racket/tree/master/collects/tests/xml/clark-tests >>> [2] ftp://ftp.jclark.com/pub/xml/xmltest.zip >>> [3] >>> https://github.com/plt/racket/blob/master/collects/tests/xml/clark-tests/readme.html >>> -- >>> sam th >>> sa...@ccs.neu.edu >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev > > > > -- > sam th > sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] The Clark XML tests & licensing
On Thu, Mar 8, 2012 at 11:52 AM, Robby Findler wrote: > Doesn't file/gunzip do that? From the documentation, that seems to be about files that use gzip, not zip. I didn't think they were the same, but I don't know much about this stuff. Trying it, it doesn't seem to work: -> (gunzip "xmltest.zip") ; gnu-unzip: bad header [,bt for context] > On Thu, Mar 8, 2012 at 9:39 AM, Sam Tobin-Hochstadt wrote: >> Summary: we are currently violating the license of James Clark's XML >> test suite, and should fix this. >> >> Currently, the `tests/xml' directory [1] contains a comprehensive >> collection tests for XML parsing from James Clark [2]. The >> readme.html file [3] in that directory states the license of that test >> suite: >> >> Copyright (C) 1998 James Clark. All rights reserved. Permission is >> granted to copy and modify this collection in any way for internal use >> within a company or organization. Permission is granted to >> redistribute the file xmltest.zip containing this >> collection to third parties provided that no modifications of any kind >> are made to this file. Note that permission to distribute the >> collection in any other form is not granted. >> >> See in particular the last sentence. We're clearly violating this >> license, since we distribute the unzipped collection. We need to fix >> this. >> >> Fortunately, this should be easy to fix. We need to do the following: >> >> 1. Remove the 'clark-tests' directory. >> 2. Add the 'xmltest.zip' file. >> 3. Unzip the file on-demand when running the tests. >> >> Currently, we don't have a Racket interface to unzip files. We could >> use the command-line 'unzip' tool, or write such an interface., or >> perhaps someone's already written one. >> >> [1] https://github.com/plt/racket/tree/master/collects/tests/xml/clark-tests >> [2] ftp://ftp.jclark.com/pub/xml/xmltest.zip >> [3] >> https://github.com/plt/racket/blob/master/collects/tests/xml/clark-tests/readme.html >> -- >> sam th >> sa...@ccs.neu.edu >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] The Clark XML tests & licensing
Doesn't file/gunzip do that? On Thu, Mar 8, 2012 at 9:39 AM, Sam Tobin-Hochstadt wrote: > Summary: we are currently violating the license of James Clark's XML > test suite, and should fix this. > > Currently, the `tests/xml' directory [1] contains a comprehensive > collection tests for XML parsing from James Clark [2]. The > readme.html file [3] in that directory states the license of that test > suite: > > Copyright (C) 1998 James Clark. All rights reserved. Permission is > granted to copy and modify this collection in any way for internal use > within a company or organization. Permission is granted to > redistribute the file xmltest.zip containing this > collection to third parties provided that no modifications of any kind > are made to this file. Note that permission to distribute the > collection in any other form is not granted. > > See in particular the last sentence. We're clearly violating this > license, since we distribute the unzipped collection. We need to fix > this. > > Fortunately, this should be easy to fix. We need to do the following: > > 1. Remove the 'clark-tests' directory. > 2. Add the 'xmltest.zip' file. > 3. Unzip the file on-demand when running the tests. > > Currently, we don't have a Racket interface to unzip files. We could > use the command-line 'unzip' tool, or write such an interface., or > perhaps someone's already written one. > > [1] https://github.com/plt/racket/tree/master/collects/tests/xml/clark-tests > [2] ftp://ftp.jclark.com/pub/xml/xmltest.zip > [3] > https://github.com/plt/racket/blob/master/collects/tests/xml/clark-tests/readme.html > -- > sam th > sa...@ccs.neu.edu > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] The Clark XML tests & licensing
Summary: we are currently violating the license of James Clark's XML test suite, and should fix this. Currently, the `tests/xml' directory [1] contains a comprehensive collection tests for XML parsing from James Clark [2]. The readme.html file [3] in that directory states the license of that test suite: Copyright (C) 1998 James Clark. All rights reserved. Permission is granted to copy and modify this collection in any way for internal use within a company or organization. Permission is granted to redistribute the file xmltest.zip containing this collection to third parties provided that no modifications of any kind are made to this file. Note that permission to distribute the collection in any other form is not granted. See in particular the last sentence. We're clearly violating this license, since we distribute the unzipped collection. We need to fix this. Fortunately, this should be easy to fix. We need to do the following: 1. Remove the 'clark-tests' directory. 2. Add the 'xmltest.zip' file. 3. Unzip the file on-demand when running the tests. Currently, we don't have a Racket interface to unzip files. We could use the command-line 'unzip' tool, or write such an interface., or perhaps someone's already written one. [1] https://github.com/plt/racket/tree/master/collects/tests/xml/clark-tests [2] ftp://ftp.jclark.com/pub/xml/xmltest.zip [3] https://github.com/plt/racket/blob/master/collects/tests/xml/clark-tests/readme.html -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
