Is it possible to get a conversion from slideshow pixels to your OS+Monitors pixels?

Like, as a function or just a number.

I ask because I need to convert a slideshow rect into an interactive rect.

@mflatt or @robby one of you might know?

I see size-in-pixels, but that looks like its going the other way

Interactive’s argument gets a frame. Fill it with a canvas. The canvas will be the right size

I don’t believe you have to do any conversion.

At least I don’t.

Interesting. Do you think that is also true for an opengl canvas?

(I say that because I’m getting OpenGL contexts of a different sizes.)

Depending on the pixel density of the monitor I’m using.

Where a lower pixel density producers a smaller image…

(Or larger, I forget which way is which, but either way, it is consistent.)

Ah, higher is smaller.

I haven’t tried opengl

Alright, thanks anyway. :slightly_smiling_face:

@leif The canvas% class provides a get-gl-client-size method

You can compare that result to the get-client-size result

@mflatt Oh cool thanks.

@mflatt oh ineresting, they appear to be the same numbers.

Its still kindof odd I only get this problem with slideshow. Like when I use a canvas outside of slideshow it is scaled as expected.

@mflatt According to both get-gl-client-size and get-client-size, the size of the canvas% is 450x300

BUT, the actual amount of pixels given ~1.5x as much, at about 600x400

So it looks like get-client-size is still giving me the scaled amount, rather then the actual physical amount.

Odd…even get-scaled-client-size returns 450x300.

@mflatt AH, okay, I got it.

It looks like the interactive call actually allocates a frame that can have a different resolution than the one you requested.

And so you should base it off of the given width and height, rather than the one you requested.

That worked. Thanks.

is there a faster way to read from an input port until a nul byte besides looping with read-byte?

I don’t know if that is slow, per se, but I’m not sure if there is a better way

I guess read-bytes-avail!* could be faster if I really needed maximum speed, but that would make it possible to over-read, while read-line only ever reads up to a newline?

Yeah, my recollection is that reading a byte at a time is pretty slow in Racket, comparatively. A fast-as-possible solution (without over-reading) might involve peak-bytes-avail!… maybe… Haven’t tried it.

it probably doesn’t matter much for what I’m working on, since this is just a little script I’m running myself, but it would be nice to shave this yak :)

I think the easiest way to do it, from a programming-effort POV, might actually be to use a regexp.

yes, (regexp-match (byte-pregexp #"^([^\0]*)\0") port) seems to work, and it’s definitely fast enough for my needs :)

Is it just me or is the #irc bridge not actually working?

@asumu I think it’s been semi-broken for a while, with intermittent spurts of actually working

does anyone know who maintains it?

Is there any way to run code right before a module instance gets collected?

I don’t care if it doesn’t get run and the program stops, I just want to inform some FFI code that a closure that was once available no longer is.

About all I got right now is have a will executor attached to a variable in the module, and hope that it will only get collected when the module itself is collected.

Why can’t you attach the will-executor to the thing you’re concerned about?

Ah, okay, that should work. :slightly_smiling_face: