https://github.com/seancorfield/honeysql -- com.github.seancorfield/honeysql {:mvn/version "2.3.911"} -- Turn Clojure data structures into SQL. • Address https://github.com/seancorfield/honeysql/issues/418 by documenting a potential "gotcha" with multi-column IN expressions (a change from HoneySQL 1.x). • Fix https://github.com/seancorfield/honeysql/issues/416 via PR https://github.com/seancorfield/honeysql/issues/417 from https://github.com/corasaurus-hex -- using the internal default state for the integrity assertion. • Address https://github.com/seancorfield/honeysql/issues/414 by providing an example of ORDER BY with a CASE expression. • Address https://github.com/seancorfield/honeysql/issues/412 by documenting options in a separate page and reorganizing the ToC structure. • Address https://github.com/seancorfield/honeysql/issues/409 by making docstring check for public helpers conditional. • Fix https://github.com/seancorfield/honeysql/issues/406 by adding :alter-column (which produces MODIFY COLUMN when the MySQL dialect is selected) and deprecating :modify-column. • Address https://github.com/seancorfield/honeysql/issues/401 by adding register-dialect! and get-dialect, and also making add-clause-before, strop, and upper-case public so that new dialects are easier to construct. Follow-up in #honeysql

Pleased to announce the first release of net.clojars.john/inmesh {:mvn/version "0.1.0-alpha.1"} - "One step closer to threads on the web" - https://github.com/johnmn3/inmesh It's a simplified rewrite of tau.alpha and introduces spawn, in and future to Clojurescript. It has a simple form of implicit binding conveyance as well as explicit binding conveyance. For now, you have to declare some configuration details in an ns loaded by the screen/main thread. By the beta releases though, I'd like to provide some automation so that you only need to declare configurations for advanced scenarios. More details on configuration are in the repo. spawn - provides a .thread-like facility for spawning webworkers, either ephemeral or long-lived. (can take a half-second of overhead, depending on loaded libs) in - provides a way to invoke work on a spawned webworker. Multiple workers can be spawned and then you can nest ins so as to easily construct execution flows. (usually takes 4 or 5 milliseconds of overhead for small invocations in compile mode :none) future - backed by a pool of webworkers, provides a way to invoke work off the current thread, without having to spawn or specify a worker (usually takes 8 to 10 milliseconds of overhead for small invocations in compile mode :none) All three provide simple binding conveyance, derefability in workers, promise/thening in the screen thread and allowing for yielding in async scenarios. Also comes with a wrapping for js/IndexedDB, providing a synchronous db-get call, similar to the synchronous API of js/localstorage. Provides a standard https://johnmn3.github.io/inmesh/ built on re-frame/mui-v5/comp.el/sync-IndexedDB, with application logic (reg-subs & reg-event functions) moved into a webworker, where only react rendering is handled on the screen thread, allowing for buttery-smooth components backed by large data transformations in the workers. Also provides an auto-transducifying, auto-parallelizing =>> macro, ala https://github.com/johnmn3/injest that fans work across a worker pool, roughly doubling the speed of large transformations in Chrome and Safari and tripling it in Firefox.

(defn flip [n]
  (apply comp (take n (cycle [inc inc dec]))))

(=>> (range)
     (map (flip 100))
     (map (flip 100))
     (map (flip 100))
     (take 1000000)
     (apply +))