Why the CLR languages fail?

[Zed Becker]

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?

[Rich Morin]

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?

[Alexandru Nedelcu]

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?

[Colin Fleming]

*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?

[dennis zhuang]

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

[Phillip Lord]

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?

[dennis zhuang]

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 ?

[bernardH]

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!

[Lynn Grogan]

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

[Stuart Sierra]

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

[Gary Trakhman]

 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?

[Andy Fingerhut]

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?

[David Pollak]

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?

[Frantisek Sodomka]

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?

[dennis zhuang]

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?

[Andy Fingerhut]

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?

[dmiller]

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?

[Philip Potter]

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

[David Pollak]

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?

[Raoul Duke]

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?

[JvJ]

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?

[JvJ]

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?

[Ambrose Bonnaire-Sergeant]

[ {: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?

[Jim - FooBar();]

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?

[Chas Emerick]

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?

[Raoul Duke]

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?

[Andy Fingerhut]

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?

[Chas Emerick]

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?

[JvJ]

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?

[Philip Potter]

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?

[Chas Emerick]

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?

[Mark Engelberg]

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?

[Mark Engelberg]

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

[Lee Spector]

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?

[Brandon Bloom]

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

[Moocar]

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

[John D. Hume]

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

[Alex Baranosky]

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.