Re: [racket-dev] Release process for split repos
I like the general idea. I especially like that you've included instructions for repo managers like me who will likely forget everything about git branch management and cherry picking between releases. In the past, you've played the part of central reviewer for requests to merge to the release branch. Are we going to try for the same kind of consistency now, or leave it up to repo managers? Neil ⊥ On 01/23/2015 03:31 PM, 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] [plt] Push #29680: master branch updated
On 01/13/2015 02:00 PM, mfl...@racket-lang.org wrote:
9f3c82c Matthew Flatt 2015-01-13 08:47
:
| Windows: change `delete-{file,directory}` to attempt permission correction
|
| If a file or directory delete fails, try adjusting the file or directory
| permissions to allow writes, then try deleting again. This process should
| provide a more Unix-like experience and make programs behave more
| consistently.
|
| A new `current-force-delete-permissions` parameter provides access to
| the raw native behavior.
If I'm understand the new behavior correctly, it's possible for a
failing `delete-file` to raise an exception, having changed the file to
be writable. Do I have that right, and is that OK?
Neil ⊥
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.1.1
On 10/27/2014 12:25 PM, Ryan Culpepper wrote: neil: - remove dependence on libgtkgl (c601b82f) * For OpenGL on Linux, removed dependence on libgtkgl and added support for core profiles (see `set-legacy?`). Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1.1, Second Call
On 10/23/2014 12:48 PM, Ryan Culpepper wrote: * Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests All pass. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29355: master branch updated
Does this mean most instances of GUI classes can now cross the contract boundary? Neil ⊥ On 10/09/2014 05:37 PM, as...@racket-lang.org wrote: asumu has updated `master' from 38af459049 to 863f0c5802. http://git.racket-lang.org/plt/38af459049..863f0c5802 =[ One Commit ]= Directory summary: 5.7% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/static-contracts/combinators/ 51.3% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/utils/ 6.7% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/ 36.1% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/ ~~ 863f0c5 Asumu Takikawa 2014-10-08 01:04 : | Add contract generation for Evtof types : A pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/utils/evt-contract.rkt M .../static-contracts/combinators/structural.rkt | 6 ++-- M .../typed-racket/private/type-contract.rkt| 2 ++ M .../typed-racket/typed-racket.rkt | 4 ++- M .../typed-racket/unit-tests/contract-tests.rkt| 29 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Should `register-finalizer` unwrap impersonators?
That would be really nice for data structures defined in TR and used in untyped Racket, for which the contract boundary imposes O(n) overhead for everything. Also, it sounds dangerous. :D It wouldn't solve the problem entirely, though. Here's an untyped program that has it: #lang racket (module resource racket (require (only-in ffi/unsafe register-finalizer)) (provide (contract-out [connect-os-resource (-> (struct/c os-resource-wrapper real?) void?)]) get-os-resource (struct-out os-resource-wrapper)) (struct os-resource-wrapper (x) #:mutable) (define os-resource 0) (define (get-os-resource) os-resource) (define (connect-os-resource w) (set! os-resource (add1 os-resource)) (printf "impersonator? ~v chaperone? ~v~n" (impersonator? w) (chaperone? w)) (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource)) (require (submod "." resource)) (define w (os-resource-wrapper 1)) (connect-os-resource w) (printf "os-resource = ~v~n" (get-os-resource)) (collect-garbage) (sleep 1) ; give finalizers a chance to run (printf "os-resource = ~v~n" (get-os-resource)) This was actually hard to come up with. We usually use flat contracts like `os-resource-wrapper?`, and count on struct contracts at the boundary to ensure that `os-resource-wrapper?` implies (struct/c os-resource-wrapper real?) for any value coming in. When I did that, there was no way to provoke the error: `connect-os-resource` registered a finalizer on an unwrapped value, or on a wrapped value *for which the external module didn't have access to the original*. The above program still exhibits the wrong-value-finalizer problem if the struct is provided with a contract. It probably gets wrapped twice in that case: once when created in the external module, and once on the way into `connect-os-resource`. So I think our contracting habits make the problem rare, but it's still possible with just the contract system. I'm going to submit a bug report. Neil ⊥ On 08/17/2014 05:19 PM, Matthias Felleisen wrote: I imagine a type-definition construct that allows programmers to specify how the type is translated into a contract. Think (define-trusted-type Finalizer C) and then the C specifies how little and how much of the type you wish to check. And yes, this is potentially a soundness hole but I am thinking that the primary uses could be connected to things in the core or the FFI. And programmers who wish to reduce the soundness of TR could use it to speed up boundary crossings at the cost of getting things wrong. In a sense, it's an FFI for types. -- Matthias On Aug 17, 2014, at 3:47 PM, Sam Tobin-Hochstadt wrote: Can you say more about what the API for what you're imagining is? Sam On Sun, Aug 17, 2014 at 3:41 PM, Matthias Felleisen wrote: I am imagining that the type compilation of type Finalizer and such things would be parameterized over programmer code which would yield a 'trusted' 'thing' in this case except that this would open the door for other such things. On Aug 17, 2014, at 3:39 PM, Sam Tobin-Hochstadt wrote: How would that change things here? The issue is about finalizer-for-what, and that chaperones/impersonators affect object identity. Sam On Sun, Aug 17, 2014 at 3:37 PM, Matthias Felleisen wrote: Could we benefit from an abstract/opaque Finalizer type here? I know we don't have those yet but it may address the general problem. -- Matthias On Aug 16, 2014, at 8:55 AM, Neil Toronto wrote: Short version: the contract system doesn't allow `register-finalizer` to be used in Typed Racket. Long version: consider the following Typed Racket program, in which instances of `os-resource-wrapper` represent an operating system resource `os-resource`, which itself is just a counter. It attempts to register a finalizer for allocated wrappers, which decrements the counter. #lang typed/racket (require/typed ffi/unsafe [register-finalizer (All (A) (-> A (-> A Any) Void))]) (: os-resource Integer) (define os-resource 0) (struct os-resource-wrapper ()) (: alloc-os-resource (-> os-resource-wrapper)) (define (alloc-os-resource) (set! os-resource (add1 os-resource)) (define w (os-resource-wrapper)) (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource w) (define w (alloc-os-resource)) (printf "os-resource = ~v~n" os-resource) (collect-garbage) (sleep 1) ; give finalizers a chance to run (printf "os-resource = ~v~n" os-resource) I get this output: os-resource = 1 os-resource = 0 The finalizer is being run while the program still has a pointer to the wrapper object. I think it's because the wrapper object is being impersonated when it's sent across the contract barrier, and the *impersonator* is getting the fin
Re: [racket-dev] Should `register-finalizer` unwrap impersonators?
That's what I think. The more contracted our values get in Racket programs, the less we can trust `register-finalizer` if it doesn't change. Currently, `register-finalizer` tends to be used right after allocation, when objects don't usually have contracts yet. It doesn't have to be, though. Neil ⊥ On 08/16/2014 10:46 AM, Sam Tobin-Hochstadt wrote: That's clearly the right solution for this particular bug, but it does seem like there's a more general problem here. Sam On Sat, Aug 16, 2014 at 10:40 AM, Robby Findler wrote: Seems simplest to be to have typed racket know to trust register finalizer and thus avoid wrapping it with a contract. Robby On Saturday, August 16, 2014, Neil Toronto wrote: Short version: the contract system doesn't allow `register-finalizer` to be used in Typed Racket. Long version: consider the following Typed Racket program, in which instances of `os-resource-wrapper` represent an operating system resource `os-resource`, which itself is just a counter. It attempts to register a finalizer for allocated wrappers, which decrements the counter. #lang typed/racket (require/typed ffi/unsafe [register-finalizer (All (A) (-> A (-> A Any) Void))]) (: os-resource Integer) (define os-resource 0) (struct os-resource-wrapper ()) (: alloc-os-resource (-> os-resource-wrapper)) (define (alloc-os-resource) (set! os-resource (add1 os-resource)) (define w (os-resource-wrapper)) (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource w) (define w (alloc-os-resource)) (printf "os-resource = ~v~n" os-resource) (collect-garbage) (sleep 1) ; give finalizers a chance to run (printf "os-resource = ~v~n" os-resource) I get this output: os-resource = 1 os-resource = 0 The finalizer is being run while the program still has a pointer to the wrapper object. I think it's because the wrapper object is being impersonated when it's sent across the contract barrier, and the *impersonator* is getting the finalizer. (Or it's a chaperone, or an impostor, or a charlatan, or whatever. Let's go with impersonator.) In my specific case, the OS resources are OpenGL objects; e.g. vertex object arrays. The call to `register-finalizer` *must* be in Typed Racket code because the wrapper contains an (Instance GL-Context<%>), which can't have a contract put on it, so it can't pass from untyped to typed code. Is there any reason for `register-finalizer` to behave this way? Does it ever make sense to register a finalizer on an impersonator? 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
[racket-dev] Should `register-finalizer` unwrap impersonators?
Short version: the contract system doesn't allow `register-finalizer` to be used in Typed Racket. Long version: consider the following Typed Racket program, in which instances of `os-resource-wrapper` represent an operating system resource `os-resource`, which itself is just a counter. It attempts to register a finalizer for allocated wrappers, which decrements the counter. #lang typed/racket (require/typed ffi/unsafe [register-finalizer (All (A) (-> A (-> A Any) Void))]) (: os-resource Integer) (define os-resource 0) (struct os-resource-wrapper ()) (: alloc-os-resource (-> os-resource-wrapper)) (define (alloc-os-resource) (set! os-resource (add1 os-resource)) (define w (os-resource-wrapper)) (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource w) (define w (alloc-os-resource)) (printf "os-resource = ~v~n" os-resource) (collect-garbage) (sleep 1) ; give finalizers a chance to run (printf "os-resource = ~v~n" os-resource) I get this output: os-resource = 1 os-resource = 0 The finalizer is being run while the program still has a pointer to the wrapper object. I think it's because the wrapper object is being impersonated when it's sent across the contract barrier, and the *impersonator* is getting the finalizer. (Or it's a chaperone, or an impostor, or a charlatan, or whatever. Let's go with impersonator.) In my specific case, the OS resources are OpenGL objects; e.g. vertex object arrays. The call to `register-finalizer` *must* be in Typed Racket code because the wrapper contains an (Instance GL-Context<%>), which can't have a contract put on it, so it can't pass from untyped to typed code. Is there any reason for `register-finalizer` to behave this way? Does it ever make sense to register a finalizer on an impersonator? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1
I've pushed a change that makes it work even with the Firefox layout issue and requested it be merged to 6.1. We can change my status to "All tests pass" now. Neil On 07/23/2014 08:23 AM, Sam Tobin-Hochstadt wrote: The margin-notes appear to work correctly on Chrome but wrong on Firefox on my Linux system. Sam On Wed, Jul 23, 2014 at 8:13 AM, Robby Findler wrote: Believe it or not I actually tried that. Screenshot: http://www.eecs.northwestern.edu/~robby/tmp/x.png (that's Chome and Safari). Robby On Wed, Jul 23, 2014 at 7:02 AM, Neil Toronto wrote: They only do it on my system if the browser window is too narrow. And "overlap" is the wrong word: the margin notes are completely inside the blue boxes. BTW, #2 is fixed now. I added an "#:unscaled? #t" somewhere; Matthew did the actual work. :D Neil On 07/22/2014 07:20 PM, Robby Findler wrote: FWIW, I don't see the overlap in Chrome (on a mac) or in Safari. Robby On Tue, Jul 22, 2014 at 2:01 PM, Neil Toronto wrote: On 07/17/2014 08:03 PM, Ryan Culpepper wrote: * Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests All tests pass, but two things need fixing: some margin notes in the math documentation, and `compiled-bitmap` and `compiled-bitmap-list` when they embed compressed bitmaps. 1. There's an issue with margin notes overlapping blue boxes in some of the math documentation. I haven't looked into it deeply yet, so I'm not sure what causes it or what should be done to fix it. You can see it in the pre-release docs here: http://pre-release.racket-lang.org/doc/math/matrix_basic.html 2. The `compiled-bitmap` and `compiled-bitmap-list` macros yield bitmaps that are the right size but with a half-size image tucked into the upper-left corner, when the bitmaps are stored in the module as JPEGs. (This doesn't affect DrRacket's icons because they're all stored as PNGs.) I suspect there's a missing "#:unscaled? #t" or two. 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] Pre-Release Checklist for v6.1
They only do it on my system if the browser window is too narrow. And "overlap" is the wrong word: the margin notes are completely inside the blue boxes. BTW, #2 is fixed now. I added an "#:unscaled? #t" somewhere; Matthew did the actual work. :D Neil On 07/22/2014 07:20 PM, Robby Findler wrote: FWIW, I don't see the overlap in Chrome (on a mac) or in Safari. Robby On Tue, Jul 22, 2014 at 2:01 PM, Neil Toronto wrote: On 07/17/2014 08:03 PM, Ryan Culpepper wrote: * Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests All tests pass, but two things need fixing: some margin notes in the math documentation, and `compiled-bitmap` and `compiled-bitmap-list` when they embed compressed bitmaps. 1. There's an issue with margin notes overlapping blue boxes in some of the math documentation. I haven't looked into it deeply yet, so I'm not sure what causes it or what should be done to fix it. You can see it in the pre-release docs here: http://pre-release.racket-lang.org/doc/math/matrix_basic.html 2. The `compiled-bitmap` and `compiled-bitmap-list` macros yield bitmaps that are the right size but with a half-size image tucked into the upper-left corner, when the bitmaps are stored in the module as JPEGs. (This doesn't affect DrRacket's icons because they're all stored as PNGs.) I suspect there's a missing "#:unscaled? #t" or two. Neil ⊥ _ 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 v6.1
On 07/17/2014 08:03 PM, Ryan Culpepper wrote: * Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests All tests pass, but two things need fixing: some margin notes in the math documentation, and `compiled-bitmap` and `compiled-bitmap-list` when they embed compressed bitmaps. 1. There's an issue with margin notes overlapping blue boxes in some of the math documentation. I haven't looked into it deeply yet, so I'm not sure what causes it or what should be done to fix it. You can see it in the pre-release docs here: http://pre-release.racket-lang.org/doc/math/matrix_basic.html 2. The `compiled-bitmap` and `compiled-bitmap-list` macros yield bitmaps that are the right size but with a half-size image tucked into the upper-left corner, when the bitmaps are stored in the module as JPEGs. (This doesn't affect DrRacket's icons because they're all stored as PNGs.) I suspect there's a missing "#:unscaled? #t" or two. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
On 06/09/2014 10:25 AM, Neil Toronto wrote: On 06/09/2014 01:19 AM, Eric Dobson wrote: Does this seem like a reasonable thing to support/do people see issues with it? I can only speak on reasonableness, and my answer is emphatically YES. Typed Racket is a great language in which to define and use data structures: access is very fast, and many properties are checked statically. But accessor performance suffers badly when the data types are used in untyped Racket. If access uses higher-order functions (e.g. math/array), wrapping the functions slows access by a very high constant factor. If the data structures are first-order, every O(1) access becomes O(n). I recently had to work around this in Plot when I needed an untyped module to be able to operate on typed BSP trees. I ended up making a typed weak hash map from "BSP tree handles" (gensyms) to BSP trees, and writing a new untyped API for operating on trees using handles. It was ugly. If the untyped and typed modules had been too tightly coupled, it would have been impossible. IIUC, your proposal would make untyped use of typed data structures actually feasible for real-world use. So again, YES. Here's a concrete example, using Typed Racket to define a new list type. #lang racket (module typed-defs typed/racket (provide list->my-list my-first) (define-type (My-Listof A) (U Null (my-cons A))) (struct (A) my-cons ([fst : A] [snd : (My-Listof A)]) #:transparent) (: list->my-list (All (A) (-> (Listof A) (My-Listof A (define (list->my-list xs) (if (empty? xs) xs (my-cons (first xs) (list->my-list (rest xs) (: my-first (All (A) (-> (My-Listof A) A))) (define (my-first xs) (if (empty? xs) (error 'bad) (my-cons-fst xs))) ;; Timing loop speed is very fast and O(1) (define lst (list->my-list '(1))) (for ([_ (in-range 5)]) (time (for ([_ (in-range 100)]) (my-first lst ) (require 'typed-defs) ;; Timing loop speed is very slow and O(n) (define lst (list->my-list '(1))) (for ([_ (in-range 5)]) (time (for ([_ (in-range 100)]) (my-first lst I get 4ms for the timing loop in the typed module, and 620ms for the timing loop in the untyped module, so the constant factor is about 150. When I change the test data from '(1) to '(1 2), the untyped module's timing loop takes about 1010ms. The contract boundary has changed the asymptotic complexity of `my-first' from O(1) to O(n). Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
On 06/09/2014 01:19 AM, Eric Dobson wrote: Does this seem like a reasonable thing to support/do people see issues with it? I can only speak on reasonableness, and my answer is emphatically YES. Typed Racket is a great language in which to define and use data structures: access is very fast, and many properties are checked statically. But accessor performance suffers badly when the data types are used in untyped Racket. If access uses higher-order functions (e.g. math/array), wrapping the functions slows access by a very high constant factor. If the data structures are first-order, every O(1) access becomes O(n). I recently had to work around this in Plot when I needed an untyped module to be able to operate on typed BSP trees. I ended up making a typed weak hash map from "BSP tree handles" (gensyms) to BSP trees, and writing a new untyped API for operating on trees using handles. It was ugly. If the untyped and typed modules had been too tightly coupled, it would have been impossible. IIUC, your proposal would make untyped use of typed data structures actually feasible for real-world use. So again, YES. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28799: master branch updated
On 05/26/2014 09:21 AM, endob...@racket-lang.org wrote: 9efa4af Eric Dobson 2014-05-16 08:13 : | Make initial version of structural type recursion, and use it. : A pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/types/structural.rkt M .../typed-racket/infer/promote-demote.rkt | 66 +++- M .../typed-racket/rep/type-rep.rkt | 8 ++- I'm trying to figure out how excited I should be about this. Can you explain it a little? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Easy disassembly of JIT-compiled procedures
On 05/21/2014 02:09 PM, Sam Tobin-Hochstadt wrote: Racketeers, Thanks to some improvements from Matthew, my `disassemble` package is now much easier to use. [samth@punge:~/sw/disassemble (master) plt] racket Welcome to Racket v6.0.1.10. (require disassemble) (define (const x) 1) (disassemble const) 8943FCmov [ebx-0x4],eax 0003 83C3FCadd ebx,byte -0x4 0006 B80300mov eax,0x3 000B 83C41Cadd esp,byte +0x1c 000E 5Fpop edi 000F 5Epop esi 0010 5Bpop ebx 0011 5Dpop ebp 0012 C3ret That's crazy awesome. What were the improvements? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] "lab notebook on learning process"
On 05/06/2014 12:18 PM, Matthias Felleisen wrote: On May 6, 2014, at 2:02 PM, Jens Axel Søgaard wrote: How about an extra button, a "Run Benchmark" button? +ω I LOLed. Were you thinking of having it launch a front-end to Josh McGrath's benchmarking library? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28684: master branch updated
On 05/06/2014 12:17 PM, sa...@racket-lang.org wrote: samth has updated `master' from ad8d0629f8 to 6567ebff59. http://git.racket-lang.org/plt/ad8d0629f8..6567ebff59 =[ 6 Commits ]== Directory summary: 70.7% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/ 8.3% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/rep/ 4.6% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/ 3.2% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/utils/ 3.3% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/ 7.3% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/ ~~ f83950f Sam Tobin-Hochstadt 2014-05-05 21:30 : | Refactor type inference to eliminate exceptions. | | This provides approximately 6% speedup on | `racket -l math/scribblings/math.scrbl` and about | 14% speedup on the `new-metrics` test. | | Mostly this involves threading #f through the whole | of the inference process. There are several new | macros in `typed-racket/infer/fail` which are useful | for comprehensively using Maybe-monad style | programming in Racket. Of particular note is `%`, | which satisfies (% f e ...) => (and e ... (f e ...)) | but with the obvious fixes. | | This commit also weakens several contracts which | caused the build of DrRacket and/or `math` to fail | when contracts were enabled. This is great. Two questions. Why is the math *documentation* a good test for the new monadic-style encoding of inference algorithms? (Because it tries to evaluate expressions that fail to type?) Also, does the last paragraph refer to using contracts within TR programs, or to using contracts within the implementation of TR? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.0.1
On 05/01/2014 11:49 AM, Ryan Culpepper wrote: The release announcement sketch that I have so far is below. Please mail me new items and/or edits. -- neil: - plot 3D BSP tree (a515e7ce) - PDF/PS scaling changed to 1.0x1.0 (efc46ded) - Plot correctly renders intersecting 3D graphs and non-grid-aligned 3D rectangles. - Elements in plots output in PDF/PS format have the same relative scale as in other formats. In particular, it is not necessary to adjust `plot-font-size` to make PDF plots look the same as PNG. Neil _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0.1, Second Call
On 04/24/2014 12:58 PM, Ryan Culpepper wrote: * Neil Toronto Everything passes. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] TR optimizations and Racket overhead [was Re: [plt] Push #28633: master branch updated]
On 04/28/2014 04:46 AM, Sam Tobin-Hochstadt wrote: On Apr 28, 2014 12:16 AM, "Neil Toronto" mailto:neil.toro...@gmail.com>> wrote: > > For anyone wondering what this stuff means: most mixed exact/inexact math in Racket should be up to 5x or so faster now, depending on how conversion-heavy it is and how large the numbers are. On my machine, `real->double-flonum` is 1x or 25x faster on exact rationals (1x if the numerator and denominator both fit in a flonum; we optimized the slow path), and `inexact->exact` is 4x-100x faster (depending on the magnitude of the flonum's exponent). Also, conversions from exact to inexact now always find the closest approximation, so e.g. `sqrt` is a little more accurate when given exact rationals. Sounds great. > FWIW, the C implementations aren't much faster than the Typed Racket prototypes. I find that totally awesome. Impressive! Can you share the prototype? Attached. Also, what ends up slower? What would we have to fix to make them the same speed? After looking into it more, I've found that TR's optimizer isn't helping much, probably because big integer operations account for most of the cost. Its largest effect seems to be reducing constant overhead in the timing loops - which at least makes my analysis more accurate. :) IOW, I think the prototypes are fast mostly because Racket is fast. There's probably not a lot more you can do to speed them up. More details, as measured on my machine: For rational-to-flonum conversions, the TR implementation is about 13% slower than C. It uses a different method to determine whether it can use the fast algorithm (i.e. divide two flonums), which requires an extra conversion back to big integers, and this apparently accounts for about 3% of the extra cost. Otherwise, it uses exactly the same algorithm - it even mutates variables like in the C code. It's harder to analyze flonum-to-rational conversions, because the TR implementation has to use `real->floating-point-bytes` and `integer-bytes->integer`, but the C code can get the flonum's bits using a cast. When I fix the input to get rid of this variable, the TR implementation is 2% slower on numbers with negative exponents, and 10% *faster* on numbers with positive exponents. I suspect that when it's faster, it's because the C code is checking more cases, because the test compares `inexact->exact` with `flonum->rational`. In all, in these two programs, I think Racket overhead accounts for up to 10% of running time for TR-optimized code. I think you might be interested to see how TR's optimizer does with code that does a ridiculous amount of non-homogenous floating point. The robust geometric primitives I'm working on are a perfect test case: I use only one data structure besides short flvectors and flonums (a plane, which contains one of each), and most computations are dense sequences of flonum arithmetic that doesn't just map one operation over a vector. 1 million applications on typical domain, in ms Function #:no-optimize opt'd frac - flv3mag^2 153 97 63% flv3mag273192 70% flv3dot185112 61% flv3cross 386273 71% flv3normalize 830571 69% flv3dist^2 190132 69% flv3dist 311220 71% flv3polygon-perp 1542 1136 74% flv3polygon-normal2370 1710 72% flv3polygon-centroid 805550 68% flplane3-point-dist334236 71% flplane3-line-isect-time 1102955 87% flplane3-line-isect (seg) 747533 71% flplane3-line-isect (no-seg) 1502 1079 72% So I can get about 9.8 million robust dot products per second out of TR, and 5.4 million out of Racket. These functions return results with <= 0.5ulp error by using double-double representation (i.e. using two flonums per number in intermediate results). This makes them about 5x slower than straightforward implementations. I could probably get 45 million dirty dot products per second out of TR and 27 million out of Racket. From these two cases (flonum/rational conversion and geometric primitives) and other math-y things I've done in TR and Racket, I conclude that 1. When dealing with platform data types like flonums and small integers, it's not too hard to write TR code that's close to C in performance. 2. When dealing with non-platform data types like big integers and exact rationals, even unoptimized Racket is close to C in performance. I can't help but wonder how many of Racket's numeric primitives we could move into TR, and what it
Re: [racket-dev] [plt] Push #28633: master branch updated
On 04/27/2014 09:16 PM, Matthew Flatt wrote: At Sun, 27 Apr 2014 18:56:32 -0600, Neil Toronto wrote: Strange thing, though: while `inexact->exact` is now about 10x faster, my TR implementation `flonum->rational` is now about 7x slower. I've verified that `flonum->fields` accounts for about 85% of the running time. I see that you've changed `integer-bytes->integer`, which `flonum->fields` uses. Could it have been a pessimization on certain platforms? That's surprising. I don't expect the modified `integer-bytes->integer` to be any slower. Are you timing with the "flonum-to-racket.rkt" that you sent me? When I run it on various machines (Mac 32-bit x86, Mac 64-bit x86, Mac 32-bit PPC, Linux 64-bit x86, Windows 64-bit x86 VM), the time reported for your code is not slower than before, and it's consistently within 50% of the time reported for the new `inexact->exact`. I was being stupid. The file I sent you, which I did the majority of my testing with, does 100,000 conversions in the speed test. At some point, I changed it to 1,000,000. When I use 100,000 again, the TR implementation `flonum->rational` actually takes 50% less time than it used to. So thanks again, and sorry about making you test more! For anyone wondering what this stuff means: most mixed exact/inexact math in Racket should be up to 5x or so faster now, depending on how conversion-heavy it is and how large the numbers are. On my machine, `real->double-flonum` is 1x or 25x faster on exact rationals (1x if the numerator and denominator both fit in a flonum; we optimized the slow path), and `inexact->exact` is 4x-100x faster (depending on the magnitude of the flonum's exponent). Also, conversions from exact to inexact now always find the closest approximation, so e.g. `sqrt` is a little more accurate when given exact rationals. FWIW, the C implementations aren't much faster than the Typed Racket prototypes. I find that totally awesome. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28633: master branch updated
On 04/27/2014 05:14 PM, mfl...@racket-lang.org wrote: ~~ d682c94 Matthew Flatt 2014-04-27 13:58 : | repairs to precision of `exact->inexact` et al. | | Thanks to Neil T.! : M racket/src/racket/src/numarith.c | 28 ++-- M racket/src/racket/src/ratfloat.inc| 74 +++- M racket/src/racket/src/rational.c | 11 +++ M racket/src/racket/src/schpriv.h | 2 + M .../racket-test/tests/racket/number.rktl | 53 ++ ~~ 04c4538 Matthew Flatt 2014-04-27 15:17 : | speed up `inexact->exact` | | Parse IEEE floating-point numbers directly. | | Thanks to Neil T.! : M racket/src/racket/sconfig.h | 3 + M racket/src/racket/src/numstr.c| 177 --- M racket/src/racket/src/ratfloat.inc| 73 +++- M racket/src/racket/src/rational.c | 18 +- M racket/src/racket/src/schpriv.h | 2 + M .../racket-test/tests/racket/number.rktl | 33 +++- Thanks for translating these into C so quickly! My plane-line intersection test cases run about twice as fast now, and because `exact->inexact` is correctly rounded, I can set the error reporting threshold to 0.5 ulps. Strange thing, though: while `inexact->exact` is now about 10x faster, my TR implementation `flonum->rational` is now about 7x slower. I've verified that `flonum->fields` accounts for about 85% of the running time. I see that you've changed `integer-bytes->integer`, which `flonum->fields` uses. Could it have been a pessimization on certain platforms? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0.1
I found out that it happens when a polygon is just three collinear or nearly collinear points, and the polygon's "plane," which is degenerate, is somehow the best choice for a BSP split. I still haven't gotten the upcoming release's Plot to generate a collection of shapes that causes nontermination. I'll just push the fix I used in my dev branch, which detects degenerate planes and calls the failure continuation to try the next plane. The BSP tree build should have been sanitizing its inputs like that anyway. Doug, have you seen nontermination in your tests? Neil ⊥ On 04/18/2014 02:54 PM, Robby Findler wrote: That sounds like a good plan to me. Let us know what you find out. Robby On Fri, Apr 18, 2014 at 3:47 PM, Neil Toronto wrote: On 04/17/2014 04:44 PM, Ryan Culpepper wrote: * Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests I found an infinite loop in Plot's new 3D engine, but I've only been able to replicate it using a randomized test case for a feature I haven't pushed yet. Even though that feature won't be in the upcoming release, there's definitely an error in the 3D engine that I don't want users stumbling into. If the Powers That Be don't mind, I'll concentrate on finding a repeatable test case, and check the rest of my list at the second call. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28607: master branch updated
On 04/24/2014 10:20 AM, ntoro...@racket-lang.org wrote: ntoronto has updated `master' from d30546cb7d to bee344f41d. : | Fix Plot for new undefined behavior: # is not a truth value | | This is a nice example of why having # as a language value is | generally a bad idea. Because in Scheme/Racket, everything that isn't | `refresh?` argument entirely - it was as if its value was always #t. Any | GUI change that was not meant to cause a refresh caused one anyway: a | silent performance error. [...] (define/public (set-message msg #:refresh? [refresh? #t]) - (define refresh? (and refresh? (not (equal? msg message - (set! message msg) - (reset-message-timeout) - (when refresh? (refresh))) + (let ([refresh? (and refresh? (not (equal? msg message)))]) +(set! message msg) +(reset-message-timeout) +(when refresh? (refresh Somehow my log message got mangled. I'll show you that I can words! The idea of the line (define refresh? (and refresh? (not (equal? msg message is to optimize the case in which the message doesn't change, by not refreshing. But the RHS was always #, which, as a truth value, is equivalent to #t. So the optimization was actually a pessimization: it effectively always made the incoming `refresh?` #t. Feel free to use this as an example in papers. I would never have caught it without the new undefined semantics. Thanks to Laurent for getting hit with it first. :) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28599: master branch updated
Holy cow, Vincent, thanks! Neil ⊥ On 04/23/2014 10:45 AM, stamo...@racket-lang.org wrote: stamourv has updated `master' from e230456fd7 to 4d36910026. http://git.racket-lang.org/plt/e230456fd7..4d36910026 =[ 10 Commits ]= Directory summary: 41.1% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/ 54.7% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/ 4.0% pkgs/typed-racket-pkgs/ ~~ 171d874 Vincent St-Amour 2014-04-22 18:09 : | Basic optimizations for extflonums. : A pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/extflonum.rkt M .../typed-racket-lib/typed-racket/optimizer/float.rkt| 2 +- M .../typed-racket-lib/typed-racket/optimizer/optimizer.rkt| 7 --- ~~ 2286872 Vincent St-Amour 2014-04-23 11:02 : | Add missing forms to TR docs. : M .../typed-racket/scribblings/reference/special-forms.scrbl | 4 +++- ~~ 0a8b384 Vincent St-Amour 2014-04-23 11:51 : | More extflonum optimizations. : M .../typed-racket/optimizer/extflonum.rkt | 15 ++- ~~ b967761 Vincent St-Amour 2014-04-23 12:02 : | Tests for extflonum optimizations. : A pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/extflonums.rkt ~~ e5e5a45 Vincent St-Amour 2014-04-23 12:03 : | Export the ExtFlVector type. : M .../typed-racket-lib/typed-racket/base-env/base-types.rkt| 1 + ~~ e41e91f Vincent St-Amour 2014-04-23 12:04 : | Add extflvector optimizations. : M .../typed-racket/optimizer/tests/bounds-check.rkt | 37 +++- M .../typed-racket/optimizer/vector.rkt | 27 +- ~~ 47abc2f Vincent St-Amour 2014-04-23 12:08 : | Fix extflonum tests for line numbers. : M .../typed-racket/optimizer/tests/extflonums.rkt | 61 ++-- ~~ e8e007b Vincent St-Amour 2014-04-23 12:14 : | Typo. : M .../typed-racket-lib/typed-racket/optimizer/float.rkt| 2 +- ~~ 2adc374 Vincent St-Amour 2014-04-23 12:22 : | Be more conservative when reporing potentially exact arithmetic. : M .../typed-racket-lib/typed-racket/optimizer/float.rkt | 1 + M .../typed-racket/optimizer/tests/dead-inf-comp.rkt| 16 ~~ 4d36910 Vincent St-Amour 2014-04-23 12:38 : | Optimize expt on floats. : M .../tests/typed-racket/optimizer/tests/exact-inexact.rkt | 4 M .../tests/typed-racket/optimizer/tests/expt.rkt| 11 ++- M .../typed-racket-lib/typed-racket/optimizer/float.rkt | 2 +- M .../typed-racket/optimizer/missed-optimizations/fixnum.rkt | 2 ++ [...] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Can a TR wizard check my extflonum changes? [was [plt] Push #28592: master branch updated]
On 04/22/2014 11:50 AM, Sam Tobin-Hochstadt wrote: On Tue, Apr 22, 2014 at 1:06 PM, Neil Toronto wrote: The changes mostly mimic the types and test cases for flonums and flvectors, but with adjustments to leave extflonums out of the numeric tower. Everything passes and extflonum expressions seem to type correctly, but I can't be sure I didn't miss anything. Can a more TR-internals-savvy person give the changes a quick once-over? I'll have a look at this. In general we (the TR developers) prefer to review significant changes to TR beforehand, via GitHub pull requests. So that would be a good thing to do in the future. Noted, and I apologize for stepping out of bounds. Thanks for looking over it anyway. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Can a TR wizard check my extflonum changes? [was [plt] Push #28592: master branch updated]
On 04/22/2014 10:48 AM, ntoro...@racket-lang.org wrote: ntoronto has updated `master' from 67805b9f04 to 14bbd662e9. http://git.racket-lang.org/plt/67805b9f04..14bbd662e9 ~~ 85deab7 Neil Toronto 2014-04-22 10:45 : | Added ExtFlonum (and subtypes) and ExtFlVector to the base type environment The changes mostly mimic the types and test cases for flonums and flvectors, but with adjustments to leave extflonums out of the numeric tower. Everything passes and extflonum expressions seem to type correctly, but I can't be sure I didn't miss anything. Can a more TR-internals-savvy person give the changes a quick once-over? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Adding pi.t
While adding racket/extflonum's exports to Typed Racket's base type environment, I realized that we don't have an 80-bit pi constant. I considered exporting this definition from "racket/extflonum.rkt": (define pi.t (extfl* 4.0t0 (extflatan 1.0t0))) (Multiplication by 4.0t0 is exact if it doesn't overflow, so this is correctly rounded as long as `extflatan` is.) But what if the build platform doesn't have extflonums? I've got this right now: (define pi.t 3.1415926535897932385t0) Conversion between 80-bit flonums and decimals round-trips nicely, at least on my computer. But does decimal conversion (besides 0.0t0 and other easy cases) also require extflonums to be available? If so, is there a way to export an 80-bit pi approximation? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Regular expression types [was Re: [racket-bug] all/14455: wrong type for hash]
Are there type systems that can? It seems like you could specify this type and similar ones using regular expressions. In my research, I'll probably use regular expressions to represent sets of strings. I've been curious about how well regular-expression-like things generalize to cartesian products with repeating structure. Neil ⊥ On 04/19/2014 03:44 PM, Eric Dobson wrote: The type for hash is conservative. TR currently cannot express the alternating requirement that hash requires. On Sat, Apr 19, 2014 at 2:40 PM, wrote: A new problem report is waiting at http://bugs.racket-lang.org/query/?cmd=view&pr=14455 Reported by Alex Knauth for release: 6.0 *** Description: the type for hash appears to be (All (a b) (-> (HashTable a b))), so it's not letting me supply it with arguments, saying that it expects 0 arguments *** How to repeat: #lang typed/racket (hash 0 0) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0.1
On 04/17/2014 04:44 PM, Ryan Culpepper wrote: * Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests I found an infinite loop in Plot's new 3D engine, but I've only been able to replicate it using a randomized test case for a feature I haven't pushed yet. Even though that feature won't be in the upcoming release, there's definitely an error in the 3D engine that I don't want users stumbling into. If the Powers That Be don't mind, I'll concentrate on finding a repeatable test case, and check the rest of my list at the second call. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Adding flvector to match
Great idea! Neil ⊥ On 04/17/2014 05:00 PM, Sam Tobin-Hochstadt wrote: I think you should do 2': Change racket/match to recognize patterns with #'flvector heads -- ie, use the binding for flvector from `racket/flonum` to determine if something matches. The use of symbolic names in match, rather than bindings, is a leftover rather than something we should keep adding to. Sam On Thu, Apr 17, 2014 at 6:48 PM, Neil Toronto wrote: It would be really handy for me right now to be able to match on flvectors, and I think it's useful enough for minimal Racket. I've already tried this option: 1. Export flvector as a match expander from racket/flonum but racket/match depends on racket/flonum somehow. So I looked through the match code and determined that this one would be pretty easy: 2. Change racket/match to recognize patterns with 'flvector head (The code is very clean; kudos to whoever last rewrote it. :D) I think #2 would at worst hijack someone's custom flvector match expander, but probably do the same thing or better (e.g. also handle ellipses). But in case it's worse than I think, I can always go with this: 3. Export flvector as a match expander from math/flonum Question for the match and syntax gurus: would doing #2 be safe enough, or should I do #3? Or have I got it backwards; i.e. is #2 actually safer than #3? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Adding flvector to match
It would be really handy for me right now to be able to match on flvectors, and I think it's useful enough for minimal Racket. I've already tried this option: 1. Export flvector as a match expander from racket/flonum but racket/match depends on racket/flonum somehow. So I looked through the match code and determined that this one would be pretty easy: 2. Change racket/match to recognize patterns with 'flvector head (The code is very clean; kudos to whoever last rewrote it. :D) I think #2 would at worst hijack someone's custom flvector match expander, but probably do the same thing or better (e.g. also handle ellipses). But in case it's worse than I think, I can always go with this: 3. Export flvector as a match expander from math/flonum Question for the match and syntax gurus: would doing #2 be safe enough, or should I do #3? Or have I got it backwards; i.e. is #2 actually safer than #3? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
On 04/15/2014 07:29 PM, Asumu Takikawa wrote: On 2014-04-15 18:13:31 -0400, claire alvis wrote: The push below includes changes to letrec expressions, internal definitions, units, classes, and certain ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with classes, doesn't have to worry about # anymore) Does TR not having to worry about # mean that the following program will typecheck? #lang typed/racket (define-type (Lazy-Listof A) (Promise (Pair A (Lazy-Listof A (let () (define: lazy-zeros : (Lazy-Listof Zero) (delay (cons 0 lazy-zeros))) lazy-zeros) Currently, `lazy-zeros' has the type (U Undefined (Lazy-Listof A)) within its definition, but only because it's in an internal definition context. This has come up in a few different guises while I've programmed in TR. BTW, I was happy to see that the type `Lazy-Listof' could be defined like that when coming up with the example. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Native graphics libraries upgraded for Windows and Mac OS X (was Re: Windows GTK version conflicts with GObjectIntrospection)
No need to apologize! Anyway, the previously missing polygon is there in Northwestern's snapshot's docs now. Neil ⊥ On 04/10/2014 11:09 AM, Robby Findler wrote: The Northwestern snapshot broke, sorry about that. (The script's call to "git submodule update" doesn't work for some reason; I've run it manually and we should get a build tomorrow). Robby On Thu, Apr 10, 2014 at 9:57 AM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: This may have fixed the missing polygons in plots that I reported here for the v6.0 release: http://lists.racket-lang.org/__dev/archive/2013-December/__013797.html <http://lists.racket-lang.org/dev/archive/2013-December/013797.html> The sphere plot here is fine, whereas I *think* it wasn't before: http://www.cs.utah.edu/plt/__snapshots/current/doc/plot/__intro.html?q=plot#%28part._.__Renderer_and_.Plot_.Bounds%29 <http://www.cs.utah.edu/plt/snapshots/current/doc/plot/intro.html?q=plot#%28part._.Renderer_and_.Plot_.Bounds%29> But I really need to see the Northwestern snapshot. Yesterday's is still missing the polygon for that plot. Today's build isn't finished, though. According to previous build logs, it should be by now. Neil ⊥ On 04/10/2014 05:01 AM, Matthew Flatt wrote: I've *finally* upgraded the native Windows and Mac OS X libraries for the drawing stack, including GLib, Cairo, and Pango. I've upgraded the libraries for the development version, but not for the upcoming v6.0.1 release, because I'd like to test the new versions for a cycle before putting them in a release. The Utah snapshot page has builds using the new libraries: http://www.cs.utah.edu/plt/__snapshots/ <http://www.cs.utah.edu/plt/snapshots/> I built all the libraries from source this time, instead of taking Windows binaries from www.gtk.org <http://www.gtk.org>, and so the builds use the same version and configurations for all platforms. For example, the Mac OS X builds now include FreeType. See "racket/src/native-libs/__README.txt" for more information. In case there are still any Mac OS X PPC users, the minimum supported version of Mac OS X is now 10.5 instead of 10.4. (Version 10.5 was already the minimum version for Intel, for reasons that I can't remember.) At Mon, 14 Oct 2013 21:34:19 -0600, Matthew Flatt wrote: I haven't had a chance to look into this, but it's still on my list. At Sun, 06 Oct 2013 11:48:57 +0400, Roman Klochkov wrote: Can we upgrade GTK version in the next windows bundle? Or at least GLib and GObject. _ Racket Developers list: http://lists.racket-lang.org/__dev <http://lists.racket-lang.org/dev> _ Racket Developers list: http://lists.racket-lang.org/__dev <http://lists.racket-lang.org/dev> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Native graphics libraries upgraded for Windows and Mac OS X (was Re: Windows GTK version conflicts with GObjectIntrospection)
This may have fixed the missing polygons in plots that I reported here for the v6.0 release: http://lists.racket-lang.org/dev/archive/2013-December/013797.html The sphere plot here is fine, whereas I *think* it wasn't before: http://www.cs.utah.edu/plt/snapshots/current/doc/plot/intro.html?q=plot#%28part._.Renderer_and_.Plot_.Bounds%29 But I really need to see the Northwestern snapshot. Yesterday's is still missing the polygon for that plot. Today's build isn't finished, though. According to previous build logs, it should be by now. Neil ⊥ On 04/10/2014 05:01 AM, Matthew Flatt wrote: I've *finally* upgraded the native Windows and Mac OS X libraries for the drawing stack, including GLib, Cairo, and Pango. I've upgraded the libraries for the development version, but not for the upcoming v6.0.1 release, because I'd like to test the new versions for a cycle before putting them in a release. The Utah snapshot page has builds using the new libraries: http://www.cs.utah.edu/plt/snapshots/ I built all the libraries from source this time, instead of taking Windows binaries from www.gtk.org, and so the builds use the same version and configurations for all platforms. For example, the Mac OS X builds now include FreeType. See "racket/src/native-libs/README.txt" for more information. In case there are still any Mac OS X PPC users, the minimum supported version of Mac OS X is now 10.5 instead of 10.4. (Version 10.5 was already the minimum version for Intel, for reasons that I can't remember.) At Mon, 14 Oct 2013 21:34:19 -0600, Matthew Flatt wrote: I haven't had a chance to look into this, but it's still on my list. At Sun, 06 Oct 2013 11:48:57 +0400, Roman Klochkov wrote: Can we upgrade GTK version in the next windows bundle? Or at least GLib and GObject. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28468: master branch updated
No need to apologize! I'd feel lost if you didn't ask questions that
forced me to explain things better. :)
Do you think it's worthwhile to make it easy for people to get the old
behavior?
Neil ⊥
On 04/04/2014 11:28 AM, Robby Findler wrote:
Oh, I finally understand.
Yes, I agree that this is a good change.
Sorry for the confusion.
Robby
On Fri, Apr 4, 2014 at 10:04 AM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote:
Yes, the relative size of the font will grow, as well as minor
things, such as that the lines will thicken a bit. IOW, without the
fix, if you output the same plot to a PDF, SVG, and PNG, the PDF
will have a smaller font and thinner lines than the SVG and PNG.
It can be hard to tell without converting them to the same format
for comparison, which is why I didn't spot this for so long. I just
thought papers looked better when plots had slightly larger fonts.
I verified that the fix works by using the Gimp to convert a PDF and
an SVG to two 500x500 images, and pasted one over the other.
Neil ⊥
On 04/04/2014 06:42 AM, Robby Findler wrote:
I'm not completely clear on the precise impact of old papers:
will the
plot itself stay the same size, but the relative size of the
font (to
the other plot elements) inside the plot change only? Or
something else?
Robby
On Fri, Apr 4, 2014 at 12:08 AM, Neil Toronto
mailto:neil.toro...@gmail.com>
<mailto:neil.toro...@gmail.com
<mailto:neil.toro...@gmail.com>__>> wrote:
I did it because I was tired of putting (plot-font-size 15)
at the
top of every program that produced a plot for a paper.
Also, I think
it was bad for the "preview" in DrRacket to look different
from the
PDFs. (Some of my plots in DrRacket had legends that badly
overlapped the data in order to look right in PDF format.)
It will
cause existing PDF plots to have larger text, which could
look wrong
in plots that use the font size workaround. But I think
it's the
right move in the long run.
Here's one thing I could do: document `plot-ps-setup' and
export an
`old-plot-ps-setup' that's the default instance of
`ps-setup%', so
programs that produce plots for papers could start this way:
#lang racket
(require plot)
(plot-ps-setup old-plot-ps-setup)
Maybe that parameter is useful after all.
Neil ⊥
On 04/03/2014 10:37 AM, Robby Findler wrote:
Is efc46de backwards compatible? (I worry about
breaking people's
papers, specifically.)
Robby
On Thu, Apr 3, 2014 at 12:20 AM,
mailto:ntoro...@racket-lang.org>
<mailto:ntoronto@racket-lang.__org
<mailto:ntoro...@racket-lang.org>>
<mailto:ntoronto@racket-lang.
<mailto:ntoronto@racket-lang.>org
<mailto:ntoronto@racket-lang.__org
<mailto:ntoro...@racket-lang.org>>>> wrote:
ntoronto has updated `master' from 87cfce97f9 to
efc46ded6d.
http://git.racket-lang.org/plt/87cfce97f9..efc46ded6d
<http://git.racket-lang.org/__plt/87cfce97f9..efc46ded6d>
<http://git.racket-lang.org/__plt/87cfce97f9..efc46ded6d
<http://git.racket-lang.org/plt/87cfce97f9..efc46ded6d>>
=[ 2 Commits
]==
Directory summary:
8.2%
pkgs/plot-pkgs/plot-lib/plot/private/common/
35.5%
pkgs/plot-pkgs/plot-lib/plot/private/no-gui/
12.4%
pkgs/plot-pkgs/plot-lib/plot/____private/plot3d/
41.2% pkgs/plot-pkgs/plot-test/plot/tests/
~~
c1550b6 Neil Toronto mailto:neil.toro...@gmail.com>
<mailto:neil.toro...@gmail.com
<mailto:neil.toro...@gmail.com>__>
<mailto:neil.toro...@gmail.com
<mailto:neil.toro...@gmail.com>
<mailto:neil.toro...@gmail.com
<mailto:neil.toro...@gmail.com>__>__>> 2014-04-02 22:06
:
| Remove unnecessary use of `remove-duplicates'
:
M .../plot-lib/plot/private/plot3d/bsp.rkt
|
11 +--
Re: [racket-dev] [plt] Push #28468: master branch updated
Yes, the relative size of the font will grow, as well as minor things, such as that the lines will thicken a bit. IOW, without the fix, if you output the same plot to a PDF, SVG, and PNG, the PDF will have a smaller font and thinner lines than the SVG and PNG. It can be hard to tell without converting them to the same format for comparison, which is why I didn't spot this for so long. I just thought papers looked better when plots had slightly larger fonts. I verified that the fix works by using the Gimp to convert a PDF and an SVG to two 500x500 images, and pasted one over the other. Neil ⊥ On 04/04/2014 06:42 AM, Robby Findler wrote: I'm not completely clear on the precise impact of old papers: will the plot itself stay the same size, but the relative size of the font (to the other plot elements) inside the plot change only? Or something else? Robby On Fri, Apr 4, 2014 at 12:08 AM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: I did it because I was tired of putting (plot-font-size 15) at the top of every program that produced a plot for a paper. Also, I think it was bad for the "preview" in DrRacket to look different from the PDFs. (Some of my plots in DrRacket had legends that badly overlapped the data in order to look right in PDF format.) It will cause existing PDF plots to have larger text, which could look wrong in plots that use the font size workaround. But I think it's the right move in the long run. Here's one thing I could do: document `plot-ps-setup' and export an `old-plot-ps-setup' that's the default instance of `ps-setup%', so programs that produce plots for papers could start this way: #lang racket (require plot) (plot-ps-setup old-plot-ps-setup) Maybe that parameter is useful after all. Neil ⊥ On 04/03/2014 10:37 AM, Robby Findler wrote: Is efc46de backwards compatible? (I worry about breaking people's papers, specifically.) Robby On Thu, Apr 3, 2014 at 12:20 AM, mailto:ntoro...@racket-lang.org> <mailto:ntoronto@racket-lang.__org <mailto:ntoro...@racket-lang.org>>> wrote: ntoronto has updated `master' from 87cfce97f9 to efc46ded6d. http://git.racket-lang.org/__plt/87cfce97f9..efc46ded6d <http://git.racket-lang.org/plt/87cfce97f9..efc46ded6d> =[ 2 Commits ]=__= Directory summary: 8.2% pkgs/plot-pkgs/plot-lib/plot/__private/common/ 35.5% pkgs/plot-pkgs/plot-lib/plot/__private/no-gui/ 12.4% pkgs/plot-pkgs/plot-lib/plot/__private/plot3d/ 41.2% pkgs/plot-pkgs/plot-test/plot/__tests/ ~~ c1550b6 Neil Toronto mailto:neil.toro...@gmail.com> <mailto:neil.toro...@gmail.com <mailto:neil.toro...@gmail.com>__>> 2014-04-02 22:06 : | Remove unnecessary use of `remove-duplicates' : M .../plot-lib/plot/private/__plot3d/bsp.rkt | 11 +-- M .../plot-test/plot/tests/__plot3d-bsp-tests.rkt | 91 ~~ efc46de Neil Toronto mailto:neil.toro...@gmail.com> <mailto:neil.toro...@gmail.com <mailto:neil.toro...@gmail.com>__>> 2014-04-02 23:16 : | Changed PDF/PS backend to use 1.0 x 1.0 scaling | | This makes plotting to a file the same (well, with slight differences) | regardless of file format. Scaling and other PS options are controlled | by a `plot-ps-setup' parameter. Not sure how useful that is, yet, so | it's undocumented. : M pkgs/plot-pkgs/plot-lib/plot/__private/no-gui/plot2d.rkt | 14 -- M pkgs/plot-pkgs/plot-lib/plot/__private/no-gui/plot3d.rkt | 14 -- M .../plot-lib/plot/private/__common/parameters.rkt | 9 - M .../plot-lib/plot/private/__contracted/parameters.rkt | 2 +- =[ Overall Diff ]=__== pkgs/plot-pkgs/plot-lib/plot/__private/common/parameters.rkt ~~__ --- OLD/pkgs/plot-pkgs/plot-lib/__plot/private/common/__parameters.rkt +++ NEW/pkgs/plot-pkgs/plot-lib/__plot/private/common/__parameters.rkt @@ -3,6 +3,7 @@ ;; Parameters that control the l
Re: [racket-dev] [plt] Push #28468: master branch updated
I did it because I was tired of putting (plot-font-size 15) at the top of every program that produced a plot for a paper. Also, I think it was bad for the "preview" in DrRacket to look different from the PDFs. (Some of my plots in DrRacket had legends that badly overlapped the data in order to look right in PDF format.) It will cause existing PDF plots to have larger text, which could look wrong in plots that use the font size workaround. But I think it's the right move in the long run. Here's one thing I could do: document `plot-ps-setup' and export an `old-plot-ps-setup' that's the default instance of `ps-setup%', so programs that produce plots for papers could start this way: #lang racket (require plot) (plot-ps-setup old-plot-ps-setup) Maybe that parameter is useful after all. Neil ⊥ On 04/03/2014 10:37 AM, Robby Findler wrote: Is efc46de backwards compatible? (I worry about breaking people's papers, specifically.) Robby On Thu, Apr 3, 2014 at 12:20 AM, mailto:ntoro...@racket-lang.org>> wrote: ntoronto has updated `master' from 87cfce97f9 to efc46ded6d. http://git.racket-lang.org/plt/87cfce97f9..efc46ded6d =[ 2 Commits ]== Directory summary: 8.2% pkgs/plot-pkgs/plot-lib/plot/private/common/ 35.5% pkgs/plot-pkgs/plot-lib/plot/private/no-gui/ 12.4% pkgs/plot-pkgs/plot-lib/plot/private/plot3d/ 41.2% pkgs/plot-pkgs/plot-test/plot/tests/ ~~ c1550b6 Neil Toronto mailto:neil.toro...@gmail.com>> 2014-04-02 22:06 : | Remove unnecessary use of `remove-duplicates' : M .../plot-lib/plot/private/plot3d/bsp.rkt | 11 +-- M .../plot-test/plot/tests/plot3d-bsp-tests.rkt | 91 ~~ efc46de Neil Toronto mailto:neil.toro...@gmail.com>> 2014-04-02 23:16 : | Changed PDF/PS backend to use 1.0 x 1.0 scaling | | This makes plotting to a file the same (well, with slight differences) | regardless of file format. Scaling and other PS options are controlled | by a `plot-ps-setup' parameter. Not sure how useful that is, yet, so | it's undocumented. : M pkgs/plot-pkgs/plot-lib/plot/private/no-gui/plot2d.rkt | 14 -- M pkgs/plot-pkgs/plot-lib/plot/private/no-gui/plot3d.rkt | 14 -- M .../plot-lib/plot/private/common/parameters.rkt | 9 - M .../plot-lib/plot/private/contracted/parameters.rkt | 2 +- =[ Overall Diff ]=== pkgs/plot-pkgs/plot-lib/plot/private/common/parameters.rkt ~~ --- OLD/pkgs/plot-pkgs/plot-lib/plot/private/common/parameters.rkt +++ NEW/pkgs/plot-pkgs/plot-lib/plot/private/common/parameters.rkt @@ -3,6 +3,7 @@ ;; Parameters that control the look and behavior of plots. (require racket/contract unstable/parameter-group unstable/latent-contract/defthing + racket/class racket/draw "contract.rkt" "draw.rkt" "axis-transform.rkt" @@ -107,11 +108,17 @@ ;; Output +(define default-plot-ps-setup (new ps-setup%)) +(send default-plot-ps-setup set-margin 0 0) +(send default-plot-ps-setup set-scaling 1 1) + (defparam plot-new-window? boolean? #f) (defparam plot-jpeg-quality (integer-in 0 100) 100) (defparam plot-ps/pdf-interactive? boolean? #f) +(defparam plot-ps-setup (is-a?/c ps-setup%) default-plot-ps-setup) -(define-parameter-group plot-output (plot-new-window? plot-jpeg-quality plot-ps/pdf-interactive?)) +(define-parameter-group plot-output + (plot-new-window? plot-jpeg-quality plot-ps/pdf-interactive? plot-ps-setup)) ;; Labels pkgs/plot-pkgs/plot-lib/plot/private/contracted/parameters.rkt ~~ --- OLD/pkgs/plot-pkgs/plot-lib/plot/private/contracted/parameters.rkt +++ NEW/pkgs/plot-pkgs/plot-lib/plot/private/contracted/parameters.rkt @@ -28,7 +28,7 @@ plot3d-samples plot3d-angle plot3d-altitude plot3d-ambient-light plot3d-diffuse-light? plot3d-specular-light? - plot-new-window? plot-jpeg-quality plot-ps/pdf-interactive? + plot-new-window? plot-jpeg-quality plot-ps/pdf-interactive? plot-ps-setup plot-title plot-x-label plot-y-label plot-z-label plot-x-far-label plot-y-far-label plot-z-far-label pkgs/plot-pkgs/plot-lib/plot/private/no-gui/plot2d.rkt ~~ --- OLD/pkgs/plot-pkgs/plot-lib/plot/private/no-gui/plot2d.rkt +++ NEW/pkgs/plot-pkgs/plot-lib/plot/private/no-gui/plot2d.rkt @@ -112,12 +11
Re: [racket-dev] [plt] Push #28453: master branch updated
On 04/01/2014 02:08 AM, ntoro...@racket-lang.org wrote: ntoronto has updated `master' from 8a93eeb52b to a515e7cee1. http://git.racket-lang.org/plt/8a93eeb52b..a515e7cee1 =[ 2 Commits ]== Directory summary: 90.9% pkgs/plot-pkgs/plot-lib/plot/private/plot3d/ 5.1% pkgs/plot-pkgs/plot-test/plot/tests/ 3.8% pkgs/plot-pkgs/ ~~ 97d20c9 Neil Toronto 2014-03-27 09:16 : | Checkpoint : M .../plot-lib/plot/private/plot3d/plot-area.rkt| 119 ++- Whoops, forgot to rewrite history. How do I fix this? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28247: master branch updated
On 02/26/2014 01:43 AM, endob...@racket-lang.org wrote: endobson has updated `master' from 2df436d29c to 62a09958d2. http://git.racket-lang.org/plt/2df436d29c..62a09958d2 =[ One Commit ]= Directory summary: 76.6% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/ 23.3% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/ ~~ 62a0995 Eric Dobson 2014-02-26 00:34 : | Revert "Fix type of - to not be wrong on negative fixnums." | | The math library is relying on the current broken behavior. Revert until | we can fix it. Turns out it was nothing critical or user-facing, just an attempt at a sanity check on a value that was going to be passed to `make-vector', which checks the value's size anyway. You should be able to un-revert. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28224: master branch updated
On 02/23/2014 08:36 AM, ro...@racket-lang.org wrote: robby has updated `master' from b047b32c6e to e0a1a40fd4. http://git.racket-lang.org/plt/b047b32c6e..e0a1a40fd4 ~~ e0a1a40 Robby Findler 2014-02-23 09:24 : | change the meaning of the #:enum argument to redex-check | | Thanks to Neil Toronto for suggesting how to do this! : M pkgs/redex-pkgs/redex-lib/redex/HISTORY.txt | 2 + M .../redex-doc/redex/scribblings/ref.scrbl | 15 --- M .../redex-lib/redex/private/generate-term.rkt | 47 +--- M .../redex-pkgs/redex-test/redex/tests/rg-test.rkt | 2 +- Does this give you the kind of random test cases you were looking for? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On 02/20/2014 09:03 PM, Asumu Takikawa wrote: On 2014-02-20 20:31:56 -0700, Neil Toronto wrote: How close is this to being able to support, say, the plot library converted to TR? The OO stuff in it is a few custom classes without anything complicated, a couple of snip% descendants, and drawing onto device contexts. Should be very close. Not quite there currently because there are two more chunks that I've written and haven't pushed yet: * Implicit (mutual) recursive type aliases, so that a `define-type` can define mutually recursive type alises like the types for `bitmap%` and `bitmap-dc%`. You mean something like this would work? (define-type (Leaf1 X) (Pair (Leaf2 X) (Leaf2 X))) (define-type (Leaf2 X) (U X (Pair (Leaf1 X) (Leaf1 X * Types for everything in racket/gui and a few other libraries. Types for the framework are still work-in-progress. * Full contract support. I'm with Robby. This sounds awesome. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On 02/20/2014 02:52 PM, as...@racket-lang.org wrote: asumu has updated `master' from 1f27fb7848 to 1c6c0855f7. http://git.racket-lang.org/plt/1f27fb7848..1c6c0855f7 =[ 103 Commits ] Directory summary: 3.8% pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/ 10.7% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/ 6.1% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/ 4.0% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/rep/ 34.5% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/ 9.6% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/types/ 4.0% pkgs/typed-racket-pkgs/typed-racket-more/typed/mred/ 23.6% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/ 3.4% pkgs/ ~~ [... HOLY COW ...] How close is this to being able to support, say, the plot library converted to TR? The OO stuff in it is a few custom classes without anything complicated, a couple of snip% descendants, and drawing onto device contexts. Also, is there a paper floating around somewhere that details the interesting problems that have been solved to make this work? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27909: master branch updated
I don't think so. The flonum functions are Flonum -> Flonum, and `magnitude*' is Number -> Number. The best candidate from the math library is probably `mean'. Neil ⊥ On 01/14/2014 11:24 AM, Robby Findler wrote: Do any of these functions turn out to have case-> contracts by the time TR gets done with them? Robby On Tue, Jan 14, 2014 at 12:22 PM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: An update on my math-centered tests. The first is the built-in `magnitude' vs. a TR near-transliteration of its C implementation, called from *untyped* Racket. The numbers are in milliseconds, for 5 million calls, by input type: Function Flonum Rational Fixnum Integer Float-Complex --__--__--- Pre-static contracts: magnitude* 385 419 378 414 686 magnitude 59 44 40 40 390 Post-static contracts: magnitude* 175 196 164 195 475 magnitude 68 43 36 40 406 All but the Float-Complex case just return the absolute value of the argument, so there's not much computation. They're dominated by contract checking, and the speedup is 0.45 to 0.5. Nice. The Float-Complex case does something substantive, and is close to C. That's awesome. So for really small functions (i.e. just a test and a call to `abs'), writing them in C is still better. But for anything much larger (that part of `magnitude*' is about 10 lines and 7-13 numeric ops), a TR implementation isn't much slower than C (about 17%). -- 1 million iterations of some math library flonum functions, in TR, untyped before Robby's changes, untyped after Robby's 12/12 changes, and untyped after Eric's static contract changes, in milliseconds: Function TR UntypedRobby's Robby's+Eric's --__--__-- flrational? 5 32298 37 flsinh 55 343 121 86 fllog1p 47 351 117 80 lg+ 61 384 154 115 flgamma 165 521 262 234 So calling TR floating-point functions from untyped Racket takes only 0.11 to 0.45 times the amount of time it took only a month ago, with typical cases being about 0.25. That's awesome. Neil ⊥ On 01/14/2014 10:27 AM, Eric Dobson wrote: The changes to TR contract generation are now in at HEAD. If you can find any cases where contracts are still slowing programs down by a lot I'd like to take a look at them. (Excepting the case of structs where I know it is still an issue). On Thu, Dec 12, 2013 at 10:52 AM, Robby Findler mailto:ro...@eecs.northwestern.edu>> wrote: Re-reading your message I see that you're not actually asserting something different from what I said, but just for some precision here I wish to point out that I wasn't basing my opinion on intuition from the code, but on some microbenchmark timings. (There was a much more substantial difference yesterday because the loop inside any-wrap/c wasn't as cheap as it could have been.) I'd be interested to see if your improvements to type->contract improve the situation any! I expect they will make things better again for the Number case, but at the moment, there isn't a big difference. Program 1: #lang racket/base (module m typed/racket/base (: f (Any -> Any)) (define (f x) 1) (provide f)) (require 'm) (time (for ([x (in-range 2)]) (f 0) (f 1) (f 2) (f 3) (f 4) (f 5) (f 6) (f 7) (f 0) (f 1) (f 2) (f 3) (f 4) (f 5) (f 6) (f 7) (f 0) (f 1) (f 2) (f 3) (f 4) (f 5) (f 6) (f 7) (f 0) (f 1) (f 2) (f 3) (f 4) (f 5) (f 6) (f 7) (f 0) (f 1) (f 2) (f 3) (f 4) (f 5) (f 6) (f 7) (f 0) (f 1) (f 2) (f 3) (f 4) (f 5) (f 6) (f 7) (f 0) (f 1) (f 2) (f 3) (f 4) (f 5) (f 6) (f 7) (f 0) (f 1) (f 2) (f 3) (f 4) (f 5) (f 6) (f 7))) Timings: cpu time: 142 real time: 142 gc time: 8 cpu time: 144 real time: 144 gc time: 7 cpu time: 144 real time: 143 gc time: 6 cpu time: 142 real time: 142 gc time: 6 cpu time: 142 real time: 142
Re: [racket-dev] [plt] Push #27909: master branch updated
ining and dead code elimination can see through everything and turn it into the same code. On Thu, Dec 12, 2013 at 10:27 AM, Robby Findler wrote: FWIW, my push speeds up the any-wrap/c implementation a bunch. Those two should have similar speeds after you get that, I guess. Robby On Thu, Dec 12, 2013 at 11:03 AM, Neil Toronto wrote: I tried your branch that implements it and saw about 3.5x speedup for the `magnitude*' test. This is of course without Robby's recent first-order contract changes. (I think it's about 3.5x: I tried with magnitude* : Number -> Any first and got 2400ms on the easy tests. I changed it to magnitude* : Number -> Number and got 690ms. Apparently, for an `Any' return type, an `any-wrap/c' contract is generated instead of nothing. If that's much faster to check than `number?', though, the speedup is even better.) I'd love to see this with Robby's recent changes. Hint? Nudge? Please? I didn't see very much speedup with arrays (about 1.2x). Speed tests on the math library's distribution objects were very interesting, though, and indicate why the arrays might not be much faster. Here's my test program: #lang racket (require math/distributions) (define d (normal-dist 0 1)) (printf "pdf d 0~n") (for ([_ (in-range 5)]) (time (for ([_ (in-range 10)]) (pdf d 0 (newline) (define p (distribution-pdf d)) (printf "p 0~n") (for ([_ (in-range 5)]) (time (for ([_ (in-range 10)]) (p 0 (newline) The two tests are equivalent, as `pdf' just pulls the pdf function out of the distribution struct and applies it. In TR, the tests are exactly the same speed (extremely fast). In untyped Racket, on the main branch, the second test is 16x faster, and on your branch, it's 44x faster. (It's still 10x slower than TR on your branch, so again... I'd love to see your changes and Robby's together. :D) Neil ⊥ On 12/12/2013 12:40 AM, Eric Dobson wrote: Removing the return value checking is in the works. It actually is removing all of the checks that would blame typed code, so higher order functions/datastructure get improvements too. It is actually functional the last time I checked, but lacking documentation which is what is holding up merging with mainline. https://github.com/plt/racket/pull/453 On Wed, Dec 11, 2013 at 7:57 PM, Robby Findler wrote: I see that TR's type->contract returns (-> (flat-named-contract (quote Float) flonum?) (flat-named-contract (quote Float) flonum?)) for the type (Float -> Float), but it could return (-> (flat-named-contract (quote Float) flonum?) any) which wouldn't do any result value checking (this being different from any/c as the range of the arrow contract). Robby On Wed, Dec 11, 2013 at 6:18 PM, Neil Toronto wrote: On 12/11/2013 02:49 PM, Neil Toronto wrote: On 12/11/2013 01:55 PM, Stephen Bloch wrote: On Dec 11, 2013, at 2:36 PM, Neil Toronto wrote: numeric primitives implemented in Typed Racket are faster than the same primitives implemented in C. Whoa! How did that happen? Whoa! That's not what I meant! O_o I said "we might be getting close" to that. I haven't tried porting a numeric C primitive to TR yet, but I have a hunch that it'll still be slower. I'll try one now and report what I find. Neil ⊥ I can't figure out why `flsinh' is faster to call from untyped Racket than `sinh'. All my tests with a Typed Racket `magnitude' show calls from untyped code are significantly slower, except in the one case that it computes Euclidean distance. That case is only twice as slow. I've attached the benchmark program. The `magnitude*' function is more or less a direct translation of `magnitude' from "number.c" into Typed Racket. Here's a summary of the results I get on my computer, in milliseconds, for 5 million calls from untyped Racket, by data type. Function Flonum Rational Fixnum Integer Float-Complex --- magnitude* 385 419 378 414 686 magnitude 59 44 40 40 390 The only one that's close in relative terms is Float-Complex. The others just call `abs'. The decompiled code doesn't show any inlining of `magnitude', so this comparison should be good. I'll bet checking the return value contract (which is unnecessary) is the main slowdown. It has to check for number of values. For comparison, here are the timings for running the benchmarks in TR with #:no-optimize: Function Flonum Rational Fixnum Integer Float-Complex --- magnitude* 45 70* 37 102* 318 magnitude 61 45 39
Re: [racket-dev] [plt] Push #28022: master branch updated
On 01/06/2014 07:38 PM, mfl...@racket-lang.org wrote: eda4f35 Matthew Flatt 2014-01-06 18:52 : | file/convertible: declare 'png@2x-bytes conversion variant | | The 'png@2x-bytes variant is like 'png-bytes, but where the decoded | bytes are intended to be scaled by 1/2. | | Consumers: | | - DrRacket's print handler | | - Scribble's HTML renderer | | Producers: | | - `bitmap%`s where the scaling factor is 2 | | - picts | | Examples: Quick docs, docs for `images/icons/misc`, DrRacket interactions | for results of `images/icons/misc` functions. Is there a way to make Scribble request 'png@2x-bytes when building the Plot docs? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28009: master branch updated
On 01/05/2014 06:00 PM, Matthew Flatt wrote: At Sun, 05 Jan 2014 15:18:51 -0700, Neil Toronto wrote: How does DrRacket look on Retina displays now? It's getting there. Remaining problem include the GC icon and some part(s) of the process to show bitmaps in the interactions window. `images/icons/symbol' has `recycle-icon', but I'm guessing there's more pain than just making one. IIRC, the garbage collector itself draws it, which is a bit icky. I remember not replacing that icon because, frankly, I was afraid of the GC code. FWIW, I looked over your changes to `images' and approve of them all. :) Also, the "icons are already being rendered at 2x resolution" thing I wrote in the private email wasn't quite true. Anything drawn using the icon cache is drawn at least 32px high, and the DrRacket toolbar icons are 18px IIRC. So it was mostly true for those and other style-consistent toolbar icons, but not for logos, or for the little feet in the steppers. But that's okay - they don't take long and are done at compile time. Can you post part of a screenshot? Here's a full screenshot (2880x1800): http://www.cs.utah.edu/~mflatt/tmp/screen.png Neeet! Plots should look wonderful now, too. The 3D plots are low-res when they're being rotated, but that's intentional. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Can't change plot in DrRacket without getting link errors
Ah, I see. Now that I know that, I can duplicate the problem more easily: just having Plot's "draw.rkt" open in another tab gives me a link error. As soon as I close that tab, DrRacket uses the .zo files compiled by raco setup, and plotting works again. Another workaround (besides closing a tab) is to choose "No debugging or profiling" from the language dialog. Apparently, that makes the .zo files DrRacket builds compatible with the output of raco setup. But I still have to wait for it to recompile everything the first time. I think the current behavior would be fine with a small tweak. Is it possible for DrRacket to determine whether each .zo file in the "compiled" directory is up-to-date, and use those that are? Then I could either have DrRacket's on-demand compiler build Plot, or use raco setup. (The former would be much easier if the "-c" flag could clean just one collection or package, though.) Neil ⊥ On 01/03/2014 09:28 PM, Robby Findler wrote: Yes: as an experiment we decided to treat files that are open differently than other files for the purposes of recompiling them. Looks like that's probably a bad design decision. But it may just be a bug too, since I thought it was re-compiling more, not less, when you have the file open. Robby On Fri, Jan 3, 2014 at 7:22 PM, Jens Axel Søgaard mailto:jensa...@soegaard.net>> wrote: Try this: - open the menu "Language" in DrRacket - choose the menu item "Choose language..." - click the button "Show details" - remove the tick in "Populate 'compiled' directories (for faster loading) /Jens Axel 2014/1/4 Neil Toronto mailto:neil.toro...@gmail.com>>: > I do this: > > * In DrRacket, open "pkgs/plot-pkgs/plot-lib/plot/private/common/draw.rkt" > > * Make a small change, save > > * At the command line, "racket/bin/raco setup --no-docs -l plot" > > * Run a test file in another tab in DrRacket that has (require plot) > > > I wait a long time (I think it's recompiling) and get this error: > > link: bad variable linkage; > reference to a variable that has the wrong procedure or structure-type > shape > reference phase level: 0 > variable module: > "/home/neil/plt/pkgs/plot-pkgs/plot-lib/plot/private/common/draw.rkt" > variable phase: 0 > reference in module: > "/home/neil/plt/pkgs/plot-pkgs/plot-gui-lib/plot/private/gui/plot2d.rkt" in: > draw-bitmap > > > So I remove the "compiled" directory and try again. Same problem. > > Here's the kicker: I always get link errors *until I close "draw.rkt" in > DrRacket*. After that, I can remove the "compiled" directory, rebuild, and > run the program without errors. > > Does anybody know what's going on? > > Neil ⊥ > _ > Racket Developers list: > http://lists.racket-lang.org/dev -- -- Jens Axel Søgaard _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28009: master branch updated
That sounds right, and your description of the difference perfectly explains why the plots were wrong. Polygon vertexes were snapped to the nearest *drawing context* unit instead of the nearest *destination* unit. IOW, they were aligned with a low-resolution grid. Of course they were lumpy. I agree that the default alignment scale should be 1. If a function receives a bitmap from somewhere that may have backing scale != 1, drawing operations should still work as expected, except the resolution of the result may be higher or lower. The plots look great with your recent changes, and I look forward to unbreaking them after you break them again. :) How does DrRacket look on Retina displays now? Can you post part of a screenshot? Neil ⊥ On 01/05/2014 01:47 PM, Matthew Flatt wrote: After further exploration, I think I'm going to have to re-break your program and give you a way to un-break it. The issue is what "aligned" means: * "Pixel-aligned" makes drawing to a bitmap with a backing scale of 2 (at scale 1) consistent with drawing at scale 2 to a bitmap with a backing scale --- as you wanted. * "Unit-aligned" makes drawing to a bitmap with a backing scale of 2 more consistent with drawing to a bitmap with backing scale 1. The change I pushed was essentially from "unit-aligned" to "pixel-aligned", because "pixel-aligned" seems to better match the goal of aligned drawing. But "pixel-aligned" changes the meaning of alignment in a way that breaks programs. For example, the caret in an editor becomes slightly mangled on boundaries: it's normally drawn with a pen width of 1 in unsmoothed/aligned mode at integer unit positions, which makes the drawing shift left by one Retina pixel in Retina mode. I think the solution is to allow a backing scale and an alignment scale to be different in a drawing context. (More precisely, the backing scale is a property of a drawing destination, while alignment scale is a property of a drawing context.) By default, I think a DC's alignment scale should be 1 (i.e., unit-aligned) for compatibility. For your purposes, then, you'll need to explicitly set the DC's alignment scale to 2 to match the backing scale. Does that sound right/ok? At Sun, 5 Jan 2014 08:55:12 -0700, Matthew Flatt wrote: Thanks --- I think I've fixed alignment for drawing to a bitmap with a backing scale. At Fri, 03 Jan 2014 19:33:22 -0700, Neil Toronto wrote: On 01/03/2014 06:12 PM, mfl...@racket-lang.org wrote: bd4d0b7 Matthew Flatt 2014-01-03 17:57 : | if a bitmap has a non-1 backing scale, always draw smoothly to other contexts : M pkgs/draw-pkgs/draw-lib/racket/draw/private/dc.rkt | 11 ++- Cool. It looks like this solved another issue as well: drawing 2x bitmaps in the REPL would smooth only intermittently. There appears to be a problem with drawing in 'unsmoothed mode onto a bitmap with a backing scale. I've attached a program that demonstrates using a single polygon and with plots. In the single polygon test, the triangle drawn onto the 2x bitmap is shifted down and to the right one pixel. The code that draws a plot onto a 2x bitmap simulates the change I would make to Plot to take advantage of the new backing scale feature. The edge of the sphere looks lumpy, probably because polygons are drawn unsmoothed and their vertices are being snapped to the wrong places. The second plot shows how it's supposed to look. The last two plots show how each looks before being scaled down. The lumpiness around the edge is probably easier to see this way. Neil ⊥ -- [text/plain "unsmoothed-polygons.rkt"] [~/Desktop & open] [~/Temp & open] _ 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 #28009: master branch updated
On 01/03/2014 06:12 PM, mfl...@racket-lang.org wrote: bd4d0b7 Matthew Flatt 2014-01-03 17:57 : | if a bitmap has a non-1 backing scale, always draw smoothly to other contexts : M pkgs/draw-pkgs/draw-lib/racket/draw/private/dc.rkt | 11 ++- Cool. It looks like this solved another issue as well: drawing 2x bitmaps in the REPL would smooth only intermittently. There appears to be a problem with drawing in 'unsmoothed mode onto a bitmap with a backing scale. I've attached a program that demonstrates using a single polygon and with plots. In the single polygon test, the triangle drawn onto the 2x bitmap is shifted down and to the right one pixel. The code that draws a plot onto a 2x bitmap simulates the change I would make to Plot to take advantage of the new backing scale feature. The edge of the sphere looks lumpy, probably because polygons are drawn unsmoothed and their vertices are being snapped to the wrong places. The second plot shows how it's supposed to look. The last two plots show how each looks before being scaled down. The lumpiness around the edge is probably easier to see this way. Neil ⊥ #lang racket (require plot racket/draw) (define (get-backing-bitmap bm) (define s (send bm get-backing-scale)) (define bm2 (make-bitmap (exact-ceiling (* s (send bm get-width))) (exact-ceiling (* s (send bm get-height) (define dc (make-object bitmap-dc% bm2)) (send dc set-scale s s) (send dc set-smoothing 'unsmoothed) (send dc draw-bitmap bm 0 0) bm2) (define (draw-unsmoothed-triangle dc) (send dc set-smoothing 'unsmoothed) (send dc set-background "orange") (send dc clear) (send dc set-pen (make-object pen% "black" 1 'transparent)) (send dc set-brush (make-object brush% "black")) (send dc draw-polygon '((0 . 0) (9 . 3) (4 . 6 (define bm1 (make-bitmap 10 10 #:backing-scale 2)) (define dc1 (make-object bitmap-dc% bm1)) (draw-unsmoothed-triangle dc1) (define bm2 (make-bitmap 20 20)) (define dc2 (make-object bitmap-dc% bm2)) (send dc2 set-scale 2 2) (draw-unsmoothed-triangle dc2) (printf "Triangles drawn in unsmoothed mode (top uses backing scale):~n") (values (get-backing-bitmap bm1) bm2) (printf "Plot rendered to bitmap with backing scale:~n") (define bm3 (make-bitmap 400 400 #:backing-scale 2)) (define dc3 (make-object bitmap-dc% bm3)) (plot3d/dc (polar3d (λ (θ ρ) 1) #:color 2 #:line-style 'transparent) dc3 0 0 400 400 #:altitude 25) bm3 (printf "Plot rendered 2x and downscaled:~n") (plot3d-bitmap (polar3d (λ (θ ρ) 1) #:color 2 #:line-style 'transparent) #:altitude 25) (printf "Actual 2x bitmap:~n") (get-backing-bitmap bm3) (printf "Plot rendered 2x:~n") (define bm4 (make-bitmap 800 800)) (define dc4 (make-object bitmap-dc% bm4)) (plot3d/dc (polar3d (λ (θ ρ) 1) #:color 2 #:line-style 'transparent) dc4 0 0 800 800 #:altitude 25) bm4 _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Can't change plot in DrRacket without getting link errors
I do this: * In DrRacket, open "pkgs/plot-pkgs/plot-lib/plot/private/common/draw.rkt" * Make a small change, save * At the command line, "racket/bin/raco setup --no-docs -l plot" * Run a test file in another tab in DrRacket that has (require plot) I wait a long time (I think it's recompiling) and get this error: link: bad variable linkage; reference to a variable that has the wrong procedure or structure-type shape reference phase level: 0 variable module: "/home/neil/plt/pkgs/plot-pkgs/plot-lib/plot/private/common/draw.rkt" variable phase: 0 reference in module: "/home/neil/plt/pkgs/plot-pkgs/plot-gui-lib/plot/private/gui/plot2d.rkt" in: draw-bitmap So I remove the "compiled" directory and try again. Same problem. Here's the kicker: I always get link errors *until I close "draw.rkt" in DrRacket*. After that, I can remove the "compiled" directory, rebuild, and run the program without errors. Does anybody know what's going on? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0, Second Call
No, but that was a good idea, so I checked it. It doesn't happen in 5.3.6. Neil ⊥ On 12/30/2013 09:14 PM, Robby Findler wrote: I assume you checked and it doesn't happen in 5.3.6? Robby On Mon, Dec 30, 2013 at 9:53 PM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: We really shouldn't ship until this memory leak is fixed (which I just reported): http://bugs.racket-lang.org/__query/?cmd=view&pr=14264 <http://bugs.racket-lang.org/query/?cmd=view&pr=14264> It's making writing substantial programs very difficult, especially in Typed Racket, which seems to be affected more. It's possible there's a weird interaction with Ubuntu 13.10, which I upgraded to last week, but I don't know what it could be. Or I may just not have noticed before. (I haven't been coding much recently.) Neil ⊥ _ 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 v6.0, Second Call
We really shouldn't ship until this memory leak is fixed (which I just reported): http://bugs.racket-lang.org/query/?cmd=view&pr=14264 It's making writing substantial programs very difficult, especially in Typed Racket, which seems to be affected more. It's possible there's a weird interaction with Ubuntu 13.10, which I upgraded to last week, but I don't know what it could be. Or I may just not have noticed before. (I haven't been coding much recently.) Neil ⊥ #lang racket (require (only-in typed/racket/base index?)) (define (emit v) (printf "~a~n" v)) ;(: multi-dag-add-edge (All (T R) ((Multi-Dag T R) T R T -> (Multi-Dag T R (define (multi-dag-add-edge h src r dst) (define edges (hash-ref h src (λ () (make-immutable-hash (define dsts (hash-ref edges r (λ () (set (hash-set h src (hash-set edges r (set-add dsts dst ;; === ;(: set-union* (All (A) ((Setof (Setof A)) -> (Setof A (define (set-union* s) (define ss (set->list s)) (cond [(empty? ss) (set)] [else (apply set-union (first ss) (rest ss))])) ;(: set-image (All (A B) ((A -> B) (Setof A) -> (Setof B (define (set-image f s) (list->set (set-map s f))) ;(: set-bind (All (A B) ((Setof A) (A -> (Setof B)) -> (Setof B (define (set-bind A f) (set-union* (set-image f A))) ;; === (struct Relation (forward backward) #:transparent #:property prop:custom-print-quotable 'never #:property prop:custom-write (λ (r out mode) (write-string (symbol->string (Relation-forward r)) out))) (define-syntax-rule (define-relation name1 name2) (begin (define name1 (Relation 'name1 'name2)) (define name2 (Relation 'name2 'name1 (define-relation holding held-by) (define-relation inside outside) (define-relation north south) (define-relation east west) (define-relation up down) ;(: relation-reverse (Relation -> Relation)) (define (relation-reverse r) (Relation (Relation-backward r) (Relation-forward r))) ;; === (struct Edge (fst rel snd) #:transparent) (struct Action-Type () #:transparent) (struct Look Action-Type () #:transparent) (struct Describe Action-Type (parent relation entity) #:transparent) (struct Action-Dest (relation entity) #:transparent) (struct Action-Path (src dsts) #:transparent) (struct Init-Action (type src) #:transparent) (struct Received-Action (type path) #:transparent) ;(define-type Action (U Init-Action Received-Action)) ;(: action-path-entities (Action-Path -> (Listof Pointer))) (define (action-path-entities p) (match-define (Action-Path src dsts) p) (cons src (reverse (map Action-Dest-entity dsts ;(: action-path-relations (Action-Path -> (Listof Relation))) (define (action-path-relations p) (reverse (map Action-Dest-relation (Action-Path-dsts p ;(: action-entities (Action -> (Listof Pointer))) (define (action-entities act) (match act [(Init-Action _ src) (list src)] [(Received-Action _ path) (action-path-entities path)])) ;(: action-last-entity (Action -> Pointer)) (define (action-last-entity act) (match act [(Init-Action type src) src] [(Received-Action type (Action-Path src dsts)) (Action-Dest-entity (first dsts))])) ;(: action-push-dest (Action Relation Pointer -> Received-Action)) (define (action-push-dest act r dst) (match act [(Init-Action type src) (Received-Action type (Action-Path src (list (Action-Dest r dst] [(Received-Action type (Action-Path src dsts)) (Received-Action type (Action-Path src (cons (Action-Dest r dst) dsts)))])) ;(: action-pop-dest (Received-Action -> (Values Action Relation Pointer))) (define (action-pop-dest act) (match-define (Received-Action type (Action-Path src dsts)) act) (match-let* ([(Action-Dest rel dst) (first dsts)] [dsts (rest dsts)]) (cond [(empty? dsts) (values (Init-Action type src) rel dst)] [else (values (Received-Action type (Action-Path src dsts)) rel dst)]))) ;(: action-path-reverse (Action-Path -> Action-Path)) (define (action-path-reverse p) (match-define (Action-Path src dsts) p) (define es (reverse (action-path-entities p))) (define rs (reverse (action-path-relations p))) (Action-Path (first es) (reverse (for/list ([e (in-list (rest es))] [r (in-list rs)]) (Action-Dest (relation-reverse r) e) (struct Entity (name alts start-action receive-action properties) #:transparent) ;(: empty-property-hash (HashTable Symbol Any)) (define empty-property-hash (make-immutable-hasheq)) ;; === ;; The world ;(define-type Pointer Index) ;(: empty-entity-s
Re: [racket-dev] Pre-Release Checklist for v6.0, corrected url
I don't think there's anything I can look into. I can't duplicate the problem on my system, and Plot doesn't do anything platform-specific, so the bug is almost certainly in `pict', `racket/draw' or Cairo. Matthew? Sorry I wasn't clear on this earlier. (It could be that it's *possible* duplicate it on my system, and that it only shows up on the build machine because the default font is a different size, which gives the plot areas slightly different sizes, which gives the projected triangles slightly different vertices. I could look into that, but it seems unlikely. I use Plot a *lot* and have never seen this before.) If I were debugging it, I'd try to find the simplest plot that's missing a polygon. Here are the bad plots from the docs, rendered the way the docs do it (plot to a pict, then convert to a bitmap), with the number of samples easy to tweak: #lang racket (require pict plot/pict) (plot3d-samples 41) ; default is 41 (parameterize ([plot-z-ticks (currency-ticks)]) (pict->bitmap (plot3d-pict (contour-intervals3d (λ (x y) (- (sqr x) (sqr y))) -1 1 -1 1 #:label "z") #:legend-anchor 'center))) (pict->bitmap (plot3d-pict (polar3d (λ (θ ρ) 1) #:color 2 #:line-style 'transparent) #:altitude 25)) I'd also try passing #:out-file "out.pdf" to `plot3d-pict' to see if the PDF back-end is afflicted. I don't know how worried to be about missing polygons. It could be anything from bad array management in Cairo (which could be serious) to a mostly harmless problem in the implementation of region culling or winding rules. Neil ⊥ On 12/29/2013 09:39 PM, Robby Findler wrote: Neil: have you had time to look into this? If not, then I think we should just leave it for the next release. Please let us know what you're thinking about this one. Robby On Sat, Dec 21, 2013 at 4:13 PM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: Some plots in the documentation are missing a polygon. I think it's platform-specific, because I can't reproduce the problem. Examples: First example plot in "1.5 Renderer and Plot Bounds" (look for a light green rectangle) file:///usr/racket-5.91.0.900/__doc/plot/intro.html?q=plot#%__28part._.Renderer_and_.Plot_.__Bounds%29 Last example plot in `plot-z-far-ticks' docs (look for a white hole under the "z" in the legend) http://plt.eecs.northwestern.__edu/snapshots/current/doc/__plot/ticks_and_transforms.__html?q=plot-z-far-ticks#%__28def._%28%28lib._plot%2Fmain.__.rkt%29._plot-z-far-ticks%29%__29 <http://plt.eecs.northwestern.edu/snapshots/current/doc/plot/ticks_and_transforms.html?q=plot-z-far-ticks#%28def._%28%28lib._plot%2Fmain..rkt%29._plot-z-far-ticks%29%29> Here's a program that renders one of the bad plots like Scribble does (I think): #lang racket (require pict plot/pict) (pict->bitmap (plot3d-pict (polar3d (λ (θ ρ) 1) #:color 2 #:line-style 'transparent) #:altitude 25)) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/__dev <http://lists.racket-lang.org/dev> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] release notes
False. On 12/21/2013 07:33 PM, Robby Findler wrote: ∃ relevant(HISTORY.txt) ? Robby On Sat, Dec 21, 2013 at 8:29 PM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: Every existing, relevant HISTORY.txt was updated. :D Neil ⊥ On 12/21/2013 06:08 PM, Robby Findler wrote: Did an appropriate HISTORY.txt file get updated with these? Robby On Sat, Dec 21, 2013 at 5:25 PM, Neil Toronto mailto:neil.toro...@gmail.com> <mailto:neil.toro...@gmail.com <mailto:neil.toro...@gmail.com>__>> wrote: On 12/19/2013 07:41 PM, Robby Findler wrote: Neil \bot: point-label3d * Plot: Added plot/no-gui, plot/pict and plot/bitmap for non-GUI uses (such as documentation building), and point-label3d. Neil \bot: math library improvements (docs in 6525e8f7 other stuff?) * Math: math/flonum exports fast 105-bit precision operations. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev <http://lists.racket-lang.org/__dev> <http://lists.racket-lang.org/__dev <http://lists.racket-lang.org/dev>> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] release notes
Every existing, relevant HISTORY.txt was updated. :D Neil ⊥ On 12/21/2013 06:08 PM, Robby Findler wrote: Did an appropriate HISTORY.txt file get updated with these? Robby On Sat, Dec 21, 2013 at 5:25 PM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: On 12/19/2013 07:41 PM, Robby Findler wrote: Neil \bot: point-label3d * Plot: Added plot/no-gui, plot/pict and plot/bitmap for non-GUI uses (such as documentation building), and point-label3d. Neil \bot: math library improvements (docs in 6525e8f7 other stuff?) * Math: math/flonum exports fast 105-bit precision operations. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/__dev <http://lists.racket-lang.org/dev> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] release notes
On 12/19/2013 07:41 PM, Robby Findler wrote: Neil \bot: point-label3d * Plot: Added plot/no-gui, plot/pict and plot/bitmap for non-GUI uses (such as documentation building), and point-label3d. Neil \bot: math library improvements (docs in 6525e8f7 other stuff?) * Math: math/flonum exports fast 105-bit precision operations. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0, corrected url
* Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests Everything passes, except for the plots with the missing polygons in the docs (which may indicate missing polygons on Windows or Mac OS X in general) and the style issue in the plot docs. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0, corrected url
Yeah, I had that on my list of things to look into. They're produced by this code in "unstable/latent-contract/defthing.rkt": (define (def/value def val . pre-flows) (apply s.nested (s.tabular #:style (s.style 'boxed '()) (list (list (s.nested def)) (list (s.tabular #:style def/value-table-style (list (list "=" val)) pre-flows)) (define def/value-table-style (s.style 'boxed (list (s.table-columns (list (s.style 'plain (list 'top (s.attributes '((width . "0%") (s.style 'plain (list 'top 'left (s.attributes '((width . "100%")) I'm not sure why the tabular with "= val" in it isn't getting the boxed style like everything else. Neil ⊥ On 12/21/2013 03:20 PM, Sam Tobin-Hochstadt wrote: That same documentation has a strange rendering issue with the `= #t` in the various blue boxes. In particular, unlike here: http://docs.racket-lang.org/plot/params.html?q=z-far#%28def._%28%28lib._plot%2Fmain..rkt%29._plot-z-far-axis~3f%29%29 they're not in the blue boxes. I've CC'ed Matthew B. in case this is something he knows more about. Sam On Sat, Dec 21, 2013 at 5:13 PM, Neil Toronto wrote: Some plots in the documentation are missing a polygon. I think it's platform-specific, because I can't reproduce the problem. Examples: First example plot in "1.5 Renderer and Plot Bounds" (look for a light green rectangle) file:///usr/racket-5.91.0.900/doc/plot/intro.html?q=plot#%28part._.Renderer_and_.Plot_.Bounds%29 Last example plot in `plot-z-far-ticks' docs (look for a white hole under the "z" in the legend) http://plt.eecs.northwestern.edu/snapshots/current/doc/plot/ticks_and_transforms.html?q=plot-z-far-ticks#%28def._%28%28lib._plot%2Fmain..rkt%29._plot-z-far-ticks%29%29 Here's a program that renders one of the bad plots like Scribble does (I think): #lang racket (require pict plot/pict) (pict->bitmap (plot3d-pict (polar3d (λ (θ ρ) 1) #:color 2 #:line-style 'transparent) #:altitude 25)) Neil ⊥ _ 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 v6.0, corrected url
Some plots in the documentation are missing a polygon. I think it's platform-specific, because I can't reproduce the problem. Examples: First example plot in "1.5 Renderer and Plot Bounds" (look for a light green rectangle) file:///usr/racket-5.91.0.900/doc/plot/intro.html?q=plot#%28part._.Renderer_and_.Plot_.Bounds%29 Last example plot in `plot-z-far-ticks' docs (look for a white hole under the "z" in the legend) http://plt.eecs.northwestern.edu/snapshots/current/doc/plot/ticks_and_transforms.html?q=plot-z-far-ticks#%28def._%28%28lib._plot%2Fmain..rkt%29._plot-z-far-ticks%29%29 Here's a program that renders one of the bad plots like Scribble does (I think): #lang racket (require pict plot/pict) (pict->bitmap (plot3d-pict (polar3d (λ (θ ρ) 1) #:color 2 #:line-style 'transparent) #:altitude 25)) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0, corrected url
he 'static table' link to see a list of all tar files available] * Mike Sperber - DMdA Tests - Stepper Tests - Signature Tests * David Van Horn - EoPL Tests * Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests * Doug Williams - Additional Plot Tests * Shriram Krishnamurthi Tour: check the tour and generate a new one if needed. [Note: Since this is a v5.91, you will need to edit your .../collects/framework/private/version.rkt file and change `(version)' to `"6.0"'.] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27909: master branch updated
I tried your branch that implements it and saw about 3.5x speedup for the `magnitude*' test. This is of course without Robby's recent first-order contract changes. (I think it's about 3.5x: I tried with magnitude* : Number -> Any first and got 2400ms on the easy tests. I changed it to magnitude* : Number -> Number and got 690ms. Apparently, for an `Any' return type, an `any-wrap/c' contract is generated instead of nothing. If that's much faster to check than `number?', though, the speedup is even better.) I'd love to see this with Robby's recent changes. Hint? Nudge? Please? I didn't see very much speedup with arrays (about 1.2x). Speed tests on the math library's distribution objects were very interesting, though, and indicate why the arrays might not be much faster. Here's my test program: #lang racket (require math/distributions) (define d (normal-dist 0 1)) (printf "pdf d 0~n") (for ([_ (in-range 5)]) (time (for ([_ (in-range 10)]) (pdf d 0 (newline) (define p (distribution-pdf d)) (printf "p 0~n") (for ([_ (in-range 5)]) (time (for ([_ (in-range 10)]) (p 0 (newline) The two tests are equivalent, as `pdf' just pulls the pdf function out of the distribution struct and applies it. In TR, the tests are exactly the same speed (extremely fast). In untyped Racket, on the main branch, the second test is 16x faster, and on your branch, it's 44x faster. (It's still 10x slower than TR on your branch, so again... I'd love to see your changes and Robby's together. :D) Neil ⊥ On 12/12/2013 12:40 AM, Eric Dobson wrote: Removing the return value checking is in the works. It actually is removing all of the checks that would blame typed code, so higher order functions/datastructure get improvements too. It is actually functional the last time I checked, but lacking documentation which is what is holding up merging with mainline. https://github.com/plt/racket/pull/453 On Wed, Dec 11, 2013 at 7:57 PM, Robby Findler wrote: I see that TR's type->contract returns (-> (flat-named-contract (quote Float) flonum?) (flat-named-contract (quote Float) flonum?)) for the type (Float -> Float), but it could return (-> (flat-named-contract (quote Float) flonum?) any) which wouldn't do any result value checking (this being different from any/c as the range of the arrow contract). Robby On Wed, Dec 11, 2013 at 6:18 PM, Neil Toronto wrote: On 12/11/2013 02:49 PM, Neil Toronto wrote: On 12/11/2013 01:55 PM, Stephen Bloch wrote: On Dec 11, 2013, at 2:36 PM, Neil Toronto wrote: numeric primitives implemented in Typed Racket are faster than the same primitives implemented in C. Whoa! How did that happen? Whoa! That's not what I meant! O_o I said "we might be getting close" to that. I haven't tried porting a numeric C primitive to TR yet, but I have a hunch that it'll still be slower. I'll try one now and report what I find. Neil ⊥ I can't figure out why `flsinh' is faster to call from untyped Racket than `sinh'. All my tests with a Typed Racket `magnitude' show calls from untyped code are significantly slower, except in the one case that it computes Euclidean distance. That case is only twice as slow. I've attached the benchmark program. The `magnitude*' function is more or less a direct translation of `magnitude' from "number.c" into Typed Racket. Here's a summary of the results I get on my computer, in milliseconds, for 5 million calls from untyped Racket, by data type. Function Flonum Rational Fixnum Integer Float-Complex --- magnitude* 385 419 378 414 686 magnitude 59 44 40 40 390 The only one that's close in relative terms is Float-Complex. The others just call `abs'. The decompiled code doesn't show any inlining of `magnitude', so this comparison should be good. I'll bet checking the return value contract (which is unnecessary) is the main slowdown. It has to check for number of values. For comparison, here are the timings for running the benchmarks in TR with #:no-optimize: Function Flonum Rational Fixnum Integer Float-Complex --- magnitude* 45 70* 37 102* 318 magnitude 61 45 39 91* 394 * = unexpectedly high Here's what I understand from comparing the numbers: * Except for non-fixnum integers, calling `magnitude' in TR is just as fast as in untyped Racket. I have no idea why it would be slower on big integers. That's just weird. * C
Re: [racket-dev] [plt] Push #27909: master branch updated
On 12/11/2013 02:49 PM, Neil Toronto wrote: On 12/11/2013 01:55 PM, Stephen Bloch wrote: On Dec 11, 2013, at 2:36 PM, Neil Toronto wrote: numeric primitives implemented in Typed Racket are faster than the same primitives implemented in C. Whoa! How did that happen? Whoa! That's not what I meant! O_o I said "we might be getting close" to that. I haven't tried porting a numeric C primitive to TR yet, but I have a hunch that it'll still be slower. I'll try one now and report what I find. Neil ⊥ I can't figure out why `flsinh' is faster to call from untyped Racket than `sinh'. All my tests with a Typed Racket `magnitude' show calls from untyped code are significantly slower, except in the one case that it computes Euclidean distance. That case is only twice as slow. I've attached the benchmark program. The `magnitude*' function is more or less a direct translation of `magnitude' from "number.c" into Typed Racket. Here's a summary of the results I get on my computer, in milliseconds, for 5 million calls from untyped Racket, by data type. Function Flonum Rational Fixnum Integer Float-Complex --- magnitude* 385 419 378 414 686 magnitude 59 44 40 40 390 The only one that's close in relative terms is Float-Complex. The others just call `abs'. The decompiled code doesn't show any inlining of `magnitude', so this comparison should be good. I'll bet checking the return value contract (which is unnecessary) is the main slowdown. It has to check for number of values. For comparison, here are the timings for running the benchmarks in TR with #:no-optimize: Function Flonum Rational Fixnum Integer Float-Complex --- magnitude* 45 70* 37 102* 318 magnitude 61 45 39 91* 394 * = unexpectedly high Here's what I understand from comparing the numbers: * Except for non-fixnum integers, calling `magnitude' in TR is just as fast as in untyped Racket. I have no idea why it would be slower on big integers. That's just weird. * Calling `abs' in Racket is faster than calling `scheme_abs' in C, except on rationals and big integers. * Operating on flonums in Typed Racket, using generic numeric functions, is faster than doing the same in C. Overall, it looks like the TR code is within the same order of magnitude (pun not intended) as the C code. I would love to try this benchmark with either 1) a `magnitude*' with an `AnyValues' return type; or 2) a contract boundary that doesn't check TR's return types for first-order functions. (I managed to make a `magnitude*' with type Number -> AnyValues, but TR couldn't make a contract for it.) Neil ⊥ #lang racket (module typed-defs typed/racket (require math/base) (provide magnitude*) (: magnitude* (Number -> Any)) (define (magnitude* z) (cond [(real? z) (abs z)] [else (define r (abs (real-part z))) (define i (abs (imag-part z))) (cond [(eq? r 0) i] [else (let-values ([(r i) (if (i . < . r) (values i r) (values r i))]) (cond [(zero? r) (exact->inexact i)] [(= i +inf.0) (if (eqv? r +nan.0) +nan.0 +inf.0)] [else (define q (/ r i)) (* i (sqrt (+ 1 (* q q]))])])) ) ;(module test typed/racket #:no-optimize (module test racket (require math/base typed/racket/base (submod ".." typed-defs)) (define x (random)) (define y (/ (random 1) (+ 1 (random 1 (define i (random-integer (- (expt 2 20)) (expt 2 20))) (define n (let: loop : Integer () (define n (random-integer (- (expt 2 128)) (expt 2 128))) (if (fixnum? n) (loop) n))) (define z (make-rectangular (random) (random))) (define-syntax-rule (test-one-arg-fun f x) (begin (printf "(~a ~a)~n" 'f 'x) (for ([_ (in-range 5)]) (time (for ([_ (in-range 500)]) (f x (newline))) (test-one-arg-fun magnitude* x) (test-one-arg-fun magnitude x) (test-one-arg-fun magnitude* y) (test-one-arg-fun magnitude y) (test-one-arg-fun magnitude* i) (test-one-arg-fun magnitude i) (test-one-arg-fun magnitude* n) (test-one-arg-fun magnitude n) (test-one-arg-fun magnitude* z) (test-one-arg-fun magnitude z) ) (require 'test) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27909: master branch updated
On 12/11/2013 01:55 PM, Stephen Bloch wrote: On Dec 11, 2013, at 2:36 PM, Neil Toronto wrote: numeric primitives implemented in Typed Racket are faster than the same primitives implemented in C. Whoa! How did that happen? Whoa! That's not what I meant! O_o I said "we might be getting close" to that. I haven't tried porting a numeric C primitive to TR yet, but I have a hunch that it'll still be slower. I'll try one now and report what I find. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27909: master branch updated
On 12/11/2013 11:07 AM, ro...@racket-lang.org wrote: robby has updated `master' from 542e256206 to c321f6dd0c. http://git.racket-lang.org/plt/542e256206..c321f6dd0c =[ One Commit ]= Directory summary: 37.6% pkgs/racket-pkgs/racket-test/tests/racket/contract/ 5.5% pkgs/ 46.3% racket/collects/racket/contract/private/ 10.0% racket/collects/racket/private/ ~~ c321f6d Robby Findler 2013-12-04 22:35 : | Change contract system so that projections are more first-order friendly Awesome. I've attached some more benchmarks, for `flrational?', `flsinh', `fllog1p', `lg+', and `flgamma'. These functions are pretty representative, and have a range of complexity from trivial to complicated. (For example, `flrational?' is implemented using two flops, and `flgamma' usually does ~50 flops in the range I tested.) Approximate average times in milliseconds for 1 million calls: Function TR Untyped pre-push Untyped post-push -- flrational? 5 322 98 flsinh 55 343 121 fllog1p 47 351 117 lg+ 61 384 154 flgamma 165 521 262 There's also less variance in the timings, probably because there are fewer minor GC pauses during the tests. Not shown on the table: untyped `sinh' calls take 140ms in the same test, so it's now faster to use `flsinh' from `math/flonum' in untyped code, if operating on flonums. Cool. We might be getting close to where numeric primitives implemented in Typed Racket are faster than the same primitives implemented in C. The `flrational?' test is still amazing in TR. The function's two flops get inlined (I checked the decompiled module), which I suppose allows more JIT-level optimizations. The only things I can think of to account for the extra time over TR's now are range/domain checking and boxing flonum return values. I think I remember hearing something from someone (maybe Eric?) at RacketCon about inlining contract checks. Is that in the works? Neil ⊥ #lang racket (require math/flonum math/special-functions racket/unsafe/ops (only-in typed/racket/base :)) (define x (random)) (: bx Boolean) (define bx #f) (define vec (make-flvector 1)) (define n 100) (printf "flrational?~n") (for ([_ (in-range 5)]) (time (for ([_ (in-range n)]) (set! bx (flrational? x) (newline) (printf "flsinh~n") (for ([_ (in-range 5)]) (time (for ([_ (in-range n)]) (unsafe-flvector-set! vec 0 (flsinh x) (newline) (printf "fllog1p~n") (for ([_ (in-range 5)]) (time (for ([_ (in-range n)]) (unsafe-flvector-set! vec 0 (fllog1p x) (newline) (printf "lg+~n") (for ([_ (in-range 5)]) (time (for ([_ (in-range n)]) (unsafe-flvector-set! vec 0 (lg+ x x) (newline) (printf "flgamma~n") (for ([_ (in-range 5)]) (time (for ([_ (in-range n)]) (unsafe-flvector-set! vec 0 (flgamma x) (newline) flrational? cpu time: 4 real time: 5 gc time: 0 cpu time: 4 real time: 6 gc time: 0 cpu time: 8 real time: 5 gc time: 0 cpu time: 4 real time: 6 gc time: 0 cpu time: 8 real time: 5 gc time: 0 flsinh cpu time: 52 real time: 55 gc time: 4 cpu time: 56 real time: 54 gc time: 0 cpu time: 52 real time: 54 gc time: 0 cpu time: 56 real time: 54 gc time: 4 cpu time: 56 real time: 56 gc time: 0 fllog1p cpu time: 48 real time: 46 gc time: 0 cpu time: 44 real time: 48 gc time: 0 cpu time: 48 real time: 47 gc time: 4 cpu time: 48 real time: 47 gc time: 0 cpu time: 48 real time: 47 gc time: 0 lg+ cpu time: 60 real time: 61 gc time: 0 cpu time: 60 real time: 61 gc time: 0 cpu time: 60 real time: 61 gc time: 4 cpu time: 64 real time: 61 gc time: 0 cpu time: 60 real time: 63 gc time: 0 flgamma cpu time: 168 real time: 167 gc time: 4 cpu time: 164 real time: 165 gc time: 0 cpu time: 164 real time: 164 gc time: 0 cpu time: 164 real time: 164 gc time: 4 cpu time: 168 real time: 165 gc time: 0 flrational? cpu time: 316 real time: 315 gc time: 0 cpu time: 316 real time: 314 gc time: 0 cpu time: 328 real time: 328 gc time: 4 cpu time: 324 real time: 326 gc time: 0 cpu time: 328 real time: 327 gc time: 0 flsinh cpu time: 348 real time: 350 gc time: 12 cpu time: 336 real time: 336 gc time: 0 cpu time: 340 real time: 338 gc time: 0 cpu time: 348 real time: 349 gc time: 16 cpu time: 344 real time: 343 gc time: 4 fllog1p cpu time: 348 real time: 347 gc time: 4 cpu time: 352 real time: 354 gc time: 4 cpu time: 348 real time: 349 gc time: 8 cpu time: 348 real time: 347 gc time: 4 cpu time: 360 real time: 359 gc time: 4 lg+ cpu time: 376 real time: 379 gc time: 0 cpu time: 384 real time: 384 gc time: 8 cpu time: 388 real time: 387 gc time: 4 cpu time: 380 real time: 381 gc time: 0 cpu time:
Re: [racket-dev] [plt] Push #27767: master branch updated
On 11/15/2013 11:49 AM, Vincent St-Amour wrote: 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). It's a small one: ~410ms before, ~430 after. (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'. Cool! Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27767: master branch updated
On 11/14/2013 03:22 PM, stamo...@racket-lang.org wrote: stamourv has updated `master' from 44f810aa72 to a87dcc252e. http://git.racket-lang.org/plt/44f810aa72..a87dcc252e =[ 4 Commits ]== Directory summary: 20.3% pkgs/contract-profile/ 39.5% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/ 20.9% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/missed-optimizations/ 17.2% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/ ~~ 0dccecc Vincent St-Amour 2013-11-12 17:40 : | Clarify impedance mismatch between profiler and blame info. : M pkgs/contract-profile/boundary-view.rkt | 15 --- ~~ 04eeeb1 Vincent St-Amour 2013-11-13 18:24 : | Log hidden prng parameter dereferences. : M .../typed-racket-lib/typed-racket/optimizer/hidden-costs.rkt | 8 ~~ 7616e26 Vincent St-Amour 2013-11-14 11:04 : | Add types and optimizations for flrandom and unsafe-flrandom. : A pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/flrandom.rkt M .../typed-racket/base-env/base-env-numeric.rkt | 3 +++ M .../typed-racket/optimizer/float.rkt | 19 ++- M .../typed-racket/optimizer/hidden-costs.rkt| 4 ~~ a87dcc2 Vincent St-Amour 2013-11-14 14:11 : | Log non-optimized fixnum-specific ops as hidden costs. : M .../optimizer/missed-optimizations/fixnum.rkt | 6 +++--- M .../optimizer/tests/fixnum-bounded-expr.rkt | 8 M .../optimizer/tests/invalid-fxquotient.rkt | 2 +- A pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/missed-optimizations/fixnum-no-bound.rkt M .../typed-racket/optimizer/fixnum.rkt | 18 -- =[ Overall Diff ]=== 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) IOW, it appears the optimization only helps when passing in a pseudo-random generator. I suspected this might be the case when I ran a bunch of tests of the math library's sampling algorithms and some of them were a hair slower after updating my Racket repo. The only reason I can think of that this would be the case is if the built-in's parameter retrieval is faster. Anyhow, changing (random) to (unsafe-flrandom (current-pseudo-random-generator)) looks like a pessimization for now. (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.) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] should package "X" imply package "X-test"?
On 10/15/2013 06:40 PM, Robby Findler wrote: Actually, on second thought, I think I'm going to buck the trend here and answer "yes" to the question in the subject line. Two scenarios come to mind: someone hears about some cool new library and then does something like 'raco pkg install math'. Next thing, something goes wrong and they ask about it on a mailing list and get the response "Run this code: (require ...)" which ends up running something from the test suite of that library [1]. In that case, we'd probably like them to have everything related to the library. Second: someone decides to build a library that depends on the, say, the math library and they have to choose what to put in their info.rkt file. They don't want to put math no matter if it includes the tests or not, since they don't to force their clients to install the docs. So they'll put math-lib. In other words, I don't see a lot of value in a pkg name taken up for the lib+docs subset of some (conceptual) pile of code, but I do see value in the "everything" pile and the "non-docs non-tests" pile. So I'd say that the name "X" (from the subject) should mean everything. ... at least for a library. For an app, I'm less clear. Robby [1] this actually happened recently as you probably recall (altho 'test-floating-point' may not be in the math-test pkg) http://lists.racket-lang.org/users/archive/2013-October/059881.html Right. It's in "math-lib" (the `math/utils' module) because it's useful outside of automated testing. Users can run it to find out how reliable and repeatable their floating-point results are on a given system. The rest of the math library tests are more or less system-agnostic. (There's a custodian shutdown test for unloading `math/bigfloat' that I think may be good to test on multiple platforms, but that's more of an automation thing.) I can't imagine asking a user to run them, and if I did, I wouldn't mind asking them to install an extra package first. Are there any other circumstances, besides a package owner asking, that a user would want to run all the tests for a package? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] raco setup errors
When I broke up my packages yesterday, I had to re-run "make" when "raco setup" complained about missing packages. This looks different, though. Maybe you should save the database image? Neil ⊥ On 10/09/2013 10:13 PM, Stephen Chang wrote: Pulled today's commits and got the following errors during raco setup. I'm guessing it's because some dependencies changed. Is there a step I forgot to do? raco setup: --- building documentation --- raco setup: docs failure: query-rows: the database disk image is malformed raco setup: --- installing collections --- raco setup: --- post-installing collections --- raco setup: post-installing: /gui-lib/mred raco setup: post-installing: /gui-lib/racket/gui raco setup: post-installing: /mzcom raco setup: post-installing: /mzscheme/mzscheme raco setup: post-installing: /racket-doc/help raco setup: --- checking package dependencies --- query-rows: the database disk image is malformed context...: /home/stchang/plt/racket/collects/db/private/sqlite3/connection.rkt:369:0: handle-status* /home/stchang/plt/racket/collects/db/private/sqlite3/connection.rkt:330:8 /home/stchang/plt/racket/collects/db/private/sqlite3/connection.rkt:161:4: step method in connection% /home/stchang/plt/racket/collects/db/private/sqlite3/connection.rkt:149:8: loop /home/stchang/plt/racket/collects/db/private/sqlite3/connection.rkt:52:4: query1 method in connection% /home/stchang/plt/racket/collects/db/private/generic/functions.rkt:165:0: query-rows8 /home/stchang/plt/racket/collects/setup/doc-db.rkt:338:3: temp107 /home/stchang/plt/racket/collects/setup/doc-db.rkt:496:2: loop /home/stchang/plt/racket/collects/setup/doc-db.rkt:330:0: doc-db-get-dependencies41 /home/stchang/plt/racket/collects/setup/private/pkg-deps.rkt:317:8: for-loop /home/stchang/plt/racket/collects/setup/private/pkg-deps.rkt:344:2: for-loop /home/stchang/plt/racket/collects/setup/private/pkg-deps.rkt:22:0: check-package-dependencies /home/stchang/plt/racket/collects/setup/setup-core.rkt:59:0: setup-core /home/stchang/plt/racket/collects/setup/setup-go.rkt: [running body] /home/stchang/plt/racket/collects/setup/main.rkt: [running body] /home/stchang/plt/racket/collects/raco/main.rkt: [running body] _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package system, minimal builds and more
On 10/01/2013 07:30 AM, Neil Toronto wrote: On 10/01/2013 09:20 AM, Tobias Hammer wrote: * monolithic math currently math is one big package and installing it pulls in nearly everything through the docs. Is it planned to split it into -lib and -doc? We were waiting for a reason. This is one. I'll try it on my flight home tonight. (Never done any package management before.) Okay, that took longer than I thought. It was much easier than splitting the "plot" package, though... Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27569: master branch updated
On 10/09/2013 05:44 PM, Sam Tobin-Hochstadt wrote: On Wed, Oct 9, 2013 at 7:41 PM, wrote: 0edd7e0 Neil Toronto 2013-10-09 17:40 : | Split "plot" package into five packages : Following some of the other packages, you might want to add a `plot` package that depends on everything except `plot-compat. I did, except it depends on "plot-compat" as well. I'll take that dependency out. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] separate plot library into gui-requiring and non-gui-requiring
Pushed. Included are the plot/pict and plot/bitmap modules, which export `plot' and `plot3d' work-a-likes. The documentation has the details. The only thing left now is to break the package up. *rolls up sleeves* Neil ⊥ On 10/09/2013 12:10 PM, Stephen Chang wrote: Thanks Neil! plot/no-gui sounds fine to me. I'll give it a try after you push. On Wed, Oct 9, 2013 at 12:08 PM, Neil Toronto wrote: I'm splitting up the "plot" package today. Stephen: You'll be able to install "plot-lib", then (require plot/pict) to get a `plot' function work-a-like that outputs picts instead of snips, or (require plot/bitmap) to get one that outputs bitmaps. You could easily make a "plot-no-gui-lib" package that contains only a "plot/main.rkt" that wraps one of those modules, if/when you make a web-only Racket distribution. Anyone: Is it worth the extra complexity to make a "plot-typed-lib" and a "plot-typed-gui-lib"? Or should I put the typed interface in "plot-lib" and "plot-gui-lib"? Also, what's a good name for the module that exports `plot-file', `plot-pict', `plot-bitmap', `plot/dc', and the 3d versions of those functions? Something like plot/no-gui? Neil ⊥ On 10/08/2013 01:08 PM, Robby Findler wrote: I think it is worth having a plot/pict or pict/plot library that doesn't depend on racket/GUI/base (or maybe it would be better to disentangle snips). In any case, we have many others such libraries that turn on avoiding racket/gui/base for exactly this reason. Robby On Tuesday, October 8, 2013, Neil Toronto wrote: On 10/08/2013 11:22 AM, Stephen Chang wrote: Short question: Is there a way to separate the gui-requiring parts of plot from the non-gui-requiring parts? Long question: Many people have expressed pleasant surprise with the plot-evaluating ability of the racket pastebin Sam and I are working on. Most of the effort is due to scribble's nice sandbox evaluation capabilities but to get it fully working, I had to hack the plot library in my racket install. The problem is that plot uses racket/gui/base too eagerly but the server has no display, resulting in a gtk initialization error. I ultimately got around it by just commenting out all the gui parts of plot, knowing that it would never get invoked, but obviously this is an ugly solution. I should say that I don't think plot is at fault. The plot library does lazy-require racket/gui/base but that's not good enough because the laziness has to propagate to other requires that also require racket/gui/base (ie plot/snip) which isnt the case. But this cannot work anyways because lazy-require only works with functions and some of the things imported by plot/snip are classes. I spent awhile trying to separate the gui-requiring parts of plot but was unsuccessful. Maybe the change has to be in racket/gui/base itself (related to PR 12465) I don't really know. I guess I'm just looking for additional insight. Naively, slideshow/pict and 2htdp/draw do not have this problem so it seemed like it should be possible. Right, racket/gui/base is necessary for snips. In all the documentation that uses plots (plot, math, images) I've used the following hack when setting up the evaluators: (eval '(require (rename-in (except-in plot plot plot3d) [plot-pict plot] [plot3d-pict plot3d]))) You could also rename `plot-bitmap' and `plot3d-bitmap'. (The docs use picts because they look better rendered in a PDF.) It wouldn't be hard to make a module that does that and provides everything. (Except possibly `plot-snip', `plot-frame', etc.) I'm reluctant to single out one way of rendering when the GUI isn't available. Picts look nicer when scaled, but bitmaps look nicer when unscaled (plots are subpixel-rendered in this case). Picts take much more time to redraw, but for bitmaps it's just a blit. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/__dev <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] separate plot library into gui-requiring and non-gui-requiring
I'm splitting up the "plot" package today. Stephen: You'll be able to install "plot-lib", then (require plot/pict) to get a `plot' function work-a-like that outputs picts instead of snips, or (require plot/bitmap) to get one that outputs bitmaps. You could easily make a "plot-no-gui-lib" package that contains only a "plot/main.rkt" that wraps one of those modules, if/when you make a web-only Racket distribution. Anyone: Is it worth the extra complexity to make a "plot-typed-lib" and a "plot-typed-gui-lib"? Or should I put the typed interface in "plot-lib" and "plot-gui-lib"? Also, what's a good name for the module that exports `plot-file', `plot-pict', `plot-bitmap', `plot/dc', and the 3d versions of those functions? Something like plot/no-gui? Neil ⊥ On 10/08/2013 01:08 PM, Robby Findler wrote: I think it is worth having a plot/pict or pict/plot library that doesn't depend on racket/GUI/base (or maybe it would be better to disentangle snips). In any case, we have many others such libraries that turn on avoiding racket/gui/base for exactly this reason. Robby On Tuesday, October 8, 2013, Neil Toronto wrote: On 10/08/2013 11:22 AM, Stephen Chang wrote: Short question: Is there a way to separate the gui-requiring parts of plot from the non-gui-requiring parts? Long question: Many people have expressed pleasant surprise with the plot-evaluating ability of the racket pastebin Sam and I are working on. Most of the effort is due to scribble's nice sandbox evaluation capabilities but to get it fully working, I had to hack the plot library in my racket install. The problem is that plot uses racket/gui/base too eagerly but the server has no display, resulting in a gtk initialization error. I ultimately got around it by just commenting out all the gui parts of plot, knowing that it would never get invoked, but obviously this is an ugly solution. I should say that I don't think plot is at fault. The plot library does lazy-require racket/gui/base but that's not good enough because the laziness has to propagate to other requires that also require racket/gui/base (ie plot/snip) which isnt the case. But this cannot work anyways because lazy-require only works with functions and some of the things imported by plot/snip are classes. I spent awhile trying to separate the gui-requiring parts of plot but was unsuccessful. Maybe the change has to be in racket/gui/base itself (related to PR 12465) I don't really know. I guess I'm just looking for additional insight. Naively, slideshow/pict and 2htdp/draw do not have this problem so it seemed like it should be possible. Right, racket/gui/base is necessary for snips. In all the documentation that uses plots (plot, math, images) I've used the following hack when setting up the evaluators: (eval '(require (rename-in (except-in plot plot plot3d) [plot-pict plot] [plot3d-pict plot3d]))) You could also rename `plot-bitmap' and `plot3d-bitmap'. (The docs use picts because they look better rendered in a PDF.) It wouldn't be hard to make a module that does that and provides everything. (Except possibly `plot-snip', `plot-frame', etc.) I'm reluctant to single out one way of rendering when the GUI isn't available. Picts look nicer when scaled, but bitmaps look nicer when unscaled (plots are subpixel-rendered in this case). Picts take much more time to redraw, but for bitmaps it's just a blit. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/__dev <http://lists.racket-lang.org/dev> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] separate plot library into gui-requiring and non-gui-requiring
On 10/08/2013 11:22 AM, Stephen Chang wrote: Short question: Is there a way to separate the gui-requiring parts of plot from the non-gui-requiring parts? Long question: Many people have expressed pleasant surprise with the plot-evaluating ability of the racket pastebin Sam and I are working on. Most of the effort is due to scribble's nice sandbox evaluation capabilities but to get it fully working, I had to hack the plot library in my racket install. The problem is that plot uses racket/gui/base too eagerly but the server has no display, resulting in a gtk initialization error. I ultimately got around it by just commenting out all the gui parts of plot, knowing that it would never get invoked, but obviously this is an ugly solution. I should say that I don't think plot is at fault. The plot library does lazy-require racket/gui/base but that's not good enough because the laziness has to propagate to other requires that also require racket/gui/base (ie plot/snip) which isnt the case. But this cannot work anyways because lazy-require only works with functions and some of the things imported by plot/snip are classes. I spent awhile trying to separate the gui-requiring parts of plot but was unsuccessful. Maybe the change has to be in racket/gui/base itself (related to PR 12465) I don't really know. I guess I'm just looking for additional insight. Naively, slideshow/pict and 2htdp/draw do not have this problem so it seemed like it should be possible. Right, racket/gui/base is necessary for snips. In all the documentation that uses plots (plot, math, images) I've used the following hack when setting up the evaluators: (eval '(require (rename-in (except-in plot plot plot3d) [plot-pict plot] [plot3d-pict plot3d]))) You could also rename `plot-bitmap' and `plot3d-bitmap'. (The docs use picts because they look better rendered in a PDF.) It wouldn't be hard to make a module that does that and provides everything. (Except possibly `plot-snip', `plot-frame', etc.) I'm reluctant to single out one way of rendering when the GUI isn't available. Picts look nicer when scaled, but bitmaps look nicer when unscaled (plots are subpixel-rendered in this case). Picts take much more time to redraw, but for bitmaps it's just a blit. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] What can cause "Interactions disabled"?
I have that preference set to #f, if this is what it looks like in the preferences file: (plt:framework-pref:drracket:show-killed-dialog #f) Apparently, it got set to #f when I unchecked "Show this dialog next time" once after I hit Ctrl-K and DrRacket warned me that I couldn't use the REPL until I re-ran the program. At least, that's how I interpreted the message. Given my interpretation, that seems like an overloaded setting. My mental model of running programs differentiates Ctrl-K and an error, so I expect the message box for Ctrl-K to be different from the error message box. Is that wrong? I'll set it to #t and try the simulation in DrRacket again soon-ish. (For now, I need to use the command line because this is for a paper that's due on Friday.) Thanks for your help! Neil ⊥ On 10/07/2013 11:41 AM, Robby Findler wrote: Then I think that that means that the message came from rep.rkt's no-user-evaluation-message function and that you either should have gotten a dialog with an explanation for why it terminated, or you have the preference 'drracket:show-killed-dialog set to #f. I think that the only two explanations are that 'exit' was called or that your ran out of memory, but it may also be the case that you'd get a dialog with no explanation. This could happen with this program, for example: #lang racket (custodian-shutdown-all (current-custodian)) or this one: #lang racket (kill-thread (current-thread)) Or, it may be the case that you'd get a dialog with no explanation when you ran out of memory, if there's a bug (race-condition or something possibly). I don't see how you'd get the yellow/black warning message without getting a dialog, tho, unless you have that pref set. Not much help, I know. Sorry. Robby On Mon, Oct 7, 2013 at 10:52 AM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: Black on yellow. On 10/07/2013 09:50 AM, Robby Findler wrote: Was it black on yellow or red? Robby On Mon, Oct 7, 2013 at 10:32 AM, Neil Toronto mailto:neil.toro...@gmail.com> <mailto:neil.toro...@gmail.com <mailto:neil.toro...@gmail.com>__>> wrote: I have a long-running random simulation that spits out debug messages. I extrapolated that it would take 20 hours to get 5,000,000 samples, and let it run for a day. Here's what I saw when I returned: Welcome to DrRacket, version 5.90.0.9--2013-10-04(876995d5/d) [3m]. Language: typed/racket [custom]; memory limit: 1024 MB. starting... sample-search-tree returned failure refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f i = 100 refinement-sample-point returned #f refinement-sample-point returned #f [...] refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f i = 2605500 refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f Interactions disabled | 560157:0720.77MB Fear my ASCII art status bar.
Re: [racket-dev] What can cause "Interactions disabled"?
Black on yellow. On 10/07/2013 09:50 AM, Robby Findler wrote: Was it black on yellow or red? Robby On Mon, Oct 7, 2013 at 10:32 AM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: I have a long-running random simulation that spits out debug messages. I extrapolated that it would take 20 hours to get 5,000,000 samples, and let it run for a day. Here's what I saw when I returned: Welcome to DrRacket, version 5.90.0.9--2013-10-04(876995d5/__d) [3m]. Language: typed/racket [custom]; memory limit: 1024 MB. starting... sample-search-tree returned failure refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f i = 100 refinement-sample-point returned #f refinement-sample-point returned #f [...] refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f i = 2605500 refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f Interactions disabled | 560157:0720.77MB Fear my ASCII art status bar. "720.77MB" is what I got after clicking the GC indicator. (Before, it was about 300MB.) There were no command-line messages from DrRacket. I don't think this is an out-of-memory problem. DrRacket has been good about asking for more during other simulations, my limit is set to 1024MB, and I really doubt I'm allocating a 304MB temporary object. I wrote a small program to print 60 debug messages, thinking it was a limit on the number of lines in the REPL, and it ran to completion. For full disclosure: I paused and restarted DrRacket from the command line (fg; ctrl-z; bg) a few times while the simulation was running, so I could use my laptop unplugged without draining the battery. Besides running out of memory, what else could cause a program to halt with "Interactions disabled", and how can I avoid it? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/__dev <http://lists.racket-lang.org/dev> _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] What can cause "Interactions disabled"?
I have a long-running random simulation that spits out debug messages. I extrapolated that it would take 20 hours to get 5,000,000 samples, and let it run for a day. Here's what I saw when I returned: Welcome to DrRacket, version 5.90.0.9--2013-10-04(876995d5/d) [3m]. Language: typed/racket [custom]; memory limit: 1024 MB. starting... sample-search-tree returned failure refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f i = 100 refinement-sample-point returned #f refinement-sample-point returned #f [...] refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f i = 2605500 refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f refinement-sample-point returned #f Interactions disabled | 560157:0720.77MB Fear my ASCII art status bar. "720.77MB" is what I got after clicking the GC indicator. (Before, it was about 300MB.) There were no command-line messages from DrRacket. I don't think this is an out-of-memory problem. DrRacket has been good about asking for more during other simulations, my limit is set to 1024MB, and I really doubt I'm allocating a 304MB temporary object. I wrote a small program to print 60 debug messages, thinking it was a limit on the number of lines in the REPL, and it ran to completion. For full disclosure: I paused and restarted DrRacket from the command line (fg; ctrl-z; bg) a few times while the simulation was running, so I could use my laptop unplugged without draining the battery. Besides running out of memory, what else could cause a program to halt with "Interactions disabled", and how can I avoid it? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package system, minimal builds and more
On 10/01/2013 09:20 AM, Tobias Hammer wrote: * monolithic math currently math is one big package and installing it pulls in nearly everything through the docs. Is it planned to split it into -lib and -doc? We were waiting for a reason. This is one. I'll try it on my flight home tonight. (Never done any package management before.) I suppose this is a good rule of thumb: if your docs make pictures, put them in a separate package. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27446: master branch updated
Nice, and thanks for the explanation. Just to make sure I get it: does this mean fully expanded TR modules are smaller? Does it reduce the number of generated contracts? On 09/08/2013 12:24 PM, Sam Tobin-Hochstadt wrote: Typed Racket has to expand into code that registers the type of each module-top-level identifier in the global environment so that other modules can find the types to typecheck with. For example, this program: #lang typed/racket (provide x) (define: x : Integer 1) expands into (greatly simplified): #lang ... (#%provide x) (begin-for-syntax (declare #'x Integer-rep)) (define-values (x) 1) but what is `Integer-rep`? It needs to be an expression that _constructs_ the internal Typed Racket representation of the `Integer` type. Previously, that looked something like this: (make-Union (sort (list Negative-Fixnum-rep Positive-Fixnum-rep ...))) and so on and so forth for the components, all the way down to base types. You can imagine how this gets quite large, especially for large types. However, this is wasteful, because every Typed Racket program, at type checking time, defines a constant that's the representation of the `Integer` type, right here [1]. So instead of serializing an expression that constructs the same thing as `-Int`, we can just *reference* `-Int` in the expanded code. To make that possible, Typed Racket now builds a hash table [2] mapping types (really, their representations) to identifiers that denote those types. Then the serializer just consults this table [3]. It turns out that base types (but no others) already used basically this mechanism, by storing the identifier *in* the type representation. But that's now obsolete, and thus was removed in my subsequent commit. As a result, the type serialization is much smaller. [1] https://github.com/plt/racket/blob/master/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/types/numeric-tower.rkt#L107 [2] https://github.com/plt/racket/blob/master/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/types/base-abbrev.rkt#L23 [3] https://github.com/plt/racket/blob/master/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/env/init-envs.rkt#L51 On Sat, Sep 7, 2013 at 3:20 PM, Neil Toronto wrote: On 09/06/2013 04:14 PM, sa...@racket-lang.org wrote: 56b372c Sam Tobin-Hochstadt 2013-09-06 14:22 : | Remember types that are defined, and use them in serialization. | | This extends a facility already available for base types, | making that facility no longer strictly needed. | | Shrinks the zo size for the `math` package by almost 1MB. : M .../typed-racket/env/init-envs.rkt| 1 + M .../typed-racket/typecheck/def-export.rkt | 7 +- M .../typed-racket/typecheck/tc-toplevel.rkt| 31 +++--- M .../typed-racket/types/abbrev.rkt | 36 +++ M .../typed-racket/types/base-abbrev.rkt| 12 ++- M .../typed-racket/types/numeric-tower.rkt | 108 +-- Would you mind explaining this a little more? It sounds interesting, and the commit almost has my name in it. :) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27446: master branch updated
On 09/06/2013 04:14 PM, sa...@racket-lang.org wrote: 56b372c Sam Tobin-Hochstadt 2013-09-06 14:22 : | Remember types that are defined, and use them in serialization. | | This extends a facility already available for base types, | making that facility no longer strictly needed. | | Shrinks the zo size for the `math` package by almost 1MB. : M .../typed-racket/env/init-envs.rkt| 1 + M .../typed-racket/typecheck/def-export.rkt | 7 +- M .../typed-racket/typecheck/tc-toplevel.rkt| 31 +++--- M .../typed-racket/types/abbrev.rkt | 36 +++ M .../typed-racket/types/base-abbrev.rkt| 12 ++- M .../typed-racket/types/numeric-tower.rkt | 108 +-- Would you mind explaining this a little more? It sounds interesting, and the commit almost has my name in it. :) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v5.3.6, second call
On 07/26/2013 03:39 PM, Ryan Culpepper wrote: * Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests All pass. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On 07/13/2013 12:56 PM, Matthew Flatt wrote: Here's a big-picture update of where we are in the new package system and the conversion of the Racket distribution to use packages. This message covers [lots of awesome stuff]... Thanks a ton for the update and clarifications, Matthew. I have one question. I maintain 3 collections that will become ring-0 packages. What should I (and others like me) be doing right now in response to the Big Package Shift? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26996: master branch updated
Should I do the same kind of thing with "math/tests" and "plot/tests"?
In general, should everything have a separate tests package?
On 06/19/2013 07:53 PM, ro...@racket-lang.org wrote:
robby has updated `master' from f7a344dc32 to 9df3aa6a94.
http://git.racket-lang.org/plt/f7a344dc32..9df3aa6a94
=[ 2 Commits ]==
Directory summary:
49.7% pkgs/gui-pkgs/gui-lib/framework/tests/
49.7% pkgs/gui-pkgs/gui-test/framework/tests/
~~
28e23fa Robby Findler 2013-06-19 20:02
:
| move framework tests to their own package (but still inside the framework
collection)
:
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/README (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/canvas.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/debug.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/exit.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/frame.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/framework-test (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/framework-test-engine
(100%)
R pkgs/gui-pkgs/{gui-lib =>
gui-test}/framework/tests/framework-test-engine.icns (100%)
R pkgs/gui-pkgs/{gui-lib =>
gui-test}/framework/tests/framework-test-engine.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/group-test.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/handler-test.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/keys.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/load.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/main.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/mem.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/number-snip.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/panel.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/panel-single.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/pasteboard.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/prefs.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/racket.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/search.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/test-docs-complete.rkt
(100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/test-suite-utils.rkt
(100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/text.rkt (100%)
R pkgs/gui-pkgs/{gui-lib => gui-test}/framework/tests/utils.rktl (100%)
~~
9df3aa6 Robby Findler 2013-06-19 20:53
:
| adjust games to use find-relevant-directories instead of
| working directly with collections
|
| also some Rackety
:
M pkgs/games/main.rkt | 44 ++--
=[ Overall Diff ]===
pkgs/games/main.rkt
~~~
--- OLD/pkgs/games/main.rkt
+++ NEW/pkgs/games/main.rkt
@@ -4,24 +4,19 @@
(define-struct game (file name set icon))
-(define gamedirs
- (filter directory-exists?
- (map (λ (x) (build-path x "games"))
- (current-library-collection-paths
-
-(define (get-game gamedir game)
- (let* ([game (path-element->string game)]
- [info (with-handlers ([exn:fail? (lambda (x) #f)])
- (get-info (list "games" game)))]
- [main (and info (info 'game (lambda () #f)))]
- [gamefile (lambda (f) (build-path gamedir game f))])
-(and main
- (make-game
- (gamefile main)
- (info 'name (lambda ()
-(string-titlecase (regexp-replace* #rx"-" game " "
- (info 'game-set (lambda () "Other Games"))
- (info 'game-icon (lambda () (gamefile (format "~a.png" game
+(define (get-game gamedir)
+ (define-values (base name dir?) (split-path gamedir))
+ (define game (path-element->string name))
+ (define info (with-handlers ([exn:fail? (lambda (x) #f)])
+ (get-info (list "games" game
+ (define main (and info (info 'game (lambda () #f
+ (define (gamefile f) (build-path gamedir f))
+ (and main
+ (make-game
+(gamefile main)
+(info 'name (λ () (string-titlecase (regexp-replace* #rx"-" game "
"
+(info 'game-set (λ () "Other Games"))
+(info 'game-icon (λ () (gamefile (format "~a.png" game)))
(define (run-game game)
(define c (make-custodian))
@@ -51,15 +46,12 @@
(run))
(define games
- (apply
- append
- (for/list ([gamedir (in-list gamedirs)])
- (filter values (map (λ (x) (get-game gamedir x))
- (directory-list gamedir))
+ (for/list ([gamedir (in-list (find-relevant-directories '(game)))])
+(get-game gamedir)))
(define game-sets
(let ([ht (make-hash)])
-(for ([g games])
+(for
Re: [racket-dev] [plt] Push #26989: master branch updated
I'm up and running as well. In fact, this was the easiest in-place build, like, ever: just "make -j 8". Thanks for all your hard work, guys. I'm looking forward to seeing how this goes next. Neil ⊥ On 06/19/2013 10:40 AM, Matthias Felleisen wrote: Never mind, path confusion in my shell. I am up and running and with a 6/19 drracket. So far so good. -- Matthias [...] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] updated proposal for moving to packages
On 06/05/2013 08:42 PM, Sam Tobin-Hochstadt wrote: On Wed, Jun 5, 2013 at 8:19 PM, Matthew Flatt wrote: I think we're at the point, though, for you to assess whether this is the right direction. If it looks like a good direction, then the follow-up question is how fast to move. Some possible conclusions: 1. This is the wrong way. 2. This is plausible, but the details are not right or not clear; we should stick with our current repository structure for at least one more release and consider switching after that. 3. This will work, and we should switch right away and start sorting out the details together --- but we should not actually break out into separate repositories until after a release or so. 4. This will work, we should try to switch right away --- AND we should split the repository as soon as possible. I'm mostly in favor of 3, but I'm still unsure about some of the details. I think we won't really converge on these details without moving forward [...] This. Figuring out the details will go 20 times faster when we're all forced to work with them. I'm for #3. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] experiment reorganizing the repo into packages
On 05/28/2013 03:44 PM, Sam Tobin-Hochstadt wrote: On Tue, May 28, 2013 at 5:14 PM, Matthew Flatt wrote: I don't know whether the "-lib"/"-docs" split is worthwhile, but it's part of erring on the side of breaking things apart. Maybe it makes more sense to keep things together and rely on binary packaging to reduce dependencies. Would using binary packaging for that be more complicated? It seems that not splitting the source would keep things simpler for most developers, so I'd lean that way. But it's not a strong opinion. For Typed Racket, it seems worth it in one place, and isn't needed in another. For the core of TR, making it available without docs is useful. I'm less sure about the contents of `typed/*`. I suppose that will depend on whether those packages themselves ship with documentation. For the core of TR, could the uses you're thinking about benefit just as much from a binary-only core TR? (I imagine you mean other packages like `math', which just use the TR language, but I'm not sure.) Also worth noting is that the "unstable" collection does not work nicely as a package --- as should be expected. I created a few "unstable-" packages and imagine many more, but I'm not sure that's the right way to go. I think we should just make all of `unstable` go away as part of this transition. It was mostly a way to work around the monolithic nature of the collections tree, and thus has outlived its purpose. That sounds right to me. So, how does this split correspond to what you expected? (My guess is that this far too fine-grained for some of us, while others will want exactly this kind of flexibility.) I expect `plot' to depend on `math' in the near-ish future. Right now, `math' already depends on `plot' to build its docs. IOW, I expect the sources to be interdependent, but as binaries, `plot' will depend on `math' but `math' won't depend on `plot'. Can the package system handle that, or will I have to merge the two or factor out a common parent? If the package system won't handle it, I'd rather have both the `plot' and the `math' collections in a single `math' package. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR & check-equal?
I use this workaround in the math library, whose arrays are higher-order values that *can* be checked for equality: (require (except-in typed/rackunit check-equal?)) ;; This gets around the fact that typed/rackunit can no longer test ;; higher-order values for equality, since TR has firmed up its rules ;; on passing `Any' types in and out of untyped code (define-syntax-rule (check-equal? a b . message) (check-true (equal? a b) . message)) There's got to be a more general fix along these lines. Neil ⊥ On 05/29/2013 09:19 AM, Robby Findler wrote: Yes: my message is about strange error messages that cause newbies to just conclude that testing TR programs doesn't work. While I can certainly fault someone for coming to this conclusion (and I did) I think only half of the problem is on their side. If they had gotten this message, they might have said "equal? isn't what I want here" and then maybe made some progress. But I do agree with you and if it is hard to get to even this state, then it probably isn't worth pursuing. Robby On Wed, May 29, 2013 at 10:11 AM, Matthias Felleisen mailto:matth...@ccs.neu.edu>> wrote: If TR lived up exactly to the R level of semantics, to wit: > Welcome to DrRacket, version 5.3.4.10--2013-05-29(05524114/d) [3m]. > Language: racket. > > (struct s ()) > > (require rackunit) > > (check-equal? (s) (s)) > > FAILURE > actual: # > expected: # > name: check-equal? > location: (unsaved-editor324 5 2 126 22) > expression: (check-equal? (s) (s)) > > . . Check failure > would you really write a different message to dev? Opaque structures pose a problem for testing and that problem exists at both levels. -- Matthias On May 29, 2013, at 8:02 AM, Robby Findler mailto:ro...@eecs.northwestern.edu>> wrote: > Well, given that replacing check-equal? with equal? (on the typed side) works, then it seems to me that one solution would be to move more of rackunit into TR, or to refactor rackunit to be more friendly to TR. (And if someone is going to work on this, then it would also be great if the error messages from failed test cases were made a bit more legible.) > > Robby > > > On Wed, May 29, 2013 at 6:53 AM, Sam Tobin-Hochstadt mailto:sa...@ccs.neu.edu>> wrote: > That is indeed the correct fix. I'm not entirely sure how to improve > the error message, since the problem in your original code is real. > There's no way the generated contract can tell at runtime that the > values passed to `check-equal?` aren't higher-order, so it has to > conservatively reject the call. Suggestions are certainly welcome. > > Sam > > On Wed, May 29, 2013 at 7:46 AM, Robby Findler > mailto:ro...@eecs.northwestern.edu>> wrote: > > I'm not sure if this should be considered a bug or a feature request (or > > something else, but hopefully one of those two!) so I thought I'd ask here > > before sending in a PR. This program: > > > > #lang typed/racket > > (require typed/rackunit) > > (struct: s ([a : Integer])) > > (check-equal? (s 1) (s 2)) > > > > produces the output: > > > > check-equal?: broke its contract > > Attempted to use a higher-order value passed as `Any` in untyped code: > > # > > in: the 1st argument of > > (recursive-contract > >(->* (Any Any) (String) any/c) > >#:impersonator) > > contract from: (interface for check-equal?) > > blaming: (interface for check-equal?) > > at: /typed/rackunit/main.rkt:20.2 > > > > which is a bit confusing. (As someone who's been around Racket long enough, > > I guessed that sticking #:transparent into the struct declaration would be a > > thing to try, but newcomers seem unlikely to find that workaround.) > > > > Robby > > > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On 05/03/2013 09:12 AM, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: Given that we don't yet even have a prototype of racket2, I'm going to guess that "near" isn't all that near. IMO, there are other big things that we should be focused on going first (notably the package system). +1, since the "damage" would be that people will need to convert uses `match', but that'll be minor compared to `cond'. +1, same reasons. When I don't use match for a while, the first time I use it, I almost always write [else ...] as the last clause. Then I catch myself and replace `else' with `_'. I started being careful about catch-all cases in `match' when I wrote an expression similar to this: (match a [(list x) #t] [else (case (first a) [(6) #f] [else #t])]) got this error: case: bad syntax (not a datum sequence) in: else and was completely baffled for a long time. A few minutes ago, J. Ian Johnson wrote: I've used else as a catch-all binding in match. Yes, it's not the best practice, but I think since I've done it, other people must have done it too. This could annoy them. Do you have an actual use that would *break*? That is, something like (match x ... [else else]) I'll bet almost every use of just `else' as a pattern in the wild doesn't have `else' in the body because it's intended to be a catch-all case. If it does have `else' in the body, it's almost certainly in a `cond' or a `case', which is either an error or hideous style. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3.4
I finally tried this. Very clever!
On 04/23/2013 07:54 AM, Robby Findler wrote:
* Tally Maze: a new game based an enumeration of 2d mazes.
Robby
On Mon, Apr 22, 2013 at 10:16 PM, Ryan Culpepper mailto:ry...@ccs.neu.edu>> wrote:
The release announcement sketch that I have so far is below. Please
mail me new items and/or edits.
--__--__--
mflatt:
- added file-truncate (48e05093)
- mach-o: handle some new load commands (a229f292)
- mach-o: code signing fixes (1744a787)
- scribble/latex-properties: add command-extras (17865bfa)
- ffi/com: improve handling of type-described (79266fcf)
- added scribble/book and scribble/report langs (09d4aa3d)
- add _size, _ssize, _ptrdiff, etc (d46411d3)
- add phaseless modules (899a3279)
- improve complexity of hash-iterate-{key-value} (7a8c2ff0)
- add 'so-mode to system-type (cdf0f6b9)
- add interactive to slideshow (454f4c3f)
- ffi/com repairs, including mysterx compat (6e40caa7)
robby:
- added union-find (33747ec9)
- 2d (bb216d14)
- improved jump-to-def (39e4ac15)
jay:
- various pkg (39ae7a83, 9d3a42f1, 6bf03c12)
dyoo:
- parser-tools (9e0fce22, ???)
- fixed readline (f1e70516)
eli:
- add links to old documentation (250880d2)
- add {take,drop}f, splitf-at, etc (bb17b6a8, 2cdfe18b, 3af72eca)
- make configure install docs in standard place (59b18eec)
ryanc:
- added #:datum-literals (d5fe6021)
- added unstable/macro-testing (1ef38458)
- added unstable/socket (b3afbdd4)
- added #:grammar to defform, etc (293b208a)
sstrickl:
- with-contract improvements (539c25bb)
chrdimo:
- support for multiple blame parties (17e419e7)
- added option contracts (5808b0c4)
bfetscher:
- redex-generator: determine bound order automatically (2a9d4221)
stamourv:
- move optimization coach to planet2 (2c8e5f9a)
asumu:
- make srfi/19 compat with date* (d406e2db)
- separate in/out contracts for parameters (3ddde6a7)
Michael Filonenko:
- extflonums (17b80926)
- extflounum unboxing (840fc9c6)
Eric Dobson:
- AnyValues type (aac25b42)
Tobias Hamer:
- readline improvements (0f6a5833)
- support multiple values in wrap-evt and handle-evt (7e2b443f)
Patrick Mahoney:
- move eopl language to racket (b265e260)
Chris Jester-Young:
- fix srfi/61 use of =>, else (9e93ee26)
Juan Francisco Cantero Hurtado:
- fix configure for openbsd (292c81a8)
William Bowman:
- changed define-union-language to merge nts (b0db8798, 42847ea5)
--__--__--
_
Racket Developers list:
http://lists.racket-lang.org/__dev
_
Racket 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.4, Second Call
* Neil Toronto - Plot Tests - Images Tests - Inspect icons - Math tests All pass. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Packages
I probably shouldn't jump into this because I've barely used the new package system, but here I go... On 04/08/2013 03:17 PM, Eli Barzilay wrote: 50 minutes ago, Jay McCarthy wrote: I don't see how you can start from this place and say, "I am making the elis-awesome-stuff package, so therefore I should *not* create the elis-awesome-stuff directory". It feels contradictory. Probably because you already have a correct mental model of the package system. It's not unreasonable for a new user to think, "Hey, this looks like an easy way to turn my single collection into a package" and get confused by the extra step and frustrated at having to move files around. If I *had* published my awesome stuff as a single big package, then you're right: this would be a fine use. And as I said, this is exactly what the "this-and-that" and "mischief" packages do. But in my case -- and I suspect in many other cases -- I don't have an overall awesome directory of things to publish: I have a pile of things where *some* of them are publishable. So I'd like to be able to publish it quickly with raco pkg create ~/my-stuff/elibot and be done with it. I'll still maintain a single "my-stuff" repository, and I'll still have ~/my-stuff as the only linked (with a "--root") collection directory. I'm gonna jump on the "submit a patch" bandwagon. How hard could it be to make this work: raco pkg create-single ~/my-stuff/elibot and have "create" and "create-single" documented together so that the latter is hard to miss? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Extflonum type for windows
On 03/20/2013 05:14 AM, Michael Filonenko wrote: Meanwhile, it happens that switching the precision at the last minute allows the 32-bit Windows build to support extflonums without using SSE and without affecting flonum arithmetic. Agreed. But since switching the processor "at last minute" every time slows things down a bit, it may be useful to have an option to switch to the extended mode on Win32 just once. That will be useful for us and other users who have SSE and worry about performance. Could you please take a look on the updated pull request which now contains #define-guarded code? I expect this to cause the tests in "math/tests/flonum-tests.rkt" to fail. I think the optimization Matthew mentioned earlier - switching to extended mode once for multiple operations - is a better option. The blocks of code guarded by mode switches should be roughly the same as those that stack-allocate extflonums. IOW, switching modes would mostly coincide with moving extflonums in and out of the heap, which is slow enough that the mode switches would be unnoticeable. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Extflonum type for windows
On 03/18/2013 07:53 AM, Matthew Flatt wrote: The JIT could be improved to avoid switching between consecutive operations, but does the cost of this approach look reasonable as a start? IMO, yes. The only other good options for higher precision are Racket's rationals and `math/bigfloat', which are both much slower. Compared to those, a 2x penalty for addition and subtraction is nothing. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `math' compilation time !!!
On 02/27/2013 01:51 PM, Neil Toronto wrote:
On Sunday, Eli Barzilay wrote:
According to my rough count (and running setup with a "-j 1"),
compiling `math' takes 40% of the whole tree compilation.
I'm running my own timing tests. So far, I've got 917s (about 15
minutes) to compile the math library on this machine, single-threaded. I
need to run a separate test for this, but it looks like the docs took
more than half that time - which is weird. Stand by on that.
Timings below are from these two shell commands:
find . -name 'compiled' -exec rm -rf \{\} \;
time ~/plt-copy/bin/raco setup -j 1
For "math", I executed the commands in the "math" directory. For
"without docs", I added "--no-docs" to the setup command.
With docs:
math: 15m17s = 917s (34%)
all: 45m04s = 2704s
Without docs:
math: 12m38s = 758s (46%)
all: 27m30s = 1650s
IMO, this warrants a "!!!".
Neil ⊥
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] `math' compilation time !!!
On 02/27/2013 09:17 AM, Jens Axel Søgaard wrote: 2013/2/27 Eli Barzilay : On Sunday, Eli Barzilay wrote: According to my rough count (and running setup with a "-j 1"), compiling `math' takes 40% of the whole tree compilation. I'm surprised that nobody finds this disturbing. Maybe it was the lack of bangs in the subject. Disturbing, yes. But besides porting it to non-Typed Racket, is there anything that can be done? Yes. But first, porting to untyped Racket is a nonstarter. Racket's numeric tower is nice to work in until you want to make things fast or guarantee the data types of results. Typed Racket allows the math library to do both and not be crashy. (An example that came up in the implementation of matrix norms: the type of (sqrt (/ 1 x)) isn't Nonnegative-Real if x : Nonnegative-Real, but Complex. Consider x = -0.0. Without TR's complaints, `matrix-norm' would have contained a time bomb.) I'm running my own timing tests. So far, I've got 917s (about 15 minutes) to compile the math library on this machine, single-threaded. I need to run a separate test for this, but it looks like the docs took more than half that time - which is weird. Stand by on that. I tried to make the code typecheck quickly, primarily by using fl- and fx-prefixed functions, whose applications take less time to check because they have fewer cases. We could probably speed up the number theory code a little by creating arithmetic functions with similarly specialized integer types. Beyond that, I don't know what Jens Axel and I could do. One place I know things are slow is checking functions with `case->' types. Such a function is checked once for each case, each time from scratch. A lot of the matrix functions have many case types, to ensure, for example, that TR can prove the inverse of a (Matrix Real) is a (Matrix Real). I have no idea how this could be faster; it just seems like a good place to start. Sam has mentioned that `syntax-parse' is a source of slowness, but he's in the same situation we're in: replacing it with something that checks fewer properties, like `syntax-case', would introduce a lot of errors. Maybe judicious use of cuts would speed some things up? Does `syntax-parse' cache the classes and attributes of syntax objects? Another idea: would it be possible to serialize the results of type checking, or serialize a trace that would enable quick re-checking? If so, we could distribute results or traces with the Racket code. I'll reply later with my full timing results. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Experimenting with generics in TR
On 02/10/2013 06:55 AM, Sam Tobin-Hochstadt wrote:
What is the type of `ops-hash` intended to be here?
There's no valid Typed Racket type. It represents an extensible mapping
from types to ring operations on those types.
Using `case->', it's not too hard to make a mapping from symbols to ring
operations; e.g.
(case-> ('integer -> (ring-ops Integer))
('polynomial -> (ring-ops (polynomial T
...)
But everything that uses a function with that type has to itself have
corresponding cases, so I can't write a function with this type:
ring+ : (All (A) ((ring-member A) (ring-member A) -> (ring-member A)))
It would have to have a huge `case->' type as well, which rules out
separate compilation: `ring+' could operate only on rings it statically
knows about.
This program represents the closest I've gotten to generics using a hash
table of types to ring operations:
#lang racket/load
(module ring-types typed/racket
(provide (all-defined-out))
(struct: (A) ring-member ([value : A] [ops-name : Symbol]))
;; Can't use a struct; gives this error when using `set-ring-ops!':
;; struct/dc: expected chaperone contracts, but field zero has
;; #
;; Fields: zero, add, negate, multiply
(define-type (ring-ops A) (List A (A A -> A) (A -> A) (A A -> A
(module dispatch racket
(require 'ring-types)
(provide set-ring-ops! get-ring-ops)
(define ops-hash (make-hasheq))
(define (set-ring-ops! name ops)
(hash-set! ops-hash name ops))
(define (get-ring-ops name)
(hash-ref ops-hash name (λ () (error 'get-ring-ops
"unregistered ring ~a"
name)
(module defs typed/racket
(require 'ring-types)
(require/typed
'dispatch
[set-ring-ops! (All (A) (Symbol (ring-ops A) -> Void))]
[get-ring-ops (All (A) (Symbol -> (ring-ops A)))])
(set-ring-ops! 'integer (list 0 + - *))
((inst get-ring-ops Integer) 'integer))
(require 'defs)
I (expectedly) get this error:
get-ring-ops: broke its contract
promised: A7
produced: #
with ((inst get-ring-ops Integer) 'integer) highlighted.
Obviously, the contract system can't prove that the (ring-ops A) it
returns has the right type. That's why I asked about an
ultra-super-secret back door.
FWIW, I've managed to get something less than decent working just using
Typed Racket, by including a (ring-ops A) in every (ring-member A); i.e.
(struct: (A) ring-member ([value : A] [ops : (ring-ops A)]))
But the function types in `ring-ops' make `ring-member' invariant. I
want (Polynomial Integer) <: (Polynomial Real).
Neil ⊥
On Sat, Feb 9, 2013 at 9:27 PM, Neil Toronto wrote:
I'd like to play around with implementing generics or type classes in Typed
Racket, but without changing its internals, just to see what it takes. I
think I could get something pretty decent working if I could get the
following program to type:
(define ops-hash (make-hasheq))
(: set-ring-ops! (All (A) (Symbol (ring-ops A) -> Void)))
(define (set-ring-ops! name ops)
(hash-set! ops-hash name ops))
(: get-ring-ops (All (A) ((ring-member A) -> (ring-ops A
(define (get-ring-ops x)
(define name (ring-member-ops-name x))
(hash-ref ops-hash name (λ () (error 'get-ring-ops
"unregistered ring ~a"
name
Of course, I can't. In fact, I can't get this to work by writing
`set-ring-ops!' and `get-ring-ops' in untyped Racket and importing them
using `require/typed', because the contract system can't prove that the `A'
in `get-ring-ops' is the same as the `A' in `set-ring-ops!'.
Is there a secret, hidden escape hatch that would allow me to get functions
with these types and behaviors?
Neil ⊥
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] Speeding up sequence->list
The performance of `sequence->list' came up on this thread: http://thread.gmane.org/gmane.comp.lang.racket.user/16384 `sequence->list' uses the sequence API to make a copy of its input. This can dominate the running time of functions that look like this: (define (f xs) (let ([xs (sequence->list xs)]) ... simple O(n) computation using xs ...)) Also, it seems wasteful to make a copy if `xs' is already a list. I'd like to change the definition of `sequence->list' from this: (define (sequence->list s) (for/list ([v s]) v)) to this, to handle the two most common sequences specially: (define (my-sequence->list s) (cond [(list? s) s] [(vector? s) (vector->list s)] [else (for/list ([v s]) v)])) For vectors, I measure a 3x speedup. For lists, it's of course O(1). It's a semantic change, but I can't imagine anyone relying on this fact: (not (eq? xs (sequence->list xs))) If someone does, [(list? s) (map values s)] would preserve that fact, and is 3x faster in my measurements. Thoughts? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Experimenting with generics in TR
I'd like to play around with implementing generics or type classes in Typed Racket, but without changing its internals, just to see what it takes. I think I could get something pretty decent working if I could get the following program to type: (define ops-hash (make-hasheq)) (: set-ring-ops! (All (A) (Symbol (ring-ops A) -> Void))) (define (set-ring-ops! name ops) (hash-set! ops-hash name ops)) (: get-ring-ops (All (A) ((ring-member A) -> (ring-ops A (define (get-ring-ops x) (define name (ring-member-ops-name x)) (hash-ref ops-hash name (λ () (error 'get-ring-ops "unregistered ring ~a" name Of course, I can't. In fact, I can't get this to work by writing `set-ring-ops!' and `get-ring-ops' in untyped Racket and importing them using `require/typed', because the contract system can't prove that the `A' in `get-ring-ops' is the same as the `A' in `set-ring-ops!'. Is there a secret, hidden escape hatch that would allow me to get functions with these types and behaviors? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Floating-Point Compliance Testing
Excellent test! I can think of two things that could cause the difference: 1. `flexpt' works around `pow' bugs on 64-bit Linux but not 32-bit (Racket can fix this one) 2. 64-bit compile uses SSE instructions, and the SSE unit is better than the FPU There are probably more possibilities. Neil ⊥ On 02/08/2013 11:53 AM, Tobias Hammer wrote: Tested it too and got an interesting result. On a 32bit linux its: +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 so, completely wrong. But on a 64bit Linux its correct if i use the 64bit racket version. When i try the 32bit build i get the wrong results again. I think you can blame it on 32 implementation of racket/libc/compiler or whatever. Not on the actual cpu in use because the hardware was always the same (2 identical computers, identical OS + version, only 32bit in one, 64 in the other). Tobias On Fri, 08 Feb 2013 19:07:53 +0100, Neil Toronto wrote: Back on list. A lot of things point to general sloppiness in either the FPU or C libraries, but I'd like more information just in case. Can you reply with the values of the following expressions on the Athlon? (flexpt -1001.0 -1.3407807929942596e+154) (flexpt -1001.0 1.3407807929942596e+154) (flexpt -0.1 -1.3407807929942596e+154) (flexpt -0.1 1.3407807929942596e+154) (flexpt -744.4400719213812 -1.3407807929942596e+154) (flexpt -744.4400719213812 1.3407807929942596e+154) (flexpt -1.0 -1.3407807929942596e+154) (flexpt -1.0 1.3407807929942596e+154) You should get these values: 0.0 +inf.0 +inf.0 0.0 0.0 +inf.0 1.0 1.0 I think these are cases Racket handles specially instead of handing off to C's `pow' on platforms where we know `pow' handles them wrongly. We might need to ask Matthew to expand that set of platforms. Small rounding errors like this: ((fl*/error -6.87181640380727e-156 2.3341566035927725e-153) 0.7079979032237692) which are only 1 bit off, are probably the cause of these errors: ((fl2log 1.5124390004859715e-308 0.0) 4294967296.220986) ((fl2log1p 3.799205740343036e+246 1.4492752004468653e+230) 549755813887.9473)) `fl2log' and `fl2log1p' are 103-ish-bit logarithm implementations used in certain tricky subdomains of a few special functions. They assume arithmetic is always correct and are very sensitive to rounding errors. You're getting about 65-bit output precision for certain inputs. We can almost certainly blame the FPU because IEEE 754 requires arithmetic to be implemented and correctly rounded. IEEE 754 only *recommends* typical irrational functions. When they're not implemented in hardware, C libraries compute them in software. So I don't know whether these and others are the FPU's or C library's fault: ((flsin 2.5489254492488616e+52) 22637349860729424.0) ((flcos 3.91520018229574e+49) 6369061509154398.0) ((fltan 1.6614020610450763e+21) 9158003261155244.0) ((flexp 16.938769136983012) 7.0) ((flexp 282.52374429474406) 102.0) ((flexp -10.0) 4.0) ((flexp -708.3964185322641) 124.0) These errors come from not doing argument reductions carefully enough. The trigonometric functions probably don't compute x % 2*pi using a high-precision 2*pi when x is large. They seem to be correct enough when x is small, though. The exponential function wasn't tested well at the boundaries of its domain: ((flexp 709.782712893384) +inf.0) 709.782712893384 is (fllog +max.0), and (flexp (fllog +max.0)) should be near +max.0, not (as I suspect) +inf.0. I don't know whether Racket should do anything about these errors. I don't think it would be too hard to do something like Java's StrictMath, but it would take time. In the meantime, don't use the Athlon for serious numerical computation. Neil ⊥ On 02/08/2013 12:13 AM, Laurent wrote: Hi Neil, Interaction in a terminal is attached, using Racket 5.3.2.3. Some details about my machine: Linux 3.2.0-37-generic-pae #58-Ubuntu SMP Thu Jan 24 15:51:02 UTC 2013 i686 athlon i386 GNU/Linux In particular, I use a 32bits Ubuntu 12.04.2 on a 686 processor, if that's of any interest. Cheers, Laurent On Fri, Feb 8, 2013 at 1:15 AM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: On 02/07/2013 12:09 PM, Laurent wrote: On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto mailto:neil.toro...@gmail.com> <mailto:neil.toro...@gmail.com <mailto:neil.toro...@gmail.com>__>> wrote: Today is not that day, but thanks for asking about this anyway. :) On one machine with Ubuntu 12.10, I get no error, but on another machine with Ubuntu 12.04, I get more than 14000 errors, many of them being +inf.0 and other numbers with big exponents (is my machine really that bad?). Is this exactly the kind of reply you want to avoid for now or are
Re: [racket-dev] Floating-Point Compliance Testing
Back on list. A lot of things point to general sloppiness in either the FPU or C libraries, but I'd like more information just in case. Can you reply with the values of the following expressions on the Athlon? (flexpt -1001.0 -1.3407807929942596e+154) (flexpt -1001.0 1.3407807929942596e+154) (flexpt -0.1 -1.3407807929942596e+154) (flexpt -0.1 1.3407807929942596e+154) (flexpt -744.4400719213812 -1.3407807929942596e+154) (flexpt -744.4400719213812 1.3407807929942596e+154) (flexpt -1.0 -1.3407807929942596e+154) (flexpt -1.0 1.3407807929942596e+154) You should get these values: 0.0 +inf.0 +inf.0 0.0 0.0 +inf.0 1.0 1.0 I think these are cases Racket handles specially instead of handing off to C's `pow' on platforms where we know `pow' handles them wrongly. We might need to ask Matthew to expand that set of platforms. Small rounding errors like this: ((fl*/error -6.87181640380727e-156 2.3341566035927725e-153) 0.7079979032237692) which are only 1 bit off, are probably the cause of these errors: ((fl2log 1.5124390004859715e-308 0.0) 4294967296.220986) ((fl2log1p 3.799205740343036e+246 1.4492752004468653e+230) 549755813887.9473)) `fl2log' and `fl2log1p' are 103-ish-bit logarithm implementations used in certain tricky subdomains of a few special functions. They assume arithmetic is always correct and are very sensitive to rounding errors. You're getting about 65-bit output precision for certain inputs. We can almost certainly blame the FPU because IEEE 754 requires arithmetic to be implemented and correctly rounded. IEEE 754 only *recommends* typical irrational functions. When they're not implemented in hardware, C libraries compute them in software. So I don't know whether these and others are the FPU's or C library's fault: ((flsin 2.5489254492488616e+52) 22637349860729424.0) ((flcos 3.91520018229574e+49) 6369061509154398.0) ((fltan 1.6614020610450763e+21) 9158003261155244.0) ((flexp 16.938769136983012) 7.0) ((flexp 282.52374429474406) 102.0) ((flexp -10.0) 4.0) ((flexp -708.3964185322641) 124.0) These errors come from not doing argument reductions carefully enough. The trigonometric functions probably don't compute x % 2*pi using a high-precision 2*pi when x is large. They seem to be correct enough when x is small, though. The exponential function wasn't tested well at the boundaries of its domain: ((flexp 709.782712893384) +inf.0) 709.782712893384 is (fllog +max.0), and (flexp (fllog +max.0)) should be near +max.0, not (as I suspect) +inf.0. I don't know whether Racket should do anything about these errors. I don't think it would be too hard to do something like Java's StrictMath, but it would take time. In the meantime, don't use the Athlon for serious numerical computation. Neil ⊥ On 02/08/2013 12:13 AM, Laurent wrote: Hi Neil, Interaction in a terminal is attached, using Racket 5.3.2.3. Some details about my machine: Linux 3.2.0-37-generic-pae #58-Ubuntu SMP Thu Jan 24 15:51:02 UTC 2013 i686 athlon i386 GNU/Linux In particular, I use a 32bits Ubuntu 12.04.2 on a 686 processor, if that's of any interest. Cheers, Laurent On Fri, Feb 8, 2013 at 1:15 AM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote: On 02/07/2013 12:09 PM, Laurent wrote: On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto mailto:neil.toro...@gmail.com> <mailto:neil.toro...@gmail.com <mailto:neil.toro...@gmail.com>__>> wrote: Today is not that day, but thanks for asking about this anyway. :) On one machine with Ubuntu 12.10, I get no error, but on another machine with Ubuntu 12.04, I get more than 14000 errors, many of them being +inf.0 and other numbers with big exponents (is my machine really that bad?). Is this exactly the kind of reply you want to avoid for now or are you interested in a report? Alrighty, you've piqued my interest. Better send it off-list, though. :) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
