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

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

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

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 >

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

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

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

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

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

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

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

*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 []

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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: >

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

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: > >

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

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

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

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"

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

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

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

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

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

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

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

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: >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

[ANN] Clojure 1.8.0-RC1 is now available

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:

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

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,

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

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

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

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

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

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

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

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

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

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

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

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:

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

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: