Find maps with embedded functions in a set

[Goldritter]

I have following problem. 
I have a set with different objects (maps). Normally the maps contains only 
a key with a value which is a number or a collection. 
For example like this:

(def testset #{ {:a 3 :b 5 :c 6} 
   {:a 3 :b 5 :c 7} 
   {:a 3 :b 5 :c 8}
   {:a 3 :b 5 :g #{1 2 3 4 5)

If I now use contains? with the map as key I get true, even when the order 
of the number in the set is not the same as the order I used during the 
"creation" of the map.
=> (contains? testset {:a 3 :b 5 :g #{1 2 3 4 5}})
true
=> (contains? testset {:a 3 :b 5 :g #{1 2 3 5 4}})
true

But if the map contains a function like in the following example It doe not 
find the map.

=> (def testset #{ {:a 3 :b 5 :c 6} 
   {:a 3 :b 5 :c 7} 
   {:a 3 :b 5 :c 8}
   {:a 3 :b 5 :g #{1 2 3 4 5}}
   {:a 3 :h 5 :c #(+ 1 1)}})

=> (contains? testset {:a 3 :h 5 :c #(+ 1 1)})
false


I knew that 
=> (= #(+ 1 1) #(+ 1 1))
false

because these functions are different objects, as I see on the hash values
=> (hash #(+ 1 1))
   (hash #(+ 1 1))
1965115675
784046647

Now I wonder if it is possible to find a map in a set, which contains a 
function as value.
Is this possible?


I tried it with ' too.

(def testset #{ {:a 3 :b 5 :c 6} 
   {:a 3 :b 5 :c 7} 
   {:a 3 :b 5 :c 8}
   {:a 3 :b 5 :g #{1 2 3 4 5}}
   {:a 3 :h 5 :c '#(+ 1 1)}})

And could use the contains? function
=> (contains? testset {:a 3 :h 5 :c '#(+ 1 1)})
true

But when I tried to access the value I got an Exception
=>(c: {:a 3 :h 5 :c '#(+ 1 1)})
RuntimeException Invalid token: c:  clojure.lang.Util.runtimeException 
(Util.java:219)
{:a 3, :c (fn* [] (+ 1 1)), :h 5}

The same with get
=> (get {:a 3 :h 5 :c '#(+ 1 1)} c:)
RuntimeException Invalid token: c:  clojure.lang.Util.runtimeException 
(Util.java:219)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException 
(Util.java:219)

-- 
-- 
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: Find maps with embedded functions in a set

[Jim]

On 31/07/13 11:01, Goldritter wrote:

But when I tried to access the value I got an Exception
=>(c: {:a 3 :h 5 :c '#(+ 1 1)})
RuntimeException Invalid token: c: clojure.lang.Util.runtimeException 
(Util.java:219)

{:a 3, :c (fn* [] (+ 1 1)), :h 5}

The same with get
=> (get {:a 3 :h 5 :c '#(+ 1 1)} c:)
RuntimeException Invalid token: c: clojure.lang.Util.runtimeException 
(Util.java:219)
RuntimeException Unmatched delimiter: ) 
clojure.lang.Util.runtimeException (Util.java:219)


it seems to me that you wrote c: instead of :c ...try again with the 
correct key :)


Jim

--
--
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: Find maps with embedded functions in a set

[Jim]

On 31/07/13 11:19, Jim wrote:

On 31/07/13 11:01, Goldritter wrote:

But when I tried to access the value I got an Exception
=>(c: {:a 3 :h 5 :c '#(+ 1 1)})
RuntimeException Invalid token: c: clojure.lang.Util.runtimeException 
(Util.java:219)

{:a 3, :c (fn* [] (+ 1 1)), :h 5}

The same with get
=> (get {:a 3 :h 5 :c '#(+ 1 1)} c:)
RuntimeException Invalid token: c: clojure.lang.Util.runtimeException 
(Util.java:219)
RuntimeException Unmatched delimiter: ) 
clojure.lang.Util.runtimeException (Util.java:219)


it seems to me that you wrote c: instead of :c ...try again with the 
correct key :)


Jim


I just tried it:

user=> ((eval (:c {:a 3 :h 5 :c '#(+ 1 1)})))
2

Jim :)

--
--
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: Find maps with embedded functions in a set

[Marcus Lindner]

Ups. [?]
Sorry.
Have not seen this typo :(.


2013/7/31 Jim 

> On 31/07/13 11:01, Goldritter wrote:
>
>> But when I tried to access the value I got an Exception
>> =>(c: {:a 3 :h 5 :c '#(+ 1 1)})
>> RuntimeException Invalid token: c: clojure.lang.Util.**runtimeException
>> (Util.java:219)
>> {:a 3, :c (fn* [] (+ 1 1)), :h 5}
>>
>> The same with get
>> => (get {:a 3 :h 5 :c '#(+ 1 1)} c:)
>> RuntimeException Invalid token: c: clojure.lang.Util.**runtimeException
>> (Util.java:219)
>> RuntimeException Unmatched delimiter: ) clojure.lang.Util.**runtimeException
>> (Util.java:219)
>>
>
> it seems to me that you wrote c: instead of :c ...try again with the
> correct key :)
>
> Jim
>
>
> --
> --
> 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+unsubscribe@**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+unsubscribe@**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.


<<322.gif>>

Getting a living standalone jar with "lein uberjar" and a handful of resources

[Alex Fowler]

I have an application which is built fine with uberjar with an exception of 
two things which do not get incuded:
1) Additonal jar files (about 150Mb) from various Java libraries that are 
not present on Clojars and that I have no power of will or time of trying 
to upload them there. This folder is speciiified with :resource-paths in 
project.clj 
2) About 150Mb of resources such as pictures and video-files which are 
loaded by these java libraries using *their own methods* which I cannot 
change.

What lein uberjar does - it skips these files and simply creates an 
incomplete jar with my compiled sources, which does not launch because it 
is missing those files. However, "lein run" works just fine!

My question is: how do I make a single jar with lein that, being run with 
"java -jar" exposes the same behavior as simply "lein run"?

PS: As an idea: when I was programming in Scala, I was using 
"com.jdotsoft.jarloader.JarClassLoader" which was the entry point in my app 
and I could simply put all files into the jar and it would search them in 
that order:
1) recursively inside the jar
2) in the same folder as the jar (which would allow simple externalizing of 
files like settings files if needed to be exposed to users).
3) in system path folders...
Maybe there is a way to use that magical JarClassLoader with 
Leiningen/Clojure?

-- 
-- 
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: Find maps with embedded functions in a set

[Cedric Greevey]

If you saved the original function instance, you can use it to find the
map. This should work:

(let [f #(+ 1 1)
  s #{{:a 3 :b 5 :c f}}]
  (contains? s {:a 3 :b 5 :c f}))

Note that the value for the :c key is now the same *instance* of that
function.

Storing the function source, with ', instead of the function itself works
until you want to call the function. Then you need eval. You might want to
avoid that, perhaps by using a map of quoted functions to compiled
functions (you can also use something similar to avoid compiling each
single one of these functions over and over again at runtime even if you do
use eval -- or just (def meval (memoize eval)) and use meval, or something).

If you don't use eval, you can use other keys instead of the function
source; a suitable keyword name like :add-x might be good, so you'd end up
with {:a 3 :b 5 :c :add-x} in your data structure and a {:add-x #(+ 1 1)}
in a lookup table somewhere.



On Wed, Jul 31, 2013 at 6:34 AM, Marcus Lindner <
marcus.goldritter.lind...@gmail.com> wrote:

> Ups. [?]
> Sorry.
> Have not seen this typo :(.
>
>
> 2013/7/31 Jim 
>
>> On 31/07/13 11:01, Goldritter wrote:
>>
>>> But when I tried to access the value I got an Exception
>>> =>(c: {:a 3 :h 5 :c '#(+ 1 1)})
>>> RuntimeException Invalid token: c: clojure.lang.Util.**runtimeException
>>> (Util.java:219)
>>> {:a 3, :c (fn* [] (+ 1 1)), :h 5}
>>>
>>> The same with get
>>> => (get {:a 3 :h 5 :c '#(+ 1 1)} c:)
>>> RuntimeException Invalid token: c: clojure.lang.Util.**runtimeException
>>> (Util.java:219)
>>> RuntimeException Unmatched delimiter: ) clojure.lang.Util.**runtimeException
>>> (Util.java:219)
>>>
>>
>> it seems to me that you wrote c: instead of :c ...try again with the
>> correct key :)
>>
>> Jim
>>
>>
>> --
>> --
>> 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+unsubscribe@**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+unsubscribe@**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.
>
>
>

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


<<322.gif>>

Emitting a proper line numbers in code generated by macro

[Dmitry Groshev]

Hello, dear All.

Is there any proper way to preserve line numbers in stack traces with code 
generation? I have a bunch of macroses that store their arguments in a 
variable, and one that emits all stored forms with some modifications. 
Consequently, in all stacktraces I see the line that contains that emission 
instead of the one that was a base of generation.

-- 
-- 
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: October Barnstorming in Europe

[Tj Gabbour]

That is very exciting. Will talk with my usergroup. I'd personally really 
love a discussion on what we've been up to in promoting Clojure locally, 
and what your thoughts are.

For instance, I'm no longer enthusiastic about coming up with a talk (which 
goes in one ear and out the other), but rather trying increasingly gonzo 
things at (say) NoSQL user groups. Like announcing that the attendees need 
to avert some sudden crisis by investigating data... which just happens to 
be in my laptop's Datomic instance. Or explore how my dinky fruit stand 
illegally collects customer data and mines it with Cascalog, because I 
dream of one day triumphing over Walmart. If nothing else, people hopefully 
find it an amusing evening, because Clojure is fun.

(And it seems hard to really describe the experience of dynamism, with a 
static talk. Of course, we also do more conventional workshops.)


All the best,
  Tj

On Tuesday, July 30, 2013 10:59:14 PM UTC+2, stuart@gmail.com wrote:
>
> Michael Nygard [1] and Stu Halloway [2] will be in Europe for much of
> October.  We are speaking at a bunch of conferences [3], [4], [5], and
> [6] and hope to see some of you there.
>
> Since we are already on the road, we thought it would be a good
> opportunity to turn this into a barnstorming tour, working with teams
> who are looking for help with Clojure, ClojureScript, and/or Datomic.
> If you would like to have us work with your team, pricing is as
> follows:
>
> * Free for user group talks
> * $1500 for a 90 minute talk
> * $5000 for a day of training or consulting
> * $0 for travel expenses (we are already there!)
>
> Our prepared materials are summarized at [7] and [8], or feel free to 
> request
> specific topics.
>
> If you are interested in scheduling a meeting, please send an email to
> in...@thinkrelevance.com , subject line: "October 
> Barnstorming".
> Includes in the body of the message the kind of event you are
> interested in, as well as possible dates and locations.
>
> Regards,
> Michael and Stu
>
> [1] http://thinkrelevance.com/team/members/stuart-halloway
> [2] http://thinkrelevance.com/team/members/michael-nygard
> [3] http://euroclojure.com/2013/
> [4] http://reaktordevday.fi/2013/
> [5] http://gotocon.com/berlin-2013/
> [6] http://gotocon.com/amsterdam-2013/upcomingevents/
> [7] https://github.com/stuarthalloway/presentations/wiki
> [8] https://github.com/mtnygard/presentations/wiki
>
>

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

clojure.org/java_interop

[Simon Morgan]

There seems to be a problem with the markup on 
http://clojure.org/java_interop.

(bean [[http://java.awt.Color/black|java.awt.Color/black]])


should probably be

 (bean java.awt.Color/black)

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

In-order triggering of watches on mutable state

[Michael Drogalis]

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: []



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

[Timothy Baldridge]

Code? It's hard to debug if we can't see what's going on.


On Wed, Jul 31, 2013 at 9:00 AM, Michael Drogalis 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: []
> 
> 
>
> 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 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.
>
>
>



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

[Aaron Cohen]

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 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: []
> 
> 
>
> 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 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

[Michael Drogalis]

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/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 
> 
> > 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: []
>> 
>> 
>>
>> 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=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.
>>  
>>  
>>
>
>

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

[Michael Drogalis]

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/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 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: []
>>> 
>>> 
>>>
>>> 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=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.
>>>  
>>>  
>>>
>>
>>

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

[Timothy Baldridge]

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 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/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 
>>> 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: []
 
 

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



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



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

[Mike Drogalis]

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 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 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/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 
 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: []
> 
> 
>
> 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=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
> .
>
>
>

  --
>> --
>> 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.
>>
>>
>>
>
>
>
> --
> “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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/0b5HWJE6Jx4/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/groups/opt_out.
>
>
>

-- 
-- 
You received thi

Re: Getting a living standalone jar with "lein uberjar" and a handful of resources

[Kevin Downey]

On 7/31/13 4:18 AM, Alex Fowler wrote:
> I have an application which is built fine with uberjar with an exception of 
> two things which do not get incuded:
> 1) Additonal jar files (about 150Mb) from various Java libraries that are 
> not present on Clojars and that I have no power of will or time of trying 
> to upload them there. This folder is speciiified with :resource-paths in 
> project.clj 
> 2) About 150Mb of resources such as pictures and video-files which are 
> loaded by these java libraries using *their own methods* which I cannot 
> change.
> 
> What lein uberjar does - it skips these files and simply creates an 
> incomplete jar with my compiled sources, which does not launch because it 
> is missing those files. However, "lein run" works just fine!
> 
> My question is: how do I make a single jar with lein that, being run with 
> "java -jar" exposes the same behavior as simply "lein run"?
> 
> PS: As an idea: when I was programming in Scala, I was using 
> "com.jdotsoft.jarloader.JarClassLoader" which was the entry point in my app 
> and I could simply put all files into the jar and it would search them in 
> that order:
> 1) recursively inside the jar
> 2) in the same folder as the jar (which would allow simple externalizing of 
> files like settings files if needed to be exposed to users).
> 3) in system path folders...
> Maybe there is a way to use that magical JarClassLoader with 
> Leiningen/Clojure?
> 

clojars is just a maven repo, and a simple maven repo is just a http server.

you can setup your own "private maven repo" easily by copying the
directory structure of your ~/.m2 to an http server somewhere.

for something more full featured you can setup something like apache
archiva (which is what I use at work) http://archiva.apache.org/index.cgi

once you have a private maven repo you can deploy whatever you want to
it, and use whatever you deploy has a dependency as normal


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



signature.asc
Description: OpenPGP digital signature

Re: In-order triggering of watches on mutable state

[Timothy Baldridge]

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 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 
> 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 
>> 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/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  > 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: []
>> 
>> 
>>
>> 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=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
>> .
>>
>>
>>
>
>  --
>>> --
>>> 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.
>>>
>>>
>>>
>>
>>
>>
>> --
>> “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 a topic in the

Re: Getting a living standalone jar with "lein uberjar" and a handful of resources

[Alex Fowler]

Thank you for the advice and I will explore the Archiva initiative, 
however, I think it would do for jars, but not to managing application 
resources during development. For example, pictures used in the application 
may change several times a day, depending on how designers work, and having 
it managed by something other than the trivial OS filesystem is an 
overkill.. Besides that, the java engine that I am using, has it's own 
means of loading files from locations available for search which, I think, 
does not include getting something from a repository...

среда, 31 июля 2013 г., 20:19:21 UTC+4 пользователь red...@gmail.com 
написал:
>
> On 7/31/13 4:18 AM, Alex Fowler wrote: 
> > I have an application which is built fine with uberjar with an exception 
> of 
> > two things which do not get incuded: 
> > 1) Additonal jar files (about 150Mb) from various Java libraries that 
> are 
> > not present on Clojars and that I have no power of will or time of 
> trying 
> > to upload them there. This folder is speciiified with :resource-paths in 
> > project.clj 
> > 2) About 150Mb of resources such as pictures and video-files which are 
> > loaded by these java libraries using *their own methods* which I cannot 
> > change. 
> > 
> > What lein uberjar does - it skips these files and simply creates an 
> > incomplete jar with my compiled sources, which does not launch because 
> it 
> > is missing those files. However, "lein run" works just fine! 
> > 
> > My question is: how do I make a single jar with lein that, being run 
> with 
> > "java -jar" exposes the same behavior as simply "lein run"? 
> > 
> > PS: As an idea: when I was programming in Scala, I was using 
> > "com.jdotsoft.jarloader.JarClassLoader" which was the entry point in my 
> app 
> > and I could simply put all files into the jar and it would search them 
> in 
> > that order: 
> > 1) recursively inside the jar 
> > 2) in the same folder as the jar (which would allow simple externalizing 
> of 
> > files like settings files if needed to be exposed to users). 
> > 3) in system path folders... 
> > Maybe there is a way to use that magical JarClassLoader with 
> > Leiningen/Clojure? 
> > 
>
> clojars is just a maven repo, and a simple maven repo is just a http 
> server. 
>
> you can setup your own "private maven repo" easily by copying the 
> directory structure of your ~/.m2 to an http server somewhere. 
>
> for something more full featured you can setup something like apache 
> archiva (which is what I use at work) http://archiva.apache.org/index.cgi 
>
> once you have a private maven repo you can deploy whatever you want to 
> it, and use whatever you deploy has a dependency as normal 
>
>
> -- 
> And what is good, Phaedrus, 
> And what is not good-- 
> Need we ask anyone to tell us these things? 
>
>

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

[GSoC] CinC mid-term evaluation status

[Nicola Mometto]

For the last month or so I've been working on completing Aaron Cohen's
CinC.

As planned, this first period has been spent working extensively on the
analyzer improving it to the point where it's competitive with the
analysis done in Compiler.java while keeping it clojurescript-like and
extensible via small composable passes over the AST [1].

There's some doc about the passes that are implemented and about the AST
nodes produced at in the doc directory of the repository [2].

Notably, the jvm analyzer is able to propagate the tag of expressions
to infer the tag of more complex expressions avoiding the necessity
of explicit tagging in order to avoid run-time reflection in some cases.

There are two "main" namespaces: `cinc.analyzer` and
`cinc.analyzer.jvm`; the first one should not be used directly but
should rather be extended to platform-specific forms and passes as done
by `cinc.analyzer.jvm`.

Work on the jvm emitter will start soon.

Thanks,
Nicola.

[1] https://github.com/Bronsa/CinC/tree/analyzer-WIP/src/cinc/analyzer/passes
[2] https://github.com/Bronsa/CinC/tree/analyzer-WIP/doc

-- 
-- 
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: changing a value in a vector of maps

[Gary Johnson]

Here's the code analogue of your find-assoc-in function for the approach 
Cedric is proposing. I actually came to the same solution before reading 
the responses to your post, so it's good to see that others also think this 
is a more memory efficient approach (obviously for larger vectors than the 
example).

(defn my-find-assoc-in
  [[test-key update-key] [test-val update-val] mapvec]
  (reduce
   (fn [v idx] (if (= (get-in v [idx test-key]) test-val)
   (assoc-in v [idx update-key] update-val)
 v))
   mapvec
   (range (count mapvec


Happy hacking,
  ~Gary

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

[Mike Drogalis]

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 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 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 > > 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 
>>> 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/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: []
>>> 
>>> 
>>>
>>> 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=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
>>> .
>>>
>>>
>>>
>>
>>  --
 --
 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.



>>>
>>>
>>>
>>> --
>>> “One of the main causes of the fall of the Roman Empire was that–lacking
>>> zero–they had no way to indicate successf

Re: In-order triggering of watches on mutable state

[Timothy Baldridge]

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

> 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 
> 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 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 >>> > 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/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: []
 
 

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



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

Re: [GSoC] CinC mid-term evaluation status

[Ben Wolfson]

This is very cool!


On Wed, Jul 31, 2013 at 9:41 AM, Nicola Mometto  wrote:

>
> For the last month or so I've been working on completing Aaron Cohen's
> CinC.
>
> As planned, this first period has been spent working extensively on the
> analyzer improving it to the point where it's competitive with the
> analysis done in Compiler.java while keeping it clojurescript-like and
> extensible via small composable passes over the AST [1].
>
> There's some doc about the passes that are implemented and about the AST
> nodes produced at in the doc directory of the repository [2].
>
> Notably, the jvm analyzer is able to propagate the tag of expressions
> to infer the tag of more complex expressions avoiding the necessity
> of explicit tagging in order to avoid run-time reflection in some cases.
>
> There are two "main" namespaces: `cinc.analyzer` and
> `cinc.analyzer.jvm`; the first one should not be used directly but
> should rather be extended to platform-specific forms and passes as done
> by `cinc.analyzer.jvm`.
>
> Work on the jvm emitter will start soon.
>
> Thanks,
> Nicola.
>
> [1]
> https://github.com/Bronsa/CinC/tree/analyzer-WIP/src/cinc/analyzer/passes
> [2] https://github.com/Bronsa/CinC/tree/analyzer-WIP/doc
>
> --
> --
> 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.
>
>
>


-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
-- 
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: [GSoC] CinC mid-term evaluation status

[Ambrose Bonnaire-Sergeant]

Very exciting! Keep up the great work Nicola!

Ambrose


On Thu, Aug 1, 2013 at 12:41 AM, Nicola Mometto  wrote:

>
> For the last month or so I've been working on completing Aaron Cohen's
> CinC.
>
> As planned, this first period has been spent working extensively on the
> analyzer improving it to the point where it's competitive with the
> analysis done in Compiler.java while keeping it clojurescript-like and
> extensible via small composable passes over the AST [1].
>
> There's some doc about the passes that are implemented and about the AST
> nodes produced at in the doc directory of the repository [2].
>
> Notably, the jvm analyzer is able to propagate the tag of expressions
> to infer the tag of more complex expressions avoiding the necessity
> of explicit tagging in order to avoid run-time reflection in some cases.
>
> There are two "main" namespaces: `cinc.analyzer` and
> `cinc.analyzer.jvm`; the first one should not be used directly but
> should rather be extended to platform-specific forms and passes as done
> by `cinc.analyzer.jvm`.
>
> Work on the jvm emitter will start soon.
>
> Thanks,
> Nicola.
>
> [1]
> https://github.com/Bronsa/CinC/tree/analyzer-WIP/src/cinc/analyzer/passes
> [2] https://github.com/Bronsa/CinC/tree/analyzer-WIP/doc
>
> --
> --
> 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: [ANN] Vertigo: fast, idiomatic C-style structs

[Ezra Lee]

Hi,
I'm trying out vertigo and hoping you can help me figure out what I am 
missing, I get an error when I use get-in:

; nREPL 0.1.8-preview
user> (use 'vertigo.structs)
nil
user> (def-typed-struct ints-and-floats :ints (array uint32 10) :floats 
(array float32 10))
#'user/ints-and-floats
user> (def x {:ints (range 10) :floats (map float (range 10))})
#'user/x
user> (require '[vertigo.core :as v])
nil
user> (def ^:ints-and-floats s (v/marshal-seq ints-and-floats [x]))
#'user/s
user> (v/get-in s [:floats 4])
IllegalArgumentException Invalid field '4' for type ints-and-floats 
 vertigo.core/validate-lookup (core.clj:177)
user> (v/get-in s [4 :floats])
IllegalArgumentException   java.nio.Buffer.position (Buffer.java:216)

Thanks,
Ezra

On Tuesday, July 9, 2013 11:56:03 PM UTC-4, Zach Tellman wrote:
>
> Last year, I gave a talk at the Conj on my attempt to write an AI for the 
> board game Go.  Two things I discovered is that it was hard to get 
> predictable performance, but even once I made sure I had all the right type 
> hints, there was still a lot of room at the bottom for performance 
> improvements.  Towards the end [1], I mentioned a few ideas for 
> improvements, one of which was simply using ByteBuffers rather than objects 
> to host the data.  This would remove all the levels of indirection, giving 
> much better cache coherency, and also allow for fast unsynchronized 
> mutability when the situation called for it.
>
> So, ten months and several supporting libraries [2] [3] later, here it is: 
> https://github.com/ztellman/vertigo
>
> At a high level, this library is useful whenever your datatype has a fixed 
> layout and is used more than once.  Depending on your type, it will give 
> you moderate to large memory savings, and if you're willing to forgo some 
> of core library in favor of Vertigo's operators, you can get significant 
> performance gains on batch operations.  And, in the cases where performance 
> doesn't matter, it will behave exactly like any other Clojure data 
> structure.
>
> I want to point out that something like this would be more or less 
> impossible in Java; reading from an offset in a ByteBuffer without the 
> compile-time inference and validation provided by this library would be 
> pointlessly risky.  There's not a lot of low-level Clojure libraries, but 
> there's an increasing amount of production usage where people are using 
> Clojure for performance-sensitive work.  I'm looking forward to seeing what 
> people do with Vertigo and libraries like it.
>
> Zach
>
> [1] 
> http://www.youtube.com/watch?feature=player_detailpage&v=v5dYE0CMmHQ#t=1828s
> [2] https://github.com/ztellman/primitive-math
> [3] https://github.com/ztellman/byte-streams
>

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

[Mike Drogalis]

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 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 wrote:
>
>> 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 > > 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 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/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: []
> 
> 
>
> 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=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.

Re: CoderPost: Programmer's daily digest compiled by machine and human

[Marcus Blankenship]

Very cool, thanks!

On Saturday, July 27, 2013 1:15:51 PM UTC-7, Mingli Yuan wrote:
>
> Sorry for spamming,
>
> Recently I launch a paper.li site for compiled news on programming topics.
> The source of these news are from every related topics of pinboard.in.
>
> And I think the quality is still OK, and even better than what I 
> originally think.
> So I hope you can take a look if you are interested.
>
> http://coderpost.org/
>
> regards,
>
> Mingli
>
>

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

Korma belongs-to relationships

[serialhex]

I'm trying to set up a DB and some insert statements to get my data into
said DB.  The problem I'm having is in getting the customer data into the
proper tables, when they have a belongs-to relationship.  Do I explicitly
stick the ID of the `customer` in the `phone-number` or `address` insert
statements?  Or is there some spiffy way to do it?

Basically:

(let [id (insert db/customers (values { ...stuff... }))]
  (insert db/phone-number (values { ... :customer_id id })))

or is there another way?

Justin

p.s. the reason why phone-number is in it's own table is b/c a customer may
have more than one phone number: work, home, cell, spouse's cell, etc...

-- 
This email is protected under the Fourth Amendment of the United States of
America, the text of which states:

"The right of the people to be secure in their persons, houses, papers, and
effects, against unreasonable searches and seizures, shall not be violated,
and no Warrants shall issue, but upon probable cause, supported by Oath or
affirmation, and particularly describing the place to be searched, and the
persons or things to be seized."

This email is one of my "effects" and my "effects" shall be secure "against
unreasonable searches and seizures".  Collecting this email - seizing it -
or gathering data or metadata on this email - searching it - is prohibited
by the Constitution of the United States of America unless you have a
Warrant, issued with "probable cause, supported by Oath or affirmation" and
"particularly describing the place to be searched, and the persons or
things to be seized".
---
CFO: “What happens if we train people and they leave?”
CTO: “What if we don’t and they stay?”

-- 
-- 
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: [ANN] Vertigo: fast, idiomatic C-style structs

[Zach Tellman]

Hi Ezra,

This is admittedly a little confusing, but you're hinting 's' with the type
of the *element*.  Here you've created a sequence containing a single
'ints-and-floats' struct, so you'd want to do this:

user> (v/get-in s [0 :floats 4])
4.0
user> (v/get-in s [0])
{:ints (0 1 2 3 4 5 6 7 8 9), :floats (0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0
9.0)}

I'll try to make this clearer in the documentation.  Let me know if you
have any other questions.

Zach


On Wed, Jul 31, 2013 at 10:10 AM, Ezra Lee  wrote:

> Hi,
> I'm trying out vertigo and hoping you can help me figure out what I am
> missing, I get an error when I use get-in:
>
> ; nREPL 0.1.8-preview
> user> (use 'vertigo.structs)
> nil
> user> (def-typed-struct ints-and-floats :ints (array uint32 10) :floats
> (array float32 10))
> #'user/ints-and-floats
> user> (def x {:ints (range 10) :floats (map float (range 10))})
> #'user/x
> user> (require '[vertigo.core :as v])
> nil
> user> (def ^:ints-and-floats s (v/marshal-seq ints-and-floats [x]))
> #'user/s
> user> (v/get-in s [:floats 4])
> IllegalArgumentException Invalid field '4' for type ints-and-floats
>  vertigo.core/validate-lookup (core.clj:177)
> user> (v/get-in s [4 :floats])
> IllegalArgumentException   java.nio.Buffer.position (Buffer.java:216)
>
> Thanks,
> Ezra
>
> On Tuesday, July 9, 2013 11:56:03 PM UTC-4, Zach Tellman wrote:
>>
>> Last year, I gave a talk at the Conj on my attempt to write an AI for the
>> board game Go.  Two things I discovered is that it was hard to get
>> predictable performance, but even once I made sure I had all the right type
>> hints, there was still a lot of room at the bottom for performance
>> improvements.  Towards the end [1], I mentioned a few ideas for
>> improvements, one of which was simply using ByteBuffers rather than objects
>> to host the data.  This would remove all the levels of indirection, giving
>> much better cache coherency, and also allow for fast unsynchronized
>> mutability when the situation called for it.
>>
>> So, ten months and several supporting libraries [2] [3] later, here it
>> is: 
>> https://github.com/**ztellman/vertigo
>>
>> At a high level, this library is useful whenever your datatype has a
>> fixed layout and is used more than once.  Depending on your type, it will
>> give you moderate to large memory savings, and if you're willing to forgo
>> some of core library in favor of Vertigo's operators, you can get
>> significant performance gains on batch operations.  And, in the cases where
>> performance doesn't matter, it will behave exactly like any other Clojure
>> data structure.
>>
>> I want to point out that something like this would be more or less
>> impossible in Java; reading from an offset in a ByteBuffer without the
>> compile-time inference and validation provided by this library would be
>> pointlessly risky.  There's not a lot of low-level Clojure libraries, but
>> there's an increasing amount of production usage where people are using
>> Clojure for performance-sensitive work.  I'm looking forward to seeing what
>> people do with Vertigo and libraries like it.
>>
>> Zach
>>
>> [1] http://www.youtube.com/**watch?feature=player_**
>> detailpage&v=v5dYE0CMmHQ#t=**1828s
>> [2] 
>> https://github.com/ztellman/**primitive-math
>> [3] 
>> https://github.com/**ztellman/byte-streams
>>
>  --
> --
> 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/BayfuaqMzvs/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/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...@googlegrou

Re: [ANN] Vertigo: fast, idiomatic C-style structs

[Zach Tellman]

Actually, looking at the readme, I can see the code you were trying to use.
 Sorry, I'm not sure how I didn't catch that before, but I've fixed it.

Zach


On Wed, Jul 31, 2013 at 10:17 AM, Zach Tellman  wrote:

> Hi Ezra,
>
> This is admittedly a little confusing, but you're hinting 's' with the
> type of the *element*.  Here you've created a sequence containing a single
> 'ints-and-floats' struct, so you'd want to do this:
>
> user> (v/get-in s [0 :floats 4])
> 4.0
> user> (v/get-in s [0])
> {:ints (0 1 2 3 4 5 6 7 8 9), :floats (0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0
> 9.0)}
>
> I'll try to make this clearer in the documentation.  Let me know if you
> have any other questions.
>
> Zach
>
>
> On Wed, Jul 31, 2013 at 10:10 AM, Ezra Lee  wrote:
>
>> Hi,
>> I'm trying out vertigo and hoping you can help me figure out what I am
>> missing, I get an error when I use get-in:
>>
>> ; nREPL 0.1.8-preview
>> user> (use 'vertigo.structs)
>> nil
>> user> (def-typed-struct ints-and-floats :ints (array uint32 10) :floats
>> (array float32 10))
>> #'user/ints-and-floats
>> user> (def x {:ints (range 10) :floats (map float (range 10))})
>> #'user/x
>> user> (require '[vertigo.core :as v])
>> nil
>> user> (def ^:ints-and-floats s (v/marshal-seq ints-and-floats [x]))
>> #'user/s
>> user> (v/get-in s [:floats 4])
>> IllegalArgumentException Invalid field '4' for type ints-and-floats
>>  vertigo.core/validate-lookup (core.clj:177)
>> user> (v/get-in s [4 :floats])
>> IllegalArgumentException   java.nio.Buffer.position (Buffer.java:216)
>>
>> Thanks,
>> Ezra
>>
>> On Tuesday, July 9, 2013 11:56:03 PM UTC-4, Zach Tellman wrote:
>>>
>>> Last year, I gave a talk at the Conj on my attempt to write an AI for
>>> the board game Go.  Two things I discovered is that it was hard to get
>>> predictable performance, but even once I made sure I had all the right type
>>> hints, there was still a lot of room at the bottom for performance
>>> improvements.  Towards the end [1], I mentioned a few ideas for
>>> improvements, one of which was simply using ByteBuffers rather than objects
>>> to host the data.  This would remove all the levels of indirection, giving
>>> much better cache coherency, and also allow for fast unsynchronized
>>> mutability when the situation called for it.
>>>
>>> So, ten months and several supporting libraries [2] [3] later, here it
>>> is: 
>>> https://github.com/**ztellman/vertigo
>>>
>>> At a high level, this library is useful whenever your datatype has a
>>> fixed layout and is used more than once.  Depending on your type, it will
>>> give you moderate to large memory savings, and if you're willing to forgo
>>> some of core library in favor of Vertigo's operators, you can get
>>> significant performance gains on batch operations.  And, in the cases where
>>> performance doesn't matter, it will behave exactly like any other Clojure
>>> data structure.
>>>
>>> I want to point out that something like this would be more or less
>>> impossible in Java; reading from an offset in a ByteBuffer without the
>>> compile-time inference and validation provided by this library would be
>>> pointlessly risky.  There's not a lot of low-level Clojure libraries, but
>>> there's an increasing amount of production usage where people are using
>>> Clojure for performance-sensitive work.  I'm looking forward to seeing what
>>> people do with Vertigo and libraries like it.
>>>
>>> Zach
>>>
>>> [1] http://www.youtube.com/**watch?feature=player_**
>>> detailpage&v=v5dYE0CMmHQ#t=**1828s
>>> [2] 
>>> https://github.com/ztellman/**primitive-math
>>> [3] 
>>> https://github.com/**ztellman/byte-streams
>>>
>>  --
>> --
>> 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/BayfuaqMzvs/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/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 ema

core.async: async java.jdbc

[Alice]

(defonce ^ExecutorService db-thread-pool (Executors/newFixedThreadPool 8))

(defn db-thread-call
  [f]
  (let [c (chan 1)]
(.execute db-thread-pool
  (fn []
(let [ret (try
(f)
(catch Throwable t
  nil))]
  (when-not (nil? ret)
(>!! c ret))
  (close! c
c))

(defmacro db-thread
  [& body]
  `(db-thread-call (fn [] ~@body)))

(defn insert-async!
  [& args]
  (db-thread
(try
  (apply jdbc/insert! args)
  (catch Throwable t
t

(go
  (jdbc/db-transaction [t-con db-spec]
(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

[Sean Corfield]

On Wed, Jul 31, 2013 at 10:29 AM, Alice  wrote:
> (go
>   (jdbc/db-transaction [t-con db-spec]
> (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 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.

core.async: throwing an exception into the channel

[Alice]

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 (Exception.)))
  (go (try
(let [res (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

[Alice]

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 > 
> wrote: 
> > (go 
> >   (jdbc/db-transaction [t-con db-spec] 
> > (
> Does this work: 
>
> (jdbc/db-transaction [t-con db-spec] 
>   (go 
>  (
> -- 
> 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 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

[Timothy Baldridge]

Why not use  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  wrote:
>> > (go
>> >   (jdbc/db-transaction [t-con db-spec]
>> > (>
>> Does this work:
>>
>> (jdbc/db-transaction [t-con db-spec]
>>   (go
>>  (>
>> --
>> 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 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.
>
>
>



-- 
“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: core.async: async java.jdbc

[Alice]

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  >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  wrote: 
>>> > (go 
>>> >   (jdbc/db-transaction [t-con db-spec] 
>>> > (>>
>>> Does this work: 
>>>
>>> (jdbc/db-transaction [t-con db-spec] 
>>>   (go 
>>>  (>>
>>> -- 
>>> 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=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.
>>  
>>  
>>
>
>
>
> -- 
> “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.

[ANN] core.typed 0.1.18

[Ambrose Bonnaire-Sergeant]

Hi,

To mark the mid-GSoC evaluations, I'm happy to release another
core.typed version.

Highlights:

- type checking speed enhancements
- some usages of `every?` now update local types as expected
  - currently works best on things exactly of type IPersistentCollection
(aka. a new alias Coll)

eg. cast a (Coll Any) to (Coll Number):
  (cf (let [a (ann-form [] (Coll Any))]
 (assert (every? number? a))
 a))
  ;=> (Coll Number)

- combining keys/vals with every? updates an IPersistentMap type as you
would expect

eg. cast a (IPM Any Any) to (IPM Number Any)
(cf (let [a (ann-form {} (IPersistentMap Any Any))]
   (assert (every? number? (keys a)))
   a))
;=> (IPersistentMap Number Any

- New `Extends` type constructor can say which interfaces a type does *not*
extend (helps fix some unsoundness)

Thanks,
Ambrose

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

[Timothy Baldridge]

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] (! 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])
  ( 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  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  wrote:
 > (go
 >   (jdbc/db-transaction [t-con db-spec]
 > (>>>
 Does this work:

 (jdbc/db-transaction [t-con db-spec]
   (go
  (>>>
 --
 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=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
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> “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.
>
>
>



-- 
“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: core.async: throwing an exception into the channel

[Timothy Baldridge]

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  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 ( (catch Throwable t
>   (prn "exception")
>
> instead of
>
> (let [c (chan)]
>   (go (>! c (Exception.)))
>   (go (try
> (let [res (   (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 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.
>
>
>



-- 
“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: [ANN] core.typed 0.1.18

[Ambrose Bonnaire-Sergeant]

Probably even more exciting is that we can handle (filter identity coll),
although it
currently requires instantiating identity:

(cf (filter (inst identity (U nil Number)) [1 nil 2]))
;=> (Seqable Number)

Finally!
Ambrose



On Thu, Aug 1, 2013 at 2:31 AM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> Hi,
>
> To mark the mid-GSoC evaluations, I'm happy to release another
> core.typed version.
>
> Highlights:
>
> - type checking speed enhancements
> - some usages of `every?` now update local types as expected
>   - currently works best on things exactly of type IPersistentCollection
> (aka. a new alias Coll)
>
> eg. cast a (Coll Any) to (Coll Number):
>   (cf (let [a (ann-form [] (Coll Any))]
>  (assert (every? number? a))
>  a))
>   ;=> (Coll Number)
>
> - combining keys/vals with every? updates an IPersistentMap type as you
> would expect
>
> eg. cast a (IPM Any Any) to (IPM Number Any)
> (cf (let [a (ann-form {} (IPersistentMap Any Any))]
>(assert (every? number? (keys a)))
>a))
> ;=> (IPersistentMap Number Any
>
> - New `Extends` type constructor can say which interfaces a type does
> *not* extend (helps fix some unsoundness)
>
> Thanks,
> Ambrose
>

-- 
-- 
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: changing a value in a vector of maps

[cej38]

Friends,
  Thanks for the replies.  I will try your suggestions and get back to you 
if I have further questions.

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

[Alice]

(defn insert-async!
  [& args]
  (db-thread
(try
  (apply jdbc/insert! args)
  (catch Throwable t
t

db-thread is a macro that runs the body in a fixed thread pool, so IO isn't 
done inside a go block.

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] (  (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])
>   (
> 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  >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  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  wrote: 
> > (go 
> >   (jdbc/db-transaction [t-con db-spec] 
> > (
> Does this work: 
>
> (jdbc/db-transaction [t-con db-spec] 
>   (go 
>  (
> -- 
> 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=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
 .
  
  

>>>
>>>
>>>
>>> -- 
>>> “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.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/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: core.async: async java.jdbc

[Sean Corfield]

On Wed, Jul 31, 2013 at 10:58 AM, Alice  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.

Right. I was just showing how to avoid the compile error (because you
need 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 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.

clojure keyword spec

[Brent Millare]

I've been discovering in my code that namespaced identifiers are a 
wonderful thing. In particular, I am found of namespaced integers as an id.

Keywords usually serve the role as identifiers, but currently, the spec 
does not allow namespaced integers, which is odd since integers are valid 
as keywords and you can namespace words.

Again in table form:

Keyword...
name-starts-with | has-namespace | is-valid?
letter, no, yes
letter, yes, yes
number, no, yes
number, yes, no <-- This is odd

Can we change this so we don't get stack traces like so?

clojure.lang.LispReader$ReaderException: java.lang.RuntimeException: 
Invalid token: :asdf/3a
   LispReader.java:220 
clojure.lang.LispReader.read
 core.clj:3407 clojure.core/read
 core.clj:3405 clojure.core/read
 interruptible_eval.clj:52 
clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
  main.clj:257 clojure.main/repl[fn]
  main.clj:257 clojure.main/repl[fn]
  main.clj:277 clojure.main/repl[fn]
  main.clj:277 clojure.main/repl
  RestFn.java:1096 
clojure.lang.RestFn.invoke
 interruptible_eval.clj:56 
clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
  AFn.java:159 
clojure.lang.AFn.applyToHelper
  AFn.java:151 clojure.lang.AFn.applyTo
  core.clj:617 clojure.core/apply
 core.clj:1788 
clojure.core/with-bindings*
   RestFn.java:425 
clojure.lang.RestFn.invoke
 interruptible_eval.clj:41 
clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj:171 
clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval[fn]
 core.clj:2330 clojure.core/comp[fn]
interruptible_eval.clj:138 
clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
   AFn.java:24 clojure.lang.AFn.run
  ThreadPoolExecutor.java:1145 
java.util.concurrent.ThreadPoolExecutor.runWorker
   ThreadPoolExecutor.java:615 
java.util.concurrent.ThreadPoolExecutor$Worker.run
   Thread.java:724 java.lang.Thread.run
Caused by: java.lang.RuntimeException: Invalid token: :asdf/3a
 Util.java:219 
clojure.lang.Util.runtimeException
   LispReader.java:326 
clojure.lang.LispReader.interpretToken
   LispReader.java:211 
clojure.lang.LispReader.read

-- 
-- 
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: clojure keyword spec

[Ben Wolfson]

what's really strange about this is that the double-colon trick does work
for integers:

user> ::3
:user/3

You just can't write :user/3 directly.


On Wed, Jul 31, 2013 at 12:59 PM, Brent Millare wrote:

> I've been discovering in my code that namespaced identifiers are a
> wonderful thing. In particular, I am found of namespaced integers as an id.
>
> Keywords usually serve the role as identifiers, but currently, the spec
> does not allow namespaced integers, which is odd since integers are valid
> as keywords and you can namespace words.
>
> Again in table form:
>
> Keyword...
> name-starts-with | has-namespace | is-valid?
> letter, no, yes
> letter, yes, yes
> number, no, yes
> number, yes, no <-- This is odd
>
> Can we change this so we don't get stack traces like so?
>
> clojure.lang.LispReader$ReaderException: java.lang.RuntimeException:
> Invalid token: :asdf/3a
>LispReader.java:220
> clojure.lang.LispReader.read
>  core.clj:3407 clojure.core/read
>  core.clj:3405 clojure.core/read
>  interruptible_eval.clj:52
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>   main.clj:257 clojure.main/repl[fn]
>   main.clj:257 clojure.main/repl[fn]
>   main.clj:277 clojure.main/repl[fn]
>   main.clj:277 clojure.main/repl
>   RestFn.java:1096
> clojure.lang.RestFn.invoke
>  interruptible_eval.clj:56
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>   AFn.java:159
> clojure.lang.AFn.applyToHelper
>   AFn.java:151 clojure.lang.AFn.applyTo
>   core.clj:617 clojure.core/apply
>  core.clj:1788
> clojure.core/with-bindings*
>RestFn.java:425
> clojure.lang.RestFn.invoke
>  interruptible_eval.clj:41
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj:171
> clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval[fn]
>  core.clj:2330 clojure.core/comp[fn]
> interruptible_eval.clj:138
> clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
>AFn.java:24 clojure.lang.AFn.run
>   ThreadPoolExecutor.java:1145
> java.util.concurrent.ThreadPoolExecutor.runWorker
>ThreadPoolExecutor.java:615
> java.util.concurrent.ThreadPoolExecutor$Worker.run
>Thread.java:724 java.lang.Thread.run
> Caused by: java.lang.RuntimeException: Invalid token: :asdf/3a
>  Util.java:219
> clojure.lang.Util.runtimeException
>LispReader.java:326
> clojure.lang.LispReader.interpretToken
>LispReader.java:211
> clojure.lang.LispReader.read
>
> --
> --
> 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.
>
>
>



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
-- 
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: [GSoC] CinC mid-term evaluation status

[Colin Fleming]

This is great news, Nicola - thanks for all the hard work!


On 1 August 2013 04:57, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> Very exciting! Keep up the great work Nicola!
>
> Ambrose
>
>
> On Thu, Aug 1, 2013 at 12:41 AM, Nicola Mometto wrote:
>
>>
>> For the last month or so I've been working on completing Aaron Cohen's
>> CinC.
>>
>> As planned, this first period has been spent working extensively on the
>> analyzer improving it to the point where it's competitive with the
>> analysis done in Compiler.java while keeping it clojurescript-like and
>> extensible via small composable passes over the AST [1].
>>
>> There's some doc about the passes that are implemented and about the AST
>> nodes produced at in the doc directory of the repository [2].
>>
>> Notably, the jvm analyzer is able to propagate the tag of expressions
>> to infer the tag of more complex expressions avoiding the necessity
>> of explicit tagging in order to avoid run-time reflection in some cases.
>>
>> There are two "main" namespaces: `cinc.analyzer` and
>> `cinc.analyzer.jvm`; the first one should not be used directly but
>> should rather be extended to platform-specific forms and passes as done
>> by `cinc.analyzer.jvm`.
>>
>> Work on the jvm emitter will start soon.
>>
>> Thanks,
>> Nicola.
>>
>> [1]
>> https://github.com/Bronsa/CinC/tree/analyzer-WIP/src/cinc/analyzer/passes
>> [2] https://github.com/Bronsa/CinC/tree/analyzer-WIP/doc
>>
>> --
>> --
>> 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.
>
>
>

-- 
-- 
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: clojure keyword spec

[John D. Hume]

It's probably worth distinguishing between the "spec" as documented on
clojure.org (or https://github.com/edn-format/edn if you prefer) and what
the reader permits. Symbols are documented to begin with a non-numeric
character (with a special note in the EDN spec about the names of
namespaced symbols following the same first-character rule. Keywords are in
both documents described as following the rules of symbols.

The first char restriction for symbols makes sense, since they're Clojure's
identifier type, and the reader needs to be able to distinguish between a
number like `2M` and a symbol. I haven't thought of a reason it's important
to have the same restriction on keywords, but there may well be one.

Switching gears, you can do this (at least in Clojure 1.5.1):

(keyword "foo" "1")
(symbol "foo" "1")

but since the docs say these are invalid, I wouldn't recommend using it in
non-throw-away code.



On Wed, Jul 31, 2013 at 2:59 PM, Brent Millare wrote:

> I've been discovering in my code that namespaced identifiers are a
> wonderful thing. In particular, I am found of namespaced integers as an id.
>
> Keywords usually serve the role as identifiers, but currently, the spec
> does not allow namespaced integers, which is odd since integers are valid
> as keywords and you can namespace words.
>
> Again in table form:
>
> Keyword...
> name-starts-with | has-namespace | is-valid?
> letter, no, yes
> letter, yes, yes
> number, no, yes
> number, yes, no <-- This is odd
>
> Can we change this so we don't get stack traces like so?
>
> clojure.lang.LispReader$ReaderException: java.lang.RuntimeException:
> Invalid token: :asdf/3a
>LispReader.java:220
> clojure.lang.LispReader.read
>  core.clj:3407 clojure.core/read
>  core.clj:3405 clojure.core/read
>  interruptible_eval.clj:52
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>   main.clj:257 clojure.main/repl[fn]
>   main.clj:257 clojure.main/repl[fn]
>   main.clj:277 clojure.main/repl[fn]
>   main.clj:277 clojure.main/repl
>   RestFn.java:1096
> clojure.lang.RestFn.invoke
>  interruptible_eval.clj:56
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>   AFn.java:159
> clojure.lang.AFn.applyToHelper
>   AFn.java:151 clojure.lang.AFn.applyTo
>   core.clj:617 clojure.core/apply
>  core.clj:1788
> clojure.core/with-bindings*
>RestFn.java:425
> clojure.lang.RestFn.invoke
>  interruptible_eval.clj:41
> clojure.tools.nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj:171
> clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval[fn]
>  core.clj:2330 clojure.core/comp[fn]
> interruptible_eval.clj:138
> clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
>AFn.java:24 clojure.lang.AFn.run
>   ThreadPoolExecutor.java:1145
> java.util.concurrent.ThreadPoolExecutor.runWorker
>ThreadPoolExecutor.java:615
> java.util.concurrent.ThreadPoolExecutor$Worker.run
>Thread.java:724 java.lang.Thread.run
> Caused by: java.lang.RuntimeException: Invalid token: :asdf/3a
>  Util.java:219
> clojure.lang.Util.runtimeException
>LispReader.java:326
> clojure.lang.LispReader.interpretToken
>LispReader.java:211
> clojure.lang.LispReader.read
>
> --
> --
> 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.
>
>
>



-- 
http://elhumidor.blogspot.com/

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

how to get use clojure.contrib.import-static

[jayvandal]

I am trying to run the snake program . I don't know how to fin this "use 
clojure.contrib.import-static" ?
Any help will be appreciated!
Thanks, jvandal

-- 
-- 
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: [ANN] immutable-bitset: smalller, faster integer sets

[Alexander Hudek]

Nice! Thanks for this Zach!

I also have an immutable bitset for integers based on BigInteger, should 
anyone need backwards compatibility with older jvms. However, you look to 
have put significantly more time into optimization than I did. My 
implementation does have a few extra functions (shifts and retrieving of 
the smallest and largest integers in a set). If anyone is interested I'm 
happy to formally package it.

https://www.refheap.com/17075

Alex

On Tuesday, July 30, 2013 8:58:38 PM UTC-4, Zach Tellman wrote:
>
> https://github.com/ztellman/immutable-bitset
>
> There's not much to describe here, this provides an implementation of an 
> integer-only set which can take up three orders of magnitude less memory 
> under certain conditions.  I needed this to implement a Bloom filter, but I 
> figured it had applications elsewhere.  If anyone has questions, I'd be 
> happy to answer them.
>
> Zach
>

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

Accessing Record Constructors

[JvJ]

I tried to define this record, but the Vec2. constructor doesn't exist yet.
How can I use the constructor inside the record's method?

(defrecord Vec2 [x y]

  Vector
  (mag [this]
   (Math/sqrt
(+ (* x x) (* y y
  
  (v+ [this] this)
   (v+ [this other]
   (Vec2. (+ (:x this) (:x other)
 (:y this) (:y other
  (v+ [this a b & c]
  (reduce v+
  this
  (conj c b a

-- 
-- 
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: Robo VM

[PublicFarley]

Niklas, RoboVM looks incredibly cool. I'm definitely going to fool around with 
it to see if I can get some Clojure code up and running on iOS. This could 
become RubyMotion for JVM language devs!

Have you looked at RubyMotion? Is your approach conceptually similar? How do 
you handle GC? Via an ARC like mechanism or do you bundle a garbage collector?

Again, great work. 

-- 
-- 
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: Accessing Record Constructors

[Armando Blancas]

The constructor should be available, like in this contrived sample:

Clojure 1.5.1
user=> (deftype Foo [a] Object (toString [this] (Foo. 1)))
user.Foo

What error are you getting?

On Wednesday, July 31, 2013 5:51:36 PM UTC-7, JvJ wrote:
>
> I tried to define this record, but the Vec2. constructor doesn't exist yet.
> How can I use the constructor inside the record's method?
>
> (defrecord Vec2 [x y]
>
>   Vector
>   (mag [this]
>(Math/sqrt
> (+ (* x x) (* y y
>   
>   (v+ [this] this)
>(v+ [this other]
>(Vec2. (+ (:x this) (:x other)
>  (:y this) (:y other
>   (v+ [this a b & c]
>   (reduce v+
>   this
>   (conj c b a
>

-- 
-- 
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: Accessing Record Constructors

[JvJ]

I figured it out.  I assumed it was some quirk with defrecord, but it was 
an arity exception.  Didn't pass 2 params to the ctor.
DERP!

;; This is the right way:
(Vec2. (+ (:x this) (:x other))
   (+ (:y this) (:y other)))

On Wednesday, 31 July 2013 17:51:36 UTC-7, JvJ wrote:
>
> I tried to define this record, but the Vec2. constructor doesn't exist yet.
> How can I use the constructor inside the record's method?
>
> (defrecord Vec2 [x y]
>
>   Vector
>   (mag [this]
>(Math/sqrt
> (+ (* x x) (* y y
>   
>   (v+ [this] this)
>(v+ [this other]
>(Vec2. (+ (:x this) (:x other)
>  (:y this) (:y other
>   (v+ [this a b & c]
>   (reduce v+
>   this
>   (conj c b a
>

-- 
-- 
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: how to get use clojure.contrib.import-static

[Sean Corfield]

Sounds like you're looking at a very old example - monolithic
clojure.contrib was deprecated when Clojure 1.3 came out. Some modules
had active maintainers and migrated to new modular contrib libraries.
Looking at:

http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go

I don't even see clojure.contrib.import-static listed which suggests
it disappeared in the Clojure 1.2 timeframe (or earlier) - so it no
longer exists in any form that you're likely to find / use with modern
releases of Clojure.

I think if you have something like: (import-static java.lang.Math PI
sqrt) and code that uses PI and sqrt directly, you can (import
java.lang.Math) and use Math/PI and Math/sqrt instead.

Sean


On Wed, Jul 31, 2013 at 4:40 PM, jayvandal  wrote:
> I am trying to run the snake program . I don't know how to fin this "use
> clojure.contrib.import-static" ?
> Any help will be appreciated!
> Thanks, jvandal
>
> --
> --
> 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.
>
>



-- 
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 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: clojure keyword spec

[Brent Millare]

I do want to change the "spec" since those rules are what the documentation 
say.

Let's highlight the question, does the same reasoning for restrictions on 
symbols also apply for keywords?

On Wednesday, July 31, 2013 5:36:15 PM UTC-4, John Hume wrote:
>
> It's probably worth distinguishing between the "spec" as documented on 
> clojure.org (or https://github.com/edn-format/edn if you prefer) and what 
> the reader permits. Symbols are documented to begin with a non-numeric 
> character (with a special note in the EDN spec about the names of 
> namespaced symbols following the same first-character rule. Keywords are in 
> both documents described as following the rules of symbols.
>
> The first char restriction for symbols makes sense, since they're 
> Clojure's identifier type, and the reader needs to be able to distinguish 
> between a number like `2M` and a symbol. I haven't thought of a reason it's 
> important to have the same restriction on keywords, but there may well be 
> one.
>
> Switching gears, you can do this (at least in Clojure 1.5.1):
>
> (keyword "foo" "1")
> (symbol "foo" "1")
>
> but since the docs say these are invalid, I wouldn't recommend using it in 
> non-throw-away code.
>
>
>
> On Wed, Jul 31, 2013 at 2:59 PM, Brent Millare 
> 
> > wrote:
>
>> I've been discovering in my code that namespaced identifiers are a 
>> wonderful thing. In particular, I am found of namespaced integers as an id.
>>
>> Keywords usually serve the role as identifiers, but currently, the spec 
>> does not allow namespaced integers, which is odd since integers are valid 
>> as keywords and you can namespace words.
>>
>> Again in table form:
>>
>> Keyword...
>> name-starts-with | has-namespace | is-valid?
>> letter, no, yes
>> letter, yes, yes
>> number, no, yes
>> number, yes, no <-- This is odd
>>
>> Can we change this so we don't get stack traces like so?
>>
>> clojure.lang.LispReader$ReaderException: java.lang.RuntimeException: 
>> Invalid token: :asdf/3a
>>LispReader.java:220 
>> clojure.lang.LispReader.read
>>  core.clj:3407 clojure.core/read
>>  core.clj:3405 clojure.core/read
>>  interruptible_eval.clj:52 
>> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>>   main.clj:257 clojure.main/repl[fn]
>>   main.clj:257 clojure.main/repl[fn]
>>   main.clj:277 clojure.main/repl[fn]
>>   main.clj:277 clojure.main/repl
>>   RestFn.java:1096 
>> clojure.lang.RestFn.invoke
>>  interruptible_eval.clj:56 
>> clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
>>   AFn.java:159 
>> clojure.lang.AFn.applyToHelper
>>   AFn.java:151 
>> clojure.lang.AFn.applyTo
>>   core.clj:617 clojure.core/apply
>>  core.clj:1788 
>> clojure.core/with-bindings*
>>RestFn.java:425 
>> clojure.lang.RestFn.invoke
>>  interruptible_eval.clj:41 
>> clojure.tools.nrepl.middleware.interruptible-eval/evaluate
>> interruptible_eval.clj:171 
>> clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval[fn]
>>  core.clj:2330 clojure.core/comp[fn]
>> interruptible_eval.clj:138 
>> clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
>>AFn.java:24 clojure.lang.AFn.run
>>   ThreadPoolExecutor.java:1145 
>> java.util.concurrent.ThreadPoolExecutor.runWorker
>>ThreadPoolExecutor.java:615 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run
>>Thread.java:724 java.lang.Thread.run
>> Caused by: java.lang.RuntimeException: Invalid token: :asdf/3a
>>  Util.java:219 
>> clojure.lang.Util.runtimeException
>>LispReader.java:326 
>> clojure.lang.LispReader.interpretToken
>>LispReader.java:211 
>> clojure.lang.LispReader.read
>>  
>> -- 
>> -- 
>> 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

Re: Find maps with embedded functions in a set

[Marcus Lindner]

Thanks.
That sound good.
I had played with eval, but wasn happy about this.



2013/7/31 Cedric Greevey 

> If you saved the original function instance, you can use it to find the
> map. This should work:
>
> (let [f #(+ 1 1)
>   s #{{:a 3 :b 5 :c f}}]
>   (contains? s {:a 3 :b 5 :c f}))
>
> Note that the value for the :c key is now the same *instance* of that
> function.
>
> Storing the function source, with ', instead of the function itself works
> until you want to call the function. Then you need eval. You might want to
> avoid that, perhaps by using a map of quoted functions to compiled
> functions (you can also use something similar to avoid compiling each
> single one of these functions over and over again at runtime even if you do
> use eval -- or just (def meval (memoize eval)) and use meval, or something).
>
> If you don't use eval, you can use other keys instead of the function
> source; a suitable keyword name like :add-x might be good, so you'd end up
> with {:a 3 :b 5 :c :add-x} in your data structure and a {:add-x #(+ 1 1)}
> in a lookup table somewhere.
>
>
>
> On Wed, Jul 31, 2013 at 6:34 AM, Marcus Lindner <
> marcus.goldritter.lind...@gmail.com> wrote:
>
>> Ups. [?]
>> Sorry.
>> Have not seen this typo :(.
>>
>>
>> 2013/7/31 Jim 
>>
>>> On 31/07/13 11:01, Goldritter wrote:
>>>
 But when I tried to access the value I got an Exception
 =>(c: {:a 3 :h 5 :c '#(+ 1 1)})
 RuntimeException Invalid token: c: clojure.lang.Util.**runtimeException
 (Util.java:219)
 {:a 3, :c (fn* [] (+ 1 1)), :h 5}

 The same with get
 => (get {:a 3 :h 5 :c '#(+ 1 1)} c:)
 RuntimeException Invalid token: c: clojure.lang.Util.**runtimeException
 (Util.java:219)
 RuntimeException Unmatched delimiter: ) 
 clojure.lang.Util.**runtimeException
 (Util.java:219)

>>>
>>> it seems to me that you wrote c: instead of :c ...try again with the
>>> correct key :)
>>>
>>> Jim
>>>
>>>
>>> --
>>> --
>>> 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+unsubscribe@**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+unsubscribe@**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.
>>
>>
>>
>
>  --
> --
> 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