Fork me on GitHub
#clojurescript
<
2017-04-22
>
tech_hutch00:04:03

When I go to compile, I'm getting an error that I have a duplicate case test constant on a line where I don't even have a case. Here is the file in question (line 35 is where it says the error is): https://hastebin.com/ecucawobev.cljs Here is the full error: https://hastebin.com/oliciqupaj.txt

souenzzo00:04:19

using :hooks [leiningen.cljsbuild] how to select the build id that I want to target?

tech_hutch00:04:39

I also have no idea where '6' is coming from, since the only case I use in the file doesn't have that :thinking_face:

noisesmith00:04:52

@tech_hutch is line 36 an infinite loop caused by not adding an extra arg?

noisesmith00:04:16

oh wait, no, the underscore means they are duplicate arities

noisesmith00:04:27

I bet that's the real error, and the message is just hallucinating

tech_hutch00:04:45

How does the underscore mean duplicate arities?

noisesmith00:04:52

it's an argument

noisesmith00:04:01

which means you have the same argument count twice

tech_hutch00:04:04

I'm not using that arity now, but that was just to throw away an extra argument, if it was given

noisesmith00:04:18

two of the same arity is invalid, that arity is defined twice

noisesmith00:04:41

clojure multi-arity functions can only dispatch on argument count

noisesmith00:04:58

so two "arity definitions" that have the same arity, is invalid

tech_hutch00:04:59

I'm not sure what you mean. The first arity has an additional (unused) argument.

noisesmith00:04:04

no it does not

noisesmith00:04:14

it has the same arg count, but one is unnamed

tech_hutch00:04:29

Thanks for pointing that out

tech_hutch00:04:52

What a strange error message, though :thinking_face:

noisesmith00:04:59

it would be nice if the compiler could give you that error directly (I bet the stack trace was created inside the unwrapping / rewriting of the form)

noisesmith00:04:21

6 is a duplicate case: two arg counts that are both 6

tech_hutch01:04:31

Okay, that makes a little more sense I guess haha

john01:04:41

@tech_hutch Are you sure it doesn't have a ".js" on the end of filename in question?

tech_hutch01:04:51

As it says in the error, it's debug.cljs. Why?

john01:04:32

ah, yeah, I thought I saw something like that recently. But after looking your error message, not sure.

johnj02:04:45

is ^:const on a def equivalent to javascript's const ?

souenzzo03:04:26

Hey I'm using cljsbuild with :hook method. How to remove hook from test?

john03:04:01

@lockdown- Someone was talking about that recently, I believe. You may want to check the logs. But according to Mike Fikes, it can definitely result in different JS being produced by the CLJS compiler. See here: http://blog.fikesfarm.com/posts/2015-06-15-clojurescript-case-constants.html

riz12:04:52

What's that .-target and .-value in https://reagent-project.github.io/ ?

riz12:04:25

The dotted functions are usually from some standard Java libraries, right?

john12:04:51

In CLJS, the .- syntax gets at the value of the property on a particular object. Whereas the . syntax invokes the method of a particular object. So, .next might invoke the next execution of the next method, but .-next gets the value stored in a property called next.

john12:04:07

Both dot operators are for doing host interop. On CLJS, we have both the dot operator and the dot-dash operator. On CLJ (on Java), we have only the dot operator.

john12:04:24

This is because, in javascript land, we don't have an easy way of differentiating between which fields are value properties and which are methods.

john12:04:51

So, for CLJ, yes, the dotted function syntax is for interop between CLJ and all Java libraries.

john12:04:33

and in CLJS the dotted and dot-dashed syntax is for interop between CLJS and all JavaScript libraries.

john12:04:44

'standard' or otherwise.

riz12:04:42

Okay, makes sense. So an r/atom has as default some property called target, which in turn has a property called value?

john12:04:42

close, but not quite. I suppose you're talking about (swap! bmi-data assoc param (.-target.value e))

john12:04:04

in that line, the bmi-data is the atom

john12:04:13

because this is a Lisp, the first item in the list is the function operating on every other item in the list. In this case, swap! always takes the atom it is operating on as the first argument.

john12:04:13

in this particular example, e is the event value that is usually passed to a callback in JS-land.

john12:04:13

so there looking at this line, it looks like, because the second argument to swap! is an assoc, the value in the atom is probably a map. swap! always supplies the value of the atom as the first argument to the function passed into swap!s second argument.

riz12:04:34

Well actually I was talking about the component atom-input in one of the simpler examples

john12:04:54

So we are associng param as a key on the map in the atom, with the value returned by (.-target.value e)

john12:04:23

ah, this one? #(reset! value (-> % .-target .-value))

john12:04:56

same deal, reset! just ignores the current value in the atom.

john12:04:31

but same deal, we are working with an onChange listener in JS land. This always supplies an event object to the callback being supplied. In this instance, we're using an anonymous function, so event or what's usually called e in many examples, is just % here.

john12:04:14

So, event object has a property on it called target

john12:04:38

inside target there are apparently more fields we can access, one of which is called value

john12:04:09

another way to write that would be (.-value (.-target %))

john12:04:58

We can see that neither of those are method invocations, because they are both dot-dash operators.

john12:04:27

We're simply pulling the data out of the event object that we care about.

riz12:04:37

I think I get it now. So an event handler like :on-change has that implicit event, to which you can refer to with % in an anonymous function, or like (fn [event] ...)

john12:04:58

precisely

riz12:04:57

Thanks a bunch!

tbaldridge13:04:16

@john @riz .- was also added to CLJ, when CLJS became popular, for cross-platform reasons. So thankfully there's no reason to write CLJ code differently. When CLJ sees .- it treats it pretty much the same as .

john13:04:28

@tbaldridge didn't know that! thanks.

petterik14:04:09

Does anyone have an idea of how to use the new cljs :npm-deps with npm library "@google/maps"? Can't write the deps as a keyword: :npm-deps {:@google/maps "0.3.1"}, and can't require (:require [@google/maps]) 🤷‍♂️