@dnolen: The possibility of using Closure as a bundler for React Native is mentioned in Markbåge commit :) crossing fingers https://twitter.com/sebmarkbage/status/674392365260341248

@mfikes: yay!

Is there a way to “require” local edn data file? In node/js, I’d require() a .json file. I’ve got some largish data, and I could put it in just a normal .cljs file, but I was wondering if there’s a way to get it from a separate file (so it doesn’t clutter up the code)

@jaredly: if the file is large you want to use transit

If you just want it in an edn file for organizational purposes you could use a macro to read the file at compile time and basically in-line it into your cljs file

and if it’s transit, it’s just JSON

and you can use all the old tricks

@noonian: yeah! that’s exactly what I want

right, that’s other approach

yeah I should have specified - this is web target, not node

hi clojurescript folk! i ran into an issue with om next, datascript, and react native in how it handled rerenders from the root. might be a larger cljs/react native integration to be aware of. heres a gist of a reproduction and the reconciler implementation i made that (seems) to address it

https://gist.github.com/jobez/9ea1963b2b07454a28a6

also have some gifs of the bug in comments in the gist

HACKON

@johannjohann: you’ll want to ask your question in the #C06DT2YSY and #C0E1SN0NM channels

Hi people!

We’re running into a silly issue: how do we detect if js/window exists without running into reference erros?

errors

for instance, on node runtime

@joost-diepenmaat: exists?

so (exists? js/window) ?

it’s a macro that compiles to the typeof x == “undefined" JS pattern

ok thanks that looks like what we need

thanks!

Any idea why advanced optimization breaks "line" property access? ("cursor" is ok).

@deas check the externs file

I don’t see anything about line property anywhere

if advanced optimization + externs isn’t working the answer is nearly always, "the externs file is not complete"

@dnolen: The compiler does not take line:204 (@return {{line:number, ch:number}}) into account?

@deas that's just type checking information

nothing to do with renaming

@dnolen: Ok, and (.. cursor -ch) works because it is just two letters?

maybe, but doesn’t matter really - you’re just getting lucky

that externs file is just incomplete

getCursor should probably be given a a type (even if fabricated) and that type should appear in the externs file with its properties

@dnolen (aget cm "line") is the workaround I came up with, but I really wanted to figure out whats going wrong. Thanks!

@deas aget for Object access is discouraged, use goog.object helpers

@dnolen Thanks. I guess I just go and try "fixing" the externs file first. 😉

that’s what I would recommend

people are irrationally scared of externs files but they are very, very simple

I understand the people.

really they are no different from TypeScript typing files and they give you more control over the final artifact

Annotating JavaScript for the Closure Compiler https://developers.google.com/closure/compiler/docs/js-for-compiler?hl=en

should probably be in everyone bookmarks

@dnolen Actually been there before. Did mistakenly expect that property names are taken into account for @return.

did any of the NYTimes demos use Clojurescript?

@ghadi: ? what are you referring to?

just wondering if you ever posted cljs on the nytimes properties, and I was looking for a cool example

ah no, never used ClojureScript on anything at while I was at NYT

That's what I thought. Was there a technical barrier?

not really, just that nobody knew Clojure or ClojureScript

that’s a huge problem on newsroom deadlines

ive been sneaking in things like ramda and mori at work — an inch at a time 😉

ramda is great fun , but doesn't handle nils like I'd expect because it's written by a bunch of haskellers.

we've been using it for over a year

notably, isEmpty on null is false.

interesting

@ghadi I did use Clojure for some offline things, but nobody cares about that stuff. We even used Haskell for offline stuff.

we're thinking about moving our JS code over to Mori from immutable.js b/c wedging in Om.Next looks realistic. thanks @dnolen

cool!

seems a better target than relay or falcor, because we (I) don't care about node.js at all, and I do care about clojure.

and we want time-travel

but we're using redux as an intermediate step.

haha same here

redux-wise

there's still half of an ember codebase in there...

scary 😉

Does anyone know how I can install leiningen "dev-dependencies" packages?

Here's what I have:

:dev-dependencies [[speclj "3.3.1"] [lein-phantomjs "0.1.0"]]

As far as I can tell, that's the canonical way to add those deps, but neither of them were automatically installed.

Here's my regular deps:

:dependencies [[org.clojure/clojure "1.7.0"] [org.clojure/clojurescript "1.7.170"] [org.clojure/core.async "0.2.374"] [reagent "0.5.0"]]

@tompurl: use :profiles {:dev { :dependencies [] }})

@cab Thanks a bunch, that worked!

If you also write Clojure, do you tend to restrict your Clojure ns forms to the constraints of ClojureScript (avoiding prefix lists, etc.)? Just curious if that’s common practice.

@mfikes: No every few months I forget CLJS doesn't support the prefix list syntax actually and stare at the error output for a while before remembering...

When dealing with long namespaces (> 5 segments), like in com.acme.project.subproject.app.frontend.views.* I really miss that actually

I’ve never used prefix lists not even once

but I have seen that they are quite popular, still nothing will convince me of adding any of that stuff to ClojureScript

the only one missing thing I’m interested in is :rename

Anyone have any experience running figwheel inside of Docker? I've been trying to figure it out for a bit, and I'm not having a ton of luck.

sdroadie: I run the CLJS stack inside of Docker, not specifically figwheel, but I can probably help

@pandeiro: Sweet. We're deploying our app with Docker, and I'm just trying to get our dev environment as close as possible to production.

@pandeiro: For production, we're shipping an uberjar, but for dev, we're using Figwheel because hot swapping is pretty rad.

@pandeiro: Though honestly, I feel like Docker might be more my point of difficulty as I'm thinking about. Ideally, I could statically assign an IP to my container, set that to the :websocket-port for Figwheel, and be on my way.

@pandeiro: Not sure if that is possible.

@sdroadie: You have two options basically -- exposing ports between the container and the host, or changing the --net parameter to 'host' to simply run the container on the host's network stack

The former is more 'correct' and 'the Docker way', but can be impossible if containers have bi-directional links

The latter is quick and dirty and 'just works', until you need to do things right

This is just for dev purposes. Quick and dirty will work, I think.

For production, we have a .jar running in one container, and postgres in another. Simple, easy to set up, no issues.

So just run the docker container with your Clojure stack with --net="host"

you can do that easily whether using docker alone or docker-compose

Cool. I'm using docker-compose.

The only thing I'm not sure about is if you're using OS X, b/c then you're actually using Docker and VirtualBox, and there are issues with the latter regarding volume mounting that my team and I have never been able to sort out properly 😕

I'm running on Ubuntu.

Then you should be fine

Rad. Thanks for your help.

Sure

Virtualbox is teh suck. I've always been having some problems with it. I also have a Clojure setup working inside docker. I on the other hand bind exposed ports to host ports and it's working well.

@jaen: yeah binding works fine; what doesn't work is mounting volumes from hosts in OS X to Docker through VirtualBox, especially when there are symlinks anywhere in them

@sdroadie: did you created a shared/shareable Dockerfile for CLJS by any chance?

(which is essential for the figwheel/boot-reload workflow)

@richiardiandrea: I have one -- https://hub.docker.com/r/pandeiro/lein/

@richiardiandrea: I haven't, sorry. I only have the Dockerfile for prod, which just grabs a jar file, exposes a port, etc.

or for boot: https://hub.docker.com/r/pandeiro/boot/

@pandeiro: yeah; I tried to get my setup running on a Windows machine (main reason I did a docker setup, so that Windows people in the university project could have an easier time working on that) and it failed miserably '

@pandeiro: tnx! @sdroadie: no worries man, now we have it 😄

You should be able to use either as-is, just mount your clj/cljs app to /app

@pandeiro: cool stuff

@jaen: had the same experience too, visions of "run everywhere" including our product people's Windows machines... sadly, no 😞

I guess it might have worked better with VMware, but that's non-free, soo...

@jaen: Not sure if you've tried recently, but I've found it pretty easy developing cljs on Windows now - way, way easier than a year ago.

Might be feasible to get rid of docker if it was just for ease of setup

Possibly, though I hoped I wouldn't have to hand hold people through that, just tell them to install docker and call it a day.

that's the dream yeah...

They all didn't see anything apart from Visual Studio, sooo...

not sure what the status of Boot's Windows support is, too...

I'm at least luck one girl has Mint, so that's one less person for me to hand hold : V

I remember a friend trying it on his tablet PC once

And it wasn't as flawless as on Linux

Did the parallel build stuff that was happening ~1/2 months ago end up making it into ClojureScript?

yep

I think you have to build it from source

think it is experimental but in yes

Hm

Or not

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojurescript%22

189 should have it

Awesome; gonna check it out

@richiardiandrea: it will appear in the next release

so far I’ve been using :parallel-build without issue, but more feedback is good

ooooops sorry @dnolen I assumed it wrong

@richiardiandrea: quite a few people have tried it out now and as far as I know I’ve fixed the obvious problems in the initial cut of it (clobbering System.out)

@dnolen: we had a crash in an internal project

we haven’t had time to make a minimal case yet

@danielcompton: for :parallel-build that’ll probably require more effort on your side to report since minimal cases will be quite tricky

I do suspect for anything that calls into macros with side-effects you’re going to have a hard time getting it to work reliably

but that’s a non-goal

and ClojureScript libraries that lie about dependencies between namespaces will spew warnings (devcards appears to have this problem)

@dnolen: What would be an example of a macro with side-effects here? Would reading from the filesystem to inject static values into build count as side-effects?

@pandeiro: anything

you can do whatever you want in a macro

@pandeiro: generally a ns is compiled once it dependencies are compiled, if they depend on the macro that was not required before they enter a race

eg. thread a compiles file with (:require-macros [cljs.core.async])

thread b as well

now one of them causes (require 'cljs.core.async) in clojure

the other one sees that it already was required and proceeds

but the macro may not be available or whatever

since a is still processing it

require doesn't lock or anything

at least that was the problem I ran into a year ago or so

makes sense @thheller, thanks for the explanation

dont think anything in that regard changed

So then that means code that e.g. uses core.async would potentially face this race condition using :parallel-builds?

yes

For completeness, here’s the stack trace we get

yeah pretty much what I ran into

https://www.refheap.com/91731

@danielcompton: right so this is probably the issue @theller has already pointed out

http://dev.clojure.org/jira/browse/CLJS-957

noted that there 😉

@thheller: in that ticket you say "FWIW the gain was minimal to begin with." <- you're referring to the gain in compile time with parallel building right?

yeah

although it really varies from project to project

depends on how many files can actually be compiled in parallel

and that is computed based on their dependency graphs not 'crossing'?

yeah

@pandeiro: the gain is not actually minimal in practice

people have reported 30%-300% faster

@dnolen: I'm testing it here for sure, I just want to see it regardless

On my project it’s twice as fast to build

is memory an issue?

I mean JVM memory

not that I’ve seen so far

hmm, what's the syntax? :compiler-options {:parallel-builds true} ?

@pandeiro: yep

wait, no s there right?

(says the wiki)

https://github.com/clojure/clojurescript/wiki/Compiler-Options#parallel-build

I managed a 6.5× speedup on an artificial project: https://github.com/mfikes/fifth-postulate

@pandeiro: yes sorry no s

@pandeiro: with cljsbuild we got parallel false: wallclock time: 95 seconds, build time 84 seconds parallel true: wallclock time: 62 seconds, build time 50 seconds (and a bunch of warnings which don’t show up with parallel false)

@danielcompton: @thheller: I just added locking around clojure.core/require usage might want to try with master

@danielcompton: looks pretty good

as I said the warnings mean you have some assumption about load order that do not respect the actual declared dependencies

I haven’t seen this problem in any cognitect ClojureScript libraries (core.async) or my own stuff

@danielcompton: there may be a bug here but I have yet to see any evidence of it yet

And timbre was the culprit for breaking our parallel builds, pulling it out let us build fine

the lock stuff should fix that

yes

Yeah, the master seems to fix require issues. I've tried :parallel-build true in one project and got a bunch of warnings like

WARNING: Use of undeclared Var cljs.core.async.impl.channels/ManyToManyChannel at line 30 .../public/assets/javascripts/application.out/cljs/core/async/impl/channels.cljs

cool, good to know

I still get warnings from devcards here even with the fix

@jaen: have you used it with boot-cljs by chance?

Si

with boot i'm not seeing any appreciable difference, neither with :none nor :advanced

That was with boot-cljs

I must be doing it wrong

@pandeiro: not necessarily, a lot factors could mean you don’t see any change or that it’s small

oh ok... no warnings though at least

@pandeiro my project has very little gains too, it really depends on how your project is structured

Compile sources, elapsed time: 18861.283601 msecs ; not parallel
Compile sources, elapsed time: 8902.465968 msecs ; parallel

@jaen nice

@thheller: can you shed any light in terms of what structural differences matter?

This project here - https://gitlab.com/jaen/clj-cljs-presentation

would total number of namespaces be one?

Though in this one I seem to have gotten some warnings

basically I have a bunch of "small" namespaces that can be compiled in parallel but all compile in <50ms

WARNING: Use of undeclared Var cljs.core.async.impl.timers/skip-list-node at line 34 .../public/assets/javascripts/application.out/cljs/core/async/impl/timers.cljs

then a bunch of "large" namespaces that others have to wait for

that take >1sec

eg. cljs.core, cljs.pprint, etc

can I turn up the verbosity to see how this is breaking down while it's compiling?

so if you have many of those "blocker" namespaces

the gains will be dominated by waiting for those

shadow-build shows detailed output 😉

cool yeah :verbose true is showing it

@dnolen: running from master, now I can build the project (with timbre in it) sometimes, and other times it fails with different errors. And the warnings we’re getting are different every time

the joys of debugging threads

@danielcompton: again there is a limit to what we can accomplish given arbitrary side effects, programmatic require, and all the other crazy things Clojure lets you do

so we can put a lock around require in ClojureScript but that won’t fix everything since require isn’t thread-safe

might be worth bringing up in #C06E3HYPR as something to think about for 1.9

Hi, I just got this error compiling my clojurescript using figwheel: {:tag :cljs/analysis-error} ANALYSIS ERROR: on file null, line null, column null

The problem was a circular ns reference I introduced accidentally. Would it be possible to show that in the error message?

Is that a figwheel or a clojurescript message?

@sveri Figwheel obfuscates the message more than it should. ClojureScript fixed the deeper in master a couple of days ago

so it’ll appear in the next big release

@dnolen: great, thank you

Is it possible to :refer-macros and rename them to something else? Or access them by their alias?

:include-macros is what I was looking for

@danielcompton: :include-macros doesn’t do that, it just allows you do avoid the corresponding :require-macros

there is as of yet, no :rename support in ClojureScript, and I said earlier I would be OK with a patch for that

would need to cover runtime stuff & macros of course.

doesn’t :include-macros let me access them by alias though?

yes it will use the ns alias you supplied

(ns my.ns
  [cljs.test :as cljs-test :include-macros true]
  [jx.reporter.karma :as karma :include-macros true]

…
  (karma/run-tests
  (cljs-test/run-tests

note you don’t need to bother with though

it works without :include-macros in this case

because cljs.test runtime & macros have same namespace and cljs.test runtime requires the macros ns

so you’ll get it for “free"

the only thing that doesn’t work yet is macro var inference in :refer, patch welcome for that too.

cool, thanks for explaining (what must be your millionth cljs macro explanation)