This should work for all throwables, all Clj datastructures, Dates etc.

interesting one sec

One problem I found was Less4J error classes, which don't extend Serializable

(The exception itself is serializable, but it has properties which are not)

wait so objectoutputstream serialization can correctly serialize clojure data across clojure versions for example?

Yes

whoa

that's incredible, i wonder how it does it

Or well, I haven't tested between two versions, but works between two classloaders at least

that is what it is used for

i worry about binary compatibility with object serialization like that

for Java RMI or something

between clojure versions

i wrote a crazy thing to get around that

with pods

https://github.com/boot-clj/boot/blob/master/boot/pod/src/boot/xform.clj

this uses the class name and reflection to build a copy of the thing

or if it's a native java object (like from the bootclassloader) it just passes it through

this method is used in with-pod

Aha, I also implemented similar solution to Boot-cljs which created Exceptions using reflection

What does that Stash do?

boot.user=> (def p (boot.pod/make-pod (get-env)))
#'boot.user/p
boot.user=> (def e (try (boot.pod/with-pod p (throw (Exception. "foop"))) (catch Throwable ex ex)))
#'boot.user/e
boot.user=> (type e)
java.lang.Exception
boot.user=> (.getMessage e)
"foop"

the Stash is how it passes java objects straight through

so the both pods are dealing with the same object rather than one pod making a copy of what is in the other pod

Okay. But yeah, the problem is not passing the java classes which are shared, but the problem is when those objects contain Clj objects which can't be passed straight throughh

I wouldn't worry much about serialization changing between clojure versions, e.g, PersistentHashMap properties haven't been changed in 7 years,

right so you can do things like this

boot.user=> (boot.pod/with-pod p (def xxx 100))
#object[clojure.lang.Var 0x46f62c15 "#'pod/xxx"]
boot.user=> (def f (boot.pod/with-pod p (fn [x] (+ x xxx))))
#'boot.user/f
boot.user=> (f 100)
200

hm

hm how would that work?

that currently does work

i just did that in a 2.7.1 boot repl

oh right, both calculations are inside the pod

yeah the f that is returned is a proxy that calls through to the other one in the pod

http://www.ibm.com/developerworks/java/library/j-5things1/index.html

^ re Java Serialization and changing the classes

still seems like an issue, no?

because it goes only one way

like you can add a new field, but you can't remove a field

that would mean that you could pass things onle one way betwen pods

the other way would break?

I think this kind of data passing is usually only needed from task pod -> main pod

Or well, currently I think I pass all file paths as strings to task impl

Could be useful to use File's

But mostly the serialization is interesting for cases where it is not possible to know what data is passed between pods

very interesting development with the serialization

like Cljs exception data

It would be easy to just select the few interesting fields for use in boot-cljs/reload

but Figwheel presumes that the exception is the same as from Cljs compiler

yeah i think i am ok with just assuming binary compatibility

the same as in the exact same instance?

no, but maps with all the same fields

and different errors and warnings have different metadata, files etc.

in one case the compiler state is atteched to warning metadata, that breaks the serialization because it has (I think) circular reference to itself

some things are not serializable i imagine

like {:a (fn [])}

Yeah

Except functions are serializable

no way

really?

I think Clj functions create a class that extends AFunction? https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AFunction.java

that must just be something they hacked to get the type system to not complain

Not sure if this really works between classloaders, but serializing function returns something and deserializing that returns a function

(def x 100)

(serialize (fn [y] (+ x y)))

that can't be serialized really

maybe it can but in some weird way

(def foo 100)
((deserialize-object (serialize-object (fn [] {:x foo}))))
;; => {:x 100}

huh

that's bizarre

serialize-object fn should be in clojure.core

Okay, doesn't really work between classloaders

I think fn returns something which is serializable and refers to the real function

boot.user=> (def a (atom 100))
#'boot.user/a
boot.user=> (defn f [] (swap! a inc))
#'boot.user/f
boot.user=> (f)
101
boot.user=> (def f' (serialize-object f))
#'boot.user/f'
boot.user=> (type f')
java.lang.String
boot.user=> (def g (deserialize-object f'))
#'boot.user/g
boot.user=> (type g)
boot.user$f
boot.user=> (g)
102
boot.user=> (g)
103
boot.user=> (g)
104
boot.user=> (g)
105

(def p (boot.pod/make-pod))
(boot.pod/with-eval-in p
  (import [java.util Base64]
          [ ObjectOutputStream ByteArrayOutputStream])
  (defn serialize-object
    "Serialize given Object to String using Object Streams and encode the bytes
    as Base64 string."
    [e]
    (with-open [bos (ByteArrayOutputStream.)
                out (ObjectOutputStream. bos)]
      (.writeObject out e)
      (.encodeToString (Base64/getEncoder) (.toByteArray bos)))))
((deserialize-object (boot.pod/with-eval-in p
                       (def foo 100)
                       (serialize-object (fn [] {:x foo})))))
;; java.lang.ClassNotFoundException: pod$eval56$fn__57

hm right

Deserialization fails as the class created by fn is not found in another classloader

those classes that are generated on the fly

with gensym names

yeah that's a hard problem i guess

Yeah, I was surprised it works at all

the idea of serializing a lambda is kind of wild

my xform thing wraps lambdas with a proxy

https://github.com/boot-clj/boot/blob/master/boot/pod/src/boot/xform.clj#L69-L78

when you cal lthe function it uses reflection to call it with args that are translated into things that are from the pod the function was created in

it's funny, you can pass functions back and forth between the pods as many times as you want, it will keep building more layers of proxies

dominicm: do you override "repl" or just add a cider task? i follow the advice in "a better way" at https://github.com/boot-clj/boot/wiki/Cider-REPL, but that does not override anything, it just adds a task.

mobileink I add the cider task, and just run either boot cider repl or boot cider dev as appropriate

gotcha. no override there, though (so as not to confuse n00bs).

@U0LGCREMU I don't understand that

I try and keep things kinda "raw" I don't worry too much about beginners. I concentrate more on educating on the basic concepts which make the reasoning behind additional cider tasks & such make sense.

I suppose that > I don't worry too much about beginners would be better worded as "I don't worry much about making things easy for beginners."

when you add a cider task, you"re not overriding anything. just putting another task in the pipeline. the repl task is unchanged

Yeah. I don't override things if I can help it. I've only been inclined when hearing the easy argument from cider users.