Whoops, yes, I meant Jan 9, thanks
On Jan 6, 8:02 pm, ajay gopalakrishnan ajgop...@gmail.com wrote:
It's Jan 9 I guess
On Wed, Jan 6, 2010 at 10:53 PM, nallen05 nalle...@gmail.com wrote:
Two very cool presentations this Saturday at the Hacker Dojo in
Mountain View:
1. An introduction
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:
It's Jan 9 I guess
On Wed, Jan 6, 2010 at 10:53 PM, nallen05 nalle...@gmail.com 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
On Thu, Jan 29, 2009 at 7:28 PM, Greg Harman ghar...@gmail.com 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
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
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:
-
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 ghar...@gmail.com wrote:
One of Clojure's big
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,
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 ghar...@gmail.com wrote:
One of Clojure's big selling points (obviously) is the support for
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
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 ghar...@gmail.com wrote:
Hank:
I have looked at TC in the past, and took another look today at your
suggestion. Terracotta certainly seems to have promise
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
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
13 matches
Mail list logo
