Re: Google+ community
Well, thanks @dspiteself for bringing up the topic. I like the interaction at G+ and joined the larger G+ Clojure community as a result of this thread. On Sunday, January 6, 2013 3:51:26 AM UTC+6, dspiteself wrote: Thanks I am surprised I did not see it when I created it a week or 2 ago. I deleted it so we can congregate at one. On Saturday, January 5, 2013 2:17:43 PM UTC-6, JM Ibanez wrote: FWIW, there's already this existing Clojure community: https://plus.google.com/u/0/communities/103410768849046117338 -- JM Ibanez jmib...@gmail.com http://jmibanez.com/ Sent with Sparrow http://www.sparrowmailapp.com On Sunday, January 6, 2013 at 4:15 AM, dspiteself wrote: I started a google plus communityhttps://plus.google.com/u/0/communities/102842407348588249223. I know most of the Clojure community is generally more into twitter, but I have been enjoying Google+ communities very much. It could be a great more externally visible venue for some of the conversation that happen on google groups. It also has the effect off make your search results of people and people in your circles and communities show up higher. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To 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 Conj Videos
You are right Alex. I got it mixed up since I've been waiting for both the Strange Loop and the Clojure Conj talks on InfoQ. On Sunday, January 6, 2013 7:29:15 AM UTC+6, Alex Miller wrote: Barski hasn't spoken at Strange Loop, perhaps you mean his talk at the conj? On Friday, January 4, 2013 3:30:55 AM UTC-6, kinleyd wrote: Thanks for taking the trouble Alex - that was pretty comprehensive. I've seen Rathore's and Nolen's (both excellent), skipped Stokke's (but only because Catnip didn't interest me) and was looking forward to Barski (but don't see him on the horizon though his talk was delivered a while back). I will now go through the others that you have listed. On Friday, January 4, 2013 9:45:06 AM UTC+6, Alex Miller wrote: The full Strange Loop video schedule is here: https://thestrangeloop.com/news/strange-loop-2012-video-schedule Re Clojure talks, Already released related in some way to Clojure and ClojureScript: - Nathan Marz on big data - http://www.infoq.com/presentations/Complexity-Big-Data - Jim Weirich on Y Combinator - http://www.infoq.com/presentations/Y-Combinator - Chris Granger on Light Table - http://www.infoq.com/presentations/Learn-Tools - David Nolen on ClojureScript - http://www.infoq.com/presentations/ClojureScript-Optimizations - Amit Rathore on Clojure+Datomic+Storm - http://www.infoq.com/presentations/Zolodeck - Bodil Stokke on Catnip IDE and ClojureScript - http://www.infoq.com/presentations/Catnip Still to be released: - Jason Wolfe's talk on the Prismatic Graph library is coming out week of Jan 28th - Kevin Lynagh's talk on his ClojureScript visualization lib is week of Feb 11th - Rich Hickey's talk is scheduled for week of Mar 18th but same one has already been released on InfoQ so not sure if they'll re-release it - Stuart Sierra's talk on functional design patterns is week of Apr 1st Sorry if I missed any. Alex On Thursday, January 3, 2013 2:43:39 AM UTC-6, kinleyd wrote: I've been waiting forever for the recent Strange Loop Clojure talks to be made available as well. So far I've only seen two, Amit Rathore's Clojure + Datomic + Stomr = Zolodeck and David Nolen's ClojureScript - Better semantics at low, low prices on InfoQ. Any one have any idea when the others will be made available? On Thursday, January 3, 2013 2:26:18 PM UTC+6, CA wrote: Let the party begin :-) On Thursday, January 3, 2013 2:02:41 AM UTC+1, Lynn Grogan wrote: Confreaks is just completing the final edits on the videos and we should be releasing them soon (in a week or so?). Of course, it will probably be a staggered release just to drive everyone crazy ;) Lynn Grogan Relevance On Wednesday, January 2, 2013 7:12:03 PM UTC-5, Sean Corfield wrote: On Wed, Jan 2, 2013 at 3:42 PM, Mark Derricutt ma...@talios.com wrote: +1 - I'm sure I've even seen any BLOGS on this years Conj let alone videos. http://corfield.org/blog/post.cfm/clojure-conj-2012 -- 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
Upcoming London Clojurian Events
Roll up! Roll up! We have 2 Clojure events coming up in the next 7 days here are the details! - Bodil Stokke and ClojureScript all the way down Thursday 10 January at Skills Matter 18:30 http://skillsmatter.com/event/scala/clojurescript-all-the-way-down Node.js is really hip these days. Of course, a barrier to adoption for any sensible programmer is the fact that while the opportunities it provides for network programming are shiny and brilliant, it expects you to write your code in Javascript, a language born with so many design flaws it makes you pine for the halcyon days of COBOL. - Clojure Hammock Weekend Sunday 13 January at Forward Technology 10:00 - 22:00 http://clojure-hammock-weekend.eventbrite.com/ Tommy Hall says: quote I just competed in the Node Knockout and while I quite like Node I prefer clojure and was thinking of doing something similar. The format of a sleep deprived weekend cranking out a webapp does not feel a good fit for the clojure culture, which seems to me a bit more mature and reflective so I thought the following might be fun. Fri: Meet for dinner with you team to discuss ideas. Go to sleep early (and not too drunk) Sat: Go for a walk somewhere nice as a team to discuss. Eat nice food, sleep early (in a hammock maybe, again not too drunk) Sun: For some of the hours between 10am and 10pm, build something. A library, a webapp, whatever you like. The contest will be judged by the contestants, I'll build some sort of voting app beforehand. quote I hope to see you all there or at the other 5 clojure events coming up in the next 32 days! cheers, Bruce -- @otfrom | CTO co-founder @MastodonC | mastodonc.com See recent coverage of us in the Economist http://econ.st/WeTd2i and the Financial Times http://on.ft.com/T154BA -- 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-javafx 0.2
Hi, I released the version 0.2 of clj-javafx. You can find it here: https://github.com/chrix75/clj-javafx/tree/clj-javafx/0.2 As a reminder, this project helps you out to use JavaFX with Clojure. You have information about this project in the Wiki pages. Chris -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
core.match gotcha
I've recently started using core.match, which has been quite pleasant and successful; thank you to David Nolen, and all others that have contributed. The only hiccup I've had has been around how core.match incorporates bindings from local scope into pattern rows. A stupid example demonstrating the (potential) confusion: = (match [[:k]] [[x]] x) :k vs. = (let [x 12] (match [[:k]] [[x]] x)) nil I was assuming that bindings established by the wildcards in pattern rows shadowed any other local bindings. It took me a while to realize that, e.g. in the example above, `x` was being interpolated into `[[x]]` to yield a pattern row of `[[12]]`. Now that I know that, all's well; but, it took me perhaps longer than it should have to figure it out. All this is to say, perhaps a relevant note in the (really excellent) overview wiki page[1] might be helpful. Thanks, - Chas [1] https://github.com/clojure/core.match/wiki/Overview -- 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: core.match gotcha
On Jan 6, 2013, at 10:48 AM, Ambrose Bonnaire-Sergeant wrote: On a related note, combining a quoted symbol and a named wildcard pattern seems to be buggy. clojure.core.match= (match 'my-sym a a) #CompilerException java.lang.RuntimeException: Unable to resolve symbol: ocr-3612 in this context, compiling:(REPL:79) clojure.core.match= (macroexpand-1 '(match 'my-sym a a)) (clojure.core/let [a ocr-3620] a) Yeah, I've hit that, but presumed I was just doing something wrong. :-) I included a section on how symbols work as patterns. Perfect, reads very well. I'm glad I didn't just add something, it would not have been as clear or succinct. Interestingly, the old design page still has some good stuff, including an explanation of this particular issue. I'm not sure how much is still relevant. https://github.com/clojure/core.match/wiki/Design-Wiki Ach, I hadn't thought to look at what else might be lurking in the wiki! The 'Local Bindings' section on the design page would have made it all obvious. Thanks! - Chas -- 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
Extracting map values matching a pattern
I have a web handler which will take any number of parameters beginning with 'q' and a number, like 'q1', 'q2', etc. I want to iterate and operate on just those parameters. My first thought is to simply iterate the web parameter map, and convert each key to a string using NAME and then a regex on the name. Is there a better way? -- 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: Extracting map values matching a pattern
On Jan 6, 2013 1:55 PM, Jonathon McKitrick jmckitr...@gmail.com wrote: My first thought is to simply iterate the web parameter map, and convert each key to a string using NAME and then a regex on the name. Is there a better way? If the numeric range may not be contiguous or start at 0 or 1, and you do not need to process them in numeric order, your suggested approach is fine. -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. -- 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
Copying (immigrating) macros from namespace to namespace
I have come up with a solution to a problem I don't think exists outside of my mind, but since I can't for the life of me figure out how Clojure 'wants' me to do this, I thought I would bounce this off the Google Group. *The scenario:* I am trying to collect a bunch of functions and macros from all the different namespaces in my library into a single namespace; let's call the namespace adams-lib.api. The idea is that the consumer of the library will only have to include that one API namespace, and not all of the little namespaces with parts of the functionality. *The problem:* Obviously, calling (use) doesn't cut it, because the aliased vars are not immigrated by subsequent calls to the (use) of the namespace that (used) them. You know what I mean. *The solution: *For functions this is simpler, but macros pose some additional challenges, which is why I'm including my solution for immigrating macros. Hold on to your hats, this one is ugly: (defmacro immigrate-macro [ns-sym macro-sym] `(let [ nspublics# (ns-publics '~ns-sym) macro-var# (nspublics# '~macro-sym) macro-fn# @macro-var# macro-meta# (meta macro-var#)] (def ~macro-sym macro-fn#) (. (var ~macro-sym) (setMacro)) (reset-meta! (var ~macro-sym) macro-meta#)) nil) And using it: (immigrate-macro adams-lib.some-other-ns some-macro) There has got to be a simpler/better/less insane way of doing this. Would anyone care to weigh in? For the record, I fully realize that my solution is not OK. -Adam -- 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: core.match gotcha
On Jan 6, 10:48 am, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: On a related note, combining a quoted symbol and a named wildcard pattern seems to be buggy. clojure.core.match= (match 'my-sym a a) #CompilerException java.lang.RuntimeException: Unable to resolve symbol: ocr-3612 in this context, compiling:(REPL:79) clojure.core.match= (macroexpand-1 '(match 'my-sym a a)) (clojure.core/let [a ocr-3620] a) Ticket opened here FWIW: http://dev.clojure.org/jira/browse/MATCH-66 - Chas -- 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: Copying (immigrating) macros from namespace to namespace
Here's what I use to pull symbols from Enlive into FW/1: (def ^:private enlive-symbols ['append 'at 'clone-for 'content 'do- 'html-content 'prepend 'remove-class 'set-attr 'substitute]) (defmacro enlive-alias ^:private [sym] `(let [enlive-sym# (resolve (symbol (str html/ ~sym)))] (intern *ns* (with-meta ~sym (meta enlive-sym#)) (deref enlive-sym# This pulls in both functions and macros. It hard-codes the alias for Enlive (html, for net.cgrand.enlive-html) but otherwise should serve your needs. FW/1 uses it like this: (doseq [sym enlive-symbols] (enlive-alias sym)) Sean On Sun, Jan 6, 2013 at 12:19 PM, the80srobot a...@ingenious.cz wrote: I have come up with a solution to a problem I don't think exists outside of my mind, but since I can't for the life of me figure out how Clojure 'wants' me to do this, I thought I would bounce this off the Google Group. The scenario: I am trying to collect a bunch of functions and macros from all the different namespaces in my library into a single namespace; let's call the namespace adams-lib.api. The idea is that the consumer of the library will only have to include that one API namespace, and not all of the little namespaces with parts of the functionality. The problem: Obviously, calling (use) doesn't cut it, because the aliased vars are not immigrated by subsequent calls to the (use) of the namespace that (used) them. You know what I mean. The solution: For functions this is simpler, but macros pose some additional challenges, which is why I'm including my solution for immigrating macros. Hold on to your hats, this one is ugly: (defmacro immigrate-macro [ns-sym macro-sym] `(let [ nspublics# (ns-publics '~ns-sym) macro-var# (nspublics# '~macro-sym) macro-fn# @macro-var# macro-meta# (meta macro-var#)] (def ~macro-sym macro-fn#) (. (var ~macro-sym) (setMacro)) (reset-meta! (var ~macro-sym) macro-meta#)) nil) And using it: (immigrate-macro adams-lib.some-other-ns some-macro) There has got to be a simpler/better/less insane way of doing this. Would anyone care to weigh in? For the record, I fully realize that my solution is not OK. -Adam -- 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 -- 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
Suggestion: add `into` on clojure.org/data_structures page
I noticed that `into` is not currently mentioned on http://clojure.org/data_structures How do community-suggested documentation changes work? Is there a wiki? Auto-generated docs from source? Thanks, David -- 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: Suggestion: add `into` on clojure.org/data_structures page
For most of the documentation on clojure.org, only a few people have authorization to modify it. You could create a JIRA ticket suggesting a change here: http://dev.clojure.org/jira/browse/CLJ Such tickets can take anywhere from a few days to many months before someone acts upon them, depending upon the severity of the issue. I'm not sure if you were looking for the info below, but here are some other sources of Clojure documentation: http://clojure-doc.org takes pull requests on github from anyone wanting to make changes to it. http://clojuredocs.org lets anyone with a free-and-quick-to-create account add examples or edit existing ones, add see also links, etc. There are auto-generated docs from source by going to clojure.org, clicking Documentation, then API Documentation. That is hosted on github, too. http://clojure.org/cheatsheet has one way of organizing Clojure symbols. By clicking the link Download other versions with tooltips near the top of that page, you can find versions of the cheatsheet that show the documentation of the symbols when you hover your mouse over them. Andy On Jan 6, 2013, at 2:10 PM, David James wrote: I noticed that `into` is not currently mentioned on http://clojure.org/data_structures How do community-suggested documentation changes work? Is there a wiki? Auto-generated docs from source? Thanks, David -- 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: Suggestion: add `into` on clojure.org/data_structures page
And there's also the excellent http://clojureatlas.com for exploring concepts and their implementations within the Clojure ecosystem. On Sun, Jan 6, 2013 at 3:08 PM, Andy Fingerhut andy.finger...@gmail.com wrote: For most of the documentation on clojure.org, only a few people have authorization to modify it. You could create a JIRA ticket suggesting a change here: http://dev.clojure.org/jira/browse/CLJ Such tickets can take anywhere from a few days to many months before someone acts upon them, depending upon the severity of the issue. I'm not sure if you were looking for the info below, but here are some other sources of Clojure documentation: http://clojure-doc.org takes pull requests on github from anyone wanting to make changes to it. http://clojuredocs.org lets anyone with a free-and-quick-to-create account add examples or edit existing ones, add see also links, etc. There are auto-generated docs from source by going to clojure.org, clicking Documentation, then API Documentation. That is hosted on github, too. http://clojure.org/cheatsheet has one way of organizing Clojure symbols. By clicking the link Download other versions with tooltips near the top of that page, you can find versions of the cheatsheet that show the documentation of the symbols when you hover your mouse over them. Andy On Jan 6, 2013, at 2:10 PM, David James wrote: I noticed that `into` is not currently mentioned on http://clojure.org/data_structures How do community-suggested documentation changes work? Is there a wiki? Auto-generated docs from source? Thanks, David -- 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 -- 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
Clojure/Script pr-str/read-string roundtrip differences
Hey,
I'm writing a Clojure Webapp with a CLJS Frontend and expected to be able
to cljs.reader/read-string everything I pr-str'd on the CLJ side. That
however does not work for defrecords and BigDecimals (1.1M) .
1. defrecord
In CLJ I can:
(ns dummy)
(defrecord Foo [bar])
(pr-str (Foo. 1)) ; = #dummy.Foo{:bar 1}
in CLJS however this will print as
#Foo{:bar 1}
missing the Namespace. I found an old
posthttps://groups.google.com/d/msg/clojure/YSkPd4zQTKQ/757Wd4Ex8pAJabout
this but no other information.
Also when I pr-str this record in CLJ and cljs.reader/read-string it in
CLJS it fails with Could not find tag parser for dummy.Foo in (inst
uuid queue) , although the defrecord exists and is in the same ns
(actually a cljsbuild crossover). I figured out that I can
(cljs.reader/register-tag-parser! 'dummy.Foo make-foo) but thats seems
faulty. I read about EDN and understand why the reader would think its
reading a Tag but I can do read-string in CLJ just fine. Shouldnt both
sides be equal here?
2. BigDecimals:
I understand that JavaScript has no BigDecimals and I can live with
js/parseFloat on the Client for now, however is there any way I can hint
the CLJS printer to print 1.1 as 1.1M?
On the Topic of EDN: How would I tag a value in CLJ(S) to print {:foo
bar} as #my/tag {:foo bar}? The docs only talk about data_readers.clj.
The answers probably lie in the sources, but I hope somebody here has a
quick answer. ;)
Cheers,
/thomas
PS: I'd actually prefer using tagged literals instead of the defrecord
constructor form since I dont trust anything coming from the client even it
looks like clojure data. Is there some protocol I can implement for the
record and have it print as tagged instead? For CLJ and CLJS? :)
--
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: Copying (immigrating) macros from namespace to namespace
On Jan 6, 2013, at 3:34 PM, Sean Corfield seancorfi...@gmail.com wrote: Here's what I use to pull symbols from Enlive into FW/1: Midje plays similar tricks to make namespace abilities available via one `use`. Which makes me think: 1: In the old patterns world, there was a rule of three which claimed that something shouldn't be published as a pattern until it could be demonstrated in three real systems. 2: Lispers like Gabriel and others noted that what were patterns in languages like Smalltalk and C++ were built into Lisp or were easily regularized in-language with macros. Therefore: to me, this email thread suggests that the ability to do such consolidation should be immortalized not in email examples of patterns (here's how I accomplished X) but - in a more Lispy fashion - by writing a common library and making it available to the user base. That is: functions like Adam's and Sean's and mine should be in some official library close to clojure.core. Occasional consulting on programming technique Contract programming in Ruby and Clojure Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- 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: Copying (immigrating) macros from namespace to namespace
+1 I was thinking of doing the same in the validation lib I published recently [1] and this thread came in handy. I haven't implemented it yet but having a common way in which people do this seems reasonable - if it's in core then all the better. Cheers, Leo [1] - https://github.com/leonardoborges/bouncer Leonardo Borges www.leonardoborges.com On Mon, Jan 7, 2013 at 12:04 PM, Brian Marick mar...@exampler.com wrote: On Jan 6, 2013, at 3:34 PM, Sean Corfield seancorfi...@gmail.com wrote: Here's what I use to pull symbols from Enlive into FW/1: Midje plays similar tricks to make namespace abilities available via one `use`. Which makes me think: 1: In the old patterns world, there was a rule of three which claimed that something shouldn't be published as a pattern until it could be demonstrated in three real systems. 2: Lispers like Gabriel and others noted that what were patterns in languages like Smalltalk and C++ were built into Lisp or were easily regularized in-language with macros. Therefore: to me, this email thread suggests that the ability to do such consolidation should be immortalized not in email examples of patterns (here's how I accomplished X) but - in a more Lispy fashion - by writing a common library and making it available to the user base. That is: functions like Adam's and Sean's and mine should be in some official library close to clojure.core. Occasional consulting on programming technique Contract programming in Ruby and Clojure Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- 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: Copying (immigrating) macros from namespace to namespace
I've said it before and I will keep saying it: copying symbols by interning vars breaks the identity of the original vars. It breaks dynamic binding, with-redefs, and the ability to redefine functions at the REPL. Clojure has a two perfectly good mechanisms for making vars available in other namespaces: 1. `refer`. Define a public function that `refer`s all the symbols you want. It's an extra step for the user, but that's good because it makes it evident that extra symbols are being added. 2. `load`. If you have N namespaces with no clashing symbols, then you only need one namespace. If you want to split it across multiple files, use `load`. `clojure.core` does this. -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
Re: Copying (immigrating) macros from namespace to namespace
On Mon, Jan 7, 2013 at 1:17 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: I've said it before and I will keep saying it: copying symbols by interning vars breaks the identity of the original vars. It breaks dynamic binding, with-redefs, and the ability to redefine functions at the REPL. Clojure has a two perfectly good mechanisms for making vars available in other namespaces: 1. `refer`. Define a public function that `refer`s all the symbols you want. It's an extra step for the user, but that's good because it makes it evident that extra symbols are being added. So this would be no different than having the user put an extra 'use' call to use any additional namespaces right? In this case I'd rather have the user explicitly perform the use call instead of refer, like this: (require '[bouncer.core :as b]) (use '[bouncer.validators :only [defvalidator]) Which is what I recommend at the moment. 2. `load`. If you have N namespaces with no clashing symbols, then you only need one namespace. If you want to split it across multiple files, use `load`. `clojure.core` does this. This sounds like what I want. I'll look into it, thanks. Leo. -- 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: Copying (immigrating) macros from namespace to namespace
On Sun, Jan 6, 2013 at 6:17 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: 1. `refer`. Define a public function that `refer`s all the symbols you want. It's an extra step for the user, but that's good because it makes it evident that extra symbols are being added. Forcing all users of a library to refer a whole slew of symbols from another library that they don't even know they're using is horrible usability and really not a useful suggestion. The user should be able to (:require [main-library :refer [what i want]) without being forced to know about a transitive dependency and know which symbols come from which library, if the main-library developer wishes to provide a single, simple API. Could you explain exactly how this breaks dynamic binding, with-redefs, and the ability to redefine functions at the REPL given the scenario we're discussing? Remember that the whole purpose of this discussion is to essentially hide the underlying namespace from which symbols originate, and to present a single namespace with the desired API. 2. `load`. If you have N namespaces with no clashing symbols, then you only need one namespace. If you want to split it across multiple files, use `load`. `clojure.core` does this. Fine if you control all of the source yourself. In the case of FW/1, I want a portion of Enlive available directly and easily to users of FW/1. Enlive is a transitive dependency - users of FW/1 don't need to know about it, and shouldn't really care. Since this appears to be a relatively common use case for library developers, perhaps a native Clojure solution that doesn't have the downsides you list would be worth adding? Perhaps some sort of (export some-ns/some-symbol) that makes *ns*/some-symbol appear like an exact public alias of some-ns/some-symbol? So users of the library see those exported symbols exactly as if they were declared in the library itself, rather than the third-party dependency, and could interact with them as such. -- 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
Unable to save the source file which loads repl
c:\hello.clj: (clojure.main/repl) C:\java -jar clojure-1.4.0.jar hello.clj user= And then the file becomes read-only. I'm launching repl myself to avoid threading issue in my wpf project. (https://gist.github.com/3062194) -- 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: Unable to save the source file which loads repl
On Jan 6, 2013 10:22 PM, Alice dofflt...@gmail.com wrote: C:\java -jar clojure-1.4.0.jar hello.clj user= And then the file becomes read-only. I'm launching repl myself to avoid threading issue in my wpf project. (https://gist.github.com/3062194) It's how Windows works. You'll have to do something else, maybe wrap the repl call in (future ...), maybe put your actual app in a separate file. -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. -- 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: core.matrix proposal
+1 on Konrad's comment about N-dimensional arrays for me. I think the issue of using immutable arrays (which can be important for performance) in Clojure is interesting to think about. I have had some ideas about how to use arrays with restricted or limited mutability but haven't solidified anything yet. On Saturday, January 5, 2013 10:11:59 PM UTC+11, Konrad Hinsen wrote: Mikera writes: I think this could be very useful for the Clojure community, especially given the interest in big data, simulations, machine learning, 3D graphics etc. If it goes well and there is enough interest, I guess that this could form the basis for a future core.matrix library. Comments / ideas / patches welcome. I haven't looked at your library yet, but my immediate comment is that I'd much prefer to have an API for N-dimensional arrays rather than just for matrices (2d) and vectors (1d). Konrad. -- 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: core.matrix proposal
Initial tests seem to suggest that supporting N-dimensional arrays should be pretty easy in terms of the API itself. We could also provide fast-paths for 1D and 2D arrays. Of course, actual support for N-dimensional arrays would depend on the underlying implementation. On Monday, 7 January 2013 13:22:38 UTC+8, James Sofra wrote: +1 on Konrad's comment about N-dimensional arrays for me. I think the issue of using immutable arrays (which can be important for performance) in Clojure is interesting to think about. I have had some ideas about how to use arrays with restricted or limited mutability but haven't solidified anything yet. On Saturday, January 5, 2013 10:11:59 PM UTC+11, Konrad Hinsen wrote: Mikera writes: I think this could be very useful for the Clojure community, especially given the interest in big data, simulations, machine learning, 3D graphics etc. If it goes well and there is enough interest, I guess that this could form the basis for a future core.matrix library. Comments / ideas / patches welcome. I haven't looked at your library yet, but my immediate comment is that I'd much prefer to have an API for N-dimensional arrays rather than just for matrices (2d) and vectors (1d). Konrad. -- 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: core.matrix proposal
Yep, the idea is to be flexible enough to support many different implementations. The pure Clojure version should be very easy to use and flexible since it uses regular Clojure persistent vectors. The trade-off is of less performance compared to the Java/native implementations. As an added bonus, writing a pure Clojure version is useful for testing / validating the design of the API before we extend it to more complex implementations. On Sunday, 6 January 2013 12:54:08 UTC+8, Rob Lachlan wrote: I really like this idea -- I think there's a need for a dedicated matrix computation library in clojure. I really like the idea of having matrix operations implemented in clojure (I think that you have this in persistent_vector.clj) but also being able to call on java libraries. On Saturday, January 5, 2013 2:00:23 AM UTC-8, Mikera wrote: Hello all, I've been experimenting with a common API / abstraction for matrix and vector maths in Clojure: https://github.com/mikera/matrix-api The idea is: - Provide a clear, consistent API for matrix and vector operations - Support multiple different underlying implementations (e.g. native code via JBLAS vs pure Java like vectorz-clj) - Provide a base which other libraries that need to consume matrices can build upon (e.g. Incanter) - Offer good performance while still presenting a reasonably flexible high level API I think this could be very useful for the Clojure community, especially given the interest in big data, simulations, machine learning, 3D graphics etc. If it goes well and there is enough interest, I guess that this could form the basis for a future core.matrix library. Comments / ideas / patches welcome. Mike. -- 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: Copying (immigrating) macros from namespace to namespace
I remembered bookmarking a library that did something similar, so I looked at my bookmarks. Here is Zach Tellman's potemkin library, you might be interested in checking it out: https://github.com/ztellman/potemkin From the README : Clojure’s namespaces conflate how you implement your code and how it’s consumed by other code. This isn’t always a bad thing, but in practice this means that large projects either have surprisingly large source files (e.g. clojure.core) or a surprising number of namespaces that have to all be used in concert to accomplish complex tasks (e.g. Ring). The former approach places an onus on the creator of the library; the various orthogonal pieces of his library all coexist, which can make it difficult to keep everything straight. The latter approach places an onus on the consumers of the library, forcing them to remember exactly what functionality resides where before they can actually use it. import-fn and import-macro decouple the structure of the code from the structure of the API, allowing the library creator to structure the code however he likes, without necessarily requiring that the consumers have the same intimate understanding of that structure. As someone who spends a fair amount of time worrying both about the structure of the code and the presentation of the API, it’s helpful not to have to think about how one affects the other. You might find it helpful, too. /vedang On Mon, Jan 7, 2013 at 8:12 AM, Sean Corfield seancorfi...@gmail.com wrote: On Sun, Jan 6, 2013 at 6:17 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: 1. `refer`. Define a public function that `refer`s all the symbols you want. It's an extra step for the user, but that's good because it makes it evident that extra symbols are being added. Forcing all users of a library to refer a whole slew of symbols from another library that they don't even know they're using is horrible usability and really not a useful suggestion. The user should be able to (:require [main-library :refer [what i want]) without being forced to know about a transitive dependency and know which symbols come from which library, if the main-library developer wishes to provide a single, simple API. Could you explain exactly how this breaks dynamic binding, with-redefs, and the ability to redefine functions at the REPL given the scenario we're discussing? Remember that the whole purpose of this discussion is to essentially hide the underlying namespace from which symbols originate, and to present a single namespace with the desired API. 2. `load`. If you have N namespaces with no clashing symbols, then you only need one namespace. If you want to split it across multiple files, use `load`. `clojure.core` does this. Fine if you control all of the source yourself. In the case of FW/1, I want a portion of Enlive available directly and easily to users of FW/1. Enlive is a transitive dependency - users of FW/1 don't need to know about it, and shouldn't really care. Since this appears to be a relatively common use case for library developers, perhaps a native Clojure solution that doesn't have the downsides you list would be worth adding? Perhaps some sort of (export some-ns/some-symbol) that makes *ns*/some-symbol appear like an exact public alias of some-ns/some-symbol? So users of the library see those exported symbols exactly as if they were declared in the library itself, rather than the third-party dependency, and could interact with them as such. -- 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 -- Unix is simple. It takes a genius to understand it's simplicity.-Anon People think it must be fun to be a super genius, but they don't realize how hard it is to put up with all the idiots in the world. -Calvin. Cheers, Vedang. Programmer, Infinitely Beta. http://twitter.com/vedang http://vedang.me -- 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: core.matrix proposal
Mikera writes: Initial tests seem to suggest that supporting N-dimensional arrays should be pretty easy in terms of the API itself. We could also provide fast-paths for 1D and 2D arrays. Of course, actual support for N-dimensional arrays would depend on the underlying implementation. There are a few array implementations that support N-d arrays, for example the ones in JHDF5 (https://wiki-bsse.ethz.ch/display/JHDF5) and in netCDF (http://www.unidata.ucar.edu/software/netcdf-java/). Yep, the idea is to be flexible enough to support many different implementations. The real problem I see in making all this practically usable is efficient conversion between implementations. The fragmentation of the scientific computing ecosystem in Java makes it nearly impossible to get any real work done without some conversion between array libraries. If I want to read a matrix from an HDF5 file and then calculate its eigenvalues, I need to convert from HDF5 arrays to Colt (or whatever) arrays. Some libraries provide a way to construct an N-d array from a 1-d data storage area plus a shape vector, without copying the data. I think it's important to leverage such functionality in a Clojure API in order to let conversion happen as much as possible behind the scenes. BTW, I started my own attempt at something similar a while ago, but never found the time to get it to a usable state: https://code.google.com/p/clj-multiarray/ Konrad. -- 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
