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

2021-10-25 Thread 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?

2021-09-15 Thread 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)

2021-09-15 Thread 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.


Re: [ANN] Discontinuing 4clojure.com

2021-07-14 Thread Alan Malloy
There have been a number of requests on this thread for me to transfer the 
4clojure.com domain name to a designated successor. I'm open to that in 
principle, but there are a couple issues.

   1. I don't actually own the 4clojure.com domain name. That belongs to 
   4clojure's founder, dbyrne, who has been renewing it and pointing it at my 
   server. I imagine he will be happy to transfer it, but there might be 
   organizational hiccups I'm not aware of. If a successor is chosen, we can 
   loop him in then.
   2. I wouldn't want to transfer the domain to someone who turns out to be 
   unable to use it - maybe setting up a copy of 4clojure is harder than one 
   might imagine, since it's all 10-year-old technology. If any of the 
   prospective new owners already have a copy of 4clojure running under a 
   different domain name, I'd love to see it. Of course, the 4ever-clojure 
   guys have already done this.
   3. This is more of a "me" problem because my interaction with the 
   Clojure community for years has just been the tiny IRC room and Stack 
   Overflow, but so far all the offers to take on the mantle have come from 
   people and companies I've never heard of. Maybe you're all pillars of the 
   community now, but I just don't know it. I'd hate to give the name over to 
   a group planning to do something nefarious with collected email addresses, 
   for example. I feel like kinda a jerk for asking, since it's not like I was 
   the greatest maintainer, but I don't suppose there are any old-time 
   Clojurists who can vouch for any of these groups? Feel free to email me 
   privately (amalloy@ the domain in question, for now!) if you'd prefer not 
   to be on record as favoring one of these groups over the others.


On Monday, July 12, 2021 at 9:13:09 PM UTC-7 brando...@gmail.com wrote:

> Thank you Alan for all the work and time put into 4clojure, and thank 
> those of you who've started and contributed to 4ever-clojure!
>
> Cheers,
> Brandon
>
> On Sun, Jul 11, 2021 at 2:38 PM Alan Malloy  wrote:
>
>> I've also exported the problem data: 
>> https://drive.google.com/file/d/1hHrygxAs5Do8FpHC9kphYnmyTwZvISnb/view?usp=sharing
>> . 
>>
>> On Sunday, July 11, 2021 at 2:22:33 PM UTC-7 Alan Malloy wrote:
>>
>>> I'm happy to see this project, and I think exporting some data is a 
>>> reasonable compromise. Rather than re-learn how to do any fancy mongodb 
>>> stuff to make it into "pretty" json, I've just done a raw JSON export of 
>>> the solutions collection, which is world-readable at 
>>> https://drive.google.com/file/d/1UQHznThT_eVTBjmLGz3yME8L3teGygUs/view?usp=sharing.
>>>  
>>> I'm contemplating doing a partial export of the users collection too: I 
>>> could connect usernames to IDs without including the email addresses or 
>>> passwords, which would let you rebuild most of the user information. But 
>>> I'm not totally sure this is a good idea: some people may not want their 
>>> usernames shared, or associated with their solutions. Does anyone in this 
>>> thread have an opinion?
>>>
>>> On Tuesday, July 6, 2021 at 9:58:29 AM UTC-7 oxa...@gmail.com wrote:
>>>
>>>> Thank you Alan for all your contributions :)
>>>>
>>>> Hosting things and maintaing them is really hard. We, the LambdaIsland 
>>>> team, are already maintaining clojurians-log and clojureverse and it's 
>>>> definitely not easy!
>>>>
>>>> With a wonderful idea from @borkdude and his `sci` library, I built 
>>>> "4ever-clojure": a completely static version of 4clojure which runs using 
>>>> cljs + sci. It interprets the code in the browser itself. 
>>>>
>>>> It's live at: 4clojure.oxal.org  (Source code at: 
>>>> https://github.com/oxalorg/4ever-clojure  I'm planning to move it 
>>>> under the clojureverse github org)
>>>>
>>>> I have 2 asks from you if it is feasible:
>>>> 1. An export of all solutions (only solutions, no user data needed) - 
>>>> the community is already coming up with some amazing ideas of hooking up 
>>>> user solutions to automatically commit to a Github repo 
>>>> 2. Possibility of transfering *4clojure.com <http://4clojure.com> *-or- 
>>>> *4clojure.org <http://4clojure.org> *over to us so that we can host 
>>>> 4ever-clojure there (instead of on a separate domain)
>>>>
>>>> Thanks!
>>>> - Mitesh
>>>>
>>>> On Tuesday, July 6, 2021 at 5:56:10 PM UTC+5:30 Srihari Sriraman wrote:
>>>>
>>>>> Hey Alan, we really like 4clojure. We've suggested 

Re: [ANN] Discontinuing 4clojure.com

2021-07-11 Thread Alan Malloy
I've also exported the problem 
data: 
https://drive.google.com/file/d/1hHrygxAs5Do8FpHC9kphYnmyTwZvISnb/view?usp=sharing.
 

On Sunday, July 11, 2021 at 2:22:33 PM UTC-7 Alan Malloy wrote:

> I'm happy to see this project, and I think exporting some data is a 
> reasonable compromise. Rather than re-learn how to do any fancy mongodb 
> stuff to make it into "pretty" json, I've just done a raw JSON export of 
> the solutions collection, which is world-readable at 
> https://drive.google.com/file/d/1UQHznThT_eVTBjmLGz3yME8L3teGygUs/view?usp=sharing.
>  
> I'm contemplating doing a partial export of the users collection too: I 
> could connect usernames to IDs without including the email addresses or 
> passwords, which would let you rebuild most of the user information. But 
> I'm not totally sure this is a good idea: some people may not want their 
> usernames shared, or associated with their solutions. Does anyone in this 
> thread have an opinion?
>
> On Tuesday, July 6, 2021 at 9:58:29 AM UTC-7 oxa...@gmail.com wrote:
>
>> Thank you Alan for all your contributions :)
>>
>> Hosting things and maintaing them is really hard. We, the LambdaIsland 
>> team, are already maintaining clojurians-log and clojureverse and it's 
>> definitely not easy!
>>
>> With a wonderful idea from @borkdude and his `sci` library, I built 
>> "4ever-clojure": a completely static version of 4clojure which runs using 
>> cljs + sci. It interprets the code in the browser itself. 
>>
>> It's live at: 4clojure.oxal.org  (Source code at: 
>> https://github.com/oxalorg/4ever-clojure  I'm planning to move it under 
>> the clojureverse github org)
>>
>> I have 2 asks from you if it is feasible:
>> 1. An export of all solutions (only solutions, no user data needed) - the 
>> community is already coming up with some amazing ideas of hooking up user 
>> solutions to automatically commit to a Github repo 
>> 2. Possibility of transfering *4clojure.com <http://4clojure.com> *-or- 
>> *4clojure.org 
>> <http://4clojure.org> *over to us so that we can host 4ever-clojure 
>> there (instead of on a separate domain)
>>
>> Thanks!
>> - Mitesh
>>
>> On Tuesday, July 6, 2021 at 5:56:10 PM UTC+5:30 Srihari Sriraman wrote:
>>
>>> Hey Alan, we really like 4clojure. We've suggested using it for training 
>>> most people at nilenso and we're very thankful to you and all the 
>>> contributors for that!
>>> We (nilenso) would be up for picking up the hosting costs, and also some 
>>> other operations or development work if needed.
>>>
>>> It would be even better if we could work together and turn this into a 
>>> community owned project (ex: clojurists together 
>>> <http://clojuriststogether.org>). That might also assuage your concerns 
>>> about data ownership.
>>>
>>> The questions, and solutions that the community has put together on 
>>> 4clojure over the last decade are very valuable as a learning tool. Perhaps 
>>> we can find a way to keep them around without attributing them to a user? 
>>> One idea might be to deactivate all existing accounts, and remove the user 
>>> data (email, passwords, other PII) etc while keeping the questions and 
>>> solutions from those users.
>>>
>>> We would be sad to see 4clojure go away, hope we can find a way for it 
>>> to live on.
>>>
>>> Cheers,
>>> Srihari
>>>
>>> On Tuesday, July 6, 2021 at 1:12:44 PM UTC+5:30 Robert P. Levy wrote:
>>>
>>>> Hi Alan,
>>>>
>>>> Just as a thought.  If it's minimal work on your end (eg. if the folks 
>>>> from Roam research who chimed in above pick it up) why not clear the 
>>>> password hashes and let the new maintainer handle the communication that 
>>>> passwords need to be reset?
>>>>
>>>> Rob
>>>>
>>>> On Sun, Jul 4, 2021 at 1:26 PM Alan Malloy  wrote:
>>>>
>>>>> TL;DR: Turning off 4clojure.com by the end of July 2021
>>>>>
>>>>> Hello, 4clojure problem solvers. You've probably noticed SSL errors on 
>>>>> 4clojure.com over the last week. The old decrepit system 4clojure 
>>>>> runs on has finally gotten out of date enough that I can't even figure 
>>>>> out 
>>>>> how to get it recent enough that SSL certs will auto-renew anymore.
>>>>>
>>>>> In principle I could start from scratch on a new server and move 
>>>>> 

Re: [ANN] Discontinuing 4clojure.com

2021-07-11 Thread Alan Malloy
I'm happy to see this project, and I think exporting some data is a 
reasonable compromise. Rather than re-learn how to do any fancy mongodb 
stuff to make it into "pretty" json, I've just done a raw JSON export of 
the solutions collection, which is world-readable at 
https://drive.google.com/file/d/1UQHznThT_eVTBjmLGz3yME8L3teGygUs/view?usp=sharing.
 
I'm contemplating doing a partial export of the users collection too: I 
could connect usernames to IDs without including the email addresses or 
passwords, which would let you rebuild most of the user information. But 
I'm not totally sure this is a good idea: some people may not want their 
usernames shared, or associated with their solutions. Does anyone in this 
thread have an opinion?

On Tuesday, July 6, 2021 at 9:58:29 AM UTC-7 oxa...@gmail.com wrote:

> Thank you Alan for all your contributions :)
>
> Hosting things and maintaing them is really hard. We, the LambdaIsland 
> team, are already maintaining clojurians-log and clojureverse and it's 
> definitely not easy!
>
> With a wonderful idea from @borkdude and his `sci` library, I built 
> "4ever-clojure": a completely static version of 4clojure which runs using 
> cljs + sci. It interprets the code in the browser itself. 
>
> It's live at: 4clojure.oxal.org  (Source code at: 
> https://github.com/oxalorg/4ever-clojure  I'm planning to move it under 
> the clojureverse github org)
>
> I have 2 asks from you if it is feasible:
> 1. An export of all solutions (only solutions, no user data needed) - the 
> community is already coming up with some amazing ideas of hooking up user 
> solutions to automatically commit to a Github repo 
> 2. Possibility of transfering *4clojure.com <http://4clojure.com> *-or- 
> *4clojure.org 
> <http://4clojure.org> *over to us so that we can host 4ever-clojure there 
> (instead of on a separate domain)
>
> Thanks!
> - Mitesh
>
> On Tuesday, July 6, 2021 at 5:56:10 PM UTC+5:30 Srihari Sriraman wrote:
>
>> Hey Alan, we really like 4clojure. We've suggested using it for training 
>> most people at nilenso and we're very thankful to you and all the 
>> contributors for that!
>> We (nilenso) would be up for picking up the hosting costs, and also some 
>> other operations or development work if needed.
>>
>> It would be even better if we could work together and turn this into a 
>> community owned project (ex: clojurists together 
>> <http://clojuriststogether.org>). That might also assuage your concerns 
>> about data ownership.
>>
>> The questions, and solutions that the community has put together on 
>> 4clojure over the last decade are very valuable as a learning tool. Perhaps 
>> we can find a way to keep them around without attributing them to a user? 
>> One idea might be to deactivate all existing accounts, and remove the user 
>> data (email, passwords, other PII) etc while keeping the questions and 
>> solutions from those users.
>>
>> We would be sad to see 4clojure go away, hope we can find a way for it to 
>> live on.
>>
>> Cheers,
>> Srihari
>>
>> On Tuesday, July 6, 2021 at 1:12:44 PM UTC+5:30 Robert P. Levy wrote:
>>
>>> Hi Alan,
>>>
>>> Just as a thought.  If it's minimal work on your end (eg. if the folks 
>>> from Roam research who chimed in above pick it up) why not clear the 
>>> password hashes and let the new maintainer handle the communication that 
>>> passwords need to be reset?
>>>
>>> Rob
>>>
>>> On Sun, Jul 4, 2021 at 1:26 PM Alan Malloy  wrote:
>>>
>>>> TL;DR: Turning off 4clojure.com by the end of July 2021
>>>>
>>>> Hello, 4clojure problem solvers. You've probably noticed SSL errors on 
>>>> 4clojure.com over the last week. The old decrepit system 4clojure runs 
>>>> on has finally gotten out of date enough that I can't even figure out how 
>>>> to get it recent enough that SSL certs will auto-renew anymore.
>>>>
>>>> In principle I could start from scratch on a new server and move 
>>>> 4clojure over, but I won't. 4clojure has been piggybacking along on a 
>>>> server that I use for personal reasons, and over the years I have less and 
>>>> less reason to keep paying for that server - it's now pretty much just 
>>>> 4clojure costing me an embarrassing amount of money every month because I 
>>>> haven't wanted to disappoint the community by shutting it down. This SSL 
>>>> thing is just what made me finally pull the trigger.
>>>>
>>>> I don't have a specific EOL date in mind, but so

[ANN] Discontinuing 4clojure.com

2021-07-04 Thread Alan Malloy
TL;DR: Turning off 4clojure.com by the end of July 2021

Hello, 4clojure problem solvers. You've probably noticed SSL errors on 
4clojure.com over the last week. The old decrepit system 4clojure runs on 
has finally gotten out of date enough that I can't even figure out how to 
get it recent enough that SSL certs will auto-renew anymore.

In principle I could start from scratch on a new server and move 4clojure 
over, but I won't. 4clojure has been piggybacking along on a server that I 
use for personal reasons, and over the years I have less and less reason to 
keep paying for that server - it's now pretty much just 4clojure costing me 
an embarrassing amount of money every month because I haven't wanted to 
disappoint the community by shutting it down. This SSL thing is just what 
made me finally pull the trigger.

I don't have a specific EOL date in mind, but sometime near the end of the 
month, since that's the billing cycle. Until that time, 4clojure still 
works, as long as you don't mind clicking through the security warnings - 
it really is still me hosting the site, and since the connection is still 
HTTPS (albeit with an invalid cert) I think that means your data is still 
safe. If you have solutions to problems you're proud of, you've still got 
some time to print them out and put them up on your refrigerator.

I'm not seeking new maintainers. I'd feel uncomfortable handing over a 
database with so many email addresses and password hashes in it to anyone. 
The service has had a good run - just over a decade since the first release 
.
 
I hope you enjoyed it during that time.

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


Re: Could not locate

2021-01-05 Thread 'Alan Forrester' via Clojure
On 5 Jan 2021, at 10:50, Yang Xu  wrote:

> I am begin with clojure, when I invoke clojure from java. The "Could not 
> locate cljcore/core__init.class, cljcore/core.clj or cljcore/core.cljc on 
> classpath" is arised.
> 
> (defproject cljcore "0.1.0-SNAPSHOT"
> :description "FIXME: write description"
> :url "http://example.com/FIXME;
> :license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
> :url "https://www.eclipse.org/legal/epl-2.0/"}
> :dependencies [[org.clojure/clojure "1.10.1"]
> [org.clojure/core.logic "1.0.0"]
> ]
> :repl-options {:init-ns cljcore.core}
> :java-source-paths
> ["java"]
> :source-paths
> ["src"]
> :test-paths
> ["test”]
> )

Have you installed leiningen?

Alan Forrester

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


[JOB] Strategic Blue Clojure job in London

2020-12-03 Thread 'Alan Forrester' via Clojure
Hello

Strategic Blue is a company that helps organisations buy cloud on terms to suit 
their needs and optimise long-term cloud costs. We’re hiring a Clojure 
developer in London:

https://strategic-blue.com/careers_pt/developer-2/

Alan Forrester


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


An Intuition for Lisp Syntax

2020-10-25 Thread 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

2020-08-12 Thread 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
> ---
> Y

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

2020-08-12 Thread 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

2020-08-11 Thread 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

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

2020-08-10 Thread 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

2020-08-10 Thread Alan Thompson
tpasyncclient/4.1.3/httpasyncclient-4.1.3.jar:/Users/alanthompson/.m2/repository/org/checkerframework/checker-qual/2.0.0/checker-qual-2.0.0.jar:/Users/alanthompson/.m2/repository/ns-tracker/ns-tracker/0.3.1/ns-tracker-0.3.1.jar:/Users/alanthompson/.m2/repository/cljsjs/react-select/2.4.4-0/react-select-2.4.4-0.jar:/Users/alanthompson/.m2/repository/org/javassist/javassist/3.18.1-GA/javassist-3.18.1-GA.jar:/Users/alanthompson/.m2/repository/com/google/protobuf/protobuf-java/3.11.1/protobuf-java-3.11.1.jar:/Users/alanthompson/.m2/repository/org/fusesource/jansi/jansi/1.16/jansi-1.16.jar:/Users/alanthompson/.m2/repository/com/cognitect/transit-clj/0.8.309/transit-clj-0.8.309.jar:/Users/alanthompson/.m2/repository/org/codehaus/mojo/animal-sniffer-annotations/1.14/animal-sniffer-annotations-1.14.jar:/Users/alanthompson/.m2/repository/org/apache/httpcomponents/httpclient/4.5.3/httpclient-4.5.3.jar:test-figwheel-main:/Users/alanthompson/.m2/repository/com/cognitect/transit-cljs/0.8.256/transit-cljs-0.8.256.jar:
..
:/Users/alanthompson/.m2/repository/zprint/zprint/0.5.1/zprint-0.5.1.jar:
*resources*
:/Users/alanthompson/.m2/repository/org/clojure/tools.analyzer/1.0.0/tools.analyzer-1.0.0.jar:/Users/alanthompson/.m2/repository/re-frame/re-frame/0.10.5/re-frame-0.10.5.jar:/Users/alanthompson/.m2/repository/rewrite-cljs/rewrite-cljs/0.4.4/rewrite-cljs-0.4.4.jar:/Users/alanthompson/.m2/repository/net/cgrand/macrovich/0.2.0/macrovich-0.2.0.jar:/Users/alanthompson/.m2/repository/org/clojure/clojurescript/1.10.764/clojurescript-1.10.764.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/eclipse/jetty/jetty-client/9.4.28.v20200408/jetty-client-9.4.28.v20200408.jar


with `resources` nearly at the end!  This breaks Figwheel.Main, which
cannot find `index.html` correctly and puts up a bogus webpage of 2 words:

*Debux Test*


which I assume is due to finding some other `index.html` earlier on the
classpath.

Questions:


   1. What is the difference between the brew targets `clojure` and
   `clojure/tools/clojure`?  Can these be unified somehow? It seems
   error-prone as-is.
   2. I assume the classpath change in 1.10.1.645 is a bug that needs to be
   corrected?
   3. Is it possible this is a Figwheel.Main problem instead?


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/CAN67zA0P4k-PBnX%2BLf8K_%2BzOWC%2BekMDFEAxi4nwRF3OY3qZM3A%40mail.gmail.com.


Cognitect joins Nubank!

2020-07-23 Thread Alan Moore
Congrats!

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/7bcf635c-051e-401a-9824-7b7d3bcc66fao%40googlegroups.com.


Re: bit-wise operators for bigint in Clojure

2020-05-28 Thread 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
> <https://groups.google.com/d/msgid/clojure/4b6e3f5e-c70c-404a-9348-8117a4b32db8%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/CAN67zA2sC%3D2TQYpWaZsfmPuGErTKmkY4buB2M3qPwRgJM%2Bpwxg%40mail.gmail.com.


Excellent series of videos by Uncle Bob Martin

2020-04-28 Thread Alan Thompson
I think everyone can benefit from viewing this material:


   - Clean Code - pt 1 <https://youtu.be/7EmboKQH8lM>
   - Clean Code - pt 2 <https://youtu.be/2a_ytyt9sf8>
   - Clean Code - pt 3 <https://youtu.be/Qjywrq2gM8o>
   - Clean Code - pt 4 <https://youtu.be/58jGpV2Cg50>
   - Clean Code - pt 5 <https://youtu.be/sn0aFEMVTpA>
   - Clean Code - pt 6 <https://youtu.be/l-gF0vDhJVI>


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

2020-04-12 Thread 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

2020-04-10 Thread 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

2020-04-02 Thread 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

2020-04-02 Thread 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

2020-03-28 Thread 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

2020-03-28 Thread 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

2020-03-25 Thread 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.


italian government is making a fast call for contributions on telemedicine and data analysis solutions in order to contain the spread of Covid-19

2020-03-24 Thread Alan Moore
Luca,

Thanks for reaching out. Will take a look to see how I can help. Currently 
helping out with a tracking app effort to slow the spread.

Best of luck to you and all of Italy & well, all of us.

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/5c7a0a46-b79a-416f-ad13-723788188b8d%40googlegroups.com.


Re: Clojure 1.10 "Illegal Reflective Access Operation"

2020-03-22 Thread Alan Thompson
I have included easy-to-use parsers of 3 types in the Tupelo library for 3
formats:

- HTML:  tupelo.parse.tagsoup
<https://cljdoc.org/d/tupelo/tupelo/0.9.199/api/tupelo.parse.tagsoup>
- XML:   tupelo.parse.xml
<https://cljdoc.org/d/tupelo/tupelo/0.9.199/api/tupelo.parse.xml>
- YAML:  tupelo.parse.yaml
<https://cljdoc.org/d/tupelo/tupelo/0.9.199/api/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
> <https://groups.google.com/d/msgid/clojure/cd43204d-cbd2-488e-95dc-26a392f991bc%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/CAN67zA3xrC8mp0YRSQ399PSZAq69jpuaRCZD-M0-mia_zOnLmA%40mail.gmail.com.


Re: quoting vs syntax quoting

2020-03-02 Thread 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
>> <https://groups.google.com/d/msgid/clojure/82bdc4fc-2453-4561-80da-e3c6d6346900%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure"

Re: Clojars deployment failing

2020-02-20 Thread 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
>> <https://github.com/technomancy/leiningen/blob/c72803cbff53c4abb8ccb5538d54824845bfd0c0/sample.project.clj#L114>
>>
>> > $ 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.
>>> Fa

Re: Stack Overflow developer survey

2020-02-07 Thread Alan Moore
Done.

Alan

On Wednesday, February 5, 2020 at 8:02:13 PM UTC-8, Sean Corfield wrote:
>
> I've been encouraging folks to take the survey and write in Clojure. 
> Representation matters!
>
> On Wed, Feb 5, 2020 at 5:45 PM Matching Socks  > wrote:
>
>> Today, I noticed an invitation to complete the Stack Overflow developer 
>> survey.
>>
>> (Clojure was not on the menu.)
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clo...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clo...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/clojure/f46ba1b5-72db-4a72-be41-6f0d83cd7839%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/clojure/f46ba1b5-72db-4a72-be41-6f0d83cd7839%40googlegroups.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)
>

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


[ANN] Juxt/Bidi routing library demo

2020-01-29 Thread 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

2020-01-17 Thread 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?

2019-12-16 Thread 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?

2019-12-16 Thread 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

2019-12-03 Thread 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

2019-11-12 Thread 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

2019-11-12 Thread 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

2019-11-08 Thread 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)

2019-10-11 Thread 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

2019-10-09 Thread 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

2019-08-23 Thread 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.


[ANN] ubergraph 0.6.0

2019-07-25 Thread Alan Moore
Damn, this dude is on FIRE!

Thanks Mark for these awesome libraries. It clear you’ve put a lot of time and 
effort into them!

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/c9cef2e5-9d06-405e-a22d-43661a73df44%40googlegroups.com.


Re: Calling Java from Clojure

2019-06-12 Thread Alan Moore
Nice, this looks very handy. Thanks!

Alan

On Wednesday, June 12, 2019 at 12:12:01 AM UTC-7, henrik42 wrote:
>
> I hacked just that a few days ago to support Java development at work: 
> https://github.com/henrik42/deeto Not released yet but could be a starter 
> in that direction.
> Henrik
>

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


Re: Calling Java from Clojure

2019-06-11 Thread Alan Moore
Maybe this is too old school but wouldn’t a dynamic proxy help here? E.g. 
java.lang.reflect.InvocationHandler & java.lang.reflect.Proxy.

Clearly you’d be relying on reflection but if your interface usage is large 
grained enough the overhead wouldn’t be too bad.

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


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

2019-06-07 Thread 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.


[ANN] cpython bindings for clojure

2019-06-05 Thread Alan Moore
Awesome!

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/234d90b5-089f-49e2-9102-1f14d28f5c9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: No "clojure --version" switch

2019-05-08 Thread 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

2019-05-07 Thread 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

2019-05-07 Thread 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

2019-04-09 Thread 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

2019-04-01 Thread 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
> <https://github.com/danielcompton/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
> <https://danielcompton.net/2019/03/31/announcing-defn-spec>, and there
> are more details on GitHub <https://github.com/danielcompton/defn-spec>.
> 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.


Oz: Live code reloading for Clojure (& data science)

2019-03-27 Thread Alan Moore
Chris,

Nice feature, thanks! I’m not in a position to try it out now but will give it 
a go after an ongoing trade show scramble.

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: [ANN] Clojure 1.10.1-beta1

2019-03-26 Thread 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"

2019-03-03 Thread 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"

2019-03-02 Thread 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"

2019-02-24 Thread 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

2019-02-08 Thread 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 ???

2019-02-06 Thread 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

2019-01-04 Thread Alan Thompson
Hi have been very happy using Pedestal for routing <http://pedestal.io/>
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?

2019-01-04 Thread Alan Thompson
If you haven't seen it before, you can use the excellent Claypoole library
<https://github.com/TheClimateCorporation/claypoole> 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

2018-12-18 Thread 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, 

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

2018-12-15 Thread 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?

2018-12-15 Thread 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 ?

2018-12-15 Thread 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 ?

2018-12-15 Thread 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: Announcing The REPL podcast

2018-11-28 Thread Alan Moore
Same here, great work in the podcast and Clojurists Together!

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

2018-11-17 Thread 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 <http://avro.apache.org/docs/current/> library
> for Clojure and ClojureScript. It aims to be fully compliant with the Avro
> Specification <http://avro.apache.org/docs/current/spec.html>. Lancaster
> is faster than JSON encoding / decoding and produces much smaller output.
> It also supports Avro schema evolution
> <http://avro.apache.org/docs/current/spec.html#Schema+Resolution>,
> 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

2018-11-04 Thread 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

2018-11-04 Thread 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

2018-10-17 Thread 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.
&g

Re: [ANN] Clojure 1.10.0-beta1

2018-10-05 Thread 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
>><https://dev.clojure.org/jira/browse/CLJ-1550> - Classes generated by
>>deftype and defrecord don’t play nice with .getPackage
>>- Revert change for CLJ-1435
>><https://dev.clojure.org/jira/browse/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

2018-10-04 Thread 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

Re: Keyword namespacing best practices

2018-10-01 Thread 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

2018-09-20 Thread 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

2018-09-20 Thread 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

2018-09-20 Thread 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

2018-08-30 Thread 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?

2018-08-09 Thread 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: Rusts Upgrades

2018-07-30 Thread Alan Moore
Nathan,

I wasn’t concerned with Github per se but the CI server compiling/running
arbitrary code should some library’s repo get pwnd in some way or that a
rogue library could make it into the list of repos to build in the proposed
system. A hand curated list of repos would mitigate this last concern.

I suppose CircleCI/Travis have this figured out (sandboxes?) given that
they already run arbitrary code via tests. I’ve not used any of the
cloud-based CI services, just in-house installations that are tightly
controlled.

Never mind... I think I’ve left my paranoia dial set to 11 after reading
about remote Spectre attacks.

Alan

On Jul 30, 2018, at 1:01 PM, Nathan Fisher  wrote:

If it’s run on CircleCI or Travis and has readonly access to github, I
wouldn’t be too concerned.

The most frequent downloads API in Clojars is a good idea. Could use it as
a basis for the hand rolled site for now and target it for automation in
the future. I’m wondering how amenable/suitable it would be for the data to
live in Clojars.

On Mon, Jul 30, 2018 at 02:17, Alan Moore 
wrote:

> Has anyone looked for vulnerabilities exposed by pulling random libraries
> from github.com (or gitlab.com?) and building them? Macros come mind
> (mined?!) Solved problem? AFAIK the Rust compiler can't run arbitrary code.
>
> Also instead of choosing "top-N projects on Github" I would begin with
> the "most used projects on clojars" (# downloads in the last 12 months?) as
> that might be a better metric/signal for prioritizing which libraries to
> include. #RememberLeftPad
>
> Don't get me wrong, I like the idea. I'm just trying to think through the
> possible hazards.
>
> Alan
>
>
> On Friday, July 27, 2018 at 4:11:27 PM UTC-7, Nathan Fisher wrote:
>>
>> Hi Folks,
>>
>> Reading up the recent blog post “What is Rust 2018” and happened upon
>> this;
>>
>> “We put in a lot of work to make upgrades painless; for example, we run a
>> tool (called “crater”) before each Rust release that downloads every
>> package on crates.io and attempts to build their code and run their
>> tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
>>
>> Seems an interesting idea and with Travis and other CI services providing
>> free builds for OSS it doesn’t need to put a heavy financial/operational
>> burden on a single entity. The main benefit for this is for people could
>> get a quick centralised overview of compatibility of various projects and
>> impending releases of Clojure.
>>
>> The main idea would be to have a grid view of the latest Clojure projects
>> and their status against HEAD of Clojure (are snapshots pushed to a maven
>> repo automatically as a result of a commit build?). Travis allows periodic
>> builds so that could be used to trigger verification even when changes
>> haven’t occurred.
>>
>> In terms of initial focus targeting the top-N projects on Github makes
>> the most sense to me. The bit I’m still thinking through is providing some
>> form of dashboard/aggregation without requiring a large investment in
>> changes, infrastructure, etc. Might fit in nicely with something like
>> clojars? Was thinking initially having a Github page with a table of
>> projects and their build badges and talking to maintainers about
>> configuring periodic builds with the latest Clojure snapshot.
>>
>> Thoughts?
>>
>> Cheers,
>> Nathan
>> --
>> - 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.
>
-- 
- 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 

Re: Rusts Upgrades

2018-07-29 Thread Alan Moore
Has anyone looked for vulnerabilities exposed by pulling random libraries 
from github.com (or gitlab.com?) and building them? Macros come mind 
(mined?!) Solved problem? AFAIK the Rust compiler can't run arbitrary code.

Also instead of choosing "top-N projects on Github" I would begin with the 
"most used projects on clojars" (# downloads in the last 12 months?) as 
that might be a better metric/signal for prioritizing which libraries to 
include. #RememberLeftPad

Don't get me wrong, I like the idea. I'm just trying to think through the 
possible hazards.

Alan

On Friday, July 27, 2018 at 4:11:27 PM UTC-7, Nathan Fisher wrote:
>
> Hi Folks,
>
> Reading up the recent blog post “What is Rust 2018” and happened upon this;
>
> “We put in a lot of work to make upgrades painless; for example, we run a 
> tool (called “crater”) before each Rust release that downloads every 
> package on crates.io and attempts to build their code and run their 
> tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
>
> Seems an interesting idea and with Travis and other CI services providing 
> free builds for OSS it doesn’t need to put a heavy financial/operational 
> burden on a single entity. The main benefit for this is for people could 
> get a quick centralised overview of compatibility of various projects and 
> impending releases of Clojure.
>
> The main idea would be to have a grid view of the latest Clojure projects 
> and their status against HEAD of Clojure (are snapshots pushed to a maven 
> repo automatically as a result of a commit build?). Travis allows periodic 
> builds so that could be used to trigger verification even when changes 
> haven’t occurred.
>
> In terms of initial focus targeting the top-N projects on Github makes the 
> most sense to me. The bit I’m still thinking through is providing some form 
> of dashboard/aggregation without requiring a large investment in changes, 
> infrastructure, etc. Might fit in nicely with something like clojars? Was 
> thinking initially having a Github page with a table of projects and their 
> build badges and talking to maintainers about configuring periodic builds 
> with the latest Clojure snapshot.
>
> Thoughts?
>
> Cheers,
> Nathan
> -- 
> - 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.


Re: Best way to use Lein only as a build tool?

2018-07-27 Thread 'Alan Forrester' via Clojure
On 27 Jul 2018, at 06:39, Didier  wrote:

> What's the best way to use Lein only as a build tool? If I want to do my own 
> dependency resolutions. Or say use tools.deps for dependency resolution, but 
> Lein for all other build tasks?

There’s a leiningen plugin for using tools.deps:

https://github.com/RickMoynihan/lein-tools-deps

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?

2018-07-18 Thread 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?

2018-07-18 Thread 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

2018-07-18 Thread 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

2018-06-02 Thread 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

2018-05-24 Thread 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, <skf.phoe...@gmail.com> 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

2018-05-24 Thread 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.


[ANN] re-graph 0.1.5 - the GraphQL client for Clojurescript

2018-05-13 Thread Alan Moore
Nice! Thanks, I’ll have to take a look. This is good timing for my current 
project.

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: Clojure/flutter

2018-04-27 Thread Alan Moore
Or maybe a WebAssembly or LLVM target. Lots of reach from those ;-)

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.


[ANN] clj-new -- creating new Clojure projects using the clj CLI

2018-04-19 Thread Alan Moore
Nice... this looks super helpful, 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.
For more options, visit https://groups.google.com/d/optout.


Clojure Games

2018-04-16 Thread Alan Moore
Peter,

What gaming toolchains/platforms are you intending to target?

Unity, Unreal, Godot, web, Facebook, mobile, JVM or just roll your own?

I’ve experimented with Unity/Arcadia (doing VR stuff) but nothing requiring 
high performance nor too complex. See:

https://github.com/arcadia-unity/Arcadia

I really like it and it serves my use case. You can even fire up a repl-like 
envy and create GameObjects on the fly. Most of my work is procedurally 
generated if that makes any difference.

There are some Clojure libraries that either wrap other JVM gaming libraries or 
do all/most of the work in Clojure itself but I haven’t used them so I can’t 
opine on their utility. Here are a few link that might help:

https://lambdaisland.com/blog/08-12-2016-game-development-with-clojure-clojurescript
http://www.clojure-games.org/code
https://github.com/oakes/play-cljs

Fire away w questions.

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: [ANN] packthread 0.1.10

2018-04-03 Thread 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 

[ANN] datahike 0.1.0

2018-04-01 Thread Alan Moore
Christian,

Nice, I’m excited to see this come together! I’ll jump back on gitter to see if 
there is something I can do to help.

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.


[ANN] A couple of libraries for functional reactive web programming - Ulmus & Recurrent

2018-03-31 Thread Alan Moore
Thanks for putting this out. Good to see so many interesting solutions from the 
ClojureScript community.

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.


StackOverflow Job Survey results are out

2018-03-13 Thread 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.


transients problem

2018-02-24 Thread 'Alan Forrester' via Clojure
Calling (first #{1}) gives the result 1.

Calling (first (transient #{1})) gives an error:

“IllegalArgumentException Don't know how to create ISeq from: 
clojure.lang.PersistentHashSet$TransientHashSet  clojure.lang.RT.seqFrom 
(RT.java:550)”

Is this behaviour intended?

And whether or not this is intentional is there a way round it?

Alan Forrester


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

2018-02-20 Thread 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.


Clojure integrates Cesium, Openstreetmap and OpenMap inside Protege

2018-02-06 Thread Alan Moore
Ru,

You’ve done some impressive work on this and previous projects. I especially 
like the level of integration with other tools. 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.
For more options, visit https://groups.google.com/d/optout.


Re: what does future do after fn finish ?

2018-02-01 Thread 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 <noisesm...@gmail.com> 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 <grzebyta@gmail.com> 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 <john...@gmail.com> wrote:
>>
>>> Ah, he's using one agent, I see.
>>>
>>> On Jan 31, 2018 9:15 PM, "John Newman" <john...@gmail.com> 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" <noisesm...@gmail.com> 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 <john...@gmail.com> 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" <noisesm...@gmail.com>
>>>>>>> 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 <ja...@booleanknot.com>
>>>>>>>>> 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 

Re: Russ olsen's Clojure Book

2018-01-22 Thread Alan Thompson
Really looking forward to it!
Alan

On Mon, Jan 22, 2018 at 11:43 AM, Shaun Parker <shaunrpar...@gmail.com>
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 <clo...@googlegroups.com> on behalf of
>>> William Swaney <the2...@gmail.com>
>>> *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.


  1   2   3   4   5   6   7   8   9   10   >