see inline
On Friday, 29 April 2011 04:25:58 UTC+1, kovasb wrote:
>
> Thats some serious hacking. Definitely agree that distributed clojure
> would be awesome.
>
> Two points/questions:
>
> 1) Is this just a bug in DynamicClassLoader? Why doesn't it call
> super.defineClass instead of falling back on the URLClassLoader?:
>
> public Class defineClass(String name, byte[] bytes){
> return defineClass(name, bytes, 0, bytes.length);
> }
>
I wondered this.
Perhaps the guy who wrote it thought it conceptually cleaner to map his
defineClass into another method at the same inheritance-level, rather than
super, or he intended that you be able to make use of the UCL fn-ality
within DCL, or that it is just how the code has turned out after being
edited several times by several people....
> If it simply called super, then I believe I can pass in the right
> "bytecode preserving" class with the context class loader, thus
> avoiding modifications to the clojure source.
>
You could try patching it to do so, so that you could try out your approach.
If it is successful it might provide a less intrusive way of achieving the
same thing. I have messed wih ClassLoaders before and just took the simplest
approach that I could see to get where I wanted to go. I did try aspecting
the DCL to get my bytecode memo table working without code modification - no
joy, but I can't remember if I tried slipping my own ClassLoader into the
hierarchy...
Given that, without my patch, there are no URLs to fall back on, would the
code not fall through and do what you want to do anyway ?
> 2) Do you know how to serialize an entire namespace? This largely
> avoids the issue of closures.
>
I haven't tried this - you are ahead of me here.
> Right now I'm serializing the classes, and serializing all the vars in
> the NS, and then containing them in some ad-hoc format on disk.
> Obviously this somehow can be done with a single class, but how the
> compiler does it is too hairy for me to understand.
>
>
> This sounds like a bit more of a challenge.
Is the idea that you are dynamically creating a namespace and then
dynamically creating types/functions within it and that you then want to
persist/migrate this construct ?
I haven't investigated how ns-es are implemented, but I expect that you are
going to have to chase down a list of nested references and ensure that you
have marshalled up everything that you need. Along the way, you will
probably have to filter out references to other static ns-es on which you
depend.
This sounds like the sort of code that I would want to write in Clojure
rather than in Java. You are likely to come across types that are not
serialisable as well and have to write custom serialisation routines for
them.
Sounds interesting :-) - wish I could help more - please keep the list
posted.
Jules
On Thu, Apr 28, 2011 at 9:28 AM, Jules <jules....@gmail.com> wrote:
> > well spotted :-)
> >
> > I have ported it up to 1.3.0-alpha5 - alpha6 gave me some trouble that I
> > haven't had time to sort out.
> >
> > [BTW - the following is from memory]
> >
> > You set the JVM's UID via a sys property.
> >
> > If this property is set it is incorporated into the names of new classes
> > created in this JVM.
> >
> > The DynamicClassLoader maintains a map of classname : bytecode.
> >
> > I run a Jetty in this JVM which knows how to respond to URLClassLoader
> > requests for class bytecode by looking them up in this map.
> >
> > I think I hacked DynamicClassLoader (which ?inherits? from
> URLClassLoader)
> > so that you can optionally set a system property that is a URL from which
> it
> > can request classes that it cannot find locally. So you do this on client
> > JVMs
> >
> > Putting this all together, you can basically create types/fns on the-fly
> in
> > a one JVM, serialise instances of these and send them to another JVM,
> then
> > deserialise them (transparently pulling their class over from their
> parent
> > JVM) and use them as if they had been created at compile rather than
> > runtime.
> >
> > This plugs what I have found to be a bit of a hole in Clojure, namely
> > dynamism is great, but I want to use it in a distributed app...
> >
> > The patches are not prodction ready, but I have been using them for some
> > time with no problem. I'd be very happy to find other people with similar
> > interest, improve the patches and see if we can persuade the powers that
> be
> > to accept them or something providing similar fn-ality into e.g.
> Clojure-1.4
> > :-)
> >
> > If you need any help getting this stuff to work, just shout.
> >
> >
> > Jules
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+u...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
