the writer part would probably be implementable with something like that, but really the API should look like a simple function and it should be up to the #lang implementation whether to use something like parser-tools to implement that function
this is on my mind lately because it’s the only way I can think of to get my resyntax project to work on non-s-exp languages
speaking of which: made another attempt at a cleanup pull request! this time in the main racket repository https://github.com/racket/racket/pull/3689
This is very nice!! I like how many case-lambda have been quite simplified.
Seems maybe worth doing, but I’d rather invest my time in improving the let-to-define rules
I’m considering restricting the rules to only fire when they eliminate let forms entirely, so that the pull requests I make with those rules are more obviously useful and require less review effort
I wonder whether the original lambda was chosen in order to reduce the indentation?
could have just formatted it like this instead then: (define (make-embedding-executable
dest
mred?
verbose? ...)
...)
True.
@telepopsound has joined the channel
JavaScript floating point is IEEE–754. Is that true of Racket as well? I’ve been doing a lot of work with trigonometric functions lately and I get some different results depending on whether I’m using JavaScript or Racket. Unfortunately I only notice there’s a problem after a long chain of calculations. For example, if I’m calculating the great circle distance between two points just less than 100km apart, in one environment I might get 97.1km and in another 96.8km, using the same algorithm. This comes up in my test cases, so I’m trying to figure out where things start to diverge. I’ll have to explore what Racket’s test cases are for trigonometric functions, because I’m sure they exist. One difference is I use exact numbers when that makes sense in Racket, which is not part of JavaScript’s model, Racket’s numeric tower generally being more sophisticated. It’s one of those situations where I’m trying to figure out which system is right and where the results start to diverge and what should I do about it.
Out of curiosity, would using the the Chez version of call/cc to implement escaping be safe? That is, is it safe to use Chez call/cc to capture a continuation and invoke it if both happen in the same OS thread?
Yes, it is IEEE–754. Likely the difference is in various math functions, such as exp or sin, which are not specified in IEEE 754.
Yes, that should be safe. (It doesn’t even have to be the same OS thread.)
@pavpanchekha A job for Herbie?
Okay, thanks!
Hi @gknauth I’m kinda the floating point guy around here. I would expect Racket’s answer to be, on average, a little more accurate, and can give you details if you want.
Herbie, linked above, could help rewrite your computation into a generally more accurate form. Maybe! Let me know if it doesn’t work :slightly_smiling_face:
@gknauth Also, check out https://docs.racket-lang.org/math/bigfloat.html It’s useful to figure which of the two implementations are most precise.
Thanks everyone. I’ll check all these things out. Basically I’ve been working from examples on this page https://www.movable-type.co.uk/scripts/latlong.html and this page https://www.movable-type.co.uk/scripts/latlong-vincenty.html and my results were slightly different. I also have lots of material from an expert just about everyone cites (John P. Snyder), but first order of business, I need my tests to be accurate so I can verify my computations are within promised ranges of accuracy. An interesting journey for sure. Thanks again.
Herbie looks awesome BTW.
Thanks!
is there a way to get the line number of where the print statement is? similar to rusts dbg!() macro? I have lots of (println) statements littered everywhere and its a pain to find them
@jestarray with macros, yes. there’s a few packages that add handy debugging macros, like the debug package
to use it, change your #lang <whatever> to #lang debug <whatever>, then stick #R in front of expressions you want to see
#lang debug racket/base
(define x #R(+ 1 2 3)) prints out: (+ 1 2 3) = 6
if you use #RR or #RRR instead of #R, you’ll get more information. #RR gives you line numbers: (+ 1 2 3) = 6 on line 2
(to install, run raco pkg install --auto debug)
oh this is great all my time with (define (dbg x) (pretty-print x) x)… a waste
I’ve noticed the following change moving from 7.9 CS to 8.0. The following program which uses the ffi, works when run from racket but I get “internal error: terminated in atomic mode!” when running raco test: ☞ cat entry.c
void (*error_handler)();
void entry() {
error_handler();
}
☞ cat small.rkt
#lang racket
(require ffi/unsafe)
(define libt.so (ffi-lib "entry.so"))
(define entry
(get-ffi-obj 'entry libt.so (_fun -> _int64)))
(set-ffi-obj! "error_handler" libt.so _pointer
(function-ptr (λ () (raise 'err))
(_fun -> _void)))
(with-handlers ((symbol? identity))
(entry))
☞ gcc -c entry.c -o entry.o
☞ gcc -shared entry.o -o entry.so
☞ racket small.rkt
'err
☞ raco test small.rkt
raco test: "small.rkt"
'err
internal error: terminated in atomic mode!
Callbacks in Racket CS are always in atomic mode. That is indeed a difference compared to BC.
And an exception doesn’t end atomic mode.
But… this was working in 7.9 CS. Also why does raco test make a difference?
Yes, this did change since v7.9.
I think raco test ends up doing something that isn’t allowed in atomic mode.
Getting escapes in callbacks to work in Chez Scheme turns out to be tricky. Possibly a new ffi/unsafe library should provide better support for it.
To put things another way, it didn’t really work in v7.9, but there were fewer constraints in place to help highlight when you’re entered a bad state.
Thanks. So adding a call to end-atomic in the handler is what I want here?
That will avoid the error in this case, but it’s not really the right change.
There’s an example of something that can work in readline/rktrl.rkt.
It’s complicated, and the essential ingredient is that it creates a new OS thread to isolate the call and callback from Racket threads.
at least in my particular case, when the callback is invoked, I’m done with the library, if that simplifies things.
:eyes:
oh boy
I’ll extract the relevant part of that code.
thanks Matthew. That code is beyond my level.
I think the part you need is much simpler, because you don’t need the callback to be in non-atomic mode, which is the case for readline.
Hm… a relevant facet of the readline code, though, is that it works at the level of the Chez Scheme FFI. I don’t think I can make it work on the outside of the Racket FFI layer (i.e., without changing the Racket FFI).
I started to think more about why I haven’t had to solve this simpler problem before, and that lead me to relevant code in “draw-lib/racket/draw/unsafe/callback.rkt”.
It turns out that the (enable-interrupts) there is no longer needed (which is consistent with the comment about this being fragile). Probably this code should be part of the core FFI.
Meanwhile, assuming you need things to work earlier, that’s reasonable code to use for now.
OK, thanks for your help.
Today I learned that splicing syntax classes can be spliced into templates without using ellipses (define-splicing-syntax-class three-forms
(pattern (~seq _ _ _)))
(syntax-parse #'(a b c d e f g h)
[(triplet:three-forms rest ...)
#`(TRIPLET #,@#'triplet REST rest ...)])
;; result: (TRIPLET a b c REST d e f g h) The #,@#'var part was the part I didn’t realize would work. I initially tried TRIPLET triplet … REST rest … and when that didn’t work I assumed it wasn’t possible.
It’d be nice if there were a tidier way to use splicing syntax classes in templates. I generally use #'(foo {~@ . var} bar), which isn’t great. I find the #,@#'var to be rather noisy-looking.
(I generally don’t use ellipses to splice in a splicing syntax class if it isn’t itself defined with an ellipsis pattern. Now that I think about it, I can’t really explain why I do that, but I think it has to do with clarifying, in the template, how I think about the grammar.)