Fork me on GitHub
#clojurescript
<
2015-12-09
>
mfikes01:12:29

@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

jaredly03:12:49

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)

dnolen03:12:43

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

noonian03:12:30

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

dnolen03:12:38

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

dnolen03:12:44

and you can use all the old tricks

jaredly03:12:52

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

dnolen03:12:29

right, that’s other approach

jaredly03:12:54

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

johannjohann06:12:39

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

johannjohann06:12:50

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

dnolen11:12:36

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

joost-diepenmaat12:12:06

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

joost-diepenmaat12:12:16

for instance, on node runtime

joost-diepenmaat12:12:47

so (exists? js/window) ?

dnolen12:12:04

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

joost-diepenmaat12:12:14

ok thanks that looks like what we need

deas13:12:47

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

dnolen13:12:21

@deas check the externs file

dnolen13:12:29

I don’t see anything about line property anywhere

dnolen13:12:08

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

deas13:12:42

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

dnolen13:12:28

@deas that's just type checking information

dnolen13:12:32

nothing to do with renaming

deas13:12:40

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

dnolen13:12:06

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

dnolen13:12:20

that externs file is just incomplete

dnolen13:12:01

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

deas13:12:28

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

dnolen13:12:56

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

deas13:12:43

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

dnolen13:12:11

that’s what I would recommend

dnolen13:12:29

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

deas13:12:58

I understand the people. simple_smile

dnolen13:12:51

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

dnolen13:12:05

should probably be in everyone bookmarks

deas13:12:18

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

ghadi16:12:53

did any of the NYTimes demos use Clojurescript?

dnolen16:12:27

@ghadi: ? what are you referring to?

ghadi16:12:55

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

dnolen16:12:30

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

ghadi16:12:52

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

dnolen16:12:09

not really, just that nobody knew Clojure or ClojureScript

dnolen16:12:16

that’s a huge problem on newsroom deadlines

cab16:12:56

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

gtrak16:12:20

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

gtrak16:12:29

we've been using it for over a year

gtrak16:12:52

notably, isEmpty on null is false.

cab16:12:04

interesting

dnolen16:12:34

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

gtrak16:12:49

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

gtrak16:12:49

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.

gtrak16:12:04

and we want time-travel

gtrak16:12:17

but we're using redux as an intermediate step.

cab16:12:23

haha same here

cab16:12:25

redux-wise

gtrak16:12:45

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

cab16:12:54

scary 😉

tompurl17:12:07

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

tompurl17:12:23

Here's what I have:

tompurl17:12:24

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

tompurl17:12:49

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

tompurl17:12:02

Here's my regular deps:

tompurl17:12:03

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

cab17:12:28

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

tompurl17:12:26

@cab Thanks a bunch, that worked!

mfikes18:12:55

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.

pandeiro18:12:45

@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...

pandeiro18:12:48

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

dnolen18:12:55

I’ve never used prefix lists not even once

dnolen18:12:43

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

dnolen18:12:24

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

sdroadie19:12:11

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.

pandeiro19:12:53

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

sdroadie19:12:50

@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.

sdroadie19:12:43

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

sdroadie19:12:43

@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.

sdroadie19:12:57

@pandeiro: Not sure if that is possible.

pandeiro19:12:08

@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

pandeiro19:12:38

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

pandeiro19:12:53

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

sdroadie19:12:13

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

sdroadie19:12:33

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

pandeiro19:12:42

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

pandeiro19:12:54

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

sdroadie19:12:03

Cool. I'm using docker-compose.

pandeiro19:12:40

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 😕

sdroadie19:12:55

I'm running on Ubuntu.

pandeiro19:12:04

Then you should be fine

sdroadie19:12:10

Rad. Thanks for your help.

jaen19:12:58

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.

pandeiro19:12:42

@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

richiardiandrea19:12:57

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

pandeiro19:12:03

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

sdroadie19:12:55

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

jaen19:12:24

@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 '

richiardiandrea19:12:25

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

pandeiro19:12:32

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

pandeiro19:12:07

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

jaen19:12:07

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

shaun-mahood19:12:44

@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.

shaun-mahood19:12:09

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

jaen19:12:49

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.

pandeiro19:12:15

that's the dream yeah...

jaen19:12:41

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

pandeiro19:12:53

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

jaen19:12:21

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

jaen19:12:40

I remember a friend trying it on his tablet PC once

jaen19:12:51

And it wasn't as flawless as on Linux

pandeiro19:12:48

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

jaen19:12:18

I think you have to build it from source

richiardiandrea19:12:20

think it is experimental but in yes

jaen19:12:37

189 should have it

pandeiro19:12:52

Awesome; gonna check it out

dnolen20:12:37

@richiardiandrea: it will appear in the next release

dnolen20:12:52

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

richiardiandrea20:12:24

ooooops sorry @dnolen I assumed it wrong

dnolen20:12:19

@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)

danielcompton20:12:35

@dnolen: we had a crash in an internal project

danielcompton20:12:54

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

dnolen20:12:23

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

dnolen20:12:46

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

dnolen20:12:55

but that’s a non-goal

dnolen20:12:58

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

pandeiro20:12:30

@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?

dnolen20:12:01

you can do whatever you want in a macro

thheller20:12:51

@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

thheller20:12:15

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

thheller20:12:19

thread b as well

thheller20:12:43

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

thheller20:12:58

the other one sees that it already was required and proceeds

thheller20:12:06

but the macro may not be available or whatever

thheller20:12:14

since a is still processing it

thheller20:12:21

require doesn't lock or anything

thheller20:12:40

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

pandeiro20:12:44

makes sense @thheller, thanks for the explanation

thheller20:12:09

dont think anything in that regard changed

pandeiro20:12:19

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

danielcompton20:12:37

For completeness, here’s the stack trace we get

thheller20:12:35

yeah pretty much what I ran into

dnolen20:12:39

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

thheller20:12:54

noted that there 😉

pandeiro20:12:38

@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?

thheller20:12:05

although it really varies from project to project

thheller20:12:18

depends on how many files can actually be compiled in parallel

pandeiro20:12:40

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

dnolen20:12:17

@pandeiro: the gain is not actually minimal in practice

dnolen20:12:26

people have reported 30%-300% faster

pandeiro20:12:39

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

dnolen20:12:41

On my project it’s twice as fast to build

pandeiro20:12:43

is memory an issue?

pandeiro20:12:48

I mean JVM memory

dnolen20:12:03

not that I’ve seen so far

pandeiro20:12:02

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

pandeiro20:12:39

wait, no s there right?

pandeiro20:12:48

(says the wiki)

mfikes20:12:08

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

dnolen20:12:48

@pandeiro: yes sorry no s

danielcompton20:12:49

@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)

dnolen20:12:19

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

dnolen20:12:46

@danielcompton: looks pretty good

dnolen20:12:05

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

dnolen20:12:26

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

dnolen20:12:04

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

danielcompton20:12:20

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

thheller20:12:37

the lock stuff should fix that

jaen20:12:10

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
With freshly build compiler it's gone.

dnolen20:12:47

cool, good to know

dnolen20:12:56

I still get warnings from devcards here even with the fix

pandeiro20:12:17

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

pandeiro20:12:54

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

jaen20:12:56

That was with boot-cljs

pandeiro20:12:00

I must be doing it wrong

dnolen20:12:41

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

pandeiro20:12:22

oh ok... no warnings though at least simple_smile

thheller20:12:16

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

jaen20:12:35

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

pandeiro20:12:59

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

pandeiro20:12:21

would total number of namespaces be one?

jaen20:12:25

Though in this one I seem to have gotten some warnings

thheller20:12:36

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

jaen20:12:45

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

thheller20:12:45

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

thheller20:12:53

that take >1sec

thheller20:12:01

eg. cljs.core, cljs.pprint, etc

pandeiro20:12:20

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

thheller20:12:28

so if you have many of those "blocker" namespaces

thheller20:12:38

the gains will be dominated by waiting for those

thheller20:12:03

shadow-build shows detailed output 😉

pandeiro20:12:54

cool yeah :verbose true is showing it

danielcompton20:12:35

@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

thheller20:12:11

the joys of debugging threads simple_smile

dnolen20:12:00

@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

dnolen20:12:14

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

dnolen20:12:09

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

sveri22:12:56

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

sveri22:12:23

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

sveri22:12:40

Is that a figwheel or a clojurescript message?

dnolen22:12:42

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

dnolen22:12:50

so it’ll appear in the next big release

sveri22:12:42

@dnolen: great, thank you simple_smile

danielcompton22:12:40

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

danielcompton22:12:36

:include-macros is what I was looking for

dnolen22:12:49

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

dnolen23:12:09

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

dnolen23:12:17

would need to cover runtime stuff & macros of course.

danielcompton23:12:28

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

dnolen23:12:54

yes it will use the ns alias you supplied

danielcompton23:12:07

(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

dnolen23:12:26

note you don’t need to bother with though

dnolen23:12:37

it works without :include-macros in this case

dnolen23:12:00

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

dnolen23:12:05

so you’ll get it for “free"

dnolen23:12:06

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

danielcompton23:12:06

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