This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-26
Channels
- # adventofcode (2)
- # beginners (69)
- # boot (37)
- # cider (6)
- # clara (31)
- # cljs-dev (75)
- # cljsrn (5)
- # clojure (72)
- # clojure-dev (7)
- # clojure-italy (11)
- # clojure-nl (8)
- # clojure-russia (2)
- # clojure-spec (56)
- # clojure-uk (54)
- # clojure-za (1)
- # clojurescript (156)
- # cursive (2)
- # datomic (34)
- # emacs (1)
- # fulcro (227)
- # hoplon (74)
- # jobs (1)
- # jobs-discuss (16)
- # leiningen (5)
- # lumo (17)
- # off-topic (9)
- # om (3)
- # onyx (10)
- # other-languages (1)
- # portkey (2)
- # re-frame (2)
- # reagent (36)
- # reitit (1)
- # remote-jobs (1)
- # ring-swagger (8)
- # shadow-cljs (85)
- # slack-help (2)
- # spacemacs (6)
- # specter (3)
- # sql (17)
- # test-check (15)
- # tools-deps (80)
Is this a bug?
clojure => (int \z) ;; 122
cljs => (int \z) ;; 0 (warning all arguments must be numbers)
for this to work in cljs int
should do .charCodeAt
on a string
It would be nice if int
were consistent, this appears to be a hosty difference in that, in Java, char
is easily treated as a numeric.
I noticed this today as well. Trouble is that Javascript doesn't distinguish between char and string
Yeah, I would chalk it up as a hosty difference that, if attempted to smooth over, would be at odds with perf.
Plus, what would (int "aa")
return?
(Given that "aa" and \a have the same type)
This doesn't work in Clojure, which is related.
(subvec (into [] (range 256)) \a)
I think it is water under the bridge, but perhaps Clojure's int
should never have worked on character types.That is one of its primary uses, so disagree
(If you take a peek at ClojureScript's subvec
you would see that messing with int
would all of the sudden either make that code start working and/or slow it down.)
Agreed about overall perf impact. Not sure if this should be addressed via type hint?
and defspec
is only used twice in the cljs test suite, and I get the same behavior in chrome and safari, what the heck is defspec
doing
Canary detected an issue with Spector. I'm inclined to believe that Spector is making an unwarranted assumption about vec
and created an issue there https://github.com/nathanmarz/specter/issues/261
Please chime in if you think my view is misplaced.
Those unit tests aren't often executed directly from within a browser. So, unrelated completely to your test result display code.
It is hilarious that js/print
can either mean sense 2a "to make a copy of by impressing paper against an inked printing surface" or 2d: "to display on a surface (such as a computer screen) for viewing" (Merriam Webster)
The issue mentioned above regarding Specter has been fixed downstream https://github.com/nathanmarz/specter/commit/e7abb2b5384b0b64d871fb347be7c34a15473eb2 and Canary is passing again.
@mfikes any background info on why those change was needed? I’d have thought it is equivalent as far as correctness goes.
@U0LK1552A That particular bit of code is being used in a context which extends a protocol to cljs.core/Subvec
. A consequence of the optimization on master (for CLJS-2442) is that vec
directly returns any subvec passed to it. This causes the Specter code to dispatch back to the same extension for cljs.core/Subvec
, and thus leads to infinite recursion. The intent of the Specter code is to convert the subvec to a persistent vector instance (not a subvec of a persistent vector), so into []
suffices to achieve the intent.
TL;DR, types matter to that particular code—with the difference between cljs.core/Subvec
and cljs.core/PersistentVector
being important.
Ah ok. That makes sense. I know specter does a lot of digging at types to try to achieve high performance etc. so it makes sense that kind of edge case could creep in. Thanks for the details.
@mfikes could you help me understand what cljs code this test is compiling? https://github.com/clojure/clojurescript/blob/master/src/test/self/self_host/test.cljs#L141-L153
@ambrosebs It is skipping ClojureScript source compilation and returning "cached" JavaScript associated with the load4.core
macros namespace. (The test is essentially checking that this results in load4.core$macros
being placed in the *loaded*
namespace set.)
I assume it is because I made compiler/emit
error. Perhaps more usefully to me: is a defmethod
on ISeq
enough to dispatch an empty LazySeq to that method in self-hosting?
There's almost definitely some bigger misunderstanding I'm having. I think I've hit a wall in trying to guess what self-hosting will do.
I'm trying to add a :quote
op to the analyzer that gets used on any 'quote
form, then the quoted value becomes a :const
child of the :quote
node. This is my progress so far https://github.com/clojure/clojurescript/commit/d849cbd1d40fca8e5623abdaadb46fc929998f28
and the build failure
https://travis-ci.org/frenchy64/clojurescript/builds/396685198?utm_source=github_status&utm_medium=notification
the github link is only an approximation of the actual built code, I rebased and nerfed the original commit
@ambrosebs One problem is that, the defmethod
s in that revision currently have protocol names in the :cljs
branches, but instead need type names.
But that raises a problem if you need to also catch Subvec
or MapEntry
, or anything else that would satisfy vector?
ah. Are there any examples that I can copy of a defmulti
that dispatches intelligently on any possible CLJS type?
I ran in to that very problem here and ended up with a solution that was "open" because it uses defmulti
but a bit tied to types: https://github.com/planck-repl/planck/blob/master/planck-cljs/src/planck/io.cljs#L388
The ability to do that in this blog post was arguably nice http://blog.fikesfarm.com/posts/2016-01-22-clojurescript-eval.html but I wonder if that aspect is really being used out there
hmm I was going to rename emit-constant
to emit-constant*
and make emit-constant
a function that emits metadata for each constant (then calls the multimethod)
To be honest, I would be surprised if people are extending the compiler with their own defmethods
. Hrm.
ok let's assume it's a non-issue. Is there a better dispatch function for this defmulti
to be compatible with protocols?
perhaps a good compromise is to have a cond for the base types and then default to a multimethod for tagged literals and such
@mfikes do you know what emit-constant
case (or predicate) I can use to handle this constant?
failed compiling constant: [object Object]; function (val){ this.val = val; } is not a valid ClojureScript constant.
these are my changes https://github.com/frenchy64/clojurescript/pull/19/commits/ba0475124317dbcc4f371b84977e96f8be67371c#diff-55b85385d2d0bfb6dc20d59ed982d5c8R247
I wonder what the associated source is. All of these things would involve a quote in the source?
here's the error https://travis-ci.org/frenchy64/clojurescript/builds/397076731#L3773
@ambrosebs If you revise the "not a valid ClojureScript constant" error string slightly to include (pr-str x)
, you will see #object[cljs.tagged-literals.JSValue]
Planck REPL shows
cljs.user=> (require 'cljs.tagged-literals)
nil
cljs.user=> (cljs.tagged-literals/->JSValue 1)
#object[cljs.tagged-literals.JSValue]
cljs.user=> (type *1)
cljs.tagged-literals/JSValue
so it is an open question as to why this isn't dispatching to https://github.com/frenchy64/clojurescript/pull/19/commits/ba0475124317dbcc4f371b84977e96f8be67371c#diff-55b85385d2d0bfb6dc20d59ed982d5c8R386is there a difference between the values #object[cljs.tagged-literals.JSValue]
and cljs.tagged-literals/JSValue
?
@mfikes ha, the tests pass if I hardcode the JSValue instance? test https://github.com/frenchy64/clojurescript/pull/19/commits/1700e648475010e99e13f70da640fe94b7bcf3ea#diff-55b85385d2d0bfb6dc20d59ed982d5c8R253