Re: Performant string concatenation (of many, large strings)

[Herwig Hochleitner]

Also, since you probably want defined order of columns for CSV, replace

(map #(interpose ", " (vals %)))

with

(map #(interpose ", " (map % [:one :two :three :four])))

in the str - sequence version

or

#(eduction (comp (map val) (interpose-xf ", ")) %)

with

#(eduction (comp (map %) (interpose-xf ", "))
   [:one :two :three :four])

respectively

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Performant string concatenation (of many, large strings)

[Herwig Hochleitner]

The most versatile way to do this is a pattern, I like to call concatenated
lists of strings.

You implement the parts as functions returning sequences of strings.
You combine parts with concat. And map parts over input data with mapcat.
Interpose and interleave have the role of str/join.
Another useful macro for this style is forcat here:
https://github.com/webnf/webnf/blob/master/base/src/webnf/base/utils.clj#L32

At the very top level, you can either (apply str (toplevel-part data)) or
write the string parts directly to a socket, like ring does.
In clojure, this is already pretty efficient, thanks to lazy sequences.

(do (time
 (->> data-struct
  (map #(interpose ", " (vals %)))
  (interpose [\newline])
  (apply concat)
  (apply str)))
nil)
; => "Elapsed time: 1104.311277 msecs"

If you still want to save on the allocation of the lazy sequence, you could
write it in reducer style with a StringBuilder as state and .append as a
step function.

(defn interpose-xf
  "A transducer version of interpose"
  [sep]
  (fn [xf]
(let [is-first (volatile! true)]
  (completing
   (fn [s v]
 (-> (if @is-first
   (do (vreset! is-first false) s)
   (xf s sep))
 (xf v)))

(defn sb-append [sb s] (.append ^StringBuilder sb (str s)))

(do (time (str (transduce
(comp (map #(eduction (comp (map val) (interpose-xf ", "))
%))
  (interpose-xf [\newline])
  cat)
sb-append
(StringBuilder.) data-struct)))
nil)
; => "Elapsed time: 578.444552 msecs"

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let bindings and immutability

[James Reeves]

On 12 February 2015 at 02:06, gvim  wrote:
>
> That explains it but I think Clojure's syntax is misleading here. Without
> knowledge of this magic the mind doesn't readily translate:
>
> (let [x 1
> x (inc x)
> x (inc x)
> x (inc x)]
>x)
>
>  into:
>
> (let [x 1]
>   (let [x (inc x)]
> (let [x (inc x)]
>   (let [x (inc x)]
>   x
>

It's not magic; it's just how the syntax is defined. The for and doseq
forms have the same behaviour.

Languages like Racket that are perhaps more focused on teaching do have
separate let and let* forms. However, Clojure has a more practical focus,
and there isn't much practical point in having a non-shadowing let.

- James

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] closp - leiningen template combining luminus and chestnut + some more features

[Alan Moore]

FYI - I found the tool I mentioned @ modularity.org

Alan


On Wednesday, February 11, 2015 at 7:11:31 PM UTC-8, Alan Moore wrote:
>
> Nice - thanks! 
>
> I was thinking it would be cool to create a meta-lein template that would 
> allow the user to specify which libraries (or features?) to include and the 
> template would (magic happens here) pull in each library and make the 
> needed mods to the base template. 
>
> Obviously this would require each library to specify the stuff they need 
> done to get integrated/merged into the base template (add these 
> dependencies to project.clj, add these html snippets, etc.) Opportunities 
> for conflicts abound and versioning issues, etc. probably make this too 
> hard. I'm not sure it is worth doing due to the open ended nature of 
> libraries/fiddly bits but it sure would be handy. 
>
> I remember seeing a project on github that does something like this using 
> a library approach (not via a lein template) but I can't remember the name 
> of it... 
>
> Also, did you look into using feature expressions instead of cljx? 
>
> Thanks again for this template! I'm going to give it a spin right now... 
>
> Alan 
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] closp - leiningen template combining luminus and chestnut + some more features

[Alan Moore]

Nice - thanks!

I was thinking it would be cool to create a meta-lein template that would allow 
the user to specify which libraries (or features?) to include and the template 
would (magic happens here) pull in each library and make the needed mods to the 
base template.

Obviously this would require each library to specify the stuff they need done 
to get integrated/merged into the base template (add these dependencies to 
project.clj, add these html snippets, etc.) Opportunities for conflicts abound 
and versioning issues, etc. probably make this too hard. I'm not sure it is 
worth doing due to the open ended nature of libraries/fiddly bits but it sure 
would be handy.

I remember seeing a project on github that does something like this using a 
library approach (not via a lein template) but I can't remember the name of 
it...

Also, did you look into using feature expressions instead of cljx?

Thanks again for this template! I'm going to give it a spin right now...

Alan

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: OO Programmer trying to move to Clojure: Encapsulation

[Herwig Hochleitner]

Hm, the most common way to encapsulate in clojure is with a closure:

Your account repository would be:

(defn account-repository [connection]
  ;; <- here goes additional constructor logic
  (fn save [account]
(sql-save connection account))

If the repository has more methods than just save, you can return a map of
functions, or an implementation of a protocol / interface.

In my experience, component is most useful when talking to stateful APIs at
the fringes of the application. There you need lifecycle methods to let the
user (or system) nudge the application from one state to the next,
observing and doing stuff along the edges. But the meat of an application
(calculating what to do) can normally be stateless functions over data.

A recent alternative for when there are only two lifecycle events around a
single updater method (construct, finish, step), are transducers.

hth, kind regards
​

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let bindings and immutability

[Herwig Hochleitner]

2015-02-12 3:06 GMT+01:00 gvim :

>
> That explains it but I think Clojure's syntax is misleading here. Without
> knowledge of this magic the mind doesn't readily translate:
>
>
In some other lisps, clojure's let is called let* for this reason. Their
let binds only in parallel, similar to clojure's (binding []) form for vars.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is this the good way to write get-percentage

[Matching Socks]

There was also some discussion of this back in November, where Fluid
Dynamics suggested higher-order functions, and tbc++, multimethods(!).

The main source of complexity in get-percentage has to do with
selecting what it should do.  Also, both percentage computation and
rounding could potentially be useful on their own without the other.
Those considerations recommend higher order functions.  Using
higher-order functions can make the code shorter, clearer, and more
flexible.

First, there's the essential computation:

(defn pct [p t] (/ (* p 100.0) t))

Second, various general-purpose ways to round floating-point numbers:

(defn round-up [x]   (int (Math/ceil x)))
(defn round-down [x] (int (Math/floor x)))
(defn round [x]  (int (Math/round x)))

To put them together, get-percentage took a hint about the rounding
function, dispatched on the hint, and took upon itself responsibility
for detecting a bogus hint.  Instead of a hint from a closed set, why
not let the caller pass in the rounding function itself?  Now
get-percentage is down to one line:

(defn get-percentage* [f p t] (f (pct p t)))

For example

(get-percentage* round-up 4 30)
14
(get-percentage* round-down 4 30)
13

Alternatively, the standard function "comp" can produce your canned
combinations, so you might not need get-percentage* itself anymore:

(def get-percentage-high (comp round-up pct))

For example:

(get-percentage-high 4 30)
14


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let bindings and immutability

[Herwig Hochleitner]

I think that, from a user perspective, the important difference from
mutation to shadowing is, that outer x is available even in the inner
context, if captured by a closure.
Likewise, a second thread, that runs an outer closure, would see the
original x.
Observe:

(let [x :outer
  f (fn [] x)
  x :inner]
  (println (f)) ; => :outer
  (println x))  ; => :inner

Shadowing can still be confusing to a smaller extent, so I like to call
shadowed versions x, x', x'', aso.

regards

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7.0-alpha5 clobber warning error?

[Andy Fingerhut]

Sam:

I believe if you proceed to do the following in your REPL:

(in-ns 'monger.collection)
(doc update)

You will see that the name 'update' _from within the namespace
monger.collection_ refers to monger.collection/update, not
clojure.core/update.

That is what the message is intended to convey.

In the user namespace where you are making your doc calls, the name update
still refers to clojure.core/update.

Andy

On Wed, Feb 11, 2015 at 5:53 PM, Sam Raker  wrote:

> I just added monger as a dependency to my Clojure 1.7.0-alpha5 project,
> and saw the following in my repl:
>
> user=> (require '(monger [core :as mg] [collection :as mc]))
> WARNING: update already refers to: #'clojure.core/update in namespace:
> monger.collection, being replaced by: #'monger.collection/update
>
> That warning seems to be in error, though, because `(doc update)` and
> `(doc mc/update)` print different (and correct) things.
>
> Is this a bug? Should I file something somewhere?
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let bindings and immutability

[gvim]

On 12/02/2015 01:53, Ben Wolfson wrote:

The multiple-binding form of let can be recursively transformed into
nested lets:

(let [name1 value1 name2 value2 ... name value] body)
>
(let [name1 value1] (let [name2 value2] ...  (let [name value] body)))

All you're doing with your let form is shadowing the name; there's no
mutation. If you had something like this:

(let [x 1]
(let [x (inc x)]
  (println x))  ;; prints 2
(println x)) ;; prints 1

it would be more obvious; it's less apparent in your case because
there's no room for the extra forms.



That explains it but I think Clojure's syntax is misleading here. 
Without knowledge of this magic the mind doesn't readily translate:


(let [x 1
x (inc x)
x (inc x)
x (inc x)]
   x)


 into:

(let [x 1]
  (let [x (inc x)]
(let [x (inc x)]
  (let [x (inc x)]
  x

The single bracket pair in the original leads the unwitting newcomer to 
assume all the x'es are in the same scope.


gvim






--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let bindings and immutability

[Ambrose Bonnaire-Sergeant]

Local bindings are immutable.

Your example demonstrates lexical shadowing of bindings.

This is an equivalent program semantically.

(let [x   1
  x_1 (inc x)
  x_2 (inc x_1)
  x_3 (inc x_2)]
  x_3)

By the rules of lexical scoping, you cannot access the first `x` but it is
never mutated.

Thanks,
Ambrose

On Wed, Feb 11, 2015 at 8:42 PM, gvim  wrote:

> Why is this possible in a language based on immutability:
>
> (let [x 1
> x (inc x)
> x (inc x)
> x (inc x)]
>x)
>
> ;;=> 4
>
> Maybe under the hood (ie. memory registers/pointers etc.) this isn't
> strictly mutation but as a relative newcomer to Clojure I find it goes
> against the grain of what I find elsewhere in the language.
>
> gvim
>
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let bindings and immutability

[Justin Smith]

(let [x 0
   f #(println x)
   x 1
   g #(println x)
   x 2]
  (f)
  (g)
  x)

there is no mutation of x, only scope shadowing hiding the other binding. Most 
functional languages (all that I know) allow shadowing.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let bindings and immutability

[Ben Wolfson]

The multiple-binding form of let can be recursively transformed into nested
lets:

(let [name1 value1 name2 value2 ... name value] body)
>
(let [name1 value1] (let [name2 value2] ...  (let [name value] body)))

All you're doing with your let form is shadowing the name; there's no
mutation. If you had something like this:

(let [x 1]
   (let [x (inc x)]
 (println x))  ;; prints 2
   (println x)) ;; prints 1

it would be more obvious; it's less apparent in your case because there's
no room for the extra forms.


On Wed, Feb 11, 2015 at 5:49 PM, gvim  wrote:

> On 12/02/2015 01:44, Laurens Van Houtven wrote:
>
>> Hi,
>>
>> You're confusing mutation with single assignment. You're not mutating
>> anything: 1 is still 1, 2 is still 2; you're just assigning the same name
>> to different numbers. The numbers themselves are immutable.
>>
>>
> It's x that bothers me, not the values assigned to it. I don't quite get
> it as x seems to behave here like any old mutable variable in Ruby or
> Python even if it's not called mutation. I suppose I've just never really
> "got" this (big) one :(
>
>
> gvim
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

1.7.0-alpha5 clobber warning error?

[Sam Raker]

I just added monger as a dependency to my Clojure 1.7.0-alpha5 project, and 
saw the following in my repl:

user=> (require '(monger [core :as mg] [collection :as mc]))
WARNING: update already refers to: #'clojure.core/update in namespace: 
monger.collection, being replaced by: #'monger.collection/update

That warning seems to be in error, though, because `(doc update)` and `(doc 
mc/update)` print different (and correct) things.

Is this a bug? Should I file something somewhere?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let bindings and immutability

[gvim]

On 12/02/2015 01:44, Laurens Van Houtven wrote:

Hi,

You’re confusing mutation with single assignment. You’re not mutating anything: 
1 is still 1, 2 is still 2; you’re just assigning the same name to different 
numbers. The numbers themselves are immutable.



It's x that bothers me, not the values assigned to it. I don't quite get 
it as x seems to behave here like any old mutable variable in Ruby or 
Python even if it's not called mutation. I suppose I've just never 
really "got" this (big) one :(


gvim

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let bindings and immutability

[Laurens Van Houtven]

Hi,


> On Feb 11, 2015, at 5:42 PM, gvim  wrote:
> 
> Why is this possible in a language based on immutability:
> 
> (let [x 1
>x (inc x)
>x (inc x)
>x (inc x)]
>   x)
> 
> ;;=> 4
> 
> Maybe under the hood (ie. memory registers/pointers etc.) this isn't strictly 
> mutation but as a relative newcomer to Clojure I find it goes against the 
> grain of what I find elsewhere in the language.


You’re confusing mutation with single assignment. You’re not mutating anything: 
1 is still 1, 2 is still 2; you’re just assigning the same name to different 
numbers. The numbers themselves are immutable.


hth
lvh

> gvim
> 
> 
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Let bindings and immutability

[gvim]

Why is this possible in a language based on immutability:

(let [x 1
x (inc x)
x (inc x)
x (inc x)]
   x)

;;=> 4

Maybe under the hood (ie. memory registers/pointers etc.) this isn't 
strictly mutation but as a relative newcomer to Clojure I find it goes 
against the grain of what I find elsewhere in the language.


gvim


--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Improving stacktraces in your custom ClojureScript REPL (Cider, Weasel, ...)

[David Nolen]

This message is mostly aimed at Clojure and ClojureScript REPL developers -
Cider, Weasel, etc. I've written up some details on how to integrate the
new automatic source mapping functionality:

https://github.com/clojure/clojurescript/wiki/Custom-REPLs#source-mapping

Feedback welcome and preferably soon as I would like to wrap this up pretty
quickly into something that everyone can live with.

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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Performant string concatenation (of many, large strings)

[mark]

I'm looking for the most performant way to transform a huge seq (size 
25) of maps into a single CSV.

The data structure looks something like:

(def data-struct

  (repeat 25 {:one 1 :two 2 :three 3 :four 4}))


A naive implementation would be:

(let [f #(->> % (map (comp str val)) (clojure.string/join ","))]

  (->> data-struct

(map f)

(clojure.string/join "\n")))


However, this takes far too long for my application (an the order of 10s of 
seconds).

Another attempt using reducers:

(require '[clojure.core.reducers :as r])

 

(let [f #(->> % (map (comp str val)) (clojure.string/join ","))

  r-join (fn

   ([] nil)

 ([x y]

  (if (and x y) (str x "\n" y)

(if x (str x)

  (if y (str y))]

  (->> data-struct

(r/map f)

(r/fold r-join)))


Still not great.

But, Looking at the sources of clojure.string/join and clojure.core/str, it 
becomes apparent that the both implementations create an instance of 
java.lang.StringBuilder 
for each element in the sequence. (I have to imagine this is the main 
issue, even though GC seems to only be ~5% of the runtime)

Would it make sense to instantiate one java.lang.StringBuilder for all of 
the concatenation (and call java.lang.StringBuilder append)?

What's the best way to do this with idiomatic Clojure?

Thanks a lot!

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question about ClojureScript Testing

[David Nolen]

You can run tests in any REPL that ships with ClojureScript - we include
two JVM based ones Rhino and Nashorn. Rhino is older and more mature.
Nashorn probably needs some further work to be good for testing. Patches
welcome. Both of these options suffer from different forms of slowness
(Rhino is just slow, Nashorn is slow to start) so I'm not sure I'd
recommend them wholeheartedly. But they are there and and I'm happy to see
them improved by the community for your purposes in whatever way they can
reasonably be.

David

On Wed, Feb 11, 2015 at 8:16 PM, Elric Erkose 
wrote:

> Thanks, I've seen figwheel. It doesn't address what I'm asking.
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question about ClojureScript Testing

[Elric Erkose]

Thanks, I've seen figwheel. It doesn't address what I'm asking. 

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] closp - leiningen template combining luminus and chestnut + some more features

[martin_clausen]

Link: https://github.com/sveri/closp

On Wednesday, February 11, 2015 at 11:59:20 AM UTC+1, Sven Richter wrote:
>
> Hi,
>
> I took some time to put together a leiningen template which combines the 
> awesome proecjts luminus and chestnut and adds some more features to start 
> development sideprojects for the web without much hassle.
> The rationale behind this is that I found myself adding these features 
> again and again for every new project and I wanted to stop that.
>
> Features:
>
> * H2 database on filesystem as a default
> * Ragtime for database migrations
> * Selmer as templating solution
> * http-kit as a server
> * cljx support
> * Figwheel with clojurescript live reloading
> * Reloading support for templates and clojure code
> * Configuration with nomad
> * User management with login/logout/registration with email activation 
> (provided by postal)
> * Authentication provided by buddy
> * reagent and datascript on frontend side
> * Ring Antiforgery middleware
> * Clojure miniprofiler example
> * Componentized application
> * Datascript with reagent example
> * Booststrap css styles
>
> As always I am happy about any kind of feedback, pull requests or whatever 
> comes to your mind.
>
>
>
> Best Regagrds,
> Sven
>
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question about ClojureScript Testing

[Stephen Nelson]

That's really not the answer Elric is looking for. Figwheel does all the
things you're talking about but doesn't provide a javascript execution
environment, which is required for running tests (which you might want for
testing in a CI environment, for example).

If you want a purely leiningen/JVM solution you will need to execute your
tests using rhino or nashorn, both JVM javascript VMs.

Cljsbuild provides rhino hooks, see
https://github.com/cemerick/clojurescript.test for example.

Most people tend to use non-JVM tools for cljs testing because native
engines tend to be faster. Phantom also provides a browser stack, which is
necessary for testing anything dom-related.

You might get more feedback on clojurescript issues by posting on the
clojurescript mailing list.

Stephen

On Thu, Feb 12, 2015 at 10:44 AM, Mike Thompson 
wrote:

>
>
> On Thursday, February 12, 2015 at 6:29:10 AM UTC+11, Elric Erkose wrote:
>>
>> I started looking at coljurescript testing yesterday and find it
>> disappointing that every example I find focuses on pantomjs. I'm looking
>> for a solution that doesn't require external software. By external
>> software, I mean anything that is not "jared" up and accessible through
>> lein. I haven't played with the clojurescript repl. Is there a testing
>> solution that relies on the repl envioment?
>>
>
>
> Sounds like you might be looking for figwheel  -
> https://github.com/bhauman/lein-figwheel   It provides a repl,
> auto-reloading etc.
>
> Here's a template project for the combination of figwheel and reagent:
> https://github.com/gadfly361/reagent-figwheel
>
> On a different track, here's a way to use:"optimizations :none"
> https://github.com/mike-thompson-day8/cljsbuild-none-test-seed
>
> --
> Mike
>
>
>  --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is this the good way to write get-percentage

[Michael Blume]

I think you could replace your condp = with case, since all your mode
keywords are known at compile-time, otherwise looks about right.

On Tue Feb 10 2015 at 11:32:58 PM Cecil Westerhof 
wrote:

> I needed a function to get the percentage as an int. Input is place and
> total-count.
> I want the normal definition (which is the default) and a high and low
> variant.
>
> I came up with the following code:
> (defn get-percentage
>   ([place total-count] (get-percentage :normal place total-count))
>   ([mode place total-count]
> (let [percentage (/ (* place 100.0) total-count)]
>   (condp = mode
> :high (int (Math/ceil  percentage))
> :low  (int (Math/floor percentage))
> :normal   (int (Math/round percentage))
> (throw (Exception. "ERROR: get-percentage [:high|:low|:normal]
>  "))
>
> Is this a good version, or could it be done better?
>
> --
> Cecil Westerhof
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question about ClojureScript Testing

[Mike Thompson]

On Thursday, February 12, 2015 at 6:29:10 AM UTC+11, Elric Erkose wrote:
>
> I started looking at coljurescript testing yesterday and find it 
> disappointing that every example I find focuses on pantomjs. I'm looking 
> for a solution that doesn't require external software. By external 
> software, I mean anything that is not "jared" up and accessible through 
> lein. I haven't played with the clojurescript repl. Is there a testing 
> solution that relies on the repl envioment?
>


Sounds like you might be looking for figwheel  -  
https://github.com/bhauman/lein-figwheel   It provides a repl, 
auto-reloading etc. 

Here's a template project for the combination of figwheel and reagent:  
https://github.com/gadfly361/reagent-figwheel

On a different track, here's a way to use:"optimizations :none"  
https://github.com/mike-thompson-day8/cljsbuild-none-test-seed 

--
Mike


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending the LispReader with "embeded language lorms"

[Steven Yi]

For what it's worth, I see two things intertwined here, one being the 
desire to embed text in an arbitrary format and interpret it, the other 
being the mechanism in which you're doing it.  To me, it seems you can do 
the kinds of things you have shown as examples by using just functions, 
macros, and strings, without having to resort to arbitrary reader 
extension.  If you embed things as strings, say, similarly to how 
instaparse works, then you can still read in CSV text, code in other 
languages, etc. For example, rewriting your csv example using 
macros/functions/string:

(def parse-csv 
  (insta/parser "
  file = record  (line-break record)*
  <_> = <\" \"+>
   = '\u000D'
   = <'\u000A'>
   = CR LF
   = CRLF | CR | LF
   = <#\" *, *\">
   = unquoted-field | quoted-field
  unquoted-field = #\"[a-zA-Z0-9]*\"
  quoted-field = <'\"'> #\"[^\\\"\\n\\r]*\" <'\"'>
  record = _? field (field-sep field)* _?"))

(defmacro parse-csv! [csv]
  (parse-csv csv))

(parse-csv! " 
 foo , \"bar man ccc\",  boo
 fred , fox
")

Now, while going through and quoting text is inconvenient, it's just that. 
It doesn't limit one from still using existing mechanisms to interpret text 
at run-time or compile-time via functions and macros respectively. 

To get around the inconvenience of quoting, having here docs, or 
triple-quoted strings ala Python, as a first-class construct in Clojure 
could address that.  It's a smaller change that would seem to address 
making convenient what you're doing, but without the bigger costs that 
would occur with arbitrary reader extension. At least with this, the rest 
of the Clojure language remains the same (homoiconicity, commas as white 
space, indenting is insignificant, etc.). The only change that ripples out 
to users and tooling is that a string has a new way of being defined. (To 
note, alternate string quoting has been proposed at [1], which includes a 
link to an implementation of triple-quote reading, but this design page 
seems to have been around a while...) 

[1] - http://dev.clojure.org/display/design/Alternate+string+quote+syntaxes






On Wednesday, February 11, 2015 at 3:59:45 AM UTC-5, Henrik Heine wrote:
>
> Hi,
>
> Am Dienstag, 10. Februar 2015 21:07:50 UTC+1 schrieb Gary Verhaegen:
>>
>> For the sake of completeness, in this context "other users" is not 
>> limited to humans: what about IDE support? Refactoring tools? Code analysis?
>
>
> I agree. You lock out "others" and that takes away a lot. For me that's 
> the main argument against my proposal.
>
> I was not thinking to copy&paste huge CSV data in to Clojure files. I'm 
> thinking more about in-line configuration that you can copy&paste to/from 
> other sources, test data, maybe literate programming (haven't worked that 
> out though). But not only "data stuff" could be in-lined: prolog code, SQL 
> statements compiled to the corresponding Clojure libs. OK - the indirection 
> through an external file does not cost that much.
>
> You could even use it to try out new Clojure features (like reader 
> conditionals) without touching one line of Clojure core - just make it a 
> #[CLJxxx ...] form and play around with it before you move it over to the 
> Clojure core code. And you could back-port things just by supplying a 
> lib/function. In this case the "embedded syntax" would still be Clojure.
>
> I still feel like being "new to Clojure", so thanks for all the replies 
> and the insights into "The Clojure Way".
>
> Henrik
>
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Question about ClojureScript Testing

[Elric Erkose]

I started looking at coljurescript testing yesterday and find it 
disappointing that every example I find focuses on pantomjs. I'm looking 
for a solution that doesn't require external software. By external 
software, I mean anything that is not "jared" up and accessible through 
lein. I haven't played with the clojurescript repl. Is there a testing 
solution that relies on the repl envioment?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: OO Programmer trying to move to Clojure: Namespace Organization

[Colin Yates]

I wouldn't get too hung up on imitation as whilst there are style
guides [1] I you will find a lot of diversity in "published" Clojure
code.

I would suggest you internalise the style guide, lean on "lein kibit"
and "lein eastwood" and then do some navel gazing and ask yourself
what problem you are trying to solve. Not to get all meta, but I often
find seemingly "obvious" questions can hide a whole bunch of risk and
complexity.

For example, some answers (as to why you are looking for this
"standardisation") are:
 - I obsess over details whilst not actually caring about the answer -
somebody just make a decision!
 - I care very much about this and have a strong opinion on how I
should do it but I want to make sure I am not in conflict with prior
art
 - I plan on publishing this work and want the lowest barrier to entry
 - I want to make this future proof and/or I have a team of people who
all need to find this intuitive

and so on. Each answer would leave to a slightly different direction.

Alternatively, ignore completely the above (except the style guide and
lein references ;)), grab a cup of coffee and just start writing some
code :)

[1] https://duckduckgo.com/?t=lm&q=clojure+style+guide

On 11 February 2015 at 15:21, Dru Sellers  wrote:
> Yeah, it wouldn't surprise me if I'm over thinking it too much. But in the
> model of 'shu-ha-ri' I am still very much in the shu stage so i'm looking
> for concrete stuff to imitate. :)
>
> Thank you everyone for the ideas and thoughts,
>
> -d
>
>
> On Saturday, February 7, 2015 at 10:23:43 AM UTC-6, Dru Sellers wrote:
>>
>> Greetings,
>>
>> I am trying to convert my mind from OO (C#) to one more functionally
>> friendly. I am increasingly comfortable with simple applications in clojure,
>> but as I start to build more complex applications, I start to fall down
>> about how to structure my application. I don't want to just shove OO ideas
>> into the functional nature of Clojure. I'm looking for any help someone can
>> provide to help shimmy my brain into the right mental patterns.
>>
>> Background: Long time C# developer who leans heavily on IoC / DI /
>> Interfaces / Testing / Object Encapsulation.
>>
>> Specific Questions: Namespace Organization
>>
>> Now I know this is almost entirely personal preference, but I'm playing
>> with a namespace model that looks like this and I'd love some feed back.
>> Tear it about, bust that red pen out and help me to better think of things
>> in clojure way. I only have my C# / OO background to lean on and need some
>> fresh brain juice. :)
>>
>> I currently organize my projects like this. a spin off of 'duct'
>> https://github.com/weavejester/duct but i'm looking for a bit more detail.
>>
>> Context: Project name is going to be "ford", feature is going to be a
>> simple log of text
>>
>>
>> ~/
>>   src/
>> ford/ - the project
>>   log/ - the feature name
>> http.clj - contains clojure routes at 'http/routes' - orchestrate
>> the business calls
>> model.clj - contains my 'defrecords' / yesql / db calls
>> core.clj - the "business" calls
>>
>>
>> I def have a preference for shorter files rather than longer files
>> I also tend to have a heavy use of 'ceremony' - right now I need a lot of
>> structure because I'm still learning to think in terms of clojure. and I
>> spend a lot of time still reading it rather than thinking about it.
>>
>> Again, thank you.
>>
>> -d
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: OO Programmer trying to move to Clojure: Namespace Organization

[Dru Sellers]

Yeah, it wouldn't surprise me if I'm over thinking it too much. But in the 
model of 'shu-ha-ri' I am still very much in the shu stage so i'm looking 
for concrete stuff to imitate. :) 

Thank you everyone for the ideas and thoughts,

-d

On Saturday, February 7, 2015 at 10:23:43 AM UTC-6, Dru Sellers wrote:
>
> Greetings,
>
> I am trying to convert my mind from OO (C#) to one more functionally 
> friendly. I am increasingly comfortable with simple applications in 
> clojure, but as I start to build more complex applications, I start to fall 
> down about how to structure my application. I don't want to just shove OO 
> ideas into the functional nature of Clojure. I'm looking for any help 
> someone can provide to help shimmy my brain into the right mental patterns.
>
> Background: Long time C# developer who leans heavily on IoC / DI / 
> Interfaces / Testing / Object Encapsulation.
>
> Specific Questions: Namespace Organization
>
> Now I know this is almost entirely personal preference, but I'm playing 
> with a namespace model that looks like this and I'd love some feed back. 
> Tear it about, bust that red pen out and help me to better think of things 
> in clojure way. I only have my C# / OO background to lean on and need some 
> fresh brain juice. :)
>
> I currently organize my projects like this. a spin off of 'duct' 
> https://github.com/weavejester/duct but i'm looking for a bit more detail.
>
> Context: Project name is going to be "ford", feature is going to be a 
> simple log of text
>
>
> ~/
>   src/
> ford/ - the project
>   log/ - the feature name
> http.clj - contains clojure routes at 'http/routes' - orchestrate 
> the business calls
> model.clj - contains my 'defrecords' / yesql / db calls
> core.clj - the "business" calls
>
>
> I def have a preference for shorter files rather than longer files
> I also tend to have a heavy use of 'ceremony' - right now I need a lot of 
> structure because I'm still learning to think in terms of clojure. and I 
> spend a lot of time still reading it rather than thinking about it.
>
> Again, thank you.
>
> -d
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Anyone know why cheat sheet links sometimes don't keep anchors?

[Gary Verhaegen]

Sometimes, when I go to the clojure.org website, I see my address bar
flashing a few urls on the wikispaces domain. I would look in that
direction: these redirects might not keep the fragment in the url.

I do not think this is related to the cheat sheet itself; i seem to
remember losong fragments on google search result links too, though I did
not keep notes.

On Wednesday, 11 February 2015, Andy Fingerhut 
wrote:

> There are multiple links in the Clojure cheat sheet here:
>
>
> http://jafingerhut.github.io/cheatsheet/clojuredocs/cheatsheet-tiptip-cdocs-summary.html
>
> that go to clojure.org/somewhere#some-anchor
>
> For example, in the "Special Forms" section, and the sub-section "Binding
> Forms / Destructuring", there is a link "(examples)" that (tries to) go to
> the URL: http://clojure.org/special_forms#binding-forms
>
> Often when I click on it for the first time in a while, it will lose the
> anchor and instead go to:
>
> http://clojure.org/special_forms
>
> If I hit back in my browser and click on the same link again, this time it
> keeps the whole URL, including the anchor.   I have tested Safari on Mac OS
> X 10.9.5, which definitely does this, sometimes.  It does not happen all of
> the time, so I am not yet sure whether it happens with other browsers like
> Firefox 35.0.1 and recent Chrome, too.
>
> Other links that sometimes exhibit this behavior:
>
> 4 links "literals" in the Primitives/Other section, all of which should go
> to here: http://clojure.org/reader#The%20Reader--Reader%20forms  but
> sometimes I see it go to http://clojure.org/reader instead.
>
> 5 links in "Reader Macros" section -- not the ones to quote, var, or
> deref, but the ones appearing first in the descriptions.
>
> Anyone else see this behavior?  More importantly, can anyone explain why
> it happens, and/or how the behavior can be prevented?  If it is simply a
> bug in Safari, then I won't worry too much about it.
>
> Thanks,
> Andy
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: OO Programmer trying to move to Clojure: Encapsulation

[Dru Sellers]

Thank you everyone for all of the helpful ideas.

I def like the Component library and I will have to sit down and figure out 
how to best work that into my application while it is still young.
All of the links have been consumed and I am starting to absorb more and 
more. Thank you for taking the time to share your thoughts and ideas with 
me.

-d

On Saturday, February 7, 2015 at 10:07:45 AM UTC-6, Dru Sellers wrote:
>
> Greetings,
>
> I am trying to convert my mind from OO (C#) to one more functionally 
> friendly. I am increasingly comfortable with simple applications in 
> clojure, but as I start to build more complex applications, I start to fall 
> down about how to structure my application. I don't want to just shove OO 
> ideas into the functional nature of Clojure. I'm looking for any help 
> someone can provide to help shimmy my brain into the right mental patterns.
>
> Background: Long time C# developer who leans heavily on IoC / DI / 
> Interfaces / Testing / Object Encapsulation.
>
>
> *Specific Question: Object Encapsulation*
> I feel like my function parameter lists are much "wider" than they would 
> be in C#. This is due to the "lack" of a constructor. So if I previously 
> had a C# class that looked like:
>
>
> public class AccountRepository : IAccountRepository
> {
>   IDatabaseConnection _connection;
>
>   public AccountRepository(IDatabaseConnection connection)
>   {
> _connection = connection;
>   }
>
>   public void Save(Account account)
>   {
> _connection.Execute("UPDATE accounts SET coupon=@coupon WHERE id=@id", 
> { coupon = account.Coupon, id=account.Id});
>   }
> }
>
> In the above I have encapsulated the "_connection", the other methods 
> don't have to deal with it. In Clojure (especially if you are following 
> Sierra's Component pattern) you end up with 
>
> (defn save [db account]
>   (update db (:coupon account) (:id account))
> )
>
> I end up having to pass this 'db' around all over the place. I think that 
> this is just something I'll have to get used to more than anything. Am I 
> missing anything?
>
> Thank you for your time.
>
> -d
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: ClojureScript 0.0-2814, Nashorn REPL, async testing, and much more

[David Nolen]

On Wed, Feb 11, 2015 at 6:52 AM, Daniel Skarda  wrote:

> Could you please write few examples how to take advantage of new unified
> source-map support? I tried 0.0-2816 with node.js without success. I tried
> with piggieback and without. But the only solution was with 'npm install
> source-map-support' (I guess this is not the unified support you wrote
> about).
>

For targets like Node.js the new source map stuff doesn't make much of a
difference. `source-map-support` is pretty good.


> Even with source-map-support I got errors to console (see below).
>
> 1) Is new unified source-map support compatible with piggieback/cider or
> is some modification required?
>

No idea about piggieback or cider, but I suspect these tools will need to
be updated to take advantage of what we've landed.


> 2) Is {:source-map true} enough for unified source-mapping support? Does
> it work OOTB or is there any hidden switch


It is not an automatic thing. There is a new a protocol that REPL
environments must implement and the details are somewhat in flux as we
determine what will work best for the wide variety of platforms that will
want to leverage this: iOS, Android, Safari, Chrome, Firefox, accounting
for Windows dev environment differences etc.

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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Anyone know why cheat sheet links sometimes don't keep anchors?

[Andy Fingerhut]

There are multiple links in the Clojure cheat sheet here:


http://jafingerhut.github.io/cheatsheet/clojuredocs/cheatsheet-tiptip-cdocs-summary.html

that go to clojure.org/somewhere#some-anchor

For example, in the "Special Forms" section, and the sub-section "Binding
Forms / Destructuring", there is a link "(examples)" that (tries to) go to
the URL: http://clojure.org/special_forms#binding-forms

Often when I click on it for the first time in a while, it will lose the
anchor and instead go to:

http://clojure.org/special_forms

If I hit back in my browser and click on the same link again, this time it
keeps the whole URL, including the anchor.   I have tested Safari on Mac OS
X 10.9.5, which definitely does this, sometimes.  It does not happen all of
the time, so I am not yet sure whether it happens with other browsers like
Firefox 35.0.1 and recent Chrome, too.

Other links that sometimes exhibit this behavior:

4 links "literals" in the Primitives/Other section, all of which should go
to here: http://clojure.org/reader#The%20Reader--Reader%20forms  but
sometimes I see it go to http://clojure.org/reader instead.

5 links in "Reader Macros" section -- not the ones to quote, var, or deref,
but the ones appearing first in the descriptions.

Anyone else see this behavior?  More importantly, can anyone explain why it
happens, and/or how the behavior can be prevented?  If it is simply a bug
in Safari, then I won't worry too much about it.

Thanks,
Andy

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Why can't I override equals & hashCode in defrecord?

[Michael Sperber]

I'm implementing some low-level data structures using arrays, and
I'd like to use defrecord to make type for them.

I need to override equals & hashCode, but defrecord won't let me do it.
I know this has been discussed before:

https://groups.google.com/forum/#!topic/clojure/Nvz0WDhj0qk

The advice there is to use deftype, but this would mean copying a large
amount of boilerplate which includes references to internal Clojure
interfaces.  So I'd like to avoid that.

Couldn't defrecord check whether I'm overriding any of the interfaces it
can implement and then not to do it?

Cheers,
Mike

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending the LispReader with "embeded language lorms"

[Chris Ford]

As an example of pushing data into an external DSL you could check out John
Cowie's Scenic wrapper for Bidi - https://github.com/johncowie/scenic.

Note that Scenic loads data from the external file at _compile_ time - so
it comes closer to being like embedding a DSL in Clojure source and less
like a configuration file that's read at runtime.

Chris

On 11 February 2015 at 19:59, Henrik Heine 
wrote:

> Hi,
>
> Am Dienstag, 10. Februar 2015 21:07:50 UTC+1 schrieb Gary Verhaegen:
>>
>> For the sake of completeness, in this context "other users" is not
>> limited to humans: what about IDE support? Refactoring tools? Code analysis?
>
>
> I agree. You lock out "others" and that takes away a lot. For me that's
> the main argument against my proposal.
>
> I was not thinking to copy&paste huge CSV data in to Clojure files. I'm
> thinking more about in-line configuration that you can copy&paste to/from
> other sources, test data, maybe literate programming (haven't worked that
> out though). But not only "data stuff" could be in-lined: prolog code, SQL
> statements compiled to the corresponding Clojure libs. OK - the indirection
> through an external file does not cost that much.
>
> You could even use it to try out new Clojure features (like reader
> conditionals) without touching one line of Clojure core - just make it a
> #[CLJxxx ...] form and play around with it before you move it over to the
> Clojure core code. And you could back-port things just by supplying a
> lib/function. In this case the "embedded syntax" would still be Clojure.
>
> I still feel like being "new to Clojure", so thanks for all the replies
> and the insights into "The Clojure Way".
>
> Henrik
>
>  --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why STM read are not cached?

[Stefan Kamphausen]

Hi,


It's been quite a while since I last looked into the impl of STM but I seem 
to remember that the committing transaction actively notifies other running 
transactions (see method barge) to restart and thus the restart is not 
triggered by the second deref at all.  

You could also find out by examining the history after your experiment with 
(.getHistoryCount a)


Hope that helps,
stefan

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: ClojureScript 0.0-2814, Nashorn REPL, async testing, and much more

[Robin Heggelund Hansen]

Does there exist a tutorial for how to setup a project using cljs.test? And 
some details on how the async testing works?

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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: ClojureScript 0.0-2814, Nashorn REPL, async testing, and much more

[Daniel Skarda]

David,
thank you for all improvements and work you do for ClojureScript!

Could you please write few examples how to take advantage of new unified 
source-map support? I tried 0.0-2816 with node.js without success. I tried with 
piggieback and without. But the only solution was with 'npm install 
source-map-support' (I guess this is not the unified support you wrote about). 

Even with source-map-support I got errors to console (see below).

1) Is new unified source-map support compatible with piggieback/cider or is 
some modification required?

2) Is {:source-map true} enough for unified source-mapping support? Does it 
work OOTB or is there any hidden switch?

Thank you,
Dan

TypeError: Cannot call method 'cljs$core$IPrintWithWriter$_pr_writer$arity$3' 
of undefined
at [object Error].pr_str_STAR_ [as toString] 
(/home/0rfelyus/prace/cryptelo/target/cljs-repl-node/cljs/core.cljs:441:17)
at Function.prepareStackTrace 
(/home/0rfelyus/prace/cryptelo/node_modules/source-map-support/source-map-support.js:298:16)
at Socket. ([stdin]:48:31)
at Socket.emit (events.js:95:17)
at Socket. (_stream_readable.js:748:14)
at Socket.emit (events.js:92:17)
at emitReadable_ (_stream_readable.js:410:10)
at emitReadable (_stream_readable.js:406:5)
at readableAddChunk (_stream_readable.js:168:9)
at Socket.Readable.push (_stream_readable.js:130:10)


On Tuesday, February 10, 2015 at 1:47:31 AM UTC+1, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> New release version: 0.0-2814
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "0.0-2814"]
> 
> 
> There are numerous enhancements in this release including: a Nashorn
> REPL, Node.js 0.12 support, cljs.test async testing support,
> `cljs.closure/watch`, extra JSDoc annotation support, unified source
> mapping on client/server (thus REPLs!), and many small fixes.
> 
> 
> I'm particularly excited about unified source mapping as this means we
> get a much better debugging experience on newer targets (for us) like iOS, 
> see https://github.com/omcljs/ambly
> 
> 
> ## 0.0-2814
> 
> 
> ### Enhancements
> * add simple source directory `cljs.closure/watch` watcher using java.nio
> * CLJS-1022: Concatenate foreign dependencies safely
> * CLJS-988: Support async testing in cljs.test
> * CLJS-1018: Add support for cljs.core/*e Modify the JavaScript that is sent 
> for evaluation to wrap in a try and then catch any exception thrown, assign 
> it to *e, and then rethrow.
> * CLJS-1012: Correct behavior when *print-length* is set to 0
> * Added new :closure-extra-annotations compiler option allowing to define 
> extra JSDoc annotation used by closure libraries.
> * Mirrored source map support APIs on server/client
> * Unified source mapping support in REPLs
> * Nashorn REPL (thanks Pieter van Prooijen)
> 
> 
> ### Fixes
> * CLJS-1023: regression, macro-autoload-ns? and ns-dependents need to throw 
> on cyclic dependencies
> * fix require with browser REPL, set base path to "goog/"
> * CLJS-1020: off by one error in REPL source map support
> * Node.js 0.12 support
> * browser REPL needs to respect :output-dir
> * CLJS-1006: Implicit dependency of clojure.browser.repl on cljs.repl
> * CLJS-1005: Browser REPL creates 'out' directory no matter what
> * CLJS-1003: fix cljs.test run-tests do-report :summary issues
> * CLJS-1003: Cannot pass custom env to run-tests
> * Windows Node.js REPL issues

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] closp - leiningen template combining luminus and chestnut + some more features

[Sven Richter]

Hi,

I took some time to put together a leiningen template which combines the 
awesome proecjts luminus and chestnut and adds some more features to start 
development sideprojects for the web without much hassle.
The rationale behind this is that I found myself adding these features 
again and again for every new project and I wanted to stop that.

Features:

* H2 database on filesystem as a default
* Ragtime for database migrations
* Selmer as templating solution
* http-kit as a server
* cljx support
* Figwheel with clojurescript live reloading
* Reloading support for templates and clojure code
* Configuration with nomad
* User management with login/logout/registration with email activation 
(provided by postal)
* Authentication provided by buddy
* reagent and datascript on frontend side
* Ring Antiforgery middleware
* Clojure miniprofiler example
* Componentized application
* Datascript with reagent example
* Booststrap css styles

As always I am happy about any kind of feedback, pull requests or whatever 
comes to your mind.



Best Regagrds,
Sven

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Testing ClojureScript code with clojurescript.test and Karma

[Mike Thompson]

On Wednesday, February 11, 2015 at 6:00:15 AM UTC+11, Kevin Bell wrote:
>
> We at CircleCI have been running our clojurescript.test tests with Karma 
> lately, with great results. Easy access to Chrome devtools for unit tests 
> is great, and it provides great community plugins like junit-formatted xml 
> output (which CircleCI understands).
>
> You can read about how it works in our blog post on the topic 
> .
>  
> The main caveat is that at the moment our karma-cljs.test adapter is 
> hardcoded to call "circle.karma.run_tests_for_karma" as an entry point to 
> the ClojureScript side of things. We also use a bit of a hack to load all 
> of the test namespaces when {:optimizations :none} is used.
>
>
Just heads up ... 

You'll need to change your  ":none" hack as soon as you switch to 
clojurescript  v0.0.2719 :
https://github.com/mike-thompson-day8/cljsbuild-none-test-seed/blob/master/test.html#L112-L124


Cheers,
Mike

 

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending the LispReader with "embeded language lorms"

[Henrik Heine]

Hi,

Am Dienstag, 10. Februar 2015 21:07:50 UTC+1 schrieb Gary Verhaegen:
>
> For the sake of completeness, in this context "other users" is not limited 
> to humans: what about IDE support? Refactoring tools? Code analysis?


I agree. You lock out "others" and that takes away a lot. For me that's the 
main argument against my proposal.

I was not thinking to copy&paste huge CSV data in to Clojure files. I'm 
thinking more about in-line configuration that you can copy&paste to/from 
other sources, test data, maybe literate programming (haven't worked that 
out though). But not only "data stuff" could be in-lined: prolog code, SQL 
statements compiled to the corresponding Clojure libs. OK - the indirection 
through an external file does not cost that much.

You could even use it to try out new Clojure features (like reader 
conditionals) without touching one line of Clojure core - just make it a 
#[CLJxxx ...] form and play around with it before you move it over to the 
Clojure core code. And you could back-port things just by supplying a 
lib/function. In this case the "embedded syntax" would still be Clojure.

I still feel like being "new to Clojure", so thanks for all the replies and 
the insights into "The Clojure Way".

Henrik

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.