Why the CLR languages fail?
Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight? Chas did a survey in 2012, which gave very negative results for clojureCLR, with 70% people having no motivation to even play with it, and almost no production use. How can ClojureCLR be protected from dwindling? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Why the CLR languages fail?
On Jun 5, 2013, at 23:55, Zed Becker wrote: Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight? I have a theory for your consideration. Consider the case of (say) MacRuby, which was sponsored by Apple for several years. It had a great deal of good work done on it, mostly by Laurent Sansonetti. However, despite earnest pleas by Laurent's manager, Jordan Hubbard, only a few folks in the user community jumped in to lend a hand. Basically, I think it's very hard for a company to jumpstart an open source development effort, particularly if the company is seen as being large, wealthy, etc. Too bad, really... -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Why the CLR languages fail?
On Thu, Jun 6, 2013 at 9:55 AM, Zed Becker zed.bec...@gmail.com wrote: Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight? N.B. - Not all is well on top of the JVM. Jython, the Python implementation, tends to die and get revived and then it dies again. I don't know the state of IronPython right now, but it was in much better shape when I last looked at it. The JVM is more popular for other languages though. There are multiple issues at play here. Language authors prefer the JVM as a target, as it's easier to bootstrap a new language on top of the JVM. The JVM as a target is much friendlier to other languages, compared to the CLR, in spite of the initial hype surrounding the CLR's multi-language capabilities. There's also the huge open-source Java ecosystem to blame. For everything you want to do, there's already a library that you can build on top of (Netty is a stellar example, being used all over the place). Also, many language authors would like to support both, but they lack the resources to do it, so they end up picking one and stick with it. Then there's the audience. Unix has always been a true tower of Babel for programming languages (that's why it has a Shebang). And the JVM has and always had first-class support for Unix variants, including Linux, BSD and OS X. People that target Unix for deployments (web apps, mobile apps) or people that use Unix on their workstations accustomed to Unix toolchains, will always prefer tools that are first-class in Unix. Having true cross-platform support and not having to recompile is pretty sweet too. Then there are also the Java developers that are fed up with Java, the programming language, but love the JVM, the tooling available and the Java ecosystem (such as myself). So Unix is like a tower of Babel for programming languages, but the .NET ecosystem is the exact opposite. .NET developers that want to pick alternatives to C# have an uphill battle to do against the status quo, as .NET developers and companies tend to be pretty conservative. The uptake of F# has been abysmal compared to JRuby, even though F# is included in Visual Studio and classic ASP.NET is still more popular than ASP.NET MVC. JRuby is an interesting case-study. It is popular because it's used as a deployment target for web applications (Rails runs well on top of it), quickly becoming the de-facto standard, as more and more people start realizing how awesome it is compared to Ruby MRI in a server-side environment. With each release, performance has been improved by leaps and bounds. So it won converts that normally live in the Ruby ecosystem and had no interest in Java or the JVM. Also, JRuby is a community-driven project, sponsored by multiple companies involved in the Ruby ecosystem, born out of real necessities and that thrived because it was designed to fit well within the existing Ruby ecosystem. IronRuby, a project started by Microsoft for demoing the DLR library, never stood a chance to catch up with it. -- Alexandru Nedelcu https://bionicspirit.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.
Re: Why the CLR languages fail?
*The JVM as a target is much friendlier to other languages, compared to the CLR, in spite of the initial hype surrounding the CLR's multi-language capabilities.* I'm not sure this is true, Don Syme has written several times about how difficult it would be to implement F# on the JVM - I believe tail recursion and not being able to define new intrinsic types (i.e. new primitives) are the sticking points. I think a lot of people believe that from a functionality point of view the CLR is better than the JVM - as far as I know it's not missing any functionality from the JVM and it has significant advantages (reified generics as well as the functionality mentioned above). That said, I agree with most of what you say. But it's not just the deployment and UNIX toolchain, it's also the development OS. I don't run Windows nor do I want to, but if I don't the development tooling for .NET languages is terrible. Even if Mono were a respectable JVM competitor for deployment (and it may be, I hear it's pretty good these days) there is no decent environment for writing C# or F# on OSX. Which is a shame, C# is a much nicer language than Java. So although I love the look of F# I've never seriously played with it, which means I'll almost certainly never use it for any real work. Cheers, Colin On 6 June 2013 20:14, Alexandru Nedelcu m...@alexn.org wrote: On Thu, Jun 6, 2013 at 9:55 AM, Zed Becker zed.bec...@gmail.com wrote: Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight? N.B. - Not all is well on top of the JVM. Jython, the Python implementation, tends to die and get revived and then it dies again. I don't know the state of IronPython right now, but it was in much better shape when I last looked at it. The JVM is more popular for other languages though. There are multiple issues at play here. Language authors prefer the JVM as a target, as it's easier to bootstrap a new language on top of the JVM. The JVM as a target is much friendlier to other languages, compared to the CLR, in spite of the initial hype surrounding the CLR's multi-language capabilities. There's also the huge open-source Java ecosystem to blame. For everything you want to do, there's already a library that you can build on top of (Netty is a stellar example, being used all over the place). Also, many language authors would like to support both, but they lack the resources to do it, so they end up picking one and stick with it. Then there's the audience. Unix has always been a true tower of Babel for programming languages (that's why it has a Shebang). And the JVM has and always had first-class support for Unix variants, including Linux, BSD and OS X. People that target Unix for deployments (web apps, mobile apps) or people that use Unix on their workstations accustomed to Unix toolchains, will always prefer tools that are first-class in Unix. Having true cross-platform support and not having to recompile is pretty sweet too. Then there are also the Java developers that are fed up with Java, the programming language, but love the JVM, the tooling available and the Java ecosystem (such as myself). So Unix is like a tower of Babel for programming languages, but the .NET ecosystem is the exact opposite. .NET developers that want to pick alternatives to C# have an uphill battle to do against the status quo, as .NET developers and companies tend to be pretty conservative. The uptake of F# has been abysmal compared to JRuby, even though F# is included in Visual Studio and classic ASP.NET is still more popular than ASP.NET MVC. JRuby is an interesting case-study. It is popular because it's used as a deployment target for web applications (Rails runs well on top of it), quickly becoming the de-facto standard, as more and more people start realizing how awesome it is compared to Ruby MRI in a server-side environment. With each release, performance has been improved by leaps and bounds. So it won converts that normally live in the Ruby ecosystem and had no interest in Java or the JVM. Also, JRuby is a community-driven project, sponsored by multiple companies involved in the Ruby ecosystem, born out of real necessities and that thrived because it was designed to fit well within the existing Ruby ecosystem. IronRuby, a project started by Microsoft for demoing the DLR library, never stood a chance to catch up with it. -- Alexandru Nedelcu https://bionicspirit.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
sorted-map-by issue?
user= (sorted-map-by (constantly 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil user= (keys (sorted-map-by (constantly 1) :b 1 :a 2)) (:b :a) user= (count (sorted-map-by (constantly 1) :b 1 :a 2)) 2 user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil It looks so strange.The result map has keys :a and :b,but i can't get their values. Why? I try to hack the code,but i can't find the reason. -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] alpacas: a new Clojure source viewer
Laurent PETIT laurent.pe...@gmail.com writes: 2013/6/5 John Gabriele jmg3...@gmail.com: On Tuesday, June 4, 2013 4:24:49 PM UTC-4, Gary Trakhman wrote: Just fyi, most clojure libs are published under EPL or Apache licenses, of course the choice is up to you :-). GPL has some restrictions that would prevent the lib from being used in many projects. from the EPL wikipedia page: 'The EPL 1.0 is not compatible with the GPL, and a work created by combining a work licensed under the GPL with a work licensed under the EPL cannot be lawfully distributed.' LGPL is also a fine choice for Clojure libs. Given that it is by default suggested to use the EPL for Open Source Clojure projects, what would be the incentive to use LGPL. tl;dr: when should I prefer LGPL over EPL for a Clojure lib ? If you don't like the terms of the EPL. In particular, the choice of law clause in EPL makes it, I think, a poor choice under many circumstances. Why would I want my software license to use the law of a foreign country which I have no control over? You could also use GPL, if you wanted a strong copyleft, as linking to the core Clojure libraries is covered by the standard interface clause; likewise, you can write GPL code in Java, or C, even if the core language is not GPL. However, this would prevent you from building a single combined work with libraries that used EPL. Or you could use a BSD style license, which has no copyleft restrictions. So, if you don't like the patent retaliation clause in EPL, or the idea that derivative works of the library must themselves be EPL, then this would be a good choice. Licenses are a pain; but they do have different implications and different protections. But, it not that much more difficult than learning the semantics of a programming language. Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: sorted-map-by issue?
Sorry, it's my mistake. Because treep map use the comparator to compare keys, and if the comparator returns 1 constantly,it can not find the item that equals the key. So i can modified the example,and it works: user= (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 2 user= (:b (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 1 2013/6/6 dennis zhuang killme2...@gmail.com user= (sorted-map-by (constantly 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil user= (keys (sorted-map-by (constantly 1) :b 1 :a 2)) (:b :a) user= (count (sorted-map-by (constantly 1) :b 1 :a 2)) 2 user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil It looks so strange.The result map has keys :a and :b,but i can't get their values. Why? I try to hack the code,but i can't find the reason. -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
No bit shift for clojure.lang.BigInt ?
Hi, I wanted to shave a few cycles of a (quot n 2) by using (bit-shift-right n 1) instead, with n being a bigint. However, this fails with an IllegalArgumentException bit operation not supported for: class clojure.lang.BigInt clojure.lang.Numbers.bitOpsCast (Numbers.java:1008). Since the underlying java types would support this [*], is there a good reason not to have those operators in clojure.lang.BigInt ? Best Regards B. [*] http://docs.oracle.com/javase/6/docs/api/java/math/BigInteger.html#shiftRight%28int%29 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
[ANN] Just one more day to submit a proposal to Clojure/conj 2013!
Hey All, The CFP for Clojure/conj 2013 closes tomorrow, June 6 at 5 PM EST. http://clojure-conj.org/call-for-proposals Clojure/conj 2013 Alexandria, VA (D.C. Area) November 14-16, 2013 All speakers receive a conference ticket, lodging at the conference hotel, airfare stipend and an invitation to the Speaker's Dinner. www.clojure-conj.org Thanks! Lynn from Relevance -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Utility libraries and dependency hygiene
puzzler wrote: I decided it would be a bad idea to include rhizome directly in instaparse's dependencies. Nevertheless, it made sense to enable the visualize function *provided* rhizome was already in the user's dependencies. I prefer to avoid these kinds of load-time tricks, as they break easily when anything else is involved in loading code, e.g. an IDE or app server. Fortunately, Rhizome is driven by data. If you can provide functions that return the data structures that Rhizome expects, then Instaparse users can easily invoke Rhizome themselves to get the visualizations. If this is not possible, I would suggest providing the visualization tools as a separate library release which depends on both Instaparse and Rhizome. This might make sense anyway, if they are intended only as a development-time tool. -S -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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: Making things go faster
Note that the problem is actually the Clojure startup time, *not* the JVM startup. JVM starts up in about 0.1sec on my machine. The rest of the time is spend loading Clojure code, compiling all the core namespaces etc. That's one way to look at it, another is that clojure's design tightly integrates with the implications of java's tradeoffs. Classloading and initialization can take a big chunk of time, even on AOT code, and clojure's decision to map directly to those constructs exacerbates the problem (though it's worth it for most apps). Any time I make a command-line launcher, I spend some time writing a shim that uses this code to defer loading components until necessary: (defmacro deferred Loads and runs a function dynamically to defer loading the namespace. Usage: \(deferred clojure.core/+ 1 2 3)\ returns 6. There's no issue calling require multiple times on an ns. [fully-qualified-func args] (let [func (symbol (name fully-qualified-func)) space (symbol (namespace fully-qualified-func))] `(do (require '~space) (let [v# (ns-resolve '~space '~func)] (v# ~@args) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: sorted-map-by issue?
Your comparator #(if (= %1 %2) 0 1) may happen to give the correct answers for your example sorted-maps, but it is also a bad comparator that will fail for larger examples: user= (:a (sorted-map-by #(if (= %1 %2) 0 1) :z -26 :b 1 :a 2 :c 3 :m 13 :h 8)) nil user= (:z (sorted-map-by #(if (= %1 %2) 0 1) :z -26 :b 1 :a 2 :c 3 :m 13 :h 8)) nil That is because if two items are not =, by returning 1 you are telling the caller the first argument should come after the second argument. Thus if at some time the comparator is called as (cmp :a :z), and later it is called as (cmp :z :a), it returns the inconsistent results that :a should come after :z, and later that :z should come after :a. No sorted tree can hope to return correct results given such an inconsistent comparator. More examples and discussion at the link below, if you are interested: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md Andy On Thu, Jun 6, 2013 at 4:19 AM, dennis zhuang killme2...@gmail.com wrote: Sorry, it's my mistake. Because treep map use the comparator to compare keys, and if the comparator returns 1 constantly,it can not find the item that equals the key. So i can modified the example,and it works: user= (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 2 user= (:b (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 1 2013/6/6 dennis zhuang killme2...@gmail.com user= (sorted-map-by (constantly 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil user= (keys (sorted-map-by (constantly 1) :b 1 :a 2)) (:b :a) user= (count (sorted-map-by (constantly 1) :b 1 :a 2)) 2 user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil It looks so strange.The result map has keys :a and :b,but i can't get their values. Why? I try to hack the code,but i can't find the reason. -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Re: Why the CLR languages fail?
On Wed, Jun 5, 2013 at 11:55 PM, Zed Becker zed.bec...@gmail.com wrote: Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) FWIW -- Scala on the CLR has always been a Microsoft funding issue. When Martin's lab got a grant for ScalaCLR, it did the work. When the funding went away, the work stopped. There was never a large pull to Scala on the CLR and given F# on the CLR, there was never any need for Scala on the CLR. do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight? Chas did a survey in 2012, which gave very negative results for clojureCLR, with 70% people having no motivation to even play with it, and almost no production use. How can ClojureCLR be protected from dwindling? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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. -- Telegram, Simply Beautiful CMS https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Compiler bug?
Hi all, I am trying new parsing library Instaparse. I setup a Leiningen project, included [instaparse 1.1.0] as my dependency and tried to run it. Unfortunately, I am getting this error: Exception in thread main java.lang.NoClassDefFoundError: instaparse/print$parser__GT_str (wrong name: instaparse/print$Parser__GT_str) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(Unknown Source) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$000(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at instaparse.print__init.load(Unknown Source) at instaparse.print__init.clinit(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at clojure.lang.RT.loadClassForName(RT.java:2098) at clojure.lang.RT.load(RT.java:430) Inside compiled class: target\classes\instaparse\print$parser__GT_str.class is a string instaparse/print$Parser__GT_str, which I believe is a name of a class. Class name and file name do not match - lowercase p versus uppercase P in $parser. Windows 7 64-Bit Leiningen 2.2.0 on Java 1.6.0_35 Java HotSpot(TM) 64-Bit Server VM Instaparse 1.1 has a dependency on [org.clojure/clojure 1.5.1]. Is this a bug inside the Clojure compiler? Or is my setup wrong? Downloading just Instaparse (branch 1.1) from github and compiling it yields the same class/file name difference. Thank you for your help, Frantisek -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: sorted-map-by issue?
Thanks,you are right.I want to creat a map which keeps elements in insertion order, but clojure doesn‘t have. 在 2013-6-6 下午10:02,Andy Fingerhut andy.finger...@gmail.com写道: Your comparator #(if (= %1 %2) 0 1) may happen to give the correct answers for your example sorted-maps, but it is also a bad comparator that will fail for larger examples: user= (:a (sorted-map-by #(if (= %1 %2) 0 1) :z -26 :b 1 :a 2 :c 3 :m 13 :h 8)) nil user= (:z (sorted-map-by #(if (= %1 %2) 0 1) :z -26 :b 1 :a 2 :c 3 :m 13 :h 8)) nil That is because if two items are not =, by returning 1 you are telling the caller the first argument should come after the second argument. Thus if at some time the comparator is called as (cmp :a :z), and later it is called as (cmp :z :a), it returns the inconsistent results that :a should come after :z, and later that :z should come after :a. No sorted tree can hope to return correct results given such an inconsistent comparator. More examples and discussion at the link below, if you are interested: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md Andy On Thu, Jun 6, 2013 at 4:19 AM, dennis zhuang killme2...@gmail.comwrote: Sorry, it's my mistake. Because treep map use the comparator to compare keys, and if the comparator returns 1 constantly,it can not find the item that equals the key. So i can modified the example,and it works: user= (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 2 user= (:b (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 1 2013/6/6 dennis zhuang killme2...@gmail.com user= (sorted-map-by (constantly 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil user= (keys (sorted-map-by (constantly 1) :b 1 :a 2)) (:b :a) user= (count (sorted-map-by (constantly 1) :b 1 :a 2)) 2 user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil It looks so strange.The result map has keys :a and :b,but i can't get their values. Why? I try to hack the code,but i can't find the reason. -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Re: sorted-map-by issue?
A few people, I believe primarily Alan Malloy and Anthony Grimes, have created a Clojure library for what they call ordered sets and maps that do exactly this. They are implemented not as you tried to do, but by remembering a number for each element (for ordered sets) or key (for ordered maps) that is the relative order that it was added in. https://github.com/flatland/ordered Andy On Thu, Jun 6, 2013 at 7:56 AM, dennis zhuang killme2...@gmail.com wrote: Thanks,you are right.I want to creat a map which keeps elements in insertion order, but clojure doesn‘t have. 在 2013-6-6 下午10:02,Andy Fingerhut andy.finger...@gmail.com写道: Your comparator #(if (= %1 %2) 0 1) may happen to give the correct answers for your example sorted-maps, but it is also a bad comparator that will fail for larger examples: user= (:a (sorted-map-by #(if (= %1 %2) 0 1) :z -26 :b 1 :a 2 :c 3 :m 13 :h 8)) nil user= (:z (sorted-map-by #(if (= %1 %2) 0 1) :z -26 :b 1 :a 2 :c 3 :m 13 :h 8)) nil That is because if two items are not =, by returning 1 you are telling the caller the first argument should come after the second argument. Thus if at some time the comparator is called as (cmp :a :z), and later it is called as (cmp :z :a), it returns the inconsistent results that :a should come after :z, and later that :z should come after :a. No sorted tree can hope to return correct results given such an inconsistent comparator. More examples and discussion at the link below, if you are interested: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md Andy On Thu, Jun 6, 2013 at 4:19 AM, dennis zhuang killme2...@gmail.comwrote: Sorry, it's my mistake. Because treep map use the comparator to compare keys, and if the comparator returns 1 constantly,it can not find the item that equals the key. So i can modified the example,and it works: user= (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 2 user= (:b (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 1 2013/6/6 dennis zhuang killme2...@gmail.com user= (sorted-map-by (constantly 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil user= (keys (sorted-map-by (constantly 1) :b 1 :a 2)) (:b :a) user= (count (sorted-map-by (constantly 1) :b 1 :a 2)) 2 user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil It looks so strange.The result map has keys :a and :b,but i can't get their values. Why? I try to hack the code,but i can't find the reason. -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Re: Why the CLR languages fail?
On Thursday, June 6, 2013 1:55:13 AM UTC-5, Zed Becker wrote: Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight? Many respondents have dealt with this question, in detail. I can confirm that some of the CLR extras (structs, reified generics, ...) complicate life for the language implementer, particularly in the area of interop. Chas did a survey in 2012, which gave very negative results for clojureCLR, with 70% people having no motivation to even play with it, and almost no production use. For me, the more interesting question is: How can ClojureCLR be protected from dwindling? 1. Send more fish. :) 2. Contribute. We can't do much about the culture in the .Net world that impedes adoption of these languages , as discussed by other respondents. The biggest impediment seems to be tooling. Progress is being made. This year has seen a noticeable increase in the number of contributors. ClojureCLR is now also on Mono, more libs have been ported, everything is being made available on nuget, we have a good start in the leiningen space with lein-clr and nleiningen (both mentioned in a recent thread here), and there have been some updates on the Visual Studio plugin. We just need more. ClojureCLR will have an official 1.5 release any day now (it's already caught up to 1.5.1 on the master branch, I just haven't tagged an official release yet). I'd like to see the work on lein-clr (which depends on ClojureJVM) moved into nleiningen (native ClojureCLR) and nlein extended to be more comprehensive. The nrepl port needs to be completed so it can be incorporated into nlein, the VS plugin, maybe emacs. And the the VS plugin needs continued refinement. I am not surprised by the low numbers for ClojureCLR on the Clojure survey. I am pleased by the increase of interest and participation that I have been seeing. And I'm really glad we didn't call it IronClojure. :) -David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: sorted-map-by issue?
The java core library also provides LinkedHashMap which preserves insertion order, although this is a mutable bash-in-place data structure rather than an immutable persistent data structure. On Jun 6, 2013 4:06 PM, Andy Fingerhut andy.finger...@gmail.com wrote: A few people, I believe primarily Alan Malloy and Anthony Grimes, have created a Clojure library for what they call ordered sets and maps that do exactly this. They are implemented not as you tried to do, but by remembering a number for each element (for ordered sets) or key (for ordered maps) that is the relative order that it was added in. https://github.com/flatland/ordered Andy On Thu, Jun 6, 2013 at 7:56 AM, dennis zhuang killme2...@gmail.comwrote: Thanks,you are right.I want to creat a map which keeps elements in insertion order, but clojure doesn‘t have. 在 2013-6-6 下午10:02,Andy Fingerhut andy.finger...@gmail.com写道: Your comparator #(if (= %1 %2) 0 1) may happen to give the correct answers for your example sorted-maps, but it is also a bad comparator that will fail for larger examples: user= (:a (sorted-map-by #(if (= %1 %2) 0 1) :z -26 :b 1 :a 2 :c 3 :m 13 :h 8)) nil user= (:z (sorted-map-by #(if (= %1 %2) 0 1) :z -26 :b 1 :a 2 :c 3 :m 13 :h 8)) nil That is because if two items are not =, by returning 1 you are telling the caller the first argument should come after the second argument. Thus if at some time the comparator is called as (cmp :a :z), and later it is called as (cmp :z :a), it returns the inconsistent results that :a should come after :z, and later that :z should come after :a. No sorted tree can hope to return correct results given such an inconsistent comparator. More examples and discussion at the link below, if you are interested: https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md Andy On Thu, Jun 6, 2013 at 4:19 AM, dennis zhuang killme2...@gmail.comwrote: Sorry, it's my mistake. Because treep map use the comparator to compare keys, and if the comparator returns 1 constantly,it can not find the item that equals the key. So i can modified the example,and it works: user= (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 2 user= (:b (sorted-map-by #(if (= %1 %2) 0 1) :b 1 :a 2)) 1 2013/6/6 dennis zhuang killme2...@gmail.com user= (sorted-map-by (constantly 1) :b 1 :a 2) {:b 1, :a 2} user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil user= (keys (sorted-map-by (constantly 1) :b 1 :a 2)) (:b :a) user= (count (sorted-map-by (constantly 1) :b 1 :a 2)) 2 user= (:a (sorted-map-by (constantly 1) :b 1 :a 2)) nil It looks so strange.The result map has keys :a and :b,but i can't get their values. Why? I try to hack the code,but i can't find the reason. -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Re: Making things go faster
Folks, I'm skipping Midge for the time being. I've written up a little more on my environment for other newbies: http://blog.goodstuff.im/clojure_setup I plan to read more of Chas' book on my NYC flight on Saturday. Thanks, David On Wed, Jun 5, 2013 at 2:44 AM, Chas Emerick c...@cemerick.com wrote: Hi David, It's odd/interesting that you're finding yourself restarting the JVM regularly. For many years, I've developed Clojure with very rare restarts; especially if my baseline project configuration is stable, I often have REPL sessions that last days. (Random thought: it'd be cute if various development environments regularly plinged `(.. java.lang.management.ManagementFactory getRuntimeMXBean getUptime)` so as to show uptime of your REPL/runtime.) Stuart's clojure.tools.namespace patches over a couple of long-standing trapdoors around code loading, but I've always preferred simply loading files/expressions into the REPL, much as we described in the 'REPL-oriented Programming' chapter in the book. I generally prefer to have as complete an understanding as possible of what's being loaded / being done to my REPL, and so various automated tools have never appealed to me. As for testing, I've always used `clojure.test`, so re-running tests after changing them or the code under test has always been just a `(test-ns *ns*)` away. This was actually a primary objective of mine in porting `clojure.test` to [clojurescript.test]( https://github.com/cemerick/clojurescript.test), which carries forward all of the former's dynamic-runtime facilities like `test-ns` and `run-all-tests`, despite the lack of first-class namespaces and the static nature of ClojureScript compilation and Closure optimization. In any case, whatever you do, any workflow that results in your bouncing the JVM is a broken one, and any tools/libraries/frameworks/whatever that push you in that direction are to be avoided IMO. Cheers, - Chas On Jun 4, 2013, at 4:51 PM, David Pollak wrote: Folks, I've been doing Clojure coding for the last couple of weeks and really love the language... and the community is fantastic. But the development cycle is slow. I'm coming from mostly Scala and a little Java. In Java, there's no REPL or anything... but the compile/test cycle is very fast. So, I can make a few changes to code, type mvn test and see the results typically in less than 2 seconds (my MacBook Pro and my Linux desktop). In Scala, the compile cycles are slower than in Java because the Scala compiler is doing a whole ton more. But in sbt (Simple [ha ha] Built Tool), one is always building/testing in the same JVM instance so the JVM is warmed up. A change code and run tests cycle is typically as fast as it is in Java. For example, Changing something significant in the net.liftweb.util package and doing a recompile and test takes about 9 seconds. This is running 450 tests. My Clojure development cycle is much slower. On my MacBook Pro (3rd gen i7 quadcore processor, 16GB of ram), each time I make a change and re-run the test for Plugh ( https://github.com/projectplugh/plugh ) it takes about 20 second and there are only 4 tests. On my desktop Linux box (i7-3770 with 32gb of RAM) it takes about 4 seconds to run the 4 tests. I also ran stuff on a very old ThinkPad (core 2 duo with 4GB ram running Linux Mint 15) and the test cycle takes 12 second. So... the questions: * Is there a faster cycle than to change code, change tests and type lein test to see the results? * Is there a way to keep everything in a hot JVM (I've done a little research on Nailgun... but it seems to be out of vogue) so there's no JVM start-up penalty? * Is there a reason for the huge disparity between my MacBook Pro and my desktop box? Thanks, David -- Telegram, Simply Beautiful CMS https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Re: Why aim for repeatability of specification / generative testing?
i always thought it was basically solely for letting you re-run the test that just/previously failed, nothing more weird or silly than that. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Shortcut for variadic map destructuring?
Consider the following: (let [ [{:keys [] :as m}] [:a 1 :b 2 :c 3]] m) == {:a 1 :b 2 :c 3} Is there a shorter form of [{:keys [] :as m}]? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Shortcut for variadic map destructuring?
Well... I'm a dingus. [{:as m}] On Thursday, 6 June 2013 15:23:22 UTC-4, JvJ wrote: Consider the following: (let [ [{:keys [] :as m}] [:a 1 :b 2 :c 3]] m) == {:a 1 :b 2 :c 3} Is there a shorter form of [{:keys [] :as m}]? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Shortcut for variadic map destructuring?
[ {:as m}] On Fri, Jun 7, 2013 at 3:23 AM, JvJ kfjwhee...@gmail.com wrote: Consider the following: (let [ [{:keys [] :as m}] [:a 1 :b 2 :c 3]] m) == {:a 1 :b 2 :c 3} Is there a shorter form of [{:keys [] :as m}]? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Re: Shortcut for variadic map destructuring?
On 06/06/13 20:23, JvJ wrote: Is there a shorter form of [{:keys [] :as m}]? if you don't care about the actual keys just do this: [ {:as m}] HTH, Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Why aim for repeatability of specification / generative testing?
Well, if *that's* all it is, I'll feel like quite the heel for putting so much thought into it! ;-) Assuming failures are rarer, then starting with a just-previously-failed seed would be better as an explicit action, rather than defaulting to a constant? - Chas On Jun 6, 2013, at 3:21 PM, Raoul Duke wrote: i always thought it was basically solely for letting you re-run the test that just/previously failed, nothing more weird or silly than that. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Why aim for repeatability of specification / generative testing?
yes, a constant is weird. whenever i've implemented my own variant of this, i always use a seed from the clock or whatever, and then spit out the seed in test/assertion failure messages so people can paste it back in to reproduce. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Why aim for repeatability of specification / generative testing?
I've worked on hardware logic design, where the time and effort required to create good tests that find subtle bugs rivals the complexity of the hardware being designed itself. In this context, much of the testing has often been generated using pseudo-random streams similar to test.generative and the simulation approach being advocated for software. I think that is a great idea for improving software quality. In hardware testing via simulation, reproducible tests are important because most of the testing cycles are run with a low amount of logging enabled -- just enough logging to look for signs of incorrect behavior. When a hardware designer wants to debug the problem, the test can be re-run with very detailed logs enabled (basically amounting to recording the logic 0/1 value of every wire in the hardware being designed at every instant in simulated time). These are much slower and require a lot more temporary disk space to record the logs. So you end up using a large variety of different seed values to increase test coverage, and if any of them fails, you can turn on the extra logging and re-run it, knowing that you will hit the same problem as before. Andy On Thu, Jun 6, 2013 at 12:30 PM, Chas Emerick c...@cemerick.com wrote: Well, if *that's* all it is, I'll feel like quite the heel for putting so much thought into it! ;-) Assuming failures are rarer, then starting with a just-previously-failed seed would be better as an explicit action, rather than defaulting to a constant? - Chas On Jun 6, 2013, at 3:21 PM, Raoul Duke wrote: i always thought it was basically solely for letting you re-run the test that just/previously failed, nothing more weird or silly than that. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Re: Why aim for repeatability of specification / generative testing?
Thanks for that perspective, Andy! It sounds like one ends up looking for canaries in the coal mine, perhaps just borderline behaviour or results, odd sideband emissions, etc. that indicate that it'd be worthwhile to turn the debug knobs up to 11. It's interesting to think of cases where the same dynamic might apply with software where the test data in question isn't readily captured. I can't think of any right off the top of my head (assuming we're always talking about purely functional properties under test), but I'm sure they exist. Back in the weeds, it does sound like the analogous default would be to vary the seed for every test run, but always capturing it for replay if necessary. - Chas On Jun 6, 2013, at 3:52 PM, Andy Fingerhut wrote: I've worked on hardware logic design, where the time and effort required to create good tests that find subtle bugs rivals the complexity of the hardware being designed itself. In this context, much of the testing has often been generated using pseudo-random streams similar to test.generative and the simulation approach being advocated for software. I think that is a great idea for improving software quality. In hardware testing via simulation, reproducible tests are important because most of the testing cycles are run with a low amount of logging enabled -- just enough logging to look for signs of incorrect behavior. When a hardware designer wants to debug the problem, the test can be re-run with very detailed logs enabled (basically amounting to recording the logic 0/1 value of every wire in the hardware being designed at every instant in simulated time). These are much slower and require a lot more temporary disk space to record the logs. So you end up using a large variety of different seed values to increase test coverage, and if any of them fails, you can turn on the extra logging and re-run it, knowing that you will hit the same problem as before. Andy On Thu, Jun 6, 2013 at 12:30 PM, Chas Emerick c...@cemerick.com wrote: Well, if *that's* all it is, I'll feel like quite the heel for putting so much thought into it! ;-) Assuming failures are rarer, then starting with a just-previously-failed seed would be better as an explicit action, rather than defaulting to a constant? - Chas On Jun 6, 2013, at 3:21 PM, Raoul Duke wrote: i always thought it was basically solely for letting you re-run the test that just/previously failed, nothing more weird or silly than that. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Re: Shortcut for variadic map destructuring?
I just realized it after I posted, but thanks for the help anyways. On Thursday, 6 June 2013 15:27:28 UTC-4, Jim foo.bar wrote: On 06/06/13 20:23, JvJ wrote: Is there a shorter form of [{:keys [] :as m}]? if you don't care about the actual keys just do this: [ {:as m}] HTH, Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Why aim for repeatability of specification / generative testing?
I can quite imagine seeing a failure from a Travis ci run which can't be explained by the test output; being able to reproduce it locally is the first step towards diagnosis. (warning: thread drift ahead...) I also have a hardware background - specifically, xilinx FPGAs. The xilinx synthesis tools have an interesting phenomenon where they use PRNGs in their place and route algorithms, which map logical netlists to physical slices configure the routing to minimize critical path delay. A different PRNG seed could result in a different place route result, with different maximum clock speed hence different performance. Hence having a repeatable build was necessary to ensure uniform performance from the same source code. On Jun 6, 2013 10:38 PM, Chas Emerick c...@cemerick.com wrote: Thanks for that perspective, Andy! It sounds like one ends up looking for canaries in the coal mine, perhaps just borderline behaviour or results, odd sideband emissions, etc. that indicate that it'd be worthwhile to turn the debug knobs up to 11. It's interesting to think of cases where the same dynamic might apply with software where the test data in question isn't readily captured. I can't think of any right off the top of my head (assuming we're always talking about purely functional properties under test), but I'm sure they exist. Back in the weeds, it does sound like the analogous default would be to vary the seed for every test run, but always capturing it for replay if necessary. - Chas On Jun 6, 2013, at 3:52 PM, Andy Fingerhut wrote: I've worked on hardware logic design, where the time and effort required to create good tests that find subtle bugs rivals the complexity of the hardware being designed itself. In this context, much of the testing has often been generated using pseudo-random streams similar to test.generative and the simulation approach being advocated for software. I think that is a great idea for improving software quality. In hardware testing via simulation, reproducible tests are important because most of the testing cycles are run with a low amount of logging enabled -- just enough logging to look for signs of incorrect behavior. When a hardware designer wants to debug the problem, the test can be re-run with very detailed logs enabled (basically amounting to recording the logic 0/1 value of every wire in the hardware being designed at every instant in simulated time). These are much slower and require a lot more temporary disk space to record the logs. So you end up using a large variety of different seed values to increase test coverage, and if any of them fails, you can turn on the extra logging and re-run it, knowing that you will hit the same problem as before. Andy On Thu, Jun 6, 2013 at 12:30 PM, Chas Emerick c...@cemerick.com wrote: Well, if *that's* all it is, I'll feel like quite the heel for putting so much thought into it! ;-) Assuming failures are rarer, then starting with a just-previously-failed seed would be better as an explicit action, rather than defaulting to a constant? - Chas On Jun 6, 2013, at 3:21 PM, Raoul Duke wrote: i always thought it was basically solely for letting you re-run the test that just/previously failed, nothing more weird or silly than that. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Re: Why aim for repeatability of specification / generative testing?
Sure; just to clarify, I was definitely talking about capturing test *input*, not output. BTW, if anyone with a hardware testing background have pointers to good literature on the topic that might be accessible to lowly software twiddlers, fire away... :-) - Chas On Jun 6, 2013, at 6:16 PM, Philip Potter wrote: I can quite imagine seeing a failure from a Travis ci run which can't be explained by the test output; being able to reproduce it locally is the first step towards diagnosis. (warning: thread drift ahead...) I also have a hardware background - specifically, xilinx FPGAs. The xilinx synthesis tools have an interesting phenomenon where they use PRNGs in their place and route algorithms, which map logical netlists to physical slices configure the routing to minimize critical path delay. A different PRNG seed could result in a different place route result, with different maximum clock speed hence different performance. Hence having a repeatable build was necessary to ensure uniform performance from the same source code. On Jun 6, 2013 10:38 PM, Chas Emerick c...@cemerick.com wrote: Thanks for that perspective, Andy! It sounds like one ends up looking for canaries in the coal mine, perhaps just borderline behaviour or results, odd sideband emissions, etc. that indicate that it'd be worthwhile to turn the debug knobs up to 11. It's interesting to think of cases where the same dynamic might apply with software where the test data in question isn't readily captured. I can't think of any right off the top of my head (assuming we're always talking about purely functional properties under test), but I'm sure they exist. Back in the weeds, it does sound like the analogous default would be to vary the seed for every test run, but always capturing it for replay if necessary. - Chas On Jun 6, 2013, at 3:52 PM, Andy Fingerhut wrote: I've worked on hardware logic design, where the time and effort required to create good tests that find subtle bugs rivals the complexity of the hardware being designed itself. In this context, much of the testing has often been generated using pseudo-random streams similar to test.generative and the simulation approach being advocated for software. I think that is a great idea for improving software quality. In hardware testing via simulation, reproducible tests are important because most of the testing cycles are run with a low amount of logging enabled -- just enough logging to look for signs of incorrect behavior. When a hardware designer wants to debug the problem, the test can be re-run with very detailed logs enabled (basically amounting to recording the logic 0/1 value of every wire in the hardware being designed at every instant in simulated time). These are much slower and require a lot more temporary disk space to record the logs. So you end up using a large variety of different seed values to increase test coverage, and if any of them fails, you can turn on the extra logging and re-run it, knowing that you will hit the same problem as before. Andy On Thu, Jun 6, 2013 at 12:30 PM, Chas Emerick c...@cemerick.com wrote: Well, if *that's* all it is, I'll feel like quite the heel for putting so much thought into it! ;-) Assuming failures are rarer, then starting with a just-previously-failed seed would be better as an explicit action, rather than defaulting to a constant? - Chas On Jun 6, 2013, at 3:21 PM, Raoul Duke wrote: i always thought it was basically solely for letting you re-run the test that just/previously failed, nothing more weird or silly than that. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Re: Compiler bug?
Short answer: This is fixed in 1.2.0-SNAPSHOT. Long answer: There was a file in instaparse that had two functions: parser-str and Parser-str On case-insensitive filesystems, the clojure compiler ends up spitting out a bunch of classfiles that correspond to the different functions, and the one for parser-str overwrites the one for Parser-str, wreaking havoc. I guess I'd consider this a Clojure compiler bug, but I'm not sure there's an easy fix, since Clojure presumably relies on the underlying filesystem for the compilation process. The lesson I've learned is that it is dangerous to rely on case sensitivity 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.
Re: Compiler bug?
On Thu, Jun 6, 2013 at 4:27 PM, Mark Engelberg mark.engelb...@gmail.comwrote: Short answer: This is fixed in 1.2.0-SNAPSHOT. To be clear, just change your project file to [instaparse 1.2.0-SNAPSHOT] and you should be good to go. As a bonus, there are some new perf improvements and features already in there, slated for the next release. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Best IDE
On Jun 5, 2013, at 11:12 AM, Catonano wrote: My 2 cents: it´s ture that the Emacs features are not discoverable and that the learning curve is mean. But it also true that once you´ve done it, it brings you a great value. My suggestions about Emacs: 1) ... 2) ... 3) ... 4) ... 5) ... 6) ... 7) ... 8) If you want to become a rock star eternal golden coder's hero then develop an Emacs-like Clojure coding environment for which the features ARE discoverable and for which the learning curve is gentle. This sort of thing has been done before! At least FRED (FRED Resembles Emacs Deliberately), which was part of the (sadly) long dead Macintosh Common Lisp environment, counts in my book. And the MCLIDE project continued this work to some extent for a while, for multiple Lisps including Clojure (http://mclide.com). All of that was just for Mac, however, and none of it appears to be active... but the idea is a superb one: Provide all of the power of Emacs but ditch the ancient user interface. E.g., instead of hiding buffers invisibly behind each other, just pop up ordinary windows that people already know how to use. Use standard menus and dialogs to interact with the user for opening files, browsing stack traces, and everything else. Set preferences in a standard preferences dialog. Allow features to be discovered by browsing menus, and allow key commands to be viewed/changed in standard ways. Life would be beautiful if something like this arose in the Clojure community. Okay, of course I know this isn't a great suggestion for the OP! But I think it's a really good suggestion for the community. -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.
Re: Why the CLR languages fail?
Alexandru's analysis is spot on. Here's the pithy IRC version I've used in the past: C# has a better type system and compiler, so it doesn't need as good of a JIT. That's a problem for languages that aren't C#, especially dynamic ones. There are lots of caveats, but that more or less covers it. On Thursday, June 6, 2013 6:53:05 AM UTC-4, Alexandru Nedelcu wrote: On Thu, Jun 6, 2013 at 12:47 PM, Colin Fleming colin.ma...@gmail.comjavascript: wrote: I'm not sure this is true, Don Syme has written several times about how difficult it would be to implement F# on the JVM - I believe tail recursion and not being able to define new intrinsic types (i.e. new primitives) are the sticking points. Yes, both of these have been issues people had to confront on the JVM. However, for example tail-recursion in CLR not being used by C# meant that it went unoptimized and even broken on the 64bits CLR for years. Also, tail-recursion is not such a big issue, because self-tail recursion is easy to optimize by generating a simple loop (Scala does it, Clojure does it) and more complicated cases require indeed usage of trampolines. Not to underestimate their importance, being a useful feature to model state-machines, however you can still work by means of trampolines (Clojure elegantly solves it with syntactic sugar and it's workable in Scala because of it's good type-system [1]) On the other hand, the lack of support for new primitives has been hurting language implementations, like JRuby. Note that both features have experimental implementations as part of OpenJDK and it's possible we'll see them in the JVM. Plus, why stop at tail-calls? There are many languages that can hardly be implemented on top of both .NET and the JVM - not having continuations support, useful for Scheme or Smalltalk is a PITA. Haskell wouldn't be possible in either, because of it's laziness by default. You also mentioned primitive types, but for example the CLR lacks a Union data type, so implementing lazy integers for example comes with a lot of overhead. I think a lot of people believe that from a functionality point of view the CLR is better than the JVM - as far as I know it's not missing any functionality from the JVM and it has significant advantages (reified generics as well as the functionality mentioned above). That's not true. It does have a couple of advantages (like the ones you mentioned), but that list is shrinking and the advantages that the JVM has are huge and the list gets bigger with each new release. Reified generics are actually a PITA for new languages. Scala's generics are much more flexible, with a much better design than the ones in Java - you cannot implement Scala's type system on top of .NET's generics without cutting down on their features. Erasure is not bad per se and for the utility of reified generics, it really depends on what language you're talking about. Erasure has only been bad for Java, because Java's type system is too weak and because in Java the wildcards are used on the methods themselves, rather than at the class level, which has been a big mistake. Also, Scala's type system is much stronger, much more static and much more expressive. I never felt the need for reification in Scala. It even has the option of doing specialization for primitives, to avoid boxing/unboxing, as an optimization option. Haskell also implements generics by erasure. Reified generics are bad for other languages if you need to workaround them. For dynamic languages it's somewhat a disaster. On the JVM the bytecode is pretty dynamic, except for when you need to work with primitives (for invoking operations optimized for primitives) or when you call a method, you need to know the interface it belongs to (something which changed in OpenJDK 7 with invokeDynamic). Otherwise you don't have static types in the actual bytecode (e.g. casting an object to something is just an assertion in the actual bytecode that you don't need). But with reified generics, suddenly you have more static typing you need to take care of and avoid. When generating bytecode it's easier on the JVM. The final packages (Jars) are just Zip files containing .class files, with a text-based manifest. The .class files themselves contain the debugging symbols and those debugging symbols are part of the standard spec, whereas the format for the CLR was never a part of the ECMA standard, was private and for a long time Mono has been using their own format for those debugging symbols, as they had to slowly reverse-engineer whatever Microsoft was doing. Because Java libraries tend to use a lot of bytecode-generating routines, the tools available for that are amazing (like ASM), whereas on top of .NET things like System.Reflection.Emit takes care of only a subset, so the Mono people had to come up with their own alternatives (like
clojure diffs
Hi all, Diffs for clojure code (and lisps in general) can be hard to read. Every time we wrap a form, any lines below are indented. The resulting diff just shows that you've deleted lines and added lines, even though you've only changed a few characters. What diff tools do people use to address this? I've found ediff is useful in emacs, but what I really want is a way to see good diffs in github pull requests. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 diffs
One neat hidden Github feature is that if you add the query string parameter w=1 to any diff view, it will ignore whitespace-only changes (like passing -w to git diff). That doesn't help with those final lines with added or removed close parens, but it still improves readability of many diffs. https://github.com/blog/967-github-secrets On Jun 6, 2013 9:31 PM, Moocar anthony.mar...@gmail.com wrote: Hi all, Diffs for clojure code (and lisps in general) can be hard to read. Every time we wrap a form, any lines below are indented. The resulting diff just shows that you've deleted lines and added lines, even though you've only changed a few characters. What diff tools do people use to address this? I've found ediff is useful in emacs, but what I really want is a way to see good diffs in github pull requests. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
Re: clojure diffs
Intellij diffs, FileMerge, or Meld - they all highlight the words that changed not just the lines. On Thu, Jun 6, 2013 at 7:57 PM, John D. Hume duelin.mark...@gmail.comwrote: One neat hidden Github feature is that if you add the query string parameter w=1 to any diff view, it will ignore whitespace-only changes (like passing -w to git diff). That doesn't help with those final lines with added or removed close parens, but it still improves readability of many diffs. https://github.com/blog/967-github-secrets On Jun 6, 2013 9:31 PM, Moocar anthony.mar...@gmail.com wrote: Hi all, Diffs for clojure code (and lisps in general) can be hard to read. Every time we wrap a form, any lines below are indented. The resulting diff just shows that you've deleted lines and added lines, even though you've only changed a few characters. What diff tools do people use to address this? I've found ediff is useful in emacs, but what I really want is a way to see good diffs in github pull requests. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.