I recently pushed a change to DrRacket in the way that it handles snips that are the results of computations [1].
This change is backwards incompatible in the sense that code that commonly worked before can commonly fail before. At a high-level that code was buggy all along, but now the buggy behavior gets in the way all the time instead of just in less common situations. Let me give a little background to explain. The snip% class is how racket/gui's editors represent things that can appear in an editor (and be edited). The most common one of these is a string-snip%, which represents a chunk of text (perhaps one line in a file that's being edited in DrRacket). But there are lots of others, like image-snip% that you get when you use the "Insert Image..." menu item or the things you get when you evaluate 2/3 in the interactions window. There are a bunch of more sophisticated such values (like plots) and the thing they all have in common is that they are subclasses of snip%. Turns out that DrRacket offering this interface to "fancy values" was a bad choice, but it was one that I made a long time ago (late 90s or so). So this message is about an attempt to fix it and the repercussions. The reason this was a bad choice is that the snip% API is all about "things that live in editors". And one important feature of a thing that lives in an editor is that you can save it. Editors edit files, after all (duh!). Well, not all values are things that can easily be saved in files (double duh!). This is the crux of the reason why it was a bad choice. This shows up in that many of these fancy value snips need procedures that were compute random, unknown ahead of time things (think of a plot of a function -- it plots an arbitrary function and it needs that function when you zoom or whatever). So they just didn't implement the marshalling part of the snip% interface. Unfortunately, the change to DrRacket now requires that the marshalling part of the interface to be implemented. Why? Because moving a snip% object from the user's program's "space" (eventspace specifically) to the DrRacket's only works by marshalling and unmarshalling the snip. This triggers part of the snip API that enables DrRacket to find and load it's implementation. And without that step, the snip cannot actually be saved (PR 15049 [2]). I'm writing to know what people think of this backwards incompatibility. I don't know if it helps, but I'm willing to fix all of the existing snips to use a new interface that's designed for "special values" (which wouldn't ask the values to be able to be saved) or to actually finish the implementation of snip%-ness, depending on which is appropriate for each. The ones I know about are plot, pict3d, value turtles, and frtime's signals. (If you know of more, please let me know.) I don't see a way to both fix PR 15049 and maintain backwards compatibility, but it may be possible. (I'm confident it will be complicated, if it is possible, however.) And finally, this is also related to some security-based research work that Scott and Christos are doing and I believe that the backwards incompatible change is the most productive for that purpose, but my guess is that maintaining backwards compatibility just makes some of the hacking involved in that research more painful (as opposed to impossible). Anyway, if you made it this far in this message, thanks. Thoughts welcome. Robby [1]: https://github.com/racket/drracket/commit/01a19794ff9ab8188c0eb269b0ab12509096de1a and https://github.com/racket/gui/commit/469add8d57c03f1ed269b48f5453dfad2f60d0c6 [2]: http://bugs.racket-lang.org/query/?cmd=view&pr=15049 -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-dev@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAL3TdOOr9J4P4EA1pphQhA%3Dp-9fx86_q1Ojm4U5wY_W7qiWp7g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
