This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-29
Channels
- # beginners (41)
- # cider (2)
- # cljs-dev (5)
- # cljsrn (16)
- # clojure (157)
- # clojure-russia (29)
- # clojure-uk (1)
- # clojurescript (164)
- # code-reviews (7)
- # cursive (3)
- # datavis (7)
- # datomic (1)
- # emacs (16)
- # hoplon (2)
- # ldnclj (1)
- # off-topic (4)
- # om (167)
- # other-lisps (10)
- # overtone (8)
- # parinfer (1)
- # re-frame (19)
- # testing (2)
@jaredly: I'd suggest you start with this brilliant bit of work: http://shaunlebron.github.io/t3tr0s-slides/#0 (a step by step guide to building Tetris in cljs). Code: https://github.com/shaunlebron/t3tr0s-slides
Yes, @eyelidlessness, I’ve added (def f (fn x [] #'f))
to CLJS-1495
I'm puzzled by exists?
. At the REPL this works:
cljs.user=> (exists? js/window)
true
But this is odd:
cljs.user=> exists?
WARNING: Use of undeclared Var cljs.core/exists? at line 1 <cljs repl>
nil
It is used in https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs but never defined.Where does it come from?
@mikethompson: it is a macro: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/core.cljc
@darwin: of course. Thanks!
why might one of my Om components not get IDidUpdate called ?
(the others do, but one of them doesn't)
@octo221: did you put logging inside render function? is it really being re-rendered by Om?
yes, IRender is being called
(render [this] I mean)
isn’t its parent being re-rerendered as well and discarding it as a child somehow? or isn’t it rendering nil or empty value? just wild guesses
ok cheers for the ideas
hey child components in general don't seem to get did-update called
apparently this Chrome plugin has been written in clojurescript. http://lifehacker.com/relevance-reorganizes-tabs-based-on-what-youve-read-1744584661?utm_campaign=socialflow_lifehacker_twitter&utm_source=lifehacker_twitter&utm_medium=socialflow
@borkdude: I believe it is using khroma library: https://github.com/suprematic/khroma, both lib and extension written by @ricardo
@borkdude: well, I was asking because, just recently I have been working on a similar library mine also covers APIs for chrome apps now: https://github.com/binaryage/chromex/
still an early version, want to see some real usage (except for my own extensions) to iron out remaining problems
@borkdude: @darwin is correct, it uses Khroma. His ChromeX is a pretty neat approach, too.
If nothing else, easier to maintain than having a random human make assorted, not-necessarily-consistent decisions about how to expose a particular API when he needs it. 😛
@darwin: I see you removed your “don’t use this because it’ll kick your pets” warning. Do you expect the API is more stable? Are you planning to add some extension-specific tests?
big credit goes to Google developers who were so disciplined to provide automated way how index their APIs, according to my stats there is 1000+ functions in their public apis right now, zero chance anyone could cover them manually
@ricardo: I just started building my own real extension on top of it, I don’t know about any limitations right now
I don’t plan extension-specific tests, that’s Google’s job I mock simple extension apis in my tests and test just my wrappers, also I want to automate it and extension code is much harder to test automatically
I merged it into the main khroma
repo. This has got me thinking I should just release it to 0.3.0 as is, so that people don’t have to look at two repositories. Going to do that now
I will have one example project which I will maintain, there will be a “test” button to run quick battery of simple tests, but I will just use it for ad-hoc testing
btw. here is my quick chrome API mock, seems to be ok, for simple tests for my wrappers: https://github.com/binaryage/chromex/blob/master/test/chromex/test/playground.cljs#L15-L62
@ricardo: as API stability, I don’t know, conceptually the api won’t change I think, but I cannot guarantee it at this point
To me it’s less about making sure that extensions still work and more about making sure the way I expose them is consistent with what people are expecting from before.
that is why I’m trying to spread a word early and get some people on board with their extensions-in-development, so we can discover issues early and stabilise the interface
@borkdude: If you’re looking into getting acquainted with a Clojureic way to access the API, check out the khroma
tests.
This returns true with advanced compilation and false without (or with :pseudo-names):
(seq? (google.maps.LatLngBounds. (google.maps.LatLng. 1 2) (google.maps.LatLng. 3 4)))
Any ideas why it would return true? Some kind of name collision?
@henriklundahl: did you test the name collision theory by using a closure around your code?
@dnolen: Nope. Will try.
@dnolen: I get the same result with :output-wrapper true
...
it’s possible it’s an advanced optimization bug, I’ve certainly seen those now and then
The thing is I'm trying to use js->clj
on the results from the Google Maps geocoder, where LatLngBounds
are among the values.
...and seq?
is used in js->clj
.
@henriklundahl: yeah so I suspect that under advanced the protocol gets renamed to a property that the google map object has
no good answer is coming to mind other than write your own js->clj
that doesn’t have the seq?
or coll?
cases
I don’t really think it should have them, but I think these were added as convenience back in the old days
should maybe revisit that but would need to determine how much breakage it would cause
@dnolen: But couldn't something be done about the name collisions (if that is what is happening)? Feels like anything can happen if functions or properties are overwritten?
@henriklundahl: I got burnt by this http://dev.clojure.org/jira/browse/CLJS-1249
if you have an instance of the same issue, then Google Closure Compiler does not connect access to .-lat
nad .-lng
properties (for reading) with access to them (for writing), and removes them in some cases (for example in LatLng.
constructor), that leads to .equals
return true when comparing both constructed objects, because it compares undefined values, … just a theory
@henriklundahl: try to build a minimal repro case and we can try to reason about what happened there^
@henriklundahl: you can’t do anything about these kinds of name collisions in JavaScript period
@darwin: I think there aren't any usable properties in LatLngBounds
or LatLng
so I wouldn't expect js->clj
to do anything with them, which is what happens without advanced compilation.
@thheller: Google Maps API.
@dnolen: Sure, but there are some steps before we end up with the same names...
I'm using these: https://raw.githubusercontent.com/google/closure-compiler/master/contrib/externs/maps/google_maps_api_v3_22.js
@henriklundahl: this just isn’t how Google Closure works
you are using a foreign library that Google Closure doesn’t know about, there’s no way to know that names won’t clash
@henriklundahl: if you don’t want to monkey-patch js->clj
then providing this information is another route
@dnolen: You mean what's missing in the externs?
But couldn't the names of those properties change at any time?
I guess not.
But can you help me understand, what's (probably) happening?
How can those private properties munge anything?
A) ClojureScript uses properties to know what types belong to which protocols (since there are no interfaces in JavaScript)
C) You are using a 3rd party library with properties the Closure Compiler does not know about and not providing externs to cover you
interesting problem though that the renamed property contain exactly the value required to make it look like a cljs seq
thinking about it some more Google Maps is probably the worst case scenario - since I suspect they don’t allow you to build from source and the thing you get is already advanced compiled
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/core.cljc#L1960
@dnolen: Ok, I understand, thanks. It does feel quite brittle as it is now...
You're right about Google Maps.
@henriklundahl: this is the first time anyone has ever reported this issue in 4 years
we’ve had more bug reports about real bugs in the Google Closure compiler than challenging name clash edge cases like this
@henriklundahl: if you just want to pass data to the google maps api and don't need to work on it in cljs you can use the #js {}
reader literal stuff to directly construct js objects instead of closure maps
Ok then. 😉
@thheller: Yeah, I know and I do when it's possible. This time it's the other way around (js->clj), though.
@dnolen: So I guess there aren't many other situations that CLJS handles in a similar way?
@henriklundahl: this really just doesn’t come up that often
this particularly bad interaction is because you have 2 Closure advanced builds compiled separately
Yeah, I know, but are there other places in the CLJS codebase that relies on object properties in a similar fashion?
Would it be possible to take the whole Google Maps API and put that as an extern?
@henriklundahl: you could try that but that doesn’t sound like a good idea to me
Ok, sure, but I'm just worried that other things suddenly start breaking...
you have so many better helpers for dealing with foreign data in ClojureScript and Closure I really don’t know why people bother
Ok, I guess there aren't many places in my code where I'm dealing with Google Maps objects and when I do I don't use any CLJS functions, except in this case.
So I guess I shouldn't worry.
Thanks!
@mfikes: thanks for your follow ups wrt re-defining a function! The solution with the ns-qualified var works great! And good work on the issue report
@grav: Looks like we are coming up on a year of having var
. Interestingly, perhaps the first commit refers to shadowing https://github.com/clojure/clojurescript/commit/91153fa7d26f55cc466ac1d24184ba78bac7cf72
I'm trying to pull an item from a set. The item in the set has metadata, but when I use get, it seems like get returns the lookup value I used, and not the item actually in the set...anyone have ideas?
Maps themselves are fine: (meta (get {[1] [1] [2] [2] [3] (with-meta [3] {:k 1})} [3]))
I’m trying to use goog.async.Debouncer
http://google.github.io/closure-library/api/source/closure/goog/async/debouncer.js.src.html
But when I do (:import goog.async.Debouncer)
, I get a no such namespace
exception.
@roberto that file is pretty new, good chance it isn't in the closure release that is used by clojurescript
does clojurescript have an index-of function where I can get the position of an item in a list? In clojure proper, we call out to java, but best I can do it seems is convert the list to a js array first then use .indexOf on it.