How cider-nrepl gets loaded, all depends. The manual has something to say
about it, at https://docs.cider.mx/cider/basics/up_and_running.html
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to
I can tell by the beet-colored theme that beta.clojars.org is a wholesome
replica.
--
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
Witty and instructive:
http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent
--
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
Alan, consider JSoup too, if you can... Enlive offers both options, and, if
memory serves, JSoup seemed the more capable with HTML5.
--
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
Feel free to post this kind of question to https://ask.clojure.org/, where
things are better organized.
At the risk of not answering your specific question, I'd suggest you put
aside "Web development with Clojure" for matters of ClojureScript. (And
regard with suspicion any template system
Dmitri Sotnikov's book "Web development with Clojure" includes an example.
Do not be put out by books or primers dated a few years back. HTTP,
Servlets, and Clojure have been quite stable. Likewise the basic facts of
authentication and authorization, right?
On Saturday, March 21, 2020
Sierra's Component README illustrates factory functions that take a
complete static configuration at once, followed up by injections. But,
really, it's none of Component's concern how you work a Lifecycle thing
into shape for Component to assoc the injections and start it.
In Schematic,
Too fragile. This reminds me of the notion of "situated programming",
featured in the talk by Rich Hickey: you and your programs operate in the
middle of a bizarre and changing situation. For Clojure, the Java
ecosystem is part of that situation. Even if some jars do not overlap
today, you
I especially like the "bigger aspirations" -
https://github.com/cljctools/readme#bigger-aspirations
And your summary of relevant strengths of Clojure.
On Sunday, August 30, 2020 at 2:42:25 AM UTC-4, Sergei Udris wrote:
>
> Thought process behind and goals of the https://github.com/cljctools
>
I can't comment on the whole crazy world of JSON, but it's a shame to think
of all the coal-fired watts spent unnecessarily parsing UUIDs. If all you
need is a string, there is no dishonor in letting it be a string.
> I was made to wonder how the rest of the world lives!
>
> P.S. Also,
Rich Hickey has pushed using solid domain names before, and I'm super glad
to see more progress on that front. But it's unfortunate if the tools
castigate the victim, not the perpetrator. Wouldn't Clojars be a better
point for enforcement? Has the question been raised with Clojars?
Alex's
await takes many steps and is not synchronized, so it would be messy to
guarantee how it relates to other threads.
--
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
I think this will *compound interest* in the language!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first
This is not either/or.
There is room for an alternative, spec-enforcing, EDN reader.
A drop-in replacement, as it were, for those inclined to try it.
If you want speed, you use Transit anyway, right?
P.S. Even better if the alternative, compliant, reader were compatibly
licensed, to replace
201 - 214 of 214 matches
Mail list logo