Re: [racket-dev] Pre-Release Checklist for v5.1
Two hours ago, Eli Barzilay wrote: > > Seems like there's a bigger problem -- on linux the games dialog > doesn't have the icons on the game buttons. If I run the following on windows it works, but on linux (I tried three different setups) I get the label without the bitmap. #lang racket/gui (define f (new frame% [label "Foo"])) (new button% [label (list (read-bitmap (build-path (collection-path "games/mines") "mines.png")) "Foo" 'left)] [parent f]) (send f show #t) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
On Tue, Feb 1, 2011 at 6:39 PM, Eli Barzilay wrote: > Four minutes ago, Robby Findler wrote: >> Oh -- but I did notice that the lambda cube game does not work; when >> you move your mouse over the left hand set of thingies, then turn >> black and never turn colored again. > > Oh, right -- I completely forgot about it. I'll see if I can do a > quick fix. (It uses a xor as a cheap highlighting hack, which is no > longer in gr2.) Making it come back when you mouse away seems sufficient, if that makes the fix trivial. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
25 minutes ago, Robby Findler wrote: > Oh -- but I did notice that the lambda cube game does not work; when > you move your mouse over the left hand set of thingies, then turn > black and never turn colored again. Seems like there's a bigger problem -- on linux the games dialog doesn't have the icons on the game buttons. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
Four minutes ago, Robby Findler wrote: > Oh -- but I did notice that the lambda cube game does not work; when > you move your mouse over the left hand set of thingies, then turn > black and never turn colored again. Oh, right -- I completely forgot about it. I'll see if I can do a quick fix. (It uses a xor as a cheap highlighting hack, which is no longer in gr2.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
Oh -- but I did notice that the lambda cube game does not work; when you move your mouse over the left hand set of thingies, then turn black and never turn colored again. Robby On Tue, Feb 1, 2011 at 10:43 AM, Robby Findler wrote: > On Mon, Jan 31, 2011 at 4:50 PM, Ryan Culpepper wrote: >> * Robby Findler >> - DrRacket Tests >> - Framework Tests >> - Contracts Tests >> - Games Tests >> - Teachpacks Tests: image tests >> - PLaneT Tests >> Updates: >> - DrRacket Updates: update HISTORY >> (updates should show v5.1 as the most current version) >> - Ensure that previous version of DrRacket's preference files still >> starts up with new DrRacket >> - Update man pages in racket/man/man1: drracket.1 >> Email me to pick the changes when they're done, or tell me if there >> are no such changes. > > Done. > > History update pushed, mentioned merge in commit message. > > Robby > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
At Mon, 31 Jan 2011 17:50:56 -0500, Ryan Culpepper wrote: > - Typed Scheme Tests Done. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Phase distinctions and "compile: identifier used out of context"
On Tue, Feb 1, 2011 at 3:09 PM, Matthew Flatt wrote: > At Sat, 29 Jan 2011 15:07:37 -0500, Carl Eastlund wrote: >> The following program binds => at both phase 0 (module-scoped macro) >> and phase 1 (lexically-scoped value). The use of the => macro at the >> end expands into a recursive reference to =>, which in turn produces >> the error "compile: identifier used out of context". As I understand >> it, this happens because the identifier => has been taken out of the >> scope of its phase 1 binding. However, it is being used here at phase >> 0. I would much prefer if the expander simply ignored the phase 1 >> binding and carried out the recursive macro invocation. >> >> Before I file this as a bug report, have I understood what's going on? >> Is there any reason this shouldn't or couldn't be fixed? > > It would indeed be sensible to have local bindings at phase N shadow > only at phase N, leaving bindings in other phases as they are. > > We haven't done that so far for two reasons: > > * They're local bindings, so you can always pick different identifiers > for bindings that have overlapping scopes. > > * If you use the same identifier for bindings with overlapping scopes > at different phases, the results can be confusing. > > As an example of the latter, consider > > (syntax-case stx () > [(_ id) > (let ([id (munge #'id)]) > #'(list id))]) > > versus > > (syntax-case stx () > [(_ id) > (with-syntax ([id (munge #'id)]) > #'(list id))]) > > Currently, only the latter is sensible, and the former leads to a phase > error. If the two `id's were bound only in their respective phases > (i.e., 0 and -1), then the former example's result template would use > `id' from the pattern, quietly ignoring the `let' binding. > > I don't think that's a great example, but it has the flavor of a kind > of mistake that I make. Given the options, I think I prefer to rename > local variables that collide to trigger errors, instead of having > bindings that look like they shadow lead to something different > (usually quietly). But I haven't actually tried programming with the > other option. > > Of course, with respect to the possibility of confusion, it's just as > potentially confusing to use the same identifier for imported bindings > different phases. For example, it can be confusing that `lambda' is > available at multiple phases, perhaps even with different meanings. In > contrast to just local bindings, however, picking different names for > all bindings in different phases --- including alternatives for > `lambda' at different phases --- would be truly inconvenient. Thanks for the response, Matthew. I wound up concluding I was better off using different names anyway, so I think the status quo is okay. However, the error message could be more informative. For instance: "compile: reference to in phase is out of the scope of defined in phase at ; bindings in all phases must be in scope." --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Phase distinctions and "compile: identifier used out of context"
At Sat, 29 Jan 2011 15:07:37 -0500, Carl Eastlund wrote: > The following program binds => at both phase 0 (module-scoped macro) > and phase 1 (lexically-scoped value). The use of the => macro at the > end expands into a recursive reference to =>, which in turn produces > the error "compile: identifier used out of context". As I understand > it, this happens because the identifier => has been taken out of the > scope of its phase 1 binding. However, it is being used here at phase > 0. I would much prefer if the expander simply ignored the phase 1 > binding and carried out the recursive macro invocation. > > Before I file this as a bug report, have I understood what's going on? > Is there any reason this shouldn't or couldn't be fixed? It would indeed be sensible to have local bindings at phase N shadow only at phase N, leaving bindings in other phases as they are. We haven't done that so far for two reasons: * They're local bindings, so you can always pick different identifiers for bindings that have overlapping scopes. * If you use the same identifier for bindings with overlapping scopes at different phases, the results can be confusing. As an example of the latter, consider (syntax-case stx () [(_ id) (let ([id (munge #'id)]) #'(list id))]) versus (syntax-case stx () [(_ id) (with-syntax ([id (munge #'id)]) #'(list id))]) Currently, only the latter is sensible, and the former leads to a phase error. If the two `id's were bound only in their respective phases (i.e., 0 and -1), then the former example's result template would use `id' from the pattern, quietly ignoring the `let' binding. I don't think that's a great example, but it has the flavor of a kind of mistake that I make. Given the options, I think I prefer to rename local variables that collide to trigger errors, instead of having bindings that look like they shadow lead to something different (usually quietly). But I haven't actually tried programming with the other option. Of course, with respect to the possibility of confusion, it's just as potentially confusing to use the same identifier for imported bindings different phases. For example, it can be confusing that `lambda' is available at multiple phases, perhaps even with different meanings. In contrast to just local bindings, however, picking different names for all bindings in different phases --- including alternatives for `lambda' at different phases --- would be truly inconvenient. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
> * Jon Rafkind > Release tests for (one of the) linux releases: > - Test that the `racket' and `racket-textual' source releases > compile fine > - Test that the binary installers for both work, try each one in > both normal and unix-style installation modes. (just ubuntu) > [Note: get the release candidates from the URL in this email. Use >the 'static table' link to see a list of all tar files available] > Using mz-5.0.99.900-src-unix.tgz, configure error'd out config.status: error: cannot find input file: plot/Makefile.in _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
On Mon, Jan 31, 2011 at 4:50 PM, Ryan Culpepper wrote: > * Robby Findler > - DrRacket Tests > - Framework Tests > - Contracts Tests > - Games Tests > - Teachpacks Tests: image tests > - PLaneT Tests > Updates: > - DrRacket Updates: update HISTORY > (updates should show v5.1 as the most current version) > - Ensure that previous version of DrRacket's preference files still > starts up with new DrRacket > - Update man pages in racket/man/man1: drracket.1 > Email me to pick the changes when they're done, or tell me if there > are no such changes. Done. History update pushed, mentioned merge in commit message. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
2011/1/31 Ryan Culpepper : > * Jay McCarthy > - Web Server Tests > - XML Tests > - HTML Tests > - PLAI Tests > - Racklog tests > - Datalog tests All passed -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
At Mon, 31 Jan 2011 17:50:56 -0500, Ryan Culpepper wrote: > * Matthew Flatt > - Racket Tests > - Languages Tests > - GRacket Tests (Also check that `gracket -z' and `gracket-text' still > works in Windows and Mac OS X) > - mzc Tests > - mzc --exe tests > - .plt-packing Tests > - Games Tests > - Unit Tests > - Syntax Color Tests > - R6RS Tests > - JPR's test suite. > [...] > Updates: > - Racket Updates: update HISTORY > - GRacket Updates: update README, HISTORY > (updates should show v5.1 as the most current version) > - Update man pages in racket/man/man1: racket.1, gracket.1, raco.1 > Email me to pick the changes when they're done, or tell me if there > are no such changes. Done. There was one bug fix for `raco exe' (called `mzc --exe' above) and a minor man-page fix. > - Create an executable from a BSL program. While most programs that I tried worked, I've submitted a PR on one problem. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
