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
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){
BTW...
Here is the code that runs Jetty :
https://github.com/JulesGosnell/dada/blob/master/dada-core/src/main/clojure/org/dada/web.clj
I have also found that I need to explicitly set up a DCL in my client :
https://github.com/JulesGosnell/dada/blob/master/dada-swt/src/main/clojure/org/dada/swt/
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.
If anyone else is interested, looks like the code is at
https://github.com/JulesGosnell/dada/tree/master/dada-core/src/main/java/clojure/lang
Pretty simple modifications actually. Thanks to Jules for figuring it out.
On Tue, Apr 26, 2011 at 2:16 PM, kovas boguta wrote:
> Hi,
>
> This sounds v
Hi,
This sounds very interesting and useful.
Is the source code available somewhere? Or a more detailed description?
Thanks
On Fri, Mar 4, 2011 at 1:48 AM, Jules wrote:
>
> So,
>
> Just a quick update.
>
> I gave the client-side ClassLoader encapsulation idea some more
> thought and rejeted it
On 5 March 2011 18:02, Christopher Brown wrote:
> Sorry for not explaining L2 in my original response.
> The tuple of is not guaranteed to be unique either, but
> we're approaching crazy-town with the probabilities.
> This tuple fails in a way analogous to the L2 MAC addr problem.
Yes, that's w
Take the SHA1 hash of the concatenation of the MAC address
and the time. The MAC address is vendor specific and serially
incremented for each device although it can be reset in
software. The time is reasonably random and the SHA1 hash is
nearly unique. The odds of these three items generating a
h
Christopher Brown asked me:
> Is there a reason a moderately strong random GUID generator is not enough?
But I'm not the OP who wanted unique node-IDs, and the above doesn't
seem to need to remain private, and it's also an interesting problem,
so I'm going to post my reply to the list:
Not if you
Sorry for not explaining L2 in my original response.
The tuple of is not guaranteed to be unique either, but we're
approaching crazy-town with the probabilities.
This tuple fails in a way analogous to the L2 MAC addr problem.
If your L3 (IP address) network is behind a proxy and is talking to a n
On 5 March 2011 07:38, Ken Wesson wrote:
> On Fri, Mar 4, 2011 at 8:07 PM, Christopher Brown
> wrote:
>> It will always return a MAC address, but in a virtualized environment those
>> are a fiction and under the control of the VM creator (and hence, not real
>> physical hardware).
>>
>> Since
On Fri, Mar 4, 2011 at 8:07 PM, Christopher Brown wrote:
> It will always return a MAC address, but in a virtualized environment those
> are a fiction and under the control of the VM creator (and hence, not real
> physical hardware).
>
> Since those MAC addrs are only required to be unique withi
It will always return a MAC address, but in a virtualized environment those are
a fiction and under the control of the VM creator (and hence, not real physical
hardware).
Since those MAC addrs are only required to be unique within the L2 domain, two
separate "private clouds" in the same organiz
On Fri, Mar 4, 2011 at 1:09 PM, Christopher Brown wrote:
> It's always tempting to use the MAC address, and while in physical hardware
> it's unique, in networking it's only required to be unique within a single L2
> domain.
> Some virtualized environments, including EC2, play games with the MAC
oops - thanks for this aswell...
If anyone else has a good idea for coming up with the most concise
unique jvmid, I'd be grateful to hear it.
Jules
On Mar 4, 6:09 pm, Christopher Brown wrote:
> It's always tempting to use the MAC address, and while in physical hardware
> it's unique, in networ
I like that - I'm using ip at the moment - you'd need to combine it
with pid aswell, since you may be running more than one jvm per box.
thanks for the idea/code,
Jules
On Mar 4, 5:37 pm, Ken Wesson wrote:
> On Fri, Mar 4, 2011 at 4:48 AM, Jules wrote:
> > So, I introduced the concept of a pe
It's always tempting to use the MAC address, and while in physical hardware
it's unique, in networking it's only required to be unique within a single L2
domain.
Some virtualized environments, including EC2, play games with the MAC address
and rendering it useless as a global ID.
-C
Ken Wesson
On Fri, Mar 4, 2011 at 4:48 AM, Jules wrote:
> So, I introduced the concept of a per-jvm id and hacked it into RT,
> Compiler and LispReader. There were not too many places that needed to
> be changed.
Why not just use the machine's MAC address?
user=> (defn mac []
(if-let [ni (java.net
So,
Just a quick update.
I gave the client-side ClassLoader encapsulation idea some more
thought and rejeted it (sorry) for the reasons that :
- I've lived through J2EE ClassLoader hell and don't want to repeat
the experience
- I'm looking towards an architecture where I can define new types o
On Mar 3, 1:22 pm, Alessio Stalla wrote:
> On Thursday, March 3, 2011 11:46:03 AM UTC+1, Jules wrote:
>
> > Thanks, Alessio,
>
> > I did know this, but it is a welcome addition to the thread.
>
> Ok. Classloaders are a tricky matter and many people don't have clear ideas
> about them - sorry for
On Thursday, March 3, 2011 11:46:03 AM UTC+1, Jules wrote:
>
>
>
> Thanks, Alessio,
>
> I did know this, but it is a welcome addition to the thread.
>
Ok. Classloaders are a tricky matter and many people don't have clear ideas
about them - sorry for assuming you were one of those people :)
>
Thanks, Alessio,
I did know this, but it is a welcome addition to the thread.
I reread my last posting and it was a bit confused - I've done a
little research in the Compiler class and can now clarify what I think
is happening.
Clojure 1.3.0-alpha4
user=> (type (fn []))
user$eval1$fn__2
user=>
On Wednesday, March 2, 2011 2:54:07 PM UTC+1, Jules wrote:
[snip]
> I don't have time to look at this any further today, but I think it is
> looking promising if I can find a way to avoid class name collisions -
> more hacking of clojure.lang I'm afraid :-(
>
> Apologies for posting all the sou
client-side
user=> (Class/forName "user.Foo")
user.Foo
user=> (Foo. 1 2 3)
CompilerException java.lang.IllegalArgumentException: Unable to
resolve classname: Foo, compiling:(NO_SOURCE_PATH:5)
user=> (user.Foo. 1 2 3)
{:a 1, :b 2, :c 3}
user=>
as you can see - not quite there yet
Can we arrange for richhickey.github.com/* and/or github.com/
richhickey/* to issue a 301 moved permanently to the appropriate
clojure page? That seems to describe our scenario exactly and would
make search engines stop giving people disastrously outdated content.
On Mar 1, 7:53 am, Michael Wood
On 1 March 2011 16:40, Seth wrote:
[...]
> In Compiler.java
> https://github.com/richhickey/clojure/blob/master/src/jvm/clojure/lang/Compiler.java
Sorry to butt in here, but don't use github.com/richhickey/...
anymore. The current home of Clojure on github is
github.com/clojure/...
Not that it
Now reflecting on it, and without looking exactly at source code, i
think it is clear that functions are implemented as classes (which
extend RestFn, etc). and the body are methods of the classes - so,
one couldnt force function class names to be the same. And of course
they need to be random enou
On Mar 1, 2:40 pm, Seth wrote:
> > So, combine the ClassLoader hackery with slapping "implements
> > Serializable" on clojure.lang.IFn?
>
> Actually, I just looked at the implementation code -and this is not
> true. Actually, a variadic function is of type RestFn and otherwise it
> is of type AFun
> So, combine the ClassLoader hackery with slapping "implements
> Serializable" on clojure.lang.IFn?
Actually, I just looked at the implementation code -and this is not
true. Actually, a variadic function is of type RestFn and otherwise it
is of type AFunction. Restfn extends AFunction, and AFunct
On Mar 1, 12:03 am, Phil Hagelberg wrote:
> On Feb 25, 7:45 am, Jules wrote:
>
> > I want to include functions in my metadata - e.g. I might want to
> > specify a version comparator function to allow tables to decide
> > whether a new version that they are presented with is actually more
> > re
On Feb 28, 4:03 pm, Ken Wesson wrote:
> On Mon, Feb 28, 2011 at 9:25 AM, Jules wrote:
> > This is actualy my preferred route - however I've just revisited some
> > test code I wrote a while back, that I thought I had working... - I
> > only had it half working :-( - and in having another go at
pretty cute Phil!
It does break for closures that use vars, like this:
(let [a inc] (def dinc (fn [x] (inc (a x)
Caused by: java.lang.IllegalArgumentException: No matching field
found: v for class clojure.lang.Compiler$VarExpr
so you probably want to test the return type from "(.init local)
On Feb 25, 7:45 am, Jules wrote:
> I want to include functions in my metadata - e.g. I might want to
> specify a version comparator function to allow tables to decide
> whether a new version that they are presented with is actually more
> recent than the one that they already hold. I might want to
On Mon, Feb 28, 2011 at 2:51 PM, Seth wrote:
> Notice that saving the code wouldn't work if you had locals (i.e.
> clojures). On the other hand, clojures are serialized when you
> serialize the function.
All the way back in my first post to this thread, I noted that for
closures you'd need to sen
Notice that saving the code wouldn't work if you had locals (i.e.
clojures). On the other hand, clojures are serialized when you
serialize the function.
For example, heres some code which saves the function to a file, and
then loads it back
;
;;;
aaarrrgh !! no dice :-(
Clojure.lang Compiler and RT conspire to return a new DCL every time
you deref the Compiler/LOADER var :
user=> @clojure.lang.Compiler/LOADER
#
user=> @clojure.lang.Compiler/LOADER
#
user=> @clojure.lang.Compiler/LOADER
#
...
you can get in underneath this, by setting up
On Mon, Feb 28, 2011 at 11:13 AM, Jules wrote:
> I've had one last throw of the dice - a plan to intercept class
> definition and remember associated bytecode so that my URLClassLoader
> server could look it up when given the correspondong class name - with
> no luck :
>
> ;; UNFINISHED
>
> ;; let
I've had one last throw of the dice - a plan to intercept class
definition and remember associated bytecode so that my URLClassLoader
server could look it up when given the correspondong class name - with
no luck :
;; UNFINISHED
;; let's maintain a map of class-name : byte-code
(def class-name-to
On Mon, Feb 28, 2011 at 9:25 AM, Jules wrote:
> This is actualy my preferred route - however I've just revisited some
> test code I wrote a while back, that I thought I had working... - I
> only had it half working :-( - and in having another go at it, I've
> realised that there is a big problem w
On Feb 28, 1:50 pm, Ken Wesson wrote:
> On Mon, Feb 28, 2011 at 5:59 AM, Jules wrote:
> > Unfortunately, I'd like it to be a open set, just as I would like the
> > system's types to be - this was one of the choices driving Clojure
> > over Java as the implementation language.
>
> The simplest t
On Mon, Feb 28, 2011 at 5:59 AM, Jules wrote:
> Unfortunately, I'd like it to be a open set, just as I would like the
> system's types to be - this was one of the choices driving Clojure
> over Java as the implementation language.
The simplest thing I can think of in that case is to send function
On Feb 26, 2:10 am, Ken Wesson wrote:
> Embedding literal functions in macros "sorta" works. It behaves
> glitchy sometimes, especially if the functions are closures.
>
> If your set of functions is not open-ended, I'd suggest simply
> defn'ing all of them at both client and server sides, sticki
On Feb 26, 2:10 am, Ken Wesson wrote:
> Embedding literal functions in macros "sorta" works. It behaves
> glitchy sometimes, especially if the functions are closures.
>
> If your set of functions is not open-ended, I'd suggest simply
> defn'ing all of them at both client and server sides, sticki
On Feb 26, 2:10 am, Ken Wesson wrote:
> Embedding literal functions in macros "sorta" works. It behaves
> glitchy sometimes, especially if the functions are closures.
>
> If your set of functions is not open-ended, I'd suggest simply
> defn'ing all of them at both client and server sides, sticki
On Feb 26, 2:10 am, Ken Wesson wrote:
> Embedding literal functions in macros "sorta" works. It behaves
> glitchy sometimes, especially if the functions are closures.
>
> If your set of functions is not open-ended, I'd suggest simply
> defn'ing all of them at both client and server sides, sticki
Embedding literal functions in macros "sorta" works. It behaves
glitchy sometimes, especially if the functions are closures.
If your set of functions is not open-ended, I'd suggest simply
defn'ing all of them at both client and server sides, sticking them in
a map, and putting a keyword instead of
Imagine I started with e.g.
(defrecord Widget [^Integer id ^Integer version ^Integer amount])
but, whilst using records as my underlying datatype, I needed to hold
more metadata than a record definition allows - so I expanded
defrecord
into e.g.:
(deftable;; a table of Widgets
widg
47 matches
Mail list logo
