Re: How does ! order results from async?
The go block itself (and thus any call to walker) returns a channel. This value is indeed thrown away; its utility lies entirely in the fact that the caller had to wait for it. All of the actual values from the tree are written to the supplied channel 'ch', and the ultimate caller of this function will have to take them from there. I am stupid and recursion is clearly beyond my intellect. Martin Trojer has a great blog post here which I learned a lot from but I don't understand why the final example works: http://martintrojer.github.io/clojure/2013/07/17/non-tailrecursive-functions-in-coreasync/ He offers this as an example of recursively walking a binary search tree: (defn walk [tree ch] (letfn [(walker [t] (go (when t (walker (:left t)) (! ch (:value t)) (walker (:right t)] (go (! (walker tree)) (close! ch and then he writes: This looks promising, but the results in the channel can be in any order (since there are no order guarantees in the scheduling of go processes) – this also means that some of the values might be missing since the “top” go process can be scheduled before a child one. We need a little bit more synchronisation to arrive at a working solution. and then offers this as the final working example: (defn walk [tree ch] (letfn [(walker [t] (go (when t (! (walker (:left t))) (! ch (:value t)) (! (walker (:right t))] (go (! (walker tree)) (close! ch I am confused what this line does: (! (walker (:left t))) It looks like we are pulling a value off channel that's returned from that call to walker? But why? We seem to be throwing this value away? I don't see it being stored anywhere. How does this give us synchronization? -- -- 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: How does ! order results from async?
For this value please read the value taken from this channel. On Sep 14, 2013 12:21 AM, Alan Shaw noden...@gmail.com wrote: The go block itself (and thus any call to walker) returns a channel. This value is indeed thrown away; its utility lies entirely in the fact that the caller had to wait for it. All of the actual values from the tree are written to the supplied channel 'ch', and the ultimate caller of this function will have to take them from there. I am stupid and recursion is clearly beyond my intellect. Martin Trojer has a great blog post here which I learned a lot from but I don't understand why the final example works: http://martintrojer.github.io/clojure/2013/07/17/non-tailrecursive-functions-in-coreasync/ He offers this as an example of recursively walking a binary search tree: (defn walk [tree ch] (letfn [(walker [t] (go (when t (walker (:left t)) (! ch (:value t)) (walker (:right t)] (go (! (walker tree)) (close! ch and then he writes: This looks promising, but the results in the channel can be in any order (since there are no order guarantees in the scheduling of go processes) – this also means that some of the values might be missing since the “top” go process can be scheduled before a child one. We need a little bit more synchronisation to arrive at a working solution. and then offers this as the final working example: (defn walk [tree ch] (letfn [(walker [t] (go (when t (! (walker (:left t))) (! ch (:value t)) (! (walker (:right t))] (go (! (walker tree)) (close! ch I am confused what this line does: (! (walker (:left t))) It looks like we are pulling a value off channel that's returned from that call to walker? But why? We seem to be throwing this value away? I don't see it being stored anywhere. How does this give us synchronization? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, floats, ints and OpenGL
Timothy, thanks,for giving a thorough answer to my questions, I appreciate this! As far as I understood, you did some work for Clojure team, and you have the necessary knowledge to express a knowing opinion on what are the implications of the matter. That was one of the things I wanted to know - the cause of the present situation. However, still I don't understand (although you mentioned a reason) why no one from the core team gives a definite, cut-off answer, like the one, Mikera is also asking for - what is for the future? Probably, as somebody mentioned here (sorry, I look and can't find the message, deleted?), the question would probably be better addressed to clojure-dev. But I have no good knowledge of Clojure internals and would be easily suppressed by an answer of a person, showing a technical knowledge, like yours. Yes, I understand what you're saying, but I do not have knowledge of Clojure or JVM to answer you on par. Simply I do not know what to say, although I feel there is a break between JVM and Clojure that should not be. And I feel, that you have a right in what you're saying - you know the language, you know the people here, more than me. But not to let a discussion on such a topic to die, here I am glad that Mikera, someone who has that knowledge, can sympathise me and say what I cannot say. James, for some numbers on OpenGL penalties, please refer to message #6 in thread (my initial answer for Timothy). You can also google on it, I am sure, you will find more information, or, why not, simply call NVIDIA or ATI support lines, and ask them. A perfectly valid question for them to consult you on :) As for more Java-friendly answers, you might also be interested in asking on LWJGL or JOGL forums. Personally I work with OpenGL for quite a long time already. Even when we were on C/C++ we never used doubles. Then we went Java, and there too, doubles are nowhere. One of the cornerstone computational workhorses of LWJGL, for example, the class Vertex3f, has no double version. And that is for a reason, not because Java bindings are bad and we must go C-plus-plusing now. Probably, after 10 years we will have only doubles and longs on GPUs... do you believe in it? Why we need them there at all? I still strongly believe that primitives support should be made one of the highest priorities to support. Lets look from a perspective of someone who researches the language, considering if to adhere to it. Here is a couple of frustrations that hit me so much that I think could even diverse somone from using the language. Warning: the following three points may cause rage in some individuals (they do cause a rage in me at least, because I really like Clojure) : 1) Clojure is said to be data-oriented. Rich Hickey says that in the videos. Cool! I have a stream of millions floats and ints to be processed on the fly! Now we find that it is not data-oriented. It is double, long and Object oriented. Data does not just come as information it comes with its data-type. Bending data-sources and data-consumers to your will usually does not sign a good data-processing. 2) Clojure is said to make simple things easy. Alright, that's a PC in front of me? With a JVM? Alright, I want to add,multiply, divide and subtract some billion floats. What could be simpler?... Uh... typehints.. alright, sure JVM is typed, we have types in Java and Scala, that's ok! Oh, only local... oh, still always returns doubles... err.. boxed? Cast? Oh... 3) As Mikera pointed out, some libraries, like fast arrays on Clojure is just.. a little bit too much. Are they faster than Java arrays? A library that implements fast arrays for a language that runs on a VM that has fast arrays? For a language, claimed to be perfect for data-processing? There is nothing wrong with the library, I think it is a masterpiece, but something scares me here. Surely, preserving semantics while letting full primitives support for Clojure, as it is right now, is a challenge. I really like the symantics as it is now, but the cost is too great. The examples that Timothy and Mikera are discussing right now is a problem. Some my ideas, although I am not as professional with them and some of them might not make sense at all (sorry): 1) In computations you do not often use functions that compute floats to compute ints instead. Usually you know what are you computing. I wouldn't switch, say spatial vector calculations from floats to ints under any circumstances. Remember Java - when you write signatures of your computational functions - how often do you change types? float-double or int-long maybe, but still not likely. Even on a lisp. 2) That leads to the other question - what if you *still* somehow want to reuse a computational function for other types? Well, maybe you could make functions named (+f) or (+i)? Or have a macros that builds them for you and calls them for you? 3) To simplify furhter: can a
Re: Clojure, floats, ints and OpenGL
7) Maybe genclass and stuff can still get away as it is now, falling back to boxing and reduced number of types? Or special genclass metadata hints be introduced? Still, not everyone will use that. But those who will, could spare a couple more hints to the compiler.. -- -- 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.
A library function for the repeated application of a lambda with values from a sequence
Hello, Consider the following problem: (def v [1 2 3]) (def l '(4 5 6)) ; we need to apply in sequence ; `v - (func v e)`, ; where `e` goes over elements of the list `l` (def new-v (apply-from-list func v l)) For example, if `(def func conj)`, then the value of `new-v` is `[1 2 3 4 5 6]`. Is there some function (or a simple combination of functions) from the standard library that does that? It seems to me that it could be done with something like `-`, but a function, not a macro. At the moment I have the following ugly implementation: (defn apply-from-list [init-res func init-l] (if (empty? init-l) init-res (loop [res init-res l init-l] (let [first-elem (first l) rest-elems (rest l) res (func res first-elem)] (if (empty? rest-elems) res (recur res rest-elems)) -- -- 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: A library function for the repeated application of a lambda with values from a sequence
Why not just (reduce func v l)? On Sat, Sep 14, 2013 at 8:12 AM, Bogdan Opanchuk manti...@gmail.com wrote: Hello, Consider the following problem: (def v [1 2 3]) (def l '(4 5 6)) ; we need to apply in sequence ; `v - (func v e)`, ; where `e` goes over elements of the list `l` (def new-v (apply-from-list func v l)) For example, if `(def func conj)`, then the value of `new-v` is `[1 2 3 4 5 6]`. Is there some function (or a simple combination of functions) from the standard library that does that? It seems to me that it could be done with something like `-`, but a function, not a macro. At the moment I have the following ugly implementation: (defn apply-from-list [init-res func init-l] (if (empty? init-l) init-res (loop [res init-res l init-l] (let [first-elem (first l) rest-elems (rest l) res (func res first-elem)] (if (empty? rest-elems) res (recur res rest-elems)) -- -- 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: A library function for the repeated application of a lambda with values from a sequence
Hi Cedric, Thanks, I'm feeling really silly now... I should have thought about folds the first second after encountering this :) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: another game of exploding heap, via clojure.string/split
If you're working with large text files, tsv especially, you may encounter Java's memory overhead for Strings as well. I remember parsing a 1GB TSV file into EDN, and watching it consume 10GB of RAM. I'd recommend taking a look at the Iota library to see if it would be of any help to you, https://github.com/thebusby/iota On Fri, Sep 13, 2013 at 11:47 AM, Cedric Greevey cgree...@gmail.com wrote: On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut andy.finger...@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. -- -- 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.
Source for Clojure/conj 2012 slides?
Hi, I'm just watching some videos from Clojure/conj 2012 and would like to peruse the slides, but I haven't found a download anywhere on the Internet. Does somebody here have them? Any help will be much appreciated. -- -- 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
Very interesting. Thanks. On Saturday, September 14, 2013 5:48:57 AM UTC-7, TheBusby wrote: If you're working with large text files, tsv especially, you may encounter Java's memory overhead for Strings as well. I remember parsing a 1GB TSV file into EDN, and watching it consume 10GB of RAM. I'd recommend taking a look at the Iota library to see if it would be of any help to you, https://github.com/thebusby/iota On Fri, Sep 13, 2013 at 11:47 AM, Cedric Greevey cgre...@gmail.comjavascript: 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. -- -- 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: Clojure, floats, ints and OpenGL
Excuse me, when I said Vertex3f I meant Vector3f. суббота, 14 сентября 2013 г., 15:14:01 UTC+4 пользователь Alex Fowler написал: Timothy, thanks,for giving a thorough answer to my questions, I appreciate this! As far as I understood, you did some work for Clojure team, and you have the necessary knowledge to express a knowing opinion on what are the implications of the matter. That was one of the things I wanted to know - the cause of the present situation. However, still I don't understand (although you mentioned a reason) why no one from the core team gives a definite, cut-off answer, like the one, Mikera is also asking for - what is for the future? Probably, as somebody mentioned here (sorry, I look and can't find the message, deleted?), the question would probably be better addressed to clojure-dev. But I have no good knowledge of Clojure internals and would be easily suppressed by an answer of a person, showing a technical knowledge, like yours. Yes, I understand what you're saying, but I do not have knowledge of Clojure or JVM to answer you on par. Simply I do not know what to say, although I feel there is a break between JVM and Clojure that should not be. And I feel, that you have a right in what you're saying - you know the language, you know the people here, more than me. But not to let a discussion on such a topic to die, here I am glad that Mikera, someone who has that knowledge, can sympathise me and say what I cannot say. James, for some numbers on OpenGL penalties, please refer to message #6 in thread (my initial answer for Timothy). You can also google on it, I am sure, you will find more information, or, why not, simply call NVIDIA or ATI support lines, and ask them. A perfectly valid question for them to consult you on :) As for more Java-friendly answers, you might also be interested in asking on LWJGL or JOGL forums. Personally I work with OpenGL for quite a long time already. Even when we were on C/C++ we never used doubles. Then we went Java, and there too, doubles are nowhere. One of the cornerstone computational workhorses of LWJGL, for example, the class Vertex3f, has no double version. And that is for a reason, not because Java bindings are bad and we must go C-plus-plusing now. Probably, after 10 years we will have only doubles and longs on GPUs... do you believe in it? Why we need them there at all? I still strongly believe that primitives support should be made one of the highest priorities to support. Lets look from a perspective of someone who researches the language, considering if to adhere to it. Here is a couple of frustrations that hit me so much that I think could even diverse somone from using the language. Warning: the following three points may cause rage in some individuals (they do cause a rage in me at least, because I really like Clojure) : 1) Clojure is said to be data-oriented. Rich Hickey says that in the videos. Cool! I have a stream of millions floats and ints to be processed on the fly! Now we find that it is not data-oriented. It is double, long and Object oriented. Data does not just come as information it comes with its data-type. Bending data-sources and data-consumers to your will usually does not sign a good data-processing. 2) Clojure is said to make simple things easy. Alright, that's a PC in front of me? With a JVM? Alright, I want to add,multiply, divide and subtract some billion floats. What could be simpler?... Uh... typehints.. alright, sure JVM is typed, we have types in Java and Scala, that's ok! Oh, only local... oh, still always returns doubles... err.. boxed? Cast? Oh... 3) As Mikera pointed out, some libraries, like fast arrays on Clojure is just.. a little bit too much. Are they faster than Java arrays? A library that implements fast arrays for a language that runs on a VM that has fast arrays? For a language, claimed to be perfect for data-processing? There is nothing wrong with the library, I think it is a masterpiece, but something scares me here. Surely, preserving semantics while letting full primitives support for Clojure, as it is right now, is a challenge. I really like the symantics as it is now, but the cost is too great. The examples that Timothy and Mikera are discussing right now is a problem. Some my ideas, although I am not as professional with them and some of them might not make sense at all (sorry): 1) In computations you do not often use functions that compute floats to compute ints instead. Usually you know what are you computing. I wouldn't switch, say spatial vector calculations from floats to ints under any circumstances. Remember Java - when you write signatures of your computational functions - how often do you change types? float-double or int-long maybe, but still not likely. Even on a lisp. 2) That leads to the other question - what if you *still* somehow want to reuse
Re: Clojure, floats, ints and OpenGL
1) Clojure is said to be data-oriented. Well it is, it's just that your definition of data is radically different from the normal business use case. In the line of work I'm in, big data is millions of hash maps filled with heterogeneous data types. In these cases, Clojure really shines. 2) Clojure is said to make simple things easy. That's a tad debatable. I would say that Clojure simplifies your code, therefore allowing for easier reasoning about that code. One of the ways it accomplishes this by being a dynamic language. And that right there hits on the main reason you're experiencing problems. This simplicity doesn't come without a cost. There are many trade-offs Clojure makes. Immutable data-structures are fast, but not as fast as mutable structures. Clojure allows for REPL based development at the cost of requiring that every function must go through a var deref. This cost is low (very low thanks to the JVM), but it still exists. And we see this cost when it comes to primitives. In languages like Scala and Java you know exactly what functions every function will call, and so you can link it to the exact overload needed for the primitives in use. However, in Clojure, at any moment a def (var) could be changed at the REPL, and we have to pick that up without problems. In return you have the ability to program without having to re-compile at every step. The same thing applies with type hinting in general. No other dynamic language offers the performance of Clojure. Python is used heavily by the scientific community, and yet it boxes everything. It doesn't support floats, let alone unboxing. So Clojure really should be viewed as a super fast dynamic language, not as a slow Scala/Java clone. I think this is clearly exemplified by Fressian ( https://github.com/Datomic/fressian), this is the serialization library used by Datomic (also written by Rich Hickey). Notice something interesting about this codebase. It almost 100% java (except for the tests, those are in Clojure). Why? Because serialization libraries need to be lean, fast, and are mostly side-effecting, this is a use case Java excels at. Now I've never seen the inner workings of Datomic, but I've heard it said the database is written in Clojure. So that's interesting...it's a set of Java libraries (for performance) glued together and controlled by Clojure (for simplicity). When Clojure people talk about simplicity what we're really railing against is the complexity of orchestrating large projects using a OOP language like Java. Write your data processing routines as static java members that take float arrays and emit float arrays and you're going to do quite well. One other thing you touched on is the idea that no one has given you a straight answer on this yet. And I think this comes down to several things: a) No one wants to speak for Rich. When it comes down to it, Clojure is his baby, so no one but him has the authority to say this is a focus for version X. He doesn't hang out on the mailing lists a whole lot, so perhaps an email to him might do well, or even to clojure-dev. b) No one has a clue on how to implement this without changing Clojure semantics. And changing the semantics of a language just to support a single use case is one of the best ways to get your patch rejected by Rich. :-) c) I want to make this point as carefully as possible...there's little incentive for anyone (including Rich) to implement this. If you came to me an said Tim...we want to pay double your current salary for the next year and have you re-write the Clojure compiler from scratch to support these features, I might actually do that. But sadly, I have a day job, and making massive changes to the Clojure compiler is not something I plan on spending my time on this year. Perhaps at some point a corporation will offer paid support for Clojure and then things like this can be possible. As the saying goes, money talks. Offer enough money and people will get more motivated to help. I know this point isn't very nice to hear from the OSS world, but the sad fact of it is, you seem to have a unique use case, and until the people with the knowledge of the system have the need of that same use case, nothing is going to happen. That being said, if someone hired me to write a video editor (as I've done some work in that area in the past), I'd probably write it in either C (for SSE support), CUDA/OpenCL, or perhaps bare Java, and once again, I'd glue my library together with Clojure code. Writing the image processing code for 4K video at 48fps in a dynamic language is a joke. Unless you're the people who write PyPy, but then again, I'm convinced that those people are mostly insane :-). So there it is, it's not going to change soon (if ever), and you probably won't get much feedback from others unless you start offering money. But once again I want to come back to something I've said a lot in this conversation: I work with Clojure a lot. If someone came to me
Re: Clojure, floats, ints and OpenGL
On 14 September 2013 12:14, Alex Fowler alex.murat...@gmail.com wrote: Timothy, thanks,for giving a thorough answer to my questions, I appreciate this! As far as I understood, you did some work for Clojure team, and you have the necessary knowledge to express a knowing opinion on what are the implications of the matter. James, for some numbers on OpenGL penalties, please refer to message #6 in thread (my initial answer for Timothy). You can also google on it, I am sure, you will find more information, or, why not, simply call NVIDIA or ATI support lines, and ask them. A perfectly valid question for them to consult you on :) As for more Java-friendly answers, you might also be interested in asking on LWJGL or JOGL forums. Personally I work with OpenGL for quite a long time already. Even when we were on C/C++ we never used doubles. Then we went Java, and there too, doubles are nowhere. One of the cornerstone computational workhorses of LWJGL, for example, the class Vertex3f, has no double version. And that is for a reason, not because Java bindings are bad and we must go C-plus-plusing now. Probably, after 10 years we will have only doubles and longs on GPUs... do you believe in it? Why we need them there at all? But presumably you've done some benchmarks that show a loss in performance? Otherwise I don't understand why you'd be arguing so passionately. I did some some benchmarks myself, but any performance loss was below the noise level of my machine. In theory, if HotSpot is doing its job, then the conversion from a double to the float is compiled down to a single machine instruction. On the i7 architecture at least, the reciprocal throughput for converting a float from double to single precision is one clock cycle. If you're pushing data to the GPU, aren't your primary performance bottlenecks going to be the latency and bandwidth of the link? I'm having difficulty seeing how a double-to-float conversion would be an significant issue. - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, floats, ints and OpenGL
+1 on all the answers from Timothy to these items Been working with Clojure for 5 years by now handling huge data loads in real time. You want to get lean and mean performance in specific areas then thunk down to Java or native libs. We never had to do from Clojure btwy, there's been always an alternate implementation in Clojure to improve speed. In the 1980s/1990s you needed perf in some critical code chunks ? You would look at the machine code issued by the compiler, tweak your code and use compiler options if possible to make these faster. Or else write assembler code to be closer to the metal and glue this code to your top level code. Been doing this on SCADA systems for a number of years with success... Some advice, use the right tool instead of trying to shift the universe by a few degrees, life is too short :) Luc P. 1) Clojure is said to be data-oriented. Well it is, it's just that your definition of data is radically different from the normal business use case. In the line of work I'm in, big data is millions of hash maps filled with heterogeneous data types. In these cases, Clojure really shines. 2) Clojure is said to make simple things easy. That's a tad debatable. I would say that Clojure simplifies your code, therefore allowing for easier reasoning about that code. One of the wa it accomplishes this by being a dynamic language. And that right there hits on the main reason you're experiencing problems. This simplicity doesn't come without a cost. There are many trade-offs Clojure makes. Immutable data-structures are fast, but not as fast as mutable structures. Clojure allows for REPL based development at the cost of requiring that every function must go through a var deref. This cost is low (very low thanks to the JVM), but it still exists. And we see this cost when it comes to primitives. In languages like Scala and Java you know exactly what functions every function will call, and so you can link it to the exact overload needed for the primitives in use. However, in Clojure, at any moment a def (var) could be changed at the REPL, and we have to pick that up without problems. In return you have the ability to program without having to re-compile at every step. The same thing applies with type hinting in general. No other dynamic language offers the performance of Clojure. Python is used heavily by the scientific community, and yet it boxes everything. It doesn't support floats, let alone unboxing. So Clojure really should be viewed as a super fast dynamic language, not as a slow Scala/Java clone. I think this is clearly exemplified by Fressian ( https://github.com/Datomic/fressian), this is the serialization library used by Datomic (also written by Rich Hickey). Notice something interesting about this codebase. It almost 100% java (except for the tests, those are in Clojure). Why? Because serialization libraries need to be lean, fast, and are mostly side-effecting, this is a use case Java excels at. Now I've never seen the inner workings of Datomic, but I've heard it said the database is written in Clojure. So that's interesting...it's a set of Java libraries (for performance) glued together and controlled by Clojure (for simplicity). When Clojure people talk about simplicity what we're really railing against is the complexity of orchestrating large projects using a OOP language like Java. Write your data processing routines as static java members that take float arrays and emit float arrays and you're going to do quite well. One other thing you touched on is the idea that no one has given you a straight answer on this yet. And I think this comes down to several things: a) No one wants to speak for Rich. When it comes down to it, Clojure is his baby, so no one but him has the authority to say this is a focus for version X. He doesn't hang out on the mailing lists a whole lot, so perhaps an email to him might do well, or even to clojure-dev. b) No one has a clue on how to implement this without changing Clojure semantics. And changing the semantics of a language just to support a single use case is one of the best ways to get your patch rejected by Rich. :-) c) I want to make this point as carefully as possible...there's little incentive for anyone (including Rich) to implement this. If you came to me an said Tim...we want to pay double your current salary for the next year and have you re-write the Clojure compiler from scratch to support these features, I might actually do that. But sadly, I have a day job, and making massive changes to the Clojure compiler is not something I plan on spending my time on this year. Perhaps at some point a corporation will offer paid support for Clojure and then things like this can be possible. As the saying goes, money talks. Offer enough money and people will get more motivated to help. I know this point isn't very nice to hear from the OSS world, but the sad fact of
core.async and channel flushing
Hello all, I am developing an application and I use core.async to push data from multiple threads within an infinite (go (while true (let [data (! @my-channel) do processing here...)) in order to be processed. I keep my channel inside an atom defined at the start of my app. If an exception occurs in one of the threads, then I am calling an exception a global exception handler which will reset the atom which holds the channel in order to flush it and make sure the processing of the data it contains will stop. Now, my question is, does anyone know a better way to flush a core.async channel or the only way is to re-create the channel? Thank you for your time. Regards, Alexander -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
core.async and channel flushing
I am developing an application and I use core.async to push data from multiple threads within an infinite (go (while true (let [data (! @my-channel) (do processing here...))) in order to be processed. As you probably already figured out, I store my channel inside an atom defined at the start of my app. If an exception occurs in one of the threads, then I am calling a global exception handler which will reset the atom that holds the channel in order to flush it and make sure the processing of the data it contains will stop. Now, my question is, does anyone know a better way to flush a core.async channel or the only way is to re-create the channel? Thank you for your time. Regards, Alexander -- -- 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.
Architectural Review of Stefon: A Composable Blog Engine
Hi all,
This follows a previous post I made (see
herehttps://groups.google.com/forum/#!searchin/clojure/stefon/clojure/rCmPYa0Vw-4/XZx1CIaoEB4J).
I was looking for a simple, Clojure-based blog engine that allowed me to
stitch together components on an as needed basis.
I didn't find one. And to that end, I decided to create a system with a
very small kernel, which is wrapped by a simple plugin system. All
interactions with the system basically just happen in-memory. While this is
lightweight, it will only get interesting once we start attaching plugins,
and listen for messages in the system. Thus, all other components are
plugged into that kernel. I've gotten a small way towards that goal, and
I'm getting ready to package up an initial proof-of-concept. While I was
doing that though, I was hoping to get some architectural feedback from the
community. I ultimately want to make it easy for people to write plugins
for the this system. What do you think, and what do you want from this
system?
*Install Run Tests *
- go to your projects directory
- `*git clone g...@github.com:twashing/stefon.git*`
- `*git clone g...@github.com:twashing/stefon-datomic.git*`
- go to stefon-datomic and `*mkdir checkouts; ln -s ../stefon
checkouts/stefon*` ;; I'll push to Clojars once all is packaged up.
Read more about the checkouts
herehttp://jakemccrary.com/blog/2012/03/28/working-on-multiple-clojure-projects-at-once/
.
- To run either test suite, you can go to *stefon* or *stefon-datomic*
and run `*lein spec*`
*Overview *
- Typical Workflow
-
- ;; basic, in-memory operation
- (stefon.shell/start-system)
- (stefon.shell/create :post fubar one c c/t nil
nil)
- (stefon.shell/retrieve :post {:title fubar one})
-
- ;; Pluging in a component
- (defn receive-fn [message] (println message from the kernel
message)
- (def send-fn (stefon.shell/attach-plugin receive-fn)
- (send-fn {:fu :bar})
-
- ;; messages are lightweight - send any map you want; all other
plugins will receive it (like being connected to a network)
- ;; messages for which stefon listens, are configured
herehttps://github.com/twashing/stefon/blob/master/resources/config.edn
-
- Use of lamina (vs. core.async): I basically went with
Laminahttps://github.com/ztellman/lamina,
as it gives me the *channel-pair* function. This just returns a pair of
channels, where all messages sent to one channel can be received by the
other, and vice-versa. This is obviously used to communicate between the
kernel and plugins. If I didn't use this, I'd end up writing something that
did the same thing. I'd also be interested in something that gives me a
more straightforward path in testing. And if I need to switch out Lamina,
no plugin has to worry about changing any of their communication code. They
just keep using the same *receive* and *send* functions.
- Plugin scheme
- message structure is very lightweight. You can send any map you
want. And the traffic flow is open. So all other plugins will receive it
(like being connected to a network).
- And again, I chose to pass in and receive functions, instead of raw
channels. If I need to switch out Lamina, no plugin has to worry about
changing any of their communication code. They just keep using the same
*receive* and *send* functions.
*Todo *
- Finish Documentation
- have stefon pull in all configured plugins
- deploy libs to Clojars
That's it. If there's any setup or explanation that I've missed, please let
me know. Hope this is something you find useful. Looking forward to your
feedback.
Cheers
Tim Washington
Interruptsoftware.ca / Bkeeping.com
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members 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: The Eclipse Public License is not a good license
Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. That's my problem. On Sep 12, 2013, at 19:18, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote: This is an interesting thread. I think, though, it repeats what is a misconception about GPL -- that you cannot produce GPL code using Clojure. This isn't true, as far as I can see -- you can write GPL code using any language, because it doesn't usage restrictions in GPL do not percolate through a standard interface. So, for instance, my own library is covered by LGPL; it is possible to link this to GPL code without problems. Historically, the first GPL products (Emacs for example) were built using on non GPL platforms; it is the same issue. Sean Corfield seancorfi...@gmail.com writes: Searching the archives would have turned up some _long_ threads about this where it would have been clear that the license is not going to change - as well as explaining why it is the way it is. For example: https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8 (from 2008) Sean On Wed, Sep 11, 2013 at 6:41 AM, Kalinni Gorzkis musicdenotat...@gmail.com wrote: I think that Clojure should switch to a better license with similar spirit like Apache 2.0, BSD, or MIT. While the EPL doesn't have the evil copyleft requirement of GPL, and therefore allows and encourages commercial uses of the code, it has a requirement that makes it incompatible with the GPL: If you create modified versions of EPL-covered software, you must slap your name (or any other identity) on it. In my humble opinion, this restriction isn't justified. (All, or most, creators of modified versions will do that anyway). It may have been chosen uncarefully. Other permissive licenses better fulfill Rich Hickey's spirit. -- -- 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: The Eclipse Public License is not a good license
On Sat, Sep 14, 2013 at 5:31 PM, Musical Notation musicdenotat...@gmail.com wrote: Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. That's my problem. People are, of course, perfectly entitled to decide to not contribute to any free open source project for any reason, just as projects are entitled to choose whatever license they wish - and we should assume both sets of reasons are valid for the parties concerned... But I would hope you can understand why software intended for use by corporations would not want to include anonymous contributions (for legal reasons)? -- 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: Fantasy Baseball Lineup Optimization
Perhaps a bit intense but this problem might lend itself to mixed integer linear programming. MILP is a very broad formulation of optimization problems. Optimal solution of MILP problems is NP-Hard but very mature software solutions exist. I don't know what's out there in Clojure land for this but in Python the PuLP library offers idiomatic expression of MILP problems and connections to various open source solvers. At the very least you may find their examples illuminating; MILP is a very powerful tool to have in your toolbox. http://pythonhosted.org/PuLP/ http://pythonhosted.org/PuLP/CaseStudies/a_blending_problem.html On Friday, September 13, 2013 7:52:04 AM UTC-7, Mark Watson wrote: Hi, newish user here. I want to make an app that finds a simple, optimized, fantasy baseball lineup. Each player has a cost associated with them, as well as the average points per game they score, and position. For example: Mike Napoli, 4600, 2.9, 1B You have to choose one of each position: catcher, pitcher, 1st base, 2nd base, 3rd base, and shortstop. You also have to pick three outfielders. It would be easy to just pick the players with the highest points per game, but you also need to stay under a specified total cost. Currently, I iterate through every possibility, and swap an atom with a new lineup if the total average points is higher, while staying under the total cost limit. My issues are: 1) This seems like an inelegant solution (brute force) 2) I don't know how to best handle the fact that I need to select three outfielders from a single list, and cannot select one player more than once Any advice, suggestions would be great. Thanks! -- -- 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] quickie- autotest plugin for clojure.test
Hi, I put up a screenshot and a it now will show a little bit of unimportant stacktrace near the important stuff. Please let me know if you have any more ideas. thanks, Jake On Friday, September 13, 2013 12:21:00 PM UTC-6, Christopher Allen wrote: Link: https://github.com/jakepearson/quickie Is it possible to see *some* of the stack trace so you can debug? Also you should include a screenshot of what the library looks like in action. :) On Friday, September 13, 2013 10:57:35 AM UTC-7, Jake Pearson wrote: Hi, Quickie is a leiningen plugin to autotest clojure.test tests. There don't seem to be any active projects for clojure.test, so a couple of people at my office wrote one. Please let me know if you have any problems or ideas: - Uses the builtin clojure.test test runner so you don't need to rewrite your tests - Tools.namespace will unload and reload namespaces as needed to keep process in sync - Runs every time a clojure file in your project changes - Uses (Clansi)[https://github.com/ams-clj/clansi] to show a red or green bar to know if you tests are passing - Filters out exception stacktraces to remove cruft thanks, Jake -- -- 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] quickie- autotest plugin for clojure.test
Hi, I put up a screenshot and a it now will show a little bit of unimportant stacktrace near the important stuff. Please let me know if you have any more ideas. Bump your version to 0.2.2. thanks, Jake On Friday, September 13, 2013 12:21:00 PM UTC-6, Christopher Allen wrote: Link: https://github.com/jakepearson/quickie Is it possible to see *some* of the stack trace so you can debug? Also you should include a screenshot of what the library looks like in action. :) On Friday, September 13, 2013 10:57:35 AM UTC-7, Jake Pearson wrote: Hi, Quickie is a leiningen plugin to autotest clojure.test tests. There don't seem to be any active projects for clojure.test, so a couple of people at my office wrote one. Please let me know if you have any problems or ideas: - Uses the builtin clojure.test test runner so you don't need to rewrite your tests - Tools.namespace will unload and reload namespaces as needed to keep process in sync - Runs every time a clojure file in your project changes - Uses (Clansi)[https://github.com/ams-clj/clansi] to show a red or green bar to know if you tests are passing - Filters out exception stacktraces to remove cruft thanks, Jake -- -- 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] modern-cljs tutorials updated
You know you're a lisp programmer when you feel conflicted about balancing parentheses around emoticons. (like this :)) (or like this :) - Korny On 13 Sep 2013 12:35, Cedric Greevey cgree...@gmail.com wrote: On Thu, Sep 12, 2013 at 2:47 PM, Mimmo Cosenza mimmo.cose...@gmail.comwrote: Hi All, after a very long (and beautiful vacation) I came back on the modern-cljs series of tutorials... Oh, c'mon. Would you write (map #(* % 2.0 my-seq))? We're Lispers! We're supposed to get our parenthesis placement right! :) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, floats, ints and OpenGL
On Saturday, 14 September 2013 01:04:16 UTC+8, tbc++ wrote: This would be better, IMHO, than forever accepting semantics that prevent idiomatic code from ever being truly fast. You're going to have a hard time convincing people to give up some of the dynamism of Clojure just for the sake of more performance. Especially considering that many Clojure users are perfectly okay with boxed values, let alone need floats or other primitives. Let's be clear - I'm not asking anyone to give up on any dynamism. I am asking for an agreement that we want to allow high performance *options* in Clojure, so that we can at least match Scala/Java, for those use cases where people have genuine performance requirements. Some people don't care about performance enough for the distinction between float and double to matter. But others do. I think we (as a community) should try to support both use cases. Clojure has the potential to be *both* dynamic and fast if we design it right. It would be a shame if people in the community took a general stance that performance is good enough for me, so we aren't interested in supporting further performance improvements. I'm sure that isn't what is intended, but it could appear like that to people who raise performance issues only to get challenged / told that they don't have a valid problem. But what you are describing creates a whole ton of new problems, problems I don't see a good solution for. What you are describing would require the recompilation of entire source trees when a inner function is modified. So now we're in the Scala/Java land of recompile after every edit. Perhaps there's a use-case for invoke dynamic here, but now you're talking about breaking backwards compatibility for everyone not using Java 7+. I'm not suggesting recompile everything after edit. I'm suggesting lazily recompile stuff that is dependent on the one thing you changed. That's a much smaller compilation unit in most cases - maybe you are recompiling 2-5 functions instead of 1. If you change something that is used everywhere in your whole app, then yes: maybe it's going to recompile 100 or so functions. But even then, I doubt it will be a significant compile time compared to Java/Scala land. And note that we're talking about incurring this cost only for people doing dynamic changes to existing vars. This isn't common production usage (if you are mutating production state, I would hope you are using something with proper concurrency semantics like atoms or agents or refs to mutate data!). So performance probably shouldn't matter at all, apart from the subjective experience of compiling fast enough to be usable at the REPL. Which I'm pretty sure is a fairly easy target to hit. Like I said, this would be a big change, but it would be a good way to combine dynamism with excellent runtime performance. I'll be the first to admit that I'd like to rewrite the Clojure compiler as a true multi-pass optimizing compiler. But that's a task I haven't undertaken for two reasons 1) it's a ton of work that would take months (if not years) to reach the level of performance currently offered by Clojure. 2) I really don't need it. Every time I need that level of performance I drop to Java, CUDA or some other high performance toolkit. Personally I think it would be much better for someone to come up with a typed lisp that interops very cleanly with Clojure. That way you can build your inner kernels using a lisp-like language, and then glue it together with Clojure. But let me close by saying, if you really want better primitives, I'd suggest writing up a proposal for how it would work, perhaps even with some example using macros and genclass. Until then we don't have anything to go off of, people say I'd love to have feature X, well we all would, but all the suggestions thus far won't work, so how do you plan on fixing that? My pragmatic proposal for now is very simple: allow metadata to specify functions to be compiled in a way that invocation is compiled statically to an invokevirtual. You lose the dynamic var deref, but gain better runtime performance and the ability to use arbitrary types / primitives (which solves the OP's problem). This limited-scope proposal won't effect any existing dynamic usage, so people who like their fully mutable vars with their dynamic lookups can keep them. It is on JIRA as CLJ-1263 , comments / improvements welcome. http://dev.clojure.org/jira/browse/CLJ-1263 Timothy On Fri, Sep 13, 2013 at 1:54 AM, Mikera mike.r.an...@gmail.comjavascript: wrote: On Friday, 13 September 2013 12:11:50 UTC+8, tbc++ wrote: If we can do away with the interface generation, then support for arbitrary primitive arguments should become relatively straightforward. How would we even call a function without an interface? Remember everything is defined behind vars, so you simply can't assume that a
