Hi David,
Not to detract from the Cloact approach but the problem here is having to do
the merge by hand and thus that logic for snapshotting and reinstating will
need to be replicated from application to application. It could be abstracted
away, but this is the type of additional
Hi all, am running ClojureScript 0.0-2156.
With :advanced compilation on, I'm getting:
`js/window.foo_bar` = nil
`(.-foo_bar js/window)` = nil
`(aget js/window foo_bar)` = The string I was expecting.
Is this the correct behaviour? I was expecting the three expressions to always
return the same
Hi Alexander,
That makes complete sense. For some reason I'd incorrectly assumed something
like `.-foo_bar` wouldn't get munged. Will just add an externs def.
Much appreciated! Cheers :-)
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You
Hi all,
Have been seeing `:invalid-arithmetic` compiler warnings recently of the form
WARNING: cljs.core/=, all arguments must be numbers, got [number #{nil
clj-nil}], etc.
This is a handy idea, but it seems the type inference (?) that's going on still
has some kinks to work out (?) since I
Thanks for the response David.
You can suppress this warning like anything other warning.
Sorry, I'm not sure what the suggested method of suppressing any warning is. Is
there a doc on this somewhere - search isn't turning up anything? I see there's
a dynamic `*cljs-warnings*` var in
Ah sorry I thought this was exposed in some way. :warnings as a
compiler option is now exposed in master.
Great, will take a look - thanks!
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to
Thanks Herwig, Francis - appreciate the assistance!
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving
Hi there,
Am running Clojure 1.7.0-beta1, ClojureScript 0.0-3196.
Just noticed:
(hash 1) ; 1, ClojureScript
(hash 1 ) ; 1392991556, Clojure
(.hashCode 1) ; 1, Clojure
i.e. numeric hashes aren't consistent between Clojure and ClojureScript.
I'm assuming that's intentional?
This got me
Hi folks,
Running ClojureScript 1.7.28 - just ran into some unexpected behaviour:
(aget nil foo) throws an error; was expecting it to return nil.
This also leads to (aget obj foo bar) throwing when obj doesn't have a
foo property. Was expecting that to return nil too.
Is this behaviour
Interesting, was under the impression that `aget` was initially encouraged for
property access, or am I mistaken?
Have certainly seen a lot of `aget` property access in the wild. May I ask what
the disadvantage is?
Will start migrating stuff on my end, thanks for the input!
--
Note that
@Shaun: would be easy enough to get `nil` safety via `aget` though?:
(defn aget
([array i] (when-let [a array] (cljs.core/aget a i)))
([array i idxs] (apply aget (aget array i) idxs)))
Just wondering what the rationale is for discouraging this since it seems (?)
to work in practice far as
Thanks David,
Any particular argument against extending `get` to objects using
`goog.object/get` by default?
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
Yes performance. We not adding any more cases to `get`.
`get`'s implemented with `cond` - adding an object case after other conditions
(before `:else nil`) wouldn't affect performance in any real way, would it?
Is object property access not a pretty common occurrence?
--
Note that posts from
There is no simple test for plain objects, `typeof x` will return `object`
for many things. only `foo.constructor === Object` is going to work. This is
not as fast as it would seem.
The test would be slow, but the cost only incurred when `get` is called on
something that's:
not nil, not an
If you have to fall through so many cases to get to the Object case why would
you not just use `goog.object/get`?
So the concern isn't a performance regression against current uses of `get`,
but about `get` being inefficient relative to plain `goog.object/get` for
objects - is that correct?
No. You're still damaging anyone in the final cases - native extenders and
those who just fall completely through.
Native extenders would go through `native-satisfies?`, no? The object extension
I'm suggesting would happen after that.
About those that just fall completely through, not sure -
An alternative modelled after `aget` that's simpler + faster:
(defn oget Like `aget` for JS objects.
[o k] (when o (gobj/get o k nil))
[o k1 k2] (when-let [o (oget o k1)] (gobj/get o k2 nil)) ; Optimized common
case
[o k1 k2 ks] (when-let [o (oget o k1 k2)] (apply oget o ks))) ; Can also
native-satisifes? must come last due to `default` case.
Okay, gotcha! I wasn't aware of this, thanks for the explanation.
So the concern with extending `get` to objects actually _is_ a global
regression: there's no way of avoiding a hit to anything relying on
`native-satisfies?`, is that
We are not adding any new functions for dealing with objects. Use goog.object.
Judging by the number of people I've seen reach for `aget` out of convenience,
I might suggest that object property access is a common enough use case to be
worth at least considering a sanctioned util for?
Nested
Thanks for the input Thomas, Daniel!
Have ruled out dep conflicts, and only have a single extern that I've had
around for forever (jquery).
Next step might be a bisect, but honestly not urgent enough to go to the effort
- especially if (as it looks) I might be the only one experiencing a
Quick update to confirm that the newly released ClojureScript 1.9.293 appears
to resolve these compiler issue for me.
Cheers!
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google
Hi all,
Was wondering if anyone might be familiar with the reason for some unexpected
behaviour I'm seeing?
(extend-type js/jQuery
ILookup
(-lookup
([this k] nil)
([this k not-found] nil))
IFn
(-invoke
([this k] (-lookup this k))
([this k not-found] (-lookup this k
Hi there!
Would anyone possibly know where to start debugging this?
I have a large codebase that compiles fine with ClojureScript <= 1.8.40.
Starting from ClojureScript 1.8.51 (that is 1.8.51, 1.9.14, 1.9.76) I see:
java.lang.RuntimeException: INTERNAL COMPILER ERROR.
Please report this
Hi David, thanks a lot for the quick reply!
Tried sampling a few newer + older versions of
`com.google.javascript/closure-compiler` against ClojureScript 1.9.75 without
much luck:
v20160713 - No matching ctor found for class
com.google.javascript.jscomp.ES6ModuleLoader
v20160619 - No matching
Hi folks!
So this is the 1st of 4 libs I’ve been meaning to publish for forever.
Available at: https://github.com/ptaoussanis/tempura
Other libs (as usual) at: https://www.taoensso.com/clojure
Enjoy, cheers! :-)
\- Peter Taoussanis, [@ptaoussanis](https://twitter.com/ptaoussanis)
--
Note
Hi folks!
So this is the 2nd of 4 libs I’ve been meaning to publish for forever.
Available at: https://github.com/ptaoussanis/tengen
Other libs (as usual) at: https://www.taoensso.com/clojure
Release announcements on Twitter: https://twitter.com/ptaoussanis
Enjoy, cheers! :-)
- Peter
26 matches
Mail list logo
