@soegaard2 The depth and breadth of what the small group of core racketeers has produced is remarkable, and allows me to teach in ways that simply wouldn’t be feasible otherwise. So I understand when my priorities aren’t/can’t be theirs, but my answer to your question of what to implement next has been filed as https://github.com/racket/gui/issues/113 . The 2htdp/image saving and loading for transformed bitmaps is currently so slow, and the saved files so large, that essentially any image that a student has or finds is impossible to use. I’ve diagnosed three of the main reasons, with corresponding fixes, but without knowing what approaches are acceptable can’t go any further in contributing to a fix.
I should add: while some of this is specific to the described scenario, it’s also about the general impact on performance of the wxme format.
Thanks for adding the bug report.
Question about plot - trying to map a 3d color space with points3d is there anyway to provide a proc to #:color so that each point in the plot can be the color i’m mapping in 3d space?
This is my plot of rgb values in a 3d space https://dl.dropbox.com/s/o1tkdyohs1ju7rn/Screenshot%202018-09-23%2016.30.07.png - want to get something where each dot is the rgb color being mapped
@gfb I think a patch or pull request would be helpful to move that bug report along
It looks like it got sidetracked into discussion of sharing which wasn’t the real issue
@samth Ok, but I’m a bit tight for time for a while, and not an expert on wxme, so it would help to know the space of what could be accepted, and how to best accomplish it. This is a case where the code changes are unlikely to reveal any non-obvious effects, it’s more about knowing the reasons for the current behaviour and whether/when they still apply. The simplest change and discussion will be removing the 72 column limit, which I’ll submit when I have a chance.
I think lots of things could be accepted provided that they keep existing code working