Re: [ANN] Carmine (Redis client) v2, Nippy (serializer) v2 are out
Thanks Las, much appreciated! Just shout if there's anything I can assist with. - Peter -- -- 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.
anaphoric macro?
Hi, I want to write a macro that introduces new variables from data. The data is a vector and looks like this for example: [a b c] I want to use the macro like this: (def-names [a b c] (str a b)) What code I want the macro to produce from the above is the following: (let [a a b b c c] (str a b)) Is it possible to do that? Is it a good thing to do that or is it bad practice? Thanks --anders -- -- 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: anaphoric macro?
Since the bindings are a function of the data that's passed in, IMO you don't need a anaphoric macro for this. For example - (defmacro def-names [names body] (let [bindings* (vec (mapcat (juxt symbol identity) names))] `(let ~bindings* ~@body))) As to whether it's a good idea or not, I'd say it depends but YMMV. Regards, BG On Tue, Jul 23, 2013 at 12:48 PM, eliassona...@yahoo.com wrote: Hi, I want to write a macro that introduces new variables from data. The data is a vector and looks like this for example: [a b c] I want to use the macro like this: (def-names [a b c] (str a b)) What code I want the macro to produce from the above is the following: (let [a a b b c c] (str a b)) Is it possible to do that? Is it a good thing to do that or is it bad practice? Thanks --anders -- -- 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: anaphoric macro?
Hi Anders, (defmacro def-name [name-vec body] `(let ~(vec (interleave (map symbol name-vec) name-vec)) ~@body)) user= (macroexpand '(def-name [a b c] 1 2 3)) (let* [a a b b c c] 1 2 3) user= (def-name [a b c] a) a user= (def-name [a b c] b) b user= (def-name [a b c] (str a b)) ab Best, Alex On Tue, Jul 23, 2013 at 12:18 AM, eliassona...@yahoo.com wrote: Hi, I want to write a macro that introduces new variables from data. The data is a vector and looks like this for example: [a b c] I want to use the macro like this: (def-names [a b c] (str a b)) What code I want the macro to produce from the above is the following: (let [a a b b c c] (str a b)) Is it possible to do that? Is it a good thing to do that or is it bad practice? Thanks --anders -- -- 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: anaphoric macro?
Good point BG, I think it is almost certainly not a good idea :) But educational, definitely. On Tue, Jul 23, 2013 at 12:48 AM, Baishampayan Ghose b.gh...@gmail.comwrote: Since the bindings are a function of the data that's passed in, IMO you don't need a anaphoric macro for this. For example - (defmacro def-names [names body] (let [bindings* (vec (mapcat (juxt symbol identity) names))] `(let ~bindings* ~@body))) As to whether it's a good idea or not, I'd say it depends but YMMV. Regards, BG On Tue, Jul 23, 2013 at 12:48 PM, eliassona...@yahoo.com wrote: Hi, I want to write a macro that introduces new variables from data. The data is a vector and looks like this for example: [a b c] I want to use the macro like this: (def-names [a b c] (str a b)) What code I want the macro to produce from the above is the following: (let [a a b b c c] (str a b)) Is it possible to do that? Is it a good thing to do that or is it bad practice? Thanks --anders -- -- 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. -- -- 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: Interest in a Full Featured Clojure Blog Engine
Il giorno martedì 23 luglio 2013 03:32:52 UTC+2, frye ha scritto: On Sun, Jul 21, 2013 at 5:16 PM, Manuel Paccagnella manuel.pa...@gmail.com javascript: wrote: - what I should use to model workflow; possibly laminahttps://github.com/ztellman/lamina ? I'm not sure Lamina is the right tool for this job. What are your ideas for modeling and executing workflows? When I say Workflow, I mean something along the lines of a Petri Net ( http://www.informatik.uni-hamburg.de/TGI/PetriNets/). I've used Lamina in order to handle multiple channels in my domain. And that was just me wondering out loud if it can be grafted onto the task. I don't see any well fleshed out Petri Nets or Finite State Machines in Clojure (although googling gives you a bunch of user trials and whatnot) I've pondered a bit about this, I like your idea. Regarding finite state machines, have you seen devshttps://github.com/mtnygard/devs? - - what's the best interface messages to pass between the core service and plug-ins; I'm thinking of the nreplhttps://github.com/clojure/tools.nreplprotocol, but I need to work out: 1. communication between plug-ins 2. way to list possible actions (namespace qualify action names) 3. way to publish actions 4. way for core service to listen for messages from a plug-in 5. way to pass binary data (asset(s)) between stefon and plug-in I've not investigated this in depth, but why not a simple HTTP interface that talks EDN? I plan on having an HTTP plug-in, using an edn transport; but that would be a chunk of code that uses the plug-in architecture, and talks to HTTP clients I think the next week or so will be investigating this list. It represents most of the hurdles I see in getting a successful core / plug-in architecture running. Insight or expertise on any of these points is very welcome. I don't know if you have read thishttp://www.chris-granger.com/2013/01/24/the-ide-as-data/, but maybe it could give you some ideas about the plugin architecture. The blog engine as data. The plugin system could be the kernel, and maybe most features could be implemented as plugins. Just dreaming out loud :) Yes, what you describe is very much the concept that I have -- -- 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: Interest in a Full Featured Clojure Blog Engine
Il giorno martedì 23 luglio 2013 04:11:48 UTC+2, frye ha scritto: Hey all, *A)* Thanks for all the feedback on this topic. There's a few interesting things here. Notably that there are at least these existing blog engines: - http://github.com/bitemyapp/neubite (apparently needs a WYSIWYG editor) - https://github.com/yogthos/yuggoth (although this advertises itself as a full blog engine) *B)* I'll also look into putting HTML code within Markdown text. Wrt * Asciidoc*, what I wonder is i) does it handle all media types (images, video, audio, etc) and ii) are there well-developed web-editors for asciidoc ? i) Yes http://www.methods.co.nz/asciidoc/asciidoc.html#X98 :) ii) I haven't found none. However, it should be quite feasible to write AsciiDoc markup in plain text and render a preview in real time in-browser using asciidoctor.jshttp://asciidoctor.org/news/2013/05/21/asciidoctor-js-render-asciidoc-in-the-browser/. *C)* Also, the idea of a static site or blog generator (like Jekyll) is good. But that strikes me as a sub-set of a full-featured blog engine. My concept of having a small core (or kernel, if you like), would certainly allow for a static site generator as a plug-in. Looks like there are already working examples with: http://liquidz.github.io/misaki I would still like something.. a blog library that you can thread into your existing site. It wouldn't make too many assumptions about your setup (data store, http framework, templating, workflow, etc). And it would allow you to plug-in pieces on an as needed basis. I can't see that in neubite or yuggoth, unless I missed it. Please let me know. I agree. That way it could be used any number of markup languages for posts (and pages): Markdown, AsciiDoc, HTML, etc. Thanks Tim Washington Interruptsoftware.ca / Bkeeping.com On Mon, Jul 22, 2013 at 6:22 AM, Manuel Paccagnella manuel.pa...@gmail.com javascript: wrote: There is also Yuggoth: https://github.com/yogthos/yuggoth It's pretty feature-complete as I can see, but I haven't looked at the source for its the architecture. Trivia: It has been written starting with Luminus, and the author is writing a book about web development in Clojure for The Pragmatic Programmers. Il giorno domenica 21 luglio 2013 22:10:45 UTC+2, frye ha scritto: Ooh. Ok, lemme check it out. On Sat, Jul 20, 2013 at 10:34 PM, Chris Allen calle...@gmail.comwrote: http://github.com/bitemyapp/**neubite/http://github.com/bitemyapp/neubite/ Could probably use a WYSIWYG editor, beyond that, pretty serviceable. -- -- 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: anaphoric macro?
I use a similar macro in my music codehttps://github.com/ctford/leipzig/blob/master/src/leipzig/scale.clj, because I want to take a sequence and explicitly give parts of it names. (defmacro defs [names docstring values] `(do ~@(map (fn [name value] `(def ~name ~docstring ~value)) names (eval values (defs [C D E F G A B] A key, expressed as a translation function. (map (comp from (from 60) major) (range))) This macro is not part of the public API. :-) On 23 July 2013 10:52, Alex Baranosky alexander.barano...@gmail.com wrote: Good point BG, I think it is almost certainly not a good idea :) But educational, definitely. On Tue, Jul 23, 2013 at 12:48 AM, Baishampayan Ghose b.gh...@gmail.comwrote: Since the bindings are a function of the data that's passed in, IMO you don't need a anaphoric macro for this. For example - (defmacro def-names [names body] (let [bindings* (vec (mapcat (juxt symbol identity) names))] `(let ~bindings* ~@body))) As to whether it's a good idea or not, I'd say it depends but YMMV. Regards, BG On Tue, Jul 23, 2013 at 12:48 PM, eliassona...@yahoo.com wrote: Hi, I want to write a macro that introduces new variables from data. The data is a vector and looks like this for example: [a b c] I want to use the macro like this: (def-names [a b c] (str a b)) What code I want the macro to produce from the above is the following: (let [a a b b c c] (str a b)) Is it possible to do that? Is it a good thing to do that or is it bad practice? Thanks --anders -- -- 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. -- -- 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: Socket.IO and Clojure?
A bit off-topic, but in some situations where bidirectional communication is not necessary, one might consider EventSource instead of Websockets to push data from server to the client. For some reason, EventSource is not as well known as Websockets. It has some advantages like being more backwards compatible. http://www.html5rocks.com/en/tutorials/eventsource/basics/ http://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource https://github.com/Yaffle/EventSource Ustun On Wednesday, July 17, 2013 8:07:34 AM UTC+3, Sean Corfield wrote: At work we're starting down the path of building a new piece of functionality based on WebSockets and the external team we're working with is a Node.js shop so their go to solution is Socket.IO and they've produced a very nice front end in CoffeeScript and a prototype back end on Node.js. I'd really like to have our back end on the JVM, of course, and so I'd like to find a JVM-based Socket.IO solution that I use from/with Clojure... This seems like a reasonable option: https://github.com/mrniko/netty-socketio A little bit of experimentation with lein-try (Thank you Ryan!) shows that it's pretty easy to get a basic server up and running in the REPL - and I was able to get several of their demos running unchanged against Clojure, instead of their Java applications, so that was promising. Are there other folks out there doing Socket.IO stuff with Clojure? What approaches have you taken? Obviously, we could run Node.js and have it hit a Clojure-based REST API to do the integration, and that might be less pain long term but... -- 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: Making RPCs with Shoreleave
Hi, I'm using Shoreleave in one of our projects and it works fine for us. I followed the same tutorial and everything was OK. I've seen something similar when I was using the autogeneration of the js file. For some reason after updating the cljs the continuous compilation breaks the shoreleave RPC. When it happens I fix it by cleaning and compiling the whole thing again. Tony. On Sunday, 21 July 2013 16:08:07 UTC+1, Alex Fowler wrote: Considering the severity of the bug that i found, i want to ask if someone is using Shoreleave's rpc without any problems? Maybe it's me missing something? Or maybe someone run into the same problem too? On Saturday, July 20, 2013 2:16:02 PM UTC+4, Alex Fowler wrote: That wasn't hte case either. After some buzz with ddellacosta and others on #clojure, it was found that the RPC call is unable to find that very remote procedure I was requesting. Then I have verified that all is properly stored in the remote procedures registry on backend and that the front end makes proper calls. The problem was that the backend was expecting edn while the frontend was sending it in html-form format in request body. I am just a beginner with Clojure's web stack, so I think that maybe I missed some wrappers with Noir or Ring, but I was doing all according to the tutorial and it failed to work. So I had to manually override several functions from Shoreleave back-end and front-end to behave coherently and send and receive data in edn format. I think this makes a patch for the library since the RPC functionality is broken out-of-the-box. Unless I am missing something crucial, but examples I found miss that either... четверг, 18 июля 2013 г., 15:42:35 UTC+4 пользователь terjesb написал: The default /_shoreleave endpoint should work if you're running using lein ring server. Are you running a WAR in a container? If so, I don't think Shoreleave currently picks up the context. If you have only one client app, you could proxy this using nginx in front on your container. For multiple client apps (also standalone, without a container), you may need to do what I did: override default /_shoreleave in your app: (wrap-rpc /your-context/_shoreleave) and then (binding [shoreleave.remotes.http-rpc/*remote-uri* /your-context/_shoreleave] ) around your client calls. Terje. kl. 10:50:17 UTC+2 mandag 15. juli 2013 skrev Alex Fowler følgende: Did not work.. all that is strange since I've been following the manual step-by-step.. looks like the shoreleave's wrapper does not even create a http route for itself... any other ideas? On Friday, July 12, 2013 7:14:42 AM UTC+4, Samrat Man Singh wrote: I think you need to (use projectname.ajax) in your projectname.handler page. If I remember correctly, there's also a way to specify which namespace your remote function is in. On Thursday, July 11, 2013 10:42:15 PM UTC+5:45, Alex Fowler wrote: Hi all, this is my first experience with Shoreleave and I'm trying to use it's RPC mechanism to perform AJAX tasks. However, on a call to a remote procedure, I get this: ` 1. POST http://localhost:8080/_shoreleave 404 (Not Found) cljs.js:25223 http://localhost:8080/js/cljs.js 1. goog.net.XhrIo.sendcljs.js:25223http://localhost:8080/js/cljs.js 2. xhr__delegatecljs.js:31416http://localhost:8080/js/cljs.js 3. xhrcljs.js:31423 http://localhost:8080/js/cljs.js 4. remote_callback__delegatecljs.js:32504http://localhost:8080/js/cljs.js 5. remote_callbackcljs.js:32515http://localhost:8080/js/cljs.js 6. load_storecljs.js:32745 http://localhost:8080/js/cljs.js 7. mk__AMPERSAND__load_store__delegatecljs.js:32755http://localhost:8080/js/cljs.js 8. mk__AMPERSAND__load_storecljs.js:32763http://localhost:8080/js/cljs.js 9. example_storecljs.js:33341http://localhost:8080/js/cljs.js 10. simplecljs.js:33361 http://localhost:8080/js/cljs.js 11. setup_guicljs.js:33962 http://localhost:8080/js/cljs.js 12. setup_allcljs.js:33982 http://localhost:8080/js/cljs.js 13. startupcljs.js:41166 http://localhost:8080/js/cljs.js 14. onloadapp:2 http://localhost:8080/app XHR ERROR: Not Found ` What is wrong and how do I fix it? I have been following this tutorial: Shoreleave Tutorial 10 - Introducing Ajaxhttps://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-10.md my code (relevant parts) is this: Project.clj: ` (defproject projectname 0.1.0-SNAPSHOT :description FIXME: write description :url http://example.com/FIXME; :dependencies [[org.clojure/clojure 1.5.1] [lib-noir 0.6.3] [compojure 1.2.0-SNAPSHOT] [ring-server 0.2.8] [clabango 0.5] [hiccup 1.0.3] [com.taoensso/timbre 2.1.2] [com.taoensso/tower 1.7.1] [markdown-clj
futures - The Joy Of Clojure book question
There is an example in the book The Joy of Clojure on p.262 that uses futures that I evaluated in the REPL. user (time (let [x (future (do (Thread/sleep 2000) (+ 1 1)))] [@x @x])) Elapsed time: 2000.809 msecs [2 2] I figured that taking out the future would cause the execution to take twice as long, however, when I try this: user (time (let [x (do (Thread/sleep 2000) (+ 1 1))] [x x])) Elapsed time: 2000.512 msecs [2 2] as you see it takes about the same amount of time. Does this have something to do with the REPL evaluating things or maybe the newer version of Clojure handles things differently from the Joy of Clojure book? 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: futures - The Joy Of Clojure book question
It's definitely got to do with the code, the right way to test it out will be to wrap the form in a function and then calling it twice. Like so - (time (let [x (fn [] (Thread/sleep 2000) (+ 1 1))] [(x) (x)])) ;= Elapsed time: 4002.0 msecs ;= [2 2] Hope that helps. Regards, BG On Tue, Jul 23, 2013 at 8:34 PM, Ryan Moore niclas1...@gmail.com wrote: There is an example in the book The Joy of Clojure on p.262 that uses futures that I evaluated in the REPL. user (time (let [x (future (do (Thread/sleep 2000) (+ 1 1)))] [@x @x])) Elapsed time: 2000.809 msecs [2 2] I figured that taking out the future would cause the execution to take twice as long, however, when I try this: user (time (let [x (do (Thread/sleep 2000) (+ 1 1))] [x x])) Elapsed time: 2000.512 msecs [2 2] as you see it takes about the same amount of time. Does this have something to do with the REPL evaluating things or maybe the newer version of Clojure handles things differently from the Joy of Clojure book? 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. -- 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: futures - The Joy Of Clojure book question
On Tue, Jul 23, 2013 at 11:12 AM, Baishampayan Ghose b.gh...@gmail.com wrote: It's definitely got to do with the code, the right way to test it out will be to wrap the form in a function and then calling it twice. Like so - (time (let [x (fn [] (Thread/sleep 2000) (+ 1 1))] [(x) (x)])) ;= Elapsed time: 4002.0 msecs ;= [2 2] Hope that helps. Regards, BG On Tue, Jul 23, 2013 at 8:34 PM, Ryan Moore niclas1...@gmail.com wrote: There is an example in the book The Joy of Clojure on p.262 that uses futures that I evaluated in the REPL. user (time (let [x (future (do (Thread/sleep 2000) (+ 1 1)))] [@x @x])) Elapsed time: 2000.809 msecs [2 2] I figured that taking out the future would cause the execution to take twice as long, however, when I try this: user (time (let [x (do (Thread/sleep 2000) (+ 1 1))] [x x])) Elapsed time: 2000.512 msecs [2 2] as you see it takes about the same amount of time. Does this have something to do with the REPL evaluating things or maybe the newer version of Clojure handles things differently from the Joy of Clojure book? Can also show the difference using two different vars (time (let [x (future (do (Thread/sleep 2000) (+ 1 1))) y (future (do (Thread/sleep 3000) (+ 2 2)))] [@x @y])) Elapsed time: 3003.802 msecs [2 4] (time (let [x (do (Thread/sleep 2000) (+ 1 1)) y (do (Thread/sleep 3000) (+ 2 2))] [x y])) Elapsed time: 5003.049 msecs [2 4] Basically, [x x] doesn't do the evaluation, it happens in the let once for x. For [@x @x] the thread is kicked off once to do the computation, and the first @x waits for the result (if not already available) while the second @x uses the cached value. In my modified version, the second case the two Thread/sleep happens in sequence, while in the first they take place in parallel thanks to the futures. Lars Nilsson -- -- 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.
Can we please deprecate the :use directive ?
I think I read somewhere that :use is no longer encouraged, but I could be mistaken. From what I've read, it seems like most people agree that Clojure has too many ways of including/importing/referencing/requiring/using things: http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html The above gives a very nice explanation of all the various difference, but it also acknowledges their complexity. Since :use uses :require, and since :require can do everything that :use can, can we simplify Clojure programming a bit for newcomers by deprecating the use of :use? The situation in ClojureScript is even worse because it adds :require-macros on top of all the other ways of including files. Ideally, it would be awesome if there was just a single directive for everything, but perhaps there's some complicated low-level reason why that's not possible. :-\ Thoughts? Thanks, Greg P.S. If this has already been brought up you have my sincere apologies. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- -- 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: Can't get namespace metadata
I can confirm this behavior. It's not the fault of the `ns`
macro, however. This works just fine:
user= (ns ^{:doc This is foo} foo)
nil
foo= (in-ns 'user)
#Namespace user
user= (meta (the-ns 'foo))
{:doc This is foo}
AOT-compilation appears to be the culprit (as usual). This
has been known for a long time, see CLJ-130, which I just
updated.
[CLJ-130]: http://dev.clojure.org/jira/browse/CLJ-130
-S
On Saturday, July 20, 2013 8:50:18 AM UTC-4, Alexander Yakushev wrote:
Example:
user= (meta (find-ns 'clojure.set))
nil
user= (meta (find-ns 'clojure.string))
nil
user= (meta (find-ns 'clojure.core))
{:doc Fundamental library of the Clojure language}
clojure.core is the only namespace that has metadata. Apparently because
it has metadata set differently
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6158,
so I blame *ns *macro.
I tested this with clojure 1.2-1.5, so it is not a regression, and unless
I'm doing something wrong, this was broken from the beginning.
--
--
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: Can't get namespace metadata
Thank you for confirming this, Stuart. Hopefully this will be fixed someday.
On Tuesday, July 23, 2013 7:06:18 PM UTC+3, Stuart Sierra wrote:
I can confirm this behavior. It's not the fault of the `ns`
macro, however. This works just fine:
user= (ns ^{:doc This is foo} foo)
nil
foo= (in-ns 'user)
#Namespace user
user= (meta (the-ns 'foo))
{:doc This is foo}
AOT-compilation appears to be the culprit (as usual). This
has been known for a long time, see CLJ-130, which I just
updated.
[CLJ-130]: http://dev.clojure.org/jira/browse/CLJ-130
-S
On Saturday, July 20, 2013 8:50:18 AM UTC-4, Alexander Yakushev wrote:
Example:
user= (meta (find-ns 'clojure.set))
nil
user= (meta (find-ns 'clojure.string))
nil
user= (meta (find-ns 'clojure.core))
{:doc Fundamental library of the Clojure language}
clojure.core is the only namespace that has metadata. Apparently because
it has metadata set differently
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6158,
so I blame *ns *macro.
I tested this with clojure 1.2-1.5, so it is not a regression, and unless
I'm doing something wrong, this was broken from the beginning.
--
--
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: Can we please deprecate the :use directive ?
+1, :use is IMO an antipattern. I hate it mainly in blogs, where they explain some new API. They :use like 3 namespaces and you have to guess which fn is from which ns :) JW On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote: I think I read somewhere that :use is no longer encouraged, but I could be mistaken. From what I've read, it seems like most people agree that Clojure has too many ways of including/importing/referencing/requiring/using things: http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html The above gives a very nice explanation of all the various difference, but it also acknowledges their complexity. Since :use uses :require, and since :require can do everything that :use can, can we simplify Clojure programming a bit for newcomers by deprecating the use of :use? The situation in ClojureScript is even worse because it adds :require-macros on top of all the other ways of including files. Ideally, it would be awesome if there was just a single directive for everything, but perhaps there's some complicated low-level reason why that's not possible. :-\ Thoughts? Thanks, Greg P.S. If this has already been brought up you have my sincere apologies. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- -- 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: Can we please deprecate the :use directive ?
We should scour clojuresphere for uses of 'use' and automatically post github issues to the projects of interest, and redefine the ns macro to issue a warning with use. Does anyone actually like 'use'? Require is always more evident. On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner jozef.wag...@gmail.comwrote: +1, :use is IMO an antipattern. I hate it mainly in blogs, where they explain some new API. They :use like 3 namespaces and you have to guess which fn is from which ns :) JW On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote: I think I read somewhere that :use is no longer encouraged, but I could be mistaken. From what I've read, it seems like most people agree that Clojure has too many ways of including/importing/**referencing/requiring/using things: http://blog.8thlight.com/**colin-jones/2010/12/05/** clojure-libs-and-namespaces-**require-use-import-and-ns.htmlhttp://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html The above gives a very nice explanation of all the various difference, but it also acknowledges their complexity. Since :use uses :require, and since :require can do everything that :use can, can we simplify Clojure programming a bit for newcomers by deprecating the use of :use? The situation in ClojureScript is even worse because it adds :require-macros on top of all the other ways of including files. Ideally, it would be awesome if there was just a single directive for everything, but perhaps there's some complicated low-level reason why that's not possible. :-\ Thoughts? Thanks, Greg P.S. If this has already been brought up you have my sincere apologies. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- -- 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: Can we please deprecate the :use directive ?
On Jul 23, 2013, at 2:27 PM, Gary Trakhman wrote: We should scour clojuresphere for uses of 'use' and automatically post github issues to the projects of interest, and redefine the ns macro to issue a warning with use. Does anyone actually like 'use'? Require is always more evident. I like it and I use it regularly, mainly, I guess, when all of the namespaces are my own and I know there are no conflicts. I split things into namespaces to keep the project organized, etc., but I don't want to have to qualify everything everywhere. -Lee -- -- 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: Can we please deprecate the :use directive ?
We have production code using it. It's easy to say that it's a bad pattern after the fact. We have been using it in a disciplined way. It simplifies our life in the REPL we have some tools we want to see included automatically each time we switch to a name space. Anything else aside from clojure.core is required using an alias. This minimized name clashes to zero so far. This is easily spottable in the ns macro declarations and is not a source of confusion for us. We have less manipulations to do in the REPL when attaching to the live app with these defaults included. I do not mind about the deprecation warning as a first step. However I would like some breathing space before it gets removed entirely. It's just another to do on top of the pile of work we have these times... Luc P. We should scour clojuresphere for uses of 'use' and automatically post github issues to the projects of interest, and redefine the ns macro to issue a warning with use. Does anyone actually like 'use'? Require is always more evident. On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner jozef.wag...@gmail.comwrote: +1, :use is IMO an antipattern. I hate it mainly in blogs, where they explain some new API. They :use like 3 namespaces and you have to guess which fn is from which ns :) JW On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote: I think I read somewhere that :use is no longer encouraged, but I could be mistaken. From what I've read, it seems like most people agree that Clojure has too many ways of including/importing/**referencing/requiring/using things: http://blog.8thlight.com/**colin-jones/2010/12/05/** clojure-libs-and-namespaces-**require-use-import-and-ns.htmlhttp://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html The above gives a very nice explanation of all the various difference, but it also acknowledges their complexity. Since :use uses :require, and since :require can do everything that :use can, can we simplify Clojure programming a bit for newcomers by deprecating the use of :use? The situation in ClojureScript is even worse because it adds :require-macros on top of all the other ways of including files. Ideally, it would be awesome if there was just a single directive for everything, but perhaps there's some complicated low-level reason why that's not possible. :-\ Thoughts? Thanks, Greg P.S. If this has already been brought up you have my sincere apologies. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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: Can we please deprecate the :use directive ?
For much the same reason, I've been using :require with :as and a one-or-two-letter alias, so I can do x/whatever. Generally works well. On Tue, Jul 23, 2013 at 1:38 PM, Lee Spector lspec...@hampshire.edu wrote: On Jul 23, 2013, at 2:27 PM, Gary Trakhman wrote: We should scour clojuresphere for uses of 'use' and automatically post github issues to the projects of interest, and redefine the ns macro to issue a warning with use. Does anyone actually like 'use'? Require is always more evident. I like it and I use it regularly, mainly, I guess, when all of the namespaces are my own and I know there are no conflicts. I split things into namespaces to keep the project organized, etc., but I don't want to have to qualify everything everywhere. -Lee -- -- 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: Can we please deprecate the :use directive ?
We only have :use in a couple of legacy tests and two scratch projects. We've switched from :use to :require .. :refer :all for situations where :use used to make sense (primarily in a test ns where we want to just refer in all of the ns being tested). We have a handful of places where we :refer :all elsewhere because the code reads better without ns aliases all over the place and we bring in a lot of functions. Certainly in blogs and documentation, :require .. :as short alias seems a better approach for teaching / explaining things but I'm sure I'm guilty of :use in earlier blog posts about Clojure (... checking ... yup, three blog posts from early 2012 contain :use, mostly with :only, so those should be updated to use :require / :refer instead). Sean On Tue, Jul 23, 2013 at 11:27 AM, Gary Trakhman gary.trakh...@gmail.com wrote: We should scour clojuresphere for uses of 'use' and automatically post github issues to the projects of interest, and redefine the ns macro to issue a warning with use. Does anyone actually like 'use'? Require is always more evident. On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner jozef.wag...@gmail.com wrote: +1, :use is IMO an antipattern. I hate it mainly in blogs, where they explain some new API. They :use like 3 namespaces and you have to guess which fn is from which ns :) JW On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote: I think I read somewhere that :use is no longer encouraged, but I could be mistaken. From what I've read, it seems like most people agree that Clojure has too many ways of including/importing/referencing/requiring/using things: http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html The above gives a very nice explanation of all the various difference, but it also acknowledges their complexity. Since :use uses :require, and since :require can do everything that :use can, can we simplify Clojure programming a bit for newcomers by deprecating the use of :use? The situation in ClojureScript is even worse because it adds :require-macros on top of all the other ways of including files. Ideally, it would be awesome if there was just a single directive for everything, but perhaps there's some complicated low-level reason why that's not possible. :-\ Thoughts? Thanks, Greg P.S. If this has already been brought up you have my sincere apologies. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- -- 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. -- 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: Can we please deprecate the :use directive ?
:use...:only doesn't strike me as especially problematic, since it documents the specific symbols it's importing and from where. On Tue, Jul 23, 2013 at 3:04 PM, Sean Corfield seancorfi...@gmail.comwrote: We only have :use in a couple of legacy tests and two scratch projects. We've switched from :use to :require .. :refer :all for situations where :use used to make sense (primarily in a test ns where we want to just refer in all of the ns being tested). We have a handful of places where we :refer :all elsewhere because the code reads better without ns aliases all over the place and we bring in a lot of functions. Certainly in blogs and documentation, :require .. :as short alias seems a better approach for teaching / explaining things but I'm sure I'm guilty of :use in earlier blog posts about Clojure (... checking ... yup, three blog posts from early 2012 contain :use, mostly with :only, so those should be updated to use :require / :refer instead). Sean On Tue, Jul 23, 2013 at 11:27 AM, Gary Trakhman gary.trakh...@gmail.com wrote: We should scour clojuresphere for uses of 'use' and automatically post github issues to the projects of interest, and redefine the ns macro to issue a warning with use. Does anyone actually like 'use'? Require is always more evident. On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner jozef.wag...@gmail.com wrote: +1, :use is IMO an antipattern. I hate it mainly in blogs, where they explain some new API. They :use like 3 namespaces and you have to guess which fn is from which ns :) JW On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote: I think I read somewhere that :use is no longer encouraged, but I could be mistaken. From what I've read, it seems like most people agree that Clojure has too many ways of including/importing/referencing/requiring/using things: http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html The above gives a very nice explanation of all the various difference, but it also acknowledges their complexity. Since :use uses :require, and since :require can do everything that :use can, can we simplify Clojure programming a bit for newcomers by deprecating the use of :use? The situation in ClojureScript is even worse because it adds :require-macros on top of all the other ways of including files. Ideally, it would be awesome if there was just a single directive for everything, but perhaps there's some complicated low-level reason why that's not possible. :-\ Thoughts? Thanks, Greg P.S. If this has already been brought up you have my sincere apologies. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- -- 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. -- 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
Re: Can we please deprecate the :use directive ?
Yea, I have a single namespace with project-specific common utilities which I refer to as u/some-util-function. For me, it's a bit scary to have implicit symbols in scope. A typo can make a local binding refer to something that might not exist in production, or at least not what's intended. Conversely, I don't want extra code in my project that has nothing to do with the project. Seems useful to enforce a separation of the artifact from the tools that made it, more-so for a lib that other things depend on than a production app. The 'user' namespace can cover the use-case of convenience functions? Or, you can add those symbols dynamically at run-time when you need to with something like: https://github.com/flatland/useful/blob/develop/src/flatland/useful/ns.clj#L26 or some aggregated (require ..) calls. On Tue, Jul 23, 2013 at 2:46 PM, Steven Degutis sbdegu...@gmail.com wrote: For much the same reason, I've been using :require with :as and a one-or-two-letter alias, so I can do x/whatever. Generally works well. On Tue, Jul 23, 2013 at 1:38 PM, Lee Spector lspec...@hampshire.eduwrote: On Jul 23, 2013, at 2:27 PM, Gary Trakhman wrote: We should scour clojuresphere for uses of 'use' and automatically post github issues to the projects of interest, and redefine the ns macro to issue a warning with use. Does anyone actually like 'use'? Require is always more evident. I like it and I use it regularly, mainly, I guess, when all of the namespaces are my own and I know there are no conflicts. I split things into namespaces to keep the project organized, etc., but I don't want to have to qualify everything everywhere. -Lee -- -- 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. -- -- 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: Can we please deprecate the :use directive ?
What's problematic about it is that it's slightly easier to do the wrong thing. It seems insignificant, but 98% of times you use use, it's going to be wrong. Also, 'use only' means I have to change my calling NS twice in different parts of the emacs buffer any time I change a function name in the called namespace. On Tue, Jul 23, 2013 at 3:08 PM, Cedric Greevey cgree...@gmail.com wrote: :use...:only doesn't strike me as especially problematic, since it documents the specific symbols it's importing and from where. On Tue, Jul 23, 2013 at 3:04 PM, Sean Corfield seancorfi...@gmail.comwrote: We only have :use in a couple of legacy tests and two scratch projects. We've switched from :use to :require .. :refer :all for situations where :use used to make sense (primarily in a test ns where we want to just refer in all of the ns being tested). We have a handful of places where we :refer :all elsewhere because the code reads better without ns aliases all over the place and we bring in a lot of functions. Certainly in blogs and documentation, :require .. :as short alias seems a better approach for teaching / explaining things but I'm sure I'm guilty of :use in earlier blog posts about Clojure (... checking ... yup, three blog posts from early 2012 contain :use, mostly with :only, so those should be updated to use :require / :refer instead). Sean On Tue, Jul 23, 2013 at 11:27 AM, Gary Trakhman gary.trakh...@gmail.com wrote: We should scour clojuresphere for uses of 'use' and automatically post github issues to the projects of interest, and redefine the ns macro to issue a warning with use. Does anyone actually like 'use'? Require is always more evident. On Tue, Jul 23, 2013 at 2:17 PM, Jozef Wagner jozef.wag...@gmail.com wrote: +1, :use is IMO an antipattern. I hate it mainly in blogs, where they explain some new API. They :use like 3 namespaces and you have to guess which fn is from which ns :) JW On Tuesday, July 23, 2013 5:50:50 PM UTC+2, Greg Slepak wrote: I think I read somewhere that :use is no longer encouraged, but I could be mistaken. From what I've read, it seems like most people agree that Clojure has too many ways of including/importing/referencing/requiring/using things: http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html The above gives a very nice explanation of all the various difference, but it also acknowledges their complexity. Since :use uses :require, and since :require can do everything that :use can, can we simplify Clojure programming a bit for newcomers by deprecating the use of :use? The situation in ClojureScript is even worse because it adds :require-macros on top of all the other ways of including files. Ideally, it would be awesome if there was just a single directive for everything, but perhaps there's some complicated low-level reason why that's not possible. :-\ Thoughts? Thanks, Greg P.S. If this has already been brought up you have my sincere apologies. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- -- 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. -- 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
Re: Can we please deprecate the :use directive ?
One of the main issues I have faced with :use is, understanding a non-trivial codebase becomes very difficult and almost always requires Emacs Meta-dot. I'd vote for deprecating :use. Shantanu -- -- 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: Can we please deprecate the :use directive ?
On Jul 23, 2013, at 3:06 PM, Gary Trakhman wrote: Yea, I have a single namespace with project-specific common utilities which I refer to as u/some-util-function. For me, it's a bit scary to have implicit symbols in scope. A typo can make a local binding refer to something that might not exist in production, or at least not what's intended. Conversely, I don't want extra code in my project that has nothing to do with the project. Seems useful to enforce a separation of the artifact from the tools that made it, more-so for a lib that other things depend on than a production app. The 'user' namespace can cover the use-case of convenience functions? Or, you can add those symbols dynamically at run-time when you need to with something like: https://github.com/flatland/useful/blob/develop/src/flatland/useful/ns.clj#L26 or some aggregated (require ..) calls. I'm sure I'm coming from a minority perspective on this, but for the kind of work I do it's often more important to be able to quickly sketch out and test ideas, without any ceremony about which functions come from where, than it is to ensure safety in a production environment which is really just me running it right now. In fact I'd sometimes like to go the other way and use everything in a whole directory subtree, or even to get rid of using altogether and have the runtime system find the function wherever it can (within reason :-) and let me know if it can't or if there's a conflict. I do understand that there are a great many programming contexts in which it would be foolish and dangerous to manage references so loosely and implicitly and dynamically. In fact it's a bad idea in some of my work too, so I'm slightly more disciplined than this some of the time. But my point is just that different users will have different priorities, and from where I sit, at least, it'd be nice to keep :use. -Lee -- -- 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: Can we please deprecate the :use directive ?
On Tue, Jul 23, 2013 at 3:26 PM, Gary Trakhman gary.trakh...@gmail.comwrote:
What's problematic about it is that it's slightly easier to do the wrong
thing. It seems insignificant, but 98% of times you use use, it's going to
be wrong. Also, 'use only' means I have to change my calling NS twice in
different parts of the emacs buffer any time I change a function name in
the called namespace.
On Tue, Jul 23, 2013 at 3:08 PM, Cedric Greevey cgree...@gmail.comwrote:
:use...:only doesn't strike me as especially problematic, since it
documents the specific symbols it's importing and from where.
Is it wrong 98% of the times you use :use...:only?
And if you change the name of the function fnname where it's defined,
yeah you'll have to change fnname wherever it's used as well, whether
those uses say fnname or mylib.core/fnname or m/fnname or even
(:require [mylib.core :refer :rename {fnname othername}]).
Of course, the latter suggests the question of whether it's wrong to use
:require ... :refer :only as well. :)
--
--
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: Can we please deprecate the :use directive ?
On Tue, Jul 23, 2013 at 12:57 PM, Lee Spector lspec...@hampshire.edu wrote: I'm sure I'm coming from a minority perspective on this, but for the kind of work I do it's often more important to be able to quickly sketch out and test ideas, without any ceremony about which functions come from where, than it is to ensure safety in a production environment which is really just me running it right now. In fact I'd sometimes like to go the other way and use everything in a whole directory subtree, or even to get rid of using altogether and have the runtime system find the function wherever it can (within reason :-) and let me know if it can't or if there's a conflict. I do understand that there are a great many programming contexts in which it would be foolish and dangerous to manage references so loosely and implicitly and dynamically. In fact it's a bad idea in some of my work too, so I'm slightly more disciplined than this some of the time. But my point is just that different users will have different priorities, and from where I sit, at least, it'd be nice to keep :use. Well, you can always use (require '[some.ns :refer :all]) instead of (use 'some.ns) but I recognize the former is a lot more typing. Certainly in the REPL, working in the user ns, I can see a good argument for (use 'some.ns) while you're evolving a solution, but I think :use in the ns macro should be deprecated (i.e., :use should at some point go away but perhaps the use function should stay for REPL-based exploration?). Tightening up the ns macro so it issues warning for undocumented constructs would also be a good idea: (ns some.ns (require [foo.bar :as f])) ;; supported and works, but really should be :require instead! -- 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: Can we please deprecate the :use directive ?
None of what has been said so far makes me believe that our usage of use is bad. It's like a rope, you can use it for useful purposes or you can hang yourself. You use it at your own taste and will. Lack of discipline does not constitute for me a reason to trash a feature as scarce as his usefulness seems to be. :refer :all can be used as badly as :use. I am not convinced that removing a facade and leaving the feature available through a backdoor makes life better for anyone. :use is easily searchable and quite obvious. Not sure about spotting :refer :all in 15 name space require clauses. You will simply end up say do not use refer all instead of warning against using use. Gee, What a lot of uses in this thread :) Luc P. One of the main issues I have faced with :use is, understanding a non-trivial codebase becomes very difficult and almost always requires Emacs Meta-dot. I'd vote for deprecating :use. Shantanu -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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: Can we please deprecate the :use directive ?
I think what we're proposing is not about removing the capability to do 'use'. That will remain, it's clojure after all. You could also implement it yourself easily enough. The issue is whether it's worthwhile to have it as a core function, without some kind of notice that better things exist. For instance, we have defrecords now, no one's going to reach for defstruct because records are documented and promoted more thoroughly. But 'use' is more pervasive, and also 'easier'. As the language grows, it'll be good for newcomers to have less things to think about, so deprecation is a way to counter bad inertia. The damage of 'use' is also less visible on the small scale, so that's why it's hard to make an argument about it. :require is proportionately more verbose for an effect. Use's verbosity is inversely proportional to its effect, so it takes extra effort to limit its effects. A limited scope by default is what I mean by 'good', for similar reasons that clojure goes with 'immutability by default'. On Tue, Jul 23, 2013 at 3:57 PM, Lee Spector lspec...@hampshire.edu wrote: On Jul 23, 2013, at 3:06 PM, Gary Trakhman wrote: Yea, I have a single namespace with project-specific common utilities which I refer to as u/some-util-function. For me, it's a bit scary to have implicit symbols in scope. A typo can make a local binding refer to something that might not exist in production, or at least not what's intended. Conversely, I don't want extra code in my project that has nothing to do with the project. Seems useful to enforce a separation of the artifact from the tools that made it, more-so for a lib that other things depend on than a production app. The 'user' namespace can cover the use-case of convenience functions? Or, you can add those symbols dynamically at run-time when you need to with something like: https://github.com/flatland/useful/blob/develop/src/flatland/useful/ns.clj#L26 or some aggregated (require ..) calls. I'm sure I'm coming from a minority perspective on this, but for the kind of work I do it's often more important to be able to quickly sketch out and test ideas, without any ceremony about which functions come from where, than it is to ensure safety in a production environment which is really just me running it right now. In fact I'd sometimes like to go the other way and use everything in a whole directory subtree, or even to get rid of using altogether and have the runtime system find the function wherever it can (within reason :-) and let me know if it can't or if there's a conflict. I do understand that there are a great many programming contexts in which it would be foolish and dangerous to manage references so loosely and implicitly and dynamically. In fact it's a bad idea in some of my work too, so I'm slightly more disciplined than this some of the time. But my point is just that different users will have different priorities, and from where I sit, at least, it'd be nice to keep :use. -Lee -- -- 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: Can we please deprecate the :use directive ?
On Tuesday, July 23, 2013 9:42:39 PM UTC+2, Shantanu Kumar wrote: One of the main issues I have faced with :use is, understanding a non-trivial codebase becomes very difficult and almost always requires Emacs Meta-dot. which is particularly annoying when you read code on a blog (as mentioned by the OP) or on paper I'd vote for deprecating :use. inc It complects require and refer ;-) stefan -- -- 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: Can we please deprecate the :use directive ?
On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen ska2...@gmail.comwrote: It complects require and refer ;-) How so? -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- 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: Can we please deprecate the :use directive ?
On Tue, Jul 23, 2013 at 1:53 PM, Ben Wolfson wolf...@gmail.com wrote: On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen ska2...@gmail.com wrote: It complects require and refer ;-) How so? Because use = require + refer (essentially). -- 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: Can we please deprecate the :use directive ?
On Jul 23, 2013, at 4:43 PM, Gary Trakhman wrote: For instance, we have defrecords now, no one's going to reach for defstruct because records are documented and promoted more thoroughly. FWIW I'm even a contrarian on defstruct :-! although I've switched to records anyway on account of speed. On Jul 23, 2013, at 4:55 PM, Sean Corfield wrote: Because use = require + refer (essentially). Is using :refer :all semantically identical to using :use? Or does essentially have a gap here? If it's identical then I guess I don't care much either way, although I'd prefer to stick with the shorter thing that's already in my code. -Lee -- -- 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: Can we please deprecate the :use directive ?
It's not as if *some* (cough cough) parts of Clojure were'nt opinionated, right? :-) Having in the (ns) macro the possibility to use :use, to use :require, to use :refer-clojure, to use :require-macros can be daunting, and not only for newcomers! And not to mention that the vast majority of the docstring for ns talks about :gen-class defaults ! And all this choice for only historical reasons is not opinionated enough for my taste! I'd be willing too, to deprecate a couple things: :use :all in favor of :require :all :use :only in favor of :require :only Let's be opinionated! :-D I think that's the only subset that has a chance to pass without having to gather a commitee at the next Clojure-conj ;-) 2013/7/23 Softaddicts lprefonta...@softaddicts.ca: None of what has been said so far makes me believe that our usage of use is bad. It's like a rope, you can use it for useful purposes or you can hang yourself. You use it at your own taste and will. Lack of discipline does not constitute for me a reason to trash a feature as scarce as his usefulness seems to be. :refer :all can be used as badly as :use. I am not convinced that removing a facade and leaving the feature available through a backdoor makes life better for anyone. :use is easily searchable and quite obvious. Not sure about spotting :refer :all in 15 name space require clauses. You will simply end up say do not use refer all instead of warning against using use. Gee, What a lot of uses in this thread :) Luc P. One of the main issues I have faced with :use is, understanding a non-trivial codebase becomes very difficult and almost always requires Emacs Meta-dot. I'd vote for deprecating :use. Shantanu -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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: anaphoric macro?
Thanks a lot guys, I'll try it out tomorrow. Anders -- -- 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: Can we please deprecate the :use directive ?
On Tue, Jul 23, 2013 at 1:55 PM, Sean Corfield seancorfi...@gmail.comwrote: On Tue, Jul 23, 2013 at 1:53 PM, Ben Wolfson wolf...@gmail.com wrote: On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen ska2...@gmail.com wrote: It complects require and refer ;-) How so? Because use = require + refer (essentially). If that's all that's required for one thing to complect two others, clojure's rife with the stuff. if-let complects if and let. Destructuring assignment complects assignment and getting values from a data structure (as the macroexpansion of (let [[a b] x]) demonstrates. split-with complects take-while and drop-while. let complects lambda abstraction and function application. Etc. I had assumed that a complects b and c on the one hand meant more than a can be expressed using b and c and on the other was a criticism. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- 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: Can we please deprecate the :use directive ?
Maybe we need an simpler alternative to the ns macro without all these complex options :) With a short name like ns-stop-banging-your-head-on-the-wall :) Or the reverse, ns-make-your-life-more-chaotic... :) Luc P. It's not as if *some* (cough cough) parts of Clojure were'nt opinionated, right? :-) Having in the (ns) macro the possibility to use :use, to use :require, to use :refer-clojure, to use :require-macros can be daunting, and not only for newcomers! And not to mention that the vast majority of the docstring for ns talks about :gen-class defaults ! And all this choice for only historical reasons is not opinionated enough for my taste! I'd be willing too, to deprecate a couple things: :use :all in favor of :require :all :use :only in favor of :require :only Let's be opinionated! :-D I think that's the only subset that has a chance to pass without having to gather a commitee at the next Clojure-conj ;-) 2013/7/23 Softaddicts lprefonta...@softaddicts.ca: None of what has been said so far makes me believe that our usage of use is bad. It's like a rope, you can use it for useful purposes or you can hang yourself. You use it at your own taste and will. Lack of discipline does not constitute for me a reason to trash a feature as scarce as his usefulness seems to be. :refer :all can be used as badly as :use. I am not convinced that removing a facade and leaving the feature available through a backdoor makes life better for anyone. :use is easily searchable and quite obvious. Not sure about spotting :refer :all in 15 name space require clauses. You will simply end up say do not use refer all instead of warning against using use. Gee, What a lot of uses in this thread :) Luc P. One of the main issues I have faced with :use is, understanding a non-trivial codebase becomes very difficult and almost always requires Emacs Meta-dot. I'd vote for deprecating :use. Shantanu -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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,
Re: Can we please deprecate the :use directive ?
2013/7/23 Softaddicts lprefonta...@softaddicts.ca: Maybe we need an simpler alternative to the ns macro without all these complex options :) With a short name like ns-stop-banging-your-head-on-the-wall :) would violate the rule use often = short name ;-) Or the reverse, ns-make-your-life-more-chaotic... Deal :-D :) Luc P. It's not as if *some* (cough cough) parts of Clojure were'nt opinionated, right? :-) Having in the (ns) macro the possibility to use :use, to use :require, to use :refer-clojure, to use :require-macros can be daunting, and not only for newcomers! And not to mention that the vast majority of the docstring for ns talks about :gen-class defaults ! And all this choice for only historical reasons is not opinionated enough for my taste! I'd be willing too, to deprecate a couple things: :use :all in favor of :require :all :use :only in favor of :require :only Let's be opinionated! :-D I think that's the only subset that has a chance to pass without having to gather a commitee at the next Clojure-conj ;-) 2013/7/23 Softaddicts lprefonta...@softaddicts.ca: None of what has been said so far makes me believe that our usage of use is bad. It's like a rope, you can use it for useful purposes or you can hang yourself. You use it at your own taste and will. Lack of discipline does not constitute for me a reason to trash a feature as scarce as his usefulness seems to be. :refer :all can be used as badly as :use. I am not convinced that removing a facade and leaving the feature available through a backdoor makes life better for anyone. :use is easily searchable and quite obvious. Not sure about spotting :refer :all in 15 name space require clauses. You will simply end up say do not use refer all instead of warning against using use. Gee, What a lot of uses in this thread :) Luc P. One of the main issues I have faced with :use is, understanding a non-trivial codebase becomes very difficult and almost always requires Emacs Meta-dot. I'd vote for deprecating :use. Shantanu -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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
Re: Can we please deprecate the :use directive ?
On Tuesday, July 23, 2013 11:13:11 PM UTC+2, Ben wrote: On Tue, Jul 23, 2013 at 1:55 PM, Sean Corfield seanco...@gmail.comjavascript: wrote: On Tue, Jul 23, 2013 at 1:53 PM, Ben Wolfson wol...@gmail.comjavascript: wrote: On Tue, Jul 23, 2013 at 1:50 PM, Stefan Kamphausen ska...@gmail.comjavascript: wrote: It complects require and refer ;-) How so? Because use = require + refer (essentially). If that's all that's required for one thing to complect two others, clojure's rife with the stuff. if-let complects if and let. Destructuring assignment complects assignment and getting values from a data structure (as the macroexpansion of (let [[a b] x]) demonstrates. split-with complects take-while and drop-while. let complects lambda abstraction and function application. Etc. I had assumed that a complects b and c on the one hand meant more than a can be expressed using b and c and on the other was a criticism. you're right. I did not think a lot before writing the above. Please, don't take it too seriously. Kind regards, Stefan -- -- 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: Can we please deprecate the :use directive ?
On Tue, Jul 23, 2013 at 2:13 PM, Ben Wolfson wolf...@gmail.com wrote: If that's all that's required for one thing to complect two others, clojure's rife with the stuff. if-let complects if and let. Destructuring assignment complects assignment and getting values from a data structure (as the macroexpansion of (let [[a b] x]) demonstrates. Those examples provide an overall simplification for common constructs. As the 'use' docstring says, it is Like 'require, but also refers to each lib's namespace using clojure.core/refer. so it explicitly combines two already somewhat complex operations. When we added :refer to 'require' we also complected things but we improved expressiveness and we allowed the overall 'ns' construct to be more uniform and consistent so I think, on balance, that was a win (and I certainly like having one construct - :require - in my ns declarations rather than a mix of :use and :require). We probably should have taken that opportunity to deprecate :use at the same time but as I recall, :refer was added very late in the cycle and arguing over deprecating :use would have detracted from the discussion of the utility of adding :refer to :require in the first place. -- 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: Can't get namespace metadata
As an aside from this, how problematic is AOT compilation? It seems to be
the source of many bugs (for example, my own
CLJ-1227http://dev.clojure.org/jira/browse/CLJ-1227).
Is there a list anywhere of things to watch out for when AOT compiling?
On 24 July 2013 04:06, Stuart Sierra the.stuart.sie...@gmail.com wrote:
I can confirm this behavior. It's not the fault of the `ns`
macro, however. This works just fine:
user= (ns ^{:doc This is foo} foo)
nil
foo= (in-ns 'user)
#Namespace user
user= (meta (the-ns 'foo))
{:doc This is foo}
AOT-compilation appears to be the culprit (as usual). This
has been known for a long time, see CLJ-130, which I just
updated.
[CLJ-130]: http://dev.clojure.org/jira/browse/CLJ-130
-S
On Saturday, July 20, 2013 8:50:18 AM UTC-4, Alexander Yakushev wrote:
Example:
user= (meta (find-ns 'clojure.set))
nil
user= (meta (find-ns 'clojure.string))
nil
user= (meta (find-ns 'clojure.core))
{:doc Fundamental library of the Clojure language}
clojure.core is the only namespace that has metadata. Apparently because
it has metadata set differently https://github.com/clojure/**
clojure/blob/master/src/clj/**clojure/core.clj#L6158https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6158,
so I blame *ns *macro.
I tested this with clojure 1.2-1.5, so it is not a regression, and unless
I'm doing something wrong, this was broken from the beginning.
--
--
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: cannot import namespace reducers
Please spam the list!!! I am sure anyone who receives that message is probably running Mac OS X 10.7.x or later and trying to unravel the mess between Java 6 and Java 7. Please post recommendations. I finally got Eclipse to see the jdl1.7.0_25.jdk now how do I get the OS to replace the Apple installed 1.6.x? On Sunday, 16 June 2013 17:29:40 UTC-4, Las wrote: Then you are having a path problem. Your lein is still using java6 Check your $PATH and $JAVA_HOME env. variables. As this not strictly clojure related, let's not spam the list, im happy to help off list Sent from my phone On Jun 16, 2013 11:22 PM, Johannes Brauer bra...@nordakademie.dejavascript: wrote: I am on clojure 1.5.1 and I use lein repl. But after (require '[clojure.core.reducers :as r]) I still get the same error message as with Java 6: CompilerException java.lang.ClassNotFoundException: jsr166y.ForkJoinPool, compiling:(clojure/core/reducers.clj:56:21) A second input of (require '[clojure.core.reducers :as r]) generates the message: Exception namespace 'clojure.core.reducers' not found clojure.core/load-lib (core.clj:5380) Johannes Am 16.06.2013 um 23:16 schrieb László Török ltor...@gmail.comjavascript: : are you on clojure 1.5+ ? If I launch the REPL using lein repl and then (require 'clojure.core.reducers) it works ok for me. 2013/6/16 Johannes Brauer bra...@nordakademie.de javascript: now, I've Java 7 installed and get another error message: Exception namespace 'clojure.core.reducers' not found clojure.core/load-lib (core.clj:5380) any further hints? Johannes Am 16.06.2013 um 22:43 schrieb Johannes Brauer bra...@nordakademie.dejavascript: : thank you, Las, for the quick tip. I will give Java 7 a try. I hope there are no problems on Mac OS 10.8.4 Johannes Am 16.06.2013 um 22:15 schrieb László Török ltor...@gmail.comjavascript: : .. sorry, gmail's new annoying keyboard shortcut b) include the dependency to the forkjoin library [1] that is not included in Java6 Las [1] http://mavenhub.com/mvn/central/org.coconut.forkjoin/jsr166y/070108 2013/6/16 László Török ltor...@gmail.com javascript: Hi, there are two ways to deal with this: a) use Java 7 2013/6/16 Johannes bra...@nordakademie.de javascript: Hi, trying (require '[clojure.core.reducers :as r]) at the repl prompt the error message CompilerException java.lang.ClassNotFoundException: jsr166y.ForkJoinPool, compiling:(clojure/core/reducers.clj:56:21) What is going wrong? Johannes -- -- 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. -- László Török -- László Török -- -- 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. -- Staatlich anerkannte private Fachhochschule NORDAKADEMIE Gemeinnützige Aktiengesellschaft Köllner Chaussee 11 25337 Elmshorn Vorstand: Prof. Dr. Georg Plate (Vorsitzender), Dipl.-Ing. Jörg Meier (stellv. Vorstand) Vorsitzender des Aufsichtsrats: Dr. h.c. Hans-Heinrich Bruns Sitz: Elmshorn, Amtsgericht Pinneberg, HRB 1682 -- -- 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 ---
Re: Can we please deprecate the :use directive ?
On Tuesday, July 23, 2013 11:50:50 AM UTC-4, Greg Slepak wrote: I think I read somewhere that :use is no longer encouraged, but I could be mistaken. From what I've read, it seems like most people agree that Clojure has too many ways of including/importing/referencing/requiring/using things: http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html The above gives a very nice explanation of all the various difference, but it also acknowledges their complexity. Since :use uses :require, and since :require can do everything that :use can, can we simplify Clojure programming a bit for newcomers by deprecating the use of :use? The situation in ClojureScript is even worse because it adds :require-macros on top of all the other ways of including files. Ideally, it would be awesome if there was just a single directive for everything, but perhaps there's some complicated low-level reason why that's not possible. :-\ Thoughts? I find that use of `:use` makes code more difficult to read. Names from clojure.core are written without the namespace; everything else I expect to see a namespace in front to provide context. Yes, I also write dates like -MM-DD. :) -- John -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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] verily, non-magic testing lib
https://github.com/evanescence/verily Verily is a new testing lib with a few goals: - Build off existing Clojure concepts (functions, vars, etc) - Be as functional/immutable as possible - Be easy to use from terminal or REPL - Have composable pieces that are easy to swap out - Keep running tests separate from reporting the results Some upcoming features: - Some convenience functions for assertions - Better reports -Steven -- -- 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.
Confused again by core.async
Hi, I hope I can get a lightbulb on what's happening here: https://github.com/nodename/async-plgd/blob/master/src/hoare/problem.clj Testing fan-in on a pair of processes and getting nutty results. Thanks, -A -- -- 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] verily, non-magic testing lib
Whoops. Looks like I didn't check the namespace well enough, there's already a lib called verily. (Sorry Justin.) Will think up a new name soon. On Tue, Jul 23, 2013 at 11:55 PM, Steven Degutis sbdegu...@gmail.comwrote: https://github.com/evanescence/verily Verily is a new testing lib with a few goals: - Build off existing Clojure concepts (functions, vars, etc) - Be as functional/immutable as possible - Be easy to use from terminal or REPL - Have composable pieces that are easy to swap out - Keep running tests separate from reporting the results Some upcoming features: - Some convenience functions for assertions - Better reports -Steven -- -- 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.
