Amit, Is it possible to configure a video conference for the next
clojure meeting?
On Mar 1, 12:21 pm, Amit Rathore wrote:
> Are any of the folks on this thread in/around the bay area? (I know
> Nabib is).
> We're having a clojure user-group meeting on the 12th of March - and
> the clojure/terra
Sounds fun! I'd love to come out, but I'm in the Washington DC area.
It would be an expensive flight.
I pushed an initial version of a TIM for Clojure. It's is simply my
previous work bundled as a TIM. Not much, but it's a base to build on.
I'm starting to figure out how to have Terracotta replac
I'm in Montreal Quebec, we have several feet of snow here and still have
a month of snow storms to go.
Having some spare time I would love to visit you but there's too much
work here
and you area is a bit too far away :)))
Luc
On Sun, 2009-03-01 at 12:21 -0800, Amit Rathore wrote:
> Are any of t
Are any of the folks on this thread in/around the bay area? (I know
Nabib is).
We're having a clojure user-group meeting on the 12th of March - and
the clojure/terracotta topic is of interest to a lot of people...
It would be wonderful if someone would come and talk about the
progress...
Regards,
We will go for a TIM. Just looked at the doc and tes that would simplify
our work a lot.
Thank you,
Luc
On Sat, 2009-02-28 at 18:48 -0800, Nabib El-Rahman wrote:
> Hi guys,
>
> I work for Terracotta ( on the server side ) and find this work with
> Clojure + Terracotta very exciting. Writing a
I've started work on a Terracotta Integration Module for Clojure
already. As I understand it, we can package up the Terracotta config
as well as any replacement classes. This way we can "patch" Clojure
temporarily until either Terracotta supports the features we need, or
Clojure can be rewritten s
Its a way to package integration details into a module. For example, if I
want to cluster EHCache, I can drive through the code and figure out what
data structure to share and subsequently lock on. All that work can be
packaged into a module for terracotta, so that way people who just want to
use
>
>
> Writing a TIM is definitely the way to go, It's a place to hide the glue
> until both Terracotta and Clojure catches up with each other.
uhhh what is a TIM?
Thanks
Hank
--
blog: whydoeseverythingsuck.com
--~--~-~--~~~---~--~~
You received this m
Hi guys,
I work for Terracotta ( on the server side ) and find this work with Clojure
+ Terracotta very exciting. Writing a TIM is definitely the way to go, It's
a place to hide the glue until both Terracotta and Clojure catches up with
each other. If you have any questions feel free to post on o
We think the same way. Our first implementation of an alternative to
AtomicReference
is straightforward, we will look at improving it if the need arises.
It will be easier to do so when we get stats from Terracotta after
running some benchmarks.
There's much to do before getting there.
Luc
On S
In the Namespace case, it might be premature optimization to worry
about AtomicReference being replaced. If there is a way to rewrite
that code with, say, synchronized blocks, and it will work better with
Terracotta, I think it would be worth doing. I don't think it would be
normal usage to be upd
1) AtomicReference is used in several places. Instead of changing it, we
think we can keep
it when Clojure runs "locally" and provide an alternative when running
in "shared" mode.
AtomicReference is optimized to be efficient in a standalone JVM. We
would like to
keep it that way. Eventually Terra
My approach was just to share what few refs I wanted, but another
approach (like Luc's) is to share everything. The obvious advantage
being that you can set! the root binding of vars (like function
definitions). The goal with Terracotta is to make things as
transparent as possible, so I don't thin
You're right Rich,
We all have to agree on the means used to implement this in the Clojure
runtime.
Any code we throw right now has to be somewhat aligned with these
decisions.
The decision to hide the AtomicReference class was easy to take. It was
an unavoidable
obstacle. Any other issues from t
On Feb 27, 6:54 pm, Luc Prefontaine
wrote:
> Having the ability to redefine a function once for all instances is
> something we really want...
> and you need name spaces to be shared for that to happen.
> We take the approach of sharing everything that seems to worth it, then
> we will see
> wh
Having the ability to redefine a function once for all instances is
something we really want...
and you need name spaces to be shared for that to happen.
We take the approach of sharing everything that seems to worth it, then
we will see
what we might need to keep private to each JVM.
Sharing var
Yeah, after sharing clojure.lang.Keyword.table I tried to share
clojure.lang.Namespace.namespaces, but ran into a problem because
Namespace uses an AtomicReference for its mappings and aliases
members. I thought that not sharing namespaces would be a problem (and
maybe it still is I don't have as
Paul Stadig writes:
> I've recently done some experimentation with Clojure and Terracotta.
> I've detailed my experience at:
>
> http://paul.stadig.name/2009/02/clojure-terracotta-yeah-baby.html
Very exciting; I'm looking forward to trying this out! Thanks for posting.
-Phil
--~--~-~-
We are trying to get Clojure shared over Terracotta, not just specific
things but the whole Clojure object space
(name spaces, root values, ) except stuff that needs to remain local
(streams, ).
We take an all or nothing approach here, we would to see many Clojure
instances work as a singl
I've recently done some experimentation with Clojure and Terracotta.
I've detailed my experience at:
http://paul.stadig.name/2009/02/clojure-terracotta-yeah-baby.html
and shared my code at:
http://github.com/pjstadig/terraclojure/tree/master/
I'm the first to admit that I'm not an expert in Te
20 matches
Mail list logo
