Oh, I see. Thanks for clarifying. As best I understand it, then, you're adding the ability to have image (and other snip) constants in compiled code, something that elsewhere in the system we skirt around by just not compiling things (eg when building an executable if there is a file with an image constant in it, it just doesn't get compiled).
I guess the Right Fix is to figure out some general-purpose mechanism for dealing with graphical syntax and do that, so that compiled bytecode I don't see a way that is fundamentally better than what you're doing there, but one minor tweak is that you could turn the images into something like this (make-an-image #"...image's bytes go here") instead of a url, where make-an-image builds the image from the bytes. But maybe you have some reason why urls work better, I'm not sure. Robby On Tue, Aug 9, 2011 at 3:48 PM, Danny Yoo <[email protected]> wrote: > On Tue, Aug 9, 2011 at 3:50 PM, Robby Findler > <[email protected]> wrote: >> I think you should be working with the wxme library, not with image >> snips directly. Did you investigate that? > > Implicitly, that's being done for me. I'm depending > read-accept-reader to do the right thing when I read wxme-encoded > source programs. Trying to deal with the file as a raw wxme-encoded > file seems unnecessarily low-level, since I know that the source > program is readable with read-syntax. > > > zo-parse does not work on compiled-code values directly, nor does it > work when given the input port of the original source program. It > only works when given an input port containing compiled bytecode. > That's why there is this extra, involved step where I compile to > bytecode, and then attempt to push that bytecode into a port. > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
