Fork me on GitHub
#clojurescript
<
2016-03-24
>
base69800:03:25

@weavejester: Sweet, seems like an obvious way to do it.

base69800:03:16

Did you have to keep the events in sorted order by some priority? I was doing that for a bit, but if I break it up into 3 handlers I don't seem to need it. Like a remove entity event that comes before update entity.

base69800:03:26

i do all the updates first then removes.

domainmoon02:03:39

Hello. I am new to Clojurescript RN. I am testing Luno sample which has tab bar controller. But, it doen’t act like native (iOS). Is it native?

jaredly03:03:35

which I would assume is just using cocoa’s native tab bar

weavejester03:03:35

@base698: No, I didn’t sort the events. A remove entity event just invalidates an update if the update comes after the remove.

mal04:03:55

Shameless newbie gimme-da-codez question: What is document.body.style.backgroundColor = "green"; in ClojureScript?

mal04:03:43

Looking to change the background color of a reagent app, and seeing this http://stackoverflow.com/questions/25474803/trying-to-use-react-dom-to-set-body-styles

akjetma04:03:17

(set! js/document.body.style.backgroundColor "green")

akjetma04:03:47

There are many ways to skin that cat though

akjetma04:03:04

(BTW what a weird phrase)

mal04:03:33

Right, duh, I'd just forgotten the set! -- yes, so I get tangled up in the various furs of CLJS/JS interop...

fasiha04:03:19

I'm not sure if it's proper HTML, but I've put a <style> tag inside the body of my view. In Hiccup: [:style "body {background-color: green;}"]. (I generate the CSS using garden.)

mal04:03:23

Oh wow fasiha, so then you can just have a function pop that pill in there as needed, and remove as well?

mal04:03:56

you guys rock

fasiha04:03:56

I'm not sure how robust that is. In plain HTML, one puts <style> inside <head>, but I tried putting it inside my top-level application <div> and it worked in Chrome ¯\(ツ)

fasiha04:03:20

I should stop cargo-culting DOM and properly learn how it works eh? 😞

akjetma04:03:43

@fasiha: that is a cool idea, i’d never thought of having a dynamic style component

mal04:03:37

Didn't know about garden for CSS, nice.

mal04:03:01

You guys wouldn't by chance know how feasible it is to use medium-editor (from cljsjs) in Reagent...?

jimmy07:03:14

hi guys I have this error while trying to setup cljs.test with lein doo :

(ns my-project.tests
  (:require
   [clojure.test.check :as tc]
   [clojure.test.check.generators :as gen]
   [clojure.test.check.properties :as prop]
   [cljs.test :refer-macros [deftest is are testing]])
  (:require-macros
   [clojure.test.check.clojure-test :refer (defspec)]))

(deftest testett
  (is (= 2 2)))

(defspec first-element-is-min-after-sorting ;; the name of the test
  100 ;; the number of iterations for test.check to test
  (prop/for-all [v (gen/not-empty (gen/vector gen/int))]
                (= (apply min v)
                                 (first (sort v)))))
The error I got
debug.html:38 Fail (first-element-is-min-after-sorting) (TypeError:NaN:NaN)
Expected nil
Actual: #object[TypeError TypeError: Cannot read property 'call' of null]
The test in deftest ran just fine. Are you guys have any idea why it does wrong ? THanks

danielcompton07:03:36

@nxqd have you tried a simple (= 1 1) in the body of your property test?

danielcompton07:03:44

Just to make sure it is written right?

jimmy07:03:14

@danielcompton: ah I got you. You meant in test.check

jimmy07:03:40

let me try

danielcompton07:03:51

(defspec first-element-is-min-after-sorting ;; the name of the test
  100 ;; the number of iterations for test.check to test
  (prop/for-all [v (gen/not-empty (gen/vector gen/int))]
                (= 1 1
                                 )))

jimmy07:03:34

I got the same error

danielcompton08:03:36

Try simplifying v to be gen/int

jimmy08:03:26

@danielcompton: I got another error:

Fail (first-element-is-min-after-sorting) (TypeError:NaN:NaN)
        Expected nil
        Actual: #object[TypeError TypeError: Cannot read property 'call' of null]

jimmy08:03:50

FYI: I got a warning that karma doesn't get the cljs_deps. But due to the docs from doo, it seems to be fine since it's included in the page itself. I do check that it's already included through /base/..../cljs_deps.js. Just in case you need this kind of information.

danielcompton08:03:58

gotta go sorry, good luck!

jimmy08:03:49

yeah, thanks

jimmy08:03:04

I think the key here is that cljs_deps should be included in karma as well.

jimmy09:03:19

@danielcompton: problem fixed, forgot to add :include-macros true to properties for clojurescript -_-

slotkenov12:03:48

Combining ClojureScript with JS libraries is still a bit of a dark area to me. Someone could point me in the right direction?

slotkenov13:03:35

@bhauman: seems like a good read, thanks!

bhauman13:03:11

@slotkenov: something to know is that it makes a lot of sense to leverage existing Google Closure libraries, also there is cljsjs as well

slotkenov13:03:36

Yeah. What I’m trying to do here is make use of a generated code for a client to a REST server defined by a swagger contract.

bhauman13:03:38

Gotcha, yeah check that doc out :)

dhruv113:03:08

I am trying to use http://www.material-ui.com/#/components/raised-button but can’t use the icon property. I keep getting the following error:

Warning: Failed propType: Invalid prop `icon` supplied to `RaisedButton`, expected a ReactNode. Check the render method of `reagent6`.
(defn main-panel []
  (reagent/create-class
   {:reagent-render
    (fn []
      [:div [(reagent/adapt-react-class js/MaterialUI.RaisedButton) {:onClick (fn [_] (println "clicked!"))
                                                                     :className "material-icons"
                                                                     :icon [:i {:class "material-icons"} "favourite"]}
             "home"]])}))

dhruv113:03:56

would anyone know how to create a react node? I’ve been googling but no luck

ckarlsen13:03:28

try {:icon (reagent/as-element [:i {:class "material-icons"} "favourite"])}

urbanslug13:03:45

I have this interesting problem where merely adding a go block makes an Om component fail.

dhruv113:03:47

wow. i no longer get the error. But i don’t see what I expect to see either 😞

dhruv113:03:02

buuutttt this works!! (reagent/as-element [:i {:class "material-icons"} "search”]) awesome! thank you very much!

base69816:03:18

can you ignore argument values in #(...)

base69816:03:21

if so how?

stex16:03:20

It looks like Clojurescript doesn’t warn when you call an anonymous function with the incorrect arity. The bugtracker indicates that it is fixed (http://dev.clojure.org/jira/browse/CLJS-361), but Clojurescript 1.8.34 doesn’t warn when I execute this code:

(defn hello-world []
  (fn []
    (println "hello!")))

((hello-world) "1")
Am I doing it wrong…?

richiardiandrea16:03:41

I tried it on my local replumb instance and I don't see warnings either

dnolen17:03:26

@stex it’s possible it’s a regression - file an issue with that example in JIRA please - thanks

stex17:03:42

@dnolen: I’ve just re-read https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure and it states "here is currently no runtime enforcement of arity when calling a fn”. It seems like this is by design, or do I misinterpret the text?

mfikes17:03:41

@stex: You can convert WARNINGS to compiler errors, FWIW

dnolen17:03:44

@stex there’s no guarantee of runtime enforcement

dnolen17:03:18

@stex that said I looked more closely at your example - we don’t handle that particular case actually

dnolen17:03:26

so it would be a minor enhancement ticket - not a regression

stex17:03:39

Ok, thanks for the quick response! I’ll file a ticket tomorrow 😉.

cky17:03:35

I have CLJS code that actually depends on the non-enforcement of arity.

cky17:03:00

So if it ever becomes enforced, code would break. 😛

dnolen17:03:08

@cky it’s not a good thing to depend on since that's JS semantics

dnolen17:03:18

however it's unlikely to ever change - the runtime hit is simply too big

cky17:03:24

Right, exactly JS semantics.

domkm19:03:59

Advanced compilation is not eliding dead code as I would expect it to. With goog.DEBUG as false, (when ^boolean goog/DEBUG (devtools/install!)) causes cljs-devtools to be included in the advanced build even though that is the only use of cljs-devtools in the project. Any ideas why it's not being elided?

domkm19:03:46

Hmm, it looks like simply requiring cljs-devtools causes it to be included in advanced build without even invoking it. I guess it's messing with the global environment by default so GClosure is unable to determine that it should be elided. CC @darwin

darwin19:03:20

@domkm: cannot comment on this without investigating it, but there is a reliable solution how to exclude devtools in release build, use different :source-paths and do not include devtools-related files in release build

darwin19:03:10

I have one experience with DCE not working as expected when under :advanced optiomizations, when I store function reference to a map under a key and that key is never accesssed/used, the function still doesn’t get removed as a dead code

darwin19:03:44

had a config map working this way and then had to generate it via a macro, to work around this problem

domkm19:03:57

@darwin That would undoubtedly solve the issue but it's less convenient and, given GClosure's advanced DCE, shouldn't be necessary

domkm19:03:45

@darwin that function in a map problem is likely due to GClosure not understanding CLJS data structures

darwin19:03:07

I agree, would be great if you could find the actual reason why is it not removed, maybe it has some reasonable explanation which could be worked around

domkm19:03:43

@darwin: I'd bet that if you changed the defs into defns it would work perfectly

domkm19:03:58

@darwin: many of those defs compile to immediately invoked functions which, as far as GClosure can tell, are impure and therefore cannot be elided

darwin19:03:10

if defs are problem, why defns aren’t? defn compiles down to something like (def x (fn …))

darwin19:03:35

or do you mean those ^:dynamic defs?

domkm19:03:51

@darwin: because GClosure can tell that the defns are not invoked

domkm19:03:55

@darwin: the issue, I think, are things like '(def foo (if ... ...))' because they immediately do something which could be side-effecting

darwin19:03:06

@domkm: can you point me to some instance of this in cljs-devtools code? I don’t see it anywhere

darwin19:03:39

I will go ahead and add a new profile into cljs-devtools-sample with your usecase under :advanced build and test it there

darwin19:03:54

will see how it behaves, now it is just guessing for me

domkm19:03:24

Sure, stand by

darwin19:03:25

thanks, will investigate it

domkm19:03:55

There are some others as well. Happy to find them all if it would help you.

raf20:03:54

Hi, when I start figwheel (in Cider or as lein figwheel) I get such warnings: WARNING: Unknown option ':compiler-env'. WARNING: Unknown option ':init'. Did you mean ':main'? WARNING: Unknown option ':special-fns'. WARNING: Unknown option ':bind-err'. WARNING: Unknown option ':warn-on-undeclared'. WARNING: Unknown option ':quit-prompt'. Could you point me where I could find this settings? What should I do with them? Thanks in advance

dnolen20:03:41

@raf it’s fixed in master, incremental release tomorrow

raf20:03:04

@dnolen: ah, thanks a lot for info. I thought it's fault of my configuration

dnolen20:03:27

@raf no a unintentional side-effect of some better error reporting

raf20:03:01

@dnolen: I see, good to know - thx for info and your contribution/code

darwin22:03:13

@domkm: just added some dirty code to test differences between advanced builds into cljs-devtools-sample: https://github.com/binaryage/cljs-devtools-sample/commit/bbaee2b3d58c00d6dd64f88ee053ea01db42f14b

darwin22:03:44

conclusion: eliding works, but not using your method, the optimizer does not seem to understand js/goog.DEBUG

domkm22:03:07

Try putting ^boolean before goog/DEBUG

domkm22:03:21

Also it's goog/DEBUG, not js/goog.DEBUG

darwin22:03:26

I did, used your version of condition as well

darwin22:03:39

it behaves the same AFAIK

darwin22:03:08

but there is still room for improvement on cljs-devtools side, because some stuff gets generated even in minimal case (no-install)

darwin22:03:35

as you pointed out, some side-effecting code is run when cljs-devtools is required

darwin22:03:06

and bunch of methods in devtools.dirac namespace have ^:export set, so they force some parts to be included

darwin22:03:25

I can fix both things

domkm22:03:43

I don't think you set the Closure define in your advanced build

domkm22:03:36

You need to specify goog.DEBUG as false so that GClosure knows the value ahead of compilation

darwin22:03:49

I did not, ok that is a mistake, sorry for that, I thought it is automatic

darwin22:03:56

let me reeval

domkm22:03:02

No problem. I thought it was automatic earlier today simple_smile

domkm22:03:08

be sure to change js/goog.DEBUG to goog/DEBUG when you add that compilation option simple_smile

richiardiandrea22:03:28

I have had weird behaviors with goog.DEBUG too lately, why do I need ^boolean?

richiardiandrea22:03:04

in my case it was like this: (when goog.DEBUG (print (make-warning-fn# %)))

richiardiandrea22:03:15

but the print was always executed

richiardiandrea22:03:20

in replumb tests

domkm22:03:18

@richiardiandrea JS truth is different than CLJS truth. If you don't add ^boolean, CLJS will wrap it in a check to make sure it is null, false, or undefined (I think) but not 0 or "". GClosure doesn't know about this truth check nor can it infer the result of the check, so it cannot elide a conditional based on it. ^boolean tells CLJS that the return value of the expression is a boolean and therefore it doesn't need to wrap it in an additional truth check.

darwin22:03:25

so far if goog/DEBUG behaves the same as in my previous case even with closure-defines

richiardiandrea22:03:37

(not a really JS guru here)

domkm22:03:52

with ^boolean?, @darwin?

darwin22:03:36

no, without, let me do another test

domkm22:03:49

@darwin: Thanks for working on this simple_smile

richiardiandrea22:03:05

will try that too, maybe you solved too problems at the same time 😉

domkm22:03:02

Yay! Nicely done

domkm22:03:38

Those are the results I would expect simple_smile

darwin22:03:50

so now I will just get rid of those ^:export and init code a we should be clean

domkm22:03:06

Yeah, I think so

domkm22:03:27

I don't even know if getting rid of ^:export is necessary. I'd be curious to know either way.

darwin22:03:07

removing those exports definitely reduced the number of remaining symbols

domkm22:03:12

Ah, you're probably right then. I guess it might be best to remove them.

domkm22:03:30

Why were you exporting?

darwin22:03:02

theoretically someone could want to use dirac against advanced build

darwin22:03:11

it should be possible

domkm22:03:16

Ah. I see

darwin22:03:09

no worries, I will let it configurable via ENV, and generate that api dynamically when enabled (via macro I guess)

darwin22:03:26

will solve it somehow

domkm22:03:44

Perhaps it could be a different entry point?

domkm22:03:59

So you only get dirac stuff if you require it

darwin22:03:06

that is also a possibility

darwin22:03:27

maybe dirac support should be completely decoupled from cljs-devtools as a separate library

domkm23:03:46

Anyone know if it's possible to output ES6 from ClojureScript? Specifically, I'd like to output a class definition.