bat-test: How can I stop the capture of test output?

[Alan Thompson]

Does anybody here use `bat-test` with boot?  It defaults to capturing all
test output, and I can't figure out how to stop that.

Thanks,
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/CAN67zA1Ni84FyCRgRhD%3DyAcHHosmd5xnR7iEqmpdu3bSk7iazQ%40mail.gmail.com.

Re: how to package a project to a jar file?

[Alan Thompson]

You could also check out depstar

https://github.com/seancorfield/depstar


On Tue, Sep 14, 2021 at 8:35 AM c y  wrote:

> i can't use lein
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/485ed672-20d6-4325-bcef-5162395481f0n%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/CAN67zA2FkKrwNb34SFvpeFQT%2B7TQ5KZb53UqKePLs8mDACQFqg%40mail.gmail.com.

First build of Tupelo Clojure using Java 17 (Clojure 1.11.0-alpha1)

[Alan Thompson]

and everything is working fine (as expected!).

25936  lines of Clojure
  419  tests
4014 assertions




~/tupelo > lein clean; lein test

Java HotSpot(TM) 64-Bit Server VM warning: Options -Xverify:none and
-noverify were
  deprecated in JDK 13 and will likely be removed in a future release.

lein test tst._bootstrap

--
   Clojure 1.11.0-alpha1Java 17
--

lein test tst.tupelo.array

lein test tst.tupelo.array.mutable

lein test tst.tupelo.async

lein test tst.tupelo.base64

lein test tst.tupelo.base64url

lein test tst.tupelo.bits

lein test tst.tupelo.chars

lein test tst.tupelo.core

lein test tst.tupelo.csv

lein test tst.tupelo.demo

lein test tst.tupelo.deprecated

lein test tst.tupelo.dev

lein test tst.tupelo.forest

..

lein test tst.tupelo.y64

Ran 419 tests containing 4014 assertions.
0 failures, 0 errors.

53.88s user 3.08s system 259% cpu 21.940 total

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

An Intuition for Lisp Syntax

[Alan Thompson]

Nice article on how you can "discover" lisp:  https://stopa.io/post/265

Enjoy!
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/CAN67zA0RcWPB6F8sdMg%2BoJxr5YF-cVY3oNLv-x3UJuTVVH2KZw%40mail.gmail.com.

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

[Alan Thompson]

I verified the problem in the StackOverflow post.  For some reason keyword
lookup of record fields in CLJS doesn't work.
Alan

On Tue, Aug 4, 2020 at 12:05 PM Justin Smith  wrote:

> I don't think this is true, or if true is incidental to the real problem
>
> % cljs
> ClojureScript 1.10.758
> cljs.user=> (defrecord Attr [has-default default])
> cljs.user/Attr
> cljs.user=> (get (->Attr true 1) :default)
> 1
> cljs.user=> (:default (->Attr true 1))
> nil
> cljs.user=>
>
> On Tue, Aug 4, 2020 at 11:53 AM Mark Engelberg 
> wrote:
> >
> > You misspelled default in your defrecord.
> >
> > On Tue, Aug 4, 2020 at 7:42 AM 'clartaq' via Clojure <
> clojure@googlegroups.com> wrote:
> >>
> >> I originally posted this on StackOverflow.
> >>
> >> When I try this:
> >>
> >> ```clojure
> >> (defrecord Attr [has-default default])
> >> (def attr (->Attr true 1))
> >> (get attr :default) ;;=> 1
> >> (:default attr) ;;=> ClojureScript returns nil, Clojure returns 1
> >> ```
> >>
> >> Is the difference in behavior when using keyword access expected? I
> couldn't find anything about it in the [docs][1]  on the differences
> between Clojure and ClojureScript.
> >>
> >> **Update 2020-08-04**
> >>
> >> Well, this is getting weird. This morning, if I open a REPL with
> figwheel-main, or from CIDER, it sometimes works as expected -- `(:default
> attr)` returns 1.
> >>
> >> If I try it by opening the ClojureScript REPL using `clj`, it is still
> broken.
> >>
> >> ```clojure
> >> % clj --main cljs.main --repl
> >> ClojureScript 1.10.773
> >> cljs.user=> (defrecord Attr [has-default defaut])
> >> cljs.user/Attr
> >> cljs.user=> (def attr (->Attr true 1))
> >> #'cljs.user/attr
> >> cljs.user=> (get attr :default)
> >> nil
> >> cljs.user=> (:default attr)
> >> nil
> >> cljs.user=> (:has-default attr)
> >> true
> >> cljs.user=> (println "attr: " attr)
> >> attr:  #cljs.user.Attr{:has-default true, :defaut 1}
> >> nil
> >> ```
> >>
> >>
> >>   [1]: https://www.clojurescript.org/about/differences#_data_structures
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/5dd44871-3915-4d80-a959-28be44c8cc32o%40googlegroups.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAORbMON7N3ukBEn%3D%3DzX8pAz3tJg%2BjX32x4TTDDqYdCxbWDswbA%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/CAGokn9LpwPYku9606pYXXzLSGQp6aphtsvckjd%3DASG6JEQM2VA%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 

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Alan Thompson]

Hi Alex,

1. Great news that the Homebrew team has responded to your request to point
only to stable versions.

2. The resources directory is the contains the path
`resources/public/index.html`.  The local one is definitely not the one
being served in my original example (2nd half) re 1.10.1.645 when the
`resources` dir was listed near the end. The `index.html` being found by
the Figwheel.Main server had different contents, and was pointing to a
different *.js executable file (possibly in a different *.jar file?).  That
is the source of the 2-word `Debux Test` webpage.

3. Unless I'm missing something, I believe we have already run your
suggested test. Using 1.10.1.561 from `brew install clojure/tools/clojure`,
I got the `resources` and `target` dirs as items #1 and #2 on the
classpath; everything worked as expected.  Using 1.10.1.645 from `brew
install clojure`, `resources` was near the end of the classpath and it
failed (I didn't track down where the `target` dir wound up in that
instance).

4. I could possibly try to replicate your proposed experiment explicitly,
but I no longer have easy access to 1.10.1.645 since Homebrew has been
fixed.  I did find the `brew-install` repo on GH, but am not certain how to
replicate the broken install of *.645.

Thank you for the attention you are giving to this issue.

Alan



On Tue, Aug 11, 2020 at 5:41 PM 'Alex Miller' via Clojure <
clojure@googlegroups.com> wrote:

> Can you change that resources file and see if what you're looking at
> changes to double check? I did actually check a bunch of jars from the
> prior message and did some searching for that message. Or you could even
> dump the classpath with -Spath, then move resources to the front, then use
> -Scp (which will force the classpath you say, ignoring everything else).
>
> Or could be that it's not the index.html but something it refers to
> getting picked up from elsewhere?
>
> On Tue, Aug 11, 2020 at 6:18 PM Alan Thompson  wrote:
>
>> Hi - I just tried your suggestion and no joy:
>>
>>
>> ~/work/tmp810/xanadu >   clj -e "((requiring-resolve '
>> clojure.java.io/resource) \"public/index.html\")"
>> DEPRECATED: Libs must be qualified, change deps-ancient =>
>> deps-ancient/deps-ancient (deps.edn)
>> DEPRECATED: Libs must be qualified, change reagent => reagent/reagent
>> (deps.edn)
>> DEPRECATED: Libs must be qualified, change ns-tracker =>
>> ns-tracker/ns-tracker (deps.edn)
>> DEPRECATED: Libs must be qualified, change camel-snake-kebab =>
>> camel-snake-kebab/camel-snake-kebab (deps.edn)
>> DEPRECATED: Libs must be qualified, change bidi => bidi/bidi (deps.edn)
>> DEPRECATED: Libs must be qualified, change orchestra =>
>> orchestra/orchestra (deps.edn)
>> DEPRECATED: Libs must be qualified, change cljs-ajax =>
>> cljs-ajax/cljs-ajax (deps.edn)
>> DEPRECATED: Libs must be qualified, change expound => expound/expound
>> (deps.edn)
>> DEPRECATED: Libs must be qualified, change re-frame => re-frame/re-frame
>> (deps.edn)
>> DEPRECATED: Libs must be qualified, change re-frame-utils =>
>> re-frame-utils/re-frame-utils (deps.edn)
>> DEPRECATED: Libs must be qualified, change cljs-bean =>
>> cljs-bean/cljs-bean (deps.edn)
>> #object[java.net.URL 0x6c345c5f
>> "file:/Users/alanthompson/work/tmp810/xanadu/resources/public/index.html"]
>>
>>
>> The call to `requiring-resolve` claims it is finding my local
>> `./resources/public/index.html`.  However, the error remains that it is
>> finding some other `index.html`, which also points to an incorrect JS
>> output file.
>>
>> Alan
>>
>>
>>
>>
>> On Tue, Aug 11, 2020 at 2:15 PM 'Alex Miller' via Clojure <
>> clojure@googlegroups.com> wrote:
>>
>>>
>>> On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
>>> clojure@googlegroups.com> wrote:
>>>
>>>> Here's some maven-specific discussion:
>>>> https://stackoverflow.com/questions/793054/maven-classpath-order-issue.
>>>> They have a defined order since 2.0.9. and declaration order is
>>>> considered for transitive dependencies conflict.
>>>>
>>>
>>> Unfortunately, neither that 11 year old SO answer nor the referenced
>>> jiras actually document, explain, or refer to any documentation about the
>>> ordering, or afaict commit to anything specific other than reproducibility.
>>> I'm not saying this is your fault or anything, just does not seem well
>>> defined to me other than as an artifact of implementation.
>>>
>>> For libs, Maven (and I presume lein which relies on 

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Alan Thompson]

Hi - I just tried your suggestion and no joy:


~/work/tmp810/xanadu >   clj -e "((requiring-resolve '
clojure.java.io/resource) \"public/index.html\")"
DEPRECATED: Libs must be qualified, change deps-ancient =>
deps-ancient/deps-ancient (deps.edn)
DEPRECATED: Libs must be qualified, change reagent => reagent/reagent
(deps.edn)
DEPRECATED: Libs must be qualified, change ns-tracker =>
ns-tracker/ns-tracker (deps.edn)
DEPRECATED: Libs must be qualified, change camel-snake-kebab =>
camel-snake-kebab/camel-snake-kebab (deps.edn)
DEPRECATED: Libs must be qualified, change bidi => bidi/bidi (deps.edn)
DEPRECATED: Libs must be qualified, change orchestra => orchestra/orchestra
(deps.edn)
DEPRECATED: Libs must be qualified, change cljs-ajax => cljs-ajax/cljs-ajax
(deps.edn)
DEPRECATED: Libs must be qualified, change expound => expound/expound
(deps.edn)
DEPRECATED: Libs must be qualified, change re-frame => re-frame/re-frame
(deps.edn)
DEPRECATED: Libs must be qualified, change re-frame-utils =>
re-frame-utils/re-frame-utils (deps.edn)
DEPRECATED: Libs must be qualified, change cljs-bean => cljs-bean/cljs-bean
(deps.edn)
#object[java.net.URL 0x6c345c5f
"file:/Users/alanthompson/work/tmp810/xanadu/resources/public/index.html"]


The call to `requiring-resolve` claims it is finding my local
`./resources/public/index.html`.  However, the error remains that it is
finding some other `index.html`, which also points to an incorrect JS
output file.

Alan




On Tue, Aug 11, 2020 at 2:15 PM 'Alex Miller' via Clojure <
clojure@googlegroups.com> wrote:

>
> On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
> clojure@googlegroups.com> wrote:
>
>> Here's some maven-specific discussion:
>> https://stackoverflow.com/questions/793054/maven-classpath-order-issue.
>> They have a defined order since 2.0.9. and declaration order is
>> considered for transitive dependencies conflict.
>>
>
> Unfortunately, neither that 11 year old SO answer nor the referenced jiras
> actually document, explain, or refer to any documentation about the
> ordering, or afaict commit to anything specific other than reproducibility.
> I'm not saying this is your fault or anything, just does not seem well
> defined to me other than as an artifact of implementation.
>
> For libs, Maven (and I presume lein which relies on Maven libs for this)
> uses the ordering of deps in the pom wrt the ordering in the classpath. clj
> intentionally does not include this ordering - the libs are in an unordered
> map, the version selection algorithm is completely different, etc. If this
> matters, then one of your deps is broken and should be fixed.
>
>
>> Intellij's Dependencies tab in Module settings: You can re-order the
>> dependencies and they reflect in the classpath.
>>
>
> Not sure that has anything to do with Maven or lein, seems orthogonal to
> the question here.
>
>
>>
>> lein classpath -> local paths added first, JARs afterwards
>>
>> Please consider returning to a :paths first, then :deps in a stable order.
>>
>
> I will consider some options.
>
>
>>
>> I know it is not pretty and it is not desirable for code to be dependent
>> on that, but resource-loading uses the CLASSPATH and that makes the order
>> of dependencies intrinsically linked to locating resources.
>>
>
>> I'd also rather fighweel-main behave differently, but it relies on
>> (io/resource "public/index.html")
>>
>
> I think that is perfectly ok - the problem here is whether a jar includes
> that resource, which is likely to conflict. I'd be very interested to know
> whether this is actually a jar or an issue with the ordering of your local
> paths. To check where it's finding index.html:
>
> clj -e "((requiring-resolve 'clojure.java.io/resource)
> \"public/index.html\")"
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAOdgdgz88M5jfbSOb2yTkehh3b32uQ6rh0bqa44T7J7hnP7LBQ%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 

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Alan Thompson]

P.S.  There seems to be no *`clojure --version`* flag.  Should this be
added to the command line tool?


On Mon, Aug 10, 2020 at 4:58 PM Alan Thompson  wrote:

> Hi.  Just helped a colleague debug a vexing problem on a CLJS project
> using Figwheel.Main.
>
> If we do *`brew install clojure/tools/clojure`*, it works:
>
> ~/work/tmp810/xanadu > clj --help
> Version: *1.10.1.561*
>
> Usage: clojure [dep-opt*] [--] [init-opt*] [main-opt] [arg*]
>clj [dep-opt*] [--] [init-opt*] [main-opt] [arg*]
>
> The clojure script is a runner for Clojure. clj is a wrapper
> for interactive repl use. These scripts ultimately construct and
> 
>
>
> Note that local ./resources etc are at the beginning of the classpath
>
> ~/work/tmp810/xanadu > clj -Spath
> *resources:target:src/clj:src/cljc:src/cljs:test/cljs:test-figwheel-main*
> :/Users/alanthompson/.m2/repository/com/cognitect/transit-java/0.8.332/transit-java-0.8.332.jar:/Users/alanthompson/.m2/repository/com/google/elemental2/elemental2-core/1.0.0-RC1/elemental2-core-1.0.0-RC1.jar:/Users/alanthompson/.m2/repository/org/clojure/data.json/0.2.6/data.json-0.2.6.jar:/Users/alanthompson/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar:/Users/alanthompson/.m2/repository/day8/re-frame/test/0.1.5/test-0.1.5.jar:/Users/alanthompson/.m2/repository/commons-codec/commons-codec/1.11/commons-codec-1.11.jar:/Users/alanthompson/.m2/repository/cljsjs/material-ui-currency-textfield/0.8.6-0/material-ui-currency-textfield-0.8.6-0.jar:/Users/alanthompson/.m2/repository/org/clojure/tools.analyzer/1.0.0/tools.analyzer-1.0.0.jar:/Users/alanthompson/.m2/repository/com/bhauman/cljs-test-display/0.1.1/cljs-test-display-0.1.1.jar:/Users/alanthompson/.m2/repository/org/eclipse/jetty/jetty-xml/9.4.28.v20200408/jetty-xml-9.4.28.v20200408.jar:/Users/alanthompson/.m2/repository/com/bhauman/figwheel-repl/0.2.11/figwheel-repl-0.2.11.jar:/Users/alanthompson/.m2/repository/org/eclipse/jetty/jetty-servlet/9.4.28.v20200408/jetty-servlet-9.4.28.v20200408.jar:/Users/alanthompson/.m2/repository/ring/ring-devel/1.8.1/ring-devel-1.8.1.jar:/Users/alanthompson/.m2/repository/com/google/errorprone/error_prone_annotations/2.3.1/error_prone_annotations-2.3.1.jar:/Users/alanthompson/.m2/repository/org/clojure/tools.logging/0.3.1/tools.logging-0.3.1.jar:/Users/alanthompson/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar:/Users/alanthompson/.m2/repository/co/deps/ring-etag-middleware/0.2.0/ring-etag-middleware-0.2.0.jar:/Users/alanthompson/.m2/repository/expound/expound/0.7.2/expound-0.7.2.jar:/Users/alanthompson/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar:/Users/alanthompson/.m2/repository/com/cemerick/url/0.1.1/url-0.1.1.jar:
>
> ..
>
>
> However, my colleague had accidentally typed *`brew install clojure`.  *This
> caused a mysterious failure:
>
> ---
> ~/work/tmp810/xanadu > clojure --help
> Version: *1.10.1.645*
>
> You use the Clojure tools ('clj' or 'clojure') to run Clojure programs
> on the JVM, e.g. to start a REPL or invoke a specific function with data.
> 
>
> and the classpath
>
> -
> ~/work/tmp810/xanadu > clj -Spath
> DEPRECATED: Libs must be qualified, change deps-ancient =>
> deps-ancient/deps-ancient (deps.edn)
> DEPRECATED: Libs must be qualified, change reagent => reagent/reagent
> (deps.edn)
> DEPRECATED: Libs must be qualified, change ns-tracker =>
> ns-tracker/ns-tracker (deps.edn)
> DEPRECATED: Libs must be qualified, change camel-snake-kebab =>
> camel-snake-kebab/camel-snake-kebab (deps.edn)
> DEPRECATED: Libs must be qualified, change bidi => bidi/bidi (deps.edn)
> DEPRECATED: Libs must be qualified, change orchestra =>
> orchestra/orchestra (deps.edn)
> DEPRECATED: Libs must be qualified, change cljs-ajax =>
> cljs-ajax/cljs-ajax (deps.edn)
> DEPRECATED: Libs must be qualified, change expound => expound/expound
> (deps.edn)
> DEPRECATED: Libs must be qualified, change re-frame => re-frame/re-frame
> (deps.edn)
> DEPRECATED: Libs must be qualified, change re-frame-utils =>
> re-frame-utils/re-frame-utils (deps.edn)
> DEPRECATED: Libs must be qualified, change cljs-bean =>
> cljs-bean/cljs-bean (deps.edn)
>
> /Users/alanthompson/.m2/repository/alandipert/storage-atom/1.2.4/storage-atom-1.2.4.jar:/Users/alanthompson/.m2/repository/com/google/errorprone/error_prone_annotations/2.3.1/error_prone_annotations-2.3.1.jar:/Users/alanthompson/.m2/repository/org/clojure/core.cache/1.0.207/core.cache-1.0.207.jar:/Users/alanthompson/.m2/repository/com/google/jsinterop/jsinterop-annotations/1.0.2/jsinterop-annotations-1.0.2.jar:/Users/alanthompson/.m2/repository/compliment/compliment/0.3.6/compliment-0.3.6.jar:/Users/alanthompson/.m2/repository/ring/r

Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Alan Thompson]

Hi.  Just helped a colleague debug a vexing problem on a CLJS project using
Figwheel.Main.

If we do *`brew install clojure/tools/clojure`*, it works:

~/work/tmp810/xanadu > clj --help
Version: *1.10.1.561*

Usage: clojure [dep-opt*] [--] [init-opt*] [main-opt] [arg*]
   clj [dep-opt*] [--] [init-opt*] [main-opt] [arg*]

The clojure script is a runner for Clojure. clj is a wrapper
for interactive repl use. These scripts ultimately construct and



Note that local ./resources etc are at the beginning of the classpath

~/work/tmp810/xanadu > clj -Spath
*resources:target:src/clj:src/cljc:src/cljs:test/cljs:test-figwheel-main*
:/Users/alanthompson/.m2/repository/com/cognitect/transit-java/0.8.332/transit-java-0.8.332.jar:/Users/alanthompson/.m2/repository/com/google/elemental2/elemental2-core/1.0.0-RC1/elemental2-core-1.0.0-RC1.jar:/Users/alanthompson/.m2/repository/org/clojure/data.json/0.2.6/data.json-0.2.6.jar:/Users/alanthompson/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar:/Users/alanthompson/.m2/repository/day8/re-frame/test/0.1.5/test-0.1.5.jar:/Users/alanthompson/.m2/repository/commons-codec/commons-codec/1.11/commons-codec-1.11.jar:/Users/alanthompson/.m2/repository/cljsjs/material-ui-currency-textfield/0.8.6-0/material-ui-currency-textfield-0.8.6-0.jar:/Users/alanthompson/.m2/repository/org/clojure/tools.analyzer/1.0.0/tools.analyzer-1.0.0.jar:/Users/alanthompson/.m2/repository/com/bhauman/cljs-test-display/0.1.1/cljs-test-display-0.1.1.jar:/Users/alanthompson/.m2/repository/org/eclipse/jetty/jetty-xml/9.4.28.v20200408/jetty-xml-9.4.28.v20200408.jar:/Users/alanthompson/.m2/repository/com/bhauman/figwheel-repl/0.2.11/figwheel-repl-0.2.11.jar:/Users/alanthompson/.m2/repository/org/eclipse/jetty/jetty-servlet/9.4.28.v20200408/jetty-servlet-9.4.28.v20200408.jar:/Users/alanthompson/.m2/repository/ring/ring-devel/1.8.1/ring-devel-1.8.1.jar:/Users/alanthompson/.m2/repository/com/google/errorprone/error_prone_annotations/2.3.1/error_prone_annotations-2.3.1.jar:/Users/alanthompson/.m2/repository/org/clojure/tools.logging/0.3.1/tools.logging-0.3.1.jar:/Users/alanthompson/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar:/Users/alanthompson/.m2/repository/co/deps/ring-etag-middleware/0.2.0/ring-etag-middleware-0.2.0.jar:/Users/alanthompson/.m2/repository/expound/expound/0.7.2/expound-0.7.2.jar:/Users/alanthompson/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar:/Users/alanthompson/.m2/repository/com/cemerick/url/0.1.1/url-0.1.1.jar:

..


However, my colleague had accidentally typed *`brew install clojure`.  *This
caused a mysterious failure:

---
~/work/tmp810/xanadu > clojure --help
Version: *1.10.1.645*

You use the Clojure tools ('clj' or 'clojure') to run Clojure programs
on the JVM, e.g. to start a REPL or invoke a specific function with data.


and the classpath

-
~/work/tmp810/xanadu > clj -Spath
DEPRECATED: Libs must be qualified, change deps-ancient =>
deps-ancient/deps-ancient (deps.edn)
DEPRECATED: Libs must be qualified, change reagent => reagent/reagent
(deps.edn)
DEPRECATED: Libs must be qualified, change ns-tracker =>
ns-tracker/ns-tracker (deps.edn)
DEPRECATED: Libs must be qualified, change camel-snake-kebab =>
camel-snake-kebab/camel-snake-kebab (deps.edn)
DEPRECATED: Libs must be qualified, change bidi => bidi/bidi (deps.edn)
DEPRECATED: Libs must be qualified, change orchestra => orchestra/orchestra
(deps.edn)
DEPRECATED: Libs must be qualified, change cljs-ajax => cljs-ajax/cljs-ajax
(deps.edn)
DEPRECATED: Libs must be qualified, change expound => expound/expound
(deps.edn)
DEPRECATED: Libs must be qualified, change re-frame => re-frame/re-frame
(deps.edn)
DEPRECATED: Libs must be qualified, change re-frame-utils =>
re-frame-utils/re-frame-utils (deps.edn)
DEPRECATED: Libs must be qualified, change cljs-bean => cljs-bean/cljs-bean
(deps.edn)

Re: bit-wise operators for bigint in Clojure

[Alan Thompson]

In Clojure, it is probably easiest to just use Java interop, eg:
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/math/BigInteger.html#setBit(int)
Alan


On Tue, May 26, 2020 at 9:39 AM Harmon Nine  wrote:

> Hello.
>
> I noticed a post about this from 2013, so doing a bump.
>
> The bit-wise operators appear to be supported for 'bigint' in
> ClojureScript, but not in Clojure.  Is support for these operations on
> 'bigint' in Clojure a future enhancement?
>
> Thanks :)
> -- Harmon
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/4b6e3f5e-c70c-404a-9348-8117a4b32db8%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/CAN67zA2sC%3D2TQYpWaZsfmPuGErTKmkY4buB2M3qPwRgJM%2Bpwxg%40mail.gmail.com.

Excellent series of videos by Uncle Bob Martin

[Alan Thompson]

I think everyone can benefit from viewing this material:


   - Clean Code - pt 1 
   - Clean Code - pt 2 
   - Clean Code - pt 3 
   - Clean Code - pt 4 
   - Clean Code - pt 5 
   - Clean Code - pt 6 


Enjoy!
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/CAN67zA13%2BJf19Jv4%2B-Vmahkxxp0-tWhhS_mPModdy30syJ1%2B2A%40mail.gmail.com.

Re: Strange result for clojure.core/time

[Alan Thompson]

I now feel like Homer Simpson.  Doh!
Alan

On Sat, Apr 11, 2020 at 2:34 AM Paul Stadig  wrote:

> The output of `time` is in milliseconds and the output of
> `with-timer-print` is in seconds. So to make them comparable:
> `time` 0.01344 msec
> `time` with eval 0.922536 msec
>
> `with-timer-print` 0.048 msec
> `with-timer-print` with eval 1.041 msec
>
> The `with-timer-print` version is slower, and I suspect it is the use of
> `format` instead of `str`.
>
> Paul
>
> On Fri, Apr 10, 2020 at 8:46 PM Alan Thompson  wrote:
>
>> I was doing some macro work and was curious about the cost of an inline
>> `eval` vs compiled code.  I tried to time it with `clojure.core/time` and
>> got results I can't explain:
>>
>>
>> (println :eval-time)
>> (time
>>   (do
>> (println (eval (quote (+ 40 0
>> (println (eval (quote (+ 40 1
>> (println (eval (quote (+ 40 2
>> (println (eval (quote (+ 40 3
>> (println (eval (quote (+ 40 4))
>>
>>
>> :eval-time
>> 40
>> 41
>> 42
>> 43
>> 44
>> "Elapsed time: 0.922536 msecs"
>>
>> On a modern computer, this is an insanely long amount of time. And yes,
>> it is approx 5x longer than doing just one line of the above.  I also tried
>> it without the eval:
>>
>> (println :add-time)
>> (time
>>   (do
>> (println (+ 30 0))
>> (println (+ 30 1))
>> (println (+ 30 2))
>> (println (+ 30 3))
>> (println (+ 30 4
>>
>>
>> :add-time
>> 30
>> 31
>> 32
>> 33
>> 34
>> "Elapsed time: 0.01344 msecs"
>>
>> Still seems pretty slow to just print 5 lines with a single addition each.
>>
>> The `time` macro is very simple, and is often used as introductory
>> example of how macros work and when they are needed:
>>
>> (defmacro time
>>   "Evaluates expr and prints the time it took.  Returns the value of
>>  expr."
>>   {:added "1.0"}
>>   [expr]
>>   `(let [start# (. System (nanoTime))
>>  ret# ~expr]
>>  (prn (str "Elapsed time: " (/ (double (- (. System (nanoTime)) start#)) 
>> 100.0) " msecs"))
>>  ret#))
>>
>>
>> I coincidentally had a homegrown timer available with nearly identical
>> code.  It has results:
>>
>> (prof/with-timer-print :add-prof
>>   (do
>> (println (+ 10 0))
>> (println (+ 10 1))
>> (println (+ 10 2))
>> (println (+ 10 3))
>> (println (+ 10 4
>>
>>
>> 10
>> 11
>> 12
>> 13
>> 14
>> :with-timer-print :add-prof 0.48
>>
>>
>>
>> and
>>
>> (prof/with-timer-print :eval-prof
>>   (do
>> (println (eval (quote (+ 20 0
>> (println (eval (quote (+ 20 1
>> (println (eval (quote (+ 20 2
>> (println (eval (quote (+ 20 3
>> (println (eval (quote (+ 20 4))
>>
>>
>> 20
>> 21
>> 22
>> 23
>> 24
>> :with-timer-print :eval-prof 0.001041
>>
>> So we see the times are much, much shorter.  The timing code is nearly
>> identical to clojure.core/time:
>>
>> (defmacro with-timer-result
>>   "Times execution of Clojure forms, returning a result map like:
>>   {:result result  :seconds seconds} "
>>   [& forms]
>>   `(let [start#   (System/nanoTime)
>>  result#  (do ~@forms)
>>  stop#(System/nanoTime)
>>  elapsed# (double (- stop# start#))
>>  seconds# (/ elapsed# 1e9)]
>>  {:result  result#
>>   :seconds seconds#}))
>>
>> (defmacro with-timer-print
>>   "Times execution of Clojure forms, printing the result to the screen. "
>>   [id & forms]
>>   (when-not (keyword? id)
>> (throw (ex-info "id must be a keyword" (vals->map id
>>   `(let [result-map# (with-timer-result ~@forms)]
>>  (println (format ":with-timer-print %s %12.6f" ~id (grab :seconds 
>> result-map#)))
>>  (grab :result result-map#)))
>>
>>
>> Does anyone have an idea of why `clojure.core/time` gives such insanely
>> inflated results?
>>
>> Alan
>>
>> PS.  I ran the above 4 sequences multiple times using lein-test-refresh,
>> and these were the shortest I could get.  I'm pretty confident the answer
>> is not loading, compiling, or JIT related.
>>
>>
>

Strange result for clojure.core/time

[Alan Thompson]

I was doing some macro work and was curious about the cost of an inline
`eval` vs compiled code.  I tried to time it with `clojure.core/time` and
got results I can't explain:


(println :eval-time)
(time
  (do
(println (eval (quote (+ 40 0
(println (eval (quote (+ 40 1
(println (eval (quote (+ 40 2
(println (eval (quote (+ 40 3
(println (eval (quote (+ 40 4))


:eval-time
40
41
42
43
44
"Elapsed time: 0.922536 msecs"

On a modern computer, this is an insanely long amount of time. And yes, it
is approx 5x longer than doing just one line of the above.  I also tried it
without the eval:

(println :add-time)
(time
  (do
(println (+ 30 0))
(println (+ 30 1))
(println (+ 30 2))
(println (+ 30 3))
(println (+ 30 4


:add-time
30
31
32
33
34
"Elapsed time: 0.01344 msecs"

Still seems pretty slow to just print 5 lines with a single addition each.

The `time` macro is very simple, and is often used as introductory example
of how macros work and when they are needed:

(defmacro time
  "Evaluates expr and prints the time it took.  Returns the value of
 expr."
  {:added "1.0"}
  [expr]
  `(let [start# (. System (nanoTime))
 ret# ~expr]
 (prn (str "Elapsed time: " (/ (double (- (. System (nanoTime))
start#)) 100.0) " msecs"))
 ret#))


I coincidentally had a homegrown timer available with nearly identical
code.  It has results:

(prof/with-timer-print :add-prof
  (do
(println (+ 10 0))
(println (+ 10 1))
(println (+ 10 2))
(println (+ 10 3))
(println (+ 10 4


10
11
12
13
14
:with-timer-print :add-prof 0.48



and

(prof/with-timer-print :eval-prof
  (do
(println (eval (quote (+ 20 0
(println (eval (quote (+ 20 1
(println (eval (quote (+ 20 2
(println (eval (quote (+ 20 3
(println (eval (quote (+ 20 4))


20
21
22
23
24
:with-timer-print :eval-prof 0.001041

So we see the times are much, much shorter.  The timing code is nearly
identical to clojure.core/time:

(defmacro with-timer-result
  "Times execution of Clojure forms, returning a result map like:
  {:result result  :seconds seconds} "
  [& forms]
  `(let [start#   (System/nanoTime)
 result#  (do ~@forms)
 stop#(System/nanoTime)
 elapsed# (double (- stop# start#))
 seconds# (/ elapsed# 1e9)]
 {:result  result#
  :seconds seconds#}))

(defmacro with-timer-print
  "Times execution of Clojure forms, printing the result to the screen. "
  [id & forms]
  (when-not (keyword? id)
(throw (ex-info "id must be a keyword" (vals->map id
  `(let [result-map# (with-timer-result ~@forms)]
 (println (format ":with-timer-print %s %12.6f" ~id (grab :seconds
result-map#)))
 (grab :result result-map#)))


Does anyone have an idea of why `clojure.core/time` gives such insanely
inflated results?

Alan

PS.  I ran the above 4 sequences multiple times using lein-test-refresh,
and these were the shortest I could get.  I'm pretty confident the answer
is not loading, compiling, or JIT related.

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

Re: Using Deps/CLI for building mixed Clojure & Java projects

[Alan Thompson]

Since Kaocha already uses a short shell script to kick things off, I just
added a manual Java compile step there.  I saved the results in my Clojure
template project:

https://github.com/io-tupelo/clj-template

I'll still take a closer look at badigeon in the future.  It seems to have
many useful features.

Alan


On Thu, Apr 2, 2020 at 2:32 PM Sean Corfield  wrote:

> And you might look at https://github.com/EwenG/badigeon (which is listed
> on that tools page) since it says it will "Compile java sources"
> according to the readme
>
> On Thu, Apr 2, 2020 at 2:30 PM Sean Corfield  wrote:
>
>> You would need to write a Clojure script with a -main function that would
>> (somehow) compile Java source code according to whatever rules you wanted
>> and then invoke it from the CLI (as an initial step to get the compiled
>> class files onto the classpath that a subsequent CLI invocation could use).
>>
>> It would be just another tool like any of the others listed here:
>> https://github.com/clojure/tools.deps.alpha/wiki/Tools
>>
>> On Thu, Apr 2, 2020 at 2:18 PM Alan Thompson  wrote:
>>
>>> I've seen this conversation:
>>> https://clojureverse.org/t/is-there-a-sales-pitch-for-switching-to-deps-edn-from-lein-in-2020/5367/15
>>>
>>> which seems to say there is no existing way to combine Java & Clojure
>>> source code when building with deps/CLI.  Is this correct?
>>>
>>> If so, what would be entailed in enhancing Deps/CLI to handle Java
>>> source files?
>>>
>>> Thanks,
>>> 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/CAN67zA3%3DxtbsaC3iGgBSjPgUjw0LwZp%2Bu6bM54ktr1svgxeESQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/clojure/CAN67zA3%3DxtbsaC3iGgBSjPgUjw0LwZp%2Bu6bM54ktr1svgxeESQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> 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)
>>
>
>
> --
> 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/CAD4thx8pLe4mnDvQyb0Sf%2BfrpHNc_NKA5RO4bFKw69SDvrCuAQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/clojure/CAD4thx8pLe4mnDvQyb0Sf%2BfrpHNc_NKA5RO4bFKw69SDvrCuAQ%40mail.gmail.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/CAN67zA3csMt8-u%3DxRi-9ndoOf78%2B%2B3ZEinRBq3v_gTQj-_SrZA%40mail.gmail.com.

Using Deps/CLI for building mixed Clojure & Java projects

[Alan Thompson]

I've seen this conversation:
https://clojureverse.org/t/is-there-a-sales-pitch-for-switching-to-deps-edn-from-lein-in-2020/5367/15

which seems to say there is no existing way to combine Java & Clojure
source code when building with deps/CLI.  Is this correct?

If so, what would be entailed in enhancing Deps/CLI to handle Java source
files?

Thanks,
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/CAN67zA3%3DxtbsaC3iGgBSjPgUjw0LwZp%2Bu6bM54ktr1svgxeESQ%40mail.gmail.com.

Re: Clojars moved to new infrastructure

[Alan Thompson]

OK, it is fixed.  :)

Got rid of the beta test stuff for the new Clojars.org:

  :deploy-repositories [["clojars" "http://beta.clojars.org/repo/;]]


Now it works perfectly.  Thanks, Toby.
Alan



On Sat, Mar 28, 2020 at 6:05 PM Toby Crawley  wrote:

> Hi Alan:
>
> This looks like it may be an issue with the logic in lein to warn you
> about non-https repos. I see in your project.clj[1] you have
> :deploy-repositories set to ["clojars"
> "http://beta.clojars.org/repo/;] - can you remove that or change it to
> https? Also, beta.clojars.org is now a CNAME for clojars.org, so you
> can drop the beta.
>
> - Toby
>
> [1]: https://github.com/cloojure/tupelo/blob/master/project.clj#L17
>
> On Sat, Mar 28, 2020 at 7:53 PM Alan Thompson  wrote:
> >
> > Just tried to upload a new release to Clojars.org and got an error.
> Details:
> >
> > ~/tupelo > uname -a
> > Linux brandy 4.4.0-176-generic #206-Ubuntu SMP Fri Feb 28 05:02:04 UTC
> 2020 x86_64 x86_64 x86_64 GNU/Linux
> >
> >
> >
> > ~/tupelo > lsb_release -a
> > LSB Version:
> core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:printing-9.20160110ubuntu0.2-amd64:printing-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
> > Distributor ID: Ubuntu
> > Description: Ubuntu 16.04.6 LTS
> > Release: 16.04
> > Codename: xenial
> >
> >
> >
> > ~/tupelo > lein --version
> > Java HotSpot(TM) 64-Bit Server VM warning: Options -Xverify:none and
> -noverify were deprecated in JDK 13 and will likely be removed in a future
> release.
> > Leiningen 2.9.1 on Java 14 Java HotSpot(TM) 64-Bit Server VM
> >
> >
> >
> > ~/tupelo > lein deploy clojars
> > Java HotSpot(TM) 64-Bit Server VM warning: Options -Xverify:none and
> -noverify were deprecated in JDK 13 and will likely be removed in a future
> release.
> > No credentials found for clojars
> > See `lein help deploying` for how to configure credentials to avoid
> prompts.
> > Username: cloojure
> > Password:
> > Created /home/alan/tupelo/target/provided/tupelo-0.9.200.jar
> > Wrote /home/alan/tupelo/pom.xml
> > Need to sign 2 files with GPG
> > [1/2] Signing /home/alan/tupelo/target/provided/tupelo-0.9.200.jar with
> GPG
> >
> > You need a passphrase to unlock the secret key for
> > user: "Alan Thompson (n/a) "
> > 2048-bit RSA key, ID 303912FC, created 2018-11-25
> >
> > [2/2] Signing /home/alan/tupelo/pom.xml with GPG
> >
> > You need a passphrase to unlock the secret key for
> > user: "Alan Thompson (n/a) "
> > 2048-bit RSA key, ID 303912FC, created 2018-11-25
> >
> > Exception in thread "main" java.lang.AbstractMethodError: Receiver class
> leiningen.core.main$insecure_http_abort$reify__6678 does not define or
> inherit an implementation of the resolved method 'abstract void
> removeTransferListener(org.apache.maven.wagon.events.TransferListener)' of
> interface org.apache.maven.wagon.Wagon.
> > at
> org.eclipse.aether.transport.wagon.WagonTransporter.execute(WagonTransporter.java:440)
> > at
> org.eclipse.aether.transport.wagon.WagonTransporter.put(WagonTransporter.java:419)
> > at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.runTask(BasicRepositoryConnector.java:519)
> > at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:359)
> > at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.put(BasicRepositoryConnector.java:283)
> > at
> org.eclipse.aether.internal.impl.DefaultDeployer.deploy(DefaultDeployer.java:289)
> > at
> org.eclipse.aether.internal.impl.DefaultDeployer.deploy(DefaultDeployer.java:223)
> > at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:384)
> > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> > at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:167)
> > at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:102)
> > at
> cemerick.pomegranate.aether$deploy_artifacts.invokeStatic(aether.clj:358)
> > at cemerick.pomegranate.aether$deploy_artifacts.doInvoke(aether.clj:308)
> > at clojure.lang.RestFn.applyTo(Rest

Re: Clojars moved to new infrastructure

[Alan Thompson]

Just tried to upload a new release to Clojars.org and got an error.  
Details:

~/tupelo > uname -a
Linux brandy 4.4.0-176-generic #206-Ubuntu SMP Fri Feb 28 05:02:04 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

 

~/tupelo > lsb_release -a
LSB Version: 
core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:printing-9.20160110ubuntu0.2-amd64:printing-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial

 

~/tupelo > lein --version
Java HotSpot(TM) 64-Bit Server VM warning: Options -Xverify:none and 
-noverify were deprecated in JDK 13 and will likely be removed in a future 
release.
Leiningen 2.9.1 on Java 14 Java HotSpot(TM) 64-Bit Server VM

 

~/tupelo > lein deploy clojars
Java HotSpot(TM) 64-Bit Server VM warning: Options -Xverify:none and 
-noverify were deprecated in JDK 13 and will likely be removed in a future 
release.
No credentials found for clojars
See `lein help deploying` for how to configure credentials to avoid prompts.
Username: cloojure
Password: 
Created /home/alan/tupelo/target/provided/tupelo-0.9.200.jar
Wrote /home/alan/tupelo/pom.xml
Need to sign 2 files with GPG
[1/2] Signing /home/alan/tupelo/target/provided/tupelo-0.9.200.jar with GPG

You need a passphrase to unlock the secret key for
user: "Alan Thompson (n/a) "
2048-bit RSA key, ID 303912FC, created 2018-11-25

[2/2] Signing /home/alan/tupelo/pom.xml with GPG

You need a passphrase to unlock the secret key for
user: "Alan Thompson (n/a) "
2048-bit RSA key, ID 303912FC, created 2018-11-25

Exception in thread "main" java.lang.AbstractMethodError: Receiver class 
leiningen.core.main$insecure_http_abort$reify__6678 does not define or 
inherit an implementation of the resolved method 'abstract void 
removeTransferListener(org.apache.maven.wagon.events.TransferListener)' of 
interface org.apache.maven.wagon.Wagon.
at 
org.eclipse.aether.transport.wagon.WagonTransporter.execute(WagonTransporter.java:440)
at 
org.eclipse.aether.transport.wagon.WagonTransporter.put(WagonTransporter.java:419)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.runTask(BasicRepositoryConnector.java:519)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:359)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector.put(BasicRepositoryConnector.java:283)
at 
org.eclipse.aether.internal.impl.DefaultDeployer.deploy(DefaultDeployer.java:289)
at 
org.eclipse.aether.internal.impl.DefaultDeployer.deploy(DefaultDeployer.java:223)
at 
org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:384)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:167)
at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:102)
at cemerick.pomegranate.aether$deploy_artifacts.invokeStatic(aether.clj:358)
at cemerick.pomegranate.aether$deploy_artifacts.doInvoke(aether.clj:308)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:665)
at clojure.core$apply.invoke(core.clj:660)
at cemerick.pomegranate.aether$deploy.invokeStatic(aether.clj:427)
at cemerick.pomegranate.aether$deploy.doInvoke(aether.clj:391)
at clojure.lang.RestFn.invoke(RestFn.java:619)
at leiningen.deploy$deploy.invokeStatic(deploy.clj:215)
at leiningen.deploy$deploy.invoke(deploy.clj:172)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.core$apply.invokeStatic(core.clj:667)
at clojure.core$apply.invoke(core.clj:660)
at leiningen.core.main$partial_task$fn__6592.doInvoke(main.clj:284)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.lang.AFunction$1.doInvoke(AFunction.java:31)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:667)
at clojure.core$apply.invoke(core.clj:660)
at leiningen.core.main$apply_task.invokeStatic(main.clj:334)
at leiningen.core.main$apply_task.invoke(main.clj:320)
at leiningen.core.main$resolve_and_apply.invokeStatic(main.clj:343)
at leiningen.core.main$resolve_and_apply.invoke(main.clj:336)
at leiningen.core.main$_main$fn__6681.invoke(main.clj:452)
at leiningen.core.main$_main.invokeStatic(main.clj:442)
at leiningen.core.main$_main.doInvoke(main.clj:439)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.core$apply.invokeStatic(core.clj:665)
at clojure.main$main_opt.invokeStatic(main.clj:491

Destructuring in Kotlin

[Alan Thompson]

I was just reading an article on Kotlin and noticed they have nearly
identical destructuring syntax as in Clojure:

for ((k, v) in map) { println(“$k -> $v”) }


Kotlin can also be compiled into JavaScript ES5.1 to target browsers, just
like with ClojureScript.

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

Re: Clojure 1.10 "Illegal Reflective Access Operation"

[Alan Thompson]

I have included easy-to-use parsers of 3 types in the Tupelo library for 3
formats:

- HTML:  tupelo.parse.tagsoup

- XML:   tupelo.parse.xml

- YAML:  tupelo.parse.yaml


Enjoy!
Alan


On Wed, Feb 19, 2020 at 6:37 AM Alex Miller  wrote:

> I believe this has already been discussed in this same thread, but to
> rehash.
>
> More info on what this warning means:
> https://clojure.org/guides/faq#illegal_access
>
> To diagnose the cause, you can use --illegal-access=debug to get better
> info about the cause. Here I assume it's in xml/parse, but you haven't
> provided enough info to know what exactly xml is aliasing here. One likely
> candidate is clojure.xml and indeed clojure.xml/parse is reflective by
> design. You should consider that function deprecated - it does not present
> a full range of xml parsing options in the modern world and you should use
> the contrib lib org.clojure/data.xml instead (which does not have this
> issue).
>
> On Wednesday, February 19, 2020 at 8:26:49 AM UTC-6, Vitex Software wrote:
>>
>> Todays warning:
>>
>>
>> (defn fix-fields
>>   "Only Fields branch"
>>   []
>>   (:content (-> (clojure.zip/xml-zip (xml/parse
>> "specs/RHUB_v2.8_QuickFIX.xml"))
>> zip/down
>> zip/right
>> zip/right
>> zip/right
>> zip/right
>> zip/node))
>>   )
>>
>> (defn fix-fields->format [rec]
>>   {:tag (-> rec :attrs :number Long/parseLong)
>>:name(-> rec :attrs :name)
>>:type(-> rec :attrs :type)
>>:keyword (csk/->kebab-case (-> rec :attrs :name))
>>:values  (-> rec :content :enum)
>>})
>>
>>
>> (def fix-fields-reindexed (->> (fix-fields) (map fix-fields->format)))
>>
>> =>
>>
>> ARNING: An illegal reflective access operation has occurred
>> WARNING: Illegal reflective access by
>> clojure.lang.InjectedInvoker/0x7f3ca00b4c40
>> (file:/home/vitex/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.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/0x7f3ca00b4c40
>> 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
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/cd43204d-cbd2-488e-95dc-26a392f991bc%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/CAN67zA3xrC8mp0YRSQ399PSZAq69jpuaRCZD-M0-mia_zOnLmA%40mail.gmail.com.

Re: quoting vs syntax quoting

[Alan Thompson]

It is even simpler if you just run the following code:

(println "plain-quote:   " 'map)
(println "syntax-quote:  " `map)


with result:

plain-quote:map
syntax-quote:   clojure.core/map


The syntax-quote also allows you to unquote forms using `~` and `~@` (you
can't do this with plain-quote).  The combination allows you to easily make
code templates, the same way you might make HTML templates with Selmer,
Django, etc.

For full details of macro writing, please see this answer:
https://stackoverflow.com/questions/60212576/how-do-i-write-a-clojure-threading-macro

Alan

P.S.  Note that you can use syntax quote in regular functions as a trick to
easily fully-qualify symbol names.  It is not *only* for macros.



On Mon, Mar 2, 2020 at 4:49 AM Rutvik Patel  wrote:

> > How can I make a symbol without a namespace in syntax quoting?
> You need quote + unquote.
>
> user=> (defmacro moo2 [] `(defn ~'foo []))
> #'user/moo2
> user=> (macroexpand-1 '(moo2))
> (clojure.core/defn foo [])
> user=> (moo2)
> #'user/foo
>
> Focus on *~'foo *thing, we first *quote* the foo and *unquote* is using ~.
>
> On Mon, Mar 2, 2020 at 4:09 PM Anatoly Smolyaninov 
> wrote:
>
>> Yes, backtick is hygienic, i.e. it adds ns to symbols. you can define
>> name first and inject:
>>
>> ```
>> (defmacro moo2 []
>>   (let [name (symbol "foo")]
>> `(defn ~name [])))
>>
>> ```
>>
>> понедельник, 2 марта 2020 г., 10:54:51 UTC+1 пользователь Sonny To
>> написал:
>>>
>>> (defmacro moo1 []
>>>   '(defn foo []))
>>>
>>> (defmacro moo2 []
>>>
>>>
>>>   `(defn foo []))
>>>
>>> stigmergy.wocket.server> (moo1)
>>>
>>> #'stigmergy.wocket.server/foo
>>>
>>>
>>> stigmergy.wocket.server> (moo2)
>>>
>>> CompilerException clojure.lang.ExceptionInfo: Call to clojure.core/defn
>>> did not conform to spec:
>>> In: [0] val: stigmergy.wocket.server/foo fails spec:
>>> :clojure.core.specs.alpha/defn-args at: [:args :name] predicat\
>>> e: simple-symbol?
>>>
>>>  #:clojure.spec.alpha{:problems [{:path [:args :name], :pred
>>> clojure.core/simple-symbol?, :val stigmergy.wocket.ser\
>>> ver/foo, :via [:clojure.core.specs.alpha/defn-args
>>> :clojure.core.specs.alpha/defn-args], :in [0]}], :spec #object[c\
>>> lojure.spec.alpha$regex_spec_impl$reify__2436 0x33d84248
>>> "clojure.spec.alpha$regex_spec_impl$reify__2436@33d84248"]\
>>> , :value (stigmergy.wocket.server/foo []), :args
>>> (stigmergy.wocket.server/foo [])}, compiling:(*cider-repl workspac\
>>> e/clj-collage:localhost:39319(clj)*:131:26)
>>>
>>> stigmergy.wocket.server> (macroexpand-1 '(moo1))
>>> (defn foo [])
>>>
>>> stigmergy.wocket.server> (macroexpand-1 '(moo2))
>>> (clojure.core/defn stigmergy.wocket.server/foo [])
>>>
>>>
>>>
>>>
>>> moo1 uses normal quoting while moo2 uses syntax quoting. Why does (moo1)
>>> succeeds but( moo2) fails? Both seem to evaluate to same data-structure
>>> except moo2 has namespaces.
>>>
>>> The error message is cryptic but it seems moo2 is failing on 
>>> clojure.core/simple-symbol?
>>> which seems like a symbol without a namespace.  How can I make a symbol
>>> without a namespace in syntax quoting?
>>>
>>>
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to 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/82bdc4fc-2453-4561-80da-e3c6d6346900%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/CAABz%3DKr4qagDt1URgb9ZPHxvfCG4UfjiRE8Ch7Moaf%2BiX0UPaw%40mail.gmail.com
> 

Re: Clojars deployment failing

[Alan Thompson]

I just did a `lein deploy clojars` and it worked fine.
Alan


On Wed, Feb 19, 2020 at 8:40 PM Aaron D.  wrote:

> Whelp -- Just another data point -- I got two releases through just now
> successfully. So this is intermittent or something was fixed.
>
> On Wednesday, February 19, 2020 at 10:24:47 PM UTC-6, Aaron D. wrote:
>>
>> Hey Toby
>>
>> > What do you mean by "I disabled :checksum checking for clojars"?
>>
>> I added `:checksum :ignore` to :repositories in profile.clj -- per lein
>> example here
>> 
>>
>> > $ lein version
>> Leiningen 2.9.1 on Java 1.8.0_181 Java HotSpot(TM) 64-Bit Server VM
>>
>> I tried another release just now (without the checksum config) and am
>> able to reproduce the failure -- you can see that the release/deploy is
>> successful in transferring the signed jar artifacts but the final failure
>> is something to do with checking the checksum of maven-metadata.xml (see
>> output log below).
>>
>> Let me know if I can help anyway -- by running release attempts or
>> what-have-you .. will try to jump on slack and sync up there
>>
>> $ lein release :alpha
>> [master 19022c5] Version 0.0.3-alpha8
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> Compiling 16 source files to
>> /Users/atdixon/_work/code-sandbox/thurber/target/classes
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> Created
>> /Users/atdixon/_work/code-sandbox/thurber/target/thurber-0.0.3-alpha8.jar
>> Wrote /Users/atdixon/_work/code-sandbox/thurber/pom.xml
>> Need to sign 2 files with GPG
>> [1/2] Signing
>> /Users/atdixon/_work/code-sandbox/thurber/target/thurber-0.0.3-alpha8.jar
>> with GPG
>> [2/2] Signing /Users/atdixon/_work/code-sandbox/thurber/pom.xml with GPG
>> Sending com/github/atdixon/thurber/0.0.3-alpha8/thurber-0.0.3-alpha8.jar
>> (52k)
>> to https://repo.clojars.org/
>> Sending com/github/atdixon/thurber/0.0.3-alpha8/thurber-0.0.3-alpha8.pom
>> (4k)
>> to https://repo.clojars.org/
>> Sending
>> com/github/atdixon/thurber/0.0.3-alpha8/thurber-0.0.3-alpha8.jar.asc (1k)
>> to https://repo.clojars.org/
>> Sending
>> com/github/atdixon/thurber/0.0.3-alpha8/thurber-0.0.3-alpha8.pom.asc (1k)
>> to https://repo.clojars.org/
>> Could not transfer metadata com.github.atdixon:thurber/maven-metadata.xml
>> from/to releases (https://repo.clojars.org): Failed to transfer file:
>> https://repo.clojars.org/com/github/atdixon/thurber/maven-metadata.xml.
>> Return code is: 400 , ReasonPhrase:Bad Request.
>> Failed to retrieve remote metadata
>> com.github.atdixon:thurber/maven-metadata.xml: Could not transfer metadata
>> com.github.atdixon:thurber/maven-metadata.xml from/to releases (
>> https://repo.clojars.org): Failed to transfer file:
>> https://repo.clojars.org/com/github/atdixon/thurber/maven-metadata.xml.
>> Return code is: 400 , ReasonPhrase:Bad Request.
>>
>> On Sunday, February 16, 2020 at 6:25:49 PM UTC-6, Aaron D. wrote:
>>>
>>> My gpg creds are as usual (and verified) and I'm deploying in standard
>>> fashion but my last attempt at lein deploy fails with 400/Bad Request at
>>> the very ened trying  to retrieve maven-metadata.xml -- is anyone / has
>>> anyone seen this? My last deploy was 10 days ago...
>>>
>>> The log to error:
>>>
>>> Created /code/thurber/target/thurber-0.0.3-alpha5-SNAPSHOT.jar
>>> Wrote /code/thurber/pom.xml
>>> Could not find metadata
>>> com.github.atdixon:thurber:0.0.3-alpha5-SNAPSHOT/maven-metadata.xml in
>>> snapshots (https://repo.clojars.org)
>>> Sending
>>> com/github/atdixon/thurber/0.0.3-alpha5-SNAPSHOT/thurber-0.0.3-alpha5-20200217.002121-1.jar
>>> (52k)
>>> to https://repo.clojars.org/
>>> Sending
>>> com/github/atdixon/thurber/0.0.3-alpha5-SNAPSHOT/thurber-0.0.3-alpha5-20200217.002121-1.pom
>>> (4k)
>>> to https://repo.clojars.org/
>>> Could not transfer metadata
>>> com.github.atdixon:thurber/maven-metadata.xml from/to snapshots (
>>> https://repo.clojars.org): Failed to transfer file:
>>> https://repo.clojars.org/com/github/atdixon/thurber/maven-metadata.xml.
>>> Return code is: 400 , ReasonPhrase:Bad Request.
>>> Failed to retrieve remote metadata
>>> com.github.atdixon:thurber/maven-metadata.xml: Could not transfer metadata
>>> com.github.atdixon:thurber/maven-metadata.xml from/to snapshots (
>>> https://repo.clojars.org): Failed to transfer file:
>>> https://repo.clojars.org/com/github/atdixon/thurber/maven-metadata.xml.
>>> Return code is: 400 , ReasonPhrase:Bad Request.
>>>
>>>
>> On Wednesday, February 19, 2020 at 7:25:13 PM UTC-6, Toby Crawley wrote:
>>>
>>> Also, what version of lein are you using? What is the output of `lein
>>> version`?
>>>
>>> On Wed, Feb 19, 2020 at 8:14 PM Toby Crawley 
>>> wrote:
>>> >
>>> > Howdy Aaron:
>>> >
>>> > We've 

[ANN] Juxt/Bidi routing library demo

[Alan Thompson]

I just started maintaining a new codebase that uses the juxt/bidi routing
library, which I've not used before.  In going through the code, the
project uses some features which are not fully documented in the juxt/bidi
README, so I wrote some demo code to clarify what is going on and the
proper syntax to use.

https://github.com/io-tupelo-demo/bidi


It is written as a sequence of unit tests, so one can verify that
everything is OK by just running `lein test`:

~/io.tupelo.demo/bidi > lein clean ; lein test

lein test _bootstrap
---
   Clojure 1.10.1Java 13
---

lein test tst.demo.core

Ran 2 tests containing 17 assertions.
0 failures, 0 errors.


The demo tests start out simple:

(let [route ["/index.html" :index]]
  (is= (bidi/match-route route "/index.html") {:handler :index}) ; found route
  (is= (bidi/match-route route "/another.html") nil) ; did not find route
  (is= "/index.html" (bidi/path-for route :index))) ; find URI for handler

but then dive into some lesser-known features like "Guards":

; short version to match GET "/index.html"
(let [route ["/index.html" {:get :index}]]
  (is= (bidi/match-route route "/index.html" :request-method :get)
{:handler :index, :request-method :get})
  (is= (bidi/match-route route "/index.html" :request-method :put) nil))

; long version to match GET "/index.html"
(let [route ["" {
 {:request-method :get} {"/index.html" :index}
 }]]
  (is= (bidi/match-route route "/index.html" :request-method :get)
{:handler :index, :request-method :get})
  (is= (bidi/match-route route "/index.html" :request-method :post) nil))

Enjoy!
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/CAN67zA3WP4vUK9yCSKghrsU6t0pWL-ArtFzy-LOiwSaGOkpK1Q%40mail.gmail.com.

[ANN] Tupelo Clojure I/O Utils - tupelo.io - 0.9.185

[Alan Thompson]

ity to make temporary disk files &
directories, and to recursively delete a dir:

(dotest
  ; Create nested dirs & files, then delete recursively
  (let [tmp-path   (create-temp-directory "some-stuff")
tmp-name   (str tmp-path)
dir-one(create-temp-directory tmp-path "dir-one")
dir-two(create-temp-directory dir-one "dir-two")
tmp-one-a  (create-temp-file dir-one "aaa" nil)
tmp-one-b  (create-temp-file dir-one "bbb" ".dummy")
tmp-two-a  (create-temp-file dir-two "aaa" ".tmp")
tmp-two-b  (create-temp-file dir-two "bbb" ".tmp")
count-files-fn (s/fn [dir-name :- s/Str]
 (let [dir-file (io/file dir-name)
   counts   (for [file (file-seq dir-file)]
  (if (.exists file)
1
0))
   total(apply + counts)]
   total))]
(when false ; debug printouts
  (spyx (str tmp-path))
  (spyx (str tmp-name))
  (spyx (str dir-one))
  (spyx (str tmp-one-a))
  (spyx (str tmp-one-b))
  (spyx (str tmp-two-a))
  (spyx (str tmp-two-b))
  (pprint/pprint (vec (sort
(map str
  (file-seq (.toFile tmp-path))
  ; Sample debug output:
  ;(str tmp-path) => "/tmp/some-stuff-562114607264734833"
  ;(str tmp-name) => "/tmp/some-stuff-562114607264734833"
  ;(str dir-one) =>
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970"
  ;(str tmp-one-a) =>
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970/aaa-345552808102662294.tmp"
  ;(str tmp-one-b) =>
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970/bbb-14875687905791190659.dummy"
  ;(str tmp-two-a) =>
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970/dir-two-15168249174986120265/aaa-14487327636081006800.tmp"
  ;(str tmp-two-b) =>
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970/dir-two-15168249174986120265/bbb-8158500208162744706.tmp"
  ;
  ; File names produced:
  ;["/tmp/some-stuff-562114607264734833"
  ; "/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970"
  ; 
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970/aaa-345552808102662294.tmp"
  ; 
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970/bbb-14875687905791190659.dummy"
  ; 
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970/dir-two-15168249174986120265"
  ; 
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970/dir-two-15168249174986120265/aaa-14487327636081006800.tmp"
  ; 
"/tmp/some-stuff-562114607264734833/dir-one-15514198984069907970/dir-two-15168249174986120265/bbb-8158500208162744706.tmp"]
  )

(is= 7 (count-files-fn tmp-name))
(is= 7 (delete-directory tmp-name))
(is= 0 (count-files-fn tmp-name))
(is= 0 (delete-directory tmp-name)) ; idempotent
))



There are also a few stream type-testing predicates:

(let [in-stream  (io/input-stream dummy-file)
  out-stream (io/output-stream dummy-file)
  dis(DataInputStream. in-stream)
  dos(DataOutputStream. out-stream)]
  (isnt (data-input-stream? in-stream))
  (is (input-stream? in-stream))
  (is (input-stream? dis))
  (is (data-input-stream? dis))

  (isnt (data-output-stream? out-stream))
  (is (output-stream? out-stream))
  (is (output-stream? dos))
  (is (data-output-stream? dos


Enjoy!
Alan Thompson

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

Re: Enlive: select a comment, drop all subsequent nodes?

[Alan Thompson]

You can be more precise if you use the `tupelo.forest` library for
processing tree-like data structures (this will allow you to avoid the
trailing `nil` values, for example).  Please see the docs
<https://github.com/cloojure/tupelo/blob/master/docs/forest.adoc>, and also
the numerous examples
<https://github.com/cloojure/tupelo/blob/master/test/clj/tst/tupelo/forest_examples.clj>
.
Alan

On Mon, Dec 16, 2019 at 12:18 PM Alan Thompson  wrote:

> Quick & dirty technique:
>
> (ns tst.demo.core
>   (:use demo.core tupelo.core tupelo.test)
>   (:require
> [clojure.java.io :as io]
> [clojure.walk :as walk]
> [tupelo.parse.tagsoup :as tagsoup] ))
>
> (dotest
>   (let [txt(slurp (io/resource "test.html"))
> >> (println txt)
> enlive-data (tagsoup/parse txt)
> >> (spyx-pretty enlive-data)
> found-comment? (atom false)
> tx-fn  (fn [item]
>  (when (and (map? item)
>  (= :comment (:type item))
>  (= "more" (:data item)))
>(reset! found-comment? true))
>  (if @found-comment?
>nil
>item))
> enlive-keep(walk/prewalk tx-fn enlive-data) ]
> (newline)
> (spyx-pretty enlive-keep)
> ) )
>
>
> with result:
>
> ---
>Clojure 1.10.1Java 13
> ---
>
> Testing tst.demo.core
> 
>   This is a test 
>   
>   This is only a test 
> 
>
>
> enlive-data =>
> {:tag :html,
>  :attrs {},
>  :content
>  [{:tag :body,
>:attrs {},
>:content
>[{:tag :h1, :attrs {}, :content ["This is a test "]}
> {:type :comment, :data "more"}
> {:tag :h2, :attrs {}, :content ["This is only a test "]}]}]}
>
> enlive-keep =>
> {:tag :html,
>  :attrs {},
>  :content
>  [{:tag :body,
>:attrs {},
>:content
>[{:tag :h1, :attrs {}, :content ["This is a test "]} nil nil]}]}
>
>
>
>
>
>
> On Sun, Dec 15, 2019 at 3:44 PM Matching Socks 
> wrote:
>
>> Indeed "lefts" or "rights" will be the key.  A transformation is just a
>> function (open up enlive's html.clj to see how it works), so you can
>> sanity-check yourself by providing a "transformation" that prints out the
>> matched nodes.  Feel free to regard Enlive's own transformations as mere
>> samples.  You could match some node (the comment's parent) and replace its
>> contents with 2 divs, one selecting content-before the marker comment and
>> the other the content-after.
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to 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/9da515ab-d685-4dbb-91cd-ffdfc29ee23b%40googlegroups.com
>> <https://groups.google.com/d/msgid/clojure/9da515ab-d685-4dbb-91cd-ffdfc29ee23b%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/CAN67zA3QJLGLo6RSo%2BqgSeOyxe2x%3DJusjRi2MLeQx5S-C72Vjw%40mail.gmail.com.

Re: Enlive: select a comment, drop all subsequent nodes?

[Alan Thompson]

Quick & dirty technique:

(ns tst.demo.core
  (:use demo.core tupelo.core tupelo.test)
  (:require
[clojure.java.io :as io]
[clojure.walk :as walk]
[tupelo.parse.tagsoup :as tagsoup] ))

(dotest
  (let [txt(slurp (io/resource "test.html"))
>> (println txt)
enlive-data (tagsoup/parse txt)
>> (spyx-pretty enlive-data)
found-comment? (atom false)
tx-fn  (fn [item]
 (when (and (map? item)
 (= :comment (:type item))
 (= "more" (:data item)))
   (reset! found-comment? true))
 (if @found-comment?
   nil
   item))
enlive-keep(walk/prewalk tx-fn enlive-data) ]
(newline)
(spyx-pretty enlive-keep)
) )


with result:

---
   Clojure 1.10.1Java 13
---

Testing tst.demo.core

  This is a test 
  
  This is only a test 



enlive-data =>
{:tag :html,
 :attrs {},
 :content
 [{:tag :body,
   :attrs {},
   :content
   [{:tag :h1, :attrs {}, :content ["This is a test "]}
{:type :comment, :data "more"}
{:tag :h2, :attrs {}, :content ["This is only a test "]}]}]}

enlive-keep =>
{:tag :html,
 :attrs {},
 :content
 [{:tag :body,
   :attrs {},
   :content
   [{:tag :h1, :attrs {}, :content ["This is a test "]} nil nil]}]}






On Sun, Dec 15, 2019 at 3:44 PM Matching Socks  wrote:

> Indeed "lefts" or "rights" will be the key.  A transformation is just a
> function (open up enlive's html.clj to see how it works), so you can
> sanity-check yourself by providing a "transformation" that prints out the
> matched nodes.  Feel free to regard Enlive's own transformations as mere
> samples.  You could match some node (the comment's parent) and replace its
> contents with 2 divs, one selecting content-before the marker comment and
> the other the content-after.
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/9da515ab-d685-4dbb-91cd-ffdfc29ee23b%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/CAN67zA26pf4SRjxM0mh4%2B2wKCsHX69Kg5rAqiqBqzHMisTUwCw%40mail.gmail.com.

Re: 100x startup for Clojure using GraalVM

[Alan Thompson]

When you have a short-running task that completes in 0.01 sec, a startup
delay of 1.3 seconds (or more) *is* the total execution time.

On Fri, Nov 29, 2019 at 10:32 AM david hoyt  wrote:

> This kind of think is really only interesting for shell piping in bash. It
> won’t help numerical, tensor, neural, simulation, nor business codes. Good
> FORTRAN environments can do hard numerical faster. To a lesser amount, so
> can C. In supercomputing, that advantage is reduced. I/O bandwidth becomes
> more important. In business, I/O is the only thing that’s important. The
> only think that reliably makes a difference is the quality of the
> developers.
>
> Startup in Java, Microsoft’s library framework,  have slower start up
> times because no one has bothered to optimize things for startup time. The
> time to get the entire task completed (or cost) is the only thing that is
> important.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/7c64109c-4e3c-4b99-9eb8-1e826be08603%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/CAN67zA0BJL0dwg_eB_1uLDYUAO6%2Bjrgx479URPgrM7jM%2BJj8cw%40mail.gmail.com.

Re: 100x startup for Clojure using GraalVM

[Alan Thompson]

A quick comparison with python:

> time python -c 'print("Hello world!")'
Hello world!
0.03s user 0.01s system 80% cpu 0.048 total

> /usr/bin/time -l  python -c 'print("Hello world!")'
Hello world!
0.04 real 0.02 user 0.01 sys
 6  maximum resident set size (MB)
  2110  page reclaims
24  involuntary context switches

So the Python version *takes 5x longer*, and uses *3x more memory.*


On Tue, Nov 12, 2019 at 12:58 PM Nate Sutton  wrote:

> Another way to achieve fast startup is to compile clojurescript to a
> nodejs target and then use the nodejs library called pkg to bundle the
> nodejs binary with the script. I haven't timed it but it's an interesting
> alternative.
>
> On Tue, Nov 12, 2019 at 12:46 PM Colin Yates 
> wrote:
>
>> Do we have any idea how that memory saving scales?
>>
>> I know a bunch of meta data isn’t needed as it is hotspot specific, but
>> are there any other memory savings?
>>
>> Sent from my iPhone
>>
>> On 12 Nov 2019, at 18:42, Alan Thompson  wrote:
>>
>> In my initial post, I failed to mention the huge memory savings achieved
>> by the standalone executable (in addition to the startup time savings).
>>
>> Note that using *time* at the command line resolves to a shell built-in
>> command. We can get more information from the standard Unix version of time:
>> # JVM+UberJar
>> > /usr/bin/time -l  java -jar
>> target/hello-world-0.1.0-SNAPSHOT-standalone.jar
>> Hello, World!
>> Goodbye...
>> 1.20 real 2.47 user 0.24 sys
>>409  maximum resident set size (MB)
>> 100469  page reclaims
>>   3569  involuntary context switches
>>
>> # Static Executable
>> > /usr/bin/time -l  target/hello-world
>> Hello, World!
>> Goodbye...
>> 0.00 real 0.00 user 0.00 sys
>>  2  maximum resident set size (MB)
>>657  page reclaims
>>  4  involuntary context switches
>> So we see that the maximum RSS memory requirement *was reduced from 409
>> MB to 2 MB*. Yes, an improvement *over 200x!*  Note also that context
>> switches have been *reduced by 900x,* and page reclaims by *about 200x*.
>>
>> So, it is the combination of reduced startup time and vastly reduced
>> memory requirements that make standalone executables ideal for short-lived
>> tasks, especially in constrained environments such as serverless/lambda.
>>
>>
>>
>> On Sun, Nov 10, 2019 at 7:54 AM Michiel Borkent 
>> wrote:
>>
>>> Might be worth mentioning that lread and I are collecting information
>>> about GraalVM here:
>>>
>>> https://github.com/lread/clj-graal-docs
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to 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/8dbd1a23-61b4-42dc-8815-3d8422956901%40googlegroups.com
>>> <https://groups.google.com/d/msgid/clojure/8dbd1a23-61b4-42dc-8815-3d8422956901%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
>

Re: 100x startup for Clojure using GraalVM

[Alan Thompson]

In my initial post, I failed to mention the huge memory savings achieved by
the standalone executable (in addition to the startup time savings).

Note that using *time* at the command line resolves to a shell built-in
command. We can get more information from the standard Unix version of time:
# JVM+UberJar
> /usr/bin/time -l  java -jar
target/hello-world-0.1.0-SNAPSHOT-standalone.jar
Hello, World!
Goodbye...
1.20 real 2.47 user 0.24 sys
   409  maximum resident set size (MB)
100469  page reclaims
  3569  involuntary context switches

# Static Executable
> /usr/bin/time -l  target/hello-world
Hello, World!
Goodbye...
0.00 real 0.00 user 0.00 sys
 2  maximum resident set size (MB)
   657  page reclaims
 4  involuntary context switches
So we see that the maximum RSS memory requirement *was reduced from 409 MB
to 2 MB*. Yes, an improvement *over 200x!*  Note also that context switches
have been *reduced by 900x,* and page reclaims by *about 200x*.

So, it is the combination of reduced startup time and vastly reduced memory
requirements that make standalone executables ideal for short-lived tasks,
especially in constrained environments such as serverless/lambda.



On Sun, Nov 10, 2019 at 7:54 AM Michiel Borkent 
wrote:

> Might be worth mentioning that lread and I are collecting information
> about GraalVM here:
>
> https://github.com/lread/clj-graal-docs
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/8dbd1a23-61b4-42dc-8815-3d8422956901%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/CAN67zA1USV_sX0bP%3Dg-p0r7%2BqMOvYscWY9aj7yBnYsSeikcskQ%40mail.gmail.com.

100x startup for Clojure using GraalVM

[Alan Thompson]

Some people I know have been interested in switching from Clojure to Go in
order to get faster startup times and statically linked executables for
microservices on AWS Lambda, etc.  Having recently reviewed the Go: the
Good, the Bad, and the Ugly
, as well as
stumbling through a Go bootcamp, I was looking for a good
counter-argument.  While the command-line usage via Clojure/CLI:

> clj -e '(println "Hello World")'  # 0.98 sec


takes only about a second, and

> java -jar hello-standalone.jar# 1.30 sec


takes only about 1.3 seconds, I needed something faster.  Joker
 has a lot of potential, but it includes
only basic Clojure namespaces.  Having tracked news about GraalVM over the
past couple of years, I thought it was time for a quick demo project.

TL;DR:  The bottom line:

> target/hello-world# 0.009 sec


*Yes, you read that right!*  The statically linked executable is over *130x*
faster than running via the uberjar.

I summarized all the steps to install and run using GraalVM in this demo
project:

https://github.com/cloojure/graalvm


Just peruse the README and you'll be off to the races.
See also:

   -

   Nice ClojureD video  by Jan Stepien
   -

   Bruno Bonacci’s GraalVM Clojure Demo
   


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

Love Letter to Clojure (by Gene Kim)

[Alan Thompson]

Thought this would be of interest:
https://itrevolution.com/love-letter-to-clojure-part-1/

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

Java in 2019 survey

[Alan Thompson]

I thought this might be of interest to Clojure devs:

  https://www.baeldung.com/java-in-2019

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

Good Clojure article by Uncle Bob

[Alan Thompson]

Nicely sums up the advantages of Clojure:

http://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html

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

Nice blog entry on not trying to do much with `:prep-tasks` in `lein`

[Alan Thompson]

Makes a good point that other tools should be used for non-clojure build
steps.

   https://grishaev.me/en/lein/

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

Re: No "clojure --version" switch

[Alan Thompson]

Jira CLJ-2508 created.

On Wed, May 8, 2019 at 4:51 AM Alex Miller  wrote:
>
> Actually, reporting the Clojure AND Java version would be even better.
>
> > On May 8, 2019, at 6:31 AM, Alex Miller  wrote:
> >
> > I would echo the other comments here. What user question are we trying to 
> > answer? The scripts are not written in Clojure, but use a Clojure program 
> > to compute the classpath, then launch your Clojure program. The version 
> > used for the first is largely irrelevant to you and probably more confusing 
> > than useful.
> >
> > Having a helper for the version used in the second is possibly useful and 
> > would be happy to consider that. This could be done either in clojure.main 
> > (CLJ) or in the Clojure scripts (TDEPS). I guess I would probably lean 
> > towards the former.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > 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/cvVPFpTkTaQ/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/d679ae95-13f3-41a7-a3ba-f90a5839ba8d%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/EC7DC405-6718-4AED-87E9-6A31336E182B%40puredanger.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/CAN67zA3AnBTjrXhURmHssZbW%2BQwZc%3DWADcT1fKNBPxNOO_nYfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Compiler error message misses the target

[Alan Thompson]

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

No "clojure --version" switch

[Alan Thompson]

Seems we should have the "--version" switch that is pretty universal.
Right now, the best one can do is

> clojure --eval "(clojure-version)"
"1.10.0"


which is hard for a new user to figure out.  Jira ticket?

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/CAN67zA0yrhNhfx2vwH%3D-oy1kbJPA0EyGwwvg%2BFX3kyV4tgz3Qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

StackOverflow Survey Results

[Alan Thompson]

are in.  Clojure ranks highly on the scale of global salary and in the
"Most Loved" categories:

https://insights.stackoverflow.com/survey/2019?utm_source=so-owned_medium=announcement-banner_campaign=dev-survey-2019#top-paying-technologies

https://insights.stackoverflow.com/survey/2019?utm_source=so-owned_medium=announcement-banner_campaign=dev-survey-2019#technology-_-most-loved-dreaded-and-wanted-languages

Here is an interesting graph showing salary vs experience for different
languages:

https://insights.stackoverflow.com/survey/2019?utm_source=so-owned_medium=announcement-banner_campaign=dev-survey-2019#work-_-salary-and-experience-by-language

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

[Alan Thompson]

Looks interesting!  Definitely need to check this out.
Alan

On Sun, Mar 31, 2019 at 12:44 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks
>
> I've released 0.1.0 of defn-spec
> , a library that lets you
> define your function specs inline with your function definitions.
>
> A quick example, defn-spec lets you write:
>
> (ds/defn to-zoned-dt :- ::zoned-date-time
>   [instant :- ::instant
>zone-id :- ::zone-id]
>   (ZonedDateTime/ofInstant instant zone-id))
>
> instead of:
>
> (defn to-zoned-dt
>   [instant zone-id]
>   (ZonedDateTime/ofInstant instant zone-id))
>
> (s/fdef to-zoned-dt
> :args (s/cat :instant ::instant :zone-id ::zone-id)
> :ret ::zoned-date-time)
>
> If you're thinking "that looks a lot like Schema's defn macro", then you'd
> be right. defn-spec uses the same syntax and much of the implementation of
> Schema's defn macro.
>
> I wrote more background in the announcement post
> , and there
> are more details on GitHub .
> I hope you find it useful!
>
> Thanks, Daniel.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.1-beta1

[Alan Thompson]

Working fine for the Tupelo library:  https://github.com/cloojure/tupelo

-
   Clojure 1.10.1-beta1Java 12
-
Ran 312 tests containing 2874 assertions.
0 failures, 0 errors.
lein test :all   61.60s user  1.22s system  299% cpu  20.996 total


Also for ClojureScript:

;; ==
;; Testing with Phantom:

doorunner - beginning
doorunner - end

Testing tst._bootstrap

   ClojureScript 1.10.439

Ran 145 tests containing 1698 assertions.
0 failures, 0 errors.
lein doo phantom test once  63.31s user 1.40s system 280% cpu 23.069 total





On Tue, Mar 26, 2019 at 10:53 AM Sean Corfield  wrote:

> Everything seems to be running fine on 1.10.1-beta1 here at World Singles
> Networks. We were not experiencing the user.clj loading problem so I can't
> speak to how it addresses that, nor are we looking at Java 12 yet :)
>
> The only piece of feedback I'll offer here -- and Alex already knows
> because I raised it on Zulip but want a broader audience as a sanity check:
>
> The new clojure.main error handling definitely works well but on macOS the
> temporary folder path -- where the EDN report of the stack trace etc gets
> written -- is very long so the "Full report at:" line wraps, making it a
> bit fiddle to copy'n'paste the file path. It would be easier if the file
> path was on a separate line, by adding a newline after "at:", so selection
> of the file path is easier.
>
> That might also make it easier for tooling that invokes Clojure apps via
> the command-line (instead of having to parse the file path out of a line
> that has other text in it).
>
> On Thursday, March 21, 2019 at 9:35:32 PM UTC-7, Alex Miller wrote:
>>
>> 1.10.1-beta1 is now available. You can try it with clj using:
>>   clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
>> "1.10.1-beta1"}}}'
>>
>> 1.10.1-beta1 includes the following changes since 1.10.0:
>>
>>- CLJ-2484  - Fix Java
>>performance regression loading user.clj
>>- CLJ-2463  -
>>clojure.main uncaught exception handling
>>- CLJ-2491  - Fix
>>fragile tests that fail under Java 12
>>
>> The issue in CLJ-2484 was introduced in Java itself, specifically Java
>> 1.8 u202, Java 11.0.2, and Java 12. It primarily affects loading of
>> user.clj and can cause a significant load time difference for anything done
>> in user.clj. CLJ-2463 affects how errors are reported from clojure.main.
>> This includes many Clojure uses under tools like Leiningen, such as
>> compile, test,  etc.
>>
>> We would greatly appreciate feedback if you could check out this release
>> in your own project and give it a try!!
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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"

[Alan Thompson]

After further investigation, I modified my copy of the xml parsing code to
wrap either an InputStream or a Reader with an org.xml.sax.InputSource (and
changed the type hint):

(defn ^:private sax-parse-fn
  [xml-input content-handler]
  (let [input-source (cond
   (or (instance? InputStream xml-input)
   (instance? Reader xml-input))
(org.xml.sax.InputSource. xml-input)
   (instance? org.xml.sax.InputSource xml-input)
xml-input
   :else (throw (ex-info "sax-parse-fn: xml-input must
be one of InputStream, Reader, or org.xml.sax.InputSource"
  {:type  (type xml-input)
   :class (class xml-input)})))]
(it-> (SAXParserFactory/newInstance)
  (doto it
(.setValidating false)
(.setFeature "http://xml.org/sax/features/external-general-entities;
false)
(.setFeature "
http://xml.org/sax/features/external-parameter-entities; false))
  (.newSAXParser it)
  (doto it
(.setProperty "http://xml.org/sax/properties/lexical-handler;
content-handler))
  (.parse it
^org.xml.sax.InputSource input-source
^org.xml.sax.helpers.DefaultHandler  content-handler

(s/defn parse   ; #todo fix docstring
  ([xml-input] (parse xml-input sax-parse-fn))
  ([xml-input parse-fn]
(let [result-atom (atom (xml-zip {:type :document :content nil}))
  content-handler (handler result-atom)]
  (parse-fn xml-input content-handler)
  ; #todo document logic vvv using xkcd & plain xml example
  (let [parsed-data (it-> @result-atom
  (first it)
  (:content it)
  (drop-if #(= :dtd (:type %)) it)
  (drop-if #(string? %) it)
  (only it))]
parsed-data






On Sat, Mar 2, 2019 at 4:11 PM Matching Socks  wrote:

> Does this need adjusting in clojure.xml too?  The code looks pretty
> similar:
>
> (defn startparse-sax [s ch]
>   (.. SAXParserFactory (newInstance) (newSAXParser) (parse s ch)))
>
> The reflection on "parse" is convenient. There are multiple
> SaxParser.parse methods with unique capabilities. The String method allows
> you not to know how the data is encoded.  To open an InputStream, you have
> to know the encoding.  It's pretty hard to open an XML instance correctly!
> And the InputSource method allows you to parse from a Reader, e.g., a
> StringReader.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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"

[Alan Thompson]

I was deceived by the error message.  Since I had only changed the Clojure
version 1.9 => 1.10, and since the warning mentioned only Clojure code:

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)


I thought the problem was within the Clojure source.  After investigating
further, the problem was indeed a lack of type-hinting in a dependent
library (Enlive).  The fix was to add 2 type hints to a function call:

   (.parse
 ^java.io.InputStreams ; actual type =>
java.io.BufferedInputStream
 ^org.xml.sax.helpers.DefaultHandler ch; actual type =>
net.cgrand.xml.proxy$org.xml.sax.ext.DefaultHandler2
   )


A Pull Request has been filed.  Much thanks to Andy Fingerhut for pointing
me in the right direction.
Alan Thompson


On Sun, Feb 24, 2019 at 5:53 PM Andy Fingerhut 
wrote:

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

Clojure 1.10 "Illegal Reflective Access Operation"

[Alan Thompson]

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.

Re: Using map to produce side effects, not working

[Alan Thompson]

Also remember that `mapv` is not lazy and will force the map to run right
away, which helps if side-effecty things like `println` are a part of the
function.

On Thu, Feb 7, 2019 at 10:54 AM Justin Smith  wrote:

> also do note that clojure.core/run! is designed for two-arg map when
> it's only run for side effects, and clojure.core/doseq is designed for
> nested side-effecting iteration
>
> On Thu, Feb 7, 2019 at 3:33 AM Pierpaolo Tofani
>  wrote:
> >
> > Thanks ! Your diagnosis is correct. With two dorun works fine.
> >
> > Il giorno giovedì 7 febbraio 2019 12:19:40 UTC+1, Orestis Markou ha
> scritto:
> >>
> >> Without having ran your code, it seems that the inner map is not
> wrapped in a doall, so while the outer lazy-seq is forced, the inner is not.
> >>
> >> This might be of interest to you:
> http://clojure-doc.org/articles/language/laziness.html
> >>
> >> If you only want to do map for side effects, you could use dorun
> instead of doall.
> >>
> >> On 7 Feb 2019, at 12:04 PM, Pierpaolo Tofani 
> wrote:
> >>
> >> Hi
> >> i am new in clojure sorry.
> >> In the snippet of code i used two map functions only to produce side
> effects on two ref.
> >> Even using doall no affect is produced on ref aaa and zzz, seems that
> the sequence is still lazy.
> >> But if i remove the final :done , and the repl show me the sequence
> produced (that i don't care) the ref aaa and zzz are affected.Thanks in
> advance.
> >> PS The two map are in effect doing a for.
> >>
> >> (def aaa (ref 0))
> >> (def zzz (ref 0))
> >> (def s1 [1 2 3 4 5])
> >> (def s2 [1 2 3 4 5])
> >> (defn make-side []
> >> (do
> >> (doall
> >> (map
> >>   (fn [x]
> >> (map
> >>   (fn [y]
> >> (dosync
> >>   (alter aaa inc)
> >>   (alter zzz dec)
> >> )
> >> )
> >>   s2))
> >>   s1)
> >> )
> >> :done
> >> )
> >> )
> >>
> >>
> >> --
> >> 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.
>

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

crossclj.info unavailable ???

[Alan Thompson]

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.

Re: [ANN] Calfpath (v0.7.1), a fast and flexible Ring request router

[Alan Thompson]

Hi have been very happy using Pedestal for routing 
chores.  How does this compare to Pedestal?
Alan


On Fri, Jan 4, 2019 at 9:50 PM Shantanu Kumar 
wrote:

> Hi,
>
> (Cross-posted on Clojure and Ring mailing lists.)
>
> Happy new year to all!
>
> I am pleased to announce Calfpath, a fast Ring-based routing library that
> supports flexible, à la carte request matching. It supports both
> macro-based and data-driven routing.
>
> https://github.com/kumarshantanu/calfpath
>
> At SAP Concur we have been using this library for over 3 years in
> production on REST(ish) API servers. During early 2015 when we were using
> Compojure, we found it was causing 4% of the total internal latency. That
> is when we switched to Calfpath - roughly an order of magnitude faster. The
> benchmarking code is included in the repo - however, you should probably
> test against your own use-case to determine suitability.
>
> The API has matured quite a bit over time and is now more stable than ever
> before. Among downsides, as of now Calfpath is neither bi-directional, nor
> ClojureScript ready.
>
> I would love to receive your feedback and answer any questions. Please let
> me know what you think.
>
>
> 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: How does Executors/newScheduledThreadPool know how or where to parallelize work?

[Alan Thompson]

If you haven't seen it before, you can use the excellent Claypoole library
 for many parallel
scheduling tasks.
Alan

On Wed, Jan 2, 2019 at 1:07 PM  wrote:

> I guess this is more of a JVM question than a Clojure question, unless
> Clojure exerts any special magic here. I'm open to a more Clojure approach
> than what I have now.
>
> Someone suggested I use Executors/newScheduledThreadPool for some
> recurring work, so I set it up like this:
>
> (def scheduler-aggregate
>   (Executors/newScheduledThreadPool 32))
>
> at the start I call:
>
>   (.scheduleAtFixedRate  scheduler-aggregate ^Runnable (cycle-aggregate
> to-database-queue) 1 30 TimeUnit/MINUTES)
>
> Aside from a try/catch block (which I just removed to simplify this
> example) the inner function looks like this:
>
> (defn- cycle-aggregate
>   [to-database-queue]
>   (fn []
>  (let [
>transcripts (query @global-database-connection {:item-type
> :transcript :processed { operators/$exists false }})
>]
>(doseq [x transcripts]
>  (aggregate-words x)
>  (set-transcript-processed  @global-database-connection x)))
>
> The function (aggregate-words) counts up a bunch of words, doing some prep
> work for a later NLP engine, and then there is this line:
>
> (log "The end of aggregate-words.")))
>
> The whole process takes about 5 minutes to run, about 300 seconds. I watch
> the database and I see the number of new records increase. About every 10
> seconds I see these words appear in the logs:
>
> "The end of aggregate-words."
>
> At the end of 5 minutes, these words have appeared 30 times, one for each
> of the transcripts I'm importing.
>
> This seems like I've done something wrong? Since the words "The end of
> aggregate-words."
> appear at roughly equal intervals, and the transcripts are all about the
> same size, it seems that all of the transcripts are being handled on one
> thread. After all, if the 30 transcripts were handled on 30 threads, I'd
> expect the 30 calls to aggregate-words would all end at roughly the same
> time, instead of sequentially.
>
> What else do I need to do to parallelize this work? If I call (future)
> inside of aggregate-words, would the new thread come from the pool? Is
> there a way I can call aggregate-words and make sure it runs on its own
> thread from the pool?
>
>
>
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

[Alan Thompson]

Looks very nice.  I will definitely be using this in the future.
Alan

On Tue, Dec 18, 2018 at 4:44 AM  wrote:

> Odd. The exact same code works for me. This is clojure 1.10/oz 1.4, and
> evaluating the whole blob from lighttable.
>
> I had to call (oz/v! line-plot) again to get it to show the figure,
> rather then the opening text. And you can leave out the (oz/start-plot-
> server!). It will start a server if it needs one.
>
> I guess I have a similar workflow as Christopher, and similar needs in
> terms of visualization. I have used vega-lite through vizard and now oz for
> about a year now, after trying so many different visualization packages for
> clojure (Incanter/JFreechart, C2, quil, gyptis, quil/grafica,
> rojure->ggplot2, vizard). Really happy that oz takes vizard further.
> vega/vega-lite works really well with clojure.
>
>
>
> On Tuesday, December 18, 2018 at 10:12:07 AM UTC+1, Juraj Martinka wrote:
>>
>> I'd like to try this but got stuck pretty early:
>>
>> (ns clojure-repl-experiments.visualizations.oz
>>   (:require [oz.core :as oz]))
>>
>>
>> (oz/start-plot-server!)
>>
>>
>> (defn group-data [& names]
>>   (apply concat (for [n names]
>>   (map-indexed (fn [i x] {:x i :y x :col n}) (take 20 
>> (repeatedly
>> #(rand-int 100)))
>>
>>
>> (def line-plot
>>   {:data {:values (group-data "monkey" "slipper" "broom")}
>>:encoding {:x {:field "x"}
>>   :y {:field "y"}
>>   :color {:field "col" :type "nominal"}}
>>:mark "line"})
>>
>>
>> ;; Render the plot to the
>> (oz/v! line-plot)
>>
>>
>>
>> It has opened a new browser window at http://localhost:10666/ but I see
>> nothing only errors in the JS console:
>> socket.cljs?rel=1502542805393:64 WebSocket connection to
>> 'ws://localhost:3449/figwheel-ws/dev' failed: Error in connection
>> establishment: net::ERR_CONNECTION_REFUSED
>> figwheel$client$socket$open @ socket.cljs?rel=1502542805393:64
>> 10:10:10.089
>>
>> Does it require some special setup (figwheel)?
>>
>>
>>
>>
>> On Monday, 17 December 2018 21:41:36 UTC+1, Christopher Small wrote:
>>>
>>>
>>> Greetings!
>>>
>>> I'm happy to announce today the release of Oz 1.4.0.
>>>
>>> https://github.com/metasoarous/oz
>>>
>>> If you're on the Slack #datascience channel, you may have already caught
>>> wind of some earlier versions. But in the interest of introducing it more
>>> broadly, I'm posting an overview here for those of you who aren't familiar.
>>> If you *are* familiar, you may still wish to scroll down to the bottom
>>> as there are some new features available in the latest release.
>>>
>>>
>>> *Vega & Vega-Lite*
>>>
>>> Oz is based on the fantastic Vega & Vega-Lite data visualization JS
>>> libraries, and so to really understand what Oz has to offer, it's best to
>>> start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics,
>>> an approach to data visualization which emphasizes writing declarative
>>> descriptions of how properties of data should translate to aesthetic
>>> attributes of a visualization. This approach guided the design of the R's
>>> popular ggplot2 library, and has since influenced numerous libraries in
>>> other languages.
>>>
>>> Vega & Vega-Lite take this vision further in two important ways:
>>>
>>>1. In Vega & Vega-Lite, data visualizations are described using *pure
>>>data*. This makes it more declarative, and confers all the benefits
>>>we know and love about data-driven programming in Clojure. For instance,
>>>you can send a chunk of Vega or Vega-Lite data over the wire from one
>>>program to another effortlessly (as Oz does), and load it up in another
>>>process without having to worry about the security concerns of executing
>>>someone else's code. The bottom line is that Vega & Vega-Lite are
>>>philosophically and technically compatible with "the Clojure way" (IT'S.
>>>JUST. DATA.).
>>>2. Vega & Vega-Lite take the Grammar of Graphics one step further by
>>>introducing a Grammar of Interaction. You can declaratively describe the
>>>addition of controls (dropdowns, checkboxes, etc) and interactive
>>>properties of the visualization itself (click, hover, etc), and use the
>>>data from these interactions to inform other parts of a visualization. 
>>> For
>>>example, you might highlight a set of points in one part of a
>>>visualization, and display summary statistics about that selection in
>>>another. This is facilitated in part by a general purpose dataflow 
>>> language
>>>as part of the greater spec.
>>>
>>> Vega itself is highly customizable and flexible, but somewhat verbose
>>> and not suitable for day to day visualization tasks. Vega-Lite steps in as
>>> a somewhat higher level and more automated flavor which itself compiles
>>> down to Vega. I have been using them together for a better part of a year
>>> now, and can say without reservation that they are amazing. For years I've
>>> longed for a ggplot2 from Clojure, 

Re: `lein test` 28x slower than `lein run`.... Why?

[Alan Thompson]

Never mind, I found the problem.  During testing I had enabled Plumatic
Schema function validation:


(s/set-fn-validation! true) ; enforce fn schemas
Disabling validation made `lein test` and `lein run` produce comparable
times.
Alan




On Sat, Dec 15, 2018 at 10:41 AM Alan Thompson  wrote:

> Hi,
>
> I'm seeing something I never expected with Leiningen, namely that `lein
> test` can take 28x longer to run a task than if it is invoked via `lein
> run`.  Elapsed time measurements (sec):
>
> *   function   test
>   run   ratio*
> :add-tree-xml 0.3140.188  *1.7x*
> :remove-whitespace-leaves 5.1040.183 *28x*
> :hid->bush0.4290.009 *48x*
>
> From the table, you can see that the speed ratio varies quite a bit
> depending on the task.  Since the slowest task is 28x, I'm using that as a
> reference point. I have my `:jvm-opts` in project.clj set as follows:
>
> :jvm-opts ["-Xms500m" "-Xmx2g" "-server"]
>
> It seems to make no difference if I use -Xmx value of 2g or 8g.  Using a
> flat of "-server", "-client" or nothing also makes no significant
> difference.
>
> I have found no information in the lein docs that might explain such huge
> variations.  Any ideas?
>
> 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.

`lein test` 28x slower than `lein run`.... Why?

[Alan Thompson]

Hi,

I'm seeing something I never expected with Leiningen, namely that `lein
test` can take 28x longer to run a task than if it is invoked via `lein
run`.  Elapsed time measurements (sec):

*   function   test
  run   ratio*
:add-tree-xml 0.3140.188  *1.7x*
:remove-whitespace-leaves 5.1040.183 *28x*
:hid->bush0.4290.009 *48x*

>From the table, you can see that the speed ratio varies quite a bit
depending on the task.  Since the slowest task is 28x, I'm using that as a
reference point. I have my `:jvm-opts` in project.clj set as follows:

:jvm-opts ["-Xms500m" "-Xmx2g" "-server"]

It seems to make no difference if I use -Xmx value of 2g or 8g.  Using a
flat of "-server", "-client" or nothing also makes no significant
difference.

I have found no information in the lein docs that might explain such huge
variations.  Any ideas?

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.

Re: (float 0.819869321599107) = 0.81986934 ?

[Alan Thompson]

For more precision, use `double`, which is a 64-bit double-precision
floating-point value

(float  0.819869321599107) => 0.81986934
(double 0.819869321599107) => 0.819869321599107


https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Double.html



On Sat, Dec 15, 2018 at 10:18 AM Alan Thompson  wrote:

> An IEEE-754 floating point value has only 32 bits (total), which
> corresponds to approximately 8 decimal digits.  For full info, see the java
> spec:
>
>
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Float.html
>
> 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: (float 0.819869321599107) = 0.81986934 ?

[Alan Thompson]

An IEEE-754 floating point value has only 32 bits (total), which
corresponds to approximately 8 decimal digits.  For full info, see the java
spec:


https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Float.html

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: [ANN] Lancaster 0.6.0 - Avro Schema Creation / Serialization / Deserialization

[Alan Thompson]

Looks nice.
Alan

On Sat, Nov 17, 2018 at 6:57 PM Chad Harrington 
wrote:

> https://github.com/deercreeklabs/lancaster
>
> Lancaster is an Apache Avro  library
> for Clojure and ClojureScript. It aims to be fully compliant with the Avro
> Specification . Lancaster
> is faster than JSON encoding / decoding and produces much smaller output.
> It also supports Avro schema evolution
> ,
> allowing your data formats to change over time without breaking things.
>
> Issues and PRs are welcomed.
>
> Chad Harrington
> chad.harring...@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.
> 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: Plumatic Schema error in CLJS

[Alan Thompson]

OK, I found the cause of the error.  In a dependent namespace, I had
defined some schemas:

(ns tupelo.schema
  "Prismatic Schema type definitions"
  (:require [schema.core :as s])
  #?(:clj (:import [java.util HashSet] ))
  #?(:clj (:gen-class)))

(def Set
  "Either a Clojure hash-set or a java.util.HashSet"
  (s/either #{s/Any}
*#?(:clj* java.util.HashSet*)*))  ; <= *This was missing the
#?(:clj ...)*   and caused the error








On Sun, Nov 4, 2018 at 9:43 PM Alan Thompson  wrote:

> I am seeing the following errors in CLJS, but not in CLJ:
>
> ERROR in (dotest-line-695) (schema/core.js:33:64)
> expected: (clojure.core/= (t/thru 9) (t/glue-rows data))
>   actual: #object[Error Error: No protocol method Schema.spec defined for
> type undefined: ]
>
>
> The errors disappear if I remove Plumatic Schema elements of the function
> definition:
>
> ; this one produces the error in clojurescript (clojure runs fine)
> (s/defn glue-rows  :- tsk/List
>   [coll-2d :- tsk/List]
> ...
>
> ; this one works fine in both clojure and clojurescript
> (s/defn glue-rows  :- tsk/List
>   [coll-2d :- tsk/List]
> ...
>
>
> Any clues as to the cause of this behavior?
> 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.

Plumatic Schema error in CLJS

[Alan Thompson]

I am seeing the following errors in CLJS, but not in CLJ:

ERROR in (dotest-line-695) (schema/core.js:33:64)
expected: (clojure.core/= (t/thru 9) (t/glue-rows data))
  actual: #object[Error Error: No protocol method Schema.spec defined for
type undefined: ]


The errors disappear if I remove Plumatic Schema elements of the function
definition:

; this one produces the error in clojurescript (clojure runs fine)
(s/defn glue-rows  :- tsk/List
  [coll-2d :- tsk/List]
...

; this one works fine in both clojure and clojurescript
(s/defn glue-rows  :- tsk/List
  [coll-2d :- tsk/List]
...


Any clues as to the cause of this behavior?
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.

Re: Prototype code for enhanced CIDER code completion for Java methods

[Alan Thompson]

I love Cursive and use the IntelliJ Vim keybindings everyday.  Apparently
they have alternate keybindings for those of you from the dark side.
Alan

On Wed, Oct 17, 2018 at 4:19 AM 'somewhat-functional-programmer' via
Clojure  wrote:

> I appreciate your thoughtful response -- I wish some of the other tooling
> could do this level of analysis but I can only imagine the time it took
> Colin to implement :-).  Like I mentioned in my response to him -- I'm
> going to have to seriously consider leaving the cult of emacs not only for
> Java but maybe Clojure too :-).
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, October 17, 2018 3:56 AM, Aaron Cohen 
> wrote:
>
> This seems like it could be done using threading.
>
> (-> "my-string"
>(.ch<-- completion should give you good results here, for only
> String methods
>
>
> (-> (new MyType)
>   (.<-- completion should give you only methods of MyType
>
>
> ; One interesting case is the following:
> (def foo "hello")
>
> ; foo's type isn't known, so would need to be hinted
> (-> ^String foo
> (.to  <-- good completions again, because of the type hint
>
> I think you won't be able to get all the way to your jvm macro, but likely
> pretty close, and it's much more idiomatic...
>
> The doto macro is also useful in a similar way, and often what you want
> when using some of the more byzantine java libraries.
>
> (All of the above works in Cursive, I'm not sure about how it works in
> CIDER, but I assume it's equivalent).
>
> --Aaron
>
>
>
> On Tue, Oct 16, 2018 at 8:30 PM 'somewhat-functional-programmer' via
> Clojure  wrote:
>
>> Comments inline...  I really appreciate you taking the time to look at
>> this.  I think I am still imprecise in my language -- I hope the comments
>> below doesn't come across as too tedious :-)...
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, October 16, 2018 7:46 PM, Timothy Baldridge <
>> tbaldri...@gmail.com> wrote:
>>
>> As you say, this is a limitation in the code completer. In Cursive this
>> problem doesn't exist to this extent, when I type `(.get` the completer
>> responds with a list of methods and classes that could be completed to that
>> method, starting with classes in the namespace I'm currently editing.
>>
>>
>> I think we are saying the same thing here.  I believe compliment (the
>> library CIDER/other clojure tooling uses for code completion) does what we
>> are describing (showing Java methods and fields from multiple Java types
>> that are imported into the namespace currently being edited (or type hinted
>> in locals/function definitions).  My point is I want more -- I want the
>> completion list to only include methods and fields from the type I as a
>> developer know that I have.
>>
>> Like a Java IDE:
>> MyType a = new MyType();
>> Now typing "a." yields just completions valid for MyType, and not 5 other
>> types I've used nearby.
>>
>> Yes, this takes static analysis, or perhaps some indexing and
>> introspection. But changing the syntax is never really going to gain
>> traction here, as manually typing the name of every method just so my
>> editor can produce a list seems like me conforming to my tool rather than
>> my tool learning to work with me.
>>
>>
>> Just to make sure I'm completely clear -- I'm *not* advocating a change
>> to clojure lang -- only proposing a macro/library.  The prototype macro I
>> wrote simply transforms the (Type:method ...) syntax into the (.
>> instance-expr member-symbol) that (.method ...) macroexpands into anyhow.
>> This is not intended to replace (.method obj args) notation.
>>
>> I'm not sure what you mean by "manually typing the name of every method
>> just so my editor can produce a list".
>>
>> The way this works is, you type "(MyType:" and get presented with a list
>> of completions that are *only* applicable to MyType -- there's no manually
>> typing lists of methods and fields anywhere.  And, the way this works for
>> me in CIDER, I type "(My" and I get "(MyType", then I add a ":", and
>> now I get completions just for MyType -- it also shows me the Java
>> signature of the methods as I highlight a potential completion.  There's no
>> manually seeding the list anywhere...
>>
>> The imported classes in the current namespace are stored in the mappings
>> attribute. It seems like an editor should be able to install hooks into
>> that and index the methods on the classes to provide this feedback.
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Namespace.java#L123
>>
>>
>>
>> Yes I agree -- and I believe that's exactly what the existing tooling
>> already does -- I just want more precision.
>>
>> Some of my motivation has been working with monstrously large class
>> libraries in Java.  GIS libraries in Java are notoriously class/method
>> heavy and after importing many of these classes into a namespace,
>> completion that cannot narrow down to the exact type I'm using for the
>> reasons we agree on -- simply is painful to work 

Re: [ANN] Clojure 1.10.0-beta1

[Alan Thompson]

Looks good to me, tested on both prod and open source code.
Alan

On Fri, Oct 5, 2018 at 9:21 PM Alex Miller  wrote:

> Now is a great time to try 1.10.0-beta1 and let us know if you find any
> major bugs or performance issues.
>
> I also meant to mention that all changes in Clojure 1.10 are now collected
> in the changelog:
>
> https://github.com/clojure/clojure/blob/master/changes.md
>
> At this point, we consider 1.10 to be feature complete and only plan to
> address critical bug fixes so we can move expeditiously towards a final
> release.
>
>
>
> On Friday, October 5, 2018 at 11:09:25 PM UTC-5, Alex Miller wrote:
>>
>> 1.10.0-beta1 is now available. You can try it with clj using:
>>   clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version
>> "1.10.0-beta1"}}}'
>>
>> 1.10.0-beta1 includes the following changes since 1.10.0-alpha9:
>>
>>- Revert change for CLJ-1550
>> - Classes generated by
>>deftype and defrecord don’t play nice with .getPackage
>>- Revert change for CLJ-1435
>> - 'numerator and
>>'denominator fail to handle integral values (i.e. N/1)
>>- Add changelog since 1.9
>>- Mark prepl as alpha
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Alan Thompson]

How would the :when and :do forms work?
Alan

On Wed, Oct 3, 2018 at 7:22 PM Mark Engelberg 
wrote:

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

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

Re: Keyword namespacing best practices

[Alan Thompson]

It is easy to overdo it when trying to predict future needs.  I always
(now) do the minimal solution, with the expectation that it *may* evolve in
the future.

Since the parts that do need change (say 5% ?) are usually not the ones I
would have predicted, I am usually very glad I didn't over-engineer the API
in advance.

Alan

PS:  YAGNI rules - and it's easier/less painful to fix the 5% where it's
wrong than the 95% where it's right

PPS:  YMMV (but not much!)



On Sun, Sep 30, 2018 at 7:12 PM Michael Gardner  wrote:

>
> > On Sep 30, 2018, at 18:54, Eric Lavigne  wrote:
> >
> > I would not use keyword namespaces in this situation. Users of the
> "fetch" function will likely type :timeout, :status, and :body when using
> this function. Keyword namespaces would just force users to type longer
> names for these.
>
> Thanks for the response, Eric. Leaving :timeout aside for the moment, the
> issue I'm wrestling with is that you never know what your clients will do
> with the response. That makes it hard to anticipate the likelihood of
> keyword collisions, especially for a more complex compound response. There
> are also some fringe benefits, like greater synergy with clojure.spec and a
> kind of self-description effect (again, more relevant for larger APIs).
>
> I've also heard some library developers say they've adopted namespaced
> keywords almost everywhere, so I guess I'm just wondering about where to
> draw that line.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: IF, WHEN or SOME

[Alan Thompson]

Should have been:(evens? nil)

On Thu, Sep 20, 2018 at 1:47 PM Alan Thompson  wrote:

> `println` always returns `nil`.  So it prints "one", returns `nil`, and
> you try to execute the form:
>
> (nil)  => NullPointerException
>
>
> user=> (evens? (println “one”))
> one
> NullPointerException   user/eval239 (NO_SOURCE_FILE:74)
>
>
> On Thu, Sep 20, 2018 at 9:06 AM Orestis Markou  wrote:
>
>> evens? is not a macro, therefore when you do (evens? (println “one”)),
>> the println will be evaluated first, and its return value, nil, gets passed
>> into the evens function.
>>
>>
>>

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

Re: IF, WHEN or SOME

[Alan Thompson]

`println` always returns `nil`.  So it prints "one", returns `nil`, and you
try to execute the form:

(nil)  => NullPointerException


user=> (evens? (println “one”))
one
NullPointerException   user/eval239 (NO_SOURCE_FILE:74)


On Thu, Sep 20, 2018 at 9:06 AM Orestis Markou  wrote:

> evens? is not a macro, therefore when you do (evens? (println “one”)), the
> println will be evaluated first, and its return value, nil, gets passed
> into the evens function.
>
>
> 20 Σεπ 2018, 5:44 μμ, ο χρήστης «Stephen Feyrer »
> έγραψε:
>
> Hi,
>
> I have just been playing around with this idea and I got something.
>
> user=> (def some-numbers ‘(2 4 6 8))  #This is my value to test later.
> #’user/some-numbers
> user=> (def evens? (partial (when (apply = (map even? some-numbers)
> #’user/evens?
> user=> (evens? (println “one”))
> one
> NullPointerException   user/eval239 (NO_SOURCE_FILE:74)
> user=>
>
> What is my mistake?
>
> Thanks.
>
>
> On 12 December 2017 at 07:52, Stephen Feyrer 
> wrote:
>
>> Hi Tim,
>>
>> Thank you.
>>
>>
>> --
>> Kind regards
>>
>> Stephen.
>>
>> On 11 December 2017 at 23:58, Timothy Baldridge 
>> wrote:
>>
>>> I talked a bit about this in my video on Boolean Blindness:
>>> https://www.youtube.com/watch?v=K1LaaJMscCc
>>>
>>> Might be worth a watch.
>>>
>>> On Mon, Dec 11, 2017 at 4:56 PM, Stephen Feyrer <
>>> stephen.fey...@gmail.com> wrote:
>>>
 Hi there,

 I have been trying to shake this thought for a while now.  Essentially,
 my thought was if you can return a function why not decision component of
 an IF, WHEN or SOME statement?  That would give you a re-usable named
 choice.

 Then you could write:

 (celebration: do-something do-something-else)


 This would be equivalent to writing:

 (def success [apples bananas pears])

 (defn celebration: [x y] (if (empty? success) x y))

 (celebration: (do-something do-something-else))


 I'm reasonably certain of the foolishness of this thought but
 occasionally, I have doubts.

 Maybe I'm barking up the wrong tree or possibly I've seen something
 like this before and forgotten about it.  Perhaps, this is just taking
 things too far...  Either way, it's deferring the choice until it's
 needed.  In the right hands it could make for more readable code.

 For completeness sake, to define the first form above you'd use:

 (defc celebration: (if (empty? success)))


 A more usable example might look like:

 (def nums [1 2 3 4 5 6 7 8])

 (defc even-nums: (some (even? nums)))

 I guess this makes the real question, is it a good thing to be able to
 defer choice like this?


 Btw, defc would be like def-choice but other options might be deft -
 def-test or defp - def-predicate.


 --
 Kind regards

 Stephen

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

>>>
>>>
>>>
>>> --
>>> “One of the main causes of the fall of the Roman Empire was that–lacking
>>> zero–they had no way to indicate successful termination of their C
>>> programs.”
>>> (Robert Firth)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> 

Still loving the lein-test-refresh

[Alan Thompson]

Just tried the test selector feature, which lets you use metadata to mark
only some tests to be re-run when you are focusing on a specific part of
the code.

https://github.com/jakemcc/lein-test-refresh#built-in-test-narrowing-test-selector

Loving it!

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.

Agile in 2018 - Martin Fowler talk

[Alan Thompson]

Very good talk if you haven't seen it yet:

https://www.infoq.com/presentations/agile-2018

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

Clojure treat all Thread's as deamon?

[Alan Thompson]

There is question on StackOverflow:

https://stackoverflow.com/questions/51776663/why-does-looping-over-a-large-amount-of-data-in-another-thread-cause-an-overacti/5164#5164

In my answer, I document how Clojure seems to tread a manually created java
Thread as if it a daemon thread, even though `(isDaemon thread)` returns
`false`.  The only way to prevent early termination of the program is via a
manual `(.join thread)` call.

This seems like it is a bug in the expected behavior re non-daemon
threads.  Is this correct?

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.

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

[Alan Thompson]

There is also a function `glue`
<https://github.com/cloojure/tupelo#gluing-together-like-collections> for
combining like collections:

-
Gluing Together Like Collections

The concat function can sometimes have rather surprising results:

(concat {:a 1} {:b 2} {:c 3} );=>   ( [:a 1] [:b 2] [:c 3] )

In this example, the user probably meant to merge the 3 maps into one.
Instead, the three maps were mysteriously converted into length-2 vectors,
which were then nested inside another sequence.

The conj function can also surprise the user:

(conj [1 2] [3 4] );=>   [1 2  [3 4] ]

Here the user probably wanted to get [1 2 3 4] back, but instead got a
nested vector by mistake.

Instead of having to wonder if the items to be combined will be merged,
nested, or converted into another data type, we provide the glue function to
 *always* combine like collections together into a result collection of the
same type:

; Glue together like collections:
(is (= (glue [ 1 2] '(3 4) [ 5 6] )   [ 1 2 3 4 5 6 ]  ))   ; all
sequential (vectors & lists)
(is (= (glue {:a 1} {:b 2} {:c 3} )   {:a 1 :c 3 :b 2} ))   ; all maps
(is (= (glue #{1 2} #{3 4} #{6 5} )  #{ 1 2 6 5 3 4 }  ))   ; all sets
(is (= (glue "I" " like " \a " nap!" )   "I like a nap!"   ))   ; all
text (strings & chars)
; If you want to convert to a sorted set or map, just put an empty one first:
(is (= (glue (sorted-map) {:a 1} {:b 2} {:c 3})   {:a 1 :b 2 :c 3} ))
(is (= (glue (sorted-set) #{1 2} #{3 4} #{6 5})  #{ 1 2 3 4 5 6  } ))

An Exception will be thrown if the collections to be 'glued' are not all of
the same type. The allowable input types are:

   -

   all sequential: any mix of lists & vectors (vector result)
   -

   all maps (sorted or not)
   -

   all sets (sorted or not)
   -

   all text: any mix of strings & characters (string result)



On Wed, Jul 18, 2018 at 1:13 PM, Alan Thompson  wrote:

> As someone mentioned, the functions `prepend` and `append` exist in the
> Tupelo library
> <https://github.com/cloojure/tupelo#adding-values-to-the-beginning-or-end-of-a-sequence>
> to prevent this kind of confusion:
>
> from the README:
> 
> 
> Adding Values to the Beginning or End of a Sequence
>
> Clojure has the cons, conj, and concat functions, but it is not obvious
> how they should be used to add a new value to the beginning of a vector or
> list:
>
> ; Add to the end
> > (concat [1 2] 3);=> IllegalArgumentException
> > (cons   [1 2] 3);=> IllegalArgumentException
> > (conj   [1 2] 3);=> [1 2 3]
> > (conj   [1 2] 3 4)  ;=> [1 2 3 4]
> > (conj  '(1 2) 3);=> (3 1 2)   ; oops
> > (conj  '(1 2) 3 4)  ;=> (4 3 1 2) ; oops
> ; Add to the beginning
> > (conj 1  [2 3] ) ;=> ClassCastException
> > (concat   1  [2 3] ) ;=> IllegalArgumentException
> > (cons 1  [2 3] ) ;=> (1 2 3)
> > (cons   1 2  [3 4] ) ;=> ArityException
> > (cons 1 '(2 3) ) ;=> (1 2 3)
> > (cons   1 2 '(3 4) ) ;=> ArityException
>
> Do you know what conj does when you pass it nil instead of a sequence? It
> silently replaces it with an empty list: (conj nil 5) ⇒ (5) This can
> cause you to accumulate items in reverse order if you aren’t aware of the
> default behavior:
>
> (-> nil
>   (conj 1)
>   (conj 2)
>   (conj 3));=> (3 2 1)
>
> These failures are irritating and unproductive, and the error messages
> don’t make it obvious what went wrong. Instead, use the simple prepend and
>  append functions to add new elements to the beginning or end of a
> sequence, respectively:
>
> (append [1 2] 3  )   ;=> [1 2 3  ]
> (append [1 2] 3 4)   ;=> [1 2 3 4]
>
> (prepend   3 [2 1])  ;=> [  3 2 1]
> (prepend 4 3 [2 1])  ;=> [4 3 2 1]
>
> Both prepend and append always return a vector result.
> <https://github.com/cloojure/tupelo#combining-scalars-and-vectors>
>
>
>
>
> On Wed, Jul 18, 2018 at 8:17 AM, Christian Seberino 
> wrote:
>
>> Actually I was just kicked out of paradise.  concat always returns a list
>> and does NOT return a vector for this (concat [1 2] [3 4]) sadly.
>>
>> cs
>>
>> ___
>>
>> Christian Seberino, Ph.D.
>> Phone: (936) 235-1139
>> Email: cseber...@gmail.com
>> ___
>>
>>
>>
>> On Wed, Jul 18, 2018 at 2:16 AM, Didier  wrote:
>>
>>> It's never a good idea to use the wrong data structure for the job.
>>>
>>> And thus Clojure takes the sta

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

[Alan Thompson]

As someone mentioned, the functions `prepend` and `append` exist in the
Tupelo library

to prevent this kind of confusion:

from the README:

Adding Values to the Beginning or End of a Sequence

Clojure has the cons, conj, and concat functions, but it is not obvious how
they should be used to add a new value to the beginning of a vector or list:

; Add to the end
> (concat [1 2] 3);=> IllegalArgumentException
> (cons   [1 2] 3);=> IllegalArgumentException
> (conj   [1 2] 3);=> [1 2 3]
> (conj   [1 2] 3 4)  ;=> [1 2 3 4]
> (conj  '(1 2) 3);=> (3 1 2)   ; oops
> (conj  '(1 2) 3 4)  ;=> (4 3 1 2) ; oops
; Add to the beginning
> (conj 1  [2 3] ) ;=> ClassCastException
> (concat   1  [2 3] ) ;=> IllegalArgumentException
> (cons 1  [2 3] ) ;=> (1 2 3)
> (cons   1 2  [3 4] ) ;=> ArityException
> (cons 1 '(2 3) ) ;=> (1 2 3)
> (cons   1 2 '(3 4) ) ;=> ArityException

Do you know what conj does when you pass it nil instead of a sequence? It
silently replaces it with an empty list: (conj nil 5) ⇒ (5) This can cause
you to accumulate items in reverse order if you aren’t aware of the default
behavior:

(-> nil
  (conj 1)
  (conj 2)
  (conj 3));=> (3 2 1)

These failures are irritating and unproductive, and the error messages
don’t make it obvious what went wrong. Instead, use the simple prepend and
append functions to add new elements to the beginning or end of a sequence,
respectively:

(append [1 2] 3  )   ;=> [1 2 3  ]
(append [1 2] 3 4)   ;=> [1 2 3 4]

(prepend   3 [2 1])  ;=> [  3 2 1]
(prepend 4 3 [2 1])  ;=> [4 3 2 1]

Both prepend and append always return a vector result.





On Wed, Jul 18, 2018 at 8:17 AM, Christian Seberino 
wrote:

> Actually I was just kicked out of paradise.  concat always returns a list
> and does NOT return a vector for this (concat [1 2] [3 4]) sadly.
>
> cs
>
> ___
>
> Christian Seberino, Ph.D.
> Phone: (936) 235-1139
> Email: cseber...@gmail.com
> ___
>
>
>
> On Wed, Jul 18, 2018 at 2:16 AM, Didier  wrote:
>
>> It's never a good idea to use the wrong data structure for the job.
>>
>> And thus Clojure takes the stance that it won't make bad ideas easy for
>> you to use. Yet, it will never prevent you from doing anything.
>>
>> If you want to do something bad, you'll need to get your own hands dirty.
>>
>> That's why slow data structure access functions don't exist as standard.
>> That's why data transforms are lazy by default. And why the non lazy
>> variant (transducers) do loop fusion for you. That's why mutability is ugly
>> and requires you to wrap things in extra verbosity. That's why OOP isn't
>> there, and forces you to use the host interop if you want it. That's why
>> there's only recursive loops. Etc.
>>
>> The Clojure standard lib is opinionated. It's not trying to make
>> everything easy and convenient. It's trying to make things simple to reason
>> about, and promote Rich Hickeys opinion of what is a good idea, and what
>> isn't.
>>
>> But, it can afford to be this way, because it made itself a Lisp, meaning
>> it gave you all the power needed to disagree and make your own core, which
>> follows your own opinions of good and bad.[1]
>>
>> Now, I recommend that everyone should have a core library of their own
>> that they keep around for cases like this, where they disagree.
>>
>> And for beginners, I mean, what are you trying to teach them? What
>> problem requires them to add items to the beginning and end of an ordered
>> collection?
>>
>> Anyways, my advice is to teach them concat. It's even nicer then
>> append/prepend. You just give it the arguments where you want them to go.
>>
>> (concat [1] [2 3])
>>
>> (concat [1 2] [3])
>>
>> And it works for any type of ordered collections, even arrays.
>>
>> Also, this blog I think does a great job at teaching all this to a
>> beginner https://medium.com/@greg_63957/conj-cons-concat-oh-my-1398a2
>> 981eab
>>
>>
>>
>> [1] Except for reader macros. Rich didn't want you to be able to change
>> the whole program syntax in unconstrained ways. That's probably a good
>> thing to at least keep the foundation universal accross code bases.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To 

Re: concat and mapcat not sufficiently lazy

[Alan Thompson]

I have added this to the Tupelo library 
 as `tupelo.lazy/join`:

API docs:http://cloojure.github.io/doc/tupelo/tupelo.lazy.html

source:

 (defn join
   "Lazily concatenates a sequence-of-sequences into a flat sequence."
   [sequences]
   (lazy-seq
 (when-let [seq-of-seqs (seq sequences)]
   (concat (first seq-of-seqs) (join (rest seq-of-seqs))

with tests:

(dotest
  (is= [](lazy/join [[]]))
  (is= [1]   (lazy/join [[1]]))
  (is= [1 2 3 ]  (lazy/join [[1] [2 3]]))
  (is= [1 2 3 4 5 6] (lazy/join [[1] [2 3] [4 5 6]]))
  (is= [1 2 3 4 5 6] (lazy/join [[] [1] [] [2 3] [4 5 6] []])))


On Wed, Jul 18, 2018 at 3:08 AM, Nicola Mometto  wrote:

> Yes, you’re right that neither directly handles `concat`, however CLJ-1583
> improves the behaviour of both your examples and is _necessary_ to fix any
> `apply` related laziness issues
>
> user=>  (first (apply concat (map #(do (println %) [%]) (list 1 2 3 4 5
> 1
> 2
> 3
> 1
> user=> (first (mapcat #(do (println %) [%]) (list 1 2 3 4 5)))
> 1
> 2
> 3
> 1
>
> While CLJ-1218 in conjunction with CLJ-1583 “fixes” the mapcat example:
>
> user=>  (first (mapcat #(do (println %) [%]) (list 1 2 3 4 5)))
> 1
> 1
>
> So to make all your examples as lazy as possible we need a combination of
> CLJ-1218, CLJ-1583 and a `join`-like `concat`
>
>
>
>
> On 18 Jul 2018, at 09:24, Mark Engelberg  wrote:
>
> Thanks, I hadn't seen those issues.
> https://dev.clojure.org/jira/browse/CLJ-1218 talks about mapcat, and
> https://dev.clojure.org/jira/browse/CLJ-1583 talks about apply. Those are
> aspects of the problem, for sure, but fixing those two issues would not
> solve the problem with (apply concat ...), I don't think, because another
> facet of the problem is that concat's args are of the form [x y & zs].
>
> Gary Fredericks recognizes this problem in the comments for CLJ-1218: "I
> realized that concat could actually be made lazier without changing its
> semantics, if it had a single [& args] clause that was then implemented
> similarly to join above."
>
> But for the most part, the comments are focused on fixing mapcat by
> implementing a new function, join, rather than fixing the problem with
> concat directly.  Seems better to fix concat, if possible.
>
> I'm truly astonished I haven't gotten bitten by this before.  This is a
> pattern I use frequently in my code; I guess I just never had deep enough
> recursion for it to slow things down enough for me to realize what was
> happening.
>
>
>
> On Wed, Jul 18, 2018 at 12:53 AM, Nicola Mometto 
> wrote:
>
>> This behaviour is known and there are a couple of tickets about it :
>>
>> https://dev.clojure.org/jira/browse/CLJ-1583
>> https://dev.clojure.org/jira/browse/CLJ-1218
>>
>> On Wed, 18 Jul 2018, 08:28 Mark Engelberg, 
>> wrote:
>>
>>> I'm kind of surprised I haven't run across this before, but tonight I
>>> was debugging a function that was doing an explosion of computation to
>>> return the first value of a lazy sequence, and I was able to reduce the
>>> problem down to this example:
>>>
>>> > (first (apply concat (map #(do (println %) [%]) (list 1 2 3 4 5
>>> 1
>>> 2
>>> 3
>>> 4
>>> 1
>>>
>>> The last 1 is the return value, but notice that it realized 4 values in
>>> order to return the 1.  This has nothing to do with chunked sequences, by
>>> the way -- a list is an unchunked sequence.  It appears to be that the way
>>> concat is written, it realizes the first two elements, and then another two
>>> elements in a recursive call before the lazy-seq kicks in.
>>>
>>> In the function in question, the "apply concat" was part of a recursion,
>>> causing that explosion of realizing values (four at each level of the
>>> recursion, it would seem) to get at the first element.
>>>
>>> Note that this affects mapcat as well, which relies on concat under the
>>> hood:
>>> > (first (mapcat #(do (println %) [%]) (list 1 2 3 4 5)))
>>> 1
>>> 2
>>> 3
>>> 4
>>> 1
>>>
>>> I don't see a quick fix other than writing my own improved
>>> concat/mapcat.  Do you?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send 

Re: Windows Cygwin lein repl

[Alan Thompson]

I have successfully used Cygwin on many older versions of Windows.  Once
installed, you can 95% forget you aren't on a real linux system.
Alan

On Fri, Jun 1, 2018 at 7:55 AM,  wrote:

> Hi Sean,
>
> Unfortunately, I'm on Windows 8.  Even if that weren't an issue, I'd still
> have to navigate a strict set of software procurement policies.  That would
> be worth a try though.
>
> Thanks though, nice thought.
>
>
> On Friday, May 25, 2018 at 7:23:30 AM UTC+1, Sean Corfield wrote:
>>
>> If you’re on Windows 10, I highly recommend trying Windows Subsystem for
>> Linux and Ubuntu (or one of the other distros in the Microsoft Store). I do
>> all of my Clojure development on Windows that way.
>>
>>
>>
>> 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
>> Alan Thompson 
>> *Sent:* Thursday, May 24, 2018 4:48:58 PM
>> *To:* clo...@googlegroups.com
>> *Subject:* Re: Windows Cygwin lein repl
>>
>> I have used cygwin extensively in the past, but not recently.  If you
>> haven't tried it yet, you should try installing Git For Windows and then
>> use the "Git Bash" command shell.
>> Alan
>>
>> On Wed, May 23, 2018 at 3:37 AM,  wrote:
>>
>>> A quick note to anyone coming to this later.  I haven't been able to fix
>>> this and have reverted back to 2.7.1
>>>
>>>
>>> --
>>> Kind regards
>>>
>>> Stephen
>>>
>>> --
>>> 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 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: Windows Cygwin lein repl

[Alan Thompson]

I have used cygwin extensively in the past, but not recently.  If you
haven't tried it yet, you should try installing Git For Windows and then
use the "Git Bash" command shell.
Alan

On Wed, May 23, 2018 at 3:37 AM,  wrote:

> A quick note to anyone coming to this later.  I haven't been able to fix
> this and have reverted back to 2.7.1
>
>
> --
> Kind regards
>
> Stephen
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: accessing symbols in local context of a closure

[Alan Thompson]

No, it is hidden inside the closure and can't be accessed from the outside.

On Thu, May 24, 2018 at 11:22 AM, Sonny To  wrote:

> (defn foo[]
>  (let [x  1]
>(fn []
>  (+ x 1)
> )
>  )
>
> (def bar  (foo))
>
> Is there a way to get the value of x from closure bar?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] packthread 0.1.10

[Alan Thompson]

If you are interested in alternatives to `clojure.core/->`, you may be
interested in the `it->` macro from the Tupelo library
.  Here is a
summary:

=

Usage examples for tupelo.core/it→
Name:
"it-thread" (literate threading macro)

Homepage: https://github.com/cloojure/tupelo
Lein
coords: [tupelo "0.9.75"]

Usage: clojure

  (it-> ...)

Why?

Because every time you’ve wanted to:

(ns xyz
  (:use tupelo.core))
(it-> 3
  (let [x 9]
(- x it))
  (inc it)
  (- it 6));=> 1

(it-> 42
  (if true
(inc it)
:blah)) ;=> 43
(it-> 42
  (if false
(inc it)
:blah)) ;=> :blah
; works same for `if-not`, `when`, `when-not`, etc.

(it-> 42
  (case 1
1 (inc it)
2 (dec it))) ;=> 43

(it-> 42
  (case 2
1 (inc it)
2 (dec it))) ;=> 41

(it-> 42
  (cond
(= 1 2)
(inc it))) ;=> 42

(it-> 42
  (cond
(= 1 1)
(dec it))) ;=> 41

(it-> 42
  (let [x 1]
(+ it x))) ;=> 43

try

The current expression is threaded through the body of the try form. The
*same* value is threaded through each catchclause and any finally clause.

(ti-> 42
  (try
(inc it)
(catch Exception e
  (dec it))) ;=> 43

(it-> 42
  (try
(+ it :foo)
(catch Exception e
  (dec it ;=> 41

(it-> 42
  (try
(inc it)
(finally
  (+ 10 it ;=> 53
; with anonymous functions
(it-> 7
  ((fn [x y] (* x y)) it 3))  ;=> 21
(it-> 42
  #(-> % inc inc)) ;=> 44



On Tue, Apr 3, 2018 at 8:40 AM, Jason Felice 
wrote:

> This release handles `if-some` and `when-some` and supports ClojureScript.
>
> packthread
>
> https://github.com/maitria/packthread
>
> "Heavy" threading macros.
> Why?
>
> Because every time you've wanted to:
>
> (-> 42
>   (let [x 79]
> (+ x))
>   inc)
>
> but clojure wouldn't let you.
> +>
>
> Threads value through forms in much the same way as ->, except for
> special handling of the following forms:
>
> if,
> if-not, if-let, if-some, when, when-let, when-not, when-some
>
> The value is threaded through the *then* and *else* clauses
> independently, leaving the test conditions alone. If an else clause is
> missing, it is will be supplied as though the value had been threaded
> through identity.
>
> For example,
>
> (+> 42 (if true inc)) ;=> 43
> (+> 42 (if false inc)) ;=> 42
>
> In when, when-let, when-not, and when-some forms, the value is threaded
> through every form in the body, not just the last.
> case
>
> The values being compared are left untouched and the value is threaded
> through the expr clause of each condition.
>
> For example,
>
> (+> 42
>   (case 1
> 1 inc
> 2 dec)) ;=> 43
>
> (+> 42
>   (case 2
> 1 inc
> 2 dec)) ;=> 41
>
> cond
>
> The test clauses are left untouched and the value is threaded through the
> expr clauses of each condition. If there's no :else condition, +> pretends
> it was (identity).
>
> For example,
>
> (+> 42
>   (cond
> (= 1 2)
> inc)) ;=> 42
>
> (+> 42
>   (cond
> (= 1 1)
> dec)) ;=> 41
>
> do
>
> The current expr is threaded through the body forms of the do.
> let
>
> The current expression is threaded through the body of the let form, with
> the bindings in place. For example:
>
> (+> 42
>   (let [x 1]
> (+ x))) ;=> 43
>
> try
>
> The current expression is threaded through the body of the try form. The
> *same* value is threaded through each catchclause and any finally clause.
>
> (+> 42 (try
>  inc
>(catch Exception e
>  dec)) ;=> 43
>
> (+> 42 (try
>  (+ :foo)
>(catch Exception e
>  dec))) ;=> 41
>
> (+> 42 (try
>  inc
>(finally dec))) ;=> 42
>
> in
>
> Threads inner expressions through a lens
> 
>  of value.
>
> lens is a function with two arities - 1 and 2. The 1-arity body is the
> "get" function, while the 2-arity body is the "putback" function. "get"
> lifts the value into the new 

StackOverflow Job Survey results are out

[Alan Thompson]

& Clojure is still doing well on the salary front:


https://insights.stackoverflow.com/survey/2018/#work-salary-and-experience-by-language

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

Re: [ANN] com.walmartlabs/dyn-edn 0.1.0

[Alan Thompson]

Looks very useful.  One suggestion:  the example might be easier to read if
you included the values of the env vars, and clarified the way you specify
default values:

{:connection-pool
  {:user-name #dyn/prop [DB_USER "accountsuser"]  ; default value
"accountsuser"
   :user-pw #dyn/prop DB_PW   ; no default value
   :url  #dyn/join ["jdbc:postgresql://"
   #dyn/prop [DB_HOST "localhost"]
   ":"
   #dyn/prop [DB_PORT "5432"]
   "/accounts"]}
 :web-server
  {:port #dyn/long #dyn/prop "WEB_PORT"}}


with  environment variables:

# DB_USER 
DB_PW=change-me
DB_HOST=db.example.org
# DB_PORT 
WEB_PORT=8192


yields:

{:connection-pool
  {:user-name "accountsuser"
   :user-pw "change-me"
   :url  "jdbc:postgresql://db.example.org:5432/accounts"]}
 :web-server
  {:port 8192}}






On Fri, Feb 16, 2018 at 2:20 PM, Howard Lewis Ship  wrote:

>
> com.walmartlabs/dyn-edn 0.1.0
>
> Tiny library to allow dynamic data when parsing EDN; useful for
> configuration files.
>
> https://github.com/hlship/dyn-edn
>
> For example:
>
> {:connection-pool
>   {:user-name #dyn/prop [DB_USER "accountsuser"]
>:user-pw #dyn/prop DB_PW
>:url  #dyn/join ["jdbc:postgresql://"
>#dyn/prop [DB_HOST "localhost"]
>":"
>#dyn/prop [DB_PORT "5432"]
>"/accounts"]}
>  :web-server
>   {:port #dyn/long #dyn/prop "WEB_PORT"}}
>
>
> can use environment variables to reduce down to:
>
>
> {:connection-pool
>   {:user-name "accountsuser"
>:user-pw "change-me"
>:url  "jdbc:postgresql://db.example.org:5432/accounts"]}
>  :web-server
>   {:port 8192}}
>
>
> --
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: what does future do after fn finish ?

[Alan Thompson]

You may find that using the Claypoole library is the easiest way to handle
threadpools:   https://github.com/TheClimateCorporation/claypoole
Alan

On Thu, Feb 1, 2018 at 11:16 AM, Justin Smith  wrote:

> yes, that's the idea exactly
>
> also, you might want more fine grained control of how much parallelism
> occurs (eg. if every thread is writing to the same physical device, you can
> often get better throughput by not parallelizing at all, or keeping the
> parallelism quite limited - it's worth experimenting) - there are good ways
> to control that using ThreadPoolExecutor directly, or using
> clojure.lang.PersistentQueue/EMPTY as a control construct, or core.async
> channels, or ztellman's manifold library, or the claypoole threading library
>
> On Thu, Feb 1, 2018, 03:44 Jacek Grzebyta  wrote:
>
>> Thanks folks. I see now! It should be a list of agents not list of
>> futures within agent.  Also any task sent to a agent is processed
>> within a thread anyway so I do not need to add future...
>>
>> On 1 February 2018 at 02:17, John Newman  wrote:
>>
>>> Ah, he's using one agent, I see.
>>>
>>> On Jan 31, 2018 9:15 PM, "John Newman"  wrote:
>>>
 Multiple sen-doffs to one agent will serialize it's calls, but spawning
 agents on each new task will spawn threads on a bounded thread pool, I
 believe.

 On Jan 31, 2018 8:32 PM, "Justin Smith"  wrote:

> Doing all the actions via one agent means that the actions are
> serialized though - you end up with no performance improvement over doing
> them all in a doseq in one future - the right way to do this tends to be
> trickier than it looks at first glance, and depends on your requirements.
> agents, the claypoole library, and reducers are all potentially useful. If
> parallelization leads to complex coordination needs, core.async can help
> too.
>
> On Wed, Jan 31, 2018 at 5:18 PM John Newman  wrote:
>
>> Agents manage a pool of threads for you. Try doing it without the
>> future call and see if that works (unless you're trying to do something
>> else).
>>
>> John
>>
>> On Wed, Jan 31, 2018 at 7:31 PM, Jacek Grzebyta <
>> grzebyta@gmail.com> wrote:
>>
>>> Thanks a lot. I will check it tomorrow.
>>>
>>> J
>>>
>>> On 1 Feb 2018 12:12 a.m., "Justin Smith" 
>>> wrote:
>>>
 this is exactly the kind of problem code I was describing - there's
 no backpressure on existing future tasks to hold up the launching of 
 more
 futures - the work done by the agent calling conj is negligible. You 
 need
 to control the size of the pool of threads used, and you need to impose
 back-pressure.

 On Wed, Jan 31, 2018 at 3:46 PM Jacek Grzebyta <
 grzebyta@gmail.com> wrote:

> On 31 January 2018 at 18:08, James Reeves 
> wrote:
>
>> On 31 January 2018 at 17:59, Jacek Grzebyta <
>> grzebyta@gmail.com> wrote:
>>
>>> I have application with quite intense tripe store populating
>>> ~30/40 k records per chunk (139 portions). The data are wrapped 
>>> within the
>>> future:
>>>
>>> (conj agent (future (apply task args)))
>>>
>>>  and that all together is send-off into (agent []).
>>>
>>
>> What is "agent"? The first line of code indicates that it's a
>> local collection shadowing the code function, while the second code 
>> snippet
>> indicates that you're using the core agent function.
>>
>> Also why are you sending off to an agent?
>>
>
> I have ~8sec computing task for each input dataset which generates
> those records. After that I write it into disk (in software-specific
> transaction). I just wanted to separate hard computing and io 
> operations. I
> created a side-effect method which is injected together with the 
> dataset
> into a future. The futures are async collected within a list wrapped 
> in
> agent. After the computing the main thread is waiting until all io 
> tasks
> will be finished.
>
>
>>
>> At the end of the main thread function I just use await-for and
>>> after that:
>>>
>>> (reduce + (map #(deref %) @data-loading-tasks))
>>>
>>
> As a control, tasks return number of written records.
>
>
>
>>
>>> For some reason I see the happy collecting (see attached
>>> screenshot of jconsole).
>>>
>>
>> "happy" = "heap"?
>>
>
> Both. As 

Re: Russ olsen's Clojure Book

[Alan Thompson]

Really looking forward to it!
Alan

On Mon, Jan 22, 2018 at 11:43 AM, Shaun Parker 
wrote:

> The book is now available to purchase. Thanks Russ, I can't wait to read
> it!
>
> https://pragprog.com/book/roclojure/getting-clojure
>
> On Wednesday, January 17, 2018 at 5:12:15 PM UTC-7, William Swaney wrote:
>>
>> Thanks Sean.
>>
>> On Tuesday, January 16, 2018 at 8:08:22 PM UTC-8, Sean Corfield wrote:
>>>
>>> https://pragprog.com/book/roclojure/getting-clojure -- “This title will
>>> be available on or about 2018-08-10.”
>>>
>>>
>>>
>>> I’m a bit surprised it wasn’t available under their Beta program…
>>>
>>>
>>>
>>> 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
>>> William Swaney 
>>> *Sent:* Saturday, January 13, 2018 4:53:00 PM
>>> *To:* Clojure
>>> *Subject:* Re: Russ olsen's Clojure Book
>>>
>>> Any idea when it'll be published? I don't see it at Pragmatic's site
>>> yet, nor at Amazon.
>>>
>>> Bill
>>>
>>> On Wednesday, June 29, 2011 at 8:09:56 PM UTC-7, Sayth Renshaw wrote:


 Just wanted to put a shout out to Russ Olsen to see what would be
 needed to get a Russ Olsen book on clojure to happen. I am reading
 design principles in Ruby and its a great read, I feel I am learning
 much moe than just Ruby which is why I am reading it.

 I woould absolutely love to read how Russ would apply these design
 principles to Clojure a more functional language. His books are all 5
 star reads(amazon ratings) and would greatly enjoy being able to read
 a Russ Olsen clojure book.

 Is there any way we could help this to happen? Is anyone else
 interested in such a book?

 Sayth
>>>
>>> --
>>> 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: [ANN] Datomic Cloud

[Alan Thompson]

Cool.

On Wed, Jan 17, 2018 at 6:25 AM, Jeroen van Dijk  wrote:

> Congrats!
>
> On Wed, Jan 17, 2018 at 3:06 PM, Stuart Halloway <
> stuart.hallo...@gmail.com> wrote:
>
>> Datomic Cloud is now available! http://blog.datomic
>> .com/2018/01/datomic-cloud.html
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Alan Thompson]

Hey - I love the idea.  However, I'm getting an error message trying to run
the example:

~/work/fred > cat deps.edn
{:deps
 {github-clj-time/clj-time
  {:git/url "https://github.com/clj-time/clj-time; :rev "cce58248"}}
}


~/work/fred > clj
Error building classpath. Manifest type :lein not loaded when finding deps
for github-clj-time/clj-time in coordinate {:git/url "
https://github.com/clj-time/clj-time;, :rev
"cce58248937bc05452ebfc8b65134961227a554e", *:deps/manifest :lein*,
:deps/root
"/home/alan/.gitlibs/libs/github-clj-time/clj-time/cce58248937bc05452ebfc8b65134961227a554e"}


​Any pointers on where I'm going wrong?
Alan


On Sun, Jan 7, 2018 at 1:43 PM, Nathan Fisher 
wrote:

> Im probably not typical for this but I really value the ability to
> override the location of where they’re placed. I actually commit my deps to
> SCM for production code. The internet is fast enough these days that i
> don’t care about a common code cache. I’m more interested in a reproducible
> build.
>
> On Sat, 6 Jan 2018 at 11:25, Alex Miller  wrote:
>
>>
>>
>> > On Jan 6, 2018, at 5:43 AM, Khalid Jebbari 
>> wrote:
>> >
>> > Great news, great work ! Soon running Clojure will be dead easy.
>> >
>> > 2 questions :
>> > - where do dependencies get downloaded ? `~/.m2` ? It depends on the
>> procurer (mvn/git/etc.)
>>
>> It depends. Maven deps go to .m2, git deps go to .gitlibs.
>>
>> > - does it work for Cljs ? What does it mean for Cljs ?
>>
>> This is targeted at launching Clojure programs. ClojureScript itself is a
>> Clojure program, so it’s relevant in that sense.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> - sent from my mobile
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Advice on Shell Scripting with new "clojure" binary

[Alan Thompson]

Cool!  I had somehow missed that in the announcement.  Quick test on linux:

 > echo '(println "Yes!!!")' | time clojure
Clojure 1.9.0
user=> Yes!!!
nil
user=>
clojure  1.38s user   0.07s system   198% cpu   *0.730 total*


Well under a second, even with a full-power JVM to load.  Very convenient!

Alan

On Thu, Jan 4, 2018 at 6:14 PM, Sean Corfield  wrote:

> The `clojure` command just loads your script – it doesn’t call -main – if
> you had
>
>
>
>   ;; test.clj
>
>   (println “Loaded!”)
>
>
>
> And you ran `clojure test.clj` then it would print Loaded!
>
>
>
> So you could do:
>
>
>
>   #!/usr/bin/env clojure
>
>   (println (str “Hello, “ (first *command-line-args*)))
>
>
>
> (the clojure.main/main function binds the command line arguments to that
> var)
>
>
>
> This works on OS X – I haven’t tried it on Linux.
>
>
>
> 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
> Delon Newman 
> *Sent:* Thursday, January 4, 2018 3:26:43 PM
> *To:* Clojure
> *Subject:* Advice on Shell Scripting with new "clojure" binary
>
> How do I get command line arguments in a Clojure shell script using the
> new "clojure" binary?
>
> So for a file like:
>
>
> # file-name: hello
> #!/usr/bin/env clojure
>
> (defn -main [name]
>(println (str "Hello, " name)))
>
> and execute it like:
>
> ./hello John
>
> the "-main" function is not executed. Is there another method?
>
> Also, any additional advice with respect to using Clojure for shell
> scripting would be appreciated.
>
> 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.
>

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

[Alan Thompson]

I just noticed that Python will give you hints (but only after guessing
wrong):

~ > python
Python 2.7.12 (default, Nov 20 2017, 18:23:56)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>>





On Sat, Dec 9, 2017 at 8:29 PM, Alan Thompson <clooj...@gmail.com> wrote:

> Would a message such as "use CRTL-D to exit" be appropriate?  Right now it
> is very bare.  Maybe this?
>
> ~ > clj
> Clojure 1.9.0 (use ^D to exit)
> user=>
> ~ >
>
> Alan
>
> On Sat, Dec 9, 2017 at 5:15 PM, Sean Corfield <s...@corfield.org> wrote:
>
>> I find the fact that "exit" and "quit" work in leiningen repls to be weird
>>
>>
>>
>> I agree. I’ve always used ctl-d to exit a Leiningen REPL or a Boot REPL –
>> or pretty much any console program I’ve ever used. I’m only surprised when
>> ctl-d _*doesn’t*_ work in such a program!
>>
>>
>>
>> And, after all, both Leiningen and Boot give ctl-d as the first option
>> for exiting a REPL:
>>
>>
>>
>> Exit: Control+D …
>>
>>
>>
>> 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 <clojure@googlegroups.com> on behalf of
>> Justin Smith <noisesm...@gmail.com>
>> *Sent:* Saturday, December 9, 2017 2:55:17 PM
>> *To:* clojure@googlegroups.com
>> *Subject:* Re: Terminating 'clj' REPL session
>>
>> I find the fact that "exit" and "quit" work in leiningen repls to be
>> weird - this doesn't follow the otherwise consistent rules of the language.
>> What about an exit function, something like
>>
>> (defn exit
>>   ([] (exit 0))
>>   ([n] (System/exit n))
>>
>> so that it's not an out of band special case input?
>>
>> On Sat, Dec 9, 2017 at 2:38 PM Alan Thompson <clooj...@gmail.com> wrote:
>>
>>> Hi - Just downloaded the new Clojure 1.9.0 package.  When I tried the
>>> repl I noticed that it doesn't respond to either `exit` or `quit` as one
>>> might expect from the lein repl:
>>>
>>> ~/cool/tools > clj
>>> Clojure 1.9.0
>>> user=> (+ 2 3)
>>> 5
>>> user=> exit
>>> CompilerException java.lang.RuntimeException: Unable to resolve symbol:
>>> exit in this context, compiling:(NO_SOURCE_PATH:0:0)
>>> user=>
>>> user=> quit
>>> CompilerException java.lang.RuntimeException: Unable to resolve symbol:
>>> quit in this context, compiling:(NO_SOURCE_PATH:0:0)
>>> user=> ^D
>>> ~/cool/tools >
>>>
>>>
>>> Lein repl for comparison:
>>>
>>> ~/tupelo > lein repl
>>> nREPL server started on port 37115 on host 127.0.0.1 - Clojure 1.9.0
>>> tupelo.core=> exit
>>> Bye for now!
>>>
>>> ~/tupelo >
>>>
>>> ~/tupelo > lein repl
>>> nREPL server started on port 40639 on host 127.0.0.1 - Clojure 1.9.0
>>> tupelo.core=> quit
>>> Bye for now!
>>> ~/tupelo >
>>>
>>>
>>> The new repl does terminate upon CRTL-D or CRTL-C, but many users will
>>> probably be confused that `quit` and `exit` are not accepted.
>>>
>>> Should I file a JIRA?
>>>
>>> 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.
>>>
>

Re: Terminating 'clj' REPL session

[Alan Thompson]

Would a message such as "use CRTL-D to exit" be appropriate?  Right now it
is very bare.  Maybe this?

~ > clj
Clojure 1.9.0 (use ^D to exit)
user=>
~ >

Alan

On Sat, Dec 9, 2017 at 5:15 PM, Sean Corfield <s...@corfield.org> wrote:

> I find the fact that "exit" and "quit" work in leiningen repls to be weird
>
>
>
> I agree. I’ve always used ctl-d to exit a Leiningen REPL or a Boot REPL –
> or pretty much any console program I’ve ever used. I’m only surprised when
> ctl-d _*doesn’t*_ work in such a program!
>
>
>
> And, after all, both Leiningen and Boot give ctl-d as the first option for
> exiting a REPL:
>
>
>
> Exit: Control+D …
>
>
>
> 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 <clojure@googlegroups.com> on behalf of
> Justin Smith <noisesm...@gmail.com>
> *Sent:* Saturday, December 9, 2017 2:55:17 PM
> *To:* clojure@googlegroups.com
> *Subject:* Re: Terminating 'clj' REPL session
>
> I find the fact that "exit" and "quit" work in leiningen repls to be weird
> - this doesn't follow the otherwise consistent rules of the language. What
> about an exit function, something like
>
> (defn exit
>   ([] (exit 0))
>   ([n] (System/exit n))
>
> so that it's not an out of band special case input?
>
> On Sat, Dec 9, 2017 at 2:38 PM Alan Thompson <clooj...@gmail.com> wrote:
>
>> Hi - Just downloaded the new Clojure 1.9.0 package.  When I tried the
>> repl I noticed that it doesn't respond to either `exit` or `quit` as one
>> might expect from the lein repl:
>>
>> ~/cool/tools > clj
>> Clojure 1.9.0
>> user=> (+ 2 3)
>> 5
>> user=> exit
>> CompilerException java.lang.RuntimeException: Unable to resolve symbol:
>> exit in this context, compiling:(NO_SOURCE_PATH:0:0)
>> user=>
>> user=> quit
>> CompilerException java.lang.RuntimeException: Unable to resolve symbol:
>> quit in this context, compiling:(NO_SOURCE_PATH:0:0)
>> user=> ^D
>> ~/cool/tools >
>>
>>
>> Lein repl for comparison:
>>
>> ~/tupelo > lein repl
>> nREPL server started on port 37115 on host 127.0.0.1 - Clojure 1.9.0
>> tupelo.core=> exit
>> Bye for now!
>>
>> ~/tupelo >
>>
>> ~/tupelo > lein repl
>> nREPL server started on port 40639 on host 127.0.0.1 - Clojure 1.9.0
>> tupelo.core=> quit
>> Bye for now!
>> ~/tupelo >
>>
>>
>> The new repl does terminate upon CRTL-D or CRTL-C, but many users will
>> probably be confused that `quit` and `exit` are not accepted.
>>
>> Should I file a JIRA?
>>
>> 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.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note tha

OutOfMemoryError when using Plumatic Schema and infinite lazy lists

[Alan Thompson]

I am a huge fan of Plumatic Schema, and it regularly helps me to find
mistakes in my code early in the development process.  However, I just
tracked down a very unexpected error when using a lazy infinite list such
as that produced by  `(range)`

Suppose you define two simple functions like `clojure.core/first`.  One
doesn't use Schema and the other does:

  (defn show-1
[arg]
(nth arg 0))

  (s/defn show-2 :- s/Any
[arg :- [s/Any] ]
(nth arg 0))

  (nl) (println "show-1")
  (spyx (mapv show-1 [ [:a :b :c] (range) ]))

  (nl) (println "show-2")
  (spyx (mapv show-2 [ [:a :b :c] (range) ]))


The results of running this code are:

show-1
(mapv show-1 [[:a :b :c] (range)]) => [:a 0]

show-2

ERROR in (dotest-line-472) (Iterate.java:54)
Uncaught exception, not in assertion.
expected: nil
  actual: *java.lang.OutOfMemoryError*: Java heap space
 at clojure.lang.Iterate.next (Iterate.java:54)
clojure.lang.RT.next (RT.java:706)
...


Apparently, turning on Schema validations causes the input collection to be
realized for `show-2` function call.

I am generally not a big fan of (infinite) lazy seq's and don't use them
much. However, this one came up during a simple unit test and really had me
scratching the old noggin for quite a while.

I'm not sure if there is an easy way of enhancing Schema to avoid this
problem, or if it is just something one needs to be wary of.

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.

Terminating 'clj' REPL session

[Alan Thompson]

Hi - Just downloaded the new Clojure 1.9.0 package.  When I tried the repl
I noticed that it doesn't respond to either `exit` or `quit` as one might
expect from the lein repl:

~/cool/tools > clj
Clojure 1.9.0
user=> (+ 2 3)
5
user=> exit
CompilerException java.lang.RuntimeException: Unable to resolve symbol:
exit in this context, compiling:(NO_SOURCE_PATH:0:0)
user=>
user=> quit
CompilerException java.lang.RuntimeException: Unable to resolve symbol:
quit in this context, compiling:(NO_SOURCE_PATH:0:0)
user=> ^D
~/cool/tools >


Lein repl for comparison:

~/tupelo > lein repl
nREPL server started on port 37115 on host 127.0.0.1 - Clojure 1.9.0
tupelo.core=> exit
Bye for now!

~/tupelo >

~/tupelo > lein repl
nREPL server started on port 40639 on host 127.0.0.1 - Clojure 1.9.0
tupelo.core=> quit
Bye for now!
~/tupelo >


The new repl does terminate upon CRTL-D or CRTL-C, but many users will
probably be confused that `quit` and `exit` are not accepted.

Should I file a JIRA?

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.

Re: Lazy Flatten; One seq at a Time

[Alan Thompson]

You can also solve this using `lazy-gen` and `yield-all` from the Tupelo
library
.
It allows you to make
a lazy generator function (a la Python):

  (let [seq-of-seqs [(range  0  5)
 (range 10 15)
 (range 20 25)]
flat-seq(lazy-gen
  (doseq [curr-seq seq-of-seqs]
(yield-all curr-seq)))]
(is= flat-seq [0 1 2 3 4 10 11 12 13 14 20 21 22 23 24]))


Alan


On Tue, Nov 21, 2017 at 4:47 PM, Jason Wolfe  wrote:

> I think this
> 
> will do it:
>
> (lazy-cat (first coll) (when-let [n (next coll)] (lazy-flatten n
>
>
> On Tuesday, November 21, 2017 at 2:34:15 PM UTC-8, Matt Anderson wrote:
>>
>> I have a function that is returning a lazy-seq of lazy-seq's.
>>
>>
>> (seq (seq [1 2 3]) (seq [4 5 6]) ...)
>>
>>
>> The end-user API, however, should be able to get back a lazy-seq of the
>> individual items across all lazy-seq's--essentially a flattening of the
>> output of my function--instead of the "top level" seqs.
>>
>>
>> (seq [1 2 3 4 5 6 ...])
>>
>> Each of the internal lazy-seq's is expensive in terms of memory usage so
>> I'd like to only "load" one at a time.  I've been trying to find a way to
>> only calculate one of the top-level lazy-seq's at a time and then not
>> "take" the next until the user gets to the end of the first and needs the
>> first item from the next (eg: (seq [4 5 6]) doesn't get calculated until we
>> have consumed 3 and are asking for the next), but haven't found a way to do
>> it. Best I've gotten is "loading" 2 "top level" seqs at a time and I'm
>> afraid that may be the best I get, but I thought it might be an exercise
>> worth presenting in case anyone had ideas. Here's a contrived example:
>>
>>
>> (defn lazy-flatten
>>
>>  [coll]
>>
>>  (when-let [s (seq coll)]
>>
>>(lazy-seq
>>
>>  (if (seq? (first s))
>>
>>(concat (lazy-flatten (first s)) (lazy-flatten (rest s)))
>>
>>(cons (first s) (lazy-flatten (rest s)))
>>
>> (->> (repeatedly
>>(fn []
>>  (println "New seq...")
>>  (map (fn [x] + x (rand-int 10)) (range 4
>>  lazy-flatten
>>  (take 1))
>>
>>
>>
>> Prints:
>>
>>
>> New seq...
>>
>> New seq...
>>
>> => (8)
>>
>>
>> I realize this is because 2 items must be taken for "concat", so there
>> would need to be another approach (this was just my best shot
>> implementation).
>>
>>
>> Any ideas on how to get the bottom form to only print 1 "New 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: [ANN] data.xml 0.2.0-alpha5

[Alan Thompson]

I seem to still be getting the JDK 1.9 reflection warning:


~/tupelo > grep data.xml project.clj
[org.clojure/data.xml "0.2.0-alpha5"]

> lein test
lein test tst.tupelo._bootstrap

-
   Clojure 1.9.0-RC1Java 9.0.1
-

lein test tst.tupelo.array

lein test tst.tupelo.async

lein test tst.tupelo.dev

lein test tst.tupelo.forest

lein test tst.tupelo.forest-examples
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by clojure.lang.Reflector
(file:/home/alan/.m2/repository/org/clojure/clojure/1.9.0-RC1/clojure-1.9.0-RC1.jar)
to method
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(org.xml.sax.InputSource,org.xml.sax.helpers.DefaultHandler)
WARNING: Please consider reporting this to the maintainers of
clojure.lang.Reflector
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





On Mon, Nov 13, 2017 at 3:47 PM, Herwig Hochleitner 
wrote:

> data.xml is a Clojure contrib library that parses and emits XML.
>
> Github: https://github.com/clojure/data.xml
> Changelog: https://github.com/clojure/data.xml/blob/master/CHANGES.md
>
> Information on updating the dependency is here
> .
>
> 0.2.0-alpha5 fixes a bug with emitting attributes in the builtin `xml:`
> namespace. In the process, there was a lot of clean-up work, removing
> various partial implementations of the recently introduced pu-map.
>
> Michael Blume got rid of reflection warnings. This should also remove the
> "illegal reflection" warning (CLJ-2066) on jdk >= 1.9
>
> Thanks to @MichaelBlume and all data.xml contributors!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Alan Thompson]

Looking at the source code here
<https://github.com/ztellman/potemkin/blob/master/src/potemkin/namespaces.clj>
I
can see that `import-vars` delegates to `import-fn` or `import-macro`,
which in turn calls `link-vars`. That uses `add-watch` with a function
described by the docstring:  "Makes sure that all changes to `src` are
reflected in `dst`."

​I haven't seen any problems in using it for a year or so, but the
implementation is not the same as I expected.  Hmmm.

Alan​


On Tue, Nov 7, 2017 at 12:08 PM, Alan Thompson <clooj...@gmail.com> wrote:

> In the Tupelo library, I have been using `import-fn` and `import-macro`
> from Potemkin so that I can define functions/macros in a single namespace
> `tupelo.impl`, but then expose an API in "user-visible" namespaces like:
>
>- tupelo.core
>- tupelo.char
>- tupelo.test
>- etc
>
> Perhaps I've been doing it wrong and should switch to `import-vars`.?
> Alan
>
>
> On Tue, Nov 7, 2017 at 10:13 AM, Nick Mudge <n...@perfectabstractions.com>
> wrote:
>
>> I am interested to know if people/you use import-vars to decouple the
>> structure of code from its API.
>>
>> import-vars is from the potemkin library: https://github.com/ztellman/po
>> temkin
>>
>> If you don't use import-vars how do you structure your code and provide
>> an API?
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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: Who Uses import-vars?

[Alan Thompson]

In the Tupelo library, I have been using `import-fn` and `import-macro`
from Potemkin so that I can define functions/macros in a single namespace
`tupelo.impl`, but then expose an API in "user-visible" namespaces like:

   - tupelo.core
   - tupelo.char
   - tupelo.test
   - etc

Perhaps I've been doing it wrong and should switch to `import-vars`.?
Alan


On Tue, Nov 7, 2017 at 10:13 AM, Nick Mudge 
wrote:

> I am interested to know if people/you use import-vars to decouple the
> structure of code from its API.
>
> import-vars is from the potemkin library: https://github.com/ztellman/
> potemkin
>
> If you don't use import-vars how do you structure your code and provide an
> API?
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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

[Alan Thompson]

Just upgraded from 0.0.8 to


[org.clojure/data.x
​​
ml "0.2.0-alpha3"]
​


 and am still getting the same error.  The offending statement is

(clojure.data.xml/parse)


where the BIS is the result of

(clojure.java.io/input-stream
  (clojure.java.io/resource ))

​
​Alan


On Fri, Nov 3, 2017 at 1:36 PM, Alan Thompson <clooj...@gmail.com> wrote:

> OK, I upgraded lein to 2.8.1, and it removed one of the error messages.
> I still have one remaining:
>
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by clojure.lang.Reflector
> (file:/home/alan/.m2/repository/org/clojure/clojure/1.9.0-beta4/clojure-1.9.0-beta4.jar)
> to method com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.
> parse(org.xml.sax.InputSource,org.xml.sax.helpers.DefaultHandler)
> WARNING: Please consider reporting this to the maintainers of
> clojure.lang.Reflector
> 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
>
>
> It seems to claim that  clojure.lang.Reflector  is a problem   Trying
> to narrow it down.
> Alan
>
>
> On Thu, Nov 2, 2017 at 1:11 PM, Peter Hull <peterhul...@gmail.com> wrote:
>
>> On Thursday, 2 November 2017 19:46:35 UTC, Alex Miller wrote:
>>>
>>> I think this is an issue with Leiningen with Java 1.9 (re things in
>>> dynapath and the changes in classloader details in Java 1.9), and not
>>> Clojure itself.
>>>
>>> Yes this was leiningen issue #2331 now fixed:
>> https://github.com/technomancy/leiningen/issues/2331
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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

[Alan Thompson]

OK, I upgraded lein to 2.8.1, and it removed one of the error messages.   I
still have one remaining:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by clojure.lang.Reflector
(file:/home/alan/.m2/repository/org/clojure/clojure/1.9.0-beta4/clojure-1.9.0-beta4.jar)
to method
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(org.xml.sax.InputSource,org.xml.sax.helpers.DefaultHandler)
WARNING: Please consider reporting this to the maintainers of
clojure.lang.Reflector
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


It seems to claim that  clojure.lang.Reflector  is a problem   Trying
to narrow it down.
Alan


On Thu, Nov 2, 2017 at 1:11 PM, Peter Hull  wrote:

> On Thursday, 2 November 2017 19:46:35 UTC, Alex Miller wrote:
>>
>> I think this is an issue with Leiningen with Java 1.9 (re things in
>> dynapath and the changes in classloader details in Java 1.9), and not
>> Clojure itself.
>>
>> Yes this was leiningen issue #2331 now fixed:
> https://github.com/technomancy/leiningen/issues/2331
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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

[Alan Thompson]

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

Nice screencast overview of Specter

[Alan Thompson]

I just saw this on YouTube and thought you may enjoy it:
https://youtu.be/rh5J4vacG98

While there is lots of written documentation on Specter, the live-coding
and narration of what one is seeing provides some nice examples.

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

Re: Help ship Clojure 1.9!

[Alan Thompson]

Before Clojure 1.9 is shipped, I would like to reiterate the appeal from
many in the community to stop the terrible, permanent mistake that is
*clojure.core/any?*

For those who have not seen past emails on this topic, you may view the
main threads here:

   -
   
https://groups.google.com/forum/#!searchin/clojure/semantic$20mismatch$20any%7Csort:relevance/clojure/f25y6N1OiIo/5Gq70PV1CAAJ
   -
   
https://groups.google.com/forum/#!searchin/clojure/any$20not-any$20mismatch%7Csort:relevance/clojure/2l2f1jKExUc/aX4KpqlABAAJ
   -
   
https://groups.google.com/forum/#!searchin/clojure/any$20not-any$20mismatch%7Csort:relevance/clojure/tPiW2DGHTN0/A4LyknV4BAAJ

Alan


On Wed, Oct 4, 2017 at 1:27 PM, Michał Marczyk 
wrote:

> I've run into a behaviour change that was actually already present in
> alpha20 – with the CLJ-99 patch in place, {min,max}-key now return the
> first argument with the minimum/maximum key, whereas previously they
> returned the last such argument.
>
> The new behaviour seems like the more natural one, but this is a breaking
> change, so I filed https://dev.clojure.org/jira/browse/CLJ-2247 to track
> this (with a patch that takes the "default" approach of restoring
> established behaviour).
>
> Cheers,
> Michał
>
>
> On 3 October 2017 at 21:11, Beau Fabry  wrote:
>
>> We've been using 1.9 in a small app for a while with no issues. After
>> upgrading schema to the latest version (with the PR above) I've also
>> successfully run our larger codebase with 1.9.
>>
>> On Tuesday, October 3, 2017 at 4:41:14 AM UTC-7, stuart@gmail.com
>> wrote:
>>>
>>> Hi Mark,
>>>
>>> I think this approach totally makes sense, and the alpha naming exists
>>> to inform this kind of decision-making.
>>>
>>> For libraries where the use of spec does not have to be user-facing, I
>>> am putting specs in separate (Clojure) namespaces, and loading them in such
>>> a way that they can coexist with non (or maybe different) spec
>>> environments. But that is extra work for sure.
>>>
>>> Stu
>>>
>>> On Mon, Oct 2, 2017 at 3:35 PM, Mark Engelberg 
>>> wrote:
>>>
 On Mon, Oct 2, 2017 at 7:55 AM, Stuart Halloway 
 wrote:

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

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

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

 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to 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 

Re: any? in clojure 1.9.0 alpha

[Alan Thompson]

Before 1.9.0 is officially released, I would like to propose a revisit to
the semantic mismatch introduced by the *clojure.core/any? *function.

Many, many people are dissatisfied by the choice of *clojure.core/any?* to
be defined as *(constantly true)*, which is completely in conflict with
*clojure.core/not-any?* .After all, any logical person would
automatically assume that:

(= (not-any? args...) (not (any? args...))


for any set of legal arguments.  This follows the well-established
tradition in Clojure of having negated pairs such as* if* vs *if-not*,
*when *vs *when-not*, *every? *vs* not-every?*, etc.

However, I can see that it is convenient to say something like this:

(s/fdef clojure.core/declare
:args (s/cat :names (s/* simple-symbol?))
:ret any?)


It seems a simple solution to the problem would be to just define some
keyword specs in place of the globally visible *any? *function.  The
following example shows that we could define *:clojure.spec/pass-all *and
*:clojure.spec/pass-none* which would could serve as an exact replacement
for *any? *(& its negative).

(:require [clojure.spec.alpha :as s] ...)
(deftest demo
  (s/def ::s/pass-all  (constantly true))
  (s/def ::s/pass-none (constantly false))

  (is  (s/valid? ::s/pass-all 5 ))
  (is  (s/valid? ::s/pass-all "joe" ))
  (is  (s/valid? ::s/pass-all { :blah 42 :blue 66 :hut! 'hut! }))
  (is (not (s/valid? ::s/pass-none 5 


Since 1.9.0 is not out yet, is not too late to avoid a permanent pollution
of the language with a gigantic mistake such as *any?*.  At the very least,
the function could be moved to *clojure.spec/any?* from *clojure.core*.  If
we insist on adding this blatant contradiction to *clojure.core*, we won't
even have the excuse of a committee to blame it on.

Alan Thompson



On Sun, Nov 13, 2016 at 4:15 PM, Nathan Smutz <nsm...@gmail.com
<https://mail.google.com/mail/?view=cm=1=1=nsm...@gmail.com>>
wrote:

> Is there a Tricky Names for Nubies page?
> We might save some stack-overflow searches.
>
> In the spirit of Honest Trailers: if we named functions for what they do:
> or-> first-truthy
> some  -> first-satisfying
> some? -> not-nil?
> any?  -> return-true
>
> Are there others?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> <https://mail.google.com/mail/?view=cm=1=1=clojure@googlegroups.com>
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> <https://mail.google.com/mail/?view=cm=1=1=clojure%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> <https://mail.google.com/mail/?view=cm=1=1=clojure%2bunsubscr...@googlegroups.com>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [core.spec] Stricter map validations?

[Alan Thompson]

While it doesn't use spec, you can do this using the validate-map-keys
helper function in the Tupelo library .
It verify that a map does not contain any keys other than those you
specify.  The unit test shows it in action:

(ns tst.demo.core
  (:use demo.core tupelo.test )
  (:require
[tupelo.core :as t] ))
(t/refer-tupelo)

(dotest
  (let [map-ab   {:a 1 :b 2}
map-abc  {:a 1 :b 2 :c 3}]
(is= map-ab  (validate-map-keys map-ab [:a :b]))
(is= map-ab  (validate-map-keys map-ab [:a :b :x]))
(is= map-ab  (validate-map-keys map-ab #{:a :b}))
(is= map-ab  (validate-map-keys map-ab #{:a :b :x}))
(is= map-abc (validate-map-keys map-abc [:a :b :c :x]))

(is (thrown? IllegalArgumentException (validate-map-keys map-ab [:a])))
(is (thrown? IllegalArgumentException (validate-map-keys map-ab [:b])))
(is (thrown? IllegalArgumentException (validate-map-keys map-ab [:a
:x])))
(is (thrown? IllegalArgumentException (validate-map-keys map-abc [:a
:b])))
(is (thrown? IllegalArgumentException (validate-map-keys map-abc [:a :c
:x])


The API docs are hosted on Github Pages, but it seems to be down at the
moment.  You can find some older API docs (May 2017) on CrossClj:
https://crossclj.info/doc/tupelo/0.9.1/index.html

Alan





On Tue, Oct 3, 2017 at 2:37 PM, Didier  wrote:

> I'm loving Spec as an FYI, and I'll use it even if it stays as is, even in
> its alpha state it is a great tool. I also highly value the Clojure core
> value to avoid breakage, as the cost to enterprise of every migration is
> very high.
>
> I'm just wanting to give more data points to the Core team that I hope
> would be taken into consideration in the decisions of where to put the line
> on what Spec provides and doesn't.
>
> In my case, Spec has already not gone where my code base has. I'm sure
> there's use cases out there where a closed map spec would have been
> problematic, so I'm glad spec has an open map spec, but I've never had this
> problem, and I've failed to see anyone describe it to me where I felt the
> problem was real. What I do know is that I've experienced the problem of an
> open map spec that others have clearly described in this thread. When I
> need to validate for security that no extra keys were added to my maps, and
> when I want to be sure, for correctness, that my instrumentation is not
> accidentally not asserting my input because of a missing key spec, or if I
> want to be reminded that I forgot to update the spec when I extended the
> map to have additional keys, then clojure.spec falls short.
>
> I wouldn't ask of this to be taken into account by the core spec team, if
> it was easy to extend Spec to support this, but from what I could tell from
> the source, it is non trivial for me to add my own strict s/keys, and it
> doesn't seem possible to easily extend s/keys itself with more features.
> Especially if I want all the features of s/keys, except with strict key
> spec validation.
>
> I trust the core team to have good judgement, as they've shown to have
> with much of Clojure till date, but I think this is valuable data points
> for them to discuss and decide what's best. This was also part of a real
> enterprise project, that took 4 months with 5 engineers to develop. We're
> using it in production, so this is not feedback out of a toy project, or
> just experimentation.
>
> Maybe there's a better way to solve this problem then a strict spec, maybe
> we need a strict s/validate?, or some other more powerful and flexible
> construct. And maybe there are easy to extend spec for my needs, then I'd
> love to learn about those.
>
> Anyways, for the purpose of gathering data points about this use case. It
> currently seems like Me, Yury, Leon, Puzzler, and Tommi have all faced this
> issue. I've fixed it by doing my own validation on top of spec. So I only
> use spec as a data description language, and not as a validation tool. I
> use s/describe to get the keys, and then I resolve the specs, and assert
> that no more keys are on the map then what I got from s/describe. The
> downside is that I can't use instrumentation, assert, validate?, etc. So
> its hard to guarantee that the spec is always validated as my data should.
> The spec data description language is not powerful enough to be able to
> model invariants such as a closed set of keys, or keys which must have
> associated specs, unless I implement that predicate spec myself, which I
> couldn't figure out how to do.
>
> Since spec is still alpha, I think this is a great time to bring up these
> issues.
>
>
> On Tuesday, 3 October 2017 13:29:40 UTC-7, Tommi Reiman wrote:
>>
>> Open Specs seem like a good idea.
>>
>> In real life, we need to close our Data at system borders.
>>
>> With Java, there is Jackson, which fails by default on extra keys. The
>> Schema, the models are closed by default. JSON Schemas can be closed.
>>
>> Saying "use normal clojure" on 

Re: Clojure rookie vs parsing

[Alan Thompson]

While Instaparse is (IMHO) the best parser for use with Clojure, you don't
have to start from such a low level (i.e. parsing a char stream text
file).  Just re-write your original problem a little and you can skip
writing a custom parser.

In Clojure, perhaps the most popular format (certainly the tersest format) is
Hiccup .  It is written as a series
of nested vectors, where the *tag* is the first item and any *attributes* are
in a map that is the 2nd item.  We choose the keyword *:value* to label
anything on the right of the equals sign in your original data.  You thus
end up with this:



(def ast-hiccup
  [:HeaderRule {:value :hr-ftp}
[:Term {:value 100}
  [:name {:value "ftp"}]
  [:From {:value 1}
[:networkPort {:value "21"}]
[:Protocol {:value 1}
  [:Tcp {:value 1}]]]
  [:Then {:value 1}
[:ProtocolInspection {:value 1}
  [:ftpRuleSet {:value "frs-ftp"}]]
[:ServiceDataFlowId {:value 1}
  [:payload {:value 99}] )

Using the tupelo.forest library
, we can easily
parse this tree of data and then issue queries on it:


(ns tst.demo.core
  (:use demo.core tupelo.test)
  (:require
[tupelo.core :as t]
[tupelo.forest :as tf] ))
(t/refer-tupelo)

(dotest
  (tf/with-forest(tf/new-forest)
(let [root-hid   (tf/add-tree-hiccup ast-hiccup)
  tree-1 (tf/hid->tree root-hid)
  bush-1 (tf/hid->bush root-hid)
  >> (spyx-pretty bush-1)   ; print the AST in "bush"
format (similar to hiccup)

  networkPort-hid (tf/find-hid root-hid [:** :From :networkPort])
  ; find the :networkPort node
  networkPort-value   (spyx (grab :value (tf/hid->node
networkPort-hid)))   ; extract the :value from it
]
  (is= bush-1
[{:value :hr-ftp, :tag :HeaderRule}
  [{:value 100, :tag :Term}
[{:value "ftp", :tag :name}]
[{:value 1, :tag :From}
  [{:value "21", :tag :networkPort}]
  [{:value 1, :tag :Protocol}
[{:value 1, :tag :Tcp}]]]
[{:value 1, :tag :Then}
  [{:value 1, :tag :ProtocolInspection}
[{:value "frs-ftp", :tag :ftpRuleSet}]]
  [{:value 1, :tag :ServiceDataFlowId}
[{:value 99, :tag :payload}] )

  (is= networkPort-value "21" ;  verify we found the value "21"

For more examples please see the forest-examples.cljc file

and the API docs .
More documentation forthcoming.

Enjoy!
Alan



On Tue, Aug 15, 2017 at 7:11 PM, dennis zhuang  wrote:

> In my experience, instaparse + defun is a good choice.
>
> https://github.com/Engelberg/instaparse
> https://github.com/killme2008/defun/
>
> 2017-08-15 22:02 GMT+08:00 Gary Trakhman :
>
>> I enjoyed working with clj-antlr recently, it's a wrapper over a java
>> library, but gives you a fast feedback loop with an interpreter instead of
>> generated java code.  The 'clojurey' part is that the output is a nested
>> sequence, from there it's really effective to use tree zippers and
>> core.match to transform the parse-tree into the data structure you need.
>>
>> Take a look at:
>> https://github.com/clojure/core.match
>> https://github.com/aphyr/clj-antlr
>> https://www.ibm.com/developerworks/library/j-treevisit/
>> https://github.com/akhudek/zip-visit
>>
>> On Tue, Aug 15, 2017 at 9:56 AM Laurens Van Houtven <_...@lvh.cc> wrote:
>>
>>> Hi,
>>>
>>>
>>> Instaparse is a great parser generator, especially if you already have a
>>> BNF.
>>>
>>> Sent from my iPhone
>>>
>>> On Aug 15, 2017, at 08:44, sventrax...@gmail.com wrote:
>>>
>>> Thanks for your input. LFE is quite an unexpected "thing".
>>>
>>> What I'm trying to do, is just a "lunch time project"; something that I
>>> can target without corporate constrains just as a learning exercise.
>>> Furthermore I can test the Clojure version against my old working Java
>>> version.
>>>
>>> As I was saying, while experimenting with Instaparse, I'm having the
>>> feeling it is not the correct Clojure tool for this type of development
>>>
>>>
>>>
>>> On Tuesday, August 15, 2017 at 2:17:50 PM UTC+1, adrians wrote:

 If you need the features of Erlang but would like that in a Lisp (not
 Common Lisp, though) environment, have you taken a look at LFE (Lisp
 Flavored Erlang)? I'm not trying to discourage you from looking at Clojure,
 but if you need/depend on some of the features of Erlang, LFE might be a
 closer fit.

 http://lfe.io

 On Tuesday, August 15, 2017 at 8:11:53 AM UTC-4, svent...@gmail.com
 wrote:
>
>
> Hi
>
> Months ago I read a review that praised Clojure's clean approach and
> 

Re: The Empire Strikes Back: Microsoft Visual Studio IDE Integration for F#

[Alan Thompson]

Link:
https://blogs.msdn.microsoft.com/dotnet/2017/05/31/why-you-should-use-f/


On Mon, Jun 5, 2017 at 9:23 AM, Alan Thompson <clooj...@gmail.com> wrote:

> Here is an interesting talk from MS Build 2017 conference, especially when
> compared to similar capabilities in Clojure/Cursive, etc.
>
> For the first time they can do code completion, IDE REPL integration, and
> simple refactorings (e.g. "Rename Variable").
>
> They also have an interactive data explorer called "Type Providers". It is
> like code completion but works in realtime for data (not code/libraries).
> He did a live demo exploring the Wikipedia "Doctor Who" page with the IDE
> providing "code completion" for accessing the webpage content. He said that
> this feature is not available in any other .Net language.
>
> This feature was implemented by the F# open source community (data
> scientists, etc). He also showed another feature "Jump to Definition"
> (CTRL-B in IDEA) was also implemented by the OSS users and is now merged
> into Visual Studio (also only available for F#).
>
> From a Clojure perspective you can see that they are still playing
> catch-up, but it looks like they have really committed to both functional
> programming and the corresponding tooling.
>
> 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.

Re: Adding debug traces to expressions

[Alan Thompson]

Hi - The Tupelo library has some nice "spy" debugging tools available
<https://github.com/cloojure/tupelo#expression-debugging>.  ​
Full docs are available on GitHub pages:
http://cloojure.github.io/doc/tupelo/index.html

My favorite one is `spyx` (short for "spy expression"). It is used like
this:

(it-> 1 ; tupelo.core/it->
  (spyx (inc it))
  (* 2 it)); (inc it) => 2 ; the expression is used as the label4


​A newer version (not in the README yet!) can turn any `let` expression
into a `spy` debugging tool.  In a code fragment like this:


  (let [module-hid (tf/add-tree-hiccup yang-ast-hiccup)
module-bush-before (tf/hid->bush module-hid)
>> (tx-module module-hid)
module-bush-after  (tf/hid->bush module-hid) ]



just replace `let` with `let-spy-pretty`


  (let-spy-pretty
   [module-hid (tf/add-tree-hiccup yang-ast-hiccup)
module-bush-before (tf/hid->bush module-hid)
>> (tx-module module-hid)
module-bush-after  (tf/hid->bush module-hid)
]

to get printed output like this:

module-hid =>
:5d77d6d3a49b09624ca8e8c9f9c975228a212d03

module-bush-before =>
[{:tag :module}
 [{:tag :identifier} "calculator"]
 [{:tag :namespace}
  [{:tag :string} "http://brocade.com/ns/calculator;]]
 [{:tag :contact}
  [{:tag :string} "Alan Thompson <atho...@brocade.com>"]]
 [{:tag :description}
  [{:tag :string} "YANG spec for a simple RPN calculator"]]
 [{:tag :revision}
  [{:tag :iso-date} "2017-04-01"]
  [{:tag :description} [{:tag :string} "Prototype 1.0"]]]
 [{:tag :rpc}
  [{:tag :identifier} "add"]
  [{:tag :description} [{:tag :string} "Add 2 numbers"]]
  [{:tag :input}
   [{:tag :leaf}
[{:tag :identifier} "x"]
[{:tag :type} [{:tag :identifier} "decimal64"]]]
   [{:tag :leaf}
[{:tag :identifier} "y"]
[{:tag :type} [{:tag :identifier} "decimal64"
  [{:tag :output}
   [{:tag :leaf}
[{:tag :identifier} "result"]
[{:tag :type} [{:tag :identifier} "decimal64"]]

>> =>
{:attrs {:tag :rpc, :name :add},
 :kids
 [:f0212a89632b49ac693979b01f40ba330a081288
  :6e6cf8dee634c80046510d8ab161d7e32ca60456]}

module-bush-after =>
[{:tag :module,
  :name :calculator,
  :namespace "http://brocade.com/ns/calculator;,
  :contact "Alan Thompson <atho...@brocade.com>",
  :description "YANG spec for a simple RPN calculator",
  :revision "2017-04-01"}
 [{:tag :rpc, :name :add}
  [{:tag :input}
   [{:type :decimal64, :name :x}]
   [{:type :decimal64, :name :y}]]
  [{:tag :output} [{:type :decimal64, :name :result}


Alan


On Sat, Jun 3, 2017 at 4:57 PM, Bill Piel <b...@billpiel.com> wrote:

> Hi lvh,
>
> Author of sayid here. Couple questions:
>
> - would you want the debug traces to be available only during development?
> Or does this need to run in production too?
> - what editor are you using? or does the solution need to be
> editor-agnostic?
>
> Also, FWIW, Sayid does have features that allow you get to at the raw
> captured data, not just the printed output. These two commands are
> available from the sayid buffer.
>
> > d -- def value to $s/*
> > g -- generate instance expression and put in kill ring
>
> https://www.youtube.com/watch?v=ipDhvd1NsmE#t=13m (13:00)
>
> Bill
>
> On Saturday, June 3, 2017 at 11:11:09 AM UTC-4, Laurens Van Houtven wrote:
>>
>> And, immediately after I sent this, I remembered clojure.tools.trace;
>> which also looks pretty similar :)
>>
>> On Sat, Jun 3, 2017 at 9:57 AM, lvh <_...@lvh.io> wrote:
>>
>>> Hi,
>>>
>>>
>>> I have a piece of code that takes a limited subset of Clojure as
>>> queries, e.g.:
>>>
>>> (not= (some gnarly expr) (some-other-gnarly-expr))
>>>
>>> It also produces the result, which is interesting when the query is just
>>> (some gnarly expr) and the result itself is interesting, but less
>>> interesting when the top level is  a =/not= call and the result is just
>>> "true" or "false". I would like to report intermediate values, because they
>>> tell you _why_ something failed.
>>>
>>> So far, I have a few ideas (thanks to clojure slack for adding a few):
>>>
>>> * coerce taoensso.timbre/spy, which roughly does what I want, into
>>> giving me results as data instead of capturing stdout; potentially just
>>> using with-out-str as a first pass. Problem: some of these expressions are
>>> quite meaty, and this doesn't gi

The Empire Strikes Back: Microsoft Visual Studio IDE Integration for F#

[Alan Thompson]

Here is an interesting talk from MS Build 2017 conference, especially when
compared to similar capabilities in Clojure/Cursive, etc.

For the first time they can do code completion, IDE REPL integration, and
simple refactorings (e.g. "Rename Variable").

They also have an interactive data explorer called "Type Providers". It is
like code completion but works in realtime for data (not code/libraries).
He did a live demo exploring the Wikipedia "Doctor Who" page with the IDE
providing "code completion" for accessing the webpage content. He said that
this feature is not available in any other .Net language.

This feature was implemented by the F# open source community (data
scientists, etc). He also showed another feature "Jump to Definition"
(CTRL-B in IDEA) was also implemented by the OSS users and is now merged
into Visual Studio (also only available for F#).

>From a Clojure perspective you can see that they are still playing
catch-up, but it looks like they have really committed to both functional
programming and the corresponding tooling.

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.

SymbolHound search engine

[Alan Thompson]

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.

Re: How to Create Clojure `defn` Functions automatically?

[Alan Thompson]

Yes, exactly. You can replicate what `def` and macros do using a regular
function and `intern`.

On Sat, May 13, 2017 at 4:04 PM, Timothy Baldridge <tbaldri...@gmail.com>
wrote:

> Okay, so I've read these SO articles about 4 times now, and I finally
> think I'm starting to understand what the `intern` solution is doing. I
> would recommend this then can we simply state that:
>
> `(def x 42)`
>
> is equal to
>
> `(intern 'x 42)`
>
> Except the first is a compiler special form (and hence requires a compiler
> and/or macro system) while the other is a function (and requires a
> namespace system). That will probably save people a ton of reading. Like I
> said, I program Clojure a lot, and it took me about 60 minutes of reading
> and thinking about this code before I finally figured out what the problem
> and the solution and the solution being presented.
>
>
> On Sat, May 13, 2017 at 4:49 PM, Alan Thompson <clooj...@gmail.com> wrote:
>
>> I was just trying to answer a question posed by someone else, so I can't
>> give details about the original motivation. I thought it was a good example
>> of the capabilities of `intern` that I hadn't seen before, which could be
>> useful in a dynamic case where one wanted to generate functions on the fly
>> w/o using macros.
>>
>> A previous answer the OP was referred to
>> <http://stackoverflow.com/questions/7852351/clojure-macro-to-generate-functions>
>> was incomplete for the new question and I was trying to fill in the missing
>> parts.
>>
>>
>>
>> On Sat, May 13, 2017 at 3:40 PM, Timothy Baldridge <tbaldri...@gmail.com>
>> wrote:
>>
>>> Sorry, but this use of intern is a pointless. What does intern give you
>>> that a let over a defn doesn't?
>>>
>>> On Sat, May 13, 2017 at 4:37 PM, Alan Thompson <clooj...@gmail.com>
>>> wrote:
>>>
>>>> If anyone is interested, I cleaned up the question to (hopefully) make
>>>> it clearer, as well as adding the macro-calling-a-macro solution.
>>>>
>>>> While some may consider it esoteric, I thought it was a good example of
>>>> the power `intern` can provide, as well as a good way to avoid macros and
>>>> stick to pure functions.
>>>>
>>>> Here is the re-worked version:  http://stackoverflow.com/ques
>>>> tions/43958471/how-to-create-clojure-defn-functions-automati
>>>> cally-without-macros/
>>>>
>>>> Alan
>>>>
>>>> On Thu, May 11, 2017 at 10:15 AM, Alan Thompson <clooj...@gmail.com>
>>>> wrote:
>>>>
>>>>> Actually someone else wrote the original CLJS question (1):
>>>>> http://stackoverflow.com/questions/43897632/mapped-calls-to
>>>>> -clojurescript-macro
>>>>>
>>>>> It was marked as a duplicate of this question (2):
>>>>> http://stackoverflow.com/questions/43897632/mapped-calls-to
>>>>> -clojurescript-macroThis one also had an answer using `intern` to
>>>>> avoid the need for a macro.
>>>>>
>>>>> I didn't think question (1) was an exact duplicate of (2), and I
>>>>> wanted to work out the details of solving (1) using `intern` instead of
>>>>> macros (it seemed like a good goal at the time...).  I tried to simplify
>>>>> question (1) w/o the CLJS callback stuff, and may have oversimplified.
>>>>>
>>>>> Since question was closed as being a "duplicate" (in error, I think),
>>>>> I couldn't answer there and posed the Q style answer separately at (3):
>>>>> http://stackoverflow.com/questions/43904628/how-to-create-c
>>>>> lojure-defn-functions-automatically
>>>>>
>>>>> The main goal I had here was simply finding a good way to avoid macros
>>>>> when auto-generating functions, and to generalize/document the technique
>>>>> described in (2) using `intern`.
>>>>>
>>>>> Alan
>>>>>
>>>>> P.S.  Regarding (3), Joel Spolsky, creator of StackOverflow, has often
>>>>> encouraged people to post both a question and its answer on the site:
>>>>> https://stackoverflow.blog/2011/07/01/its-ok-to-ask-and-ans
>>>>> wer-your-own-questions  In fact, they even have a special button
>>>>> for this purpose.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, May 11, 2017 at 9:39 AM, Timothy Baldridge <
>>>>> tbaldr

Re: How to Create Clojure `defn` Functions automatically?

[Alan Thompson]

I was just trying to answer a question posed by someone else, so I can't
give details about the original motivation. I thought it was a good example
of the capabilities of `intern` that I hadn't seen before, which could be
useful in a dynamic case where one wanted to generate functions on the fly
w/o using macros.

A previous answer the OP was referred to
<http://stackoverflow.com/questions/7852351/clojure-macro-to-generate-functions>
was incomplete for the new question and I was trying to fill in the missing
parts.



On Sat, May 13, 2017 at 3:40 PM, Timothy Baldridge <tbaldri...@gmail.com>
wrote:

> Sorry, but this use of intern is a pointless. What does intern give you
> that a let over a defn doesn't?
>
> On Sat, May 13, 2017 at 4:37 PM, Alan Thompson <clooj...@gmail.com> wrote:
>
>> If anyone is interested, I cleaned up the question to (hopefully) make it
>> clearer, as well as adding the macro-calling-a-macro solution.
>>
>> While some may consider it esoteric, I thought it was a good example of
>> the power `intern` can provide, as well as a good way to avoid macros and
>> stick to pure functions.
>>
>> Here is the re-worked version:  http://stackoverflow.com/ques
>> tions/43958471/how-to-create-clojure-defn-functions-automat
>> ically-without-macros/
>>
>> Alan
>>
>> On Thu, May 11, 2017 at 10:15 AM, Alan Thompson <clooj...@gmail.com>
>> wrote:
>>
>>> Actually someone else wrote the original CLJS question (1):
>>> http://stackoverflow.com/questions/43897632/mapped-calls-to
>>> -clojurescript-macro
>>>
>>> It was marked as a duplicate of this question (2):
>>> http://stackoverflow.com/questions/43897632/mapped-calls-to
>>> -clojurescript-macroThis one also had an answer using `intern` to
>>> avoid the need for a macro.
>>>
>>> I didn't think question (1) was an exact duplicate of (2), and I wanted
>>> to work out the details of solving (1) using `intern` instead of macros (it
>>> seemed like a good goal at the time...).  I tried to simplify question (1)
>>> w/o the CLJS callback stuff, and may have oversimplified.
>>>
>>> Since question was closed as being a "duplicate" (in error, I think), I
>>> couldn't answer there and posed the Q style answer separately at (3):
>>> http://stackoverflow.com/questions/43904628/how-to-create-c
>>> lojure-defn-functions-automatically
>>>
>>> The main goal I had here was simply finding a good way to avoid macros
>>> when auto-generating functions, and to generalize/document the technique
>>> described in (2) using `intern`.
>>>
>>> Alan
>>>
>>> P.S.  Regarding (3), Joel Spolsky, creator of StackOverflow, has often
>>> encouraged people to post both a question and its answer on the site:
>>> https://stackoverflow.blog/2011/07/01/its-ok-to-ask-and-ans
>>> wer-your-own-questions  In fact, they even have a special button
>>> for this purpose.
>>>
>>>
>>>
>>> On Thu, May 11, 2017 at 9:39 AM, Timothy Baldridge <tbaldri...@gmail.com
>>> > wrote:
>>>
>>>> I assume this is a real problem you are encountering since you wrote
>>>> the original Stack Overflow questions. As Dragan mentioned, this example
>>>> doesn't warrant such a complex solution, maps and keywords *are* function,
>>>> so all you really need is `foo` as a getter. Or even if they weren't
>>>> functions you still have `(partial get foo)`.
>>>>
>>>> On Thu, May 11, 2017 at 10:27 AM, Alan Thompson <clooj...@gmail.com>
>>>> wrote:
>>>>
>>>>> Since the original question was in CLJS, which has neither `intern`
>>>>> nor `eval`, does that mean the macro mapping another macro approach is the
>>>>> only solution there?
>>>>>
>>>>>
>>>>> On Thu, May 11, 2017 at 9:18 AM, Alan Thompson <clooj...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I like the idea of using `eval` and  `memoize`.  I'll have to keep
>>>>>> that in mind.
>>>>>> Alan
>>>>>>
>>>>>> On Thu, May 11, 2017 at 7:58 AM, Timothy Baldridge <
>>>>>> tbaldri...@gmail.com> wrote:
>>>>>>
>>>>>>> This is a somewhat weird answer to a overcomplicated problem. As
>>>>>>> mentioned, the data is a map to start with, and maps are functions so
>>>>>>> treating the maps a

Re: Functional Pattern to Replace Temp Var

[Alan Thompson]

You are already doing exactly the right thing by having a temporary
variable.

To be precise a code fragment like:


(let [expensive-answer (some-fn x y z)
  final-result { :k1 (f1 expensive-answer)
 :k2 (f2 expensive-answer)
 :k3 (f3 expensive-answer) } ]
  final-result)


is already purely functional and very appropriate.  In fact, there is even
a name for a closely-related technique:
https://refactoring.com/catalog/extractVariable.html

Alan


On Sat, May 13, 2017 at 1:26 PM, Kevin Kleinfelter <
kleinfelter.gro...@gmail.com> wrote:

> How would one convert the following procedural logic into
> functional/Clojure?
> x = expensive-calculation
> return (f1(x), f2(x), f3(x))
>
> I'm sure I could force it by using a var to save the intermediate value,
> but that's still procedural.  It seems like the pattern of reusing an
> expensive result in multiple function calls without recalculating it must
> have a functional approach, but I'm not finding it.
>
> What I really want to do is to return:
> {:key1 f1(f0(x)), :key2 f2(f0(x)), :key3 f3(f0(x))}
>
> without paying the price of executing f0 multiple times.
>
> Tnx.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.