announcements 2023-05-20

mauricio.szabo04:05:47

Hi, everybody: Pulsar Editor got a significant improvement on syntax highlighting - we just published (on the rolling release channel) a version where we basically redesigned tree-sitter! The new version is closer to other editor's and we now have Clojure being highlighted via tree-sitter (previously we only used TextMate for Clojure)! You can grab at https://pulsar-edit.dev - currently, we need to toggle the modern version because we don't want to break anything. This is actually quite huge for me, at least, because this new implementation makes it possible do differentiate between function calls and lists; it is also possible (but still not implemented) to support both #_ and comment, highlighting it correctly to a code comment (but also allow the user to decide if that's desirable); and finally, because it opens the doors to newest Electron versions!

💯 20

⭐ 22

💪 14

😎 4

🎉 2

pfeodrippe13:05:37

Aí sim, papai!!

Noah Bogart14:05:05

This is sick! Good job y’all

niwinz15:05:14

Hi everybody, I'm happy to announce a new major release of *promesa* library: 11.0.664. The most relevant change behind this version is: In this version, one of the problems that existed since the birth of this library has been corrected, related to the fact that the default implementation of js/Promise makes it impossible to nest promises . This fact has caused the library in the first place to have had a divergence with its counterpart in CLJ/JVM and, secondly, to the fact that mapcat-type operators could not be correctly implemented, making them practically useless on CLJS until now. With this version, the problem is fixed and while it cannot technically be considered a backwards compatibility break, some operators with promises will not function identically. Basically the magical auto-unwrapping of promises is gone in some operators. Function docstrings have already been explicit about what they are expected to return, so if you've been relying on the js/Promise implementation detail in CLJS, it's possible that some pieces of code are broken, because now several operators already work the same way in CLJ and CLJS. Other relevant changes: • CSP: add first class support for errors on channels • Promise: add introspection support on CLJS (pending? done?, deref, ...) • Exec: many improvements and fixes on vthreads support (already available in 10.x) You can see a complete changelog here: https://github.com/funcool/promesa/blob/master/CHANGELOG.md#version-110664

🎉 45

❤️ 9

borkdude17:05:49

@U06B73YQJ curious as to how much overhead is introduced compared to using js/Promise directly and what the effect on performance is

niwinz22:05:56

Interesting question, in our nonscientific tests the performance is analogous, but this is something that I still in my TODO list for measure it ...

niwinz15:05:33

niwinz15:05:11

it has a lightweight overhead over native promise, but still looks reasonable for correctness

niwinz15:05:08

This on release build, for completeness

seems 50% slower?

404ns vs 575ns

ok 42% then :)

In JS you can't "wait" for a promise unless you use async/await (which is just syntactic sugar for .then basically). What then is the semantics of deref of a promise in JS?

borkdude15:05:13

Btw, was the overhead similar to previous releases of promesa?

niwinz15:05:33

this measures only native Promise impl vs promesa builtin promise impl (without all promesa abstractions, just underlying impl)

borkdude15:05:18

would it be an idea to have a mode in which the promesa macros just compile to regular "bare" js/Promise without the extra baggage? I don't think I've ever wanted to reach for anything that wasn't possible with js/Promise alone, just that the macros offer a convenience

niwinz15:05:45

yes, it is possible, but this will imply to have different versions of macros for clj and cljs, and the main reason for internally use protocols, is to have the same macro impl for CLJ and CLJS

borkdude15:05:39

you can't block in JS. what does deref do when the value isn't available?

niwinz15:05:06

the deref is irelevant here, is just a side effect of being able to inspect the state

niwinz15:05:12

you can't block in JS. what does deref do when the value isn't available? => returns nil

borkdude15:05:50

maybe throwing would be better?

borkdude15:05:57

since nil might be a legit return value

niwinz15:05:22

this is why you have the state introspection predicates... you need to explicit check but yes, throwing may be an option

borkdude15:05:18

ok thanks for explaining the design choices

mccraigmccraig19:05:21

nesting and CSP error state are making my code simpler!

mccraigmccraig19:05:15

for deref/extract of cljs promise values i don't mind if the 1-arity throws on unfulfilled promises, as long as there is a 2-arity which lets you specify a distinguished unfulfilled value

👍 2

2023-05-20

Channels