[ANN] tools.deps.alpha 0.5.435, clj 1.9.0.381

2018-05-13 Thread Alex Miller 
Now available:

   - tools.deps.alpha 0.5.435
   - clj 1.9.0.381
  - Mac: brew upgrade clojure
  - Linux: see https://clojure.org/guides/getting_started
  - Windows: working on it! 
   
Changelog:

   - Support for Maven deps in authenticated repositories (TDEPS-9 - thanks 
Dominic 
   Monroe!)
   - In local jar dependencies like {:local/root "path/to.jar"}, if the jar 
   has an embedded pom, it will be used to traverse and include transitive deps
   - Use `exec` for final Java invocation in scripts (TDEPS-76 - 
   thanks Mikhail Gusarov!)
   - Convey lib map via Java system property - a first step towards add-lib 
    and other future 
   functionality
   
For Maven deps in authenticated repositories, existing Maven infrastructure 
is used to convey credentials via the ~/.m2/settings.xml:

  
…

  my-auth-repo
  zango
  123

…
  

Then in your deps.edn include a repo with a name matching the :

{:deps
 {authenticated/dep {:mvn/version "1.2.3"}}
 :mvn/repos
 {"my-auth-repo" {:url "https://my.auth.com/repo"}}}

This will be included in the docs too, just haven't had time yet.

Issues: https://dev.clojure.org/jira/browse/TDEPS
Chat: Clojurian Slack in #tools-deps




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

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

2018-05-13 Thread Oliver Hine 
Hi everyone,

I'm pleased to announce the release of re-graph 0.1.5 
. re-graph is a 
GraphQL client for Clojurescript with re-frame bindings and support for 
queries, subscriptions and mutations over websocket or HTTP.

   - 
   
   This release *adds support for*:
   - Providing the payload to be sent in the connection_init message, sent 
  whenever a websocket connection is made. See #19 
   and #20 
   for details, thanks to 
  @gabrielnau 
  - Now works on React native. See #25 
  , thanks to @madstap 
  
  - Working with query builders like venia 
   which include "query" at the start 
  of the string, see #18 
   

   

   
It's available now on Clojars.

Thanks and enjoy,
Oliy

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

2018-05-13 Thread Oliver Hine 
Hi,

Not a direct answer, but something that may help you simplify your problem:

I have a general rule to avoid core.async when only one value would ever be 
sent down the channel. For these use cases promises are an order of 
magnitude simpler, giving you control of the thread of operation, simple 
testing for completion (future-done?), simple timeouts, and no cleanup 
required afterwards.

>From what I understand, a promise would fit your requirements and I think 
would be much easier to reason about.

Hope this helps,
Oliy

On Tuesday, 8 May 2018 21:45:00 UTC+1, Brjánn Ljótsson wrote:
>
> Hi!
>
> I'm writing a server-side (S1) function that initiates an action on 
> another server (S2) and regularly checks if the action has finished 
> (failed/completed). It should also be possible for a client to ask S1 for 
> the status of the action performed by S2.
>
> My idea is to create an uid on S1 that represents the action and the uid 
> is returned to the client. S1 then asynchronously polls S2 for action 
> status and updates an atom with the uid as key and status as value. The 
> client can then request the status of the uid from S1. Below is a link to 
> my proof of concept code (without any code for the client requests or 
> timeout guards) - and it is my first try at writing code using core.async.
>
> https://gist.github.com/brjann/d80f1709b3c17ef10a4fc89ae693927f
>
> The code can be tested with for example (start-poll) or (repeatedly 10 
> start-poll) to test the behavior when multiple requests are made.
>
> The code seems to work, but is it a correct use of core.async? One thing 
> I'm wondering is if the init-request and poll functions should use threads 
> instead of go-blocks, since the http requests may take a few hundred 
> milliseconds and many different requests (with different uids) could be 
> made simultaneously. I've read that "long-running" tasks should not be put 
> in go blocks. I haven't figured out how to use threads though.
>
> I would be thankful for any input!
>
> Best wishes,
> Brjánn Ljótsson
>

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

2018-05-13 Thread Brjánn Ljótsson 
Hi Oliy,

I really appreciate your input since I'm totally new to writing
asynchronous tasks. If I understand you correctly, promises are a better
way to go if only one value is collected from S2 by S1. However, S1 will
keep polling S2 (once every 1.5 secs, by S2's API specification) for
updates on the status of the task that S2 is running. The task can be in
several different states and S1 needs to know the current state of the task
and pass it on to the client. So, actually, multiple and different values
will be sent down the channel. The polling will quit once the task has been
completed or timed out (ca 5 minutes). That's why I went for core.async as
it seems to be suitable for launching a separate "thread" that takes care
of the polling.

Does this make any sense as a rationale for using core.async?

Thanks!

Brjánn

On 13 May 2018 at 20:58, Oliver Hine  wrote:

> Hi,
>
> Not a direct answer, but something that may help you simplify your problem:
>
> I have a general rule to avoid core.async when only one value would ever
> be sent down the channel. For these use cases promises are an order of
> magnitude simpler, giving you control of the thread of operation, simple
> testing for completion (future-done?), simple timeouts, and no cleanup
> required afterwards.
>
> From what I understand, a promise would fit your requirements and I think
> would be much easier to reason about.
>
> Hope this helps,
> Oliy
>
>
> On Tuesday, 8 May 2018 21:45:00 UTC+1, Brjánn Ljótsson wrote:
>>
>> Hi!
>>
>> I'm writing a server-side (S1) function that initiates an action on
>> another server (S2) and regularly checks if the action has finished
>> (failed/completed). It should also be possible for a client to ask S1 for
>> the status of the action performed by S2.
>>
>> My idea is to create an uid on S1 that represents the action and the uid
>> is returned to the client. S1 then asynchronously polls S2 for action
>> status and updates an atom with the uid as key and status as value. The
>> client can then request the status of the uid from S1. Below is a link to
>> my proof of concept code (without any code for the client requests or
>> timeout guards) - and it is my first try at writing code using core.async.
>>
>> https://gist.github.com/brjann/d80f1709b3c17ef10a4fc89ae693927f
>>
>> The code can be tested with for example (start-poll) or (repeatedly 10
>> start-poll) to test the behavior when multiple requests are made.
>>
>> The code seems to work, but is it a correct use of core.async? One thing
>> I'm wondering is if the init-request and poll functions should use threads
>> instead of go-blocks, since the http requests may take a few hundred
>> milliseconds and many different requests (with different uids) could be
>> made simultaneously. I've read that "long-running" tasks should not be put
>> in go blocks. I haven't figured out how to use threads though.
>>
>> I would be thankful for any input!
>>
>> Best wishes,
>> Brjánn Ljótsson
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

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

Alan

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