[plt-scheme] Can subclasses of editor-snips% be saved?

This is a problem that we keep hitting, and then we hack DrScheme to
work around it without fixing the underlying problem.

The problem is that there are different snip-class% instances in the
user space and in DrScheme's space. So when you copy from the editor,
which is in DrScheme's space, the snip-class% associated with the snip
isn't in DrScheme's registry, and so it isn't properly marshaled.

DrScheme actually copies its `snip-class%' instances (as loaded by your
tool, for example) to the user's space. But when you load
`my-snip-class/my-snip-class' in the user program, it creates a new
`snip-class%' instance, and its snips use that instance.

You could try this in "my-snip-class.ss":

 (define the-class-name
   (format "~s" '(lib "my-editor-snip.ss" "my-editor-snip")))

 ;; Install an instance, which will be ignored if one is already
 ;; there:
 (send (get-the-snip-class-list) add
       (new my-editor-snipclass%))

 ;; Bind `snip-class' to the one that DrScheme may have provided,
 ;;  or the one installed above if DrScheme didn't provide one.
 (define snip-class
   (send (get-the-snip-class-list) find the-class-name))

 ;; Don't try something like this:
 ;;  (or (send (get-the-snip-class-list) find the-class-name)
 ;;      (new my-editor-snipclass%)))
 ;; because the `the-class-name' triggers an attempt to load the
 ;; module if the class is not already registered.

The danger here is that the user-space program may end up with
instances of the `my-editor-snip%' class as created in DrScheme's
space.

In the past, we've hacked DrScheme by explicitly attaching modules like
"my-editor-snip.ss" from the DrScheme space to the user space; see
`to-be-copied-module-specs' in `drscheme/private/eval'. As far as I
know, that's still the only solution.

Matthew

At Thu, 29 May 2008 18:12:15 -0400 (EDT), Danny Yoo wrote:
> > I've been trying to implement the serialization protocol for my 
> > editor-snip% subclass, but things aren't working so well.  I can see 
> > that my write method fires off, but when I try reading back, my 
> > snipclass is silent.
> 
> Following up on this: if I construct instances of my-editor-snip from the 
> REPL, those are snips that I can't copy-and-paste.
> 
> 
> However, if I construct the instances from a callback in DrScheme itself, 
> those seem to be copy-pasteable.  But why in the world should the source 
> of the snip matter?  I'm still very confused.
> 
> 
> I see a very subtle difference in the physical bytes being written out, 
> depending on the context where I create the snip.  Depending on whether I 
> initially created the snip in the REPL or in a DrScheme callback, in two 
> places, I see a '-1', whereas in the other, I see a '18'.  For example, I 
> created two files containing a single snip.
> 
> #####################################################################
> dyoo at kfisler-ra1:~/work/function-table$ diff example.ss example2.ss
> 183,184c183,184
> < 00000000001 18 00000000002 20 #"dyoo:function-table\0"
> < 1 18 00000000012 4 9 #"mzscheme\0"
> ---
> > 00000000001 -1 00000000002 20 #"dyoo:function-table\0"
> > 1 -1 00000000012 4 9 #"mzscheme\0"
> #####################################################################
> 
> 
> example.ss is something I can load back, and example2 is corrupted.  I 
> created example.ss's snip from a DrScheme callback, whereas I created 
> example2.ss's snip by running a function in the REPL.
> 
> There seems to be a low level detail here that's messing up.  I don't see 
> what it is yet...
> 
> 
> 
> Any help here would be greatly appreciated.  Thanks!
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme