Clojurians Log v2
dev-tooling
From this perspective, it makes sense that the streaming "envelope" format is bencode and not json: https://clojurians.slack.com/archives/C02165ZDU9E/p1689466408927169 I've tried several JSON parsers in the clojure ecosystem for streaming but none of them seem to support it well without a lot of hoop jumping. I've never encountered this problem with bencode in any language and even if I did, it's possible to hand-roll something in one afternoon
Yeah, streaming JSON is really hard. That's why I've never been very fond of it.
"That's why I've been very fond of it." => bencode, you mean, right?
+ never 🙂 This was for JSON.
I'm a master of crazy typos. 😄
👍
I'm also re-confirmed in my decision to blindly copy bencode for bb pods ;)
☝️ @ingy
Greetings! My name is https://github.com/ingydotnet/ and I was invited here by @pez. I helped invent and currently maintain the https://yaml.org/. A few months ago I started writing a Clojure platform called https://github.com/ingydotnet/lingy. Lingy intends to target host languages currently lacking a Clojure, starting with Perl. Lingy wants to take Clojure concepts deep into Perl including compiling to some JITing VM (tbd). @pez already has me working on an nREPL implementation for integration with Calva and other Clojure editors! I also started a sister language called https://github.com/yaml/yamlscript that is really just an alternate syntax reader for Clojure platforms. At https://tprc.to/tprc-2023-tor/ last week I gave a talk about https://www.youtube.com/watch?v=9OcFh-HaCyI. I'm extremely pleased that it got noticed by @pez and led me to this amazing place. Among other things, a top goal of both Lingy and YAMLScript is to bring more programming communities together. Please stop by the new #lingy and #yamlscript channels and let's chat!
It'd be great if you could also see what it would take to get kondo / clojure-lsp analysis working for your new host dialects. Often it's just making it aware of interop differences and missing/added core functions.
@snoe (and everyone, really). The Discussions are enabled for the Lingy repo: https://github.com/lingy-lang/lingy/discussions I have started some threads there, with things I have started to think about needs addressing. Would be great with input like ^that^ there as well.
Welcome @ingy! You might be interested in https://github.com/clj-commons/clj-yaml, a thin wrapper over SnakeYAML, usable from Clojure and Babashka. #clj-yaml
Hi @lee! I'm very familiar with SnakeYAML. I am more interested to know if there is a more pure (lisp) YAML implementation in Clojure. If there is then I could easily port it to YAMLScript, and thus have a YAML framework written in YAML 😄
But great to know about clj-yaml for real usage.
I don't know of anyone who has taken on writing a YAML implementation in Clojure. So you could be the first!
@ingy It is common in Clojure world to leverage high-quality Java libraries, either directly via interop or through thin idiomatic wrappers, instead of rolling a pure Clojure implementation.
There are 2 reasons for that: 1. The performance is usually better in a Java implementation. 2. This compensates for the Clojure community being significantly smaller than Java's.
@alexyakushev that makes sense. And I Lingy can already use Perl's YAML modules directly. But a pure Lisp reference parser would be a valuable learning tool. And encoding that in YAML would be a pretty cool asset for YAML framework authors to reference.
Of course, writing something from scratch is often a good learning exercise :).
I've written a YAML reference parser https://github.com/yaml/yaml-reference-parser in multiple languages. Would like to have a functional lisp version in there. 🙂
@alexyakushev Another reason for a pure Clojure implementation would be a potential ClojureScript port...
Good point. And thus Lingy (Perl, etc) implementation!
Implementing YAML correctly is... hard.
Maybe porting from another functional framework like HsYAML is the best approach.
@seancorfield Sure! Not dissuading, just explaining why things are the way they are now.
related to that, does Clojure bind well to FFI / C-based shared libs?
I'd guess it's possible but not preferred
I'm in the planning phase of a project I call YAMLStar which is a full-yaml-stack framework implementation ported to 42 languages (I often say "42 languages" to mean all langs I can) such that they all are fully correct, compatible and expose the same functionalities.
Most of the work is done by libfyaml, with a thin veneer in the hosting language. But for JVM languages maybe I should do this as a clojar.
Speaking of which, I have yet to publish a JVM package. Anyone know where to look here or elsewhere to make that easier?
I do have a sonatype account setup. But I recall maven publishing and clojars publishing being a lot of work last time I tried, and didn't get it all figured out.
> does Clojure bind well to FFI / C-based shared libs? Clojure's story is exactly equal to Java's, and the latter is... not optimal. You can do it if you must, but it's not very convenient, has certain limitations and performance tradeoffs. And certainly not beginner-friendly (for the person that has to write the bindings).
What I expected 🙂
Publishing to Clojars is very easy if you use either Leiningen or tools.deps as a build tool. All those repositories (Sonatype, Maven Central, Clojars) have the same API, and the same tools/commands are used to publish to either. The difference is only in the amount of organizational ceremony at the repository side. Clojars is probably the easiest to push to (doesn't require signing, gives a groupId by default that doesn't need domain name verification, etc) from scratch.
Not requiring signing is 👍 for me making progress. thanks
This is the tutorial how to do it with Leiningen, with tools.deps it's a bit of "make your own build tool from parts", but similar guides exist for it. https://github.com/technomancy/leiningen/blob/stable/doc/TUTORIAL.md#publishing-libraries
I will try again very soon.
https://clojure-doc.org/articles/cookbooks/cli_build_projects/ for deps.edn / tools.build (which links to the official guides which you'll need to read first).