Re: Can I safely put that Clojure will Primarily remain a JVM language in the future as it is now?
On Nov 24, 2012, at 9:24 PM, Leon Adler wrote: This post was not meant for any queries on the release schedules of the various Clojure versions, but for a curious question -- Will Clojure (take all the upcomming versions back-to-back) remain to be known as the JVM language anytime in the future?. You can say, that this question arises from curiosity :), but there is more. Lets' take Scala (scala runs on CLR too, but is still known as the JVM language, and it seems, will remain so) or Groovy. Nobody assured me about their future, but somewhere I know, that they will remain to be developed as the ''JVM languages''. Can I put Clojure in their league? Leon: Here is a suggestion. Take the mental process by which you did this: Nobody assured me about their future, but somewhere I know, that they will remain to be developed as the JVM languages.' Do a replacement of the words Scala and Groovy with Clojure in that mental process, and Bob's your uncle. Somehow I just know that this will work. Andy -- 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: Can I safely put that Clojure will Primarily remain a JVM language in the future as it is now?
Thanks Andy. I will do that. :) Thank you all. Andy Fingerhut wrote: On Nov 24, 2012, at 9:24 PM, Leon Adler wrote: This post was not meant for any queries on the release schedules of the various Clojure versions, but for a curious question -- Will Clojure (take all the upcomming versions back-to-back) remain to be known as the JVM language anytime in the future?. You can say, that this question arises from curiosity :), but there is more. Lets' take Scala (scala runs on CLR too, but is still known as the JVM language, and it seems, will remain so) or Groovy. Nobody assured me about their future, but somewhere I know, that they will remain to be developed as the ''JVM languages''. Can I put Clojure in their league? Leon: Here is a suggestion. Take the mental process by which you did this: Nobody assured me about their future, but somewhere I know, that they will remain to be developed as the JVM languages.' Do a replacement of the words Scala and Groovy with Clojure in that mental process, and Bob's your uncle. Somehow I just know that this will work. Andy -- 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: Can I safely put that Clojure will Primarily remain a JVM language in the future as it is now?
Thanks Andy. I will do that. :) Thank you all. Andy Fingerhut wrote: On Nov 24, 2012, at 9:24 PM, Leon Adler wrote: This post was not meant for any queries on the release schedules of the various Clojure versions, but for a curious question -- Will Clojure (take all the upcomming versions back-to-back) remain to be known as the JVM language anytime in the future?. You can say, that this question arises from curiosity :), but there is more. Lets' take Scala (scala runs on CLR too, but is still known as the JVM language, and it seems, will remain so) or Groovy. Nobody assured me about their future, but somewhere I know, that they will remain to be developed as the ''JVM languages''. Can I put Clojure in their league? Leon: Here is a suggestion. Take the mental process by which you did this: Nobody assured me about their future, but somewhere I know, that they will remain to be developed as the JVM languages.' Do a replacement of the words Scala and Groovy with Clojure in that mental process, and Bob's your uncle. Somehow I just know that this will work. Andy -- 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
a question for crate and hiccup
I wonder if it would be worth making the effort to separate the hiccup
rendering from the hiccup generation in these libraries.
By hiccup generation, I mean constructing data of the form [:tag {:attr
val} contents] ...
By rendering, I mean
in the case of hiccup - producing HTML strings
in the case of crate - directly producing DOM nodes in the browser
My thought is that this would give a generic set of hiccup data generating
functions that could be easily used across both libs with rendering
specific to the environment.
I don't generally use the libs in hiccup or crate because they are not
portable and slightly inconsistent in places - all my hiccup data
generation code can run on the server or on the browser. It might be good
to have a core unified set for both...
thoughts?
Dave
--
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: Can I safely put that Clojure will Primarily remain a JVM language in the future as it is now?
When I asked my close friend, he answered that till there's a *j* in clo*j*ure, stay calm. Thank you all again. On Sunday, November 25, 2012 3:45:01 PM UTC+5:30, Leon Adler wrote: Thanks Andy. I will do that. :) Thank you all. Andy Fingerhut wrote: On Nov 24, 2012, at 9:24 PM, Leon Adler wrote: This post was not meant for any queries on the release schedules of the various Clojure versions, but for a curious question -- Will Clojure (take all the upcomming versions back-to-back) remain to be known as the JVM language anytime in the future?. You can say, that this question arises from curiosity :), but there is more. Lets' take Scala (scala runs on CLR too, but is still known as the JVM language, and it seems, will remain so) or Groovy. Nobody assured me about their future, but somewhere I know, that they will remain to be developed as the ''JVM languages''. Can I put Clojure in their league? Leon: Here is a suggestion. Take the mental process by which you did this: Nobody assured me about their future, but somewhere I know, that they will remain to be developed as the JVM languages.' Do a replacement of the words Scala and Groovy with Clojure in that mental process, and Bob's your uncle. Somehow I just know that this will work. Andy -- 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] sublime-lispindent, clojure indenting for sublime text 2
On 2012-11-25, at 12:45 AM, Anthony Grimes disciplera...@gmail.com wrote: I just took a shot at it. I put it in Pristine Packages as described, but it disappears when I restart ST2 and try to use it. I imagine you tried to put it in: ~/Library/Application Support/Sublime Text 2/Pristine Packages I did that too. You need to put it in: /Applications/Sublime Text 2.app/Contents/MacOS/Pristine Packages Cheers, Bob Also, will this work with the built in 'reindent' command? If not, will it work with vintage mode (you can reindent blocks with =ab from Vim)? I really wish the Clojure mode just didn't suck so bad. On Monday, November 12, 2012 10:25:38 AM UTC-6, Jonathan Fischer Friberg wrote: Dear clojure mailing list, As the indenting for clojure (and lisp in general) was very lacking in sublime, I decided to make a plugin: https://github.com/odyssomay/sublime-lispindent I hope someone finds this useful. By the way, if someone with a mac could try the keyboard shortcuts that would be great. I don't own a mac so I cannot test them. Sincerely, Jonathan -- 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: [ANN] sublime-lispindent, clojure indenting for sublime text 2
I didn't realize that the install looks completely different on mac. Sorry! In any case, I have sent a request to include it into the sublime package control. That should make it much easier to install. :) *Also, will this work with the built in 'reindent' command? If not, will it work with vintage mode (you can reindent blocks with =ab from Vim)? * No, lispindent does not actually override the indenting command. You can however override key bindings. For example, lispindent overrides the enter key binding. -- 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: a question for crate and hiccup
Strong +1
This is a great idea.
This would allow more flexibility in some corner cases and
prevent unnecessary duplication, not to mention sharing.
Another example: I believe crate compiles templates using the DOM API,
which is often fine, but sometimes you'd want it to do this using raw
strings (when working with a large number of Elements), for performance
reason. This would help to solve such issues.
Max
On Sunday, November 25, 2012 12:11:09 PM UTC+1, Dave Sann wrote:
I wonder if it would be worth making the effort to separate the hiccup
rendering from the hiccup generation in these libraries.
By hiccup generation, I mean constructing data of the form [:tag {:attr
val} contents] ...
By rendering, I mean
in the case of hiccup - producing HTML strings
in the case of crate - directly producing DOM nodes in the browser
My thought is that this would give a generic set of hiccup data generating
functions that could be easily used across both libs with rendering
specific to the environment.
I don't generally use the libs in hiccup or crate because they are not
portable and slightly inconsistent in places - all my hiccup data
generation code can run on the server or on the browser. It might be good
to have a core unified set for both...
thoughts?
Dave
--
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: a question for crate and hiccup
+1 for sure! I dug into Crate a while ago specifically to see if I could
generate strings instead of DOM objects, and was unable to untangle the
parsing from the output. This would be very useful.
On Sun, Nov 25, 2012 at 12:51 PM, Max Penet m...@qbits.cc wrote:
Strong +1
This is a great idea.
This would allow more flexibility in some corner cases and
prevent unnecessary duplication, not to mention sharing.
Another example: I believe crate compiles templates using the DOM API,
which is often fine, but sometimes you'd want it to do this using raw
strings (when working with a large number of Elements), for performance
reason. This would help to solve such issues.
Max
On Sunday, November 25, 2012 12:11:09 PM UTC+1, Dave Sann wrote:
I wonder if it would be worth making the effort to separate the hiccup
rendering from the hiccup generation in these libraries.
By hiccup generation, I mean constructing data of the form [:tag {:attr
val} contents] ...
By rendering, I mean
in the case of hiccup - producing HTML strings
in the case of crate - directly producing DOM nodes in the browser
My thought is that this would give a generic set of hiccup data
generating functions that could be easily used across both libs with
rendering specific to the environment.
I don't generally use the libs in hiccup or crate because they are not
portable and slightly inconsistent in places - all my hiccup data
generation code can run on the server or on the browser. It might be good
to have a core unified set for both...
thoughts?
Dave
--
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
help choosing dev environment for clojure
hello -- There are a few resources out there to help one getting started with emacs+clojure, eclipse+ccw, etc. but I haven't found so far a resource helping me decide which learning curve to climb: the pros and cons of sweating to learn eclipse/ccw versus sweating learning the emacs ecosystem, etc. In making that choice, my priority is an environment that complements the REPL with a debugger that allows me to step through the execution, peek at values at intermediate stages of the computation, evaluate expressions within that intermediate stage, etc. Given that, does anybody have advice for a newcomer? thanks in advance -- hoping this doesn't initiate a holy-war-of-IDEs... -- 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: help choosing dev environment for clojure
I spent 3 years doing Clojure (for prod apps) in IntelliJ. 3 months ago I switched to emacs - and would never go back. If the idea of customizing your dev environment to automate repetitive tasks is appealing to you, start learning emacs immediately. I deeply regret not learning emacs earlier. If you just want to get things done and don't care too much about your development env, stick with eclipse or IntelliJ. Sent from my iPad On Nov 25, 2012, at 8:39 AM, Sol Tourne artists...@yahoo.com wrote: hello -- There are a few resources out there to help one getting started with emacs+clojure, eclipse+ccw, etc. but I haven't found so far a resource helping me decide which learning curve to climb: the pros and cons of sweating to learn eclipse/ccw versus sweating learning the emacs ecosystem, etc. In making that choice, my priority is an environment that complements the REPL with a debugger that allows me to step through the execution, peek at values at intermediate stages of the computation, evaluate expressions within that intermediate stage, etc. Given that, does anybody have advice for a newcomer? thanks in advance -- hoping this doesn't initiate a holy-war-of-IDEs... -- 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: help choosing dev environment for clojure
can you give a few examples that should convince a lot of people on the spot? Am 25.11.2012 17:57, schrieb Jay Fields: I spent 3 years doing Clojure (for prod apps) in IntelliJ. 3 months ago I switched to emacs - and would never go back. If the idea of customizing your dev environment to automate repetitive tasks is appealing to you, start learning emacs immediately. I deeply regret not learning emacs earlier. If you just want to get things done and don't care too much about your development env, stick with eclipse or IntelliJ. Sent from my iPad On Nov 25, 2012, at 8:39 AM, Sol Tourne artists...@yahoo.com mailto:artists...@yahoo.com wrote: hello -- There are a few resources out there to help one getting started with emacs+clojure, eclipse+ccw, etc. but I haven't found so far a resource helping me decide which learning curve to climb: the pros and cons of sweating to learn eclipse/ccw versus sweating learning the emacs ecosystem, etc. In making that choice, my priority is an environment that complements the REPL with a debugger that allows me to step through the execution, peek at values at intermediate stages of the computation, evaluate expressions within that intermediate stage, etc. Given that, does anybody have advice for a newcomer? thanks in advance -- hoping this doesn't initiate a holy-war-of-IDEs... -- 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 mailto: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 mailto: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 -- -- 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: help choosing dev environment for clojure
On Nov 25, 2012 5:41 PM, Sol Tourne artists...@yahoo.com wrote: hello -- There are a few resources out there to help one getting started with emacs+clojure, eclipse+ccw, etc. but I haven't found so far a resource helping me decide which learning curve to climb: the pros and cons of sweating to learn eclipse/ccw versus sweating learning the emacs ecosystem, etc. In making that choice, my priority is an environment that complements the REPL with a debugger that allows me to step through the execution, peek at values at intermediate stages of the computation, evaluate expressions within that intermediate stage, etc. Hello, In your list, the only thing you won't be able to do with Eclipse is executing clojure forms in the context of the breakpoint. Given that, does anybody have advice for a newcomer? My advice: don't try to learn too much at once. Eclipse+counterclockwise (and probably Intellij+La Clojure) lets you start right away hacking clojure. They are specifically designed to be newbie friendly Postpone the decision of becoming an emacs ninja to when you feel ok with clojure and you feel that you lack customization power (if ever). thanks in advance -- hoping this doesn't initiate a holy-war-of-IDEs... -- 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: clojurescript: ex-info and ex-data
Agreed. Patches welcome!
On Saturday, November 24, 2012, Dave Sann wrote:
Is there a plan to add these?
It seems like a step towards more generic exception handling between clj
and cljs code.
Dave
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clojure@googlegroups.comjavascript:_e({}, 'cvml',
'clojure@googlegroups.com');
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@googlegroups.com');
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To 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: help choosing dev environment for clojure
On Nov 25, 2012 6:47 PM, Jonathan Fischer Friberg odysso...@gmail.com wrote: Personally, I don't like using an integrated environment. I opt for an editor + terminal instead. Therefore, I have very limited knowledge about the things you are asking for (debugging, evaluating ...). Even so, I'll try to summarize the different environments below: emacs - The standard. Used by most. From what I understand, it offers the tightest integration with clojure. vim - similar to emacs. I don't know how the clojure integration stands feature wise against emacs, but my guess is that it's pretty similar. I think vim vs emacs depends mostly on which editor you prefer. Moving on... eclipse/netbeans - the standard big IDEs with clojure integration. eclipse supports lein as well as execution of whole files or smaller segments (and of course a repl). I'm not sure if netbeans supports lein, but at least it does support the other things. Personally, I prefer netbeans with clojure. However, it's not supported with the latest version of netbeans, so I haven't tested it in a while. jEdit - fairly standard text editor. Does offer a lot of customization (relative to other text editors), but not as much as emacs/vim. Sublime text 2 (sublime) - as jEdit but more polished (and has some really useful features that jEdit does not offer). They both offer some clojure integration. I have to admit that I haven't actually tested the integrations, but my impression is that they are not very mature. Overall, I think the most important part is what kind of dev environment you actually prefer. Want a ridiculously customizable editor? Use emacs or vim. Want a standard full-blown IDE? Use eclipse or netbeans. Want something closer to a standard text editor? Use jEdit or sublime. My choice falls on the more standard text editor, i.e jEdit or sublime. They are both easy to get in to (standard commands; ctrl-s to save ctrl-o to open, and so on), but at the same time has a lot of depth to them (i.e. they offer great capabilities for power users). But then again - the most important part is what kind of environment you prefer. Yeah, that is probably the final word : start with whatever you like/know most. Hope this helps! Jonathan On Sun, Nov 25, 2012 at 2:39 PM, Sol Tourne artists...@yahoo.com wrote: hello -- There are a few resources out there to help one getting started with emacs+clojure, eclipse+ccw, etc. but I haven't found so far a resource helping me decide which learning curve to climb: the pros and cons of sweating to learn eclipse/ccw versus sweating learning the emacs ecosystem, etc. In making that choice, my priority is an environment that complements the REPL with a debugger that allows me to step through the execution, peek at values at intermediate stages of the computation, evaluate expressions within that intermediate stage, etc. Given that, does anybody have advice for a newcomer? thanks in advance -- hoping this doesn't initiate a holy-war-of-IDEs... -- 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 -- 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
Design Drag And Drop in clojureScript
Hello, I am new to Clojure and Clojure Script. Beside the syntax, I am also trying to learn this new way of thinking. I was looking at clojure one and started playing with closure drag-and-drop. After I got my code working, I started thinking what is the best way to create an API for this in clojure taste. DND objects have a handful of methods and properties, so coming from an object oriented background, I would just make them objects and classes. But I don't think that is the way to do in clojure. Could you help me educated my self? thanks, -arash -- 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: help choosing dev environment for clojure
You could consider lighttable by chris granger as well. It is at a very early stage, but pretty much usable for hacking some clojure. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: help choosing dev environment for clojure
You could consider lighttable by chris granger as well. It is at a very early stage, but pretty much usable for hacking some clojure. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure expression benchmarks
Thanks for putting this together, Andy! It's great to have this data. -S -- 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: clj-schema, Schemas For Clojure Maps
Clj-schema is a library for defining and validating schemas for maps, as well as for using those schemas to create valid test data. We've been using this in production for at least a few months now, at Runa. https://github.com/runa-dev/clj-schema The main benefits I've found from using this library are: * validating the inputs to the application: validating Ring request params and config files * validating before storing maps into the DB * using the clj-schema.fixtures library to create valid test data that stays valid. So as the standard form of a map changes over time the tests will stay in sync with those changes automatically. * there are some code-readability benefits as well - any developer can pretty quickly see what certain kinds of maps tend to look like. There's more info in the README: https://github.com/runa-dev/clj-schema/blob/master/README.md Future possibilities: * auto-generating test data from clj-schema fixtures * being able to create schemas for sets and sequences (currently a schema is always for a map) Contributors welcome. Alex -- 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
REPL behavior different from running from a file
I'm trying to learn a bit about Clojure and it's concurrency features but I've hit an issue at an early point, where the same program exhibits different behavior if run within the REPL or from a regular file. This is the code I'm running: (def foo (atom 0)) (pmap (fn [_] (swap! foo inc)) (range 1)) (println @foo) When I run this inside the REPL, the (pmap ...) returns the whole sequence with 1 elements and the last line prints 1, as expected. But when I put this code in a file and run it as one of java -cp clojure-1.4.0.jar clojure.main swap.clj java -jar clojure-1.4.0-slim.jar swap.clj then it will output 32 and the program won't terminate, I have to hit CTRL+C to get control back to the console. Am I doing something wrong here? I'm running Clojure 1.4.0 with Java 1.6.0_21 in Windows. -- 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: REPL behavior different from running from a file
The won't terminate part is due to background threads being created by the call to pmap, and by default it will wait 60 seconds before exiting. If you don't wait that long, it definitely appears like it is hung. If you look on the ClojureDocs entry for pmap, the last example says to see the examples for future, which describe why this happens, and how you can avoid the 60-second wait by calling (shutdown-agents) at the end. http://clojuredocs.org/clojure_core/clojure.core/future At the REPL, realize that REPL stands for Read, Eval, Print, and Loop. Every expression you enter in the REPL is read, evaluated, *the result is printed*, and then loop (start over). When you put multiple expressions in a file, each expression is read and evaluated, but its result is not printed unless you ask for it. Because map and pmap are lazy, and nothing is done with its return value, it only evaluates part of the answer and then stops. If you print the result of the pmap, or wrap it in (dorun (pmap ...)) or (doall (pmap ...)), then you should get the same results when running it from a file as you get in the REPL. Andy On Nov 25, 2012, at 4:44 PM, Felipe Coelho wrote: I'm trying to learn a bit about Clojure and it's concurrency features but I've hit an issue at an early point, where the same program exhibits different behavior if run within the REPL or from a regular file. This is the code I'm running: (def foo (atom 0)) (pmap (fn [_] (swap! foo inc)) (range 1)) (println @foo) When I run this inside the REPL, the (pmap ...) returns the whole sequence with 1 elements and the last line prints 1, as expected. But when I put this code in a file and run it as one of java -cp clojure-1.4.0.jar clojure.main swap.clj java -jar clojure-1.4.0-slim.jar swap.clj then it will output 32 and the program won't terminate, I have to hit CTRL+C to get control back to the console. Am I doing something wrong here? I'm running Clojure 1.4.0 with Java 1.6.0_21 in Windows. -- 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: [ClojureScript] My implementation of ISeqable for NodeList doesn't work on Opera.
Shouldn't that be (.-length nl) ? Matt On Tuesday, January 10, 2012 7:25:29 AM UTC+10, Jozef Wagner wrote: Beware that NodeList is often a live collection, so it is probably a good idea to produce eager seq. I use this to convert it to seq: (defn nodelist-to-seq Converts nodelist to (not lazy) seq. [nl] (let [result-seq (map #(.item nl %) (range (.length nl)))] (doall result-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: a question for crate and hiccup
Another +1 (for those keeping score).
On 2012-11-25, at 9:01 AM, Murphy McMahon pande...@gmail.com wrote:
+1 for sure! I dug into Crate a while ago specifically to see if I could
generate strings instead of DOM objects, and was unable to untangle the
parsing from the output. This would be very useful.
On Sun, Nov 25, 2012 at 12:51 PM, Max Penet m...@qbits.cc wrote:
Strong +1
This is a great idea.
This would allow more flexibility in some corner cases and prevent
unnecessary duplication, not to mention sharing.
Another example: I believe crate compiles templates using the DOM API, which
is often fine, but sometimes you'd want it to do this using raw strings (when
working with a large number of Elements), for performance reason. This would
help to solve such issues.
Max
On Sunday, November 25, 2012 12:11:09 PM UTC+1, Dave Sann wrote:
I wonder if it would be worth making the effort to separate the hiccup
rendering from the hiccup generation in these libraries.
By hiccup generation, I mean constructing data of the form [:tag {:attr val}
contents] ...
By rendering, I mean
in the case of hiccup - producing HTML strings
in the case of crate - directly producing DOM nodes in the browser
My thought is that this would give a generic set of hiccup data generating
functions that could be easily used across both libs with rendering specific
to the environment.
I don't generally use the libs in hiccup or crate because they are not
portable and slightly inconsistent in places - all my hiccup data generation
code can run on the server or on the browser. It might be good to have a core
unified set for both...
thoughts?
Dave
--
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
--
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
