Re: Without breakloop not much of a REPL

[Andy Fingerhut]

There is no reason to merely imagine ... you can do it today.

Here is a transcript of Stuart Halloway's "REPL-Driven Development" talk
with links to sources that he mentions:
https://github.com/matthiasn/talk-transcripts/blob/master/Halloway_Stuart/REPLDrivenDevelopment.md

The part of that talk where he discusses a break facility in the REPL can
be found by searching that transcript for "Joy of Clojure", the book where
one implementation of this is given.

There is a link in the transcript to this repository, which has code you
can copy and paste into your own project, or utility library, etc.

https://github.com/joyofclojure/book-source/blob/master/first-edition/src/joy/breakpoint.clj

The source for the macro named `contextual-eval` is here:
https://github.com/joyofclojure/book-source/blob/master/first-edition/src/joy/macros.clj

Andy

On Mon, Feb 1, 2021 at 4:28 AM Nesvarbu Nereikia 
wrote:

> Thanks Brandon, what a productivity booster the breakloop wold be, huh?
> Basically would save you time and mental energy every time you sprinkle
> your code with print statements now.
>
> On Friday, January 29, 2021, Brandon R  wrote:
>
>> This may be the talk I was thinking of: https://vimeo.com/223309989
>>
>> On Fri, Jan 29, 2021 at 10:04 AM Brandon R 
>> wrote:
>>
>>> I believe what's described in that post is possible in Clojure, at least
>>> to an extent. I can't remember where I saw it described, but I think it was
>>> a talk by Stuart Halloway. IIRC you can configure Clojure to run
>>> clojure.main/repl when an exception is thrown, this puts you into a new sub
>>> repl with the lexical bindings at that point in execution. You can inspect
>>> things here and I believe change things. I'm not sure about continuing
>>> running with new values, but I'm guessing that's possible too.
>>>
>>> Maybe someone in this group can point to a good resource about this, as
>>> I didn't find it in a quick search.
>>>
>>> On Fri, Jan 29, 2021 at 6:09 AM SideStep 
>>> wrote:
>>>
 According to this post:
 https://mikelevins.github.io/posts/2020-12-18-repl-driven/

 Breakloop is a true differentiator for "real" REPLs. I can see how
 breakloop really is a game changer.

 Also, there is no breakloop in modern languages such as clojure, which
 is heralded for it's REPL driven development, craftsmans' playground, live
 coding etc...

 Is breakloop gone from modern REPL languages? Maybe it's not a big
 deal? Or is 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.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/clojure/6cbcc0e9-c8d6-42b1-a1ae-3d3b88fcdfb6n%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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/Q1NQU8M17qc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/CAB_6y6GsPfkRXWXrwrE6gHaCXr7hJxFK1zXBYp%3Dh5DRD7mFkrw%40mail.gmail.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
> 

Re: clojure.edn/read isn't spec compliant

[Andy Fingerhut]

Here is some possibly relevant information.

I suspect the reason that `(clojure.edn/read-string ":a:")` gives an error
is that Clojure's EDN reader implementation was originally developed as an
adaptation from Clojure's reader, and `(read-string ":a:")` also gives an
error.  The reference documentation for Clojure's reader here
https://clojure.org/reference/reader#_symbols says "Symbols beginning or
ending with ':' are reserved by Clojure.  A symbol can contain one or more
non-repeating ':'s".  That is likely why Clojure's reader gives an error
attempting to read ":a:".

Perhaps it was intended that the last sentence should be included in the
EDN specification, too.  I do not know.

My personal guess: the authors of the EDN specification and
implementation are content with their level of detail, and might not be
interested in making them 100% equivalent in all ways.  (This is only my
personal guess.  Realize that making specifications and implementations
match can be an exhausting and unrewarding process.)

Andy

On Sat, Oct 31, 2020 at 5:38 AM 'EuAndreh' via Clojure <
clojure@googlegroups.com> wrote:

> Sean Corfield  writes:
>
> > If you find valid EDN that a particular EDN reader fails to process
> > correctly, that's a bug. If you feed it invalid EDN, well, you may or may
> > not get an error or a value or...
>
> This is a good guideline. A valid edn reader should read valid edn, and
> the behaviour for "illegal" edn is unspecified. In fact, it is helping
> me to think about my own implementation. Good tip.
>
> Other than a few more "illegal" things that clojure.edn accepts, I have
> found a valid edn value that it doesn't:
>
> user=> (edn/read-string ":a:")
> Execution error at user/eval33 (REPL:1).
> Invalid token: :a:
>
> As per the spec, a keyword:
> "Keywords follow the rules of symbols, except they can (and must)
> begin with `:`"
>
> And for symbols:
> "`: #` are allowed as constituent characters in symbols other than
> as the first character."
>
> It follows that ":a:" is a valid keyword, as ":a#" is. The first
> produces an error, while the second is a valid keyword.
>
> From what we've discussed on this thread, this is a bug.
>
> Did I miss anything?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/87mu02607y.fsf%40euandre.org.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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/CAKvLtDbrr%2B-ZQwLi6vYEUiMePdUExh589ZPjCHV3MHxTkRt9eg%40mail.gmail.com.

Re: sort-by reverse order?

[Andy Fingerhut]

This document goes into fairly deep dive on other ways to do it, including
a gotcha on edge cases of using something like (comp - compare) that will
rarely if ever bite you, but some people may want to know about them to
avoid them.

https://clojure.org/guides/comparators

Andy

On Wed, Oct 14, 2020 at 7:58 AM Matthew O. Smith  wrote:

> Google brought this up in 2020
>
> Try
> (comp - compare)
>
>
>
> On Tuesday, December 23, 2014 at 10:04:35 AM UTC-7
> julian...@googlemail.com wrote:
>
>> That's awesome! (though I'm slightly surprised there isn't an easier
>> way).
>>
>> Thanks.
>>
>>
>> On Tuesday, 23 November 2010 21:03:37 UTC, Tyler Perkins wrote:
>>>
>>> Nice! And with just a bit more, we have a clean, sorting DSL:
>>>
>>> (def asc compare)
>>> (def desc #(compare %2 %1))
>>> ;;  compare-by generates a Comparator:
>>> (defn compare-by [& key-cmp-pairs]
>>>   (fn [x y]
>>>   (loop [[k cmp & more] key-cmp-pairs]
>>>  (let [result (cmp (k x) (k y))]
>>>   (if (and (zero? result) more)
>>>   (recur more)
>>>   result)
>>>
>>> (sort (compare-by :last-name asc, :date-of-birth desc) coll)
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/769d3b44-e1dc-43f4-8728-7ecfdce86e79n%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/CAKvLtDZEuD3%3DAzGW0HHC5-NGwbSba0hyUnLTn4vOPkWvWuGrgQ%40mail.gmail.com.

Re: Clojure API copyright assignment?

[Andy Fingerhut]

You ask: "I was not sure if the Eclipse license was only for the
implementation of the interpreter / compiler, or if it covers the language
API itself?"

If you are merely curious, then I don't know the answer.

If you have a significant investment of money and/or time depending upon
the answer to the question, then you should hire a good intellectual
property lawyer familiar with the case law in this area in your
jurisdiction, and ask them.

Are you asking: If I create an API-compatible implementation of Clojure
separately from the original, can I be sued by Clojure's creator, as Google
was sued by Oracle?  You can try to sue anyone for anything.  Will the case
be won or lost?  I have no idea.  See above.

Is it likely that Rich Hickey wants to sue people over such a reason?  If
they call the resulting thing they distribute "Clojure" in the USA, he has
a trademark on that name, and might legally block you from using that name,
and make you pick a different name.

There are other implementations of Clojure, or minor variations, released
under different names, and as far as I know Rich Hickey has no interest in
suing them.  e.g. sci, babashka

Andy

On Sun, May 24, 2020 at 7:52 AM Nicholas Papadonis <
nick.papadonis...@gmail.com> wrote:

> I was not sure if the Eclipse license was only for the implementation of
> the interpreter / compiler, or if it covers the language API itself?
>
> On Sunday, May 24, 2020 at 10:49:46 AM UTC-4, Hadil Sabbagh wrote:
>>
>> Clojure is covered by the Eclipse Public License 1.0.
>>
>> I hope this answers your question.
>>
>> On May 24, 2020, at 7:32 AM, Nicholas Papadonis 
>> wrote:
>>
>> There is a widely known case Oracle vs. Google on whether the syntax and
>> API of Java can be copyrighted or if it falls under fair use. When the
>> Clojure language specification was released the author became the copyright
>> holder. I'm assuming the copyright holder is Rich Hickey.  Does anyone
>> know if the copyright holder provided any license or copyright
>> assignment that allowed others to legally use of the language?  If not, has
>> the copyright holder considered providing such  device (MIT, Apache, GPL,
>> etc)?
>>
>> I ask because C and C++ assigned it's copyright to the ISO standards
>> committee which makes the copyright free for all to use. Interested in
>> Clojure's status.
>>
>> Thanks,
>> Nick
>>
>> --
>> 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
>> clo...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clo...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/c393de63-f219-49fe-99fe-f5ba1b32ded0%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/aeacb4e3-68bc-4a57-861b-b77bb1b1a584%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 

Re: Clojure API copyright assignment?

[Andy Fingerhut]

The implementation of Clojure on the JVM, and of ClojureScript, were both
initially written by Rich Hickey, and he released their implementations
under the Eclipse Public License version 1.0.  It says so in the first
couple of sentences of the readme here: https://github.com/clojure/clojure/

For ClojureScript, it says so in the last few sentences of the
ClojureScript README here: https://github.com/clojure/clojurescript

All contributions by others since then have been under a contributor's
agreement that assigns joint copyright of those contributions to Rich
Hickey, and the author, and all later versions have been released under the
same EPL v1.0 license.  You can see the contributor agreement here:
https://clojure.org/dev/contributor_agreement

That covers the implementation of Clojure and ClojureScript.

You mention a "Clojure language specification".  There is no separate
specification of the Clojure language, other than its implementation and
documentation published on clojure.org.

Andy

On Sun, May 24, 2020 at 7:45 AM Nicholas Papadonis <
nick.papadonis...@gmail.com> wrote:

> There is a widely known case Oracle vs. Google on whether the syntax and
> API of Java can be copyrighted or if it falls under fair use. When the
> Clojure language specification was released the author became the copyright
> holder. I'm assuming the copyright holder is Rich Hickey.  Does anyone
> know if the copyright holder provided any license or copyright assignment
> that allowed others to legally use of the language?  If not, has the
> copyright holder considered providing such  device (MIT, Apache, GPL, etc)?
>
> I ask because C and C++ assigned it's copyright to the ISO standards
> committee which makes the copyright free for all to use. Interested in
> Clojure's status.
>
> Thanks,
> Nick
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/c393de63-f219-49fe-99fe-f5ba1b32ded0%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/CAKvLtDbhkG%3D97xkhnvPQhgb8RHzwQz1d%3DdjWZ%3Di_2GuArt3OJA%40mail.gmail.com.

Re: [JOB] Software Engineer | Red Planet Labs | Fully distributed team

[Andy Fingerhut]

I suspect "radically change the economics of software development" means
"drastically reduce the cost to achieve any of a large set of goals we
believe our technology covers".  Reduce by how much?  Maybe they have
proposed answers to that question that they are willing to share publicly,
but such things can be difficult to quantify today, even with over 40 years
of world-wide experience of teams using different programming languages,
tools, processes, workflows, etc.

How do they propose to achieve this?  I would not be surprised if the
linked articles on the red-planet-labs web site might be the extent of the
public answers to that question.  Lots of startups remain in 'stealth' mode
for a while, being very very careful to let out details of what they are
doing, lest some other company use the ideas themselves and run with them.

Andy

On Fri, Feb 21, 2020 at 12:41 PM Don Waldhalm 
wrote:

> Please expound "radically change the economics of software development."
>
> On Thursday, February 20, 2020 at 2:01:33 PM UTC-5, Nathan Marz wrote:
>>
>> We're a well-funded startup building a new kind of software development
>> tool that will radically change the economics of software development.
>> We're backed by some amazing investors including Max Levchin, Naval
>> Ravikant, and Alexis Ohanian.
>>
>> Since our first round of hiring last year we've gotten the hang of
>> operating as a fully distributed team and are now ready to grow the team
>> further.
>>
>> Our technology is entirely in Clojure, and it pushes the boundaries of
>> what's possible with compilers, databases, and distributed systems. If
>> you'd be interested in joining, please reach out!
>>
>> *Website*: https://redplanetlabs.com/
>> *Blog post introducing company*:
>> https://medium.com/red-planet-labs/introducing-red-planet-labs-2a0304a67312
>> *How we operate as a fully distributed team*:
>> https://medium.com/red-planet-labs/why-fully-distributed-is-by-far-the-best-way-to-run-a-software-team-d99abfc0c700
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/7eb64aef-1cd0-43de-9f08-12fa004d782a%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/CAKvLtDb_zU7XRpM0z8E3gcandEoWYD1_tQ2PEZ6NGLn8xgcBjA%40mail.gmail.com.

Re: Two new transcripts available of talks by Rich Hickey

[Andy Fingerhut]

Interesting that the links went to somewhere on Slack.  I copied and pasted
the original message from the announcement I wrote on Clojurians Slack,
without realizing that might happen.  The links in this email should be
correct, without any Slack-ness in them:

https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureConcurrency.md

https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureForJavaProgrammers.md

Andy

On Mon, Dec 2, 2019 at 10:05 AM Anthony Leonard 
wrote:

> On Monday, December 2, 2019 at 6:29:24 AM UTC, Andy Fingerhut wrote:
> > Transcripts of two of Rich Hickey's oldest (and longest) talks are now
> published and available, included in a collection of many other talk
> transcripts.  The newest transcripts are:
> >
> >
> > (1) "Clojure Concurrency" from March 2008, where he introduced the
> fairly well known "ant colony" simulation program to demonstrate refs,
> transactions, and agents, here:
> https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureConcurrency.md
> >
> >
> > (2) "Clojure for Java Programmers" from June 2008, here:
> https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureForJavaProgrammers.md
> >
> >
> > That Github repository contains many other talk transcripts.
> >
> >
> >
> >
> > If you are interested in helping create transcripts of other talks that
> do not have one yet, I am happy to help edit/polish them if someone wants
> to volunteer creating a first draft of all or even part of another talk.
> Offer your time and coordinate efforts on any of the open Github issues for
> not-yet-transcribed talks in that same Github repo.
> >
> >
> >
> > Regards,
> > Andy Fingerhut
>
> Firstly - congratulations - this is a massive effort as these are much
> longer talks (more like evening sessions) than your average keynote
> presentations. Having done a little transcribing I know how arduous it is -
> good job and thanks!9
>
> Secondly the links didn't work for me. I think the text of the links is
> fine in the email but they link to somewhere on slack :)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/b25fbd78-6ea9-4bc0-a7ea-be73895d4515%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/CAKvLtDZoRO_fwE82C75CDXru0rsk27%2Bqs%3DecG1vtr28N-MAaFg%40mail.gmail.com.

Two new transcripts available of talks by Rich Hickey

[Andy Fingerhut]

Transcripts of two of Rich Hickey's oldest (and longest) talks are now
published and available, included in a collection of many other talk
transcripts. The newest transcripts are:

(1) "Clojure Concurrency" from March 2008, where he introduced the fairly
well known "ant colony" simulation program to demonstrate refs,
transactions, and agents, here:
https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureConcurrency.md
<https://slack-redir.net/link?url=https%3A%2F%2Fgithub.com%2Fmatthiasn%2Ftalk-transcripts%2Fblob%2Fmaster%2FHickey_Rich%2FClojureConcurrency.md>

(2) "Clojure for Java Programmers" from June 2008, here:
https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureForJavaProgrammers.md
<https://slack-redir.net/link?url=https%3A%2F%2Fgithub.com%2Fmatthiasn%2Ftalk-transcripts%2Fblob%2Fmaster%2FHickey_Rich%2FClojureForJavaProgrammers.md>

That Github repository contains many other talk transcripts.


If you are interested in helping create transcripts of other talks that do
not have one yet, I am happy to help edit/polish them if someone wants to
volunteer creating a first draft of all or even part of another talk. Offer
your time and coordinate efforts on any of the open Github issues for
not-yet-transcribed talks in that same Github repo.

Regards,
Andy Fingerhut

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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/CAKvLtDb%3Dq%3DvamtBX%2BS4vMk_F2VyF-UcOZ41knk9ZSbPy2fdp2w%40mail.gmail.com.

Re: 100x startup for Clojure using GraalVM

[Andy Fingerhut]

I believe at least some of the people working on this, and interested in
these results, would like to use Clojure for command line utilities and
such, which tend to have quite short run times when implemented in
C/C++/Python/etc.  They are probably much less interested in using these
methods for long-running server processes.

Andy

On Tue, Nov 12, 2019 at 8:46 PM 'Gerard Klijs' via Clojure <
clojure@googlegroups.com> wrote:

> Hello world is fun, but doesn't say much. I would like to see benchmarks
> on the actual application. Ideally it would take several jvm's so also
> Graal and J9 and also use the commercial version of making a native image,
> asses how much memory is needed when run on the JVM and limit that, since
> otherwise it will might take upto a quarter of available memory. Measures
> both the time to the first successful handled request from startup, the max
> throughput after being warmed up properly, the .99 percentile latency after
> being warmed up, and the memory use.
> Only if you have those numbers you could decide if a native image is worth
> it. For example if with the current load one instance with a native image
> could always handle the load, it might save a lot, because you can and to
> 0, where the total first request just take seconds. But if at loyal moments
> with a native image you need 30 instances, while on the JVM you need only 3
> it might not.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/bcc8f1d8-db0a-45f0-9d95-d280ae653fcc%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/CAKvLtDYgqxifgtagXKr192Dozhq3tG8oN%3D%3DjTBjXPbDO41PAkg%40mail.gmail.com.

Re: Why ('f 1) does deliver nil?

[Andy Fingerhut]

Both symbols and keywords, when placed inside of an expression in the first
position, e.g. (:my-keyword my-map), or ('some-symbol my-map), behave as
functions that "look themselves up" in the map that is the first argument,
and if that symbol or keyword is a key in that map, the associated value is
returned from the expression.  This is most often used for keywords, but it
does also work for symbols, which is what is happening in your expression.
The number `1` is not a map, and both this kind of lookup expression, as
well as the function `get`, have always returned nil when the
thing-to-be-looked-up-in is not a map or set (or anything else that
implements the appropriate lookup interface methods being used in the Java
implementation under the covers there).

Some other examples of similar behavior:

$ clj
Clojure 1.10.1
user=> ('f 1)
nil
user=> ('f 1 :not-found)
:not-found
user=> ('f {'f 17 :bar 8})
17
user=> ('f {:bar 8} :not-found-value)
:not-found-value
user=> (get {'f 17 :bar 8} 'f)
17
user=> (get 1 'f)
nil
user=> (get 1 'f :not-found)
:not-found

Andy



On Sat, Oct 26, 2019 at 10:05 AM Johannes  wrote:

> ... instead of an exception?
>
> Can anyone explain it to me?
>
> Johannes
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/f2007954-107c-4918-bf0a-6bfd8040ba39%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/CAKvLtDYiLJVXxCUTSsaHZXOTAzk4pYGk2%3DJ09Ac2MkYS8aXO5A%40mail.gmail.com.

[ANN] core.rrb-vector 0.1.1 -- eliminate a warning in ClojureScript version

[Andy Fingerhut]

I am pleased to announce the 0.1.1 release of core.rrb-vector, a Clojure
Contrib library extending the Clojure vector API with logarithmic-time
concatenation and slicing:

  https://github.com/clojure/core.rrb-vector

  [org.clojure/core.rrb-vector "0.1.1"]

  
org.clojure
core.rrb-vector
0.1.1
  

This release is nearly identical to the recent version 0.1.0 release.  The
only notable change is for the ClojureScript implementation, to avoid
causing the ClojureScript compiler to issue a warning.  I am not aware of
any functional bugs due to that warning, but it seemed best to clean up the
code there anyway.

Independent of that, I have added some benchmarks and extra documentation
related to the library since the 0.1.0 release, described in the change log:

  https://github.com/clojure/core.rrb-vector/blob/master/CHANGES.md

Cheers,
Michał Marczyk and Andy Fingerhut

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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/CAKvLtDapo1HztzQoVVzAHGXdbH3-q5NSutK3hu40OHPir1WKrg%40mail.gmail.com.

Re: [ANN] core.rrb-vector 0.1.0 -- bug fixes

[Andy Fingerhut]

Also, maybe you are doing this already, but note that you can save
significant memory in Clojure and core.rrb-vector by using (vector-of :char
...) to create vectors that are restricted to contain only char's, if that
is all you want to hold inside of them.  It is about a 3x more memory if
you use a normal Clojure vector of arbitrary Object's because of the boxing
of Character objects.  Same for :long and other vectors of primitives.

Andy

On Wed, Oct 2, 2019 at 6:31 AM Andy Fingerhut 
wrote:

> Excellent!  Please do file additional reports if you find any issues with
> the latest version.
>
> Andy
>
> On Wed, Oct 2, 2019 at 2:27 AM Terje Dahl  wrote:
>
>> Nice list of fixes. Great work!
>>
>> I use Vector as my text editor's char-buffer.
>> I believe I have seen one or more of the fixed bugs surface, so I am
>> upgrading immediately. :-D
>>
>>
>> Terje
>>
>>
>> On Monday, September 30, 2019 at 10:21:05 PM UTC+2, Andy Fingerhut wrote:
>>>
>>> I am pleased to announce the 0.1.0 release of core.rrb-vector, a Clojure
>>> Contrib library extending the Clojure vector API with logarithmic-time
>>> concatenation and slicing:
>>>
>>>   https://github.com/clojure/core.rrb-vector
>>>
>>>   [org.clojure/core.rrb-vector "0.1.0"]
>>>
>>>   
>>> org.clojure
>>> core.rrb-vector
>>> 0.1.0
>>>   
>>>
>>> This release fixes several bugs that were found in previous releases of
>>> the library.  More details can be found in the change log:
>>>
>>>   https://github.com/clojure/core.rrb-vector/blob/master/CHANGES.md
>>>
>>> Cheers,
>>> Michał Marczyk and Andy Fingerhut
>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to 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/cfed16b8-e941-45f3-95c1-3261e19e8340%40googlegroups.com
>> <https://groups.google.com/d/msgid/clojure/cfed16b8-e941-45f3-95c1-3261e19e8340%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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/CAKvLtDb5nBHVnd6FqWy__gfC4nd1o1iaNXzo8EyAwBME%3DmRfVQ%40mail.gmail.com.

Re: [ANN] core.rrb-vector 0.1.0 -- bug fixes

[Andy Fingerhut]

Excellent!  Please do file additional reports if you find any issues with
the latest version.

Andy

On Wed, Oct 2, 2019 at 2:27 AM Terje Dahl  wrote:

> Nice list of fixes. Great work!
>
> I use Vector as my text editor's char-buffer.
> I believe I have seen one or more of the fixed bugs surface, so I am
> upgrading immediately. :-D
>
>
> Terje
>
>
> On Monday, September 30, 2019 at 10:21:05 PM UTC+2, Andy Fingerhut wrote:
>>
>> I am pleased to announce the 0.1.0 release of core.rrb-vector, a Clojure
>> Contrib library extending the Clojure vector API with logarithmic-time
>> concatenation and slicing:
>>
>>   https://github.com/clojure/core.rrb-vector
>>
>>   [org.clojure/core.rrb-vector "0.1.0"]
>>
>>   
>> org.clojure
>> core.rrb-vector
>> 0.1.0
>>   
>>
>> This release fixes several bugs that were found in previous releases of
>> the library.  More details can be found in the change log:
>>
>>   https://github.com/clojure/core.rrb-vector/blob/master/CHANGES.md
>>
>> Cheers,
>> Michał Marczyk and Andy Fingerhut
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/cfed16b8-e941-45f3-95c1-3261e19e8340%40googlegroups.com
> <https://groups.google.com/d/msgid/clojure/cfed16b8-e941-45f3-95c1-3261e19e8340%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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/CAKvLtDbDXQHCb%2Bp0R8vo04PD5bALdk7%3DgyF-2_E4UDJf9rCD0w%40mail.gmail.com.

[ANN] core.rrb-vector 0.1.0 -- bug fixes

[Andy Fingerhut]

I am pleased to announce the 0.1.0 release of core.rrb-vector, a Clojure
Contrib library extending the Clojure vector API with logarithmic-time
concatenation and slicing:

  https://github.com/clojure/core.rrb-vector

  [org.clojure/core.rrb-vector "0.1.0"]

  
org.clojure
core.rrb-vector
0.1.0
  

This release fixes several bugs that were found in previous releases of the
library.  More details can be found in the change log:

  https://github.com/clojure/core.rrb-vector/blob/master/CHANGES.md

Cheers,
Michał Marczyk and Andy Fingerhut

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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/CAKvLtDbQoHXFaL3PTQPoeq5BWR-TgDPJi96QoWH8EMxx5hWXnA%40mail.gmail.com.

Re: Using :clojure.spec.alpha/invalid inside clojure.core macros throw exception

[Andy Fingerhut]

I do not know the specifics of this issue, but just because it was reported
in 2016 does not necessarily imply that the Clojure spec developers believe
it is a bug, rather than something than an unexpected corner case that some
spec users wish would behave differently.

Also, Rich Hickey and Alex Miller (and perhaps others I am unaware of) are
actively working on developing spec version 2.

Andy

On Wed, Sep 18, 2019 at 1:11 PM Peter Hull  wrote:

>
>
> On Wednesday, 18 September 2019 20:48:39 UTC+1, David Bürgin wrote:
>>
>> This is a known issue, see
>> https://clojure.atlassian.net/projects/CLJ/issues/CLJ-1966
>>
> 2016!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/6bfbcf08-eaf2-4bd4-ba96-f16f627f4380%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/CAKvLtDYcyouJMLH4G289x8dacFuEs65Vpwky3G2iSmrNQNFhfQ%40mail.gmail.com.

Re: records alias with local vars

[Andy Fingerhut]

I tried it on Clojure 1.10.1 and if I first did (set! *warn-on-reflection*
true) the defn of b did give a reflection warning if you first did the
defrecord, but not without the defrecord.

Andy

On Wed, Aug 28, 2019 at 6:35 PM Sean Corfield  wrote:

> What version of Clojure/Script are you using? This works fine for me on
> Clojure 1.10.1.
>
> On Wed, Aug 28, 2019 at 4:08 PM Brian Craft  wrote:
>
>> In this example
>>
>> (defrecord x [y])
>>
>> (defn b [x] (.getBytes ^String x))
>>
>>
>> The compiler fails to resolve .getBytes. It emits reflection code, saying
>> x is a class. It is resolved by deleting the defrecord, or renaming the
>> parameter.
>>
>> Is this expected, or documented? Are there other cases like this?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to 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/38933dc0-1b8e-452a-ae01-feec77739623%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles Networks, LLC. -- https://worldsinglesnetworks.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/CAD4thx9mFjG-5QvuiYK40JnOa%3DgiC4gvap4qkMiLpf0inZJCug%40mail.gmail.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/CAKvLtDZPz7OidY09JoWD-gcKiKxveD4RO7DPdRe71Z_-mae00g%40mail.gmail.com.

Re: Strange behavior with clojure.java.io/copy

[Andy Fingerhut]

Ah, I should have read further in the Java doc here, though, before
posting.  In particular, the last sentence of this paragraph: "If the
length of b is zero, then no bytes are read and 0 is returned; otherwise,
there is an attempt to read at least one byte. If no byte is available
because the stream is at the end of the file, the value -1 is returned;
otherwise, at least one byte is read and stored into b."

https://docs.oracle.com/javase/8/docs/api/java/io/InputStream.html#read-byte:A-

If implementations actually follow that documentation, then it appears that
a non-0 buffer size should never result in a return value of 0.

Andy

On Sun, Aug 25, 2019 at 9:54 PM Andy Fingerhut 
wrote:

> That bit of Java-Doc says nothing about the behavior when providing a
> buffer b with a non-0 length.
>
> If it said: "If the length of b is non-zero, then the return value will
> never be 0", then I might agree with you.  Also, if you knew for some
> reason that the implementation guaranteed this.  (I have not looked at the
> implementation to know either way.)
>
> Andy
>
> On Sun, Aug 25, 2019 at 9:21 PM 'Dirk Wetzel' via Clojure <
> clojure@googlegroups.com> wrote:
>
>> As alpeware already said, *.read* will not return [1024, 0, 1024, 201,
>> -1] because it will not return a zero unless *buffer-size* is zero.
>> This bit of the Java-Doc: If the length of b is zero, then no bytes are
>> read and 0 is returned;
>>
>> So if the check is changed to (<= 0 size), passing a *buffer-size* of 0
>> (for whatever silly reason) would result in an infinite loop.
>> While not my decision to make, I personally don't think that this would
>> be desirable behaviour.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to 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/9deb8024-ce4b-4ef4-88d0-bbd817152ab6%40googlegroups.com
>> <https://groups.google.com/d/msgid/clojure/9deb8024-ce4b-4ef4-88d0-bbd817152ab6%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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/CAKvLtDYjqzJrwphmVJWachsZVwd__Y0vcpUwymQNBx64q%3DROVA%40mail.gmail.com.

Re: Strange behavior with clojure.java.io/copy

[Andy Fingerhut]

That bit of Java-Doc says nothing about the behavior when providing a
buffer b with a non-0 length.

If it said: "If the length of b is non-zero, then the return value will
never be 0", then I might agree with you.  Also, if you knew for some
reason that the implementation guaranteed this.  (I have not looked at the
implementation to know either way.)

Andy

On Sun, Aug 25, 2019 at 9:21 PM 'Dirk Wetzel' via Clojure <
clojure@googlegroups.com> wrote:

> As alpeware already said, *.read* will not return [1024, 0, 1024, 201, -1] 
> because
> it will not return a zero unless *buffer-size* is zero.
> This bit of the Java-Doc: If the length of b is zero, then no bytes are
> read and 0 is returned;
>
> So if the check is changed to (<= 0 size), passing a *buffer-size* of 0
> (for whatever silly reason) would result in an infinite loop.
> While not my decision to make, I personally don't think that this would be
> desirable behaviour.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/9deb8024-ce4b-4ef4-88d0-bbd817152ab6%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/CAKvLtDagFDJ_XDpeFTv487jcVPLdeZXuCDnPFpPHdTM4NOXmRw%40mail.gmail.com.

Re: Shorter form to check if some words are contained in a sentence?

[Andy Fingerhut]

No tip or payment needed for me.  If at some point you desperately want to
toss some money to someone for Clojure, one possibility is to make periodic
small payments to Cognitect Labs, which also gives you access to a tool
called REBL that you may find useful at some point if you continue using
Clojure for development: https://www.patreon.com/cognitect/posts

The syntax #(.contains value %) creates an anonymous function that takes
one argument, and the % represents where the argument is used in the
function body.

If it makes more sense, you can replace it with (fn [x] (.contains value
x)), which will do the same thing.

Yes, every? and some are similar to each other, with every? doing the AND
of all individual function calls on the elements in the sequence, and some
doing the OR, and not only doing the OR, but also returning the value of
the first call that returns a logical true value (anything except nil or
false).

There are Clojurians Slack and ZulipChat chat channels called #beginners
that are also useful for getting started problems.

Andy


On Sat, Jun 22, 2019 at 11:41 AM Thad Guidry  wrote:

> Beautiful Andy!  Can you confirm that last syntax for me?
> I see it as treating the anonymous function of #(.contains value %) as the
> predicate to check on every member of the vector?
> But anonymous function expansion is what throws me off... I need layman's
> terms (grandma speak) to break down the logic there.  Specifically, there
> must be some wiring of the vector members to the % placeholder?
> Ahhh! I guess that what does that actual wiring is the every? function ...
> "for every x in coll"
> So this is just a simple every? invocation I guess.
> And I assume that some <https://clojuredocs.org/clojure.core/some>would
> be like an or/coalesce, kinda in my usecase ?
> (some #(.contains value %) ["CBS" "Bar" "cat"])
>
> It worked by the way. See screenshot attached.
>
> Still learning a few ropes on Clojure  (and I still can't get the stupid
> nrepl to initialize in my Visual Studio Code with leiningen
> <https://marketplace.visualstudio.com/items?itemName=avli.clojure>  so
> that doesn't help my learning when I don't have a real dev environment that
> I can learn Clojure against.  Would love someone to help me with that)
>
> Finally, how can I send you a tip or payment for this help?
> Thad
> https://www.linkedin.com/in/thadguidry/
>
>
> On Sat, Jun 22, 2019 at 12:38 PM Andy Fingerhut 
> wrote:
>
>> And, of course you can continue to use .contains:
>>
>> (every? #(.contains value %) ["CBS" "Bar" "cat"])
>>
>>
>>
>> On Sat, Jun 22, 2019 at 10:37 AM Andy Fingerhut 
>> wrote:
>>
>>> I haven't counted characters, but this would certainly become relatively
>>> shorter the more substrings you check for.  It is shown in the context of a
>>> Clojure REPL.  I do not know whether OpenRefine might already do the
>>> require for you, or perhaps even (use 'clojure.string).
>>>
>>> user=> (def value "Bar the cat from CBS")
>>> #'user/value
>>> user=> (require '[clojure.string :as str])
>>> nil
>>> user=> (every? #(str/includes? value %) ["CBS" "Bar" "cat"])
>>> true
>>>
>>> Andy
>>>
>>>
>>> On Sat, Jun 22, 2019 at 10:32 AM Thad Guidry 
>>> wrote:
>>>
>>>> Clojure is supported as an expression language in OpenRefine.  Where
>>>> any cells value in OpenRefine's datagrid is just accessed by the name
>>>> value.
>>>> Here's one of my cells value in OpenRefine...
>>>>
>>>> "001","878","245","$c","CBS Barmarick Publications,","$c","Emerald"
>>>>
>>>> and I am trying to see if that cells value contains all of these
>>>> words...
>>>>
>>>> (and (.contains value "CBS") (.contains value "Bar") (.contains value
>>>> "cat"))
>>>>
>>>> It works, but I am looking to Clojure experts to find out how to
>>>> shorten this expression?
>>>>
>>>> -Thad
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clojure@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+uns

Re: Shorter form to check if some words are contained in a sentence?

[Andy Fingerhut]

And, of course you can continue to use .contains:

(every? #(.contains value %) ["CBS" "Bar" "cat"])



On Sat, Jun 22, 2019 at 10:37 AM Andy Fingerhut 
wrote:

> I haven't counted characters, but this would certainly become relatively
> shorter the more substrings you check for.  It is shown in the context of a
> Clojure REPL.  I do not know whether OpenRefine might already do the
> require for you, or perhaps even (use 'clojure.string).
>
> user=> (def value "Bar the cat from CBS")
> #'user/value
> user=> (require '[clojure.string :as str])
> nil
> user=> (every? #(str/includes? value %) ["CBS" "Bar" "cat"])
> true
>
> Andy
>
>
> On Sat, Jun 22, 2019 at 10:32 AM Thad Guidry  wrote:
>
>> Clojure is supported as an expression language in OpenRefine.  Where any
>> cells value in OpenRefine's datagrid is just accessed by the name value.
>> Here's one of my cells value in OpenRefine...
>>
>> "001","878","245","$c","CBS Barmarick Publications,","$c","Emerald"
>>
>> and I am trying to see if that cells value contains all of these words...
>>
>> (and (.contains value "CBS") (.contains value "Bar") (.contains value
>> "cat"))
>>
>> It works, but I am looking to Clojure experts to find out how to shorten
>> this expression?
>>
>> -Thad
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to 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/c37eb1b0-1557-486b-b95a-a5bc53b67b24%40googlegroups.com
>> <https://groups.google.com/d/msgid/clojure/c37eb1b0-1557-486b-b95a-a5bc53b67b24%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAKvLtDZxWM49qu-CCt-Lzn%3DCiQq%3DQy9MeY0kWV0tP4eHJknVbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shorter form to check if some words are contained in a sentence?

[Andy Fingerhut]

I haven't counted characters, but this would certainly become relatively
shorter the more substrings you check for.  It is shown in the context of a
Clojure REPL.  I do not know whether OpenRefine might already do the
require for you, or perhaps even (use 'clojure.string).

user=> (def value "Bar the cat from CBS")
#'user/value
user=> (require '[clojure.string :as str])
nil
user=> (every? #(str/includes? value %) ["CBS" "Bar" "cat"])
true

Andy


On Sat, Jun 22, 2019 at 10:32 AM Thad Guidry  wrote:

> Clojure is supported as an expression language in OpenRefine.  Where any
> cells value in OpenRefine's datagrid is just accessed by the name value.
> Here's one of my cells value in OpenRefine...
>
> "001","878","245","$c","CBS Barmarick Publications,","$c","Emerald"
>
> and I am trying to see if that cells value contains all of these words...
>
> (and (.contains value "CBS") (.contains value "Bar") (.contains value
> "cat"))
>
> It works, but I am looking to Clojure experts to find out how to shorten
> this expression?
>
> -Thad
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/c37eb1b0-1557-486b-b95a-a5bc53b67b24%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAKvLtDa49XSNFjsA53ou7hcMmMnLeyKe94p_fHR%2BdbGxVA6kzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Compiler error message misses the target

[Andy Fingerhut]

You can check with Alex Miller if you have doubts, but given that error
messages, and in particular the one you show, is at this moment an area of
active changes in Clojure 1.10.1 beta versions, they may be open to fixes
to such things right now.

Andy

On Tue, May 7, 2019 at 9:21 PM Alan Thompson  wrote:

> 
>
> So I get a strange error from the compiler after a few minor edits:
>
> Syntax error compiling at (tupelo/forest.clj:7:1).
> Unable to resolve symbol: d in this context
> Full report at: /tmp/clojure-18236661144073611223.edn
>
>
> with the following EDN message:
>
> {:clojure.main/message
>  "Syntax error compiling at (tupelo/forest.clj:7:1).\nUnable to resolve
> symbol: d in this context\n",
>  :clojure.main/triage
>  {:clojure.error/phase :compile-syntax-check,
>   :clojure.error/line 7,
>   :clojure.error/column 1,
>   :clojure.error/source "forest.clj",
>   :clojure.error/path "tupelo/forest.clj",
>   :clojure.error/class java.lang.RuntimeException,
>   :clojure.error/cause "Unable to resolve symbol: d in this context"},
>  :clojure.main/trace
>  {:via
>   [{:type clojure.lang.Compiler$CompilerException,
> :message "Syntax error compiling at (tupelo/forest.clj:7:1).",
> :data
> {:clojure.error/phase :compile-syntax-check,
>  :clojure.error/line 7,
>  :clojure.error/column 1,
>  :clojure.error/source "tupelo/forest.clj"},
> :at [clojure.lang.Compiler analyze "Compiler.java" 6808]}
>{:type java.lang.RuntimeException,
> :message "Unable to resolve symbol: d in this context",
> :at [clojure.lang.Util runtimeException "Util.java" 221]}],
>
> .
>
> and I figure I accidentally got a typo somewhere.  Look at the top of the
> file:
>
> [image: Screenshot from 2019-05-07 21-08-39.png]
> Hmmm, no stray characters there...
>   head-scratching, finally looks at random near edit site...Ah ha!>
> Oh, look at this on line 159:
> [image: Screenshot from 2019-05-07 21-12-11.png]
>
> So, I got a random character inserted, and the compiler directs me to a
> line 152 lines away from the actual error location.  Any we wonder why
> Clojure has slow adoption
>
> 
>
> I could probably figure out a fix for problems like this, but I'm worried
> that it wouldn't be accepted.
>
> Alan
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/CAN67zA1vrk_%2BTx0LcmznPNnZzW7GZFsOGaSn1AdWWJ1Fyc%2BZGg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAKvLtDZUj5Ne0A%3D-M_70Yj9KwUnJevmaiypo_dE5gacCH6ac_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Developing Closure in 2019 on Windows 10 or using Windows - WSL/Linux.

[Andy Fingerhut]

Sorry, I do not know the answer to your questions.

There are multiple relevant channels on the Clojurians Slack [1] and
Zulipchat [2] servers where you may get quicker feedback.

On Slack, for example, there is a #clj-on-windows channel, #beginners, and
#cursive

[1] https://clojurians.slack.com
[2] https://clojurians.zulipchat.com


On Fri, Mar 15, 2019 at 10:22 PM Eric Calonico <
eric.calonico.ci...@gmail.com> wrote:

> I am trying o Windows for now, I got lein running with closure working but
> I cannot connect to intellij/Cursive, does anyone know?
>
> Em sexta-feira, 15 de março de 2019 19:44:41 UTC-3, Eric Calonico escreveu:
>>
>> Hi everyone,
>>
>> How are you?
>>
>> I finally just signed in on the Eric's Normand with his help on 
>> *https://purelyfunctional.t
>> v
>>  *and I
>> will learn Closure.
>>
>> I was wondering the best possible environment for Closure on Windows 10.
>>
>> Using WSL or on Windows?
>>
>> What's more, using WSL how do I configure Intellij with Cursive for
>> working on WSL?
>>
>> Intellij+Cursive is better than Emacs and VScode with closurevscode.
>>
>> What about another plugin for the (( ))
>>
>> Lein?
>>
>> Sorry for all the newbie questions but all posts I found about this are
>> 2017,16 and I was wondering if there is a better solution.
>>
>> 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: Clojure 1.10 "Illegal Reflective Access Operation"

[Andy Fingerhut]

I believe this FAQ entry covers what is known about this issue, which many
others have also seen: https://clojure.org/guides/faq#illegal_access

Andy

On Sun, Feb 24, 2019 at 4:48 PM Alan Thompson  wrote:

> Upgrading from Clojure 1.9 to 1.10, I am getting a new warning:
>
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> clojure.lang.InjectedInvoker/0x000800231c40
> (file:/home/alan/.m2/repository/org/clojure/clojure/1.10.0/clojure-1.10.0.jar)
> to method
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(org.xml.sax.InputSource,org.xml.sax.HandlerBase)
> WARNING: Please consider reporting this to the maintainers of
> clojure.lang.InjectedInvoker/0x000800231c40
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
>
>
> Using Java 11 on Ubuntu 16.04.  Should I file an issue for this?
> Alan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: crossclj.info unavailable ???

[Andy Fingerhut]

The creator of the site announced on on 2018-Dec-22 that he would be
shutting it down:
https://www.reddit.com/r/Clojure/comments/a99jwn/crossclj_is_shutting_down/


The issue is not lack of funds, but lack of his time/interest to continue
updating it, and not wanting it to gradually become more and more out of
date.

He has published the source code he used to generate the site, but note
that it is not always a simple push-and-click to update the site to index
later versions of source code -- the analysis programs sometimes require
updating and/or bug fixing in order to work on new code bases.

Anyone sufficiently interested could set up another similar site, perhaps
starting from the existing published code.  I suspect the original
publisher would be willing to transfer the domain if you wanted to use the
same domain name, but you would have to contact them to know for sure.

Andy


On Wed, Feb 6, 2019 at 3:38 PM Alan Thompson  wrote:

> Trying to hit http://crossclj.info (Ubuntu 16.04 + Chrome) yields:
>
>
> This site can’t provide a secure connection
>
> *crossclj.info * sent an invalid response.
> ERR_SSL_PROTOCOL_ERROR
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: (gen/sample (s/gen #{'nil})): Couldn't satisfy such-that predicate

[Andy Fingerhut]

Sometimes text in comments in ClojureDocs.org examples can be more useful
than the examples.  They are effectively longer (unofficial) doc strings.

Andy

On Thu, Jan 31, 2019 at 5:36 AM Alex Miller  wrote:

> Go for it. Not sure the type stuff is adding anything in the context of
> quote examples here beyond the other explanation though.
>
> On Thu, Jan 31, 2019 at 6:50 AM Rostislav Svoboda <
> rostislav.svob...@gmail.com> wrote:
>
>> Hi Alex,
>>
>> > quote is a special form that returns the value you pass it, without
>> evaluation
>>
>> Aah! "without evaluation" is the key! Now it makes sense. Yea you
>> mentioned it before already, but it takes twice the effort to undo and
>> re-comprehend an acquired misconception. Thank you so much!
>>
>> Would you mind if I add this example to
>> http://clojuredocs.org/clojure.core/quote ?
>> It's basically your explanation in the REPL.
>>
>> ;; Quote returns the argument you pass it, without evaluation. So:
>> ;; In the expression `(quote 42)` the argument is the number 42 and...
>> user> (= (quote 42) 42)
>> true ;; ... it is returned without any evaluation and...
>> user> (= (type (quote 42)) (type 42) java.lang.Long)
>> true ;; ... as expected, without changing it's type.
>>
>> ;; In the expression `(quote (quote 42))` the argument is the list of
>> two elements
>> ;; `(quote 42)` and...
>> user> (= (quote (quote 42)) (list (read-string "quote") (read-string
>> "42")))
>> true ;; ... and it is returned without any evaluation and...
>> user> (= (type (quote (quote 42))) (type (list "1st-elem" "2nd-elem"))
>>  clojure.lang.PersistentList)
>> true ;; ... again, without changing it's type.
>>
>>
>> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/K74chBn4Pis/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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: Invalid-token when dereferencing namespaced keywords.

[Andy Fingerhut]

I believe the original intent was that keywords with a digit immediately
after the colon would not be supported, but due to a bug in the Clojure
reader they were permitted.  There was a brief time in 2013 where this bug
was fixed, but there were enough extant Clojure code bases that used such
keywords, that the change was reverted.  See the comments on the Clojure
ticket below for some history:

https://dev.clojure.org/jira/browse/CLJ-1252

I believe that this bug has never existed for namespaced keywords, and I am
not aware of any desire to change Clojure to allow such keywords.

Andy


On Tue, Jan 29, 2019 at 5:12 PM Philip Markgraf  wrote:

> Thank you. I apologize that my condensed example was in error. (Is the
> error you are showing that you can't create a namespaced keyword in a
> namespace you are not in?)
>
> However, the condition I originally describe occurs when the original
> namespace is properly created with ns:
>
> user=> (ns name1)
> nil
> name1=> (def ex1 {:015-00 "1"})
> #'name1/ex1
> name1=> (def ex2 {::015-00 "2"})
> #'name1/ex2
> name1=> (::015-00 ex2)
> "2"
> name1=> (ns name2)
> nil
> name2=> (::name1/015-00 name1/ex2)
>
> Syntax error reading source at (REPL:1:16).
> Invalid token: ::name1/015-00
> Syntax error reading source at (REPL:1:27).
> Unmatched delimiter: )
> name2=>
>
>
>
> On Tuesday, January 29, 2019 at 4:49:54 PM UTC-8, Justin Smith wrote:
>>
>> you are misusing the :: alias resolution operator, user is not an alias
>>
>> Clojure 1.9.0
>> (ins)user=> (ns foo)
>> nil
>> (ins)foo=> ::user/a
>> RuntimeException Invalid token: ::user/a
>> clojure.lang.Util.runtimeException (Util.java:221)
>> (ins)foo=> :user/a
>> :user/a
>>
>> On Tue, Jan 29, 2019 at 2:52 PM Philip Markgraf 
>> wrote:
>> >
>> > I am moving some code to use spec and namespaced keywords under Clojure
>> 1.10.0 (release). One group of keywords starts with a numeric character
>> after the colon, which has worked fine in the non-namespaced context.
>> Creating and using the namespaced keyword works correctly in the local
>> namespace (using only the double-colon), but fails with "Invalid Token"
>> when dereferencing from another workspace.
>> >
>> > I'm not sure if this is a bug or if I have been taking advantage of an
>> undocumented/unsupported feature.
>> > Having a leading-digit keyword has been very useful, as the names are
>> an exacting fit of the problem domain and don't suffer from the addition of
>> any visual pollution.
>> >
>> > user=> (def example-a {:015-00 "015-00"})
>> > #'user/example-a
>> > user=> (def example-b {::015-00 "015-00"})
>> > #'user/example-b
>> > user=> (:015-00 example-a)
>> > "015-00"
>> > user=> (:015-00 example-b)
>> > nil
>> > user=> (::015-00 example-b)
>> > "015-00"
>> > user=> (::015-00 example-a)
>> > nil
>> > user=> (ns try)
>> > nil
>> > try=> (:015-00 user/example-a)
>> > "015-00"
>> > try=> (::user/015-00 user/example-b)
>> >
>> > Syntax error reading source at (REPL:1:15).
>> > Invalid token: ::user/015-00
>> > Syntax error reading source at (REPL:1:31).
>> > Unmatched delimiter: )
>> > try=>
>> >
>> > The current behavior is certainly inconsistent, even if it is not a
>> serious bug.
>> >
>> > Thank you!
>> >
>> >
>> > --
>> > 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

Re: Noob question on the --> macro implementation

[Andy Fingerhut]

When you ask "am I right?" about your proposed change, what is it that the
current behavior does not do, that your change would do?  Do you have some
use case in mind that works with your change, but doesn't with the current
implementation?

Andy

On Sat, Jan 26, 2019 at 10:50 AM Ujjwal Thaakar 
wrote:

> Hi,
> I'm trying to learn Clojure and I just curiously typed
> (source ->>)
>  in the REPL and was wondering about this:
> https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784
>
> Am I missing something?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Learn Clojure - Syntax Test your knowledge No4. question.

[Andy Fingerhut]

If in a Clojure REPL session you type `(doc find-doc)`, you should see this
(I'm using Clojure 1.10 here, in case the doc string has changed in a
recent Clojure version):

ser=> (doc find-doc)
-
clojure.repl/find-doc
([re-string-or-pattern])
  Prints documentation for any var whose documentation or name
 contains a match for re-string-or-pattern
nil

That says that if I do `(find-doc "some-string")` or `(find-doc
#"some-regular-expression")`, it will scan through the names and
documentation of all vars looking for something that matches, and print it.

For example, if I am looking for something relevant to "stack", try
`(find-doc "stack")` and see what comes out.

Andy

On Sat, Jan 19, 2019 at 6:10 AM Dervish  wrote:

>
>1.
>
>Using find-doc, find the function that prints the stack trace of the
>most recent REPL exception.
>
> what does this mean?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Why did this compile? It's an obvious syntax mistake

[Andy Fingerhut]

If you can provide the entire file that compiled with the mistake in it,
that might help provide valuable context, especially if someone else can
reproduce it locally.

>From what you have described, if the only difference between two files is
that one has a ] and the other has that one character deleted, and it isn't
commented out or inside of a string, I can think of no way that both of
those files have correctly balanced square brackets, and thus one or the
other seems like it should give an error when trying to compile.

Do you have something in your development environment that might be
automatically balancing expressions for you?

Andy

On Wed, Dec 26, 2018 at 8:59 AM  wrote:

> I'm wondering why this compiled?
>
> I was supposed to add this to my requirements:
>
> [environ.core :refer [env]]
>
> Instead I added this:
>
> [environ.core :refer [env]
>
> I rebuilt this, and it compiled. Then, in the cider REPL, I tried to call
> my "start" function. I was told it didn't exist, which was a big surprise,
> since I was looking right at it.
>
> It took me a few minutes to track down the problem. The problem was the
> missing "]". Okay, easy to fix, but why did it compile?
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: error in process filter: Stack overflow in regexp matcher

[Andy Fingerhut]

I would recommend trying to temporarily rename ~/.lein/profiles.clj to a
different name, so that there is no such file with that name any more, and
try your file-seq expression again to see if it behaves any differently.

Andy

On Mon, Dec 24, 2018 at 1:38 PM nenad mitrovic 
wrote:

> Sorry, here is profiles.clj
>
> {:user
>   {
>   :java-cmd "C:\\Program Files\\Java\\jdk1.8.0_111\\bin\\java.exe"
>   :plugins [
>
> [cider/cider-nrepl "0.8.1"]
> [luminus/lein-template "2.9.9.2"]
>
> ]
>}
>  }
>
> On Monday, December 24, 2018 at 10:12:04 PM UTC+1, nenad mitrovic wrote:
>>
>> I am trying to execute this piece of code: (rest (file-seq (file (str
>> "corpus/" "ham"))).
>> When I execute I get this error: "error in process filter: Stack overflow
>> in regexp matcher".
>> I have 1400 files in corpus/ham folder. But when I execute only three
>> file it works.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: error in process filter: Stack overflow in regexp matcher

[Andy Fingerhut]

I have just tried to reproduce a similar case on a system running Mac OS X
10.13.6, Oracle/Apple Java 1.8.0_192, Clojure 1.9.0, and Leiningen 2.8.3,
and a directory containing 1400 files.  I did not see the error you did.

What versions of OS, Java, Clojure, and anything on top of Clojure (e.g.
Leiningen) are you using?

If you are using Leiningen, what is the contents of your
~/.lein/profiles.clj and project.clj files, if any?  Some add-on plugins
that modify what is shown in the REPL, e.g. that auto-pretty-print results,
can have errors parsing some input, or printing some output, even if
Clojure by itself has no problems.  If you can reproduce your problem using
a `clj` command line that avoids using Leiningen, for example, that would
help determine whether it is caused by something in your Leiningen setup,
vs. elsewhere.

Andy

On Mon, Dec 24, 2018 at 1:12 PM nenad mitrovic 
wrote:

> I am trying to execute this piece of code: (rest (file-seq (file (str
> "corpus/" "ham"))).
> When I execute I get this error: "error in process filter: Stack overflow
> in regexp matcher".
> I have 1400 files in corpus/ham folder. But when I execute only three file
> it works.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 1.10 issue: thrown? no longer works on macros

[Andy Fingerhut]

Alex, just so I understand, are you saying that because of the
implementation of `(is (thrown-with-msg? ..))` and the changes to
exceptions in Clojure 1.10.0, that other Clojure programs that use `(is
(thrown-with-msg? ...))` may need to be updated to use something similar to
what you linked, in order to test the new Clojure 1.10.0 behavior?

Thanks,
Andy


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

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

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

[Andy Fingerhut]

I do not know if Leiningen is involved in the difference in the
reproduction project linked below yet (I am testing with the latest
Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg?
...` expression that gives no error when running 'lein test' with Clojure
1.9.0, but does with Clojure 1.10.0.  I do not know if it is the same root
cause as Mark's example or not, but wanted to create this in hopes it
represents a minimal test case to reproduce the behavior difference.

https://github.com/jafingerhut/clojure-110-is-thrown

Andy

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

> In particular, I am challenging this assertion from the original post:
>
> However, the following test (using is from clojure.test) used to work
> prior to 1.10, but now fails:
>
> => (is (thrown? AssertionError (f true)))
> Unexpected error (AssertionError) macroexpanding f at
> (test:localhost:62048(clj)*:268:56).
> Assert failed: (number? x)
>
>
> When I do this on 1.9 I see:
>
> user=> (is (thrown? AssertionError (f true)))
> CompilerException java.lang.AssertionError: Assert failed: (number? x),
> compiling:(NO_SOURCE_PATH:20:29)
>
>
> Which is printed differently but is the same behavior, because this is
> happening while expanding the is, not during execution.
>
> I believe you're seeing a change in your test suite, I'm just having a
> hard time reproducing what you're seeing.
>
>
> On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote:
>>
>> This particular example given fails in a similar way on 1.9. Could you
>> give me something closer to what you are actually seeing in your test
>> suite? Specifically something that is a passing clojure.test test on 1.9
>> but a failure/error on 1.10?
>>
>> The problem with the given example is that it fails during macroexpansion
>> of the test itself, not during test execution, and I don't think that's the
>> case you're trying to replicate.
>>
>> On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote:
>>>
>>> I think the relevant change here is that exceptions thrown during
>>> macroexpansion are now wrapped into CompilerExceptions as a way to attach
>>> all of the source context information. The REPL understands this and still
>>> prints the original cause so the printing hides some of that structure (but
>>> you can see it by looking at the exception chain).
>>>
>>> This here is a particularly tricky case here though and I think there
>>> might be something else coming into play, still looking at it. There was a
>>> couple other changes inside the compiler exception handling that might also
>>> be coming into play.
>>>
>>> (Would have been great to see this during a pre-release build rather
>>> than after release! ;)
>>>
>>>
>>> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote:

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

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

> I'm not sure, but probably it behaves so because of throwing at
> macroexpand stage.
>
> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler
> написал:
>>
>> Consider the following macro:
>>
>> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5))
>> => (f 3)
>> 8
>> => (f true)
>> Unexpected error (AssertionError) macroexpanding f at
>> (test:localhost:62048(clj)*:265:28).
>> Assert failed: (number? x)
>>
>> So, as expected it throws an AssertionError if passed a non-number.
>> However, the following test (using is from clojure.test) used to work
>> prior to 1.10, but now fails:
>>
>> => (is (thrown? AssertionError (f true)))
>> Unexpected error (AssertionError) macroexpanding f at
>> (test:localhost:62048(clj)*:268:56).
>> Assert failed: (number? x)
>>
>> What's odd is that the macro still throws an AssertionError, but the
>> `thrown?` inside the `is` is no longer intercepting the AssertionError, 
>> so
>> the test doesn't pass -- instead the error causes a failure in the test
>> suite.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the 

Re: (float 0.819869321599107) = 0.81986934 ?

[Andy Fingerhut]

The rounding of floats and doubles is _not_ in decimal digits.  It is
internally implemented in binary, so the rounding behavior you see, while
it might not make much sense when written in decimal, probably makes
perfect sense if you write it in the IEEE binary format.

Andy

On Sat, Dec 15, 2018 at 2:21 PM ru  wrote:

> I have to use float in one application.
> I just thought that a reasonable implementation of the float function
> could use the rounding we were used to, that is, (float
> 0.819869321599107) = 0.81986932
>
> суббота, 15 декабря 2018 г., 21:10:54 UTC+3 пользователь ru написал:
>>
>> Dear Clojure users and team!
>>
>> Please explain me this result:
>>
>> Ruslans-iMac:clojure ru$ lein repl
>>
>> nREPL server started on port 54147 on host 127.0.0.1 - nrepl://
>> 127.0.0.1:54147
>>
>> REPL-y 0.3.7, nREPL 0.2.12
>>
>> Clojure 1.8.0
>>
>> Java HotSpot(TM) 64-Bit Server VM 11.0.1+13-LTS
>>
>> 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=> (float 0.819869321599107)
>>
>> 0.81986934
>>
>> user=>
>>
>>
>> Thanks in advance.
>>
>>
>> Sincerely,
>>
>>   Ru
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: (float 0.819869321599107) = 0.81986934 ?

[Andy Fingerhut]

As mentioned in other responses, floating point numbers are usually
approximations, with round-off error in the least significant digits (both
floats and doubles do this, with more digits of precision for doubles, at
the cost of more storage in memory).

Depending on how deeply you want to dive into the details of this, this
article may interest you: "What Every Computer Scientist Should Know About
Floating-Point Arithmetic"
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

There is a whole field of study called "numerical analysis" where people
study and quantify how much error can be introduced in programs that
calculate using floating point values in different ways.  Two programs that
according to algebra will calculate the same value, can calculate values
with much different 'error ranges' from each other:
https://en.wikipedia.org/wiki/Numerical_analysis   There are Fortran
libraries that are used _because_ the language specifies the order of
operations and how they relate to the source code, so the programmer has
control over such things, i.e. the compiler is _not allowed_ to make
certain kinds of transformations that may appear equivalent to the source
code according to the usual rules of algebra.

Andy

On Sat, Dec 15, 2018 at 10:11 AM ru  wrote:

> Dear Clojure users and team!
>
> Please explain me this result:
>
> Ruslans-iMac:clojure ru$ lein repl
>
> nREPL server started on port 54147 on host 127.0.0.1 - nrepl://
> 127.0.0.1:54147
>
> REPL-y 0.3.7, nREPL 0.2.12
>
> Clojure 1.8.0
>
> Java HotSpot(TM) 64-Bit Server VM 11.0.1+13-LTS
>
> 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=> (float 0.819869321599107)
>
> 0.81986934
>
> user=>
>
>
> Thanks in advance.
>
>
> Sincerely,
>
>   Ru
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Confusing Regex Behavior

[Andy Fingerhut]

The doc string for re-matches says that it
uses java.util.regex.Matcher.matches().  The Java doc page for the class
java.util.regex.Matcher [1] says "The matches

method
attempts to match the entire input sequence against the pattern."

The doc string for re-find says that it
uses java.util.regex.Matcher.find().  On [1] you can find the statement "
The find

method
scans the input sequence looking for the next subsequence that matches the
pattern."

I haven't dug into your regex and string in detail, but most likely what is
happening is that the regex matches part of the string, but it doesn't
match the _entire_ string.

Andy

[1] https://docs.oracle.com/javase/8/docs/api/java/util/regex/Matcher.html




On Tue, Dec 4, 2018 at 11:16 AM Randy J. Ray  wrote:

> I must be doing something wrong here, but I cannot figure this out.
>
> The following results in "nil" from re-matches:
>
> (re-matches #"\[((\d+)-(\d+)-(\d+) (\d\d):(\d\d))\] (.*)" "[1518-05-27
> 00:42] falls asleep\n")
>
> This, however, properly matches the line and produces the backreferences:
>
> (re-find (re-matcher #"\[((\d+)-(\d+)-(\d+) (\d\d):(\d\d))\] (.*)"
> "[1518-05-27 00:42] falls asleep\n"))
>
> I've used re-matches many times, but this has me stumped. This is behaving
> this way on both 1.8.0 and 1.9.0.
>
> Randy
> --
> Randy J. Ray - randy.j@gmail.com - twitter.com/rjray
> Silicon Valley Scale Modelers: http://www.svsm.org
> Sunnyvale, CA
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 to use defrecord getBasis to look up record instance field values

[Andy Fingerhut]

Maybe you are looking for something like this?

(map #(% p1) (map keyword (Person/getBasis)))

keyword can take a symbol as argument, and return a corresponding keyword.

Andy

On Sun, Dec 2, 2018 at 8:31 PM  wrote:

>
> defrecord Person [name age company])
>
> (def p1 {:name "foo", :age 27, :company :bar})
>
> (map #(% p1) (keys p1))
> ("foo" 27 :bar)
>
> user=> (map #(% p1) (Person/getBasis))
> (nil nil nil nil)
>
> user=> (map #(class %) (Person/getBasis))
> (clojure.lang.Symbol clojure.lang.Symbol clojure.lang.Symbol
> clojure.lang.Symbol)
>
> getBasis seems to return the symbol but my record lookup technique doesnt
> seem to be working..
>
> any idea why
>
> I dont wish to use keys on the record instance since the instance might be
> missing some fields in the record
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Received fatal alert: protocol_version

[Andy Fingerhut]

What are the outputs of 'java -version' and 'lein version' ?  What OS?

Some older versions of the JVM have older crypto certificates built into
them, which newer versions may improve upon.

Andy

On Thu, Nov 22, 2018 at 12:42 PM  wrote:

> Saw a suggestion here:
>
> https://github.com/technomancy/leiningen/issues/2364
>
> and tried it:
>
> LEIN_JVM_OPTS=-Dhttps.protocols=TLSv1.2 lein -U deps
>
> but got:
>
> Could not transfer artifact io.javalin:javalin:pom:2.4.0 from/to central (
> https://repo1.maven.org/maven2/): java.lang.RuntimeException: Unexpected
> error: java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
>
>
>
>
> On Thursday, November 22, 2018 at 3:37:31 PM UTC-5, lawrence...@gmail.com
> wrote:
>>
>> I've been away from Clojure for a year and I'm just coming back to it. I
>> assume some of my dependencies are out of date. I'm working on a project
>> that is 90% Java with a Clojure wrapper. I tried this:
>>
>> lein uber
>>
>> I got a "protocol version" error which seems to have something to do with
>> a new level of security at Maven.
>>
>> So I tried this:
>>
>>  LEIN_JVM_OPTS=-Dhttps.protocols=TLSv1.2   lein uber
>>
>> and got all this:
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGBUS (0xa) at pc=106510692, pid=66917, tid=123145404563456
>> #
>> # JRE version: 7.0-b222
>> # Java VM: OpenJDK 64-Bit Server VM (21.0-b17 mixed mode bsd-amd64
>> compressed oops)
>> # Problematic frame:
>> # J  clojure.lang.Symbol.equals(Ljava/lang/Object;)Z
>> #
>> # Failed to write core dump. Core dumps have been disabled. To enable
>> core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # An error report file with more information is saved as:
>> #
>> /Users/sugar/projects/vegetable/repos/cortex/cortext-clj/hs_err_pid66917.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   http://bugreport.sun.com/bugreport/crash.jsp
>> #
>> /usr/local/bin/lein: line 152: 66917 Abort trap: 6
>>  "$LEIN_JAVA_CMD" "${BOOTCLASSPATH[@]}" -Dfile.encoding=UTF-8
>> -Dmaven.wagon.http.ssl.easy=false -Dmaven.wagon.rto=1 $LEIN_JVM_OPTS
>> -Dleiningen.original.pwd="$ORIGINAL_PWD" -Dleiningen.script="$0" -classpath
>> "$CLASSPATH" clojure.main -m leiningen.core.main "$@"
>>
>>
>> Looking for some advice about the simplest way to get past this error?
>>
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.10.0-beta8

[Andy Fingerhut]

I suspect Alex and other folks have already done all of the bikeshedding
internally that they have the patience for, and are content with the name
and the reasons they ahve for it, and are not enthusiastic about another
round of that in a public forum.

Rich owns Clojure code legally, and I would say ethically as well (given
his time investment vs. that of others in it, and his original authorship
of most of the code, and that everyone who contributed code agreed in
advance to give him co-ownership).  Project maintainers get to craft the
rules by which changes are made, for any project.  Some choose to turn it
over to a committee, others do not.

Andy


On Wed, Nov 21, 2018 at 11:25 AM Timothy Baldridge 
wrote:

> >>   We’re good with the name. The docstring exists for further
> explanation.
>
> Except the code is less-readable. The name is meaningless. "async-require"
> appends the adverb "async" to the verb "require", therefore making it an
> asynchronous variant of require, which is exactly the opposite of what the
> function actually does. So it might as well be named `foo-require`.
> Actually `foo-require` is better, since I don't know what `foo` means and
> I'd look up the docstring to find out. With `async-requrie` I now have more
> cognitive load having to remember what Clojure's special definition of
> `async` is in this context. All these crazy edge-cases in the naming of the
> language really start to add up after awhile, and it takes mental space
> away that I could be using to focus on the problem I'm trying to solve.
>
> It blows my mind that the Clojure team even cares enough to say no to
> this, why does it matter this much that it can't change. This conversation
> reinforces the view that Clojure is close-source development. Once the
> community hears about a feature, it's written in stone. Apparently all
> required input has already been thought of and anything the community says
> couldn't possibly matter.
>
>
>
> On Wed, Nov 21, 2018 at 11:34 AM Chris Nuernberger 
> wrote:
>
>> Agreed, specifically to avoid things like this:
>>
>> https://github.com/tech-ascent/tech.compute/blob/master/src/tech/compute/cpu/tensor_math.clj#L45
>>
>> Great timing and we will be looking forward to it!
>>
>> On Wed, Nov 21, 2018 at 11:09 AM Sean Corfield  wrote:
>>
>>> This makes me smile… My first reaction to the name was the same as
>>> Alexander’s and then my second reaction cut in: “No, they’ll have thought
>>> about the name and won’t entertain changes” 
>>>
>>>
>>>
>>> It’s for safely doing requires in asynchronous (multi-threaded) code.
>>>
>>>
>>>
>>> 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:* clojure@googlegroups.com  on behalf
>>> of Alex Miller 
>>> *Sent:* Wednesday, November 21, 2018 9:54:28 AM
>>> *To:* clojure@googlegroups.com
>>> *Subject:* Re: [ANN] Clojure 1.10.0-beta8
>>>
>>> We’re good with the name. The docstring exists for further explanation.
>>>
>>> On Nov 21, 2018, at 11:29 AM, Alexander Yakushev 
>>> wrote:
>>>
>>> Could I suggest bikeshedding on the name async-require? Before I've
>>> seen the patch, my initial impression was that it loads namespaces
>>> asynchronously (that is, returns control immediately and loads them in the
>>> background). It might be somewhat confusing that a function
>>> async-require is actually even more synchronous than the regular require
>>> :). How about synchronized-require (it's basically word-to-word
>>> description of the function body)?
>>>
>>> Otherwise, thanks for this one, I needed something like this plenty of
>>> times!
>>>
>>> On Wednesday, November 21, 2018 at 5:17:26 PM UTC+2, Alex Miller wrote:

 1.10.0-beta8 is now available.

 You can try it with clj using:

 clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta8"}}}'

 Changes in 1.10.0-beta8:

- CLJ-2438  - demunge
source location in execution error messages
- CLJ-2437  - add
async-require and use it from requiring-resolve
- CLJ-2436  - fix
reflection warning in reflect.java

 You can read the full 1.10 changelog here:
 https://github.com/clojure/clojure/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 

Re: [ANN] Clojure 1.10.0-beta7

[Andy Fingerhut]

Not testing results this time, but just a comparison of reflection warnings
in Clojure 1.9.0 vs. 1.10.0-beta7, after adding (set! *warn-on-reflection*
true) to all .clj files in Clojure's source code that did not already have
one.  These were obtained when compiling Clojure using mvn and Oracle Java
1.8.0_192.

A few reflection warnings in clojure/main.clj that were in 1.9.0 are gone
now.  Cool.

One new reflection warning in Clojure 1.10.0-beta7 that was not in Clojure
1.9.0:
 [java] Reflection warning, clojure/reflect/java.clj:183:35 - reference
to field getModifiers on java.lang.Object can't be resolved.

That is line 181 in the original source file here:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/reflect/java.clj#L181

That code doesn't appear to have changed, so only reason I can think of off
the top of my head why a new reflection warning is perhaps due to a change
in the method resolution code?

Andy



On Mon, Nov 19, 2018 at 1:51 PM Alex Miller  wrote:

> We expect to move back into release candidates next, so testing welcome...
>
> On Monday, November 19, 2018 at 3:34:03 PM UTC-6, Alex Miller wrote:
>>
>> 1.10.0-beta7 is now available.
>>
>> You can try it with clj using:
>>
>> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta7"}}}'
>>
>> Changes in 1.10.0-beta7:
>>
>>- CLJ-2435  - include
>>root cause class name in compilation and macroexpansion errors
>>
>> You can read the full 1.10 changelog here:
>> https://github.com/clojure/clojure/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] 1.10.0-beta5

[Andy Fingerhut]

Great, sounds like you are on top of it.  I tried compiling Clojure 1.9.0
and 1.10.0-beta5 with a line (set! *warn-on-reflection* true) in the
src/clj/clojure/main.clj source file of both, and the reflection warnings
appear to be different from each other when building Clojure, in a similar
way to how they are different when running Eastwood on that namespace of
those two different versions, and the differences in the reflection
warnings don't surprise me at all given the code changes there.

Andy

On Thu, Nov 15, 2018 at 1:12 PM Alex Miller  wrote:

> I looked at current version of main and found some unintentional
> reflection in new code and expect that to be fixed for next beta. There is
> also some intended reflection in there, based on the docstrings so I left
> that there.
>
> On Thu, Nov 15, 2018 at 1:04 PM Andy Fingerhut 
> wrote:
>
>> Understood.  I am curious, too, and will reply to this email thread if I
>> get more details in a coherent form.
>>
>> The main reason for taking more time here is that it is possible that
>> Eastwood-generated reflection warnings are different than the reflection
>> warnings without Eastwood -- Eastwood reads, analyzes with
>> tools.analyzer.jvm, emits new forms, and then evals those.
>> tools.analyzer.jvm _might_ be causing the emitted code to generate
>> different reflection warnings than Clojure would on the original code.
>>
>> Probably the quickest way for me to double-check is just to stick a (set!
>> *warn-on-reflection* true) at the beginning of clojure/main.clj source file
>> for Clojure 1.9.0 and 1.10.0-beta5 and compare the output there.  If those
>> are identical/similar-enough, then it is tools.analyzer.jvm or something
>> else in Eastwood causing the different reflection warnings.
>>
>> Andy
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] 1.10.0-beta5

[Andy Fingerhut]

Understood.  I am curious, too, and will reply to this email thread if I
get more details in a coherent form.

The main reason for taking more time here is that it is possible that
Eastwood-generated reflection warnings are different than the reflection
warnings without Eastwood -- Eastwood reads, analyzes with
tools.analyzer.jvm, emits new forms, and then evals those.
tools.analyzer.jvm _might_ be causing the emitted code to generate
different reflection warnings than Clojure would on the original code.

Probably the quickest way for me to double-check is just to stick a (set!
*warn-on-reflection* true) at the beginning of clojure/main.clj source file
for Clojure 1.9.0 and 1.10.0-beta5 and compare the output there.  If those
are identical/similar-enough, then it is tools.analyzer.jvm or something
else in Eastwood causing the different reflection warnings.

Andy


On Thu, Nov 15, 2018 at 6:07 AM Alex Miller  wrote:

> Thanks Andy!
>
> I'd be curious to see what reflection errors you're talking about in
> clojure.main just to make sure I understand the difference.
>
>
> On Thursday, November 15, 2018 at 12:32:20 AM UTC-6, Andy Fingerhut wrote:
>>
>> I have run versions 0.2.6 and 0.3.3 of the Eastwood Clojure lint tool on
>> 84 projects in its "crucible" set of projects that we use for testing
>> Eastwood.  You can find the list at [2].
>>
>> I tried comparing the output for these pairs of version combinations of
>> (Eastwood version, Clojure version, JDK version):
>>
>> (0.2.6, 1.9.0, Oracle 1.8.0_192) compared with (0.2.6, 1.10.0-beta5,
>> Oracle 1.8.0_192)
>> (0.2.6, 1.9.0, OpenJDK 11.0.1) compared with (0.2.6, 1.10.0-beta5,
>> OpenJDK 11.0.1)
>> (0.3.3, 1.9.0, Oracle 1.8.0_192) compared with (0.3.3, 1.10.0-beta5,
>> Oracle 1.8.0_192)
>> (0.3.3, 1.9.0, OpenJDK 11.0.1) compared with (0.3.3, 1.10.0-beta5,
>> OpenJDK 11.0.1)
>>
>> All test runs were run on an Ubuntu Linux 18.04.1 system in a VM on my
>> Intel x86_64 based Mac laptop.
>>
>> The only differences I found were:
>>
>> + differing line numbers of Clojure source code that appeared in stack
>> traces, which is expected in a new Clojure release
>> + fewer deprecation warnings when linting Clojure namespace
>> clojure.java.browse-ui, because of intentional changes made for Clojure
>> 1.10.0 to eliminate the use of deprecated APIs [3]
>> + a couple of reflection warnings present in namespace clojure.main are
>> gone.  There was no change in the Java interop calls, so perhaps this is
>> because of changes made in how the Clojure compiler resolves Java method
>> calls.
>>
>> I didn't see anything more than 3 to 4 percent difference in run times
>> across all of the version combinations above.
>>
>> Andy
>>
>> [1] https://github.com/jonase/eastwood
>> [2]
>> https://github.com/jonase/eastwood/tree/master/crucible/project-clj-files
>> [3]
>> https://github.com/clojure/clojure/commit/fb916808669ef65dce5dfe58e23d4a902253ca55
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] 1.10.0-beta5

[Andy Fingerhut]

I have run versions 0.2.6 and 0.3.3 of the Eastwood Clojure lint tool on 84
projects in its "crucible" set of projects that we use for testing
Eastwood.  You can find the list at [2].

I tried comparing the output for these pairs of version combinations of
(Eastwood version, Clojure version, JDK version):

(0.2.6, 1.9.0, Oracle 1.8.0_192) compared with (0.2.6, 1.10.0-beta5, Oracle
1.8.0_192)
(0.2.6, 1.9.0, OpenJDK 11.0.1) compared with (0.2.6, 1.10.0-beta5, OpenJDK
11.0.1)
(0.3.3, 1.9.0, Oracle 1.8.0_192) compared with (0.3.3, 1.10.0-beta5, Oracle
1.8.0_192)
(0.3.3, 1.9.0, OpenJDK 11.0.1) compared with (0.3.3, 1.10.0-beta5, OpenJDK
11.0.1)

All test runs were run on an Ubuntu Linux 18.04.1 system in a VM on my
Intel x86_64 based Mac laptop.

The only differences I found were:

+ differing line numbers of Clojure source code that appeared in stack
traces, which is expected in a new Clojure release
+ fewer deprecation warnings when linting Clojure namespace
clojure.java.browse-ui, because of intentional changes made for Clojure
1.10.0 to eliminate the use of deprecated APIs [3]
+ a couple of reflection warnings present in namespace clojure.main are
gone.  There was no change in the Java interop calls, so perhaps this is
because of changes made in how the Clojure compiler resolves Java method
calls.

I didn't see anything more than 3 to 4 percent difference in run times
across all of the version combinations above.

Andy

[1] https://github.com/jonase/eastwood
[2]
https://github.com/jonase/eastwood/tree/master/crucible/project-clj-files
[3]
https://github.com/clojure/clojure/commit/fb916808669ef65dce5dfe58e23d4a902253ca55


On Tue, Nov 6, 2018 at 5:42 AM Alex Miller  wrote:

> 1.10.0-beta5 is now available.
>
> You can try it with clj using:
>
>   clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
> "1.10.0-beta5"}}}'
>
> Changes in 1.10.0-beta5:
>
>
>- In addition to prior methods of extension, values can now extend
>protocols by adding metadata where keys are fully-qualified symbols naming
>protocol functions and values are function implementations. Protocol
>implementations are checked first for direct definitions (defrecord,
>deftype, reify), then metadata definitions, then external extensions
>(extend, extend-type, extend-protocol). datafy has been updated to use this
>mechanism.
>- `symbol` can now be passed vars or keywords to obtain the
>corresponding symbol
>- CLJ-2420  error
>reporting enhancements - more refined phase reporting, new
>clojure.main/ex-triage split out of clojure.main/ex-str, execution errors
>now report the top *user* line in the stack trace omitting frames from
>core, enhancements to providing file and line via meta on a form
>- CLJ-2425  add java 11
>javadoc url
>- CLJ-2424  fix test bug
>from CLJ-2417
>
> You can read the full 1.10 changelog here:
> https://github.com/clojure/clojure/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: Inconsistent stack traces from the same expression.

[Andy Fingerhut]

I am not sure if this is the reason, but I would recommend checking the
command line options used when starting the java process in these cases.
Leiningen uses some command line options by default, for faster startup
times I think, that might affect how much detail is captured in stack
traces when exceptions are created.

Andy

On Wed, Oct 24, 2018 at 6:53 PM Austin Haas  wrote:

> I don't understand what is going on here. I'm trying to throw an exception
> with a cause and sometimes the cause is included in the stacktrace and
> sometimes it isn't.
>
> ~$ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
> "1.10.0-beta4"}}}'
> Clojure 1.10.0-beta4
> user=> (try (/ 1 0) (catch Exception e "caught"))
> "caught"
> user=> (try (/ 1 0) (catch Exception e (throw (Exception. "caught and
> rethrown" e
> Evaluation error (ArithmeticException) at clojure.lang.Numbers.divide (
> Numbers.java:188).
> Divide by zero
> user=> (clojure.repl/pst)
> ArithmeticException Divide by zero
>  clojure.lang.Numbers.divide (Numbers.java:188)
>  clojure.lang.Numbers.divide (Numbers.java:3901)
>  user$eval3.invokeStatic (:2)
>  user$eval3.invoke (:2)
>  clojure.lang.Compiler.eval (Compiler.java:7172)
>  clojure.lang.Compiler.eval (Compiler.java:7135)
>  clojure.core/eval (core.clj:3206)
>  clojure.core/eval (core.clj:3202)
>  clojure.main/repl/read-eval-print--8898/fn--8901 (main.clj:309)
>  clojure.main/repl/read-eval-print--8898 (main.clj:307)
>  clojure.main/repl/fn--8907 (main.clj:332)
>  clojure.main/repl (main.clj:332)
> nil
>
> Same behavior with Clojure 1.8 and 1.9.
>
> If I start a REPL via lein, the cause appears:
>
> $ lein repl
> nREPL server started on port 46767 on host 127.0.0.1 - nrepl://
> 127.0.0.1:46767
> REPL-y 0.3.7, nREPL 0.2.12
> Clojure 1.8.0
> Java HotSpot(TM) 64-Bit Server VM 1.8.0_102-b14
> 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=> (try (/ 1 0) (catch Exception e (throw (Exception. "caught and
> rethrown" e
>
>
> ArithmeticException Divide by zero  clojure.lang.Numbers.divide
> (Numbers.java:158)
> user=> (clojure.repl/pst)
> java.lang.Exception: caught and rethrown
>   (Unknown Source) user/eval1736
>   (Unknown Source) user/eval1736
> Compiler.java:6927 clojure.lang.Compiler.
> eval
> Compiler.java:6890 clojure.lang.Compiler.
> eval
>  core.clj:3105 clojure.core/eval
>  core.clj:3101 clojure.core/eval
>   main.clj:240 clojure.main/repl[fn]
>   main.clj:240 clojure.main/repl[fn]
>   main.clj:258 clojure.main/repl[fn]
>   main.clj:258 clojure.main/repl
>   main.clj:174 clojure.main/repl
>   RestFn.java:1523 clojure.lang.RestFn.
> invoke
>  interruptible_eval.clj:87 clojure.tools.nrepl.
> middleware.interruptible-eval/evaluate[fn]
>   AFn.java:152 clojure.lang.AFn.
> applyToHelper
>   AFn.java:144 clojure.lang.AFn.
> applyTo
>   core.clj:646 clojure.core/apply
>  core.clj:1881 clojure.core/with-
> bindings*
>  core.clj:1881 clojure.core/with-
> bindings*
>RestFn.java:425 clojure.lang.RestFn.
> invoke
>  interruptible_eval.clj:85 clojure.tools.nrepl.
> middleware.interruptible-eval/evaluate
>  interruptible_eval.clj:55 clojure.tools.nrepl.
> middleware.interruptible-eval/evaluate
> interruptible_eval.clj:224 clojure.tools.nrepl.
> middleware.interruptible-eval/interruptible-eval[fn]
> interruptible_eval.clj:192 clojure.tools.nrepl.
> middleware.interruptible-eval/run-next[fn]
>AFn.java:22 clojure.lang.AFn.run
>   ThreadPoolExecutor.java:1142 java.util.concurrent.
> ThreadPoolExecutor.runWorker
>ThreadPoolExecutor.java:617 java.util.concurrent.
> ThreadPoolExecutor$Worker.run
>Thread.java:745 java.lang.Thread.run
> Caused by: java.lang.ArithmeticException: Divide by zero
>   Numbers.java:158 clojure.lang.Numbers.
> divide
>  Numbers.java:3808 clojure.lang.Numbers.
> divide
> nil
>
> But if I run lein repl from inside a project directory, the cause is 

Re: [ANN] Clojure 1.10.0-RC1 (please test!)

[Andy Fingerhut]

I ran the latest version of Eastwood on the Clojure code itself, and didn't
find any surprising/new warnings.  There are a fair number of reflection
warnings in what I would consider non-performance-critical functions (e.g.
clojure.java.browse/open-url-in-browser, and code for handling/printing
exceptions) that are not new.  There are also what I think have always been
reflection warnings for things like aget/aset that I don't recall digging
into before -- Clojure code for that stuff hasn't changed in quite a while,
so I can't see that is anything new.

I made some preliminary updates to the Clojure cheatsheet in preparation
for the 1.10 release, and noticed that the new Var clojure.main/ex-str does
not have any :added "1.10" metadata for it, but many other Vars in
clojure.main also do not, so perhaps that is intentional.

I will try a full run of Eastwood on a set of 80+ open source projects with
Clojure 1.9.0 and 1.10.0-RC1 soon-ish, and see if anything surprising comes
out of that.  I've done it with 1.10.0-beta1 and didn't see any issues, and
don't expect any problems.

Andy


On Thu, Oct 11, 2018 at 5:22 PM Matthew Phillips  wrote:

> Hi Alex, have just finished testing on an 18 KLOC Clojure backend service
> (Java 8, Linux). Test suites and deployed service runs fine.
>
> Let me add my thanks for your hard work!
>
> Cheers,
>
> Matthew.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Large core.math expression produces excessively long Clojure-generated class names

[Andy Fingerhut]

Laurens: I know on Clojurians Slack you pointed out this repository:
https://github.com/simonpure/clojure-match-io-exception

This is not really an issue on a file system that can have very long file
names.  My recommendation is if you can arrange that, you should be good to
go.  There is a 'quick workaround' section in the README of the repository
above showing one way to do that on a Linux machine, if your base Linux
kernel imposes file name length limitations that are being exceeded
(apparently some encrypted Linux file systems have such limits).  I haven't
seen the file system name issue on a Mac OS X system.  I haven't tried
Windows to know what its file name length limitations might be, or whether
there are similar workarounds to enable longer file names.

There are a couple of relevant Clojure JIRA tickets I know of, which anyone
is welcome to vote on, but waiting for them to be resolved before deciding
what you are going to do about this issue doesn't seem like a viable
approach.

Kevin Downey has worked on patches for the Clojure ticket
https://dev.clojure.org/jira/browse/CLJ-701 that change the Clojure
compiler so that instead of wrapping various things in (fn* ...) that the
compiler does today, instead creates separate methods for those things.  I
don't know how production-worthy any of them are, but the comments seem to
imply that there are non-working edge cases for those approaches at the
moment.  You can vote on that issue

https://dev.clojure.org/jira/browse/CLJ-1852 comments mention some ideas of
changing the Clojure compiler to use shorter class file names, e.g. via
hashing the contents of long names to shorter ones.

Andy


On Sun, Oct 7, 2018 at 10:42 AM Andy Fingerhut 
wrote:

> I was able to fork your repo and created a different 'growing expression'
> that nests each one inside the 'catch' clause of the enclosing try
> expression, which is what the macro-expansion of core.match `match`
> expressions do as they get longer.
>
> It shows that the longest class file names are getting longer.  I believe
> that at least the body of the catch clause is enclosed in a new function by
> the Clojure compiler, if not the main body of the try.
>
> https://github.com/jafingerhut/nestedrepro
>
> Andy
>
>
> On Sun, Oct 7, 2018 at 8:36 AM Laurens Van Houtven <_...@lvh.io> wrote:
>
>> FWIW: I tried to reproduce it here: https://github.com/lvh/nestedrepro
>> but I was unable to cause these sorts of errors using try/catch and do.
>>
>> On Sat, Oct 6, 2018 at 6:17 PM Laurens Van Houtven <_...@lvh.io> wrote:
>>
>>> I'm hitting CLJ-1852 [0] (Clojure-generated class names length exceed
>>> file-system limit) with a large core.match expression. I have verified that
>>> it is the number of clauses in core.match: compilation works as soon as I
>>> reduce it, and looking at `target/` it is actually producing very long
>>> filenames a la:
>>>
>>>
>>> 'iddqd$xyzzy$fn__19779$fn__19788$fn__19789$fn__19790$fn__19793$fn__19794$fn__19795$fn__19796$fn__19797$fn__19814$fn__19815$fn__19816$fn__19819$fn__19820$fn__19823$fn__19824$fn__19825$fn__19826.class'
>>>
>>> However, I don't quite understand _why_ core.match produces such long
>>> filenames. The error and filename suggest the problem is deeply nested
>>> fn*s. Judging by macroexpand-all it's just a ton of let and try/catch which
>>> I'd expect don't compile to fn*s internally (I'm aware of the equivalent
>>> between let and lambda but I expect that's not really how it's
>>> implemented). I am trying to understand why it's producing all of these
>>> nested fns as compiled classes to see if I can somehow work around this
>>> (without rewriting the function completely, hopefully!).
>>>
>>> I've found a similar reproducer here[1]. Unfortunately it doesn't do a
>>> better job explaining _why_ the compiler emits that. Any tools for helping
>>> me understand the compiler would be helpful. I'm already quite comfortable
>>> with JVM bytecode and asm. Is the best way to figure this out just to read
>>> Compiler.java?
>>>
>>>
>>> [0]: https://dev.clojure.org/jira/browse/CLJ-1852
>>> [1]: https://github.com/simonpure/clojure-match-io-exception
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/c

Re: Large core.math expression produces excessively long Clojure-generated class names

[Andy Fingerhut]

I was able to fork your repo and created a different 'growing expression'
that nests each one inside the 'catch' clause of the enclosing try
expression, which is what the macro-expansion of core.match `match`
expressions do as they get longer.

It shows that the longest class file names are getting longer.  I believe
that at least the body of the catch clause is enclosed in a new function by
the Clojure compiler, if not the main body of the try.

https://github.com/jafingerhut/nestedrepro

Andy


On Sun, Oct 7, 2018 at 8:36 AM Laurens Van Houtven <_...@lvh.io> wrote:

> FWIW: I tried to reproduce it here: https://github.com/lvh/nestedrepro
> but I was unable to cause these sorts of errors using try/catch and do.
>
> On Sat, Oct 6, 2018 at 6:17 PM Laurens Van Houtven <_...@lvh.io> wrote:
>
>> I'm hitting CLJ-1852 [0] (Clojure-generated class names length exceed
>> file-system limit) with a large core.match expression. I have verified that
>> it is the number of clauses in core.match: compilation works as soon as I
>> reduce it, and looking at `target/` it is actually producing very long
>> filenames a la:
>>
>>
>> 'iddqd$xyzzy$fn__19779$fn__19788$fn__19789$fn__19790$fn__19793$fn__19794$fn__19795$fn__19796$fn__19797$fn__19814$fn__19815$fn__19816$fn__19819$fn__19820$fn__19823$fn__19824$fn__19825$fn__19826.class'
>>
>> However, I don't quite understand _why_ core.match produces such long
>> filenames. The error and filename suggest the problem is deeply nested
>> fn*s. Judging by macroexpand-all it's just a ton of let and try/catch which
>> I'd expect don't compile to fn*s internally (I'm aware of the equivalent
>> between let and lambda but I expect that's not really how it's
>> implemented). I am trying to understand why it's producing all of these
>> nested fns as compiled classes to see if I can somehow work around this
>> (without rewriting the function completely, hopefully!).
>>
>> I've found a similar reproducer here[1]. Unfortunately it doesn't do a
>> better job explaining _why_ the compiler emits that. Any tools for helping
>> me understand the compiler would be helpful. I'm already quite comfortable
>> with JVM bytecode and asm. Is the best way to figure this out just to read
>> Compiler.java?
>>
>>
>> [0]: https://dev.clojure.org/jira/browse/CLJ-1852
>> [1]: https://github.com/simonpure/clojure-match-io-exception
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.10.0-alpha7

[Andy Fingerhut]

Doing a little bit more digging, I just did a Google search for:

clojure "expects more than one argument"

and found this code hit that may be relevant for CIDER users:

https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/test/extensions.clj#L28

Andy

On Thu, Sep 6, 2018 at 8:57 AM Andy Fingerhut 
wrote:

> Thanks for the response.  Makes sense.  I haven't used CIDER before, and
> don't plan to try it out just to learn if it has a feature that checks unit
> tests for problems.  If anyone else knows whether CIDER has a feature to do
> that, I would be a little curious to learn more about it.
>
> Thanks,
> Andy
>
> On Thu, Sep 6, 2018 at 8:09 AM Peter Hull  wrote:
>
>>
>> On Thursday, 6 September 2018 15:09:15 UTC+1, Andy Fingerhut wrote:
>>>
>>>
>>> If you have a few minutes to try out the tests in my repo to see if you
>>> get different results than I did, I'd be curious to hear if your results
>>> are different.  I'd be more curious to learn of a way to write a unit test
>>> that gives the exception you see with Clojure 1.10.0-alpha7.
>>>
>>> Thanks for your help. I think I've made a mistake somewhere. I use emacs
>> + CIDER  and run the tests from there. With 'lein test' I don't see that
>> error, but I do from emacs. So it may be something that's been updated in
>> CIDER rather than clojure itself. I didn't realise they were different.
>> The offending test was in a work project which has been put on
>> hold/abandoned, but every time a new clojure comes out, I test it again to
>> check it still works (ever hopeful it might be reinstated!). So, more had
>> changed than just alpha6 to alpha7 when I tested this time.
>>
>> Does that make sense?
>>
>> Peter
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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.10.0-alpha7

[Andy Fingerhut]

Thanks for the response.  Makes sense.  I haven't used CIDER before, and
don't plan to try it out just to learn if it has a feature that checks unit
tests for problems.  If anyone else knows whether CIDER has a feature to do
that, I would be a little curious to learn more about it.

Thanks,
Andy

On Thu, Sep 6, 2018 at 8:09 AM Peter Hull  wrote:

>
> On Thursday, 6 September 2018 15:09:15 UTC+1, Andy Fingerhut wrote:
>>
>>
>> If you have a few minutes to try out the tests in my repo to see if you
>> get different results than I did, I'd be curious to hear if your results
>> are different.  I'd be more curious to learn of a way to write a unit test
>> that gives the exception you see with Clojure 1.10.0-alpha7.
>>
>> Thanks for your help. I think I've made a mistake somewhere. I use emacs
> + CIDER  and run the tests from there. With 'lein test' I don't see that
> error, but I do from emacs. So it may be something that's been updated in
> CIDER rather than clojure itself. I didn't realise they were different.
> The offending test was in a work project which has been put on
> hold/abandoned, but every time a new clojure comes out, I test it again to
> check it still works (ever hopeful it might be reinstated!). So, more had
> changed than just alpha6 to alpha7 when I tested this time.
>
> Does that make sense?
>
> Peter
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.10.0-alpha7

[Andy Fingerhut]

Sorry, wrong link to the unit test that I tried, which should have been:
https://github.com/jafingerhut/catch-bad-unit-test/blob/master/test/catchme/core_test.clj#L5-L7


On Thu, Sep 6, 2018 at 7:08 AM Andy Fingerhut 
wrote:

> Peter:
>
> I do not know why you are seeing this change in behavior.  In order to see
> if I could determine why, I created my own unit test based on your
> description, but when I run my incorrectly unit test with Clojure
> 1.10.0-alpha6 or 1.10.0-alpha7, I get the same results -- no failures, and
> no "error: java.lang.Exception: = expects more than one argument" exception
> as you are seeing.  I am probably doing something too different from your
> code.
>
> I created a tiny test repo on Github with what I tried, here:
> https://github.com/jafingerhut/catch-bad-unit-test
>
> Here is the unit test I tried:
> https://github.com/jafingerhut/catch-bad-unit-test
>
> where the definitions of functions x and y are simply these:
> https://github.com/jafingerhut/catch-bad-unit-test/blob/master/src/catchme/core.clj#L3-L7
>
> If you have a few minutes to try out the tests in my repo to see if you
> get different results than I did, I'd be curious to hear if your results
> are different.  I'd be more curious to learn of a way to write a unit test
> that gives the exception you see with Clojure 1.10.0-alpha7.
>
> Andy
>
>
> On Thu, Sep 6, 2018 at 4:34 AM Peter Hull  wrote:
>
>> On Wednesday, 5 September 2018 13:39:36 UTC+1, stuart@gmail.com
>> wrote:
>>>
>>> 1.10.0-alpha7 includes the following changes since 1.10.0-alpha6:
>>>
>>
>> I was pleased to see that going from alpha 6 to 7 found an error in one
>> of my tests. I had something like
>> (is (= (x (func y
>> and the new version reports
>>
>>>  error: java.lang.Exception: = expects more than one argument
>>>
>>
>> But (purely for my own interest) I tried to discover which change in
>> clojure source made the difference and I couldn'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.
>>
>

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

Re: [ANN] Clojure 1.10.0-alpha7

[Andy Fingerhut]

Peter:

I do not know why you are seeing this change in behavior.  In order to see
if I could determine why, I created my own unit test based on your
description, but when I run my incorrectly unit test with Clojure
1.10.0-alpha6 or 1.10.0-alpha7, I get the same results -- no failures, and
no "error: java.lang.Exception: = expects more than one argument" exception
as you are seeing.  I am probably doing something too different from your
code.

I created a tiny test repo on Github with what I tried, here:
https://github.com/jafingerhut/catch-bad-unit-test

Here is the unit test I tried:
https://github.com/jafingerhut/catch-bad-unit-test

where the definitions of functions x and y are simply these:
https://github.com/jafingerhut/catch-bad-unit-test/blob/master/src/catchme/core.clj#L3-L7

If you have a few minutes to try out the tests in my repo to see if you get
different results than I did, I'd be curious to hear if your results are
different.  I'd be more curious to learn of a way to write a unit test that
gives the exception you see with Clojure 1.10.0-alpha7.

Andy


On Thu, Sep 6, 2018 at 4:34 AM Peter Hull  wrote:

> On Wednesday, 5 September 2018 13:39:36 UTC+1, stuart@gmail.com wrote:
>>
>> 1.10.0-alpha7 includes the following changes since 1.10.0-alpha6:
>>
>
> I was pleased to see that going from alpha 6 to 7 found an error in one of
> my tests. I had something like
> (is (= (x (func y
> and the new version reports
>
>>  error: java.lang.Exception: = expects more than one argument
>>
>
> But (purely for my own interest) I tried to discover which change in
> clojure source made the difference and I couldn'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.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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: Pipe shell output into REPL?

[Andy Fingerhut]

Others with better imagination or Unix-like system hackery skills than
myself may respond with a way, but my first inclination is 'no'.  In
particular, normally what you type at the REPL is being read from standard
in.

Perhaps if you had a way of changing the Clojure REPL function executed
when you type the command 'lein repl' read from a different Unix file
descriptor than 0 (the one for stdin), _and_ you found some way for the
terminal/console/whatever to have keystrokes you type go to that file
descriptor rather than 0, that would do it.  That second part sounds like
the trickiest bit to me.

Have you look at named pipes?  By creating one of those, and cat'ing the
file you want into that named pipe, you could start a REPL in the usual
way, type commands into it, and when you were ready, open the named pipe
and read from it.

Andy

On Wed, Sep 5, 2018 at 6:56 PM Didier  wrote:

> Hi all,
>
> I was wondering if there is an easy way I can pipe my shell output into a
> REPL. Something like:
>
> cat /tmp/remus-lighthouse-apis-info.ion | lein repl
>
> When I try this, it starts a REPL, and then each line gets sent one by one
> to the REPL and ran.
>
> I'd like it so that I'm at the REPL, and standard in is ready to be read
> by me, from the REPL, so I can manipulate the input being piped how I see
> fit within the repl session.
>
> Is there anyway to do this?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 to escape a space in a keyword?

[Andy Fingerhut]

If you want to serialize the data to EDN and back, and print them out into
the EDN file as (keyword "arbitrary-char-sequence"), then using the normal
Clojure functions for reading the EDN data in will leave those expressions
as the lists (keyword "arbitrary-char-sequence").  Of course you could
write a simple function that walks the data structure looking for such
lists and replacing them with the corresponding keywords.  However, that
breaks round-tripability of the data if you ever have an occurrence of such
a list in your original data before printing it to EDN.  If you believe, or
can somehow ensure, that will never happen, seems workable to me.

Using a custom data-reader like #my.namespace/keyword
"arbitrary-char-sequence" with a globally unique namespace that you own
would be less susceptible to such aliasing problems.

Andy

On Wed, Aug 8, 2018 at 4:55 PM Didier  wrote:

> Reviving an old thread. I have a case where I convert ION to Clojure, and
> ION has a SYMBOL type, which can be any UTF-8 character, including spaces.
> I though of making them keywords in Clojure, since they serve the same
> purpose, to be used as identifiers. I can create such keyword with the
> keyword function, but they don't serialize to EDN and back using the
> default printer and reader.
>
> I'm thinking of extending the printer like tbc++ says so keywords are
> printed as (keyword "string") instead. Does anyone believe there is
> something that's going to bite me later if I do this?
>
> On Tuesday, 13 March 2012 00:14:48 UTC-7, Andy Fingerhut wrote:
>>
>> Ah, my senior moment was not noticing the invalid example use of symbol
>> in the second example, which was passing strings of decimal digits to
>> symbol.  I went ahead and deleted that one.
>>
>> Thanks,
>> Andy
>>
>> On Mar 13, 2012, at 12:04 AM, Andy Fingerhut wrote:
>>
>> Which one?
>>
>> (symbol 'foo)
>>
>> (symbol "foo")
>>
>> (symbol "clojure.core" "foo")
>>
>> I don't see it, but I'm probably having a senior moment.
>>
>> clojuredocs.org are editable to anyone willing to create a free account,
>> by the way.  I'm nobody special there.
>>
>> Andy
>>
>> On Mar 12, 2012, at 11:53 PM, Meikel Brandmeyer (kotarak) wrote:
>>
>> Hi,
>>
>> Am Dienstag, 13. März 2012 07:46:58 UTC+1 schrieb Andy Fingerhut:
>>>
>>>
>>> http://clojuredocs.org/clojure_core/clojure.core/symbol
>>>
>>>
>> And right below is an example of invalid usage.
>>
>> Sincerely
>> Meikel
>>
>>
>> --
>> 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 post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.core/keys

[Andy Fingerhut]

Except for sorted-map and a few other special kinds of maps with ordering
guarantees, the normal kind of map in Clojure is a hash-map, which uses a
hash function of the keys to create a tree data structure with the hash
value as a search key.  seq on hash-map's traverses these trees in a
deterministic order, so the return order of keys from the clojure.core/keys
or clojure.core/seq functions are in increasing order of hash value of the
keys (or maybe it is decreasing -- either way, it is independent of the
order that you added the keys to the map).

For memory and run-time efficiency, maps that have 8 or fewer keys in them
are implemented with a different concrete data structure called
array-map's.  Those do happen to give you back the elements in the order
that the keys were first added, but as soon as you add a 9th key, the
implementation switches to a hash-map, and the order is then unrelated to
the order that keys were added.

If you want a map that is guaranteed to return the keys in the order they
were added, there is an implementation of this available called
ordered-maps's here: https://github.com/amalloy/ordered

Andy

On Sun, Aug 5, 2018 at 12:12 AM Andres Pineda  wrote:

> Why does the keys function return unexpected order when there are 8 or
> more keys in a map?
>
> I believe the order issue also applies to seq.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 test has 10 failures

[Andy Fingerhut]

Just another data point.

I tried Windows 10 Enterprise, Oracle JDK 1.8.0_171, Maven 3.5.0,
unmodified latest Clojure source code 1.10.0-alpha6.

mvn clean test

gave no errors.  The language/system/internationalization settings were US
English, but I have no idea if that could be making a difference.  The
errors you have during your tests do not seem related to language.

Andy

On Tue, Jul 24, 2018 at 9:18 AM 冯忠孝  wrote:

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

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

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Andy Fingerhut]

On Thu, Jul 19, 2018 at 1:04 PM Benoît Fleury  wrote:

> Replying to myself ... :)
>
> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
> as mental models for the different implementations of conj?
>
> No.
>
> 2. Am I wrong in thinking that they shouldn't?
>
> Yes.
>
> Clojure developers need to know the behavior of conj for vectors and
> lists. This is even what often drives the choice between the two data
> structures.
>
> And I think that's where a lot of confusion comes from. I think I
> (and maybe others) expect that the complete semantic of a function
>  be described in its documentation. I don't know whether this
>  expectation is justified or not :)
>

You are not alone in wishing for more details in documentation of Clojure
functions.  That is one of the reasons ClojureDocs.org exists, for example,
and its first few examples make explicit the different behavior of conj for
lists vs. vectors: http://clojuredocs.org/clojure.core/conj

If you wish for the Clojure core team to provide that style of
documentation for you, I expect your wish will not be fulfilled.  It is not
technically difficult to replace all Clojure doc strings with more verbose
variants.  It _is_ a lot of work to write documentation like that and
maintain it over time.  For example, here is a whole bunch of stuff I wrote
on the behavior of clojure.core/= and clojure.core/hash.  It took way more
hours than I care to admit:
https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/equality.md

I believe someone wrote a book aiming to be a reference to all Clojure
functions, but don't recall the name or author at the moment, nor have I
read it.

Andy



>
>
> On Thu, Jul 19, 2018 at 11:04 AM Benoît Fleury  wrote:
>
>> I agree with Alex. It is important to understand the rationale behind the
>> behavior of conj. conj is for adding an element to a collection. It
>> doesn't
>> say anything about ordering. It has been chosen as an operation, as
>> opposed to append/prepend, because it can be implemented with the
>> same time complexity for a lot of data structures.
>>
>> To convince myself that time complexity mattered in programming, I take
>> the example of a stack. If you give me an implementation of a stack that
>> push and pop items in linear time, I will write very inefficient programs
>> very quickly. To the point of not working at all. So it makes sense to me
>> that space/time complexity should be part of the signature of an
>> operation.
>>
>> Now, I think the problem here comes from the fact that we have a tendency
>> to infer the semantic of an operation from its behavior on certain types.
>> We
>> see that (conj [1 2] 3) returns [1 2 3] so we conclude that conj is for
>> adding
>> an item at the end of a collection. And then we get surprised when the
>> behavior is "different" for other types. As Clojure programmers, it is
>> something
>> we need to be careful about and make sure we understand the actual
>> semantic of the operations.
>>
>> However, I think it is easier said than done. I would be ready to bet
>> that a
>> lot of Clojure programs rely on the fact that conj *appends* to a vector
>> or
>> *prepends* to a list. I agree that it is problematic. First, it makes the
>> understanding of the code harder because you need to remember the behavior
>> of conj on each type. And it prevents the implementation of conj to change
>> because so many programs rely on implementation details. But to all expert
>> Clojure programmers here, can you honestly think about what mental model
>> you
>> use when using conj on vectors and lists? Are you really thinking: I'm
>> adding
>> this element to this collection. I don't really care where it ends up :) ?
>>
>> So my questions are:
>>
>> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
>> as mental models for the different implementations of conj?
>>
>> 2. Am I wrong in thinking that they shouldn't?
>>
>> 3. And if I'm not wrong, how could we make it easier for programmers to
>> make
>> sure they code against the semantic of an operation and not its
>> implementation
>> details? Is there methods, tools or tests that could help us with that?
>>
>>
>> On Thu, Jul 19, 2018 at 3:20 AM Didier  wrote:
>>
>>> Hey Alan,
>>>
>>> Nice job on Tupelo by the way. I do find it a bit bloated though, and
>>> that's why I never use it. Any reason why all the different namespace are
>>> still mixed together? Seem like they could each be an independent lib, like
>>> how the datomic namespace was split out.
>>>
>>> On Wednesday, 18 July 2018 13:16:15 UTC-7, Alan Thompson wrote:

 There is also a function `glue`
 
 for combining like collections:


 -
 Gluing Together Like Collections

 The concat function can sometimes have rather surprising results:

 

Re: Plain clojure 1.9 fails with Could not locate ... clojure/spec/alpha.clj on classpath. in Kubuntu 18.04

[Andy Fingerhut]

Thanks, Justin.

I tried the commands you suggested on an Ubuntu 18.04 LTS system, and 'lein
repl' still fails the same way afterwards when using Ubuntu's OpenJDK
installation (and still succeeds when using Oracle's JDK installation).

Andy

On Mon, May 21, 2018 at 1:04 PM, Justin Smith <noisesm...@gmail.com> wrote:

> I should have been more specific. Just uninstalling leaves old configs
> around, and fixing this requires a full purge of the package.
>
> these are my steps on a debian system:
>
> $ sudo dpkg --purge --force-depends ca-certificates-java
> $ sudo apt-get install ca-certificates-java
>
>
> sourced from this stackoverflow answer
> https://stackoverflow.com/a/33440168
>
> On Mon, May 21, 2018 at 12:28 PM Andy Fingerhut <andy.finger...@gmail.com>
> wrote:
>
>>
>> Jesús:
>>
>> Agreed that this issue is frustrating.  It doesn't necessarily help you
>> here, but realize that this issue appears like it might be unique to Ubuntu
>> 18.04's OpenJDK installations.
>>
>> This issue did not occur with earlier versions of Ubuntu that I am aware
>> of.
>>
>> Andy
>>
>> On Mon, May 21, 2018 at 10:29 AM, Jesús Gómez <jgo...@gmail.com> wrote:
>>
>>> I followed the Getting Started guide and nothing worked well, except
>>> for the boot with nix installation.
>>>
>>> The clj tools Linux instructions failed the same way the lein one
>>> failed: Error with some certs [1]
>>> I've been told that this problem could be solved if I install Oracle
>>> Java instead of using OpenJDK. I don't want to do that.
>>>
>>> I avoided the local build instructions because it was going to require
>>> maven. I don't want to use it for now.
>>>
>>> So, for now I'm working with the Clojure 1.8 jar.
>>>
>>> I must say, Clojure is a good language, but the tooling is awful, not
>>> userfriendly, not beginers friendly. Maven is a beast, is the only
>>> thing had keped me away of Java for years, and now I must live with
>>> it, Voluntarily (I'm learning Clojure not because the work, but
>>> because I like it too much).
>>>
>>> Probably I should try Clojurescript instead.
>>>
>>> Thank you.
>>>
>>> [1]
>>> Could not transfer artifact
>>> clojure-complete:clojure-complete:jar:0.2.4 from/to central
>>> (https://repo1.maven.org/maven2/): java.lang.RuntimeException:
>>> Unexpected error: java.security.InvalidAlgorithmParameterEx
>>> ception: the trustAnchors parameter must be non-empty
>>> .
>>> .
>>> .
>>>
>>>
>>> 2018-05-21 14:40 GMT-02:30 Alex Miller <a...@puredanger.com>:
>>> > As of Clojure 1.9, the Clojure jar depends on two additional libraries
>>> > (spec.alpha and core.specs.alpha). Using only the clojure jar is thus
>>> not
>>> > sufficient.
>>> >
>>> > There are several ways to handle this, as described on the
>>> > https://clojure.org/guides/getting_started page.
>>> >
>>> > 1. Use the new command line clj tools (linux install instructions on
>>> that
>>> > page) - this will fetch the deps for you.
>>> > 2. Do a local build into a single standalone jar (note this is a
>>> custom jar
>>> > containing deps and is different than just the artifact you
>>> downloaded).
>>> > 3. Use a build tool like leiningen or boot that will fetch the deps
>>> for you.
>>> > 4. Download clojure and its deps manually and build your own custom
>>> > classpath. (not recommended)
>>> >
>>> >
>>> > On Monday, May 21, 2018 at 11:17:37 AM UTC-5, Jesús Gómez wrote:
>>> >>
>>> >> Simply: 1.7 works but 1.9 not.
>>> >>
>>> >> Test:
>>> >>
>>> >> $ # Download Clojure 1.7, 1.8 and 1.9 jars
>>> >> $ seq 7 9 | xargs -L1 -I% wget
>>> >> http://repo1.maven.org/maven2/org/clojure/clojure/1.%.0/
>>> clojure-1.%.0.jar
>>> >> $ seq 7 9 | xargs -L1 -I% java -jar clojure-1.%.0.jar -e '"1.%.0 is
>>> >> Working"'
>>> >> "1.7.0 is Working"
>>> >> "1.8.0 is Working"
>>> >> Exception in thread "main" java.lang.ExceptionInInitializerError
>>> >> ...
>>> >> Caused by: java.io.FileNotFoundException: Could not locate
>>> >> clojure/spec/alpha__init.class or clojure/spec/alpha.clj on classpath.

Re: Plain clojure 1.9 fails with Could not locate ... clojure/spec/alpha.clj on classpath. in Kubuntu 18.04

[Andy Fingerhut]

Jesús:

Agreed that this issue is frustrating.  It doesn't necessarily help you
here, but realize that this issue appears like it might be unique to Ubuntu
18.04's OpenJDK installations.

This issue did not occur with earlier versions of Ubuntu that I am aware of.
Andy

On Mon, May 21, 2018 at 10:29 AM, Jesús Gómez  wrote:

> I followed the Getting Started guide and nothing worked well, except
> for the boot with nix installation.
>
> The clj tools Linux instructions failed the same way the lein one
> failed: Error with some certs [1]
> I've been told that this problem could be solved if I install Oracle
> Java instead of using OpenJDK. I don't want to do that.
>
> I avoided the local build instructions because it was going to require
> maven. I don't want to use it for now.
>
> So, for now I'm working with the Clojure 1.8 jar.
>
> I must say, Clojure is a good language, but the tooling is awful, not
> userfriendly, not beginers friendly. Maven is a beast, is the only
> thing had keped me away of Java for years, and now I must live with
> it, Voluntarily (I'm learning Clojure not because the work, but
> because I like it too much).
>
> Probably I should try Clojurescript instead.
>
> Thank you.
>
> [1]
> Could not transfer artifact
> clojure-complete:clojure-complete:jar:0.2.4 from/to central
> (https://repo1.maven.org/maven2/): java.lang.RuntimeException:
> Unexpected error: java.security.InvalidAlgorithmParameterEx
> ception: the trustAnchors parameter must be non-empty
> .
> .
> .
>
>
> 2018-05-21 14:40 GMT-02:30 Alex Miller :
> > As of Clojure 1.9, the Clojure jar depends on two additional libraries
> > (spec.alpha and core.specs.alpha). Using only the clojure jar is thus not
> > sufficient.
> >
> > There are several ways to handle this, as described on the
> > https://clojure.org/guides/getting_started page.
> >
> > 1. Use the new command line clj tools (linux install instructions on that
> > page) - this will fetch the deps for you.
> > 2. Do a local build into a single standalone jar (note this is a custom
> jar
> > containing deps and is different than just the artifact you downloaded).
> > 3. Use a build tool like leiningen or boot that will fetch the deps for
> you.
> > 4. Download clojure and its deps manually and build your own custom
> > classpath. (not recommended)
> >
> >
> > On Monday, May 21, 2018 at 11:17:37 AM UTC-5, Jesús Gómez wrote:
> >>
> >> Simply: 1.7 works but 1.9 not.
> >>
> >> Test:
> >>
> >> $ # Download Clojure 1.7, 1.8 and 1.9 jars
> >> $ seq 7 9 | xargs -L1 -I% wget
> >> http://repo1.maven.org/maven2/org/clojure/clojure/1.%.0/
> clojure-1.%.0.jar
> >> $ seq 7 9 | xargs -L1 -I% java -jar clojure-1.%.0.jar -e '"1.%.0 is
> >> Working"'
> >> "1.7.0 is Working"
> >> "1.8.0 is Working"
> >> Exception in thread "main" java.lang.ExceptionInInitializerError
> >> ...
> >> Caused by: java.io.FileNotFoundException: Could not locate
> >> clojure/spec/alpha__init.class or clojure/spec/alpha.clj on classpath.
> >> ...
> >>
> >> I've been trying to learn Clojure, so I've installed it in many ways:
> >>
> >>  * Lein - Not working due some SSL credential
> >>  * boot vian nix - Working but ... I don't remember the why already...
> >> something related with CIDR?... not important for this post anyways
> >>  * via apt - Working but I can't make a simple clojure -m hello to work
> >>
> >> So I tried to understand the basics (No maven, no 3rd parties, etc.) and
> >> found the mentioned problem.
> >>
> >> I was expecting it to work flawless and to not be affected on what I got
> >> already installed in my system, but probably is the fact I installed
> clojure
> >> via APT, which installed 1.9.0, that is causing the jar for 1.9.0 to
> fail
> >> and not the others.
> >>
> >> In any case... 1.9.0 jar is not working for me.
> >>
> >> Thank you.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 

Re: Plain clojure 1.9 fails with Could not locate ... clojure/spec/alpha.clj on classpath. in Kubuntu 18.04

[Andy Fingerhut]

Justin, I have tried doing these commands on an Ubuntu 18.04 LTS system
(which I believe is Debian based):

% sudo apt-get --reinstall install ca-certificates
% sudo apt-get --reinstall install ca-certificates-java

Afterwards, the command "lein repl" still fails when using Ubuntu's
OpenJDK8 or OpenJDK10 installations, and succeeds before and after with
Oracle's JDK installations.

Is there some other command you would recommend to force reinstall of
ca-certs that might work?

Andy


On Mon, May 21, 2018 at 10:38 AM, Justin Smith  wrote:

> this is a problem with your distribution's config for installing the vm,
> on debian based systems it can be fixed by forcing reinstall of ca-certs,
> it does not require an oracle vm
>
> On Mon, May 21, 2018 at 10:30 AM Jesús Gómez  wrote:
>
>> I followed the Getting Started guide and nothing worked well, except
>> for the boot with nix installation.
>>
>> The clj tools Linux instructions failed the same way the lein one
>> failed: Error with some certs [1]
>> I've been told that this problem could be solved if I install Oracle
>> Java instead of using OpenJDK. I don't want to do that.
>>
>> I avoided the local build instructions because it was going to require
>> maven. I don't want to use it for now.
>>
>> So, for now I'm working with the Clojure 1.8 jar.
>>
>> I must say, Clojure is a good language, but the tooling is awful, not
>> userfriendly, not beginers friendly. Maven is a beast, is the only
>> thing had keped me away of Java for years, and now I must live with
>> it, Voluntarily (I'm learning Clojure not because the work, but
>> because I like it too much).
>>
>> Probably I should try Clojurescript instead.
>>
>> Thank you.
>>
>> [1]
>> Could not transfer artifact
>> clojure-complete:clojure-complete:jar:0.2.4 from/to central
>> (https://repo1.maven.org/maven2/): java.lang.RuntimeException:
>> Unexpected error: java.security.InvalidAlgorithmParameterEx
>> ception: the trustAnchors parameter must be non-empty
>> .
>> .
>> .
>>
>>
>> 2018-05-21 14:40 GMT-02:30 Alex Miller :
>> > As of Clojure 1.9, the Clojure jar depends on two additional libraries
>> > (spec.alpha and core.specs.alpha). Using only the clojure jar is thus
>> not
>> > sufficient.
>> >
>> > There are several ways to handle this, as described on the
>> > https://clojure.org/guides/getting_started page.
>> >
>> > 1. Use the new command line clj tools (linux install instructions on
>> that
>> > page) - this will fetch the deps for you.
>> > 2. Do a local build into a single standalone jar (note this is a custom
>> jar
>> > containing deps and is different than just the artifact you downloaded).
>> > 3. Use a build tool like leiningen or boot that will fetch the deps for
>> you.
>> > 4. Download clojure and its deps manually and build your own custom
>> > classpath. (not recommended)
>> >
>> >
>> > On Monday, May 21, 2018 at 11:17:37 AM UTC-5, Jesús Gómez wrote:
>> >>
>> >> Simply: 1.7 works but 1.9 not.
>> >>
>> >> Test:
>> >>
>> >> $ # Download Clojure 1.7, 1.8 and 1.9 jars
>> >> $ seq 7 9 | xargs -L1 -I% wget
>> >> http://repo1.maven.org/maven2/org/clojure/clojure/1.%.0/
>> clojure-1.%.0.jar
>> >> $ seq 7 9 | xargs -L1 -I% java -jar clojure-1.%.0.jar -e '"1.%.0 is
>> >> Working"'
>> >> "1.7.0 is Working"
>> >> "1.8.0 is Working"
>> >> Exception in thread "main" java.lang.ExceptionInInitializerError
>> >> ...
>> >> Caused by: java.io.FileNotFoundException: Could not locate
>> >> clojure/spec/alpha__init.class or clojure/spec/alpha.clj on classpath.
>> >> ...
>> >>
>> >> I've been trying to learn Clojure, so I've installed it in many ways:
>> >>
>> >>  * Lein - Not working due some SSL credential
>> >>  * boot vian nix - Working but ... I don't remember the why already...
>> >> something related with CIDR?... not important for this post anyways
>> >>  * via apt - Working but I can't make a simple clojure -m hello to work
>> >>
>> >> So I tried to understand the basics (No maven, no 3rd parties, etc.)
>> and
>> >> found the mentioned problem.
>> >>
>> >> I was expecting it to work flawless and to not be affected on what I
>> got
>> >> already installed in my system, but probably is the fact I installed
>> clojure
>> >> via APT, which installed 1.9.0, that is causing the jar for 1.9.0 to
>> fail
>> >> and not the others.
>> >>
>> >> In any case... 1.9.0 jar is not working for me.
>> >>
>> >> Thank you.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the 

Looking for people interested in developing Eastwood lint tool

[Andy Fingerhut]

Jonas Enlund started the Eastwood project [1], and beginning around 2014 I
hacked on it fairly feverishly for a while, along with Nicola Mometto who
developed the tools.reader, tools.analyzer, and tools.analyzer.jvm
libraries upon which Eastwood is based.

I have not spent time to do much with Eastwood for the last couple of
years, other than to ensure that it doesn't break completely with new
Clojure releases (a few things in Eastwood sometimes do, given a few
internal Clojure details that Eastwood currently relies upon in its
checking).  I don't expect that time to increase in the future.

Thus this message, to ask if anyone out there is interested in hacking
Eastwood to scratch their particular itches.  Jonas was willing to give me
commit access to the repository when I started hacking on it in significant
ways, and I would guess he is willing to add others similarly interested.

I don't know how many developers use Eastwood, but I have tracked how many
downloads it gets from Clojars.org for a while.  During the previous 1
year, it has averaged close to 500 downloads per day.  I am sure that is
tiny compared to Clojure itself, or the most popular Clojure libraries like
Ring.  One feature that might make it more widely useful for developers is
if like other lint tools for other languages, there were a way to add
structured comments that disabled particular warnings that developers knew
to be false positives, so they didn't have to see them repeatedly in the
future.

Regards,
Andy Fingerhut

[1] https://github.com/jonase/eastwood

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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 Group

[Andy Fingerhut]

I believe Bijay's earlier questions he is referring to were sent to the
group using a different email address of his:

pbi...@gmail.com


Several short messages to the Clojure Google group sent from that
address in the last month or so appear to have gone through just fine
and been published, but no one chose to answer them.


Bijay, sometimes for very short simple questions like those, the
#beginners channel on clojurians.slack.com might be a higher
probability method of getting answers, and perhaps with quicker
turnaround, too.


Looking at those questions, it seems like for some of them, the answer
depends on what data type you have, and there are multiple ways of
representing it, so the answer could depend upon those details.  A
person might see the question, but not be interested in writing an
email that tries to answer all the possibilities.


Andy


On Mon, Apr 16, 2018 at 11:50 AM, Gregg Reynolds  wrote:

>
>
> On Mon, Apr 16, 2018, 11:37 AM Bijay Paudel  wrote:
>
>> I post lots of questions but I did not get any response
>>
>
> FWIW not all messages get a response but in my experience that usually
> means nobody has anything useful to say, not that the message is unwelcome.
> Wait a while, then try again; if you are not comfortable in English try
> rephrasing the question.
>
> HTH
>
> G
>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: lein midje not working

[Andy Fingerhut]

The contents of your $HOME/.lein/profiles.clj file can affect the behavior
of all 'lein' commands run from any project, if you have one.

Andy

On Wed, Apr 11, 2018 at 4:31 PM, Renata Soares 
wrote:

> It happens with 'lein repl' too (gives timeout in this case).
>
>
> Em quarta-feira, 11 de abril de 2018 20:27:04 UTC-3, Renata Soares
> escreveu:
>>
>> Hello,
>>
>> I am running 'lein midje' on my project and looks like an infinite loop.
>> Doesn't show any message of error.
>>
>> Project.clj:
>>
>> (defproject job-queue "0.1.0-SNAPSHOT"
>>   :description "FIXME: write description"
>>   :url "http://example.com/FIXME;
>>   :main job-queue.core
>>   :license {:name "Eclipse Public License"
>> :url "http://www.eclipse.org/legal/epl-v10.html"}
>>   :dependencies [[org.clojure/clojure "1.8.0"]
>>  [org.clojure/data.json "0.2.6"]
>>  [midje "1.9.0"]]
>>   :plugins [[lein-midje "3.2.1"]])
>>
>> I created this test just to check the midje:
>>
>> (ns job-queue.core-test
>> (:require [job-queue.core :refer :all]
>>   [midje.sweet :refer :all]))
>>
>> (fact
>>   [1 3 5 8] => (contains even?))
>>
>> What can it be?
>>
>> 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: Coordinating STM with database?

[Andy Fingerhut]

I do not know what the result of that discussion was, but I would guess it
did not turn into a change that was incorporated into Clojure.  In the
discussion thread you linked to, Dave Griffith mentioned attaching a patch
"to the group".  I am pretty sure file attachments to Google groups went
away several years ago, but the file attached to this message might be the
one that Dave Griffith was referring to.  Looking at the latest Clojure
code and that patch should make it clear whether the patch was applied or
not.

Andy


On Fri, Mar 23, 2018 at 12:23 PM, Rob Nikander 
wrote:

> Hi,
>
> I see this was discussed before. Did it go anywhere? Basic idea: make a
> `dosync` transaction succeed or fail along with a database transaction.
>
> https://groups.google.com/forum/#!topic/clojure/qiKnCVAaZKw
>
> Rob
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.


external_transactions.patch
Description: Binary data

Re: [?] Adding my own function to clojure.core namespace

[Andy Fingerhut]

I would echo the question "is it truly a good idea?"

You can do it, but typing a single :require clause in an ns form once, and
then copying and pasting to other places that you use functions defined in
that namespace, is likely to be less time-consuming in the long run.

Andy

On Sat, Feb 24, 2018 at 10:08 PM, Philos Kim  wrote:

> Is there any way to add my own function to clojure.core namespace? Because
> I want to use that function globally without 'require' or 'use'.
>
> Thanks in advance.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] test-runner, a test runner for projects using Clojure Deps

[Andy Fingerhut]

Any call to clojure.core/future will also cause this 60-second delay,
including calls to pmap or clojure.java.shell/sh:
http://clojuredocs.org/clojure.core/future

Andy

On Tue, Feb 20, 2018 at 8:14 PM, 'Avi Flax' via Clojure <
clojure@googlegroups.com> wrote:

> On Tuesday, 20 February 2018 12:10:01 UTC-5, Luke VanderHart wrote:
>>
>> You're very likely correct about shutdown-agents, I don't think I
>> happened to fire up any agents in my test code. I'll try to reproduce as
>> soon as I get a chance.
>>
>
> FWIW, I’m seeing the same delay, and my project doesn’t use agents — at
> least, my project’s code doesn’t. I added a dummy test that calls
> (shutdown-agents) and that removed the delay, so I guess one of my
> dependencies is starting an agent; I have no idea which.
>
> 
> Principal Engineer @ Funding Circle
> Our mission: To build a better financial world
> We’re hiring! http://app.jobvite.com/m?34fSyjwx
>
>
> Our Mission: To build a better financial world
>
> Unless specifically indicated, this e-mail is not an offer to sell or a
> solicitation of any investment products or other financial product or
> service, an official confirmation of any transaction, or an official
> statement of Funding Circle USA.  This e-mail is meant only for the
> intended recipient of this transmission, and contains trade secret
> and strictly confidential information belonging to the sender. It is
> unlawful for unauthorized individuals to review, use, copy, disclose, or
> disseminate confidential information. If you have received this e-mail in
> error, please notify the sender immediately by telephone at (415) 813-5245 or 
> by
> return email and promptly delete this message from your system.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Why not clojure support raw string?

[Andy Fingerhut]

Clojure does not have Python's triple-quoted strings, that is true.  Why?
They have only come up a few times before in discussion on this Google
group, and Rich Hickey has not participated in them that I have seen, so
most likely he may simply not see much advantage to having them in the
language, vs. possible backwards-compatibility issues that might arise if
they were added.

One of the main uses of raw string literals in Python is to avoid having to
use two consecutive backslashes to get on backslash in a string, which is
most useful in regular expressions, where backslashes are quite common.
Clojure has regex literals with the syntax #"\d+" which have that feature
of Python raw string literals.

Andy

On Mon, Feb 19, 2018 at 10:46 PM, Promise.  wrote:

> Just like r"" or r""" """ in python.
>
> r"""{"doc":"This is a JSON string."}"""
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: tlc Expect like library?

[Andy Fingerhut]

Google searches for the terms: java tcl expect

turn up a few things that appear to be integrations of existing Tcl/Expect
into the JVM via native interfaces like JNI.  There might also be a "native
Java" version available that way.

The up side of wrapping an existing implementation is that it would be more
familiar to Tcl/Expect users, and all of the docs and support that exist
for that.  The down side is: if you don't want to learn Tcl/Expect, but
want features like that, then coming up with a new way of specifying the
kinds of behaviors one wants is much easier by starting fresh.  (Easier to
create something different, at least -- clean APIs are difficult to design).

Andy

On Tue, Feb 13, 2018 at 1:34 PM, Stephen Feyrer 
wrote:

> Hi Justin,
>
> That looks really cool.  I'll take some time reading about it and see if I
> can do anything.
>
> Thank you.
>
>
> --
> Kind regards,
>
> Stephen.
>
> On 13 February 2018 at 18:26, Justin Smith  wrote:
>
>> I've long thought implementing something like TCL expect in Clojure would
>> be a fun project, as far as I know it hasn't been tried (though the google
>> results are drowned out by the Expectations testing library so who
>> knows...).
>>
>> If I were doing this from scratch I'd start with the Process and
>> ProcessBuilder APIs, or use node child_process API with cljs. core.match
>> might be useful for program interaction dispatch.
>>
>> On Tue, Feb 13, 2018 at 4:42 AM Stephen Feyrer 
>> wrote:
>>
>>> Hi,
>>>
>>> I would like to ask, is there a Clojure version of the tlc expect
>>> library or an equivalent?
>>>
>>> Something to launch and control other applications.  Specifically I want
>>> to control text based terminal application.  Emulating the screen, moving
>>> the cursor around and firing character codes at it?
>>>
>>> Thanks.
>>>
>>>
>>> Stephen Feyrer.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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 please: New to clojure development

[Andy Fingerhut]

Nadeen:

You are welcome to send questions here, of course.  I wanted to point out
another resource that many people take advantage of: The #beginners channel
on Slack.

https://clojurians.slack.com

Sorry, I don't recall the exact button clicks necessary after you create a
free account on Slack for yourself in order to join particular 'channels',
but hopefully the web page makes that not difficult to figure out.

Andy

On Tue, Feb 6, 2018 at 8:50 AM, Nadeen Kurz  wrote:

> Thanks Simon, I am using the repl and I am sorry, I should have click
> share to make it easier, don't know what I was thinking.
>
> Thanks everyone for your help, really appreciate it.
>
> On Feb 6, 2018 10:32 AM, "Simon Luetzelschwab"  wrote:
>
>> Hi Nadeen,
>>
>> Welcome to Clojure!
>>
>> I'd recommend incorporating Clojure's excellent REPL into your workflow
>> to easily try things out with quick feedback.
>>
>> Here's an online version with your code snippet prepopulated - just hit
>> the run button!
>>
>> https://repl.it/repls/OblongIntrepidAlabamamapturtle
>>
>> This should do what you like -
>>
>> (def input-file [{:st_abbrev "AZ", :firstname "john", :lastname "smith"}
>>   {:st_abbrev "FL", :firstname "roy", :lastname
>> "wills"}
>>{:st_abbrev "OH", :firstname "jay", :lastname
>> "louis"}])
>>
>>  (def state-names
>> {"AZ" "Arizona", "FL" "Florida", "OH" "Ohio"})
>>
>>  (defn state-desc3 [e]
>> (assoc e :state (state-names (:st_abbrev e
>>
>> (map state-desc3 input-file)
>>
>>
>> On Tue, Feb 6, 2018 at 5:27 AM, Nadeen Kurz  wrote:
>>
>>> Thanks for the quick response James. Yes, you hit the nail on the head
>>> with me not understanding map, explanation you provided helps. I like the
>>> second option better. I have tried both options and now I am getting
>>> "illegalargumentexception, key must be an integer"
>>> When I call
>>> (state-desc3 input-file)
>>>
>>> When I do this, it works find of course cause it's only one
>>> (state-desc3 {:st_abbr "AZ", :first name "John", :lastname  "Smith"})
>>>
>>>
>>>  1) maybe an index problem which I don't understand yet and researching
>>>
>>> 2) I need to figure out how to call function for testing
>>>
>>>
>>> On Feb 5, 2018 9:57 PM, "James Reeves"  wrote:
>>>
>>> First:
>>>
>>>   (#(map :st_abbrev input-file))
>>>
>>> Is equivalent to:
>>>
>>>   (map :st_abbrev input-file)
>>>
>>> Because your putting the form in an anonymous function, then immediately
>>> calling it. This is equivalent to just evaluating the form.
>>>
>>> Next, I think you're confused as to how `map` handles multiple
>>> arguments. If you call:
>>>
>>>   (map f [1 2 3] [4 5 6])
>>>
>>> Then it will return:
>>>
>>>   [(f 1 4) (f 2 5) (f 3 6)]
>>>
>>> The two collections are lined up, then passed as arguments to the
>>> function.
>>>
>>> If you want to put this into one function, then you don't need an inner
>>> map. You instead want:
>>>
>>>   (defn state-desc2 [input-file]
>>> (let [desc2 (:st_abbrev input-file)]
>>> (case desc2
>>>  "AZ" (assoc input-file :state "Arizona")
>>>  "FL" (assoc input-file :state "Florida")
>>>  "OH" (assoc input-file :state "Ohio")
>>>  "default")))
>>>
>>> You could also write it as:
>>>
>>>   (def state-names
>>> {"AZ" "Arizona", "FL" "Florida", "OH" "Ohio"})
>>>
>>>   (defn state-desc3 [input-file]
>>> (assoc input-file :state (state-names (:st_abbrev input-file
>>>
>>>
>>>
>>> On 6 February 2018 at 01:22, Nadeen Kurz  wrote:
>>>
 Can someone help me with the following please: I am new to clojure and
 i haven't developed in 4 years, previous was mainframe. See questions in
 blue

 ; Task is to add full state name based on st_abbr


 (def input-file [{:st_abbrev "AZ", :firstname "john", :lastname "smith"}
   {:st_abbrev "FL", :firstname "roy", :lastname
 "wills"}
{:st_abbrev "OH", :firstname "jay", :lastname
 "louis"}])

 *Question 1: How do I make these between the lines into one Defn?*
 ---
 (def get-state
   (#(map :st_abbrev input-file)))

 #'user/get-state
 ("AZ" "FL" "OH")

 (defn state-desc [get-state input-file]
   (let [desc get-state]
   (case desc
"AZ" (assoc input-file :state "Arizona")
"FL" (assoc input-file :state "Florida")
"OH" (assoc input-file :state "Ohio")
"default"
)))

 (map state-desc get-state input-file)

 #'user/state-desc
  ({:st_abbrev "AZ", :firstname "john", :lastname "smith", :state
 "Arizona"}
   {:st_abbrev "FL", :firstname "roy", :lastname "wills", :state
 "Florida"}
   {:st_abbrev "OH", :firstname "ja  y", :lastname "louis", :state

Re: lein repl broken under 1.9?

[Andy Fingerhut]

Given the warning about seesaw.util, I would guess that your project.clj
file has seesaw as a dependency?  Or maybe  you have seesaw in your
~/.lein/profiles.clj file as a dependency?

If so, either seesaw, or some other dependency being loaded, likely has an
erroneous ns form somewhere.  Perhaps where that erroneous ns form is can
be determined from some of the error messages you have not shown.  Clojure
1.9.0 checks the syntax of ns forms more strictly, and issues error
messages about them, more strictly than previous versions of Clojure.

Andy

On Sat, Jan 13, 2018 at 1:07 PM, Andrew Dabrowski 
wrote:

> I can't start a lein repl under 1.9 ( clojure 1.8 still works fine).
>
> $ lein repl
> WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace:
> seesaw.util, being replaced by: #'seesaw.util/boolean?
> Exception in thread "main" clojure.lang.ExceptionInfo: Call to
> clojure.core/ns did not conform to spec:
>
> and then follows pages more error messages.  Is there really a problem
> with clojure.core/ns?
>
> I haven't even written any code yet, this is right after creating a new
> project with lein.
>
> I'm on ubuntu 16 LTS, 64bit.
>
> openjdk version "1.8.0_151"
>
> Leiningen 2.8.1 on Java 1.8.0_151 OpenJDK 64-Bit Server VM
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Understanding remove-ns and require

[Andy Fingerhut]

If you do have namespace names that do not correspond with the file name
they are placed in, in a Clojure/Java files, Eastwood can find them for you
quickly.  Eastwood doesn't analyze ClojureScript files, though.

Andy

https://github.com/jonase/eastwood


On Fri, Dec 22, 2017 at 9:41 AM, Stuart Sierra 
wrote:

> => CompilerException java.lang.Exception: namespace 'foo.bar' not found
>> after loading '/foo/bar', compiling:(*cider-repl foo*:65:7)
>>
>
> An error like this usually means that the ns declaration does not match
> the expected namespace name, based on the file path.
>
> Also be aware that AOT-compilation
>  causes all sorts of havoc
> with namespace reloading, because AOT-compiled .class files get read by a
> different ClassLoader. In effect, you cannot "unload" an AOT-compiled
> namespace. Make sure you do not have any AOT-compiled .class files in your
> project, and note that some tools and templates enable AOT by default.
>
> –S
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Understanding remove-ns and require

[Andy Fingerhut]

I don't have the answer, but perhaps a clue that might lead you to one: the
function remove-lib inside of the tools.namespace library does this:

(defn remove-lib
  "Remove lib's namespace and remove lib from the set of loaded libs."
  [lib]
  (remove-ns lib)
  (dosync (alter @#'clojure.core/*loaded-libs* disj lib)))

I suspect that perhaps since in your example REPL session you are not doing
anything to change clojure.core/*loaded-libs*, that perhaps it still
contains the namespace name on which you called remove-ns.  *loaded-libs*
is modified by functions used to implement the behavior of 'require',
because require tries to avoid re-loading namespaces that have already been
loaded earlier.

Andy

On Tue, Dec 19, 2017 at 2:14 PM, Mark Melling 
wrote:

> Hi,
>
> Apologies in advance for the possibly stupid question!
>
> I was having a problem with clojure.tools.namespace.repl/refresh where a
> namespace that had been successfully loaded subsequently failed to be
> reloaded when doing a repl/refresh.
>
> Whilst investigating the problem, (this is probably totally unrelated to
> my issue), I realised I didn't understand how remove-ns and require
> actually work.
>
> To illustrate this I did the following:
>
> (require '[foo.bar :as bar])
> => nil
> (remove-ns 'foo.bar)
> => #namespace[foo.bar]
> (require '[foo.bar :as bar])
> => CompilerException java.lang.Exception: namespace 'foo.bar' not found,
> compiling:(*cider-repl foo*:30:7)
>
>
>
>
> So what does remove-ns do to cause the second require to fail?
>
>
>
> Thanks
>
> 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.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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: Slow -main function termination by pmap

[Andy Fingerhut]

Well, this behavior is documented _somewhere_, but not in the doc string or
on clojure.org that I know of (happy to be corrected if I'm wrong there).

On the ClojureDoc.org web site, the docs for pmap:
http://clojuredocs.org/clojure.core/pmap

suggest looking at the docs for future for info about a 1-minute wait and
how to avoid it, where there are lots of details:
http://clojuredocs.org/clojure.core/future

Andy

On Tue, Dec 19, 2017 at 1:15 PM, Mike <145...@gmail.com> wrote:

> last line in -main should be (System/exit 0) or (shutdown-agents).
> 1 min awaiting it is documented behaviour of clojure.
>
> вторник, 19 декабря 2017 г., 23:08:09 UTC+3 пользователь Justin Smith
> написал:
>>
>> any Clojure program that uses the built in thread pools (future, agent,
>> pmap, core.async, etc.) should call (shutdown-agents) if prompt exit is
>> needed
>>
>> On Tue, Dec 19, 2017 at 12:05 PM Jacek Grzebyta 
>> wrote:
>>
>>> Hi,
>>>
>>> I have multi -mains project. Thus the execution looks like:
>>>
>>> java -cp location/file.jar some.method ..
>>>
>>>
>>> One -main method looks like:
>>>
>>> (defn -main
>>>   [& args]
>>>   (let [validated (validate-args args)]
>>> (if (:msg validated)
>>>   (println (st/join \newline (:msg validated)))
>>>   (run validated))
>>> (log/debug "finish")))
>>>
>>>
>>> There is nothing special in that except in the run time I have displayed
>>> the last log "finish" and the program termination is done after ~1 min
>>> later what is annoying. I found it is caused by deeply hidden pmap even if
>>> it is wrapped by doall. I thought after pmap returns results all threads
>>> are finished i.e. the main thread waits until all sub threads will be
>>> finished. If I am right what else can cause the delay? The threads pool
>>> manager?
>>>
>>> Tanks a lot,
>>> Jacek
>>>
>>> --
>>> 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: rationale for IAtom2 ?

[Andy Fingerhut]

I believe the short answer is: There are existing implementers of the IAtom
interface out there.  If the interface grew, those implementers would
become broken with Clojure 1.9.0.

There is no deep discussion of the details here, but a mention of wanting
to avoid breaking changes in the IAtom interface here:
https://groups.google.com/forum/#!searchin/clojure-dev/iatom%7Csort:date/clojure-dev/_ixXNiIyiuQ/p1HrCRGJDAAJ

Andy

On Sun, Dec 17, 2017 at 2:16 PM, dimitris  wrote:

> Hi all,
>
> This is mainly a question for the Clojure core dev team. I'm trying really
> hard to understand the thinking behind the new IAtom2 interface. My train
> of thought is detailed below, but you don't have to read the full thing.
> The core question is "How come the existing IAtom didn't grow, given the
> fact that you guys *own* the interface?"
>
> OK so here is the full story:
>
> I recently found out about https://dev.clojure.org/jira/browse/CLJ-1454,
> and it's true that often you want a version of `swap!` that returns the
> value that was swapped *out*. As indicated on the ticket various people
> have worked around the lack of such a fn in various ways. The solution that
> I'm using/maintaining looks very much like the approach taken with IAtom2,
> only it's goes through a protocol and it's written in clojure. Basically
> I've defined a new abstraction and extending it to Atom.
>
> (defprotocol IAtomic
>   ... ;; more methods
>   (trade![this f]
> [this f x]
> [this f x y]
> [this f x y more]
> "Like `clojure.core/swap!`, but returns the value that was swapped out."))
>
> (defmacro ^:private trade*
>   [ref f & args]
>   `(let [validate# (.getValidator ~ref)] ;; extract the validator-fn once 
> (loop []
>(let [oldv# (.deref ~ref)
>  newv# (~f oldv# ~@args)]
>  (try   (when-not (validate# newv#)
>  (throw (IllegalStateException. "Invalid reference state")))
>(catch Exception e#
>  (IllegalStateException. "Invalid reference state" ) e#))
>
>  (if (.compareAndSet ~ref oldv# newv#)
>(do (.notifyWatches ~ref oldv# newv#)
>oldv#)
>(recur))
>
> (extend-protocol IAtomic
>   ... ;; more types
>
>   Atom
>   (trade!([this f]
>  (trade* this f))
> ([this f x]
>  (trade* this f x))
> ([this f x y]
>  (trade* this f x y))
> ([this f x y more]
>  (trade* this #(apply f % x y more)))
> )
> )
>
>
> Ok, so at this point I want to stress out that the way I see it this
> solution seems to me like the second best option. I say 'second', because
> IMO the best option would be to add `trade!` (or however you want to call
> it) to the original IAtom.java and implement it straight in Atom.java. But
> obviously I can't do that - only clojure.core can. Since clojure.core
> didn't, I'd say that it's safe to assume that either a) growing IAtom is
> not desirable, and/or b) having IAtom2 is a superior solution . Personally,
> I wouldn't be able to explain/defend any of those in a conversation. I'm
> probably missing something here, and that's exactly why I'm sending this
> email. Enlighten me please... :) what am i missing? How come IAtom was, in
> some sense, cloned, rather than grown? Many thanks in advance...
>
> Jim
>
>  ps: oh and btw congrats on the 1.9 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.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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 is now available!

[Andy Fingerhut]

Rostislav:

I haven't run a bunch of benchmarks to double-check this in detail, but
just running a '(println "Hello")' shows a difference between 1.8 and 1.9,
which is purely Clojure startup time.  I don't see anything in your results
that suggests the time difference is getting large with more computation,
do you?

If it is all extra startup time, that could be due to loading spec and
def'ing extra Clojure 1.9 Vars during initialization.

Andy

On Fri, Dec 8, 2017 at 5:53 PM, Rostislav Svoboda <
rostislav.svob...@gmail.com> wrote:

> Hi, first of all: thanks for the 1.9.0!
> And now issue: it looks like the 1.9.0 is slower than 1.8.0. Is there
> any --turbo switch to flip?
>
> Bost
>
>
> time java -jar /home/bost/.m2/repository/org/
> clojure/clojure/1.8.0/clojure-1.8.0.jar
> -e '(defn Σ [n] (reduce + (range (inc n (println (Σ (* 1000
> 1000)))'
> #'user/Σ
> 5050
> 1.31user 0.04system 0:00.65elapsed 205%CPU (0avgtext+0avgdata
> 101872maxresident)k
> 0inputs+64outputs (0major+21822minor)pagefaults 0swaps
>
> time clj -e '(defn Σ [n] (reduce + (range (inc n (println (Σ (*
> 1000 1000)))'
> #'user/Σ
> 5050
> 2.03user 0.05system 0:00.92elapsed 226%CPU (0avgtext+0avgdata
> 108284maxresident)k
> 0inputs+64outputs (0major+25522minor)pagefaults 0swaps
>
>
>
> time java -jar /home/bost/.m2/repository/org/
> clojure/clojure/1.8.0/clojure-1.8.0.jar
> -e '(defn Σ [n] (reduce + (range (inc n (println (Σ (* 1000 1000
> 10)))'
> #'user/Σ
> 500500
> 1.72user 0.08system 0:00.88elapsed 204%CPU (0avgtext+0avgdata
> 199204maxresident)k
> 0inputs+64outputs (0major+46108minor)pagefaults 0swaps
>
> time clj -e '(defn Σ [n] (reduce + (range (inc n (println (Σ (*
> 1000 1000 10)))'
> #'user/Σ
> 500500
> 2.63user 0.09system 0:01.27elapsed 214%CPU (0avgtext+0avgdata
> 210056maxresident)k
> 0inputs+64outputs (0major+50405minor)pagefaults 0swaps
>
>
>
> time java -jar /home/bost/.m2/repository/org/
> clojure/clojure/1.8.0/clojure-1.8.0.jar
> -e '(defn Σ [n] (reduce + (range (inc n (println (Σ (* 1000 1000
> 100)))'
> #'user/Σ
> 50005000
> 2.17user 0.23system 0:01.59elapsed 151%CPU (0avgtext+0avgdata
> 729756maxresident)k
> 0inputs+64outputs (0major+178749minor)pagefaults 0swaps
>
> time clj -e '(defn Σ [n] (reduce + (range (inc n (println (Σ (*
> 1000 1000 100)))'
> #'user/Σ
> 50005000
> 2.95user 0.28system 0:01.87elapsed 172%CPU (0avgtext+0avgdata
> 739368maxresident)k
> 0inputs+64outputs (0major+182736minor)pagefaults 0swaps
>
>
>
> time java -jar /home/bost/.m2/repository/org/
> clojure/clojure/1.8.0/clojure-1.8.0.jar
> -e '(defn Σ [n] (reduce + (range (inc n (println (Σ (* 1000 1000
> 1000)))'
> #'user/Σ
> 55
> 9.34user 0.27system 0:08.75elapsed 109%CPU (0avgtext+0avgdata
> 744520maxresident)k
> 0inputs+64outputs (0major+183953minor)pagefaults 0swaps
>
> time clj -e '(defn Σ [n] (reduce + (range (inc n (println (Σ (*
> 1000 1000 1000)))'
> #'user/Σ
> 55
> 10.52user 0.25system 0:09.29elapsed 115%CPU (0avgtext+0avgdata
> 752244maxresident)k
> 0inputs+104outputs (0major+189351minor)pagefaults 0swaps
>
>
> 2017-12-08 23:17 GMT+01:00 Jose Figueroa Martinez <col...@gmail.com>:
> > Excelent news! Thank you all for your effort.
> >
> > It feels like christmas but earlier :-D
> >
> > "We wish you a merry christmas and a happy new Clojure!"
> >
> > José FM
> >
> >
> > El viernes, 8 de diciembre de 2017, 13:35:39 (UTC-6), Alex Miller
> escribió:
> >>
> >> Clojure 1.9 is now available!
> >>
> >>
> >> Clojure 1.9 introduces two major new features: integration with spec and
> >> command line tools.
> >>
> >>
> >> spec (rationale, guide) is a library for describing the structure of
> data
> >> and functions with support for:
> >>
> >> Validation
> >> Error reporting
> >> Destructuring
> >> Instrumentation
> >> Test-data generation
> >> Generative test generation
> >> Documentation
> >>
> >> Clojure integrates spec via two new libraries (still in alpha):
> >>
> >> spec.alpha - spec implementation
> >> core.specs.alpha - specifications for Clojure itself
> >>
> >> This modularization facilitates refinement of spec separate from the
> >> Clojure release cycle.
> >>
> >> The command line tools (guide, reference) provide:
> >>
> >> Quick and easy install
> >> Clojure REPL and runner
> >> Use of Mave

Re: [core.spec] Stricter map validations?

[Andy Fingerhut]

I don't know if this is a fruitful avenue to pursue, but the Eastwood lint
tool [1] uses tools.reader to read Clojure code, and the tools.analyzer
library to analyze it, while expanding all macros.

If someone can figure out a way to scan through the Abstract Syntax Tree
output of tools.analyzer to detect that such a missing spec seems to be
occurring, this is the kind of check that fits right in with Eastwood's
goals. Very often, such checks simply involve walking the AST looking for
certain types of nodes, or sometimes pairs of parent-child node pairs of
particular types, and checking certain properties on those, and/or building
up maps of info about names or things of interest.  I have never
experienced writing a linter where it required understanding all of the
possible AST data structures to get the job done.  Most of the time is in
learning enough about the AST to experiment with some approaches, and then
run your linter on as many live examples of code that might use code that
can trigger the warning, to 'tune' it in case it creates warnings in cases
you don't expect it to.

There is currently an issue on Eastwood suggesting using Stuart Halloway's
approach to implement a check in Eastwood for what Stuart's code already
checks for.  I haven't been spending much time on Eastwood development for
the last year or so, but if someone gets the itch to want to look into it,
let me know and I may be able to give advice.

Andy

[1] https://github.com/jonase/eastwood
[2] https://github.com/jonase/eastwood/issues/237

On Thu, Dec 7, 2017 at 12:28 PM, Ben Brinckerhoff 
wrote:

> I ran into a case today where I mistyped the keyword in a `keys` spec and
> was surprised that validation was not catching invalid data. For my
> purposes, it would be sufficient to have a automated test that looks at my
> specs and identifies typos in the spirit of https://gist.github.com/stuart
> halloway/f4c4297d344651c99827769e1c3d34e9
>
> However, I ran into a problem because my `keys` specs are often generated
> by the various multi-methods in a multi-spec. I took a stab at implementing
> a version of a "spec linter" that would catch typos in multi-specs, but I
> couldn't get anything that worked (at least in Clojurescript, I haven't
> tried implementing it in Clojure).
>
> Is it possible to write a CLJS linter that will catch the missing spec in
> the example below? If so, great! If not, I worry that the recommended
> approach of adding a linter on top of spec may not be sufficient in this
> case.
>
>  (s/def ::name string?)
>  (defmulti msg :msg-type)
>  (defmethod msg :greeting [x]
> (s/keys :req-un [::name]))
>  (defmethod msg :count [x]
>(s/keys :req-un [::num]))
>  (s/def ::msg (s/multi-spec msg :msg-type))
>
> (I suppose it's always going to be possible to write a linter that walks the 
> Clojure code and understands the semantics of the above macros, but I was 
> hoping I could write one using the data contained in the spec registry 
> instead)
>
>
> Ben
>
>
> On Thursday, November 23, 2017 at 7:09:15 AM UTC-7, Nico Schneider wrote:
>>
>> Hello everyone,
>>
>> On Thursday, 16 November 2017 23:29:56 UTC+1, John Newman wrote:
>>>
>>> [...] when we constrain maps in that closed way, aren't we creating some
>>> new subtype of a map, with fundamentally different semantics? If you are
>>> going to fully close a map, you might as well use a deftype and make a
>>> custom object and not call it a map, right?
>>>
>>
>> Just to add my two cents, I've been following the discussion and this has
>> been my thinking for quite some time. Is it not a valid argument? Having a
>> validation mechanism pick only certain keys, or ensuring that keys in a map
>> are specced, look as trivial to me than other data wrangling we do in
>> Clojure. My (preliminary) conclusion in cases like this is to build
>> validation tooling around spec, instead of using it directly.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 

Re: clojure.edn versus clojure.tools.reader.edn

[Andy Fingerhut]

I am pretty sure that clojure.tools.reader.edn is a version of the Clojure
reader specifically for the edn subset, hence the name of the namespace.

That said, no need to add a separate dependency on clojure.tools.reader if
you would prefer to avoid it, and you are reading EDN inside Clojure on the
JVM.

Andy

On Tue, Nov 28, 2017 at 1:14 PM, Alex Miller  wrote:

> Presuming you're in Clojure, just use clojure.edn. clojure.edn is written
> in Java and targets the edn subset of Clojure's syntax. Presuming you're
> reading typical edn data, this is the best answer.
>
> clojure.tools.reader is a version of the Clojure reader (not the edn
> subset) written in Clojure (the biggest user of this is ClojureScript).
>
>
> On Tuesday, November 28, 2017 at 9:51:45 AM UTC-6, Aaron Cummings wrote:
>>
>> I have a case where I'm reading a Clojure data structure serialized to
>> edn, but I don't have complete trust in the soure.
>>
>> Clearly I want to avoid clojure.core/read-string.  The
>> cheatsheet at https://clojure.org/api/cheatsheet hints that
>> clojure.tools.reader.edn/read-string is a good choice, but I also see
>> clojure.edn/read-string.
>>
>> Are both of these edn readers considered equally safe on untrusted
>> input?  What tradeoffs are there for one versus the other?
>>
>> Thanks,
>> Aaron
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Unexpected behaviour of transient map

[Andy Fingerhut]

I know they aren't "official" Clojure documentation, but the examples and
comments at clojuredocs.org are often correct, and even sometimes
illuminating.

http://clojuredocs.org/clojure.core/assoc!

All of the clojuredocs.org pages for transient operations refer to that one
for a more full discussion of the correct way to use them.

Andy

On Mon, Nov 27, 2017 at 1:16 AM, Mark Melling 
wrote:

> Thanks, that is useful advice.
>
> I do think that the docstring for assoc! could be more explicit about the
> dangers of not using the return value.
>
> Given the value placed in experimenting in the REPL it's easy to see how
> one could be fooled into using assoc! incorrectly.
>
>
> On Friday, 24 November 2017 16:52:15 UTC, Stuart Sierra wrote:
>>
>> The way I like to think of it, if it helps: Transients are still
>> *immutable*, but they are not *persistent*. Each new value *invalidates*
>> the previous value.
>>
>> –S
>>
>>
>> On Friday, November 24, 2017 at 11:01:48 AM UTC-5, Alex Miller wrote:
>>>
>>> Transients must still be used in the same calling pattern as persistent
>>> data structures. That is, you must use the value returned from the ! call
>>> to make the next call.
>>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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-RC1

[Andy Fingerhut]

I see the same behavior in Clojure 1.7.0 and 1.8.0 as you see in 1.9.0-RC1.

Andy

On Mon, Nov 13, 2017 at 9:48 PM, Shantanu Kumar 
wrote:

> Sorry, I did not specify the problem completely earlier. The coercion
> fails only when *uncheked-math* is set to truthy in 1.9.0-RC1.
>
> user=> (byte \a)
> 97
> user=> (set! *unchecked-math* true)  ; or :warn-on-boxed
> true
> user=> (byte \a)
>
> ClassCastException java.lang.Character cannot be cast to java.lang.Number
> clojure.lang.RT.uncheckedByteCast (RT.java:1376)
>
>
> Shantanu
>
> On Tuesday, 14 November 2017 01:27:36 UTC+5:30, Alex Miller wrote:
>>
>> Works for me in 1.9.0-RC1. I don't know of anything that changed in this
>> area.
>>
>> Clojure 1.9.0-RC1
>> user=> (byte \a)
>> 97
>>
>> On Mon, Nov 13, 2017 at 1:09 PM, Shantanu Kumar 
>> wrote:
>>
>>> The coercion (byte \a) works fine in Clojure 1.8, but it fails with
>>> `ClassCastException java.lang.Character cannot be cast to java.lang.Number`
>>> in 1.9.0-RC1. Is this by design?
>>>
>>>
>>> Shantanu
>>>
>>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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-beta4

[Andy Fingerhut]

Alan, I get similar messages when starting 'lein repl' with this
combination of versions:
+ Leiningen version 2.8.0, Clojure 1.8.0, Java 9.0.1 (note - No Clojure
1.9.0 involved)

Changing only the Leiningen to version 2.8.1 and there is no such error
message.

Andy

On Thu, Nov 2, 2017 at 11:29 AM, Alan Thompson  wrote:

> Hi.  1.9.0-beta4 works great for the Tupelo library on java 1.8, but I get
> the following warnings using Java 9.0.1:
>
> ​WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by dynapath.defaults$eval380$fn__381
> to method java.net.URLClassLoader.addURL(java.net.URL)
> WARNING: Please consider reporting this to the maintainers of
> dynapath.defaults$eval380$fn__381
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
>
> lein test tst.tupelo._bootstrap
>
> ---
>Clojure 1.9.0-beta4Java 9.0.1
> ---
>
>
> Is Clojure 1.9 intended to be compatible with Java 9?
>
> Alan
>
>
>
>
> On Wed, Nov 1, 2017 at 6:26 PM, Didier  wrote:
>
>> FWIW, bigdec? seemed to fit better, given bigdec as a coercion and
>>> BigDecimal as the underlying type – decimal? always seemed like the anomaly.
>>>
>>
>> Thought so too, but since there's no small decimal, or any other decimal,
>> its survivable. Though it does get a bit confusing, especially since int?
>> exclude bigint, for which you have to use integer?, which gets very
>> confusing if that includes or not biginteger.
>>
>> My conclusion is, its already all a bit of a mess, so maybe the broken
>> window principle applies here (even though that principle is actually to
>> say broken windows are not a good reason to break more of them, but...).
>>
>> On Wednesday, 1 November 2017 08:21:50 UTC-7, Sean Corfield wrote:
>>>
>>> Aside from needing to change bigdec? to decimal? in four places in our
>>> code, testing with Beta 4 has not shown any problems so we’ll probably go
>>> to production with it early next week.
>>>
>>>
>>>
>>> FWIW, bigdec? seemed to fit better, given bigdec as a coercion and
>>> BigDecimal as the underlying type – decimal? always seemed like the anomaly.
>>>
>>>
>>>
>>> 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:* Tuesday, October 31, 2017 7:24:04 AM
>>> *To:* Clojure
>>> *Subject:* [ANN] Clojure 1.9.0-beta4
>>>
>>> Clojure 1.9.0-beta4 is now available.
>>>
>>> Try it via
>>>
>>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure
>>> /1.9.0-beta4
>>> - Leiningen: [org.clojure/clojure "1.9.0-beta4"]
>>>
>>> 1.9.0-beta4 includes the following changes since 1.9.0-beta3:
>>>
>>> - CLJ-2259  - Remove
>>> unnecessary bigdec? predicate added in 1.9
>>> - Bumped spec.alpha dependency to 0.1.143
>>>
>>> We would appreciate anything you can do to try out this release. We do
>>> not plan to make any further changes prior to 1.9.0 release unless
>>> regressions are found.
>>>
>>> --
>>> 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
> 

Re: hello world question !!!

[Andy Fingerhut]

I haven't deployed an application written in Clojure to a server as a WAR
file before, so can't speak from experience, but I am sure others here
probably can.  Hey, others, have you deployed a Clojure application via a
WAR file without using AOT compilation, with only Clojure source code
packaged in the WAR file?  Is that something that works?

Andy

On Fri, Oct 13, 2017 at 11:05 AM, Damien Mattei <damien.mat...@gmail.com>
wrote:

> but i am in this situation, i wrote application in Scheme (Kawa,Bigloo)
> ,LisP that ran on an apache tomcat server, the application is deplyed in
> war files , they are precompiled ,with Kawa or Bigloo Scheme, and also use
> regular Java class compiled with Java8.
> They never ran in REPL ,all the test and debug must be done on the host
> that run tomcat web server in Java 8, here is the site :
> https://sidonie.oca.eu/
>
> On Friday, October 13, 2017 at 7:37:08 PM UTC+2, Andy Fingerhut wrote:
>>
>> Just a note that at the top of the documentation page you mention, it
>> says: "Clojure compiles all code you load on-the-fly into JVM bytecode,
>> but sometimes it is advantageous to compile ahead-of-time (AOT)."
>>
>> I would venture an estimate that most people who use Clojure do so
>> without using AOT compilation.  Many would advocate against using AOT
>> compilation, unless you are in a particular situation that requires it.
>>
>> Andy
>>
>> On Fri, Oct 13, 2017 at 10:13 AM, Damien Mattei <damien...@gmail.com>
>> wrote:
>>
>>> i did not have , i just follow the tutorial:
>>> https://clojure.org/reference/compilation
>>> i made the file but still the same problem:
>>>
>>> [mattei@moita ~]$ export CLASSPATH=.:./clojure/examples
>>> [mattei@moita ~]$ clojure
>>> Clojure 1.5.1
>>> user=> (compile 'clojure.examples.hello)
>>> FileNotFoundException Could not locate clojure/examples/hello__init.class
>>> or clojure/examples/hello.clj on classpath:   clojure.lang.RT.load
>>> (RT.java:443)
>>> user=> ^C[mattei@moita ~]$
>>>
>>> [mattei@moita ~]$ cat clojure/examples/hello.clj
>>> (ns clojure.examples.hello
>>> (:gen-class))
>>>
>>> (defn -main
>>>   [greetee]
>>>   (println (str "Hello " greetee "!")))
>>>
>>> On Friday, October 13, 2017 at 4:48:40 PM UTC+2, James Reeves wrote:
>>>>
>>>> Maybe this is a dumb question, but do you have a file
>>>> "clojure/examples/hello.clj" on the classpath? Since that's what the
>>>> exception is complaining about.
>>>>
>>>> On 13 October 2017 at 15:09, Damien Mattei <damien...@gmail.com> wrote:
>>>>
>>>>> hello,
>>>>>
>>>>> i'm new to clojure, just installed it on a CentOS box,
>>>>>
>>>>> and try to compile the code below from tutorial, but it does not work,
>>>>> i searched a lot before posting, no answer... i do not want to use
>>>>> leiningen at this stage,later perheaps...
>>>>>
>>>>> just want to compile and run
>>>>>
>>>>> user=> (ns clojure.examples.hello
>>>>> (:gen-class))
>>>>> nil
>>>>> clojure.examples.hello=>
>>>>> clojure.examples.hello=> (defn -main
>>>>>   [greetee]
>>>>>   (println (str "Hello " greetee "!")))
>>>>> #'clojure.examples.hello/-main
>>>>> clojure.examples.hello=> (compile 'clojure.examples.hello)
>>>>> FileNotFoundException Could not locate clojure/examples/hello__init.class
>>>>> or clojure/examples/hello.clj on classpath:   clojure.lang.RT.load
>>>>> (RT.java:443)
>>>>>
>>>>> help greatly appreciated (because i'm just one step to leave Clojure
>>>>> and continue using  Kawa or Bigloo i already use or dive into ABCL , but
>>>>> Clojure has a so good reputation, i cannot imagine being sticked here by a
>>>>> simple hello world!)
>>>>>
>>>>> damien
>>>>>
>>>>> --
>>>>> 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

Re: hello world question !!!

[Andy Fingerhut]

Just a note that at the top of the documentation page you mention, it says:
"Clojure compiles all code you load on-the-fly into JVM bytecode, but
sometimes it is advantageous to compile ahead-of-time (AOT)."

I would venture an estimate that most people who use Clojure do so without
using AOT compilation.  Many would advocate against using AOT compilation,
unless you are in a particular situation that requires it.

Andy

On Fri, Oct 13, 2017 at 10:13 AM, Damien Mattei 
wrote:

> i did not have , i just follow the tutorial:
> https://clojure.org/reference/compilation
> i made the file but still the same problem:
>
> [mattei@moita ~]$ export CLASSPATH=.:./clojure/examples
> [mattei@moita ~]$ clojure
> Clojure 1.5.1
> user=> (compile 'clojure.examples.hello)
> FileNotFoundException Could not locate clojure/examples/hello__init.class
> or clojure/examples/hello.clj on classpath:   clojure.lang.RT.load
> (RT.java:443)
> user=> ^C[mattei@moita ~]$
>
> [mattei@moita ~]$ cat clojure/examples/hello.clj
> (ns clojure.examples.hello
> (:gen-class))
>
> (defn -main
>   [greetee]
>   (println (str "Hello " greetee "!")))
>
> On Friday, October 13, 2017 at 4:48:40 PM UTC+2, James Reeves wrote:
>>
>> Maybe this is a dumb question, but do you have a file
>> "clojure/examples/hello.clj" on the classpath? Since that's what the
>> exception is complaining about.
>>
>> On 13 October 2017 at 15:09, Damien Mattei  wrote:
>>
>>> hello,
>>>
>>> i'm new to clojure, just installed it on a CentOS box,
>>>
>>> and try to compile the code below from tutorial, but it does not work, i
>>> searched a lot before posting, no answer... i do not want to use leiningen
>>> at this stage,later perheaps...
>>>
>>> just want to compile and run
>>>
>>> user=> (ns clojure.examples.hello
>>> (:gen-class))
>>> nil
>>> clojure.examples.hello=>
>>> clojure.examples.hello=> (defn -main
>>>   [greetee]
>>>   (println (str "Hello " greetee "!")))
>>> #'clojure.examples.hello/-main
>>> clojure.examples.hello=> (compile 'clojure.examples.hello)
>>> FileNotFoundException Could not locate clojure/examples/hello__init.class
>>> or clojure/examples/hello.clj on classpath:   clojure.lang.RT.load
>>> (RT.java:443)
>>>
>>> help greatly appreciated (because i'm just one step to leave Clojure and
>>> continue using  Kawa or Bigloo i already use or dive into ABCL , but
>>> Clojure has a so good reputation, i cannot imagine being sticked here by a
>>> simple hello world!)
>>>
>>> damien
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> James Reeves
>> booleanknot.com
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Eastwood, the Clojure lint tool, version 0.2.5 released

[Andy Fingerhut]

Eastwood, the Clojure lint tool, version 0.2.5 has been released.  See
install instructions and complete documentation at [1].

Below are some of the changes since version 0.2.4.  A complete list is at
[2].

Thanks to contributions from Daniel Compton, Derek Passen, Emlyn Corrin,
and Reid McKenzie.

Go squash some bugs!

Jonas Enlund, Nicola Mometto, and Andy Fingerhut

[1] https://github.com/jonase/eastwood
[2]
https://github.com/jonase/eastwood/blob/master/changes.md#changes-from-version-024-to-025


The main changes with version 0.2.5 are for improving how Eastwood works
with Clojure 1.9.0, and eliminating false positives when using the
:unused-namespaces linter.

   - Updated version of tools.reader adds support for new syntax in Clojure
   1.9.0-beta2, e.g. map namespace syntax, Issue #228 #201
   - Eliminate some common :suspicious-expression warnings due to how some
   clojure.spec macros such as every and and are implemented. Issue #227.
   There are likely further improvements that can be made in this area in the
   future.
   - :unused-namespaces linter has been significantly improved, in that it
   gives far fewer false positive warnings. Issue #200 #211 #186
   - Eliminate warnings when running with Clojure 1.9.0 for conflict with
   new functions in core like boolean? and uri? Issue #232 #233

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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.core.server/start-server should have :encoding as option

[Andy Fingerhut]

And if you need specific instructions on filing an issue in JIRA, here they
are:

If you want to be able to create or edit JIRA tickets, create an
account by going to this page:

https://dev.clojure.org/jira/secure/Signup!default.jspa

The link below gives a brief introduction to the process of creating
tickets and submitting patches to Clojure and its contributed
libraries:

https://dev.clojure.org/display/community/Contributing+FAQ

It contains some links to pages with further details, but the one
below is a good link to bookmark if you want to get to just about
anywhere related to Clojure contribution and development:

https://dev.clojure.org/display/community/Contributing

Andy Fingerhut


On Sun, Sep 24, 2017 at 8:50 AM, Alex Miller <a...@puredanger.com> wrote:

> File a jira
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Using memory with futures

[Andy Fingerhut]

You can probably also avoid the 60- to 80-second wait if you call
(shutdown-agents) at the end of your program.

https://clojuredocs.org/clojure.core/future

Andy


On Thu, Sep 7, 2017 at 2:27 AM, Max Muranov  wrote:

> it takes about a minute for the pool to decide to shutdown the threads.
>>
>
> Yes, I tried to wait 80 seconds after each creating futures loop and
> everything was okay, thanks!
>
> In certain configurations, the JVM may never give the memory back the OS
>
>
> Oh, I suffered from this some time ago when used java library for ML. I
> thought it was bad library =D Can you please tell me what to learn about
> configs to avoid these problems?
>
> *Didier*, no that's not the case, I have enough time between creating
> futures in my program. But thanks for the link!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: need help on json format extraction multiple deep

[Andy Fingerhut]

I don't know if this is the issue, but the JSON data has it spelled
resolvedQuery, but you spelled it differently in your Clojure code as
:resolvedQuerry  (two "r"s in Query instead of one)

In general, using a REPL session to examine the contents of data, or good
old-fashioned debug print statements or logging, to print out the contents
of intermediate values like from your expression (get-in (json-body-request
request {:keywords? true :bigdecimals true}) [:body :result])
:resolvedQuerry), can help debug these kinds of things.

Andy

On Wed, Sep 6, 2017 at 3:42 AM, dinesh bhardwaj 
wrote:

> I have a json request coming as:
>
> Headers:
> //user defined headers
> Content-type: application/json
>
> POST body:
>
> {
> "lang": "en",
> "result": {
> "parameters": {
> "city": "Rome",
> "name": "Tom"
> },
> "contexts": [],
> "resolvedQuery": "my name is Tom",
>
>  },
> "action": "greetings",
> },
>
> }
>
>
> I am ble to extract like :lang using following
>
> (get-in (json-body-request request {:keywords? true :bigdecimals true}) 
> [:body :lang])
>
> But I am not able to extract :resolvedQuerry. Although I am able to extract 
> :result. I used following code , but I know i am missing something. Please 
> help me out?
>
> (get  (get-in (json-body-request request {:keywords? true :bigdecimals true}) 
> [:body :result]) :resolvedQuerry))
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: SRSLY? (= (true? identity) (false? identity)) => true

[Andy Fingerhut]

By design, true? never throws an exception.   Neither does false?  You can
create functions similar to those that throw an exception when given a
non-boolean value, if you want such functions.

(Note: examples below rely on existence of clojure.core/boolean? which does
not exist in Clojure 1.8.0)

user=> (clojure-version)
"1.9.0-alpha19"
user=> (defn true-boolean?
  #_=>   [x]
  #_=>   (assert (boolean? x))
  #_=>   (true? x))
#'user/true-boolean?

user=> (true-boolean? true)
true
user=> (true-boolean? false)
false
user=> (true-boolean? identity)
AssertionError Assert failed: (boolean? x)  user/true-boolean?
(form-init3633819970128261150.clj:3)


Do the following function return values help shed any light on things,
perhaps?  They demonstrate that true and false are boolean value, but
identity has a value that is not a boolean type, but a function type.

user=> (boolean? true)
true
user=> (boolean? false)
true
user=> (boolean? identity)
false
user=> (fn? true)
false
user=> (fn? false)
false
user=> (fn? identity)
true

Andy


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

> > identity isn't a boolean, so neither true? nor false? should return true
> for it
>
> But then why it should return 'false'?
>
> 2017-09-02 6:04 GMT+02:00 Justin Smith :
> > identity isn't a boolean, so neither true? nor false? should return true
> for
> > it
> >
> >
> > On Fri, Sep 1, 2017 at 9:01 PM Rostislav Svoboda
> >  wrote:
> >>
> >> > (true? identity) -> false
> >> > (false? identity) -> false
> >> > (= false false) -> true
> >>
> >> Well:
> >> (= identity identity) -> true
> >>
> >> My math books say booleans can't be true and false in the same time.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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] expound 0.1.2

[Andy Fingerhut]

inspectable was recently announced in this group as well.  Do you know what
the similarities and differences are between these projects?

Andy

On Tue, Jul 25, 2017 at 4:16 PM, Ben Brinckerhoff 
wrote:

> Expound formats clojure.spec errors in a way that is optimized for humans
> to read. Expound works in Clojure and Clojurescript.
>
> This release provides human-optimized error messages when using a number
> of spec features, including instrumentation and `assert`.
>
> More information is available in the README
> .
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Migrating nREPL out of Clojure Contrib

[Andy Fingerhut]

Contribs are on github, but none of them accept pull requests.  All of them
use JIRA for tickets, listed here:
https://dev.clojure.org/jira/secure/BrowseProjects.jspa#all

Some background on the contribution process:
https://dev.clojure.org/display/community/Contributing+FAQ

Andy

On Tue, Jul 18, 2017 at 11:10 PM, Didier  wrote:

> I'm not too familiar with the way contribs are managed, isn't tools.nrepl
> repo in github? Wouldn't the only step to contribute be to sign the CA and
> send a pull request of your changes?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: ClojureDocs example management?

[Andy Fingerhut]

I think part of it is that examples are easy to edit, so if there are small
easily fixed mistakes, often someone will.

Unlike politically contentious issues on Wikipedia, there isn't much to be
gained from putting misleading information in ClojureDocs.

Andy

On Sun, Jun 18, 2017 at 7:53 PM, Alex Miller  wrote:

> I believe Lee Hinman was the original maintainer of ClojureDocs and it's
> mostly Zachary Kim now.
>
> Reop is at: https://github.com/zk/clojuredocs although the data is not
> publicly available other than through the site afaik.
>
> I'm not sure how much editing it receives right now. In general, I think
> most of the examples are reasonably good and/or there are corrections in
> later comments.
>
> Some factors that I think are in our collective favor are:
> - Clojure favors stability and backwards compatibility so in general it's
> pretty rare for examples to break over time
> - Most examples are 1-liners that are easy to put in a REPL and verify
> yourself
> - Clojure fans are all good thoughtful, careful people who never make
> foolish mistakes
>
>
> On Sunday, June 18, 2017 at 9:13:16 PM UTC-5, Mars0i wrote:
>>
>> Who polices ClojureDocs?  If someone adds a silly or simply incorrect
>> example, does someone eventually remove it?  Are there ever spam-like
>> "examples"?  Or are Clojure fans all good, thoughtful, careful people who
>> never make foolish mistakes?
>>
>> I'm curious because I see no sign that anyone polices ClojureDocs, and it
>> nevertheless seems like a uniformly useful resource.  The only flaws I've
>> experienced came when I thought something was missing--and then it was easy
>> enough to add an example or crossreference link myself.
>>
>> I'm asking because of a conversation in another language-centered
>> community where a worry was expressed that a community-contributed examples
>> website would end up full of junk--bad examples, etc.  Supposedly some
>> sites end up that way.  What's our secret?
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: New guide: Reading Clojure Characters

[Andy Fingerhut]

I would recommend _against_ using the same parameter name multiple times
like this, for the confusion in people's minds that it can easily create.
If you avoid this practice, then it is irrelevant why the last value is
used versus an earlier one.

The foo2 function works for the same reason that foo works, because '_' is
just another parameter name, no more or less special to the compiler than
the parameter name 'arg1' or 'f'.

Andy

On Sat, Jun 17, 2017 at 2:01 PM, Gregg Reynolds <d...@mobileink.com> wrote:

>
>
> On Jun 17, 2017 3:36 PM, "Andy Fingerhut" <andy.finger...@gmail.com>
> wrote:
>
> Consider this Clojure 1.8.0 REPL session:
>
> user=> (defn foo [a a] [a a])
>
> #'user/foo
>
> ser=> (foo 1 2)
>
> [2 2]
>
> user=> (defn foo2 [_ _] [_ _])
>
> #'user/foo2
>
> user=> (foo2 1 2)
>
> [2 2]
>
>
> This is the sense in which _ is just another function parameter name, no
> more or less special to the compiler than the parameter name 'a'.  There is
> no requirement in the Clojure compiler that parameter names are unique.
>
>
> thanks.  tried to do that on some of the online clj thingies, no luck.
>
> personally i view this as one of those clojure wierdisms that annoy newbs.
>  very counter-intuitive, imho.  why shouldn't the 1st arg be used?  and
> your foo2 - the fn definition, strictly speaking, makes no sense. if it
> works, i think we need to explain explicitly why.  maybe not in the section
> on '_', but somewhere.
>
> Andy
>
> On Sat, Jun 17, 2017 at 12:16 PM, Gregg Reynolds <d...@mobileink.com>
> wrote:
>
>>
>>
>> On Jun 17, 2017 1:55 PM, "Timothy Baldridge" <tbaldri...@gmail.com>
>> wrote:
>>
>> Anonymous implies there might be some sort of auto gen going on (as there
>> is with anonymous functions), Irrelevant has my vote therefore. The other
>> characteristics are a side-effect of it being a naming convention (with no
>> official support by the compiler).
>>
>>
>> yeah, i could go either way, although i might change "var" to "arg" - is
>> '_' ever a var?  actually i'm thinking "nonce arg" would be more accurate,
>> but then i'm a naming fanatic so take it with a grain of salt.
>>
>> Maybe that could be pointed out in greater detail. So maybe an edit along
>> the lines of:
>>
>> "Note: _ does not have special functionality in the compiler, it is seen
>> the same as any other local or arg, therefore the same rules of uniqueness
>> and precedence apply with _ as they would with any other symbol"
>>
>>
>> i might not understand the rules but my understanding is that '_' (as an
>> arg) is outside of the uniqueness (obviously) and precedence rules.  i'm
>> not understanding the point of your suggested edit, i guess.  thinking from
>> a newbie perspective.  are you saying that each '_' gets a gen-sym, so each
>> ends up being unique?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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 gro

Re: New guide: Reading Clojure Characters

[Andy Fingerhut]

Consider this Clojure 1.8.0 REPL session:

user=> (defn foo [a a] [a a])

#'user/foo

ser=> (foo 1 2)

[2 2]

user=> (defn foo2 [_ _] [_ _])

#'user/foo2

user=> (foo2 1 2)

[2 2]


This is the sense in which _ is just another function parameter name, no
more or less special to the compiler than the parameter name 'a'.  There is
no requirement in the Clojure compiler that parameter names are unique.

Andy

On Sat, Jun 17, 2017 at 12:16 PM, Gregg Reynolds  wrote:

>
>
> On Jun 17, 2017 1:55 PM, "Timothy Baldridge"  wrote:
>
> Anonymous implies there might be some sort of auto gen going on (as there
> is with anonymous functions), Irrelevant has my vote therefore. The other
> characteristics are a side-effect of it being a naming convention (with no
> official support by the compiler).
>
>
> yeah, i could go either way, although i might change "var" to "arg" - is
> '_' ever a var?  actually i'm thinking "nonce arg" would be more accurate,
> but then i'm a naming fanatic so take it with a grain of salt.
>
> Maybe that could be pointed out in greater detail. So maybe an edit along
> the lines of:
>
> "Note: _ does not have special functionality in the compiler, it is seen
> the same as any other local or arg, therefore the same rules of uniqueness
> and precedence apply with _ as they would with any other symbol"
>
>
> i might not understand the rules but my understanding is that '_' (as an
> arg) is outside of the uniqueness (obviously) and precedence rules.  i'm
> not understanding the point of your suggested edit, i guess.  thinking from
> a newbie perspective.  are you saying that each '_' gets a gen-sym, so each
> ends up being unique?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] Eastwood, the Clojure lint tool, version 0.2.4 released

[Andy Fingerhut]

I do not know whether you (Peter) are the same as the user pedro-w on
Github, but pedro-w created this Eastwood issue and added a comment with
links to a related discussion on a tools.reader issue tracker:
https://github.com/jonase/eastwood/issues/222

If you can find a way, with just tools.reader alone, to call
clojure.tools.reader/read in such a way that it first reads and uses the
contents of a data_readers.clj file, and then can successfully read the
sample .clj file in that issue #222 that causes Eastwood to fail now, that
sequence of API calls would be useful to know, and might be all that
Eastwood needs to work for projects with a non-empty data_readers.clj
file.  Adding that working sequence of API calls to Eastwood issue #222
would be a good place to document that, if someone finds out how to do it.


Yes, Eastwood does have source code copies of tools.reader and several
other open source libraries inside of itself, renamed to different
namespaces.  Why do such a crazy thing, you might reasonably ask?  Because
then Eastwood can read, analyze, and load tools.reader itself, without
conflicting with the one that Eastwood uses for its own purposes.  If a
project you want to lint via Eastwood is using an older version of
tools.reader, missing some function or feature Eastwood relies on, and
Eastwood didn't use this technique, it would fail on such a project.

I started 'dolly' (https://github.com/jafingerhut/dolly) to assist with
bringing new versions of libraries Eastwood depends upon into Eastwood,
renaming the namespaces semi-automatically for you.  It isn't in a shape
that I would recommend others to use right now, and it might never be in
that kind of shape, but it can do some things.  Its README mentions
mranderson as another similar project that might be better suited for
others.

Andy


On Thu, Jun 1, 2017 at 8:19 AM, Peter Hull <peterhul...@gmail.com> wrote:

> I had a quick look at this. As I understand it, the clojure.core reader
> processes data_readers.clj, but Eastwood uses tools.reader (or a version of
> it, copied into the Eastwood project?) which does not.
>
> I thought that, for linting, we don't need to actually run the data reader
> functions, so it should be possible to use the *default-data-reader-fn*
> mechanism to swallow the tag + value, returning 'something' (doesn't matter
> what, I used (gensym) ).
>
> I tried editing leiningen.eastwood/eastwood, but unfortunately couldn't
> find a way to set *default-data-reader-fn* such that tools.reader could
> pick it up. I am now at the limits of my clojur e knowledge!
>
> Does this sound reasonable? Any ideas what I am doing wrong?
>
> Pete
>
>
>
> On Thursday, 1 June 2017 07:19:04 UTC+1, Peter Hull wrote:
>>
>> On Thursday, 1 June 2017 06:55:52 UTC+1, Andy Fingerhut wrote:
>>>
>>> Sounds like a limitation/bug in the current Eastwood implementation that
>>> it doesn't handle this.  You are welcome to file an issue on Github:
>>> https://github.com/jonase/eastwood/issues
>>>
>>> Thanks for getting back to me. I've filed #222 (
>> https://github.com/jonase/eastwood/issues/222)
>> Pete
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] Eastwood, the Clojure lint tool, version 0.2.4 released

[Andy Fingerhut]

Sounds like a limitation/bug in the current Eastwood implementation that it
doesn't handle this.  You are welcome to file an issue on Github:
https://github.com/jonase/eastwood/issues

Sorry, no promises on when it might be addressed.

Andy

On Wed, May 31, 2017 at 5:39 AM, Peter Hull  wrote:

> On Monday, 22 May 2017 01:51:32 UTC+1, David Cook wrote:
>>
>> Eastwood, the Clojure lint tool, version 0.2.4 has been released.  See
>> install instructions and complete documentation at [1].
>>
> Hi David and others,
> I tried this for the first time on my code and it found some errors
> (hooray!) but also failed to parse some files using tagged literals. Is
> this expected?
>
> As a minimal example I have
>
> === src/ewe/core.clj ===
> (ns ewe.core
>   (:gen-class))
>
> (defn ereader [x] (str "Make my " x ))
>
> (defn -main
>   "I don't do a whole lot ... yet."
>   [& args]
>   (println #ewe/E "day"))
> ===
>
> === src/data_readers.clj
> {ewe/E ewe.core/ereader}
> ===
>
> which runs OK with 'lein run' but with 'lein eastwood' gives:
>
> == Linting ewe.core ==
> Linting failed:
> ExceptionInfo No reader function for tag E
> clojure.core/ex-info (core.clj:4617)
> ...
>
> I am using clojure 1.8.0, fedora 25 (also tried Macos, same result)
>
> Thanks,
> Pete
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: testing println in clojure.test

[Andy Fingerhut]

The with-out-str macro should be able to do this for you.  A few examples
of use can be found on ClojureDocs here:

https://clojuredocs.org/clojure.core/with-out-str

You may find the Clojure cheat sheet useful for discovering things like
this (at least for things the cheat sheet includes -- it doesn't cover any
but a tiny handful of functions outside of Clojure core functionality).  In
particular for your question, the section titled "IO" (i.e. Input/Output),
subsection "to string" would have helped:

https://clojure.org/api/cheatsheet

Andy

On Tue, May 30, 2017 at 2:43 PM, Kevin Kleinfelter <
kleinfelter.gro...@gmail.com> wrote:

> I've got a function which is supposed to println a computed value.  How do
> I test whether it printed that value, when using clojure.test?
>
> Or, another way of asking the same question is how do I grab the output
> from println when testing a function with clojure.test?
>
> TIA
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: 'get' behaviors

[Andy Fingerhut]

On Mon, May 29, 2017 at 1:20 PM,  wrote:
>
> On Monday, 29 May 2017 18:45:20 UTC+1, Nicola Mometto wrote:
>>
>> Issue #1 had been logged in CLJ-1242, but it was later decided to just
>> focus on making equality not throw as contains/get throwing is consistent
>> with java behaviour, see comments from Stu and Alex here
>> https://dev.clojure.org/jira/browse/CLJ-1242?focusedCommentI
>> d=40612=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-40612
>>
>
> Mmmh, I see. I've also seen now that by forcing compare semantic the tree
> search can stay O(logN) average. Removing the compare constraint would make
> the search O(n/2) avg. So there is a point I guess.
>

I believe it is O(log N) worst case, as well as average case, via a
balanced binary tree implementation.


>> I'm not aware of any previous discussion on Issue #3 but IMO this is
>> consistent with clojure's GIGO behaviour
>>
>
> It's kind of border line, because the doc refers to "map" and "key" as
> arguments but then it can also handle other associative things like
> vectors. nth correctly handles the outofbound. Perhaps get should do the
> same.
>

I have noticed this behavior before, but not brought it up in the group,
since my guess is that a programming mistake leading to an actual bug here
seems unlikely (i.e. you wouldn't accidentally get there from sequentially
walking through a list starting at 0 and incrementing by 1, because you'd
pretty much always hit the end of the vector/list/etc. first).  That and
the GIGO behavior that Nicola refers, and a focus on performance, combine
to mean it is unlikely that any change would be made to Clojure that leads
to a longer execution time for get when the index is in range (unlikely is
my guess -- I am not a person who makes these decisions, but have seen
several made in this direction before over the years).

It may be more likely that the Clojure core team would be willing to accept
a change to clojure.spec that would check for such erroneous inputs to
get.  If you are interested, you could try creating a JIRA ticket for a
change like that.  You could mention in the ticket that a change to
clojure.core/get might be interesting, if someone can think of a way that
has no performance impact in the non-error case.

Andy



> My 2C
> Thanks
>
>
>>
>> On 29/05/17 19:15, rebo...@gmail.com wrote:
>>
>> I was wondering if the following 'get' behaviors are worth a chat.
>> Apologies if this is known issue, but they don't seem impossible corner
>> cases to me.
>>
>> #1
>>
>> This one looks read-only access to me and I'm not sure why a suitable
>> comparator should be in place.
>>
>> (get (sorted-map :a 1 :b 2) "a" "not found");; ClassCastException
>>
>> #2
>>
>> 'get' is happy with other transients (namely vectors and maps) but fails 
>> silently on sets:
>>
>> (get (transient #{0 1 2}) 1);; nil
>>
>> #3 (.intValue x) can throw away bits with precision loss. Sufficiently large 
>> keys produce the following:
>>
>> (get ["a" "b" "c"] 4294967296) ;; "a"
>>
>> Thanks
>> Renzo
>>
>> --
>> 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 

Re: SymbolHound search engine

[Andy Fingerhut]

Yep, useful things, those.

"The weird and wonderful characters of Clojure" article is also linked from
the Clojure Cheat Sheet, in the Special Characters section, the link called
"tutorial":

https://clojure.org/api/cheatsheet
http://jafingerhut.github.io

Andy


On Thu, May 25, 2017 at 8:04 AM, Alan Thompson  wrote:

> Hi - Just came across a reference to a search engine *symbolhound.com
> * which explicitely *does not* ignore special
> characters.  This could be very useful in searching for Clojure literals
> like *#{}* & reader macros like *#' *which are difficult to search for
> using Google et al.
>
> Enjoy!
> Alan
>
> P.S.  If you haven't seen it yet, don't forget this nice summary:
> https://yobriefca.se/blog/2014/05/19/the-weird-and-
> wonderful-characters-of-clojure/
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: slackpocalypse?

[Andy Fingerhut]

I have no skin in this game, but wasn't the move to Slack pretty much a
"vote with your feet" combined with word of mouth advertising?  It seems to
me the same could happen to add another on-line chat tool/system, without
anyone taking a poll/voting on this or any other medium.  We'll know when
it has happened by the rumor mill on Slack, IRC, and/or this email group.

Andy

On Tue, May 23, 2017 at 2:04 PM, Colin Fleming 
wrote:

> On 24 May 2017 at 00:13, Herwig Hochleitner 
> wrote:
>
>> I doubt the whole community would want to move anywhere from Slack.
>>
>
> Perhaps this will have to wait until Slack inevitably throws us off, then.
>
> What would you need to solve your discoverability issues (a)? Isn't it as
>> easy as handing out a link like https://riot.im/app/#/roo
>> m/#clojure-community:matrix.org ? Not even registration needed.
>>
>
> It's a far cry from searching for "cursive" from anywhere in Clojurians,
> though. Searching for channels based on some vague criteria seemed
> difficult, and searching for Clojure related content across channels is
> also a pretty bad experience. There has been some talk of making a
> Clojure-related room directory in an external webpage or something but it's
> still a kludge. I'm not sure to what extent this would be fixed if we ran
> our own room server, but then someone has to maintain that.
>
>
>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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] Eastwood, the Clojure lint tool, version 0.2.4 released

[Andy Fingerhut]

Eastwood analyzes your code to look for constructs that might be errors.

Kibit analyzes code to look for places where you could use Clojure macros
or functions that may make your code shorter, or more idiomatic.

Andy

On Tue, May 23, 2017 at 9:16 AM, Travis Daudelin 
wrote:

>  Hi, thanks for posting this looks great!
>
> Is there any overlap in functionality between Eastwood and Kibit
> ? It's not clear to me which tool I
> should prefer nor when.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] Eastwood, the Clojure lint tool, version 0.2.4 released

[Andy Fingerhut]

And I would hasten to add David Cook to the list of developers.  He has
done the coding, testing, and release steps except deploying to Clojars.
Thank you, David!

Andy

On Sun, May 21, 2017 at 5:46 PM, David Cook <divergentd...@gmail.com> wrote:

> Eastwood, the Clojure lint tool, version 0.2.4 has been released.  See
> install instructions and complete documentation at [1].
>
> Below are some of the changes since version 0.2.3.  A complete list is at
> [2].
>
> Go squash some bugs!
>
> Jonas Enlund, Nicola Mometto, and Andy Fingerhut
>
> [1] https://github.com/jonase/eastwood
> [2] https://github.com/jonase/eastwood/blob/master/changes.md#
> changes-from-version-023-to-024
>
>
> No new linters. Added initial support for .cljc files and reader
> conditionals.
>
>-
>
>Read .cljc files in addition to .clj files when scanning namespaces.
>-
>
>Handle reader conditionals by always parsing the :clj branch.
>-
>
>Allow ClojureScript-specific libspec entries, such as :include-macros
>true.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.