@dthien As @lexi.lambda mentioned, there’s a readtable extension mechanism that can do this. Here’s the introduction from the guide: http://docs.racket-lang.org/guide/hash-reader.html#(part._readtable)

@dthien If <decimal>*[.<decimal>*] is the only number format you want, I think the easiest is to write your own read-decimal-number that first reads in a string, then calls string->number.

The standard reader will accept numbers like 1##4 etc.

(evaluates to 1004 fwiw)

Once you’ve implemented my-read-number, extending read-syntax is as easy as: (define my-readtable (apply make-readtable (current-readtable) (for/fold ([lst null]) ([d (in-string "0123456789")]) (list* d 'non-terminating-macro my-read-number lst)))) (parameterize ([current-readtable my-readtable]) (read-syntax ...))

Thanks all for the help!

Quick pict question: I’ve constructed an image using a bitmap and a pin-over, roughly as follows: (pin-over (bitmap "foobar.png") x y (a-translucent-filled-flash-pict)). My resulting image has 2x the dimensions of the original PNG image, as if it’s being rendered in hi-dpi or something. I’m curious, how can I avoid this expansion factor?

I looked at the current-expected-text-scale, but it returns (1 1), so I don’t think that’s the multiplier I’m seeing

what are the dimensions of the flash?

Smaller than the png, by a lot. (The png is 1368x764, or whatever that typical screen size is, and the flash is 90x50)

I don’t absolutely need to use pict here; I could use 2hdtp/image instead. But it was easier to find the shapes I wanted in pict…

@blerner this program produces the same answer for both for me: #lang racket (require pict pict/flash) (define x 100) (define y 100) (define c (bitmap "cilk.png")) (define v (pin-over c x y (filled-flash 50 50))) (pict-width c) (pict-width v)

do you have a hi-DPI screen?

@samth yes, I do. I was surprised by this behavior because when I use 2htdp/image (in other scribble documents), I don’t ever see hidpi scaling.

what’s the pict-width of the various components?

also this is almost certainly a bug in racket/draw

unless the issues are not apparently until you display the image in which case the bug is in racket/gui

I’ll check in a moment (an not on that computer yet). And it seems odd to me, in the sense of nondeterministic builds, that such an environmental feature could be incorporated from the same command line invocation

No, I’m generating HTML and loading it in a browser

Not using drr for this at all

ah

then that makes it seem like the bug is in racket/draw

The dimensions of the png according to pict-width and pict-height are 1366x728. The dimensions of the flash are 75.0x30.83017… The dimensions of the final pin-over are 1366x728.

The dimensions of the final pict#.png are 2744x1468

which are just slightly bigger than 2x the original png

can you convert the pict to png manually (not using scribble, instead using convert) and see if it’s the same result?

? using the command line utility?

or is convert a Racket function too?

no, using the convert function from file/convertible

ok, lemme try that

my guess is that something is calling convert with png@2x-bytes

once I call convert with ’png-bytes, how do I dump that into a file from within my scribble doc? (I don’t want to figure out how to extract this to a standalone file yet, not least because I don’t want to vary the scribble environment to a racket one and change two variables at once)

@blerner I explicitly want to try the minimal reproduction, ie a racket environment

ah, ok. that’ll take me a bit. hold, please…

my guess is that you get exactly the results you’re seeing if you use convert with png@2x-bytes

Is there an easy way, once I’ve got the png-bytes and png@2x-bytes, to examine their width and height from DrR, or do I need to save them to files and look at them in a browser?

you can just do bytes-length

but not really

you could convert them to a bitmap somehow

i recommend saving them to a file

Is there a bytes->file counterpart to file->bytes?

write-to-file

close; that seems to write it out as a string. but I tried with-output-to-file/write-bytes, and that combo seems to suffice… anyway: the result of (convert the-pict 'png-bytes) has dimensions 1366x728. The result with 'png@2x-bytes has dimensions 2732x1456 — exactly double, and not identical to the results from scribble

(It appears scribble stuck a few pixels of transparent border around the image, I don’t know why)

(then scribble explicitly sets a margin of –3px all around the image, and explicitly sets its width and height to 1372x734, so the browser scales the image back down to the size it “should” be)

ISTM that the png@2x-bytes is coming from current-render-convertible-requests, and maybe picts know how to respond to the 2x request, but 2htdp/images don’t, and that’s why the latter happen to work out “as expected”, but picts show up doubled? (I don’t grep png@2x-bytes anywhere near files that seem related to 2htdp/image, but I do see png-bytes in gui-lib/mrlib/image-core.)

We are using the handin server together with some of our own design recipe checking material. We are running into a very strange problem with the sandbox evaluator. In the sandbox evaluator the following expressions don’t all produce true.

(equal? (* 3 3.3) 9.9) ; produces false

(= (* 3 3.3) 9.9) ; produces false

(=~ (* 3 3.3) 9.9 .001) ;produces true

The handin server creates the evaluator with a byte-stream, and the documentation talks about it expecting to get any additional code to evaluate in that same form. Which made me think perhaps there was a printing/reading thing going on here. But I can’t see in the code where that would be happening.

Any ideas?

@gregor.kiczales If you just do the calculation (* 3 3.3) you can see you get 9.899999999999999 which is not equal to 9.9 which I think is why the first fails. The same goes for the second, and the third is true because it checks that the numbers are within a range of each other 0.001 of each other in this case (which the numbers are)