Fork me on GitHub
#clojurescript
<
2015-09-02
>
benzen00:09:05

guys how do you handle environement configuration, I mean something like the url of your server

okal10:09:26

I’ve been trying to get the async test example given in the cljs.test.async macro source to run but it fails every single time. It’s essentially a copy paste, with an (is true) assertion. Has anyone been able to get this working successfully?

okal10:09:29

This is it, basically:

(deftest example-with-timeout
  (async done
         (js/setTimeout (fn []
                          (is true)
                          (done))
                        0)))

dnolen11:09:38

@okal need more information, how are you trying to run it? It works fine for me.

okal11:09:22

@dnolen Here are some more details. Running ClojureScript 1.7.28. Using cljs.test. Running tests via lein cljsbuild auto test. None of the tests after the above run at all. The whole suite is terminated, with no summary.

okal11:09:30

The rest of the suite works just fine if I remove the async test, and keeps running even after failures occur.

dnolen11:09:01

@okal: pretty sure cljsbuild doesn’t have cljs.test support.

dnolen11:09:27

in general when saying something “doesn’t work” it’s important to add at least a few words about your environment

dnolen11:09:55

or what you actually tried

okal11:09:14

I’m sorry if I was unclear. We ported our entire test suite to cljs.test from cemerick.cljs.test. The tests run, and they have been for a while. Every last one. With cljsbuild. Could you please clarify what you mean by “support" here? Do you mean “support certain specific features”, or "support at all”?

okal11:09:27

The snippet I shared in my first post was the very thing I tried.

okal11:09:25

The project I’m experiencing this issue with is proprietary, so I can’t share anything too detailed. However, the structure isn’t all that different from this other project https://github.com/onaio/milia, which is Open Source. Which uses cljs.test. Which also uses lein-cljsbuild.

dnolen12:09:12

@okal: cljsbuild doesn’t have any real support for cljs.test or even clojurescript.test, all it does is build

dnolen12:09:37

or at least I have never used it in any other way

dnolen12:09:59

once built I just run with :notify-command, I’ve never used clojurescript.test so I can’t help you there.

okal12:09:37

lein cljsbuild auto test picks up any changes to your suite, or to the code under test, and runs them automatically. It works with both. It could be a peculiarity of the async macro that prevents tests using it from working with lein-cljsbuild (Not that I can see from the source).</digression> Anyway, my point is, tests written using either library work. Just tests using the async macro that fail. Thanks for taking time to answer, all the same, @dnolen.

dnolen12:09:07

@okal yes but I have no idea where you’re problem is.

dnolen12:09:32

core.async uses lein cljsbuild + cljs.test + async + :notify-commands works fine.

dnolen12:09:51

ClojureScript itself uses cljs.test + async + invoking node directly

dnolen12:09:26

so there’s something about your setup which might have nothing to do with cljs.test or async

okal12:09:38

👍:skin-tone-5: I’ll try and work out what’s going on.

dnolen12:09:34

@okal I see that you’re using phantom. One thing to try to isolate this, would be to just build your test file and try to run the tests directly with phantom.

dnolen12:09:23

@okal or slimer.js (where source maps are supported) - while I’m skeptical at the moment - it’s totally possible there’s some subtle bug with async that I haven’t heard about before.

okal12:09:12

That’s helpful, thanks. I’d actually thought of switching to Slimer in a moment of frustration.

ericstewart12:09:25

@okal I saw the behavior you describe with that exact example when trying to to use the async macro in planck a few days ago. I haven’t had a chance to go back and investigate further. I believe if I took out the (is true) from that example it didn’t terminate. This is not in browser however.

dnolen12:09:54

@ericstewart: I would not confuse any issues with anything involved anything bootstrapped

ericstewart12:09:06

the tests would just terminate with it in. Not sure how that helps as Planck (https://github.com/mfikes/planck) is a bit of of a different beast. Using ClojureScript 1.7.122 at the moment

dnolen12:09:09

it’s really a terrible idea given the untested state of bootstrapped things

ericstewart12:09:27

not surprising

dnolen12:09:39

@ericstewart: like I said assuming bootstrapped things are related to non-bootstrapped things is not a reasonable thing to do.

dnolen12:09:51

maybe 6 months from now

dnolen12:09:53

but not today

okal12:09:22

@ericstewart Odd. Like @dnolen said, probably unrelated, but might still be helpful. Not ruling anything out (including weird setup on my end, which is the likely culprit) at this point. Thank you.

dnolen12:09:30

@okal OK I took a moment to test phantom.js with nothing other than the cljs.jar. One file with one test using async and a setTimeout and one assertion.

dnolen12:09:33

it works fine here.

dnolen12:09:21

this would rule out that anything obvious in ClojureScript itself is the source of the issue

okal12:09:00

Did a minimal repro with just the one test, running with cljsbuild. Behaves the same way, so I think you’re right.

ricardo12:09:13

Thinking out loud time...

dnolen12:09:20

@okal so that helps, perhaps you’re mixing sync and async tests in the same file?

angusiguess12:09:12

@dnolen that's incredible.

ricardo12:09:10

I’ve got an application built with re-frame. I’ve been integrating pushy and bidi on the front end, so I can also handle state switches based on the path. But then it becomes a bit of a synchronization issue... Say I hve something with possible ui-states :state-1 and :state-2. Going to /the-site/state-1 will fire up that state. So far so good. Then we go to /the-site/state-2 and click on something, which fills in data for state-1. Right now I'm just changing the value on the app-state, but now I need to change both the value and the route, to keep them in sync (otherwise /the-site/state-2 would remain). Seems like the best thing to do is to pick one thing that'll drive everything... likely the routes, since that's user-controllable as well, and firing up the app-state changes from there.

okal13:09:19

@dnolen I was mixing them up earlier, under the (incorrect?) impression earlier that calling (done) would relinquish control from the async block, but I’ve managed to reproduce it, with just a single async test in a single file. @wilkerlucio Musicoacher looks really cool simple_smile Nice work.

dnolen13:09:23

@okal: yeah was just thinking through the possibilities. mixing async/sync tests definitely works and is supported.

dnolen13:09:04

@okal if you’ve got some code, I can test it over here.

jrychter13:09:08

Has anybody seen messages like these:

WARNING: No such namespace: clojure.lang.PersistentHashMap, could not locate clojure/lang/PersistentHashMap.cljs, clojure/lang/PersistentHashMap.cljc, or Closure namespace "" at line 146
WARNING: Use of undeclared Var clojure.lang.PersistentHashMap/create at line 146
Successfully compiled "resources/public/static/js/app.js" in 1.841 seconds.
I get these and can't hunt them down. The lines point to some defc or defcs forms (macros from Rum), nothing special about them. And the errors only happen when using figwheel, I don't get them when compiling the whole application with cljsbuild.

dnolen13:09:29

@jrychter: sounds like reader conditional issue with figwheel?

dnolen13:09:27

if not that then some other resolution problem

jrychter13:09:09

The strange thing is that it doesn't happen on every use of a defc macro, only sometimes.

okal13:09:18

@dnolen Thank you. Give this a try when you have a chance https://github.com/okal/async-cljsbuild-failure-repro

bhauman13:09:51

@jrychter: assuming that you have done a lein clean to see if the warning goes away? And things are still compiling and working though correct?

bhauman13:09:15

@jrychter: or (clean-builds) in the figwheel repl

dnolen13:09:17

@okal in general prefer to have something more minimal, before I look at that you should try some more things.

dnolen13:09:27

@okal is testing part of the problem?

okal13:09:51

Let me strip that out.

jrychter13:09:55

@bhauman: lein clean, yes. I haven't tried clean-builds. Things start behaving strangely after the errors: app in Safari starts working very slowly after reload. I would like to narrow it down, but I need a pointer.

dnolen13:09:32

@okal so note I never look anything involving cljsbuild, I don’t have the time or patience for 3rd party issues.

dnolen13:09:47

I will copy and paste this into something that only uses cljs.jar

dnolen13:09:53

in general that’s how issues should be reported

dnolen13:09:05

anything more is a huge waste of my time.

okal13:09:10

I thought we’d established that cljsbuild is part of the problem after your earlier attempt at reproduction. I misunderstood.

bhauman13:09:53

@jrychter: I'm assuming you have lein 2.5.2 and you are using fighweel in a script that was setup by chestnut?

dnolen13:09:03

@okal I just tried your code, cannot reproduce

dnolen13:09:19

@okal right but you put together an example that uses cljsbuild

dnolen13:09:27

which doesn’t remove that variable

jrychter14:09:30

@bhauman: lein 2.5.2, figwheel 0.3.8 (same behavior with 0.3.7) and my setup is derived from chestnut. Slightly simplified, as I removed piggieback and weasel. ClojureScript 1.7.48.

jrychter14:09:17

@bhauman: oh, one more variable: I run everything via cider-jack-in. Then from the REPL I launch figwheel as in the chestnut template (the start-figwheel function). But I also just tried from lein repl, same symptoms.

jrychter14:09:54

Well I guess I have to try to recreate this using a minimal example — I have no hints to go on.

dnolen14:09:49

@jrychter: rum uses sablono which I note has clojure.lang.Foo bits in there

dnolen14:09:18

doesn’t explain why it’s happening but that’s where I would start looking

jrychter14:09:52

Thanks. Will work on narrowing it down.

bhauman15:09:59

@jrychter: two things to try come to mind. Downgrade lien to 2.5.1 ... I'd really be interested to see if the problem goes away in this case. Otherwise I would try a standard lein figwheel setup where you launch figwheel separately from nrepl and your server code.

cjwebb17:09:45

hello. i'm having a go at cljs+nodejs. is there anything more clojurescripty than using expressjs? something that looks like compojure, perhaps?

akiva17:09:07

If you’re looking just for client-side routing, look into https://github.com/gf3/secretary or, if you’re looking for bidirectional matching, https://github.com/juxt/bidi.

cjwebb17:09:02

@akiva: thanks. i'm looking for routing on the server-side, ala expressjs or compojure. can secretary be used like that?

akiva17:09:21

Nope, it’s client-side only. Why not just use compojure?

cjwebb17:09:28

i could write the api in clojure, but im hoping a cljs version will use up less memory when running!

akiva17:09:39

Oh, I see what you mean.

cjwebb17:09:43

i'd like to deploy to vps

cjwebb17:09:59

so < 500Mb memory... which would all be comsumed by compojure

cjwebb17:09:47

if there isn't anything, i can just use normal expressjs in cljs

akiva17:09:53

I think bidi will do what you want.

cjwebb17:09:09

ok, i'll check it out. thanks again!

akiva17:09:37

No problem.

dnolen17:09:25

@cjwebb: I don’t know where you’re coming up with this 500mb number

dnolen17:09:59

JVM can run fine ~64mb, and Compojure shouldn’t be adding that much overhead

dnolen17:09:06

granted you can probably run Node.js in 5-10mb

cjwebb17:09:22

@dnolen: very possible i was doing something dumb, but a cursory glance at the used heap size whilst running a simple compojure app was ~250MB. JVM claimed the rest of the space available in case it needed to grow

cjwebb17:09:35

i could try the Xmx settings, and try to limit it somewhat though...

martinklepsch17:09:28

cjwebb: how did you run it?

cjwebb17:09:54

made an uberjar, then java -jar blah

dnolen17:09:57

@cjwebb: there’s going to memory defaults for your platform, if you want something different you need to supply this

cjwebb17:09:53

@dnolen: true. I didn't really investigate tuning them at all. i'll have go limiting it to 64mb

dnolen17:09:59

also Node.js is optimized for starting small but poorly reflects stable usage, it will also grow over time

dnolen17:09:24

people are reporting anywhere from 400mb - 500mb RAM usage in this case for an express.js app

dnolen17:09:43

assuming V8 is somehow magically going to have smaller memory than JVM for a real application - that’s a pipe dream

cjwebb17:09:38

interesting. wasn't aware of that either!

cjwebb18:09:29

looks like the clj app does perform when i restrict the heap-size to 64MB, so i'll go with that for now. sorry for wasting everyone's time 😐

cjwebb18:09:35

(and thanks again)

dnolen18:09:16

@cjwebb: no worries there’s an incredible amount of JVM FUD out there these days so hard to find the facts admittedly simple_smile

dnolen18:09:19

Opportunity grants available for Clojure/conj http://clojure-conj.org/opportunity

jrychter18:09:46

I've run small Clojure webapps with 64MB of heap just fine. These days I usually use 256MB in most cases, just to leave some headroom, and because servers are cheaper than they used to be.

wildermuthn18:09:00

When compiling in advanced mode, what’s the right way to prevent js-interop attributes from being renamed? I used “aget”, but that doesn’t appear to work. I remember reading about a goog function, but haven’t been able to find it.

wildermuthn18:09:31

(set! (.-MyProp js/window) true)

wildermuthn18:09:48

(set! (aget js/window “MyProp”) true)

wildermuthn18:09:10

That’s just an example. But no luck with both of those patterns for me, in advanced compilation.

dnolen18:09:29

@wildermuthn: 1) don’t use aget, use goog.object/get 2) I’m skeptical that the second thing doesn’t work

wildermuthn18:09:09

Maybe there’s another problem I’m overlooking, but good to know what to use now.

wildermuthn18:09:56

Would there be a reason not to use goog.object/set instead of set!?

darwin18:09:16

is it possible to somehow tell group-by to give sorted-map back?

dnolen18:09:18

@darwin no but you can pour the result in to sorted-map

dnolen18:09:26

or just write your own group-by

dnolen18:09:30

can’t be more than 10 lines or something

darwin18:09:46

@dnolen: ok will do, thanks

dnolen18:09:22

@wildermuthn: ah your second example just isn’t really valid code

dnolen18:09:48

@wildermuthn: use goog.object/set

dnolen18:09:57

(goog.object/set js/window “MyProp” true”)

darwin18:09:45

@dnolen: rewrite would not be as performant I guess, sorted-map does not support transient: No protocol method IEditableCollection.-as-transient defined for type cljs.core/PersistentTreeMap

darwin18:09:52

I will leave it as is

tel19:09:30

anyone know where to go to debug a bad base path for reloading in figwheel?

bhauman19:09:51

@tel: depends on your setup

bhauman19:09:26

What version of figwheel

tel19:09:56

just realized I was on 3.7, so I’ll try to update first

tel19:09:33

but goog.basePath shows up "

tel19:09:48

and I keep getting Refused to execute script from '' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

tel19:09:38

same issue with 3.8

tel19:09:56

I’m launching it on the client as

(figwheel/start
  {:websocket-url ""
   :on-jsload main/refresh!})

bhauman19:09:43

So basePath is set from where you are loading your ha

tel19:09:27

but base path appears to be correct when I check it in the console

bhauman19:09:26

And I'm assuming basePath is correct but the "reify" path is wrong

tel19:09:04

yeah, js/out/reify/fisher/… would work

tel19:09:23

sorry, should have been more clear simple_smile

bhauman19:09:00

So please do a clean and make sure that you are using the 3.8 client code

tel19:09:54

mmk, will double check that

tel19:09:19

oh, well, I wasn’t on the 3.8 code… but now that I am it’s blowing the call stack

tel19:09:53

but that might be on me

bhauman19:09:57

Ok no go to

bhauman19:09:17

0.3.9 snapshot your are using weasel

tel19:09:26

ah, yes I am

bhauman19:09:02

Be sure to close the browser tab

bhauman19:09:27

Or the so will prevent the rest from connecting

tel19:09:41

mmk, rebuilding now

bhauman19:09:59

I'm on my phone so it's hard to type :)

tel19:09:39

and that appears to have it!

tel19:09:46

thanks for directing me here

tel20:09:24

oh, hm, this call stack blowing thing seems to be persistent

tel20:09:35

I’ll try lein cleaning again

jtackett20:09:48

basic Om project if anyone is interested in how Om works https://github.com/jtackett/om-tictactoe

tel21:09:37

@bhauman: do you think the call stack blowing is arising from figwheel?

tel21:09:47

I seem to be seeing it every few reloads

tel21:09:26

actually, every 2 it seems

tel21:09:36

it might be a weasel interaction again

tel21:09:58

since figwheel appears to be ignoring my :figwheel-no-load

tel21:09:15

well… ugh, and now it’s unrepeatable

tel21:09:21

heisenbug

dnolen21:09:32

@bhauman @tel: I’m curious as to why people keep using Weasel if Figwheel has a REPL?

tel21:09:01

I learned the idea from Chestnut

tel21:09:12

I’ve seen reference to figwheel’s repl, but never investigated using it

tel21:09:37

it’s kind of a mess though

dnolen21:09:39

@tel ah yeah bringing in two different REPLs does not seem like a good idea

tel21:09:17

the only nicety I’ve seen from this design is that you just have one bg console rebuilding things

tel21:09:35

so it’s nice to say that dev startup is lein repl then (go!)

tel21:09:19

but… now that I get what’s going on more I’m not really sure the tradeoff is right

tel21:09:25

hm, there’s a weird interaction with figwheel and closure defines

tel21:09:35

since closure defines leaves bare symbols in the project map

tel22:09:03

I’m getting these guys: Exception in thread "main" java.lang.ClassNotFoundException: namespace.of.my.closure.defined.symbol, compiling: ...

martinklepsch22:09:32

What does your actual namespace look like?

martinklepsch22:09:56

make sure the namespace correlates to the directory structure and the path has no dashes

tel22:09:12

reify.fisher.ui.runtime.main

martinklepsch22:09:25

ok, so the dashes are out 😄

martinklepsch22:09:18

also closure? was that s intended?

martinklepsch22:09:34

any stacktrace?

tel22:09:39

it might have something to do with the weird quoting behavior of the project map

tel22:09:55

lemme stacktrace

martinklepsch22:09:04

are we talking about :closure-defines?

martinklepsch22:09:10

tried plain strings?

tel22:09:38

yep, and plain strings make it through figwheel boot but then don’t get replaced 😞

martinklepsch22:09:21

Hm. It should never try to load that. You’re not quoting the symbol in project.clj yes?

tel22:09:44

nope, if I do it complains about quote not being defined

tel22:09:02

I’m assuming Figwheel is peeking into the project map when it boots up

tel22:09:12

and then is blowing up when it evals those symbols

bhauman22:09:23

@tel: darn well the stack overflows are probably from the interaction of figwheel and the clojure.browser.repl that is being used by weasel.

martinklepsch22:09:42

Not using figwheel or lein so probably not going to be able to help

tel22:09:13

@martinklepsch: that’s cool, thanks for looking in simple_smile

bhauman22:09:17

@tel: I tried to patch it so they can work together but it sounds like its not working

tel22:09:54

I think at this rate I’m happy to just try jettisoning clojure.browser.repl simple_smile

tel22:09:50

but the closure-defines bit is sticky

bhauman22:09:56

@tel: hmmm so the project map has bare symbols in it

bhauman22:09:26

@tel: can you use strings?

tel22:09:47

I tried but it doesn’t seem to actually do the replacement then

bhauman22:09:34

@tel: can you show me a snippet of the build with the closure-defines in it

tel22:09:21

yep, with small redactions

bhauman22:09:23

my god this has never stopped being a pain in the but. symbols having to cross a serialization border in lein

bhauman22:09:04

@tel does that work in cljsbuild?

tel22:09:25

hah, yeah… it’s super confusing to keep in mind how the project map is being interpreted

juhoteperi22:09:26

:closure-defines only works with :advanced

tel22:09:35

and yeah

bhauman22:09:22

@derean: it only works with advanced?

juhoteperi22:09:52

use goog-define in the source to set defaults for dev

bhauman22:09:10

@tel: then there is no need to have it in the opt :none build

tel22:09:20

huh, I suppose not

tel22:09:39

I guess I had it there but it was being ignored anyway

bhauman22:09:42

And that is probably why it wasn't working with strings

tel22:09:00

except it wasn’t 😕

tel22:09:12

I was definitely getting config information through, huh

tel22:09:32

anyway, I can just have the defaults in source

bhauman22:09:30

@juhoteperi: it doesn't say it only works in advanced mode in the link you sent

juhoteperi22:09:42

"Ignored under :none and :whitespace modes."

bhauman22:09:54

I just can't read

tel22:09:32

deraen: they’re certainly not though

martinklepsch22:09:30

@juhoteperi: @tel, right, they’re only ignored if you do not use goog.define

bhauman22:09:41

well this is an issue that I'm going to have to look at

juhoteperi22:09:22

Hmh, looks like Cljs compiler might write closure-defines to the shim ns in :none mode.

bhauman22:09:23

@tel: I think I have a solution for the Stack Overflows for weasel.

ken22:09:43

is there any categorical theoretic abstraction support on cljs?

ken22:09:38

thank you

bhauman23:09:15

@tel: I just patched 0.3.9-SNAPSHOT to kill off the overflows. If you get a chance give it a clean build and let me know.