Clojurians
#cljs-dev
<
2017-01-24
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

martinklepsch17:01:06

@dnolen resuming from twitter: maybe do a sneak peek before it gets out so issues can be ironed out before “it hits the news”?

dnolen17:01:25

@martinklepsch there’s not a great way to do that with the website far as I know?

dnolen17:01:38

@alexmiller do we have staging place for the ClojureScript website?

martinklepsch17:01:12

@dnolen if there’s a git repo with a branch that can be shared here maybe that would be sufficient? I guess it’s all markdown/asciidoc/etc

dnolen17:01:42

@martinklepsch cutting a release doesn’t seem necessary if people just want to kick the tires - I also suspect it doesn’t matter what we do there will be lot of fixes enhancements around this stuff

dnolen17:01:48

it’s all definitely alpha

dnolen17:01:33

this one is not done yet

dnolen17:01:55

this one more or less is

martinklepsch17:01:57

was just looking for that repo :slightly_smiling_face:

alexmiller17:01:01

We do have staging, but it's not public

alexmiller17:01:28

I can walk you through it though @dnolen if needed

dnolen17:01:52

@alexmiller can’t go through it right now - but if you have some time Friday I will ping you :slightly_smiling_face:

martinklepsch17:01:06

Cool, staging not needed I guess.

martinklepsch17:01:30

ping @roman01la — might be of interest to you as well

dnolen17:01:53

@martinklepsch the Externs guide assumes Quick Start

martinklepsch17:01:59

@dnolen I’ll check the links and give it a shot tomorrow

dnolen17:01:02

the JS Modules one just uses Leinengen for deps

martinklepsch17:01:45

Tried the externs stuff in some basic form before, worked great :ok_hand: (not sure if I ever reported back, sorry :)

dnolen17:01:19

@martinklepsch heh, it was actually pretty broken :slightly_smiling_face:

dnolen17:01:26

so you might want to try it again - much more enhanced now

dnolen17:01:39

might not be obvious though

martinklepsch18:01:16

:smile: I tried pretty basic stuff and the warnings were super helpful + after addressing them the advanced build seemed right IIRC, but again, basic cases...

dnolen18:01:57

yeah the warnings are a bit fancier now

dnolen18:01:14

and actually it demonstrates that the ClojureScript could do a lot more wrt. interop validation

dnolen18:01:21

but that’s for later

martinklepsch18:01:45

sounds exciting! loving the docs as well :slightly_smiling_face:

dnolen18:01:39

glad to hear it :slightly_smiling_face:

darwin20:01:36

just started investigating CLJS-1901 and the task of inlining source maps found this interesting condition while reading the code: https://github.com/clojure/clojurescript/blob/960bb9b778190aa7359acb2f74cc61d452cef2ae/src/main/clojure/cljs/compiler.cljc#L1315 is this for historical reason because advanced optimization would render our maps invalid and there was no way to make it work? I think when :source-map is enabled in opts, we should allow source maps generation in advanced mode as well and let closure compiler to transform it

dnolen20:01:39

@darwin source maps work with advanced compilation

dnolen20:01:46

there’s just no reason to write intermediate stuff to disk

dnolen20:01:05

look at cljs/closure.clj to see how source map merging works

darwin20:01:18

ah, ok thanks

darwin20:01:59

didn’t read that yet, so the idea is to take closure-produced source map and our (:none-mode) cljs source map and concatenate them in order: cljs-map + closure-map, so that result maps from original cljs sources to optimized result after closure compilation, right?

dnolen20:01:19

there is no concatenation

dnolen20:01:22

just merging

dnolen20:01:36

order doesn’t matter

dnolen20:01:43

it’s just mapping to mapping

darwin20:01:21

I’m probably missing something here, the concatenation must happen somewhere

dnolen20:01:33

why do you need concatenation?

darwin20:01:03

the mapping form original cljs source to cljs-produced-js must be recorded somewhere

darwin20:01:19

google closure goes from cljs-produced-js to final advanced-js

dnolen20:01:23

the Google Closure source map is from every preserved location (DCE removes stuff) to the compiled JS source file location

dnolen20:01:55

Loc GADV-JS -> Loc CLJS-GENJS

dnolen21:01:41

each original CLJS input to the compiler has an in memory mapping of Loc CLJS-GENJS -> Loc CLJS

dnolen21:01:08

Loc GADV-JS -> Loc CLJS-GENJS -> Loc CLJS

dnolen21:01:15

no concatenation of any kind required

darwin21:01:03

ok, thanks

darwin21:01:21

there was a naming confusion, by “concatenation" I meant what you mean by “merging" and what closure devs call “composing of source maps” :slightly_smiling_face: [1] looking into —source_map_input flag [1] https://github.com/google/closure-compiler/pull/2129#issue-187494266

dnolen21:01:38

@darwin ok sorry was confused, usually think about appending when people say concatenation here

dnolen21:01:54

so I thought you were talking about appending source maps together which we don’t do

darwin21:01:03

I got confused by “merging” because normal clojure map merging clicked in my head :slightly_smiling_face:

dnolen21:01:38

right, “composing” is probably a better word here

dnolen21:01:42

like f -> g -> h

darwin22:01:14

gathered some intel here: http://dev.clojure.org/jira/browse/CLJS-1901 It looks promising, I’m going to implement a flag to optionally inline source maps in generated js files using data URLs. This will fix my original issue[1] but also opens a possibility for closure compiler to read our source maps as input (in all compilation modes). This would enable: 1. better closure compiler error reporting with source-mapped messages back to original sources 2. complete production of source maps by closure compiler. We could remove emit-optimized-source-map and rely solely on closure compiler to do the right job. Not sure about backward compatibility. Our compiler flags should map reasonably to closure compiler ones. Also not sure about module splitting and other advanced closure compiler features (yet). [1] https://github.com/binaryage/dirac/blob/master/docs/node.md#source-maps

dnolen22:01:48

@darwin yes looks promising but quite a bit of due diligence involved in this one

darwin22:01:26

I just wanted make sure that my potential work on inlined source maps won’t be wasted time in the light of recent closure compiler development with source maps support. Also from what I’ve seen implementing inlining in cljs compiler seems easy. So even if it didn’t land it won’t be much wasted effort.

dnolen22:01:53

@darwin as long Google Closure can be shown to use the inlined source maps and that the result is as good / better than what we have this is an enhancement I’m all for

dnolen22:01:02

less stuff for us to maintain

dnolen22:01:04

the best code is no code

darwin22:01:55

this is a bit fishy: https://github.com/clojure/clojurescript/blame/master/src/main/clojure/cljs/compiler.cljc#L1228-L1230 I assume the goal was to get relative path from output-dir to sm-file if the sm-file has output-dir as prefix, or leave it as is otherwise

darwin22:01:14

my concern: this could cause unexpected replacements in sm-file if it happens to repeat output-dir in the path multiple times

darwin22:01:05

e.g. output-dir is /root/web and sm-file is /root/web/my-project/resources/root/web/something/my-file.js.map