Re: Clojure, floats, ints and OpenGL
You can always fork Clojure and patch IFn.java and Compiler.java to support floats for at least some types of functions. It probably won't be so hard. As your case is a very specific one, this may be a viable solution. JW On Mon, Sep 16, 2013 at 11:40 PM, Alex Fowler alex.murat...@gmail.comwrote: Timothy, thank you very much for such a good explanation! I fully agree with you. Actually, except for a few details, that is really how I thought the things are. It is good that you describe the technical base for problems with the issue. As well as clearified the human factor. What you're saying is very much like what I would say if I were in your shoes. Currently, what you're saying, is the present. In the present we make our choices for currents. And I also agree with Mikera, that an attempt should be taken. I would participate in it myself if I was into JVM and Clojure internals. I plan to learn it, but it will take time. Mikera, thanks for the reference for the library, I will have a look. Also I strongly encourage you in the attempt and I will be happy if I can be of any help, although, you seem to know much more than me. I agree with Tim that some more decisive steps have to be taken into this direction. James, ah.. yes, we did benchmarks. We use highly optimized mathematical calculations, derived from numerical analysis. Every single instruction matters there. Due to the nature of the calculations, the amout of casts, however, varies from 3 to N in one computation. There can be 1 to M such computation for a data unit. And thre can be 1 to P data units. At the end, what worked on plain Java or Java-stylized Scala, worked that times faster, NxMxP more instructions to be computed. Where there were 500 fps, sometimes happen to be 480 fps and sometimes 0.01 fps. And I am not even talking about operations on vast arrays or NIO buffers. But imagine for example, you have a 1.5GB float NIO-buffer, that came from an OpenGL data-type and will go back to it. Operation on each float takes, say 5 casts double-float in Clojure. Also, as Mikera points out, bus speeds come into play too. Of course, as Timothy said, why don't we go back to C for that kind of stuff? This is a popular question in such cases. I am not going to go into details on that, except for saying that we have mostly migrated from C to JVM and it satisfies our requirements, while giving huge benifits. However, we still do some things in C. To prevent arguments, here is an articlehttp://beautynbits.blogspot.ru/2013/01/performance-java-vs-c.html that somewhat describes what one can lose in computation, but does not describe what one gains in other aspects. The loss is what can be tolerated. But that loss for JVM is understandable. The one more loss for Clojure is understandable too, but it can be changed. I think that the discussion branch of Java vs C may be laid to rest. On Mon, Sep 16, 2013 at 9:03 PM, James Reeves ja...@booleanknot.comwrote: On 16 September 2013 09:03, Mikera mike.r.anderson...@gmail.com wrote: Obviously this is just a microbenchmark, but it fits my general experience that floats are a reasonable bit faster than doubles, typically 20-100% (doubles are closer when it is pure number crunching since 64-bit CPUs are actually pretty good at doubles, floats have a bigger advantage when you are manipulating a lot of data points and hence memory bandwidth matters more) Code here for those interested: src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java That's a pretty interesting result. I ran some tests of my own, based on your code, as I wondered whether or not the time to instantiate the array of doubles was biasing the test. My goal was to see whether or not I'd get a similar result running an array of floats through a method that processed doubles. (See: https://gist.github.com/weavejester/6583367) It turns out that I get a similar result. Passing floats to a method that takes doubles slows things down by a similar amount, unless I've somehow botched up the test. Considering that converting between single and double precision should be pretty cheap on the CPU, I'm surprised at the difference. This somewhat changes my view on things. It doesn't affect me in practice, but I can see how someone might be frustrated by having to drop down to Java to achieve performance for floating point calculations. - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To
Re: Clojure, floats, ints and OpenGL
Please, no! Sure, forking Clojure is technically possible and might even solve the specific problem for the OP. But that's not the point. This isn't a technical problem, it's a social/organisational problem. The idea that we should fork Clojure (or even create an intricate clever new library that does some funky code generation) every time someone has a new performance requirement is going to be disastrous for the Clojure ecosystem. It will cause massive fragmentation and/or cause people to give up and abandon Clojure altogether. People have written extensively about the Lisp Curse and this is exactly the kind of dysfunction we should try to avoid. See e.g.: http://kresimirbojcic.com/2012/08/14/why-lisp-did-not-and-never-will-gain-enough-traction.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html The right answer is to figure out how to get these kind of core improvements into Clojure itself. That's harder to do. It requires people to work together and understand each others' requirements rather than just dismissing them (the well I don't need this so you should just find a workaround attitude isn't at all helpful). It requires engaging, cultivating and encouraging the people with the skill and motivation to to make these kind of improvements. It may require developing a proper roadmap for Clojure. It requires people to sign CAs and follow JIRA processes etc. But the effort to do this is worth it: this way everyone benefits from the development effort, we avoid creating a thousand different incompatible software stacks, and we make traction happen on Clojure development itself. Please note: my only reason for arguing passionately about this kind of stuff is to help Clojure succeed. Presumably that's what we would all like to see, or we wouldn't be here, right? On Tuesday, 17 September 2013 14:48:32 UTC+8, Jozef Wagner wrote: You can always fork Clojure and patch IFn.java and Compiler.java to support floats for at least some types of functions. It probably won't be so hard. As your case is a very specific one, this may be a viable solution. JW On Mon, Sep 16, 2013 at 11:40 PM, Alex Fowler alex.m...@gmail.comjavascript: wrote: Timothy, thank you very much for such a good explanation! I fully agree with you. Actually, except for a few details, that is really how I thought the things are. It is good that you describe the technical base for problems with the issue. As well as clearified the human factor. What you're saying is very much like what I would say if I were in your shoes. Currently, what you're saying, is the present. In the present we make our choices for currents. And I also agree with Mikera, that an attempt should be taken. I would participate in it myself if I was into JVM and Clojure internals. I plan to learn it, but it will take time. Mikera, thanks for the reference for the library, I will have a look. Also I strongly encourage you in the attempt and I will be happy if I can be of any help, although, you seem to know much more than me. I agree with Tim that some more decisive steps have to be taken into this direction. James, ah.. yes, we did benchmarks. We use highly optimized mathematical calculations, derived from numerical analysis. Every single instruction matters there. Due to the nature of the calculations, the amout of casts, however, varies from 3 to N in one computation. There can be 1 to M such computation for a data unit. And thre can be 1 to P data units. At the end, what worked on plain Java or Java-stylized Scala, worked that times faster, NxMxP more instructions to be computed. Where there were 500 fps, sometimes happen to be 480 fps and sometimes 0.01 fps. And I am not even talking about operations on vast arrays or NIO buffers. But imagine for example, you have a 1.5GB float NIO-buffer, that came from an OpenGL data-type and will go back to it. Operation on each float takes, say 5 casts double-float in Clojure. Also, as Mikera points out, bus speeds come into play too. Of course, as Timothy said, why don't we go back to C for that kind of stuff? This is a popular question in such cases. I am not going to go into details on that, except for saying that we have mostly migrated from C to JVM and it satisfies our requirements, while giving huge benifits. However, we still do some things in C. To prevent arguments, here is an articlehttp://beautynbits.blogspot.ru/2013/01/performance-java-vs-c.html that somewhat describes what one can lose in computation, but does not describe what one gains in other aspects. The loss is what can be tolerated. But that loss for JVM is understandable. The one more loss for Clojure is understandable too, but it can be changed. I think that the discussion branch of Java vs C may be laid to rest. On Mon, Sep 16, 2013 at 9:03 PM, James Reeves ja...@booleanknot.comjavascript: wrote: On 16 September 2013 09:03,
Re: [ANN] Cognitect
Congrats on the new venture - wishing you the best of luck! On Monday, 16 September 2013 21:50:46 UTC+8, Rich Hickey wrote: I just wanted to let everyone know that Metadata Partners (the company behind Datomic) and I have merged with Relevance, Inc., to form Cognitect, Inc. This merger is great for Clojure, adding considerable resources and stability to its development and support, including new enterprise support offerings and reinvigorated community support. (You should read the hiring of Alex Miller as the first example of the latter). I hope the availability of enterprise support for the entire platform makes it easier for people to introduce Clojure into their organizations. This is a very exciting time for Clojure and the platform and ecosystem surrounding it. You can find out more at: http://cognitect.com Thanks, Rich -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Memory leak problem
Dear Andy, Thanks for your reply. I am using java version 1.6.0_51. I'm a bit reluctant to upgrade however, so I was wondering how sure you are that this is indeed the problem? The problem persists after calling clojure.tools.reader.edn/read on (java.io.PushbackReader. (clojure.java.io/reader f)) by the way, so maybe it's something else after all? Joachim. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Memory leak problem
Dear Brian, Thanks for your reply. I tried to use jmap, unfortunately it fails: bash-3.2$ jmap -F -dump:file=heap.bin 58708 Attaching to process ID 58708, please wait... Debugger attached successfully. Server compiler detected. JVM version is 20.51-b01-457 Dumping heap to heap.bin ... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.tools.jmap.JMap.runTool(JMap.java:179) at sun.tools.jmap.JMap.main(JMap.java:110) Caused by: sun.jvm.hotspot.oops.UnknownOopException As for visualvm: it never seems to finish producing a heap dump :( Joachim. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: interleave with one argument
Hi Denis, This should also work, but fails for the same reason you outline: #(apply interleave (repeat %2 %1)) The jira ticket says the enhancement was closed in V1.3 although it is still failing in V1.5.1. P. On Friday, February 15, 2013 9:15:31 PM UTC, Denis Washington wrote: Hi, I just solved the Replicate a Sequence problem on 4clojure [1] using interleave. However, I noticed that interleave cannot be called with a single argument. My first attempt at solving the problem was like this: (defn replicate-n-times [xs n] (apply interleave (replicate n xs))) This works fine for n 1: clojure= (replicate-n-times [1 2 3] 3) (1 1 1 2 2 2 3 3 3) However, for n = 1 the function fails with an exception: clojure= (replicate-n-times [1 2 3] 1) ArityException Wrong number of args (1) passed to: core$interleave clojure.lang.AFn.throwArity (AFn.java:437) I had to add a special case to make this work: (fn replicate-n-times [xs n] (if (= n 1) xs (apply interleave (replicate n xs I think it would be nice if interleave called with a single argument would just return the argument itself, just like single-argument + and * do. Regards, Denis Washington [1] http://www.4clojure.com/problem/33 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: interleave with one argument
My bad - fixed in 1.6! On Friday, February 15, 2013 9:15:31 PM UTC, Denis Washington wrote: Hi, I just solved the Replicate a Sequence problem on 4clojure [1] using interleave. However, I noticed that interleave cannot be called with a single argument. My first attempt at solving the problem was like this: (defn replicate-n-times [xs n] (apply interleave (replicate n xs))) This works fine for n 1: clojure= (replicate-n-times [1 2 3] 3) (1 1 1 2 2 2 3 3 3) However, for n = 1 the function fails with an exception: clojure= (replicate-n-times [1 2 3] 1) ArityException Wrong number of args (1) passed to: core$interleave clojure.lang.AFn.throwArity (AFn.java:437) I had to add a special case to make this work: (fn replicate-n-times [xs n] (if (= n 1) xs (apply interleave (replicate n xs I think it would be nice if interleave called with a single argument would just return the argument itself, just like single-argument + and * do. Regards, Denis Washington [1] http://www.4clojure.com/problem/33 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, floats, ints and OpenGL
Here is the mundane patch I described earlier: https://github.com/cgrand/clojure/commit/4c202ad9757ce47ac9e669847c0e5bf68785e2d6 It adds four functions (add-, multiply-, divide- and subtract-float), backs them with their corresponding bytecodes and enhance the conversion emitted when going from long/int to double/float. Please give it a try. It doesn't help with functions taking primitive but it's another problem. Christophe On Mon, Sep 16, 2013 at 7:03 PM, James Reeves ja...@booleanknot.com wrote: On 16 September 2013 09:03, Mikera mike.r.anderson...@gmail.com wrote: Obviously this is just a microbenchmark, but it fits my general experience that floats are a reasonable bit faster than doubles, typically 20-100% (doubles are closer when it is pure number crunching since 64-bit CPUs are actually pretty good at doubles, floats have a bigger advantage when you are manipulating a lot of data points and hence memory bandwidth matters more) Code here for those interested: src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java That's a pretty interesting result. I ran some tests of my own, based on your code, as I wondered whether or not the time to instantiate the array of doubles was biasing the test. My goal was to see whether or not I'd get a similar result running an array of floats through a method that processed doubles. (See: https://gist.github.com/weavejester/6583367) It turns out that I get a similar result. Passing floats to a method that takes doubles slows things down by a similar amount, unless I've somehow botched up the test. Considering that converting between single and double precision should be pretty cheap on the CPU, I'm surprised at the difference. This somewhat changes my view on things. It doesn't affect me in practice, but I can see how someone might be frustrated by having to drop down to Java to achieve performance for floating point calculations. - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting Contracting http://lambdanext.eu/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clojure-sql 0.1.0: relational algebra in clojure
This library looks great!
I've always liked ClojureQL much more than the other Clojure SQL libraries,
exactly for its emphasis on composability
and relational algebra.
At first looks - your library looks like it will be easier to extend for
different database servers...
I'd be interested in knowing some more about your approach compared to that
of ClojureQL and the motivation behind it.
Dan
On Saturday, July 6, 2013 5:34:37 PM UTC+2, r0man wrote:
You can do this with the second argument to the where function. I added an
example here:
https://github.com/r0man/sqlingvo/blob/master/test/sqlingvo/test/core.clj#L24
On Saturday, July 6, 2013 4:02:23 PM UTC+2, Carlo wrote:
This is a fairly restricted composition, though:
(def triangles (compose (select [:color :num_sides] (from :shapes))
(where '(= :num_sides 3
(def green-triangles (compose triangles
(where '(= :color green
(sql green-triangles)
;= [SELECT color, num_sides FROM shapes WHERE (color = ?) green]
We've lost our `num_sides` selection, so now our query is wrong. Last
clause wins means you have to be aware of the previous ones to ensure you
don't obliterate them when composing.
The same example in `clojure-sql`:
(def triangles (- (table :shapes)
(project [:color :num_sides])
(select '(= :num_sides 3
(def green-triangles (select triangles '(= :color :green)))
(deref green-triangles)
;= [SELECT \shapes2142\.\color\ AS \color\,
\shapes2142\.\num_sides\ AS \num_sides\ FROM \shapes\ AS
\shapes2142\ WHERE ((\shapes2142\.\num_sides\ = 3) AND
(\shapes2142\.\color\ = ?)) green]
On 6 July 2013 22:37, r0man roman@burningswell.com wrote:
Composing queries is done via compose.
Take a look here:
https://github.com/r0man/sqlingvo/blob/master/test/sqlingvo/test/core.clj#L16
On Saturday, July 6, 2013 5:46:06 AM UTC+2, Carlo wrote:
Hey Roman,
The issue that I see with `sqlingvo`, and the thing which I was trying
to solve for myself, is that it doesn't compose well. Unless I'm missing
something, you have to generate the entire query in the one `sql` form. To
me, this is a big restriction and was the number one thing I was trying to
fix with `clojure-sql`.
The basic sort of thing I want to be able to do is this:
(def users (- (table :users) (project [:id :person :username])))
(def people (- (table :people) (project [:id :first-name])))
(def combined-query (- people
(rename {:id :person})
(join users)
(project [:username :first-name])))
So now in queries I can use `people`, `users` and `combined-query` in
the same way. The only difference in terms of how I can compose them is
that they expose different fields (`users` exposes [:id, :person,
:username], `people` exposes [:id :first-name], `combined-query` exposes
[:username :first-name]). In this example it's not completely obvious why
this would be beneficial, but it means that I can change `users`, for
instance, to also have a `(select '(= :deleted false)` in its definition
and no other code has to change. They will all join/query against the
users
where `deleted` is false without any other modifications of code.
This freedom of composition is what you have in relational algebra, and
what I was trying to get in Clojure as well. All the naming of tables and
field aliases and everything is handled by the library, so you only have
to
worry about constructing the queries. Unfortunately SQL provides a number
of operations outside of the relational algebra model (grouping, sorting,
take/drop), so they've been tacked on as a bit of an afterthought and
could probably use some improvement.
Looking at `sqlingvo` did show up a mistake that I made in how I was
dealing with sorts, though, so thanks for that! I think our libraries just
have fairly different concerns at the moment.
Carlo
On 5 July 2013 20:59, r0man roman@burningswell.**com wrote:
Hi Carlo,
if you'are looking for generating more complex SQL there's also:
https://github.com/r0man/**sqlingvohttps://github.com/r0man/sqlingvo
Roman.
On Wednesday, July 3, 2013 10:48:07 AM UTC+2, Carlo wrote:
Hey guys!
I've been working on a small library to make writing SQL queries a
little bit easier. It's along the same lines as ClojureQL, but takes a
different approach and compiles into quite different SQL in the end.
At the moment it's quite immature, but it should be able to support
any queries which can be expressed in relational algebra. There will be
some SQL queries which can't be expressed in clojure-sql, but hopefully
there won't be too many of those. A greater limitation is that at the
moment the SQL generation is specific to the PostgresSQL database
(although
any contributions for other databases are welcome!).
Dependency vector:
Re: Weird core.async/ClojureScript not workings...
I'm having the same issue. Here's a project with a timeout loop demonstrating the problem: https://github.com/zentrope/clock Using core.async SNAPSHOT and any clojurescript release after 1859 seems to break along the same lines as the OP. Other elements I have going: - cljsbuild 0.3.3 - prismatic 0.1.2 but they don't seem to cause issues with 1859. If you've got any tips on using core.async master (maybe using lein's checkout feature?) I wouldn't mind trying that. On Sep 16, 2013, at 3:32 PM, David Nolen dnolen.li...@gmail.com wrote: Which versions of ClojureScript and core.async are you using? David On Mon, Sep 16, 2013 at 5:25 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I'm using core.async and ClojureScript and it seems that inside a go block, if/when/loop/while code is never executed. For example: (def dog33 (go (if true (.log js/console it's true) (.log js/console it's false prints neither it's true nor it's false, but (def dog33 (go (do (.log js/console it's true) (.log js/console it's false prints both. I'm doing lein cljsbuild auto to generate the JavaScript. Any pointers would be appreciated. Thanks, David -- Brick Alloy http://brickalloy. Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Memory leak problem
If the problem persists after that change, then at least we know that it isn't the large strings produced by 'slurp' that are causing the problem, but something else. I don't have any guesses based on what you have shown where that might be. I've seen your message about difficulties using tools like jmap and visualvm -- I'd recommend doing Google searches for the name of the tool and the error message you get. That often turns up questions where someone else has a similar error, and sometimes a solution is given to the problem. Andy On Tue, Sep 17, 2013 at 2:11 AM, Joachim De Beule joachim.de.be...@gmail.com wrote: Dear Andy, Thanks for your reply. I am using java version 1.6.0_51. I'm a bit reluctant to upgrade however, so I was wondering how sure you are that this is indeed the problem? The problem persists after calling clojure.tools.reader.edn/read on (java.io.PushbackReader. ( clojure.java.io/reader f)) by the way, so maybe it's something else after all? Joachim. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Weird core.async/ClojureScript not workings...
Works fine for me using core.async master. I just ran `lein install` from the core.async directory and changed project.clj core.async to: [core.async 0.1.0-SNAPSHOT] David On Mon, Sep 16, 2013 at 11:29 PM, Keith Irwin ke...@devtrope.com wrote: I'm having the same issue. Here's a project with a timeout loop demonstrating the problem: https://github.com/zentrope/clock Using core.async SNAPSHOT and any clojurescript release after 1859 seems to break along the same lines as the OP. Other elements I have going: - cljsbuild 0.3.3 - prismatic 0.1.2 but they don't seem to cause issues with 1859. If you've got any tips on using core.async master (maybe using lein's checkout feature?) I wouldn't mind trying that. On Sep 16, 2013, at 3:32 PM, David Nolen dnolen.li...@gmail.com wrote: Which versions of ClojureScript and core.async are you using? David On Mon, Sep 16, 2013 at 5:25 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I'm using core.async and ClojureScript and it seems that inside a go block, if/when/loop/while code is never executed. For example: (def dog33 (go (if true (.log js/console it's true) (.log js/console it's false prints neither it's true nor it's false, but (def dog33 (go (do (.log js/console it's true) (.log js/console it's false prints both. I'm doing lein cljsbuild auto to generate the JavaScript. Any pointers would be appreciated. Thanks, David -- Brick Alloy http://brickalloy. https://telegr.am/ Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Weird core.async/ClojureScript not workings...
I continue to see the issue with 1878/0.1.0-SNAPSHOT, but when I rolled back to 1859, the issue went away. Thanks Keith! On Tue, Sep 17, 2013 at 6:42 AM, David Nolen dnolen.li...@gmail.com wrote: Works fine for me using core.async master. I just ran `lein install` from the core.async directory and changed project.clj core.async to: [core.async 0.1.0-SNAPSHOT] David On Mon, Sep 16, 2013 at 11:29 PM, Keith Irwin ke...@devtrope.com wrote: I'm having the same issue. Here's a project with a timeout loop demonstrating the problem: https://github.com/zentrope/clock Using core.async SNAPSHOT and any clojurescript release after 1859 seems to break along the same lines as the OP. Other elements I have going: - cljsbuild 0.3.3 - prismatic 0.1.2 but they don't seem to cause issues with 1859. If you've got any tips on using core.async master (maybe using lein's checkout feature?) I wouldn't mind trying that. On Sep 16, 2013, at 3:32 PM, David Nolen dnolen.li...@gmail.com wrote: Which versions of ClojureScript and core.async are you using? David On Mon, Sep 16, 2013 at 5:25 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I'm using core.async and ClojureScript and it seems that inside a go block, if/when/loop/while code is never executed. For example: (def dog33 (go (if true (.log js/console it's true) (.log js/console it's false prints neither it's true nor it's false, but (def dog33 (go (do (.log js/console it's true) (.log js/console it's false prints both. I'm doing lein cljsbuild auto to generate the JavaScript. Any pointers would be appreciated. Thanks, David -- Brick Alloy http://brickalloy. https://telegr.am/ Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Brick Alloy http://brickalloy.com https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this
Re: another game of exploding heap, via clojure.string/split
Another possibility: The people who know aren't reading this thread. I'd tell you if I knew, but I haven't needed to track down a problem like this for several years, and forgotten whatever tool I used at the time (it was probably jmap). Suggestion: Google search java memory leak and see what tools and techniques people suggest in articles they write on the topic. Andy On Tue, Sep 17, 2013 at 8:07 AM, Brian Craft craft.br...@gmail.com wrote: On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote: On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut andy.fi...@gmail.comwrote: I have just added some discussion of this on ClojureDocs.org for the function clojure.core/subs, and references to that discussion for several other Clojure functions that I am pretty sure are affected, e.g. re-find, re-seq, re-matches, clojure.string/split, replace, replace-first We know with certainty that clojure.string/split is affected. Also, the OP's question about how to use tooling to track down similar leaks in the future does not appear to have been satisfactorily answered as of yet. cricket, cricket, cricket... ;) Is there really no working tooling for the jvm? The string thing bothers me less than the problem of seq heads. It is ridiculously easy to create a memory leak with a seq, and desperately hard to track one down. I would be surprised if most clojure apps were not leaking memory somewhere, in places that go unnoticed until a sufficiently large input fills the heap. I wonder if a static analysis approach could identify code that appears to retain a seq head to no effect. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: another game of exploding heap, via clojure.string/split
On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote: On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut andy.fi...@gmail.comjavascript: wrote: I have just added some discussion of this on ClojureDocs.org for the function clojure.core/subs, and references to that discussion for several other Clojure functions that I am pretty sure are affected, e.g. re-find, re-seq, re-matches, clojure.string/split, replace, replace-first We know with certainty that clojure.string/split is affected. Also, the OP's question about how to use tooling to track down similar leaks in the future does not appear to have been satisfactorily answered as of yet. cricket, cricket, cricket... ;) Is there really no working tooling for the jvm? The string thing bothers me less than the problem of seq heads. It is ridiculously easy to create a memory leak with a seq, and desperately hard to track one down. I would be surprised if most clojure apps were not leaking memory somewhere, in places that go unnoticed until a sufficiently large input fills the heap. I wonder if a static analysis approach could identify code that appears to retain a seq head to no effect. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Hotspot predictability
I ran a little benchmark comparing different implementations of a toy pattern matching protocol: https://gist.github.com/jamii/6595850 I'm surprised to find that the staged version is not significantly slower than the compiled version. Now I'm wondering whether this is feasible on a larger scale. Can I always rely on those fns being inlined? Is there some magic threshold on closure nesting where suddenly there will be inlining and I will blow up my stack? More generally, how can I find out this sort of thing? There seems to be very little hard information on what optimisations hotspot will reliably perform. This looks like it could be useful - http://mechanical-sympathy.blogspot.co.uk/2013/06/printing-generated-assembly-code-from.html - but I'm not sure how I would make that work with clojures class name mangling for closures. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: another game of exploding heap, via clojure.string/split
You might want to give Eclipse MAT (http://www.eclipse.org/mat/) a try. It can be used as a standalone tool. Julien Le mardi 17 septembre 2013 12:45:41 UTC-3, Brian Craft a écrit : I did, of course, spend a lot of time with google before posting. All of the hits point to jconsole, jmap, and visualvm. None of these tools work reliably. They hang, they crash, they spit up errors, they generate useless results. You'll note in another thread this morning another developer having jmap and visualvm barf on them. It's not an isolated incident. On Tuesday, September 17, 2013 8:21:14 AM UTC-7, Andy Fingerhut wrote: Another possibility: The people who know aren't reading this thread. I'd tell you if I knew, but I haven't needed to track down a problem like this for several years, and forgotten whatever tool I used at the time (it was probably jmap). Suggestion: Google search java memory leak and see what tools and techniques people suggest in articles they write on the topic. Andy On Tue, Sep 17, 2013 at 8:07 AM, Brian Craft craft...@gmail.com wrote: On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote: On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut andy.fi...@gmail.comwrote: I have just added some discussion of this on ClojureDocs.org for the function clojure.core/subs, and references to that discussion for several other Clojure functions that I am pretty sure are affected, e.g. re-find, re-seq, re-matches, clojure.string/split, replace, replace-first We know with certainty that clojure.string/split is affected. Also, the OP's question about how to use tooling to track down similar leaks in the future does not appear to have been satisfactorily answered as of yet. cricket, cricket, cricket... ;) Is there really no working tooling for the jvm? The string thing bothers me less than the problem of seq heads. It is ridiculously easy to create a memory leak with a seq, and desperately hard to track one down. I would be surprised if most clojure apps were not leaking memory somewhere, in places that go unnoticed until a sufficiently large input fills the heap. I wonder if a static analysis approach could identify code that appears to retain a seq head to no effect. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: another game of exploding heap, via clojure.string/split
I didn't notice before posting my previous message that YourKit also has a free for open source project use only license for their tool. Click on the Open Source or License Comparison tabs on this page: http://www.yourkit.com/purchase/index.jsp On Tue, Sep 17, 2013 at 8:56 AM, Andy Fingerhut andy.finger...@gmail.comwrote: Some of the hits point at commercial tools, which you didn't mention. I've heard positive comments about YourKit in the past. It is commercial, but it looks pretty easy to get a 15-day evaluation license. I haven't used it, but it claims to have some features to aid in detecting and analyzing memory leaks: http://www.yourkit.com/docs/80/help/memory_leaks.jsp I also saw hits for a tool called plumbr. I have no information about it, good or bad. Andy On Tue, Sep 17, 2013 at 8:45 AM, Brian Craft craft.br...@gmail.comwrote: I did, of course, spend a lot of time with google before posting. All of the hits point to jconsole, jmap, and visualvm. None of these tools work reliably. They hang, they crash, they spit up errors, they generate useless results. You'll note in another thread this morning another developer having jmap and visualvm barf on them. It's not an isolated incident. On Tuesday, September 17, 2013 8:21:14 AM UTC-7, Andy Fingerhut wrote: Another possibility: The people who know aren't reading this thread. I'd tell you if I knew, but I haven't needed to track down a problem like this for several years, and forgotten whatever tool I used at the time (it was probably jmap). Suggestion: Google search java memory leak and see what tools and techniques people suggest in articles they write on the topic. Andy On Tue, Sep 17, 2013 at 8:07 AM, Brian Craft craft...@gmail.com wrote: On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote: On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut andy.fi...@gmail.comwrote: I have just added some discussion of this on ClojureDocs.org for the function clojure.core/subs, and references to that discussion for several other Clojure functions that I am pretty sure are affected, e.g. re-find, re-seq, re-matches, clojure.string/split, replace, replace-first We know with certainty that clojure.string/split is affected. Also, the OP's question about how to use tooling to track down similar leaks in the future does not appear to have been satisfactorily answered as of yet. cricket, cricket, cricket... ;) Is there really no working tooling for the jvm? The string thing bothers me less than the problem of seq heads. It is ridiculously easy to create a memory leak with a seq, and desperately hard to track one down. I would be surprised if most clojure apps were not leaking memory somewhere, in places that go unnoticed until a sufficiently large input fills the heap. I wonder if a static analysis approach could identify code that appears to retain a seq head to no effect. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe
Re: Clojure, floats, ints and OpenGL
I ported Mikera's benchmark to Clojure using my patch https://gist.github.com/cgrand/6595939 The ratio between time-float and time-double (0.632) is very similar to the ratio between timeFloat and timeDouble Mikera reported (0.618) On Tue, Sep 17, 2013 at 1:25 PM, Christophe Grand christo...@cgrand.netwrote: Here is the mundane patch I described earlier: https://github.com/cgrand/clojure/commit/4c202ad9757ce47ac9e669847c0e5bf68785e2d6 It adds four functions (add-, multiply-, divide- and subtract-float), backs them with their corresponding bytecodes and enhance the conversion emitted when going from long/int to double/float. Please give it a try. It doesn't help with functions taking primitive but it's another problem. Christophe On Mon, Sep 16, 2013 at 7:03 PM, James Reeves ja...@booleanknot.comwrote: On 16 September 2013 09:03, Mikera mike.r.anderson...@gmail.com wrote: Obviously this is just a microbenchmark, but it fits my general experience that floats are a reasonable bit faster than doubles, typically 20-100% (doubles are closer when it is pure number crunching since 64-bit CPUs are actually pretty good at doubles, floats have a bigger advantage when you are manipulating a lot of data points and hence memory bandwidth matters more) Code here for those interested: src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java That's a pretty interesting result. I ran some tests of my own, based on your code, as I wondered whether or not the time to instantiate the array of doubles was biasing the test. My goal was to see whether or not I'd get a similar result running an array of floats through a method that processed doubles. (See: https://gist.github.com/weavejester/6583367) It turns out that I get a similar result. Passing floats to a method that takes doubles slows things down by a similar amount, unless I've somehow botched up the test. Considering that converting between single and double precision should be pretty cheap on the CPU, I'm surprised at the difference. This somewhat changes my view on things. It doesn't affect me in practice, but I can see how someone might be frustrated by having to drop down to Java to achieve performance for floating point calculations. - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting Contracting http://lambdanext.eu/ -- On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting Contracting http://lambdanext.eu/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: another game of exploding heap, via clojure.string/split
Awesome, thanks! I'd forgotten about the hits for MAT, because I don't use eclipse, and I had not found YourKit. On Tuesday, September 17, 2013 9:13:17 AM UTC-7, Andy Fingerhut wrote: I didn't notice before posting my previous message that YourKit also has a free for open source project use only license for their tool. Click on the Open Source or License Comparison tabs on this page: http://www.yourkit.com/purchase/index.jsp On Tue, Sep 17, 2013 at 8:56 AM, Andy Fingerhut andy.fi...@gmail.comjavascript: wrote: Some of the hits point at commercial tools, which you didn't mention. I've heard positive comments about YourKit in the past. It is commercial, but it looks pretty easy to get a 15-day evaluation license. I haven't used it, but it claims to have some features to aid in detecting and analyzing memory leaks: http://www.yourkit.com/docs/80/help/memory_leaks.jsp I also saw hits for a tool called plumbr. I have no information about it, good or bad. Andy On Tue, Sep 17, 2013 at 8:45 AM, Brian Craft craft...@gmail.comjavascript: wrote: I did, of course, spend a lot of time with google before posting. All of the hits point to jconsole, jmap, and visualvm. None of these tools work reliably. They hang, they crash, they spit up errors, they generate useless results. You'll note in another thread this morning another developer having jmap and visualvm barf on them. It's not an isolated incident. On Tuesday, September 17, 2013 8:21:14 AM UTC-7, Andy Fingerhut wrote: Another possibility: The people who know aren't reading this thread. I'd tell you if I knew, but I haven't needed to track down a problem like this for several years, and forgotten whatever tool I used at the time (it was probably jmap). Suggestion: Google search java memory leak and see what tools and techniques people suggest in articles they write on the topic. Andy On Tue, Sep 17, 2013 at 8:07 AM, Brian Craft craft...@gmail.comwrote: On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote: On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut andy.fi...@gmail.com wrote: I have just added some discussion of this on ClojureDocs.org for the function clojure.core/subs, and references to that discussion for several other Clojure functions that I am pretty sure are affected, e.g. re-find, re-seq, re-matches, clojure.string/split, replace, replace-first We know with certainty that clojure.string/split is affected. Also, the OP's question about how to use tooling to track down similar leaks in the future does not appear to have been satisfactorily answered as of yet. cricket, cricket, cricket... ;) Is there really no working tooling for the jvm? The string thing bothers me less than the problem of seq heads. It is ridiculously easy to create a memory leak with a seq, and desperately hard to track one down. I would be surprised if most clojure apps were not leaking memory somewhere, in places that go unnoticed until a sufficiently large input fills the heap. I wonder if a static analysis approach could identify code that appears to retain a seq head to no effect. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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
Re: another game of exploding heap, via clojure.string/split
I did, of course, spend a lot of time with google before posting. All of the hits point to jconsole, jmap, and visualvm. None of these tools work reliably. They hang, they crash, they spit up errors, they generate useless results. You'll note in another thread this morning another developer having jmap and visualvm barf on them. It's not an isolated incident. On Tuesday, September 17, 2013 8:21:14 AM UTC-7, Andy Fingerhut wrote: Another possibility: The people who know aren't reading this thread. I'd tell you if I knew, but I haven't needed to track down a problem like this for several years, and forgotten whatever tool I used at the time (it was probably jmap). Suggestion: Google search java memory leak and see what tools and techniques people suggest in articles they write on the topic. Andy On Tue, Sep 17, 2013 at 8:07 AM, Brian Craft craft...@gmail.comjavascript: wrote: On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote: On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut andy.fi...@gmail.comwrote: I have just added some discussion of this on ClojureDocs.org for the function clojure.core/subs, and references to that discussion for several other Clojure functions that I am pretty sure are affected, e.g. re-find, re-seq, re-matches, clojure.string/split, replace, replace-first We know with certainty that clojure.string/split is affected. Also, the OP's question about how to use tooling to track down similar leaks in the future does not appear to have been satisfactorily answered as of yet. cricket, cricket, cricket... ;) Is there really no working tooling for the jvm? The string thing bothers me less than the problem of seq heads. It is ridiculously easy to create a memory leak with a seq, and desperately hard to track one down. I would be surprised if most clojure apps were not leaking memory somewhere, in places that go unnoticed until a sufficiently large input fills the heap. I wonder if a static analysis approach could identify code that appears to retain a seq head to no effect. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Memory leak problem
I'm learning that the tooling for the jvm covers a spectrum from pathetically broken to non-existent. I've had some luck running jmap like jmap -histo:live pid. Pipe it through head and run with watch, and you have a crude real-time monitor. E.g. running against the processing running from a SNAPSHOT uberjar: watch jmap -histo:live $(ps axu | grep SNA[P] | sed -e 's/ \+/\t/g' | cut -f2) \| head -40 On Tuesday, September 17, 2013 2:14:20 AM UTC-7, Joachim De Beule wrote: Dear Brian, Thanks for your reply. I tried to use jmap, unfortunately it fails: bash-3.2$ jmap -F -dump:file=heap.bin 58708 Attaching to process ID 58708, please wait... Debugger attached successfully. Server compiler detected. JVM version is 20.51-b01-457 Dumping heap to heap.bin ... Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.tools.jmap.JMap.runTool(JMap.java:179) at sun.tools.jmap.JMap.main(JMap.java:110) Caused by: sun.jvm.hotspot.oops.UnknownOopException As for visualvm: it never seems to finish producing a heap dump :( Joachim. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Hotspot predictability
For larger patterns, the staged version is actually significantly faster: https://gist.github.com/jamii/6597235 On 17 September 2013 16:29, Jamie Brandon ja...@scattered-thoughts.net wrote: I ran a little benchmark comparing different implementations of a toy pattern matching protocol: https://gist.github.com/jamii/6595850 I'm surprised to find that the staged version is not significantly slower than the compiled version. Now I'm wondering whether this is feasible on a larger scale. Can I always rely on those fns being inlined? Is there some magic threshold on closure nesting where suddenly there will be inlining and I will blow up my stack? More generally, how can I find out this sort of thing? There seems to be very little hard information on what optimisations hotspot will reliably perform. This looks like it could be useful - http://mechanical-sympathy.blogspot.co.uk/2013/06/printing-generated-assembly-code-from.html - but I'm not sure how I would make that work with clojures class name mangling for closures. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Building Trees
I thought last night I had not stated the exact root problem, so I'm glad you brought it up. It is an underlying assumption with my co-workers, but out of that context it is important to state it explicitly. The issue is perplexity http://en.wikipedia.org/wiki/Perplexity. The tree is built root to leaf. Along that path it produces, with big data sets, enormous perplexity. So the problem is when you know what you want, using the tree reveals an interesting consequence of it's construction. You can start at the root and find any node you want. However, you don't know where they are and you must navigate at times many, many branches. In fact you can't know you've found all of your data until you scanned the entire tree. Since the tree for even the most modest use case is going to have a very high perplexity this really isn't an option. However if you know where the data is within the tree and the information you want is the path to the root and that path has a perplexity of 0, the obvious answer is to have a tree that you can index into and get what you need. yesterday i finally solved the problem without mutability and without getting terribly fancy. One of my issues in going from OO to FP has been abstraction. What is wonderful and awful at the same time with OO is heavy abstraction. FP is much less abstract and transcendental. I replaced pointers with array positions and created structures in a set of arrays that allow me to find what I want and backtrack following a simple functional process. I am actually doing the implementation today. I think the proof of concept will probably end up being at most 2 printed pages of functions when I am done. Once that is working I'll be able to construct a Datomic built version of the algorithm and I think that is where it will become capable of working on any dataset. ^^^ High perplexity ^^^ Low perplexity :-) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: another game of exploding heap, via clojure.string/split
Some of the hits point at commercial tools, which you didn't mention. I've heard positive comments about YourKit in the past. It is commercial, but it looks pretty easy to get a 15-day evaluation license. I haven't used it, but it claims to have some features to aid in detecting and analyzing memory leaks: http://www.yourkit.com/docs/80/help/memory_leaks.jsp I also saw hits for a tool called plumbr. I have no information about it, good or bad. Andy On Tue, Sep 17, 2013 at 8:45 AM, Brian Craft craft.br...@gmail.com wrote: I did, of course, spend a lot of time with google before posting. All of the hits point to jconsole, jmap, and visualvm. None of these tools work reliably. They hang, they crash, they spit up errors, they generate useless results. You'll note in another thread this morning another developer having jmap and visualvm barf on them. It's not an isolated incident. On Tuesday, September 17, 2013 8:21:14 AM UTC-7, Andy Fingerhut wrote: Another possibility: The people who know aren't reading this thread. I'd tell you if I knew, but I haven't needed to track down a problem like this for several years, and forgotten whatever tool I used at the time (it was probably jmap). Suggestion: Google search java memory leak and see what tools and techniques people suggest in articles they write on the topic. Andy On Tue, Sep 17, 2013 at 8:07 AM, Brian Craft craft...@gmail.com wrote: On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote: On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut andy.fi...@gmail.comwrote: I have just added some discussion of this on ClojureDocs.org for the function clojure.core/subs, and references to that discussion for several other Clojure functions that I am pretty sure are affected, e.g. re-find, re-seq, re-matches, clojure.string/split, replace, replace-first We know with certainty that clojure.string/split is affected. Also, the OP's question about how to use tooling to track down similar leaks in the future does not appear to have been satisfactorily answered as of yet. cricket, cricket, cricket... ;) Is there really no working tooling for the jvm? The string thing bothers me less than the problem of seq heads. It is ridiculously easy to create a memory leak with a seq, and desperately hard to track one down. I would be surprised if most clojure apps were not leaking memory somewhere, in places that go unnoticed until a sufficiently large input fills the heap. I wonder if a static analysis approach could identify code that appears to retain a seq head to no effect. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Reading namespaced keywords
Hey, You have too many colons: user= (read-string :l/test) :l/test Dave On Tue, Sep 17, 2013 at 4:03 PM, Casper Clausen casp...@gmail.com wrote: I am reading a bunch of clojure files using the build-in reader (or tools.reader, it has the same problem) and I am running into a problem regarding namespaced keywords (is that the right term?) such as ::l/test. = (read-string ::l/test) RuntimeException Invalid token: ::l/test clojure.lang.Util.runtimeException (Util.java:219) It seems that the reader requires the namespace alias 'l' to exist. This is a shame because in most (all?) other respects the reader is able to just read in the symbols even if their namespace is not loaded. So in order for me to read a file with a namespaced keyword I need to eval at least the ns form of the file, which then requires me to eval the ns forms of its dependencies (and so on). My code is basically building on the excellent codeq analyzer ( https://github.com/Datomic/codeq/blob/master/src/datomic/codeq/analyzers/clj.clj), so I am guessing this would have the same problem when running into a similar namespaced keyword. So my question is how do I best get around this? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Reading namespaced keywords
I am reading a bunch of clojure files using the build-in reader (or tools.reader, it has the same problem) and I am running into a problem regarding namespaced keywords (is that the right term?) such as ::l/test. = (read-string ::l/test) RuntimeException Invalid token: ::l/test clojure.lang.Util.runtimeException (Util.java:219) It seems that the reader requires the namespace alias 'l' to exist. This is a shame because in most (all?) other respects the reader is able to just read in the symbols even if their namespace is not loaded. So in order for me to read a file with a namespaced keyword I need to eval at least the ns form of the file, which then requires me to eval the ns forms of its dependencies (and so on). My code is basically building on the excellent codeq analyzer (https://github.com/Datomic/codeq/blob/master/src/datomic/codeq/analyzers/clj.clj), so I am guessing this would have the same problem when running into a similar namespaced keyword. So my question is how do I best get around this? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Clojure BBM Channel
For those using the beta version of BBM Channels, I have created a new channel all about clojure. Below is the barcode with which to join. Cheers, Josh https://lh6.googleusercontent.com/-H6C_EUGNYeY/UjjUeCqdhKI/BmU/XTIuDfhWqqU/s1600/IMG_0171_edit.png -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Reading namespaced keywords
The double colon keyword creates a namespaced keyword and is perfectly valid syntax. It's just not used that often :) By default a keyword like ::test resolves to the current namespace like ::current-ns/test, but you can also provide another ns which causes the problem when reading. Have at look at https://github.com/clojure/core.logic/blob/0d1d545f0a81c585c7449aecb5d661120f3da568/src/main/clojure/clojure/core/logic/fd.clj for instance. On Wednesday, September 18, 2013 1:05:01 AM UTC+2, daveray wrote: Hey, You have too many colons: user= (read-string :l/test) :l/test Dave On Tue, Sep 17, 2013 at 4:03 PM, Casper Clausen cas...@gmail.comjavascript: wrote: I am reading a bunch of clojure files using the build-in reader (or tools.reader, it has the same problem) and I am running into a problem regarding namespaced keywords (is that the right term?) such as ::l/test. = (read-string ::l/test) RuntimeException Invalid token: ::l/test clojure.lang.Util.runtimeException (Util.java:219) It seems that the reader requires the namespace alias 'l' to exist. This is a shame because in most (all?) other respects the reader is able to just read in the symbols even if their namespace is not loaded. So in order for me to read a file with a namespaced keyword I need to eval at least the ns form of the file, which then requires me to eval the ns forms of its dependencies (and so on). My code is basically building on the excellent codeq analyzer ( https://github.com/Datomic/codeq/blob/master/src/datomic/codeq/analyzers/clj.clj), so I am guessing this would have the same problem when running into a similar namespaced keyword. So my question is how do I best get around this? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Reading namespaced keywords
A namespace-qualified keyword has a single colon: :my-namespace/something The double-colon is only shorthand for the current namespace: (in-ns 'my-namespace) ::something - :my-namespace/something Dave On Tue, Sep 17, 2013 at 4:58 PM, Casper Clausen casp...@gmail.com wrote: The double colon keyword creates a namespaced keyword and is perfectly valid syntax. It's just not used that often :) By default a keyword like ::test resolves to the current namespace like ::current-ns/test, but you can also provide another ns which causes the problem when reading. Have at look at https://github.com/clojure/core.logic/blob/0d1d545f0a81c585c7449aecb5d661120f3da568/src/main/clojure/clojure/core/logic/fd.cljfor instance. On Wednesday, September 18, 2013 1:05:01 AM UTC+2, daveray wrote: Hey, You have too many colons: user= (read-string :l/test) :l/test Dave On Tue, Sep 17, 2013 at 4:03 PM, Casper Clausen cas...@gmail.com wrote: I am reading a bunch of clojure files using the build-in reader (or tools.reader, it has the same problem) and I am running into a problem regarding namespaced keywords (is that the right term?) such as ::l/test. = (read-string ::l/test) RuntimeException Invalid token: ::l/test clojure.lang.Util.**runtimeException (Util.java:219) It seems that the reader requires the namespace alias 'l' to exist. This is a shame because in most (all?) other respects the reader is able to just read in the symbols even if their namespace is not loaded. So in order for me to read a file with a namespaced keyword I need to eval at least the ns form of the file, which then requires me to eval the ns forms of its dependencies (and so on). My code is basically building on the excellent codeq analyzer (https://github.com/Datomic/** codeq/blob/master/src/datomic/**codeq/analyzers/clj.cljhttps://github.com/Datomic/codeq/blob/master/src/datomic/codeq/analyzers/clj.clj), so I am guessing this would have the same problem when running into a similar namespaced keyword. So my question is how do I best get around this? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clojure-sql 0.1.0: relational algebra in clojure
On Tue, Sep 17, 2013 at 02:28:08AM -0700, Daniel Neal wrote: I'd be interested in knowing some more about your approach compared to that of ClojureQL and the motivation behind it. Sure! The basic difference is that I tried to be a little bit more rigid in how queries must be constructed. I tried to ensure that the generated queries weren't just valid SQL, but that they were also sensible and unambiguous (or, if there isn't enough information to make a sensible, unambiguous, query, that it throws an exception). As an example, in ClojureQL you can create the following query, which will compile into a query without any issue: (join (table :users) (table :people) (where (= :uid :pid))) but the result of this query (or even the structure of the result) is difficult to determine by examining the code. Even worse, because the :uid and :pid aren't from either table explicitly, this could fail on the database if both tables have a :uid or :pid field. The equivalent query in clojure-sql, (join (table :users) (table :people) :on `(= :uid :pid)) will fail, telling you there's an ambiguous field :uid in the query. If you disambiguate :uid (by projecting :uid in either of the tables) then it will complain about :pid. My ideal is that you could treat a query as some opaque object about which you can only know two things: the shape of the data it specifies, and (after executing the query) the data that it specifies. You should then be able to arbitrarily apply clojure-sql functions to those queries to produce new opaque queries without any concern about how the subqueries were produced (with each of the functions causing a known, predictable, effect on the execution result). At the moment this should be true of all the relational operators (project/select/rename/join), the set operations (union/intersection) and some other operations (take/drop/sort) but it's not true of the grouping operations (group/having). Carlo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Reading namespaced keywords
Casper, in the example source file you pointed at in the core.logic test
suite, the only times it uses the ::namespace/symbol syntax is where
namespace is an alias for a namespace that has been created by an earlier
:require statement.
In my limited testing in Clojure 1.5.1, that syntax throws an exception if
namespace is an existing namespace, or an alias for one, but throws an
exception if it is not an existing namespace.
So in a plain vanilla Clojure 1.5.1 REPL, this works because there is a
namespace clojure.set:
user= (def s1 #{::clojure.set/foo})
#'user/s1
user= s1
#{:clojure.set/foo}
but this doesn't work, because there is no namespace clojure.foo:
user= (def s2 #{::clojure.foo/bar})
RuntimeException Invalid token: ::clojure.foo/bar
clojure.lang.Util.runtimeException (Util.java:219)
RuntimeException Unmatched delimiter: } clojure.lang.Util.runtimeException
(Util.java:219)
RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException
(Util.java:219)
I do not know if David Nolen is using a supported feature here or an
accident of the Clojure 1.5.1 implementation.
Andy
On Tue, Sep 17, 2013 at 5:01 PM, Dave Ray dave...@gmail.com wrote:
A namespace-qualified keyword has a single colon:
:my-namespace/something
The double-colon is only shorthand for the current namespace:
(in-ns 'my-namespace)
::something - :my-namespace/something
Dave
On Tue, Sep 17, 2013 at 4:58 PM, Casper Clausen casp...@gmail.com wrote:
The double colon keyword creates a namespaced keyword and is perfectly
valid syntax. It's just not used that often :)
By default a keyword like ::test resolves to the current namespace like
::current-ns/test, but you can also provide another ns which causes the
problem when reading.
Have at look at
https://github.com/clojure/core.logic/blob/0d1d545f0a81c585c7449aecb5d661120f3da568/src/main/clojure/clojure/core/logic/fd.cljfor
instance.
On Wednesday, September 18, 2013 1:05:01 AM UTC+2, daveray wrote:
Hey,
You have too many colons:
user= (read-string :l/test)
:l/test
Dave
On Tue, Sep 17, 2013 at 4:03 PM, Casper Clausen cas...@gmail.comwrote:
I am reading a bunch of clojure files using the build-in reader (or
tools.reader, it has the same problem) and I am running into a problem
regarding namespaced keywords (is that the right term?) such as ::l/test.
= (read-string ::l/test)
RuntimeException Invalid token: ::l/test
clojure.lang.Util.**runtimeException
(Util.java:219)
It seems that the reader requires the namespace alias 'l' to exist.
This is a shame because in most (all?) other respects the reader is able to
just read in the symbols even if their namespace is not loaded. So in order
for me to read a file with a namespaced keyword I need to eval at least the
ns form of the file, which then requires me to eval the ns forms of its
dependencies (and so on). My code is basically building on the excellent
codeq analyzer (https://github.com/Datomic/**
codeq/blob/master/src/datomic/**codeq/analyzers/clj.cljhttps://github.com/Datomic/codeq/blob/master/src/datomic/codeq/analyzers/clj.clj),
so I am guessing this would have the same problem when running into a
similar namespaced keyword.
So my question is how do I best get around this?
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@**googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@**googlegroups.com.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated -
Re: Reading namespaced keywords
It is used in test.generative code by Stuart Halloway, which is probably
about as supported as you can get:
https://github.com/clojure/test.generative/blob/master/src/main/clojure/clojure/test/generative/runner.clj#L55
Andy
On Tue, Sep 17, 2013 at 5:16 PM, Andy Fingerhut andy.finger...@gmail.comwrote:
Casper, in the example source file you pointed at in the core.logic test
suite, the only times it uses the ::namespace/symbol syntax is where
namespace is an alias for a namespace that has been created by an earlier
:require statement.
In my limited testing in Clojure 1.5.1, that syntax throws an exception if
namespace is an existing namespace, or an alias for one, but throws an
exception if it is not an existing namespace.
So in a plain vanilla Clojure 1.5.1 REPL, this works because there is a
namespace clojure.set:
user= (def s1 #{::clojure.set/foo})
#'user/s1
user= s1
#{:clojure.set/foo}
but this doesn't work, because there is no namespace clojure.foo:
user= (def s2 #{::clojure.foo/bar})
RuntimeException Invalid token: ::clojure.foo/bar
clojure.lang.Util.runtimeException (Util.java:219)
RuntimeException Unmatched delimiter: }
clojure.lang.Util.runtimeException (Util.java:219)
RuntimeException Unmatched delimiter: )
clojure.lang.Util.runtimeException (Util.java:219)
I do not know if David Nolen is using a supported feature here or an
accident of the Clojure 1.5.1 implementation.
Andy
On Tue, Sep 17, 2013 at 5:01 PM, Dave Ray dave...@gmail.com wrote:
A namespace-qualified keyword has a single colon:
:my-namespace/something
The double-colon is only shorthand for the current namespace:
(in-ns 'my-namespace)
::something - :my-namespace/something
Dave
On Tue, Sep 17, 2013 at 4:58 PM, Casper Clausen casp...@gmail.comwrote:
The double colon keyword creates a namespaced keyword and is perfectly
valid syntax. It's just not used that often :)
By default a keyword like ::test resolves to the current namespace like
::current-ns/test, but you can also provide another ns which causes the
problem when reading.
Have at look at
https://github.com/clojure/core.logic/blob/0d1d545f0a81c585c7449aecb5d661120f3da568/src/main/clojure/clojure/core/logic/fd.cljfor
instance.
On Wednesday, September 18, 2013 1:05:01 AM UTC+2, daveray wrote:
Hey,
You have too many colons:
user= (read-string :l/test)
:l/test
Dave
On Tue, Sep 17, 2013 at 4:03 PM, Casper Clausen cas...@gmail.comwrote:
I am reading a bunch of clojure files using the build-in reader (or
tools.reader, it has the same problem) and I am running into a problem
regarding namespaced keywords (is that the right term?) such as ::l/test.
= (read-string ::l/test)
RuntimeException Invalid token: ::l/test
clojure.lang.Util.**runtimeException
(Util.java:219)
It seems that the reader requires the namespace alias 'l' to exist.
This is a shame because in most (all?) other respects the reader is able
to
just read in the symbols even if their namespace is not loaded. So in
order
for me to read a file with a namespaced keyword I need to eval at least
the
ns form of the file, which then requires me to eval the ns forms of its
dependencies (and so on). My code is basically building on the excellent
codeq analyzer (https://github.com/Datomic/**
codeq/blob/master/src/datomic/**codeq/analyzers/clj.cljhttps://github.com/Datomic/codeq/blob/master/src/datomic/codeq/analyzers/clj.clj),
so I am guessing this would have the same problem when running into a
similar namespaced keyword.
So my question is how do I best get around this?
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+u...@**googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@**googlegroups.com.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
--
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
Re: Reading namespaced keywords
The double-colon is only shorthand for the current namespace: Or other namespaces via an alias: (alias 'clj 'clojure.core) ::clj/foo = :clojure.core/foo Inside ns forms, the :as keyword creates aliases. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Reading namespaced keywords
Cool. You learn something new every day :)
On Tuesday, September 17, 2013, Brandon Bloom wrote:
The double-colon is only shorthand for the current namespace:
Or other namespaces via an alias:
(alias 'clj 'clojure.core)
::clj/foo = :clojure.core/foo
Inside ns forms, the :as keyword creates aliases.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clojure@googlegroups.comjavascript:_e({}, 'cvml',
'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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@googlegroups.com');.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, floats, ints and OpenGL
Hi Christophe, Looks like a good patch to me - would you be able to submit it to JIRA? I already submitted an issue to add primitive support for statically compiled functions (http://dev.clojure.org/jira/browse/CLJ-1263) which I think would complement yours nicely. The combination of the two should give float support that is comparable to Java in most cases. On Tuesday, 17 September 2013 19:25:04 UTC+8, Christophe Grand wrote: Here is the mundane patch I described earlier: https://github.com/cgrand/clojure/commit/4c202ad9757ce47ac9e669847c0e5bf68785e2d6 It adds four functions (add-, multiply-, divide- and subtract-float), backs them with their corresponding bytecodes and enhance the conversion emitted when going from long/int to double/float. Please give it a try. It doesn't help with functions taking primitive but it's another problem. Christophe On Mon, Sep 16, 2013 at 7:03 PM, James Reeves ja...@booleanknot.comjavascript: wrote: On 16 September 2013 09:03, Mikera mike.r.an...@gmail.com javascript:wrote: Obviously this is just a microbenchmark, but it fits my general experience that floats are a reasonable bit faster than doubles, typically 20-100% (doubles are closer when it is pure number crunching since 64-bit CPUs are actually pretty good at doubles, floats have a bigger advantage when you are manipulating a lot of data points and hence memory bandwidth matters more) Code here for those interested: src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java That's a pretty interesting result. I ran some tests of my own, based on your code, as I wondered whether or not the time to instantiate the array of doubles was biasing the test. My goal was to see whether or not I'd get a similar result running an array of floats through a method that processed doubles. (See: https://gist.github.com/weavejester/6583367) It turns out that I get a similar result. Passing floats to a method that takes doubles slows things down by a similar amount, unless I've somehow botched up the test. Considering that converting between single and double precision should be pretty cheap on the CPU, I'm surprised at the difference. This somewhat changes my view on things. It doesn't affect me in practice, but I can see how someone might be frustrated by having to drop down to Java to achieve performance for floating point calculations. - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting Contracting http://lambdanext.eu/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] mod-lang-clojure for Vert.x 0.2.0 released
mod-lang-clojure[0] 0.2.0 was released earlier today, and is now available in Maven Central. The biggest change in 0.2.0 is the addition of a ClojureScript wrapper around the client-side vertxbus.js.[1] For a full list of changes, see the ChangeLog[2]. # What is mod-lang-clojure? mod-lang-clojure is a fledging Clojure language module for Vert.x[3]. Vert.x is an asynchronous polyglot application platform based on Netty. [0]: https://github.com/vert-x/mod-lang-clojure/ [1]: https://github.com/vert-x/mod-lang-clojure/blob/0.2.0/api/src/main/clojure/vertx/client/eventbus.cljs [2]: https://github.com/vert-x/mod-lang-clojure/blob/master/ChangeLog.md [3]: http://vertx.io/ -- Toby Crawley http://immutant.org | http://torquebox.org -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] clojure.java.jdbc 0.3.0-alpha5 available on Maven Central
Clojure JDBC contrib library takes another step toward an 0.3.0 with a fifth alpha release! Release 0.3.0-alpha5 on 2013-09-15 * DDL now supports entities naming strategy JDBC-53. * Attempt to address potential memory leaks due to closures - see Christophe Grand's blog post on Macros, closures and unexpected object retention. * Documentation has moved to Using java.jdbc on Clojure-Doc.org * Added Leiningen support for easier development/testing (Maven is still the primary build tool). * Added create-index / drop-index DDL JDBC-62 - moquist * Make transaction? boolean optional in various db-do-* functions * Create clojure.java.jdbc.ddl namespace * Add create-table, drop-table, create-index and drop-index * Deprecate create-table, create-table-ddl and drop-table in main namespace * Update README to clarify PostgreSQL instructions. * Fix test suite for PostgreSQL JDBC-59 * Improve hooks for Oracle data type handling JDBC-57 * Fix reflection warnings JDBC-55 What's next? Beta1 of course! I'm still considering whether to add support for multiple result sets and to expose the raw ResultSet object(s) for 0.3.0 - or punt on them. If those go into 0.3.0, beta1 will include them :) Everything else on the table will be considered for a later release. 0.3.0 deprecates nearly all of the old API. Input welcome on how long y'all think we need to keep the deprecated API around. It'll definitely go away before 1.0.0 :) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Hotspot predictability
I've found similar things with compiling schema validators. Be careful with doseq benchmarks like this though, if you aren't careful hotspot can completely eliminate parts of the computation as dead code if it can infer the results aren't used. Criterion has a neat trick for making sure this can't happen, IIRC. On Tuesday, September 17, 2013 10:00:46 AM UTC-7, Jamie Brandon wrote: For larger patterns, the staged version is actually significantly faster: https://gist.github.com/jamii/6597235 On 17 September 2013 16:29, Jamie Brandon ja...@scattered-thoughts.netjavascript: wrote: I ran a little benchmark comparing different implementations of a toy pattern matching protocol: https://gist.github.com/jamii/6595850 I'm surprised to find that the staged version is not significantly slower than the compiled version. Now I'm wondering whether this is feasible on a larger scale. Can I always rely on those fns being inlined? Is there some magic threshold on closure nesting where suddenly there will be inlining and I will blow up my stack? More generally, how can I find out this sort of thing? There seems to be very little hard information on what optimisations hotspot will reliably perform. This looks like it could be useful - http://mechanical-sympathy.blogspot.co.uk/2013/06/printing-generated-assembly-code-from.html - but I'm not sure how I would make that work with clojures class name mangling for closures. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
