Re: Simple Clojure/Java interop
This method that makes a simple call to the log4j library throws an exception even though the message it written to the file. Not sure if there has something to do with static methods again. user>( defn logtrace[message]( (let [logger (org.apache.log4j.LogManager/getLogger "Stream")]( .log logger org.apache.log4j.Level/FATAL message ) ))) user>(logtrace name ) Backtrace: 0: user$logtrace.invoke(NO_SOURCE_FILE:1) 1: user$eval2626.invoke(NO_SOURCE_FILE:1) 2: clojure.lang.Compiler.eval(Compiler.java:5424) 3: clojure.lang.Compiler.eval(Compiler.java:5391) 4: clojure.core$eval.invoke(core.clj:2382) I have been able to log successfully from within .clj files as well as using the REPL but there is an exception always. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Simple Clojure/Java interop
Hi, On 18 Apr., 09:43, MohanR wrote: > user>( defn logtrace[message]( ; <- paren? > (let [logger (org.apache.log4j.LogManager/getLogger "Stream")]( > .log logger org.apache.log4j.Level/FATAL message > ) > )) ; <- paren? > ) You don't say what the exception is, but I suspect a NPE. If it is an NPE, it most likely comes from these parens, because (.log) probably returns nil and you finally try to call nil as a function. Disclaimer: Don't get the following wrong. I know you are a newbie. It is meant as a honest advice. YMMV. You should consider a different style of indentation. It really helps to spot these issues. Compare: (defn logtrace [message] ((let [logger (org.apache.log4j.LogManager/getLogger "Stream")] (.log logger org.apache.log4j.Level/FATAL message With this layout you can easily spot the two parens in front of the let, which is almost always not what you want. 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: Simple Clojure/Java interop
Thanks. There is no NPE now. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
newbie question
hello, i'm trying to start learning clojure with lein but i get into trouble. I'm doing simple project: > lein new foo > cd foo > lein deps > echo '(println "hello")' >> src/foo/core.clj > lein run -m foo.core hello Exception in thread "main" java.lang.NullPointerException (NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:5440) at clojure.lang.Compiler.eval(Compiler.java:5415) at clojure.lang.Compiler.eval(Compiler.java:5391) at clojure.core$eval.invoke(core.clj:2382) at clojure.main$eval_opt.invoke(main.clj:235) at clojure.main$initialize.invoke(main.clj:254) at clojure.main$null_opt.invoke(main.clj:279) at clojure.main$main.doInvoke(main.clj:354) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:369) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:482) at clojure.main.main(main.java:37) Caused by: java.lang.NullPointerException at user$eval13.invoke(NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:5424) ... 12 more obviously my code ((println "hello")) was executed followed by exception which i don't understand. What is 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: newbie question
Hi, lein run looks for a -main function in your source file. This is a convention borrowed from java (and other languages). The null pointer exception is probably lein or clojure looking for -main. > echo '(defn -main [] (println "no exception)' >> src/foo/core.clj > lein run -m foo.core hello asdf Ambrose On Mon, Apr 18, 2011 at 7:48 PM, lesni bleble wrote: > hello, > > i'm trying to start learning clojure with lein but i get into > trouble. I'm doing simple project: > > > lein new foo > > cd foo > > lein deps > > echo '(println "hello")' >> src/foo/core.clj > > lein run -m foo.core > hello > Exception in thread "main" java.lang.NullPointerException > (NO_SOURCE_FILE:1) >at clojure.lang.Compiler.eval(Compiler.java:5440) >at clojure.lang.Compiler.eval(Compiler.java:5415) >at clojure.lang.Compiler.eval(Compiler.java:5391) >at clojure.core$eval.invoke(core.clj:2382) >at clojure.main$eval_opt.invoke(main.clj:235) >at clojure.main$initialize.invoke(main.clj:254) >at clojure.main$null_opt.invoke(main.clj:279) >at clojure.main$main.doInvoke(main.clj:354) >at clojure.lang.RestFn.invoke(RestFn.java:421) >at clojure.lang.Var.invoke(Var.java:369) >at clojure.lang.AFn.applyToHelper(AFn.java:163) >at clojure.lang.Var.applyTo(Var.java:482) >at clojure.main.main(main.java:37) > Caused by: java.lang.NullPointerException >at user$eval13.invoke(NO_SOURCE_FILE:1) >at clojure.lang.Compiler.eval(Compiler.java:5424) >... 12 more > > obviously my code ((println "hello")) was executed followed by > exception which i don't understand. What is 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: newbie question
To use lein run, you need to do two things: 1) Write a -main function (defn -main [] ... ) in whatever namespace you like (you could put it in the core namescape, like you did in your echo statement for the (println "foo")). For example: (defn -main [] (println "foo")) 2) Specify which namespace holds this main function in your project.clj file in the root of your project. It's just another entry, like :dependencies, and it looks like this: :main foo.core Now when you run 'lein run', it will find your main function in that namespace and run it. If this seems a bit random, it's part Clojure's Java heritage. It's basically a shortcut for running your program as if it were an exectuble jar, which must have a "main" function that acts as an entry point for the program. The command 'lein run' allows you to treat your program as an executable jar without having to actually run 'lein uberjar' and then execute it separately. -Daniel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Help with function to partition my data
(Sent the below email earlier but for some reason didn't make it to the list)
I wasn't aware of the group-by function. Being new to clojure, I spent a lot of
time coming up with my complex function. Seeing the one line solution really
blew me away. Thanks!!
Follow up questions on my problem (my code again first):
;data is a list of records (maps)
(def data '({:a1 2 :a2 34 :a3 76 :a4 87},
{:a1 3 :a2 30 :a3 38 :a4 39},
{:a1 2 :a2 67 :a3 32 :a4 38},
{:a1 4 :a2 47 :a3 73 :a4 38},
{:a1 3 :a2 84 :a3 86 :a4 63}))
;result is a map, key = value of :a1, val = all records for that value of a1
;as pointed out, result can be obtained by (group-by :a1 data)
(def result
'{2 [{:a1 2 :a2 34 :a3 76 :a4 87}, {:a1 2 :a2 67 :a3 32 :a4 39}], ;grouped a1
= 2
3 [{:a1 3 :a2 30 :a3 38 :a4 39}, {:a1 3 :a2 84 :a3 86 :a4 63}], ;grouped a1
= 3
4 [{:a1 4 :a2 47 :a3 73 :a4 38}] ;grouped :a1 = 4
})
;groups the data by :a1 (see result above)
(def data-g (group-by :a1 data)
;for a key value in data-g returns the total of all :a4 values
(defn calc-tot-a4 [data-g k]
(reduce + (map :a4 (get data-g k
;adjust a4 values for a given key
(defn adj-a4 [data k]
(assoc data k (map #(assoc % :a4 (+ (:a3 %) (:a4 %))) (get data k
;adjust data
(defn adj-data [data f]
(reduce f data (keys data)))
;make adjustments to the grouped data
(def data-adj (adj-data data-g adj-a4))
I am expressing my domain specific problem in a very abstract way above. In
reality the data I am manipulating comes from a database. This is financial
performance data for an entire month. The data set is large - about 50,000
records. I need to group it by "day" and then perform manipulations on it. For
example, I need to make adjustments to the values loaded from the database
based on certain conditions. I need to aggregate values for a certain day etc.
My question is - am I on the right track with the adj-data/adj-a4 functions.
Secondly since I am constantly modifying the in-memory data (loaded using
contrib.sql functions which loads it into plain maps), is this inefficient
since the data structures are immutable. So every time I change a value,
clojure functions will return me a new data structure. Will this be inefficient
when I am dealing with a large data set and making constant
modifications/adjustments to the values?
Thanks for your great help.
-Original Message-
From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On Behalf Of
Alan
Sent: Sunday, April 17, 2011 5:18 PM
To: Clojure
Subject: Re: Help with function to partition my data
Simpler still: group-by?
(group-by :a1 data) produces the result that Shoeb was looking for.
PS The original message isn't in Google's archives either.
On Apr 17, 7:54 am, Nate Austin wrote:
> I didn't see this original email for some reason, but here's a
> simplified version:
>
> (reduce
> (fn [coll {a1 :a1 :as value}] (update-in coll [a1] conj value))
> {}
> data)
>
> This takes advantage of update-in passing nil if it doesn't have the
> key and conj with nil returning a seq of one value.
>
>
>
>
>
>
>
> On Sun, Apr 17, 2011 at 12:30 AM, Shoeb Bhinderwala wrote:
> > Wrote the following function which did the trick:
>
> > (defn partn [data]
> > (let
> > [add-mapping
> > (fn [m v]
> > (assoc m v (filter #(= v (:a1 %)) data)))]
> > (reduce add-mapping {} (set (map #(:a1 %) data
>
> > On Sat, Apr 16, 2011 at 8:15 PM, shuaybi wrote:
>
> >> I am trying to write a function but can't get it right. I need to loop
> >> through my data records and for each unique value of :a1 I need to
> >> partition the data and create a resulting map so that the key is value
> >> of :a1 and the associated value of this key is all records with that
> >> value of :a1. Better explained with code, where given the definition
> >> of data below, I need to write a function that will return the
> >> definition of "result" below.
>
> >> ;data is a list of records (maps)
> >> (def data '({:a1 2 :a2 34 :a3 76 :a4 87},
> >> {:a1 3 :a2 30 :a3 38 :a4 39},
> >> {:a1 2 :a2 67 :a3 32 :a4 38},
> >> {:a1 4 :a2 47 :a3 73 :a4 38},
> >> {:a1 3 :a2 84 :a3 86 :a4 63}))
>
> >> ;result should be a map, keyed by unique values of :a1 and containing
> >> all records for that value of :a1
> >> (def result '{2 ({:a1 2 :a2 34 :a3 76 :a4 87}, {:a1 2 :a2 67 :a3
> >> 32 :a4 39}), ;list of records where :a1 = 2
> >> 3 ({:a1 3 :a2 30 :a3 38 :a4 39}, {:a1 3 :a2 84 :a3
> >> 86 :a4 63}), ;list of records where :a1 = 3
> >> 4 ({:a1 4 :a2 47 :a3 73 :a4 38}) ;list of records
> >> where :a1 = 4
> >> })
>
> >> (defn get-val-a1
> >> "Return all records in data where :a1 is specified val"
> >> [data val]
> >> (filter
> >> #(= val (:a1 %)) ;filter function
> >> data))
>
> >> (defn unique-a1
> >> "Get set of all unique :a1 values"
> >> [m]
> >> (set (map #(:a1
Re: Understanding the Clojure source-code and functionality
You may want to follow this thread and look for the latest version of Clojure in Small Pieces: http://groups.google.com/group/clojure/browse_thread/thread/460417fe45f314c3/db1e7b58031efc7e On Apr 17, 12:27 pm, Terje Dahl wrote: > I would very much like to study and understand how Clojure works > "under the hood". > > Yes, I have downloaded the source and looked at it. > Yes, I have all the books about programming in Clojure. > > But what I am looking for is learning and understanding how the > Clojure JVM-code actually works. > And how it interacts with with the CLJ-files. > About underlying principals and functionality in general, > considerations in relation to Java and the JVM, and where the > development path goes from here. > > Is anything written on the subject? > Is there a book under way? > > Perhaps this is an interesting project on its own - and important for > developing understanding for Clojure, and helping aspiring developers > (such as myself) to participate in the development of 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
Future of clojure.contrib.core/-?> macro
Hello, The -?> and -?>> macros are currently inside "old", "soon to be deprecated" clojure contrib. They have proven useful to me a number of times, and I personnally wouldn't see them stay in the soon "deprecated" , "not maintained anymore" old clojure contrib repo/jar. (Not to say that I would not want to have to add the whole old clojure contrib jar to my project just for these macros). So the question is: do a sufficiently important number of other people use and want them as well ? If so, I may ask to the clojure-dev ml if and how and/or where we could move this macro so that it is still visible and `usable`. But if nobody uses it (or few people), then I could understand, and then I'd revert to use my own copy of this macro in my projects (ick). "Users of the Null Safe Threading Operators, speak today, or suffer tomorrow !" ;-) Cheers, -- Laurent Petit -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Future of clojure.contrib.core/-?> macro
On 18 April 2011 16:47, Laurent PETIT wrote: > So the question is: do a sufficiently important number of other people > use and want them as well ? If so, I may ask to the clojure-dev ml if > and how and/or where we could move this macro so that it is still > visible and `usable`. I use it, and I think more people would use it if this were in core. - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Future of clojure.contrib.core/-?> macro
I definitely find them useful. On Apr 18, 8:47 am, Laurent PETIT wrote: > Hello, > > The -?> and -?>> macros are currently inside "old", "soon to be > deprecated" clojure contrib. > > They have proven useful to me a number of times, and I personnally > wouldn't see them stay in the soon "deprecated" , "not maintained > anymore" old clojure contrib repo/jar. (Not to say that I would not > want to have to add the whole old clojure contrib jar to my project > just for these macros). > > So the question is: do a sufficiently important number of other people > use and want them as well ? If so, I may ask to the clojure-dev ml if > and how and/or where we could move this macro so that it is still > visible and `usable`. > > But if nobody uses it (or few people), then I could understand, and > then I'd revert to use my own copy of this macro in my projects (ick). > > "Users of the Null Safe Threading Operators, speak today, or suffer > tomorrow !" ;-) > > Cheers, > > -- > Laurent Petit -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Future of clojure.contrib.core/-?> macro
I use -?> quite often. On Mon, Apr 18, 2011 at 11:47 AM, Laurent PETIT wrote: > Hello, > > The -?> and -?>> macros are currently inside "old", "soon to be > deprecated" clojure contrib. > > They have proven useful to me a number of times, and I personnally > wouldn't see them stay in the soon "deprecated" , "not maintained > anymore" old clojure contrib repo/jar. (Not to say that I would not > want to have to add the whole old clojure contrib jar to my project > just for these macros). > > So the question is: do a sufficiently important number of other people > use and want them as well ? If so, I may ask to the clojure-dev ml if > and how and/or where we could move this macro so that it is still > visible and `usable`. > > But if nobody uses it (or few people), then I could understand, and > then I'd revert to use my own copy of this macro in my projects (ick). > > "Users of the Null Safe Threading Operators, speak today, or suffer > tomorrow !" ;-) > > Cheers, > > -- > Laurent Petit > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Future of clojure.contrib.core/-?> macro
On Mon, Apr 18, 2011 at 9:33 AM, James Reeves wrote: > I use it, and I think more people would use it if this were in core. I only discovered them recently - they would certainly be more discoverable in core and that would lead to greater use (so the question then will be whether Clojure/core consider them idiomatic or whether they think handling nil should be done a different way). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Future of clojure.contrib.core/-?> macro
On 18 Apr 2011, at 17:47, Laurent PETIT wrote: The -?> and -?>> macros are currently inside "old", "soon to be deprecated" clojure contrib. I must confess that I don't even know what those macros do, so I have no opinion. However, I think the question of "what will happen to module clojure.contrib.XXX" is of wider interest. Only very few modules/ sublibraries have made it into the "new contrib". OK, many of the old ones (including some of mine) are experiments and probably not used by anyone any more. But there's a lot in between: useful and used code that for whatever reason does not satisfy the stricter criteria (whatever they are) of "new contrib". Concerning my own modules in old contrib, there are three that I use myself and that I am planning to maintain, independently of where they will end up: - clojure.contrib.monads - clojure.contrib.macro-utils - clojure.contrib.generic If nothing else is decided collectively, I'll maintain them as private projects on Google Codes or Bitbucket. 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: Future of clojure.contrib.core/-?> macro
I very much like the -?> and -?>> macros and fine them pretty useful. I'd support their addition into core. Also, regarding Konrad's comment: I also find a lot of random one-off things in old contrib that I think are useful to use as well as to read through some of the source. I think something like a solid Monad library deserves a place in contrib, and other smaller packages should be combed for useful nuggets and rolled into comprehensive, cohesive libraries. Paul On Apr 18, 11:49 am, Konrad Hinsen wrote: > On 18 Apr 2011, at 17:47, Laurent PETIT wrote: > > > The -?> and -?>> macros are currently inside "old", "soon to be > > deprecated" clojure contrib. > > I must confess that I don't even know what those macros do, so I have > no opinion. > > However, I think the question of "what will happen to module > clojure.contrib.XXX" is of wider interest. Only very few modules/ > sublibraries have made it into the "new contrib". OK, many of the old > ones (including some of mine) are experiments and probably not used by > anyone any more. But there's a lot in between: useful and used code > that for whatever reason does not satisfy the stricter criteria > (whatever they are) of "new contrib". > > Concerning my own modules in old contrib, there are three that I use > myself and that I am planning to maintain, independently of where they > will end up: > - clojure.contrib.monads > - clojure.contrib.macro-utils > - clojure.contrib.generic > > If nothing else is decided collectively, I'll maintain them as private > projects on Google Codes or Bitbucket. > > 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: Future of clojure.contrib.core/-?> macro
+1 for Konrad's Monad library sent from my mobile device On Apr 18, 2011 9:19 PM, "Paul deGrandis" wrote: > I very much like the -?> and -?>> macros and fine them pretty useful. > I'd support their addition into core. > > Also, regarding Konrad's comment: > I also find a lot of random one-off things in old contrib that I think > are useful to use as well as to read through some of the source. I > think something like a solid Monad library deserves a place in > contrib, and other smaller packages should be combed for useful > nuggets and rolled into comprehensive, cohesive libraries. > > Paul > > On Apr 18, 11:49 am, Konrad Hinsen wrote: >> On 18 Apr 2011, at 17:47, Laurent PETIT wrote: >> >> > The -?> and -?>> macros are currently inside "old", "soon to be >> > deprecated" clojure contrib. >> >> I must confess that I don't even know what those macros do, so I have >> no opinion. >> >> However, I think the question of "what will happen to module >> clojure.contrib.XXX" is of wider interest. Only very few modules/ >> sublibraries have made it into the "new contrib". OK, many of the old >> ones (including some of mine) are experiments and probably not used by >> anyone any more. But there's a lot in between: useful and used code >> that for whatever reason does not satisfy the stricter criteria >> (whatever they are) of "new contrib". >> >> Concerning my own modules in old contrib, there are three that I use >> myself and that I am planning to maintain, independently of where they >> will end up: >> - clojure.contrib.monads >> - clojure.contrib.macro-utils >> - clojure.contrib.generic >> >> If nothing else is decided collectively, I'll maintain them as private >> projects on Google Codes or Bitbucket. >> >> 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
Feedback Request
Hi, For the last few weeks, I've been working on a Clojure Swing wrapper called Seesaw. I've learned a lot about Clojure so far, but I think it's time to ask for some feedback. If I wait 'til it's perfect or complete, ... well, then no one would ever hear from me. The code can be found on github here: https://github.com/daveray/seesaw I guess I'm looking for two kinds of feedback: 1) Is something like this useful or interesting to anybody? As someone who spends a lot of time programming Swing, it's useful to me, but if some tweaks or changes would help others, I'd like to know. 2) How bad am I abusing Clojure and what could I do to improve it? It's not particularly functional, but I'm currently using Swing's insanely imperative style as an excuse for that. Thanks! Dave -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Future of clojure.contrib.core/-?> macro
On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote: On 18 Apr 2011, at 17:47, Laurent PETIT wrote: The -?> and -?>> macros are currently inside "old", "soon to be deprecated" clojure contrib. I must confess that I don't even know what those macros do, so I have no opinion. However, I think the question of "what will happen to module clojure.contrib.XXX" is of wider interest. Only very few modules/ sublibraries have made it into the "new contrib". OK, many of the old ones (including some of mine) are experiments and probably not used by anyone any more. But there's a lot in between: useful and used code that for whatever reason does not satisfy the stricter criteria (whatever they are) of "new contrib". Concerning my own modules in old contrib, there are three that I use myself and that I am planning to maintain, independently of where they will end up: - clojure.contrib.monads - clojure.contrib.macro-utils - clojure.contrib.generic If nothing else is decided collectively, I'll maintain them as private projects on Google Codes or Bitbucket. The only criterion for migrating into new contrib is someone willing to do the work of moving, and, subsequently, maintaining. This processes is emphatically not about deprecating the contrib libs, nor pushing anything out. We had to work out the kinks in the new build/deploy method, and that was done first for: Some brand new libs (e.g. unify, nrepl and finger trees) Some of the most common others, as need arose and time permitted for the core team. We *are* deprecating the old build process and packaging, but I would hope anyone with any interest in any of the other contrib libs would please step up and move them over. The only ones that will be left behind will be those that die of neglect or disinterest. Stuart Sierra has documented the process here: http://dev.clojure.org/display/design/How+to+Create+New+Contrib+Projects and I'm sure will be willing to help out anyone with the desire to move a lib. What you should not do is wait for someone else to move your favorite lib. We've moved the ones we have time to do, and expect the community to do the rest, with our help. Special thanks to Stuart Sierra and Chas Emerick, who did a ton of work to set this up. I hope that clarifies things, 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: Future of clojure.contrib.core/-?> macro
> On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote: >> If nothing else is decided collectively, I'll maintain them as private >> projects on Google Codes or Bitbucket. If they don't end up as part of the new lineup of contrib libraries, would you at least keep them on github.com? On Mon, Apr 18, 2011 at 5:15 PM, Rich Hickey wrote: > The only criterion for migrating into new contrib is someone willing to do > the work of moving, and, subsequently, maintaining. Rich, could you comment on the process for picking new names for the libraries? I got the impression that Clojure/core were trying to do a bit of cleanup there by introducing a better namespace structure for the libraries that survive 1.3.0? (which is definitely a good step forward) > Some of the most common others, as need arose and time permitted for the > core team. For example, clojure.contrib.sql will survive as clojure.java.jdbc. > http://dev.clojure.org/display/design/How+to+Create+New+Contrib+Projects That process requires actions by members of the Clojure organization - https://github.com/clojure - and the folks who manage the Hudson build server - http://build.clojure.org/people/ - so you do need to get those people engaged in helping you move your contrib libraries into the new world. I forked clojure.java.jdbc to get a first cut build in place once that new contrib library was approved. Part of the work is setting up the maven stuff correctly and then cleaning up any dependencies on old contrib libraries. I'm already using clojure.java.jdbc 0.0.1-SNAPSHOT in my own code while I am waiting to engage with Stephen Gilardi and the other folks to get the code back into the Clojure repo and onto Hudson. I'd definitely like to see the monads library move forward (and I think -?> and -?>> should be considered for core, alongside -> and ->>). I'm not (yet) familiar enough with a lot of the other contrib libraries to have an opinion (c.c.sql was the only one I was relying on - but since we just started integrating Clojure into our production code base, I may well start to depend on others :) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Feedback Request
I haven't had a chance to look over more than the README, but I was actually considering writing something like this myself. Before I progress any further, I must say: thank you so much for doing this so that I don't have to. On Apr 18, 5:57 pm, Dave Ray wrote: > Hi, > > For the last few weeks, I've been working on a Clojure Swing wrapper > called Seesaw. I've learned a lot about Clojure so far, but I think > it's time to ask for some feedback. If I wait 'til it's perfect or > complete, ... well, then no one would ever hear from me. The code can > be found on github here: > > https://github.com/daveray/seesaw > > I guess I'm looking for two kinds of feedback: > > 1) Is something like this useful or interesting to anybody? As someone > who spends a lot of time programming Swing, it's useful to me, but if > some tweaks or changes would help others, I'd like to know. > > 2) How bad am I abusing Clojure and what could I do to improve it? > It's not particularly functional, but I'm currently using Swing's > insanely imperative style as an excuse for that. > > Thanks! > > Dave -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Future of clojure.contrib.core/-?> macro
Rich, Thanks for the feedback and righting some things for me. Can you speak to the -?> and -?>> macros, specifically if you think nil should be handled differently, or if these macros code find a new home in core? That said, I'd happily pitch in and help maintain a handful of the contrib libs for the community. I'll take it upon myself to get my CA in, acquire any accounts I need, and work with Stuart Sierra to get all the support and setup I need. So community, aside from monads, what contrib libs are top picks? Paul On Apr 18, 6:02 pm, Sean Corfield wrote: > > On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote: > >> If nothing else is decided collectively, I'll maintain them as private > >> projects on Google Codes or Bitbucket. > > If they don't end up as part of the new lineup of contrib libraries, > would you at least keep them on github.com? > > On Mon, Apr 18, 2011 at 5:15 PM, Rich Hickey wrote: > > The only criterion for migrating into new contrib is someone willing to do > > the work of moving, and, subsequently, maintaining. > > Rich, could you comment on the process for picking new names for the > libraries? I got the impression that Clojure/core were trying to do a > bit of cleanup there by introducing a better namespace structure for > the libraries that survive 1.3.0? (which is definitely a good step > forward) > > > Some of the most common others, as need arose and time permitted for the > > core team. > > For example, clojure.contrib.sql will survive as clojure.java.jdbc. > > >http://dev.clojure.org/display/design/How+to+Create+New+Contrib+Projects > > That process requires actions by members of the Clojure organization > -https://github.com/clojure- and the folks who manage the Hudson build > server -http://build.clojure.org/people/- so you do need to get > those people engaged in helping you move your contrib libraries into > the new world. > > I forked clojure.java.jdbc to get a first cut build in place once that > new contrib library was approved. Part of the work is setting up the > maven stuff correctly and then cleaning up any dependencies on old > contrib libraries. I'm already using clojure.java.jdbc 0.0.1-SNAPSHOT > in my own code while I am waiting to engage with Stephen Gilardi and > the other folks to get the code back into the Clojure repo and onto > Hudson. > > I'd definitely like to see the monads library move forward (and I > think -?> and -?>> should be considered for core, alongside -> and > ->>). I'm not (yet) familiar enough with a lot of the other contrib > libraries to have an opinion (c.c.sql was the only one I was relying > on - but since we just started integrating Clojure into our production > code base, I may well start to depend on others :) > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View --http://corfield.org/ > World Singles, LLC. --http://worldsingles.com/ > Railo Technologies, Inc. --http://www.getrailo.com/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Future of clojure.contrib.core/-?> macro
2011/4/19 Rich Hickey : > > On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote: > >> On 18 Apr 2011, at 17:47, Laurent PETIT wrote: >> >>> The -?> and -?>> macros are currently inside "old", "soon to be >>> deprecated" clojure contrib. >> >> I must confess that I don't even know what those macros do, so I have no >> opinion. >> >> However, I think the question of "what will happen to module >> clojure.contrib.XXX" is of wider interest. Only very few >> modules/sublibraries have made it into the "new contrib". OK, many of the >> old ones (including some of mine) are experiments and probably not used by >> anyone any more. But there's a lot in between: useful and used code that for >> whatever reason does not satisfy the stricter criteria (whatever they are) >> of "new contrib". >> >> Concerning my own modules in old contrib, there are three that I use >> myself and that I am planning to maintain, independently of where they will >> end up: >> - clojure.contrib.monads >> - clojure.contrib.macro-utils >> - clojure.contrib.generic >> >> If nothing else is decided collectively, I'll maintain them as private >> projects on Google Codes or Bitbucket. >> >> > > The only criterion for migrating into new contrib is someone willing to do > the work of moving, and, subsequently, maintaining. > > This processes is emphatically not about deprecating the contrib libs, nor > pushing anything out. We had to work out the kinks in the new build/deploy > method, and that was done first for: > > Some brand new libs (e.g. unify, nrepl and finger trees) > Some of the most common others, as need arose and time permitted for the > core team. > > We *are* deprecating the old build process and packaging, but I would hope > anyone with any interest in any of the other contrib libs would please step > up and move them over. The only ones that will be left behind will be those > that die of neglect or disinterest. > > Stuart Sierra has documented the process here: > > http://dev.clojure.org/display/design/How+to+Create+New+Contrib+Projects > > and I'm sure will be willing to help out anyone with the desire to move a > lib. > > What you should not do is wait for someone else to move your favorite lib. > We've moved the ones we have time to do, and expect the community to do the > rest, with our help. Hello Rich, thanks for the clarification. For sure, my email was a first step towards this direction : find in the general ml whether there is enough interest in he -?> and -?>> macros, before suggesting their migration either to clojure itself, or to a new clojure contrib. It seems to me that they've gotten the minimal community support, so now I'm officially volunteer to help get them out of clojure.contrib.core and into ? > > Special thanks to Stuart Sierra and Chas Emerick, who did a ton of work to > set this up. > > I hope that clarifies things, > > 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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Future of clojure.contrib.core/-?> macro
On 19 Apr 2011, at 03:02, Sean Corfield wrote: On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote: If nothing else is decided collectively, I'll maintain them as private projects on Google Codes or Bitbucket. If they don't end up as part of the new lineup of contrib libraries, would you at least keep them on github.com? I'll try to see if I can manage to migrate to new contrib (I am not exactly looking forward to all those new tools to learn), but otherwise, I use Mercurial rather than git all day, so github is never my first choice. 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: Future of clojure.contrib.core/-?> macro
On 19 Apr 2011, at 02:15, Rich Hickey wrote: The only criterion for migrating into new contrib is someone willing to do the work of moving, and, subsequently, maintaining. OK, thanks for the clarification! Stuart Sierra has documented the process here: http://dev.clojure.org/display/design/How+to+Create+New+Contrib+Projects That looks like a good start, but I suspect that this requires accounts with suitable access rights on both github and Hudson. What you should not do is wait for someone else to move your favorite lib. We've moved the ones we have time to do, and expect the community to do the rest, with our help. That's of course very reasonable. 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: Future of clojure.contrib.core/-?> macro
On Mon, Apr 18, 2011 at 11:25 PM, Konrad Hinsen wrote: > I'll try to see if I can manage to migrate to new contrib (I am not exactly > looking forward to all those new tools to learn) I hadn't needed to deal with maven until I tried to set up clojure.java.jdbc - but that was the only piece I was new to. I'd be happy to help you with the monads library if it moves forward. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Feedback Request
I haven't look nothing but the REAME too, but the project seems promising :) Good work and keep improving it! Alfredo On Apr 19, 3:23 am, Rayne wrote: > I haven't had a chance to look over more than the README, but I was > actually considering writing something like this myself. Before I > progress any further, I must say: thank you so much for doing this so > that I don't have to. > > On Apr 18, 5:57 pm, Dave Ray wrote: > > > > > > > > > Hi, > > > For the last few weeks, I've been working on a Clojure Swing wrapper > > called Seesaw. I've learned a lot about Clojure so far, but I think > > it's time to ask for some feedback. If I wait 'til it's perfect or > > complete, ... well, then no one would ever hear from me. The code can > > be found on github here: > > > https://github.com/daveray/seesaw > > > I guess I'm looking for two kinds of feedback: > > > 1) Is something like this useful or interesting to anybody? As someone > > who spends a lot of time programming Swing, it's useful to me, but if > > some tweaks or changes would help others, I'd like to know. > > > 2) How bad am I abusing Clojure and what could I do to improve it? > > It's not particularly functional, but I'm currently using Swing's > > insanely imperative style as an excuse for that. > > > Thanks! > > > Dave -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Future of clojure.contrib.core/-?> macro
On 19 April 2011 08:25, Konrad Hinsen wrote: > On 19 Apr 2011, at 03:02, Sean Corfield wrote: > >>> On Apr 18, 2011, at 2:49 PM, Konrad Hinsen wrote: If nothing else is decided collectively, I'll maintain them as private projects on Google Codes or Bitbucket. >> >> If they don't end up as part of the new lineup of contrib libraries, >> would you at least keep them on github.com? > > I'll try to see if I can manage to migrate to new contrib (I am not exactly > looking forward to all those new tools to learn), but otherwise, I use > Mercurial rather than git all day, so github is never my first choice. There is a git plugin for Mercurial (that I've only used to migrate an old Mercurial repository to git). It is supposed to allow hg to talk to a remote git repository as if it were Mercurial and it seems to work well. The only possible issue is that it puts a bit of metadata in some of the log messages, but maybe that's not an issue and maybe it's possible to turn it off if it is an issue. -- Michael Wood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
