Re: [ANN] spec.alpha 0.1.109

[Sean Corfield]

I’ve mentioned this on Slack and IRC and I’ll just highlight it again here…

 

If you’re doing programmatic decoding of explain-data to produce “friendly” 
messages and you currently do anything with the :pred value in the returned 
map, then this change will affect you:

 

· CLJ-2059 - explain-data should return resolved preds

 

In particular, a :pred for an anonymous function, such as used by s/keys for 
required keys, used to return:

 

    (contains? % :the-key)

 

but now it returns:

 

    (clojure.core/fn [%] (contains? % :the-key))

 

(I think the way it tested for the data being a map? has changed in a similar 
way – I was expecting clojure.core/map? but no)

 

The change is important – previously you couldn’t tell which actual predicate 
was used whenever you had the same name in multiple namespaces – but it is a 
bit weird that not all symbols are fully resolved: it depends on how the 
predicate is written.

 

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

 

On 5/26/17, 9:21 AM, "Alex Miller"  wrote:

 

There was a build snafu with the version number so we have re-released this as 
[org.clojure/spec.alpha "0.1.123"]. 

No code changes, so effectively the same content.

On Friday, May 26, 2017 at 10:16:57 AM UTC-5, Alex Miller wrote:

spec.alpha 0.1.109 is now available.

 

Try it via:  [org.clojure/spec.alpha "0.1.109"]

 

0.1.109 includes the following changes:

·  CLJ-2153 - Docstring for int-in-range? and int-in now mention fixed 
precision constraint

·  CLJ-2085 - Add the top level spec and value to explain-data

·  CLJ-2076 - coll-of and map-of should unform their elements

·  CLJ-2063 - report explain errors in order from longest to shortest path

·  CLJ-2061 - Better error message when exercise-fn called on fn without :args 
spec

·  CLJ-2059 - explain-data should return resolved preds

·  CLJ-2057 - If :ret spec is not supplied, use any?

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

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.562"]

This release coincides with Clojure 1.9.0-alpha17, includes a variety
of fixes, and updates both the Closure Compiler & Library dependencies.

As always, feedback welcome!

### Enhancements
* CLJS-2027: Add language-in for ECMA 2017 and ECMA Next
* CLJS-2026: Add Compiler option for rewrite polyfills

### Changes
* CLJS-2021: subvec throws when passed non-vector
* CLJS-1884: Give a chance to MetaFn to be removed by closure under
:advanced
  optimization Replace with-meta calls by -with-meta calls where possible
* CLJS-2052: Port new spec.alpha enhancements
* Update Google Closure Compiler dependency
* Update Google Closure Library dependency

### Fixes
* CLJS-2053: Regression: cljs.spec.alpha/any for fdef
* CLJS-2039: remove extraneous argument from ChunkBuffer.chunk
* Fix assumption that all closure-compliant JS is goog.*
* CLJS-2035: Self-host: Add map-entry-test to self-parity
* CLJS-2033: set-validator! should check current state
* CLJS-2008: Self-host: backport fixes to threading macros
* CLJS-2005: Bad error message with duplicate arity function definitions
* CLJS-2032: Case macro expansion evaluates expression twice when no
matching clause
* CLJS-2023: User supplied type hints stopped working on js/goog.DEBUG
* CLJS-2020: defmulti "miss" performance poor
* CLJS-2034: Sequence and Eduction produce infinite loop in transducer that
appends to the reduction

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

regarding writing unit tests in clojure for existing java code

[manas . marthi]

Hello All,.

  We have a large java code base. Junits are not keeping in pace with the 
code base changes and quite a number are outdated.
  I was wondering if I can use clojure to write unit tests and run them 
using Junit Runner so that the unit tests pass inside eclipse as part of 
compilation of Junit test suite execution.
  Please can someone advise if there is any library already for achieving 
this 

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.

[ANN] Clojure 1.9.0-alpha17

[Alex Miller]

Clojure 1.9.0-alpha17 is now available.

Try it via

- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha17
- Leiningen: [org.clojure/clojure "1.9.0-alpha17"]

1.9.0-alpha17 includes the following changes since 1.9.0-alpha16:

- CLJ-1793 Clear 'this' before calls in tail position
- CLJ-2091 clojure.lang.APersistentVector#hashCode is not thread-safe
- CLJ-1860 Make -0.0 hash consistent with 0.0
- CLJ-2141 Return only true/false from qualified-* predicates
- CLJ-2142 Fix check for duplicate keys with namespace map syntax
- CLJ-2128 spec error during macroexpand no longer throws compiler 
exception with location
- Updated to use spec.alpha 0.1.123

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

[Timothy Dean]

I have used pipeline before, and when working with channels it is quite
convenient. But transducers are useful for many cases outside the use of
channels and core.async. And pipeline cannot compose with transducers,
afaik. So for the situation I describe, it seems to me that using pipeline
would introduce even further complexity. I would start with comp and
transducers, and wind up with a let, two local temporary channels, etc.
etc. I don't see what pipeline would buy me that current core.async pmap
would not already provide.

It's a bit of a simple case for parallelism, but then again so is current
`pmap` behavior.

Thanks,
~Timothy Dean

On Fri, May 26, 2017 at 11:47 AM, Gary Trakhman 
wrote:

> Have you looked into core.async's 'pipeline' function for parallelism?
> That was my first question when I saw this post.  I'm not sure why there's
> a need for pmap.
>
> On Fri, May 26, 2017 at 12:29 PM Timothy Dean 
> wrote:
>
>> You can also get an indication this way, I think:
>>
>> user=> (defn f [x] (Thread/sleep 100) x)
>> #'user/f
>> user=> (time (doall (pmap f (range 32
>> "Elapsed time: 128.383719 msecs"
>> user=> (time (doall (pmap f (range 33
>> "Elapsed time: 201.462131 msecs"
>> user=> (time (doall (pmap f (range 64
>> "Elapsed time: 201.89915 msecs"
>> user=> (time (doall (pmap f (range 65
>> "Elapsed time: 301.711263 msecs"
>> user=> (time (doall (pmap f (range 96
>> "Elapsed time: 302.205999 msecs"
>> user=> (time (doall (pmap f (range 97
>> "Elapsed time: 402.236708 msecs"
>>
>> Regarding motivation for having a pmap transducer, my own is mainly that
>> it composes with other transducers. A major practical/implementation
>> "triumph" of transducers may be the reduced garbage, but there is a benefit
>> of simplified expression as well, since transducers encode transformation
>> in a manner agnostic to many elements of the context of the transformation.
>> In a project containing many transducers variously composed and consumed
>> throughout, it may be that I wish to parallelize one portion of a
>> transformation occurring in the middle of a composition of transducers. If
>> so, I can't simply drop in clojure.core's pmap.
>>
>> Instead I now must -- in the specific context of whatever higher-order
>> transducing function I happen to be using -- break the composed transducers
>> apart, generate a transitory sequence, pmap over that, and then proceed
>> with transforming the temporary sequence. That is, in this case I'm not
>> concerned so much with the resource overhead of swapping a transducer for a
>> non-transducer, but the expressive overhead. Composition is elegant. My
>> solutions with clojure.core's pmap are clunky. I'm not ruling out PEBCAK
>> error, but a pmap transducer seems to me the "obvious" solution preserving
>> compositional elegance.
>>
>> For instance, a very simple example using transduce:
>>
>> (transduce (comp (remove bad)
>>
>>  ...
>>
>>  (map transform)
>>
>>  ...
>>
>>  (keep pred))
>>
>>reducer
>>
>>init coll)
>>
>>
>> must become something like:
>>
>> (->> coll
>>
>>  (sequence (comp (remove bad)
>>
>>  ...))
>>
>>  (pmap transform)
>>
>>  (transduce (comp ...
>>
>>   (keep pred))
>>
>> reducer
>>
>> init))
>>
>> But it could be as simple as:
>>
>> (transduce (comp (remove bad)
>>
>>  ...
>>
>>  (pmap transform)
>>
>>  ...
>>
>>  (keep pred))
>>
>>reducer
>>
>>init coll)
>>
>> Does that make sense, or am I crazy? :)
>>
>> ~Timothy Dean
>>
>> On Friday, May 26, 2017 at 3:10:15 AM UTC-6, Matching Socks wrote:
>>>
>>> With the overhead of threading, isn't the triumph of a transducer (no
>>> seq allocations) rather subtle in the case of pmap?
>>>
>>>
>>> At any rate!, as a point of interest, since you mentioned a quirk of
>>> pmap's thread usage: It apparently has to do with whether the input
>>> sequence is a
>>> chunked sequence or not.
>>>
>>> Comparing two possible inputs
>>>
>>> user> (def c (into [] (range 50))) ;; chunked
>>>
>>> user> (def n (into '() (range 50))) ;; not chunked
>>>
>>> With pmap invoking a function that just returns the thread's name (and
>>> takes some time, so as to keep its assigned thread busy enough not to
>>> accept more tasks right away)
>>>
>>> user> (defn f [x] (Thread/sleep 22) (.getName (Thread/currentThread)))
>>> #'user/f
>>> user> (count (distinct (pmap f c)))
>>> 32
>>> user> (count (distinct (pmap f n)))
>>> 7
>>>
>>> The test is not perfect because it does not show that all 32
>>> threads were used *at once*. There were simply 32 distinct threads used
>>> at one
>>> point or another.  Nonetheless the difference between 7 and 32 is
>>> suggestive.
>>>
>>> In this environment there are 4 "processors", so 32 is indeed more than
>>> you might want.
>>>
>>> T

Re: pmap: transducer & chunking

[Gary Trakhman]

Have you looked into core.async's 'pipeline' function for parallelism?
That was my first question when I saw this post.  I'm not sure why there's
a need for pmap.

On Fri, May 26, 2017 at 12:29 PM Timothy Dean 
wrote:

> You can also get an indication this way, I think:
>
> user=> (defn f [x] (Thread/sleep 100) x)
> #'user/f
> user=> (time (doall (pmap f (range 32
> "Elapsed time: 128.383719 msecs"
> user=> (time (doall (pmap f (range 33
> "Elapsed time: 201.462131 msecs"
> user=> (time (doall (pmap f (range 64
> "Elapsed time: 201.89915 msecs"
> user=> (time (doall (pmap f (range 65
> "Elapsed time: 301.711263 msecs"
> user=> (time (doall (pmap f (range 96
> "Elapsed time: 302.205999 msecs"
> user=> (time (doall (pmap f (range 97
> "Elapsed time: 402.236708 msecs"
>
> Regarding motivation for having a pmap transducer, my own is mainly that
> it composes with other transducers. A major practical/implementation
> "triumph" of transducers may be the reduced garbage, but there is a benefit
> of simplified expression as well, since transducers encode transformation
> in a manner agnostic to many elements of the context of the transformation.
> In a project containing many transducers variously composed and consumed
> throughout, it may be that I wish to parallelize one portion of a
> transformation occurring in the middle of a composition of transducers. If
> so, I can't simply drop in clojure.core's pmap.
>
> Instead I now must -- in the specific context of whatever higher-order
> transducing function I happen to be using -- break the composed transducers
> apart, generate a transitory sequence, pmap over that, and then proceed
> with transforming the temporary sequence. That is, in this case I'm not
> concerned so much with the resource overhead of swapping a transducer for a
> non-transducer, but the expressive overhead. Composition is elegant. My
> solutions with clojure.core's pmap are clunky. I'm not ruling out PEBCAK
> error, but a pmap transducer seems to me the "obvious" solution preserving
> compositional elegance.
>
> For instance, a very simple example using transduce:
>
> (transduce (comp (remove bad)
>
>  ...
>
>  (map transform)
>
>  ...
>
>  (keep pred))
>
>reducer
>
>init coll)
>
>
> must become something like:
>
> (->> coll
>
>  (sequence (comp (remove bad)
>
>  ...))
>
>  (pmap transform)
>
>  (transduce (comp ...
>
>   (keep pred))
>
> reducer
>
> init))
>
> But it could be as simple as:
>
> (transduce (comp (remove bad)
>
>  ...
>
>  (pmap transform)
>
>  ...
>
>  (keep pred))
>
>reducer
>
>init coll)
>
> Does that make sense, or am I crazy? :)
>
> ~Timothy Dean
>
> On Friday, May 26, 2017 at 3:10:15 AM UTC-6, Matching Socks wrote:
>>
>> With the overhead of threading, isn't the triumph of a transducer (no
>> seq allocations) rather subtle in the case of pmap?
>>
>>
>> At any rate!, as a point of interest, since you mentioned a quirk of
>> pmap's thread usage: It apparently has to do with whether the input
>> sequence is a
>> chunked sequence or not.
>>
>> Comparing two possible inputs
>>
>> user> (def c (into [] (range 50))) ;; chunked
>>
>> user> (def n (into '() (range 50))) ;; not chunked
>>
>> With pmap invoking a function that just returns the thread's name (and
>> takes some time, so as to keep its assigned thread busy enough not to
>> accept more tasks right away)
>>
>> user> (defn f [x] (Thread/sleep 22) (.getName (Thread/currentThread)))
>> #'user/f
>> user> (count (distinct (pmap f c)))
>> 32
>> user> (count (distinct (pmap f n)))
>> 7
>>
>> The test is not perfect because it does not show that all 32
>> threads were used *at once*. There were simply 32 distinct threads used
>> at one
>> point or another.  Nonetheless the difference between 7 and 32 is
>> suggestive.
>>
>> In this environment there are 4 "processors", so 32 is indeed more than
>> you might want.
>>
>> The docstring about pmap could be clearer about 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Goog

Re: pmap: transducer & chunking

[Timothy Dean]

You can also get an indication this way, I think:

user=> (defn f [x] (Thread/sleep 100) x)
#'user/f
user=> (time (doall (pmap f (range 32
"Elapsed time: 128.383719 msecs"
user=> (time (doall (pmap f (range 33
"Elapsed time: 201.462131 msecs"
user=> (time (doall (pmap f (range 64
"Elapsed time: 201.89915 msecs"
user=> (time (doall (pmap f (range 65
"Elapsed time: 301.711263 msecs"
user=> (time (doall (pmap f (range 96
"Elapsed time: 302.205999 msecs"
user=> (time (doall (pmap f (range 97
"Elapsed time: 402.236708 msecs"

Regarding motivation for having a pmap transducer, my own is mainly that it 
composes with other transducers. A major practical/implementation "triumph" 
of transducers may be the reduced garbage, but there is a benefit of 
simplified expression as well, since transducers encode transformation in a 
manner agnostic to many elements of the context of the transformation. In a 
project containing many transducers variously composed and consumed 
throughout, it may be that I wish to parallelize one portion of a 
transformation occurring in the middle of a composition of transducers. If 
so, I can't simply drop in clojure.core's pmap.

Instead I now must -- in the specific context of whatever higher-order 
transducing function I happen to be using -- break the composed transducers 
apart, generate a transitory sequence, pmap over that, and then proceed 
with transforming the temporary sequence. That is, in this case I'm not 
concerned so much with the resource overhead of swapping a transducer for a 
non-transducer, but the expressive overhead. Composition is elegant. My 
solutions with clojure.core's pmap are clunky. I'm not ruling out PEBCAK 
error, but a pmap transducer seems to me the "obvious" solution preserving 
compositional elegance.

For instance, a very simple example using transduce:

(transduce (comp (remove bad)   

 ...   
 
 (map transform)   
 
 ...   
 
 (keep pred))   

   reducer 
 
   init coll)   


must become something like:

(->> coll   

 (sequence (comp (remove bad)   

 ...)) 
 
 (pmap transform)   

 (transduce (comp ...   

  (keep pred)) 
 
reducer 

init))

But it could be as simple as:

(transduce (comp (remove bad)   

 ...   
 
 (pmap transform)   
 
 ...   
 
 (keep pred))   

   reducer 
 
   init coll)

Does that make sense, or am I crazy? :)

~Timothy Dean

On Friday, May 26, 2017 at 3:10:15 AM UTC-6, Matching Socks wrote:
>
> With the overhead of threading, isn't the triumph of a transducer (no
> seq allocations) rather subtle in the case of pmap?
>
>
> At any rate!, as a point of interest, since you mentioned a quirk of
> pmap's thread usage: It apparently has to do with whether the input 
> sequence is a
> chunked sequence or not.
>
> Comparing two possible inputs
>
> user> (def c (into [] (range 50))) ;; chunked
>
> user> (def n (into '() (range 50))) ;; not chunked
>
> With pmap invoking a function that just returns the thread's name (and
> takes some time, so as to keep its assigned thread busy enough not to
> accept more tasks right away)
>
> user> (defn f [x] (Thread/sleep 22) (.getName (Thread/currentThread)))
> #'user/f
> user> (count (distinct (pmap f c)))
> 32
> user> (count (distinct (pmap f n)))
> 7
>
> The test is not perfect because it does not show that all 32
> threads were used *at once*. There were simply 32 distinct threads used at 
> one
> point or another.  Nonetheless the difference between 7 and 32 is
> suggestive.
>
> In this environment there are 4 "processors", so 32 is indeed more than 
> you might want.
>
> The docstring about pmap could be clearer about this.
>
>

-- 
You received this message because you are subscribed to the Goog

Re: Beginner: let with Java object

[Christopher Howard]

I restarted the Emacs CIDER REPL, and now it seems to work fine. Maybe I
just don't understand how to use this CIDER REPL properly.

On 05/26/2017 07:58 AM, Gary Trakhman wrote:
> There shouldn't be a difference, I would suspect a typo in your file.
> 
> The error 'ClassCastException java.awt.image.BufferedImage cannot be cast to
> clojure.lang.IFn  tutorial.core/-main (core.clj:11)' would lead me to
> look for things like '(img)' where the object ends up in call position
> of the s-expression.
> 
> On Fri, May 26, 2017 at 11:54 AM Christopher Howard
> mailto:christopher.how...@qlfiles.net>>
> wrote:
> 
> When I run
> 
> tutorial.core> (let [img (new-image 32 32)] (set-pixel img 10 10 cyan)
> (show img))
> 
> from the REPL, this returns a javax.swing.JFrame object, and displays
> the frame and image as expected. However, if put the same in
> 
> (defn -main
>   "Generates image."
>   [& args]
>   (let [img (new-image 32 32)]
> (set-pixel img 10 10 cyan)
> (show img)))
> 
> in more core.clj, and run (-main) from the REPL, I get error
> 
> ClassCastException java.awt.image.BufferedImage cannot be cast to
> clojure.lang.IFn  tutorial.core/-main (core.clj:11)
> 
> Why the difference?
> 
> --
> https://qlfiles.net
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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.

-- 
https://qlfiles.net

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

[Alex Miller]

There was a build snafu with the version number so we have re-released this 
as [org.clojure/spec.alpha "0.1.123"]. 
No code changes, so effectively the same content.

On Friday, May 26, 2017 at 10:16:57 AM UTC-5, Alex Miller wrote:
>
> spec.alpha 0.1.109 is now available.
>
> Try it via:  [org.clojure/spec.alpha "0.1.109"]
>
> 0.1.109 includes the following changes:
>
>- CLJ-2153  - Docstring 
>for int-in-range? and int-in now mention fixed precision constraint
>- CLJ-2085  - Add the 
>top level spec and value to explain-data
>- CLJ-2076  - coll-of 
>and map-of should unform their elements
>- CLJ-2063  - report 
>explain errors in order from longest to shortest path
>- CLJ-2061  - Better 
>error message when exercise-fn called on fn without :args spec
>- CLJ-2059  - 
>explain-data should return resolved preds
>- CLJ-2057  - If :ret 
>spec is not supplied, use any?
>
>

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

[Gary Trakhman]

There shouldn't be a difference, I would suspect a typo in your file.

The error 'ClassCastException java.awt.image.BufferedImage cannot be cast to
clojure.lang.IFn  tutorial.core/-main (core.clj:11)' would lead me to look
for things like '(img)' where the object ends up in call position of the
s-expression.

On Fri, May 26, 2017 at 11:54 AM Christopher Howard <
christopher.how...@qlfiles.net> wrote:

> When I run
>
> tutorial.core> (let [img (new-image 32 32)] (set-pixel img 10 10 cyan)
> (show img))
>
> from the REPL, this returns a javax.swing.JFrame object, and displays
> the frame and image as expected. However, if put the same in
>
> (defn -main
>   "Generates image."
>   [& args]
>   (let [img (new-image 32 32)]
> (set-pixel img 10 10 cyan)
> (show img)))
>
> in more core.clj, and run (-main) from the REPL, I get error
>
> ClassCastException java.awt.image.BufferedImage cannot be cast to
> clojure.lang.IFn  tutorial.core/-main (core.clj:11)
>
> Why the difference?
>
> --
> https://qlfiles.net
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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.

Beginner: let with Java object

[Christopher Howard]

When I run

tutorial.core> (let [img (new-image 32 32)] (set-pixel img 10 10 cyan)
(show img))

from the REPL, this returns a javax.swing.JFrame object, and displays
the frame and image as expected. However, if put the same in

(defn -main
  "Generates image."
  [& args]
  (let [img (new-image 32 32)]
(set-pixel img 10 10 cyan)
(show img)))

in more core.clj, and run (-main) from the REPL, I get error

ClassCastException java.awt.image.BufferedImage cannot be cast to
clojure.lang.IFn  tutorial.core/-main (core.clj:11)

Why the difference?

-- 
https://qlfiles.net

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

[Alex Miller]

spec.alpha 0.1.109 is now available.

Try it via:  [org.clojure/spec.alpha "0.1.109"]

0.1.109 includes the following changes:

   - CLJ-2153  - Docstring 
   for int-in-range? and int-in now mention fixed precision constraint
   - CLJ-2085  - Add the top 
   level spec and value to explain-data
   - CLJ-2076  - coll-of and 
   map-of should unform their elements
   - CLJ-2063  - report 
   explain errors in order from longest to shortest path
   - CLJ-2061  - Better error 
   message when exercise-fn called on fn without :args spec
   - CLJ-2059  - explain-data 
   should return resolved preds
   - CLJ-2057  - If :ret spec 
   is not supplied, use any?

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

Re: [ANN] com.walmartlabs/lacinia 0.17.0

[Antoine Chesnais]

Awesome! Thank you so much

On Wednesday, 24 May 2017 17:58:35 UTC+2, Howard M. Lewis Ship wrote:
>
> Lacinia is an open-source implementation of Facebook's GraphQL 
> specification, in Clojure.
>
> GraphQL is an outstanding approach to getting diverse clients and servers 
> exchanging data cleanly and efficiently.
>
> The GitHub repository is https://github.com/walmartlabs/lacinia
>
> Documentation: http://lacinia.readthedocs.io/en/latest/
>
> This release adds:
>
> - Simplified default mapping from field name to map key
> - Ability to apply type tags to values that don't support metadata
> - Ability to decorate field resolvers, typically to adapt the return value 
> to Lacinia
> - API to identify the operations in the query before execution
> - API to identify selections to execute below a particular field, during 
> query execution
>
> -- 
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>

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

Re: Able to consume some nom modules, not others

[Christian Johansen]

I suspect that the problem is that the library I'm looking to fetch does 
not actually export anything. It only defines a polyfill. If there's any 
way to make that work I'd like to know.

Christian

fredag 26. mai 2017 10.59.20 UTC+2 skrev Christian Johansen følgende:
>
> I'm in need of an EventSource polyfill for my app to work in IE/Edge. So I 
> figured I'd take a look at the new npm support. I can get the left-pad 
> example from this post to work: 
> https://anmonteiro.com/2017/03/requiring-node-js-modules-from-clojurescript-namespaces/
>
> However, trying to build with the module I actually need does not work:
>
> (ns test.ns
>   (:require event-source-polyfill))
>
> Build with:
>
> (b/build "test/ns.cljs"
>{:optimizations :none
> :main 'test.ns
> :npm-deps {:event-source-polyfill "0.0.9"}
> :output-to "test.js"})
>
> Fails with:
>
> ExceptionInfo No such namespace: event-source-polyfill, could not locate 
> event_source_polyfill.cljs, event_source_polyfill.cljc, or Closure 
> namespace "event-source-polyfill"
>
> I can `require` the module from a Node repl just fine, so there's nothing 
> obviously wrong with the module.
>
> Any ideas?
>
> Christian
>

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

[Matching Socks]

With the overhead of threading, isn't the triumph of a transducer (no
seq allocations) rather subtle in the case of pmap?


At any rate!, as a point of interest, since you mentioned a quirk of
pmap's thread usage: It apparently has to do with whether the input 
sequence is a
chunked sequence or not.

Comparing two possible inputs

user> (def c (into [] (range 50))) ;; chunked

user> (def n (into '() (range 50))) ;; not chunked

With pmap invoking a function that just returns the thread's name (and
takes some time, so as to keep its assigned thread busy enough not to
accept more tasks right away)

user> (defn f [x] (Thread/sleep 22) (.getName (Thread/currentThread)))
#'user/f
user> (count (distinct (pmap f c)))
32
user> (count (distinct (pmap f n)))
7

The test is not perfect because it does not show that all 32
threads were used *at once*. There were simply 32 distinct threads used at 
one
point or another.  Nonetheless the difference between 7 and 32 is
suggestive.

In this environment there are 4 "processors", so 32 is indeed more than you 
might want.

The docstring about pmap could be clearer about 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.
For more options, visit https://groups.google.com/d/optout.

Able to consume some nom modules, not others

[Christian Johansen]

I'm in need of an EventSource polyfill for my app to work in IE/Edge. So I 
figured I'd take a look at the new npm support. I can get the left-pad 
example from this post to work: 
https://anmonteiro.com/2017/03/requiring-node-js-modules-from-clojurescript-namespaces/

However, trying to build with the module I actually need does not work:

(ns test.ns
  (:require event-source-polyfill))

Build with:

(b/build "test/ns.cljs"
   {:optimizations :none
:main 'test.ns
:npm-deps {:event-source-polyfill "0.0.9"}
:output-to "test.js"})

Fails with:

ExceptionInfo No such namespace: event-source-polyfill, could not locate 
event_source_polyfill.cljs, event_source_polyfill.cljc, or Closure 
namespace "event-source-polyfill"

I can `require` the module from a Node repl just fine, so there's nothing 
obviously wrong with the module.

Any ideas?

Christian

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