[racket-dev] Release process for split repos
I’ve added a draft of a new release process that takes the repository split into account. The main difference is that there is no longer a single release branch under central management; instead, there is a release branch for each repository, and management responsibilities for package release branches is distributed. The wiki page is here: https://github.com/plt/racket/wiki/Release-process Please review, ask questions, and point out ambiguities and potential problems. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release Announcement for v6.1.1, Second Draft
The release announcement sketch that I have so far is below. Please mail me new items and/or edits. -- Racket version 6.1.1 is now available from http://racket-lang.org/ * Mac OS X Yosemite: fixed compatibility problems, mainly by patching the Pango text-drawing library that is bundled with Racket. * Windows, 32-bit version: fixed window-update crashes by patching the Cairo drawing library that is bundled with Racket. * Windows: made the GUI library DPI-aware. * Added a binary library installation mode to install packages without source or documentation. Use the `--binary-lib` option with `raco pkg install`. * Repaired the compiler's use-before-defined analysis for certain forms of nested `letrec`, some `let` forms, and some uses of `set!` or `with-continuation-mark`. * Added bytecode optimizations (thanks to Gustavo Massaccesi). * Added a `replace-evt` event constructor (as suggested by Jan Dvořák). * Added the drracket/check-syntax library to facilitate check syntax-like behavior in other IDEs. * Redex: explained the benchmark programs added a conditional-form to metafunctions. * 2htdp/image's notion of equality no longer considers an image's baseline. * Contracts: contract-stronger? is now more consistently useful and contract error messages now admit the contract itself might be wrong. * Exception handling changed to be safe. This may break existing programs that rely on unsafe behavior. * Casts and predicates are supported in typed regions. * The `openssl' library supports Server Name Indication for server contexts (thanks to Jay Kominek). * The `syntax/parse' library allows the definition of new pattern forms via pattern expanders, similar to match expanders (thanks to Alex Knauth). * For OpenGL on Linux, removed dependence on libgtkgl and added support for core profiles (see `set-legacy?`). * The unit test framework for the *SL teaching languages supports check-satisfied, a construct for checking whether a result satisfies a named predicate, e.g.: (check-satisfied (sort l) sorted?) -- _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release Announcement for v6.1.1
The release announcement sketch that I have so far is below. Please mail me new items and/or edits. -- mflatt: - optimizations (most from Gustavo Massaccesi) (82ffd405, 25c05d66, a7a912ee, 1f2f7a1d, d14b4a80, 769c5b6e, 35eb6562, 15423988) - add replace-evt (as suggested by Jan Dvořák) (bc69a9b0) - performance tuning (c570a862, 1809df45) - windows: use native api for dates (135ccf09) - allow mixing exceptions with ffi/unsafe/alloc (from Jan Dvořák) (8bd5aa38) - fixing letrec updates? (eg 926e64f5?) - senora gc (2916fc34, a312f499, 881990ed) - raco pkg add '--binary-lib' (05523a0b, b2b00010) - Mac OS X Yosemite Pango repair (76f1ebde) - throw out latex back-end for picts ? (77ddf71b) - chaperones w/o redirections (1f1a10db, a8d0534e) - DPI-aware racket/gui on Windows (a64a1cb1) - Windows: fix handling of junctions as links (cf7c0134) - behavior of numpad Enter (7d388a07, a41cc0c3) - UDP improvements (2a387ace) - natipkg (40f5ec07) robby: - add #:post condition to meta functions (e991dd46) - improve the random checking for -i (72c83a32) - add contract-correct caveat to error messages (1dda800c) - add #:pre to define-judgment-form (54a6d317) - contract-stronger (eaf48bbb, 05185dcd, f669c47c, ...) matthias: - check-satisfied (ecfafe63, and following) neil: - remove dependence on libgtkgl (c601b82f) ryanc: - add pattern expanders to syntax/parse (from Alex Knauth) (81cc6bf4) - openssl server-side SNI (from Jay Kominek) (320079ee, 2d2f5dc3) -- _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pre-Release Checklist for v6.1.1, Second Call
Checklist items for the v6.1.1 release (using the v6.1.0.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre-release.racket-lang.org Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests, you can do this: cd ...racket-root... ./bin/raco pkg install -i main-distribution-test -- * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles - Try teaching-languages testing framework (check-expect) Updates: - Teachpack Updates: update HISTORY (updates should show v6.1.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Verify PL language - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (. .../racket-completion.zsh; _racket --self-test) * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine (note that they're still called `plt' and `mz' at this stage). - 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] * David Van Horn dvanh...@ccs.neu.edu - EoPL Tests * Neil Toronto neil.toro...@gmail.com - Plot Tests - Images Tests - Inspect icons - Math tests _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release for v6.1.1 has begun
The release process for v6.1.1 has begun: the `release' branch was created for any work that is left and is now bumped to v6.1.0.900. You can go on using the `master' branch as usual, it is now bumped to v6.1.1.1 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Please make sure that code that you're responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release. NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT The time between the `release' branch creation and the actual release is for fixing new errors that prevent proper functioning of major components and that show up during the preparation for a release. You can also finalize piece of work that is not yet complete, but please avoid merging new features. Note that nightly builds will go on as usual (starting from v6.1.1.1 and going up as usual), and pre-release builds will be available shortly at http://pre-release.racket-lang.org/ Please tell me if you think that this release is significant enough that it should be announced on the users list for wider testing. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release for v6.1.1 is about to begin
The release process for v6.1.1 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] Release Announcement for v6.1, second draft
The release announcement draft that I have so far is below. Please mail me new items and/or edits. -- Racket v6.1 raises an exception when a local variable is used before its definition, instead of producing an #undefined value. (Thanks to Claire Alvis.) Since programs are rarely intended to produce #undefined, raising an exception provides earlier and better feedback to programmer. Module-level variables have always triggered an exception when used too early, and this change makes local bindings --- including fields within a class --- behave the same. This is a backward-incompatible change to Racket. Aside from exposing a few bugs, the change mainly affects programs that include (define undefined (letrec ([x x]) x)) to obtain the #undefined value. There is now no #undefined value in the old sense, but the `racket/undefined` library (which was introduced in the previous release) provides `undefined` for use in place of the pattern above when an undefined value is still needed. * Plumbers generalize the flush-on-exit capability of primitive output ports to enable arbitrary flushing actions and to give programmers control over the timing of flushes (i.e., a composable `atexit`). New functions include `current-plumber`, `plumber-add-flush!`, and `plumber-flush-all`. * contracts: the contract system's random testing facility has been strengthened so that it can easily find simple mistakes in contracted data structure implementations (e.g. an accidental reverse of a conditional in a heap invariant check). * redex: the semantics of mis-match patterns (variables followed by _!_) inside ellipses has changed in a backwards incompatible way; they semantics is now much clearer and now potentially even useful. This change simplifies the patterns' semantics and increases the usefulness of these patterns. * check-random is an addition to the preferred unit testing framework in the teaching languages. It enables the testing of students' functions that use random-number generation. (Thanks to David Van Horn (UMaryland) for proposing this idea.) * Upgraded and normalized versions of graphics libraries and dependencies (Pango, Cairo, GLib, etc.) that are bundled with Racket on Windows and Mac OS X. For example, FreeType support is consistently enabled. * The Typed Racket standard library includes contracted exports from the Racket standard library, such as racket/format's formatting combinators. * Typed Racket now supports asynchronous channels using the `typed/racket/async-channel' library. * The openssl library supports forward secrecy via DHE and ECDHE cipher suites (thanks to Edward Lee) and Server Name Indication (thanks to Jay Kominek). -- _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release Announcement for v6.1
The release announcement sketch that I have so far is below. Please mail me new items and/or edits. -- mflatt: - ARM JIT: fix software floating-point (ffb0dd52) - add plumbers (d5b42f8c) - raco make: improve parallelism (9e3b9844) - deprecate 3-arg module name resolver calls (8aaa3fc5) - win32: support symbolic links (3e3cb716, 9fed5b58) - drawing, bounding boxes, picts, scribble (970b040d, 37af1c8e, c4a58dc4, 05760a12, dac8ba28) robby: - random generation from contracts (1cb1ff28, 76c6a1b7) - contract improvements (c64d70ab) - change semantics of _!_ variables under ellipses (69c96c62) - change metafunction contract formatting (d067311c) - recursive-contract and cyclic values (7728e062, d664ee14, ..., 0db4df1d, f49dd363) - add dvipdf backend to scribble (5280395f) - add history (???) (3cd15cea, 145644ac, 83e8cfba, fb048647, d9dae651) matthias: - add check-random (aec84f4a) ryanc: - ssl DHE/ECDHE, TLS 1.1,1.2 (thanks to Edward Lee) (5c11e621) - add SSL client SNI (Jay Kominek) (52159fea) asumu: - removed mzlib/class100 (5711e900) - classes and TR (various) samth/stamourv: - TR changes? -- Racket now raises an exception when a local variable is used before its definition, instead of producing an #undefined value. (Thanks to Claire Alvis.) Since programs are rarely intended to produce #undefined, raising an exception provides earlier and better feedback to programmer. Module-level variables have always triggered an exception when used too early, and this change makes local bindings --- including fields within a class --- behave the same. This is a backward-incompatible change to Racket. Aside from exposing a few bugs, the change mainly affects programs that include (define undefined (letrec ([x x]) x)) to obtain the #undefined value. There is now no #undefined value in the old sense, but the `racket/undefined` library (which was introduced in the previous release) provides `undefined` for use in place of the pattern above when an undefined value is still needed. -- _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release for v6.1 has begun
The release process for v6.1 has begun: the `release' branch was created for any work that is left and is now bumped to v6.0.900.900. You can go on using the `master' branch as usual, it is now bumped to v6.1.0.1 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Please make sure that code that you're responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release. NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT The time between the `release' branch creation and the actual release is for fixing new errors that prevent proper functioning of major components and that show up during the preparation for a release. You can also finalize piece of work that is not yet complete, but please avoid merging new features. Note that nightly builds will go on as usual (starting from v6.1.0.1 and going up as usual), and pre-release builds will be available shortly at http://pre-release.racket-lang.org/ Please tell me if you think that this release is significant enough that it should be announced on the users list for wider testing. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release for v6.0.2 is about to begin
The release process for v6.0.2 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] Release Announcement for v6.0.1
The release announcement sketch that I have so far is below. Please mail me new items and/or edits. -- mflatt: - 2x bitmaps (037a211f, e47a90cc, etc); file/convertible (eda4f357) - retina displays (7dc63162) - dc alignment scale (582e9925) - bignum performance (780d6ae5) - added syntax/wrap-modbeg (bfda0665) - treat FFI primitives like other primitives (eff53cde) - add PLTUSERHOME (e4ce0d03) - fix bignum allocation (efa19918) - add racket/undefined (8abf7825, 74f82bbd) robby: - check syntax info even with syntax errors (09920bd8) - contract system change, more first-order-friendly (c321f6dd) - class/c changes (2989918a, 7bec967c, 4f65d57f, 59f57b1b) vincent: - contract profiler (cc0e6763, 7495243d, etc) - make f[lx]vectors sequences (8e32e6e4) asumu: - TR :-less syntax (e6e3ab4e, 45d36579, 37b09521, etc) - explain/warn about Class types? - TR recursive type aliases (a8cc430d) samth: - web pages? (154b5453, etc) neil: - plot 3D BSP tree (a515e7ce) - PDF/PS scaling changed to 1.0x1.0 (efc46ded) -- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] actionable items, was: comments on comments on learning Racket
On 04/28/2014 10:08 AM, Laurent wrote: On Mon, Apr 28, 2014 at 3:47 PM, Matthias Felleisen matth...@ccs.neu.edu mailto:matth...@ccs.neu.edu wrote: [...] Why not something like `apply-list` or `apply/list`? (personally I usually call it `cvl` for call/values-list, but that's because I often use it on the command line, which makes going from `(foo 'a 'b 'c)` to `(cvl foo 'a 'b 'c)` effortless) (define (nth-return-value i f . s) (call-with-values (lambda () (apply f s)) (lambda l (list-ref l i unstable/list has an unexported 'values-list' macro that takes an expression and returns the list of values it produces. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] actionable items, was: comments on comments on learning Racket
(values-list (values 1 2 3)) = (list 1 2 3) It can't be a function; a function-argument continuation only accepts a single value. As to why prefer a macro instead of a function like 'call/values-list', I think 'values-list' represents a smaller, more coherent bit of behavior. You can trivially wrap it around arbitrary expressions instead of just function calls. Ryan On 04/28/2014 01:45 PM, Matthias Felleisen wrote: Time to move it to a place easy to find? But why a macro? On Apr 28, 2014, at 1:10 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: On 04/28/2014 10:08 AM, Laurent wrote: On Mon, Apr 28, 2014 at 3:47 PM, Matthias Felleisen matth...@ccs.neu.edu mailto:matth...@ccs.neu.edu wrote: [...] Why not something like `apply-list` or `apply/list`? (personally I usually call it `cvl` for call/values-list, but that's because I often use it on the command line, which makes going from `(foo 'a 'b 'c)` to `(cvl foo 'a 'b 'c)` effortless) (define (nth-return-value i f . s) (call-with-values (lambda () (apply f s)) (lambda l (list-ref l i unstable/list has an unexported 'values-list' macro that takes an expression and returns the list of values it produces. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pre-Release Checklist for v6.0.1, Second Call
Checklist items for the v6.0.1 release (using the v6.0.0.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre-release.racket-lang.org/ Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests, you can do this: cd ...racket-root... ./bin/raco pkg install -i main-distribution-test -- * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests - Typed Racket Updates: update HISTORY (updates should show v6.0.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v6.0.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper r...@cs.utah.edu - Macro Debugger Tests - Syntax Classifier Tests - RackUnit GUI Tests - Data Tests - DB Tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Stephen Chang stch...@ccs.neu.edu - Lazy Racket Tests - Lazy stepper tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Verify PL language - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (. .../racket-completion.zsh; _racket --self-test) Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Neil Toronto neil.toro...@gmail.com - Plot Tests * Doug Williams m.douglas.willi...@gmail.com - Additional Plot Tests _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pre-Release Checklist for v6.0.1
Checklist items for the v6.0.1 release (using the v6.0.0.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre-release.racket-lang.org/ Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests, you can do this: cd ...racket-root... ./bin/raco pkg install -i main-distribution-test -- * Matthew Flatt mfl...@cs.utah.edu - Racket Tests - Languages Tests - GRacket Tests (Also check that `gracket -z' and `gracket-text' still works in Windows and Mac OS X) - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests - JPR's test suite - Create an executable from a BSL program - Run COM tests - Try compiling with -funsigned-char - Try compiling with TEST_ALTERNATE_TARGET_REGISTER Updates: - Racket Updates: update HISTORY (updates should show v6.0.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. * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests - Redex Tests Updates: - DrRacket Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v6.0.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. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v6.0.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests - Typed Racket Updates: update HISTORY (updates should show v6.0.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v6.0.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper r...@cs.utah.edu - Macro Debugger Tests - Syntax Classifier Tests - RackUnit GUI Tests - Data Tests - DB Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Stevie Strickland sstri...@ccs.neu.edu - Unit Contract Tests - Contract Region Tests - Class Contract Tests * Stephen Chang stch...@ccs.neu.edu - Lazy Racket Tests - Lazy stepper tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Verify PL language - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (. .../racket-completion.zsh; _racket --self-test) Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests * Greg Cooper g...@cs.brown.edu - FrTime Tests * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine (note that they're still called `plt' and `mz' at this stage). - 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
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
IIRC, most of the code in openssl/mzssl.rkt predates ffi/unsafe/alloc. So yes, BIO_new etc should use (allocator _) etc, and that would simplify some of the code that currently uses the local with-failure macro to do deallocation. But no need to fix that in this patch. Some comments on the patch: - Regarding curves/c, the curve NID_* definitions, and symbol-nid: There's some redundancy here that could be eliminated with the following pattern: (define curve-nid-alist '((sect163k1 . 721) )) (define curve/c (apply or/c (map car curve-nid-alist))) (define (curve-nid sym) (cond [(assq sym curve-nid-alist) = cdr] [else (error )])) That eliminates the problem of keeping the enumeration of curves in sync in three places. - SSL_CTRL_SET_ECDH_AUTO is unused; it should be removed. - There's a missing ! in some of the symbols passed to error in ssl-server-context-enable-dhe!. If you send a new version of the patch I'll commit that; otherwise I can make the changes above myself when I get a chance. Ryan On 04/11/2014 01:46 PM, Edward Lee wrote: Thanks for catching the typo. I don't have a good answer to your second question; I really don't know if they should. --Edward On Thu, Apr 10, 2014 at 02:54:36PM -0400, Stephen Chang wrote: Ok thanks. Sorry, I think one more is missing from curve/c (sect283r1)? Another question: Should BIO_new_mem_buf have an additional #:wrap (allocator BIO_free) argument, similar to other allocating functions? More generally, should BIO_new and BIO_free have #:wrap arguments like the other allocating/deallocating functions? On Thu, Apr 10, 2014 at 2:11 PM, Edward Lee e45...@uwaterloo.ca wrote: Those are accidental omissions; I've attached a patch that should fix the contract and symbol-nid. --Edward On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: I checked out the patch and have a few questions. (I'm a non-expert.) How come some curves are omitted from the curve/c contract (eg sect163k1 and sect193r2)? Is there also a curve missing from symbol-nid (eg sect571r1)? On Wed, Apr 9, 2014 at 7:52 PM, Neil Van Dyke n...@neilvandyke.org wrote: Edward, your patch sounds OK to me, FWIW. Neil V. _ 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
[racket-dev] Release for v6.0.1 is about to begin
The release process for v6.0.1 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] Testing for Racket v6.0
We need volunteers for a final round of testing for Racket v6.0. This round of testing will focus on the package system and changes related to it. We would like to test the release candidate on the following configurations: - Unix build from source, in-place install - Unix build from source, Unix-style install - Unix build from source, minimal, in-place install - Unix build from source, minimal, Unix-style install - Mac OS X 32-bit - Mac OS X 64-bit - Mac OS X 32-bit, minimal - Windows 32-bit - Windows 64-bit - Windows 32-bit, minimal We would like the testers to try the following: 1. Start DrRacket, if non-minimal, and check the version display in interactions. 2. Create a hello world executable distribution: from within DrRacket if non-minimal, via `raco exe` and `raco dist` if minimal. 3. Install the aws package and try to read the docs; use the GUI package manager for non-minimal, use `raco pkg install` for minimal; double-check that installation was in user scope. 4. If minimal, install DrRacket (as a package) and try to start it as in step 1. 5. Uninstall the aws package. The idea here is that our tests for functionality worked as well as ever for v5.93, while the problems were mostly related build and package configuration (as we expected). We haven't heard about any problems particularly related to step 2 above, but it's especially sensitive to the installation configuration, so it's a useful extra check. If you are interested in helping, please reply to this message to the mailing list and include the configuration(s) you are willing to test. Thanks, Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [patch] OpenSSL ECDH(E) + DHE support.
On 02/08/2014 05:52 PM, Edward Lee wrote: Hi. Racket's OpenSSL bindings do not currently enable the ECDH(E) and the DHE ciphers, which are needed for perfect forward secrecy. I've attached a patch that: - Embeds reasonable defaults for DHE mode. - Adds two functions, ssl-server-context-enable-dhe! and ssl-server-context-enable-ecdhe! that when given DHE/ECDHE setup arguments (for DHE, a DH parameter file path, for ECDHE, the name of one of the built-in OpenSSL elliptic curves [currently, only secp521r1]) - (unrelated, but also useful) Adds bindings for TLS 1.1/1.2-only server/client contexts. This patch is currently a work in progress (it currently only supports one elliptic curve name) that works well enough for what I am using it for, but I'm interested in getting this patch upstream. Here are a few comments: What is SSL_CTRL_SET_ECDH_AUTO? I couldn't find it in the openssl headers, and I searched a few recent versions. It seems unused here, anyway. I think it would be better to read the DH params file into memory using Racket file operations and then use a memory BIO for PEM_read_bio_DHparams. Two reasons: the file access will then automatically go through Racket's security-guard checks, and the file read will go through Racket's IO system, so if the read blocks it won't block all Racket threads. In ...enable-ecdhe!, the 'case' form doesn't need 'quote'. It should be this instead: (case name [(secp521r1) NID_secp521r1] [else ___]) As it is, the function will accept 'quote as the name of a curve. What's the exact process for this? If you have a github account, you can fork the repo there and submit a pull request. But we can certainly handle patches like this too. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket v5.93
Racket v5.93 is now available from http://racket-lang.org/ Version 5.93 repairs a few problems with the recent v5.92 release (in preparation for a v6.0 release): * fixed a low-level concurrency problem with the GUI library for Mac OS X, which especially affected 32-bit builds; * fixed GRacket-based launchers (such as `drracket`) in a Unix-style installation; * expanded the list of recognized OpenSSL library versions; * fixed small CSS problems and inconsistencies (relative to v5.3.6) in the new Scribble style as used by the Racket documentation; and * added the version number back to the racket directory within the source distribution bundle. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket v5.92
Racket 5.92 has a new package system, including a catalog of hundreds of already-available packages. Please visit http://pkgs.racket-lang.org/ for an overview of the packages. Recent releases included the beta versions of the package system. Racket version 5.92 incorporates many improvements suggested by these preliminary experiences: * A package is treated as a single collection by default, so it is even easier to use a Github repository as a package. Get started quickly: http://docs.racket-lang.org/pkg/getting-started.html * DrRacket includes a new package manager GUI, available via the File|Package Manager ... menu item. The GUI is also available as a stand-alone program via the gui-pkg-manager package. * The main Racket distribution has been separated into about 200 packages. The Racket installer combines the core system with bundled versions of these packages. Alternatively, you may now install a Minimal Racket distribution --- which is about 1/10 the size of the main distribution --- and add only those packages that you need. * Package installation supports pre-built packages that include compiled byte code and rendered documentation, meaning packages can be installed quickly when built versions are available. All packages in the main distribution are available in pre-built form. Further improvements are in the works, notably including package documentation on the package-catalog web site. COMPATIBILITY NOTE: PLaneT, the previous Racket package system, will remain in place for the foreseeable future, but we expect all package work to shift to the new system. Beyond the package system, this release brings a number of other changes: * Racket's HTML documentation has a new and improved look, thanks to Matthew Butterick. * The documentation includes a style guide, How to Program Racket http://docs.racket-lang.org/style/ * Racket's JIT compiler supports the ARM architecture. * Racket supports the Mac's Retina display mode. * The performance of the Typed Racket compiler improved by 50% on some typed programs; e.g., see http://bit.ly/1d0Ye4z * The profiler provides a new mode that uses the errortrace library to produce fine-grained profiles. * A new contract profiler reports how much time programs spend checking contracts, and which contracts are most expensive. * The math/flonum library exports fast 105-bit precision operations. * Check Syntax handles generated identifiers, especially those introduced by struct (e.g. field selectors) and Redex (e.g., e_1, e_2) * 2htdp/batch-io includes functions for dealing with html/xml in files and web sites as X-expressions plus conveniences for web-based graph traversals. * The `gen:set' generic interface extends set operations to work on user-defined types that implement set methods, as well as on other set-like built-in types, such as lists. * Picts support conversion to SVG format. * Under unix, Racket provides desktop entries (.desktop files) for its graphical executables. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pre-Release Checklist for v6.0, Second Call
Checklist items for the v6.0 release (using the v5.91.0.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://plt.eecs.northwestern.edu/release-snapshots/ Note the nonstandard location! The Racket plus Tests builds already include the test packages. If you use a Minimal Racket build instead, install test packages manually using raco pkg install. -- * Matthew Flatt mfl...@cs.utah.edu - Run COM tests * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - HTML Tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Verify PL language - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (. .../racket-completion.zsh; _racket --self-test) Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * David Van Horn dvanh...@ccs.neu.edu - EoPL Tests * Neil Toronto neil.toro...@gmail.com - Plot Tests _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pre-Release Checklist for v6.0
Checklist items for the v6.0 release (using the v5.91 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://plt.eecs.northwestern.edu/snapshots/ Note the nonstandard location! The Racket plus Tests builds already include the test packages. If you use a Minimal Racket build instead, install test packages manually using raco pkg install. -- * Matthew Flatt mfl...@cs.utah.edu - Racket Tests - Languages Tests - GRacket Tests (Also check that `gracket -z' and `gracket-text' still works in Windows and Mac OS X) - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests - JPR's test suite - Create an executable from a BSL program - Run COM tests - Try compiling with -funsigned-char - Try compiling with TEST_ALTERNATE_TARGET_REGISTER Updates: - Racket Updates: update HISTORY (updates should show v6.0 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. * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests - Redex Tests Updates: - DrRacket Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v6.0 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. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v6.0 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests - Typed Racket Updates: update HISTORY (updates should show v6.0 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v6.0 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper r...@cs.utah.edu - Macro Debugger Tests - Syntax Classifier Tests - RackUnit GUI Tests - Data Tests - DB Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Stevie Strickland sstri...@ccs.neu.edu - Unit Contract Tests - Contract Region Tests - Class Contract Tests * Stephen Chang stch...@ccs.neu.edu - Lazy Racket Tests - Lazy stepper tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Verify PL language - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (. .../racket-completion.zsh; _racket --self-test) Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests * Greg Cooper g...@cs.brown.edu - FrTime Tests * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine (note that they're still called `plt' and `mz' at this stage). - 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] * Mike Sperber sper...@deinprogramm.de - DMdA Tests
[racket-dev] Pre-Release Checklist for v6.0, corrected url
(Re-sending with corrected URL for release candidates. Thanks to Sam for the quick catch!) Checklist items for the v6.0 release (using the v5.91 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://plt.eecs.northwestern.edu/release-snapshots/ Note the nonstandard location! The Racket plus Tests builds already include the test packages. If you use a Minimal Racket build instead, install test packages manually using raco pkg install. -- * Matthew Flatt mfl...@cs.utah.edu - Racket Tests - Languages Tests - GRacket Tests (Also check that `gracket -z' and `gracket-text' still works in Windows and Mac OS X) - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests - JPR's test suite - Create an executable from a BSL program - Run COM tests - Try compiling with -funsigned-char - Try compiling with TEST_ALTERNATE_TARGET_REGISTER Updates: - Racket Updates: update HISTORY (updates should show v6.0 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. * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests - Redex Tests Updates: - DrRacket Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v6.0 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. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v6.0 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests - Typed Racket Updates: update HISTORY (updates should show v6.0 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v6.0 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper r...@cs.utah.edu - Macro Debugger Tests - Syntax Classifier Tests - RackUnit GUI Tests - Data Tests - DB Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Stevie Strickland sstri...@ccs.neu.edu - Unit Contract Tests - Contract Region Tests - Class Contract Tests * Stephen Chang stch...@ccs.neu.edu - Lazy Racket Tests - Lazy stepper tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Verify PL language - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (. .../racket-completion.zsh; _racket --self-test) Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests * Greg Cooper g...@cs.brown.edu - FrTime Tests * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine (note that they're still called `plt' and `mz' at this stage). - 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
[racket-dev] Fwd: [plt] Push #27935: master branch updated
Matthew has requested this commit be included in the release branch. It looks safe to me, but I can't tell if it fixes the problem in all cases. A more obvious, if coarser, fix would be something like (define (file-connection file [write? #f]) (unless (file-exists? file) (create-and-initialize )) (connect )) Let's take the commit below in the interest of moving forward, and if Matthew wants to change it again later we can take that commit too. Ryan Original Message Subject: [plt] Push #27935: master branch updated Date: Mon, 16 Dec 2013 20:51:58 -0500 From: mfl...@racket-lang.org To: dev@racket-lang.org mflatt has updated `master' from ac480e7535 to 6ff7359212. http://git.racket-lang.org/plt/ac480e7535..6ff7359212 =[ One Commit ]= Directory summary: 100.0% pkgs/racket-pkgs/racket-index/setup/ ~~ 6ff7359 Matthew Flatt mfl...@racket-lang.org 2013-12-16 18:19 : | raco setup: create docindex database before trying to read | | Commit 0f80c71fab propagates read-only mode so that a documentation | database is not created for read operations, but `raco setup` (with | documentation-index support) attempts to read the database before | writing to it. Change `raco setup` to make sure the database | exists if a later write operation is expected to create it. | | Merge bug fix to v6.0 (pending review) : M pkgs/racket-pkgs/racket-index/setup/scribble.rkt | 18 ++ =[ Overall Diff ]=== pkgs/racket-pkgs/racket-index/setup/scribble.rkt --- OLD/pkgs/racket-pkgs/racket-index/setup/scribble.rkt +++ NEW/pkgs/racket-pkgs/racket-index/setup/scribble.rkt @@ -223,6 +223,20 @@ (define main-doc-exists? (ormap (lambda (d) (member 'main-doc-root (doc-flags d))) main-docs)) + (define (can-build*? docs) (can-build? only-dirs docs)) + + (define main-db (find-doc-db-path latex-dest #f main-doc-exists?)) + (define user-db (find-doc-db-path latex-dest #t main-doc-exists?)) + + ;; Ensure that databases are created: + (define (touch-db db-file) +(doc-db-disconnect + (doc-db-file-connection db-file #t))) + (when (ormap can-build*? main-docs) +(touch-db main-db)) + (when (ormap can-build*? user-docs) +(touch-db user-db)) + (when (and (or (not only-dirs) tidy?) (not avoid-main?) (not latex-dest)) @@ -256,7 +270,6 @@ ht setup-printf) - (define (can-build*? docs) (can-build? only-dirs docs)) (define auto-main? (and auto-start-doc? (or (ormap can-build*? main-docs) (and tidy? (not avoid-main?) @@ -399,9 +412,6 @@ (get-files! #f) (doc-db-clean-files user-db files - (define main-db (find-doc-db-path latex-dest #f main-doc-exists?)) - (define user-db (find-doc-db-path latex-dest #t main-doc-exists?)) - (define (make-loop first? iter) (let ([infos (filter-not info-failed? infos)] [src-info (make-hash)] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release for v6.0 has begun
On 11/25/2013 09:44 AM, Matthew Flatt wrote:
Here's the full comment:
The version string has one of the forms:
X.Y
X.Y.Z Z != 0
X.Y.Z.W W != 0
where each X, Y, Z, W is a non-negative exact integer, Y must not
exceed 99, and Z or W must not exceed 999. Y=90 means that this is
working towards {X+1}.0, and X.Y (Z=0, W=0) is an alpha version for
{X+1}.0; Z=900 means working towards X.{Y+1}, and X.Y.Z as an
alpha release.
Then intent is that when Z and W are 0, the string form of the version
number is just X.Y, not X.Y.Z.W.
How about this clarification?
... and X.Y (i.e., Z=0 and W=0, so Z and W are
omitted from the string form) ...
That's not the part that needs clarifying. I think that fact that the
string form drops final zeros is clear from lines 2-4.
The part that needs clarifying is how to choose the version number for
the alpha releases leading up to version {X+1}.0. (Really, how to choose
alpha version numbers in general, since I've had similar problems in the
past.) From this statement, X.Y (Z=0, W=0) is an alpha version for
{X+1}.0 (Y=90 already stated), I would expect that 5.91 would be a
fine alpha version number for 6.0. Is it? If not, what should the alpha
version number be?
Ryan
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Release for v6.0 has begun
On 11/25/2013 10:28 AM, Matthew Flatt wrote:
At Mon, 25 Nov 2013 09:56:45 -0500, Ryan Culpepper wrote:
On 11/25/2013 09:44 AM, Matthew Flatt wrote:
Here's the full comment:
The version string has one of the forms:
X.Y
X.Y.Z Z != 0
X.Y.Z.W W != 0
where each X, Y, Z, W is a non-negative exact integer, Y must not
exceed 99, and Z or W must not exceed 999. Y=90 means that this is
working towards {X+1}.0, and X.Y (Z=0, W=0) is an alpha version for
{X+1}.0; Z=900 means working towards X.{Y+1}, and X.Y.Z as an
alpha release.
Then intent is that when Z and W are 0, the string form of the version
number is just X.Y, not X.Y.Z.W.
How about this clarification?
... and X.Y (i.e., Z=0 and W=0, so Z and W are
omitted from the string form) ...
That's not the part that needs clarifying. I think that fact that the
string form drops final zeros is clear from lines 2-4.
The part that needs clarifying is how to choose the version number for
the alpha releases leading up to version {X+1}.0. (Really, how to choose
alpha version numbers in general, since I've had similar problems in the
past.) From this statement, X.Y (Z=0, W=0) is an alpha version for
{X+1}.0 (Y=90 already stated), I would expect that 5.91 would be a
fine alpha version number for 6.0. Is it? If not, what should the alpha
version number be?
I agree that 5.91 is the right alpha-version string, assuming that
it's intended as an alpha in the sense of our release rules (as
opposed to a release candidate, which has a non-zero W).
The problem with the release branch currently is that 5.91.0.0 is
not a valid version string, and so
#define MZSCHEME_VERSION 5.91.0.0
creates trouble, right?
OH! I didn't realize that was the problem, because I knew not to do
that, but apparently I did it anyway. Sorry about that. I just pushed a fix.
Ryan
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] Release for v6.0 has begun
The release process for v6.0 has begun: the `release' branch was created for any work that is left and is now bumped to v5.91. You can go on using the `master' branch as usual, it is now bumped to v6.0.0.1 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Please make sure that code that you're responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release. NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT The time between the `release' branch creation and the actual release is for fixing new errors that prevent proper functioning of major components and that show up during the preparation for a release. You can also finalize piece of work that is not yet complete, but please avoid merging new features. Note that nightly builds will go on as usual (starting from v6.0.0.1 and going up as usual), and pre-release builds will be available shortly at http://pre.racket-lang.org/release/ Please tell me if you think that this release is significant enough that it should be announced on the users list for wider testing. _ Racket Developers list: http://lists.racket-lang.org/dev
[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
Re: [racket-dev] accessing @deftech terms in the reference from the guide
On 10/23/2013 08:22 PM, David T. Pierson wrote:
Are terms defined via @deftech in the Racket reference supposed to be
accessible via @tech from the Racket guide?
In pkgs/racket-pkgs/racket-doc/scribblings/reference/evts.scrbl there
exists a line that looks like:
... @deftech{synchronizable event} ...
In my pkgs/racket-pkgs/racket-doc/scribblings/guide/concurrency.scrbl I
have:
... @tech{synchronizable event}s. ...
When I build, I get:
raco setup: --- building documentation ---
raco setup: WARNING: undefined tag in
pkgs/racket-doc/scribblings/guide/guide.scrbl:
raco setup: (tech synchronizable event)
I'm guessing only the @deftech terms defined in the guide are accessible? This
is not a big deal, I just wanted to be sure I wasn't doing something
incorrectly.
You need to use the #:doc argument to the tech function to tell it that
the term was defined in the Racket Reference. Thus:
@tech[#:doc '(lib
scribblings/reference/reference.scrbl)]{synchronizable events}
or better:
@(define reference-doc '(lib scribblings/reference/reference.scrbl))
@tech[#:doc reference-doc]{synchronizable events}
Ryan
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] patch for make-base-eval
I'm concerned about this: +[sandbox-namespace-specs + (cons (λ () (namespace-anchor-namespace anchor)) It seems like this would cause all evaluators to share a single namespace, if I'm reading the docs right. (That would be a good test to add.) Why not just [sandbox-namespace-specs (append (sandbox-namespace-specs) (if ___))] instead? Ryan On 10/03/2013 02:09 PM, Stephen Chang wrote: Here's another attempt at a patch. Would someone mind code reviewing it? Ryan pointed me towards sandbox-namespace-specs and it seems to do the trick. I also added some tests and the docs seem to compile ok. On Wed, Oct 2, 2013 at 7:21 PM, Robby Findler ro...@eecs.northwestern.edu wrote: namespace-attach-module sets up shared state between two modules so that, in this case, the racket/pretty in one namespace is the same as the racket/pretty in the other. Try putting a printf in the top-level of racket/pretty (and in various other places in that code as it does what it does) and then doing the dynamic-require with and without the attach. Robby On Wed, Oct 2, 2013 at 4:58 PM, Stephen Chang stch...@ccs.neu.edu wrote: Ok here's another dumb question. Why is that namespace-attach-module even needed? It seems the dynamic require on the next line does the desired thing? On Wed, Oct 2, 2013 at 4:16 PM, Stephen Chang stch...@ccs.neu.edu wrote: Ok thanks for the explanations. I'll try doing one of the last two suggestions. On Wed, Oct 2, 2013 at 4:09 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: No, the 'racket/pretty' module might be declared even if the symbol isn't defined (or mapped) in the namespace: (define ns (make-base-namespace)) (define repl-ns (current-namespace)) (parameterize ((current-namespace ns)) (eval '(require (only-in racket/pretty (parameterize ((current-namespace ns)) (namespace-attach-module repl-ns 'racket/pretty)) namespace-attach-module: a different module with the same name is already in the destination namespace module name: /opt/racket-5.3.6/collects/racket/pretty.rkt context...: /opt/racket-5.3.6/collects/racket/private/misc.rkt:87:7 And the symbol can be defined in the namespace even if the module is not declared: (define ns (make-base-namespace)) (define repl-ns (current-namespace)) (parameterize ((current-namespace ns)) (eval '(define pretty-print-handler #t))) (parameterize ((current-namespace ns)) (namespace-variable-value 'pretty-print-handler)) #t ;; but racket/pretty is not declared, ;; and #t is not a good print handler Ryan On 10/02/2013 03:58 PM, Stephen Chang wrote: A namespace is a mapping from top-level identifiers to whatever they are, as well as a separate mapping from module names to modules (roughly). What you care about here is the second mapping, but you're checking the first with the patch. Thanks for the explanation. That helps a lot. So the danger with my check is when someone has another definition of pretty-print handler but racket/pretty has not been attached? But given the context, ie the dynamic require on the next line, it seems like there's already an assumption about what the identifier I'm checking is, so in this specific situation, isnt my check sufficient? Robby On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang stch...@ccs.neu.edu wrote: Whether that identifier exists in the namespace has nothing to do with whether racket/pretty can be attached. Can you explain this a little more because it's a little unintuitive to me? One option would be for install-pretty-printer! to just catch and discard the error. Evaluators for some languages would mysteriously not have pretty-printing turned on by default. Another option would be to attach racket/pretty before requiring the initial language for the namespace. Another option is use #:pretty-print? #f when attaching racket/pretty would fail. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] patch for make-base-eval
On 10/02/2013 03:19 PM, Stephen Chang wrote: Can I push the attached (1-line) patch? I don't have a good grasp of namespaces so I would like someone to review it first. Right now, make-base-eval tries to attach racket/pretty to the namespace regardless of whether it's already there, which sometimes results in an exception (for example if the #lang given to make-base-eval is racket). The patch simply first checks if the desired identifier is already there. Whether that identifier exists in the namespace has nothing to do with whether racket/pretty can be attached. One option would be for install-pretty-printer! to just catch and discard the error. Evaluators for some languages would mysteriously not have pretty-printing turned on by default. Another option would be to attach racket/pretty before requiring the initial language for the namespace. Another option is use #:pretty-print? #f when attaching racket/pretty would fail. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] patch for make-base-eval
Yes. Also, it's not enough to check that 'racket/pretty' (or really, the name 'racket/pretty' resolves to) isn't declared in the target namespace; you must also check any module it (transitively) requires is either undeclared or was attached from the same namespace you want to attach racket/pretty from. Ryan On 10/02/2013 03:50 PM, Robby Findler wrote: A namespace is a mapping from top-level identifiers to whatever they are, as well as a separate mapping from module names to modules (roughly). What you care about here is the second mapping, but you're checking the first with the patch. Robby On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang stch...@ccs.neu.edu mailto:stch...@ccs.neu.edu wrote: Whether that identifier exists in the namespace has nothing to do with whether racket/pretty can be attached. Can you explain this a little more because it's a little unintuitive to me? One option would be for install-pretty-printer! to just catch and discard the error. Evaluators for some languages would mysteriously not have pretty-printing turned on by default. Another option would be to attach racket/pretty before requiring the initial language for the namespace. Another option is use #:pretty-print? #f when attaching racket/pretty would fail. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] patch for make-base-eval
No, the 'racket/pretty' module might be declared even if the symbol isn't defined (or mapped) in the namespace: (define ns (make-base-namespace)) (define repl-ns (current-namespace)) (parameterize ((current-namespace ns)) (eval '(require (only-in racket/pretty (parameterize ((current-namespace ns)) (namespace-attach-module repl-ns 'racket/pretty)) namespace-attach-module: a different module with the same name is already in the destination namespace module name: /opt/racket-5.3.6/collects/racket/pretty.rkt context...: /opt/racket-5.3.6/collects/racket/private/misc.rkt:87:7 And the symbol can be defined in the namespace even if the module is not declared: (define ns (make-base-namespace)) (define repl-ns (current-namespace)) (parameterize ((current-namespace ns)) (eval '(define pretty-print-handler #t))) (parameterize ((current-namespace ns)) (namespace-variable-value 'pretty-print-handler)) #t ;; but racket/pretty is not declared, ;; and #t is not a good print handler Ryan On 10/02/2013 03:58 PM, Stephen Chang wrote: A namespace is a mapping from top-level identifiers to whatever they are, as well as a separate mapping from module names to modules (roughly). What you care about here is the second mapping, but you're checking the first with the patch. Thanks for the explanation. That helps a lot. So the danger with my check is when someone has another definition of pretty-print handler but racket/pretty has not been attached? But given the context, ie the dynamic require on the next line, it seems like there's already an assumption about what the identifier I'm checking is, so in this specific situation, isnt my check sufficient? Robby On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang stch...@ccs.neu.edu wrote: Whether that identifier exists in the namespace has nothing to do with whether racket/pretty can be attached. Can you explain this a little more because it's a little unintuitive to me? One option would be for install-pretty-printer! to just catch and discard the error. Evaluators for some languages would mysteriously not have pretty-printing turned on by default. Another option would be to attach racket/pretty before requiring the initial language for the namespace. Another option is use #:pretty-print? #f when attaching racket/pretty would fail. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet require gone wild
I think you just ran into all of the problems with planet1 at the same time. I started with kazzmir/peg and browsed sources, and as far as I can tell, all of the packages you got are actually transitively required by kazzmir/peg. So it's not a PLaneT implementation bug. It looks like there's a chance to cut out most of the other packages by some small changes to schemeunit. I'll see if I can do that. Here are my notes as of the point where I got tired of chasing links. The best part is when kazzmir/peg (a Packrat parsing library) depends on bzlib/parseq (a combinator-based parsing library)---with six degrees of separation. peg - memoize memoize - schemeunit:3 (for testing) schemeunit:3 - sake:1 (in build.ss !!) - require:1:3 (in check-test.ss) sake:1 - schemeunit:3 - unlib:3 (in base.ss) - galore:4 unlib:3 - planet package directories - autoplanet:1 (from autoplanet.ss) - cce/scheme:6 (from base.ss) - bzlib/date:1 (same) - bzlib/date-tz:1 (same) - schematics/namespace:1 (same) - schematics/schemeunit:3 (same) autoplanet:1 - schemeunit:3 bzlib/date:1 - bzlib/base:1 (from depend.ss) - bzlib/parseq:1 (same) bzlib/date-tz:1 - bzlib/base:1 (from depend.ss) - bzlib/file:1 (same) - bzlib/date:1 (same) bzlib/base:1 - zitterbewegung/uuid-v4:1 Ryan On 08/01/2013 09:57 PM, Greg Hendershott wrote: p.s. The About text from DrRacket is: Welcome to DrRacket, version 5.90.0.3--2013-07-30(c126a8aa/d), english by PLT. Just to confirm I ran the DrRacket built from HEAD = c126a8a, not an older version by accident. On Thu, Aug 1, 2013 at 9:55 PM, Greg Hendershott greghendersh...@gmail.com wrote: I'm running HEAD = c126a8a from about 1 week ago. I wanted to try the PEG Planet 1 package. My source file was simply this: #lang racket (require (planet kazzmir/peg:2:0/peg)) 1. Using command-line Racket, I got: Welcome to Racket v5.90.0.3. ; uncaught exception: '#/Users/greg/src/scheme/collects/markdown/markdown/peg.rkt Huh. I had the bright idea of trying this again, in DrRacket 5.90.0.3. 2. Right away, I got a red message: make-directory: forbidden (write) access to /Users/greg/Library/Racket/planet/300/5.90.0.3 Strange... 3. Perhaps dumbly, I decided to hit Run, anyway. What happened is that it installed a LOT of Planet packages. I let it run for awhile, thinking maybe there were more dependencies for `peg' than I realized. But the names flying by were making less and less sense. I got worried it was running wild and doing something like maybe trying to install ALL Planet packages. Plus then it started spitting out the following in the eval pane: Welcome to DrRacket, version 5.90.0.3--2013-07-30(c126a8aa/d) [3m]. Language: racket [custom]; memory limit: 2048 MB. Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/class.ss:36:16: module: identifier is already imported at: send+ in: (define-syntaxes (send+) (new-lambda (stx) (syntax-case stx () ((s+ expr clause ...) (syntax/loc stx (let* ((obj expr)) (send obj . clause) ... obj)) Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module in: proj-get Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module in: proj-get raco setup: error: during making for planet/cce/scheme.plt/6/3 (Scheme Utilities: (planet cce/scheme)) raco setup: Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/class.ss:36:16: module: identifier is already imported raco setup: at: send+ raco setup: in: (define-syntaxes (send+) (new-lambda (stx) (syntax-case stx () ((s+ expr clause ...) (syntax/loc stx (let* ((obj expr)) (send obj . clause) ... obj)) raco setup: error: during making for planet/cce/scheme.plt/6/3/reference raco setup: Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module raco setup: in: proj-get raco setup: error: during Building docs for /Users/greg/Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/reference/manual.scrbl raco setup: Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module raco setup: in: proj-get Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module in: proj-get Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module in: proj-get . . ../../../../../../../../../../../src/plt/racket/racket/collects/setup/private/omitted-paths.rkt:71:2: user break . . src/plt/racket/racket/collects/planet/private/resolver.rkt:606:8: user break So I hit Stop in DrRacket (as you see from user break). Whew. 4. Here's everything it just installed. The only 2 I expected
[racket-dev] Pre-Release Checklist for v5.3.6, second call
Checklist items for the v5.3.6 release (using the v5.3.5.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Verify PL language - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (. .../racket-completion.zsh; _racket --self-test) Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine (note that they're still called `plt' and `mz' at this stage). - 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] * David Van Horn dvanh...@ccs.neu.edu - EoPL Tests * Neil Toronto neil.toro...@gmail.com - Plot Tests - Images Tests - Inspect icons - Math tests * Doug Williams m.douglas.willi...@gmail.com - Additional Plot Tests * Danny Yoo d...@cs.wpi.edu - Whalesong Tests (confirm that Whalesong runs from PLaneT) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax-parse ~once keyword sometimes does not report too-few error?
On 07/25/2013 05:41 PM, Stephen Chang wrote: Here is a syntax-parse macro that requires one subexpression to be wrapped with an exclamation point. (define-syntax (test stx) (syntax-parse stx #:datum-literals (!) [((~or (~once (! x:expr) #:name !) (~not (! y:expr))) ...) #'42])) Everything works like I would expect: (test (! 1) (! 2)) = test: too many occurrences of ! in: () (test (! 1) 2) = 42 (test 1 2) = test: missing required occurrence of ! in: () Here is the same macro but with an extra ~seq and an extra pair of parens around the pattern: (define-syntax (test stx) (syntax-parse stx #:datum-literals (!) [((~seq (~or (~once (! x:expr) #:name !) (~not (! y:expr))) ...)) #'42])) Here are the same tests: (test (! 1) (! 2)) = test: too many occurrences of ! in: () (test (! 1) 2) = 42 (test 1 2) = test: bad syntax in: (test 1 2) I expected the same outputs as the first macro, but the last test example only reports bad syntax and not too few. Is this expected behavior that I'm not understanding or a bug? That's a bug. Two bugs, actually: your two examples should behave the same, and too-few failures should be ranked higher. I'm working on a fix. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket 5.3.6 db/postgresql ssl performance fix
It's not there, but it should be. I'll add it. Ryan On 07/24/2013 09:26 PM, Neil Van Dyke wrote: Did a PostgreSQL SSL performance fix get into 5.3.6 pre-release in some form? In the pre-release I just downloaded, I don't see Ryan's original fix to collects/db/private/postgresql/connection.rkt. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] generate-temporaries and #%top
This sounds like a job for the zero-values define-syntaxes trick, documented here: http://docs.racket-lang.org/reference/syntax-model.html#%28part._macro-introduced-bindings%29 Ryan On 07/10/2013 03:40 PM, Carl Eastlund wrote: I'm having trouble with some of the features of define-generics in top-level contexts. Specifically, if I generate any names with generate-temporaries, and there are forward references to them in the expanded code, then the forward reference fails to expand because #%top is not bound in the context of the temporary name. This problem doesn't come up in module or lexical bindings because all the definitions are bound, not using #%top, by the time the forward reference is expanded. So are generate-temporaries identifiers simply dangerous to use for anything that might wind up at the top level? Or is there a smarter way to use them that I'm missing? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] expand, local-expand, and syntax-procedure-converted-arguments-property
On 07/10/2013 09:04 PM, Asumu Takikawa wrote: Hi all, I'm currently trying to fix the Typed Racket unit tests. I think I've narrowed down the issue to a certain syntax property for keyword functions. The issue is illustrated by the following example: #lang racket (require racket/file (for-syntax racket/file racket/keyword-transform)) ;; the property is #f (begin-for-syntax (displayln (syntax-case (expand-syntax #'(copy-directory/files 1 2)) () [(let-values (((temp1) _) ((temp2) _)) (if _ (#%plain-app1 copy-directory/files15 e1 ...) (#%plain-app2 copy-directory/files17 e2 ...))) (syntax-procedure-converted-arguments-property #'copy-directory/files15)]))) ;; property is syntax (begin-for-syntax (displayln (syntax-case (local-expand #'(copy-directory/files 1 2) 'expression null) () [(let-values (((temp1) _) ((temp2) _)) (if _ (#%plain-app1 copy-directory/files15 e1 ...) (#%plain-app2 copy-directory/files17 e2 ...))) (syntax-procedure-converted-arguments-property #'copy-directory/files15)]))) There are two syntax-time computations here. Both are expanding an application of a keyword function (one with local-expand, one with expand) and looking at the resulting syntax. The key point here is that I want to find the property looked up by `syntax-procedure-converted-arguments-property` on an output identifier because Typed Racket needs it to type-check the expansion. Unfortunately, as the comments indicate, only the second piece of code can find the property. The reason appears to be that the property key is actually a private `gensym`ed symbol and the two pieces of code appear to get separate instantiations of the kw.rkt module (perhaps at different phases). To check that, if I modify kw.rkt to use a plain symbol, both of the snippets above return the same property value. Anyone have any idea how I can keep using `expand` but still be able to look up the property? To get information about a phase-0 '#%app' expansion, you need to call the phase-1 version of 'syntax-procedure-converted-arguments-property'. That's going to require a bit of phase-crossing trickery, because the identifier you want to query is a phase-0 (dynamic) value, and you want the result as a phase-0 value, but the phase-1 function naturally consumes and produces phase-1 values. One solution is to use 'quote-syntax', 'eval', and 'phase1-eval' all together. Use 'eval' with 'quote-syntax' to convert the phase-0 identifier to a phase-1 identifier. Use 'phase1-eval' to run the computation at phase 1 and capture the phase-1 result as a phase-0 value (also using 'quote-syntax'). Here's the code: (require unstable/macro-testing) (define (get-converted-args-property proc-id) (eval #`(phase1-eval (syntax-procedure-converted-arguments-property (quote-syntax #,proc-id)) #:quote quote-syntax))) (printf property is ~s\n (syntax-case (expand-syntax #'(copy-directory/files 1 2)) () [(let-values (((temp1) _) ((temp2) _)) (if _ (#%plain-app1 copy-directory/files15 e1 ...) (#%plain-app2 copy-directory/files17 e2 ...))) (get-converted-args-property #'copy-directory/files15)])) Note that by asking 'phase1-eval' to convert the phase-1 result to a phase-0 value using 'quote-syntax', we've converted the pair of identifiers to a syntax object containing the pair. You'll have to break it apart again yourself. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On 06/26/2013 02:32 PM, Sam Tobin-Hochstadt wrote: [...] Things that didn't move: * `mzlib/compile`: This is used in one place in the compiler, and should probably be handled differently. Matthew, any suggestions? * `mzlib/unit200`. This is loaded into a new namespace in which code is evaluated in `setup/unpack`. I don't understand what is happening there, and thus won't change it. It's also still used genuinely in `file/gzip`. * `mzlib/contract`. This is different enough from `racket/contract` that I'd prefer to have someone who knows the contract system better handle this. Also, much of the contract system implementation is in the `mzlib` directory, which seems odd. * `srfi/13`: used in `net/cookie` in a way that's intertwined with `srfi/14` and would be hard to remove on its own. * `srfi/8`: Used in unmodified srfi code that we probably shouldn't change. * Other SRFIs -- used in the `db` collection, or depended on by those that are. I have a branch where I've split db into the base code and sqlite3 driver, which stays in racket/lib/collects/db, and the other drivers and utils, which move to a package. After the split, the core db code would no longer depend on srfi/19 or json. It doesn't depend on xml now. (The xml and json collections were mentioned earlier in the thread.) The branch isn't quite ready to merge because I might need to update lazy-require to work across packages. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Constructing an identifier to an unexported binding
On 05/23/2013 01:57 AM, Eric Dobson wrote: Some modules have macros which expand into identifiers that are not exported, as they want to protect those bindings. TR currently has the following code which allows it to generate an identifier which is free-identifier=? to what would appear in the output of the macros. define (make-template-identifier what where) (let ([name (module-path-index-resolve (module-path-index-join where #f))]) (parameterize ([current-namespace (make-empty-namespace)]) (namespace-attach-module (current-namespace) ''#%kernel) (parameterize ([current-module-declare-name name]) (eval `(,#'module any '#%kernel (#%provide ,what) (define-values (,what) #f (namespace-require `(for-template ,name)) (namespace-syntax-introduce (datum-syntax #f what) This turns out to be a slightly slow part of the initialization of TR. Does anyone know another way to get such an identifier? There's another way around this issue, which is to avoid creating these identifiers at all. In other words, change the representation of the type environment to something that supports symbol+module pairs as keys in addition to identifiers. The easiest way to do that is to add in a hash table behind the current free-id-table, since the two tables would handle disjoint sets of identifiers. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On 05/05/2013 12:49 PM, Eric Dobson wrote: Keywords are normally right because they are syntactically distinct from expressions --- and so using a keyword avoids various potential ambiguities and sources of confusion. Isn't this only true for default bindings of #%datum? It seems like macros which assume this lose compatibility with #langs that allow keywords as expressions. I'm not sure whether we want to support that or not, but it seems wrong to say that they are syntatically distinct from expressions. I think it goes the other way around: we want keywords not be be expressions, so we would discourage languages from defining #%datum macros that accept them. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On 05/03/2013 11:12 AM, Robby Findler wrote: Can you point to some examples? Note that you can still use else, as long as you don't refer to it as a variable. Just to check: If match treats else specially, it should only accept it as the entire pattern. For example, the following should be an illegal use of else: (match x [(list 'if test then else) ___]) Right? (BTW, I may have written exactly the code above. I need to check.) Ryan On Friday, May 3, 2013, J. Ian Johnson wrote: I've used else as a catch-all binding in match. Yes, it's not the best practice, but I think since I've done it, other people must have done it too. This could annoy them. -Ian - Original Message - From: Robby Findler ro...@eecs.northwestern.edu javascript:; To: Sam Tobin-Hochstadt sa...@ccs.neu.edu javascript:; Cc: dev@racket-lang.org javascript:; Sent: Friday, May 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] else clauses: possible change to match? Given that we don't yet even have a prototype of racket2, I'm going to guess that near isn't all that near. IMO, there are other big things that we should be focused on going first (notably the package system). Just to check again: Is no one concerned with the backwards incompatibility issue? Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: Right, I agree with this. My question is basically: are we going to, in the reasonably near future, be encouraging people to program in a `#lang racket2` where `cond` works differently, in which case it doesn't seem worth it to change `match`. Otherwise, I'll do this now. Sam On Fri, May 3, 2013 at 10:42 AM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: Cond's else cannot change. I agree that that's what I would change if I could have it back to do it over, but we cannot. That's the way to perhaps be thinking about racket2, tho. Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: On Fri, May 3, 2013 at 10:22 AM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: For this kind of thing, my preference would be to change match than to issue a warning. I don't like warnings that are basically admitting weaknesses in the language design Of course, changing a core thing like that may be more trouble than it is worth, due to backwards compatibility concerns, which is why I think it is worth raising here to see what others think. I'm happy to make this change to `match`, except that I've heard Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, and I wouldn't want to change one way, and then change back. Sam _ 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
[racket-dev] Release Announcement for v5.3.4, Final Draft
The release announcement sketch that I have so far is below. Please mail me new items and/or edits. -- * Extflonums (80-bit floating-point numbers) are supported on some x86/x86_64 platforms --- including Windows, and including platforms where Racket is compiled to use SSE instructions for flonum arithmetic. Thanks to Michael Filonenko. * DrRacket (and all of the other apps) are now signed with an official OS X key. * Tally Maze: a new game based an enumeration of 2d mazes. * The Optimization Coach DrRacket plugin has been moved from the Racket distribution to the Racket package repository. * Redex: define-union-language now merges productions when languages define the same nonterminals. Thanks to William Bowman. * The srfi/19 library is now compatible with the date structure type exported by racket/base. -- _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release Announcement for v5.3.4
The release announcement sketch that I have so far is below. Please
mail me new items and/or edits.
--
mflatt:
- added file-truncate (48e05093)
- mach-o: handle some new load commands (a229f292)
- mach-o: code signing fixes (1744a787)
- scribble/latex-properties: add command-extras (17865bfa)
- ffi/com: improve handling of type-described (79266fcf)
- added scribble/book and scribble/report langs (09d4aa3d)
- add _size, _ssize, _ptrdiff, etc (d46411d3)
- add phaseless modules (899a3279)
- improve complexity of hash-iterate-{key-value} (7a8c2ff0)
- add 'so-mode to system-type (cdf0f6b9)
- add interactive to slideshow (454f4c3f)
- ffi/com repairs, including mysterx compat (6e40caa7)
robby:
- added union-find (33747ec9)
- 2d (bb216d14)
- improved jump-to-def (39e4ac15)
jay:
- various pkg (39ae7a83, 9d3a42f1, 6bf03c12)
dyoo:
- parser-tools (9e0fce22, ???)
- fixed readline (f1e70516)
eli:
- add links to old documentation (250880d2)
- add {take,drop}f, splitf-at, etc (bb17b6a8, 2cdfe18b, 3af72eca)
- make configure install docs in standard place (59b18eec)
ryanc:
- added #:datum-literals (d5fe6021)
- added unstable/macro-testing (1ef38458)
- added unstable/socket (b3afbdd4)
- added #:grammar to defform, etc (293b208a)
sstrickl:
- with-contract improvements (539c25bb)
chrdimo:
- support for multiple blame parties (17e419e7)
- added option contracts (5808b0c4)
bfetscher:
- redex-generator: determine bound order automatically (2a9d4221)
stamourv:
- move optimization coach to planet2 (2c8e5f9a)
asumu:
- make srfi/19 compat with date* (d406e2db)
- separate in/out contracts for parameters (3ddde6a7)
Michael Filonenko:
- extflonums (17b80926)
- extflounum unboxing (840fc9c6)
Eric Dobson:
- AnyValues type (aac25b42)
Tobias Hamer:
- readline improvements (0f6a5833)
- support multiple values in wrap-evt and handle-evt (7e2b443f)
Patrick Mahoney:
- move eopl language to racket (b265e260)
Chris Jester-Young:
- fix srfi/61 use of =, else (9e93ee26)
Juan Francisco Cantero Hurtado:
- fix configure for openbsd (292c81a8)
William Bowman:
- changed define-union-language to merge nts (b0db8798, 42847ea5)
--
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] Pre-Release Checklist for v5.3.4
Checklist items for the v5.3.4 release (using the v5.3.3.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * Matthew Flatt mfl...@cs.utah.edu - Racket Tests - Languages Tests - GRacket Tests (Also check that `gracket -z' and `gracket-text' still works in Windows and Mac OS X) - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests - JPR's test suite - Create an executable from a BSL program - Run COM tests - Try compiling with -funsigned-char - Try compiling with TEST_ALTERNATE_TARGET_REGISTER Updates: - Racket Updates: update HISTORY (updates should show v5.3.4 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. * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests - Redex Tests Updates: - DrRacket Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v5.3.4 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. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v5.3.4 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests - Typed Racket Updates: update HISTORY (updates should show v5.3.4 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v5.3.4 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper r...@cs.utah.edu - Macro Debugger Tests - Syntax Classifier Tests - RackUnit GUI Tests - Data Tests - DB Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Stevie Strickland sstri...@ccs.neu.edu - Unit Contract Tests - Contract Region Tests - Class Contract Tests * Stephen Chang stch...@ccs.neu.edu - Lazy Racket Tests - Lazy stepper tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Verify PL language - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (. .../racket-completion.zsh; _racket --self-test) Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests * Greg Cooper g...@cs.brown.edu - FrTime Tests * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine (note that they're still called `plt' and `mz' at this stage). - 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
[racket-dev] Release for v5.3.4 has begun
The release process for v5.3.4 has begun: the `release' branch was created for any work that is left and is now bumped to v5.3.3.900. You can go on using the `master' branch as usual, it is now bumped to v5.3.4.1 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Please make sure that code that you're responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release. NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT The time between the `release' branch creation and the actual release is for fixing new errors that prevent proper functioning of major components and that show up during the preparation for a release. You can also finalize piece of work that is not yet complete, but please avoid merging new features. Note that nightly builds will go on as usual (starting from v5.3.4.1 and going up as usual), and pre-release builds will be available shortly at http://pre.racket-lang.org/release/ Please tell me if you think that this release is significant enough that it should be announced on the users list for wider testing. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26528: master branch updated
On 04/02/2013 11:48 PM, Asumu Takikawa wrote: On 2013-03-30 10:10:20 -0400, ry...@racket-lang.org wrote: 293b208 Ryan Culpepper ry...@racket-lang.org 2013-03-20 10:52 : | added optional #:grammar clause to defform, etc : M collects/scribble/private/manual-form.rkt | 68 - M collects/scribblings/scribble/manual.scrbl | 132 ++ Is this the preferred way of documenting forms now? It does look more convenient, and I noticed that `defform/subs` and friends are now relegated to a smaller corner of the docs. Well, *I* prefer it, and I hope people will use it when writing new documentation. No one has suggested deprecating the old forms, though. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] The next Racket release is about to begin
The release process for the next Racket release 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
Re: [racket-dev] Stumped!
The line (date-day quando)99 looks pretty suspicious; with the 99 there, the first branch of the enclosing 'if' expression returns 8 values but the second branch returns 7 values. Ryan On 02/22/2013 09:48 AM, Pierpaolo Bernardi wrote: This one got me stumped for a while. I don't remember a case like this ever occurring in the past, so I'm thinking that maybe this is a regression? In DrRacket, with debugging and stacktrace enabled in all the buffers involved, when I run the file strano.rkt, I get this error: Welcome to DrRacket, version 5.3.3.3--2013-02-16(1ddacff/a) [3m]. Language: racket [custom]; memory limit: 16000 MB. . . result arity mismatch; expected number of values not received expected: 7 received: 8 from: in: local-binding form values...: 2013 2 22 99 14 17 36.15819 0 And the region of source highlighted is the let*-values expression starting at line 28 in strano.rkt. However, the error is not there: it's in the function equation-of-time-alt at line 272 in astronomia.rkt, and DrRacket gave me no hint of where the error actually happened. If this is what DrRacket always did, I'm surprised I had not stumped over this before. If it's a novelty, then I don't like it. 8^) (I'm attaching the two files mentioned, for reference. They are not compilable alone, because there are other components missing, one of these being a foreign library. I can supply all of the missing sources, if requested. I can also supply the library as a win64 dll (and can compile it for win32 too)) Cheers P. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] When does 3D syntax get marshalled?
Your explanation sounds correct, but 3D syntax is not encouraged and not supported. I think the fix is to change your macro to avoid 3D syntax. It's a little awkward due to the lack of let-for-syntax (and splicing-let-for-syntax, I guess), but how about the following (not tested): (define-syntax-rule (M id body) (splicing-let*-syntax ([new-tr (let ([p-tr (syntax-parameter-value #'p)]) (λ (syn) (syntax-case syn () [(_ e) (p-tr #'(foo e))])))] [id (λ (stx) (syntax-case stx () [(_ blah) #`(splicing-syntax-parameterize ([p (syntax-local-value #'new-tr)]) (id blah))])))]) body)) ... except that there doesn't seem to be a splicing-let*-syntax, either, so you'll have to do this instead (or use splicing-letrec-syntax, maybe): (define-syntax-rule (M id body) (splicing-let-syntax ([new-tr (let ([p-tr (syntax-parameter-value #'p)]) (λ (syn) (syntax-case syn () [(_ e) (p-tr #'(foo e))])))]) (splicing-let-syntax ([id (λ (stx) (syntax-case stx () [(_ blah) #`(splicing-syntax-parameterize ([p (syntax-local-value #'new-tr)]) (id blah))]))]) body)) Ryan On 01/22/2013 06:19 PM, J. Ian Johnson wrote: [Moving to dev] The problem is with the implementation of splicing-syntax-parameterize, which turns the parameterization of p to #,new-tr into a TOP LEVEL define-syntax, which does NOT expand away, leading to this borkage. This calls for an mflatt. -Ian - Original Message - From: J. Ian Johnson i...@ccs.neu.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: users us...@racket-lang.org Sent: Tuesday, January 22, 2013 6:08:49 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket] When does 3D syntax get marshalled? I found that this example does NOT work if you take the use of M out of its expression context. Problem program: #lang racket (require racket/stxparam racket/splicing) (define-syntax-parameter p #f) (define-syntax-rule (M id body) (splicing-let-syntax ([id (let* ([p-tr (syntax-parameter-value #'p)] [new-tr (λ (syn) (syntax-case syn () [(_ e) (p-tr #'(foo e))]))]) (λ (stx) (syntax-case stx () [(_ blah) #`(splicing-syntax-parameterize ([p #,new-tr]) (id blah))])))]) body)) (define-syntax-rule (F x) (list x)) (splicing-syntax-parameterize ([p (syntax-rules () [(_ e) e])]) (M F (F 'small-example))) Thoughts? -Ian - Original Message - From: J. Ian Johnson i...@ccs.neu.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: users us...@racket-lang.org Sent: Tuesday, January 22, 2013 1:48:55 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket] When does 3D syntax get marshalled? Here is a concrete example that is an outline of what I do. It works. However, in my project, when I replace F with the form that I actually defined and mix in more for p's transformer, I get that new-tr cannot be marshalled in the compiled code. This baffles me. #lang racket (module A racket (require racket/stxparam racket/splicing) (provide M p) (define-syntax-parameter p #f) (define-syntax-rule (M id body) (splicing-let-syntax ([id (let* ([p-tr (syntax-parameter-value #'p)] [new-tr (λ (syn) (syntax-case syn () [(_ e) (p-tr #'(foo e #;mix-in-more-here))]))]) (λ (stx) (syntax-case stx () [(_ blah) #`(splicing-syntax-parameterize ([p #,new-tr]) (id blah #;mix-in-more-here))])))]) body))) (module B racket (require (submod .. A) racket/splicing) (define-syntax-rule (F x) (list x)) (splicing-syntax-parameterize ([p (syntax-rules () [(_ e) e])]) (printf ~a~% (M F (F 'small-example) (require 'B) Very frustrating. -Ian - Original Message - From: J. Ian Johnson i...@ccs.neu.edu To: users us...@racket-lang.org Sent: Tuesday, January 22, 2013 12:12:28 PM GMT -05:00 US/Canada Eastern Subject: [racket] When does 3D syntax get marshalled? I have a fairly crazy macro that chains together syntax transformers that are stored in syntax-parameters to get a sort of macro mix-in if you will. In order to do this, I have code that looks like the following: (define old-tr (syntax-parameter-value #'p)) (define new-tr (syntax-parser [(_ blah) (old-tr #'(modified-blah))])) (syntax-parser [(_ macro-in) #'(syntax-parameterize ([p #,new-tr]) macro-out)]) Often this works. However, I am now putting this kind of code inside of a let-syntax that is the product of a macro that is given the identifier to bind in the let-syntax. The use of this macro uses the bound identifier, which (in my head) should just use this transformer, expand away and not have to be marshalled. There
[racket-dev] Pre-Release Checklist for v5.3.2
Checklist items for the v5.3.2 release (using the v5.3.1.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * Matthew Flatt mfl...@cs.utah.edu - Racket Tests - Languages Tests - GRacket Tests (Also check that `gracket -z' and `gracket-text' still works in Windows and Mac OS X) - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests - JPR's test suite - Create an executable from a BSL program - Run COM tests - Try compiling with -funsigned-char Updates: - Racket Updates: update HISTORY (updates should show v5.3.2 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. * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests - Redex Tests Updates: - DrRacket Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v5.3.2 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. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v5.3.2 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests - Typed Racket Updates: update HISTORY (updates should show v5.3.2 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v5.3.2 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper r...@cs.utah.edu - Macro Debugger Tests - Syntax Classifier Tests - RackUnit GUI Tests - Data Tests - DB Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Stevie Strickland sstri...@ccs.neu.edu - Unit Contract Tests - Contract Region Tests - Class Contract Tests * Stephen Chang stch...@ccs.neu.edu - Lazy Racket Tests - Lazy stepper tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (. .../racket-completion.zsh; _racket --self-test) Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests * Greg Cooper g...@cs.brown.edu - FrTime Tests * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine (note that they're still called `plt' and `mz' at this stage). - 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
[racket-dev] Release Announcement for v5.3.2
The release announcement sketch that I have so far is below. Please
mail me new items and/or edits.
--
mflatt:
- generalized local-type tracking for unboxing (bdf1c3e1)
- removed sirmail (3e505af4)
- added file/untar (3a76581a), file/untgz (0f47069f), file/unzip
(8a77d87a)
- raco setup: use db for doc tags (8c1b5db8)
- serialize: simplify quotable values (20bdbb6d)
- f[xl]vectors: read/write (492167c2 with tewk, 9cf821b3) and
serialize (9e8477dd)
- faster FFI calls (42a03421)
- support MinGW build (5b016b4c)
- ffi/com: added com-get-property* (0f909af7)
- added phantom byte strings (aa08a684)
- added exn:fail:{filesystem,network}:errno (cdfc4912)
jay:
- planet2 (fae660b0), versions for dependencies (0e140a81)
robby:
- improvements to online check syntax (c6caf113)
- added show-derivations to redex (9377b634)
- improved language dialog (c02797b1)
- deprecated mrlib/cache-image-snip (0b332a17)
- sped up tab switching (4e95220d)
ntoronto:
- math library (f2dc2027, 0936d8c2, 3670916a)
- plot/typed (5a2aa226)
stamourv:
- serialize srclocs (cc8bd4f2)
- define-inline (b715a6fe)
ryanc:
- ssl additions (d6cb2ece, f446adad, ba62b1dd)
- ssl default CA certs (4b4113d5, 7b0a13bf, 10a34881)
- db: start-transaction (05e7e61d), exn (30397acc), sql-bits (a2ae8137)
- racket/lazy-require (fd7d8a41)
matthias:
- batch-io updates (69800aa5)
eli:
- DMG improvements (baa0e126, 48380b48)
bfetscher:
- define-relation improvements (cf9b0f77)
jensaxel:
- bit-vectors (028d14a8)
Joe Gibbs Politz:
- added check-match to rackunit (e264e414)
Nadeem Abdul Hamid:
- automatic paren mode improvements (8f3343cd)
J. Ian Johnson:
- optimize singleton sequences (889f1591)
Greg Hendershott:
- markdown rendering mode for Scribble (6aa6dc04)
--
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] bug in ~r
I just pushed a fix. Thanks for reporting this! Ryan On 01/13/2013 10:48 AM, Matthew Flatt wrote: It's still broken. Although I don't get an error with the latest sources (v5.3.2.1), the output is not right: (~r (/ 15625 16384) #:min-width 4 #:precision 1) 0.1 (~r (/ 15625 16384)) 0.953674 At Sun, 13 Jan 2013 10:40:04 -0500, Curtis Dutton wrote: I think this is a bug... (~r (/ 15625 16384) #:min-width 4 #:precision 1) gives me make-string: contract violation expected: exact-nonnegative-integer? given: -1 argument position: 1st other arguments...: #\0 Can anyone else reproduce this? If so I'll file it as a bug... Thanks, Curt _ 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] racket/date, SRFI-19, date construction
I don't know how important this is, but ideally serialized old SRFI-19 dates should now deserialize as date*. I think that you can just restore the definition of deserialize-info:tm:date-v0 and change the second function (the cyclic value builder) to raise an error: (define deserialize-info:tm:date-v0 (make-deserialize-info srfi:make-date (lambda () (error 'deserialize-info:tm:date-v0 cycles not allowed and also restore the provide. Ryan On 01/11/2013 09:13 PM, Asumu Takikawa wrote: On 2013-01-11 15:39:08 -0600, Robby Findler wrote: I think it would be great if you were to find backwards-compatible ways to bring these two a little bit closer. Making them use the same internal date struct, for example, would be a great thing. I wrote a patch to make both of these use the same structure, attached to the e-mail. It seems to pass all of the srfi-19 and date tests (with some tests changed where appropriate). Does it look alright? It turns out there was one (sort of) good reason for SRFI-19 to define its own struct type: it used mutation for several functions. Racket's date/date* are immutable. I just changed these to use functional update. Another thing: when a string is converted to a date, it's possible that the format string only has time-of-day but no date specification. Previously, this produced a srfi/19 date with '#t's but I've now defaulted it to the start day of the Unix epoch (arbitrarily). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release for v5.3.2 has begun
The release process for v5.3.2 has begun: the `release' branch was created for any work that is left and is now bumped to v5.3.1.900. You can go on using the `master' branch as usual, it is now bumped to v5.3.2.1 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Please make sure that code that you're responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release. NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT The time between the `release' branch creation and the actual release is for fixing new errors that prevent proper functioning of major components and that show up during the preparation for a release. You can also finalize piece of work that is not yet complete, but please avoid merging new features. Note that nightly builds will go on as usual (starting from v5.3.2.1 and going up as usual), and pre-release builds will be available shortly at http://pre.racket-lang.org/release/ Please tell me if you think that this release is significant enough that it should be announced on the users list for wider testing. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] egal?
It sounds like an easier solution would be to switch from boxes to a mutable struct with one field that overrides equal? and hash-code. Ryan On 12/17/2012 03:38 PM, J. Ian Johnson wrote: Short message: is there any chance of getting egal and egal hashes any time soon? Longer message: I have a situation where I key my hashes with immutable structs, but something they contain has a box that later is updated and never changed. I'd really like for the struct value before the set-box! to be keyed to and positively compare to the value after this set-box! happens. Otherwise I have to do something abstraction-breaking to separate these boxes from the structures which would likely introduce more overhead (yet another hash lookup). I'm going to look into just hacking egal in myself, but want to know what the other devs know about this. Thanks, -Ian _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] bit-vectors and serialization
On 12/17/2012 04:30 AM, Jens Axel Søgaard wrote: 2012/12/17 Ryan Culpepper r...@cs.utah.edu: I'd like to make bit-vectors serializable so I can replace sql-bits with them. I'll deprecate the current sql-bits names but keep them around for a while. The issue is that bit-vectors are implemented using fxvectors, which are serializable, but simply serializing them will presumably cause errors if a bit-vector is serialized on a 64-bit machine and deserialized on a 32-bit machine or vice versa. One solution would be to use bytes instead of fxvectors. The performance is about the same as far as I could tell using the sieve benchmark. Another option is to declare that serialization across word sizes doesn't work for bit vectors. Any opinions? The sieve-benchmark works on individual bits, so it makes sense that the performance is about the same. What happens for operations that work on words (e.g. the popcount operation)? My intuition is that these operations will be slower. True, popcount takes about three times as long as it used to. With a few additional changes, popcount on a million-bit bit-vector takes 1.1 ms using bytes, as opposed to 0.35 ms using fxvectors. (Tested on a 64-bit machine.) Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] bit-vectors and serialization
I'd like to make bit-vectors serializable so I can replace sql-bits with them. I'll deprecate the current sql-bits names but keep them around for a while. The issue is that bit-vectors are implemented using fxvectors, which are serializable, but simply serializing them will presumably cause errors if a bit-vector is serialized on a 64-bit machine and deserialized on a 32-bit machine or vice versa. One solution would be to use bytes instead of fxvectors. The performance is about the same as far as I could tell using the sieve benchmark. Another option is to declare that serialization across word sizes doesn't work for bit vectors. Any opinions? Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
I understood the feature request differently. I take it as wanting to write a module like the following: #lang racket (provide (with-declared-contracts-out f g)) (declare-contract f ) (define f ) (declare-contract g ) (define g ) That is, the contracts themselves are near the functions, so it's easy to keep them in sync. And one can find the names provided by just looking at the top of the module---but you only get the names, not the contracts, so the interface is incomplete. This should be easily doable with some compile-time state. Ryan On 12/14/2012 11:41 AM, Greg Hendershott wrote: Matthias has vastly more experience and perspective in matters like this; you would be wise to prefer his advice. But if I understand correctly what you want, I think you could do this yourself with a simple macro: (define-syntax define/contract/provide (syntax-rules () [(_ (id . args) contract body ...) (begin (define/contract (id . args) contract body ...) (provide id))] [(_ id contract expr) (begin (define/contract id contract expr) (provide id))])) That's the version I've used in some past projects. However: It uses define/contract promiscuously, which is (a) not universally beloved and (b) much slower than provide/contract in the current version of Racket. Instead I think you could flip it around to use provide/contract, instead: (define-syntax define/provide/contract (syntax-rules () [(_ (id . args) contract body ...) (begin (provide/contract (id . args) contract body ...) (define id))] [(_ id contract expr) (begin (provide/contract id contract expr) (define id))])) I _think_ that's essentially what you're asking for? (Of course this means the function won't be protected by a contract when called from inside the module, which could be considered bad, good, or N/A. Just be aware.) Any approach not using a single provide/contract list has the disadvantage that Matthias explained: The module no longer has a contiguous description of its interface in the source. That's a serious disadvantage. Some might consider it mitigated if the module has Scribble documentation. Also someone reading the source might collapse in Emacs (or whatever) to quickly see all the top-level definitions (although that would include any non-provided items, so it's not perfect (unless the stock collapse is customized)). You could also put a list in comments, I suppose. On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: It is critical to inform clients of the services that a module provides. In the absence of types, contracts are the closest information we have. Reading the implementation is against all good SE ideas. IF we could assume that people always programmed in DrRacket, we could compromise and add a tool that synthesizes the interface of a module in some way. Since some contributors break this guideline all the time anyway, we should have such a tool available anyway. BUT there are also people who use Emacs and the other editor. So, if you want to be good, put provide contract-out at the top of your module. On Dec 14, 2012, at 1:02 AM, Harry Spier wrote: If you place provide/contract at the beginning of a module it makes the interface clear but it is separated from its function. If you place it right before its function and not at the top of the module, it makes the function clearer but the module interface is not so clear. Is it possible (would it be a good idea?) to provide a new form that splits the provide/contract form into two parts. One part the contract definition which you could place immediately before the function definition and the second part a provide spec for inclusion in a provide statement that included the function name but not the contract spec.) . That way the contract definition can be by the function definition and the function name can be in a provide statement at the beginning of the module. Harry Spier _ 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 _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] planet2 and versions
I'm trying to understand how things are supposed to work in planet2 without version information. Let's say I release a package, webapis. Time passes, and I notice that Racket gets some cool new features (eg, better SSL support) that the webapis package should use. I write the code, and ... Do I release the new code under the same package name? If so, then the package breaks for older versions of Racket, because IIUC planet2 has nothing corresponding to planet1's 'required-core-version field. And there doesn't seem to be a way to tell Racket no, sorry, go back to the older version of the package. (Rather, there's no way for a client to do so. The fix would be for the package maintainer to release an upgrade that reverts to the old code.) So it seems like it would be really bad for me to release the new code under the name webapis. In other words, if a package changes its dependencies, that's an incompatible change for the package, and it needs a new name. Right? Suppose I release the new code as webapis2. And suppose there's another package (let's call it scriblogify) that depends on webapis. If that code wants to use webapis2, that's a dependency change, so it would have to be released as scriblogify2. There's no way to express link me with the most recent compatible version of webapis*, right? Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] planet2 and versions
On 12/12/2012 03:13 PM, Carl Eastlund wrote: I believe it is by design that Planet 2 does not resolve this kind of issue. This gives us room to experiment with different solutions without committing to one up-front, since Planet 1 ran into various limitations of its built-in policies. I will propose one possible solution for your webapis example. Distribute a primary wrapper package called webapis and separate specific versions such as webapis1, webapis2, and so forth. Have the code in webapis determine at compile-time which specific version of webapis is appropriate for the current Racket version and install that package. The specific packages would contain the actual code a client would import. That way, installing the webapis package on any Racket version would install only the version of the implementation that works. IIUC, a package's dependencies are fixed at package creation time; they can't be adjusted at compile time. (Well, now that the dependencies are specified via an expression in a #lang setup/infotab file, maybe it's possible to adjust them at compile time... or maybe installation time? But there's still no access to the Racket version, although there's access to other things) Ryan I don't know if this is a complete solution, but it seems like a reasonable starting point. As we figure out what patterns work, they themselves can be developed as reusable tools and built into their own packages. I think this room for improvement will make Planet 2 a much better long-term model than Planet 1. Of course we do eventually want a default system that package developers can use without too much mucking about with experimental versioning systems. But I think an initial period of crowd-sourcing the design of that system will do us some good. Carl Eastlund On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper r...@cs.utah.edu mailto:r...@cs.utah.edu wrote: I'm trying to understand how things are supposed to work in planet2 without version information. Let's say I release a package, webapis. Time passes, and I notice that Racket gets some cool new features (eg, better SSL support) that the webapis package should use. I write the code, and ... Do I release the new code under the same package name? If so, then the package breaks for older versions of Racket, because IIUC planet2 has nothing corresponding to planet1's 'required-core-version field. And there doesn't seem to be a way to tell Racket no, sorry, go back to the older version of the package. (Rather, there's no way for a client to do so. The fix would be for the package maintainer to release an upgrade that reverts to the old code.) So it seems like it would be really bad for me to release the new code under the name webapis. In other words, if a package changes its dependencies, that's an incompatible change for the package, and it needs a new name. Right? Suppose I release the new code as webapis2. And suppose there's another package (let's call it scriblogify) that depends on webapis. If that code wants to use webapis2, that's a dependency change, so it would have to be released as scriblogify2. There's no way to express link me with the most recent compatible version of webapis*, right? Ryan _ Racket Developers list: http://lists.racket-lang.org/__dev http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] planet2 and versions
On 12/12/2012 03:58 PM, Jay McCarthy wrote: I agree with Carl. But I would make an even stronger suggestion, I would suggest that you completely drop support for old Racket versions and if necessary release webapis-lts and scriblogify-lts packages that conflict with webapis and can only work on old versions. The LTS ones wouldn't be included in the DrDr-tested collection of packages, but the others would be. Casual users should upgrade and users with serious version problems should upgrade slowly with only the LTS versions. If I understand correctly, you are saying that non-LTS packages should ignore the recommendation of the FAQ (6.5, package authors should not make backwards incompatible changes to packages). That doesn't sound like a good solution. If I want to support users running versions of Racket that are a couple releases old, it doesn't work. If I want to depend on other packages, then in the absence of a standard approach I've got to trust that they have the same notions about compatibility and versions-encoded-as-package-names as I do. If I want to support Racket back to X.Y, I had better hope that the packages I depend on do too. That is, I'd have to figure out how each of them (and all of their dependencies) handle compatibility instead of just trusting that they all follow the single standard approach. Finally, as a meta-point, is there any evidence that just throwing away versions will work? Any precedents? So far, this seems like a classic case of throwing the baby out with the bathwater: versions sometimes cause problems... so we won't have them. Now we have the same problems but fewer tools for handling them. (See also Eli's response.) If planet2 is aimed at a problem that is restricted in scope somehow that it doesn't need to worry about version issues, I still don't understand what that narrower problem is. If I'm supposed to think about planet2 as a way of distributing code, I'm still confused about what my obligations are when I create a package and what I can rely on from other packages. Ryan I would also hope that P2's lack of an ability to depend on the core version would induce better backwards and forwards compatibility from Racket in the version. But I'm a bit radical on this front, so I assume that we will have a robust alternative based on Carl's idea that uses P2 underneath it. Jay On Wed, Dec 12, 2012 at 1:13 PM, Carl Eastlund c...@ccs.neu.edu wrote: I believe it is by design that Planet 2 does not resolve this kind of issue. This gives us room to experiment with different solutions without committing to one up-front, since Planet 1 ran into various limitations of its built-in policies. I will propose one possible solution for your webapis example. Distribute a primary wrapper package called webapis and separate specific versions such as webapis1, webapis2, and so forth. Have the code in webapis determine at compile-time which specific version of webapis is appropriate for the current Racket version and install that package. The specific packages would contain the actual code a client would import. That way, installing the webapis package on any Racket version would install only the version of the implementation that works. I don't know if this is a complete solution, but it seems like a reasonable starting point. As we figure out what patterns work, they themselves can be developed as reusable tools and built into their own packages. I think this room for improvement will make Planet 2 a much better long-term model than Planet 1. Of course we do eventually want a default system that package developers can use without too much mucking about with experimental versioning systems. But I think an initial period of crowd-sourcing the design of that system will do us some good. Carl Eastlund On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper r...@cs.utah.edu wrote: I'm trying to understand how things are supposed to work in planet2 without version information. Let's say I release a package, webapis. Time passes, and I notice that Racket gets some cool new features (eg, better SSL support) that the webapis package should use. I write the code, and ... Do I release the new code under the same package name? If so, then the package breaks for older versions of Racket, because IIUC planet2 has nothing corresponding to planet1's 'required-core-version field. And there doesn't seem to be a way to tell Racket no, sorry, go back to the older version of the package. (Rather, there's no way for a client to do so. The fix would be for the package maintainer to release an upgrade that reverts to the old code.) So it seems like it would be really bad for me to release the new code under the name webapis. In other words, if a package changes its dependencies, that's an incompatible change for the package, and it needs a new name. Right? Suppose I release the new code as webapis2. And suppose there's another package (let's call
Re: [racket-dev] [plt] Push #25831: master branch updated
I updated the references in the racket git repo, and I left the unstable/lazy-require module in place with a re-export of lazy-require. I did remove a feature that didn't seem to be in use (unquote), though, so if someone is using lazy-require with unquote outside of the racket git repo, that will break. Ryan On 12/03/2012 07:57 PM, Robby Findler wrote: Does the lazy-require move break code? Robby On Mon, Dec 3, 2012 at 6:40 PM, ry...@racket-lang.org wrote: ryanc has updated `master' from 0252207e38 to 33f3574f7e. http://git.racket-lang.org/plt/0252207e38..33f3574f7e =[ 4 Commits ]== Directory summary: 10.7% collects/racket/ 39.3% collects/unstable/scribblings/ 44.7% collects/unstable/ 5.1% collects/ ~~ [...] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] tiny doc bug?
On 12/01/2012 04:23 AM, David Vanderson wrote: http://docs.racket-lang.org/data/Orders_and_Ordered_Dictionaries.html Towards the bottom of this page there is the following error: (datum-order (make-fish 'alewife) (make-fish 'sockeye)) make-fish: undefined; cannot reference undefined identifier Is this intentional? No, it's a bug. I've pushed a fix. Thanks, Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25698: master branch updated
On 11/16/2012 04:43 PM, Neil Toronto wrote: On 11/16/2012 02:10 PM, mfl...@racket-lang.org wrote: 9a48e5d Matthew Flattmfl...@racket-lang.org 2012-11-16 14:03 : | math: avoid import at unnecessary phase | | This repair avoids using at compile time external libraries that | are needed at run time. : M collects/math/private/matrix/matrix-sequences.rkt | 4 +--- [...] collects/math/private/matrix/matrix-sequences.rkt ~ --- OLD/collects/math/private/matrix/matrix-sequences.rkt +++ NEW/collects/math/private/matrix/matrix-sequences.rkt @@ -5,9 +5,7 @@ in-column) (require math/array - (except-in math/matrix in-row in-column) - (for-syntax (except-in math/matrix in-row in-column)) - (for-template (except-in math/matrix in-row in-column))) + (except-in math/matrix in-row in-column)) Was this the only necessary change? If so, it's a little weird, because libmpfr isn't supposed to be loaded until its first export is used. The constants are all delayed (their names are bound to macros that expand to uses of `force'), and every function and delay thunk is wrapped with code that loads the external library. IOW, this: (require math/bigfloat) doesn't load libmpfr, but this does: pi.bf Also, I have no idea what it all has to do with a typed submodule in math/special-functions.rkt, which is apparently what the error was complaining about. I can't work out the dependency chain. Help? (FWIW, you're right about libmpfr not being needed at compile time. Well, it shouldn't be. I used Eli's nifty interaction-fakery code forms in the `math/bigfloat' docs, for example.) If you made bigfloats serializable, you could also use 'make-log-based-eval' from unstable/sandbox as an alternative to 'eval:alts'. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Math library pushed
I get this message (during doc build, actually): raco setup: error running: (lib math/scribblings/math.scrbl) ffi-lib: couldn't open libmpfr.so (libmpfr.so: cannot open shared object file: No such file or directory) I have /usr/lib/libmpfr.so.1, which is symlinked to /usr/lib/libmpfr.so.1.2.2. I expect that libmpfr.so (no version number) is provided by the development package. I changed math/private/bigfloat/mpfr.rkt to use the following lines instead: (define libgmp (lazy (ffi-lib libgmp '( 3) #:get-lib-dirs get-lib-dirs))) (define libmpfr (lazy (ffi-lib libmpfr '( 1) #:get-lib-dirs get-lib-dirs))) (Running 32-bit Ubuntu 10.04.4) When I run the test file with the changes, it works, and the last four digits are 4888 as expected. Looks like my work machine (64-bit Ubuntu 12.10) has libmpfr.so.4 and libgmp.so.10. I haven't run the test program there yet. Ryan On 11/16/2012 01:59 PM, Neil Toronto wrote: [...] One thing I'm not sure of is whether the FFI to libmpfr works on all our supported platforms. Could I have all the devs run the following program after your next compile? #lang racket (require math/bigfloat) (parameterize ([bf-precision 8192]) pi.bf) Then reply with the last four digits printed. They should be 4888. If the program doesn't run because Racket can't load libmpfr, it's an opportunity to test the documentation. Please see if I've made the docs for the `math/bigfloat' module clear enough to help you fix the problem. Thanks! Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pre-Release Checklist for v5.3.1, Second Call
Checklist items for the v5.3.1 release (using the v5.3.0.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests - Typed Racket Updates: update HISTORY (updates should show v5.3.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v5.3.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper r...@cs.utah.edu - Macro Debugger Tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Danny Yoo d...@cs.wpi.edu - Whalesong Tests (confirm that Whalesong runs from PLaneT) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25530: master branch updated
That's the plan. Ryan On 10/22/2012 07:30 PM, Sam Tobin-Hochstadt wrote: Will these be in 5.3.1? Without this fix, the macro stepper is very broken. Sam On Oct 22, 2012 3:05 PM, ry...@racket-lang.org mailto:ry...@racket-lang.org wrote: ryanc has updated `master' from f60d57a27f to 1137b444ad. http://git.racket-lang.org/plt/f60d57a27f..1137b444ad =[ 2 Commits ]== Directory summary: 60.2% collects/macro-debugger/model/ 39.7% collects/macro-debugger/ ~~ 5f15401 Ryan Culpepper ry...@racket-lang.org mailto:ry...@racket-lang.org 2012-10-22 17:09 : | macro stepper: fix bug re taking over run button | Closes PR 13019 : M collects/macro-debugger/tool.rkt | 9 ++--- ~~ 1137b44 Ryan Culpepper ry...@racket-lang.org mailto:ry...@racket-lang.org 2012-10-22 17:26 : | macro-stepper: show errors in provide expansion | closes PR 13018 : M collects/macro-debugger/model/reductions.rkt | 17 ++--- =[ Overall Diff ]=== collects/macro-debugger/model/reductions.rkt --- OLD/collects/macro-debugger/model/reductions.rkt +++ NEW/collects/macro-debugger/model/reductions.rkt @@ -222,12 +222,7 @@ [#:learn (list #'?var)])] [(Wrap p:provide (e1 e2 rs ?1 inners ?2)) - (let ([wrapped-inners -(for/list ([inner (in-list inners)]) - (match inner -[(Wrap deriv (e1 e2)) - (make local-expansion e1 e2 - #f e1 inner #f e2 #f)]))]) + (let ([wrapped-inners (map expr-local-action inners)]) (R [! ?1] [#:pattern ?form] [#:pass1] @@ -668,7 +663,9 @@ [#:do (DEBUG (printf ** module begin pass 2\n))] [ModulePass ?forms pass2] ;; ignore pass3 for now: only provides -)])) +[#:new-local-context + [#:pattern ?form] + [LocalActions ?form (map expr-local-action (or pass3 null))]])])) ;; ModulePass : (list-of MBRule) - RST (define (ModulePass mbrules) @@ -796,6 +793,12 @@ (when #f (apply error sym args))) +(define (expr-local-action d) + (match d +[(Wrap deriv (e1 e2)) + (make local-expansion e1 e2 + #f e1 d #f e2 #f)])) + ;; opaque-table ;; Weakly remembers assoc between opaque values and ;; actual syntax, so that actual can be substituted in collects/macro-debugger/tool.rkt --- OLD/collects/macro-debugger/tool.rkt +++ NEW/collects/macro-debugger/tool.rkt @@ -269,8 +269,12 @@ (set! user-custodian (current-custodian))) (define (uncaught-exception-raised) ;; =user= -;; formerly shut down user custodian -(void)) +(set! normal-termination? #t) +(parameterize ([current-eventspace drs-eventspace]) + (queue-callback + (λ () + (cleanup) + (custodian-shutdown-all user-custodian) (define (show-error-report/tab) ;; =drs= (send the-tab turn-on-error-report) (send (send the-tab get-error-report-text) scroll-to-position 0) @@ -294,7 +298,6 @@ (parameterize ([current-eventspace drs-eventspace]) (queue-callback (λ () -(send the-tab syncheck:clear-highlighting) (cleanup) (custodian-shutdown-all user-custodian)) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] build problems on plt/release branch?
Try building the release branch in a fresh clone. (It should be safe to clone your existing clone (or checkout) rather than clone directly from the server.) If the errors go away, I would suspect the problem is that git clean missed some things. I just tried it and encountered no errors. Ryan On 10/17/2012 01:13 PM, Danny Yoo wrote: Does anyone else see severe build problems on the plt/release branch? I'm seeing a lot of compile-time errors during 'raco setup'; it's making it difficult to test things because when a problem occurs, I'm not sure if it's my fault or if the repo is just in a weird state. I made sure to clean my local repository by doing: git clean -fdx at the root of the git repo, just to make sure nothing else was interfering with the build. I'm at 513f85baa2051cd7428ac008e5b2d1e6858f52d6. I'm including a sampling of the output below: raco setup: 0 making: tmp/racket/collects/2htdp (HtDP/2e Teachpacks) image.rkt:37:9: module: identifier already imported from: (all-except ../mrlib/image-c... at: render-image in: private/image-more.rkt context...: /Users/dyoo/local/racket/collects/compiler/cm.rkt:350:0: compile-zo* /Users/dyoo/local/racket/collects/compiler/cm.rkt:551:26 /Users/dyoo/local/racket/collects/compiler/cm.rkt:544:42 /Users/dyoo/local/racket/collects/compiler/cm.rkt:509:0: maybe-compile-zo /Users/dyoo/local/racket/collects/compiler/cm.rkt:622:2: do-check /Users/dyoo/local/racket/collects/compiler/cm.rkt:696:4 /Users/dyoo/local/racket/collects/setup/parallel-do.rkt:419:20: loop order.rkt:17:0: define-generics: bad syntax in: (define-generics (ordered-dict gen:ordered-dict prop:ordered-dict ordered-dict? #:defined-table dict-def-table #:prop-defined-already? #f) (dict-iterate-least ordered-dict) (dict-iterate-greatest ordered-dict) (dict-iterate-least/? ordered-dict key) (d... context...: /Users/dyoo/local/racket/collects/racket/private/modbeg.rkt:46:4 /Users/dyoo/local/racket/collects/compiler/cm.rkt:350:0: compile-zo* /Users/dyoo/local/racket/collects/compiler/cm.rkt:551:26 /Users/dyoo/local/racket/collects/compiler/cm.rkt:544:42 /Users/dyoo/local/racket/collects/compiler/cm.rkt:509:0: maybe-compile-zo /Users/dyoo/local/racket/collects/compiler/cm.rkt:622:2: do-check /Users/dyoo/local/racket/collects/compiler/cm.rkt:696:4 /Users/dyoo/local/racket/collects/setup/parallel-do.rkt:419:20: loop raco setup: 0 making: tmp/racket/collects/errortrace/private namespace-attach-module: unknown module (in the source namespace) name: #resolved-module-path:/Users/dyoo/local/racket/collects/errortrace/errortrace-key.rkt context...: /Users/dyoo/local/racket/collects/tmp/racket/collects/errortrace/errortrace-lib.rkt:474:0: make-errortrace-compile-handler /Users/dyoo/local/racket/collects/tmp/racket/collects/errortrace/errortrace-lib.rkt: [running body] /Users/dyoo/local/racket/collects/compiler/cm.rkt:350:0: compile-zo* /Users/dyoo/local/racket/collects/compiler/cm.rkt:551:26 /Users/dyoo/local/racket/collects/compiler/cm.rkt:544:42 /Users/dyoo/local/racket/collects/compiler/cm.rkt:509:0: maybe-compile-zo /Users/dyoo/local/racket/collects/compiler/cm.rkt:622:2: do-check /Users/dyoo/local/racket/collects/compiler/cm.rkt:696:4 /Users/dyoo/local/racket/collects/setup/parallel-do.rkt:419:20: loop raco setup: 0 making: tmp/racket/collects/honu/core define-honu-syntax: expected argument of type procedure (arity 1); given: #procedure:...syntax-parse.rkt:13:2 context...: /Users/dyoo/local/racket/collects/honu/core/private/transformer.rkt:18:0: make-honu-transformer /Users/dyoo/local/racket/collects/compiler/cm.rkt:350:0: compile-zo* /Users/dyoo/local/racket/collects/compiler/cm.rkt:551:26 /Users/dyoo/local/racket/collects/compiler/cm.rkt:544:42 /Users/dyoo/local/racket/collects/compiler/cm.rkt:509:0: maybe-compile-zo /Users/dyoo/local/racket/collects/compiler/cm.rkt:622:2: do-check /Users/dyoo/local/racket/collects/compiler/cm.rkt:696:4 /Users/dyoo/local/racket/collects/setup/parallel-do.rkt:419:20: loop _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pre-Release Checklist for v5.3.1
Checklist items for the v5.3.1 release (using the v5.3.0.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * Matthew Flatt mfl...@cs.utah.edu - Racket Tests - Languages Tests - GRacket Tests (Also check that `gracket -z' and `gracket-text' still works in Windows and Mac OS X) - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests - JPR's test suite - Create an executable from a BSL program - Run COM tests - Try compiling with -funsigned-char Updates: - Racket Updates: update HISTORY (updates should show v5.3.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. * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests - Redex Tests Updates: - DrRacket Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v5.3.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. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v5.3.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests - Typed Racket Updates: update HISTORY (updates should show v5.3.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v5.3.1 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper r...@cs.utah.edu - Macro Debugger Tests - Syntax Classifier Tests - RackUnit GUI Tests - Data Tests - DB Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Stevie Strickland sstri...@ccs.neu.edu - Unit Contract Tests - Contract Region Tests - Class Contract Tests * Stephen Chang stch...@ccs.neu.edu - Lazy Racket Tests - Lazy stepper tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (_racket --self-test) Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests * Greg Cooper g...@cs.brown.edu - FrTime Tests * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine (note that they're still called `plt' and `mz' at this stage). - 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] * Mike Sperber sper
[racket-dev] Release for v5.3.1 is about to begin
The release process for v5.3.1 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
Re: [racket-dev] Syntax errors in a Scribble evaluator look like documentation errors
On 09/11/2012 07:29 PM, Neil Toronto wrote: It doesn't seem to matter how I set up the evaluator (using `make-base-eval' or `make-evaluator'). If an example fails to typecheck, it looks like an ugly documentation error. This is an actual example in the math docs, which I would really like to keep: (flabs (exact-inexact 0.5f0)) eval:8:0: Type Checker: Expected Flonum, but got Positive-Single-Flonum in: (#%app exact-inexact (quote 0.5f0)) I want the error to look like it does in the REPL: Type Checker: Expected Flonum, but got Positive-Single-Flonum in: (exact-inexact 0.5f0) It seems all syntax errors are fugly: (cond [else 1.0] [else 2.0]) eval:11:0: cond: bad syntax (`else' clause must be last) at: (else 1.0) in: (cond (else 1.0) (else 2.0)) How can I fix this? The formatting of syntax errors is controlled by the error-print-source-location parameter. I hacked the formatting of syntax errors for the syntax/parse docs; see the beginning of syntax/scribblings/parse/parse-common.rkt for a starting point. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax parsing: must be a nice pattern-y way to do this
On 09/17/2012 02:20 PM, John Clements wrote: On Sep 16, 2012, at 5:48 PM, Ryan Culpepper wrote: See 'define-template-metafunction' in syntax/parse/experimental/template. Remember to change the relevant occurrences of 'syntax' to 'template'. Neat! I'm guessing, though, that I probably shouldn't release planet packages that depend on experimental-mumble… I think it's fine if you're prepared to update the package when it changes. If I do remove syntax/parse/experimental/template, I'll mark it as deprecated for a release cycle or two first. Ryan On 09/16/2012 08:31 PM, John Clements wrote: I want to apply a transformation to a nested pattern element. To start with, suppose I have a (kind of useless) with-handlers that looks like this: (with-syntax ([((arg ...) ...) #`((clause.input ...) ...)]) et-cetera) That is, I've basically just renamed clause.input to arg. But now, I want to perform some transformation on the elements. I'd like to write this: (with-syntax ([((arg ...) ...) #`((#,(transform #'clause.input) ...) ...)]) et-cetera) .. but this fails, with the error new-style-signals.rkt:42:30: syntax: missing ellipsis with pattern variable in template in: clause.input I can certainly work around this, by abandoning the pattern-matching slickness and just using a bunch of syntax-lists, but it seems like there must be a nicer way. Am I missing some nifty trick? John _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax parsing: must be a nice pattern-y way to do this
See 'define-template-metafunction' in syntax/parse/experimental/template. Remember to change the relevant occurrences of 'syntax' to 'template'. Ryan On 09/16/2012 08:31 PM, John Clements wrote: I want to apply a transformation to a nested pattern element. To start with, suppose I have a (kind of useless) with-handlers that looks like this: (with-syntax ([((arg ...) ...) #`((clause.input ...) ...)]) et-cetera) That is, I've basically just renamed clause.input to arg. But now, I want to perform some transformation on the elements. I'd like to write this: (with-syntax ([((arg ...) ...) #`((#,(transform #'clause.input) ...) ...)]) et-cetera) .. but this fails, with the error new-style-signals.rkt:42:30: syntax: missing ellipsis with pattern variable in template in: clause.input I can certainly work around this, by abandoning the pattern-matching slickness and just using a bunch of syntax-lists, but it seems like there must be a nicer way. Am I missing some nifty trick? John _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/format
The change to ~a, ~v, and ~s seems reasonable to me. The renamed
keywords and generalization of ~v and ~s to multiple arguments are good.
The ~r function seems okay except for the way it chooses which notation
(positional or exponential) to use. It should take a rule, not an
answer, and the default rule should not depend on the precision
argument, as it produces peculiar results. Contrast:
(catn pi #:precision 0) = 3
(~r pi #:precision 0) = 3e+00
Unfortunately, I think the kind of rules supported by 'catn'
(pos/exp-range) are also wrong. Probably the best solution is to take a
function. I'll change ~r to drop the #:exponential? argument and instead
take a #:notation argument, with contract
(or/c 'positional 'exponential
(- rational? (or/c 'positional 'exponential)))
and default value of 'positional.
Ryan
On 09/07/2012 10:27 AM, Matthew Flatt wrote:
I've added a `racket/format' library that is a revised version of
Ryan's `unstable/cat'. It's re-exported by `racket', but not by
`racket/base'.
I think Ryan's library is a step in the right direction for string
formatting, and the difficult remaining task is getting the names
right. So, this `racket/format' experiment changes all of the names.
As reflected in the `racket/format' library name, the new function
names are intended to leverage your experience with `format': the `cat'
function is `~a', the `catp' function is `~v', and the `catw' function
is `~s'. The `catn' functions are collapsed to a single `~r'.
Using this library, instead of writing
(format The result of\n ~s\nis\n ~v
expr
(eval expr))
you'd write
(~a The result of\n
(~s expr) \n
is\n
(~v (eval expr)))
or even, when using `#lang at-exp racket',
@~a{The result of
@~s[expr]
is
@~v[(eval expr)]}
Keyword options like `#:width' and `#:align', of course, can be an even
bigger help for formatting.
I concede that names like `~s' are not remotely mnemonic unless you've
already learned the somewhat obscure `format' escapes, but it seems
difficult to find compact names that are meaningful and that don't
cause collisions; we can at least take advantage of the compact names
that we've already learned. Embracing tildes also means that we worry
less about replacing all sorts of APIs, such as `error', that have
`format' built in. And maybe `~a' works relatively well as a shorthand
for `string-append'.
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] When is it safe to not rename a runtime value in a macro?
On 08/25/2012 12:19 PM, Neil Toronto wrote: A lot of macros start by renaming some syntax that's assumed to eventually represent a runtime value, like the `or' macro does: (syntax-datum (expand-syntax #'(or #t #f))) '(let-values (((or-part) '#t)) (if or-part or-part '#f)) But it's not always a good thing, particularly when the output will be processed by another macro, and parts will be tested using an `identifier=?' function. For example, my `inline-sort' takes `' as an argument. So (inline-sort a b) expands to (let ([lt? ] [temp1 a] [temp2 b]) (if (lt? temp1 temp2) (values temp1 temp2) (values temp2 temp1))) Well, it did at first. When I discovered that Typed Racket's optimizer would never detect that `lt?' is actually `' and replace it with `unsafe-fl', I altered the macro to detect when the `' is an identifier, and not rename it with a `let'. Is it feasible to make the TR optimizer smarter about this? That would be the best solution. I know that I should assert my rights under the Macro Bill. But I like to program defensively. So what's safe to not rename? I think the following are: I've reordered these a bit: number string bytes character regexp In other words, literal data. But did you check that the '#%datum' macro associated with them has the standard meaning? If not, they could expand into arbitrary expressions (possibly with side effects)! symbol Do you mean identifier, as in it's just a variable reference? But it could be an identifier macro. Or it could be a variable that other parts of the code could concurrently mutate. For example, suppose 'match' expanded less cautiously than it actually does: (match x [(cons a b) a]) = (if (pair? x) (unsafe-car x) (match-error )) Now suppose that x is a module-level variable that some other thread mutates between the 'pair?' check and the 'unsafe-car'. null prefab struct key I don't know what you mean by these in this context. Maybe 'quote' expressions containing them? -- If you must do such things, the safest way in general is to fully local-expand the expression you want to analyze; that gives you something with a known grammar. Now it's feasible to identify literal data: it's any 'quote' expression. You don't have to worry about identifier macros, but the 'set!' danger remains for any variables that you don't completely control the scope of. In your specific case, it would also be safe to check whether the comparison expression is an identifier free-identifier=? to one of a fixed list of known (immutable) variables; if so, it's safe to duplicate. Also, should I ever have to intern syntax that's one of these kinds of things? Do you mean intern the data? IIUC, yes: the reader interns literal data, but macros are free to introduce non-interned literal data. (It will probably get interned again when the compiled form is loaded from zo, but there's a period during the expansion of the enclosing module when it won't be interned.) Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] When is it safe to not rename a runtime value in a macro?
On 08/25/2012 01:08 PM, Neil Toronto wrote: On 08/25/2012 10:53 AM, Ryan Culpepper wrote: On 08/25/2012 12:19 PM, Neil Toronto wrote: I've reordered these a bit: number string bytes character regexp In other words, literal data. But did you check that the '#%datum' macro associated with them has the standard meaning? If not, they could expand into arbitrary expressions (possibly with side effects)! A number can expand to an arbitrary expression? How? And what do you mean by the '#%datum' macro associated with them? Applied to them? (let-syntax ([#%datum (lambda (stx) #'(printf hello\n))]) 5) hello In Racket, literal data carry lexical information just like identifiers. When a literal datum is used as an expression, the macro expander synthesizes a '#%datum' identifier that determines what to do with the literal. The Racket '#%datum' macro just expands into a 'quote' expression if the datum is not a keyword. The implicit '#%app' syntax works similarly, except it takes its lexical context from the pair that represents the application. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release Announcement for v5.3, third draft
Below is the third draft of the release announcement items for v5.3. Let me know if I've missed something. * Submodules are nested module declarations that can be loaded and run independently from the enclosing module. For an overview of submodules, see http://blog.racket-lang.org/2012/06/submodules.html * The futures visualizer is a graphical profiling tool for parallel programs using futures. The tool shows a detailed execution timeline depicting the migration of futures between threads, and gives detailed information about each runtime synchronization that occurred during program execution. In addition, `would-be-future' is a special type of future that always executes sequentially and records all potential barricades a regular future would encounter. * Optimization Coach (formerly Performance Report) reports information about Racket's inlining optimizations. Optimization Coach can be launched in any language through the View menu. * The new `images/flomap' library defines floating-point bitmaps and fast image processing operations on them. It is written in Typed Racket, so Typed Racket code may use it without the cost of contract checks. * A new `json' library (derived from Dave Herman's PLaneT library) for parsing and generating JSON comes with the distribution. * `racket/string' is extended with string manipulation functions that avoid some basic regexp tweaks. `regexp-match*' and friends come with new keyword arguments to return specific matched group/s and gaps. * The new `racket/generic' library allows generic function definitions, which dispatch to methods added to a structure type via the new `#:methods' keyword. * The `class' form supports declaring a method abstract. An abstract method prevents a class from being instantiated unless it is overridden. * The contract library comes with support for interfaces, generics, prompts, continuation-marks, and structs. * Most error messages use a new multi-line format that is more consistent with contract errors and accommodates more information. * Typed Racket supports function definitions with keyword arguments; the startup time of Typed Racket programs has been sharply reduced. * A new `ffi/com' library replaces MysterX; a compatibility `mysterx' library remains, but without ActiveX support. The new `ffi/unsafe/com' library offers a more primitive and direct way to use COM classes and methods. * There is now a very complete completion code for zsh. It is not included in the distribution though, get it at: http://goo.gl/DU8JK (This script and the bash completions will be included in the standard installers in future versions.) * The `tex2page' and `combinator-parser' libraries have been moved from the Racket distribution to PLaneT: - (require (planet plt/tex2page)) - (require (planet plt/combinator-parser)) === DEPRECATION == The following has been deprecated and will be removed in the January 2013 release: - the `planet' command-line tool. Use `raco planet' instead. The following has been deprecated and will be removed in the August 2013 release: - the `mzlib/class100' library. Use `racket/class' instead. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3, third draft
On 08/02/2012 11:16 AM, Ryan Culpepper wrote: [...] * There is now a very complete completion code for zsh. It is not included in the distribution though, get it at: http://goo.gl/DU8JK (This script and the bash completions will be included in the standard installers in future versions.) Should we leave this item out and include it in the future, once the scripts are actually included in the distribution? Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release Announcement for v5.3, second draft
Below is the second draft of the release announcement items for v5.3. Let me know if I've missed something. * Submodules are nested module declarations that can be loaded and run independently from the enclosing module. For an overview of submodules, see http://blog.racket-lang.org/2012/06/submodules.html * The futures visualizer is a graphical profiling tool for parallel programs using futures. The tool shows a detailed execution timeline depicting the migration of futures between threads, and gives detailed information about each runtime synchronization that occurred during program execution. In addition, `would-be-future' is a special type of future that always executes sequentially and records all potential barricades a regular future would encounter. * Optimization Coach (formerly Performance Report) reports information about Racket's inlining optimizations. Optimization Coach can be launched in any language through the View menu. * The API for fast floating-point bitmaps (flomaps) supports image processing operations, including pointwise arithmetic, gradients, blur, resizing with correct downsampling, arbitrary spatial transformations, and pict-like combiners. * A new `json' library (derived from Dave Herman's PLaneT library) for parsing and generating JSON comes with the distribution. * `racket/string' is extended with string manipulation functions that avoid some basic regexp tweaks. `regexp-match*' and friends come with new keyword arguments to return specific matched group/s and gaps. * The new `racket/generic' library allows generic function definitions, which dispatch to methods added to a structure type via the new `#:methods' keyword. * The `class' form supports declaring a method abstract. An abstract method prevents a class from being instantiated unless it is overridden. * The contract library comes with support for interfaces, generics, prompts, continuation-marks, and structs. * Most error messages use a new multi-line format that is more consistent with contract errors and accommodates more information. * Typed Racket supports function definitions with keyword arguments; the startup time of Typed Racket programs has been sharply reduced. * A new `ffi/com' library replaces MysterX; a compatibility `mysterx' library remains, but without ActiveX support. The new `ffi/unsafe/com' library offers a more primitive and direct way to use COM classes and methods. * There is now a very complete completion code for zsh. It is not included in the distribution though, get it at: http://goo.gl/DU8JK (This script and the bash completions will be included in the standard installers in future versions.) * The `tex2page' and `combinator-parser' libraries have been moved from the Racket distribution to PLaneT. === DEPRECATION == The following have been deprecated and will be removed in the January 2013 release: - the `planet' command-line tool. Use `raco planet' instead. The following have been deprecated and will be removed in the August 2013 release: - the `mzlib/class100' library. Use `racket/class' instead. - the `define-contract-struct' form. Use `struct' with `struct/dc' contracts instead. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible 5.2.900.1 bug involving rest argument
Yes, I fixed the bug. The fix should be in the release build tomorrow. Ryan On 07/28/2012 08:28 PM, Robby Findler wrote: I believe Ryan fixed this a few hours ago. He may be waiting for a release build before commenting. Robby On Sat, Jul 28, 2012 at 7:25 PM, Eli Barzilay e...@barzilay.org wrote: 6 hours ago, Neil Van Dyke wrote: Looks like a minor compiler/optimizer bug in Friday's 5.2.900.1 pre-release. I haven't yet found a simpler test case, but you can reproduce by installing a particular PLaneT package as shown below. The line 1275 it's complaining about is the following, which starts a procedure definition that is later applied at toplevel in the same module: (define (charterm-make-keydec keydec-id . keysets) The demo program for this PLaneT package seems to run correctly despite these install/compile-time error messages. I tried to track this, and I don't think that it's a compiler bug... It looks like it's a failure at the stage of compiling the docs which would explain why the code runs fine. The problem looks like something in syntax/parse -- either there or it doesn't do enough checking of its input. A small example that shows it: #lang racket/base (require syntax/parse) (syntax-parse #'(X Y . Z) [(NAME:id ARGn ...) 1] [else 1]) which produces the following error: andmap: contract violation expected: list? given: '(#syntax:/tmp/zzz:5:19 Y . #syntax:/tmp/zzz:5:23 Z) argument position: 2nd other arguments...: #procedure:void context...: /home/scheme/html/release/racket/collects/syntax/parse/private/residual.rkt:206:0: predicate-ellipsis-parser /tmp/zzz: [running body] and the trace that points at synax/parse/private/residual.rkt was there when I tried your original line, so I think that it's the right error. (I'll let Ryan take it from here, I just did a semi-blind tracking...) -- ((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 Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v5.3
Doug: Can you test your program again with the release build that just completed? (Sorry it wasn't available sooner.) Ryan On 07/25/2012 02:39 PM, Doug Williams wrote: And one last post on this. Now it is reliably running. I'm assuming once I got a .zo of the offending module actually built, from then on I'm okay as long as I don't play around with it. Does that make sense? And, just to test that, I deleted the compiled directory and the weird behavior comes back. I (re-)load it and hit run enough times until I get it to start and from then on it starts fine. [Although I'm not sure I should actually trust it - but it seems to be running fine after that.] Doug - done with experimenting for the day - Williams On Wed, Jul 25, 2012 at 12:27 PM, Doug Williams m.douglas.willi...@gmail.com wrote: And, actually I was premature with the I have a work around for Windows XP. Sometimes it runs, but usually it dies in weird and wonderful ways - sometimes with a Win32 error, sometimes with a seg fault during gc, sometimes with errors about undefined symbols various places. It's rather amusing to watch - but I assume memory is just being corrupted now instead of always dying the same way. Let me know when there is a version I can try again. Doug On Wed, Jul 25, 2012 at 12:16 PM, Ryan Culpepper r...@cs.utah.edu wrote: I suspect the problem is caused by commit 8358420f, which changed match to load part of its implementation lazily using lazy-require. Part of that commit was reverted by 949d12e2, but possibly the use of lazy-require left in is causing problems in some cases. I think it would be best to just fully revert the commit (8358420f) on the release branch. Ryan On 07/25/2012 01:56 PM, Doug Williams wrote: It turns out that if I require racket/match explicitly it works. Although I shouldn't have to since racket/match is provided by #lang racket. So, I have a work around on Windows XP 32-bit. But it would be nice to get the problem fixed. On Wed, Jul 25, 2012 at 11:51 AM, Doug Williams m.douglas.willi...@gmail.com wrote: I used Create Executable in DrRacket. But, I just tried raco exe --gui main.rkt to create it and get exactly the same error. On Wed, Jul 25, 2012 at 11:46 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Is this application generated with 'raco exe'? Or 'Create Executable' in DrRacket? On Wed, Jul 25, 2012 at 10:31 AM, Doug Williams m.douglas.willi...@gmail.com wrote: Some more information on the problem. The application runs fine with the pre-release on Windows 7 - 64 bit. The code that is dying on Windows XP 32-bit is: --- (require racket/runtime-path) ... ;;; (define-runtime-path subject-path ..\\Subjects.txt) ;;; (define (load-subject-encodings) (let ((port (open-input-file subject-path #:mode 'text))) (set! subject-encodings (append default-subject-encodings (for/list ((line (in-lines port)) #:when (regexp-match? #px^\(.*)\\\s*\(.*)\ line)) (match line ((pregexp ^\(.*)\\\s*\(.*)\ (list _ subject encoding)) (list (pregexp (format ^(?i:~a) subject)) encoding)) (close-input-port port))) ... (define subject-encodings default-subject-encodings) (load-subject-encodings) ... --- This code loads some data at load time. It does use match, which might explain the message: standard-module-name-resolver: collection not found collection: racket/match in collection directories: context...: standard-module-name-resolver #%embedded:g13106:ground-truth-data: [running body] #%embedded:g13057:radar-data: [traversing imports] #%embedded:g8619:classifier-panel: [traversing imports] main: [traversing imports] loop [Exited. Close box or Ctrl-C closes the console.] I get when I run the compiled version. In DrRacket it dies with the unhandled Win 32 exception. Doug On Wed, Jul 25, 2012 at 8:39 AM, Doug Williams m.douglas.willi...@gmail.com wrote: The pre-release 32-bit version still fails for my large applications at work fails to execute in DrRacket - 32-bit Windows XP. I don't have the source or symbol tables loaded so the only message I get from the Visual Studio debugger is attached. This is the same problem I was having with the previous pre-release version a month or so ago. I can create an executable of the application. It fails because it doesn't find racket/match. I'll look into that further. Doug _ 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] Pre-Release Checklist for v5.3
I just tried downloading the Racket package for Windows (x86, 64-bit), and it worked for me. Can you try again and let me know if it still fails? Also, if you can't download from the form, can you try the static table link (just under the usual download form, on the right side) and see if you can download it from the link on that page? Thanks, Ryan On 07/25/2012 10:05 AM, Doug Williams wrote: Attempting to download the 64 bit windows version gives a Page Not-Found error and the following. ((uncaught-exception-handler) (*(+(*)(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*(+(*)(*)(*)(* uncaught exception: 404 The 32 bit Windows versions downloads okay. Doug On Tue, Jul 24, 2012 at 9:03 AM, Ryan Culpepper r...@cs.utah.edu wrote: Checklist items for the v5.3 release (using the v5.2.900.1 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * Matthew Flatt mfl...@cs.utah.edu - Racket Tests - Languages Tests - GRacket Tests (Also check that `gracket -z' and `gracket-text' still works in Windows and Mac OS X) - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests - JPR's test suite - Create an executable from a BSL program - Run COM tests - Try compiling with -funsigned-char Updates: - Racket Updates: update HISTORY (updates should show v5.3 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. * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests - Redex Tests Updates: - DrRacket Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v5.3 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. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v5.3 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests - Typed Racket Updates: update HISTORY (updates should show v5.3 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v5.3 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper r...@cs.utah.edu - Macro Debugger Tests - Syntax Classifier Tests - RackUnit GUI Tests - Data Tests - DB Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Stevie Strickland sstri...@ccs.neu.edu - Unit Contract Tests - Contract Region Tests - Class Contract Tests * Stephen Chang stch...@ccs.neu.edu - Lazy Racket Tests - Lazy stepper tests * Eli Barzilay e...@barzilay.org - Swindle Tests - XREPL Tests - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests - Run zsh completions tests (_racket --self-test) Version Updates: if a major change has
[racket-dev] Release Announcement for v5.3
Below is a rough list of additions and changes for v5.3. If you are responsible for a change, please either elaborate it into an announcement item or tell me if it shouldn't be included in the announcement. Let me know if I've missed something. mflatt: - ffi/com, ffi/unsafe/com (ff41a896) - scribble xref change (a1fd742e) - raco exe can make launchers (2c479683) - prop:cpointer (6cd2e3c7) - handle-evt change to match doc (084278fa) - MysterX changes: ffi/com, removed ActiveX support (11de33d4) - openssl improvements (efcb6078, 1032ce8a) - submodules (3d69dfab) - racket/draw easier access to cairo (4f197f4b) - use AVL trees for immutable hashes (df0651c2) - (turon) add box-cas!, etc (868dcb6d) - libpng15/libpng12 (c5d3750d) - sgl/gl: NURBS (a55a20f9) - new error message convention - date/time stuff (ff8a062b, 4323096a) - changed module-name-resolver interface (c8f4ac6a) robby: - grammar cycle check (93c21e34) - hole equality? (2afda360) - side-condition, define-judgment-form (b3c450ff) - - contract optimizations (3f6a8355) - define-union-language (e4e4d70b) - plai changes (c42675f8) - add make-platform-bitmap (1945ff27) - define-extended-judgment-form (b7caf411) - drracket run 'main' submodule (72ec4070) - drracket easter egg tests (617df05e) - drracket run 'test' submodule (5c7a299c) - added context/path to contract errors (81252541) - added struct/dc, etc (5e03c7cf) - deprecate define-contract-struct (52fa588f) eli: - regexp improvements (0eb5f09e) - json library (b35d1b01, 54021323) - xrepl improvements (89dee6f6) - add completions for zsh (904d2666) - doc search improvement (ecc43ff1) james: - added would-be-future (a5676e9a) - added futures visualizer (b6f71ec4) ryanc: - added db cursors - added statement cache - syntax/parse template (exp) - syntax/parse roles asumu: - class/c changes (3eb963f6) - class contracts for racket/draw, racket/snip (30311058, 2e1d59f7) - add contracts to interfaces (6f4ad1de) - abstract methods (06091079) - generics (518bf0fd) - contracts for generics (552d6de9) - prompt/c, continuation-mark-key/c (de5c756d, 095d47fc) - mzlib deprecation notices (e4141077) neil: - image, flomaps changes? - resizable plot snips (3ed1a787) stamourv: - enable performance report for typed/racket/base (b73421f8) tewk: - distributed places (09bed0d6) samth: - keyword functions in TR (865a2cdc) - TR load time optimizations (794bfa50, 6bf14151) matthias: - teaching lang doc reorg (5fbb660a) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v5.3
I suspect the problem is caused by commit 8358420f, which changed match to load part of its implementation lazily using lazy-require. Part of that commit was reverted by 949d12e2, but possibly the use of lazy-require left in is causing problems in some cases. I think it would be best to just fully revert the commit (8358420f) on the release branch. Ryan On 07/25/2012 01:56 PM, Doug Williams wrote: It turns out that if I require racket/match explicitly it works. Although I shouldn't have to since racket/match is provided by #lang racket. So, I have a work around on Windows XP 32-bit. But it would be nice to get the problem fixed. On Wed, Jul 25, 2012 at 11:51 AM, Doug Williams m.douglas.willi...@gmail.com wrote: I used Create Executable in DrRacket. But, I just tried raco exe --gui main.rkt to create it and get exactly the same error. On Wed, Jul 25, 2012 at 11:46 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Is this application generated with 'raco exe'? Or 'Create Executable' in DrRacket? On Wed, Jul 25, 2012 at 10:31 AM, Doug Williams m.douglas.willi...@gmail.com wrote: Some more information on the problem. The application runs fine with the pre-release on Windows 7 - 64 bit. The code that is dying on Windows XP 32-bit is: --- (require racket/runtime-path) ... ;;; (define-runtime-path subject-path ..\\Subjects.txt) ;;; (define (load-subject-encodings) (let ((port (open-input-file subject-path #:mode 'text))) (set! subject-encodings (append default-subject-encodings (for/list ((line (in-lines port)) #:when (regexp-match? #px^\(.*)\\\s*\(.*)\ line)) (match line ((pregexp ^\(.*)\\\s*\(.*)\ (list _ subject encoding)) (list (pregexp (format ^(?i:~a) subject)) encoding)) (close-input-port port))) ... (define subject-encodings default-subject-encodings) (load-subject-encodings) ... --- This code loads some data at load time. It does use match, which might explain the message: standard-module-name-resolver: collection not found collection: racket/match in collection directories: context...: standard-module-name-resolver #%embedded:g13106:ground-truth-data: [running body] #%embedded:g13057:radar-data: [traversing imports] #%embedded:g8619:classifier-panel: [traversing imports] main: [traversing imports] loop [Exited. Close box or Ctrl-C closes the console.] I get when I run the compiled version. In DrRacket it dies with the unhandled Win 32 exception. Doug On Wed, Jul 25, 2012 at 8:39 AM, Doug Williams m.douglas.willi...@gmail.com wrote: The pre-release 32-bit version still fails for my large applications at work fails to execute in DrRacket - 32-bit Windows XP. I don't have the source or symbol tables loaded so the only message I get from the Visual Studio debugger is attached. This is the same problem I was having with the previous pre-release version a month or so ago. I can create an executable of the application. It fails because it doesn't find racket/match. I'll look into that further. Doug _ 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] Pre-Release Checklist for v5.3
Well, the possible problem that I had in mind still should not cause behavior like that, at least not by itself. I would expect it to always fail trying to load a module in the racket/match implementation. OTOH, if reverting the lazy-require addition fixes the problem, that suggests that the bug has something to do with the machinery that lazy-require uses (dynamic-require, racket/runtime-path, module path indexes, etc). And if it doesn't fix the problem, then hopefully it at least simplifies the example to be debugged. A release build with this change should be available tomorrow morning. Ryan On 07/25/2012 02:27 PM, Doug Williams wrote: And, actually I was premature with the I have a work around for Windows XP. Sometimes it runs, but usually it dies in weird and wonderful ways - sometimes with a Win32 error, sometimes with a seg fault during gc, sometimes with errors about undefined symbols various places. It's rather amusing to watch - but I assume memory is just being corrupted now instead of always dying the same way. Let me know when there is a version I can try again. Doug On Wed, Jul 25, 2012 at 12:16 PM, Ryan Culpepperr...@cs.utah.edu wrote: I suspect the problem is caused by commit 8358420f, which changed match to load part of its implementation lazily using lazy-require. Part of that commit was reverted by 949d12e2, but possibly the use of lazy-require left in is causing problems in some cases. I think it would be best to just fully revert the commit (8358420f) on the release branch. Ryan On 07/25/2012 01:56 PM, Doug Williams wrote: It turns out that if I require racket/match explicitly it works. Although I shouldn't have to since racket/match is provided by #lang racket. So, I have a work around on Windows XP 32-bit. But it would be nice to get the problem fixed. On Wed, Jul 25, 2012 at 11:51 AM, Doug Williams m.douglas.willi...@gmail.com wrote: I used Create Executable in DrRacket. But, I just tried raco exe --gui main.rkt to create it and get exactly the same error. On Wed, Jul 25, 2012 at 11:46 AM, Sam Tobin-Hochstadtsa...@ccs.neu.edu wrote: Is this application generated with 'raco exe'? Or 'Create Executable' in DrRacket? On Wed, Jul 25, 2012 at 10:31 AM, Doug Williams m.douglas.willi...@gmail.com wrote: Some more information on the problem. The application runs fine with the pre-release on Windows 7 - 64 bit. The code that is dying on Windows XP 32-bit is: --- (require racket/runtime-path) ... ;;; (define-runtime-path subject-path ..\\Subjects.txt) ;;; (define (load-subject-encodings) (let ((port (open-input-file subject-path #:mode 'text))) (set! subject-encodings (append default-subject-encodings (for/list ((line (in-lines port)) #:when (regexp-match? #px^\(.*)\\\s*\(.*)\ line)) (match line ((pregexp ^\(.*)\\\s*\(.*)\ (list _ subject encoding)) (list (pregexp (format ^(?i:~a) subject)) encoding)) (close-input-port port))) ... (define subject-encodings default-subject-encodings) (load-subject-encodings) ... --- This code loads some data at load time. It does use match, which might explain the message: standard-module-name-resolver: collection not found collection: racket/match in collection directories: context...: standard-module-name-resolver #%embedded:g13106:ground-truth-data: [running body] #%embedded:g13057:radar-data: [traversing imports] #%embedded:g8619:classifier-panel: [traversing imports] main: [traversing imports] loop [Exited. Close box or Ctrl-C closes the console.] I get when I run the compiled version. In DrRacket it dies with the unhandled Win 32 exception. Doug On Wed, Jul 25, 2012 at 8:39 AM, Doug Williams m.douglas.willi...@gmail.com wrote: The pre-release 32-bit version still fails for my large applications at work fails to execute in DrRacket - 32-bit Windows XP. I don't have the source or symbol tables loaded so the only message I get from the Visual Studio debugger is attached. This is the same problem I was having with the previous pre-release version a month or so ago. I can create an executable of the application. It fails because it doesn't find racket/match. I'll look into that further. Doug _ 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] Pre-Release Checklist for v5.3
On 07/25/2012 04:00 PM, Neil Toronto wrote: On 07/24/2012 08:03 AM, Ryan Culpepper wrote: * Neil Toronto neil.toro...@gmail.com - Plot Tests Done. Can you also add the following to future checklists? - Images tests - Inspect icons I've just done these, too. Okay, I've added those items to the checklist for future releases. Thanks, Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pre-Release Checklist for v5.3, second call
Checklist items for the v5.3 release (using the v5.2.900.1 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * Matthew Flatt mfl...@cs.utah.edu - JPR's test suite - Run COM tests - Try compiling with -funsigned-char Updates: - 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. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v5.3 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v5.3 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Stephen Chang stch...@ccs.neu.edu - Lazy stepper tests * Eli Barzilay e...@barzilay.org - XREPL Tests - Racket Tree: compare new distribution tree to previous one - Run the unix installer tests Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine (note that they're still called `plt' and `mz' at this stage). - 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] * Mike Sperber sper...@deinprogramm.de - DMdA Tests - Stepper Tests - Signature Tests * Danny Yoo d...@cs.wpi.edu - Whalesong Tests (confirm that Whalesong runs from PLaneT) _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] testing for v5.3
Just a reminder that testing for release v5.3 begins Monday. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25038: master branch updated
On 07/20/2012 04:36 PM, Carl Eastlund wrote: On Fri, Jul 20, 2012 at 4:33 PM, Vincent St-Amourstamo...@ccs.neu.edu wrote: At Fri, 20 Jul 2012 16:17:22 -0400, as...@racket-lang.org wrote: 3582b57 Asumu Takikawaas...@racket-lang.org 2012-07-20 15:10 : | Move mzlib/defmacro = racket/defmacro I'm not sure this belongs in `racket'. This is not a Racket feature. It's closer to a CL compatibility library. How about having a `compatibility' collect, which would include this and things like `racket/package' (compatibility with Chez) and `racket/mpair' (compatibility with Scheme)? It would be harder to confuse these things with blessed Racket features. Vincent +1 For backwards (ahem) compatibility, we would have to maintain the racket/package and racket/mpair names as aliases, but changing existing uses of them to the new name and making the racket/ documentation point to compatibility/ would help make the point. -1 I think proliferating indirections and aliases is just as bad as (or maybe worse than) proliferating top-level collections. If it's in mzlib/ and it's still really useful, move it to racket/ (or data/, etc). If it isn't (eg, mzlib/defmacro, perhaps mzlib/thread), then just leave it alone. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release for v5.3 has begun
The release process for v5.3 has begun: the `release' branch was created for any work that is left and is now bumped to v5.2.900.0. You can go on using the `master' branch as usual, it is now bumped to v5.3.0.16 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Please make sure that code that you're responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release. NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT The time between the `release' branch creation and the actual release is for fixing new errors that prevent proper functioning of major components and that show up during the preparation for a release. You can also finalize piece of work that is not yet complete, but please avoid merging new features. Note that nightly builds will go on as usual (as v5.3.0.16), and pre-release builds will be available shortly at http://pre.racket-lang.org/release/ Please tell me if you think that this release is significant enough that it should be announced on the users list for wider testing. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Failure when using `lazy-require` in `match`
On 07/14/2012 06:31 PM, Sam Tobin-Hochstadt wrote: I'm trying to use `unstable/lazy-require` to load time compile-time portion of `match` on-demand; the attached patch implements what I think should be the right thing. However, when I try to run 'raco setup' with this, I get: raco setup: bootstrapping from source... write: cannot marshal value that is embedded in compiled code value: #resolved-module-path:/home/samth/sw/plt/collects/racket/match/define-forms.rkt Is this a bug in lazy-require? A problem in racket? Is using this trick not allowed in the dependencies of `raco setup`? The patch didn't include stxtime.rkt, so I couldn't verify this, but the error is what I would expect if you used relative-path requires from transformation modules to residual modules. See http://macrologist.blogspot.com/2011/10/lazy-module-loading.html and search for Use absolute module paths in all requires between the different kinds of modules. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Enhancement to the syntax system?
On 07/10/2012 10:51 AM, Eli Barzilay wrote: 20 minutes ago, Marijn wrote: It seems to me that both these results cannot be correct simultaneously, but I'll await the experts' opinion on that. This does look weird: #lang racket (define-for-syntax (f stx) #`(let ([x 1]) #,stx)) (define-syntax (m stx) (with-syntax ([zz (f #'x)]) #`(let ([x 2]) zz))) (m) evaluates to 1, but if I change the first two stx names into x *or* if I change the argument name for the macro to x, then it returns 2. The difference between (define-for-syntax (f1 stx) #`(let ([x 1]) #,stx) and (define-for-syntax (f2 x) #`(let ([x 1]) #,x) is that the 'x' in the template in the 'f2' is not bound-identifier=? to the 'x' that appears in the template of 'm', because it has a rename wrap due to the 'x' formal parameter of 'f2'. That is, 'f2' behaves essentially the same as (define-for-syntax (f2* x*) #`(let ([x* 1]) #,x*) A likely mistake is to think that the wrap generated by the 'x' in 'f2' doesn't count because it happens before we get around to the real macro expansion that you care about. But that's not the case (at least in Racket). A good rule of thumb is to never use local variable names in your macro implementation (including compile-time auxiliary functions) that also appear in the macro's template (including etc). A related error is the identifier used out of context error that you get from, eg, (define-syntax (m stx) (let ([+ *]) #'(+ 1 2))) (m) ;; = identifier used out of context in: + The binding of '+' in the macro changes the meaning of the '+' in the template, even though the bindings exist at different phases. You could perhaps avoid this issue by changing the hygiene algorithm by adding a phase level to rename wraps and skipping different-phase rename wraps during resolution. I'm not sure if this is a good idea or if anyone has tried it. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release for v5.3 is about to begin
The release process for v5.3 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. -- Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24906: master branch updated
On 06/25/2012 06:57 PM, Asumu Takikawa wrote: On 2012-06-25 20:35:21 -0400, as...@racket-lang.org wrote: | racket/generics: add contract combinator | | The generics library now generates a `name/c` macro | for a generic interface `name`. The combinator can be | used to contract instances (or constructors) of a | generic interface across standard contract boundaries. To add a bit more context, the purpose of this feature is to allow contracts to be applied to generic interfaces like how `prop:dict/contract` does for dictionaries. It's more flexible because it allows contracts to be added for any interface (without any additional properties) and allows contracts to be added at different places. e.g., you could export `make-prime-dict` and `make-dict` constructors with different contracts. If nobody minds, I may go ahead and convert uses of `prop:dict/contract` to use `dict/c` and export the latter from `racket/dict`. IIUC from your later message, you've implemented the generics analogue of object/c (per-instance contract), whereas prop:dict/contract is closer to class/c (per-type contract). It's a little fuzzy because prop:dict/contract hacks in per-instance contracts too in a kind of ad hoc way. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24906: master branch updated
On 06/25/2012 09:04 PM, Asumu Takikawa wrote: On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote: IIUC from your later message, you've implemented the generics analogue of object/c (per-instance contract), whereas prop:dict/contract is closer to class/c (per-type contract). It's a little fuzzy because prop:dict/contract hacks in per-instance contracts too in a kind of ad hoc way. That's a good point. The better analogy might be interface contracts vs. class/c. With generics, it is easy to control all points that an instance is created since constructors are just procedures. With classes, you can't get away with that since the instantiation forms are macros. The difference/advantage you might get with a per-type contract for generics is that you get a more interface-like blame story, as with interface contracts. Coverage isn't as much of an issue since you can just contract all constructors. Unfortunately, it's also not clear how to implement interface-like contracts for generics. Since the generics forms don't control the constructors, it's not obvious how to instantiate the blame at the construction site. You don't want to blame the construction site; the relevant party is the implementation site, where the generic interface is associated with concrete methods within a 'struct' form. See the docs for 'struct-type-property/c' for an example. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24906: master branch updated
On 06/25/2012 09:27 PM, Stevie Strickland wrote: On Jun 25, 2012, at 11:21 PM, Ryan Culpepper wrote: On 06/25/2012 09:04 PM, Asumu Takikawa wrote: On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote: IIUC from your later message, you've implemented the generics analogue of object/c (per-instance contract), whereas prop:dict/contract is closer to class/c (per-type contract). It's a little fuzzy because prop:dict/contract hacks in per-instance contracts too in a kind of ad hoc way. That's a good point. The better analogy might be interface contracts vs. class/c. With generics, it is easy to control all points that an instance is created since constructors are just procedures. With classes, you can't get away with that since the instantiation forms are macros. The difference/advantage you might get with a per-type contract for generics is that you get a more interface-like blame story, as with interface contracts. Coverage isn't as much of an issue since you can just contract all constructors. Unfortunately, it's also not clear how to implement interface-like contracts for generics. Since the generics forms don't control the constructors, it's not obvious how to instantiate the blame at the construction site. You don't want to blame the construction site; the relevant party is the implementation site, where the generic interface is associated with concrete methods within a 'struct' form. See the docs for 'struct-type-property/c' for an example. Well, there are two blame parties, right? Much like interface contracts mediate between the creator of a class (that implements the interface) and the client of that class (that instantiates objects from that interface), I would think the contracts for a generic interface would be between the creator of a specific instance (the implementation site) and the user of that specific instance (the constructor site). Stevie The analogy to interface contracts doesn't help me, because I don't know anything about them. But I think I disagree. (module GEN racket (define-generics has-prime (get-a-prime has-prime)) (provide-generics-with-contract (has-prime [get-a-prime (- has-prime? prime?)]))) (module IMPL racket (struct prime-box (val) #:methods gen:has-prime [(define (get-a-prime self) (prime-box-val self))]) (provide (struct-out prime-box))) (module CLIENT racket (define p (prime-box 4)) (get-a-prime p)) ;; ERROR I think IMPL should be blamed for violating the contract on gen:has-prime. As I see it, GEN establishes an obligation on implementors of 'has-prime'. IMPL provides an implementation that turns out to be faulty; it doesn't live up to the obligation imposed by GEN. CLIENT is blameless; I don't see how the location of the constructor call has anything to do with it. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24906: master branch updated
On 06/25/2012 10:25 PM, Stevie Strickland wrote: [Hit Reply instead of Reply All, so fixing that here.] On Jun 25, 2012, at 11:53 PM, Ryan Culpepper wrote: On 06/25/2012 09:27 PM, Stevie Strickland wrote: On Jun 25, 2012, at 11:21 PM, Ryan Culpepper wrote: On 06/25/2012 09:04 PM, Asumu Takikawa wrote: On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote: IIUC from your later message, you've implemented the generics analogue of object/c (per-instance contract), whereas prop:dict/contract is closer to class/c (per-type contract). It's a little fuzzy because prop:dict/contract hacks in per-instance contracts too in a kind of ad hoc way. That's a good point. The better analogy might be interface contracts vs. class/c. With generics, it is easy to control all points that an instance is created since constructors are just procedures. With classes, you can't get away with that since the instantiation forms are macros. The difference/advantage you might get with a per-type contract for generics is that you get a more interface-like blame story, as with interface contracts. Coverage isn't as much of an issue since you can just contract all constructors. Unfortunately, it's also not clear how to implement interface-like contracts for generics. Since the generics forms don't control the constructors, it's not obvious how to instantiate the blame at the construction site. You don't want to blame the construction site; the relevant party is the implementation site, where the generic interface is associated with concrete methods within a 'struct' form. See the docs for 'struct-type-property/c' for an example. Well, there are two blame parties, right? Much like interface contracts mediate between the creator of a class (that implements the interface) and the client of that class (that instantiates objects from that interface), I would think the contracts for a generic interface would be between the creator of a specific instance (the implementation site) and the user of that specific instance (the constructor site). Stevie The analogy to interface contracts doesn't help me, because I don't know anything about them. But I think I disagree. (module GEN racket (define-generics has-prime (get-a-prime has-prime)) (provide-generics-with-contract (has-prime [get-a-prime (- has-prime? prime?)]))) (module IMPL racket (struct prime-box (val) #:methods gen:has-prime [(define (get-a-prime self) (prime-box-val self))]) (provide (struct-out prime-box))) (module CLIENT racket (define p (prime-box 4)) (get-a-prime p)) ;; ERROR I think IMPL should be blamed for violating the contract on gen:has-prime. As I see it, GEN establishes an obligation on implementors of 'has-prime'. IMPL provides an implementation that turns out to be faulty; it doesn't live up to the obligation imposed by GEN. CLIENT is blameless; I don't see how the location of the constructor call has anything to do with it. I agree that IMPL is the positive blame party here and should be blamed for not returning a prime?, So far so good but that's because in this example it's not protecting itself from bad prime-box values. It shouldn't suggest that it will, in fact, return prime numbers if it isn't protecting its constructor with a contract, or checking inside its implementation of get-a-prime that it is going to return a prime number without that constructor guarantee. Why but? You have explained why IMPL is at fault. It accepted an obligation and failed to meet it. As for the negative blame, who should be responsible? Who's responsible for the negative blame that gets triggered below, where we have a generic interface for containers mapping names to public keys? (module GEN racket (define-generics key-container ([get-key (- key-container? (- string? prime?))])) (provide gen:key-container)) (module IMPL racket (struct my-key-container (hash) #:methods gen:key-container [(define (get-key self) (lambda (str) (hash-ref my-key-container-hash str)))]) (provide (struct-out my-key-generator)) (module CLIENT racket (define gen (my-key-generator (hash '((foo . 5) (define key-lookup (get-key gen)) (key-lookup 'bad-key)) I'd say the person who created the generator (that is, the person who called the constructor, analogous to the object creator in the interface story). If they wanted to pass off key-lookup to someone else without being blamed for bad inputs, then they, of course, could just provide it with a contract. Let's split the CLIENT module up into three regions/labels/submodules/whatever: C1: (define gen (my-key-generator (hash '((foo . 5) C2: (define key-lookup (get-key gen)) C3: (key-lookup 'bad-key)) C2 should be blamed. The contract on get-key is (or should be) (- key-container? (- string? prime?)) so C2 gets back a value that it is obligated to treat as a (- string? prime?) but it allows that value to be misused (at point C3
