Re: Dependency conflict between parkour [0.6.2] and inflections [0.9.13]

[Sunil S Nandihalli]

I was wrong about :exclusions not working, the code was crashing due to
some other reason. :exclusions worked as expected. Thanks for making me
take another look at what was happening.

Regards,
Sunil.

On Mon, Feb 23, 2015 at 10:43 PM, Jeremy Heiler 
wrote:

> On Mon, Feb 23, 2015 at 11:22 AM, Sunil S Nandihalli <
> sunil.nandiha...@gmail.com> wrote:
>
>> I tried putting the above in :exclusions in the project.clj with no
>> success.
>
>
> What do you mean by "with no success"? Can you show how you modified your
> project.clj?
>
> --
> 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: can binary arithmetic guru help improve these "bitmasking" ops?

[Leif]

Hello, again.  Just wanted to clarify, in case the below speedup didn't 
seem worth it.  That 6% speedup was in the top-level uuid/v1 function, not 
mask!

I'll try to give a clearer picture of my suggestion:  Consider

(let [bitmask (mask 8 (* 8 (dec 7)))
  off (mask-offset bitmask)
  moff (>>> bitmask off)]
  (defn ^long ldb6 [^long num]
(bit-and moff (bit-shift-right num off

This function gives a speedup of 370% over calling (ldb (mask ...) num), 
because you don't really need to calculate the mask, offset, or offset-mask 
at runtime.

I envisioned writing a macro that would write the function

(let [bitmask0 (mask 8 (* 8 (dec 1)))
  off0 (mask-offset bitmask0)
  moff0 (>>> bitmask0 off0)
  ...]
  (defn ^long ldb-j [^long j ^long num]
(case j
  0 (bit-and moff0 (bit-shift-right num off0))
  ...
  7 (bit-and moff7 (bit-shift-right num off7))
  (throw IAE

Or just write the unrolled version by hand.  I think you would get a fair 
speedup if you did that for ldb and dpb.

Hoping that's clearer,
Leif

On Monday, February 23, 2015 at 9:20:12 PM UTC-5, Leif wrote:
>
>
> If you're trying to squeeze every last bit of performance, and you don't 
> mind some messiness and macros, I noticed that many of these functions are 
> called with only a few values in the first argument.  So you are doing a 
> lot of bit-fiddling at runtime that could be done at compile-time.  So you 
> could partially evaluate (i.e. unroll, i.e. ~make lookup table for) 'ldb' 
> and 'dpb' for the 8 or 9 different first arguments you actually call it 
> with.  I unrolled your 'mask' fn into a 8-way case statement, and got about 
> 6% speedup.
>
> --Leif
>
> On Monday, February 23, 2015 at 1:59:32 PM UTC-5, danl...@gmail.com wrote:
>>
>> So, much of the pain involved in handling UUID's correctly on the JVM
>> relates to the fact that there is no primitive unsigned numeric type
>> that can represent the full range of possible values of the msb and lsb.
>> Ie., we need to always deal with the unpleasant "am I negative?" approach 
>> to
>> reading (writing) that 64th bit.  To avoid the complexity of all the 
>> edge cases, we encapsulate the basic primitives of working with
>> unsigned numbers entirely within the abstraction of "mask" and
>> "mask offset".  Using these, we built the two fundamental bitwise 
>> operations
>> that are used for most of the UUID calculation: ldb (load-byte) and
>> dpb (deposit-byte).
>>
>> This scrap of code from my clj-uuid.bitmop library is extremely useful 
>> for working 
>> with "unsigned" long/binary values (analogously to how one might using 
>> the common-lisp
>> functions by the same name).  And, it has been "good enough" to do pretty 
>> well
>> so far in terms of performance.  But I'm sure that there are gifted 
>> binariticians
>> in the audience that can improve this. (Note, the namespace uses 
>> ztellman/primitive-math
>> which changes the semantics of some arithmetic operations and some type 
>> hinting.  Also
>> some of the 'let's are there for that reason. It may be helpful to refer 
>> to the link.
>>
>> ;;; 
>> https://github.com/danlentz/clj-uuid/blob/master/src/clj_uuid/bitmop.clj
>>
>>
>> (defn ^long expt2 [^long pow]
>>   (bit-set 0 pow))
>>
>> (defn ^long mask [^long width ^long offset]
>>   (if (< (+ width offset) 64)
>> (bit-shift-left (dec (bit-shift-left 1 width)) offset)
>> (let [x (expt2 offset)]
>>   (bit-and-not -1 (dec ^long x)
>>
>> (declare ^long mask-offset ^long mask-width)
>>
>> (defn ^long mask-offset [^long m]
>>   (cond
>> (zero? m) 0
>> (neg?  m) (- 64 ^long (mask-width m))
>> :else (loop [c 0]
>> (if (pos? (bit-and 1 (bit-shift-right m c)))
>>   c
>>   (recur (inc c))
>>
>> (defn ^long mask-width [^long m]
>>   (if (neg? m)
>> (let [x (mask-width (- (inc m)))]
>>   (- 64  ^long x))
>> (loop [m (bit-shift-right m (mask-offset m)) c 0]
>>   (if (zero? (bit-and 1 (bit-shift-right m c)))
>> c
>> (recur m (inc c))
>>
>> (defn ^long ldb
>>   "Load Byte"
>>   [^long bitmask ^long num]
>>   (let [off (mask-offset bitmask)]
>> (bit-and (>>> bitmask ^long off)
>>   (bit-shift-right num off
>>
>> (defn ^long dpb
>>   "Deposit Byte"
>>   [^long bitmask ^long num ^long value]
>>   (bit-or (bit-and-not num bitmask)
>> (bit-and bitmask
>>   (bit-shift-left value (mask-offset bitmask)
>>
>

-- 
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 u

Re: can binary arithmetic guru help improve these "bitmasking" ops?

[Leif]

If you're trying to squeeze every last bit of performance, and you don't 
mind some messiness and macros, I noticed that many of these functions are 
called with only a few values in the first argument.  So you are doing a 
lot of bit-fiddling at runtime that could be done at compile-time.  So you 
could partially evaluate (i.e. unroll, i.e. ~make lookup table for) 'ldb' 
and 'dpb' for the 8 or 9 different first arguments you actually call it 
with.  I unrolled your 'mask' fn into a 8-way case statement, and got about 
6% speedup.

--Leif

On Monday, February 23, 2015 at 1:59:32 PM UTC-5, danl...@gmail.com wrote:
>
> So, much of the pain involved in handling UUID's correctly on the JVM
> relates to the fact that there is no primitive unsigned numeric type
> that can represent the full range of possible values of the msb and lsb.
> Ie., we need to always deal with the unpleasant "am I negative?" approach 
> to
> reading (writing) that 64th bit.  To avoid the complexity of all the 
> edge cases, we encapsulate the basic primitives of working with
> unsigned numbers entirely within the abstraction of "mask" and
> "mask offset".  Using these, we built the two fundamental bitwise 
> operations
> that are used for most of the UUID calculation: ldb (load-byte) and
> dpb (deposit-byte).
>
> This scrap of code from my clj-uuid.bitmop library is extremely useful for 
> working 
> with "unsigned" long/binary values (analogously to how one might using the 
> common-lisp
> functions by the same name).  And, it has been "good enough" to do pretty 
> well
> so far in terms of performance.  But I'm sure that there are gifted 
> binariticians
> in the audience that can improve this. (Note, the namespace uses 
> ztellman/primitive-math
> which changes the semantics of some arithmetic operations and some type 
> hinting.  Also
> some of the 'let's are there for that reason. It may be helpful to refer 
> to the link.
>
> ;;; 
> https://github.com/danlentz/clj-uuid/blob/master/src/clj_uuid/bitmop.clj
>
>
> (defn ^long expt2 [^long pow]
>   (bit-set 0 pow))
>
> (defn ^long mask [^long width ^long offset]
>   (if (< (+ width offset) 64)
> (bit-shift-left (dec (bit-shift-left 1 width)) offset)
> (let [x (expt2 offset)]
>   (bit-and-not -1 (dec ^long x)
>
> (declare ^long mask-offset ^long mask-width)
>
> (defn ^long mask-offset [^long m]
>   (cond
> (zero? m) 0
> (neg?  m) (- 64 ^long (mask-width m))
> :else (loop [c 0]
> (if (pos? (bit-and 1 (bit-shift-right m c)))
>   c
>   (recur (inc c))
>
> (defn ^long mask-width [^long m]
>   (if (neg? m)
> (let [x (mask-width (- (inc m)))]
>   (- 64  ^long x))
> (loop [m (bit-shift-right m (mask-offset m)) c 0]
>   (if (zero? (bit-and 1 (bit-shift-right m c)))
> c
> (recur m (inc c))
>
> (defn ^long ldb
>   "Load Byte"
>   [^long bitmask ^long num]
>   (let [off (mask-offset bitmask)]
> (bit-and (>>> bitmask ^long off)
>   (bit-shift-right num off
>
> (defn ^long dpb
>   "Deposit Byte"
>   [^long bitmask ^long num ^long value]
>   (bit-or (bit-and-not num bitmask)
> (bit-and bitmask
>   (bit-shift-left value (mask-offset bitmask)
>

-- 
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: can binary arithmetic guru help improve these "bitmasking" ops?

[Dan Lentz]

Actually, yes, your code is exactly what I was looking for. Your
"countTrailingZeros" is what I'm calling "mask-offset".  Very helpful,
thank you.  Although, I gotta say, I'm still gonna do it in Clojure.  This
is supposed to be programming for enjoyment! :)

Best,
Dan

On Mon, Feb 23, 2015 at 8:39 PM, Mikera 
wrote:

> Bit operations is one area where I'd actually recommend writing in Java
> before wrapping in Clojure for several reasons:
> 1) You can port / compare directly with canonical C implementation
> 2) You can be pretty sure of avoiding boxing / other overheads by sticking
> to Java primitive maths
> 3) Clojure still doesn't quite have the full range of bitwise
> functionality as far as I'm aware
>
> Feel free to use any of my Java bitwise code, if helpful:
>
> https://github.com/mikera/mikera/blob/master/src/main/java/mikera/util/Bits.java
>
>
> On Tuesday, 24 February 2015 02:59:32 UTC+8, danl...@gmail.com wrote:
>>
>> So, much of the pain involved in handling UUID's correctly on the JVM
>> relates to the fact that there is no primitive unsigned numeric type
>> that can represent the full range of possible values of the msb and lsb.
>> Ie., we need to always deal with the unpleasant "am I negative?" approach
>> to
>> reading (writing) that 64th bit.  To avoid the complexity of all the
>> edge cases, we encapsulate the basic primitives of working with
>> unsigned numbers entirely within the abstraction of "mask" and
>> "mask offset".  Using these, we built the two fundamental bitwise
>> operations
>> that are used for most of the UUID calculation: ldb (load-byte) and
>> dpb (deposit-byte).
>>
>> This scrap of code from my clj-uuid.bitmop library is extremely useful
>> for working
>> with "unsigned" long/binary values (analogously to how one might using
>> the common-lisp
>> functions by the same name).  And, it has been "good enough" to do pretty
>> well
>> so far in terms of performance.  But I'm sure that there are gifted
>> binariticians
>> in the audience that can improve this. (Note, the namespace uses
>> ztellman/primitive-math
>> which changes the semantics of some arithmetic operations and some type
>> hinting.  Also
>> some of the 'let's are there for that reason. It may be helpful to refer
>> to the link.
>>
>> ;;; https://github.com/danlentz/clj-uuid/blob/master/src/clj_
>> uuid/bitmop.clj
>>
>>
>> (defn ^long expt2 [^long pow]
>>   (bit-set 0 pow))
>>
>> (defn ^long mask [^long width ^long offset]
>>   (if (< (+ width offset) 64)
>> (bit-shift-left (dec (bit-shift-left 1 width)) offset)
>> (let [x (expt2 offset)]
>>   (bit-and-not -1 (dec ^long x)
>>
>> (declare ^long mask-offset ^long mask-width)
>>
>> (defn ^long mask-offset [^long m]
>>   (cond
>> (zero? m) 0
>> (neg?  m) (- 64 ^long (mask-width m))
>> :else (loop [c 0]
>> (if (pos? (bit-and 1 (bit-shift-right m c)))
>>   c
>>   (recur (inc c))
>>
>> (defn ^long mask-width [^long m]
>>   (if (neg? m)
>> (let [x (mask-width (- (inc m)))]
>>   (- 64  ^long x))
>> (loop [m (bit-shift-right m (mask-offset m)) c 0]
>>   (if (zero? (bit-and 1 (bit-shift-right m c)))
>> c
>> (recur m (inc c))
>>
>> (defn ^long ldb
>>   "Load Byte"
>>   [^long bitmask ^long num]
>>   (let [off (mask-offset bitmask)]
>> (bit-and (>>> bitmask ^long off)
>>   (bit-shift-right num off
>>
>> (defn ^long dpb
>>   "Deposit Byte"
>>   [^long bitmask ^long num ^long value]
>>   (bit-or (bit-and-not num bitmask)
>> (bit-and bitmask
>>   (bit-shift-left value (mask-offset bitmask)
>>
>  --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/XIN2ZerhIcI/unsubscribe.
> To unsubscribe from this group and all its topics, 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 grou

Re: can binary arithmetic guru help improve these "bitmasking" ops?

[Mikera]

Bit operations is one area where I'd actually recommend writing in Java 
before wrapping in Clojure for several reasons:
1) You can port / compare directly with canonical C implementation
2) You can be pretty sure of avoiding boxing / other overheads by sticking 
to Java primitive maths
3) Clojure still doesn't quite have the full range of bitwise functionality 
as far as I'm aware

Feel free to use any of my Java bitwise code, if helpful:
https://github.com/mikera/mikera/blob/master/src/main/java/mikera/util/Bits.java

On Tuesday, 24 February 2015 02:59:32 UTC+8, danl...@gmail.com wrote:
>
> So, much of the pain involved in handling UUID's correctly on the JVM
> relates to the fact that there is no primitive unsigned numeric type
> that can represent the full range of possible values of the msb and lsb.
> Ie., we need to always deal with the unpleasant "am I negative?" approach 
> to
> reading (writing) that 64th bit.  To avoid the complexity of all the 
> edge cases, we encapsulate the basic primitives of working with
> unsigned numbers entirely within the abstraction of "mask" and
> "mask offset".  Using these, we built the two fundamental bitwise 
> operations
> that are used for most of the UUID calculation: ldb (load-byte) and
> dpb (deposit-byte).
>
> This scrap of code from my clj-uuid.bitmop library is extremely useful for 
> working 
> with "unsigned" long/binary values (analogously to how one might using the 
> common-lisp
> functions by the same name).  And, it has been "good enough" to do pretty 
> well
> so far in terms of performance.  But I'm sure that there are gifted 
> binariticians
> in the audience that can improve this. (Note, the namespace uses 
> ztellman/primitive-math
> which changes the semantics of some arithmetic operations and some type 
> hinting.  Also
> some of the 'let's are there for that reason. It may be helpful to refer 
> to the link.
>
> ;;; 
> https://github.com/danlentz/clj-uuid/blob/master/src/clj_uuid/bitmop.clj
>
>
> (defn ^long expt2 [^long pow]
>   (bit-set 0 pow))
>
> (defn ^long mask [^long width ^long offset]
>   (if (< (+ width offset) 64)
> (bit-shift-left (dec (bit-shift-left 1 width)) offset)
> (let [x (expt2 offset)]
>   (bit-and-not -1 (dec ^long x)
>
> (declare ^long mask-offset ^long mask-width)
>
> (defn ^long mask-offset [^long m]
>   (cond
> (zero? m) 0
> (neg?  m) (- 64 ^long (mask-width m))
> :else (loop [c 0]
> (if (pos? (bit-and 1 (bit-shift-right m c)))
>   c
>   (recur (inc c))
>
> (defn ^long mask-width [^long m]
>   (if (neg? m)
> (let [x (mask-width (- (inc m)))]
>   (- 64  ^long x))
> (loop [m (bit-shift-right m (mask-offset m)) c 0]
>   (if (zero? (bit-and 1 (bit-shift-right m c)))
> c
> (recur m (inc c))
>
> (defn ^long ldb
>   "Load Byte"
>   [^long bitmask ^long num]
>   (let [off (mask-offset bitmask)]
> (bit-and (>>> bitmask ^long off)
>   (bit-shift-right num off
>
> (defn ^long dpb
>   "Deposit Byte"
>   [^long bitmask ^long num ^long value]
>   (bit-or (bit-and-not num bitmask)
> (bit-and bitmask
>   (bit-shift-left value (mask-offset bitmask)
>

-- 
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.

More details on the Google Closure Module Support now in ClojureScript

[David Nolen]

Posted here:
http://swannodette.github.io/2015/02/23/hello-google-closure-modules/

David

-- 
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: Advice on core.async and (JDBC) transactions

[Andrey Antukh]

Hi Colin.

You are talking about suricatta documentation? Is build with asciidoctor.

And, about core.async and transactions, suricatta comes with an async
abstraction that internally uses a clojure agent for serialize all access
to one connection from different threads (managed by core.async internal
thread pool). Nothing special is used from jooq for handle it.

A suricatta context encapsulates the standard jdbc connection and
additional state. As far as I know, JDBC connection is not fully thread
safe (
http://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe),
and the general opinion is avoid use the same connection instance from
different threads concurrently. But the suricata approach is share a
connection instance between threads but ensuring that only one thread can
use it at same time (as I said previously) using serialization semantics of
clojure agents.

I hope it has been helpful.

Cheers
Andrey


2015-02-23 22:26 GMT+01:00 Colin Yates :

> Thanks Christian, that looks interesting.
>
> By the way, any idea what tool was used to generate the documentation?
>
> On 23 February 2015 at 21:22, Christian Weilbach
>  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 23.02.2015 18:20, Colin Yates wrote:
> >> Currently each request gets serviced in its own thread (web
> >> container) and I am thinking of integrating core.async and I wonder
> >> how core.async and a JDBC transactional "unit of work" get on.
> >>
> >> Conceptually, this model (thread-per-request) is trivial however
> >> the problems are well known. Replacing this with core.async right
> >> at the front is trivial but I can see the benefit of sprinkling
> >> asynchronous behaviour throughout the (still very trivial)
> >> pipeline. Or rather I can see the beauty of decomposed components
> >> communicating via channels.
> >>
> >> My question is about transactionality. I am used to JDBC
> >> transactions being thread local and I understand core.async
> >> utilises a thread-pool, so how does one implement a "unit of work"
> >> that spans multiple channels?
> >>
> >> I want to do something like:
> >>
> >> - request comes in - the appropriate handler/service consumes it
> >> (either through request mapping, defmethod whatever) - TX starts -
> >> in parallel some logging happens (and DB is updated) - the message
> >> is handled (and DB is updated) - performance metrics are stored
> >> (and DB is updated) - all work on all channels gets finished - TX
> >> commits
> >>
> >> The point is that channels are used only to communicate between
> >> disconnected components but they should all participate in the same
> >> TX.
> >>
> >> Is anyone else using channels like this?
> > I have done it in IndexedDB in JavaScript and had to use the proper
> > callback API (1), because otherwise transactions break. I guess you
> > cannot do channel operations inside a JDBC operation since they are
> > executed in the threadpool (by the state-machine) while each JDBC
> > connection seems to be pinned to a thread, so you cannot participate
> > in the same transaction from another thread of the threadpool. But if
> > you can wrap your blocking JDBC stuff in a singular thread call, you
> > might be able to use async/thread (probably less than you want).
> >
> > There is also https://github.com/niwibe/suricatta, but I have no
> > experience with it. jooq seems to solve the the thread per request
> > problem decoupling into async operations you have in mind.
> >
> > Cheers,
> > Christian
> >
> > (1)
> >
> https://github.com/ghubber/konserve/blob/master/src/cljs/konserve/indexeddb.cljs
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJU65n6AAoJEKel+aujRZMkwaAH/1Eq2/vr84WqNq6u2rcG4ly+
> > xkByy602oMy9/ScK1/ytv/kFdPG+qAYmtQ4EHq/LGUma3zLjpPdrf49A1RUGfVii
> > fbwIUiRgUJWdigrGiSf/2zIn972MgIfc4qKFj/+/2hJNZIAwlAKiPQSvG2VPrHo7
> > dskeQZeCZI4yGSz4+dQFGmKvjiAum+UConkzn0T/N2XGknerFsLonXyvpbTv/SCC
> > NwNoRJzI39kjIyhfUuwbwHoy0/DtbxjvkbrLHeyGIKGOJ75QutWY6gvkRsSlzS5g
> > A2jVtZo/hw02di3mxrD1vwSZ2PWads2juKjCmmOQrIPofSBWyVmoGeQ/qyD/Dgw=
> > =Wi7E
> > -END PGP SIGNATURE-
> >
> > --
> > 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 

Re: Is there a way to stop a long running expression in the REPL

[Erik Price]

Vim Fireplace  supports Ctrl-c
without killing its REPL host. Highly recommended if you are a Vim user.

e
​

On Sat, Feb 21, 2015 at 7:32 AM, Shawn Rasheed  wrote:

> If it's the clojure repl this might work:
> https://clojuredocs.org/clojure.repl/set-break-handler!
>
> On Sat, Feb 21, 2015 at 5:28 PM, Lucas Bradstreet <
> lucasbradstr...@gmail.com> wrote:
>
>> Which repl are you using? In lein repl, this does not happen to me, it
>> just terminates the expression.
>>
>> On 21 February 2015 at 19:45, Cecil Westerhof 
>> wrote:
>> > Sometimes I execute something that takes to long. With -C I can
>> cancel
>> > it, but this also cancels the REPL itself. Is there a way to terminate
>> the
>> > running command without terminating the running REPL?
>> >
>> > --
>> > Cecil Westerhof
>> >
>> > --
>> > 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.
>>
>
>
>
> --
> ---sr
>
> --
> 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: [BUG] : clojure.data/diff handles nested empty collections incorrectly

[Timothy Pratley]

Hi Andy,


Having thunk on it, I will try to articulate my preference for nil
over {} more clearly:

(clojure.data/diff {:x {:y 1}} {:x {}})
;; => ({:x {:y 1}} {:x nil} nil)

Do you agree the current result is wrong?

:x nil is not 'in' {:x {}}
nil is not associative so in this context does not mean empty, it
means literally nil.
only (clojure.data/diff {:x {:y 1}} {:x nil}) should return {:x nil}
as the 'only in b' result.

So choosing between ({:x {:y 1}} nil nil)  vs  ({:x {:y 1}} {:x {}}
nil) as solutions:

I argue that using {} adds an unnecessary special case.

Non-empty absence uses nil to indicate nothing was added.
(clojure.data/diff {:x {:y 1, :z 2}} {:x {:z 2}})
;; => ({:x {:y 1}} nil {:x {:z 2}})

It is not correct to say that :x {} was added as a replacement value, because
(clojure.data/diff {:x {:z 2}} {:x {:y 1, :z 2}})
;; => (nil {:x {:y 1}} {:x {:z 2}})
{:y 1} is not a replacement, but is associative (there is {:y 1, :z 2} in both).

It is correct to say that :x {} equally represents no change, but
additionally flags the collection is now empty. For my part I do not
think clojure.data/diff should do this. It might be useful
information, but is easily identifiable state, and comes at the cost
of introducing a special case.

Also consider this case:
(clojure.data/diff {} {:x {}})
;; => (nil {:x {}} nil)
There was no map associated with :x in the first argument, but there
is in the second argument. Here it accurately represents differential
participation and so should be distinguishable from (clojure.data/diff
{:x {:y 1}} {:x {}}).

What do you think?



Regarding your questions about patchin specifically:

On Sat, Feb 21, 2015 at 4:36 PM, Andy Fingerhut
 wrote:
> Do you plan to support sending a different 'diff' in each of these cases, 
> such that the 'receiver' can end up in the same final state, for each of 
> these case?

Yes, patchin works this way.


> Or perhaps the idea is that some of those are not supported?

I claim that every data representation/change that conforms to EDN is
currently supported :)
Thank you for the thoughtful test cases, I recognized an opportunity
to remove some redundancy in patch creation while experimenting with
them.


> both sides is {:x {:y 1}}, and the 'sender' wants to change to one of these 
> states:

Here is some REPL output of the patches generated which successfully
cause those transformations:

(a) patchin> (diff {:x {:y 1}} {:x nil})
;; => [{:x nil}]

(b) patchin> (diff {:x {:y 1}} {:x {}})
;; => [{:x {}}]

(bb) patchin> (diff {:x {:y 1}} {:x []})
;; => [{:x []}]

(c) patchin> (diff {:x {:y 1}} {:x {:y nil}})
;; => [{:x {:y nil}}]

All of these are 'replace the entire state with this', because the
equivalent dissoc/assoc steps create a larger patch than the final
state.


To demonstrate transformations, we need to add some extra data:

(a) patchin> (diff {:x {:y "22"}, :z "somelargedata"} {:x nil :z
"somelargedata"})
;; => [{} {:x nil}]

{} indicates nothing to dissoc/disj
{:x nil} are the things to replace.
so the second transform results in {:x nil :z "somelargedata"}

patchin> (patch {:x {:y "22"}, :z "somelargedata"} [{} {:x nil}])
;; => {:z "somelargedata", :x nil}


(b) patchin> (diff {:x {:y "22"}, :z "somelargedata"} {:x {} :z
"somelargedata"})
;; => [{:x {:y 1}} {}]

{:x {:y 1}} are the things to remove (1 is an arbitrary non-map/set terminal).
This indicates the paths to dissoc/disj; in this case there is only
one path [:x :y]
so the first transform results in: {:x {} :z "somelargedata"}
{} means nothing to add

patchin> (patch {:x {:y "22"}, :z "somelargedata"} [{:x {:y 1}} {}])
;; => {:z "somelargedata", :x {}}


(bb) patchin> (diff {:x {:y "22"}, :z "somelargedata"} {:x [] :z
"somelargedata"})
;; => [{} {:x []}]

Same as (a), :x is replaced with []

patchin> (patch {:x {:y "22"}, :z "somelargedata"} [{} {:x []}])
;; => {:z "somelargedata", :x []}


(c) patchin> (diff {:x {:y "22"}, :z "somelargedata"} {:x {:y nil} :z
"somelargedata"})
;; => [{} {:x {:y nil}}]

Replacing path [:x :y] with nil

patchin> (patch {:x {:y "22"}, :z "somelargedata"} [{} {:x {:y nil}}])
;; => {:z "somelargedata", :x {:y nil}}


The way that patchin identifies the difference between empty
collections and nil is by monkey patching data/diff-associative-key to
avoid the empty associative issue.

Thank you for your interest.


Regards,
Timothy

-- 
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.co

Re: Can someone offer refactoring suggestions for my protocol example?

[Daniel Hinojosa]

Thanks Colin!

On Monday, February 23, 2015 at 12:55:12 PM UTC-7, Colin Yates wrote:
>
> Unless of course your whole example was to work with Protocols (he says as 
> he notices the file is called protocols.clj in a protocols namespace) in 
> which case - yep, that is fine :).
>
> On Monday, 23 February 2015 19:51:00 UTC, Colin Yates wrote:
>>
>> A minor point (get col n) is the same as (col n). 
>>
>> It's more of a stylistic thing, but your use of protocols and 
>> implementation is quite 'stateful'. I would have done the same with 
>> vanilla maps: 
>>
>> (def employee [first-name last-name level] 
>>  {:first-name .}) 
>>
>> (defn promote [{:keys [level] :as employee] 
>>   (assoc employee :level (next-item levels level))) 
>>
>> but that is just me - maybe I ran too far from the OO world 
>>
>> On 23 February 2015 at 18:44, Daniel Hinojosa 
>> > wrote: 
>> > This is for my language matrix project that has samples for 10 
>> different 
>> > languages.  My clojure knowledge is ok, but not really as great where I 
>> > would like it to be, therefore looking towards the community for help. 
>> > 
>> > This example works, but it still has the feel of a lot of duplication, 
>> are 
>> > there any refactorings that I can do to this to make it more concise? 
>> > 
>> > 
>> https://github.com/dhinojosa/language-matrix/blob/master/clojure/protocols/protocols.clj
>>  
>> > 
>> > Thank you in advance, 
>> > 
>> > Danno 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "Clojure" group. 
>> > To post to this group, send email to clo...@googlegroups.com 
>>  
>> > Note that posts from new members are moderated - please be patient with 
>> your 
>> > first post. 
>> > To unsubscribe from this group, send email to 
>> > clojure+u...@googlegroups.com  
>> > For more options, visit this group at 
>> > http://groups.google.com/group/clojure?hl=en 
>> > --- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "Clojure" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to clojure+u...@googlegroups.com . 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

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

Re: To the person who recently tried to post a message about using vert.x library

[Luc Prefontaine]

You got the name right but I am not the sender :)


> I may have the name of that library incorrect.  I was going through
> messages to the Clojure group from new senders.  I saw this message, and
> was intending to approve it, but accidentally hit the 'report as spam and
> block the sender' button.  Ugh.  My apologies.  If you were the sender, and
> you are reading this, please send me a private message so I can try to
> figure out how to undo this.
> 
> Thanks,
> Andy
> 
> -- 
> 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.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
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: Advice on core.async and (JDBC) transactions

[Colin Yates]

Thanks Christian, that looks interesting.

By the way, any idea what tool was used to generate the documentation?

On 23 February 2015 at 21:22, Christian Weilbach
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 23.02.2015 18:20, Colin Yates wrote:
>> Currently each request gets serviced in its own thread (web
>> container) and I am thinking of integrating core.async and I wonder
>> how core.async and a JDBC transactional "unit of work" get on.
>>
>> Conceptually, this model (thread-per-request) is trivial however
>> the problems are well known. Replacing this with core.async right
>> at the front is trivial but I can see the benefit of sprinkling
>> asynchronous behaviour throughout the (still very trivial)
>> pipeline. Or rather I can see the beauty of decomposed components
>> communicating via channels.
>>
>> My question is about transactionality. I am used to JDBC
>> transactions being thread local and I understand core.async
>> utilises a thread-pool, so how does one implement a "unit of work"
>> that spans multiple channels?
>>
>> I want to do something like:
>>
>> - request comes in - the appropriate handler/service consumes it
>> (either through request mapping, defmethod whatever) - TX starts -
>> in parallel some logging happens (and DB is updated) - the message
>> is handled (and DB is updated) - performance metrics are stored
>> (and DB is updated) - all work on all channels gets finished - TX
>> commits
>>
>> The point is that channels are used only to communicate between
>> disconnected components but they should all participate in the same
>> TX.
>>
>> Is anyone else using channels like this?
> I have done it in IndexedDB in JavaScript and had to use the proper
> callback API (1), because otherwise transactions break. I guess you
> cannot do channel operations inside a JDBC operation since they are
> executed in the threadpool (by the state-machine) while each JDBC
> connection seems to be pinned to a thread, so you cannot participate
> in the same transaction from another thread of the threadpool. But if
> you can wrap your blocking JDBC stuff in a singular thread call, you
> might be able to use async/thread (probably less than you want).
>
> There is also https://github.com/niwibe/suricatta, but I have no
> experience with it. jooq seems to solve the the thread per request
> problem decoupling into async operations you have in mind.
>
> Cheers,
> Christian
>
> (1)
> https://github.com/ghubber/konserve/blob/master/src/cljs/konserve/indexeddb.cljs
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJU65n6AAoJEKel+aujRZMkwaAH/1Eq2/vr84WqNq6u2rcG4ly+
> xkByy602oMy9/ScK1/ytv/kFdPG+qAYmtQ4EHq/LGUma3zLjpPdrf49A1RUGfVii
> fbwIUiRgUJWdigrGiSf/2zIn972MgIfc4qKFj/+/2hJNZIAwlAKiPQSvG2VPrHo7
> dskeQZeCZI4yGSz4+dQFGmKvjiAum+UConkzn0T/N2XGknerFsLonXyvpbTv/SCC
> NwNoRJzI39kjIyhfUuwbwHoy0/DtbxjvkbrLHeyGIKGOJ75QutWY6gvkRsSlzS5g
> A2jVtZo/hw02di3mxrD1vwSZ2PWads2juKjCmmOQrIPofSBWyVmoGeQ/qyD/Dgw=
> =Wi7E
> -END PGP SIGNATURE-
>
> --
> 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: Advice on core.async and (JDBC) transactions

[Christian Weilbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23.02.2015 18:20, Colin Yates wrote:
> Currently each request gets serviced in its own thread (web
> container) and I am thinking of integrating core.async and I wonder
> how core.async and a JDBC transactional "unit of work" get on.
> 
> Conceptually, this model (thread-per-request) is trivial however
> the problems are well known. Replacing this with core.async right
> at the front is trivial but I can see the benefit of sprinkling
> asynchronous behaviour throughout the (still very trivial)
> pipeline. Or rather I can see the beauty of decomposed components
> communicating via channels.
> 
> My question is about transactionality. I am used to JDBC
> transactions being thread local and I understand core.async
> utilises a thread-pool, so how does one implement a "unit of work"
> that spans multiple channels?
> 
> I want to do something like:
> 
> - request comes in - the appropriate handler/service consumes it
> (either through request mapping, defmethod whatever) - TX starts -
> in parallel some logging happens (and DB is updated) - the message
> is handled (and DB is updated) - performance metrics are stored
> (and DB is updated) - all work on all channels gets finished - TX
> commits
> 
> The point is that channels are used only to communicate between 
> disconnected components but they should all participate in the same
> TX.
> 
> Is anyone else using channels like this?
I have done it in IndexedDB in JavaScript and had to use the proper
callback API (1), because otherwise transactions break. I guess you
cannot do channel operations inside a JDBC operation since they are
executed in the threadpool (by the state-machine) while each JDBC
connection seems to be pinned to a thread, so you cannot participate
in the same transaction from another thread of the threadpool. But if
you can wrap your blocking JDBC stuff in a singular thread call, you
might be able to use async/thread (probably less than you want).

There is also https://github.com/niwibe/suricatta, but I have no
experience with it. jooq seems to solve the the thread per request
problem decoupling into async operations you have in mind.

Cheers,
Christian

(1)
https://github.com/ghubber/konserve/blob/master/src/cljs/konserve/indexeddb.cljs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU65n6AAoJEKel+aujRZMkwaAH/1Eq2/vr84WqNq6u2rcG4ly+
xkByy602oMy9/ScK1/ytv/kFdPG+qAYmtQ4EHq/LGUma3zLjpPdrf49A1RUGfVii
fbwIUiRgUJWdigrGiSf/2zIn972MgIfc4qKFj/+/2hJNZIAwlAKiPQSvG2VPrHo7
dskeQZeCZI4yGSz4+dQFGmKvjiAum+UConkzn0T/N2XGknerFsLonXyvpbTv/SCC
NwNoRJzI39kjIyhfUuwbwHoy0/DtbxjvkbrLHeyGIKGOJ75QutWY6gvkRsSlzS5g
A2jVtZo/hw02di3mxrD1vwSZ2PWads2juKjCmmOQrIPofSBWyVmoGeQ/qyD/Dgw=
=Wi7E
-END PGP SIGNATURE-

-- 
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: [ClojureScript] Re: ANN: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support

[David Nolen]

Closure Module support was developed by testing alongside with cljsbuild.
There's nothing to wait for.

Is there some issue that you encountered?

On Mon, Feb 23, 2015 at 3:35 PM, Shaun LeBron 
wrote:

> I was trying out the Closure Module support.  Looks like we need to wait
> for cljsbuild to support this.
> On Saturday, February 21, 2015 at 3:16:11 PM UTC-6, Boris Kourtoukov wrote:
> > On Saturday, February 21, 2015 at 1:01:39 PM UTC-5, David Nolen wrote:
> > > ClojureScript, the Clojure compiler that emits JavaScript source code.
> > >
> > >
> > > README and source code: https://github.com/clojure/clojurescript
> > >
> > >
> > > New release version: 0.0-2913
> > >
> > >
> > > Leiningen dependency information:
> > >
> > >
> > > [org.clojure/clojurescript "0.0-2913"]
> > >
> > >
> > > This release comes with two very big enhancements.
> > >
> > >
> > > The first is support for Google Closure Modules via the :modules build
> > > option. Google Closure Modules permits splitting advanced compiled
> > > builds into optimal smaller pieces for faster page
> > > loads. ClojureScript's Google Closure Module support is fully
> > > :foreign-libs aware. Source mapping for modules is also fully
> > > supported.
> > >
> > >
> > > The feature is described in more detail here:
> > > https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules
> > >
> > >
> > > The second big change is a fundamental rearchitecting of ClojureScript
> > > REPLs. ClojureScript REPLs now support a set of options similar to
> > > those taken by `clojure.main/repl` with small changes to account for
> > > different JavaScript evaluation environments. Many third party REPLs
> > > like Figwheel, Weasel, and Ambly are either unaffected or have already
> > > accounted for these changes. However current tooling leveraging
> > > Piggieback will likely present an inferior experience as Piggieback was
> > > designed to work around the previous limitations of ClojureScript
> > > REPLs. Now that ClojureScript REPLs are more like the standard Clojure
> > > REPL it should be far simpler to add proper interruptible-eval and
> > > load-file nREPL middleware so that existing tooling around nREPL can
> > > more easily integrate ClojureScript REPLs as first class citizens.
> > >
> > >
> > > Feedback on both of these enhancements is very welcome!
> > >
> > >
> > >
> > > There are also many smaller fixes around REPL command line behavior,
> > > the Nashorn REPL, :foreign-libs resource finding issues, the full
> > > list follows:
> > >
> > >
> > > ## 0.0-2913
> > > * Support custom :output-to for :cljs-base module
> > >
> > >
> > > ## 0.0-2911
> > >
> > >
> > > ### Enhancements
> > > * CLJS-1042: Google Closure Modules :source-map support
> > > * CLJS-1041: Google Closure Modules :foreign-libs support
> > > * Google Closure Modules support via :modules
> > > * CLJS-1040: Source-mapped script stack frames for the Nashorn repl
> > >
> > >
> > > ### Changes
> > > * CLJS-960: On carriage return REPLs should always show new REPL prompt
> > > * CLJS-941: Warn when a symbol is defined multiple times in a file
> > > * REPLs now support parameterization a la clojure.main/repl
> > > * all REPLs analyze cljs.core before entering loop
> > > * can emit :closure-source-map option for preserving JS->JS map
> > > * REPLs can now merge new REPL/compiler options via -setup
> > >
> > >
> > > ### Fixes
> > > * CLJS-998: Nashorn REPL does not support require special fn
> > > * CLJS-1052: Cannot require ns from within the ns at the REPL for
> reloading purposes
> > > * CLJS-975: preserve :reload & :reload-all in ns macro sugar
> > > * CLJS-1039: Under Emacs source directory watching triggers spurious
> recompilation
> > > * CLJS-1046: static vars do not respect user compile time metadata
> > > * CLJS-989: ClojureScript REPL loops on EOF signal
> > > * fix DCE regression for trivial programs
> > > * CLJS-1036: use getResources not findResources in get-upstream-deps*
> >
> > Closure Module support is an amazing  addition, thank you for
> implementing it. It is something that has always been nagging at me when
> building multi page/multi ui applications with CLJS.
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
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 option

Re: ANN: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support

[Shaun LeBron]

I was trying out the Closure Module support.  Looks like we need to wait for 
cljsbuild to support this.
On Saturday, February 21, 2015 at 3:16:11 PM UTC-6, Boris Kourtoukov wrote:
> On Saturday, February 21, 2015 at 1:01:39 PM UTC-5, David Nolen wrote:
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> > 
> > 
> > README and source code: https://github.com/clojure/clojurescript
> > 
> > 
> > New release version: 0.0-2913
> > 
> > 
> > Leiningen dependency information:
> > 
> > 
> >     [org.clojure/clojurescript "0.0-2913"]
> > 
> > 
> > This release comes with two very big enhancements.
> > 
> > 
> > The first is support for Google Closure Modules via the :modules build
> > option. Google Closure Modules permits splitting advanced compiled
> > builds into optimal smaller pieces for faster page
> > loads. ClojureScript's Google Closure Module support is fully
> > :foreign-libs aware. Source mapping for modules is also fully
> > supported.
> > 
> > 
> > The feature is described in more detail here:
> > https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules
> > 
> > 
> > The second big change is a fundamental rearchitecting of ClojureScript
> > REPLs. ClojureScript REPLs now support a set of options similar to
> > those taken by `clojure.main/repl` with small changes to account for
> > different JavaScript evaluation environments. Many third party REPLs
> > like Figwheel, Weasel, and Ambly are either unaffected or have already
> > accounted for these changes. However current tooling leveraging
> > Piggieback will likely present an inferior experience as Piggieback was
> > designed to work around the previous limitations of ClojureScript
> > REPLs. Now that ClojureScript REPLs are more like the standard Clojure
> > REPL it should be far simpler to add proper interruptible-eval and
> > load-file nREPL middleware so that existing tooling around nREPL can
> > more easily integrate ClojureScript REPLs as first class citizens.
> > 
> > 
> > Feedback on both of these enhancements is very welcome!
> > 
> > 
> > 
> > There are also many smaller fixes around REPL command line behavior,
> > the Nashorn REPL, :foreign-libs resource finding issues, the full
> > list follows:
> > 
> > 
> > ## 0.0-2913
> > * Support custom :output-to for :cljs-base module
> > 
> > 
> > ## 0.0-2911
> > 
> > 
> > ### Enhancements
> > * CLJS-1042: Google Closure Modules :source-map support
> > * CLJS-1041: Google Closure Modules :foreign-libs support
> > * Google Closure Modules support via :modules
> > * CLJS-1040: Source-mapped script stack frames for the Nashorn repl
> > 
> > 
> > ### Changes
> > * CLJS-960: On carriage return REPLs should always show new REPL prompt
> > * CLJS-941: Warn when a symbol is defined multiple times in a file
> > * REPLs now support parameterization a la clojure.main/repl
> > * all REPLs analyze cljs.core before entering loop
> > * can emit :closure-source-map option for preserving JS->JS map
> > * REPLs can now merge new REPL/compiler options via -setup
> > 
> > 
> > ### Fixes
> > * CLJS-998: Nashorn REPL does not support require special fn
> > * CLJS-1052: Cannot require ns from within the ns at the REPL for reloading 
> > purposes
> > * CLJS-975: preserve :reload & :reload-all in ns macro sugar
> > * CLJS-1039: Under Emacs source directory watching triggers spurious 
> > recompilation
> > * CLJS-1046: static vars do not respect user compile time metadata
> > * CLJS-989: ClojureScript REPL loops on EOF signal
> > * fix DCE regression for trivial programs
> > * CLJS-1036: use getResources not findResources in get-upstream-deps*
> 
> Closure Module support is an amazing  addition, thank you for implementing 
> it. It is something that has always been nagging at me when building multi 
> page/multi ui applications with CLJS.

-- 
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] Buddy 0.4.0: Security library for clojure.

[Andrey Antukh]

Hi Dave

Buddy authorization/authentication facilities are more low level and less
opinionated that friend and allow build over them easy other high level
abstractions.
Technically, friend abstraction can be build on top of buddy.

Cheers.
Andrey

2015-02-23 2:25 GMT+01:00 Dave Sann :

> buddy-auth vs friend?
>
> What is the difference/motivation?
>
>
>
>
> On Monday, 23 February 2015 06:32:22 UTC+11, g vim wrote:
>>
>> On 22/02/2015 11:36, Andrey Antukh wrote:
>> > Documentation:
>> > https://funcool.github.io/buddy-core/latest/
>> > https://funcool.github.io/buddy-auth/latest/
>> > https://funcool.github.io/buddy-hashers/latest/
>> > https://funcool.github.io/buddy-sign/latest/
>> >
>>
>> Great addition to Clojure web development security. For new users might
>> I suggest adding a namespace table to -core, -hashers and -sign as with
>> -auth?
>>
>> gvim
>>
>  --
> 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.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
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: Can someone offer refactoring suggestions for my protocol example?

[Colin Yates]

Unless of course your whole example was to work with Protocols (he says as 
he notices the file is called protocols.clj in a protocols namespace) in 
which case - yep, that is fine :).

On Monday, 23 February 2015 19:51:00 UTC, Colin Yates wrote:
>
> A minor point (get col n) is the same as (col n). 
>
> It's more of a stylistic thing, but your use of protocols and 
> implementation is quite 'stateful'. I would have done the same with 
> vanilla maps: 
>
> (def employee [first-name last-name level] 
>  {:first-name .}) 
>
> (defn promote [{:keys [level] :as employee] 
>   (assoc employee :level (next-item levels level))) 
>
> but that is just me - maybe I ran too far from the OO world 
>
> On 23 February 2015 at 18:44, Daniel Hinojosa 
>  wrote: 
> > This is for my language matrix project that has samples for 10 different 
> > languages.  My clojure knowledge is ok, but not really as great where I 
> > would like it to be, therefore looking towards the community for help. 
> > 
> > This example works, but it still has the feel of a lot of duplication, 
> are 
> > there any refactorings that I can do to this to make it more concise? 
> > 
> > 
> https://github.com/dhinojosa/language-matrix/blob/master/clojure/protocols/protocols.clj
>  
> > 
> > Thank you in advance, 
> > 
> > Danno 
> > 
> > -- 
> > 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: Can someone offer refactoring suggestions for my protocol example?

[Colin Yates]

A minor point (get col n) is the same as (col n).

It's more of a stylistic thing, but your use of protocols and
implementation is quite 'stateful'. I would have done the same with
vanilla maps:

(def employee [first-name last-name level]
 {:first-name .})

(defn promote [{:keys [level] :as employee]
  (assoc employee :level (next-item levels level)))

but that is just me - maybe I ran too far from the OO world

On 23 February 2015 at 18:44, Daniel Hinojosa
 wrote:
> This is for my language matrix project that has samples for 10 different
> languages.  My clojure knowledge is ok, but not really as great where I
> would like it to be, therefore looking towards the community for help.
>
> This example works, but it still has the feel of a lot of duplication, are
> there any refactorings that I can do to this to make it more concise?
>
> https://github.com/dhinojosa/language-matrix/blob/master/clojure/protocols/protocols.clj
>
> Thank you in advance,
>
> Danno
>
> --
> 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.

Can someone offer refactoring suggestions for my protocol example?

[Daniel Hinojosa]

This is for my language matrix project that has samples for 10 different 
languages.  My clojure knowledge is ok, but not really as great where I 
would like it to be, therefore looking towards the community for help.

This example works, but it still has the feel of a lot of duplication, are 
there any refactorings that I can do to this to make it more concise?

https://github.com/dhinojosa/language-matrix/blob/master/clojure/protocols/protocols.clj

Thank you in advance, 

Danno

-- 
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.

To the person who recently tried to post a message about using vert.x library

[Andy Fingerhut]

I may have the name of that library incorrect.  I was going through
messages to the Clojure group from new senders.  I saw this message, and
was intending to approve it, but accidentally hit the 'report as spam and
block the sender' button.  Ugh.  My apologies.  If you were the sender, and
you are reading this, please send me a private message so I can try to
figure out how to undo this.

Thanks,
Andy

-- 
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.

can binary arithmetic guru help improve these "bitmasking" ops?

[danle...@gmail.com]

So, much of the pain involved in handling UUID's correctly on the JVM
relates to the fact that there is no primitive unsigned numeric type
that can represent the full range of possible values of the msb and lsb.
Ie., we need to always deal with the unpleasant "am I negative?" approach to
reading (writing) that 64th bit.  To avoid the complexity of all the 
edge cases, we encapsulate the basic primitives of working with
unsigned numbers entirely within the abstraction of "mask" and
"mask offset".  Using these, we built the two fundamental bitwise operations
that are used for most of the UUID calculation: ldb (load-byte) and
dpb (deposit-byte).

This scrap of code from my clj-uuid.bitmop library is extremely useful for 
working 
with "unsigned" long/binary values (analogously to how one might using the 
common-lisp
functions by the same name).  And, it has been "good enough" to do pretty 
well
so far in terms of performance.  But I'm sure that there are gifted 
binariticians
in the audience that can improve this. (Note, the namespace uses 
ztellman/primitive-math
which changes the semantics of some arithmetic operations and some type 
hinting.  Also
some of the 'let's are there for that reason. It may be helpful to refer to 
the link.

;;; https://github.com/danlentz/clj-uuid/blob/master/src/clj_uuid/bitmop.clj


(defn ^long expt2 [^long pow]
  (bit-set 0 pow))

(defn ^long mask [^long width ^long offset]
  (if (< (+ width offset) 64)
(bit-shift-left (dec (bit-shift-left 1 width)) offset)
(let [x (expt2 offset)]
  (bit-and-not -1 (dec ^long x)

(declare ^long mask-offset ^long mask-width)

(defn ^long mask-offset [^long m]
  (cond
(zero? m) 0
(neg?  m) (- 64 ^long (mask-width m))
:else (loop [c 0]
(if (pos? (bit-and 1 (bit-shift-right m c)))
  c
  (recur (inc c))

(defn ^long mask-width [^long m]
  (if (neg? m)
(let [x (mask-width (- (inc m)))]
  (- 64  ^long x))
(loop [m (bit-shift-right m (mask-offset m)) c 0]
  (if (zero? (bit-and 1 (bit-shift-right m c)))
c
(recur m (inc c))

(defn ^long ldb
  "Load Byte"
  [^long bitmask ^long num]
  (let [off (mask-offset bitmask)]
(bit-and (>>> bitmask ^long off)
  (bit-shift-right num off

(defn ^long dpb
  "Deposit Byte"
  [^long bitmask ^long num ^long value]
  (bit-or (bit-and-not num bitmask)
(bit-and bitmask
  (bit-shift-left value (mask-offset bitmask)

-- 
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] Buddy 0.4.0: Security library for clojure.

[Liu Shijun]

Great job guys!

On Monday, 23 February 2015 00:38:02 UTC+13, Andrey Antukh wrote:
>
> Hi!
>
> I am happy to announce a new release of buddy (security library for 
> Clojure).
>
> Since 0.3.0, buddy is split from monolithic library in four modules:
>
> - buddy-core: Cryptographyc api.
> - buddy-sign: High level message signing
> - buddy-auth: Authentication and Authorization facilities for ring based 
> web apps.
> - buddy-hashers: Collection of password hashers.
>
> Relevant changes since 0.3.0:
>
> buddy-core:
>
> - Add buddy.core.nonce namespace with functions for generate 
> cryptographically secure ivs and nonces.
> - Add buddy.core.padding with interface to the common padding algorithms.
> - Function name consistency improvements in almost all api (with proper 
> backward compatibility for almost all changes, see changelog for breaking 
> changes).
> - Improved low level interface to Hash and Mac algorithms, allowing to the 
> user build own high level abstractions over it.
>
> buddy-sign:
>
> - Removed generic signing implementation
> - Add compact signing as replacement for generic (the difference and the 
> purpose is explained in the documentation).
> - Improved time based validation and fix some related bugs.
> - Improved error reporting on message validation using Either monadic type.
>
> buddy-auth:
>
> - Remove generic signed token backend.
> - Add JWS/JWT backend as replacement to generic signed token backend).
> - Improved generic authorization system, now it extensible with clojure 
> protocols.
>
> buddy-hashers:
>
> - Update versions and adapt the code to buddy-core internal api changes.
>
> Github:
> https://github.com/funcool/buddy-core
> https://github.com/funcool/buddy-auth
> https://github.com/funcool/buddy-hashers
> https://github.com/funcool/buddy-sign
>
> Documentation:
> https://funcool.github.io/buddy-core/latest/
> https://funcool.github.io/buddy-auth/latest/
> https://funcool.github.io/buddy-hashers/latest/
> https://funcool.github.io/buddy-sign/latest/
>
> Cheers.
> Andrey
>
> -- 
> Andrey Antukh - Андрей Антух - > / <
> ni...@niwi.be >
> http://www.niwi.be 
> https://github.com/niwibe
>  

-- 
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] Sweet Liberty: Set Your Data Free with Clojure and REST

[Bill Piel]

Thanks

I haven't seen that method of paging before. The trade offs are interesting.
I've been toying around with how we might make sweet liberty have more of a 
pluggable architecture -- allowing you to choose a custom feature set. This 
could allow features that are independent, 3rd-party implementations. Your 
example would be a perfect use case.

Bill

On Saturday, February 21, 2015 at 11:43:11 AM UTC-5, Andy Chambers wrote:
>
>
>
> On Tuesday, February 17, 2015 at 11:24:48 AM UTC-5, Bill Piel wrote:
>>
>> Blog post: 
>> https://blog.rjmetrics.com/2015/02/15/sweet-liberty-set-your-data-free-with-clojure-and-rest/
>>
>>
>> Sweet-Liberty is a library for building database-backed RESTful services 
>> using Clojure. You can think of it as a means to build and configure 
>> components that translate between REST and SQL. Or, you might say that it 
>> helps you wrap a REST interface around a relational database. Besides 
>> standard CRUD operations (available via appropriate HTTP methods), it also 
>> supports some other features through query parameters, such as: filtering, 
>> paging and returning a subset of fields. 
>>
>>
>> Feedback is welcome and appreciated. Thanks
>>
>
> It looks cool!
>
> I started out on a similar track but using datomic as the storage and 
> ended up with http://github.com/cddr/crud 
>
> Since you have implemented paging, you might be interested in reading 
> http://use-the-index-luke.com/sql/partial-results/fetch-next-page which 
> provides a method of paging with different (IMO better) trade-offs to the 
> method you see in most tutorials.
>
> Cheers,
> Andy
>

-- 
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.

Advice on core.async and (JDBC) transactions

[Colin Yates]

Currently each request gets serviced in its own thread (web container) and 
I am thinking of integrating core.async and I wonder how core.async and a 
JDBC transactional "unit of work" get on.

Conceptually, this model (thread-per-request) is trivial however the 
problems are well known. Replacing this with core.async right at the front 
is trivial but I can see the benefit of sprinkling asynchronous behaviour 
throughout the (still very trivial) pipeline. Or rather I can see the 
beauty of decomposed components communicating via channels.

My question is about transactionality. I am used to JDBC transactions being 
thread local and I understand core.async utilises a thread-pool, so how 
does one implement a "unit of work" that spans multiple channels?

I want to do something like:

 - request comes in
 - the appropriate handler/service consumes it (either through request 
mapping, defmethod whatever)
 - TX starts
 - in parallel some logging happens (and DB is updated)
 - the message is handled (and DB is updated)
 - performance metrics are stored (and DB is updated)
 - all work on all channels gets finished
 - TX commits

The point is that channels are used only to communicate between 
disconnected components but they should all participate in the same TX.

Is anyone else using channels like this?

Thanks!

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

Re: Dependency conflict between parkour [0.6.2] and inflections [0.9.13]

[Jeremy Heiler]

On Mon, Feb 23, 2015 at 11:22 AM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> I tried putting the above in :exclusions in the project.clj with no
> success.


What do you mean by "with no success"? Can you show how you modified your
project.clj?

-- 
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.

Dependency conflict between parkour [0.6.2] and inflections [0.9.13]

[Sunil S Nandihalli]

Hi Everybody,
 I am having a dependency conflict when using parkour and inflections
library.

[inflection "0.9.13"] also pulls [com.google.protobuf/protobuf-java "2.4.1"]

I don't want it to pull [com.google.protobuf/protobuf-java "2.4.1"]

 since the hadoop system (CDH-5.3.1) I am running already provides
[com.google.protobuf/protobuf-java "2.5.0"]
I tried putting the above in :exclusions in the project.clj with no
success.

How can I make this work?

Thanks,
Sunil.

-- 
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: defmulti: dispatch function is not called

[Timothy Baldridge]

Except that doesn't work, since the var is de-reffed when handed to the
defmulti. You can var quote it, and that should work:

(defmulti create-fact #'create-fact-dispatch)


Timothy


On Mon, Feb 23, 2015 at 8:44 AM, Francis Avila  wrote:

> You can work around this by using a symbol for the dispatch function
> instead of inlining the function:
>
> (defn create-fact-dispatch [item-vector]
>   (do
> (print item-vector)
> (first item-vector)))
>
>
> (defmulti create-fact create-fact-dispatch)
>
>
>
> When you reload in the REPL the defmulti will not be redefed, but the
> dispatch function will. This is usually all you need when you are messing
> around in the REPL.
>
> There may be some performance cost, but I don't know if it is significant.
> There is at least the var lookup cost. Maybe defmulti dispatch result can't
> be cached? (not sure)
>
> On Sunday, February 22, 2015 at 12:19:24 PM UTC-6, Timur wrote:
>>
>> Thank you all for your answers. The problem was caused by not starting
>> the REPL. I did not know that defmulti had defonce semantics.
>>
>> On Sunday, February 22, 2015 at 7:04:58 PM UTC+1, Jeremy Heiler wrote:
>>>
>>> On 2/22/15 12:52 PM, Timur wrote:
>>> > Hi everyone,
>>> >
>>> > I have the following question regarding the defmultis of clojure:
>>> >
>>> > (defmulti create-fact
>>> >(fn [item-vector] (do
>>> >(print item-vector)
>>> >(first item-vector
>>> >
>>> > (defmethod create-fact [:a] [item-vector]
>>> >(str "a"))
>>> >
>>> > (defmethod create-fact [[:a "safs"]] [item-vector]
>>> >(str "safs"))
>>> >
>>> >
>>> > (mapv create-fact {:a "safs"})
>>> >
>>> >
>>> > Dispatch function is not called in this case and return is "safs" so
>>> the
>>> > matching key is [[:a "safs"]]. I except it to be :a, why is that [[:a
>>> > "safs"]]?
>>>
>>> First, observe:
>>>
>>>  > (seq {:a 1 :b 2})
>>> ([:a 1] [:b 2])
>>>
>>> A map is converted into a sequence with each element being a key/value
>>> pair. The mapv function does this under the hood so that it can operate
>>> on the map as a sequence.
>>>
>>> Now, when I run your code, I get an IllegalArgumentException stating
>>> that :a is not a dispatch value. This is correct, because the two
>>> dispatch values defined are [:a] and [[:a "safs"]]. If you change the
>>> [:a] method to be :a, then the return value will be "a". The dispatch
>>> values in each defmethod must be literal, and not wrapped in a vector
>>> like when defining the arguments to a fn.
>>>
>>> Does that clear things up?
>>>
>>  --
> 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: defmulti: dispatch function is not called

[Francis Avila]

You can work around this by using a symbol for the dispatch function 
instead of inlining the function:

(defn create-fact-dispatch [item-vector]
  (do
(print item-vector)
(first item-vector)))


(defmulti create-fact create-fact-dispatch)



When you reload in the REPL the defmulti will not be redefed, but the 
dispatch function will. This is usually all you need when you are messing 
around in the REPL.

There may be some performance cost, but I don't know if it is significant. 
There is at least the var lookup cost. Maybe defmulti dispatch result can't 
be cached? (not sure)

On Sunday, February 22, 2015 at 12:19:24 PM UTC-6, Timur wrote:
>
> Thank you all for your answers. The problem was caused by not starting the 
> REPL. I did not know that defmulti had defonce semantics. 
>
> On Sunday, February 22, 2015 at 7:04:58 PM UTC+1, Jeremy Heiler wrote:
>>
>> On 2/22/15 12:52 PM, Timur wrote: 
>> > Hi everyone, 
>> > 
>> > I have the following question regarding the defmultis of clojure: 
>> > 
>> > (defmulti create-fact 
>> >(fn [item-vector] (do 
>> >(print item-vector) 
>> >(first item-vector 
>> > 
>> > (defmethod create-fact [:a] [item-vector] 
>> >(str "a")) 
>> > 
>> > (defmethod create-fact [[:a "safs"]] [item-vector] 
>> >(str "safs")) 
>> > 
>> > 
>> > (mapv create-fact {:a "safs"}) 
>> > 
>> > 
>> > Dispatch function is not called in this case and return is "safs" so 
>> the 
>> > matching key is [[:a "safs"]]. I except it to be :a, why is that [[:a 
>> > "safs"]]? 
>>
>> First, observe: 
>>
>>  > (seq {:a 1 :b 2}) 
>> ([:a 1] [:b 2]) 
>>
>> A map is converted into a sequence with each element being a key/value 
>> pair. The mapv function does this under the hood so that it can operate 
>> on the map as a sequence. 
>>
>> Now, when I run your code, I get an IllegalArgumentException stating 
>> that :a is not a dispatch value. This is correct, because the two 
>> dispatch values defined are [:a] and [[:a "safs"]]. If you change the 
>> [:a] method to be :a, then the return value will be "a". The dispatch 
>> values in each defmethod must be literal, and not wrapped in a vector 
>> like when defining the arguments to a fn. 
>>
>> Does that clear things up? 
>>
>

-- 
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.