Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Saturday, July 18, 2015 at 5:44:29 PM UTC+2, Luc wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) Comments like that are often linked as an expample of Functional Programmers attitude. Let's not do that. I beleive that talking things out is the only way to improve in cases like that. But it can be only achieved through civil and equal discussion without any attempts to undermine authority of each other. Let's try to do that, I beleive people in the clojure community can do that easily. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Many people feel this way, but ultimately Clojure is Rich's project and I guess Cognitect's to some extent. If they don't want to run it like other more open contribution-friendly OSS projects this is obviously their right. Similar concern and attitude caused apearence of io.js. Do we want similar situation in this community? -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.8.0-alpha2
Hey Alex, Looks terrific, thank you! Particularly excited about CLJ-703 and tuples. Quick question: are tuples intended to implement :kv-reduce? Currently (with 1.8.0-alpha2): (reduce-kv (fn [acc idx in] acc) nil [1 2 3 4 5 6 7]) ; = nil (reduce-kv (fn [acc idx in] acc) nil [1 2]) ;; = No implementation of method: :kv-reduce of protocol: ;; #'clojure.core.protocols/IKVReduce found for class: clojure.lang.Tuple$T2 Cheers :-) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Agent order of message processing
I've been working with agents and it looked like messages are often processed in the reverse of the order received. I checked http://clojure.org/agents and confirmed that Actions dispatched to an agent from another single agent or thread will occur in the order they were sent, potentially interleaved with actions dispatched to the same agent from other sources. So I looked in Agent.java at github.com/clojure/clojure and found that incoming messages were stacked rather than queued. Is this a documentation bug? -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Agent order of message processing
Oh, I could be all wet about the code. It is probably a ring being used to create an immutable queue. I'm going to need to think about that some more. Not sure at all why my tests are showing old values being returned after an update. Some volatile issue? I've got some cheats in my code that I thought would be ok. :-( -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Sunday, 19 July 2015 00:03:04 UTC+8, Andy Fingerhut wrote: I don't think the tweets you link are the 'normal approach'. I would call them pretty unusual in several aspects. For one, I think that for the vast majority of Clojure tickets created, no on asks and gets Rich's comments on them before they are created. Second, most end up being committed as the submitter created them, with fewer rounds of review and updates. Most of them are a lot less work on the part of the contributor than the two examples mentioned. Note: I am not saying that those two examples didn't happen, or that there are no others like that. I am saying they are unusual examples, as compared to the great majority of Clojure tickets. Most tickets that have a change committed for them end up being committed as a patch submitted by a contributor, without being implemented differently. It is fairly common for there to be months or years of waiting time for a ticket to be considered. Rich is one person, and like most people, he gets to choose how much time he spends on volunteer projects, and what projects those are. Alex Miller spends a significant fraction of his time tending to tickets and commenting on and reviewing patches. This point (i.e. lead time) is by far my biggest gripe about the Clojure contribution process. It causes a number of problems: A) Contributors get de-motivated waiting for feedback / communication B) Patches often become stale. This wastes more time C) People forget what they were thinking about months or years ago D) Improvements take too long to get into Clojure (Zach's CLJ-1517 case is a good example) E) It creates the perception (even if it is not the reality?) that Clojure is unfriendly to contributors My practical suggestion is simple: Clojure needs more trusted maintainers who know particular parts of Clojure well and can work more closely with contributors to get patches in a good state for Rich to review, and potentially even merge the simpler types of changes (bug fixes, documentation updates, basic refactoring, indentation etc.). Rich's time can then be spent on the high value stuff (reviewing good quality patches only when they are ready in the view of the trusted maintainer, considering changes which impact language design etc.). FWIW It's worth comparing the rate of development on Clojure vs. Linux: Clojure: https://github.com/clojure/clojure/graphs/commit-activity (10 commits per week) Linux: https://github.com/torvalds/linux/graphs/commit-activity (500-1500 commits per week) Obviously Linux is a bigger project, but there is still only one BDFL in both cases (and I am sure both BDFLs are very busy!) So how does Linus do it? The answer is organisation. Linux has many trusted subsystem maintainers who do most of the work reviewing and merging patches. Linus may have the final say on everything but the Linux community has done a lot of thinking and self-organisation to make sure that Linus is not usually the bottleneck. Also worth noting that Linus does indeed use pull requests (just not GitHub ones, see the extended discussion here if interested: https://github.com/torvalds/linux/pull/17#issuecomment-5654674 ). Not saying Rich has to do so himself, but the trusted maintainers would be able to do so if it helped with the workflow for work-in-progress patches. As for indentation of Java code, it is called Whitesmiths style: https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style Clojure was the first project I came across using this indentation style, but Rich isn't the only one to use it. A few bits of code have crept in over the years using other indentation styles, usually contributed by others. Andy On Sat, Jul 18, 2015 at 4:13 AM, Andrey Antukh ni...@niwi.nz javascript: wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation:
Re: [ANN] Clojure 1.8.0-alpha2
Are tuples used for small maps as well? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Your comments are one-sided. When I modify code written by others, I follow their style. I do not complain about their code formatting habits. I wrote/modified enough code in 30 years written by hundreds of individuals to find emphasis on code formatting and variable naming a waste of time and effort. If the code structure is good essentially it's maintainable. I answered a recurring subject of low-level importance wrapped in some humorous wording to try to pass under the political correctness radar that will eventually kill humanity. It does not please you ? Let the OP comment on this, it was not addressed to you personally. Just zap. He can rant on me on this mailing list, I will not whine about it. I'm made though. Kumbaya... Sent from my iPhone On Jul 19, 2015, at 04:21, Max Gonzih gon...@gmail.com wrote: On Saturday, July 18, 2015 at 5:44:29 PM UTC+2, Luc wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) Comments like that are often linked as an expample of Functional Programmers attitude. Let's not do that. I beleive that talking things out is the only way to improve in cases like that. But it can be only achieved through civil and equal discussion without any attempts to undermine authority of each other. Let's try to do that, I beleive people in the clojure community can do that easily. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
I agree with you but changes like this need time to bloom and are motivated by increased pressure to release. We have been seeing more of that in the last year. Linus did not find solid maintainers day one. You need to test drive individuals before you can delegate significant chunks and not worry about the minute details and just review work at the end of the pipeline. By now such people should be identified in the community. It's kind of an internal Cognitec subject but some public statement looks to me inevitable :) Alex ? Sent from my iPhone On Jul 19, 2015, at 02:21, Mikera mike.r.anderson...@gmail.com wrote: On Sunday, 19 July 2015 00:03:04 UTC+8, Andy Fingerhut wrote: I don't think the tweets you link are the 'normal approach'. I would call them pretty unusual in several aspects. For one, I think that for the vast majority of Clojure tickets created, no on asks and gets Rich's comments on them before they are created. Second, most end up being committed as the submitter created them, with fewer rounds of review and updates. Most of them are a lot less work on the part of the contributor than the two examples mentioned. Note: I am not saying that those two examples didn't happen, or that there are no others like that. I am saying they are unusual examples, as compared to the great majority of Clojure tickets. Most tickets that have a change committed for them end up being committed as a patch submitted by a contributor, without being implemented differently. It is fairly common for there to be months or years of waiting time for a ticket to be considered. Rich is one person, and like most people, he gets to choose how much time he spends on volunteer projects, and what projects those are. Alex Miller spends a significant fraction of his time tending to tickets and commenting on and reviewing patches. This point (i.e. lead time) is by far my biggest gripe about the Clojure contribution process. It causes a number of problems: A) Contributors get de-motivated waiting for feedback / communication B) Patches often become stale. This wastes more time C) People forget what they were thinking about months or years ago D) Improvements take too long to get into Clojure (Zach's CLJ-1517 case is a good example) E) It creates the perception (even if it is not the reality?) that Clojure is unfriendly to contributors My practical suggestion is simple: Clojure needs more trusted maintainers who know particular parts of Clojure well and can work more closely with contributors to get patches in a good state for Rich to review, and potentially even merge the simpler types of changes (bug fixes, documentation updates, basic refactoring, indentation etc.). Rich's time can then be spent on the high value stuff (reviewing good quality patches only when they are ready in the view of the trusted maintainer, considering changes which impact language design etc.). FWIW It's worth comparing the rate of development on Clojure vs. Linux: Clojure: https://github.com/clojure/clojure/graphs/commit-activity (10 commits per week) Linux: https://github.com/torvalds/linux/graphs/commit-activity (500-1500 commits per week) Obviously Linux is a bigger project, but there is still only one BDFL in both cases (and I am sure both BDFLs are very busy!) So how does Linus do it? The answer is organisation. Linux has many trusted subsystem maintainers who do most of the work reviewing and merging patches. Linus may have the final say on everything but the Linux community has done a lot of thinking and self-organisation to make sure that Linus is not usually the bottleneck. Also worth noting that Linus does indeed use pull requests (just not GitHub ones, see the extended discussion here if interested: https://github.com/torvalds/linux/pull/17#issuecomment-5654674 ). Not saying Rich has to do so himself, but the trusted maintainers would be able to do so if it helped with the workflow for work-in-progress patches. As for indentation of Java code, it is called Whitesmiths style: https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style Clojure was the first project I came across using this indentation style, but Rich isn't the only one to use it. A few bits of code have crept in over the years using other indentation styles, usually contributed by others. Andy On Sat, Jul 18, 2015 at 4:13 AM, Andrey Antukh ni...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little
Re: Agent order of message processing
The code for actor looks very different this morning. Obviously an immutable queue is being used. On Sunday, July 19, 2015 at 2:12:43 AM UTC-4, William la Forge wrote: I've been working with agents and it looked like messages are often processed in the reverse of the order received. I checked http://clojure.org/agents and confirmed that Actions dispatched to an agent from another single agent or thread will occur in the order they were sent, potentially interleaved with actions dispatched to the same agent from other sources. So I looked in Agent.java at github.com/clojure/clojure and found that incoming messages were stacked rather than queued. Is this a documentation bug? -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [:ann :book] ClojureScript Unraveled
I'm a Clojure beginner and wanted to compliment the authors on a very clear yet concise text. Thank you. Aria Media Sagl Via Rompada 40 6987 Caslano Switzerland +41 (0)91 600 9601 +41 (0)76 303 4477 cell skype: ariamedia On Fri, Jul 17, 2015 at 7:30 PM, Alejandro Gómez alejan...@dialelo.com wrote: Hello everybody, I'm happy to announce that Andrey Antoukh (@niwinz) and I published the book about ClojureScript that we have been writing lately on Leanpub. It's not still 100% complete but the sections about the language and compiler are almost done. We'd greatly appreciate any feedback, errata or suggestions for the book. It is an open source book licensed under a Creative Commons BY-SA license and will forever remain free and open to community participation. Publishing it on Leanpub is a convenient way for readers to be notified whenever a new release comes out and not to go through the process of generating the book themselves. If you feel like it and can afford it you can make a donation and buy us a beer too! - Leanpub: https://leanpub.com/clojurescript-unraveled - GitHub repository: https://github.com/funcool/clojurescript-unraveled - HTML version: http://funcool.github.io/clojurescript-unraveled/ Yours, Alejandro -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 19:54, Luc Préfontaine lprefonta...@softaddicts.ca wrote: My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I think everyone in this community should aspire to more than I'm not as rude as Linus. There's nothing that makes me shiver more than political correctness. Political correctness has nothing to do with remaining civil in a discussion. On Jul 18, 2015, at 13:32, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this
Re: [ANN] Clojure 1.8.0-alpha2
Seems like a bug to me. On Sunday, July 19, 2015 at 3:10:37 AM UTC-5, Peter Taoussanis wrote: Hey Alex, Looks terrific, thank you! Particularly excited about CLJ-703 and tuples. Quick question: are tuples intended to implement :kv-reduce? Currently (with 1.8.0-alpha2): (reduce-kv (fn [acc idx in] acc) nil [1 2 3 4 5 6 7]) ; = nil (reduce-kv (fn [acc idx in] acc) nil [1 2]) ;; = No implementation of method: :kv-reduce of protocol: ;; #'clojure.core.protocols/IKVReduce found for class: clojure.lang.Tuple$T2 Cheers :-) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Sunday, July 19, 2015 at 7:02:43 AM UTC-5, Luc wrote: I agree with you but changes like this need time to bloom and are motivated by increased pressure to release. We have been seeing more of that in the last year. Linus did not find solid maintainers day one. You need to test drive individuals before you can delegate significant chunks and not worry about the minute details and just review work at the end of the pipeline. By now such people should be identified in the community. It's kind of an internal Cognitect subject but some public statement looks to me inevitable :) Alex ? There are no plans to change this aspect of the process at this time. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: roundtripping using data.xml?
Matching socks and Herwig, thanks for your answers. https://github.com/bendlas/data.xml works for roundtripping the data. Currently using raw-parsing and raw-emit. Great work, hope it will be accepted into master eventually. On Tue, Jun 23, 2015 at 1:56 PM Herwig Hochleitner hhochleit...@gmail.com wrote: Matching Socks, thanks for mentioning the design page I created. I haven't pushed anything recently, but I'm still working on the rewrite implementing the proposal: https://github.com/bendlas/data.xml I've also made a library, that uses a snapshot from my rewrite to implement a WebDAV server: https://github.com/bendlas/davstore/blob/master/src/davstore/dav.clj I'm now in the process of simplifying my data.xml rewrite based on experience with the library. E.g. I intend to drop the raw mode described in the design page and instead make it possible to transduce the event stream in order to implement such modes. If you are thinking about rolling your own xml processing, please also consider joing efforts on data.xml. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [:ann :book] ClojureScript Unraveled
We just released the second revision which includes a lot of corrections, an Acknowledgments section and an almost finished chapter about CSP core.async which covers all its API and introduces the CSP concepts. - Leanpub: https://leanpub.com/clojurescript-unraveled - GitHub repository: https://github.com/funcool/clojurescript-unraveled - HTML version: http://funcool.github.io/clojurescript-unraveled/ On Sun, Jul 19, 2015, at 14:51, Nando Breiter wrote: I'm a Clojure beginner and wanted to compliment the authors on a very clear yet concise text. Thank you. Thanks a lot, any feedback will be greatly appreciated since one of the goals of the project is to make ClojureScript accesible to newcomers. Aria Media Sagl Via Rompada 40 6987 Caslano Switzerland +41 (0)91 600 9601 +41 (0)76 303 4477 cell skype: ariamedia On Fri, Jul 17, 2015 at 7:30 PM, Alejandro Gómez alejan...@dialelo.com wrote: Hello everybody, I'm happy to announce that Andrey Antoukh (@niwinz) and I published the book about ClojureScript that we have been writing lately on Leanpub. It's not still 100% complete but the sections about the language and compiler are almost done. We'd greatly appreciate any feedback, errata or suggestions for the book. It is an open source book licensed under a Creative Commons BY-SA license and will forever remain free and open to community participation. Publishing it on Leanpub is a convenient way for readers to be notified whenever a new release comes out and not to go through the process of generating the book themselves. If you feel like it and can afford it you can make a donation and buy us a beer too! - Leanpub: https://leanpub.com/clojurescript-unraveled - GitHub repository: https://github.com/funcool/clojurescript-unraveled - HTML version: http://funcool.github.io/clojurescript-unraveled/ Yours, Alejandro -- 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[1] 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com[2]. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. Links: 1. mailto:clojure%2bunsubscr...@googlegroups.com 2. mailto:clojure%2bunsubscr...@googlegroups.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Building Falcor/Relay/... for Clojure Clojurescript
Hi everyone, In a recent talk, David Nolen talks about a great idea for Om Next, where components declaratively describe what data they’re interested in. [omnext] I’d like to explore the optional server-side router part. The idea is that you write your code on the front-end as if you have *all* the data; then, in the background, you download just enough data to do it. This idea has also been explored by Facebook with Relay, and Netflix with Falcor. Since David suggested using Datomic pull syntax to describe what data you’re interested in, Datascript was my first port of call. The author of Datascript has also written a superb article on exactly this topic. [webtmrw] Falcor has it easier, though; because it solves a very specific problem. It does asynchronous access for strictly hierarchical model objects whose schema is known completely ahead of time, and without any querying capabilities like Datascript’s. The challenge is that Datascript is really just a bunch of tuples in a few sorted sets. [dsint] We’re trying to teach it about data that *doesn’t* live there. While Datascript makes it easy to write additional backends (IDB, ISearch, IIndexAccess), those APIs are synchronous, so I can’t do much in the browser. The obvious piece of data to ferry around is the datom; the hard part is: 1. knowing if there’s datoms you don’t know about, but live on the server, 2. as the server, knowing which datoms are relevant. One approach might be to just run queries on the server as well as on the client. Another is to add “hints” that there’s some data here, but you just don’t know what it is. (The problem is that the latter breaks pretty easily; it’s not like you can do range queries on `:go-ask-the-server`…) Finally, there’s backing this data with, say, a legacy REST API or something. That’s fine as long as you do it on the server, because the blocking restriction goes away. Due to my relative inexperience with Datascript/Datomic, I wanted to reach out to the mailing list before continuing. Is anyone else working on something similar? Good results, dead ends? [omnext]: https://www.youtube.com/watch?v=ByNs9TG30E8 [webtmrw]: http://tonsky.me/blog/the-web-after-tomorrow/ [dsint]: http://tonsky.me/blog/datascript-internals/ hth lvh -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [ANN] Clojure 1.8.0-alpha2
(It looks like you're depending on Potemkin through clj-http, so upgrading to clj-http 2.0.0 will also solve the problem) On Sun, Jul 19, 2015 at 4:53 PM Michael Blume blume.m...@gmail.com wrote: Looks like it has, pinning to Potemkin 0.4.1 should probably sort you out On Sun, Jul 19, 2015 at 4:50 PM Michael Blume blume.m...@gmail.com wrote: Sean, I think that was identified as a bug in Potemkin. The pull was merged but I'm not sure if there's been a release since. Zack? https://github.com/ztellman/potemkin/pull/40 http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632 On Sun, Jul 19, 2015 at 4:47 PM Sean Corfield s...@corfield.org wrote: On Jul 18, 2015, at 10:33 PM, Sean Corfield s...@corfield.org wrote: Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this week. We may go to production with it fairly quickly. Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting here in case anyone knows immediately what the cause is, while I go debugging... Exception in thread main java.lang.NoClassDefFoundError: IllegalName: compile__stub.clj_http.headers.clj-http.headers/HeaderMap, compiling:(clj_http/headers.clj:105:1) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.eval(Compiler.java:6847) at clojure.lang.Compiler.eval(Compiler.java:6839) at clojure.lang.Compiler.load(Compiler.java:7295) at clojure.lang.RT.loadResourceScript(RT.java:372) at clojure.lang.RT.loadResourceScript(RT.java:363) at clojure.lang.RT.load(RT.java:453) at clojure.lang.RT.load(RT.java:419) at clojure.core$load$fn__5448.invoke(core.clj:5866) at clojure.core$load.doInvoke(core.clj:5865) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5671) at clojure.core$load_lib$fn__5397.invoke(core.clj:5711) at clojure.core$load_lib.doInvoke(core.clj:5710) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:632) at clojure.core$load_libs.doInvoke(core.clj:5749) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:632) at clojure.core$require.doInvoke(core.clj:5832) at clojure.lang.RestFn.invoke(RestFn.java:482) at clj_http.core$eval855$loading__5340__auto856.invoke(core.clj:1) at clj_http.core$eval855.invoke(core.clj:1) Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.8.0-alpha2
Is this a good candidate area for adding generative tests? It seems like they may have been able to catch this regression. On Mon, Jul 20, 2015 at 1:40 AM Alex Miller a...@puredanger.com wrote: Seems like a bug to me. On Sunday, July 19, 2015 at 3:10:37 AM UTC-5, Peter Taoussanis wrote: Hey Alex, Looks terrific, thank you! Particularly excited about CLJ-703 and tuples. Quick question: are tuples intended to implement :kv-reduce? Currently (with 1.8.0-alpha2): (reduce-kv (fn [acc idx in] acc) nil [1 2 3 4 5 6 7]) ; = nil (reduce-kv (fn [acc idx in] acc) nil [1 2]) ;; = No implementation of method: :kv-reduce of protocol: ;; #'clojure.core.protocols/IKVReduce found for class: clojure.lang.Tuple$T2 Cheers :-) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- Daniel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.8.0-alpha2
Sean, I think that was identified as a bug in Potemkin. The pull was merged but I'm not sure if there's been a release since. Zack? https://github.com/ztellman/potemkin/pull/40 http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632 On Sun, Jul 19, 2015 at 4:47 PM Sean Corfield s...@corfield.org wrote: On Jul 18, 2015, at 10:33 PM, Sean Corfield s...@corfield.org wrote: Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this week. We may go to production with it fairly quickly. Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting here in case anyone knows immediately what the cause is, while I go debugging... Exception in thread main java.lang.NoClassDefFoundError: IllegalName: compile__stub.clj_http.headers.clj-http.headers/HeaderMap, compiling:(clj_http/headers.clj:105:1) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.eval(Compiler.java:6847) at clojure.lang.Compiler.eval(Compiler.java:6839) at clojure.lang.Compiler.load(Compiler.java:7295) at clojure.lang.RT.loadResourceScript(RT.java:372) at clojure.lang.RT.loadResourceScript(RT.java:363) at clojure.lang.RT.load(RT.java:453) at clojure.lang.RT.load(RT.java:419) at clojure.core$load$fn__5448.invoke(core.clj:5866) at clojure.core$load.doInvoke(core.clj:5865) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5671) at clojure.core$load_lib$fn__5397.invoke(core.clj:5711) at clojure.core$load_lib.doInvoke(core.clj:5710) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:632) at clojure.core$load_libs.doInvoke(core.clj:5749) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:632) at clojure.core$require.doInvoke(core.clj:5832) at clojure.lang.RestFn.invoke(RestFn.java:482) at clj_http.core$eval855$loading__5340__auto856.invoke(core.clj:1) at clj_http.core$eval855.invoke(core.clj:1) Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.8.0-alpha2
Bumping clj-http to 2.0.0 got me past that problem (and it uses Potemkin 0.4.1) but then I hit the problem below, which I’ve run into several times trying to use updated versions of clj-http over the last year. Message java.lang.RuntimeException: No such var: clj-tuple/vector, compiling:(potemkin/utils.clj:110:10) Cause clojure.lang.Compiler$CompilerException Stacktrace The Error Occurred in core.clj: line 5866 called from core.clj: line 5865 called from core.clj: line 5671 called from core.clj: line 5711 called from core.clj: line 5710 called from core.clj: line 632 called from core.clj: line 5753 called from core.clj: line 634 called from core.clj: line 5843 called from collections.clj: line 1 called from collections.clj: line 1 called from core.clj: line 5866 called from core.clj: line 5865 called from core.clj: line 5671 called from core.clj: line 5711 called from core.clj: line 5710 called from core.clj: line 632 called from core.clj: line 5753 called from core.clj: line 632 called from core.clj: line 5832 called from potemkin.clj: line 1 called from potemkin.clj: line 1 called from core.clj: line 5866 called from core.clj: line 5865 called from core.clj: line 5671 called from core.clj: line 5711 called from core.clj: line 5710 called from core.clj: line 632 called from core.clj: line 5749 called from core.clj: line 632 called from core.clj: line 5832 called from headers.clj: line 1 called from headers.clj: line 1 called from core.clj: line 5866 called from core.clj: line 5865 called from core.clj: line 5671 called from core.clj: line 5711 called from core.clj: line 5710 called from core.clj: line 632 called from core.clj: line 5749 called from core.clj: line 632 called from core.clj: line 5832 called from core.clj: line 1 called from core.clj: line 1 called from core.clj: line 5866 called from core.clj: line 5865 called from core.clj: line 5671 called from core.clj: line 5711 called from core.clj: line 5710 called from core.clj: line 632 called from core.clj: line 5749 called from core.clj: line 632 called from core.clj: line 5832 called from client.clj: line 1 On Jul 19, 2015, at 4:53 PM, Michael Blume blume.m...@gmail.com wrote: Looks like it has, pinning to Potemkin 0.4.1 should probably sort you out On Sun, Jul 19, 2015 at 4:50 PM Michael Blume blume.m...@gmail.com mailto:blume.m...@gmail.com wrote: Sean, I think that was identified as a bug in Potemkin. The pull was merged but I'm not sure if there's been a release since. Zack? https://github.com/ztellman/potemkin/pull/40 https://github.com/ztellman/potemkin/pull/40 http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632 http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632 On Sun, Jul 19, 2015 at 4:47 PM Sean Corfield s...@corfield.org mailto:s...@corfield.org wrote: On Jul 18, 2015, at 10:33 PM, Sean Corfield s...@corfield.org mailto:s...@corfield.org wrote: Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this week. We may go to production with it fairly quickly. Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting here in case anyone knows immediately what the cause is, while I go debugging... Exception in thread main java.lang.NoClassDefFoundError: IllegalName: compile__stub.clj_http.headers.clj-http.headers/HeaderMap, compiling:(clj_http/headers.clj:105:1) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.eval(Compiler.java:6847) at clojure.lang.Compiler.eval(Compiler.java:6839) at clojure.lang.Compiler.load(Compiler.java:7295) at clojure.lang.RT.loadResourceScript(RT.java:372) at clojure.lang.RT.loadResourceScript(RT.java:363) at clojure.lang.RT.load(RT.java:453) at clojure.lang.RT.load(RT.java:419) at clojure.core$load$fn__5448.invoke(core.clj:5866) at clojure.core$load.doInvoke(core.clj:5865)
[ANN] Afterglow 0.1.0, an open-source live-coding Clojure environment for light shows
I just released version 0.1.0 of Afterglow so that other interested people can start exploring it. I simply cannot believe I have been able to create a system like this in a couple of months, after being inspired by the example of Overtone. Thank you, Clojure community, for making software development so powerful and so much fun again! Interested parties can find the repository here: https://github.com/brunchboy/afterglow From the online manual: Afterglow is a lighting controller designed to support live coding https://en.wikipedia.org/wiki/Live_coding, written in Clojure http://clojure.org/, intended to enable people to produce spectacular and highly customizable light shows using modern stage and effect lighting, and which are related in deep ways to the phrasing of music being played. (Its creator http://deepsymmetry.org/ is a DJ and producer of light and laser shows by avocation.) Currently, the lighting effects https://github.com/brunchboy/afterglow/blob/master/doc/effects.adoc#effects and fixture definitions https://github.com/brunchboy/afterglow/blob/master/doc/fixture_definitions.adoc#fixture-definitions are written and organized through Clojure code, so you will either need to learn Clojure or work with a Clojure programmer to create new ones, but they are controlled through MIDI control surfaces or Open Sound Control, so once they are set up, there is great flexibility in how you can perform them. Someday a user interface for building shows and fixture definitions may be created, either within Afterglow, or as a companion project, but that is not currently planned. For now the focus is on building rich user interfaces for controlling shows, such as the Ableton Push mapping https://github.com/brunchboy/afterglow/blob/master/doc/mapping_sync.adoc#using-ableton-push and web interface https://github.com/brunchboy/afterglow/blob/master/doc/README.adoc#the-embedded-web-interface, while using the concise expressive power of Clojure for writing the fixture definitions, effects, and cues. Afterglow communicates with the lighting hardware using the Open Lighting Architecture https://www.openlighting.org/ola/, so it supports a wide variety of communication methods and interfaces. Information about installing OLA https://github.com/brunchboy/afterglow#installation is included in the project README https://github.com/brunchboy/afterglow. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.8.0-alpha2
On Jul 18, 2015, at 10:33 PM, Sean Corfield s...@corfield.org wrote: Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this week. We may go to production with it fairly quickly. Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting here in case anyone knows immediately what the cause is, while I go debugging... Exception in thread main java.lang.NoClassDefFoundError: IllegalName: compile__stub.clj_http.headers.clj-http.headers/HeaderMap, compiling:(clj_http/headers.clj:105:1) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.eval(Compiler.java:6847) at clojure.lang.Compiler.eval(Compiler.java:6839) at clojure.lang.Compiler.load(Compiler.java:7295) at clojure.lang.RT.loadResourceScript(RT.java:372) at clojure.lang.RT.loadResourceScript(RT.java:363) at clojure.lang.RT.load(RT.java:453) at clojure.lang.RT.load(RT.java:419) at clojure.core$load$fn__5448.invoke(core.clj:5866) at clojure.core$load.doInvoke(core.clj:5865) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5671) at clojure.core$load_lib$fn__5397.invoke(core.clj:5711) at clojure.core$load_lib.doInvoke(core.clj:5710) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:632) at clojure.core$load_libs.doInvoke(core.clj:5749) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:632) at clojure.core$require.doInvoke(core.clj:5832) at clojure.lang.RestFn.invoke(RestFn.java:482) at clj_http.core$eval855$loading__5340__auto856.invoke(core.clj:1) at clj_http.core$eval855.invoke(core.clj:1) Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.8.0-alpha2
Looks like it has, pinning to Potemkin 0.4.1 should probably sort you out On Sun, Jul 19, 2015 at 4:50 PM Michael Blume blume.m...@gmail.com wrote: Sean, I think that was identified as a bug in Potemkin. The pull was merged but I'm not sure if there's been a release since. Zack? https://github.com/ztellman/potemkin/pull/40 http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632 On Sun, Jul 19, 2015 at 4:47 PM Sean Corfield s...@corfield.org wrote: On Jul 18, 2015, at 10:33 PM, Sean Corfield s...@corfield.org wrote: Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this week. We may go to production with it fairly quickly. Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting here in case anyone knows immediately what the cause is, while I go debugging... Exception in thread main java.lang.NoClassDefFoundError: IllegalName: compile__stub.clj_http.headers.clj-http.headers/HeaderMap, compiling:(clj_http/headers.clj:105:1) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.eval(Compiler.java:6847) at clojure.lang.Compiler.eval(Compiler.java:6839) at clojure.lang.Compiler.load(Compiler.java:7295) at clojure.lang.RT.loadResourceScript(RT.java:372) at clojure.lang.RT.loadResourceScript(RT.java:363) at clojure.lang.RT.load(RT.java:453) at clojure.lang.RT.load(RT.java:419) at clojure.core$load$fn__5448.invoke(core.clj:5866) at clojure.core$load.doInvoke(core.clj:5865) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5671) at clojure.core$load_lib$fn__5397.invoke(core.clj:5711) at clojure.core$load_lib.doInvoke(core.clj:5710) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:632) at clojure.core$load_libs.doInvoke(core.clj:5749) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:632) at clojure.core$require.doInvoke(core.clj:5832) at clojure.lang.RestFn.invoke(RestFn.java:482) at clj_http.core$eval855$loading__5340__auto856.invoke(core.clj:1) at clj_http.core$eval855.invoke(core.clj:1) Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Prioritizing the 'good' form over the substance is the first step toward political correctness and lobotomy. Civility is more about form than substance and has various meaning depending on the people involved. You can say horrendous things using a civil tone. It's as unbearable as a crude statement with a lot of bad words. As far as aspiring to be not as rude as Linus, yeah, he's kind of extreme. But becoming a care bear is not on my list of todos. Dying by civilicide either. As far as I know, I did not used obscene words or used bird names toward people. If my kind of humor is not your taste it's a legit critic and I can take it. If you have specific complaints about my tone we can pursue this off list if needed. That's channel is opened for anyone that may need to let steam out. If there's enough interest, I can even start a blog and publish emailed comments/complaints as is and anonymously if asked for. Some are stamp collectors, I could start an original collection of my own. Sent from my iPad On Jul 19, 2015, at 09:36, Colin Fleming colin.mailingl...@gmail.com wrote: On 18 July 2015 at 19:54, Luc Préfontaine lprefonta...@softaddicts.ca wrote: My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I think everyone in this community should aspire to more than I'm not as rude as Linus. There's nothing that makes me shiver more than political correctness. Political correctness has nothing to do with remaining civil in a discussion. On Jul 18, 2015, at 13:32, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my
Re: How to implement a distributed and concurrent system in Clojure?
http://docs.paralleluniverse.co/pulsar/ is out there. I can't say I've used it in anger, but I did enjoy experimenting with it. On Sun, Jul 19, 2015 at 11:24 AM Colin Yates colin.ya...@gmail.com wrote: I don’t have anything to add at that scale, but I wanted to echo Stuart’s comment about the serialisability of EDN. Moving EDN between the front and back tiers on our app has cut down a bunch of boilerplate. That principle can scale across machines as well. On 19 Jul 2015, at 16:54, Stuart Sierra the.stuart.sie...@gmail.com wrote: Absolutely would use again. But I'm biased towards Clojure already. :) –S On Sunday, July 19, 2015 09goral wrote: Thanks Stuart for your answer, it is very helpfull. Would you choose Clojure again ? 2015-07-19 17:13 GMT+02:00 Stuart Sierra: This is an old thread, but it showed up in my Google Groups so I figured I would give an answer. I have worked on fairly large (10-50 machines) distributed systems written entirely in Clojure -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:eduction :performance} Trying to understand when to use eduction
Stuart and Alex, thank you for your replies and recommondations. I take it then that the problem is the seq casting performed in apply and in reduce1. For now the only way to avoid applys seq casting seems to be a hackish .doInvoke call. Kind regards, Leon. On Sunday, July 19, 2015 at 6:34:37 PM UTC+2, Alex Miller wrote: On Sunday, July 19, 2015 at 10:53:25 AM UTC-5, Stuart Sierra wrote: Hi Leon, I think this is an edge case related to how varargs functions are implemented in Clojure. The varargs arity of `max` is implemented with `reduce1`: core.clj line 1088 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/clj/clojure/core.clj#L1088 `reduce1` is a simplified implementation of reduce defined early in clojure.core before the optimized reduction protocols have been loaded: core.clj line 894 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/clj/clojure/core.clj#L894. `reduce1` is implemented in terms of lazy sequences, with support for chunking. So `apply max` defaults to using chunked lazy sequence operations. `map` and `range` both return chunked sequences. `eduction` returns an Iterable, so when you `apply max` on it, it turns the Iterable into a Seq, but it's not a chunked seq. Therefore, it's slightly slower than `apply max` on a chunked seq. seqs on eductions *are* chunked - they will fall into this case during seq: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L524-L525 which produces a chunked sequence over an Iterable. In this case, to ensure you're using the fast-path internal reduce over ` eduction`, you can use `reduce` directly: (reduce max 0 (eduction (map inc) (range 10))) You must provide an init value because `eduction` does not assume the init with first element behavior of sequences. This version, in my informal benchmarking, is the fastest. Lots of functions in clojure.core use `reduce1` in their varargs implementation. Perhaps they could be changed to use the optimized ` reduce`, but this might add a lot of repeated definitions as clojure.core is bootstrapping itself. I'm not sure. For various bootstrapping reasons, this is a hard change. In general, I would not assume that `eduction` is automatically faster than lazy sequences. It will be faster only in the cases where it can use the optimized reduction protocols such as InternalReduce. If the optimized path isn't available, many operations will fall back to lazy sequences for backwards-compatibility. I would suggest using `eduction` only when you *know* you're going to consume the result with `reduce` or `transduce`. As always, test first, and profilers are your friend. :) Use eduction for delayed eager *non-cached* execution. Seqs give you delayed *cached* execution. If you're doing a transformation once, or if the thing you're doing would consume too many resources if cached, then use eduction. If you need to do a transformation once and then use the result multiple times, it's better to use sequence+transducer to get the caching effect and the benefits of reduced allocation during transformation. Chunked seqs are surprisingly fast, particularly when all of the operations in a nested transformation are chunked. However, every new layer adds another set of (chunked) sequence allocation. Eduction or anything transducer-based is going to do no seq allocation and execute as a single eager pass. Generally this means that transducer stuff will win more if the collection source is reducible, if the inputs are large (more input = more win), or if the number of transformations is 1 (more transformations = more wins). –S On Saturday, July 18, 2015 at 9:11:45 AM UTC-4, Leon Grapenthin wrote: My understanding was that if I pass an eduction to a process using reduce, I can save the computer time and space because the per step overhead of lazy sequences is gone and also the entire sequence does not have to reside in memory at once. When I time the difference between (apply max (map inc (range 10))) and (apply max (eduction (map inc) (range 10))), the lazy-seq variant wins. I'd like to understand why, and when eductions should be used instead. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more
Re: #{:eduction :performance} Trying to understand when to use eduction
Hi Leon, I think this is an edge case related to how varargs functions are implemented in Clojure. The varargs arity of `max` is implemented with `reduce1`: core.clj line 1088 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/clj/clojure/core.clj#L1088 `reduce1` is a simplified implementation of reduce defined early in clojure.core before the optimized reduction protocols have been loaded: core.clj line 894 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/clj/clojure/core.clj#L894. `reduce1` is implemented in terms of lazy sequences, with support for chunking. So `apply max` defaults to using chunked lazy sequence operations. `map` and `range` both return chunked sequences. `eduction` returns an Iterable, so when you `apply max` on it, it turns the Iterable into a Seq, but it's not a chunked seq. Therefore, it's slightly slower than `apply max` on a chunked seq. In this case, to ensure you're using the fast-path internal reduce over ` eduction`, you can use `reduce` directly: (reduce max 0 (eduction (map inc) (range 10))) You must provide an init value because `eduction` does not assume the init with first element behavior of sequences. This version, in my informal benchmarking, is the fastest. Lots of functions in clojure.core use `reduce1` in their varargs implementation. Perhaps they could be changed to use the optimized `reduce`, but this might add a lot of repeated definitions as clojure.core is bootstrapping itself. I'm not sure. In general, I would not assume that `eduction` is automatically faster than lazy sequences. It will be faster only in the cases where it can use the optimized reduction protocols such as InternalReduce. If the optimized path isn't available, many operations will fall back to lazy sequences for backwards-compatibility. I would suggest using `eduction` only when you *know* you're going to consume the result with `reduce` or `transduce`. As always, test first, and profilers are your friend. :) –S On Saturday, July 18, 2015 at 9:11:45 AM UTC-4, Leon Grapenthin wrote: My understanding was that if I pass an eduction to a process using reduce, I can save the computer time and space because the per step overhead of lazy sequences is gone and also the entire sequence does not have to reside in memory at once. When I time the difference between (apply max (map inc (range 10))) and (apply max (eduction (map inc) (range 10))), the lazy-seq variant wins. I'd like to understand why, and when eductions should be used instead. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Is there any need to speak with this tone and this arrogance? It's just an attempt to improve things, and I think there is nothing negative about it. I think the initial motivation of this email is change things to be better and with good intentions. It make sense to attack good intentions without any needs? We are all adults and we should all be able to talk about issues in a more calm manner, without arrogance and with understanding. This kind of responses not only discourages participating in clojure development, it also damages the community and completely discourages the participation in this mailing list. Personally, this kind of things discourages me completely from participating in this mailing list. My two cents! Andrey On Sun, Jul 19, 2015 at 5:19 PM, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Prioritizing the 'good' form over the substance is the first step toward political correctness and lobotomy. Civility is more about form than substance and has various meaning depending on the people involved. You can say horrendous things using a civil tone. It's as unbearable as a crude statement with a lot of bad words. As far as aspiring to be not as rude as Linus, yeah, he's kind of extreme. But becoming a care bear is not on my list of todos. Dying by civilicide either. As far as I know, I did not used obscene words or used bird names toward people. If my kind of humor is not your taste it's a legit critic and I can take it. If you have specific complaints about my tone we can pursue this off list if needed. That's channel is opened for anyone that may need to let steam out. If there's enough interest, I can even start a blog and publish emailed comments/complaints as is and anonymously if asked for. Some are stamp collectors, I could start an original collection of my own. Sent from my iPad On Jul 19, 2015, at 09:36, Colin Fleming colin.mailingl...@gmail.com wrote: On 18 July 2015 at 19:54, Luc Préfontaine lprefonta...@softaddicts.ca wrote: My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I think everyone in this community should aspire to more than I'm not as rude as Linus. There's nothing that makes me shiver more than political correctness. Political correctness has nothing to do with remaining civil in a discussion. On Jul 18, 2015, at 13:32, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works
Re: How to implement a distributed and concurrent system in Clojure?
This is an old thread, but it showed up in my Google Groups so I figured I would give an answer. I have worked on fairly large (10-50 machines) distributed systems written entirely in Clojure. The language itself doesn't provide an explicit mechanism for communication between machines, so you just have to pick an existing tool or technique that suits your application architecture. There are many possibilities to choose from, all with different strengths and weaknesses: 1. Direct connections between nodes, e.g. HTTP, raw sockets, HornetQ 2. Message broker, e.g. ActiveMQ, RabbitMQ 3. Distributed shared memory, e.g. ZooKeeper, Hazelcast, memcached 4. Distributed job control, e.g. Hadoop, Storm You can end up implementing something that looks very much like the Actor Model using these components. But you have other options as well. Where Clojure helps you in designing these systems is its focus on generic, immutable data structures and pure functions. Clojure's data structures are trivially serializable (EDN, Transit, Fressian). When all the data in your application can be represented by Clojure's generic data structures, it is easy to distribute work or data across multiple machines. When functions are stateless, it is less important where they are executed. When functions (or declarative expressions, e.g. database queries) can be expressed as data structures, they are easier to compose and distribute. –S On Wednesday, July 3, 2013, Hussein B. wrote: I read recently on the internet that Clojure concurrency tools make it easy to implement a highly concurrent system but on a single machine. But how to implement a highly concurrent system that runs on a multiple machines? Erlang, Elixir and Scala have the Actors model. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: #{:eduction :performance} Trying to understand when to use eduction
On Sunday, July 19, 2015 at 10:53:25 AM UTC-5, Stuart Sierra wrote: Hi Leon, I think this is an edge case related to how varargs functions are implemented in Clojure. The varargs arity of `max` is implemented with `reduce1`: core.clj line 1088 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/clj/clojure/core.clj#L1088 `reduce1` is a simplified implementation of reduce defined early in clojure.core before the optimized reduction protocols have been loaded: core.clj line 894 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/clj/clojure/core.clj#L894. `reduce1` is implemented in terms of lazy sequences, with support for chunking. So `apply max` defaults to using chunked lazy sequence operations. `map` and `range` both return chunked sequences. `eduction` returns an Iterable, so when you `apply max` on it, it turns the Iterable into a Seq, but it's not a chunked seq. Therefore, it's slightly slower than `apply max` on a chunked seq. seqs on eductions *are* chunked - they will fall into this case during seq: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L524-L525 which produces a chunked sequence over an Iterable. In this case, to ensure you're using the fast-path internal reduce over ` eduction`, you can use `reduce` directly: (reduce max 0 (eduction (map inc) (range 10))) You must provide an init value because `eduction` does not assume the init with first element behavior of sequences. This version, in my informal benchmarking, is the fastest. Lots of functions in clojure.core use `reduce1` in their varargs implementation. Perhaps they could be changed to use the optimized `reduce`, but this might add a lot of repeated definitions as clojure.core is bootstrapping itself. I'm not sure. For various bootstrapping reasons, this is a hard change. In general, I would not assume that `eduction` is automatically faster than lazy sequences. It will be faster only in the cases where it can use the optimized reduction protocols such as InternalReduce. If the optimized path isn't available, many operations will fall back to lazy sequences for backwards-compatibility. I would suggest using `eduction` only when you *know* you're going to consume the result with `reduce` or `transduce`. As always, test first, and profilers are your friend. :) Use eduction for delayed eager *non-cached* execution. Seqs give you delayed *cached* execution. If you're doing a transformation once, or if the thing you're doing would consume too many resources if cached, then use eduction. If you need to do a transformation once and then use the result multiple times, it's better to use sequence+transducer to get the caching effect and the benefits of reduced allocation during transformation. Chunked seqs are surprisingly fast, particularly when all of the operations in a nested transformation are chunked. However, every new layer adds another set of (chunked) sequence allocation. Eduction or anything transducer-based is going to do no seq allocation and execute as a single eager pass. Generally this means that transducer stuff will win more if the collection source is reducible, if the inputs are large (more input = more win), or if the number of transformations is 1 (more transformations = more wins). –S On Saturday, July 18, 2015 at 9:11:45 AM UTC-4, Leon Grapenthin wrote: My understanding was that if I pass an eduction to a process using reduce, I can save the computer time and space because the per step overhead of lazy sequences is gone and also the entire sequence does not have to reside in memory at once. When I time the difference between (apply max (map inc (range 10))) and (apply max (eduction (map inc) (range 10))), the lazy-seq variant wins. I'd like to understand why, and when eductions should be used instead. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to implement a distributed and concurrent system in Clojure?
Thanks Stuart for your answer, it is very helpfull. Would you choose Clojure again ? 2015-07-19 17:13 GMT+02:00 Stuart Sierra the.stuart.sie...@gmail.com: This is an old thread, but it showed up in my Google Groups so I figured I would give an answer. I have worked on fairly large (10-50 machines) distributed systems written entirely in Clojure. The language itself doesn't provide an explicit mechanism for communication between machines, so you just have to pick an existing tool or technique that suits your application architecture. There are many possibilities to choose from, all with different strengths and weaknesses: 1. Direct connections between nodes, e.g. HTTP, raw sockets, HornetQ 2. Message broker, e.g. ActiveMQ, RabbitMQ 3. Distributed shared memory, e.g. ZooKeeper, Hazelcast, memcached 4. Distributed job control, e.g. Hadoop, Storm You can end up implementing something that looks very much like the Actor Model using these components. But you have other options as well. Where Clojure helps you in designing these systems is its focus on generic, immutable data structures and pure functions. Clojure's data structures are trivially serializable (EDN, Transit, Fressian). When all the data in your application can be represented by Clojure's generic data structures, it is easy to distribute work or data across multiple machines. When functions are stateless, it is less important where they are executed. When functions (or declarative expressions, e.g. database queries) can be expressed as data structures, they are easier to compose and distribute. –S On Wednesday, July 3, 2013, Hussein B. wrote: I read recently on the internet that Clojure concurrency tools make it easy to implement a highly concurrent system but on a single machine. But how to implement a highly concurrent system that runs on a multiple machines? Erlang, Elixir and Scala have the Actors model. -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/4GRJVxctlU0/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Pozdrawiam, Mateusz Górski -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to implement a distributed and concurrent system in Clojure?
Absolutely would use again. But I'm biased towards Clojure already. :) –S On Sunday, July 19, 2015 09goral wrote: Thanks Stuart for your answer, it is very helpfull. Would you choose Clojure again ? 2015-07-19 17:13 GMT+02:00 Stuart Sierra: This is an old thread, but it showed up in my Google Groups so I figured I would give an answer. I have worked on fairly large (10-50 machines) distributed systems written entirely in Clojure -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to implement a distributed and concurrent system in Clojure?
I don’t have anything to add at that scale, but I wanted to echo Stuart’s comment about the serialisability of EDN. Moving EDN between the front and back tiers on our app has cut down a bunch of boilerplate. That principle can scale across machines as well. On 19 Jul 2015, at 16:54, Stuart Sierra the.stuart.sie...@gmail.com wrote: Absolutely would use again. But I'm biased towards Clojure already. :) –S On Sunday, July 19, 2015 09goral wrote: Thanks Stuart for your answer, it is very helpfull. Would you choose Clojure again ? 2015-07-19 17:13 GMT+02:00 Stuart Sierra: This is an old thread, but it showed up in my Google Groups so I figured I would give an answer. I have worked on fairly large (10-50 machines) distributed systems written entirely in Clojure -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to implement a distributed and concurrent system in Clojure?
I'll also add that if you're interested in the Storm model (distributed stream processing), you may want to check out Onyx (https://github.com/onyx-platform/onyx). It's newer, but I have a feeling that moving forward we're going to see it take a dominant position as far as that flavor of distributed computing goes. The reasons for this (briefly): * Data all the topologies: Because computational topologies are data structures, it's far simpler to have more dynamic computational workflows than with storms opaque macros. * It's more Clojure centric: Parts of Storm are Clojure, but the Clojure API seems almost an afterthought, reading the documentation. (However, support is on the way for other JVM languages). * Pace of development: Storm is now an Apache Incubator project, and development is slower than molasses. I was working on a project for over a year and many times encountered issues with stale dependencies that didn't play nicely with newer things. * Designed with batch processing in mind: Even though both are designed around streaming first, Onyx has a little more explicit support for batched computations. For a while, the biggest advantage of Storm was that it was a lot faster, but the gap there has closed considerably recently (perhaps entirely?). Storm is still more battle tested, but there are folks starting to use it in production. The biggest reason I see Onyx taking sway over Storm is the data centric approach. I see this resonating with the community's data all the things philosophy as a way of maximizing composability and productivity. Anecdotally, folks using Onyx are already saying this about it. My 2 c Chris On Sunday, July 19, 2015 at 9:38:09 AM UTC-7, Devin Walters (devn) wrote: http://docs.paralleluniverse.co/pulsar/ is out there. I can't say I've used it in anger, but I did enjoy experimenting with it. On Sun, Jul 19, 2015 at 11:24 AM Colin Yates colin...@gmail.com javascript: wrote: I don’t have anything to add at that scale, but I wanted to echo Stuart’s comment about the serialisability of EDN. Moving EDN between the front and back tiers on our app has cut down a bunch of boilerplate. That principle can scale across machines as well. On 19 Jul 2015, at 16:54, Stuart Sierra the.stua...@gmail.com javascript: wrote: Absolutely would use again. But I'm biased towards Clojure already. :) –S On Sunday, July 19, 2015 09goral wrote: Thanks Stuart for your answer, it is very helpfull. Would you choose Clojure again ? 2015-07-19 17:13 GMT+02:00 Stuart Sierra: This is an old thread, but it showed up in my Google Groups so I figured I would give an answer. I have worked on fairly large (10-50 machines) distributed systems written entirely in Clojure -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [:ann :book] ClojureScript Unraveled
That's a really exciting project, as a lot of people are looking to get started with ClojureScript and are finding it kind of hard because of the lack of such resources. My advise would be to put a bit heavier focus on the differences between Clojure ClojureScript and add some section about setting up various editors/IDEs. A chapter like ClojureScript for Clojure devs would be great IMO. On 20 July 2015 at 00:51, Alejandro Gómez alejan...@dialelo.com wrote: We just released the second revision which includes a lot of corrections, an Acknowledgments section and an almost finished chapter about CSP core.async which covers all its API and introduces the CSP concepts. - Leanpub: https://leanpub.com/clojurescript-unraveled - GitHub repository: https://github.com/funcool/clojurescript-unraveled - HTML version: http://funcool.github.io/clojurescript-unraveled/ On Sun, Jul 19, 2015, at 14:51, Nando Breiter wrote: I'm a Clojure beginner and wanted to compliment the authors on a very clear yet concise text. Thank you. Thanks a lot, any feedback will be greatly appreciated since one of the goals of the project is to make ClojureScript accesible to newcomers. Aria Media Sagl Via Rompada 40 6987 Caslano Switzerland +41 (0)91 600 9601 +41 (0)76 303 4477 cell skype: ariamedia On Fri, Jul 17, 2015 at 7:30 PM, Alejandro Gómez alejan...@dialelo.com wrote: Hello everybody, I'm happy to announce that Andrey Antoukh (@niwinz) and I published the book about ClojureScript that we have been writing lately on Leanpub. It's not still 100% complete but the sections about the language and compiler are almost done. We'd greatly appreciate any feedback, errata or suggestions for the book. It is an open source book licensed under a Creative Commons BY-SA license and will forever remain free and open to community participation. Publishing it on Leanpub is a convenient way for readers to be notified whenever a new release comes out and not to go through the process of generating the book themselves. If you feel like it and can afford it you can make a donation and buy us a beer too! - Leanpub: https://leanpub.com/clojurescript-unraveled - GitHub repository: https://github.com/funcool/clojurescript-unraveled - HTML version: http://funcool.github.io/clojurescript-unraveled/ Yours, Alejandro -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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
'cljsbuild' not a task
I followed the instructions to add the proper dependencies, plugins to the project, but upon entering lein cljsbuild once as noted in every online doc/ tutorial related, I get the error C:\Functional_Languages\Clojure\clojurescript_master\!work\modern-cljslein cljsbuild once 'cljsbuild' is not a task. See 'lein help'. what can I do to figure out the issue; where might there be something not set correctly? 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.8.0-alpha2
You're also going to have to target [clj-tuple 0.2.2], since something else seems to be shadowing that depedency. Sorry for all the fuss. On Sunday, July 19, 2015 at 5:02:13 PM UTC-7, Sean Corfield wrote: Bumping clj-http to 2.0.0 got me past that problem (and it uses Potemkin 0.4.1) but then I hit the problem below, which I’ve run into several times trying to use updated versions of clj-http over the last year. Messagejava.lang.RuntimeException: No such var: clj-tuple/vector, compiling:(potemkin/utils.clj:110:10)Cause clojure.lang.Compiler$CompilerExceptionStacktraceThe Error Occurred in *core.clj: line 5866* *called from* core.clj: line 5865 *called from* core.clj: line 5671 *called from* core.clj: line 5711 *called from* core.clj: line 5710 *called from* core.clj: line 632 *called from* core.clj: line 5753 *called from* core.clj: line 634 *called from* core.clj: line 5843 *called from* collections.clj: line 1 *called from* collections.clj: line 1 *called from* core.clj: line 5866 *called from* core.clj: line 5865 *called from* core.clj: line 5671 *called from* core.clj: line 5711 *called from* core.clj: line 5710 *called from* core.clj: line 632 *called from* core.clj: line 5753 *called from* core.clj: line 632 *called from* core.clj: line 5832 *called from* potemkin.clj: line 1 *called from* potemkin.clj: line 1 *called from* core.clj: line 5866 *called from* core.clj: line 5865 *called from* core.clj: line 5671 *called from* core.clj: line 5711 *called from* core.clj: line 5710 *called from* core.clj: line 632 *called from* core.clj: line 5749 *called from* core.clj: line 632 *called from* core.clj: line 5832 *called from* headers.clj: line 1 *called from* headers.clj: line 1 *called from* core.clj: line 5866 *called from* core.clj: line 5865 *called from* core.clj: line 5671 *called from* core.clj: line 5711 *called from* core.clj: line 5710 *called from* core.clj: line 632 *called from* core.clj: line 5749 *called from* core.clj: line 632 *called from* core.clj: line 5832 *called from* core.clj: line 1 *called from* core.clj: line 1 *called from* core.clj: line 5866 *called from* core.clj: line 5865 *called from* core.clj: line 5671 *called from* core.clj: line 5711 *called from* core.clj: line 5710 *called from* core.clj: line 632 *called from* core.clj: line 5749 *called from* core.clj: line 632 *called from* core.clj: line 5832 *called from* client.clj: line 1 On Jul 19, 2015, at 4:53 PM, Michael Blume blume...@gmail.com javascript: wrote: Looks like it has, pinning to Potemkin 0.4.1 should probably sort you out On Sun, Jul 19, 2015 at 4:50 PM Michael Blume blume...@gmail.com javascript: wrote: Sean, I think that was identified as a bug in Potemkin. The pull was merged but I'm not sure if there's been a release since. Zack? https://github.com/ztellman/potemkin/pull/40 http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632 On Sun, Jul 19, 2015 at 4:47 PM Sean Corfield se...@corfield.org javascript: wrote: On Jul 18, 2015, at 10:33 PM, Sean Corfield se...@corfield.org javascript: wrote: Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this week. We may go to production with it fairly quickly. Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting here in case anyone knows immediately what the cause is, while I go debugging... Exception in thread main java.lang.NoClassDefFoundError: IllegalName: compile__stub.clj_http.headers.clj-http.headers/HeaderMap, compiling:(clj_http/headers.clj:105:1) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.analyze(Compiler.java:6553) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789) at clojure.lang.Compiler.analyze(Compiler.java:6592) at clojure.lang.Compiler.eval(Compiler.java:6847) at clojure.lang.Compiler.eval(Compiler.java:6839) at clojure.lang.Compiler.load(Compiler.java:7295) at clojure.lang.RT.loadResourceScript(RT.java:372) at clojure.lang.RT.loadResourceScript(RT.java:363) at clojure.lang.RT.load(RT.java:453) at
