Re: what is the best forum for keeping up with Clojure?

[Sean Corfield]

The Clojurians Slack is probably the largest and most activity community these 
days – http://clojurians.net to self-signup and https://clojurians.slack.com 
for the content – but there's also https://clojureverse.org if you prefer a 
"forum" over "chat". And there's r/Clojure on Reddit – which also has a handy 
list of active Clojure communities online in the right hand column.

Also check out this list of resources on the official website: Clojure - 
Community Resources

Sean A Corfield -- (510) 862-3370
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)


From: clojure@googlegroups.com  on behalf of Laws 

Sent: Tuesday, January 9, 2024 2:46 PM
To: Clojure 
Subject: what is the best forum for keeping up with Clojure?

Hi everyone,

I did a lot with Clojure back 2012-2019, but I've been away from it for several 
years. Now I'm beginning a big new project in Clojure. I'm curious, where would 
I go to learn about the newest libraries and projects? There was a time 5 years 
ago when I knew all of the best and most interesting projects, but nowadays I 
know very little about the scene. is there any forum where people talk about 
Clojure and all that is new?


Lawrence Krubner

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

Re: Why is next.jdbc using my IP address?

[Sean Corfield]

> Okay, this seems to have to do with characters acting as wildcards in the
password itself. This is in the .env file:

I don't know what library you are using for managing your configuration but
perhaps it interprets $n as an environment variable called n and
substitutes the value (which will be empty, in general).

On Fri, Mar 4, 2022 at 5:58 AM Lawrence Krubner 
wrote:

> Okay, this seems to have to do with characters acting as wildcards in the
> password itself. This is in the .env file:
>
> vvv*8Ezr30R%$n?L5!
>
> but printlin in the Clojure code outputs:
>
> vvv*8Ezr30R%?L5!
>
> The "$n" simply vanishes.
>
> Why is that? This is not a regular expression. I didn't think plain
> strings in Clojure would be interpreted like this.
>
> Or is this how bash interprets it?
>
>
>
>
> On Friday, March 4, 2022 at 8:06:56 AM UTC-5 Lawrence Krubner wrote:
>
>> So, as a new way to test this, I've ssh'ed to an EC2 instance that is in
>> the same VCP as the RDS database. I upload my jar file so I can run it on
>> this EC2 instance.
>>
>> println the hash map at startup:
>>
>> {:dbtype mysql, :dbname pulsedata, :user pulseuser, :password , :host
>> pulse-data.cclr8stksfch.us-west-2.rds.amazonaws.com}
>> This gets me the above error. But if I copy and paste the values and use
>> them with the mysql client:
>>
>> mysql -u pulseuser -h pulse-data.cclr8stksfch.us-west-2.rds.amazonaws.com
>> -p pulsedata
>>
>> I am able to log in. This is in the same terminal window: the MySQL
>> client, at the command line in my terminal, logs me into MySQL, but "java
>> -jar user.jar" in the same terminal window gives me this error, about me
>> being rejected. I am copying and pasting the same values for user and host
>> and password.
>>
>> It has to be something about the Clojure code.
>>
>>
>> On Friday, March 4, 2022 at 6:35:59 AM UTC-5 ore...@orestis.gr wrote:
>>
>>> The error message indicates that you connect with user `pulseuser` - is
>>> that the expected user?
>>>
>>> I would print out the configuration that you’re passing in to jdbc.next
>>> to be absolutely certain it contains the values you expect it does.
>>>
>>> When you say “cli”, do you mean a mysql client? Double check the
>>> credentials (dbname, user, password) that *it* uses.
>>>
>>> Best,
>>> Orestis
>>>
>>> On 4 Mar 2022, at 13.27, Lawrence Krubner  wrote:
>>>
>>> But, again, I can connect from the cli using my terminal. I'm using my
>>> Spectrum connection to the Internet in both cases. If I run the app on my
>>> laptop, or I connect from the terminal, using the CLI, then in all cases
>>> I'm connecting over my Spectrum connection to the Internet. If MySQL was
>>> going to block one, then it would block the other, yes? I think the issue
>>> must have something to do with the Clojure code, since that is the only
>>> difference. I mean, if I do "java -jar user.jar" in the same terminal
>>> window, it fails, but then in that same terminal window I can connect to
>>> RDS without a problem using the CLI.
>>>
>>>
>>> On Thursday, March 3, 2022 at 3:26:31 PM UTC-5 red...@gmail.com wrote:
>>>
 That is a message from MySQL, not next.jdbc.

 MySQL allows you to grant permissions to a user base on the host they
 are connecting from so permission denied kinds of errors include the
 username and the host the users connection came from.

 On Thu, Mar 3, 2022, 11:18 Lawrence Krubner 
 wrote:

> I just wrote a small app that needs to connect to a MySQL app. I was
> running it on my laptop, connecting to MySQL on the laptop, and everything
> was working fine. Then I wanted to connect to one of our test databases in
> RDS in AWS. I've a simple function that finds the environment variables 
> and
> returns them as a map:
>
> (defn get-config
>   []
>   (check-config)
>   {
>:dbtype "mysql"
>:dbname (System/getenv "DATABASE_NAME")
>:user (System/getenv "DATABASE_USER")
>:password (System/getenv "DATABASE_PASSWORD")
>:host (System/getenv "DATABASE_HOST")
>})
>
> This is used simply:
>   ds (jdbc/get-datasource  (get-config))
>
> I've checked the environment values several times and they are
> correct. But when the code tries to write to the RDS database, I get:
>
> *java.sql.SQLException*: *Access denied for user
> 'pulseuser'@'cpe-74-71-234-49.nyc.res.rr.com
> ' (using password: YES)*
>
> I am connecting to the Internet through Spectrum, and apparently "
> rr.com" is Spectrum. I'm confused, why would next.jdbc use this info?
> Did I forget some important value in the hash map?
>
> From my laptop, I can reach the RDS database using the MySQL CLI, so
> there are no problems with connectivity. I whitelisted the IP address of 
> my
> house. This is something specific about what next.jdbc needs in that hash
> map, I think.
>
>
>

Re: pre and post assertions, always in the meta data?

[Sean Corfield]

Whilst you solved your problem, you didn't get an answer about metadata.

There are multiple places metadata can appear in a function definition:

dev=> (defn ^{:one true} func (^{:two true} [x] {:three true} x) {:four 
true})
#'dev/func
dev=> (meta #'func)
{:one true, :arglists ([x]), :four true, :line 1, :column 1, :file 
"/home/seanc/.clojure/dev.clj", :name func, :ns 
#object[clojure.lang.Namespace 0x17b6ad97 "dev"]}
dev=> (->> #'func (meta) :arglists (mapv meta))
[{:two true, :three true}]
dev=>

I've delineated the arity of the function with ( ) for clarity so you can 
which metadata belongs to the function Var and which belongs to a specific 
arity, and you can see they are combined.

I've never seen anything except :pre/:post in position three and I've never 
seen :pre/:post in position two (until I saw your example from ostash.dev) 
-- but as you can see they are equivalent (and they combine).

I don't think I've ever seen function Var metadata in position four.
On Thursday, February 3, 2022 at 10:56:59 AM UTC-8 Laws wrote:

>
> I see this old post by Fogus:
>
> http://blog.fogus.me/2009/12/21/clojures-pre-and-post/
>
> With this example:
>
> (defn constrained–fn [f x]
>   {:pre  [(pos? x)]
>:post [(= % (* 2 x))]}
>   (f x))
>
> But I see this modern example:
>
> https://ostash.dev/posts/2021-07-01-pre-post-conditions/
>
> (defn func ^{:pre [(pos? x)] :post [(< % 100) (> % 1)]} [x] (+ 1 x))
>
> Where it is in the metadata. 
>
> But here I still the old style:
>
> https://clojure.org/reference/special_forms
>
> (defn constrained-sqr [x] {:pre [(pos? x)] :post [(> % 16), (< % 225)]} (* 
> x x))
>
> I was away from Clojure for a few years, so I think it I missed some of 
> its evolution. Is one of these styles favored? 
>
> I'm struggling with an issue where I cannot get the error to show up, even 
> when I deliberately send in data that would cause the assertion to return 
> false. 
>
> My function started: 
>
> (defn get-cisa-advisories
>   [cisa-advisory-urls]
>   {
>:pre [(set? cisa-advisory-urls)]
>:post [(vector? %)]
>}
>   (println "get-cisa-advisories")
>   (try
>
> When I called this with a vector, I got no error, but the app silently 
> died. I'm confused about this. The call to this function is wrapped in a 
> try/catch block, and that assertion must have thrown an error because that 
> is where the app dies, yet I couldn't see the exception in my catch block. 
>

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

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

[Sean Corfield]

On Wed, Sep 15, 2021 at 11:51 AM Alan Thompson  wrote:

> You could also check out depstar
>

No, please use tools.build -- I already use it in most of my OSS projects
to build library JARs for deployment to Clojars (instead of depstar).

I've been working with Alex to close the gap between uber in tools.build
and uberjar in depstar and have already switched over to tools.build at
work for our production artifacts (again, switching away from depstar).

Once tools.build's uber has parity with depstar's uberjar, I intend to *sunset
the depstar project* to avoid continued fragmentation of tooling and I
strongly encourage everyone to look to tools.build for JAR building at this
point.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
On Wed, Sep 15, 2021 at 11:51 AM Alan Thompson  wrote:

> You could also check out depstar
>
> https://github.com/seancorfield/depstar
>
>
> On Tue, Sep 14, 2021 at 8:35 AM c y  wrote:
>
>> i can't use lein
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/485ed672-20d6-4325-bcef-5162395481f0n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAN67zA2FkKrwNb34SFvpeFQT%2B7TQ5KZb53UqKePLs8mDACQFqg%40mail.gmail.com
> 
> .
>

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

Re: [BLOG] Once Upon A Class

[Sean Corfield]

Much clearer now! Thank you!

On Mon, May 24, 2021 at 4:22 PM daniel szmulewicz <
daniel.szmulew...@gmail.com> wrote:

> Hi Sean,
>
> Thank you for explaining what was confusing. With that input, I've edited
> my blog post, separating the parts that apply to both REPL and nREPL and
> those that apply to nREPL only.
> I hope this avoids the pitfall you've described, and that the general
> discussion on Clojure's on-the-fly code generation and class loading
> mechanism will be of benefit to all Clojurians.
>
> Daniel
>
> On Tue, May 25, 2021 at 1:30 AM Sean Corfield  wrote:
>
>> It wasn't clear to me that the entire article only applies to nREPL.
>> Especially since most of the article just uses "REPL" and most of the code
>> does work in a normal REPL -- and you start with:
>>
>> Our exploration of the topic makes heavy use of a REPL, I invite you to
>> fire one up and play along.
>>
>> and then later say:
>>
>> It is worth reproducing the experiment in a plain Clojure REPL and a
>> nREPL client side by side.
>>
>> which makes it seem like everything up to that point applies to both and
>> this part is a specific difference.
>>
>> (the article may be particularly confusing for me since I never use nREPL
>> at all so "REPL" = "Clojure REPL" as far as I'm concerned)
>>
>> On Mon, May 24, 2021 at 1:21 PM daniel szmulewicz <
>> daniel.szmulew...@gmail.com> wrote:
>>
>>>
>>> Hi Sean,
>>>
>>> Absolutely, the growing stack of context class loaders is a quirk of the
>>> nREPL client.
>>>
>>> * something fairly unexpected is that with a CIDER/nREPL setup, each
>>> evaluation adds an extra classloader*
>>>
>>> And later I write:
>>>
>>> In the default REPL, one instance of DynamicClassLoader stays associated
>>> with the REPL throughout the session. In a nREPL client, instances of
>>> DynamicClassLoader keep piling up.
>>>
>>> If you think there is a lack of clarity, I'll be happy to amend the text
>>> to make it less likely for the reader to miss that. Thank you very much for
>>> your input.
>>>
>>> Daniel
>>>
>>> On Mon, May 24, 2021 at 10:58 PM Sean Corfield 
>>> wrote:
>>>
>>>> When I tried some of your code in a default REPL (via the Clojure CLI),
>>>> I don't see the same results. In particular:
>>>>
>>>> user=> (hash (.getContextClassLoader (Thread/currentThread)))
>>>>
>>>> 1865201235
>>>>
>>>> user=> (hash (.getContextClassLoader (Thread/currentThread)))
>>>>
>>>> 1865201235
>>>>
>>>> user=> (hash (.getContextClassLoader (Thread/currentThread)))
>>>>
>>>> 1865201235
>>>>
>>>> user=> (hash (.getContextClassLoader (Thread/currentThread)))
>>>>
>>>> 1865201235
>>>>
>>>> (although all the rest of it seems to apply)
>>>>
>>>> On Mon, May 24, 2021 at 2:10 AM Daniel Szmulewicz <
>>>> daniel.szmulew...@gmail.com> wrote:
>>>>
>>>>> Every time you press ENTER at the REPL, a new class is created. In
>>>>> addition, it comes with a new class loader instance exclusively dedicated
>>>>> to loading it. That's Clojure behind the scenes doing its runtime magic. 
>>>>> On
>>>>> the other hand, in a nREPL client like Cider, not one but two class loader
>>>>> instances are produced, and that is a quirk that carries over since its
>>>>> earliest days. I bring you that story as an excuse for dwelling on the
>>>>> subject of class loading. Arcane, maybe, but essential.
>>>>>
>>>>> Read on <https://danielsz.github.io/blog/2021-05-12T13_24.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 becaus

Re: [BLOG] Once Upon A Class

[Sean Corfield]

It wasn't clear to me that the entire article only applies to nREPL.
Especially since most of the article just uses "REPL" and most of the code
does work in a normal REPL -- and you start with:

Our exploration of the topic makes heavy use of a REPL, I invite you to
fire one up and play along.

and then later say:

It is worth reproducing the experiment in a plain Clojure REPL and a nREPL
client side by side.

which makes it seem like everything up to that point applies to both and
this part is a specific difference.

(the article may be particularly confusing for me since I never use nREPL
at all so "REPL" = "Clojure REPL" as far as I'm concerned)

On Mon, May 24, 2021 at 1:21 PM daniel szmulewicz <
daniel.szmulew...@gmail.com> wrote:

>
> Hi Sean,
>
> Absolutely, the growing stack of context class loaders is a quirk of the
> nREPL client.
>
> * something fairly unexpected is that with a CIDER/nREPL setup, each
> evaluation adds an extra classloader*
>
> And later I write:
>
> In the default REPL, one instance of DynamicClassLoader stays associated
> with the REPL throughout the session. In a nREPL client, instances of
> DynamicClassLoader keep piling up.
>
> If you think there is a lack of clarity, I'll be happy to amend the text
> to make it less likely for the reader to miss that. Thank you very much for
> your input.
>
> Daniel
>
> On Mon, May 24, 2021 at 10:58 PM Sean Corfield  wrote:
>
>> When I tried some of your code in a default REPL (via the Clojure CLI), I
>> don't see the same results. In particular:
>>
>> user=> (hash (.getContextClassLoader (Thread/currentThread)))
>>
>> 1865201235
>>
>> user=> (hash (.getContextClassLoader (Thread/currentThread)))
>>
>> 1865201235
>>
>> user=> (hash (.getContextClassLoader (Thread/currentThread)))
>>
>> 1865201235
>>
>> user=> (hash (.getContextClassLoader (Thread/currentThread)))
>>
>> 1865201235
>>
>> (although all the rest of it seems to apply)
>>
>> On Mon, May 24, 2021 at 2:10 AM Daniel Szmulewicz <
>> daniel.szmulew...@gmail.com> wrote:
>>
>>> Every time you press ENTER at the REPL, a new class is created. In
>>> addition, it comes with a new class loader instance exclusively dedicated
>>> to loading it. That's Clojure behind the scenes doing its runtime magic. On
>>> the other hand, in a nREPL client like Cider, not one but two class loader
>>> instances are produced, and that is a quirk that carries over since its
>>> earliest days. I bring you that story as an excuse for dwelling on the
>>> subject of class loading. Arcane, maybe, but essential.
>>>
>>> Read on <https://danielsz.github.io/blog/2021-05-12T13_24.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/d7c270ef-d8e0-4935-ac2f-6fd56c9d4c3en%40googlegroups.com
>>> <https://groups.google.com/d/msgid/clojure/d7c270ef-d8e0-4935-ac2f-6fd56c9d4c3en%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- https://corfield.org/
>> World Singles Networks, LLC. -- https://worldsinglesnetworks.com/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http:/

Re: [BLOG] Once Upon A Class

[Sean Corfield]

When I tried some of your code in a default REPL (via the Clojure CLI), I
don't see the same results. In particular:

user=> (hash (.getContextClassLoader (Thread/currentThread)))

1865201235

user=> (hash (.getContextClassLoader (Thread/currentThread)))

1865201235

user=> (hash (.getContextClassLoader (Thread/currentThread)))

1865201235

user=> (hash (.getContextClassLoader (Thread/currentThread)))

1865201235

(although all the rest of it seems to apply)

On Mon, May 24, 2021 at 2:10 AM Daniel Szmulewicz <
daniel.szmulew...@gmail.com> wrote:

> Every time you press ENTER at the REPL, a new class is created. In
> addition, it comes with a new class loader instance exclusively dedicated
> to loading it. That's Clojure behind the scenes doing its runtime magic. On
> the other hand, in a nREPL client like Cider, not one but two class loader
> instances are produced, and that is a quirk that carries over since its
> earliest days. I bring you that story as an excuse for dwelling on the
> subject of class loading. Arcane, maybe, but essential.
>
> Read 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/d7c270ef-d8e0-4935-ac2f-6fd56c9d4c3en%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: How get function name in body?

[Sean Corfield]

Sorry, it's clojure.repl/demunge so it depends on how you run your REPL and
evaluate code -- in my case, clojure.repl symbols were all referred in. In
your case, you'll need to require clojure.repl and refer it in:

(require '[clojure.repl :refer [demunge])

or make that part of your ns form as:

  (:require [clojure.repl :refer [demunge]])

-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

On Thu, Apr 29, 2021 at 10:27 PM damon kwok  wrote:

>
> Clojure 1.10.1
>(defn haha []
>(println (demunge (.getName (.getCallerClass
> (java.lang.StackWalker/getInstance
> java.lang.StackWalker$Option/RETAIN_CLASS_REFERENCE))
> Syntax error compiling at (REPL:1:23).
> Unable to resolve symbol: demunge in this context
> 在2021年4月30日星期五 UTC+8 上午4:35:45 写道：
>
>> That's definitely nicer:
>>
>> dev=> (*defn* *add* [a b]
>>
>>  #_=>   (*println* (demunge (*.getName* (*.getCallerClass* (
>> *java.lang.StackWalker*/getInstance *java.lang.StackWalker$Option*
>> /RETAIN_CLASS_REFERENCE)
>>
>>  #_=>   (*+* a b))
>>
>> #'dev/add
>>
>> dev=> (add 1 2)
>>
>> dev/add
>>
>> 3
>>
>> dev=>
>>
>> Thanks, Rémi!
>>
>> On Thu, Apr 29, 2021 at 12:08 PM Remi Forax  wrote:
>>
>>>
>>>
>>> --
>>>
>>> *De: *"Sean Corfield" 
>>> *À: *"clojure" 
>>> *Envoyé: *Jeudi 29 Avril 2021 01:26:34
>>> *Objet: *Re: How get function name in body?
>>>
>>> Consider that:
>>>
>>> (defn add [a b] (+ a b))
>>>
>>> is expanded to (something like):
>>>
>>> (def add (fn [a b] (+ a b)))
>>>
>>> So the actual code that runs is an anonymous function, which is bound to
>>> the (global) var #'add -- the function itself has no name.
>>>
>>> dev=> (*macroexpand* '(*defn**add* [a b] (*+* a b)))
>>>
>>> (def add (clojure.core/fn ([a b] (+ a b
>>>
>>> dev=> (*defn**add* [a b] (*+* a b))
>>>
>>> #'dev/add
>>>
>>> dev=> add
>>>
>>> #object[dev$add 0x72f91c91 "dev$add@72f91c91"]
>>>
>>> So the value of add is an object, with type dev$add, a class that
>>> implements a bunch of things including clojure.lang.IFn and
>>> java.lang.Runnable and java.util.concurrent.Callable etc.
>>>
>>> The "name" of function is hard to get to, inside a function because of
>>> that.
>>>
>>> One way to figure that out at runtime is to dig into the stack, which
>>> you can get at by creating an exception and inspecting it: be aware that
>>> this is an expensive operation!
>>>
>>> dev=> (*defn**add* [a b]
>>>
>>> #_=> (*let* [frame (*first* (*:trace* (*Throwable->map* (*ex-info**""*
>>> {}]
>>>
>>> #_=> (*println* (demunge (*name* (*first* frame
>>>
>>> #_=> (*+* a b)))
>>>
>>> #'dev/add
>>>
>>> dev=> (add 1 2)
>>>
>>> dev/add
>>>
>>> 3
>>>
>>> dev=>
>>>
>>> demunge is what turns Clojure's generated classnames back into readable
>>> source names.
>>>
>>>
>>> Instead of using the stacktrace of java.lang.Throwable, you can use
>>> StackWalker.getCallerClass() if you are using a jdk 9+
>>>
>>>
>>> The more important question is: why do you want the function's name
>>> inside the body?
>>> --
>>> Sean A Corfield -- (904) 302-SEAN
>>> An Architect's View -- https://corfield.org/
>>> World Singles Networks, LLC. -- https://worldsinglesnetworks.com/
>>>
>>> "Perfection is the enemy of the good."
>>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>>
>>>
>>> Rémi
>>>
>>> [1]
>>> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()
>>>
>>> --
>>> 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
>>> yo

Re: How get function name in body?

[Sean Corfield]

That's definitely nicer:

dev=> (*defn* *add* [a b]

 #_=>   (*println* (demunge (*.getName* (*.getCallerClass* (
*java.lang.StackWalker*/getInstance *java.lang.StackWalker$Option*
/RETAIN_CLASS_REFERENCE)

 #_=>   (*+* a b))

#'dev/add

dev=> (add 1 2)

dev/add

3

dev=>

Thanks, Rémi!

On Thu, Apr 29, 2021 at 12:08 PM Remi Forax  wrote:

>
>
> ------
>
> *De: *"Sean Corfield" 
> *À: *"clojure" 
> *Envoyé: *Jeudi 29 Avril 2021 01:26:34
> *Objet: *Re: How get function name in body?
>
> Consider that:
>
> (defn add [a b] (+ a b))
>
> is expanded to (something like):
>
> (def add (fn [a b] (+ a b)))
>
> So the actual code that runs is an anonymous function, which is bound to
> the (global) var #'add -- the function itself has no name.
>
> dev=> (*macroexpand* '(*defn**add* [a b] (*+* a b)))
>
> (def add (clojure.core/fn ([a b] (+ a b
>
> dev=> (*defn**add* [a b] (*+* a b))
>
> #'dev/add
>
> dev=> add
>
> #object[dev$add 0x72f91c91 "dev$add@72f91c91"]
>
> So the value of add is an object, with type dev$add, a class that
> implements a bunch of things including clojure.lang.IFn and
> java.lang.Runnable and java.util.concurrent.Callable etc.
>
> The "name" of function is hard to get to, inside a function because of
> that.
>
> One way to figure that out at runtime is to dig into the stack, which you
> can get at by creating an exception and inspecting it: be aware that this
> is an expensive operation!
>
> dev=> (*defn**add* [a b]
>
> #_=> (*let* [frame (*first* (*:trace* (*Throwable->map* (*ex-info**""*
> {}]
>
> #_=> (*println* (demunge (*name* (*first* frame
>
> #_=> (*+* a b)))
>
> #'dev/add
>
> dev=> (add 1 2)
>
> dev/add
>
> 3
>
> dev=>
>
> demunge is what turns Clojure's generated classnames back into readable
> source names.
>
>
> Instead of using the stacktrace of java.lang.Throwable, you can use
> StackWalker.getCallerClass() if you are using a jdk 9+
>
>
> The more important question is: why do you want the function's name inside
> the body?
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- https://corfield.org/
> World Singles Networks, LLC. -- https://worldsinglesnetworks.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
> Rémi
>
> [1]
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/843762456.638578.1619723272421.JavaMail.zimbra%40u-pem.fr
> <https://groups.google.com/d/msgid/clojure/843762456.638578.1619723272421.JavaMail.zimbra%40u-pem.fr?utm_medium=email_source=footer>
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: How get function name in body?

[Sean Corfield]

Consider that:

(defn add [a b] (+ a b))

is expanded to (something like):

(def add (fn [a b] (+ a b)))

So the actual code that runs is an anonymous function, which is bound to
the (global) var #'add -- the function itself has no name.

dev=> (*macroexpand* '(*defn* *add* [a b] (*+* a b)))

(def add (clojure.core/fn ([a b] (+ a b

dev=> (*defn* *add* [a b] (*+* a b))

#'dev/add

dev=> add

#object[dev$add 0x72f91c91 "dev$add@72f91c91"]

So the value of add is an object, with type dev$add, a class that
implements a bunch of things including clojure.lang.IFn and
java.lang.Runnable and java.util.concurrent.Callable etc.

The "name" of function is hard to get to, inside a function because of that.

One way to figure that out at runtime is to dig into the stack, which you
can get at by creating an exception and inspecting it: be aware that this
is an expensive operation!

dev=> (*defn* *add* [a b]

 #_=>   (*let* [frame (*first* (*:trace* (*Throwable->map* (*ex-info* *""*
{}]

 #_=> (*println* (demunge (*name* (*first* frame

 #_=> (*+* a b)))

#'dev/add

dev=> (add 1 2)

dev/add

3

dev=>

demunge is what turns Clojure's generated classnames back into readable
source names.

The more important question is: why do you want the function's name inside
the body?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
On Wed, Apr 28, 2021 at 6:35 AM damon kwok  wrote:

>
> How get function name in body?
>
> (defn add [a b]
>  ;; how get "add" here?
>   (+ a b))
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/5c533ccf-ec0b-4c84-b759-851f1fe3b3can%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/CAD4thx93gtbitV20HNk9XBGF%2BkoDyCLYadNp32dvrOSQdpRN0w%40mail.gmail.com.

Re: Socket servers, threads, and redirecting error output.

[Sean Corfield]

Austin,

You might find a macro like this helpful -- just use it directly instead of
future. You can replace println with whatever sort of logging you want.

(defmacro logged-future
"Given a body, execute it in a try/catch and log any errors."
[& body]
(let [line (:line (meta ))
file *file*]
`(future
(try
~@body
(catch Throwable t#
(println t# "Unhandled exception at:"
~file "line:" ~line
"on thread:"
(.getName (Thread/currentThread


On Sat, Jan 2, 2021 at 5:59 PM Austin Haas  wrote:

> Ah, thanks for pointing that out. I must've overlooked your example,
> because I'd already written off futures.
>
> It seems like what you are suggesting, catch and print, might be about as
> good as I could hope for. If I don't want to block the main thread, then I
> don't see what else I could possibly do but print the exception. I guess I
> could store it somewhere, but in any case, I'd use this same pattern.
>
> Thanks, Justin.
> On Saturday, January 2, 2021 at 1:44:55 PM UTC-8 noise...@gmail.com wrote:
>
>> to be clear, in my second example you see the error from the future
>> without using deref
>>
>> good luck finding your solution
>>
>> On Sat, Jan 2, 2021 at 12:50 PM Austin Haas  wrote:
>>
>>> Thank you very much for the explanation, Justin.
>>>
>>> I don't see how I can use futures, though, without blocking on the main
>>> thread (to get the exception when it occurs). I'm spawning a long-running
>>> process that never returns a value.
>>> On Saturday, January 2, 2021 at 12:43:14 AM UTC-8 noise...@gmail.com
>>> wrote:
>>>
 By the time the exception is caught, you are already outside the
 context of the Thread which the repl client is interacting with. The
 default exception handler has no information tying the executing thread to
 the repl process (not to mention the dynamic variables clojure is using to
 associate output from code your client runs with that socket connection).

 You probably don't want to rebind the root exception handler to show
 *all* exceptions to your client socket. Which means that you need to set up
 some soft of infrastructure connecting the information about the failed
 function to the socket you are listening to.

 I find "future" very convenient for this, it uses a pool which will
  perform better than creating Threads ad-hoc, and will capture Exceptions
 and re-throw when you deref (of course, it's up to you to ensure you deref,
 or use try/catch and otherwise forward the failure information via the
 catch block). Also, it conveys dynamic bindings for things like
 clojure.core/*out* and clojure.core/*err* that java classes don't know
 about.

 (ins)user=> (def fut (future (throw (Exception. "oops"
 #'user/fut
 (ins)user=> @fut ; waits until deref to raise the error
 Execution error at user/fn (REPL:11).
 oops
 (ins)user=> (def fut2 (future (try (throw (Exception. "oops")) (catch
 Exception e (println "wat\n" e) ; prints instead of raising
 #'user/fut2
 user=> wat
  #error {
  :cause oops
  :via
  [{:type java.lang.Exception
:message oops
:at [user$fn__165 invokeStatic NO_SOURCE_FILE 13]}]
  :trace
  [[user$fn__165 invokeStatic NO_SOURCE_FILE 13]
   [user$fn__165 invoke NO_SOURCE_FILE 13]
   [clojure.core$binding_conveyor_fn$fn__5754 invoke core.clj 2030]
   [clojure.lang.AFn call AFn.java 18]
   [java.util.concurrent.FutureTask run FutureTask.java 264]
   [java.util.concurrent.ThreadPoolExecutor runWorker
 ThreadPoolExecutor.java 1128]
   [java.util.concurrent.ThreadPoolExecutor$Worker run
 ThreadPoolExecutor.java 628]
   [java.lang.Thread run Thread.java 834]]}



 On Thu, Dec 31, 2020 at 1:48 PM Austin Haas 
 wrote:

>
> Problem: When I connect to a socket server and create a thread,
> exceptions in the thread are printed in the server's process, not the
> client's. I'd like them to appear in the client's process, where the 
> thread
> was created.
>
> (I'm using the term "process" very generally here, because I don't
> understand what is going on.)
>
> From searching, I understand that there are some other things at play,
> like System/err, but I don't understand what is happening or how I can 
> work
> around it. Why does an exception thrown in the client process show in the
> client process, but an exception thrown in a thread created by the client
> process shows in the server process? Why doesn't binding *err* in a thread
> seem to have any effect? Any suggestions or workarounds?
>
> I'm not using futures, because this is a long-running process that
> never returns a value.
>
> Example transcript:
>
> # Socker server
>
> (The only command entered is the first one, which begins with clj.
> Everything after "user=>" is due to the client below.)
>

Re: what is currently considered a good blog engine, written in Clojure?

[Sean Corfield]

I think a lot of people use Cryogen: Simple static sites (cryogenweb.org)
 -- I used to use Octopress, based on Jekyll, and
switched to Cryogen recently. For the commenting system, I've used Disqus
for a long time. And I host on GitHub (via seancorfield.github.io and a
custom corfield.org domain).

On Sat, Dec 12, 2020 at 1:53 AM lawrence...@gmail.com <
lawrence.krub...@gmail.com> wrote:

> Hello everyone. I've been away from the Clojure community for the last 2
> years (nowadays I do more managing than programming) but I'm starting a new
> blog. I tried to use Wordpress on the theory that it is "easy" and also
> because I've been told they fixed their old security flaws, but I installed
> the latest version and it was hacked in less than a day, so now I'm feeling
> unkindly towards Wordpress.
>
> I'm looking for a blog engine, which can use a database or flat files, I
> don't care.
>
> The main thing I need is a working comment system, with an ability on my
> side to whitelist particular commenters. Does anything like that exist
> written in Clojure?
>
> I'm very grateful, if anyone can point me to something that works, and is
> reasonably maintained.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/3cb3a068-a916-4bd4-925f-cd71744908dcn%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

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

[Sean Corfield]

As someone who has spent a lot of time around standardization committees
(eight years on ANSI X3J16 C++ and some time around the ANSI C work before
that, as well as years of BSI work as well), here's how I view the EDN
specification: it states what is valid or invalid, a compliant reader
should parse valid input correctly, what a compliant reader does with
invalid input is either not specified or it is undefined.

This is very common in standards and specifications. C and C++ have
undefined behavior (where the standard places no restrictions on what the
system can do -- and does not require it be documented either!),
implementation-defined behavior (where the standard allows systems to do
what they want but it must be documented), and unspecified behavior (where
the standard provides some guidelines but otherwise does not specify what a
system should do, not is it necessarily required to be documented, but it
is "defined" behavior somehow, e.g., order of evaluation of arguments).

Undefined behavior is deliberately very broad: a system can silently accept
erroneous input with any outcome it chooses or it can dump core or launch
missiles. It's generally the user's responsibility to ensure they do not
provide erroneous input.

In the case of Clojure's EDN implementation, it makes sense to match the
Clojure reader's behavior in cases where the EDN is "not valid" (i.e., does
not have a defined meaning). In other EDN implementations, it might make
more sense for EDN that has an undefined meaning to be rejected.

If you find valid EDN that a particular EDN reader fails to process
correctly, that's a bug. If you feed it invalid EDN, well, you may or may
not get an error or a value or...

On Tue, Oct 20, 2020 at 4:42 PM 'EuAndreh' via Clojure <
clojure@googlegroups.com> wrote:

> The speed over validation is only valid for Clojure's LispReader, not to
> clojure.edn. I'm completely fine with Clojure's reader keeping all of
> those weird behaviours, and many other more.
>
> But that doesn't apply to clojure.edn: it is code for a format with an
> specification, and it goes against the specification. Having it be
> faster or slower is less relevant in face of it not being correct, where
> correct means "matches the specification".
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/87362bel34.fsf%40euandre.org.
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Why is `binding-conveyor-fn` private?

[Sean Corfield]

Isn't that what bound-fn and bound-fn* are for?

On Fri, Aug 21, 2020 at 11:21 AM Dimitrios Jim Piliouras <
jimpil1...@gmail.com> wrote:

> Hi folks,
>
> I don’t get this…
>
> Why would such a neat/important utility private? Every time I
> submit/schedule a function to some Executor manually (not via `future`
>  or `agent`), I need to remember to wrap it with `binding-conveyor-fn`
> (otherwise dynamic bindings won’t get propagated), and every time I have to
> copy/paste it into whatever project I’m working in.
>
> Shouldn’t it, not only be public, but also come with a doc-string that
> strongly encourages its use  when manually submitting functions to
> Executors? Am I missing something?
>
> Many thanks in advance...
>
> Kind regards,
> Dimitrios
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/A6C14F3B-D725-4B11-9A8F-4C008DC1BB3D%40gmail.com
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

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

[Sean Corfield]

Alan,

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

Per the clojure/homebrew-tools readme:
https://github.com/clojure/homebrew-tools#version-archive-tool-releases

brew install clojure/tools/clojure@1.10.1.645

You may also need:

brew link --overwrite clojure@1.10.1.645

This allows you to easily switch back and forth between different versions
for testing.

On Wed, Aug 12, 2020 at 2:09 PM Alan Thompson  wrote:

> Hi Alex,
>
> 1. Great news that the Homebrew team has responded to your request to
> point only to stable versions.
>
> 2. The resources directory is the contains the path
> `resources/public/index.html`.  The local one is definitely not the one
> being served in my original example (2nd half) re 1.10.1.645 when the
> `resources` dir was listed near the end. The `index.html` being found by
> the Figwheel.Main server had different contents, and was pointing to a
> different *.js executable file (possibly in a different *.jar file?).  That
> is the source of the 2-word `Debux Test` webpage.
>
> 3. Unless I'm missing something, I believe we have already run your
> suggested test. Using 1.10.1.561 from `brew install clojure/tools/clojure`,
> I got the `resources` and `target` dirs as items #1 and #2 on the
> classpath; everything worked as expected.  Using 1.10.1.645 from `brew
> install clojure`, `resources` was near the end of the classpath and it
> failed (I didn't track down where the `target` dir wound up in that
> instance).
>
> 4. I could possibly try to replicate your proposed experiment explicitly,
> but I no longer have easy access to 1.10.1.645 since Homebrew has been
> fixed.  I did find the `brew-install` repo on GH, but am not certain how to
> replicate the broken install of *.645.
>
> Thank you for the attention you are giving to this issue.
>
> Alan
>
>
>
> On Tue, Aug 11, 2020 at 5:41 PM 'Alex Miller' via Clojure <
> clojure@googlegroups.com> wrote:
>
>> Can you change that resources file and see if what you're looking at
>> changes to double check? I did actually check a bunch of jars from the
>> prior message and did some searching for that message. Or you could even
>> dump the classpath with -Spath, then move resources to the front, then use
>> -Scp (which will force the classpath you say, ignoring everything else).
>>
>> Or could be that it's not the index.html but something it refers to
>> getting picked up from elsewhere?
>>
>> On Tue, Aug 11, 2020 at 6:18 PM Alan Thompson  wrote:
>>
>>> Hi - I just tried your suggestion and no joy:
>>>
>>>
>>> ~/work/tmp810/xanadu >   clj -e "((requiring-resolve '
>>> clojure.java.io/resource) \"public/index.html\")"
>>> DEPRECATED: Libs must be qualified, change deps-ancient =>
>>> deps-ancient/deps-ancient (deps.edn)
>>> DEPRECATED: Libs must be qualified, change reagent => reagent/reagent
>>> (deps.edn)
>>> DEPRECATED: Libs must be qualified, change ns-tracker =>
>>> ns-tracker/ns-tracker (deps.edn)
>>> DEPRECATED: Libs must be qualified, change camel-snake-kebab =>
>>> camel-snake-kebab/camel-snake-kebab (deps.edn)
>>> DEPRECATED: Libs must be qualified, change bidi => bidi/bidi (deps.edn)
>>> DEPRECATED: Libs must be qualified, change orchestra =>
>>> orchestra/orchestra (deps.edn)
>>> DEPRECATED: Libs must be qualified, change cljs-ajax =>
>>> cljs-ajax/cljs-ajax (deps.edn)
>>> DEPRECATED: Libs must be qualified, change expound => expound/expound
>>> (deps.edn)
>>> DEPRECATED: Libs must be qualified, change re-frame => re-frame/re-frame
>>> (deps.edn)
>>> DEPRECATED: Libs must be qualified, change re-frame-utils =>
>>> re-frame-utils/re-frame-utils (deps.edn)
>>> DEPRECATED: Libs must be qualified, change cljs-bean =>
>>> cljs-bean/cljs-bean (deps.edn)
>>> #object[java.net.URL 0x6c345c5f
>>> "file:/Users/alanthompson/work/tmp810/xanadu/resources/public/index.html"]
>>>
>>>
>>> The call to `requiring-resolve` claims it is finding my local
>>> `./resources/public/index.html`.  However, the error remains that it is
>>> finding some other `index.html`, which also points to an incorrect JS
>>> output file.
>>>
>>> Alan
>>>
>>>
>>>
>>>
>>> On Tue, Aug 11, 2020 at 2:15 PM 'Alex Miller' via Clojure <
>>> clojure@googlegroups.com> wrote:
>>>

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

> Here's some maven-specific discussion:
> https://stackoverflow.com/questions/793054/maven-classpath-order-issue
> .
> They have a defined order since 2.0.9. and declaration order is
> considered for transitive dependencies conflict.
>

 Unfortunately, neither that 11 year old SO answer nor the referenced
 jiras actually document, explain, or refer to any documentation about the
 ordering, or afaict commit to anything specific other 

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

[Sean Corfield]

I'd like to point out that tools.deps.alpha can build a differently-ordered
classpath from the exact same input files when run on a different machine
(i.e., the same source/deps, the same version of t.d.a./CLI).

This has bitten me a couple of times with depstar which I use for building
JARs/uberjars (and which I maintain) because a JAR built on one machine can
behave differently than a JAR built on another machine -- because of
classpath ordering of things that overlap on the classpath. This is
completely separate from the :paths issue (with which I have some sympathy).

The most recent "gotcha" for me was with log4j2 which has a
Log4J2Plugins.dat file containing a cache of the plugins that control
formatting in log files, so any library that includes formatter plugins
tends to have its own copy of this file. There have been a couple of
long-standing bug reports against Log4J2 because of this -- because people
in Maven-land keep tripping over classpath ordering issues and finding
logging breaks "randomly" in their applications. Years of complaints and
the official answer is "We'll stop doing the plugins cache thing in log4j
3". There is a Maven plugin that knows how to merge Log4J2Plugins.dat files
but, of course, it is specific to log4j2 and Maven. There is a Leiningen
plugin for it as well -- also specific to log4j2 code -- because Leiningen
is built on the same "reproducible" base as Maven...

So this _is_ an issue in Maven-land. It's an acknowledged problem with
libraries that contain overlapping files and has been for years. That
t.d.a/CLI makes this a bit more visible is a positive, in my opinion,
because you're more likely to realize that you have a problem upstream with
badly-behaved dependencies.

p.s., My "hack" for depstar was to have it overwrite Log4J2Plugins.dat in
the JAR until it found one bigger than ~10K and then ignore subsequent ones
(the plugin cache file in the main log4j2 JAR is 20K, the plugin cache
files in all the other libs I've seen are 5K or smaller). Sure, that means
you don't get _all_ the formatter plugins, you only get the core ones, but
in the real world that is almost always going to be the right choice.

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

> Ok, let's reset as we start talking about different things now.
>
> None of these libraries are broken. They just include resources. Also, I
> don't think it is realistic to tell library authors to please move certain
> files out of the way because my build tool randomizes my classpath. That is
> not going to happen. People will keep including things like
> log4j.properties that are in potential conflict with a local file or files
> in other JAR paths.
>
> The question remains: Should my build tool allow me control over the order
> of the classpath? I believe the answer is yes.
> (Even gradle gives you that control and/or offers ways to ensure that my
> chosen paths and libraries are first on the classpath.
> Regarding maven: Even if there would be no documentation at all, their
> algorithm has not changed since 2.0.9. It's the Normative Kraft des
> Faktischen at play. )
>
> If the build tool from version A to version B changes this order, it is
> not a usable tool. I can't make this point any clearer.
> We might agree to disagree here, but a build tool should not be at liberty
> to sort top-level dependencies at will.
>
> Note that this is completely independent from the thought that order
> *shouldn't* matter.
> When in fact it does matter. It is an unfortunate reality. That's simply
> how resource loading works in Java.
>
> I understand that building dependency trees is not trivial, but it is
> rather trivial to ensure :paths comes before everything else.
> Please define some stable order and establish a top-level order for
> explicit dependencies. That makes builds deterministic.
>
> Thanks for looking in this issue,
>  Jochen
>
> PS: happy to learn you got in touch with the homebrew team. That is
> excellent news.
>
>
>
>
> On Tuesday, August 11, 2020 at 6:01:18 PM UTC-7 Alex Miller wrote:
>
>> On Tue, Aug 11, 2020 at 6:41 PM 'bed...@yahoo.com' via Clojure <
>> clo...@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 

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

[Sean Corfield]

The warning appears about your own use of unqualified lib names in your
project's dependencies: so it really is "castigating the perpetrator", by
making you use groupId/artifactId format names for dependencies, instead of
the (lazy/convenient) shorthand of artifactId for libs that have a groupId
that matches the artifactId.

At work that meant changing all our dependencies for: Ring (and several
Ring-related libs), Selmer, Compojure, clj-http, http-kit, Hiccup,
HoneySQL, Instaparse, joda-time (a Java library that does it badly!),
wsdl4j (another naughty Java library!), Cheshire, clj-time,
camel-snake-kebab, date-clj, bidi, clojure.java-time -- which is already a
horrendous violator of both artifact naming _and_ namespace naming!).

On Fri, Aug 7, 2020 at 4:45 AM Matching Socks  wrote:

> Rich Hickey has pushed using solid domain names before, and I'm super glad
> to see more progress on that front.  But it's unfortunate if the tools
> castigate the victim, not the perpetrator.  Wouldn't Clojars be a better
> point for enforcement?  Has the question been raised with Clojars?
>
> Alex's advice reminds me of a pioneering ClojureScript React-wrapping
> library whose groupId is a domain that belongs to someone else.  The funny
> thing is that this is the library's *second* squatting.  The first one
> lasted only briefly; folks pointed out the domain was already used for an
> unflattering website.  So then the maintainers picked a domain that no one
> had registered at the time.  Risky!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/88400d9e-9c68-4098-9321-7cfb89e92be8o%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Inadequate behavior of agent await?

[Sean Corfield]

If you provide an error handler on the agent -- or just specify the error
mode as :continue -- it does not hang. That makes me think that what you're
seeing is "expected behavior" although it does seem a bit strange...?

On Wed, Jun 10, 2020 at 1:49 AM Ernesto Garcia  wrote:

> I have discovered that, in the case of an agent action exception, the
> behavior of agent await depends on timing:
> - If your await happens to execute after the action is completed, it will
> happily throw an exception that the agent is in a failed state.
> - If your await happens to execute before the action is completed, it will
> dangerously block. (!!!)
>
> Shouldn't await behave the same in both cases?
>
> Code example:
>
> (defn await-agent-after-fail []
>   (let [agt (agent nil)]
> (send-off agt (fn [_]
> (println "Agent throws exception now")
> (throw (ex-info "fail!" {}
> (Thread/sleep 1000)
> (println "Agent is awaited now...")
> (println "Await timed out?" (not (await-for 1 agt)
>
> (comment
>   (await-agent-after-fail))
>
>
> (defn await-agent-before-fail []
>   (let [agt (agent nil)]
> (send-off agt (fn [_]
> (Thread/sleep 1000)
> (println "Agent throws exception now")
> (throw (ex-info "fail!" {}
> (println "Agent is awaited now...")
> (println "Await timed out?" (not (await-for 1 agt)
>
> (comment
>   (await-agent-before-fail))
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/9cf9a5c3-1dcb-4d4a-b180-a2cd6568853do%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: [ANN] Deploy tokens for Clojars

[Sean Corfield]

This thread has illuminated something that wasn't at all clear from your
original post: namely that all tooling can continue exactly as-is, just
with user tokens swapped for passwords, and no code changes are required.

If all it takes is for users of Clojars to set CLOJARS_PASSWORD to a token
obtained from clojars.org instead of their original password, that's not
much of a burden at all.


On Mon, May 18, 2020 at 5:38 AM Toby Crawley  wrote:

> Thanks for the feedback Sean. In my experience, it doesn't matter if
> you give users a week, a month, or a year to switch - the majority
> won't until their first password-based deploy fails. And to be clear -
> all a user has to do is log in to Clojars, create a token, and use the
> token string in place of their Clojars password, which shouldn't be to
> onerous. Clojars will respond with a status message that briefly
> explains the issue and links to the wiki if a password is used after
> the switchover.
>
> That said, I have no strong attachment to switching over on June 27th
> - I would be open to discussing other dates. If someone does want to
> argue for a later date, please file an issue at
> https://github.com/clojars/clojars-web/issues/new?template=issue.md
> and we can chat there.
>
> It looks like Erik has already updated the deps-deploy documentation
> (thanks Erik!).
>
> - Toby
>
> On Mon, May 18, 2020 at 12:25 AM Sean Corfield  wrote:
> >
> > Here's a project that is documented to use the Clojars password and is
> fairly widely used: https://github.com/slipset/deps-deploy -- all
> projects created by clj-new rely on this and all of them will have the same
> documentation to use the Clojars password.
> >
> > Forcing everyone to change their deployment processes across the board
> within just over a month seems a bit... aggressive...
> >
> > On Sun, May 17, 2020 at 1:56 PM Toby Crawley  wrote:
> >>
> >> Howdy folks!
> >>
> >> Just letting you know that Clojars[1] now allows you to create and use
> >> deploy tokens[2] in place of passwords when deploying. If you don't
> >> deploy OSS projects to Clojars, feel free to stop reading now.
> >>
> >> The deploy tokens are to be used in place of a password when
> >> deploying, and can optionally be scoped to only allow deployment of a
> >> single artifact or any artifact within a group[2].
> >>
> >> We now consider deploying with your Clojars password deprecated, and
> >> will *disable deploying with a password on or after 2020-06-27*. So
> >> please switch to using deploy tokens as soon as you can, and please
> >> file an issue[3] or get in touch via the #clojars channel on the
> >> Clojurians slack if you encounter any problems.
> >>
> >> Also please file an issue[3] if you know of any public documentation
> >> that should be updated to mention deploy tokens.
> >>
> >> We are currently working with GitHub to enable secret scanning[4] for
> >> these tokens. Once that is in place, any token that GitHub discovers
> >> in source code will automatically be disabled and Clojars will email
> >> you about it.
> >>
> >> This work is being sponsored by Clojurists Together[5]. Please
> >> consider joining to sponsor this and other OSS work in the Clojure
> >> community if you aren't already a member. If you are already a member:
> >> thank you!
> >>
> >> - Toby
> >>
> >> [1]: https://clojars.org
> >> [2]: https://github.com/clojars/clojars-web/wiki/Deploy-Tokens
> >> [3]:
> https://github.com/clojars/clojars-web/issues/new?template=issue.md
> >> [4]: https://developer.github.com/partnerships/secret-scanning/
> >> [5]:
> https://www.clojuriststogether.org/news/clojurists-together-is-funding-clojars/
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to 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 w

Re: [ANN] Deploy tokens for Clojars

[Sean Corfield]

Here's a project that is documented to use the Clojars password and is
fairly widely used: https://github.com/slipset/deps-deploy -- all projects
created by clj-new rely on this and all of them will have the same
documentation to use the Clojars password.

Forcing everyone to change their deployment processes across the board
within just over a month seems a bit... aggressive...

On Sun, May 17, 2020 at 1:56 PM Toby Crawley  wrote:

> Howdy folks!
>
> Just letting you know that Clojars[1] now allows you to create and use
> deploy tokens[2] in place of passwords when deploying. If you don't
> deploy OSS projects to Clojars, feel free to stop reading now.
>
> The deploy tokens are to be used in place of a password when
> deploying, and can optionally be scoped to only allow deployment of a
> single artifact or any artifact within a group[2].
>
> We now consider deploying with your Clojars password deprecated, and
> will *disable deploying with a password on or after 2020-06-27*. So
> please switch to using deploy tokens as soon as you can, and please
> file an issue[3] or get in touch via the #clojars channel on the
> Clojurians slack if you encounter any problems.
>
> Also please file an issue[3] if you know of any public documentation
> that should be updated to mention deploy tokens.
>
> We are currently working with GitHub to enable secret scanning[4] for
> these tokens. Once that is in place, any token that GitHub discovers
> in source code will automatically be disabled and Clojars will email
> you about it.
>
> This work is being sponsored by Clojurists Together[5]. Please
> consider joining to sponsor this and other OSS work in the Clojure
> community if you aren't already a member. If you are already a member:
> thank you!
>
> - Toby
>
> [1]: https://clojars.org
> [2]: https://github.com/clojars/clojars-web/wiki/Deploy-Tokens
> [3]: https://github.com/clojars/clojars-web/issues/new?template=issue.md
> [4]: https://developer.github.com/partnerships/secret-scanning/
> [5]:
> https://www.clojuriststogether.org/news/clojurists-together-is-funding-clojars/
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/CAA3HuyZiAFk8Bb4gRjrKuO-fs4psK9TPvR0FZX00w-01ZGhhSQ%40mail.gmail.com
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

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

[Sean Corfield]

And you might look at https://github.com/EwenG/badigeon (which is listed on
that tools page) since it says it will "Compile java sources" according to
the readme

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

> You would need to write a Clojure script with a -main function that would
> (somehow) compile Java source code according to whatever rules you wanted
> and then invoke it from the CLI (as an initial step to get the compiled
> class files onto the classpath that a subsequent CLI invocation could use).
>
> It would be just another tool like any of the others listed here:
> https://github.com/clojure/tools.deps.alpha/wiki/Tools
>
> On Thu, Apr 2, 2020 at 2:18 PM Alan Thompson  wrote:
>
>> I've seen this conversation:
>> https://clojureverse.org/t/is-there-a-sales-pitch-for-switching-to-deps-edn-from-lein-in-2020/5367/15
>>
>> which seems to say there is no existing way to combine Java & Clojure
>> source code when building with deps/CLI.  Is this correct?
>>
>> If so, what would be entailed in enhancing Deps/CLI to handle Java source
>> files?
>>
>> Thanks,
>> Alan
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/CAN67zA3%3DxtbsaC3iGgBSjPgUjw0LwZp%2Bu6bM54ktr1svgxeESQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/clojure/CAN67zA3%3DxtbsaC3iGgBSjPgUjw0LwZp%2Bu6bM54ktr1svgxeESQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles Networks, LLC. -- https://worldsinglesnetworks.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

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

[Sean Corfield]

You would need to write a Clojure script with a -main function that would
(somehow) compile Java source code according to whatever rules you wanted
and then invoke it from the CLI (as an initial step to get the compiled
class files onto the classpath that a subsequent CLI invocation could use).

It would be just another tool like any of the others listed here:
https://github.com/clojure/tools.deps.alpha/wiki/Tools

On Thu, Apr 2, 2020 at 2:18 PM Alan Thompson  wrote:

> I've seen this conversation:
> https://clojureverse.org/t/is-there-a-sales-pitch-for-switching-to-deps-edn-from-lein-in-2020/5367/15
>
> which seems to say there is no existing way to combine Java & Clojure
> source code when building with deps/CLI.  Is this correct?
>
> If so, what would be entailed in enhancing Deps/CLI to handle Java source
> files?
>
> Thanks,
> Alan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAN67zA3%3DxtbsaC3iGgBSjPgUjw0LwZp%2Bu6bM54ktr1svgxeESQ%40mail.gmail.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: WebApp authentication and authorization - up-to-date information?

[Sean Corfield]

Authentication is a serious business. Posting code examples for beginners
to follow is likely to either be too complex to be a good example or too
simple to be a good authentication process.

Also, I think a lot of "the experienced users" are building real-world apps
that are proprietary in nature, especially around a sensitive topic such as
authentication/authorization. We built our own OAuth 2 server-side stuff on
top of Apache OLTS (which is very poorly documented) and it's both too
complex to be a useful example -- an Auth Server, a Login Server, and a
separate API Server that uses access/refresh tokens with the Auth Server --
and also includes proprietary logic that would be hard to detangle, even if
the overall code was simple enough to serve as a useful example :(

I found a lot of stuff about client-side OAuth 2 authentication -- which is
the simplest part of the process and there are libraries out there for
interacting with Twitter, Facebook, GitHub, and other OAuth 2/OpenID
providers -- but there seemed to be almost nothing about writing the
server-side stuff (and even when I found OLTS I pretty much had to work
from the Java source code and the OAuth 2 RFC to figure it all out).

On Sun, Mar 22, 2020 at 7:02 AM iamDecim  wrote:

> I think this could be easily solved if some of the experienced users show
> more code.  I'm 100% sure a few of them could grab
> http-kit/pedestal/immutant and give an example of basic authentication and
> even making a simple post and throwing it up on github then advertising it
> via Twitter or reddit.  One weird issue which I've said a few times is a
> lot of people are using clojure but no one seems to like to make
> code/examples public.
>
> On Saturday, March 21, 2020 at 3:29:04 PM UTC-4, Bost wrote:
>>
>> I have difficulties finding up-to-date information, tutorials, articles,
>> blog posts etc. concerning WebApp authentication and authorization.
>>
>> The most "recent" useful articles I found are from 2015 and 2014:
>> https://rundis.github.io/blog/2015/buddy_auth_part2.html
>> https://blog.knoldus.com/google-sign-in-using-clojure/
>>
>> Uhm, my google-fu is getting weak... can anyone help please? Thanks
>>
>> Bost
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/7dca94f3-b20c-4073-b2ee-0dbe3619f337%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: WebApp authentication and authorization - up-to-date information?

[Sean Corfield]

omething useful and relevant to show the company.  That's how Java got
> into C++ shops and how Ruby got into Java shops.
>
> Clojure will remain vital to some big companies regardless of whether the
> cost of entry is reduced; but sadly, the comparative abomination called
> JavaScript will continue to grow - eating the backend now too.  It could be
> Clojure/ClojureScript taking over the world.
>
>
> On Saturday, March 21, 2020 at 10:51:47 PM UTC+1, Sean Corfield wrote:
>>
>> > some form of database interface (definitely need not be ORM; just a
>> demonstrated pattern)
>>
>> I'm curious as to what you feel is missing beyond clojure.java.jdbc /
>> next.jdbc? SQL is the lingua franca for relational databases and those
>> libraries provide the interface between Clojure data -- hash maps and
>> vectors of hash maps -- and rows/resultsets.
>>
>> On Sat, Mar 21, 2020 at 2:30 PM z9znz  wrote:
>>
>>> This is what primarily keeps me from ever building a first (web) app
>>> with Clojure.
>>>
>>> Even the Web Development with Clojure, 3rd edition that I bought (beta)
>>> still does not have the section on this topic filled in.
>>>
>>> I'm convinced that part of what prevents Clojure from being adopted more
>>> is the lack of a killer framework.  When I ask about this, the usual answer
>>> is that Clojure people don't like to be constrained and are happier to
>>> choose their own tools and libraries.  This is great if you already know
>>> what you're doing, but it's a vertical wall for newbies.
>>>
>>> I admit I have not yet looked at Coast on Clojure - and perhaps it has
>>> the potential to be that entry point for newbies.
>>>
>>> But apropos to your question, perhaps the Coast docs on authentication
>>> will help you.  They illustrate using Buddy.  Buddy has not been updated
>>> since Q3 2017 (a fact I find discouraging), but perhaps it is still
>>> relevant.
>>> https://github.com/coast-framework/coast/blob/master/docs/authentication.md
>>>
>>> I keep dreaming of a Clojure-based starter system that includes
>>> authentication and some form of database interface (definitely need not be
>>> ORM; just a demonstrated pattern).  We could begin with that, and once we
>>> have a clue what's what, then we can go the usual Clojure route and hand
>>> select every library.
>>>
>>>
>>> On Saturday, March 21, 2020 at 8:29:04 PM UTC+1, Bost wrote:
>>>>
>>>> I have difficulties finding up-to-date information, tutorials,
>>>> articles, blog posts etc. concerning WebApp authentication and
>>>> authorization.
>>>>
>>>> The most "recent" useful articles I found are from 2015 and 2014:
>>>> https://rundis.github.io/blog/2015/buddy_auth_part2.html
>>>> https://blog.knoldus.com/google-sign-in-using-clojure/
>>>>
>>>> Uhm, my google-fu is getting weak... can anyone help please? Thanks
>>>>
>>>> Bost
>>>>
>>> --
>>> 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/6d358084-de60-42a7-8893-a118a207bdab%40googlegroups.com
>>> <https://groups.google.com/d/msgid/clojure/6d358084-de60-42a7-8893-a118a207bdab%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> World Singles Networks, LLC. -- https://worldsinglesnetworks.com/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group

Re: WebApp authentication and authorization - up-to-date information?

[Sean Corfield]

> some form of database interface (definitely need not be ORM; just a
demonstrated pattern)

I'm curious as to what you feel is missing beyond clojure.java.jdbc /
next.jdbc? SQL is the lingua franca for relational databases and those
libraries provide the interface between Clojure data -- hash maps and
vectors of hash maps -- and rows/resultsets.

On Sat, Mar 21, 2020 at 2:30 PM z9znz  wrote:

> This is what primarily keeps me from ever building a first (web) app with
> Clojure.
>
> Even the Web Development with Clojure, 3rd edition that I bought (beta)
> still does not have the section on this topic filled in.
>
> I'm convinced that part of what prevents Clojure from being adopted more
> is the lack of a killer framework.  When I ask about this, the usual answer
> is that Clojure people don't like to be constrained and are happier to
> choose their own tools and libraries.  This is great if you already know
> what you're doing, but it's a vertical wall for newbies.
>
> I admit I have not yet looked at Coast on Clojure - and perhaps it has the
> potential to be that entry point for newbies.
>
> But apropos to your question, perhaps the Coast docs on authentication
> will help you.  They illustrate using Buddy.  Buddy has not been updated
> since Q3 2017 (a fact I find discouraging), but perhaps it is still
> relevant.
> https://github.com/coast-framework/coast/blob/master/docs/authentication.md
>
> I keep dreaming of a Clojure-based starter system that includes
> authentication and some form of database interface (definitely need not be
> ORM; just a demonstrated pattern).  We could begin with that, and once we
> have a clue what's what, then we can go the usual Clojure route and hand
> select every library.
>
>
> On Saturday, March 21, 2020 at 8:29:04 PM UTC+1, Bost wrote:
>>
>> I have difficulties finding up-to-date information, tutorials, articles,
>> blog posts etc. concerning WebApp authentication and authorization.
>>
>> The most "recent" useful articles I found are from 2015 and 2014:
>> https://rundis.github.io/blog/2015/buddy_auth_part2.html
>> https://blog.knoldus.com/google-sign-in-using-clojure/
>>
>> Uhm, my google-fu is getting weak... can anyone help please? Thanks
>>
>> Bost
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/6d358084-de60-42a7-8893-a118a207bdab%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

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

[Sean Corfield]

I don't think the doc generator runs automatically at the moment -- and,
for a while, it was having problems processing several Contrib repos
(java.jdbc still shows 0.7.10-SNAPSHOT in the generated docs, but 0.7.11
was released a while back).

On Sat, Mar 14, 2020 at 10:21 AM Matching Socks 
wrote:

> (A constructive note) The core.async official API docs are still labeled
> "core.async 0.7.560-SNAPSHOT (in development)".
>
> I followed the link from https://github.com/clojure/core.async .
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/f54c13b1-7332-4ab3-a2bd-d0b6992b96fa%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

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

[Sean Corfield]

That ship done sailed already today... many Contrib libs hit 1.0.0 (or
1.0.x) and most of the rest will follow suit in the next several days I
expect!

I certainly plan to bump tools.cli and, with Fogus' help, core.cache and
core.memoize to 1.0.0. java.jdbc will likely remain at 0.7.11 since its
"1.0.0" was really seancorfield/next.jdbc.

On Tue, Feb 18, 2020 at 5:46 PM 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/53c37f03-d28a-45e3-9903-d30d0c6b163a%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: ANN: jedi-time 0.2.0

[Sean Corfield]

Just had a play with this in REBL and it feels much more intuitive now,
thank you! I'll be adding this to my dev setup for work on Monday :)

On Sun, Feb 16, 2020 at 7:57 AM dimitris  wrote:

> Hi folks,
>
> Following the recent discussion/feedback I got, I am pleased to announce
> the second release of `jedi-time` [1]. This has significant differences
> than the previous version, and so I have completely reworked the
> README.md and intro.md to reflect the new design. It looks like a lot at
> first because there are many types, but once the (recursive merging)
> approach clicks, hopefully the whole thing should easily make sense.
>
> I spent a couple of hours with REBL and as far as I can see, the data
> representations returned by `jedi-time` work as expected. If your
> experience differs, please consider taking two minutes to report it :).
>
> Kind regards,
>
> Dimitris
>
> [1]: https://github.com/jimpil/jedi-time
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/2ae46b54-d46b-8aea-d4da-016c09300e73%40gmail.com
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

RE: ANN: jedi-time 0.1.4

[Sean Corfield]

> The only way to have `nav` selectively recognise keys based on their  
> existence in the map, is to put its whole logic behind a `contains?`  check. 
> However that sounds counter-intuitive/productive...

Remember that nav is called with the key _and the value_ so it will be passed 
whatever value is associated with the key in the data structure. So (nav data 
:format nil) means either the key exists with the value nil or the key doesn’t 
exist, but either way nil isn’t a valid format so your nav should just return 
the value unchanged.

If (get data k) produces v, then nav will be called as (nav data k (get data 
k)) – if v is part of data via some other “path”, then nav will be called as 
(nav data nil v) so you always get v from data and you may get k from data. The 
key, if passed, comes from the data structure – not some fabricated key.

If I do this:

(assoc (d/datafy (java.time.LocalDateTime/now)) :month {:name "MARCH" :value 3 
:length 31})

When I navigate through the fields of that data structure to :month, I should 
get a java.time.Month for March – because that’s the value passed into nav. 
Your current implementation still returns February. That’s why nav should pay 
attention to the value v that is passed in (again, per the docstring, nav 
“Returns (possibly transformed) v, in the context of coll and k”).

The nav docstring:

“Returns (possibly transformed) v in the context of coll and k (a
  key/index or nil). Callers should attempt to provide the key/index
  context k for Indexed/Associative/ILookup colls if possible, but not
  to fabricate one e.g. for sequences (pass nil). nav returns the
  value of clojure.core.protocols/nav.”

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: Monday, February 10, 2020 2:20 PM
To: clojure@googlegroups.com
Subject: Re: ANN: jedi-time 0.1.4

On 10/02/2020 20:45, Sean Corfield wrote:
> I’m suggesting that if you add certain key/value pairs to the datafied 
> Java Time values, nav could recognize those as navigation from data to 
> “stuff”. This gets you much closer to your original concept while 
> staying within the datafy/nav confines.

The keys recognised by `nav` have been manually hard-coded to match the 
keys in the map (in my current implementation), so if I add :format it 
will always be recognised regardless of whether it exists in the map. 
The only way to have `nav` selectively recognise keys based on their 
existence in the map, is to put its whole logic behind a `contains?` 
check. However that sounds counter-intuitive/productive...


> What I didn’t like about the original was that your nav function 
> accepted arbitrary keys and values that weren’t related to the datait 
> was “magic” and had extended navigation arbitrarily outside of the 
> Clojure navigation of the data

I'm surprised you said that right after having shown exactly how I had 
navigation for :format up until yesterday. What makes :format not 
arbitrary or magic? How could `nav` possibly know that a new key has 
been added (or removed/updated for that matter), and dynamically add the 
corresponding behaviour?


> I don’t know how I would feel about the add/subtract time periods 
> being done this way
Again, I find that interesting because if there is one operation that 
naturally leads you from data to another Java object, that is shifting. 
For example, the :format capability we're discussing leads you to a 
String, whereas `(nav datafied :+ [2 :weeks])` leads you back to a 
(datafiable) java object (i.e. a nicer fit for going from data to 
stuff). The `:at-zone` and `:at-offset` navigation paths were similarly 
good fits for the same reason. To me, :format although convenient and 
all, is totally arbitrary.


> if you take data (the hash map produced by datafying a Java Time 
> object) and manipulate the data in ways that preserves the nav 
> metadata, then calling nav on that new data could do more things than 
> calling nav on the original data

I honestly don't see how that is possible in the open way that you seem 
to imply...Someone needs to define upfront what the `nav` capabilities 
will be (what keys will be recognised), and those are not tied in any 
way to the keys/values in the map at any given point in time. As I said 
in my first point above, one could manually force that a navigation path 
only fires if the key is actually contained in the data, but that sounds 
like an anti-pattern if I'm honest.

I would love to understand a bit deeper why you thought that my original 
nav keys felt arbitrary and magic, whereas you clearly think that 
:format isn't...To me they all are, or none are.


Thanks again...


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@go

RE: ANN: jedi-time 0.1.4

[Sean Corfield]

> Ok, I'm glad datafy/nav works as expected, but the rest of you response 
> confuses me again :)

Sorry ☹ 

> You now seem to implying going back to "doing too much" with `nav` - or have 
> I misunderstood you (again)?

I’m suggesting that if you add certain key/value pairs to the datafied Java 
Time values, nav could recognize those as navigation from data to “stuff”. This 
gets you much closer to your original concept while staying within the 
datafy/nav confines.

Let’s take a concrete example:

(d/datafy (java.time.LocalDateTime/now)) -> a hash map like this:

{:second-milli 114, :hour 14, :second-micro 114866, :second 47,
 :month {:name "FEBRUARY", :value 2, :length 29, :day 9},
 :year {:value 2020, :leap? true, :length 366, :week 6, :day 40},
 :weekday {:name "SUNDAY", :value 7}, :second-nano 114866000, :minute 42}

(get data :month) -> {:name "FEBRUARY", :value 2, :length 29, :day 9}

(nav data :month (get data :month)) -> a java.time.Month object for “FEBRUARY” 
(losing the day – which suggests :day should be part of the datafication 
separately BTW)

Now lets look for :format:

(get data :format) -> nil

(nav data :format (get data :format)) -> nil

As expected. But it’s data and we can augment it with other keys:

(let [data’ (assoc data :format :iso)] (get data’ :format)) -> :iso

At this point, we have a key and a value so we can call nav with those:

(let [data’ (assoc data :format :iso)] (nav data’ :format (get data’ :format)) 
-> could navigate to an ISO-formatted version of the local date time

> Moreover, if `:format` is recognised by `nav`, you wouldn't need to `assoc` 
> it in order to use it 

What I didn’t like about the original was that your nav function accepted 
arbitrary keys and values that weren’t related to the datait was “magic” and 
had extended navigation arbitrarily outside of the Clojure navigation of the 
data (see the nav docstring below):. I’m not suggesting that all of your 
original functionality maps down naturally to get/nav like this – I don’t know 
how I would feel about the add/subtract time periods being done this way but if 
you take data (the hash map produced by datafying a Java Time object) and 
manipulate the data in ways that preserves the nav metadata, then calling nav 
on that new data could do more things than calling nav on the original data, if 
it follows the get/nav path that is intended by the datafy/nav mappings:

Foo -> datafy -> data

(get data k) -> v

(nav data k v) -> v or some new Foo or…

But the expectation is that nav will get called as if (nav data k (get data k)) 
or (nav data nil v) if there’s no natural key/index associated with the value v.

Here’s the docstring for nav – I’ve added some emphasis:

“Returns (possibly transformed) v in the context of coll and k (a
  key/index or nil). Callers should attempt to provide the key/index
  context k for Indexed/Associative/ILookup colls if possible, but not
  to fabricate one e.g. for sequences (pass nil). nav returns the
  value of clojure.core.protocols/nav.”

Hopefully this clarifies what I was trying to express, but I’m happy to have 
another few goes around if we’re not both there yet  

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: Monday, February 10, 2020 4:50 AM
To: clojure@googlegroups.com
Subject: Re: ANN: jedi-time 0.1.4

Ok, I'm glad datafy/nav works as expected, but the rest of you response 
confuses me again :)
The reason I removed support for navigating to `:format` was because we 
established in previous conversations that I was doing too much with `nav`. I 
was using it for comparing, shifting, formatting & converting. I've put all of 
that behind separate protocols and extending them via metadata (similarly to 
`nav`). You now seem to implying going back to "doing too much" with `nav` - or 
have I misunderstood you (again)?
Moreover, if `:format` is recognised by `nav`, you wouldn't need to `assoc` it 
in order to use it - it would just work (as it used to work before my commit 
last night), so that bit confuses me too. In any case, I do massively 
appreciate the time you're putting into this...There is great confusion on-line 
about datafy/nav, whether they are useful on their own (vs being complementary 
to each other), the right arguments, where we draw the line in terms of doing 
too much etc etc.  
Thanks again :)

On 09/02/2020 22:57, Sean Corfield wrote:
That is starting to work nicely with REBL for the basic datafy/nav 
functionality. Thank you! 

Once I'd verified that, I tried this: (assoc (d/datafy 
(java.time.LocalDateTime/now)) :format :iso) hoping that if I nav'd to the new 
:format key, it would "navigate" to a formatted version but it didn't. Then I 
realized you hadn't added support for that in y

Re: ANN: jedi-time 0.1.4

[Sean Corfield]

That is starting to work nicely with REBL for the basic datafy/nav
functionality. Thank you!

Once I'd verified that, I tried this: (assoc (d/datafy
(java.time.LocalDateTime/now)) :format :iso) hoping that if I nav'd to the
new :format key, it would "navigate" to a formatted version but it didn't.
Then I realized you hadn't added support for that in your nav
implementation (you're assuming folks explicitly use your protocol-based
functions on the original objects, I think?). That would be the next
logical step: being able to augment a datafied date/time with additional
key/value pairs that would be recognized by the implementation of nav. The
datafication wouldn't need to add these keys (although, if you wanted an
obvious "default" behavior, you could add some) but the navigation would
need to recognize them and do the appropriate calculation/conversion. Does
that make sense?

On Sun, Feb 9, 2020 at 1:46 PM dimitris  wrote:

> Hi again Sean and folks,
>
> I've had another stub at this, mostly by flattening the model but also by
> separating navigation from query/comparing/formatting etc. Most datafied
> representations are now navigable on their keys (returning either a Java
> object or some base value), and some on certain extra keys.
>
> I believe this version will play much nicer with REBL, and all the wrapper
> style fns now live in `jedi-time.datafied` namespace and backed-by
> `jedi-time.protocols`. In other words, navigation is now purely for
> traversing the graph - everything else has its own protocol.
>
> Unfortunately, now Instant can't really navigate to anything interesting
> (it falls back to data navigation via `get`).
>
> I would be very interested in feedback on the new approach (git-sha:
> 8e756ecb71bbfa0b081e00d71a21c47037f1eae4). If anything, it separates
> navigation from the other capabilities, and makes sure that there is always
> a navigation path to either upgrade (by making assumptions), or downgrade
> (by losing information) your datafied representation .
>
> As always, thanks in advance...
>
> Dimitris
>
>
> On 09/02/2020 19:35, Sean Corfield wrote:
>
> Yes, I agree with all of that I think.
>
> For nested navigation, consider that (get-in data [:year :month) is
> equivalent to (get data :month (get data :year)) so you could nav one step
> at a time. Calling nav (& then datafy) on the intermediate steps would just
> bring you back to the data world at the same point as the inner (top-level)
> get in that case.
>
> nav-in would be a strange operation since it would need to call datafy
> after each step to get the arguments needed for the next nav call. REBL
> provides nav-> which does this behind the scenes while it is threading data
> through the pipeline of nav operations (so there is a precedent).
>
> Even with an equivalent to nav-in (or nav->) I think that using datafy/nav
> on Java Time objects may be an incomplete mapping -- and probably somewhat
> hard to work with. When you first posted, I was more focused on the
> confusion using non-core datafy/nav would be and interop with REBL -- I
> didn't look too deep into the _actual_ navigation you were proposing,
> sorry.
>
> On Sun, Feb 9, 2020 at 1:19 AM dimitris  wrote:
>
>> Hi Sean,
>>
>> I'm back home and trying to understand/internalize this...Unfortunately,
>> this kind of (flat & arg-less) navigation is not going to be very useful
>> for the majority of java.time (datafied) objects. That is for two
>> reasons... First of all the datafied maps I'm returning are nested. This
>> means that for example to get to the `YearMonth` object, you would need to
>> navigate to the [:year :month] path, and in the absence of `nav-in` this is
>> somewhat awkward. Secondly, most of the interesting/useful conversions (in
>> the context of date-times), almost always requires some sort of argument
>> (e.g. `Instant` to `LocalDateTime`), and so if the last arg to `nav` has to
>> be either nil (for missing keys), or match the actual value in the map,
>> then there is no room left for arguments.
>>
>> It is true that I'm probably trying to do too much with `nav`, but now
>> that I'm understanding its purpose better, I get the feeling that it's not
>> going to be as useful as I originally thought (in the context of this lib).
>> Yes, I can pull all the clever stuff into distinct functions, but
>> ultimately for `nav` to be useful I would have to either:
>>
>> 1. Change the datafied representation to something flat, OR
>>
>> 2. accept that navigating to pure data (via `get-in`) will be done with
>> real paths (e.g. `[:year :month]`), whereas navigating to objects (via
>> `nav`) will be done with bogus

Re: ANN: jedi-time 0.1.4

[Sean Corfield]

Yes, I agree with all of that I think.

For nested navigation, consider that (get-in data [:year :month) is
equivalent to (get data :month (get data :year)) so you could nav one step
at a time. Calling nav (& then datafy) on the intermediate steps would just
bring you back to the data world at the same point as the inner (top-level)
get in that case.

nav-in would be a strange operation since it would need to call datafy
after each step to get the arguments needed for the next nav call. REBL
provides nav-> which does this behind the scenes while it is threading data
through the pipeline of nav operations (so there is a precedent).

Even with an equivalent to nav-in (or nav->) I think that using datafy/nav
on Java Time objects may be an incomplete mapping -- and probably somewhat
hard to work with. When you first posted, I was more focused on the
confusion using non-core datafy/nav would be and interop with REBL -- I
didn't look too deep into the _actual_ navigation you were proposing,
sorry.

On Sun, Feb 9, 2020 at 1:19 AM dimitris  wrote:

> Hi Sean,
>
> I'm back home and trying to understand/internalize this...Unfortunately,
> this kind of (flat & arg-less) navigation is not going to be very useful
> for the majority of java.time (datafied) objects. That is for two
> reasons... First of all the datafied maps I'm returning are nested. This
> means that for example to get to the `YearMonth` object, you would need to
> navigate to the [:year :month] path, and in the absence of `nav-in` this is
> somewhat awkward. Secondly, most of the interesting/useful conversions (in
> the context of date-times), almost always requires some sort of argument
> (e.g. `Instant` to `LocalDateTime`), and so if the last arg to `nav` has to
> be either nil (for missing keys), or match the actual value in the map,
> then there is no room left for arguments.
>
> It is true that I'm probably trying to do too much with `nav`, but now
> that I'm understanding its purpose better, I get the feeling that it's not
> going to be as useful as I originally thought (in the context of this lib).
> Yes, I can pull all the clever stuff into distinct functions, but
> ultimately for `nav` to be useful I would have to either:
>
> 1. Change the datafied representation to something flat, OR
>
> 2. accept that navigating to pure data (via `get-in`) will be done with
> real paths (e.g. `[:year :month]`), whereas navigating to objects (via
> `nav`) will be done with bogus keys (e.g. `:month-of-year`).
>
> As things stand (with my current nested representation), only LocalDate,
> LocalDateTime, OffsetDateTime & ZonedDateTime can have useful navigations:
>
> - LocalDate => :week-day , :year-month
>
> - LocalDateTime => :local-date, :local-time
>
> - OffsetDateTime => :local-datetime, :instant
>
> - ZonedDateTime => :offset-datetime, :local-datetime, :instant
>
> That is pretty much it in terms of `nav`...
>
> Does that make (more) sense?
>
>
> Many thanks in advance...
>
> Dimitris
>
> ps:  Sean I can be on slack but with my work email
>
>
> On 04/02/2020 05:18, Sean Corfield wrote:
>
> You're misunderstanding me. I'll try again.
>
> I'm not saying you can't navigate to keys that don't exist in the data --
> but since there would be no corresponding value, the nav call would be (nav
> coll k nil) essentially.
>
> If (get coll k) produces some value v, then (nav coll k v) will take you
> from the right side (pure data) to the left side (objects) to the object
> that "corresponds" to the equivalent navigation on the right (i.e., within
> the data).
>
> object -> datafy -> pure data
> pure data -> get etc -> new pure data
> pure data -> nav -> new object "corresponding" to new pure data
>
> On Mon, Feb 3, 2020 at 3:38 AM Dimitrios Jim Piliouras <
> jimpil1...@gmail.com> wrote:
>
>> This is what I've done but it contradicts what we said earlier...
>>
>> If I navigate to some existing key and it gives me back a Java object,
>> then it means that the datafied representation had a key pointing to non
>> data!
>>
>> I have read your blog post multiple times ;), but I think the situation
>> you're describing  with the foreign keys is rather unique...
>>
>> The datafied datetime cannot possibly include all its possible formats,
>> nor all the possible alternatives - that would be extremely wasteful and
>> meaningless the way I see it.
>>
>>
>> Let's take an Instant as an example...it datafies to map of two keys
>> (:epoch, :second). Does it make sense to add a :format-iso key in there
>> pointing to a String? Is there any point navigating to that key? Is there
>> any point navig

Re: Stack Overflow developer survey

[Sean Corfield]

I've been encouraging folks to take the survey and write in Clojure.
Representation matters!

On Wed, Feb 5, 2020 at 5:45 PM Matching Socks  wrote:

> Today, I noticed an invitation to complete the Stack Overflow developer
> survey.
>
> (Clojure was not on the menu.)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/f46ba1b5-72db-4a72-be41-6f0d83cd7839%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

RE: Bit rot and leiningen?

[Sean Corfield]

> because I still haven't found a development environment I like better than 
> LightTable

Have you looked at Atom/Chlorine recently? It has the same inline result 
display that LightTable had, it has a built-in ClojureScript REPL, support for 
Socket REPLs (in local and remote processes), and support for shadow-cljs if 
you’re in the ClojureScript world.

I used to use LightTable all the time but after it stopped being maintained I 
gave up on it and went back to Emacs for a while, then switched to 
Atom/ProtoREPL – until ProtoREPL stopped being maintained – and then to 
Atom/Chlorine where I’ve been extremely happy for over a year.

I’ve posted a few YouTube videos showing how I work with Atom/Chlorine and 
Cognitect’s REBL for data browsing/visualization: 
https://www.youtube.com/channel/UC8GD-smsEvNyRd3EZ8oeSrA

I have also have a repo of Atom/Chlorine customization/setup (mostly to enable 
the REBL integration I show in those videos): 
https://github.com/seancorfield/atom-chlorine-setup
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: 'Simon Brooke' via Clojure
Sent: Wednesday, February 5, 2020 2:16 AM
To: Clojure
Subject: Re: Bit rot and leiningen?


On Wednesday, 5 February 2020 09:59:25 UTC, Simon Brooke wrote:

On Tuesday, 4 February 2020 15:56:47 UTC, 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.

Thanks for this suggestion. Sadly, it doesn't help.

OK, I beg your pardon. It seems you were right. Upgrading lein-ring to 0.12.5 
and immediately doing a build did not work, but after a bit of tinkering a 
build did work, and the differences were:

- [com.stuartsierra/component "0.3.2"]
+ [com.stuartsierra/component "0.4.0"]
-    [lein-ring "0.8.13" :exclusions [org.clojure/clojure]]]
+    [lein-ring "0.12.5" :exclusions [org.clojure/clojure]]]

As Alex Miller suggests, the problem is that something isn't conformant to 
spec, and it isn't something in my code since that runs under Clojure 1.8 
(because I still haven't found a development environment I like better than 
LightTable). So it must be something in a leiningen plugin, so the change that 
worked must have been your change.

Many 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/4238247e-5ed7-474b-9905-b697c466b3e5%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/5e3b42ea.1c69fb81.828b6.28fd%40mx.google.com.

Re: ANN: jedi-time 0.1.4

[Sean Corfield]

You're misunderstanding me. I'll try again.

I'm not saying you can't navigate to keys that don't exist in the data --
but since there would be no corresponding value, the nav call would be (nav
coll k nil) essentially.

If (get coll k) produces some value v, then (nav coll k v) will take you
from the right side (pure data) to the left side (objects) to the object
that "corresponds" to the equivalent navigation on the right (i.e., within
the data).

object -> datafy -> pure data
pure data -> get etc -> new pure data
pure data -> nav -> new object "corresponding" to new pure data

On Mon, Feb 3, 2020 at 3:38 AM Dimitrios Jim Piliouras 
wrote:

> This is what I've done but it contradicts what we said earlier...
>
> If I navigate to some existing key and it gives me back a Java object,
> then it means that the datafied representation had a key pointing to non
> data!
>
> I have read your blog post multiple times ;), but I think the situation
> you're describing  with the foreign keys is rather unique...
>
> The datafied datetime cannot possibly include all its possible formats,
> nor all the possible alternatives - that would be extremely wasteful and
> meaningless the way I see it.
>
>
> Let's take an Instant as an example...it datafies to map of two keys
> (:epoch, :second). Does it make sense to add a :format-iso key in there
> pointing to a String? Is there any point navigating to that key? Is there
> any point navigating to :epoch or :second? The answer is no, right? Is
> there a point in navigating to :zoned-datetime given a zone id? I would
> think yes...
>
> On Mon, 3 Feb 2020, 04:47 Sean Corfield,  wrote:
>
>> Think of it as a square:
>>
>> You start with an object of some sort (left side) -> datafy -> turns it
>> into pure Clojure data (including metadata). (right side)
>>
>> Given pure Clojure data, you can navigate through it with get etc and you
>> stay in the right side (pure data).
>>
>> Given that pure Clojure data, you can navigate back to the left hand wide
>> with nav, mimicking how get etc work.
>>
>> So datafy is L -> R, get is R -> R, nav is R -> L on a "diagonal" that
>> takes you back to the object world on the left, corresponding to the place
>> on the right that you'd get to via get etc.
>>
>> See if this blog post helps
>> https://corfield.org/blog/2018/12/03/datafy-nav/
>>
>>
>> On Sun, Feb 2, 2020 at 1:22 AM Dimitrios Jim Piliouras <
>> jimpil1...@gmail.com> wrote:
>>
>>> Hi Sean,
>>>
>>>
>>>
>>> Admittedly, I’ve never used REBL, and I did struggle with the shape and
>>> name of the `nav` arguments...
>>>
>>>
>>>
>>> In particular I’m struggling to understand why would anyone use `nav` to
>>> navigate to a key that already exists in the map...Can’t we just use `get`
>>> or `get-in`?
>>>
>>> You used the :format as an example, which works with nil, :iso, or a
>>> String pattern as the last arg to nav. But again, :format is NOT in the
>>> datafied representation.
>>>
>>>
>>>
>>> In essence, I’ve tried to use `nav` to navigate to things that can be
>>> expensive and don’t necessarily belong in the actual datafied
>>> representation.
>>>
>>> If the second argument to `nav`,  is expected to be a key already
>>> present in the map, then I really don’t understand what is the point of
>>> `nav`.
>>>
>>>
>>>
>>> kind regards,
>>>
>>> Dimitris
>>>
>>>
>>>
>>>
>>>
>>> *From: *Sean Corfield 
>>> *Sent: *02 February 2020 07:36
>>> *To: *Clojure Mailing List 
>>> *Subject: *Re: ANN: jedi-time 0.1.4
>>>
>>>
>>>
>>> This is very cool but I would strongly recommend you try using this with
>>> REBL so you can figure out how to make the `nav` part work in a more
>>> natural way.
>>>
>>>
>>>
>>> nav is intended to work with a key and value (from the datafied
>>> structure), but your nav expects special values so it doesn't work with
>>> REBL.
>>>
>>>
>>>
>>> You can put (java.time.Instant/now) into REBL and your datafication
>>> produces a great data representation, but you can't navigate into it using
>>> the keys (and values) of the data structure itself. You can put :format
>>> into the nav-> bar and it defaults to a format you can get a string back,
>>> but none of the other nav calls will

Re: ANN: jedi-time 0.1.4

[Sean Corfield]

Think of it as a square:

You start with an object of some sort (left side) -> datafy -> turns it
into pure Clojure data (including metadata). (right side)

Given pure Clojure data, you can navigate through it with get etc and you
stay in the right side (pure data).

Given that pure Clojure data, you can navigate back to the left hand wide
with nav, mimicking how get etc work.

So datafy is L -> R, get is R -> R, nav is R -> L on a "diagonal" that
takes you back to the object world on the left, corresponding to the place
on the right that you'd get to via get etc.

See if this blog post helps https://corfield.org/blog/2018/12/03/datafy-nav/


On Sun, Feb 2, 2020 at 1:22 AM Dimitrios Jim Piliouras 
wrote:

> Hi Sean,
>
>
>
> Admittedly, I’ve never used REBL, and I did struggle with the shape and
> name of the `nav` arguments...
>
>
>
> In particular I’m struggling to understand why would anyone use `nav` to
> navigate to a key that already exists in the map...Can’t we just use `get`
> or `get-in`?
>
> You used the :format as an example, which works with nil, :iso, or a
> String pattern as the last arg to nav. But again, :format is NOT in the
> datafied representation.
>
>
>
> In essence, I’ve tried to use `nav` to navigate to things that can be
> expensive and don’t necessarily belong in the actual datafied
> representation.
>
> If the second argument to `nav`,  is expected to be a key already present
> in the map, then I really don’t understand what is the point of `nav`.
>
>
>
> kind regards,
>
> Dimitris
>
>
>
>
>
> *From: *Sean Corfield 
> *Sent: *02 February 2020 07:36
> *To: *Clojure Mailing List 
> *Subject: *Re: ANN: jedi-time 0.1.4
>
>
>
> This is very cool but I would strongly recommend you try using this with
> REBL so you can figure out how to make the `nav` part work in a more
> natural way.
>
>
>
> nav is intended to work with a key and value (from the datafied
> structure), but your nav expects special values so it doesn't work with
> REBL.
>
>
>
> You can put (java.time.Instant/now) into REBL and your datafication
> produces a great data representation, but you can't navigate into it using
> the keys (and values) of the data structure itself. You can put :format
> into the nav-> bar and it defaults to a format you can get a string back,
> but none of the other nav calls will work.
>
>
>
> You might consider combining the :format key with the actual format, e.g.,
> :format-iso, :format-yy-MM-dd and if the key is something your don't
> recognize, just let it behave like regular data navigation.
>
>
>
> I think you're trying to do too much with nav, beyond "navigation". I
> think you could split some of the "clever" navigation out into a transform
> function that takes a datafied time and produces a new datafied time, and
> then let nav do the "conversion" back to Java objects. You've complected
> the transforms and the conversion right now.
>
>
>
> If you're on Slack, I'm happy to DM about this in more detail (when you're
> back from traveling).
>
>
>
> Sean
>
>
>
> On Sat, Feb 1, 2020 at 6:02 AM dimitris  wrote:
>
> Hi folks,
>
> The first public release of `jedi-time` should be hitting clojars any
> minute now. I am traveling next week so may be slow to reply to
> feedback/bugs/PRs...
>
> https://github.com/jimpil/jedi-time
>
>
> Kind regards,
>
> Dimitris
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/8dbb9c5b-0ab0-fc76-6dc6-5e75b93d452a%40gmail.com
> .
>
>
>
>
> --
>
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles Networks, LLC. -- https://worldsinglesnetworks.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure"

Re: ANN: jedi-time 0.1.4

[Sean Corfield]

This is very cool but I would strongly recommend you try using this with
REBL so you can figure out how to make the `nav` part work in a more
natural way.

nav is intended to work with a key and value (from the datafied structure),
but your nav expects special values so it doesn't work with REBL.

You can put (java.time.Instant/now) into REBL and your datafication
produces a great data representation, but you can't navigate into it using
the keys (and values) of the data structure itself. You can put :format
into the nav-> bar and it defaults to a format you can get a string back,
but none of the other nav calls will work.

You might consider combining the :format key with the actual format, e.g.,
:format-iso, :format-yy-MM-dd and if the key is something your don't
recognize, just let it behave like regular data navigation.

I think you're trying to do too much with nav, beyond "navigation". I think
you could split some of the "clever" navigation out into a transform
function that takes a datafied time and produces a new datafied time, and
then let nav do the "conversion" back to Java objects. You've complected
the transforms and the conversion right now.

If you're on Slack, I'm happy to DM about this in more detail (when you're
back from traveling).

Sean

On Sat, Feb 1, 2020 at 6:02 AM dimitris  wrote:

> Hi folks,
>
> The first public release of `jedi-time` should be hitting clojars any
> minute now. I am traveling next week so may be slow to reply to
> feedback/bugs/PRs...
>
> https://github.com/jimpil/jedi-time
>
>
> Kind regards,
>
> Dimitris
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/8dbb9c5b-0ab0-fc76-6dc6-5e75b93d452a%40gmail.com
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

RE: Feedback on datafy/nav project

[Sean Corfield]

Dimitris,

As a follow-up to Alex’s comments: if you change your lib to extend the 
clojure.datafy version, I’ll almost certainly use your library  

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: Friday, January 31, 2020 1:23 PM
To: clojure@googlegroups.com
Subject: Re: Feedback on datafy/nav project

Ok, thanks a million Alex

On 31/01/2020 21:13, Alex Miller wrote:
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 

RE: Feedback on datafy/nav project

[Sean Corfield]

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 this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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/d0db9e09-6419-2e13-3a0b-9bacf2bbf4fd%40gmail.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/5e331755.1c69fb81.ff1ad.21cf%40mx.google.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+u

RE: Feedback on datafy/nav project

[Sean Corfield]

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 this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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/d0db9e09-6419-2e13-3a0b-9bacf2bbf4fd%40gmail.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/5e331755.1c69fb81.ff1ad.21cf%40mx.google.com.

Re: Upcoming changes to Clojars

[Sean Corfield]

Will the upload URL or process be changing?

On Mon, Dec 23, 2019 at 9:51 AM Toby Crawley  wrote:

> Howdy folks! We're in the process of making some changes to the
> Clojars infrastructure to make it more robust, reliable, and easier to
> maintain. One of those changes will be to provide a single canonical
> repository instead of serving artifacts from two locations.
>
>
> ## A Tale of Two Repositories
>
> You can currently access the Clojars repository in two ways:
>
> - via the "on-disk" repository at https://clojars.org/repo/
> - via the "cdn-fronted" repository at https://repo.clojars.org/
>
> The artifacts for these two repositories are stored in different
> places. The on-disk repository serves from the disk of the clojars.org
> server. The cdn-fronted repository serves from a Rackspace Cloudfiles
> repository. When a deploy occurs, it is first written to disk, then
> uploaded to Cloudfiles. The intent was for the repositoriesitories to
> be identical, but that hasn't always been the case - we would
> occasionally fail to upload artifacts to the Cloudfiles repository,
> leaving the two repositories out of sync. We've done recent work[1] to
> mitigate that, but would like to move to having a single,
> Cloudfiles/blobstore-based repository.
>
>
> ## The proposed changes
>
> In order to have a single repository, we plan to make the following
> changes:
>
> - Any GET requests to the on-disk repository at
>   https://clojars.org/repo/ will be redirected to the
>   cdn-fronted repository at https://repo.clojars.org/
> - Deploys will no longer write to the on-disk repository, just to the
>   cdn-fronted one
>
>
> ## Timeline
>
> We would like to make these changes within the next few weeks, but may
> delay that based on your feedback (see below).
>
>
> ## How this will affect you
>
> If you are using a modern version of lein (2.8.0 or newer), boot
> (2.7.0 or newer), or tools.deps.alpha (0.5.425 or newer), you are
> already using the cdn-fronted repository, and should see no issues
> with dependency resolution or deployment.
>
> The cdn-fronted repository uses some TLS features that aren't
> supported by older java versions by default. If you are using an older
> version of Java (pre-Java 8), you may be using older build tools or
> have configured newer versions of the tools to point to the on-disk
> repository to avoid this. With this change, you may no longer be able
> to resolve dependencies. If this affects you, we would love to hear
> about it!  Please comment on the issue where this change is being
> discussed[2].
>
> Once we remove the on-disk repository, rsync'ing a copy of the
> repository will no longer be a supported feature. Based on our rsync
> logs, it looks like we've had ~100k rsync connections over the last
> month from ~100 ip addresses. But the bulk of those requests were over
> a few scattered days where a single ip would connect every 2-5
> *seconds*. If you are using the rsync feature to maintain a copy of
> the repository, please comment on the issue where this change is being
> discussed[3] to let us know your use case and we'll see if we can come
> up with an alternate solution.
>
> [1]:
> https://groups.google.com/forum/#!topic/clojars-maintainers/FXcV6O-FjiA
> [2]: https://github.com/clojars/clojars-web/issues/734
> [3]: https://github.com/clojars/clojars-web/issues/735
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/CAA3HuyZtb1jOmNgYA%2BcLpvcxk-Yce74G4KRGKctbA6xuc-x19w%40mail.gmail.com
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

[ANN] seancorfield/next.jdbc 1.0.10

[Sean Corfield]

The next generation Clojure wrapper for JDBC-based access to databases.

https://github.com/seancorfield/next-jdbc

Support available via Clojurians Slack in the #sql channel.

Enhancements:
• Fix #75 by adding support for java.sql.Statement to plan, execute!, and 
execute-one!.
• Fix #73 by providing a new, optional namespace next.jdbc.date-time that can 
be required if your database driver needs assistance converting java.util.Date 
(PostgreSQL!) or the Java Time types to SQL timestamp (or SQL date/time).
• Address #70 by adding CLOB & BLOB SQL Types to the Tips & Tricks section of 
Friendly SQL Functions and by adding next.jdbc.result-set/clob-column-reader 
and next.jdbc.result-set/clob->string helper to make it easier to deal with 
CLOB column data.
Documentation:
• Fix link to All The Options in Migration from clojure.java.jdbc. PR #71 
(@laurio).
• Clarify what execute! and execute-one! produce when the result set is empty 
([] and nil respectively, and there are now tests for this). Similarly for 
find-by-keys and get-by-id.
• Add MS SQL Server section to Tips & Tricks to note that it returns an empty 
string for table names by default (so table-qualified column names are not 
available). Using the :result-type (scroll) and :concurrency options will cause 
table names to be returned.
• Clarify that Friendly SQL Functions are deliberately simple (hint: they will 
not be enhanced or expanded -- use plan, execute!, and execute-one! instead, 
with a DSL library if you want!).
• Improve migration docs: explicitly recommend the use of a datasource for code 
that needs to work with both clojure.java.jdbc and next.jdbc; add caveats about 
column name conflicts (in several places).
• Improve datafy/nav documentation around :schema.
Miscellaneous:
• Address #74 by making several small changes to satisfy Eastwood.
• Update org.clojure/java.data to "0.1.4" (0.1.2 fixes a number of reflection 
warnings).


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

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

[ANN] org.clojure/core.memoize 0.8.2

[Sean Corfield]

Pluggable memoization based on org.clojure/core.cache

https://github.com/clojure/core.memoize

New in 0.8.2:
- updates core.cache dependency to 0.8.2
- fixes a bug in the seed implementation for PluggableMemoization
- adds memoizer as an easier way to build memoization on top of custom
caches
- deprecates build-memoizer (the older, harder way to build memoization on
top of custom cache factories)

The bump in version number (from 0.7.2) is partly to signify the internal
re-plumbing to use memoizer instead of build-memoizer and partly to get
back in sync with core.cache, since the two libraries are fairly tightly
coupled.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: [?] Spec error: please tell me the reason.

[Sean Corfield]

With that correction, you should see:

spec-test=> (transform-fontspecs test-sample)
{"283f1EV" {:size 21, :family "c2S6", :color ""}, "BzYMt4eEm" {:size -5,
:family "q0xhOE3", :color "bhV3PsVh"}, "uA2i" {:size -5, :family "HHGoD",
:color "J47ZX935"}}
spec-test=>

On Wed, Oct 30, 2019 at 9:51 PM Sean Corfield  wrote:

> (s/def ::fontspecs (s/coll-of ::fontspec))
>
> Sorry, I missed that error first time around. s/* is a regex spec but your
> argument should be a collection of ::fontspec
>
> On Wed, Oct 30, 2019 at 9:02 PM Philos Kim  wrote:
>
>> Thanks for your answer!
>>
>> I corrected the code like the following according to your advice.
>>
>> (s/fdef transform-fontspecs
>>   :args (s/cat :fontspecs ::fontspecs))
>>
>> However, the same error occurs again.
>>
>> 2019년 10월 31일 목요일 오전 11시 44분 46초 UTC+9, Philos Kim 님의 말:
>>>
>>> I don't know why the following spec error occurred.
>>>
>>> Could anyone tell me why?
>>>
>>> (ns spec-test
>>>(:require [clojure.spec.alpha :as s]
>>>  [clojure.spec.test.alpha :as stest]))
>>>
>>> ;;; spec definitions
>>>
>>> (s/def :msds.fontspec/tag #{:fontspec})
>>>
>>> (s/def ::id string?)
>>> (s/def ::size int?)
>>> (s/def ::family string?)
>>> (s/def ::color string?)
>>>
>>> (s/def :msds.fontspec/attrs
>>>   (s/keys :req-un [::id ::size ::family ::color]))
>>>
>>> (s/def :msds.fontspec/content (s/cat))
>>>
>>> (s/def ::fontspec
>>>   (s/keys :req-un [:msds.fontspec/tag :msds.fontspec/attrs
>>> :msds.fontspec/content]))
>>>
>>> (s/def ::fontspecs (s/* ::fontspec))
>>>
>>>
>>> ;;; spec application
>>>
>>> (defn transform-fontspecs
>>>   "fontspecs를 사용하기 편리한 형태로 변환한다."
>>>   [fontspecs]
>>>   (->> fontspecs
>>>(map (fn [{:keys [attrs] :as fontspec}]
>>>   [(get attrs :id) (dissoc attrs :id)] ))
>>>(into {}) ))
>>>
>>> (s/fdef transform-fontspecs
>>>   :args ::fontspecs)
>>>
>>> (stest/instrument `transform-fontspecs)
>>>
>>>
>>> ;;; test code
>>>
>>> (def test-sample
>>>   '({:tag :fontspec,
>>>  :attrs {:id "283f1EV", :size 21, :family "c2S6", :color ""},
>>>  :content ()}
>>> {:tag :fontspec,
>>>  :attrs
>>>  {:id "BzYMt4eEm", :size -5, :family "q0xhOE3", :color "bhV3PsVh"},
>>>  :content ()}
>>> {:tag :fontspec,
>>>  :attrs {:id "uA2i", :size -5, :family "HHGoD", :color "J47ZX935"},
>>>  :content ()}))
>>>
>>> (transform-fontspecs test-sample)
>>> 2. Unhandled clojure.lang.Compiler$CompilerException
>>>Error compiling src/spec_test.clj at (55:1)
>>>#:clojure.error{:phase :compile-syntax-check,
>>>:line 55,
>>>:column 1,
>>>:source "/home/philos/work/metapdf/src/spec_test.clj"}
>>>  Compiler.java: 7648  clojure.lang.Compiler/load
>>>   REPL:1  metapdf.core/eval19243
>>>   REPL:1  metapdf.core/eval19243
>>>  Compiler.java: 7177  clojure.lang.Compiler/eval
>>>  Compiler.java: 7132  clojure.lang.Compiler/eval
>>>   core.clj: 3214  clojure.core/eval
>>>   core.clj: 3210  clojure.core/eval
>>>   main.clj:  437  clojure.main/repl/read-eval-print/fn
>>>   main.clj:  437  clojure.main/repl/read-eval-print
>>>   main.clj:  458  clojure.main/repl/fn
>>>   main.clj:  458  clojure.main/repl
>>>   main.clj:  368  clojure.main/repl
>>>RestFn.java: 1523  clojure.lang.RestFn/invoke
>>> interruptible_eval.clj:   79
>>> nrepl.middleware.interruptible-eval/evaluate
>>> interruptible_eval.clj:   55
>>> nrepl.middleware.interruptible-eval/evaluate
>>> interruptible_eval.clj:  142
>>> nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
>>>   AFn.java:   22  clojure.lang.AFn/run
>>>session.clj:  171
>>> nrepl.middle

Re: [?] Spec error: please tell me the reason.

[Sean Corfield]

(s/def ::fontspecs (s/coll-of ::fontspec))

Sorry, I missed that error first time around. s/* is a regex spec but your
argument should be a collection of ::fontspec

On Wed, Oct 30, 2019 at 9:02 PM Philos Kim  wrote:

> Thanks for your answer!
>
> I corrected the code like the following according to your advice.
>
> (s/fdef transform-fontspecs
>   :args (s/cat :fontspecs ::fontspecs))
>
> However, the same error occurs again.
>
> 2019년 10월 31일 목요일 오전 11시 44분 46초 UTC+9, Philos Kim 님의 말:
>>
>> I don't know why the following spec error occurred.
>>
>> Could anyone tell me why?
>>
>> (ns spec-test
>>(:require [clojure.spec.alpha :as s]
>>  [clojure.spec.test.alpha :as stest]))
>>
>> ;;; spec definitions
>>
>> (s/def :msds.fontspec/tag #{:fontspec})
>>
>> (s/def ::id string?)
>> (s/def ::size int?)
>> (s/def ::family string?)
>> (s/def ::color string?)
>>
>> (s/def :msds.fontspec/attrs
>>   (s/keys :req-un [::id ::size ::family ::color]))
>>
>> (s/def :msds.fontspec/content (s/cat))
>>
>> (s/def ::fontspec
>>   (s/keys :req-un [:msds.fontspec/tag :msds.fontspec/attrs
>> :msds.fontspec/content]))
>>
>> (s/def ::fontspecs (s/* ::fontspec))
>>
>>
>> ;;; spec application
>>
>> (defn transform-fontspecs
>>   "fontspecs를 사용하기 편리한 형태로 변환한다."
>>   [fontspecs]
>>   (->> fontspecs
>>(map (fn [{:keys [attrs] :as fontspec}]
>>   [(get attrs :id) (dissoc attrs :id)] ))
>>(into {}) ))
>>
>> (s/fdef transform-fontspecs
>>   :args ::fontspecs)
>>
>> (stest/instrument `transform-fontspecs)
>>
>>
>> ;;; test code
>>
>> (def test-sample
>>   '({:tag :fontspec,
>>  :attrs {:id "283f1EV", :size 21, :family "c2S6", :color ""},
>>  :content ()}
>> {:tag :fontspec,
>>  :attrs
>>  {:id "BzYMt4eEm", :size -5, :family "q0xhOE3", :color "bhV3PsVh"},
>>  :content ()}
>> {:tag :fontspec,
>>  :attrs {:id "uA2i", :size -5, :family "HHGoD", :color "J47ZX935"},
>>  :content ()}))
>>
>> (transform-fontspecs test-sample)
>> 2. Unhandled clojure.lang.Compiler$CompilerException
>>Error compiling src/spec_test.clj at (55:1)
>>#:clojure.error{:phase :compile-syntax-check,
>>:line 55,
>>:column 1,
>>:source "/home/philos/work/metapdf/src/spec_test.clj"}
>>  Compiler.java: 7648  clojure.lang.Compiler/load
>>   REPL:1  metapdf.core/eval19243
>>   REPL:1  metapdf.core/eval19243
>>  Compiler.java: 7177  clojure.lang.Compiler/eval
>>  Compiler.java: 7132  clojure.lang.Compiler/eval
>>   core.clj: 3214  clojure.core/eval
>>   core.clj: 3210  clojure.core/eval
>>   main.clj:  437  clojure.main/repl/read-eval-print/fn
>>   main.clj:  437  clojure.main/repl/read-eval-print
>>   main.clj:  458  clojure.main/repl/fn
>>   main.clj:  458  clojure.main/repl
>>   main.clj:  368  clojure.main/repl
>>RestFn.java: 1523  clojure.lang.RestFn/invoke
>> interruptible_eval.clj:   79
>> nrepl.middleware.interruptible-eval/evaluate
>> interruptible_eval.clj:   55
>> nrepl.middleware.interruptible-eval/evaluate
>> interruptible_eval.clj:  142
>> nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
>>   AFn.java:   22  clojure.lang.AFn/run
>>session.clj:  171
>> nrepl.middleware.session/session-exec/main-loop/fn
>>session.clj:  170
>> nrepl.middleware.session/session-exec/main-loop
>>   AFn.java:   22  clojure.lang.AFn/run
>>Thread.java:  748  java.lang.Thread/run
>>
>> 1. Caused by clojure.lang.ExceptionInfo
>>Spec assertion failed.
>>
>>  Spec: #object[clojure.spec.alpha$regex_spec_impl$reify__2509
>> 0x3660c4ee "clojure.spec.alpha$regex_spec_impl$reify__2509@3660c4ee"]
>> Value: (({:tag :fontspec,
>>   :attrs {:id "283f1EV", :size 21, :family "c2S6", :color
>> ""},
>>   :content ()}
>>  {:tag :fontspec,
>>   :attrs
>>   {:id "BzYMt4eEm", :size -5, :family "q0xhOE3", :color
>> "bhV3PsVh"},
>>   :content ()}
>>  {:tag :fontspec,
>>   :attrs {:id "uA2i", :size -5, :family "HHGoD", :color
>> "J47ZX935"},
>>   :content ()}))
>>
>>  Problems:
>>
>> val: ({:tag :fontspec,
>>:attrs {:id "283f1EV", :size 21, :family "c2S6",
>> :color ""},
>>:content ()}
>>   {:tag :fontspec,
>>:attrs
>>{:id "BzYMt4eEm", :size -5, :family "q0xhOE3", :color
>> "bhV3PsVh"},
>>:content ()}
>>   {:tag :fontspec,
>>:attrs {:id "uA2i", :size -5, :family "HHGoD", :color
>> "J47ZX935"},
>>:content ()})
>>

Re: [?] Spec error: please tell me the reason.

[Sean Corfield]

s/fdef's :args should be a sequence of the arguments to the function. In
this case it should be :args (s/cat :fontspecs ::fontspecs) which indicates
it is a sequence with one element, named :fontspecs, whose spec is
::fontspecs

On Wed, Oct 30, 2019 at 7:45 PM Philos Kim  wrote:

> I don't know why the following spec error occurred.
>
> Could anyone tell me why?
>
> (ns spec-test
>(:require [clojure.spec.alpha :as s]
>  [clojure.spec.test.alpha :as stest]))
>
> ;;; spec definitions
>
> (s/def :msds.fontspec/tag #{:fontspec})
>
> (s/def ::id string?)
> (s/def ::size int?)
> (s/def ::family string?)
> (s/def ::color string?)
>
> (s/def :msds.fontspec/attrs
>   (s/keys :req-un [::id ::size ::family ::color]))
>
> (s/def :msds.fontspec/content (s/cat))
>
> (s/def ::fontspec
>   (s/keys :req-un [:msds.fontspec/tag :msds.fontspec/attrs
> :msds.fontspec/content]))
>
> (s/def ::fontspecs (s/* ::fontspec))
>
>
> ;;; spec application
>
> (defn transform-fontspecs
>   "fontspecs를 사용하기 편리한 형태로 변환한다."
>   [fontspecs]
>   (->> fontspecs
>(map (fn [{:keys [attrs] :as fontspec}]
>   [(get attrs :id) (dissoc attrs :id)] ))
>(into {}) ))
>
> (s/fdef transform-fontspecs
>   :args ::fontspecs)
>
> (stest/instrument `transform-fontspecs)
>
>
> ;;; test code
>
> (def test-sample
>   '({:tag :fontspec,
>  :attrs {:id "283f1EV", :size 21, :family "c2S6", :color ""},
>  :content ()}
> {:tag :fontspec,
>  :attrs
>  {:id "BzYMt4eEm", :size -5, :family "q0xhOE3", :color "bhV3PsVh"},
>  :content ()}
> {:tag :fontspec,
>  :attrs {:id "uA2i", :size -5, :family "HHGoD", :color "J47ZX935"},
>  :content ()}))
>
> (transform-fontspecs test-sample)
> 2. Unhandled clojure.lang.Compiler$CompilerException
>Error compiling src/spec_test.clj at (55:1)
>#:clojure.error{:phase :compile-syntax-check,
>:line 55,
>:column 1,
>:source "/home/philos/work/metapdf/src/spec_test.clj"}
>  Compiler.java: 7648  clojure.lang.Compiler/load
>   REPL:1  metapdf.core/eval19243
>   REPL:1  metapdf.core/eval19243
>  Compiler.java: 7177  clojure.lang.Compiler/eval
>  Compiler.java: 7132  clojure.lang.Compiler/eval
>   core.clj: 3214  clojure.core/eval
>   core.clj: 3210  clojure.core/eval
>   main.clj:  437  clojure.main/repl/read-eval-print/fn
>   main.clj:  437  clojure.main/repl/read-eval-print
>   main.clj:  458  clojure.main/repl/fn
>   main.clj:  458  clojure.main/repl
>   main.clj:  368  clojure.main/repl
>RestFn.java: 1523  clojure.lang.RestFn/invoke
> interruptible_eval.clj:   79
> nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj:   55
> nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj:  142
> nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
>   AFn.java:   22  clojure.lang.AFn/run
>session.clj:  171
> nrepl.middleware.session/session-exec/main-loop/fn
>session.clj:  170
> nrepl.middleware.session/session-exec/main-loop
>   AFn.java:   22  clojure.lang.AFn/run
>Thread.java:  748  java.lang.Thread/run
>
> 1. Caused by clojure.lang.ExceptionInfo
>Spec assertion failed.
>
>  Spec: #object[clojure.spec.alpha$regex_spec_impl$reify__2509
> 0x3660c4ee "clojure.spec.alpha$regex_spec_impl$reify__2509@3660c4ee"]
> Value: (({:tag :fontspec,
>   :attrs {:id "283f1EV", :size 21, :family "c2S6", :color
> ""},
>   :content ()}
>  {:tag :fontspec,
>   :attrs
>   {:id "BzYMt4eEm", :size -5, :family "q0xhOE3", :color
> "bhV3PsVh"},
>   :content ()}
>  {:tag :fontspec,
>   :attrs {:id "uA2i", :size -5, :family "HHGoD", :color
> "J47ZX935"},
>   :content ()}))
>
>  Problems:
>
> val: ({:tag :fontspec,
>:attrs {:id "283f1EV", :size 21, :family "c2S6", :color
> ""},
>:content ()}
>   {:tag :fontspec,
>:attrs
>{:id "BzYMt4eEm", :size -5, :family "q0xhOE3", :color
> "bhV3PsVh"},
>:content ()}
>   {:tag :fontspec,
>:attrs {:id "uA2i", :size -5, :family "HHGoD", :color
> "J47ZX935"},
>:content ()})
>  in: [0]
>  failed: map?
>spec: :spec-test/fontspec
>
>  alpha.clj:  132
> clojure.spec.test.alpha/spec-checking-fn/conform!
>  alpha.clj:  140
> clojure.spec.test.alpha/spec-checking-fn/fn
>RestFn.java:  408  clojure.lang.RestFn/invoke
>  spec_test.clj:  

RE: How can I do something like (= (class ds) next.jdbc.connection)??

[Sean Corfield]

With the clue you gave me, I can look at that page and I see that 
javax.sql.DataSource is used in two protocols, so I guess I could then look to 
see where those protocols are used. But I'm thinking there might be an easier 
way to reverse-engineer an interface or class to get something that I can use 
in an if statement, when I'm adding in a runtime check?

Maybe take a step back and explain the problem you are trying to solve here?

It sounds like you’re trying to jump into some really low-level stuff that you 
almost certainly do not need to do. You asked “What is the correct way to do 
this?” but it’s not at all clear what you’re trying to do so I don’t know how 
to answer it, other than suggesting you read the docs and join the Slack 
community so you can have real time conversations where folks can better 
understand how to help you by asking you questions and looking at your code. 
The mailing list is just too slow a medium for the sort of conversations I 
think you need to have at this stage in your Clojure journey.

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: Laws
Sent: Tuesday, October 22, 2019 3:17 PM
To: Clojure
Subject: Re: How can I do something like (= (class ds) next.jdbc.connection)??

> The ds binding that you have will satisfy this check (instance? 
> javax.sql.DataSource ds) -- 
> because it is an instance of that Java interface.

My experience so far has been a lot of this stuff seems like commonsense to 
those programmers who have a background with Java, but those of us who learn 
Clojure without knowing Java have a harder time picking this up. Part of my 
question was "How do I know this?" Or in your case, how did you know this? The 
reason I included the link to the Github page is I was hoping to find out what 
on that page I was supposed to look at to figure out the answer. 

With the clue you gave me, I can look at that page and I see that 
javax.sql.DataSource is used in two protocols, so I guess I could then look to 
see where those protocols are used. But I'm thinking there might be an easier 
way to reverse-engineer an interface or class to get something that I can use 
in an if statement, when I'm adding in a runtime check? I'm a little surprised 
that (class) and (type) and (ancestors) did not give me something that I could 
use. 


On Friday, October 18, 2019 at 12:23:02 AM UTC-4, Sean Corfield wrote:
You should :require the namespaces, not try to :import things.

(ns your.namespace
  (:require [next.jdbc :as jdbc]))

I suggest you start off by working through 
https://cljdoc.org/d/seancorfield/next.jdbc/1.0.9/doc/getting-started 

The ds binding that you have will satisfy this check (instance? 
javax.sql.DataSource ds) -- because it is an instance of that Java interface.

It sounds like you have quite a few misconceptions about using the library (and 
perhaps using Clojure in general?) so I highly recommend joining the Clojurians 
Slack http://clojurians.net and https://clojurians.slack.com where you can ask 
real time questions in the #beginners channel and next.jdbc-specific questions 
in the #sql channel.



On Thu, Oct 17, 2019 at 6:03 PM Laws  wrote:
If I do this:

(class ds)

I see: 

next.jdbc.connection$url_PLUS_etc$reify__555

Is there anyway I can match against this? I'd like a runtime check to know that 
the code really does have a database connection. Imagine code like this:

(if (= next.jdbc.connection (class ds))
      (println "its next.jdbc.connection")
      (println "fail, it is not next.jdbc.connection"))

I get errors such as:

java.lang.ClassNotFoundException: seancorfield/next.jdbc.Connection, 
compiling:(core.clj:1:1)

The namespace is here:

https://github.com/seancorfield/next-jdbc/blob/master/src/next/jdbc/connection.clj


   (:import
   [seancorfield/next.jdbc Connection]
   )

   (:import
   [next.jdbc Connection]
   )

   (:import
   [next.jdbc.connection]
   )


What is the correct way to do this? 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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/8a486bd5-bb5f-41ef-bcb6-74e49ed58db4%40googlegroups.com.



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- ht

Re: How can I do something like (= (class ds) next.jdbc.connection) ??

[Sean Corfield]

You should :require the namespaces, not try to :import things.

(ns your.namespace
  (:require [next.jdbc :as jdbc]))

I suggest you start off by working through
https://cljdoc.org/d/seancorfield/next.jdbc/1.0.9/doc/getting-started

The ds binding that you have will satisfy this check (instance?
javax.sql.DataSource ds) -- because it is an instance of that Java
interface.

It sounds like you have quite a few misconceptions about using the library
(and perhaps using Clojure in general?) so I highly recommend joining the
Clojurians Slack http://clojurians.net and https://clojurians.slack.com
where you can ask real time questions in the #beginners channel and
next.jdbc-specific questions in the #sql channel.



On Thu, Oct 17, 2019 at 6:03 PM Laws  wrote:

> If I do this:
>
> (class ds)
>
> I see:
>
> next.jdbc.connection$url_PLUS_etc$reify__555
>
> Is there anyway I can match against this? I'd like a runtime check to know
> that the code really does have a database connection. Imagine code like
> this:
>
> (if (= next.jdbc.connection (class ds))
>   (println "its next.jdbc.connection")
>   (println "fail, it is not next.jdbc.connection"))
>
> I get errors such as:
>
> java.lang.ClassNotFoundException: seancorfield/next.jdbc.Connection,
> compiling:(core.clj:1:1)
>
> The namespace is here:
>
>
> https://github.com/seancorfield/next-jdbc/blob/master/src/next/jdbc/connection.clj
>
>
>(:import
>[seancorfield/next.jdbc Connection]
>)
>
>(:import
>[next.jdbc Connection]
>)
>
>(:import
>[next.jdbc.connection]
>)
>
>
> What is the correct way to do this?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/8a486bd5-bb5f-41ef-bcb6-74e49ed58db4%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

[ANN] seancorfield/next.jdbc 1.0.8

[Sean Corfield]

The next generation of clojure.java.jdbc** – a new low-level Clojure wrapper 
for JDBC-based access to databases!

https://github.com/seancorfield/next-jdbc -- source
https://cljdoc.org/d/seancorfield/next.jdbc -- documentation
https://clojars.org/seancorfield/next.jdbc -- clojars

It’s been about four months since I announced the “gold” 1.0.0 release here on 
this list so I thought it was about time to post another announcement.

Nearly all of the work in the last eight patch releases has gone into improving 
the documentation, adding clarifications, expanding examples, providing 
database-specific caveats (and helpful tips). The latest release includes an 
example of using HugSQL 0.5.1’s new next.jdbc adapter (thanks to Nikola Peric 
for writing that adapter!).

Some of the (purely additive) changes since 1.0.0:
• Add next.jdbc.connection/->pool to support connection pooled datasources via 
c3p0 and HikariCP.
• Add next.jdbc.prepare/execute-batch! to support batch execution (if your 
database supports it).
• Add next.jdbc.result-set/as-maps-adapter (and as-arrays-adapter) to make it 
easier to deal with database-specific JDBC data types.
• Making it easier to use next.jdbc with JDBC drivers it doesn’t already know 
about (both local and remote).

You can read the latest, complete changelog here 
https://github.com/seancorfield/next-jdbc/blob/master/CHANGELOG.md (including 
changes on master since 1.0.8).

If you have any questions or issues with next.jdbc, reach out to me on the 
Clojurians Slack via the #sql channel.

** clojure.java.jdbc is now considered “Stable -- working but development is 
irregular” here https://clojure.org/community/contrib_libs -- it will continue 
to get bug fixes but no new features at this point. Read 
https://cljdoc.org/d/seancorfield/next.jdbc/CURRENT/doc/migration-from-clojure-java-jdbc
 to see what’s involved in migrating to next.jdbc (it is not a drop-in 
replacement).

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

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

RE: records alias with local vars

[Sean Corfield]

Yup. Repro’d it now. Not sure why I didn’t get the reflection warning when I 
tried it yesterday. Weird.

Definitely looks like a bug.

I guess almost no one has ever run into this because it’s idiomatic (and almost 
universal, I expect) to use CamelCase for record names and kebab-case for 
arguments/locals so they would never normally conflict…?

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: Andy Fingerhut
Sent: Wednesday, August 28, 2019 7:06 PM
To: clojure@googlegroups.com
Subject: Re: records alias with local vars

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

Andy

On Wed, Aug 28, 2019 at 6:35 PM Sean Corfield  wrote:
What version of Clojure/Script are you using? This works fine for me on Clojure 
1.10.1.

On Wed, Aug 28, 2019 at 4:08 PM Brian Craft  wrote:
In this example

(defrecord x [y])

(defn b [x] (.getBytes ^String x))


The compiler fails to resolve .getBytes. It emits reflection code, saying x is 
a class. It is resolved by deleting the defrecord, or renaming the parameter.

Is this expected, or documented? Are there other cases like this?
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/38933dc0-1b8e-452a-ae01-feec77739623%40googlegroups.com.



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAD4thx9mFjG-5QvuiYK40JnOa%3DgiC4gvap4qkMiLpf0inZJCug%40mail.gmail.com.
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAKvLtDZPz7OidY09JoWD-gcKiKxveD4RO7DPdRe71Z_-mae00g%40mail.gmail.com.

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

Re: records alias with local vars

[Sean Corfield]

What version of Clojure/Script are you using? This works fine for me on
Clojure 1.10.1.

On Wed, Aug 28, 2019 at 4:08 PM Brian Craft  wrote:

> In this example
>
> (defrecord x [y])
>
> (defn b [x] (.getBytes ^String x))
>
>
> The compiler fails to resolve .getBytes. It emits reflection code, saying
> x is a class. It is resolved by deleting the defrecord, or renaming the
> parameter.
>
> Is this expected, or documented? Are there other cases like this?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/38933dc0-1b8e-452a-ae01-feec77739623%40googlegroups.com
> 
> .
>


-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

[ANN] org.clojure/core.cache 0.8.1

[Sean Corfield]

A caching library for Clojure implementing various cache strategies https://github.com/clojure/core.cache The core.cache library API has always assumed that you store the (immutable) caches in a Clojure reference type (usually an atom) so it has often been confusing to newcomers and it comes with a far bit of boilerplate since all that atom-wrapping code gets written by everyone and there are some edge cases to watch out for (such as potential cache stampede when using `through` or `through-cache` because of potential retries). The 0.8.0 release adds a new namespace, clojure.core.cache.wrapped, that is “identical” to the main API but operates on atoms (containing caches) instead of bare caches. The factory functions return atoms, all the other functions accept atoms (but return the same thing as the main API – often the updated immutable cache itself). The 0.8.1 release fixes a bug in 0.8.0’s wrapped TTL cache. There’s also a new `lookup-or-miss` function that’s like `through-cache` in the old API but avoids cache stampede by only evaluating `wrap-fn` and `value-fn` at most once, no matter how many retries there are. This is a completely additive release (despite the 0.7.2 -> 0.8.x version bump, which reflects the new API namespace addition) and I hope it will make core.cache easier to use for the “mainstream” cases in the wild. See https://cljdoc.org/d/org.clojure/core.cache/0.8.0/api/clojure.core.cache.wrapped#lookup-or-miss for the new function. Reminder: Contrib projects are governed by the Clojure CA process and use JIRA/patches: https://clojure.atlassian.net/projects/CCACHE/issues/?filter=allopenissues If you don’t have a JIRA account, you can raise issues (and ask questions) about core.cache here: https://ask.clojure.org/index.php/questions/contrib-libs/core-cache Sean Corfield -- (904) 302-SEANAn Architect's View -- http://corfield.org/"If you're not annoying somebody, you're not really alive."-- Margaret Atwood 



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

Re: [ANN] clj 1.10.1.458 and tools.deps.alpha 0.7.516

[Sean Corfield]

Thanks Alex.

I'm updating clj-new to use default-deps and will release a new version 
later today.

On Saturday, June 29, 2019 at 11:44:31 AM UTC-7, Alex Miller wrote:
>
> A new version of clj and tools.deps.alpha are now available.
>
> - Mac - `brew upgrade clojure`
> - Linux - see scripts at https://clojure.org/guides/getting_started
> - Windows - see 
> https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Windows
>
> Tickets and issues affected by these releases:
>
> - fix formatting issues in clj man page and help
> - fix TDEPS-131 - update bug tracker link in man page
> - fix TDEPS-52 - transitive deps pick up :paths from current project
> - fix TDEPS-88 - set meaning of -Srepro
> - fix TDEPS-96 - fix relative path calculation for transitive pom projects
> - partial fix TDEPS-127 - for overlap covered by TDEPS-96
> - won't fix TDEPS-80 - means to get classpath for tools.deps, already 
> exists
> - won't fix TDEPS-57 - give names to config files
> - add new clojure.tools.deps.alpha.reader/default-deps and 
> ctdar/install-dep
> - deprecate clojure.tools.deps.alpha.reader/clojure-env
>
> Primarily, these changes all focus around moving the install-level 
> deps.edn inside tools.deps.alpha as a resource,
> rather than being picked up from the file system. This addresses a number 
> of issues, allowing it to be used
> automatically rather than needing to be found and explicitly included at 
> the appropriate deps reader times.
>
> The changes at the end are concerned with deprecating (and eventually 
> removing) ctdar/clojure-env, which shells
> out to clj to build a set of config data, including the list of config 
> files. As the install-level file no longer exists, it is
> now easy to replicate the calculations done by clj inside the code, 
> without shelling out. Library users of 
> tools.deps.alpha should replace calls to (:config-files 
> (reader/clojure-env)) with (reader/default-deps). Several
> tools have already been patched.
>

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

RE: Calling Java from Clojure

[Sean Corfield]

Oh, you know me: I avoid AOT and gen-class at all costs _if I don’t have to use 
them_ 

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 Alex 
Miller 
Sent: Friday, June 21, 2019 1:53:43 PM
To: clojure@googlegroups.com
Subject: Re: Calling Java from Clojure

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 
mailto:s...@corfield.org>> 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<mailto:clojure@googlegroups.com> 
mailto:clojure@googlegroups.com>> on behalf of Didier 
mailto:didi...@gmail.com>>
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<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com<mailto:clojure+unsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
clojure+unsubscr...@googlegroups.com<mailto: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<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com<mailto:clojure+unsubscr...@googlegroups.com>
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<mailto: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<https://groups.google.com/d/msgid/clojure/CY4PR2201MB11266042416A0BEFDBB233C6F4E70%40CY4PR2201MB1126.namprd22.prod.outlook.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/cloj

RE: Java Interop on steroids?

[Sean Corfield]

I got the impression this was the primary reason for Storm’s rewrite:

While Storm's Clojure implementation served it well for many years, it was 
often cited as a barrier for entry to new contributors. Storm's codebase is now 
more accessible to developers who don't want to learn Clojure in order to 
contribute.

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 Nathan 
Fisher 
Sent: Friday, June 21, 2019 4:17:43 PM
To: clojure@googlegroups.com
Subject: Re: Java Interop on steroids?

Storm recently moved away from Clojure in its core.

https://storm.apache.org/2019/05/30/storm200-released.html

I wonder how much of the legacy Clojure core could be optimised or if they 
reached an upper limit imposed by the runtime/architecture. That being said I 
suspect for 90% of orgs they'll never hit that boundary.

On Fri, Jun 21, 2019 at 16:40, Chris Nuernberger 
mailto:ch...@techascent.com>> wrote:
Sean,

That is an interesting blog post.  Sorry if I am not following everything but 
why not use the annotation support in gen-class for those types of things?

https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34

On Friday, June 21, 2019 at 1:29:56 PM UTC-6, Sean Corfield wrote:
You might be interested in how we provide type-based annotations on Clojure 
functions so that tooling (in our case New Relic) sees those annotations:

https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/

I agree that this could be a lot easier.

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: clo...@googlegroups.com  on behalf of eglue 

Sent: Thursday, June 20, 2019 9:03:45 PM
To: Clojure
Subject: Java Interop on steroids?

Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶ 
̶H̶i̶c̶k̶e̶y̶  guy.

However -- there are many popular Java frameworks that love to reflect on their 
annotations and their generic type signatures.

To name a heavyweight: Spring. But also, of late: big data frameworks, many 
written in Java, love reflecting on generic type signatures. My org is looking 
at Beam and Flink, for example.

These frameworks use types not for the static checking really but as parameters 
governing their own dynamic behavior. For example, Spring will use types at 
runtime to simply match objects to where they should be dynamically injected. 
Beam will look at your type signatures and do runtime validations to ensure it 
can process things appropriately. Of course this is unfortunate, using types 
this way, when it is all really just data. Clojure does -- or would do -- it 
better, simpler, directer, and all of that.

Yet we would like to leverage these frameworks. Or rather, we must for various 
pragmatic and business reasons.

And any time we need to "communicate" to these frameworks "through" their 
desired fashion of generic types and annotations, we can, of course, create the 
appropriate .java files to represent what is needed (and then do the invocation 
back to Clojure via IFn.invoke or Compiler.eval, etc). Yes, this works.

However this is quite tedious because in these frameworks I mentioned you end 
up having to create these Java files quite a bit. For example, when expressing 
a streaming data pipeline to Beam, you may specify multiple transforms, each a 
function with its own type signature.

A little searching and it seems Clojure has shied away from generating generic 
type information in places where it could offer this capability.

For example, in `proxy` ... or I suppose also in `gen-class`, `reify`, and 
other dynamic bytecode generation features of Clojure.

However it seems to me that `proxy` (and these others) could allow one to pass 
in a representation of desired type arguments, annotations, etc. and then we 
could remain in Clojure to interop with these popular frameworks.

I respect Clojure's efforts to keep its core small and wait for worthy features 
to prove themselves.

So my question is not when is Clojure going to do this, but rather:

Are there any precedents in the community for someone building out the kind of 
richer Java interop that I'm nodding toward here?

For example, does anyone know of an attempt out there to build a `proxy` 
plus-plus, that would allow one to extend a generic class with provided type 
parameters and have this metadata properly rendered in the bytecode that proxy 
produces?

If not, as a practical and hopefully quick and workable solution, I was 
thinking it'd be possible to take the bytecode emitted by proxy and re-run it 
through ASM to create a *new* class with simply the proxy-pr

RE: Java Interop on steroids?

[Sean Corfield]

Two reasons:

  1.  When I searched for ‘annotations in Clojure’ I pretty much came up empty 
– so I didn’t know you could do that sort of stuff with gen-class 
  2.  I was very focused on adding annotations to specific functions that I 
wanted New Relic to trace so I didn’t think much about class level stuff
  3.  We’ve since dropped the New Relic tracing stuff from our code (because we 
got the data we needed and moved on)

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 Chris 
Nuernberger 
Sent: Friday, June 21, 2019 12:40:28 PM
To: Clojure
Subject: Re: Java Interop on steroids?

Sean,

That is an interesting blog post.  Sorry if I am not following everything but 
why not use the annotation support in gen-class for those types of things?

https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34

On Friday, June 21, 2019 at 1:29:56 PM UTC-6, Sean Corfield wrote:
You might be interested in how we provide type-based annotations on Clojure 
functions so that tooling (in our case New Relic) sees those annotations:

https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/

I agree that this could be a lot easier.

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: clo...@googlegroups.com 
> on behalf of eglue 
>
Sent: Thursday, June 20, 2019 9:03:45 PM
To: Clojure
Subject: Java Interop on steroids?

Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶ 
̶H̶i̶c̶k̶e̶y̶  guy.

However -- there are many popular Java frameworks that love to reflect on their 
annotations and their generic type signatures.

To name a heavyweight: Spring. But also, of late: big data frameworks, many 
written in Java, love reflecting on generic type signatures. My org is looking 
at Beam and Flink, for example.

These frameworks use types not for the static checking really but as parameters 
governing their own dynamic behavior. For example, Spring will use types at 
runtime to simply match objects to where they should be dynamically injected. 
Beam will look at your type signatures and do runtime validations to ensure it 
can process things appropriately. Of course this is unfortunate, using types 
this way, when it is all really just data. Clojure does -- or would do -- it 
better, simpler, directer, and all of that.

Yet we would like to leverage these frameworks. Or rather, we must for various 
pragmatic and business reasons.

And any time we need to "communicate" to these frameworks "through" their 
desired fashion of generic types and annotations, we can, of course, create the 
appropriate .java files to represent what is needed (and then do the invocation 
back to Clojure via IFn.invoke or Compiler.eval, etc). Yes, this works.

However this is quite tedious because in these frameworks I mentioned you end 
up having to create these Java files quite a bit. For example, when expressing 
a streaming data pipeline to Beam, you may specify multiple transforms, each a 
function with its own type signature.

A little searching and it seems Clojure has shied away from generating generic 
type information in places where it could offer this capability.

For example, in `proxy` ... or I suppose also in `gen-class`, `reify`, and 
other dynamic bytecode generation features of Clojure.

However it seems to me that `proxy` (and these others) could allow one to pass 
in a representation of desired type arguments, annotations, etc. and then we 
could remain in Clojure to interop with these popular frameworks.

I respect Clojure's efforts to keep its core small and wait for worthy features 
to prove themselves.

So my question is not when is Clojure going to do this, but rather:

Are there any precedents in the community for someone building out the kind of 
richer Java interop that I'm nodding toward here?

For example, does anyone know of an attempt out there to build a `proxy` 
plus-plus, that would allow one to extend a generic class with provided type 
parameters and have this metadata properly rendered in the bytecode that proxy 
produces?

If not, as a practical and hopefully quick and workable solution, I was 
thinking it'd be possible to take the bytecode emitted by proxy and re-run it 
through ASM to create a *new* class with simply the proxy-produced class bytes 
filled-in with the desired, provided type parameters. I bet this could be 
sufficient and fast, with the slight overhead of the extra class.

To do this, I think I'd need access to these proxy-made bytes... either by 
having proxy answer them somehow, or offering a hook to contribute t

RE: Calling Java from Clojure

[Sean Corfield]

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 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/CY4PR2201MB11266042416A0BEFDBB233C6F4E70%40CY4PR2201MB1126.namprd22.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

RE: Java Interop on steroids?

[Sean Corfield]

You might be interested in how we provide type-based annotations on Clojure 
functions so that tooling (in our case New Relic) sees those annotations:

https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/

I agree that this could be a lot easier.

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 eglue 

Sent: Thursday, June 20, 2019 9:03:45 PM
To: Clojure
Subject: Java Interop on steroids?

Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶ 
̶H̶i̶c̶k̶e̶y̶  guy.

However -- there are many popular Java frameworks that love to reflect on their 
annotations and their generic type signatures.

To name a heavyweight: Spring. But also, of late: big data frameworks, many 
written in Java, love reflecting on generic type signatures. My org is looking 
at Beam and Flink, for example.

These frameworks use types not for the static checking really but as parameters 
governing their own dynamic behavior. For example, Spring will use types at 
runtime to simply match objects to where they should be dynamically injected. 
Beam will look at your type signatures and do runtime validations to ensure it 
can process things appropriately. Of course this is unfortunate, using types 
this way, when it is all really just data. Clojure does -- or would do -- it 
better, simpler, directer, and all of that.

Yet we would like to leverage these frameworks. Or rather, we must for various 
pragmatic and business reasons.

And any time we need to "communicate" to these frameworks "through" their 
desired fashion of generic types and annotations, we can, of course, create the 
appropriate .java files to represent what is needed (and then do the invocation 
back to Clojure via IFn.invoke or Compiler.eval, etc). Yes, this works.

However this is quite tedious because in these frameworks I mentioned you end 
up having to create these Java files quite a bit. For example, when expressing 
a streaming data pipeline to Beam, you may specify multiple transforms, each a 
function with its own type signature.

A little searching and it seems Clojure has shied away from generating generic 
type information in places where it could offer this capability.

For example, in `proxy` ... or I suppose also in `gen-class`, `reify`, and 
other dynamic bytecode generation features of Clojure.

However it seems to me that `proxy` (and these others) could allow one to pass 
in a representation of desired type arguments, annotations, etc. and then we 
could remain in Clojure to interop with these popular frameworks.

I respect Clojure's efforts to keep its core small and wait for worthy features 
to prove themselves.

So my question is not when is Clojure going to do this, but rather:

Are there any precedents in the community for someone building out the kind of 
richer Java interop that I'm nodding toward here?

For example, does anyone know of an attempt out there to build a `proxy` 
plus-plus, that would allow one to extend a generic class with provided type 
parameters and have this metadata properly rendered in the bytecode that proxy 
produces?

If not, as a practical and hopefully quick and workable solution, I was 
thinking it'd be possible to take the bytecode emitted by proxy and re-run it 
through ASM to create a *new* class with simply the proxy-produced class bytes 
filled-in with the desired, provided type parameters. I bet this could be 
sufficient and fast, with the slight overhead of the extra class.

To do this, I think I'd need access to these proxy-made bytes... either by 
having proxy answer them somehow, or offering a hook to contribute to the 
defined bytecode before it is committed to the classloader, or by having 
DynamicClassLoader have these bytes on hand for inquiring parties, or something 
else along these lines. This would likely be something that Clojure core would 
have to expose .. correct me if I'm wrong.

Would love to hear any other immediate thoughts on this.

I think once you realize that this generic type information is not even being 
used for "static typing" by these frameworks but rather as an (albeit poor) 
means to receive semantic information from their clients (as parameters to 
govern their own dynamic behavior), then the need/value of being able to remain 
in Clojure and communicate to these libraries through generic params and 
annotations perhaps becomes more understandable..










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

[ANN] org.clojure/core.memoize 0.7.2

[Sean Corfield]

A manipulable, pluggable, memoization framework for Clojure

This release fixes a small bug in how memo-swap! and 0-arity functions 
interact, as well as expanding the local Clojure version testing to match 
what’s on Jenkins, and picking up org.clojure/core.cache 0.7.2 (from 0.7.1, for 
a small bug fix).

https://github.com/clojure/core.memoize#change-log

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

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

RE: [ANN] seancorfield/next.jdbc 1.0.0

[Sean Corfield]

From: Oleksandr Shulgin

> After a month of alpha builds being available for testing, the first beta 
> build was released on June 24th, 2019.

/me looks at his pocket clock distrustfully ;)

Good catch! A PR to fix that has already been merged 
https://github.com/seancorfield/next-jdbc/pull/32

That’s what happens when your brain is thinking “the Release Candidate came out 
in June” and your fingers are trying to type “the first beta build was released 
on May 24th, 2019.” 

Love the datafy/nav support out of the box, but a bit confused by the function 
name "plan" (especially together with prepared statements).  Do you happen to 
have any piece of discussion that lead to this choice of name?

https://github.com/seancorfield/next-jdbc/issues/16

Bottom line: execute! and execute-one! indicate something happening right away 
(and potentially side-effecting) but reducible! (the previous name for plan) 
was misleading because a) what’s a reducible in SQL/JDBC context and b) it 
doesn’t actual perform an operation – not until you reduce/transduce it. So it 
was definitely a poor name. clojure.java.jdbc’s reducible-query is the 
forerunner for next.jdbc’s plan but the former only let you run SELECT queries 
whereas the latter lets you run any SQL (but, sure, most uses will still be 
SELECT queries) so that name wouldn’t have been right either. Plan was the best 
suggestion, in my opinion, because it indicates you are _planning_ to execute 
SQL, it creates a “plan of execution” in terms of producing a reducible object, 
and it’s a little nod to “execution plan” in SQL anyway so it’s a bit punny. 
Naming is hard 

Sean

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

[ANN] seancorfield/next.jdbc 1.0.0

[Sean Corfield]

The first “gold” release of the next generation of clojure.java.jdbc – a new 
low-level Clojure wrapper for JDBC-based access to databases!

https://github.com/seancorfield/next-jdbc

Compared to the release candidate, this contains just a couple of usability 
additions. The API has been stable since Beta 1 and only accretive/fixative 
changes will be made. Read more about the release: 
https://clojureverse.org/t/next-jdbc-1-0-0-the-gold-release/4379

Official documentation on the excellent cljdoc.org: 
https://cljdoc.org/d/seancorfield/next.jdbc

A longer blog post about the library’s journey to 1.0.0 will come at some 
point. We are using next.jdbc in production at World Singles Networks (of 
course!) so I hope you will feel comfortable doing the same!

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

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

Re: [ANN] Clojure 1.10.1

[Sean Corfield]

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.
>
> 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.
>
> 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 
>  for 
> configuration details.
> Changelog
>
> See the change log 
> 
>  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 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/01fe6d24-ae4a-409e-989e-987760b389a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: congomongo 0.5.2 comptable with MongoDB 3.6 version

[Sean Corfield]

The first thing I would suggest you try is updating to the latest version of 
CongoMongo – 1.1.0. Prior to 1.0.0, CongoMongo was not tested against the 3.x 
series of drivers nor the 3.x versions of the database itself, as far as I can 
remember.

See https://github.com/congomongo/congomongo/releases

In particular, note the potential breaking changes around authentication that 
happened in the 1.0.0 release due to upgrading to the 3.x series of the driver.

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 
Bharathiraja Narayanan 
Sent: Wednesday, June 5, 2019 4:17:41 AM
To: Clojure
Subject: congomongo 0.5.2 comptable with MongoDB 3.6 version

Hi Team,

We are getting below exception message when clojure application is hitting the 
mongodb (3.6 version ).
We are using congomongo library (version: 0.5.2 ) in clojure application for 
mongodb operation.

This exception occuring intermittenly, not regulary. Also, this exception is 
not occuring with mongodb (2.6 version).

Kindly let me know, if any way to resolve this.

Exception Message: message Read operation to server localhost:27017 failed on 
database.


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
clojure+unsubscr...@googlegroups.com<mailto:clojure+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/992da016-5e81-47ab-a060-cc4850e36830%40googlegroups.com<https://groups.google.com/d/msgid/clojure/992da016-5e81-47ab-a060-cc4850e36830%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/CY4PR2201MB1126E04776A8B0C79253DED0F4160%40CY4PR2201MB1126.namprd22.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] seancorfield/next.jdbc "1.0.0-beta1" (stable)

[Sean Corfield]

next.jdbc 1.0.0 Beta 1 -- the "next generation" of clojure.java.jdbc: a modern 
low-level JDBC wrapper for Clojure

http://corfield.org/blog/2019/05/25/next-jdbc/ for the announcement.

https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-beta1/doc/getting-started to 
get started using it.

Only accretive and fixative changes will be made from this point on.

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

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

RE: results from sort-by are not sorted

[Sean Corfield]

Good catch, thank you! And that was my _second_ edit (my first draft was also 
wrong in a different way). Lesson: just try this stuff in the REPL to see what 
_really_ happens! 

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 Justin 
Smith 
Sent: Monday, May 6, 2019 1:53:48 PM
To: Clojure
Subject: Re: results from sort-by are not sorted

minor nitpick to the answer Sean provided: #{:age} as a function returns :age 
for an argument equal to :age and nil for all other inputs, including a hash 
map containing that key.

On Sun, May 5, 2019, 22:22 
mailto:sheng.peisi@gmail.com>> wrote:
Thanks. What a newbie question.

在 2019年5月6日星期一 UTC+8上午11:34:36，se...@corfield.org<mailto:se...@corfield.org>写道：
(sort-by #{:age} …) will use the set #{:age} as the keyfn, and both (#{:age} 
{:age 3, :name “luo”}) and (#{:age} {:age 1, :name “sheng”}) both return :age – 
because both maps contain the key in the set. As far as sort-by is concerned, 
both hash maps compare equal.

What you want is (sort-by :age …) so you the keyfn pulls the value 
corresponding to :age out of the hash maps. That will produce 3 from {:age 3, 
:name “luo”} and 1 from {:age 1, :name “sheng”} so they will sort appropriately.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

From: sheng@gmail.com
Sent: Sunday, May 5, 2019 7:48 PM
To: Clojure
Subject: results from sort-by are not sorted

Hey there,

in my lein repl,

(sort-by #{:age} [{:age 3,:name "luo"},{:age 1,:name "sheng"}])

returns

({:age 3, :name "luo"} {:age 1, :name "sheng"})

rather than

({:age 1, :name "sheng"}, {:age 3, :name "luo"}).

Why?
--
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.
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<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com<mailto:clojure%2bunsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
clojure+unsubscr...@googlegroups.com<mailto: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<mailto: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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CY4PR2201MB11266635C48A625AD749EB33F4310%40CY4PR2201MB1126.namprd22.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] seancorfield/next.jdbc 1.0.0-alpha8

[Sean Corfield]

I've talked about this in a few groups -- it's been a long time coming.
This is the "next generation" of clojure.java.jdbc -- a modern wrapper for
JDBC, that focuses on reduce/transducers, qualified-keywords, and
datafy/nav support (so, yes, it requires Clojure 1.10).

https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-alpha8/doc/readme

The next generation of clojure.java.jdbc: a new low-level Clojure wrapper
for JDBC-based access to databases.  It's intended to be both faster and
simpler than clojure.java.jdbc and it's where I intend to focus my future
energy, although I have not yet decided whether it will ultimately be a new
set of namespaces in the Contrib lib or a separate, standalone OSS library!

At this point, I'm looking for feedback on the API and the approach (as
well as bugs, performance issues, etc). Please take it for a spin and let
me know what you think (here, on Slack, on Zulip, or via Issues on GitHub).

The group/artifact ID will change at some point: and the actual namespaces
will too, but I will try to make that as painless as possible when I take
this out of the alpha phase.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles Networks, LLC. -- http://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

RE: next.jdbc -- early access

[Sean Corfield]

I maintain four Contrib libraries: core.cache, core.memoize, java.jdbc, and 
tools.cli – most of the libraries are complete and stable. You can see the full 
list here:

https://clojure.org/community/contrib_libs

Only about half a dozen are considered inactive at this point.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Pankaj 
Doharey 
Sent: Sunday, March 31, 2019 11:58:05 PM
To: clojure@googlegroups.com
Subject: Re: next.jdbc -- early access

WoW, good to hear about pure Clojure libs being written, Is contrib still alive?
On Mon, 1 Apr 2019 at 12:09 PM, Sean Corfield 
mailto:s...@corfield.org>> wrote:
OK, I'm finally at a place where I feel comfortable showing an early working 
draft of `next.jdbc` to the world: 
https://github.com/seancorfield/next-jdbc/blob/master/src/next/jdbc.clj -- 
although it is *not* API-compatible with `clojure.java.jdbc`, it is almost at 
feature parity at this point.

Feedback here, or via issues, or via DM is all fine. The code is substantially 
shorter and simpler than `clojure.java.jdbc` and the performance is 
substantially better.

_I have not yet decided whether this will live in Contrib or not, at this point 
so feedback on that is also useful!_

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


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

next.jdbc -- early access

[Sean Corfield]

OK, I'm finally at a place where I feel comfortable showing an early working 
draft of `next.jdbc` to the world: 
https://github.com/seancorfield/next-jdbc/blob/master/src/next/jdbc.clj -- 
although it is *not* API-compatible with `clojure.java.jdbc`, it is almost at 
feature parity at this point.

Feedback here, or via issues, or via DM is all fine. The code is substantially 
shorter and simpler than `clojure.java.jdbc` and the performance is 
substantially better.

_I have not yet decided whether this will live in Contrib or not, at this point 
so feedback on that is also useful!_

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

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

[Sean Corfield]

Everything seems to be running fine on 1.10.1-beta1 here at World Singles 
Networks. We were not experiencing the user.clj loading problem so I can't 
speak to how it addresses that, nor are we looking at Java 12 yet :) 

The only piece of feedback I'll offer here -- and Alex already knows 
because I raised it on Zulip but want a broader audience as a sanity check:

The new clojure.main error handling definitely works well but on macOS the 
temporary folder path -- where the EDN report of the stack trace etc gets 
written -- is very long so the "Full report at:" line wraps, making it a 
bit fiddle to copy'n'paste the file path. It would be easier if the file 
path was on a separate line, by adding a newline after "at:", so selection 
of the file path is easier.

That might also make it easier for tooling that invokes Clojure apps via 
the command-line (instead of having to parse the file path out of a line 
that has other text in it).

On Thursday, March 21, 2019 at 9:35:32 PM UTC-7, Alex Miller wrote:
>
> 1.10.1-beta1 is now available. You can try it with clj using:
>   clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version 
> "1.10.1-beta1"}}}'
>
> 1.10.1-beta1 includes the following changes since 1.10.0:
>
>- CLJ-2484  - Fix Java 
>performance regression loading user.clj
>- CLJ-2463  - 
>clojure.main uncaught exception handling
>- CLJ-2491  - Fix 
>fragile tests that fail under Java 12
>
> The issue in CLJ-2484 was introduced in Java itself, specifically Java 1.8 
> u202, Java 11.0.2, and Java 12. It primarily affects loading of user.clj 
> and can cause a significant load time difference for anything done in 
> user.clj. CLJ-2463 affects how errors are reported from clojure.main. This 
> includes many Clojure uses under tools like Leiningen, such as compile, 
> test,  etc.  
>
> We would greatly appreciate feedback if you could check out this release 
> in your own project and give it a try!! 
>

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

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

[Sean Corfield]

I’ve been working with WSL (and Ubuntu) so that I can run all our backend stuff 
– and `clj`/`deps.edn` -- but the problem is that if your editor is on Windows 
and your nREPL or Socket REPL is on Linux, they will disagree on file paths. As 
far as I know Chlorine (for Atom) is the only Clojure editor setup on Windows 
that will work properly with WSL because it understands the file path 
differences and maps :\path\to\file.clj to /mnt//path/to/file.clj

But it is a pain that you can’t run REBL on WSL and I rely on REBL for my 
workflow on macOS these days, so I was glad of the alpha PowerShell version of 
`clj` so that I can run REBL via my normal `clj`-based workflow _on Windows_ 
now, and then connect Atom/Chlorine to that (via a Socket REPL).

So now I can run all the backend stuff, test suites, scripts etc etc on WSL, 
but I can also run a REPL on Windows now the same way (but with REBL!), and 
develop on Windows – the same way I did on macOS.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

From: Matching Socks
Sent: Saturday, March 16, 2019 4:27 AM
To: Clojure
Subject: Re: Developing Closure in 2019 on Windows 10 or using Windows 
-WSL/Linux.

Overall, WSL might not help much here.  Last I heard, WSL did not include an X 
Window server to accommodate any GUI.  Therefore, I suppose Intellij IDEA would 
be most useful as a native Windows app.  In addition, Java and Leiningen work 
natively in Windows.  I am glad you got Leiningen in gear, that's definitely 
the way 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.
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: Noob: Getting (re)started with Clojure on OS X

[Sean Corfield]

With modern versions of CIDER, those dependencies are injected automatically 
(and with the correct version).

I would advise keeping as little as possible in your profiles.clj file – it’s 
possibly the number one cause of problems for Leiningen users because people 
forget they have some plugin or dependency in there and months later it 
conflicts with some new project they’re working on in weird ways.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Kenneth 
Beesley 
Sent: Wednesday, March 13, 2019 10:54:19 AM
To: clojure@googlegroups.com
Subject: Re: Noob: Getting (re)started with Clojure on OS X



On 13Mar2019, at 10:19, Sean Corfield 
mailto:s...@corfield.org>> wrote:

Check what’s in your ~/.lein/profiles.clj file – that’s usually the cause of 
bizarre errors that people report with Leiningen.

Hello Sean,

Hah!  I changed my ~/.lein/profiles.clj from

{:user {:plugins [[cider/cider-nrepl "0.8.2"]]}}

to

{:user {:plugins [[lein-pprint "1.1.1"]]
:dependencies [[slamhound "1.3.1"]]}}

and now ‘lein repl’ launches.

Anything else I should add to ~/.lein/profiles.clj ?

Many thanks!

Ken

***
Kenneth R. Beesley, D.Phil.
PO Box 540475
North Salt Lake UT 84054
USA







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

[Sean Corfield]

Check what’s in your ~/.lein/profiles.clj file – that’s usually the cause of 
bizarre errors that people report with Leiningen.

Also check your environment variables: env|fgrep CLASSPATH

Per the warning, you probably want to remove whatever is setting that (from one 
of your shell’s dot files, perhaps?).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Kenneth 
Reid Beesley 
Sent: Wednesday, March 13, 2019 9:47:24 AM
To: Clojure
Subject: Noob: Getting (re)started with Clojure on OS X

I played happily with Clojure/leiningen several years ago, on OS X, but I'm 
having trouble getting restarted.

I have
macOS High Sierra Version 10.13.6
java version 1.8.0_05

and I just did

$ brew upgrade leiningen
(it confirms that I have leiningen 2.9.1 already installed)

and
$ brew install clojure
(I now have stable 1.10.0.414)

But then I try

$ lein repl

and get


WARNING: You have $CLASSPATH set, probably by accident.

It is strongly recommended to unset this before proceeding.

clojure.lang.Compiler$CompilerException: Syntax error compiling at 
(cider/nrepl.clj:1:1).

#:clojure.error{:phase :compile-syntax-check, :line 1, :column 1, :source 
"cider/nrepl.clj"}

 at clojure.lang.Compiler.load (Compiler.java:7647)

...


and


Caused by: java.io.FileNotFoundException: Could not locate 
clojure/tools/nrepl/server__init.class, clojure/tools/nrepl/server.clj or 
clojure/tools/nrepl/server.cljc on classpath.

 at clojure.lang.RT.load (RT.java:466)

...





So, where am I going wrong?  How do I get back in the Clojure saddle on OS X?


Ken Beesley

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

[Sean Corfield]

> Such a beautiful language with so few tutorials, Elixir and other newer 
> languages have so much video tutorials for the newcomers...I really don't 
> understand.

Historically, Clojure’s main attraction has been for seasoned developers so 
there hasn’t been much need or incentive to create tutorials aimed at 
newcomers, especially folks who aren’t already professional software 
developers, and especially the sort of video tutorials you are referring to 
(which seem like a fairly new-ish phenomenon to me, regardless of language).

I think that may change as Clojure gains more popularity and more reach. Maybe. 
But it’s always going to be a fairly niche language.

In addition to Eric’s purelyfunctional.tv, Jacek’s Reagent, and a few others 
already mentioned, see if anything here helps: 
http://www.learn-clojure.com/clojure_videos.html (mostly presentations from 
conferences and user groups but also some links to tutorials/courses).

Also check out Timothy Baldridge’s Clojure videos: 
https://tbaldridge.pivotshare.com/home

Regarding Windows, yes, it’s always been a second-class citizen for Clojure 
development because all the early adopters were Mac/Linux users. Windows 
versions of Leiningen and Boot took a while to appear. A Windows version of the 
new CLI/`deps.edn` tooling is in alpha testing right now.

Make sure you sign up for the Clojurians Slack (sign up http://clojurians.net/ 
) and/or the Clojurians Zulip https://clojurians.zulipchat.com – both of these 
have active communities who will be happy to help beginners getting up to 
speed. Slack is by far the larger community but Zulip has a fully searchable 
archive (which Slack lacks on the free plans – and most of the channels from 
Slack are mirrored to Zulip now).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Eric 
Calonico 
Sent: Saturday, March 9, 2019 3:07:56 PM
To: Clojure
Subject: Re: Closure lang for newbies in 2019

Hi Marcin, I gree 110% with you!!!

I am having the same problems and I agree 100% with you!! What's more, I am on 
Windows...lol

It's just too much work right now, not enough free tutorials and I am not a 
professional programmer.

I'd rather learn by video tutorials that's a weakness of mine...sorry.

Such a beautiful language with so few tutorials, Elixir and other newer 
languages have so much video tutorials for the newcomers...I really don't 
understand.

Even on the big platforms, Udemy, Pluralsight, Lynda, hard to find tutorials...

Thanks.



Em sábado, 9 de março de 2019 19:49:48 UTC-3, Marcin Piczkowski escreveu:
Hi,
I've also started learning clojure a few months ago. I will tell you my story.

The most painful at the beginning was to find the right environment setup, in 
particular the IDE. Many Clojure professionals advice to use Emacs but I could 
not get up to speed with it so I dropped it. I come from Java land where I got 
used to Intellij Idea so after a few fails of trying Emacs, Atom, LightTable 
etc, I decided not to loose more time on playing with IDEs and stick to the 
known Idea with Cursive plugin and concentrate on learning the language itself.

I started reading the mentioned "Clojure for the Brave and True" (which by the 
way also proposes to use Emacs) and it is a great book, but personally I like 
more to follow video tutorials. Recently I found this one

https://www.youtube.com/playlist?list=PLXsXu5srjNlxI7b2smnHxDeMMwR4mVZ2m

and I liked it a lot. It's very concise and gives a good intro to Clojure.

The next which I heard is quite good is a book titled  "Living Clojure" but I 
have not read it yet.

Instead, I went straight into ClojureScript because building sth visual is more 
motivating for me. I was also catched by it's advantages over Reactjs.
Then again I got lost with an amount of different approaches to build websites 
(with Reagent, Ohm, Figwheel, using leiningen or just .edn project setup)

I found this free course about Reagent which was helpful for me helpful 
https://www.jacekschae.com/learn-reagent-free

Then I looked for some examples of project setup with leiningen and figwheel 
because it looks to me like this is a more productive way (or tell me if I'm 
wronged and there is sth better and more commonly used in prod apps?) and I 
found a nice Tetris game, which I'm analyzing at the moment - 
http://timothypratley.blogspot.com/2015/07/you-should-be-using-figwheelreagent.html?m=1

The next in more distant future on my list is to look at the real production 
web app built with ClojureScript - Circle CI, you can watch this video about it:
https://youtu.be/LNtQPSUi1iQ

Getting into the Clojure world is the most painful road from any roads to new 
programming language I had in the past but the elegance of the language and 
it's 

[ANN] org.clojure/java.jdbc 0.7.9

[Sean Corfield]

The Contrib wrapper for JDBC has a minor update:

It contains a couple of tweaks around insert-multi! and highly experimental 
datafy/nav functionality (for Clojure 1.10). See 
https://github.com/clojure/java.jdbc/blob/master/CHANGES.md for more details.

I wrote about the datafy/nav work here 
http://corfield.org/blog/2018/12/03/datafy-nav/ while I was at Clojure/conj.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

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

[Sean Corfield]

Is there a way to programmatically create a spec from data?

There will be in Spec2 (which is a work-in-progress – see Alex’s Inside Clojure 
Journal posts for the state of that work).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Sonny To 

Sent: Tuesday, February 19, 2019 4:18:20 AM
To: Clojure
Subject: dynamically defining specs

(let [n :foo/bar
f int?]
(s/def n f)
)

(s/get-spec :foo/bar)

why does this return nil?

it seems I can only define a spec like this

(s/def :foo/bar int?)

Is there a way to programmatically create a spec from data?

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

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

Re: [ANN] tools.deps.alpha 0.6.488 and clj 1.10.0.414

[Sean Corfield]

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.

RE: r/fold combinef and reducef init values

[Sean Corfield]

Ah, yes… So this line…

The reducef function will be called with no arguments to produce an identity 
value in each partition.

…needs updating/removing.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Brian 
Craft 
Sent: Saturday, January 26, 2019 2:02:42 PM
To: Clojure
Subject: Re: r/fold combinef and reducef init values

hey Sean -- The ones on the reducers reference page:

https://clojure.org/reference/reducers

On Friday, January 25, 2019 at 4:05:12 PM UTC-8, Sean Corfield wrote:
Which docs are you reading? The docstring for r/fold says this – with no 
indication of calling (reducef) with no arguments (well, unless you do not 
supply combinef – in which case reducef will be used for that, so (reducef) 
would be called to seed the reductions):

"Reduces a collection using a (potentially parallel) reduce-combine
  strategy. The collection is partitioned into groups of approximately
  n (default 512), each of which is reduced with reducef (with a seed
  value obtained by calling (combinef) with no arguments). The results
  of these reductions are then reduced with combinef (default
  reducef). combinef must be associative, and, when called with no
  arguments, (combinef) must produce its identity element. These
  operations may be performed in parallel, but the results will
  preserve order."

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

From: Brian Craft
Sent: Friday, January 25, 2019 3:36 PM
Subject: r/fold combinef and reducef init values

>From the docs:

r/fold takes a reducible collection and partitions it into groups of 
approximately n (default 512) elements. Each group is reduced using the reducef 
function. The reducef function will be called with no arguments to produce an 
identity value in each partition. The results of those reductions are then 
reduced with the combinef (defaults to reducef) function. When called with no 
arguments, (combinef) must produce its identity element - this will be called 
multiple times. Operations may be performed in parallel. Results will preserve 
order.

So, this seems to say r/fold will partition the collection and reduce each 
partition using the (reducef) as the init value.

Then, all these intermediate results will be reduced with combinef, using 
(combinef) as the init value.

However, in test it seems (reducef) is never called, and (combinef) is used as 
the init value for calls to reducef.

  (defn combinef
([] {:combine :f})
([acc v] acc))

  (defn reducef
([] {:reduce :f})
([acc v]
 (println "acc" acc "v" v)
 v))

  (clojure.core.reducers/fold combinef reducef ["foo" "bar"])

; outputs:
acc {:combine :f} v foo
acc foo v bar
"bar"

The accumulator in reducef is the init value from combinef, not the init value 
from reducef.

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


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

RE: Noob question on the --> macro implementation

[Sean Corfield]

I suspect it’s done for consistency with the source of -> (which has to use 
first/next because it threads the expression between them) – using first/next/x 
in ->> is therefore a closer parallel to using first/x/next in -> so it’s 
easier to see the similarity (and correctness) of the code.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of James 
Reeves 
Sent: Saturday, January 26, 2019 11:08:25 AM
To: clojure@googlegroups.com
Subject: Re: Noob question on the --> macro implementation

I believe he's just saying it's simpler and possibly more efficient.

Unless I'm missing something subtle in the way this is resolved, I believe 
Ujjwal is right that:

`(~(first form) ~@(next form) ~x)

Is equivalent to:

`(~@form ~x)

On Sat, 26 Jan 2019 at 19:04, Andy Fingerhut 
mailto:andy.finger...@gmail.com>> wrote:
When you ask "am I right?" about your proposed change, what is it that the 
current behavior does not do, that your change would do?  Do you have some use 
case in mind that works with your change, but doesn't with the current 
implementation?

Andy

On Sat, Jan 26, 2019 at 10:50 AM Ujjwal Thaakar 
mailto:ujjwalthaa...@gmail.com>> wrote:
Hi,
I'm trying to learn Clojure and I just curiously typed
(source ->>)
 in the REPL and was wondering about this: 
https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784

Am I missing something?

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


--
James Reeves
booleanknot.com<http://booleanknot.com>

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

[Sean Corfield]

2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9

My approach is to isolate the pieces that need to be AOT compiled to as few 
namespaces as possible and have them only depend on other namespaces at 
runtime, i.e., avoid :require in the ns clause where possible and use 
require/resolve in the AOT-compiled functions to get at the larger body of 
Clojure code. And, of course, to try to avoid gen-class as much as possible too 


The transitive AOT compilation thing is a giant pain but there are ways around 
it with tooling.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Didier 

Sent: Friday, January 25, 2019 10:11:45 PM
To: Clojure
Subject: Re: Issue when moving to Clojure 1.10

So I got to the bottom bottom of the problem here.

This is a scenario:

1) Library A depends on library B and Clojure 1.10
2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
3) Library A does not work, because it is now using the Clojure core spec 1.9 
compiled transitively through the Library B AOT, and found in its Jar, since 
.class get precedence over source files.

So, this means that a library with a dependency on another one that is AOT can 
cause spec conflicts.

This is new now that spec is out. And so I first caught this when some of our 
libs were using 1.9, and I started moving others to 1.10.

The way I solved this is by hacking our build, so that the clojure compiled 
classes from the AOT don't get included in the Jar after they are compiled.

In my opinion, this is a bit of a problem. What would be nice is either to have 
a way to compile only a gen-class, and not the namespace that contains it. Or 
not compile things transitively. Or maybe just a way for compile to exclude 
clojure core namespaces.

Now, if you depend on libraries that don't need AOT, it is not an issue. But if 
you do, it forces you to re-compile all your dependencies and do a full big 
bang upgrade to the new Clojure version. You can't just use libs compiled with 
older versions of spec. While before, you were able to use libs compiled with 
older version of Clojure from packages that use newer version of Clojure.

On Wednesday, 16 January 2019 20:47:43 UTC-8, Mark Derricutt wrote:

On 16 Jan 2019, at 18:17, Alex Miller wrote:

Yes, it's one of the downsides of AOT.

I'd say it's not so much a downside of AOT - but of having a single output path 
for classes. I've long wanted Chas's patch to be applied, or something like it.

Having everyone reinvent the mechanism whenever they happen to need AOT is kind 
of annoying - rare, but still annoying.



"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time." — Mark 
Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

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

[Sean Corfield]

Which docs are you reading? The docstring for r/fold says this – with no 
indication of calling (reducef) with no arguments (well, unless you do not 
supply combinef – in which case reducef will be used for that, so (reducef) 
would be called to seed the reductions):

"Reduces a collection using a (potentially parallel) reduce-combine
  strategy. The collection is partitioned into groups of approximately
  n (default 512), each of which is reduced with reducef (with a seed
  value obtained by calling (combinef) with no arguments). The results
  of these reductions are then reduced with combinef (default
  reducef). combinef must be associative, and, when called with no
  arguments, (combinef) must produce its identity element. These
  operations may be performed in parallel, but the results will
  preserve order."

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

From: Brian Craft<mailto:craft.br...@gmail.com>
Sent: Friday, January 25, 2019 3:36 PM
Subject: r/fold combinef and reducef init values

>From the docs:

r/fold takes a reducible collection and partitions it into groups of 
approximately n (default 512) elements. Each group is reduced using the reducef 
function. The reducef function will be called with no arguments to produce an 
identity value in each partition. The results of those reductions are then 
reduced with the combinef (defaults to reducef) function. When called with no 
arguments, (combinef) must produce its identity element - this will be called 
multiple times. Operations may be performed in parallel. Results will preserve 
order.

So, this seems to say r/fold will partition the collection and reduce each 
partition using the (reducef) as the init value.

Then, all these intermediate results will be reduced with combinef, using 
(combinef) as the init value.

However, in test it seems (reducef) is never called, and (combinef) is used as 
the init value for calls to reducef.

  (defn combinef
([] {:combine :f})
([acc v] acc))

  (defn reducef
([] {:reduce :f})
([acc v]
 (println "acc" acc "v" v)
 v))

  (clojure.core.reducers/fold combinef reducef ["foo" "bar"])

; outputs:
acc {:combine :f} v foo
acc foo v bar
"bar"

The accumulator in reducef is the init value from combinef, not the init value 
from reducef.

What's going 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<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

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

Re: [ANN] tools.deps.alpha 0.6.480 and clj 1.10.0.411 are now available.

[Sean Corfield]

...and nor did this.

On Friday, January 4, 2019 at 12:21:55 PM UTC-8, Alex Miller wrote:
>
> Just a small additional bug fix over the release a couple days ago related 
> to classifiers.
>
> Changes:
>
>- TDEPS-112  
>- Exclusions don't exclude transitive classifier libs
>
> 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: [ANN] tools.deps.alpha 0.6.474 and clj 1.10.0.408

[Sean Corfield]

This didn't come through in email...

On Wednesday, January 2, 2019 at 1:30:01 PM UTC-8, Alex Miller wrote:
>
> tools.deps.alpha 0.6.474 and clj 1.10.0.408 are now available. 
>
> Changes:
>
> * TDEPS-79 , TDEPS-109 
>  Fix infinite loop in 
> resolving recursive deps tree (will often improve resolution perf in other 
> cases as well)
> * TDEPS-50 , TDEPS-109 
>  Fix handling of Maven 
> classifiers during resolution
>   To explicitly specify a Maven classifier in a dep, specify it in the lib 
> name as follows:  groupId/artifactId$classifier
>   Note: the :classifier attribute in Maven dep coordinates is no longer 
> supported and will now produce an error.
> * TDEPS-107  Canonicalize 
> exclusion groupIds in pom gen
> * TDEPS-82   Ensure 
> -Sdescribe doesn't trigger resolution
> * Error handling improvements when Maven artifact is not found
> * Error handling improvements for invalid syntax in deps.edn
>
> 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: State of Clojure 2019 Survey!

[Sean Corfield]

I'm only seeing this in the web version of Google Groups. This did not get 
delivered via email -- so I'm replying to ensure more people see it.

Alex, pretty much none of your posts to the group seem to come through in 
email, although your _replies_ do (as do other people's replies to your 
posts).

On Monday, January 7, 2019 at 7:32:42 AM UTC-8, Alex Miller wrote:
>
> It’s time for the annual State of Clojure Community Survey!
>
> If you are a user of Clojure or ClojureScript, we are greatly interested 
> in your responses to the following survey:
>
>- 
>
>State of Clojure 2019 
>
> The survey contains four pages:
>
>1. 
>
>General questions applicable to any user of Clojure or ClojureScript
>2. 
>
>Questions specific to JVM Clojure (skip if not applicable)
>3. 
>
>Questions specific to ClojureScript (skip if not applicable)
>4. 
>
>Final comments
>
> The survey will close January 22nd, after which all of the data will be 
> released with some analysis. We greatly appreciate your input!
>

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

[Sean Corfield]

Did you change your ~/.lein/profiles.clj file? That’s the most common cause of 
mysterious startup failures with Leiningen it seems. Try removing/renaming that 
file and see if your problems go away.

If you have more of the stacktrace to share (via pastebin or a gist etc), that 
might help folks offer suggestions.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of 
lawrence.krub...@gmail.com 
Sent: Monday, December 24, 2018 8:39:11 AM
To: Clojure
Subject: Exception: clojure.lang.ExceptionInfo thrown from the 
UncaughtExceptionHandler in thread "main"

I'm not sure what I did, but suddenly I'm getting this:

Exception: clojure.lang.ExceptionInfo thrown from the UncaughtExceptionHandler 
in thread "main"

Exception: clojure.lang.ExceptionInfo thrown from the UncaughtExceptionHandler 
in thread "Thread-0"

I had been using println to do some debugging, but then I added :

 [com.taoensso/timbre "4.10.0"]

I think that is the last think I did. Then I did:

lein uberjar

And then I tried to run that from the command line.

I've added a bunch of logging to try to get a stacktrace, but none of this is 
working so far:

(defn -main [& args]

  (slingshot/try+

   ;; 2017-10-04 -- see this:
   ;; 
https://stackoverflow.com/questions/28908835/ssl-peer-shut-down-incorrectly-in-java
   (System/setProperty "https.protocols" "TLSv1.1")

   (.addShutdownHook (Runtime/getRuntime)
 (Thread.
  #(do (error "addShutdownHook triggered. This app is 
shutting down.")
   (stop

   ;; 2017-07-12 -- stealing code from here:
   ;; https://stuartsierra.com/2015/05/27/clojure-uncaught-exceptions
   ;; Assuming require [clojure.tools.logging :as log]
   (Thread/setDefaultUncaughtExceptionHandler
(reify Thread$UncaughtExceptionHandler
  (uncaughtException [_ thread ex]
(log "the app has died ")
(log ex)
(log "Uncaught background exception on thread " (.getName thread) " 
Caught by Thread/setDefaultUncaughtExceptionHandler in core/main.")
(System/exit 1

   (slingshot/try+
(start)
(catch Exception e
  (stack/parse-exception e)
  (log (str e))
  (log "the app has died!")
  (System/exit 1))
(catch Throwable t
  (log t)
  (log "the app has died!")
  (System/exit 1))
(catch Object o
  (log o)
  (log "the app has died!")
  (System/exit 1)


And yet all I get is:

Exception: clojure.lang.ExceptionInfo thrown from the UncaughtExceptionHandler 
in thread "main"

Exception: clojure.lang.ExceptionInfo thrown from the UncaughtExceptionHandler 
in thread "Thread-0"

Somehow the other lines that I try to print never get called. Nor my call to my 
log function which should give me a stacktrace.

What is the obvious thing to do here?







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

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

RE: [ANN] Clojure 1.10 has been released!

[Sean Corfield]

I'm not touching it until Sean Corfield has it running in production ;)

We have a mix of RC3 and RC4 in production right now. Clojure 1.10 “gold” is 
already on QA so it’ll go to production in the next few days 

And, yeah, this was the first release of Clojure itself that I got a patch 
into… and it was just a backport of a patch from the ASM Java code, so it 
wasn’t really even my contribution!

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of 
peterhul...@gmail.com 
Sent: Monday, December 17, 2018 12:55:24 PM
To: Clojure
Subject: Re: [ANN] Clojure 1.10 has been released!

On Monday, 17 December 2018 17:30:01 UTC, Alex Miller wrote:

Clojure 1.10 focuses on two major areas: improved error reporting and Java 
compatibility.


I'm not touching it until Sean Corfield has it running in production ;)

Seriously, well done everyone and thank you!


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

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

Re: [ANN] Clojure 1.10.0-RC5

[Sean Corfield]

And as you can no doubt imagine, we are already testing it at World Singles 
Networks (albeit on OpenJDK 8).

Sean

On Tuesday, December 11, 2018 at 1:37:42 PM UTC-8, Alex Miller wrote:
>
> 1.10.0-RC5 is now available. Please test, particularly if your 
> library/application uses interop calls and reflection...
>
> You can try it with clj using:
>
> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-RC5"}}}'
>
> Changes in 1.10.0-RC5:
>
>- CLJ-2454  - fix 
>IllegalAccessException from invoking matching reflective call
>
> You can read the full 1.10 changelog here: 
> https://github.com/clojure/clojure/blob/master/changes.md
>

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

Re: [ANN] Clojure 1.10.0-RC4

[Sean Corfield]

All tests pass here at World Singles Networks! Looking forward to the 
"gold" release.

On Friday, December 7, 2018 at 6:45:36 AM UTC-8, Alex Miller wrote:
>
> 1.10.0-RC4 is now available. Please note that 1.10 release is imminent - 
> this is likely your last opportunity to provide feedback before we release!
>
> You can try it with clj using:
>
> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-RC4"}}}'
>
> Changes in 1.10.0-RC4:
>
>- CLJ-2449  - make 
>serialized-require private
>
> You can read the full 1.10 changelog here: 
> https://github.com/clojure/clojure/blob/master/changes.md
>
>
>

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

RE: [ANN] Clojure 1.10.0-RC3

[Sean Corfield]

We have 1.10 RC 3 in production. So far, so good.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Sean 
Corfield 
Sent: Monday, December 3, 2018 4:13:10 PM
To: Clojure
Subject: Re: [ANN] Clojure 1.10.0-RC3

Our full test suite passes with 1.10 RC 3 at World Singles Networks.

This will go into our next production build, some time this week (possibly 
tomorrow).

On Monday, December 3, 2018 at 8:19:25 AM UTC-8, Alex Miller wrote:
1.10.0-RC3 is now available.

You can try it with clj using:

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

Changes in 1.10.0-RC3:

  *   CLJ-2447<https://dev.clojure.org/jira/browse/CLJ-2447> - clojure.datafy 
docstring is missing
  *   CLJ-2448<https://dev.clojure.org/jira/browse/CLJ-2448> - change name of 
async-require to serialized-require

You can read the full 1.10 changelog here: 
https://github.com/clojure/clojure/blob/master/changes.md

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

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

Re: [ANN] Clojure 1.10.0-RC3

[Sean Corfield]

Our full test suite passes with 1.10 RC 3 at World Singles Networks.

This will go into our next production build, some time this week (possibly 
tomorrow).

On Monday, December 3, 2018 at 8:19:25 AM UTC-8, Alex Miller wrote:
>
> 1.10.0-RC3 is now available.
>
> You can try it with clj using:
>
> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-RC3"}}}'
>
> Changes in 1.10.0-RC3:
>
>- CLJ-2447  - 
>clojure.datafy docstring is missing
>- CLJ-2448  - change 
>name of async-require to serialized-require
>
> You can read the full 1.10 changelog here: 
> https://github.com/clojure/clojure/blob/master/changes.md
>

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

RE: [ANN] Clojure 1.10.0-beta8

[Sean Corfield]

In news that should surprise no one: our full test suite passes on Beta 8 (I 
meant to post that yesterday afternoon but got distracted).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Alex 
Miller 
Sent: Wednesday, November 21, 2018 7:17:26 AM
To: Clojure
Subject: [ANN] Clojure 1.10.0-beta8

1.10.0-beta8 is now available.

You can try it with clj using:

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

Changes in 1.10.0-beta8:

  *   CLJ-2438<https://dev.clojure.org/jira/browse/CLJ-2438> - demunge source 
location in execution error messages
  *   CLJ-2437<https://dev.clojure.org/jira/browse/CLJ-2437> - add 
async-require and use it from requiring-resolve
  *   CLJ-2436<https://dev.clojure.org/jira/browse/CLJ-2436> - fix reflection 
warning in reflect.java

You can read the full 1.10 changelog here: 
https://github.com/clojure/clojure/blob/master/changes.md

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

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

RE: [ANN] Clojure 1.10.0-beta8

[Sean Corfield]

This makes me smile… My first reaction to the name was the same as Alexander’s 
and then my second reaction cut in: “No, they’ll have thought about the name 
and won’t entertain changes” 

It’s for safely doing requires in asynchronous (multi-threaded) code.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Alex 
Miller 
Sent: Wednesday, November 21, 2018 9:54:28 AM
To: clojure@googlegroups.com
Subject: Re: [ANN] Clojure 1.10.0-beta8

We’re good with the name. The docstring exists for further explanation.

On Nov 21, 2018, at 11:29 AM, Alexander Yakushev 
mailto:unlo...@bytopia.org>> wrote:

Could I suggest bikeshedding on the name async-require? Before I've seen the 
patch, my initial impression was that it loads namespaces asynchronously (that 
is, returns control immediately and loads them in the background). It might be 
somewhat confusing that a function async-require is actually even more 
synchronous than the regular require :). How about synchronized-require (it's 
basically word-to-word description of the function body)?

Otherwise, thanks for this one, I needed something like this plenty of times!

On Wednesday, November 21, 2018 at 5:17:26 PM UTC+2, Alex Miller wrote:
1.10.0-beta8 is now available.

You can try it with clj using:

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

Changes in 1.10.0-beta8:

  *   CLJ-2438<https://dev.clojure.org/jira/browse/CLJ-2438> - demunge source 
location in execution error messages
  *   CLJ-2437<https://dev.clojure.org/jira/browse/CLJ-2437> - add 
async-require and use it from requiring-resolve
  *   CLJ-2436<https://dev.clojure.org/jira/browse/CLJ-2436> - fix reflection 
warning in reflect.java

You can read the full 1.10 changelog here: 
https://github.com/clojure/clojure/blob/master/changes.md

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 
clojure@googlegroups.com<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com<mailto:clojure+unsubscr...@googlegroups.com>
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/2GQQpxNcDlM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
clojure+unsubscr...@googlegroups.com<mailto: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<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

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

RE: [ANN] Clojure 1.10.0-beta7

[Sean Corfield]

Given how small the delta is from Beta 6 to Beta 7, it should surprise no one 
that all our tests pass on Beta 7 at World Singles Networks 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Alex 
Miller 
Sent: Monday, November 19, 2018 1:34:03 PM
To: Clojure
Subject: [ANN] Clojure 1.10.0-beta7

1.10.0-beta7 is now available.

You can try it with clj using:

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

Changes in 1.10.0-beta7:

  *   CLJ-2435<https://dev.clojure.org/jira/browse/CLJ-2435> - include root 
cause class name in compilation and macroexpansion errors

You can read the full 1.10 changelog here: 
https://github.com/clojure/clojure/blob/master/changes.md

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

[Sean Corfield]

This doesn’t answer your question but I’m wondering why you’re using refs at 
all? In production Clojure code I think they are extremely rare (we have about 
85K lines of Clojure and no refs at all).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Thais 
Lima 
Sent: Saturday, November 17, 2018 1:27:25 PM
To: Clojure
Subject: [Question] How to properly start up refs in web applications?

Hi,

I've started learning Clojure and I am creating a simple web application using 
Compojure and Ring.
I have refs defined in my core.clj like this:

(def my-ref1 (ref {}))
(def my-ref2 (ref {}))
(def my-ref3 (ref 0))


And in my handler.clj, I call the functions from my core namespace that change 
those refs inside a dosync.

The problem is: I've created tests for my handler and for my core, when I ran 
each of them separately, everything works fine.
But when I ran

lein test

I get errors for my handler-test, because my refs were modified by the 
core-test and this messes up my expected results.

Besides that problem, I wonder if there is a proper way of defining those refs 
in ring initialization.

What is the proper way of initializing refs in a project?

Thank you,
Thais

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

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

RE: [ANN] 1.10.0-beta6

[Sean Corfield]

All our tests pass at World Singles Networks with Beta 6 – and we’re already 
started using `symbol` on keywords and the new `requiring-resolve` (thank you 
for that!).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Alex 
Miller 
Sent: Friday, November 16, 2018 12:04:00 PM
To: Clojure
Subject: [ANN] 1.10.0-beta6

1.10.0-beta6 is now available.

You can try it with clj using:

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

Changes in 1.10.0-beta6:

  *   The metadata protocol extension added in 1.10.0-beta5 now requires opt-in 
when the protocol is defined, using :extend-via-metadata.
  *   The JavaReflector under clojure.reflect has been datafied
  *   CLJ-2432<https://dev.clojure.org/jira/browse/CLJ-2432> - Added 
clojure.core/requiring-resolve which is like `resolve` but will `require` the 
symbol's namespace if needed.
  *   CLJ-2427<https://dev.clojure.org/jira/browse/CLJ-2427> - fix bug in 
CompilerException.toString() that could cause a secondary exception to be 
thrown while making the exception string, obscuring the original exception.
  *   CLJ-2430<https://dev.clojure.org/jira/browse/CLJ-2430> - more work on 
error phases, ex-triage, and allowing prepl to better use the new error 
reporting infrastructure

You can read the full 1.10 changelog here: 
https://github.com/clojure/clojure/blob/master/changes.md









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

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

Re: [ANN] 1.10.0-beta6

[Sean Corfield]

CLJ-2432  - Added 
clojure.core/requiring-resolve which is like `resolve` but will `require` 
the symbol's namespace if needed.


This is not listed in the change log, just FYI.

On Friday, November 16, 2018 at 12:04:00 PM UTC-8, Alex Miller wrote:
>
> 1.10.0-beta6 is now available.
>
> You can try it with clj using:
>
> clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta6"}}}'
>
> Changes in 1.10.0-beta6:
>
>- The metadata protocol extension added in 1.10.0-beta5 now requires 
>opt-in when the protocol is defined, using :extend-via-metadata.
>- The JavaReflector under clojure.reflect has been datafied
>- CLJ-2432  - Added 
>clojure.core/requiring-resolve which is like `resolve` but will `require` 
>the symbol's namespace if needed.
>- CLJ-2427  - fix bug in 
>CompilerException.toString() that could cause a secondary exception to be 
>thrown while making the exception string, obscuring the original exception.
>- CLJ-2430  - more work 
>on error phases, ex-triage, and allowing prepl to better use the new error 
>reporting infrastructure
>
> You can read the full 1.10 changelog here: 
> https://github.com/clojure/clojure/blob/master/changes.md
>
>
>
>
>
>
>
>
>

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

RE: An Error spec?

[Sean Corfield]

Ah, that makes much more sense. Got it!

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of alex 

Sent: Friday, November 9, 2018 12:23:50 AM
To: Clojure
Subject: Re: An Error spec?

Sean, thanks for your feedback! Instance of Throwable is fail anyway and I 
can't imagine a situation when it's not. *exception-base-class* only sets 
behavior of call  - what we should catch and what will be thrown. Probably 
naming is kinda ambiguous here and *exception-base-class* should be called 
*catch-from* to make its purpose more clear without reading docstring.

пятница, 9 ноября 2018 г., 8:05:18 UTC+2 пользователь Sean Corfield написал:
Alex, I’m curious, should this 
https://github.com/dawcs/flow/blob/master/src/dawcs/flow.clj#L53 use 
*exception-base-class* rather than Throwable directly?

It looks very interesting and elegant – I’ll probably give this a test drive 
next week!

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clo...@googlegroups.com 
> on behalf of alex 
>
Sent: Wednesday, November 7, 2018 2:05:28 PM
To: Clojure
Subject: Re: An Error spec?

How about using exception instances as errors? That plays pretty nicely with 
ex-info and (try ... (catch Exception e e)). I've built 
https://github.com/dawcs/flow on top of that approach  and that seems like 
pretty good abstraction. Despite I'm not sure about CLJS.
Anomalies are also great and you may check out 
https://github.com/dawcs/anomalies-tools for some tooling around it. But you 
may still need a bridge to convert exceptions caught from 3rd-party java libs 
into anomalies structure. And despite Cognitect roots, it doesn't feel like 
"official standard".

пятница, 26 октября 2018 г., 4:46:54 UTC+3 пользователь Didier написал:
I've started to see a pattern in my spec like this:

(s/or :success string?
  :error ::error)

And I've been tempted to create my own spec macro for this. But I also thought, 
maybe Spec itself should have such a spec.

(s/error  )

What do people think?

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

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

[Sean Corfield]

Alex, I’m curious, should this 
https://github.com/dawcs/flow/blob/master/src/dawcs/flow.clj#L53 use 
*exception-base-class* rather than Throwable directly?

It looks very interesting and elegant – I’ll probably give this a test drive 
next week!

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of alex 

Sent: Wednesday, November 7, 2018 2:05:28 PM
To: Clojure
Subject: Re: An Error spec?

How about using exception instances as errors? That plays pretty nicely with 
ex-info and (try ... (catch Exception e e)). I've built 
https://github.com/dawcs/flow on top of that approach  and that seems like 
pretty good abstraction. Despite I'm not sure about CLJS.
Anomalies are also great and you may check out 
https://github.com/dawcs/anomalies-tools for some tooling around it. But you 
may still need a bridge to convert exceptions caught from 3rd-party java libs 
into anomalies structure. And despite Cognitect roots, it doesn't feel like 
"official standard".

пятница, 26 октября 2018 г., 4:46:54 UTC+3 пользователь Didier написал:
I've started to see a pattern in my spec like this:

(s/or :success string?
  :error ::error)

And I've been tempted to create my own spec macro for this. But I also thought, 
maybe Spec itself should have such a spec.

(s/error  )

What do people think?

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

[Sean Corfield]

Flow reminds me a bit of a project I started in early 2015 and decided to 
sunset in late 2016: https://github.com/seancorfield/engine

We actually used Engine at work for a while but decided the resulting code was 
both harder to read and not really very idiomatic. I’ll be interested to hear 
how people find Flow in production – it’s a lot more focused and simpler than 
Engine (which is definitely a good thing!  ).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of alex 

Sent: Wednesday, November 7, 2018 2:05:28 PM
To: Clojure
Subject: Re: An Error spec?

How about using exception instances as errors? That plays pretty nicely with 
ex-info and (try ... (catch Exception e e)). I've built 
https://github.com/dawcs/flow on top of that approach  and that seems like 
pretty good abstraction. Despite I'm not sure about CLJS.
Anomalies are also great and you may check out 
https://github.com/dawcs/anomalies-tools for some tooling around it. But you 
may still need a bridge to convert exceptions caught from 3rd-party java libs 
into anomalies structure. And despite Cognitect roots, it doesn't feel like 
"official standard".

пятница, 26 октября 2018 г., 4:46:54 UTC+3 пользователь Didier написал:
I've started to see a pattern in my spec like this:

(s/or :success string?
  :error ::error)

And I've been tempted to create my own spec macro for this. But I also thought, 
maybe Spec itself should have such a spec.

(s/error  )

What do people think?

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

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

RE: What's the end goal for tools.deps?

[Sean Corfield]

I guess I see the need for a dependency manager.



I’m curious as to how you define this tool: what exactly do you consider a 
“dependency manager” to be, and what are it’s specific functions/features? You 
talk about having an “internal dependency manager” – how do you leverage that 
from Clojure?



Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood




From: clojure@googlegroups.com  on behalf of Didier 

Sent: Sunday, November 4, 2018 10:58:43 AM
To: Clojure
Subject: RE: What's the end goal for tools.deps?

Thanks everyone.

I guess I see the need for a dependency manager. And I love having a CLI to 
launch Clojure programs. And I understand it is fundamental. That said, it 
always felt like Lein had solved that problem long ago. Maybe it wasn't 
official enough. But Lein could have been bundled with Clojure and effectively 
solved the same problems and more.

That said, I do prefer the tools.deps abstraction. Just feels a little like 
reinventing the wheel.

I'll be interested to read your blog posts Sean.

At my work, I can't use tools.deps, because we have an internal dependency 
manager. And all dependencies are imported and vetted in it first. So I've 
always wanted a build tool that was decoupled from dependency management. Since 
tools.deps only outputs a classpath, I assume all these extra tools you 
mentioned using to build and run your tests and deploy somehow work only given 
a classpath. They might be useful 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.

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

RE: What's the end goal for tools.deps?

[Sean Corfield]

Any serious work will need a build tool of some sort. If you use lein, it comes 
with its own dependency management and config. Same for boot (as far as I 
know). So in practice, if I use tools.deps, I've now doubled the number of 
tools I depend on. I need lein and tools.deps.

At World Singles Networks, we’ve just completed our shift from a complex 
Boot-based pipeline to just clj/deps.edn and a small shell script to make the 
invocation simpler. We originally started with Leiningen (back in 2011). We 
switched to Boot at the end of 2015 (you can read why, and details about our 
journey, here: http://corfield.org/blog/categories/boot/ ). We still have two 
small Boot tasks, related to legacy projects, that I will likely convert this 
week. I’ll write a lengthy blog post (or two or more) about why we made this 
switch and what pros and cons we encountered, but I’d sum it up as 
“simplicity”. We are now dependent solely on a small, focused tool that is 
“standard” with Clojure. For deployment, we still build uberjars (using my fork 
of depstar that fixes a couple of bugs, and adds “thin” JAR support). We start 
those JARs with java -cp path/to/the.jar clojure.main -m our.namespace which is 
pretty much what we were doing with Boot (we used java -jar path/to/the.jar -m 
our.namespace but switched to the slightly longer form just before we migrated 
to clj/deps.edn). We use Cognitect’s test-runner, we use Olical’s depot (to 
track outdated dependencies).

I’ve published JARs to Clojars using just clj -Spom, clj -A:jar (invoking 
depstar), and mvn deploy:deploy-file (the only thing I actually use Maven for!).

As I’ve worked on various Contrib libraries (that already have pom.xml and use 
Maven on the CI system), I’ve removed the “convenience” project.clj files that 
were originally added to make working with those projects easier (e.g., to 
start an nREPL server, to run tests with multiple versions of Clojure etc) and 
replaced them with deps.edn files – and by using aliases for different Clojure 
versions, I can do multi version testing like this: for v in 1.6 1.7 1.8 1.9 
master; do clojure -A:test:$v; done

I’ve published my .clojure/deps.edn file on GitHub 
https://github.com/seancorfield/dot-clojure as an example of tooling 
integration with a clj-based workflow: starting nREPL servers, running 
Eastwood, benchmarking, testing, building JAR and uberjar files, even creating 
new clj-based projects.

If you’re happy with Leiningen or Boot, there’s no reason for you to switch. 
You can still adopt the new deps.edn format and use 
https://github.com/RickMoynihan/lein-tools-deps or 
https://github.com/seancorfield/boot-tools-deps to integrate it, if you wish.

One important caveat to consider right now is that there is no support for 
Windows for clj/deps.edn projects (I develop on both macOS and Windows 10 – I 
just use WSL with Ubuntu on the latter – and at work everything is deployed to 
Linux).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Didier 

Sent: Saturday, November 3, 2018 8:46:45 PM
To: Clojure
Subject: What's the end goal for tools.deps?

I read the rationale, and I understand that we needed a way to bundle depencies 
for clj and clojure cli. But in practice, I'm seeing a lot of people move to 
it, away from boot or lein, and I fail to see what the end goal really is?

Any serious work will need a build tool of some sort. If you use lein, it comes 
with its own dependency management and config. Same for boot (as far as I 
know). So in practice, if I use tools.deps, I've now doubled the number of 
tools I depend on. I need lein and tools.deps.

For me, it seems the benefit would be around unified dependency config format 
and maybe reuse of the resolver logic. Like say Lein and Boot and all tools 
needing to specify dependencies adopted the format of tools.deps. This would be 
nice, especially for source based dependencies, and dealing with transitive 
dependencies in such case.

So, is there any hope/work to adopt the format in Lein and Boot? Or what is the 
end goal otherwise?

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<mailto:clojure+unsubscr...@googlegroups.co