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 2))
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
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:
http://www.that
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 this
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
that you can make use
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 t
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 it:
>
> https://githu
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 ema
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 h
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
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.
>
> *
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
12 matches
Mail list logo