Fork me on GitHub
#cljs-dev
<
2017-03-21
>
superstructor02:03:10

Is there a reason why clj->js uses doseq to build up #js arrays instead of reduce which is faster ?

anmonteiro02:03:35

@superstructor probably historical reasons. if you see reduce is faster, please create a ticket with benchmarks

anmonteiro02:03:45

if we verify it's faster I'm sure it'll be considered

jjl07:03:17

Apparently I should discuss CLJS-1986 (es6 generators) here

jjl07:03:06

i wanted them for a build tool i'm writing in cljs. async/await will be supported in node soon and this is a stepping stone towards that

jjl07:03:48

given that google closure supports transpiling them to es3, i'm not sure what the problem is

thheller08:03:40

@jjl one issue is that while in development most people are using :none which does not go through closure

jjl08:03:07

i considered that. i think most people develop against a modern browser

thheller08:03:10

so it will break if their browser doesn't support it

jjl08:03:18

also you need to actually use that feature

thheller08:03:25

I have to run everything I do in IE10

thheller08:03:32

which doesn't have await

jjl08:03:04

neither does node yet (except on master). this is generators (function*, yield)

thheller08:03:05

its also a dependency issue .. a library I may want to use may use it

jjl08:03:36

nod. my use case was for node. i don't think it's such a compelling feature in the browser

jjl08:03:02

this is for macchiato btw

thheller08:03:17

people tend to use things they read about .. so if someone reads that CLJS does support await they will start using it

jjl08:03:36

if we follow that reasoning, we never get any new things

thheller08:03:41

and maybe miss the browser support issue

thheller08:03:02

FWIW I think core.async is 10x better than await

jjl08:03:30

i think forcing core.async upon users isn't a good thing in a library

thheller08:03:33

it may look like it does the same thing but the core.async channels are so powerful

thheller08:03:07

well forcing generators isn't any different?

jjl08:03:00

forcing generators doesn't require you to ship another whole library

thheller08:03:42

maybe once it supported everywhere ... until then you'd require the user to always use Closure even in development

jjl08:03:58

if they used that feature, yes

thheller08:03:15

like I said .. even if you put warning labels on things .. people will use it

jjl08:03:54

"if your project (or a dependency thereof) uses this feature, you need to add this to your compiler options"

jjl08:03:38

actually i think being able to tell closure what version of es to compile for would be nice

thheller08:03:50

you can already do that part

jjl08:03:59

oh there's an option for it?

thheller08:03:10

:language-in :language-out

jjl08:03:25

okay, so if the user has that and :optimizations :simple in dev, they would be able to use this feature with this patch and still run it on ie10

jjl08:03:59

so i suppose the next question is "how expensive is simple optimisation?"

thheller08:03:20

any optimization other than :none breaks live reloading

jjl08:03:27

is that an intractable problem?

thheller08:03:55

sort of .. with :simple or even :whitespace you just get one file

thheller08:03:05

so you always reload everything instead of just one file

thheller08:03:31

I'm sure that will cause a bunch of problems

jjl08:03:31

hrm. i wonder if we can make closure not do that

thheller08:03:47

well I suppose you could create a new compiler mode

thheller08:03:13

than would process every compiled CLJS file with closure

jjl08:03:25

in a 'do nothing except transpile' mode

thheller08:03:50

yeah, that is basically what the js-modules stuff does

thheller08:03:13

except processing other the .js not the generated js from .cljs of course

jjl08:03:38

okay. that seems like something i could probably do

thheller08:03:45

but FWIW I think it would be far more valuable to have everyone use core.async instead of adopting the many different async patterns there are in JS land

thheller08:03:05

YMMV of course

thheller08:03:54

but given that the JS world will still do its thing we have do adopt it anyways in some form

jjl08:03:10

this is my concern

thheller08:03:14

I don't know .. not my call to make

jjl08:03:15

i want to play with them

thheller08:03:42

you could probably do what you are doing in a library

jjl08:03:04

i definitely don't want cljs to get left behind new features because despite being so futuristic we stick to generating code that is N major versions behind

jjl08:03:20

i think that would be difficult

jjl08:03:35

(in fact i don't believe it's possible)

thheller08:03:17

you'd be surprised whats possible with a few with-redefs 😉

jjl08:03:38

correction; i don't believe it's possible without making me not want to use that library

thheller08:03:51

I have a completely different (ns ...) handling than the default CLJS in shadow-build

jjl08:03:01

what does yours do?

thheller08:03:07

stricter parsing, less side effects

thheller08:03:50

doesn't matter .. the end result is the same. Just an example of whats possible 😉

jjl08:03:49

sure, but i'm not feeling like maintaining a fork just to get features i can have in javascript

thheller08:03:02

not a fork, but yes everyone wanting to use that would need to use your hack

jjl08:03:19

or even maintaining a set of ugly hax

thheller08:03:23

so it is dirty 😉

thheller08:03:37

maybe you should try your patch in a fork

thheller08:03:52

and create some compelling examples why its a good idea to have generators

jjl08:03:34

my compelling reason is "we're gonna have es7 soon, why can't we have things javascript can have?"

jjl08:03:02

also my main alternative is node fibers and ewwwww

thheller08:03:03

well .. we have something better already ... that is supported everywhere

thheller08:03:40

will node rewrite everything to promises instead of callbacks?

jjl08:03:02

there are wrappers in js already. it'll take time for node to migrate all the libs

thheller08:03:43

so what is missing is a wrapper in CLJS to core.async? 😉

jjl08:03:12

i dunno, you seem pretty obsessed with only having one option to choose from

thheller08:03:47

have you used core.async? beyond the basics? I mean transducers in channels, alt!, etc?

jjl08:03:03

no, i've only done the basics. but it's totally overkill for what i need

thheller08:03:26

what do you need? other than what (<! something) gives you?

jjl08:03:14

pretty much that. i do not want to use core async.

rauh09:03:46

Personally, I'd love to see async/yield/await support in cljs. I primarily use Promises for async stuff.

thheller09:03:15

yeah might be useful. I don't know. I'm working with about 50/50 CLJ/CLJS and haven't used a single promise, so I'm obviously biased towards core.async.

Jon09:03:01

@dnolen https://github.com/clojure/clojurescript/blob/2171ae9859a2e982497764a04de10916aae68307/src/main/cljs/cljs/core.cljs#L1272-L1293 I got curious on this piece of code. I saw your comment like "TODO: we should remove this", what was the plan about that?

thheller10:03:40

@jjl on second though: you may only yield in generator functions right? that will be problematic with some constructs in CLJS as they introduce inner functions for scoping reasons

jjl10:03:08

this currently only applies to the method of a function (i.e. one arity)

jjl10:03:24

and yes, you will have to restrict yourself somewhat

jjl10:03:45

it is possible we could do some tracking but then it's not such a small patch

dnolen13:03:27

@jjl we need to step back, what actually problem is this solving for most users - why do they need a JS feature

dnolen13:03:44

any other discussion is completely secondary to that

dnolen13:03:04

no rationale, it’s not going to happen - “I want to use it for something I’m doing in Node.js” is not a rationale

mitchelkuijpers14:03:24

Hi I played around with the new js-modules support, pretty awesome stuff. But I seem to hit a bug when I add this library: https://github.com/styled-components/styled-components I would think this is probably an issue with the google-closure-compiler instead of the clojurescript compiler? I am trying to figure out where it's best to put this bugreport...

spinningtopsofdoom14:03:15

Where are you encountering the bug?

mitchelkuijpers14:03:25

I get the following warnings when compiling:

WARNING: JSC_JS_MODULE_LOAD_WARNING. Failed to load module "supports-color" at /home/mitchel/Development/styled-om-components/node_modules/styled-components/lib/vendor/postcss/css-syntax-error.js line 9 : 4
WARNING: JSC_JS_MODULE_LOAD_WARNING. Failed to load module "supports-color" at /home/mitchel/Development/styled-om-components/node_modules/styled-components/lib/vendor/postcss/css-syntax-error.js line 9 : 21

mitchelkuijpers14:03:43

And this pretty much seems to break the rest of the stuff that styled-components need

mitchelkuijpers14:03:22

And when I open it in the browser I get errors like this:

Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$container is not defined
    at at-rule.js:6
rule.js:4 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$container is not defined
    at rule.js:4
comment.js:5 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$node is not defined
    at comment.js:5
declaration.js:5 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$node is not defined
    at declaration.js:5
parser.js:9 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$root is not defined
    at parser.js:9
parse.js:5 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$input is not defined
    at parse.js:5
root.js:6 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$container is not defined
    at root.js:6
input.js:4 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$css_syntax_error is not defined
Which all seem to be a result of not being able to load supports-color. The first thing that I can think of is that google-closure does not use the browser field in package.json

spinningtopsofdoom14:03:24

You're using the new :npm-dpes compiler option right?

mitchelkuijpers14:03:39

And I am running from master

spinningtopsofdoom14:03:16

It looks like a failure running cljs.closure/node-inputs try requiring styled-components manually (see here https://clojurescript.org/guides/javascript-modules for guide)

spinningtopsofdoom14:03:08

You'll need to replace cljs.build.api/node-inputs with cljs.closure/node-inputs

spinningtopsofdoom14:03:56

node-inputs will process all your node module dependencies in foreign-libsto pass to ClojureScript

mitchelkuijpers14:03:24

This is necessary to see if this a clojurescript or closure bug?

spinningtopsofdoom14:03:57

Yep we want to see if the supports-color module is getting passed in when ClojureScript is importing node modules

mitchelkuijpers14:03:54

Sure I'll try it out do I need to follow the Node Modules Chapter?

spinningtopsofdoom14:03:14

You'll want to have this JavaScript file

var Styled = require('styled-components');

module.exports = {
    Styled: Styled
};

spinningtopsofdoom14:03:02

and then run this Clojure code

(require '[cljs.closure :as cc])
(require '[ :as io])

(def entry {:file (.getAbsolutePath (io/file "path/to/npm_stuff.js"))
                   :provides ["libs.npm-stuff"]
                    :module-type :commonjs}])

(def foreign-libs
  (into [entry] (cc/node-inputs [entry]))

spinningtopsofdoom14:03:43

Then check foreign-libs (it'll be a large vector of files to pass into ClojureScript) for the supports-color module

spinningtopsofdoom14:03:38

I've got to get to work I hope this helps

mitchelkuijpers14:03:00

Thank you I am trying it out and will report back

mitchelkuijpers14:03:31

That is weird it seems to do the correct thing:

{:file
  "/home/mitchel/Development/hello-cjs/node_modules/supports-color/browser.js",
  :module-type :commonjs,
  :provides ["supports-color"]}

mitchelkuijpers14:03:24

But when I try this:

(b/build
 (b/inputs "src")
 {:main 'hello-cjs.core
  :output-to "main.js"
  :output-dir "out"
  :externs ["process.js"]
  :foreign-libs foreign-libs
  :optimizations :none
  :closure-warnings {:non-standard-jsdoc :off
                     :global-this :off}})
It still gives the same warning I also checked the contents of "/home/mitchel/Development/hello-cjs/node_modules/supports-color/browser.js":
'use strict';
module.exports = false;

mitchelkuijpers14:03:38

Which seems fine to me

anmonteiro14:03:35

@mitchelkuijpers CLJS does respect the browser field

mitchelkuijpers14:03:15

Yeah I noticed ^^ @anmonteiro the output above proofs it

anmonteiro14:03:32

Is the problem requiring styled-components?

anmonteiro14:03:46

I'll try it out once I get to work

mitchelkuijpers14:03:58

The problem is that once I try to load it in the browser it wont load styled components because it cannot load that module and then everything fails

anmonteiro14:03:13

It's probably too soon to judge whether it's a Closure or CLJS bug

mitchelkuijpers14:03:47

Do you want me to push a minimal reproducible case?

anmonteiro14:03:48

We need to figure out why you're getting the warning in the first place

mitchelkuijpers14:03:33

btw I also put this in the compiler options:

:language-in :ecmascript5

mitchelkuijpers14:03:12

Then you will only get the 2 above warnings

anmonteiro14:03:50

@mitchelkuijpers what version of supports-color is that trying to require?

anmonteiro14:03:10

You can check it by going to your node_modules folder and inspecting the pckage.json

anmonteiro14:03:22

Hrm I may have a hunch, need to confirm in front of a computer

mitchelkuijpers15:03:47

Cool, if you need anything from me let me know

anmonteiro16:03:28

can you tell me the styled-components version?

anmonteiro16:03:47

@mitchelkuijpers so the problem seems to be with 'use strict’;

mitchelkuijpers16:03:33

Woa that's weird, was that your hunch?

anmonteiro16:03:18

hrm I might have spoken too early

anmonteiro16:03:27

I just realized I’m probably not running the right version of Closure

mitchelkuijpers16:03:38

Whoops, I have just tried it without use strict and it still breaks

anmonteiro17:03:22

@mitchelkuijpers can’t figure it out right now, and also can’t afford to spend any more time on it today

mitchelkuijpers17:03:44

No problem, thank you for trying @anmonteiro