Re: Clojure + BDD + TDD + Pairing...
I can do it with you if we limit the hours to Saturday and sunday. I am a noob though i have 2 apps in production. (You can get alot done without knowing the whole of clojure) I am in GMT +3 Thanks. On Wed, Oct 30, 2013 at 6:43 AM, Marcus Blankenship mar...@creoagency.comwrote: Hi Folks, I’m a Clojure n00b, but am interested in finding another n00b who aspires to learn Clojure, and do so using BDD / TDD practices through regular pairing sessions. I’ve found novice - novice pairing to be a great way to ramp up on skills, but I don’t live near anyone who I can pair with. I’m thinking that doing 3 1-hour sessions a week, for a month, would give us a nice start. Obviously, this would be remote pairing via ScreenHero (or some other tool). Anyone interested? Best, Marcus marcus blankenship \\\ Partner, Problem Solver, Linear Thinker \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] modern-cljs - Tutorial 22
Thanks for putting this one together! I like that the tutorial series has a steady ramp up to complexity and nuance, it really turns it into a long term learning experience. On Tuesday, October 29, 2013 3:12:34 PM UTC-4, Magomimmo wrote: Hi all, I just published the 22th tutorial - Learn by Contributing (Part 3) - of the modern-cljs series. https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-22.md In this tutorial I introduced in the 'enfocus' lib what we learnt about the separation of concerns principle in previous tutorial and the I started implementing few CLJ/CLJS shared unit tests by using clojurescript.test lib by the great Chas and introducing again clix to make the unit tests sharable between CLJ and CLJS. In doing this stuff we'll run in few hidden bugs which are discover by adopting a unit test strategy which minimizes the pain of writing unit tests. Those bugs are then first correct by using the REPL and then ported into the codebase. I want to thanks a lot Creighton Kirkendall for the support he gave me during the last week while working on this tutorial and for being so open minded with me and my proposed improvements. HIH Mimmo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: eval-after-load
Hmm, well, it was a nice idea, but it fails, as the eval happens before the load. Can't quite work out why this is true, but it is. Far as I can tell, this requires Java level changes. Or I can provide support in the package. Shame. Phil Phillip Lord phillip.l...@newcastle.ac.uk writes: Well, yes, but it always does it and needs modification of the source. Anyway, I found a solution; requires usage of a private var, unfortunately, but it does work. (defn eval-after-load [library form] (let [key (keyword (str eval-after-load- library))] (add-watch (var-get #'clojure.core/*loaded-libs*) key (fn[key ref old new] (when (= library (first (clojure.set/difference new old))) (eval form library)) (eval-after-load 'bob '(println Hello Bob!)) Cedric Greevey cgree...@gmail.com writes: Doesn't simply putting some executable forms at the end of the namespace's source code do that? e.g. (ns foo ...) (defn ...) (def ...) (defn ...) ... (do-something!) On Mon, Oct 28, 2013 at 1:05 PM, Phillip Lord phillip.l...@newcastle.ac.ukwrote: I want to add some additional configuration after I have loaded a library. Is there anything equivalent to eval-after-load in emacs, which enables me to do something after a namespace has been loaded? Or a file? Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ClojureScript] Re: [ANN] modern-cljs - Tutorial 22
Thanks Boris. I'm glad you found it useful. That's the best ROI to me. I would like to have more time to add more tutorials quickly than I'm doing now to better serve this extraordinary community. Mimmo On Oct 30, 2013, at 8:40 AM, Boris Kourtoukov borisko...@gmail.com wrote: Thanks for putting this one together! I like that the tutorial series has a steady ramp up to complexity and nuance, it really turns it into a long term learning experience. On Tuesday, October 29, 2013 3:12:34 PM UTC-4, Magomimmo wrote: Hi all, I just published the 22th tutorial - Learn by Contributing (Part 3) - of the modern-cljs series. https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-22.md In this tutorial I introduced in the 'enfocus' lib what we learnt about the separation of concerns principle in previous tutorial and the I started implementing few CLJ/CLJS shared unit tests by using clojurescript.test lib by the great Chas and introducing again clix to make the unit tests sharable between CLJ and CLJS. In doing this stuff we'll run in few hidden bugs which are discover by adopting a unit test strategy which minimizes the pain of writing unit tests. Those bugs are then first correct by using the REPL and then ported into the codebase. I want to thanks a lot Creighton Kirkendall for the support he gave me during the last week while working on this tutorial and for being so open minded with me and my proposed improvements. HIH Mimmo -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
.length vs. count for string length
Which one is preferred? .length needs to be type hinted, so more verbose. The performance penalty of count is negligible in most cases. I think including len in clojure.string would be a good idea because it's used so often. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: .length vs. count for string length
What'd clojure.string/len do any differently than clojure.core/count? count already provides does the fastest possible thing for strings. ~BG On Wed, Oct 30, 2013 at 4:14 PM, Alice dofflt...@gmail.com wrote: Which one is preferred? .length needs to be type hinted, so more verbose. The performance penalty of count is negligible in most cases. I think including len in clojure.string would be a good idea because it's used so often. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
FWIW, I too am interested in a better SQL tool for Clojure, but my take on it is that we don't need a new language on top of SQL, but a better way to use SQL directly. My thinking, plus an *alpha-grade* library, can be found here: https://github.com/krisajenkins/yesql#rationale Cheers, Kris On Tuesday, 29 October 2013 16:35:45 UTC, ArturoH wrote: I am interested in writing a better SQL mapping tool for clojure. Because I am not convinced that simple SQL composition is effective, for various reasons. I rather have some kind of logic construct that I could use to generate SQL from. My main concern is to eliminate the hard boundary between the RDBMS and the rest of the code. Any given logic construct would a candidate to be translated into SQL or executed inside the JVM. One option that I have been considering is a production rule system. The most popular are based on the rete algorithm. I know there are a few open source productions systems out there, but I think translating into SQL from an established rule language may be too complicated. At this point I plan to use the language extensions proposed by Anurag Acharya, that eliminate sequential guards and adds collection support. The reason is that I want to process the rules in parallel, and I want to be as close to SQL as possible. Clojure pure functions could also be called from within a production rule. The use case I have in mind is regular IT apps, not necessarily complex decision systems. I just find myself writing too much code, and often an SQL a clojure procedure and a function in the GUI will have some aspect of the same business rule embedded in the code. A layered approach helps to alleviate the problem, but it still persists. More support for declarative code may be the answer. But other than SQL or LINQ and other minor examples, there is little support for declarative code for average IT systems. Anyone has any ideas/opinions? I would appreciate any feedback. Arturo Hernandez -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: .length vs. count for string length
count does some type checks, but it's negligible in most cases as I already said. len can give a clear intention than count somtimes. I'm not suggesting that it should be included in clojure.string, but if count is currently not preferred over .length, including it can be a good option. On Wednesday, October 30, 2013 7:50:04 PM UTC+9, Baishampayan Ghose wrote: What'd clojure.string/len do any differently than clojure.core/count? count already provides does the fastest possible thing for strings. ~BG On Wed, Oct 30, 2013 at 4:14 PM, Alice doff...@gmail.com javascript: wrote: Which one is preferred? .length needs to be type hinted, so more verbose. The performance penalty of count is negligible in most cases. I think including len in clojure.string would be a good idea because it's used so often. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: .length vs. count for string length
Strings are character sequences, count is a better option to stay within the sequence abstraction. Lic P. count does some type checks, but it's negligible in most cases as I already said. len can give a clear intention than count somtimes. I'm not suggesting that it should be included in clojure.string, but if count is currently not preferred over .length, including it can be a good option. On Wednesday, October 30, 2013 7:50:04 PM UTC+9, Baishampayan Ghose wrote: What'd clojure.string/len do any differently than clojure.core/count? count already provides does the fastest possible thing for strings. ~BG On Wed, Oct 30, 2013 at 4:14 PM, Alice doff...@gmail.com javascript: wrote: Which one is preferred? .length needs to be type hinted, so more verbose. The performance penalty of count is negligible in most cases. I think including len in clojure.string would be a good idea because it's used so often. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] The long awaited Dire 0.5.0 - Slingshot integration
This feature has been requested for a few months, and it's finally made its way into Dire. I'd like to thank Dylan Paris for sending in a patch to do this. The tl;dr: error handling can now dispatch based on predicates rather than types. Dire: https://github.com/MichaelDrogalis/dire Slingshot: https://github.com/scgilardi/slingshot Blog post: http://michaeldrogalis.tumblr.com/post/65520940178/dire-0-5-0-slingshot-integration -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
On 30 October 2013 11:47, Kris Jenkins krisajenk...@gmail.com wrote: FWIW, I too am interested in a better SQL tool for Clojure, but my take on it is that we don't need a new language on top of SQL, but a better way to use SQL directly. My thinking, plus an *alpha-grade* library, can be found here: https://github.com/krisajenkins/yesql#rationale Something similar I'm using in production on a couple of sites: https://github.com/ray1729/sql-phrasebook Ray. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Why isn't a docstring allowed for defrecord?
I understand that defrecord can't take a docstring (see Doc string for variables and record in this group), and I have learned that record types are somewhat odd beasts. I know that there are workarounds (http://clojure-log.n01se.net/date/2010-10-03.html). Still, I'm surprised. *Why* can't I document a record type with a docstring? It seems like extremely useful coding practice to provide a docstring for a type. Even if the underlying semantics would be weird and special-cased, well, that's already true for record types. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why isn't a docstring allowed for defrecord?
On 30/10/13 16:19, Mars0i wrote: Still, I'm surprised. /Why/ can't I document a record type with a docstring? of course you can...just add a :doc key in the record's meta :) 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why isn't a docstring allowed for defrecord?
Jim - FooBar(); jimpil1...@gmail.com writes: On 30/10/13 16:19, Mars0i wrote: Still, I'm surprised. /Why/ can't I document a record type with a docstring? of course you can...just add a :doc key in the record's meta :) The OP is correct. He says why can't I document a record type with a docstring, rather than why can't I add directly to the metadata of the symbol. Consistency is always good; in the ideal world all def* forms should have a docstring. Being able to do privacy (defn vs defn-) would be nice also. defmethod definterface defstruct deftype Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Incanter/vector-clj use error
On 30/10/13 16:56, P Martin wrote: Thanks - I'm still a little confused on the different between use and require. 'use' is sort of deprecated after it was noticed that people were abusing it. It's not exactly deprecated because in some cases like incremental development at the repl it is really usefyl to have. That said, 'require' can do everything 'use' can via :refer :all. so what I'm saying is the the following two are equivalent : (require '[clojure.tools.macro :refer :all]) (use '[clojure.tools.macro]) Now, in perhaps 8/10 cases you should not do any of that. The next guy that will look at your code will not have the slightest clue what external fns you're using. He literally has to manually inspect the entirity of that external namespace and figure out which ones you've actually used. A more informative way would be the following 2: (require '[clojure.tools.macro :as mac]) ;;if you're unsure of what you 'll end up using just alias it (require '[clojure.tools.macro :refer [name-with-attributes mexpand-all ]]) ;;if you know upfront what you need, specify it using the second you don't need an alias, but you've explicitly said here are the only vars i've used. Massive difference don't you agree? In the case of var-clash due to same name, just make sure you use aliases. That is if you want both vars with the same name. If you don't just overwrite the one or :exclude it via: (:refer-clojure :exclude [==]) ;;core.logic does this all the time When I try your suggestion for the matrix library, (require '(clojure.core.matrix :as mat)), I get: IllegalArgumentException Don't know how to create ISeq from: clojure.lang.Keyword clojure.lang.RT.seqFrom (RT.java:505) I'm really sorry about that...I'm pretty sure that works in a ns-declaration, I'm puzzled as to why it doesn't work here. In any case, a quoted vector (as shown above) does work just fine. It also looks nicer :) hope that helps, 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why isn't a docstring allowed for defrecord?
On 30/10/13 16:54, Phillip Lord wrote: Jim - FooBar(); jimpil1...@gmail.com writes: On 30/10/13 16:19, Mars0i wrote: Still, I'm surprised. /Why/ can't I document a record type with a docstring? of course you can...just add a :doc key in the record's meta :) The OP is correct. He says why can't I document a record type with a docstring, rather than why can't I add directly to the metadata of the symbol. Consistency is always good; in the ideal world all def* forms should have a docstring. Being able to do privacy (defn vs defn-) would be nice also. defmethod definterface defstruct deftype Phil Ok my bad...for a second there I thought that a defrecord expression returns a Var but it doesn't. It returns a Class object. You can't put anything on that therefore 'doc' won't work on it anyway. It is the instance of that Class that is able to take meta data. I concur that consistency is good to have. apologies for the rushed response. 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
how to turn on smartparens-strict-mode in emacs-live
Where should I place the setting to turn on smartparens-strict-mode in emacs-live? Following this thread, https://github.com/Fuco1/smartparens/issues/158 I tried adding this to my own pack but that did not work, subsequently added it to the clojure-pack under the smartparents-conf.el but that is not a good long term solution. Any suggestions? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] Clojure Support for the Intellij Sublime Theme
Hi, I have been using the Sublime Theme https://github.com/y3sh/Intellij-Colors-Sublime-Monokai for IntelliJ, however it doesnt play nice with clojure. So added support for clojure forms too, so that will not look ugly. Here is my fork which adds the support - https://github.com/murtaza52/Intellij-Colors-Sublime-Monokai Thanks, Murtaza -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Which Json parser can parse a complete jason string?
Hi I noticed jason parser such as Cheshire, data.json only parse one layer of json string. In order to get the whole object, I have to write a recursive method to do that. Is there a library can do it automatically? Thanks Gary -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Which Json parser can parse a complete jason string?
Cheshire should parse the whole JSON object. I haven't noticed any problem with it. What do you mean by one layer of json string? Could you provide an example? - James On 30 October 2013 21:36, Gary Zhao garyz...@gmail.com wrote: Hi I noticed jason parser such as Cheshire, data.json only parse one layer of json string. In order to get the whole object, I have to write a recursive method to do that. Is there a library can do it automatically? Thanks Gary -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
road map for clojure?
Hi, Is clojure under dev? there is no much commits in months, any plan or road map for clojure? thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What non-deprecated Clojure Web libraries to use?
A probably simplistic consideration: maybe there should be a data model expressed as a data structure so that it can be leveraged by arbitrary libs. This way there would be a single representation, but no explicit dependencies between single libs. Here probably Datomic could be an example. Il giorno mercoledì 30 ottobre 2013 01:12:25 UTC+1, Brian Craft ha scritto: In general, my point is that libraries don't compose if they have incompatible or hidden representations of the data structures over which they operate, which is the default condition if no one has thought about how the libraries might be used together. A consequence of this is that a framework is much, much greater than the sum of its parts. A dsl that can abstract away details of building queries (e.g. joins) requires a declared schema. In contrast, the clojure migration tools describe a schema as a series of functions, or sql string literals. It's hard to derive one from the other. You wouldn't want to start trying to parse the sql to deduce the schema, for instance. Consequently you end up repeating the schema. Then you add an administrative UI, and you have the same problem: the pages and forms for the admin depend on the schema. You end up repeating the schema a third time. And so forth. It quickly becomes unmanageable. For this case, migrations, it's easier to derive the sql for the migrations from a declared schema (doing a diff against the previous version) than the other way around (parsing sql to find the schema). This is how django-south works (it automatically generates the sql for the migrations, in most cases), but there's nothing like it for clojure that I'm aware of. Also, the sql dsls in clojure that I've seen cover very little of sql for data model creation, so you can't actually compose them with the migration tools as you suggest: they can't represent migrations. Having a declared schema also makes the code more maintainable. It can be bewildering to work on code where the schema is written as a series of alter table statements. Any non-trivial project will have a dozen or two boilerplate tables (users, sessions, settings, etc.). If they are all written as a series of alter table statements, there is a huge cognitive load just in figuring out what the tables are, and how they are related. On Tuesday, October 29, 2013 4:09:33 PM UTC-7, Chris Kuttruff wrote: Well things were kept separate intentionally. If someone wants to use Korma or some other DSL within their migrations, they can augment their migration file to use that to generate the SQL, but having the migrations set up such that instructions to jdbc are simple clojure strings is very intentional. This way I don't limit anyone's decision about what other libraries they use, but complicated migrations can easily be dynamically generated (since they are being picked up within the context of a clojure file). Not sure I fully understand your point, but this seems like a reasonable case for modularity. On Tuesday, October 29, 2013 8:49:55 AM UTC-7, Brian Craft wrote: On Monday, October 28, 2013 4:36:56 PM UTC-7, Chris Kuttruff wrote: Separate from DSLs like Korma, etc. I have written a simple library for doing database migrations with clojure (clj-sql-up ( https://github.com/ckuttruff/clj-sql-up )). There are also other libraries still maintained along these lines (drift, migratus, ragtime, etc.) It's unfortunate that these are separate, because you need the schema information not just for migrations, but also for query abstraction (sql dsl, etc.). The argument for small, composable libraries only works if they can actually be meaningfully composed: if, in this case, a declared schema can be used for migrations, and query abstraction, and administrative UI, and anything else that requires it. So far there's not much like this in clojure that I've found. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
If you just want to build up and apply constraints, Korma can do that. If you want something closer to Datalog with unification, then a Datalog to SQL bridge is the most practical of largely impractical choices. On Tuesday, October 29, 2013 9:35:45 AM UTC-7, ArturoH wrote: I am interested in writing a better SQL mapping tool for clojure. Because I am not convinced that simple SQL composition is effective, for various reasons. I rather have some kind of logic construct that I could use to generate SQL from. My main concern is to eliminate the hard boundary between the RDBMS and the rest of the code. Any given logic construct would a candidate to be translated into SQL or executed inside the JVM. One option that I have been considering is a production rule system. The most popular are based on the rete algorithm. I know there are a few open source productions systems out there, but I think translating into SQL from an established rule language may be too complicated. At this point I plan to use the language extensions proposed by Anurag Acharya, that eliminate sequential guards and adds collection support. The reason is that I want to process the rules in parallel, and I want to be as close to SQL as possible. Clojure pure functions could also be called from within a production rule. The use case I have in mind is regular IT apps, not necessarily complex decision systems. I just find myself writing too much code, and often an SQL a clojure procedure and a function in the GUI will have some aspect of the same business rule embedded in the code. A layered approach helps to alleviate the problem, but it still persists. More support for declarative code may be the answer. But other than SQL or LINQ and other minor examples, there is little support for declarative code for average IT systems. Anyone has any ideas/opinions? I would appreciate any feedback. Arturo Hernandez -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: road map for clojure?
Roadmap: http://dev.clojure.org/jira/browse/CLJ#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel On Wed, Oct 30, 2013 at 4:02 PM, julius wee@gmail.com wrote: Hi, Is clojure under dev? there is no much commits in months, any plan or road map for clojure? thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
On Wednesday, October 30, 2013 4:27:31 PM UTC-7, Christopher Allen wrote: If you just want to build up and apply constraints, Korma can do that. If you want something closer to Datalog with unification, then a Datalog to SQL bridge is the most practical of largely impractical choices. Are you aware of a Datalog - SQL implementation? I went looking for one about a year ago and could only find a paper on how one might achieve such a thing. I was hoping for a more out-of-the-box solution. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
I did that recently, as well. Found this: https://github.com/ghxiao/nrdatalog2sql Haven't done more than glance at the code. On Wednesday, October 30, 2013 4:29:33 PM UTC-7, Mark wrote: On Wednesday, October 30, 2013 4:27:31 PM UTC-7, Christopher Allen wrote: If you just want to build up and apply constraints, Korma can do that. If you want something closer to Datalog with unification, then a Datalog to SQL bridge is the most practical of largely impractical choices. Are you aware of a Datalog - SQL implementation? I went looking for one about a year ago and could only find a paper on how one might achieve such a thing. I was hoping for a more out-of-the-box solution. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
request for feedback
Hey everyone, I'm working on project called jarkeeper (https://github.com/hashobject/jarkeeper.com). It's a simple tool that may be helpful in few cases: 1. Can help you understand if some Clojure library uses latest dependencies (e.x. http://www.jarkeeper.com/korma/Korma) 2. Provides status of dependencies in your own Clojure projects. I'm curious if anyone founds this useful (because I'm thinking on adding more functionality). Appreciate any feedback. P.S. Most of the work is done inside https://github.com/xsc/ancient-clj library. Also there is similar project. Anton Podviaznikov -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any interest in Compojure/Ring screencasts?
And me. cheers Paddy On Wednesday, October 30, 2013 2:36:45 AM UTC, Yuan He wrote: Count me in too.. _ Best regards - Yuan blog http://blog.lenage.com/ github http://github.com/lenage On Wed, Oct 30, 2013 at 7:19 AM, Luc Prefontaine lprefo...@softaddicts.cajavascript: wrote: Count me in, Luc P. I'm considering putting together a screencast, or a series of screencasts, based on my Functional Web Architecturehttp://skillsmatter.com/podcast/home/functional-web talk. The base presentation would be improved, and I'd probably wind up going into more detail on certain topics. I'll probably charge a small fee (perhaps $10 or so) to cover costs. Would there be any interest in this? - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: road map for clojure?
Also a list of features planned for Clojure 1.6, and some that were postponed to after Clojure 1.6: http://dev.clojure.org/display/design/Release.Next+Planning Andy On Wed, Oct 30, 2013 at 4:29 PM, Sean Corfield seancorfi...@gmail.comwrote: Roadmap: http://dev.clojure.org/jira/browse/CLJ#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel On Wed, Oct 30, 2013 at 4:02 PM, julius wee@gmail.com wrote: Hi, Is clojure under dev? there is no much commits in months, any plan or road map for clojure? thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] collection-check: validation for data structure variants
It's relatively rare that people write variants of Clojure data structures. Partially, this is because the existing data structures are quite good, but it's also because it's surprisingly difficult. Clojure's vectors, sets, and maps each implement about a dozen interfaces with overlapping functionality, making it easy to think you've written something correct until someone accesses it in a way you didn't think to test. I have written a number of alternate data structures [1] [2] [3], and each time there's been some lacunae of the standard API that I overlooked. To make this easier for myself and others, I've written a library for the express purpose of validating data structures that are extensions of the standard three data structures: https://github.com/ztellman/collection-check. It's already uncovered some minor bugs in my own libraries, as well as an issue with Clojure's own hash-sets and hash-maps [4]. I strongly encourage anyone who's playing around in this space to use it, and to let me know if there are invariants I've overlooked. Enjoy, Zach [1] https://github.com/ztellman/clj-tuple [2] https://github.com/ztellman/immutable-bitset [3] https://github.com/ztellman/potemkin [4] https://groups.google.com/forum/#!topic/clojure-dev/HvppNjEH5Qc -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: road map for clojure?
Even looking at this repo, it's not many commits. I count around 50 commits in the last 6 months. By way of comparison, JRuby and Scala both have more than that in the last couple of weeks. P.S. Not intended as a criticism of anybody: just an observation. On Thursday, 31 October 2013 07:05:18 UTC+8, John Hume wrote: Are you looking at the right repo? https://github.com/clojure/clojure/commits/master On Wed, Oct 30, 2013 at 6:02 PM, julius wee...@gmail.com javascript:wrote: Hi, Is clojure under dev? there is no much commits in months, any plan or road map for clojure? thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: road map for clojure?
I'm not saying it puts the total number of commits up with other projects, or that it needs to, but the development of core.async has effectively been part of the core Clojure development work done in the last several months, and it has been moving along: https://github.com/clojure/core.async Andy On Wed, Oct 30, 2013 at 7:20 PM, Mikera mike.r.anderson...@gmail.comwrote: Even looking at this repo, it's not many commits. I count around 50 commits in the last 6 months. By way of comparison, JRuby and Scala both have more than that in the last couple of weeks. P.S. Not intended as a criticism of anybody: just an observation. On Thursday, 31 October 2013 07:05:18 UTC+8, John Hume wrote: Are you looking at the right repo? https://github.com/clojure/**clojure/commits/masterhttps://github.com/clojure/clojure/commits/master On Wed, Oct 30, 2013 at 6:02 PM, julius wee...@gmail.com wrote: Hi, Is clojure under dev? there is no much commits in months, any plan or road map for clojure? thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
On Wednesday, October 30, 2013 12:01:02 PM UTC-5, Brian Craft wrote On Wednesday, October 30, 2013 7:56:46 AM UTC-7, ArturoH wrote: I think the shortcoming of ORM tools is that they bring a higher level technology like SQL and lower it down to the low level of imperative languages. Can you give an example? In SQL you can nest statements use views, outer joins. Some new features include window functions. In a single SQL statement you can get a lot of functionality that would take many more lines of code in an imperative language. Plus the database has statistics on data distribution that is used to order the file access. Once your data makes it to the imperative language. The order of execution of for example, looping constructs, is hard-coded. And I could go on. I have to say ORM writers have done wonders with imperative languages. They are perfectly usable and in production in many places. I just want something even better. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
Christopher, thanks for the info. My hesitation with Datalog comes from the separation from database and general purpose code. In a way it has the same problem as SQL. Once you get your result set then you are on your own. Clojure is a fantastic language, but I'd like to extend that same logic model to the client. Usually performance is the culprit, if I need to issue several datalog queries to get data to the browser. Once on the browser I can't reuse the same rules. What I said is not all true. I could possibly use core.logic and reuse the rules. Then what is left is the difference between forward chaining and backward chaining. From what I can research the first is more data driven and the second is more goal oriented. My use case is general information systems, so I thought forward rules would be more appropriate. One other thing I did not know is that there are Datalog to SQL bridges that is good to know. On Wednesday, October 30, 2013 6:27:31 PM UTC-5, Christopher Allen wrote: If you just want to build up and apply constraints, Korma can do that. If you want something closer to Datalog with unification, then a Datalog to SQL bridge is the most practical of largely impractical choices. On Tuesday, October 29, 2013 9:35:45 AM UTC-7, ArturoH wrote: I am interested in writing a better SQL mapping tool for clojure. Because I am not convinced that simple SQL composition is effective, for various reasons. I rather have some kind of logic construct that I could use to generate SQL from. My main concern is to eliminate the hard boundary between the RDBMS and the rest of the code. Any given logic construct would a candidate to be translated into SQL or executed inside the JVM. One option that I have been considering is a production rule system. The most popular are based on the rete algorithm. I know there are a few open source productions systems out there, but I think translating into SQL from an established rule language may be too complicated. At this point I plan to use the language extensions proposed by Anurag Acharya, that eliminate sequential guards and adds collection support. The reason is that I want to process the rules in parallel, and I want to be as close to SQL as possible. Clojure pure functions could also be called from within a production rule. The use case I have in mind is regular IT apps, not necessarily complex decision systems. I just find myself writing too much code, and often an SQL a clojure procedure and a function in the GUI will have some aspect of the same business rule embedded in the code. A layered approach helps to alleviate the problem, but it still persists. More support for declarative code may be the answer. But other than SQL or LINQ and other minor examples, there is little support for declarative code for average IT systems. Anyone has any ideas/opinions? I would appreciate any feedback. Arturo Hernandez -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
On Wednesday, October 30, 2013 8:04:25 PM UTC-7, ArturoH wrote: On Wednesday, October 30, 2013 12:01:02 PM UTC-5, Brian Craft wrote On Wednesday, October 30, 2013 7:56:46 AM UTC-7, ArturoH wrote: I think the shortcoming of ORM tools is that they bring a higher level technology like SQL and lower it down to the low level of imperative languages. Can you give an example? In SQL you can nest statements use views, outer joins. Some new features include window functions. In a single SQL statement you can get a lot of functionality that would take many more lines of code in an imperative language. Plus the database has statistics on data distribution that is used to order the file access. Once your data makes it to the imperative language. The order of execution of for example, looping constructs, is hard-coded. And I could go on. I have to say ORM writers have done wonders with imperative languages. They are perfectly usable and in production in many places. I just want something even better. My experience with ORMs is that they make these things more declarative, not more imperative. For example, sql requires a lot of low-level information in how to perform a query: which tables to join, which fields to join on, what order to join, whether to do a join or a subselect, etc., etc., etc. The ORMs instead present a more declarative API, like user.address.city, abstracting all the low-level details of following relations. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: SQL to logic rule mapping
On Wednesday, October 30, 2013 8:37:51 PM UTC-7, ArturoH wrote: One other thing I did not know is that there are Datalog to SQL bridges that is good to know. That python script is the only one I've found. I'd be curious to hear of any others. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] collection-check: validation for data structure variants
Thanks Zach for this cool testing library, and thanks Reid for simple-check! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Resources for learning techniques for isolating pure functions
Clojure is the first functional programming language I've used for anything more than toy examples, so I'm learning functional programming in general as well as Clojure specifically. I understand the value of creating pure functions in theory, but when writing applications, I'm finding that logic and IO are getting hopelessly entangled. Specifically, in my web application, there is interaction with the DB on most requests. The interaction may be quite complicated: e.g. first get some user data, inspect it, and then make more DB calls if a user is allowed to view some resource. Does anyone know of any books or articles on structuring functional code to separate pure and impure functions? Or other resources? Projects that are good examples? Although I've found good resources on writing pure functions and good resources on using Clojure IO libraries, I haven't yet found anything that talks about architectures that let you cleanly integrate the two in real-world projects. Thanks, Ben -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] collection-check: validation for data structure variants
This looks like a really useful library, but I mostly came here to say +1 for the use of lacunae. Now I have to find a way to insert that into my own conversations. On 31 October 2013 15:13, Zach Tellman ztell...@gmail.com wrote: It's relatively rare that people write variants of Clojure data structures. Partially, this is because the existing data structures are quite good, but it's also because it's surprisingly difficult. Clojure's vectors, sets, and maps each implement about a dozen interfaces with overlapping functionality, making it easy to think you've written something correct until someone accesses it in a way you didn't think to test. I have written a number of alternate data structures [1] [2] [3], and each time there's been some lacunae of the standard API that I overlooked. To make this easier for myself and others, I've written a library for the express purpose of validating data structures that are extensions of the standard three data structures: https://github.com/ztellman/collection-check. It's already uncovered some minor bugs in my own libraries, as well as an issue with Clojure's own hash-sets and hash-maps [4]. I strongly encourage anyone who's playing around in this space to use it, and to let me know if there are invariants I've overlooked. Enjoy, Zach [1] https://github.com/ztellman/clj-tuple [2] https://github.com/ztellman/immutable-bitset [3] https://github.com/ztellman/potemkin [4] https://groups.google.com/forum/#!topic/clojure-dev/HvppNjEH5Qc -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
