Slack users confirm the problem when the backing scale is 1.5.
Should DrRacket give a warning dialog on Linux, when started with a
non-integer backing scale?
/Jens Axel
Den ons. 13. maj 2020 kl. 05.48 skrev evdubs :
> I did some more digging and found locations in racket/draw that control
>
I suppose that may be helpful, but this performance issue extends to any
other Racket GUI application on Linux, including the simple editor example
from earlier in this thread. Maybe printing something to a console could
help, but it would be better if there was some fix to improve fractional
I'm working on an enhancement for write/print/display, and thought I had it
all implemented in io/print/main.rkt before realizing that code is only
used for Racket-CS.
Now I'm working on making equivalent changes in print.c for the traditional
implementation, and that code is substantially
Good to hear from you!
Unfortunately, it’s going to be really hard to help you without more
information.
Can you give us some context on what your goal is, here? Is this part of a
class? Your problem seems very under-specified.
John
> On May 27, 2020, at 8:53 PM, Med Ra wrote:
>
> Dear
Based on a quick look, I believe it has to do with serializing compiled
code, including quoted values embedded in compiled code. Serializing
compiled code uses the same entry point as the other printing functions.
For example, try this:
(write (compile '(quote (1 2 3
and compare the
I was using the image? predicate as an arbitrary example of something you
might want to do with an image after extracting it from the sandbox. What
if I wanted to pass the result along to beside or overlay?
In all cases, these functions don't recognize the result as an image:
beside: expects an
Perfect, thanks for insight =)
--
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.
To view this discussion on the web
Just in case, the general phenomenon happening here is that you've got two
instantiations of the image library (I believe that mrlib/image-core is the
essential one that's getting duplicated in this case) so there are two
different sets of structs for the representation of images and the one
Ooooh, okay. That explanation helps a lot. Both of these paths seem
workable. I'll see what I can do.
Thanks, Robby!
On Thu, May 28, 2020 at 3:17 PM Robby Findler
wrote:
> Just in case, the general phenomenon happening here is that you've got two
> instantiations of the image library (I
9 matches
Mail list logo
