This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-10
Channels
- # announcements (15)
- # bangalore-clj (1)
- # beginners (207)
- # calva (22)
- # cider (4)
- # clara (73)
- # cljs-dev (7)
- # cljsrn (4)
- # clojure (125)
- # clojure-dev (38)
- # clojure-europe (2)
- # clojure-india (11)
- # clojure-italy (11)
- # clojure-nl (14)
- # clojure-russia (22)
- # clojure-uk (32)
- # clojurescript (30)
- # cursive (11)
- # datavis (2)
- # datomic (14)
- # editors (3)
- # emacs (3)
- # hyperfiddle (4)
- # juxt (13)
- # klipse (1)
- # luminus (5)
- # nrepl (7)
- # off-topic (9)
- # overtone (13)
- # portkey (1)
- # re-frame (15)
- # reagent (13)
- # ring (30)
- # schema (4)
- # shadow-cljs (108)
- # spacemacs (8)
- # specter (3)
- # sql (2)
- # testing (11)
- # tools-deps (21)
- # unrepl (4)
I just came across https://dev.clojure.org/jira/browse/CLJ-2464 and was wondering, if one were to create a patch for this. Would the correct implementation be to let PersistentVector$TransientVector
implement IPersistenStack
, and then implement both peek
and pop
for PersistentVector$TransientVector
?
It may not be trivial to fix without significantly changing the class hierarchy. There is at least one other similar ticket in the system that has a similar feel.
I don’t have time to boot all that context into memory right now
Ran across an interesting exception and had me wondering a bit here. Exception was of the form:
java.lang.IllegalArgumentException: find not supported on type: my.ns.RecordType$reify__26254
This was from a callsite looking like this (find (:x (->my.ns.RecordType)) :y)
The (:x (->my.ns.RecordType))
is a keyword callsite, I think it is being optimized via the KeywordLookupSite logic.
This is one of the only places on the record def I’d see a “reify inner class” - coming from the defrecord
impl of clojure.core/getLookupThunk
This looks like this
(clojure.core/reify
clojure.lang.ILookupThunk
(clojure.core/get
[thunk gtarget]
(if
(clojure.core/identical? (clojure.core/class gtarget) gclass)
(. gtarget -x)
thunk)))
Maybe because (clojure.core/identical? (clojure.core/class gtarget) gclass)
is false?
returning the thunk
is pretty different than returning the target object I’d think, so the things get
returns is odd. I guess it is checked by the caller with an identical?
check prob
maybe you reloaded the code and have a record instance from an old version of the record class?
I’m just guessing, have never looked at this code
it Just Works :)
it’s fine, I’ll dig more at things. and yeah, certainly could just be classloader problems.
looking at that code you posted, it looks wrong
or rather the branches look inconsistent in what they return
doesn’t it seem like the thunk should be invoked at the end?
(thunk)
instead of thunk
?
if it’s not invoked it returns the thunk and that seems to match the error you get
IIRC returning the thunk itself is a sentinel value that means that the inline cache is wrong
ah, that rings a bell
The exception I’m getting is odd. Makes me think find
ends up trying to be called on the thunk itself
that’s exactly what it looks like
I’d expect the inner thunk detail to be transparent. But who knows. Maybe I’ll be able to recreate something here enough to dig through.
can’t say I’ve seen anything like it before