Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-15 Thread Daniel Compton
Tom, would you be able to run your performance regression suite against 1.8
with direct linking enabled and share the performance changes?

On Mon, Nov 16, 2015 at 1:19 PM Andy Fingerhut 
wrote:

> With updates I have made in the latest release of Eastwood 0.2.2
> (announced in a separate message), I am seeing pretty much identical
> linting results running Eastwood on about 80 Clojure contrib and 3rd party
> libraries when using Clojure 1.8.0-RC1 as I see with Clojure 1.7.0.  The
> run time is nearly the same -- about 2% longer with 1.8.0-RC1, but I only
> ran each set of tests once, and that could be within the range of
> variability across runs.
>
> Andy
>
>
> On Wed, Nov 11, 2015 at 12:02 PM, Andy Fingerhut  > wrote:
>
>> Results of some testing done on 1.8.0-RC1:
>>
>> Ran 'mvn clean test' on a few OS/JDK combos that are not tested as
>> often.  Reason: there have been (or still are) build or test failures with
>> some of them.  All JDKs listed below were 64-bit.
>>
>> Windows 7 Enterprise SP1 + Oracle JDK 1.7.0_80-b15: ok 3/3 trials
>> Ubuntu 14.04.3 LTS + OpenJDK 1.7.0_85: ok 3/3 trials
>> Ubuntu 14.04.3 LTS + IBM JDK 1.7.0: ok 10/10 trials, as long as failing
>> tests mentioned in http://dev.clojure.org/jira/browse/CLJ-1678 are
>> commented out
>> Ubuntu 14.04.3 LTS + IBM JDK 1.8.0 (based on jdk8u51-b15): same as for
>> IBM JDK 1.7.0
>> Mac OS X 10.11.1 + Oracle JDK 1.8.0_11: ok 631/631 trials
>>
>> There were some JVM crashes during 'mvn test' that I have seen with an
>> earlier version of IBM JDK 1.8.0 (based on jdk8u45-b13), but with the
>> version mentioned above those seem to be gone.  The older one failed 5 out
>> of 10 trials.  The newer one gave passing test results with no JVM crash 10
>> out of 10 trials.
>>
>> I plan to, but haven't yet, compared Eastwood results with 1.8.0-RC1 vs.
>> 1.7.0.  That will take some work before I can give those results, primarily
>> updating Eastwood to work with 1.8.0-RC1.  Eastwood makes some assumptions
>> about the structure of ASTs (abstract syntax trees) that 1.8.0-RC!'s
>> :rettag addition changed.  I don't think it is much work, but not sure when
>> I will be able to get to it.  Until then, I have the following message near
>> the beginning of Eastwood's README:
>>
>> It has been tried with some of the Clojure 1.8.0-alpha versions, but
>> there are known problems there (e.g. incorrect warning about misplaced
>> docstrings, perhaps incorrect warnings about wrong tags, etc.)
>>
>> Andy
>>
>>
>> On Tue, Nov 10, 2015 at 9:30 AM, Alex Miller  wrote:
>>
>>> Clojure 1.8.0-RC1 is now available. *This build is a "release
>>> candidate"!* We would appreciate any and all testing you can do on your
>>> own libraries or internal projects to find problems. If no problems are
>>> found, we expect to make this the 1.8.0 final release!
>>>
>>> Try it via
>>>
>>>- Download:
>>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>>>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>>>
>>> Below is the only change since 1.8.0-beta2. See the full 1.8 change log
>>> here: https://github.com/clojure/clojure/blob/master/changes.md.
>>>
>>>- CLJ-1845  Make
>>>clojure.core/load dynamic so it can be redef'ed even with direct linking
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Daniel

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated -

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-15 Thread Andy Fingerhut
With updates I have made in the latest release of Eastwood 0.2.2 (announced
in a separate message), I am seeing pretty much identical linting results
running Eastwood on about 80 Clojure contrib and 3rd party libraries when
using Clojure 1.8.0-RC1 as I see with Clojure 1.7.0.  The run time is
nearly the same -- about 2% longer with 1.8.0-RC1, but I only ran each set
of tests once, and that could be within the range of variability across
runs.

Andy


On Wed, Nov 11, 2015 at 12:02 PM, Andy Fingerhut 
wrote:

> Results of some testing done on 1.8.0-RC1:
>
> Ran 'mvn clean test' on a few OS/JDK combos that are not tested as often.
> Reason: there have been (or still are) build or test failures with some of
> them.  All JDKs listed below were 64-bit.
>
> Windows 7 Enterprise SP1 + Oracle JDK 1.7.0_80-b15: ok 3/3 trials
> Ubuntu 14.04.3 LTS + OpenJDK 1.7.0_85: ok 3/3 trials
> Ubuntu 14.04.3 LTS + IBM JDK 1.7.0: ok 10/10 trials, as long as failing
> tests mentioned in http://dev.clojure.org/jira/browse/CLJ-1678 are
> commented out
> Ubuntu 14.04.3 LTS + IBM JDK 1.8.0 (based on jdk8u51-b15): same as for IBM
> JDK 1.7.0
> Mac OS X 10.11.1 + Oracle JDK 1.8.0_11: ok 631/631 trials
>
> There were some JVM crashes during 'mvn test' that I have seen with an
> earlier version of IBM JDK 1.8.0 (based on jdk8u45-b13), but with the
> version mentioned above those seem to be gone.  The older one failed 5 out
> of 10 trials.  The newer one gave passing test results with no JVM crash 10
> out of 10 trials.
>
> I plan to, but haven't yet, compared Eastwood results with 1.8.0-RC1 vs.
> 1.7.0.  That will take some work before I can give those results, primarily
> updating Eastwood to work with 1.8.0-RC1.  Eastwood makes some assumptions
> about the structure of ASTs (abstract syntax trees) that 1.8.0-RC!'s
> :rettag addition changed.  I don't think it is much work, but not sure when
> I will be able to get to it.  Until then, I have the following message near
> the beginning of Eastwood's README:
>
> It has been tried with some of the Clojure 1.8.0-alpha versions, but there
> are known problems there (e.g. incorrect warning about misplaced
> docstrings, perhaps incorrect warnings about wrong tags, etc.)
>
> Andy
>
>
> On Tue, Nov 10, 2015 at 9:30 AM, Alex Miller  wrote:
>
>> Clojure 1.8.0-RC1 is now available. *This build is a "release
>> candidate"!* We would appreciate any and all testing you can do on your
>> own libraries or internal projects to find problems. If no problems are
>> found, we expect to make this the 1.8.0 final release!
>>
>> Try it via
>>
>>- Download:
>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>>
>> Below is the only change since 1.8.0-beta2. See the full 1.8 change log
>> here: https://github.com/clojure/clojure/blob/master/changes.md.
>>
>>- CLJ-1845  Make
>>clojure.core/load dynamic so it can be redef'ed even with direct linking
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-14 Thread Ambrose Bonnaire-Sergeant
Can we get a 3rd jar that is AOT compiled but without direct linking? I'd
like the benefits of AOT load
time but also to build dev-time tooling to improve core error messages.

Thanks,
Ambrose

On Sat, Nov 14, 2015 at 7:02 AM, tcrayford  wrote:

> Hi,
>
> I ran Yeller's very extensive benchmark suite against Clojure 1.8 RC1.
> I saw no performance regressions, over 72 individual benchmarks.
> There were no notable performance improvements either (all benchmarks were
> comparatively equal to a benchmark run against 1.7 with a 95% confidence
> interval).
>
> I've also ran Yeller's (extensive) test.check based suite (94 individual
> test.check properties) for 24h on a CI machine against Clojure 1.8 RC1 and
> saw
> no test failures at all. There were ~1 billion assertions made during that
> test run.
>
> So, from all my testing, Clojure 1.8 RC1 seems to be fine. Thumbs up on my
> end.
>
> Thanks for all the hard work that goes into making Clojure so stable.
>
> Tom Crayford
> Founder, yellerapp.com
>
> On Tuesday, 10 November 2015 17:30:47 UTC, Alex Miller wrote:
>
>> Clojure 1.8.0-RC1 is now available. *This build is a "release
>> candidate"!* We would appreciate any and all testing you can do on your
>> own libraries or internal projects to find problems. If no problems are
>> found, we expect to make this the 1.8.0 final release!
>>
>> Try it via
>>
>>- Download:
>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>>
>> Below is the only change since 1.8.0-beta2. See the full 1.8 change log
>> here: https://github.com/clojure/clojure/blob/master/changes.md.
>>
>>- CLJ-1845  Make
>>clojure.core/load dynamic so it can be redef'ed even with direct linking
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-14 Thread tcrayford
Hi,

I ran Yeller's very extensive benchmark suite against Clojure 1.8 RC1.
I saw no performance regressions, over 72 individual benchmarks.
There were no notable performance improvements either (all benchmarks were
comparatively equal to a benchmark run against 1.7 with a 95% confidence 
interval).

I've also ran Yeller's (extensive) test.check based suite (94 individual
test.check properties) for 24h on a CI machine against Clojure 1.8 RC1 and 
saw
no test failures at all. There were ~1 billion assertions made during that
test run.

So, from all my testing, Clojure 1.8 RC1 seems to be fine. Thumbs up on my 
end.

Thanks for all the hard work that goes into making Clojure so stable.

Tom Crayford
Founder, yellerapp.com

On Tuesday, 10 November 2015 17:30:47 UTC, Alex Miller wrote:
>
> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!* 
> We would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make 
>clojure.core/load dynamic so it can be redef'ed even with direct linking
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Sean Corfield
Nicola Mometto wrote on Thursday, November 12, 2015 at 11:52 AM:
*mostly* works, and since 1.8 only.
The issue pre 1.8 is that since metadata on arglist is not evaluated, the type 
hint wasn't a fully qualified classname, forcing the user namespaces to import 
that Class.

Scenarios like this would break:

(ns foo (:import my.Klass))
(defn foo ^Klass [] (Klass.))

(ns bar (:require foo))
(.method (foo/foo))

Ah, thank you for the explanation! I’d run into that and couldn’t really 
understand why it was failing!

Sean


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Nicola Mometto
*mostly* works, and since 1.8 only.
The issue pre 1.8 is that since metadata on arglist is not evaluated, the type 
hint wasn't a fully qualified classname, forcing the user namespaces to import 
that Class.

Scenarios like this would break:

(ns foo (:import my.Klass))
(defn foo ^Klass [] (Klass.))

(ns bar (:require foo))
(.method (foo/foo))


> On 12 Nov 2015, at 19:49, Leon Grapenthin  wrote:
> 
> Does this mean putting it in the arglist always works and there is rarely a 
> practical reason to do anything else?
> 
> On Thursday, November 12, 2015 at 8:36:20 PM UTC+1, Nicola Mometto wrote:
> It.. depends :(
> 
> If your type hint is a *primitive* then you want to put it in the arglist. If 
> you put it in the Var, the best case scenario is that you'll get either 
> reflection warnings or boxed maths, and the worst case scenario is a 
> Compiler/bytecode error.
> 
> If your type hint is an array type hint (^objects, ^ints ..) you want to put 
> it in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).
> 
> If your type hint is a non primitive class, you want to put it in the Var or 
> in the arglist as a fully qualified symbol (not necessary anymore since 1.8)
> 
> If your type hint is a string representing a class, you can safely put it in 
> either place.
> 
>> On 12 Nov 2015, at 19:28, Michael Blume > 
>> wrote:
>> 
>> Sorry, I'm confused now -- is the appropriate place to give a return type 
>> hint for a function the arg list and not the function name? I've always seen 
>> the function name hinted.
>> 
>> On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto > > wrote:
>> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
>> 
>>> On 12 Nov 2015, at 19:14, Nicola Mometto > 
>>> wrote:
>>> 
>>> 
>>> Depends on how you look at it.
>>> From my point of view, both examples are using an otherwise valid type 
>>> hint, at an invalid location, and in both cases the emitted code is 
>>> nonsensical.
>>> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
>>> with a compile time error, this one should too.
>>> 
>>> 
 On 12 Nov 2015, at 16:47, Alex Miller > 
 wrote:
 
 Neither is acceptable, so I either misunderstand or disagree with your 
 question. :) 
 
 The code below is an invalid type hint at that location. Are you maybe 
 saying this should throw an error on definition?
 
 CLJ-1846 is instead a valid type hint that is in conflict with the call. 
 Which now throws an error.
 
 
 On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
 This is :rettag in action.
 Any reason why this error should be acceptable while the CLJ-1846 one 
 isn't?
 
> On 12 Nov 2015, at 12:55, Alex Miller  > wrote:
> 
> That's not a valid type hint. Var meta is evaluated, in this case to the 
> double function object. You really want:
> 
> (defn timespi ^double [^double x] (* x 3.14))
> 
> 
> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebo...@gmail.com 
>  wrote:
> Hello,
> 
> the following stops executing on 1.8.0-rc1 or current master-head 
> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
> CLJ-1846):
> 
> [/Users/reborg]$ repl
> Clojure 1.8.0-master-SNAPSHOT
> user=> (defn ^double timespi [^double x] (* x 3.14))
> #'user/timespi
> user=> (timespi 2)
> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; 
> is abstract  user/timespi (NO_SOURCE_FILE:-1)
> 
> It works if you enable direct linking (or if you use 1.7.0).
> 
> Renzo
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com 
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com 
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en 
 
 --- 
 You received this message because you are subscribed to the Google Groups 
 "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+u...@googlegroups.com .
 For more options, visit https://groups.google.com/d/optout 
 .
>>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en 
>> 

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Leon Grapenthin
Does this mean putting it in the arglist always works and there is rarely a 
practical reason to do anything else?

On Thursday, November 12, 2015 at 8:36:20 PM UTC+1, Nicola Mometto wrote:
>
> It.. depends :(
>
> If your type hint is a *primitive* then you want to put it in the arglist. 
> If you put it in the Var, the best case scenario is that you'll get either 
> reflection warnings or boxed maths, and the worst case scenario is a 
> Compiler/bytecode error.
>
> If your type hint is an array type hint (^objects, ^ints ..) you want to 
> put it in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).
>
> If your type hint is a non primitive class, you want to put it in the Var 
> or in the arglist as a fully qualified symbol (not necessary anymore since 
> 1.8)
>
> If your type hint is a string representing a class, you can safely put it 
> in either place.
>
> On 12 Nov 2015, at 19:28, Michael Blume > 
> wrote:
>
> Sorry, I'm confused now -- is the appropriate place to give a return type 
> hint for a function the arg list and not the function name? I've always 
> seen the function name hinted.
>
> On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto  > wrote:
>
>> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
>>
>> On 12 Nov 2015, at 19:14, Nicola Mometto > 
>> wrote:
>>
>>
>> Depends on how you look at it.
>> From my point of view, both examples are using an otherwise valid type 
>> hint, at an invalid location, and in both cases the emitted code is 
>> nonsensical.
>> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
>> with a compile time error, this one should too.
>>
>>
>> On 12 Nov 2015, at 16:47, Alex Miller > 
>> wrote:
>>
>> Neither is acceptable, so I either misunderstand or disagree with your 
>> question. :) 
>>
>> The code below is an invalid type hint at that location. Are you maybe 
>> saying this should throw an error on definition?
>>
>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>> Which now throws an error.
>>
>>
>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>>
>>> This is :rettag in action.
>>> Any reason why this error should be acceptable while the CLJ-1846 one 
>>> isn't?
>>>
>>> On 12 Nov 2015, at 12:55, Alex Miller >> > wrote:
>>>
>>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>>> double function object. You really want:
>>>
>>> (defn timespi ^double [^double x] (* x 3.14))
>>>
>>>
>>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebo...@gmail.com 
>>>  wrote:

 Hello,

 the following stops executing on 1.8.0-rc1 or current master-head 
 (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix 
 for CLJ-1846):

 [/Users/reborg]$ repl
 Clojure 1.8.0-master-SNAPSHOT
 user=> (defn ^double timespi [^double x] (* x 3.14))
 #'user/timespi
 user=> (timespi 2)
 AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; 
 is abstract  user/timespi (NO_SOURCE_FILE:-1)

 It works if you enable direct linking (or if you use 1.7.0).

 Renzo

>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For mor

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Nicola Mometto
It.. depends :(

If your type hint is a *primitive* then you want to put it in the arglist. If 
you put it in the Var, the best case scenario is that you'll get either 
reflection warnings or boxed maths, and the worst case scenario is a 
Compiler/bytecode error.

If your type hint is an array type hint (^objects, ^ints ..) you want to put it 
in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).

If your type hint is a non primitive class, you want to put it in the Var or in 
the arglist as a fully qualified symbol (not necessary anymore since 1.8)

If your type hint is a string representing a class, you can safely put it in 
either place.

> On 12 Nov 2015, at 19:28, Michael Blume  wrote:
> 
> Sorry, I'm confused now -- is the appropriate place to give a return type 
> hint for a function the arg list and not the function name? I've always seen 
> the function name hinted.
> 
> On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto  > wrote:
> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
> 
>> On 12 Nov 2015, at 19:14, Nicola Mometto > > wrote:
>> 
>> 
>> Depends on how you look at it.
>> From my point of view, both examples are using an otherwise valid type hint, 
>> at an invalid location, and in both cases the emitted code is nonsensical.
>> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
>> with a compile time error, this one should too.
>> 
>> 
>>> On 12 Nov 2015, at 16:47, Alex Miller >> > wrote:
>>> 
>>> Neither is acceptable, so I either misunderstand or disagree with your 
>>> question. :) 
>>> 
>>> The code below is an invalid type hint at that location. Are you maybe 
>>> saying this should throw an error on definition?
>>> 
>>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>>> Which now throws an error.
>>> 
>>> 
>>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>> This is :rettag in action.
>>> Any reason why this error should be acceptable while the CLJ-1846 one isn't?
>>> 
 On 12 Nov 2015, at 12:55, Alex Miller >>> > wrote:
 
 That's not a valid type hint. Var meta is evaluated, in this case to the 
 double function object. You really want:
 
 (defn timespi ^double [^double x] (* x 3.14))
 
 
 On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
  wrote:
 Hello,
 
 the following stops executing on 1.8.0-rc1 or current master-head 
 (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
 CLJ-1846):
 
 [/Users/reborg]$ repl
 Clojure 1.8.0-master-SNAPSHOT
 user=> (defn ^double timespi [^double x] (* x 3.14))
 #'user/timespi
 user=> (timespi 2)
 AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
 abstract  user/timespi (NO_SOURCE_FILE:-1)
 
 It works if you enable direct linking (or if you use 1.7.0).
 
 Renzo
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com 
>>> 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en 
>>> 
>>> --- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to clojure+unsubscr...@googlegroups.com 
>>> .
>>> For more options, visit https://groups.google.com/d/optout 
>>> .
>> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com 
> 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.goog

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Michael Blume
Sorry, I'm confused now -- is the appropriate place to give a return type
hint for a function the arg list and not the function name? I've always
seen the function name hinted.

On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto  wrote:

> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
>
> On 12 Nov 2015, at 19:14, Nicola Mometto  wrote:
>
>
> Depends on how you look at it.
> From my point of view, both examples are using an otherwise valid type
> hint, at an invalid location, and in both cases the emitted code is
> nonsensical.
> So I'd say that if the decision for the CLJ-1846 issue was to handle that
> with a compile time error, this one should too.
>
>
> On 12 Nov 2015, at 16:47, Alex Miller  wrote:
>
> Neither is acceptable, so I either misunderstand or disagree with your
> question. :)
>
> The code below is an invalid type hint at that location. Are you maybe
> saying this should throw an error on definition?
>
> CLJ-1846 is instead a valid type hint that is in conflict with the call.
> Which now throws an error.
>
>
> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>
>> This is :rettag in action.
>> Any reason why this error should be acceptable while the CLJ-1846 one
>> isn't?
>>
>> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
>>
>> That's not a valid type hint. Var meta is evaluated, in this case to the
>> double function object. You really want:
>>
>> (defn timespi ^double [^double x] (* x 3.14))
>>
>>
>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com
>> wrote:
>>>
>>> Hello,
>>>
>>> the following stops executing on 1.8.0-rc1 or current master-head
>>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix
>>> for CLJ-1846):
>>>
>>> [/Users/reborg]$ repl
>>> Clojure 1.8.0-master-SNAPSHOT
>>> user=> (defn ^double timespi [^double x] (* x 3.14))
>>> #'user/timespi
>>> user=> (timespi 2)
>>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object;
>>> is abstract  user/timespi (NO_SOURCE_FILE:-1)
>>>
>>> It works if you enable direct linking (or if you use 1.7.0).
>>>
>>> Renzo
>>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Nicola Mometto
Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8

> On 12 Nov 2015, at 19:14, Nicola Mometto  wrote:
> 
> 
> Depends on how you look at it.
> From my point of view, both examples are using an otherwise valid type hint, 
> at an invalid location, and in both cases the emitted code is nonsensical.
> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
> with a compile time error, this one should too.
> 
> 
>> On 12 Nov 2015, at 16:47, Alex Miller > > wrote:
>> 
>> Neither is acceptable, so I either misunderstand or disagree with your 
>> question. :) 
>> 
>> The code below is an invalid type hint at that location. Are you maybe 
>> saying this should throw an error on definition?
>> 
>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>> Which now throws an error.
>> 
>> 
>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>> This is :rettag in action.
>> Any reason why this error should be acceptable while the CLJ-1846 one isn't?
>> 
>>> On 12 Nov 2015, at 12:55, Alex Miller >> > wrote:
>>> 
>>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>>> double function object. You really want:
>>> 
>>> (defn timespi ^double [^double x] (* x 3.14))
>>> 
>>> 
>>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
>>>  wrote:
>>> Hello,
>>> 
>>> the following stops executing on 1.8.0-rc1 or current master-head 
>>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
>>> CLJ-1846):
>>> 
>>> [/Users/reborg]$ repl
>>> Clojure 1.8.0-master-SNAPSHOT
>>> user=> (defn ^double timespi [^double x] (* x 3.14))
>>> #'user/timespi
>>> user=> (timespi 2)
>>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
>>> abstract  user/timespi (NO_SOURCE_FILE:-1)
>>> 
>>> It works if you enable direct linking (or if you use 1.7.0).
>>> 
>>> Renzo
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com 
>> 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en 
>> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Nicola Mometto

Depends on how you look at it.
>From my point of view, both examples are using an otherwise valid type hint, 
>at an invalid location, and in both cases the emitted code is nonsensical.
So I'd say that if the decision for the CLJ-1846 issue was to handle that with 
a compile time error, this one should too.


> On 12 Nov 2015, at 16:47, Alex Miller  wrote:
> 
> Neither is acceptable, so I either misunderstand or disagree with your 
> question. :) 
> 
> The code below is an invalid type hint at that location. Are you maybe saying 
> this should throw an error on definition?
> 
> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
> Which now throws an error.
> 
> 
> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
> This is :rettag in action.
> Any reason why this error should be acceptable while the CLJ-1846 one isn't?
> 
>> On 12 Nov 2015, at 12:55, Alex Miller > > wrote:
>> 
>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>> double function object. You really want:
>> 
>> (defn timespi ^double [^double x] (* x 3.14))
>> 
>> 
>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
>>  wrote:
>> Hello,
>> 
>> the following stops executing on 1.8.0-rc1 or current master-head 
>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
>> CLJ-1846):
>> 
>> [/Users/reborg]$ repl
>> Clojure 1.8.0-master-SNAPSHOT
>> user=> (defn ^double timespi [^double x] (* x 3.14))
>> #'user/timespi
>> user=> (timespi 2)
>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
>> abstract  user/timespi (NO_SOURCE_FILE:-1)
>> 
>> It works if you enable direct linking (or if you use 1.7.0).
>> 
>> Renzo
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Alex Miller
Neither is acceptable, so I either misunderstand or disagree with your 
question. :) 

The code below is an invalid type hint at that location. Are you maybe 
saying this should throw an error on definition?

CLJ-1846 is instead a valid type hint that is in conflict with the call. 
Which now throws an error.


On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>
> This is :rettag in action.
> Any reason why this error should be acceptable while the CLJ-1846 one 
> isn't?
>
> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
>
> That's not a valid type hint. Var meta is evaluated, in this case to the 
> double function object. You really want:
>
> (defn timespi ^double [^double x] (* x 3.14))
>
>
> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
> wrote:
>>
>> Hello,
>>
>> the following stops executing on 1.8.0-rc1 or current master-head 
>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix 
>> for CLJ-1846):
>>
>> [/Users/reborg]$ repl
>> Clojure 1.8.0-master-SNAPSHOT
>> user=> (defn ^double timespi [^double x] (* x 3.14))
>> #'user/timespi
>> user=> (timespi 2)
>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; 
>> is abstract  user/timespi (NO_SOURCE_FILE:-1)
>>
>> It works if you enable direct linking (or if you use 1.7.0).
>>
>> Renzo
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Renzo Borgatti
Thanks Alex, I’ve missed the wrong type hint in that line. Now 1.8 is even 
telling me!

Cheers
Renzo

> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
> 
> That's not a valid type hint. Var meta is evaluated, in this case to the 
> double function object. You really want:
> 
> (defn timespi ^double [^double x] (* x 3.14))
> 
> 
> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com wrote:
> Hello,
> 
> the following stops executing on 1.8.0-rc1 or current master-head 
> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
> CLJ-1846):
> 
> [/Users/reborg]$ repl
> Clojure 1.8.0-master-SNAPSHOT
> user=> (defn ^double timespi [^double x] (* x 3.14))
> #'user/timespi
> user=> (timespi 2)
> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
> abstract  user/timespi (NO_SOURCE_FILE:-1)
> 
> It works if you enable direct linking (or if you use 1.7.0).
> 
> Renzo
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Nicola Mometto
Given the number of bytecode/type hinting issues we've seen caused by direct 
linking and the lack of real benchmarks demonstrating its benefits, I'm also 
wondering what's the rationale between including it in the current release.


> On 10 Nov 2015, at 18:15, Ghadi Shayban  wrote:
> 
> Two points of feedback:
> 
> 
> 1) One of the reason tuples were disabled was that they polluted dispatch 
> paths.  Shouldn't we make sure that they are completely inactive?
> 
>Map entries (everywhere: c.l.Persistent*, records, gvec, bean) still use 
> them.
> 
> 2) I get the rationale behind direct linking, but I'm lacking evidence that 
> the benefits are achieved.
> 
> 
> 
> 
> On Tuesday, November 10, 2015 at 12:30:47 PM UTC-5, Alex Miller wrote:
> Clojure 1.8.0-RC1 is now available. This build is a "release candidate"! We 
> would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
> 
> Try it via
> Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1 
> 
> Leiningen: [org.clojure/clojure "1.8.0-RC1"]
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md 
> .
> CLJ-1845  Make clojure.core/load 
> dynamic so it can be redef'ed even with direct linking
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Nicola Mometto
This is :rettag in action.
Any reason why this error should be acceptable while the CLJ-1846 one isn't?

> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
> 
> That's not a valid type hint. Var meta is evaluated, in this case to the 
> double function object. You really want:
> 
> (defn timespi ^double [^double x] (* x 3.14))
> 
> 
> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com wrote:
> Hello,
> 
> the following stops executing on 1.8.0-rc1 or current master-head 
> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
> CLJ-1846):
> 
> [/Users/reborg]$ repl
> Clojure 1.8.0-master-SNAPSHOT
> user=> (defn ^double timespi [^double x] (* x 3.14))
> #'user/timespi
> user=> (timespi 2)
> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
> abstract  user/timespi (NO_SOURCE_FILE:-1)
> 
> It works if you enable direct linking (or if you use 1.7.0).
> 
> Renzo
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread Alex Miller
That's not a valid type hint. Var meta is evaluated, in this case to the 
double function object. You really want:

(defn timespi ^double [^double x] (* x 3.14))


On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
wrote:
>
> Hello,
>
> the following stops executing on 1.8.0-rc1 or current master-head 
> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix 
> for CLJ-1846):
>
> [/Users/reborg]$ repl
> Clojure 1.8.0-master-SNAPSHOT
> user=> (defn ^double timespi [^double x] (* x 3.14))
> #'user/timespi
> user=> (timespi 2)
> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
> abstract  user/timespi (NO_SOURCE_FILE:-1)
>
> It works if you enable direct linking (or if you use 1.7.0).
>
> Renzo
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-12 Thread reborgml
Hello,

the following stops executing on 1.8.0-rc1 or current master-head 
(9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix 
for CLJ-1846):

[/Users/reborg]$ repl
Clojure 1.8.0-master-SNAPSHOT
user=> (defn ^double timespi [^double x] (* x 3.14))
#'user/timespi
user=> (timespi 2)
AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
abstract  user/timespi (NO_SOURCE_FILE:-1)

It works if you enable direct linking (or if you use 1.7.0).

Renzo

On Tuesday, 10 November 2015 17:30:47 UTC, Alex Miller wrote:
>
> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!* 
> We would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make 
>clojure.core/load dynamic so it can be redef'ed even with direct linking
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Robin Heggelund Hansen
You were right. Aleph depended on potemkin, upgrading that dependency fixed 
the problem.

onsdag 11. november 2015 12.12.40 UTC+1 skrev Alex Miller følgende:
>
> There is a Potemkin error that was exposed during 1.8 that looks like this 
> (the compile_stub) - is that library in your dependencies? If so, supplying 
> the latest version explicitly should fix the problem.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Alex Miller
Rich pushed a commit to master that will now detect this invalid primitive 
type hint and throw a compiler error.

Shantanu - your asphalt library will fail due to this new compile error. 
You should change your two ^int type hints to casts instead (int ...) to 
fix the error. FYI, this type mismatch was ignored (effectively a no-op) 
until the change from CLJ-1533 in 1.8.0-alpha2 which is why we did not see 
it previously.

On Wednesday, November 11, 2015 at 8:23:16 AM UTC-6, Nicola Mometto wrote:
>
> To be honest I'm not sure this should even be a valid use of type hints.
> You're telling the compiler that the result of (foo) is an int, when it is 
> infact a long.
>
> The correct way to do this should be:
>  (Integer/bitCount (int (foo))
>
> Again, lack of specification on what the correct type hinting semantics 
> should be make it hard to evaluate if this should be considered a bug or 
> just an user error that previously just got ignored.
>
> On 11 Nov 2015, at 12:08, Shantanu Kumar  wrote:
>
> Thanks, Nicola!
>
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846
>
> Shantanu
>
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
>>
>> Here's a minimal repro case:
>>
>> user=> (defn foo ^long [] 1)
>> #'user/foo
>> user=> (Integer/bitCount ^int (foo))
>> VerifyError (class: user$eval13, method: invokeStatic signature: 
>> ()Ljava/lang/Object;) Expecting to find integer on stack 
>>  java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
>>
>>
>> On 11 Nov 2015, at 07:46, Shantanu Kumar  wrote:
>>
>> One of my libraries (https://github.com/kumarshantanu/asphalt) is 
>> failing to compile with 1.8 (works fine with 1.6, 1.7); the stack trace is 
>> below:
>>
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class: 
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>> at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>> at clojure.lang.Compiler.eval(Compiler.java:6918)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:5894)
>> at clojure.core$load_one.invokeStatic(core.clj:5694)
>> at clojure.core$load_one.invoke(core.clj)
>> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>> at clojure.core$load_lib.invokeStatic(core.clj:5738)
>> at clojure.core$load_lib.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$load_libs.invokeStatic(core.clj:5776)
>> at clojure.core$load_libs.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$require.invokeStatic(core.clj:5798)
>> at clojure.core$require.doInvoke(core.clj)
>> at clojure.lang.RestFn.invoke(RestFn.java:457)
>> at 
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>> at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>> at asphalt.test_util$eval198.invoke(test_util.clj)
>> at clojure.lang.Compiler.eval(Compiler.java:6913)
>> at clojure.lang.Compiler.eval(Compiler.java:6902)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:5894)
>> at clojure.core$load_one.invokeStatic(core.clj:5694)
>> at clojure.core$load_one.invoke(core.clj)
>> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>> at clojure.core$load_lib.invokeStatic(core.clj:5738)
>> at clojure.core$load_lib.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$load_libs.invokeStatic(core.clj:5776)
>> at clojure.core$load_libs.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$require.invokeStatic(core.clj:5798)
>> at clojure.core$require.doInvoke(core.clj)
>> at clojure.lang.RestFn.invoke(RestFn.java:457)
>> at 
>> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>> at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>> at asphalt.core_test$eval192.invoke(core_test.clj)
>> at clojure.lang.Compiler.eval(Compiler.java:6913)
>> at clojure.lang.Compiler.eval(Compiler.java:6902)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.la

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Alex Miller

On Wednesday, November 11, 2015 at 2:03:07 PM UTC-6, Andy Fingerhut wrote:
>
> Results of some testing done on 1.8.0-RC1:
>
> Ran 'mvn clean test' on a few OS/JDK combos that are not tested as often.  
> Reason: there have been (or still are) build or test failures with some of 
> them.  All JDKs listed below were 64-bit.
>

Thanks Andy!!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Andy Fingerhut
Results of some testing done on 1.8.0-RC1:

Ran 'mvn clean test' on a few OS/JDK combos that are not tested as often.
Reason: there have been (or still are) build or test failures with some of
them.  All JDKs listed below were 64-bit.

Windows 7 Enterprise SP1 + Oracle JDK 1.7.0_80-b15: ok 3/3 trials
Ubuntu 14.04.3 LTS + OpenJDK 1.7.0_85: ok 3/3 trials
Ubuntu 14.04.3 LTS + IBM JDK 1.7.0: ok 10/10 trials, as long as failing
tests mentioned in http://dev.clojure.org/jira/browse/CLJ-1678 are
commented out
Ubuntu 14.04.3 LTS + IBM JDK 1.8.0 (based on jdk8u51-b15): same as for IBM
JDK 1.7.0
Mac OS X 10.11.1 + Oracle JDK 1.8.0_11: ok 631/631 trials

There were some JVM crashes during 'mvn test' that I have seen with an
earlier version of IBM JDK 1.8.0 (based on jdk8u45-b13), but with the
version mentioned above those seem to be gone.  The older one failed 5 out
of 10 trials.  The newer one gave passing test results with no JVM crash 10
out of 10 trials.

I plan to, but haven't yet, compared Eastwood results with 1.8.0-RC1 vs.
1.7.0.  That will take some work before I can give those results, primarily
updating Eastwood to work with 1.8.0-RC1.  Eastwood makes some assumptions
about the structure of ASTs (abstract syntax trees) that 1.8.0-RC!'s
:rettag addition changed.  I don't think it is much work, but not sure when
I will be able to get to it.  Until then, I have the following message near
the beginning of Eastwood's README:

It has been tried with some of the Clojure 1.8.0-alpha versions, but there
are known problems there (e.g. incorrect warning about misplaced
docstrings, perhaps incorrect warnings about wrong tags, etc.)

Andy


On Tue, Nov 10, 2015 at 9:30 AM, Alex Miller  wrote:

> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!*
> We would appreciate any and all testing you can do on your own libraries or
> internal projects to find problems. If no problems are found, we expect to
> make this the 1.8.0 final release!
>
> Try it via
>
>- Download:
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make
>clojure.core/load dynamic so it can be redef'ed even with direct linking
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Alex Miller
In this case, I am definitely in agreement with FD that producing invalid 
bytecode does not seem like an acceptable outcome. The other two options 
are a compiler error or having the compiler ignore or resolve the mismatch 
such that it produces valid bytecode. Rich is looking at it.

On Wednesday, November 11, 2015 at 9:59:24 AM UTC-6, Nicola Mometto wrote:
>
> Clojure has a history of adopting the GIGO approach
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Nicola Mometto
Clojure has a history of adopting the GIGO approach


> On 11 Nov 2015, at 12:08, Shantanu Kumar  wrote:
> 
> Thanks, Nicola!
> 
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846 
> 
> 
> Shantanu
> 
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
> Here's a minimal repro case:
> 
> user=> (defn foo ^long [] 1)
> #'user/foo
> user=> (Integer/bitCount ^int (foo))
> VerifyError (class: user$eval13, method: invokeStatic signature: 
> ()Ljava/lang/Object;) Expecting to find integer on stack  
> java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
> 
> 
>> On 11 Nov 2015, at 07:46, Shantanu Kumar gmail.com 
>> > wrote:
>> 
>> One of my libraries (https://github.com/kumarshantanu/asphalt 
>> ) is failing to compile with 1.8 
>> (works fine with 1.6, 1.7); the stack trace is below:
>> 
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class: 
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>>  at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>>  at clojure.lang.Compiler.eval(Compiler.java:6918)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>>  at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>>  at asphalt.test_util$eval198.invoke(test_util.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>>  at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>>  at asphalt.core_test$eval192.invoke(core_test.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$lo

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Fluid Dynamics
On Wednesday, November 11, 2015 at 9:23:16 AM UTC-5, Nicola Mometto wrote:
>
> To be honest I'm not sure this should even be a valid use of type hints.
> You're telling the compiler that the result of (foo) is an int, when it is 
> infact a long.
>
> The correct way to do this should be:
>  (Integer/bitCount (int (foo))
>
> Again, lack of specification on what the correct type hinting semantics 
> should be make it hard to evaluate if this should be considered a bug or 
> just an user error that previously just got ignored.
>

It's a bug. Even if ^int (thing-that-returns-long) is a user error, the 
result should be a sane error message from the Clojure compiler, not bad 
bytecode that later fails with a VerifyError. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Alex Miller
Aside on the type hinting specs: - I would be happy to have a doc
contribution at https://github.com/clojure/clojure-site that defines specs
that I could move through review with Rich.

On Wed, Nov 11, 2015 at 8:22 AM, Nicola Mometto  wrote:

> To be honest I'm not sure this should even be a valid use of type hints.
> You're telling the compiler that the result of (foo) is an int, when it is
> infact a long.
>
> The correct way to do this should be:
>  (Integer/bitCount (int (foo))
>
> Again, lack of specification on what the correct type hinting semantics
> should be make it hard to evaluate if this should be considered a bug or
> just an user error that previously just got ignored.
>
> On 11 Nov 2015, at 12:08, Shantanu Kumar  wrote:
>
> Thanks, Nicola!
>
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846
>
> Shantanu
>
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
>>
>> Here's a minimal repro case:
>>
>> user=> (defn foo ^long [] 1)
>> #'user/foo
>> user=> (Integer/bitCount ^int (foo))
>> VerifyError (class: user$eval13, method: invokeStatic signature:
>> ()Ljava/lang/Object;) Expecting to find integer on stack
>>  java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
>>
>>
>> On 11 Nov 2015, at 07:46, Shantanu Kumar  wrote:
>>
>> One of my libraries (https://github.com/kumarshantanu/asphalt) is
>> failing to compile with 1.8 (works fine with 1.6, 1.7); the stack trace is
>> below:
>>
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class:
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature:
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;)
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>> at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>> at clojure.lang.Compiler.eval(Compiler.java:6918)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:5894)
>> at clojure.core$load_one.invokeStatic(core.clj:5694)
>> at clojure.core$load_one.invoke(core.clj)
>> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>> at clojure.core$load_lib.invokeStatic(core.clj:5738)
>> at clojure.core$load_lib.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$load_libs.invokeStatic(core.clj:5776)
>> at clojure.core$load_libs.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$require.invokeStatic(core.clj:5798)
>> at clojure.core$require.doInvoke(core.clj)
>> at clojure.lang.RestFn.invoke(RestFn.java:457)
>> at
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>> at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>> at asphalt.test_util$eval198.invoke(test_util.clj)
>> at clojure.lang.Compiler.eval(Compiler.java:6913)
>> at clojure.lang.Compiler.eval(Compiler.java:6902)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:5894)
>> at clojure.core$load_one.invokeStatic(core.clj:5694)
>> at clojure.core$load_one.invoke(core.clj)
>> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>> at clojure.core$load_lib.invokeStatic(core.clj:5738)
>> at clojure.core$load_lib.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$load_libs.invokeStatic(core.clj:5776)
>> at clojure.core$load_libs.doInvoke(core.clj)
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>> at clojure.core$apply.invokeStatic(core.clj:647)
>> at clojure.core$require.invokeStatic(core.clj:5798)
>> at clojure.core$require.doInvoke(core.clj)
>> at clojure.lang.RestFn.invoke(RestFn.java:457)
>> at
>> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>> at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>> at asphalt.core_test$eval192.invoke(core_test.clj)
>> at clojure.lang.Compiler.eval(Compiler.java:6913)
>> at clojure.lang.Compiler.eval(Compiler.java:6902)
>> at clojure.lang.Compiler.load(Compiler.java:7360)
>> at clojure.lang.RT.loadResourceScript(RT.java:372)
>> at clojure.lang.RT.loadResourceScript(RT.java:363)
>> at clojure.lang.RT.load(RT.java:453)
>> at clojure.lang.RT.load(RT.java:419)
>> at clojure.core$load$fn__5673.invoke(core.clj:5895)
>> at clojure.core$load.invokeStatic(core.clj:58

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Nicola Mometto
To be honest I'm not sure this should even be a valid use of type hints.
You're telling the compiler that the result of (foo) is an int, when it is 
infact a long.

The correct way to do this should be:
 (Integer/bitCount (int (foo))

Again, lack of specification on what the correct type hinting semantics should 
be make it hard to evaluate if this should be considered a bug or just an user 
error that previously just got ignored.

> On 11 Nov 2015, at 12:08, Shantanu Kumar  wrote:
> 
> Thanks, Nicola!
> 
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846 
> 
> 
> Shantanu
> 
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
> Here's a minimal repro case:
> 
> user=> (defn foo ^long [] 1)
> #'user/foo
> user=> (Integer/bitCount ^int (foo))
> VerifyError (class: user$eval13, method: invokeStatic signature: 
> ()Ljava/lang/Object;) Expecting to find integer on stack  
> java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
> 
> 
>> On 11 Nov 2015, at 07:46, Shantanu Kumar gmail.com 
>> > wrote:
>> 
>> One of my libraries (https://github.com/kumarshantanu/asphalt 
>> ) is failing to compile with 1.8 
>> (works fine with 1.6, 1.7); the stack trace is below:
>> 
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class: 
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>>  at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>>  at clojure.lang.Compiler.eval(Compiler.java:6918)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>>  at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>>  at asphalt.test_util$eval198.invoke(test_util.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>>  at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>>  at asphalt.core_test$eval192.invoke(core_test.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Phillip Lord


I've been trying out RC1. I've tried enabling the direct linking in
leiningen, by sticking:

:jvm-opts ["-Dclojure.compiler.direct-linking=true"]

I can't see any particular performance change (when running tests
anyway).

Is there a way to know whether it is actually working?

Phil


Alex Miller  writes:

> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!* 
> We would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
>
> Try it via
>
>- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make 
>clojure.core/load dynamic so it can be redef'ed even with direct linking

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Shantanu Kumar
Thanks, Nicola!

Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846

Shantanu

On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
>
> Here's a minimal repro case:
>
> user=> (defn foo ^long [] 1)
> #'user/foo
> user=> (Integer/bitCount ^int (foo))
> VerifyError (class: user$eval13, method: invokeStatic signature: 
> ()Ljava/lang/Object;) Expecting to find integer on stack 
>  java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
>
>
> On 11 Nov 2015, at 07:46, Shantanu Kumar  > wrote:
>
> One of my libraries (https://github.com/kumarshantanu/asphalt) is failing 
> to compile with 1.8 (works fine with 1.6, 1.7); the stack trace is below:
>
> $ lein do clean, with-profile dev,c18 test
> Exception in thread "main" java.lang.VerifyError: (class: 
> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
> Expecting to find integer on stack, compiling:(core.clj:201:1)
> at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
> at clojure.lang.Compiler.eval(Compiler.java:6918)
> at clojure.lang.Compiler.load(Compiler.java:7360)
> at clojure.lang.RT.loadResourceScript(RT.java:372)
> at clojure.lang.RT.loadResourceScript(RT.java:363)
> at clojure.lang.RT.load(RT.java:453)
> at clojure.lang.RT.load(RT.java:419)
> at clojure.core$load$fn__5673.invoke(core.clj:5895)
> at clojure.core$load.invokeStatic(core.clj:5894)
> at clojure.core$load_one.invokeStatic(core.clj:5694)
> at clojure.core$load_one.invoke(core.clj)
> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
> at clojure.core$load_lib.invokeStatic(core.clj:5738)
> at clojure.core$load_lib.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$load_libs.invokeStatic(core.clj:5776)
> at clojure.core$load_libs.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$require.invokeStatic(core.clj:5798)
> at clojure.core$require.doInvoke(core.clj)
> at clojure.lang.RestFn.invoke(RestFn.java:457)
> at 
> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
> at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
> at asphalt.test_util$eval198.invoke(test_util.clj)
> at clojure.lang.Compiler.eval(Compiler.java:6913)
> at clojure.lang.Compiler.eval(Compiler.java:6902)
> at clojure.lang.Compiler.load(Compiler.java:7360)
> at clojure.lang.RT.loadResourceScript(RT.java:372)
> at clojure.lang.RT.loadResourceScript(RT.java:363)
> at clojure.lang.RT.load(RT.java:453)
> at clojure.lang.RT.load(RT.java:419)
> at clojure.core$load$fn__5673.invoke(core.clj:5895)
> at clojure.core$load.invokeStatic(core.clj:5894)
> at clojure.core$load_one.invokeStatic(core.clj:5694)
> at clojure.core$load_one.invoke(core.clj)
> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
> at clojure.core$load_lib.invokeStatic(core.clj:5738)
> at clojure.core$load_lib.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$load_libs.invokeStatic(core.clj:5776)
> at clojure.core$load_libs.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$require.invokeStatic(core.clj:5798)
> at clojure.core$require.doInvoke(core.clj)
> at clojure.lang.RestFn.invoke(RestFn.java:457)
> at 
> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
> at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
> at asphalt.core_test$eval192.invoke(core_test.clj)
> at clojure.lang.Compiler.eval(Compiler.java:6913)
> at clojure.lang.Compiler.eval(Compiler.java:6902)
> at clojure.lang.Compiler.load(Compiler.java:7360)
> at clojure.lang.RT.loadResourceScript(RT.java:372)
> at clojure.lang.RT.loadResourceScript(RT.java:363)
> at clojure.lang.RT.load(RT.java:453)
> at clojure.lang.RT.load(RT.java:419)
> at clojure.core$load$fn__5673.invoke(core.clj:5895)
> at clojure.core$load.invokeStatic(core.clj:5894)
> at clojure.core$load_one.invokeStatic(core.clj:5694)
> at clojure.core$load_one.invoke(core.clj)
> at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
> at clojure.core$load_lib.invokeStatic(core.clj:5738)
> at clojure.core$load_lib.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$load_libs.invokeStatic(core.clj:5776)
> at clojure.core$load_libs.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$require.invokeStatic(core.clj:5798)
> at clojure.core$require.doInvoke(core.clj)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invokeStatic(core.clj:647)
> at clojure.core$apply.invoke(core.clj)
> at user$eval91.invokeStati

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Nicola Mometto
Here's a minimal repro case:

user=> (defn foo ^long [] 1)
#'user/foo
user=> (Integer/bitCount ^int (foo))
VerifyError (class: user$eval13, method: invokeStatic signature: 
()Ljava/lang/Object;) Expecting to find integer on stack  
java.lang.Class.getDeclaredConstructors0 (Class.java:-2)


> On 11 Nov 2015, at 07:46, Shantanu Kumar  wrote:
> 
> One of my libraries (https://github.com/kumarshantanu/asphalt) is failing to 
> compile with 1.8 (works fine with 1.6, 1.7); the stack trace is below:
> 
> $ lein do clean, with-profile dev,c18 test
> Exception in thread "main" java.lang.VerifyError: (class: 
> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
> Expecting to find integer on stack, compiling:(core.clj:201:1)
>   at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>   at clojure.lang.Compiler.eval(Compiler.java:6918)
>   at clojure.lang.Compiler.load(Compiler.java:7360)
>   at clojure.lang.RT.loadResourceScript(RT.java:372)
>   at clojure.lang.RT.loadResourceScript(RT.java:363)
>   at clojure.lang.RT.load(RT.java:453)
>   at clojure.lang.RT.load(RT.java:419)
>   at clojure.core$load$fn__5673.invoke(core.clj:5895)
>   at clojure.core$load.invokeStatic(core.clj:5894)
>   at clojure.core$load_one.invokeStatic(core.clj:5694)
>   at clojure.core$load_one.invoke(core.clj)
>   at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>   at clojure.core$load_lib.invokeStatic(core.clj:5738)
>   at clojure.core$load_lib.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$load_libs.invokeStatic(core.clj:5776)
>   at clojure.core$load_libs.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$require.invokeStatic(core.clj:5798)
>   at clojure.core$require.doInvoke(core.clj)
>   at clojure.lang.RestFn.invoke(RestFn.java:457)
>   at 
> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>   at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>   at asphalt.test_util$eval198.invoke(test_util.clj)
>   at clojure.lang.Compiler.eval(Compiler.java:6913)
>   at clojure.lang.Compiler.eval(Compiler.java:6902)
>   at clojure.lang.Compiler.load(Compiler.java:7360)
>   at clojure.lang.RT.loadResourceScript(RT.java:372)
>   at clojure.lang.RT.loadResourceScript(RT.java:363)
>   at clojure.lang.RT.load(RT.java:453)
>   at clojure.lang.RT.load(RT.java:419)
>   at clojure.core$load$fn__5673.invoke(core.clj:5895)
>   at clojure.core$load.invokeStatic(core.clj:5894)
>   at clojure.core$load_one.invokeStatic(core.clj:5694)
>   at clojure.core$load_one.invoke(core.clj)
>   at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>   at clojure.core$load_lib.invokeStatic(core.clj:5738)
>   at clojure.core$load_lib.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$load_libs.invokeStatic(core.clj:5776)
>   at clojure.core$load_libs.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$require.invokeStatic(core.clj:5798)
>   at clojure.core$require.doInvoke(core.clj)
>   at clojure.lang.RestFn.invoke(RestFn.java:457)
>   at 
> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>   at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>   at asphalt.core_test$eval192.invoke(core_test.clj)
>   at clojure.lang.Compiler.eval(Compiler.java:6913)
>   at clojure.lang.Compiler.eval(Compiler.java:6902)
>   at clojure.lang.Compiler.load(Compiler.java:7360)
>   at clojure.lang.RT.loadResourceScript(RT.java:372)
>   at clojure.lang.RT.loadResourceScript(RT.java:363)
>   at clojure.lang.RT.load(RT.java:453)
>   at clojure.lang.RT.load(RT.java:419)
>   at clojure.core$load$fn__5673.invoke(core.clj:5895)
>   at clojure.core$load.invokeStatic(core.clj:5894)
>   at clojure.core$load_one.invokeStatic(core.clj:5694)
>   at clojure.core$load_one.invoke(core.clj)
>   at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>   at clojure.core$load_lib.invokeStatic(core.clj:5738)
>   at clojure.core$load_lib.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$load_libs.invokeStatic(core.clj:5776)
>   at clojure.core$load_libs.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Alex Miller
Can you file a ticket for that VerifyError Shantanu?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-11 Thread Alex Miller
There is a Potemkin error that was exposed during 1.8 that looks like this (the 
compile_stub) - is that library in your dependencies? If so, supplying the 
latest version explicitly should fix the problem.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Shantanu Kumar
One of my libraries (https://github.com/kumarshantanu/asphalt) is failing 
to compile with 1.8 (works fine with 1.6, 1.7); the stack trace is below:

$ lein do clean, with-profile dev,c18 test
Exception in thread "main" java.lang.VerifyError: (class: 
asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
Expecting to find integer on stack, compiling:(core.clj:201:1)
at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
at clojure.lang.Compiler.eval(Compiler.java:6918)
at clojure.lang.Compiler.load(Compiler.java:7360)
at clojure.lang.RT.loadResourceScript(RT.java:372)
at clojure.lang.RT.loadResourceScript(RT.java:363)
at clojure.lang.RT.load(RT.java:453)
at clojure.lang.RT.load(RT.java:419)
at clojure.core$load$fn__5673.invoke(core.clj:5895)
at clojure.core$load.invokeStatic(core.clj:5894)
at clojure.core$load_one.invokeStatic(core.clj:5694)
at clojure.core$load_one.invoke(core.clj)
at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
at clojure.core$load_lib.invokeStatic(core.clj:5738)
at clojure.core$load_lib.doInvoke(core.clj)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:647)
at clojure.core$load_libs.invokeStatic(core.clj:5776)
at clojure.core$load_libs.doInvoke(core.clj)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:647)
at clojure.core$require.invokeStatic(core.clj:5798)
at clojure.core$require.doInvoke(core.clj)
at clojure.lang.RestFn.invoke(RestFn.java:457)
at 
asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
at asphalt.test_util$eval198.invoke(test_util.clj)
at clojure.lang.Compiler.eval(Compiler.java:6913)
at clojure.lang.Compiler.eval(Compiler.java:6902)
at clojure.lang.Compiler.load(Compiler.java:7360)
at clojure.lang.RT.loadResourceScript(RT.java:372)
at clojure.lang.RT.loadResourceScript(RT.java:363)
at clojure.lang.RT.load(RT.java:453)
at clojure.lang.RT.load(RT.java:419)
at clojure.core$load$fn__5673.invoke(core.clj:5895)
at clojure.core$load.invokeStatic(core.clj:5894)
at clojure.core$load_one.invokeStatic(core.clj:5694)
at clojure.core$load_one.invoke(core.clj)
at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
at clojure.core$load_lib.invokeStatic(core.clj:5738)
at clojure.core$load_lib.doInvoke(core.clj)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:647)
at clojure.core$load_libs.invokeStatic(core.clj:5776)
at clojure.core$load_libs.doInvoke(core.clj)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:647)
at clojure.core$require.invokeStatic(core.clj:5798)
at clojure.core$require.doInvoke(core.clj)
at clojure.lang.RestFn.invoke(RestFn.java:457)
at 
asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
at asphalt.core_test$eval192.invoke(core_test.clj)
at clojure.lang.Compiler.eval(Compiler.java:6913)
at clojure.lang.Compiler.eval(Compiler.java:6902)
at clojure.lang.Compiler.load(Compiler.java:7360)
at clojure.lang.RT.loadResourceScript(RT.java:372)
at clojure.lang.RT.loadResourceScript(RT.java:363)
at clojure.lang.RT.load(RT.java:453)
at clojure.lang.RT.load(RT.java:419)
at clojure.core$load$fn__5673.invoke(core.clj:5895)
at clojure.core$load.invokeStatic(core.clj:5894)
at clojure.core$load_one.invokeStatic(core.clj:5694)
at clojure.core$load_one.invoke(core.clj)
at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
at clojure.core$load_lib.invokeStatic(core.clj:5738)
at clojure.core$load_lib.doInvoke(core.clj)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:647)
at clojure.core$load_libs.invokeStatic(core.clj:5776)
at clojure.core$load_libs.doInvoke(core.clj)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:647)
at clojure.core$require.invokeStatic(core.clj:5798)
at clojure.core$require.doInvoke(core.clj)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:647)
at clojure.core$apply.invoke(core.clj)
at user$eval91.invokeStatic(form-init7505432955041312280.clj:1)
at user$eval91.invoke(form-init7505432955041312280.clj)
at clojure.lang.Compiler.eval(Compiler.java:6913)
at clojure.lang.Compiler.eval(Compiler.java:6903)
at clojure.lang.Compiler.load(Compiler.java:7360)
at clojure.lang.Compiler.loadFile(Compiler.java:7298)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$init_opt.invokeStatic(main.clj:277)
at clojure.main$init_opt.invoke(main.clj)
at clojure.main$initialize.invokeStatic(main.clj:308)
at clojure.main$null_opt.invokeStatic(main.clj:342)
at clojure.main$null_opt.invoke(main.clj)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj)
at clojure.lang.Res

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Robin Heggelund Hansen
I got an exception when compiling with this RC (exception below). Seems it 
have trouble compiling aleph, so I've added an issue there. I assume you 
will be contacted if the bug is found to be an error in Clojure itself, and 
not Aleph.

#error {
 :cause IllegalName: compile__stub.aleph.http.core.aleph.http.core/HeaderMap
 :via
 [{:type clojure.lang.Compiler$CompilerException
   :message java.lang.NoClassDefFoundError: IllegalName: 
compile__stub.aleph.http.core.aleph.http.core/HeaderMap, 
compiling:(aleph/http/core.clj:81:1)
   :at [clojure.lang.Compiler analyzeSeq Compiler.java 6861]}
  {:type java.lang.NoClassDefFoundError
   :message IllegalName: 
compile__stub.aleph.http.core.aleph.http.core/HeaderMap
   :at [java.lang.ClassLoader preDefineClass ClassLoader.java 654]}]
 :trace
 [[java.lang.ClassLoader preDefineClass ClassLoader.java 654]
  [java.lang.ClassLoader defineClass ClassLoader.java 758]
  [java.lang.ClassLoader defineClass ClassLoader.java 642]
  [clojure.lang.DynamicClassLoader defineClass DynamicClassLoader.java 46]
  [clojure.lang.Compiler$NewInstanceExpr compileStub Compiler.java 7880]
  [clojure.lang.Compiler$NewInstanceExpr build Compiler.java 7745]
  [clojure.lang.Compiler$NewInstanceExpr$DeftypeParser parse Compiler.java 
7655]
  [clojure.lang.Compiler analyzeSeq Compiler.java 6854]
  [clojure.lang.Compiler analyze Compiler.java 6655]
  [clojure.lang.Compiler analyze Compiler.java 6611]
  [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5987]
  [clojure.lang.Compiler$LetExpr$Parser parse Compiler.java 6305]
  [clojure.lang.Compiler analyzeSeq Compiler.java 6854]
  [clojure.lang.Compiler analyze Compiler.java 6655]
  [clojure.lang.Compiler analyze Compiler.java 6611]
  [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5987]
  [clojure.lang.Compiler$FnMethod parse Compiler.java 5368]
  [clojure.lang.Compiler$FnExpr parse Compiler.java 3971]
  [clojure.lang.Compiler analyzeSeq Compiler.java 6852]
  [clojure.lang.Compiler analyze Compiler.java 6655]
  [clojure.lang.Compiler eval Compiler.java 6910]
  [clojure.lang.Compiler eval Compiler.java 6902]
  [clojure.lang.Compiler load Compiler.java 7360]
  [clojure.lang.RT loadResourceScript RT.java 372]
  [clojure.lang.RT loadResourceScript RT.java 363]
  [clojure.lang.RT load RT.java 453]
  [clojure.lang.RT load RT.java 419]
  [clojure.core$load$fn__5673 invoke core.clj 5895]
  [clojure.core$load invokeStatic core.clj 5894]
  [clojure.core$load_one invokeStatic core.clj 5694]
  [clojure.core$load_one invoke core.clj -1]
  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]
  [clojure.core$load_lib invokeStatic core.clj 5738]
  [clojure.core$load_lib doInvoke core.clj -1]
  [clojure.lang.RestFn applyTo RestFn.java 142]
  [clojure.core$apply invokeStatic core.clj 647]
  [clojure.core$load_libs invokeStatic core.clj 5776]
  [clojure.core$load_libs doInvoke core.clj -1]
  [clojure.lang.RestFn applyTo RestFn.java 137]
  [clojure.core$apply invokeStatic core.clj 647]
  [clojure.core$require invokeStatic core.clj 5798]
  [clojure.core$require doInvoke core.clj -1]
  [clojure.lang.RestFn invoke RestFn.java 551]
  [aleph.http.server$eval18258$loading__5565__auto18259 invoke 
server.clj 1]
  [aleph.http.server$eval18258 invokeStatic server.clj 1]
  [aleph.http.server$eval18258 invoke server.clj -1]
  [clojure.lang.Compiler eval Compiler.java 6913]
  [clojure.lang.Compiler eval Compiler.java 6902]
  [clojure.lang.Compiler load Compiler.java 7360]
  [clojure.lang.RT loadResourceScript RT.java 372]
  [clojure.lang.RT loadResourceScript RT.java 363]
  [clojure.lang.RT load RT.java 453]
  [clojure.lang.RT load RT.java 419]
  [clojure.core$load$fn__5673 invoke core.clj 5895]
  [clojure.core$load invokeStatic core.clj 5894]
  [clojure.core$load_one invokeStatic core.clj 5694]
  [clojure.core$load_one invoke core.clj -1]
  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]
  [clojure.core$load_lib invokeStatic core.clj 5738]
  [clojure.core$load_lib doInvoke core.clj -1]
  [clojure.lang.RestFn applyTo RestFn.java 142]
  [clojure.core$apply invokeStatic core.clj 647]
  [clojure.core$load_libs invokeStatic core.clj 5780]
  [clojure.core$load_libs doInvoke core.clj -1]
  [clojure.lang.RestFn applyTo RestFn.java 137]
  [clojure.core$apply invokeStatic core.clj 647]
  [clojure.core$require invokeStatic core.clj 5798]
  [clojure.core$require doInvoke core.clj -1]
  [clojure.lang.RestFn invoke RestFn.java 457]
  [aleph.http$eval16931$loading__5565__auto16932 invoke http.clj 1]
  [aleph.http$eval16931 invokeStatic http.clj 1]
  [aleph.http$eval16931 invoke http.clj -1]
  [clojure.lang.Compiler eval Compiler.java 6913]
  [clojure.lang.Compiler eval Compiler.java 6902]
  [clojure.lang.Compiler load Compiler.java 7360]
  [clojure.lang.RT loadResourceScript RT.java 372]
  [clojure.lang.RT loadResourceScript RT.java 363]
  [clojure.lang.RT load RT.java 453]
  [clojure.lang.RT load RT.java 419]
  [clojure.core$load$fn__5673 invoke core.clj 589

Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Mike Rodriguez
I did a trial run of some of my production applications (big data space) and I 
did see an overall improvement in execution time that seemed consistent. It was 
not too significant of a difference though, but it was still good to see. I am 
not positive my use case would have necessarily been in position to drastically 
improve from the direct linking at this point though anyways. 
I also haven't tried to direct link my own application code (I think that's an 
option you can switch on, I forget ). 

I was just curious to hear if there were some significant differences people 
have observed. It's always good to see concrete examples. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Alex Miller
I would love for people to try building their apps with and without direct 
linking to see if there is a difference! Has anyone done so?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Mike Rodriguez
I second Ghadi's question (2). Is there any further information to read that 
discusses the benefits found from direct linking? I understand the motivation. 
I was just hoping to here some performance boost success stories. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Michael Drogalis
Upgrading Clojure to 1.8.0-RC1 passed Onyx's full test suite. Thumbs up on 
our end.

On Tuesday, November 10, 2015 at 9:30:47 AM UTC-8, Alex Miller wrote:
>
> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!* 
> We would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make 
>clojure.core/load dynamic so it can be redef'ed even with direct linking
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Ghadi Shayban
Never mind the first point.  I've been pointed to the fact that 
Tuple/create returns a PV [1]

[1] 
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Tuple.java#L22

On Tuesday, November 10, 2015 at 1:15:44 PM UTC-5, Ghadi Shayban wrote:
>
> Two points of feedback:
>
>
> 1) One of the reason tuples were disabled was that they polluted dispatch 
> paths.  Shouldn't we make sure that they are completely inactive?
>
>Map entries (everywhere: c.l.Persistent*, records, gvec, bean) still 
> use them.
>
> 2) I get the rationale behind direct linking, but I'm lacking evidence 
> that the benefits are achieved.
>
>
>
> On Tuesday, November 10, 2015 at 12:30:47 PM UTC-5, Alex Miller wrote:
>>
>> Clojure 1.8.0-RC1 is now available. *This build is a "release 
>> candidate"!* We would appreciate any and all testing you can do on your 
>> own libraries or internal projects to find problems. If no problems are 
>> found, we expect to make this the 1.8.0 final release! 
>>
>> Try it via
>>
>>- Download: 
>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>>
>> Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
>> here: https://github.com/clojure/clojure/blob/master/changes.md.
>>
>>- CLJ-1845  Make 
>>clojure.core/load dynamic so it can be redef'ed even with direct linking
>>
>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Alan Thompson
Just keeps it simpler when typing, and most other things seem to be all
lowercase.  Not a big deal.
Alan

On Tue, Nov 10, 2015 at 9:55 AM, Alex Miller  wrote:

> Any reason why?
>
> On Tuesday, November 10, 2015 at 11:51:40 AM UTC-6, Alan Thompson wrote:
>>
>> Runs fine in my tests.
>>
>> One small question: would it be feasible to keep everything lowercase in
>> the future (i.e. org.clojure:clojure:jar:1.8.0-rc1)?
>>
>> Keep up the great work,
>> Alan
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Ghadi Shayban
Two points of feedback:


1) One of the reason tuples were disabled was that they polluted dispatch 
paths.  Shouldn't we make sure that they are completely inactive?

   Map entries (everywhere: c.l.Persistent*, records, gvec, bean) still use 
them.

2) I get the rationale behind direct linking, but I'm lacking evidence that 
the benefits are achieved.



On Tuesday, November 10, 2015 at 12:30:47 PM UTC-5, Alex Miller wrote:
>
> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!* 
> We would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make 
>clojure.core/load dynamic so it can be redef'ed even with direct linking
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Alex Miller
Any reason why?

On Tuesday, November 10, 2015 at 11:51:40 AM UTC-6, Alan Thompson wrote:
>
> Runs fine in my tests.
>
> One small question: would it be feasible to keep everything lowercase in 
> the future (i.e. org.clojure:clojure:jar:1.8.0-rc1)?
>
> Keep up the great work,
> Alan
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Alan Thompson
Runs fine in my tests.

One small question: would it be feasible to keep everything lowercase in
the future (i.e. org.clojure:clojure:jar:1.8.0-rc1)?

Keep up the great work,
Alan

On Tue, Nov 10, 2015 at 9:30 AM, Alex Miller  wrote:

> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!*
> We would appreciate any and all testing you can do on your own libraries or
> internal projects to find problems. If no problems are found, we expect to
> make this the 1.8.0 final release!
>
> Try it via
>
>- Download:
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
>- Leiningen: [org.clojure/clojure "1.8.0-RC1"]
>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  Make
>clojure.core/load dynamic so it can be redef'ed even with direct linking
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[ANN] Clojure 1.8.0-RC1 is now available

2015-11-10 Thread Alex Miller
Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!* 
We would appreciate any and all testing you can do on your own libraries or 
internal projects to find problems. If no problems are found, we expect to 
make this the 1.8.0 final release! 

Try it via

   - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
   - Leiningen: [org.clojure/clojure "1.8.0-RC1"]

Below is the only change since 1.8.0-beta2. See the full 1.8 change log 
here: https://github.com/clojure/clojure/blob/master/changes.md.

   - CLJ-1845  Make 
   clojure.core/load dynamic so it can be redef'ed even with direct linking


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.