Re: ANN: a Clojure docs site, and github organization
+1 to lowering the barrier to entry for contributing to the community. One of the much lauded features of Git is that it can be used to create a network of trust. In principle this means you can open your repo up to anyone, but by being choosy about the pull requests you accept you can control what's going to get in. This is perfect for something like documentation. Also, as it's been said before, a pen and paper CA is a pain. On Friday, 5 October 2012 08:26:39 UTC-5, Mayank Jain wrote: On Fri, Oct 5, 2012 at 6:54 PM, Michael Klishin michael@gmail.comjavascript: wrote: 2012/10/5 Michael Fogus mef...@gmail.com javascript: You say that as if it's a bad thing. I'm of the opinion that these kinds of efforts should have a low barrier to contribution and be fun. My apologies, I did not imply that it is a bad thing, only that it is not entirely clear what direction the project will take. While for CDS it is pretty clear (at least to people who have started it). While we are at this fun stuff, can we also make the CA submission process fun? +1 -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- 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 -- Regards, Mayank. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: how to use clojure.reflect/doc in the cljs-repl?
Sorry about the reflect stuff is quite new and in need of work. The reflect
support should work through whatever port browser REPL was setup on.
On Saturday, October 6, 2012, Frank Siebenlist wrote:
Ok - I managed to get clojure.reflect/doc to work if the browser loads the
javascript from the repl-server instead of the separate webserver…
When the reason for this issue is that the repl- web-servers are
listening on different ports, where the js is downloaded from the webserver
while the reflect-handler is associaed with the repl-server…
then you will not be able to use the clojure.reflect/doc with the standard
lein-cljsbuild setup.
Unless you can somehow specify the port number for the clojure.reflect/doc
GET request (?).
Ough.
-FS.
On Oct 5, 2012, at 9:28 PM, Frank Siebenlist
frank.siebenl...@gmail.comjavascript:;
wrote:
Forgot to mention that the issue is most probably on the browser side,
because pointing a webbrowser at
http://localhost:9000/reflect?var=example.hello/say-hello; by hand,
yields in the browser window:
cljs.core.ObjMap.fromObject([\uFDD0'method-params,\uFDD0'name,\uFDD0'doc,\uFDD0'line,\uFDD0'file],{\uFDD0'method-params:[[]],\uFDD0'name:example.hello/say-hello,\uFDD0'doc:say-hello
doc,\uFDD0'line:10,\uFDD0'file:/Users/franks/Development/ClojureScript/swimtimer/src-cljs/example/hello.cljs});
which is what one expects.
-FS.
On Oct 5, 2012, at 9:13 PM, Frank Siebenlist
frank.siebenl...@gmail.comjavascript:;
wrote:
…bumb…
Is this maybe related to the use of lein-cljsbuild and having a
separate server from which the js is downloaded?
In other words, the reflect handler seems to be listening on the repl
server on port 9000,
while the web server from which the js is initially downloaded is
listening on port 3000.
The cljs-reflect code seems to get a conn from (net/xhr-connection),
but I can not see any port number specified…
I've reached the end of my javascript and goog knowledge… please.
Did anyone get this to work with the lein-cljsbuild setup?
-FrankS.
On Sep 23, 2012, at 2:10 PM, Frank Siebenlist
frank.siebenl...@gmail.com javascript:; wrote:
Trying to use the clojure.reflect/doc function in the cljs-repl,
but I only errors
---
ClojureScript:cljs.user (clojure.reflect/doc clojure.reflect/doc)
nil
Reflection query failed.
ClojureScript:cljs.user (clojure.reflect/doc clojure.reflect.doc)
nil
Reflection query failed.
ClojureScript:cljs.user (clojure.reflect/doc 'clojure.reflect.doc)
nil
Reflection query failed.
ClojureScript:cljs.user (clojure.reflect/doc 'doc)
nil
Reflection query failed.
---
Do I have to configure something on the server side maybe?
Any suggestions?
Thanks, FrankS.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@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+unsubscr...@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: ANN: a Clojure docs site, and github organization
This insistence on the so-called CA pain seems to me overemphasized. It's a one shot process. Even if it takes 4 weeks for the paper to reach its destination, it does not prevent anyone from starting to work on some contribution. The CA needs to be in by the time the work is about to get published, not by the time you start to contribute. My writing is horrible, worst than a doctor, I hate filling forms by hand but I was able to fill the CA, stamp it and drop it in the mailbox in less than 10 mns. I live in Canada close to the US, I can understand the frustration if you have to drop by your local post office if it needs to get stamped over there but one time processes like this rarely benefit from an optimization. I would be surprised that we end up with 250,000 contributors in the next 3 years. There is simply not enough Clojure wired brains out there to get to numbers like the above. If it ever happens, you can bet than Clojure Core will come out with something to avoid being flooded by papers if it is legally feasible. Laws in many countries have been slow to move to consider electronic formats as legally binding documents. This may well be why a written CA is needed considering that contributors come different countries. What may seem obviously legal in one country may not be legal at all in another. Better documentation is to me by far a more urgent priority to attract newbies than allowing CAs to be submitted electronically given the legal fees involved just to get an opinion about its feasability. Luc P. +1 to lowering the barrier to entry for contributing to the community. One of the much lauded features of Git is that it can be used to create a network of trust. In principle this means you can open your repo up to anyone, but by being choosy about the pull requests you accept you can control what's going to get in. This is perfect for something like documentation. Also, as it's been said before, a pen and paper CA is a pain. On Friday, 5 October 2012 08:26:39 UTC-5, Mayank Jain wrote: On Fri, Oct 5, 2012 at 6:54 PM, Michael Klishin michael@gmail.comjavascript: wrote: 2012/10/5 Michael Fogus mef...@gmail.com javascript: You say that as if it's a bad thing. I'm of the opinion that these kinds of efforts should have a low barrier to contribution and be fun. My apologies, I did not imply that it is a bad thing, only that it is not entirely clear what direction the project will take. While for CDS it is pretty clear (at least to people who have started it). While we are at this fun stuff, can we also make the CA submission process fun? +1 -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- 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 -- Regards, Mayank. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Some Friend documentation and regarding documentation in general
Hi folks, I've been pretty slack in communicating via the mailing list, but I realized today that there is a lot of important dialogue going on here so I have to make more of an effort to take part--I want to be a part of this community! In any case, I've been using Friend a lot lately, since I come from Ruby-on-Rails-land, and it addresses a lot of the pain points that Devise does for me. But (as has been mentioned in other threads quite recently), documentation is definitely the Clojure community's week point: it's inconsistent, formatted inconsistently (Ring and Compojure, for example, are wonderful exceptions), and updated erratically. When it's good, it's great; but when it's not, it puts me off from using a library. For example, I stayed away from Enlive for months before I realized what a useful library it is--so I re-wrote the README to suit my tastes (https://github.com/ddellacosta/enlive). I think Chas Emerick writes much better docs than much of what accompanies most Clojure libraries, but he's quite an advanced Clojure developer, and he's moving very fast--so as a newbie, I had difficulty even with his relatively good docs for Friend. And I suspect you'll be getting more and more folks from the web development world in the next few years like me. So it will be good to have things from the perspective of someone not just trying to grok the libraries that exist, but also trying to understand how Clojure works, and how the eco-system fits together. I've written some material on how to use Friend, including some OAuth2 resources. I'd appreciate any feedback you can give, I'm pretty new to Clojure (and Lisp in general). In any case: https://github.com/ddellacosta/friend-interactive-form-tutorial https://github.com/ddellacosta/friend-oauth2-examples https://github.com/ddellacosta/friend-oauth2 I have a bunch of other Clojure-related stuff on my github account too, feedback is most welcome! Cheers, DD -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: a Clojure docs site, and github organization
The CA process isn't what stops me from contributing, the post a patch to Jira is what seems broken to me. I don't even remember how to create a patch. Clojure is on github - we live in a fork pull request world, it's time for Clojure to get on board with that. I once noticed that a Clojure fn didn't have a type hint on a return value. Adding ^String made a substantial performance difference. Not knowing the process, I forked, and did a pull request. I got this response: Clojure projects cannot accept pull requests so all issues need to be logged in the appropriate JIRA project and patches can be accepted from people who have a signed Contributor's Agreement on file: http://clojure.org/contributing http://clojure.org/patches; Which is informative and correct, but, do you really think I'm going to go through that trouble? If you said yes, you're wrong. Cheers, Jay On Sat, Oct 6, 2012 at 11:40 AM, Softaddicts lprefonta...@softaddicts.ca wrote: This insistence on the so-called CA pain seems to me overemphasized. It's a one shot process. Even if it takes 4 weeks for the paper to reach its destination, it does not prevent anyone from starting to work on some contribution. The CA needs to be in by the time the work is about to get published, not by the time you start to contribute. My writing is horrible, worst than a doctor, I hate filling forms by hand but I was able to fill the CA, stamp it and drop it in the mailbox in less than 10 mns. I live in Canada close to the US, I can understand the frustration if you have to drop by your local post office if it needs to get stamped over there but one time processes like this rarely benefit from an optimization. I would be surprised that we end up with 250,000 contributors in the next 3 years. There is simply not enough Clojure wired brains out there to get to numbers like the above. If it ever happens, you can bet than Clojure Core will come out with something to avoid being flooded by papers if it is legally feasible. Laws in many countries have been slow to move to consider electronic formats as legally binding documents. This may well be why a written CA is needed considering that contributors come different countries. What may seem obviously legal in one country may not be legal at all in another. Better documentation is to me by far a more urgent priority to attract newbies than allowing CAs to be submitted electronically given the legal fees involved just to get an opinion about its feasability. Luc P. +1 to lowering the barrier to entry for contributing to the community. One of the much lauded features of Git is that it can be used to create a network of trust. In principle this means you can open your repo up to anyone, but by being choosy about the pull requests you accept you can control what's going to get in. This is perfect for something like documentation. Also, as it's been said before, a pen and paper CA is a pain. On Friday, 5 October 2012 08:26:39 UTC-5, Mayank Jain wrote: On Fri, Oct 5, 2012 at 6:54 PM, Michael Klishin michael@gmail.comjavascript: wrote: 2012/10/5 Michael Fogus mef...@gmail.com javascript: You say that as if it's a bad thing. I'm of the opinion that these kinds of efforts should have a low barrier to contribution and be fun. My apologies, I did not imply that it is a bad thing, only that it is not entirely clear what direction the project will take. While for CDS it is pretty clear (at least to people who have started it). While we are at this fun stuff, can we also make the CA submission process fun? +1 -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- 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 -- Regards, Mayank. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Question on mandatory arguments for - and - macros
Hi, I am curious about the rationale for the mandatory arguments for - and - macros. user= (doc -) - clojure.core/- ([x] [x form] [x form more]) user= (doc -) - clojure.core/- ([x form] [x form more]) For - a form is optional, but for - it is not. Can anybody help me understand why is there a difference? 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: Some Friend documentation and regarding documentation in general
This is fantastic documentation and Michael's feedback is apt and valuable. I think resources like this should be linked-to from the Friend README (or an appropriate documentation site, e.g. CDS) to collect such pointers in one place. Shantanu On Oct 6, 10:02 pm, Michael Klishin michael.s.klis...@gmail.com wrote: 2012/10/6 Dave Della Costa ddellaco...@gmail.com I've written some material on how to use Friend, including some OAuth2 resources. I'd appreciate any feedback you can give, I'm pretty new to Clojure (and Lisp in general). In any case: https://github.com/ddellacosta/friend-interactive-form-tutorial This tutorial is missing the crucial first step: explaining how to add Friend as a dependency with Leiningen (and Maven). Another thing worth adding is a section of what kind of features Friend has: not everybody is coming from the same background and knows what Devise and CanCan are or what they are used for. I haven't done Web development in a while so maybe it's just me but I have no idea what the interactive form workflow is. https://github.com/ddellacosta/friend-oauth2-examples This one is missing the information about what port the example is running on. It's running now, cool, how do I try it out? I have a bunch of other Clojure-related stuff on my github account too, feedback is most welcome! It's great to see someone writing tutorials for projects that are fundamental building blocks (if you choose to build a Web app in Clojure, you probably gonna need Friend or something like Friend fairly quickly). It will take a few rounds to make your tutorial good, don't get discouraged by it. And I really hope it will make it into Friend's documentation in some shape or form. -- 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: clojurescript: how to use clojure.reflect/doc in the cljs-repl?
David, please do not apologize… your contributions to clojurescript have been
invaluable, and the last time I checked you still have a full-time job with
that village-newspaper somewhere on the East coast...
My current efforts are to help improve the clojurescript help facilities. I
have working versions of the apropos, ns-resolve, find-ns, source-fn,
ns-mapfriends, and managed to make our clj-ns-browser work with that
clojurescript metadata such that you can browse the cljs-namespaces (see
https://gist.github.com/3803119 and
https://raw.github.com/franks42/clj-ns-browser/cljs/Cljs%20Browser%202012-10-05.png
for some proof of progress).
All those facilities run on the clj-jvm and make use of the meta-data in the
cljs.analyzer/@namespaces map. You can invoke them from any clj-repl that
connects to the same jvm while you interact with the cljs-repl.
To make them available to the cljs-repl, you ideally need some form of rpc-like
calls to get that info from the clj-jvm, like the clojure.reflect/doc
implementation (the repl-prompting is a little awkward, though - with all the
asynchronous processing it may be better to drive the promp-printing from the
js-side… but that's a different discussion)
As I didn't get clojure.reflect/doc to work, I've used the special-fns
interface that you pass into the cljs.repl/repl function. However, and I
don't think I will offend anyone, the way how those special-fns are
implemented is one huge ugly hack…;-), and I do not really want to share my
project while it depends on that.
So… that's why I was trying so hard to make that clojure.reflect/doc work with
lein-cljsbuild.
Regards, FrankS.
On Oct 6, 2012, at 7:56 AM, David Nolen dnolen.li...@gmail.com wrote:
Sorry about the reflect stuff is quite new and in need of work. The reflect
support should work through whatever port browser REPL was setup on.
On Saturday, October 6, 2012, Frank Siebenlist wrote:
Ok - I managed to get clojure.reflect/doc to work if the browser loads the
javascript from the repl-server instead of the separate webserver…
When the reason for this issue is that the repl- web-servers are listening
on different ports, where the js is downloaded from the webserver while the
reflect-handler is associaed with the repl-server…
then you will not be able to use the clojure.reflect/doc with the standard
lein-cljsbuild setup.
Unless you can somehow specify the port number for the clojure.reflect/doc
GET request (?).
Ough.
-FS.
On Oct 5, 2012, at 9:28 PM, Frank Siebenlist frank.siebenl...@gmail.com
wrote:
Forgot to mention that the issue is most probably on the browser side,
because pointing a webbrowser at
http://localhost:9000/reflect?var=example.hello/say-hello; by hand,
yields in the browser window:
cljs.core.ObjMap.fromObject([\uFDD0'method-params,\uFDD0'name,\uFDD0'doc,\uFDD0'line,\uFDD0'file],{\uFDD0'method-params:[[]],\uFDD0'name:example.hello/say-hello,\uFDD0'doc:say-hello
doc,\uFDD0'line:10,\uFDD0'file:/Users/franks/Development/ClojureScript/swimtimer/src-cljs/example/hello.cljs});
which is what one expects.
-FS.
On Oct 5, 2012, at 9:13 PM, Frank Siebenlist frank.siebenl...@gmail.com
wrote:
…bumb…
Is this maybe related to the use of lein-cljsbuild and having a separate
server from which the js is downloaded?
In other words, the reflect handler seems to be listening on the repl
server on port 9000,
while the web server from which the js is initially downloaded is
listening on port 3000.
The cljs-reflect code seems to get a conn from (net/xhr-connection), but I
can not see any port number specified…
I've reached the end of my javascript and goog knowledge… please.
Did anyone get this to work with the lein-cljsbuild setup?
-FrankS.
On Sep 23, 2012, at 2:10 PM, Frank Siebenlist frank.siebenl...@gmail.com
wrote:
Trying to use the clojure.reflect/doc function in the cljs-repl,
but I only errors
---
ClojureScript:cljs.user (clojure.reflect/doc clojure.reflect/doc)
nil
Reflection query failed.
ClojureScript:cljs.user (clojure.reflect/doc clojure.reflect.doc)
nil
Reflection query failed.
ClojureScript:cljs.user (clojure.reflect/doc 'clojure.reflect.doc)
nil
Reflection query failed.
ClojureScript:cljs.user (clojure.reflect/doc 'doc)
nil
Reflection query failed.
---
Do I have to configure something on the server side maybe?
Any suggestions?
Thanks, FrankS.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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
Re: clojurescript: how to use clojure.reflect/doc in the cljs-repl?
On Sat, Oct 6, 2012 at 1:32 PM, Frank Siebenlist frank.siebenl...@gmail.com wrote: David, please do not apologize… your contributions to clojurescript have been invaluable, and the last time I checked you still have a full-time job with that village-newspaper somewhere on the East coast... My current efforts are to help improve the clojurescript help facilities. I have working versions of the apropos, ns-resolve, find-ns, source-fn, ns-mapfriends, and managed to make our clj-ns-browser work with that clojurescript metadata such that you can browse the cljs-namespaces (see https://gist.github.com/3803119 and https://raw.github.com/franks42/clj-ns-browser/cljs/Cljs%20Browser%202012-10-05.pngfor some proof of progress). All those facilities run on the clj-jvm and make use of the meta-data in the cljs.analyzer/@namespaces map. You can invoke them from any clj-repl that connects to the same jvm while you interact with the cljs-repl. To make them available to the cljs-repl, you ideally need some form of rpc-like calls to get that info from the clj-jvm, like the clojure.reflect/doc implementation (the repl-prompting is a little awkward, though - with all the asynchronous processing it may be better to drive the promp-printing from the js-side… but that's a different discussion) As I didn't get clojure.reflect/doc to work, I've used the special-fns interface that you pass into the cljs.repl/repl function. However, and I don't think I will offend anyone, the way how those special-fns are implemented is one huge ugly hack…;-), and I do not really want to share my project while it depends on that. So… that's why I was trying so hard to make that clojure.reflect/doc work with lein-cljsbuild. Regards, FrankS. special-fns is not the way to go :) clojure.reflect should be fixed to do the right thing - it was a oversight to make the interaction asynchronous - it should work precisely as browser REPL does now - synchronously. There's an open ticket for this in 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Some Friend documentation and regarding documentation in general
Michael, this is great feedback. This tutorial is missing the crucial first step: explaining how to add Friend as a dependency with Leiningen (and Maven). So, part of me had thought that these details would covered by looking through the source of the repo, but on consideration, I think you're right--this is indeed the kind of stuff I was bit by when I started working with Clojure. Point taken; I'll tweak it to make that part clear. features Friend has: not everybody is coming from the same background and knows what Devise and CanCan are or what they are used for. Good point--I'll add some links and/or descriptions, as it seems appropriate. I haven't done Web development in a while so maybe it's just me but I have no idea what the interactive form workflow is. Another good point: this is what it is called in Friend. I'll fix this so it is more clear what I mean by this (or just change the wording). This one is missing the information about what port the example is running on. It's running now, cool, how do I try it out? You should just be able to clone the repo, and start it up, assuming you've got the necessary oauth config for FB or App.net. The source should make it pretty clear, but if anything is unclear, do let me know. Obviously the README is not enough, so if you play with it and have ideas how it can be improved, let me know. And sorry, what do you mean by what port? It will take a few rounds to make your tutorial good, don't get discouraged by it. Not at all! This kind of feedback is exactly what I want. I want to help make these docs as high quality as possible, so they can be a resource for those coming into the community. I have an ulterior motive: the more folks that are using Clojure for building high-quality web apps, the more chance I can get a job doing Clojure stuff fulltime, instead of as a hobby...haha. Anyways, I'll update this stuff as soon as I have time. Thanks again for the feedback, Michael. DD (12/10/07 2:01), Michael Klishin wrote: 2012/10/6 Dave Della Costa ddellaco...@gmail.com mailto:ddellaco...@gmail.com I've written some material on how to use Friend, including some OAuth2 resources. I'd appreciate any feedback you can give, I'm pretty new to Clojure (and Lisp in general). In any case: https://github.com/ddellacosta/friend-interactive-form-tutorial This tutorial is missing the crucial first step: explaining how to add Friend as a dependency with Leiningen (and Maven). Another thing worth adding is a section of what kind of features Friend has: not everybody is coming from the same background and knows what Devise and CanCan are or what they are used for. I haven't done Web development in a while so maybe it's just me but I have no idea what the interactive form workflow is. https://github.com/ddellacosta/friend-oauth2-examples This one is missing the information about what port the example is running on. It's running now, cool, how do I try it out? I have a bunch of other Clojure-related stuff on my github account too, feedback is most welcome! It's great to see someone writing tutorials for projects that are fundamental building blocks (if you choose to build a Web app in Clojure, you probably gonna need Friend or something like Friend fairly quickly). It will take a few rounds to make your tutorial good, don't get discouraged by it. And I really hope it will make it into Friend's documentation in some shape or form. -- 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 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Some Friend documentation and regarding documentation in general
Thanks Shantanu! Yeah, I'll ping Chas Emerick to see what he thinks if he doesn't tune in on this thread. (12/10/07 2:25), Shantanu Kumar wrote: This is fantastic documentation and Michael's feedback is apt and valuable. I think resources like this should be linked-to from the Friend README (or an appropriate documentation site, e.g. CDS) to collect such pointers in one place. Shantanu On Oct 6, 10:02 pm, Michael Klishin michael.s.klis...@gmail.com wrote: 2012/10/6 Dave Della Costa ddellaco...@gmail.com I've written some material on how to use Friend, including some OAuth2 resources. I'd appreciate any feedback you can give, I'm pretty new to Clojure (and Lisp in general). In any case: https://github.com/ddellacosta/friend-interactive-form-tutorial This tutorial is missing the crucial first step: explaining how to add Friend as a dependency with Leiningen (and Maven). Another thing worth adding is a section of what kind of features Friend has: not everybody is coming from the same background and knows what Devise and CanCan are or what they are used for. I haven't done Web development in a while so maybe it's just me but I have no idea what the interactive form workflow is. https://github.com/ddellacosta/friend-oauth2-examples This one is missing the information about what port the example is running on. It's running now, cool, how do I try it out? I have a bunch of other Clojure-related stuff on my github account too, feedback is most welcome! It's great to see someone writing tutorials for projects that are fundamental building blocks (if you choose to build a Web app in Clojure, you probably gonna need Friend or something like Friend fairly quickly). It will take a few rounds to make your tutorial good, don't get discouraged by it. And I really hope it will make it into Friend's documentation in some shape or form. -- 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: Some Friend documentation and regarding documentation in general
Ah, right. Again, something I'm making assumptions about that maybe I shouldn't be. I use 'lein ring server-headless' to run the app, and it always shows up on port 3000. I believe this is a part of Compojure, but I have to admit I'm not positive--it shows up in the Compojure docs here (minus the 'headless' bit, which just avoids loading a browser up, something I don't want to be happening every time): https://github.com/weavejester/compojure/wiki/Getting-Started (12/10/07 2:57), Michael Klishin wrote: 2012/10/6 Dave Della Costa ddellaco...@gmail.com mailto:ddellaco...@gmail.com And sorry, what do you mean by what port? Will the example be accessible on http://localhost:4000, :3000 or :8080? -- 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 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: a Clojure docs site, and github organization
On Saturday, October 6, 2012 12:03:00 PM UTC-4, Jay Fields wrote: I once noticed that a Clojure fn didn't have a type hint on a return value. Adding ^String made a substantial performance difference. Not knowing the process, I forked, and did a pull request. I got this response: Clojure projects cannot accept pull requests so all issues need to be logged in the appropriate JIRA project and patches can be accepted from people who have a signed Contributor's Agreement on file: http://clojure.org/contributing http://clojure.org/patches; Which is informative and correct, but, do you really think I'm going to go through that trouble? If you said yes, you're wrong. In cases like this, how would Core react if you just emailed clojure-dev with hi, noticed $issue, is this a bug?? Though, I just remembered, it can take some time to get approved to post on the clojure-dev ML. Hm. ---John -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Some Friend documentation and regarding documentation in general
Sorry Michael, I was mistaken about it being Compojure, this is obviously all lein-ring territory (see in particular, Starting a web server): https://github.com/weavejester/lein-ring (12/10/07 2:57), Michael Klishin wrote: 2012/10/6 Dave Della Costa ddellaco...@gmail.com mailto:ddellaco...@gmail.com And sorry, what do you mean by what port? Will the example be accessible on http://localhost:4000, :3000 or :8080? -- 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 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: a Clojure docs site, and github organization
I do not agree at all with you. Any piece of software that gets used widely needs to be maintained with some formal process otherwise there's no way to insure consistency of future releases. It gets worse as you increase the # of people that can modify code. Tickets may seem to you as overhead but it's a decent way to track issues and fixes according to release plans. Looking at a bunch of commits in git is limited compared to dedicated ticket logging solutions like Jira. Providing patches attached to the ticket links the ticket to the code in git is much more usable. Refusing pull requests is a way to force issues to be logged in Jira. The main entrance gate is in Jira, not the other way around. Clojure is not the only open source projects driven by a ticket reporting system. This may look as overhead to you but it is still lighter than similar processes in many software businesses. You can report the kind of problems you highlighted on the mailing list so at least others can take ownership of the issue if you do not feel inclined to post it in Jira. Luc The CA process isn't what stops me from contributing, the post a patch to Jira is what seems broken to me. I don't even remember how to create a patch. Clojure is on github - we live in a fork pull request world, it's time for Clojure to get on board with that. I once noticed that a Clojure fn didn't have a type hint on a return value. Adding ^String made a substantial performance difference. Not knowing the process, I forked, and did a pull request. I got this response: Clojure projects cannot accept pull requests so all issues need to be logged in the appropriate JIRA project and patches can be accepted from people who have a signed Contributor's Agreement on file: http://clojure.org/contributing http://clojure.org/patches; Which is informative and correct, but, do you really think I'm going to go through that trouble? If you said yes, you're wrong. Cheers, Jay On Sat, Oct 6, 2012 at 11:40 AM, Softaddicts lprefonta...@softaddicts.ca wrote: This insistence on the so-called CA pain seems to me overemphasized. It's a one shot process. Even if it takes 4 weeks for the paper to reach its destination, it does not prevent anyone from starting to work on some contribution. The CA needs to be in by the time the work is about to get published, not by the time you start to contribute. My writing is horrible, worst than a doctor, I hate filling forms by hand but I was able to fill the CA, stamp it and drop it in the mailbox in less than 10 mns. I live in Canada close to the US, I can understand the frustration if you have to drop by your local post office if it needs to get stamped over there but one time processes like this rarely benefit from an optimization. I would be surprised that we end up with 250,000 contributors in the next 3 years. There is simply not enough Clojure wired brains out there to get to numbers like the above. If it ever happens, you can bet than Clojure Core will come out with something to avoid being flooded by papers if it is legally feasible. Laws in many countries have been slow to move to consider electronic formats as legally binding documents. This may well be why a written CA is needed considering that contributors come different countries. What may seem obviously legal in one country may not be legal at all in another. Better documentation is to me by far a more urgent priority to attract newbies than allowing CAs to be submitted electronically given the legal fees involved just to get an opinion about its feasability. Luc P. +1 to lowering the barrier to entry for contributing to the community. One of the much lauded features of Git is that it can be used to create a network of trust. In principle this means you can open your repo up to anyone, but by being choosy about the pull requests you accept you can control what's going to get in. This is perfect for something like documentation. Also, as it's been said before, a pen and paper CA is a pain. On Friday, 5 October 2012 08:26:39 UTC-5, Mayank Jain wrote: On Fri, Oct 5, 2012 at 6:54 PM, Michael Klishin michael@gmail.comjavascript: wrote: 2012/10/5 Michael Fogus mef...@gmail.com javascript: You say that as if it's a bad thing. I'm of the opinion that these kinds of efforts should have a low barrier to contribution and be fun. My apologies, I did not imply that it is a bad thing, only that it is not entirely clear what direction the project will take. While for CDS it is pretty clear (at least to people who have started it). While we are at this fun stuff, can we also make the CA submission process fun? +1 -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- You received this message
Re: ANN: a Clojure docs site, and github organization
I don't always remember how to create a patch, either, but I do remember where to go to get the short instructions to do so in case I forget. In case you are curious, the process for creating a patch is documented here, under the heading Developing and submitting patches to Clojure and Clojure Contrib. This page is linked to from the contributing and patches pages you give links for in your message. http://dev.clojure.org/display/design/JIRA+workflow On my screen it is about 2 1/2 screenfuls. If you would prefer not to go through those steps, I understand, but it isn't terribly arcane. Andy On Oct 6, 2012, at 9:02 AM, Jay Fields wrote: The CA process isn't what stops me from contributing, the post a patch to Jira is what seems broken to me. I don't even remember how to create a patch. Clojure is on github - we live in a fork pull request world, it's time for Clojure to get on board with that. I once noticed that a Clojure fn didn't have a type hint on a return value. Adding ^String made a substantial performance difference. Not knowing the process, I forked, and did a pull request. I got this response: Clojure projects cannot accept pull requests so all issues need to be logged in the appropriate JIRA project and patches can be accepted from people who have a signed Contributor's Agreement on file: http://clojure.org/contributing http://clojure.org/patches; Which is informative and correct, but, do you really think I'm going to go through that trouble? If you said yes, you're wrong. Cheers, Jay -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: a Clojure docs site, and github organization
I would agree that the CA pain is overemphasized if the submitter lives in the USA or Canada. It isn't difficult at all. I have since heard that to get a letter from Russia to the USA, there are several methods, but they range from inexpensive-but-can-take-months-and-are-unreliable, to quick-and-reliable-but-$200. Those are significantly higher barriers than for developers based in the USA and Canada, where it is a 44 cent stamp and a few days to get there quite reliably. Andy On Oct 6, 2012, at 8:40 AM, Softaddicts wrote: This insistence on the so-called CA pain seems to me overemphasized. It's a one shot process. Even if it takes 4 weeks for the paper to reach its destination, it does not prevent anyone from starting to work on some contribution. The CA needs to be in by the time the work is about to get published, not by the time you start to contribute. My writing is horrible, worst than a doctor, I hate filling forms by hand but I was able to fill the CA, stamp it and drop it in the mailbox in less than 10 mns. I live in Canada close to the US, I can understand the frustration if you have to drop by your local post office if it needs to get stamped over there but one time processes like this rarely benefit from an optimization. I would be surprised that we end up with 250,000 contributors in the next 3 years. There is simply not enough Clojure wired brains out there to get to numbers like the above. If it ever happens, you can bet than Clojure Core will come out with something to avoid being flooded by papers if it is legally feasible. Laws in many countries have been slow to move to consider electronic formats as legally binding documents. This may well be why a written CA is needed considering that contributors come different countries. What may seem obviously legal in one country may not be legal at all in another. Better documentation is to me by far a more urgent priority to attract newbies than allowing CAs to be submitted electronically given the legal fees involved just to get an opinion about its feasability. Luc P. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 not transitive?
On Friday, October 5, 2012 7:17:50 PM UTC+2, Ben wrote: I'm not sure what you mean by this. Transitivity means that for all x, y, and z, (Fxy Fyz) = Fxz. But there are values of x, y, and z for which that does not hold. Yeah, sorry. What I meant was that == is only commutative if you pass it two arguments as of right now. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Some Friend documentation and regarding documentation in general
Hi Dave, This is a metric ton of awesome; thank you very much for taking the time and effort to put all this together. And, BTW, based on what I've seen so far, I never would have thought you were new to Clojure. :-) cont'd… On Oct 6, 2012, at 11:49 AM, Dave Della Costa wrote: I think Chas Emerick writes much better docs than much of what accompanies most Clojure libraries, but he's quite an advanced Clojure developer, and he's moving very fast--so as a newbie, I had difficulty even with his relatively good docs for Friend. And I suspect you'll be getting more and more folks from the web development world in the next few years like me. So it will be good to have things from the perspective of someone not just trying to grok the libraries that exist, but also trying to understand how Clojure works, and how the eco-system fits together. Noted re: Friend's docs. I've actually fallen behind a bit on my documentation activities this year; both Friend and nREPL are underdocumented at the moment. I know that Friend's docs are particularly dense, especially for anyone that just wants to use the stuff. That's probably due to my using the docs to talk through the library's design more than anything else, in part to help potential workflow authors understand what's going on, in part to provoke people into protesting certain decisions (this is my first swing at writing an authentication/authorization library, which should petrify you... ;-) I've known for some time that I'd like to have a companion project that implements all sorts of common usage scenarios that can be easily pushed up to heroku in order to facilitate experimentation. Pairing those with end-user-focused tutorials would be even better. I daresay you're getting the jump on me in both directions, which I really appreciate. I've written some material on how to use Friend, including some OAuth2 resources. I'd appreciate any feedback you can give, I'm pretty new to Clojure (and Lisp in general). In any case: https://github.com/ddellacosta/friend-interactive-form-tutorial https://github.com/ddellacosta/friend-oauth2-examples https://github.com/ddellacosta/friend-oauth2 I am personally very interested in friend-oauth2, for obvious reasons. (Onlookers can watch https://github.com/cemerick/friend/issues/23 for activity between it and Friend itself.) I haven't worked through the tutorial, but I did find it really well-written and a phenomenal start. I think a good next step would be for me to create a Friend organization (of course https://github.com/friend is taken! :-P), so that you and others can readily contribute tutorials, example projects, and more that can be gradually cultivated into canonical, easily-approachable code and content. Talk later… Thanks again, - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: a Clojure docs site, and github organization
On Oct 6, 2012, at 12:02 PM, Jay Fields wrote: The CA process isn't what stops me from contributing, the post a patch to Jira is what seems broken to me. I don't even remember how to create a patch. Clojure is on github - we live in a fork pull request world, it's time for Clojure to get on board with that. Lots of people eat fast food as well. I once noticed that a Clojure fn didn't have a type hint on a return value. Adding ^String made a substantial performance difference. Not knowing the process, I forked, and did a pull request. I got this response: Clojure projects cannot accept pull requests so all issues need to be logged in the appropriate JIRA project and patches can be accepted from people who have a signed Contributor's Agreement on file: http://clojure.org/contributing http://clojure.org/patches; Which is informative and correct, but, do you really think I'm going to go through that trouble? If you said yes, you're wrong. I'm responding to Jay here (because we're friends and I know he can take it:), but this is for everyone who feels similarly: I prefer patches. I understand some people don't. Can't we just agree to disagree? Why must this be repeatedly gone over? I'm not sure what value you think a message like this is going to provide to the thousands of participants in this list. Does it make you feel better? It will not convince me otherwise. Here's how I see it. I've spent at least 100,000x as much time on Clojure as you will in the difference between producing a patch vs a pull request. The command is: git format-patch master --stdout your-patch-file.diff There are two sides to change management - production/submission, and management/assessment/application/other-stewardship. People who argue that the process should be optimized for ease of submission are simply wrong. What if I said patches were twice as efficient for me to assess and manage as pull requests? (it's more than that) Do the math and figure out how the effort should best be distributed. I don't think asking for patches is asking too much, and I truly appreciate the people who are going to the extra effort. And, I respect the fact that people disagree, and they might decide not to participate as a result. However, I don't need to justify my decision over and over. How about a little consideration for me, and the other list participants? There is a real diluting effect of get-it-off-my-chest messages such as these on the value of the list and the utility of reading it for myself and others. Sometimes it's better to save it for your bartender :) Rich -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: a Clojure docs site, and github organization
It would be nice if there were an alternative to the CA for small documentation contributions. Wikipedia is largely built up from a small pool of dedicated people but many valuable contributions come from small anonymous edits. On Saturday, 6 October 2012 18:22:32 UTC-5, Luc wrote: The validity of a scanned signature or electronic keys is subject to interpretation and assessment on a per case basis especially in civil contracts by the diverse legal systems on Earth. It's not the Clojure community that is behind, it's the legal systems of many countries that did not follow the pace of technology. Some will not recognize scanned signatures at all. On the other hand, original hand written signatures are recognized almost every where. As much as you complain about the paper CA, you should complain about the legal systems of these countries that do not follow US and western Europe attempts to recognize technology changes and adapt to it. You analyze the issue by the wrong end It's not a technology issue, it's a legal one. You could have the best electronic authentication scheme, if it's not recognized by a country's legal system, it's useless in court in this country. If claims rights on contributions not backed by a CA in a valid form as defined in this country, it's a lost case. Big organizations have the tools and budgets to fight in various legal systems out there. Not small open source projects or projects without big sponsors. I understand and approve the requirement of the original hand written signature in this context. That's a real life issue that cannot be dealt with by technology alone. If a national mail system is not able to get reliably an envelope to the US within 4/5 weeks, I would be very concerned about the state of their legal system. Luc 2012/10/7 Softaddicts lprefo...@softaddicts.ca javascript: I do not agree at all with you. Any piece of software that gets used widely needs to be maintained with some formal process otherwise there's no way to insure consistency of future releases. It gets worse as you increase the # of people that can modify code. Sorry, have you tried reading what people who complain about the CA submission process actually complain about? They do not complain about having the CA. They are not eager to jump in working on the language. They complain about being shut out from contributing *anything* (including documentation and updates to libraries like data.json) by the requirement that CA has to be mailed in paper, in the year 2012. We have posted examples of projects and corporations that accept PDFs over email: Oracle, OpenJDK, Apache Software Foundation, Neo4J. Scala and Opscode found more creative solutions that use OAuth and similar techniques. As far as the number of language designers, I think there is little disagreement that the number Clojure has right now (1 or 2, with some influence from maybe 5-6 more) is about optimal. There is much more to success and adoption of Clojure than just language features, design, consistency and other things that may benefit from this tight grip. Tickets may seem to you as overhead but it's a decent way to track issues and fixes according to release plans. Looking at a bunch of commits in git is limited compared to dedicated ticket logging solutions like Jira. Providing patches attached to the ticket links the ticket to the code in git is much more usable. Refusing pull requests is a way to force issues to be logged in Jira. The main entrance gate is in Jira, not the other way around. This is all handwaving. You can use a bug tracker and plan the hell out of releases on github. Many projects do so. However, how quickly contributions are accepted matters a lot for smaller improvements like the Jay's example. Go take a look at repositories under github.com/clojure, you will find 10-20 people contributing small improvements and being rejected every single month. Do you really think most of them actually will come back? Do you have the guts to say they should not be considered valuable members of the community because of that? If you make something difficult or time consuming, people will do it less. Clojure is not the only open source projects driven by a ticket reporting system. This may look as overhead to you but it is still lighter than similar processes in many software businesses. You can report the kind of problems you highlighted on the mailing list so at least others can take ownership of the issue if you do not feel inclined to post it in Jira. It's about even having a chance to participate. JIRA and patches are annoying to anyone who has used github for
Re: ANN: a Clojure docs site, and github organization
For documentation purposes, I think it could be relaxed but it would still need some reviewing process. The main concern here's is to avoid cloning other published stuff with legal rights either intentionally or not. Luc P. It would be nice if there were an alternative to the CA for small documentation contributions. Wikipedia is largely built up from a small pool of dedicated people but many valuable contributions come from small anonymous edits. On Saturday, 6 October 2012 18:22:32 UTC-5, Luc wrote: The validity of a scanned signature or electronic keys is subject to interpretation and assessment on a per case basis especially in civil contracts by the diverse legal systems on Earth. It's not the Clojure community that is behind, it's the legal systems of many countries that did not follow the pace of technology. Some will not recognize scanned signatures at all. On the other hand, original hand written signatures are recognized almost every where. As much as you complain about the paper CA, you should complain about the legal systems of these countries that do not follow US and western Europe attempts to recognize technology changes and adapt to it. You analyze the issue by the wrong end It's not a technology issue, it's a legal one. You could have the best electronic authentication scheme, if it's not recognized by a country's legal system, it's useless in court in this country. If claims rights on contributions not backed by a CA in a valid form as defined in this country, it's a lost case. Big organizations have the tools and budgets to fight in various legal systems out there. Not small open source projects or projects without big sponsors. I understand and approve the requirement of the original hand written signature in this context. That's a real life issue that cannot be dealt with by technology alone. If a national mail system is not able to get reliably an envelope to the US within 4/5 weeks, I would be very concerned about the state of their legal system. Luc 2012/10/7 Softaddicts lprefo...@softaddicts.ca javascript: I do not agree at all with you. Any piece of software that gets used widely needs to be maintained with some formal process otherwise there's no way to insure consistency of future releases. It gets worse as you increase the # of people that can modify code. Sorry, have you tried reading what people who complain about the CA submission process actually complain about? They do not complain about having the CA. They are not eager to jump in working on the language. They complain about being shut out from contributing *anything* (including documentation and updates to libraries like data.json) by the requirement that CA has to be mailed in paper, in the year 2012. We have posted examples of projects and corporations that accept PDFs over email: Oracle, OpenJDK, Apache Software Foundation, Neo4J. Scala and Opscode found more creative solutions that use OAuth and similar techniques. As far as the number of language designers, I think there is little disagreement that the number Clojure has right now (1 or 2, with some influence from maybe 5-6 more) is about optimal. There is much more to success and adoption of Clojure than just language features, design, consistency and other things that may benefit from this tight grip. Tickets may seem to you as overhead but it's a decent way to track issues and fixes according to release plans. Looking at a bunch of commits in git is limited compared to dedicated ticket logging solutions like Jira. Providing patches attached to the ticket links the ticket to the code in git is much more usable. Refusing pull requests is a way to force issues to be logged in Jira. The main entrance gate is in Jira, not the other way around. This is all handwaving. You can use a bug tracker and plan the hell out of releases on github. Many projects do so. However, how quickly contributions are accepted matters a lot for smaller improvements like the Jay's example. Go take a look at repositories under github.com/clojure, you will find 10-20 people contributing small improvements and being rejected every single month. Do you really think most of them actually will come back? Do you have the guts to say they should not be considered valuable members of the community because of that? If you make something difficult or time consuming, people will do it less. Clojure is not the only open source projects driven by a ticket reporting system. This may look as overhead to you but it is still lighter than
Re: ANN: a Clojure docs site, and github organization
On Oct 6, 2012, at 6:04 PM, Michael Klishin michael.s.klis...@gmail.com wrote: 2012/10/7 Softaddicts lprefonta...@softaddicts.ca The validity of a scanned signature or electronic keys is subject to interpretation and assessment on a per case basis especially in civil contracts by the diverse legal systems on Earth. It's not the Clojure community that is behind, it's the legal systems of many countries that did not follow the pace of technology. Some will not recognize scanned signatures at all. On the other hand, original hand written signatures are recognized almost every where. A reminder: scans work for Oracle and ASF. Oracle probably has x100 as many lawyers as Clojure/core, lawyers several times as experienced and about x10,000 times as much experience with this stuff as a company. And it works for them. I thought the CA for chef had a pretty slick online process: https://secure.echosign.com/public/hostedForm?formid=PJIF5694K6L -Ben -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: a Clojure docs site, and github organization
Google also has something similiar, and it has probably been checked by an army of layers. http://code.google.com/legal/individual-cla-v1.0.html On Sunday, October 7, 2012 2:25:36 AM UTC+2, Ben Mabey wrote: On Oct 6, 2012, at 6:04 PM, Michael Klishin michael@gmail.comjavascript: wrote: 2012/10/7 Softaddicts lprefo...@softaddicts.ca javascript: The validity of a scanned signature or electronic keys is subject to interpretation and assessment on a per case basis especially in civil contracts by the diverse legal systems on Earth. It's not the Clojure community that is behind, it's the legal systems of many countries that did not follow the pace of technology. Some will not recognize scanned signatures at all. On the other hand, original hand written signatures are recognized almost every where. A reminder: scans work for Oracle and ASF. Oracle probably has x100 as many lawyers as Clojure/core, lawyers several times as experienced and about x10,000 times as much experience with this stuff as a company. And it works for them. I thought the CA for chef had a pretty slick online process: https://secure.echosign.com/public/hostedForm?formid=PJIF5694K6L -Ben -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: a Clojure docs site, and github organization
It works for Oracle because they have the $$$ to support it. You just confirmed that we are on the same wavelength, they have the weapons to nail anyone who would like to exercise exclusive rights on some contribution made under their CA even if that individual lives in Kazakhstan. They have the infra structure and several offices in various Countries and continents to cover their ass. Just to keep in touch with our marvelous legal systems in North America, read this: http://hrdailyadvisor.blr.com/archive/2010/08/20/Epinions_Employment_Law_Update_Scanned_Documents.aspx The first question/answer is pretty instructive. It's easier to avoid the whole issue with a piece of paper. Maybe in ten years things will have settled somehow. The above is dated from 2010 that's not far away. I will not anything else to this thread, the world is as it is. I you think that you are frustrated, maybe we should have a drink together and I could explain how much I am frustrated by this shattered world Do you expect to drop at the Conj ? Luc 2012/10/7 Softaddicts lprefonta...@softaddicts.ca The validity of a scanned signature or electronic keys is subject to interpretation and assessment on a per case basis especially in civil contracts by the diverse legal systems on Earth. It's not the Clojure community that is behind, it's the legal systems of many countries that did not follow the pace of technology. Some will not recognize scanned signatures at all. On the other hand, original hand written signatures are recognized almost every where. A reminder: scans work for Oracle and ASF. Oracle probably has x100 as many lawyers as Clojure/core, lawyers several times as experienced and about x10,000 times as much experience with this stuff as a company. And it works for them. As much as you complain about the paper CA, you should complain about the legal systems of these countries that do not follow US and western Europe attempts to recognize technology changes and adapt to it. You analyze the issue by the wrong end It's not a technology issue, it's a legal one. You could have the best electronic authentication scheme, if it's not recognized by a country's legal system, it's useless in court in this country. If claims rights on contributions not backed by a CA in a valid form as defined in this country, it's a lost case. Big organizations have the tools and budgets to fight in various legal systems out there. Not small open source projects or projects without big sponsors. I understand and approve the requirement of the original hand written signature in this context. That's a real life issue that cannot be dealt with by technology alone. If a national mail system is not able to get reliably an envelope to the US within 4/5 weeks, I would be very concerned about the state of their legal system. Sorry to break it to you, but legal systems outside of a few countries are seriously broken and it will take decades and many lives to fix this. And I assure you, people who live in those countries are just as concerned as you are, thanks for caring. So the system is how it is. Clojure/core can accept this unfortunate fact and find a way to accept CA submissions electronically. Or they can ignore all the complaints (again, not about the CA per se, but how it is currently submitted) and lose many potential contributions. Contributions from people who really want to make Clojure better, ready to spend many hours of their time contributing but were not lucky enough to be born in the Wonderland called Canada, where the law rules and the sun shines (at least 2 months of the year). It always starts with contributing something small. Then something else small. Then something slightly more significant. And next thing you know, you are a major contributor. That's how it started for every single active OSS contributor I know. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: optimized clojurescript-js file throws exception but debug version does not?
What about the --output_wrapper part? My clojurescript js never calls the minified foreign library directly: What I have is [1] some plain non-optimized javascript that calls [2] CodeMirror for the code and position, then calls [3] my clojurescript js to find out how to do the requested paredit thing, and then calls [2] CodeMirror again to do it. So [3] never calls [2] [2] and [3] export stuff so that [1] can call them. And my problem is that [2] isn't wrapped in an anonymous function. How do I get cljsbuild to tell Closure to use --output_wrapper? (Also, I guess there's a good reason why it doesn't always wrap its output?) On Friday, October 5, 2012 2:39:34 PM UTC-4, David Nolen wrote: By the way, I'm not sure compiling CodeMirror and my stuff in one go is the right approach, because I don't know whether CodeMirror is compatible with Google Closure's advanced compilation. (I see that CodeMirror 1's compression page had Google Closure advanced optimization as an option but it disappeared for CodeMirror 2.) I think doing so would require me to hand-edit CodeMirror to add a goog.provide call. You don't need to do that. That's what the :foreign-libs option is for which is described at the end of blog post. 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
