Whoops, yes, I meant Jan 9, thanks
On Jan 6, 8:02 pm, ajay gopalakrishnan wrote:
> It's Jan 9 I guess
>
>
>
> On Wed, Jan 6, 2010 at 10:53 PM, nallen05 wrote:
> > Two very cool presentations this Saturday at the Hacker Dojo in
> > Mountain View:
>
> > 1. An introduction to Wraith Scheme by Jay
It's Jan 9 I guess
On Wed, Jan 6, 2010 at 10:53 PM, nallen05 wrote:
> Two very cool presentations this Saturday at the Hacker Dojo in
> Mountain View:
>
> 1. An introduction to Wraith Scheme by Jay Reynolds Freeman
> 2. An introduction to parallel and distributed programming with
> Clojure by Am
Two very cool presentations this Saturday at the Hacker Dojo in
Mountain View:
1. An introduction to Wraith Scheme by Jay Reynolds Freeman
2. An introduction to parallel and distributed programming with
Clojure by Amit Rathore
Go here for more info: http://www.meetup.com/balisp/calendar/12248048/
you want a "distributed clojure" you need to spend a little time working
out the most appropriate abstraction for Clojure to use (This is where Rich
excels IMHO, he always has a well thought out, coherent set of abstractions
he wants to support and is ruthless in trading things off against the
On Thu, Jan 29, 2009 at 7:28 PM, Greg Harman wrote:
>
> Hank:
>
> I have looked at TC in the past, and took another look today at your
> suggestion. Terracotta certainly seems to have promise feature-wise,
> but I have to admit it's a "heavier" solution than I had been thinking
> of, and there ar
On 30.01.2009, at 00:59, Greg Harman wrote:
> Agreed; the communication layer needs to come first. Regarding
> serialization, specifically, I think we get that for "free" with s-
> exps (there may be some under-the-hood evaluation time necessary for
> remoted expressions, but [de]serialization is
> Another thing to look at (there's always another thing to look at)
this worries me... it is sorta like the discussions i see about how
some new db engine is FAST, oh but it totally fails on occasion and
trashes the data, oopsy, oh well.
how do we know any given lib is not going to just end up
How about Hazelcast? [1] Its much lighter weight than TC.
[1] http://www.hazelcast.com
On Fri, Jan 30, 2009 at 1:28 PM, Greg Harman wrote:
>
> Hank:
>
> I have looked at TC in the past, and took another look today at your
> suggestion. Terracotta certainly seems to have promise feature-wise,
>
Another thing to look at (there's always another thing to look at) might be
grid gain (http://www.gridgain.com/). It's map/reduce centric and might
suite clojure very well.
-k.
On Fri, Jan 30, 2009 at 11:28 AM, Greg Harman wrote:
>
> Hank:
>
> I have looked at TC in the past, and took another l
Hank:
I have looked at TC in the past, and took another look today at your
suggestion. Terracotta certainly seems to have promise feature-wise,
but I have to admit it's a "heavier" solution than I had been thinking
of, and there are probably all sorts of gotchas (and reviewing old
threads on the
have you looked at the available java frameworks like hadoop? there is
also some kind of java interface to erlang
instead of reinventing the wheel again...
On Thu, Jan 29, 2009 at 6:15 AM, Greg Harman wrote:
>
> One of Clojure's big selling points (obviously) is the support for
> concurrent prog
Agreed; the communication layer needs to come first. Regarding
serialization, specifically, I think we get that for "free" with s-
exps (there may be some under-the-hood evaluation time necessary for
remoted expressions, but [de]serialization is rarely a lightweight
process).
On Jan 29, 10:03 am,
As has been discussed on this list before, it seems to me the basis for this
should be terracotta, which handles much (most?) of the heavy lifiting
required for this kind of task. Have you looked at it?
On Thu, Jan 29, 2009 at 9:15 AM, Greg Harman wrote:
>
> One of Clojure's big selling points (
On Jan 29, 2009, at 15:15, Greg Harman wrote:
> So, I've been mulling over the idea of putting together a framework
> for distributed applications. I think it should deal with issues such
> as:
...
I think the very first step should be to implement the basics of
distributed computing:
- comm
One of Clojure's big selling points (obviously) is the support for
concurrent programming. However, the performance gains you get with
this concurrency hits a scalability wall once you're fully utilizing
all the cores available in your server. The next step, of course, is
to add additional servers
15 matches
Mail list logo
