[ANN]: clojure.tools.trace 0.7.9
A Clojure trace tool. Defines tracing macros/fns to help you see what your code is doing. Summary of changes of this release: * Release 0.7.9 October 8, 2015: * Closed TTRACE-11, trace-vars/untrace-vars now accept vars * Closed TTRACE-12, move away from Java 5, extend some new throwables with ThrowableRecompose * Added more tests for TTRACE-12 -- Luc Préfontaine SoftAddicts inc. Québec, Canada Rabat, Morocco -- 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.
--- advanced warning: the following section contains a lethal form of irony, please skip it if your health condition does not tolerate irony --- Sure and I never maintained code written by others in 30 years... Never wrote patches, never had to comply with odd indentation habits. I am an absolute newbie on that subject. I always write new code and leave maintenance to other less fortunate people. --- end of ironic section --- I agree with you. Totally. Maintenance has never been funnier than new dev and will never be. Day to day maintenance specifically is a pain in the ass. Preemptive rewrites as part of maintenance is doable when the code reaches an unbearable state but someone in charge has to call the shots. I had numerous discussions about rewriting in the last few decades and yes patch consistency is always brought forward. The driving factors around a decision like this are: the life expectancy of the code vs it's complexity vs maintenance cost and agility vs risks involved in a rewrite vs budget vs accumulated knowledge. The maintainer's pain is not the only factor taken into account and often not the most important. That's the harsh reality of life. Ideally we would always write new stuff and trash code every 2/3 years to keep our mood at its peak. Life is not like that. Sorry :) Sent from my iPhone On Jul 20, 2015, at 08:14, Nicola Mometto brobro...@gmail.com wrote: I take it you have never worked on a patch for clojure. I have, and I can tell you that it's not the indentation style the issue -- everybody likes his own and it's definitely in the maintainer's rights to chose what indentation style should be used and for contributors to adapt, I don't have a problem with that. I have a problem with the fact that the indentation style is not consistent even between lines of the same method, tabs and spaces are mixed everywhere -- for every non trivial patch I submit I have to spend non trivial amounts of time to reindent my code using spaces or tabs where appropriate to be consistent with the surrounding code and making sure I don't accidentally commit whitespace changes in my patches. It's certainly not the biggest issue (not even close to it) in the contributing process, but it definitely is an issue and it doesn't help making the overall contributing experience a pleasant one, or one would want to repeat. And the claim that no indentation fix can happen to avoid breaking existing patches in jira is frankly laughable. With the amount of time that usually passes between the writing of a patch and its application to the code base, a lot of them already need to be rebased/rewritten to apply cleanly, often multiple times. On Sat, Jul 18, 2015 at 5:44 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) -- 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.
Lets make it clear (the ironic portion seems to obfuscate my email). I did not criticIzed his work and if you ask me, yes his work is stellar. I fully agreed with him that maintenance is often a less than funny task. Inconsistency in code when maintaining code however is more the norm than the exception even within a single organization. Tension between day to day maintenance pain versus all the other constraints will not disappear tomorrow. Code ages. It takes around 5 years to reach maturity. Afterward you need to prevent decay. This it what I can say after going through so many software projects. I tried to put things in perspective. Real-life constraints exist for business driven projects and open source projects. It seems that you are not interested at all by these. Fine. That's your call. Now if you think that because I did not contribute to patches in Clojure core makes my conclusions about maintenance work unworthy you are erring. And this a very soft statement from my part :) The ironic section was partly about my inadequate skills and you fell happily into this trap. If you really want to discuss my professional achievements send me a private email. This is not the place to discuss this and is orthogonal to the point brought up by Nicola. Which is absolutely valid but hard to solve in a satisfactory way given the constraints. Clojure in Clojure on the JVM and CLR will ease up this... Eventually when some time will have passed. Sent from my iPhone On Jul 20, 2015, at 10:08, Colin Fleming colin.mailingl...@gmail.com wrote: Leaving aside your usual humour, you are once again setting up a total strawman. Nicola did not say that maintenance should be as much fun as writing new code, nor did he propose rewriting anything. He made a very specific claim - that contributing to the Clojure codebase is much less pleasant than it could be, not because the indentation style is unusual but because it is inconsistent. Since he has a long history of writing very high quality patches for Clojure whereas you, as far as I can tell, have never written any, means that his opinion holds a lot more weight in this discussion, for me at least. On 20 July 2015 at 14:45, Luc Prefontaine lprefonta...@softaddicts.ca wrote: --- advanced warning: the following section contains a lethal form of irony, please skip it if your health condition does not tolerate irony --- Sure and I never maintained code written by others in 30 years... Never wrote patches, never had to comply with odd indentation habits. I am an absolute newbie on that subject. I always write new code and leave maintenance to other less fortunate people. --- end of ironic section --- I agree with you. Totally. Maintenance has never been funnier than new dev and will never be. Day to day maintenance specifically is a pain in the ass. Preemptive rewrites as part of maintenance is doable when the code reaches an unbearable state but someone in charge has to call the shots. I had numerous discussions about rewriting in the last few decades and yes patch consistency is always brought forward. The driving factors around a decision like this are: the life expectancy of the code vs it's complexity vs maintenance cost and agility vs risks involved in a rewrite vs budget vs accumulated knowledge. The maintainer's pain is not the only factor taken into account and often not the most important. That's the harsh reality of life. Ideally we would always write new stuff and trash code every 2/3 years to keep our mood at its peak. Life is not like that. Sorry :) Sent from my iPhone On Jul 20, 2015, at 08:14, Nicola Mometto brobro...@gmail.com wrote: I take it you have never worked on a patch for clojure. I have, and I can tell you that it's not the indentation style the issue -- everybody likes his own and it's definitely in the maintainer's rights to chose what indentation style should be used and for contributors to adapt, I don't have a problem with that. I have a problem with the fact that the indentation style is not consistent even between lines of the same method, tabs and spaces are mixed everywhere -- for every non trivial patch I submit I have to spend non trivial amounts of time to reindent my code using spaces or tabs where appropriate to be consistent with the surrounding code and making sure I don't accidentally commit whitespace changes in my patches. It's certainly not the biggest issue (not even close to it) in the contributing process, but it definitely is an issue and it doesn't help making the overall contributing experience a pleasant one, or one would want to repeat. And the claim that no indentation fix can happen to avoid breaking existing patches in jira is frankly laughable. With the amount of time that usually passes between the writing of a patch and its application to the code base, a lot
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: #{:rant} Questions about contribution policy and clojure compiler source.
You mentionned RedHat Linux centric type corporations. There are a lot more businesses that are not Linux centric business wise. They use it but provide something else on top. Did you even read this article against your own statement ? :) A huge number of occasional contributors were not reluctant to log a ticket and submit a patch instead of ranting about it. This is the main point you missed. That 'entry barrier' of yours does not stand with Linux. I would think hard about the reasons behind these numbers. There has to be some value added in the process of submitting patches. Luc P. On Sat, 18 Jul 2015 23:02:30 +0300 Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 22:52, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ Did you even read this article? 75% – The share of all kernel development that is done by developers who are being paid for their work. This doesn't exactly contract what I said. There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. As this conversation isn't really going anywhere I'll keep my thoughts to myself. Luc P. Luc P. Sent from my iPad On Jul 18, 2015, at 14:32, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 20:18, 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. So, Ruby on Rails is a small project, right? And if we have many contributors we should show no respect for their time - we should actually make it harder to contribute, so it'd be easier on us, right? 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. Many projects predate GitHub, yet they eventually adopted it. And it's never about GitHub in particular - it's only about making things efficient and pleasant for everyone involved. I work with JIRA for a living and my team mostly hates
Re: #{:rant} Questions about contribution policy and clojure compiler source.
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. 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 are not very complicated to adopt and has a lot of benefit. My two cents! On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@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 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: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- 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
Re: clojure don't support .clj source code file by utf-8.
I agree that the number of encodings makes a full proof transparent solution impossible to implement. I still think that some simpler text file handling out of the box should exist on the JVM to read utf files. Utf-8 is kind of natural within the JVM. Exposing all this BOM machinery every time you need to read a text file is a pain. Either implement BOM recognition on the fly or make it mandatory in utf-8 files every where. The BOM is required for utf-16 and above as far as I know. The time spent on stupid issues like this one must be significant given the number of people struggling with this... Sent from my iPhone On Jul 13, 2015, at 18:46, Sungjin Chun chu...@castlesoft.co.kr wrote: Assume that charset is the same, even this case, there're many types of encoding scheme for it and for portability, you have to consider both input and output encoding. On Mac OS X or Linux, this is controlled by locale system, on windows 1. you can force encoding system using control panel or you have to change your encoding before output to console. Here, we in korea, do this stuffs for internationalized application development. Of course, you have to use correct charset for i18n application :-) On Mon, Jul 13, 2015 at 11:56 PM Luc Préfontaine lprefonta...@softaddicts.ca wrote: I cannot remember the details but in 2010 I had similar problem in a cross-platform project using Clojure. And problems earlier in another cross-platform/cross-language project. So it's the reverse way, no BOM at all... Can't believe we are in 2015 still struggling with character set issues. Having to to think about this when saving a file in notepad...That's depressing. No wonder why I now stay away from Windows as much as possible. I can't understand why we cannot get some transparent behavior from the Java runtime. These are human readable text files. Not some unreadable binary format. Googled a bit about this and numerous people face this problem reading windows generated files. They all ended up having to skip the BOM if present when reading the file. So much for portability. Beurk. On Mon, Jul 13, 2015 at 2:52 PM, Luc Préfontaine lprefonta...@softaddicts.ca wrote: BG is right on it. I hit this problem a decade ago (roughly :)). UTF-8 files with no BOM are not handled properly on windows. It assumes that they are ASCII coded. That works partially (both character sets have the same encoding for many characters) but eventually fails. Make sure that the files have a BOM. You can do this on a per file basis using an IDE (Eclipse, ...) or if you can use bash scripts to do this if you have access to a u*x environment. I did not find an equivalent native windows tool but they might be some to do this in batch. Luc P. Clojure source files are expected to be in UTF-8 and Clojure on Windows doesn't require a BOM. In fact, Clojure files must not contain a BOM because it isn't considered to be whitespace by the clojure parser and will cause the error Unable to resolve symbol: ? in this context. Some software, such as Windows notepad uses the presence of a BOM to detect UTF-8, but that can be overridden in the File | Open dialog. Other than that, the behaviour of the BOM on Clojure between Linux and Windows should be the same - this stuff is all handled by Java code in the JDK - not by the Windows platform. -- 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. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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/Rk5JGhq-IJY/unsubscribe. To unsubscribe from this group and all its topics, send an email to
Re: clojure don't support .clj source code file by utf-8.
Windows a problem ? N, impossible :))) Luc P. Sent from my iPhone On Jul 12, 2015, at 19:39, Sungjin Chun chu...@gmail.com wrote: On Mac OS X (Yosemite) and Linux (Ubuntu), this code works well (I'm using en_US.UTF-8 as charset and encoding for my system). I suspect that the OS (Windows) or its configuration is the source of the problem. On Sunday, July 12, 2015 at 10:57:59 AM UTC+9, Denis Fuenzalida wrote: I was able to reproduce an error involving Windows 7 and UTF-8 in a virtual machine with VirtualBox 4.3 (not sure if it is the issue that Alex experienced though): * Installed Windows 7, then used Ninite.com to install Notepad++ (text editor), Oracle JDK 8 (1.8.0_45). Installed Leiningen 2.5.1 as .bat file from the website. * Created a new leiningen project with lein new app utf8test * Opened the file src/utf8test/core.clj in Notepad++ and replaced the contents of with the following: (ns utf8test.core (:gen-class)) (defn saludo-año [año] (str Saludos en el año año)) (def saludo-japonés どうもありがとう) (defn -main [ args] (println (saludo-año 2015)) (println saludo-japonés)) * On Notepad++ went to the Encoding menu and selected Encoding in UTF-8 w/o BOM. Saved the file. When running lein run on the cmd.exe console it works but it outputs garbage instead of any non-ascii character (see http://i.imgur.com/H0rngyq.png) * To trigger the compilation error, change the encoding of the file in Notepad++ to Encoding in UTF-8. Save the file. When running lein run this time it will not compile and complains about being unable to resolve a symbol (see http://i.imgur.com/3SHegTH.png) ... however, if you type the contents of the file in the cmd.exe console (with type src\utf8test\core.clj) you'll see there's some extra garbage chars before the namespace declaration. My theory is that such garbage chars are the Byte Order Mark (BOM) Unicode character (https://en.wikipedia.org/wiki/Byte_order_mark) and they are not being correctly handled in Windows somewhere in the stack. I don't use Windows regularly and I never had UTF-8 issues on Linux though. -- Denis Fuenzalida El jueves, 9 de julio de 2015, 12:33:46 (UTC-7), Daniel Compton escribió: Hi Alex You'll need to give us some more information about this to help us troubleshoot what's going on. Can you share the file with us? On Fri, 10 Jul 2015 at 3:59 AM Alex Woods linp...@gmail.com wrote: clojure don't support .clj source code file by utf-8. it's ok when the .clj source code files by ascii env: windows7,jdk1.8u45,lein2.5.0 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=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. 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. -- 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: Running test.check and cljs.test tests under Clojurescript
Dunno if this can help you: https://github.com/lprefontaine/clara-rules/blob/master/project.clj I run tests with : lein cljsbuild test-cljs If I my memory is not fooling me. There might be a better way but this is what I had time to tweak this weekend. You need to setup phantomjs, etc...look at the phantomjs folder in the project. Luc P. Sent from my iPhone On Jul 1, 2015, at 00:03, Nathan Marz nathan.m...@gmail.com wrote: I figured out a way to do it by manually launching a ClojureScript REPL, writing a test runner script, and then invoking that script at the REPL, like so: https://github.com/nathanmarz/specter/blob/cljs/DEVELOPER.md Still wondering if there's a more straightforward way to do this. On Tuesday, June 30, 2015 at 7:20:58 PM UTC-4, Nathan Marz wrote: I'm trying to get Specter's tests running under ClojureScript. I can run the tests manually in a REPL just fine, but I cannot figure out a straightforward way to run all the tests like you can in Clojure with lein test. Here are the tests I'm trying to run, which are a mix of tests defined using test.check and cljs.test: https://github.com/nathanmarz/specter/blob/cljs/test/com/rpl/specter/core_test.cljc I've tried the instructions in http://abratukhin.blogspot.com/2015/03/how-to-set-up-unit-tests-in.html but the cemerick.cljs.test package does not seem to run test.check tests defined with defspec. How can I set up a runner to run my tests with a one line command at the terminal? -- 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: boot(2) question
Btwy, For is not a loop as in imperative languages. It returns a lazy sequence. Luc P. Sent from my iPhone On Jun 18, 2015, at 07:51, Haim Ashkenazi haim.ashken...@gmail.com wrote: Hi, I'm trying boot scripting capabilities so I have the following file: #!/usr/bin/env boot (set-env! :dependencies '[[org.clojure/clojure 1.6.0]]) (defn -main [] (println before) (for [s [one two three]] (do (spit output s :append true) (println s))) (println after)) When running this script form the command line all the stuff inside the for loop is doesn't seem to run: ✓ src ➤ ./testboot before after ... and there's no out[put file. Inside a REPL it runs without a problem. Am I missing something? Thanks in advance -- Haim -- 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: boot(2) question
For is lazy. Replace it with doseq. Use doseq when you want side effects to occur and do not need a result. Luc P. Sent from my iPhone On Jun 18, 2015, at 07:51, Haim Ashkenazi haim.ashken...@gmail.com wrote: Hi, I'm trying boot scripting capabilities so I have the following file: #!/usr/bin/env boot (set-env! :dependencies '[[org.clojure/clojure 1.6.0]]) (defn -main [] (println before) (for [s [one two three]] (do (spit output s :append true) (println s))) (println after)) When running this script form the command line all the stuff inside the for loop is doesn't seem to run: ✓ src ➤ ./testboot before after ... and there's no out[put file. Inside a REPL it runs without a problem. Am I missing something? Thanks in advance -- Haim -- 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] Time-Bombed Open License - thoughts?
I agree. I can't see how you can build a business model out of this. We already lower the cost for our customers by using open source as much as possible. Luc P. Sent from my iPhone On Jun 5, 2015, at 12:16, Colin Fleming colin.mailingl...@gmail.com wrote: I'm the author of Cursive, which I'm planning to sell and which will be (mostly) closed source. What I don't see here is what would be the advantage to me in using this license? I'm not releasing closed source because I'm evil, but because I want Cursive development to be sustainable so I can continue to develop it and my family can continue to eat and not live in cardboard boxes. Charging for closed source software is the only realistic model I can see that achieves this goal. I suspect the Datomic team's reasoning is similar - their pricing is far from outrageous for the sort of product they're offering. What would be the advantage to them in doing this? They would simply lose the ability to charge in two years' time, and they would also lose the vast majority of their clients who also wouldn't want to be bound by these restrictions. Nobody wins, as far as I can see. On 5 June 2015 at 22:17, Fergal Byrne fergalbyrnedub...@gmail.com wrote: An old-school C++ dev and I have started an initiative to combine the best of Open Source with a limited commercial license. It's not a new idea - MySQL creator Monty Widenius thought of something less viral in 2013 [1]. The Time-Bombed Open License [2] is the commercial side of a dual-licensed project, best paired with something strongly viral like GPL. Essentially, the project owner has 2 (up to 4) years to commercialise their product and then must go fully Open Source. The license is viral, so any commercial licensees must also use the TBOL and eventually open up their derived products. One major idea is to foster a culture of disruption of exploitative industries. If you can develop software to disrupt in your local market, your innovation can be used similarly by others elsewhere, and each new startup can improve on your work while earning their keep. Eventually, all derived products become Open Source and are free to all. We'd appreciate any comments, feedback and assistance from the wonderful Clojure community - we're up on twitter at @OccupyStartups. Regards, Fergal Byrne p.s. I wonder if this might be a solution to the clamour for Datomic to be Open Sourced (cough)? [1] http://monty-says.blogspot.ie/2013/06/business-source-software-license-with.html [2] http://occupystartups.me -- Fergal Byrne, Brenter IT http://inbits.com - Better Living through Thoughtful Technology http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne Founder of Clortex: HTM in Clojure - https://github.com/nupic-community/clortex Author, Real Machine Intelligence with Clortex and NuPIC Read for free or buy the book at https://leanpub.com/realsmartmachines e:fergalbyrnedub...@gmail.com t:+353 83 4214179 Join the quest for Machine Intelligence at http://numenta.org Formerly of Adnet edi...@adnet.ie http://www.adnet.ie -- 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
Re: [ANN] Clojure 1.7.0-RC1 now available
We have a planned upgrade at a customer site before xmas of our oldest product. Internal work on upgrading it to 1.7 starts in august. If I look at the Clojure upgrade track since 2009, I can't say that I am nervous about this. Not at all :) We are presently building a new product and integrating 1.7 made sense. We already reused some common internal components w/o any glitches. 25 years ago I was used to smooth upgrades working on VMS. I did not see that happening many times since then. And we run critical services 24/7 on premises, not in a fully controlled off-site environment. Our up times are insane. Yahoo ! Luc On Jun 4, 2015, at 2:51 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Still 3 months away from production beta. I get twitchy if we go more than two weeks between production builds — but then it’s the web :) 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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.7.0-RC1 now available
Hi, Have been using 1.7 since beta1 in dev and test in a new dev. Still 3 months away from production beta. So far no issues. Zero, nada, nil, ... Reader conditionals are quite amazing, we started unifying backend and front end code. Wow... No more split brain syndrome and a huge simplification of front end/back end code. That's a huge relief on my nervous system :) For the first time in many years I enjoy working on a web front end... finally. Thank you all, Luc P. On Thu, 21 May 2015 11:30:47 -0500 Alex Miller a...@puredanger.com wrote: Clojure 1.7.0-RC1 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/ - Leiningen: [org.clojure/clojure 1.7.0-RC1] The only change since 1.7.0-beta3 is CLJ-1706, which makes reader conditional splicing an error at the top level (previously it would silently drop all but the first spliced element). For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not). The more and quicker feedback we get, the sooner we can release 1.7.0 final! - Alex -- Luc Préfontaine SoftAddicts inc. Québec, Canada Mobil: +1 (514) 993-0320 Fax: +1 (514) 800-2017 Rabat, Maroc Mobil: +1 212 6 98 00 64 47 -- 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: Advice when running java -jar rather than a managed server like tomcat?
I like it when someone says 'do not do this' without some supporting cost/benefit rationale. My next question is why not ? I'll add my own salt here: - Daemonizing does not alter business logic, it can be kept separate using more than one entry point - Supervisory functions are not as generic as some may think. You may have a need to support extra stuff in daemon mode that may/may not be offered by your platform supervisor - Portability might be an issue which is easier to deal with within the JVM than having to cope with different platform specific supervisors As to the why not, I am eager to see them. In general your mileage will vary depending on your needs. This is the real answer to many of the 'do not do this' so named 'rules'. Luc P. Sent from my iPhone On May 29, 2015, at 08:02, piastkra...@gmail.com wrote: Stuart, about the JSVC, I am curious if you have an opinion about the argument made in the comments of this blog post: Great post, but in reality you should never write app that daemonize them self. Always use supervisors that your system provides. http://www.rkn.io/2014/02/06/clojure-cookbook-daemons/ On Wednesday, May 27, 2015 at 3:53:24 AM UTC-4, Stuart Sierra wrote: JSVC (Apache Commons daemon for Unix) is excellent for this sort of thing. There's a Windows Services version too. –S On Tuesday, May 26, 2015 at 12:38:30 PM UTC+1, Colin Yates wrote: Hi, I am venturing into new territory using http-kit, as I usually use a 'managed' web server container like tomcat and have a few questions about packing and running a JAR file: - are there are convenient service wrappers for windows and/or Linux - any best practice around managing class path for things like logback.xml I have a jar created from lein uberjar and java -jar the.jar works, but this seems a long way away from automated deployment :). Any advice welcome - 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: Using :refer 'sparingly'
We systematically use refer all on tools.trace and a few other of our name spaces used for production support. It becomes handy in a live repl in production. Luc P. I agree with the general sentiment expressed here, but would just like to add that `:refer`-ing a few frequently used functions (as Colin Yates stated, particularly when it's assumed there is strong coupling or closeness between the two namespaces involved), is a much more minor nuisance than `:refer :all`. At least with `:refer [some-fn some-other-fn]`, you _can_ figure out where the function came from by going up to the `ns` declaration, and if you're fast with your editor, this is easy to do. Both `:refer :all` and `:use`/ `(use)` should (IMHO) only be used for hacking around at the repl. -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: CLJ-703 - 10x compilation time decrease after applying one-line patch, no downsides.
There's a better 'fix'. Run your builds on SSDs or on a memory based file system. With the RAM available these days, any build can be done on a memory based file system. It speeds up every step by a huge factor. Not only compilation. You only need to copy your targets to a 'permanent' place. We have been doing this for years to shrink build times. We AOT most of our code base. Luc P. I'll just say one more time that the team should really consider doing bug-fix releases in the future. This problem sounds serious enough to be handled as quickly as possible. Clojure 1.6 was released over one year ago, so I'm guessing 1.8 is more than a year away from now. Waiting for major releases for a bug fix in not exactly the greatest user experience. On 9 May 2015 at 05:18, Alexander Hudek a...@diligenceengine.com wrote: I'd like to chime in here in support of this, our company has been running a modified clojure build because of this for over a year now. Alex On Friday, May 8, 2015 at 2:12:50 PM UTC-4, Martin Raison wrote: Hi all, This issue has been around for a while without much activity, although a very simple fix is already there: http://dev.clojure.org/jira/browse/CLJ-703 We have a pretty big Clojure project that we compile on machines with slow hard-drives, on CentOS 6. We noticed that compilation had become extremely slow, however CPU usage was always below 10%. Simply removing the line cfs.getFD().sync(); inside src/jvm/clojure/lang/Compiler.java dramatically improved the compilation time (Something like 10x, although at this level of increase, measurement almost doesn't make sense anymore :)). We've been using the suggested fix (remove-sync-only.patch) for a few weeks and haven't observed any issues. It seems we should really figure out whether this line is actually necessary, or if it was added there just in case. Even if some situations require it, the speed bump is so huge that we might want some special-case logic. Martin -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Clojure needs a web framework with more momentum
+1 This exactly the kind of exercises that needs to done as part of a product design. New potential needs have to be foreseen at this stage, not 18 months after a first release. This is why I hate frameworks, they assume some of these decisions and it's not always stated clearly. Someone has to discover the sad effects and if you are not lucky, you're the 'king of the farce'. They lure you in a trap pampered with 'easy', 'obvious'... Until you have a need that cannot be met along the way. I read several comments about how easy it is to upgrade Rails. Either things have been improving at the speed of light or I am a complete idiot. My last upgrades from 2.x to 2.y have been nightmares, dependency hell multiplied by an unknown factor above 100... I would rather deal with an explicit dependency graph than work with magic stuff that eventually breaks in obscure ways after an upgrade and requires mods in remote places in foreign code. Luc P. The thing that bugs me the most about these sort of conversations about best practices is that they often present a set of solutions without first analyzing the problem at hand. If I came to this mailing list and asked I want to write a websever in Clojure..what should I use?. The response would most likely be Ring + Compojure. Okay, not bad options, but that recommendation has been given with absolutely no analysis of what I'm trying to accomplish. What if I need async? What if I need web sockets? What sort of connection load am I expecting? Will my system handle mostly persistent connections (like websockets or SSE), or will it be more canned (and cacheable) data? If someone recommends Ring to me, I may be pigeonholed into some system I'll have to refactor later. Perhaps the best option is Aleph or Pedestal. That's the real issue with canned responses like rails tutorial. They assume my needs match your needs and match the needs of most people. That's just not the best way to go about doing software development. And it's a problem I've seen in so many areas of computing. I've lost countless hundreds of hours of my life to frameworks that default to bulky serialization formats (like XML or JSON), or frameworks that assume LAN connections to the servers, or frameworks that assume I won't be using multi-threading, or frameworks that assume I won't try to load 10k rows on a single page, or frameworks that assume any number of things. The thing I love the most about the Clojure community is that, more than any other community I've been a part of, they try to ask you to think before you jump. So what I would recommend is more of a set of guidelines, and matrices. List all the frameworks/libraries on one axis, and features on another, and start commenting. Make a page like this: ( http://en.wikipedia.org/wiki/Comparison_of_video_container_formats) Mention that Ring is well supported by the community, but doesn't work well with fully async servers, mention that Aleph does all the async you need, but is a bit non-standard. Mention that data.json is pure Clojure, but cheshire is most likely faster. Just present the options, and let the users make up their own minds. You don't understand the needs of all of your users. So don't try to solve their problems, instead present them with options and let them make up their own minds. I guarantee you that whatever tech you recommend to someone, the won't like some aspect of it, so better to present them with all the options and let them choose, then they can only blame themselves if it doesn't work out exactly like they expected. On Mon, May 4, 2015 at 7:34 AM, Ernie de Feria ernie.defe...@gmail.com wrote: I would like to echo the sentiment expressed by several posters in this thread, but with a slight twist. A few years back I picked up Ruby and Ruby on Rails as the language/framework to create a website with moderate complexity and functionality. I did this without any prior experience with the language of framework. What allowed me to quickly pick up both was the excellent documentation around the language and framework. For example, with the information from http://guides.rubyonrails.org and the canonical application built in https://www.railstutorial.org one can acquire the necessary knowledge to develop highly functional websites. Branching out to leverage non-canonical libraries/products then becomes a fairly easy exercise (MongoDB instead of MySQL, Mongoid instead of ActiveRecords, etc.). What allows that to happen is the momentum built around the Rails ecosystem via community participation and documentation. We have recently started to build our back end infrastructure in Clojure. Many times we have discussed the value and desire to unify our development efforts on and around Clojure. Inevitably we tally up all the functionality inherited from Ruby gems (that play nice with Rails - the Framework) that would have to be
Why is Caribou unmaintained ?
Spawned from the other thread about web frameworks. Can any of the original maintainers answer this one ? Thank you Luc P. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Clojure needs a web framework with more momentum
Business case... I have two business cases at hand. None can be done with frameworks w/o making the end products look like any other one in their respective space and having to bend to framework limitations. Being disruptive requires a different approach. Having to write all these individual libs ourselves would make these two product sets much more difficult to create. Experimentation would also suffer a lot. Now we have the elements to create new recipes instead of everyone eating the same dry cake that's been left on the shelf for a year. Aside from HR tagging, I see little value in a branded framework. Being reluctant to be part of a tagged herd, I can't agree with you :) But given my (bad) character this may explain that :) Luc P. On 03/05/2015 00:53, Christopher Small wrote: I disagree with the premise entirely. I think that the Clojure community has just done a better job of building smaller, more modular tooling. And this is frankly something I prefer, and find refreshing in the Clojure sphere (as compared with my previous Rails webdev experience). Note that to put things on the same footing, you'd want to be noting that Luminus depend on Ring and Compojure, with commit counts 761 and 865 resp, and contributor counts 73 and 29 resp. I'm not saying that Clojure can't improve it's offering in web dev with added libraries etc, but I wouldn't want to see us move away from the modularity with which we've built things, because I think it's a win. Just my 2 c Chris Small Most decent web frameworks these days are built from modular components so this distinction is a bit laboured. Rails is built on top of Active* and Rack so the Ring/Compojure distinction is illusory. Laravel is built on top of Symfony components it could be argued that Symfony has played a similar role to Ring/Compojure in the PHP community. Clojure's modular approach is great but I just don't see the need to polarise when there's such a strong business case for structured frameworks. If you look at most of the jobs in web development at Indeed.com they're almost exclusively framework-based. Modular is great but it would also be nice to see a few more Clojure jobs advertised. gvim -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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] Clojure Reactive Programming
Bought it myself too... If this is some kind of marketing stunt, it caught me off guard... (sic) Luc P. The list is so cool that I think this discussion is actually part of the book's marketing strategy. It worked! I just bought my copy ;-) On Thu, Mar 26, 2015 at 4:57 PM, Colin Yates colin.ya...@gmail.com wrote: Hi Leonardo, I haven't read it yet but I am very much looking forward to it based on other people's responses :). On 26 March 2015 at 15:52, Leonardo Borges leonardoborges...@gmail.com wrote: Thanks everyone for the kind words! It makes it all worth it :) Cheers, Leonardo On Thursday, March 26, 2015 at 11:44:27 AM UTC-3, Shaun Mahood wrote: Just thought I would leave a quick note for anyone interested in the book (and hopefully get the thread back on topic). I'm about 1/3 through the book and have found it really well written and interesting so far. It's an excellent introduction to reactive programming in general and for clojure specifically, and is easy to follow for a relative beginner in both clojure and reactive programming. If you have any interest at all in the topic I highly recommend picking it up. Thanks for writing it Leonardo! On Tuesday, March 24, 2015 at 8:26:02 AM UTC-6, Leonardo Borges wrote: Hi all, Some of you may know that I have been working on a book for the better part of last year. I'm happy to announce it has finally been published! Here's the link: https://www.packtpub.com/web-development/clojure-reactive-programming I hope you find it useful! I've had a great time putting it together! Cheers, Leonardo Borges www.leonardoborges.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. -- 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. -- Hildeberto Mendonça, Ph.D Blog: http://www.hildeberto.com Community: http://www.cejug.net Twitter: https://twitter.com/htmfilho -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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 related articles on Semaphore Community
Nice to you to raise the flag :) Luc P. Hi everyone, I wanted to share a few articles about testing and deployment of Clojure applications that I wrote for Semaphore Community - https://semaphoreci.com/community/tags/clojure. I plan to continue writing on those and other topics so I would love to hear some feedback or ideas. What topics would you recommend me to explore? Any questions you would like to be answered in the tutorial form? Thanks, Nebojša Stričević -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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] Clojure Reactive Programming
Fine with me. Let's call it off. It's not either a forum about netiquette or about 'how bad this word/expression hurts anonymous people'. Luc, you are missing the point: this isn't the forum for that discussion regardless of how valid the points in that discussion are. This is a _Clojure_ forum, not a 'what's wrong with the (technology) world' forum, I would suggest this isn't even a 'how can Clojure fix the world' forum. Luc, please read the various responses carefully - replying by validating the points in your discussion/justifying your position is missing the point, please do not reply until you understand that. I think we should just let this thread die, so I'm out. On 26 March 2015 at 13:08, Luc Préfontaine lprefonta...@softaddicts.ca wrote: The 'attack' word is again a manifestation of extreme political correctness. I will argue that these technologies with their inherent complexity are creating huge bureaucracies to attract and hide unqualified/unskilled/uncommited/.. aka 'stupid' people from scrutiny. These environments have the perverse effect of encouraging people not to think too much at least not publicly because of that political correctness pushed to the limit. 'You are not a team player, blablablalbla...'. 'Stupidity' is not off topic here, not at all. It's been a plague for two decades in this industry as soon as demand increased for sotfware. It started to attract people mid 80s because of the promise to get a well paid job. Not because they had above average skills or had a keen interest in it. 'I do not need to understand technology, I'll be a manager in three years'. This a real quote from a colleague when I was quite green. Meanwhile HR replaced know-how by worthless tags (add water to this pouch and you will get a Java/Ruby/... asset) and processes hoping to use a Taylor approach to creativity like if we were building cars on an assembly line. Some would argue that without this enterprise mass market, we would not have the technology we have at hand these days. True. The industry has been recycling old concepts for 30 years branding them as new. Huge costs with incremental changes. This mitigated success is limited by this assembly line model. And unlike a car plant, it cannot be robotized. You need to change wetware... Hence the 'stupidity' factor discussion -- 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: Disk based caching for Clojure app
We have been running builds on the same SSDs, doing intensive logging, ... for three years now. None deteriorated. Builds are mainly scrap write thousands of small files plus a few big ones (the targets). Write speed makes a huge difference for this kind of task. Aws allows to get VMs with SSDs of decent sizes and not to store only the OS. I think they would restrict usage if rewrites were a huge concern... Luc P. On Friday, March 6, 2015 at 3:16:09 PM UTC-5, Michael Blume wrote: Possibly stupid question: can you just pretend you have more memory than you do and let the operating system do the heavy lifting? As in, put the swap partition on the SSD and jack up the virtual memory in the OS config? Isn't it a bad idea to put swap on an SSD, because of the limited number of times an SSD byte can be rewritten before it sticks permanently? Thus making SSD more suited to storing stuff where speed counts, but which doesn't change very much, like the operating system kernel and modules and core libraries, plus your most often used applications? Then you get faster boot and app-startup times without constant writes to the SSD (just when something is upgraded). Of course, SSD being less well suited to frequently-written data would also militate against using it for a cache managed by the application, rather than by the OS ... -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: To the person who recently tried to post a message about using vert.x library
You got the name right but I am not the sender :) I may have the name of that library incorrect. I was going through messages to the Clojure group from new senders. I saw this message, and was intending to approve it, but accidentally hit the 'report as spam and block the sender' button. Ugh. My apologies. If you were the sender, and you are reading this, please send me a private message so I can try to figure out how to undo this. Thanks, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Possible additions to tools.trace
Hi, Got your ticket notification, it's a busy week, beeing on the road most of it. I will look at it by next Sunday after crossing the Atlantic :) Luc P. Hi all, I've proposed some changed to tools.trace and created an initial implementation (linked in the JIRA ticket). http://dev.clojure.org/jira/browse/TTRACE-10 Thanks, Aaron -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Set equality bug?
Danger vs flexibility. or are safe. Should they throw an exception then ? Compiler in some older typed languages would warn you about testing equality between two float numbers irrelevant of their types but would be silent about other operators. Testing equality with floats is seldom used in the context of heavy computations. Testing against a range is often preferred. Money related apps use specific types to deal with rounding/truncating. This is why packed decimal was used intensively. You would always end up with two decimals. W/o having to care for the intermediate computation steps too much. Danger comes from ignorance. What you with it afterward is another story :) I would find it odd to see some operators throw such errors in a typeless language. If the underlying argument is that it is horribly dangerous to mix floats and doubles in your code, then maybe (= (float 1.5) (double 1.5)) should have the semantics of (.compareTo (float 1.5) (double 1.5)), i.e., throw an error. I'm not certain that's a good idea for Clojure, but it does seem like the logical outcome of this line of thinking. -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Set equality bug?
Obviously... user= (= (byte 1) (short 1) (long 1) 1) true user= http://clojure.org/rationale Language as platform vs. language + platform - Old way - each language defines its own runtime GC, bytecode, type system, libraries etc - New way (JVM, .Net) - Common runtime independent of language Clojure 'type system' embraces the platform it runs on with the exception of its own persistent data structures. It's not the other way around. On Fri, 23 Jan 2015 14:23:34 -0800 (PST) Fluid Dynamics a2093...@trbvm.com wrote: And this is not a typeless language, it is a strongly dynamically typed language. -- Luc Préfontaine SoftAddicts inc. Québec, Canada Mobil: (514) 993-0320 Fax: (514) 800-2017 -- 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: Set equality bug?
Agree, it's broken... in java...
Has it has been broken in the past in several architectures...
I understand your frustration but this is not something new. It's been a
problem for at least 30 years.
It is kind of a basic programming issue:
- Never compare floats with different representations.
- Never mix different representations in computations
- Convert representations as early as possible to a common format
These are the rules to follow to avoid running into trouble.
Now if you think you can overcome this persistent (ah ! ah !) problem with some
David Copperfield trick, fine.
But that's a trick nothing else. The problem will resurface in some form in
another. Better cope with reality...
Luc P.
On Jan 23, 2015, at 1:33 AM, Immo Heikkinen immo.heikki...@gmail.com wrote:
I actually ran into this while comparing nested data structures from two
different sources and spent a good part of my day figuring out what's
happening. While it is a good advice to avoid mixing floats and doubles, it
is inevitable that Clojure users will get bitten by this once in a while
and hours will be wasted.
It is also very disturbing to realise that (= a b) doesn't always imply
(= (hash a) (hash b)) or (= #{a} #{b}) as you would think.
(inc)
This is fundamentally broken behavior. Telling people to just learn to avoid
it is not good, IMO. If the hashes must be unequal, then = should return
false.
As for backwards compatibility, note that if such a change were made to =, it
wouldn't affect anyone who was already following Andy's advice to avoid
mixing doubles and floats. IOW, it should only affect those who are doing
something you're not supposed to do anyway.
--
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.
--
Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
--
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: Set equality bug?
public class TestClass {
public static void equality () {
double dd = 3.5;
float ff = 3.5f;
System.out.println(String.format(dd vs ff == %b, dd==ff));
double dd2 = 3.2;
float ff2 = 3.2f;
System.out.println(String.format(dd2 vs ff2 == %b, dd2==ff2));
}
}
REPL output:
= (idem.core.TestClass/equality)
nil
Console output:
nREPL server started on port 38698 on host 127.0.0.1 - nrepl://127.0.0.1:38698
dd vs ff == true
dd2 vs ff2 == false
We are talking about values as primitive types, not boxed values as objects:
The equals method for class Object implements the most discriminating possible
equivalence relation on objects; that is, for any non-null reference values x
and y, this method returns true if and only if x and y refer to the same object
(x == y has the value true).
= (class (float 3.2))
java.lang.Float
= (class (double 3.2))
java.lang.Double
Oupse... :)
Luc P.
On Fri, 23 Jan 2015 01:31:31 -0800
Mark Engelberg mark.engelb...@gmail.com wrote:
On Fri, Jan 23, 2015 at 1:10 AM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
Agree, it's broken... in java...
I think it's more frustrating in Clojure than in Java, though,
because in Java you have those big, ugly type annotations on every
single variable, input and output, so there's really no question when
you're working with a mixture of floats and doubles. In Clojure,
it's much easier for this kind of thing to slip into your program
unnoticed. Call a couple of external libraries that produce floats
or doubles -- Clojure will happily hide the difference from you and
then you get burned.
As I frequently find myself explaining to newcomers to Clojure, one of
Clojure's biggest weaknesses is that it goes to great pains to hide
type details (floats vs doubles, boxed vs unboxed, hash sets vs array
sets, etc.) and every once in a while it really matters -- a lot --
what the types actually are and there aren't many tools for
discovering the flow of types through your code.
So I wouldn't necessarily go blaming this on Java.
Furthermore, I'm not so sure it is broken in Java:
= (.equals (float 2) (double 2))
false
= (.compareTo (float 2) (double 2))
ClassCastException Cannot cast java.lang.Double to java.lang.Float
java.lang.Class.cast (Class.java:3258)
So Java doesn't appear to transparently treat floats and doubles as
equal (which is consistent with the fact that Java's hashes of floats
and doubles can be different).
--
Luc Préfontaine
SoftAddicts inc.
Québec, Canada
Mobil: (514) 993-0320
Fax: (514) 800-2017
--
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 do you name your protocols?
I do this when there is added value, like sone common logic I can wrap on top of the protocol methods that I do not want to call/duplicate in every implementation. But this is quite specific to my own app. The lifecycle's only purpose is to be extended to your own components. Can't see what would be the added value here, the wrapping fn would only be calling the protocol method. Nothing else... If you require more in your context then define your own wrapper. Nothing generic can help you at this point... I think... Luc P. I was just refering to the fact that the 'start' protocol method is meant to be called directly by library's users. I'm not using components in any of my projects, so take it with a grain of salt. It seems to me that it would be better (i.e. less coupled, fewer assumptions about the starting process for implementers, more freedom for Stuart to introduce non-breaking implementation changes) to have a dedicated start function, that in its simplest form would just call Lifecycle/start method. Jozef On Mon, Dec 29, 2014 at 3:40 PM, Malcolm Sparks malc...@juxt.pro wrote: I agree with you and Meikel's points about wrapping protocols with API functions, it makes sense, especially if you want to combine these calls with (Prismatic) schema checks. However, I'm not sure about your point that Stuart made an 'unfortunate' design to 'expose' protocol methods directly, it's just a necessary consequence of the component design, unless you can suggest an alternative approach. On Sunday, 28 December 2014 16:54:30 UTC, Jozef Wagner wrote: I was not implying anything about what Rich have said. While the SPI term may be used in the 'enterprise' field too much (and in an unnecessary complicated manner), I think it has perfectly valid uses in Clojure. The API tells you what a function or a macro does for you, but SPI tells you what you have to do in order to integrate with existing functionalities. BTW I think protocol methods should be in SPI too. (Stuart's components library made IMO a bit unfortunate decision to expose 'start' and 'stop' protocol methods directly) See http://kotka.de/blog/2011/ 07/Separation_of_concerns.html for a related write-up. Jozef On Sunday, December 28, 2014 4:18:47 PM UTC+1, adrian...@mail.yu.edu wrote: You're overlooking the fact that a service provider interface is simply enterprise design pattern jargon for a subset of public APIs that expose the underlying interfaces of the library to consumers. Saying that Rich is saying protocols should never ever be part of the public API is both misleading and false. On Sunday, December 28, 2014 2:50:06 AM UTC-5, Jozef Wagner wrote: Protocols should never ever be part of public API. Protocols can be part of the SPI, if custom extensions are to be supported. Otherwise they are an implementation detail. See Rich's talk at 4:30 http://vimeo.com/ 100518968 Jozef On Sun, Dec 28, 2014 at 8:11 AM, Mikera mike.r.an...@gmail.com wrote: That depends if the protocols are part of your user-facing API or not - a lot of the time I find that protocols are best hidden as implementation details rather than exposed to users. In core.matrix, for example, users never see the protocols directly: only implementers of new matrix libraries need to care On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote: Changing old protocol names should trigger a major revision change in the minimum because it breaks backwards compatibility. --Ashton Sent from my iPhone On Dec 27, 2014, at 11:18 AM, Michael Klishin michael@gmail.com wrote: On 27 December 2014 at 19:10:38, Jozef Wagner (jozef@gmail.com) wrote: clj-time seems to be naming protocols inconsistently. It uses ISomething, Something and SomethingProtocol naming. I suspect it is because it has 60 contributors and most users never have to extend the protocols. Feel free to submit a PR that standardises all names on Something. -- @michaelklishin, github.com/michaelklishin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=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. 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
Re: CCW bug [SEVERE]
I'll repeat myself : '...guessing which error is relevant or not is an educated guess at best except if you are deep in Eclipse plugins coding.' Laurent stated clearly that saving a file triggers a number of things in several plugins. There could be suspicious messages in the log that have nothing to do with CCW and that could give an idea of the root of the problem. I'll leave you to think about this and figure out what should be your next action. Guess what ? It's not adding another email to this thread, I wrote 'action' above. Luc P. On Friday, October 31, 2014 6:23:42 PM UTC-4, Luc wrote: Just curious, how can you expect a fix if you do not provide any information that could support a serious investigation ? I read the eclipse log file from time to time and guessing which error is relevant or not is an educated guess at best except if you are deep in Eclipse plugins coding. Creating an issue in the ccw project page takes under a minute including attaching the log file. If you expect the developer to find the root cause from thin air, you will wait for eternity. Laurent is very proactive in investigating problems but w/o any grounds, he's better having a glass of wine than trying to guess what happened here. I would do the same... It's not *my* fault the log file doesn't contain anything unusual between before the hang happened and after recovery. If CCW didn't log anything that helps indicate what was different or unusual on that occasion of saving, then there's simply not much I can do about it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: where do I think the wrong way
You need to provide a key and a value. (assoc book :authors (conj ... LP Thanks James, But how do I use assoc with it I tried this : (defn add-author [book new-author] (assoc book (conj (book :authors) new-author))) but then I see this message : ArityException Wrong number of args (2) passed to: core$assoc clojure.lang.AFn.throwArity (AFn.java:437) Roelof Op woensdag 29 oktober 2014 12:08:35 UTC+1 schreef James Reeves: On 29 October 2014 11:01, Roelof Wobben rwo...@hotmail.com javascript: wrote: For a exercise I have to add something to the end of a existing map. So I thought this would work : (defn add-author [book new-author] (assoc book (conj :authors new-author))) Take a look at that conj expression on its own: (conj :authors new-author) You're trying to conjoin new-author onto the keyword :authors, but keywords aren't collections. That's what the error means. It's saying that it expected a collection, but you've supplied a keyword instead. What you want is: (conj (get book :authors) new-author) Which can also be written: (conj (book :authors) new-author) (conj (:authors book) new-author) These two expressions are shortcuts for the above get function. They work because maps and keywords can act as functions. - James -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: CCW bug [SEVERE]
Ka-plonk :) Do the names Ken Wesson or Cedric Greevey mean anything to you? Just checking. On Tue, Oct 28, 2014 at 1:28 PM, Fluid Dynamics a2093...@trbvm.com wrote: On Tuesday, October 28, 2014 12:19:29 PM UTC-4, Marcus Blankenship wrote: Agreed. I've been amazed at how kind this group has been, despite your attitude of disrespect toward them. On Tue, Oct 28, 2014 at 9:09 AM, Dylan Butman dbu...@gmail.com wrote: From your attitude and lack of respect for the very knowledgeable, experienced, and respectful people here trying to help improve and understand the short comings in your current workflow, I'd say you might be walking to work in the near future. Parking's free that way. Really? Because I'm not the one who accused someone of nonexistent shortcomings and then made the impotent threat to revoke someone's driver's license -- and then had his threatening post deleted by the moderator. Hmm. :) Meanwhile, I think some people still have not grasped the scale of what I'm doing, namely how small it is. Small, experimental, limited to one person, and so forth. Version control, I repeat, would be MASSIVE overkill under the circumstances. It would make barely any less sense to reach for version control before writing a hello, world program. IF the project grows enough and is successful enough, then I might consider creating a github account and basing it there. But right now things are NOWHERE NEAR that kind of state. I am unsure how else to try to communicate the fact of how small, unpublishable, and etc. it is at this stage, so I will probably give up on anyone here who still seems to think it's big enough, has enough developers, or whatever to benefit from version control. It's not. So far there's two files of combined size 1200 lines, most of them comment and docstring lines. There might be as many as 200 actual lines of Clojure in there so far. Using a version control system, and dealing with all of the associated ceremony and formalities, would be like renting a factory and setting up all of the process monitoring, conveyor belt equipment, robot arms, safety inspections, permits, and everything else attendant the use of such a facility, just to put together a high school shop project wooden birdhouse to hang from a tree in my own back yard. :) It would be like filing a flight plan with the FAA before going to the city park with a kite. Like getting in the car and driving to the house next door to visit the neighbors for coffee. Like bringing a map, compass, pack full of survival supplies, camp stove, satellite phone, avalanche beacon, ropes, pitons, and sturdy hiking boots to take a walk in NYC that crosses through Central Park. Like commissioning the Glomar Explorer to fish a ring out of a toilet bowl. Bringing lawyers and pages of CYA contract text to a negotiation with a Starbucks for the purchase of a latte. Taking out a business license and city zoning permit to open a kid's five-cent lemonade stand. Seeking an import license before bringing a couple of Disney T-shirts back from EuroDisney. Requiring a full credit check before loaning your neighbor a screwdriver. Using steel-reinforced concrete to build a sandcastle. I trust everyone now gets the picture, and that any exception is named Sheldon Cooper? :) -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this
Re: Profiling in Counterclockwise
Have a look at criterium. https://github.com/hugoduncan/criterium It will allow you to look at the performance of code chunks in the REPL, you get meaningful results and a solid comparison basis. So practical that it's part of my default profile. You can test different approaches w/o leaving the REPL. I use VisualVM and similar tools for integrated tests once the app is packaged as a safeguard. Luc P. On Sunday, October 5, 2014 3:57:37 PM UTC-4, Gary Verhaegen wrote: When I need to profile (which is asmittedly quite rare), I use VisualVM, which should have been installed along with the JDK. I'd recommend editing the default settings to remove clojure.** and add your own namespaces as starting points for the profiling. For more lightweight approaches, I'd suggest checking out Timbre and Criterium, though I have very little experience with both. None of this is Eclipse specific or runs in Eclipse. So, what you're saying is that I'd have to 1) Package everything up 2) Deploy to somewhere 3) Learn how to use insert new, complicated tool here that requires classpath configuration and stuff 4) Identify hot spots 5) Make improvement of some sort 6) Back to step 1? Because that seems to *completely eliminate* the benefit of having a REPL and fast development/try things/edit cycle. :( Meanwhile, why did I get google results for a supposed Profiling and Logging perspective in Eclipse if no such thing exists? -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Profiling in Counterclockwise
As far as I know the external tools exposed so far are the only way to get the breakdown you are seeking. Profiling in dev with an external tool is kind of a conflicting goal to me. Such tools used in dev are also a form of micro benchmarking on incomplete code. Your app is not fully packaged, how meaningful are the hot spots you may find at this stage ? What does it tell you about the future behaviour of your app ? With the REPL in the way reevaluating code as you modify it ? Criterium allows us to evaluate at any level in our code if the performance is acceptable or not. It does a sane job collecting stats. I can exercise 5% or 50% of the code and get stats from its execution within a couple of minutes with the workload size I desire. I can do minute changes and see the effect. If the performance is satisfactory, no need to dig for a hot spot at this stage. We look at hotspots when the app packaging is near completed in test. Then its behaviour is much closer to production. But we rarely find a performance issue justifying a code change except if it's trivial. It's a matter of putting some reasonable effort toward optimization when justified. Doing this early in dev with a time efficient tool to me is a better use of my time than using a sophisticated one requiring some complex wiring from my part. Luc P. On Sunday, October 5, 2014 4:58:04 PM UTC-4, Luc wrote: Have a look at criterium. https://github.com/hugoduncan/criterium That's (micro)benchmarking, not profiling. Profiling would break down the time spent in different functions and help to identify hot spots that might especially benefit from optimization. -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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.7.0-alpha2
The keyword has different meaning depending on the language and context. Most of the time to prevent optimizations by the compiler to insure write ordering and some consistent view (Java use). Not here. It's meant to warn that nothing is guaranteed, no synchronization, no consistent view. It should be kept local (no leak outside of a narrow scope) and certainly not shared by multiple threads. Luc P. Excuse my ignorance but does volatile! have anything to do with Java's volatile keyword? Is there any relation at all? I'm not suggesting a name change, but it can be confusing coming from that angle. Maybe a blurb in the doc string? -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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.7.0-alpha2
+1 for the ! No atomic changes here, no coordination whatsoever. At the mercy of the caller... I asked Rich and he said making a volatile is as dangerous as any ! op. Some people have also asked about vswap! being a macro instead of a method on Volatile. The issue there is that vswap! takes a variadic number of update function args. If implemented as a method, you'd need to provide multiple arities or eventually use apply (like in Atom's swap! https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Atom.java#L79) - doing it in a macro lets that expansion take place at compile time to provide better performance without the apply. On Mon, Sep 8, 2014 at 1:36 PM, Jozef Wagner jozef.wag...@gmail.com wrote: FYI the ticket about volatile is at http://dev.clojure.org/jira/browse/CLJ-1512 and the same question was raised there. On Mon, Sep 8, 2014 at 4:25 PM, Frantisek Sodomka fsodo...@gmail.com wrote: Hello, I posted a question about volatiles on the github commit: https://github.com/clojure/clojure/commit/60440977823752f13a3fec3637538e9a1d68c5d4 I don't know if anybody noticed, so... why is volatile created with function volatile! and not volatile ? Atoms, refs and agents don't have exclamation mark in their constructor functions. Should I think about volatiles as mutable locals? :-) František On Friday, September 5, 2014 4:26:53 PM UTC+2, Alex Miller wrote: Clojure 1.7.0-alpha1 is now available. Try it via - Download: http://central.maven.org/maven2/org/clojure/clojure/1.7.0-alpha2/ - Download securely: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha2/ - Leiningen: [org.clojure/clojure 1.7.0-alpha2] Highlights below, full change log here: https://github.com/clojure/clojure/blob/master/changes.md For users of Clojure 1.7.0-alpha1, there have been a few important changes in transducers since alpha1: - Removed flatmap transducer - Added cat transducer - mapcat 1-arity is now a transducer, specifically: (comp (map f) cat) - The completing function has been lifted to be public Clojure 1.7.0-alpha2 has the changes below from 1.6.0: ## 1 New and Improved Features ### 1.1 Transducers Transducers is a new way to decouple algorithmic transformations from their application in different contexts. Transducers are functions that transform reducing functions to build up a recipe for transformation. Also see: http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming Many existing sequence functions now have a new arity (one fewer argument than before). This arity will return a transducer that represents the same logic but is independent of lazy sequence processing. Functions included are: * conj (conjs to []) * map * mapcat * filter * remove * take * take-while * drop * drop-while * cycle * take-nth * replace * partition-by * partition-all * keep * keep-indexed Additionally some new transducer functions have been added: * cat - concatenates the contents of each input * de-dupe - removes consecutive duplicated values * random-sample - returns items from coll with random probability And this function can be used to make completing transforms: * completing There are also several new or modified functions that can be used to apply transducers in different ways: * sequence - takes a transformation and a coll and produces a lazy seq * transduce - reduce with a transformation (eager) * iteration - returns an iterable/seqable/reducible seq of applications of the transducer to items in coll. Applications are re-performed with every iterator/seq/reduce. * run! - run the transformation for side effects on the collection There have been a number of internal changes to support transducers: * volatiles - there are a new set of functions (volatile!, vswap!, vreset!, volatile?) to create and use volatile boxes to hold state in stateful transducers. Volatiles are faster than atoms but give up atomicity guarantees so should only be used with thread isolation. * array iterators - added support for iterators over arrays Some issues created and addressed during development: * [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511) * [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497) ### 1.2 Keyword and Symbol Construction In response to issues raised in [CLJ-1439](http://dev.clojure.org/jira/browse/CLJ-1439), several changes have been made in symbol and keyword construction: 1) The main bottleneck in construction of symbols (which also occurs inside keywords) was interning of the name and namespace strings. This interning has been removed, resulting in a performance increase. 2) Keywords are cached and keyword
Re: Useless Java error messages
Where do you see a Java error here ? I see the Clojure implementation reporting that you are trying to apply a numeric operator to a null/nil value :) I agree the JVM stack traces are not nice and polluted by all the frames which may/may not be relevant. The messages are not always as clear as this one either. You do not have any source file line number anywhere in the stack trace pointing to your code ? Luc P. Compiling a file in Emacs, this error: NullPointerException clojure.lang.Numbers.ops (Numbers.java:961) . leaves me clueless as to where the error occurred. Is there hope for native Clojure debugging anytime soon as this is the kind of thing which can easily drive a non-Java user like me to distraction? I noticed the Elixir community had the same problem with Erlang's cryptic error messages and produced their own error logging to make the language attractive to non-Erlangers. This seems to me to be perhaps the biggest barrier to entry with hosted languages. We can't expect everyone coming to Clojure to master Java's less-than-helpful error messages. Many will just give up. gvim -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Is Clojure a language for growth?
+1 same weakness + big fingers on small iPhone keyboard :( Urgent need for a second one... We choose Clojure in 2008 strictly for efficiency. In 2009 after being in prod, we were told that hiring would be a major problem. We dealt with this noise by accepting the fact that we will train people. Why ? Because we need 7 to 10 times less people. Everything got simpler from design to deployment. We get people to learn by adding tests. I can't stand TDD but I agree that safeguards like automated tests add value. So let the newcomers do the boring stuff while they learn :) I think that there is a huge perception problem. For some reason apparently in the industry complex systems = huge teams. It looks to me more like a peeing contest more than anything else. My team is bigger than yours, blablabla, Like if bigger meant better To me big teams are mostly a sign of inefficiency except if you intend to send men on the moon or similar unusual goals. Luc P. + Grammar. I should not write correspondence before having coffee. On Thursday, August 21, 2014 9:31:42 AM UTC+2, Henrik Eneroth wrote: Sweden has some things going for it, and some not, as always. I think business overall is somewhat less cutthroat here than in the States, which is why it struck me that I might be making assumptions about what OP should or should not do out of ignorance of his situation. The scape goat reasoning really brought this home. At the two most recent places I've been (I'm a consultant, a UX designer), they've worked with autonomous teams. That is, the teams are themselves responsible for deciding how to solve a problem, sometimes including what programming language to use. One result of this seems to emerge (I only have a sample size of two) a microservice centered design and a general decoupling between the teams. Also, it naturally seems to lead to a more heterogeneous environment, for good or for bad. This seems to be somewhat self-regulating however, as other most members of a team will protest if one member wants to write the new service in the Shakespearean Programming Language, for example. It also leads to the same kind of resistance to more sensible choices as well, like Clojure. But unlike SPL or Brainfuck, they actually have chance of being used if they show merit, probably by filling some niche role to begin with. When I was with Spotify, I learned that they had snuck in some Clojure in one of the teams of the organization. No one has been fired yet, and everyone seems happy enough. Especially the people who now get to do at least *some* Clojure during their work day. Oh, and like Linus, I try to promote Clojure wherever I go. As a designer, I'd love to work with a team that uses Clojure. That is, a team that understands that incidental complexity eventually seeps out to for the user to deal with, and so on. Unfortunately, being framed as a designer means I have less natural authority when I say that Clojure is awesome. Although this is somewhat mitigated somewhat by the sheer shock of having a designer saying something comprehensible about a programming language. On Thursday, August 21, 2014 7:44:18 AM UTC+2, Quzanti wrote: If an investor were kicking people out, its usually because money is running low or for other more diffuse reasons. If an investor or boss somewhere where kicking out people at random, he would quickly loose respect from his other employeers. The rest would soon leave as well Hence the need for a scapegoat. Generally if an investor can make 20% of their startups work, people will blame the technologists for the failure of the other 80%, and the investor will have a PR machine to distort the history if needed. But yes, startup hubs work best when there are angel investors who want to build a personal reputation or where the institutional investors have strong links with the universities producing the start up talent and so don't want to jeopardise those (eg the Stanford University system). Even the best VCs will shut down the majority of their start ups though, so you'd think that would make people avoid them, but there are always people out there who need money to try and realise their dreams. All a bit tangential to the the original thread question though, which was assuming a high growth, high pressure, scale it up fast, need results kind of culture, would Clojure be a good fit? On Wednesday, August 20, 2014 11:46:48 PM UTC+1, Linus Ericsson wrote: Well, for better or worse we don't like conflicts that much. This has benefits when it comes to some kinds of problem solving (the way to consensus in Swedish companies is worth at least a chapter in a big book about antrophology). This shyness for open conflicts can lead to stagnation. This means that status quo is not turned over that easily, but
Re: CLJS Function clobbering js function of same name
That's what I inferred but it has nothing to do with my astonishing ESP
capabilities,
currently drinking an excellent beer in Rabat :)
Cheers,
Luc P
I meant would not
On Mon, Aug 4, 2014 at 4:28 PM, David Nolen dnolen.li...@gmail.com wrote:
I would rely on the behavior in the REPL to check this - the REPL
compilation environment is likely different.
On Mon, Aug 4, 2014 at 3:59 PM, Sam Ritchie sritchi...@gmail.com wrote:
Hey Herwig,
I'm currently on [org.clojure/clojurescript 0.0-2261], and I'm seeing
no munging:
paddleguru.api.register.validation (defn console [])
#function console(){return null;
}
nil
paddleguru.api.register.validation (defn console [s] (.log js/console s))
#function console(s){return console.log(s);
}
nil
paddleguru.api.register.validation (console HI!)
Error evaluating: (console HI!) :as
paddleguru.api.register.validation.console.call(null,\HI!\);\n
#TypeError: undefined is not a function
TypeError: undefined is not a function
at console (eval at anonymous (
https://local.paddleguru.com/cljs/dev/generated.js:83183:294),
anonymous:1:146)
at eval (eval at anonymous (
https://local.paddleguru.com/cljs/dev/generated.js:83183:294),
anonymous:1:108)
at eval (eval at anonymous (
https://local.paddleguru.com/cljs/dev/generated.js:83183:294),
anonymous:5:3)
at https://local.paddleguru.com/cljs/dev/generated.js:83183:289
at https://local.paddleguru.com/cljs/dev/generated.js:83197:4
at G__30641__2 (
https://local.paddleguru.com/cljs/dev/generated.js:23732:22)
at G__30641 [as call] (
https://local.paddleguru.com/cljs/dev/generated.js:23977:28)
at null.anonymous (
https://local.paddleguru.com/cljs/dev/generated.js:83238:80)
at goog.events.EventTarget.fireListeners (
https://local.paddleguru.com/cljs/dev/generated.js:42772:23)
at Function.goog.events.EventTarget.dispatchEventInternal_ (
https://local.paddleguru.com/cljs/dev/generated.js:42817:26)
nil
Herwig Hochleitner hhochleit...@gmail.com
August 4, 2014 at 11:43 AM
Thomas, in my test, (defn console []) is munged aswell, so I'm guessing
that Sam is using a version from before
https://github.com/clojure/clojurescript/commit/f371c04d95a00cdda79c63f89f35088d62de8e73
Sam, is that correct?
The observation that eval should be in js-globals is irrelevant, because
as I detailed a couple of messages ago, js-globals is wrong and should be
removed.
(fn x []) should never cast a shadow on js/x for any x.
So far, I believe David to agree. I commented on CLJS-833 to reflect this
point of view.
Waiting on a statement towards fully removing gensyms from the compiler,
i.e. CLJS-401 revisited ...
--
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.
Thomas Heller th.hel...@gmail.com
August 4, 2014 at 10:40 AM
https://gist.github.com/thheller/4731f682665d38b1053c
On Monday, August 4, 2014 3:34:33 PM UTC+2, Nicola Mometto wrote: --
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.
Nicola Mometto brobro...@gmail.com
August 4, 2014 at 7:34 AM
Try with (fn document [] js/document)
Thomas Heller th.hel...@gmail.com
August 4, 2014 at 7:30 AM
I was not able to reproduce Sam's initial problem.
eval as I said does not appear in the :js-globals which seems like a
mistake.
--
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,
Re: Clojure Contributor Agreement process update
What about the real world constraints ? As far as I know, everyone needs air, water, heat, and a minimal food ration to survive. The day I cut your air away, I bet you'll be suddenly be very concerned about the 'the physical world' and that you will relinquish the 'digital age' way back in some remote primitive place in your brain :) Ok, lawyers are not as vital as air, however they flourish on litigation systems like some plants in dump yards. The day you are stuck in a lawsuit or the day someone steals something you have created and you have not cared about these 'real' things you are left alone on an ice bank, plenty of air I agree but seldom provided with a grocery store and a Starbuck... Contrary to popular belief, sharing does not imply that you allow others to steal your ideas so they can make $ out of them or claim that it's now their own and that you should get lost. I hope you stay anchored in the real world :))) Luc P. Sorry if that was already answered, Is there a possibility to get rid of this legalwall? I realize that there are good intents behind the existing practice, but it feels a bit wrong for an open source artifact in the digital age of instant sharing. Starting today, we have updated the Clojure Contributor Agreement process. -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Top-down code in namspaces
I maintain that the average human being looking at sed commands would rather end up standing on his head for a significant amount of time to avoid it :))) BTWY, I have been scripting under u*x for a few decades by now. I resort to it when nothing and I mean nothing (think about Daffy Duck's voice here) else can do it :)) Luc P. Luc P. On Wednesday, June 4, 2014 9:42:41 AM UTC-5, Mars0i wrote: ... Then I add the new functions to the declare statement by hand, or I periodically do something like: grep defn mysourcefile.clj mysourcefile.clj (Be careful to use two s!) and then I edit the junk at the end of the file into a declare statement at the top of the file. And maybe if f I were ... lazier, I'd code a script that would update the declare in one pass. OK, I couldn't resist my own implicit challenge. #!/bin/sh sourcefile=$1 newsourcefile=new.$sourcefile newdeclare=$(echo '(declare' \ `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` ')' \ | sed 's/ )/)/') sed s/(declare .*/$newdeclare/ $sourcefile $newsourcefile This writes a new version of the file named new.oldfilename. Or if you either trust your script or trust your backups, and are on a system that includes the mighty ed http://www.gnu.org/fun/jokes/ed.msg.html editor, you can replace the last line with: echo 1,\$s/(declare .*/$newdeclare/\nw\n | ed $sourcefile which edits the file in place, assuming that the previous version of the declaration was on one line. You may want to use a different scriptable editor. The messy part is the sed and tr line: `sed -n '/defn/s/(defn-* //p' $sourcefile | tr '\n' ' '` The sed part finds all of the lines with defn in them, then substitutes the empty string for (defn or (defn-. 'tr' then removes the newlines between the function names, replacing the newlines with spaces. You'll need something a little more complicated if you put the parameter vector or anything else on the same line as the function name. The 'echo' on the previous line, along with the final ')' adds (declare and its closing parenthesis. Those two lines can be used by themselves to generate a declare statement from the command line. The 'sed' command after these lines isn't necessary; it just removes an unnecessary space before the closing parenthesis. Obviously, there will be source files on which this won't work. It's not worth making it foolproof. It's a certainty that others would code this more elegantly or more succinctly. It could be written in Clojure, obviously, but still wouldn't be foolproof unless someone hacks it from the Clojure parser. -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Top-down code in namspaces
a) move out helpers or core code out of the API name space b) tag stuff left not part of the API as private in the API name space c) keep the API at the bottom d) do the above iteratively as code evolves So far it's been workable ( 2 locs so far). Not too much name space switches while improving or fixing code. Luc P Hi everyone, I'm looking to get some opinions on code style. Specifically, I like to write my code in a top-down. What I mean by that is that within a file the highest-level functions sit at the top, and are implemented in terms of lower-level functions further down. The idea is that through sensible naming, a reader should be able to stop reading at any point and still know what's going on. I was recently watching the prismatic schema presentation from the 2013 conj, and noticed they too promoted having a public section at the top of the namespace. The problem now is because of the single-pass nature of clojure's evaluation - simply writing code like this doesn't actually work. There's a few approaches i've seen from reading other's code: 1. Have an impl namespace which contains all of the helper functions for the public interface 2. Make use of (declare) forms where necessary to improve forward readability 3. Don't worry about source order, just have the api functions further down the file and live with it Some other options I considered include making really heavy use of (declare), or even defining some sort of (eval-reversed) macro which runs the code backwards. I'd like to know if people are experiencing this issue, and how you all are resolving it? Cheers Glen -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Confusion about binding *ns* before defining a var
*ns* is bound at execution time, not at compile time. Eval here postpones the definition at runtime after the bindings have been evaluated and *ns* gets rebinded. Otherwise the definition would be created at compile time in the namespace of the caller. The full form has to be compiled to get the new bindings evaled. Leaving def unwrapped would get it done at compilation time, not at runtime. Is this a bit clearer ? Luc P. On Thursday, May 29, 2014 8:43:58 PM UTC-7, squeegee wrote: On May 29, 2014, at 7:11 PM, ian.tegebo ian.t...@gmail.com javascript: wrote: user (binding [*ns* (the-ns 'blah)] (defn foo [])) #'user/foo user (binding [*ns* (the-ns 'blah)] (eval '(defn foo []))) #'blah/foo In the first case, the defn form is compiled before the binding to (the-ns ‘blah) is in effect. It's exactly this point that's confusing. The defn form expands into a def, whose documentation says it uses the current namespace. The current namespace, as I understand it, is what's bound to *ns* which IIUC should have been accomplished with the binding macro. The first code snippet was meant to demonstrate that. Here's another variant in case there's confusing about *ns* being lexical: user (defn println-ns [] *ns*) #'user/println-ns user (binding [*ns* (the-ns 'blah)] (println-ns)) #Namespace blah I don't see the reason why def should behave as it currently does; it seems like it should lookup the current thread-binding for *ns*, making the second case's use of eval unnecessary. Since it doesn't, I'd like to know why it couldn't (or shouldn't) do the thing that seems more intuitive. That said, if the special form let* does not evaluate its arguments in left to right order such that let* actually evaluates def's before anything else, then I would understand why the current behavior is the way it is However, then I'd just be curious about let*... -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Expected inconsistency between set and map w/ ArrayList?
Euh
From the top of my head after a long working day,
aren't we comparing apples with cabbages here ?
How can you expect a mutable
structure to have any stability
over time ?
They're not values and even worse
they are alien to Clojure.
To how much contortions should
go through to deal with this issue over
all the implementations while
retaining some common semantic ?
I have a pretty rigid principle
of keeping interop stuff away from
the core of my code.
Interop is needed but at the edges.
My answer to such an issue is that you need to
convert alien structures before
getting them to participate on the
Clojure side of the fence.
But I may be old fashion...
Luc P.
OK. this thread is a bit worrying. If I understand correctly, it means
that we've now got inconsistent hash and equals functions. I suspect this
hasn't bitten many people yet simply because it is unusual to mix Java and
Clojure collections as keys in the same structure, but it seems like a
really nasty issue.
Hash and equality functions generally have a very simple rule: if two
things are equal they must have the same hashcode. But now we've got:
(= (java.util.ArrayList. [1 2]) [1 2])
= true
(hash (java.util.ArrayList. [1 2]))
= 994
(hash [1 2])
= 156247261
I consider this a major defect. If we want to define our own equals and
hashcode that's fine, but then these functions absolutely should be
consistent with each other.
If it is really true that non-Clojure collections aren't considered as
values and aren't expected to participate in hash/= comparisons then I'd
expect an exception, not an erroneous value. Silent potential corruption of
data is *much* worse than a noisy failure. But I think even that is a bad
direction to go: easy Java ecosystem interop is definitely one of the main
reasons why I'm using Clojure, and I'd like to see this maintained.
I can think of only two sensible ways to fix this inconsistency:
a) Roll back the hash changes. Correctness is much more important than a
performance edge case. (I suspect the hash changes have hurt average case
performance anyway...)
b) Make (= (java.util.ArrayList. [1 2]) [1 2]) and similar comparisons
evaluate to false (on the grounds that ArrayLists aren't Clojure
collections, so should not be considered equal).
On Saturday, 10 May 2014 15:51:24 UTC+1, John Hume wrote:
Thanks for the ticket pointer. I didn't find it in my initial search
because it Affects Version/s: None :-/, and I knew this behavior was new
to 1.6.
For those not up for the medium-length comment-thread read:
non-Clojure-aware Java Collections Framework interface instances are not
considered values,* and 'Rich says all bets should be off for
hasheq/equiv of non-values.' That's a bit down in the details, but I
think the upshot is that they're not currently supported as set members or
hash keys. Unfortunately they used to be supported (unintentionally, I
guess) due to Clojure following Java's lead, so I have some interop-heavy
code to review and test very carefully. Though the above seems to frame
non-support as based on principle, it seems the driver is keeping the new
hasheq stuff highly performant. I would hope a performant implementation
that supported the Collections interfaces would be accepted for some future
version.
*If there is one, I'd like to read a clear definition of what values
means in Clojure. The headings on http://clojure.org/data_structures are
almost an enumeration of them, except the Collections section talks a
little about Java Collections classes, hashCode, and hasheq without making
it clear that non-Clojure collections are not values. Unfortunately the
current definition seems to admit only the Java primitives and
near-primitives (String and primitive wrappers) and clojure-aware types.
What not supported looks like via maps:
user *clojure-version*
{:major 1, :minor 6, :incremental 0, :qualifier nil}
user (hash-map [1 2] v (java.util.ArrayList. [1 2]) a)
{[1 2] a, [1 2] v}
user {[1 2] v (java.util.ArrayList. [1 2]) a}
IllegalArgumentException Duplicate key: [1 2]
clojure.lang.PersistentArrayMap.createWithCheck
(PersistentArrayMap.java:70)
user (- {} (assoc [1 2] v) (assoc (java.util.ArrayList. [1 2]) a))
{[1 2] a}
On Friday, May 9, 2014 6:34:26 PM UTC-5, Andy Fingerhut wrote:
Mike is correct. This change in behavior is due to the hashing changes
in Clojure 1.6. See the comments on ticket
http://dev.clojure.org/jira/browse/CLJ-1372http://www.google.com/url?q=http%3A%2F%2Fdev.clojure.org%2Fjira%2Fbrowse%2FCLJ-1372sa=Dsntz=1usg=AFQjCNG6I-rrRfAMsUZUomYEbGOJkJqWGAfor
some discussion of whether this is considered a bug. It appears that
perhaps the hash consistency is not promised for mutable objects, only
immutable ones.
Below are a couple more REPL transcripts that illustrate the change in
behavior:
user=
Re: Functional programming and security
Reading this thread convinced me. I will not write any information on any support except my brain cells and will not share it to avoid any leaks. I will also forget it immediately so no one can scrub my brain to recover it Going to erase everything I wrote and learned in the last past 30 years right now... Seriously, when concerns about security reaches the garbage collector which operates in live memory, I wonder why we bother entering any information in a computer... Any security related discussion reaches a point were sanity is left far behind don't you agree ? :))) What was I writing a few seconds ago ? Luc P. On Tue, May 6, 2014 at 9:45 AM, Cecil Westerhof cldwester...@gmail.com wrote: 2014-05-05 19:48 GMT+02:00 Brian Craft craft.br...@gmail.com: I would never have guessed modularity as a reason to worry about security in fp. I worry about immutability in fp, wrt security. Security requires mutability in order to remove sensitive data from memory, and from app history. A FIPS Would forced garbage collection not take care of that? I think the combination of zeroizing destructors, weak references, and forced garbage collection would go a long way. Then you only need to convince the FIPS validator/evaluator/thingie that your garbage collector behaves well so that sensitive data is scrubbed in a timely manner. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Light table
I have been using Eclipse for the last 10 years roughly. Having a polyglot project made this choice obvious. Now that our code base is in Clojure at 99%, I do not feel tempted by emacs. May give a try with LightTable however. I used to do most of my editing with emacs in the 1980s, using the first version written in Teco on tops-20. In these times it was a vast improvement on line by line editing. But I can't get back to it, the keyboard shortcuts do not seem to fit in my brain anymore. Years of WYSIWYG probably shrank this brain function to a bare minimum :) Luc P. On Apr 16, 2014, at 10:48 PM, Mikera mike.r.anderson...@gmail.com wrote: On Thursday, 17 April 2014 03:57:56 UTC+8, Mike Haney wrote: The conventional wisdom seems to be that you will end up learning emacs eventually if you spend any amount of time doing clojure or lisp, so you might as well learn it from the start. That is definitely the approach taken in the braveclojure book, and he may be right, but I have no regrets starting with lighttable. As a counter-example to the conventional wisdom, I have never really used Emacs and I've being doing Clojure successfully for around 4 years now. I'm sure Emacs is great for those who have taken the time to master it, but it certainly isn't necessary to be productive in Clojure. I personally use Counterclockwise - this is mainly because I also do a lot of Java work in Eclipse and it makes the polyglot integration much easier if you aren't switching tools all the time. I'm also quite excited about the potential of things like Session or Gorilla-REPL for exploratory / data science work. I like the way that the Clojure ecosystem is developing a lot of innovative, plug-able components and tools that enable different development styles. A different kind of counter-example: I've used emacs a fair bit in my decades of Lisping and now years of Clojuring, but I now too use Counterclockwise. IMHO emacs has tremendous and beautiful power but unnecessarily awful usability characteristics. I hope that some day someone will develop a Clojure environment with the former but without the later, possibly driven by emacs under the hood. -Lee -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Clojure compiletime vs runtime
Compilation is mandatory before executing anything. By default when code is loaded it's executed. That's how a Lisp behaves. If you want to isolate compilation, from execution, you can use AOT (ahead of time compilation). You would use this to deliver compiled code w/o source code, make sure there's no missing references, ... But this is not used in interactive development where you want to redefine stuff, change states, and be as dynamic as possible. Do you have a specific need that you want to cover ? Luc P. Why are the toplevel forms which arent macros executed at compile time? For example Lua can be compiled to bytecode without executing its top level calls. On Tue, Apr 15, 2014 at 9:04 PM, Softaddicts lprefonta...@softaddicts.cawrote: Ahem :) a) The fn x does not exist in the universe until you call foo, hence you cannot expect the compiler to known anything about it if it's not called before making any reference to x. b) If you refer to x at the top level (the universe above :) before defining it, obviously it does not exist. You might use (declare x) before referring to it. This allows you to define it later at your convenience. c) In general, you should avoid using def/defn within a function. Macros may do that but this is a different story. d) Yes code at the top level is executed, how can you expect the REPL to work interactively if forms are not evaluated first ? A defn expands to a function call, a special form in fact but it still behaves like a function. Any function call at top level will get executed after being compiled to byte code. Now about the compilation step... Traditionally, most Lisps allow you to refer to stuff in interpreted mode not defined yet hoping that it will get defined by the time you run the code that refers to these undefined things. It can even be something transient on the stack... oups... You can still compile in other Lisps but this is a special case where you have to make sure that stuff is defined in some way. You need to add directives to tell the compiler that this stuff will exist later and that it can safely refer to it. On the JVM, some underlying byte code has to be generated for any forms typed in the REPL at the top level any reference has to be defined before hand. There's no other way to generate byte code... there cannot be black holes waiting to get filled later. Hence the compilation phase and the restriction that stuff you refer to are to be defined either directly or using declare. Hope it explains the compromise. Luc P. Is there an explanation of how clojure deals with scoping and its static checking. It seems to be a hybrid of a static language and a dynamic language when it comes to compilation. I'll elaborate. The following code wont compile: (defn x [] nil) (defn y[]) ((x)) however this code will compile: (defn foo[] (defn x[] nil)) (defn y[]) ((x)) but calling y before foo fails with a runtime exception. Also, the following code: (println hello) (defn -main [args] (println world)) prints hello at compile time and also hello world at runtime. My conclusions from this is that the static symbol checker is actually fairly stupid and is just there to provide some simple sanity, and that all toplevel code in a namespace is executed at compile time AND at runtime. Is this correct? -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit
Re: Sharing optional arguments among functions
Use (apply base-fun opts)
Luc P.
I'm trying to define a couple of functions that support the same options,
but return different return types.
I have one function that is the base function that provides the most raw
access, and some other functions that call this base function and do their
thing.
I would like to make these keyword args available to all of these
functions, but I'm unsure how to do this.
e.g.
(defn base-fun[ {:keys [num-responses timeout] :or {:num-responses 1
:timeout 5000}}]
num-responses)
(defn other-fun[required-arg opts]
(base-fun opts))
(other-fun fred :num-responses 4) ;IllegalArgumentException No value
supplied for key: (:num-responses 4)
Is there a way to define common keyword args among functions?
--
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.
--
Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
--
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: STM and persistent data structures performance on mutli-core archs
I would say that guidelines can help but curiosity is mandatory. I used to sleep with books on my bedside table about hardware design, operating system internals, io subsystems, networking, ... I did this for 15 years after I started to work with computers. Aside from work related stuff of course, this was to increase my general knowledge and to be more relaxed on the job :) Knowing your enemy is essential... Luc P. On 16/03/14 18:24, Softaddicts wrote: I think that significant optimizations have to be decided at a higher level. I doubt that any of that can be implemented at the hardware level alone and let it decide on the fly. This sounds like magic, too good to be true. I am also quite convinced that optimizing in hardware single threaded and muti-threaded processing are antagonist goals given the current hardware designs. Martin hits a number of significant nails, we need to be aware of hardware limitations and we need to measure the impacts of our choices and change these within some reachable goals. However achieving 10% or less cpu idle time on a specific server architecture to me is not a goal. I'm interested by the constraints I have to met (business and physical ones) and playing within a large playground to meet these wether it involves using more powerful/specially designed hardware or using better software designs. I hear you well. Whether further progress comes from hardware and/or software doesn't matter, I just hope progress is being made somewhere and that we won't have to fiddle with hundreds of parameters as it's the case for the JVM right now. Until then, tedious experimentation will be the only way to ensure scaling does happen. Sure Martin's case at LMAX was extreme, not many people will have such concerns. But we're in an age where the need for scalability can be very sudden (e.g. popular phone app.). With servers nowadays that can have many CPUs and cores, and many Gb of RAM, one can easily hope that vertical scaling can be sufficient, but it's often not as simple as that. Vertical can even be more dangerous than horizontal, since in the horizontal case you probably architect for scaling right from start. So what works and doesn't work is valuable information, and initiatives such as the Reactive Manifesto http://www.reactivemanifesto.org/ are helpful because they provide guidelines. -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: STM and persistent data structures performance on mutli-core archs
In the old days, the principle of locality was prevalent. Most data allocation was static or if not contiguous (the stack). Code was also contiguous being most of the time statically compiled on several pages. Memory was costly, its size remained reasonable. Today, data is scattered everywhere in a huge memory, its location changes frequently, code can be dynamically compiled, get loaded by small chunks, Hardware wise they do what they can to deal with this but I think it's a lost battle. We need a quantum jump at the hardware level to get some faster random access to memory. This will probably shake the software stack a lot. Which brings other issues... Meanwhile we are stuck with finding the least painful path to get our stuff to run asap. Luc P. From what I understand, a single core can easily saturate a memory bus. At the same time L2 and L3 caches are so small as compared to GB of memory systems yet growing them does not necessarily help either due to larger latencies. It all limits the number of practical applications which could really take a full advantage of multi core architectures. Having said that I just wonder if a typical async Clojure application can even be efficiently performed on a multi-core architecture. In any case, immutability helps writing reliable multi execution context software there is no need for explicit synchronization in most of cases. BTW, I absolutely love the async name itself chosen by Clojure authors as opposed to reactive as in http://www.reactivemanifesto.org. Reactive comes with bad connotations and really does not reflect the intentions well. Best, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- 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: Clojure performance question
I cannot agree with this...
Not at 100% at least.
String manipulations are frequent
enough to mandate some tuning
if the need is obvious.
Looks to me that this is the case here.
Other core fns went through rewrites
to improve performance.
Simplicity has nothing to do with
internal implementations.
If someone comes up with a better
implementation while providing
the same behaviours as the current
str fn, then it should make it's way
maybe in clojure.string.
fast-strings ? Whatever it may be
named.
Luc P.
Core fns should be simple, unsurprising, and general.
'Improving' str may hurt simplicity, make behavior more surprising and
unexpected, and less general unless proven otherwise.
On Sat, Mar 1, 2014 at 7:02 PM, bob wee@gmail.com wrote:
Good point, Thanks a lot.
Shall we improve the str fn in the core lib? From my point of view, the
core fns should be performance sensitive.
On Sunday, March 2, 2014 12:03:21 AM UTC+8, Shantanu Kumar wrote:
On Saturday, 1 March 2014 15:32:41 UTC+5:30, bob wrote:
Case :
clojure verison:
(time (dotimes [n 1000] (str n another word))) ;; take about
5000msec
java version
long time = System.nanoTime();
for(int i=0 ; i1000 ;i++){
String a=i+another word;
}
System.out.println(System.nanoTime()-time);
The java version take about 500 msecs, I thought it might be caused by
the str implementation which is using string builder, and it might not be
the best choice in the case of no much string to concat, and then I
replace
another word with 5 long strings as the parameter, however no surprise.
I just wonder what make the difference, or how to find the difference.
Others have added useful points to this thread. Java string concatenation
internally uses StringBuilder, so if you replace (str n another word)
with the following:
(let [sb (StringBuilder.)]
(.append sb n)
(.append sb another word)
(.toString sb))
..then the perf improves 1/4 to 1/3. Further, with the following tweak:
(let [sb (StringBuilder. 20)] ; because StringBuilder allocates only 16
chars by default on Oracle JRE
(.append sb n)
(.append sb another word)
(.toString sb))
..the perf improves from 1/3 to less than 1/2. Here we simply avoid
double allocation in StringBuilder.
Other things I made sure were:
1. I used Criterium to measure
2. I used `-server` option
3. Made sure reflection warning was on
Shantanu
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To 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/groups/opt_out.
--
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/groups/opt_out.
--
Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
--
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/groups/opt_out.
Re: Security implications of code is data/data is code
Just joking :) There are a bunch of golden rules that violate on a regular basis for good reasons. With some satisfaction I have to confess. When you have a muti purpose tool in your hands that you can bend to almost any use it's hard to be restrained by taboos :) Luc P. Sorry Luc P., you are right. I meant that people wouldn't do that without a good reason, but it was not what I wrote. On Wednesday, January 22, 2014 3:10:27 AM UTC-2, Luc wrote: Your last statement is incomplete. It all depends on trust. We do eval at runtime of code and data w/o edn but we know it comes from a secured source. Doing such thing from an unsecured alien source would potentially look insane. Lets not presume about the insanity of the designer w/o some deeper analysis :))) Luc P. Hi Daniel, I'm not an expert in security but AFAIK this is not a problem. Every user input is a string and you chose how to parse it. There is a edn reader that is safe, but you can use specific parsers depending on the input. Of course if you read and eval the string anything could happen, but nobody would do that. Best, mynomoto On Tuesday, January 21, 2014 10:22:11 PM UTC-2, Daniel Compton wrote: I've been thinking for a while about what the security implications are for a homoiconic language like Clojure where code is data and data is code. What protections do you have against malicious input being automatically evaluated by the reader? It seems like every user input would be a possible case of 'Clojure injection'. Is this an issue or am I missing something really obvious here? Thanks, Daniel. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: Security implications of code is data/data is code
Your last statement is incomplete. It all depends on trust. We do eval at runtime of code and data w/o edn but we know it comes from a secured source. Doing such thing from an unsecured alien source would potentially look insane. Lets not presume about the insanity of the designer w/o some deeper analysis :))) Luc P. Hi Daniel, I'm not an expert in security but AFAIK this is not a problem. Every user input is a string and you chose how to parse it. There is a edn reader that is safe, but you can use specific parsers depending on the input. Of course if you read and eval the string anything could happen, but nobody would do that. Best, mynomoto On Tuesday, January 21, 2014 10:22:11 PM UTC-2, Daniel Compton wrote: I've been thinking for a while about what the security implications are for a homoiconic language like Clojure where code is data and data is code. What protections do you have against malicious input being automatically evaluated by the reader? It seems like every user input would be a possible case of 'Clojure injection'. Is this an issue or am I missing something really obvious here? Thanks, 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: clojure.edn/read-string exceptions = nil
Wrap the read in a try catch just return nil in the catch clause
for this specific exception and wrap it in a function for ease
of use. You might want to throw up any other exceptions and
only catch this one
Luc P.
I should add: this problem arises due to cljs / clojure talking over the
network, so:
(*) not using serialization is NOT an option
(*) however, I don't have to use edn/read-string + pr-str
(*) it's perfectly fine to use different encoding/decoding methods
On Thu, Jan 16, 2014 at 12:11 AM, t x txrev...@gmail.com wrote:
Hi,
Right now if I do (clojure.edn/read-string ...) on a string with a
unreadable part, I get an exception. Instead, I would like to just get nil.
For example:
## code
(clojure.edn/read-string
(pr-str
{:tag :message
:chan (async/chan 10)}))
## currently returns
java.lang.RuntimeException: Unreadable form
at clojure.lang.Util.runtimeException (Util.java:219)
## instead, I would like:
{:tag :message
:chan :nil}
Is there a way to make this happen?
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/groups/opt_out.
--
Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
--
--
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/groups/opt_out.
Re: clojure.edn/read-string exceptions = nil
Oups, skipped the last part of your
emal. With edn I see no way to
do this.
Luc
Either you misunderstood my question or I misunderstood your answer.
I don't want the entire expression to return nil. I only want the
_unparsable_ part to return nil.
Thus, the above answer should be
{:tag :message
:chan ni}
rather than
nil
On Thu, Jan 16, 2014 at 1:47 AM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
Wrap the read in a try catch just return nil in the catch clause
for this specific exception and wrap it in a function for ease
of use. You might want to throw up any other exceptions and
only catch this one
Luc P.
I should add: this problem arises due to cljs / clojure talking over the
network, so:
(*) not using serialization is NOT an option
(*) however, I don't have to use edn/read-string + pr-str
(*) it's perfectly fine to use different encoding/decoding methods
On Thu, Jan 16, 2014 at 12:11 AM, t x txrev...@gmail.com wrote:
Hi,
Right now if I do (clojure.edn/read-string ...) on a string with a
unreadable part, I get an exception. Instead, I would like to just get
nil.
For example:
## code
(clojure.edn/read-string
(pr-str
{:tag :message
:chan (async/chan 10)}))
## currently returns
java.lang.RuntimeException: Unreadable form
at clojure.lang.Util.runtimeException (Util.java:219)
## instead, I would like:
{:tag :message
:chan :nil}
Is there a way to make this happen?
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/groups/opt_out.
--
Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
--
--
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/groups/opt_out.
--
--
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/groups/opt_out.
--
Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
--
--
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/groups/opt_out.
Re: clojure.core.async java.lang.IllegalArgumentException
You are trying to close a nil channel. W/O the code it's all I can say :) Did you check to make sure you are not trying to handle nil as a channel ? Luc P. Hi, I'm getting the following error over and over again in my code, I've tried adding in some print statement and suddenly the error went away and my code worked again, then today I got the same error yet again. I suspect this might be a race condition or something similar. I can take the same library from the repl and it works, but when I use it from inside another app I suddenly get this problem error only at certain times. I've removed all close! statements from my code and I still get the same error :(, The code is https://github.com/gerritjvv/clj-tcp/blob/master/clj-tcp/src/clj_tcp/client.clj Exception in thread async-dispatch-6 java.lang.IllegalArgumentException: No implementation of method: :close! of protocol: #'clojure.core.async.impl.protocols/Channel found for class: nil at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:541) at clojure.core.async.impl.protocols$fn__779$G__774__784.invoke(protocols.clj:21) at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:818) at clj_tcp.client$client$fn__6374.invoke(client.clj:334) at clojure.lang.AFn.run(AFn.java:24) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Any ideas? -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: [ANN] Yesql 0.3.0 - Clojure SQL queries rethought.
This lib is a perfect fit here, we create adapter plugins for databases of various software suppliers. Being able to load the queries as resources is absolutely in line with how we handle these plugins, as optional configurable dynamically loadable components. Combined with views to return EDN data compliant with our business model it simplifies the support of these plugins. Thank you, great idea :) Luc P. Yesql is a simple library for blending SQL queries Clojure together, cleanly. Here's how it workshttps://github.com/krisajenkins/yesql#rationale, and how to use it https://github.com/krisajenkins/yesql#example-usage. Project: https://github.com/krisajenkins/yesql Leiningen: [yesql 0.3.0] New since v0.2.x: Support for multiple queries in a single file. Feedback welcomed, Kris -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: clojure.core.async java.lang.IllegalArgumentException
Maybe hidden in the go macro expanded code. I do not have access to it (iPhone). You may want to use macroexpand and grep on the expansion. Just take your go block and wrap it in (macroexpand '(your form)) Don't forget the quote. Maybe the expansion will shed some light. Do not panic on the look of the expansion, the code shuffling is kind of heavy. Luc I do not have a single close! statement in my code anywhere. I've double checked with grep -lhr close\! . through my whole codebase and all the projects in it. On Tuesday, 7 January 2014 21:05:53 UTC+1, Luc wrote: You are trying to close a nil channel. W/O the code it's all I can say :) Did you check to make sure you are not trying to handle nil as a channel ? Luc P. Hi, I'm getting the following error over and over again in my code, I've tried adding in some print statement and suddenly the error went away and my code worked again, then today I got the same error yet again. I suspect this might be a race condition or something similar. I can take the same library from the repl and it works, but when I use it from inside another app I suddenly get this problem error only at certain times. I've removed all close! statements from my code and I still get the same error :(, The code is https://github.com/gerritjvv/clj-tcp/blob/master/clj-tcp/src/clj_tcp/client.clj Exception in thread async-dispatch-6 java.lang.IllegalArgumentException: No implementation of method: :close! of protocol: #'clojure.core.async.impl.protocols/Channel found for class: nil at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:541) at clojure.core.async.impl.protocols$fn__779$G__774__784.invoke(protocols.clj:21) at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:818) at clj_tcp.client$client$fn__6374.invoke(client.clj:334) at clojure.lang.AFn.run(AFn.java:24) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Any ideas? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: clojure.core.async java.lang.IllegalArgumentException
Just got your email, I remember vaguely about this issue maybe when Tim did is presentation at fhe Conj. Or maybe on the mailing list. You may try what I described in my previous email and make your mind about this. Luc P. I've changed all of the go blocks to thread and got an exception that I cannot recur over a try catch. mm.. did not get this error in my go block. removing the recur's over try catch blocks makes the code work now with both go and thread. At least this is what I've changed now and the error has gone away. On Tuesday, 7 January 2014 21:55:06 UTC+1, Gerrit Jansen van Vuuren wrote: I do not have a single close! statement in my code anywhere. I've double checked with grep -lhr close\! . through my whole codebase and all the projects in it. On Tuesday, 7 January 2014 21:05:53 UTC+1, Luc wrote: You are trying to close a nil channel. W/O the code it's all I can say :) Did you check to make sure you are not trying to handle nil as a channel ? Luc P. Hi, I'm getting the following error over and over again in my code, I've tried adding in some print statement and suddenly the error went away and my code worked again, then today I got the same error yet again. I suspect this might be a race condition or something similar. I can take the same library from the repl and it works, but when I use it from inside another app I suddenly get this problem error only at certain times. I've removed all close! statements from my code and I still get the same error :(, The code is https://github.com/gerritjvv/clj-tcp/blob/master/clj-tcp/src/clj_tcp/client.clj Exception in thread async-dispatch-6 java.lang.IllegalArgumentException: No implementation of method: :close! of protocol: #'clojure.core.async.impl.protocols/Channel found for class: nil at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:541) at clojure.core.async.impl.protocols$fn__779$G__774__784.invoke(protocols.clj:21) at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:818) at clj_tcp.client$client$fn__6374.invoke(client.clj:334) at clojure.lang.AFn.run(AFn.java:24) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Any ideas? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=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. For more options, visit https://groups.google.com/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: core.async - extracting code from a go block
I would say use macros to avoid hiding calls from the go macro scope. Luc P. I recently discovered that parking calls only work if they're directly contained within a go block. So this works fine: (defn foo [ch] (go (! ch))) But this: (defn bar [ch] (! ch)) (defn foo [ch] (go (bar ch))) Results in Assert failed: ! used not in (go ...) block Is there any way around this? If I have a go block that's getting too big and want to extract some portion of it into a separate function, what's the best approach? -- paul.butcher-msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?
We added this as part of our standard logging, not only when exceptions are raised. It does help a lot in prod... Luc P. On Dec 27, 2013, at 11:33 PM, guns wrote: On Fri 27 Dec 2013 at 11:23:22PM -0500, Lee Spector wrote: On Dec 27, 2013, at 11:18 PM, guns wrote: (defmacro dump-locals [] ... ` When and where do you call this? I call this inside of the closest function that raised the exception. Ah, so you have to see an exception, edit your code to include a call to this, re-run, and get to the same exception. So it will only help for exception-raising situations that are easy to repeat, which mine often are not. Like you mentioned, I've heard nrepl-ritz does this in emacs, and David Greenberg has something like this set up for vim: https://github.com/dgrnbrg/vim-redl It would be really nice if this sort of thing -- dumping all locals when an exception is raised -- could be done in an IDE-independent way. FWIW my code is often running via lein run, and when one of those runs raises an exception I'd really like to get more information about what happened. -Lee -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: Is Clojure right for me?
Then we have more in common than you may think :) I learned Ruby first, went through Scala which appeared in the same time frame, all this to pick up the language of choice to replace Java and Ruby which we used to prototype our product. All this took around 9 months including the time to get the prototype working. Choose carefully... :) Luc P. The point is that Clojure is not the only modern language out there. I can't possibly learn them all in depth just to decide which language to use for my production code. That would be time-inefficient because my goal in not to learn languages, but to pick up a new language suitable for my needs. On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: This depends strictly on your learning speed which I will not comment here :) It took me three months full time to start to feel at ease with Clojure writing production code and I was around 45 years old at the time. Learning is never inefficient... when you want to learn. Luc P On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: Is Clojure right for me?
I would add that you *need* to write some code to get a feeling about a new language. Feature comparisons may help you up to a certain degree. However deciding about how efficient you may become using a new language requires you to dive at least a bit into it. Not all brains are wired the same. Luc P. Then we have more in common than you may think :) I learned Ruby first, went through Scala which appeared in the same time frame, all this to pick up the language of choice to replace Java and Ruby which we used to prototype our product. All this took around 9 months including the time to get the prototype working. Choose carefully... :) Luc P. The point is that Clojure is not the only modern language out there. I can't possibly learn them all in depth just to decide which language to use for my production code. That would be time-inefficient because my goal in not to learn languages, but to pick up a new language suitable for my needs. On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: This depends strictly on your learning speed which I will not comment here :) It took me three months full time to start to feel at ease with Clojure writing production code and I was around 45 years old at the time. Learning is never inefficient... when you want to learn. Luc P On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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
Re: Namespaces [was Re: Is Clojure right for me?]
We have a good basis with versioning. 99% of the time, workers are the ones accessing the configuration. They are at the top level. It happens that they do access configuration through the workers service name space. In fact through a single fn ... Passing a version number when pulling out a resource is feasible. This could override the default (the current config established at startup). I want to make it clear, we never intended to do this BUT it happens that we need a way to compare configs. It's not implemented yet. It maybe more or less an unconscious design decision that makes it easy to implement. Versioning is mainly a way for us to revert back to previous configs but it's also a way to fake an immutable config state. It's an operational requirement more than a code or design issue. Luc P. On Fri, Dec 27, 2013 at 10:35 AM, Softaddicts lprefonta...@softaddicts.cawrote: Passing this stuff around using one of the two methods you have shown would have been cumbersome and unmaintainable. Most of the time our configuration information comes from top level fns so the lower layers remain even more insensitive to how this info is pulled in. Agreed. Now imagine that one day you realize that you have a problem that can't be solved with one single configuration for the entire lifecycle of the program, but somehow, you have to process and compare results from two configurations simultaneously. What would you do? How painful would that change be? Is there something we can do to make this more feasible 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: Is Clojure right for me?
I am kind of old school. To me these things come through practice... Which I understand maybe of little help to you in the immediate future :) When I was young we had many books that had little to do with the ones mostly available today. (Learn xxx in nnn days) Looks to me that this is the missing piece in the puzzle. Not sure that this kind of book would be popular these days. Luc P. That makes me think that maybe there's a need for more books about Clojure. There are many introductory books but nothing more advanced such as best practices, patterns, etc... That's maybe a problem for someone like me who wants to do things right from the start. Should I read books about Common LISP and functional programming in general? On Friday, December 27, 2013 5:55:57 PM UTC+1, Luc wrote: It took us some time to structure the code at the time and now with protocols we went under a other restructuring a year ago. I agree this part can be hard (structuring the code) but at the time we started protocols were not yet there hence some of the restructuring. Best practices also evolved for a couple of years. It's much more stable these days. When I say write some code, well you need to choose a domain aside from simple things like hello world. Which makes it harder to write some code :) but forces you to question yourself about how to do this right the first time. This is the list of my favorite items that I keep an eye on: a) abstractions, choose them according to your business domain, do not try to re-invent the wheel or create alien terminology. This is a starting point to get your name space structure right. b) In your APIs try to stay generic by not assuming implementation details. This step can be hard to achieve. Keep doors opened. c) You may want to redefine the implementations of your abstractions or provide different flavors or some flexibility in your APIs. Protocols/multimethods become handy at some point here. This is the part that may feel a bit like OO but this is the one you have to think last. (remember point a and b) d) Do not hesitate to refactor. There's less code than in most other languages that get some support for refactoring from their IDE so you should not wait until it becomes a mess. If a name space is not rightly named anymore, chane it. If more separation of concerns is required, add/change name spaces accordingly and reorg the code. e) A good indicator of the stability of your APIs is how much your test code gets messed up when you do change something. It could be related to implementation details leaking out, bad choice in name space design, I am not an advocate of TDD but at some point when the code of a name space is stable enough, a few test cases can be used as health signs. f) Search for existing librairies, there are enough of them out there, either Java libs with/wo Clojure wrappers or Clojure centric ones to speed you up not having to rewrite the universe. g) Read the code of the libs you are pulling in as you go along. This will probably light a bulb in your brain about tricks you should apply to your code. The above should sound familiar :) It's not that different in Clojure to me than in many other languages. If you have some specific concerns, send them to me off line. I may share some code privately to answer some of your questions. Sorry for the other folks on this thread but there are copyright issues here :) Luc P. I've seen Clojure in action and I know it's extremely concise and expressive. What I wanted to know is how it copes with complexity when you develop complex systems. You can't get an idea of that just by writing some code and getting a feeling about the language, IMHO. When I studied OOP at University my professors taught me that OOP was extremely successful in reducing the complexity of big systems. I was given many examples of that in the many courses of software engineering I took. FP was relegated to some theoretical courses about paradigms. With such a background it's not easy to accept some of the things the Clojure community claim. The fact that I'm here asking questions should mean that I'm more open minded than most :) But please understand where I'm coming from. On Friday, December 27, 2013 3:50:23 PM UTC+1, Luc wrote: I would add that you *need* to write some code to get a feeling about a new language. Feature comparisons may help you up to a certain degree. However deciding about how efficient you may become using a new language requires you to dive at least a bit into it. Not all brains are wired the same. Luc P. Then
Re: Is Clojure right for me?
Been writing these on my iPhone most of the day and if I do not cut lines myself, it looks pretty ugly on my side :) I am pretty bad at writing poetry, glad to see I could fake at it :) Luc P. Luc, I've just got to say, your tiny margin widths always make me think your message is some kind of haiku :) On Fri, Dec 27, 2013 at 1:08 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: I am kind of old school. To me these things come through practice... Which I understand maybe of little help to you in the immediate future :) -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: Is Clojure right for me?
Agree, classes are not simple structures, they carry internal mutable state and hidden behaviours. Compounding mutable objects creates a huge brittled context were system state at any given point in time is untraceable by a normal human brain except in simplistic systems. Now you could create un mutable objects but then why bother creating classes with hidden behaviours if there is no hidden state ? Please explain then the advantage of using classes in this context versus name spaces to delimit concerns with high order functions ? How can you stick to both things at the same time ? Luc P. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: Is Clojure right for me?
This depends strictly on your learning speed which I will not comment here :) It took me three months full time to start to feel at ease with Clojure writing production code and I was around 45 years old at the time. Learning is never inefficient... when you want to learn. Luc P On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
I agree entirely with Korny's statements. As for concrete examples ? Hard to enumerate some, I can only say I agree after more than 30 years coding in various languages and finally getting out of Java hell. When I started there were a variety of dynamic languages used in the industry and given the kind of hardware we had at our disposal (more or less the power of today's cheap pocket calculator) the so-called Performance hit was rarely a problem. With the hardware available today, this is not a bigger issue than 25 years ago, except maybe for some highly specific problems. I saw enough typed language driven systems performing poorly to say that statically typed languages are not bullet proof performance wise. As for discovering significant errors, that's a false claim. So good a compiler may be, nothing can replace your brain. If the language and its related tools make your job so complex that your brain overloads then you are shooting yourself in the foot. Luc P. Do you guys have any concrete examples? Sent from my iPhone On 23 Dec 2013, at 10:13, Korny Sietsma ko...@sietsma.com wrote: This ties in nicely to my summary of how I feel about static typing: Static typing is a premature optimisation. Like most optimisations, it has genuine value, but if you apply it globally and too early, you end up causing more pain than you gain. sometime type discussions lead to lead to early and convenient detection of bugs - I'd agree with this; but in my experience, most of the bugs caught by type systems are relatively simple and straightforward, and not the sort of bugs that make it into production. I've almost never seen a _serious_ bug caused by dynamic typing - and I've seen plenty of serious bugs that type systems would not have caught. Static types also help with rapid IDE/compiler feedback of errors - but you often pay for this with slow compilation, especially when you need global type inferencing; and with complex (and often buggy) IDEs/compilers. I had huge pain getting the Scala IDEs to work reliably, last time I worked in Scala (admittedly this was a few years ago) - and they are still having lots of pain with performance, even though Scala doesn't have global type inference. Statically typed code generally performs better - but if there's one major rule I've learned in 25 years in IT, it's that code performance is not your real problem, 99% of the time. Your real problem is more likely to be IO, or poor algorithm design, or inefficient scalability, or slow speed of development, or difficulty diagnosing bugs, or unreadable unmaintainable code. I had people telling me that C++ was too slow, I should stick to C. Then, that Java was too slow, I should stick to C++. Then, that Ruby/JavaScript was too slow, I should stick to Java. None of these people were right. These days, I'd generally optimise first for expressive code so it's fast to develop and maintain; then for powerful flexible languages that can do anything I need them to do, and last for raw performance. I'm quite attracted by optional static typing, because it means I can rapidly code in a flexible dynamic language, and if I get to the point where I really need types, I can add them. But I suspect that most of the time, I'll never get to that point - or I'll use something like Prismatic Schema to define constraints at my external interfaces only, which is where I generally find I need them. - Korny On 23 December 2013 12:24, Richard Cole richard.j.c...@gmail.com wrote: The things is that dynamically typed languages are easier to implement than statically typed languages. Static typing comes down to making statements about the program and deriving other statements from them. It leads to all sorts of interesting work including I think into systems like Z. However theorem provers are limited in what they can do, and it can be both limiting and a big distraction to you as programmer to get into a dialogue with the theorem prover about your program. It can distract you from your original intention which was to write a program to do something in particular. So simply put, dynamic languages are better than static ones because they don't distract you with type discussions that can end up being unprofitable or limiting. Static languages are better because sometimes the type discussions lead to early and convenient detection of bugs and can also in some cases make it easier for other people to understand you program or how to use your library. Static types I think also help refactoring tools. Having optional typing in clojure is very nice. It allows for a lot of experimentation and research on type systems and for them to be used to the extent that people find them useful in their work. It is why I guess Alan Kay said that lisp is not a
Re: Is Clojure more functional then Scala?
In 2008 I was reviewing options, we had to move away from Java. I choose Clojure rather than Scala, I found Scala quite confusing. Attempts to pour in FP notions in an OO language looked too me as an attempt to transplant a fifth limb to a four limb made body. Since then I had a few discussions with Scala developers and the answers I got made it clear to me that choosing Clojure is a better choice. The common ground to these answers is 'do not use mutable collections', 'use values...','this is bad practice,...' I never got a satisfying answer to my counter questions 'then why offer all these features (mutation, objects, ...) easily accessible, if they are not to be used ? And how a newbie is suppose to know how to avoid all these sand traps ? If you want to use mutation in Clojure, it's doable but it also colors your code in a way that makes it obvious and exceptional somehow. Clojure sits at the frontier but with a bias toward FP while being pragmatic. We have a problem in this industry, features inflation. At some point it becomes useless to add not so natural features to a language. Scala is OO derived and adding FP features will not change it's DNA. Look at what Java 8 promises and it will end up in some form of chaos. Just thinking at what a mixed Java code base will look like in 10 years gives me nausea :) Yes there's a plan to make Cobol OO aware. It's not because it's doable that we should to do it. http://rotpier.over-blog.com/article-97207983.html Luc P. I jumped on the FP bandwagon over a year ago and have been using Scala both at work and for personal interest. Recently however I decided to take a closer look at Clojure and see if it is something i actually like. I have to admit at first the syntax form was awkward, but im starting to really see the simplicity behind it. I have heard many people claim that Clojure sets you up and supports you for FP more so then Scala does. However they never provide any examples of something Clojure does that is more supporting of FP then the way idiomatic Scala does it. Here are some things that I have heard people say when comparing Clojure vs Scala in reference to FP Clojure has immutable persistance data structures. but so does Scala Scala also tries to get you to use its immutable collections, like Vectors, and are also persistent data structures. However they are not as uniform as Clojures Seq i agree with that. Also Scala recommends using vals and not vars, which gives you immutable references points I am certainly learning towards dropping Scala for a bit and giving Clojure a real shot. The reason i even picked up Scala was because i wanted to learn more about FP, and if there is a better tool for both doing and learning FP then i want it. So tell me, if you have used both Scala and Clojure, do you have some real examples of some things where Clojure really does support you better when doing FP, where Scala really leads you no way, or worse the imperative way? -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: [ANN] overload-middleware 0.1.1
No, no, I can assure you, it's not an insult, you are well beyond. :))) -- toward the edge of the universe Luc P Is that intended as some sort of an insult aimed at me? I'm just pointing out that the web != everything that might conceivably be done with the HTTP protocol. The web is that thing you browse with Firefox, more or less by definition (even if sometimes tools like curl and wget are used as shortcuts when downloading files or scraping data off some site, and testing tools used to find dead links, and the like -- the web is that HTTP-served stuff whose *primary* interface is intended to be a web browser). So, for example, although the Gnutella file-sharing software uses HTTP under the hood for file transfers, it's not the web. On Sun, Nov 17, 2013 at 8:04 AM, Clinton Dreisbach clin...@dreisbach.uswrote: People, you are not going to win a fight with a Level 65 Troll Wizard. Back away slowly. Rob, this is a cool library: thanks for writing it. -- Clinton Dreisbach On Sun, Nov 17, 2013 at 7:53 AM, Cedric Greevey cgree...@gmail.comwrote: So, when people here are talking about the web, they might not be talking about the web. Erm, okay, I guess ... On Sun, Nov 17, 2013 at 7:11 AM, James Reeves ja...@booleanknot.comwrote: On 17 November 2013 05:25, Cedric Greevey cgree...@gmail.com wrote: On Sat, Nov 16, 2013 at 9:35 PM, James Reeves ja...@booleanknot.comwrote: On 17 November 2013 01:52, Cedric Greevey cgree...@gmail.com wrote: The distribution will be narrow and peak at around 1 second, though, which may not be what you want. Of course, the OP has since indicated that he meant non-web uses of HTTP rather than serving web sites... Web services are generally considered to be part of the web, hence the term *web* service :) Well, which is it? Either it's the web, and the user will probably promptly hit reload if faced with a 503 error at what should be a working URL, or else it's not the web, and lies outside the scope of my original remark. You're going to be very confused if you keep believing that the web only refers to the visible parts you can access through a browser! When people talk about web apps, they're not necessarily talking about websites. You just need to use your common sense to discern what they mean. If someone suggests something that might seem undesirable for a user-facing website to have, maybe they're talking about a machine-readable web service instead. - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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/groups/opt_out. -- -- 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/groups/opt_out. -- -- 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/groups/opt_out. -- -- 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
Re: .length vs. count for string length
I meant collection ... not sequence. Luc P. Strings are character sequences, count is a better option to stay within the sequence abstraction. Lic P. count does some type checks, but it's negligible in most cases as I already said. len can give a clear intention than count somtimes. I'm not suggesting that it should be included in clojure.string, but if count is currently not preferred over .length, including it can be a good option. On Wednesday, October 30, 2013 7:50:04 PM UTC+9, Baishampayan Ghose wrote: What'd clojure.string/len do any differently than clojure.core/count? count already provides does the fastest possible thing for strings. ~BG On Wed, Oct 30, 2013 at 4:14 PM, Alice doff...@gmail.com javascript: wrote: Which one is preferred? .length needs to be type hinted, so more verbose. The performance penalty of count is negligible in most cases. I think including len in clojure.string would be a good idea because it's used so often. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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/groups/opt_out. -- Baishampayan Ghose b.ghose at gmail.com -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: .length vs. count for string length
Strings are character sequences, count is a better option to stay within the sequence abstraction. Lic P. count does some type checks, but it's negligible in most cases as I already said. len can give a clear intention than count somtimes. I'm not suggesting that it should be included in clojure.string, but if count is currently not preferred over .length, including it can be a good option. On Wednesday, October 30, 2013 7:50:04 PM UTC+9, Baishampayan Ghose wrote: What'd clojure.string/len do any differently than clojure.core/count? count already provides does the fastest possible thing for strings. ~BG On Wed, Oct 30, 2013 at 4:14 PM, Alice doff...@gmail.com javascript: wrote: Which one is preferred? .length needs to be type hinted, so more verbose. The performance penalty of count is negligible in most cases. I think including len in clojure.string would be a good idea because it's used so often. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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/groups/opt_out. -- Baishampayan Ghose b.ghose at gmail.com -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: Any interest in Compojure/Ring screencasts?
Count me in, Luc P. I'm considering putting together a screencast, or a series of screencasts, based on my Functional Web Architecturehttp://skillsmatter.com/podcast/home/functional-web talk. The base presentation would be improved, and I'd probably wind up going into more detail on certain topics. I'll probably charge a small fee (perhaps $10 or so) to cover costs. Would there be any interest in this? - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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/groups/opt_out. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
Hopefully, we all knew it :))
And you should add that auto boxing
Is done on the literal, otherwise this
magic would not work.
Otherwise, Java would be the most
brittled language.
It probably is anyway :))
Luc P..
The string concatenation operator in java calls 'toString' on it's args.
---
Joseph Smith
j...@uwcreations.com
@solussd
On Oct 8, 2013, at 2:29 PM, Cedric Greevey cgree...@gmail.com wrote:
On Tue, Oct 8, 2013 at 8:49 AM, Nando Breiter na...@aria-media.com wrote:
If you try and add 10 to Hello in a typed language, you get an error.
Interesting. I hadn't realized that the following's language was not typed:
package foo.bar;
public class Main {
public static void main (String[] args) {
System.out.println(Hello + 10);
}
}
% javac Main.java
% java foo.bar.Main
Hello10
%
:)
--
--
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/groups/opt_out.
--
--
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/groups/opt_out.
--
Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
--
--
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/groups/opt_out.
Re: Coding Standard - ns usage
I just find this puzzling, the coding standards emphasizes reducing dependencies. Now if you add dependencies in your boiler plate that may in fact not be used by the source code in the current name space, how can a human reader understand your dependencies by reading the top nth lines of your source file ? This will worsen as your boiler plate expands. Why not require a utility name space (:use [my-boilerplate]) with a single public uniquely named macro (zxcv or any adjacent keys on your keyboard that you find easy to type) to get all that stuff on your behalf in the REPL ? Include this systematically and just type (zxcv) at the REPL. If you want to avoid the typing while in dev mode, add (zxcv) in the source code after the (ns) macro. It will require all the other things you need until you are done with it. No need to type it in the REPL anymore. Later on you can add the real dependencies in the ns macro. That can be the last step after your dev is done. It should sum up to a few requires with aliases. The zxcv is still available (requiring twice the same name space with the same alias has no bad effects) when you go back later at the REPL. I maintain that once you require a name space, is entirely loaded so the explicit narrowing of function used looks to me an overkill. Especially if you have an alias in your require call. There's no possible confusion with an alias and calls are can easily be searched as text strings which all IDEs support. Luc P. On Sun, 11 Nov 2012 20:44:24 +0100 Denis Labaye denis.lab...@gmail.com wrote: On Sun, Nov 11, 2012 at 6:02 AM, Softaddicts lprefonta...@softaddicts.cawrote: How does that shrink his boilerplate ? Why such a long boilerplate ? Do you need the string library everywhere ? Why not drop :only ? oftentimes, I am at the REPL, and I know this particular function in clojure.set (or clojure,io, or ...) is exactly what I need I want it at my fingertips, I don't want to break my flow and `require` it. And when creating a new namespace, I don't know in advance what other namespaces I will need. That's why I always paste the same boilerplate when creating a new namespace. In Java land, all IDEs have shortcut to import classes at the time it's needed, maybe that's what I need (in Emacs in my case). Luc P. Convert (:use [lib :only [...]]) = (:require [lib :refer [...] :as ...]) On Sun, Nov 11, 2012 at 12:49 PM, Denis Labaye denis.lab...@gmail.com wrote: Talking about `use` and `require`: How are you dealing with the repetition of each namespace configuration? Each time I create a new namespace I add the following boilerplate: (ns foo.bar (:use [clojure [pprint :only [pprint pp]] [repl:only [doc find-doc apropos]]] [clojure.java.javadoc :only [javadoc]] [clojure.tools.trace :only [trace deftrace trace-forms trace-ns untrace-ns trace-vars]]) (:require [clojure [set :as set] [string :as str] [xml :as xml]] [clojure.java [shell :as sh] [io :as io]])) How do you avoid repeating this ? A clojure macro?, IDE support?, ... ? On Fri, Nov 9, 2012 at 7:07 PM, Softaddicts lprefonta...@softaddicts.cawrote: Yep but still longer to type :) we are in the process of shrinking the code base, nit expanding it, any bytes count :)) On Fri, Nov 9, 2012 at 8:28 AM, Sean Corfield seancorfi...@gmail.com wrote: On Thu, Nov 8, 2012 at 3:19 PM, Softaddicts lprefonta...@softaddicts.ca wrote: Removing use would force us to redefine it somehow. (:use clojure.tools.trace) = (:require [clojure.tools.trace :refer :all) *sigh* no paredit in Gmail and I haven't had my coffee yet: (ns ... (:use clojure.tools.trace) = (:require [clojure.tools.trace :refer :all]) ...) but I'm sure y'all knew what I meant. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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
Re: Coding Standard - ns usage
This is the best I can come with in a short time: (ns higiebus.services.depcy-profiles Shortcut to common dependency profile) (defmacro basic-service-deps [] `(do (require [higiebus.services.config :as conf] [higiebus.services.loggers :as log] [clojure.string :as s]) (use [clojure.tools.trace]))) In the caller's name space: (ns higiebus.services.aqueduct Implement sinks and risers as abstractions on top of concrete transports. (:require [higiebus.adaptors.socket :as sock] [higiebus.services.queuemgr :as q]) (:use [higiebus.services.depcy-profiles])) (basic-service-deps) There is a bit of information loss but if the dependency profiles are correctly defined it's probably bearable and not to numerous. I am juggling with the idea of using this in our code base. Especially when using some service portfolios, we have to spell a litany of dependencies. Now, how far should I go with this requires some thinking. I can probably represent profiles as data and add some functions to report what they are made of, provide a single fn to load profiles by name, allowing to compound them, ... I'll play with this in the next couple of days. Luc On Sun, 11 Nov 2012 14:26:03 -0800 Mark Engelberg mark.engelb...@gmail.com wrote: I can relate to Denis' issue. I find it pretty common to have a common set of dependencies across every file in a project. Copying and pasting this header to every file and updating changes manually across every file doesn't feel like a very robust solution. This is something that has bothered me as well. -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
Louis, obviously there's a problem here, the REPL should return user= (map first [[1] [2]]) (1 2) As for my point about macros, it's not about the calls, it's about macro processing before spitting out the code that will be compiled, what would this return ? user= (defmacro mymac [func] (let [args (rest func)] `(- ~@args))) #'user/mymac Presently: user= (mymac (+ 1 2 3)) -4 What about (mymac + (1 2 3)) ? Would + (1 2 3) be considered as one argument ? Why ? How the compiler achieve this grouping ? If the macro argument involves a list ([body] being a common example) how do you decide what is a real list versus a call using your new syntax in the variable list of arguments ? If you cannot deal with this and have to force (mymac (+ 1 2 3)) when a macro is involved then what's the use of this new syntax ? What about embedded calls involving a mix of fns and macros ? I cannot see people having to dig to find out if some of these calls are macros versus fns and change the shape according to what is being called. You missed the point that I made about the fact that code is data and can be modified accordingly either through macros or runtime evaluations. Luc On Wed, 28 Dec 2011 01:59:12 +0800 Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: On Wed, Dec 28, 2011 at 1:46 AM, Louis Yu Lu louisy...@gmail.com wrote: The proposed syntax sugar does not break the existing code clojure.core= map(first [[1] [2]]) #core$map clojure.core$map@5ec3d2 [1] Ambrose -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Drift DB
Ahem, considering that I regularly alternate between MySql, Postgres and Oracle databases, I like the idea of just calling a pop menu like Create table (full) and let Aqua spit out the DDL in an adjacent window while having a database explorer pane on the left :) Memory becomes a pricey real estate after a certain age :) I use Eclipse/CCW for the same reason, having to navigate in a multilingual code base, I cannot see myself learning different tools for editing purposes or having to remember a significant amount of Emacs key shortcuts. For those that are screaming at me (or laughing ironically), I started using Emacs in 1981 on a DEC-20. This version was written in Teco, extending Emacs was weirder than just dealing with a few parenthesis imbrications. I suspect that some of you were not born yet or were crawling around wearing a diaper :) You will all get there eventually (now I am laughing very loudly :) Luc On Wed, 30 Nov 2011 09:54:26 +0200 Michael Wood esiot...@gmail.com wrote: Hi On 29 November 2011 07:03, Luc Prefontaine lprefonta...@softaddicts.ca wrote: [...] It yields in MySql: CREATE TABLE meta_entities ( id int(11) NOT NULL, name varchar(255) NOT NULL, created_at datetime NULL, updated_at datetime NULL, PRIMARY KEY(id) ) ENGINE = InnoDB AUTO_INCREMENT = 0 According to the AquaStudio tool I use to reverse engineer the DDL. Just by the way, MySQL supports this: SHOW CREATE TABLE meta_entities\G No need to reverse engineer the DDL for the tables :) -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Drift DB
Thank you,
Luc
On Wed, 30 Nov 2011 07:18:56 -0800 (PST)
Matt macourt...@gmail.com wrote:
This should now be fixed in version 1.0.6.
-Matt
On Nov 29, 12:03 am, Luc Prefontaine lprefonta...@softaddicts.ca
wrote:
Hi Matt,
working with this stuff... pretty sure I can make rake obsolete
pretty soon :)
However I am struggling with the auto increment column attribute...
(create-table
:meta-entities
(integer :id {:not-null true :auto-increment true :primary-key
true}) (string :name {:not-null true :unique true })
(date-time :created_at)
(date-time :updated_at))
which looks to me compliant with what your code does in the mysql
flavor lib.
It yields in MySql:
CREATE TABLE meta_entities (
id int(11) NOT NULL,
name varchar(255) NOT NULL,
created_at datetime NULL,
updated_at datetime NULL,
PRIMARY KEY(id)
)
ENGINE = InnoDB
AUTO_INCREMENT = 0
According to the AquaStudio tool I use to reverse engineer the DDL.
The trace message:
DEBUG Thread-51 2028 234732,063
drift-db-mysql.flavor ] Create table: :meta-entities with specs:
({:not-null true, :primary-key
true, :spec-type :column, :type :integer, :name :id} {:not-null
true, :spec-type :column, :type :string, :name :name}
{:spec-type :column, :type :date-time, :name :created_at}
{:spec-type :column, :type :date-time, :name :updated_at})
Looks like the :auto-increment is dropped. drift_db/core.clj at
line 155 is not selecting it as a potential attribute of an integer
field.
I'll patch it locally so I can continue to play with it.
Any reason why the id type does not accept optional attributes ? I
use id auto incremented keys everywhere :)
Thank you,
Luc
On Thu, 24 Nov 2011 14:58:43 -0800 (PST)
Matt macourt...@gmail.com wrote:
Drift DB is a clojure database library focused on migration
functions.
With Drift DB you can create tables, drop tables, add columns to
tables, remove columns from tables, query tables, and, though it
is not the focus of Drift DB, you can insert, update, delete and
select rows from tables.
The only databases currently supported are H2 and Mysql. However,
Drift DB uses a protocol to abstract out database specific code.
All you would have to do to support other databases is implement
the Drift DB protocol for it.
Drift DB, like Drift, was originally a part of Conjure. However,
I had several requests to separate out the function into their
own library.
Drift DB is not supposed to be a replacement for ClojureQL or
Korma. Instead, Drift DB is focused on table altering and other
tasks usually done in Drift migrations. Such tasks are currently
not well supported in any other Clojure database library.
All of the code for Drift DB can be found on github at:
http://github.com/macourtney/drift-db
Drift DB on Clojars:
Drift DB Core:http://clojars.org/org.drift-db/drift-db
Drift DB H2:http://clojars.org/org.drift-db/drift-db-h2
Drift DB Mysql:http://clojars.org/org.drift-db/drift-db-mysql
--
Luc P.
The rabid Muppet
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: [ANN] Drift DB
Hi Matt,
working with this stuff... pretty sure I can make rake obsolete pretty soon :)
However I am struggling with the auto increment column attribute...
(create-table
:meta-entities
(integer :id {:not-null true :auto-increment true :primary-key true})
(string :name {:not-null true :unique true })
(date-time :created_at)
(date-time :updated_at))
which looks to me compliant with what your code does in the mysql flavor lib.
It yields in MySql:
CREATE TABLE meta_entities (
id int(11) NOT NULL,
namevarchar(255) NOT NULL,
created_at datetime NULL,
updated_at datetime NULL,
PRIMARY KEY(id)
)
ENGINE = InnoDB
AUTO_INCREMENT = 0
According to the AquaStudio tool I use to reverse engineer the DDL.
The trace message:
DEBUG Thread-51 2028 234732,063 drift-db-mysql.flavor ]
Create table: :meta-entities with specs: ({:not-null true, :primary-key true,
:spec-type :column, :type :integer, :name :id} {:not-null true, :spec-type
:column, :type :string, :name :name} {:spec-type :column, :type :date-time,
:name :created_at} {:spec-type :column, :type :date-time, :name :updated_at})
Looks like the :auto-increment is dropped. drift_db/core.clj at line 155 is not
selecting
it as a potential attribute of an integer field.
I'll patch it locally so I can continue to play with it.
Any reason why the id type does not accept optional attributes ? I use id auto
incremented keys
everywhere :)
Thank you,
Luc
On Thu, 24 Nov 2011 14:58:43 -0800 (PST)
Matt macourt...@gmail.com wrote:
Drift DB is a clojure database library focused on migration functions.
With Drift DB you can create tables, drop tables, add columns to
tables, remove columns from tables, query tables, and, though it is
not the focus of Drift DB, you can insert, update, delete and select
rows from tables.
The only databases currently supported are H2 and Mysql. However,
Drift DB uses a protocol to abstract out database specific code. All
you would have to do to support other databases is implement the Drift
DB protocol for it.
Drift DB, like Drift, was originally a part of Conjure. However, I had
several requests to separate out the function into their own library.
Drift DB is not supposed to be a replacement for ClojureQL or Korma.
Instead, Drift DB is focused on table altering and other tasks usually
done in Drift migrations. Such tasks are currently not well supported
in any other Clojure database library.
All of the code for Drift DB can be found on github at:
http://github.com/macourtney/drift-db
Drift DB on Clojars:
Drift DB Core: http://clojars.org/org.drift-db/drift-db
Drift DB H2: http://clojars.org/org.drift-db/drift-db-h2
Drift DB Mysql: http://clojars.org/org.drift-db/drift-db-mysql
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: clojure libs and logging
Hi, Do you have the :disable-implicit-clean option set to false in your project.clj file ? If not, add it to remove the classes from dependencies that otherwise may pollute your target. As far as standard logging in a lib, it might be time to rely on clojure.tools.logging systematically. We do not use it here yet but at some point it will become unavoidable. Luc P. On Mon, 21 Nov 2011 21:10:31 -0800 (PST) Keith Irwin keith.ir...@gmail.com wrote: Folks-- I'm working on an experimental library which interfaces with external resources (i.e., not purely functional) and I'd like the library to log things when stuff goes wrong (say, with network connections). I don't want to throw exceptions and let clients handle it because I want to build in some automated reconnect stuff. Normally, I use clojure.tools.logging and add dependencies for log back. Works great. What's the standard way for including logging in a library? I've included clojure.tools.logging as a dependency, but the resulting jar (lein install), contains clojure.tools.logging classes. Is that okay, given any project its likely to be included in will also depend on clojure.tools.logging? Is there some way to do this? Is embedded logging (like Jetty has, for instance), just Not Done in the clojure library world? Keith -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure libs and logging
Oups, I'll look at it... we may have well upgraded Lein without reviewing project.clj options. We're about to deliver another version of our software so it's just about time to do that. On Tue, 22 Nov 2011 10:57:47 -0800 Phil Hagelberg p...@hagelb.org wrote: On Mon, Nov 21, 2011 at 9:10 PM, Keith Irwin keith.ir...@gmail.com wrote: What's the standard way for including logging in a library? I've included clojure.tools.logging as a dependency, but the resulting jar (lein install), contains clojure.tools.logging classes. Is that okay, given any project its likely to be included in will also depend on clojure.tools.logging? This is just a quirk of the Clojure compiler; there's currently no way to compile a namespace without compiling all its dependencies: http://dev.clojure.org/jira/browse/CLJ-322 Leiningen includes a workaround for this; you can set :clean-non-project-classes in project.clj, but it's not on by default since there are edge cases with protocols where it breaks. The option Luc mentioned is from an older version where it was turned on by default. It's best to avoid AOT compilation unless you need it. You can use the -m option to lein run to avoid having to declare your -main namespaces in project.clj: $ lein run -m clojure.main -Phil -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Overused phrases in the Clojure community
Maybe we should qualify non-idiomatic code as being idiotmatic, that may help reducing the # of posts referencing idiomatic. However this only a letter way from making (slight) mistakes in the posts :) I just spent my day's quota of idiotic writing ... Luc On Thu, 17 Nov 2011 11:22:27 -0600 Duane Searsmith dsearsm...@gmail.com wrote: Perhaps idiot-magic would sub? On Thu, Nov 17, 2011 at 8:30 AM, Sergey Didenko sergey.dide...@gmail.com wrote: I coded mutable Dejkstra algorithm isolated in a single function, because it's easier for me to maintain it - I used to write a lot of mutable algorithms. But I consider this code not idiomatic though useful in my case. So I think idiomatic Clojure code is not as ubiquitous as you probably mean and the word idiomatic is quite useful for discussions. In fact I challenge anyone to give an example of the least idiomatic code written in Clojure (using Java interop is cheating). -- 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 -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Conj extracurricular activities spreadsheet
Same for me. I'll find a spot depending on the final schedule. I would like myself to attend some of these meetings :) Luc P. On Mon, 07 Nov 2011 13:31:47 -0500 daly d...@axiom-developer.org wrote: Well, despite my best efforts I'm unable to edit the spreadsheet. The Literate Software talk was supposed to be at 7pm in the Presidents Ballroom but it appears that Pallet has reserved that time. I'll default to the old-fashioned BOF schedule board when I arrive to try to post a time and place. Tim Daly On Mon, 2011-11-07 at 11:18 -0500, David Nolen wrote: Anybody mind if the miniKanren / cKanren presentation happens at 6pm Thursday in the main ballroom? David On Mon, Nov 7, 2011 at 10:53 AM, Christopher Redinger redin...@gmail.com wrote: On Thursday, November 3, 2011 3:46:40 PM UTC-4, David Nolen wrote: Any thoughts about when / where these events can take place? Is it possible to get access to a projector? Or do we have to fend for ourselves? We have modified the contract with the hotel to keep the projector in the main ballroom on Thursday evening until midnight. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen: How to remove source code from uberjar
You have to make sure that all the dependencies you control are generated with :omit-source true But any dependency that has some clj files in its target will get bundled as is in the target jar. This includes Clojure itself,contrib, ... Luc P. On Thu, 3 Nov 2011 02:55:20 -0700 (PDT) finbeu info_pe...@t-online.de wrote: Hello is there a way to tell Leinigen not to include the source code into the uberjar? I just want to ship the class files (AOT compiled). Thx. Finn -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript and Counterclockwise?
I run cljs_watch in a terminal window at the top of the project and I defined .cljs files to use the CCW editor. cljs_watch spots the changed .cljs files through Eclipse and recompiles on the fly. Then I refresh the browser. It does most of the job. Luc P. On Thu, 27 Oct 2011 10:27:29 -0700 (PDT) Base basselh...@gmail.com wrote: Hi All - Do any of you happen to know if Counterclockwise supports the development of apps using ClojureScript? Thanks! Base -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Conj extracurricular activities spreadsheet
Hi, it's me again, new subject: Java Dependency Injection using Clojure, presentation. 30mns max including QA. if it extends will end this with a couple of drinks. Please add me to the ClojureScript talk, Pallet and ClojureCLR. I'll bring my clones with me :) Thank you, Luc On Tue, 25 Oct 2011 22:25:41 -0400 Michael Fogus mefo...@gmail.com wrote: We built quite a large list before the internet graffiti started taking over, so if you have an addition then please post it here and it'll be added. -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Conj extracurricular activities spreadsheet
Please add me to Clojure and the web, Luc P. On Tue, 25 Oct 2011 22:25:41 -0400 Michael Fogus mefo...@gmail.com wrote: We built quite a large list before the internet graffiti started taking over, so if you have an addition then please post it here and it'll be added. -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
CON1 - I'm buying your argumentation about consistency in Clojure maps and fixing them. Integer OBJECTS (as opposed to int primitive) should be handle as objects consistenly, not as primitive values promoted to long. CON2, CON3 and CON4 - No way, the current design choice is the good one. So many languages have been plagued with numbers of different sizes/formats for ints and floating point values, it's not a direction that Clojure should follow. These distinct types are source of many problems (overflow handling, precision problems, ...). The need for Clojure to support these things is similar to calling assembler from C. You matter about bytes, shorts and similar things at the frontier, when it's time to call a low level service, you need to be able to pass these values. By no means this implies that you have to support them in your language runtime. It complects (;) everything including computations and makes your runtime much more harder to port. It's an interop centric thing and interop is by essence not portable. It does not belong to the core of Clojure. It's better to rely on cast operators to call interop than to expect Clojure to box numeric values according to some interop convention that may vary according to the platform Clojure runs on. Luc P. On Sun, 23 Oct 2011 07:19:41 -0400 Paul Stadig p...@stadig.name wrote: On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway stuart.hallo...@gmail.comwrote: I am dropping off this thread now. At this point I think it would be more useful for me (or someone) to expand the notes about numerics into better documentation, rather than continuing this rambling point-by-point treatment without getting all of the considerations into play at once. I hope to get that done by conj. So you are still thinking that the current behavior is OK and just needs to be documented better? Or are you saying that we need to collect the various pros and cons to decide whether the current behavior should change or remain the same? Having reviewed the thread there is lots of confusion, but from the points made it seems clear to me that the behavior should change. CON (The we should box ints as Longs (or we should keep things as they are) camp): 1) If we box ints as Integers it will break Clojure's collections (Stu Halloway) 2) Boxing ints as Integers would make Clojure's design inconsistent (David Nolen) 3) Clojure now only has 64-bit primitives (David Nolen/Kevin Downey) 4) If 32-bit ints are allowed to exist, the Clojure's numeric operators would have to handle them (David Nolen) CON1 is a bug in PersistentHashMap, and I opened a Jira bug for it ( http://dev.clojure.org/jira/browse/CLJ-861). CON2 is false. The way primitives are boxed for interop doesn't and shouldn't have any effect on Clojure's design as such. This is a discussion about interop consistency, and if you look at the PRO section you will see Clojure is already inconsistent with respect to interop. Nathan and others are arguing that it should be made consistent. CON3 is false. 32-bit primitives do exist in Clojure (at least Java Clojure), they are just not the optimized case. They may get immediately converted to longs or boxed in some way, but we cannot deny their existence, especially around interop. CON4 Again, 32-bit integers do exist, and are already handled by the numeric operators. When you compile a function with primitive args, Clojure also generates a method that takes Objects. If you pass in anything other than a long it gets boxed, cast to a java.lang.Number, has its longValue method called, and that value gets passed to the primitive arg version. This is slow (as expected) because you are not using the optimized case (64-bit primitives). Absolutely none of that would have to change/get slower because ints were boxed as Integers instead of Longs. I think the problem with all of these CONs is that they confuse boxing for interop with either a bug in PersistentHashMap, or fast primitive maths, and neither of those has anything to do with how ints are boxed. PRO (The we should box ints as Integers camp): 1) Clojure is inconsistent in how it boxes primitive data (Chris Perkins) Clojure 1.3: (class (Long/parseLong 1)) = java.lang.Long (class (Integer/parseInt 1)) = java.lang.Long (class (Short/parseShort 1)) = java.lang.Short (class (Byte/parseByte 1)) = java.lang.Byte (class (Float/parseFloat 1)) = java.lang.Float (class (Double/parseDouble 1)) = java.lang.Double Paul -- Luc P. The rabid Muppet -- 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
Re: Clojure 1.3 treatment of integers and longs
On Sun, 23 Oct 2011 20:31:51 +0200 Ivan Koblik ivankob...@gmail.com wrote: Hello Luc, In all fairness I don't see how converting ints to Integers returned by class methods would break the abstraction. If you start talking about portability of Clojure code, then Long is as portable as Integer is. (In general they are not.) It's simpler to use one representation to port the core. You can choose the fastest/efficient one. You do not have to carry all these intermediate types with you. The day a 128 bits primitive type become available, there's little changes to do to support that. If you keep mixed types, that adds another one to the babel tower. The problem is not to choose between ints or longs, it has to do with carrying all these intermediate types. Frankly aside from interop, how many are using short ints in Clojure ? That's a leftover from the PDP-11 era. Could you explain your position on the fact that shorts get converted to Short? Why is it not possible to do the same for ints? This should disappear. I think all the small primitive types including ints should be promoted to long except when doing an interop call. Rich can explain why it's been kept. Maybe a question of priority/effort or something else. I don't think that there was anyone in this thread that would suggest keeping 32bit math in Clojure. For what it's worth, Integer can be converted to Long first time it is used in any computation. That is unnecessary overhead, again lets split boxed values from primitive types. If you compute in Clojure, keeping primitive ints/shorts/bytes around has no value. You end up having type conversion to do depending on what is specified in the expression. When doing an interop call, this is when you need to be specific. Elsewhere I see no value in keeping this scheme. This way of thinking about primitive types has been sticking around for at least 35 years carrying 64/32/16/8 bit unsigned/signed int values. Maybe it's time we toss this away. I have been writing a couple of hundred thousand lines of assembly code in my professional life and I understand this model. Of course when you deal with hardware in a device driver you need these things, but in Clojure ? And with today's hardware, why stick with these data types ? To reduce memory footprint ? Ha ! Ha !, I used to work on computers with 256K of physical memory. This concern was legitimate in this prehistoric era. But today ? If you need bit manipulation in Clojure, better write a lib for this than mangling with these data types. Cheers, Ivan. On 23 October 2011 17:16, Luc Prefontaine lprefonta...@softaddicts.cawrote: CON1 - I'm buying your argumentation about consistency in Clojure maps and fixing them. Integer OBJECTS (as opposed to int primitive) should be handle as objects consistenly, not as primitive values promoted to long. CON2, CON3 and CON4 - No way, the current design choice is the good one. So many languages have been plagued with numbers of different sizes/formats for ints and floating point values, it's not a direction that Clojure should follow. These distinct types are source of many problems (overflow handling, precision problems, ...). The need for Clojure to support these things is similar to calling assembler from C. You matter about bytes, shorts and similar things at the frontier, when it's time to call a low level service, you need to be able to pass these values. By no means this implies that you have to support them in your language runtime. It complects (;) everything including computations and makes your runtime much more harder to port. It's an interop centric thing and interop is by essence not portable. It does not belong to the core of Clojure. It's better to rely on cast operators to call interop than to expect Clojure to box numeric values according to some interop convention that may vary according to the platform Clojure runs on. Luc P. On Sun, 23 Oct 2011 07:19:41 -0400 Paul Stadig p...@stadig.name wrote: On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway stuart.hallo...@gmail.comwrote: I am dropping off this thread now. At this point I think it would be more useful for me (or someone) to expand the notes about numerics into better documentation, rather than continuing this rambling point-by-point treatment without getting all of the considerations into play at once. I hope to get that done by conj. So you are still thinking that the current behavior is OK and just needs to be documented better? Or are you saying that we need to collect the various pros and cons to decide whether the current behavior should change or remain the same? Having reviewed the thread there is lots of confusion, but from the points made it seems clear to me that the behavior should change. CON (The we should box ints as Longs (or we should keep things
Re: Clojure 1.3 treatment of integers and longs
Java != JVM. That's a too common mistake. Integer vs Long, Byte, ... are Java creations. They have nothing to do with the JVM primitive data types. Clojure implements a semantic different than Java on top of the JVM, why not ? That's the whole idea of having the JVM around. Abstracting the metal. Clojure reuses Java strings as is but it could have implemented its own on top of the char primitive type at the expense of less transparent interop. This is an implementation choice. It does not tie Clojure to Java. These are Clojure centric decisions. Lets get out Java out of this discussion. Clojure is not Java and even if it provides a soft bridge to reuse Java code, its feature set is certainly not Java centric. A Clojure persistent map is a ... Clojure data structure, not a Java data structure. Interfaces like java.util.Map have nothing to do with the content of the map itself. If they help make interop calls smoother fine. But do not tie their Java semantic to the Clojure semantic. It's unrelated outside of the interop domain. I do not care about Java centric stuff. I adopted Clojure to get away from Java ASAP. Luc P. On Sat, 22 Oct 2011 10:48:00 -0400 Paul Stadig p...@stadig.name wrote: On Sat, Oct 22, 2011 at 9:48 AM, Chas Emerick cemer...@snowtide.com wrote: If Clojure's primary objective were Java interop, I might agree with you. However, it's not, and it's bizarre to see someone argue that this is not broken: user= (.equals (Integer. -1) (Long. -1)) false Sure, not broken according to the Java object model and its equality semantics, but damn well broken if your standard is something other than what was canonized in java.lang.Object 20 years ago. 1 == 1 all the time — or, it should — regardless of the containers such integers incidentally find themselves within. From the beginning Clojure's story has been, why reinvent the wheel when there's this great JVM with a million man-months of engineering, and I do believe interop has been a huge objective. There are lots of existing libraries that can be used, and the whole Clojure integers are java.lang.Integers, and Clojure Strings are java.lang.Strings always seemed to me to be about interop and being a good, integrated citizen on the JVM. Of course I was not saying that 1 should not equal 1. I was saying that to be on the JVM you should adhere to the hashCode contract. And it's not the java.lang.Object equality semantics that are broken. The hashCode contract is a mathematical contract that you must follow if you want to implement a hash table in any language. Sure, Integer and Long seem to be weird in that they are not equal to each other when they are in the same range, but that's a problem with Integer and Long semantics, not java.lang.Object semantics. And you can't fix that problem by essentially rewriting/overriding the equals method for Integer and Long, and not also rewriting/overriding the hashCode method for those same classes. If you don't also override hashCode, then you get broken behavior as I demonstrated. Thus, Clojure's notion of equivalence, which leads to pleasantly consistent behaviour, e.g. (== (Integer. 1) 1 1N). Which, of course, doesn't preclude one using .equals if you truly want Java math semantics instead of = or == (neither of which have ever been advertised as adhering to the hashcode/.equals contract, at least since Clojure 1.0 IIRC). Clojure PersistentHashMaps are java.util.Maps, and to whatever extend Clojure defines new types on the JVM and implements an equals method for those types, it should also implement a hashCode method that adheres to the contract. If there are some common rough spots in the interop for certain use cases, perhaps those can be smoothed out with a library, maybe contributed by someone that acutely feels that pain. I don't intend to muddle the discussion, but only to point out that there are two separate issues: 1) the way collections behave when you use Longs that are in the Integer range. This is a problem with the implementation of PersistentHashMap, and unrelated to boxing ints as Longs. Boxing ints as Longs only hides the underlying issue that PersistentHashMap should not be using the default implementation of hashCode, but it's own implementation of equals. 2) ints being boxed as Longs. When you looks a Chris Perkin's post it certainly seems broken that ints are the *only* primitive that is not boxed into its java.lang equivalent. Also, AFAICT boxing ints as Integers would have no effect on the faster numeric maths. Paul -- Luc P. The rabid Muppet -- 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
Re: Clojure 1.3 treatment of integers and longs
a) Clojure does not to implement Integer, Byte, ... or any of the number
related Java classes.
It uses native JVM data types. The Integer class has nothing to do with the
JVM primitive types.
These are Java concepts. It has nothing to do with Clojure itself. It's
alien stuff.
Dunno why you insists on these. Clojure has not been designed to be a Java
superset.
It's a language of its own.
b) The way Java interprets equality based on the hash code is a Java specific
behavior.
It's defined by the Java API.
There's nothing in the jvm spec that defines how a hash code should be used.
It's a reference.
Nothing more.
All the contracts you mention are language centric, each of them defined their
contract according
to their own needs. Clojure should have the right to do so.
Clojure prefers to avoid having different rules than Java regarding number
handling ? Be so, it's legitimate.
If people like you were free to take these decisions we would end up with three
different languages, one on the
jvm, one on CLR and one on JS. Nonsense. Having to deal with three different
interops and trying to
unify them a bit is enough work by itself.
Interop stuff is low level and should remain there. If a single interop
implementation starts to influence
the Clojure language and result in such short term and narrow scope decisions,
we will all have a problem
in the future.
Luc P.
On Sat, 22 Oct 2011 15:04:33 -0400
Paul Stadig p...@stadig.name wrote:
On Sat, Oct 22, 2011 at 1:49 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
Java != JVM.
That's a too common mistake. Integer vs Long, Byte, ... are Java
creations. They have nothing to do with the JVM primitive data
types.
Clojure implements a semantic different than Java on top of the
JVM, why not ?
That's the whole idea of having the JVM around. Abstracting the
metal.
Clojure reuses Java strings as is but it could have implemented its
own on top of the
char primitive type at the expense of less transparent interop.
This is an implementation choice.
It does not tie Clojure to Java.
Um...I guess I don't understand how what you're saying is relevant.
Are you saying that Clojure should implement it's own Byte, Short,
Integer, and Long? If you are, then the hashCode contract should be
obeyed. If you're not, then it's fine for PersistentHashMap to
redefine equals for java.lang.{Byte,Short,Integer,Long}, but hashCode
should also be redefined.
The hashCode contract is not a Java thing, it is a JVM thing, and in
fact (as I mentioned before) it is a mathematical contract that you
must obey to implement a hash table in any language and on any
platform.
Python has a similar contract
http://docs.python.org/reference/datamodel.html#object.__hash__
C# has a similar contract
http://msdn.microsoft.com/en-us/library/system.object.gethashcode.aspx
Common Lisp has a similar contract
http://www.lispworks.com/documentation/HyperSpec/Body/f_sxhash.htm#sxhash
The brokenness of PersistentHashMap with respect to the hashCode
problem has nothing to do with Java (or even the JVM).
These are Clojure centric decisions. Lets get out Java out of this
discussion.
Clojure is not Java and even if it provides a soft bridge
to reuse Java code, its feature set is certainly not Java centric.
A Clojure persistent map is a ... Clojure data structure, not a
Java data structure.
Interfaces like java.util.Map have nothing to do with the content
of the map itself.
If they help make interop calls smoother fine. But do not tie their
Java semantic to
the Clojure semantic. It's unrelated outside of the interop domain.
I do not care about Java centric stuff. I adopted Clojure to get
away from Java
ASAP.
The reality is that PersistentHashMap does implement j.u.Map, and as
much as possible Clojure tries to live at peace with other
classes/objects on the JVM. There will always be some level of
interop and semantics that must be matched with the platform. If you
want to totally avoid Java, then I don't think Clojure is going to
help you. It's not just a coincidence that Clojure strings are
java.lang.Strings, and there are probably many people who would not
have found Clojure as compelling if it didn't have a great interop
story, and the ability to access a huge set of existing libraries. I
feel like this is drifting off topic though.
Coming back to the original issues:
1) PersistentHashMap should be using a hashing function that is
congruent with the equals function it uses.
2) Boxing ints as Longs sticks out when every other primitive is
boxed into its java.lang.* equivalent.
3) Boxing ints as Integers would not have any adverse effect on the
improvements to primitive maths.
I'd be glad to help out with any of this.
Paul
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Re: Clojure 1.3 treatment of integers and longs
The contract in Clojure is clear, they are only long integer values except if
you cast
them accordingly for Java interop purposes. Anything else is a long so there
are no
contract breaches.
It's not a platform issue, it's a Java issue. Equality is implemented by Java
for objects.
It has nothing to do with Clojure which uses primitive types like long for
numeric representation.
user= (= 1 (int 1))
true
user= (.equals 1 (int 1))
true
user= (.equals (long 1) (int 1))
true
user= (.equals (Long. 1) (Integer. 1))
false
Where's the contract breach here ? Don't mention breaking the Java contract in
the two first
examples. You are in Clojure's playground here, arithmetic primitive types (not
classes) are getting promoted
according to Clojure's rules.
The third one starts in Clojure's playground were the same promotion occurs and
both values get boxed to Long for interop purposes (.equals on java objects)
and the result
satisfies the Java contract.
The fourth one is not in Clojure's playground, it's pure Java and it also
respects the Java contract
between comparing objects, not primitive jvm types.
Were's the problem ? The Java contract is respected as soon as you dive in Java.
It's the same here:
user= (class (key (first { (int 1) :a})))
java.lang.Long
You create a Clojure map with a numeric key, the key gets promoted from
primitive int to primitive long.
As soon as you jump in interop, you get a Long object key. Obviously, the map
comes from the Clojure's
playground but java cannot cope with primitive types in keys, you need an
object so Clojure boxes
accordingly to a Long object.
user= (class (key (first { (Integer. 1) :a})))
java.lang.Integer
user=
Here you decide to create a key type from the Java world (a Java object) and it
gets preserved so you
ship the map to a Java call for interop.
Were are the contract breaches ? Aside from the fact that Clojure implements a
contract of its own
and respects it, there are no breaches.
You have been mixing Java objects with primitive types defined by the JVM since
you entered this
discussion. It's two different things.
On Sat, 22 Oct 2011 16:06:04 -0400
Paul Stadig p...@stadig.name wrote:
Luc,
On Sat, Oct 22, 2011 at 3:40 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
All the contracts you mention are language centric, each of them
defined their contract according
to their own needs. Clojure should have the right to do so.
The contract is required for implementing any kind of hash map
anywhere. This is not Java or the JVM influencing Clojure to do
something it wouldn't have otherwise. The references were examples to
show that widely varied languages/platforms agree: if you want to
implement a hash map in any language on any platform, then when two
objects are equal their hashCodes should be equal.
I'm fine with changing the Java semantics with respect to Integer and
Long equality, BUT if we're going to change equality, then the
hashing function has to be congruent with that equality function. If
equals and hashCode are not congruent, on any platform, in any
language, anywhere, then you do not have a hash map, you have a
broken hash map. You can see the brokenness in the example code I
posted.
Clojure prefers to avoid having different rules than Java regarding
number handling ? Be so, it's legitimate.
I'm not arguing against that. I'm saying make the equality different,
BUT you also have to make the hashCode function congruent.
If people like you were free to take these decisions we would end up
with
three different languages, one on the
jvm, one on CLR and one on JS. Nonsense. Having to deal with three
different interops and trying to
unify them a bit is enough work by itself.
Interop stuff is low level and should remain there. If a single
interop implementation starts to influence
the Clojure language and result in such short term and narrow scope
decisions, we will all have a problem
in the future.
I mean, again, I don't understand why you're saying this. I agree
interop needs to exist and to be at a low level. The question is,
given that some form of interop must exist, how should it work?
Right. The discussion that we're having here is about how Java
interop should work. I don't think it makes sense to come in and say,
that we can't let Java and the JVM influence how we interop with Java
and the JVM. Perhaps you are misunderstanding me, or I you.
I'm saying given that there must be some form of interop, it does not
make sense to box ints as Longs. And the decision to box them as
Integers instead should not have any effect on the semantics of
anything. Two objections have been raised against boxing ints as
Integers so far: 1) it breaks Clojure's collections, and 2) it would
have bad effects on the new faster primitive maths.
I'm saying: 1) Clojure's PersistentHashMap is broken because it is
using incongruent equals and hashCode methods
Re: Clojure 1.3 treatment of integers and longs
Your example is so short that I cannot replicate it:
user= (def a (hash-map -1 :a))
#'user/a
user= (def b (array-map -1 :a))
#'user/b
user= (= a b)
true
user= (= (key (first a)) (key (first b)) -1)
true
I said to myself, Ok he's been throwing some ints in there:
user= (def a (hash-map (int -1) :a))
#'user/a
user= (def b (array-map -1 :a))
#'user/b
user= (= a b)
true
user= (= (key (first a)) (key (first b)) -1)
true
Still ok.
Now if you have been using Integer and Long objects as key, of course maps will
not match.
You are using Java objects as keys, not primitive types. You're not in
Clojure's playground
anymore, half of your map is in Java's own sandbox.
What's missing from your shortened example ?
On Sat, 22 Oct 2011 14:23:24 -0700 (PDT)
Chris Perkins chrisperkin...@gmail.com wrote:
On Saturday, October 22, 2011 4:31:29 PM UTC-4, Luc wrote:
Where's the contract breach here ?
Glad you asked. Consider the following clojure session (1.3),
shortened for your reading pleasure:
map-1 = {-1 :yo}
map-2 = {-1 :yo}
key-1 = -1
key-2 = -1
Just some simple maps and values, right?
(= map-1 map-2) = true
(= key-1 key-1 -1) = true
Yup, they're the same. But:
(map-1 key-1) = :yo
(map-2 key-1) = :yo
(map-1 key-2) = :yo
(map-2 key-2) = nil
Oops! Despite being equal, the two maps behave differently. Why?
(class map-1) = clojure.lang.PersistentArrayMap
(class map-2) = clojure.lang.PersistentHashMap
(class key-1) = java.lang.Integer
(class key-2) = java.lang.Long
Unless I am mistaken, the difference between an ArrayMap and a
HashMap is supposed to be an implementation detail - an optimization.
I'm sure that they shouldn't have different semantics. But when
hashCodes and equality do not agree, this is the sort of thing that
can happen.
Note that I'm not claiming to have any deep insights into what's
broken and what's not, either in Clojure or in Java. All I'm saying
is that claiming anything along the lines of Clojure is not Java, so
we can do whatever we want - contracts do not apply does not lead to
sane map behavior. Those contracts were created for a reason.
To be honest, I've sort-of lost the plot of how this is related to
the boxing-ints-as-Longs issue, but that's probably due to both my
lack of expertise in this area and to the generous glass of whiskey I
had while watching Megamind with my kids this afternoon. But I
digress. The point I think I was trying to back up is if clojure
changes equality semantics, it should change hashcodes to match.
That sounds right to me.
- Chris
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
Ha ! Ok, I missed the digression here and I now understand the issue.
Considering that a PersistentArrayMap may eventually become a PersistentHashMap
this opens the door to *funny* bugs.
Is this the only known case ?
Luc
On Sat, 22 Oct 2011 18:55:52 -0400
Paul Stadig p...@stadig.name wrote:
On Sat, Oct 22, 2011 at 5:42 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
What's missing from your shortened example ?
I think what you want is the example I posted originally:
user= (get {(Long. -1) :here} (Integer. -1))
:here
That works fine because you are actually creating an
PersistentArrayMap, which does not care about hash codes. However,
when you use a PersistentHashMap you see were things break down
because the hashing function and the equality function that
PersistentHashMap is using are not congruent (i.e. they break the
hashing contract):
user= (get (clojure.lang.PersistentHashMap/create {(Long. -1) :here})
(Integer. -1))
nil
user= (get (clojure.lang.PersistentHashMap/create {(Long. 0) :here})
(Integer. 0))
:here
This happens because PersistentHashMap does not use .equals to
compare keys, however it does use .hashCode to hash the keys. So it's
fine to not use .equals and define Clojurey semantics for integer
comparisons, but if we're not using .equals, then we should not be
using .hashCode, and instead redefine .hashCode with Clojurey
semantics as well. The contract that is being broken is the contract
for hashing, not equality.
This problem has nothing to do with Java interop. I has nothing to do
with the Java language or the JVM. It has nothing to do with whether
ints are boxed as Integers or Longs. What is happening is
PersistentHashMap is supposed to be an implementation of an abstract
Computer Science data structure called a hash table, and for a hash
table to work correctly the following must be true: if two keys are
equal, then their computed hash values for those keys should be equal.
The reason we wandered into this is because one of the objections
that has been raised against boxing ints as Integers is that doing so
would break Clojure's collections. What I have been trying
(unsuccessfully I gather) to communicate is that PersistentHashMap is
broken in and of itself, and boxing ints as Longs only hides the
issue. Boxing ints as Longs makes it less likely that you would
actually be using an Integer as a key, because you have to explicitly
ask for an Integer. However, if you explicitly ask for an Integer you
still get the broken behavior, because PersistentHashMap needs to be
fixed.
Bottom line: changing Clojure to box ints as Integers would not break
Clojure's collection, but Clojure's collections need to be fixed to
use a hashing function that is congruent with their equality function.
Paul
--
Luc P.
The rabid Muppet
--
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
