Macro for quickly switching libraries

I'm working on some code where I want to evaluate different implementations of the same functionality. Each implementation of a function lives in its own namespace. For example, suppose that I have the following simplified code. (ns tst1) (defn foo [x] (+ x 1)) (ns tst2) (defn foo [x] (+ x

Re: Advice getting started with concurrency and parallelism in Clojure

If it all seems confusing, do not despair, there's two things that will handle the vast majority of the use cases you may have: 1) `future` - spawns a thread that runs the body of the future ( https://clojuredocs.org/clojure.core/future) 2) `atom` and `swap!` - Used to store data that needs to be

Advice getting started with concurrency and parallelism in Clojure

I was doing some reading of code recently to help me get up to speed with Clojure. One of the libraries I randomly came across dealt with parallelism and I had a hard time following along with it. To try and wrap my head around things I did a quick search and found this article:

Re: [ANN] components.md

The thing that this doc also advocates (and I am against) is manual dependency management, your app start function must call start on its dependencies. This not only hardcodes the dependency, but also requires the user to think about the startup order of components on every usage. In addition

Re: [ANN] components.md

On 5 April 2016 at 17:23, wrote: > Not sure it's worth to depend on a library for a defprotocol with two > functions. Also, still need to double check, but I think I can get rid of > that defprotocol. > Well, the advantage with using the Lifecycle protocol from Component is

Re: [ANN] components.md

Not sure it's worth to depend on a library for a defprotocol with two functions. Also, still need to double check, but I think I can get rid of that defprotocol. Renzo On Tuesday, 5 April 2016 16:12:42 UTC+1, James Reeves wrote: > > Why implement your own Lifecycle protocol, rather than using

Re: [ANN] components.md

Why implement your own Lifecycle protocol, rather than using the one from the Component library? - James On 5 April 2016 at 09:28, Renzo Borgatti wrote: > Hello clj, > > kinda late into that discussion of a while ago about “how I use > components”, I finally wrote-up about

Re: [ANN] dali SVG library 0.7.0

Wow very nice work. It's very close to what I did on github.com/pallix/lacij and https://github.com/pallix/tikkba and I'm wondering if some part could be put in common. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send

Re: Clojure library

Yes, thats I wanted. Thanks a lot Regards Em domingo, 3 de abril de 2016 07:10:01 UTC-3, Ashish Negi escreveu: > > By default build tool : lein would not do AOT i.e. create .class files. > So, your jar with `lein uberjar` would have .clj files. You can verify with > un-tar the jar. > > If you

Re: [ANN] kithara 0.1.0 - Reliable RabbitMQ Consumers for Clojure

This is great - we're planning to open source our tiny consumer lib - there might be no need after all :-) Looking at the source and the readme it's **very** similar to our solution. Łukasz -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post

Re: [ANN] Aleph 0.4.1

Zach - thank you for all the work you do on Aleph, I use it every day! On Saturday, April 2, 2016 at 11:44:53 PM UTC-7, Zach Tellman wrote: > > This release represents a number of incremental improvements to 0.4.0, > which has been handling billions of daily requests for close to a year. > > *

[ANN] components.md

Hello clj, kinda late into that discussion of a while ago about “how I use components”, I finally wrote-up about it: https://github.com/reborg/scccw/blob/master/COMPONENTS.md The result is a markdown document that is meant to be used by copy-pasting. So no libraries, no frameworks. The reason