Fork me on GitHub
#cljs-dev
<
2018-12-15
>
dnolen01:12:27

@lilactown thanks for the patches as well!

😁 4
lilactown01:12:31

Welcome! Thanks for making the process easy. I am having fun playing with the new protocols now

lilactown02:12:32

Well, now that I’m in your good graces 😛 I’ll ask a question. I’ve hit a kind of corner case using with-meta with functions… and React. The problem:

(defn Foo [_] "bar")

(react-is/isValidElementType Foo)
;; => true

(react-is/isValidElementType (with-meta Foo {:bar "baz"}))
;; => false
The crux of the issue seems to be that React checks if typeof equals "function".
(goog/typeOf Foo)
;; => "function"

(goog/typeOf (with-meta Foo {:bar "baz"}))
;; => "object"

lilactown02:12:58

there happens to be another issue already filed about with-meta and functions, CLJS-2446: https://dev.clojure.org/jira/browse/CLJS-2446 the proposed implementation in the ticket actually solves this particular thing as well

favila03:12:07

Crazy idea; could use a WeakMap to keep metadata on arbitrary (native) objects

lilactown03:12:21

mfikes actually pasted a similar idea at me the other day: https://gist.github.com/mfikes/122814757fd1f2aec9de509446793e5f

lilactown03:12:11

WeakMap would be better in that it wouldn’t leak memory as the metas map is accreted and the referenced objects are GC’d, but I’d be worried about support in all environments 😕

john04:12:19

I'm not sure that impl is accreting/leaking though. New references are bumping off the old ones from the map, right?

mfikes04:12:21

My gist leaks

mfikes04:12:41

In the sense that the metas out live the objects

john04:12:50

Ah right

john04:12:32

It'd be nice to have a WeakPersistentHashMap for those purposes.

john04:12:23

I was just wondering about that 😁 it's just JavaScript. How would that fair with advanced compile?

mfikes04:12:32

Interesting question. If you did (set! (.-object-meta o) meta) then your key could get smaller, but maybe collide with another existing key.

john04:12:28

But goog.obj/set is safe?

mfikes04:12:53

Yeah, in the sense that the key will be left as "object_meta" under :advanced

mfikes16:12:18

I'm not seeing the typo @lilactown. Grabbing another cup of coffee. 🙂

lilactown16:12:36

:problems :fn :cljs.spec.test.alpha/caller are keywords

lilactown16:12:56

at least, this throws when I try and run that commit in shadow-cljs

lilactown16:12:19

but AFAICT they should be symbols problems fn cljs.spec.test.alpha/caller

mfikes16:12:40

Yeah, they probably should be symbols. Perhaps there is an older destructuring fn at play that is causing the issue. Both can work.

cljs.user=> (let [{:foo/keys [:a]} {:foo/a 1}] a)
1
cljs.user=> (let [{:foo/keys [a]} {:foo/a 1}] a)
1

mfikes16:12:08

Maybe it just works by accident but is incorrect.

lilactown16:12:11

:face_with_monocle: huh!

mfikes16:12:10

Regardless, probably worth fixing if we get to the bottom of it 🙂

lilactown16:12:47

I thought I uncovered another problem with MetaFn: it breaks equality

(= Foo (with-meta Foo {:bar "baz"}))
but apparently Clojure has the same behavior 😐
user=> (defn foo [] "bar")
#'user/foo
user=> (= foo (with-meta foo {:bar "baz"}))
false

lilactown16:12:34

> dustingetz: functions are reference equality that makes sense nevermind

mfikes17:12:40

@lilactown You are right about the :foo/keys thing. In that case, the spec says the vector has to contain simple symbols. https://github.com/clojure/core.specs.alpha/blob/master/src/main/clojure/clojure/core/specs/alpha.clj#L37

mfikes17:12:50

I'll follow up with a JIRA and a patch.

mfikes18:12:10

Now that master provides the JavaScript error type when an execution error occurs, as in

cljs.user=> (ffirst 1)
Execution error (Error) at (<cljs repl>:1).
1 is not ISeqable
there might be more motivation to revise the places where we simply throw js/Error and instead throw more specific error types. For example, note the appearance of TypeError:
cljs.user=> (re-matches #"a" 1)
Execution error (TypeError) at (<cljs repl>:1).
re-matches must match against a string.

❤️ 4
lilactown22:12:46

created an issue about metadata on functions and typeof: https://dev.clojure.org/jira/browse/CLJS-3018

lilactown22:12:57

hope I’m being helpful 😬 I’d like this to work so I can figure out datafying React elements and components

lilactown23:12:13

OK I have no idea why, but now tests in master don’t run for me 😞

Exception in thread "main" clojure.lang.ExceptionInfo: failed compiling file:/Users/will/Code/clojurescript/src/test/cljs/cljs/npm_deps_test.cljs {:file #object[java.io.File 0x20843604 "/Users/will/Code/clojurescript/src/test/cljs/cljs/npm_deps_test.cljs"], :clojure.error/phase :compilation}, compiling:(/Users/will/Code/clojurescript/bin/../bin/cljsc.clj:22:1)
...
Caused by: clojure.lang.ExceptionInfo: No such namespace: lodash/array, could not locate lodash_SLASH_array.cljs, lodash_SLASH_array.cljc, or JavaScript source providing "lodash/array" (Please check that namespaces with dashes use underscores in the ClojureScript file name) in file /Users/will/Code/clojurescript/src/test/cljs/cljs/npm_deps_test.cljs {:tag :cljs/analysis-error}
going back to previous commits doesn’t remedy this. I tried re-cloning the repo even, same issue

mfikes23:12:50

@lilactown Seeing if I can repro locally... this has happened before, I think owing to a glitch in npm

lilactown23:12:41

$ npm -v
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.61.dylib
  Referenced from: /usr/local/bin/node
  Reason: image not found
[1]    91527 abort      npm -v

lilactown23:12:49

o_O something might be very wrong with my environment

mfikes23:12:15

Yeah, I've had crap like that happen. Are you using brew?

lilactown23:12:10

I am. trying brew upgrade node 🤞

lilactown23:12:36

yepp, that fixed it. bizarre. thanks for the sanity check

mfikes23:12:24

My guess is that lbicu is on version 62 and some other package upgraded it out from under npm ¯\(ツ)