Clojurians Log v2

maybe advance the reader til it reaches \[, then pass it to cheshire parsed-seq? hopefully will stop parsing at the \] and ignore the rest of the buffer

👋 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?

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))

@holyjak you can use tagged-literal

also see https://insideclojure.org/2018/06/21/tagged-literal/

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

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")

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

(keyword "")

they will be unreadable essentially

(keyword "" "")
=> :/

it can get weird fast

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

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.

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?

You can test this using clojure.spec.gen.alpha :)

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

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"]}

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?

Maybe the cider debugger?

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?

i'm not aware of any debugger for cljs. Cursive and CIDER each only support Clojure as far as I am aware

@meditans You can use https://github.com/jpmonettas/flow-storm-debugger

It is editor agnostic.