Re: [racket-users] How to improve compile times?
On Friday, April 28, 2017 at 2:47:41 AM UTC+8, Dupéron Georges wrote: > Thank you Matthew for the explanation. > > If I understand correctly, > > * Alex Harsanyi's start-up time is due to run-time (phase 0) initialisation > code in the required libraries, including things like (define v > costly-expression), which look like they could be saved as constants, but > actually involve running the expression. > I actively try to avoid this case and I believe the program has little or no such code anymore. However, even when I removed such cases, it did not seem to make much difference. Racket code actually runs fast. > * If Alex Harsanyi's code uses dynamic-require or eval, the phase 1 > initialisation code of the required libraries is executed when eval or > dynamic-require are first invoked. The code does not use any of those things. Also, apart from 3 macros dealing with baking in some API KEYS at compile time, there are no uses of `define-syntax` and friends. > * The size of the bytecode does matter (and switching to Chez scheme's > run-time could hopefully improve that) All the .zo files put together are about 4Mb. I'm not sure if this is big or not? What I'm wondering is if class definition actually runs some code when a module is required, like the code below: (define my-class% (class object% (init) (super-new) (define/public (say-hello) (printf "hello~%" In the end, the start up time does not bother me too much, as it is a GUI application and I spend a lot of time using it after starting it up, so the 7 second wait is acceptable. I have other, more interesting, application features to work on anyway :-) If anyone wants to look at the startup time, or help out with any other development, here is the application: https://github.com/alex-hhh/ActivityLog2 Best Regards, Alex. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Racket v6.9
Hi, ...it looks like, that the REPL still states to be verion 6.8 of racket ? (x86_84/Linux) Cheers Meino On 04/27 03:47, Vincent St-Amour wrote: > Racket version 6.9 is now available from > > http://racket-lang.org/ > > --- > > Security Announcement: > > A security vulnerability in the `racket/sandbox` library and Typed > Racket allowed malicious Typed Racket code to escape the sandbox. > This vulnerability has been fixed in Racket version 6.9. Anyone using > `racket/sandbox` to execute untrustworthy code with access to Typed > Racket should upgrade to version 6.9 immediately. > > While this known vulnerability has been eliminated, it is possible that > similar errors in other installed collections could also be exploited, > although we are not currently aware of any existing vulnerabilities. We > recommend that if you use the Racket sandbox to execute untrustworthy > Racket code, you should also employ additional operating system or > virtual machine level protections. The documentation for `racket/sandbox` > has been updated to list recommended security practices for using the > library. > > Thanks to Scott Moore for identifying this vulnerability. > > --- > > - The official package catalog Web site is revised to have a new user > experience. > > - The Northwestern snapshot site keeps weekly snapshots going up to 12 > weeks into the past. Those provide a middle ground for users who want > access to new features earlier than stable releases, but want less > churn than nightly builds. > > - DrRacket provides a refactoring tool to remove unused requires in > modules. > > - DrRacket's #lang-line customization support works better with buggy > (i.e., in development) languages. > > - The web server's cookie libraries, including "id cookie" authentication, > support RFC 6265. > > - The `db` library supports PostgreSQL's UUID type. > > - The `raco` command lists matching commands when passed an ambiguous > command prefix. > > - The bytecode compiler detects more optimization opportunities for > structure operations. > > - Scribble can produce output via XeLaTeX as an alternative to LaTeX. > > - Scribble supports the `acmart` LaTeX style, for use with ACM > publications. > > - Scribble supports the use of CJK characters in tags. > > --- > > The following people contributed to this release: > Alex Knauth, Alexander Shopov, Alexis King, Andrew Kent, Asumu Takikawa, > Ben Greenman, Daniel Feltey, David Van Horn, Georges Dupéron, Greg > Hendershott, Gustavo Massaccesi, Ingo Blechschmidt, James Bornholt, > James Whang, Jay McCarthy, Jeff Shelley, John Clements, Jordan Johnson, > Leandro Facchinetti, Leif Andersen, Marc Burns, Matthew Butterick, > Matthew Eric Bassett, Matthew Flatt, Matthias Felleisen, Michael Myers, > Mike Sperber, Philip McGrath, Philippe Meunier, Robby Findler, Royall > Spence, Ryan Culpepper, Sam Caldwell, Sam Tobin-Hochstadt, Shu-Hung You, > Spencer Florence, Stephen Chang, Tony Garnock-Jones, Vincent St-Amour, > WarGrey Gyoudmon Ju, Wei Tang, and William G Hatch. > > Feedback Welcome > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Proper non-tail recursion?
On Thu, Apr 27, 2017 at 8:13 PM, Justin Zamora wrote: > On Thu, Apr 27, 2017 at 8:06 PM, Jon Zeppieri wrote: >> >> OCaml does handle tail calls properly. But proper tails calls are not >> the subject of this discussion. The original post was explicitly about >> non-tail calls and how, in Racket, you cannot exhaust the stack >> without exhausting all of the memory available to the program. >> (Whereas in OCaml you can, because it uses a fixed-size stack.) > > > How common is it to have a fixed-size stack? I thought it was normal > practice for the heap and stack to be on opposite ends of memory and to grow > towards each other, so that either can use all available memory. > > Justin It's the norm, and it's typically enforced by the OS. (Of course, you could ignore the system's stack and build your own stack in the heap, but you will pay a performance price.) That's why the technique that Matthias described involves detecting overflows and copying the current stack to the heap. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Proper non-tail recursion?
On Thu, Apr 27, 2017 at 8:06 PM, Jon Zeppieri wrote: > > OCaml does handle tail calls properly. But proper tails calls are not > the subject of this discussion. The original post was explicitly about > non-tail calls and how, in Racket, you cannot exhaust the stack > without exhausting all of the memory available to the program. > (Whereas in OCaml you can, because it uses a fixed-size stack.) > How common is it to have a fixed-size stack? I thought it was normal practice for the heap and stack to be on opposite ends of memory and to grow towards each other, so that either can use all available memory. Justin -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Proper non-tail recursion?
On the other hand, if I recall correctly SML has the same behavior as racket. I think the implementation uses a chain of "stacklets" that are heap allocated. On Apr 27, 2017, 8:07 PM -0400, Jon Zeppieri , wrote: > On Thu, Apr 27, 2017 at 8:05 PM, Hendrik Boom wrote: > > On Thu, Apr 27, 2017 at 07:14:15PM -0400, Jon Zeppieri wrote: > > > On Thu, Apr 27, 2017 at 7:10 PM, Raoul Duke wrote: > > > > i should think any "real" fp would support it. where real is a bijection > > > > with having such support. well, at least necessary if not sufficient. > > > > > > That would be a rather contentious claim, as it rules out OCaml, for > > > example. > > > > I really thought OCaml did tail-recursion properly. Its tutorial > > literature goes th some trouble to explain that it's OK to recurse > > tailfully. What is the truth here? > > > > OCaml does handle tail calls properly. But proper tails calls are not > the subject of this discussion. The original post was explicitly about > non-tail calls and how, in Racket, you cannot exhaust the stack > without exhausting all of the memory available to the program. > (Whereas in OCaml you can, because it uses a fixed-size stack.) > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Proper non-tail recursion?
On Thu, Apr 27, 2017 at 8:05 PM, Hendrik Boom wrote: > On Thu, Apr 27, 2017 at 07:14:15PM -0400, Jon Zeppieri wrote: >> On Thu, Apr 27, 2017 at 7:10 PM, Raoul Duke wrote: >> > i should think any "real" fp would support it. where real is a bijection >> > with having such support. well, at least necessary if not sufficient. >> >> That would be a rather contentious claim, as it rules out OCaml, for example. > > I really thought OCaml did tail-recursion properly. Its tutorial > literature goes th some trouble to explain that it's OK to recurse > tailfully. What is the truth here? > OCaml does handle tail calls properly. But proper tails calls are not the subject of this discussion. The original post was explicitly about non-tail calls and how, in Racket, you cannot exhaust the stack without exhausting all of the memory available to the program. (Whereas in OCaml you can, because it uses a fixed-size stack.) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Proper non-tail recursion?
On Thu, Apr 27, 2017 at 07:14:15PM -0400, Jon Zeppieri wrote: > On Thu, Apr 27, 2017 at 7:10 PM, Raoul Duke wrote: > > i should think any "real" fp would support it. where real is a bijection > > with having such support. well, at least necessary if not sufficient. > > That would be a rather contentious claim, as it rules out OCaml, for example. I really thought OCaml did tail-recursion properly. Its tutorial literature goes th some trouble to explain that it's OK to recurse tailfully. What is the truth here? -- hendrik -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Proper non-tail recursion?
On Thu, Apr 27, 2017 at 7:10 PM, Raoul Duke wrote: > i should think any "real" fp would support it. where real is a bijection > with having such support. well, at least necessary if not sufficient. That would be a rather contentious claim, as it rules out OCaml, for example. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Proper non-tail recursion?
i should think any "real" fp would support it. where real is a bijection with having such support. well, at least necessary if not sufficient. On Apr 27, 2017 4:01 PM, "brendan" wrote: > Dr. Felleisen, > > Thanks for the informative response. Is Racket the only language with > unbounded recursion depth as far as you know? And with respect to > implementation, can you explain the role of the one extra bit that you > mention? > > A number of functional languages targeting platforms like the JVM and > browsers are compromised by the lack of proper tail calls. I often wonder > how much of a performance penalty you would have to pay if those languages > were implemented by CPS-transforming the whole program and running on a > trampoline, except where the compiler could prove constant-bounded call > depth. > > On Tuesday, April 25, 2017 at 9:09:10 PM UTC-4, Matthias Felleisen wrote: > > Brendan, > > > > you’re correct in attributing the idea that the proper implementation of > tail calls is far less important to the Scheme and Racket community. Dybvig > expressed this idea first in a talk titled a Bag of Hacks in the early 90s. > Matthew then at some point said that the true goal is to never run out of > stack space (other than run out of memory period); once we have that proper > tail-call implementation might just be of secondary value. > > > > As for terminology, I think I would say that a language ought to support > ‘unbounded recursion depth’. Unwieldy name. > > > > How is it implemented? When a call is about to exhaust the available > stack space, grab the stack, move it into the heap, start a new one with a > frame that links to the moved stack. If you now also want to implement > continuation-grabing control operators (call/cc, C, F, prompt, etc) you can > do so with one extra bit per stack frame and lazy copying of heap-moved > stacks to the stack proper. > > > > While I am at it, let me advocate PITCH as the slogan for Proper > Implementation of Tail Calls. (Where does the H come from? I added it to > make a complete word.) What many people fail to see is that every language > with function calls has tail positions. The syntax may obscure those with > various superfluous keywords but that does not invalidate the idea. A > tail-call position is a ‘return’ place in a function body. Period. So when > people say “we implement tail calls”, it’s basically nonsense because every > language with function calls must implement tail calls. The question is > whether the evaluation of arguments or the evaluation of function calls > consumes space. And if you love OO design patterns — which is where Scheme > comes from — you must opt into the former not the latter, which means you > must implement tail calls properly. > > > > — Matthias > > > > > > > > > > > > > > > > > On Apr 25, 2017, at 7:32 PM, brendan wrote: > > > > > > Good points: It wasn't strictly true to say that you can make non-tail > calls "without fear." Rather, your memory for continuation frames is shared > with, and just as large as, any other kind of data. > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Proper non-tail recursion?
Dr. Felleisen, Thanks for the informative response. Is Racket the only language with unbounded recursion depth as far as you know? And with respect to implementation, can you explain the role of the one extra bit that you mention? A number of functional languages targeting platforms like the JVM and browsers are compromised by the lack of proper tail calls. I often wonder how much of a performance penalty you would have to pay if those languages were implemented by CPS-transforming the whole program and running on a trampoline, except where the compiler could prove constant-bounded call depth. On Tuesday, April 25, 2017 at 9:09:10 PM UTC-4, Matthias Felleisen wrote: > Brendan, > > you’re correct in attributing the idea that the proper implementation of tail > calls is far less important to the Scheme and Racket community. Dybvig > expressed this idea first in a talk titled a Bag of Hacks in the early 90s. > Matthew then at some point said that the true goal is to never run out of > stack space (other than run out of memory period); once we have that proper > tail-call implementation might just be of secondary value. > > As for terminology, I think I would say that a language ought to support > ‘unbounded recursion depth’. Unwieldy name. > > How is it implemented? When a call is about to exhaust the available stack > space, grab the stack, move it into the heap, start a new one with a frame > that links to the moved stack. If you now also want to implement > continuation-grabing control operators (call/cc, C, F, prompt, etc) you can > do so with one extra bit per stack frame and lazy copying of heap-moved > stacks to the stack proper. > > While I am at it, let me advocate PITCH as the slogan for Proper > Implementation of Tail Calls. (Where does the H come from? I added it to make > a complete word.) What many people fail to see is that every language with > function calls has tail positions. The syntax may obscure those with various > superfluous keywords but that does not invalidate the idea. A tail-call > position is a ‘return’ place in a function body. Period. So when people say > “we implement tail calls”, it’s basically nonsense because every language > with function calls must implement tail calls. The question is whether the > evaluation of arguments or the evaluation of function calls consumes space. > And if you love OO design patterns — which is where Scheme comes from — you > must opt into the former not the latter, which means you must implement tail > calls properly. > > — Matthias > > > > > > > > > On Apr 25, 2017, at 7:32 PM, brendan wrote: > > > > Good points: It wasn't strictly true to say that you can make non-tail > > calls "without fear." Rather, your memory for continuation frames is shared > > with, and just as large as, any other kind of data. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to racket-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Racket v6.9
Racket version 6.9 is now available from http://racket-lang.org/ --- Security Announcement: A security vulnerability in the `racket/sandbox` library and Typed Racket allowed malicious Typed Racket code to escape the sandbox. This vulnerability has been fixed in Racket version 6.9. Anyone using `racket/sandbox` to execute untrustworthy code with access to Typed Racket should upgrade to version 6.9 immediately. While this known vulnerability has been eliminated, it is possible that similar errors in other installed collections could also be exploited, although we are not currently aware of any existing vulnerabilities. We recommend that if you use the Racket sandbox to execute untrustworthy Racket code, you should also employ additional operating system or virtual machine level protections. The documentation for `racket/sandbox` has been updated to list recommended security practices for using the library. Thanks to Scott Moore for identifying this vulnerability. --- - The official package catalog Web site is revised to have a new user experience. - The Northwestern snapshot site keeps weekly snapshots going up to 12 weeks into the past. Those provide a middle ground for users who want access to new features earlier than stable releases, but want less churn than nightly builds. - DrRacket provides a refactoring tool to remove unused requires in modules. - DrRacket's #lang-line customization support works better with buggy (i.e., in development) languages. - The web server's cookie libraries, including "id cookie" authentication, support RFC 6265. - The `db` library supports PostgreSQL's UUID type. - The `raco` command lists matching commands when passed an ambiguous command prefix. - The bytecode compiler detects more optimization opportunities for structure operations. - Scribble can produce output via XeLaTeX as an alternative to LaTeX. - Scribble supports the `acmart` LaTeX style, for use with ACM publications. - Scribble supports the use of CJK characters in tags. --- The following people contributed to this release: Alex Knauth, Alexander Shopov, Alexis King, Andrew Kent, Asumu Takikawa, Ben Greenman, Daniel Feltey, David Van Horn, Georges Dupéron, Greg Hendershott, Gustavo Massaccesi, Ingo Blechschmidt, James Bornholt, James Whang, Jay McCarthy, Jeff Shelley, John Clements, Jordan Johnson, Leandro Facchinetti, Leif Andersen, Marc Burns, Matthew Butterick, Matthew Eric Bassett, Matthew Flatt, Matthias Felleisen, Michael Myers, Mike Sperber, Philip McGrath, Philippe Meunier, Robby Findler, Royall Spence, Ryan Culpepper, Sam Caldwell, Sam Tobin-Hochstadt, Shu-Hung You, Spencer Florence, Stephen Chang, Tony Garnock-Jones, Vincent St-Amour, WarGrey Gyoudmon Ju, Wei Tang, and William G Hatch. Feedback Welcome -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] How to improve compile times?
Thank you Matthew for the explanation. If I understand correctly, * Alex Harsanyi's start-up time is due to run-time (phase 0) initialisation code in the required libraries, including things like (define v costly-expression), which look like they could be saved as constants, but actually involve running the expression. * If Alex Harsanyi's code uses dynamic-require or eval, the phase 1 initialisation code of the required libraries is executed when eval or dynamic-require are first invoked. * The size of the bytecode does matter (and switching to Chez scheme's run-time could hopefully improve that) Concerning the definition of a macro: ;; a.rkt #lang racket (require "b.rkt") v ;; b.rkt #lang racket (require "c.rkt") (provide v) (define v (foo)) ;; c.rkt #lang racket (provide foo) (require racket/function) (define-syntax foo (curry (λ (v stx) (displayln v) #'1) (begin (displayln "XX") (string-append "c" "c" * The "cc" is printed when compiling b.rkt, but not when running a.rkt, nor when compiling a.rkt. * The curry and string-append are executed when compiling c.rkt, when c.rkt is instantiated because it is required by b.rkt, and another fresh instantiation of c.rkt is done when it is transitively required by a.rkt. This can be seen by running raco make c.rkt; raco make b.rkt; raco make a.rkt, and observing that XX is printed each time. * When executing racket a.rkt, no XX is printed unless eval is called at run-time at some point. My conclusions, in terms of performance hints are that: * It is safe to put code within the body of a transformer function (bound to a macro). * Code outside of transformer functions (to define compile-time constants, or the curry in the example above) has a cost when compiling all files which transitively require that module. It also has a one-time run-time cost if/when eval, dynamic-require or something similar is used. * The bytecode size has an impact too. * It is therefore better to avoid requiring too many modules if they are not needed. It would be nice to find a way to detect what code gets executed when a module is required, at the various meta-levels. Maybe running raco cover on an empty file containing only (require some-module) could help? I'm not sure how submodules fit in this picture (the main concerns being the test submodule, and the doc submodule for literate programs). -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] How to improve compile times?
At Wed, 26 Apr 2017 15:04:15 -0700 (PDT), Dupéron Georges wrote:
> However, I'm not sure what operations can cause compile-time code to
> be run in this situation. My (possibly incorrect) understanding is
> that macros are executed only once (when expanding the code), but the
> code to the right-hand-side of a (define-syntax foo
> costly-operation), and the code within a (begin-for-syntax …) will
> both be run each time the module is required.
Each time a module is compiled, the compile-time code for any imported
modules is run in fresh compile-time instantiations of those modules.
("Compile" = "expand" in this context.)
So, given "a.rkt" as
;; a.rkt
#lang racket
(require "b.rkt")
and "b.rkt" as
;; b.rkt
#lang racket
(begin-for-syntax (displayln "b"))
if you use `racket a.rkt` leaving both modules as source, you'll see
printed "b" twice: once when compiling "b.rkt", and once when compiling
"a.rkt". If you use `raco make a.rkt`, you'll also see "b" printed
twice, but then `racket a.rkt` will not print "b".
If you have run `raco make a.rkt` already, then here's a potentially
confusing result:
% racket
Welcome to Racket
> (require "a.rkt")
> 1
b
1
In this case, no "b" is printed to load and execute the runtime part of
"a.rkt". Still, compile-time module instances have been created to
handle further evaluation in the REPL. So, as soon as `eval` is called
by the REPL for the expression `1`, the compile-time parts of "a.rkt"
and "b.rkt" are run. That's why "b" prints, and why it prints so late.
When you've compiled a program to bytecode and then run it, whether any
compile-time code is run depends on whether you use `eval` or
`dynamic-require` or similar.
Another part of the run time is just reading in bytecode, though. The
bytecode-loading part of Racket seems slower than it should be, and
that was one of the things I had planned to rebuild --- but now I'm
hoping that we'll get better load times by swapping Chez Scheme in
place of the current runtime system.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
