I suppose one cold write !++ and ++! to indicate pre- and post-increment respectively.
I think, I’ll try to find some coding guide lines for Java to see whether they recommend against using ++ in expressions.
Will lazy-require speed up application startup when the application is built as an executable?
I am trying to speed up the startup of my application by using lazy-require for modules which are not needed for the initial window to be displayed (e.g. the module which implements the “Help/About” frame does not need to be loaded until the user selects “help/about” from the menu). While there is an improvement to startup speed when the application is started using racket (e.g. “racket run.rkt”), there does not seem to be any improvement once an executable is built and the executable is run.
Since there is a significant amount of effort to switch to using lazy-require , and my initial tests are not promising, I just wanted to check if this is a valid approach or not…
I think you’re probably right that lazy-require is less effective for reducing startup in an executable created by raco exe. When lazy-require saves time, it’s by not loading module declarations and instead consulting module files on demand; an executable needs all module declarations up front. If instantiating a declared module takes significant time, then lazy-require can still help, but instantiation is not usually the expensive part.
@haasis_noah has joined the channel
Unfortunate. @jsyeo do you know what happened?
Is there a way to get the value of the largest fixnum?
I’m sure someone will reply with a simple constant that exists, but assuming that fix/flo-nums are just tagged, this should at least get you the value on your system if you need it to make forward progress:
(define (max-fixnum)
(letrec ([try (λ (n)
(let ([m (sub1 (expt 2 n))])
(if (fixnum? m)
m
(try (sub1 n)))))])
(try 64)))
For my (64-bit) it looks like 4-bits for tagging, which makes sense for aligning the pointers to 16-byte boundaries, so 60-bit fixnums.
I keep almost adding a function, but then my use case shifts and I avoid the distraction (in that context) after all.
Here’s code from the current “fixnum.rktl” test suite. I think it would be better to have core functions to report this information, though.
(define 64-bit? (= (system-type 'word) 64))
(define (fixnum-width) (if (eq? 'racket (system-type 'vm))
(if 64-bit? 63 31)
(if 64-bit? 61 30)))
(define (least-fixnum) (- (expt 2 (sub1 (fixnum-width)))))
(define (greatest-fixnum) (sub1 (expt 2 (sub1 (fixnum-width)))))
Aha, I’m also working on a “Racket version of Processing”! But I want to make those programs more in the Racket’s idioms instead of the Processing’s.
Great minds think alike :slightly_smiling_face:
Well, I guess including ++ is more about being “feature complete”, rather than expecting it to be used.
I got inspired by the Coding Train videos by Daniel Schiffman. Have you seen some of them?
Is there a standard round function in Racket? (One that doesn’t round to even).
A round-up would be a good thing - as far as I can tell, in most other languages round refers to round to nearest integer and round up on ties.
Seen a lot years before. They are my creative coding 101.
Late response — thanks! Doing this as a full-on parser might actually be the way to go.