I'm not aware of such a list, but there aren't that many special forms.
Other than the mentioned fn*, let* and catch, you have loop* and def.
def doesn't create a lexical binding like the others, but creates its var
before evaluating its init-expr.
--
You received this message because you are su
Got it, thanks.
It's the "`".
On Friday, November 9, 2012 11:59:00 AM UTC+8, Justin Kramer wrote:
>
> Yours is not actually the same as the one from Monger. Hint: you're
> missing an important character that prevents def from being called.
>
> Justin
>
> On Thursday, November 8, 2012 10:22:39 PM
Yours is not actually the same as the one from Monger. Hint: you're missing
an important character that prevents def from being called.
Justin
On Thursday, November 8, 2012 10:22:39 PM UTC-5, Satoru Logic wrote:
>
> Hi, all.
>
> When I try to run the following `macro` in `lein repl` (with clojur
Hmm, this is the second (unverified) report of transients being slower than
persistents.
Jim, are you on OSX too, by chance? Which JVM?
--
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
Hi, all.
When I try to run the following `macro` in `lein repl` (with clojure1.3 and
clojure1.4):
(defmacro ^{:private true} defoperator
[operator] (def ^{:const true} ~(symbol (str operator)) ~(str
operator)))
But a `CompilerException` is raised:
CompilerException java.lang.Run
On Thu, Nov 8, 2012 at 2:39 PM, Mayank Jain wrote:
> Try this code : MBBGS
> It should give you 50% off on the book. Hopefully. :)
Thanx but too late. One of my colleagues also bought it 50% off with a
different code. I'm happy with $15 :)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View
Roughly... My FPU module is slow tonight
> My own tests shows that the transient version is twice as fast:
>
> (time (dotimes [_ 100] (assoc [1 2 3 4 5 6 7 8 9 0] 3 5 6 8)))
> Elapsed time: 711.848312 msecs
>
> (time (dotimes [_ 100] (persistent! (assoc! (transient [1 2 3 4 5 6 7 8
So 100 million (rand) calls take 20 seconds. From temporarily changing
^BufferedImage chunk (chunk-cache chunk-num) to ^BufferedImage chunk nil, I
determined that 100 million of the *combination* of the cache lookup (with
no misses) and the .getRGB call took 30. That still leaves just over two
minu
Monger is an idiomatic Clojure MongoDB driver for a more civilized age.
It has batteries included, offers powerful expressive query DSL, strives to
support every MongoDB 2.0+ feature and has sane defaults.
It also has solid documentation at http://clojuremongodb.info.
`1.3.4` is a minor *100% back
(rand) is expensive -- removing the two (rand)s knocks about 40 seconds off
it, nearly 1/5 the total time. I'll try replacing them with lookup from a
precalculated grid of randoms -- long-range correlations shouldn't matter
here.
On Thu, Nov 8, 2012 at 8:00 PM, Cedric Greevey wrote:
> On Thu,
On Thu, Nov 8, 2012 at 3:48 PM, Cedric Greevey wrote:
> I have the following code to perform a complicated image convolution. It
> takes 10-15 seconds with output dimensions 256x256 and samples 6. No
> reflection warnings, and using unchecked math doesn't speed it up any. I've
> tried to ensure i
My own tests shows that the transient version is twice as fast:
(time (dotimes [_ 100] (assoc [1 2 3 4 5 6 7 8 9 0] 3 5 6 8)))
Elapsed time: 711.848312 msecs
(time (dotimes [_ 100] (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9
0]) 3 5 6 8
Elapsed time: 399.466556 msecs
Luc P.
> :require :as is always good and generally preferred over :refer or :use
:only.
I think we all agree with this, but in reality :use with/without :only is
very widely used in a number of real project I've seen on github.
:use (especially without :only) makes code reading painful and usually
read
user=> (use '[criterium.core])
nil
user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a)) ;;2 operations
Evaluation count : 125829120 in 60 samples of 2097152 calls.
Execution time mean : 488.826554 ns
Execution time std-deviation : 19.952095 ns
Execution time lower quantile
We systematically use them. Our typical use case however is way above this
threshold. The policy here is that it cannot be worse than the persistent
version.
Luc P
> Some quick benchmarking that I did, showed that it is actually more
> expensive to convert to transient, conj/assoc and convert
1/2 +
Use is still a short way of including mundane stuff like tools.trace and a few
others. We leave :use clojure.tools.trace in place in namespaces once we
have done
it.
Doing it in the REPL each time we need it while debugging is tedious.
Oh, I must say that I rarely use the Eclipse d
Share the benchmark!
In theory, conversion to and from transients should be constant time
operations, but it would not surprise me if in practice transients aren't
universally faster than persistent.
Performance in different environments varies wildly, so I would doubt
results from a small benchm
Some quick benchmarking that I did, showed that it is actually more
expensive to convert to transient, conj/assoc and convert back to
persistent than the regular conj/assoc unless you want to do more than 8
operations at a time (preferably more than that). My experiments were on
vectors and the
Am Donnerstag, 8. November 2012 19:42:26 UTC+1 schrieb Luc:
>
> I am pragmatic and quite lazy, I use require with an alias
>
inc
An explicit call to use every now and then on the REPL, but no :use in ns.
IMHO use and :use can be removed from the language.
--
You received this message because
Try this code : MBBGS
It should give you 50% off on the book. Hopefully. :)
On Fri, Nov 9, 2012 at 4:00 AM, Sean Corfield wrote:
> On Wed, Nov 7, 2012 at 4:23 PM, Stuart Sierra
> wrote:
> > Not to toot our own horn, but people have been asking about getting
> started
> > with ClojureScript, so
On Wed, Nov 7, 2012 at 4:23 PM, Stuart Sierra
wrote:
> Not to toot our own horn, but people have been asking about getting started
> with ClojureScript, so here's our contribution, just released in book form:
...
> http://shop.oreilly.com/product/0636920025139.do
Nice. $15 and already sync'd to m
Roll up! Roll up!
On 19 November at 7PM hosted by our friends Forward in Camden is the next
London Clojure Dojo!
http://mid-november-2012-ldnclj-dojo.eventbrite.co.uk/
Food! Beer! Clojure!
I hope to see you all there!
--
You received this message because you are subscribed to the Google
Group
Finished the Macro, probably not the best solution but certainly beats the
plain JavaScript Version.
https://gist.github.com/4041597 if anyones interested.
Not yet usable via lein-cljsbuild or any official clojurescript release,
since the goog.result stuff is pretty new and not officially relea
Awesome. Would you say that this is essentially a completed work? Growing
weary or reading and re-reading beta books lately.
Cheers regardless,
Robert
On Wednesday, November 7, 2012 4:23:22 PM UTC-8, Stuart Sierra wrote:
>
> Not to toot our own horn, but people have been asking about getting
>
Doh, just me being stupid again.
I write macros by macroexpand-1'ing it over and over until I get what I
want, used macroexpand this time which caused my problem.
Thanks.
On Thursday, November 8, 2012 6:05:34 PM UTC+1, Herwig Hochleitner wrote:
>
> 2012/11/8 Thomas Heller >
>
>> I'm trying to w
Sorry, yes, to clarify -- :require :as is always good and generally
preferred over :refer or :use :only.
Justin
On Thursday, November 8, 2012 1:42:26 PM UTC-5, Luc wrote:
>
> I am pragmatic and quite lazy, I use require with an alias and use mostly
> with stuff like
> clojure.tools.trace, clo
I look forward to my copy ( currently in the mail ) !
On Thu, Nov 8, 2012 at 12:07 PM, Stuart Sierra
wrote:
> > Already bought it weeks ago, like it, it's a concise recipe, right on
> target.
>
> Aw, thanks!
>
>
> > Disclaimer: I am not a blonde Stuart Sierra groupie :)
>
> Aw, shucks! ;)
>
>
> -
I am pragmatic and quite lazy, I use require with an alias and use mostly with
stuff like
clojure.tools.trace, clojure.pprint where selecting explicit vars brings
no or little value (in my opinion).
You either need most of the public vars or the potential name conflict is a
remote
possibility a
2012/11/8 Ben Wolfson
> Is that true? I mean, lots of uses of condp I see have the p be =, and
> this came up for me precisely because I was using a map as the test in
> cond. In any case, when it *is* useful, it's pretty useful.
= is a point in case:
(condp = foo
bar :>> #(using-foo-identit
On Thu, Nov 8, 2012 at 10:09 AM, Herwig Hochleitner
wrote:
>
> Occasionally I had found found something like that useful, but more often
> than not you'd just get booleans when binding the result of a cond test
> (this is different to condp).
Is that true? I mean, lots of uses of condp I see have
2012/11/8 Ben Wolfson
> A message in early 2010 notes that there had been some discussion of
> adding support for :>> to cond, but I suppose nothing came of
> that---does anyone know why or if it's still something that might
> happen?
Occasionally I had found found something like that useful, b
> Already bought it weeks ago, like it, it's a concise recipe, right on
target.
Aw, thanks!
> Disclaimer: I am not a blonde Stuart Sierra groupie :)
Aw, shucks! ;)
-S
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send
On Thu, Nov 8, 2012 at 10:00 AM, Moritz Ulrich wrote:
> What should :>> do? For me, it looks awfully like the operator mess they
> have in Scala and Haskell.
It should do the same thing :>> already does in condp, and that =>
does in Scheme's cond.
--
Ben Wolfson
"Human kind has used its intelli
What should :>> do? For me, it looks awfully like the operator mess they
have in Scala and Haskell.
On Thu, Nov 8, 2012 at 6:55 PM, Ben Wolfson wrote:
> A message in early 2010 notes that there had been some discussion of
> adding support for :>> to cond, but I suppose nothing came of
> that---
A message in early 2010 notes that there had been some discussion of
adding support for :>> to cond, but I suppose nothing came of
that---does anyone know why or if it's still something that might
happen?
--
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which ma
Current best practice in my view:
For Clojure 1.4+, do not use :use at all. Use :require :refer
(judiciously). :refer :all is almost never a good idea.
For Clojure 1.3 and below, :use :only is strongly encouraged. Bare :use is
almost never good.
Justin
On Thursday, November 8, 2012 11:57:21 A
Ah, only now I see what you were even trying to do. Let me explain why I
think not having unpack is a good idea:
In clojure syntax, (G (F x)) is, under all circumstances - even if F is a
macro -, G called with a _single_ argument, which is the result of (F x)
Even if we had smth like unpack, i.e.
Some time have passed since i posted
"Is clojure need it's own web framework like ruby on rails" ?
https://groups.google.com/forum/?hl=en&fromgroups=#!topic/clojure/C41MfD72UBE
There answer mostly was no. But i still think that clojure need some base
for "Clojure web programming" maybe wiki site
Hi,
I thought :require with :refer superseded :use :only.
Or am I mistaken?
Las
On Nov 8, 2012 6:03 PM, "Jim - FooBar();" wrote:
> I'm pretty sure this is still valid
> :)
>
> Jim
>
> On 08/11/12 16:57, David McNeil wrote:
>
>> I notice the following item at http://dev.clojure.org/**
>> displa
2012/11/8 Thomas Heller
> I'm trying to write a Macro for CLJS which calls a Javascript Function
> directly in the generated code (NOT in the macro). But since the javascript
> function (and namespace) is unknown to Clojure it fails trying to resolve
> it.
>
Syntax quote (`) doesn't resolve name
I'm pretty sure this is still valid
:)
Jim
On 08/11/12 16:57, David McNeil wrote:
I notice the following item at
http://dev.clojure.org/display/design/Library+Coding+Standards
"Be explicit and minimalist about dependencies on other packages.
(Prefer the :only option to use and require)."
I notice the following item at
http://dev.clojure.org/display/design/Library+Coding+Standards
"Be explicit and minimalist about dependencies on other packages.
(Prefer the :only option to use and require)."
The page was last edited on Mar 29, 2011 and ns usage has been discussed a
fair bit
2012/11/8 Sankrant Chaubey
> Clojure runs on multiple platforms namely the JVM, CLR and Javascript, but
> the ecosystem in all these mentioned platforms is quite different from each
> other; i.e the process of thinking methodologies change when working with
> different kinds of environments. I wo
Adam,
Good job. You answered the question I asked. Thank you.
Everyone else,
Yes, I told you I could usually come up with ways around what I was
asking for, but there could be problems with what you have suggested. I
haven't had time to do more detailed testing, so there might be more use
Hey,
I'm trying to write a Macro for CLJS which calls a Javascript Function
directly in the generated code (NOT in the macro). But since the javascript
function (and namespace) is unknown to Clojure it fails trying to resolve
it.
Extemely simplified example:
question.clj
(ns question)
(defmac
Hi,
I am new to Clojure, and the whole ecosystem in here, so don't be to harsh
on me! :)
Clojure runs on multiple platforms namely the JVM, CLR and Javascript, but
the ecosystem in all these mentioned platforms is quite different from each
other; i.e the process of thinking methodologies chang
Hi.
Thanks Ben & Ambrose.
I will look through this material.
Br,
Timo
On Thursday, November 8, 2012 9:06:31 AM UTC+2, Ambrose Bonnaire-Sergeant
wrote:
>
> Hi Timo,
>
> I played around with type inference in core.logic last year.
>
> You might find my Logic Starter project interesting. Certainl
Have you seen David Nolen's conj 2011 talk, "Predicate Dispatch"? It
covers exactly this material, but looks at trying to be somewhat more
efficient by not making method dispatch O(n) in the number of
implementations. At least as far as I understand it anyway.
http://lanyrd.com/2011/clojure-conj/s
Keep your static concerns out of my dynamic language ; )
Seriously, do you think/know that's the reason people don't do this? Even
in Java, you don't know which method implementation will be called until
runtime. And you can define a default polyimpl with an always-true
predicate, once you've c
49 matches
Mail list logo
