Re: [ANN] graphql-clj 0.2.0

[Didier]

How does this compare to Lacinia?

On Monday, 24 April 2017 11:24:22 UTC-7, Lei wrote:
>
> graphql-clj is a Clojure library that provides GraphQL implementation.
>
> In this new version 0.2.0,  schema and query validator have been 
> completely rewritten for simplicity and robustness. APIs have simplified in 
> this new version as well.
>
> The github repository is: https://github.com/tendant/graphql-clj
>
> Any comments and advices are welcome!
>
> Cheers,
> Lei
>

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

[Dragan Djuric]

I'll write more in an introductory blog post in a day or two. Until that, 
there is a website http://clojurecuda.uncomplicate.org, that has the 
details and documentation.

It is similar to ClojureCL (http://clojurecl.uncomplicate.org), but is 
targeted to CUDA and Nvidia GPUs specifically. The main benefit over 
ClojureCL is that ClojureCUDA will make possible to call various Nvidia 
libraries such as cuBLAS, cuFFT or cuDNN from your Clojure code.

Fast matrix library Neanderthal (http://neanderthal.uncomplicate.org) will 
soon have a cuBLAS GPU backend in addition to MKL CPU, and OpenCL GPU 
backends. 

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

[Alan Thompson]

Unless prevented by outside considerations, it might also be
cleaner/simpler to copy all inputs from Java -> Clojure, do all the
algorithm work in Clojure, then copy all outputs back from Clojure -> Java.
I'm looking specifically at `java-memory-map`, but would also replace
native java stuff like `java.util.HashMap` with Clojure versions whenever
possible.  Again, the goal is to avoid clashes in the hidden assumptions of
the two models.
Alan

On Mon, Apr 24, 2017 at 1:05 PM, Alan Thompson  wrote:

> Having not gone through your code in detail, I would suggest replacing
> `map` -> `mapv` to make it an eager operation so that state updates (i.e. `
> next-states`) occur right away.  The presence of laziness where it is not
> needed or expected (especially in Java interop code) can cause problems
> with the (implicit) assumptions of other code.
> Alan
>
> On Sat, Apr 22, 2017 at 2:59 AM, Lucas Wiener  wrote:
>
>> Hi all,
>>
>> I'm working on solving the problem http://adventofcode.com/2016/day/11 ,
>> and ran into some weird behaviour. I have solved the actual problem, so
>> let's not focus on it.
>>
>> Here's my code:
>>
>> (defn compute3
>>   {:test (fn []
>>(is= (compute3 (create-state "F4 .  .  .  .  .  "
>> "F3 .  .  .  LG .  "
>> "F2 .  HG .  .  .  "
>> "F1 E  .  HM .  LM "))
>> 11))}
>>   [state]
>>   (let [done-simple-state (state->simple-state (construct-finished-state
>> state))
>> inner-fn (fn [states steps java-memory-map]
>>(println "On step" steps)
>>(println "Number of states" (count states))
>>(let [next-states (->> states
>>   (map (fn [state]
>>  (->> (get-next-states
>> state)
>>   (filter (fn [s]
>> (nil? (.get java-memory-map (state->simple-state s
>>   (flatten))]
>>  ;; (println (count next-states)) <- Uncomment this
>> line to change the behavior
>>  (if (.get java-memory-map done-simple-state)
>>steps
>>(do (doseq [next-state next-states]
>>  (.put java-memory-map (state->simple-state
>> next-state) steps))
>>(recur next-states (inc steps)
>> java-memory-map)]
>> (inner-fn [state] 0 (java.util.HashMap.
>>
>> When running this in the repl I get the following output:
>>
>> On step 0
>> Number of states 1
>> On step 1
>> Number of states 1
>> On step 2
>> Number of states 3
>> On step 3
>> Number of states 11
>> On step 4
>> Number of states 14
>> On step 5
>> Number of states 22
>> On step 6
>> Number of states 37
>> On step 7
>> Number of states 48
>> On step 8
>> Number of states 35
>> On step 9
>> Number of states 22
>> On step 10
>> Number of states 17
>> On step 11
>> Number of states 7
>>
>> However, if I uncomment the println statement I get the following output
>> in the REPL:
>>
>> On step 0
>> Number of states 1
>> 1
>> On step 1
>> Number of states 1
>> 3
>> On step 2
>> Number of states 3
>> 11
>> On step 3
>> Number of states 11
>> 15
>> On step 4
>> Number of states 15
>> 28
>> On step 5
>> Number of states 28
>> 63
>> On step 6
>> Number of states 63
>> 107
>> On step 7
>> Number of states 107
>> 90
>> On step 8
>> Number of states 90
>> 82
>> On step 9
>> Number of states 82
>> 115
>> On step 10
>> Number of states 115
>> 81
>> On step 11
>> Number of states 81
>> 110
>>
>> Please note that "On step 4" prints "Number of states 14" and "Number of
>> states 15"  differently.
>>
>> Any thoughts?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to 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 

Re: (doseq/lazy/interop)? problem, different behaviour when adding a println

[Alan Thompson]

Having not gone through your code in detail, I would suggest replacing
`map` -> `mapv` to make it an eager operation so that state updates (i.e. `
next-states`) occur right away.  The presence of laziness where it is not
needed or expected (especially in Java interop code) can cause problems
with the (implicit) assumptions of other code.
Alan

On Sat, Apr 22, 2017 at 2:59 AM, Lucas Wiener  wrote:

> Hi all,
>
> I'm working on solving the problem http://adventofcode.com/2016/day/11 ,
> and ran into some weird behaviour. I have solved the actual problem, so
> let's not focus on it.
>
> Here's my code:
>
> (defn compute3
>   {:test (fn []
>(is= (compute3 (create-state "F4 .  .  .  .  .  "
> "F3 .  .  .  LG .  "
> "F2 .  HG .  .  .  "
> "F1 E  .  HM .  LM "))
> 11))}
>   [state]
>   (let [done-simple-state (state->simple-state (construct-finished-state
> state))
> inner-fn (fn [states steps java-memory-map]
>(println "On step" steps)
>(println "Number of states" (count states))
>(let [next-states (->> states
>   (map (fn [state]
>  (->> (get-next-states
> state)
>   (filter (fn [s]
> (nil? (.get java-memory-map (state->simple-state s
>   (flatten))]
>  ;; (println (count next-states)) <- Uncomment this
> line to change the behavior
>  (if (.get java-memory-map done-simple-state)
>steps
>(do (doseq [next-state next-states]
>  (.put java-memory-map (state->simple-state
> next-state) steps))
>(recur next-states (inc steps)
> java-memory-map)]
> (inner-fn [state] 0 (java.util.HashMap.
>
> When running this in the repl I get the following output:
>
> On step 0
> Number of states 1
> On step 1
> Number of states 1
> On step 2
> Number of states 3
> On step 3
> Number of states 11
> On step 4
> Number of states 14
> On step 5
> Number of states 22
> On step 6
> Number of states 37
> On step 7
> Number of states 48
> On step 8
> Number of states 35
> On step 9
> Number of states 22
> On step 10
> Number of states 17
> On step 11
> Number of states 7
>
> However, if I uncomment the println statement I get the following output
> in the REPL:
>
> On step 0
> Number of states 1
> 1
> On step 1
> Number of states 1
> 3
> On step 2
> Number of states 3
> 11
> On step 3
> Number of states 11
> 15
> On step 4
> Number of states 15
> 28
> On step 5
> Number of states 28
> 63
> On step 6
> Number of states 63
> 107
> On step 7
> Number of states 107
> 90
> On step 8
> Number of states 90
> 82
> On step 9
> Number of states 82
> 115
> On step 10
> Number of states 115
> 81
> On step 11
> Number of states 81
> 110
>
> Please note that "On step 4" prints "Number of states 14" and "Number of
> states 15"  differently.
>
> Any thoughts?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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] graphql-clj 0.2.0

[Lei]

graphql-clj is a Clojure library that provides GraphQL implementation.

In this new version 0.2.0,  schema and query validator have been completely 
rewritten for simplicity and robustness. APIs have simplified in this new 
version as well.

The github repository is: https://github.com/tendant/graphql-clj

Any comments and advices are welcome!

Cheers,
Lei

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

[Dave Dixon]

Both, actually. The algorithm incrementally builds a tree via simulation. 
There's a step of traversing the current version of the tree to find a 
leaf, which requires immutability, as I have to remember the path taken 
(the path is generated via simulation, not by walking an existing tree 
structure, so requires updates to the state maps). But once at a leaf, I 
run multiple simulations in parallel, and provided each starts with an 
independent mutable "copy", then the subsequent states can be mutable. That 
should be a big perf win, since it's where the algo spends a lot of it's 
time. The data structures that hold the statistics about the states in the 
tree could also be mutable. These are keyed by state maps, hoping improved 
hash/equality performance will help a little there as well.

On Sunday, April 23, 2017 at 1:18:56 PM UTC-7, Zach Tellman wrote:
>
> Are you relying on the immutability of these structures, or are they 
> effectively always transient?
> On Sun, Apr 23, 2017 at 11:02 AM Dave Dixon  > wrote:
>
>> FWIW, the use-case I have essentially involves Monte Carlo simulations. 
>> So we start with a state (non-empty map), and then make a series of 
>> modifications to it. Various statistics are held in hash-maps keyed by the 
>> state, so there's a lot of lookups and modifications in those maps.
>>
>> That said, I'm not sure if for this particular case I care too much using 
>> Clojure idioms vs. direct API access. The algorithms tend to be 
>> hand-tweaked for performance anyway. The big win for me in wrapping 
>> bifurcan would be the ability to use spec without having to write 
>> specialized specs, generators, etc.
>>
>>
>> On Thursday, April 20, 2017 at 9:53:56 PM UTC-7, Zach Tellman wrote:
>>
>>> Sure, happy to elaborate.  Bifurcan offers potential performance wins a 
>>> few different ways:
>>>
>>> * We can use standard Java equality semantics, bypassing all the 
>>> overhead of the hash calculations and enhanced numeric equality checks 
>>> (this can lead to moderate performance gains)
>>> * We can use a mutable data structure as long as it never escapes a 
>>> local context (this can lead to significant performance gains)
>>> * We can use the extra capabilities the data structures expose, like 
>>> concatenation, slicing, set operations, etc. (this is too dependent on the 
>>> use case to really quantify)
>>>
>>
>>> it would be easy to have a `map` and `map*` method that expose Clojure 
>>> and Java equality semantics, respectively, but that puts a big onus on the 
>>> developer to determine if the latter is safe for their use case.  I've been 
>>> bit by this when I've used j.u.c.ConcurrentHashMap before, so I expect 
>>> people will suffer similarly weird bugs.
>>>
>>> However, I think there's a way to use the mutable data structures.  
>>> Technically, transient data structures allow arbitrary persistent data 
>>> structures to be batch updated, but in practice they tend to be empty, and 
>>> after they're populated they tend to be treated as read-only.
>>>
>>> If we're convinced this is common enough, every empty transient data 
>>> structure could be mutable, and when we make it persistent we could wrap it 
>>> in a "virtual" collection [1] which allows updates without touching the 
>>> base collection.  This would allow for faster writes, faster reads, and 
>>> only marginally slower updates if those are required.
>>>
>>> This is all predicated on a bunch of assumptions that are hard to 
>>> validate, but if this describes enough real-world use cases, it could lead 
>>> to a big, easy performance win.  It's even possible to automatically 
>>> replace the base Clojure collections with these alternatives using 
>>> something like Sleight [2].
>>>
>>> Anyway, that's what I've been mulling over.  If anyone has opinions, I'm 
>>> happy to hear them.
>>>
>>> Zach
>>>
>>> [1] 
>>> https://github.com/lacuna/bifurcan/blob/master/src/io/lacuna/bifurcan/Maps.java#L103
>>> [2] https://github.com/ztellman/sleight
>>>
>>> On Thu, Apr 20, 2017 at 8:55 AM Dave Dixon  wrote:
>>>
 Sounds great. If you have time, I'd certainly like to hear your 
 thoughts on the issues of equality semantics and transients, maybe I can 
 ponder and make some suggestions based on my target use-case.


 On Tuesday, April 18, 2017 at 9:32:32 AM UTC-7, Zach Tellman wrote:

> To be clear, my intention was always to wrap the implementations in 
> the appropriate Clojure interfaces, and I don't believe that will cause 
> much, if any, of a performance hit (inlining is magic).  However, there 
> are 
> some real questions regarding how to expose non-standard equality 
> semantics, and whether transients should be represented using the 
> immutable 
> or mutable collection variants.  
>
> For what it's worth, I have about 1/3 of an implementation of 
> Clojure-compatible versions of these data structures, I 

Re: [ANN] Clojure infrastructure SSL

[Jo Geraerts]

Hello,

Op vrijdag 21 april 2017 23:08:22 UTC+2 schreef Alex Miller:
>
> The following bits of Clojure infrastructure are now https-only and 
> redirect all traffic from http to https:
>
> https://build.clojure.org - Jenkins
> https://dev.clojure.org/jira - JIRA
> https://dev.clojure.org - Confluence
>
> Let me know if you see anything amiss.
>
>
Since you're going https-only you should also make your cookies secure as 
well as set HTTP Strict Transport Security headers. 

Kr,

Jo

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