Clojurians Log v2

Clojurists Together wants to hear from you on what we could be doing differently. We're running a public survey for OSS Clojure devs to hear more about what you need and how we can serve you better. Check it out! :clojurists-together: https://www.clojuriststogether.org/news/listening-to-maintainers-for-the-next-phase-of-clojurists-together/

Cool! I'm receiving a permission error on the public survey though 😅

Oops, thanks! I've fixed that now

Refreshed version of this I2C library for your IOT projects ; talking to sensors and such from Clojure JVM : https://github.com/helins/linux.i2c.clj Also "sub-libraries" targetting specific devices such as the BME280 sensor (see README) 😉

I remember years of building linux kernels and adding in the I2C-bit banging module 🙂. Really cool to see some low-level love here 🙂.

We have a new blog post talking specifically about the FFI architecture in dtype-next. Write some code that accesses C libraries and runs across JDK-8 with JNA, JDK-16 with JEP-191, and the Graal Native. This is the architecture behind clj-python and my example avclj library. https://techascent.com/blog/next-gen-native.html

Yes, with Clojure spreading around, I hope to see more works like that. Those libs are not new but it's true they are a bit expert-friendly, also because the JVM wasn't making things easy when it came to talking to the OS, using native code, etc

No kidding. Great direction 🙂.

I believe this is actually very important work. Historically, it has been hard to leverage native tooling but the few examples we have are, in my opinion, authentic success stories (eg. Neandertal). With BinF, I did some work on having "C-like ABI" tooling as well. It is essentially about describing composite types as EDN, although it was not the primary goal. A small example: https://github.com/helins/binf.cljc/blob/main/src/example/helins/binf/example/cabi.cljc It is not a complete solution such as what you show, it's more about having very basic building blocks so that many things can me implemented on top. I mention all that because I focused on being CLJS friendly as I believe strongly in WebAssembly. Imagine using native libraries/utils both from Clojure JVM and CLJS browser exactly in the same way. It would definitely be a killer feature. Goal-wise, BinF and Dtype seem to be different. Binf is rather "protocol-oriented" while Dtype is rather "math/performance" oriented. But when it comes to that ABI stuff, maybe there is some synergy to be found, especially when it comes to targetting WASM.

@chris441 random feedback for that blog site: make the icon link to the homepage please 🙂

@martinklepsch - Great feedback 🙂. Will do! @adam678 - I have thought about extending dtype to the browser and there was ages ago some level of effort there but learning the intricacies of the JVM in order to compete with the spark ecosystem sort of made that go away. I am not sure the architecture would even work on the browser; it relies on very fast virtual calls in some situations which the browser's javascript engine often does extremely poorly. I agree with the insight that WASM is a unifying direction for both; I have thought before that the JVM should have first class support for WASM itself which it kind of does through GraalVM but I think it should be a JEP and part of the main codebase. There is definitely space in there for us to work together and talk about our directions as they are very similar in a lot of respects.

In avclj I have an example of using https://github.com/cnuernber/avclj/blob/master/src/avclj/av_context.clj and using those to create struct definitions that are very similar to your binf work.

Today seems to be "native tooling day". Here is another refresh, a GPIO (General-Purpose Input Output) library for your IOT projects: https://github.com/helins/linux.gpio.clj Eg. Handling pins on a Raspberry Pi from Clojure JVM (I had to migrate some underlying Java libs from Bintray, I took some time to "modernize" those libs)

Definitely some overlapping, nice example! Funny how things converge, a few days ago I was messing ffmpeg (decompiling ffmpeg-wasm with a lib I'll release "soon"). It is a very good target for testing/developing that kind of tooling. Is there a "lower-level" facility for describing those layouts besides text? One of the reason I preferred working with fns and EDN right away, abstracting primitive types, was to be more language agnostic (eg. being more friendly towards Rust). Another argument towards trying to be more agnostic/programmatic for describing composite types, when it comes to WASM, is interface types. I am not sure yet but I believe it could be possible to "easily" decompile a lib such as ffmpeg-wasm and automatically generate such struct descriptions in some situations.

Yes for sure - https://cnuernber.github.io/dtype-next/tech.v3.datatype.struct.html

Actually the documentation for that namespace is lacking. The clang namespace uses the low-level api: https://cnuernber.github.io/dtype-next/tech.v3.datatype.ffi.clang.html

Just added https://lucywang000.github.io/clj-statecharts/docs/parallel-states/ (a.k.a concurrent states) support to https://github.com/lucywang000/clj-statecharts, the State Machine and StateCharts for Clojure(Script). The value proposition of Parallel States becomes more and more prominent when the applications UI gets more complex. What's more, this is a major rewrite of the internals (used a lot of the reference algorithm in the https://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation instead of my own one, because the latter is awkward to implement parallel states feature. All the https://github.com/lucywang000/clj-statecharts/blob/master/test/statecharts/impl_test.cljc still pass, even the core impl code has more than 50% changed! I have not cut a release yet, so the version number is still 0.0.1-SNAPSHOT. Don't be scared by that, though, because I have been using it in commodity futures trading for almost half a year now 🙂

I wanted to check the cljdoc link but it returns an error: An exception occurred, sorry about that!

I'm just curious if the new api lets you set the pulldown resistor on an input. My clojure rpi project just used sysfs gpio for everything, but I had to get wiringpi installed and initialize the pulldowns manually when the pi boots up.

New library looks cool btw. Thanks!

Congrats! Contemplated writing a cljs adaptation myself after a friend shared xstate with me but you beat me to it. Looks solid too, excited to give it a shot. 🏆