Fork me on GitHub
#announcements
<
2022-08-30
>
rschmukler00:08:48

Announcing tapestry-0.3.0-SNAPSHOT - seeking feedback or thoughts (message me or post in #teknql) on the new APIs before potentially releasing it with the GA release of JDK 19 later in september. Changes: • Added tapestry.core/interrupt! to interrupt fibers. • Added tapesty.core/timeout! to set a timeout on fibers • Added tapestry.core/alive? to see whether a fiber is still alive • Refactored fibers to use a custom tapestry.core/Fiber type allowing for better introspection (custom print-method) as well as the functions above. Takes us a step away from manifold (used to return deferreds) and toward built-in JDK stuff. • Removed custom tapestry.core/locking implementation - was needed when loom and clojure.core/locking didn't play well together (Monitors weren't yet supported). • Updates to the JDK 19 APIs instead of the loom preview build APIs. • Updated the readme w/ JDK 19 installation instructions and examples of the new APIs Check it out here: https://github.com/teknql/tapestry

🧵 6
🎉 6
🚀 5
didibus01:08:47

Looks good. It'll be interesting to see what kind of various async abstractions eventually develop on top of loom, tapestry looks like a nice start. I'm also curious to see core.async loom support and maybe promesa loom support, as well as Missionary or other structured concurency approach

💯 1
Joshua Suskalo13:08:39

I will say I doubt if core.async will do anything to support loom (because it needs to support JDK versions from 8 ). Most likely the easiest way to handle it will be to monkey patch it so that go blocks just use tapestry and parking put and take get replaced with the blocking ones.

hlship17:08:50

Well, I have to say you chose a really great name!

🙏 1
💯 1
orestis09:09:06

Wasn't tapestry a Java web framework?

borkdude13:08:26

fs 0.1.11 (File system utility library for Clojure) https://github.com/babashka/fshttps://github.com/babashka/fs/issues/65: Explicitly support :win-exts option on which function (https://github.com/lread) • https://github.com/clj-kondo/clj-kondo/issues/1782: exists? should never throw on illegal input path. • Remove ^:const to not cache OS-specific constants, so AOT-ed code can be re-used in multiple OS-es.

🎉 12
❤️ 6
Darrick Wiebe16:08:07

I've updated and released Jordan Lewis's data.union-find 1.0.0 It's a clean and fast implementation of the Union Find algorithm for quickly finding groups of interrelated elements. https://github.com/jordanlewis/data.union-find This version updates from the previous 0.1.0 release with support for fast construction using transient/persistent! I used this library as it is now in 2015 for a drug discovery project and it worked great. Unfortunately that variant was never properly released. I recently came back to it for a different project and asked Jordan to update the release. He asked me to take it over instead, so I have. I don't expect any significant changes in the future since I think it's feature complete and stable. If you aren't familiar with Union Find, you should check it out. It's a simple idea and quite useful!

😮 5
🏎️ 3
🎉 6
respatialized17:08:25

http://www.frankmcsherry.org/graph/scalability/cost/2015/01/15/COST.html I first read about union-find in this engagingly written (and frankly devastating) takedown of Scalable:tm: "big data" systems. Thanks for releasing this implementation!

Charles Comstock18:08:27

I've used https://github.com/huahaiy/nifty/blob/master/src/nifty/disjoint_set.cljc for this in the past as it supports both CLJ and CLJS. I know it can be tricky to support both, but it's really appreciated when implementations of fundamental data-structures support multiple platforms. I am curious how the data.union-find implementation compares on performance though.

Huahai18:08:42

By looking at the code, the data.union-find library seems to have immutable semantics, having transient and such, whereas mine is a faithful implementation of the mutable algorithm of union-find in Clojure syntax. Mine also use loop-recur instead of explicit recursion, so it probably won’t blow the stack.

Darrick Wiebe18:08:56

@UFTRLDZEW Thanks for the link! @UMGAMGWF8 interesting, thanks for the pointer to the nifty lib. I hadn't seen it before. I'd definitely be curious about the relative performance between these implementations. I see that nifty also implements disj which is nice. @U0A74MRCJ you're right, I was just writing the same thing!

Darrick Wiebe18:08:26

In practice I haven't seen any problem with blowing the stack even with reasonably large scale usage, but it's something to consider.