Re: Clojure Literature
I started clojure right at the point where contrib changed. I think I had a lot less problems than did many who had already started and were use to the old setup. I didn't mention the contrib change because it was long before the dates the OP was talking about, because none of the books I mentioned (except 1st editonn of Stuart's book) are based on anything pre 1.3 and because while the change to how contrib was structured may cause some little confusion, it is not a change in the language. All the core language constructs and basic concepts are the same. Of course, anyone who is using a book where it states it was written against an earlier version of the language than the current version they are using would be wise to check the release notes and summary of what has changed in the versions between the one the book used and the one they are using. Doesn't do any real harm to force some early problem solving anyway - certainly helps cement your knowledge and understanding. What would be a shame is to dismiss an otherwise good text simply because it was written for an older version. Imagine a C programmer not reading KR simply because it was written for an old version of C@ Tim On Saturday, January 19, 2013 1:46:14 AM UTC+11, Reginald Choudari wrote: I am looking for a new Clojure book to get me started on the language. I've been doing some clojure-koans and reading up on web-development with Clojure and am interested to get down to the knitty-gritty... From what I've seen, it looks like the latest Clojure books are from around March/April 2012. Seeing that Clojure is a changing language, I didn't want to buy a book that would quickly become obsolete. From all that I read, this page seemed to be the most comprehensive description of the current state of Clojure literature: http://stackoverflow.com/questions/2578837/comparing-clojure-books I'd like to hear if anyone has any recommendations or if there is news of any upcoming books coming out that might be worth waiting for. Thanks, Reginald -- 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: a question about running embedded jetty
https://github.com/ring-clojure/ring/wiki/Interactive-Development Ensure that: - Your Ring adapter is running in a background thread so it doesn't block your REPL. - Your handler function is wrapped in a var, so it will be updated when you reload the namespace. aha ... handler functions ... wrapped in a var ... are updated when you reload the namespace hmm ... i will study source of ring/run-jetty to get it. sorry for the noise. -- 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: a question about running embedded jetty
On Sat, Jan 19, 2013 at 5:24 AM, faenvie fanny.aen...@gmx.de wrote:
i have learned that for a ring/compojure-app the embedded jetty
service can be started like this:
(def app (handler/site routes))
(defn start [port]
(ring/run-jetty (var app) {:port (or port 8080)
:join? false}))
can anyone explain, what is the var for ? why '(var app)' or #'app ?
i found some remarks about being able to change the app without
having to restart the server but how exactly does this relate ?
If you pass in the app as it is, then the var gets evaluated to the
function that the var refers to and the jetty adapter uses that
function to run the server.
Now if you recompile your ring handlers (aka functions) the same app
var will get rebound to a new function while the jetty server will
continue holding on to the old handler function, so if you refresh the
page, etc. you won't see the change on your browser. You will have to
kill the server and restart jetty.
If you pass just the var instead, jetty holds on to the container (the
var) and not the value. The jetty-adapter derefs the var on every
request and sends the response back. As a result if you recompile your
handlers you'll see the effects immediately without restarting the
server.
The derefing has a penalty, albeit minor. Thus, you may choose to not
pass in the app as a var in production deployments.
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: [ANN] Schejulure 0.1.1
There is no need to wrap the Executor Service in a* delay* because it already implements lazy-start semantics. From the *ThreadPoolExecutor* Javadoc: On-demand constructionBy default, even core threads are initially created and started only when new tasks arrive, but this can be overridden dynamically using methodprestartCoreThread()http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#prestartCoreThread() or prestartAllCoreThreads()http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#prestartAllCoreThreads(). You probably want to prestart threads if you construct the pool with a non-empty queue. Also, if you constrain the design to a singleton scheduled thread pool, there is no pressing need to shut it down after all schedules are cancelled: a total of a few idle threads is deemed acceptable, especially because scheduling is either needed for the entire runtime, or not needed at all. The major issue were the abandoned schedulers, which you have solved. A more pressing concern is the size of the thread pool: with just one thread, only one task can run at a time. In practice many tasks are very short-lived and a single thread can take care of dozens of them, but some are quite long-lived, going for 10 minutes and more. Combining such tasks with the short-lived ones will result in the short-lived tasks executing on a very irregular schedule. This leads towards a configurable stateful implementation, which is against the first goal of your design. Regrettably, no obvious solutions come to mind. On Saturday, January 19, 2013 1:00:26 AM UTC+1, Adam Clements wrote: Hi Marko, I've addressed some of your concerns by re-using a single thread pool for multiple schedule calls in the current master. The original use case was one set of scheduled tasks running for the lifetime of my application. If you can suggest improvements to cover other use cases with more stopping/starting scheduled tasks and automatically cleaning up the executor service if it's no longer needed that would be great. Adam Clements On Fri, Jan 18, 2013 at 9:50 PM, Marko Topolnik marko.t...@gmail.comjavascript: wrote: This looks great. I was building a couple of applications that run periodic tasks/services on top of quartzite, but I'll definitely play with this. Much nicer scheduling syntax, and the lack of a single stateful scheduler feels much more Clojurian (and cleaner, too). Behind the apparent elegance is a design that could be wasteful with system resources, starting another thread with each invocation of * schedule* and leaving the executor service running after the future is cancelled. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To 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: a question about running embedded jetty
very helpful answer. thank you Baishampayan.
On Saturday, January 19, 2013 10:26:06 AM UTC+1, Baishampayan Ghose wrote:
On Sat, Jan 19, 2013 at 5:24 AM, faenvie fanny@gmx.de javascript:
wrote:
i have learned that for a ring/compojure-app the embedded jetty
service can be started like this:
(def app (handler/site routes))
(defn start [port]
(ring/run-jetty (var app) {:port (or port 8080)
:join? false}))
can anyone explain, what is the var for ? why '(var app)' or #'app ?
i found some remarks about being able to change the app without
having to restart the server but how exactly does this relate ?
If you pass in the app as it is, then the var gets evaluated to the
function that the var refers to and the jetty adapter uses that
function to run the server.
Now if you recompile your ring handlers (aka functions) the same app
var will get rebound to a new function while the jetty server will
continue holding on to the old handler function, so if you refresh the
page, etc. you won't see the change on your browser. You will have to
kill the server and restart jetty.
If you pass just the var instead, jetty holds on to the container (the
var) and not the value. The jetty-adapter derefs the var on every
request and sends the response back. As a result if you recompile your
handlers you'll see the effects immediately without restarting the
server.
The derefing has a penalty, albeit minor. Thus, you may choose to not
pass in the app as a var in production deployments.
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ClojureScript + Jayq Resulting in Error
You need to use a more recent clojurescript version (you are missing
clj-js from cljs.core).
see
https://github.com/ibdknox/jayq/blob/master/CHANGELOG.md#200-breaking-changes
On Saturday, January 19, 2013 4:02:29 AM UTC+1, Ari wrote:
I also noticed that when I compile the cljs code I get:
WARNING: Use of undeclared Var jayq.core/clj-js
On Friday, January 18, 2013 9:56:22 PM UTC-5, Ari wrote:
Hi,
Below is the project.clj -- anything stand out? Thanks for the help.
(defproject sample 0.1.0-SNAPSHOT
:description Practice Clojure/Clojurescript app
:url
:license {:name Eclipse Public License
:url http://www.eclipse.org/legal/epl-v10.html}
:source-paths [src/clj]
:dependencies [[org.clojure/clojure 1.4.0]
[org.clojure/data.xml 0.0.7]
[org.clojure/data.json 0.2.0]
[org.clojure/clojurescript 0.0-1450]
[compojure 1.1.3]
[enlive 1.0.1]
[com.cemerick/friend 0.1.3]
[jayq 2.0.0]
[crate 0.2.3]
[waltz 0.1.0-alpha1]
[com.novemberain/monger 1.4.1]]
:plugins [[lein-ring 0.7.5]
[lein-cljsbuild 0.2.9]]
:cljsbuild {:builds [{:source-path src/cljs
:compiler {:output-to
resources/public/javascripts/app.js :optimizations :whitespace
:pretty-print true}}]
:repl-listen-port 3000
:repl-launch-commands {firefox [firefox :stdout
stdout.log :stderr stderr.log]}}
:ring {:handler sample.routes/app})
On Friday, January 18, 2013 6:48:31 PM UTC-5, Ilia Ablamonov wrote:
Hello Ari,
I've tried to reproduce your case and it works for me. I use the
following project.clj:
(defproject playground 0.1.0
:dependencies [[jayq 2.0.0]]
:min-lein-version 2.0.0
:source-paths [src]
:plugins [[lein-cljsbuild 0.2.10]]
:cljsbuild {:builds
[{:source-path src
:compiler {:output-to public/app.js
:pretty-print true
:optimizations :whitespace}}]})
Maybe something in your project.clj makes difference. Could you plz list
it?
суббота, 19 января 2013 г., 2:43:43 UTC+4 пользователь Ari написал:
The error message was cutoff in my previous post; the error returned is:
Uncaught TypeError: Cannot call method 'call' of undefined
jQuery.ajaxSetup(jayq.core.clj__GT_js.call(null,
cljs.core.ObjMap.fromObject([\ufdd0'accepts, \ufdd0'contents,
\ufdd0'converters],
{\ufdd0'accepts:cljs.core.ObjMap.fromObject([\ufdd0'edn,
\ufdd0'clojure], {\ufdd0'edn:application/edn, text/edn,
\ufdd0'clojure:application/clojure, text/clojure}),
\ufdd0'contents:cljs.core.ObjMap.fromObject([clojure],
{clojure:/edn|clojure/}),
\ufdd0'converters:cljs.core.ObjMap.fromObject([text edn, text
clojure], {text edn:jayq.core.mimetype_converter,
Uncaught TypeError: Cannot call method 'call' of undefined
On Friday, January 18, 2013 3:48:16 PM UTC-5, Ari wrote:
Hi,
When I use the jayq https://github.com/ibdknox/jayq library to wait
until the page loads (see following code) I get the error below. If I
remove jayq, the code executes correctly. Does anyone know what I'm doing
wrong? Thanks.
Html:
!DOCTYPE html
html
head/head
body
script type=text/javascript src=
https://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js
/script
script type=text/javascriptvar CLOSURE_NO_DEPS = true;/script
script type=text/javascript src=javascripts/app.js/script
/body
/html
Clojurescript:
(ns myapp.example
(:use [jayq.core :only [$]])
(:use-macros [jayq.macros :only [ready]]))
(ready (js/alert Hello))
Error:
jQuery.ajaxSetup(jayq.core.clj__GT_js.call...
-Ari
--
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: [ANN] Schejulure 0.1.1
Ah, thanks for the tip. I have now released 0.1.2 which is unchanged apart from this fix (not leaking ExecutorServices) and improved documentation. For the single threaded point, I have added in to the documentation that tasks with a non-trivial running time should fire futures in order to avoid affecting subsequent scheduled tasks, which I think is a reasonable restriction to make given the resulting simplicity. Thanks again for the useful feedback. Adam On 19 Jan 2013 09:53, Marko Topolnik marko.topol...@gmail.com wrote: There is no need to wrap the Executor Service in a* delay* because it already implements lazy-start semantics. From the *ThreadPoolExecutor* Javadoc: On-demand constructionBy default, even core threads are initially created and started only when new tasks arrive, but this can be overridden dynamically using methodprestartCoreThread()http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#prestartCoreThread() or prestartAllCoreThreads()http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#prestartAllCoreThreads(). You probably want to prestart threads if you construct the pool with a non-empty queue. Also, if you constrain the design to a singleton scheduled thread pool, there is no pressing need to shut it down after all schedules are cancelled: a total of a few idle threads is deemed acceptable, especially because scheduling is either needed for the entire runtime, or not needed at all. The major issue were the abandoned schedulers, which you have solved. A more pressing concern is the size of the thread pool: with just one thread, only one task can run at a time. In practice many tasks are very short-lived and a single thread can take care of dozens of them, but some are quite long-lived, going for 10 minutes and more. Combining such tasks with the short-lived ones will result in the short-lived tasks executing on a very irregular schedule. This leads towards a configurable stateful implementation, which is against the first goal of your design. Regrettably, no obvious solutions come to mind. On Saturday, January 19, 2013 1:00:26 AM UTC+1, Adam Clements wrote: Hi Marko, I've addressed some of your concerns by re-using a single thread pool for multiple schedule calls in the current master. The original use case was one set of scheduled tasks running for the lifetime of my application. If you can suggest improvements to cover other use cases with more stopping/starting scheduled tasks and automatically cleaning up the executor service if it's no longer needed that would be great. Adam Clements On Fri, Jan 18, 2013 at 9:50 PM, Marko Topolnik marko.t...@gmail.comwrote: This looks great. I was building a couple of applications that run periodic tasks/services on top of quartzite, but I'll definitely play with this. Much nicer scheduling syntax, and the lack of a single stateful scheduler feels much more Clojurian (and cleaner, too). Behind the apparent elegance is a design that could be wasteful with system resources, starting another thread with each invocation of * schedule* and leaving the executor service running after the future is cancelled. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Schejulure 0.1.1
For the single threaded point, I have added in to the documentation that tasks with a non-trivial running time should fire futures in order to avoid affecting subsequent scheduled tasks, which I think is a reasonable restriction to make given the resulting simplicity. I agree, this is a great decision. It allows your library to keep the focus on rendering its key value-adding service without involving separate concerns that are easily managed by the client side. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Get digits of a number
(defn num-digits [num] (loop [n num res []] (if (zero? n) res (recur (long (/ n 10)) (cons (mod n 10) res) 在 2011年2月17日星期四UTC+8下午1时29分10秒，Andreas Kostler写道： Is there an easy and idiomatic way of getting the digits of a number in clojure? (defn explode-to-digits [number] (map #(- (int %) (int \0)) (str number))) (explode-to-digits 123456) = (1 2 3 4 5 6) Seems a bit clunky... Andreas -- 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
11th modern-cljs tutorial on clojurescript
Hi all, here is the latest modern-cljs tutorial on clojurescript. It talks a little biro more about dom event and domina library. HIH, best mimmo https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-11.md -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Literature
Hi, wherever you start from (all the cited books are from good to very good), I think that one day you could take you're time to read a couple amazing books. SICP: http://mitpress.mit.edu/sicp/ and Onlisp: http://www.paulgraham.com/onlisp.html I studied the first one (written for scheme) almost 30 years ago, but its still the book for any serious programmer. The second one (written for CommonLisp) is very, really very amazing if you want to be serious with macros. That said I'm still waiting for a very good book about co-recursion in clojure (or whatever functional programming). If someone has advice for that, I'll appreciate. Mimmo On Friday, January 18, 2013 3:46:14 PM UTC+1, Reginald Choudari wrote: I am looking for a new Clojure book to get me started on the language. I've been doing some clojure-koans and reading up on web-development with Clojure and am interested to get down to the knitty-gritty... From what I've seen, it looks like the latest Clojure books are from around March/April 2012. Seeing that Clojure is a changing language, I didn't want to buy a book that would quickly become obsolete. From all that I read, this page seemed to be the most comprehensive description of the current state of Clojure literature: http://stackoverflow.com/questions/2578837/comparing-clojure-books I'd like to hear if anyone has any recommendations or if there is news of any upcoming books coming out that might be worth waiting for. Thanks, Reginald -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Literature
your* bG9sLCBzb3JyeS4gSSB0aG91Z2h0IGl0IHdhcyBmdW5ueSBtZS1jb3JyZWN0aW5nLXlvdSBhdCB0aGlzIHBvaW50IGFuZCBzZWVtaW5nIGFsbCBzZXJpb3VzOykgSSBob3BlIHlvdSBzbWlsZWQgYmVmb3JlIHJlYWRpbmcgdGhpcw== On Sat, Jan 19, 2013 at 5:33 PM, Mimmo Cosenza mimmo.cose...@gmail.comwrote: Hi, wherever you start from (all the cited books are from good to very good), I think that one day you could take you're time to read a couple amazing books. SICP: http://mitpress.mit.edu/sicp/ and Onlisp: http://www.paulgraham.com/onlisp.html I studied the first one (written for scheme) almost 30 years ago, but its still the book for any serious programmer. The second one (written for CommonLisp) is very, really very amazing if you want to be serious with macros. That said I'm still waiting for a very good book about co-recursion in clojure (or whatever functional programming). If someone has advice for that, I'll appreciate. Mimmo On Friday, January 18, 2013 3:46:14 PM UTC+1, Reginald Choudari wrote: I am looking for a new Clojure book to get me started on the language. I've been doing some clojure-koans and reading up on web-development with Clojure and am interested to get down to the knitty-gritty... From what I've seen, it looks like the latest Clojure books are from around March/April 2012. Seeing that Clojure is a changing language, I didn't want to buy a book that would quickly become obsolete. From all that I read, this page seemed to be the most comprehensive description of the current state of Clojure literature: http://** stackoverflow.com/questions/**2578837/comparing-clojure-**bookshttp://stackoverflow.com/questions/2578837/comparing-clojure-books I'd like to hear if anyone has any recommendations or if there is news of any upcoming books coming out that might be worth waiting for. Thanks, Reginald -- 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 -- I may be wrong or incomplete. Please express any corrections / additions, they are encouraged and appreciated. At least one entity is bound to be transformed if you do ;) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Literature
On Jan 19, 2013, at 9:33 AM, Mimmo Cosenza mimmo.cose...@gmail.com wrote: Hi, wherever you start from (all the cited books are from good to very good), I think that one day you could take you're time to read a couple amazing books. SICP: http://mitpress.mit.edu/sicp/ SiCP also available as epub from https://github.com/ieure/sicp and pdf from http://sicpebook.wordpress.com/ -- Charlie Griefer http://charlie.griefer.com Give light, and the darkness will disappear of itself. -- Desiderius Erasmus -- 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) function return results
I am struggling to understand what Clojure is doing. This is definitely a
newbie question but I cannot figure it out :). The question is best asked
via a repl session:
[code]user= (defn create-user [] {:id 1})
#'user/create-user
user= (create-user)
{:id 1}
user= (take 10 (repeatedly create-user))
({:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1}
{:id 1})
user= (defn stream1 [] repeatedly create-user)
#'user/stream1
user= (take 10 stream1)
IllegalArgumentException Don't know how to create ISeq from: user$stream1
clojure.lang.RT.seqFrom (RT.java:494)
user= (take 10 (stream1))
IllegalArgumentException Don't know how to create ISeq from:
user$create_user clojure.lang.RT.seqFrom (RT.java:494)
user= (defn stream2 [] (repeatedly create-user))
#'user/stream2
user= (take 10 stream2)
IllegalArgumentException Don't know how to create ISeq from: user$stream2
clojure.lang.RT.seqFrom (RT.java:494)
user= (take 10 (stream2))
({:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1}
{:id 1})
[/code]
My question is two parted - what is the different between stream1 and
stream2 - what exactly do they return. And, based on that, why doesn't
(stream1) return a sequence. In other words, what effect does wrapping the
function body in quotes actually do?
I know I will kick myself when I get the answer, so please feel free to
cause me to receive a good kicking ;).
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
[ANN] clj-squash 0.1.0
Hi, I did some work to enable Clojure applications to use Squash, an exception reporting and bug analysis tool recently released by Square (see http://www.square.io). This resulted in clj-squash (apologies for the lack of fantasy), which I think is now usable enough to warrant an offical 0.1.0 release in the hope that others might find it useful. A release has been pushed to Clojars, and the code is available at: https://github.com/ragnard/clj-squash Feedback and/or contributions are most welcome and appreciated. Best regards, Ragnar Dahlén -- 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: Is contributing to clojurescript is intentionally made hard ?
For what it's worth, I've submitted 20+ patches to ClojureScript and one or two to Clojure proper. I still find the process to be extremely unpleasant. I consistently avoid interacting with JIRA until the last possible minute: That software is actively user-hostile. Without naming names, I've spoken with a half dozen other active contributors who feel the same way. If I wasn't between jobs at the time, I'd never have made it over the hump towards being a contributor. On Friday, January 18, 2013 1:01:52 PM UTC-8, Irakli Gozalishvili wrote: I have being trying to engage community and to contribute to clojurescript for a while already, but so far it's being mostly frustrating and difficult. I hope to start discussion here and maybe get some constructive outcome. ## Rationale I'm primarily interested in clojurescript and not at all in clojure, because of specific reasons (that I'll skip since their irrelevant for this discussion) dependency on JVM is a problem. Removing that's dependency is also my primary motivation to contribute. ## Problems - I do understand that most of the clojurescript audience is probably also interested in clojure, but please don't enforce that. Have a separate mailing list so that people interested in clojurescript and not clojure could follow relevant discussions without manually filtering out threads. - What is the point of being on github if you don't accept pull requests and require I do understand that there maybe specific reasons why jira flow was chosen, but seriously that's another ball thrown at potential contributor to joggle. Not to mention that there are several options how jira and github could be integrated. - My latest attempt was to configure travis.ci for integration tests https://github.com/clojure/clojurescript/pull/21 Integration tests are great specially because they run on every pull request and post details back into pull requests. This also means that lot of local test run time can be saved. Not to mention that for clojurescript tests you need JVM, v8, spidermonkey and more… If these things are intentionally made hard to stop new people with more clojurescipt interests then please make it more clear, cause otherwise it just a motivation killer. Thanks -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ANN ide-files--Leiningen template to generate IDE files for existing projects
Hi, I am happy to announce `ide-files` (version 0.1.0), a Leiningen template for generating Eclipse and IDEA files for existing Clojure projects. Leiningen issue #933[1] was the primary motivation. You can find the template here: https://github.com/kumarshantanu/ide-files Currently the template generates somewhat fixed content without looking at `project.clj`, something that you can easily fix after opening the project in the IDE. In a future version the template would generate IDE files based on `project.clj` content. I will appreciate feedback, ideas and contribution. [1] https://github.com/technomancy/leiningen/issues/933 Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (newbie) function return results
On Sat, Jan 19, 2013 at 11:32 PM, Colin Yates colin.ya...@gmail.com wrote:
I am struggling to understand what Clojure is doing. This is definitely a
newbie question but I cannot figure it out :). The question is best asked
via a repl session:
[code]user= (defn create-user [] {:id 1})
#'user/create-user
user= (create-user)
{:id 1}
user= (take 10 (repeatedly create-user))
({:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1}
{:id 1})
user= (defn stream1 [] repeatedly create-user)
#'user/stream1
user= (take 10 stream1)
IllegalArgumentException Don't know how to create ISeq from: user$stream1
clojure.lang.RT.seqFrom (RT.java:494)
user= (take 10 (stream1))
IllegalArgumentException Don't know how to create ISeq from:
user$create_user clojure.lang.RT.seqFrom (RT.java:494)
The mistake is in the body of stream1. You should have wrapped
`repeatedly ceate-user` in parenthesis, otherwise the return value of
stream1 is the function `create-user`.
You'd want to fix the code like this -
(defn stream1 []
(repeatedly create-user))
And then, you should call get some users from the stream like this -
(take 10 (stream1))
You need to call stream1 like a function because otherwise it'd mean
`take`-ing things from a function which doesn't make any sense.
If you really want to deal with a stream directly and not call a
function, you can bind the stream in a var directly -
(def stream (repeatedly create-user))
`repeatedly` returns a lazy sequence so dealing with an infinite
sequence is not a problem. Mind you, you're holding on to the head
here, so you are still prone to facing stackoverflow errors if you
`def` an infinite sequence.
user= (defn stream2 [] (repeatedly create-user))
#'user/stream2
user= (take 10 stream2)
IllegalArgumentException Don't know how to create ISeq from: user$stream2
clojure.lang.RT.seqFrom (RT.java:494)
user= (take 10 (stream2))
({:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1} {:id 1}
{:id 1})
[/code]
My question is two parted - what is the different between stream1 and
stream2 - what exactly do they return. And, based on that, why doesn't
(stream1) return a sequence. In other words, what effect does wrapping the
function body in quotes actually do?
`stream1` returns just the function `create-user` when invoked.
`stream2` return an infinite lazy-sequence of the results of calling
`create-user` repeatedly.
Hope that helps.
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: (newbie) function return results
On Sat, Jan 19, 2013 at 7:02 PM, Colin Yates colin.ya...@gmail.com wrote:
user= (defn stream1 [] repeatedly create-user)
This function invokes neither repeatedly nor create-user. It pointlessly
refers to repeatedly and then returns a reference to the create-user
function.
Which is function and not a sequence, which is why you cannot take n from
it.
user= (defn stream2 [] (repeatedly create-user))
This function invokes repeatedly with a reference to create-user and
returns a lazy-sequence, which you can take n from.
In other words, what effect does wrapping the function body in quotes
actually do?
By quotes I assume you mean ()'s. The answer is above. in stream1 you are
simply refering to functions. Without the ()'s
you're not invoking anything.
Compare:
user create-user
#user$create_user user$create_user@3f8ecde
to:
user (create-user)
{:id 1}
user
/S
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Is contributing to clojurescript is intentionally made hard ?
On Friday, 2013-01-18 at 18:03 , Sean Corfield wrote: Because by submitting a JIRA patch explicitly, you are taking the legal responsibility for the contents of the patch as being a change that you are authorized to submit under the CA... You can in fact do similar with contributing guidelines that are displayed once pull requests is created: https://github.com/blog/1184-contributing-guidelines And just reject pulls from people who did not signed CA I'm not sure that you can even attach a patch to a Clojure ticket in JIRA without being given permission to modify tickets (which means you have a CA on file)? Yes I did signed CA and it's always possible to not merge pull requests from people who have not signed CA yet. As you say, at Mozilla, you have a whole team of legal people making sure things are safe and acceptable. Clojure/core does not have that luxury. Maybe I was not clear here but legal people do not go through each pull request only signers do merges people sending pull requests. I also have contributed to several other projects that required signing CA before taking any of my pull requests, so I really don't see why it's a problem for clojure. On Fri, Jan 18, 2013 at 5:16 PM, Irakli Gozalishvili rfo...@gmail.com (mailto:rfo...@gmail.com) wrote: One could also copy attach patch with lines that belong to someone else. How is that different ? Pull requests are just a tool for working with patches nothing else Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Friday, 2013-01-18 at 16:18 , Sean Corfield wrote: That will depend on whether it traces the origin of each line in the patch - just relying on the pull request originator is not sufficient (unfortunately). On Fri, Jan 18, 2013 at 4:11 PM, Hugo Duncan duncan.h...@gmail.com (mailto:duncan.h...@gmail.com) wrote: Sean Corfield seancorfi...@gmail.com (mailto:seancorfi...@gmail.com) writes: My understanding is that with pull requests it becomes much harder to provide accountability for Intellectual Property which is a legal concern, and that's why we have a Contributor's Agreement. I wonder if the availability of http://www.clahub.com/ changes anything... Hugo -- 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 (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com) For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com (mailto: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 (mailto: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 (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com) For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com (mailto: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 (mailto: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
Re: (newbie) function return results
Thanks both - (and yes I did mean brackets - oops).
On 19 Jan 2013, at 18:26, Sven Johansson johansson.s...@gmail.com wrote:
On Sat, Jan 19, 2013 at 7:02 PM, Colin Yates colin.ya...@gmail.com wrote:
user= (defn stream1 [] repeatedly create-user)
This function invokes neither repeatedly nor create-user. It pointlessly
refers to repeatedly and then returns a reference to the create-user function.
Which is function and not a sequence, which is why you cannot take n from it.
user= (defn stream2 [] (repeatedly create-user))
This function invokes repeatedly with a reference to create-user and returns
a lazy-sequence, which you can take n from.
In other words, what effect does wrapping the function body in quotes
actually do?
By quotes I assume you mean ()'s. The answer is above. in stream1 you are
simply refering to functions. Without the ()'s
you're not invoking anything.
Compare:
user create-user
#user$create_user user$create_user@3f8ecde
to:
user (create-user)
{:id 1}
user
/S
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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: Get digits of a number
Qiu Xiafei qiuxia...@gmail.com writes: (defn num-digits [num] (loop [n num res []] (if (zero? n) res (recur (long (/ n 10)) (cons (mod n 10) res) How about (quot n 10) instead of (long (/ n 10))? No sense in the extra step. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is contributing to clojurescript is intentionally made hard ?
As a matter of fact I have abandoned clojurescript once before and just wrote my own implementation of JVM free clojurescript subset: https://github.com/Gozala/wisp http://jeditoolkit.com/wisp/ But kanaka's clojurescript in clojurescript https://github.com/kanaka/clojurescript/ got me excited and I'm trying to get involved again. Luckily he's being awesome to work with has no problems accepting pull requests. But if the process of contributing is more work than I can keep up with I'll have to turn away again :( I also don't quite see the point of being on github if use of it's features is unacceptable. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 10:03 , Brandon Bloom wrote: For what it's worth, I've submitted 20+ patches to ClojureScript and one or two to Clojure proper. I still find the process to be extremely unpleasant. I consistently avoid interacting with JIRA until the last possible minute: That software is actively user-hostile. Without naming names, I've spoken with a half dozen other active contributors who feel the same way. If I wasn't between jobs at the time, I'd never have made it over the hump towards being a contributor. On Friday, January 18, 2013 1:01:52 PM UTC-8, Irakli Gozalishvili wrote: I have being trying to engage community and to contribute to clojurescript for a while already, but so far it's being mostly frustrating and difficult. I hope to start discussion here and maybe get some constructive outcome. ## Rationale I'm primarily interested in clojurescript and not at all in clojure, because of specific reasons (that I'll skip since their irrelevant for this discussion) dependency on JVM is a problem. Removing that's dependency is also my primary motivation to contribute. ## Problems - I do understand that most of the clojurescript audience is probably also interested in clojure, but please don't enforce that. Have a separate mailing list so that people interested in clojurescript and not clojure could follow relevant discussions without manually filtering out threads. - What is the point of being on github if you don't accept pull requests and require I do understand that there maybe specific reasons why jira flow was chosen, but seriously that's another ball thrown at potential contributor to joggle. Not to mention that there are several options how jira and github could be integrated. - My latest attempt was to configure travis.ci (http://travis.ci) for integration tests https://github.com/clojure/clojurescript/pull/21 Integration tests are great specially because they run on every pull request and post details back into pull requests. This also means that lot of local test run time can be saved. Not to mention that for clojurescript tests you need JVM, v8, spidermonkey and more… If these things are intentionally made hard to stop new people with more clojurescipt interests then please make it more clear, cause otherwise it just a motivation killer. Thanks -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com (mailto: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 (mailto: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: Is contributing to clojurescript is intentionally made hard ?
BTW also as hugo pointed out with http://www.clahub.com/ one could just reject pull requests if any of the commit included is from author who have not signed CLA yet. So looks like CLA problem can be also easily solved. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Friday, 2013-01-18 at 18:03 , Sean Corfield wrote: Because by submitting a JIRA patch explicitly, you are taking the legal responsibility for the contents of the patch as being a change that you are authorized to submit under the CA... I'm not sure that you can even attach a patch to a Clojure ticket in JIRA without being given permission to modify tickets (which means you have a CA on file)? As you say, at Mozilla, you have a whole team of legal people making sure things are safe and acceptable. Clojure/core does not have that luxury. On Fri, Jan 18, 2013 at 5:16 PM, Irakli Gozalishvili rfo...@gmail.com (mailto:rfo...@gmail.com) wrote: One could also copy attach patch with lines that belong to someone else. How is that different ? Pull requests are just a tool for working with patches nothing else Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Friday, 2013-01-18 at 16:18 , Sean Corfield wrote: That will depend on whether it traces the origin of each line in the patch - just relying on the pull request originator is not sufficient (unfortunately). On Fri, Jan 18, 2013 at 4:11 PM, Hugo Duncan duncan.h...@gmail.com (mailto:duncan.h...@gmail.com) wrote: Sean Corfield seancorfi...@gmail.com (mailto:seancorfi...@gmail.com) writes: My understanding is that with pull requests it becomes much harder to provide accountability for Intellectual Property which is a legal concern, and that's why we have a Contributor's Agreement. I wonder if the availability of http://www.clahub.com/ changes anything... Hugo -- 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 (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com) For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com (mailto: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 (mailto: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 (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com) For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com (mailto: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 (mailto: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: Clojure Literature
I wouldn't worry too much about differences because a book was written for clojure 1.2 or 1.3 even though 1.5 is only just around the corner. The differences are minor and tend to be most directly related to more advanced topics that are unlikely to be of critical importance to begin with. Once you have covered the content in these books, you will pick up the minor differences in later versions easily enough. The changes that happened between 1.0 and 1.3 are not just in the language---they are quite a bit in how the language is being *approached. *For example, in the old days the number-one subject everywhere was the Clojure STM and refs. Halloway's book doesn't even feature atoms, if I remember correctly, or at least it downplays them, pushing refs into the spotlight. Today it is pretty much accepted that atoms and agents are very useful and refs and the STM plays a side-role. In my personal experience, for quite a long time I had lived with some sort of guilty feeling about the fact that I never ended up using refs; even if I did use them, the usage was kind of trivial, I felt I was doing something wrong. It took me a while to grow confidence that it's not me---it's the STM. Not that it is broken in any way, it's just that the use cases where it brings value are vanishingly rare. Newer books that speak from more years of living and breathing Clojure contain many nuggets of wisdom such as this, this is why they are important for a beginner. -- 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: Associative extends Seqable?
On Fri, Jan 18, 2013 at 10:31 PM, Stephen Compall
stephen.comp...@gmail.com wrote:
First, I have a suggestion for your associative: make `seq' return (map
vector (iterate inc' 0) (constantly the-const-value)). This would be a
correct result, as far as it's possible to observe.
True, but it would break this proposed law:
anAssociative.entryAt(k) returning entry E,
implies that (seq anAssociative) contains E.
You couldn't observe the breakage, but it would still the case that
for many elements of the domain no finite subsequence of the seq
contains those elements.
[(x,y) | x - [0..], y - [0..]] correctly produces all the pairs of
the integers as far as it's possible to observe, but it's still less
correct than a diagonal procedure.
There are other ways to make trouble anyway: it's perfectly possible
to define infinite sets that support conjoining, disjoining, union,
intersection, difference, etc., whether in forms that also support
seq-ing, e.g. sets of multiples of a given integer, or not (or not
obviously to me), in terms of an arbitrary characteristic
function---these not necessarily being infinite, I suppose. But sets
are also counted (twice over, once by extending Counted and once by
extending IPersistentCollection).
On Fri, 2013-01-18 at 16:16 -0800, Ben Wolfson wrote:
It may seem less odd if, instead of I can enumerate my contents, you
take the implication as I can transform my domain forwards.
In ordinary functions, the domain can be transformed, but the
transformer function can't go olddomain - newdomain; it has to go
newdomain - olddomain. (This also applies to those functions that can,
given a value, report whether that value is defined for the domain,
because such functions simply have a total codomain of a particular
shape.)
Associatives are related to functions in that converting an associative
to a function is an injection, and both have domains and codomains. But
the way you transform the domain of an associative is backwards from how
you must for functions: the transformer function goes olddomain -
newdomain.
I don't really understand this. Surely you can, in fact, transform the
domain of an associative the same way you transform the domain of a
function? You could support the associative interface via a function
from newdomain - olddomain + the old associative. (And if you can go
function - associative, couldn't you just transform the domain of the
associative forwards, then stick a function newdomain - codomain in
front of it, thereby transforming the domain of the initial function?)
Why does this imply enumeration? You can't use the transformer function
on lookups; the lookup keys are in newdomain already. So you must have
applied that transformer to a data representation of the domain first,
so that you have a newdomain search space for the key you're looking up.
You must be able to produce the entire search space during a domain
transform, which implies an enumeration. Once you're enumerating the
domain, you can just apply the associative to produce the codomain, and
thus, enumerate the contents.
I can see why enumeration implies the ability to transform the domain
forward (modulo a question, below), but not why, in every case, the
forward transformation of the domain implies enumeration.
If the domain transformation function is injective and the associative
maps everything to the same value, then transforming the domain
forward is a no-op: there can't be something in the new domain that
wasn't in the old domain at all, since everything was in the old
domain. All we could do is shuffle elements in the domain around with
respect to what they're associated with. But they're all associated
with the same thing. You don't need to enumerate anything in this
case.
If the domain transformation function is not injective, then I get
very nervous about transforming the domain at all.
Given the map {-2 :x 2 :y} and the domain transformation function #(*
% %), what should the result map be? {4 :x}? {4 :y}? Blowup
(tantamount to requiring an injective function in the first place)?
What actually happens in clojure-land is clearly a function of how you
actually implement the transformation:
user= (defn map-keys [f m] (- m (map (fn [[k v]] [(f k) v])) (into {})))
#'user/map-keys
user= (map-keys #(* % %) {-2 :x 2 :y})
{4 :y}
user= (defn map-keys* [f m] (let [ks (set (keys m))] (apply hash-map
(mapcat (juxt f m) ks
#'user/map-keys*
user= (map-keys* #(* % %) {-2 :x 2 :y})
java.lang.IllegalArgumentException: Duplicate key: 4 (NO_SOURCE_FILE:0)
And of course the fact that we got {4 :y} and not {4 :x} in the first
case is a function of the (arbitrary!) ordering of the result of seq.
But in the end my more fundamental question is: what makes it the case
that associatives can transform their domains forward? AFAICT the
answer is the enumerability of associatives. So, in fact, it has not
helped me to look at the relation between enumerability and forward
Re: Is contributing to clojurescript is intentionally made hard ?
On Jan 18, 2013, at 3:52 PM, Sean Corfield wrote: On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut andy.finger...@gmail.com wrote: The issue that Clojure, its contrib libraries, and ClojureScript do not accept github pull requests has been brought up several times before on this email list in the past. Feel free to search the Google group for terms like pull request. Short answer: Rich Hickey prefers a workflow of evaluating patches, not pull requests. It is easier for him. My understanding is that with pull requests it becomes much harder to provide accountability for Intellectual Property which is a legal concern, and that's why we have a Contributor's Agreement. The patch process naturally falls out of the legal CA-covered process since each patch is clearly identified as belonging to a specific contributor - and submitting a patch comes with the responsibility of vouching for the legal status of that submission. Github's pull request process makes it all too easy to incorporate code that belongs to a Github account holder who is not covered by the legal agreement and places the burden of verification on screeners to verify the IP ownership. But let's not re-hash the issue of the CA. Folks can just read the archives and there's really nothing new to add... I won't rehash the issue, but will provide direct pointers to a couple of posts that led me to believe my statements above. Here is a link to the whole thread, with many posts on the then-just-being-started clojure-doc.org web site (which I'm pleased to see has certainly come a long way since early Oct 2012): https://groups.google.com/forum/?fromgroups=#!topic/clojure/jWMaop_eVaQ Scan a down to Jay Fields post from Oct 6 2012, and then to Rich Hickey's response later the same day. I don't have any inside info about Rich's preferences for patches outside of such public messages, but it definitely seems to be due to workflow preference issues, not legal issues. Andy -- 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: Is contributing to clojurescript is intentionally made hard ?
Irakli: I am curious about the possibility of auto-creating patches from git pull requests, in case that would bridge the divide between people that would prefer submitting pull requests, and Clojure screeners that would prefer evaluating patches and JIRA tickets. Causing a new git pull request to to auto-create a JIRA ticket with a patch sounds easy, but that isn't the whole process. What about comments that are later added to the pull request? Are they auto-added as comments to the JIRA ticket? Are comments added to the JIRA ticket auto-added as comments to the pull request? If the JIRA ticket is closed, does that automatically close the github pull request? If the answer to all of the above is yes, already works that way, then I'd be willing to spend a little more time looking into it. Do you have links to any info on the tools that enable such behavior? Thanks, Andy On Jan 18, 2013, at 5:13 PM, Irakli Gozalishvili wrote: At mozilla we also require signing CA but do accept pull requests and there are whole team of legal people that makes sure things like that don't raise any legal concerns. After all it's just .patch to the pull request url gives you an actual change patch so if reviewing patches is desired it's easy to build a tool that attaches it to JIRA. We in fact do that for bugzilla. The good news is that such tools are already written for JIRA so it's just matter of enabling it! -- 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
Proposal: Suppressing tracebacks from clojure.core
Hi all
I've been thinking about how long tracebacks get for pure Clojure errors,
and it would be really nice if we could hide the Java traceback from the
compiler when it's not relevant. When there's no Java interop, it's not
useful. I can't see any case where we want the tracebacks from the compiler
referencing clojure.core.
I threw together a patch -- I'm sure a seasoned Java developer would find a
nicer way to do this.
Here's how the tracebacks look at the moment on trunk:
$ more dodgy-map.clj
(defn dodgy-map []
{:1 :2 :3})
$ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main
dodgy-map.clj
Exception in thread main java.lang.RuntimeException: Map literal must
contain an even number of forms,
compiling:(/home/wilfred/src/clojure/dodgy-map.clj:2:13)
at clojure.lang.Compiler.load(Compiler.java:7069)
at clojure.lang.Compiler.loadFile(Compiler.java:7019)
at clojure.main$load_script.invoke(main.clj:286)
at clojure.main$script_opt.invoke(main.clj:348)
at clojure.main$main$fn__6676.invoke(main.clj:432)
at clojure.main$main.doInvoke(main.clj:429)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.lang.Var.invoke(Var.java:415)
at clojure.lang.AFn.applyToHelper(AFn.java:161)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Map literal must contain an even
number of forms
at clojure.lang.Util.runtimeException(Util.java:219)
at clojure.lang.LispReader$MapReader.invoke(LispReader.java:1090)
at clojure.lang.LispReader.readDelimitedList(LispReader.java:1145)
at clojure.lang.LispReader$ListReader.invoke(LispReader.java:979)
at clojure.lang.LispReader.read(LispReader.java:182)
at clojure.lang.Compiler.load(Compiler.java:7057)
... 10 more
If I change src/jvm/clojure/main.java to:
public static void main(String[] args) {
REQUIRE.invoke(CLOJURE_MAIN);
try {
MAIN.applyTo(RT.seq(args));
} catch (Compiler.CompilerException e) {
System.out.println(e.toString());
}
}
Then my traceback is simplified to:
$ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main
dodgy-map.clj
java.lang.RuntimeException: Map literal must contain an even number of
forms, compiling:(/home/wilfred/src/clojure/dodgy-map.clj:2:13)
This also means that name errors have shorter tracebacks:
$ more i-dont-exist.clj
(defn no-such-variable []
i-dont-exist)
$ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main
i-dont-exist.clj
java.lang.RuntimeException: Unable to resolve symbol: i-dont-exist in this
context, compiling:(/home/wilfred/src/clojure/i-dont-exist.clj:1:1)
Of course, there's huge scope for improvement. The reference to
java.lang.RuntimeException isn't useful. It would be nice to split
CompilerException into more specific exception classes (SyntaxError,
NameError etc) so we can print different errors at the top level. This
simple patch also changes the exit code of the compiler, which is
undesirable. Finally, it'd need some new unit tests.
Anyway, is this something that is worth opening an issue for? I'd love to
hear your thoughts.
Wilfred
--
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: Is contributing to clojurescript is intentionally made hard ?
Irakli Gozalishvili: If these things are intentionally made hard to stop new people with more clojurescipt interests then please make it more clear, cause otherwise it just a motivation killer. Irakli, Over the years, many people have tried raising the question of why contributing to Clojure (and ClojureScript, and anything Clojure/core touches) involves so many obstacles and bureaucracy. Just search the archives. Unfortunately, the answer many folks come up with is: Clojure/core don't see it as a major problem. So, my advice to you: forget about it. Contributing to Clojure[Script] projects that do not involve Clojure CA and the existing process is much more productive. MK -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Literature
Wow, I did not expect the wide range of responses and opinions. A lot of valuable information here for a beginner like myself... Thanks to everyone who contributed.. Reginald On Friday, January 18, 2013 9:46:14 AM UTC-5, Reginald Choudari wrote: I am looking for a new Clojure book to get me started on the language. I've been doing some clojure-koans and reading up on web-development with Clojure and am interested to get down to the knitty-gritty... From what I've seen, it looks like the latest Clojure books are from around March/April 2012. Seeing that Clojure is a changing language, I didn't want to buy a book that would quickly become obsolete. From all that I read, this page seemed to be the most comprehensive description of the current state of Clojure literature: http://stackoverflow.com/questions/2578837/comparing-clojure-books I'd like to hear if anyone has any recommendations or if there is news of any upcoming books coming out that might be worth waiting for. Thanks, Reginald -- 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: Is contributing to clojurescript is intentionally made hard ?
+1 On Saturday, January 19, 2013 11:47:56 PM UTC+4, Andy Fingerhut wrote: On Jan 18, 2013, at 3:52 PM, Sean Corfield wrote: On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut andy.fi...@gmail.com javascript: wrote: The issue that Clojure, its contrib libraries, and ClojureScript do not accept github pull requests has been brought up several times before on this email list in the past. Feel free to search the Google group for terms like pull request. Short answer: Rich Hickey prefers a workflow of evaluating patches, not pull requests. It is easier for him. My understanding is that with pull requests it becomes much harder to provide accountability for Intellectual Property which is a legal concern, and that's why we have a Contributor's Agreement. The patch process naturally falls out of the legal CA-covered process since each patch is clearly identified as belonging to a specific contributor - and submitting a patch comes with the responsibility of vouching for the legal status of that submission. Github's pull request process makes it all too easy to incorporate code that belongs to a Github account holder who is not covered by the legal agreement and places the burden of verification on screeners to verify the IP ownership. But let's not re-hash the issue of the CA. Folks can just read the archives and there's really nothing new to add... I won't rehash the issue, but will provide direct pointers to a couple of posts that led me to believe my statements above. Here is a link to the whole thread, with many posts on the then-just-being-started clojure-doc.org web site (which I'm pleased to see has certainly come a long way since early Oct 2012): https://groups.google.com/forum/?fromgroups=#!topic/clojure/jWMaop_eVaQ Scan a down to Jay Fields post from Oct 6 2012, and then to Rich Hickey's response later the same day. I don't have any inside info about Rich's preferences for patches outside of such public messages, but it definitely seems to be due to workflow preference issues, not legal issues. Andy -- 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: A Working nrepl-ritz Setup?
On Windows, I had to put the profiles.clj in the Windows home directory C:\Users\%user name%\AppData\Roaming, where also .emacs.d reesides (see also https://github.com/pallet/ritz/issues/28#issuecomment-12460118). -fb Am Mittwoch, 5. Dezember 2012 18:24:20 UTC+1 schrieb Hugo Duncan: Timothy Washington twas...@gmail.com javascript: writes: 1) I start from an empty *~/.emacs.d/* 2) I then populate init.el from the example in ritz/nreplhttps://github.com/pallet/ritz/tree/develop/nrepl 3) I open a lein project and run `*M-x nrepl-ritz-jack-in*` **) The error I get back is: *error in process sentinel: Could not start nREPL server: 'ritz-nrepl' is not a task. See 'lein help'.* This is actually a lein message, and it is saying that the lein-ritz plugin is not in the :plugins vector of a lein profile. There is an example of setting this up in ~/.lein/profiles.clj on the page you linked. HTH, Hugo -- 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 to (easily) show the advantages of Clojure
On Wed, Jan 16, 2013 at 4:08 PM, Thomas th.vanderv...@gmail.com wrote: Hi All, Something that came up last night in the blank? thread. What is a good way to show someone the advantages of Clojure. Something that is simple, not too complicated, easily understood, shows a (significant) benefit, etc. Any ideas? (As said in the other thread, I have used the blank? example from Stuart Halloway to show people the difference). Open a connection to a service/database/... and mess around with it (for example a remote db, with a very slow connection initialization). And show how it's easy to experiment when you always have the JVM up and running. Constrast it with Java for example, where when the unit test or the main method is exited, you have to rebuild the context again. Thomas -- 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: Associative extends Seqable?
On Sat, 2013-01-19 at 11:39 -0800, Ben Wolfson wrote: You couldn't observe the breakage, but it would still the case that for many elements of the domain no finite subsequence of the seq contains those elements. Indeed, it would merely be observably correct, not actually correct. What do you return for count, though? There are other ways to make trouble anyway: it's perfectly possible to define infinite sets that support conjoining, disjoining, union, intersection, difference, etc., whether in forms that also support seq-ing, e.g. sets of multiples of a given integer, or not (or not obviously to me), in terms of an arbitrary characteristic function---these not necessarily being infinite, I suppose. Such sets couldn't support forward domain transformation, though, because membership testing could then fail to terminate. I don't really understand this. Surely you can, in fact, transform the domain of an associative the same way you transform the domain of a function? You could support the associative interface via a function from newdomain - olddomain + the old associative. But you couldn't transform that result's domain with a newdomain - newhotnessdomain; it would thus no longer be an associative under the qualification I'm positing. It would be no different from converting to a function, with a peculiarly shaped codomain that modeled domain membership testing, then transforming the domain in the usual way for functions. (And if you can go function - associative But you can't. If the domain transformation function is injective and the associative maps everything to the same value, then transforming the domain forward is a no-op: there can't be something in the new domain that wasn't in the old domain at all, since everything was in the old domain. All we could do is shuffle elements in the domain around with respect to what they're associated with. But they're all associated with the same thing. You don't need to enumerate anything in this case. Yes; this is the case I described as follows: The only way you can apply both transformations is if your domain is vacuous: that is, constant functions like yours are the only ones that permit domain transform in either direction. If the domain transformation function is not injective, then I get very nervous about transforming the domain at all. I would absolutely agree that only injective forward domain transformations are well-defined. But in the end my more fundamental question is: what makes it the case that associatives can transform their domains forward? AFAICT the answer is the enumerability of associatives. My previous email argued that the former implied the latter, rather than vice versa. Forward domain transformation via injection seems more fundamental than enumerability, to me. So, in fact, it has not helped me to look at the relation between enumerability and forward domain transformability, because I no more see why the latter is something that belongs with associating elements of a domain with elements of a codomain than I do the former. Because that definition of associative, associating elements of a domain with elements of a codomain, is entirely characterized by the codomain of the associative - function isomorphism. Such functions support containsKey, entryAt, assoc, and both valAts. Because such an isomorphism exists, the only reason to use this not-a-function is to exploit the extra operations and guarantees by law we get, and allowing domain transformation this way is a stronger claim than the ability to override particular mappings. -- Stephen Compall ^aCollection allSatisfy: [:each|aCondition]: less is better -- 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: ClojureScript + Jayq Resulting in Error
A simple observation: Ari, you are using [lein-cljsbuild 0.2.9] while Ilia is using version 0.2.10. Also, you are using [org.clojure/clojurescript 0.0-1450]. I generally do not recommend specifying a clojurescript version explicitly -- the version that lein-cljsbuild defaults to is the one that it has been tested against and is known to work with. You should only specify a custom version of clojurescript if you have a good reason and know exactly what you're doing. -Evan -- 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: Is contributing to clojurescript is intentionally made hard ?
Being the maintainer of an open source problem is a hard task. Contributing to a project is not a process that begins and ends with code submissions. In fact, it's often more work for a maintainer to accept a patch or pull request than it is for him or her to write the equivalent code himself. Clojure is hardly the only project that doesn't accept pull requests. The Linux Kernel and Guava are two that immediately come to mind. For Guava's rationale, you might read the following: https://plus.google.com/113026104107031516488/posts/ZRdtjTL1MpM Their reasons are not identical to Rich's, but the sentiment is similar. Does this mean you shouldn't even try to contribute? No, of course not. But, contributions to clojure are definitely less easy to make than to projects that willy-nilly accept any pull request. On Sat, Jan 19, 2013 at 3:02 PM, Alexey Petrushin alexey.petrus...@gmail.com wrote: +1 On Saturday, January 19, 2013 11:47:56 PM UTC+4, Andy Fingerhut wrote: On Jan 18, 2013, at 3:52 PM, Sean Corfield wrote: On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut andy.fi...@gmail.com wrote: The issue that Clojure, its contrib libraries, and ClojureScript do not accept github pull requests has been brought up several times before on this email list in the past. Feel free to search the Google group for terms like pull request. Short answer: Rich Hickey prefers a workflow of evaluating patches, not pull requests. It is easier for him. My understanding is that with pull requests it becomes much harder to provide accountability for Intellectual Property which is a legal concern, and that's why we have a Contributor's Agreement. The patch process naturally falls out of the legal CA-covered process since each patch is clearly identified as belonging to a specific contributor - and submitting a patch comes with the responsibility of vouching for the legal status of that submission. Github's pull request process makes it all too easy to incorporate code that belongs to a Github account holder who is not covered by the legal agreement and places the burden of verification on screeners to verify the IP ownership. But let's not re-hash the issue of the CA. Folks can just read the archives and there's really nothing new to add... I won't rehash the issue, but will provide direct pointers to a couple of posts that led me to believe my statements above. Here is a link to the whole thread, with many posts on the then-just-being-started clojure-doc.org web site (which I'm pleased to see has certainly come a long way since early Oct 2012): https://groups.google.com/**forum/?fromgroups=#!topic/** clojure/jWMaop_eVaQhttps://groups.google.com/forum/?fromgroups=#!topic/clojure/jWMaop_eVaQ Scan a down to Jay Fields post from Oct 6 2012, and then to Rich Hickey's response later the same day. I don't have any inside info about Rich's preferences for patches outside of such public messages, but it definitely seems to be due to workflow preference issues, not legal issues. Andy -- 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: Is contributing to clojurescript is intentionally made hard ?
Also, another blog post dealing with the open source code contribution issue: http://www.igvita.com/2011/12/19/dont-push-your-pull-requests/ On Sat, Jan 19, 2013 at 5:38 PM, Aaron Cohen aa...@assonance.org wrote: Being the maintainer of an open source problem is a hard task. Contributing to a project is not a process that begins and ends with code submissions. In fact, it's often more work for a maintainer to accept a patch or pull request than it is for him or her to write the equivalent code himself. Clojure is hardly the only project that doesn't accept pull requests. The Linux Kernel and Guava are two that immediately come to mind. For Guava's rationale, you might read the following: https://plus.google.com/113026104107031516488/posts/ZRdtjTL1MpM Their reasons are not identical to Rich's, but the sentiment is similar. Does this mean you shouldn't even try to contribute? No, of course not. But, contributions to clojure are definitely less easy to make than to projects that willy-nilly accept any pull request. On Sat, Jan 19, 2013 at 3:02 PM, Alexey Petrushin alexey.petrus...@gmail.com wrote: +1 On Saturday, January 19, 2013 11:47:56 PM UTC+4, Andy Fingerhut wrote: On Jan 18, 2013, at 3:52 PM, Sean Corfield wrote: On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut andy.fi...@gmail.com wrote: The issue that Clojure, its contrib libraries, and ClojureScript do not accept github pull requests has been brought up several times before on this email list in the past. Feel free to search the Google group for terms like pull request. Short answer: Rich Hickey prefers a workflow of evaluating patches, not pull requests. It is easier for him. My understanding is that with pull requests it becomes much harder to provide accountability for Intellectual Property which is a legal concern, and that's why we have a Contributor's Agreement. The patch process naturally falls out of the legal CA-covered process since each patch is clearly identified as belonging to a specific contributor - and submitting a patch comes with the responsibility of vouching for the legal status of that submission. Github's pull request process makes it all too easy to incorporate code that belongs to a Github account holder who is not covered by the legal agreement and places the burden of verification on screeners to verify the IP ownership. But let's not re-hash the issue of the CA. Folks can just read the archives and there's really nothing new to add... I won't rehash the issue, but will provide direct pointers to a couple of posts that led me to believe my statements above. Here is a link to the whole thread, with many posts on the then-just-being-started clojure-doc.org web site (which I'm pleased to see has certainly come a long way since early Oct 2012): https://groups.google.com/**forum/?fromgroups=#!topic/** clojure/jWMaop_eVaQhttps://groups.google.com/forum/?fromgroups=#!topic/clojure/jWMaop_eVaQ Scan a down to Jay Fields post from Oct 6 2012, and then to Rich Hickey's response later the same day. I don't have any inside info about Rich's preferences for patches outside of such public messages, but it definitely seems to be due to workflow preference issues, not legal issues. Andy -- 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: Associative extends Seqable?
On Sat, Jan 19, 2013 at 1:26 PM, Stephen Compall
stephen.comp...@gmail.com wrote:
What do you return for count, though?
I don't currently implement count.
There are other ways to make trouble anyway: it's perfectly possible
to define infinite sets that support conjoining, disjoining, union,
intersection, difference, etc., whether in forms that also support
seq-ing, e.g. sets of multiples of a given integer, or not (or not
obviously to me), in terms of an arbitrary characteristic
function---these not necessarily being infinite, I suppose.
Such sets couldn't support forward domain transformation, though,
because membership testing could then fail to terminate.
Given the definition of seq you suggested above, membership testing
for a transformed map will also be in danger of not terminating.
That's the only reason it's not observably incorrect.
But fine---again, it's not clear to me why this makes the sets deficient.
But you couldn't transform that result's domain with a newdomain -
newhotnessdomain; it would thus no longer be an associative under the
qualification I'm positing.
[...]
Yes; this is the case I described as follows:
The only way you can apply both transformations is if your
domain is vacuous: that is, constant functions like yours are
the only ones that permit domain transform in either direction.
[given, I assume, the proviso that the transformed result must be
capable of further forward transformation?]
But in the end my more fundamental question is: what makes it the case
that associatives can transform their domains forward? AFAICT the
answer is the enumerability of associatives.
My previous email argued that the former implied the latter, rather than
vice versa. Forward domain transformation via injection seems more
fundamental than enumerability, to me.
But there's a case where forward domain transformation is possible
without (correct) enumeration being possible (you don't, contrary to
what you said, need to produce the entire search space), which ought
to scotch that direction of implication.
So, in fact, it has not helped me to look at the relation between
enumerability and forward domain transformability, because I no more
see why the latter is something that belongs with associating elements
of a domain with elements of a codomain than I do the former.
Because that definition of associative, associating elements of a
domain with elements of a codomain, is entirely characterized by the
codomain of the associative - function isomorphism. Such functions
support containsKey, entryAt, assoc, and both valAts.
And without, too. Except that actually they don't support any of them:
user= (.containsKey even? 2)
java.lang.IllegalArgumentException: No matching method found:
containsKey for class clojure.core$even_QMARK_ (NO_SOURCE_FILE:0)
user= (get even? 2)
nil
And, as Clojure now stands, such functions *can't* honestly support
those operations, because supporting them would require also
supporting seq and count. They can support valAt through ILookUp, but
there are no corresponding independent interfaces for containsKey,
entryAt (both of which you might expect to be in ILookUp), or assoc.
Or without.
In practice, there are lots of reasons to use these not-a-functions
other than extra operations and guarantees. I would not like to have
to write the map {2 :x -2 :y} as #(case % 2 :x -2 :y ::not-found)* and
I suspect the implementation of assoc gains by not being e.g. (fn [m k
v] #(if (= % k) v (m %))), not to mention the implementation of the
maps themselves. In very few cases, I think, has anyone thought
should I use a function or a map? Well, I need forward domain
transformation, so, a map. In the particular case that eventually
prompted my discovery of the inheritance relation mentioned in the
subject of this thread, neither enumeration nor forward domain
transformation was relevant, just assoc and valAt.
* though one could imagine a reader macro to do the relevant transformation.
Now, I would like to use, alongside the full-fledged not-a-functions
that have the various extra operations and guarantees, some
basically-just-a-functions, with the same interface---since the only
operations I'll actually use can be supported by both. But the only
interface that provides get, assoc, and dissoc makes *further*
guarantees.
I don't really care about the name. If there were an interface
IDomainToCodomain, I wouldn't complain that Associative extends
IPersistentCollection and Seqable. (In fact, in that case, Associative
could consist entirely in extending IDomainToCodomain and
IPersistentCollection. (Optimally---from my perspective---there would
additionally be some interface for dissociable things apart from
everything IPersistentMap brings with it.) If that separation were
effected, then the decision whether to use a function or a
not-a-function could be made on the basis of the strength of the
guarantees one requires.
Re: Is contributing to clojurescript is intentionally made hard ?
contributions to clojure are definitely less easy to make than to projects that willy-nilly accept any pull request. False dichotomy. Accepting pull requests does not mean you need to be willy-nilly about it. You know how people carefully optimize their signup forms and checkout flows? They do this because there's a (very large) category of people who simply give up when things aren't immediately obvious. Granted, this category is much smaller among the class of folks skilled enough to create a desirable Clojure patch. However, the fact that this topic keeps coming up suggests that maybe that group is large enough to pay attention too. As the Clojure implementations evolve, fewer and fewer people will discover issues large enough to justify diving into the code base to fix them. Most people just work around the issues. If somebody takes the initiative to properly fix an issue, we shouldn't add yet another hurdle discouraging them from contributing. -- 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: Is contributing to clojurescript is intentionally made hard ?
Aaron, please forgive my failure at formalities: Allow me to add that I agree with the rest of your post. The Linux kernel and Guava guys are absolutely right about patches defaulting to the rejected state. I'm a big believer in the minus 100 points philosophy. It's just that I just really hate JIRA. -- 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: Is contributing to clojurescript is intentionally made hard ?
Yep, tools to maintain tickets suck, Jira, Mantis,... However, having Clojure code in production 24/7 and ClojureScript code reaching production status in a month or so, I feel reassured that a maintenance process is in place and that patch screening is tight. We have enough doing the same thing here with our own code, I wonder how we would fare if the layers we are building upon were not tightly managed as possible given the limited resources. Building pyramids on sand is not my cup of tea. Nobody yet has invented a maintenance process relying on thin air. Wether you accept or not pull requests is like focusing on the tree and not seeing the forest. There's a documented maintenance/enhancement process, it may look rigid but unless someone makes a formal proposal for a full maintenance workflow with human costs and benefits, I would rather stick with this one. Luc P. Aaron, please forgive my failure at formalities: Allow me to add that I agree with the rest of your post. The Linux kernel and Guava guys are absolutely right about patches defaulting to the rejected state. I'm a big believer in the minus 100 points philosophy. It's just that I just really hate JIRA. -- 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 -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: a question about running embedded jetty
I did not know #'app is for reload. It's very helpful. Thanks.
On Saturday, January 19, 2013 5:26:06 PM UTC+8, Baishampayan Ghose wrote:
On Sat, Jan 19, 2013 at 5:24 AM, faenvie fanny@gmx.de javascript:
wrote:
i have learned that for a ring/compojure-app the embedded jetty
service can be started like this:
(def app (handler/site routes))
(defn start [port]
(ring/run-jetty (var app) {:port (or port 8080)
:join? false}))
can anyone explain, what is the var for ? why '(var app)' or #'app ?
i found some remarks about being able to change the app without
having to restart the server but how exactly does this relate ?
If you pass in the app as it is, then the var gets evaluated to the
function that the var refers to and the jetty adapter uses that
function to run the server.
Now if you recompile your ring handlers (aka functions) the same app
var will get rebound to a new function while the jetty server will
continue holding on to the old handler function, so if you refresh the
page, etc. you won't see the change on your browser. You will have to
kill the server and restart jetty.
If you pass just the var instead, jetty holds on to the container (the
var) and not the value. The jetty-adapter derefs the var on every
request and sends the response back. As a result if you recompile your
handlers you'll see the effects immediately without restarting the
server.
The derefing has a penalty, albeit minor. Thus, you may choose to not
pass in the app as a var in production deployments.
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: How to (easily) show the advantages of Clojure
I think it depends a lot on your audience. For example, java spring programmers are likely going to be impressed by the simplicity and speed at which you can get a project started, especially when using lein and being able to avoid the common load of bolerplate java, xml, etc. Programmers familiar with database development etc, may appreciate the STM more, lisp programmers will likely be impressed by how easy it is to take advantage of the huge wealth of existing Java APIs and managers may be impressed by the fact things can be deployed under the existing ecosystem. There is no single answer, but a little research into what type of audience you are addressing will help. Try and find out what some of the current 'pain points' are with their current environment. This could be testing, it could be deployment, it could be the ability to make rapid changes, handle concurrency issues, prototyping, cumbersome code, build test cycles etc. If you know this, you can structure examples that will clearly show the relevance and likely generate some excitement etc. Tim On Thursday, January 17, 2013 2:08:41 AM UTC+11, Thomas wrote: Hi All, Something that came up last night in the blank? thread. What is a good way to show someone the advantages of Clojure. Something that is simple, not too complicated, easily understood, shows a (significant) benefit, etc. Any ideas? (As said in the other thread, I have used the blank? example from Stuart Halloway to show people the difference). Thomas -- 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: Associative extends Seqable?
On Sat, 2013-01-19 at 14:56 -0800, Ben Wolfson wrote:
Such sets couldn't support forward domain transformation, though,
because membership testing could then fail to terminate.
Given the definition of seq you suggested above, membership testing
for a transformed map will also be in danger of not terminating.
That's the only reason it's not observably incorrect.
Domain transformation need not be implemented with enumeration, as in
the case of vacuous domains, as it is not permitted for the transform to
do something like exclude keys that were present in the old domain.
But fine---again, it's not clear to me why this makes the sets deficient.
You can test for membership of infinite sets like the even integers very
quickly. Once an arbitrary injection is applied, though, it is more
troublesome.
The only way you can apply both transformations is if your
domain is vacuous: that is, constant functions like yours are
the only ones that permit domain transform in either direction.
[given, I assume, the proviso that the transformed result must be
capable of further forward transformation?]
Of course. :)
But in the end my more fundamental question is: what makes it the case
that associatives can transform their domains forward? AFAICT the
answer is the enumerability of associatives.
My previous email argued that the former implied the latter, rather than
vice versa. Forward domain transformation via injection seems more
fundamental than enumerability, to me.
But there's a case where forward domain transformation is possible
without (correct) enumeration being possible (you don't, contrary to
what you said, need to produce the entire search space), which ought
to scotch that direction of implication.
That's fair. The slightly stronger claim of Associative, then, is
useful for its exclusion of constant functions.
Because that definition of associative, associating elements of a
domain with elements of a codomain, is entirely characterized by the
codomain of the associative - function isomorphism.
Apologies, I should have said monomorphism; indeed, there are no
isomorphisms given the definitions I'm using :]
Such functions support containsKey, entryAt, assoc, and both
valAts.
And without, too. Except that actually they don't support any of them:
user= (.containsKey even? 2)
java.lang.IllegalArgumentException: No matching method found:
containsKey for class clojure.core$even_QMARK_ (NO_SOURCE_FILE:0)
user= (get even? 2)
nil
Yes; Clojure can't discriminate this kind of function, so implementing
even that subset of Associative I mentioned couldn't be done safely. We
can write them, though, applying the needed constraints ourselves if you
wish safety.
;; A total function whose codomain represents both boundedness and the
;; values of some other function.
(def-alias Kma (TFn [[x :variance :contravariant]
[y :variance :covariant]]
(Fn [x - (Option (Vector* y))])))
(ann associative-kma
(All [a b] (Fn [(IPersistentMap a b) - (Kma a b)])))
(defn associative-kma
This is *the* associative - function monomorphism, because it is
isomorphic to all other associative - function monomorphisms.
[m]
(fn [k] (if-let [[_ v] (find m k)]
[v])))
(ann entry-at
(All [a b] (Fn [(Kma a b) a - (Option (Vector* a b))])))
(defn entry-at
As with entryAt.
[kma k]
(if-let [[v] (kma k)]
[k v]))
(ann val-at
(All [a b] (Fn [(Kma a b) a - (Option b)]
[(Kma a b) a b - b])))
(defn val-at
As with valAt.
([kma k] (first (kma k)))
([kma k o] (if-let [[v] (kma k)]
v
o)))
(ann assoc'
(All [a b] (Fn [(Kma a b) a b - (Kma a b)])))
(defn assoc'
Preserves the earlier law suggested for assoc.
[kma k v]
(fn [k'] (if (= k k') [v] (kma k'
(ann contains?'
(All [a b] (Fn [(Kma a b) a - Boolean])))
(defn contains?'
[kma k]
(if (kma k) true false)) ;yeah I know
I suspect the implementation of assoc gains by not being e.g. (fn [m k
v] #(if (= % k) v (m %))), not to mention the implementation of the
maps themselves.
Agreed. However, a general assoc could detect when you are using a
specialized representation of function, preserving compatibility with
something like Kma.
In very few cases, I think, has anyone thought should I use a function
or a map? Well, I need forward domain transformation, so, a map.
I imagine it goes on indirectly, that is to say well, I need [some
implication of forward domain transformation], so, a map.
* though one could imagine a reader macro to do the relevant transformation.
Aye, what is {}, after all?
I don't really care about the name. If there were an interface
IDomainToCodomain, I wouldn't complain that Associative extends
IPersistentCollection and Seqable. (In fact, in that case, Associative
could consist entirely in extending
[ANN] Leiningen 2.0.0 released
Greetings fellow Clojure people. I've just pushed out the final release of Leiningen 2.0.0. The changes since the last release candidate have mostly been minor bugfixes. Highlights since 1.x include profiles, a much-improved REPL, signature support, partial application of aliases, offline mode, faster search, and much more. If you're interested in the full list you can check out NEWS.md here: https://github.com/technomancy/leiningen/blob/master/NEWS.md As mentioned earlier in the RC cycle, if you've been tracking the development plans for Leiningen 2, you may be curious to note that the above does not include a switch to the Clojars releases repository. We ran into a number of unforeseen technical problems with the promotion process to the releases repository and want to give library authors more time to get their artifacts promoted. For the time being Leiningen's behaviour regarding Clojars remains unchanged. You should be able to pull in the latest release with `lein upgrade`[1]. Please report any issues to either the Librelist mailing list or the GitHub issue tracker: https://github.com/technomancy/leiningen/issues Thanks to everyone who contributed to make this release happen. -Phil [1] - There was a bug in certain preview releases that may make it necessary to run `lein upgrade 2.0.0` instead. pgpL7a0CZTrA9.pgp Description: PGP signature
Re: Is contributing to clojurescript is intentionally made hard ?
I think Brandon, in fact I discovered bunch of clojurescript bugs while working on my wisp project but since submitting and fixing them felt like too much work I just ignored them. Unfortunately I keep looking into my fixes now to back port them to cljs_in_cljs. I also absolutely agree if issues keeps coming up that certainly means there is a problem worth looking into Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 14:57 , Brandon Bloom wrote: contributions to clojure are definitely less easy to make than to projects that willy-nilly accept any pull request. False dichotomy. Accepting pull requests does not mean you need to be willy-nilly about it. You know how people carefully optimize their signup forms and checkout flows? They do this because there's a (very large) category of people who simply give up when things aren't immediately obvious. Granted, this category is much smaller among the class of folks skilled enough to create a desirable Clojure patch. However, the fact that this topic keeps coming up suggests that maybe that group is large enough to pay attention too. As the Clojure implementations evolve, fewer and fewer people will discover issues large enough to justify diving into the code base to fix them. Most people just work around the issues. If somebody takes the initiative to properly fix an issue, we shouldn't add yet another hurdle discouraging them from contributing. -- 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 (mailto: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 (mailto: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: Is contributing to clojurescript is intentionally made hard ?
As of comments related to projects that also make contributions hard that's their choice, and I really hope clojure community will do better than that. I also know that sometimes rewriting patch is a lot less work than making someones contribution acceptable, my day job involves all of that, but still we help people trying to contribute regardless sometimes that means they send in copies of files :) Never the less we work with them so people are still encouraged to contribute, over the time level of these contributions also grows. Turning them away is just strange to me. And yes at mozilla we do code that is production and used by billions of people over the world and being helpful to contributors never had being harmful in doing that. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 15:08 , Brandon Bloom wrote: Aaron, please forgive my failure at formalities: Allow me to add that I agree with the rest of your post. The Linux kernel and Guava guys are absolutely right about patches defaulting to the rejected state. I'm a big believer in the minus 100 points philosophy. It's just that I just really hate JIRA. -- 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 (mailto: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 (mailto: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: Is contributing to clojurescript is intentionally made hard ?
On Saturday, 2013-01-19 at 11:56 , Andy Fingerhut wrote: Irakli: I am curious about the possibility of auto-creating patches from git pull requests, in case that would bridge the divide between people that would prefer submitting pull requests, and Clojure screeners that would prefer evaluating patches and JIRA tickets. Causing a new git pull request to to auto-create a JIRA ticket with a patch sounds easy, but that isn't the whole process. What about comments that are later added to the pull request? Are they auto-added as comments to the JIRA ticket? Are comments added to the JIRA ticket auto-added as comments to the pull request? If the JIRA ticket is closed, does that automatically close the github pull request? If the answer to all of the above is yes, already works that way, then I'd be willing to spend a little more time looking into it. Do you have links to any info on the tools that enable such behavior? I'm afraid I don't have answers to those questions it's just someone have pointed out this link https://confluence.atlassian.com/display/JIRASTUDIO/Linking+GitHub+Activities+to+JIRA+Issues in the pull request I created when it was closed down. Bugzilla integration does all of these, but syncing comments. Maybe support for JIRA is better or worth, I have no way of trying that out as I don't have access to JIRA. Thanks, Andy On Jan 18, 2013, at 5:13 PM, Irakli Gozalishvili wrote: At mozilla we also require signing CA but do accept pull requests and there are whole team of legal people that makes sure things like that don't raise any legal concerns. After all it's just .patch to the pull request url gives you an actual change patch so if reviewing patches is desired it's easy to build a tool that attaches it to JIRA. We in fact do that for bugzilla. The good news is that such tools are already written for JIRA so it's just matter of enabling it! -- 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 (mailto: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 (mailto: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: Is contributing to clojurescript is intentionally made hard ?
Than Sean for pointing to that thread that's helpful although that got me wondering if Rich is only one doing the reviews ? If that's not the case maybe there at least on maintainer that is willing to bridge the gap here ? I really hope someone will step up to bridge the gap, maybe setup a fork and then forward contributions as a patches to JIRA so people who love patches will look at them instead. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 11:47 , Andy Fingerhut wrote: On Jan 18, 2013, at 3:52 PM, Sean Corfield wrote: On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut andy.finger...@gmail.com (mailto:andy.finger...@gmail.com) wrote: The issue that Clojure, its contrib libraries, and ClojureScript do not accept github pull requests has been brought up several times before on this email list in the past. Feel free to search the Google group for terms like pull request. Short answer: Rich Hickey prefers a workflow of evaluating patches, not pull requests. It is easier for him. My understanding is that with pull requests it becomes much harder to provide accountability for Intellectual Property which is a legal concern, and that's why we have a Contributor's Agreement. The patch process naturally falls out of the legal CA-covered process since each patch is clearly identified as belonging to a specific contributor - and submitting a patch comes with the responsibility of vouching for the legal status of that submission. Github's pull request process makes it all too easy to incorporate code that belongs to a Github account holder who is not covered by the legal agreement and places the burden of verification on screeners to verify the IP ownership. But let's not re-hash the issue of the CA. Folks can just read the archives and there's really nothing new to add... I won't rehash the issue, but will provide direct pointers to a couple of posts that led me to believe my statements above. Here is a link to the whole thread, with many posts on the then-just-being-started clojure-doc.org (http://clojure-doc.org) web site (which I'm pleased to see has certainly come a long way since early Oct 2012): https://groups.google.com/forum/?fromgroups=#!topic/clojure/jWMaop_eVaQ Scan a down to Jay Fields post from Oct 6 2012, and then to Rich Hickey's response later the same day. I don't have any inside info about Rich's preferences for patches outside of such public messages, but it definitely seems to be due to workflow preference issues, not legal issues. Andy -- 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 (mailto: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 (mailto: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: Is contributing to clojurescript is intentionally made hard ?
I would be curious to also see number of lost contributors. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 22:00 , David Nolen wrote: I have nothing to add to this thread beyond pointing out that ClojureScript has had _51_ contributors in the short year and a half of its existence: http://github.com/clojure/clojurescript/graphs/contributors. Via JIRA. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com (mailto: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 (mailto: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: Is contributing to clojurescript is intentionally made hard ?
Anyway it's seems to me that message in this thread is pretty clear: We're just doing fine without people like you It's a shame, but whatever I'll just shut up and let you guys roll as you pleased Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 22:31 , Irakli Gozalishvili wrote: I would be curious to also see number of lost contributors. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 22:00 , David Nolen wrote: I have nothing to add to this thread beyond pointing out that ClojureScript has had _51_ contributors in the short year and a half of its existence: http://github.com/clojure/clojurescript/graphs/contributors. Via JIRA. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com (mailto: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 (mailto: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: [ANN] Leiningen 2.0.0 released
Hey, congratulations! Thank you so much Phil and everyone else for making this happen. I still remember the pre-Leiningen 1 days with the occasional dependency-script PTSD flashback. Lein 2 is a great big step up from 1. All kinds of awesome. Well done! -- 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: Is contributing to clojurescript is intentionally made hard ?
It is great that questions are being asked about how things do, might or should work - but tone of the original question and the ensuing discussion, in my view, unfortunate. On Sunday, 20 January 2013 17:36:11 UTC+11, Irakli Gozalishvili wrote: Anyway it's seems to me that message in this thread is pretty clear: We're just doing fine without people like you It's a shame, but whatever I'll just shut up and let you guys roll as you pleased Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 22:31 , Irakli Gozalishvili wrote: I would be curious to also see number of lost contributors. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Saturday, 2013-01-19 at 22:00 , David Nolen wrote: I have nothing to add to this thread beyond pointing out that ClojureScript has had _51_ contributors in the short year and a half of its existence: http://github.com/clojure/clojurescript/graphs/contributors. Via JIRA. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To 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
