date:20130801

Can I refer all but specified symbols with 'ns' macro?

2013-08-01 Thread Yoshinori Kohyama

Hi group.

Assumed that I want to refer 'baz, 'qux and etc and don't want to refer 
'quux of 'bar namespace within my 'foo namespace.

With 'ns' macro, I can require a namespace and refer all public symbols in 
it.

  (ns foo (:require [bar :refer :all]))

I can refer only some specific symbols.

  (ns foo (:require [bar :refer (baz qux)]))

Can I refer all but specific symbols?

I'm doing

  (ns foo (:require bar))
  (refer 'bar :exclude '(quux))

or

  (ns foo)
  (require 'bar)
  (refer 'bar :exclude '(quux))

for now.

Thanks in advance.

Y. Kohyama

-- 
-- 
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/groups/opt_out.

Re: Can I refer all but specified symbols with 'ns' macro?

2013-08-01 Thread Carlo Zancanaro

I think the way to do it is:

(ns foo
  (:require [bar :refer :all :exclude (quux)]))


On 1 August 2013 18:19, Yoshinori Kohyama yykohy...@gmail.com wrote:

 Hi group.

 Assumed that I want to refer 'baz, 'qux and etc and don't want to refer
 'quux of 'bar namespace within my 'foo namespace.

 With 'ns' macro, I can require a namespace and refer all public symbols in
 it.

   (ns foo (:require [bar :refer :all]))

 I can refer only some specific symbols.

   (ns foo (:require [bar :refer (baz qux)]))

 Can I refer all but specific symbols?

 I'm doing

   (ns foo (:require bar))
   (refer 'bar :exclude '(quux))

 or

   (ns foo)
   (require 'bar)
   (refer 'bar :exclude '(quux))

 for now.

 Thanks in advance.

 Y. Kohyama

  --
 --
 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/groups/opt_out.




-- 
-- 
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/groups/opt_out.

Re: core.async: async java.jdbc

2013-08-01 Thread Alice

What if I want to run a select query in the middle of a transaction?

On Thursday, August 1, 2013 3:33:29 AM UTC+9, tbc++ wrote:

 DB work is a IO operation, and IO shouldn't be done inside a go block (go 
 blocks use limited thread pools). 

 So what about something like this?

 (defn handle-db [chan]
  (thread
 (while true
   (let [[data result] (! c)]
  (run-db-transaction-as-normal data)
  (! result :done)

 Now spin up a few of these:

 (def db-chan (let [c (chan 4)]
  (dotimes [x 4] 
(handle-db c))
  c))

 Now it's trivial to use this from a go block:

 (defn db-async [data]
   (go
 (let [c (chan)]
   (! db-chan [data c])
   (! c

 So this is the pattern: create processors using threads, then send data to 
 those processors via a shared channel, passing in a response channel. 

 Anyways, that's the way I'm thinking these days. 

 Timothy




 On Wed, Jul 31, 2013 at 12:24 PM, Alice doff...@gmail.com 
 javascript:wrote:

 I have an async http handler and I don't want it to consume a thread.

 On Thursday, August 1, 2013 3:16:52 AM UTC+9, tbc++ wrote:

 Why not use !! ?

 Timothy


 On Wed, Jul 31, 2013 at 11:58 AM, Alice doff...@gmail.com wrote:

 It doesn't produce a compile time error but I think it's not the 
 correct code because the transaction can be committed while insert-async! 
 is still executing.

 On Thursday, August 1, 2013 2:46:29 AM UTC+9, Sean Corfield wrote:

 On Wed, Jul 31, 2013 at 10:29 AM, Alice doff...@gmail.com wrote: 
  (go 
(jdbc/db-transaction [t-con db-spec] 
  (! (insert-async! t-con :fruit {:name apple} 

 Does this work: 

 (jdbc/db-transaction [t-con db-spec] 
   (go 
  (! (insert-async! t-con :fruit {:name apple} 

 -- 
 Sean A Corfield -- (904) 302-SEAN 
 An Architect's View -- http://corfield.org/ 
 World Singles, LLC. -- http://worldsingles.com/ 

 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 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=enhttp://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/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .
  
  




 -- 
 “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 clo...@googlegroups.comjavascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  




 -- 
 “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/groups/opt_out.

Re: In-order triggering of watches on mutable state

2013-08-01 Thread Cedric Greevey

Try using an agent send from inside a transaction. Such sends are only
dispatched if the transaction commits, and successive sends to the same
agent from a single thread are run by the agent in the same order the
thread sent them.

On Wed, Jul 31, 2013 at 1:12 PM, Mike Drogalis madrush...@gmail.com wrote:

Good reasoning; that makes a lot of sense -- even if intuitively it
doesn't follow through.

I'll do some more thinking about my concurrency needs and come back with a
follow up question later. Thanks man!

On Wed, Jul 31, 2013 at 12:51 PM, Timothy Baldridge
tbaldri...@gmail.comwrote:

Deadlocks? Imagine a watch that ended up running a transaction against
the ref it was triggered from. Sounds insane, but it could be fairly easy
to do in a situation like this:

ref - calls watchers - calls fn1 - calls fn 2 - calls fn3 - starts
transaction on ref

Since watchers are notified outside of a ref transaction deadlocking is
impossible. Inside a transaction you'd have a instant deadlock.

Timothy Baldridge

On Wed, Jul 31, 2013 at 10:47 AM, Mike Drogalis madrush...@gmail.comwrote:

I'll play around with agents for this when I get some more free time.

I find it odd that, as the sole perceiver of an indentity, events are
capable of being perceived out of order.
If I were watching a line queue up in person, events are obviously
dispatched in order through my visual perception.
I trust there's a good reason it's designed this way, at any rate.

On Wed, Jul 31, 2013 at 12:25 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

You might want to consider switching to agents (or something else) I
don't think it's possible to do what you want with refs.

Timothy Baldridge

On Wed, Jul 31, 2013 at 10:08 AM, Mike Drogalis
madrush...@gmail.comwrote:

Thanks for the link. :) I understand that the behavior I'm seeing is
correct. Any idea how to achieve the desired behavior, though?

On Wed, Jul 31, 2013 at 12:06 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

The answer is here:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L361

Agents and watches are dispatched outside of the transaction locking.
This means that multiple transactions could be executing watches in
parallel, and hence execute out of order.

Timothy Baldridge

On Wed, Jul 31, 2013 at 9:43 AM, Michael Drogalis
madrush...@gmail.com wrote:

I can precisely exemplify the behavior here:

https://gist.github.com/MichaelDrogalis/6123177

On Wednesday, July 31, 2013 11:13:17 AM UTC-4, Michael Drogalis
wrote:

Aaron: Yep, I'm aware - and am using the value provided by the last
parameter.

This is going to be tough to show the problem without bringing more
details of my concurrency set up.
I'm not sure if this will exhibit the problem, but this is what it
boils down to:

https://gist.github.com/**MichaelDrogalis/6122834https://gist.github.com/MichaelDrogalis/6122834

When enough threads are trying to write to the queue, the watches
triggered later can finish before watches triggered earlier.

On Wednesday, July 31, 2013 11:05:16 AM UTC-4, Aaron Cohen wrote:

A watcher fn has 4 parameters: key, reference, old-state, new-state

If you use old-state and new-state rather than the reference, you
should not see your problem.

--Aaron

On Wed, Jul 31, 2013 at 11:00 AM, Michael Drogalis
madru...@gmail.com wrote:

Problem:

I have a ref representing a queue of people in line.
I add a watch to the ref to print out the contents of the queue
whenever it changes.
Naturally, and expected, the following can happen if queuing
happens in rapid succession:

Queue: []
add Mike to queue
add John to queue

console: Queue is Mike, John
console: Queue is Mike

I'd like to write a UI for this program, but I clearly can't
reliably render based on the result delivered
by the add-watch hook. What's the solution for this problem?

--
--
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=enhttp://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/**
groups/opt_out https://groups.google.com/groups/opt_out.

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

core.async: faulty rebinding of loop-bindings in go blocks

2013-08-01 Thread Kemar

There seems to be an issue with the rebinding of loop-bindings using 
loop/recur in go blocks,
specifically when you are just changing the order of the original bindings 
in a recur call.

Take this snippet for example:

   
(require '[clojure.core.async :refer [go timeout]])
 (go (loop [a :black, b :white]  
   (println a b)
   (! (timeout 1000))
   (recur b a)))


Instead of repeatedly printing

:black :white
 :white :black
 :black :white 
 :white :black
 (...)


 it actually prints

:black :white
 :white :white
 :white :white
 :white :white
 (...)

 
Note however, that 
 

 (require '[clojure.core.async :refer [go timeout]])
 (go (loop [a :black, b :white]  
   (println a b)
   (! (timeout 1000))
   (recur (identity b) (identity a


works correctly.

Any ideas as to what's causing this?


Cheers,
Kevin

-- 
-- 
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/groups/opt_out.

Re: core.async: throwing an exception into the channel

2013-08-01 Thread Alice

throw! is an explicit operation, and there's no special channel states 
involved. It's passing an exception like other data that just automatically 
throws it when taken. So it won't hurt anybody. You can use it when you 
need it, you can ignore it if you don't need it. Yet, it makes using async 
functions look almost identical to the sync functions.

On Thursday, August 1, 2013 3:37:51 AM UTC+9, tbc++ wrote:

 The position of core.async is to not specify how exceptions should be done 
 (instead leaving it up to the user). So if that method works well for you, 
 write some macros and use it! 

 Other methods may be the use of supervisor channels. In this model, go 
 blocks that die would enqueue the exception into a global (or shared) 
 channel and the go block would then be re-started by a monitor process.

 Both methods (and may more) are supported by core.async...it simply 
 doesn't care how you handle exceptions, but it is up to you to specify how 
 they are handled. 

 Timothy


 On Wed, Jul 31, 2013 at 11:49 AM, Alice doff...@gmail.com 
 javascript:wrote:

 It would be nice to have a function throw! that puts an exception into 
 the channel and throws it when taken, so that I can write

 (let [c (chan)]
   (go (throw! c (Exception.)))
   (go (try
 (prn (! c))
 (catch Throwable t
   (prn exception)

 instead of

 (let [c (chan)]
   (go (! c (Exception.)))
   (go (try
 (let [res (! c)]
   (if (instance? Throwable res)
 (throw res)
 (prn res)))
 (catch Throwable t
   (prn exception)

  -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.comjavascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  




 -- 
 “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/groups/opt_out.

Re: Can I refer all but specified symbols with 'ns' macro?

2013-08-01 Thread Yoshinori Kohyama

Carlo,

Works fine. Thank you!

Y. Kohyama

-- 
-- 
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/groups/opt_out.

Re: In-order triggering of watches on mutable state

2013-08-01 Thread Mike Drogalis

Cedric: Will agents give me the guarantee that if I have something in Agent
A, and I want to move it to agent B, and I do this inside a transaction:
- perceivers will see it in A at read point
- perceivers will see it in B at write point
- perceivers will never see it in neither nor both?

If that's the case, which is effectively synchronous coordination (I
think?), what do refs buy you that agents don't?

On Thu, Aug 1, 2013 at 5:57 AM, Cedric Greevey cgree...@gmail.com wrote:

On Wed, Jul 31, 2013 at 1:12 PM, Mike Drogalis madrush...@gmail.comwrote:

Good reasoning; that makes a lot of sense -- even if intuitively it
doesn't follow through.

I'll do some more thinking about my concurrency needs and come back with
a follow up question later. Thanks man!

On Wed, Jul 31, 2013 at 12:51 PM, Timothy Baldridge tbaldri...@gmail.com
wrote:

Deadlocks? Imagine a watch that ended up running a transaction against
the ref it was triggered from. Sounds insane, but it could be fairly easy
to do in a situation like this:

ref - calls watchers - calls fn1 - calls fn 2 - calls fn3 - starts
transaction on ref

Since watchers are notified outside of a ref transaction deadlocking is
impossible. Inside a transaction you'd have a instant deadlock.

Timothy Baldridge

On Wed, Jul 31, 2013 at 10:47 AM, Mike Drogalis madrush...@gmail.comwrote:

I'll play around with agents for this when I get some more free time.

On Wed, Jul 31, 2013 at 12:25 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

You might want to consider switching to agents (or something else) I
don't think it's possible to do what you want with refs.

Timothy Baldridge

On Wed, Jul 31, 2013 at 10:08 AM, Mike Drogalis
madrush...@gmail.comwrote:

Thanks for the link. :) I understand that the behavior I'm seeing is
correct. Any idea how to achieve the desired behavior, though?

On Wed, Jul 31, 2013 at 12:06 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

The answer is here:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L361

Agents and watches are dispatched outside of the transaction
locking. This means that multiple transactions could be executing
watches
in parallel, and hence execute out of order.

Timothy Baldridge

On Wed, Jul 31, 2013 at 9:43 AM, Michael Drogalis
madrush...@gmail.com wrote:

I can precisely exemplify the behavior here:

https://gist.github.com/MichaelDrogalis/6123177

On Wednesday, July 31, 2013 11:13:17 AM UTC-4, Michael Drogalis
wrote:

Aaron: Yep, I'm aware - and am using the value provided by the
last parameter.

This is going to be tough to show the problem without bringing
more details of my concurrency set up.
I'm not sure if this will exhibit the problem, but this is what it
boils down to:

https://gist.github.com/**MichaelDrogalis/6122834https://gist.github.com/MichaelDrogalis/6122834

When enough threads are trying to write to the queue, the watches
triggered later can finish before watches triggered earlier.

On Wednesday, July 31, 2013 11:05:16 AM UTC-4, Aaron Cohen wrote:

A watcher fn has 4 parameters: key, reference, old-state,
new-state

If you use old-state and new-state rather than the reference, you
should not see your problem.

--Aaron

On Wed, Jul 31, 2013 at 11:00 AM, Michael Drogalis
madru...@gmail.com wrote:

Problem:

Queue: []
add Mike to queue
add John to queue

console: Queue is Mike, John
console: Queue is Mike

I'd like to write a UI for this program, but I clearly can't
reliably render based on the result delivered
by the add-watch hook. What's the solution for this problem?

Re: core.async: throwing an exception into the channel

2013-08-01 Thread John D. Hume

I think I'd rather see separate functions or macros for consuming from a
channel with the maybe throw behavior rather than having the standard
consume form(s) come with that feature (or threat, depending on whether you
want it). At that point you're back to the earlier advice to wrap
core.async to fit your approach.

As new as core.async is to the Clojure community, it seems premature to
build in an error-handling approach that may turn out not to be appropriate
for many users.
 On Aug 1, 2013 5:19 AM, Alice dofflt...@gmail.com wrote:

throw! is an explicit operation, and there's no special channel states
involved. It's passing an exception like other data that just automatically
throws it when taken. So it won't hurt anybody. You can use it when you
need it, you can ignore it if you don't need it. Yet, it makes using async
functions look almost identical to the sync functions.


On Thursday, August 1, 2013 3:37:51 AM UTC+9, tbc++ wrote:

 The position of core.async is to not specify how exceptions should be done
 (instead leaving it up to the user). So if that method works well for you,
 write some macros and use it!

 Other methods may be the use of supervisor channels. In this model, go
 blocks that die would enqueue the exception into a global (or shared)
 channel and the go block would then be re-started by a monitor process.

 Both methods (and may more) are supported by core.async...it simply
 doesn't care how you handle exceptions, but it is up to you to specify how
 they are handled.

 Timothy


 On Wed, Jul 31, 2013 at 11:49 AM, Alice doff...@gmail.com wrote:

 It would be nice to have a function throw! that puts an exception into
 the channel and throws it when taken, so that I can write

 (let [c (chan)]
   (go (throw! c (Exception.)))
   (go (try
 (prn (! c))
 (catch Throwable t
   (prn exception)

 instead of

 (let [c (chan)]
   (go (! c (Exception.)))
   (go (try
 (let [res (! c)]
   (if (instance? Throwable res)
 (throw res)
 (prn res)))
 (catch Throwable t
   (prn exception)

  --
 --
 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=enhttp://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/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .






 --
 “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/groups/opt_out.

-- 
-- 
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/groups/opt_out.

Re: In-order triggering of watches on mutable state

2013-08-01 Thread Timothy Baldridge

That's not the problem. The problem is that agent sends (just like
watchers) are dispatched outside of the transaction. So multiple threads
accessing the same refs can be releasing sends to agents at the same time.
This in turn means that the messages being sent to the agents can arrive
out-of-order since one thread could pause allowing the other to send
messages.

Something to think about though is that you probably should be dealing with
commutative operations. So instead of sending set bank account to X to
refs/agents, instead send increment bank account by 10. In this way many
of these race-conditions no longer exist.

Timothy

On Thu, Aug 1, 2013 at 6:54 AM, Mike Drogalis madrush...@gmail.com wrote:

Cedric: Will agents give me the guarantee that if I have something in
Agent A, and I want to move it to agent B, and I do this inside a
transaction:
- perceivers will see it in A at read point
- perceivers will see it in B at write point
- perceivers will never see it in neither nor both?

If that's the case, which is effectively synchronous coordination (I
think?), what do refs buy you that agents don't?

On Thu, Aug 1, 2013 at 5:57 AM, Cedric Greevey cgree...@gmail.com wrote:

On Wed, Jul 31, 2013 at 1:12 PM, Mike Drogalis madrush...@gmail.comwrote:

Good reasoning; that makes a lot of sense -- even if intuitively it
doesn't follow through.

I'll do some more thinking about my concurrency needs and come back with
a follow up question later. Thanks man!

On Wed, Jul 31, 2013 at 12:51 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

Deadlocks? Imagine a watch that ended up running a transaction against
the ref it was triggered from. Sounds insane, but it could be fairly easy
to do in a situation like this:

ref - calls watchers - calls fn1 - calls fn 2 - calls fn3 - starts
transaction on ref

Since watchers are notified outside of a ref transaction deadlocking is
impossible. Inside a transaction you'd have a instant deadlock.

Timothy Baldridge

On Wed, Jul 31, 2013 at 10:47 AM, Mike Drogalis
madrush...@gmail.comwrote:

I'll play around with agents for this when I get some more free time.

On Wed, Jul 31, 2013 at 12:25 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

You might want to consider switching to agents (or something else) I
don't think it's possible to do what you want with refs.

Timothy Baldridge

On Wed, Jul 31, 2013 at 10:08 AM, Mike Drogalis madrush...@gmail.com
wrote:

Thanks for the link. :) I understand that the behavior I'm seeing is
correct. Any idea how to achieve the desired behavior, though?

On Wed, Jul 31, 2013 at 12:06 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

The answer is here:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L361

Agents and watches are dispatched outside of the transaction
locking. This means that multiple transactions could be executing
watches
in parallel, and hence execute out of order.

Timothy Baldridge

On Wed, Jul 31, 2013 at 9:43 AM, Michael Drogalis
madrush...@gmail.com wrote:

I can precisely exemplify the behavior here:

https://gist.github.com/MichaelDrogalis/6123177

On Wednesday, July 31, 2013 11:13:17 AM UTC-4, Michael Drogalis
wrote:

Aaron: Yep, I'm aware - and am using the value provided by the
last parameter.

This is going to be tough to show the problem without bringing
more details of my concurrency set up.
I'm not sure if this will exhibit the problem, but this is what
it boils down to:

https://gist.github.com/**MichaelDrogalis/6122834https://gist.github.com/MichaelDrogalis/6122834

When enough threads are trying to write to the queue, the watches
triggered later can finish before watches triggered earlier.

On Wednesday, July 31, 2013 11:05:16 AM UTC-4, Aaron Cohen wrote:

A watcher fn has 4 parameters: key, reference, old-state,
new-state

If you use old-state and new-state rather than the reference,
you should not see your problem.

--Aaron

On Wed, Jul 31, 2013 at 11:00 AM, Michael Drogalis
madru...@gmail.com wrote:

Problem:

I have a ref representing a queue of people in line.
I add a watch to the ref to print out the contents

[ANN] Tawny-OWL 0.12

2013-08-01 Thread Phillip Lord


I am pleased to announce the release of tawny-owl, Version 0.12.

This package allows users to construct OWL ontologies in a fully programmatic
environment, namely Clojure. This means the user can take advantage of
programmatic language to automate and abstract the ontology over the
development process; also, rather than requiring the creation of ontology
specific development environments, a normal programming IDE can be used;
finally, a human readable text format means that we can integrate with the
standard tooling for versioning and distributed development.

OWL is a W3C standard ontology representation language; an ontology is a fully
computable set of statements, describing the things and their relationships.
These statements can be reasoned over, inferences made and contradictions
detected automatically using an off-the-shelf reasoner. 


0.12 is planned to be the final, feature complete release before the 1.0
release. New features will not be added before 1.0. Key new features in 0.12
are:

- Complete support for OWL 2, include data types
- OWL documentation can be queries as normal clojure metadata
- New namespaces, query and fixture
- Completion of rendering functionality
- Regularisation of interfaces: where relevant functions now take an ontology
  as  the first argument.
- Updated to Hermit 1.3.7.3, OWL API 3.4.5


Tawny is available at https://github.com/phillord/tawny-owl, or as a maven
artifact from http://clojars.org. The development of tawny-owl is documented
in my journal at
http://www.russet.org.uk/blog/category/all/professional/tech/tawny-owl

-- 
-- 
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/groups/opt_out.

Re: In-order triggering of watches on mutable state

2013-08-01 Thread Mike Drogalis

Unfortunately, my problem is not one where the operation is communitive. To
be concrete,
I am dealing with multiple threads plucking elements off the top of many
different queues, and
putting them into a new queue. So adding element A, then B results in line
[A, B], whereas
adding element B, then A results in line [B, A], which aren't equal.

Maybe I'm misunderstanding my problem, perhaps it is communitive. I just
don't see it though.

On Thu, Aug 1, 2013 at 9:13 AM, Timothy Baldridge tbaldri...@gmail.comwrote:

Something to think about though is that you probably should be dealing
with commutative operations. So instead of sending set bank account to X
to refs/agents, instead send increment bank account by 10. In this way
many of these race-conditions no longer exist.

Timothy

On Thu, Aug 1, 2013 at 6:54 AM, Mike Drogalis madrush...@gmail.comwrote:

Cedric: Will agents give me the guarantee that if I have something in
Agent A, and I want to move it to agent B, and I do this inside a
transaction:
- perceivers will see it in A at read point
- perceivers will see it in B at write point
- perceivers will never see it in neither nor both?

If that's the case, which is effectively synchronous coordination (I
think?), what do refs buy you that agents don't?

On Thu, Aug 1, 2013 at 5:57 AM, Cedric Greevey cgree...@gmail.comwrote:

On Wed, Jul 31, 2013 at 1:12 PM, Mike Drogalis madrush...@gmail.comwrote:

Good reasoning; that makes a lot of sense -- even if intuitively it
doesn't follow through.

I'll do some more thinking about my concurrency needs and come back
with a follow up question later. Thanks man!

On Wed, Jul 31, 2013 at 12:51 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

Deadlocks? Imagine a watch that ended up running a transaction against
the ref it was triggered from. Sounds insane, but it could be fairly easy
to do in a situation like this:

ref - calls watchers - calls fn1 - calls fn 2 - calls fn3 -
starts transaction on ref

Since watchers are notified outside of a ref transaction deadlocking
is impossible. Inside a transaction you'd have a instant deadlock.

Timothy Baldridge

On Wed, Jul 31, 2013 at 10:47 AM, Mike Drogalis
madrush...@gmail.comwrote:

I'll play around with agents for this when I get some more free time.

On Wed, Jul 31, 2013 at 12:25 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

You might want to consider switching to agents (or something else) I
don't think it's possible to do what you want with refs.

Timothy Baldridge

On Wed, Jul 31, 2013 at 10:08 AM, Mike Drogalis
madrush...@gmail.com wrote:

Thanks for the link. :) I understand that the behavior I'm seeing
is correct. Any idea how to achieve the desired behavior, though?

On Wed, Jul 31, 2013 at 12:06 PM, Timothy Baldridge
tbaldri...@gmail.com wrote:

The answer is here:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L361

Agents and watches are dispatched outside of the transaction
locking. This means that multiple transactions could be executing
watches
in parallel, and hence execute out of order.

Timothy Baldridge

On Wed, Jul 31, 2013 at 9:43 AM, Michael Drogalis
madrush...@gmail.com wrote:

I can precisely exemplify the behavior here:

https://gist.github.com/MichaelDrogalis/6123177

On Wednesday, July 31, 2013 11:13:17 AM UTC-4, Michael Drogalis
wrote:

Aaron: Yep, I'm aware - and am using the value provided by the
last parameter.

This is going to be tough to show the problem without bringing
more details of my concurrency set up.
I'm not sure if this will exhibit the problem, but this is what
it boils down to:

https://gist.github.com/**MichaelDrogalis/6122834https://gist.github.com/MichaelDrogalis/6122834

When enough threads are trying to write

[GSoC] core.matrix NDArray: after the first half

2013-08-01 Thread Dmitry Groshev

So it's the mid-point of GSoC and a good time to review what's already done 
and what is yet to be done.

The main focus of first half of the summer was making NDArray work. NDArray 
is a new implementation of core.matrix protocols, intended to become the 
default one. It's implemented in pure Clojure as strided array over flat 
Java arrays, similar to NumPy's NDArray.

Well, it works. Some highlights:

 - It works as as fully functional, N-dimensional array as part of 
core.matrix
 - It passes all current tests
 - A few bugs were fixed in core.matrix itself, uncovered during 
implementation testing.
 - An overview of implemented protocols is now generated from the code 
directly as html page and can be seen at [1].
 - Some of the default implementations within core.matrix have been 
rewritten to be faster and use NDArray internally where it's appropriate.

You can find examples of NDArray usage at [2].

An important issue in such libraries is performance. The first and most 
obvious step to win some is to use specialized primitive arrays instead of 
Object one; the trouble is that most of the code is duplicated many times. 
Clojure, with it's homoiconicity and ease of code juggling, is a big win 
here — after introduction of some magic main implementation of ndarray is 
almost completely free of boring repetition [3], despite generating code 
for 4 different types (and it's easily extensible).

Then it's time for type hinting, little gory details of hidden type 
coercion, playing with memory access patterns. Matrix multiplication was a 
very important playground for me: it's fairly easy on the surface, well 
studied and easily checkable. Moreover, I have a reference point: Mike 
Anderson's Vectorz library [4]. After some time I've managed to beat it, at 
least at large matrices [5] (look at ndarray-double; ndarray now uses 
default implementation, which was based on persistent vectors in the past 
and became 2-3x faster after rewrite). There is plenty of room for 
improvement on small matrices, though. I'm writing a big post on this 
optimization experience, stay tuned :)

What's next? A couple of interesting problems/tasks still await:

- a lot of elementwise operations are very repetitive in code and are 
differentiated one from another only because of performance overhead of 
map-like dynamic solutions. They should really be a macro in case of 
NDArray; and what stops us from exposing this macro through an API so users 
can write very efficient custom elementwise operations? AFAIK, nothing. I'm 
very curious about how far this approach can be pushed.
- for now there are some repetitive patterns with iterating index-wise over 
array and finding true index inside it by multiplicating indexes by 
strides. First benchmarks show that rewriting this loops to count true 
index, stepping by stride instead of by one, is beneficial to performance. 
An open question is whether it's possible to hide this in code generation 
without significantly hurting readability of code.
- can we come up with better way to slice arrays in arbitrary ways (boolean 
vectors? boolean functions?) and in the same time make it efficient?
- how hard it would be to port all this to CLJS and be efficient there too?

Of course, there is also a huge pile of more mundane, but even more 
important work: documentation (will need to patch Marginalia, I suppose), 
tests (I'm very happy that simple-check [6] already exists, property-based 
testing is a giant leap forward, too often overlooked), infrastructure 
(currently I'm trying to find the best format to present performance test 
results at HTML page) and more optimization/protocol reimplementation.

It has been a very interesting experience to day to work full-time on an 
open-source library. It was not so glossy and bleeding-edge, making the 
library work faster and more correct, but definitely very interesting. I've 
learned a lot about numerical programming and Clojure; I'm very pleased by 
a raise in my Clojure productivity during this project so far. It was also 
very enjoyable to work with my mentor, Mike Anderson. I'm looking forward 
to push core.matrix as far as I can during the time left.

[1]: http://mikera.github.io/matrix-api/summary.html
[2]: https://gist.github.com/si14/6131125
[3]: 
https://github.com/mikera/matrix-api/blob/develop/src/main/clojure/clojure/core/matrix/impl/ndarray.clj
[4]: https://github.com/mikera/vectorz/
[5]: https://gist.github.com/si14/6127020
[6]: https://github.com/reiddraper/simple-check

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

Re: In-order triggering of watches on mutable state

2013-08-01 Thread Timothy Baldridge

Ding! You said the magic words! For queues, can I recommend one of the
following?

http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html

According to Rich why doesn't Clojure provide queues? The Java ones are
just fine! Use them

Also, if you have a large number of queues and don't want to tie up
threads, have a look a core.async (http://github.com/clojure/core.async)
it's designed exactly for this sort of thing.

With either of these you may still have some fun with having shared state
between the threads, but perhaps these approaches may help a bit.

Timothy

On Thu, Aug 1, 2013 at 7:21 AM, Mike Drogalis madrush...@gmail.com wrote:

Unfortunately, my problem is not one where the operation is communitive.
To be concrete,
I am dealing with multiple threads plucking elements off the top of many
different queues, and
putting them into a new queue. So adding element A, then B results in line
[A, B], whereas
adding element B, then A results in line [B, A], which aren't equal.