Fork me on GitHub
#clojurescript
<
2017-03-18
>
Jon01:03:29

Is there any way to split bundles in ClojureScript? I mean bundle the cljs core library part in one file, and others in another?

dpurrington15:03:44

@johanatan not sure if I’m on state of the art, but I have gotten to a functional state

dpurrington15:03:27

using cljsbuild and doo

dnolen15:03:48

@jiyinyiyong ClojureScript has code splitting via Closure but it involves code motion, so there’s no way to really ensure that some “bundle” is just one namespace or anything

dpurrington15:03:31

I have what I think is a pretty basic question, which is getting the same effect as JSON.stringify in cljs. So far, I’ve tried not using it at all (and just (.log js/console obj)) using JSON.stringify (.log js/console (.stringify js/JSON obj) and (.log js/console (with-out-str (cljs.pprint/pprint obj)))

dpurrington15:03:28

the first printed a lot of extra stuff that told me I needed to stringify, the second was not really any better, and the third doesn’t resolve to an actual fn

dpurrington15:03:52

I think either I need a require, or to address it some other way.

dpurrington15:03:05

I tried removing the namespace and it wasn’t any better

dpurrington15:03:49

If I’m using this (http://cljs.github.io/api/cljs.pprint/) do I need to require the ns?

dnolen15:03:56

@dpurrington you always need to require any ns you want to use

dnolen15:03:02

the equivalent of JSON.stringify would be pr-str

dnolen15:03:18

js isn’t really a namespace so much as it is the ambient global scope

dpurrington15:03:46

it kinda looks like one in the fn references

dnolen15:03:47

(js/console.log (pr-str {:text “Hello!”}))

dnolen15:03:04

or println instead of js/console.log

dpurrington15:03:20

I don’t have to do (.log js/console x)?

dnolen15:03:53

either works, generally you should prefer yours, but the other way works for convenience

dpurrington15:03:04

apparently, cljs is moving so fast SO can’t keep up

dnolen15:03:41

heh, @dpurrington in this case this behavior has been around for 5 years

dpurrington15:03:34

right on. That gave me exactly what I was looking for.

baptiste-from-paris15:03:12

@dnolen , I am looking at Clojurescript git history, trying to understand the compiler, I saw that you started to work on it around late 2011 - can you share how did you were able to get into the project (technically)

dpurrington15:03:24

should I concern myself with cljs jvm vs js?

dpurrington15:03:29

regarding the note on [this topic] (http://cljs.github.io/api/cljs.core/): "We are currently only listing the "ClojureScript JVM" implementations here. The "ClojureScript JS" macro implementations are not listed here, but their API is identical of course."

dnolen15:03:22

@baptiste-from-paris I just sent some patches

dnolen15:03:08

dev activity wasn’t super intense in late 2011 so I got commit rights and I supplied more patches and made sure other people’s patches also made it through - that was it

dnolen15:03:59

having a lot of JS expertise also meant that I was well positioned to do a lot of the early runtime optimization work

baptiste-from-paris15:03:25

yes but I guess you had somehow to understand everything - parsing, emiting code

baptiste-from-paris15:03:58

maybe before submitting you first few patches

dnolen15:03:11

not really

dnolen15:03:24

the ClojureScript compiler is still simple

dnolen15:03:38

back then the analyzer and compiler together were ~1000 lines of code

baptiste-from-paris15:03:44

Yes, I am looking at the First commit ! really instructive

baptiste-from-paris15:03:30

So if I want to understand internals now that codebase is quite big, should I go back at the beginning of the project to simplify things

dnolen15:03:31

it’s one of the simplest compiler you could work on - I think other contributors in #cljs-dev can mostly confirm that 🙂

dnolen15:03:53

@baptiste-from-paris you can or just find a bug in JIRA that you want to fix and learn that way

johanatan17:03:10

@dpurrington ya I gave doo another try and it seems to be working fine now

dpurrington17:03:42

let me know if you see a way to get more verbose errors from cljs.test

dpurrington17:03:03

b/c I have an invocation throwing an exception in a test

dpurrington17:03:11

just a one-line typeerror

johanatan17:03:14

@dpurrington 👍:skin-tone-2:will do

dpurrington17:03:45

huh. So “can’t find x of undefined” is a null reference issue. And I got the stack trace by explicitly doing a (try…). I was missing a parameter in my fn call, which doesn’t get detected in cljs.

dpurrington17:03:44

(I read that earlier today, no arity validation in cljs)

jjl17:03:24

am i correct in understanding that currently there is no way to use async/await in cljs? node currently has the capability to run them, so i'm interested

thosmos18:03:35

@anmonteiro re: :npm-deps {:faunadb "1.0.0"} that had errors due to reserved words (https://clojurians.slack.com/archives/C03S1L9DN/p1489791634538694) I tried fixing the code in the local node_modules/faundb folder, but when I ran the build again, it overwrote my changes. Is this cljs or closure handling this piece? Is there a way to pin it or use a local source?

anmonteiro18:03:28

@thosmos for now the solution would be to call cljs.closure/index-node-modules and pass its result to foreign libs

thosmos18:03:06

ok thanks, will look into that

thosmos19:03:06

@anmonteiro found a small one-liner bug in that function ...

thosmos19:03:27

should I do a JIRA or just paste it

anmonteiro19:03:55

can you tell me what you think the bug is first?

thosmos19:03:35

when called without opts it loops many times

anmonteiro19:03:57

if you have signed the CA, you can make a ticket + patch

anmonteiro19:03:05

definitely a bug 🙂

thosmos19:03:11

i have signed it

thosmos19:03:21

ok cool, my first patch 🙂

thosmos20:03:06

cljs.closure/index-node-modules worked quite well. it got through the build and now the browser is complaining about a handful of requires that got skipped. for example: var request$$module$$Users$thomas$Develop$cljs$rimdb$fauna_module$node_modules$faunadb$src$Client=require("superagent");

thosmos20:03:11

but it looks like that is a problem with closure-compiler: https://www.refheap.com/133297

anmonteiro20:03:17

@thosmos just looks like the foreign libs array doesn't have those modules listed

thosmos20:03:05

oh got it, they need to be added manually

anmonteiro20:03:53

they shouldn't hrm

hlolli20:03:11

some differences between cljs and clj

user=> (>= 1 nil)
NullPointerException   clojure.lang.Numbers.ops (Numbers.java:1013)
cljs.user=> (>= 1 nil)
true
watch out 🙂

hlolli20:03:16

actually I like this that cljs treats nil here as 0

thosmos20:03:21

@anmonteiro if I print out what index-node-modules generates, those are actually already in there: {:file /Users/thomas/Develop/cljs/rimdb/fauna-module/node_modules/superagent/lib/client.js, :module-type :commonjs, :provides [superagent]}

thheller20:03:36

@hlolli thats javascript for you 😉

anmonteiro20:03:38

so that makes sense

anmonteiro20:03:57

@thosmos does it also list their package.json files?

thosmos21:03:24

for this one yes: {:file /Users/thomas/Develop/cljs/rimdb/fauna-module/node_modules/superagent/package.json, :module-type :commonjs}

thosmos21:03:08

is it possibly an ordering thing?

anmonteiro21:03:46

I don't think order matters

thosmos21:03:55

is there a way to get more detailed info out of the closure-compiler?

anmonteiro21:03:25

@thosmos can you put together a minimal example I can try locally?

anmonteiro21:03:40

you can check in the node_modules folder too, since you're making changes to some modules

thosmos21:03:11

yes will do

jjl06:03:55

promesa is not ES7 async/await

dpurrington17:03:39

ok, then I don’t understand the question. Sorry

anmonteiro21:03:58

@thosmos so I had a look at your example

anmonteiro22:03:18

1. I don't think that faunadb module is supposed to work in the browser

thosmos22:03:43

it's supposed to ..., but that doesn't mean it actually does ...

thosmos22:03:02

it seems like they've put minimal attention into making sure it does at this point

anmonteiro22:03:27

because it tries to require('util')

anmonteiro22:03:32

that's a Node.js internal module

anmonteiro22:03:55

switched to :target :nodejs and made some progress

anmonteiro22:03:04

that led me to find another bug in ClojureScript 🙂

thosmos22:03:09

oh good 🙂

anmonteiro22:03:31

now it compiles fine, but there seems to be a problem with a dependency called qs

thosmos22:03:05

ok, switched to :target :nodejs and I'm still getting failed module loads on the same packages. is this related to the other bug?

anmonteiro22:03:02

@thosmos yes, see CLJS-1985

thosmos22:03:27

@anmonteiro added your patch and still getting those module load errors. Are you possibly using a patched version of closure-compiler, such as with the PR patch you referenced earlier?

anmonteiro22:03:47

I was using Closure Compiler from master

anmonteiro22:03:56

@thosmos note that some warnings are expected

anmonteiro22:03:20

the expected warnings should refer to Node.js internal modules

jennifer22:03:25

ooooh. i’ll try that!

thosmos22:03:01

@anmonteiro I'm still getting the same errors on the external modules and when I run node main.js it biffs it on the first require: https://www.refheap.com/133303

thosmos22:03:28

I'm also using closure-compiler master

anmonteiro22:03:05

@thosmos oh hrm, you need to pass :target :nodejs in the opts to index-node-modules

thosmos22:03:21

right makes sense

shaun-mahood22:03:35

@jennifer: Reading your code snippet, I don’t think I’m clear on what part isn’t working - is the backend handler working but just never receiving the text you are sending?

jennifer23:03:29

yup. backend is working but not receiving the text. exactly.

jennifer23:03:16

backend updates the atom i have stored there (this is just a basic todo app) and returns the updated atom, which has incremented properly, but doesn’t contain the new text.

jennifer23:03:53

and i’ve tested the backend with sample data in the repl and that function works as expected.

jennifer23:03:27

so i’m pretty confident that it’s just something here not passing to the backend correctly.

shaun-mahood23:03:37

Looking at some of my existing code, it looks like all I’ve done is

(POST
      {:params        data
       :keywords?     true
       :handler       (fn …)})
but I remember having some trouble getting it working at the beginning - you could try adding :response-format :json (assuming your backend is expecting json) as well, that’s given me trouble with some backends.

shaun-mahood23:03:21

@jennifer: ^ and if you’re sending just a string the keywords? part shouldn’t matter I don’t think.

jennifer23:03:46

hmm. okay. my backend is expecting a stringified atom. i wonder if i’m sending over the wrong stringified thing. thanks for the feedback!

shaun-mahood23:03:24

@jennifer: You should be able to print out the entire ajax map from the server side - I think Chrome devtools can show it all, but I think I’ve also had things when troubleshooting that didn’t seem to show up there due to problems with the format or things. Good luck getting it to work!

jennifer23:03:59

thanks! i think i might be onto why it’s not working. but been at this for a while. gonna rest my eyes and try again later. cheers!

thosmos23:03:32

@anmonteiro: Now I'm only getting the internal node module load errors like you mentioned, but also a java.lang.IllegalStateException: Cannot build without root node being specified https://www.refheap.com/133306

anmonteiro23:03:06

@thosmos use :language-in :es5 in your compiler options

thosmos23:03:11

@jennifer if it's expecting an atom than what I suggested above is wrong, and you might just try sending the text-atom without the @

thosmos23:03:37

@anmonteiro ah yes, it built! The qs problem I think has something to with this module load error: WARNING: JSC_JS_MODULE_LOAD_WARNING. Failed to load module "./lib/" at .../node_modules/qs/index.js line 1 : 17

anmonteiro23:03:50

yeah, that's what I got

anmonteiro23:03:20

@thosmos so here's the problem

anmonteiro23:03:30

superagent is a dependency of faunadb

anmonteiro23:03:50

and faunadb is using a super old version of superagent

anmonteiro23:03:23

which in turn has a super old version of qs as a dep

anmonteiro23:03:44

I suspect qs does some weird dynamic require magic that Closure Compiler can't understand

thosmos23:03:50

this fixed the qs thing for me: module.exports = require('./lib/index');

anmonteiro23:03:11

if you use qs v6 it also works

anmonteiro23:03:31

or upgrading superagent or something

thosmos23:03:49

closure doesn't turn /lib/ into /lib/index.js

thosmos23:03:00

yeah, makes sense about the dep versions too

anmonteiro23:03:40

so that's probably a Closure bug

anmonteiro23:03:45

you should report it upstream

thosmos23:03:31

ok will do, looks like it also happens here: Failed to load module "string_decoder/"

thosmos23:03:26

@anmonteiro gotta run, it's been fun bug hunting with you

thosmos23:03:10

in the future should I post this kind of thing in #cljs-dev ?

qqq23:03:36

(defn foo [x y z]
  (let [bar (long computation that does NOT dependon x y z and can be cached)]
    ...))
in the above case, the bar has to be evaled eveyr time, because clj has no idea whetehr there are side effects right? so if I want to 'cache it', I'd ahve to do something like
(let [bar .... ]
  (defn foo [x y z] ...))
?

thosmos23:03:06

@anmonteiro should I include anything for compiler flags/options, as they request?

anmonteiro23:03:06

as detailed as possible

noisesmith23:03:07

qqq that's one option, another is to put bar in a def, or make a memoization of the function called to calculate bar, and use that in foo