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

I’m in no rush; lemme know if I can help debug 🙂

anmonteiro00:08:52

@lvh so I can’t 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’s how I’d 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’s a release going out tomorrow

anmonteiro00:08:32

but I don’t cut releases so not promising anything 🙂

lvh00:08:58

@anmonteiro that did indeed fix it! thanks 🙂

lvh00:08:03

I’m 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’t 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’s 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’s a node_modules/react-dom/server.js file

lvh00:08:43

conj talk suggestion (which I’m 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’s 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’s a bug preventing it from happening

anmonteiro00:08:38

which has been fixed in the meantime

lumpy10:08:58

can’t 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’t 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’t 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’s 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 -> {“id” {:score integer}} b -> [{:id “id”} {“:id “id”}] 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’re not there, your teammates can make small changes, audit the output diff, and catch any mistakes. It’s 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’re upgrading BuckleScript version, you’d catch any output difference. It’s like Jest snapshots, for free!

grav18:08:27

It’s 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’t make any sense for ClojureScript in my opinion

dnolen18:08:43

the source we generate is not for humans

dnolen18:08:21

also that’s 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’t sound like a great recommendation

dnolen18:08:05

patching the generated sources … for real?

anmonteiro18:08:29

not sure that’s what they mean

dnolen18:08:39

I sincerely hope not, but that’s exactly how it reads

anmonteiro18:08:53

wait, that’s exactly what they mean

anmonteiro18:08:08

that’s 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’ve been doing some Reason on the side recently and haven’t checked in any JS

anmonteiro18:08:49

kinda agree that recommendation shouldn’t be such a highlight 😛

dnolen18:08:55

I dunno, I recall people recommending this with CoffeeScript, and having tried it - don’t 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’s surprising that you can efficiently implement your language’s 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’t 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’ll 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’m just being lazy and using Clojure’s implementation as the definition of how protocols are supposed to work when partially implemented.

mfikes20:08:19

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

dnolen20:08:26

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

dnolen20:08:56

there’s no support for incomplete protocol implementations

dnolen20:08:22

@richiardiandrea heh yeah, not surprised re: TypeScript, and yeah in JS people really don’t lean on the REPL because the integration isn’t 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’s 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! 🙂