On Aug 23, 7:07 pm, ataggart alex.tagg...@gmail.com 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
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:35 pm, Robert McIntyre r...@mit.edu 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
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
On Aug 18, 7:35 am, Sreeraj a writeto...@gmail.com 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
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 twash...@gmail.comwrote:
Ok, I have a dumb question here.
On Aug 24, 6:44 am, Stuart Halloway stuart.hallo...@gmail.com 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
On Mon, Aug 23, 2010 at 8:41 PM, Seth seth.schroe...@gmail.com 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
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
On Tue, Aug 24, 2010 at 10:30 AM, Isaac Gouy igo...@yahoo.com 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
@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
On Aug 24, 6:44 am, Stuart Halloway stuart.hallo...@gmail.com 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
On Aug 24, 8:48 am, Stuart Halloway stuart.hallo...@gmail.com wrote:
On Aug 24, 6:44 am, Stuart Halloway stuart.hallo...@gmail.com 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
On Tue, Aug 24, 2010 at 12:33 PM, Isaac Gouy igo...@yahoo.com 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
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 igo...@yahoo.com wrote:
On Aug 23, 7:07 pm, ataggart alex.tagg...@gmail.com wrote:
It's never been clear to me
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
want to collect
On Tue, Aug 24, 2010 at 5:33 PM, Isaac Gouy igo...@yahoo.com 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
On Aug 24, 9:58 am, Nicolas Oury nicolas.o...@gmail.com wrote:
On Tue, Aug 24, 2010 at 5:33 PM, Isaac Gouy igo...@yahoo.com 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
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 23, 9:03 pm, Dmitri dmitri.sotni...@gmail.com 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
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:
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
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
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 the.stuart.sie...@gmail.com wrote:
I've updated the clojure-contrib build to create the uberjar at
On Aug 24, 7:48 pm, ataggart alex.tagg...@gmail.com 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
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
26 matches
Mail list logo
