ANN: ClojureScript 0.0-2067, regressions, type inference & numeric checks

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

New release version: 0.0-2067

Leiningen dependency information:

    [org.clojure/clojurescript "0.0-2067"]

This release fixes issues introduced by the source map checks, the

checks have been relaxed.

This release also include a fairly significant enhancement - pervasive

simple type inference. This is to detect common mistakes involving

primitive arithmetic and non-numeric types. However this also adds a

new pass to the compiler and stores more information in compiler

environment. Feedback on signifiant changes to compile time and memory 

usage welcome.

Enhancements:

* pervasive inference, inlined primitive arithmetic is now checked

Bug fixes:

* CLJS-685: elide :end-column :end-line from metadata

* CLJS-694: remove Java 7 dependency

[Moritz Ulrich]

Exciting news!

Feedback to speed/memory: With :optimizations :whitespace (my default,
for convenience reasons) the generation of the final result (main.js)
takes forever and eventually dies with an OOM exception: GC overhead
limit exceeded.

I'm running lein-cljsbuild-1.0 and 0.0.2067 of Clojurescript.

This isn't a big project, just some tests with core.async and Prismatic's dommy.

> --
> Note that posts from new members are moderated - please be patient with your
> first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescrip...@googlegroups.com.
> To post to this group, send email to clojur...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

[Moritz Ulrich]

Small addition: All intermediate files are generated just fine. It's
just the main.js that fails with OOM. Incremental compilation doesn't
seem to help either.

--
Moritz Ulrich

[Moritz Ulrich]

And *another* addition - I'm sorry.

I tracked it down to a problem with source-maps. After deactivating
them I didn't get another OOM.

That's rather interesting: It generates main.js.map just fine, then
goes to 100% CPU and fails with an OOM after one or two minutes.

[David Nolen]

I've tested by building core.async itself already no problems. What memory settings are you giving to the JVM and are they actually being respected (i.e. a lein-cljsbuild bug) ?

David

[Tim Visher]

I'm compiling fine with source-maps enabled in both whitespace and
advanced mode, with marginal but not awful increases to time.

[Mimmo Cosenza]

Hi David,

some problem here.

If I switch to cljsbuild 0.3.4 it works, but it use a lot of memory. With r2060 (even if there is a dependency on jvm7) the compilation works with cljsbuild 1.0.0 too (not the r2030).

I'm start to think (but I did not investigated) that it's not a cljsbuild 1.0.0 bug (aside from limiting the heap to 256M, which is not so small).

mimmo

[Chas Emerick]

https://github.com/emezeske/lein-cljsbuild/issues/271 has a
reproducible case provided by Mimmo that doesn't involve source maps.
(The error emitted by JDK 7 — "GC overhead limit exceeded" — *can* be
significant, i.e. just bumping -Xmx doesn't always work, if the program
in question is allocating in such a way that the GC simply can't keep
up.)

Anyway, bumping the heap to 512m does work for Mimmo's test case. I'll
get a hack into cljsbuild shortly that will allow you to control the
heap of the compilation subprocess via :jvm-opts, but it seems like
there's something else going on if 512m is needed. That the
compilation will succeed after some part of the work is done definitely
points to a leak (or, over-aggressive caching) of some kind.

- Chas

On Fri 22 Nov 2013 11:16:18 AM EST, Mimmo Cosenza wrote:
> Hi David,
> some problem here.
>
> If I switch to cljsbuild 0.3.4 it works, but it use a lot of memory.
> With r2060 (even if there is a dependency on jvm7) the compilation
> works with cljsbuild 1.0.0 too (not the r2030).
>
> I'm start to think (but I did not investigated) that it's not a
> cljsbuild 1.0.0 bug (aside from limiting the heap to 256M, which is
> not so small).
>
> mimmo
>
>
>
> On Nov 22, 2013, at 5:01 PM, David Nolen <dnolen...@gmail.com

>> <mailto:clojurescript%2Bunsu...@googlegroups.com>.

>> >> To post to this group, send email to
>> clojur...@googlegroups.com

>> <mailto:clojur...@googlegroups.com>.

>> >> Visit this group at http://groups.google.com/group/clojurescript.
>>
>>
>> --
>> Moritz Ulrich
>>
>>
>>
>> --
>> Note that posts from new members are moderated - please be patient
>> with your first post.
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to clojurescrip...@googlegroups.com

>> <mailto:clojurescrip...@googlegroups.com>.

>> To post to this group, send email to clojur...@googlegroups.com

>> <mailto:clojur...@googlegroups.com>.

[Mimmo Cosenza]

David,
I know you're a super master, but if you're going to use my repo, just remember to exclude the tools.reader from the org.clojars.magomimmo/shoreleave-remote-ring dependency which uses the 0.7.10 release.

hih

mimmo

[David Nolen]

Can everyone please try master and verify the memory issue no longer exists? 

Thanks!

David

[David Nolen]

0.0-2069 released, the only change is not caching AST nodes in the compiler environment. Should address the memory issues people are experiencing.

David

[Julien Eluard]

I can confirm I don't see the issue anymore.

Thanks!

Julien

[Mimmo Cosenza]

me too. just tested my  reproducible repo with cljs master and it works now!

Thanks David!

mimmo