[ANN] Primitive Operator

[Phillip Lord]

This is the first alpha release of my new library! Comments welcome.

Clojure has an extensive system for dealing with numbers, including
error on overflow, or auto-promotion, defaulting to long and double data
types.

This is all well and good, but irritating if you need to implement an
algorithm which depends on ints overflowing for instance. While, clojure
provides functions for operating over ints, the names tend to be long
and wieldy, such as clojure.core/unchecked-int-add. Clojure is also
rather inconsistent; for example, the bit-shifting operators in Java are
not accessible in Clojure over ints.

This library provides accessible, easily named float and int functions
for Clojure. Where possible, functions with the same name as the
operators are provided as well as names (<< and left-shift). Three Java
operators are not valid symbols in clojure (~, % and ^), so just have
names. Short reader literals are also provided to simplify the creation
of ints and float.

(require '[primititve.operator.integer :as i])

(i/+ 10 10)
=> 20

(type (i/+ 10 10))
=> java.lang.Integer

(i/add 10 10)
=> 20

(i/not 10)
=> -11

(i/+ #p/i 10 #p/i 10)
=> 20


https://github.com/phillord/primitive-operator

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

[Nicola Mometto]

Hi Phillip,

I've had a very quick look at the code and I've spotted a few issues, here's my 
feedback:

1- all your functions will cause input args and return value to be boxed. 
There's a few ways to avoid it, none of which are particularly pretty. If your 
library is not worried about performance but just about behaviour then this is 
not a problem, if it is, I can guide you through ways to avoid boxing 
(primitive type hinting of ints and floats is unfortunately not an option).

2- defining a var called &, while technically valid, is not a good idea. 
syntax-quote will not resolve vars named & to avoid collision with the & rest 
syntax in destructuring, so I'd consider using a different name

3- clojure/core encourages libraries to provide "sufficiently uniquely named 
data literals", p/i and p/f to me while convenient don't seem unique enough to 
be safely included in a library. This one could be detabatable

Nicola

> On 3 Jul 2017, at 10:44, Phillip Lord  wrote:
> 
> 
> 
> This is the first alpha release of my new library! Comments welcome.
> 
> Clojure has an extensive system for dealing with numbers, including
> error on overflow, or auto-promotion, defaulting to long and double data
> types.
> 
> This is all well and good, but irritating if you need to implement an
> algorithm which depends on ints overflowing for instance. While, clojure
> provides functions for operating over ints, the names tend to be long
> and wieldy, such as clojure.core/unchecked-int-add. Clojure is also
> rather inconsistent; for example, the bit-shifting operators in Java are
> not accessible in Clojure over ints.
> 
> This library provides accessible, easily named float and int functions
> for Clojure. Where possible, functions with the same name as the
> operators are provided as well as names (<< and left-shift). Three Java
> operators are not valid symbols in clojure (~, % and ^), so just have
> names. Short reader literals are also provided to simplify the creation
> of ints and float.
> 
> (require '[primititve.operator.integer :as i])
> 
> (i/+ 10 10)
> => 20
> 
> (type (i/+ 10 10))
> => java.lang.Integer
> 
> (i/add 10 10)
> => 20
> 
> (i/not 10)
> => -11
> 
> (i/+ #p/i 10 #p/i 10)
> => 20
> 
> 
> https://github.com/phillord/primitive-operator
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because 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.


signature.asc
Description: Message signed with OpenPGP

Re: [ANN] Primitive Operator

[Max Penet]

This seems quite similar to https://github.com/ztellman/primitive-math. Did 
you know about it?

On Monday, July 3, 2017 at 11:44:40 AM UTC+2, Phillip Lord wrote:
>
>
>
> This is the first alpha release of my new library! Comments welcome. 
>
> Clojure has an extensive system for dealing with numbers, including 
> error on overflow, or auto-promotion, defaulting to long and double data 
> types. 
>
> This is all well and good, but irritating if you need to implement an 
> algorithm which depends on ints overflowing for instance. While, clojure 
> provides functions for operating over ints, the names tend to be long 
> and wieldy, such as clojure.core/unchecked-int-add. Clojure is also 
> rather inconsistent; for example, the bit-shifting operators in Java are 
> not accessible in Clojure over ints. 
>
> This library provides accessible, easily named float and int functions 
> for Clojure. Where possible, functions with the same name as the 
> operators are provided as well as names (<< and left-shift). Three Java 
> operators are not valid symbols in clojure (~, % and ^), so just have 
> names. Short reader literals are also provided to simplify the creation 
> of ints and float. 
>
> (require '[primititve.operator.integer :as i]) 
>
> (i/+ 10 10) 
> => 20 
>
> (type (i/+ 10 10)) 
> => java.lang.Integer 
>
> (i/add 10 10) 
> => 20 
>
> (i/not 10) 
> => -11 
>
> (i/+ #p/i 10 #p/i 10) 
> => 20 
>
>
> https://github.com/phillord/primitive-operator 
>
>

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

Simultaneous development of a clojure project and an internal util library

[István Dévai]

Hi all,

How to maintain an internal tools library parallel to writing a Clojure 
app? Having a separate Emacs open with that project + releasing + 
installing it after every small change seems to be a big hassle to me. What 
are the best practices of this? For example adding the source path of the 
library to the srcpath of the dependent project? (only in DEV profile of 
course). I'm looking for a setup that's plays nice with Leiningen, Emacs, 
Cider and Clojurescript+Figwheel. Also it would be nice not to have hard 
coded things like workstation-dependent paths in project.clj and such. 
Also, preferably when I build a package (uberjar, etc.) of my project, that 
should rely on a released version of the util library.

Thanks for help :)

Istvan

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

[Tomasz Sulej]

this article may be helpful:
http://insideclojure.org/2014/12/15/warn-on-boxed/

On 3 July 2017 at 13:36, Tomasz Sulej  wrote:

> When you decide to work with longs and doubles you can achieve the same in
> pure clojure
> Just add primitive type hints and (set! *unchecked-math* true).
> (to see if you have boxed operations add (set! *unchecked-math*
> :warn-on-boxed))
>
> (set! *unchecked-math* :warn-on-boxed) ;; set math to be unchecked and
> warn if boxed operations are used
>
> (defn add ^long [^long a ^long b] (+ a b))
> (defn not ^long [^long a] (bit-not a))
>
> (add 10 10)
> ;; => 20
>
> (not 10)
> ;; => -11
>
> (type (add 10 10))
> ;; => java.lang.Long
>
> On 3 July 2017 at 11:44, Phillip Lord 
> wrote:
>
>>
>>
>> This is the first alpha release of my new library! Comments welcome.
>>
>> Clojure has an extensive system for dealing with numbers, including
>> error on overflow, or auto-promotion, defaulting to long and double data
>> types.
>>
>> This is all well and good, but irritating if you need to implement an
>> algorithm which depends on ints overflowing for instance. While, clojure
>> provides functions for operating over ints, the names tend to be long
>> and wieldy, such as clojure.core/unchecked-int-add. Clojure is also
>> rather inconsistent; for example, the bit-shifting operators in Java are
>> not accessible in Clojure over ints.
>>
>> This library provides accessible, easily named float and int functions
>> for Clojure. Where possible, functions with the same name as the
>> operators are provided as well as names (<< and left-shift). Three Java
>> operators are not valid symbols in clojure (~, % and ^), so just have
>> names. Short reader literals are also provided to simplify the creation
>> of ints and float.
>>
>> (require '[primititve.operator.integer :as i])
>>
>> (i/+ 10 10)
>> => 20
>>
>> (type (i/+ 10 10))
>> => java.lang.Integer
>>
>> (i/add 10 10)
>> => 20
>>
>> (i/not 10)
>> => -11
>>
>> (i/+ #p/i 10 #p/i 10)
>> => 20
>>
>>
>> https://github.com/phillord/primitive-operator
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because 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: [ANN] Primitive Operator

[Phillip Lord]

Nicola Mometto  writes:

> Hi Phillip,
>
> I've had a very quick look at the code and I've spotted a few issues,
> here's my feedback:
>
> 1- all your functions will cause input args and return value to be
> boxed. There's a few ways to avoid it, none of which are particularly
> pretty. If your library is not worried about performance but just
> about behaviour then this is not a problem, if it is, I can guide you
> through ways to avoid boxing (primitive type hinting of ints and
> floats is unfortunately not an option).

I'd be happy to get that information. Performance is not really my
concern here, rather it is ensuring that I can replicate int/float based
algorithms in Clojure.

Having said that, all things being equal, performance is better than not.


> 2- defining a var called &, while technically valid, is not a good
> idea. syntax-quote will not resolve vars named & to avoid collision
> with the & rest syntax in destructuring, so I'd consider using a
> different name

Ah, yes. Clojure really sucks up all those handy punctuation characters.


> 3- clojure/core encourages libraries to provide "sufficiently uniquely
> named data literals", p/i and p/f to me while convenient don't seem
> unique enough to be safely included in a library. This one could be
> detabatable

Yeah, I was worried about that. If they are longer, though, it defeats
the point.

#primitive/int 10
(int 10)

Phil

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

[Phillip Lord]

Nicola Mometto  writes:

> Hi Phillip,
>
> I've had a very quick look at the code and I've spotted a few issues,
> here's my feedback:
>
> 1- all your functions will cause input args and return value to be
> boxed. There's a few ways to avoid it, none of which are particularly
> pretty. If your library is not worried about performance but just
> about behaviour then this is not a problem, if it is, I can guide you
> through ways to avoid boxing (primitive type hinting of ints and
> floats is unfortunately not an option).

I'd be happy to get that information. Performance is not really my
concern here, rather it is ensuring that I can replicate int/float based
algorithms in Clojure.

Having said that, all things being equal, performance is better than not.


> 2- defining a var called &, while technically valid, is not a good
> idea. syntax-quote will not resolve vars named & to avoid collision
> with the & rest syntax in destructuring, so I'd consider using a
> different name

Ah, yes. Clojure really sucks up all those handy punctuation characters.


> 3- clojure/core encourages libraries to provide "sufficiently uniquely
> named data literals", p/i and p/f to me while convenient don't seem
> unique enough to be safely included in a library. This one could be
> detabatable

Yeah, I was worried about that. If they are longer, though, it defeats
the point.

#primitive/int 10
(int 10)

Phil

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

[Phillip Lord]

Yes, but it doesn't supoort ints for all the operators, as far as I can
tell.

You are right, though, perhaps I should look at this also.

Phil

Max Penet  writes:

> This seems quite similar to https://github.com/ztellman/primitive-math. Did 
> you know about it?
>
> On Monday, July 3, 2017 at 11:44:40 AM UTC+2, Phillip Lord wrote:
>>
>>
>>
>> This is the first alpha release of my new library! Comments welcome. 
>>
>> Clojure has an extensive system for dealing with numbers, including 
>> error on overflow, or auto-promotion, defaulting to long and double data 
>> types. 
>>
>> This is all well and good, but irritating if you need to implement an 
>> algorithm which depends on ints overflowing for instance. While, clojure 
>> provides functions for operating over ints, the names tend to be long 
>> and wieldy, such as clojure.core/unchecked-int-add. Clojure is also 
>> rather inconsistent; for example, the bit-shifting operators in Java are 
>> not accessible in Clojure over ints. 
>>
>> This library provides accessible, easily named float and int functions 
>> for Clojure. Where possible, functions with the same name as the 
>> operators are provided as well as names (<< and left-shift). Three Java 
>> operators are not valid symbols in clojure (~, % and ^), so just have 
>> names. Short reader literals are also provided to simplify the creation 
>> of ints and float. 
>>
>> (require '[primititve.operator.integer :as i]) 
>>
>> (i/+ 10 10) 
>> => 20 
>>
>> (type (i/+ 10 10)) 
>> => java.lang.Integer 
>>
>> (i/add 10 10) 
>> => 20 
>>
>> (i/not 10) 
>> => -11 
>>
>> (i/+ #p/i 10 #p/i 10) 
>> => 20 
>>
>>
>> https://github.com/phillord/primitive-operator 

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

[Tommi Reiman]

https://github.com/metosin/spec-tools

spec-tools is is a small Clojure(Script) library adding some batteries for 
clojure.spec, including: Schema-like runtime coercion, Spec visitors, JSON 
Schema generation and macro-free data-specs.

0.3.0 adds support for Swagger2 Schema generation, merged from 
metosin/spec-swagger. As a reference implementation, compojure-api 2.0.0-alpha5 
provides clojure.spec as an alternative coercion & swagger implementation to 
Plumatic Schema. 

Blog post about it:

http://www.metosin.fi/blog/clojure-spec-with-ring-and-swagger/

Example repo of c-api with spec:

https://github.com/metosin/c2

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

[Howard Lewis Ship]

The checkouts feature of Leiningen exists to support this scenario.

https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies

On Sun, Jul 2, 2017 at 11:40 AM, István Dévai 
wrote:

> Hi all,
>
> How to maintain an internal tools library parallel to writing a Clojure
> app? Having a separate Emacs open with that project + releasing +
> installing it after every small change seems to be a big hassle to me. What
> are the best practices of this? For example adding the source path of the
> library to the srcpath of the dependent project? (only in DEV profile of
> course). I'm looking for a setup that's plays nice with Leiningen, Emacs,
> Cider and Clojurescript+Figwheel. Also it would be nice not to have hard
> coded things like workstation-dependent paths in project.clj and such.
> Also, preferably when I build a package (uberjar, etc.) of my project, that
> should rely on a released version of the util library.
>
> Thanks for help :)
>
> Istvan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because 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.
>



-- 
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: Simultaneous development of a clojure project and an internal util library

[Vitalie Spinu]

Leningen has checkout dependencies for this purpose:

  
https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies


  Vitalie

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

core.async/close! locks on chans with pending transforms

[Vitalie Spinu]

Hi,

Async/close! causes deadlocks if its reducer is stalled (e.g. waits for an 
event from
 another chan). 

Consider:

  (let [d (chan)
s (chan 1 (map (fn [v]
 (println "this:" v)
 (println "from d:" (! s 1))
(Thread/sleep 100)
(println "closing s")
(async/close! s))

  ;; =>
  ;; this: 1
  ;; closing s
  ;; .. [lock]

This is caused by (.lock mutex) in close! method here:

   
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L247

I wonder if it is there "by design" or a bug. IMO it makes little sense to 
lock
external code simply because chan's reducer function is stalled. Just as 
close!
doesn't lock on pending puts it shouldn't stall on pending "half-puts".

I need this for systems with inter-dependent chans. In the above example
component 'd' is a dependency of 's', then system will halt in reverse 
order of
dependencies closing `s` first.

Thank you,

   Vitalie

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

[Timothy Baldridge]

Transducers on channels lock the channel while they are running. This is by
design. So yes, the side-effect of this means that no other operation
(puts, takes or closes) can succeed while the transducer is running.

So the short answer is: If you have code that can take awhile to run, don't
put it in a channel transducer, put it in `async/pipeline(-blocking)`
instead.

On Mon, Jul 3, 2017 at 12:03 PM, Vitalie Spinu  wrote:

>
> Hi,
>
> Async/close! causes deadlocks if its reducer is stalled (e.g. waits for an
> event from
>  another chan).
>
> Consider:
>
>   (let [d (chan)
> s (chan 1 (map (fn [v]
>  (println "this:" v)
>  (println "from d:" (  v)))]
> (go (>! s 1))
> (Thread/sleep 100)
> (println "closing s")
> (async/close! s))
>
>   ;; =>
>   ;; this: 1
>   ;; closing s
>   ;; .. [lock]
>
> This is caused by (.lock mutex) in close! method here:
>
>https://github.com/clojure/core.async/blob/master/src/
> main/clojure/clojure/core/async/impl/channels.clj#L247
>
> I wonder if it is there "by design" or a bug. IMO it makes little sense to
> lock
> external code simply because chan's reducer function is stalled. Just as
> close!
> doesn't lock on pending puts it shouldn't stall on pending "half-puts".
>
> I need this for systems with inter-dependent chans. In the above example
> component 'd' is a dependency of 's', then system will halt in reverse
> order of
> dependencies closing `s` first.
>
> Thank you,
>
>Vitalie
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

[Kevin Downey]

On 07/03/2017 11:03 AM, Vitalie Spinu wrote:


Hi,

Async/close! causes deadlocks if its reducer is stalled (e.g. waits for 
an event from

  another chan).

Consider:

   (let [d (chan)
 s (chan 1 (map (fn [v]
  (println "this:" v)
  (println "from d:" (

Discussion of locks aside, doing blocking operations like io or >!! or basically anything that looks like it blocks and isn't >! or is a very bad idea in a transducer on a channel. You will (eventually) 
block the threadpool and get deadlocks. If you must use a transducer 
that does blocking operations, you should checkout pipeline-blocking. 
pipeline-blocking has a slightly convoluted internal structure exactly 
to avoid blocking operations running on the go block threadpool.


The transducer will be executed when publishing to a channel(this is a 
little bit squishy, sometimes publishing to a channel doesn't actually 
publish because the channel is full and a callback is registered to do 
the publishing the next time a consumer takes), if you publish to a 
channel with a transducer that blocks from a go-block, then you are 
blocking that go block which is bad.



  v)))]
 (go (>! s 1))
 (Thread/sleep 100)
 (println "closing s")
 (async/close! s))

   ;; =>
   ;; this: 1
   ;; closing s
   ;; .. [lock]

This is caused by (.lock mutex) in close! method here:


https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L247


I wonder if it is there "by design" or a bug. IMO it makes little sense 
to lock
external code simply because chan's reducer function is stalled. Just as 
close!

doesn't lock on pending puts it shouldn't stall on pending "half-puts".

I need this for systems with inter-dependent chans. In the above example
component 'd' is a dependency of 's', then system will halt in reverse 
order of

dependencies closing `s` first.

Thank you,

Vitalie

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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because 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.



--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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

[Vitalie Spinu]

> the side-effect of this means that no other operation (puts, takes or 
closes)

Is there a deeper reason for this beside the ease of implementation?

 If chan is buffered I still fail to see why should close and take 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.
For more options, visit https://groups.google.com/d/optout.

Re: core.async/close! locks on chans with pending transforms

[Vitalie Spinu]

On Monday, 3 July 2017 22:48:40 UTC+2, red...@gmail.com wrote:
>
>
> Discussion of locks aside, doing blocking operations like io or   >!! or basically anything that looks like it blocks and isn't >! or  is a very bad idea in a transducer on a channel. You will (eventually) 
> block the threadpool and get deadlocks. 
>


Is this the limitation in general or only when I use the chan with blocking 
transducer withing a go block?  Transducers are not run on a go block, are 
they?

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

[Kevin Downey]

On 07/03/2017 03:12 PM, Vitalie Spinu wrote:




On Monday, 3 July 2017 22:48:40 UTC+2, red...@gmail.com wrote:


Discussion of locks aside, doing blocking operations like io or !! or basically anything that looks like it blocks and isn't >!
or Is this the limitation in general or only when I use the chan with 
blocking transducer withing a go block?  Transducers are not run on a go 
block, are they?




It is kind of complicated, and I haven't traced through everything in 
channels.clj recently, but assume transducers are not magic, the 
computation has to occur on some real thread some where, and the best 
threads available to do that are the consumer thread and the producer 
thread. If those threads are both executing go blocks, and you have a 
transducer doing blocking stuff on a channel they operate on, you may 
not be technically "blocking" in the go block, but the channel machinery 
is now blocking before it yields control back to the go  block. Putting 
blocking operations in a transducer then operating on the channel from 
go blocks turns `!>` and '(just park go blocks), in to operations that do block a whole OS thread, 
of which the core.async threadpool that go blocks execute on only has 8 
by default.


There is this sort of dance where control is handed back and forth 
between channels and go blocks without tying up a thread. When you 
introduce blocking in to the channel machinery (by making the channel 
execute a blocking operation as things are produced or consumed) then 
the dance stops and the thread waits.



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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because 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.



--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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

Clojure versions used by java.jdbc users

[Sean Corfield]

I ran a short survey for java.jdbc users to gauge feeling about dropping 
support for Clojure versions prior to 1.7 (so I could add reducible queries 
without worrying about CollReduce vs IReduceInit vs IReduce).

 

So far, 68 people have taken the survey and the results are overwhelmingly in 
favor of only supporting Clojure 1.7+ -- so I thought I’d share the results 
with a larger audience, just for information:

 

    https://www.surveymonkey.com/results/SM-CJY2YMHP/

 

Of 68 respondents, only one is still on Clojure 1.7, none are on earlier 
versions. I was expecting a few more 1.7 responses – and I was not expecting 
35% already on Clojure 1.9 alpha builds!

 

If you use java.jdbc and haven’t already taken the survey and want your voice 
heard:

 

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

 

Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN

An Architect's View -- http://corfield.org/

 

"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: core.async/close! locks on chans with pending transforms

[Timothy Baldridge]

A big reason they have to be run inside the lock is that they have to
operate in the context of the channel.

For example:

(chan (take 10))

Firstly we must recognize that transducer instances are *not* thread safe.
They should only ever be executed by one thread at a time. But channels
allow multiple puts and takes. Also channels are not processes, they are
simply rather complex lists with locks around them.

This means, if you want to execute take correctly you must ensure that only
one thread executes the take instance at one time, since channels already
operate via a channel-level lock, it makes sense to run the transducer
inside the channels' lock.

But that's also why it's always been recommended to stick with simple, non
cpu-intensive, non blocking operations in channel transducers.

Timothy

On Mon, Jul 3, 2017 at 4:30 PM, Kevin Downey  wrote:

> On 07/03/2017 03:12 PM, Vitalie Spinu wrote:
>
>>
>>
>>
>> On Monday, 3 July 2017 22:48:40 UTC+2, red...@gmail.com wrote:
>>
>>
>> Discussion of locks aside, doing blocking operations like io or >   >!! or basically anything that looks like it blocks and isn't >!
>> or > is a very bad idea in a transducer on a channel. You will (eventually)
>> block the threadpool and get deadlocks.
>>
>>
>>
>> Is this the limitation in general or only when I use the chan with
>> blocking transducer withing a go block?  Transducers are not run on a go
>> block, are they?
>>
>>
> It is kind of complicated, and I haven't traced through everything in
> channels.clj recently, but assume transducers are not magic, the
> computation has to occur on some real thread some where, and the best
> threads available to do that are the consumer thread and the producer
> thread. If those threads are both executing go blocks, and you have a
> transducer doing blocking stuff on a channel they operate on, you may not
> be technically "blocking" in the go block, but the channel machinery is now
> blocking before it yields control back to the go  block. Putting blocking
> operations in a transducer then operating on the channel from go blocks
> turns `!>` and ' blocks), in to operations that do block a whole OS thread, of which the
> core.async threadpool that go blocks execute on only has 8 by default.
>
> There is this sort of dance where control is handed back and forth between
> channels and go blocks without tying up a thread. When you introduce
> blocking in to the channel machinery (by making the channel execute a
> blocking operation as things are produced or consumed) then the dance stops
> and the thread waits.
>
> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because 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 > clojure+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: Simultaneous development of a clojure project and an internal util library

[Daniel Compton]

By the way, if you do use checkouts with Figwheel, be aware of
https://github.com/bhauman/lein-figwheel/issues/9. Currently you need to
add the path to the checkout project into your cljsbuild :source-paths.

On Tue, Jul 4, 2017 at 8:16 AM Vitalie Spinu  wrote:

>
> Leningen has checkout dependencies for this purpose:
>
>
> https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies
>
>
>
>   Vitalie
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because 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.