Re: Critiques of "my-flatten" which uses CPS

[Mark Engelberg]

Yeah, you've answered your own question.  In practice, I doubt the
difference is measurable.

Another common idiom you see in Clojure code is:
(defn f [xs]
  (if-let [s (seq xs)]
...do something with (first s) and (f (rest s))...
...base case...))

This ensures that you seq-ify the input (rather than assuming it has been
seq'ed before passed in), gives you the fast test against nil, and uses
rest rather than next because next would have the effect of causing an
extra unnecessary call to seq.

In a loop-recur situation, it is more common to do the seq once in the
initialization of the loop and then use next which calls seq:

(defn f [xs]
  (loop [s (seq xs)]
(if s
   ... (recur (next s))...
   ... base case ...)))


Out of habit, I prefer to see the base case first so I don't usually do
either of these, but these two patterns are a very popular style, and very
fast execution.  If you don't have a pre-existing preference, these would
be good choices.

-- 
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: unexpected behavior of clojure.core/empty

[Mark Engelberg]

As Mike points out, it does seem that MapEntry is considered a collection
and is designed to emulate a vector so that you don't really have to worry
about whether you have a MapEntry or a two-element vector (and as he points
out, in ClojureScript there really is no distinction between a MapEntry and
a vector).

With that in mind, I would agree that MapEntry's lack of implementation for
empty is most likely an oversight, and ideally should behave as if it were
a vector.




On Sat, Jul 19, 2014 at 11:46 AM, Mike Fikes  wrote:

> MapEntry is a collection:
>
> (coll? (clojure.lang.MapEntry. "a" 1))
>
> ;=> true
>
>
> (ancestors (class (clojure.lang.MapEntry. "a" 1)))
>
> ;=> (a set that includes clojure.lang.IPersistentCollection)
>
>
> The docstring for empty implies it would return an empty MapEntry. But
> perhaps since MapEntry is a special collection type that must have a size
> exactly equal to 2, empty must return nil.
>
>
> Perhaps ClojureScript will one day introduce a MapEntry type and behave
> the same way as Clojure (ClojureScript currently returns a
> PersistentVector).
>
> --
> 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 on Cloudbees versus Heroku?

[Mark Engelberg]

My experience is that Cloudbees' free tier works better than Heroku's and
is somewhat easier to deploy (with cloudbees you just upload a war file
that you've built on your machine, whereas on Heroku, you are checking
files into git which are built server-side, and if the build doesn't quite
work properly on their machine but it does work on yours, it can be
difficult to track down what's going on).

I believe that Heroku's lowest cost priced tier is cheaper than Cloudbees',
but it has been a while since I've compared the two.


On Wed, Jul 30, 2014 at 4:40 AM, Jonathon McKitrick 
wrote:

> I've deployed a few apps to Heroku, but I'm always looking for new options
> with better pricing or features.
>
> Is there any reason Cloudbees might be better for Clojure apps than
> Heroku?  If the big selling point of Cloudbees is Jenkins, I don't think
> that benefits Clojure projects, right?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 on Cloudbees versus Heroku?

[Mark Engelberg]

Yes.


On Wed, Jul 30, 2014 at 5:18 PM, Jonathon McKitrick 
wrote:

> Did you deploy clojure apps?
>
>
> On Wednesday, July 30, 2014, Mark Engelberg 
> wrote:
>
>> My experience is that Cloudbees' free tier works better than Heroku's and
>> is somewhat easier to deploy (with cloudbees you just upload a war file
>> that you've built on your machine, whereas on Heroku, you are checking
>> files into git which are built server-side, and if the build doesn't quite
>> work properly on their machine but it does work on yours, it can be
>> difficult to track down what's going on).
>>
>> I believe that Heroku's lowest cost priced tier is cheaper than
>> Cloudbees', but it has been a while since I've compared the two.
>>
>>
>> On Wed, Jul 30, 2014 at 4:40 AM, Jonathon McKitrick > > wrote:
>>
>>> I've deployed a few apps to Heroku, but I'm always looking for new
>>> options with better pricing or features.
>>>
>>> Is there any reason Cloudbees might be better for Clojure apps than
>>> Heroku?  If the big selling point of Cloudbees is Jenkins, I don't think
>>> that benefits Clojure projects, right?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/k_bOLXXCAn8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> --
> Jonathon McKitrick
>
>  --
> 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: Transducers are Coming

[Mark Engelberg]

I'm also curious to understand how the underlying implementation of
transducers leads function composition to behave in the reverse order of
ordinary function composition.


On Thu, Aug 7, 2014 at 8:07 AM,  wrote:

> Hello, what is the reason for comp to produce two different orderings
> depending on whether it composes partials or transducers?
>
> (comp (partial filter even?) (partial map (partial + 1)))
> (comp (filter even?) (map (partial + 1)))
>
> Wouldn't it be more intuitive for upcoming clojurians to have both
> cases exhibit the same execution order?
>
>
> On Wednesday, August 6, 2014 8:01:24 PM UTC+2, Rich Hickey wrote:
>
>> I pushed today the initial work on transducers. I describe transducers
>> briefly in this blog post:
>>
>> http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming
>>
>> This work builds on the work done for reducers, bringing
>> context-independent mapping, filtering etc to other areas, such as
>> core.async.
>>
>> This is work in progress. We will be cutting alpha releases to help make
>> it easier to start using core's transducers together with core.async's new
>> support for them.
>>
>> I am very excited about this powerful technique and how we all might use
>> it.
>>
>> Please have a look.
>>
>> Feedback welcome,
>>
>> Rich
>>
>>  --
> 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.logic for boardgames

[Mark Engelberg]

I don't see how core.logic would apply here.

You might be interested in a Java-based general game playing engine which
you can leverage from Clojure.  Many take logical descriptions of the game
rules in LISP form.

http://www.ggp.org/



On Sat, Aug 9, 2014 at 3:51 AM, Robin Heggelund Hansen  wrote:

> Hi.
>
> I'm starting a new project now, where users are presented with a set of
> boardgames (chess, checkers, othello...) which they then can play together
> online.
> Does it make sense to implement the game logic using core.logic, and does
> it transfer well to cljs (i'd like to share logic between backend and
> frontend if i can)?
>
> I don't know core.logic, but would like to learn if it is a good fit for
> the problem I'm solving.
>
> 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.
>

-- 
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: How is this code evaluated (question about transdurcers)

[Mark Engelberg]

The comp is the same comp as in clojure.core, but the way that transducers
are implemented, comp has the effect of chaining them in a left-to-right
manner rather than the way it behaves with regular functions.  I actually
prefer left-to-right composition, but it is somewhat unfortunate that
transducers compose in the opposite direction from normal functions; I
suspect this is going to be a point of confusion for many people.


On Sun, Aug 24, 2014 at 11:39 AM, Ashton Kemerling <
ashtonkemerl...@gmail.com> wrote:

> If you are referring to the new transducer comp, if I recall correctly it
> works in the opposite direction from the comp in clojure.core. I can't find
> any docs at hand that prove that, so I would check the docstring of comp.
>
>
> On Sun, Aug 24, 2014 at 11:04 AM, rogergl  wrote:
>
>> I have problems to understand how the following code evaluates. I
>> understand what the code does but not how this result is computed:
>>
>> BTW: This is an example from the async webinar:
>>
>>  (chan 1 (comp (map #(.-keyCode %))
>>   (filter #{37 39})
>>   (map {37 :previous 39 :next})
>>
>> For example:  comp evaluates from right to left. But this code looks more
>> like it is evaluated from left to right ?
>>
>> Regards
>>   Roger
>>
>>
>>  --
>> 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: Books on Functional Algorithms aimed towards undergrad CS?

[Mark Engelberg]

Although it's not specifically an "algorithms" book, the book "How to
Design Programs" covers a number of important classes of algorithms
(sorting, graph searches, etc.), and more importantly, teaches you how to
reason about them and how to come up with them yourself.

Another great resource is programmingpraxis.com.  If you work through a
significant number of those exercises, you'll gain significant algorithm
expertise.  All the exercises are accompanied by a Scheme solution, which
should be easy to port to Clojure.

Also worth mentioning is a very hard book (harder than Okasaki) called
Pearls of Functional Programming (code is in Haskell).

You can learn a lot by taking any typical algorithms book and try
converting the algorithms to Clojure.  Ask here if you run into problems.

On Mon, Sep 8, 2014 at 2:09 PM, Evan Zamir  wrote:

> Thanks, Chris.
>
> I actually have Okasaki's book and thought to mention it in the post as an
> example of a book that is too advanced for me. Not to mention, it's in ML.
> I'm sure it's a great book, and I could try to slog through it, but it
> would be great to have a more introductory level book on algorithms from a
> functional perspective.
>
>
> On Monday, September 8, 2014 1:38:28 PM UTC-7, Chris Sims wrote:
>>
>> On Mon, Sep 8, 2014, at 10:04 AM, Evan Zamir wrote:
>>
>> (First, I should say that I am not an undergrad, haven't been for almost
>> two decades! But in terms of my CS knowledge, that's pretty much where I
>> am.)
>>
>> I recently started reading Sedgewick's Algorithms book ("the red one")
>> and am at least making an attempt to follow along with his Coursera course.
>> As someone who has also been trying to learn Clojure, it struck me that it
>> would be great to have a resource/book on functional versions of all the
>> same algorithms. I know there are Clojure implementations of many, if not
>> all, of the algorithms in the book (for example I found an implementation
>> of union-find  on
>> github), but it would be nice to have a self-contained functional version
>> of an "Algorithms" book.
>>
>> I guess my question boils down to this. Is there a functional algorithms
>> book aimed at the beginning/intermediate CS undergraduate curriculum? If
>> not, seems to me that would be a big hole that needs to be filled.
>> -evan
>>
>>
>> It's not quite what you're looking for, but Osaki's Purely Functional
>> Data Structures might be of interest to you. It obviously covers data
>> structures, but also operations on the data structures.
>>
>> --Chris
>>
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-alpha2

[Mark Engelberg]

When I explain to new Clojurists what the ! means, I explain that it calls
attention to a mutation function that is unsafe to call inside a
transaction.  Many programmers coming from Scheme are used to thinking of !
as meaning *anything* involving mutation, but that's not the case in the
Clojure.  This more subtle distinction (that it needs to be unsafe in a
transaction) clarifies why swap! has an exclamation point, but ref-set does
not, even though both involve mutation.

Assuming my description of Clojure's use of ! is correct (and if I'm wrong
and am not thinking of some important counterexample, please let me know),
then it doesn't really make sense for volatile to be called volatile!.
Yes, volatiles are less safe than atoms, but the creation of the volatile
itself is perfectly fine to occur in a transation.  Only vswap! and vreset!
require the exclamation point.

I'd go one step further and question why we need new names vswap! and
vreset!, when swap! and reset! are perfectly clear and sufficient.  As
Clojure has become increasingly interface and protocol-driven, it makes
less and less sense to have a proliferation of function names for the same
behavior on different underlying objects.  vswap!, for example, is exactly
the semantics you'd expect if you overloaded swap!, describing it as a
function that can be applied to both atoms and volatiles, where volatiles
are the more thread-unsafe, less atomic, alternative, because that's the
nature of the underlying box.

--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: [ANN] Clojure 1.7.0-alpha2

[Mark Engelberg]

I'm curious: how much faster are volatiles than atoms?

-- 
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: (Request) Rich Hickey's EuroClojure 2014 slides

[Mark Engelberg]

+1.  I also was unable to follow the video without the slides.

On Thu, Sep 11, 2014 at 12:36 PM, Leon Grapenthin 
wrote:

> @Alex Miller: It would be great if an exception could be made. Again: The
> slides are not in the video.
>
> Consuming them "in context of the talk" is my intention by opening two
> windows (one with the video, one with the slides).
>
>
> Thanks, Leon.
>
>
> On Thursday, September 11, 2014 4:33:41 PM UTC+2, Alex Miller wrote:
>
>> Usually Rich doesn't release his slides as he prefers for them to be
>> consumed in the context of the talk.
>>
>> On Thursday, September 11, 2014 8:44:47 AM UTC-5, Leon Grapenthin wrote:
>>>
>>> Hi,
>>>  I am looking for the slides of this talk because one can't see them in
>>> the video:
>>>
>>> http://vimeo.com/100518968
>>>
>>> Thanks,
>>>  Leon.
>>>
>>>
>>>
>>>
>>>  --
> 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: pigpen newbie question

[Mark Engelberg]

You're probably using Clojure 1.7.0 alpha 2, which introduced a new
function called "cat" into the core namespace, which overlaps with a
function in instaparse.

A couple nights ago, I updated instaparse to version 1.3.4, with an update
to deal with this change in alpha 2, but pigpen has not yet been updated to
use that version of instaparse.

You can either go back to a non-alpha release of Clojure, or wait for the
pigpen folks to update, or perhaps there is some leiningen-fu you can do in
the project.clj file to override the instaparse dependency loaded by pigpen
with instaparse 1.3.4.

On Thu, Sep 11, 2014 at 5:16 PM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> Hi ,
>  I am trying to compile a simple clj file which does nothing apart from
> requiring the pigpen name-space and it fails to compile with the following
> error. Can anybody help?
>
> Attempting to call unbound fn: #'instaparse.combinators-source/cat
>
> the full stack trace is here.
> https://gist.github.com/sunilnandihalli/b400e21552ca97038e56
>
> Thanks,
> Sunil.
>
> --
> 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 terminology

[Mark Engelberg]

This whole discussion makes me think you're trying to teach Clojure in a
Scheme-like way, which maybe isn't the best approach.

In Clojure, it is rare to need quoted lists and symbols.
Instead of 'hello, you would use :hello.
Instead of '(1 2 3), you would use [1 2 3].

So the whole notion of quoting can be avoided with beginners, and doesn't
typically need to be introduced until you get to macros.  This is good
because quoting can be a surprisingly subtle and tricky topic.  Much easier
to work with and teach self-evaulating expressions.  If you really need a
list, I'd recommend teaching it as (list 1 2 3), and only much later
teaching quote as a sort of shortcut.

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

[Mark Engelberg]

Relating to your random thought, note that:
=> '[(+ 2 3) (+ 4 5)]
[(+ 2 3) (+ 4 5)]

Probably the only way to make sense out of this is to talk about how every
expression is first "read" then "evaluated".

You can interactively explore how things are "read" in Clojure with
read-string.

=> (read-string "(a b c)")
(a b c)

As far as I know, Clojure doesn't give you a whole lot of control over how
things print at the REPL.  Several things print out identically, so a
legitimate follow-up question to the above, is "What exactly is that data
structure that was printed out as (a b c)?"

We can probe at it a little bit:
=> (type *1)
clojure.lang.PersistentList
=> (type (first *2))
clojure.lang.Symbol

>From this, we can perhaps conclude that in order to construct such a data
structure manually, we would evaluate:

=> (list (symbol "a") (symbol "b") (symbol "c"))
(a b c)

Through this process, you can gradually learn the way that expressions
typed into the REPL are read in as data structures.
Taking some of your other examples:

hello
after being read, becomes the data that would be produced by evaluating
(symbol "hello")

(1 2 3)
after being read, becomes the data that would be produced by evaluating
(list 1 2 3)

[(+ 2 3) (+ 4 5)]
after being read, becomes the data that would be produced by evaluating
(vector (list (symbol "+") 2 3) (list (symbol "+") 4 5)))
Note, I'm ignoring here the details of namespaces, and the details of how
these numbers are internally represented as longs.

Once you understand this reading process, the next step is to understand
the rules of evaluation.

For example,

Symbols evaluate by looking up what's stored in the corresponding var.
Lists evaluate by evaluating all the elements of the list, and treating it
as a function application of the first element to the rest of the elements
as arguments.
Vectors evaluate to a vector of all the evaluated items.
Numbers evaluate to themselves.
Keywords evaluate to themselves.
Strings evaluate to themselves.

Then, the question is what happens with quote.

=> (read-string "'(a b c)")
(quote (a b c))

So we see that '(a b c) is read in as the data structure
(list (symbol "quote") (list (symbol "a") (symbol "b") (symbol "c")))

Now we know how quotes are read, but how do they evaluate?

With all this background, it is now easy to understand how quote
evaluates.  Very simply, quote returns whatever it is quoting,
unevaluated.  The effect of this is that quote gives you a mechanism to get
back the data structure as it was read, without evaluating it.

Summing all this up,

'(a b c)
is like a shortcut for
(read-string "(a b c)")



On Fri, Sep 12, 2014 at 10:54 AM, jvanderhyde 
wrote:

> Another random thought: What to you call this?
> [(+ 2 3) (+ 4 5)]
> It is an expression, but it is not a literal--I cannot say it "evaluates
> to itself."
>
> Sorry if I'm being pedantic. Maybe it doesn't matter. Terminology is
> important, though, when I'm trying to teach.
>
> --
> 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 terminology

[Mark Engelberg]

That's a neat trick!

-- 
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: Profiling in Counterclockwise

[Mark Engelberg]

I haven't done it in a while so can't give detailed instructions, but it is
definitely possible to profile code running in the REPL.  The profiler that
comes with java allows you to select any java process running on your
machine, so you just select the JVM instance that is running the REPL.
Then, you can start and stop recording profiling data any time you want, as
you do things in the REPL you want to profile.

On Sun, Oct 5, 2014 at 3:55 PM, Andy Fingerhut 
wrote:

> I would suggest doing Google searches for combinations of terms such as:
>
> clojure profiling
>
> That search found several relevant matches when I tried it.
>
> I am not sure why you say "2) Deploy to somewhere", unless by "somewhere"
> you include running a JVM on your own local development machine?  You
> should be able to profile a JVM process on whatever machine that you run a
> REPL on.
>
> Your step "3) Learn how to use ..." might be true, but it depends upon
> your threshold of "complicated".  For some, it is simply par for the course
> for development.
>
> Andy
>
> On Sun, Oct 5, 2014 at 1:38 PM, Fluid Dynamics  wrote:
>
>> On Sunday, October 5, 2014 3:57:37 PM UTC-4, Gary Verhaegen wrote:
>>>
>>> When I need to profile (which is asmittedly quite rare), I use VisualVM,
>>> which should have been installed along with the JDK. I'd recommend editing
>>> the default settings to remove clojure.** and add your own namespaces as
>>> starting points for the profiling.
>>>
>>> For more lightweight approaches, I'd suggest checking out Timbre and
>>> Criterium, though I have very little experience with both.
>>>
>>>
>>> None of this is Eclipse specific or runs in Eclipse.
>>>
>>
>> So, what you're saying is that I'd have to
>>
>> 1) Package everything up
>> 2) Deploy to somewhere
>> 3) Learn how to use > classpath configuration and stuff>
>> 4) Identify hot spots
>> 5) Make improvement of some sort
>> 6) Back to step 1?
>>
>> Because that seems to *completely eliminate* the benefit of having a REPL
>> and fast development/try things/edit cycle. :(
>>
>> Meanwhile, why did I get google results for a supposed "Profiling and
>> Logging perspective" in Eclipse if no such thing exists?
>>
>>  --
>> 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: Modelling in Clojure

[Mark Engelberg]

On Thu, Oct 16, 2014 at 3:49 PM, James Reeves  wrote:

>
> {:name "Alice", :email "al...@example.com"}
>
> At this point, stop. You have your data model.
>
>
>
I think that coming from OO, the most disconcerting piece of Clojure's
philosophy is that it is relatively rare in Clojure to publish an API with
data accessors like `get-name`.  The most common way to access the name
would be to simply use
(:name person)

But let's say later you decide you want your data model to be {:first-name
"Alice", :last-name "Beasley", :email "al...@example.com"}, and you want to
change name to be a computed value that concatenates first and last names
-- this is going to break all your existing code.  If name were only
accessed throughout your code via the call `get-name`, then it would be
trivial to make this change.

(Theoretically, it is possible to implement a revision to a person data
structure by representing it as a custom map that reimplements keyword
access so that (:name person) calls a function rather than does the usual
keyword lookup, but I've never seen anyone do this, so I'm ignoring this
possibility for the purpose of this discussion).

Many OO languages force, or encourage you stylistically, to hide everything
behind setters and accessors, so you get for free the ability to change
your mind about the data model later.

With Clojure, it is very common to allow your data model to *be* the API.
This puts some additional pressure to get it right the first time.  You
have to explicitly think ahead about which fields might need to change in
the future.

--Mark

P.S. To answer your specific questions about what is preferred, I'd go with
your version that looks like:

(defn make-customer [name email]
 {:name name, :email email})

(def customer1 (make-customer "Tom" "em...@address.com"))

I wouldn't bother with records unless I needed to use protocols.  I would
use a constructor like make-customer, but I would probably not use an
accessor like get-name.  I think these would be the most common choices in
the Clojure community (although other choices are also valid).

-- 
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: Modelling in Clojure

[Mark Engelberg]

Right, my point wasn't just about "data change", it was more specifically
about the addition or change of "computed fields".

In Clojure, non-computed fields are usually accessed directly by keyword,
whereas computed fields require an actual API.  This difference in access
style complicates things if you want to change which things are stored
versus computed.

Another complicated scenario that occurs fairly commonly in my work is that
there are computed fields that you want to memoize so that you only want to
compute them once.  For example, imagine that the first time you look up
this customer's zip code, you want to do some lookup against some
time-consuming service to compute the more precise 4-digit extension to the
zip code, and store it as part of the data so you never have to compute it
again.  These sorts of data models are very natural in OO, but require more
thought to pull off successfully in Clojure.

Clojure's modeling capability fits my brain quite well, and I don't see
these things as major problems.  But I feel obligated to point them out to
people coming from an OO background as things to watch out for.

As you say, there is a motto in Clojure: "The data *is* the API."  What
that means is that planning out the data representation becomes just as
important as planning out the API is in an OO language.  In OO, the API
protects you from certain kinds of data changes, whereas in Clojure the
data is more visible, and once people start writing code assuming that
certain fields are going to always be present and stay named the same way,
you're not going to be able to change that without upsetting your users.

-- 
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: Modelling in Clojure

[Mark Engelberg]

Yeah, it's hard to deny the convenience of Clojure's keyword lookups and
standard assoc mechanism for getting and setting stored values, but I think
Bertrand Meyer's Uniform Access Principle reflects some pretty deep
thinking about the kinds of complications that arise in maintaining large
programs.  Although the Clojure community mostly rejects the Uniform Access
Principle right now, as people start writing larger programs in Clojure,
and need to maintain them for longer periods of time, it will be
interesting to see if the pendulum swings back in favor of uniform access.

It will be fun to have this conversation again in 5 years time.

The good news is that if the community does start to see more value in
uniform access, achieving that is just a few macros away.

--Mark

On Fri, Oct 17, 2014 at 10:49 PM, Mars0i  wrote:

> On Thursday, October 16, 2014 11:53:42 PM UTC-5, puzzler wrote:
>>
>> In Clojure, non-computed fields are usually accessed directly by keyword,
>> whereas computed fields require an actual API.  This difference in access
>> style complicates things if you want to change which things are stored
>> versus computed.
>>
>
> This also means that you have to remember which data has a keyword
> accessor and which uses a function.
>
> --
> 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: Modelling in Clojure

[Mark Engelberg]

I think all of James' points about the proven value of structuring an
application primarily around data rather than a complex API are right on
point.  It is one of the things I love about the Clojure philosophy.

But there's nothing about the value of data-driven development that
requires data lookups and data computations to be so different.  There's
plenty of room for Clojure to have continued evolution in this area and
still preserve the essence of its approach.

For example, consider that several years ago, Rich declared that Clojure
would never have a simple mutable box.  But lo and behold, now we have
volatiles.  Consider the rise of records, protocols, and components -- a
lot of judiciously applied OOish concepts.

I really enjoy introducing Java programmers to the Clojure way of thinking
about data.  But when I do, I like to explain the current thinking in the
Clojure community, talk about some of the most triumphant success stories
(e.g., Ring), acknowledge some of the pain points, talk about some of the
ways that Clojure has grown to handle other data modeling pain points, and
some of the ways that Clojure may continue to grow.

-- 
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 empty on a map entry

[Mark Engelberg]

See this thread:
https://groups.google.com/forum/#!searchin/clojure/unexpected$20behavior$20of$20clojure.core$2Fempty/clojure/z4GiyxvFEqg/zxwTklPa2mEJ

-- 
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: CCW bug [SEVERE]

[Mark Engelberg]

On Sat, Oct 25, 2014 at 11:19 PM, Fluid Dynamics  wrote:

> This is a really weird one, when you think about it. How the heck does a
> programmer make a mistake that results in the *file save* function going
> into an *infinite loop*? At least it didn't go into an infinite loop
> filling my filesystem...
>

You're making a pretty big assumption that the bug happened in the file
save function.  By your own admission, the file was saved perfectly fine,
so perhaps after the file was saved it triggered a screen refresh or a
project reload or a rescanning of the files in your directory, or any
number of things that could have hung due to something specific on your
system like a lack of sufficient memory or some file locked by another
process, or whatever.

You're also making a big assumption that this is a bug in counterclockwise,
and not a problem with Eclipse itself.  I wouldn't exactly call Eclipse a
rock-solid development environment.

I understand why you feel freaked out, because it is extremely disturbing
to potentially lose work, but there's not much of a foundation here for
your fear that the integrity of your data was put at risk, at least, not
any more so than any other random crash that can happen when using any
modern IDE, or, say, a power outage or hard drive failure.

As others have said, source control is one of your best protections against
many types of failure.  In the meantime, this definitely seems worth
reporting, through proper channels, if you genuinely care about making the
product better.  Although you say you only got a stacktrace, Eclipse logs a
lot of information about what it is doing.  Laurent could probably guide
you through the process of sending him a copy of the log so he can see
exactly where the failure occurred.  Of course, if you don't really want to
make counterclockwise better, then just move along and try a different
development environment -- there are several to choose from.  In my
experience, Emacs, as one of the oldest development environments, is one of
the most stable environments I've ever used -- I've kept Emacs open for
weeks without it ever glitching.  So if that's the most important thing for
you, try Emacs.  Ultimately, I decided I just don't like Emacs, and now I'm
a happy Counterclockwise user.

-- 
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: CCW 0.28.1.STABLE001 editor *very* slow when entering docstrings.

[Mark Engelberg]

I think a lot of people use the paredit mode which automatically keeps
quotes balanced, but as someone who doesn't use paredit, I have also
noticed this problem, and agree that it is a nuisance.  (It's not just
strings, I think, but can occur with other sorts of unbalanced things when
typing at the top of a long file).  The only workaround I know of is the
one you've already discovered.

-- 
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: 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] 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: 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] 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: [ANN] Clojure 1.9.0-alpha1

[Mark Engelberg]

On Wed, May 25, 2016 at 6:38 AM, Alex Miller  wrote:

> So something like
>
> (defn valid-or-explain [spec data]
>   (let [v (s/valid? spec data)]
> (when-not v (s/explain spec data))
> v))
>
>

Right, that's what I was originally thinking. The form Sean Corfield
suggested might make more sense:
(defn assert-valid [spec data]
(when-not (s/valid? spec data)
 (throw (AssertionError. (with-out-str (s/explain spec data))
  (ex-info “SpecFailure” (s/explain-data
spec data))

My objective in suggesting it is that we figure out what is the most useful
thing inside a pre-/post-condition, and implement it once and standardize
on it rather than a bunch of people coming up with their own ad-hoc
solution in their own libraries for printing a meaningful error message
when something doesn't conform.

-- 
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: Avoiding nested ifs...

[Mark Engelberg]

On Thu, May 26, 2016 at 1:29 PM, John Szakmeister 
wrote:

>
> Yeah, cond is definitely useful here, but not in general.
>
>
cond *is* useful in general, just not the cond that is built-in to Clojure.

About 5 years ago, Christophe Grand pointed out in a blog post that cond,
augmented with a few extra things (:let, :when, and :when-let) neatly
solved a ton of situations where Clojure often gets inelegantly nested,
i.e., interleavings of conditional tests with local variable definitions,
protection against nil values, etc.

I've been using this better cond ever since, for five years now, routinely,
in my own code.  Once you start using this better cond, you'll never want
to go back.

Here's the implementation, for use in your own code:
https://gist.github.com/Engelberg/9fc1264f938077cf03eee112ebed1768

The most important ingredient here is the ability to put :let into your
cond.  There has been a JIRA issue for this for nearly 7 years (it's a
natural extension to cond, because :let is allowed in for clauses).  Given
the incredible value this feature offers in terms of keeping code nice and
"flat" as opposed to deeply nested/indented, I'm surprised it hasn't yet
made it in to Clojure core.  Maybe soon, though, if enough people
demonstrate that they care.  Go vote for this issue:
http://dev.clojure.org/jira/browse/CLJ-200.

If you don't see how this feature would clean up code, feel free to post an
example that feels ugly with cond, and I'll show you how this improves it.

-- 
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 0.11.0, performance without the tradeoffs

[Mark Engelberg]

In your writeup, you say that there would be further speed benefits if you
could have a global mutable variable within the context of a function (like
a static field).

Can't you effectively accomplish that already in Clojure like this?:

(let [mycache (volatile! nil)]
  (defn foo []
  ...)))

-- 
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 0.11.0, performance without the tradeoffs

[Mark Engelberg]

I think this is an interesting problem, so here are some additional
brainstorms on the issue that may or may not be useful...

One strategy to create a global mutable variable from inside the function
would be to use def at macroexpansion time to create a var, and then just
refer to it in the expansion, like this:

(defmacro expand-to-something-with-mutable-global []
  ; At macroexpansion time, create a (private) var containing a volatile.
  (let [global-name (gensym "cache")]
(eval `(def ^:private ~global-name (volatile! nil)))
; Now macro can refer to this var, can use as a cache, etc.
`(if-let [cache-contents# (deref ~global-name)]
   (do-something-with cache-contents#)
   (reset! ~global-name init-value-for-cache

Not sure if this would be any faster than ConcurrentHashMap, but I would
guess that it would be if Clojure resolves the location of the var in
memory once, at compile-time.

A related technique would be for Specter to maintain an ArrayList of
volatiles.  At macroexpansion time, you add a fresh volatile to the end of
the ArrayList, noting the index of its location, and then inside the macro
you hardcode a lookup in the ArrayList at the specific index to retrieve
the volatile containing the cache for this particular expansion.  I would
expect this to be faster than looking up in a hash map, although there'd be
some additional concurrency/locking details to worry about that I assume
ConcurrentHashMap handles for you.

Or just use an ArrayList's slot directly as the cache (rather than storing
a volatile to add a level of indirection), but then the concurrency
logistics would be even more complicated.

On Tue, May 31, 2016 at 12:50 PM, Nathan Marz  wrote:

> No, because that global mutable variable would need to be specifiable by
> Specter on usage of the library. For example, if you wrote:
>
> (defn foo []
>   (select [:a :b] {:a {:b 1}}))
>
> `select` has no ability to control anything outside the context of its
> form. It certainly can't wrap `foo` to put a volatile field in its closure.
> So for the static-field idea, it would expand to something like:
>
> (defn foo []
>   (static-field [pathcache]
>  (if-not pathcache (set! pathcache ...))
>  ...
>  ))
>
>
>
> On Tuesday, May 31, 2016 at 3:15:26 PM UTC-4, puzzler wrote:
>>
>> In your writeup, you say that there would be further speed benefits if
>> you could have a global mutable variable within the context of a function
>> (like a static field).
>>
>> Can't you effectively accomplish that already in Clojure like this?:
>>
>> (let [mycache (volatile! nil)]
>>   (defn foo []
>>   ...)))
>>
> --
> 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 0.11.0, performance without the tradeoffs

[Mark Engelberg]

I'm glad it helped!

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

Deep transients

[Mark Engelberg]

Let's say I have an object represented by a series of nested maps:

{:a {:b 1} :c {:d 2}}

and now I'm going to be making a whole slew of edits to the submaps.

To do this efficiently, I need to make all the levels of the map
transients, because any update to the inner map also updates the outer map:

(transient {:a (transient {:b 1}), :c (transient {:d 2})})

and then at the end I need to do a nested persistent! operation.

However, there aren't good facilities for dealing with nested transients,
for example, there's no assoc!-in.  So it's a real pain to work with.

Has anyone dealt with this already, and developed a suite of tools for
working with nested transients, or other techniques for making batch
updates efficient for deeply nested objects?

-- 
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] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Mark Engelberg]

This is interesting.  Is it faster than uuid for generation and/or
comparing for equality?

On Thu, Jun 2, 2016 at 6:03 PM, Max Countryman  wrote:

> Hi,
>
> I’m happy to announce a new release of Flake, the decentralized, k-ordered
> unique ID generator.
>
> Flake 0.4.0 includes a number of important breaking changes, but by far
> the most important is dropping `generate` in favor of `generate!` which now
> returns a ByteBuffer. Previously `generate` returned a BigInteger, however
> this arbitrarily limits how an application can handle IDs and goes against
> the spirit of the Erlang implementation. In order to maintain backwards
> compatibility, a helper `flake->bigint` was added to the core namespace.
> Applications which already consume flakes should update their calls to
> `generate` so they are `generate!` and wrap them with `flake->bigint` if
> BigIntegers are desirable or already used.
>
> Github: https://github.com/maxcountryman/flake
> Changes: https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md
>
> Thanks!
>
>
> Max
>
> --
> 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: Deep transients

[Mark Engelberg]

That's an interesting idea.  Maybe there's a way to build a set of Specter
navigators that operate on transients, and then use its corresponding
eqiuvalences for assoc-in, update-in, etc.

On Thu, Jun 2, 2016 at 9:01 PM, Colin Fleming 
wrote:

> Have you looked at Specter? I actually don't know if it uses transients
> under the hood or not, or if you can make it do so, but it seems like a
> good fit for the data manipulation problem, at least.
>
> On 3 June 2016 at 14:43, Mark Engelberg  wrote:
>
>> Let's say I have an object represented by a series of nested maps:
>>
>> {:a {:b 1} :c {:d 2}}
>>
>> and now I'm going to be making a whole slew of edits to the submaps.
>>
>> To do this efficiently, I need to make all the levels of the map
>> transients, because any update to the inner map also updates the outer map:
>>
>> (transient {:a (transient {:b 1}), :c (transient {:d 2})})
>>
>> and then at the end I need to do a nested persistent! operation.
>>
>> However, there aren't good facilities for dealing with nested transients,
>> for example, there's no assoc!-in.  So it's a real pain to work with.
>>
>> Has anyone dealt with this already, and developed a suite of tools for
>> working with nested transients, or other techniques for making batch
>> updates efficient for deeply nested objects?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.9.0-alpha5

[Mark Engelberg]

Also non-scientific: I personally use BigInteger a fair amount, but have
never needed to use BigDecimal.

On Tue, Jun 7, 2016 at 9:41 PM,  wrote:

> As a completely non-scientific data point, we had precisely one place in
> our 30k+ lines of code where we can use bigdec? And there is also precisely
> one place we could use biginteger? 😊
>
>
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
>
>
>
> *From: *Alex Miller 
> *Sent: *Tuesday, June 7, 2016 7:56 PM
> *To: *Clojure 
> *Subject: *Re: [ANN] Clojure 1.9.0-alpha5
>
>
>
> Not sure, I can ask. I think BigDecimal is probably used way more than
> BigInteger.
>
>
> On Tuesday, June 7, 2016 at 8:52:36 PM UTC-5, Sean Corfield wrote:
>
> Whilst updating our code, I noticed there’s bigdec? to test for
> java.math.BigDecimal but not bigint? or biginteger?
>
>
>
> Is there a specific reason for that omission or were those just missed?
>
> --
> 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: What I'm missing in my Instaparse rules?

[Mark Engelberg]

Regular expressions are treated with their ordinary Java/Clojure, greedy
semantics.

Your regular expression for ITEM doesn't exclude whitespace or }
characters, so ITEM is matching "Harden }" which leaves no characters left
to match your grammar's right curly brace requirement.

=> (re-seq #"[^\"]+" "Harden }")
("Harden }")

A solution would be to make the regex for ITEM more restrictive.

On Sun, Jun 12, 2016 at 12:52 PM, Hussein B.  wrote:

> Hello,
>
> I'm playing around Instaparse library, starting very simple.
>
> For input like :
>
> { player }
>
> I created the following parser:
>
> (def ast
>   (ist/parser
> "TEST = OBJECT
>  = <#'\\s+'>
>  = <'{'>
>  = <'}'>
> ITEM = #'[^\"]+'
> OBJECT = CURLY_OPEN WHITESPACE* ITEM WHITESPACE* CURLY_CLOSE"))
>
>
> In the REPL:
>
> user=> (ast "{ Harden } ")
>
> Parse error at line 1, column 12:
>
> { Harden }
>
>^
>
> Expected one of:
>
> "}" (followed by end-of-string)
>
> #"\s+"
>
>
> Any ideas what I'm doing wrong?
>
> Thanks for help.
>
> --
> 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: What I'm missing in my Instaparse rules?

[Mark Engelberg]

Looks like you left off a + in your regular expression for String.

On Mon, Jun 13, 2016 at 2:59 AM, Hussein B.  wrote:

> Thanks for your help.
>
> I tried this new grammar to match characters only:
>
> "
>
> TEST = OBJECT
>
>  = <#'\\s+'>
>
> OBJECT = CURLY_OPEN WHITESPACE* STRING WHITESPACE* (WHITESPACE* OBJECT
> WHITESPACE*)* CURLY_CLOSE
>
>  = <'{'>
>
>  = <'}'>
>
> STRING = #'[a-zA-Z]'
>
> "
>
>
> (parse "{harden {James}}")
>
>
> Parse error at line 1, column 3:
>
> {harden {James}}
>
>   ^
>
> Expected one of:
>
> "}" (followed by end-of-string)
>
> "{"
>
> #"\s+"
>
> On Sunday, June 12, 2016 at 10:07:01 PM UTC+2, puzzler wrote:
>>
>> Regular expressions are treated with their ordinary Java/Clojure, greedy
>> semantics.
>>
>> Your regular expression for ITEM doesn't exclude whitespace or }
>> characters, so ITEM is matching "Harden }" which leaves no characters left
>> to match your grammar's right curly brace requirement.
>>
>> => (re-seq #"[^\"]+" "Harden }")
>> ("Harden }")
>>
>> A solution would be to make the regex for ITEM more restrictive.
>>
>> On Sun, Jun 12, 2016 at 12:52 PM, Hussein B.  wrote:
>>
>>> Hello,
>>>
>>> I'm playing around Instaparse library, starting very simple.
>>>
>>> For input like :
>>>
>>> { player }
>>>
>>> I created the following parser:
>>>
>>> (def ast
>>>   (ist/parser
>>> "TEST = OBJECT
>>>  = <#'\\s+'>
>>>  = <'{'>
>>>  = <'}'>
>>> ITEM = #'[^\"]+'
>>> OBJECT = CURLY_OPEN WHITESPACE* ITEM WHITESPACE* CURLY_CLOSE"))
>>>
>>>
>>> In the REPL:
>>>
>>> user=> (ast "{ Harden } ")
>>>
>>> Parse error at line 1, column 12:
>>>
>>> { Harden }
>>>
>>>^
>>>
>>> Expected one of:
>>>
>>> "}" (followed by end-of-string)
>>>
>>> #"\s+"
>>>
>>>
>>> Any ideas what I'm doing wrong?
>>>
>>> Thanks for help.
>>>
>>> --
>>> 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.

clojure.spec - s/and interferes with regular expressions

[Mark Engelberg]

I'm having trouble spec'ing out something like this, a function that takes
an integer as an input followed by a series of optional keyworded args.
:even is an allowed optional keyword, but we definitely want to forbid :odd
as an optional keyword.

(s/def ::even even?)
(s/def ::options
  (s/and
(s/keys* :opt-un [::even])
(fn [m] (not (contains? m :odd)

(defn f [n & {:as options}] nil)
(s/fdef f :args (s/cat :integer int? :options ::options))
(stest/instrument `f)

This doesn't work at all and gives all sorts of errors when f is called
with any input. I believe it is because the use of s/and in the definition
of ::options interferes with the ability of ::options to be "flattened"
into the s/cat definition.

My reasoning:
::options correctly validates [:even 2] and rejects [:even 2 :odd 3] and
[:even 3].
If I omit the s/and and the second clause so that it reads:
(s/def ::options (s/keys* :opt-un [::even]))
this also behaves as expected.

So my conclusion is that the s/and is interfering with the ability of
s/keys* to sit within the s/cat definition.

How does one solve this problem?

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

[Mark Engelberg]

Years ago, Christophe Grand wrote a blog post about how to achieve flatter,
clearer, less-nested code by using a special version of Clojure's cond that
supported :let clauses (just like Clojure's for comprehensions), as well as
:when-let.

I've been using that code on a daily basis ever since, copying it from one
project to another.

For example, here's some code I wrote just today:

(defn- row-type [row]
  (if (set? row) ::row-seq
(loop [row (seq row), seen (transient #{})]
  (b/cond
(not row) nil
:let [item (first row)]
(not (number? item)) ::row-seq
(and (not (== item 0)) (not (== item 1))) ::row-seq
(seen item) ::matrix
:let [seen (conj! seen item)]
(recur (next row) seen)

There's been a JIRA issue for this for 7 years (
http://dev.clojure.org/jira/browse/CLJ-200), but this feature hasn't yet
made it into Clojure.  That doesn't affect me too much, since I can just
keep using this improved cond in my own source.  But it *does *affect me
when I want to share my code with others, for example, in my open-source
projects.  To avoid confusing other people, I've tried to avoid using this
improved cond in my open-source projects, but once you're used to using
:let inside of cond, it's downright painful to go without, and that pain
was actually stopping me from releasing some of my programs as open-source.

So, in order to begin releasing projects that use this better cond, I've
put better-cond into Clojars.  My convention is that in open-source code,
I'm qualifying the cond with a namespace alias like b/cond as a flag to
readers of the code that this might not be the cond they expect.  In my own
code, I just exclude Clojure's cond (as well as if-let and when-let, for
which improved versions are also offered in this library), and `use` them
directly at the top of every namespace, no qualifying necessary since they
function as drop-in replacements (no real performance hit since the
additional complexity occurs at macro-expansion time).  That way I don't
have to think about it, I just always have the better features at my
disposal.

Now that the library is in Clojars, that means you all can benefit from
this great improvement as well.  Try it, use it, get hooked!  Enjoy.

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

--Mark

P.S. 1.0.1 *removes* a feature from 1.0.0, namely a quirky syntax for
supporting if-let inside of cond, which I've never used, and just felt like
clutter.  But 1.0.0 works perfectly fine, so if that's the version number
that's easier for you to remember, by all means, use it.

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

[Mark Engelberg]

I should add that Dunaj already has this feature, so if you are a user of
Dunaj you do not need this library.

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

[Mark Engelberg]

Thanks for the pointer to your library, Jason.  I hadn't known about it.

In response to the interest and questions I've been getting about
better-cond, I've added a Rationale section to the README, and I've
mentioned your library in that section:

https://github.com/Engelberg/better-cond#rationale


On Fri, Jul 1, 2016 at 7:22 AM, Jason Felice 
wrote:

> You've got me thinking whether there's a more general thing which could be
> done for packthread: (https://github.com/maitria/packthread).
>
> Hrmm...
>
>

-- 
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] Release 0.35.0 of Counterclockwise

[Mark Engelberg]

Thank you!

On Sat, Jul 9, 2016 at 2:09 PM, Laurent PETIT 
wrote:

> Counterclockwise, the Eclipse Clojure development tool.
>
> Counterclockwise 0.35.0 has been released.
>
> Highlights:
>
> - Eclipse Neon Support
>
> This is the first version which requires Java 8
>
> ChangeLog
> =
>
>
> http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_34_0_and_0_35_0
>
> Installation instructions
> ==
>
> http://doc.ccw-ide.org/documentation.html#_install_counterclockwise
>
> Cheers,
>
> --
> Laurent Petit
>
> --
> 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.

Thoughts on clojure.spec

[Mark Engelberg]

I've played around now with implementing specs for a couple of my projects.

What I'm finding is that writing specs to check the inputs of a function is
easy-ish, but building useful random generators is very hard -- in my
projects, this seems too hard to do with any reasonable amount of effort.

This isn't due to anything inherent in clojure.spec, it's just that for
non-trivial functions, coming up with relevant random input is a very hard
problem.  For example, let's say I have a function that takes two
integers.  Odds are that not any two randomly chosen integers will work.
Some combinations of integers are non-sensical and could trigger an error,
other combinations may cause the function to run way too long.  As a
concrete example, I just tried to spec out a SAT solver (which tries to
solve NP-complete problems).  The input should be a vector of vectors of
ints, but many combinations of inputs will just run forever.  How to
generate "good" SAT problems?  I have no idea.

So for the most part, I've ignored the generation aspect of specs because
it just feels like too much work.  But without the generators,
clojure.spec's utility is significantly diminished.

1. No way to test function output specs.  For documentation purposes, I
want to have an output spec on my function.  However, as far as I know,
after instrumentation-triggered checking of output specs was removed a
couple of alphas ago, the only way remaining to check against output specs
is to use randomly generated tests.  So if I can't make good generators, I
have no way to confirm that my output spec works the way I think it does.
My documentation could be totally out of touch with reality, and that
displeases me.

2. Limited ability for testing that functions take and receive what you
expect.  Whereas a static type system can prove certain properties about
whether functions are called with valid inputs, with spec, you only get
those guarantees if you pump a function with enough valid random data to
trigger the function calling all its callees with interesting combinations
of data.  But if I use the naive generators, the function will never even
complete with most of the randomly generated input, let alone call other
functions in a useful way.  And in many cases I don't see how to generate
something of better quality.

So looking back at my experiments, my preliminary impression is that by
adding specs to my public APIs, I've gained some useful documentation, and
I've given users the ability to instrument functions in order to get
high-quality assertion-checking of the inputs.  In some cases, the error
messages for bad input when instrumented are also more useful than I would
have otherwise gotten, but in some cases they aren't.  Overall, I've
struggled to write generators, and without them, the value proposition
isn't as great.

One other issue I've had, unrelated to generators, is that I'm struggling
to express higher-order type constraints, for example, this function takes
a vector v1 of anything and a vector v2 of anything, but the type of the
things in vector v1 better match the type of the things in vector v2.

What are other people finding?  Do you find it easy/hard to write
generators?  (If you think it's easy, I'd love to know your tricks).  Do
you find it easy/hard to read specs as a form of documentation about the
contract of a function?  Do you find it frustrating that there's no way to
turn on instrumentation of function outputs for manual testing?  Do you
feel your generators are providing sufficient code coverage when exercising
callee functions?

-- 
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: taking my clojure game to a higher level

[Mark Engelberg]

Sounds like you are ready for this book:
https://www.amazon.com/Clojure-Applied-Practice-Practitioner-Vandgrift/dp/1680500740

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

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

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

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]

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

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

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.

[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]

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.

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

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

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.

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.

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

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

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 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: [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: [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: [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: [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: 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: 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]

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

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

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

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.

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.