Exploring the (tap>) functions

[Glen Mailer]

Hello All

I was wondering if there is an annoucement or a rationale doc coming for 
(tap>) and it's related functions? The current docstrings do a good job of 
telling you what they do and how to use them, but the docs on the homepage 
 seem quite open-ended. 
Was there a particular motivating case which led to their inclusion in core?

I've been playing around with them a bit, a colleague of mine was using 
them for local debugging, but then we were unsure whether it made sense to 
leave them committed when the code shipped to production. I've also been 
experimenting with extending our logging protocol to send all of the 
application logs to tap, where they can be siphoned off elsewhere.

One thing I did find a bit unusual was that although these are somewhat 
similar to `add-watch` and `remove-watch`, there is no `reference` 
argument, so if a function is re-evaled then it can be easy to lose the 
original and be unable to `remove-tap` without reaching into the private 
set. Is there a reason for this omission? I'm fairly confident that a 
backwards-compatible extension to take an optional reference could be added 
if not, defaulting to the fn itself. Failing that, a `clear-taps` fn might 
be desirable.

Thanks
Glen


-- 
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] Clojure 1.9.0-alpha1

[Glen Mailer]

Is the plan that any lib which adds specs will force the rest of the running 
system up to 1.9, or is it possible to keep the specs in a different namespace 
and not blow up?

Would it be reasonable to release something for 1.8 which contains all the spec 
vars but no-ops them?

-- 
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] Elements of Clojure

[Glen Mailer]

>
>
> Maybe this is what's conveyed in some programming contexts, and perhaps 
> that's reason enough not to use "style" in your title, but "style" doesn't 
> convey that in general.
>  
>

It would appear that "style", being a natural name, has an ambiguous sense.

I suppose then that we must rely on the definition in the introduction, or 
invent a synthetic term which would confuse novices.

-- 
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: Reducing the pain of a clojars outage

[Glen Mailer]

This seems like it could be a fruitful avenue to me (cloudflare or another CDN)

I know the folks at npm use fastly in a similar fashion - gaining both 
geographical distribution and improved resiliency.

-- 
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: Naming convention for atoms, refs, etc.?

[Glen Mailer]

I saw some sample code that prefixed the atom name with a ! recently, seemed to 
look sensible to me.

(swap! !state conj :whatever)

And so on.

-- 
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] Shrubbery 0.2.0, a stubbing, spying, and mocking library for Clojure protocols

[Glen Mailer]

This looks neat Brian!

People who find this useful may also like a similar lib I wrote that provides 
mocking tools at a single function level: https://github.com/glenjamin/q

-- 
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: Om design query

[Glen Mailer]

In ordinary React I think I would keep all of this logic in the parent, and 
read from the DOM in didUpdate. There's a feature called refs which can be used 
to grab references to the rendered children to get their DOM nodes.

I'm afraid I don't know how to do the equivalent in Om.

-- 
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: ClojureScript 0.0-2496, cljs.test - a clojure.test port

[Glen Mailer]

 Also there's a doc macro now in the cljs.repl namespace that works as 
 expected. 

This is great to hear!

Excited to see test.check being on the horizon as well.

-- 
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] seqspert-1.7.0-alpha4-1.0-SNAPSHOT now on Clojars - Merge big hash-maps, FAST !

[Glen Mailer]

I did?

I have no recollection of this at all!

Is this a similar concept to the Patricia trees as found in 
https://github.com/clojure/data.int-map ?

Glen

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

Eager (cat) in transducers

[Glen Mailer]

While watching Rich's strangeloop talk, I noticed a slight oddity in the 
definition of mapcat.

I brought this up briefly in the IRC channel yesterday and the general 
consensus seemed to be that this is awkward, but not easily solvable:

The original lazy definition of (mapcat) uses (concat), and concat 
explicitly uses a lazy sequence:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L679

The reducers defintion of (mapcat), like all reducers, explicitly uses 
(reduce)
https://github.com/clojure/clojure/blob/f3259f4f34a68eae7db7efc0be9d19fa5dafbd3c/src/clj/clojure/core/reducers.clj#L171


As I understand it, part of the goals of transducers is to unify the 
similar patterns seen in reducers, lazy-sequences and elsewhere.


However, transducers' (mapcat) is currently implemented via a new core 
function called (cat)
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2648
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L7221

(cat) unfortunately contains an explicit call to (reduce), which makes the 
(map) part eager, here's an example of something that works with the 
previous mapcat, but not with the tranducers flavour:

(take 3 (mapcat repeat [1]))
; = (1 1 1)
(take 3 (sequence (mapcat repeat) [1]))
; = #OutOfMemoryError java.lang.OutOfMemoryError: Java heap space

Despite asking for a lazy transducer implementation, we get an eager step.

Is there some clever way to avoid this? I believe this applies generally to 
any transducer which calls the step function multiple times. Conceptually I 
think that transducer processor would have to wrap the step function in 
some way to make it act like a continuation to enforce laziness with the 
executing transducer?


Hopefully that all makes sense!

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

Top-down code in namspaces

[Glen Mailer]

Hi everyone, I'm looking to get some opinions on code style.

Specifically, I like to write my code in a top-down.

What I mean by that is that within a file the highest-level functions sit 
at the top, and are implemented in terms of lower-level functions further 
down.

The idea is that through sensible naming, a reader should be able to stop 
reading at any point and still know what's going on.

I was recently watching the prismatic schema presentation from the 2013 
conj, and noticed they too promoted having a public section at the top of 
the namespace.


The problem now is because of the single-pass nature of clojure's 
evaluation - simply writing code like this doesn't actually work.

There's a few approaches i've seen from reading other's code:

1. Have an impl namespace which contains all of the helper functions for 
the public interface
2. Make use of (declare) forms where necessary to improve forward 
readability
3. Don't worry about source order, just have the api functions further down 
the file and live with it

Some other options I considered include making really heavy use of 
(declare), or even defining some sort of (eval-reversed) macro which runs 
the code backwards.


I'd like to know if people are experiencing this issue, and how you all are 
resolving it?


Cheers
Glen

-- 
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: Kwargs vs explicit parameter map for APIs?

[Glen Mailer]

While reading the clojure.java.jdbc code yesterday, I discovered to my 
surprise that map destructuring can be used after an  in an arglist.

This should give you all the described benefits of the two approaches you 
mention

((fn [a  {:as d}] d) 1 :opt1 'blah :opt2 false)

You can also do defaults using :or - although these defaults don't get 
merged into the value of :as - so an explicit (merge) might be better.

((fn [a  {:keys [misc] :or {misc :misc-default} :as d}] [d misc]) 1 :opt1 
'blah :opt2 false)

Hope that makes sense!

Glen

On Friday, 25 April 2014 23:41:22 UTC+1, Colin Fleming wrote:

 Hi all,

 I'm working on an API at the moment, and I'm balancing whether to use 
 inline keyword args which I would destructure in the functions, or whether 
 to just pass an explicit params map as the last parameter. Comparison of 
 the two options in case I'm not explaining myself well:

 Kwargs:
 (class/create-class :instancelist
 :description My description
 :implements  (keys class-methods)
 :methods (calculate-my-methods))

 Map:
 (class/create-class {:instancelist
  :description My description
  :implements  (keys class-methods)
  :methods (calculate-my-methods)})

 A lot of APIs I've seen have favoured kwargs, and it undeniably makes for 
 some pretty code - Seesaw is the best example I've seen here, the API is a 
 thing of beauty. However it seems to me to have some issues:

1. If I want to delegate to another call from within an API function 
and use the same arguments, it's really awkward: (apply delegate 
(mapcat identity args)) or some similarly awful black juxt magic. Or 
of course writing out all the parameters again, but that's even worse.
2. It's more difficult to make parameters optional based on some 
runtime criteria since the params are baked into the function call. I 
 guess 
this is usually dealt with by making the calls handle nil for a particular 
parameter. 

 Both of these are much easier when passing an explicit map. Any 
 preferences here, from either writing or using APIs like this?

 Cheers, 

 Colin


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

Need HTTP Client not to verify cert on Heroku

[Glen Mailer]

The option you need is :insecure? true - although it's worth considering if 
you'd be better off setting up the certificate chain with the appropriate CA 
for the service in question (see trust store section in readme)

-- 
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: fast parallel reduction into hash-set/map

[Glen Mailer]

Is there a specific part of this implementation which means it needs to 
live in core?

It would be cool to have this as a library that could be used with existing 
versions of clojure (I have no idea if enough of the internals are exposed 
to make this viable)

Glen

On Saturday, 15 February 2014 23:06:24 UTC, Jules wrote:

 Guys,

 I've been playing with reducers on and off for a while but have been 
 frustrated because they don't seem to fit a particular usecase that I have 
 in mind... specifically: getting as many associations into a hash-map as as 
 I can in as short a time as possible.

 My understanding of the reason for this is that reducers practice a divide 
 and conquer strategy. The incoming sequence is divided up. Each 
 sub-sequence is reduced into a sub-result (possibly in parallel) and then 
 the sub-results are combined into the the final outgoing result.

 Unfortunately, there does not seem to be a better way of combining two 
 hash-maps other than to read each entry from one and create a new 
 corresponding association in the other. This means that each recombination 
 in the above process essentially repeats most of the work already performed 
 in the previous reduction stage.

 Hash-sets are implemented via hash-maps, and simpler with which to 
 demonstrate this problem:

 user= (def a (doall (range 1000)))
 #'user/a
 user= (def b (doall (range 500 1500)))
 #'user/b
 user= (time (def c (into #{} a)))
 Elapsed time: 6319.392669 msecs
 #'user/c
 user= (time (def d (into #{} b)))
 Elapsed time: 5389.805233 msecs
 #'user/d
 user= (time (def e (into c d)))
 Elapsed time: 8486.032191 msecs
 #'user/e


 In the example above, you can see that the reduction into hash-sets of two 
 overlapping lists of 10,000,000 elements takes 6.3 and 5.4 seconds. This 
 stage can be carried out in parallel i.e. time elapsed for this stage would 
 be 6.3 seconds - but we now have two hash-sets and we want one, so we have 
 to combine them.


 user= (time (def e (into c d)))
 Elapsed time: 8486.032191 msecs
 #'user/e

 As you can see, all the advantages of splitting the original sequence into 
 2 and processing the two halves in parallel are lost since the 
 recombination or their results takes 8.5 seconds - more than we saved by 
 doing the reduction in parallel.

 So, what can we do about it ?

 I had a look at the code for PersistentHashMap (PersistentHashSet uses 
 PersistantHashMap internally). I realised that it was possible to splice 
 together the internal structure of two hash maps into a single one without 
 repeating most of the work required to build one from scratch. So, I had a 
 go at implementing it:


 user= (time (def f (clojure.lang.PersistentHashSet/splice c d)))
 Elapsed time: 3052.690911 msecs
 #'user/f

 and:

 user= (= e f)
 true

 Whilst this is still adding 3 seconds to our time, that 3 seconds is half 
 the time that we would have added had we executed the second reduction in 
 serial, rather than in parallel.

 This means that we can now reduce large datasets into sets/maps more 
 quickly in parallel than we can in serial :-) As an added benefit, because 
 splice reuses as much of the internal structure of both inputs as possible, 
 it's impact in terms of heap consumption and churn is less - although I 
 think that a full implementation might add some Java-side code complexity.

 If you would like to give 'splice' a try out, you will need to clone my 
 fork of clojure at github 

 https://github.com/JulesGosnell/clojure

 Please let me know if you try out the code. I would be interested to hear 
 if people think it is worth pursuing.

 I was also thinking that it should be possible to use a similar trick to 
 quickly and cheaply split a map/set into [roughly] equal sized pieces 
 (assuming an good hash distribution). This would enable the use of a 
 map/set as an input sequence into the parallel reduction process outlined 
 above. Currently, I believe that only a vector can be used in this way. It 
 would be harder to arrange that 'count' could be implemented efficiently on 
 these sub-maps/sets, but this is not important for the reduction process.

 BTW - benchmarks were run on a 3.2ghz Phenom II / clojure/master / 
 openjdk-1.7.0_51 / Fedora 20 with min and max 4gb ram.

 regards,



 Jules




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

Re: Lein, Speclj clojure 1.6.0-beta1

[Glen Mailer]

:eval-in can be overridden in your project.clj, just add:

:speclj-eval-in :subprocess


I agree that the default is rather odd - especially when the only reason 
I'm aware of is it's a bit faster

Cheers
Glen


On Monday, 17 February 2014 12:09:13 UTC, Karsten Schmidt wrote:

 Hi all, am trying to test out the new hashing approach for my datatypes in 
 1.6 but it seems that even though I'm referring to the latest beta in my 
 project.clj, Speclj is overriding that dependency with 1.5.1 and I can't 
 run my tests. How can I force it to honor my setting and use 1.6.0-beta1? I 
 guess that's a more general question about leiningen's dep resolution for 
 plugins...

 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/groups/opt_out.

Code re-use in Speclj

[Glen Mailer]

My usual approach is to use a macro that expands to the appropriate (it) forms, 
or have a helper function that is called inside each (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
--- 
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/groups/opt_out.

Re: Contributors needed for Rouge (Clojure on Ruby)

[Glen Mailer]

Have you looked into running clojurescript on Node.js? 

This should be a reasonable environment for command line scripting

-- 
-- 
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/groups/opt_out.

Re: Parallel http requests

[Glen Mailer]

I can't speak for whether this is a truly idiomatic way of doing this, but 
this is a macro i've been using for this case.

(defmacro plet [bindings  body]  Just like let, but evaluates bindings in 
parallel  (let [bindings (partition-all 2 bindings)destructs (map 
first bindings)expressions (map second bindings)vars 
(repeatedly (count bindings) gensym)]`(let [~@(mapcat (fn [var expr] `[~var 
(future ~expr)]) vars expressions)   ~@(mapcat (fn [destr var] `[~destr 
(deref ~var)]) destructs vars)]   ~@body)))


This gives me a similar construct to let, but with each binding evaluated 
in parallel using a future. For small sets i think this is less overhead 
than pmap - note that unlike the traditional let, this will not handle 
multiple bindings for the same variable properly.

Usage would then be

(plet [a (http/get url1)
   b (http/get url2)]
  (vec a b))

Or similar

Cheers
Glen
On Tuesday, 31 December 2013 08:46:53 UTC, chinmoy debnath wrote:

 I am a newbie in clojure. I need to send multiple http requests in 
 parallel and need to have a call back when response for each request come 
 back. What will be the idiomatic way of doing it in clojure?
 Thanks in advacne



-- 
-- 
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/groups/opt_out.

loop/recur with multiple branches

[Glen Mailer]

I was recently working on some toy recursion problems, when I ran into a 
function that I can express simply using normaly recursion, but I can't 
seem to convert it into a form that works nicely with loop/recur.

It's certainly not the right way to solve this problem, but I'm intrigued 
to see what this pattern looks like with explicit tail calls:

Problem:
Extract a slice from a list
(slice [ 3 4 5 6 7 8 9 ] 2 4)
;= [ 5 6 7 8 ]

Normal Recursive Solution:
(defn slice [[h  tail] s n]
  (cond
(zero? n) nil
(zero? s) (cons h (slice tail s (dec n)))
:else (slice tail (dec s) n)))

What would the tail recursive version of this look like? can it retain the 
nice readability of this form?


-- 
-- 
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/groups/opt_out.

Re: blog article on RSpec like TDD with a rapid feedback cycle in Clojure

[Glen Mailer]

If you're on a Mac and using Speclj you may want to try out 
https://github.com/pgr0ss/speclj-growl - you won't even need to look at your 
terminal!

Glen

-- 
-- 
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/groups/opt_out.

Re: Clojure generates unnecessary and slow type-checks

[Glen Mailer]

This doesn't really answer your question directly, but is there a reason you 
need to keep this in clojure, or are you just aiming to establish why this is 
happening?

My understanding was that for performance critical code the general advice is 
to drop down to raw java?

Glen

-- 
-- 
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/groups/opt_out.

Re: Screencast: Clojure development with Sublime Text 2

[Glen Mailer]

I've been using sublime-paredit for a while, and the dodgy closing bracket 
behaviour has been bugging me - so it was nice to spot a fix in your key 
bindings file.

Would you be able to submit this back upstream to the author?

Cheers
Glen

On Saturday, 18 May 2013 21:36:21 UTC+1, James MacAulay wrote:

 This is a little show-and-tell I recorded today:

 http://www.youtube.com/watch?v=wBl0rYXQdGg

 Hopefully it's useful for some of you. Feedback welcome!

 Cheers,
 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/groups/opt_out.

Re: Utility libraries and dependency hygiene

[Glen Mailer]

At the risk of making a slight strawman here, I agree this issue has the 
potential to drag on Clojure adoption - but in the opposite way to what you 
describe.

At the root of it, is the Clojure ecosystem a dependencies are bad 
system, or a dependencies are good system?

The former encourages roll-your-own, but reduces code sharing and re-use
The latter promotes sharing and building upon the work of others, but 
requires more advanced dependency management tooling

As great as the language is, having the general advice be don't have 
dependencies in your libraries seems like a step backwards to me.

I would always rather spend an hour finding a documented, tested existing 
library, than spend 20 minutes creating my own duplicate of that work.

I hope this doesn't come over as too accusatory, if the cost of 
dependencies truly is higher than the cost of duplicating work/code then 
perhaps we need to try and make the former easier.

Glen

On Tuesday, 14 May 2013 13:19:15 UTC+1, Dave Kincaid wrote:

 This thread seems to have gotten way off track and I think that Stuart 
 made a very important point in the original post that's getting lost. It 
 would help all of us out if library authors stopped making their libraries 
 dependent on 10+ other libraries. This issue does have the potential to 
 really drag on Clojure adoption. Just try to maintain your own local 
 repository for your projects and you'll see what I mean the first time you 
 need to add a Clojure dependency.

 On Tuesday, May 14, 2013 4:22:59 AM UTC-5, Phillip Lord wrote:

 Stuart Sierra ma...@stuartsierra.com writes: 
  On Tue, May 14, 2013 at 3:25 AM, Phil Hagelberg ph...@hagelb.org 
 wrote: 
  
  It's really not difficult to do if you limit yourself to Clojure since 
  Clojure namespaces are first-class and easy to manipulate at 
  run-time. We implemneted a prototype of this in under two hours at a 
  Seajure meeting a while back: 
  
  https://github.com/technomancy/metaverse 
  
  However, it's significantly more difficult to do for arbitrary Java 
  bytecode. 
  
  
  
  That's cool, and it will work for the simple case of libraries A and B 
  depending on different versions of C. 
  
  But it still breaks down in more complex cases: e.g. if I want to share 
  data between A and B using a protocol or type defined in C, and there 
 are 2 
  incompatible versions of C. Even ClassLoaders can't help you there - 
 I'm 
  not aware of any solution. 


 Automatically, no, but the solution would be to use something akin to an 
 adaptor. The two versions of C would be manipulated to be in different 
 namespaces; now you just have two libraries, so the task of plumbing 
 them together remains the same. 

 To be honest, though, this is unlikely; after all, if you are using A 
 and B, and they are using C *as a utility*, my feeling is that C 
 shouldn't really be in their public interface. If C *is* in their public 
 interface, then again, you need adaptors. 

 Or you can fork A and/or B, fix them to use the same version! 

 Phil 



-- 
-- 
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/groups/opt_out.

Re: Utility libraries and dependency hygiene

[Glen Mailer]

Are dependencies the potential problem, or are utility belt dependencies 
the issue here?

If its the latter, then should we be trying to break down the utility belt 
into groups of related functionality, which can be stable and focused.

Promoting zero-dependency libraries just means re-inventing a bunch of 
wheels, I believe node.js has this right by making dependencies cheap and 
easy and promoting publishing reusable libraries with only a few functions 
in. Not being able to load multiple versions of the same dependency make 
this slightly harder, but the general goal appears to me to be a good one.

Glen

-- 
-- 
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/groups/opt_out.

Parallel let form

[Glen Mailer]

Hi All,

I was recently looking at how to make better use of parallelisation for 
simple tasks in my compojure app, I had a construction similar to the 
following:

(views/some-view (api/api-call-1) (api/api-call-2) (api/api-call-3))

It seemed that the easiest way to introduce some parallelism here would be 
in the style of a let form:

(let [result-1 (api/api-call-1)
  result-2 (api/api-call-2)
  result-3 (api/api-call-3)]
  (views/some-view result-1 result-2 result-3)

There doesn't appear to be anything in core that does, this - after a brief 
discussion in the IRC channel, I received the following two suggestions: 
https://gist.github.com/jcromartie/5459350 and 
https://gist.github.com/guv/5459364

I ended up going with the approach from guv, as I understood it better - 
and I moved the let form inside the view function to cut down on the 
repetition a bit.

Now, to my actual questions:

What are the differences between the pmap approach and the futures approach?

And would a construction like this be useful in core? If so, how does it 
potentially get there?


Thanks
Glen Mailer
Budding Clojurer


-- 
-- 
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/groups/opt_out.