This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (79)
- # bangalore-clj (3)
- # beginners (49)
- # boot (74)
- # cider (10)
- # cljs-dev (21)
- # cljsrn (2)
- # clojure (105)
- # clojure-berlin (1)
- # clojure-brasil (1)
- # clojure-dusseldorf (1)
- # clojure-korea (1)
- # clojure-poland (3)
- # clojure-russia (38)
- # clojure-spec (146)
- # clojure-uk (20)
- # clojurescript (70)
- # cloverage (1)
- # component (1)
- # core-async (23)
- # css (16)
- # cursive (22)
- # datascript (1)
- # datomic (22)
- # defnpodcast (6)
- # emacs (60)
- # events (1)
- # hoplon (94)
- # jobs (1)
- # jobs-rus (13)
- # luminus (11)
- # off-topic (11)
- # om (48)
- # onyx (5)
- # proton (7)
- # re-frame (87)
- # reagent (39)
- # rethinkdb (1)
- # ring-swagger (14)
- # rum (6)
- # specter (14)
- # untangled (105)
- # vim (6)
- # yada (22)
I was trying to get my head around records and defprotocol, is it possible to define operators like + - for the new types?
@jacoelho those operations aren't part of a protocol. You might be able to do something by implementing your own subclass of java.lang.Number
@jacoelho I think it's either impossible or has serious drawbacks, otherwise core.matrix would use this technique
if you're running on Node, everything that's available in Node is available to cljs
I'm just reading a book here and I see older version of core.async then I went on github to find out core.async is using clojure 1.6.0
core.async is compatible with later versions of Clojure. The version a library "depends" usually just indicates how far back it offers support.
As of the start of 2016, about 20% of users were still on Clojure 1.6 http://blog.cognitect.com/blog/2016/1/28/state-of-clojure-2015-survey-results#clj
I expect that’s shifted now to most folks being on 1.8.0 (nearly a year later) and some of us already have 1.9.0 Alpha builds in production.
yeah but when you see the library including a version like 1.5.1 or 1.6.0 doesn't it make you wonder if it's compatible with latest ?
Most of the Contrib libraries have a CI matrix of versions, e.g., http://build.clojure.org/job/java.data-test-matrix/
(core.async doesn’t, but it’s an interesting beast from a testing point of view)
And if you look at core.async’s Change Log you can see the latest version included a bug fix for Clojure 1.9 so you can tell it’s tested against that https://github.com/clojure/core.async#changelog
So, no, seeing an "old" version of Clojure in a library that has active commits and ongoing maintenance doesn’t make me wonder if it’s compatible with latest — it just gives me confidence that they’re still supporting older versions as well.
core.async is very heavily used so a lack of compatibility with recent Clojure builds would be a "Big Deal(tm)"...
I reckon most people would use
clojure.data.xml to parse the xml into persistent data structures and probably
cheshire to emit json from the persistent data structures
You got the same answer last time. I said to go XML -> Clojure data structures -> JSON.
And that’s partly because there are several possible JSON interpretations for any given XML structure / format so you can’t really expect to go automatically straight from XML to JSON — you need to interpret how the XML is structured (in a data structure) first.
clojure.data.xml to parse the XML and probably
clojure.data.json to produce JSON — both are Contrib libraries — but Cheshire is a more capable (and faster) JSON parsing/emitting library.
In the middle, you’ll have to massage the Clojure representation of the raw XML into a structure that suits whatever JSON purpose you have downstream.
As an example
<a b="42"><c>something</c><d e="x"/><f g="y"><h/></f></a> — how would you represent a mixture of attributes and nested data in general in JSON? There are several possibilities.
what do the numbers mean in
:message "java.lang.RuntimeException: Map literal must contain an even number of forms, compiling:(res/jobs/current_value.clj:16:89)”
i assume one indicates the line number