Fantastic! Thank you!
-John
On Tue, Oct 18, 2016 at 11:49 PM, David Nolen wrote:
> This issue is fixed in master now thanks to Thomas Heller. The performance
> hit is negligible.
>
> Thank you for the report.
>
> David
>
> On Tue, Oct 18, 2016 at 3:45 PM, John Szakmeister
> wrote:
>>
>> On Tue
This issue is fixed in master now thanks to Thomas Heller. The performance
hit is negligible.
Thank you for the report.
David
On Tue, Oct 18, 2016 at 3:45 PM, John Szakmeister
wrote:
> On Tue, Oct 18, 2016 at 5:59 AM, Thomas Heller
> wrote:
> > Don't think there is a best practice for your ca
On Tue, Oct 18, 2016 at 5:59 AM, Thomas Heller wrote:
> Don't think there is a best practice for your case in particular.
Okay. Earlier in the thread you said "while this issue can be very
confusing you will hardly ever run into it when following best
practices." So it seemed to me that perhaps
Just a quick glance makes it look like handlers can be overridden, but I
haven't tried this and I don't think it's documented anywhere:
https://github.com/cognitect/transit-cljs/blob/master/src/cognitect/transit.cljs#L109
On Tue, Oct 18, 2016 at 11:41 AM John Szakmeister
wrote:
> Yes, you could
Yes, you could do that, but it could also do Bad Things. Namely if
you have strings that match some of the format, it could be
misinterpreted as Transit data rather than JSON, so I don't consider
it a particularly useful solution either. It just moves where the
problem can happen. :-( If there w
If you're parsing raw json streams/strings, I think transit claims to be a
30x perf improvement over js/JSON.parse+js->clj:
http://swannodette.github.io/2014/07/26/transit-clojurescript
On Tue, Oct 18, 2016 at 6:41 AM Matching Socks wrote:
> A reliable "implements?" would be better than a fast-a
A reliable "implements?" would be better than a fast-and-sometimes-wrong
"implements?".
With that in mind, have you tried a distinct sentinel object, as opposed to
true?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send
Don't think there is a best practice for your case in particular.
The issue is that js->cli is built on top of protocols to allow converting
custom JS types to CLJS types. Which makes it extensible for the price of
checking protocols. In your case you are converting JSON which cannot have
custo
On Tue, Oct 18, 2016 at 2:59 AM, Thomas Heller wrote:
[snip]
> While this issue can be very confusing you will hardly ever run into it when
> following best practices. As David suggested using a custom js->clj here
> would prevent the issue and is probably the best course of action
> regardless.
Yeah the issue can be quite confusing since the error produced may complain
about protocols you are not even calling anywhere. I've run into it several
times when the code ended up checking protocols on js/window. Since that
has all the munged global variables closure produces just about anythin
I think one reason why these issues are reported infrequently is because it
is really hard to track them down. I can imagine people disable :advanced
optimizations or restructure their code instead of hunting down the real
cause. John went really far to isolate/demonstrate the issue.
Thanks for
FWIW I investigated the check with "true" and a sentinel value and found
them to both have a small performance impact over just checking for a
true-ish property.
http://dev.clojure.org/jira/browse/CLJS-1658
The impact is really small so it might be worth the trade-off.
/thomas
On Sunday, Octo
It's true that there other scenarios where you can encounter this but it
gets reported infrequently enough that I don't think these kinds of
property name collisions are common.
Still it has come up before and I think the simplest solution least likely
to adversely affect performance is to test fo
Unfortunately, this problem is not specific to `js->clj` only.
I believe in general under :advanced optimizations, any object which was
created or modified by a code which
was not subject of the same closure compiler optimization pass could
exhibit similar problems when used with ClojureScript
On Sat, Oct 15, 2016 at 2:49 PM, David Nolen wrote:
> This issue is somewhat to be expected if you're going to use `js->clj`. This
> issue has nothing to do with ClojureScript compiler versions - you just got
> lucky before. Google Closure will collapse properties, but some of these
> collapsed pr
This issue is somewhat to be expected if you're going to use `js->clj`.
This issue has nothing to do with ClojureScript compiler versions - you
just got lucky before. Google Closure will collapse properties, but some of
these collapsed properties are going to be used to determine protocol
membershi
I've been using ClojureScript rather successfully for a year now, but
ran into an interesting issue recently.
I've discovered that js->clj isn't quite working as expected. After
quite a bit of tearing things down and apart, I discovered it was one
of the keys in some JSON data coming back from th
17 matches
Mail list logo
