Re: Sum types in Clojure? Better to represent as tagged records or as variant vectors?
Just a casual bystander here, and this is fascinating to read. The
question screaming out to be answered is what problem are you trying
to solve with your choice of encoding? It seems both James and Timothy
have different requirements, both of which are valid but incompatible
with each other.
Nothing is simple and everything is a decision, and the more explicit
we can make those decisions the better we all becomes as software
engineers..
Anyway, I had better get back to work where I model everything as a
map, just because... ;).
On 23 August 2017 at 06:00, James Reeves wrote:
> On 23 August 2017 at 05:15, Timothy Baldridge wrote:
>>
>> Simple: because failing to put it in a map constrains future growth.
>
>
> Sometimes that's what you want. A constrained function is a simple function.
>
> Should (find {:a 1} :a) produce {:key :a, :val 1} instead of [:a 1]? No,
> because it doesn't need to be extensible.
>
> And for that matter, where do we stop? Should:
>
> {:person/score 89}
>
> Be:
>
> {:person/score {:val 89}}
>
> Just in case we want to extend it in future?
>
> {:person/score {:val 89, :max 100}}
>
> Any argument about extensibility around [[k v]] also applies to {k v}.
>
>> But I guess I'd flip it around. Why would I ever want:
>>
>> [:response val]
>>
>> when I could have
>>
>> {:status :response
>> :result val}
>
>
> Well, going purely by syntax, it's more concise, (IMO) more readable, easier
> to match and destruct, and intrinsically compatible with "into" like
> functions:
>
> (def latest-values (async/into {} ch))
>
> I don't see how you can say {k v} is somehow fine, but a stream of [k v]
> pairs over time is somehow bad.
>
> --
> James Reeves
> booleanknot.com
>
> --
> 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.
CPU & platform for best compilation performance
Hi all,
My codebase (mix of CLJ, CLJS and CLJS) is about fifty thousand lines of
code, and compilation times are starting to interfere with my workflow
happiness. In addition, Chrome Devtools is becoming somewhat sluggish due
to the high number of separate namespaces loaded through Figwheel.
My current machine is a 6-core Mac Pro 3.5 Ghz Xeon ("late 2013"). For
quite a while I have been investigating whether a switch to another machine
and/or platform would be interesting from a workflow speed point of view.
However, aside from Timothy Pratley's article on the AMD Ryzen 1800x
(http://timothypratley.blogspot.in/2017/03/ryzen-is-for-programmers.html),
I have trouble finding information that is relevant for us Clojure
programmers.
I would summarize my research as follows:
* single-core performance is most important, so that it is probably the
case that a 4-core CPU with a higher single-thread speed is preferable to
an 6/8/10-core CPU with a slower single-thread speed;
* as from 4 cores, there are hardly any speedups to be expected for having
more cores in CLJ or even (parallel) CLJS builds;
* the Ryzens are great value, but their single-core performance is usually
10-20% below the top of the line Intels;
* according to the many Phoronix benchmarks, Linux and OSX have about the
same performance, although there are some interesting deviations for some
workflows (even up to 30 - 40%);
* the single-core performance difference between my current CPU and the
single-core top of the line (i7700K, i7-7800X or i7-7820X) seems to be
between 20-40%
While a 50% performance increase would be enough to warrant the time
investment & cost of switching, my fear is that the real-world speed-up
will probably be more like a meager 20%.
Ignoring cost considerations and performance outside CLJ development: what
CPU and platform would you recommend?
Many thanks!
Maarten
--
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] Clojure 1.9.0-alpha18
Clojure 1.9.0-alpha18 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha18 - Leiningen: [org.clojure/clojure "1.9.0-alpha18"] 1.9.0-alpha18 includes the following changes since 1.9.0-alpha17: - Can now bind *reader-resolver* to an impl of LispReader$Resolver to control the reader's use of namespace interactions when resolving autoresolved keywords and maps. - Tighten autoresolved keywords and autoresolved namespace map syntax to support *only* aliases, as originally intended - Updated to use core.specs.alpha 0.1.24 -- 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: CPU & platform for best compilation performance
"My codebase (mix of CLJ, CLJS and CLJS) is about fifty thousand lines of
code, and compilation times are starting to interfere with my workflow
happiness. In addition, Chrome Devtools is becoming somewhat sluggish due
to the high number of separate namespaces loaded through Figwheel."
That's not an insane codebase size, but I wonder what your actual
compilation times are? Honesty, I'd be surprised if you even got a 20%
speedup in a compiler by simply upgrading the CPU. CPU tech improvements
are more often focused around numerical computing and vector optimizations.
When there are massive leaps forward in raw execution performance, they're
often less than 20%.
So perf numbers are important here. Also if figwheel is loading large
namespaces into the browser, and running a lot of hooks to patch up the
running system, that can also affect performance.
I'd recommend taking a look the CLJS code in a profiler and seeing where
the slowdown is. Perhaps the namespaces are too large and figwheel is
sending across megabytes of JS, or perhaps there's a bad algorithm
somewhere.
On Wed, Aug 23, 2017 at 9:54 AM, Maarten Truyens <
maarten.truy...@siteffects.be> wrote:
> Hi all,
>
> My codebase (mix of CLJ, CLJS and CLJS) is about fifty thousand lines of
> code, and compilation times are starting to interfere with my workflow
> happiness. In addition, Chrome Devtools is becoming somewhat sluggish due
> to the high number of separate namespaces loaded through Figwheel.
>
> My current machine is a 6-core Mac Pro 3.5 Ghz Xeon ("late 2013"). For
> quite a while I have been investigating whether a switch to another machine
> and/or platform would be interesting from a workflow speed point of view.
> However, aside from Timothy Pratley's article on the AMD Ryzen 1800x (
> http://timothypratley.blogspot.in/2017/03/ryzen-is-for-programmers.html),
> I have trouble finding information that is relevant for us Clojure
> programmers.
>
> I would summarize my research as follows:
> * single-core performance is most important, so that it is probably the
> case that a 4-core CPU with a higher single-thread speed is preferable to
> an 6/8/10-core CPU with a slower single-thread speed;
> * as from 4 cores, there are hardly any speedups to be expected for having
> more cores in CLJ or even (parallel) CLJS builds;
> * the Ryzens are great value, but their single-core performance is usually
> 10-20% below the top of the line Intels;
> * according to the many Phoronix benchmarks, Linux and OSX have about the
> same performance, although there are some interesting deviations for some
> workflows (even up to 30 - 40%);
> * the single-core performance difference between my current CPU and the
> single-core top of the line (i7700K, i7-7800X or i7-7820X) seems to be
> between 20-40%
>
> While a 50% performance increase would be enough to warrant the time
> investment & cost of switching, my fear is that the real-world speed-up
> will probably be more like a meager 20%.
>
> Ignoring cost considerations and performance outside CLJ development: what
> CPU and platform would you recommend?
>
> Many thanks!
>
> Maarten
>
> --
> 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.
>
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
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: CPU & platform for best compilation performance
Thanks, appreciated! Compiling the CLJ side takes about 30 seconds, a non-optimized CLJS about 60 seconds, and an optimized CLJS about 120 seconds. I am very well aware that these absolute numbers are not so high, at least compared to languages such as Scala. However, I perform recompilations several times per day, and this adds up. What adds up even more, is the time it takes for Chrome to perform a hard refresh of the page (about 6 seconds), which happens many many more times per day. Funny that you mention large namespaces as a possible problem, because I personally had the impression that in a Figwheel environment, having less-but-somewhat-bigger namespaces was actually preferable to having more-but-smaller namespaces. FYI: I currently have about 200 CLJS/CLJC namespaces, differing in size between 50-800 lines on average. The total amount of CLJS/Javascript code loaded during development is about 20 MB — which doesn't seem out of the ordinary, right? -- 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: CPU & platform for best compilation performance
Shot in the dark, but dependent namespace compilation may be the source of
your CLJS compiler slowdowns if you have tons of namespaces. Try seeing
what happens when you set :recompile-dependents to false in the CLJS
compiler options.
On Wednesday, August 23, 2017 at 11:54:44 AM UTC-4, Maarten Truyens wrote:
>
> Hi all,
>
> My codebase (mix of CLJ, CLJS and CLJS) is about fifty thousand lines of
> code, and compilation times are starting to interfere with my workflow
> happiness. In addition, Chrome Devtools is becoming somewhat sluggish due
> to the high number of separate namespaces loaded through Figwheel.
>
> My current machine is a 6-core Mac Pro 3.5 Ghz Xeon ("late 2013"). For
> quite a while I have been investigating whether a switch to another machine
> and/or platform would be interesting from a workflow speed point of view.
> However, aside from Timothy Pratley's article on the AMD Ryzen 1800x (
> http://timothypratley.blogspot.in/2017/03/ryzen-is-for-programmers.html),
> I have trouble finding information that is relevant for us Clojure
> programmers.
>
> I would summarize my research as follows:
> * single-core performance is most important, so that it is probably the
> case that a 4-core CPU with a higher single-thread speed is preferable to
> an 6/8/10-core CPU with a slower single-thread speed;
> * as from 4 cores, there are hardly any speedups to be expected for having
> more cores in CLJ or even (parallel) CLJS builds;
> * the Ryzens are great value, but their single-core performance is usually
> 10-20% below the top of the line Intels;
> * according to the many Phoronix benchmarks, Linux and OSX have about the
> same performance, although there are some interesting deviations for some
> workflows (even up to 30 - 40%);
> * the single-core performance difference between my current CPU and the
> single-core top of the line (i7700K, i7-7800X or i7-7820X) seems to be
> between 20-40%
>
> While a 50% performance increase would be enough to warrant the time
> investment & cost of switching, my fear is that the real-world speed-up
> will probably be more like a meager 20%.
>
> Ignoring cost considerations and performance outside CLJ development: what
> CPU and platform would you recommend?
>
> Many thanks!
>
> Maarten
>
--
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: Sum types in Clojure? Better to represent as tagged records or as variant vectors?
I usually model sum types as maps with either a :type or :tag key to specify the kind of map it is. Occasionally, I use vectors with the tag in the first position, especially when I need to favor concision, for example, when the data is serving as a DSL with which I will be manually entering a lot of data. I almost never use records for sum types. Using vectors would be somewhat more useful with core.match, because it is easy to combine taking cases on the tag with destructuring the correct number of expected slots after the tag. I personally don't trust core.match for serious projects, because it is still in alpha after 7 years. With regular destructuring, vectors are best for scenarios where each vector has the same number of slots -- then you can naturally destructure all the slots of the vector at once in the input to the function. I avoid records for this kind of use because: 1. They aren't sufficiently flexible when the needs of projects change (i.e., everything you can do with records and protocols you can do with maps and multimethods, but not vice versa). 2. Records and protocols tend to mess up the state of your REPL (e.g., when defrecords are recompiled they cause problems with instance? calls and equality checks to things in memory until your whole program is recompiled and prior objects thrown away). 3. Until a very recent 1.9 alpha, records performed poorly in sets or as keys in a map because they didn't cache their hash values. 4. Use of records and protocols requires much more careful code organization because it is all too easy to run afoul of Clojure's lack of support for cyclical dependencies between namespaces. -- 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] Citrus (Scrum) 3.0.0 — State management library for Rum
To avoid confusion with Agile term “Scrum” the library, artifact and namespaces were renamed to *Citrus* since v3.0.0. Older versions are still available under the old name *Scrum*. To migrate to v3.0.0+ replace all occurrences of *scrum* with *citrus.* Old artifact name: *org.roman01la/scrum* New artifact name: *org.roman01la/citrus* Namespaces changes: - scrum.core -> citrus.core - scrum.cursor -> citrus.cursor - scrum.macros -> citrus.macros - scrum.reconciler -> citrus.reconciler - scrum.resolver -> citrus.resolver https://github.com/roman01la/citrus -- 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-alpha18
Just for everyone's info: seems this update breaks CIDER 0.15: https://github.com/clojure-emacs/cider/issues/2081 -- 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-alpha18
> > Tighten autoresolved keywords and autoresolved namespace map syntax to > support *only* aliases, as originally intended What does this mean? Is there a JIRA discussion about this? On 24 August 2017 at 04:03, Alex Miller wrote: > Clojure 1.9.0-alpha18 is now available. > > Try it via > > - Download: https://repo1.maven.org/maven2/org/clojure/ > clojure/1.9.0-alpha18 > - Leiningen: [org.clojure/clojure "1.9.0-alpha18"] > > 1.9.0-alpha18 includes the following changes since 1.9.0-alpha17: > > - Can now bind *reader-resolver* to an impl of LispReader$Resolver to > control the reader's use of namespace interactions when resolving > autoresolved keywords and maps. > - Tighten autoresolved keywords and autoresolved namespace map syntax to > support *only* aliases, as originally intended > - Updated to use core.specs.alpha 0.1.24 > > -- > 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: [ANN] Clojure 1.9.0-alpha18
The breakage in CIDER is a good example of what this change disallows: java.lang.RuntimeException: Invalid token: ::clojure.test/once-fixtures Invalid because clojure.test is not an alias – so it should be :clojure.test/once-fixtures instead (or ::test/once-fixtures). See the source here: https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/test.clj#L124-L138 Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood From: Colin Fleming Sent: Wednesday, August 23, 2017 5:59 PM To: clojure@googlegroups.com Subject: Re: [ANN] Clojure 1.9.0-alpha18 Tighten autoresolved keywords and autoresolved namespace map syntax to support *only* aliases, as originally intended What does this mean? Is there a JIRA discussion about this? On 24 August 2017 at 04:03, Alex Miller wrote: Clojure 1.9.0-alpha18 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha18 - Leiningen: [org.clojure/clojure "1.9.0-alpha18"] 1.9.0-alpha18 includes the following changes since 1.9.0-alpha17: - Can now bind *reader-resolver* to an impl of LispReader$Resolver to control the reader's use of namespace interactions when resolving autoresolved keywords and maps. - Tighten autoresolved keywords and autoresolved namespace map syntax to support *only* aliases, as originally intended - Updated to use core.specs.alpha 0.1.24 -- 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. -- 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-alpha18
Correct, this was just something Rich ran into while doing the pluggable resolver work. The intent has always been that only aliases were to be supported in auto-resolved keyword qualifiers and fully-qualified keywords there would accidentally work. The spec and code now *only* support aliases. On Wed, Aug 23, 2017 at 9:01 PM, Sean Corfield wrote: > The breakage in CIDER is a good example of what this change disallows: > > > > java.lang.RuntimeException: Invalid token: ::clojure.test/once-fixtures > > > > Invalid because clojure.test is not an alias – so it should be > :clojure.test/once-fixtures instead (or ::test/once-fixtures). See the > source here: > > > > https://github.com/clojure-emacs/cider-nrepl/blob/master/ > src/cider/nrepl/middleware/test.clj#L124-L138 > > > > Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > > *From: *Colin Fleming > *Sent: *Wednesday, August 23, 2017 5:59 PM > *To: *clojure@googlegroups.com > *Subject: *Re: [ANN] Clojure 1.9.0-alpha18 > > > > Tighten autoresolved keywords and autoresolved namespace map syntax to > support *only* aliases, as originally intended > > > > What does this mean? Is there a JIRA discussion about this? > > > > On 24 August 2017 at 04:03, Alex Miller wrote: > > Clojure 1.9.0-alpha18 is now available. > > > > Try it via > > > > - Download: https://repo1.maven.org/maven2/org/clojure/ > clojure/1.9.0-alpha18 > > - Leiningen: [org.clojure/clojure "1.9.0-alpha18"] > > > > 1.9.0-alpha18 includes the following changes since 1.9.0-alpha17: > > > > - Can now bind *reader-resolver* to an impl of LispReader$Resolver to > control the reader's use of namespace interactions when resolving > autoresolved keywords and maps. > > - Tighten autoresolved keywords and autoresolved namespace map syntax to > support *only* aliases, as originally intended > > - Updated to use core.specs.alpha 0.1.24 > > -- > 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. > > > > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/clojure/rb22V98rPLM/unsubscribe. > To unsubscribe from this group and all its topics, 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.
[ANN] clj-chrome-devtools 0.1.1
A simple new library for controlling a headless Chrome browser from Clojure using the Chrome Devtools Protocol. https://github.com/tatut/clj-chrome-devtools All CDP commands are supported (as they are automatically generated from the protocol specification by macros). Also contains a rudimentary higher-level API and a clojure.test fixture for starting a fresh headless Chrome. -- 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.
