Re: ExceptionInInitialization error

[Punit Naik]

Thank you so much Gary. Updating Cheshire totally worked!! But may I ask
how were you able to deduce that Cheshire was the problem? Do tell me so
that in the future I can fix these kind of problems myself.

On Thu, Feb 25, 2016 at 12:07 PM, Punit Naik  wrote:

> Okay thanks a lot Gary. Will try that.
>
> On Thu, Feb 25, 2016 at 6:49 AM, Gary Verhaegen 
> wrote:
>
>> So when I do `lein deps :tree` with these dependencies (except for the
>> swissknife one, which my computer does not seem to find), I get a
>> *lot* of conflicts with riemann, starting with:
>>
>> $ lein deps :tree
>> Possibly confusing dependencies found:
>> [cheshire "5.3.1"]
>>  overrides
>> [riemann "0.2.10"] -> [clj-http "1.1.2" :exclusions
>> [org.clojure/tools.reader]] -> [chesh
>> ire "5.4.0" :exclusions [org.clojure/clojure]]
>>  and
>> [riemann "0.2.10"] -> [cheshire "5.5.0"]
>>
>> Consider using these exclusions:
>> [riemann "0.2.10" :exclusions [cheshire]]
>> [riemann "0.2.10" :exclusions [cheshire]]
>>
>>
>> I would try updating the cheshire version you're declaring in
>> project.clj, instead of adding exclusions, though. (On my machine this
>> gets rid of the conflicts.)
>>
>>
>> On 24 February 2016 at 10:24, Punit Naik  wrote:
>> > Okay. So this is my project.clj:
>> >
>> >
>> > (defproject chowkidar "0.3.0-SNAPSHOT"
>> >   :description "Formcept Monitoring Framework"
>> >   :dependencies [[org.clojure/clojure "1.6.0"]
>> >  [org.clojure/java.jmx "0.3.0"]
>> >  [org.clojure/tools.logging "0.3.1"]
>> >  [riemann/riemann "0.2.10"]
>> >  [riemann-clojure-client "0.4.2"]
>> >  [org.formcept/swissknife "0.6.0"]
>> >  [com.novemberain/langohr "3.0.1"]
>> >  [cheshire "5.3.1"]]
>> >   :java-source-paths ["src/java"]
>> >   :resource-paths ["resources" "conf"]
>> >   :jvm-opts ["-XX:+UseConcMarkSweepGC"]
>> >   :profiles {:ship {:aot :all
>> > :omit-source true}
>> >  :uberjar {:uberjar-name "formcept-chowkidar.jar"}})
>> >
>> > So I had changed the version of "riemann" from 0.2.6 to 0.2.10. Only
>> that.
>> >
>> >
>> > On Wednesday, February 24, 2016 at 2:41:14 PM UTC+5:30, Gary Verhaegen
>> > wrote:
>> >>
>> >> No sign of conflict there - that's a bit surprising. Can you post your
>> >> project.clj? Do you have any explicit exclusions? What did you change
>> last
>> >> before it broke? Is it possible that you somehow corrupted your Maven
>> >> repository and are missing the mentioned class?
>> >>
>> >> Maybe it's not a dependency issue at all.
>> >>
>> >> On Wednesday, 24 February 2016, Punit Naik 
>> wrote:
>> >>
>> >> Here it is:
>> >>
>> >> [cheshire "5.3.1"] [com.fasterxml.jackson.core/jackson-core "2.3.1"]
>> >> [com.fasterxml.jackson.dataformat/jackson-dataformat-smile "2.3.1"]
>> [tigris
>> >> "0.1.1"] [clojure-complete "0.2.3" :scope "test" :exclusions
>> >> [[org.clojure/clojure]]] [com.novemberain/langohr "3.0.1"]
>> >> [clojurewerkz/support "1.1.0"] [com.google.guava/guava "18.0"]
>> >> [com.rabbitmq/amqp-client "3.4.2"] [org.clojure/clojure "1.6.0"]
>> >> [org.clojure/java.jmx "0.3.0"] [org.clojure/tools.logging "0.3.1"]
>> >> [org.clojure/tools.nrepl "0.2.6" :scope "test" :exclusions
>> >> [[org.clojure/clojure]]] [org.formcept/swissknife "0.6.0"]
>> >> [com.twitter/carbonite "1.4.0"] [com.esotericsoftware.kryo/kryo "2.21"]
>> >> [com.esotericsoftware.minlog/minlog "1.2"]
>> >> [com.esotericsoftware.reflectasm/reflectasm "1.07" :classifier
>> "shaded"]
>> >> [org.ow2.asm/asm "4.0"] [org.objenesis/objenesis "1.2"]
>> >> [com.twitter/chill-java "0.3.5"] [riemann-clojure-client "0.4.2"]
>> >> [com.aphyr/riemann-java-client "0.4.1"]
>> [com.google.protobuf/protobuf-java
>> >> "2.6.1"] [io.netty/netty "3.6.1.Final"] [riemann "0.2.10"] [amazonica
>> >> "0.3.28" :exclusions [[joda-time]]]
>> [com.amazonaws/amazon-kinesis-client
>> >> "1.1.0" :exclusions [[joda-time]]] [com.taoensso/nippy "2.7.0"]
>> >> [com.taoensso/encore "1.11.2"] [net.jpountz.lz4/lz4 "1.2.0"]
>> >> [org.clojure/tools.reader "0.8.9"] [org.iq80.snappy/snappy "0.3"]
>> >> [org.tukaani/xz "1.5"] [robert/hooke "1.3.0"] [capacitor "0.4.3"
>> :exclusions
>> >> [[http-kit]]] [org.clojure/core.async "0.1.319.0-6b1aca-alpha"]
>> >> [org.clojure/tools.analyzer.jvm "0.1.0-beta12"]
>> [org.clojure/core.memoize
>> >> "0.5.6"] [org.clojure/tools.analyzer "0.1.0-beta12"]
>> [org.ow2.asm/asm-all
>> >> "4.1"] [clj-antlr "0.2.2"] [org.antlr/antlr4-runtime "4.2.2"]
>> >> [org.abego.treelayout/org.abego.treelayout.core "1.0.1"]
>> >> [org.antlr/antlr4-annotations "4.2.2"] [org.antlr/antlr4 "4.2.2"]
>> >> [org.antlr/ST4 "4.0.8"] [org.antlr/antlr-runtime "3.5.2"] [clj-campfire
>> >> "2.2.0"] [http.async.client "0.5.2"] [com.ning/async-http-client
>> "1.7.10"]
>> >> [clj-http "1.1.2" :exclusions [[org.clojure/tools.reader]]]
>> >> [com.cognitect/transit-clj "0.8.271" :exclusions
>> [[org.clojure/clojure]]]
>> >> [com.cognitect/transit-java "0

Re: ExceptionInInitialization error

[Punit Naik]

Okay thanks a lot Gary. Will try that.

On Thu, Feb 25, 2016 at 6:49 AM, Gary Verhaegen 
wrote:

> So when I do `lein deps :tree` with these dependencies (except for the
> swissknife one, which my computer does not seem to find), I get a
> *lot* of conflicts with riemann, starting with:
>
> $ lein deps :tree
> Possibly confusing dependencies found:
> [cheshire "5.3.1"]
>  overrides
> [riemann "0.2.10"] -> [clj-http "1.1.2" :exclusions
> [org.clojure/tools.reader]] -> [chesh
> ire "5.4.0" :exclusions [org.clojure/clojure]]
>  and
> [riemann "0.2.10"] -> [cheshire "5.5.0"]
>
> Consider using these exclusions:
> [riemann "0.2.10" :exclusions [cheshire]]
> [riemann "0.2.10" :exclusions [cheshire]]
>
>
> I would try updating the cheshire version you're declaring in
> project.clj, instead of adding exclusions, though. (On my machine this
> gets rid of the conflicts.)
>
>
> On 24 February 2016 at 10:24, Punit Naik  wrote:
> > Okay. So this is my project.clj:
> >
> >
> > (defproject chowkidar "0.3.0-SNAPSHOT"
> >   :description "Formcept Monitoring Framework"
> >   :dependencies [[org.clojure/clojure "1.6.0"]
> >  [org.clojure/java.jmx "0.3.0"]
> >  [org.clojure/tools.logging "0.3.1"]
> >  [riemann/riemann "0.2.10"]
> >  [riemann-clojure-client "0.4.2"]
> >  [org.formcept/swissknife "0.6.0"]
> >  [com.novemberain/langohr "3.0.1"]
> >  [cheshire "5.3.1"]]
> >   :java-source-paths ["src/java"]
> >   :resource-paths ["resources" "conf"]
> >   :jvm-opts ["-XX:+UseConcMarkSweepGC"]
> >   :profiles {:ship {:aot :all
> > :omit-source true}
> >  :uberjar {:uberjar-name "formcept-chowkidar.jar"}})
> >
> > So I had changed the version of "riemann" from 0.2.6 to 0.2.10. Only
> that.
> >
> >
> > On Wednesday, February 24, 2016 at 2:41:14 PM UTC+5:30, Gary Verhaegen
> > wrote:
> >>
> >> No sign of conflict there - that's a bit surprising. Can you post your
> >> project.clj? Do you have any explicit exclusions? What did you change
> last
> >> before it broke? Is it possible that you somehow corrupted your Maven
> >> repository and are missing the mentioned class?
> >>
> >> Maybe it's not a dependency issue at all.
> >>
> >> On Wednesday, 24 February 2016, Punit Naik  wrote:
> >>
> >> Here it is:
> >>
> >> [cheshire "5.3.1"] [com.fasterxml.jackson.core/jackson-core "2.3.1"]
> >> [com.fasterxml.jackson.dataformat/jackson-dataformat-smile "2.3.1"]
> [tigris
> >> "0.1.1"] [clojure-complete "0.2.3" :scope "test" :exclusions
> >> [[org.clojure/clojure]]] [com.novemberain/langohr "3.0.1"]
> >> [clojurewerkz/support "1.1.0"] [com.google.guava/guava "18.0"]
> >> [com.rabbitmq/amqp-client "3.4.2"] [org.clojure/clojure "1.6.0"]
> >> [org.clojure/java.jmx "0.3.0"] [org.clojure/tools.logging "0.3.1"]
> >> [org.clojure/tools.nrepl "0.2.6" :scope "test" :exclusions
> >> [[org.clojure/clojure]]] [org.formcept/swissknife "0.6.0"]
> >> [com.twitter/carbonite "1.4.0"] [com.esotericsoftware.kryo/kryo "2.21"]
> >> [com.esotericsoftware.minlog/minlog "1.2"]
> >> [com.esotericsoftware.reflectasm/reflectasm "1.07" :classifier "shaded"]
> >> [org.ow2.asm/asm "4.0"] [org.objenesis/objenesis "1.2"]
> >> [com.twitter/chill-java "0.3.5"] [riemann-clojure-client "0.4.2"]
> >> [com.aphyr/riemann-java-client "0.4.1"]
> [com.google.protobuf/protobuf-java
> >> "2.6.1"] [io.netty/netty "3.6.1.Final"] [riemann "0.2.10"] [amazonica
> >> "0.3.28" :exclusions [[joda-time]]] [com.amazonaws/amazon-kinesis-client
> >> "1.1.0" :exclusions [[joda-time]]] [com.taoensso/nippy "2.7.0"]
> >> [com.taoensso/encore "1.11.2"] [net.jpountz.lz4/lz4 "1.2.0"]
> >> [org.clojure/tools.reader "0.8.9"] [org.iq80.snappy/snappy "0.3"]
> >> [org.tukaani/xz "1.5"] [robert/hooke "1.3.0"] [capacitor "0.4.3"
> :exclusions
> >> [[http-kit]]] [org.clojure/core.async "0.1.319.0-6b1aca-alpha"]
> >> [org.clojure/tools.analyzer.jvm "0.1.0-beta12"]
> [org.clojure/core.memoize
> >> "0.5.6"] [org.clojure/tools.analyzer "0.1.0-beta12"]
> [org.ow2.asm/asm-all
> >> "4.1"] [clj-antlr "0.2.2"] [org.antlr/antlr4-runtime "4.2.2"]
> >> [org.abego.treelayout/org.abego.treelayout.core "1.0.1"]
> >> [org.antlr/antlr4-annotations "4.2.2"] [org.antlr/antlr4 "4.2.2"]
> >> [org.antlr/ST4 "4.0.8"] [org.antlr/antlr-runtime "3.5.2"] [clj-campfire
> >> "2.2.0"] [http.async.client "0.5.2"] [com.ning/async-http-client
> "1.7.10"]
> >> [clj-http "1.1.2" :exclusions [[org.clojure/tools.reader]]]
> >> [com.cognitect/transit-clj "0.8.271" :exclusions
> [[org.clojure/clojure]]]
> >> [com.cognitect/transit-java "0.8.287"]
> >> [com.fasterxml.jackson.datatype/jackson-datatype-json-org "2.3.2"]
> >> [org.json/json "20090211"]
> >> [org.apache.directory.studio/org.apache.commons.codec "1.8"]
> >> [org.msgpack/msgpack "0.6.10"] [com.googlecode.json-simple/json-simple
> >> "1.1.1" :exclusions [[junit]]] [org.javassist/javassist "3.18.1-GA"]
> >> [commons-codec "1.10" :exclusions [[org.clojure

Re: [ANN] debux 0.2.0 is out

[Robert Levy]

Looks like there's some overlap with the debugging utils in
https://github.com/AlexBaranosky/print-foo

On Wed, Feb 24, 2016 at 4:57 PM, Philos Kim  wrote:

> Debux is a simple but useful library for debugging Clojure and
> ClojureScript. I wrote this library to debug my own Clojure(Script) code
> and to analyze other developer's Clojure(Script) code.
>
> This version includes the new features of debugging ->, ->>, let and comp
> forms.
>
> https://github.com/philoskim/debux
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: ExceptionInInitialization error

[Gary Verhaegen]

So when I do `lein deps :tree` with these dependencies (except for the
swissknife one, which my computer does not seem to find), I get a
*lot* of conflicts with riemann, starting with:

$ lein deps :tree
Possibly confusing dependencies found:
[cheshire "5.3.1"]
 overrides
[riemann "0.2.10"] -> [clj-http "1.1.2" :exclusions
[org.clojure/tools.reader]] -> [chesh
ire "5.4.0" :exclusions [org.clojure/clojure]]
 and
[riemann "0.2.10"] -> [cheshire "5.5.0"]

Consider using these exclusions:
[riemann "0.2.10" :exclusions [cheshire]]
[riemann "0.2.10" :exclusions [cheshire]]


I would try updating the cheshire version you're declaring in
project.clj, instead of adding exclusions, though. (On my machine this
gets rid of the conflicts.)


On 24 February 2016 at 10:24, Punit Naik  wrote:
> Okay. So this is my project.clj:
>
>
> (defproject chowkidar "0.3.0-SNAPSHOT"
>   :description "Formcept Monitoring Framework"
>   :dependencies [[org.clojure/clojure "1.6.0"]
>  [org.clojure/java.jmx "0.3.0"]
>  [org.clojure/tools.logging "0.3.1"]
>  [riemann/riemann "0.2.10"]
>  [riemann-clojure-client "0.4.2"]
>  [org.formcept/swissknife "0.6.0"]
>  [com.novemberain/langohr "3.0.1"]
>  [cheshire "5.3.1"]]
>   :java-source-paths ["src/java"]
>   :resource-paths ["resources" "conf"]
>   :jvm-opts ["-XX:+UseConcMarkSweepGC"]
>   :profiles {:ship {:aot :all
> :omit-source true}
>  :uberjar {:uberjar-name "formcept-chowkidar.jar"}})
>
> So I had changed the version of "riemann" from 0.2.6 to 0.2.10. Only that.
>
>
> On Wednesday, February 24, 2016 at 2:41:14 PM UTC+5:30, Gary Verhaegen
> wrote:
>>
>> No sign of conflict there - that's a bit surprising. Can you post your
>> project.clj? Do you have any explicit exclusions? What did you change last
>> before it broke? Is it possible that you somehow corrupted your Maven
>> repository and are missing the mentioned class?
>>
>> Maybe it's not a dependency issue at all.
>>
>> On Wednesday, 24 February 2016, Punit Naik  wrote:
>>
>> Here it is:
>>
>> [cheshire "5.3.1"] [com.fasterxml.jackson.core/jackson-core "2.3.1"]
>> [com.fasterxml.jackson.dataformat/jackson-dataformat-smile "2.3.1"] [tigris
>> "0.1.1"] [clojure-complete "0.2.3" :scope "test" :exclusions
>> [[org.clojure/clojure]]] [com.novemberain/langohr "3.0.1"]
>> [clojurewerkz/support "1.1.0"] [com.google.guava/guava "18.0"]
>> [com.rabbitmq/amqp-client "3.4.2"] [org.clojure/clojure "1.6.0"]
>> [org.clojure/java.jmx "0.3.0"] [org.clojure/tools.logging "0.3.1"]
>> [org.clojure/tools.nrepl "0.2.6" :scope "test" :exclusions
>> [[org.clojure/clojure]]] [org.formcept/swissknife "0.6.0"]
>> [com.twitter/carbonite "1.4.0"] [com.esotericsoftware.kryo/kryo "2.21"]
>> [com.esotericsoftware.minlog/minlog "1.2"]
>> [com.esotericsoftware.reflectasm/reflectasm "1.07" :classifier "shaded"]
>> [org.ow2.asm/asm "4.0"] [org.objenesis/objenesis "1.2"]
>> [com.twitter/chill-java "0.3.5"] [riemann-clojure-client "0.4.2"]
>> [com.aphyr/riemann-java-client "0.4.1"] [com.google.protobuf/protobuf-java
>> "2.6.1"] [io.netty/netty "3.6.1.Final"] [riemann "0.2.10"] [amazonica
>> "0.3.28" :exclusions [[joda-time]]] [com.amazonaws/amazon-kinesis-client
>> "1.1.0" :exclusions [[joda-time]]] [com.taoensso/nippy "2.7.0"]
>> [com.taoensso/encore "1.11.2"] [net.jpountz.lz4/lz4 "1.2.0"]
>> [org.clojure/tools.reader "0.8.9"] [org.iq80.snappy/snappy "0.3"]
>> [org.tukaani/xz "1.5"] [robert/hooke "1.3.0"] [capacitor "0.4.3" :exclusions
>> [[http-kit]]] [org.clojure/core.async "0.1.319.0-6b1aca-alpha"]
>> [org.clojure/tools.analyzer.jvm "0.1.0-beta12"] [org.clojure/core.memoize
>> "0.5.6"] [org.clojure/tools.analyzer "0.1.0-beta12"] [org.ow2.asm/asm-all
>> "4.1"] [clj-antlr "0.2.2"] [org.antlr/antlr4-runtime "4.2.2"]
>> [org.abego.treelayout/org.abego.treelayout.core "1.0.1"]
>> [org.antlr/antlr4-annotations "4.2.2"] [org.antlr/antlr4 "4.2.2"]
>> [org.antlr/ST4 "4.0.8"] [org.antlr/antlr-runtime "3.5.2"] [clj-campfire
>> "2.2.0"] [http.async.client "0.5.2"] [com.ning/async-http-client "1.7.10"]
>> [clj-http "1.1.2" :exclusions [[org.clojure/tools.reader]]]
>> [com.cognitect/transit-clj "0.8.271" :exclusions [[org.clojure/clojure]]]
>> [com.cognitect/transit-java "0.8.287"]
>> [com.fasterxml.jackson.datatype/jackson-datatype-json-org "2.3.2"]
>> [org.json/json "20090211"]
>> [org.apache.directory.studio/org.apache.commons.codec "1.8"]
>> [org.msgpack/msgpack "0.6.10"] [com.googlecode.json-simple/json-simple
>> "1.1.1" :exclusions [[junit]]] [org.javassist/javassist "3.18.1-GA"]
>> [commons-codec "1.10" :exclusions [[org.clojure/clojure]]] [commons-io "2.4"
>> :exclusions [[org.clojure/clojure]]] [crouton "0.1.2" :exclusions
>> [[org.clojure/clojure]]] [org.jsoup/jsoup "1.7.1"]
>> [org.apache.httpcomponents/httpclient "4.4.1" :exclusions
>> [[org.clojure/clojure]]] [commons-logging "1.2"]
>> [org.apache.httpcomponents/httpcore "4.4

[ANN] debux 0.2.0 is out

[Philos Kim]

Debux is a simple but useful library for debugging Clojure and 
ClojureScript. I wrote this library to debug my own Clojure(Script) code 
and to analyze other developer's Clojure(Script) code.

This version includes the new features of debugging ->, ->>, let and comp 
forms.

https://github.com/philoskim/debux

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

Re: Scripting with Clojure / "slow" boot time

[ZhX Chen]

Hi Alex,

A couple of months ago I did an investigation on the slow boot time of 
`lein repl`. As you said, a lot of time (around 30% time on my computer) 
are spent on the features like completion. Also, I notice that there is a 
parsing library called `sjacket ` at https://github.com/cgrand/sjacket , 
which provides the functionality to generating the parsing tree on the fly. 
Unfortunately it seems that the parser itself is constructed every time 
during the startup time, although the parser itself is always the same 
every time. My idea the thoughts are put at 
https://github.com/cgrand/sjacket/issues/24 , and I guess it would be 
interesting to let somebody who is concerned to notice.


在 2016年2月11日星期四 UTC-5下午4:47:34，Alex Miller写道：
>
> Nice! I have some stuff similar to this I use, but this is nicely packaged.
>
> On Thu, Feb 11, 2016 at 2:30 PM, Ryan Fowler  > wrote:
>
>> On Tue, Feb 9, 2016 at 12:36 PM, Alex Miller > > wrote:
>>
>>> I'm doing some research on slow Clojure boot time and would be 
>>> interested in collecting info about example use cases where it's been a 
>>> problem for people.
>>>
>>
>> ​The following snippet helps me visualize load times. It might be helpful 
>> to others.​ The output is a bit long, so I just added the code and 
>> usage/output in a gist at 
>> https://gist.github.com/ryfow/4283b64b4dd205d610e8
>>
>> ​​(def ^:dynamic *indent* 0)
>> (alter-var-root
>>  #'clojure.core/load
>>  (fn [orig]
>>(fn [& paths]
>>  (let [t (System/nanoTime)
>>r (binding [*indent* (inc *indent*)]
>>(apply orig paths))]
>>(binding [*out* *err*]
>>  (println (apply str (repeat *indent* " ")) (/ (- 
>> (System/nanoTime) t) 100.0)  paths)
>>  (flush))
>>r
>>
>> ;; Require namespace in question here
>> (require 'clojure.core.async)
>>
>>
>>
>>
>

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

Re: [ANN] Doubling down on Onyx

[Colin Fleming]

Hi Michael,

Congratulations! That's fantastic - I'm really happy to see more people
being able to work full time on tools :)

Cheers,
Colin

On 25 February 2016 at 05:22, Michael Drogalis  wrote:

> Hi everyone,
>
> I'm happy to announce that, starting next week, I'll be supporting the Onyx
> Platform  full time.
> I want to thank the incredible Clojure community that's helped to make
> Onyx a
> successful open source project. Read on in the blog post
> 
> for specifics, but I wanted to drop
> a message here to say how excited I am to push Clojure forward as a
> distributed systems/data analysis
> front runner.
>
> -- Michael
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Add support for seq on Java streams?

[Andrew Oberstar]

If you want to use reduce or transducers on a stream, you could take a look
at ike.cljj (shameless plug). Depending on your use case, it might not
provide a lot of benefit over Gary's suggestion.

https://github.com/ike-tools/ike.cljj

Andrew Oberstar

On Wed, Feb 24, 2016 at 7:07 AM <676c7...@gmail.com> wrote:

> Thanks, Alex and Gary.
>
> I understand that Java 8 is not yet on the roadmap, so iterator-seq
> seems like the best solution.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Compile time constants not generated with the appropriate type.

[Michael du Breuil]

If the JIT is eating it then you're right I'm absolutely fine with it. My 
concern is driven because this is in the hot loop of the program and the 
functions that are being called are fairly straightforward math that 
accumulate results into an array, and I am pushing the performance limits 
on the lower end hardware already. Now with all that said I admit I did 
forget about the JIT when I first started looking at this, and I strongly 
suspect you are right and the JIT is quietly fixing this (and the constant 
math) in the background for me. I need to go verify that of course (which 
I'm not sure how to do yet, but I'm sure google will tell me).

The only reason past that is for the one off performance (who really cares 
though?) and a reduction in byte code size (which I suspect will be almost 
unnoticable in almost all programs, and even in mine to be very small).

On Wednesday, February 24, 2016 at 1:49:41 PM UTC-7, red...@gmail.com wrote:
>
> On 02/24/2016 02:53 AM, Michael du Breuil wrote: 
> > The following (this is interop with libgdx if anyone is curious, 
> > hud-corner-top-left is a delayed TextureRegion 
> > 
> > (.draw batch ^TextureRegion @hud-corner-top-left 
> >(float -199) 
> >(float -32)) 
> > 
> > Which yields the following: 
> >   
> > 
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
>  
>
> >   RT.uncheckedFloatCast(-199L), 
> >   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch) 
>
> I think the best response to this is a far more polite than I can manage 
> "so what?". Which is not to imply that was meant to be impolite, just as 
> a way to prompt for more, it can seem impolite. 
>
> Bytecode is a means to end, the execution of Clojure on the JVM. So in 
> some sense, who cares what it looks like, as long as Clojure is running 
> well. The most common answer to "Why does the bytecode look like this?" 
> is going to be something like "It was the easiest bytecode to generate 
> for the given Clojure code". What you really should be asking yourself 
> here is, why when you call the function `float`; which is a Clojure 
> function, held in a var, represented as an Object implementing IFn, does 
> all that var lookup, and IFn invocation code disappear and is replaced 
> with one call to the static uncheckedFloatCast method. 
>
> Is this a quantifiable issue, or an aesthetic issue to you? 
>
> If it is an aesthetic issue, I would not expect other people to care 
> that much about it one way or another. Which means if you want to change 
> it, you need to write the patch yourself, and hope the patch gets 
> reviewed and accepted. If you do end up writing a patch, please also add 
> uncheckedFloat to Intrinsics.java. 
>
> If it is a quantifiable issue (these are usually performance issues), 
> many more people will care about it, and someone else may care enough to 
> write a patch. I would be really surprised if this effects performance 
> at all, since it seems like the kind of a jit would eat for breakfast, 
> but I am far from an expert, so who knows. 
>
>
> > 
> > Unless I'm missing something on how to interpret bytecode :) I can post 
> > more source if you want but that is one interop call and its generated 
> > code, the rest will look the same. 
> > 
> > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto 
> wrote: 
> > 
> > Can you post the code? 
> > 
> > > On 24 Feb 2016, at 10:26, Michael du Breuil 
> > > wrote: 
> > > 
> > > I have some interop code that I have carefully specified all the 
> > arguments to be in the correct type (IE the function signature takes 
> > 3 floats, so I cast everything to float so that I can avoid 
> > reflection). What I'm surprised by is compile time constants such as 
> > (float -173) or (float 8.5) are not saved as the correct primitive 
> > type, using jd-gui I see that these were actually turned into 
> > RT.uncheckedFloatCast(-173L), and RT.uncheckedFloatCast(8.5D), 
> > respectively. Why isn't this just saved as a the correct primitive 
> > directly in the generated bytecode? This is with clojure 1.8.0 
> > > 
> > > -- 
> > > 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 ema

Re: Compile time constants not generated with the appropriate type.

[Kevin Downey]

On 02/24/2016 02:53 AM, Michael du Breuil wrote:
> The following (this is interop with libgdx if anyone is curious,
> hud-corner-top-left is a delayed TextureRegion
> 
> (.draw batch ^TextureRegion @hud-corner-top-left
>(float -199)
>(float -32))
> 
> Which yields the following:
>  
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
>  
>   RT.uncheckedFloatCast(-199L), 
>   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch)

I think the best response to this is a far more polite than I can manage
"so what?". Which is not to imply that was meant to be impolite, just as
a way to prompt for more, it can seem impolite.

Bytecode is a means to end, the execution of Clojure on the JVM. So in
some sense, who cares what it looks like, as long as Clojure is running
well. The most common answer to "Why does the bytecode look like this?"
is going to be something like "It was the easiest bytecode to generate
for the given Clojure code". What you really should be asking yourself
here is, why when you call the function `float`; which is a Clojure
function, held in a var, represented as an Object implementing IFn, does
all that var lookup, and IFn invocation code disappear and is replaced
with one call to the static uncheckedFloatCast method.

Is this a quantifiable issue, or an aesthetic issue to you?

If it is an aesthetic issue, I would not expect other people to care
that much about it one way or another. Which means if you want to change
it, you need to write the patch yourself, and hope the patch gets
reviewed and accepted. If you do end up writing a patch, please also add
uncheckedFloat to Intrinsics.java.

If it is a quantifiable issue (these are usually performance issues),
many more people will care about it, and someone else may care enough to
write a patch. I would be really surprised if this effects performance
at all, since it seems like the kind of a jit would eat for breakfast,
but I am far from an expert, so who knows.


> 
> Unless I'm missing something on how to interpret bytecode :) I can post
> more source if you want but that is one interop call and its generated
> code, the rest will look the same.
> 
> On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote:
> 
> Can you post the code?
> 
> > On 24 Feb 2016, at 10:26, Michael du Breuil
> > wrote:
> >
> > I have some interop code that I have carefully specified all the
> arguments to be in the correct type (IE the function signature takes
> 3 floats, so I cast everything to float so that I can avoid
> reflection). What I'm surprised by is compile time constants such as
> (float -173) or (float 8.5) are not saved as the correct primitive
> type, using jd-gui I see that these were actually turned into
> RT.uncheckedFloatCast(-173L), and RT.uncheckedFloatCast(8.5D),
> respectively. Why isn't this just saved as a the correct primitive
> directly in the generated bytecode? This is with clojure 1.8.0
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com
> 
> > Note that posts from new members are moderated - please be patient
> with your first post.
> > To unsubscribe from this group, send email to
> > clojure+u...@googlegroups.com 
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> 
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an email to clojure+u...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout
> .
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


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

Re: Compile time constants not generated with the appropriate type.

[Michael du Breuil]

A more reproduceable example:

(let [y (float 10)]
  (println (str y)))


Yields this:
float y = RT.uncheckedFloatCast(10L);

((IFn)const__42.getRawRoot()).invoke(((IFn)const__43.getRawRoot()).invoke(Float.valueOf(y)));

On Wednesday, February 24, 2016 at 1:15:41 PM UTC-7, Michael du Breuil 
wrote:
>
> (let [x (float -199)]
> (.draw batch ^TextureRegion @hud-corner-top-left
>x
>(float -32)))
>
> That's an interop call to libgdx. That generated the disassembly I pasted 
> before.
>
> On Wednesday, February 24, 2016 at 5:05:30 AM UTC-7, Nicola Mometto wrote:
>>
>>
>> > On 24 Feb 2016, at 11:58, Michael du Breuil  
>> wrote: 
>> > 
>> > That just performs a runtime cast to a variable then reference the 
>> variable later, which is even worse. 
>> > 
>> > float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch) 
>> >   
>> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__42.getRawRoot()),
>>  
>> x, 
>> > 
>> >   RT.uncheckedFloatCast(-32L)); 
>> > 
>>
>>
>> No it doesn't. 
>>
>> having 
>>
>> (ns test) 
>>
>> (definterface Foo 
>>   (x [^float y])) 
>>
>> (let [a (float 1)] 
>>   (defn y [b] 
>> (.x ^Foo b a))) 
>>
>> This is the disassemble of y's invoke method: 
>>
>>   public java.lang.Object invoke(java.lang.Object); 
>> Code: 
>>  0: aload_1 
>>  1: aconst_null 
>>  2: astore_1 
>>  3: checkcast #18 // class test/Foo 
>>  6: aload_0 
>>  7: getfield  #14 // Field a:F 
>> 10: invokeinterface #22,  2   // InterfaceMethod 
>> test/Foo.x:(F)Ljava/lang/Object; 
>> 15: areturn 
>>
>> No float cast involved there. The primitive float is closed over and used 
>> directly. 
>>
>> > I definitely expected the compiler to pay attention to it, although I 
>> also discovered at the same time that the compilier doesn't actually 
>> resolve expressions like (+ (* 2 4) 1) to just be 9 at compile time either, 
>> even though all the values were constants. Both of these are a problem 
>> because they are inside the hot loop of the program. (There are some 
>> constant math expressions that are only expressions as it is easier to 
>> read/change ^:const named things then to just put one resultant number. 
>> > 
>> > Is it worth opening a Jira issue for resolving either or both of these 
>> at compile time? I looked a briefly at the definition for (float ) but I'm 
>> not at all familiar with how the byte code is generated and how to actually 
>> replace that with what I'm looking for. 
>>
>> Sure, although I don't think doing this kind of constant folding this is 
>> going to be a priority. 
>>
>> > 
>> > On Wednesday, February 24, 2016 at 3:58:46 AM UTC-7, Nicola Mometto 
>> wrote: 
>> > Those are runtime casts, this is the expected behaviour (although one 
>> could argue that clojure should be able to optimize them away at compile 
>> time). 
>> > 
>> > If you want to avoid the runtime casting, you can do something like 
>> this: 
>> > 
>> > (let [x (float 123)] 
>> >   (defn y [..] 
>> > (.foo bar x))) 
>> > 
>> > 
>> > > On 24 Feb 2016, at 10:53, Michael du Breuil  
>> wrote: 
>> > > 
>> > > The following (this is interop with libgdx if anyone is curious, 
>> hud-corner-top-left is a delayed TextureRegion 
>> > > 
>> > > (.draw batch ^TextureRegion @hud-corner-top-left 
>> > >(float -199) 
>> > >(float -32)) 
>> > > 
>> > > Which yields the following: 
>> > >   
>> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
>>  
>>
>> > >   RT.uncheckedFloatCast(-199L), 
>> > >   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch) 
>> > > 
>> > > Unless I'm missing something on how to interpret bytecode :) I can 
>> post more source if you want but that is one interop call and its generated 
>> code, the rest will look the same. 
>> > > 
>> > > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto 
>> wrote: 
>> > > Can you post the code? 
>> > > 
>> > > > On 24 Feb 2016, at 10:26, Michael du Breuil <
>> wicked.she...@gmail.com> wrote: 
>> > > > 
>> > > > I have some interop code that I have carefully specified all the 
>> arguments to be in the correct type (IE the function signature takes 3 
>> floats, so I cast everything to float so that I can avoid reflection). What 
>> I'm surprised by is compile time constants such as (float -173) or (float 
>> 8.5) are not saved as the correct primitive type, using jd-gui I see that 
>> these were actually turned into RT.uncheckedFloatCast(-173L), and 
>> RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved as a 
>> the correct primitive directly in the generated bytecode? This is with 
>> clojure 1.8.0 
>> > > > 
>> > > > -- 
>> > > > You received this message because you are subscribed to the Google 
>> > > > Groups "Clojure" group. 
>> > > > To post to this group, send email to clo...@googlegroup

Re: Compile time constants not generated with the appropriate type.

[Michael du Breuil]

(let [x (float -199)]
(.draw batch ^TextureRegion @hud-corner-top-left
   x
   (float -32)))

That's an interop call to libgdx. That generated the disassembly I pasted 
before.

On Wednesday, February 24, 2016 at 5:05:30 AM UTC-7, Nicola Mometto wrote:
>
>
> > On 24 Feb 2016, at 11:58, Michael du Breuil  > wrote: 
> > 
> > That just performs a runtime cast to a variable then reference the 
> variable later, which is even worse. 
> > 
> > float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch) 
> >   
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__42.getRawRoot()),
>  
> x, 
> > 
> >   RT.uncheckedFloatCast(-32L)); 
> > 
>
>
> No it doesn't. 
>
> having 
>
> (ns test) 
>
> (definterface Foo 
>   (x [^float y])) 
>
> (let [a (float 1)] 
>   (defn y [b] 
> (.x ^Foo b a))) 
>
> This is the disassemble of y's invoke method: 
>
>   public java.lang.Object invoke(java.lang.Object); 
> Code: 
>  0: aload_1 
>  1: aconst_null 
>  2: astore_1 
>  3: checkcast #18 // class test/Foo 
>  6: aload_0 
>  7: getfield  #14 // Field a:F 
> 10: invokeinterface #22,  2   // InterfaceMethod 
> test/Foo.x:(F)Ljava/lang/Object; 
> 15: areturn 
>
> No float cast involved there. The primitive float is closed over and used 
> directly. 
>
> > I definitely expected the compiler to pay attention to it, although I 
> also discovered at the same time that the compilier doesn't actually 
> resolve expressions like (+ (* 2 4) 1) to just be 9 at compile time either, 
> even though all the values were constants. Both of these are a problem 
> because they are inside the hot loop of the program. (There are some 
> constant math expressions that are only expressions as it is easier to 
> read/change ^:const named things then to just put one resultant number. 
> > 
> > Is it worth opening a Jira issue for resolving either or both of these 
> at compile time? I looked a briefly at the definition for (float ) but I'm 
> not at all familiar with how the byte code is generated and how to actually 
> replace that with what I'm looking for. 
>
> Sure, although I don't think doing this kind of constant folding this is 
> going to be a priority. 
>
> > 
> > On Wednesday, February 24, 2016 at 3:58:46 AM UTC-7, Nicola Mometto 
> wrote: 
> > Those are runtime casts, this is the expected behaviour (although one 
> could argue that clojure should be able to optimize them away at compile 
> time). 
> > 
> > If you want to avoid the runtime casting, you can do something like 
> this: 
> > 
> > (let [x (float 123)] 
> >   (defn y [..] 
> > (.foo bar x))) 
> > 
> > 
> > > On 24 Feb 2016, at 10:53, Michael du Breuil  
> wrote: 
> > > 
> > > The following (this is interop with libgdx if anyone is curious, 
> hud-corner-top-left is a delayed TextureRegion 
> > > 
> > > (.draw batch ^TextureRegion @hud-corner-top-left 
> > >(float -199) 
> > >(float -32)) 
> > > 
> > > Which yields the following: 
> > >   
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
>  
>
> > >   RT.uncheckedFloatCast(-199L), 
> > >   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch) 
> > > 
> > > Unless I'm missing something on how to interpret bytecode :) I can 
> post more source if you want but that is one interop call and its generated 
> code, the rest will look the same. 
> > > 
> > > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto 
> wrote: 
> > > Can you post the code? 
> > > 
> > > > On 24 Feb 2016, at 10:26, Michael du Breuil  
> wrote: 
> > > > 
> > > > I have some interop code that I have carefully specified all the 
> arguments to be in the correct type (IE the function signature takes 3 
> floats, so I cast everything to float so that I can avoid reflection). What 
> I'm surprised by is compile time constants such as (float -173) or (float 
> 8.5) are not saved as the correct primitive type, using jd-gui I see that 
> these were actually turned into RT.uncheckedFloatCast(-173L), and 
> RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved as a 
> the correct primitive directly in the generated bytecode? This is with 
> clojure 1.8.0 
> > > > 
> > > > -- 
> > > > 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 email

Re: Compile time constants not generated with the appropriate type.

[Michael du Breuil]

I posted the disassembly from the AOT'd result, so I'm pretty clearly still 
seeing all the casting happening at runtime. I'm not sure why that is 
different then no.disassemble...

On Wednesday, February 24, 2016 at 5:05:30 AM UTC-7, Nicola Mometto wrote:
>
>
> > On 24 Feb 2016, at 11:58, Michael du Breuil  > wrote: 
> > 
> > That just performs a runtime cast to a variable then reference the 
> variable later, which is even worse. 
> > 
> > float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch) 
> >   
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__42.getRawRoot()),
>  
> x, 
> > 
> >   RT.uncheckedFloatCast(-32L)); 
> > 
>
>
> No it doesn't. 
>
> having 
>
> (ns test) 
>
> (definterface Foo 
>   (x [^float y])) 
>
> (let [a (float 1)] 
>   (defn y [b] 
> (.x ^Foo b a))) 
>
> This is the disassemble of y's invoke method: 
>
>   public java.lang.Object invoke(java.lang.Object); 
> Code: 
>  0: aload_1 
>  1: aconst_null 
>  2: astore_1 
>  3: checkcast #18 // class test/Foo 
>  6: aload_0 
>  7: getfield  #14 // Field a:F 
> 10: invokeinterface #22,  2   // InterfaceMethod 
> test/Foo.x:(F)Ljava/lang/Object; 
> 15: areturn 
>
> No float cast involved there. The primitive float is closed over and used 
> directly. 
>
> > I definitely expected the compiler to pay attention to it, although I 
> also discovered at the same time that the compilier doesn't actually 
> resolve expressions like (+ (* 2 4) 1) to just be 9 at compile time either, 
> even though all the values were constants. Both of these are a problem 
> because they are inside the hot loop of the program. (There are some 
> constant math expressions that are only expressions as it is easier to 
> read/change ^:const named things then to just put one resultant number. 
> > 
> > Is it worth opening a Jira issue for resolving either or both of these 
> at compile time? I looked a briefly at the definition for (float ) but I'm 
> not at all familiar with how the byte code is generated and how to actually 
> replace that with what I'm looking for. 
>
> Sure, although I don't think doing this kind of constant folding this is 
> going to be a priority. 
>
> > 
> > On Wednesday, February 24, 2016 at 3:58:46 AM UTC-7, Nicola Mometto 
> wrote: 
> > Those are runtime casts, this is the expected behaviour (although one 
> could argue that clojure should be able to optimize them away at compile 
> time). 
> > 
> > If you want to avoid the runtime casting, you can do something like 
> this: 
> > 
> > (let [x (float 123)] 
> >   (defn y [..] 
> > (.foo bar x))) 
> > 
> > 
> > > On 24 Feb 2016, at 10:53, Michael du Breuil  
> wrote: 
> > > 
> > > The following (this is interop with libgdx if anyone is curious, 
> hud-corner-top-left is a delayed TextureRegion 
> > > 
> > > (.draw batch ^TextureRegion @hud-corner-top-left 
> > >(float -199) 
> > >(float -32)) 
> > > 
> > > Which yields the following: 
> > >   
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
>  
>
> > >   RT.uncheckedFloatCast(-199L), 
> > >   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch) 
> > > 
> > > Unless I'm missing something on how to interpret bytecode :) I can 
> post more source if you want but that is one interop call and its generated 
> code, the rest will look the same. 
> > > 
> > > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto 
> wrote: 
> > > Can you post the code? 
> > > 
> > > > On 24 Feb 2016, at 10:26, Michael du Breuil  
> wrote: 
> > > > 
> > > > I have some interop code that I have carefully specified all the 
> arguments to be in the correct type (IE the function signature takes 3 
> floats, so I cast everything to float so that I can avoid reflection). What 
> I'm surprised by is compile time constants such as (float -173) or (float 
> 8.5) are not saved as the correct primitive type, using jd-gui I see that 
> these were actually turned into RT.uncheckedFloatCast(-173L), and 
> RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved as a 
> the correct primitive directly in the generated bytecode? This is with 
> clojure 1.8.0 
> > > > 
> > > > -- 
> > > > 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, 
> se

Re: Compile time constants not generated with the appropriate type.

[Nicola Mometto]

Can you post the actual code you're compiling?

> On 24 Feb 2016, at 20:03, Michael du Breuil  
> wrote:
> 
> I posted the disassembly from the AOT'd result, so I'm pretty clearly still 
> seeing all the casting happening at runtime. I'm not sure why that is 
> different then no.disassemble...
> 
> On Wednesday, February 24, 2016 at 5:05:30 AM UTC-7, Nicola Mometto wrote:
> 
> > On 24 Feb 2016, at 11:58, Michael du Breuil  wrote:
> >
> > That just performs a runtime cast to a variable then reference the variable 
> > later, which is even worse.
> >
> > float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch)
> >   
> > .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__42.getRawRoot()),
> >  x,
> >
> >   RT.uncheckedFloatCast(-32L));
> >
> 
> 
> No it doesn't.
> 
> having
> 
> (ns test)
> 
> (definterface Foo
>   (x [^float y]))
> 
> (let [a (float 1)]
>   (defn y [b]
> (.x ^Foo b a)))
> 
> This is the disassemble of y's invoke method:
> 
>   public java.lang.Object invoke(java.lang.Object);
> Code:
>  0: aload_1
>  1: aconst_null
>  2: astore_1
>  3: checkcast #18 // class test/Foo
>  6: aload_0
>  7: getfield  #14 // Field a:F
> 10: invokeinterface #22,  2   // InterfaceMethod 
> test/Foo.x:(F)Ljava/lang/Object;
> 15: areturn
> 
> No float cast involved there. The primitive float is closed over and used 
> directly.
> 
> > I definitely expected the compiler to pay attention to it, although I also 
> > discovered at the same time that the compilier doesn't actually resolve 
> > expressions like (+ (* 2 4) 1) to just be 9 at compile time either, even 
> > though all the values were constants. Both of these are a problem because 
> > they are inside the hot loop of the program. (There are some constant math 
> > expressions that are only expressions as it is easier to read/change 
> > ^:const named things then to just put one resultant number.
> >
> > Is it worth opening a Jira issue for resolving either or both of these at 
> > compile time? I looked a briefly at the definition for (float ) but I'm not 
> > at all familiar with how the byte code is generated and how to actually 
> > replace that with what I'm looking for.
> 
> Sure, although I don't think doing this kind of constant folding this is 
> going to be a priority.
> 
> >
> > On Wednesday, February 24, 2016 at 3:58:46 AM UTC-7, Nicola Mometto wrote:
> > Those are runtime casts, this is the expected behaviour (although one could 
> > argue that clojure should be able to optimize them away at compile time).
> >
> > If you want to avoid the runtime casting, you can do something like this:
> >
> > (let [x (float 123)]
> >   (defn y [..]
> > (.foo bar x)))
> >
> >
> > > On 24 Feb 2016, at 10:53, Michael du Breuil  
> > > wrote:
> > >
> > > The following (this is interop with libgdx if anyone is curious, 
> > > hud-corner-top-left is a delayed TextureRegion
> > >
> > > (.draw batch ^TextureRegion @hud-corner-top-left
> > >(float -199)
> > >(float -32))
> > >
> > > Which yields the following:
> > >   
> > > .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
> > >   RT.uncheckedFloatCast(-199L),
> > >   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch)
> > >
> > > Unless I'm missing something on how to interpret bytecode :) I can post 
> > > more source if you want but that is one interop call and its generated 
> > > code, the rest will look the same.
> > >
> > > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote:
> > > Can you post the code?
> > >
> > > > On 24 Feb 2016, at 10:26, Michael du Breuil  
> > > > wrote:
> > > >
> > > > I have some interop code that I have carefully specified all the 
> > > > arguments to be in the correct type (IE the function signature takes 3 
> > > > floats, so I cast everything to float so that I can avoid reflection). 
> > > > What I'm surprised by is compile time constants such as (float -173) or 
> > > > (float 8.5) are not saved as the correct primitive type, using jd-gui I 
> > > > see that these were actually turned into RT.uncheckedFloatCast(-173L), 
> > > > and RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just 
> > > > saved as a the correct primitive directly in the generated bytecode? 
> > > > This is with clojure 1.8.0
> > > >
> > > > --
> > > > 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 yo

[ANN] Gorilla REPL v0.3.6

[Jony Hudson]

Hi All,

 I'm happy to point you to a new Gorilla REPL release. I can't take any 
credit for this, as all of the work was done by contributors in this 
release :-) From the changelog:

## Version 0.3.6

- Axis labels on plots (thanks to @dtolpin).
- Bump to latest CIDER-nrepl version 0.10.2.
- Undo segment delete (thanks to @mikeivanov).


If you're new to Gorilla REPL, you can find out all you want to know here:

http://gorilla-repl.org/

And instructions for getting started here:

http://gorilla-repl.org/start.html

Enjoy!


Jony

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

Re: [ANN] Doubling down on Onyx

[Bruce Durling]

Michael,

Congrats! A great thing to get behind.

cheers,
Bruce

On Wed, Feb 24, 2016 at 4:22 PM, Michael Drogalis  wrote:
> Hi everyone,
>
> I'm happy to announce that, starting next week, I'll be supporting the Onyx
> Platform full time.
> I want to thank the incredible Clojure community that's helped to make Onyx
> a
> successful open source project. Read on in the blog post for specifics, but
> I wanted to drop
> a message here to say how excited I am to push Clojure forward as a
> distributed systems/data analysis
> front runner.
>
> -- Michael
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [ANN] Doubling down on Onyx

[Colin Yates]

Congrats Michael - Onyx is a thing of beauty :-).

On 24 February 2016 at 16:22, Michael Drogalis  wrote:
> Hi everyone,
>
> I'm happy to announce that, starting next week, I'll be supporting the Onyx
> Platform full time.
> I want to thank the incredible Clojure community that's helped to make Onyx
> a
> successful open source project. Read on in the blog post for specifics, but
> I wanted to drop
> a message here to say how excited I am to push Clojure forward as a
> distributed systems/data analysis
> front runner.
>
> -- Michael
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[ANN] Doubling down on Onyx

[Michael Drogalis]

Hi everyone,

I'm happy to announce that, starting next week, I'll be supporting the Onyx 
Platform  full time.
I want to thank the incredible Clojure community that's helped to make Onyx 
a
successful open source project. Read on in the blog post 

 
for specifics, but I wanted to drop
a message here to say how excited I am to push Clojure forward as a 
distributed systems/data analysis
front runner.

-- Michael

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

Re: Add support for seq on Java streams?

[676c7473]

Thanks, Alex and Gary.

I understand that Java 8 is not yet on the roadmap, so iterator-seq
seems like the best solution.

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

Re: Add support for seq on Java streams?

[Gary Verhaegen]

In the mean time, you can probably get pretty far with the
java.util.stream.BaseStream#iterator method and the
clojure.core/iterator-seq function.

On Tuesday, 23 February 2016, Alex Miller  wrote:

> It may, however keep in mind that Clojure supports Java 1.6+ and Stream
> was added in 1.8. That's not an impossible hurdle, but it might make sense
> to make longer before hurdling it.
>
> On Tuesday, February 23, 2016 at 11:03:55 AM UTC-6, 676c7...@gmail.com
>  wrote:
>>
>> Hello!
>>
>> For interoperation with Java, Clojure’s seq supports the Iterable
>> interface directly, which means that all Java collections are
>> automatically seqable. seq also supports the CharSequence and
>> java.util.Map interfaces, and arrays too.
>>
>> Would it make sense to have seq also support java.util.stream.Stream?
>> Streams are just as important an abstraction as collections, and I
>> believe that stream-producing APIs are becoming more and more common. It
>> would be nice if Clojure supported it out of the box.
>>
>> An example (context: http://stackoverflow.com/q/35574155):
>>
>> (->> (.splitAsStream #"\s+" "one two three")
>>  (remove #(clojure.string/includes? % "o"))
>>  (map clojure.string/upper-case)
>>  first)
>>
>> Thanks,
>>
>>
>> --
>> David
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Compile time constants not generated with the appropriate type.

[Nicola Mometto]

> On 24 Feb 2016, at 11:58, Michael du Breuil  
> wrote:
> 
> That just performs a runtime cast to a variable then reference the variable 
> later, which is even worse.
> 
> float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch)
>   
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__42.getRawRoot()),
>  x,
> 
>   RT.uncheckedFloatCast(-32L));
> 


No it doesn't.

having

(ns test)

(definterface Foo
  (x [^float y]))

(let [a (float 1)]
  (defn y [b]
(.x ^Foo b a)))

This is the disassemble of y's invoke method:

  public java.lang.Object invoke(java.lang.Object);
Code:
 0: aload_1
 1: aconst_null
 2: astore_1
 3: checkcast #18 // class test/Foo
 6: aload_0
 7: getfield  #14 // Field a:F
10: invokeinterface #22,  2   // InterfaceMethod 
test/Foo.x:(F)Ljava/lang/Object;
15: areturn

No float cast involved there. The primitive float is closed over and used 
directly.

> I definitely expected the compiler to pay attention to it, although I also 
> discovered at the same time that the compilier doesn't actually resolve 
> expressions like (+ (* 2 4) 1) to just be 9 at compile time either, even 
> though all the values were constants. Both of these are a problem because 
> they are inside the hot loop of the program. (There are some constant math 
> expressions that are only expressions as it is easier to read/change ^:const 
> named things then to just put one resultant number.
> 
> Is it worth opening a Jira issue for resolving either or both of these at 
> compile time? I looked a briefly at the definition for (float ) but I'm not 
> at all familiar with how the byte code is generated and how to actually 
> replace that with what I'm looking for.

Sure, although I don't think doing this kind of constant folding this is going 
to be a priority.

> 
> On Wednesday, February 24, 2016 at 3:58:46 AM UTC-7, Nicola Mometto wrote:
> Those are runtime casts, this is the expected behaviour (although one could 
> argue that clojure should be able to optimize them away at compile time).
> 
> If you want to avoid the runtime casting, you can do something like this:
> 
> (let [x (float 123)]
>   (defn y [..]
> (.foo bar x)))
> 
> 
> > On 24 Feb 2016, at 10:53, Michael du Breuil  wrote:
> >
> > The following (this is interop with libgdx if anyone is curious, 
> > hud-corner-top-left is a delayed TextureRegion
> >
> > (.draw batch ^TextureRegion @hud-corner-top-left
> >(float -199)
> >(float -32))
> >
> > Which yields the following:
> >   
> > .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
> >   RT.uncheckedFloatCast(-199L),
> >   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch)
> >
> > Unless I'm missing something on how to interpret bytecode :) I can post 
> > more source if you want but that is one interop call and its generated 
> > code, the rest will look the same.
> >
> > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote:
> > Can you post the code?
> >
> > > On 24 Feb 2016, at 10:26, Michael du Breuil  
> > > wrote:
> > >
> > > I have some interop code that I have carefully specified all the 
> > > arguments to be in the correct type (IE the function signature takes 3 
> > > floats, so I cast everything to float so that I can avoid reflection). 
> > > What I'm surprised by is compile time constants such as (float -173) or 
> > > (float 8.5) are not saved as the correct primitive type, using jd-gui I 
> > > see that these were actually turned into RT.uncheckedFloatCast(-173L), 
> > > and RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved 
> > > as a the correct primitive directly in the generated bytecode? This is 
> > > with clojure 1.8.0
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clo...@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with 
> > > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+u...@googlegroups.com
> > > For more options, visit this group at
> > > http://groups.google.com/group/clojure?hl=en
> > > ---
> > > You received this message because you are subscribed to the Google Groups 
> > > "Clojure" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to clojure+u...@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to 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...@googlegroup

Re: Compile time constants not generated with the appropriate type.

[Michael du Breuil]

That just performs a runtime cast to a variable then reference the variable 
later, which is even worse.

float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch)
  
.draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__42.getRawRoot()),
 
x, 
  
  RT.uncheckedFloatCast(-32L));

I definitely expected the compiler to pay attention to it, although I also 
discovered at the same time that the compilier doesn't actually resolve 
expressions like (+ (* 2 4) 1) to just be 9 at compile time either, even 
though all the values were constants. Both of these are a problem because 
they are inside the hot loop of the program. (There are some constant math 
expressions that are only expressions as it is easier to read/change 
^:const named things then to just put one resultant number.

Is it worth opening a Jira issue for resolving either or both of these at 
compile time? I looked a briefly at the definition for (float ) but I'm not 
at all familiar with how the byte code is generated and how to actually 
replace that with what I'm looking for.

On Wednesday, February 24, 2016 at 3:58:46 AM UTC-7, Nicola Mometto wrote:
>
> Those are runtime casts, this is the expected behaviour (although one 
> could argue that clojure should be able to optimize them away at compile 
> time). 
>
> If you want to avoid the runtime casting, you can do something like this: 
>
> (let [x (float 123)] 
>   (defn y [..] 
> (.foo bar x))) 
>
>
> > On 24 Feb 2016, at 10:53, Michael du Breuil  > wrote: 
> > 
> > The following (this is interop with libgdx if anyone is curious, 
> hud-corner-top-left is a delayed TextureRegion 
> > 
> > (.draw batch ^TextureRegion @hud-corner-top-left 
> >(float -199) 
> >(float -32)) 
> > 
> > Which yields the following: 
> >   
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
>  
>
> >   RT.uncheckedFloatCast(-199L), 
> >   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch) 
> > 
> > Unless I'm missing something on how to interpret bytecode :) I can post 
> more source if you want but that is one interop call and its generated 
> code, the rest will look the same. 
> > 
> > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto 
> wrote: 
> > Can you post the code? 
> > 
> > > On 24 Feb 2016, at 10:26, Michael du Breuil  
> wrote: 
> > > 
> > > I have some interop code that I have carefully specified all the 
> arguments to be in the correct type (IE the function signature takes 3 
> floats, so I cast everything to float so that I can avoid reflection). What 
> I'm surprised by is compile time constants such as (float -173) or (float 
> 8.5) are not saved as the correct primitive type, using jd-gui I see that 
> these were actually turned into RT.uncheckedFloatCast(-173L), and 
> RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved as a 
> the correct primitive directly in the generated bytecode? This is with 
> clojure 1.8.0 
> > > 
> > > -- 
> > > You received this message because you are subscribed to the Google 
> > > Groups "Clojure" group. 
> > > To post to this group, send email to clo...@googlegroups.com 
> > > Note that posts from new members are moderated - please be patient 
> with your first post. 
> > > To unsubscribe from this group, send email to 
> > > clojure+u...@googlegroups.com 
> > > For more options, visit this group at 
> > > http://groups.google.com/group/clojure?hl=en 
> > > --- 
> > > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com. 
> > > For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
>  
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

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

Re: Compile time constants not generated with the appropriate type.

[Nicola Mometto]

Those are runtime casts, this is the expected behaviour (although one could 
argue that clojure should be able to optimize them away at compile time).

If you want to avoid the runtime casting, you can do something like this:

(let [x (float 123)] 
  (defn y [..]
(.foo bar x))) 


> On 24 Feb 2016, at 10:53, Michael du Breuil  
> wrote:
> 
> The following (this is interop with libgdx if anyone is curious, 
> hud-corner-top-left is a delayed TextureRegion
> 
> (.draw batch ^TextureRegion @hud-corner-top-left
>(float -199)
>(float -32))
> 
> Which yields the following:
>   
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
>  
>   RT.uncheckedFloatCast(-199L), 
>   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch)
> 
> Unless I'm missing something on how to interpret bytecode :) I can post more 
> source if you want but that is one interop call and its generated code, the 
> rest will look the same.
> 
> On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote:
> Can you post the code? 
> 
> > On 24 Feb 2016, at 10:26, Michael du Breuil  
> > wrote: 
> > 
> > I have some interop code that I have carefully specified all the arguments 
> > to be in the correct type (IE the function signature takes 3 floats, so I 
> > cast everything to float so that I can avoid reflection). What I'm 
> > surprised by is compile time constants such as (float -173) or (float 8.5) 
> > are not saved as the correct primitive type, using jd-gui I see that these 
> > were actually turned into RT.uncheckedFloatCast(-173L), and 
> > RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved as a 
> > the correct primitive directly in the generated bytecode? This is with 
> > clojure 1.8.0 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> > your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com 
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google Groups 
> > "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+u...@googlegroups.com. 
> > For more options, visit https://groups.google.com/d/optout. 
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Compile time constants not generated with the appropriate type.

[Michael du Breuil]

The following (this is interop with libgdx if anyone is curious, 
hud-corner-top-left is a delayed TextureRegion

(.draw batch ^TextureRegion @hud-corner-top-left
   (float -199)
   (float -32))

Which yields the following:
  
.draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
 
  RT.uncheckedFloatCast(-199L), 
  RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch)

Unless I'm missing something on how to interpret bytecode :) I can post 
more source if you want but that is one interop call and its generated 
code, the rest will look the same.

On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote:
>
> Can you post the code? 
>
> > On 24 Feb 2016, at 10:26, Michael du Breuil  > wrote: 
> > 
> > I have some interop code that I have carefully specified all the 
> arguments to be in the correct type (IE the function signature takes 3 
> floats, so I cast everything to float so that I can avoid reflection). What 
> I'm surprised by is compile time constants such as (float -173) or (float 
> 8.5) are not saved as the correct primitive type, using jd-gui I see that 
> these were actually turned into RT.uncheckedFloatCast(-173L), and 
> RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved as a 
> the correct primitive directly in the generated bytecode? This is with 
> clojure 1.8.0 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
>  
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

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

Re: Compile time constants not generated with the appropriate type.

[Nicola Mometto]

Can you post the code?

> On 24 Feb 2016, at 10:26, Michael du Breuil  
> wrote:
> 
> I have some interop code that I have carefully specified all the arguments to 
> be in the correct type (IE the function signature takes 3 floats, so I cast 
> everything to float so that I can avoid reflection). What I'm surprised by is 
> compile time constants such as (float -173) or (float 8.5) are not saved as 
> the correct primitive type, using jd-gui I see that these were actually 
> turned into RT.uncheckedFloatCast(-173L), and RT.uncheckedFloatCast(8.5D), 
> respectively. Why isn't this just saved as a the correct primitive directly 
> in the generated bytecode? This is with clojure 1.8.0
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Compile time constants not generated with the appropriate type.

[Michael du Breuil]

I have some interop code that I have carefully specified all the arguments 
to be in the correct type (IE the function signature takes 3 floats, so I 
cast everything to float so that I can avoid reflection). What I'm 
surprised by is compile time constants such as (float -173) or (float 8.5) 
are not saved as the correct primitive type, using jd-gui I see that these 
were actually turned into RT.uncheckedFloatCast(-173L), 
and RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved as 
a the correct primitive directly in the generated bytecode? This is with 
clojure 1.8.0

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

Re: Compojure does not augment response map

[Torsten Uhlmann]

Got it, makes sense.

Thanks, 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/d/optout.

Re: ExceptionInInitialization error

[Punit Naik]

Okay. So this is my project.clj:


(defproject chowkidar "0.3.0-SNAPSHOT"
  :description "Formcept Monitoring Framework"
  :dependencies [[org.clojure/clojure "1.6.0"]
 [org.clojure/java.jmx "0.3.0"]
 [org.clojure/tools.logging "0.3.1"]
 [riemann/riemann "0.2.10"]
 [riemann-clojure-client "0.4.2"]
 [org.formcept/swissknife "0.6.0"]
 [com.novemberain/langohr "3.0.1"]
 [cheshire "5.3.1"]]
  :java-source-paths ["src/java"]
  :resource-paths ["resources" "conf"]
  :jvm-opts ["-XX:+UseConcMarkSweepGC"]
  :profiles {:ship {:aot :all
:omit-source true}
 :uberjar {:uberjar-name "formcept-chowkidar.jar"}})

So I had changed the version of "riemann" from 0.2.6 to 0.2.10. Only that.


On Wednesday, February 24, 2016 at 2:41:14 PM UTC+5:30, Gary Verhaegen 
wrote:
>
> No sign of conflict there - that's a bit surprising. Can you post your 
> project.clj? Do you have any explicit exclusions? What did you change last 
> before it broke? Is it possible that you somehow corrupted your Maven 
> repository and are missing the mentioned class?
>
> Maybe it's not a dependency issue at all.
>
> On Wednesday, 24 February 2016, Punit Naik  > wrote:
>
> Here it is:
>
> [cheshire "5.3.1"] [com.fasterxml.jackson.core/jackson-core "2.3.1"] [com.
> fasterxml.jackson.dataformat/jackson-dataformat-smile "2.3.1"] [tigris 
> "0.1.1"] [clojure-complete "0.2.3" :scope "test" :exclusions [[org.clojure
> /clojure]]] [com.novemberain/langohr "3.0.1"] [clojurewerkz/support 
> "1.1.0"] [com.google.guava/guava "18.0"] [com.rabbitmq/amqp-client "3.4.2"
> ] [org.clojure/clojure "1.6.0"] [org.clojure/java.jmx "0.3.0"] [org.
> clojure/tools.logging "0.3.1"] [org.clojure/tools.nrepl "0.2.6" :scope 
> "test" :exclusions [[org.clojure/clojure]]] [org.formcept/swissknife 
> "0.6.0"] [com.twitter/carbonite "1.4.0"] [com.esotericsoftware.kryo/kryo 
> "2.21"] [com.esotericsoftware.minlog/minlog "1.2"] [com.esotericsoftware.
> reflectasm/reflectasm "1.07" :classifier "shaded"] [org.ow2.asm/asm "4.0"] 
> [org.objenesis/objenesis "1.2"] [com.twitter/chill-java "0.3.5"] [riemann-
> clojure-client "0.4.2"] [com.aphyr/riemann-java-client "0.4.1"] [com.
> google.protobuf/protobuf-java "2.6.1"] [io.netty/netty "3.6.1.Final"] 
> [riemann 
> "0.2.10"] [amazonica "0.3.28" :exclusions [[joda-time]]] [com.amazonaws/
> amazon-kinesis-client "1.1.0" :exclusions [[joda-time]]] [com.taoensso/nippy 
> "2.7.0"] [com.taoensso/encore "1.11.2"] [net.jpountz.lz4/lz4 "1.2.0"] [org
> .clojure/tools.reader "0.8.9"] [org.iq80.snappy/snappy "0.3"] [org.tukaani
> /xz "1.5"] [robert/hooke "1.3.0"] [capacitor "0.4.3" :exclusions [[http-
> kit]]] [org.clojure/core.async "0.1.319.0-6b1aca-alpha"] [org.clojure/
> tools.analyzer.jvm "0.1.0-beta12"] [org.clojure/core.memoize "0.5.6"] [org
> .clojure/tools.analyzer "0.1.0-beta12"] [org.ow2.asm/asm-all "4.1"] 
> [clj-antlr 
> "0.2.2"] [org.antlr/antlr4-runtime "4.2.2"] [org.abego.treelayout/org.
> abego.treelayout.core "1.0.1"] [org.antlr/antlr4-annotations "4.2.2"] [org
> .antlr/antlr4 "4.2.2"] [org.antlr/ST4 "4.0.8"] [org.antlr/antlr-runtime 
> "3.5.2"] [clj-campfire "2.2.0"] [http.async.client "0.5.2"] [com.ning/
> async-http-client "1.7.10"] [clj-http "1.1.2" :exclusions [[org.clojure/
> tools.reader]]] [com.cognitect/transit-clj "0.8.271" :exclusions [[org.
> clojure/clojure]]] [com.cognitect/transit-java "0.8.287"] [com.fasterxml.
> jackson.datatype/jackson-datatype-json-org "2.3.2"] [org.json/json 
> "20090211"] [org.apache.directory.studio/org.apache.commons.codec "1.8"] [
> org.msgpack/msgpack "0.6.10"] [com.googlecode.json-simple/json-simple 
> "1.1.1" :exclusions [[junit]]] [org.javassist/javassist "3.18.1-GA"] [
> commons-codec "1.10" :exclusions [[org.clojure/clojure]]] [commons-io 
> "2.4" :exclusions [[org.clojure/clojure]]] [crouton "0.1.2" :exclusions [[
> org.clojure/clojure]]] [org.jsoup/jsoup "1.7.1"] [org.apache.
> httpcomponents/httpclient "4.4.1" :exclusions [[org.clojure/clojure]]] [
> commons-logging "1.2"] [org.apache.httpcomponents/httpcore "4.4.1" 
> :exclusions 
> [[org.clojure/clojure]]] [org.apache.httpcomponents/httpmime "4.4.1" 
> :exclusions 
> [[org.clojure/clojure]]] [potemkin "0.3.13" :exclusions [[org.clojure/
> clojure]]] [clj-tuple "0.2.1"] [riddley "0.1.7"] [clj-librato "0.0.5"] [
> clj-nsca "0.0.3"] [com.googlecode/jsendnsca-core "1.3.1"] [clj-time 
> "0.10.0"] [joda-time "2.7"] [clj-wallhack "1.0.1"] [com.amazonaws/aws-java
> -sdk "1.10.5.1" :exclusions [[joda-time]]] 
> [com.amazonaws/aws-java-sdk-autoscaling 
> "1.10.5.1"] [com.amazonaws/aws-java-sdk-cloudformation "1.10.5.1"] [com.
> amazonaws/aws-java-sdk-cloudfront "1.10.5.1"] 
> [com.amazonaws/aws-java-sdk-cloudhsm 
> "1.10.5.1"] [com.amazonaws/aws-java-sdk-cloudsearch "1.10.5.1"] [com.
> amazonaws/aws-java-sdk-cloudtrail "1.10.5.1"] 
> [com.amazonaws/aws-java-sdk-cloudwatch 
> "1.10.5.1"] [com.amazonaws/a

Re: Compojure does not augment response map

[Gary Verhaegen]

My understanding is that compojure concerns itself mostly with routing and
does not try (anymore?) to handle response maps.

Concerning ring.util.response, I think these functions are meant to be
threaded:

(-> (not-found "oh noes")
(content-type "text"))

On Wednesday, 24 February 2016, Torsten Uhlmann 
wrote:

> Thanks Gary!
>
> I haven't touched the middleware stack for a while, and I only found out
> about this thing when testing my routes for security.
> But, if response maps are supposed to be left alone, how is
> ring.util.response supposed to work, for instance the "not-found" function:
>
> (defn not-found
>   "Returns a 404 'not found' response."
>   {:added "1.1"}
>   [body]
>   {:status  404
>:headers {}
>:bodybody})
>
>
> They all return an empty header.
> I guess it's not something (not accepting the response if content type is
> missing?) that has changed in Chrome or Firefox over the last few month?
>
> But then, the compojure wiki's example for a map also manually adds the
> content-type:
> https://github.com/weavejester/compojure/wiki/Routes-In-Detail
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Compojure does not augment response map

[Torsten Uhlmann]

Thanks Gary!

I haven't touched the middleware stack for a while, and I only found out 
about this thing when testing my routes for security.
But, if response maps are supposed to be left alone, how is 
ring.util.response supposed to work, for instance the "not-found" function:

(defn not-found
  "Returns a 404 'not found' response."
  {:added "1.1"}
  [body]
  {:status  404
   :headers {}
   :bodybody})


They all return an empty header.
I guess it's not something (not accepting the response if content type is 
missing?) that has changed in Chrome or Firefox over the last few month?

But then, the compojure wiki's example for a map also manually adds the 
content-type: https://github.com/weavejester/compojure/wiki/Routes-In-Detail

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

Re: ExceptionInInitialization error

[Gary Verhaegen]

No sign of conflict there - that's a bit surprising. Can you post your
project.clj? Do you have any explicit exclusions? What did you change last
before it broke? Is it possible that you somehow corrupted your Maven
repository and are missing the mentioned class?

Maybe it's not a dependency issue at all.

On Wednesday, 24 February 2016, Punit Naik  wrote:

> Here it is:
>
> [cheshire "5.3.1"] [com.fasterxml.jackson.core/jackson-core "2.3.1"] [com.
> fasterxml.jackson.dataformat/jackson-dataformat-smile "2.3.1"] [tigris
> "0.1.1"] [clojure-complete "0.2.3" :scope "test" :exclusions [[org.clojure
> /clojure]]] [com.novemberain/langohr "3.0.1"] [clojurewerkz/support
> "1.1.0"] [com.google.guava/guava "18.0"] [com.rabbitmq/amqp-client "3.4.2"
> ] [org.clojure/clojure "1.6.0"] [org.clojure/java.jmx "0.3.0"] [org.
> clojure/tools.logging "0.3.1"] [org.clojure/tools.nrepl "0.2.6" :scope
> "test" :exclusions [[org.clojure/clojure]]] [org.formcept/swissknife
> "0.6.0"] [com.twitter/carbonite "1.4.0"] [com.esotericsoftware.kryo/kryo
> "2.21"] [com.esotericsoftware.minlog/minlog "1.2"] [com.esotericsoftware.
> reflectasm/reflectasm "1.07" :classifier "shaded"] [org.ow2.asm/asm "4.0"]
> [org.objenesis/objenesis "1.2"] [com.twitter/chill-java "0.3.5"] [riemann-
> clojure-client "0.4.2"] [com.aphyr/riemann-java-client "0.4.1"] [com.
> google.protobuf/protobuf-java "2.6.1"] [io.netty/netty "3.6.1.Final"] [riemann
> "0.2.10"] [amazonica "0.3.28" :exclusions [[joda-time]]] [com.amazonaws/
> amazon-kinesis-client "1.1.0" :exclusions [[joda-time]]] [com.taoensso/nippy
> "2.7.0"] [com.taoensso/encore "1.11.2"] [net.jpountz.lz4/lz4 "1.2.0"] [org
> .clojure/tools.reader "0.8.9"] [org.iq80.snappy/snappy "0.3"] [org.tukaani
> /xz "1.5"] [robert/hooke "1.3.0"] [capacitor "0.4.3" :exclusions [[http-
> kit]]] [org.clojure/core.async "0.1.319.0-6b1aca-alpha"] [org.clojure/
> tools.analyzer.jvm "0.1.0-beta12"] [org.clojure/core.memoize "0.5.6"] [org
> .clojure/tools.analyzer "0.1.0-beta12"] [org.ow2.asm/asm-all "4.1"] [clj-antlr
> "0.2.2"] [org.antlr/antlr4-runtime "4.2.2"] [org.abego.treelayout/org.
> abego.treelayout.core "1.0.1"] [org.antlr/antlr4-annotations "4.2.2"] [org
> .antlr/antlr4 "4.2.2"] [org.antlr/ST4 "4.0.8"] [org.antlr/antlr-runtime
> "3.5.2"] [clj-campfire "2.2.0"] [http.async.client "0.5.2"] [com.ning/
> async-http-client "1.7.10"] [clj-http "1.1.2" :exclusions [[org.clojure/
> tools.reader]]] [com.cognitect/transit-clj "0.8.271" :exclusions [[org.
> clojure/clojure]]] [com.cognitect/transit-java "0.8.287"] [com.fasterxml.
> jackson.datatype/jackson-datatype-json-org "2.3.2"] [org.json/json
> "20090211"] [org.apache.directory.studio/org.apache.commons.codec "1.8"] [
> org.msgpack/msgpack "0.6.10"] [com.googlecode.json-simple/json-simple
> "1.1.1" :exclusions [[junit]]] [org.javassist/javassist "3.18.1-GA"] [
> commons-codec "1.10" :exclusions [[org.clojure/clojure]]] [commons-io
> "2.4" :exclusions [[org.clojure/clojure]]] [crouton "0.1.2" :exclusions [[
> org.clojure/clojure]]] [org.jsoup/jsoup "1.7.1"] [org.apache.
> httpcomponents/httpclient "4.4.1" :exclusions [[org.clojure/clojure]]] [
> commons-logging "1.2"] [org.apache.httpcomponents/httpcore "4.4.1" :exclusions
> [[org.clojure/clojure]]] [org.apache.httpcomponents/httpmime "4.4.1" 
> :exclusions
> [[org.clojure/clojure]]] [potemkin "0.3.13" :exclusions [[org.clojure/
> clojure]]] [clj-tuple "0.2.1"] [riddley "0.1.7"] [clj-librato "0.0.5"] [
> clj-nsca "0.0.3"] [com.googlecode/jsendnsca-core "1.3.1"] [clj-time
> "0.10.0"] [joda-time "2.7"] [clj-wallhack "1.0.1"] [com.amazonaws/aws-java
> -sdk "1.10.5.1" :exclusions [[joda-time]]] 
> [com.amazonaws/aws-java-sdk-autoscaling
> "1.10.5.1"] [com.amazonaws/aws-java-sdk-cloudformation "1.10.5.1"] [com.
> amazonaws/aws-java-sdk-cloudfront "1.10.5.1"] 
> [com.amazonaws/aws-java-sdk-cloudhsm
> "1.10.5.1"] [com.amazonaws/aws-java-sdk-cloudsearch "1.10.5.1"] [com.
> amazonaws/aws-java-sdk-cloudtrail "1.10.5.1"] 
> [com.amazonaws/aws-java-sdk-cloudwatch
> "1.10.5.1"] [com.amazonaws/aws-java-sdk-cloudwatchmetrics "1.10.5.1"] [com
> .amazonaws/aws-java-sdk-codecommit "1.10.5.1"] [com.amazonaws/aws-java-sdk
> -codedeploy "1.10.5.1"] [com.amazonaws/aws-java-sdk-codepipeline
> "1.10.5.1"] [com.amazonaws/aws-java-sdk-cognitoidentity "1.10.5.1"] [com.
> amazonaws/aws-java-sdk-cognitosync "1.10.5.1"] [com.amazonaws/aws-java-sdk
> -config "1.10.5.1"] [com.amazonaws/aws-java-sdk-core "1.10.5.1"] [com.
> fasterxml.jackson.core/jackson-databind "2.5.3"] [com.fasterxml.jackson.
> core/jackson-annotations "2.5.0"] [com.amazonaws/aws-java-sdk-datapipeline
> "1.10.5.1"] [com.amazonaws/aws-java-sdk-devicefarm "1.10.5.1"] [com.
> amazonaws/aws-java-sdk-directconnect "1.10.5.1"] [com.amazonaws/aws-java-
> sdk-directory "1.10.5.1"] [com.amazonaws/aws-java-sdk-dynamodb "1.10.5.1"]
> [com.amazonaws/aws-java-sdk-ec2 "1.10.5.1"] [com.amazonaws/aws-java-sdk-ecs
> "1.10.5.1"] [com.amazonaws/aws-java-sdk-efs "1.10.5.1"] [com.amazonaws/aws
> -java-

Re: Compojure does not augment response map

[Gary Verhaegen]

IIRC this has always been the behaviour of compojure: if you return a
string it wraps it into a minimalist, valid Ring map, but if you return a
map it assumes it is a Ring map and leaves it alone.

There is a content-type ring middleware somewhere on the web, though in
general I don't think the content type is something that can be magically
detected.

Any changes in your middlewares? The JSON middlewares in particular tend to
fill in the content type automatically (given a map for the body).


On Wednesday, 24 February 2016, Torsten Uhlmann 
wrote:

> Hi,
>
> I'm experiencing a strange behavior in my app. I'm not sure if that's
> because of a version update or something I broke...
>
> The Compojure version used is 1.4.0
>
> In the past a response like this would usually work:
>
> {:status 404
>  :headers {}
>  :body "Not authorized"}
>
>
> The map would be augmented with missing header information.
>
>
> Now the browser tells me this is an invalid response. Logging the output 
> shows that the map is returned as is, without any additional headers. Adding 
> "Content-Type" "text/html; charset=utf-8" to the :headers manually would 
> solve the problem.
>
>
> When my handler only returns a string, that is turned into a response map:
>
>
> {:status 200,
>  :headers {"Content-Type" "text/html; charset=utf-8"},
>  :body "hiha"}
>
>
> I'm using compojure's "route" function not the "defroutes" macro to assemble 
> route
>
>
> This is the development version middleware stack I'm using:
>
>
> (-> handler
> (wrap-authorization auth-backend)
> (wrap-authentication auth-backend)
> ;(wrap-spy "SPY")
> ext-session/wrap-extended-session
> (wrap-defaults ring-defaults-config)
> auth/wrap-authorized-redirects
> wrap-exceptions
> reload/wrap-reload
> wrap-enlive-reload)
>
>
> I know I could solve this by adding the content type by hand, but I'd like to 
> get to the cause of this. I'd also like to just use response functions 
> provided by ring.util.response, these do also not work currently.
>
>
> I guess I just have misconfigured something- although I have no idea what.
>
>
> Torsten.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: ExceptionInInitialization error

[Gary Verhaegen]

Caused by:java.lang.ClassNotFoundException:com.fasterxml.jackson.dataformat.
cbor.CBORFactory

Looks like a dependency problem. If you can't share the whole code, can you
please post the result of

lein deps :tree

On Wednesday, 24 February 2016, Punit Naik  wrote:

> I was compiling my project and I got this error:
>
>
> java.lang.ExceptionInInitializerError, compiling:(riemann.clj:1:1)
>  at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3558)
>  at clojure.lang.Compiler.compile1(Compiler.java:7226)
>  at clojure.lang.Compiler.compile1(Compiler.java:7216)
>  at clojure.lang.Compiler.compile(Compiler.java:7292)
>  at clojure.lang.RT.compile(RT.java:398)
>  at clojure.lang.RT.load(RT.java:438)
>  at clojure.lang.RT.load(RT.java:411)
>  at clojure.core$load$fn__5066.invoke(core.clj:5641)
>  at clojure.core$load.doInvoke(core.clj:5640)
>  at clojure.lang.RestFn.invoke(RestFn.java:408)
>  at clojure.core$load_one.invoke(core.clj:5446)
>  at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
>  at clojure.core$load_lib.doInvoke(core.clj:5485)
>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>  at clojure.core$apply.invoke(core.clj:626)
>  at clojure.core$load_libs.doInvoke(core.clj:5524)
>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>  at clojure.core$apply.invoke(core.clj:626)
>  at clojure.core$require.doInvoke(core.clj:5607)
>  at clojure.lang.RestFn.invoke(RestFn.java:1523)
>  at chowkidar.core$loading__4958__auto__.invoke(core.clj:1)
>  at clojure.lang.AFn.applyToHelper(AFn.java:152)
>  at clojure.lang.AFn.applyTo(AFn.java:144)
>  at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3553)
>  at clojure.lang.Compiler.compile1(Compiler.java:7226)
>  at clojure.lang.Compiler.compile1(Compiler.java:7216)
>  at clojure.lang.Compiler.compile(Compiler.java:7292)
>  at clojure.lang.RT.compile(RT.java:398)
>  at clojure.lang.RT.load(RT.java:438)
>  at clojure.lang.RT.load(RT.java:411)
>  at clojure.core$load$fn__5066.invoke(core.clj:5641)
>  at clojure.core$load.doInvoke(core.clj:5640)
>  at clojure.lang.RestFn.invoke(RestFn.java:408)
>  at clojure.core$load_one.invoke(core.clj:5446)
>  at clojure.core$compile$fn__5071.invoke(core.clj:5652)
>  at clojure.core$compile.invoke(core.clj:5651)
>  at user$eval9$fn__16.invoke(form-init3209452928121977251.clj:1)
>  at user$eval9.invoke(form-init3209452928121977251.clj:1)
>  at clojure.lang.Compiler.eval(Compiler.java:6703)
>  at clojure.lang.Compiler.eval(Compiler.java:6693)
>  at clojure.lang.Compiler.load(Compiler.java:7130)
>  at clojure.lang.Compiler.loadFile(Compiler.java:7086)
>  at clojure.main$load_script.invoke(main.clj:274)
>  at clojure.main$init_opt.invoke(main.clj:279)
>  at clojure.main$initialize.invoke(main.clj:307)
>  at clojure.main$null_opt.invoke(main.clj:342)
>  at clojure.main$main.doInvoke(main.clj:420)
>  at clojure.lang.RestFn.invoke(RestFn.java:421)
>  at clojure.lang.Var.invoke(Var.java:383)
>  at clojure.lang.AFn.applyToHelper(AFn.java:156)
>  at clojure.lang.Var.applyTo(Var.java:700)
>  at clojure.main.main(main.java:37)
> Caused by: java.lang.ExceptionInInitializerError
>  at java.lang.Class.forName0(Native Method)
>  at java.lang.Class.forName(Class.java:278)
>  at clojure.lang.RT.loadClassForName(RT.java:2093)
>  at clojure.lang.RT.load(RT.java:430)
>  at clojure.lang.RT.load(RT.java:411)
>  at clojure.core$load$fn__5066.invoke(core.clj:5641)
>  at clojure.core$load.doInvoke(core.clj:5640)
>  at clojure.lang.RestFn.invoke(RestFn.java:408)
>  at clojure.core$load_one.invoke(core.clj:5446)
>  at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
>  at clojure.core$load_lib.doInvoke(core.clj:5485)
>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>  at clojure.core$apply.invoke(core.clj:626)
>  at clojure.core$load_libs.doInvoke(core.clj:5524)
>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>  at clojure.core$apply.invoke(core.clj:626)
>  at clojure.core$require.doInvoke(core.clj:5607)
>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>  at cheshire.core$loading__4958__auto__.invoke(core.clj:1)
>  at cheshire.core__init.load(Unknown Source)
>  at cheshire.core__init.(Unknown Source)
>  at java.lang.Class.forName0(Native Method)
>  at java.lang.Class.forName(Class.java:278)
>  at clojure.lang.RT.loadClassForName(RT.java:2093)
>  at clojure.lang.RT.load(RT.java:430)
>  at clojure.lang.RT.load(RT.java:411)
>  at clojure.core$load$fn__5066.invoke(core.clj:5641)
>  at clojure.core$load.doInvoke(core.clj:5640)
>  at clojure.lang.RestFn.invoke(RestFn.java:408)
>  at clojure.core$load_one.invoke(core.clj:5446)
>  at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
>  at clojure.core$load_lib.doInvoke(core.clj:5485)
>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>  at clojure.core$apply.invoke(core.clj:626)
>  at clojure.core$load_libs.doInvoke(core.clj:5524)
>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>  at clojure.core$apply.invoke(core.clj:626)
>  at clojure.core$require.doInvoke(core.clj:5607)
>  at clojure.lang

Compojure does not augment response map

[Torsten Uhlmann]

Hi,

I'm experiencing a strange behavior in my app. I'm not sure if that's 
because of a version update or something I broke...

The Compojure version used is 1.4.0

In the past a response like this would usually work:

{:status 404
 :headers {}
 :body "Not authorized"}


The map would be augmented with missing header information.


Now the browser tells me this is an invalid response. Logging the output shows 
that the map is returned as is, without any additional headers. Adding 
"Content-Type" "text/html; charset=utf-8" to the :headers manually would solve 
the problem.


When my handler only returns a string, that is turned into a response map:


{:status 200,
 :headers {"Content-Type" "text/html; charset=utf-8"},
 :body "hiha"}


I'm using compojure's "route" function not the "defroutes" macro to assemble 
route


This is the development version middleware stack I'm using:


(-> handler
(wrap-authorization auth-backend)
(wrap-authentication auth-backend)
;(wrap-spy "SPY")
ext-session/wrap-extended-session
(wrap-defaults ring-defaults-config)
auth/wrap-authorized-redirects
wrap-exceptions
reload/wrap-reload
wrap-enlive-reload)


I know I could solve this by adding the content type by hand, but I'd like to 
get to the cause of this. I'd also like to just use response functions provided 
by ring.util.response, these do also not work currently.


I guess I just have misconfigured something- although I have no idea what.


Torsten.


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