This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-11-03
Channels
- # announcements (55)
- # babashka (14)
- # beginners (49)
- # biff (9)
- # calva (73)
- # cider (14)
- # clerk (8)
- # clj-kondo (6)
- # clojure (92)
- # clojure-dev (4)
- # clojure-europe (18)
- # clojure-norway (62)
- # clojure-uk (5)
- # clojuredesign-podcast (4)
- # clojurescript (34)
- # cursive (40)
- # data-science (4)
- # datomic (5)
- # dev-tooling (1)
- # eastwood (6)
- # emacs (107)
- # figwheel-main (9)
- # fulcro (13)
- # gratitude (9)
- # hyperfiddle (5)
- # introduce-yourself (2)
- # off-topic (45)
- # overtone (23)
- # portal (5)
- # releases (3)
- # shadow-cljs (6)
- # specter (1)
- # squint (32)
- # timbre (4)
- # vscode (2)
Overtone 0.11.0 has been released 🎶 Overtone is a (live) music coding environment for Clojure. This is the first release in 4.5 years, many thanks to everyone who contributed!
• Official channel: #C053Q1QSG • Mailing list: https://groups.google.com/g/overtone
CHANGELOG
• Fix overtone.music.pitch/dec-last
(#437)
• Return notes in ascending order in overtone.music.pitch/chord
• Fix printing of huge map when calling instruments with Cider (#432)
• Fix size checks to multichannel buffer writes (#338)
• Add clj-kondo support (#493)
• Fix broken version comparison in args/SC-ARG-INFO (#449)
• OSC: use #getHostScript to fallback on hostname string (#450)
• Upgrade dependencies (#456)
• Add support for the grain-buf
ugen (#470)
• use canonical URL for freesound API (#479)
• Fix window paths to allow downloading samples (#487)
• Removed obsolete JVM option CMSConcurrentMTEnabled (#488)
• Read synthdef files correctly (#489)
• Fix buffer reading (#490)
• Add clj-kondo support (see overtone.linter
) (#493)
• Qualify the overtone ns in lein example (#495)
Contributors: Andréas Kündig, dvc, Hlöðver Sigurðsson, Lee Araneta, Markku Rontu, Matt Kelly, Nada Amin, Paulo Rafael Feodrippe, Perry Fraser, Phillip Mates, Wesley Merkel
Wow! Thank you so much, Arne!!! This is so great
Wow, that's awesome
Clojure Deref for Nov 3, 2023 https://clojure.org/news/2023/11/03/deref
Oops, put it in the wrong place, sorry!
This looks great.
I love the group ID -- so appropriate 🙂
using clojure.asm
is pretty wild. What made you decide to go that route instead of "normal" clojure? did you see performance benefits?
the generated bytecode causes exceptions that are thrown by go to jump right to where the label is, which you can't do with clojure
that's very clever
there are ways you could emulate it in clojure, using a try/catch around a loop over a case, similar to what core.async's go macro does, but I wanted to use the capabilities the jvm exposes as directly as possible, without emulating features of the jvm that aren't exposed in clojure using features of clojure
jvm bytecode is very strange. i gotta read up on it to get why/how it all works
Have you tried java-decompiling the generated bytecode? I'm curious what it makes of it... 🙂
I highly recommend adding a new throwable type for this so that you can elide stacktrace creation
This looks really cool though!
It generates a new throwable subtype for every label, I don't have it eliding stacktrace construction, but it creates all the instances once up front and just rethrows the same instances as needed
Oh that's good to know, I hadn't quite realized that it would rethrow the same throwable each time
Wait, didn't you flame Joshua for using Errors for flow control in his library? I am confused now.
Yes, you were, I remember now. And that would not be an issue here because these gotos are local to a single stackframe, right?
Oh, no it totally could be an issue, it throws throwables, and exposes those throwables for throwing in the dynamic extent of tagbody
Anything using throwables for jumps has potential issues when composed with other code
reading through this, the limitation for 255 forms comes from using a function for each form right? If that was changed to group all the forms into a single function between labels would the limitation jump to 255 labels?
the limitation is because each form is wrapped in a function, and then each function is passed as an argument to a static method, and that static method runs each function in turn with the exception handlers and what not set up
right. that’s what i was wondering if all of the bodies between labels were accumulated into a single function then the limit would be the number of labels (ie form groups instead of forms)
I haven't looked into a ton, but I did skim the jvm spec on exception handlers the other day and did not immediately see any limitation to how many exception handlers you can have
haha yeah. i was checking my understanding. love reading this code and was just wondering
something I have wondered about a little is if I could mess with internal compiler state enough to have it generate the bytecode for each body inside the runner class, and there by avoid having to wrap things as fns and pass them in
but that seems very intense (might involve writing a subclass of ObjExpr or something)
Released ham-fisted 2.010 which contains an extensible primitive typed let system and helpers to invoke primitive functions - both of which are aimed at removing boxing from tight loops - https://github.com/cnuernber/ham-fisted/. hamf already contains a *-array macros that will inline array creation so - combined with the let statement - you can use arrays as tuples and get the full expected performance and of course eliminate boxing from tight loops. For example of typed let and primitive-invoke pathways see https://github.com/cnuernber/ham-fisted/blob/master/test/ham_fisted/hlet_test.clj.