Fork me on GitHub
#shadow-cljs
<
2022-08-29
>
Klay00:08:38

I was able to fix my issue by declaring the dependencies Datalevin wanted, though I don’t know what exactly caused it.

dvingo16:08:22

Hi - is there anywhere in the compiler state that records a timestamp or datetime of when a namespace was last loaded? Or similarly - any info about which namespaces are stale when a code change is noticed (before a hot-reload)? The use-case is for malli function instrumentation and wanting to only instrument stale namespaces instead of doing a full ns scan on each hot reload.

thheller16:08:30

it does but not in a way that would be accessible to malli? which I assume uses a macro to do this?

thheller16:08:49

it is stored in the build state but not in the analyzer data

dvingo16:08:30

ah ok - Yea I was thinking the macro could make that data visible to the cljs runtime which would then be able to filter on it

dvingo16:08:33

is it infeasible to access the build state in a macro then?

thheller17:08:00

yeah, currently you can't

isak17:08:16

For example, in our build we look at some data in the compiler-env and throw an exception sometimes in the {:shadow.build/stage :compile-finish} stage, which shadow-cljs displays in the browser

dvingo17:08:09

thanks for the suggestion! I will play around with it, might be able to hack something (like writing to a file with generated code) idk

isak17:08:37

Here an example of updating the compiler env in a macro, then using that in a build hook (translation use-case): https://www.isaksky.com/posts/macro-assisted-translations-in-clojurescript/

dvingo17:08:06

amazing, thank you!

thheller17:08:18

FWIW I have been thinking of introducing a formal API that is called after compilation and basically lets you generate extra code. sort of like looking at metadata and generating code for it. in clojure you can just do that at runtime dynamically but CLJS you can't. so that might bridge that a little.

1
superstructor02:08:18

would this enable tracing use cases ?

thheller06:08:54

I don't know? haven't thought about tracing in a long long time so not sure what that needs?

superstructor06:08:14

I imagine the ability to walk/inspect the tree of code and inject custom tracing code at many points (e.g. every fn call)

thheller06:08:06

that would not be possible with what I had in mind

thheller06:08:34

the idea was just to generate extra code based on metadata

thheller06:08:46

not affect all other code that is generated

thheller07:08:13

I mean that could be done elsewhere. if you have a formal definition of what would be needed I could certainly add that

superstructor07:08:09

I'm not sure if this API would be the best place to serve that requirement or not ?

thheller07:08:53

no, this one doesn't seem to be. the idea is that for example I have metadata in my projects which "tags" certain functions as event handlers

thheller07:08:08

I then have a macro that collects all these and hooks them up properly

thheller07:08:37

think of it as (rf/reg-event ::m/tap-clear! (fn [...] ...))

thheller07:08:50

only that its a regular defn and not an anonymous function

thheller07:08:15

so basically the macro generates (rf/reg-event ::m/tap-clear! that.ns/var) (none of this actually uses re-frame, but it is very similar in concept)

thheller07:08:33

makes it easier to test functions from the REPL and stuff

thheller07:08:45

and imho makes for cleaner looking code

thheller07:08:58

but the macro has the problem that it needs to run after all other compilation is completed

thheller07:08:09

and needs to run after every compilation

thheller07:08:24

which is sort of weird for a macro and busts all caching and stuff

thheller07:08:03

so I want to move that to some API that just runs after all compilation and can collect all the necessary stuff from the analyzer data and generate some extra code

thheller07:08:31

same goes for instrumentation I think

thheller07:08:42

but tracing requires rewriting the actual code that is already generated

thheller07:08:46

so that doesn't fit this stuff

isak14:08:44

That sounds really nice!

dvingo17:08:16

nice! that would be very useful