6

I want to embed a Java object (in this case a BufferedImage) in Clojure code that can be evald later.

Creating the code works fine:

(defn f [image]
     `(.getRGB ~image 0 0))
=> #'user/f

(f some-buffered-image)
=> (.getRGB #<BufferedImage BufferedImage@5527f4f9: type = 2 DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=ff000000 IntegerInterleavedRaster: width = 256 height = 256 #Bands = 4 xOff = 0 yOff = 0 dataOffset[0] 0> 0 0)

However you get an exception when trying to eval it:

(eval (f some-buffered-image))
=> CompilerException java.lang.RuntimeException: Can't embed object in code, maybe print-dup not defined: BufferedImage@612dcb8c: type = 2 DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=ff000000 IntegerInterleavedRaster: width = 256 height = 256 #Bands = 4 xOff = 0 yOff = 0 dataOffset[0] 0, compiling:(NO_SOURCE_PATH:1)

Is there any way to make something like this work?

EDIT:

The reason I am trying to do this is that I want to be able to generate code that takes samples from an image. The image is passed to the function that does the code generation (equivalent to f above), but (for various reasons) can't be passed as a parameter to the compiled code later.

I need to generate quoted code because this is part of a much larger code generation library that will apply further transforms to the generated code, hence I can't just do something like:

(defn f [image] 
  (fn [] (.getRGB image 0 0)))
Improve this question
4
  • is it just eval that gives this error? macros (eg if) can use it just fine, i assume? if so, then it's probably because eval forces things to go through text (which makes sense for eval). if this is an issue for you, you may be using eval when it's not necessary - when a macro may be what you need. Commented May 24, 2012 at 13:34
  • @andrewcooke As I understand it, the eval doesn't really force things to go through text. Eval (via compile) generates JVM code that creates the objects. Going through text (via serialization) is the last resort used on unknown objects. Commented May 24, 2012 at 13:50
  • 2
    @mikera Stepping back, can you comment on why you chose to use quoting and eval vs. doing something like (defn f [a] (fn [] (.getRGB a 0 0)))? Commented May 24, 2012 at 14:33
  • @mikera This would be much simpler if you could just stash the Java objects somewhere and only embed their ids in the generated code. Why cannot you do that? Commented May 25, 2012 at 11:29

3 Answers 3

Reset to default
3

Not sure what you need it for, but you can create code that evals to an arbitrary object using the following cheat:

(def objs (atom []))


(defn make-code-that-evals-to [x] 
    (let [
         nobjs (swap! objs #(conj % x)) 
         i (dec (count nobjs))]
     `(nth ~i @objs)))

Then you can:

> (eval (make-code-that-evals-to *out*))
#<PrintWriter java.io.PrintWriter@14aed2c>

This is just a proof of concept and it leaks the objects being produced - you could produce code that removes the reference on eval but then you could eval it only once.

Edit: The leaks can be prevented by the following (evil!) hack:

The above code bypasses eval's compiler by storing the object reference externally at the time the code is generated. This can be deferred. The object reference can be stored in the generated code with the compiler being bypassed by a macro. Storing the reference in the code means the garbage collector works normally.

The key is the macro that wraps the object. It does what the original solution did (i.e. store the object externally to bypass the compiler), but just before compilation. The generated expression retrieves the external reference, then deletes to prevent leaks.

Note: This is evil. Expansion-time of macros is the least desirable place for global side-effects to occur and this is exactly what this solution does.

Now for the code:

(def objs (atom {}))

Here's where will temporarily store the objects, keyed by unique keys (dictionary).

(defmacro objwrap [x sym]
  (do
   (swap! objs #(assoc % sym x) ) ; Global side-effect in macro expansion
   `(let [o# (@objs ~sym)]
      (do
        (swap! objs #(dissoc % ~sym))
        o#))))

This is the evil macro that sits in the generated code, keeping the object reference in x and a unique key in sym. Before compilation it stores the object in the external dictionary under the key sym and generates code that retrieves it, deletes the external reference and returns the retrieved object.

(defn make-code-that-evals-to [x]
  (let [s 17]    ; please replace 17 with a generated unique key. I was lazy here.
  `(objwrap ~x ~s)))

Nothing fancy, just wrap the object in the evil macro, together with a unique key.

Of course if you only expand the macro without evaluating its result, you'll still get a leak.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

nice idea! but I agree the memory leak makes this one a bit nasty
@mikera I have idea how to fix it, will edit when time allows :)
@mikera Solution added. Would still look for a way around this, as this seems to be going against the grain.
3

I guess you would need to write a macro that takes the object (or a way to create the required object) at compile time, serialize that object in binary format (byte array) and the output of the macro should be - a symbol that refer to the byte array and a function that can be used to get the object from the serialized data by de-serializing it.

Improve this answer

3 Comments

Why is the serialization necessary? The compiled code depends on the external byte array anyway, so why not make it an object array and just keep the reference to the original object there?
Basically when the macro will be evaluated that will be compile time, For ex: (embed-resource "my-file.jpeg") , the macro embed-resource will read the file and stored that as an java array in code, this will allow you to embed the image in code itself
Thanks, I think I get it now. If I understand correctly, you can also serialize the object immediately when generating the code (in function f in OP's example), right?
0

why not: (defmacro m [img] `(.getRGB ~img 0 0)) then u can write: (m some-buffered-image)

The difference is that f is a function, so its argument will be evaluated before its body being evaluated. Thus the image object itself will be placed within the generated code. But for macros, their arguments will not be evaluated. So only the symbol some-buffered-image will be placed within the code. The generated code will be: (.getRGB some-buffered-image 0 0). Just like u write the source code directly. I think that's what u want.

But why can't I place an object in the generated code? The answer is: yes, u can. What the exception message says is not the truth. u can embed some kinds of objects in generated code, but not all kinds of them. They include symbol, number, character, string, regex patten, keyword, boolean, list, map, set etc. All these objects will be understood by the Clojure compiler. They are like key words, operators and literals in other languages. u can't require the Clojure compiler knows all kinds of objects, just like u can't require a C or Java compiler knows all words not included by its syntax.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.