Fork me on GitHub

Why do equality checks on vectors appear to not short-circuit? The following does not terminate:

(= [1] (range))
In general it looks like any seqs on the RHS are traversed entirely, compared to (= '(1) (range)) or (= (range) [1]) which return false immediately. The Java source for APersistentVector looks correct, returning false on the first non-equal element or end of vector, so I'm not sure where this comes from.


props to @U1NDXLDUG for noticing that


But that's only in the obj instanceof IPersistentVector branch which shouldn't be the case for the range seq?


you could consider filing a bug, but I'm not sure there's a good fix. the fast path that uses vector size is pretty important in general


oh right - that's Java's List type, I read it automatically as clojure's (list? obj) I'll post this on then. I actually found this out by profiling a slow path in my code which was comparing small vectors to large partially realized seqs, but I guess there are optimization tradeoffs for treating lazy seqs specially

👍 1

The underlying problem is that we don't have an O(1) count function for Clojure. count is O(N) or faster.


I don't think that's right, the issue is that the Java List interface doesn't come with performance guarantees, so the 'optimized' branch with obj instanceof List ends up being worse when the collection happens to have an expensive .size() method.


That's fair.


With has anyone seen thaw failed against type-id: 102 / 112 errors (which are :long-lg and :map-sm according to the nippy source) when moving the nippy file to one machine to another? It doesn't seem like the file is corrupted, it still works on the original machine

👀 1
Noah Bogart19:10:38

@alexmiller is there any particular reason for the lack of progress on a formal specification for

Alex Miller (Clojure team)19:10:29

That is the specification


i think it might be about this? > Currently this specification is casual, as we gather feedback from implementors. A more rigorous e.g. BNF will follow.

☝️ 1
Noah Bogart19:10:34

a fair number of open questions in the github issues, disagreements about what is or is not conforming (no mention of NaN but since 1.9 clojure has ##NaN, no mention of ratios in the spec but the reader will produce valid clojure ratios, etc)

Alex Miller (Clojure team)22:10:37

What's in the edn spec is edn. Some languages may do more (like Clojure). The best place to file issues is on the edn repo (or ask Clojure)

Noah Bogart23:10:33

Would it be helpful to tag you or someone else in various issues?

Noah Bogart23:10:59

I'm asking cuz the repo hasn't had a commit in 7 years and no one at Cognitect has responded to any issues since then

Noah Bogart23:10:13

I am worried this is coming across as critical. I don't mean to be. More that I would like to see progress and am willing to put in work to help achieve that progress of this is something y'all are interested in

Alex Miller (Clojure team)23:10:15

Well that was the last time we did a round of feedback :)

Noah Bogart19:10:48

i know some things are hard to resolve, like the difference between the built-in function keyword accepting non-conforming strings and producing “invalid” keywords (`(keyword "1 2 3")` produces “:1 2 3”) vs what would ideally be a valid keyword, but it does make it hard for developing libraries for edn in other languages

Alexander Bukata21:10:04

Hi, I'm struggling with and writer I try to set up custom buffer-size. According to docs I can pass :buffer-size to the opts, but this is not working

(defn private-field [obj fn-name-string]
  (let [m (.. obj getClass (getDeclaredField fn-name-string))]
    (. m (setAccessible true))
    (. m (get obj))))

(def rdr (io/writer "file.out" :buffer-size 20240))
(class rdr) =>
(count (private-field rdr "cb")) => 8192
I can create BufferedReader/Writer directly, but using wrapper is more convinient way "cb" is an internal field for buffer in BufferedReader/Writer Do I do something wrong?

Linus Ericsson23:10:19

The implementation for BufferedWriter ignore options entirely. I don't know the reason for this, maybe it is just an oversight. Since it is a protocol you can replace that extension with something that honours the :buffer-size option.


What is Clojure's preferred 'binary' edn, for when you need to communicate large amounts of data with other languages ?


This is the only one I've seen:

Alex Miller (Clojure team)22:10:00

Depending on the language, Transit


Does work? If not, what are the weaknesses ?


Transit, likely. Its the only one i know that is semi-widely implemented


I think the "between other languages bit" disqualifies fressian somewhat - i don't know of any implementations in other things


If you give up on "quick and easy 1-1 with EDN", then you are shopping around with stuff like CBOR, XML, protobuf, parquet, etc depending on the tradeoffs you want to make


I’ve enjoyed using for a variety of things


it depends if the language you want to communicate with are dynamically or statically typed: if dynamic, msgpack, cbor are good choices. If static, something like flatbuffers, protobuf or avro might be preferable