State of Clojure 2023 Survey

[Alex Miller]

Hello, the annual State of Clojure 2023 survey is now open! This survey has 
been done every year since 2010 and has been instrumental in tracking 
changes in the Clojure community over time. 

https://www.surveymonkey.com/r/clojure2023

We would greatly appreciate it if you could complete this by March 13th! It 
takes about 10 minutes and almost all questions are optional.

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

Re: Override deps

['Alex Miller' via Clojure]

There may be other things wrong, but hard to tell without more context of
your deps.edn.

On Mon, Feb 13, 2023 at 7:02 PM Alex Miller  wrote:

> It looks like you misspelled ":override-deps" (two r's) ?
>
> On Mon, Feb 13, 2023 at 5:50 PM 'Tête à-tête' via Clojure <
> clojure@googlegroups.com> wrote:
>
>> :overide-deps
>> {edu.stanford.nlp/stanford-corenlp {:mvn/version "4.5.2"}}
>>
>> I've tried preventing corenlp 4.4.0 and, here, I'm insisting on 4.5.2!
>>
>> A framework that I use relies on corenlp but, I want deps to resolve to
>> the latest version only, so not backfill the m2 repo.
>>
>>
>> On Monday, 13 February 2023 at 23:27:38 UTC Alex Miller wrote:
>>
>>> Can you share an example deps.edn or some more information?  Also, what
>>> Clojure CLI version are you using `clj --version`.
>>>
>>> Alex
>>>
>>> On Monday, February 13, 2023 at 7:14:20 AM UTC-6
>>> deliver...@googlemail.com wrote:
>>>
>>>> My laptop is struggling for space and, I would like to override a
>>>> dependency, so that earlier versions aren't pulled to m2 repo.
>>>>
>>>> If it's :override-deps, I'm just doing it wrong!
>>>>
>>>> Whenever I boot a repl, it won't boot, unless it starts pulling a
>>>> half-gig of I-don't-want-this- old-version!
>>>>
>>>>
>>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 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/g-Gy3Q7jHfk/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/22215b6b-73ec-4f5d-ba4f-c24a3010b32fn%40googlegroups.com
>> <https://groups.google.com/d/msgid/clojure/22215b6b-73ec-4f5d-ba4f-c24a3010b32fn%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/CAOdgdgxWS8kfBQUCHd7FvdZu9Unr%2BLjW_mDatxOUhxpSStu-DQ%40mail.gmail.com.

Re: Override deps

['Alex Miller' via Clojure]

It looks like you misspelled ":override-deps" (two r's) ?

On Mon, Feb 13, 2023 at 5:50 PM 'Tête à-tête' via Clojure <
clojure@googlegroups.com> wrote:

> :overide-deps
> {edu.stanford.nlp/stanford-corenlp {:mvn/version "4.5.2"}}
>
> I've tried preventing corenlp 4.4.0 and, here, I'm insisting on 4.5.2!
>
> A framework that I use relies on corenlp but, I want deps to resolve to
> the latest version only, so not backfill the m2 repo.
>
>
> On Monday, 13 February 2023 at 23:27:38 UTC Alex Miller wrote:
>
>> Can you share an example deps.edn or some more information?  Also, what
>> Clojure CLI version are you using `clj --version`.
>>
>> Alex
>>
>> On Monday, February 13, 2023 at 7:14:20 AM UTC-6
>> deliver...@googlemail.com wrote:
>>
>>> My laptop is struggling for space and, I would like to override a
>>> dependency, so that earlier versions aren't pulled to m2 repo.
>>>
>>> If it's :override-deps, I'm just doing it wrong!
>>>
>>> Whenever I boot a repl, it won't boot, unless it starts pulling a
>>> half-gig of I-don't-want-this- old-version!
>>>
>>>
>>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/g-Gy3Q7jHfk/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/22215b6b-73ec-4f5d-ba4f-c24a3010b32fn%40googlegroups.com
> <https://groups.google.com/d/msgid/clojure/22215b6b-73ec-4f5d-ba4f-c24a3010b32fn%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/CAOdgdgyDiR1DGfOG9a-ACnMg1fw3jdxzCe0ceh6tCMFA31KisA%40mail.gmail.com.

Re: Override deps

['Alex Miller' via Clojure]

Can you share an example deps.edn or some more information?  Also, what 
Clojure CLI version are you using `clj --version`.

Alex

On Monday, February 13, 2023 at 7:14:20 AM UTC-6 deliver...@googlemail.com 
wrote:

> My laptop is struggling for space and, I would like to override a 
> dependency, so that earlier versions aren't pulled to m2 repo.
>
> If it's :override-deps, I'm just doing it wrong!
>
> Whenever I boot a repl, it won't boot, unless it starts pulling a half-gig 
> of I-don't-want-this- old-version!
>
>
>

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

Re: ANN: just-maven-clojure-archetype 0.3-RELEASE

['Alex Miller' via Clojure]

It still builds all the Clojure contrib projects. :)

On Saturday, November 19, 2022 at 10:54:18 PM UTC-6 ma...@talios.com wrote:

> Nice,
>
> Almost surprised to not see my clojure-maven-plugin pop in there - it’s 
> always a surprise finding folk still using it.
>
> -- 
> "Great artists are extremely selfish and arrogant things" — Steven Wilson, 
> Porcupine Tree
>
>
> On 20/11/2022 at 1:43:52 PM, Jon Seltzer  wrote:
>
>> Bumped version, some small changes - see details here 
>> .
>>
>> Let's you do Clojure development in a Java shop without demanding the 
>> adoption of a new build stack - it's just Maven.
>>
>>

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

Re: Any updates on spec after “Maybe Not” presentation?

[Alex Miller]

The schema and select support has been added to spec in spec2 
(https://github.com/clojure/spec-alpha2) but is still a work in progress. 
You can find more info at 
https://github.com/clojure/spec-alpha2/wiki/Schema-and-select .

Alex

On Thursday, May 19, 2022 at 4:12:33 PM UTC-5 Dmitry Kakurin wrote:

> Hello,
> The “Maybe Not” talk from 2018 has hinted at significant upcoming changes 
> for spec, such as removal of “:req” keys for map specs and potential 
> introduction of “spec/select”.
> But I could not find any additional information in the past 3-4 years on 
> the evolution of that line of development.
> Are there any updates or additional information on this?
>
> Thank you, Dmitry.
>

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

Re: Book project : compilation of Rich Hickey conferences transcripts translated in french

[Alex Miller]

Hi Paul, contact me at alex.mil...@cognitect.com.

I will say that if anyone wants to do translations / transcriptions in 
other languages for anything on ClojureTV, I am more than happy to add 
those to the video.

Alex

On Tuesday, May 24, 2022 at 6:21:02 AM UTC-5 paul@gmail.com wrote:

> Hi,
>
> I am a French web developer, soon a teacher, IT books and standards 
> enthusiast.
>
> I've listened many times to many of Rich Hickey conferences. It took me 
> time and mental efforts to understand those ideas and concepts, but now I 
> can say that I consider Rich Hickey to be on of the most precious (public 
> at least) thinker and artisan in the IT. So for that, I want first to thank 
> him to have shape my mind to fascinating new horizons.
>
> I want to make the ideas and concepts discussed in those conferences 
> accessible for a French-speaking audience. I think many people (besides 
> programmers) interested from near or far to information systems would 
> benefit from this content. I'm rather surprised to realize that even if 
> understanding/reading English language is a "must have" for any developer 
> around the world, still many French-speaking developers and IT people are 
> not able to "read" (in the general sense) with ease many English textbooks 
> or conferences. I would like to contribute to feel that gap by translating 
> and publishing some content found in those conferences for this audience, 
> because this work is highly valuable, and I think need to be better known 
> by many IT people.
>
> I've already made a French subtitle version of the conference "The Value 
> of Values" (Jax Conference, 2012) available on YouTube (link: 
> https://www.youtube.com/watch?v=VJi1vOwu2SM). I've been doing caption for 
> many years now. Mainly I have caption 5 of 7 of the Feynman Lectures on 
> Physics conference (1964) (I'm an ex physicist and big fan of Richard 
> Feynman...) (link: 
> https://www.youtube.com/watch?v=GSeSqqUV7_4=PLS3XEhTy6-AkS1j8JrHoJnkSrY31Bfddl).
>  
> And I saw that many people were hungry for this wonderful and rich content 
> (as your work) they cannot access otherwise.
>
> I would like, in the near future, to work on a compilation of transcripts 
> of some of Rich Hickey conferences (based on some themes), translated in 
> French. The idea I have in mind is to try to publish a small book in French 
> in the same idea as the book "La nature de la physique", a French 
> transcript compilation of the Feynman Lectures on Physics.
>
> I wanted to know if Rich Hickey (or any other people involved) would be 
> interested to see this project happening or not, and if there are any legal 
> questions, constrains etc...
>
> Thank you for reading this way too long message,
>
> I wish you a very pleasant day,
>
> Best regards,
>
> Paul Schuhmacher

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

Re: Unnecessary boxing of return from set!

['Alex Miller' via Clojure]

I don't think that void type hint is going to do anything there.  The 
deftype impl of apply here will (has to by Java requirements) return void 
here. There is a gap here I think where the return gets needlessly boxed. 
You might try just putting a nil expr after the set! as a workaround.
In any case, we should definitely get a ticket filed and track this down.

On Sunday, May 15, 2022 at 7:11:31 AM UTC-5 pete windle wrote:

> Hey, I'm trying to work on some performance sensitive code using Clojure 
> together with the Carrotsearch HPPC library. I've come up against a weird 
> behaviour of set! in conjunction with primitive maths.
>
> This example is a toy problem not a production problem, but there are 
> things I might not be harder to do at work w/Clojure.
>
> I have a com.carrotsearch.hppc.LongLongHashMap and I wish to sum the 
> contents of the map. They provide a com.carrotsearch.hppc.LongLongProcedure 
> where an apply method is called for each k, v.
>
> Thence:
> (defprotocol ValueRetriever
>   (get-value [this ^LongLongHashMap memory]))
>
> (deftype ValueAdder [^{:unsynchronized-mutable true} ^long total]
>   LongLongProcedure
>   (^void apply [this ^long k ^long v]
>(set! total (unchecked-add total v)))
>   ValueRetriever
>   (get-value [this memory] (set! total 0) (.forEach memory this) total))
>
> To a first approximation all of the time spent summing the map is in the 
> apply method as expected, however when I profile it with YourKit every 
> sample taken is actually in clojure.lang.Numbers.num. Using the extremely 
> handy *clj-java-decompiler *library I can try to see what's happening, 
> and it looks like we're attempting to box the return value from set!
>
> public void apply(final long k, final long n) {
> Numbers.num(this.total += n);
> }
>
>
> Is there some technique I can use to stop the return value from set! being 
> boxed (before the box is discarded to the void)?
>
> I do have real use cases where a rather tight aggregation loop will be 
> called for many millions of values and I'd prefer not to incur this cost.
>
> Workaround is obviously to write the aggregators in Java but that's 
> strongly not preferred, at the point I'm mixing modes I might as well write 
> the whole core in Java.
>
> Cheers,
>
> Pete Windle
>
>

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

Clojure 1.11 is now available!

[Alex Miller]

You can find an overview here:
https://clojure.org/news/2022/03/22/clojure-1-11-0

And full changelog here:
https://github.com/clojure/clojure/blob/master/changes.md#changes-to-clojure-in-version-1110

Enjoy!

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

Re: How to suppress warnings about namespace replacements?

['Alex Miller' via Clojure]

Most likely a newer version of this library exists that addresses these 
warnings. In this particular case, the issue was fixed in June 2016 as of 
tools.analyzer version 0.6.9.

In a namespace with this issue, you can address like this:

(ns whatever
  (:refer-clojure :exclude [boolean?]))

But you can't really do that from outside the namespace or suppress this 
warning otherwise.

Alex


On Tuesday, February 1, 2022 at 11:22:28 AM UTC-6 Laws wrote:

> I get a lot of warnings like this:
>
> WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: 
> clojure.tools.analyzer.utils, being replaced by: 
> #'clojure.tools.analyzer.utils/boolean?
>
>
> Is there an official way to acknowledge that I'm aware of this namespace 
> issue, such that the warnings disappear? 
>

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

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

[Alex Miller]

You might want to check out the tools.build project.

https://clojure.org/guides/tools_build


On Tuesday, September 14, 2021 at 10:35:24 AM UTC-5 yccal...@gmail.com 
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/dd6434ce-104b-4949-9c79-21e5d6afa0b0n%40googlegroups.com.

Re: ClassNotFoundException when importing a clojure interface

[Alex Miller]

definterface is generally considered a low-level tool in Clojure and 
typically Clojure developers do not create interfaces directly like this.

The two primary means of function abstraction/polymorphism are multimethods 
(can dispatch on any aspect of any of the parameters to a function) and 
protocols (which dispatch on the type of the first parameter to the 
function). There are tradeoffs between these - the former is very flexible, 
the latter is very similar to interfaces (and does use them under the hood) 
so is limited to type-based dispatch but gets all the JVM performance of 
that operation.

On Saturday, July 17, 2021 at 7:44:18 PM UTC-5 jack...@topicquests.org 
wrote:

> Tanya,
>
> That did help, swapping  ie4clj.api.Inferrable for its import.
> That, of course, got me into the next coding bug, about which I shall ask 
> next (I am attempting to use doseq to walk a list and AND its Inferrable 
> members)
>
> Meanwhile, I am truly surprised that you said
>
> I don't think it is the right way to use interfaces in clojure. 
>>
> It's likely a result of dyslexia that I did not see that coming after 
> studying all the online banter about interfaces and protocols.. I chose 
> definterface because the examples showed how to specify the return values, 
> and programming by interface is how I do Java. I'd like to discover what, 
> precisely, to read and get past dyslexic events to learn how to use 
> interfaces.
>
> Many thanks
> Jack
>
> On Sat, Jul 17, 2021 at 4:10 PM Tanya Moldovan  
> wrote:
>
>> Hi,
>>
>> I don't think it is the right way to use interfaces in clojure. Take a 
>> look at  this 
>> 
>>  and this 
>> 
>> . 
>> You could create a java project with the interfaces you need and import 
>> that instead.
>>
>> I think the issue is that this setup requires AOT and it might be missing 
>> from your configuration.
>> To fix it try adding this to project.clj file:
>>
>> :profiles {:dev {:aot [ie4clj.api]}}
>>
>> It can be tricky If you want to do lein uberjar and generate a jar file.
>>
>> Alternatively, you can use compile-files 
>>  (then you don't 
>> need import statement).
>> (note that in your gist you had some errors when defining AndList, I've 
>> fixed it)
>> (also take a look at the clojure style guide 
>> , as AndList is not 
>> really the way to name things in clojure )) )
>>
>> (ns ie4clj.api)
>>
>> (definterface Inferrable
>>   (^boolean eval [])
>>   (^boolean evalMembers [members]))
>>
>> (ns ie4clj.AndList)
>>
>> (when *compile-files*
>>   (require 'ie4clj.api))
>>
>> (def AndList
>>   (reify
>>ie4clj.api.Inferrable
>>(eval [_] true)
>>(evalMembers [_ m] true)))
>>
>> Hope this helps,
>>
>>
>>
>> On Sat, 17 Jul 2021 at 21:06, Jack Park  wrote:
>>
>>> I created a gist
>>> https://gist.github.com/KnowledgeGarden/39742ae9ae641f0d8facb31b288ece4c
>>>
>>> which explains a ClassNotFoundException when I am importing and reifying 
>>> a particular interface in another clj file.
>>>
>>> It's really baffling because, in the load order, core calls a test in a 
>>> test file - getting that to compile landed on the solution of an (:import 
>>> ...) statement; once that worked, then the code in that test calls another 
>>> file AndList.clj which happens to have several places where it reifies the 
>>> same interface. Except, with the same import statement, on that file, I get 
>>> the error.  Difficult to even find a decent StackOverflow because one such 
>>> StackOverflow appears to be very similar, and the suggested fix is what I 
>>> have now.
>>>
>>> Thanks in advance for ideas.
>>> Jack
>>>
>>> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/clojure/ffb09a94-5aa4-4600-8c9a-e0d00901df72n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email 

Re: Reporting Potential Security Vulnerabilities in the Clojure Codebase

[Alex Miller]

If you want to report something privately, you can email it to 
cloj...@cognitect.com.

Alex


On Saturday, July 17, 2021 at 2:21:56 PM UTC-5 William Blair wrote:

>
> Does the Clojure project have a protocol in place for reporting potential 
> security vulnerabilities found in the runtime? I'd be happy to share a 
> proof of concept I have so that the developers can assess whether or not 
> what I've found is a true vulnerability. 
>

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

Re: deps.edn dependency whose name starts with a number

['Alex Miller' via Clojure]

I don't think there is any workaround for this, it's the first time I've 
seen someone run into this. I'll log it and think about a solution.

On Saturday, May 15, 2021 at 6:22:41 PM UTC-5 zk wrote:

> Is there a way to specify a dependency whose name starts with a number? 
> For example:
>
> ```
> {:deps {com.github.2captcha/2captcha-java {:mvn/version "1.0.1"}}}
> ```
>
> will error with
>
> ```
> Error building classpath. Error reading edn. Invalid token: 
> com.github.2captcha/2captcha-java (/Users/zk/code/monorepo/web/deps.edn)
> ```
>
> due to the fact that symbols can't start with a numeric character.
>
> I've tried using a string in its place but no dice. I couldn't find 
> anything in the documentation on how to resolve this. Has anybody else run 
> into this situation?
>

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

State of Clojure 2021 survey results

['Alex Miller' via Clojure]

Read all about it here!

https://clojure.org/news/2021/04/06/state-of-clojure-2021

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

Re: Unexpected "#_ - Discard" error

[Alex Miller]

The discard reader will read, then discard (so the following form still has 
to be readable). In this case, the 1:2 starts with a number so is parsed as 
one, but that's an invalid form.


On Saturday, April 3, 2021 at 8:50:49 AM UTC-5 zen...@gmail.com wrote:

> I'm reading https://clojure.org/guides/weird_characters#_discard and run 
> into this error:
>
> *user> #_({1:2})*
>
> *Syntax error reading source at (REPL:247:14).*
> *Invalid number: 1:2*
>
> Ty.
>

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

State of Clojure 2021 survey

['Alex Miller' via Clojure]

It's that time of year again! Please complete the State of Clojure 2021 
survey, an important tool for tracking our community over the last decade.

https://www.surveymonkey.com/r/clojure2021

Thanks!

Alex

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

Re: Documentation of clojure.string/split is confusing

['Alex Miller' via Clojure]

The best place to ask questions like this is at https://ask.clojure.org, 
which is the official forum to file requests/bug reports (and get turned 
into tickets after triage there).

It turns out you are not the first to point this out and it has already 
been filed at https://clojure.atlassian.net/browse/CLJ-1857 and was then 
duped to include changes in https://clojure.atlassian.net/browse/CLJ-1360 
which is still open. I will try to get that included in 1.11.

You can (and should!) vote for this issue 
at 
https://ask.clojure.org/index.php/4282/doc-that-clojure-string-split-strips-trailing-delimiters
 
(which is the ask.clojure question corresponding to that last ticket). 
Votes really do matter in our prioritization!

Alex

On Tuesday, January 12, 2021 at 2:17:28 PM UTC-6 oliver...@gmail.com wrote:

> Happy new year, folks.
>
> (Might not be the best place to post this, but I failed to find a better 
> one, please advise if there is. I've also tried to look for previous 
> comments about this. If there are, then my Google-fu was simply too weak.)
>
> https://clojuredocs.org/clojure.string/split says:
> --
> Usage:
> (split s re)
> (split s re limit)
>
> Splits string on a regular expression. Optional argument limit is the 
> maximum number of splits. Not lazy. Returns vector of the splits.
> --
>
> Where I initially understand "number of splits" to be the number of 
> matches acted upon, that's where a split occurs. I realize there's another 
> meaning of "split", meaning fragment, and that is the one meant here. 
> "Returns vector of the splits." hints at that as well, but it literally 
> says "splits string on..., ... maximum number of splits.".
>
> And even in the same docs a few lines later the example for this is 
> phrased like this:
> --
> ;; Note that the 'limit' arg is the maximum number of strings to
> ;; return (not the number of splits)
> user=> (str/split "q1w2e3r4t5y6u7i8o9p0" #"\d+" 5) ["q" "w" "e" "r" 
> "t5y6u7i8o9p0"]
> --
> Contradicting the upper description with "(not the number of splits)".
>
> I've run into this more than once now, because different languages do this 
> differently. Whenever I go to the documentation, I read the description and 
> am satisfied that I've grokked it, just to be mocked by my off-by-one code 
> minutes later.
>
> Does anyone agree that this might be worth changing?
> I think at least the contradiction in the example should be addressed, but 
> I think a better solution would be to rephrase the main description to be 
> unambiguous.
>
> I've also looked up a few documentations in other languages. Those that 
> limit the number of "splits" in my sense (number of matches at which to 
> split) use the word "splits", those with a behaviour similar to that of 
> Clojure explicitly talk about the maximum number of resulting 
> elements/substrings/strings, and I think that would make it much clearer.
>
> Apologies for the length!
>
> Cheerio
>   Oliver
>
>

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

Cognitect and Nubank are Sponsoring Open Source Developers

[Alex Miller]

https://cognitect.com/blog/2020/12/15/sponsoring-open-source-developers

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

Clojure 1.10.2-rc1

[Alex Miller]

Clojure 1.10.2-rc1 is now available. This is a release candidate and we 
would appreciate it if you could try it in your own projects. If you 
encounter issues, https://ask.clojure.org is the best place to file a 
report. Below is a changelog for 1.10.2 (items new to this release since 
1.10.2-alpha4 are marked with a *):


*1 Fixes1.1 Interop / JVM*
CLJ-1472 Ensure monitor object is on stack, for verifiers
CLJ-2517 More fixes for invocation of static interface methods with 
primitive args - thanks Nicola Mometto!
CLJ-2492 Remove uses of deprecated Class.newInstance()
CLJ-2534 Fix javadoc urls for JDK 11+ - thanks Andy Fingerhut!
CLJ-2571 Add Throwable return type hint to ex-cause - thanks Michiel 
Borkent!
CLJ-2572 Avoid reflection in clojure.data - thanks Michiel Borkent!
CLJ-2502 Fix reflection warnings in clojure.stacktrace/print-stack-trace - 
thanks Michiel Borkent!

*1.2 Core*
CLJ-2580 Fix case expression branch analysis that resulted in compilation 
error - thanks Ghadi Shayban!
CLJ-2564 Improve error message for case
CLJ-2585* nth with not-found on regex matcher returns not-found on last 
group index
CLJ-1364 vector-of does not implement equals or hashing methods
CLJ-2549 vector-of does not implement IObj for metadata - thanks Andy 
Fingerhut!
CLJ-1187 quoted metadata on empty literal colls is lost - thanks Nicola 
Mometto!
CLJ-2459* ExceptionInInitializerError if jars executed with java -jar - 
thanks Piotrek Żygieło!

*1.3 Printing*
CLJ-2469 Fix errors in printing some maps with namespace syntax
CLJ-1445* pprint doesn't print collection metadata when *print-meta* is true

*1.4 Docstrings*
CLJ-2295 Eliminate duplicate doc string printing for special forms - thanks 
Andy Fingerhut!
CLJ-2495* prepl docstring is incorrect
CLJ-2169* conj has out-of-date :arglists - thanks Michał Marczyk!

*2 Performance*
CLJ-1005* Use transient map in zipmap - thanks Michał Marczyk!

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

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

[Alex Miller]

These changes are in the new 1.10.1.693 prerelease of clj if you want to 
test it. Assuming things look good, I'll promote that to a stable release 
soon.

In this release, things will be ordered :extra-paths (in order, if used), 
then :paths (in order, if used), then libs. That reverts the changes in the 
release that led to the issue here.

Additionally, libs are now sorted by tree depth (roots first, then their 
deps, etc), then alpha per depth so this should greatly improve 
reproducibility of lib ordering across builds.




On Monday, September 14, 2020 at 7:51:07 AM UTC-5 Alex Miller wrote:

> Just FYI, we have a plan to address this and it should be in the next 
> stable version.
>
> On Sep 14, 2020, at 1:00 AM, 'bed...@yahoo.com' via Clojure <
> clo...@googlegroups.com> wrote:
>
> 
>
> I couldn't agree more.
>
> It really boils down to the simple fact that class loading in the JVM - 
> for the standard classloaders - is well-defined.
>
> If a build tool is not able to reflect this, it is an unreliable build 
> tool. It doesn't matter if anyone thinks CLASSPATH order shouldn't matter 
> from a philosophical point of view. (And inconveniencing deps.edn users to 
> go tell the authors of dependencies to "fix their resources" is not a 
> realistic approach)
>
> Providing dependencies in an unsorted map like deps.edn is doing now is 
> inherently unstable. 
> That doesn't necessarily make deps.edn unusable, but - as others have 
> pointed out - a source of surprising errors.
> Until an order is defined that survives changing OS/JVMs, I will advise 
> anyone to not use deps.edn.
>
> Furthermore, all build tools - with the exception of Bazel and derivates - 
> do rely on transitive dependency resolution and thus also are inherently 
> fragile.
> But either through established practices or defined standards: they offer 
> a way to define an order should conflicts arise.
> (Take a look at https://issues.apache.org/jira/browse/MNG-1412 again for 
> a longer discussion).
>
> At the very least: The location of your own classpath entries must be 
> well-defined. They are by default first on regular CLASSPATH.
> I wasn't following the latest development on this, but I would assume that 
> is a reasonable demand and has been fixed in newer tools.deps versions?
>
> Thanks,
>  Jochen
>
> On Sunday, September 13, 2020 at 8:37:31 AM UTC-7 Matching Socks wrote:
>
>> Too fragile.  This reminds me of the notion of "situated programming", 
>> featured in the talk by Rich Hickey:  you and your programs operate in the 
>> middle of a bizarre and changing situation.  For Clojure, the Java 
>> ecosystem is part of that situation.  Even if some jars do not overlap 
>> today, you will be forced to take a minor update someday that introduces a 
>> clash.  Or perhaps (quite likely) jars do overlap today, but you will take 
>> a minor update someday that causes the classpath to emerge from the 
>> hash-map differently and your program won't work anymore.  The insight of 
>> the theory of "situated programs" is, not to hit a cliff when a perfectly 
>> legal quirk arises in the situation.
>>
>>> -- 
>
> 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 a topic in the 
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/WI3ddZRK4Bg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+u...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clojure/e229b29e-304d-4e96-bf26-59b255e3920bn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/clojure/e229b29e-304d-4e96-bf26-59b255e3920bn%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/5af9b933-ad9a-413f-96cb-3350dfaf7990n%40googlegroups.com.

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

['Alex Miller' via Clojure]

Just FYI, we have a plan to address this and it should be in the next stable 
version.

> On Sep 14, 2020, at 1:00 AM, 'bed...@yahoo.com' via Clojure 
>  wrote:
> 
> 
> I couldn't agree more.
> 
> It really boils down to the simple fact that class loading in the JVM - for 
> the standard classloaders - is well-defined.
> 
> If a build tool is not able to reflect this, it is an unreliable build tool. 
> It doesn't matter if anyone thinks CLASSPATH order shouldn't matter from a 
> philosophical point of view. (And inconveniencing deps.edn users to go tell 
> the authors of dependencies to "fix their resources" is not a realistic 
> approach)
> 
> Providing dependencies in an unsorted map like deps.edn is doing now is 
> inherently unstable. 
> That doesn't necessarily make deps.edn unusable, but - as others have pointed 
> out - a source of surprising errors.
> Until an order is defined that survives changing OS/JVMs, I will advise 
> anyone to not use deps.edn.
> 
> Furthermore, all build tools - with the exception of Bazel and derivates - do 
> rely on transitive dependency resolution and thus also are inherently fragile.
> But either through established practices or defined standards: they offer a 
> way to define an order should conflicts arise.
> (Take a look at https://issues.apache.org/jira/browse/MNG-1412 again for a 
> longer discussion).
> 
> At the very least: The location of your own classpath entries must be 
> well-defined. They are by default first on regular CLASSPATH.
> I wasn't following the latest development on this, but I would assume that is 
> a reasonable demand and has been fixed in newer tools.deps versions?
> 
> Thanks,
>  Jochen
> 
>> On Sunday, September 13, 2020 at 8:37:31 AM UTC-7 Matching Socks wrote:
>> Too fragile.  This reminds me of the notion of "situated programming", 
>> featured in the talk by Rich Hickey:  you and your programs operate in the 
>> middle of a bizarre and changing situation.  For Clojure, the Java ecosystem 
>> is part of that situation.  Even if some jars do not overlap today, you will 
>> be forced to take a minor update someday that introduces a clash.  Or 
>> perhaps (quite likely) jars do overlap today, but you will take a minor 
>> update someday that causes the classpath to emerge from the hash-map 
>> differently and your program won't work anymore.  The insight of the theory 
>> of "situated programs" is, not to hit a cliff when a perfectly legal quirk 
>> arises in the situation.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/WI3ddZRK4Bg/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/e229b29e-304d-4e96-bf26-59b255e3920bn%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/C283D14D-A5E9-4EF9-AB3E-AAF816200C26%40puredanger.com.

Re: core.async buffers alternative backend

[Alex Miller]

I don't actually remember now, but it's possible that when core.async was 
created we were still trying to accommodate an older version of Java before 
some of those existed. That's not an issue now as we only need to support 
Java 1.8+. So, I don't know of any reason these wouldn't be an option. 
Would be happy to see a core.async issue and/or patch (may need to sign the 
CA and become the contributor first).

On Thursday, September 10, 2020 at 8:14:53 AM UTC-5 Jim foo.bar wrote:

> Hi folks, 
>
> `LinkedList` is used as the underlying data-structure for all core.async 
> buffers. However, looking closer reveals that what is really needed is a 
> `Deque` (for its .addFirst/.removeLast methods). So naturally then it 
> begs the question - why not `ArrayDeque` [1]? It should offer superior 
> insertion/removal/traversing performance, and in the context of 
> core.async it will never be resized (if initialised with `n`). 
>
> And since we're on the subject, why not even go crazy with a 
> (thread-safe) `ConcurrentLinkedDeque` [2] ? Leaving the counting 
> complication aside for a moment (something which I wouldn't mind 
> feedback on), having a thread-safe buffer opens up the door to safe 
> buffer snapshots. 
>
> Anything wrong with either of those approaches? Many thanks in advance... 
>
> Kind regards, 
>
> Dimitris 
>
> [1]: 
>
> https://github.com/jimpil/asynctopia/blob/master/src/asynctopia/buffers/array.clj
>  
>
> [2]: 
>
> https://github.com/jimpil/asynctopia/blob/master/src/asynctopia/buffers/thread_safe.clj
>  
>
>
>
>

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

Re: Clojure tools-deps Docker image versions & stable releases

['Alex Miller' via Clojure]

On Thursday, August 13, 2020 at 10:32:45 AM UTC-5 cap10...@gmail.com wrote:

> I was recently made aware in a separate thread in this group* that, until 
> very recently, the tools-deps versions that were being installed via the 
> main Homebrew tap's clojure installer included some versions considered 
> unstable. As of the day I'm writing this, the latest stable version is 
> 1.10.1.561.
>
> I had been updating the official clojure:tools-deps (& :latest since it 
> includes all three build tools we support) Docker image when that Homebrew 
> build updated, but am now planning to take steps to revert back to stable 
> versions only.
>
> So, I have a couple of questions:
>
> 1. For Alex Miller or other Cognitect folks: What's the best place to 
> monitor for new stable tools-deps releases (to trigger Docker image 
> updates)? Are updates to Cognitect's clojure/tools/clojure Homebrew tap 
> sufficient?
>

To answer the last question first, no - we update prerelease versions there 
all the time and those generally shouldn't be used to build new images (and 
sometimes there are manual changes too).

For current stable version, you can watch either:

https://github.com/clojure/homebrew-tools/blob/master/Formula/clojure.rb 
(the actual formula) or
https://github.com/clojure/brew-install/blob/1.10.1/stable.properties (the 
data file)
 

> 2. Does anyone have a need for Docker images with unstable tools-deps 
> versions? I'm not planning on building them unless the community has a need 
> for them. If I do build them, they would be available under 
> version-specific tags (e.g. clojure:tools-deps-1.10.1.619) but the 
> clojure:tools-deps tag would get you the latest stable release.
>

I don't think it's relevant to have every one of them for sure. I sometimes 
release multiple per day even. People might occasionally need a prerelease 
version, don't know. I'm hoping not to make the gaps too large between 
stable versions. The goal of the prereleases is really tire kicking and 
feedback on imminent stuff, but don't I expect it to get too for off of 
stable.
 

> It's also worth pointing out that the unstable versions we've already 
> released won't disappear, so if you're using them, feel free to continue. 
> If you want to ensure you stay on that version, be sure to specify it in 
> your image tag (e.g. in the FROM line of your Dockerfile).
>
> * Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main 
> <https://groups.google.com/u/2/g/clojure/c/WI3ddZRK4Bg>
>

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

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

['Alex Miller' via Clojure]

FYI, I've been working with the homebrew team today and homebrew-core now 
points to the latest stable clojure tools version and will track that 
automatically going forward.


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

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

['Alex Miller' via Clojure]

On Tue, Aug 11, 2020 at 6:41 PM 'bed...@yahoo.com' via Clojure <
clojure@googlegroups.com> wrote:

> Just 2 quick points before I go back to migrate to shadow-cljs & leiningen
> ;)
>
> "just does not seem well defined "
> This is not a line of argument you want to pursue when we are talking
> about maven, who has had a stable order for what feels like decades now.
> If you need a current link:
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
> (search for "first")
>

I understand it may feel like that to you, but I have been using Maven for
at least 15 years and have spent a lot of time fighting classpath ordering
issues while using it. That link says nothing about classpath order and I
spent some more time today looking for something like that, without
success. There are plenty of Maven tickets about this, it's changed over
the years, and a lot of complexity to cover when you start to consider
parent poms, dependency management, etc. I don't think it's as fixed as you
think it is, probably more that they just don't touch it much (and most
differences don't actually matter). It may be stable largely by fear.


> To your comment re Intellij: you can actually use Intellij to build and it
> uses its own project configuration to do that and cobble together the
> classpath (in many cases it merely syncs with maven/lein etc.). In a way,
> Intellij acts like clj: It builds a classpath and runs stuff.
>

Yeah, I use it every day. My point was just that it's independent from what
we're talking about.


> Also, arguing that "JARs need to be fixed" is interesting,  as I can get
> *any* resource with `(io/resource...)` and will get different answers
> depending on CLASSPATH order.
>

You can only get different answers if two roots have the same resource,
which again, is bad, and the cause of a big percentage of dependency issues
I've tracked down at one point or another. Same resource = shadowing =
eventually you will reorder your deps and see something different.


> If that order changes in between minor versions of clj, that makes it an
> unstable build system.
>

I'd say if that's coming from dependencies, then it's your build deps that
are unstable, you just didn't know it. The ordering of project paths before
deps is a separate issue.


> Just try to io-resource '/log4j.properties', for funsies. If in version A
> of clj I'm getting my own /log4j.properties and in version I'm getting the
> one from some other JAR, it's a problem.
>
> If I run
> find . -name "*.jar" -exec unzip -l {} \; | awk '{print $4}' | sort | less
> in ~/.m2
> to crudely get all file names for all my cached jars,
> I can find 4 instances of 'public/index.html'
> 3 of 'public/css/style.css' etc. etc.
>

You are proving my point. That's all broken. Those libs cannot control
where they are placed in an application's classpath and whether they will
shadow or be shadowed by something else. They are time bombs waiting to
break your build. You should complain to their creators.


> Please return to at least having :paths at the front of the CLASSPATH.
>

As I said, that's a different issue and I'm inclined to agree with you. The
details of changing it are more complicated than it appears.

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

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

['Alex Miller' via Clojure]

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 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 'c

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

['Alex Miller' via Clojure]

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

['Alex Miller' via Clojure]

Just to beat the horse...

On Tue, Aug 11, 2020 at 1:05 PM 'bed...@yahoo.com' via Clojure <
clojure@googlegroups.com> wrote:

> Changing the order of classpath entry and not having paths be at the
> beginning of the CLASSPATH will break existing code that uses `(io/resource
> ...)` to load resources from the CLASSPATH.
> While in theory the order of the classpath should not matter, in practice
> it does, often involuntarily.
>

Just to reiterate so it's clear, this is bad, at least for deps and usually
for most other uses. That's why we provide features in deps.edn to
encourage you to be specific when you are overriding something that exists
in the classpath rather than relying on an ordering mechanism. If there is
a use case where shadowing is a feature and not a bug that is not already
covered, I'd be interested in hearing about it.


> Fighweel-main's default behavior is to load `public/index.html` which
> works fine if the local paths come first, but will fail if any other JAR
> has a `public/index.html` resource.
>
> And as we learned, they do!
>

This is bad, and we should loudly complain about it to whoever is doing it,
not just accept it. (It's probably accidental, not intentional.)


> Please consider going back to the old, defined behavior.
>

I am considering options.


> All other build tools I know have - for good or bad - a defined CLASSPATH
> order.
>

Do they? I'm not aware of documentation about or guarantees for this with
either lein or Maven but would love to be pointed at those docs if you're
aware of something. Both Maven and lein have considered how to make builds
repeatable/reproducible, but I'm actually not aware that the order is well
defined and documented (and I have looked).

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

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

['Alex Miller' via Clojure]

Bunch of things here...

Clojure maintains its own brew tap and a "stable" release that you can 
obtain with `brew install clojure/tools/clojure` (the brew conventions 
automatically find the prior repo based on that). That tap also includes 
prerelease unstable versions that can be obtained with "@version" - more on 
that is doc'ed in the readme for that repo. The current stable version is 
1.10.1.561.

Homebrew core is what you are pulling from if you just do `brew install 
clojure`. The formula there is no longer maintained by the Clojure team as 
anyone can update it (and have, with changes we did not agree with). There 
is no "ownership" model in homebrew-core. I would happily remove it from 
there but they said they would not accept that PR. Recently, the 
homebrew-core formula has been updated by members of the homebrew team to 
newer prerelease (not yet stable) versions of clj. There is not really 
anything we can do about this.

The classpath difference is interesting. The classpath is a set of path 
roots and in general the files in these paths should be mutually exclusive. 
If the roots are mutually exclusive, then the classpath order is 
unimportant (as the JVM will always find the same class/clj/resource file 
regardless). Roots that include the same file are nearly always trouble and 
the source of "jar hell" style problems. clj and deps.edn provide features 
to cover most of the scenarios where users are typically tempted to use 
ordering for replacement (:override-deps, :classpath-overrides, etc).

Based on this, we did knowingly make a change since the last stable release 
that effectively made the classpath unordered (all the roots go through 
keys of a map at one point). To date, I had not seen any issues with that, 
so this is a useful data point we can take into consideration. I assume 
you're getting an index.html out of some library that's either unimportant 
or accidentally included. For now, I'd recommend that you continue using 
the latest stable version from the official Clojure homebrew tap.

Re the version - you can see the version with either `clj -h` (first line) 
or `clj -Sdescribe`. 

Relevant links:

* Clojure homebrew tap - https://github.com/clojure/homebrew-tools
* Official clj stable formula - 
https://github.com/clojure/homebrew-tools/blob/master/Formula/clojure.rb 
(what you get with `brew install clojure/tools/clojure`)
* Getting started/install doc - https://clojure.org/guides/getting_started
* Homebrew core - https://github.com/Homebrew/homebrew-core
* clj reference - https://clojure.org/reference/deps_and_cli (or see `clj 
-h` or `man clj`)


On Monday, August 10, 2020 at 7:04:40 PM UTC-5 cloo...@gmail.com wrote:

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

Re: DEPRECATED: Libs must be qualified, change cljfmt => cljfmt/cljfmt (~/.clojure/deps.edn)

['Alex Miller' via Clojure]

Hi, couple things here...

First, for information on this change you can see the section at the very 
end of this blog: https://insideclojure.org/2020/07/28/clj-exec/ - probably 
best to read that and then I can answer any follow-ups as I tried to 
explain there.

Second, this is only in a preview release of clj and has not been promoted 
to the stable release yet (you can find both at the official Clojure 
Homebrew tap (https://github.com/clojure/homebrew-tools). The core homebrew 
tap is not being updated by the Clojure team anymore and it seems someone 
has updated it past the newest stable release of `clj` so using the core 
tap may be giving you preview releases. So, use the official tap!

Alex


On Thursday, August 6, 2020 at 12:19:31 PM UTC-5 ben.k...@gmail.com wrote:

> I've started seeing a lot of messages like this, I think after I updated 
> clojure, but I can't find any documentation or points in the changelog 
> about the change, why I'm getting this message, or what the correct fix is. 
> I know it provides a change I can make, but is it the right one?
>
> Some examples deps.edn that come up in this message:
>
> ~/.clojure/deps.edn
>
> {:aliases
>  {:runner
>   {:extra-paths ["test"]
>:extra-deps {com.cognitect/test-runner
> {:git/url "
> https://github.com/cognitect-labs/test-runner.git;
>  :sha "209b64504cb3bd3b99ecfec7937b358a879f55c1"}}
>:main-opts ["-m" "cognitect.test-runner"]}
>
>   :fmt
>   {:extra-deps {cljfmt {:mvn/version "0.6.4"}}
>:main-opts ["-m" "cljfmt.main"]}
>
>   :srepl
>   {:jvm-opts 
> ["-Dclojure.server.repl={:port,,:accept,clojure.core.server/repl}"]}
>
>   :prepl
>   {:jvm-opts 
> ["-Dclojure.server.repl={:port,,:accept,clojure.core.server/io-prepl}"]}
>
>   :rebel {:extra-deps {com.bhauman/rebel-readline {:mvn/version "RELEASE"}}
>   :main-opts ["-e" "(use,'clojure.repl)"
>   "-m" "rebel-readline.main"]}
>
>   :nrepl {:extra-deps {nrepl {:mvn/version "RELEASE"}}
>   :main-opts ["-m" "nrepl.cmdline"]}
>
>   :cider
>   {:extra-deps {cider/cider-nrepl {:mvn/version "RELEASE"}}
>:main-opts ["-m" "nrepl.cmdline"
>"--middleware" "[cider.nrepl/cider-middleware]"]}
>
>   :ciders
>   {:extra-deps {org.clojure/clojurescript {:mvn/version "RELEASE"}
> cider/cider-nrepl {:mvn/version "RELEASE"}
> cider/piggieback {:mvn/version "RELEASE"}}
>:main-opts ["-m" "nrepl.cmdline"
>"--middleware" 
> "[cider.nrepl/cider-middleware,cider.piggieback/wrap-cljs-repl]"]}}}
>
>
> Project specific deps.edn:
>
> {:deps
>  {hiccup {:mvn/version "1.0.5"}
>   ring {:mvn/version "1.8.0"}
>   compojure {:mvn/version "1.6.1"}}
>
>  :aliases
>  {:spec
>   {:extra-paths ["classes" "spec"]
>:extra-deps {speclj
> {:git/url "https://github.com/kyptin/speclj;
>  :sha "a843b64cc5a015b8484627eff6e84bbac2712692"}}
>:main-opts ["-m" "speclj.cli"]}
>
>   :runner
>   {:extra-paths ["test"]
>:extra-deps {com.cognitect/test-runner
> {:git/url "
> https://github.com/cognitect-labs/test-runner.git;
>  :sha "209b64504cb3bd3b99ecfec7937b358a879f55c1"}}
>:main-opts ["-m" "cognitect.test-runner"]}
>
>   :fmt
>   {:extra-deps {cljfmt {:mvn/version "0.6.4"}}
>:main-opts ["-m" "cljfmt.main"]}
>
>   :explore-test
>   {:extra-deps {clj-http {:mvn/version "3.10.0"}
> org.clojure/core.async {:mvn/version "1.1.587"}
> org.clojure/data.json {:mvn/version "1.0.0"}
> enlive {:mvn/version "1.1.6"}}
>:main-opts ["-m" "jst-explore-test-a6"]}}}
>
>
> Perhaps the biggest question is—some of the deps are already qualified 
> (com.cognitect/test-runner); doesn't that mean cljfmt/cljfmt may not be the 
> right qualified form?
>
> Additionally, I would love to know
> - where this is documented
> - what changed, and why
>

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

Re: Optimizaton for finding the next key in a sorted-map

['Alex Miller' via Clojure]

Hi, there is no such optimization and that's not really feasible in the 
sorted-map impl. However there are other sorted map data structures like 
https://github.com/clojure/data.avl which have facilities in this area.

On Monday, May 25, 2020 at 4:47:58 PM UTC-5, Harmon Nine wrote:
>
> Is there an optimization for sorted-maps that, when you have a given key 
> in the map, you can get the next key in O(log n) time?
>
> Given "compare" is the boolean function on which the sorted-map is based, 
> the following code will get the next-key given a current-key:
>
> (defn get-next-key [my-map current-key]
>   (first (filter #(compare current-key %) (keys my-map
>
>
> In the worst case, this would take O(n) time, as the "keys" function would 
> iterate through the n keys of the map.
>
> However, if it could be detected that the the filter is using the 
> "compare" function on which the map is based, this could speed up the 
> search:  the "current-key" could be found first and iteration could start 
> from there.  Then the "first" function could cut the search short, 
> resulting in worst-case O(log n) time to get the next key (given the 
> sorted-map is based on a tree).
>
>
> Does such an optimization exist?  If not, is there an means of getting the 
> next-key in a sorted-map given a current-key that is better than O(n)?
>
> 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/66b516c0-e4f6-46c4-9820-48fe449c885d%40googlegroups.com.

Re: HP Fortify Security Scanner and Clojure

['Alex Miller' via Clojure]

Most Clojure classes cannot be decompiled to Java (locals clearing is all 
over it and has no Java equivalent, just as one problem, there are others).

Some people have tried this with Fortify and other bytecode oriented 
scanners but I don't know of anyone that's gotten any results that were 
useful.

On Thursday, April 2, 2020 at 5:33:50 PM UTC-5, Didier wrote:
>
> Reviving an old topic here, does anyone know of a Clojure 1.10 compatible 
> security analysis tool? I too thought of just decompiling the .class to 
> Java. It also appears Fortify can run on bytecode only, so I might give 
> that a try if I can't find anything else.
>
> Regards
>
> On Wednesday, 21 October 2015 15:14:31 UTC-7, Alex Miller wrote:
>>
>> In general, Clojure code cannot be decompiled from .class to .java as the 
>> Clojure generated bytecode does things that cannot be represented in Java. 
>> The particular issue below looks like the local-clearing code. It is 
>> possible to turn that off during compilation, however there are likely 
>> other things as well that cannot be decompiled satisfactorily.
>>
>> FindBugs works directly from bytecode (not source code) so might be more 
>> amenable for this kind of analysis. There is a sonar plugin (
>> https://github.com/zmsp/sonar-clojure) which uses Eastwood and Kibit 
>> that might also be useful.
>>
>> FYI, Clojure is registered in CVE with id CVE-2015-4653 (although there 
>> are no reports registered yet). I gather that it is useful to create at 
>> least one such thing to make it searchable and I have that on my todo list 
>> (although it's not a high priority). 
>>
>> Alex
>>
>>
>> On Wednesday, October 21, 2015 at 3:41:21 PM UTC-5, ryan medlin wrote:
>>>
>>> A customer requires that we scan our clojure projects with this tool:
>>>
>>> http://www8.hp.com/us/en/software-solutions/static-code-analysis-sast/
>>>
>>>
>>> They must get some meaningful report from this.
>>>
>>> So I thought, well why don't I compile and then decompile the class 
>>> files and then scan those to at least give them something.
>>>
>>> However when I do that I get a TON of high security issues in multiple 
>>> dependencies (ring, clojure.core)
>>>
>>> Here is the most prevalent:
>>>
>>> https://cwe.mitre.org/data/definitions/476.html
>>>
>>> /* */ package nio;
>>> /* */ 
>>> /* */ import clojure.lang.AFunction;
>>> /* */ import clojure.lang.IFn;
>>> /* */ import clojure.lang.RT;
>>> /* */ import clojure.lang.Var;
>>> /* */ import java.nio.Buffer;
>>> /* */ import java.nio.ByteBuffer;
>>> /* */ 
>>> /* */ public final class core$fn__1869 extends AFunction
>>> /* */ {
>>> /* 284 */   public static final Var const__0 = 
>>> (Var)RT.var("clojure.core", "make-array");
>>> /* */ 
>>> /* */   public Object invoke(Object x)
>>> /* */   {
>>> /* 297 */ x = null; Object x = ((ByteBuffer)x).duplicate();
>>> /* 298 */ Object array = 
>>> ((IFn)const__0.getRawRoot()).invoke(Byte.TYPE, 
>>> Integer.valueOf(((Buffer)x).remaining()));
>>> /* 299 */ x = null; ((ByteBuffer)x).get((byte[])array); array = 
>>> null; return array;
>>> /* */   }
>>> /* */ }
>>>
>>>
>>> Decompiler:
>>>
>>> http://jd.benow.ca/
>>>
>>> Id the decompiler somehow generating code with these security issues and 
>>> the actual bytecode does not have them maybe?
>>>
>>>
>>> I have no idea how to move forward with this.  We have to "check a box" 
>>> for them in corporate speak yet there is no clear path to run a dependable 
>>> security scan against the codebase.
>>>
>>>
>>> Yes I realize this is silly to demand running this tool.
>>>
>>> Any other tools out there that might be able to scan Clojure code like 
>>> this?
>>>
>>>
>>>
>>>

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

Re: Emacs-cider

['Alex Miller' via Clojure]

It would probably help to include any error information for someone to 
learn more about the problem.

On Friday, March 13, 2020 at 1:54:40 PM UTC-5, Duke wrote:
>
> The emacs-cider combo chokes with an error to the effect that cider-nrepl 
> could not be loaded.
> I'm on a Win10 box. Would someone point m to a possible solution please. 
> Thx.
>

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

Re: [ANN] Clojure 1.10.2-alpha1

['Alex Miller' via Clojure]

Generally, you don't explicitly download it at all - you should just change 
your dependency in your project.clj to use 

[org.clojure/clojure "1.10.2-alpha1"] 

and then leiningen will download it for you into your local Maven 
repository (usually in ~/.m2/repository).


On Friday, March 13, 2020 at 1:54:40 PM UTC-5, Duke wrote:
>
> Thanks for the  heads up!  Need some advice though - if I may. Being a 
> clojure/lein newbie, I'm not sure how to tell Lein that I've just DLed the 
> latest, bleeding-edge version of clojure.  And while I'm at it, to what 
> directory on my Win10 box should I have DLed 1.10.2-alpha1 to?  Thanks in 
> advance!
>

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

Re: Clj on Win: Error building classpath

['Alex Miller' via Clojure]

Hi Daniel, sorry you're having troubles. This error typically occurs if the 
artifact metadata can't be downloaded from the central Maven repository. 
Any chance you have a network proxy or something like that?

The file it should be trying to download is this one: 
https://repo1.maven.org/maven2/org/clojure/clojure/1.10.1/clojure-1.10.1.pom

If you do need a proxy setup, there are docs on this at 
https://clojure.org/reference/deps_and_cli if you search for "Maven 
proxies" there.

Alex


On Tuesday, March 10, 2020 at 7:23:38 AM UTC-5, Daniel G. Gamonal wrote:
>
> I tried on https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Windows
>
> Some tweaking after, I'm stuck at:
>
>
> I've done a quick search and found nothing, also did on 
> https://dev.clojure.org/jira/browse/TDEPS and provided same feedback.
>
> Now I'm going to try alternatives as online REPL for the sake of getting 
> started.
>
> Hope someone can help, thank you very much.
>
> Best regards.
>

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

Re: Register to the International Clojure Data Science Meetup in Berlin on 27th of February

['Alex Miller' via Clojure]

I don't know if it makes sense, but might be worth updating the clojure.org 
event page at https://clojure.org/events/2020/clojured  (PR to 
https://github.com/clojure/clojure-site/blob/master/content/events/2020/clojured.adoc).

On Tuesday, December 17, 2019 at 8:59:30 AM UTC-6, Sami Kallinen wrote:
>
> The registration for The International Clojure Data Science Meetup in 
> Berlin on 27th of February, a few days before ClojureD, is now open. It is 
> a meetup about improving the Clojure Data Science story. Clojure is a 
> fantastic language for data, yet the data science ecosystem still needs 
> some love. A bunch of us are busy with it. Join us if you have a dual crush 
> on Clojure and data, or if you are just curious! Please register at 
> https://ti.to/scicloj/international-clojure-data-science-meetup-in-berlin
>

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

Re: Clojure 1.10 "Illegal Reflective Access Operation"

[Alex Miller]

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.

Re: A controversial call to bump libraries from 0.x to 1.0

[Alex Miller]

I think you are misinterpreting what people believe the 0.x to 1.x means. 
In the wide world of semver, 0.x indicates "unstable" and 1.x indicates 
"first stable"- you're conflating that special case with a general n.x to 
n+1.x which is interpreted as "breaking change". (See https://semver.org/ 
#4 and #8)

In this case, these contrib libraries at least are already stable and have 
been so for years. Moving from 0.x to 1.x is recognition of that for those 
with the above interpretation.


On Tuesday, February 18, 2020 at 7:46:20 PM UTC-6, Matching Socks wrote:
>
> Dear August Forum:  Today I noticed a new post on "Inside Clojure" 
> https://insideclojure.org/2020/02/18/lib-version/ , which says, after 
> some thoughtful justification, "we have lots of libraries in the Clojure 
> ecosystem that have been around for many years, are widely used, have 
> stable APIs, and yet are 0.x version. It’s silly for that to be (falsely) 
> indicating to people not to use them, so I have asked Clojure contrib 
> library owners to more actively bump up their library versions."
>
> A 0.x version number is a badge of honor; earned, not bestown.  It is one 
> of the things that makes Clojure stand out.  Let's not throw it away.
>
> If 0.x's -- at org.clojure and beyond -- renumbered themselves as 1.x's, 
> it would set off years of annoying aftershocks as a massive 
> dependency-update churn rippled far and wide.
>
> And still, people who don't like quiet would complain, "Clojure is fine, 
> but most of the libraries never got past 1.0."  You can't outrun that mob.  
> Stand firm.  If complaints about stasis are going to happen, better they 
> happened to 0.x than 1.x.  You can at least defend 0.x on principle.
>
> In short, I hope maintainers will defer the 0.x to 1.x transition until 
> they must commit a breaking or major change.
>

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

Re: [ANN] Cognitect Labs' aws-api 0.8.430

[Alex Miller]

There is no public repo for it, but the source is in the jar.

https://repo1.maven.org/maven2/com/cognitect/http-client/0.1.104/http-client-0.1.104.jar

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

Re: Clojure has been selected to participate in GSoC 2017!

[Alex Miller]

Having this discussion under the topic GSOC 2017 is increasingly confusing 
(given that it's now not GSOC or 2017), so I'd suggest starting a new 
thread if there is more to talk about...

On Monday, February 3, 2020 at 5:53:31 PM UTC-6, Daniel Slutsky wrote:
>
> Hi.
>
> Wanted to update that I decided not to be involved in GSoC 2020.
>
> Another option, similar and different, that some of us are discussing 
> elsewhere is Rails Girls SoC 2020.
> https://railsgirlssummerofcode.org
> https://railsgirlssummerofcode.org/about/
> I like the idea that it actively seeks diversity, and that it is possible 
> to submit a concrete open source project as a suggestion.
>
>
> On Sunday, 12 January 2020 09:03:05 UTC+2, Daniel Slutsky wrote:
>>
>> To summarize the GSoC 2020 discussion so far:
>> - Several individuals seem to be interested.
>> - Alex Miller described some past experience and lessons. 
>> - .. and explained what is required to make it happen.
>> - Daniel Compton and Clojurists Together offered their administrative 
>> help.
>> - We need a small group or person to take the commitment of making it 
>> happen.
>> - Some of us (like me) are thinking about it, not sure yet, and will 
>> decide in few weeks.
>>
>>
>> On Sunday, 12 January 2020 01:49:13 UTC+2, Daniel Slutsky wrote:
>>>
>>> GSoC 2020 has been announced.
>>> https://summerofcode.withgoogle.com
>>> https://summerofcode.withgoogle.com/how-it-works/#timeline
>>>
>>>
>>> On Thursday, 5 December 2019 00:05:12 UTC+2, Alex Miller wrote:
>>>>
>>>> Outreachy seems like a great program but like most things, it requires 
>>>> significant time and money (https://www.outreachy.org/mentor/). 
>>>>
>>>> They need an organization coordinator who can apply, find funds 
>>>> ($6500/intern), find mentors, help develop and assess projects. They also 
>>>> need mentors who are expected to spend 5-10 hrs/week for 6 weeks during 
>>>> the 
>>>> project.
>>>>
>>>> I'm not aware of anyone with the time or money to commit to an effort 
>>>> like this for Clojure. 
>>>>
>>>>
>>>> On Wed, Dec 4, 2019 at 3:51 PM Noor Afshan Fathima  
>>>> wrote:
>>>>
>>>>> Hello, 
>>>>> GSOC would be great. Can someone also look into getting Clojure to 
>>>>> participate in Outreachy? 
>>>>>
>>>>> On Wed, 4 Dec 2019 at 10:18 PM, Alex Miller  
>>>>> wrote:
>>>>>
>>>>>> As far as I'm aware the work involved here is:
>>>>>>
>>>>>> - submitting the organization application (in Jan)
>>>>>> - soliciting and writing up project ideas (in Jan/Feb)
>>>>>> - soliciting potential mentors for each project (often there is a 
>>>>>> natural match between idea and mentor) - spring
>>>>>> - pairing up selected students/projects and mentors - spring
>>>>>> - getting mentors to write evals for their students - summer
>>>>>> - accepting funds - fall
>>>>>> - if desired, distributing those funds in some way (when I helped 
>>>>>> Cognitect run it, we redistributed the funds to pay for students to 
>>>>>> travel 
>>>>>> to Clojure conferences) - fall
>>>>>>
>>>>>> Great opportunity for someone to contribute!
>>>>>>
>>>>>> On Wed, Dec 4, 2019 at 10:35 AM Daniel Compton <
>>>>>> daniel.co...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi folks, I'm the secretary of Clojurists Together.
>>>>>>>
>>>>>>> Thanks very much for the background on GSoC and the kind words Alex 
>>>>>>> :)
>>>>>>>
>>>>>>> Clojurists Together would be happy to help provide the backing admin 
>>>>>>> infrastructure (bank accounts, international payments, etc.) and 
>>>>>>> oversight 
>>>>>>> to help run GSoC. However, I don't think anyone on the committee has 
>>>>>>> the 
>>>>>>> bandwidth to be the primary person to lead the GSoC project; we'd need 
>>>>>>> someone from the community to volunteer to be that person.
>>>>>>>
>>>>>>> If someone else wants to run this as part of a different 
>>>>>>> organisat

Re: Bit rot and leiningen?

[Alex Miller]

What you're seeing here is a spec failure on macro specs that have been 
added in Clojure 1.9+ (tighter checks on code, so basically identifying 
existing silently wrong code).  Note that lein is itself a Clojure program 
with plugins and running on it's own version of Clojure, which can change 
independently of your app.

I think James' suggestion is a good one (the underlying core.unify issue 
was fixed and released years ago).

On Tuesday, February 4, 2020 at 9:56:47 AM UTC-6, James Reeves wrote:
>
> This may be due to the plugins overriding a dependency that Leiningen 
> itself needs. There was an issue like this 
>  logged with 
> Lein-Ring, which I notice you're using. Try updating the Lein-Ring version 
> to 0.12.5 and see if that fixes the issue.
>
> On Tue, 4 Feb 2020 at 13:18, 'Simon Brooke' via Clojure <
> clojure@googlegroups.com> wrote:
>
>> Hi all
>>
>> I recently wanted to do some work on a project of mine I've not worked on 
>> for more than a year, and found to my great surprise that it will no longer 
>> build. Full details of the bug are here 
>> , but the core seems 
>> to be:
>>
>> clojure.lang.Compiler$CompilerException: Syntax error macroexpanding 
>> clojure.core/fn at (clojure/core/unify.clj:83:18).
>> #:clojure.error{:phase :macro-syntax-check, :line 83, :column 18, :source 
>> "clojure/core/unify.clj", :symbol clojure.core/fn}
>>  at clojure.lang.Compiler.checkSpecs (Compiler.java:6971)
>>
>> ...
>>
>> Caused by: clojure.lang.ExceptionInfo: Call to clojure.core/fn did not 
>> conform to spec.
>> #:clojure.spec.alpha{:problems ({:path [:fn-tail :arity-1 :params], :pred 
>> clojure.core/vector?, :val clojure.core.unify/var-unify, :via 
>> [:clojure.core.specs.alpha/params+body :clojure.core.specs.alpha/param-list 
>> :clojure.core.specs.alpha/param-list], :in [0]} {:path [:fn-tail :arity-n], 
>> :pred (clojure.core/fn [%] (clojure.core/or (clojure.core/nil? %) 
>> (clojure.core/sequential? %))), :val clojure.core.unify/var-unify, :via 
>> [:clojure.core.specs.alpha/params+body 
>> :clojure.core.specs.alpha/params+body], :in [0]}), :spec 
>> #object[clojure.spec.alpha$regex_spec_impl$reify__2509 0x7c214cc0 
>> "clojure.spec.alpha$regex_spec_impl$reify__2509@7c214cc0"], :value 
>> (clojure.core.unify/var-unify [G__813 G__814 G__815 G__816] 
>> (clojure.core/if-let [vb__806__auto__ (G__816 G__814)] 
>> (clojure.core.unify/garner-unifiers G__813 vb__806__auto__ G__815 G__816) 
>> (clojure.core/if-let [vexpr__807__auto__ (clojure.core/and (G__813 G__815) 
>> (G__816 G__815))] (clojure.core.unify/garner-unifiers G__813 G__814 
>> vexpr__807__auto__ G__816) (if (clojure.core.unify/occurs? G__813 G__814 
>> G__815 G__816) (throw (java.lang.IllegalStateException. (clojure.core/str 
>> "Cycle found in the path " G__815))) (clojure.core.unify/bind-phase G__816 
>> G__814 G__815), :args (clojure.core.unify/var-unify [G__813 G__814 
>> G__815 G__816] (clojure.core/if-let [vb__806__auto__ (G__816 G__814)] 
>> (clojure.core.unify/garner-unifiers G__813 vb__806__auto__ G__815 G__816) 
>> (clojure.core/if-let [vexpr__807__auto__ (clojure.core/and (G__813 G__815) 
>> (G__816 G__815))] (clojure.core.unify/garner-unifiers G__813 G__814 
>> vexpr__807__auto__ G__816) (if (clojure.core.unify/occurs? G__813 G__814 
>> G__815 G__816) (throw (java.lang.IllegalStateException. (clojure.core/str 
>> "Cycle found in the path " G__815))) (clojure.core.unify/bind-phase G__816 
>> G__814 G__815)}
>>  at clojure.spec.alpha$macroexpand_check.invokeStatic (alpha.clj:705)
>>
>> ... 
>>
>>
>> No functions of mine occur anywhere in the stacktrace, but below all the 
>> clojure compiler functions I get to:
>>
>> clojure.lang.RestFn.invoke (RestFn.java:408)
>> leiningen.core.utils$require_resolve.invokeStatic (utils.clj:102)
>> leiningen.core.utils$require_resolve.invoke (utils.clj:95)
>> leiningen.core.utils$require_resolve.invokeStatic (utils.clj:105)
>> leiningen.core.utils$require_resolve.invoke (utils.clj:95)
>> leiningen.core.main$lookup_task_var.invokeStatic (main.clj:69)
>> leiningen.core.main$lookup_task_var.invoke (main.clj:65)
>> leiningen.core.main$pass_through_help_QMARK_.invokeStatic (main.clj:79)
>> leiningen.core.main$pass_through_help_QMARK_.invoke (main.clj:73)
>> leiningen.core.main$task_args.invokeStatic (main.clj:82)
>> leiningen.core.main$task_args.invoke (main.clj:81)
>> leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:339)
>> leiningen.core.main$resolve_and_apply.invoke (main.clj:336)
>> leiningen.core.main$_main$fn__6681.invoke (main.clj:452)
>> leiningen.core.main$_main.invokeStatic (main.clj:442)
>> leiningen.core.main$_main.doInvoke (main.clj:439)
>>
>>
>> The versions of Leiningen I am currently using are `Leiningen 2.9.1 on 
>> Java 1.8.0_242 OpenJDK 64-Bit Server VM` and `Leiningen 2.9.1 on Java 
>> 

Re: Recursively convert Java Map to Clojure Map

[Alex Miller]

You don't need that - Clojure maps *are* Java maps (they implement 
java.util.Map) and you can pass them into most Java APIs as is (with the 
caveat that they are made for reading, not for writing).

If you did really want to convert them to hash-maps or whatever, it's 
pretty easy to do so with a clojure.walk/postwalk-replace.

On Friday, January 31, 2020 at 3:07:24 PM UTC-6, Jason Ross wrote:
>
> Hey I know this is super old post but what would the reverse look like, 
> eg. recursively convert Clojure to java map
>
> On Saturday, October 15, 2011 at 4:10:32 AM UTC-5, Baishampayan Ghose 
> wrote:
>>
>> > I have a Java Map contains Map of Maps/List (JSON like map) and have
>> > to convert to Clojure map (This happens at Java - Clojure Interop), So
>> > I have written a converter function 'as-clj-map' by modifying the
>> > clojure walk functions, It works fine, but consume lot of cpu when the
>> > data structure is quit big. Any suggestions to improve this code?
>>
>> What about using protocols for this job?
>>
>> (defprotocol ConvertibleToClojure
>>   (->clj [o]))
>>
>> (extend-protocol ConvertibleToClojure
>>   java.util.Map
>>   (->clj [o] (let [entries (.entrySet o)]
>>(reduce (fn [m [^String k v]]
>>  (assoc m (keyword k) (->clj v)))
>>{} entries)))
>>
>>   java.util.List
>>   (->clj [o] (vec (map ->clj o)))
>>
>>   java.lang.Object
>>   (->clj [o] o)
>>
>>   nil
>>   (->clj [_] nil))
>>
>> (defn as-clj-map
>>   [m]
>>   (->clj m))
>>
>>
>> Let me know if this works for you & meets your performance requirements.
>>
>> Regards,
>> BG
>>
>> -- 
>> Baishampayan Ghose
>> b.ghose at gmail.com
>>
>>

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

Re: Feedback on datafy/nav project

[Alex Miller]

Datafiable is not special, the guidelines (recently refreshed with Rich's 
input at https://clojure.org/reference/protocols#_guidelines_for_extension) 
still make sense, but are still just guidelines for your thinking not Laws 
whose breakage will land you in Clojure Jail.

If you want to make protocol extensions for java time objects to datafiable 
and put it in a lib, go for it. No one is making anyone else use it. Maybe 
some day we'll do that in core, maybe not.

I'm certain that copying Datafiable to your own version however would lead 
only to a) confusion and b) a certainty that no one else would actually use 
it, and that seems like a waste of time.


On Friday, January 31, 2020 at 1:24:09 PM UTC-6, Jim foo.bar wrote:
>
> I tend to agree with you in where the benefit is - it's just that the way 
> the protocol docs are phrased, and some of the language used in that 
> mailing discussion from 10 years ago (from authoritative sources like Rich 
> and Stuart), implies that *no library is to extend clojure.core protocols 
> to core Java objects*, and that only Clojure itself is allowed do that. 
> The example Stuart gave back then with the english/spelling-corrector VS 
> spanish/spelling-corrector is pretty telling...
>
> Could it perhaps be the case that `Datafiable` is somewhat special in 
> that, it was conceived for the purpose of open extension by third parties, 
> and that the protocol extension guidelines don't really apply to it (or 
> perhaps not as strictly)?  
>
>
> Thanks for taking the time :)
>
> Dimitris
>
>
> On 31/01/2020 01:23, Sean Corfield wrote:
>
> If your library is intended specifically to provide the ability to 
> datafy/nav java.time objects then it is something optional that users can 
> choose to opt into.
>
>  
>
> The section you meant to link to 
> https://clojure.org/reference/protocols#_guidelines_for_extension says: “To 
> minimize conflicts, consider these guidelines”
>
>  
>
> So they’re a) guidelines and b) just given as a caution to minimize 
> conflicts.
>
>  
>
> There are libraries out there already that exist specifically to give 
> users the option to extend protocols from one library (such as 
> clojure.java.jdbc or next.jdbc) to Java types to provide customized 
> behavior, above and beyond the “base versions for common targets” 
> mentioned in that section provided by the original library.
>
>  
>
> I see benefit in libraries that extend Clojure’s datafy/nav to new domains 
> as a narrow purpose that users can opt into. I see much less benefit in 
> providing the same protocols and function names that core already includes, 
> targeted to new types, in an isolated way such as this. Perhaps that is 
> because I’m already using datafy/nav and I find their utility is enhanced 
> by being extended to other Java types?
>
>  
>
> Yes, if multiple people write multiple libraries A, B, C that extend 
> datafy/nav to java.time types and then other libraries X, Y, Z start 
> pulling in those extenders, consumers of X, Y, Z can be in trouble.
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> *From: *dimitris 
> *Sent: *Thursday, January 30, 2020 9:58 AM
> *To: *clojure@googlegroups.com
> *Subject: *Re: Feedback on datafy/nav project
>
>  
>
> Well, the official Clojure guidelines are to NOT extend protocols, unless 
> you own either the protocol of the type(s) [1].
>
> In particular these lines:
>
> *If you are a library developer, you should not extend if you own neither 
> the protocol nor the target.*
>
> *You should take particular care when extending protocols included with 
> Clojure itself.*
>
>  
>
> Kind regards,
>
> Dimitris
>
> [1]: https://clojure.org/reference/protocols#_extend_via_metadata
>
>  
>
> On 30/01/2020 17:50, Sean Corfield wrote:
>
> Is there a reason you’ve mirrored those protocols/implementations rather 
> than just use Clojure’s built-in versions?
>
>  
>
> As it stands, your library wouldn’t work with other tooling that builds on 
> Clojure’s datafy/nav (REBL, for example).
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>
> *From: *dimitris 
> *Sent: *Thursday, January 30, 2020 9:05 AM
> *To: *Clojure 
> *Subject: *Feedback on datafy/nav project
>
>  
>
> Hi folks,
>
>  
>
> I'm looking for honest and constructive feedback on [1] - not so much 
>
> about the actual implementation (even though these are welcome too), but 
>
> rather about the general idea of basing everything on top of (mirrored 
>
> versions) `datafy` and `nav` (in this way). There is a TL;DR section at 
>
> the very bottom that describes the approach in 4 short sentences.
>
>  
>
> Many thanks in advance,
>
>  
>
> Dimitris
>
>  
>
> [1]: https://github.com/jimpil/jedi-time
>
>  
>
>  
>
> -- 
>
> You received 

Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"

[Alex Miller]

Using vars lets you iterate on the impl functions without invalidating the 
proxy instances. I'm not sure if that was the reason, but that would be one 
advantage.

On Wednesday, January 15, 2020 at 10:46:36 AM UTC-6, Mike Rodriguez wrote:
>
> Do you have any idea about the reason that the Clojure implementation was 
> done this way - when it obviously seems a bit limited and also slower than 
> necessary? Just curious if there's some historical context.
>
> On Tuesday, January 14, 2020 at 11:58:17 AM UTC-5, Nathan Marz wrote:
>>
>> The speedup comes from proxy+ directly overriding methods with the 
>> provided implementation, while Clojure's proxy has additional indirection. 
>> For example, if you do (proxy [Object] [] (toString [] "hello")), the 
>> bytecode for toString is:
>>
>>   public java.lang.String toString();
>>
>>  0  aload_0 [this]
>>
>>  1  getfield user.proxy$java.lang.Object$ff19274a.__clojureFnMap : 
>> clojure.lang.IPersistentMap [16]
>>
>>  4  ldc  [52]
>>
>>  6  invokestatic clojure.lang.RT.get(java.lang.Object, 
>> java.lang.Object) : java.lang.Object [36]
>>
>>  9  dup
>>
>> 10  ifnull 28
>>
>> 13  checkcast clojure.lang.IFn [38]
>>
>> 16  aload_0 [this]
>>
>> 17  invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : 
>> java.lang.Object [55] [nargs: 2]
>>
>> 22  checkcast java.lang.String [57]
>>
>> 25  goto 33
>>
>> 28  pop
>>
>> 29  aload_0 [this]
>>
>> 30  invokespecial java.lang.Object.toString() : java.lang.String [59]
>>
>> 33  areturn
>>
>> Clojure keeps the implementations in a map, and for every dispatch it 
>> does a map lookup by the method name. This is also why it can't handle 
>> overriding the same method name with different arities.
>>
>> For (proxy+ [] Object (toString [this] "hello")), the bytecode is:
>>
>>   public java.lang.String toString();
>>
>>  0  aload_0 [this]
>>
>>  1  getfield user.proxy_plus5358.toString5357 : clojure.lang.IFn [19]
>>
>>  4  aload_0 [this]
>>
>>  5  invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : 
>> java.lang.Object [30] [nargs: 2]
>>
>> 10  checkcast java.lang.String [32]
>>
>> 13  areturn
>>
>> The implementation function is stored as a field, so the cost of dispatch 
>> is a field get rather than a map lookup.
>>
>> Clojure's proxy also overrides *every* available method in all 
>> superclasses/interfaces, while proxy+ only overrides what you specify. So 
>> proxy+ generates much smaller classes than proxy.
>>
>>
>> On Tuesday, January 14, 2020 at 10:30:32 AM UTC-5, Brent Millare wrote:
>>>
>>> I skimmed the code, I don't really understand how it makes it faster 
>>> over proxy. Is it the generated ASM is better? What's the in-a-nutshell 
>>> description of how it works?
>>>
>>> On Monday, January 13, 2020 at 1:28:46 PM UTC-5, Nathan Marz wrote:

 No differences in behavior except for API being like reify. It 
 integrates with AOT and can be consumed just like any other class. No idea 
 how it interacts with Graal.

 On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote:
>
> Bravo 
>
> Are there any differences in behavior to be aware of? AOT, Graal, 
> consuming proxy+ classes from vanilla clojure classes?
>
> On Mon, Jan 13, 2020, 11:47 AM Nathan Marz  wrote:
>
>> proxy+ is a replacement for Clojure's proxy that's faster and more 
>> usable. proxy has a strange implementation where it overrides every 
>> possible method and uses a mutable field to store a map of string -> 
>> function for dispatching the methods. This causes it to be unable to 
>> handle 
>> methods with the same name but different arities.
>>
>> proxy+ fixes these issues with proxy. Usage is like reify, and it's 
>> up to 10x faster.
>>
>> *Repository: *https://github.com/redplanetlabs/proxy-plus
>>
>> -- 
>> 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/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this 

Re: Why is `(get-in m ks)` not implemented as `(get-in m ks nil)`?

[Alex Miller]

At a skim, seems like a reasonable thing to do.

On Wednesday, December 11, 2019 at 5:04:38 AM UTC-6, Dirk Wetzel wrote:
>
> Hey everyone! :)
>
> I was recently looking at the source for *get-in* to check if it would 
> exit early as soon as a key was not present in the nested maps.
> The source for quick reference:
>
> (defn get-in
>   "Returns the value in a nested associative structure,
>   where ks is a sequence of keys. Returns nil if the key
>   is not present, or the not-found value if supplied."
>   {:added "1.2"
>:static true}
>   ([m ks]
>  (reduce1 get m ks))
>   ([m ks not-found]
>  (loop [sentinel (Object.)
> m m
> ks (seq ks)]
>(if ks
>  (let [m (get m (first ks) sentinel)]
>(if (identical? sentinel m)
>  not-found
>  (recur sentinel m (next ks
>  m
>
> I noticed that the 2-arity variant does not exit early, but the 3-arity 
> variant does. Also looking at the implementation of *reduce1* vs the 
> implementation of the 3-arity variant of *get-in* got me thinking if it 
> wouldn't be slightly more efficient to just implement the 2-arity variant 
> by calling the 3-arity variant, eg:
>
> ([m ks]
>(get-in m ks nil))
>
> I've run a few micro benchmarks comparing speeds of the 2-arity and 
> 3-arity variant using *criterium* and the 3-arity variant seems to be 
> more efficient even if it can't exit early.
> Below are a few of the criterium benchmarks I did on my laptop:
>
> (crit/bench (get-in {} [:a :b]))
>
> Evaluation count : 1874799960 in 60 samples of 3124 calls.
>  Execution time mean : 32.013948 ns
> Execution time std-deviation : 1.172814 ns
>Execution time lower quantile : 29.839525 ns ( 2.5%)
>Execution time upper quantile : 34.283877 ns (97.5%)
>Overhead used : 2.189987 ns
>
> Found 17 outliers in 60 samples (28. %)
> low-severe 13 (21.6667 %)
> low-mild 4 (6.6667 %)
>  Variance from outliers : 23.7873 % Variance is moderately inflated by 
> outliers
>
> (crit/bench (get-in {} [:a :b] nil))
>
> Evaluation count : 4071018060 in 60 samples of 67850301 calls.
>  Execution time mean : 15.124086 ns
> Execution time std-deviation : 1.492542 ns
>Execution time lower quantile : 12.488672 ns ( 2.5%)
>Execution time upper quantile : 17.908223 ns (97.5%)
>Overhead used : 2.189987 ns
>
> Found 1 outliers in 60 samples (1.6667 %)
> low-severe 1 (1.6667 %)
>  Variance from outliers : 68.6898 % Variance is severely inflated by 
> outliers
>
> (crit/bench (get-in {:a {:b {:c 1}}} [:a :b :c]))
>
> Evaluation count : 1034704440 in 60 samples of 17245074 calls.
>  Execution time mean : 58.600293 ns
> Execution time std-deviation : 2.939752 ns
>Execution time lower quantile : 55.782160 ns ( 2.5%)
>Execution time upper quantile : 64.772887 ns (97.5%)
>Overhead used : 2.189987 ns
>
> Found 2 outliers in 60 samples (3. %)
> low-severe 2 (3. %)
>  Variance from outliers : 36.8128 % Variance is moderately inflated by 
> outliers
>
> (crit/bench (get-in {:a {:b {:c 1}}} [:a :b :c] nil))
>
> Evaluation count : 1359247260 in 60 samples of 22654121 calls.
>  Execution time mean : 42.744780 ns
> Execution time std-deviation : 3.356838 ns
>Execution time lower quantile : 39.571655 ns ( 2.5%)
>Execution time upper quantile : 48.841751 ns (97.5%)
>Overhead used : 2.189987 ns
>
> Found 1 outliers in 60 samples (1.6667 %)
> low-severe 1 (1.6667 %)
>  Variance from outliers : 58.4799 % Variance is severely inflated by 
> outliers
>
>
> While I can imagine that changing the implementation of the 2-arity 
> variant would barely bring noticeable improvements to projects, I also 
> can't see much of a reason not to change it. It doesn't make the code less 
> readable or maintainable. It just makes performance for both arities 
> consistently good.
>
> What would be pros and cons of such a change that I don't see at the 
> moment?
>

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

Re: Clojure has been selected to participate in GSoC 2017!

[Alex Miller]

Outreachy seems like a great program but like most things, it requires
significant time and money (https://www.outreachy.org/mentor/).

They need an organization coordinator who can apply, find funds
($6500/intern), find mentors, help develop and assess projects. They also
need mentors who are expected to spend 5-10 hrs/week for 6 weeks during the
project.

I'm not aware of anyone with the time or money to commit to an effort like
this for Clojure.


On Wed, Dec 4, 2019 at 3:51 PM Noor Afshan Fathima 
wrote:

> Hello,
> GSOC would be great. Can someone also look into getting Clojure to
> participate in Outreachy?
>
> On Wed, 4 Dec 2019 at 10:18 PM, Alex Miller  wrote:
>
>> As far as I'm aware the work involved here is:
>>
>> - submitting the organization application (in Jan)
>> - soliciting and writing up project ideas (in Jan/Feb)
>> - soliciting potential mentors for each project (often there is a natural
>> match between idea and mentor) - spring
>> - pairing up selected students/projects and mentors - spring
>> - getting mentors to write evals for their students - summer
>> - accepting funds - fall
>> - if desired, distributing those funds in some way (when I helped
>> Cognitect run it, we redistributed the funds to pay for students to travel
>> to Clojure conferences) - fall
>>
>> Great opportunity for someone to contribute!
>>
>> On Wed, Dec 4, 2019 at 10:35 AM Daniel Compton <
>> daniel.compton.li...@gmail.com> wrote:
>>
>>> Hi folks, I'm the secretary of Clojurists Together.
>>>
>>> Thanks very much for the background on GSoC and the kind words Alex :)
>>>
>>> Clojurists Together would be happy to help provide the backing admin
>>> infrastructure (bank accounts, international payments, etc.) and oversight
>>> to help run GSoC. However, I don't think anyone on the committee has the
>>> bandwidth to be the primary person to lead the GSoC project; we'd need
>>> someone from the community to volunteer to be that person.
>>>
>>> If someone else wants to run this as part of a different organisation
>>> that's also totally fine with us, don't consider this us calling "dibs".
>>>
>>> Thanks, Daniel.
>>>
>>> On Wed, Dec 4, 2019 at 9:34 AM Alex Miller  wrote:
>>>
>>>> GSoC is an amazing opportunity if you get the right combination of an
>>>> appropriately sized project, a motivated student, and a mentor that has
>>>> both sufficient availability and expertise in guiding (like Ambrose's Typed
>>>> Clojure work). If any of those aren't right, the project tends to fizzle
>>>> out or go unused so a lot of the time and effort does not result in an
>>>> effectual end result.
>>>>
>>>> To some degree, Clojurists Together is doing the same kind of work but
>>>> prioritizing projects that people care about and developers that are
>>>> already "in" the project rather than students starting fresh (and paying
>>>> more for the work). I think CT has created way more total value for the
>>>> community than GSoC ever did.
>>>>
>>>> But again, depends on goals. If your goal is to connect students more
>>>> closely to Clojure, then GSoC is great for that.
>>>>
>>>>
>>>> On Tuesday, December 3, 2019 at 2:06:13 PM UTC-6, Daniel Slutsky wrote:
>>>>>
>>>>> Ag, Alex, many thanks.
>>>>>
>>>>> These days some of us are trying to think where we should put our
>>>>> efforts in the next few months. This might be one of the things we have to
>>>>> consider. We'll update if we do.
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, 3 December 2019 17:20:47 UTC+2, Alex Miller wrote:
>>>>>>
>>>>>> Any "group" or organization can submit a project to GSoC as long as
>>>>>> there are 2+ committers and there are existing releases under an OSI
>>>>>> license (which includes EPL). The organization select projects, connects
>>>>>> mentors to students, prods people about evaluations, and receives
>>>>>> $500/completed student. Students submit proposals (usually these should
>>>>>> happen under consultation with the project) and are directly paid 
>>>>>> stipends
>>>>>> by Google for completed projects. I think the organization application is
>>>>>> usually open in January.
>>>>>>
>>>&

Re: Clojure has been selected to participate in GSoC 2017!

[Alex Miller]

As far as I'm aware the work involved here is:

- submitting the organization application (in Jan)
- soliciting and writing up project ideas (in Jan/Feb)
- soliciting potential mentors for each project (often there is a natural
match between idea and mentor) - spring
- pairing up selected students/projects and mentors - spring
- getting mentors to write evals for their students - summer
- accepting funds - fall
- if desired, distributing those funds in some way (when I helped Cognitect
run it, we redistributed the funds to pay for students to travel to Clojure
conferences) - fall

Great opportunity for someone to contribute!

On Wed, Dec 4, 2019 at 10:35 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi folks, I'm the secretary of Clojurists Together.
>
> Thanks very much for the background on GSoC and the kind words Alex :)
>
> Clojurists Together would be happy to help provide the backing admin
> infrastructure (bank accounts, international payments, etc.) and oversight
> to help run GSoC. However, I don't think anyone on the committee has the
> bandwidth to be the primary person to lead the GSoC project; we'd need
> someone from the community to volunteer to be that person.
>
> If someone else wants to run this as part of a different organisation
> that's also totally fine with us, don't consider this us calling "dibs".
>
> Thanks, Daniel.
>
> On Wed, Dec 4, 2019 at 9:34 AM Alex Miller  wrote:
>
>> GSoC is an amazing opportunity if you get the right combination of an
>> appropriately sized project, a motivated student, and a mentor that has
>> both sufficient availability and expertise in guiding (like Ambrose's Typed
>> Clojure work). If any of those aren't right, the project tends to fizzle
>> out or go unused so a lot of the time and effort does not result in an
>> effectual end result.
>>
>> To some degree, Clojurists Together is doing the same kind of work but
>> prioritizing projects that people care about and developers that are
>> already "in" the project rather than students starting fresh (and paying
>> more for the work). I think CT has created way more total value for the
>> community than GSoC ever did.
>>
>> But again, depends on goals. If your goal is to connect students more
>> closely to Clojure, then GSoC is great for that.
>>
>>
>> On Tuesday, December 3, 2019 at 2:06:13 PM UTC-6, Daniel Slutsky wrote:
>>>
>>> Ag, Alex, many thanks.
>>>
>>> These days some of us are trying to think where we should put our
>>> efforts in the next few months. This might be one of the things we have to
>>> consider. We'll update if we do.
>>>
>>>
>>>
>>> On Tuesday, 3 December 2019 17:20:47 UTC+2, Alex Miller wrote:
>>>>
>>>> Any "group" or organization can submit a project to GSoC as long as
>>>> there are 2+ committers and there are existing releases under an OSI
>>>> license (which includes EPL). The organization select projects, connects
>>>> mentors to students, prods people about evaluations, and receives
>>>> $500/completed student. Students submit proposals (usually these should
>>>> happen under consultation with the project) and are directly paid stipends
>>>> by Google for completed projects. I think the organization application is
>>>> usually open in January.
>>>>
>>>> I think there are several groups in the Clojure ecosystem that would
>>>> potentially be great orgs for this - CIDER, ClojureBridge, clj-commons, 
>>>> etc.
>>>>
>>>>
>>>> On Tuesday, December 3, 2019 at 5:23:43 AM UTC-6, Ag Ibragimov wrote:
>>>>>
>>>>>
>>>>> Would you do it Daniel, would you apply? I apologize for if that
>>>>> sounds like I'm brazenly pushing you. If I had capacity to do that, I 
>>>>> would
>>>>> volunteer, alas I'm afraid I don't even know how that works.
>>>>> It would be awesome if Clojure once again accepted in GSoC. How can we
>>>>> (ordinary Clojuristas) help to get there?
>>>>>
>>>>> On Sun 01 Dec 2019 at 15:12, Daniel Slutsky 
>>>>> wrote:
>>>>>
>>>>> > Thanks so much, that helps to know.
>>>>> >
>>>>> > On Sunday, 1 December 2019 06:36:33 UTC+2, Alex Miller wrote:
>>>>> >>
>>>>> >> We applied and were not accepted for a couple years. Having done
>>>>> some of
>>>>> >> the admin/org stuff in the past, I d

Re: Clojure has been selected to participate in GSoC 2017!

[Alex Miller]

GSoC is an amazing opportunity if you get the right combination of an 
appropriately sized project, a motivated student, and a mentor that has 
both sufficient availability and expertise in guiding (like Ambrose's Typed 
Clojure work). If any of those aren't right, the project tends to fizzle 
out or go unused so a lot of the time and effort does not result in an 
effectual end result. 

To some degree, Clojurists Together is doing the same kind of work but 
prioritizing projects that people care about and developers that are 
already "in" the project rather than students starting fresh (and paying 
more for the work). I think CT has created way more total value for the 
community than GSoC ever did.

But again, depends on goals. If your goal is to connect students more 
closely to Clojure, then GSoC is great for that.


On Tuesday, December 3, 2019 at 2:06:13 PM UTC-6, Daniel Slutsky wrote:
>
> Ag, Alex, many thanks.
>
> These days some of us are trying to think where we should put our efforts 
> in the next few months. This might be one of the things we have to 
> consider. We'll update if we do.
>
>
>
> On Tuesday, 3 December 2019 17:20:47 UTC+2, Alex Miller wrote:
>>
>> Any "group" or organization can submit a project to GSoC as long as there 
>> are 2+ committers and there are existing releases under an OSI license 
>> (which includes EPL). The organization select projects, connects mentors to 
>> students, prods people about evaluations, and receives $500/completed 
>> student. Students submit proposals (usually these should happen under 
>> consultation with the project) and are directly paid stipends by Google for 
>> completed projects. I think the organization application is usually open in 
>> January.
>>
>> I think there are several groups in the Clojure ecosystem that would 
>> potentially be great orgs for this - CIDER, ClojureBridge, clj-commons, etc.
>>
>>
>> On Tuesday, December 3, 2019 at 5:23:43 AM UTC-6, Ag Ibragimov wrote:
>>>
>>>
>>> Would you do it Daniel, would you apply? I apologize for if that sounds 
>>> like I'm brazenly pushing you. If I had capacity to do that, I would 
>>> volunteer, alas I'm afraid I don't even know how that works. 
>>> It would be awesome if Clojure once again accepted in GSoC. How can we 
>>> (ordinary Clojuristas) help to get there? 
>>>
>>> On Sun 01 Dec 2019 at 15:12, Daniel Slutsky  
>>> wrote: 
>>>
>>> > Thanks so much, that helps to know. 
>>> > 
>>> > On Sunday, 1 December 2019 06:36:33 UTC+2, Alex Miller wrote: 
>>> >> 
>>> >> We applied and were not accepted for a couple years. Having done some 
>>> of 
>>> >> the admin/org stuff in the past, I don't really want to do it again, 
>>> but an 
>>> >> organization like Clojurists Together would be great for that part 
>>> >> (although I'm not looking to add any work to anyone else either). 
>>> It's not 
>>> >> really that hard, just a little tedious to deal with the money parts. 
>>> >> 
>>> >> On Saturday, November 30, 2019 at 1:37:14 PM UTC-6, Daniel Slutsky 
>>> wrote: 
>>> >>> 
>>> >>> Hi all, 
>>> >>> has there been thoughts about clojure activity in GSoC since 2017? 
>>> >>> 
>>> >>> 
>>> >>> On Monday, 6 March 2017 11:35:41 UTC+2, Daniel Solano Gómez wrote: 
>>> >>>> 
>>> >>>> We are pleased to announce that Google has selected Clojure as a 
>>> >>>> mentoring organisation for this year’s summer of code! This means 
>>> that 
>>> >>>> Google will sponsor students from around the world to work on 
>>> projects that 
>>> >>>> are part of the Clojure ecosystem. Now that we know that Clojure 
>>> will be 
>>> >>>> participating, what happens next? 
>>> >>>> 
>>> >>>> Getting involved 
>>> >>>> 
>>> >>>> The student application period will be open from the 20th of March 
>>> >>>> through the 3rd of April. In the meantime, there are a number of 
>>> ways to 
>>> >>>> get involved: 
>>> >>>> 
>>> >>>> *Mentors* 
>>> >>>> 
>>> >>>> If you maintain an open source Clojure(Script) project and would 
>>> like to 
>>> >>>> grow it, you should consider becoming a mentor. You can

Re: Clojure has been selected to participate in GSoC 2017!

[Alex Miller]

Any "group" or organization can submit a project to GSoC as long as there 
are 2+ committers and there are existing releases under an OSI license 
(which includes EPL). The organization select projects, connects mentors to 
students, prods people about evaluations, and receives $500/completed 
student. Students submit proposals (usually these should happen under 
consultation with the project) and are directly paid stipends by Google for 
completed projects. I think the organization application is usually open in 
January.

I think there are several groups in the Clojure ecosystem that would 
potentially be great orgs for this - CIDER, ClojureBridge, clj-commons, etc.


On Tuesday, December 3, 2019 at 5:23:43 AM UTC-6, Ag Ibragimov wrote:
>
>
> Would you do it Daniel, would you apply? I apologize for if that sounds 
> like I'm brazenly pushing you. If I had capacity to do that, I would 
> volunteer, alas I'm afraid I don't even know how that works. 
> It would be awesome if Clojure once again accepted in GSoC. How can we 
> (ordinary Clojuristas) help to get there? 
>
> On Sun 01 Dec 2019 at 15:12, Daniel Slutsky  
> wrote: 
>
> > Thanks so much, that helps to know. 
> > 
> > On Sunday, 1 December 2019 06:36:33 UTC+2, Alex Miller wrote: 
> >> 
> >> We applied and were not accepted for a couple years. Having done some 
> of 
> >> the admin/org stuff in the past, I don't really want to do it again, 
> but an 
> >> organization like Clojurists Together would be great for that part 
> >> (although I'm not looking to add any work to anyone else either). It's 
> not 
> >> really that hard, just a little tedious to deal with the money parts. 
> >> 
> >> On Saturday, November 30, 2019 at 1:37:14 PM UTC-6, Daniel Slutsky 
> wrote: 
> >>> 
> >>> Hi all, 
> >>> has there been thoughts about clojure activity in GSoC since 2017? 
> >>> 
> >>> 
> >>> On Monday, 6 March 2017 11:35:41 UTC+2, Daniel Solano Gómez wrote: 
> >>>> 
> >>>> We are pleased to announce that Google has selected Clojure as a 
> >>>> mentoring organisation for this year’s summer of code! This means 
> that 
> >>>> Google will sponsor students from around the world to work on 
> projects that 
> >>>> are part of the Clojure ecosystem. Now that we know that Clojure will 
> be 
> >>>> participating, what happens next? 
> >>>> 
> >>>> Getting involved 
> >>>> 
> >>>> The student application period will be open from the 20th of March 
> >>>> through the 3rd of April. In the meantime, there are a number of ways 
> to 
> >>>> get involved: 
> >>>> 
> >>>> *Mentors* 
> >>>> 
> >>>> If you maintain an open source Clojure(Script) project and would like 
> to 
> >>>> grow it, you should consider becoming a mentor. You can find out more 
> about 
> >>>> what being a mentor is about out on the mentors page 
> >>>> <http://clojure-gsoc.org/mentors/>. 
> >>>> 
> >>>> *Students* 
> >>>> 
> >>>> While it is still to early to formally apply as GSoC student, this is 
> a 
> >>>> great time to start thinking about project ideas and reach out to 
> potential 
> >>>> mentors. Check out the students page <
> http://clojure-gsoc.org/students/> 
> >>>> for more information on how to apply successfully. 
> >>>> 
> >>>> *Everyone else* 
> >>>> 
> >>>> Even if you can’t participate as student or don’t want to be a 
> mentor, 
> >>>> you can still help by letting people know about GSoC at your local 
> Clojure 
> >>>> meetup, university, or other local group. 
> >>>> 
> >>>> Thanks 
> >>>> 
> >>>> We would also like to extend a big thank you to all of the people who 
> >>>> contributed to our project ideas 
> >>>> <http://clojure-gsoc.org/project-ideas/>.  Without their help, it is 
> >>>> likely our application would not have been a success. 
> >>>> 
> >>> 
>
>

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

Re: Clojure has been selected to participate in GSoC 2017!

[Alex Miller]

We applied and were not accepted for a couple years. Having done some of 
the admin/org stuff in the past, I don't really want to do it again, but an 
organization like Clojurists Together would be great for that part 
(although I'm not looking to add any work to anyone else either). It's not 
really that hard, just a little tedious to deal with the money parts.

On Saturday, November 30, 2019 at 1:37:14 PM UTC-6, Daniel Slutsky wrote:
>
> Hi all,
> has there been thoughts about clojure activity in GSoC since 2017?
>
>
> On Monday, 6 March 2017 11:35:41 UTC+2, Daniel Solano Gómez wrote:
>>
>> We are pleased to announce that Google has selected Clojure as a 
>> mentoring organisation for this year’s summer of code! This means that 
>> Google will sponsor students from around the world to work on projects that 
>> are part of the Clojure ecosystem. Now that we know that Clojure will be 
>> participating, what happens next?
>>
>> Getting involved
>>
>> The student application period will be open from the 20th of March 
>> through the 3rd of April. In the meantime, there are a number of ways to 
>> get involved:
>>
>> *Mentors*
>>
>> If you maintain an open source Clojure(Script) project and would like to 
>> grow it, you should consider becoming a mentor. You can find out more about 
>> what being a mentor is about out on the mentors page 
>> .
>>
>> *Students*
>>
>> While it is still to early to formally apply as GSoC student, this is a 
>> great time to start thinking about project ideas and reach out to potential 
>> mentors. Check out the students page  
>> for more information on how to apply successfully.
>>
>> *Everyone else*
>>
>> Even if you can’t participate as student or don’t want to be a mentor, 
>> you can still help by letting people know about GSoC at your local Clojure 
>> meetup, university, or other local group.
>>
>> Thanks
>>
>> We would also like to extend a big thank you to all of the people who 
>> contributed to our project ideas . 
>>  Without their help, it is likely our application would not have been a 
>> success.
>>
>

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

Re: A Concise Guide to Getting Started with Clojure on Windows

[Alex Miller]

We'd be happy to host a guide like this on clojure.org if you're 
interested... 

https://clojure.org/community/contributing_site

Alex

On Thursday, October 17, 2019 at 7:47:03 PM UTC-5, Brandon R wrote:
>
> Hello Clojure friends,
>
> I wrote this guide for a friend, and it's something I wish I had when I 
> was starting. This guide focuses on Windows, VS Code, and Calva, though 
> much of it would be useful to non-Windows users as well.
>
> Beginner resources have come a long way since I started, but there can 
> never be too many. If you know someone who wants to get started with 
> Clojure and is using Windows and/or VS Code, they may find this useful:
>
> https://gist.github.com/bpringe/4f1d07f98633a956a8b33af572e7b810 
>
>
> Sincerely,
>
> Brandon (@bringe on the Clojurians Slack)
>

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

Re: s/valid returns false, but s/explain prints "Success!"

[Alex Miller]

> On Sep 26, 2019, at 7:15 PM, Markus Agwin  wrote:
> 
> https://www.clojure.org/guides/spec are the docs I mentioned (search for 
> first occurrence of :kind)

Thanks, that’s just old, will fix.


> 

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

Re: s/valid returns false, but s/explain prints "Success!"

[Alex Miller]

On Thursday, September 26, 2019 at 7:41:20 AM UTC-5, Markus Agwin wrote:
>
> Consider the following cloure.spec-alpha2 example:
>   
> (def v [0])
> (s/def ::thevec vector?)
> (s/def ::data (s/coll-of number? :kind ::thevec))
>

:kind is expected to be a predicate, not a spec. The doc string (in 
s/every) says ":kind - a pred that the collection type must satisfy, e.g. 
vector?"

so this should be:

(s/def ::data (s/coll-of number? :kind vector?))

With the prior, you're getting the keyword ::thevec as the predicate - that 
will look ::thevec up in whatever you pass it when used as a predicate.
 

> (s/valid? ::data v) ;;=> returns false, my expectation is that it should 
> return true
>

This matches above interpretation - (::thevec [0]) yields nil
 

> (s/explain ::data v) ;;=> prints "Success!", which inconsistent to s/valid?
>

Agreed that's confusing. I think it's because the keyword as predicate 
returns nil instead of false but there is probably something to clean up 
here.
 

>
> (s/def ::data2 (s/coll-of number? :kind vector?))
> (s/valid? ::data2 v) ;;=> returns true, as expected
>
> I expect (s/valid? ::data v) to return true, but it returns false. 
> Moreover, s/explain prints "Success!" which is inconsistent to s/valid? for 
> this example.
> If I replace :kind ::thevec by :kind vector?, everything is fine. Why is 
> that (the spec documentation says: ":kind - a predicate or spec").
>

The docs were wrong at one point in time, but this was fixed a while ago, 
only preds are supported here.  Where are you seeing the old docs? 

https://clojure.github.io/spec.alpha/clojure.spec.alpha-api.html#clojure.spec.alpha/every
 
doesn't have that and you won't see it in docstrings of current spec or 
spec 2 versions

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

Re: How to use Clojure core specs in my own library with regards to the EPL license?

[Alex Miller]

I think at the point of "I copied the specs for `fn` and `defn` in my own 
code base, and modified them accordingly.", that sounds like a modification 
of source under the EPL. A more subtle interpretation would require legal 
expertise.

Re the PS, yes that's a larger known issue around regex specs in a vector, 
which is a thorny issue.



On Tuesday, August 27, 2019 at 11:59:01 PM UTC-5, Didier wrote:
>
> I'm looking to publish a Clojure library and would like to release it 
> under the MIT license. That said, I needed to modify some core specs so 
> that `fn` and `defn` can properly roundtrip between conform and unform.
>
> To do this, I copied the specs for `fn` and `defn` in my own code base, 
> and modified them accordingly.
>
> From what I understand of the EPL, modifications of EPL code must be 
> re-licensed under the EPL as well, and what changes were made must be 
> documented. But, normally (though the Google vs Oracle lawsuit might change 
> that), function signatures are not considered copyrightable. When it comes 
> to Spec, things get fuzzy for me, the spec is code, so it probably means it 
> is under the EPL. That said, even if I specced `fn` and `defn` myself, 
> starting from scratch, chances are I would end up with almost the same 
> spec. In some way, a spec is like a function signature as well. So I'm not 
> sure how to treat them.
>
> I believe my best bet right now is just either license my whole library 
> under EPL, and document the changes I made to the core specs. Or to double 
> license, move the specs into their own file with an EPL license, and 
> license the rest under MIT.
>
> P.S.: Is it a bug that fn and defn specs can not roundtrip?
>

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

Re: [ANN] defexception 0.1.0: a library for dynamically defining exception types in Clojure

[Alex Miller]

The clojure.asm namespaces are an internal vendored version of the asm library. 
It is NOT considered to be part of the public Clojure API. We periodically 
update it and have no control over that API, which does sometimes include 
breaking changes.

External users of Clojure should never depend on it directly. Instead they 
should make their dependency on asm visible by declaring a dependency on the 
asm library and using their public api.

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

[ANN] clj 1.10.1.469 and tools.deps.alpha 0.7.541

[Alex Miller]

These releases are now available...

- FIX: exclusions were not canonicalized and could fail to match and exclude
- PERF: cache Maven session and use Maven session cache
- FIX: Remove slf4j-nop as dependency of tools.deps.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAOdgdgzX3LZ2VrFQX%2Bxp1u7H6qETFC50pux3MwT%2BdV%3DmL5vX7Q%40mail.gmail.com.

Re: questionable result of Clojure code execution in org babel

[Alex Miller]

You can’t wrap ns and forms into a single do like that. If you google around 
you can find this issue referred to as the Gilardi scenario.

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

Re: Strange with "clj" tool

[Alex Miller]

The error indicates a classpath that does not include the clojure 
dependency. That shouldn't ever happen (as clojure is included as the 
default dependency set).

So not sure what would cause that, but it would help to know if there is a 
deps.edn file at the location of the failure and what it is in it.

Also, you might have something bad in the ./.cpcache/ dir in that folder - 
you could try either using clj -Sforce (to avoid using it) or just deleting 
the directory if it exists.



On Wednesday, July 31, 2019 at 6:16:31 AM UTC-5, ru wrote:
>
> Hi,
>
> The tool "clj" starts normally in any folder, except in one, that I cloned 
> from github:
>
> [image: error.png]
>
>
> Please, explain me this behavior.
>
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/a355ecda-f625-4b6c-852e-0dad91137e7b%40googlegroups.com.

Re:

[Alex Miller]

Something is wrong with Google groups. If I knew how to fix it, I would, but 
I’ve given up trying.

> On Jul 18, 2019, at 6:20 AM, 'David Bürgin' via Clojure 
>  wrote:
> 
> I’m an email user. For some reason official announcements (by Alex
> Miller) don’t get sent out via email, they only appear in the Google
> Groups web interface. Replies (and all other messages) do land in my
> inbox, though.
> 
> Something wrong with your email Alex, or is it Google Groups?
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/GSErqcN9HUo/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/20190718112053.GA12047%40azadi.
> 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/DECE2707-8DF6-4A38-B23D-731BD044F21A%40puredanger.com.
For more options, visit https://groups.google.com/d/optout.

Re: core.async: Unbound channels

[Alex Miller]

Expanding transducers (like mapcat) can produce multiple output values per 
input value, and those have to have someplace to go.

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

Re: [ANN] Cognitect Labs' aws-api 0.8.335

[Alex Miller]

clojure.xml is a ns built into Clojure core that dates from very early days of 
Clojure. At a later point, it almost certainly would have been in 
clojure-contrib or a separate library. It is not a good choice for anything 
more than one-off code. In particular, it will cause reflection/illegal access 
warnings because it has an api that truly is reflective (in passing through 
objects of many possible types).

org.clojure/data.xml is a full xml library, using modern jdk conveniences and 
providing many more features. As such, it’s a much better choice to build on.

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

Re: Calling Java from Clojure

[Alex Miller]

In that case, I would try to isolate those gen-classes into as small a box
as possible and make an artifact for just those.

On Fri, Jun 21, 2019 at 4:58 PM Didier  wrote:

> Oh, not when you don't have too. I mean, you can always hand write a class
> in Java and have it call into Clojure. That's effectively gen-class but
> done manually. Otherwise, I favour the Clojure Java API.
>
> But some code base are already using gen-class, and some people do use
> gen-class. Sometimes it works and it's easier then having to write Java and
> modify your build to also use javac and include Java built artifacts.
>
> In those cases, the AOT is problematic, because it brings in dependencies,
> so if you package them as libraries, you get additional classes which can
> then conflict. So you need to find a way to only include the generated
> class and nothing else.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/aejqMwraPk8/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/bf3a22ec-efd0-4508-8e41-895a1329e328%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/CAOdgdgxiu39ASKPt2%2B4t-2D3fzMPruw9_dPv%3Dg23AT3Lvc3orw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Calling Java from Clojure

[Alex Miller]

I just don’t understand why you would introduce aot or gen-class at all if you 
didn’t have to, which is one of the benefits of using the Clojure Java API.

> On Jun 21, 2019, at 2:35 PM, Sean Corfield  wrote:
> 
> The approach I’ve taken around :gen-class has been to ensure that the 
> namespace offering the Java class via :gen-class has no static dependencies 
> at all – instead it requires/resolves any other namespaces/symbols it needs 
> at run time. That way AOT creates the .class you need but doesn’t spread to 
> anything else.
>  
> This is even easier in Clojure 1.10 with the addition of requiring-resolve 
> (which is also thread safe, unlike regular require right now).
>  
> But yeah, as Alex indicated, you need to be careful if you have an AOT’d 
> entry point and downstream code is not AOT’d. Just one more “here be dragons” 
> aspect of AOT, IMO.
>  
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>  
>  
> From: clojure@googlegroups.com  on behalf of Didier 
> 
> Sent: Thursday, June 20, 2019 9:13:40 PM
> To: Clojure
> Subject: Re: Calling Java from Clojure
>  
> Option #1 and #3 are very much the same, just that Option #3 creates a Java 
> layer on top, instead of having everything coupled to the Clojure Java APIs 
> directly.
> 
> When you go with Option #2, you do not have to AOT everything, but AOT is 
> transitive. So as you AOT the gen class, all code it requires and all code 
> they in turn require will also be AOT. You can post-process the AOT when 
> jaring, and only include the gen-class .class files in the Jar and not the 
> dependencies, but that's more work.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to 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/1dd84879-6855-4893-99ee-de15ea6a6329%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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/aejqMwraPk8/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/CY4PR2201MB11266042416A0BEFDBB233C6F4E70%40CY4PR2201MB1126.namprd22.prod.outlook.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/D9D7F343-1BDC-4257-9FAD-BBEA5A613DE1%40puredanger.com.
For more options, visit https://groups.google.com/d/optout.

Re: Calling Java from Clojure

[Alex Miller]

With AOT, you generally shouldn't ever exclude part of the AOT'ed code.
Most problems with AOT'ed code stem from having AOT'ed code call into
non-AOT'ed code, so anything "downstream" should also be AOT'ed.

On Fri, Jun 21, 2019 at 10:01 AM eglue  wrote:

> This is a good clarification.
>
> I found that when I tried to exclude some AOT stuff from the jar you can
> get into a situation where Clojure will dynamically produce a class that is
> already statically-produced at the root classloader and then you'll hit
> ClassPathExceptions when you try to pass these things around.
>
> For example I had dynamic (non-AOT'd) code paths using a defrecord, for
> which a .class file was generated dynamically. So if I kept the AOT'd
> defrecord, as well, I'd have two classes one in the root classloader and
> one from dynamic clojure (DynamicClassLoader).
>
> So if what you're saying is possible, I think you will have to show quite
> a bit of careful surgery to avoid these kinds of problems?
>
> On Thursday, June 20, 2019 at 11:13:41 PM UTC-5, Didier wrote:
>>
>> Option #1 and #3 are very much the same, just that Option #3 creates a
>> Java layer on top, instead of having everything coupled to the Clojure Java
>> APIs directly.
>>
>> When you go with Option #2, you do not have to AOT everything, but AOT is
>> transitive. So as you AOT the gen class, all code it requires and all code
>> they in turn require will also be AOT. You can post-process the AOT when
>> jaring, and only include the gen-class .class files in the Jar and not the
>> dependencies, but that's more work.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/aejqMwraPk8/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/02a72bb0-9a6f-4574-9134-2d8983db8b81%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/CAOdgdgz-dbt67Ec90J7q2Ff3OEu-Qz38RQ9VA5VuQMfq9qQAhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Calling Java from Clojure

[Alex Miller]

Yes, the whole point of this approach is to define the interface in Java and 
the implementation in Clojure.

> On Jun 17, 2019, at 5:07 PM, ru  wrote:
> 
> core.clj defines only names "getTimestamp" and "getName", but meaning of 
> these names defined in Support.java. For example, that "getTimestamp" means 
> result of a new java.util.Date.
> 
> понедельник, 17 июня 2019 г., 23:35:30 UTC+3 пользователь Alex Miller написал:
>> 
>> No, there is a bit of Java code just to load the Clojure 
>> code, but then it’s Clojure after that (the entity record impl). 
>> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/aejqMwraPk8/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/c7ef72fe-b062-49b6-a3bb-5183e1a73d6c%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/55987A28-3662-4CB9-9D1F-1614B3F44AD7%40puredanger.com.
For more options, visit https://groups.google.com/d/optout.

Re: Calling Java from Clojure

[Alex Miller]

No, there is a bit of Java code just to load the Clojure
code, but then it’s Clojure after that (the entity record impl).

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

Re: Calling Java from Clojure

[Alex Miller]

On Mon, Jun 10, 2019 at 12:04 AM eglue  wrote:

> This is great, Alex, thanks. (Sorry, I deleted from underneath you and
> reposted to fix the title before I saw your reply...)
>
> The latter option, writing interfaces and classes in Java and calling w/
> the glue code is a great option.
>
> However one big motivator for people moving from Java to langs like Scala
> and Kotlin is being able to implement those bean/record types, eg, with
> such little fanfare & boilerplate (eg in Clojure, using defrecord is so
> concise).
>

The problem with wanting the Clojure-y version from Java is that those
interfaces are generic and weird from the Java side. So either you get
bean-like code familiar to Java users or generic collection/keyword
interfaces that will be weird to use from Java. I heard your goal as "be
friendly from Java", which means, making bean-like interfaces. On the
Clojure side, it's pretty easy to macro-ize the creation of those over
defrecords or whatever, so it could still be  a lot less macro work, just
depends how far you want to go with it. You don't get all the benefits of
Clojure from Java; you have to be in Clojure for the many related design
decisions to compound together. There's no magic solution to that (other
than "just use Clojure" :).


> And you can sometimes end up with a handful of these, so the 'glue code'
> isn't quite so small. Also gen-class and definterface I find similarly
> nice.
>

I find the glue code is actually small in practice (I've done a couple of
real systems this way). This particular example is a little weird because
it's just making a domain object, but generally you're writing the glue to
provide a factory method for a facade. Below the facade, the Clojure code
can make new objects just fine, so you're staying in Clojure for the rest
of it.


> I wonder if there's a path to improve what you're calling option #2.
> Specifically the needing to AOT compile *everything*. It seems I should
> only have to AOT/precompile the surface area that my Java consumer wants to
> link with. At runtime perhaps there'd be some creative way to leave out the
> AOT classes (which would just have been used for static-time compiling) and
> when the JVM tries to load those classes some agent could interject and do
> the dynamic Clojure loading?
>

Seems like you're taking the hardest path and trying to make it harder. I
just don't see the point in running at this one, sorry. My experience is
that the approach above works great and has none of these issues.


>
>
> On Sunday, June 9, 2019 at 11:21:28 PM UTC-5, Alex Miller wrote:
>>
>> Looks like the title for this is backwards if I understand the intent,
>> should be calling Clojure from Java, right?
>>
>> Java code is going to invoke methods on classes (that's all it knows how
>> to do). You have several options:
>>
>> 1) Use the Clojure Java API to invoke the Clojure runtime - here you're
>> leveraging the Clojure runtime's Java impl core to call into Clojure (Stu's
>> example)
>> 2) Use protocols, records, and/or genclass to actually produce Java
>> classes (your example, I think).
>> 3) Define your interface as a set of Java interfaces. Implement this
>> interface in Clojure. You will need a small amount of glue code to provide
>> the API impl (some kind of a factory to give you the impl of the Java
>> interface - either written in Java or using #1).
>>
>> #1 is straightforward but tedious - it's really only worthwhile if you
>> have a small amount of this code and hide the use of it.
>> #2 has significant downsides - needing to compile everything, all methods
>> are just going to take/return Java Objects, no javadoc on apis,  etc.
>> #3 has advantages in all those areas. You write your Java interface where
>> you can best write it ... in Java (with Javadoc, and Java interfaces, and
>> all the niceties Java users want). IDEs can autocomplete on the Java
>> interfaces. You don't have to AOT - factories can reify or load protocol
>> instances as needed as they return objects. You can even reload internal
>> vars with a connected REPL without restarting the app.
>>
>> The last does take a bit of planning to set up - you need API code (in
>> Java), and Clojure code that relies on that Java code. lein makes it pretty
>> trivial to put those in one project and compile in that order.
>>
>> I pushed an example up here:
>>
>> https://github.com/puredanger/clojure-from-java
>>
>> It defines a Java interface (java/cfj/Event.java
>> <https://github.com/puredanger/clojure-from-java/blob/master/java/cfj/Event.java>),
>> a static helper to hook the Clojure (java/cfj/Support.java
>> <https://github.co

Re: Calling Java from Clojure

[Alex Miller]

Looks like the title for this is backwards if I understand the intent, 
should be calling Clojure from Java, right?

Java code is going to invoke methods on classes (that's all it knows how to 
do). You have several options:

1) Use the Clojure Java API to invoke the Clojure runtime - here you're 
leveraging the Clojure runtime's Java impl core to call into Clojure (Stu's 
example)
2) Use protocols, records, and/or genclass to actually produce Java classes 
(your example, I think). 
3) Define your interface as a set of Java interfaces. Implement this 
interface in Clojure. You will need a small amount of glue code to provide 
the API impl (some kind of a factory to give you the impl of the Java 
interface - either written in Java or using #1). 

#1 is straightforward but tedious - it's really only worthwhile if you have 
a small amount of this code and hide the use of it.
#2 has significant downsides - needing to compile everything, all methods 
are just going to take/return Java Objects, no javadoc on apis,  etc. 
#3 has advantages in all those areas. You write your Java interface where 
you can best write it ... in Java (with Javadoc, and Java interfaces, and 
all the niceties Java users want). IDEs can autocomplete on the Java 
interfaces. You don't have to AOT - factories can reify or load protocol 
instances as needed as they return objects. You can even reload internal 
vars with a connected REPL without restarting the app.

The last does take a bit of planning to set up - you need API code (in 
Java), and Clojure code that relies on that Java code. lein makes it pretty 
trivial to put those in one project and compile in that order.

I pushed an example up here:

https://github.com/puredanger/clojure-from-java

It defines a Java interface (java/cfj/Event.java 
),
 
a static helper to hook the Clojure (java/cfj/Support.java 
),
 
which uses the Clojure Java API to load the Clojure instance in 
clj/core/cfj.clj 
. 
Just `lein uberjar` and you're done. Use the Support API from Java as any 
other Java class. No AOT required.



On Sunday, June 9, 2019 at 9:53:56 PM UTC-5, eglue wrote:
>
> I've been stalking Clojure for a while but now doing it professionally 
> full-time (woo hoo!).
>
> I saw a Stuart Halloway tweet responding to someone who'd found it a 
> "soul-crushing, miserable experience."
>
> I had a similar miserable experience and figured it was just me, but am 
> now suspecting that's not the case. (Happy to be shown the light however.)
>
> Stuart H posted https://github.com/stuarthalloway/clojure-from-java 
> 
>  to 
> demonstrate the ease of Java consuming Clojure, but I find it far more 
> important to be able to *compile* Java against Clojure interfaces not 
> invoke it dynamically from Javabecause dynamic invocation from Java is 
> unwieldy to the point of it being a likely deal breaker for any Java shop. 
> Dynamically loading classes and invoking methods c'mon, no one's going 
> to ask their Java devs to do this.
>
> If Clojure doesn't have a good compile-time consumption story for Java 
> consumers, I think that's a loss. (Even if it is just providing better docs 
> or archetype/bootstrap examples in this regard.) Because otherwise Java 
> code bases around the world could be eaten away by (compiled) Clojure from 
> the inside out, giving Java dev teams enough time to be overtaken by the 
> miracle that is Clojure.
>
> Inspired by Stuart's example, I was successful in putting together a quick 
> build to achieve this ideal: https://github.com/atdixon/clojure-from-java 
> 
>
> However, I have a few open questions:
>
> - when I tried to AOT only the public-facing clojure code that I needed to 
> compile against, I found out at runtime that this wasn't going to work. 
> Dynamic clojure code was loading my same types into DynamicClassLoader and 
> when my statically-compiled, root-class-loaded code was getting executed 
> the ClassCastExceptions of course were flying. So am I right to think that 
> you have to AOT everything in order to do this right?
> - IDE support (for me, Cursive) "works" but is non-ideal; you have to 
> manually compile the dependee/Clojure jar, then Cursive will let you 
> execute Java code against the manually aot-compiled Clojure code 
> - AOT producing generics/generic types doens't seem to be part of any of 
> this... is this a lacuna in the Clojure AOT space, are there libs that can 
> help here?
>
> This story ^^, if made easier, seems to me would boost Clojure 

Re: spec error output in web context

[Alex Miller]

On Sun, Jun 9, 2019 at 8:43 AM 'Sven Richter' via Clojure <
clojure@googlegroups.com> wrote:

> Hi Alex,
>
> I tracked it down to a minimal example with an explanation here:
> https://gist.github.com/sveri/1aaad9b12a8ec90d243206ab3b6073e3
>
> The short version is. Running a specced function in the clj repl will
> produce meaningful output, while running in the web context with immutant
> will print a stacktrace with the ExceptionInfo exception.
>
> I also tried to catch the exception and *(-> ex Throwable->map
> clojure.main/ex-triage clojure.main/ex-str) *as you suggested, which
> works. But like I said, I would not want to check for exceptions during
> production that are only thrown during development.
>

The generic question here is "what happens when my web request handler
throws an unexpected exception?" An exception can be thrown in either dev
or prod. "spec" errors are not special in this regard. Yes, you happen to
be doing some extra checking in dev, but in either case you want to
properly handle exceptions. The error handling chain above will give you
better output for all exceptions, not just spec.


>
> Do you know of a different way? Maybe a middleware would be feasible that
> is only added during development?
>

The question of how to handle exceptions in immutant is an immutant
question. If you read the docstring of immutant.web/run, it tells you how
to do it for ring handlers:

   For ring handlers, the actual writing of the response happens after
   your hander returns. If an exception occurs on the write (the most
   common case being an IOException because the client has gone away),
   the default behavior is to log the exception.

*If you would like to   be able to handle that exception yourself, you can
return a function   in the ring response under :write-error-handler.* This
function will
   be called with the exception, the request map, and the response map
   if an exception occurs when writing the response. Note that this
   handler can't actually affect the response.
*If you would prefer   a global handler, see
immutant.web.middleware/wrap-write-error-handling*.

It might be a reasonable improvement to immutant to do this better error
printing by default (with the caveat that you have to be on Clojure 1.10 to
do so).


> What does the clj repl do to produce that output?
>

It catches exceptions during the read, eval, and print phases and calls
(-> ex Throwable->map clojure.main/ex-triage clojure.main/ex-str)


> Thank you for your time,
> Sven
>
> Am Samstag, 8. Juni 2019 20:52:27 UTC+2 schrieb Alex Miller:
>>
>>
>>
>> On Saturday, June 8, 2019 at 1:41:59 AM UTC-5, Sven Richter wrote:
>>>
>>>
>>>
>>> Am Freitag, 7. Juni 2019 15:35:41 UTC+2 schrieb Alex Miller:
>>>>
>>>> How do you start the web server?
>>>>
>>> I use component to startup immutant web, I also tried with http-kit, but
>>> that didnt make a difference.
>>>
>>
>> What I mean is, what command do you use? Are using "lein ring server" or
>> something like that?
>>
>>
>>>
>>> Who is printing the error?
>>>>
>>> I think thats the key point here, right now I dont know as I never
>>> bothered to figure out who prints the stacktraces.
>>>
>>
>> I don't think you're going to be able to improve this without
>> understanding the answer to that question.
>>
>>
>>>
>>>
>>>> There are functions available in clojure.main to replicate the message
>>>> from the repl - you can call them yourself.
>>>>
>>>> See https://clojure.org/reference/repl_and_main#_error_printing for
>>>> more on error triage and the functions like Throwable>map,
>>>> clojure.main/ex-triage, and clojure.main/ex-str. This chain of functions is
>>>> what the REPL uses to produce the message below
>>>>
>>>
>>>
>>> Thanks, I will try that, but that would mean I will have to catch every
>>> potential ExceptionInfo error and check if its a spec error which is pretty
>>> cumbersome, especially as I only want to see these outputs during
>>> development (instrument is turned off in production).
>>>
>>
>> The triage process knows how to print a good message for any error, not
>> just a spec instrumentation error. There shouldn't be any conditional
>> needed.
>>
>>
>>>
>>> Thanks,
>>>
>>> Sven
>>>
>>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to

Re: spec error output in web context

[Alex Miller]

On Saturday, June 8, 2019 at 1:41:59 AM UTC-5, Sven Richter wrote:
>
>
>
> Am Freitag, 7. Juni 2019 15:35:41 UTC+2 schrieb Alex Miller:
>>
>> How do you start the web server?
>>
> I use component to startup immutant web, I also tried with http-kit, but 
> that didnt make a difference.
>

What I mean is, what command do you use? Are using "lein ring server" or 
something like that?
 

>
> Who is printing the error?
>>
> I think thats the key point here, right now I dont know as I never 
> bothered to figure out who prints the stacktraces.
>

I don't think you're going to be able to improve this without understanding 
the answer to that question. 
 

>
>
>> There are functions available in clojure.main to replicate the message 
>> from the repl - you can call them yourself.
>>  
>> See https://clojure.org/reference/repl_and_main#_error_printing for more 
>> on error triage and the functions like Throwable>map, 
>> clojure.main/ex-triage, and clojure.main/ex-str. This chain of functions is 
>> what the REPL uses to produce the message below
>>
>
>
> Thanks, I will try that, but that would mean I will have to catch every 
> potential ExceptionInfo error and check if its a spec error which is pretty 
> cumbersome, especially as I only want to see these outputs during 
> development (instrument is turned off in production).
>

The triage process knows how to print a good message for any error, not 
just a spec instrumentation error. There shouldn't be any conditional 
needed.
 

>
> Thanks,
>
> Sven
>
>

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

Re: spec error output in web context

[Alex Miller]

How do you start the web server?
Who is printing the error?

There are functions available in clojure.main to replicate the message from 
the repl - you can call them yourself.
 
See https://clojure.org/reference/repl_and_main#_error_printing for more on 
error triage and the functions like Throwable>map, clojure.main/ex-triage, 
and clojure.main/ex-str. This chain of functions is what the REPL uses to 
produce the message below


On Friday, June 7, 2019 at 8:28:56 AM UTC-5, Sven Richter wrote:
>
> Hi,
>
> I just recently found out that the spec error reporting is different in 
> different environments.
> I have the following functions:
>
>
> (defn search-page [{:keys [off-url off-user off-password]} search]
>   (let [products (off/search-products search)
> products-with-nutriments (mapv #(off/add-nutriments % 
> off/nutriments-to-extract) (:products products))]
> (layout/render "off/search.html" {:products products-with-nutriments 
> :search search})))
>
>
> (defn off-routes [config]
>   (routes (GET "/off/search" [] (search-page config "toast"
>
> where off/add-nutriments is a specced function. Now when the spec of that 
> function fails and I call *search-page* from the REPL I get this output:
>
> Execution error - invalid arguments to off/add-nutriments at (core.clj:9).
> "" - failed: #{"kJ" "kcal" "kCal" "g" "mg"} at: [:product :nutriments 
> :clojure.spec.alpha/pred :sugars_unit] spec: :off/unit
> "" - failed: #{"kJ" "kcal" "kCal" "g" "mg"} at: [:product :nutriments 
> :clojure.spec.alpha/pred :fat_unit] spec: :off/unit
> "" - failed: #{"kJ" "kcal" "kCal" "g" "mg"} at: [:product :nutriments 
> :clojure.spec.alpha/pred :salt_unit] spec: :off/unit
> {:salt "3.5", :sugars_unit "", :energy-kcal "201.81514210652017", 
> :energy_unit "kcal", :energy_value 202, :proteins_value "17.6", 
> :proteins_unit "", :carbohydrates_unit "", :saturated-fat_value "8.2", :fat 
> 12, :energy 845, :salt_value "3.5", :saturated-fat_unit "", :fat_100g 12, 
> :sugars_value 6, :sodium_100g "1.37795275590551", :carbohydrates_value 6, 
> :proteins_100g "17.6", :fat_unit "", :saturated-fat "8.2", :sugars_100g 6, 
> :sodium "1.37795275590551", :sugars 6, :carbohydrates 6, :energy_100g 845, 
> :salt_100g "3.5", :saturated-fat_100g "8.2", :salt_unit "", 
> :carbohydrates_100g 6, :proteins "17.6", :fat_value 12} - failed: nil? at: 
> [:product :nutriments :clojure.spec.alpha/nil] spec: :off/nutriments
>
> which is nice and readable.
>
> Whereas when I run the *search-page* from the started web server through the 
> */off/search* route I get a stacktrace and a very unreadable output:
>
> clojure.lang.ExceptionInfo: Call to 
> #'de.sveri.getless.service.off/add-nutriments did not conform to spec. 
> {:clojure.spec.alpha/problems ({:path [:product :nutriments 
> :clojure.spec.alpha/nil], :pred nil?, :val {:salt "3.5", :sugars_unit "", 
> :energy-kcal "201.81514210652017", :energy_unit "kcal", :energy_value 202, 
> :proteins_value "17.6", :proteins_unit "", :carbohydrates_unit "", 
> :saturated-fat_value "8.2", :fat 12, :energy 845, :salt_value "3.5", 
> :saturated-fat_unit "", :fat_100g 12, :sugars_value 6, :sodium_100g 
> "1.37795275590551", :carbohydrates_value 6, :proteins_100g "17.6", :fat_unit 
> "", :saturated-fat "8.2", :sugars_100g 6, :sodium "1.37795275590551", :sugars 
> 6, :carbohydrates 6, :energy_100g 845, :salt_100g "3.5", :saturated-fat_100g 
> "8.2", :salt_unit "", :carbohydrates_100g 6, :proteins "17.6", :fat_value 
> 12}, :via [:de.sveri.getless.service.off/nutriments], :in [0 :nutriments]} 
> {:path [:product :nutriments :clojure.spec.alpha/pred :sugars_unit], :pred 
> #{"kJ" "kcal" "kCal" "g" "mg"}, :val "", :via 
> [:de.sveri.getless.service.off/nutriments 
> :de.sveri.getless.service.off/unit], :in [0 :nutriments :sugars_unit]} {:path 
> [:product :nutriments :clojure.spec.alpha/pred :fat_unit], :pred #{"kJ" 
> "kcal" "kCal" "g" "mg"}, :val "", :via 
> [:de.sveri.getless.service.off/nutriments 
> :de.sveri.getless.service.off/unit], :in [0 :nutriments :fat_unit]} {:path 
> [:product :nutriments :clojure.spec.alpha/pred :salt_unit], :pred #{"kJ" 
> "kcal" "kCal" "g" "mg"}, :val "", :via 
> [:de.sveri.getless.service.off/nutriments 
> :de.sveri.getless.service.off/unit], :in [0 :nutriments :salt_unit]}), 
> :clojure.spec.alpha/spec 
> #object[clojure.spec.alpha$regex_spec_impl$reify__2509 0x302765e4 
> "clojure.spec.alpha$regex_spec_impl$reify__2509@302765e4"], 
> :clojure.spec.alpha/value ({:image_thumb_url 
> "https://static.openfoodfacts.org/images/products/20987664/front_de.3.100.jpg;,
>  :_keywords ["schmelzkase" "light" "toast"], :image_small_url 
> "https://static.openfoodfacts.org/images/products/20987664/front_de.3.200.jpg;,
>  :nutriments {:salt "3.5", :sugars_unit "", :energy-kcal 
> "201.81514210652017", :energy_unit "kcal", :energy_value 202, :proteins_value 
> "17.6", :proteins_unit "", :carbohydrates_unit "", :saturated-fat_value 
> "8.2", :fat 12, :energy 845, :salt_value "3.5", 

Re: [ANN] Clojure 1.10.1

[Alex Miller]

Correct, no changes were made between 1.10.1-RC1 and 1.10.1.

On Thu, Jun 6, 2019 at 11:31 AM Sean Corfield  wrote:

> Thanks for all the work on this!
>
> Can you confirm that this is the same as 1.10.1-RC1?
>
> Sean
>
> On Thursday, June 6, 2019 at 8:28:17 AM UTC-7, Alex Miller wrote:
>>
>> Clojure 1.10.1 is a small release focusing on two issues: working around
>> a Java performance regression and improving error reporting from
>> clojure.main.
>>
>> <https://clojure.org/news/2019/06/06/clojure1-10-1#_java_performance_regression>Java
>> performance regression
>>
>> Recent builds of Java 8 (u202), 11 (11.0.2), 12, and 13 included some
>> changes that drastically affect optimization performance of calls from
>> static initializers to static fields. Clojure provides support for loading
>> code on startup from a user.clj file and this occurred in the static
>> initializer of the Clojure runtime (RT) class and was thus affected.
>>
>> This issue may eventually be resolved in Java, but in Clojure we have
>> modified runtime initialization to avoid loading user.clj in a static
>> initializer, which mitigates the case where this caused a performance
>> degradation.
>>
>> <https://clojure.org/news/2019/06/06/clojure1-10-1#_clojure_main_error_reporting>clojure.main
>> error reporting
>>
>> clojure.main is frequently used as a Clojure program launcher by external
>> tools. Previously, uncaught exceptions would be automatically printed by
>> the JVM, which would also print the stack trace.
>>
>> This release will now catch exceptions and use the same error triage and
>> printing functionality as the Clojure repl. The full stack trace, ex-info,
>> and other information will be printed to a target specified by the
>> configuration. See clojure.main docs
>> <https://clojure.org/reference/repl_and_main#_error_printing> for
>> configuration details.
>> <https://clojure.org/news/2019/06/06/clojure1-10-1#_changelog>Changelog
>>
>> See the change log
>> <https://github.com/clojure/clojure/blob/master/changes.md#changes-to-clojure-in-version-1101>
>>  for
>> a complete list of all changes in Clojure 1.10.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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/dkfAXW9lZxk/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/01fe6d24-ae4a-409e-989e-987760b389a9%40googlegroups.com
> <https://groups.google.com/d/msgid/clojure/01fe6d24-ae4a-409e-989e-987760b389a9%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Use invokedynamic instead of the reflection API when possible

[Alex Miller]

Hi Rémi! Thanks for all your work on ASM and other JVM stuff over the years 
by the way.

We have of course been poking at indy off and on over the years and there 
have been a number of experiments with it. Ghadi Shayban has probably done 
the most work on that and he probably has more useful feedback than I would 
on the technical aspects of the code.

Based on where we are in the release cycle right now, I expect that we 
probably aren't ready to engage with this today and it might be a couple 
months before we are in the meat of the next release and open to it. Some 
quick thoughts and questions though...

1. As with anything we work on, we don't stuff just because it's possible 
to do but because it satisfies some objective that seems worth doing. I 
assume the target benefit here is performance, but is that really it? Are 
there other benefits? Are there downsides to using indy vs reflection?

One big thing here is that generally we expect people to remove reflective 
calls in performance-sensitive code via type hints (and some people more 
thoroughly try to remove all use of reflection). Thus my expectation would 
be that the majority of users would experience no improvement or 
improvements only in parts of the code that are considered not important 
from a performance perspective. If we're adding code that increases 
ambiguity (via having multiple invocation paths which might have different 
failure modes) without a lot of benefit to users, then that prioritizes 
this pretty far down the list for me.

2. You mentioned the caller sensitive stuff - can you point at some 
resources about what those are? I guess those are calls checking security 
policy, etc? 

3. We did some work in the last release to avoid reflective calls to 
module-private methods, by modifying our reflective search to prefer 
interfaces or classes that are module accessible. Does module accessibility 
affect indy calls as well?

4. Clojure has very few compiler / RT flags (and it's most common to use 
none of them), and that's pretty intentional. Ideally we would not want a 
clojure.compiler.emit-indy flag but maybe you added this just to make the 
new work switchable. 

5. We are somewhat sensitive to trying to make AOT-compiled code work with 
later Clojure runtimes as much as possible (we don't guarantee binary 
compatibility but we have a very good track record here and try to never 
break that expectation). As such, we generally never change signatures in 
RT or Reflector or other important interfaces and make only additive 
changes. I think this patch is additive in that way, so that's good, but 
would want to carefully consider the new publicly accessible methods in 
Reflector (as we'd be supporting them forever), like the change in 
toAccessibleSuperMethod (which I'm not sure is needed?). 

There are other imo far more interesting possible uses for indy in places 
where we care a great deal about performance and those are places where I 
would place a lot higher priority. Ghadi, in particular, has investigated 
options for lazy-initing vars which could have a noticeable impact on 
startup performance while minimizing the effect on subsequent calls like 
other approaches that have been tried. Anyways, he can probably chime in on 
that more.

Alex



On Wednesday, May 22, 2019 at 6:16:58 PM UTC-5, Rémi Forax wrote:
>
> Hi all,
> now that Clojure is compatible with java 8, it can use invokedynamic where 
> it makes sense, i.e. when the compiler has no information to generate 
> directly the call in bytecode, instead of using the reflection API.
>
> In fact, it's a little more complex than that,
> - you can not fully replace all calls to the reflective API to use 
> invokedynamic instead, because you have restriction on the methods you can 
> call (you can not call a method annotated with @CallerSensitive for 
> security reason) and
> - using the method handle API doesn't necessary means that the calls will 
> be faster than using the reflection API if the JIT is not able to inline 
> the calls.
>
> So the idea of the patch is to always generate invokedynamic at compile 
> time but at runtime to use the methodhandle API if there is a good chance 
> that the call will be inlined and fallback to call the Reflector API 
> otherwise.
>
> Obviously, i've not read how to contribute before writing the patch, so 
> the patch is currently available on github
>   https://github.com/clojure/clojure/pull/85
>
> So now that i've read how to contribute, i think the first question to ask 
> is:
> does it make sense to allow the Clojure to use invokedynamic ?
>
> regards,
> Rémi
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this 

Re: Macro help/strategy for writing a tiny DSL for circuit-model quantum computing?

[Alex Miller]

My general advice would be not to start with macros. 

1. Start with data - what are the entities (bits? gates?), and how do you 
represent them? It's ok (actually better) for these to be verbose. Plan for 
extension (maps are open, which is why they're so common in representing 
data in Clojure).
2. Create functions that manipulate that take and return that data.
3. Decide what you actually want to write to capture the domain operations 
- how do you represent these in "function-like" forms.
4. Write macros that translate #3 into #2 using #1.
5. Bask in the warm glow of a job well done.

On Wednesday, May 15, 2019 at 1:56:30 PM UTC-5, Vic Putz wrote:
>
> ...which sounds a LOT more complex than it is.  I don't care about 
> simulation--there are great Python-based packages for that.  I don't even 
> care about verification or optimization yet; I just want to generate a data 
> structure that's exportable in, say, EDN that I can write a parser for in 
> Python.
>
> So... I'm dabbling in quantum computing, and the way these things work, 
> loosely, is that you have a fairly small address space (Google's 
> Bristlecone has 72 bits, and that's HUGE), and you basically apply "gates" 
> (atomic operations) to one, two, or occasionally three bits at a time.  
> That's basically it--you can have larger operations, but at the end of they 
> day they get broken down into 1/2/3-qubit gates.
>
> Right now the available kits use python to create these, and it just feels 
> clunky... not even like writing assembler, but like writing Python code to 
> write assembler, and there's no separation of data structure from execution 
> environment.  I figure at the end of the day you're just making lists of 
> operations; if only there was a language suited for list processing!  :)
>
> Example: here's Python code for a "bell pair" (when measured, both bits 
> are either 0 or 1), from ProjectQ, one of the Python libraries:
>
> # The H operator is defined as an object elsewhere
> # because ProjectQ mixes the construction of the quantum
> # code with its execution:
> # create a main compiler engine
> eng = MainEngine()
>
> # allocate one qubit
> b1 = eng.allocate_qubit()
> b2 = eng.allocate_qubit()
>
> # put it in superposition
> H | b1
> CNOT | (b1, b2)
>
> # measure
> Measure | q1
> Measure | q2
>
> eng.flush()
> # print the result:
> print("Measured: {}{}".format(int(q1),int(q2)))
>
>
> What I'd like to see is something more like
>
> ;; declare H to be a 1-bit gate and CNOT to be a 2-bit gate
> ;; note these don't have to DO anything here as long as they can
> ;; be interpreted in the Python backends
> (defgate H 1)
> (defgate CNOT 2)
>
> (defq-fn bell-pair [b1 b2]
>   (H b1)
>   (CNOT b1 b2))
>
> (defq-pgm run-bell-pair []
>   (let [b1 (allocate-bit 1)   ;; variable of one qubit
>  b2 (allocate-bit 1)]  ;; same
>   (bell-pair b1 b2)
>   (measure b1 b2))
>
> ...where gates behave like functions (so you can use partial, map, etc, 
> like (map (partial CNOT 1) [b1 b2 b3])
>
> And doing say (bell-pair 1 2) would spit out EDN
>
> ((:H 1)
>  (:CNOT 1 2))
>
> and (run-bell-pair) might parse everything, include extra data about the 
> necessary machine, and reassign variables to allocated bits
>
> {:machine {:bitsize 2} ; calculated because only two bits were allocated 
> in all the subsidiary code
>  :code ((:block {:name bell-pair 
>  :code (:H 0) (:CNOT 0 1) (:measure 0 1)}))}
>
> That sort of thing (the ":block" idea is mostly to delineate "where you 
> are" in the output program, and to group operations for display).  Then I 
> could write a parser in Python for the simulators and such (or rewrite the 
> Clojure code for Hylang, which is its own exercise, but I could use the 
> Python libs directly then).  There are other things I'd like (allocate 
> multi-bit variables, and apply gates to individual bits of those, like to 
> have the idea of reusing bits once they're measured and done with, that 
> sort of thing) but this is a start.
>
> On the surface, this looks really easy--you're just generating and 
> traversing data structures--but it's funny how hard I'm finding it because 
> it's key that you can execute proper computational code within (to do 
> things like determine angles for parameterized gates, apply gates in 
> complex ways to sequences, etc).  
>
> I created a defgate macro that generated function stubs for gates that 
> created EDN for gates; that was easy.  But properly doing the "defq-fn" 
> macro is eluding me.  I want it to return a list of the gates' data 
> structures, but if I just eval the given form, I'll only get the last 
> result and (do...) to get a sequence is tricky because we're mixing gates 
> and clojure code.  I tried a solution where the generated "gate" functions 
> would call an "emit" function which appended to a module-level variable, 
> and that srta worked, but it's not elegant (and not threadsafe).
>
> Ideally the defq-fn macro would create a 

Re: No "clojure --version" switch

[Alex Miller]

Thanks!

On Wed, May 8, 2019 at 11:49 AM Alan Thompson  wrote:

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

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

Re: No "clojure --version" switch

[Alex Miller]

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.

No "clojure --version" switch

[Alex Miller]

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 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/d679ae95-13f3-41a7-a3ba-f90a5839ba8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Compiler error message misses the target

[Alex Miller]

I would definitely be interested in understanding and improving that error 
reporting. What was the command you ran to produce the error and can you make a 
smaller self contained repro? 

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

[ARTICLE] Shenandoah GC in production: experience report

[Alex Miller]

Excellent write up, thanks for doing that.

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

Re: clojure.data.csv/write-csv isn't thread safe (should it be?)

[Alex Miller]

I think the vast majority of the time, people are writing a csv file in a 
single thread. Issue/patch welcome though...

On Thursday, May 2, 2019 at 7:59:05 AM UTC-5, matt@gmail.com wrote:
>
> The write-csv function in clojure.data.csv isn't thread safe because even 
> though it uses the synchronized .write method on BufferedReader, it does so 
> at 
> the cell level 
> ,
>  
> not the row/line level. Is this expected or a bug? Is there a reason it 
> shouldn't be made thread safe?
>
> Attached is a simple test showing the result of calling write-csv with a 
> single thread vs. 100 threads. With a single thread, the output is correct, 
> and with 100 threads the result is a jumbled mess. Conversely, if I use 
> clojure-csv  and manually 
> write at the row level using the same harness, it works as expected with 
> multiple threads.
>

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

Re: Add support for seq on Java streams?

[Alex Miller]

We have been looking at how to provide default interop for some of the function 
APIs, and this seems equally interesting now. I don’t recall a ticket for this 
in particular so feel free to make one. Needs some assessment of course.

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

Quick question on spec alpha 2

[Alex Miller]

It’s equivalent. Schemas have no “structure”.

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

[Alex Miller]

You could put it in user.clj, but it would be reasonable to have a ticket 
for this.

On Sunday, March 31, 2019 at 8:58:30 PM UTC-5, Ben Brinckerhoff wrote:
>
> I see that this handler uses `ex-str`, which is nice because `ex-str` in 
> turn calls `*explain-out*` which is user-configurable. 
>
> Is there a recommended way to configure `s/*explain-out*` such that this 
> configuration will be run before other namespaces are loaded?
>
> For instance, this code would set up Expound, but right now I'm not sure 
> how to reliably run it before other namespaces load:
>
> (require '[expound.alpha :as expound] '[clojure.spec.alpha :as s])
> (alter-var-root #'s/*explain-out* (constantly (expound/custom-printer 
> {:print-specs? false :show-valid-values? true :theme :figwheel-theme})))
>
> Thanks,
> Ben
>
>

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

Re: regex in edn?

[Alex Miller]

There are edn impls in at least 15 languages so the problem is wider than just 
java and js.

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

pprint

[Alex Miller]

jira/patch welcome...

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

[Alex Miller]

That sounds like a different problem, don’t think Clojure 1.10.1-beta1 would 
affect anything there.

> On Mar 23, 2019, at 5:57 PM, David Neu  wrote:
> 
> Hi Alex,
> 
> I had been getting 
> 
> Error: Could not find or load main class clojure.main
> Caused by: java.lang.ClassNotFoundException: clojure.main
> 
> when starting a socket repl with a custom repl function, e.g.
> 
>  :aliases
>  {:socket {:jvm-opts 
> ["-Dclojure.server.repl={:port,,:accept,somelib.repl/socket-repl}"]}}
> 
> This RC eliminates that issue.   Many, many thanks!
> 
> Cheers,
> Dave
> 
> 
>> On Friday, March 22, 2019 at 12:35:32 AM UTC-4, 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/0YFGUdzCZ5U/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: No matching field found: length for class byte array

[Alex Miller]

Too far down the slippery slope for me.

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

Re: spec with schema and select?

[Alex Miller]

Not yet, although I am working on select at the moment for spec 2 
(at https://github.com/clojure/spec-alpha2). schema, as described in that 
talk, is still TBD in terms of how it will end up. You might also be 
interested in following my weekly journals at http://insideclojure.org to 
track what we're up to.


On Thursday, March 7, 2019 at 1:13:53 PM UTC-6, Rob Nikander wrote:
>
> Hi,
>
> I just watched a chunk of this talk from a few months ago ("Maybe Not" 
> [1]). Is there a pre-release version of spec available, that has `schema` 
> and `select` in it? I have a project where I'm fine with using bleeding 
> edge stuff that will change.
>
> Rob
>
> [1]: https://www.youtube.com/watch?v=YR5WdGrpoug
>

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

Re: Exploring the (tap>) functions

[Alex Miller]

On Saturday, March 2, 2019 at 1:23:21 PM UTC-6, Glen Mailer wrote:
>
> Hello All
>
> I was wondering if there is an annoucement or a rationale doc coming for 
> (tap>) and it's related functions? The current docstrings do a good job of 
> telling you what they do and how to use them, but the docs on the homepage 
>  seem quite open-ended. 
> Was there a particular motivating case which led to their inclusion in core?
>

tap is primarily intended for pr-style debugging. When you need that kind 
of debugging, you don't want to include an additional library or muck with 
your requires, so tap> is in core.
 

>
> I've been playing around with them a bit, a colleague of mine was using 
> them for local debugging, but then we were unsure whether it made sense to 
> leave them committed when the code shipped to production. I've also been 
> experimenting with extending our logging protocol to send all of the 
> application logs to tap, where they can be siphoned off elsewhere.
>

I don't think you should send stuff to tap> willy-nilly, but might make 
sense to have that as an option.
 

> One thing I did find a bit unusual was that although these are somewhat 
> similar to `add-watch` and `remove-watch`, there is no `reference` 
> argument, so if a function is re-evaled then it can be easy to lose the 
> original and be unable to `remove-tap` without reaching into the private 
> set. Is there a reason for this omission? I'm fairly confident that a 
> backwards-compatible extension to take an optional reference could be added 
> if not, defaulting to the fn itself. Failing that, a `clear-taps` fn might 
> be desirable.
>

Again, in a debug mode, you're generally dynamically adding and removing a 
tap function dynamically so it's not really an issue. That said, feel free 
to file an issue on the problem here (losing the function reference via 
re-eval).
 

>
> Thanks
> Glen
>
>
>

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

[Alex Miller]

Please file a jira with this info at https://dev.clojure.org/jira/browse/CLJ

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

Re: Customizable project .cpcache path

[Alex Miller]

File a ticket... https://dev.clojure.org/jira/browse/TDEPS

Please start with the problem - not being able to use in a directory which 
is not writable, which may have many solutions.

On Monday, February 25, 2019 at 10:51:24 AM UTC-6, Stanislav Yurin wrote:
>
> Currently user cache is customizable via CLJ_CACHE or CLJ_CONFIG (and 
> XDG_..) environment variables,
> but inside project dir the path is set by the following code in clojure 
> tools bash script:
>
> # Determine whether to use user or project cache
> if [[ -f deps.edn ]]; then
>   cache_dir=.cpcache
> else
>   cache_dir="$user_cache_dir"
> fi
>
> Which is not always desirable in deployments when project dir is not 
> writeable (e.g. application code is not in home directory)
> Is it reasonable to add something like CLJ_PROJECT_CACHE or there is a 
> reason to keep it static?
>
> Thanks!
>
>

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

Re: type function returning a NullPointerException

[Alex Miller]

What's the stack trace when you get an NPE? (pst *e)

Are you shadowing a core function with your own `count` or something like 
that?

On Friday, February 15, 2019 at 8:27:55 AM UTC-6, KJO wrote:
>
> Hi-
>
> This one has me stumped. The following code snippet throws a 
> NullPointerException and I just can't understand how it could.
>
> (if (set? t-val)
>   (println t-val (type t-val)))
>
> It seems that if it's a set, it should have a set type.
>
> If I change the code to 
>
> (if (set? t-val)
>   (println t-val (count t-val)))
>
> It throws a ClassCastException
> with java.math.BigDecimal cannot be cast to clojure.lang.IFn
>
> The println is only there for debugging. I was seeing the count function 
> throwing an exception further down in the code, and I couldn't understand 
> why. Any ideas?
>
> t-val is defined in a let, but if I take it out and use the original 
> value, the result is the same. I'm afraid I can't reproduce the error in 
> the REPL using any of the values I captured. The only other thing I can 
> offer is that it's being used in a reducing function over a lazy sequence.
>
> I'm stumped.
>
> Thanks
>
>

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

Re: Compiling with load instead of compile?

[Alex Miller]

On Wednesday, February 13, 2019 at 7:46:43 PM UTC-6, Didier wrote:
>
> Hey all,
>
> I've been working on internal build tools where I work, and when looking 
> into how other build tools like lein do their aot :all compilation, it 
> seems that they all rely on some brittle namespace finder library, which 
> searches either the classpath, or a folder of files and tries to identity 
> all the ns declarations.
>

Or you use a hard-coded list (like the Clojure build itself).
 

> From that, they call compile in a loop for every namespace they found. 
> But, compile just goes ahead and converts the namespace into a resource 
> path in a very brittle way, just replaces dots for forward slashes, and 
> dashes by underscores.
>

This is exactly the algorithm used by the runtime to load every Clojure 
namespace, so I don't think this particular part is brittle at all.
 

> That's because, `load-one` is actually used to compile, which internally 
> relies on `load`. Load takes a resource path which needs to be found on the 
> classpath, not a namespace.
>
> Now, there are some packages which have source files that have either a 
> different ns name then their file name
>

This is pretty rare as it's impossible for the runtime to load it in the 
normal way when required (it must be explicitly loaded via one of the load 
methods).
 

> , or they use in-ns and are actually evaluating into an existing namespace 
> defined in another file.
>

Slightly more common, but still comparatively rare to the very common case 
of 1 ns per file. (clojure itself does this a number of times)
 

> Lein actually fails to compile these, because the namespace it finds are 
> looked up as resources on the classpath by compile and it can't find the 
> resource, because the resource path does not match the namespace.
>
> So, for my build tool aot :all compilation, I decided to instead use 
> `load` with *compile-files* bound to true. And I just convert each source 
> file in the source dir to a classpath resource path.
>
> From my perspective, this seems a better way to do it, that is more 
> reliable, and frankly a lot simpler. But since no one
>
else did it this way, I'm curious if there is any known issue with this 
> approach?
>
 
Seems like a reasonable alternative to me.


> Regards!
>

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

[Alex Miller]

Oh, I mistakenly misread the successful test pass as a merge. Should be 
available in the next half day or so. (Or just 
watch https://github.com/Homebrew/homebrew-core/pull/36964)


On Wednesday, February 13, 2019 at 3:27:00 PM UTC-6, Sean Corfield wrote:
>
> Does it take some time for the brew repo to update? I'm getting this:
>
> (! 520)-> brew upgrade clojure
> Error: clojure 1.10.0.411 already installed
>
>
> And brew update says everything is up to date.
>
> Sean
>
> On Wednesday, February 13, 2019 at 12:19:03 PM UTC-8, Alex Miller wrote:
>>
>> tools.deps.alpha 0.6.488 and clj 1.10.0.414 are now available. 
>>
>> Changes:
>>
>> * TDEPS-114 Canonicalize Maven RELEASE or LATEST version marker
>> * Error handling improvements for unresolvable Maven versions
>>
>> If on Mac, use `brew upgrade clojure` or on Linux see 
>> https://clojure.org/guides/getting_started for updated scripts.
>>
>

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

[Alex Miller]

tools.deps.alpha 0.6.488 and clj 1.10.0.414 are now available. 

Changes:

* TDEPS-114 Canonicalize Maven RELEASE or LATEST version marker
* Error handling improvements for unresolvable Maven versions

If on Mac, use `brew upgrade clojure` or on Linux see 
https://clojure.org/guides/getting_started for updated scripts.

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

[Alex Miller]

Without spending more time poking around, it's hard for me to say exactly 
what the problem is, and whether it's a bug, enhancement, or won't fix. 
Having written a lot of Clojure code in the 8 or 9 years, I've run into 
head holding problems a couple times maybe. In general, it's usually not an 
issue (and it's usually pretty obvious that something's wrong). In general, 
I would not be afraid of lazy seqs just because of this. Locals are 
automatically cleared, avoiding head holding, in the vast majority of cases 
you typically run into.

On Wednesday, February 6, 2019 at 12:27:21 PM UTC-6, Lars Rune Nøstdal 
wrote:
>
>
>
> On Wednesday, February 6, 2019 at 5:15:53 PM UTC+2, Alex Miller wrote:
>>
>> I think the condition here means that the loop compilation can't tell 
>> that the s local is definitely out of scope and can be cleared, so you end 
>> up holding the head.
>>
>> While there is some analysis here, we're not doing inference level stuff 
>> on the "if false" to knock out branches etc and generally that's not the 
>> kind of thing we try to do.
>>
>
> I.e. WONTFIX? Using lazy sequences is or can be pretty dangerous without 
> plenty and frequent testing, then -- since "don't hold onto the head" means 
> one will have to take into account whatever code the compiler and/or 
> libraries (c.c.async?) may or may not generate behind the scenes based on 
> subtleties. 
>
> H ...anyway, I'll try to work around this; perhaps by avoiding lazy 
> sequences altogether. For me switching to clojure.core.async and doing 
> something like this *seems* to have worked (perhaps useful for others who 
> find this thread later):
>
>- wrap the range (or infinite or long sequence really) in a *source* 
>chan <https://clojuredocs.org/clojure.core.async/chan>.
>- do the transformation in a *middle* chan; noting that the chan Fn 
>takes an xform arg.
>- pipe <https://clojuredocs.org/clojure.core.async/pipe> the *middle* chan 
>to your final *output* chan. something like: *(async/pipe 
>(handle-source-chan (async/chan 1000 xform) ...) output-chan)*
>
> ...it's a bit tricky to setup -- but yeah; no leaks here for now. It's 
> interesting that I have a sort of more explicit buffer in the *middle* chan 
> I can fiddle around with too now!
>
> Mvh, Lars
>
>  
>
>>
>>
>> On Wednesday, February 6, 2019 at 7:57:57 AM UTC-6, Lars Rune Nøstdal 
>> wrote:
>>>
>>> Hi, so I've been staring at this for hours :
>>>
>>>
>>> (defn foo []
>>>   (let [s (range)]
>>> (if false
>>>   nil
>>>   (future
>>> (loop [s s]
>>>   (recur (rest s)))
>>>
>>>
>>> ...if I run this I run out of heap space quite fast on any of these:
>>>
>>>- Clojure: "1.11.0-master-SNAPSHOT", 1.9.0, 1.8.0 or 1.7.0
>>>- OpenJ9 0.12.1 or Oracle 11.0.2 2018-10-16 LTS
>>>
>>>
>>> ..that's what I have at hand for testing for now. If I remove the FUTURE 
>>> or place it higher up the stack it doesn't happen. I looked at a heap dump 
>>> in MAT and it seems to contain millions of empty stack frames or binding 
>>> frames (conveyor?); all held together by circular references (AFAICT).
>>>
>>> -- 
>>> Mvh, Lars Rune Nøstdal
>>> https://www.quanto.ga/
>>>
>>>

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

[Alex Miller]

I think the condition here means that the loop compilation can't tell that 
the s local is definitely out of scope and can be cleared, so you end up 
holding the head.

While there is some analysis here, we're not doing inference level stuff on 
the "if false" to knock out branches etc and generally that's not the kind 
of thing we try to do.


On Wednesday, February 6, 2019 at 7:57:57 AM UTC-6, Lars Rune Nøstdal wrote:
>
> Hi, so I've been staring at this for hours :
>
>
> (defn foo []
>   (let [s (range)]
> (if false
>   nil
>   (future
> (loop [s s]
>   (recur (rest s)))
>
>
> ...if I run this I run out of heap space quite fast on any of these:
>
>- Clojure: "1.11.0-master-SNAPSHOT", 1.9.0, 1.8.0 or 1.7.0
>- OpenJ9 0.12.1 or Oracle 11.0.2 2018-10-16 LTS
>
>
> ..that's what I have at hand for testing for now. If I remove the FUTURE 
> or place it higher up the stack it doesn't happen. I looked at a heap dump 
> in MAT and it seems to contain millions of empty stack frames or binding 
> frames (conveyor?); all held together by circular references (AFAICT).
>
> -- 
> Mvh, Lars Rune Nøstdal
> https://www.quanto.ga/
>
>

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

Re: avoiding casts with aget & friends

[Alex Miller]

Yes, there a bunch of jvm options to show you when it’s jit-ing, and even the 
rewritten code.

You can google for that stuff like LogCompilation. Occasionally I have found 
that useful.

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

Re: (gen/sample (s/gen #{'nil})): Couldn't satisfy such-that predicate

[Alex Miller]

Go for it. Not sure the type stuff is adding anything in the context of
quote examples here beyond the other explanation though.

On Thu, Jan 31, 2019 at 6:50 AM Rostislav Svoboda <
rostislav.svob...@gmail.com> wrote:

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

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