Re: [racket-dev] change to `raco setup' doc builds and SQLite
Sounds cool. On yesterday's nightly (debian squeeze 64), I had to do a `sudo raco setup` to have the help webpage, otherwise I would get a http 404. Laurent On Sat, Nov 24, 2012 at 4:09 AM, Matthew Flatt mfl...@cs.utah.edu wrote: When `raco setup' builds documentation, it now puts cross-reference keys and dependency information into an SQLite database. So, building documentation now requires that SQLite is installed (on Unixes; SQLite is installed by default on Mac OS X, and Racket includes SQLite on Windows). The changes are all under the hood, but you may notice the difference: * DrRacket's initial footprint is about 50 MB smaller for a 64-bit build. The savings come from not loading all cross-reference information into memory. When you ask for documentation on `cons', DrRacket now consults the database to determine which document might have information on `cons', and so on. Ultimately, cross-reference information must be deserialized from the same kind of out.sxref file as before. A large document like the Reference can have multiple out.sxref files, however, so DrRacket doesn't have to deserialize all of the Reference's cross-references to show information `cons'. * When you have a simple Scribble document like #lang scribble/base Hello and click Scribble HTML, the result is closer to instantaneous. Scribble doesn't have to load (another copy of) all cross-reference information into memory before rendering the document. You get the same improvement when using `raco scribble ++xref-in setup/xref load-collections-xref'. * The document-rendering part of `raco setup' uses a little less memory and runs a little faster. Besides reducing the need to load and re-load cross-reference information, dependency and global duplicate-definition checking is now handled by a database query, so it should scale better. There will almost certainly be some problems, so keep an eye out for broken or suspicious `raco setup' or documentation behavior. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] change to `raco setup' doc builds and SQLite
At Sun, 25 Nov 2012 17:03:31 +0100, Laurent wrote: On yesterday's nightly (debian squeeze 64), I had to do a `sudo raco setup` to have the help webpage, otherwise I would get a http 404. Right -- thanks for the alert! I noticed the same thing, and hopefully the build that is almost finished will fix this problem. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25754: master branch updated
On 11/25/2012 06:24 AM, mfl...@racket-lang.org wrote:
24f358a Matthew Flatt mfl...@racket-lang.org 2012-11-25 06:22
:
| scribble latex: work around `\href{...#...}{...}' as a macro argument
|
| The `math' document build was failing because `\marginpar' does not
| like `\href{...#...}{...}' as an argument.
Does this mean we have nightlies again?
Neil ⊥
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] 'case' using equal?
As a follow-up to the discussion on the users list [http://lists.racket-lang.org/users/archive/2012-November/054973.html], I changed 'case' to use equal? comparison. The diff, including additional tests and a doc change, is at [https://github.com/97jaz/racket/commit/731db72e8b9ddcba7b443478666cc278d2a898d0]. Performance on Clinger's benchmarks has improved since the last time I checked, even with the equal? change, so this must be due to unrelated optimization work. I did not implement the string optimization I mentioned in the thread on the users list. It occurred to me that (a) using string-symbol on the input would allocate if the symbol hadn't already been interned (which may come as a surprise to the user), and (b) the user probably ought to expect lexicographic equality tests if he uses strings, anyway. -Jon _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
Did you try to see if there were any case expressions in our test suites or while building docs or while starting up and fiddling with DrRacket that would behave differently with equal?? Robby On Sun, Nov 25, 2012 at 5:33 PM, Jon Zeppieri zeppi...@gmail.com wrote: As a follow-up to the discussion on the users list [http://lists.racket-lang.org/users/archive/2012-November/054973.html], I changed 'case' to use equal? comparison. The diff, including additional tests and a doc change, is at [https://github.com/97jaz/racket/commit/731db72e8b9ddcba7b443478666cc278d2a898d0]. Performance on Clinger's benchmarks has improved since the last time I checked, even with the equal? change, so this must be due to unrelated optimization work. I did not implement the string optimization I mentioned in the thread on the users list. It occurred to me that (a) using string-symbol on the input would allocate if the symbol hadn't already been interned (which may come as a surprise to the user), and (b) the user probably ought to expect lexicographic equality tests if he uses strings, anyway. -Jon _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
Not in any systematic way, no. When I first implemented the triple-dispatch case, I did look through the racket sources to see how case was actually used there. It turned out that almost all of the uses were small, simple, and, for lack of a better word, monomorphic. Looking back at the users thread, I see what you mean. I'll create a branch that will do what you suggest: evaluate the expression both ways, compare, and complain if the results differ. On Sun, Nov 25, 2012 at 7:28 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Did you try to see if there were any case expressions in our test suites or while building docs or while starting up and fiddling with DrRacket that would behave differently with equal?? Robby On Sun, Nov 25, 2012 at 5:33 PM, Jon Zeppieri zeppi...@gmail.com wrote: As a follow-up to the discussion on the users list [http://lists.racket-lang.org/users/archive/2012-November/054973.html], I changed 'case' to use equal? comparison. The diff, including additional tests and a doc change, is at [https://github.com/97jaz/racket/commit/731db72e8b9ddcba7b443478666cc278d2a898d0]. Performance on Clinger's benchmarks has improved since the last time I checked, even with the equal? change, so this must be due to unrelated optimization work. I did not implement the string optimization I mentioned in the thread on the users list. It occurred to me that (a) using string-symbol on the input would allocate if the symbol hadn't already been interned (which may come as a surprise to the user), and (b) the user probably ought to expect lexicographic equality tests if he uses strings, anyway. -Jon _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
I'm not sure what that error message means, but I think I was thinking of a different strategy. Something like this (but where you deal with 'else' properly and write in '#%kernel (so you have to use the expansion of log-info etc etc)), all staying in the same file. #lang racket (provide (rename-out [new:case case])) (define-syntax (new:case stx) (with-syntax ([line (syntax-line stx)] [fn (syntax-source stx)]) (syntax-case stx () [(_ exp [(d ...) exp ...]) #'(let ([x exp]) (check-em 'fn line x '(d ... ...)) (case exp [(d ...) exp ...] ...))]))) (define (check-em file line val datums) (for ([datum (in-list datums)]) (unless (eq? (equal? datum val) (eqv? datum val)) (log-info (format found a difference in ~a:~a; ~s vs ~s file line datum val) Robby On Sun, Nov 25, 2012 at 8:57 PM, Jon Zeppieri zeppi...@gmail.com wrote: On Sun, Nov 25, 2012 at 7:49 PM, Jon Zeppieri zeppi...@gmail.com wrote: Looking back at the users thread, I see what you mean. I'll create a branch that will do what you suggest: evaluate the expression both ways, compare, and complain if the results differ. This is not turning out to be as simple as expected. I created modules equal-case.rkt and eqv-case.rkt, and then a simple case macro in case.rkt that uses both. However, the build fails at: make xsrc/precomp.h env XFORM_PRECOMP=yes ../racketcgc -cqu ../../../racket/gc2/xform.rkt --setup . --cpp gcc -E -I./.. -I../../../racket/gc2/../include -DOS_X -D_DARWIN_UNLIMITED_SELECT -pthread -fno-common --keep-lines -o xsrc/precomp.h ../../../racket/gc2/precomp.c /Users/jaz/src/racket/collects/s-exp/lang/reader.rkt:1:36: syntax/module-reader: got two #:language keywords in: #:language context...: /Users/jaz/src/racket/collects/syntax/module-reader.rkt:19:14: loop /Users/jaz/src/racket/collects/syntax/module-reader.rkt:35:4: construct-reader standard-module-name-resolver standard-module-name-resolver standard-module-name-resolver /Users/jaz/src/racket/src/racket/gc2/xform.rkt:95:24 /Users/jaz/src/racket/src/racket/gc2/xform.rkt: [running body] make[4]: *** [xsrc/precomp.h] Error 1 make[3]: *** [all] Error 2 make[2]: *** [3m] Error 2 make[1]: *** [3m] Error 2 make: *** [all] Error 2 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
Thanks! With that approach, I can get it to build. -J On Sun, Nov 25, 2012 at 10:11 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not sure what that error message means, but I think I was thinking of a different strategy. Something like this (but where you deal with 'else' properly and write in '#%kernel (so you have to use the expansion of log-info etc etc)), all staying in the same file. #lang racket (provide (rename-out [new:case case])) (define-syntax (new:case stx) (with-syntax ([line (syntax-line stx)] [fn (syntax-source stx)]) (syntax-case stx () [(_ exp [(d ...) exp ...]) #'(let ([x exp]) (check-em 'fn line x '(d ... ...)) (case exp [(d ...) exp ...] ...))]))) (define (check-em file line val datums) (for ([datum (in-list datums)]) (unless (eq? (equal? datum val) (eqv? datum val)) (log-info (format found a difference in ~a:~a; ~s vs ~s file line datum val) Robby On Sun, Nov 25, 2012 at 8:57 PM, Jon Zeppieri zeppi...@gmail.com wrote: On Sun, Nov 25, 2012 at 7:49 PM, Jon Zeppieri zeppi...@gmail.com wrote: Looking back at the users thread, I see what you mean. I'll create a branch that will do what you suggest: evaluate the expression both ways, compare, and complain if the results differ. This is not turning out to be as simple as expected. I created modules equal-case.rkt and eqv-case.rkt, and then a simple case macro in case.rkt that uses both. However, the build fails at: make xsrc/precomp.h env XFORM_PRECOMP=yes ../racketcgc -cqu ../../../racket/gc2/xform.rkt --setup . --cpp gcc -E -I./.. -I../../../racket/gc2/../include -DOS_X -D_DARWIN_UNLIMITED_SELECT -pthread -fno-common --keep-lines -o xsrc/precomp.h ../../../racket/gc2/precomp.c /Users/jaz/src/racket/collects/s-exp/lang/reader.rkt:1:36: syntax/module-reader: got two #:language keywords in: #:language context...: /Users/jaz/src/racket/collects/syntax/module-reader.rkt:19:14: loop /Users/jaz/src/racket/collects/syntax/module-reader.rkt:35:4: construct-reader standard-module-name-resolver standard-module-name-resolver standard-module-name-resolver /Users/jaz/src/racket/src/racket/gc2/xform.rkt:95:24 /Users/jaz/src/racket/src/racket/gc2/xform.rkt: [running body] make[4]: *** [xsrc/precomp.h] Error 1 make[3]: *** [all] Error 2 make[2]: *** [3m] Error 2 make[1]: *** [3m] Error 2 make: *** [all] Error 2 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
I spoke too soon. Now I get a lot of these: /Users/jaz/src/racket/collects/images/private/flomap-transform.rkt:106:2: Type Checker: untyped identifier check-em imported from module case.rkt in: (define-values (x-min y-min x-max y-max) (case bounded-by ((id) (values 0 0 w h)) ((corners) (for*/fold: ((x-min : Float +inf.0) (y-min : Float +inf.0) (x-max : Float -inf.0) (y-max : Float -inf.0)) ((y : Integer (list 0 h)) (x : Integer (list 0 w))) (m... context...: /Users/jaz/src/racket/collects/typed-racket/typecheck/tc-toplevel.rkt:295:0: type-check success /Users/jaz/src/racket/collects/typed-racket/typed-racket.rkt:38:4 /Users/jaz/src/racket/collects/compiler/cm.rkt:353:0: compile-zo* /Users/jaz/src/racket/collects/compiler/cm.rkt:560:26 /Users/jaz/src/racket/collects/compiler/cm.rkt:553:42 /Users/jaz/src/racket/collects/compiler/cm.rkt:518:0: maybe-compile-zo /Users/jaz/src/racket/collects/compiler/cm.rkt:631:2: do-check /Users/jaz/src/racket/collects/compiler/cm.rkt:741:4: compilation-manager-load-handler standard-module-name-resolver success /Users/jaz/src/racket/collects/typed-racket/typed-racket.rkt:38:4 /Users/jaz/src/racket/collects/compiler/cm.rkt:353:0: compile-zo* /Users/jaz/src/racket/collects/compiler/cm.rkt:560:26 /Users/jaz/src/racket/collects/compiler/cm.rkt:553:42 /Users/jaz/src/racket/collects/compiler/cm.rkt:518:0: maybe-compile-zo... Is there a way to give check-em a type for TR without breaking it for non-typed code? On Sun, Nov 25, 2012 at 10:28 PM, Jon Zeppieri zeppi...@gmail.com wrote: Thanks! With that approach, I can get it to build. -J On Sun, Nov 25, 2012 at 10:11 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not sure what that error message means, but I think I was thinking of a different strategy. Something like this (but where you deal with 'else' properly and write in '#%kernel (so you have to use the expansion of log-info etc etc)), all staying in the same file. #lang racket (provide (rename-out [new:case case])) (define-syntax (new:case stx) (with-syntax ([line (syntax-line stx)] [fn (syntax-source stx)]) (syntax-case stx () [(_ exp [(d ...) exp ...]) #'(let ([x exp]) (check-em 'fn line x '(d ... ...)) (case exp [(d ...) exp ...] ...))]))) (define (check-em file line val datums) (for ([datum (in-list datums)]) (unless (eq? (equal? datum val) (eqv? datum val)) (log-info (format found a difference in ~a:~a; ~s vs ~s file line datum val) Robby On Sun, Nov 25, 2012 at 8:57 PM, Jon Zeppieri zeppi...@gmail.com wrote: On Sun, Nov 25, 2012 at 7:49 PM, Jon Zeppieri zeppi...@gmail.com wrote: Looking back at the users thread, I see what you mean. I'll create a branch that will do what you suggest: evaluate the expression both ways, compare, and complain if the results differ. This is not turning out to be as simple as expected. I created modules equal-case.rkt and eqv-case.rkt, and then a simple case macro in case.rkt that uses both. However, the build fails at: make xsrc/precomp.h env XFORM_PRECOMP=yes ../racketcgc -cqu ../../../racket/gc2/xform.rkt --setup . --cpp gcc -E -I./.. -I../../../racket/gc2/../include -DOS_X -D_DARWIN_UNLIMITED_SELECT -pthread -fno-common --keep-lines -o xsrc/precomp.h ../../../racket/gc2/precomp.c /Users/jaz/src/racket/collects/s-exp/lang/reader.rkt:1:36: syntax/module-reader: got two #:language keywords in: #:language context...: /Users/jaz/src/racket/collects/syntax/module-reader.rkt:19:14: loop /Users/jaz/src/racket/collects/syntax/module-reader.rkt:35:4: construct-reader standard-module-name-resolver standard-module-name-resolver standard-module-name-resolver /Users/jaz/src/racket/src/racket/gc2/xform.rkt:95:24 /Users/jaz/src/racket/src/racket/gc2/xform.rkt: [running body] make[4]: *** [xsrc/precomp.h] Error 1 make[3]: *** [all] Error 2 make[2]: *** [3m] Error 2 make[1]: *** [3m] Error 2 make: *** [all] Error 2 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
On Sun, Nov 25, 2012 at 10:50 PM, Jon Zeppieri zeppi...@gmail.com wrote: Is there a way to give check-em a type for TR without breaking it for non-typed code? Yes, you should add an entry to typed-racket/base-env/base-special-env for `check-em`. Note that you'll have to specify which module `check-em` is defined in. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
Thanks! -J On Sun, Nov 25, 2012 at 10:59 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sun, Nov 25, 2012 at 10:50 PM, Jon Zeppieri zeppi...@gmail.com wrote: Is there a way to give check-em a type for TR without breaking it for non-typed code? Yes, you should add an entry to typed-racket/base-env/base-special-env for `check-em`. Note that you'll have to specify which module `check-em` is defined in. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] indentation: the rb tree didn't help, but a hack to stick-to-next-sexp might
At least, as far as I can tell, it does not perform any better than the splay tree. It's actually about a second slower when indenting drracket/private/unit.rkt. Darn it. However, I did find something that's slightly nutty: the following patch appears to greatly improve indentation: https://github.com/dyoo/racket/commit/36670d335d72bb164f3e5dbd97763d69664337a2 This crazy code is motivated by the following snippets from the profiler, when a profile call is wrapped around tabify-selection: loop [34] 0.1% get-backward-sexp method in ...k/private/racket.rkt:425:2 [28] 99.9% [37] 50648(61.1%) 0(0.0%) stick-to-next-sexp? method in ...k/private/racket.rkt:425:2 ... do-forward-match method in ...rk/private/color.rkt:71:2 [50] 99.9% ... get-forward-sexp method in ...k/private/racket.rkt:425:2 [38]17.1% stick-to-next-sexp? method in ...k/private/racket.rkt:425:2 [37] 82.9% [50] 61043(73.6%)53(0.1%) do-forward-match method in ...rk/private/color.rkt:71:2 ... colorer-driver method in ...rk/private/color.rkt:71:2 [66] 99.8% match-forward method in paren-tree% [72] 0.1% If I'm reading the profiler output correctly, this is saying that 61% of the time is being spent in stick-to-next-sexp?, and that in stick-to-next-sexp?, the majority of the time goes through do-forward-match. In the diff above, I made the code speculatively match the text: if it fails, there's no need to call do-forward-match. I reasoned that it looked expensive to call: maybe we can avoid it in the common case. I'm seeing indentation times cut by 50%; I've been staring at this all day, so I don't trust myself yet. Can anyone else confirm that that they see a similarly dramatic improvement in tabification when this hack is in place? I have not committed this yet because it's kludgy code. :) I know the above is not quite the right way to solve the problem, but it seems like it would be worthwhile to do something like this. Of course, it would be better to fix forward-match so it isn't so expensive. _ Racket Developers list: http://lists.racket-lang.org/dev
