Fork me on GitHub

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

πŸ‘ 10
clojurists-together 7

Cool! I'm receiving a permission error on the public survey though πŸ˜…


Oops, thanks! I've fixed that now

πŸ‘ 1

Refreshed version of this I2C library for your IOT projects ; talking to sensors and such from Clojure JVM : Also "sub-libraries" targetting specific devices such as the BME280 sensor (see README) πŸ˜‰

πŸ‘ 5
πŸ‘€ 1

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

metal 1

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 πŸ™‚.


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.

πŸŽ‰ 18
❀️ 6

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: 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.


@UDRJMEFSN random feedback for that blog site: make the icon link to the homepage please πŸ™‚


@U050TNB9F - Great feedback πŸ™‚. Will do! @UCFG3SDFV - 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 and using those to create struct definitions that are very similar to your binf work.


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.


Actually the documentation for that namespace is lacking. The clang namespace uses the low-level api:


Today seems to be "native tooling day". Here is another refresh, a GPIO (General-Purpose Input Output) library for your IOT projects: 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)

πŸ‘ 3
clj 5
raspberry_pi 3

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!


@UHL84CDTP Thanks, updated second Cljdoc link which was indeed faulty Pullup/down depends on the Linux API. This library is based on version 1 of that API. I know there was/is a version 2 in progress which, I believe, add explicit support for that, but I don't think it's out yet.

thanks3 1
Lucy Wang15:03:39

Just added (a.k.a concurrent states) support to, 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 instead of my own one, because the latter is awkward to implement parallel states feature. All the 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 πŸ™‚

πŸŽ‰ 29
partywombat 4
Eccentric J23:03:25

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. πŸ†

Lucy Wang00:03:23

Yeah I thought of that way too, xstate is just fabulous. But I believe statecharts could be more widely used in both clj & cljs so I decided to roll my own. Still lots of the API design is borrowed from or inspired by xstate.

πŸ‘ 3
Lucy Wang02:03:19

Here is an excellent article about making use of the parallel states features (and other features) of clj-statecharts:ΒΒ .


Hey Lucy, just wanted to say that I really like your introductory documentation @ - it’s great to have the trade-offs listed upfront. The README in the github repo says that it has first-class Re-frame integration. Would you lose something significant if you don’t want use Re-frame in the frontend then?

Lucy Wang11:03:21

@U4P4NREBY the website is not my work πŸ™‚ regarding re-frame integration, the core of clj-statecharts is pure function - the transition function, or a math formula

[actions, next-state] = f(current state, event)
The re-frame integration is just some higher level helpers on top of that. I use it in a few of my own projects and find it a good pattern, so I include it in the library hoping it could be useful for others too. You can safely ignore that module if you don't use re-frame or want to roll your own way.