Re: [racket-dev] comments on comments on learning Racket
On Sun, Apr 27, 2014 at 1:09 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: ** tab completion must be faster and re-indentation of large parts of files too, if possible. Currently, re-indenting a 500 lines file can take a few seconds. ?? I don't get the Uniform syntax is harder to read comment. More highlighting, hmph? Maybe it's just that he's not used to prefix bracketed syntax. That certainly demands a bit of training. Also, because Racket makes extensive use of long-and-clear words, maybe it is comparable to reading a math formula (non-racket) and reading the same formula using words (racket): If you know how to read a formula (know what all the symbols mean, etc.), it can be much faster than reading the verbose form. ** I do get jealous when I see [(i, j, k) | i - [1..10], j - [i..10], k - [j..10], i^2 + j^2 == k^2] vs (for*/list ([i (range 1 20)] [j (range i 20)] [k (range j 20)] #:when (= (+ (sqr i) (sqr j)) (sqr k))) (list i j k)) Would you be less jealous reading the following? (for*/list ([i (.. 1 20)] [j (.. i 20)] [k (.. j 20)] #:when (= (: i ^ 2 + j ^ 2) (: k ^ 2)) (list i j k)) or is it really the #:when part that you'd have preferred to be treated on par with the rest, as in Haskell? (or the one-liner?) ** Do we need to add these to our library? ;; (X ... - Y ...) X *- [List-of Y] (define (gather-return-values f . s) (call-with-values (lambda () (apply f s)) list)) ;; Nat (X ... - Y ...) X *- Y (define (nth-return-value i f . s) (call-with-values (lambda () (apply f s)) (lambda l (list-ref l i I've been having a need of these functions on several occasions myself too. (Although the names are too long, but maybe just omitting `return` would be acceptable to my taste.) ** Printing is brutally expensive in DrRacket. Is there a way to make it cheaper? (maybe use some buffering, like wait at least 0.2 seconds before printing, instead of printing everything right away?) ;; - [1] What do we call the thing that shows up at the top right? I think Robby calls them the blue-boxes? ;; = PART II ** Why, why must everything be Inferior By Default? We obviously need a 'syntax story' that takes readers directly from define-syntax-rule to syntax-parse, bringing in hygiene only late, when it truly matters to raise expressiveness Why not use `define-simple-macro` and completely ditch `define-syntax-rule` from the guide? He could then have gone from (define-simple-macro (swap x y) ) to (define-simple-macro (swap x:id y:id) ) in no time. ** For some reason I was thinking that indentation information is somehow stored with functions/macros themselves. I was wrong. We discussed this years ago. Hmph, he thought so too. I'd also have preferred that (but it's easier to say than to do, obviously). This would allow users to define their own indentation rules for their own forms, and possible re-define it for old forms, but that is more debatable. Thanks to submodules, it could be loaded only when used, e.g. by DrRacket. ** I'm afraid that with the level of flexibility Racket allows, I'll never get to writing an actual program – most likely I'll be spending my time improving Racket itself (well, or at least changing it to suit my tastes). Well, I went there when I was young and saw macros. Who hasn't? I remember the time when I first thought Oh my, Racket is the most powerful language in the world!. Quite a enlightenment moment. On Sun, Apr 27, 2014 at 2:38 AM, Sam Tobin-Hochstadt sa...@cs.indiana.eduwrote: Ok, I think we agree then. What I'm proposing is that new DrRacket installations should start in a mode where `#lang racket (+ 3 4)` works, which is not currently the case. Completely agree on that. Also, maybe the Language preferences should be accessible from the Edit/Preferences panel, or at least be listed right under, in Edit/Language preferences. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Compile racket without native compare-and-swap support?
I'm trying to compile Racket 6.0 on OpenBSD/hppa but the compilation fails because there is not support for CAS on OpenBSD/hppa. Is it possible compile racket on platforms without atomic CAS?. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compile racket without native compare-and-swap support?
At Mon, 28 Apr 2014 00:58:48 +0200, Juan Francisco Cantero Hurtado wrote: I'm trying to compile Racket 6.0 on OpenBSD/hppa but the compilation fails because there is not support for CAS on OpenBSD/hppa. Is it possible compile racket on platforms without atomic CAS?. Does it help to use --disable-places --disable-futures as arguments to `configure`? _ 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 mfl...@racket-lang.org 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 mfl...@racket-lang.org 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] [plt] Push #28633: master branch updated
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`. _ Racket Developers list: http://lists.racket-lang.org/dev
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
