This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-09-14
Channels
- # announcements (2)
- # babashka (54)
- # beginners (53)
- # biff (15)
- # catalyst (2)
- # cider (5)
- # clerk (17)
- # clj-kondo (36)
- # clj-otel (3)
- # clojure (52)
- # clojure-argentina (1)
- # clojure-brasil (1)
- # clojure-europe (35)
- # clojure-losangeles (2)
- # clojure-nl (3)
- # clojure-norway (20)
- # clojure-uk (5)
- # clojurescript (24)
- # cursive (10)
- # datahike (9)
- # datomic (15)
- # defnpodcast (8)
- # events (6)
- # funcool (2)
- # hyperfiddle (21)
- # jobs (1)
- # lsp (19)
- # malli (4)
- # matrix (1)
- # off-topic (25)
- # podcasts-discuss (1)
- # portal (13)
- # releases (1)
- # shadow-cljs (25)
- # solo-full-stack (16)
- # squint (27)
- # tools-deps (6)
- # tree-sitter (4)
Recently discovered the mulog+portal combination, it is pretty cool. I'm wondering if I can run some custom query to gather some metrics(counter for example) from the portal sink? For example, if I publish mulog to cloudwatch, I can query the data like stats count(*) by app-name, mulog/event-name
to gather matrics and insights, can I do the same with portal data?
Do you mean running queries across the atom containing the list of history (results) that Portal retains?
yes, basically run query code on all history portal results, not sure if this is a valid use case:grinning:
So the easiest thing here might be to register the query function as a Portal command, something like (portal.api/register! #'my.query/fn)
, then you can select the list and run the command via the command palette. Is that the type of UX you had in mind?
You can also control the atom (containing the history list) that Portal uses at startup so you can treat it just like regular Clojure data: https://github.com/seancorfield/vscode-calva-setup/blob/develop/calva/config.edn#L44-L90
I have a REPL snippet to run arbitrary code on the most recent tap>
'd value in Portal as well (see Tap Input Code
immediately after the segment linked above).
The custom atom approach also has the benefit of allowing you to automatically compute these metrics as you accumulate logs
(def logs (atom {:metrics {}
:logs ^{:portal.viewer/default :portal.viewer/table} []}))
(defn submit [log]
(swap! logs
(fn [{:keys [metrics logs]}]
(let [logs (conj logs log)]
{:metrics (compute-metrics logs)
:logs logs}))))
(portal.api/inspect logs)
@U1G869VNV I was just looking over the Portal code -- I don't think the default values atom is easy to get at, right? So you pretty much have to use a custom submit and your own history atom for this...
Yeah, I think the Sean's custom atom approach is pretty much what I need. I'm quiet new to portal so I haven't tried the register function yet, I'll look into that as well. Is there api to just get the default atom instead of create a custom one?
Yeah, the default tap list atom is private since messing with it could break assumptions the default submit function makes
You could provide a history
function in the API perhaps, that returns the current contents of that atom?