[racket-dev] Is there a way to print out all inferred types for a typed racket program?
I'm essentially looking for a dump of the typed AST of a given typed racket program for use in an undergraduate research project. Is there an easy way to get this information? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Is there a way to print out all inferred types for a typed racket program?
No it is not easy. It should all be there in the expanded output. TR stores the type of an expression in a hashtable on the side, see https://github.com/plt/racket/blob/master/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/types/type-table.rkt#L34. So if you did #lang racket (require racket/pretty syntax/kerncase typed-racket/types/type-table) (define prog #'(module tr typed/racket #:no-optimize foo)) (define expanded-prog (expand prog)) (pretty-print (syntax-datum expanded-prog)) (kernel-syntax-case expanded-prog #f ((module _ _ (#%module-begin (module . _) (begin-for-syntax (module* . _)) (begin-for-syntax . _) (#%plain-app _ (_ () body) _) . _)) (type-of #'body))) You should get the value, except that between the time that TR expands the output and typechecks it and the time that it comes back from expansion it has gotten changed so that the hash lookup will not work. You can probably hack the internals of TR to export the original syntax object out a side channel and do the same thing at it should work. You want the fully-expanded-syntax value here: https://github.com/plt/racket/blob/master/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/tc-setup.rkt#L64 On Thu, Sep 19, 2013 at 9:00 AM, John Smith johnsm...@thurn.ca wrote: I'm essentially looking for a dump of the typed AST of a given typed racket program for use in an undergraduate research project. Is there an easy way to get this information? _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Recompiling on wrong version for compiled code
Hi all, Is there some reason the compiler can't either (a) ignore or (b) replace the outdated .zos when it comes across a situation like the following? compiled/html-utils_rkt.zo::0: read (compiled): wrong version for compiled code compiled version: 5.90.0.5 expected version: 5.90.0.9 context...: standard-module-name-resolver standard-module-name-resolver standard-module-name-resolver I just ran into this issue with a webservice I run: I had updated Racket but forgotten to blow away the compiled .zos of the webservice, so when I restarted the service, it repeatedly failed until I went and deleted the .zos by hand. Tony _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Why is current-module-name-resolver taking so much time?
I decided to look at why 'make' with a fully-built install takes a long time, and got a surprising result. First, the 'link-all.rkt' script takes about 17 seconds on my machine, almost all of it in `pkg-install`. I then profiled this, and got the surprising result that the majority of the time is spent resolving module names: [traversing imports] [68] 0.3% standard-module-name-resolver [49] 0.3% temp37 [43]0.9% run [5]3.9% ??? [29] 20.2% parse-loop88 [36] 29.1% for-loop [21] 45.2% [49] 11872(63.2%) 6006(32.0%) standard-module-name-resolver (unknown source) [traversing imports] [51] 31.9% find-col-file [52] 3.5% show-collection-err [54] 2.0% ??? [55] 1.8% [traversing imports] [56] 1.1% ??? [57] 1.0% [traversing imports] [53] 0.9% [traversing imports] [58] 0.8% ??? [59] 0.7% ??? [60] 0.5% split-relative-string [61] 0.5% ??? [63] 0.5% lang:read-syntax [62] 0.5% go [64]0.5% standard-module-name-resolver [49] 0.3% If you're unused to reading `profile` output, it says that 63.2% of the time is spent in `standard-module-name-resolver`, with about half that in the function itself, and half in the functions it calls in turn. I've never seen a profile where this turned up so high, and I'm trying to figure out if there's some way it can be made faster. The only call to (current-module-name-resolver) in the pkg system is on line 1333 of pkg/lib.rkt, which according to the profiler is responsible for fewer than half of this time. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Why is current-module-name-resolver taking so much time?
On Fri, Sep 20, 2013 at 3:48 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: I decided to look at why 'make' with a fully-built install takes a long time, and got a surprising result. First, the 'link-all.rkt' script takes about 17 seconds on my machine, almost all of it in `pkg-install`. I then profiled this, and got the surprising result that the majority of the time is spent resolving module names: The first result of my investigation is that this is getting the value of both `current-load-relative-directory` and `current-directory` every single time it calls `current-module-name-resolver`, which is in the thousands. So I think a bit of time can be saved there. On smaller sets of packages, this seems to make a big difference, on the full set, less so. It's also using exception handling for control flow -- having `current-module-name-resolver` take a failure callback might make this faster as well, although I wasn't about to get a build with that change not to segfault. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
