This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (26)
- # babashka (1)
- # beginners (174)
- # calva (1)
- # cider (10)
- # clj-kondo (27)
- # clj-together (1)
- # clojars (8)
- # clojure (57)
- # clojure-australia (1)
- # clojure-czech (2)
- # clojure-europe (40)
- # clojure-germany (15)
- # clojure-nl (3)
- # clojure-serbia (6)
- # clojure-uk (11)
- # clojurescript (30)
- # conjure (2)
- # cursive (8)
- # datalog (16)
- # datomic (29)
- # emacs (33)
- # etaoin (1)
- # events (2)
- # fulcro (81)
- # funcool (2)
- # integrant (3)
- # jobs (2)
- # joker (2)
- # kaocha (15)
- # lsp (19)
- # malli (8)
- # membrane (1)
- # off-topic (57)
- # pathom (2)
- # reitit (10)
- # releases (1)
- # remote-jobs (2)
- # reveal (5)
- # shadow-cljs (14)
- # sql (11)
- # tools-deps (8)
- # vim (3)
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! https://www.clojuriststogether.org/news/listening-to-maintainers-for-the-next-phase-of-clojurists-together/
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 🙂.
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
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
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.
@UDRJMEFSN random feedback for that blog site: make the icon link to the homepage please 🙂
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.
Definitely some overlapping, nice example! Funny how things converge, a few days ago I was messing
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: https://cnuernber.github.io/dtype-next/tech.v3.datatype.ffi.clang.html
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)
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.
@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.
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 🙂
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. 🏆
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.
Here is an excellent article about making use of the parallel states features (and other features) of clj-statecharts: https://doughamil.github.io/gamedev/2021/03/24/statecharts-for-animation.html .
Hey Lucy, just wanted to say that I really like your introductory documentation @ https://statecharts.github.io/ - 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?
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.
[actions, next-state] = f(current state, event)