Fork me on GitHub
#clojurescript
<
2016-07-12
>
eyelidlessness01:07:25

@dnolen: i understand we discussed the issue with bindings inside go, but i'm perplexed that CLJS-1705 was closed. the docs specifically say: > Creates new bindings for the (already-existing) vars, with the supplied initial values, executes the exprs in an implicit do, then re-establishes the bindings that existed before.

dnolen01:07:18

@eyelidlessness: where synchrony is implicit

dnolen01:07:28

CLJS-1705 is a non-issue

eyelidlessness01:07:45

those tests are all synchronous.

eyelidlessness01:07:58

and there's no documentation of the problems with asynchrony, nor any warning

dnolen01:07:03

it’s just a non-issue, sorry

eyelidlessness01:07:48

data corruption is a non-issue?

dnolen01:07:18

using binding incorrectly is the issue

dnolen01:07:35

"data corruption” has nothing to do with it

eyelidlessness01:07:38

shouldn't it be documented how to use it correctly?

eyelidlessness01:07:50

the data is corrupted. after the binding is closed, the vars are left bound

dnolen01:07:01

I already said I don’t have anything to add here

dnolen01:07:18

if you want to take it up - start a discussion in #C03S1KBA2

dnolen01:07:30

we just mimic the behavior in single-threaded environment

dnolen01:07:34

we just copy the docstrings

dnolen01:07:10

if it changes in Clojure then we can flow that into ClojureScript

eyelidlessness01:07:12

is this behavior present in clojure? clojure doesn't even provide the apis for a repro of that

dnolen01:07:34

Rich Hickey implement the binding macro

dnolen01:07:39

I assume he knows what he is doing

eyelidlessness01:07:54

but there is no clojure.test/async

dnolen01:07:05

that doesn’t have anything do with it all

eyelidlessness01:07:21

that is how the bug i posted was triggered

dnolen01:07:23

there are innumerable situations where this will happen

eyelidlessness01:07:31

the code is 100% synchronous

dnolen01:07:40

the issue has nothing to do with core.async or cljs.test

dnolen01:07:13

that’s just how cljs.test/async macro works

dnolen01:07:23

using the async macro for a synchronous test is meaningless

eyelidlessness01:07:23

is there any chance of documenting that?

eyelidlessness01:07:29

can i offer a documentation patch?

eyelidlessness01:07:48

i would like to be able to reliably find out why i'm "using it wrong" and i'm sure others would too

dnolen01:07:23

first explain to me how you think binding works, given what we’ve discussed

eyelidlessness01:07:42

> Creates new bindings for the (already-existing) vars, with the supplied initial values, executes the exprs in an implicit do, then re-establishes the bindings that existed before. The new bindings are made in parallel (unlike let); all init-exprs are evaluated before the vars are bound to their new values.

eyelidlessness01:07:27

oh you're asking for my proposed patch?

dnolen01:07:31

now imagine in the binding block you start a async thing which runs after binding block exits

eyelidlessness01:07:31

i'd have to sit down and think about it

dnolen01:07:43

now I’m trying to get you to understand binding

eyelidlessness01:07:51

i'm asking if documentation patches are accepted and whether one (if adequate) would be accepted for this

dnolen01:07:03

do you think the async code when it executes will see those bindings which are gone?

dnolen01:07:08

what about the docstring implies this at all?

eyelidlessness01:07:16

i understand the problem with async (even though literally nothing in my repro code is async!)

dnolen01:07:29

OK now you understand that

dnolen01:07:43

now what do you think the cljs.test/async macro does?

eyelidlessness01:07:53

will you hypothetically accept a patch?

niwinz06:07:27

I'm not clearly understand why so negative to accept patches just for improve the user experience. Some advice like "this function is not intended to work with asynchronous code" or " take care that using binding will cause unexpected behavior on use together with async code". Something that can help user avoid bad situations and spend hours of time searching a solution/problem...

niwinz06:07:56

It is not about understand binding, is just about a small advice that it should not be used in async code. This will improve a lot the user experience and changes nothing in implementation.

niwinz06:07:19

just my opinion 😉

vinodg06:07:49

i have written the externs for " https://apis.google.com/js/client.js" as var gapi = { "auth": { "authorize" : function () {} }, "client" : { "load" : function () {}, "people": { "people" : { "connections" : { "list" : function () { return {"execute" : function () {} }} }, "get" : function () { return {"execute" : function () {}} } } } } } it is not working, can any one help

dnolen11:07:04

@niwinz: you realize there’s countless cases like this, at some point you draw an arbitrary line. Also anybody who has been doing ClojureScript long enough realizes how many patches we’ve taken and continue to take to improve user experience. But some things just do not make the cut.

dnolen12:07:43

Still I already suggested that enhancing the binding docstring should probably happen in Clojure first if it’s going to happen at all. However this is all well trodden territory in Clojure and why stuff like bound-fn exists so I don’t see much movement there. Tweaking docstrings just for ClojureScript without a really strong reason just isn’t going to happen.

dnolen12:07:44

And adding a warning about cljs.test/async telling you not to write a sync test while at the same time using binding with the wrong expectations just doesn’t make sense.

novakboskov12:07:37

Is there any widely adopted way to handle Bootstrap modals in Reagent?

davin12:07:00

@novakboskov: might want to ask on the #C0620C0C8 channel, might get better traction

bhauman14:07:14

PSA: sharing an :output-dir between different clojurescript builds is a bad idea

scttnlsn14:07:43

(Getting a stack overflow when trying to compile CLJS)

bhauman14:07:55

circular dependency

bhauman14:07:27

a namespace that relies on itself transitively

scttnlsn14:07:35

OK, thanks, will hunt it down

scttnlsn14:07:02

@bhauman: Do you know that from past experience? Or am I missing something in the stack trace?

bhauman14:07:32

I know the topo-sort method sorts the namespaces

bhauman14:07:15

so it is a bit of an experience, insider thing, you may have discovered a bug but the most likely thing is that it's circular dependency

scttnlsn14:07:39

Found it. You were right

dnolen15:07:18

@scttnlsn: also sounds like you’re using an older version of CLJS - we don’t use the old topo-sort fn anymore (pretty sure)

bhauman17:07:58

Added knobs to Figwheel config validation, ie.`:warn-unknown-keys` or simply :ignore-unknown-keys And a new :validate-interactive (true, false, :fix, :start, :quit) to control the plugin validation loop behavior

blance19:07:32

anyone have any experience using :module-type to include amd/umd/commonjs modules?

blance19:07:01

I can only find 1 or 2 pages on cljs wiki and I don't quite understand how they work

blance19:07:40

If I simply put :module-type :amd or :commonjs for my libs, I got either ERROR: JSC_CONSTANT_REASSIGNED_VALUE_ERROR. constant module$node_modules$leaflet_pip$leaflet_pip_min assigned a value more than once.

blance19:07:00

and RROR: JSC_ES6_MODULE_LOAD_ERROR. Failed to load module "React" at node_modules/react-autosuggest/dist/standalone/autosuggest.min.js line 1 : 82 for another lib

blance19:07:24

I'm using reagent which uses cljsjs/react so not sure why it complains

dnolen19:07:58

@blance: how is reagent or cljsjs/react relevant here? (serious question)

blance19:07:28

the js library react-autosuggest has peer-dependency on react

blance19:07:41

which I believe can be supplied by cljsjs/react

dnolen19:07:07

hrm I am skeptical this can work

dnolen19:07:50

cljsjs/react is for ClojureScript use, not for some other JS dep that doesn’t access React via the global scope

blance19:07:49

so I would need to include js react myself to satisfy its peer-dependency?

dnolen19:07:02

(which is why I asked my question, doesn’t seem related at all to your :module-type question)

dnolen19:07:30

yes if you need to use something that needs to be built with React then no you can’t use cljsjs/react

blance19:07:38

but if that's the case, won't there be 2 copy of react included?

dnolen19:07:06

yep if you decide to also include cljsjs/react

blance19:07:13

what is the correct way to include react? I think include it as foreign-libs is the same thing as cljsjs/react does (accessing through global scope)

dnolen19:07:22

@blance you need separate what you are trying to do from what people normally do

dnolen19:07:58

many people do not bother with any 3rd party React stuff that requires building a custom foreign lib

dnolen19:07:17

they just write the widgets they need from scratch

dnolen19:07:31

so most people just use cljsjs/react and are done

dnolen19:07:49

however this isn’t what you want to do

dnolen19:07:09

you want to combine things which require custom builds of whatever react components you want + react

dnolen19:07:29

in that case you probably can’t use cljsjs/react

dnolen19:07:46

on top of that you will need to supply externs for all the libraries you are going to call into from your ClojureScript code

blance19:07:05

ok I feel like I got some idea on how to do that.

blance19:07:34

Any insight on the ERROR: JSC_CONSTANT_REASSIGNED_VALUE_ERROR? it seems like a closure compiler erro complains for constant reassignment

dnolen19:07:50

if you want to do that then no do not include the cljsjs/react dependency, just make it part of your build

blance19:07:59

but it's complain on the standalone js lib

blance19:07:04

ok got you

dnolen19:07:05

then report what happens then

dnolen19:07:17

right now you are talking about two completely different issues at the same time

dnolen19:07:22

making it impossible to offer any real guidance

blance19:07:36

you are right. let me solve the react thing first

dnolen19:07:50

@blance: I also would not bother with :module-type for this, just build a single foreign dep using whatever JS build tool you are using

dnolen19:07:27

JS build tool -> my_deps.js

dnolen19:07:35

this single file is your foreign dependency

dnolen19:07:48

you can crib cljsjs/react externs and add whatever else you need

blance19:07:46

great idea! why didn't I thought about that 😞

dnolen19:07:34

@blance it’s not obvious 🙂

dnolen20:07:01

huh it looks like Google Closure Compiler can compile to JavaScript https://github.com/google/closure-compiler/pull/1608

dnolen20:07:03

@mfikes: yeah you just need to mvn -DskipTests in a checkout of Closure

dnolen20:07:15

a GWT compiled Closure Compiler is one of the artifacts

dnolen20:07:16

so fully featured bootstrapped thing is probably possible - would need some more investigation

mfikes20:07:22

Maybe I’ll dig around in there and see what it involves. Interesting if it implies that you could do whole-program optimization of some sort in bootstrap ClojureScript. (Probably with a decent amount of work.)

mfikes20:07:00

Dang. We’ll have to update the bootstrap FAQ that says Closure is not available outside of the JVM 🙂

dnolen20:07:02

closure.cljc might be possible them - with GWT compiled Closure as a foreign lib require

rohit21:07:28

TL;DR - React’s findDOMNode() may be deprecated in a future release

blance21:07:43

@dnolen it works wonderfully. All I did was writing a JS file with import statement and set window.lib = lib for each lib I use. Then bundle them and use as one single foreign-lib

blance21:07:48

Thanks a lot!

dnolen22:07:56

@blance: glad to hear it!