Re: Rebinding Defs
Alan a...@malloys.org writes: Hi Alan, And yes, it slows things down a bit, so in 1.3 the default is to not support rebinding (though re-def'ing is still supported). What do you mean by doesn't support rebinding? Does that mean, that things like (def foo false) (binding [foo true] (dostuff)) (let [foo true] (dostuff) (println foo)) aren't supported anymore? BTW, I'm new to clojure, so I just got a question concerning binding versus let right now. If `dostuff' is a function that only prints the value of foo, am I right that the `binding' line would print true, whereas the the `let' line prints false and true, because the dostuff-print is not in the lexical scope of the let, right? Bye, Tassilo -- 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
Re: Rebinding Defs
And yes, it slows things down a bit, so in 1.3 the default is to not support rebinding (though re-def'ing is still supported). What do you mean by doesn't support rebinding? Does that mean, that things like (def foo false) (binding [foo true] (dostuff)) (let [foo true] (dostuff) (println foo)) Not allowed unless you mark `foo' as dynamic. The syntax looks like this - (def ^:dynamic foo false) Regards, BG -- Baishampayan Ghose b.ghose at gmail.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
Re: Macros, macros, macros
Hi, On 9 Mrz., 08:52, Andreas Kostler andreas.koestler.le...@gmail.com wrote: (defn make-native-query [db str foo] (. (proxy [ONativeSynchQuery] [db str foo] (filter [rec] (.. rec (field location) (eq Madrid) and (field name) (eq Dhali) go))) run objs)) Well, I don't want the symbols location, name, etc to be evaluated...e.g. I couldn't use location if not in a macro, right? Secondly, the structure isn't quite as uniform. Like in the example above (.. rec (create-query [[location eq Madrid] and [name eq Dhali]])) should expand to something like (.. rec (field location) (eq Madrid) and (field name) (eq Dhali)) Maybe I'm still missing something but I can't see how I could do that without a macro... You could use keywords. (query rec [[:location :eq Madrid] :and [:name :eq Dhali]]) where query is defined as (defmulti query (fn [_ [_ op _]] op)) (defmethod query :and [rec [lhs _ rhs]] (- rec (query lhs) .and (query rhs))) (defmethod query :eq [rec [lhs _ rhs]] (- rec (.field (name lhs)) (.eq rhs))) Then there is no need for a macro and you can extend things for other operators like :neq, :or and the like. If you don't need this extensibility you can even go with a single function and a case. (defn query [rec [lhs op rhs]] (case op :and (- rec (query lhs) .and (query rhs)) :eq (- rec (.field (name lhs)) (.eq rhs This should read pretty much like the API you have to use. If you really need macros the above should easy to modify: (defmacro query [rec [lhs op rhs]] (case op 'and `(- ~rec (query ~lhs) .and (query ~rhs)) 'eq `(- ~rec (.field ~(name lhs)) (.eq ~rhs Not tested, though. By using the .notation for methods you don't have to ~' quote things in the macro. And by using - instead of .. you can also use plain Clojure functions and macros besides method calls. You cannot write a macro which expands the way you want it to without significant effort with code walking and a surrounding macro. Which is not appropriate for this case, I think. Hope this helps. Sincerely Meikel -- 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
Re: Issue with lein-ring...
On Mar 8, 8:31 pm, John Szakmeister j...@szakmeister.net wrote: I've been working on a web app, and it was using leiningen-war. The author of that suggest moving to the lein-ring plugin on his github site... so, I did that. Apologies if the wording in the README of leiningen-war has caused any problems. The road to hell is paved with good intentions. Leiningen-war remains alive and supported. I'm happy to fix bugs and add features when requested - I use the plugin myself and will continue to do so. However, people new to Java web development were having problems with Leiningen-war since it does everything in the Java style with XML config files and an unfamiliar directory structure. This approach was obviously a barrier for newcomers using Clojure who wanted to create a deployable web application. The lein- ring plugin is a much easier plugin to use, it integrates well with Ring and it has extra features. It is my hope was that all new users start with lein-ring. I'll change the README in leiningen-war to make it clearer. Saul -- 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
Re: Macros, macros, macros
Hi again, On 9 Mrz., 09:23, Meikel Brandmeyer m...@kotka.de wrote: (defmacro query [rec [lhs op rhs]] (case op 'and `(- ~rec (query ~lhs) .and (query ~rhs)) 'eq `(- ~rec (.field ~(name lhs)) (.eq ~rhs Here a short note, why a macro can be actually annoying: If you write macro which expands into a query the above will break, because the symbols are suddenly qualified. Or you have to use ~'and and ~'eq all over the place. Otherwise the case won't work anymore. You'd have to write the macro more robust like this: (defmacro query [rec [lhs op rhs]] (case (name op) and eq )) With functions you don't have to think about these effects. Sincerely Meikel -- 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
Newbie: General question about concurrency in Clojure
I'm still getting started with Clojure and I'm wondering about how one should generally go about concurrency and how transparent concurrency is in Clojure. So, to me there would be two approaches: A) Be aware of the parts of your system that will be concurrent and only within these parts write concurrent code using reference types and so on. My question here would be, how much a developer has to scratch his head about concurrency. Agreed, it's much easier than using locks like in Java, but still I have to think about what should be a ref, what should be an agent and how to set up transactions. B) Write concurrent code where you can, even the (smallest) parts of your system which aren't necissarily inherently concurrent. The question here is, if handling concurrency in Clojure is simple enough to go about it this way, or if it would be much less effort to write non-concurrent code. So, in general I think the question is, how transparent concurrency is in Clojure. The ultimate goal would be to just write code, that is concurrent, but to not have to think to much about it. If you like, you could also compare Clojure's approach to actor based models. -- 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
Re: Rebinding Defs
Baishampayan Ghose b.gh...@gmail.com writes: Hi! What do you mean by doesn't support rebinding? Does that mean, that things like (def foo false) (binding [foo true] (dostuff)) (let [foo true] (dostuff) (println foo)) Not allowed unless you mark `foo' as dynamic. The syntax looks like this - (def ^:dynamic foo false) Ah, I see. Bye, Tassilo -- 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
Re: Newbie: General question about concurrency in Clojure
On Mar 9, 9:26 am, Nick Wiedenbrueck nick.wiedenbru...@googlemail.com wrote: I'm still getting started with Clojure and I'm wondering about how one should generally go about concurrency and how transparent concurrency is in Clojure. So, to me there would be two approaches: A) Be aware of the parts of your system that will be concurrent and only within these parts write concurrent code using reference types and so on. Basically, yes. But note that any code that doesn't use atoms, refs and other mutable stuff is concurrent by itself. The ref types are the ones that require some thought. As a rough rule of thumb, this means you want to keep the number of reference objects down. My question here would be, how much a developer has to scratch his head about concurrency. Agreed, it's much easier than using locks like in Java, but still I have to think about what should be a ref, what should be an agent and how to set up transactions. You always have this problem. But really, if you're new to clojure, you don't need refs nearly as much as you probably think right now. B) Write concurrent code where you can, even the (smallest) parts of your system which aren't necissarily inherently concurrent. The question here is, if handling concurrency in Clojure is simple enough to go about it this way, or if it would be much less effort to write non-concurrent code. So, in general I think the question is, how transparent concurrency is in Clojure. The ultimate goal would be to just write code, that is concurrent, but to not have to think to much about it. Again, anything that doesn't use mutable objects is automatically concurrent. But I think you're conflating concurrency and parallelism. Joost. -- 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
with-timeout... ?
Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. Thanks, Sean -- 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
Re: Newbie: General question about concurrency in Clojure
The answer would be a mix of A and B, mostly because there seems to be an assumption that you have to consider concurrency everywhere in order to be able to have it at some point later. This is not the case. You do tend to be very explicit about concurrency and only use the concurrency primitives (refs, atoms, agents and vars) at a few selected spots, but most of the time you don't have to think about concurrency at all, since even the smallest parts of the system is written in a way that allows for concurrency (by using pure functions and not using the concurrency primitives). Clojure is a functional programming language, which among other things means that computation is in general carried out using referentially transparent (pure) functions. A pure function always return the same value for the same input and is free from side-effects. Pure functions are always thread safe and will never be any problem to concurrency. In a language like Java, mutation of variables and objects is very often used for performing computations. But this intervenes calculations that has nothing to do with each other, since a mutating step in computation A can affect computation B if they operate on the same objects. The result is that in Java, you have to think about concurrency when you perform computations, unlike in Clojure. (Here, I use the word compute to mean something like produce new data of interest.) You tend to write the largest part of a Clojure application as compositions of pure functions. You only have to introduce reference primitives when you have a long-running process whose state changes and evolves over time (for instance a game or a server, or anything that communicates with the outside world and changes thereafter). Clojure acknowledges the need for things to be able to change, but keeps that separate from computation. Most library code I have written hasn't used the concurrency primitives at all. The state changing part of an application often resides at a higher level. // raek -- 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
Re: with-timeout... ?
Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. You can roll your own macro to do this. Example - (defmacro with-timeout [ms body] `(let [f# (future ~@body)] (.get #^java.util.concurrent.Future f# ~ms java.util.concurrent.TimeUnit/MILLISECONDS))) Regards, BG -- Baishampayan Ghose b.ghose at gmail.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
Re: Rebinding Defs
On Mar 8, 6:59 pm, Timothy Baldridge tbaldri...@gmail.com wrote: If in a namespace I bind a var: (def foo 3) And then later on in my program re-bind that var: (def foo 1) Will all parts of my program instantly see that update? How is it possible to have any sort performance when we're basically having a namespace function lookup for every single function call? To reiterate what others have said - referencing something that has been def'd is a two-hop lookup. The first is to follow the symbol, through the namespace map, to get the Var instance. This is the part you are concerned about, but it happens at compile-time, so it's all good. The second hop is to follow the pointer that's in the Var. This currently (in 1.2) happens at runtime, but it's pretty cheap (just a pointer deref, I think). In 1.3, this part too will happen at compile- time unless the var is specifically marked as :dynamic. I wonder what will happen in 1.3 with code that does the declare first thing: (declare foo) (defn bar [] (do-critical-loop (foo))) (defn foo [] (do-stuff)) Will it suddenly be slower (relative to other code). IOW, will it continue to run at 1.2 speeds (presumably declare will create a :dynamic var?), while code that puts functions in the right order will get magically faster? - Chris -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: with-timeout... ?
On Wed, Mar 9, 2011 at 7:25 AM, Baishampayan Ghose b.gh...@gmail.com wrote: Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. You can roll your own macro to do this. Example - (defmacro with-timeout [ms body] `(let [f# (future ~@body)] (.get #^java.util.concurrent.Future f# ~ms java.util.concurrent.TimeUnit/MILLISECONDS))) Variation on that macro are what I've seen across the variety of sources I've mentioned in my original message. It just strikes me as odd that something so general hasn't made it into a library. If it really hasn't made a library, ok.. I just wanted to make sure it wasn't in a library somewhere and that keeping the hand rolled macro wasn't something I should still be doing. -- 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
Re: Newbie: General question about concurrency in Clojure
Thanks for your answers. Guess, I just got a little bit lost after digging deeper into the whole thing. Just didn't see anymore that the core problem is mutability. But it's much clearer again now. -- 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
[ANN] borneo - Clojure wrapper for Neo4j, a graph database.
Hello, I've released a Clojure wrapper for Neo4j called borneo. Purpose of this library is to provide intiutive access to commonly used Neo4j operations. It uses official Neo4j Java bindings. It does not use Blueprints interface. Project page, examples: http://github.com/wagjo/borneo API: http://wagjo.github.com/borneo Install: Libs available through clojars, include dependency [borneo 0.1.0] in your project.clj. Best, Jozef -- 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
Re: [ANN] borneo - Clojure wrapper for Neo4j, a graph database.
I've released a Clojure wrapper for Neo4j called borneo. Purpose of this library is to provide intiutive access to commonly used Neo4j operations. It uses official Neo4j Java bindings. It does not use Blueprints interface. Looks awesome! Many thanks for this :) Regards, BG -- Baishampayan Ghose b.ghose at gmail.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
Re: [ANN] borneo - Clojure wrapper for Neo4j, a graph database.
I've released a Clojure wrapper for Neo4j called borneo. Purpose of this library is to provide intiutive access to commonly used Neo4j operations. It uses official Neo4j Java bindings. It does not use Blueprints interface. Minor observation, it seems you are using `proxy` to implement interfaces. Why not use `reify` instead? Regards, BG -- Baishampayan Ghose b.ghose at gmail.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
Re: [ANN] borneo - Clojure wrapper for Neo4j, a graph database.
On Wednesday, March 9, 2011 3:09:05 PM UTC+1, Baishampayan Ghose wrote: I've released a Clojure wrapper for Neo4j called borneo. Purpose of this library is to provide intiutive access to commonly used Neo4j operations. It uses official Neo4j Java bindings. It does not use Blueprints interface. Minor observation, it seems you are using `proxy` to implement interfaces. Why not use `reify` instead? Thank you for this remark. reify would be more idiomatic, I'll change it. proxy is a clojure-neo4j leftover, from which I've forked. Best, Jozef -- 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
Re: Issue with lein-ring...
On Tue, Mar 8, 2011 at 4:04 PM, Michael Ossareh ossa...@gmail.com wrote: [snip] 90% of the time I find that: lein clean rm -rf lib lein deps solves this type of issue. Yeah... I've done that a few times. :-) I should say that I'm using the 1.3.0-master-snapshot of Clojure. I did find that ring.util.tracker is in ring-reload-modified-0.1.0.jar for the development dependencies. But I think something else is wrong. The actual traceback points to find-namespace as being the culprit... but I don't see how it can be short of a compiler bug. :-( -John -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Rebinding Defs
On Mar 9, 12:00 am, Tassilo Horn tass...@member.fsf.org wrote: Alan a...@malloys.org writes: Hi Alan, And yes, it slows things down a bit, so in 1.3 the default is to not support rebinding (though re-def'ing is still supported). What do you mean by doesn't support rebinding? Does that mean, that things like (def foo false) (binding [foo true] (dostuff)) (let [foo true] (dostuff) (println foo)) aren't supported anymore? BTW, I'm new to clojure, so I just got a question concerning binding versus let right now. If `dostuff' is a function that only prints the value of foo, am I right that the `binding' line would print true, whereas the the `let' line prints false and true, because the dostuff-print is not in the lexical scope of the let, right? Bye, Tassilo You are correct about how binding and let behave. As Ghoseb says, you can get this behavior back in 1.3 with (def ^:dynamic foo false). The behavior of let has not changed in 1.3: Your let-form will perform identically, because it is not rebinding the global #'foo var: it is creating a new local symbol with name 'foo and value true. As in 1.2, (dostuff) will still see #'foo as false, and the println will still see 'foo as true. -- 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
Re: with-timeout... ?
See https://github.com/Raynes/clojail It's a sandboxing library for Clojure, which among other things means it needs to try running an operation and give up after N seconds. You can skip the sandboxing part entirely if you want; it exposes a pretty general thunk-timeout function. On Mar 9, 4:43 am, Sean Allen s...@monkeysnatchbanana.com wrote: On Wed, Mar 9, 2011 at 7:25 AM, Baishampayan Ghose b.gh...@gmail.com wrote: Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. You can roll your own macro to do this. Example - (defmacro with-timeout [ms body] `(let [f# (future ~@body)] (.get #^java.util.concurrent.Future f# ~ms java.util.concurrent.TimeUnit/MILLISECONDS))) Variation on that macro are what I've seen across the variety of sources I've mentioned in my original message. It just strikes me as odd that something so general hasn't made it into a library. If it really hasn't made a library, ok.. I just wanted to make sure it wasn't in a library somewhere and that keeping the hand rolled macro wasn't something I should still be doing. -- 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
Nano Text Editor Syntax Highlighting
For the Nano text editor, is there syntax highlighting clojure? I have not been able to find the highlighting config file for Clojure (or at least for Lisp) and I do not know (yet) enough Clojure to create one. Do you have one? Do you know where I can get it? Thanks in advance guys =) -- 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
Monad Lessons
I gave a talk at CodePaLOUsa on monads and got some favorable feedback. So I thought I'd offer to do a live training session on monads using pretty much the same material, but at a shared REPL rather than with slides. How it would work is I would start a Skype conference for 5 to 10 people. We would also all log in to a tmux session where I would show the examples and their results. So, my question is how many would be interested in such a session? This would be a basic introduction to monads. Future session could be about more advanced monad topics, if there was a demand for that. Jim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Tracking Clojure 1.3/2.0 progress
Hi all, I've put together a Jira dashboard to display a distillation of the current progress toward the 1.3/2.0 release. I believe that anyone can view it, so pass the link far and wide. http://dev.clojure.org/jira/secure/Dashboard.jspa?selectPageId=10014 There is additional information displayed if you log in. Enjoy. :f -- 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
Re: Nano Text Editor Syntax Highlighting
I think the best way to get this is to close Nano and open Emacs... On Mar 9, 10:45 am, Hugo Blanco white.th...@gmail.com wrote: For the Nano text editor, is there syntax highlighting clojure? I have not been able to find the highlighting config file for Clojure (or at least for Lisp) and I do not know (yet) enough Clojure to create one. Do you have one? Do you know where I can get it? Thanks in advance guys =) -- 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
Re: Issue with lein-ring...
On Wed, Mar 9, 2011 at 1:29 PM, John Szakmeister j...@szakmeister.net wrote: On Tue, Mar 8, 2011 at 4:04 PM, Michael Ossareh ossa...@gmail.com wrote: [snip] 90% of the time I find that: lein clean rm -rf lib lein deps solves this type of issue. Yeah... I've done that a few times. :-) I should say that I'm using the 1.3.0-master-snapshot of Clojure. I did find that ring.util.tracker is in ring-reload-modified-0.1.0.jar for the development dependencies. But I think something else is wrong. The actual traceback points to find-namespace as being the culprit... but I don't see how it can be short of a compiler bug. :-( Changing it to use clojure and contrib 1.2.0, everything is fine. So something is happening between going from 1.2.0 to 1.3.0. -John -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Rebinding Defs
On Mar 9, 7:31 am, Chris Perkins chrisperkin...@gmail.com wrote: On Mar 8, 6:59 pm, Timothy Baldridge tbaldri...@gmail.com wrote: If in a namespace I bind a var: (def foo 3) And then later on in my program re-bind that var: (def foo 1) Will all parts of my program instantly see that update? How is it possible to have any sort performance when we're basically having a namespace function lookup for every single function call? To reiterate what others have said - referencing something that has been def'd is a two-hop lookup. The first is to follow the symbol, through the namespace map, to get the Var instance. This is the part you are concerned about, but it happens at compile-time, so it's all good. The second hop is to follow the pointer that's in the Var. This currently (in 1.2) happens at runtime, but it's pretty cheap (just a pointer deref, I think). In 1.3, this part too will happen at compile- time unless the var is specifically marked as :dynamic. After writing this, I started to wonder whether I really know what I'm talking about, and it turns out I don't :) I checked the code, and my understanding of what is changing in 1.3 was wrong. It does still do the pointer-deref at runtime - what it doesn't do (for non-dynamic vars) is check to see whether it's thread-bound. So it saves an AtomicBoolean.get(). I wouldn't have thought that would save enough time to be worth it, but I guess maybe it does. - Chris -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] borneo - Clojure wrapper for Neo4j, a graph database.
On Wed, Mar 9, 2011 at 1:22 PM, Jozef Wagner jozef.wag...@gmail.com wrote: On Wednesday, March 9, 2011 3:09:05 PM UTC+1, Baishampayan Ghose wrote: I've released a Clojure wrapper for Neo4j called borneo. Purpose of this library is to provide intiutive access to commonly used Neo4j operations. It uses official Neo4j Java bindings. It does not use Blueprints interface. Minor observation, it seems you are using `proxy` to implement interfaces. Why not use `reify` instead? Thank you for this remark. reify would be more idiomatic, I'll change it. proxy is a clojure-neo4j leftover, from which I've forked. Last I checked, proxy can extend a concrete class (as can gen-class) but reify (and deftype, and defrecord) cannot, so there may still be some use cases for proxy. -- 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
Re: [ANN] borneo - Clojure wrapper for Neo4j, a graph database.
On Wednesday, March 9, 2011 9:23:54 PM UTC+1, Ken Wesson wrote: On Wed, Mar 9, 2011 at 1:22 PM, Jozef Wagner jozef@gmail.com wrote: On Wednesday, March 9, 2011 3:09:05 PM UTC+1, Baishampayan Ghose wrote: I've released a Clojure wrapper for Neo4j called borneo. Purpose of this library is to provide intiutive access to commonly used Neo4j operations. It uses official Neo4j Java bindings. It does not use Blueprints interface. Minor observation, it seems you are using `proxy` to implement interfaces. Why not use `reify` instead? Thank you for this remark. reify would be more idiomatic, I'll change it. proxy is a clojure-neo4j leftover, from which I've forked. Last I checked, proxy can extend a concrete class (as can gen-class) but reify (and deftype, and defrecord) cannot, so there may still be some use cases for proxy. I wonder which one is faster in my case (implementing one interface of one method). -- 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
Re: Tracking Clojure 1.3/2.0 progress
On 03/09/2011 02:18 PM, Fogus wrote: Hi all, I've put together a Jira dashboard to display a distillation of the current progress toward the 1.3/2.0 release. I believe that anyone can view it, so pass the link far and wide. http://dev.clojure.org/jira/secure/Dashboard.jspa?selectPageId=10014 There is additional information displayed if you log in. Enjoy. :f Very nice! -- Cheers, Aaron Bedra -- Clojure/core http://clojure.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
Re: Tracking Clojure 1.3/2.0 progress
On Wed, Mar 9, 2011 at 13:23, Aaron Bedra aaron.be...@gmail.com wrote: On 03/09/2011 02:18 PM, Fogus wrote: Hi all, I've put together a Jira dashboard to display a distillation of the current progress toward the 1.3/2.0 release. I believe that anyone can view it, so pass the link far and wide. http://dev.clojure.org/jira/secure/Dashboard.jspa?selectPageId=10014 There is additional information displayed if you log in. Enjoy. :f Very nice! +1 -- Cheers, Aaron Bedra -- Clojure/core http://clojure.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 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
Re: 1.3 (inc alpha4)?
Hello. I understand what it means. Thank you. -- Name: OGINO Masanori (荻野 雅紀) E-mail: masanori.og...@gmail.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
Making the JVM's stack effectively deeper
It seems to me there is a way to make the JVM's stack effectively deeper -- even limited only by available memory. Threads have separate stacks, and there's no limit on threads, *especially* if they're nearly all sleeping. So ... (defn apply-with-stack-extension [f args] (let [x (future (try [(apply f args) nil] (catch Throwable t [nil t]))) [res exc] @x] (if exc (throw exc) res))) In theory (untested as yet) this should act like apply, except that almost the full maximum stack depth is available to f, no matter how far the stack has piled up with apply-with-stack-extension. As a side effect, if an exception is thrown its stack trace starts after the last apply-with-stack-extension; everything before that is cut off. That may be more of a mixed blessing than a curse. :) In practice, something like this (plus tracking nesting depth to trigger it every 100 or so stack frames) could be used to make the lazy-stuff framework much more resistant to SOE throws. Another variation is to have an SOE handler in many common lazy functions, like map, that catches SOE and retries using apply-with-stack-extension, or using a version of the function that applies it periodically. That might reduce the performance impact to nearly nil for cases that don't have a problem with SOE without a-w-s-e. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: with-timeout... ?
Or you could just modify the source of promise ... i dont know why
promises dont support timeouts
(defprotocol PWait
(wait-for [this timeout units] [this timeout]))
;;copied from clojure source, but adding timeout wait-for
(defn promise
Alpha - subject to change.
Returns a promise object that can be read with deref/@, and set,
once only, with deliver. Calls to deref/@ prior to delivery will
block. All subsequent derefs will return the same delivered value
without blocking.
{:added 1.1}
[]
(let [d (java.util.concurrent.CountDownLatch. 1)
v (atom nil)]
(reify
clojure.lang.IDeref
(deref [_] (.await d) @v)
PWait
(wait-for [this timeout]
(wait-for this timeout
java.util.concurrent.TimeUnit/MILLISECONDS))
(wait-for [this timeout units]
(if timeout
(.await d timeout units)
(do (.await d) true)))
clojure.lang.IFn
(invoke [this x]
(locking d
(if (pos? (.getCount d))
(do (reset! v x)
(.countDown d)
x)
(throw
(IllegalStateException.
Multiple deliver calls to a promise
--
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
Re: Issue with lein-ring...
On Wed, Mar 9, 2011 at 3:29 AM, Saul Hazledine shaz...@gmail.com wrote: On Mar 8, 8:31 pm, John Szakmeister j...@szakmeister.net wrote: I've been working on a web app, and it was using leiningen-war. The author of that suggest moving to the lein-ring plugin on his github site... so, I did that. Apologies if the wording in the README of leiningen-war has caused any problems. The road to hell is paved with good intentions. No worries. :-) Leiningen-war remains alive and supported. I'm happy to fix bugs and add features when requested - I use the plugin myself and will continue to do so. However, people new to Java web development were having problems with Leiningen-war since it does everything in the Java style with XML config files and an unfamiliar directory structure. This approach was obviously a barrier for newcomers using Clojure who wanted to create a deployable web application. The lein- ring plugin is a much easier plugin to use, it integrates well with Ring and it has extra features. It is my hope was that all new users start with lein-ring. That's pretty much what I read. I happen to be a newish user of it, so I saw the readme and said oh, I guess I should try lein-ring. So I jumped that direction. I'll change the README in leiningen-war to make it clearer. Thanks for the explanation! -John -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Making the JVM's stack effectively deeper
On Mar 9, 2:27 pm, Ken Wesson kwess...@gmail.com wrote: It seems to me there is a way to make the JVM's stack effectively deeper -- even limited only by available memory. Threads have separate stacks, and there's no limit on threads, *especially* if they're nearly all sleeping. So ... (defn apply-with-stack-extension [f args] (let [x (future (try [(apply f args) nil] (catch Throwable t [nil t]))) [res exc] @x] (if exc (throw exc) res))) In theory (untested as yet) this should act like apply, except that almost the full maximum stack depth is available to f, no matter how far the stack has piled up with apply-with-stack-extension. As a side effect, if an exception is thrown its stack trace starts after the last apply-with-stack-extension; everything before that is cut off. That may be more of a mixed blessing than a curse. :) In practice, something like this (plus tracking nesting depth to trigger it every 100 or so stack frames) could be used to make the lazy-stuff framework much more resistant to SOE throws. Another variation is to have an SOE handler in many common lazy functions, like map, that catches SOE and retries using apply-with-stack-extension, or using a version of the function that applies it periodically. That might reduce the performance impact to nearly nil for cases that don't have a problem with SOE without a-w-s-e. Clever, but do we really want to encourage writing code that blows infinite stack, by burying the problem until all of the JVM's memory has been used up for stack? I agree there's a place for this sort of thing, but I don't think we would want to make it any kind of default for things like map/filter. -- 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
Re: Making the JVM's stack effectively deeper
On Wed, Mar 9, 2011 at 6:59 PM, Alan a...@malloys.org wrote: Clever, but do we really want to encourage writing code that blows infinite stack, by burying the problem until all of the JVM's memory has been used up for stack? I agree there's a place for this sort of thing, but I don't think we would want to make it any kind of default for things like map/filter. There are two situations this would affect. One, incorrect code that goes into infinite recursion would throw OOME instead of SOE. Two, semantically-correct code that happens to nest too deeply (which sometimes happens, especially with (reduce (mapcat ...))) would work instead of throw SOE. Currently, the latter can be worked around by throwing a doall into things, at the cost of no longer being lazy -- sometimes that solution causes OOME instead of SOE when we should really be able to accomplish our goals without either exception. I'm not averse to it being a doall-like thing that, instead of eagerly realizing a sequence, maintains its laziness but stack-extends that laziness (by maintaining some knowledge of stack depth and doing a-w-s-e on its lazy-seq function if it gets deep enough -- something like (let [step (fn somestuff) step (if too-deep #(a-w-s-e step %) f)] (lazy-seq ...)). -- 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
Re: [ANN] borneo - Clojure wrapper for Neo4j, a graph database.
Minor observation, it seems you are using `proxy` to implement interfaces. Why not use `reify` instead? Thank you for this remark. reify would be more idiomatic, I'll change it. proxy is a clojure-neo4j leftover, from which I've forked. Last I checked, proxy can extend a concrete class (as can gen-class) but reify (and deftype, and defrecord) cannot, so there may still be some use cases for proxy. I agree, but Jozef doesn't need to extend concrete classes in borneo, he just has a bunch of interfaces to reify :) Regards, BG -- Baishampayan Ghose b.ghose at gmail.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
Re: with-timeout... ?
I've been working in this direction with Cljque, for example http://bit.ly/gCtmAl Cljque is still an experiment and has no stable API or documentation. -Stuart Sierra clojure.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
Re: with-timeout... ?
oooh ... I can definitely find a use for this in my project! Thanks for pointing it 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
Re: [ANN] borneo - Clojure wrapper for Neo4j, a graph database.
On Wed, Mar 9, 2011 at 8:15 PM, Baishampayan Ghose b.gh...@gmail.com wrote: Minor observation, it seems you are using `proxy` to implement interfaces. Why not use `reify` instead? Thank you for this remark. reify would be more idiomatic, I'll change it. proxy is a clojure-neo4j leftover, from which I've forked. Last I checked, proxy can extend a concrete class (as can gen-class) but reify (and deftype, and defrecord) cannot, so there may still be some use cases for proxy. I agree, but Jozef doesn't need to extend concrete classes in borneo, he just has a bunch of interfaces to reify :) OK. I was just responding with clarification in case anyone reading this thread came away with the impression that proxy was completely deprecated in favor of reify. -- 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
Re: Monad Lessons
+1 (though I'll have to read about tmux first) :) Regards, Manoj. On Mar 10, 12:15 am, jim jim.d...@gmail.com wrote: I gave a talk at CodePaLOUsa on monads and got some favorable feedback. So I thought I'd offer to do a live training session on monads using pretty much the same material, but at a shared REPL rather than with slides. How it would work is I would start a Skype conference for 5 to 10 people. We would also all log in to a tmux session where I would show the examples and their results. So, my question is how many would be interested in such a session? This would be a basic introduction to monads. Future session could be about more advanced monad topics, if there was a demand for that. Jim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Monad Lessons
I'd be interested. This doesn't really scale though in the way a recording does. Are you thinking this would give you a chance to practice teaching it before making a recording? Maybe post the slides so people can get an idea of what will be covered. Also, maybe clarify whether this is free (http://xkcd.com/870/). Scott On Wed, Mar 9, 2011 at 2:15 PM, jim jim.d...@gmail.com wrote: I gave a talk at CodePaLOUsa on monads and got some favorable feedback. So I thought I'd offer to do a live training session on monads using pretty much the same material, but at a shared REPL rather than with slides. How it would work is I would start a Skype conference for 5 to 10 people. We would also all log in to a tmux session where I would show the examples and their results. So, my question is how many would be interested in such a session? This would be a basic introduction to monads. Future session could be about more advanced monad topics, if there was a demand for that. Jim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To 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
Re: Monad Lessons
On Thu, Mar 10, 2011 at 12:45 AM, jim jim.d...@gmail.com wrote: I gave a talk at CodePaLOUsa on monads and got some favorable feedback. So I thought I'd offer to do a live training session on monads using pretty much the same material, but at a shared REPL rather than with slides. How it would work is I would start a Skype conference for 5 to 10 people. We would also all log in to a tmux session where I would show the examples and their results. So, my question is how many would be interested in such a session? This would be a basic introduction to monads. Future session could be about more advanced monad topics, if there was a demand for that. Recording the session and distributing them will be more scalable... regards vivek Jim -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- The hidden harmony is better than the obvious!! -- 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
