[ANN] Instaparse 1.5.0

[Mark Engelberg]

Instaparse is a library for generating parsers from context-free grammars.
https://github.com/engelberg/instaparse

The main new feature in this release is support for namespaced
non-terminals in your grammar, which become namespaced keywords in the
parser's tagged output. Namespaced keywords have become much more prevalent
in Clojure style in the years since instaparse was first released, so I
suspect many will find it useful to have direct support for namespaces.

Namespaces utilize `.` and `/` characters which have other meanings in
grammar specifications. It shouldn't cause any problems provided there's
some whitespace around these characters when using them as grammar
operators, but I wanted to be sure not to break previous grammars where
there was no reason to be careful with spacing, so this is an *opt-in *feature
for backwards compatibility. The way to opt-in to this feature is by adding
the optional keyword argument `:allow-namespaced-nts true` when building
your parser. For more explanation and an example, see the documentation
here:
https://github.com/Engelberg/instaparse?tab=readme-ov-file#namespaced-keywords

Thanks to Oliver (github.com/or) for suggesting this feature two years ago
and providing the pull request that was the foundation of this release. And
thanks to Clojurists Together for making it feasible for me to spend time
digging back into instaparse, evaluating and testing pull requests, and
working to get them merged and documented.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOMohCDNgeFbBfGiZ7UGSD1JYiK64xLrSfaHSCQydWJXQA%40mail.gmail.com.

Re: Clojure 1.11 is now available!

[Mark Engelberg]

Exciting! Thanks for the new release.

Where can I find more information about the new iteration function? The
docstring alone isn't sufficient for me to understand how to use it
effectively.

On Tue, Mar 22, 2022 at 9:22 AM Alex Miller 
wrote:

> You can find an overview here:
> https://clojure.org/news/2022/03/22/clojure-1-11-0
>
> And full changelog here:
>
> https://github.com/clojure/clojure/blob/master/changes.md#changes-to-clojure-in-version-1110
>
> Enjoy!
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/3814ba94-48bc-4cd2-9b54-00782c53862en%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOMi-wXqTb7umk15Sx5SBD7xN74bY2DB1W5oE%2Bgn6vnbqw%40mail.gmail.com.

[ANN] rolling-stones 1.0.2

[Mark Engelberg]

https://github.com/Engelberg/rolling-stones

rolling-stones is a satisfaction solver, a Clojure wrapper for the SAT4J
Java solver.

Version 1.0.2 updates the dependency to a newer version of SAT4J,
implements a workaround for a memory leak in SAT4J, and introduces a new
option to express timeout as a number of conflicts encountered in the
solving process rather than milliseconds.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOMw46MK%2BfbNVmksnOGjCK0GTdPYgv7-0CCEEt8Y%2B9GYRA%40mail.gmail.com.

Re: Accessing Record fields with keywords in ClojureScript not working as in Clojure

[Mark Engelberg]

You misspelled default in your defrecord.

On Tue, Aug 4, 2020 at 7:42 AM 'clartaq' via Clojure <
clojure@googlegroups.com> wrote:

> I originally posted
> 
> this on StackOverflow.
>
> When I try this:
>
> ```clojure
> (defrecord Attr [has-default default])
> (def attr (->Attr true 1))
> (get attr :default) ;;=> 1
> (:default attr) ;;=> ClojureScript returns nil, Clojure returns 1
> ```
>
> Is the difference in behavior when using keyword access expected? I
> couldn't find anything about it in the [docs][1]  on the differences
> between Clojure and ClojureScript.
>
> **Update 2020-08-04**
>
> Well, this is getting weird. This morning, if I open a REPL with
> figwheel-main, or from CIDER, it sometimes works as expected -- `(:default
> attr)` returns 1.
>
> If I try it by opening the ClojureScript REPL using `clj`, it is still
> broken.
>
> ```clojure
> % clj --main cljs.main --repl
> ClojureScript 1.10.773
> cljs.user=> (defrecord Attr [has-default defaut])
> cljs.user/Attr
> cljs.user=> (def attr (->Attr true 1))
> #'cljs.user/attr
> cljs.user=> (get attr :default)
> nil
> cljs.user=> (:default attr)
> nil
> cljs.user=> (:has-default attr)
> true
> cljs.user=> (println "attr: " attr)
> attr:  #cljs.user.Attr{:has-default true, :defaut 1}
> nil
> ```
>
>
>   [1]: https://www.clojurescript.org/about/differences#_data_structures
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/5dd44871-3915-4d80-a959-28be44c8cc32o%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMON7N3ukBEn%3D%3DzX8pAz3tJg%2BjX32x4TTDDqYdCxbWDswbA%40mail.gmail.com.

[ANN] ubergraph 0.8.0 - new features and speed improvements

[Mark Engelberg]

https://github.com/Engelberg/ubergraph
Ubergraph is a batteries-loaded, immutable graph data structure for Clojure.

One of the most useful aspects of ubergraph has always been its
super-charged shortest-path function, which encompasses least-distance,
least-cost, and A* searches; targeted endpoints or open-ended searches;
strict results or lazy sequences of search progress.

Now, ubergraph's powerful shortest-path function can be used in search
contexts other than ubergraph -- all you need to do is define a transition
function and you can run its sophisticated search algorithms. This is
especially useful when you are dealing with an infinite number of states,
or a state space which is unknown (e.g., a puzzle where you know the
starting configuration and transition rules, but don't know the states you
can get to).

A new function, paths->graph, will convert the search results into an
ubergraph for further analysis.

Check out
https://github.com/Engelberg/ubergraph#search-driven-graph-generation for
examples and more details.

Finally, all the nested map access has been rewritten using the powerful
specter library for improved speed. Thanks to those who tested the specter
branch for this release.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOP8_NdpLzveyerf1HS3VgJBogZVtus006q6c8Rf4XwS4g%40mail.gmail.com.

Re: Ubergraph - request for volunteers to benchmark alternative implementation

[Mark Engelberg]

Thanks.

On Sat, Aug 17, 2019 at 2:41 PM Colin Taylor  wrote:

> I didn't strip it down for a true benchmarking test and my use case is
> large but fairly sparsely connected graphs, but I get about 10% improvement.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/fb84ca0c-5324-4730-b71c-10a02693d97c%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOO6KoZ8zErnV4VOihu%3DoXpOqRw8PHwE%3DWC0BnwUJhuUqw%40mail.gmail.com.

Re: Ubergraph - request for volunteers to benchmark alternative implementation

[Mark Engelberg]

That's great news. Thanks for the report.

On Sat, Aug 17, 2019 at 7:59 AM Matthias Nehlsen 
wrote:

> Just tried it out and the improvements were substantial. I tried to add
> 94K nodes (journal entries) to a graph, most of which have multiple edges,
> and with 0.7.2 it took 137 seconds, whereas with the specter branch, it
> only took 92 seconds. Everything else worked fine as well. Thanks for this
> library, been working very well for me in https:/github.com/matthias/meins
> .
>
> On Wednesday, August 14, 2019 at 9:09:02 AM UTC+2, puzzler wrote:
>>
>> I have created a "specter" branch of ubergraph which uses the specter
>> library for all nested map access and transformations. I believe this will
>> speed up ubergraph, especially for adding and removing edges, but I would
>> like it if some users of ubergraph would compare the performance of the
>> specter branch against the 0.7.0 master branch on their graphs.
>>
>> https://github.com/Engelberg/ubergraph/tree/specter
>>
>> If the speed improvement is enough to warrant the added dependency, I'll
>> merge the specter branch into master.
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/bdfc451a-9108-4728-89f7-1a23263b15fd%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMONreQ2Ojep%2BjDuBVokcuA4QKrnxfjbPaPr8dmC3Uo9icQ%40mail.gmail.com.

Ubergraph - request for volunteers to benchmark alternative implementation

[Mark Engelberg]

I have created a "specter" branch of ubergraph which uses the specter
library for all nested map access and transformations. I believe this will
speed up ubergraph, especially for adding and removing edges, but I would
like it if some users of ubergraph would compare the performance of the
specter branch against the 0.7.0 master branch on their graphs.

https://github.com/Engelberg/ubergraph/tree/specter

If the speed improvement is enough to warrant the added dependency, I'll
merge the specter branch into master.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOMJjkmW3A0odB66XjucYJcfyCv0zMNu9epUnOOu95NJFQ%40mail.gmail.com.

[ANN] ubergraph 0.7.0

[Mark Engelberg]

https://github.com/Engelberg/ubergraph
https://github.com/Engelberg/ubergraph/blob/master/CHANGES.md

Ubergraph is a batteries-loaded, immutable graph data structure for Clojure.

Version 0.7.0's main addition is two new convenience functions for viewing
nodes and edges with attributes attached.

See: https://github.com/Engelberg/ubergraph#attributes for a description of
the two new functions and their use cases.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMONuA3Sc0xixEwUQicvbaEawF%2Bz-xLxF_6Cv8rgnYW4L4w%40mail.gmail.com.

Re: [ANN] tarantella 1.1.1

[Mark Engelberg]

Thanks for writing the n-queens code and the blog post. It's great to see
tarantella performing well.

There's a certain amount of overhead associated with setting up the dancing
links data structure, so I would conjecture that as your problem gets more
complicated (e.g., increasing n), you'd see tarantella become competitive
with the fastest of your hand-rolled implementations.

On Tue, Jul 30, 2019 at 2:18 PM Steve Miner  wrote:

> Thanks for updated Tarantella.  I also enjoyed re-watching your talk.
>
> I just wrote a blog post to cover a simple solution to the Eight Queens
> problem using Tarantella.
>
> http://conjobble.velisco.com/2019/07/30/tarantella-queens.html
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/FE9197F8-C372-481D-B32D-2D7B9583F068%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOPhBPzDOr0Ai5HaREqOP%2Bo13-ho3NKJBcMBWu6wc1FSFw%40mail.gmail.com.

[ANN] tarantella 1.1.1

[Mark Engelberg]

"You won't believe this one weird trick for solving Sudokus and other
puzzles."

Tarantella is an implementation of Knuth's Dancing Links algorithm. I
demonstrated in my 2017 Clojure Conj talk how it can be used to solve an
assortment of puzzles (https://youtu.be/TA9DBG8x-ys) and some of you may
have played around with the library after that talk.

I've recently made a number of improvements and refinements, and completely
overhauled the README. Those of you with an interest in puzzles and/or
constraint programming may enjoy reading through the README and getting a
feel for how this library can be applied to certain classes of constraint
problems.

Tarantella is also a great case study in the combination of speed and
expressiveness you can get by writing a Clojure API for a lower-level
implementation written in Java.

https://github.com/Engelberg/tarantella

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOPOPRZ%3DeJOWT3AKrzrfLTxq%2B4rOrGDpH5DxHLAOB0gxkQ%40mail.gmail.com.

[ANN] clojure.math.combinatorics 0.1.6

[Mark Engelberg]

https://github.com/clojure/math.combinatorics

clojure.math.combinatorics is a Clojure contrib library for generating
permutations, combinations, subsets, selections, and partitions of
collections.

The new release provides a workaround for longstanding issues in Clojure
that cause (apply concat ...) and mapcat to be insufficiently lazy.

https://clojure.atlassian.net/browse/CLJ-1583
https://clojure.atlassian.net/browse/CLJ-1218

Also, new to version 0.1.6 is permuted-combinations, which permutes all the
combinations.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOPoE6GnQy1jMELc3RUCwPkrnNq%3Den4qNPBFTtEM3fhzaA%40mail.gmail.com.

[ANN] better-cond 2.1.0

[Mark Engelberg]

https://github.com/engelberg/better-cond

better-cond allows for :let bindings inside of cond, as well as a handful
of other goodies that provide for clearer, more readable code by minimizing
"rightward drift".

2.1.0 fixes a bug in the handling of pre/post-maps in the defnc macro.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOOZzQ4bFT_nPLJKG0pzCqKuBvJ7GFwomnQT3OQwdHdv_w%40mail.gmail.com.

[ANN] ubergraph 0.6.0

[Mark Engelberg]

https://github.com/Engelberg/ubergraph
https://github.com/Engelberg/ubergraph/blob/master/CHANGES.md

Ubergraph is a batteries-loaded, immutable graph data structure for Clojure.

Version 0.6.0 includes several pull requests from the community: a bugfix,
performance improvement, documentation improvements, and better handling of
special characters and namespaced keywords in graphviz output. Special
shoutout to Andy Fingerhut who did most of the work on this release.

Ubergraph has now been in use for over four years, and has no open bug
reports in github.

Given that Loom is Clojure's other main graph library, many people are
interested in how Ubergraph and Loom compare.

Broadly speaking, Ubergraph is a superset of Loom that fulfills Loom's
protocols offering several features and algorithms beyond what Loom
supports:

* Multigraphs and multidigraphs with parallel edges, i.e., multiple edges
between the same pair of nodes in the same direction.
* Multiple weights per edge (as opposed to one "privileged" weight
attribute).
* Weights that are modifiable after initialization (in the immutable sense
of producing a new graph structure with modified weights).
* Mixtures of directed and undirected edges in the same graph.
* The ability to distinguish between an undirected edge and an opposing
pair of directed edges.
* The ability to traverse all a graph's edges while guaranteeing that
undirected edges are visited only once.

Because Ubergraph implements Loom protocols, Ubergraph can typically be
used as a drop-in replacement for Loom graphs.  For the most part, Loom's
graph algorithms work on ubergraphs, and Ubergraph's graphalgorithms work
on loom graphs.  There are some exceptions to this, because in some cases,
the implementation of Loom's algorithms were not carefully implemented to
rely only on Loom's protocol abstractions, but were hard-coded to specific
aspects of Loom's concrete implementation.  And since Loom wasn't written
with multigraphs in mind, some of Loom's algorithms don't work properly on
multigraphs.

Ubergraph's algorithm namespace contains a curated collection of algorithms
from Loom known to work properly on ubergraph's more general data
structure, improved versions of several critical algorithms from Loom, and
reimplementations of several key algorithms from Loom known to be broken on
multigraphs.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAORbMOP2GYkSJxdzDUwDvGZtchuQms95mCJTyeG4EOBuHf8Yjw%40mail.gmail.com.

pprint

[Mark Engelberg]

Is there any way to make Clojure's pprint print the record tags for
records? It seems odd to me that Clojure's main printer has evolved
improved support for records over the years, but pprint still prints
records as a plain, untagged map.

-- 
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: Inside Clojure Journal

[Mark Engelberg]

+1.

I can't seem to subscribe my email to Alex's blog using the form at the
bottom of the blog. Clicking the button does nothing. Anyone else having
that problem?

On Tue, Jan 29, 2019 at 9:03 PM Shaun Parker  wrote:

> I just wanted to say thanks to Alex for taking the time to journal all the
> Clojure things he's working on (and the non-Clojure things as well).
> They're enjoyable to read and eye-opening. It's a great window into the
> effort that he and others are putting into Clojure. It's been fun to follow
> the spec-alpha2 commits and get to read the thoughts/direction in the
> journal. Great work Alex!
>
> You can find them on the Inside Clojure blog: http://insideclojure.org/
>
> Shaun
>
>
> --
> 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.

Understanding tap

[Mark Engelberg]

At first glance, tap seems like it doesn't compose well; two Clojure
libraries that use tap for different purposes can't be combined.

What is the reasoning behind having one global tap, rather than some sort
of pub/sub model?

-- 
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: Clojure 1.10 issue: thrown? no longer works on macros

[Mark Engelberg]

And the macro which that test case exercises can be found here:
https://github.com/Engelberg/instaparse/blob/dcfffad5b065e750f0f5835f017cdd8188b8ca2e/src/instaparse/core.cljc#L274

-- 
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: Clojure 1.10 issue: thrown? no longer works on macros

[Mark Engelberg]

And to be as specific as possible, the actual test that worked in 1.9 but
not in 1.10 is:
https://github.com/Engelberg/instaparse/blob/dcfffad5b065e750f0f5835f017cdd8188b8ca2e/test/instaparse/defparser_test.cljc#L34

I've temporarily elided the test from the instaparse test suite, but wanted
to report it.  Again, I apologize for not realizing the eval/quote was an
important aspect and leading you down a rabbit hole.

On Tue, Dec 18, 2018 at 12:21 PM Mark Engelberg 
wrote:

> Sorry, I tried to "shrink the error case" and I appear to have gone too
> far.  The actual problem would be more like:
> => (is (thrown? AssertionError (eval (quote (f true
>
> On Tue, Dec 18, 2018 at 11:11 AM Alex Miller  wrote:
>
>> Oh, if you're testing with thrown-with-msg?, that definitely can have an
>> impact due to the nested exception. In clojure.test, I'm using a variant to
>> test the message with the root cause:
>>
>>
>> https://github.com/clojure/clojure/blob/master/test/clojure/test_helper.clj#L134-L151
>>
>> On Tuesday, December 18, 2018 at 12:06:18 PM UTC-6, Andy Fingerhut wrote:
>>>
>>> I do not know if Leiningen is involved in the difference in the
>>> reproduction project linked below yet (I am testing with the latest
>>> Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg?
>>> ...` expression that gives no error when running 'lein test' with Clojure
>>> 1.9.0, but does with Clojure 1.10.0.  I do not know if it is the same root
>>> cause as Mark's example or not, but wanted to create this in hopes it
>>> represents a minimal test case to reproduce the behavior difference.
>>>
>>> https://github.com/jafingerhut/clojure-110-is-thrown
>>>
>>> Andy
>>>
>>> On Tue, Dec 18, 2018 at 7:07 AM Alex Miller  wrote:
>>>
>>>> In particular, I am challenging this assertion from the original post:
>>>>
>>>> However, the following test (using is from clojure.test) used to work
>>>> prior to 1.10, but now fails:
>>>>
>>>> => (is (thrown? AssertionError (f true)))
>>>> Unexpected error (AssertionError) macroexpanding f at
>>>> (test:localhost:62048(clj)*:268:56).
>>>> Assert failed: (number? x)
>>>>
>>>>
>>>> When I do this on 1.9 I see:
>>>>
>>>> user=> (is (thrown? AssertionError (f true)))
>>>> CompilerException java.lang.AssertionError: Assert failed: (number? x),
>>>> compiling:(NO_SOURCE_PATH:20:29)
>>>>
>>>>
>>>> Which is printed differently but is the same behavior, because this is
>>>> happening while expanding the is, not during execution.
>>>>
>>>> I believe you're seeing a change in your test suite, I'm just having a
>>>> hard time reproducing what you're seeing.
>>>>
>>>>
>>>> On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:
>>>>>
>>>>> This particular example given fails in a similar way on 1.9. Could you
>>>>> give me something closer to what you are actually seeing in your test
>>>>> suite? Specifically something that is a passing clojure.test test on 1.9
>>>>> but a failure/error on 1.10?
>>>>>
>>>>> The problem with the given example is that it fails during
>>>>> macroexpansion of the test itself, not during test execution, and I don't
>>>>> think that's the case you're trying to replicate.
>>>>>
>>>>> On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>>>>>>
>>>>>> I think the relevant change here is that exceptions thrown during
>>>>>> macroexpansion are now wrapped into CompilerExceptions as a way to attach
>>>>>> all of the source context information. The REPL understands this and 
>>>>>> still
>>>>>> prints the original cause so the printing hides some of that structure 
>>>>>> (but
>>>>>> you can see it by looking at the exception chain).
>>>>>>
>>>>>> This here is a particularly tricky case here though and I think there
>>>>>> might be something else coming into play, still looking at it. There was 
>>>>>> a
>>>>>> couple other changes inside the compiler exception handling that might 
>>>>>> also
>>>>>> be coming into play.
>>>

Re: Clojure 1.10 issue: thrown? no longer works on macros

[Mark Engelberg]

Sorry, I tried to "shrink the error case" and I appear to have gone too
far.  The actual problem would be more like:
=> (is (thrown? AssertionError (eval (quote (f true

On Tue, Dec 18, 2018 at 11:11 AM Alex Miller  wrote:

> Oh, if you're testing with thrown-with-msg?, that definitely can have an
> impact due to the nested exception. In clojure.test, I'm using a variant to
> test the message with the root cause:
>
>
> https://github.com/clojure/clojure/blob/master/test/clojure/test_helper.clj#L134-L151
>
> On Tuesday, December 18, 2018 at 12:06:18 PM UTC-6, Andy Fingerhut wrote:
>>
>> I do not know if Leiningen is involved in the difference in the
>> reproduction project linked below yet (I am testing with the latest
>> Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg?
>> ...` expression that gives no error when running 'lein test' with Clojure
>> 1.9.0, but does with Clojure 1.10.0.  I do not know if it is the same root
>> cause as Mark's example or not, but wanted to create this in hopes it
>> represents a minimal test case to reproduce the behavior difference.
>>
>> https://github.com/jafingerhut/clojure-110-is-thrown
>>
>> Andy
>>
>> On Tue, Dec 18, 2018 at 7:07 AM Alex Miller  wrote:
>>
>>> In particular, I am challenging this assertion from the original post:
>>>
>>> However, the following test (using is from clojure.test) used to work
>>> prior to 1.10, but now fails:
>>>
>>> => (is (thrown? AssertionError (f true)))
>>> Unexpected error (AssertionError) macroexpanding f at
>>> (test:localhost:62048(clj)*:268:56).
>>> Assert failed: (number? x)
>>>
>>>
>>> When I do this on 1.9 I see:
>>>
>>> user=> (is (thrown? AssertionError (f true)))
>>> CompilerException java.lang.AssertionError: Assert failed: (number? x),
>>> compiling:(NO_SOURCE_PATH:20:29)
>>>
>>>
>>> Which is printed differently but is the same behavior, because this is
>>> happening while expanding the is, not during execution.
>>>
>>> I believe you're seeing a change in your test suite, I'm just having a
>>> hard time reproducing what you're seeing.
>>>
>>>
>>> On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:

 This particular example given fails in a similar way on 1.9. Could you
 give me something closer to what you are actually seeing in your test
 suite? Specifically something that is a passing clojure.test test on 1.9
 but a failure/error on 1.10?

 The problem with the given example is that it fails during
 macroexpansion of the test itself, not during test execution, and I don't
 think that's the case you're trying to replicate.

 On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>
> I think the relevant change here is that exceptions thrown during
> macroexpansion are now wrapped into CompilerExceptions as a way to attach
> all of the source context information. The REPL understands this and still
> prints the original cause so the printing hides some of that structure 
> (but
> you can see it by looking at the exception chain).
>
> This here is a particularly tricky case here though and I think there
> might be something else coming into play, still looking at it. There was a
> couple other changes inside the compiler exception handling that might 
> also
> be coming into play.
>
> (Would have been great to see this during a pre-release build rather
> than after release! ;)
>
>
> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:
>>
>> Agreed.  It is not a problem for functions which throw
>> AssertionErrors, only macros.  But this is a change in behavior which
>> breaks test suites which passed previously.
>>
>> On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:
>>
>>> I'm not sure, but probably it behaves so because of throwing at
>>> macroexpand stage.
>>>
>>> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler
>>> написал:

 Consider the following macro:

 (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
 => (f 3)
 8
 => (f true)
 Unexpected error (AssertionError) macroexpanding f at
 (test:localhost:62048(clj)*:265:28).
 Assert failed: (number? x)

 So, as expected it throws an AssertionError if passed a non-number.
 However, the following test (using is from clojure.test) used to
 work prior to 1.10, but now fails:

 => (is (thrown? AssertionError (f true)))
 Unexpected error (AssertionError) macroexpanding f at
 (test:localhost:62048(clj)*:268:56).
 Assert failed: (number? x)

 What's odd is that the macro still throws an AssertionError, but
 the `thrown?` inside the `is` is no longer intercepting the 
 AssertionError,
 so the test doesn't pass -- instead the error causes a failu

Re: Clojure 1.10 issue: thrown? no longer works on macros

[Mark Engelberg]

Agreed.  It is not a problem for functions which throw AssertionErrors,
only macros.  But this is a change in behavior which breaks test suites
which passed previously.

On Tue, Dec 18, 2018 at 1:48 AM alex  wrote:

> I'm not sure, but probably it behaves so because of throwing at
> macroexpand stage.
>
> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler написал:
>>
>> Consider the following macro:
>>
>> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
>> => (f 3)
>> 8
>> => (f true)
>> Unexpected error (AssertionError) macroexpanding f at
>> (test:localhost:62048(clj)*:265:28).
>> Assert failed: (number? x)
>>
>> So, as expected it throws an AssertionError if passed a non-number.
>> However, the following test (using is from clojure.test) used to work
>> prior to 1.10, but now fails:
>>
>> => (is (thrown? AssertionError (f true)))
>> Unexpected error (AssertionError) macroexpanding f at
>> (test:localhost:62048(clj)*:268:56).
>> Assert failed: (number? x)
>>
>> What's odd is that the macro still throws an AssertionError, but the
>> `thrown?` inside the `is` is no longer intercepting the AssertionError, so
>> the test doesn't pass -- instead the error causes a failure in the test
>> suite.
>>
> --
> 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.

Clojure 1.10 issue: thrown? no longer works on macros

[Mark Engelberg]

Consider the following macro:

(defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
=> (f 3)
8
=> (f true)
Unexpected error (AssertionError) macroexpanding f at
(test:localhost:62048(clj)*:265:28).
Assert failed: (number? x)

So, as expected it throws an AssertionError if passed a non-number.
However, the following test (using is from clojure.test) used to work prior
to 1.10, but now fails:

=> (is (thrown? AssertionError (f true)))
Unexpected error (AssertionError) macroexpanding f at
(test:localhost:62048(clj)*:268:56).
Assert failed: (number? x)

What's odd is that the macro still throws an AssertionError, but the
`thrown?` inside the `is` is no longer intercepting the AssertionError, so
the test doesn't pass -- instead the error causes a failure in the test
suite.

-- 
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] better-cond 2.0.2

[Mark Engelberg]

https://github.com/engelberg/better-cond

better-cond allows for :let bindings inside of cond, as well as a handful
of other goodies that provide for clearer, more readable code by minimizing
"rightward drift".

With the release of Clojure 1.10, I took this opportunity to bump the
dependencies and provide a non-snapshot release.

-- 
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.10 has been released!

[Mark Engelberg]

I'm excited by the new improvements.  Thanks!

On Mon, Dec 17, 2018 at 12:29 PM Tom Connors  wrote:

> Thanks a bunch to everyone involved. Your work is greatly appreciated!
>
> On Monday, December 17, 2018 at 12:30:01 PM UTC-5, Alex Miller wrote:
>>
>> Clojure 1.10 focuses on two major areas: improved error reporting and
>> Java compatibility.
>>
>>
>> Error reporting at the REPL now categorizes
>>  errors
>> based on their phase of execution (read, macroexpand, compile, etc). Errors
>> carry additional information about location and context as data, and
>> present phase-specific error messages with better location reporting. This
>> functionality is built into the clojure.main REPL, but the functionality is
>> also available to other REPLs and tools with the ability to use and/or
>> modify the data to produce better error messages.
>>
>>
>> Clojure 1.10 now requires Java 8 or above and has been updated
>> particularly for compatibility with Java 8 and Java 11. Changes included
>> bytecode-related bug fixes, removed use of deprecated APIs, and updates
>> related to the module system introduced in Java 9.
>>
>>
>> See the change log
>> 
>> for a complete list of all fixes, enhancements, and new features in Clojure
>> 1.10.
>>
>>
>> Thanks to all of the community members who contributed patches to Clojure
>> 1.10 (first time contributors in bold):
>>
>>
>>-
>> *Alexander Kiel *
>>- *Ben Bader*
>>- Bruce Adams
>>- *Cezary Kosko*
>>- Erik Assum
>>- *Eugene Kostenko*
>>- Ghadi Shayban
>>- *Gijs Stuurman*
>>- Jozef Wagner
>>-
>> *Kwang Yul Seo *
>>- *Matthew Gilliard*
>>- Michał Marczyk
>>- Nicola Mometto
>>- Nikita Prokopov
>>-
>> *Sean Corfield *
>>- *Sebastien Martel*
>>- Shogo Ohta
>>- Stuart Sierra
>>
>> --
> 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] com.walmartlabs/cond-let 1.0.0

[Mark Engelberg]

Documentation for latest features in the 2.0.1 branch:
https://github.com/Engelberg/better-cond/tree/v2.0.1

An example:

 (cond
   (odd? a) 1
   :let [a (quot a 2)]
   :when-let [x (fn-which-may-return-nil a),
  y (fn-which-may-return-nil (* 2 a))]
   :when (seq x)
   :do (println x)
   (odd? (+ x y)) 2
   :else 3)

The :do performs a side-effecting statement if it gets that far in the
cond.  :do is my favorite bonus addition for cond beyond :let.  I find I
use it a lot to quickly insert some debugging print commands without
needing to change the shape of my code, so it can be trivially removed
later.

When :do did not exist, but :let did exist in my cond macro, I found myself
frequently writing things like:
:let [_ (println x)]
in order to insert a side-effecting statement into the cond sequence.
:do is a cleaner solution.

:when only continues with the cond if the value is truthy, otherwise it
bails out of the cond with nil.
:when-some (not yet merged in) will do much the same thing, but continuing
if non-nil, rather than truthy.

:when, :when-some, and :when-let don't add a whole lot of richness.  For
example, that :when line in the example could just have easily been written
as:
(not (seq x)) nil

But using these can potentially add clarity of intention, so even though I
could make do without them, I go ahead and use them when relevant.

In better-cond's cond macro, that final :else is optional. You may prefer
the new cond-let library if you want to continue enforcing the use of :else
on the last clause.

To reiterate, :let is by far the most valuable addition, and I find :do to
be the second-most valuable addition.  Other additions are fairly minor
syntactic sugar.

On Thu, Oct 4, 2018 at 1:36 PM Alan Thompson  wrote:

> How would the :when and :do forms work?
> Alan
>
> On Wed, Oct 3, 2018 at 7:22 PM Mark Engelberg 
> wrote:
>
>> This looks like a case of "convergent evolution".
>>
>> Having the ability to do a :let in the middle of a cond feels like one of
>> those things that *should* be in the core language, so if it's not in
>> there, a bunch of people are naturally going to arrive at the same solution
>> and make it happen in their own utility libraries.  A bunch of us Clojure
>> programmers from the early 1.0 days had been privately passing around and
>> using a "cond that supports :let bindings" macro for years.  The first time
>> I saw the macro was in a blog post by Christophe Grand. I really hoped it
>> would make it into Clojure proper -- other functional languages like Racket
>> and F# support ways to bind local variables with "clearer, more linear
>> code, that doesn't make a march for the right margin", as Howard Lewis Ship
>> put it.  But after several years had passed without any indication that
>> CLJ-200 was ever going to be addressed, I eventually made the improved cond
>> macro into a clojars library.
>>
>> walmartlabs' cond-let addresses the most important thing (let), which is
>> the critical piece of functionality that feels like the most natural,
>> needed addition to the language.  better-cond's :let syntax is identical.
>> But as us old-school Clojurians passed around the "better cond" macro over
>> the years, it grew in functionality.  So in better-cond, I included the
>> other little improvements that had accumulated over time, which I had found
>> useful.  So better-cond also supports :when, :when-let, and :do (and will
>> soon have :when-some).  :let is the only piece that I felt really belonged
>> in the core language's cond, and if CLJ-200 had made it into the core
>> language, I would have been content to just use Clojure's own cond.  But
>> once I realized I was going to need a library to achieve the much-needed
>> :let inside of cond, I figured I might as well use that library to include
>> the other convenient cond additions as well.  So better-cond is a superset
>> of cond-let's functionality, with support for :let plus a few bonuses.
>>
>> Use whichever one strikes your fancy.  cond-let is perfect if all you
>> care about is adding :let to your cond.  If you want to experiment with
>> some of the other features beyond :let, you could use better-cond and see
>> what you think.
>>
>> Either way, I strongly encourage you to use one of these two libraries so
>> you can start using :let inside your cond.  I agree fully with Howard Lewis
>> Ship that it results in clearer code.  Try either library which supports
>> this -- it will change your life!
>>
>>
>> On Wed, Oct 3, 2018 at 5:05 PM Matching Socks 
>> wrote:
>>
>>> Is this a refinement of Mark Engelberg's "bette

Re: [ANN] com.walmartlabs/cond-let 1.0.0

[Mark Engelberg]

This looks like a case of "convergent evolution".

Having the ability to do a :let in the middle of a cond feels like one of
those things that *should* be in the core language, so if it's not in
there, a bunch of people are naturally going to arrive at the same solution
and make it happen in their own utility libraries.  A bunch of us Clojure
programmers from the early 1.0 days had been privately passing around and
using a "cond that supports :let bindings" macro for years.  The first time
I saw the macro was in a blog post by Christophe Grand. I really hoped it
would make it into Clojure proper -- other functional languages like Racket
and F# support ways to bind local variables with "clearer, more linear
code, that doesn't make a march for the right margin", as Howard Lewis Ship
put it.  But after several years had passed without any indication that
CLJ-200 was ever going to be addressed, I eventually made the improved cond
macro into a clojars library.

walmartlabs' cond-let addresses the most important thing (let), which is
the critical piece of functionality that feels like the most natural,
needed addition to the language.  better-cond's :let syntax is identical.
But as us old-school Clojurians passed around the "better cond" macro over
the years, it grew in functionality.  So in better-cond, I included the
other little improvements that had accumulated over time, which I had found
useful.  So better-cond also supports :when, :when-let, and :do (and will
soon have :when-some).  :let is the only piece that I felt really belonged
in the core language's cond, and if CLJ-200 had made it into the core
language, I would have been content to just use Clojure's own cond.  But
once I realized I was going to need a library to achieve the much-needed
:let inside of cond, I figured I might as well use that library to include
the other convenient cond additions as well.  So better-cond is a superset
of cond-let's functionality, with support for :let plus a few bonuses.

Use whichever one strikes your fancy.  cond-let is perfect if all you care
about is adding :let to your cond.  If you want to experiment with some of
the other features beyond :let, you could use better-cond and see what you
think.

Either way, I strongly encourage you to use one of these two libraries so
you can start using :let inside your cond.  I agree fully with Howard Lewis
Ship that it results in clearer code.  Try either library which supports
this -- it will change your life!


On Wed, Oct 3, 2018 at 5:05 PM Matching Socks  wrote:

> Is this a refinement of Mark Engelberg's "better-cond", or an alternative
> approach?
>
> I have not used better-cond myself, but it starts here:
> https://dev.clojure.org/jira/browse/CLJ-200.
>
> --
> 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: Clojure(Script) web apps in 2018

[Mark Engelberg]

Pedestal isn't cross-platform -- doesn't support Windows.
Yada's documentation is not complete (several chunks of the documentation
have said "coming soon" for years).
Luminus is a great choice, the only downside is that as luminus improves,
there's no easy way to incorporate those improvements into your own
application.
If you're not married to Reagent, Hoplon is another great choice, created
specifically for the kind of purpose you've described: single-page
applications with a strong RPC component. In many situations, I prefer the
precision control you get over the reactive flow in Hoplon over the "magic"
diffing/updating you get with Reagent.

On Fri, Sep 21, 2018 at 10:47 AM, Robert Levy  wrote:

> Luminus is great. Something people might not know about Luminus is that
> it's more of a project template than a framework per se. It solves the
> choice paralysis of what libraries to use when starting off.  It generates
> a project, and you can take or leave the decisions it makes because after
> project creation, as it is no longer involved any further after that.
>
> On Mon, Sep 17, 2018 at 7:36 PM Daniel  wrote:
>
>> Having built a couple of apps with Luminus (including a SPA), my vote
>> definitely goes there.  I've even been able to cherry-pick functions and
>> project organization from the leiningen template and inject them into a cli
>> app which had a server component.  Extremely well organized and
>> documented.  Easy to get started.  You'll get a tour of the entire
>> ecosystem too - it's the only option IMO which gives you experience with
>> all the popular ring-based libraries.
>>
>> --
>> 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: New developments in beginner-friendly editing/repl environments?

[Mark Engelberg]

As someone who has taught beginners, I agree 100% with Lee's wishlist.  It
is very important to have an easy install process that gets you to an
editing environment that lets you leverage existing text editing skills
with minimal or no paren magic, with a focus on making the indenting
reflect what the typed parens indicate.  I also place a premium on ease of
starting a REPL, switching to namespace of file, and sending file to REPL.

Cursive can become a fairly simple and intuitive environment... after a
couple hours of configuration.  I'd be curious to try the new Parinfer v2
sometime to see if it improves on the things that bothered me about v1.

Counterclockwise was the best beginner option for a long time, but sadly is
no longer supported.

If anyone is motivated to work on this problem, check out DrRacket as a
model of a great educational IDE: simple enough for beginners and robust
enough for power users.  Look especially at how they handle parens (right
paren and right square bracket by default will automatically type the
correct bracket to match the corresponding left bracket, but otherwise no
magic -- lots of great auto-indenting capabilities so you understand what
your parens are doing to the structure of the code).


On Mon, Aug 27, 2018 at 6:45 AM, 'Lee' via Clojure  wrote:

> This is my roughly-annual check-in to see if there are new good
> editing/execution options for me to use in my Clojure teaching and coding.
>
> My requirements are:
>
> - Simple installation/setup, even for new programmers, on Mac/Win/Linux
>
> - Usable by new programmers without significant training or learning curve
>
> - Syntax-aware re-indentation
>
> - Visual indication of matching brackets (e.g. matching bracket
> highlighted, or rainbow brackets, etc.)
>
> - No required use of paredit or parinfer
>
> Bells and whistles that would help but aren't as critical as the
> requirements listed above:
>
> - Access to argument lists, documentation, and symbol completion while
> typing
>
> - Integrated REPL, although a command-line REPL paired with an editor that
> met the requirements above would work
>
> I would be interested in solutions that work for Clojure and
> Clojurescript, or just Clojure, or just Clojurescript.
>
> Recent developments of which I'm aware but fall short of my requirements:
>
> - Nightcode and Lightmod, which would be fabulous if not for the required
> use of parinfer
>
> - Jupyter-based approaches, which also seem great except I see none with
> syntax-aware re-indentation for Clojure
>
> FYI what I'm currently using is a combination of Gorilla REPL and
> leiningen at the command line. This is quite nice although
> installation/setup is not as easy or foolproof as I would like (I've had
> students who tried and failed to get it working on their Windows laptops
> for an entire semester, messing with Java versions etc.), Gorilla REPL is
> not very actively maintained, and the requirement to do some things at the
> command line isn't ideal.
>
> Options I've used in the past, which more-or-less met my requirements but
> are no longer viable, include Clooj, Nightcode (old versions, before
> parinfer), and Counterclockwise.
>
> I also try to keep an eye on "high-end" IDEs like Emacs and Cursive, but
> so far haven't found any that really meet my requirements for simple
> installation/setup and usability for beginners.
>
> Any pointers would be very much appreciated!
>
> Thanks,
>
>  -Lee
>
> --
> Lee Spector, Professor of Computer Science
> Director, Institute for Computational Intelligence
> Hampshire College, Amherst, Massachusetts, 01002, USA
> lspec...@hampshire.edu, http://hampshire.edu/lspector/, 413-559-5352
>
> --
> 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 

Re: Calling proxy without reflection

[Mark Engelberg]

For those following along at home, it turned out not to be a problem with
the lein-virgil plugin.  It's apparently a bug in Clojure.  Renzo and I
distilled it down to the following steps:

user=> (definterface Interface (test []))
user.Interface
user=> (def p (proxy [Object Interface] [] (test [] 1)))
#'user/p
user=> (defn get-test [o] (.test ^Interface o))
#'user/get-test
user=> (get-test p)
1
user=> (definterface Interface (test []))
user.Interface
user=> (def p (proxy [Object Interface] [] (test [] 1)))
#'user/p
user=> (defn get-test [o] (.test ^Interface o))
#'user/get-test
user=> (get-test p)

ClassCastException user.proxy$java.lang.Object$Interface$936446c6 cannot be
cast to user.Interface  user/get-test (form-init7484886365563813996.clj:1)

-- 
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: Calling proxy without reflection

[Mark Engelberg]

I am seeing the same behavior when I remove the lein-virgil plugin.

On Tue, Jul 31, 2018 at 11:38 AM, Mark Engelberg 
wrote:

> That's surprising, but good to know. Thanks.
>
> On Tue, Jul 31, 2018 at 9:56 AM, Renzo Borgatti 
> wrote:
>
>> Hey Mark, it's lein-virgil interfering. As of why, better opening an
>> issue there.
>>
>> Renzo
>>
>> > On 30 Jul 2018, at 11:50, Mark Engelberg 
>> wrote:
>> >
>> > OK, I just pushed the repo (work in progress) to github.
>> https://github.com/Engelberg/mister-rogers
>> > At the bottom of mister-rogers.wrappers I tacked on the three lines
>> we've been discussing.
>> > https://github.com/Engelberg/mister-rogers/blob/523fc29f8827
>> 193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80
>> >
>> >
>> > Here's a REPL interaction:
>> >
>> > C:\devel\Clojure\mister-rogers>lein repl
>> >
>> > recompiling all files in ["C:\\devel\\Clojure\\mister-r
>> ogers\\src\\java"]
>> > :reloading (mister-rogers.core mister-rogers.protocols
>> mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test)
>> >
>> > recompiling all files in ["C:\\devel\\Clojure\\mister-r
>> ogers\\src\\java"]
>> > :reloading (mister-rogers.core mister-rogers.protocols
>> mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test)
>> > nREPL server started on port 49492 on host 127.0.0.1 - nrepl://
>> 127.0.0.1:49492
>> > REPL-y 0.3.7, nREPL 0.2.12
>> > Clojure 1.9.0
>> > Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18
>> > Docs: (doc function-name-here)
>> >   (find-doc "part-of-name-here")
>> >   Source: (source function-name-here)
>> >  Javadoc: (javadoc java-object-or-class-here)
>> > Exit: Control+D or (exit) or (quit)
>> >  Results: Stored in vars *1, *2, *3, an exception in *e
>> >
>> > user=> (in-ns 'mister-rogers.wrappers)
>> > #namespace[mister-rogers.wrappers]
>> > mister-rogers.wrappers=> (get-test p)
>> >
>> > ClassCastException mister_rogers.wrappers.proxy$j
>> ava.lang.Object$Interface$7e434bc9 cannot be cast to
>> mister_rogers.wrappers.Interface  mister-rogers.wrappers/get-test
>> (wrappers.clj:82)
>> >
>> >
>> > Thanks for looking at this.
>> >
>> >
>> > On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto 
>> wrote:
>> > Can you paste an entire repl session, starting from how you launch it
>> (e.g. lein repl vs clj -- ideally not from a project) reproducing this?
>> >  I'm interested in taking a look but I simply cannot repro :/
>> >
>> >> On 30 Jul 2018, at 11:40, Mark Engelberg 
>> wrote:
>> >>
>> >> Yes, it is in a fresh environment.
>> >>
>> >> I find that the problematic example does work in the user namespace,
>> but it doesn't work in my segmented namespace (ns mister-rogers.wrappers,
>> to be really specific).
>> >>
>> >> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto 
>> wrote:
>> >> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as
>> I'd expect.
>> >>
>> >> Are you testing this in a fresh environment?
>> >>
>> >>
>> >>> On 30 Jul 2018, at 11:31, Mark Engelberg 
>> wrote:
>> >>>
>> >>> I'm using 1.9.0.  Is this a behavior that recently changed?
>> >>>
>> >>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto 
>> wrote:
>> >>> Which version of clojure? This works fine in 1.10
>> >>>
>> >>> Clojure 1.10.0-master-SNAPSHOT
>> >>> user=> (set! *warn-on-reflection* true)
>> >>> true
>> >>> user=> (definterface Interface (test []))
>> >>> user.Interface
>> >>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>> >>> #'user/p
>> >>> user=> (defn get-test [o] (.test ^Interface o))
>> >>> #'user/get-test
>> >>> user=> (get-test p)
>> >>> 1
>> >>>
>> >>>
>> >>>> On 30 Jul 2018, at 11:26, Mark Engelberg 
>> wrote:
>> >>>>
>> >>>> Those fishy things were errors I made when simplifying and
>> transcribing the proxy to post, but I have it correct in my own code.
>> >>&g

Re: Type hinting protocol functions

[Mark Engelberg]

I still haven't found any definitive info on this. Any pointers?  Thanks.

On Sun, Jul 29, 2018 at 6:15 PM, Mark Engelberg 
wrote:

> I'm having trouble finding current documentation for type hinting protocol
> functions.
>
> Things like:
> Do you type hint the protocol definition or the implementation?
> Does type hinting primitives work?
> What about for a return value?
> What is the behavior if you type hint some of the parameters but not the
> others?
>
> Can someone point me in the right direction for this sort of info?
>
>

-- 
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: Calling proxy without reflection

[Mark Engelberg]

That's surprising, but good to know. Thanks.

On Tue, Jul 31, 2018 at 9:56 AM, Renzo Borgatti  wrote:

> Hey Mark, it's lein-virgil interfering. As of why, better opening an issue
> there.
>
> Renzo
>
> > On 30 Jul 2018, at 11:50, Mark Engelberg 
> wrote:
> >
> > OK, I just pushed the repo (work in progress) to github.
> https://github.com/Engelberg/mister-rogers
> > At the bottom of mister-rogers.wrappers I tacked on the three lines
> we've been discussing.
> > https://github.com/Engelberg/mister-rogers/blob/
> 523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_
> rogers/wrappers.clj#L80
> >
> >
> > Here's a REPL interaction:
> >
> > C:\devel\Clojure\mister-rogers>lein repl
> >
> > recompiling all files in ["C:\\devel\\Clojure\\mister-
> rogers\\src\\java"]
> > :reloading (mister-rogers.core mister-rogers.protocols
> mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test)
> >
> > recompiling all files in ["C:\\devel\\Clojure\\mister-
> rogers\\src\\java"]
> > :reloading (mister-rogers.core mister-rogers.protocols
> mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test)
> > nREPL server started on port 49492 on host 127.0.0.1 - nrepl://
> 127.0.0.1:49492
> > REPL-y 0.3.7, nREPL 0.2.12
> > Clojure 1.9.0
> > Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18
> > Docs: (doc function-name-here)
> >   (find-doc "part-of-name-here")
> >   Source: (source function-name-here)
> >  Javadoc: (javadoc java-object-or-class-here)
> > Exit: Control+D or (exit) or (quit)
> >  Results: Stored in vars *1, *2, *3, an exception in *e
> >
> > user=> (in-ns 'mister-rogers.wrappers)
> > #namespace[mister-rogers.wrappers]
> > mister-rogers.wrappers=> (get-test p)
> >
> > ClassCastException mister_rogers.wrappers.proxy$
> java.lang.Object$Interface$7e434bc9 cannot be cast to
> mister_rogers.wrappers.Interface  mister-rogers.wrappers/get-test
> (wrappers.clj:82)
> >
> >
> > Thanks for looking at this.
> >
> >
> > On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto 
> wrote:
> > Can you paste an entire repl session, starting from how you launch it
> (e.g. lein repl vs clj -- ideally not from a project) reproducing this?
> >  I'm interested in taking a look but I simply cannot repro :/
> >
> >> On 30 Jul 2018, at 11:40, Mark Engelberg 
> wrote:
> >>
> >> Yes, it is in a fresh environment.
> >>
> >> I find that the problematic example does work in the user namespace,
> but it doesn't work in my segmented namespace (ns mister-rogers.wrappers,
> to be really specific).
> >>
> >> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto 
> wrote:
> >> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as
> I'd expect.
> >>
> >> Are you testing this in a fresh environment?
> >>
> >>
> >>> On 30 Jul 2018, at 11:31, Mark Engelberg 
> wrote:
> >>>
> >>> I'm using 1.9.0.  Is this a behavior that recently changed?
> >>>
> >>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto 
> wrote:
> >>> Which version of clojure? This works fine in 1.10
> >>>
> >>> Clojure 1.10.0-master-SNAPSHOT
> >>> user=> (set! *warn-on-reflection* true)
> >>> true
> >>> user=> (definterface Interface (test []))
> >>> user.Interface
> >>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
> >>> #'user/p
> >>> user=> (defn get-test [o] (.test ^Interface o))
> >>> #'user/get-test
> >>> user=> (get-test p)
> >>> 1
> >>>
> >>>
> >>>> On 30 Jul 2018, at 11:26, Mark Engelberg 
> wrote:
> >>>>
> >>>> Those fishy things were errors I made when simplifying and
> transcribing the proxy to post, but I have it correct in my own code.
> >>>>
> >>>> Here's a more precise, tested minimal example:
> >>>>
> >>>> (definterface Interface (test []))
> >>>> (def p (proxy [Object Interface] [] (test [] 1)))
> >>>> (defn get-test [o] (.test ^Interface o))
> >>>>
> >>>> => (get-test p)
> >>>> This throws an error that it can't cast the proxy to Interface.
> >>>>
> >>>> If you remove the ^Interface type hint, then get-test will work b

Re: Calling proxy without reflection

[Mark Engelberg]

OK, I just pushed the repo (work in progress) to github.
https://github.com/Engelberg/mister-rogers
At the bottom of mister-rogers.wrappers I tacked on the three lines we've
been discussing.

https://github.com/Engelberg/mister-rogers/blob/523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80



Here's a REPL interaction:

C:\devel\Clojure\mister-rogers>lein repl

recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"]
:reloading (mister-rogers.core mister-rogers.protocols
mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test)

recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"]
:reloading (mister-rogers.core mister-rogers.protocols
mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test)
nREPL server started on port 49492 on host 127.0.0.1 - nrepl://
127.0.0.1:49492
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.9.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> (in-ns 'mister-rogers.wrappers)
#namespace[mister-rogers.wrappers]
mister-rogers.wrappers=> (get-test p)

ClassCastException
mister_rogers.wrappers.proxy$java.lang.Object$Interface$7e434bc9
cannot be cast to mister_rogers.wrappers.Interface
mister-rogers.wrappers/get-test (wrappers.clj:82)


Thanks for looking at this.


On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto  wrote:

> Can you paste an entire repl session, starting from how you launch it
> (e.g. lein repl vs clj -- ideally not from a project) reproducing this?
>  I'm interested in taking a look but I simply cannot repro :/
>
> On 30 Jul 2018, at 11:40, Mark Engelberg  wrote:
>
> Yes, it is in a fresh environment.
>
> I find that the problematic example *does* work in the user namespace,
> but it doesn't work in my segmented namespace (ns mister-rogers.wrappers,
> to be really specific).
>
> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto 
> wrote:
>
>> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd
>> expect.
>>
>> Are you testing this in a fresh environment?
>>
>>
>> On 30 Jul 2018, at 11:31, Mark Engelberg 
>> wrote:
>>
>> I'm using 1.9.0.  Is this a behavior that recently changed?
>>
>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto 
>> wrote:
>>
>>> Which version of clojure? This works fine in 1.10
>>>
>>> Clojure 1.10.0-master-SNAPSHOT
>>> user=> (set! *warn-on-reflection* true)
>>> true
>>> user=> (definterface Interface (test []))
>>> user.Interface
>>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>>> #'user/p
>>> user=> (defn get-test [o] (.test ^Interface o))
>>> #'user/get-test
>>> user=> (get-test p)
>>> 1
>>>
>>>
>>> On 30 Jul 2018, at 11:26, Mark Engelberg 
>>> wrote:
>>>
>>> Those fishy things were errors I made when simplifying and transcribing
>>> the proxy to post, but I have it correct in my own code.
>>>
>>> Here's a more precise, tested minimal example:
>>>
>>> (definterface Interface (test []))
>>> (def p (proxy [Object Interface] [] (test [] 1)))
>>> (defn get-test [o] (.test ^Interface o))
>>>
>>> => (get-test p)
>>> This throws an error that it can't cast the proxy to Interface.
>>>
>>> If you remove the ^Interface type hint, then get-test will work but will
>>> trigger reflection.
>>>
>>> Thanks for looking at this. It seems like it should work, but it doesn't.
>>>
>>>
>>> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto 
>>> wrote:
>>>
>>>> That's exactly what you should do and it does work, e.g.:
>>>>
>>>> user=> (set! *warn-on-reflection* true)
>>>> true
>>>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta
>>>> [] {:a 1})))
>>>> {:a 1}
>>>>
>>>> In your small example you have two errors that might be fishy: a
>>>> missing arg vector to pass to the super ctor and an extra `this` parameter
>>>> in the method impl (proxy, unlike reify, is anaphoric and binds `this` for
>>>> you)
>>>>
>>>>
>>>> On 30 Jul 2018, at 10:56, Mark Engelberg 
>>>> wrote:
>>>>
>>>

Re: Calling proxy without reflection

[Mark Engelberg]

Yes, it is in a fresh environment.

I find that the problematic example *does* work in the user namespace, but
it doesn't work in my segmented namespace (ns mister-rogers.wrappers, to be
really specific).

On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto  wrote:

> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd
> expect.
>
> Are you testing this in a fresh environment?
>
>
> On 30 Jul 2018, at 11:31, Mark Engelberg  wrote:
>
> I'm using 1.9.0.  Is this a behavior that recently changed?
>
> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto 
> wrote:
>
>> Which version of clojure? This works fine in 1.10
>>
>> Clojure 1.10.0-master-SNAPSHOT
>> user=> (set! *warn-on-reflection* true)
>> true
>> user=> (definterface Interface (test []))
>> user.Interface
>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>> #'user/p
>> user=> (defn get-test [o] (.test ^Interface o))
>> #'user/get-test
>> user=> (get-test p)
>> 1
>>
>>
>> On 30 Jul 2018, at 11:26, Mark Engelberg 
>> wrote:
>>
>> Those fishy things were errors I made when simplifying and transcribing
>> the proxy to post, but I have it correct in my own code.
>>
>> Here's a more precise, tested minimal example:
>>
>> (definterface Interface (test []))
>> (def p (proxy [Object Interface] [] (test [] 1)))
>> (defn get-test [o] (.test ^Interface o))
>>
>> => (get-test p)
>> This throws an error that it can't cast the proxy to Interface.
>>
>> If you remove the ^Interface type hint, then get-test will work but will
>> trigger reflection.
>>
>> Thanks for looking at this. It seems like it should work, but it doesn't.
>>
>>
>> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto 
>> wrote:
>>
>>> That's exactly what you should do and it does work, e.g.:
>>>
>>> user=> (set! *warn-on-reflection* true)
>>> true
>>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta
>>> [] {:a 1})))
>>> {:a 1}
>>>
>>> In your small example you have two errors that might be fishy: a missing
>>> arg vector to pass to the super ctor and an extra `this` parameter in the
>>> method impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>>>
>>>
>>> On 30 Jul 2018, at 10:56, Mark Engelberg 
>>> wrote:
>>>
>>> Let's say I have a proxy object:
>>>
>>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>>>
>>> Now, I want to call (.interfaceMethod p).  How do I do this without
>>> reflection?
>>> I would have thought that (.interfaceMethod ^MyInterface p) would work,
>>> but this results in an error message that this proxy object cannot be cast
>>> to MyInterface.
>>>
>>>
>>>
>>> --
>>> 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

Re: Calling proxy without reflection

[Mark Engelberg]

I'm using 1.9.0.  Is this a behavior that recently changed?

On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto  wrote:

> Which version of clojure? This works fine in 1.10
>
> Clojure 1.10.0-master-SNAPSHOT
> user=> (set! *warn-on-reflection* true)
> true
> user=> (definterface Interface (test []))
> user.Interface
> user=> (def p (proxy [Object Interface] [] (test [] 1)))
> #'user/p
> user=> (defn get-test [o] (.test ^Interface o))
> #'user/get-test
> user=> (get-test p)
> 1
>
>
> On 30 Jul 2018, at 11:26, Mark Engelberg  wrote:
>
> Those fishy things were errors I made when simplifying and transcribing
> the proxy to post, but I have it correct in my own code.
>
> Here's a more precise, tested minimal example:
>
> (definterface Interface (test []))
> (def p (proxy [Object Interface] [] (test [] 1)))
> (defn get-test [o] (.test ^Interface o))
>
> => (get-test p)
> This throws an error that it can't cast the proxy to Interface.
>
> If you remove the ^Interface type hint, then get-test will work but will
> trigger reflection.
>
> Thanks for looking at this. It seems like it should work, but it doesn't.
>
>
> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto 
> wrote:
>
>> That's exactly what you should do and it does work, e.g.:
>>
>> user=> (set! *warn-on-reflection* true)
>> true
>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta []
>> {:a 1})))
>> {:a 1}
>>
>> In your small example you have two errors that might be fishy: a missing
>> arg vector to pass to the super ctor and an extra `this` parameter in the
>> method impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>>
>>
>> On 30 Jul 2018, at 10:56, Mark Engelberg 
>> wrote:
>>
>> Let's say I have a proxy object:
>>
>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>>
>> Now, I want to call (.interfaceMethod p).  How do I do this without
>> reflection?
>> I would have thought that (.interfaceMethod ^MyInterface p) would work,
>> but this results in an error message that this proxy object cannot be cast
>> to MyInterface.
>>
>>
>>
>> --
>> 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.
>
>
> --
> You received th

Re: Calling proxy without reflection

[Mark Engelberg]

Those fishy things were errors I made when simplifying and transcribing the
proxy to post, but I have it correct in my own code.

Here's a more precise, tested minimal example:

(definterface Interface (test []))
(def p (proxy [Object Interface] [] (test [] 1)))
(defn get-test [o] (.test ^Interface o))

=> (get-test p)
This throws an error that it can't cast the proxy to Interface.

If you remove the ^Interface type hint, then get-test will work but will
trigger reflection.

Thanks for looking at this. It seems like it should work, but it doesn't.


On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto  wrote:

> That's exactly what you should do and it does work, e.g.:
>
> user=> (set! *warn-on-reflection* true)
> true
> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta []
> {:a 1})))
> {:a 1}
>
> In your small example you have two errors that might be fishy: a missing
> arg vector to pass to the super ctor and an extra `this` parameter in the
> method impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>
>
> On 30 Jul 2018, at 10:56, Mark Engelberg  wrote:
>
> Let's say I have a proxy object:
>
> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>
> Now, I want to call (.interfaceMethod p).  How do I do this without
> reflection?
> I would have thought that (.interfaceMethod ^MyInterface p) would work,
> but this results in an error message that this proxy object cannot be cast
> to MyInterface.
>
>
>
> --
> 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.

Calling proxy without reflection

[Mark Engelberg]

Let's say I have a proxy object:

(def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))

Now, I want to call (.interfaceMethod p).  How do I do this without
reflection?
I would have thought that (.interfaceMethod ^MyInterface p) would work, but
this results in an error message that this proxy object cannot be cast to
MyInterface.

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

Type hinting protocol functions

[Mark Engelberg]

I'm having trouble finding current documentation for type hinting protocol
functions.

Things like:
Do you type hint the protocol definition or the implementation?
Does type hinting primitives work?
What about for a return value?
What is the behavior if you type hint some of the parameters but not the
others?

Can someone point me in the right direction for this sort of info?

-- 
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: Front-end with Clojure Backend

[Mark Engelberg]

Luminus is a good way to understand how to build a full stack application
in Clojure:
http://luminusweb.net/

On Fri, Jul 27, 2018 at 1:33 PM, Satyam Ramawat 
wrote:

> I want to create front-end with Clojure backend, how should I approach.
> Can anyone please provide me sample project with Clojure backend and
> front-end which takes input from the list.
>
> --
> 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: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Mark Engelberg]

The book "Simply Scheme" teaches Scheme via a library that lets students do
things to either the left or right side of the list, even though the
operations on the right side of the list are inefficient.  That author
found it to be more intuitive to his students.

But Clojure is geared more towards professional programmers who understand
that different data structures have different strengths and weaknesses, and
who prefer to use an API that makes those strengths and weaknesses
explicit, rather than fooling you into doing something inefficient.  (nth
being a notable exception).

IMHO, a programming language for professionals will never be the ideal
choice for beginners, although Clojure is better than most professional
languages for that purpose.

On Sun, Jul 22, 2018 at 7:29 PM, Christian Seberino 
wrote:

>
> Just what is it that you want to teach? Principles of computation, or
>> Clojure? Not the same. If the former, forget Clojure and give them a week
>> to work thru The Little Schemer. Then move on to clojure and the much more
>> complex stuff involved.
>>
>
> I think you bring up a good point.
> I wonder if we all have one of 2 mental images of what people mean by a
> "Clojure intro class".  Many probably mean something like a real corporate
> class where
> people are trying to train developers on Clojure to get real work done.
>  I think more of the SICP/Scheme/MIT class where you have a lot of smart
> people with no programming experience and you want to give them a solid
> academic intro.
>
> I agree Scheme is great for that.  However, what I find delicious is that
> Clojure is this >| |<--- close to being *both* a super practical
> language
> *and* a better/cleaner teaching language!  This might surprise some but I
> actually think some things are more elegant in Clojure than Scheme!
> For example, I like "fn" over "lambda".  Also, I like the seq abstraction
> over nested conses for the fundamental data structure.
>
> cs
>
>
> --
> 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: concat and mapcat not sufficiently lazy

[Mark Engelberg]

Thanks, I hadn't seen those issues.
https://dev.clojure.org/jira/browse/CLJ-1218 talks about mapcat, and
https://dev.clojure.org/jira/browse/CLJ-1583 talks about apply. Those are
aspects of the problem, for sure, but fixing those two issues would not
solve the problem with (apply concat ...), I don't think, because another
facet of the problem is that concat's args are of the form [x y & zs].

Gary Fredericks recognizes this problem in the comments for CLJ-1218: "I
realized that concat could actually be made lazier without changing its
semantics, if it had a single [& args] clause that was then implemented
similarly to join above."

But for the most part, the comments are focused on fixing mapcat by
implementing a new function, join, rather than fixing the problem with
concat directly.  Seems better to fix concat, if possible.

I'm truly astonished I haven't gotten bitten by this before.  This is a
pattern I use frequently in my code; I guess I just never had deep enough
recursion for it to slow things down enough for me to realize what was
happening.



On Wed, Jul 18, 2018 at 12:53 AM, Nicola Mometto 
wrote:

> This behaviour is known and there are a couple of tickets about it :
>
> https://dev.clojure.org/jira/browse/CLJ-1583
> https://dev.clojure.org/jira/browse/CLJ-1218
>
> On Wed, 18 Jul 2018, 08:28 Mark Engelberg, 
> wrote:
>
>> I'm kind of surprised I haven't run across this before, but tonight I was
>> debugging a function that was doing an explosion of computation to return
>> the first value of a lazy sequence, and I was able to reduce the problem
>> down to this example:
>>
>> > (first (apply concat (map #(do (println %) [%]) (list 1 2 3 4 5
>> 1
>> 2
>> 3
>> 4
>> 1
>>
>> The last 1 is the return value, but notice that it realized 4 values in
>> order to return the 1.  This has nothing to do with chunked sequences, by
>> the way -- a list is an unchunked sequence.  It appears to be that the way
>> concat is written, it realizes the first two elements, and then another two
>> elements in a recursive call before the lazy-seq kicks in.
>>
>> In the function in question, the "apply concat" was part of a recursion,
>> causing that explosion of realizing values (four at each level of the
>> recursion, it would seem) to get at the first element.
>>
>> Note that this affects mapcat as well, which relies on concat under the
>> hood:
>> > (first (mapcat #(do (println %) [%]) (list 1 2 3 4 5)))
>> 1
>> 2
>> 3
>> 4
>> 1
>>
>> I don't see a quick fix other than writing my own improved
>> concat/mapcat.  Do you?
>>
>> --
>> 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.

concat and mapcat not sufficiently lazy

[Mark Engelberg]

I'm kind of surprised I haven't run across this before, but tonight I was
debugging a function that was doing an explosion of computation to return
the first value of a lazy sequence, and I was able to reduce the problem
down to this example:

> (first (apply concat (map #(do (println %) [%]) (list 1 2 3 4 5
1
2
3
4
1

The last 1 is the return value, but notice that it realized 4 values in
order to return the 1.  This has nothing to do with chunked sequences, by
the way -- a list is an unchunked sequence.  It appears to be that the way
concat is written, it realizes the first two elements, and then another two
elements in a recursive call before the lazy-seq kicks in.

In the function in question, the "apply concat" was part of a recursion,
causing that explosion of realizing values (four at each level of the
recursion, it would seem) to get at the first element.

Note that this affects mapcat as well, which relies on concat under the
hood:
> (first (mapcat #(do (println %) [%]) (list 1 2 3 4 5)))
1
2
3
4
1

I don't see a quick fix other than writing my own improved concat/mapcat.
Do you?

-- 
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.data.priority-map 0.0.10

[Mark Engelberg]

clojure.data.priority-map is a data structure that maintains a map that is
sorted by its values, rather than its keys. This allows it to be used as a
versatile priority queue.

The latest version contains two changes:
1. Aligned the hash value of priority maps to match the way that the hash
value of plain maps changed in Clojure 1.6.  (Thanks to Andy Fingerhut for
the patch).
2. Added a priority->set-of-items function to access priority map's
internal sorted map from each priority to the set of items with that
priority.

https://github.com/clojure/data.priority-map

-- 
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: Protocols considered harmful?

[Mark Engelberg]

There are two schools of thought:
1. Multimethods are the most versatile and work better at the REPL.  Use
protocols only where necessary for performance (and doing so early is
premature optimization).
2. Protocols are the most performant and handle the most common
polymorphism need - single dispatch based on type.  So use protocols unless
you are doing something that can't be done with protocols.

I tend to agree with your coworkers and fall into camp 1, but we are
probably a minority.  Either philosophy is ok if you're working on your
own, but at work you probably need to standardize on whatever the more
experienced coworkers prefer.

On Mon, May 21, 2018 at 10:25 PM, Sam Bartolucci 
wrote:

> Hi,
>
> I've been an enthusiastic Clojure tinkerer for a few years now--it's a
> great language!--but only recently began using it professionally, where
> I've stumbled into a strong disagreement over the use of protocols vs.
> multimethods for single dispatch polymorphism. I had always assumed that
> protocols were a normal part of Clojure when polymorphism was called for,
> but a few of my coworkers (often, it seems, those who have experience with
> Lisp prior to Clojure) swear up and down that protocols are only to be used
> as a last resort because they "break the REPL". Apparently they're frowned
> upon because, due to the JVM interop, they don't reload as well as other
> constructs. It has even been suggested a few times that all uses of
> protocols should be refactored to use a multimethod with a "type" as the
> dispatch function. Protocols, in other words, should be considered harmful.
> This seems strange to me considering how many successful and mainstream
> Clojure projects use protocols, but maybe I am missing something, so I
> thought I would ask the list. So what is it? Is there any consensus around
> the assertion that "good, idiomatic Clojure will use multimethods rather
> than protocols for single-dispatch polymorphism"?
>
> Thanks,
> Sam
>
> --
> 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: Clojure Games

[Mark Engelberg]

On Thu, Apr 26, 2018 at 8:15 AM, Kris Leech  wrote:

> Puzzler, do you have source online?
>

Sorry, no.  That project is closed source.

-- 
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: Clojure Games

[Mark Engelberg]

I created this game for last year's Hour of Code, using Clojurescript and
Phaser:
http://robot-repair.thinkfun.com/

On Wed, Apr 25, 2018 at 6:17 AM, Gerard Klijs  wrote:

> I worked on a snake game, where there is a function form one state to the
> next. You can play other client site, which can get slow on slow devices,
> or server-side, I also added some simple rule-based ai,
> https://github.com/gklijs/snake I continued working for a bit on it in a
> corparate repo, so don't really know what the status of the github stuff is.
> I might sync it with the other one, and try to use wasm for updating the
> state from rust and/or kotlin.
>
> Op woensdag 25 april 2018 13:16:54 UTC+2 schreef Kris Leech:
>
>> I'm currently working on a multi player game, when I have time. The
>> backend in Clojure, the frontend in Javascript (as in a HTML browser based
>> UI). So far it has been a really fun project and a great learning
>> experience.
>>
>> All communication is over web sockets (using http-kit). I send events
>> (which have a type key) as JSON between clients and server. I use `case` to
>> run a event handler function based on the type key of the event. I intend
>> to change this to use a multimethod instead.
>>
>> I'm storing state in atoms (but I'm going to switch to agents as they are
>> async).
>>
>> The first game is "tag", any number of players can join a game and one is
>> "it", they need to "tag" someone else and they become "it".
>>
>> The UI is using HTML div and CSS absolute positioning to move the
>> players. The idea being I will switch to using canvas once working and then
>> something like phaser.js. The idea being switching rendering from DOM to
>> Canvas should only require adding new JS functions.
>>
>> As you can see I'm starting with the simplest possible game.
>>
>>
>> On Monday, 16 April 2018 13:00:21 UTC+1, Peter Ashford wrote:
>>>
>>> Hi There - Clojure noob here. I wanted to ask some question about games
>>> programming in Clojure.  Is it ok to ask here or is there a better spot?
>>> Most of my questions aren't super game-specific.
>>>
>>> --
> 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.data.priority-map 0.0.8

[Mark Engelberg]

I just deployed version 0.0.9, which adds a more efficient implementation
of reduce-kv.

-- 
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] Ubergraph 0.5.0

[Mark Engelberg]

 https://github.com/Engelberg/ubergraph

Ubergraph is a batteries-loaded, immutable graph data structure for Clojure.

Version 0.5.0 updates ubergraph to match the latest protocol changes in
Loom 1.0.0 and above.

Ubergraph has now been in use for over three years, and has no open bug
reports in github.

Given that Loom is Clojure's other main graph library, many people are
interested in how Ubergraph and Loom compare.

Broadly speaking, Ubergraph is a superset of Loom that fulfills Loom's
protocols offering several features and algorithms beyond what Loom
supports:

* Multigraphs and multidigraphs with parallel edges, i.e., multiple edges
between the same pair of nodes in the same direction.
* Multiple weights per edge (as opposed to one "privileged" weight
attribute).
* Weights that are modifiable after initialization (in the immutable sense
of producing a new graph structure with modified weights).
* Mixtures of directed and undirected edges in the same graph.
* The ability to distinguish between an undirected edge and an opposing
pair of directed edges.
* The ability to traverse all a graph's edges while guaranteeing that
undirected edges are visited only once.

Because Ubergraph implements Loom protocols, Ubergraph can typically be
used as a drop-in replacement for Loom graphs.  For the most part, Loom's
graph algorithms work on ubergraphs, and Ubergraph's graph algorithms work
on loom graphs.  There are some exceptions to this, because in some cases,
the implementation of Loom's algorithms were not carefully implemented to
rely only on Loom's protocol abstractions, but were hard-coded to specific
aspects of Loom's concrete implementation.  And since Loom wasn't written
with multigraphs in mind, some of Loom's algorithms don't work properly on
multigraphs.

Ubergraph's algorithm namespace contains a curated collection of algorithms
from Loom known to work properly on ubergraph's more general data
structure, improved versions of several critical algorithms from Loom, and
reimplementations of several key algorithms from Loom known to be broken on
multigraphs.

-- 
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.data.priority-map 0.0.8

[Mark Engelberg]

https://github.com/clojure/data.priority-map

clojure.data.priority-map is a map-like data structure that sorts by
value.  It is useful in many situations where you might ordinarily use a
priority queue.

NEW for version 0.0.8 is support for subseq and rsubseq.

I had always intended to support subseq and rsubseq for priority-map.
Clojure theoretically supports extending subseq and rsubseq to new
collections by implementing the methods of clojure.lang.Sorted.  However,
when I first tried to do this, I discovered that there were some
assumptions baked into the clojure.core implementations of subseq and
rsubseq that made it impossible to extend support to priority-map.
Specifically, the clojure.core implementations of subseq and rsubseq assume
that there will never be more than one item tied for a given priority.  But
supporting tied priorities is a key value proposition of priority-map!

So, in 2010, I filed a JIRA issue and created a patch so that subseq and
rsubseq would work with priority-maps and other novel sorted data
structures.
https://dev.clojure.org/jira/browse/CLJ-428

Eight years later, I've decided not to wait any longer for this patch to be
incorporated into core.

As a workaround, the clojure.data.priority-map namespace now contains its
own patched version of subseq and rsubseq.  These can be used as a drop-in
replacement for the implementations found in core, so if you use the subseq
and rsubseq found in clojure.data.priority-map, they will work on
priority-maps as well as Clojure's other sorted collections.

I hope you enjoy the new functionality and find it useful!

--Mark Engelberg

-- 
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] Instaparse 1.4.9

[Mark Engelberg]

 Instaparse is a library for generating parsers from context-free grammars.
https://github.com/engelberg/instaparse

This new release includes contributions from github users dundalek (bugfix
for regexp flags in Clojurescript), HausnerR (improved handling of rhizome
dependency which more gracefully handles differences in availability at
compile time and run time), and aengelberg (new optional flags to change
case sensitivity of abnf and ebnf grammars).

Thanks to the contributors.

-- 
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: numeric-tower versus clojure 1.9

[Mark Engelberg]

You seem to be requiring the numeric-tower functions into the foobar.core
namespace, and then "use"ing the foobar.core namespace from the user
namespace and expecting the numeric-tower functions to show up in the user
namespace.  However, namespaces aren't transitive like that.  You need to
require math.numeric-tower from user if you intend to use it from user, or
change your namespace to foobar.core in the REPL.

A further problem (based on your github issue) may be that your foobar.core
namespace is in a file called src.clj (and you don't say what directory
that file is in).  Usually, the system will expect foobar.core namespace to
be in a file called core.clj in a directory called foobar.


On Fri, Jan 19, 2018 at 1:55 PM, Andrew Dabrowski 
wrote:

> Maybe it isn't a cider problem, I'm having a similar issue with lein.
> Working in the project directory created by lein:
>
> $ lein repl
> nREPL server started on port 42585 on host 127.0.0.1 - nrepl://
> 127.0.0.1:42585
> REPL-y 0.3.7, nREPL 0.2.12
> Clojure 1.9.0
> OpenJDK 64-Bit Server VM 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12
> Docs: (doc function-name-here)
>   (find-doc "part-of-name-here")
>   Source: (source function-name-here)
>  Javadoc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
>  Results: Stored in vars *1, *2, *3, an exception in *e
>
> user=> (use 'foobar.core)
> nil
> user=> (math/expt 2 3)
>
> CompilerException java.lang.RuntimeException: No such namespace: math,
> compiling:(/tmp/form-init2355284152590406554.clj:1:1)
> user=>
>
>
> It seems that the lein repl also is not processing the
>
>  (:require [clojure.math.numeric-tower :as math])
>
> line in project.clj.
>
> On the other hand:
>
> user=> (require 'clojure.math.numeric-tower)
> nil
> user=> (clojure.math.numeric-tower/expt 2 3)
> 8
>
>
> On Friday, January 19, 2018 at 12:10:59 PM UTC-5, Sean Corfield wrote:
>>
>> Can’t reproduce in Boot either. Based on that CIDER ticket, it may be
>> something specific to Andrew’s project.clj file…
>>
>>
>>
>> (! 910)-> boot -d org.clojure/math.numeric-tower repl
>>
>> Retrieving maven-metadata.xml from https://repo1.maven.org/maven2/ (1k)
>>
>> Retrieving math.numeric-tower-0.0.4.pom from
>> https://repo1.maven.org/maven2/ (1k)
>>
>> Retrieving math.numeric-tower-0.0.4.jar from
>> https://repo1.maven.org/maven2/ (5k)
>>
>> …
>>
>> boot.user=> (clojure-version)
>>
>> "1.9.0"
>>
>> boot.user=> (require '[clojure.math.numeric-tower :as math])
>>
>> nil
>>
>> boot.user=>
>>
>>
>>
>> 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:* clo...@googlegroups.com  on behalf of
>> Alex Miller 
>> *Sent:* Friday, January 19, 2018 6:04:42 AM
>> *To:* Clojure
>> *Subject:* Re: numeric-tower versus clojure 1.9
>>
>> I can't reproduce this problem in either a lein repl or clj repl using
>> math.numeric-tower + clojure 1.9. Looking at the code, I don't see anything
>> that should be different with Clojure 1.9.
>>
>> On Friday, January 19, 2018 at 7:38:57 AM UTC-6, Bozhidar Batsov wrote:
>>>
>>> I also got a CIDER ticket about pretty much the same problem
>>> https://github.com/clojure-emacs/cider/issues/2169
>>>
>>> I guess there's some problem with Clojure 1.9 and the tower, but I'm not
>>> sure about its exact extent.
>>>
>>> On 18 January 2018 at 02:41, Alex Miller  wrote:
>>>
 I can't reproduce that locally. Checking with the new clojure 1.9 clj
 tool:

 $ echo '{:deps {org.clojure/math.numeric-tower {:mvn/version
 "0.0.4"}}}' > deps.edn
 $ clj
 Clojure 1.9.0
 user=> (require '[clojure.math.numeric-tower :as n])
 nil
 user=> (dir n)
 MathFunctions
 abs
 ceil
 ...


 On Wednesday, January 17, 2018 at 4:26:44 PM UTC-6, Andrew Dabrowski
 wrote:
>
> Is clojure.math.numeric-tower incompatible with clojure 1.9?  The
> numeric tower is still at version 0.0.4, 4 years old.  WHen I try to use I
> get the error
>
> 1. Caused by java.io.FileNotFoundException
>Could not locate clojure/math/numeric_tower__init.class or
>clojure/math/numeric_tower.clj on classpath. Please check that
>namespaces with dashes use underscores in the Clojure file name.
>
> In particular math.numeric-tower does not seem to obey the
> dash->underscore convention, nor does the installation seem to include
> init.class or .clj files.
>
 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@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+u...@googlegroups.com
 For more options, visit this group at

Re: numeric-tower versus clojure 1.9

[Mark Engelberg]

It does use the underscore naming convention:
https://github.com/clojure/math.numeric-tower/tree/master/src/main/clojure/clojure/math

So I suspect there's something strange about your classpath or the
dependencies haven't been downloaded, or something along those lines.

On Wed, Jan 17, 2018 at 2:54 PM, Andrew Dabrowski 
wrote:

> Yes.
>
> On Wednesday, January 17, 2018 at 5:44:18 PM UTC-5, puzzler wrote:
>>
>> Did you put
>>
>> [org.clojure/math.numeric-tower "0.0.4"]
>>
>> in your leiningen project.clj file?
>>
>>
>> On Wed, Jan 17, 2018 at 2:26 PM, Andrew Dabrowski 
>> wrote:
>>
>>> Is clojure.math.numeric-tower incompatible with clojure 1.9?  The
>>> numeric tower is still at version 0.0.4, 4 years old.  WHen I try to use I
>>> get the error
>>>
>>> 1. Caused by java.io.FileNotFoundException
>>>Could not locate clojure/math/numeric_tower__init.class or
>>>clojure/math/numeric_tower.clj on classpath. Please check that
>>>namespaces with dashes use underscores in the Clojure file name.
>>>
>>> In particular math.numeric-tower does not seem to obey the
>>> dash->underscore convention, nor does the installation seem to include
>>> init.class or .clj files.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@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: numeric-tower versus clojure 1.9

[Mark Engelberg]

Did you put

[org.clojure/math.numeric-tower "0.0.4"]

in your leiningen project.clj file?


On Wed, Jan 17, 2018 at 2:26 PM, Andrew Dabrowski 
wrote:

> Is clojure.math.numeric-tower incompatible with clojure 1.9?  The numeric
> tower is still at version 0.0.4, 4 years old.  WHen I try to use I get the
> error
>
> 1. Caused by java.io.FileNotFoundException
>Could not locate clojure/math/numeric_tower__init.class or
>clojure/math/numeric_tower.clj on classpath. Please check that
>namespaces with dashes use underscores in the Clojure file name.
>
> In particular math.numeric-tower does not seem to obey the
> dash->underscore convention, nor does the installation seem to include
> init.class or .clj files.
>
> --
> 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] Specter 1.0.5

[Mark Engelberg]

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/d/optout.

Re: [ANN] Specter 1.0.4

[Mark Engelberg]

Thank you Nathan!

On Tue, Oct 17, 2017 at 10:31 AM, Hari Krishnan 
wrote:

> Thanks for the update.  It is a great library.  Thanks for sharing..I will
> update my project.
>
>
> On Tuesday, October 17, 2017 at 9:26:32 AM UTC-7, Nathan Marz wrote:
>>
>> Specter fills in the holes in Clojure's API for manipulating immutable
>> data, allowing data manipulation to be done concisely and with near-optimal
>> performance.
>>
>> Specter 1.0.4 has minor changes. The biggest highlight since the last
>> release is the greatly improved documentation courtesy of contributions by
>> Michael Fogleman. The following wiki pages are either new or significantly
>> fleshed out:
>>
>> https://github.com/nathanmarz/specter/wiki/Using-Specter-Recursively
>> https://github.com/nathanmarz/specter/wiki/List-of-Navigators
>> https://github.com/nathanmarz/specter/wiki/List-of-Macros
>> https://github.com/nathanmarz/specter/wiki/Using-Specter-With-Zippers
>>
>> Project link: https://github.com/nathanmarz/specter
>> Changelog: https://github.com/nathanmarz/specter/blob/master/CHANGES.md
>>
> --
> 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: [core.spec] Stricter map validations?

[Mark Engelberg]

On Tue, Oct 3, 2017 at 2:55 AM, Peter Hull  wrote:

> On puzzler's database example, I would have thought that restricting the
> keys that go into the DB should not be the job of spec (since functions may
> not be instrumented anyway), but the job of the 'core logic'. Maybe I am
> misunderstanding though.
>


Even when functions are not instrumented, one powerful use of spec is to
call valid? or conform from within your code to test data against specs as
part of the function's logic.  One of the value propositions of spec is
that it handles a whole range of use cases.  You define your spec once, and
one of the many things you can do with it is to use it as part of your
validation logic.

-- 
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: [core.spec] Stricter map validations?

[Mark Engelberg]

Yesterday, I was checking a map of info submitted via web before putting
its contents into a database.  To prevent people from spamming the
database, it's necessary to make sure there aren't additional keys thrown
into the map.  It would be nice to have a *convenient *way to express this
in spec, to make it easier to use for these validation purposes in addition
to its routine use as specifying a minimal contract on function inputs.

On Mon, Oct 2, 2017 at 10:13 PM, Didier  wrote:

>  | we have experienced on virtually every consulting project we'd done
> including spec at Cognitect
>
> I'm sure this is sometimes true, but I can't think of how that would
> happen. Could you detail it a little?
>
> For me, whenever I needed to add more keys, it was simple to evolve the
> spec with the function, why would you leave the spec behind?
>
> --
> 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: Help ship Clojure 1.9!

[Mark Engelberg]

On Mon, Oct 2, 2017 at 7:55 AM, Stuart Halloway 
wrote:

> Hi David,
>
> Spec will be in alpha for a while. That is part of the point of it being a
> separate library. Can you say more about what problems this is causing?
>
> Stu
>
>
As a library maintainer, I am forced to upgrade and release my library any
time something I depend upon makes a breaking change.  I don't get paid for
maintaining open source libraries, it's something I do in my spare time, so
I prefer to do it on my own schedule.  When an underlying library makes a
breaking change, I get dozens of urgent requests from people who need me to
cut a new release ASAP, and by Murphy's Law, that often happens when I have
very little time to do it.  It's a nuisance.

Clojure is pretty good about not making breaking changes, but it happens
from time to time.  Clojurescript is less good about not making breaking
changes, and therefore, maintaining Clojurescript libraries is more of a
headache.  On the plus side, Clojurescript users seem to care very little
about backwards compatibility (most keep up with the latest version), so
sometimes it is easier to make a change to keep up with a change in
Clojurescript than one in Clojure, where I am expected to not only support
the latest breaking change, but also the last several releases.

Anything that is labeled as "alpha" is waving a big red flag that there
could be breaking changes at any time with little warning.  For my
libraries which depend on spec, there's no way I'm going to bring them out
of alpha status until spec comes out of alpha status.  If I make an
official release of something that depends on spec, then I'm going to be on
the hook to rapidly cut a new release every time spec changes, which could
be at any time.  I don't want that hassle.  I don't want to make a promise
to the community to maintain a stable product if the thing I depend upon
has not made a similar promise.  When spec reaches a point where the API
will not be changing, or rather, when we know that new changes will only be
additive, I can begin to trust that it won't be a huge maintenance headache
to release something based on spec.

-- 
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: Help ship Clojure 1.9!

[Mark Engelberg]

And to be clear, it doesn't only affect people who try to use ##Inf or
##NaN in their Clojurescript code.  It affects all existing Clojurescript
code, because running the Clojurescript compiler in a new version of
Clojure causes all Clojurescript code to emit these ## characters directly
into the javascript for its definition of the core hash function, which is
nonsensical javascript.  So all Clojurescript code is broken by running the
new release.

On Thu, Sep 28, 2017 at 11:34 AM, Mark Engelberg 
wrote:

> On Thu, Sep 28, 2017 at 11:02 AM, Jeaye  wrote:
>
>> This has been the only issue we've run into with 1.9.0-beta1 ( ticket is
>> here https://dev.clojure.org/jira/browse/CLJS-2352 ). On our back-end,
>> all tests are good, but we can't currently use beta1 (or alpha20) on the
>> front-end, since this issue causes CLJS to choke. I'm hoping that a new
>> version of CLJS comes out before Clojure 1.9.0 so that people don't get the
>> false impression that the latest of each is compatible with the other.
>>
>> J
>>
>>
> Agreed.  It is currently not possible to use Clojure 1.9.0 later than
> alpha19 with Clojurescript.  Clojurescript as it currently stands can't
> handle the new ## tags like ##Inf, ##NaN.  Like a number of people, I got
> burned by this when I tried to upgrade and spent some time tracking it
> down, only to realize it was already a known incompatibility.  There will
> be a lot more confused people if you release Clojure 1.9.0 prior to
> releasing a new version of Clojurescript that is compatible.
>

-- 
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: Help ship Clojure 1.9!

[Mark Engelberg]

On Thu, Sep 28, 2017 at 11:02 AM, Jeaye  wrote:

> This has been the only issue we've run into with 1.9.0-beta1 ( ticket is
> here https://dev.clojure.org/jira/browse/CLJS-2352 ). On our back-end,
> all tests are good, but we can't currently use beta1 (or alpha20) on the
> front-end, since this issue causes CLJS to choke. I'm hoping that a new
> version of CLJS comes out before Clojure 1.9.0 so that people don't get the
> false impression that the latest of each is compatible with the other.
>
> J
>
>
Agreed.  It is currently not possible to use Clojure 1.9.0 later than
alpha19 with Clojurescript.  Clojurescript as it currently stands can't
handle the new ## tags like ##Inf, ##NaN.  Like a number of people, I got
burned by this when I tried to upgrade and spent some time tracking it
down, only to realize it was already a known incompatibility.  There will
be a lot more confused people if you release Clojure 1.9.0 prior to
releasing a new version of Clojurescript that is compatible.

-- 
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] Instaparse 1.4.8

[Mark Engelberg]

Instaparse 1.4.8 has been updated to support a breaking change that was
made in Clojurescript 1.9.854, relating to the reader.  The change has been
tested with Clojurescript versions 1.7.28 and up.

No functionality changes, and this update should not matter for Clojure
users.
Instaparse supports Clojure 1.5.1 and up.

Thanks to pkpkpk for providing the pull request with the necessary fix:
https://github.com/Engelberg/instaparse/pull/169

(Please note that Clojurescript does not currently work with Clojure
1.9-alpha20 or newer: https://dev.clojure.org/jira/browse/CLJS-2352)

--Mark

-- 
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: Starting Clojure again

[Mark Engelberg]

You could do that by calling vec on it.  But you'd want to move the whole
let clause outside of the defn, so it is only evaluated once, not every
time the function is called.

But best, as I said earlier, is just to let chars be "0123456789ABCDEF".
You can call nth on strings, so this is the most efficient way to do a
fixed sequence of specific characters.

On Wed, Sep 6, 2017 at 1:13 AM, Cecil Westerhof 
wrote:

> Answering my own question. ;-)
>
> 2017-09-06 9:58 GMT+02:00 Cecil Westerhof :
>
>> The next step is that I want to use hexadecimal numbers. So I should use
>> (range (int \0) (inc (int \9))) combined with (range (int \A) (inc (int
>> \F))).
>> How would I do that?
>>
>
> ​(concat (range (int \0) (inc (int \9))) (range (int \A) (inc (int
> \F
> ​
>
> ​By the way. I am using a lazy sequence here. Could it be updated with
> using a vector when creating very long strings, or is that not a
> significant performance increase?​
>
> --
> Cecil Westerhof
>
> --
> 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: Starting Clojure again

[Mark Engelberg]

(let [chars "0123456789ABCDEF"] ...)

Replace `reduce` with `apply` to get the performance benefit of using a
string builder behind the scenes.

On Wed, Sep 6, 2017 at 12:58 AM, Cecil Westerhof 
wrote:

> I want to start using Clojure again. I made the following simple function
> to generate a PIN:
> (defn create-pin
>   ([] (create-pin 8))
>   ([n]
>(let [chars (map char (range (int \0) (inc (int \9]
> (reduce str (repeatedly n #(rand-nth chars))
>
> So far so good. But I want to improve a little.
>
> I think n should at least be four, but not greater as 16. What is the
> Clojure way to do this?
>
> The next step is that I want to use hexadecimal numbers. So I should use
> (range (int \0) (inc (int \9))) combined with (range (int \A) (inc (int
> \F))).
> How would I do that?
>
> Is there anything I should do differently?
>
> Of-course I make a general function that is then called from create-pin
> and create-pin-hex.
>
> --
> Cecil Westerhof
>
> --
> 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: SRSLY? (= (true? identity) (false? identity)) => true

[Mark Engelberg]

(true? identity) -> false
(false? identity) -> false
(= false false) -> true

On Fri, Sep 1, 2017 at 8:43 PM, Rostislav Svoboda <
rostislav.svob...@gmail.com> wrote:

> Hi, can anybody explain it please?
>
> $ java -cp clojure-1.8.0.jar clojure.main
> Clojure 1.8.0
> user=> (= (true? identity) (false? identity))
> true
>
> And in 1.9.0-alpha19 it behaves the same.
>
> thx Bost
>
> --
> 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: Sum types in Clojure? Better to represent as tagged records or as variant vectors?

[Mark Engelberg]

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.

Vote for Clojure support in Natural Docs

[Mark Engelberg]

Back in the day, I used to use Natural Docs to build great docs for my
projects.  There's a new version out, and the author of the project is
asking people about what languages to support.  I encourage you to upvote
the Clojure suggestion:
https://www.reddit.com/r/NaturalDocs/comments/6trhdo/which_languages_do_you_want_to_see_supported_in_21/

-- 
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] Ubergraph 0.4.0

[Mark Engelberg]

https://github.com/Engelberg/ubergraph

Ubergraph is a batteries-loaded, immutable graph data structure for Clojure.

Version 0.4.0 includes improved support for serialization/deserialization
of ubergraphs.
https://github.com/Engelberg/ubergraph#serialization

Ubergraph has now been in use for over two years, and has no open bug
reports in github.

Given that Loom is Clojure's other main graph library, many people are
interested in how Ubergraph and Loom compare.

Broadly speaking, Ubergraph is a superset of Loom that fulfills Loom's
protocols offering several features and algorithms beyond what Loom
supports:

* Multigraphs and multidigraphs with parallel edges, i.e., multiple edges
between the same pair of nodes in the same direction.
* Multiple weights per edge (as opposed to one "privileged" weight
attribute).
* Weights that are modifiable after initialization (in the immutable sense
of producing a new graph structure with modified weights).
* Mixtures of directed and undirected edges in the same graph.
* The ability to distinguish between an undirected edge and an opposing
pair of directed edges.
* The ability to traverse all a graph's edges while guaranteeing that
undirected edges are visited only once.

Because Ubergraph implements Loom protocols, Ubergraph can typically be
used as a drop-in replacement for Loom graphs.  For the most part, Loom's
graph algorithms work on ubergraphs, and Ubergraph's graph algorithms work
on loom graphs.  There are some exceptions to this, because in some cases,
the implementation of Loom's algorithms were not carefully implemented to
rely only on Loom's protocol abstractions, but were hard-coded to specific
aspects of Loom's concrete implementation.  And since Loom wasn't written
with multigraphs in mind, some of Loom's algorithms don't work properly on
multigraphs.

Ubergraph's algorithm namespace contains a curated collection of algorithms
from Loom known to work properly on ubergraph's more general data
structure, improved versions of several critical algorithms from Loom, and
reimplementations of several key algorithms from Loom known to be broken on
multigraphs.

-- 
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: Priority Map with efficient search on values?

[Mark Engelberg]

If you need to do subseq on the key space, you could do the following:
(def pm-empty (PersistentPriorityMap. (sorted-map) (sorted-map) {} nil))

This sets up the priority map to use sorted maps for both associating keys
to values and values to keys.

Use this as your base priority map to pour new key-value pairs into.  Then,
you can extract the underlying key-value sorted map with (.item->priority
pm) and call subseq on it to perform the subseq on keys.

Once you're using sorted maps for both the keys and values though, you
might want to look at the PSQ data structure you referred to which was
built with this kind of range searching on both keys and values as a
primary objective.

-- 
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: Priority Map with efficient search on values?

[Mark Engelberg]

On a priority map pm, (.priority->set-of-items pm) will return a sorted map
from priorities (i.e., the values in the priority-map) to sets of items
that have that priority (i.e., the keys in the priority-map).

With that sorted map you can look up specific priorities, or do various
subseq operations on it.

I've been waiting 7 years for the Clojure JIRA patch (
http://dev.clojure.org/jira/browse/CLJ-428) that will make it possible for
me to hook this behavior directly into Clojure's subseq when called on the
priority map.  Still waiting, so for now, you have to explicitly call
.priority->set-of-items on the priority map and work with that object.

--Mark


On Fri, Apr 7, 2017 at 8:49 PM, Brian Beckman  wrote:

> I have found a few data types in Clojure that support search and priority
> queues. In particular, I found
>
> Priority Maphttps://github.com/clojure/data.priority-map
> PSQhttps://goo.gl/Dw4gkV
> data.avlhttps://goo.gl/e07q7H
>
> I would be grateful for a few clarifying words on whether any of these can
> meet my requirements out-of-the-box before I begin a deep-dive. Forgive me
> for being a bit lazy (actually, just in a hurry), but I thought I'd check
> whether someone knows an answer for me off-the-cuff.
>
> I need collections of [k v] pairs supporting efficient peek, pop, get, and
> subseq-style search on either the key space or on the value space. I need
> all operations on just one of the two spaces.
>
> Priority map supports efficient peek and pop of the value space on its API
> surface, but I don't see a get subseq (or rsubseq) or other way to quickly
> search the value space on the API surface. The comments in the source
> suggest that there is an auxiliary inverse sorted map from values to keys.
> The supported "get" operation seems to operate on the key space, but I
> could use one on the value space (see line 313 of https://goo.gl/qhfXKL).
> Perhaps that inverse map easy to get at, in which case I'll be done.
>
> PSQ supports peek and pop on values, and efficient search on keys,
> according to its documentation. Do I read that correctly?
>
> I have not read the documentation for data.avl deeply enough to know
> whether it will do my job out-of-the box. But I am sure I could build what
> I need on top of AVL trees, RB trees, 2-3 trees, splay trees, etc. I'm just
> looking to save myself work (and use tested software).
>
> --
> 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 and RFC] Bifurcan: impure functional data strucures

[Mark Engelberg]

I do a lot of work with data structures, so this, I think, would be useful
to me.

For the immutable data structures, it seems like they could be done as a
drop-in replacement for the Clojure built-ins.  There are a couple new
functions for splitting and concatenating.  I'd recommend following
precedents set by core.rrb-vector when relevant.  Map linear/forked to
transient API.

For the mutable Linear data structures, my instinct would be to hook into
the transient functions when possible, even though it doesn't behave
exactly like transients.  Name new functions on the mutable collections
with a `!` character, but return the mutated collection as output (as
opposed to returning void), so you don't have to write functions over the
data as a "bang in place".

--Mark

-- 
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: Clojure resume tips?

[Mark Engelberg]

On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton  wrote:

>
> * So … if I was in your position, knowing what I know now, if I couldn't
> find companies that had very progressive hiring practices, I would make my
> resume stand out by leading in with an offer to spend a few hours writing a
> small implementation of anything the hiring manager would like me to write.
> Many hiring mangers are scared by take home projects because they're afraid
> of what the best candidate will think. "It's an insult to experienced
> candidates!" or "how would a rockstar candidate possibly spare the time?"
> But secretly I think all hiring mangers *really* want to know what it will
> be like to have you write code on their behalf. It's just not the industry
> norm to ask.
>

Insightful post about a lot of things related to hiring, but I have to take
exception with this very last point.  Recently, a friend of mine sought out
a data science position in the Seattle area.  Each prospective employer
gave him a take-home assignment that required 30-40 work hours to
complete.  Some of the assignments were real problems the company was
facing, so he was effectively being asked to do free consulting work for
each company.  This is a horrible, burdensome interview practice and it
would be dreadful if it became the norm in the software industry.
Suggesting that someone offer to do a take-home project may make sense in
specific cases for an inexperienced candidate, but I fear it starts our
industry down the slippery slope.

-- 
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: Combinatorics partitions that preserves adjacency?

[Mark Engelberg]

Think in terms of numbering the possible split locations:

a b c
 1 2

So the possible partitions are represented by [1], [2], [1 2], i.e., all
the non-empty subsets of [1 2].

So write a function that goes from this numbering scheme to partitions
(e.g., using subvec) and use combinatorics' subsets function.



On Wed, Mar 15, 2017 at 8:35 PM, Paul Gowder  wrote:

> Hi everyone,
>
> Does anyone know of a straightforward way to get something like
> clojure.math/combinatorics/partitions that works more like partition in
> the core library, that is, that only selects partitions with adjacent
> elements?
>
> In other words, right now this is the problem:
>
> (require '[clojure.math.combinatorics :as c])
> (c/partitions [:a :b :c] :min 2)
>
> => (([:a :b] [:c]) ([:a :c] [:b]) ([:a] [:b :c]) ([:a] [:b] [:c]))
>
> But that ([:a :c] [:b]) there in the second position isn't a proper
> partition because :a and :c aren't adjacent in the original vector.
>
> I feel like there's got to be a standard, canonical solution for this, or
> some existing sequence or combinatorics function with a funny name that
> just returns (([a :b] [:c]) ([:a] [:b :c]) ([:a] [:b] [:c])) in this
> situation.  I just don't know it...
>
> The best I can come up with is kind of a hackish workaround that only
> works when the original vector is sorted, namely, flattening all the
> partitions and testing to see whether they are sorted too, i.e.:
>
> (require '[clojure.math.combinatorics :as c])
>
> (defn test-fn [part]
>   (let [f (flatten part)]
> (= f (sort f
>
> (filter test-fn (c/partitions [:a :b :c] :min 2))
>
> => (([:a :b] [:c]) ([:a] [:b :c]) ([:a] [:b] [:c]))  ; Yay! :-)
>
> And that works, but, as noted, only when the original vector is sorted.
> What if someone wanted to preserve adjacencies in an unsorted vector?
>
> All thoughts appreciated, thanks!
>
> Cheers,
>
> -Paul
>
> --
> 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: Navigators and lenses

[Mark Engelberg]

On Mar 9, 2017 9:52 AM, "Brandon Bloom"  wrote:
>>
>
> Since you're responding to me specifically, I'd like to be clear that I
never made that claim. I only said we need more experimentation. This is a
sufficiently big enough area of ideas to warrant exploration of competing
approaches.

My comment wasn't intended as directed specifically at you.  Your list of
references was interesting and useful.  Thanks for posting 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: Navigators and lenses

[Mark Engelberg]

Just finished reading through Racket's lens library to compare.  Specter
can do everything that Racket's lens library can do, but the converse is
not true.  Specter's navigators can do more than lenses.

The lens-like navigators are the most obviously useful parts of Specter,
and maybe for some people that's all they need and they would prefer to
hide the other functionality.  If so, it looks to me like it would be
trivial to build a lens library like Racket's out of Specter, and it would
almost certainly be higher performance than the "obvious" implementation of
lenses.

But I don't agree at all with the claim that Specter is some sort of
offbeat, ill-researched version of lenses.  It is something more advanced.
If Nathan had constrained his thinking to these other approaches, Specter
wouldn't have such richness of functionality and pragmatic performance
considerations.


On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom 
wrote:

> Responsible adults sometimes needs to access and modify deeply nested data
>> structures
>
>
> So far, my experience has been that it is almost always better to build a
> pair of flattening and unflattening transforms on the data. Especially
> since you frequently want only one flattening, but potentially many
> un-flattenings. The "unflattened" form (aka "documents") is usually an
> end-point where data goes to die; assuming it isn't immediately displayed
> on the screen.
>
> However, having said that, path-dependent / context-sensitive query is a
> very rich and interesting space that does have meaningful utility,
> especially in the context of graph-like datasets. This is especially true
> when combined with some kind of algebra for unioning/intersecting/etc. I'm
> also interested in this sort of thing for programmable user-interface use
> cases: Think text editors with multiple-cursors.
>
> I think experimentation is in order
>>
>
> Agreed. Here's some starting points for pre-hammock reading/viewing
> materials:
>
> *Tree Traversal *
>
>- XPath: https://www.w3.org/TR/xpath/
>- CSS: https://www.w3.org/TR/css3-selectors/
>
> *Richer Tree Querying*
>
>- XQuery: https://www.w3.org/TR/xquery/
>- jQuery: https://api.jquery.com
>
> *Second-Class "Generalized References" (nee "L-values")*
>
>- Common Lisp: http://www.lispworks.com/documentation/lw50/CLHS/
>Body/05_a.htm
>- C/C++: http://eli.thegreenplace.net/2011/12/15/
>understanding-lvalues-and-rvalues-in-c-and-c
>
> 
>
> *Lenses in Other Languages*
>
>- Haskell: https://skillsmatter.com/skillscasts/4251-lenses-
>compositional-data-access-and-manipulation
>
> 
>(great overview of key concepts!)
>- Racket: https://docs.racket-lang.org/lens/index.html
>
> *Graph Querying*
>
>- Neo4j Cypher: https://neo4j.com/developer/cypher-query-language/
>- TinkerPop Gremlin: https://tinkerpop.apache.org/gremlin.html
>
> --
> 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: Release date for 1.9

[Mark Engelberg]

However, it does mean that libraries depending on 1.9 may be waiting to
release so as not to support a Clojure version that can make breaking
changes to the new features at any time.

On Mon, Mar 6, 2017 at 12:41 AM, Alexander Kiel 
wrote:

> We also run Clojure 1.9-alpha with great success in production. Being
> alpha doesn't mean that it's buggy. It just means that the new stuff can
> still change.
>
> Am Dienstag, 28. Februar 2017 21:10:59 UTC+1 schrieb Dan Burton:
>>
>> Obligatory: "our team uses clojure-future-spec with clojure-1.8" -- no
>> problems so far.
>>
>> -- Dan Burton
>>
>> On Tue, Feb 28, 2017 at 11:59 AM, Sean Corfield 
>> wrote:
>>
>>> On 2/28/17, 10:26 AM, "Erik Assum" >> of er...@assum.net> wrote:
>>> > And, yes, I'm aware of the fact that the 1.9-alphas are very stable
>>> wrt putting it in production.
>>>
>>> Obligatory: “we’ve been running the 1.9 Alphas in production for months
>>> so that we can leverage clojure.spec” – no problems so far.
>>>
>>> Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN
>>> World Singles -- http://worldsingles.com/
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@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: Contribute Specter to Clojure core?

[Mark Engelberg]

The first time I watched Nathan talk about Specter, I had the exact same
thoughts -- "My data structures aren't that complex, I can't relate to
these examples, I don't need Specter, I'm fine with Clojure's get-in,
update-in, assoc-in."

But then, I challenged myself for one day to use Specter's select,
transform, set-val with navigators as an alternative to Clojure's
built-ins, just to get a feel for how they worked.

Once the library was already required there at the top of my namespace, and
once I became accustomed to the navigators, suddenly, by the end of that
day I was seeing *all kinds of places* where I could use Specter in
non-obvious ways in my code to make it dramatically leaner and more elegant.

Note that this was code where I was getting along just fine without
Specter.  Yes, I could get along without it, but Specter made the code
better.  And, oh yeah, faster as well.

There seems to be a kind of thinking expressed here that Specter somehow
corrupts your programming style and makes you more likely to create
unnecessarily deep data structures.  But your data structures don't
actually have to be all that deep to derive benefit from Specter.  My data
structures weren't all that deep before Specter, and they aren't any deeper
now -- I just have richer tools to work with.

So take this as one data point:  my assessment of Specter before I actually
tried it turned out to be wrong, and its utility greatly exceeded my
expectations.  Try it for a day or two, and maybe you too will "see the
light".

--Mark






On Sat, Mar 4, 2017 at 1:22 AM, Erik Assum  wrote:

> My thoughts on this were spurred by this tweet from Nikita Prokopov
> https://twitter.com/nikitonsky/status/837049980053516310
>
> I generally don't have the need to alter stuff deep down in data
> structures, but when I do, I don't mind writing the functions to do so.
>
> The two things that worries me about Specter are
> 1) One more path-DSL to learn for both my team and I.
> 2) If Clojure were an OO-language, wouldn't I be violating the law of
> Demeter https://en.m.wikipedia.org/wiki/Law_of_Demeter when using specter?
>
> I realize that these are not arguments for or against Specter going into
> Clojure, more my thoughts on why I'm not using it.
>
> Erik.
> --
> i farta
>
> Den 16. feb. 2017 kl. 04.05 skrev Alex Miller :
>
>
> On Wednesday, February 15, 2017 at 3:41:36 PM UTC-6, Nathan Marz wrote:
>>
>> Alex – care to elaborate? When I get this question it would be nice to be
>> able to tell people why the core team isn't interested.
>>
>
> The default answer to all such questions is no. Clojure has a small
> library and Rich wants it to remain that way.
>
> --
> 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.

[ANN] Ubergraph 0.3.1

[Mark Engelberg]

https://github.com/Engelberg/ubergraph

Ubergraph is a batteries-loaded, immutable graph data structure for Clojure.

Version 0.3.1 includes a pull request from github user masztal that now
allows `viz-graph`, which is an ubergraph visualization tool using
graphviz, to pass along graph-level attributes to graphviz.

Ubergraph has now been in use for almost two years, and has no outstanding
github issues.

Given that Loom is Clojure's other main graph library, many people are
interested in how Ubergraph and Loom compare.

Broadly speaking, Ubergraph is a superset of Loom that fulfills Loom's
protocols offering several features and algorithms beyond what Loom
supports:

* Multigraphs and multidigraphs with parallel edges, i.e., multiple edges
between the same pair of nodes in the same direction.
* Multiple weights per edge (as opposed to one "privileged" weight
attribute).
* Weights that are modifiable after initialization (in the immutable sense
of producing a new graph structure with modified weights).
* Mixtures of directed and undirected edges in the same graph.
* The ability to distinguish between an undirected edge and an opposing
pair of directed edges.
* The ability to traverse all a graph's edges while guaranteeing that
undirected edges are visited only once.

Because Ubergraph implements Loom protocols, Ubergraph can typically be
used as a drop-in replacement for Loom graphs.  For the most part, Loom's
graph algorithms work on ubergraphs, and Ubergraph's graph algorithms work
on loom graphs.  There are some exceptions to this, because in some cases,
the implementation of Loom's algorithms were not carefully implemented to
rely only on Loom's protocol abstractions, but were hard-coded to specific
aspects of Loom's concrete implementation.  And since Loom wasn't written
with multigraphs in mind, some of Loom's algorithms don't work properly on
multigraphs.

Ubergraph's algorithm namespace contains a curated collection of algorithms
from Loom known to work properly on ubergraph's more general data
structure, improved versions of several critical algorithms from Loom, and
reimplementations of several key algorithms from Loom known to be broken on
multigraphs.

I encourage people from the Loom community to test all newly submitted
algorithms against Ubergraph's concrete implementation of Loom's protocols
as a way to ensure that the algorithm is properly written to Loom's
protocols, rather than leveraging concrete implementation details.  Also,
this will give you an opportunity to think through whether your algorithm
works properly with multigraphs.  (Relatedly, I welcome pull requests
identifying Loom algorithms which belong in Ubergraph's curated set of Loom
algorithms known to work well with ubergraphs, or multigraph-friendly
reimplementations of those that don't).

-- 
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: Contribute Specter to Clojure core?

[Mark Engelberg]

I like Specter and would love to have it readily available in any project,
so that aspect is appealing.  However, there are a handful of subtle ways
that Specter doesn't feel like it was designed by the same people who wrote
core.  For example, Clojure's built-in transformation functions on data
structures put the data structure first, so that they can be easily applied
to data structures sitting inside reference types.  For similar reasons of
convenience, Clojure's update-in can take extra parameters for the
transformation function.  Specter puts the navigator first and transform
doesn't take optional additional args to pass to the transformation
function.

So I think these subtle differences might cause confusion if it were in
core.  Newcomers already struggle with the fact that sequence
transformation functions (map, take, reduce) are an exception to the rule
that data structures tend to come first.

-- 
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: making a tree from map

[Mark Engelberg]

Depending on your needs, you may instead want to consider converting your
data to a graph data structure, rather than a tree.  The benefits are that
it will deal properly with cycles, multiple components, or diverging and
re-converging paths.  Then in graph form you will be able to run a large
library of graph algorithms on it to find shortest paths between nodes, etc.

https://github.com/Engelberg/ubergraph is one way to build a graph in
Clojure.  The example input you gave is known as an adjacency map, and is
one of the kinds of inputs accepted by the constructor.

So, for example, you can simply do (uber/digraph answer24).


On Mon, Jan 30, 2017 at 5:46 AM, Robert Aaron Zawiasa 
wrote:

> I got a perfect answer from @moxaj on Clojurians Slack:
> https://clojurians.slack.com/files/moxaj/F3Y6J1X0S/-.clj
>
> --
> 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.

[ANN] cloure.math.combinatorics 0.1.4 (with clojurescript support)

[Mark Engelberg]

https://github.com/clojure/math.combinatorics

clojure.math.combinatorics is a Clojure contrib library for generating
permutations, combinations, subsets, selections, and partitions of
collections.

The new release uses cljc files to provide cross-platform support for
Clojure 1.7 and up, and has been tested with the latest stable release of
Clojurescript.

If you are still using Clojure 1.2 - 1.6, you'll need to stick with
combinatorics version 0.1.3.

Thanks to Alex Miller for upgrading the contrib infrastructure to support
cljc builds.

-- 
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: Literal map keys are checked for duplication before evaluation?

[Mark Engelberg]

Another workaround:
(array-map (java.util.UUID/randomUUID) 1 (java.util.UUID/randomUUID) 2)

On Wed, Jan 4, 2017 at 9:16 PM, Timothy Baldridge 
wrote:

> The check is made at read-time, by the time to form gets to the compiler
> it's already a hash-map and one of your forms will have been dropped. So
> the decision was made to make the reader check. One way you could solve
> your problem here is with tagged literals, as the literal would be created,
> and therefore the UUID would be unique before you even got to the creation
> of the hash-map.
>
> http://clojure.org/reference/reader#_tagged_literals
>
> In short though...what should the reader do, it has no clue which of your
> two key/value pairs to drop.
>
> On Wed, Jan 4, 2017 at 9:05 PM, Tianxiang Xiong  > wrote:
>
>> Using a Clojure 1.8.0 REPL, I get the following:
>>
>> user=> {(+ 1 2) 1 (+ 1 2) 2}
>> IllegalArgumentException Duplicate key: (+ 1 2)  clojure.lang.
>> PersistentArrayMap.createWithCheck (PersistentArrayMap.java:71)
>>
>> It seems that the a check for key equality is made *before* the key is
>> evaluated, when they are still strings.
>>
>> PersistentArrayMap/createWithCheck is as below:
>>
>> static public PersistentArrayMap createWithCheck(Object[] init){
>> for(int i=0;i< init.length;i += 2)
>> {
>> for(int j=i+2;j> {
>> if(equalKey(init[i],init[j]))
>> throw new IllegalArgumentException("Duplicate key: " + init[i]);
>> }
>> }
>> return new PersistentArrayMap(init);
>> }
>>
>> The MapReader in LispReader.java seems to pass an Object[] of Strings to
>> PersistentArrayMap/createWithCheck.
>>
>> public static class MapReader extends AFn{
>> public Object invoke(Object reader, Object leftparen, Object opts, Object
>> pendingForms) {
>> PushbackReader r = (PushbackReader) reader;
>> Object[] a = readDelimitedList('}', r, true, opts,
>> ensurePending(pendingForms)).toArray();
>> if((a.length & 1) == 1)
>> throw Util.runtimeException("Map literal must contain an even number of
>> forms");
>> return RT.map(a);
>> }
>>
>> }
>>
>>
>> This behavior is surprising. Is there a reason the map creation process
>> works this way?
>>
>> The above example may seem trivial, since we would have duplicate keys
>> after evaluation as well, but consider the generation of random values:
>>
>> user=> {(java.util.UUID/randomUUID) 1 (java.util.UUID/randomUUID) 2}
>> IllegalArgumentException Duplicate key: (java.util.UUID/randomUUID)
>>  clojure.lang.PersistentArrayMap.createWithCheck
>> (PersistentArrayMap.java:71)
>>
>>
>> --
>> 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.
>

-- 
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: Cyclic namespace dependencies!

[Mark Engelberg]

On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge 
wrote:

> I can see that, and even spec has this use case. In Spec it's solved by
> having both A and B in one namespace and using declare to forward-declare
> the constructors (or defns in this case).
>
> So I guess the way I see it the tradeoff is a declare and
> all-in-one-namespace vs a massive complexity addition to the compiler and
> the redefinition of compilation units. The declare method seems like the
> cleaner route.
>
>
I wonder whether there could be something like an `external-declare` that
would satisfy Rich's concerns about knowing how to intern unencountered
vars, while allowing cyclical references when needed.

-- 
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: Cyclic namespace dependencies!

[Mark Engelberg]

On Fri, Dec 30, 2016 at 4:38 PM, Timothy Baldridge 
wrote:

>
> So the layout looks like this:
>
> Interfaces.clj
>  |
> 
> |  |
> ImplementationA   Implementation B
> |  |
> 
>  |
> Orchestration (Setup) Namespace
>
>
>

The problem I've had with this is that Implementations A and B are
generally going to be records.  For best performance, you want to write the
implementation of a record's protocols directly inside of the record.  If
the implementation of A requires constructing a B, and implementing a B
requires constructing an A, you've got a problem because a record's
constructors aren't part of Interfaces.clj, but are part of the namespaces
in which the records are defined.

-- 
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: Cyclic namespace dependencies!

[Mark Engelberg]

I feel your pain.  I also run up against this time and time again and view
it as a significant limitation -- one which often forces me to contort the
structure of my Clojure programs into something less natural.  And as the
Clojure language grows, the problem becomes even more acute.

For example, consider specs.

One common recommendation is to put your specs in a separate, parallel
namespace.

However, implementing specs often requires domain-specific logic, i.e.,
functions from your main namespace.
And your main namespace often requires specs because the logic of your
functions may need the specs in order to conform some data as part of its
processing.

So what to do?  These kinds of things happen a lot in my experience, and a
solution would be incredibly valuable.

Best solution I've found is to hoist mutually dependent things into a
common namespace and use potemkin to clone them into a more logical
partitioning.  But that's never been very satisfactory to me.

-- 
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] Instaparse 1.4.5

[Mark Engelberg]

Instaparse is a library for generating parsers from context-free grammars.
https://github.com/engelberg/instaparse

This new release fixes a regression reported in 1.4.4, released last week,
involving the application of `insta/parser` to a URL.

Also, 1.4.4's new macro `defparser` now properly supports all the relevant
optional parameters from the function `parser`, as suggested by user Jeaye
Wilkerson.

Thanks to Alex Engelberg for implementing these fixes/enhancements:
https://github.com/Engelberg/instaparse/pull/151

-- 
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: Order preservation and duplicate removal policy in `distinct`

[Mark Engelberg]

On Thu, Dec 29, 2016 at 1:32 PM, Sean Corfield  wrote:

>
> > I'm just guessing there the answer may just be "equal values are equal
> and you should never care which one you get out".  There are times to care
> though, but then perhaps just don't use `distinct` or be sure to have a
> test on it.  :P
>
>
> Can you provide a scenario when it matters? Given that you had two
> immutable, equal values in a collection, when would it matter which one was
> discarded and which one was kept?
>
>
They may have different metadata, or some objects may already have cached
hash values while others do not, or they may be complex enough objects that
for a later part in the program it matters that certain equal objects meet
the equality test quickly by actually being identical objects, not just
equal.

-- 
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] Instaparse 1.4.4

[Mark Engelberg]

Instaparse is a library for generating parsers from context-free grammars.
https://github.com/engelberg/instaparse

The big news for this release is that Alex Engelberg has combined the
Clojure version with the Clojurescript version of instaparse (initiated by
Lucas Bradstreet in 2014) so that moving forward, we can maintain both
versions as part of the same codebase.  Instaparse leverages a number of
Clojure interfaces and subtle features that differ between Clojure and
Clojurescript, so merging the ports was a significant effort.

Also, to achieve backwards compatibility, Alex wrote the cljsee leiningen
plugin which splits cljc files into clj and cljs files for compatibility
with Clojure 1.5 and 1.6.  Check out cljsee if you are interested in
maintaining backwards compatibility in your own cljc-based projects.  (
https://github.com/aengelberg/cljsee)

The one new feature is a defparser macro, especially relevant to the
Clojurescript port because it makes it possible to build the parser at
compile time so the Clojurescript code will execute more quickly.

Other than that one addition, the behavior should be identical to the prior
release.

-- 
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: recursive bindings not available in let form?

[Mark Engelberg]

Your "y" could also be "fib".  You are permitted to use the same name
inside the fn.

On Fri, Dec 2, 2016 at 12:59 PM, Walter van der Laan <
waltervanderl...@gmail.com> wrote:

> AFAIK there are two options.
>
> You can add a symbol after fn:
>
> (let [fib (fn y [x]
>   (cond
> (< x 2) x
> :else (+ (y (- x 2)) (y (- x 1)]
> (fib 5))
>
>
>

-- 
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: comp and partial vs ->>

[Mark Engelberg]

On Thu, Oct 27, 2016 at 9:39 AM, Alan Thompson  wrote:

> I almost never use either the `comp` or the `partial` functions.  I think
> it is clearer to either compose the functions like Gary showed, or to use a
> threading macro (my favorite is the `it->` macro from the Tupelo library
> ).
> Alan
>
>
You need to use comp if you're building a transducer.

-- 
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: core.async top use cases

[Mark Engelberg]

I always found it a bit ironic that my main use case for agents doesn't
really at all make use of the "mutable ref" aspect of the agent, only the
queue piece.  I usually hold the name of the log file in the mutable ref to
emphasize that the agent is "guarding" this particular log file, but I
don't actually mutate it, so the mutability doesn't really matter for this
purpose.

On Thu, Oct 13, 2016 at 7:02 PM, Mark Engelberg 
wrote:

> My primary use case for agents has always been when I want to coordinate
> multiple threads writing to a log file.  The agent effectively serializes
> all the write requests with a minimum of fuss.
>

-- 
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: core.async top use cases

[Mark Engelberg]

My primary use case for agents has always been when I want to coordinate
multiple threads writing to a log file.  The agent effectively serializes
all the write requests with a minimum of fuss.

-- 
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: Just quick review - "idiomaticy" check (Selection sort)

[Mark Engelberg]

Doesn't seem fair to use a sort algorithm in the implementation of
selection sort.  Besides, sort is an n*logn operation, so you don't want to
(first (sort-by second ...)) anyway.  Instead, choose (apply min-key second
...).  Only catch is you need to make sure you don't pass an empty list, or
it will throw an error rather than returning nil like the sort-by version.

selection-sort isn't going to be performant in an immutable data structure,
but it might be interesting to compare performance using
clojure.core.rrb-vector for faster removal of the minimum value.

On Mon, Oct 10, 2016 at 6:33 AM, Moe Aboulkheir  wrote:

> Here's an example w/ iterate & a simpler 'smallest':
>
> (defn- smallest [xs]
>   (->> xs (map-indexed vector) (sort-by second) first))
>
>

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

[Mark Engelberg]

This is the line that is broken by the recent alphas:
https://github.com/laurentpetit/ccw.server/blob/master/src/ccw/debug/serverrepl.clj#L448

I remember reading somewhere the new alphas have a breaking change to the
way :or destructuring works (but I don't remember the details), so I'm
guessing this is the culprit.

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

[Mark Engelberg]

It appears that the recent alphas are incompatible with the
Counterclockwise REPL.

When I create an empty project in Counterclockwise, using this alpha, then
when I try to launch a REPL, clojure.main throws an error saying:
Exception in thread "main" clojure.lang.ExceptionInfo: Call to
clojure.core/defn did not conform to spec:
:clojure.spec/args  (completions* "Return a sequence of matching
completions given a prefix string \n   and an optional current namespace."
([prefix] (completions* prefix *ns*)) ([prefix ns & {:keys #{filter}, :or
{filter ccw.debug.serverrepl/starts-with-filter}}] (for [[kind completions]
(potential-completions prefix ns) [match-symbol match-object :as
completion] completions :let [f (filter-completion (name match-symbol)
prefix filter)] :when f] {:kind kind, :completion match-symbol, :match
match-object, :filter f})))
 #:clojure.spec{:args (completions* "Return a sequence of matching
completions given a prefix string \n   and an optional current namespace."
([prefix] (completions* prefix *ns*)) ([prefix ns & {:keys #{filter}, :or
{filter ccw.debug.serverrepl/starts-with-filter}}] (for [[kind completions]
(potential-completions prefix ns) [match-symbol match-object :as
completion] completions :let [f (filter-completion (name match-symbol)
prefix filter)] :when f] {:kind kind, :completion match-symbol, :match
match-object, :filter f})))}, compiling:(ccw/debug/serverrepl.clj:443:1)
at clojure.lang.Compiler.load(Compiler.java:7441)

On Mon, Sep 26, 2016 at 11:41 AM, Alex Miller  wrote:

> Clojure 1.9.0-alpha13 is now available.
>
> Try it via
>
> - Download: https://repo1.maven.org/maven2/org/clojure/
> clojure/1.9.0-alpha13
> - Leiningen: [org.clojure/clojure "1.9.0-alpha13"]
>
> 1.9.0-alpha13 includes the following changes since 1.9.0-alpha12:
>
> - s/conform of nilable was always returning the passed value, not the
> conformed value
> - s/nilable now creates a generator that returns nil 10% of the time
> (instead of 50% of the time)
> - s/nilable now delays realizing the predicate spec until first use
> (better for creating recursive specs)
> - clojure.spec.gen now provides a dynload version of
> clojure.test.check.generators/frequency
>
> --
> 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: Idiom question

[Mark Engelberg]

Right, and just to take this one step farther, imagine that instead of
throwing an error, you wanted to actually return a value.  And imagine that
your call to MidiSystem/getMidiDeviceInfo might return nil as well, and
this is something that needs to be protected against and a value returned
accordingly.  These sorts of intertwinings of conditional logic and chains
of computations is exactly when I reach for better-cond, which would make
it look like this:
(cond
  :let [device-info   (MidiSystem/getMidiDeviceInfo)]

  (nil? device-info) :device-not-available

  :let [named-device-info (filter #(= (.getName ^MidiDevice$Info %) name)
device-info)
devices   (map #(MidiSystem/getMidiDevice ^MidDevice$Info
%) named-device-info)
receivables   (filter #(>= (.getMaxTransmitters ^MidiDevice %)
0) devices)]

  (empty? receivables) :no-receivers

  :let [receivable(first receivables)]
  (do
(.open ^MidiDevice receivable)
(.getReceiver ^MidiDevice receivable)))

Since you're new to the community, I want to be sure not to mislead you --
the above example is not mainstream Clojure code.  But it's a great example
of how you can mold the language to suit your own taste of what is
readable.  The above example is my preferred way to write these sorts of
things.

On Wed, Sep 28, 2016 at 2:12 PM,  wrote:

> This is a super interesting thread. Thank you all for your input
>
> I think you are right, @puzzler, that for my case a let may be better. The
> original code is above. Using as-> it looks like this (using 'it' as the
> name)
>
>   (as-> (MidiSystem/getMidiDeviceInfo) it
>  (filter #(= (.getName ^MidiDevice$Info %) name) it)
>  (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) it)
>  (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) it)
>  (if (empty? it) (throw (ex-info "No midi devices with recievers"
> {:name name})) it)
>  (first it)
>  (do (.open ^MidiDevice it) it)
>  (.getReceiver ^MidiDevice it)
>  )
>)
>
> using let it looks like this
>
> (let [device-info   (MidiSystem/getMidiDeviceInfo)
>  named-device-info (filter #(= (.getName ^MidiDevice$Info %) name)
> device-info)
>  devices   (map #(MidiSystem/getMidiDevice ^MidDevice$Info
> %) named-device-info)
>  receivables   (filter #(>= (.getMaxTransmitters ^MidiDevice
> %) 0) devices)
>  _ (when (empty? receivables) (throw (ex-info "No
> midi devices with recievers" {:name name})))
>  receivable(first receivables)
>  result(do
>  (.open ^MidiDevice receivable)
>  (.getReceiver ^MidiDevice receivable))]
>  result)
>
> and if I were doing a code review, I think I would like the last one
> better.
>
> How very interesting. Thanks all for your constructive answers. What a
> great community.
>
> On Wednesday, September 28, 2016 at 4:47:22 PM UTC-4, puzzler wrote:
>>
>> A common convention with as-> is to use the symbol $ because it is
>> recognized as a Clojure identifier but looks distinctive, so it stands out
>> as the placeholder of where to thread.
>>
>> Personally, when reading code, I don't really like to see long uses of
>> the threading operator, and I'd argue that if you find yourself using such
>> long chains of computations that the "important" argument is switching to
>> different positions, that's a sign that maybe you shouldn't be using
>> threading operators in the first place, because it can be hard to mentally
>> follow what intermediate data structure you have at each stage of the
>> computation.  Instead, I'd argue that you should be using `let`, because
>> `let` allows you to give each stage of computation a meaningful name,
>> making it easy for others (or yourself in two months) to read and reason
>> about your code.  `let` allows you to communicate intent.
>>
>> I think one reason people sometimes shy away from using `let` is that it
>> can't easily be used at all positions within one's code.  For example, if
>> you are inside a `cond`  doing some conditional logic, adding a `let` means
>> you have to also start a new `cond`, and your code ends up awkwardly nested
>> and indented, drifting to the right.   The better-cond library removes this
>> limitation, making it easy to write clear functions which intermingle long
>> chains of computations with conditional logic:
>> https://github.com/Engelberg/better-cond
>>
> --
> 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 Go

Re: Idiom question

[Mark Engelberg]

A common convention with as-> is to use the symbol $ because it is
recognized as a Clojure identifier but looks distinctive, so it stands out
as the placeholder of where to thread.

Personally, when reading code, I don't really like to see long uses of the
threading operator, and I'd argue that if you find yourself using such long
chains of computations that the "important" argument is switching to
different positions, that's a sign that maybe you shouldn't be using
threading operators in the first place, because it can be hard to mentally
follow what intermediate data structure you have at each stage of the
computation.  Instead, I'd argue that you should be using `let`, because
`let` allows you to give each stage of computation a meaningful name,
making it easy for others (or yourself in two months) to read and reason
about your code.  `let` allows you to communicate intent.

I think one reason people sometimes shy away from using `let` is that it
can't easily be used at all positions within one's code.  For example, if
you are inside a `cond`  doing some conditional logic, adding a `let` means
you have to also start a new `cond`, and your code ends up awkwardly nested
and indented, drifting to the right.   The better-cond library removes this
limitation, making it easy to write clear functions which intermingle long
chains of computations with conditional logic:
https://github.com/Engelberg/better-cond

-- 
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] data-scope - tools for interactively inspecting and visualizing data

[Mark Engelberg]

This announcement and the github site list different leiningen injections.
Which is correct?

Thanks, this looks very useful.

On Sat, Sep 24, 2016 at 9:52 PM, James Sofra  wrote:

> Hi all,
>
> I have written a little library inspired by Spyscope (which I use a lot)
> to provide tools for interactively inspecting and visualizing data.
>
> data-scope - https://github.com/jsofra/data-scope
>
> Like Spyscope, data-scope uses (abuses?) reader tags to provide a
> convenient mechanism for tagging data anywhere to visualize it.
> Currently is supports readers tags for visualizing data as both charts,
> graphs, tables and trees. There is also support for pretty printing data.
>
> I like to use it by including it in my ~/.lein/profiles.clj, this way it
> is available anywhere:
>
> :dependencies [[jsofra/data-scope "0.1.0"]]
> :injections [(require 'data-scope.charts)
>  (require 'data-scope.graphs)]
>
> or ~/.boot/profile.boot:
>
> (set-env! :dependencies #(conj % '[jsofra/data-scope "0.1.0"]))
>
> (require 'data-scope.charts)
> (require 'data-scope.graphs)
> (boot.core/load-data-readers!)
>
> Contributions and suggestions are welcome!
>
> Cheers,
> James Sofra (@sofra)
>
> --
> 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: map/filter/remove etc. change underlying structure

[Mark Engelberg]

Scala behaves more like your intuition, generally assuming you want back
the same kind of collection as what you passed in.  It can be a bit of a
pain, though, when that's *not* the behavior you want.  Clojure's way puts
you in control by always producing a sequence and letting you put it into
the collection of your choice.

-- 
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: map/filter/remove etc. change underlying structure

[Mark Engelberg]

Everything from the Clojure cheatsheet's "Seq in Seq out" section processes
the input as a sequence (ignoring its concrete type) and always returns a
lazy sequence.  When you pass in a vector v, the very first thing these
functions typically do is call `seq` on it, and they process the input
using first/next/rest.

I'm not really sure what a "lazy-like vector" would look like.  Nothing
like that exists within the set of core Clojure datatypes and no functions
return anything like that.

You can use `into` to "pour" the sequence into the collection of your
choice.  If you're using `into`, then most of these sequence functions
support transducers to avoid allocation of intermediate sequences,
providing a speed boost.

-- 
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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Mark Engelberg]

On Tue, Aug 23, 2016 at 7:45 AM, Alex Miller  wrote:

> We expect Clojure users to become familiar with spec and its output as it
> is (now) an essential part of the language. You will see specs in error
> messages.
>

Is there any documentation to help users understand how to interpret the
error messages?  For example, what is the "path" returned by spec errors?
I've been through the spec guide, and don't recall seeing anything like
that. I've been able to make a few deductions on my own, but without a
better mental model, the messages are still pretty mystifying to me.

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