Re: Refs scalability
Then, let's say there is a million refs, each transaction involves only a couple of refs, and there is a number of concurrent transactions typical for a web application that runs on one server (let's say 10-100). Of course that the real answer is in measuring it, but I wanted to know, before I build it, whether such design is feasible from the standpoint of the refs design. On Dec 11, 1:19 am, Phil Hagelberg wrote: > DraganDjuric writes: > > Is it a good idea, from the performance standpoint, to use many refs > > in the program? By many, I mean thousands or even millions? > > The question isn't how many refs you should instantiate, it's how many > refs you should read or write to at once in a transaction as well as how > many transactions you expect to run at once. The place you'll run into > perf issues is with transaction retries. The best (only?) way to know is > to measure, I think. > > -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: Slides that accompany the Rich's QCon talk
Thanks :) On Dec 11, 6:17 am, Krukow wrote: > On Dec 11, 12:21 am, Dragan Djuric wrote: > > > HI, > > > I have just watched Rich's QCon talk and in some parts he is referring > > to the slides that are not displayed in the video. Of, course, the > > talk is perfectly fine without that, but I need to understand some > > specific tricky details, and I believe that the referred slides would > > help. Are they available? > > QCon and JAOO conferences make the slides available online > > http://qconlondon.com/london-2009/schedule/thursday.jsp > > /Karl -- 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: Renaming 1.1.0-alpha-SNAPSHOT is causing problems with projects on Clojars
Not sure what was causing it, but leiningen / clojars couldn't get its deps yesterday. I thought it was caused by clojure and clojure-contrib no longer being on clojars.org, but maybe the renaming on build.clojure.org has something to do with it. On Dec 11, 6:18 am, Phil Hagelberg wrote: > liebke writes: > > I like the new naming scheme, but would it be possible to add 1.1.0- > > alpha-SNAPSHOT back to the repository (in addition to the new names), > > so that builds dependent on projects in Clojars will be able to > > download their dependencies correctly again, at least until everybody > > gets a chance to upload new poms to Clojars? > > The jars with the old version number haven't disappeared, have they? > Projects relying on -alpha should still work, they will just not get the > latest and greatest version of Clojure. > > Please speak up if you've noticed otherwise, but that's my understanding. > > -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: Code arrangement for understandability
> Do you come from a Python background? For the sake of this discussion, I would say I come from Erlang. > Judging by you examples, I looks like you're still getting used to the lisp > style of coding. Everything is a chained function call. You're correct. Comming from Erlang: * I tend to see things as if they are in a chain, concatted by commas. * I feel that I have to write lots of nested "let"s for temporary immutables. I think to avoid adding "let"s, Clojurians would just don't use temporary immutables. This makes Clojure code hard to understand, because temporary immutables with good names help explain the code. The tricks to avoid adding "let"s in previous posts are very ugly in my opinion. Is this style of "let" common and a good practice to follow? (I just want to know, sorry if my expression is offensive) > What do you mean by abstractness? By "abstractness level" in the previous post, I mean level of code block. For example I would say B1 and B4 are of the same level. B1 | B2 | B3 B4 Because of indents, my previous Clojure code lied to my eyes that x, y, f, g are not at the same block level. This is my difficulty with Clojure. In short, I can't see a rough algorithm from any Clojure code any more just by seeing the shape (levels) of blocks. To understand a Clojure code, I have to look at every bit of code, look closer. > In Clojure we still need to look farther up the screen... Things in Erlang are immutable, so I think Clojure has no advantage over Erlang here. > Practice using comp & partial... What do you mean by "comp & partial"? Could you please explain? > (let [x 1 > y (+ x 2)] > (f x) > (g y)) Well, I know my example code can be rewritten like that, but I just could not give a better one. Rearranging like this reminds me of C, in which every variables must be listed beforehand. Since all Clojurians say "lazy" is good, I would say I prefer C++ because I can be lazy in it, I only have to declare a variable when I actually use it. I'm lost in Clojure, please light me a way. Lots of 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: how 'bout a debug-repl?
On 10 Dec 2009, at 21:34, George Jahad wrote: > are you using slime? Currently, you need to use a non-slime repl, (I > think because of how slime handles io redirection) I don't use slime, but I had a similar issue with Counterclockwise/ Eclipse, which doesn't quite understand that end-of-stream (Ctrl-D) is meant to terminate not the stream, but just the portion of the stream going to the debug repl. Here is a modified version that permits quitting the debug REPL by typing "()" (empty list): http://gist.github.com/254110 It works fine with Counterclockwise, so perhaps it's also a solution for Slime users. Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: how 'bout a debug-repl?
Great ! thanks Konrad ! Another, presumably more "general" solution, but implying modifications (by adding another optional attribute) to clojure.main/repl, would be to give to the REPL a particular instance whose meaning could be interpreted by the reader as "end the current reader". This instance could be returned by a utility function provided by debug-repl as a global function. This could be of general utility, not just for debugging purposes. But then, we could even go one level deeper: not only provide a particular instance that would allow to quit the REPL, but a set of instances. And if the returned value of the call to the REPL returns one of the instances in the set, then quit. This would allow to nest debug-repls (but is it interesting ?) calls, and to go back to the encapsulating repl by e.g. a call to debug-repl/quit(1), or to go up 2 levels in the debug-repls nesting by calling debug-repl/quit(2), ... or to go back to the main environment by e.g. a call to debug-repl/quit(). 2009/12/11 Konrad Hinsen > On 10 Dec 2009, at 21:34, George Jahad wrote: > > > are you using slime? Currently, you need to use a non-slime repl, (I > > think because of how slime handles io redirection) > > I don't use slime, but I had a similar issue with Counterclockwise/ > Eclipse, which doesn't quite understand that end-of-stream (Ctrl-D) > is meant to terminate not the stream, but just the portion of the > stream going to the debug repl. > > Here is a modified version that permits quitting the debug REPL by > typing "()" (empty list): > >http://gist.github.com/254110 > > It works fine with Counterclockwise, so perhaps it's also a solution > for Slime users. > > Konrad. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- 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: Code arrangement for understandability
On Dec 11, 11:14 am, ngocdaothanh wrote: > Because of indents, my previous Clojure code lied to my eyes that x, > y, f, g are not at the same block level. This is my difficulty with > Clojure. In short, I can't see a rough algorithm from any Clojure code > any more just by seeing the shape (levels) of blocks. To understand a > Clojure code, I have to look at every bit of code, look closer. > You should come up with a real code example instead of a bunch of (f x) (y z) expressions... The example you show is not very idiomatic clojure simply because it has side-effects. (Of course you need side- effects, but they should be isolated). If the code structure gets too complicated, simplify it by writing functions or macros to better express your intent. > > In Clojure we still need to look farther up the screen... > > Things in Erlang are immutable, so I think Clojure has no advantage > over Erlang here. > > > Practice using comp & partial... > > What do you mean by "comp & partial"? Could you please explain? comp is function composition, and partial is partial application. eg: ((comp negate inc) 6) -> -7 ((partial + 1) 5) -> 6 using these to create new functions is called point-free style I'm not so much a fan, and I don't think point-free style is particularly idiomatic in Clojure (unlike in Haskell for example), but it's sometimes less noisy than #() or fn expressions, so it's good to know. They're usually best used with filter and map. > > > (let [x 1 > > y (+ x 2)] > > (f x) > > (g y)) > > Well, I know my example code can be rewritten like that, but I just > could not give a better one. I don't think there's any use for comp or partial in this case. it's too simple. > > Rearranging like this reminds me of C, in which every variables must > be listed beforehand. Since all Clojurians say "lazy" is good, I would > say I prefer C++ because I can be lazy in it, I only have to declare a > variable when I actually use it. Your code examples are a bit pathological. Usually (hopefully), you would have Clojure code that looks like this: (if-let [source (get-stuff-from-database)] (reduce + (map somefn (filter somepred (extract-data source 0) ; no data Which is more functional in style. One thing you can do is to learn to read these from right to left, which takes a bit of practice, but pays off in the end, in my opinion. The ->> and -> macros are sometimes useful for transforming the right-to-left -readable forms into forms that look more like pipelines: (->> (extract-data source) (filter somepred) (map somefn) (reduce +)) There's no need for temporary names here. If a step needs explanation, just add comments. Hope this helps. -- Jarkko -- 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: Code arrangement for understandability
> ((comp negate inc) 6) -> -7 Hm, I was sure negate existed... But seems like it doesn't. Oh well. (comp - inc) 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
Latest news on ClojureQL
Hi all, ClojureQL is now moved to Gradle and Jars are pushed to Clojars as version 0.9.7 Blogpost on status: http://www.bestinclass.dk/index.php/2009/12/clojureql-where-are-we-going/ Thanks, Lau -- 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: dumb noob ceremony question
thanks much!
On Dec 10, 7:28 pm, Richard Newman wrote:
> > (clojure.set/union #{1} #{2})
>
> > what'd I do wrong, please & thanks?
>
> Nothing wrong!
>
> Try this:
>
> (use 'clojure.set)
--
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: Possible BUG: NPE
On Wed, Dec 9, 2009 at 10:39 PM, Feng wrote: > > > On Dec 7, 9:39 pm, David Nolen wrote: >> http://github.com/jochu/swank-clojure/blob/master/src/main/clojure/sw... >> >> Is the offending line. > > It's really hard to reason about it in clojure source code. I see, in > jswat debbuger, the root cause of NPE appears around byte code > (putfield ...) for a mutual recursive letfn form. > > Here is a simple way to reproduce it. I did it this time with latest > master branch. Can anybody else reproduce it on different OS/JVM > version? > > (ns test.letfn) > > (defn debug [n] > (letfn [(even [n] > (if (== n 0) > true > (odd (- n 1 > (odd [n] > (if (== n 0) > false > (even (- n 1] > (odd n))) > > Listening for transport dt_socket at address: > Clojure 1.1.0-master-SNAPSHOT > user=> (require 'test.letfn) > nil > user=> (test.letfn/debug 5) > java.lang.NullPointerException (NO_SOURCE_FILE:0) Fixed (new branch commit 42e45b9988bfa17584f2) Thanks for the report and the isolating case. 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: Latest news on ClojureQL
On Dec 11, 11:58 am, LauJensen wrote: > Hi all, > > ClojureQL is now moved to Gradle and Jars are pushed to Clojars as > version 0.9.7 > > Blogpost on > status:http://www.bestinclass.dk/index.php/2009/12/clojureql-where-are-we-go... Very interesting. I wondered some days ago what is the best way to interact with a database from clojure and it's great to see this project progress! I'm wondering: how would you compare the use of ClojureQL and clj- record(which sadly doesn't show much activity currently)? Isn't CQL going back to the SQL level or database queries, whereas clj-record is at a higher level? Would it be easy to code this higher level layer on top of cql? Or is that less important in Clojure than it is in OO languages? And a suggestion: having migrations in CQL would be great! Raph > > Thanks, > Lau -- 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: Datatypes and protocols - update
Rich Hickey gmail.com> writes: > > An updated version of the code for datatypes[1] and protocols[2] is > now available in the 'new' branch[3]. I've converted some code that used gen-class to use deftype and defprotocol and the results are great so far. The code is shorter, easier to write and the intent is much clearer. I'm a big fan. I've come across one problem though. I've created a type with deftype that calls a function in one of its methods: (ns ns1.deftypetest) (defn bar [] "bar") (defprotocol P (foo [p])) (deftype T [] P (foo [] (bar))) When I compile the namespace, create an instance of the type from Java and invoke the foo method I get: java.lang.IllegalStateException: Var ns1.deftypetest/bar is unbound. I guess the namespace isn't getting loaded. Should this work? I've created a class in the same namespace using gen-class and that has no problem invoking the function when it's instantiated from Java. Thanks Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Renaming 1.1.0-alpha-SNAPSHOT is causing problems with projects on Clojars
Here's the error I'm getting when I do 'lein deps' on this example (http://incanter-blog.org/2009/11/29/incanter-webapp/), which used to work. [null] An error has occurred while processing the Maven artifact tasks. [null] Diagnosis: [null] [null] Unable to resolve artifact: Missing: [null] -- [null] 1) org.clojure:clojure-lang:jar:1.1.0-alpha-SNAPSHOT I used to get the same error on this example (http://incanter-blog.org/ 2009/11/20/leiningen-clojars/ ) until I uploaded a new version of Incanter to Clojars dependent on clojure-master instead of clojure- new. The first example also depends on Compojure, which hasn't been updated, which is why I can't fix the problem on my side. Unfortunately, the second example fails at compile because of the new issue with Leiningen on Mac OS X. When I run 'lein compile' I'm getting this error: [null] java.lang.Error: Cannot load com.apple.laf.AquaLookAndFeel (hello.clj:1) The build works fine on Linux. David On Dec 11, 12:18 am, Phil Hagelberg wrote: > liebke writes: > > I like the new naming scheme, but would it be possible to add 1.1.0- > > alpha-SNAPSHOT back to the repository (in addition to the new names), > > so that builds dependent on projects in Clojars will be able to > > download their dependencies correctly again, at least until everybody > > gets a chance to upload new poms to Clojars? > > The jars with the old version number haven't disappeared, have they? > Projects relying on -alpha should still work, they will just not get the > latest and greatest version of Clojure. > > Please speak up if you've noticed otherwise, but that's my understanding. > > -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: Latest news on ClojureQL
> I'm wondering: how would you compare the use of ClojureQL and clj- > record(which sadly doesn't show much activity currently)? Isn't CQL > going back to the SQL level or database queries, whereas clj-record is > at a higher level? Would it be easy to code this higher level layer on > top of cql? Or is that less important in Clojure than it is in OO > languages? I'm not familiar with the Ruby version, so going from the description on the wiki its a persistence library which only does some SQL interaction if you write conversion fn yourself. Emphasis is on the persistence bit. On the other hand ClojureQL is strictly an SQL-Statement-Compiler, which comes with its own SQL syntax, ie (query table1 [row1 row2] (> row1 row2)) for instance. Once you've learned this syntax, which should come naturally for Clojurians, ClojureQL will make sure that it translates into sane SQL statements for a multitude of backends, meaning you don't ever have to worry about SQL again. I think your explanation of high-/low-level is correct and I think it would be easy(er) to built something like that on top of ClojureQL, but I haven't looked into it. > And a suggestion: having migrations in CQL would be great! Could you elaborate a little? /Lau -- 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
Deploying Leiningen project as WAR file?
Hi folks, Does anyone have advice (recipe, blog article, etc.) for building a servlet WAR based on a Leiningen project? Is there interest in developing a 'lein war' plugin? I'm a novice at Ant, WAR, etc., but It seems to me that most of the mechanics are already present in 'lein uberjar' -- it's just a matter of getting the WAR-specific details ironed out. Best, Graham -- 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: Deploying Leiningen project as WAR file?
While we're at it, how 'bout an EAR file? Sean On Dec 11, 11:36 am, Graham Fawcett wrote: > Hi folks, > > Does anyone have advice (recipe, blog article, etc.) for building a > servlet WAR based on a Leiningen project? > > Is there interest in developing a 'lein war' plugin? I'm a novice at > Ant, WAR, etc., but It seems to me that most of the mechanics are > already present in 'lein uberjar' -- it's just a matter of getting the > WAR-specific details ironed out. > > Best, > Graham -- 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: how 'bout a debug-repl?
On Dec 11, 2009, at 5:08 AM, Laurent PETIT wrote: > But then, we could even go one level deeper: not only provide a particular > instance that would allow to quit the REPL, but a set of instances. And if > the returned value of the call to the REPL returns one of the instances in > the set, then quit. > This would allow to nest debug-repls (but is it interesting ?) calls, and to > go back to the encapsulating repl by e.g. a call to debug-repl/quit(1), or to > go up 2 levels in the debug-repls nesting by calling debug-repl/quit(2), ... > or to go back to the main environment by e.g. a call to debug-repl/quit(). One possible implementation of this is to use keywords as commands to the debug-repl. Since evaluating a keyword (alone on a line by itself) is seldom interesting, we could use ones like :quit or :pop as commands intercepted by the debug repl before evaluation. We could even respond to a set of commands and send any unrecognized commands along to the evaluator. If hijacking namespace-less keywords for that purpose is distasteful, we could also put the commands in a namespace, for example: :dr/quit --Steve smime.p7s Description: S/MIME cryptographic signature
more dumb noob pain ("2dplot.clj")
I've been having pretty good luck writing my own programs and running lots of samples from the contribute-files section of this google group, but hit a roadblock this morning: trying to run "2dplot," I installed java3d and it passes the tests on https://j3d-webstart.dev.java.net/test/ but when I try to run 2dplot.clj, I get a user=> (load-file "2dplot.clj") java.lang.ClassNotFoundException: javax.media.j3d.BranchGroup (2dplot.clj:23) which is on the import of java3d; here's line 23, unchanged: (import '(javax.media.j3d BranchGroup LineArray GeometryArray Shape3D Transform3D TransformGroup BoundingSphere Background) '(javax.vecmath Point3f Vector3f Point3d Color3f) '(com.sun.j3d.utils.universe SimpleUniverse) '(com.sun.j3d.utils.applet MainFrame) '(com.sun.j3d.utils.behaviors.keyboard KeyNavigatorBehavior) '(com.sun.j3d.utils.geometry Text2D) '(java.applet Applet) '(java.awt BorderLayout Font)) Any hints for me? I'm sure it's because I really don't know at all how to find out where java things are installed and how to refer to them if they're installed in weird places yadda yadda. -- 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: Code arrangement for understandability
> This makes Clojure code hard to understand I'd phrase this "This makes it hard for me to understand Clojure code". Lots of us do just fine most of the time. Try spending some time reading point-free Haskell: there are *no* local names. You can do that in Clojure, too. > Is this style of "let" common and a good practice > to follow? (I just want to know, sorry if my expression is offensive) Generally, if a local is used only once, I don't bother naming it. That means I don't have too many lets, and usually not nested ones. >> (let [x 1 >> y (+ x 2)] >> (f x) >> (g y)) > > Well, I know my example code can be rewritten like that, but I just > could not give a better one. The point was that when you're programming without side-effects, *all* your code can be written in this way, because there is no ordering dependency between `f` and `g`. You know your code is spreading its use of side-effects too thinly when your code starts looking procedural. Ordering dependencies are a code smell. > Rearranging like this reminds me of C, in which every variables must > be listed beforehand. Since all Clojurians say "lazy" is good, I would > say I prefer C++ because I can be lazy in it, I only have to declare a > variable when I actually use it. Even lazier is not using a variable at all. (Note, though, that "laziness" in Clojure means delaying evaluation, not being lazy as a programmer.) -- 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: Deploying Leiningen project as WAR file?
On Fri, Dec 11, 2009 at 11:51 AM, Sean Devlin wrote: > While we're at it, how 'bout an EAR file? Never encountered one of those before -- maybe that is a good thing! :) After a little study, I was able to write a simple servlet, compile it with Leiningen, and make a WAR using Maven. This might be no big news to the Java literati in the audience, but it's all new to me. :) I thought I'd share my notes here, in case anyone else is trying to do the same thing. There is a copy of my work here: http://github.com/gmfawcett/simplest The basic recipe I followed is there, and for lazier readers it also appears below. Many thanks to yogthos' clojure-maven-examples, which answered many questions (though it uses clojure-maven-plugin, and does not use Leiningen): http://github.com/yogthos/clojure-maven-examples Best, Graham * Start a new project with Leiningen (I'm using Leiningen 1.0.1): $ lein new simplest * Add your servlet. I put mine in 'src/simplest/servlet.clj': (ns simplest.servlet (:gen-class :extends javax.servlet.http.HttpServlet)) (defn -doGet [this req resp] ...) * Add your dependencies to the project file. I added [javax.servlet/servlet-api "2.5"]. * Set the :compile-path, so that the classfiles end up where Maven will expect to see them: (defproject simplest "1.0.0-SNAPSHOT" :compile-path "target/classes" ...) * Compile it with Leiningen, to make sure there aren't any errors: $ lein compile [copy] Copying 3 files to /tmp/simplest/lib Compiling simplest Compiling simplest.servlet * Add the web.xml file and whatever static resources you want under 'src/main'. I added: src/main/webapp/WEB-INF/web.xml src/main/webapp/index.html My web.xml is basic: http://www.w3.org/2001/XMLSchema-instance"; xmlns="http://java.sun.com/xml/ns/javaee"; xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"; xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"; id="simplest" version="2.5"> Simplest Clojure Servlet simplest simplest.servlet simplest /simplest/ index.html * Make your POM file for Maven: $ lein pom Wrote pom.xml * Generate the WAR file: $ lein compile; mvn war:war $ ls target/*.war target/simplest-1.0.0-SNAPSHOT.war * QED! * If you want, you can add a 'Jetty plugin' to your pom.xml. This will enable Maven to run your servlet(s) for you in a standalone Web server, for testing: Edit pom.xml: see http://github.com/gmfawcett/simplest/commit/44d978c55ae02112647a743b6f957156787fba25 $ lein compile; mvn jetty:run # visit your servlet at http://localhost:8080/ Lacking proper Leiningen/Maven integration, it's a good idea to always call 'lein compile' before you run a Maven command. Best, Graham -- 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: how 'bout a debug-repl?
Wouldn't ::quit do the same thing? On Dec 11, 11:57 am, "Stephen C. Gilardi" wrote: > On Dec 11, 2009, at 5:08 AM, Laurent PETIT wrote: > > > But then, we could even go one level deeper: not only provide a particular > > instance that would allow to quit the REPL, but a set of instances. And if > > the returned value of the call to the REPL returns one of the instances in > > the set, then quit. > > This would allow to nest debug-repls (but is it interesting ?) calls, and > > to go back to the encapsulating repl by e.g. a call to debug-repl/quit(1), > > or to go up 2 levels in the debug-repls nesting by calling > > debug-repl/quit(2), ... or to go back to the main environment by e.g. a > > call to debug-repl/quit(). > > One possible implementation of this is to use keywords as commands to the > debug-repl. Since evaluating a keyword (alone on a line by itself) is seldom > interesting, we could use ones like :quit or :pop as commands intercepted by > the debug repl before evaluation. We could even respond to a set of commands > and send any unrecognized commands along to the evaluator. > > If hijacking namespace-less keywords for that purpose is distasteful, we > could also put the commands in a namespace, for example: > > :dr/quit > > --Steve > > smime.p7s > 3KViewDownload -- 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: Code arrangement for understandability
On Dec 11, 1:14 am, ngocdaothanh wrote: > > Do you come from a Python background? > > For the sake of this discussion, I would say I come from Erlang. > > > Judging by you examples, I looks like you're still getting used to the lisp > > style of coding. Everything is a chained function call. > > You're correct. Comming from Erlang: > * I tend to see things as if they are in a chain, concatted by commas. > * I feel that I have to write lots of nested "let"s for temporary > immutables. I think to avoid adding "let"s, Clojurians would just > don't use temporary immutables. This makes Clojure code hard to > understand, because temporary immutables with good names help explain > the code. The tricks to avoid adding "let"s in previous posts are very > ugly in my opinion. Is this style of "let" common and a good practice > to follow? (I just want to know, sorry if my expression is offensive) > > > What do you mean by abstractness? > > By "abstractness level" in the previous post, I mean level of code > block. For example I would say B1 and B4 are of the same level. > > B1 > | B2 > | B3 > B4 > > Because of indents, my previous Clojure code lied to my eyes that x, > y, f, g are not at the same block level. This is my difficulty with > Clojure. In short, I can't see a rough algorithm from any Clojure code > any more just by seeing the shape (levels) of blocks. To understand a > Clojure code, I have to look at every bit of code, look closer. > > > In Clojure we still need to look farther up the screen... > > Things in Erlang are immutable, so I think Clojure has no advantage > over Erlang here. > > > Practice using comp & partial... > > What do you mean by "comp & partial"? Could you please explain? > > > (let [x 1 > > y (+ x 2)] > > (f x) > > (g y)) > > Well, I know my example code can be rewritten like that, but I just > could not give a better one. > > Rearranging like this reminds me of C, in which every variables must > be listed beforehand. Since all Clojurians say "lazy" is good, I would > say I prefer C++ because I can be lazy in it, I only have to declare a > variable when I actually use it. > > I'm lost in Clojure, please light me a way. > > Lots of thanks. It would be much easier if you pasted some real code. So far it just looks like complaining that you find it awkward to write clojure in an imperative style. -- 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: how 'bout a debug-repl?
namespacing symbols seems sufficient, indeed. 2009/12/11 Stephen C. Gilardi > > On Dec 11, 2009, at 5:08 AM, Laurent PETIT wrote: > > But then, we could even go one level deeper: not only provide a particular > instance that would allow to quit the REPL, but a set of instances. And if > the returned value of the call to the REPL returns one of the instances in > the set, then quit. > This would allow to nest debug-repls (but is it interesting ?) calls, and > to go back to the encapsulating repl by e.g. a call to debug-repl/quit(1), > or to go up 2 levels in the debug-repls nesting by calling > debug-repl/quit(2), ... or to go back to the main environment by e.g. a call > to debug-repl/quit(). > > > One possible implementation of this is to use keywords as commands to the > debug-repl. Since evaluating a keyword (alone on a line by itself) is seldom > interesting, we could use ones like :quit or :pop as commands intercepted by > the debug repl before evaluation. We could even respond to a set of commands > and send any unrecognized commands along to the evaluator. > > If hijacking namespace-less keywords for that purpose is distasteful, we > could also put the commands in a namespace, for example: > > :dr/quit > > --Steve > > -- 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: how 'bout a debug-repl?
s/symbols/keywords/ 2009/12/11 Laurent PETIT > namespacing symbols seems sufficient, indeed. > > 2009/12/11 Stephen C. Gilardi > > >> On Dec 11, 2009, at 5:08 AM, Laurent PETIT wrote: >> >> But then, we could even go one level deeper: not only provide a particular >> instance that would allow to quit the REPL, but a set of instances. And if >> the returned value of the call to the REPL returns one of the instances in >> the set, then quit. >> This would allow to nest debug-repls (but is it interesting ?) calls, and >> to go back to the encapsulating repl by e.g. a call to debug-repl/quit(1), >> or to go up 2 levels in the debug-repls nesting by calling >> debug-repl/quit(2), ... or to go back to the main environment by e.g. a call >> to debug-repl/quit(). >> >> >> One possible implementation of this is to use keywords as commands to the >> debug-repl. Since evaluating a keyword (alone on a line by itself) is seldom >> interesting, we could use ones like :quit or :pop as commands intercepted by >> the debug repl before evaluation. We could even respond to a set of commands >> and send any unrecognized commands along to the evaluator. >> >> If hijacking namespace-less keywords for that purpose is distasteful, we >> could also put the commands in a namespace, for example: >> >> :dr/quit >> >> --Steve >> >> > -- 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: Latest news on ClojureQL
> > And a suggestion: having migrations in CQL would be great! > > Could you elaborate a little? Migrations are a way to manage the evolution of a schema of a database. I'm familiar with migration in Ruby on Rails which are explained here: http://api.rubyonrails.org/classes/ActiveRecord/Migration.html All changes to the data schema are made with migrations that, when applied (in the right order), build your database. You can also possibly go back and undo the change if the operation was not destructive (migrations have an up- and downgrade operation). The list of migrations applied are kept in a table of the database, so when an upgrade is done, the migration system knows which migrations have to be run in the upgrade step. When a migration is run, its id is added to the list of migrations that have been applied to the database. And when a migration is unapplied (downgrade operation), its id is removed from the list. That way, you can go up and down in the version of your schema. Of course you most often only play with the last migrations during the development phase. And when you deploy to production, you may be sure the same changes will be applied as what you did. And migration can also manipulate the data in addition to change the data structure. For example, it can create and populate a table with initial data. In an extreme case, if you want to split a table in multiple tables, you could do that in a migration which would - create the new tables - populate them with data from the initial table - drop columns that are now superfluous in the initial table These operation can be non-destructive, and so the migration can be undone. It's really been a time saver and I think it's a really good fit with ClojureQL. Raphaël -- 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: how 'bout a debug-repl?
On Dec 11, 2009, at 3:04 PM, Sean Devlin wrote: > Wouldn't ::quit do the same thing? It wouldn't, because the repl is evaluating in the context of wherever you put the (debug-repl) call, so its namespace won't be "dr". What about instead of using keywords for commands, we use functions for commands: (debug-repl-quit) >> One possible implementation of this is to use keywords as commands to the >> debug-repl. Since evaluating a keyword (alone on a line by itself) is seldom >> interesting, we could use ones like :quit or :pop as commands intercepted by >> the debug repl before evaluation. We could even respond to a set of commands >> and send any unrecognized commands along to the evaluator. >> >> If hijacking namespace-less keywords for that purpose is distasteful, we >> could also put the commands in a namespace, for example: >> >> :dr/quit -- 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: more dumb noob pain ("2dplot.clj")
On Fri, Dec 11, 2009 at 12:15 PM, rebcabin wrote: > > Any hints for me? I'm sure it's because I really don't know at all how > to find out where java things are installed and how to refer to them > if they're installed in weird places yadda yadda. > Are the Java 3D jar files in your CLASSPATH? e -- 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: Idiomatic way to return the key of a map, which matches a vector containing a search value.
Thanks for the suggestions. I think since the original version short circuits when it finds a result (using "some"), that's probably what I have to stick with. One thing I didn't mention in the original problem statement is that my "players" map can be large. Again, thanks for the ideas. Kyle -- 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
AbstractMethodError question
Folks--
I've got a class I can't change which has an abstract method I'd like
to override using the proxy macro in Clojure.
The class looks something like:
public abstract class Foo {
private Map stuff;
private void initStuff() {
stuff = new HashMap();
stuff.put("a", new Object());
addStuff(stuff);
}
protected void abstract addStuff(Map stuff);
}
Normally, you extend the above and implement the addStuff method.
Works in Groovy as long as I explicitly state the void return type and
the type of the parameters.
In Clojure, I construct:
(proxy [Foo] []
(addStuff [stuff] (println "yay!")))
But get an AbstractMethodError when I attempt to use the Foo class
(calling a method which eventually calls addStuff).
The docs suggest I can override a protected method class, but can't
call other protected methods, which I think is fine, here.
Is there something I'm missing?
Keith
--
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: AbstractMethodError question
On Fri, Dec 11, 2009 at 12:27 PM, Keith Irwin wrote:
> public abstract class Foo {
>
> private Map stuff;
>
> private void initStuff() {
>
> stuff = new HashMap();
> stuff.put("a", new Object());
> addStuff(stuff);
> }
>
> protected void abstract addStuff(Map stuff);
> }
> In Clojure, I construct:
>
> (proxy [Foo] []
> (addStuff [stuff] (println "yay!")))
>
I should amend this to say that I get an AbstractMethodError when the
(proxy ...) is evaluted. I'm running the code as a script.
Keith
--
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: AbstractMethodError question
On Dec 11, 12:27 pm, Keith Irwin wrote:
> Folks--
>
> I've got a class I can't change which has an abstract method I'd like
> to override using the proxy macro in Clojure.
>
> The class looks something like:
>
> public abstract class Foo {
>
> private Map stuff;
>
> private void initStuff() {
>
> stuff = new HashMap();
> stuff.put("a", new Object());
> addStuff(stuff);
> }
>
> protected void abstract addStuff(Map stuff);
> }
>
> Normally, you extend the above and implement the addStuff method.
> Works in Groovy as long as I explicitly state the void return type and
> the type of the parameters.
>
> In Clojure, I construct:
>
> (proxy [Foo] []
> (addStuff [stuff] (println "yay!")))
>
> But get an AbstractMethodError when I attempt to use the Foo class
> (calling a method which eventually calls addStuff).
>
> The docs suggest I can override a protected method class, but can't
> call other protected methods, which I think is fine, here.
>
> Is there something I'm missing?
>
> Keith
Given what you have written, the proxy function will return an
instance that extends Foo, implementing the addStuff method; it
doesn't modify the Foo class, nor provide you with a derived class.
If you want to create a derived class that's accessible from java,
you'll need to use something related to gen-class.
--
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: AbstractMethodError question
On Dec 11, 12:44 pm, Keith Irwin wrote:
> On Fri, Dec 11, 2009 at 12:27 PM, Keith Irwin wrote:
> > public abstract class Foo {
>
> > private Map stuff;
>
> > private void initStuff() {
>
> > stuff = new HashMap();
> > stuff.put("a", new Object());
> > addStuff(stuff);
> > }
>
> > protected void abstract addStuff(Map stuff);
> > }
> > In Clojure, I construct:
>
> > (proxy [Foo] []
> > (addStuff [stuff] (println "yay!")))
>
> I should amend this to say that I get an AbstractMethodError when the
> (proxy ...) is evaluted. I'm running the code as a script.
>
> Keith
Hmm, this works fine for me:
user=> (def mymap (proxy [java.util.AbstractMap] [] (entrySet []
(println "yay!"
#'user/mymap
user=> (.entrySet mymap)
yay!
nil
--
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: Idiomatic way to return the key of a map, which matches a vector containing a search value.
On Dec 11, 10:44 am, mudphone wrote: > Thanks for the suggestions. > > I think since the original version short circuits when it finds a > result (using "some"), that's probably what I have to stick with. Sean's solution does as well. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Datatypes and protocols - update
I've been trying out the new branch, and on the whole I like it a lot. I know it'll take some time to learn how do things properly the "new" way, and I've figured out how to do most of the things I want to do thus far. Thanks, Rich! One thing I haven't figured out how to do cleanly without inheritance is to specify "properties" of objects in a hierarchical domain in a clean, efficient way. I'm sure I haven't fully wrapped my head around the new abstractions, so I'd love to hear about a clean way to solve this problem. A very simple example is: I have a protocol "A", and sub-protocols "A1" and "A2". Every A is either an A1 or A2, but not both (and this split is closed, as far as I'm concerned). Sometimes I want to deal with instances of A1 and A2 together, and so I put the methods shared between all "As" in protocol "A". But, at some point I need to separate out the "A1"s from the "A2"s. To do this, it seems like I have at least three options: 1. Add an "is-A1" method to Protocol A. The problem with this option is that every type that derives from A1 needs to manually write out this method returning "true", and vice-versa for implementers of A2. Users could eliminate this by "extending" their types with a mixin map to A, rather than implementing it directly in the deftype. But, this sacrifices readability (IMO) as well as efficiency. 2. use (satisfies? A1 x) to determine if x satisfies A1. The main problem with this, at least currently, is that satisfies? seems to be really slow in the negative case. I profiled my (non-trivial) program and half the runtime was going to reflection in satisfies? Moreover, this solution is not as general. 3. Use a multimethod. This would work generally and be reasonably efficient, but I feel like I'd be cluttering up my interface by mixing up protocols and multimethods. On the other hand, I guess multimethods are the main (only?) hierarchical construct built into Clojure, so maybe this is what's intended. So, which do people feel is preferred? Or have I missed a better option? Thanks! Jason -- 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: AbstractMethodError question
On Dec 11, 3:33 pm, ataggart wrote:
> On Dec 11, 12:44 pm, Keith Irwin wrote:
>
>
>
>
>
> > On Fri, Dec 11, 2009 at 12:27 PM, Keith Irwin wrote:
> > > public abstract class Foo {
>
> > > private Map stuff;
>
> > > private void initStuff() {
>
> > > stuff = new HashMap();
> > > stuff.put("a", new Object());
> > > addStuff(stuff);
> > > }
>
> > > protected void abstract addStuff(Map stuff);
> > > }
> > > In Clojure, I construct:
>
> > > (proxy [Foo] []
> > > (addStuff [stuff] (println "yay!")))
>
> > I should amend this to say that I get an AbstractMethodError when the
> > (proxy ...) is evaluted. I'm running the code as a script.
>
> > Keith
>
> Hmm, this works fine for me:
>
> user=> (def mymap (proxy [java.util.AbstractMap] [] (entrySet []
> (println "yay!"
> #'user/mymap
> user=> (.entrySet mymap)
> yay!
> nil
The case I have is that a method in the abstract class is calling the
abstract method, and my proxy object doesn't seem to, uh, proxy that
method at all. So, in your example, there's have to be some other
method in AbstractMap that called entrySet. If that worked, then I'd
really be wondering what's going on.
Argh! ;)
Keith
--
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: AbstractMethodError question
On Dec 11, 3:31 pm, ataggart wrote:
> On Dec 11, 12:27 pm, Keith Irwin wrote:
> > Folks--
>
> > I've got a class I can't change which has an abstract method I'd like
> > to override using the proxy macro in Clojure.
>
> > The class looks something like:
>
> > public abstract class Foo {
>
> > private Map stuff;
>
> > private void initStuff() {
>
> > stuff = new HashMap();
> > stuff.put("a", new Object());
> > addStuff(stuff);
> > }
>
> > protected void abstract addStuff(Map stuff);
> > }
>
> > Normally, you extend the above and implement the addStuff method.
> > Works in Groovy as long as I explicitly state the void return type and
> > the type of the parameters.
>
> > In Clojure, I construct:
>
> > (proxy [Foo] []
> > (addStuff [stuff] (println "yay!")))
>
> > But get an AbstractMethodError when I attempt to use the Foo class
> > (calling a method which eventually calls addStuff).
>
> > The docs suggest I can override a protected method class, but can't
> > call other protected methods, which I think is fine, here.
>
> > Is there something I'm missing?
>
> > Keith
> Given what you have written, the proxy function will return an
> instance that extends Foo, implementing the addStuff method; it
> doesn't modify the Foo class, nor provide you with a derived class.
> If you want to create a derived class that's accessible from java,
> you'll need to use something related to gen-class.
I was under the impression that :gen-class only works for AOT
compilation, rather than running in a scripting context. Maybe the
solution is to add a little Java to the mix. The unfortunate part of
all this is that I HAVE to use the something like the above class due
to Politics.
Thanks!
Keith
--
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: how 'bout a debug-repl?
Hmmm... functions as commands at a REPL. Now I feel silly for considering the keyword approach :) On Dec 11, 5:26 pm, Dan Larkin wrote: > On Dec 11, 2009, at 3:04 PM, Sean Devlin wrote: > > > Wouldn't ::quit do the same thing? > > It wouldn't, because the repl is evaluating in the context of wherever you > put the (debug-repl) call, so its namespace won't be "dr". > > What about instead of using keywords for commands, we use functions for > commands: > > (debug-repl-quit) > > > > >> One possible implementation of this is to use keywords as commands to the > >> debug-repl. Since evaluating a keyword (alone on a line by itself) is > >> seldom interesting, we could use ones like :quit or :pop as commands > >> intercepted by the debug repl before evaluation. We could even respond to > >> a set of commands and send any unrecognized commands along to the > >> evaluator. > > >> If hijacking namespace-less keywords for that purpose is distasteful, we > >> could also put the commands in a namespace, for example: > > >> :dr/quit -- 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 in Python
All,
I tried to use this script on Windows and it blew up real good! I'm a
Clojure, Java, and Leiningen newbie, so perhaps a kind soul can help
me out.
1. lein self-install "worked". It downloaded leiningen-1.0.0-
standalone.jar. However, that contradicts the description at
http://zef.me/2470/building-clojure-projects-with-leiningen which
indicates that self-install should download several jars, including
clojure itself. That didn't happen, and it looks like it would never
happen according to the python script. Also, I'd rather use one and
only one clojure, clojure-contrib, etc. for everything rather than
Leiningen using its own. Is this possible?
2. Any other lein command seems to require the clojure jar in the
repository ~/.m2/repository/org/clojure/clojure/1.1.0-alpha-SNAPSHOT/
clojure-1.1.0-alpha-SNAPSHOT.jar. Since I don't have one there, I
modified CLOJURE_JAR to point to my existing jar. Everything still
fails with this sort of error:
lein help
java.lang.NoClassDefFoundError: Files
Caused by: java.lang.ClassNotFoundException: Files
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:303)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
Could not find the main class: Files. Program will exit.
Exception in thread "main"
I suspect the suspicious "Files" class name is coming from the fact
that I now have CLOJURE_JAR set as follows:
CLOJURE_JAR = expanduser("C:\\Program Files (x86)\\Clojure Box\\clojure
\\clojure-1.0.0.jar")
Looks like I'm getting bit by spaces in the path name. This would not
be an issue if lein had downloaded its own clojure jar during step 1
(no spaces in that path).
3. My clojure jar is clojure-1.0.0.jar from clojure org. The script
uses clojure-1.1.0-alpha-SNAPSHOT.jar, but a comment from the link
implies that this has been supplanted by 1.1.0-master.jar. In any
event, I don't know where either of these two things are. I tried
going to build.clojure.org, but all the build artifiacts there are
named clojure.jar.
4. BTW, what's the deal with this ".m2" directory (i.e., where does
the name come from)?
Thanks for any help you can provide!
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: Code arrangement for understandability
Below is a snippet from Rich's presentation at QCon 2009 (http://
qconlondon.com/london-2009/file?path=/qcon-london-2009/slides/
RichHickey_Clojure.pdf):
(reduce (fn [model f] (assoc model f (inc (get model f 1
{} features))
Do Clojurians usually arrange like that? Can it be rearrange for more
understandability?
Thanks
On Dec 12, 5:16 am, ataggart wrote:
> On Dec 11, 1:14 am, ngocdaothanh wrote:
>
>
>
> > > Do you come from a Python background?
>
> > For the sake of this discussion, I would say I come from Erlang.
>
> > > Judging by you examples, I looks like you're still getting used to the
> > > lisp style of coding. Everything is a chained function call.
>
> > You're correct. Comming from Erlang:
> > * I tend to see things as if they are in a chain, concatted by commas.
> > * I feel that I have to write lots of nested "let"s for temporary
> > immutables. I think to avoid adding "let"s, Clojurians would just
> > don't use temporary immutables. This makes Clojure code hard to
> > understand, because temporary immutables with good names help explain
> > the code. The tricks to avoid adding "let"s in previous posts are very
> > ugly in my opinion. Is this style of "let" common and a good practice
> > to follow? (I just want to know, sorry if my expression is offensive)
>
> > > What do you mean by abstractness?
>
> > By "abstractness level" in the previous post, I mean level of code
> > block. For example I would say B1 and B4 are of the same level.
>
> > B1
> > | B2
> > | B3
> > B4
>
> > Because of indents, my previous Clojure code lied to my eyes that x,
> > y, f, g are not at the same block level. This is my difficulty with
> > Clojure. In short, I can't see a rough algorithm from any Clojure code
> > any more just by seeing the shape (levels) of blocks. To understand a
> > Clojure code, I have to look at every bit of code, look closer.
>
> > > In Clojure we still need to look farther up the screen...
>
> > Things in Erlang are immutable, so I think Clojure has no advantage
> > over Erlang here.
>
> > > Practice using comp & partial...
>
> > What do you mean by "comp & partial"? Could you please explain?
>
> > > (let [x 1
> > > y (+ x 2)]
> > > (f x)
> > > (g y))
>
> > Well, I know my example code can be rewritten like that, but I just
> > could not give a better one.
>
> > Rearranging like this reminds me of C, in which every variables must
> > be listed beforehand. Since all Clojurians say "lazy" is good, I would
> > say I prefer C++ because I can be lazy in it, I only have to declare a
> > variable when I actually use it.
>
> > I'm lost in Clojure, please light me a way.
>
> > Lots of thanks.
>
> It would be much easier if you pasted some real code. So far it just
> looks like complaining that you find it awkward to write clojure in an
> imperative style.
--
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: Code arrangement for understandability
> (reduce (fn [model f] (assoc model f (inc (get model f 1
>{} features))
>
> Do Clojurians usually arrange like that? Can it be rearrange for more
> understandability?
I can't speak for everyone, but I don't think it's common to jam
*everything* on one line. I imagine Rich was laying out for space on
slides.
For maximum readability I would arrange that thusly:
(reduce
(fn [model f]
(assoc model
f (inc (get model f 1
{}
features))
or, less verbosely
(reduce
(fn [model f]
(assoc model f (inc (get model f 1
{} features))
--
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: Code arrangement for understandability
On Dec 11, 10:33 pm, Richard Newman wrote:
> > (reduce (fn [model f] (assoc model f (inc (get model f 1
> > {} features))
>
> > Do Clojurians usually arrange like that? Can it be rearrange for more
> > understandability?
>
> I can't speak for everyone, but I don't think it's common to jam
> *everything* on one line. I imagine Rich was laying out for space on
> slides.
>
> For maximum readability I would arrange that thusly:
>
> (reduce
> (fn [model f]
> (assoc model
> f (inc (get model f 1
> {}
> features))
>
> or, less verbosely
>
> (reduce
> (fn [model f]
> (assoc model f (inc (get model f 1
> {} features))
Or one could be ridiculously verbose:
(reduce #(let [[model feature] %&
val (get model feature 1)
val (inc val)]
(assoc model feature val))
{}
features)
Its worth noting that the only reason for these extra steps is that,
unlike get, update-in doesn't take a not-found arg (much to my
chagrin). If it had a signature as has recently been discussed
(http://groups.google.com/group/clojure/browse_thread/thread/
99cc4a6bfe665a6e), then the code could simplified down to:
(reduce #(update-in %1 [%2] 2 inc) {} features)
--
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: Datatypes and protocols - update
On Dec 11, 4:14 pm, Jason Wolfe wrote: > I've been trying out the new branch, and on the whole I like it a lot. > I know it'll take some time to learn how do things properly the "new" > way, and I've figured out how to do most of the things I want to do > thus far. Thanks, Rich! > > One thing I haven't figured out how to do cleanly without inheritance > is to specify "properties" of objects in a hierarchical domain in a > clean, efficient way. I'm sure I haven't fully wrapped my head around > the new abstractions, so I'd love to hear about a clean way to solve > this problem. > > A very simple example is: I have a protocol "A", and sub-protocols > "A1" and "A2". Every A is either an A1 or A2, but not both (and this > split is closed, as far as I'm concerned). Sometimes I want to deal > with instances of A1 and A2 together, and so I put the methods shared > between all "As" in protocol "A". But, at some point I need to > separate out the "A1"s from the "A2"s. To do this, it seems like I > have at least three options: > > 1. Add an "is-A1" method to Protocol A. The problem with this option > is that every type that derives from A1 needs to manually write out > this method returning "true", and vice-versa for implementers of A2. > Users could eliminate this by "extending" their types with a mixin map > to A, rather than implementing it directly in the deftype. But, this > sacrifices readability (IMO) as well as efficiency. > > 2. use (satisfies? A1 x) to determine if x satisfies A1. The main > problem with this, at least currently, is that satisfies? seems to be > really slow in the negative case. I profiled my (non-trivial) program > and half the runtime was going to reflection in satisfies? Moreover, > this solution is not as general. > > 3. Use a multimethod. This would work generally and be reasonably > efficient, but I feel like I'd be cluttering up my interface by mixing > up protocols and multimethods. On the other hand, I guess > multimethods are the main (only?) hierarchical construct built into > Clojure, so maybe this is what's intended. > > So, which do people feel is preferred? Or have I missed a better > option? > > Thanks! > Jason If I understand Rich's reasoning, what you want runs antithetical to the protocols design, namely it being explicitly non-hierarchical. As such, you'd instead have 3 composable protocols, A, B, and C (where B and C would correspond to the functions of A1 and A2, respectively): (defprotocol A (a [x])) (defprotocol B (b [x])) (defprotocol C (c [x])) And then the type would reify the appropriate protocols: (deftype A1 [] A B (a [] (println "in A1.a")) (b [] (println "in A1.b"))) (deftype A2 [] A C (a [] (println "in A2.a")) (c [] (println "in A2.c"))) -- 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: Datatypes and protocols - update
On Dec 11, 11:44 pm, ataggart wrote: > On Dec 11, 4:14 pm, Jason Wolfe wrote: > > > > > > > I've been trying out the new branch, and on the whole I like it a lot. > > I know it'll take some time to learn how do things properly the "new" > > way, and I've figured out how to do most of the things I want to do > > thus far. Thanks, Rich! > > > One thing I haven't figured out how to do cleanly without inheritance > > is to specify "properties" of objects in a hierarchical domain in a > > clean, efficient way. I'm sure I haven't fully wrapped my head around > > the new abstractions, so I'd love to hear about a clean way to solve > > this problem. > > > A very simple example is: I have a protocol "A", and sub-protocols > > "A1" and "A2". Every A is either an A1 or A2, but not both (and this > > split is closed, as far as I'm concerned). Sometimes I want to deal > > with instances of A1 and A2 together, and so I put the methods shared > > between all "As" in protocol "A". But, at some point I need to > > separate out the "A1"s from the "A2"s. To do this, it seems like I > > have at least three options: > > > 1. Add an "is-A1" method to Protocol A. The problem with this option > > is that every type that derives from A1 needs to manually write out > > this method returning "true", and vice-versa for implementers of A2. > > Users could eliminate this by "extending" their types with a mixin map > > to A, rather than implementing it directly in the deftype. But, this > > sacrifices readability (IMO) as well as efficiency. > > > 2. use (satisfies? A1 x) to determine if x satisfies A1. The main > > problem with this, at least currently, is that satisfies? seems to be > > really slow in the negative case. I profiled my (non-trivial) program > > and half the runtime was going to reflection in satisfies? Moreover, > > this solution is not as general. > > > 3. Use a multimethod. This would work generally and be reasonably > > efficient, but I feel like I'd be cluttering up my interface by mixing > > up protocols and multimethods. On the other hand, I guess > > multimethods are the main (only?) hierarchical construct built into > > Clojure, so maybe this is what's intended. > > > So, which do people feel is preferred? Or have I missed a better > > option? > > > Thanks! > > Jason > > If I understand Rich's reasoning, what you want runs antithetical to > the protocols design, namely it being explicitly non-hierarchical. > > As such, you'd instead have 3 composable protocols, A, B, and C (where > B and C would correspond to the functions of A1 and A2, respectively): > > (defprotocol A (a [x])) > (defprotocol B (b [x])) > (defprotocol C (c [x])) > > And then the type would reify the appropriate protocols: > > (deftype A1 [] A B > (a [] (println "in A1.a")) > (b [] (println "in A1.b"))) > > (deftype A2 [] A C > (a [] (println "in A2.a")) > (c [] (println "in A2.c"))) I should also note that isa? can be used for differentiation: user=> (def my-a (A1)) #'user/my-a user=> (isa? (type my-a) ::A1) true user=> (isa? (type my-a) ::A2) false -- 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
