Fork me on GitHub
#cljs-dev
<
2016-10-30
>
Yehonathan Sharvit11:10:56

@dnolen what do you think of an interruptible version of cljs.js/eval?

dnolen11:10:30

@viebel I don’t think anything about it yet

dnolen11:10:44

what problem is it solving?

Yehonathan Sharvit11:10:23

when you eval something that has an infinite loop in a bootstrap env like planck or klipse, you stuck the browser or the process

dnolen11:10:07

no, not interested

dnolen11:10:23

if you write a loop that’s what will happen

Yehonathan Sharvit11:10:40

yeah so my idea was to tweak the compiler so it emits guard() function calls to check how much time has elapsed

dnolen11:10:19

if you want fine grained control over evaluation write a ClojureScript intepreter

dnolen11:10:35

this kind of stuff will never make it into the compiler nor bootstrapped

Yehonathan Sharvit11:10:18

@mfikes seemed interested by such a feature of the compiler when we discussed it yesterday

dnolen11:10:48

there's no reason for ClojureScript to handle this

dnolen11:10:59

nothing is stopping you from writing your own eval if you want

Yehonathan Sharvit11:10:11

this is what I did + I had to override cljs.compiler/emits

Yehonathan Sharvit11:10:22

and use with-redefs

dnolen11:10:32

ok, but I’m not interested 🙂

dnolen11:10:44

but that shouldn’t stop you!

dnolen11:10:58

this kind of thing is cool for custom projects, tooling

dnolen11:10:09

just not what we ship as core

anmonteiro11:10:13

it's a first attempt at data-readers (no self-host support yet)

dnolen11:10:52

@anmonteiro seems ok, but missing collecting those files? (or did we already do that?)

anmonteiro11:10:15

@dnolen right I was thinking about that too, but Clojure does that for us already

anmonteiro11:10:45

so they're in *data-readers* already

anmonteiro11:10:23

the only problem is that it includes the ones coming from data_readers.clj and data_readers.cljc, and we might want only the ones coming from the latter

anmonteiro11:10:52

in case that it's OK to allow support for data_readers.clj, I think we'd only need to worry about loading those files in a self-host context where there's no Clojure involved

anmonteiro11:10:56

those were the questions that arose when I was trying to make it work yesterday, which is why I wanted to run it by you before cleaning it up in a patch

dnolen11:10:23

hrm I don’t think this will be good enough

dnolen11:10:29

Clojure looks for .cljc now

dnolen11:10:52

ok this is good enough for compile time

dnolen11:10:57

but not good enough for runtime

dnolen11:10:27

we need to include these files into the ClojureScript build so runtime reading works

anmonteiro11:10:48

oh.. like cljs.reader stuff?

dnolen12:10:01

otherwise you’re not winning much here 🙂

anmonteiro12:10:07

right, that's what I was missing, doh!

dnolen12:10:08

you want reading to be the same in both places

anmonteiro12:10:37

yeah, that's going to be much trickier

anmonteiro12:10:14

@dnolen so in practice we need to explicitly look for data_readers.cljc when finding CLJS sources, right?

dnolen12:10:34

(unrelated side note)

dnolen12:10:51

I’m playing around with ES6 stuff, seems like watching and recompiling ES6 sources just works

dnolen12:10:01

which is pretty awesome

dnolen12:10:14

@juhoteperi I think we get this Node.js resolution stuff working

dnolen12:10:24

dealing with JS from a dev perspective would be really sweet

dnolen12:10:40

would definitely deliver on the what we discussed at EuroClojure

dnolen12:10:55

(advanced compilation stuff aside)

anmonteiro12:10:01

yeah, just need that option for custom transforms of .js files

dnolen12:10:04

if you need to create both JS and ClojureScript together this rocks

dnolen12:10:14

@anmonteiro I think we should nix that idea now

dnolen12:10:23

let’s just get it right

dnolen12:10:51

so devs can require whatever deps they want w/o obtuse explanations

anmonteiro12:10:20

hrm, but wouldn't that mean they'd need to transform their (e.g. JSX) code with an external tool before feeding it to ClojureScript?

dnolen12:10:39

I took Maria’s example of ES6 lib with JSX

dnolen12:10:41

just works

anmonteiro12:10:05

oh that's awesome

dnolen12:10:08

meaning we already have things in place

dnolen12:10:22

my half-baked idea was about people writing Google Closure modules + JSX

dnolen12:10:26

but the more I think about it

dnolen12:10:34

ES6 + JSX is just a way stronger marketing story

dnolen12:10:59

but from what I can tell

dnolen12:10:13

ES6/JSX + Node.js NPM modules + Figwheel is going to be pretty rad

anmonteiro12:10:34

@dnolen AFAICT, that means React needs to be properly consumed by Google Closure for us to deliver on that

anmonteiro12:10:45

which I'm not sure is the case

dnolen12:10:55

@anmonteiro you just need externs

dnolen12:10:10

externs affect things in the build

dnolen12:10:11

including the thing you externed

juhoteperi12:10:28

@dnolen I tested it and if I feed all deps of React to Closure, it will give something like 100 parse errors

anmonteiro12:10:29

I hope that's true, but I think it might be a bit more complicated than that

juhoteperi12:10:48

and that only when I skip core-js dep which causes NPE

dnolen12:10:54

right I’m suggested decomplecting the goals here 🙂

dnolen12:10:01

feeding all of React into Closure is nice to have

dnolen12:10:05

but not that important

juhoteperi12:10:19

Probably Closure people will anyways work on this once they have the basics working

dnolen12:10:33

however we have a cool story for greenfield ES6 code in your project

dnolen12:10:43

just don’t do silly metaprogramming stuff

dnolen12:10:50

and you get DCE & code splitting for free

dnolen12:10:56

and live coding via Figwheel

juhoteperi12:10:40

object-assign is one of deps of React, and using that alone works

juhoteperi12:10:53

Cljs ns uses the deps.cljs provides to resolve object-assign require

dnolen12:10:18

yeah I saw that briefly in the backlog the other day

juhoteperi12:10:44

No changes necessary to Cljs compiler, just need to pass list of all files in node_modules as foreign-libs

juhoteperi12:10:20

Though we will probably want to change the path the processed modules are written in output-dir

juhoteperi12:10:35

Currently they use foreign-lib logic and and written to root of output-dir

juhoteperi12:10:43

What will probably cause conflicts

dnolen12:10:59

yeah so patch to fix that behavior is probably a good idea

dnolen12:10:17

@anmonteiro I though you made a ticket for this ^?

anmonteiro12:10:34

I did indeed, let me dig it

juhoteperi12:10:44

Probably enough to add :closure-lib true to ijs map when processing modules

juhoteperi12:10:28

Maybe there are two problems

juhoteperi12:10:46

Handling the regular foreign-libs, and those using module processing

juhoteperi12:10:54

Because processed modules become Closure modules

dnolen12:10:15

yes - we need these to be distinct

dnolen12:10:25

:module-type tells us though

mfikes12:10:05

@viebel JavaScript engines are probably the appropriate place for interruptibility. JavaScriptCore ticket 24478 also leads to same for SpiderMonkey and V8.

Yehonathan Sharvit12:10:19

@mfikes do u have link to the JavaScriptCore ticket?

Yehonathan Sharvit12:10:52

@dnolen another thing - did u have time to take a look at my port of core.match to bootstrapped cljs - http://dev.clojure.org/jira/browse/MATCH-116 ?

dnolen12:10:49

Haven't had time and probably won't till Friday.

dnolen15:10:32

wip demo to see if Figwheel just works with ES6 support

dnolen15:10:51

@bhauman ^ I can’t get Figwheel to reload my ES6 file even though it knows it changed

dnolen15:10:10

I believe it thinks ns wasn’t required or something probably because Figwheel probably doesn’t understand these kinds of deps yet

bhauman15:10:28

@dnolen: good to know. I'll take a look.

dnolen15:10:41

@bhauman: thanks I think this will make for a pretty cool demo :)

bhauman15:10:05

Absolutely...

bhauman16:10:26

@dnolen is this running on cljs edge?

bhauman16:10:53

or will a recent release work for this?

anmonteiro16:10:09

@bhauman it needs current ClojureScript master

anmonteiro16:10:32

@bhauman ./script/bootstrap and ./script/build to install locally but I have a hunch you already know that 😉

bhauman16:10:06

yep 🙂 but its been a while so I appreciate the refresher thanks!

bhauman16:10:03

@anmonteiro actually whats the easiest way to get to a java command with the maven workflow in this demo repo? I always use lein.

dnolen17:10:05

@bhauman sorry I should have added instructions

dnolen17:10:07

done & pushed

bhauman17:10:37

its a fair assumption that I would know that already

dnolen17:10:41

I poked around a bit, it doesn’t work because Figwheel doesn’t know the name that the ES6 module will be given

dnolen17:10:04

so provided? in file-reloading ns returns false

dnolen17:10:39

in general it’s going to be quite brittle to assume anything about the names of these processed JS files

dnolen17:10:21

I think you should probably be mapping URL to the provided name

dnolen17:10:27

and ignore all this ns stuff

dnolen17:10:24

that is treat the Goog dep index as source of truth - and don’t try to add any cleverness here

dnolen17:10:00

if you were looking at goog.dependencies.requires_ then this would just work

dnolen17:10:06

that maps URL to the module name

dnolen17:10:06

ok I tried to monkeypatch provides? over here but it doesn’t work

dnolen17:10:23

since other stuff seems to be relying on the ns name instead of the URL to resolve what to load

dnolen17:10:03

@bhauman so the really cool thing here is that we’ll have better hot loading of React than anything in JavaScript 🙂

dnolen17:10:22

since we don’t wrap in closures - the namespaces get compiled into Closure namespaces

bhauman17:10:24

struggling to get my dev workflow going, what version of google.closure should I be seeing?

bhauman17:10:09

I'm seeing : WARNING: Unsupported preprocess value :jsx for foreign library src/js/Components.js. ERROR: JSC_PARSE_ERROR. Parse error. primary expression expected at src/js/Components.js line 14 : 7

dnolen17:10:58

@bhauman what version of ClojureScript did you build?

dnolen17:10:11

I’m assuming you’re trying to use the script/figwheel.clj I provided?

bhauman17:10:39

yeah that worked for sure, I'm just trying to bring up my full interactive workflow

bhauman17:10:46

through lein

dnolen17:10:02

not sure if that will be worth the trouble

dnolen17:10:21

you cannot use AOTed ClojureScript stuff with Lein - I never got that to work

bhauman17:10:44

this requires AOTed ClojureScript?

dnolen17:10:01

but if you’re trying to copy that stuff from the pom.xml

dnolen17:10:03

won’t work

bhauman17:10:12

not the problem

dnolen17:10:29

so you cannot just use a project.clj for this

dnolen17:10:38

my figwheel script requires hooking into the compiler

bhauman17:10:06

oh shit thanks

dnolen17:10:14

js-transforms multimethod from cljs.closure

bhauman17:10:16

sorry I missed that

bhauman17:10:23

no problem I got it now

bhauman17:10:03

well now I'm VERY excited!!!

dnolen17:10:14

this is about live coding JSX + ES6

bhauman17:10:30

it's a slow sunday morning for me and getting the cobwebs out of my way has been difficult

dnolen17:10:42

I also think we can do some sick interop demos between CLJS / React this way

dnolen17:10:00

since all our data structures are ES6 interface compliant

dnolen17:10:11

definitely makes me wish ES6 Map-like worked for props 😛

bhauman17:10:58

Hopefully I won't have to change my namespace identity assumptions though.... It made things sooo much easier when I switched to namespaces and away from urls... relative urls hurt in so many ways especially before :main

dnolen17:10:40

@bhauman the problem is you cannot know what the name is going to be

dnolen17:10:48

so I don’t know how you will work around that

dnolen17:10:33

however much trouble they are, I don’t see why you cannot canonicalize

dnolen17:10:35

and go from that

bhauman17:10:19

It's the simple fact that the client knows the http root and the server doesn't

bhauman17:10:54

but before we get into that let me actually take a look

dnolen17:10:12

ok, I’m just discouraging doing anything that depends on ClojureScript compiler stuff to figure this out

dnolen17:10:22

there’s too many interactions here between ClojureScript & Google Closure

dnolen17:10:33

writing any code that depends on what we do is destined for disaster

bhauman17:10:35

message received 😉

bhauman17:10:01

I'm sure I can make this work in a reasonable way

dnolen17:10:04

ok cool, just note that this isn't really about ES6 or anything - that’s just a nice example

dnolen17:10:42

AMD, CommonJS, Node.js - and how the real module names get constructed can’t necessarily be expected to be consistent

bhauman17:10:01

yeah its about flexibility

bhauman17:10:27

tremendous flexibility

dnolen17:10:35

well the real problem with JS is we can’t rely on the classpath to simplify the problem

dnolen17:10:02

so there’s no straightforward translation from namespace on disk to the namespace you see in JS environment

dnolen17:10:16

since ES6, Node.js, etc. are incompatible resolution mechanisms

bhauman17:10:50

this is all very helpful information, I haven't been following this so I really appreciate it

dnolen17:10:31

far as I know ES6 is not relative - Node.js is

dnolen17:10:06

hrm I guess that’s the issue is ES6 supports custom resolution algorithms, and Node.js works a specific way

dnolen21:10:44

@juhoteperi sorry maybe I missed this about your solution for NPM, does that involve creating custom packages for each thing on npm?

dnolen21:10:41

@juhoteperi did you look at the Closure changeset? Does it look like it wouldn’t work for some reason?

bhauman23:10:06

@dnolen I see a way forward 🙂 I have a busy week so ... probably won't have a proof of concept until the end of the week

bhauman23:10:45

this is exciting

bhauman23:10:37

actually, as is usual with added constraints, this could lead to a big improvement/simplification of how figwheel operates