Re: with-open and line-seq
I've got a question about lazy-sequence and file reading. Is line-seq good to process lines from huge file? Let take this case, I want to process each line from a file with one or more functions. All lines must be processed. Line-seq return a lazy sequence, it means all already read lines stay in memory, doesn't it? So, if the processed file's size is many gigabytes, my heap size will explode, right? Or did I miss something? Le samedi 27 octobre 2012 01:45:47 UTC+2, daveray a écrit : Hi, At work I've had a few conversations about treating files, especially large ones, as seqs of lines. In particular, the apparent conflict between using clojure.core/with-open to ensure a file is closed appropriately, and clojure.core/line-seq as a generic sequence of lines which may be consumed by code that has no idea it's coming from a file. I've been told [1] that C# solves this problem because the IEnumerator interface is disposable so it's possible to clean up the underlying file, even if it's been wrapped in several layers of enumerators... and that since Clojure doesn't do this, it's flawed :) Thoughs? I'm aware of the custom seq that closes the file when the end is reached hack, but that doesn't seem very satisfying. How do others process large files in Clojure? Just make sure that the sequence is totally consumed within with-open? Just don't worry about closing files? Cheers, Dave [1] My C# experience is limited to a few days of writing example code for the C# bindings of a product's API. :) -- 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: with-open and line-seq
Just started using Clojure, found myself asking a similar question. Was writing programs operating as part of unix command shell pipes, so I wrote a macro that did something like the perl diamond operator. It iterates over a series of files and standard input, opening each in turn and reading line by line. This enables code like: (do-read-input-source-lines [x cmdline-args] (println x)) where cmdline-args is a sequence of files. Useful for simple scripts. The above expands roughly to: (doseq [input-source# cmdline-args] (with-open [rdr# (clojure.java.io/reader input-source#)] (doseq [x (line-seq rdr#)] (println x Basically, iterate over the files, opening each and iterating over the lines. There's a bit more to it to handle standard input correctly, but that's essentially it. This was fine until needing to aggregate across line and file boundaries. For example, consider reading files containing weather data (time, temperature, etc.), aggregating data, and outputting a summary line for every hour interval (eg. average temp). Assume it is undesirable to read entire files into memory, and the data used in an hour summary can cross file boundaries. I've been trying to understand what the options are for structuring code of this form. Approaches that seem obvious: a) The doseq/with-open/doseq pattern as in the macro I wrote. This appears to require mutable data structures for the aggregation and state transitions. Straightforward, but not in keeping with Clojure's preferred style. b) loop-recur - Structurally similar to doseq solution. Would be something like: (loop [...] (with-open [...] (loop [...] (recur ...))) (recur ...)) Haven't tried coding this yet, but looks like it should work. Code could be a little messy, but workable. c) Lazy sequence - Something along the lines of read-lines described in this thread. Would be quite nice, as it would fit smoothly with all the sequence processing constructs available. The downside is that it's not clear how to retain the nice resource management properties one gets from the with-open style clauses. In particular, the guarantee that any open files are closed in the event of exceptions. My guess is that this type of interaction between sequences and resource management has come up any of times before. Are there preferred ways to handle it? Language facilities I haven't discovered yet? --Jon -- 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
Free Clojure Course
There's a free 19 part series on basic Clojure @ http://www.udemy.com/clojure-code -- 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: with-open and line-seq
On Sun, Oct 28, 2012 at 9:38 AM, Christian Sperandio christian.speran...@gmail.com wrote: I've got a question about lazy-sequence and file reading. Is line-seq good to process lines from huge file? Let take this case, I want to process each line from a file with one or more functions. All lines must be processed. Line-seq return a lazy sequence, it means all already read lines stay in memory, doesn't it? So, if the processed file's size is many gigabytes, my heap size will explode, right? Or did I miss something? You missed something. All lines only stay in memory if you hold on to a reference to the beginning of the sequence. (Holding on to the head.) Generally, doing that is a bug. The whole point on lazy sequences is that you don't need to hold the whole sequence in memory, when you're processing it one item at a time. // 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
ANN: lein-clr for building ClojureCLR projects
Hi, I am happy to announce `lein-clr`, a Leiningen plugin for building ClojureCLR projects: https://github.com/kumarshantanu/lein-clr As of 0.1.0, dependency mechanism is not provided (external dependencies can be specified) but the following tasks work: * clean * compile * repl * run * test I have tested it on Windows 7 (64-bit) on both .NET and Mono. I saw no issues when using ClojureCLR 1.4, though there were few problems with ClojureCLR 1.3. Give it a try and please feel free to let me know what you think. Full changelog and TODO is here: https://github.com/kumarshantanu/lein-clr/blob/master/CHANGES.md 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: ANN: lein-clr for building ClojureCLR projects
Great work! Really looking forward to NuGet integration. On Sun, Oct 28, 2012 at 9:13 AM, Shantanu Kumar kumar.shant...@gmail.comwrote: Hi, I am happy to announce `lein-clr`, a Leiningen plugin for building ClojureCLR projects: https://github.com/kumarshantanu/lein-clr As of 0.1.0, dependency mechanism is not provided (external dependencies can be specified) but the following tasks work: * clean * compile * repl * run * test I have tested it on Windows 7 (64-bit) on both .NET and Mono. I saw no issues when using ClojureCLR 1.4, though there were few problems with ClojureCLR 1.3. Give it a try and please feel free to let me know what you think. Full changelog and TODO is here: https://github.com/kumarshantanu/lein-clr/blob/master/CHANGES.md 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 -- 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
I've looked at this for a bit now. It seems there are some slight inconsistencies in how the redirect info is used: Where the redirect-on-autth? is being set up for the interactive-form workflow it looks to me to be assumed to be a boolean flag. https://github.com/sundbp/friend/blob/master/src/cemerick/friend/workflows.clj#L79 At that point it's given as an argument when setting up the workflow (defaulting to true). Then when it's being used in the generic code it's first picked out - looking like boolean flag still: https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L145 but then all of a sudden assumed to be a string containing the url to redirect to: https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L149 Given that, for the interactive-form workflow, it can only be set at the time of creating the workflow, it seems impossible to actually achieve the flow where friend remembers which page under authentication that user tried to access, then do auth, and finally return user to the originally requested page in a dynamic fashion. Since given at workflow creation time it can't dynamically reflect things properly I'd have assumed. I'd have expected it to not be an argument at workflow creation time, but the originally requested url being dynamically kept track of at the point friend realizes it needs to redirect the user to do authentication, then that url being used on L149 up there when the workflow sets redirect-on-auth? to true. Am I misunderstanding the flow or is there a mixup here? The tests only tests for boolean state, not as a string url. On Thursday, October 25, 2012 2:54:49 PM UTC+1, Patrik Sundberg wrote: On Thursday, October 25, 2012 1:59:36 PM UTC+1, Chas Emerick wrote: On Oct 25, 2012, at 8:04 AM, Patrik Sundberg wrote: I've digested openid and using it with google, should have a working example to share when I have a time to put it together over weekend. I've got another common useage pattern I'd like to ask about: How do we accomplish automatic redirect to the correct page? Let's say user accesses /secret, isn't authenticated and gets redirected to /login by friend. once authenticated, how do we ensure we get redirected back to /secret? I think that's a bug in the OpenID workflow. Friend will do this redirection automatically if the workflow enables it: https://github.com/cemerick/friend/blob/master/src/cemerick/friend/workflows.clj#L79 There are a couple of testcases in the project that verify this; unfortunately, the OpenID workflow doesn't yet accept the same configuration option as the interactive form workflow. Please file an issue, and, if you are so bold, a patch. :-) Got it, adding it to my weekend list. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: what is the simplest user auth system possible?
What happens if the Persona project closes down? On Friday, October 26, 2012 7:06:48 AM UTC-4, Dave Sann wrote: For authorisation, I really like mozilla persona (previously browserid) which I discovered from refheap. javascript lib plus an http request from the server to validate. really simple. https://login.persona.org/ Dave On Friday, 26 October 2012 01:35:53 UTC+11, Stephen Compall wrote: On Oct 25, 2012 9:04 AM, larry google groups lawrenc...@gmail.com wrote: For my next step, I need to come up with a user system. My needs are minimal: I only need to know when someone is logged in, and I need to associate them with some user id (the id will simply be the id from a user table kept in MySql). I am curious what is the absolutely easiest way to do this? The easiest auth system to write is the one that's already written. https://github.com/cemerick/friend -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
clojure.org requires more clicks now
I'm using clojure.org a lot. Unfortunately navigating in it, since two weeks or so, was made worse. Is anyone feeling the same way ? Or I am just too stupid to use this webpage? What has been made worse?: In the old version, on the left edge, there were, under `Documentation', all the subsections of the documentation listed, e.g. `The Reader', or `Namespaces'. Because this subpoints were the things I looked at the most and very frequently indeed, it was very handy to click on the left edge on one of these subpoints, and then see in the main panel the content. But now I need to click on `Documentation'. Then I need to choose the subsection in the main panel. Then the main panel shows me the content of the subsection. If I want to look at a different subsection, I need to click twice: 1 time on the `Documentation' link in the left edge. Than on the subsection link in the main panel. That's really bad. Don't make me click. Heinz. -- 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: what is the simplest user auth system possible?
I never really get Persona (means person in Italian that doesn't really make a lot of sense, but whatever) what if I share my pc with my brother ? Maybe i miss something... If you are using mongodb I am using https://github.com/xavi/noir-auth-app that is using congomongo and since i am using monger i port it in https://github.com/siscia/noir-auth-app ... It manage maybe too much for your need, email authentication, resend email, change password and other fancy stuff, but the code is really clean and full of comments, really good code imo... If you have time you could port it to work with korma... it is not a lot of work at all... On Sunday, October 28, 2012 8:07:02 PM UTC+1, larry google groups wrote: What happens if the Persona project closes down? On Friday, October 26, 2012 7:06:48 AM UTC-4, Dave Sann wrote: For authorisation, I really like mozilla persona (previously browserid) which I discovered from refheap. javascript lib plus an http request from the server to validate. really simple. https://login.persona.org/ Dave On Friday, 26 October 2012 01:35:53 UTC+11, Stephen Compall wrote: On Oct 25, 2012 9:04 AM, larry google groups lawrenc...@gmail.com wrote: For my next step, I need to come up with a user system. My needs are minimal: I only need to know when someone is logged in, and I need to associate them with some user id (the id will simply be the id from a user table kept in MySql). I am curious what is the absolutely easiest way to do this? The easiest auth system to write is the one that's already written. https://github.com/cemerick/friend -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. -- 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.org requires more clicks now
Hello Heinz, I'm sorry you're finding navigation difficult on Clojure.org. I agree that fewer clicks are better, but we (me, Stuart Halloway, and a few others) felt that the site was getting cluttered with too many links, which was confusing to newcomers. It would be nice if the Documentation link in the left-side column could expand into a list of sub-sections, but I don't know if the technology behind the site (Wikispaces) can support that right now. -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: Some Friend documentation and regarding documentation in general
On Oct 28, 2012, at 2:57 PM, Patrik Sundberg wrote: I've looked at this for a bit now. It seems there are some slight inconsistencies in how the redirect info is used: Where the redirect-on-autth? is being set up for the interactive-form workflow it looks to me to be assumed to be a boolean flag. https://github.com/sundbp/friend/blob/master/src/cemerick/friend/workflows.clj#L79 At that point it's given as an argument when setting up the workflow (defaulting to true). Then when it's being used in the generic code it's first picked out - looking like boolean flag still: https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L145 but then all of a sudden assumed to be a string containing the url to redirect to: https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L149 Given that, for the interactive-form workflow, it can only be set at the time of creating the workflow, it seems impossible to actually achieve the flow where friend remembers which page under authentication that user tried to access, then do auth, and finally return user to the originally requested page in a dynamic fashion. Since given at workflow creation time it can't dynamically reflect things properly I'd have assumed. I'd have expected it to not be an argument at workflow creation time, but the originally requested url being dynamically kept track of at the point friend realizes it needs to redirect the user to do authentication, then that url being used on L149 up there when the workflow sets redirect-on-auth? to true. Am I misunderstanding the flow or is there a mixup here? The tests only tests for boolean state, not as a string url. You're misunderstanding. If ::redirect-on-auth? is any truthy value (which includes strings), then `redirect-new-auth` will either: (a) send a redirect to the ::unauthorized-uri as captured in the session, which is only ever set if the user previously requested a resource for which they were not authorized (see https://github.com/cemerick/friend/blob/master/src/cemerick/friend.clj#L200), or (b) redirect to the value of ::redirect-on-auth? if it is a string, or (c) redirect to the :default-landing-url specified in the configuration provided to `authenticate`. You're right that (b) will never be the case for the interactive-form workflow, fundamentally because `cemerick.friend.workflows/make-auth` merges the `auth-meta` defaults in last, rather than first. That's a valid point of enhancement; ticket/patch welcome. :-) Note that ::redirect-on-auth? _is_ poorly named: it was originally expected to only be a boolean, thus the '?'. Its name will need to change in the future to reflect its actual role. - 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: clojure.org requires more clicks now
Hello Stuart, Thank you for your prompt reply. It would be nice if the Documentation link in the left-side column could expand into a list of sub-sections, but I don't know if the technology behind the site (Wikispaces) can support that right now. That would be very nice, indeed. The software used before the change showed all sub-sections. Thank you for trying to show them again. Good luck with it! felt that the site was getting cluttered with too many links, which was confusing to newcomers. I agree, that cluttering up a site is bad and confusing. On the other hand I think, nothing is more clarifying, i.e. deconfusing, than documentation. So finding and navigating through it should be as easy and fast as possible. I know that the following is a minority opinion: But this attention to newcomers is, albeit very honourable and of course economically necessary, bad. There is no easy path to anything that has depth. It is the duty of an apprentice to work hard to get what he desires. It is not the duty of the beauty, clojure in this case, to attract. Beauty generates attraction all by itself. As clojure does. Thanks again ! Heinz. -- 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.org requires more clicks now
P.S.: the compatibility shim for 0.1.x API functions were 2 days late. Already upgraded to the new API. Had I just waited 48 hours... ;-) -- 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.org requires more clicks now
2012/10/29 raschedh rasche...@gmail.com I know that the following is a minority opinion: But this attention to newcomers is, albeit very honourable and of course economically necessary, bad. If growing the community and making it possible for more people to use Clojure at work, school or anywhere they want is bad, then yes, attention to newcomers is terrible. If the community wants to grow and see Clojure adopted more, it *must* make sure newcomers have pretty good time. This includes many things, taking care of clojure.org so that it is useful to newcomers is one of them. -- 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
Re: with-open and line-seq
On Friday, October 26, 2012 11:11:48 PM UTC-4, daveray wrote: I guess I looking for a magical line-seq that closes the file correctly even if you consume part of the sequence, is resilient to exceptions, etc, etc. I realize that it might be impossible, so I asked. :) It's been discussed extensively in the past, but no one has come up with a solution that adequately solves the general problem. See http://dev.clojure.org/display/design/Resource+Scopes for examples of some attempts. The best approach I've found is to manage resources like files farther up the stack. Instead of having a 'with-open' block that returns a sequence, put the 'with-open' block at a higher level, so that it encompasses the entire scope in which the file will be used. -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: clojure.org requires more clicks now
Ah. I don't wanna go into flames here. And I *said*, I know this is the opinion of the majority. So relax. Nobody cares about what I think about this. Nobody is going to change anything, because of me. All I wanted to say is that this formulation: make sure newcomers have pretty good time. is *exactly* what I think is bad. If you want to have `a pretty good time', go to the movies. Or kiss a girl. Or drink lots of beer. And then kiss a lot of girls. When I am given a hard time about something I really love doing, then I enjoy myself *so* much. I *love* having a hard time. It makes be better, faster, stronger. That is where I enjoy myself the most. I do not want motivation. I have plenty of it. I want information. My mind paints it, then. And only from reading that, it is clear, how minor this minority is, that thinks that way. Ah. I don't want to go into things like this. I am just too Deutsch. ;-) Heinz. -- 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
On Sunday, October 28, 2012 8:14:41 PM UTC, Chas Emerick wrote: On Oct 28, 2012, at 2:57 PM, Patrik Sundberg wrote: I've looked at this for a bit now. It seems there are some slight inconsistencies in how the redirect info is used: Where the redirect-on-autth? is being set up for the interactive-form workflow it looks to me to be assumed to be a boolean flag. https://github.com/sundbp/friend/blob/master/src/cemerick/friend/workflows.clj#L79 At that point it's given as an argument when setting up the workflow (defaulting to true). Then when it's being used in the generic code it's first picked out - looking like boolean flag still: https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L145 but then all of a sudden assumed to be a string containing the url to redirect to: https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L149 Given that, for the interactive-form workflow, it can only be set at the time of creating the workflow, it seems impossible to actually achieve the flow where friend remembers which page under authentication that user tried to access, then do auth, and finally return user to the originally requested page in a dynamic fashion. Since given at workflow creation time it can't dynamically reflect things properly I'd have assumed. I'd have expected it to not be an argument at workflow creation time, but the originally requested url being dynamically kept track of at the point friend realizes it needs to redirect the user to do authentication, then that url being used on L149 up there when the workflow sets redirect-on-auth? to true. Am I misunderstanding the flow or is there a mixup here? The tests only tests for boolean state, not as a string url. You're misunderstanding. If ::redirect-on-auth? is any truthy value (which includes strings), then `redirect-new-auth` will either: (a) send a redirect to the ::unauthorized-uri as captured in the session, which is only ever set if the user previously requested a resource for which they were not authorized (see https://github.com/cemerick/friend/blob/master/src/cemerick/friend.clj#L200), or (b) redirect to the value of ::redirect-on-auth? if it is a string, or (c) redirect to the :default-landing-url specified in the configuration provided to `authenticate`. You're right that (b) will never be the case for the interactive-form workflow, fundamentally because `cemerick.friend.workflows/make-auth` merges the `auth-meta` defaults in last, rather than first. That's a valid point of enhancement; ticket/patch welcome. :-) Note that ::redirect-on-auth? _is_ poorly named: it was originally expected to only be a boolean, thus the '?'. Its name will need to change in the future to reflect its actual role. Ok - I think that's actually what my understanding was :) It just seemed that in the existing workflows if it is stringy (assume make-auth patched although I didn't quite get that yet) it is a fixed string rather than a dynamic value of the url user tried to access. I.e. I can give /foo as redirect-on-auth? when setting up the interactive-form workflow, but that's then a fixed url to redirecct to. To redirect to whatever page the user tried to access I'd have thought we need store it away from the original request before we go into the auth process, to later redirect back to it once successfully authenticated. Patrik -- 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.org requires more clicks now
And these kids in school, and these people at work, you refer to: My argument is this: Those that come to clojure by themselves, because they can not help. Because they are so occupied with computers, so occupied with mastering everything, because they can not stop looking for beauty. They won't be stopped by anything. And it will be their programs, that I want to use. It will be their programs that will be beautiful. Like clojure. There is too much software. Heinz. -- 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 Clojure documentation site (CDS) progress report for the week of October 28th, 2012
## TL;DR The Clojure documentation project (http://clojure-doc.org) continues to make progress. Lion's share of the work this week went into the Concurrency and Parallelism guide: http://clojure-doc.org/articles/language/concurrency_and_parallelism.html which is now about 75% complete. ## CDS Progress Report The Clojure Documentation Site (a.k.a. CDS) publishes periodic reports (every week so far, possibly two weeks in the future) to give the Clojure community a better idea of what CDS shapes up to be and what it has to offer. This is a report for the week ending October 28st, 2012. ## New Content This week was all improvements to existing guides, no new content merged. There is at least one new tutorial in the works by a contributor we've heard from, though. ## Updates By far most of the work merged this week went into the Concurrency and Parallelism guide [1] It now covers topics such as * An overview of concurrency terminology and common hazards * Identity/Value separation in Clojure * atoms * agents * refs, STM in Clojure, STM limitations * vars * delays * futures * promises * dereferencing * some commonly used `java.util.concurrent` bits * other approaches to concurrency on the JVM available to Clojure through libraries Reading that guide is highly recommended for developers of all expertise levels with the language. Tutorials updated this week: * Getting Started With Emacs for Clojure [2] Other guides updated this week: * Functions [3] * clojure.core Overview [4] * Interoperability with Java [5] * Community [6] ## Thank You, Contributors CDS would not be possible without the following people who make Clojure community a better place: * AtKaaZ * Ben Poweski * John Gabriele * Lee Hinman * Michael S. Klishin * Wes Freeman ## You Can Help! ### How It Works We have a repository on GitHub [7] that has Markdown files, toolchain setup instructions and several articles as well as stubs for several more articles. The stubs help contributors pick a topic to write about and not worry too much about article structure initially. Just pick something that you are very familiar with or interested in and write. When you are done, submit a pull request on GitHub and someone from the existing contributors team will suggest improvements or merge your work. Pretty straightforward. In order to make it easier for potential contributors to join the project, we will post a brief list of guides that do not require deep expertise and can benefit from contributions by complete beginners. ### Existing Guides Tutorials that badly need to be written: * Tutorial on VimClojure [8] Guides that have structure and good chunk of the content in place but still have holes you can help us plug: * Java interop [5] * Collections and Sequences [9] * Namespaces [10] * clojure.core Overview [11] These guides are new and cover advanced topics, so we need as much proof-reading as we can get from the community: * Concurrency and Parallelism in Clojure [1] ### New Content If you want to start working on one of those articles or have existing content you've authored that can be ported, please let us know on the Clojure mailing list. ## Summary CDS is 2-3 guides from covering the language reasonably well. There still are holes in various guides but mostly in the more advanced areas and Want to help us make things better? Join us by forking and contributing to http://github.com/clojuredocs/cds. 1. http://clojure-doc.org/articles/language/concurrency_and_parallelism.html 2. http://clojure-doc.org/articles/tutorials/emacs.html 3. http://clojure-doc.org/articles/language/functions.html 4. http://clojure-doc.org/articles/language/core_overview.html 5. http://clojure-doc.org/articles/language/interop.html 6. http://clojure-doc.org/articles/ecosystem/community.html 7. http://github.com/clojuredocs/cds 8. http://clojure-doc.org/articles/tutorials/vim.html 9. http://clojure-doc.org/articles/language/sequences.html 10. http://clojure-doc.org/articles/language/namespaces.html 11. http://clojure-doc.org/articles/language/core_overview.html -- 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
Re: clojure.org requires more clicks now
2012/10/29 raschedh rasche...@gmail.com My argument is this: Those that come to clojure by themselves, because they can not help. Because they are so occupied with computers, so occupied with mastering everything, because they can not stop looking for beauty. They won't be stopped by anything. Sorry but this is absolutely ridiculous. I know quite a few people who are interested in what Clojure has to offer but find it really hard to get in, not because of the language but because of the way Clojure documentation and tools are (experts-oriented). Some of them have given up, at least for a while. And this is not their fault. -- 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
Re: clojure.org requires more clicks now
Sorry but this is absolutely ridiculous. I know quite a few people who are interested in what Clojure has to offer but find it really hard to get in, not because of the language but because of the way Clojure documentation and tools are (experts-oriented). Some of them have given up, at least for a while. And this is not their fault. It took me three attempts with clojure. It took me eight attempts with scheme/common-lisp. So I failed seven times. But I never thought, that it was the fault of others. It was mine and mine alone. I wasn't ready for it. So I did other things. I came back. And then it worked. If you do not come back, you do not want it enough. This may sound harsh or very much self absorbed. But not `ridiculous'. I think clojure's documentation is excellent. But I read and reread it hundreds of times. Besides the beautiful clojure.contrib stuff, I see no need for other tools. But of course, you need to use a descent text editor and learn it well. And you need to use a cmdline and learn it well. And you need to have a lot of Java and JVM experience. And all that takes a lifetime. And I am still a novice. -- 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.org requires more clicks now
On Sunday, October 28, 2012 6:16:12 PM UTC-4, raschedh wrote: ... If you do not come back, you do not want it enough. ... Then a few extra clicks on the homepage shouldn't deter you. Sorry, couldn't resist :-) Vinod -- 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: with-open and line-seq
Stuart, Thanks for the link. It confirms the suspicions I had about a general solution for this issue. For the particular code I'm working with, I'll try pushing with-open further up and see if that gives me some of the flexibility I'm looking for. Cheers, Dave On Sun, Oct 28, 2012 at 2:21 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Friday, October 26, 2012 11:11:48 PM UTC-4, daveray wrote: I guess I looking for a magical line-seq that closes the file correctly even if you consume part of the sequence, is resilient to exceptions, etc, etc. I realize that it might be impossible, so I asked. :) It's been discussed extensively in the past, but no one has come up with a solution that adequately solves the general problem. See http://dev.clojure.org/display/design/Resource+Scopes for examples of some attempts. The best approach I've found is to manage resources like files farther up the stack. Instead of having a 'with-open' block that returns a sequence, put the 'with-open' block at a higher level, so that it encompasses the entire scope in which the file will be used. -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
