This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # ai (35)
- # announcements (3)
- # babashka (16)
- # babashka-sci-dev (2)
- # beginners (37)
- # biff (16)
- # calva (5)
- # cider (2)
- # clj-commons (81)
- # clj-kondo (29)
- # cljfx (2)
- # cljs-dev (4)
- # clojars (4)
- # clojure (92)
- # clojure-europe (72)
- # clojure-losangeles (8)
- # clojure-nl (1)
- # clojure-norway (10)
- # clojure-uk (1)
- # clojurescript (20)
- # clojutre (2)
- # conjure (2)
- # data-science (18)
- # datomic (1)
- # emacs (10)
- # fulcro (49)
- # joyride (1)
- # kaocha (23)
- # leiningen (8)
- # lsp (14)
- # meander (5)
- # off-topic (93)
- # polylith (4)
- # re-frame (20)
- # reagent (9)
- # reitit (2)
- # remote-jobs (8)
- # sci (1)
- # shadow-cljs (21)
- # testing (3)
- # vim (27)
- # xtdb (35)
@slipset I think think gpg stuff is your work right? ;) https://app.circleci.com/pipelines/github/clj-commons/clj-yaml/59/workflows/0e18b069-0bae-4cb8-bd61-42e01c30ed36/jobs/75
@slipset I hate YAML, but I do care about the quality of clj-yaml because it is part of #babashka. Would you mind if I added myself to CODEOWNERS or would you rather review/merge PRs on your own, now that @marc-omorainis no longer very active in the Clojure community? Perhaps @lee is also open to this as a helpful companion.
I also hate YAML 😅 I think Circle uses it because Travis uses it, because Rails uses it.
Thanks! ❤️ I've given you admin access and added you to https://github.com/clj-commons/clj-yaml/blob/master/.github/CODEOWNERS
I find YAML annoying too. I tend to struggle when I have to use it but never really read any details about it. Thus thread just lead me to google which lead me to learn that you can use node anchors in YAML. Huh!
@lee That's the thing: we could "fix" this in the clj-yaml lib. So the dilemma is: follow the (crazy) YAML 1.1 spec or protect people from this breaking change
I submitted a patch to fix a NPE in SnakeYaml a few years back. He accepted the patch and said a new version would be released in 6 months time.
http://yaml.org lists other java implementations:
I see some discussion of SnakeYAML Engine... perhaps other projects are good and also more pleasant to work with?
Java: - SnakeYAML Engine # Java 8+ / YAML 1.2 - SnakeYAML # Java 5 / YAML 1.1 - YamlBeans # To/from JavaBeans. YAML 1.0/1.1 - eo-yaml # YAML 1.2 for Java 8. Packaged as a Module (Java 9+) - Chronicle-Wire # Java Implementation
sure, but clj-yaml is built on snakeyaml, you can't easily change that. maybe we're able to get away with moving to snakeyml engine, don't know
Ok, ramping up on yaml octals.... https://www.infoworld.com/article/3669238/7-yaml-gotchas-to-avoidand-how-to-avoid-them.html#toc-4
of course, what did you expect, backwards compatibility with a minor version number update?
The changes might be for the better in 1.2 though and I don't think it will affect many programs: https://yaml.readthedocs.io/en/latest/pyyaml.html#defaulting-to-yaml-1-2-support
I can ramp up on this issue if that helps. At the very least we'd have one more person who has a better understanding.
@lee yes please! My preliminary proposal was to add an option to control the weird octal parsing
> Wouldn’t you be too if your hobby was to maintain a YAML parser? This made me snort.
(see https://bitbucket.org/snakeyaml/snakeyaml/issues/550/regressing-in-handling-number-like-strings#comment-64102182 for the sad, sad details)
@U0EHU1800 I spent a fair bit of time looking at this today. https://github.com/clj-commons/clj-yaml/issues/35#issuecomment-1248444895 https://github.com/clj-commons/clj-yaml/issues/35#issuecomment-1248656393
cheers. this whole thing is hateful, so I appreciate the diligence and attention to detail.
(I think gmail broke for me, so I'm no longer receiving email updates to all of this wonderful discussion, so thanks for pointing me to these updates)
Don’t think so. My current understanding is that we could create a custom resolver to ignore octals. Have not tried it yet, I guess they would default to strings.
For my really limited use-case, I'm dumping values via snakeyaml/clj-yaml/babashka (YAML 1.1) and reading them using js-yaml (YAML 1.2) (in CDK). One of our AWS accounts has a leading zero. AWS account ids are number-like strings, so that one with a leading 0 is being emitted without quotes by clj-yaml and being read as a number in js-yaml, dropping the 0 (and being a number)
Hmm… that was a nasty booboo with the octals in yaml 1.1 spec. And breaking change in yaml 1.2 spec.
Yeah. Rich's Spec-u-lation talk really crystalized so much of those ideas for me back in the day. Hard for me to see things any other way at this point. Well, I can see it, I just can't bring myself to agree that it's a good idea to have breaking changes.
I'm cautiously optimistic. I don't see any indication that any PR wouldn't be rejected outright based on principle that things are just find as they currently are in 1.30, but then again I don't see any indication that it necessarily would be either. I can't tell whether he's sympathetic to any of the arguments I put forward.
So, now the question for me is whether to put the time in to learn the snakeyaml code well enough to make a reasonable PR. My immediate use-case can be avoided by switching to json. I do think it's a regression in the upstream library so ideally I'd provide the fix there for The Good of All™ (😆).
Good point re: release cycle and fixing it for now. I was trying to figure out how that would be done in clj-yaml. I'm not sure how to override the provided emitter behavior. Maybe override the representer? I was looking a bit last night and it wasn't immediately obvious.
Yeah, but it depends on the scope. Writing a JSON parser is pretty easy. I've written a few in the past for fun. That wouldn't daunt me. Writing a YAML parser is probably a horrifically large task.
The only reason I care about clj-commons/clj-yaml is that its part of bb and I don't want bb to behave wrong with respect to people's builds
I mean, getting the first 80% right is probably easy. But then becoming spec-compliant with all the quirks is where it gets "fun"
Oh yes. So many quirks I bet. The CircleCI Yaml loader has to check for things like loops, which are possible in YAML.
We also had a bug where someone was able to create a map with two keys, both of which were null, with 2 values, which were also null.