Fork me on GitHub
#squint
<
2022-08-23
>
lilactown04:08:38

Wrap["getBasis"] = function () {
return [symbol("rf")];
};
Wrap["cljs$lang$type"] = true;
Wrap["cljs$lang$ctorStr"] = "Wrap";
Wrap["cljs$lang$ctorPrWriter"] = function (this__29314__auto__, writer__29315__auto__, opt__29316__auto__) {
return _write(writer__29315__auto__, "Wrap");
};
☝️:skin-tone-2: the above is generated by deftype. is it necessary?

borkdude06:08:00

@lilactown Probably not, just copied from CLJS, we can change it

lilactown15:08:08

I'll just remove it for now

borkdude19:08:04

@lilactown Excited about your protocol PR. After that one we can start introducing protocols for dispatch in some of the core fns and remove some of the hard-coded stuff (assuming it will be fast enough)

Cora (she/her)19:08:06

even if it's not fast enough for core types we can fall back on protocols for types we don't recognize

Cora (she/her)19:08:52

we'll need to be careful about checking instanceof for Object, though. we'd probably want to check the constructor to see if it's literally Object, then fall back on protocols, then fall back on instanceof checking for things derived from Object

hairfire19:08:19

I have a tangential question: "Is it reasonable to consider targeting C++ with something like Clava?" In particular I've been trying to find a way to do something like this for our embedded C++ developers. I envision using a kind-of-Clojure on a big development computer, with full REPL-driven-development and unit testing, then "compiling" for the target (i.e., Generate C++ with no exceptions or heap dynamic memory allocation).

Cora (she/her)19:08:44

you might be interested in #jank

hairfire19:08:14

I'll take a look. Thanks!

borkdude19:08:19

Or #graalvm native-image

borkdude20:08:12

Or perhaps targeting an embedded JS engine with Clava could be interesting in the future

genRaiy10:08:23

I remember @U04VDQDDY telling me that in some cases the JS was faster than C on the ESP32

borkdude10:08:42

yes, that will be an interesting target for clava