Fork me on GitHub
seancorfield02:07:43 -- com.github.seancorfield/honeysql {:mvn/version "2.3.911"} -- Turn Clojure data structures into SQL. • Address by documenting a potential "gotcha" with multi-column IN expressions (a change from HoneySQL 1.x). • Fix via PR from -- using the internal default state for the integrity assertion. • Address by providing an example of ORDER BY with a CASE expression. • Address by documenting options in a separate page and reorganizing the ToC structure. • Address by making docstring check for public helpers conditional. • Fix by adding :alter-column (which produces MODIFY COLUMN when the MySQL dialect is selected) and deprecating :modify-column. • Address 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

🚀 7
🎉 15
💜 3

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" - 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 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 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 +))
Those maps will be combined into a single transducer and then 512 element chunks will be lazily consumed and fanned across a worker pool, sequenceing the chunks through the transducer and then recombining the results on the calling thread. Returns a promise in the main thread. Caveats: work is serialized across threads. But, as shown with =>>, you can make up for that by smartly chunking your work across a threadpool for nontrivial work loads. Issues and PRs are welcome. It's a pretty early alpha and the APIs are subject to change. Might provide a pmap before the beta. Happy hacking!

🎉 20
clojure-spin 4
🤯 1

OMMFG; Fantastic work! I've been dreaming about this for ages. Well done!


Thank you sir! Looking forward to hydrating oz charts with various data transformations off main thread now!

metal 1

Stop reading my mind! 😉