This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-08
Channels
- # adventofcode (55)
- # announcements (21)
- # babashka (20)
- # beginners (89)
- # calva (21)
- # cider (16)
- # circleci (11)
- # clara (8)
- # clj-kondo (6)
- # clojure (31)
- # clojure-australia (3)
- # clojure-europe (17)
- # clojure-nl (5)
- # clojure-uk (10)
- # clojurescript (25)
- # community-development (4)
- # conjure (12)
- # cryogen (28)
- # cursive (21)
- # datomic (7)
- # deps-new (1)
- # depstar (45)
- # emacs (5)
- # fulcro (46)
- # instaparse (5)
- # jobs (5)
- # jobs-discuss (23)
- # kaocha (12)
- # lambdaisland (2)
- # leiningen (1)
- # meander (10)
- # mid-cities-meetup (1)
- # reagent (5)
- # reitit (5)
- # remote-jobs (45)
- # reveal (9)
- # sql (6)
- # tools-deps (103)
- # uncomplicate (1)
- # xtdb (1)
👋 https://github.com/clojure/data.xml has been on 0.2.0-alpha6 for over 2 years, with the latest stable being 0.0.8, yet https://github.com/cognitect-labs/aws-api is itself stable and https://clojurians-log.clojureverse.org/aws/2020-03-15 with 0.0.8 and requires 0.2.0-alpha6 instead. Is there anything preventing the rollout of a 1.0 version of org.clojure/data.xml @alexmiller?
To be honest, I don’t know. data.xml is run by Herwig. I’ve asked him this question a couple times and have not gotten an answer. It was originally alpha because of the namespace mapping approach I believe. I can certainly ask again :)
:thinking_face: Actually there’s a rather big breaking change between the 2 versions as clojure.data.xml.Element isn’t there anymore in 0.1.0 as it’s been moved to clojure.data.xml.node. Since we’re using both cognitect/aws-api and circleci.tests (https://github.com/circleci/circleci.test/blob/master/src/circleci/test/report/junit.clj#L6), I’m kinda stuck 😢. I’ll have to move away from circleci.test I reckon.
I have not looked at that. doing a quick skim, seems like users of data.xml are pretty split on 0.0.x and 0.2.0-alphaY
Even the default behaviour of clojure.data.xml/parse-str in both versions is different. They should be different libraries at that point so that both could coexist.
clj -Sdeps '{:deps {org.clojure/data.xml {:mvn/version "0.0.8"}}}'
Clojure 1.10.1
user=> (require '[clojure.data.xml])
nil
user=> (clojure.data.xml/parse-str "<tag1>\n <tag2>bar</tag2>\n</tag1>")
#clojure.data.xml.Element{:tag :tag1, :attrs {}, :content (#clojure.data.xml.Element{:tag :tag2, :attrs {}, :content ("bar")})}clj -Sdeps '{:deps {org.clojure/data.xml {:mvn/version "0.2.0-alpha6"}}}'
Clojure 1.10.1
user=> (require '[clojure.data.xml])
nil
user=> (clojure.data.xml/parse-str "<tag1>\n <tag2>bar</tag2>\n</tag1>")
#xml/element{:tag :tag1, :content ["\n " #xml/element{:tag :tag2, :content ["bar"]} "\n"]}Hello! How can I require a namespace with unknown tagged literal (`#uknown-tagged-literal` in this case)? I have tried
(binding [*default-data-reader-fn* (fn [tag value] nil)]
(require namespace))Thanks a lot, that fixed it! I guess my problem was that my *default-data-reader-fn* returned nil , perhaps it must return something non-nil not to fail downstream.
Thanks a lot, that fixed it! I guess my problem was that my *default-data-reader-fn* returned nil , perhaps it must return something non-nil not to fail downstream.
Hello! Are there any forbidden characters inside a keyword?
I tried to convert a string with special chars and hebrew chars and I couldn’t make the keyword function fails
(keyword "aa/bbשלום/dd.dd/a:::$$$ :a")officially, from the reader reference the allowed set is "alphanumeric characters and *, +, !, -, _, ', ?, <, > and =". Hebrew chars would imo fall under "alphanumeric". / and : have special constraints that are further elaborated on in the text.
Thank you for the detailed clarification
yes, the reader has some rules (https://clojure.org/reference/reader) but it's not all enforced, but you'll get broken behavior if you do not respect them in some cases
I have no intended plan to break the rules but I am willing to use https://github.com/tolitius/cbass#finding-by-the-row-key for retrieving value on HBase.
cbass find-by functions automatically keywordize column names.
I am asking myself if it could break in some edge cases
programmatically created keyword objects are fine and useful for things like these - you get into trouble when you venture into print/read roundtripping
if that's a thing you expect to do, you should use strings instead
Thanks for the clarification
So basically any string could be programmatically converted to a keyword?
If I'm not mistaken, a keyword is interned using a symbol and that in turn is represented by strings internally: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Symbol.java#L20-L21 So I think it should work for all strings.
Thank you @borkdude
some time ago I saw on youtube someone using an emacs setup to step into a function so that the result of each form was printed as he went along (for debugging). Do you know what that could have been?
yes, that was probably it, although it doesn't seem to work with clojurescript https://github.com/clojure-emacs/cider/issues/1416 is there an alternative for clojurescript?