Fork me on GitHub
#clojurescript
<
2017-08-10
>
lvh00:08:07

I鈥檓 in no rush; lemme know if I can help debug 馃檪

anmonteiro00:08:52

@lvh so I can鈥檛 repro with current master

lvh00:08:00

FWIW as a workaround (def Logging (js/require "@google-cloud/logging")) seems to work fine

anmonteiro00:08:00

with :target :nodejs

anmonteiro00:08:09

right, that would work

anmonteiro00:08:28

but I just tried in an example project and could compile & run

anmonteiro00:08:44

(ns foo.core
  (:require ["@google-cloud/logging" :as gl]))

(enable-console-print!)

(println "google logging:" gl)

anmonteiro00:08:25

@lvh would be helpful to know which CLJS version/revision + compiler opts?

anmonteiro00:08:45

you sure you have :target :nodejs in there? 馃檪

anmonteiro00:08:06

because there seems to be a bug when compiling for web

lvh00:08:36

watch.clj:

(require '[cljs.build.api :as b])

(b/watch
 "src"
 {:output-to "main.js"
  :output-dir  "out"
  :main 'cspshovel.core
  :target :nodejs

  ;; 
  :process-shim false

  :optimizations :simple

  :npm-deps {:csp-report-norm "0.1.0"
             :aws-elasticsearch-client "1.0.2"
             "@google-cloud/logging" "1.0.5"}
  :install-deps true

  :verbose true})

lvh00:08:46

[org.clojure/clojurescript 鈥1.9.854鈥漖

anmonteiro00:08:53

please try master

lvh00:08:45

Is there documentation on how to do that? like a lein checkout dependency?

lvh00:08:08

(that鈥檚 how I鈥檇 do it)

anmonteiro00:08:14

git clone && cd clojurescript && ./script/build

anmonteiro00:08:33

then note down the CLJS version it built

anmonteiro00:08:37

and use that in your dependencies

anmonteiro00:08:46

not sure about checkouts

lvh00:08:16

ok, building now鈥 thanks 馃檪

anmonteiro00:08:16

@lvh let me know if that fixes it

anmonteiro00:08:23

I think there鈥檚 a release going out tomorrow

anmonteiro00:08:32

but I don鈥檛 cut releases so not promising anything 馃檪

lvh00:08:58

@anmonteiro that did indeed fix it! thanks 馃檪

lvh00:08:03

I鈥檓 going with the workaround for now

folcon00:08:03

Hey everyone, Anyone seen this before when interoping with a js-object? In the repl I can call: (.-get.user_email js/gmail) which gives me:

#object[Function "function () {
        return api.tracker.globals[10];
    }"]
However trying to log out the same function to js/console just gives me undefined, even though js-keys shows the name "user_email" and logging the result of .-get has the function appearing.

anmonteiro00:08:17

@lvh an immediate workaround is to query for @google-cloud/logging/src

anmonteiro00:08:35

we just couldn鈥檛 compute the provided main 馃槢

lvh00:08:42

@anmonteiro huh? I meant doing js/require 馃檪

anmonteiro00:08:53

I mean putting what I said and using the namespace declaration

anmonteiro00:08:11

there鈥檚 an extra /src in there

lvh00:08:18

as in :require [鈥淍google-cloud/logging/src鈥 :as Logging] ?

lvh00:08:33

馃懟

anmonteiro00:08:14

@lvh the reason stuff like "react-dom/server" works is because we index the node_modules installation

anmonteiro00:08:35

the above actually means there鈥檚 a node_modules/react-dom/server.js file

lvh00:08:43

conj talk suggestion (which I鈥檓 sure was submitted): step-by-step walkthrough of what happens when you $FANCY_CLJS_FEATURE

anmonteiro00:08:02

but I did submit a talk on this 馃檪

anmonteiro00:08:22

anyway, to continue what I was explaining

anmonteiro00:08:34

if in your case you have @google-cloud/logging/src/index.js

anmonteiro00:08:59

we index that as ["@google-cloud/logging/src/index.js", "@google-cloud/logging/src/index", "@google-cloud/logging/src"]

anmonteiro00:08:13

^ so you can require for any of the above

anmonteiro00:08:02

plus, if it鈥檚 the specified "main" in package.json, we also index it as "@google-cloud/logging" in this case

anmonteiro00:08:31

but in your case there鈥檚 a bug preventing it from happening

anmonteiro00:08:38

which has been fixed in the meantime

lumpy10:08:58

can鈥檛 seem to get Domina to fire scroll events for the browser window, what am I missing?

lumpy10:08:22

(ns keyboard.views
  (:require [re-frame.core :as rf]
            [re-com.core :as rc]
            [domina :as dom]
            [domina.css :as css]
            [domina.events :as events]))

;; home
(events/unlisten!)
(events/listen! :keydown #(rf/dispatch [:add-down %]))
(events/listen! :keyup #(rf/dispatch [:remove-down %]))

(events/listen! (css/sel "html") :scroll #(rf/dispatch [:handle-scroll]))

lumpy10:08:18

also tried (css/sel "body") and (events/listen! :scroll #(rf/dispatch [:handle-scroll]))

lumpy10:08:47

my key handlers work

djebbz12:08:35

Hello CLJS people. Is there a way, with the CLJS repo, to simply reinstall the CLJS jar locally anytime a change is made in source code ? I want to explore CLJS through my app.

djebbz12:08:01

I think a I need something like a watcher.

dnolen12:08:23

@djebbz hrm I don鈥檛 think so. Seems like you might want to use Lein checkouts? https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies

dnolen12:08:08

you may need to make the appropriate exclusions (I haven鈥檛 used checkouts in a while)

djebbz12:08:46

I want this, but my project is using boot, so I need the watch and rebuild capability independently.

dnolen12:08:19

ah I dunno then, probably need to ask about the comparable feature in #boot

djebbz12:08:24

That's fine, I'll use a dumb watcher from npm

djebbz12:08:32

Already asked 馃槈

djebbz12:08:41

Thanks David 馃憤

djebbz12:08:20

I think just having a watched that does lein install will do

grounded_sage13:08:52

how are most people doing data vis in Cljs? Just binding to D3?

grounded_sage22:08:56

Thanks I did come across that but given that it is Beta I'm not sure I'm keen to dive into it. I ended up deciding I'm going to play around with Elm Plot

dnolen15:08:09

@grounded_sage it鈥檚 a popular option yes

richiardiandrea16:08:58

@dsapoetra it seems like you are using b for generating a list of items (therefore it seems to assume you have a list in it). Then after you try to get an :id out of it as well. So you probably don't have a list in there?

dsapoetra16:08:16

@richiardiandrea I forgot a -> {鈥渋d鈥 {:score integer}} b -> [{:id 鈥渋d鈥潁 {鈥:id 鈥渋d鈥潁] So, a is map, b is vector of map

mihaelkonjevic17:08:32

If I omit foo definition from defrecord body it works correctly

mihaelkonjevic17:08:28

also, changing (bar this 2) to (apply bar [this 2]) or even ((identity bar) this 2) works correctly

grav18:08:09

Just read this from https://reasonml.github.io/guide/javascript/converting: >We highly recommend you to check the JS output into version control. It makes your build system integration quasi-nonexistent, and makes sure that when you鈥檙e not there, your teammates can make small changes, audit the output diff, and catch any mistakes. It鈥檚 also a great selling point that the checked in JS output is friendly to emergency hot patches (a big selling point for managers!). Even if you鈥檙e upgrading BuckleScript version, you鈥檇 catch any output difference. It鈥檚 like Jest snapshots, for free!

grav18:08:27

It鈥檚 an interesting approach. Would it make sense to do in a cljs-context?

tbaldridge18:08:03

I'd say if you have to look at the .js output of CLJS you need to refine your dev workflow

tbaldridge18:08:21

so I'd say no

noisesmith18:08:03

it looks like reason prioritizes simple /readable js output, which is cool I guess but not what every lang using js as a target is doing

tbaldridge18:08:08

CLJS does so many optimizations the resulting .js is rather meaningless for humans unless you really know what you're doing.

dnolen18:08:34

doesn鈥檛 make any sense for ClojureScript in my opinion

dnolen18:08:43

the source we generate is not for humans

dnolen18:08:21

also that鈥檚 a near non-sensical rationale in my opinion

dnolen18:08:42

your mileage may vary

anmonteiro18:08:04

@grav that recommendation exists mostly because JS compiled from Reason needs additional build steps in order to produce the final artifact

anmonteiro18:08:26

ClojureScript has an all-encompassing solution with the Closure Compiler

dnolen18:08:56

@anmonteiro it still doesn鈥檛 sound like a great recommendation

dnolen18:08:05

patching the generated sources 鈥 for real?

anmonteiro18:08:29

not sure that鈥檚 what they mean

dnolen18:08:39

I sincerely hope not, but that鈥檚 exactly how it reads

anmonteiro18:08:53

wait, that鈥檚 exactly what they mean

anmonteiro18:08:08

that鈥檚 directed at teams that have 1 person doing Reason and others doing JS

dnolen18:08:19

sounds horrible even in those cases

anmonteiro18:08:23

their message is strongly directed at converting JS codebases to reason

anmonteiro18:08:11

yeah, well, I鈥檝e been doing some Reason on the side recently and haven鈥檛 checked in any JS

anmonteiro18:08:49

kinda agree that recommendation shouldn鈥檛 be such a highlight 馃槢

dnolen18:08:55

I dunno, I recall people recommending this with CoffeeScript, and having tried it - don鈥檛 recall any benefits

dnolen18:08:44

maybe one time it helped me find a CoffeeScript scoping bug 馃槢

richiardiandrea18:08:47

We were committing dist in Typescript here, and it was so so so annoying that we got rid of that

mfikes19:08:39

It鈥檚 surprising that you can efficiently implement your language鈥檚 semantics by transpiling to another language while simultaneously keeping the output human-readable, even if downstream tooling operates on that intermediate result.

pesterhazy19:08:35

not to mention that committing js bundles to git is not sustainable in the long run - git is not built to contain (lots of) build artifacts

anmonteiro19:08:28

@mfikes probably easier if you know exactly what the types are

anmonteiro19:08:04

less so in a dynamically typed language like CLJS where emitting performant code is more difficult

richiardiandrea19:08:32

well Reason's output is super good and commented even, so it was the only one worth committing

richiardiandrea19:08:04

(yeah exactly because of types)

dnolen19:08:06

@richiardiandrea CoffeeScript had the exact same story

mfikes19:08:08

Even, that, consider the old Cfront, where types where known: What if it tried to generate idiomatic C? Seems challenging.

dnolen19:08:11

I never found it all that compelling

anmonteiro19:08:53

@mfikes different kind of typing

richiardiandrea19:08:44

@dnolen coming from CLJS, I was very surprised when I discovered that in the Typescript/JS world the REPL is not used at all (...plus the horrible .editor mode) and some folks only have two windows on the screen: one with the source and the other with the transpiled code. I have never understood the utility of that...actually I would like to know if I am missing something 馃槃

mihaelkonjevic19:08:46

@dnolen is this something that should be reported as a bug or am I doing something wrong? https://clojurians.slack.com/archives/C03S1L9DN/p1502385182089351 I couldn't find any mentions of behavior change in the change log and it seems that it was introduced in 1.9.456

mfikes19:08:29

@mihaelkonjevic I can鈥檛 get your approach to work in Clojure (replacing default with Object). It seems you want to be able to partially implement a protocol, and have it fall back for the parts not implemented. Interesting.

mihaelkonjevic19:08:42

Yeah, that's how I'm using it. The interesting thing is that it's breaking only if the non overriden method is called from inside of the overriden method

mfikes19:08:24

@mihaelkonjevic If you try it in Clojure, you鈥檒l see that once you partially implement Test in TestR, you can no longer (bar (->TestR) 1)

mfikes19:08:42

I suspect that the reason (bar (->TestR) 1) works in ClojureScript is accidental

urbank19:08:02

@mfikes What's the reason for that though? Isn't it useful for methods to fall back on the default implementation?

mfikes19:08:57

@urbank I鈥檓 just being lazy and using Clojure鈥檚 implementation as the definition of how protocols are supposed to work when partially implemented.

mfikes20:08:19

Hmm. @mihaelkonjevic that doesn鈥檛 work in Clojure. Perhaps the fact that the above works is an accident of implmentation.

dnolen20:08:26

@mihaelkonjevic you shouldn鈥檛 have ever expected that to work, if it did purely accidental

dnolen20:08:56

there鈥檚 no support for incomplete protocol implementations

dnolen20:08:22

@richiardiandrea heh yeah, not surprised re: TypeScript, and yeah in JS people really don鈥檛 lean on the REPL because the integration isn鈥檛 that good and many coding patterns make it less useful

mihaelkonjevic20:08:38

@dnolen thanks, good to know

urbank20:08:54

@dnolen I'm interested in the rationale behind not supporting incomplete protocol implementations. In contrast with haskell typeclasses for example.

dnolen20:08:20

@urbank it鈥檚 just how it works in Clojure

dnolen20:08:03

ask in #clojure or on the mailing list if you want to dig up the history 馃檪

urbank20:08:27

@dnolen Ok, cool, thanks! 馃檪