One of the most common complaints about the current implementation of
Clojure is that the stack traces are often unreadable. At work we have
been using Mark McGranaghan's clj-stacktrace library[1] to print stack
traces, and it does a great job of cleaning them up and making it much
clearer as to wh
On Aug 24, 7:48 pm, ataggart wrote:
> Thanks for focusing solely on one example, and still not providing any
> useful, specific information.
You asked - "Do I really need to perform the itemCheck math ops in
the binary-tree test" - and if you can't see the answer from simply
looking at the ot
Pardon the silly question, but if it doesn't contain any AOT
compiled .class files, then is it a de facto source jar?
On Aug 24, 2:56 pm, Stuart Sierra wrote:
> I've updated the clojure-contrib build to create the "uberjar" at
> modules/complete/target/complete-1.3.0-SNAPSHOT-bin.jar
> WITHOU
Thanks for focusing solely on one example, and still not providing any
useful, specific information.
There may be a number of possible implementations for a given design
criterion. The binary-tree "memory allocation/deallocation" test (for
example) includes not only that, but also math ops, in a p
I understand the desire to keep the parser clean, but at the same time
the ability to register custom data deserializers would be very
convenient. Would something like the following help with the
performance issue, since if no deserializers were registered there
would only be a one time penalty for
Lance Bradley (lancepantz) and I are interested in getting an LA area
Clojure group started, so we started a Google group (http://
groups.google.com/group/clj-la).
If you're in the Los Angeles area, please join the group so we can
talk about setting up a first meeting. Or go to the irc channel: #c
On Aug 23, 9:03 pm, Dmitri wrote:
> Would there be an issue with adding something like that to the
> contrib?
I don't want to add anything that impacts performance in the plain
parsing case.
-S
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To pos
I've updated the clojure-contrib build to create the "uberjar" at
modules/complete/target/complete-1.3.0-SNAPSHOT-bin.jar
WITHOUT the Clojure .class build files included.
This is a binary-only JAR right now. I will look into building a JAR
that includes the clojure-contrib source files.
-S
On Aug 24, 9:50 am, ataggart wrote:
> It would have been more useful to answer the question (particularly
> with regards to a canonical implementation) than getting all passive-
> aggressive.
Did you find any programs that didn't perform itemCheck?
In Clojure does one integer addition and one
On Aug 24, 9:58 am, Nicolas Oury wrote:
> On Tue, Aug 24, 2010 at 5:33 PM, Isaac Gouy wrote:
>
> > Well when Clojure 1.3 is released...
>
> > The phrase "idiomatic code" often seems to be used to mean - code
> > written in a natural way for that language and as if performance
> > doesn't matter
On Tue, Aug 24, 2010 at 5:33 PM, Isaac Gouy wrote:
>
> Well when Clojure 1.3 is released...
>
> The phrase "idiomatic code" often seems to be used to mean - code
> written in a natural way for that language and as if performance
> doesn't matter - whereas I seem to have the strange notion that bot
>>> Clojure 1.3's performance improvements will significantly impact perf on
>>> some of the benchmarks. If you are trying these out, please try them on
>>> both 1.2 and 1.3.
>>
>>
>> Has Clojure 1.3 been released?
>>
>
> No, but since the num/prim/equiv work specifically targets performance, we
It would have been more useful to answer the question (particularly
with regards to a canonical implementation) than getting all passive-
aggressive.
On Aug 24, 5:55 am, Isaac Gouy wrote:
> On Aug 23, 7:07 pm, ataggart wrote:
>
> > It's never been clear to me exactly what the code is supposed
On Tue, Aug 24, 2010 at 12:33 PM, Isaac Gouy wrote:
> The phrase "idiomatic code" often seems to be used to mean - code
> written in a natural way for that language and as if performance
> doesn't matter - whereas I seem to have the strange notion that both
> code written as if performance matter
On Aug 24, 8:48 am, Stuart Halloway wrote:
> > On Aug 24, 6:44 am, Stuart Halloway wrote:
> >> Clojure 1.3's performance improvements will significantly impact perf on
> >> some of the benchmarks. If you are trying these out, please try them on
> >> both 1.2 and 1.3.
>
> > Has Clojure 1.3 bee
> On Aug 24, 6:44 am, Stuart Halloway wrote:
>> Clojure 1.3's performance improvements will significantly impact perf on
>> some of the benchmarks. If you are trying these out, please try them on both
>> 1.2 and 1.3.
>
>
> Has Clojure 1.3 been released?
>
No, but since the num/prim/equiv wor
@Daniel Glauser
records and protocols are an effort to provide very fast solution to
problems that where to slow in Clojure to write Clojure-in-Clojuer and
the the same speed as Clojure-in-Java.
This is an effort to make clojure faster and by this allowing Clojure-
in-Clojure.
I don't think Rich
On Tue, Aug 24, 2010 at 10:30 AM, Isaac Gouy wrote:
> Has Clojure 1.3 been released?
>
Nope.
> If you choose to throw idioms and readability out the window then
> don't be surprised at the comments that will be made about Clojure.
>
Clojure doesn't encourage mutable state. Most of the benchma
Thar she blows. This works:
* **(let [agt (agent nil)] *
* *
* **(send-off agt *
* **(fn [] (println "FINAL > " *
* **(with-out-str (**some-function-that-blocks-on-read***
* **nil*
* **) *
* **)*
* *
* **(println "foobar")*
Danke Schon
Tim
On Tue, Aug 24, 2010 at 10:17 AM, Mark Rathwell w
On Mon, Aug 23, 2010 at 8:41 PM, Seth wrote:
> Going from Java to Clojure isn't quite as easy as going the other way,
> as @brweber2 demonstrated at the local Clojure meetup. Here's the code
> he used in the presentation, might send him a direct message on
> Twitter for more info:
>
> http://githu
On Aug 24, 6:44 am, Stuart Halloway wrote:
> Clojure 1.3's performance improvements will significantly impact perf on some
> of the benchmarks. If you are trying these out, please try them on both 1.2
> and 1.3.
Has Clojure 1.3 been released?
> Also: the benchmarks are totally a numbers ga
It's not send and send-off that are blocking, it is your (println "Final"...
send expects a function, so it is waiting for "(println..." to return some
function to apply to the agent.
On Tue, Aug 24, 2010 at 9:16 AM, Timothy Washington wrote:
> Ok, I have a dumb question here. Using Clojure's c
On Aug 18, 7:35 am, Sreeraj a wrote:
> Hi,
> I am a post-grad student looking for a cool compiler - project to do.
> I am getting comfortable with clojure and would really like to help
>
> Ideas anyone?
> or, Is there a to-do list where can i start?
>
> Cheers
> Sreeraj
An idea: Use knowledge of
Clojure 1.3's performance improvements will significantly impact perf on some
of the benchmarks. If you are trying these out, please try them on both 1.2 and
1.3.
Also: the benchmarks are totally a numbers game: throw idioms and readability
out the window. Clojure 1.3 should be able to match Ja
On Aug 23, 7:35 pm, Robert McIntyre wrote:
> I hear you --- I got excited about this too, and implemented the fannuchredux
> algorithm, only to be thwarted by an undocumented "checksum" each
> program is also
> supposed to calculate. This checksum depends heavily on the exact
> order in which
>
Ok, I have a dumb question here. Using Clojure's concurrency semantics, I'm
trying to see how to spawn a thread that runs and blocks on input from the
standard-in. Vars, atoms, agents and refs all seem to deal with coordinated
/ uncoordinated access to blocks of data.
I need i) to call a function
On Aug 23, 7:07 pm, ataggart wrote:
> It's never been clear to me exactly what the code is supposed to be
> do. For example, the "spec" for the binary-tree test is so wholly
> lacking in any details that I'm left to infer that one is supposed to
> copy an implementation used previously, though w
27 matches
Mail list logo
