Re: Polymorphism based on predicates instead of dispatch value types

[Matt Ridsdale]

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 chosen a solution for handling cases with more than 
one matching implementation.

On Wednesday, November 7, 2012 7:49:19 PM UTC+1, raould wrote:
>
> On Wed, Nov 7, 2012 at 10:08 AM, Matt Ridsdale 
> > 
> wrote: 
> > that we could be even more flexible if each method implementation 
> > was associated with a predicate function of the args, instead of being 
> > associated with a fixed dispatch value. See the below code for an 
> example of 
>
> ah, so you can be even less likely to ever statically know what cases 
> you've covered? :-) 
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Polymorphism based on predicates instead of dispatch value types

[Philip Potter]

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/shhfg/

Phil

On 7 November 2012 18:08, Matt Ridsdale  wrote:
> Hi,
>
> I was thinking about multimethods and the flexibility given by being able to
> dispatch on the value of an arbitrary function of the arguments,
> instead of just the class of the first argument as in Java. It seems to me
> that we could be even more flexible if each method implementation
> was associated with a predicate function of the args, instead of being
> associated with a fixed dispatch value. See the below code for an example of
> what I mean:
>
> (ns polymorphism
>   (:use clojure.test))
>
> (def pm-to-dispatch-pred-map (ref {}))
>
> ; these are kind of like multimethods, so let's give them a similar name -
> polymethods.
> (defmacro defpoly [a-name [& args]]
>   "define a polymethod signature"
>   `(do
>  (defn ~a-name [~@args]
>  (let [dispatch-pred-to-impl-fn-map# (get
> @polymorphism/pm-to-dispatch-pred-map ~a-name)
>matching-keys# (filter #(apply % [~@args]) (keys
> dispatch-pred-to-impl-fn-map#))
>num-matches# (count matching-keys#)]
>(case num-matches#
>  0 (throw (Exception. (str "No matching function defined for
> polymethod " ~a-name " and args " [~@args])))
>  1 (apply (get dispatch-pred-to-impl-fn-map# (first
> matching-keys#)) [~@args])
>  (throw (Exception. (str num-matches# " matching functions
> defined for polymethod " ~a-name " and args " [~@args]))
>(dosync (alter polymorphism/pm-to-dispatch-pred-map assoc ~a-name
> {}
>
> (defmacro defpolyimpl [a-name dispatch-pred & body]
>   "define a polymethod implementation, for a given dispatch predicate"
>   `(let [dispatch-pred-to-impl-fn-map# (get
> @polymorphism/pm-to-dispatch-pred-map ~a-name)]
>  (if (nil? dispatch-pred-to-impl-fn-map#)
>(throw (Exception. "No such polymethod: " ~a-name)))
>  (let [impl-fn# (fn ~@body)]
>(dosync (alter polymorphism/pm-to-dispatch-pred-map assoc ~a-name
> (assoc dispatch-pred-to-impl-fn-map# ~dispatch-pred impl-fn#)))
>~a-name)))
>
>
> (deftest polymorphism-test
>   (defpoly find-name [a-map])
>
>   (defpolyimpl find-name
> #(and (contains? % :first-name) (contains? % :surname))
> [a-map]
> (str (:first-name a-map) " "  (:surname a-map)))
>
>   (defpolyimpl find-name
> #(contains? % :full-name)
> [a-map]
> (:full-name a-map))
>
>   (def personA {:first-name "John" :surname "Smith"})
>   (def personB {:full-name "Jane Bloggs"})
>   (is (= "John Smith" (find-name personA)))
>   (is (= "Jane Bloggs" (find-name personB
>
> (run-tests)
>
> I think this system of "dispatch predicates" instead of dispatch values is
> more flexible/expressive, because you can easily emulate multimethods: if
> your multimethod had dispatch function dispatch-fn and a dispatch value
> dispatch-val, you would use
>   #(isa? (apply dispatch-fn %&) dispatch-val)
> as the dispatch predicate. Whereas I can't see a simple way to express an
> arbitrary set of "polymethods" in terms of multimethods.
>
> There are a few problems I can see with this approach, but none of them seem
> to be dealbreakers to me:
> - You need to filter a list to determine the appropriate function
> implementation, whereas multimethods just look up the dispatch value in a
> hash map. This could decrease performance if there are many implementations.
> - In this version, they don't compose well: somebody could define a new
> implementation somewhere else which breaks your code, because two dispatch
> predicates match the args you're using. We could get around this with
> something like prefer-method, or by remembering the order in which
> implementations are defined, and always taking the first/last one which
> matches the args.
> - Maybe this shouldn't be called polymorphism, since there is no notion of
> type involved anywhere, except for the "types" defined by the predicates.
>
> Is there anything wrong with this approach, or any particular reason it
> wasn't done this way in Clojure?
>
> --
> 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 from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
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 from new members are moderated - please be patient 

Re: [core.logic] Type inference examples

[Timo Westkämper]

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. Certainly is not 
> solving a "non-trivial" problem though.
>
> Querying the Java hierarchy: 
> https://github.com/frenchy64/Logic-Starter/blob/master/src/logic_introduction/extend.clj#L76
>
> Have a browse through this directory: 
> https://github.com/frenchy64/Logic-Starter/tree/master/src/logic_introduction
>
> If you're willing to give up global type inference, I can give some tips 
> for local type inference (I use it in Typed Clojure).
>
> Good luck!
> Ambrose
>
> On Thu, Nov 8, 2012 at 3:25 AM, Timo Westkämper 
> 
> > wrote:
>
>> I am searching for non-trivial type inference example code for a small 
>> language project I am doing 
>>
>> I took this as the basis
>> https://gist.github.com/997140
>>
>> and ended up with this
>> https://github.com/timowest/symbol/blob/master/src/symbol/types.clj
>>
>> I read some basic papers on Hindley-Milner type inference, and I grasped 
>> the basics.
>>
>> Are there more type inference examples out there?
>>
>> I am specifically looking for inspiration to the following challenges
>> * inferring types of function invocations with varying arguments (varargs)
>> * inferring types of classes
>> * how to encode class hierarchies in a core.logic type inference engine
>>
>>
>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Some Platform related Questions of a newbie!

[Sankrant Chaubey]

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 change when working with 
different kinds of environments. I work mainly with the JVM implementation, 
but I have to constantly write in the browser too, and believe me clojure 
in the browser dosen't feel like that on the machine.

So basically I am confused about, Which implementation is primary? (As a 
matter of fact, the JVM version is primary implementation i.e most 
development, libraries, tutorials developed)

What I really want is, to focus on *the one primary implementation* guaranteed 
to be supported as is in the future. 

Will the JVM remain the primary implementation in the future? Even after 
Clojure-in-Clojure? Does Clojure-CLR, and Clojurescript compete with 
Clojure? 

To note, I have no dependency on any platform... I just ask this, because 
'porting stuff from python to python3', is what I don't want to do again in 
future

Regards,
Sankrant Chaubey

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

CLJS Macro

[Thomas Heller]

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)
(defmacro foo [a b]
  `(goog.something/other ~a ~b))

app.cljs
(ns app
  (:require-macros [question]))

(question/foo 1 2)

; so the result should be
(goog.something/other 1 2)

Another problem will be the missing goog.require('goog.something') but 
thats something I can work arround.

How do I tell the macro to leave the symbol (goog.something/other) as is 
instead of trying to resolve it?

/thomas

PS: I'm playing with goog.result/wait* which looks very interesting. The 
Goal would be a macro which lets me write:

(let [req1 (xhr/getJson "/object/1")
  req2 (xhr/getJson "/object/2")]
  (wait-success [obj1 req1
obj2 req2]
(do-stuff obj1)
(do-other obj2)
(do-more obj1 obj2)))

wait-success being the macro, hiding all the CombinedResult wrapping and 
unwrapping. Trying to coordinate 2 seperate async requests is annoying with 
callbacks.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: unseq

[cej38]

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 
cases where what you are suggesting won't work.  

I think where not having something like Lua's unpack function could be 
problematic is in control structures when you have a variable number of 
arguments.  Using the language that I started this discussion with  F is 
the cond function.  The seq A can have a variable number of elements 
depending on user input:  A1 = [true 1 false 2], or A2= [false 1 false 
2 true 3 false 4], where A1 and A2 are two different possible A.

In this case like this I believe destructing is right out.

Further, apply won't work either. Try one of these:  
(apply cond [true 1 false 2])
(apply 'cond [true 1 false 2])

On cond you can get around this by using
(eval (cons 'cond [true 1 false 2]))


But so far I haven't come up with a way of doing this in core.logic's 
conde.  Neither of these work. Of course this could be because my 
understanding of core.logic is not that great.

(run* [x]
(apply 'conde
 [[(== "tea" x) s#]
  [(== "cup" x) u#]]))

(run* [x]
(eval (cons 'conde
 [[(== "tea" x) s#]
  [(== "cup" x) u#]])))






On Tuesday, November 6, 2012 11:36:31 AM UTC-5, the80srobot wrote:
>
> If I understand this right, you're looking for something like Lua's unpack 
> function. AFAIK you will not be able to do this in Clojure using functions, 
> because Clojure functions can only return one argument. The only way to 
> achieve this behavior would by by transforming your calls using reader 
> macros and then eval. I do not recommend doing this.
>
> I understand that something like unpack is a more general case of apply, 
> but I can't think of any scenario where apply isn't enough - out of 
> interest, what are you trying to do?
>
> -Adam
>
>
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Some Platform related Questions of a newbie!

[Herwig Hochleitner]

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 work mainly with the JVM implementation,
> but I have to constantly write in the browser too, and believe me clojure
> in the browser dosen't feel like that on the machine.
>

I write a lot of Clojure and ClojureScript too. In my experience the
language feels pretty much the same. Of course, the way I develop differs
due to differences in runtime, tooling and APIs.

What I really want is, to focus on *the one primary implementation* guaranteed
> to be supported as is in the future.
>

I'm not the one to call what Clojure does or doesn't guarantee. I would
certainly expect to see Clojure and Clojurescript remain useable for the
forseeable future.


> Will the JVM remain the primary implementation in the future? Even after
> Clojure-in-Clojure? Does Clojure-CLR, and Clojurescript compete with
> Clojure?
>

I don't see competition rather than serving different ecosystems. Of course
you could develop a given application in either JVM Clojure or
ClojureScript on NodeJS, but the driving consideration there would be which
platform you would rather use, not which variant of Clojure.

I think most of those concerns disappear when you consider the following:
Clojure isn't a platform. The language is designed with the intent of being
as transparent towards the underlying platform as possible. In practice
this means: The dot interop form is utterly platform dependent. No
'wrapping' or 'portable base classes' whatsoever.

Fortunately all the other forms work the same on all platforms (modulo some
like tag metadata or numerics). This, in turn, means that code that doesn't
do interop (i.e. algorithmic code) will run as is.
This has been reported for core libs like clojure.zip. I have experienced
it myself when porting enlive to clojurescript. It works.

So say, we had Clojure-in-Clojure and hence a new JVM backend. I see no
reason to make incompatible changes to the dot form, or any metadata.

To note, I have no dependency on any platform... I just ask this, because
> 'porting stuff from python to python3', is what I don't want to do again in
> future
>

Python 3 is a slightly different matter. It was an overhaul of the language
and a chance to make incompatible changes. There are a few of those waiting
for Clojure 2: http://dev.clojure.org/display/design/Wart+Removal

- Giving builtin forms a namespace
- Maybe overhauling the ns form?

Supposedly such changes would happen simultaneously on all variants of
Clojure. There have been efforts to keep Clojure and ClojureScript in sync
syntactically (see (.-prop o))

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Coding Standard - ns usage

[David McNeil]

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 since then... this leads to the question: 

   Is the item quoted above still the standard for Clojure Libraries?

Thanks.
-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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Coding Standard - ns usage

[Jim - FooBar();]

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)."


The page was last edited on Mar 29, 2011 and ns usage has been 
discussed a fair bit since then... this leads to the question:


   Is the item quoted above still the standard for Clojure Libraries?

Thanks.
-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 from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en 


--
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: CLJS Macro

[Herwig Hochleitner]

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 namespace qualified symbols. Also it's
even less concerned with functions or whether they exists. What kind of
error do you see?


> Another problem will be the missing goog.require('goog.something') but
> thats something I can work arround.
>

Ack, that's a problem. I think it's advisable to have an accompanying cljs
file for every macro file for now.


> wait-success being the macro, hiding all the CombinedResult wrapping and
> unwrapping. Trying to coordinate 2 seperate async requests is annoying with
> callbacks.
>

Also ack. I've implemented channels for that purpose. Incidentally, the
syntax works pretty much like what you've sketched here.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Coding Standard - ns usage

[László Török]

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/**
>> 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 since then... this leads to the question:
>>
>>Is the item quoted above still the standard for Clojure Libraries?
>>
>> Thanks.
>> -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 from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscribe@**googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/**group/clojure?hl=en
>>
>
> --
> 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 from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[Learning] Clojure web programming - thoughts and series of articles

[Yakovlev Roman]

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 or site with categories and 
articles.
Good example http://www.yiiframework.com/wiki/ with some articles each week 
and forum . 
If someone is +1 for that idea ping me we will discuss this. If we can do 
something site will be announced.

For now i have small contribution. I started to explore clojure and clojure 
web programming about a month and i could say it can do a lot :)

In this series  of articles i covered these 
topics:

1. Setup with Noir and Hiccup
2. Persistence with DB ( MongoDB)
3. Working with pictures uploading
4. Using ClojureScript and fetch, jayq libs for ajax
5. Making your app reactive with pubsub service.
6. Uploading your site to heroku.

That's good tool box to start making web application with cool modern 
features
A lot more need to be discovered like shoreleave client side library and 
ClojureScript itself but it's good start point for beginners for sure.
I will write more as i explore clojure more. Feedback is appreciated.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: unseq

[Herwig Hochleitner]

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. multiple return values, it wouldn't
work on macros like cond. Im pretty sure that you can't use Lua's unpack to
fill the branches of an if.

Even if we had unpack _and_ somehow found a way to make it work on macros,
it probably wouldn't do what you expected. By the time the values get
returned an unpacked into a macro, they would have been already
evaluated. If the last sentence even made any sense to you at all, please
think about your concept of macros and how it fits into the distinction
between compile time and run time.

Your cond example above only works, because for true, false, 1 and 2 it
doesn't matter if they are already evaluated, because they evaluate to
themselves without side effects.

Concerning your core.logic example: Presumably you have a varying number of
branches in you conde. You'd have to find out what the expansion of conde
does at runtime and recreate the same for your input. Also s# and u# aren't
defined.

I hope you don't think of this response as unhelpful. I do think the whole
issue arises from a misunderstanding of clojure's semantics and I hope to
have helped clarify it.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Coding Standard - ns usage

[Justin Kramer]

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 AM UTC-5, 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)."
>
> The page was last edited on Mar 29, 2011 and ns usage has been discussed a 
> fair bit since then... this leads to the question: 
>
>Is the item quoted above still the standard for Clojure Libraries?
>
> Thanks.
> -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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

why no :>> for cond?

[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?

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: why no :>> for cond?

[Moritz Ulrich]

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---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 may be sweet, aromatic, fermented or spirit-based. ... Family
> and social life also offer numerous other occasions to consume drinks
> for pleasure." [Larousse, "Drink" entry]
>
> --
> 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 from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: why no :>> for cond?

[Ben Wolfson]

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 intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: [ANN] new book: "ClojureScript: Up and Running"

[Stuart Sierra]

> 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 email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: why no :>> for cond?

[Herwig Hochleitner]

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, but more often
than not you'd just get booleans when binding the result of a cond test
(this is different to condp).

Maybe the better answer would be something like cgrands flatter cond?
http://clj-me.cgrand.net/2011/06/17/a-flatter-cond/

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: why no :>> for cond?

[Ben Wolfson]

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 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.

> Maybe the better answer would be something like cgrands flatter cond?
> http://clj-me.cgrand.net/2011/06/17/a-flatter-cond/



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: why no :>> for cond?

[Herwig Hochleitner]

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-identity %))

vs hypothetical

(cond
  (= foo bar) :>> #(using-true %))


OTOH using a map as a predicate is a valid case and I've encountered it
myself.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Coding Standard - ns usage

[Softaddicts]

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 few light-years away.

I almost never select explicit vars from external name spaces. I find this 
cumbersome to manage.

With (short) aliases, I get auto expansion of all public vars as soon as I type 
the /
in CCW (Eclipse plugin). With a little consistency in choosing aliases,
it's then very easy to find out while reading the code where a reference comes 
from.

I am also older than most of you guys so the less stuff resides in my working 
memory,
the easier I can cheat with the slowly eroding aging process :)
I leave most of the work to the computer.

Mmmh, maybe I should create a pocket guide for elderly Clojure coders someday...

Luc P.

> 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 AM UTC-5, 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)."
> >
> > The page was last edited on Mar 29, 2011 and ns usage has been discussed a 
> > fair bit since then... this leads to the question: 
> >
> >Is the item quoted above still the standard for Clojure Libraries?
> >
> > Thanks.
> > -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 from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
Softaddicts sent by ibisMail from my ipad!

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: [ANN] new book: "ClojureScript: Up and Running"

[charlie]

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! ;)
>
>
> -S
>
>
>  --
> 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 from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Coding Standard - ns usage

[Justin Kramer]

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, 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 few light-years away. 
>
> I almost never select explicit vars from external name spaces. I find this 
> cumbersome to manage. 
>
> With (short) aliases, I get auto expansion of all public vars as soon as I 
> type the / 
> in CCW (Eclipse plugin). With a little consistency in choosing aliases, 
> it's then very easy to find out while reading the code where a reference 
> comes from. 
>
> I am also older than most of you guys so the less stuff resides in my 
> working memory, 
> the easier I can cheat with the slowly eroding aging process :) 
> I leave most of the work to the computer. 
>
> Mmmh, maybe I should create a pocket guide for elderly Clojure coders 
> someday... 
>
> Luc P. 
>
> > 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 AM UTC-5, 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)." 
> > > 
> > > The page was last edited on Mar 29, 2011 and ns usage has been 
> discussed a 
> > > fair bit since then... this leads to the question: 
> > > 
> > >Is the item quoted above still the standard for Clojure Libraries? 
> > > 
> > > Thanks. 
> > > -David 
> > > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> -- 
> Softaddicts> sent by ibisMail from 
> my ipad! 
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: CLJS Macro

[Thomas Heller]

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 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 namespace qualified symbols. Also it's 
> even less concerned with functions or whether they exists. What kind of 
> error do you see?
>  
>
>> Another problem will be the missing goog.require('goog.something') but 
>> thats something I can work arround.
>>
>
> Ack, that's a problem. I think it's advisable to have an accompanying cljs 
> file for every macro file for now.
>  
>
>> wait-success being the macro, hiding all the CombinedResult wrapping and 
>> unwrapping. Trying to coordinate 2 seperate async requests is annoying with 
>> callbacks.
>>
>
> Also ack. I've implemented channels for that purpose. Incidentally, the 
> syntax works pretty much like what you've sketched here. 
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: [ANN] new book: "ClojureScript: Up and Running"

[Robert Pitts]

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 
> started with ClojureScript, so here's our contribution, just released in 
> book form:
>
> ClojureScript: Up and Running
> by Stuart Sierra and Luke VanderHart
> published by O'Reilly in paper, eBook, and Safari
>
> http://shop.oreilly.com/product/0636920025139.do
>
> -S
>
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: CLJS Macro

[Thomas Heller]

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 released yet. 
The xhr stuff still lives in goog.labs.net which probably means its gonna 
be a while.

Cheers,
/thomas


On Thursday, November 8, 2012 8:51:03 PM UTC+1, Thomas Heller wrote:
>
> 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.
>
>>
>>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

ANN: Mid November 2012 London Clojure Dojo at Forward

[Bruce Durling]

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
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: [ANN] new book: "ClojureScript: Up and Running"

[Sean Corfield]

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 my DropBox on all my devices - some
light reading for the train in/out of SF tonight to listen to Rich
Hickey speak at the Bay Area Clojure Meetup!
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: [ANN] new book: "ClojureScript: Up and Running"

[Mayank Jain]

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 here's our contribution, just released in book
> form:
> ...
> > http://shop.oreilly.com/product/0636920025139.do
>
> Nice. $15 and already sync'd to my DropBox on all my devices - some
> light reading for the train in/out of SF tonight to listen to Rich
> Hickey speak at the Bay Area Clojure Meetup!
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> 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 from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>



-- 
Regards,
Mayank.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Coding Standard - ns usage

[Stefan Kamphausen]

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 you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

transient/persistent! not worth for less than 7-8 operations

[Jim - FooBar();]

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 vararg version of assoc/assoc!.


any thoughts? would you agree?

Jim

--
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: transient/persistent! not worth for less than 7-8 operations

[Philip Potter]

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 benchmark on a single machine are universally
applicable.

Benchmarking is hard, particularly on the jvm. Caching and dynamic inlining
and Hotspot confuse matters greatly.

Phil
 On Nov 8, 2012 10:49 PM, "Jim - FooBar();"  wrote:

> 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 vararg version of assoc/assoc!.
>
> any thoughts? would you agree?
>
> Jim
>
> --
> 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 from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Coding Standard - ns usage

[Softaddicts]

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 debugger. Tracing does most of the 
job.
Removing use would force us to redefine it somehow.

And yes I know how to use a debugger, even non-symbolic ones :)

Luc P.

> 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 you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
Softaddicts sent by ibisMail from my ipad!

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: transient/persistent! not worth for less than 7-8 operations

[Softaddicts]

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 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 vararg version of assoc/assoc!.
> 
> any thoughts? would you agree?
> 
> Jim
> 
> -- 
> 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 from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: transient/persistent! not worth for less than 7-8 operations

[Jim - FooBar();]

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 : 459.910320 ns ( 2.5%)
   Execution time upper quantile : 527.008269 ns (97.5%)
nil
user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
nil 6 'a)))

Evaluation count : 97399860 in 60 samples of 1623331 calls.
 Execution time mean : 639.789263 ns
Execution time std-deviation : 26.265080 ns
   Execution time lower quantile : 597.753127 ns ( 2.5%)
   Execution time upper quantile : 687.838668 ns (97.5%)
nil
user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a 0 "z" 2 5)) ;;4 
operations

Evaluation count : 68275920 in 60 samples of 1137932 calls.
 Execution time mean : 901.407416 ns
Execution time std-deviation : 35.682637 ns
   Execution time lower quantile : 851.060950 ns ( 2.5%)
   Execution time upper quantile : 970.492949 ns (97.5%)

Found 1 outliers in 60 samples (1.6667 %)
low-severe 1 (1.6667 %)
 Variance from outliers : 25.4849 % Variance is moderately inflated by 
outliers

nil
user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
nil 6 'a 0 "z" 2 5)))

Evaluation count : 68844120 in 60 samples of 1147402 calls.
 Execution time mean : 893.798444 ns
Execution time std-deviation : 24.566655 ns
   Execution time lower quantile : 848.307600 ns ( 2.5%)
   Execution time upper quantile : 952.841308 ns (97.5%)

Found 13 outliers in 60 samples (21.6667 %)
low-severe 7 (11.6667 %)
low-mild 6 (10. %)
 Variance from outliers : 14.2244 % Variance is moderately inflated by 
outliers

nil
user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a 0 "z" 2 5 4 (atom 
[]) 7 "v")) ;;6 operations

Evaluation count : 39783840 in 60 samples of 663064 calls.
 Execution time mean : 1.480511 us
Execution time std-deviation : 50.249443 ns
   Execution time lower quantile : 1.425053 us ( 2.5%)
   Execution time upper quantile : 1.591407 us (97.5%)
nil
user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
nil 6 'a 0 "z" 2 5 4 (atom []) 7 "v")))

Evaluation count : 44755020 in 60 samples of 745917 calls.
 Execution time mean : 1.358394 us
Execution time std-deviation : 49.723547 ns
   Execution time lower quantile : 1.306456 us ( 2.5%)
   Execution time upper quantile : 1.473882 us (97.5%)
nil

user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a 0 "z" 2 5 4 (atom 
[]) 7 "v" 5 1200 8 -)) ;;8 operations

Evaluation count : 31457280 in 60 samples of 524288 calls.
 Execution time mean : 1.907389 us
Execution time std-deviation : 74.523511 ns
   Execution time lower quantile : 1.822336 us ( 2.5%)
   Execution time upper quantile : 2.076044 us (97.5%)
nil
user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
nil 6 'a 0 "z" 2 5 4 (atom []) 7 "v" 5 1200 8 -)))

Evaluation count : 37739640 in 60 samples of 628994 calls.
 Execution time mean : 1.623599 us
Execution time std-deviation : 68.677518 ns
   Execution time lower quantile : 1.529454 us ( 2.5%)
   Execution time upper quantile : 1.777040 us (97.5%)

Found 1 outliers in 60 samples (1.6667 %)
low-severe 1 (1.6667 %)
 Variance from outliers : 28.6901 % Variance is moderately inflated by 
outliers

nil


etc etc...

you get the idea...conclusion: there is no real benefit to using 
transients for less than 6 operations...


Jim




On 08/11/12 23:04, Philip Potter wrote:


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 benchmark on a single machine are universally 
applicable.


Benchmarking is hard, particularly on the jvm. Caching and dynamic 
inlining and Hotspot confuse matters greatly.


Phil

On Nov 8, 2012 10:49 PM, "Jim - FooBar();" > wrote:


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 vararg version of assoc/assoc!.

any thoughts? would you agree?

Jim

-- 
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 from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
 

Re: Coding Standard - ns usage

[Takahiro Hozumi]

> :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 
reading time including other's is much longer than writing time.
I hope :use is used only for popular library such as clojure.test, etc.

On Friday, November 9, 2012 3:54:38 AM UTC+9, Justin Kramer wrote:
>
> 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, 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 few light-years away. 
>>
>> I almost never select explicit vars from external name spaces. I find 
>> this cumbersome to manage. 
>>
>> With (short) aliases, I get auto expansion of all public vars as soon as 
>> I type the / 
>> in CCW (Eclipse plugin). With a little consistency in choosing aliases, 
>> it's then very easy to find out while reading the code where a reference 
>> comes from. 
>>
>> I am also older than most of you guys so the less stuff resides in my 
>> working memory, 
>> the easier I can cheat with the slowly eroding aging process :) 
>> I leave most of the work to the computer. 
>>
>> Mmmh, maybe I should create a pocket guide for elderly Clojure coders 
>> someday... 
>>
>> Luc P. 
>>
>> > 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 AM UTC-5, 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)." 
>> > > 
>> > > The page was last edited on Mar 29, 2011 and ns usage has been 
>> discussed a 
>> > > fair bit since then... this leads to the question: 
>> > > 
>> > >Is the item quoted above still the standard for Clojure Libraries? 
>> > > 
>> > > Thanks. 
>> > > -David 
>> > > 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "Clojure" group. 
>> > To post to this group, send email to clo...@googlegroups.com 
>> > Note that posts from new members are moderated - please be patient with 
>> your first post. 
>> > To unsubscribe from this group, send email to 
>> > clojure+u...@googlegroups.com 
>> > For more options, visit this group at 
>> > http://groups.google.com/group/clojure?hl=en 
>> -- 
>> Softaddicts sent by ibisMail from my ipad! 
>>
>
 

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: transient/persistent! not worth for less than 7-8 operations

[Softaddicts]

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.

> 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 : 459.910320 ns ( 2.5%)
> Execution time upper quantile : 527.008269 ns (97.5%)
> nil
> user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
> nil 6 'a)))
> Evaluation count : 97399860 in 60 samples of 1623331 calls.
>   Execution time mean : 639.789263 ns
>  Execution time std-deviation : 26.265080 ns
> Execution time lower quantile : 597.753127 ns ( 2.5%)
> Execution time upper quantile : 687.838668 ns (97.5%)
> nil
> user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a 0 "z" 2 5)) ;;4 
> operations
> Evaluation count : 68275920 in 60 samples of 1137932 calls.
>   Execution time mean : 901.407416 ns
>  Execution time std-deviation : 35.682637 ns
> Execution time lower quantile : 851.060950 ns ( 2.5%)
> Execution time upper quantile : 970.492949 ns (97.5%)
> 
> Found 1 outliers in 60 samples (1.6667 %)
>  low-severe 1 (1.6667 %)
>   Variance from outliers : 25.4849 % Variance is moderately inflated by 
> outliers
> nil
> user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
> nil 6 'a 0 "z" 2 5)))
> Evaluation count : 68844120 in 60 samples of 1147402 calls.
>   Execution time mean : 893.798444 ns
>  Execution time std-deviation : 24.566655 ns
> Execution time lower quantile : 848.307600 ns ( 2.5%)
> Execution time upper quantile : 952.841308 ns (97.5%)
> 
> Found 13 outliers in 60 samples (21.6667 %)
>  low-severe 7 (11.6667 %)
>  low-mild 6 (10. %)
>   Variance from outliers : 14.2244 % Variance is moderately inflated by 
> outliers
> nil
> user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a 0 "z" 2 5 4 (atom 
> []) 7 "v")) ;;6 operations
> Evaluation count : 39783840 in 60 samples of 663064 calls.
>   Execution time mean : 1.480511 us
>  Execution time std-deviation : 50.249443 ns
> Execution time lower quantile : 1.425053 us ( 2.5%)
> Execution time upper quantile : 1.591407 us (97.5%)
> nil
> user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
> nil 6 'a 0 "z" 2 5 4 (atom []) 7 "v")))
> Evaluation count : 44755020 in 60 samples of 745917 calls.
>   Execution time mean : 1.358394 us
>  Execution time std-deviation : 49.723547 ns
> Execution time lower quantile : 1.306456 us ( 2.5%)
> Execution time upper quantile : 1.473882 us (97.5%)
> nil
> 
> user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a 0 "z" 2 5 4 (atom 
> []) 7 "v" 5 1200 8 -)) ;;8 operations
> Evaluation count : 31457280 in 60 samples of 524288 calls.
>   Execution time mean : 1.907389 us
>  Execution time std-deviation : 74.523511 ns
> Execution time lower quantile : 1.822336 us ( 2.5%)
> Execution time upper quantile : 2.076044 us (97.5%)
> nil
> user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
> nil 6 'a 0 "z" 2 5 4 (atom []) 7 "v" 5 1200 8 -)))
> Evaluation count : 37739640 in 60 samples of 628994 calls.
>   Execution time mean : 1.623599 us
>  Execution time std-deviation : 68.677518 ns
> Execution time lower quantile : 1.529454 us ( 2.5%)
> Execution time upper quantile : 1.777040 us (97.5%)
> 
> Found 1 outliers in 60 samples (1.6667 %)
>  low-severe 1 (1.6667 %)
>   Variance from outliers : 28.6901 % Variance is moderately inflated by 
> outliers
> nil
> 
> 
> etc etc...
> 
> you get the idea...conclusion: there is no real benefit to using 
> transients for less than 6 operations...
> 
> Jim
> 
> 
> 
> 
> On 08/11/12 23:04, Philip Potter wrote:
> >
> > 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 benchmark on a single machine are universally 
> > applicable.
> >
> > Benchmarking is hard, particularly on the jvm. Caching and dynamic 
> > inlining and Hotspot confuse matters greatly.
> >
> > Phil
> >
> > On Nov 8, 2012 10:49 PM, "Jim - FooBar();"  > > wrote:
> >
> > 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

Re: Slow image convolution

[Cedric Greevey]

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 it uses primitive math inside the loops, aside from
> generating the outer loop's values. What cached-load-chunk does shouldn't
> matter much, but in most cases it should boil down to a map lookup inside a
> swap! and a couple of atom derefs and function calls. The bottleneck is
> likely in the math somewhere, and likely something is being boxed, though
> I've primitive-coerced every numerical let and loop value and avoided more
> than two arguments per arithmetic op.
>
> Can anyone spot anything I haven't that could be causing boxed arithmetic
> inside the loops?
>

I've now checked for Var lookups (none outside the caching function, and
now none inside either) and checked the caching code itself (there's a .get
on a closed-over ConcurrentHashMap, a null check, a .get on a
SoftReference, and another null check, on each lookup, if there isn't a
cache miss on that lookup; plus a couple more method calls for the IFn
invokes and an ivar fetch to get the ConcurrentHashMap reference).

In the absence of cache misses I'm still seeing ~3.5 *minutes* at 1280x720
with 10 samples (= about 100 million iterations total of the inner loop).
The arithmetic in there is 23 floating-point ops, five compares, a log, an
atan, and three bitwise ANDs. Without the log and atan a hundred million of
that inner loop should take a second on this box. I very much doubt the log
and the atan are 209 times slower than the rest of it combined. So there's
three likely culprits: boxing, two calls to (rand), and the BufferedImage
.getRGB method call (on a 6000x2198 24bpp image, though its size should
matter not), unless trig is really that slow.

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Slow image convolution

[Cedric Greevey]

(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, 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 it uses primitive math inside the loops, aside from
>> generating the outer loop's values. What cached-load-chunk does shouldn't
>> matter much, but in most cases it should boil down to a map lookup inside a
>> swap! and a couple of atom derefs and function calls. The bottleneck is
>> likely in the math somewhere, and likely something is being boxed, though
>> I've primitive-coerced every numerical let and loop value and avoided more
>> than two arguments per arithmetic op.
>>
>> Can anyone spot anything I haven't that could be causing boxed arithmetic
>> inside the loops?
>>
>
> I've now checked for Var lookups (none outside the caching function, and
> now none inside either) and checked the caching code itself (there's a .get
> on a closed-over ConcurrentHashMap, a null check, a .get on a
> SoftReference, and another null check, on each lookup, if there isn't a
> cache miss on that lookup; plus a couple more method calls for the IFn
> invokes and an ivar fetch to get the ConcurrentHashMap reference).
>
> In the absence of cache misses I'm still seeing ~3.5 *minutes* at 1280x720
> with 10 samples (= about 100 million iterations total of the inner loop).
> The arithmetic in there is 23 floating-point ops, five compares, a log, an
> atan, and three bitwise ANDs. Without the log and atan a hundred million of
> that inner loop should take a second on this box. I very much doubt the log
> and the atan are 209 times slower than the rest of it combined. So there's
> three likely culprits: boxing, two calls to (rand), and the BufferedImage
> .getRGB method call (on a 6000x2198 24bpp image, though its size should
> matter not), unless trig is really that slow.
>
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

ANN Monger 1.3.4

[Michael Klishin]

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% backwards-compatible* release that eliminates more
`data.json` dependencies in `monger.json`.
We recommend all users to upgrade to it as soon as possible.


## Changes between 1.3.3 and 1.3.4

### data.json Dependency Fixes

`monger.json` no longer requires `data.json` to be present at compile time.



## Change Log

We recommend all users to upgrade to 1.3.4 [1] as soon as possible.
Monger change log [2] is available on GitHub.

1. https://clojars.org/com.novemberain/monger/versions/1.3.4
2. https://github.com/michaelklishin/monger/blob/1.3.x-stable/ChangeLog.md

-- 
MK

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Slow image convolution

[Cedric Greevey]

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
minutes with only the arithmetic left in the loop. Either something's
getting boxed or it's the trig calls.


On Thu, Nov 8, 2012 at 8:18 PM, Cedric Greevey  wrote:

> (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, 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 it uses primitive math inside the loops, aside from
>>> generating the outer loop's values. What cached-load-chunk does shouldn't
>>> matter much, but in most cases it should boil down to a map lookup inside a
>>> swap! and a couple of atom derefs and function calls. The bottleneck is
>>> likely in the math somewhere, and likely something is being boxed, though
>>> I've primitive-coerced every numerical let and loop value and avoided more
>>> than two arguments per arithmetic op.
>>>
>>> Can anyone spot anything I haven't that could be causing boxed
>>> arithmetic inside the loops?
>>>
>>
>> I've now checked for Var lookups (none outside the caching function, and
>> now none inside either) and checked the caching code itself (there's a .get
>> on a closed-over ConcurrentHashMap, a null check, a .get on a
>> SoftReference, and another null check, on each lookup, if there isn't a
>> cache miss on that lookup; plus a couple more method calls for the IFn
>> invokes and an ivar fetch to get the ConcurrentHashMap reference).
>>
>> In the absence of cache misses I'm still seeing ~3.5 *minutes* at
>> 1280x720 with 10 samples (= about 100 million iterations total of the inner
>> loop). The arithmetic in there is 23 floating-point ops, five compares, a
>> log, an atan, and three bitwise ANDs. Without the log and atan a hundred
>> million of that inner loop should take a second on this box. I very much
>> doubt the log and the atan are 209 times slower than the rest of it
>> combined. So there's three likely culprits: boxing, two calls to (rand),
>> and the BufferedImage .getRGB method call (on a 6000x2198 24bpp image,
>> though its size should matter not), unless trig is really that slow.
>>
>>
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: transient/persistent! not worth for less than 7-8 operations

[Softaddicts]

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 9 
> 0]) 3 5 6 8
> Elapsed time: 399.466556 msecs
> 
> Luc P.
> 
> > 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 : 459.910320 ns ( 2.5%)
> > Execution time upper quantile : 527.008269 ns (97.5%)
> > nil
> > user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
> > nil 6 'a)))
> > Evaluation count : 97399860 in 60 samples of 1623331 calls.
> >   Execution time mean : 639.789263 ns
> >  Execution time std-deviation : 26.265080 ns
> > Execution time lower quantile : 597.753127 ns ( 2.5%)
> > Execution time upper quantile : 687.838668 ns (97.5%)
> > nil
> > user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a 0 "z" 2 5)) ;;4 
> > operations
> > Evaluation count : 68275920 in 60 samples of 1137932 calls.
> >   Execution time mean : 901.407416 ns
> >  Execution time std-deviation : 35.682637 ns
> > Execution time lower quantile : 851.060950 ns ( 2.5%)
> > Execution time upper quantile : 970.492949 ns (97.5%)
> > 
> > Found 1 outliers in 60 samples (1.6667 %)
> >  low-severe 1 (1.6667 %)
> >   Variance from outliers : 25.4849 % Variance is moderately inflated by 
> > outliers
> > nil
> > user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
> > nil 6 'a 0 "z" 2 5)))
> > Evaluation count : 68844120 in 60 samples of 1147402 calls.
> >   Execution time mean : 893.798444 ns
> >  Execution time std-deviation : 24.566655 ns
> > Execution time lower quantile : 848.307600 ns ( 2.5%)
> > Execution time upper quantile : 952.841308 ns (97.5%)
> > 
> > Found 13 outliers in 60 samples (21.6667 %)
> >  low-severe 7 (11.6667 %)
> >  low-mild 6 (10. %)
> >   Variance from outliers : 14.2244 % Variance is moderately inflated by 
> > outliers
> > nil
> > user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a 0 "z" 2 5 4 (atom 
> > []) 7 "v")) ;;6 operations
> > Evaluation count : 39783840 in 60 samples of 663064 calls.
> >   Execution time mean : 1.480511 us
> >  Execution time std-deviation : 50.249443 ns
> > Execution time lower quantile : 1.425053 us ( 2.5%)
> > Execution time upper quantile : 1.591407 us (97.5%)
> > nil
> > user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
> > nil 6 'a 0 "z" 2 5 4 (atom []) 7 "v")))
> > Evaluation count : 44755020 in 60 samples of 745917 calls.
> >   Execution time mean : 1.358394 us
> >  Execution time std-deviation : 49.723547 ns
> > Execution time lower quantile : 1.306456 us ( 2.5%)
> > Execution time upper quantile : 1.473882 us (97.5%)
> > nil
> > 
> > user=> (bench (assoc [1 2 3 4 5 6 7 8 9 0] 3 nil 6 'a 0 "z" 2 5 4 (atom 
> > []) 7 "v" 5 1200 8 -)) ;;8 operations
> > Evaluation count : 31457280 in 60 samples of 524288 calls.
> >   Execution time mean : 1.907389 us
> >  Execution time std-deviation : 74.523511 ns
> > Execution time lower quantile : 1.822336 us ( 2.5%)
> > Execution time upper quantile : 2.076044 us (97.5%)
> > nil
> > user=> (bench (persistent! (assoc! (transient [1 2 3 4 5 6 7 8 9 0]) 3 
> > nil 6 'a 0 "z" 2 5 4 (atom []) 7 "v" 5 1200 8 -)))
> > Evaluation count : 37739640 in 60 samples of 628994 calls.
> >   Execution time mean : 1.623599 us
> >  Execution time std-deviation : 68.677518 ns
> > Execution time lower quantile : 1.529454 us ( 2.5%)
> > Execution time upper quantile : 1.777040 us (97.5%)
> > 
> > Found 1 outliers in 60 samples (1.6667 %)
> >  low-severe 1 (1.6667 %)
> >   Variance from outliers : 28.6901 % Variance is moderately inflated by 
> > outliers
> > nil
> > 
> > 
> > etc etc...
> > 
> > you get the idea...conclusion: there is no real benefit to using 
> > transients for less than 6 operations...
> > 
> > Jim
> > 
> > 
> > 
> > 
> > On 08/11/12 23:04, Philip Potter wrote:
> > >
> > > 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 benchmark on a single machine are universally 
> > > applicable.
> > >
> > > Benchmarking is hard, particularly on the jvm. Caching and dynamic 
> > > inlining and Hotspot confuse matters grea

Re: [ANN] new book: "ClojureScript: Up and Running"

[Sean Corfield]

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 -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

`CompilerException` raised when running `Monger` code snippet

[Satoru Logic]

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.RuntimeException: First argument to def must 
be a Symbol, compiling:(NO_SOURCE_PATH:3)

I found this `macro` in the source code of `Monger`, so I guess it should 
be a valid `macro`, maybe this can't be run in `repl`?

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: transient/persistent! not worth for less than 7-8 operations

[Herwig Hochleitner]

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 that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: `CompilerException` raised when running `Monger` code snippet

[Justin Kramer]

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 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.RuntimeException: First argument to def 
> must be a Symbol, compiling:(NO_SOURCE_PATH:3)
>
> I found this `macro` in the source code of `Monger`, so I guess it should 
> be a valid `macro`, maybe this can't be run in `repl`?
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: `CompilerException` raised when running `Monger` code snippet

[Satoru Logic]

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 UTC-5, Satoru Logic wrote:
>>
>> 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.RuntimeException: First argument to def 
>> must be a Symbol, compiling:(NO_SOURCE_PATH:3)
>>
>> I found this `macro` in the source code of `Monger`, so I guess it should 
>> be a valid `macro`, maybe this can't be run in `repl`?
>>
>

-- 
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 from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: list of special forms that introduce bindings?

[Herwig Hochleitner]

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 subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en