Re: Clojure + jarjar to avoid dependency conflicts

[Jason Jackson]

+1

Any clojure users have any luck with jarjar? 


On Tuesday, 6 March 2012 15:27:52 UTC-8, nathanmarz wrote:
>
> I've been playing around with the "jarjar" tool ( 
> http://code.google.com/p/jarjar/ 
> ) in order to package my jar to avoid dependency conflicts with other 
> libs. It doesn't seem to work though with Clojure-created classfiles, 
> even when using aot compilation. At runtime, when doing a require/use 
> it still tries to load the old classname and not the new classname 
> substituted by jarjar. Has anyone had success with jarjar/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: Functions using locks are slowed even when locks are never taken

[Michael Blume]

Hmm, it seems like if it were JIT related you'd see the same issue with 
java code, but I get 5ns across the board.

https://github.com/MichaelBlume/perf-test/blob/master/src-java/PerfTest.java

On Saturday, November 2, 2013 12:01:01 AM UTC-7, Trenton Strong wrote:
>
> Verified that I receive the same result patterns as you on my machine.
>
> One other possibility outside of what you have already mentioned would be 
> something JIT-related.  Perhaps there is an optimization that can be 
> performed if the locking sections of the code are in another function but 
> otherwise no, but I'm not sure how that dovetails with Clojure' fn 
> compilation.
>
> On Friday, November 1, 2013 11:53:12 AM UTC-7, Michael Blume wrote:
>>
>> Since 1.6 alpha is out, I reran the tests with that -- basically the same 
>> results.
>>
>> On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume wrote:
>>>
>>> https://github.com/MichaelBlume/perf-test
>>>
>>> (ns perf-test
>>>   (:use (criterium core))
>>>   (:gen-class))
>>>
>>> (def o (Object.))
>>>
>>> (defn foo [x]
>>>   (if (> x 0)
>>> (inc x)
>>> (do
>>>   (monitor-enter o)
>>>   (let [res (dec x)]
>>> (monitor-exit 0)
>>> res
>>>
>>> (defn bar [x]
>>>   (if (> x 0)
>>> (inc x)
>>> (dec x)))
>>>
>>> (defn locking-part [x l]
>>>   (monitor-enter l)
>>>   (let [res (dec x)]
>>> (monitor-exit l)
>>> res))
>>>
>>> (defn baz [x]
>>>   (if (> x 0)
>>> (inc x)
>>> (locking-part x o)))
>>>
>>> (defn -main []
>>>   (println "benching foo")
>>>   (bench (foo 5) :verbose) 
>>>   (println "benching bar")
>>>   (bench (bar 5) :verbose)
>>>   (println "benching baz")
>>>   (bench (baz 5) :verbose)
>>>   (println "done benching"))
>>>
>>>
>>>
>>> I'm only ever calling these functions with positive values, so the 
>>> monitor-enter branch should never be entered. Nevertheless, the performance 
>>> of foo is much worse than bar or baz.
>>>
>>> The best guess I've got is that the fact that lock-taking is involved 
>>> somehow changes how the function is compiled, somehow making the function 
>>> slower. If the practical upshot is that I shouldn't write functions that 
>>> only sometimes lock -- that the locking part of a function should always be 
>>> its own function -- then I can do that, but I'm curious why.
>>>
>>> $ lein uberjar
>>> Compiling perf-test
>>> Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar
>>> Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar
>>> $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar 
>>> benching foo
>>> WARNING: Final GC required 1.5974571326266802 % of runtime
>>> x86_64 Mac OS X 10.8.3 4 cpu(s)
>>> Java HotSpot(TM) 64-Bit Server VM 24.0-b28
>>> Runtime arguments:
>>> Evaluation count : 391582560 in 60 samples of 6526376 calls.
>>>   Execution time sample mean : 167.426696 ns
>>>  Execution time mean : 167.459429 ns
>>> Execution time sample std-deviation : 4.079466 ns
>>> Execution time std-deviation : 4.097819 ns
>>>Execution time lower quantile : 160.742869 ns ( 2.5%)
>>>Execution time upper quantile : 175.453376 ns (97.5%)
>>>Overhead used : 1.634996 ns
>>>
>>> Found 2 outliers in 60 samples (3. %)
>>> low-severe   2 (3. %)
>>>  Variance from outliers : 12.5602 % Variance is moderately inflated by 
>>> outliers
>>> benching bar
>>> x86_64 Mac OS X 10.8.3 4 cpu(s)
>>> Java HotSpot(TM) 64-Bit Server VM 24.0-b28
>>> Runtime arguments:
>>> Evaluation count : 2174037300 in 60 samples of 36233955 calls.
>>>   Execution time sample mean : 26.068923 ns
>>>  Execution time mean : 26.066422 ns
>>> Execution time sample std-deviation : 0.887937 ns
>>> Execution time std-deviation : 0.916861 ns
>>>Execution time lower quantile : 23.996763 ns ( 2.5%)
>>>Execution time upper quantile : 27.911936 ns (97.5%)
>>>Overhead used : 1.634996 ns
>>>
>>> Found 3 outliers in 60 samples (5. %)
>>> low-severe   1 (1.6667 %)
>>> low-mild 1 (1.6667 %)
>>> high-mild1 (1.6667 %)
>>>  Variance from outliers : 22.1874 % Variance is moderately inflated by 
>>> outliers
>>> benching baz
>>> x86_64 Mac OS X 10.8.3 4 cpu(s)
>>> Java HotSpot(TM) 64-Bit Server VM 24.0-b28
>>> Runtime arguments:
>>> Evaluation count : 2270676660 in 60 samples of 37844611 calls.
>>>   Execution time sample mean : 25.834142 ns
>>>  Execution time mean : 25.837429 ns
>>> Execution time sample std-deviation : 0.718382 ns
>>> Execution time std-deviation : 0.729431 ns
>>>Execution time lower quantile : 24.837925 ns ( 2.5%)
>>>Execution time upper quantile : 27.595781 ns (97.5%)
>>>Overhead used : 1.634996 ns
>>>
>>> Found 4 outliers in 60 samples (6.6667 %)
>>> low-severe   2 (3. %)
>>> low-mild 2 (3. %)
>>>  Variance from outliers : 15.7591 % Variance is moderately inflated

Re: [ANN] Jig

[Timothy Washington]

Ok, I actually got the compojure example working. I just had to remove the
*config/console.edn* and *config/default.edn* files in my jig. They must be
disrupting the config that I put in. So that's my only feedback so far.

Ok, this is looking really good. Great work :)

Tim Washington
Interruptsoftware.ca  /
Bkeeping.com



On Sat, Nov 2, 2013 at 7:05 PM, Timothy Washington wrote:

> Hey Malcolm,
>
>
> *A)* Ok, so just playing around with jig some more. I'm looking to get
> working *Compojure* and *Pedestal* examples.
>
>  *B)* I started with a raw `*git clone g...@github.com:juxt/jig.git*`.
> Then in that directory, I ran the commands in blue.
>
> *C)* Now, I run my environment in a Virtual Machine. So when using the
> browser to try and go to each of the url end points, I got an *HTTP 404*,
> "*Not Found*" error for all of these URLs. Ie, Compojure and Pedestal
> were running, giving me HTTP responses. They just weren't giving me the
> advertised endpoints, only 404s. This corresponded errors I was
> experiencing when I tried to stitch in one of my simple compojure handlers
> in a separate jig. There's probably some small config I'm missing, before
> this becomes reeeally useful. Can't wait :)
>
>- http://172.16.210.128:8091/server
>- http://172.16.210.128:8001/readme
>- http://172.16.210.128:8001
>
>
>
> $ *lein repl*
> nREPL server started on port 59398 on host 127.0.0.1
> REPL-y 0.2.1
> Clojure 1.5.1
> Welcome to Jig!
>
> (go)   -- start the system
> (reset)-- reset the system
> (refresh)  -- recover if a reset fails due to a compilation error
> (menu) -- show this menu again
> Jig user> *(go)*
>  INFO  jig.system - Starting the system
> INFO  jig.system - Starting component ':test-ring-handler'
> INFO  jig.system - Starting component ':compojure'
> INFO  jig.system - Starting component ':jetty'
> INFO  org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
> INFO  o.e.jetty.server.AbstractConnector - *Started
> SelectChannelConnector@0.0.0.0:8091
> *
> INFO  jig.system - Starting component ':console/server'
> INFO  org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
> INFO  o.e.jetty.server.AbstractConnector - *Started
> SelectChannelConnector@0.0.0.0:8001
> *
> INFO  jig.system - Starting component ':console/web'
> INFO  jig.system - Starting component ':console/readme'
> :ready
> Jig user> INFO  i.p.s.http.impl.servlet-interceptor - {:line 362, :in
> :interceptor-service-fn, :context {:servlet # io.pedestal.service.http.servlet.FnServlet@606acc48>, :servlet-config
> #,
> :servlet-response #
> >, :servlet-request # org.eclipse.jetty.server.Request@5b8f67a6>}}
> INFO  io.pedestal.service.http - {:line 58, :msg "GET /"}
> INFO  i.p.s.http.impl.servlet-interceptor - {:line 362, :in
> :interceptor-service-fn, :context {:servlet # io.pedestal.service.http.servlet.FnServlet@606acc48>, :servlet-config
> #,
> :servlet-response #
> >, :servlet-request # org.eclipse.jetty.server.Request@5b8f67a6>}}
> INFO  io.pedestal.service.http - {:line 58, :msg "GET /web"}
> INFO  i.p.s.http.impl.servlet-interceptor - {:line 362, :in
> :interceptor-service-fn, :context {:servlet # io.pedestal.service.http.servlet.FnServlet@606acc48>, :servlet-config
> #,
> :servlet-response #
> >, :servlet-request # org.eclipse.jetty.server.Request@5b8f67a6>}}
> INFO  io.pedestal.service.http - {:line 58, :msg "GET /readme"}
>
>
>
>
>
> Tim Washington
> Interruptsoftware.ca  / 
> Bkeeping.com
>
>
>
> On Sun, Oct 27, 2013 at 4:39 AM, Chris Zheng  wrote:
>
>> Thanks Malcom,
>>
>> Even something really simple like showing your current project setup
>> would be really good for me to get going.
>>
>> On 21/10/2013, at 15:57, Malcolm Sparks  wrote:
>>
>> Hi Chris, yes I will try to do something like that very soon.
>>
>> On Friday, October 18, 2013 12:30:20 AM UTC+1, zcaudate wrote:
>>>
>>> Would it be possible to put up a video of a typical workflow example
>>> with pedestal. It's quite difficult for me to piece everything together
>>> just by reading the documentation.
>>>
>>> Chris
>>>
>>

-- 
-- 
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] Narrator: expressive, composable stream analysis

[Zach Tellman]

I was aware of Babbage, but haven't used it.  There is a certain similarity
to the syntax, but I think most (if not all) of the things I listed
differentiate Narrator from Babbage, as well.  Please correct me if I'm
wrong.


On Sat, Nov 2, 2013 at 3:36 PM, Ben Wolfson  wrote:

> seems kind of similar to babbage:
> https://github.com/ReadyForZero/babbage/tree/1.1
>
>
> On Sat, Nov 2, 2013 at 3:28 PM, Zach Tellman  wrote:
>
>> https://github.com/ztellman/narrator
>>
>> This is a reimplementation of an approach I've discussed in several talks
>> [1] [2], with an eye towards performance, memory efficiency, and
>> flexibility w.r.t. how the event stream is represented.  The readme does a
>> good job of explaining how it works, but there have been a number of new
>> event processing libraries recently (core.async, EEP, etc.), so I'll spend
>> some time here describing how this differs.
>>
>> First, this library is focused on aggregations over event streams, not
>> arbitrary transformations.  It is designed such that these aggregations can
>> be automatically parallelized, and use non-thread-safe data structures
>> (such as those in the excellent stream-lib [3]) without having to worry
>> about coordination.  As such, within this narrower application it has a
>> richer set of operators, and should be a fair bit faster (millions of
>> messages/sec/core).
>>
>> Second, this has support for time-series analysis of ordered streams,
>> either historical or in real time.  The input for either type of analysis
>> can be normal sequences, core.async channels, or Lamina channels. At
>> Factual we use this for aggregations across many of our real-time systems,
>> and I also use it for both ad hoc queries and daily rollups of logs and
>> other historical data.
>>
>> On a personal note, I think this is one of the most interesting and
>> useful libraries I've written.  I'm really looking forward to seeing how
>> people use it, and encourage feedback on how to make it better.
>>
>> Zach
>>
>> [1] http://www.infoq.com/presentations/analyze-running-system
>> [2] http://vimeo.com/45132054#!
>> [3] https://github.com/addthis/stream-lib
>>
>> --
>> --
>> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/gXGVXgqd9Xs/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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Jig

[Timothy Washington]

Hey Malcolm,


*A)* Ok, so just playing around with jig some more. I'm looking to get
working *Compojure* and *Pedestal* examples.

*B)* I started with a raw `*git clone g...@github.com:juxt/jig.git*`. Then
in that directory, I ran the commands in blue.

*C)* Now, I run my environment in a Virtual Machine. So when using the
browser to try and go to each of the url end points, I got an *HTTP 404*, "*Not
Found*" error for all of these URLs. Ie, Compojure and Pedestal were
running, giving me HTTP responses. They just weren't giving me the
advertised endpoints, only 404s. This corresponded errors I was
experiencing when I tried to stitch in one of my simple compojure handlers
in a separate jig. There's probably some small config I'm missing, before
this becomes reeeally useful. Can't wait :)

   - http://172.16.210.128:8091/server
   - http://172.16.210.128:8001/readme
   - http://172.16.210.128:8001



$ *lein repl*
nREPL server started on port 59398 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.5.1
Welcome to Jig!

(go)   -- start the system
(reset)-- reset the system
(refresh)  -- recover if a reset fails due to a compilation error
(menu) -- show this menu again
Jig user> *(go)*
INFO  jig.system - Starting the system
INFO  jig.system - Starting component ':test-ring-handler'
INFO  jig.system - Starting component ':compojure'
INFO  jig.system - Starting component ':jetty'
INFO  org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
INFO  o.e.jetty.server.AbstractConnector - *Started
SelectChannelConnector@0.0.0.0:8091
*
INFO  jig.system - Starting component ':console/server'
INFO  org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
INFO  o.e.jetty.server.AbstractConnector - *Started
SelectChannelConnector@0.0.0.0:8001
*
INFO  jig.system - Starting component ':console/web'
INFO  jig.system - Starting component ':console/readme'
:ready
Jig user> INFO  i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #, :servlet-config
#,
:servlet-response #, :servlet-request #}}
INFO  io.pedestal.service.http - {:line 58, :msg "GET /"}
INFO  i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #, :servlet-config
#,
:servlet-response #, :servlet-request #}}
INFO  io.pedestal.service.http - {:line 58, :msg "GET /web"}
INFO  i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #, :servlet-config
#,
:servlet-response #, :servlet-request #}}
INFO  io.pedestal.service.http - {:line 58, :msg "GET /readme"}





Tim Washington
Interruptsoftware.ca  /
Bkeeping.com



On Sun, Oct 27, 2013 at 4:39 AM, Chris Zheng  wrote:

> Thanks Malcom,
>
> Even something really simple like showing your current project setup would
> be really good for me to get going.
>
> On 21/10/2013, at 15:57, Malcolm Sparks  wrote:
>
> Hi Chris, yes I will try to do something like that very soon.
>
> On Friday, October 18, 2013 12:30:20 AM UTC+1, zcaudate wrote:
>>
>> Would it be possible to put up a video of a typical workflow example with
>> pedestal. It's quite difficult for me to piece everything together just by
>> reading the documentation.
>>
>> Chris
>>
>

-- 
-- 
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] Narrator: expressive, composable stream analysis

[Ben Wolfson]

seems kind of similar to babbage:
https://github.com/ReadyForZero/babbage/tree/1.1


On Sat, Nov 2, 2013 at 3:28 PM, Zach Tellman  wrote:

> https://github.com/ztellman/narrator
>
> This is a reimplementation of an approach I've discussed in several talks
> [1] [2], with an eye towards performance, memory efficiency, and
> flexibility w.r.t. how the event stream is represented.  The readme does a
> good job of explaining how it works, but there have been a number of new
> event processing libraries recently (core.async, EEP, etc.), so I'll spend
> some time here describing how this differs.
>
> First, this library is focused on aggregations over event streams, not
> arbitrary transformations.  It is designed such that these aggregations can
> be automatically parallelized, and use non-thread-safe data structures
> (such as those in the excellent stream-lib [3]) without having to worry
> about coordination.  As such, within this narrower application it has a
> richer set of operators, and should be a fair bit faster (millions of
> messages/sec/core).
>
> Second, this has support for time-series analysis of ordered streams,
> either historical or in real time.  The input for either type of analysis
> can be normal sequences, core.async channels, or Lamina channels. At
> Factual we use this for aggregations across many of our real-time systems,
> and I also use it for both ad hoc queries and daily rollups of logs and
> other historical data.
>
> On a personal note, I think this is one of the most interesting and useful
> libraries I've written.  I'm really looking forward to seeing how people
> use it, and encourage feedback on how to make it better.
>
> Zach
>
> [1] http://www.infoq.com/presentations/analyze-running-system
> [2] http://vimeo.com/45132054#!
> [3] https://github.com/addthis/stream-lib
>
> --
> --
> 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.

[ANN] Narrator: expressive, composable stream analysis

[Zach Tellman]

https://github.com/ztellman/narrator

This is a reimplementation of an approach I've discussed in several talks 
[1] [2], with an eye towards performance, memory efficiency, and 
flexibility w.r.t. how the event stream is represented.  The readme does a 
good job of explaining how it works, but there have been a number of new 
event processing libraries recently (core.async, EEP, etc.), so I'll spend 
some time here describing how this differs.

First, this library is focused on aggregations over event streams, not 
arbitrary transformations.  It is designed such that these aggregations can 
be automatically parallelized, and use non-thread-safe data structures 
(such as those in the excellent stream-lib [3]) without having to worry 
about coordination.  As such, within this narrower application it has a 
richer set of operators, and should be a fair bit faster (millions of 
messages/sec/core).

Second, this has support for time-series analysis of ordered streams, 
either historical or in real time.  The input for either type of analysis 
can be normal sequences, core.async channels, or Lamina channels. At 
Factual we use this for aggregations across many of our real-time systems, 
and I also use it for both ad hoc queries and daily rollups of logs and 
other historical data.

On a personal note, I think this is one of the most interesting and useful 
libraries I've written.  I'm really looking forward to seeing how people 
use it, and encourage feedback on how to make it better.

Zach

[1] http://www.infoq.com/presentations/analyze-running-system
[2] http://vimeo.com/45132054#!
[3] https://github.com/addthis/stream-lib

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

What's the -dup in print-dup?

[John Mastro]

This isn't a very deep question, but I wonder every time I come across it:
to what does "-dup" in `print-dup` and `*print-dup*` refer?

Thanks

- John

-- 
-- 
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: assoc / dissoc consistency, maps and vectors

[vrakade]

On Saturday, November 2, 2013 4:56:13 PM UTC-5, Jozef Wagner wrote:
>
> Problem is, when your proposed dissoc removes value from a vector, it 
> shifts all larger keys. So dissoc would not only remove value at index 
> position, but also change keys for pther values. And this is not what 
> dissoc should do
>


You're right. I'm not sure why this is suddenly clear without essentially 
any new information. :) I think I had the wrong conceptual impression of 
what assoc and dissoc should be, putting the emphasis on the generality of 
the collection types instead its specificity to the indicies.

For my notion of assoc/dissoc to hold parity, it would have to work like 
this which seems undesirable:


(def some-vector ['a 'b 'c 'd 'e])
(def some-map {0 'a 1 'b 2 'c 3 'd 4 'e})

(assoc some-vector 2 'x)
;=> [a b x d e]
(dissoc some-vector 2) ;; theoretical
;=> [a b d e] ;; theoretical

(assoc some-map 2 'x)
;=> {0 a, 1 b, 2 x, 3 d, 4 e}
(dissoc some-map 2)
;=> {0 a, 1 b, 2 d, 3 e} ;; not good 

-- 
-- 
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: request for feedback

[Anton Podviaznikov]

Hi Julien,

Thank you so much for the feedback! I added these ideas to the readme.

I was also thinking about email notifications. I have few Clojure libraries 
and it will be useful for me. I would say that it can be useful also for 
application developers. If you have big Clojure app I guess it's useful to 
get notification that some library was updated.

Thanks for the link to sonatype. I didn't know about license analysis!

Anton

On Thursday, October 31, 2013 6:25:36 PM UTC-4, Julien wrote:
>
> Very nice! Definitively something I find useful.
>
> I guess most are already part of your todo list but here are some features 
> I think might be interesting for library writers:
> * receive some notification when new versions are available
> * update some dedicated branch with new versions so they can be tested by 
> continuous integration system for early feedback
>
> Beyond that here are suggestions of somewhat orthogonal ideas:
> * allow to add metadata to libraries (like known bugs, security issues) => 
> you could then qualify the urgency to update some dependency
> * resolve license conflicts (say your license is incompatible with the 
> license of one of the dependencies) (sonatype has some product doing that: 
> http://www.sonatype.com/application-health-check)
>
> Maybe some sort of extension mechanism could be helpful?
>
> Julien
>
> Le mercredi 30 octobre 2013 21:09:02 UTC-3, Anton Podviaznikov a écrit :
>>
>> Hey everyone,
>>
>> I'm working on project called jarkeeper (
>> https://github.com/hashobject/jarkeeper.com).
>>
>> It's a simple tool that may be helpful in few cases:
>>
>> 1. Can help you understand if some Clojure library uses latest 
>> dependencies (e.x. http://www.jarkeeper.com/korma/Korma)
>> 2. Provides status of dependencies in your own Clojure projects.
>>
>> I'm curious if anyone founds this useful (because I'm thinking on adding 
>> more functionality). Appreciate any feedback.
>>
>>
>> P.S. Most of the work is done inside https://github.com/xsc/ancient-clj 
>> library. 
>> Also there is similar project.
>>
>> Anton Podviaznikov
>>
>>

-- 
-- 
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: assoc / dissoc consistency, maps and vectors

[Jozef Wagner]

Problem is, when your proposed dissoc removes value from a vector, it 
shifts all larger keys. So dissoc would not only remove value at index 
position, but also change keys for pther values. And this is not what 
dissoc should do

user=> (map-indexed vector [:a :b :c :d])
([0 :a] [1 :b] [2 :c] [3 :d])
user=> (dissoc [:a :b :c :d] 1) ;; your proposal
[:a :c :d]
user=> (map-indexed vector [:a :c :d])
([0 :a] [1 :c] [2 :d])

JW

On Saturday, November 2, 2013 8:40:37 PM UTC+1, vra...@gmail.com wrote:
>
>
>
> On Saturday, November 2, 2013 2:38:57 PM UTC-5, vra...@gmail.com wrote:
>>
>> (assoc some-vector 2 'x)
>> ;=> [a b x d e]
>> (dissoc some-vector 3) ;; proposed
>> ;=> [a b d e]
>>
>
> Typo:
>
> (assoc some-vector 2 'x)
> ;=> [a b x d e]
> (dissoc some-vector 2) ;; proposed
> ;=> [a b d e]
>

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

[Video] Introduction to Light Table

[Jernau]

Hi everyone,

I've recorded an introduction to Light 
Table screencast. During 
which I explain why I'm excited about LT and its future, give a quick 
introduction to getting started with Clojure in LT, and finally cover some 
basics around customising keymaps and behaviours.

I hope that someone here finds it useful.

Cheers, 
James

-- 
-- 
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: assoc / dissoc consistency, maps and vectors

[vrakade]

On Saturday, November 2, 2013 2:38:57 PM UTC-5, vra...@gmail.com wrote:
>
> (assoc some-vector 2 'x)
> ;=> [a b x d e]
> (dissoc some-vector 3) ;; proposed
> ;=> [a b d e]
>

Typo:

(assoc some-vector 2 'x)
;=> [a b x d e]
(dissoc some-vector 2) ;; proposed
;=> [a b d e]

-- 
-- 
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: assoc / dissoc consistency, maps and vectors

[vrakade]

On Saturday, November 2, 2013 2:20:40 PM UTC-5, Ben wrote:
>
> So then (get (dissoc some-vector i) i) would be equivalent to (get 
> some-vector (inc i))? 
>

(def some-vector ['a 'b 'c 'd 'e])

(assoc some-vector 0 'x)
;=> [x b c d e]
(dissoc some-vector 0) ;; proposed
;=> [b c d e]

(assoc some-vector 1 'x)
;=> [a x c d e]
(dissoc some-vector 1) ;; proposed
;=> [a c d e]

(assoc some-vector 2 'x)
;=> [a b x d e]
(dissoc some-vector 3) ;; proposed
;=> [a b d e]


(def some-map {0 'a 1 'b 2 'c 3 'd 4 'e})

(assoc some-map 0 'x)
;=> {0 x, 1 b, 2 c, 3 d, 4 e}
(dissoc some-map 0)
;=> {1 b, 2 c, 3 d, 4 e}

(assoc some-map 1 'x)
;=> {0 a, 1 x, 2 c, 3 d, 4 e}
(dissoc some-map 1)
;=> {0 a, 2 c, 3 d, 4 e}

(assoc some-map 2 'x)
;=> {0 a, 1 b, 2 x, 3 d, 4 e}
(dissoc some-map 2)
;=> {0 a, 1 b, 3 d, 4 e}

-- 
-- 
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: assoc / dissoc consistency, maps and vectors

[Ben Wolfson]

On Sat, Nov 2, 2013 at 11:51 AM,  wrote:

>
>
>
> (dissoc ['a 'b 'c] 1)
>
> ;=> ['a 'c]
>

So then (get (dissoc some-vector i) i) would be equivalent to (get
some-vector (inc i))?

-- 
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: assoc / dissoc consistency, maps and vectors

[vrakade]

On Saturday, November 2, 2013 1:16:42 PM UTC-5, Andy Fingerhut wrote:
>
> What would you expect the return value of (dissoc ['a 'b 'c] 1) to be?
>

Hi Andy,

Thanks for your interest! This is the "ideal" behavior I would expect from 
dissoc, for consistency with assoc:


(assoc ['a 'b 'c] 1 'x)
;=> ['a 'x 'c]

(dissoc ['a 'b 'c] 1)
;=> ['a 'c]


(assoc-in [['a 'b] ['c 'd]] [1 1] 'x)
;=> [[a b] [c x]]

(clojure.core.incubator/dissoc-in [['a 'b] ['c 'd]] [1 1])
;=> [[a b] [c]]


 

-- 
-- 
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: assoc / dissoc consistency, maps and vectors

[Andy Fingerhut]

What would you expect the return value of (dissoc ['a 'b 'c] 1) to be?


On Sat, Nov 2, 2013 at 11:03 AM,  wrote:

> I realize `dissoc` isn't implemented to work on vectors for technical
> reasons (such as explained on 1/13/11 here
> https://groups.google.com/forum/#!msg/clojure/Lx9ysZ4ndfw/E52rVTvclMoJ ).
>
> "It'd be nice" if it did as I still get surprised by this on occasion, it
> feels like an inconsistency when using Clojure such that I'd imagine it's a
> general point of frustration for others as well.
>
>
> (assoc [1 2 3] 1 'a)
> ;=> [1 a 3]
>
> (dissoc ['a 'b 'c] 1)
> ;=> ClassCastException clojure.lang.PersistentVector cannot be cast to
> clojure.lang.IPersistentMap  clojure.lang.RT.dissoc (RT.java:759)
>
>
> (assoc-in [['a 'b] ['c 'd]] [1 1] 'x)
> ;=> [[a b] [c x]]
>
> (clojure.core.incubator/dissoc-in [['a 'b] ['c 'd]] [1 1])
> ;=> ClassCastException clojure.lang.PersistentVector cannot be cast to
> clojure.lang.IPersistentMap  clojure.lang.RT.dissoc (RT.java:759)
>
> --
> --
> 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.

assoc / dissoc consistency, maps and vectors

[vrakade]

I realize `dissoc` isn't implemented to work on vectors for technical 
reasons (such as explained on 1/13/11 here 
https://groups.google.com/forum/#!msg/clojure/Lx9ysZ4ndfw/E52rVTvclMoJ ).

"It'd be nice" if it did as I still get surprised by this on occasion, it 
feels like an inconsistency when using Clojure such that I'd imagine it's a 
general point of frustration for others as well.


(assoc [1 2 3] 1 'a)
;=> [1 a 3]

(dissoc ['a 'b 'c] 1)
;=> ClassCastException clojure.lang.PersistentVector cannot be cast to 
clojure.lang.IPersistentMap  clojure.lang.RT.dissoc (RT.java:759)


(assoc-in [['a 'b] ['c 'd]] [1 1] 'x)
;=> [[a b] [c x]]

(clojure.core.incubator/dissoc-in [['a 'b] ['c 'd]] [1 1])
;=> ClassCastException clojure.lang.PersistentVector cannot be cast to 
clojure.lang.IPersistentMap  clojure.lang.RT.dissoc (RT.java:759)

-- 
-- 
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: Request for help optimising a Clojure program

[Andy Fingerhut]

A few minutes ago I finished copying, pasting, and doing a little
reformatting on Mark Engelberg's document on the subject.

http://dev.clojure.org/display/design/Better+hashing

Andy


On Fri, Nov 1, 2013 at 11:28 AM, Alex Miller  wrote:

> Has anyone created a design page on dev.clojure for this yet?
>
>
> On Thursday, October 31, 2013 9:19:23 AM UTC-5, Andy Fingerhut wrote:
>
>> Just a follow up after a fair amount of thinking and experimentation has
>> been done on this problem.
>>
>> Mark Engelberg has a very nice document describing the existing hash
>> functions used by Clojure, examples with why they can cause collisions so
>> often, and suggestions for changes to them to have fewer collisions in
>> these cases.  https://docs.google.com/document/d/10olJzjNHXn1Si1LsSvjNqF_
>> X1O7OTPZLuv3Uo_duY5o/edit
>>
>> I have made modifications to a fork of the Clojure code base with his
>> suggested hash modifications here, for experimentation purposes:
>> https://github.com/jafingerhut/clojure   I also have some modifications
>> to Paul's N-queens Clojure program to print out additional statistics and
>> try out different hash functions here: https://github.com/
>> jafingerhut/chess-clojure
>>
>> Running Paul's N-queens problem with a 6x6 board without any changes to
>> Clojure takes about 7 mins on one of my computers.  With those changes to
>> the hash functions it finishes in about 12 sec.
>>
>> I haven't let a 6x9 board run to completion without those hash changes,
>> but it takes a long time :-)  With those changes to the hash functions it
>> finishes in about 11 minutes.
>>
>> The reason for the currently slow behavior is a combination of the
>> current hash functions and the implementation of the PersistentHashSet data
>> structure used to implement sets.  A PersistentHashSet is, very roughly, a
>> 32-way branching tree with the hash function of the elements used to decide
>> which branch to take.  When you hit a leaf in the tree, all elements with
>> the same hash function value are put into an array that is scanned linearly
>> whenever you want to check whether a value is already in the set.  So the
>> more hash collisions, the more it is like using an array to store and look
>> up set elements in O(n) time.
>>
>> With the 6x9 board, there are 20,136,752 solutions.  The way those
>> solutions are represented in the program as sets of vectors, those 20
>> million values only have 17,936 different hash values.  Thus the average
>> length of those arrays of values in the tree leaves is 1,122 values.  The
>> longest of those arrays has 81,610 values in it, all with the same hash
>> function.
>>
>> With Mark's proposed hash function changes, those 20,136,752 values hash
>> to 20,089,488 different ints, for an average array length of 1 value, and a
>> longest array length of 3 values.  Big speedup.
>>
>> There is nothing unique about Mark's particular hash functions that
>> achieves this.  Other hash modifications can give similar improvements.
>> The Clojure dev team is considering which changes would be good ones to
>> make, in hopes of changing them once and not having to do it again.
>>
>> Andy
>>
>>
>> On Tue, Oct 22, 2013 at 9:28 AM, Paul Butcher wrote:
>>
>>> I've been playing around with a generalised version of the N-Queens
>>> problem that handles other chess pieces. I have a Scala implementation that
>>> uses an eager depth-first search. Given enough RAM (around 12G - it's very
>>> memory hungry!) it can solve a 6x9 board with 6 pieces in around 2.5
>>> minutes on my MacBook Pro.
>>>
>>> I then created a Clojure version of the same algorithm with the
>>> intention of (eventually) using laziness to avoid the memory issue.
>>> However, the performance of the Clojure version is several orders of
>>> magnitude worse than the Scala version (I've left it running overnight on
>>> the problem that the Scala version solves in 2.5 minutes and it still
>>> hasn't completed).
>>>
>>> I'm struggling to see why the performance of the Clojure version is so
>>> much worse than the Scala. Profiling in YourKit suggests that it's spending
>>> 99% of its time in PersistentHashSet.cons, but I'm at a loss to explain
>>> why. I would be grateful for any insight.
>>>
>>> The code for the two different versions is on GitHub:
>>>
>>> https://github.com/paulbutcher/chess-scala
>>> https://github.com/paulbutcher/chess-clojure
>>>
>>> Notes:
>>>
>>> - I know that an exhaustive depth-first search isn't a great way to
>>> tackle this problem. But I'd like to understand why I see such a dramatic
>>> difference between the performance of the Scala and Clojure versions.
>>>
>>> - I believe that I've implemented the same algorithm in both Scala and
>>> Clojure - certainly they both generate the same results for small problems
>>> (there are 3x3 and 4x4 problems commented out in the source). But clearly I
>>> can't rule out the possibility that I've made a mistake in the Clojure
>>> implementation. If anyone can spot my stupid

Re: Potential improvement to select-keys ?

[Mark Engelberg]

I seem to be a relatively lone voice thinking it makes sense to preserve
the type of the map, and honestly, I'm not going to lose any sleep if this
patch is never actually implemented, but here's my two cents on the
"optimal" design for records.

Earlier in the thread, I mentioned two mental models about how select-keys
works.  Even though the actual implementation involves starting from an
empty map and building back up, I think the behavior of select-keys should
mimic the mental model of discarding irrelevant keys.

The two mental models predict somewhat differently what would happen when
working with records.  Records can hold additional keys.  So imagine
someone dumps a whole lot of additional keys, and then wants to "recover"
the original, true record, by calling select-keys with the original keys in
the record.  I think this is a use case worth supporting.  This corresponds
to the mental model of discarding unwanted keys.

To implement this for records:
If any of the original record keys do not appear in the selected keys,
then, as with dissoc, we must revert back to a map as there is no valid way
to represent this as a record.
Otherwise, maintain the record type -- the core record contents are
preserved, and essentially you only need to call select-keys only on the
extended map of extra keys stored in the record.


On Sat, Nov 2, 2013 at 8:49 AM, Andy Fingerhut wrote:

> I attached another patch to the ticket.  It builds up the answer from the
> empty map {} if the argument is a record (as the current select-keys does),
> but from (empty map) if it is not a record, so it will preserve sortedness
> of the argument.  Not sure if there are any other cases that are a problem,
> or if it does what everyone would expect, but it should be closer.
>
> http://dev.clojure.org/jira/browse/CLJ-1287
>
> Andy
>
>
> On Sat, Nov 2, 2013 at 6:07 AM, Alex Miller  wrote:
>
>> > One other point:
>> > Sometimes people use sorted maps and array maps specifically for
>> scenarios in which the keys are not hashable and therefore hash maps would
>> not apply.  Dumping the contents into a regular map in such cases doesn't
>> make much sense.
>>
>> Everything is hashable, not sure what a non-hashable key means. Array
>> maps use the hash of the key to determine the array bucket. If you get the
>> hash code of a sorted map, it will get the hash of all keys and values.
>>
>> --
>> --
>> 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: Potential improvement to select-keys ?

[Mark Engelberg]

On Sat, Nov 2, 2013 at 6:07 AM, Alex Miller  wrote:

> > One other point:
> > Sometimes people use sorted maps and array maps specifically for
> scenarios in which the keys are not hashable and therefore hash maps would
> not apply.  Dumping the contents into a regular map in such cases doesn't
> make much sense.
>
> Everything is hashable, not sure what a non-hashable key means. Array maps
> use the hash of the key to determine the array bucket. If you get the hash
> code of a sorted map, it will get the hash of all keys and values.
>


Infinite sequences are not hashable.  They can be sorted lexicographically,
provided you know in advance you're not working with two equal sequences.
I believe that array maps just store items in the order you put them in,
never computing the hash.

Not sure that using infinite sequences as keys is a common use case, but
when I wrote that, I was thinking that might be representative of a larger
set of examples where it is impossible or impractical to compute the hashes
of your keys.

-- 
-- 
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: Potential improvement to select-keys ?

[Andy Fingerhut]

I attached another patch to the ticket.  It builds up the answer from the
empty map {} if the argument is a record (as the current select-keys does),
but from (empty map) if it is not a record, so it will preserve sortedness
of the argument.  Not sure if there are any other cases that are a problem,
or if it does what everyone would expect, but it should be closer.

http://dev.clojure.org/jira/browse/CLJ-1287

Andy


On Sat, Nov 2, 2013 at 6:07 AM, Alex Miller  wrote:

> > One other point:
> > Sometimes people use sorted maps and array maps specifically for
> scenarios in which the keys are not hashable and therefore hash maps would
> not apply.  Dumping the contents into a regular map in such cases doesn't
> make much sense.
>
> Everything is hashable, not sure what a non-hashable key means. Array maps
> use the hash of the key to determine the array bucket. If you get the hash
> code of a sorted map, it will get the hash of all keys and values.
>
> --
> --
> 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: Potential improvement to select-keys ?

[Alex Miller]

> One other point:
> Sometimes people use sorted maps and array maps specifically for scenarios in 
> which the keys are not hashable and therefore hash maps would not apply.  
> Dumping the contents into a regular map in such cases doesn't make much sense.

Everything is hashable, not sure what a non-hashable key means. Array maps use 
the hash of the key to determine the array bucket. If you get the hash code of 
a sorted map, it will get the hash of all keys and values.

-- 
-- 
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: Potential improvement to select-keys ?

[Alex Miller]

> Our emails crossed paths, timing-wise, but my response to this is that not 
> all types of maps can safely be dumped into a regular map, so there's not 
> much reason to think that the standard behavior would be to build up from 
> scratch using a regular map.

Example? I can't think of one. Any key/value pair you retrieve from any map can 
be put in a regular map, right?  Note that the current behavior is to do 
exactly this.

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

Re: Any interest in Compojure/Ring screencasts?

[Rudi Engelbrecht]

Count me in

Rudi



On 30 Oct 2013, at 1:36 PM, Yuan  wrote:

> Count me in too..
> 
> >_>
> Best regards
> -
> Yuan blog github
> 
> 
> 
> 
> 
> On Wed, Oct 30, 2013 at 7:19 AM, Luc Prefontaine 
>  wrote:
> Count me in,
> 
> Luc P.
> 
> 
> > I'm considering putting together a screencast, or a series of screencasts,
> > based on my Functional Web
> > Architecture
> > talk.
> > The base presentation would be improved, and I'd probably wind up going
> > into more detail on certain topics. I'll probably charge a small fee
> > (perhaps $10 or so) to cover costs.
> >
> > Would there be any interest in this?
> >
> > - James
> >
> > --
> > --
> > 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.
> >
> --
> Luc Prefontaine sent by ibisMail!
> 
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: Functions using locks are slowed even when locks are never taken

[Trenton Strong]

Verified that I receive the same result patterns as you on my machine.

One other possibility outside of what you have already mentioned would be 
something JIT-related.  Perhaps there is an optimization that can be 
performed if the locking sections of the code are in another function but 
otherwise no, but I'm not sure how that dovetails with Clojure' fn 
compilation.

On Friday, November 1, 2013 11:53:12 AM UTC-7, Michael Blume wrote:
>
> Since 1.6 alpha is out, I reran the tests with that -- basically the same 
> results.
>
> On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume wrote:
>>
>> https://github.com/MichaelBlume/perf-test
>>
>> (ns perf-test
>>   (:use (criterium core))
>>   (:gen-class))
>>
>> (def o (Object.))
>>
>> (defn foo [x]
>>   (if (> x 0)
>> (inc x)
>> (do
>>   (monitor-enter o)
>>   (let [res (dec x)]
>> (monitor-exit 0)
>> res
>>
>> (defn bar [x]
>>   (if (> x 0)
>> (inc x)
>> (dec x)))
>>
>> (defn locking-part [x l]
>>   (monitor-enter l)
>>   (let [res (dec x)]
>> (monitor-exit l)
>> res))
>>
>> (defn baz [x]
>>   (if (> x 0)
>> (inc x)
>> (locking-part x o)))
>>
>> (defn -main []
>>   (println "benching foo")
>>   (bench (foo 5) :verbose) 
>>   (println "benching bar")
>>   (bench (bar 5) :verbose)
>>   (println "benching baz")
>>   (bench (baz 5) :verbose)
>>   (println "done benching"))
>>
>>
>>
>> I'm only ever calling these functions with positive values, so the 
>> monitor-enter branch should never be entered. Nevertheless, the performance 
>> of foo is much worse than bar or baz.
>>
>> The best guess I've got is that the fact that lock-taking is involved 
>> somehow changes how the function is compiled, somehow making the function 
>> slower. If the practical upshot is that I shouldn't write functions that 
>> only sometimes lock -- that the locking part of a function should always be 
>> its own function -- then I can do that, but I'm curious why.
>>
>> $ lein uberjar
>> Compiling perf-test
>> Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar
>> Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar
>> $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar 
>> benching foo
>> WARNING: Final GC required 1.5974571326266802 % of runtime
>> x86_64 Mac OS X 10.8.3 4 cpu(s)
>> Java HotSpot(TM) 64-Bit Server VM 24.0-b28
>> Runtime arguments:
>> Evaluation count : 391582560 in 60 samples of 6526376 calls.
>>   Execution time sample mean : 167.426696 ns
>>  Execution time mean : 167.459429 ns
>> Execution time sample std-deviation : 4.079466 ns
>> Execution time std-deviation : 4.097819 ns
>>Execution time lower quantile : 160.742869 ns ( 2.5%)
>>Execution time upper quantile : 175.453376 ns (97.5%)
>>Overhead used : 1.634996 ns
>>
>> Found 2 outliers in 60 samples (3. %)
>>  low-severe   2 (3. %)
>>  Variance from outliers : 12.5602 % Variance is moderately inflated by 
>> outliers
>> benching bar
>> x86_64 Mac OS X 10.8.3 4 cpu(s)
>> Java HotSpot(TM) 64-Bit Server VM 24.0-b28
>> Runtime arguments:
>> Evaluation count : 2174037300 in 60 samples of 36233955 calls.
>>   Execution time sample mean : 26.068923 ns
>>  Execution time mean : 26.066422 ns
>> Execution time sample std-deviation : 0.887937 ns
>> Execution time std-deviation : 0.916861 ns
>>Execution time lower quantile : 23.996763 ns ( 2.5%)
>>Execution time upper quantile : 27.911936 ns (97.5%)
>>Overhead used : 1.634996 ns
>>
>> Found 3 outliers in 60 samples (5. %)
>>  low-severe   1 (1.6667 %)
>>  low-mild 1 (1.6667 %)
>>  high-mild1 (1.6667 %)
>>  Variance from outliers : 22.1874 % Variance is moderately inflated by 
>> outliers
>> benching baz
>> x86_64 Mac OS X 10.8.3 4 cpu(s)
>> Java HotSpot(TM) 64-Bit Server VM 24.0-b28
>> Runtime arguments:
>> Evaluation count : 2270676660 in 60 samples of 37844611 calls.
>>   Execution time sample mean : 25.834142 ns
>>  Execution time mean : 25.837429 ns
>> Execution time sample std-deviation : 0.718382 ns
>> Execution time std-deviation : 0.729431 ns
>>Execution time lower quantile : 24.837925 ns ( 2.5%)
>>Execution time upper quantile : 27.595781 ns (97.5%)
>>Overhead used : 1.634996 ns
>>
>> Found 4 outliers in 60 samples (6.6667 %)
>>  low-severe   2 (3. %)
>>  low-mild 2 (3. %)
>>  Variance from outliers : 15.7591 % Variance is moderately inflated by 
>> outliers
>> done benching
>>
>>

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