[racket] need feedback on syntax-expanding/rewriting image-snips

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 <dyoo at cs.wpi.edu> wrote:
> On Tue, Aug 9, 2011 at 3:50 PM, Robby Findler
> <robby at eecs.northwestern.edu> 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.
>