I should add, I'm definitely looking for a more clojure-native library.
The big productivity gap right now is for datasets too big manipulate
in ram but too small to justify the administrative overhead and
complexity of hadoop.
On Tue, Jan 25, 2011 at 4:18 PM, kovas boguta wrote:
> Hi Olek,
>
>
I do not know Hadoop too well, but I will try to point the
difference.
The main idea is to implement MapReduce in a dynamic language.
The aim is to use higher-order functions and abstract types.
Advantages and disadvantages of the dynamic over static language are
well known, so you can decide your
2011/1/25 NovusTiro :
> Hello,
>
> Seems like this might be a good time to say thanks to Laurent for all
> the work he's done on CCW. FWIW, I've been using it for a while, and
> never had any issues installing it (at least not from a clean
> Eclipse), nor any of the other described issues.
>
> So
Hi all,
I need some help in understanding some basic concept. The book
Programming Clojure on pages 134 - 136 deals with tail recursion and
self-recursion using recur. The tail recursive example blows the stack
while the self-recursive function using recur presented on page 135
does not. On page 13
The JVM does not currently support tail call optimization (TCO) so
any tail recursion call is actually calling the function on itself
using the stack to hold new bindings. TCO hides this to you when
it's supported by the language and transforms this into a loop.
Recur will not consume the Java st
Tail-recursive just means the recursive call occurs in tail position: the
result of the recursive call gets returned as-is rather than having some
additional computations done to it first. This means the compiler *could*
optimize the recursive call to not consume any additional stack space, by
Hi,
I have created some 'deftype' objects and 'extend'ed
clojure.lang.ILookup to them to make them behave like maps. How can I
get the clojure.pprint/pprint to pretty-print them like maps?
Regards,
Shantanu
--
You received this message because you are subscribed to the Google
Groups "Clojure" g
On Wed, Jan 26, 2011 at 10:58 AM, Shantanu Kumar
wrote:
> Hi,
>
> I have created some 'deftype' objects and 'extend'ed
> clojure.lang.ILookup to them to make them behave like maps. How can I
> get the clojure.pprint/pprint to pretty-print them like maps?
A deftype can override toString like this:
Thanks! It's pretty useful.
Regards,
Shantanu
On Jan 26, 9:27 pm, Ken Wesson wrote:
> On Wed, Jan 26, 2011 at 10:58 AM, Shantanu Kumar
>
> wrote:
> > Hi,
>
> > I have created some 'deftype' objects and 'extend'ed
> > clojure.lang.ILookup to them to make them behave like maps. How can I
> > get
On Wed, Jan 26, 2011 at 7:41 AM, Michael Gardner wrote:
> However, the JVM does not support tail-call optimization. Apparently Clojure
> can't support implicit TCO without support from the JVM
always wondered about that also wrt scala etc., am under the
impression that it is implementable, but i
>From what I recall from a previous thread it would require so much byte code
>tweaking that
Hot Spot optimizations would become useless.
You can search the mailing list, you will find a couple of instructive
discussions
about this.
Luc P.
On Wed, 26 Jan 2011 10:01:04 -0800
Raoul Duke wrote:
I discuss one solution to this problem here:
http://david-mcneil.com/post/958196603/enhanced-clojure-records-part-2
-David
--
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 f
>From SICP: "With a tail-recursive implementation, iteration can be
expressed using the ordinary procedure call mechanism". As I
understand this, a tail call is a loop with functional notation but
not actually a function call. That's why I find this issue difficult
to follow, since loops are intern
I found Rich's answer August 14th, 2008:
On Aug 14, 6:35 am, "rob.la...@gmail.com" wrote:
> As I understand it, Clojure does not have tail call optimisation,
> because of limitations of the JVM. Scala, however, has TCO, or at
> least something called Tail Recursion Optimisation which, from my
>
Now try writing two mutually-recursive functions. In Scheme (as I
understand it) that will get optimized into a jump from one function
to the other, while in Clojure it will use the stack.
On Jan 26, 1:10 pm, Armando Blancas wrote:
> From SICP: "With a tail-recursive implementation, iteration can
2011/1/26 Alan :
> Now try writing two mutually-recursive functions. In Scheme (as I
> understand it) that will get optimized into a jump from one function
> to the other, while in Clojure it will use the stack.
And that's why Rich introduced clojure.core/trampoline.
Cheers,
--
Laurent
>
> On
These last posts cleared it up. Thanks.
Which remind me, I think one of the SICP lectures on youtube mentions
tail calls to *other* functions, which I totally forgot, with an
example of a person doing something for another doing something for
another... and the last one just gives the result to th
I've been working on getting clojure integrated into the build system
at work, and it appears that classes are being loaded (which is not
surprising to me) and initialized (which was somewhat surprising to
me) as part of the compilation process.
Does anyone happen to know why this is ? I would hav
To deal with macros and dynamically-generated functions, compiling Clojure
code ends up being the same thing as loading it. The only difference is that
"compile" writes out .class files to disk.
-Stuart Sierra
clojure.com
--
You received this message because you are subscribed to the Google
Gr
clojure.contrib.http-agent (which I wrote) is deprecated in 1.2 and gone in
1.3. Its design with respect to error handling is fundamentally broken, as
you discovered.
-Stuart Sierra
clojure.com
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To pos
So far, this hasn't been an issue for contrib, but only a couple of "new"
contrib libraries are releasing to Maven Central right now.
-Stuart Sierra
clojure.com
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo
Stuart, thanks for the quick reply.
In my particular case, we have a lot of legacy Java code with some
(bad) implicit assumptions about initialization order, which is why I
became aware of this behavior. It sounds like this is something I'll
have to live with !
--
You received this message b
Yes, it's hard to avoid. You might be able to work around it by using
reflection (like Class/forName) to access those classes, and take the
performance hit.
-S
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo
On Wed, 26 Jan 2011 14:42:34 -0800 (PST)
Paul Mooser wrote:
> I've been working on getting clojure integrated into the build system
> at work, and it appears that classes are being loaded (which is not
> surprising to me) and initialized (which was somewhat surprising to
> me) as part of the com
Luc, I definitely would prefer to avoid odd side effects or complex
dependencies in static initializers. Unfortunately, I'm integrating
clojure into an existing system with a large and complex codebase that
sometimes violates this - it's very similar to the configuration issue
for log4j that you're
At least, there's no bad side effects, we had an issue in 2008
with a Spring context being loaded statically in a class called
at compile time oups :). Took us some time to realize what was going on,
it was exiting (System.exit) if the context could not be loaded.
That's the worse case we hit but
On Wed, Jan 26, 2011 at 14:57, Stuart Sierra wrote:
> clojure.contrib.http-agent (which I wrote) is deprecated in 1.2 and gone in
> 1.3.
Which lib is recommended to replace it?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group,
Thanks for providing some background and cases where you ran into this
as well - it's very helpful!
Thus far I've been able to justify adding clojure support to our build
process in large part due to the fact that it integrates very well,
and doesn't require changes to how our build process (or ex
Just keep the solution in your back pocket :)
Luc
On Wed, 26 Jan 2011 17:54:17 -0800 (PST)
Paul Mooser wrote:
> Thanks for providing some background and cases where you ran into this
> as well - it's very helpful!
>
> Thus far I've been able to justify adding clojure support to our build
> pr
29 matches
Mail list logo
