Re: Leiningen documentation review?
> But if you've got some time to look over the readme, that would be > great too: http://github.com/technomancy/leiningen/blob/master/README.md Unnecessary (and ironic! :)) repetition of the word "around" in this sentence: If you use Ant, you end up copying around a lot of the same tasks around between XML files on all your projects; there's a lot of repetition. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen documentation review?
Hi Phil, On Wed, 16 Jun 2010 21:24:55 -0700 Phil Hagelberg wrote: > I'm pushing for a Leiningen 1.2.0 release really soon now, and part of > that effort is sprucing up the documentation. I've revamped the readme > and added a tutorial for folks just getting started. Of course, > self-editing is never as good as having outside help, so I'd love it > if I could get some feedback on it. I'm particularly interested in > opinions from people who are just starting out with Clojure--it's easy > for me to take things for granted that not everyone understands. > > Mostly I'd like feedback on the tutorial: > http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md > I had a problem with lein that it did not compile all of my files and after quite a while I discovered that I had to tell lein about it in projects.clj by adding a :namespaces statement. Well, don't know if this is the intended solution but it worked for me. Perhaps something like this should be mentioned in the documentation. -- Thanks, Manfred -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen documentation review?
> Mostly I'd like feedback on the tutorial: > http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md This sentence: "Libraries for the JVM are packaged up as .jar files, which are basically just .zip files with a little extra JVM-specific metadata that contain either .class files (bytecode) or .clj source files." needs reorganization. It's unclear whether the .class/.clj files are contained in the .jar or in the metadata. Additionally, it's unclear in the next sentence: "These jar files are available through repositories that serve them up over HTTP alongside their metadata." whether that's the same metadata or something else. - In this sentence: "In general relying on snapshot dependencies is discouraged, but sometimes its necessary if you need bug fixes etc. that have not made their way into a release yet." s/its/it's/ or better yet (IMO) use "but is sometimes necessary". -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: basic help with netbeans/enclojure installation
Thanks all. I've now installed NetBeans 6.8 and modulo a couple of update cycles on components everything went smoothly and I'm now running NetBeans/Enclojure. Perhaps the getting started instructions ought to include a comment about the required NetBeans version. -Lee On Jun 17, 2010, at 1:02 AM, Drew Vogel wrote: > You can easily download old releases of NetBeans. From the netbeans.org front > page click on "Download FREE". On that page click on "Archive" in the upper > right corner. Finally look for the version select box on the right side of > the page. > > IANAL, but I believe the license of each project allows you to distribute the > compatible versions together via your class's website or CDs that you hand > out in class, etc. > > > > > On Wed, Jun 16, 2010 at 6:05 PM, Lee Spector wrote: > > I'm using NetBeans 6.9, which is just what happened to be there when I went > to try this today. > > Maybe I should be trying a different environment if this is going to depend > on the netbeans version or require more manual installation. > > I'm hoping to find something that doesn't require manual git pulls or jumping > through other hoops, in part because I'll be using it with students who'll > have to set up on their own machines and I want that to be painless. Minimum > functionality is a REPL and an editor with Clojure indentation and > parentheses matching. Other stuff like > debugging/profiling/builtin-documentation would be great but if I can get the > minimum with a no-hassle installation then I'll be happy, and the no-hassle > installation part is really the most important thing. > > I'm personally using an emacs setup but that installation was not hassle free > and I don't want to make my students learn emacs anyway. Last time I tried > the Eclipse route it wasn't too bad but I found the environment confusingly > complex and there wasn't Clojure indentation, which I think is really > necessary. Ideally I'll use something cross platform, but I might use MCLIDE > if it's the best thing going -- last I tried it it still required jumping > through some hoops and didn't seem quite ready for prime time yet. > > Any advice would be appreciated. > > Thanks, > > -Lee > > On Jun 16, 2010, at 6:46 PM, Stefan Kamphausen wrote: > > > Hi, > > > > On Jun 17, 12:29 am, Lee Spector wrote: > >> - Go to the 'Avalilable Plugins' tab and select the "Enclojure Clojure > >> Plugin and click Install > >> > >> When I do it fails with the following messages: > >> > >> - > >> Some plugins require plugin Common Scripting Language API (new) to be > >> installed. > > > > I had some very similar problems some weeks ago, when I tried this, > > too. At that time I used Netbeans 6.7 and 6.9 wasn't yet released. > > After I installed Netbeans 6.8 things went almost smooth. I had to do > > a manual git pull in the created labrepl project. > > > > After that it's justing waiting for Maven to finish which took *quite* > > a while with my slow connection at home. I could even use the > > debugger to step clojure programs (after using that funny/ugly trick > > with a dummy java class). > > > > > > Cheers, > > 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 > > -- > Lee Spector, Professor of Computer Science > School of Cognitive Science, Hampshire College > 893 West Street, Amherst, MA 01002-3359 > lspec...@hampshire.edu, http://hampshire.edu/lspector/ > Phone: 413-559-5352, Fax: 413-559-5438 > > Check out Genetic Programming and Evolvable Machines: > http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To 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 -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West St
Re: Leiningen documentation review?
Hi Phil, I read through both the tutorial and the readme, and both seem to be pretty clear (though I'm not a new user). They're certainly an improvement on what came before, and it seems to be a pretty solid introduction. Perhaps though, there should be some mention of how the clojure and contrib jars and versions are also included in the project.clj, and are therefore included as a project level dependency An approach that is different from what Ruby programmers are used to with gems (i.e. leiningen also manages platform versions) (though not JVM ones). Explaining this might help people transition from playing with raw clojure builds, to using lein to build real projects. Another comment I have, is that lein's use of lancet isn't especially well documented. This is perhaps more of a deficiency in Lancets documentation, which really needs documenting... especially now that it's a dependency on lein, which is fast becoming a critical tool for most clojure projects. I mention this, because I've written some lein plugins for projects, where my plugins used lancet to perform some additional ant type tasks, e.g. moving files about etc... Lancet itself doesn't seem to wrap all of ant; and it's hard to know where it stops. For example, recently I tried to use lancet to write a lein plugin that would exec another O/S script passing specific parameters to the command. I can't remember the details now, but I seem to remember finding it wasn't possible to pass args to the command. Things like this should be clearer for developers wishing to extend lein further... whether or not this lies in lancets documentation or leins. Anyway, again, great work with lein! R. On 17 June 2010 05:24, Phil Hagelberg wrote: > I'm pushing for a Leiningen 1.2.0 release really soon now, and part of > that effort is sprucing up the documentation. I've revamped the readme > and added a tutorial for folks just getting started. Of course, > self-editing is never as good as having outside help, so I'd love it > if I could get some feedback on it. I'm particularly interested in > opinions from people who are just starting out with Clojure--it's easy > for me to take things for granted that not everyone understands. > > Mostly I'd like feedback on the tutorial: > http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md > > But if you've got some time to look over the readme, that would be > great too: http://github.com/technomancy/leiningen/blob/master/README.md > > Thanks! > > -Phil > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Gwt-Clojure - lightweight browser implementation
I will release an open source version of Gwt-Clojure next week. My approach to building web applications is based on "frame technology" which has been used commercially in mainframe code generation for nearly 30 years. You build a library of data structures (frames) that describe an application and then send it to a code generator to write the application. I have used Clojure to build my frame engine. Gwt-Clojure was developed to make scripting easier on the client side. In summary, my approach is to build web apps 100% in Lisp. On Jun 16, 6:50 pm, Rick Moynihan wrote: > Neat! > > I'm currently writting a webapp with GWT for the browser client, and > clojure on the server... What is your approach to doing this, and is > the code available anywhere yet? > > R. > > On 15 June 2010 19:48, pfisk wrote: > > > > > Gwt-Clojure is a subset of the Clojure language which was developed > > for scripting GWT (Google Windows Toolkit) widgets in the browser > > environment. It is designed to be able to share code with Clojure > > running on the server. > > > The current deployment size is about 145kb of Javascript - including > > the interpreter and several GWT widget classes. > > > Test environment:http://wisperweb.appspot.com/ > > > Gwt-Clojure blog post:http://framegen.wordpress.com/2010/06/15/gwt-clojure/ > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- 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
Installing labrepl on netbeans 6.8, problem building labrepl project
Hello everybody! I followed the instructions given...everything ok till when I try to build the labrepl project, it builds till 37% and then stops with this output [ERROR]Transitive dependency resolution for scope: compile has failed for your project. [ERROR]Error message: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. [ERROR] org.incanter:incanter-mongodb:jar:1.2.0-20100327.041516-10 [ERROR]from the specified remote repositories: [ERROR] build.clojure.org (http://build.clojure.org/snapshots), [ERROR] ibiblio (http://www.ibiblio.org/maven2), [ERROR] central (http://repo1.maven.org/maven2), [ERROR] clojars (http://clojars.org/repo/), [ERROR] clojars.org (http://clojars.org/repo), [ERROR] incanter (http://repo.incanter.org), [ERROR] clojure-snapshots (http://build.clojure.org/snapshots), [ERROR] clojure (http://build.clojure.org/releases), [ERROR] clojure-releases (http://build.clojure.org/releases) [ERROR]Path to dependency: [ERROR]1) labrepl:labrepl:jar:0.0.1 [ERROR]2) org.incanter:incanter-full:jar:1.2.0-SNAPSHOT [ERROR]3) org.incanter:incanter-mongodb:jar:1.2.0-SNAPSHOT [ERROR]Group-Id: labrepl [ERROR]Artifact-Id: labrepl [ERROR]Version: 0.0.1 [ERROR]From file: D:\Trabalho\NetBeansProjects\RelevanceLabRepl \pom.xml Actually before that I saw a warning that could be related to this: WARNING: You are running embedded Maven builds, some build may fail due to incompatibilities with latest Maven release. To set Maven instance to use for building, click here. Anybody have an idea about what went wrong? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Gwt-Clojure - lightweight browser implementation
Hi, Seems real interesting ! What I was not able to understand by reading your blog post, is which subset of clojure you ported to the client side ? Is it just a declarative API for the widgets part, or will it be possible, as with GWT java client side code, to embed logic,etc ? will it be possible to use atoms for managing state mutation, wiring fns as asynchronous callback functions , etc. ? 2010/6/17 pfisk : > I will release an open source version of Gwt-Clojure next week. > > My approach to building web applications is based on "frame > technology" which has been used commercially in mainframe code > generation for nearly 30 years. You build a library of data structures > (frames) that describe an application and then send it to a code > generator to write the application. I have used Clojure to build my > frame engine. Gwt-Clojure was developed to make scripting easier on > the client side. In summary, my approach is to build web apps 100% in > Lisp. > > > On Jun 16, 6:50 pm, Rick Moynihan wrote: >> Neat! >> >> I'm currently writting a webapp with GWT for the browser client, and >> clojure on the server... What is your approach to doing this, and is >> the code available anywhere yet? >> >> R. >> >> On 15 June 2010 19:48, pfisk wrote: >> >> >> >> > Gwt-Clojure is a subset of the Clojure language which was developed >> > for scripting GWT (Google Windows Toolkit) widgets in the browser >> > environment. It is designed to be able to share code with Clojure >> > running on the server. >> >> > The current deployment size is about 145kb of Javascript - including >> > the interpreter and several GWT widget classes. >> >> > Test environment:http://wisperweb.appspot.com/ >> >> > Gwt-Clojure blog post:http://framegen.wordpress.com/2010/06/15/gwt-clojure/ >> >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Clojure" group. >> > To post to this group, send email to clojure@googlegroups.com >> > Note that posts from new members are moderated - please be patient with >> > your first post. >> > To unsubscribe from this group, send email to >> > clojure+unsubscr...@googlegroups.com >> > For more options, visit this group at >> >http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Enhanced Primitive Support
I've been doing some work to enhance the performance, and unify the semantics, of primitives, in three branches. I've started to document this work here: https://www.assembla.com/wiki/show/clojure/Enhanced_Primitive_Support Feedback welcome, Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: working with agents and atoms - a beginner question
After reading your posts and thinking "wouldn't it be nice to just kick off a thread and not care about the return value" I recall Rich using/liking [1] the Java Executor framework [2]. I looked at clojure.lang.Agent and saw it used there, too. It's tricky because I wouldn't want to lean on Java too much for something this fundamental or go too far without expecting to have to code something as complicated as what's found in core.clj (with possible java mechanics as found in RT.java). I picture wanting a system that can kick off workers (Executor framework) that only needs start() and join() semantics. I haven't gone through all the Executor and related stuff yet so I still need to read about everything that's available. - - - [1] http://clojure.org/concurrent_programming [2] http://www.ibm.com/developerworks/java/library/j-jtp1126.html On Wed, Jun 16, 2010 at 3:51 PM, Meikel Brandmeyer wrote: > Hi, > > Am 16.06.2010 um 22:34 schrieb Christophe Grand: > >> I agree, it still feels a little dirty to use a future without caring >> about the return value but on the positive said you get an easy way to >> block and wait for the tread to finish (deref) and you also get >> future-done?, future-cancel and future-cancelled which can prove >> useful. > > True. This infrastructure is an incentive to use future. Maybe one can wash > away the dirty feeling by believing, that deref'ing is actually a > syncronisation point of sorts and the return value just a "side-effect". > > Sincerely > Meikel > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
clojure.contrib.logging in "side-effect free" functions?
Hi.
I have just started learning Clojure and I am really enjoying
myself. However, I am still getting to grips with the workings of its
concurrency model, so please excuse me if my question seems too
obvious.
I have some code that reads data from a file, parses it and generates
a CSV file. The flow is as follows:
(use 'clojure.contrib.duck-streams)
(use 'clojure.contrib.pprint)
(defn parse-line [s]
(cl-format nil "~{\"~A\"~^,~}" (into [] (.split s ";"
(let [input-seq (for [line (read-lines "input.dat")]
(parse-line line))]
(write-lines "out.CSV" input-seq))
Now the question:
I would like to generate log entries for any malformed lines occurring
in the input file. Once of the ways might be to do this in parse-line
using clojure.contrib.logging as follows:
(use 'clojure.contrib.logging)
(defn parse-line [s]
(let [cs (into [] (.split s ";"))]
(if (= (count cs) 5)
(cl-format nil "~{\"~A\"~^,~}" cs)
(error "Incorrect number of columns in file."
Since FOR returns a lazy sequence of the results, is this function
safe? (Seeing that it is not side-effect free?)
BTW:
clojure.contrib.logging indicates that it can use an agent for
logging. Is my assumption that invoking the logger (with or without
an agent) within a function would still mean that the function has
side-effects correct?
Martin.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Installing labrepl on netbeans 6.8, problem building labrepl project
I will take a look at this tomorrow morning. Can you please file an issue for it on github? Cheers, Aaron Sent from my iPhone On Jun 17, 2010, at 9:11 AM, Filipe M R wrote: Hello everybody! I followed the instructions given...everything ok till when I try to build the labrepl project, it builds till 37% and then stops with this output [ERROR]Transitive dependency resolution for scope: compile has failed for your project. [ERROR]Error message: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. [ERROR] org.incanter:incanter-mongodb:jar:1.2.0-20100327.041516-10 [ERROR]from the specified remote repositories: [ERROR] build.clojure.org (http://build.clojure.org/snapshots), [ERROR] ibiblio (http://www.ibiblio.org/maven2), [ERROR] central (http://repo1.maven.org/maven2), [ERROR] clojars (http://clojars.org/repo/), [ERROR] clojars.org (http://clojars.org/repo), [ERROR] incanter (http://repo.incanter.org), [ERROR] clojure-snapshots (http://build.clojure.org/snapshots), [ERROR] clojure (http://build.clojure.org/releases), [ERROR] clojure-releases (http://build.clojure.org/releases) [ERROR]Path to dependency: [ERROR]1) labrepl:labrepl:jar:0.0.1 [ERROR]2) org.incanter:incanter-full:jar:1.2.0-SNAPSHOT [ERROR]3) org.incanter:incanter-mongodb:jar:1.2.0-SNAPSHOT [ERROR]Group-Id: labrepl [ERROR]Artifact-Id: labrepl [ERROR]Version: 0.0.1 [ERROR]From file: D:\Trabalho\NetBeansProjects\RelevanceLabRepl \pom.xml Actually before that I saw a warning that could be related to this: WARNING: You are running embedded Maven builds, some build may fail due to incompatibilities with latest Maven release. To set Maven instance to use for building, click here. Anybody have an idea about what went wrong? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Problems with URL params and http-agent
On Wed, Jun 16, 2010 at 6:21 PM, Timothy Washington wrote: > Hey all, something very weird happens when trying to use the http-agent. If > I execute a) or b) in a browser, I get the desired result XML. > a) http://RESTful/path/to/xml > b) http://RESTful/path/to/xml?_wrap=no&_query=declare default element > namespace 'com/interrupt/bookkeeping/users';//user[ @id='one'] It's hard to say without the specific error you're seeing and what service you're hitting, but one technique I've used for debugging HTTP calls is to setup netcat on another port. Then make the same requests with the browser and library to the new port and compare netcat's output. Perhaps they are escaping the paths differently. Cheers, Jim -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ICFP 2010 in Clojure
Hi, I'm in the California bay area and am interested in participating in ICFP 2010, programming exclusively in Clojure. Is anyone in the area interested in participating, collaborating, or learning? Mike -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Problems with URL params and http-agent
You don't want to encode the whole URL, just the keys and values in the query string. Something like this: (defn encode-params [request-params] (let [encode #(URLEncoder/encode (str %) "UTF-8") coded (for [[n v] request-params] (str (encode n) "=" (encode v)))] (apply str (interpose "&" coded On Jun 16, 9:21 pm, Timothy Washington wrote: > Hey all, something very weird happens when trying to use the http-agent. If > I execute a) or b) in a browser, I get the desired result XML. > a)http://RESTful/path/to/xml > b)http://RESTful/path/to/xml?_wrap=no&_query=declaredefault element > namespace 'com/interrupt/bookkeeping/users';//user[ @id='one'] > > However, using clojure, If I try the same call, d) in this case will NOT > work. > c) (clojure.contrib.http.agent/http-agent "http://RESTful/path/to/xml";) > ; works > d) (clojure.contrib.http.agent/http-agent > "http://RESTful/path/to/xml?_wrap=no&_query=declaredefault element namespace > 'com/interrupt/bookkeeping/users';//user[ @id='one']") ; doesn't > work > > I've tried url-encoding the url using the below function, but that doesn't > help either. > (defn url-encode [text] > (URLEncoder/encode text "UTF-8")) > > Is the something obvious I'm missing? > 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
Miscellaneous noob questions
I'm a little confused over when to use a var vs. a ref vs. an agent vs. an atom. For writing small (<200 lines) single-threaded programs when do I want to use each one? Also, since you can use def to change a binding how do I know for sure that some function is not generating side-effects? I mean if it's my code I can be somewhat confident about what it's doing, but if it is a blackbox function how can I trust it? A very crude example would be something like: (defn square [n] (def x n) (def n 6) (* x x)) I've ran that in the repl and it doesn't change the values of what is passed to it, but is the same true for multithreaded apps? What if between (def n 6) and (* x x)) a different thread requested the value of n? Basically, I want to know when is immutability guaranteed? What is a form? In this overview of clojure, it talks about bindings and forms. The fragment that I am trying to understand is "The let special form creates bindings that are local to that form". http://java.ociweb.com/mark/clojure/article.html#Bindings Thanks in advance. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: basic help with netbeans/enclojure installation
On Jun 16, 6:29 pm, Lee Spector wrote: > Starting from scratch, both to try it myself and to know what to tell my > students in the fall, when I'll want them all (regardless of background) to > be able to set up a reasonable Clojure environment without hassles. I've > never previously used netbeans. I'm doing this on a Mac running MacOS 10.6.3. > > I tried to follow the instructions > athttp://www.assembla.com/wiki/show/clojure/Getting_Started_with_Netbea...and > this is what happened: > > - Install NetBeans You need only the Java SE version. > > Done -- no problem. > > - If you’ve just installed Netbeans, activate feature Java SE: > - Activate features is on the Start page > - or from Tools, Plugins, Installed > > I don't see "Activate features" on the start page. Poked around (there are > three tabs...) but still didn't see it. Went to Tools, Plugins, Installed and > saw that there wasn't just one Java SE item but rather many. Checked all of > them. Now that I return to it I see that everything has a checkmark under > Active, so perhaps it was all activated initially and I didn't notice? In any > event I suppose it's all activated now. I recently installed netbeans and I did not see activate features either. So I skipped that step. I added the url for the plugin, and downloaded it. That worked on my desktop running Ubuntu 10.04. I am having problems on my netbook with Ubuntu 9.04, but the problems seem unrelated to the plugin, and are probably due to java and gnome in general. My suggestion would be to reinstall netbeans, but this time don't check anything. Add the URL, install the plugin and see if that works. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
I think the enhanced support for primitives is fantastic. I'm looking forward to doing more numerical work in clojure. Quibble: Using a multiple-recursive algorithm for calculating fibonnaci values. user> (defn fib-2 [n] (if (>= n 1) (loop [i 0 f0 0 f1 1] (if (== i n) f0 (recur (inc i) f1 (+ f0 f1)) #'user/fib-2 user> (time (fib-2 38)) "Elapsed time: 0.12 msecs" 39088169 I understand that it's just for demonstration purposes, but impressionable people (like me!) might not know better. (Of course, we can calculate fibonacci values using the closed form formula, but that's neither here nor there.) Other than that, looks great. Rob On Jun 17, 1:13 pm, Rich Hickey wrote: > I've been doing some work to enhance the performance, and unify the > semantics, of primitives, in three branches. I've started to document > this work here: > > https://www.assembla.com/wiki/show/clojure/Enhanced_Primitive_Support > > Feedback welcome, > > Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Jun 17, 5:10 pm, Rob Lachlan wrote: > I think the enhanced support for primitives is fantastic. I'm looking > forward to doing more numerical work in clojure. > > Quibble: Using a multiple-recursive algorithm for calculating > fibonnaci values. > > user> (defn fib-2 [n] (if (>= n 1) > (loop [i 0 f0 0 f1 1] > (if (== i n) f0 (recur (inc i) > f1 > (+ f0 f1)) Naive fib is often used as a benchmark, the point being not to do a fast fib, but comparative, 'what is the perf on naive fib'? Not being tail-recursive, it tests function calling overhead, and thus here demonstrates what we gain by not having to box on args and returns. Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
Ah -- well that makes sense then. Bravo! Rob On Jun 17, 2:15 pm, Rich Hickey wrote: > On Jun 17, 5:10 pm, Rob Lachlan wrote: > > > I think the enhanced support for primitives is fantastic. I'm looking > > forward to doing more numerical work in clojure. > > > Quibble: Using a multiple-recursive algorithm for calculating > > fibonnaci values. > > > user> (defn fib-2 [n] (if (>= n 1) > > (loop [i 0 f0 0 f1 1] > > (if (== i n) f0 (recur (inc i) > > f1 > > (+ f0 f1)) > > Naive fib is often used as a benchmark, the point being not to do a > fast fib, but comparative, 'what is the perf on naive fib'? Not being > tail-recursive, it tests function calling overhead, and thus here > demonstrates what we gain by not having to box on args and returns. > > Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Miscellaneous noob questions
Regarding your def question, it never makes sense to use def inside of
a function.
In Javascript, you might do this:
{
var a = 1;
var b = 2;
...some statements that might use a and b...
}
Nothing outside of the curly braces can use those definitions of a and
b. The let form is a similar
thing;
(let [a 1
b 2]
(... some stuff that might use a and b...)
)
Nothing past that last closing parenthesis (the one that matches the
open parenthesis before the "let") knows about the definitions of a
and b. I think the term "form" just means "stuff between
parentheses".
Bill Smith
Austin, TX
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Miscellaneous noob questions
> I'm a little confused over when to use a var vs. a ref vs. an agent > vs. an atom. For writing small (<200 lines) single-threaded programs > when do I want to use each one? Vars are intended for global data that is not normally modified, except that they can be re-bound thread-locally. http://clojure.org/special_forms#def At the end you will see the recommentation: "Using def to modify the root value of a var at other than the top level is usually an indication that you are using the var as a mutable global, and is considered bad style. Consider either using binding to provide a thread-local value for the var, or putting a ref or agent in the var and using transactions or actions for mutation." Probably the most common use of vars is to refer to functions. The fact that their values can be changed means that you can re-load code and have new function definitions take effect during runtime; so there is an inherent desire to allow such mutations. This use is pretty similar to a shared global variable in C/C++/Java. The other common type of use is thread-local re-binding. So for example, standard out is *out* in clojure: user=> *out* # And you can thread-locally re-bind this without modifying it's global root binding: (binding [*out* (open-some-file)] (println "this will be printed to the file instead of stdout")) Doing so never affects other threads, and so covers a common use case of C/C++/Java style shared globals, except that you can safely override their values without the usual pitfalls. Atoms are for anything that you need to mutate atomically but without co-ordination. One example is a counter that keeps some kind of statistic: (def request-count (atom 0)) ... (swap! request-count inc) Here the request-count var is shared, but it's value is an atom which can be efficiently (relative to e.g. a ref) incremented by multiple threads without co-ordinating their access to the atom. Atoms are described here: http://clojure.org/atoms Refs are intended for mutation within transactions (and they enforce that fact); typically they are used when you need to update multiple things atomically, or an update is dependent on one or more reads of other refs. They are described here: http://clojure.org/refs Agents are described here: http://clojure.org/agents > Also, since you can use def to change a binding how do I know for sure > that some function is not generating side-effects? There is no guarantee; clojure does not try to provide a hard guarantee that no side-effects happen when you call some arbitrary function whose implementation you don't know or trust. However modification of shared state is very different from the usual local bindings used in clojure, that you do not easily do so by 'mistake'. > I mean if it's my > code I can be somewhat confident about what it's doing, but if it is a > blackbox function how can I trust it? A very crude example would be > something like: > (defn square [n] > (def x n) > (def n 6) > (* x x)) > > I've ran that in the repl and it doesn't change the values of what is > passed to it, but is the same true for multithreaded apps? What if > between (def n 6) and (* x x)) a different thread requested the value > of n? Basically, I want to know when is immutability guaranteed? (def..) always affects the global root binding, and is almost never used within functions like that (see the quote further above). Function-local (and thread-local) re-bindings are done using (binding ...), and is comparatively uncommon. Most code would be using (let ..) for your run-of-the-mill local variables and only start using refs/atoms/agents when there is a specific reason to do so (for example, some kind of shared cache like a connection pool). > What is a form? In this overview of clojure, it talks about bindings > and forms. The fragment that I am trying to understand is "The let > special form creates bindings that are local to that form". > http://java.ociweb.com/mark/clojure/article.html#Bindings Someone may provide a better formal definition, but a form is essentially "clojure code". In the context of the sentence above about let, the first use of 'form' refers to the use of let itself. I.e., this is a let form which evaluates to 5: (let [x 5] x) I'm not sure whether it will help, but this part of "Practical Common Lisp" may be useful even though the book is about Common Lisp: http://www.gigamonkeys.com/book/syntax-and-semantics.html -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: basic help with netbeans/enclojure installation
Indeed, it appears that enclojure and NetBeans 6.9 do not mix well. I've updated the "getting started" wiki page (http://www.assembla.com/wiki/show/clojure/Getting_Started_with_Netbeans_and_Enclojure ) with a note to reflect this, and point directly at the 6.8 download page. FYI, there is also an enclojure-specific group/mailing list: http://groups.google.com/group/enclojure Cheers, - Chas On Jun 17, 2010, at 8:19 AM, Lee Spector wrote: Thanks all. I've now installed NetBeans 6.8 and modulo a couple of update cycles on components everything went smoothly and I'm now running NetBeans/Enclojure. Perhaps the getting started instructions ought to include a comment about the required NetBeans version. -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
Re: parallel vs serial iteration in a "for" loop
Sean, On Jan 10, 12:29 pm, Sean Devlin wrote: > Conrad, > What's your use case that requires for and not map? I haven't seen > something like this yet, and you've got my curious. Stumbled across this thread after looking for some CL loop equivalents. For instance in CL, the loop macro provides, (loop for x in '(a b c d e) for y in '(1 2 3 4 5) collect (list x y) ) ((A 1) (B 2) (C 3) (D 4) (E 5)) Are there any good (and idiomatic) methods to achieve this using a Clojure loop construct? Cheers Viksit > > On Jan 8, 4:41 pm, Conrad wrote: > > > > > Thanks again Sean/Chouser- Sounds like there isn't any easy way to do > > in-stepiterationusing the "for" construct, as I suspected- This is > > of course easily remedied for writing a convenience function for "(map > > vec ...)" > > > (As I mentioned in the top post, I am aware the simple example I gave > > can be written more elegantly without the "for" construct.) > > > On Jan 8, 2:07 pm, Sean Devlin wrote: > > > > Oh, right. I saw "paralell" and the brain hit autopilot. > > > > And I think you CAN improve on your fn a little bit. This should do > > > the trick > > > > (map + (range 1 5) (range 11 15)) > > > > The mapping fn itself will be applied to as many arguments as you have > > > collections. Since + is variadic, it will do the job nicely. > > > > Sean > > > > On Jan 8, 11:56 am, Chouser wrote: > > > > > On Fri, Jan 8, 2010 at 11:34 AM, Sean Devlin > > > > wrote: > > > > > Take a look at pmap > > > > > I don't think that's the kind of "parallel" being asked about. > > > > > > On Jan 8, 11:13 am, Conrad wrote: > > > > >> Looping variables in a clojure "for" loop are iterated in aserial, > > > > >> cartesian fashion: > > > > > >> > (for [a (range 5) b (range 10 15)] > > > > > >> (+ a b)) > > > > >> (10 11 12 13 14 11 12 13 14 15 12 13 14 15 16 13 14 15 16 17 14 15 16 > > > > >> 17 18) > > > > > >> I was wondering if there's a standard idiom for looping inparallel > > > > >> fashion- Doesn't look like it's supported by the "for" macro > > > > >> directly. > > > > >> The best code I can come up with to do this is: > > > > > >> > (for [[a b] (map vector (range 5) (range 10 15))] > > > > > >> (+ a b)) > > > > >> (10 12 14 16 18) > > > > > >> Is there a more elegant way to do this? > > > > > Probably not. 'map' is the primary way to walk multiple seqs in > > > > step. 'zipmap' does this too, though only for building > > > > a hash-map. Of course you can always use recur as well. > > > > > --Chouser > > > > -- > > > > -- I funded Clojure 2010, did you? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
It's great to be discussing the possibility of enhanced primitive support. I like most of the proposals. But this part troubles me: # For bigints, specify bigints * new literal bigint format 42N # bigints contagious, no more auto-reductions * (\+ 0N 21 21) => 42N One of the big reasons I prefer Clojure over languages like Scala/F# is that in Clojure, numbers "just work". I don't have to worry about overflow errors, and the use of numbers in sets/hash tables is generally pretty intuitive (it gets a little wonky if you're using numbers produced by Java methods, but at least you're good if you stay within Clojure). As a case in point, consider writing a naive recursive factorial function. (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) In Clojure, (fact 3) produces the Integer 6. (fact 40) produces the BigInteger 8159152832478977343456112695961158942720. It just works. The answers produced by fact can be used in collections, compared for equality with other numbers. In F#, Scala, if you want factorial to not break on something like an input of 40, you have to essentially use the bigint literal syntax like what you're proposing: (defn fact [n] (if (zero? n) 1N (* n (fact (dec n) Now, the results of this function are "contaminating bigints" which can't be used as effectively with other Clojure data structures. As you pointed out, it causes problems when the same number can have two different type representations depending on the sequence of computations used to get to that number. This will always be somewhat of a problem due to Java interop, but it's important to me that all numbers arrived at through Clojure computations just work with respect to equality and use in sets/hash tables. The lack of auto-reduction, in conjunction with the proposal to make equality take numeric type into account, will really cripple the utility of bigints. Even more frustrating, in my experience with languages like F# and Scala, functions written like this are way, way slower. The reason is that Java's bigint arithmetic is sloow. To protect yourself from overflow, you've forced the function to use bigint arithmetic on 1N*2N*3N*..., well before you even reach a bigint. For this particular function, it reaches bigint status quite quickly, so the performance degradation is fairly minimal. But I have found that in general, requiring programmers to explicitly use bigint arithmetic for small numbers in order to protect from overflow is an absolute performance killer. Clojure's technique of auto-promotion to bigint upon overflow, and then auto-reduction when appropriate, is way, way faster than using bigints all the time. In summary: No auto-reduction would make bigints second-class citizens and make them difficult to use in other functions and collections. No auto-promotion to bigints means that programmers who want to protect from overflow have to use bigints everywhere, which destroys performance. So what would be the downside of implementing most of these proposals (e.g., 1 is a literal for long 1), but retain auto-promotion and auto-reduction rather than throwing an error for primitive long math? Seems to me like this would be the best of both worlds. What am I missing? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Jun 17, 2010, at 9:55 PM, Mark Engelberg wrote: It's great to be discussing the possibility of enhanced primitive support. I like most of the proposals. But this part troubles me: # For bigints, specify bigints * new literal bigint format 42N # bigints contagious, no more auto-reductions * (\+ 0N 21 21) => 42N One of the big reasons I prefer Clojure over languages like Scala/F# is that in Clojure, numbers "just work". I don't have to worry about overflow errors, and the use of numbers in sets/hash tables is generally pretty intuitive (it gets a little wonky if you're using numbers produced by Java methods, but at least you're good if you stay within Clojure). As a case in point, consider writing a naive recursive factorial function. (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) In Clojure, (fact 3) produces the Integer 6. (fact 40) produces the BigInteger 8159152832478977343456112695961158942720. It just works. The answers produced by fact can be used in collections, compared for equality with other numbers. In F#, Scala, if you want factorial to not break on something like an input of 40, you have to essentially use the bigint literal syntax like what you're proposing: (defn fact [n] (if (zero? n) 1N (* n (fact (dec n) Now, the results of this function are "contaminating bigints" which can't be used as effectively with other Clojure data structures. As you pointed out, it causes problems when the same number can have two different type representations depending on the sequence of computations used to get to that number. This will always be somewhat of a problem due to Java interop, but it's important to me that all numbers arrived at through Clojure computations just work with respect to equality and use in sets/hash tables. The lack of auto-reduction, in conjunction with the proposal to make equality take numeric type into account, will really cripple the utility of bigints. Even more frustrating, in my experience with languages like F# and Scala, functions written like this are way, way slower. The reason is that Java's bigint arithmetic is sloow. To protect yourself from overflow, you've forced the function to use bigint arithmetic on 1N*2N*3N*..., well before you even reach a bigint. For this particular function, it reaches bigint status quite quickly, so the performance degradation is fairly minimal. But I have found that in general, requiring programmers to explicitly use bigint arithmetic for small numbers in order to protect from overflow is an absolute performance killer. Clojure's technique of auto-promotion to bigint upon overflow, and then auto-reduction when appropriate, is way, way faster than using bigints all the time. In summary: No auto-reduction would make bigints second-class citizens and make them difficult to use in other functions and collections. No auto-promotion to bigints means that programmers who want to protect from overflow have to use bigints everywhere, which destroys performance. So what would be the downside of implementing most of these proposals (e.g., 1 is a literal for long 1), but retain auto-promotion and auto-reduction rather than throwing an error for primitive long math? Seems to me like this would be the best of both worlds. What am I missing? You raise several points, I'll take them in turn. First, things are not as dire as you state. Certainly one could write a version of fact that hardwired bigints as you showed. But you need not - here's the original naive definition: (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) Such logic that doesn't specify one of the components (in this case, n) is still polymorphic, as are operations with mixed components. So the power is in the hands of the supplier of n: user=> (fact 10) 3628800 user=> (fact 40) java.lang.ArithmeticException: integer overflow user=> (fact 40N) 8159152832478977343456112695961158942720N I think you can always write code in this way, such that it will work with any of the numeric types, without dictating. It is true that Java's BigIntegers are slow, especially for numbers small enough to fit in Long or Integer, so using them for smaller numbers has overhead. But there are other options, not yet pursued here. For instance, Kawa has a higher performing biginteger that uses an internal int component until it overflows. I'm sure no one has a particular attachment to BigInteger should we find a better alternative. It would be easy to create a big integer class based on the Kawa concept, perhaps with a long or int basis overflowing to BigInteger itself. http://groups.google.com/group/jvm-languages/msg/0413ed05d1371907 -- As far as performance killer, that depends on your perspective. It is my belief that overwhelming majority of code *never* uses numbers that exceed long, And those people are suffering a 'performance killer' on the order of 10-20x by having num
Re: Enhanced Primitive Support
On Thu, Jun 17, 2010 at 11:00 PM, Rich Hickey wrote: > In the end, this does put the interests of two sides of the community at > odds. Only one set of interests can be the default. Part of the point of > this discussion is to measure the sides (so speak up people!). I am squarely on the side of prim/num/equals. The number of questions on the ML, #clojure, StackOverflow, etc. for the past two years about proper type-hinting shows how much incidental complexity the current system brings to the table. Look no further than: http://clj-me.cgrand.net/2010/06/04/primitive-support-for-fns/ vs. http://clj-me.cgrand.net/2010/06/10/primitive-types-support-for-fns-coming-to-a-clojure-branch-near-you/ . The difference is startling. In order to write decently fast numeric code in Clojure up until now you had to be Christophe Grand ;) or have a fairly good understanding of macros that walk code to tag primitive types. And even so, the inability to return primitives made many nested recursive algorithms perform poorly. The only way to work around this was to convert your functions to macros and inline everything resulting of course in a considerable loss of modularity. Dirty hacks. For those that need BigInts (the majority of whom are solving Project Euler problems, god bless them), telling them to add a single N is so much simpler than explaining the current complexities to newcomers who don't understand why floating point arithmetic is so darn slow. More importantly, I think that deftype/defrecord/protocols/static/prim/num/equals represent an astounding work of *unification*. You no longer need to resort to Java - all the tools for building fast code is right there. My gut feeling is that many Clojure devs won't think to much about this work - they've got their hands full with the rest of the language or are working in domains where they are under the impression that this unification work does not affect them. But I think this kind of work is paving the way for the community to give more of a helping hand to converting core data structures from Java to Clojure, extending them, patching them, and contributing new ones - all in a language that (unlike Java) naturally guides you to "do the right thing". So though I don't know how much of a stir this thread will create (because I think it's more of a large under the surface wave), I have no doubt it will pay off in a big, big way. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
Thanks for the responses. Going back to the naive factorial function: (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) Right now, user=> (fact 40) 8159152832478977343456112695961158942720 Under the proposed changes, user=> (fact 40) java.lang.ArithmeticException: integer overflow So the same code now risks an arithmetic exception. What have I, the programmer, gained from this new level of risk? The answer, if I'm the kind of programmer who has no interest in putting in type annotations into the header of the function, is nothing. There is no speed improvement without the additional type annotations. So all I've gained is the /potential/ for a speed improvement. I assume that most Clojure users really like its dynamic nature. If this is true, then for most of us, the common case is to NOT annotate our code with types. Certainly I like the idea of making it as easy as possible to write fast code in Clojure. I want my dynamically typed code to be as fast as it can be, and it's nice to know that there is a way to write statically typed code that is even faster. But I really don't want to incur a penalty (i.e., possibility of Arithmetic Exception) when I'm not using type annotations. I agree that the burden on those who want to write type annotated code is too high. I agree that this should be made easier. But ultimately, I still want the burden to be on them (or me, the 1% time I need it), not those of us who prefer unannotated code. I that some of the changes you have proposed for moving the annotations into the header, along with literal notation for long (i.e., 0L rather than (long 0)) would be preferable to the bigint dichotomy. I agree that an improved bigint type would address the performance aspect of my argument. On the other hand, it wouldn't really address the problem of using these things in sets and hash tables. I think it's very important that Clojure have one unique canonical representation for numbers arrived at through Clojure-based computations. It is very difficult to use numbers sanely if that's not the case. I see your point that there are a couple of sides to this argument. I hope I can persuade some more people to speak up for my side :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen documentation review?
On Thu, Jun 17, 2010 at 4:24 AM, Manfred Lotz wrote: > I had a problem with lein that it did not compile all of my files and > after quite a while I discovered that I had to tell lein about it in > projects.clj by adding a :namespaces statement. > > Well, don't know if this is the intended solution but it worked for me. This is very much intentional--in Clojure you don't want to perform AOT compilation unless you have to. I tried to make this clear in the tutorial: ## Compiling If you're lucky you'll be able to get away without doing any AOT (ahead-of-time) compilation. But there are some Java interop features that require it, so if you need to use them you should add an :aot option into your project.clj file. It should be a seq of namespaces you want AOT-compiled. Again, the [sample.project.clj](http://github.com/technomancy/leiningen/blob/master/sample.project.clj) has example usage. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen documentation review?
On Thu, Jun 17, 2010 at 5:34 AM, Rick Moynihan wrote: > I read through both the tutorial and the readme, and both seem to be > pretty clear (though I'm not a new user). They're certainly an > improvement on what came before, and it seems to be a pretty solid > introduction. Perhaps though, there should be some mention of how the > clojure and contrib jars and versions are also included in the > project.clj, and are therefore included as a project level > dependency An approach that is different from what Ruby > programmers are used to with gems (i.e. leiningen also manages > platform versions) (though not JVM ones). Good point--that's certainly an interesting twist for most people. > Another comment I have, is that lein's use of lancet isn't especially > well documented. This is perhaps more of a deficiency in Lancets > documentation, which really needs documenting... especially now that > it's a dependency on lein, which is fast becoming a critical tool for > most clojure projects. True, but this is mostly because I don't have a great grasp of Lancet or Ant myself; I just use a few key calls that are needed to get the dependencies pulled in. Would welcome some help here. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Thu, Jun 17, 2010 at 11:57 PM, Mark Engelberg wrote: > I assume that most Clojure users really like its dynamic nature. If > this is true, then for most of us, the common case is to NOT annotate > our code with types. Certainly I like the idea of making it as easy > as possible to write fast code in Clojure. The problem is that it distinctly *not* easy to write fast numeric code in Clojure. It requires expert Clojure knowledge. On the other hand, the mental burden for someone who wants BigInts in the new system is very low - you'll get a trivial to track exception. And the new system doesn't remove any of the lovely dynamic stuff. There's absolutely no compromise there. In fact in the new system you can write your code initially sans ^:static and fn type hints entirely, you work to get your algorithm right, play around at the REPL as usual, then you add ^:static, type hint only the arglist and return value ... BOOM, you get raw JVM speed. But of course I'm biased as you are :) In two years I've never once been interested in BigInts. I have however have mangled and munged my code since 2008 trying to get basic numeric algorithms to perform even remotely in the vicinity to their Java counterparts to no avail. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
> > The problem is that it distinctly *not* easy to write fast numeric code in > Clojure. It requires expert Clojure knowledge. On the other hand, the mental > burden for someone who wants BigInts in the new system is very low - you'll > get a trivial to track exception. > > Also, when done, it doesn't look like clojure anymore. +1 on the new behaviour. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On 18/06/2010, at 12:30 PM, Rich Hickey wrote: > You raise several points, I'll take them in turn. First, things are not as > dire as you state. Certainly one could write a version of fact that hardwired > bigints as you showed. But you need not - here's the original naive > definition: > > (defn fact [n] > (if (zero? n) 1 (* n (fact (dec n) > > Such logic that doesn't specify one of the components (in this case, n) is > still polymorphic, as are operations with mixed components. So the power is > in the hands of the supplier of n: > > user=> (fact 10) > 3628800 > > user=> (fact 40) > java.lang.ArithmeticException: integer overflow > > user=> (fact 40N) > 8159152832478977343456112695961158942720N That's fine for fact, but as a consumer of library functions, how do I know when I should pass in bigints? How do I know when an intermediate value, for my particular combination of parameter values, is going to overflow? Should I just use 'N' on every number to every function? This proposal destroys the black-box nature of functions, and seems to me to be the easy solution rather than the best solution, which, I acknowledge, might be very hard work, possibly involving every such function having 2 polymorphic variants, one generic boxed form and one unboxed form, automatically selected and call-site-cached like OO dispatch. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If you pick up a starving dog and make him prosperous, he will not bite you. This is the principal difference between a man and a dog. -- Mark Twain -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Fri, Jun 18, 2010 at 12:24 AM, Antony Blakey wrote:
>
> That's fine for fact, but as a consumer of library functions, how do I know
> when I should pass in bigints? How do I know when an intermediate value, for
> my particular combination of parameter values, is going to overflow?
>
If the library isn't communicating that to you isn't that just a broken API
that you don't want to participate in? Tag information on arglists is
available:
(defn foo [^BigInteger a b ^BigInteger c]
(+ a b))
(print (map (fn [xs] (map meta xs)) (:arglists (meta #'foo
;(({:tag BigInteger} nil {:tag BigInteger}))
IDEs can easily (and should) expose this.
David
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
At first read this all looks awesome to me, and I'd love to see prim/ num/equals in 1.2! Type hinting math has been a pain, I rarely need bigints and would be happy being explicit about them when I do, and I can't think of obvious cases where I'd need (equals? [2.0] [2]), which I gather will no longer be possible in the equals branch (for any value of "equals?"). Moreover, the distinction between = and .equals (and, hence, = and set/ map lookups) was a significant source of complexity and confusion for me learning Clojure, and I'd be happy to see that go away. I guess it'll take some experience to see if similar difficulties arise with collections & boxing in the new setting, but at first glance the new design seems very well thought-out. One minor question: with this change, will it still be possible to do primitive math on floats and ints? On modern machines I suppose there's little reason to want this (other than perhaps saving memory), but for other hosts like 32-bit dalkvik or javascript I'd imagine this might present a performance problem? 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
Re: Enhanced Primitive Support
I don't want to commit to a full-fledged response on this issue (yet), but: On the other hand, the mental burden for someone who wants BigInts in the new system is very low - you'll get a trivial to track exception. Assuming that I understand your implication (that ArithmeticExceptions are trivial to track): that might be true in Java, with checked exceptions, but it wouldn't be true in Clojure. If some operations overflow some of the time, you need thorough tests… and for all of the libraries you use to have thorough tests. It's not a small mental burden to constantly fear that any library call at all could suddenly overflow at any time. What are we, C programmers? Automatic type promotion is a good thing, if not without its quirks (map behavior being one of them). One of the fantastic things about Common Lisp is its rich numeric tower. That said, if we could have speed and safety… -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Thu, Jun 17, 2010 at 9:20 PM, David Nolen wrote: > The problem is that it distinctly *not* easy to write fast numeric code in > Clojure. It requires expert Clojure knowledge. Right, but with just the prim branch and a shorthand for long literals, you get: (defn ^:static fib ^long [^long n] (if (<= n 1L) 1L (+ (fib (dec n)) (fib (- n 2L) which really isn't that bad. So my claim is that the prim branch gets you far enough along the road to easy fast numeric code, without screwing with the numeric tower. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
Hmmm, here's an idea: How about inside of a static function with type annotations, all literals are automatically converted into long and doubles, otherwise behavior stays the same. So: (defn ^:static fib ^long [^long n] (if (<= n 1) 1 (+ (fib (dec n)) (fib (- n 2) is automatically converted to (defn ^:static fib ^long [^long n] (if (<= n (long 1)) (long 1) (+ (fib (dec n)) (fib (- n (long 2)) whereas (defn fib [n] (if (<= n 1) 1 (+ (fib (dec n)) (fib (- n 2) works the way it always did. This behavior makes a lot of sense because (I think) the only time you really gain from literals being primitives is when the variables around it are also hinted. Otherwise, the polymorphic nature of the variable will cause the literal to get boxed anyway. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
... which, I acknowledge, might be very hard work, possibly involving every such function having 2 polymorphic variants, one generic boxed form and one unboxed form, automatically selected and call-site-cached like OO dispatch. That's pretty much what Common Lisp compilers do. The compiler (or your own compiler macro, if you so choose) can examine the input forms and the compiler environment to decide what code to produce. The following is from Allegro Common Lisp, but all of the input is ANSI CL -- part of the spec. Observe how the compiler switches between different implementations of trivial addition as it gets a progressively looser or tighter bound on x. (I've elided some of the irrelevant preamble.) What would be nice is if Clojure and/or the JVM could produce safe code/bytecode that wouldn't overflow, but could also be JIT-optimized into unboxed primitive arithmetic for known input ranges. ;; Range known, optimizing for speed: assembly add instruction. cl-user(7): (disassemble (compile nil (lambda (x) (declare (type (integer 0 255) x) (optimize (speed 3))) (+ x 2 ... 15: 48 83 c7 10 addrdi,$16 19: f8 clc 20: 4c 8b 74 24 10 movq r14,[rsp+16] 25: c3 ret ;; We know that x is a fixnum: the arithmetic doesn't need a function call, but ;; the result will be a boxed bignum, because fixnum + 2 won't fit in a fixnum. ;; If this function were inlined elsewhere, the compiler might avoid that decision. cl-user(8): (disassemble (compile nil (lambda (x) (declare (type fixnum x) (optimize (speed 3))) (+ x 2 ... 21: 74 01 jz 24 23: 17 (pop ss); sys::trap-signal-hit 24: 48 c1 ff 03 sarrdi,$3 28: 49 c7 c5 02 00 movq r13,$2 00 00 35: 49 03 fd addq rdi,r13 38: 4c 8b ef movq r13,rdi 41: 49 d1 e5 sall r13,$1 44: 70 19 jo 71 46: 49 d1 e5 sall r13,$1 49: 70 14 jo 71 51: 49 d1 e5 sall r13,$1 54: 70 0f jo 71 56: 49 8b fd movq rdi,r13 59: f8 clc 60: 48 8d 64 24 78 leaq rsp,[rsp+120] 65: 4c 8b 74 24 10 movq r14,[rsp+16] 70: c3 ret 71: 41 ff 57 47 call *[r15+71]; sys::box-to-new-bignum 75: eb ef jmp 60 77: 90 nop ;; Nothing known: call to excl::+_2op, the two-arg addition function. cl-user(9): (disassemble (compile nil (lambda (x) (declare (optimize (speed 3))) (+ x 2 ... 21: 74 01 jz 24 23: 17 (pop ss); sys::trap-signal-hit 24: 40 f6 c7 07 testb dil,$7 28: 75 12 jnz 48 30: 48 83 c7 10 addrdi,$16 34: f8 clc 35: 70 1e jo 67 37: 48 8d 64 24 78 leaq rsp,[rsp+120] 42: 4c 8b 74 24 10 movq r14,[rsp+16] 47: c3 ret 48: 49 8b af 2f ff movq rbp,[r15-209]; excl::+_2op ff ff 55: 48 c7 c6 10 00 movq rsi,$16 ; 2 00 00 62: ff 53 d0 call *[rbx-48] ; sys::tramp-two 65: eb e2 jmp 37 67: 49 c7 c5 10 00 movq r13,$16 ; 2 00 00 74: 49 2b fd subq rdi,r13 77: eb e1 jmp 48 79: 90 nop -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On 18/06/2010, at 2:26 PM, David Nolen wrote: > On Fri, Jun 18, 2010 at 12:24 AM, Antony Blakey > wrote: > > That's fine for fact, but as a consumer of library functions, how do I know > when I should pass in bigints? How do I know when an intermediate value, for > my particular combination of parameter values, is going to overflow? > > If the library isn't communicating that to you isn't that just a broken API > that you don't want to participate in? Tag information on arglists is > available: No. How do I know whether I need to pass a bigint literal or not? For what possible input values will overflow be an issue? It's easy to see with fact, but that's because the function implementation is clearly visible, and has well known growth properties of a single argument. And it's not just literals - when functions are composed from other functions that have this same problem and return primitive types - hence using the static versions of functions - the question in general becomes impossible to answer, not only because there might be a number of parameters with interdependencies, but because the structure of intermediate results may not be visible to the consumer. And what if you don't have the source to the function? This proposal not only puts the burden of promotion and representation choice onto the user of a function, but it requires that promotion be done before the function is executed, in a precautionary way, rather than iff needed. This proposal is IMO a very bad idea. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Lack of will power has caused more failure than lack of intelligence or ability. -- Flower A. Newhouse -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parallel vs serial iteration in a "for" loop
Hi, On Jun 18, 1:35 am, viksit wrote: > (loop for x in '(a b c d e) > for y in '(1 2 3 4 5) > collect (list x y) ) > > ((A 1) (B 2) (C 3) (D 4) (E 5)) > > Are there any good (and idiomatic) methods to achieve this using a > Clojure loop construct? user=> (map vector [:a :b :c :d :e] [1 2 3 4 5]) ([:a 1] [:b 2] [:c 3] [:d 4] [:e 5]) Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Fri, Jun 18, 2010 at 1:44 AM, Antony Blakey wrote: > > On Fri, Jun 18, 2010 at 12:24 AM, Antony Blakey > wrote: > This proposal is IMO a very bad idea. > Why do you need know? You're assumption is built on someone writing a writing a bad library (one that doesn't handle long & BigInt that should). The tools are there for the library to behave correctly regardless of the input. (defn fact [n] (if (zero? n) 1N (* n (fact (dec n) (fact 40) (fact 40N) both work. The burden is not on the consumer but the designer of the library. What's the problem? David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Thu, Jun 17, 2010 at 11:01 PM, David Nolen wrote: > What's the problem? > David It's a composability issue. Elaborating on Anthony's explanation, let's say you call (fact (foo n)). Do you know what values of n, when passed to foo, produce a value large enough that fact will produce an exception? If you do know this, do you know enough about the internals of foo to know the best way to fix the problem? If you pass a bigint to foo, are you guaranteed to get a bigint as an output, or do you need to explicitly wrap a protective call to bigint between the two calls? In other words, do you call (fact (foo 20N)) or (fact (bigint (foo 20))? This imposes too high a burden on any programmer who cares about safety. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen documentation review?
I've been using Lein in earnest the last couple of days, prepping for a talk on Clojure for OSCON. I'm hitting enough issues to make me think that 1.2 needs a bit of TLC before a release. Don't get me wrong; I like Lein, how easy it installs, and how focused it is. I'm just finding that, despite being "in theory" customizable to slightly different directory layouts (I like a Maven style layout, with src/main/clojure, src/test/clojure, target/classes, etc.) ... well, it just doesn't work in practice. I'm doing what I can to help with patches and bug reports. I still expect to recommend Lein as the best option out there for Clojure builds, mostly based on its potential and narrow but effective focus. On Wed, Jun 16, 2010 at 9:24 PM, Phil Hagelberg wrote: > I'm pushing for a Leiningen 1.2.0 release really soon now, and part of > that effort is sprucing up the documentation. I've revamped the readme > and added a tutorial for folks just getting started. Of course, > self-editing is never as good as having outside help, so I'd love it > if I could get some feedback on it. I'm particularly interested in > opinions from people who are just starting out with Clojure--it's easy > for me to take things for granted that not everyone understands. > > Mostly I'd like feedback on the tutorial: > http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md > > But if you've got some time to look over the readme, that would be > great too: http://github.com/technomancy/leiningen/blob/master/README.md > > Thanks! > > -Phil > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Fri, Jun 18, 2010 at 2:10 AM, Mark Engelberg wrote: > This imposes too high a burden on any programmer who cares about safety. Rich Hickey's branch work boil down to: 1) double/long crowd get to stop eating bark 2) BigInt crowd loses free lunch I'd say this is a bona fide community compromise and Rich Hickey saw it coming :) David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Upgrade from 1.1 to 1.2
I've noticed a few issues upgrading from 1.1 to 1.2; I see that ^coll is no longer supporter; you now have to use (meta coll) instead. Some of the notes on new 1.2 features imply that ^ has changed meaning; it now looks like it's the type hint, rather than #^ ? Is this true? I've checked around for the documentation but haven't seen much. Are there any other gotchas moving code from 1.1 to 1.2? -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Upgrade from 1.1 to 1.2
^ was deprecated in 1.1 as per release note below The ^ reader macro has been deprecated as a shortcut for meta in the hopes that it can eventually replace the #^ reader macro. On Jun 18, 2010, at 2:20 AM, Howard Lewis Ship wrote: > I've noticed a few issues upgrading from 1.1 to 1.2; I see that ^coll > is no longer supporter; you now have to use (meta coll) instead. > > Some of the notes on new 1.2 features imply that ^ has changed > meaning; it now looks like it's the type hint, rather than #^ ? Is > this true? I've checked around for the documentation but haven't seen > much. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
On Fri, Jun 18, 2010 at 2:10 AM, Mark Engelberg wrote: > Elaborating on Anthony's explanation, let's say you call (fact (foo n)). > This imposes too high a burden on any programmer who cares about safety. > Don't buy it. That's the whole point of BigInt contagion. If fact and foo are correctly written this will work. > (defn fact [n] (if (zero? n) 1N (* n (fact (dec n) (defn foo [n] (inc n)) (fact (foo 40)) (fact (foo 40N)) Both work. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Upgrade from 1.1 to 1.2
Hi, 2010/6/18 Wilson MacGyver : > ^ was deprecated in 1.1 as per release note below > The ^ reader macro has been deprecated as a shortcut for meta in the > hopes that it can eventually replace the #^ reader macro. No, it's not that gray: in 1.2 (so in clojure master, and all new branches like prim, equal, etc.), ^ now has the same semantics as #^. #^ is still working as usual, but becomes deprecated. The behaviour of the old ^, as mentioned by Howard, requires the explicit (meta ) call. Howard, another point to have in mind in 1.2: some libraries from clojure contrib have partially migrated to clojure. For example I/O stuff has appeared in clojure.java.io. String manipulation stuff also. As a result, you may encounter warnings in your own code, or in libraries you use which may not yet have migrated to 1.2 (which is to be expected, since 1.2 is not out), or not be prepared for 1.2 (by avoiding 'use-ing foreign namespaces, but rather using aliases). The warnings will tell you when a var is re-def-ined (this is a new feature, which may or may no stay in core : before this warning feature, you just wouldn't have been able to compile the code, redefinitions of vars bound to external namespaces vars was an error. The new "warning only" behaviour tries to enhance the user experience: allow the code to run, until everybody has removed the warnings in new versions of their code). HTH, -- Laurent -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
This imposes too high a burden on any programmer who cares about safety. Don't buy it. That's the whole point of BigInt contagion. If fact and foo are correctly written this will work. It only takes one library to screw up, and the whole stack falls down. Screwing up can occur because of omission (fact being written with a "1", not "1N", and not being tested with large inputs), or by design. This whole debate arose because people care about the speed of their numeric functions! The safety bignums (which make things slower) will be omitted for performance reasons, or by accident, and people won't obey the contract of the function… or won't be able to because of the complex interactions between libraries. I can't control where every value in my program goes. In Clojure as it stands now, those edge cases would see a small performance penalty as bignums occurred (and then it would go away if they got demoted!). After this change, a one-in-a-million collision of numbers and performance-oriented programming would throw an exception with no way to recover from higher up the stack. A programmer who really cares about safety would thus indeed have to shoulder a massive burden: either review and get complete test coverage over every library in their dependency stack, or ensure that no non-bignum can ever enter a library function. I guess that also means no strings, no file sizes, no URLs, no values which might get recombined… because any of those values could produce a non-bignum and enter an unsafe Clojure library function, causing an overflow with no possibility of continuing. (This ain't Common Lisp.) Having digested Rich's notes, pretty much the only thing that I disagree with is the lack of automatic bignum promotion/demotion. It seems like too much of a bad tradeoff, sacrificing one of Clojure's selling points for a little numeric performance. Thus far, Clojure has done pretty well in lexically scoping its "please make this fast and unsafe" bits — primitive calls, loop, transients. This would break that pattern. I wonder: is there's a middle ground, where primitives are automatic almost everywhere, but bignum promotion on overflow is still possible? -- 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
