Re: [racket-dev] What is the policy on what is included in the core libraries?
I don't think we should add functions to TR that are not in Racket and that are not clearly type-related (e.g., `cast`). I also like Jens's solution better. Education vs crutches. Vincent At Tue, 17 Feb 2015 10:39:16 -0500, Matthias Felleisen wrote: I'd add them to Typed Racket. That's what Haskellians are most likely to explore and when they find them, it's a good thing (tm). -- Matthias On Feb 17, 2015, at 2:18 AM, Alexis King lexi.lam...@gmail.com wrote: I was just thinking today that I would, for example, find it useful to have a (zip ...) function in racket/list that would be equivalent to (map list ...). Users coming from a Haskell background might even find it useful to have a zip-with function that is simply an alias for map. Admittedly, these are rather trivial, but (especially in the first case) I think they’d still be useful. I am all for avoiding feature creep and code bloat, but Racket’s “batteries included” approach seems to make functions like these prime candidates for libraries like racket/list. As long as they’re not in racket/base, they seem fairly harmless, especially considering they would only be needed at compile-time. Should I even consider adding things like this, or is the consensus that the libraries are mostly sufficient as-is? -- You received this message because you are subscribed to the Google Groups Racket Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/5D941DB1-8A55-4A41-98A2-A3BE1BFE6D40%40gmail.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/EAAD5B93-DB78-419B-A662-131AD1D3E303%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/87d258qxg8.wl%25stamourv%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
Re: [racket-dev] Github repo is two commits behind
FWIW, pulling from git.racket-lang.org has been slow (i.e. ~30mins) for some of us in the last couple of days. Something in the mirroring may be timing out for similar reasons. Vincent At Mon, 2 Feb 2015 18:41:56 -0300, Gustavo Massaccesi wrote: * openssl: recognize version 1.0.1j #8265c9 (3 days ago) -- latest commit in git.racket-lang * pretty-print: fix for a current inspector that sees through internals #8d49a9 (3 days ago) * fix reified-syntax-class-curry (missing role argument) #302986 (3 days ago) -- Latest commit in github Gustavo _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Github repo is two commits behind
I just pushed something, and now the Github mirror is up to date. The push must have kicked the mirroring mechanism. Vincent At Mon, 02 Feb 2015 16:54:10 -0500, Vincent St-Amour wrote: FWIW, pulling from git.racket-lang.org has been slow (i.e. ~30mins) for some of us in the last couple of days. Something in the mirroring may be timing out for similar reasons. Vincent At Mon, 2 Feb 2015 18:41:56 -0300, Gustavo Massaccesi wrote: * openssl: recognize version 1.0.1j #8265c9 (3 days ago) -- latest commit in git.racket-lang * pretty-print: fix for a current inspector that sees through internals #8d49a9 (3 days ago) * fix reified-syntax-class-curry (missing role argument) #302986 (3 days ago) -- Latest commit in github Gustavo _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Switching to Google Groups
In case anyone would like to use a non-gmail address for sign up, you can sign up from this URL: https://groups.google.com/forum/#!forum/racket-dev/join The regular sign up button wouldn't let me. Vincent At Wed, 28 Jan 2015 16:47:58 -0800, John Clements wrote: Dear developers, PLT would like to get out of the mailing-list administration game. Accordingly, we’re planning to switch to Google Groups. Rather than starting with our largest list, the Racket Users list, we’ve chosen to begin with the dev list, because … well, you’re probably more tolerant, if^H^H when something goes wrong. We would like the transition to be as smooth as possible, and we can use your help with this. Specifically, Google has a daily cap on the number of e-mail addresses that can be bulk-added to a mailing list. For this reason, it would speed the transition greatly if you could take a moment to sign up for the new group yourself, using this URL: https://groups.google.com/forum/#!forum/racket-dev We plan to disable signup for the old group now, and to halt delivery of mail to the existing group address tomorrow. You can post to the new group (after signing up) by sending mail to racket-...@googlegroups.com We plan to manually add or invite the members who do not add themselves, but the daily cap will mean that these users are likely to miss one or more days of postings to this list. Naturally, those posts will be archived, as part of the group. The archive of the existing list will continue to exist, though new messages will not be added to it. Let us know if you run into problems! Many thanks, John Clements PLT _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release process for split repos
That sounds good to me. One concern, though: it looks like recreating old releases requires that all the participating repos (1) still exist, (2) have the same name/location, and (3) still have the release tags. I'm not too worried about (1) and (3), but I could see (2) happening if, e.g., a package changes maintainer (and therefore location), or if we have to move away from github at some point. IIUC, archiving snapshots of the participating repos when the release is finalized may solve that problem. Does that sound reasonable? Vincent At Fri, 23 Jan 2015 15:31:21 -0500, Ryan Culpepper wrote: 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 Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.1.1
For TR: * Exception handling changed to be safe. This may break existing programs that rely on unsafe behavior. * Exports from the GUI and framework libraries have types, and can be used transparently from typed programs. * Casts and predicates are supported in typed regions. Vincent At Mon, 27 Oct 2014 12:25:22 -0400, Ryan Culpepper wrote: 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 Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29396: master branch updated
Yes, if convenient. I already emailed Ryan privately about it. Vincent At Mon, 20 Oct 2014 17:54:59 -0400, Matthias Felleisen wrote: DOn't we want to merge this into 6.1.1? On Oct 20, 2014, at 3:44 PM, stamo...@racket-lang.org wrote: stamourv has updated `master' from 538bb75d64 to 9030680e31. http://git.racket-lang.org/plt/538bb75d64..9030680e31 =[ One Commit ]= Directory summary: 16.9% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/ 83.0% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/ ~~ 9030680 Vincent St-Amour stamo...@racket-lang.org 2014-10-20 11:34 : | Fix types for foldl and foldr with 3 lists. | | Thanks to Jack Firth for the report. : M .../tests/typed-racket/unit-tests/typecheck-tests.rkt| 13 + M .../typed-racket-lib/typed-racket/base-env/base-env.rkt | 4 ++-- =[ Overall Diff ]=== pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt ~~ --- OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt +++ NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt @@ -657,11 +657,11 @@ (-poly (a b c d) (cl- [((a b . - . b) b (-lst a)) b] [((a b c . - . c) c (-lst a) (-lst b)) c] - [((a b c d . - . d) d (-lst a) (-lst b) (-lst d)) d]))] + [((a b c d . - . d) d (-lst a) (-lst b) (-lst c)) d]))] [foldr (-poly (a b c d) (cl- [((a b . - . b) b (-lst a)) b] [((a b c . - . c) c (-lst a) (-lst b)) c] - [((a b c d . - . d) d (-lst a) (-lst b) (-lst d)) d]))] + [((a b c d . - . d) d (-lst a) (-lst b) (-lst c)) d]))] [filter (-poly (a b) (cl-* ((asym-pred a Univ (-FS (-filter b 0) -top)) (-lst a) pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/typecheck-tests.rkt ~~ --- OLD/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/typecheck-tests.rkt +++ NEW/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/typecheck-tests.rkt @@ -1155,6 +1155,19 @@ (-polydots (a) ((list) (a a) . -... . -Integer))] |# +[tc-e (foldl (lambda: ([x : Integer] [acc : String]) acc) '(1 2 3)) + -String] +[tc-e (foldl (lambda: ([x : Integer] [y : Float] [acc : String]) acc) '(1 2 3) '(1.2 3.4 5.6)) + -String] +[tc-e (foldl (lambda: ([x : Integer] [y : Float] [z : Symbol ] [acc : String]) acc) '(1 2 3) '(1.2 3.4 5.6) '(a b c)) + -String] +[tc-e (foldr (lambda: ([x : Integer] [acc : String]) acc) '(1 2 3)) + -String] +[tc-e (foldr (lambda: ([x : Integer] [y : Float] [acc : String]) acc) '(1 2 3) '(1.2 3.4 5.6)) + -String] +[tc-e (foldr (lambda: ([x : Integer] [y : Float] [z : Symbol ] [acc : String]) acc) '(1 2 3) '(1.2 3.4 5.6) '(a b c)) + -String] + ;; First is same as second, but with map explicitly instantiated. [tc-e/t (plambda: (a ...) [ys : (a ... a - Number) *] (lambda: [zs : a ... a] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1.1
At Thu, 16 Oct 2014 09:13:54 -0400, Ryan Culpepper wrote: * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests Done. - Typed Racket 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.) In process. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1.1
At Thu, 16 Oct 2014 11:22:04 -0400, Vincent St-Amour wrote: - Typed Racket 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.) In process. Pushed as commit 66e5a246c42dd585be9e42b280c0338de1e30892 Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Intermittent Segfault on DrDr
Great! That's good news. It's odd that the bug only started manifesting itself (at least on this file) recently. Thanks! Vincent At Thu, 2 Oct 2014 13:48:28 -0600, Matthew Flatt wrote: I think that commit b946d4639e fixes this crash. It's nice of you to ask the day after the repair. :) I had spent a lot of time trying to replicate that crash, with no success, but yesterday was my lucky day. Claire ran a pessimization experiment on the bytecode compiler that made image.scrbl crash reliably. I can't say for certain that the bug that I fixed caused this crash, but the details are a close match for the test content and crash reports. The bug was introduced in 2009 (commit bc47db42e4). At Thu, 02 Oct 2014 15:00:25 -0400, Vincent St-Amour wrote: The file listed below has been segfaulting intermittently for about a month, but I can't reproduce the crash on any of my machines (Linux or Mac OS, both 64 bits). Walking backwards through the commit log from the first occurrence of the crash on DrDr, the first commit that looks like it may be related to segfaults is this one: https://github.com/plt/racket/commit/15423988220ce1fa5dea60917c5c7e83dde941de Any ideas? Can anyone reproduce this crash? Vincent At Wed, 1 Oct 2014 15:56:01 -0400 (EDT), d...@racket-lang.org wrote: DrDr has finished building push #29301 after 3.32h. http://drdr.racket-lang.org/29301/ A file you are responsible for has a condition that may need inspecting. unclean: http://drdr.racket-lang.org/29301/pkgs/typed-racket-pkgs/typed-racket-test/tests /typed-racket/succeed/mandelbrot.rkt stderr: http://drdr.racket-lang.org/29301/pkgs/typed-racket-pkgs/typed-racket-test/tests /typed-racket/succeed/mandelbrot.rkt _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Intermittent Segfault on DrDr
The file listed below has been segfaulting intermittently for about a month, but I can't reproduce the crash on any of my machines (Linux or Mac OS, both 64 bits). Walking backwards through the commit log from the first occurrence of the crash on DrDr, the first commit that looks like it may be related to segfaults is this one: https://github.com/plt/racket/commit/15423988220ce1fa5dea60917c5c7e83dde941de Any ideas? Can anyone reproduce this crash? Vincent At Wed, 1 Oct 2014 15:56:01 -0400 (EDT), d...@racket-lang.org wrote: DrDr has finished building push #29301 after 3.32h. http://drdr.racket-lang.org/29301/ A file you are responsible for has a condition that may need inspecting. unclean: http://drdr.racket-lang.org/29301/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/mandelbrot.rkt stderr: http://drdr.racket-lang.org/29301/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/mandelbrot.rkt _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Performance. Higher-order function
At Thu, 28 Aug 2014 08:55:59 -0600, Matthew Flatt wrote: I didn't change the main-distribution package. I changed the Utah snapshot's configuration to make the Racket distribution have main-distribution plus optimization-coach. Ah, I see. Got it. Changing main-distribution would interfere with a top-level `make` and other things that are still built around the current transitional model (i.e., still having a main Racket repository for the content of the main distribution). To really get optimization-coach into the main distribution, I think we have two options: * Split the main repo and shift everything into that mode. * Move optimization-coach into the main repo, for now, even though we expect to split the main repo in the near future. Do we have a time frame for the former? IMO, that's the way to go, but do we think this can happen for the next release? I don't like the latter. Merging it in and then back out again would be pointless work, IMO, and would lead to confusion as to what the official version is. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Performance. Higher-order function
Great, thanks! I didn't see changes to the main repo to reflect that addition. Are the contents of the main distribution not part of the repo anymore? Vincent At Wed, 27 Aug 2014 08:46:02 -0600, Matthew Flatt wrote: The Racket snapshots at http://www.cs.utah.edu/plt/snapshots/ now include the Optimization Coach package. At Tue, 12 Aug 2014 18:32:05 +0100, Matthew Flatt wrote: Our build system can create a distribution from any set of packages, and so we can easily switch over one of the snapshots to use that mode and include the OC. The Utah snapshot machine fell off the network (that's why we have more than snapshot site...), but I can try adding OC when I can reset it next week. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Performance. Higher-order function
Ok, let's try to do that. Is there currently a way to include packages from 3rd party repos to the main distribution? Vincent At Tue, 12 Aug 2014 00:03:04 -0400, Greg Hendershott wrote: Being in the main repo is different from being in the distribution (and thus automatically installed). I think that OC should be there when you download the full bundle. Definitely. 1. It's very useful. 2. Its existence says, Racket optimization is a thing. 3. It's used with one of Racket's most appealing and unique facets, DrRacket. c _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1
At Thu, 17 Jul 2014 20:03:12 -0400, Ryan Culpepper wrote: * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests Done. - Typed Racket Updates: update HISTORY (updates should show v6.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, Asumu, Eric: what's new for this release? Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1
At Mon, 21 Jul 2014 16:24:24 -0400, Asumu Takikawa wrote: On 2014-07-21 16:14:27 -0400, Vincent St-Amour wrote: Sam, Asumu, Eric: what's new for this release? This came up on IRC the other day. I think Eric was saying the main changes were inference speedups, support for contracted functions, and better keyword support. Pushed as commit 5a12f8e77. Thanks! Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.0.1
At Thu, 01 May 2014 13:49:55 -0400, Ryan Culpepper wrote: vincent: - contract profiler (cc0e6763, 7495243d, etc) Nothing significant for this release. - make f[lx]vectors sequences (8e32e6e4) Not sure that's worth putting in the release notes, but if we decide it is, here's a bullet: - flvectors and fxvectors are sequences, and can be iterated over with the `for' family of forms. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] make-empty-namespace vs make-base-empty-namespace; ie attaching racket/base does other stuff
Extra bit of information, this works too: #lang racket (define ns (make-empty-namespace)) (namespace-attach-module (current-namespace) ''#%builtin ns) (parameterize ([current-namespace ns]) (namespace-require m.rkt)) But replacing ''#%builtin with ''#%kernel or ''#%boot doesn't. Replacing it with 'racket/base (to end up with the equivalent of `make-base-empty-namespace') does work. Vincent At Mon, 28 Apr 2014 16:38:24 -0400, Stephen Chang wrote: Motivated by some recent email threads, I decided to better understand how Racket namespaces work by re-reading some docs but I got confused. Paraphrasing the examples from this part of the guide: http://docs.racket-lang.org/guide/mk-namespace.html the following example fails because the module registry in the namespace is empty: (parameterize ([current-namespace (make-empty-namespace)]) (namespace-require m.rkt)) ; error But the example works if make-base-empty-namespace is used instead: (parameterize ([current-namespace (make-base-empty-namespace)]) (namespace-require m.rkt)) ; works (Assume the contents of m.rkt is #lang racket/base with nothing else.) According to the docs, make-base-empty-namespace attaches racket/base but why does this make m.rkt suddenly available? There seems to be an unexplained gap between to the two examples. (Adding to my confusion is that (module-declared? m.rkt) evaluates to false, even in the 2nd case.) With help from Vincent, we investigated and speculate that perhaps attaching racket/base also runs boot from '#%boot, which populates current-module-name-resolver, but could not conclude anything definitively. Can someone explain what's happening? _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28619: master branch updated
It shouldn't. I used `list', not `cons'. Vincent At Fri, 25 Apr 2014 10:47:23 -0700, Eric Dobson wrote: Doesn't this make the dead clauses return void the function instead of void the value? Not that they ever should run. On Fri, Apr 25, 2014 at 10:45 AM, stamo...@racket-lang.org wrote: stamourv has updated `master' from b40619ffd5 to ce3033a0c7. http://git.racket-lang.org/plt/b40619ffd5..ce3033a0c7 =[ One Commit ]= Directory summary: 52.9% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/ 47.0% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/ ~~ ce3033a Vincent St-Amour stamo...@racket-lang.org 2014-04-25 13:40 : | Keep dead case-lambda clauses around to avoid changing arity. | | Closes PR14468. : A pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/dead-case-lambda.rkt M .../tests/typed-racket/optimizer/tests/unboxed-for.rkt | 2 +- M .../typed-racket-lib/typed-racket/optimizer/dead-code.rkt | 10 +++--- =[ Overall Diff ]=== pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/dead-code.rkt --- OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/dead-code.rkt +++ NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/dead-code.rkt @@ -49,9 +49,13 @@ (begin0 (case-lambda #,@(for/list ((formals (in-syntax #'(formals ...))) - (bodies (in-syntax #'(bodies ...))) - #:unless (dead-lambda-branch? formals)) - (cons formals (stx-map (optimize) bodies + (bodies (in-syntax #'(bodies ... + (if (dead-lambda-branch? formals) + ;; keep the clause (to have a case-lambda with the right arity) + ;; but not the body (to make the function smaller for inlining) + ;; TODO could do better, and keep a single clause per arity + (list formals #'(void)) ; return type doesn't matter, should never run + (cons formals (stx-map (optimize) bodies) ;; We need to keep the syntax objects around in the generated code with the correct bindings ;; so that CheckSyntax displays the arrows correctly #,@(for/list ((formals (in-syntax #'(formals ...))) pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/dead-case-lambda.rkt --- /dev/null +++ NEW/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/dead-case-lambda.rkt @@ -0,0 +1,19 @@ +#;#; +#END +TR opt: dead-case-lambda.rkt 4:10 () -- dead case-lambda branch +TR opt: dead-case-lambda.rkt 6:10 (d . rst) -- dead case-lambda branch +END +#END +(arity-at-least 0) + +END + +#lang typed/racket +#reader tests/typed-racket/optimizer/reset-port + +(procedure-arity + (ann (case-lambda + [() (void)] + [(d) (void)] + [(d . rst) (void)]) + (Any - Any))) pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/unboxed-for.rkt ~~~ --- OLD/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/unboxed-for.rkt +++ NEW/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/unboxed-for.rkt @@ -2,7 +2,6 @@ #END TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i (+ i sum)) -- call to fun with unboxed args TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i (+ i sum)) -- fun - unboxed fun -TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i (+ i sum)) -- unbox float-complex TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i (+ i sum)) -- unboxed call site TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i (+ i sum)) -- unboxed call site TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i (+ i sum)) -- unboxed let bindings @@ -17,6 +16,7
Re: [racket-dev] [plt] Push #28576: master branch updated
At Sat, 19 Apr 2014 19:41:49 -0600, Matthew Flatt wrote: At Sat, 19 Apr 2014 17:36:40 -0400, Vincent St-Amour wrote: At Sat, 19 Apr 2014 13:19:25 -0400, mfl...@racket-lang.org wrote: a01b12e Matthew Flatt mfl...@racket-lang.org 2014-04-19 10:11 : | optimizer: don't move expressions into a `with-continuation-mark` | | ... unless the optimizer can prove that the expression doesn't | inspect continuation marks. : M pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl | 12 +++- M racket/src/racket/src/optimize.c| 5 + This optimization can be observed from another thread, like a profiler's sampling thread, even if the relevant code doesn't observe continuation marks itself. Right: If there's some synchronization point within the expression so that you could reliably observe the thread at that point, then the expression doesn't get moved relative to marks. Ok, no problem then. Sorry for the noise. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28576: master branch updated
At Sat, 19 Apr 2014 13:19:25 -0400, mfl...@racket-lang.org wrote: a01b12e Matthew Flatt mfl...@racket-lang.org 2014-04-19 10:11 : | optimizer: don't move expressions into a `with-continuation-mark` | | ... unless the optimizer can prove that the expression doesn't | inspect continuation marks. : M pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl | 12 +++- M racket/src/racket/src/optimize.c| 5 + This optimization can be observed from another thread, like a profiler's sampling thread, even if the relevant code doesn't observe continuation marks itself. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket-bug] all/14404: profile would be more useful if it returned the result(s) of evaluating its body
I looked through the package descriptions, and it doesn't look like any of them would use the profiler. I'll do the change. Vincent At Thu, 27 Mar 2014 15:33:48 -0400, Vincent St-Amour wrote: Will do. Is there a convenient way to grep through packages without installing them? Vincent At Thu, 27 Mar 2014 14:20:01 -0500, Robby Findler wrote: [1 text/plain; UTF-8 (7bit)] It seems unlikely that anyone does, but could you look at the code on the pkg server to check? Robby On Thu, Mar 27, 2014 at 1:42 PM, Vincent St-Amour stamo...@ccs.neu.eduwrote: [ccing dev] I agree. That would also make adding profiling less intrusive than it is now. Consistency with `time' would also be nice. FWIW, `contract-profile' behaves like `time'. Currently `profile' and `profile-thunk' return whatever the profile renderer returns. Most renderers print their report and return void. But, as the documentation mentions, `values' can be used as a renderer in which case `profile' returns the pre-rendering analyzed profile data. Returning the result of the profiled expression would break that behavior. On the other hand, it's already possible to get the analyzed data by invoking the sampler and the analyzer directly. Changing the behavior of `profile' wouldn't remove that functionality, just make it less convenient. Does anyone rely on that behavior from `profile' and `profile-thunk'? If not, I think we should change it. Vincent At Sat, 15 Mar 2014 23:12:11 -0400, eric.hanch...@gmail.com wrote: A new problem report is waiting at http://bugs.racket-lang.org/query/?cmd=viewpr=14404 Reported by Eric Hanchrow for release: 6.0.0.1--2013-12-13(1f1550a/a) *** Description: I recently tried to use profile, and didn't closely read its documentation. I naively assumed that it would work similarly to time -- namely that I could simply wrap (profile ...) around my code, and my code would continue to run, but would also emit profiling information. But of course profile returns void, so I had to tediously capture my thunk's value myself, and then arrange to have that value passed outside of the profile call. Anyway ... I'd like the below snippet to print 9 not just once (from the call to time), but twice. *** How to repeat: #lang racket (require profile) (displayln (profile (+ 2 3 4))) (displayln (time (+ 2 3 4))) *** Environment: macosx Darwin Eric-Hanchrows-MacBook-Pro.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64 (x86_64-macosx/3m) (get-display-depth) = 32 Human Language: english (current-memory-use) 287758760 Links: (links) = (); (links #:user? #f) = (contract-profile syntax mysterx sgl datalog shell-completion algol60 icons ds-store slatex realm games make trace plai eopl lazy preprocessor profile racklog mzcom schemeunit unstable frtime mrlib swindle); (links #:root? #t) = (#path:/Users/erichanchrow/Library/Racket/snapshot/pkgs/throw #path:/Users/erichanchrow/Library/Racket/snapshot/pkgs/zeromq #path:/Users/erichanchrow/Library/Racket/snapshot/pkgs/zmq); (links #:user? #f #:root? #t) = (#path:/Applications/Racket v6.0.0.1/share/pkgs/racket-lib #path:/Applications/Racket v6.0.0.1/share/pkgs/main-distribution #path:/Applications/Racket v6.0.0.1/share/pkgs/at-exp-lib #path:/Applications/Racket v6.0.0.1/share/pkgs/compatibility #path:/Applications/Racket v6.0.0.1/share/pkgs/compiler #path:/Applications/Racket v6.0.0.1/share/pkgs/data #path:/Applications/Racket v6.0.0.1/share/pkgs/db #path:/Applications/Racket ! v6.0.0.1/share/pkgs/deinprogramm #path:/Applications/Racket v6.0.0.1/share/pkgs/draw #path:/Applications/Racket v6.0.0.1/share/pkgs/draw-doc #path:/Applications/Racket v6.0.0.1/share/pkgs/draw-lib #path:/Applications/Racket v6.0.0.1/share/pkgs/drracket #path:/Applications/Racket v6.0.0.1/share/pkgs/errortrace #path:/Applications/Racket v6.0.0.1/share/pkgs/future-visualizer #path:/Applications/Racket v6.0.0.1/share/pkgs/future-visualizer-typed #path:/Applications/Racket v6.0.0.1/share/pkgs/gui #path:/Applications/Racket v6.0.0.1/share/pkgs/htdp #path:/Applications/Racket v6.0.0.1/share/pkgs/html #path:/Applications/Racket v6.0.0.1/share/pkgs/images #path:/Applications/Racket v6.0.0.1/share/pkgs/macro-debugger #path:/Applications/Racket v6.0.0.1/share/pkgs/macro-debugger-text-lib #path:/Applications/Racket v6.0.0.1/share/pkgs/math #path:/Applications/Racket v6.0.0.1/share/pkgs/mzscheme #path:/Applications/Racket v6.0.0.1/share/pkgs/net #path :! /Applications/Racket v6.0.0.1/share/pkgs/parser-tools #path:! /Applications/Racket v6.0.0.1/share/pkgs/pconvert-lib #path:/Applications/Racket
Re: [racket-dev] [DrDr] R28413 (timeout 4) (unclean 16) (stderr 35) (changes 22)
Right. I'll fix the TR random tester. Vincent At Wed, 26 Mar 2014 13:25:42 -0400, Sam Tobin-Hochstadt wrote: On Wed, Mar 26, 2014 at 1:10 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Just to confirm: Redex isn't doing anything wrong, right? Correct -- I think `real` was always allowed to generate such numbers, but it didn't before. Sam Redex is now using the in-order enumeration generation in a default configuration (for a little while before adding some of the old-style random generated terms). So if you want to see what kinds of things it generates, you can use generate-term with the #:i-th argument. Robby On Wed, Mar 26, 2014 at 12:03 PM, Eric Dobson eric.n.dob...@gmail.com wrote: Looks like what is actually happening is that redex is actually generating reals for this program now. #lang racket (require redex/reduction-semantics) (define-language tr-arith [n real]) (redex-check tr-arith n #t #:prepare (lambda (x) (displayln x) x)) Before we were only getting small integers. On Wed, Mar 26, 2014 at 9:46 AM, Eric Dobson eric.n.dob...@gmail.com wrote: This push has started breaking the random TR tests. I think the issue is that TR assumed that redex wouldn't generate so large numbers that it exceeded the flonum range. Could that have changed in this commit? Or changed so that were generated earlier in random testing? If so the issue is definitely on the TR side, but just want to confirm that the theory is likely. On Wed, Mar 26, 2014 at 4:58 AM, d...@racket-lang.org wrote: DrDr has finished building push #28413 after 1.20h. http://drdr.racket-lang.org/28413/ A file you are responsible for has a condition that may need inspecting. stderr: http://drdr.racket-lang.org/28413/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/tr-random-testing.rkt unclean: http://drdr.racket-lang.org/28413/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/tr-random-testing.rkt _ 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] [plt] Push #28062: master branch updated
At Wed, 15 Jan 2014 12:31:29 -0500, mfl...@racket-lang.org wrote: +@history[#:added 6.0.0.1] IIUC, x.y.z.w versions are not usually user-visible (at least, they don't correspond to any released version). Do we want to expose them in the docs? Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] release notes draft
These release notes look good to me, but maybe a bit short. Since this is our first release with new features since 5.3.4 last May, I would have expected a longer list. For example, during the previous release notes discussion, Jay and Neil had some bullets that I don't see on this list. There also were a lot more things in Robby's original email. If we want to keep the announcement itself short, should we point to the various HISTORY.txt files where users can get more details? Vincent At Sat, 11 Jan 2014 20:27:21 -0600, Robby Findler wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] Below is the latest release notes draft. Comments? Robby Racket has a new package system, including a catalog of already available packages. Please visit http://pkgs.racket-lang.org/ for an overview. Recent releases included the beta versions of the package system. Racket version 6.0 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, which is also available as a stand-alone program via the gui-pkg-manager package. * The main Racket distribution has been broken into about 200 packages. An installation starts with Minimal Racket and then adds these bundled 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 a available. All packages in the main distribution are available in pre-built form. Further improvements are in the works, including package documentation on the package-catalog web site. COMPATIBILITY NOTE: PLaneT 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. * Racket's JIT compiler supports the ARM architecture. * Racket supports the Mac's Retina display mode. * 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. [1.2 text/html; UTF-8 (quoted-printable)] [2 text/plain; us-ascii (7bit)] _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] release notes draft
At Mon, 13 Jan 2014 12:25:06 -0600, Robby Findler wrote: [1 text/plain; UTF-8 (7bit)] On Mon, Jan 13, 2014 at 11:05 AM, Vincent St-Amour stamo...@ccs.neu.eduwrote: These release notes look good to me, but maybe a bit short. Since this is our first release with new features since 5.3.4 last May, I would have expected a longer list. For example, during the previous release notes discussion, Jay and Neil had some bullets that I don't see on this list. There also were a lot more things in Robby's original email. I spoke with Neil privately about the changes and got some agreement and my list was not intended as a list of things that were all to be included. I probably just made a mistake: would you mind helping me fix it? A candidate bullet would be great! A few from your original list, in no particular order: * 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 can now be converted to the svg format. * Racket now provides desktop entries (.desktop files) for its graphical executables. * The documentation now includes a style guide: How to Program Racket. * DrRacket now provides support for color schemes. If we want to keep the announcement itself short, should we point to the various HISTORY.txt files where users can get more details? I'm happy to do this too, but less excited about it, especially since we've now got a much better mechanism that we can use in the next release and we've not done this past releases. No problem. With the bullets above, I think we have enough. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0, corrected url
At Mon, 16 Dec 2013 11:38:32 -0500, Ryan Culpepper wrote: * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests Done. - 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.) Coming soon. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0, corrected url
At Mon, 16 Dec 2013 16:29:25 -0500, Vincent St-Amour wrote: - 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.) Coming soon. Pushed. It's commit ac480e753557 . Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27767: master branch updated
At Thu, 14 Nov 2013 20:37:28 -0500, Neil Toronto wrote: For the following program, on my computer, the new random - unsafe-flrandom optimization slows down the first loop and speeds up the second: #lang typed/racket (require math/flonum racket/unsafe/ops) (define g (current-pseudo-random-generator)) (define bx (make-flvector 1)) (for: ([_ (in-range 5)]) (time (for: ([_ (in-range 500)]) (unsafe-flvector-set! bx 0 (random) (newline) (for: ([_ (in-range 5)]) (time (for: ([_ (in-range 500)]) (unsafe-flvector-set! bx 0 (random g) On my machine, both are faster with the new optimization (first one is ~756ms before and ~675 after, second is ~361 before and ~223 after). How big is the slowdown you're seeing on the first one? Unless you're seeing a huge slowdown, I'm not too worried. This new optimization moves work from the runtime to Racket code, so as the JIT gets better, the new version will get better (which is what happened with, e.g., vector bounds checking elimination). (I'm going to speed up the math library's samplers by caching the parameter value and using the new `flrandom', but of course that's a separate issue.) The latest version of Optimization Coach can help you with that. It now reports implicit dereferences of `current-pseudo-random-generator'. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] `collection-path' Considered Brittle
While looking at Asumu's `raco-find-collection' package, Asumu and I noticed something about the `collection-path' function that made us uncomfortable. `collection-path' returns *a* path where the given collection is located. With the package system, there can now be *multiple* such paths. `collection-path' returns the first one (in alphabetical order of package name, at first glance). This means that installing a package that extends collection `foo' can break code that uses `(collection-path foo)'. For an example that's currently broken, what used to be an arrow in the macro stepper window is now a box with an X in it. The macro stepper looks for that arrow in the `icons' collection, which is now split between two packages. `collection-path' returns the path from the package that doesn't contain that arrow. A solution would be to provide a `collection-paths' function, that returns *all* the relevant paths, and add a big warning to the documentation of `collection-path'. A `collection-paths' function already exists in `pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt'. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `collection-path' Considered Brittle
At Mon, 4 Nov 2013 11:49:44 -0600, Robby Findler wrote: collection-path is legacy and should generally be removed when you find it (I think I fixed two uses of it Saturday in fact). The documentation does mention that `collection-file-path' is usually preferred, but it doesn't make it clear that `collection-path' is legacy. I'll think of a stronger wording. But hopefully you could use collection-file-path in most cases instead of a collections-path function. I pushed a fix for the macro stepper, using `collections-file-path'. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27395: master branch updated
I was thinking of the `Set' type constructor as meaning generic set, which is why I gave that type to `generic-set?'. This interpretation is a problem because TR treats sets as covariant. If we make sets invariant, could TR support generic sets? [1] Or are there other issues I'm missing? Vincent [1] Better support would also include subtyping between lists and sets. At Fri, 30 Aug 2013 16:38:11 -0700, Eric Dobson wrote: Isn't the assymetric check the wrong way? If it returns true, we know nothing because it might not be a hash-set, but if it returns false then we know that it is not a hash set? On Fri, Aug 30, 2013 at 3:30 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-08-30 16:15:23 -0400, Sam Tobin-Hochstadt wrote: I worry about mutable sets here, but I can't think of any bugs it can cause ATM. I don't have any segfault-causing bugs, but here's a violation of the blame theorem: #lang racket (module a0 racket (define s (mutable-set 1 2 3)) (provide s)) (module a typed/racket (require/typed (submod .. a0) [s Any]) (: x (Setof Any)) (define x (assert s generic-set?)) (provide x)) (require 'a) x Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27395: master branch updated
I'll fix `generic-set?''s type to work with `Set's as hash sets. Vincent At Fri, 30 Aug 2013 17:40:18 -0700, Eric Dobson wrote: As it stands the Set type constructor is for hash sets. Changing that would break backwards compatibility and pr13989 is for the issue of changing the meaning/any change. I think there is a bunch of existing code that assumes that Set is exactly hashsets, or at least covariant. On Fri, Aug 30, 2013 at 5:37 PM, Vincent St-Amour stamo...@ccs.neu.edu wrote: I was thinking of the `Set' type constructor as meaning generic set, which is why I gave that type to `generic-set?'. This interpretation is a problem because TR treats sets as covariant. If we make sets invariant, could TR support generic sets? [1] Or are there other issues I'm missing? Vincent [1] Better support would also include subtyping between lists and sets. At Fri, 30 Aug 2013 16:38:11 -0700, Eric Dobson wrote: Isn't the assymetric check the wrong way? If it returns true, we know nothing because it might not be a hash-set, but if it returns false then we know that it is not a hash set? On Fri, Aug 30, 2013 at 3:30 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-08-30 16:15:23 -0400, Sam Tobin-Hochstadt wrote: I worry about mutable sets here, but I can't think of any bugs it can cause ATM. I don't have any segfault-causing bugs, but here's a violation of the blame theorem: #lang racket (module a0 racket (define s (mutable-set 1 2 3)) (provide s)) (module a typed/racket (require/typed (submod .. a0) [s Any]) (: x (Setof Any)) (define x (assert s generic-set?)) (provide x)) (require 'a) x Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Manual inlining destroys performance for this program
It looks like you may want `define-inline' from `racket/performance-hint'. Vincent At Thu, 22 Aug 2013 11:11:51 -0400, Sam Tobin-Hochstadt wrote: Ah, indeed. I'm calling `random` in the closure now. Fixing that removes the anomaly. Sam On Thu, Aug 22, 2013 at 11:05 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 22 Aug 2013 10:59:35 -0400, Sam Tobin-Hochstadt wrote: This short program generates a lot of closures, and thus doesn't run very fast. #lang racket/base (require racket/flonum) (define (Point x0 x1 y0 y1) (list (λ () (let ([x (- x1 x0)] [y (- y1 y0)]) (flsqrt (+ (* x x) (* y y))) (define iter 1e4) (for ([i (in-range iter)]) (define p (Point (random) (random) (random) (random))) (define f (car p)) (for ([i (in-range 1e3)]) (f))) I tried manually inlining `Point` by replacing `define` with `define-syntax-rule`, and the program gets about 8x *slower*. I don't have any idea why this is happening, especially since `Point` is actually inlined by the optimizer in the `define` case. Any idea why this might be? Using `define-syntax-rule' changes the program from (let ([x (random)]) (call-a-lot (lambda () x))) to (call-a-lot (lambda () (random))) Did you mean to try (define (Point x0 x1 y0 y1) (let ([x (- x1 x0)] [y (- y1 y0)]) (let ([v (flsqrt (+ (* x x) (* y y)))]) (list (λ () v) ? _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] continuation-mark-set-context : Empty Stack Traces?
Thanks! At this point, that same benchmark has about 1 empty stack trace per 300 samples, which should be good enough. Vincent At Mon, 12 Aug 2013 17:25:38 -0600, Matthew Flatt wrote: I've pushed a repair for the main problem on x86_64 Linux (and other platforms that use DWARF-based stack unwind). A related symptom I had noticed was that building without gcc optimization used disabled stack traces; that's now fixed. There are still ways to end up with an empty stack trace, but it should happen much less often. At Wed, 07 Aug 2013 17:49:57 -0400, Vincent St-Amour wrote: I'm profiling one of the contract benchmarks[1], and I noticed that sometimes (about 10 out of 300 samples), `continuation-mark-set-context' would return an empty stack trace. This number is cut down by about half if I disable the JIT. These samples seem to be spread out throughout execution (i.e. not all at the beginning or at the end). I think this may be a regression. At least I've never observed that before (and since this causes the contract profiler to error (a bug which I'll fix), I probably would have noticed). This may be a problem because it would reduce the precision of the profiler by undercounting what actually was on the stack while these empty samples are taken. To observe this, clone the contract benchmarks repository[1], then run the attached version of render-guide.rkt inside that directory. To count the number of empty stack traces, apply the attached patch to the profiler. Vincent [1] https://github.com/stamourv/contract-benchmarks -- [application/octet-stream render-guide.rkt] [~/Desktop open] [~/Temp open] -- [application/octet-stream 0001-Have-profiler-print-number-of-empty-stack-traces.patch] [~/Desktop open] [~/Temp open] _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Package Update Fails?
I had installed Stephen's `graph' package. Then, he pushed a new version, and I tried updating my install. Here's the error I got: stamourv@ahuntsic:plt$ raco pkg update graph Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs Resolving graph via https://pkg.racket-lang.org Updating: graph Resolving graph via https://pkg.racket-lang.org Downloading https://github.com/stchang/graph/tarball/5c769639e02fac538b1034a311ea787627b8a7f6 The following uninstalled packages are listed as dependencies of graph: base data-lib rackunit-lib racket-doc scribble-lib Would you like to install these dependencies? [Y/n/a/?] y Resolving base via https://pkg.racket-lang.org Resolving base via https://planet-compat.racket-lang.org raco pkg update: cannot find package on catalogs package: base At that point, I tried removing it and reinstalling it. I got this error: stamourv@ahuntsic:plt$ raco pkg remove graph Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs Removing graph raco setup: directory: #path:/home/stamourv/src/plt/racket/share/pkgs/graph does not exist for collection: graph context...: /home/stamourv/src/plt/racket/collects/setup/setup-unit.rkt:271:2: core154 /home/stamourv/src/plt/racket/collects/setup/setup-unit.rkt:386:4: for-loop /home/stamourv/src/plt/racket/collects/pkg/main.rkt: [running body] /home/stamourv/src/plt/racket/collects/pkg/raco.rkt: [traversing imports] /home/stamourv/src/plt/racket/collects/raco/raco.rkt: [running body] /home/stamourv/src/plt/racket/collects/raco/main.rkt: [running body] That directory did exist, though. At that point, the package was not listed as installed anymore, but I couldn't install it either: stamourv@ahuntsic:plt$ raco pkg install graph Resolving graph via https://pkg.racket-lang.org Downloading https://github.com/stchang/graph/tarball/5c769639e02fac538b1034a311ea787627b8a7f6 raco setup: given collection path: graph refers to the same directory as another given collection path, graph/graph context...: /home/stamourv/src/plt/racket/collects/setup/setup-unit.rkt:539:2: check-against-all /home/stamourv/src/plt/racket/collects/pkg/main.rkt: [running body] /home/stamourv/src/plt/racket/collects/pkg/raco.rkt: [traversing imports] /home/stamourv/src/plt/racket/collects/raco/raco.rkt: [running body] /home/stamourv/src/plt/racket/collects/raco/main.rkt: [running body] Despite that error, the package was listed as being installed, but it wouldn't work. I ended up removing the package directory and removing the link (using raco link). After that, I was finally able to reinstall the package, and now everything works. The old version did not have an `info.rkt' file, but the new one does. I don't know if that makes any difference. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package Update Fails?
At Tue, 13 Aug 2013 15:59:57 -0600, Matthew Flatt wrote: At Tue, 13 Aug 2013 17:23:33 -0400, Vincent St-Amour wrote: I had installed Stephen's `graph' package. Then, he pushed a new version, and I tried updating my install. Here's the error I got: stamourv@ahuntsic:plt$ raco pkg update graph Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs I think something had gone wrong at this point, because that path looks like it should have been found as installation scope. Right, that's where the package was installed. I had a look at the source at the time, and that's where I found it. If you run `raco pkg show' now, what scope does it show for graph? I get this now, but that's after all the steps from my previous email, which involved manually unlining and reinstalling the package: Installation-wide: Package ChecksumSource graph 5c769639e02fac538b1034a311ea787627b8a7f6(catalog graph) Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package Update Fails?
At Tue, 13 Aug 2013 16:19:28 -0600, Matthew Flatt wrote: At Tue, 13 Aug 2013 18:12:12 -0400, Vincent St-Amour wrote: At Tue, 13 Aug 2013 15:59:57 -0600, Matthew Flatt wrote: At Tue, 13 Aug 2013 17:23:33 -0400, Vincent St-Amour wrote: I had installed Stephen's `graph' package. Then, he pushed a new version, and I tried updating my install. Here's the error I got: stamourv@ahuntsic:plt$ raco pkg update graph Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs I think something had gone wrong at this point, because that path looks like it should have been found as installation scope. Right, that's where the package was installed. I had a look at the source at the time, and that's where I found it. If you run `raco pkg show' now, what scope does it show for graph? I get this now, but that's after all the steps from my previous email, which involved manually unlining and reinstalling the package: Installation-wide: Package Checksum Source graph 5c769639e02fac538b1034a311ea787627b8a7f6 (catalog graph) At this point, does `raco pkg update graph' still show a path for the inferred scope? Yes: stamourv@ahuntsic:plt$ raco pkg update graph Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs Resolving graph via https://pkg.racket-lang.org No updates available Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] continuation-mark-set-context : Empty Stack Traces?
I'm profiling one of the contract benchmarks[1], and I noticed that sometimes (about 10 out of 300 samples), `continuation-mark-set-context' would return an empty stack trace. This number is cut down by about half if I disable the JIT. These samples seem to be spread out throughout execution (i.e. not all at the beginning or at the end). I think this may be a regression. At least I've never observed that before (and since this causes the contract profiler to error (a bug which I'll fix), I probably would have noticed). This may be a problem because it would reduce the precision of the profiler by undercounting what actually was on the stack while these empty samples are taken. To observe this, clone the contract benchmarks repository[1], then run the attached version of render-guide.rkt inside that directory. To count the number of empty stack traces, apply the attached patch to the profiler. Vincent [1] https://github.com/stamourv/contract-benchmarks render-guide.rkt Description: Binary data 0001-Have-profiler-print-number-of-empty-stack-traces.patch Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics updates
At Fri, 2 Aug 2013 15:33:02 -0400, Carl Eastlund wrote: [1 text/plain; UTF-8 (7bit)] On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang stch...@ccs.neu.edu wrote: With that in mind, I think it would make sense to move `set-first' and `set-empty?' to the primitive set (making it clear that they are optional, and can be derived from `set-stream' if need be). With those two in the primitive set, anything that implements all the primitives should get all the derived for free, right? Oh yeah, I like that better than moving set-stream to primitives since they are more standard set operations. So the proposal for primitive methods is to pick one canonical set of methods from which all the others can be derived? I'm fairly sure there's more than one such set, and I'm not sure there's one choice that's clearly better than the others. I can understand the benefits of documenting a suggested set, but given that it is an arbitrary and pragmatic distinction, I'm not sure I'd want to set them off in a section any more. I'd just make a list in the gen:set description or something. Sounds good to me. As long as there's a clear easy starting point for someone implementing a new set type, I think we're good. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics updates
At Thu, 1 Aug 2013 18:56:08 -0400, Carl Eastlund wrote: Ah, yes, set-stream isn't primitive because it can be derived if you have set-first and either set-rest or set-remove. And I know there are dependency cycles, this is intentional so that you can implement any one of several related things, but most of them were supposed to go all the way down to primitive methods (in some sense) if all else failed. Would it be better to just remove the primitve / derived distinction, since it's somewhat artificial, and leave it up to the individual method descriptions? Is there some better way I should be describing things? I like the primitive / derived distinction, but I don't think that the distinction should be done based on the presence of fallback implementations. IMO, it makes more sense to interpret it like Stephen did: what do I need to write to get a minimum viable set type and get the rest for free. Presence or absence of fallbacks is just an implementation detail. If we take that view, then basic (or something) may make more sense than primitive, though. With that in mind, I think it would make sense to move `set-first' and `set-empty?' to the primitive set (making it clear that they are optional, and can be derived from `set-stream' if need be). With those two in the primitive set, anything that implements all the primitives should get all the derived for free, right? Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v5.3.6
The problems I've observed were only with the tests. The first problem I reported was caused by a bug/limitation in places, which was fixed by 733907474190da499a1782b230086170c5b87643. It was preventing the TR test suite from running properly. The others were bugs in the TR tests, not in TR itself. TR itself should be fine for the release. Vincent At Wed, 24 Jul 2013 15:03:08 -0500, Robby Findler wrote: [1 text/plain; UTF-8 (7bit)] Vincent: can you clarify what the status of TR the release is, please? Are there problems only with tests, or were there problems elsewhere too? Thanks, Robby On Tue, Jul 23, 2013 at 9:11 AM, Vincent St-Amour stamo...@ccs.neu.eduwrote: The TR tests still fail when using a single place. The following commits should be included in the release: 069ff59a4bd6a988a5670c7e4dd38c1dbbe12ec0 0e7940ab4943600e6f5c8f13ce7ee13e8af9a8f5 ab5075bc762356f86bb7dfd34dac8d24ada1a140 Vincent At Mon, 22 Jul 2013 17:49:20 -0400, Vincent St-Amour wrote: At Mon, 22 Jul 2013 15:13:28 -0400, Ryan Culpepper wrote: 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 The Linux/i386/Ubuntu Precise installer is 64 bits, which is wrong. * 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.6 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) I get the following error when runing the TR tests: place-channel-put: value not allowed in a message value: '#:methods ... Is 733907474190da499a1782b230086170c5b87643 missing from the release? Now running the tests without places. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev [2 text/html; UTF-8 (quoted-printable)] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v5.3.6
The TR tests still fail when using a single place. The following commits should be included in the release: 069ff59a4bd6a988a5670c7e4dd38c1dbbe12ec0 0e7940ab4943600e6f5c8f13ce7ee13e8af9a8f5 ab5075bc762356f86bb7dfd34dac8d24ada1a140 Vincent At Mon, 22 Jul 2013 17:49:20 -0400, Vincent St-Amour wrote: At Mon, 22 Jul 2013 15:13:28 -0400, Ryan Culpepper wrote: 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 The Linux/i386/Ubuntu Precise installer is 64 bits, which is wrong. * 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.6 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) I get the following error when runing the TR tests: place-channel-put: value not allowed in a message value: '#:methods ... Is 733907474190da499a1782b230086170c5b87643 missing from the release? Now running the tests without places. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] continuation-mark-set-context Regression on 64 bit Linux
On 64 bit Linux, `continuation-mark-set-context' doesn't provide any stack trace anymore, instead always returning the empty list. It was working at least up to 5.3.4. When the JIT is disabled, I get the expected stack traces. This regression breaks the profiler, the contract profiler, and the profiling features of the Optimization Coach. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] continuation-mark-set-context Regression on 64 bit Linux
At Tue, 23 Jul 2013 19:29:27 -0500, Robby Findler wrote: Is this in 5.3.6 or in the git head version? 5.3.6 is fine. That was on git HEAD. Matthew's last commit fixed it. Is this related to the test failures you reported earlier? No. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v5.3.6
At Mon, 22 Jul 2013 15:13:28 -0400, Ryan Culpepper wrote: 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 The Linux/i386/Ubuntu Precise installer is 64 bits, which is wrong. * 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.6 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) I get the following error when runing the TR tests: place-channel-put: value not allowed in a message value: '#:methods ... Is 733907474190da499a1782b230086170c5b87643 missing from the release? Now running the tests without places. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Bash Completion Broken?
Bash completion for raco setup (in pkgs/plt-services/meta/contrib/completion/racket-completion.bash) is currently broken. It only completes collects that are in the core. I haven't tried it, but I suspect that zsh completion is similarly broken. To find collects to complete, the script looks for subdirectories of the directories listed in `current-library-collection-paths'. On my current install, these directories are: /home/stamourv/src/plt/add-on/5.3.900.5/collects /home/stamourv/src/plt/racket/lib/collects which doesn't include package-installed collects. The first directory also doesn't exist. Is this a bug in `current-library-collection-paths', or should the completion script use something else now? As a side-note, I think that plt-services/meta/contrib should be it's own package, or maybe even three separate ones (completion, honu.vim and rubber). If nobody objects, I'll do that. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26936: master branch updated
At Thu, 6 Jun 2013 18:39:57 -0400, Carl Eastlund wrote: Also if you're going to memoize things, why are you using assoc rather than a hash table? Or if at all possible, a weak hash table? I'm using `procedure-closure-contents-eq?' as the equality predicate. AFAIK, there's no hash table for that. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26936: master branch updated
Maybe. I'll see if I can think of a better solution.
Vincent
At Thu, 6 Jun 2013 17:35:50 -0500,
Robby Findler wrote:
Can't we do better than a memo table?
On Thursday, June 6, 2013, wrote:
stamourv has updated `master' from 5ea3a1ce6d to 6e8c9ed15a.
http://git.racket-lang.org/plt/5ea3a1ce6d..6e8c9ed15a
=[ 2 Commits ]==
Directory summary:
82.9% collects/racket/contract/private/
17.0% collects/scribblings/reference/
~~
d1df869 Vincent St-Amour stamo...@racket-lang.org javascript:;
2013-06-06 18:02
:
| Document procedure-closure-contents-eq?.
:
M collects/scribblings/reference/procedures.scrbl | 5 +
~~
6e8c9ed Vincent St-Amour stamo...@racket-lang.org javascript:;
2013-06-06 18:31
:
| Memoize wrapped case- range contracts.
|
| Fixes failing contract tests.
:
M collects/racket/contract/private/arrow.rkt | 21 +++--
=[ Overall Diff ]===
collects/racket/contract/private/arrow.rkt
~~
--- OLD/collects/racket/contract/private/arrow.rkt
+++ NEW/collects/racket/contract/private/arrow.rkt
@@ -1712,12 +1712,21 @@ v4 todo:
the domain of
#:swap? #t)))
dom-ctcs+case-nums)
-(map (λ (f)
- (define p (f rng-blame))
- (lambda args
- (with-continuation-mark
- contract-continuation-mark-key blame
- (apply p args
+(map (let ([memo '()])
+ ;; to preserve
procedure-closure-contents-eq?ness of the
+ ;; wrapped procedures, memoize with f
as the key.
+ (λ (f)
+ (define target
+ (assoc f memo
procedure-closure-contents-eq?))
+ (if target
+ (cdr target)
+ (let* ([p (f rng-blame)]
+[new (lambda args
+
(with-continuation-mark
+
contract-continuation-mark-key blame
+(apply p args)))])
+ (set! memo (cons (cons f new)
memo))
+ new
rng-ctcs)))
(define (chk val mtd?)
(cond
collects/scribblings/reference/procedures.scrbl
~~~
--- OLD/collects/scribblings/reference/procedures.scrbl
+++ NEW/collects/scribblings/reference/procedures.scrbl
@@ -88,6 +88,11 @@ to the wrong number of arguments, the resulting error
hides the first
argument as if the procedure had been compiled with the
@indexed-racket['method-arity-error] syntax property.}
+@defproc[(procedure-closure-contents-eq? [proc1 procedure?]
+ [proc2 procedure?]) boolean?]{
+Compares the contents of the closures of @racket[proc1] and @racket[proc2]
+for equality by comparing closure elements pointwise using @racket[eq?]}
+
@;
@section{Keywords and Arity}
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] TR tests sometimes fail with a promise error
Sam, Asumu and I found and fixed the bug. Here's the problem in a nutshell. This is the implementation of `delay/thread' from racket/promise. (define (delay/thread thunk) (let () (define (run) (call-with-exception-handler (lambda (e) (pset! p (make-reraise e)) (kill-thread (current-thread))) (lambda () (pset! p (call-with-values thunk list) (define p (make-promise/thread (make-running-thread (object-name thunk) (thread run p)) `run' depends on `p', and vice versa. The `run' thread may start executing *before* `p' is actually defined. This causes `pset!' (which is just promise mutation) to mutate `#undefined', which raises an exception[1]. The exception handler then calls `pset!' again, which raises an exception, and kills the thread without setting the promise's value. Our solution is to have `run' block on a channel until `p' is fully initialized. I'll push the fix. Vincent [1] Actually, since `pset!' uses `unsafe-struct-set!', there is no actual exception. The thread gets killed some other way. At Thu, 2 May 2013 22:27:14 -0400, Asumu Takikawa wrote: On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote: This produces a promise error on every third or fifth run or so for me. Commenting out the #:when line makes it work, very oddly. Tried it on another machine, the #:when line didn't matter there. Also, I can reproduce this more reliably on a machine with fewer cores. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR tests sometimes fail with a promise error
At Fri, 3 May 2013 11:56:02 -0400, Eli Barzilay wrote: A few minutes ago, Vincent St-Amour wrote: Sam, Asumu and I found and fixed the bug. Here's the problem in a nutshell. This is the implementation of `delay/thread' from racket/promise. (define (delay/thread thunk) (let () (define (run) (call-with-exception-handler (lambda (e) (pset! p (make-reraise e)) (kill-thread (current-thread))) (lambda () (pset! p (call-with-values thunk list) (define p (make-promise/thread (make-running-thread (object-name thunk) (thread run p)) [...] Our solution is to have `run' block on a channel until `p' is fully initialized. I'll push the fix. I haven't looked at the code recently, but I think that something along these lines can work instead of some explicit syncing: (define (delay/thread thunk) (let () (define p (make-promise/thread #f)) (pset! p (make-running-thread (thread (λ() ...same... p)) I think that introduces another race condition. If the thread is forced before the `pset!', then `force' would return #f (line 107 of racket/promise.rkt), since the value inside the `promise/thread' is not a thread. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR tests sometimes fail with a promise error
Sounds good, I'll use a semaphore. Vincent At Fri, 3 May 2013 09:58:25 -0600, Matthew Flatt wrote: Thanks for tracking this down! In case you mean a channel in the sense of `make-channel', I recommend a semaphore, instead, since a semaphore is the lightest-weight synchronization construct. At Fri, 03 May 2013 11:45:38 -0400, Vincent St-Amour wrote: Sam, Asumu and I found and fixed the bug. Here's the problem in a nutshell. This is the implementation of `delay/thread' from racket/promise. (define (delay/thread thunk) (let () (define (run) (call-with-exception-handler (lambda (e) (pset! p (make-reraise e)) (kill-thread (current-thread))) (lambda () (pset! p (call-with-values thunk list) (define p (make-promise/thread (make-running-thread (object-name thunk) (thread run p)) `run' depends on `p', and vice versa. The `run' thread may start executing *before* `p' is actually defined. This causes `pset!' (which is just promise mutation) to mutate `#undefined', which raises an exception[1]. The exception handler then calls `pset!' again, which raises an exception, and kills the thread without setting the promise's value. Our solution is to have `run' block on a channel until `p' is fully initialized. I'll push the fix. Vincent [1] Actually, since `pset!' uses `unsafe-struct-set!', there is no actual exception. The thread gets killed some other way. At Thu, 2 May 2013 22:27:14 -0400, Asumu Takikawa wrote: On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote: This produces a promise error on every third or fifth run or so for me. Commenting out the #:when line makes it work, very oddly. Tried it on another machine, the #:when line didn't matter there. Also, I can reproduce this more reliably on a machine with fewer cores. Cheers, Asumu _ 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] TR tests sometimes fail with a promise error
At Fri, 3 May 2013 12:17:46 -0400, Eli Barzilay wrote: A few minutes ago, Vincent St-Amour wrote: At Fri, 3 May 2013 11:56:02 -0400, Eli Barzilay wrote: (define (delay/thread thunk) (let () (define p (make-promise/thread #f)) (pset! p (make-running-thread (thread (λ() ...same... p)) I think that introduces another race condition. If the thread is forced before the `pset!', then `force' would return #f (line 107 of racket/promise.rkt), since the value inside the `promise/thread' is not a thread. But this can't happen because `delay/thread' won't return with the broken promise until after the `pset!' fixed it. (Even code in the input thunk will not be able to try to force itself without having itself accessible as a value.) Makes sense. I'll give it a try. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR tests sometimes fail with a promise error
I tried your suggestion, and it doesn't fix the original bug. I'll stick with the semaphores solution. Vincent At Fri, 03 May 2013 13:13:45 -0400, Vincent St-Amour wrote: At Fri, 3 May 2013 12:17:46 -0400, Eli Barzilay wrote: A few minutes ago, Vincent St-Amour wrote: At Fri, 3 May 2013 11:56:02 -0400, Eli Barzilay wrote: (define (delay/thread thunk) (let () (define p (make-promise/thread #f)) (pset! p (make-running-thread (thread (λ() ...same... p)) I think that introduces another race condition. If the thread is forced before the `pset!', then `force' would return #f (line 107 of racket/promise.rkt), since the value inside the `promise/thread' is not a thread. But this can't happen because `delay/thread' won't return with the broken promise until after the `pset!' fixed it. (Even code in the input thunk will not be able to try to force itself without having itself accessible as a value.) Makes sense. I'll give it a try. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3.4, Final Draft
At Wed, 1 May 2013 17:35:44 -0400, Eli Barzilay wrote: * The Optimization Coach DrRacket plugin has been moved from the Racket distribution to the Racket package repository. It might be good to include some very quick instructions on how to install it. * The Optimization Coach DrRacket plugin has been moved from the Racket distribution to the Racket package repository. Install it with: raco pkg install optimization-coach Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Potential Constant Propagation Bug
I have found what I think may be a bug in Racket's constant propagation: (unsafe-fx* 0 (error 'foo)) does not throw and error and evaluates to 0. If 0 is replaced with another value, or if it's `read' in, the error is thrown. `unsafe-fxquotient' has the same issue. On the one hand, this is an unsafe operation, so maybe I shouldn't expect the error to be thrown. On the other hand, I would expect effectful arguments to functions to be evaluated no matter what. Is this a bug, or is this the desired behavior for unsafe operations? Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26372: master branch updated
At Tue, 26 Feb 2013 16:59:01 -0500, mfl...@racket-lang.org wrote: 899a327 Matthew Flatt mfl...@racket-lang.org 2013-02-26 14:14 : | add experimental support for phaseless modules | After reading the docs, I find the name phaseless confusing. IIUC, these modules are not special because they have no phase, but rather because they're the same at all phases. Would pan-phase, omni-phase or cross-phase be an accurate description? Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v5.3.2
At Thu, 17 Jan 2013 13:46:37 -0500, Ryan Culpepper wrote: * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests Both done. - Typed Racket Updates: update HISTORY Pushed. Commit e763d1e1ae7cfe04d0fff173292340b6fd6c4ae6 . Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3.2
At Thu, 17 Jan 2013 13:57:51 -0500, Ryan Culpepper wrote: - define-inline (b715a6fe) * Added `define-inline' which defines functions that are guaranteed to be inlined. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Five feature/limitation interactions conspire to drive mad
At Wed, 02 Jan 2013 16:57:39 -0700, Neil Toronto wrote: On 01/02/2013 02:51 PM, Vincent St-Amour wrote: In your experience, have these types caused you trouble other than when you went looking for them specifically? Not that I recall. If I stick to union types like Integer, Exact-Rational, Flonum, Real, and Number, they don't often show up. I expect generalization and covariance have a lot to do with it. Great! Of course, these types caused me trouble immediately because I went looking for them immediately, to get optimizations. It's a happy accident that always using Index for bounds and bounds-checked values works out so well. (Unless you planned it?) That's the reason I added `Index'. Without it, fixnum optimizations would have been pretty much impossible. This brings me to what I think is the major issue for us n00bs: the types force you to understand the numeric tower really well if you want to use types more precise than `Number'. Before you reach that level of understanding, though, and Typed Racket spits errors at you, it's hard to tell whether it has a legitimate complaint - especially when you don't know whether you should expect, say, (i . fx . 0) to prove i : Positive-Index. Were there specific corners of the tower that you found frustrating (other than fixnum types)? Mostly `sqrt' and `log', when it's hard to prove their arguments are nonnegative. I've gotten around it using `flsqrt' and `fllog'. I was usually working with flonums anyway. Yep, that's a good workaround (which OC recommends). It would be nice to also have specialized versions of `sqrt', `log' and co that accept reals, but raise exceptions instead of returning complex results. They would still have to internally check for sign before calling `sqrt' (or `real?' after, if we optimistically call `sqrt'), so they may not be any faster than doing it inline in user code, but they may still be convenient. Would it make sense to provide something like that as part of the math library? One that has bugged me recently is that TR can't prove (* x (conjugate x)) : Nonnegative-Real. I have no idea how you'd do it without turning Number into a product type, though. With richer types for complexes, this could be expressible. But it would require duplicating the numeric tower for each component, which would get very complicated (and slow down typechecking) very fast. We thought about doing it, but quickly decided against it. The costs clearly outweight the benefits. I almost forgot this one: (/ (ann 5 Nonnegative-Real) (ann 3 Nonnegative-Real)) - : Real 1 2/3 That one is by design. - (/ (ann +inf.0 Nonnegative-Real) (ann -0.0 Nonnegative-Real)) - : Real -inf.0 Considering all the floating-point zeroes to be non-negative (and non-positive) helps with closure properties, but does cause some unexpected corner cases. We've thought about that one for a while, and I think it's the right compromise. If you want more, you can grep for `assert' in the math library. I will, thanks! But it's often really hard to prove that something is nonnegative without an explicit cast, assertion, or test, and thus stay within the reals in expressions with roots. I actually see that as a positive: if a property is too hard to prove using the type system alone, you have the option to use casts, assertions, or tests to help TR prove what you want [1]. Casts, assertions and tests give you extra power to prove things that you couldn't prove otherwise, or to make proofs easier. We should differentiate between what *I* can prove and what *Typed Racket* can prove. I can usually prove more. Right. Replace prove with make TR prove in what I said. Thanks again for the feedback! Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Five feature/limitation interactions conspire to drive mad
At Wed, 02 Jan 2013 12:39:21 -0700, Neil Toronto wrote: Interesting. My extremely limited experience -- and Shriram's -- suggests an eternal struggle with the numerical tower for 'beginners' like myself. This is my experience as well. One place this bit me pretty early was getting TR to optimize loops over indexes *without using casts or assertions*. Right, fixnum types are tricky. They don't have many closure properties, so it's hard to stay within these types. Because of this, we try to avoid exposing these types to beginners as much as possible (by, e.g., not having functions in the standard library require them as arguments). The hope is that only experts that are trying to either (1) get every bit of performance our of their programs or (2) enforce strict range properties in their programs actually need to use these types. For the first use case, OC provides some help (and better support is on the way). In your experience, have these types caused you trouble other than when you went looking for them specifically? Unfortunately, (i . fx . 0) doesn't prove i : Positive-Index, even though it could. That's a bug. This brings me to what I think is the major issue for us n00bs: the types force you to understand the numeric tower really well if you want to use types more precise than `Number'. Before you reach that level of understanding, though, and Typed Racket spits errors at you, it's hard to tell whether it has a legitimate complaint - especially when you don't know whether you should expect, say, (i . fx . 0) to prove i : Positive-Index. Were there specific corners of the tower that you found frustrating (other than fixnum types)? It would be really handy if TR could give counterexamples in these cases. This is how you can end up with an exact zero by multiplying an exact rational and a flonum: (* 0 1.0). Since most TR optimization failures can be traced back to a failure to typecheck at an optimizable type, Optimization Coach should be able to help you here. It doesn't currently provide counter-examples, but I'll look into it. However, OC requires a program that typechecks, so it doesn't always apply. Perhaps applying optimization coaching techniques (especially proximity) to type error messages would work. Worth a try. After you do understand the numeric tower well, you start looking for ways to prove to TR that your code won't explode at runtime. It's not always possible - again because, sometimes, the types aren't as precise as they could be. But sometimes because it's just hard. One fine example is `sqrt'. Its types are sensible: (sqrt (ann 5 Real)) - : Number 2.23606797749979 (sqrt (ann 5 Nonnegative-Real)) - : Real [generalized from Nonnegative-Real] 2.23606797749979 But it's often really hard to prove that something is nonnegative without an explicit cast, assertion, or test, and thus stay within the reals in expressions with roots. I actually see that as a positive: if a property is too hard to prove using the type system alone, you have the option to use casts, assertions, or tests to help TR prove what you want [1]. Casts, assertions and tests give you extra power to prove things that you couldn't prove otherwise, or to make proofs easier. As for the difficulty of proving properties, specific types could probably be improved, but I don't have a general solution. Racket's numeric tower is complicated, and TR needs to be compatible with it. Thanks for the feedback! Vincent [1] Assertions and tests are usually cheap, but casts are surprisingly expensive since they involve contracts. There's probably room for improvement there. In the meantime, I'll extend OC to warn you when you use casts in hot code. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR: Five feature/limitation interactions conspire to drive mad
At Mon, 31 Dec 2012 13:27:50 -0700,
Neil Toronto wrote:
1. Allow submodules to extend the reader.
Would using `#lang typed/racket/no-check' instead of `#lang racket' for
the top-level module work? It extends the reader and provides TR's
annotated forms, but otherwise counts as an untyped language.
That's not a general solution, but it may solve your problem.
2. Don't generalize argument types in let loops.
This is a bad idea. Often, inferring the types of loops only works
because of type generalization.
Agreed. Since this one is only a problem because of the other
limitations you list, ideally we should fix the others and leave this
one alone. Do you agree?
3. Allow let: loops to have unannotated arguments and return values.
This would totally work. I could use [i : Nonnegative-Fixnum 0] instead
of [#{i : Nonnegative-Fixnum} 0], and still not have to annotate `acc'
or the loop's return value.
Trying this one right now.
I think all of TR's annotating forms should allow any annotation to be
left out.
I'll look into that next.
4. Extend the set of types TR can produce contracts for.
This probably only works for first-order function types. It would be
helpful, but may not even work for functions with `Array' or `Matrix'
arguments (they're higher-order).
I can look into making contract generation smarter. Could you send me
a list of types that caused you issues with contract generation?
There are two more general solutions to the first problem, that
single-arity `case-' types sometimes make annotating impossible:
5. Find some way to name the polymorphic arguments in `case-' types.
Yes. This. At least 25% of my time refactoring `math/matrix' has gone to
writing twisty, annotation-free function bodies.
I agree that this would be useful. Sam, do you think this is doable?
In general, we need a better story for scaling up programming with
intersection types.
Vincent
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Contract barrier inefficiencies
At Thu, 27 Dec 2012 19:21:53 -0600, Robby Findler wrote: OC could suggest moving heavily called functions across boundaries, that'd be cool. That sounds interesting, and would be a good use of profiling information. Added to my to-do list. Thanks for the suggestion! Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25911: master branch updated
At Mon, 17 Dec 2012 15:00:04 -0500, stamo...@racket-lang.org wrote: b715a6f Vincent St-Amour stamo...@racket-lang.org 2012-12-14 11:39 : | Add define-inline. | | Drop-in replacement for define that guarantees inlining. : M collects/meta/props | 2 ++ A collects/unstable/inline.rkt A collects/unstable/scribblings/inline.scrbl M collects/unstable/scribblings/unstable.scrbl | 1 + I'm not sure where this should go, so I put it in `unstable' for now. It's related to `begin-encourage-inline' from `racket/performance-hint' but since `define-inline' depends on `syntax/parse', I'm hesitant to put it there. The new Optimization Coach will recommend using it instead of `define' in some cases, so maybe it should be provided by OC? It's useful beyond OC, though, so that doesn't feel like the right place. Suggestions? Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] first and rest in racket/base
I just got tripped up, again, trying to traverse a list with `first' and `rest' in a `racket/base' file. `first' and `rest' are only available in `racket' and `racket/list', but not in `racket/base'. If we want to encourage use of `first' and `rest' over `car' and `cdr' and of `racket/base' when possible (which, e.g., the style guide does), I think it makes sense to provide `first' and `rest' in `racket/base'. The attached patch implements that change. Does this sound reasonable? Vincent 0001-Move-first-and-rest-to-racket-base.patch Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] first and rest in racket/base
At Thu, 13 Dec 2012 14:51:42 -0500, Eli Barzilay wrote: A few minutes ago, Jay McCarthy wrote: I agree with Eli. first is not car and shouldn't be treated as it. car : (Cons a b) - a first : (List a) - a Right -- it's a different type, and the `list?' check adds a cost. I don't have too much problem with how they are now -- it's just that moving them to the base language makes it easier to think that they're the same thing, even more in the presence of the CL thing (where they are the same). `racket/base' already has both `pair?' and `list?', and I don't think anyone is getting confused. `#lang racket' has all of them, and that does not seem to cause any issues either. I could amend my patch to move the documentation of `first' and `rest' with the other list operations in `racket/base' (`length', `list-ref', etc.) instead of with `car' and `cdr'. Do you think that would help? Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25861: master branch updated
At Thu, 06 Dec 2012 16:27:20 -0700, Neil Toronto wrote: On 12/06/2012 04:12 PM, stamo...@racket-lang.org wrote: cc8bd4f Vincent St-Amour stamo...@racket-lang.org 2012-12-06 11:59 : | Make srclocs serializable. : M collects/racket/private/serialize.rkt | 10 -- M collects/scribblings/reference/serialization.scrbl | 10 +- M collects/tests/racket/serialize.rktl | 3 +++ Very interesting. What's it for? A new version of Optimization Coach that integrates with the profiler. Should be out soon. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [PATCH] Add a `zip' procedure to lists
Providing `zip' is still useful IMO, both for people who don't know / remember that trick and as a shorthand. Vincent At Fri, 9 Nov 2012 07:34:35 -0500 (EST), J. Ian Johnson wrote: [forgot reply all] zip is unnecessary because of n-ary map. (zip l0 l1) = (map list l0 l1) -Ian - Original Message - From: Diogo F. S. Ramos diogo...@gmail.com To: dev@racket-lang.org Sent: Thursday, November 8, 2012 11:46:15 PM GMT -05:00 US/Canada Eastern Subject: [racket-dev] [PATCH] Add a `zip' procedure to lists `zip' gathers together each element of each list, in order, returning a list of those elements. For example: (zip (list 4 2) (list 3 5)) = '((4 3) (2 5)) Every list has to have the same length. --- There was talk in the IRC about implementing a `zip' procedure. Here is my try. Unfortunately I still don't know what is the preferred way to check for the validity of the parameters. I tried to copy the style of the rest of the file. collects/racket/list.rkt |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/collects/racket/list.rkt b/collects/racket/list.rkt index fe32f68..18055e5 100644 --- a/collects/racket/list.rkt +++ b/collects/racket/list.rkt @@ -32,7 +32,8 @@ append-map filter-not shuffle - range) + range + zip) (define (first x) (if (and (pair? x) (list? x)) @@ -407,3 +408,9 @@ [(end)(for/list ([i (in-range end)])i)] [(start end) (for/list ([i (in-range start end)]) i)] [(start end step) (for/list ([i (in-range start end step)]) i)])) + +(define (zip list1 list2 . lists) + (for ((l (list* list1 list2 lists))) +(unless (list? l) + (raise-argument-error 'zip list? l))) + (apply map list (list* list1 list2 lists))) -- 1.7.9.5 _ 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] Release Announcement for v5.3.1
At Wed, 24 Oct 2012 20:29:43 -0400, Ryan Culpepper wrote: stamourv: - scheme language deprecation notice (68260a6c86) - compat: packages, mutable lists (800a328fe6) - NaN included in all float types (a6d5a98b61) * The `#lang scheme' language is deprecated. `#lang racket' should be used instead. * The `compatibility' collection provides features from Racket relatives, such as `defmacro' and mutable lists. These features are provided to ease porting code to Racket. We do not recommend using them in modern Racket code. * NaN is included in all of Typed Racket's floating-point types, which makes precise floating-point types easier to use. * Typed Racket provides the `:query-type/args' and `:query-type/result' utilities to explore types at the REPL. * Screenshots of the widgets provided by the Racket GUI library are included in the documentation. (Thanks to Diogo F. S. Ramos.) - optimization coach changes? Nothing major. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3.1
For the first one, the new part is the deprecation notice in the docs. Probably not worth including. The others items are not major changes. I don't mind if they're not included. Vincent At Sun, 28 Oct 2012 15:38:44 -0500, Robby Findler wrote: Is the first one is something new? Otherwise, I'm not sure that any of these should be in the release announcement, unless maybe there's something I'm missing about the changes? Robby On Sunday, October 28, 2012, Vincent St-Amour wrote: At Wed, 24 Oct 2012 20:29:43 -0400, Ryan Culpepper wrote: stamourv: - scheme language deprecation notice (68260a6c86) - compat: packages, mutable lists (800a328fe6) - NaN included in all float types (a6d5a98b61) * The `#lang scheme' language is deprecated. `#lang racket' should be used instead. * The `compatibility' collection provides features from Racket relatives, such as `defmacro' and mutable lists. These features are provided to ease porting code to Racket. We do not recommend using them in modern Racket code. * NaN is included in all of Typed Racket's floating-point types, which makes precise floating-point types easier to use. * Typed Racket provides the `:query-type/args' and `:query-type/result' utilities to explore types at the REPL. * Screenshots of the widgets provided by the Racket GUI library are included in the documentation. (Thanks to Diogo F. S. Ramos.) - optimization coach changes? Nothing major. Vincent _ 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.1, Second Call
At Mon, 22 Oct 2012 18:11:22 -0400, Ryan Culpepper wrote: * Sam Tobin-Hochstadt sa...@ccs.neu.edu, Vincent St-Amour stamo...@ccs.neu.edu - Match Tests - Typed Racket Tests All passed. Insert large letters is currently broken, though. Sam's on it. - 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.) Sam's on it. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Disjoint unions (from PR 13131)
At Sat, 22 Sep 2012 10:52:49 -0400, Eli Barzilay wrote: A few minutes ago, Matthias Felleisen wrote: I consider this problem distinct from Vincent's. Yes, the problem is separate (hence moving the discussion) -- it's the feature that he mentioned (being able to hide types) that I was referring to. I'd argue that the separate this/that constructors exist in your mind only. I'm not following that... If you're saying that the two constructors are not separate, then I'm more than agreeing -- I'm saying that this is the main feature of the whole thing: the fact that you cannot treat them as separate constructors as far as the type system goes. Using plain structs so there's a separate `This' and `That' types is exactly the thing that I want to remove from these type definitions. To make this even more concrete, if the types are hidden, then I cannot write this (I'm overloading `This' as both the constructor name and the type name): (: foo : Integer - This) (define (foo x) (This x)) The nice feature that Vincent describes (and that I didn't know about) is how TR will not show hidden types without the explicit introspection tool, so even if I leave things for TR's inference, I would see this on the REPL: (This 1) - : SOMETHING --- the type is not `This' (This 1) This is not what I'm describing. If `(This 1)' is used as type `SOMETHING', the TR printer will print the type as `SOMETHING', and not `(U This That)'. This is what I mean when I say that the TR printer is smart about named unions. The introspection tool allows you to look inside `SOMETHING' (:type SOMETHING) (U This That) In your example, `(This 1)' is not used as type `SOMETHING'. It's just a `This', so its type gets printed as `This'. If you want all `This's to always be considered as `SOMETHING's, you can use a wrapper around the constructor: (define (This-wrapper x) (Ann (This x) SOMETHING)) What I'm suggesting is that some unions (e.g. `Natural') be opaque even to the introspection tool. Since there's no way to get something to typecheck as `Positive-Integer-Not-Fixnum' (the typechecker will never give that type to anything, it's just a trick to get more precise intersections) showing it in `:type''s output is confusing. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
At Sun, 16 Sep 2012 17:10:01 -0500, Matthias Felleisen wrote: Suppose we had started Racket long ago and maintained it until now. Then we'd be looking at 8bit, 16, 32, and 64 precision. In some N years from now, we may need 128. (Actually there were machines in the past that did, but never mind.) Could we separate precision and type into separate dimensions so that we could state types like this: ∀ p : precision. FP[p] - FP[p] where we see FP as a type constructor that consumes a precision value to generate the right kind of type. This might be a dependent type but it could be a useful one. Of course, it isn't really a parametric form of polymorphism as Neil's functions show (and better still Vincent's rewrites). I think row types can give us that, and clean up other parts of the numeric tower, too. That's something we've been thinking about for some time. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
At Fri, 14 Sep 2012 23:45:43 -0500, Robby Findler wrote: The original message in this thread suggests that there is a type Single-Flonum and that it is making Neil wrangle his code to be careful about it. Right, TR supports `Single-Flonum's, but not `f32vector's. Part of the complexity in Neil's code is due to types, part of it is not. Assuming he wrote the math library in untyped Racket: (define (foo x) (cond [(double-flonum? x) (flfoo x)] [(single-flonum? x) (real-single-flonum (flfoo (real-double-flonum x)))] [else (flfoo (real-double-flonum x))])) The code is exactly the same as before. The complexity comes from the fact that this function, when given single-precision inputs, wants to produce single-precision outputs, hence the special case. If Neil wants `foo' to be as flexible as Racket's built-in operations (which, when given single-precision inputs, produce single-precision outputs), he needs that special case, types or not. If he gives up on that flexibility, things become a lot simpler: (define (foo x) (flfoo (real-double-flonum x))) This version still accepts single-precision inputs, but always produces doubles. The types simply mirror that distinction: (: foo (case- (Single-Flonum - Single-Flonum) (Flonum - Flonum) (Real - Real))) vs (: foo (Real - Flonum)) This kind of complexity gets worse for functions with multiple arguments, and types make it worse. When expressing coercion rules, the implementation can take shortcuts that the type system cannot currently express, leading to unwieldy types. These issues only come up when writing libraries that aim to propagate Racket's numeric flexibility, such as the math library or TR's base environment. Clients of either don't need to worry about any of that. Single-precision floats are not the source of this problem (you would run into the same issues, in both the untyped and typed worlds, with a function that takes ints to ints and floats to floats), but they do add one more type to worry about. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What are single flonums good for?
Single-precision float support used to be enabled via a configure option, which meant that some Racket installations would support them, and some would not. Since zo files are meant to be portable, they could not contain single-precision floats. So, compilation would promote single literals to doubles. This meant that compilation could change the behavior of a program. Here's an example: stamourv@ahuntsic:small-float-test$ cat test2.rkt #lang racket (define (f x) (displayln (flonum? x))) (f (if (with-input-from-string #t read) 1.0f0 2.0f0)) stamourv@ahuntsic:small-float-test$ racket test2.rkt #f stamourv@ahuntsic:small-float-test$ raco make test2.rkt stamourv@ahuntsic:small-float-test$ racket test2.rkt #t stamourv@ahuntsic:small-float-test$ This example has to be a bit convoluted to defeat constant folding, which makes the problem disappear: stamourv@ahuntsic:small-float-test$ cat test.rkt #lang racket (flonum? 1.0f0) stamourv@ahuntsic:small-float-test$ racket test.rkt #f stamourv@ahuntsic:small-float-test$ raco make test.rkt stamourv@ahuntsic:small-float-test$ racket test.rkt #f stamourv@ahuntsic:small-float-test$ raco decompile test.rkt (begin (module test (#%apply-values |_print-values@(lib racket/private/modbeg.rkt)| '#f))) stamourv@ahuntsic:small-float-test$ This can make for pretty elusive bugs. This gets especially problematic when you add unsafe float operations to the mix, which can turn these issues into segfaults. The solution we picked was to support single-precision floats by default and to allow them in zos, which makes these discrepancies go away. I agree that having to handle single floats when reasoning about numbers complicates things, and it annoys me too. But I still think it's less problematic than what I describe above. At Wed, 12 Sep 2012 08:31:29 -0600, Neil Toronto wrote: I ask because I'm tired of worrying about them. More precisely, I'm tired of Typed Racket (rightly) making me worry about them. I'm also a little bit tired of this: (: foo (case- (Single-Flonum - Single-Flonum) (Flonum - Flonum) (Real - Real))) (define (foo x) (cond [(double-flonum? x) (flfoo x)] [(single-flonum? x) (real-single-flonum (flfoo (real-double-flonum x)))] [else (flfoo (real-double-flonum x))])) This function already converts rationals to doubles, and it seems `flfoo' produces doubles too. You could drop the second clause, always produce doubles, change the type to `(Real - Flonum)' and leave the conversion to single to the client. Since the math library always operates on doubles internally anyway, this would also eliminate unnecessary conversions to singles between stages of a pipeline. They make it easy to write wrong code, because it's easy to use `exact-inexact' when you really should use `real-double-flonum'. Plot, for example, fails to render functions that return single flonums. I'm surprised it doesn't segfault. Good point, that's a problem. I'm sure plot isn't the only one. Every use of `exact-inexact' in the standard library is suspect. If followed by applying an unsafe op, it's wrong. Why do we have these things? I don't know why they were added originally (as an option). In my limited experience, I don't think I've seen non-test code that uses them. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR's optimizer eventually going to unbox structs?
I don't think it would be necessary. For the optimization to trigger, the only thing a step in the chain can do with its argument is use its components. Anything else (e.g. checking whether it's a substruct) would require the argument to be boxed, and would prevent the optimization from happening. Each step of the chain is very limited in what it can do to its argument, which works fine for complex numbers (most operations on them only use the components), but I'm not sure it would work well for structs. Vincent At Mon, 27 Aug 2012 10:15:04 -0500, Robby Findler wrote: Would you need a and is not a substruct? predicate to make such things work? Robby On Mon, Aug 27, 2012 at 10:11 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: TR's complex number optimizations eliminate repeated boxing and unboxing in chains of operations that each consume and produce complex numbers. Similar optimizations for structs would eliminate structs for intermediate results in chains of operations that each consume and produce that same (single) kind of struct. If your code has such chains of operations, then these optimizations could apply. Do you have code that you think would benefit that I could look at? Vincent At Sat, 18 Aug 2012 12:40:21 -0600, Neil Toronto wrote: Is TR's optimizer eventually going to unbox structs in the same way it unboxes rectangular flonums? I have a design choice right now: how to represent probabilities. Floats are good because of their speed, but because of floating-point limitations, *four different representations* are typically used. (For the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions that accept any one of these representations, denoted by this type: (define-type Probability (U probability 1-probability log-probability log-1-probability)) The types are simply struct types that tag Float. Of course, manually boxing flonums ruins any chance of the compiler emitting code that keeps the flonums unboxed. If TR's optimizer unboxed structs, though, everything could be speedy. FWIW, by eventually, I mean within the next n years, where n is a smallish number. Neil ⊥ _ 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] Release Announcement for v5.3, third draft
At Thu, 02 Aug 2012 11:28:56 -0400, Ryan Culpepper wrote: 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? I'd leave it out. This is unrelated to the release. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Tue, 31 Jul 2012 09:26:56 -0700, Sam Tobin-Hochstadt wrote: On Tue, Jul 31, 2012 at 6:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: To start afresh, here are two suggestions, which are mutually exclusive. The first is my preference: 1. Revert the addition of `compatibility/package' and `compatibility/mpair', including the documentation changes (but maybe add back some text to discourage misuse of these libraries). I definitely think we should keep `mpair` as a more-than-compatibility library. It's useful in real data structures, and it's nice not to have to roll your own mutable linked list when it's the right choice. Mutable pair functions are in `racket/base', I didn't touch these and am not planning to. Mutable list functions, though, I moved. The name is misleading. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A Const type constructor
At Tue, 31 Jul 2012 14:36:06 -0400, Matthias Felleisen wrote: On Jul 31, 2012, at 1:31 PM, Neil Toronto wrote: To reiterate after my absence: I won't write a typed math/vector until using its exports in Typed Racket wouldn't be a huge friggin' PITA. Let me rephrase this ever so gently. Typed Racket has failed at least one real test for now, namely, writing a highly usable math library. Agreed. The invariance of vectors is a pretty big usability problem here. I think this is a fair judgment, and you are posing the obvious, not so implied problem to the TR maintainers to fix this problem. They should thank you on their knees, especially Vincent. Yes, Sam and I should fix this. Neil: I'll study your proposal in detail, and see how we could add it (or something similar) to TR. Thanks for taking the time to write it out. I'll have a look at what Scala does, too. AFAIK, they also have invariant vectors and more than one numeric type, so they probably have similar problems. To offer a carrot instead of a stick: There could be a short paper in this, titled The Case for a Clean, Correct, Covariant Const. That is what I was thinking as I was reading your message. I have not encountered such a proposal/language before, and I think it could be a really neat extension of Vincent's PADL work. Agreed. Perhaps the two of you should work out the details together and submit follow-up to PADL n+1. Oh never mind, D stands for declarative. So ship it to ICFP next year, functional languages do include mutation. Sounds good to me. Neil: let's continue this discussion off-list. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Tue, 31 Jul 2012 13:04:40 -0600, Matthew Flatt wrote: At Tue, 31 Jul 2012 14:08:16 -0400, Vincent St-Amour wrote: Mutable pair functions are in `racket/base', I didn't touch these and am not planning to. Mutable list functions, though, I moved. The name is misleading. Should `compatibility/mpair' be `compatibility/mlist' (while `racket/mpair' keeps the misleading name)? Good idea. I'll do that. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Mon, 30 Jul 2012 13:10:28 -0600, Matthew Flatt wrote: At Fri, 20 Jul 2012 16:33:54 -0400, Vincent St-Amour wrote: 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. Sorry that I'm so late to this thread. I think a compatibility collection is a good idea, and it's a fine place for `defmacro'. I don't think `racket/...' libraries should move there, though. When the next big language shift comes, we should leave out some libraries that are now in racket, and then it may make sense to add some left-out ones to compatibility. As long as they stick around in racket though (for compatibility!), I think there's little advantage in adding them to compatibility. The main advantage (IMO) of having, say, mutable lists in `compatibility' is that searching the docs points there instead of to `racket'. This makes it clear that they are not a blessed Racket feature. This is (IMO) the main point of the `compatibility' collect. FWIW, the `package' form wasn't even intended for compatibility. It was intended to support namespace management --- possibly as an expansion target for macros --- and to work in contexts other than module top levels. It hasn't turned out to be useful, though. Now that we have submodules, are packages still useful? If not, we should encourage the use of submodules over packages, and putting packages in `compatibility' makes it clear that they are not the preferred option. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Mon, 30 Jul 2012 16:00:12 -0400, Matthias Felleisen wrote: Having said that, I would like to propose that we COPY files/subcollections from racket/ to compatibility/ (and keep them in sync) if we wish to indicate that they are not really rackety. Assuming you mean keeping the same interface re-providing bindings from one to the other, as opposed to duplicating the implementation, then that's what I did. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Mon, 30 Jul 2012 14:52:06 -0600, Matthew Flatt wrote: At Mon, 30 Jul 2012 16:00:12 -0400, Matthias Felleisen wrote: I fully and enthusiastically agree with this perspective but I don't think this is high on our list of things to do. When we consider such moves, we should always consider the opportunity cost. What could I accomplish instead? Having said that, I would like to propose that we COPY files/subcollections from racket/ to compatibility/ (and keep them in sync) if we wish to indicate that they are not really rackety. That's committed already, so I'm suggesting that we do more work to un-commit the change. It's the spirit of avoiding more of the kind of work that you suggest we avoid, though. If we really want to have two names for these things --- the compatibility name and the compatibility name --- then I think we should at least consolidate to a single compatibility manual by moving the documentation for `racket/mpair' and `racket/package' to the compatibility manual. To make sure I understand correctly, you're suggesting that: - We keep the `compatibility' collect. - We keep `compatibility/defmacro'. - We remove `compatibility/mpair' and `compatibility/package', and move them back to `racket/mpair' and `racket/package', respectively. - We leave the reference and the compatibility manual as is, with docs for `racket/mpair' and `racket/package' in the compatibility manual. If that's what you're suggesting, I'll implement it. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25105: master branch updated
At Sun, 29 Jul 2012 10:15:17 -0400, Matthias Felleisen wrote: With all due respect. Was there a reason why parametric imports don't work? They do change behavior in a way that doesn't jive with the TR port-to-typed-without-change-in-semantics philosophy. Parametric imports were already in `typed/racket', but were not in `typed/racket/base'. This commit fixes `typed/racket/base' to be consistent with `typed/racket'. It doesn't change the semantics of parametric imports. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3
At Wed, 25 Jul 2012 13:26:53 -0400, Ryan Culpepper wrote: stamourv: - enable performance report for typed/racket/base (b73421f8) - Optimization Coach (formerly Performance Report) now reports information about Racket's inlining optimizations. Optimization Coach can be launched in any language through the View menu. samth: - keyword functions in TR (865a2cdc) - TR load time optimizations (794bfa50, 6bf14151) - Typed Racket now supports definition of functions with keyword arguments. - Startup time of Typed Racket programs has been reduced. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25038: master branch updated
At Fri, 20 Jul 2012 16:17:22 -0400, as...@racket-lang.org wrote: 3582b57 Asumu Takikawa as...@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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
At Wed, 11 Jul 2012 01:33:02 -0400, Eli Barzilay wrote: Or maybe add a new tools collection for other similar things? I'm about to push the new version of Optimization Coach (formerly Performance Report). Since it now works with any language (not just TR), it would make sense to move it outside of the `typed-racket' collect. It would be a good candidate for the `tools' collection. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
(Performance) tuning? Vincent At Wed, 11 Jul 2012 10:04:46 -0500, Robby Findler wrote: tools seems like too generic of a word. Is there something like performance-debugging that isn't so long? Robby On Wed, Jul 11, 2012 at 9:58 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Wed, 11 Jul 2012 01:33:02 -0400, Eli Barzilay wrote: Or maybe add a new tools collection for other similar things? I'm about to push the new version of Optimization Coach (formerly Performance Report). Since it now works with any language (not just TR), it would make sense to move it outside of the `typed-racket' collect. It would be a good candidate for the `tools' collection. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Proposal for a no-argument
At Sun, 8 Jul 2012 08:40:41 -0400, Eli Barzilay wrote: Quick summary: I'll remove the #:before-first and #:after-last feature. If anyone wants them, please tell me -- maybe it can be left for the spliced case, or maybe they could always be spliced. +2 to always splicing. This gives us the additional features without needing the `#:nothing' argument. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
I would prefer the full word, performance. But with a name like that, I would expect things from `racket/unsafe/ops' and `racket/performance-hint' to be there. Tuning doesn't carry the same expectation (to me, at least). Vincent At Wed, 11 Jul 2012 10:39:53 -0500, Robby Findler wrote: Better than tools, IMO. How about perf? Ie, perf/future-visualizer and perf/optimization-coach/ ? Robby On Wed, Jul 11, 2012 at 10:10 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: (Performance) tuning? Vincent At Wed, 11 Jul 2012 10:04:46 -0500, Robby Findler wrote: tools seems like too generic of a word. Is there something like performance-debugging that isn't so long? Robby On Wed, Jul 11, 2012 at 9:58 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Wed, 11 Jul 2012 01:33:02 -0400, Eli Barzilay wrote: Or maybe add a new tools collection for other similar things? I'm about to push the new version of Optimization Coach (formerly Performance Report). Since it now works with any language (not just TR), it would make sense to move it outside of the `typed-racket' collect. It would be a good candidate for the `tools' collection. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24974: master branch updated
At Wed, 11 Jul 2012 09:37:19 -0700, Neil Toronto wrote: On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote: 84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26 : | Enable performance report no matter the language. : M collects/typed-racket/optimizer/tool/tool.rkt | 21 +++-- I can't tell from the overall diff. Does that also include student languages? Oops, good point. It does. I'll see how the Macro Stepper avoids that problem, and do the same. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
+1 Vincent At Wed, 11 Jul 2012 12:04:11 -0500, Robby Findler wrote: What about naming the collection tuning? Robby On Wed, Jul 11, 2012 at 11:34 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: I would prefer the full word, performance. But with a name like that, I would expect things from `racket/unsafe/ops' and `racket/performance-hint' to be there. Tuning doesn't carry the same expectation (to me, at least). Vincent At Wed, 11 Jul 2012 10:39:53 -0500, Robby Findler wrote: Better than tools, IMO. How about perf? Ie, perf/future-visualizer and perf/optimization-coach/ ? Robby On Wed, Jul 11, 2012 at 10:10 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: (Performance) tuning? Vincent At Wed, 11 Jul 2012 10:04:46 -0500, Robby Findler wrote: tools seems like too generic of a word. Is there something like performance-debugging that isn't so long? Robby On Wed, Jul 11, 2012 at 9:58 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Wed, 11 Jul 2012 01:33:02 -0400, Eli Barzilay wrote: Or maybe add a new tools collection for other similar things? I'm about to push the new version of Optimization Coach (formerly Performance Report). Since it now works with any language (not just TR), it would make sense to move it outside of the `typed-racket' collect. It would be a good candidate for the `tools' collection. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
Some tools have components that are required programmatically. E.g., the macro-debugger's useless requires detector or the graphical debugger API (which doesn't seem to be documented). Moving them may break code. But I do agree that a top-level `tool' collect would make sense. Vincent At Wed, 11 Jul 2012 21:25:04 -0400, Matthias Felleisen wrote: Is 'tool' plus flat subcollections really out? I am not really keen on 'tuning', plus I see a chance to thin out the collection top-level tree here. On Jul 11, 2012, at 8:26 PM, Robby Findler wrote: I like coaching for the (formerly known as) performance report tool. A lot! I was suggesting tuning for the collection that would house the future visualizer and the performance coach and hopefully eventually a memory profiler. (And maybe Eli's profiler could move in there someday too.) Robby On Wed, Jul 11, 2012 at 7:12 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jul 11, 2012, at 7:18 PM, Robby Findler wrote: Would tuning work? They were correct, and you conjectured correctly. We conflated 'optimization' with 'performance gains.' As everyone knows who has been around real compilers and their writers, some 'optimizations' are 'pessimizations' as Keith used to call them. And of course even when 'optimizations' reduce the running time and/or the space consumption, they aren't _optimizations_ as John Dennis used to remind us. There is a similar conflation that additional related work pointed out. People tend to confuse 'analysis results' with 'can do optimization'. This is certainly not true for in-lining in Racket and if you know of more those optimizations, I'd love to hear about them. 'Tuning' would work but we decided that 'coaching' was a good term for what was going on from the programmer's perspective. And the word isn't used anywhere else in CS as far as I know, while other terms (including 'tuning') are used and may have a different connotation. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24974: master branch updated
At Wed, 11 Jul 2012 18:00:26 -0500, Robby Findler wrote: On Wed, Jul 11, 2012 at 1:06 PM, Neil Toronto neil.toro...@gmail.com wrote: How about a tools drop-down? Or Online Optimization Coach (You can do it, Vincent!) I had that same thought, actually: online check syntax is actually factored into two parts. DrRacket provides an online expansion service and plugins you can register two handlers, one to run in the place where the expansion happened that is expected to produce a value to send back to the main place where the other handler gets it and can update the GUI. Probably Vincent has fairly little work to break that up; I'd guess the more substantial question will be how to reflect the information into the GUI in a way that doesn't fight with the check syntax information. Making the two tools combine nicely would take some thought. Currently, Optimization Coach is probably too slow to be used online, but I'm planning to work on that. Probably not before the release, though. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Insert Pict Box menu item not found in DrRacket
At Tue, 10 Jul 2012 09:13:24 -0500, Robby Findler wrote: Version 1.2 of cdrswift.plt seems to use the slideshow-insert-pict-box string constant, but it is up to version 1.5 now. http://planet.racket-lang.org/display.ss?package=cdrswift.pltowner=dignatof Probably best to just leave them in for now. Should we deprecate it and put it on a 1 year counter? (like `mzlib/class100') Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Insert Pict Box menu item not found in DrRacket
At Tue, 10 Jul 2012 11:23:04 -0500, Robby Findler wrote: I was thinking along similar lines. But maybe it would be helpful to do this for all of the unused string-constants in the tree? Good idea. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
At Tue, 10 Jul 2012 18:44:28 -0400, Neil Van Dyke wrote: I'm still using some mzlib in *new* code. Specifically, getpid, this-expression-source-directory, gethostname, and perhaps one or two other things. I could find other ways to do those things if I had to, but those definitions pop up when I search, and there's no glaring warning not to use them. Good point. We're looking through `mzlib''s bindings to find such functions that don't have equivalents elsewhere in the collects. We're planning to move these to appropriate libraries. For example, `gethostname' and `getpid' should probably go somewhere like `racket/os' (and probably be renamed to `get-hostname' and `get-pid'). Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Proposal for a no-argument
I really like this. Vincent At Sun, 1 Jul 2012 09:27:00 -0400, Eli Barzilay wrote: There rare cases where it is useful to have a value that means that no argument was passed to a function. In many of these cases there is a plain value that is used as that mark, with the most idiomatic one being #f, but sometimes others are used. IMO, while such uses of #f are idiomatic, they're a hack where an argument's domain is extended only to mark no argument. A more robust way to do that, which has become idiomatic in Racket is to use (gensym). (And as a sidenote, in other implementations there are various similar eq-based hacks.) IMO, this is an attempt to improve on the #f case by guaranteeing a unique value, but at its core it's still a similar hack. Recently, I have extended the `add-between' function in a way that ran against this problem at the interface level, where two keyword arguments default to such a gensymed value to detect when no argument is passed. Natually, this leaked into the documentation in the form of using `' to avoid specifying the default value and instead talking about what happens when no argument is given for the keywords in question. After a short discussion that I had with Matthew, the new version uses a new keyword that holds the unique no-value value, to simplify things: (define (foo x #:nothing [nothing (gensym)] [y nothing]) (printf y is ~s\n (if (eq? y nothing) 'omitted y))) The idea is that this does not depend on some specific unique value, since one can be given. For end-users of the function, there is no need to know about this. It's useful only for wrapper functions which want to mirror the same behavior, and call `foo' in a way that makes their own input passed to it, including not passing it when its own input is missing. In this case, you'd do something like this: (define (bar #:nothing [nothing (gensym)] [x nothing]) (foo 10 x #:nothing nothing)) This works, but I dislike this solution for several reasons: 1. Instead of finding a solution for the `gensym' problem, this approach embraces it as the proper way to do such things. 2. But more than that, it also exposes it in the interface of such functions, which means that simple end users need to read about it too. There is no easy way to somehow say you souldn't worry about this unless you're writing a function that ..., and if you look at the current docs for `add-between' you'd probably wonder when that #:nothing is useful. 3. There is also a half-story in this documentation -- even though the docs look like the above function definition, you obviously would want to define a single global gensymmed value and use it, to avoid redundant allocation. By the way the docs read, the above does look like the way to do these things, and I can see how a quick reading would make people believe that it's fine to write: (define (foo) (define (bar [x (gensym)]) ...) ... call bar many times ...) I considered a bunch of alternatives to this, and the one closest to looking reasonable is to use the #undefined value: it makes some sense because it is a value that is already used in some no value cases. However, it is probably a bad idea to use it for something different. In fact, that's how many languages end up with false, null, undefined, etc etc. (As a side note, a different approach would be to use a per-argument boolean flag that specifies if the corresponding argument. Since this started with a documentation point of view, I'm assuming that it won't be a good solution since it doesn't solve that problem -- a function that uses it similarly to `add-between' would still need to avoid specifying the default.) Instead, I suggest using a new special value, one that is used only for this purpose. The big difference from all of these special values is that I'm proposing a value that is used only for this. To discourage using it for other reasons, there would be no binding for it. Instead, there would be a fake one, say `no-argument', which is used only as a syntax in a default expression and only there the real no-argument gets used -- so the value is actually hidden and `no-argument' is a syntactic marker that is otherwise an error to use, like `else' and `='. (I'm no even suggesting making it a syntax parameter that has a value in default expressions, because you shouldn't be able to write (λ ([x (list no-argument)]) ...).) The only real binding that gets added is something that identifies that value, or even more convenient, something like `given?' that checks whether its input is *not* that value. To demonstrate how this looks like, assume that the kernel has only a three-argument `kernel-hash-ref', and you want to implement `hash-ref' on top of it without using a thunk (which avoid the problem in a different way). The
Re: [racket-dev] Sublinear functions of superfloat numbers
At Sun, 1 Jul 2012 20:10:30 -0400, Matthias Felleisen wrote: I had misunderstood. I thought you had suggested 'reduction of strength' (say going from square to * or double to +), which is a generally useful compiler optimization. What you suggest is some form of conditional version of this. Argument reduction extends the domain of functions to work on arguments that they can't handle directly (e.g. because they're too big to be represented as floats). It's not an optimization. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
At Fri, 15 Jun 2012 15:12:05 -0400, Asumu Takikawa wrote: * for consistency with the rest of the language, `stx-car` and friends would be renamed to use the `syntax-` prefix instead of `stx-`. +1 I always get these names wrong. * the name of the library is also consistent with the rest of the language. +1 Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
