This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-03-02
Channels
- # ai (5)
- # announcements (1)
- # babashka (8)
- # beginners (16)
- # clojure (21)
- # clojure-europe (3)
- # clojure-norway (6)
- # clojure-uk (1)
- # datomic (3)
- # events (4)
- # figwheel-main (5)
- # fulcro (10)
- # jobs (1)
- # lsp (26)
- # missionary (5)
- # pedestal (1)
- # polylith (3)
- # portal (28)
- # practicalli (1)
- # reagent (37)
- # reitit (1)
- # scittle (24)
- # tools-deps (7)
I really can't figure out how to write a tree building algorithm. I have this data
({:context ["root"], :values "lalala1"}
{:context ("root" "select-location"), :values "lalala2"}
{:context ("root" "select-location"), :values "lalala3"}
{:context ("root" "select-vendor"), :values "lalala4"}
{:context ("root" "select-vendor"), :values "lalala5"}
{:context ("root" "select-vendor"), :values "lalala6"}
{:context ["root"], :values "lalala7"}
{:context ["root"], :values "lalala8"})
And I want to have this tree at any depth
{:context "root",
:values ["lalala1"
{:context "select-location"
:values ["lalala2"
"lalala3"]}
{:context "select-vendor"
:values "lalala4"
"lalala5"
"lalala6"}
"lalala7"
"lalala8"]}
I can't seem to figure it out 😞
If you give each entry an ID, you can use https://github.com/lilactown/pyramid
Thanks for the suggestion. Seems a little too much to just solve this problem.
What kind of exercise is that? Where did you find it? The output data structure is kind of goofy : Why node values and children nodes are stored in the same place (in any order)? It seems overly complicated to construct 😀
Yeah, it's not an exercise. I'm trying to group logging lines. However I updated the output
I accedentally made it wrong
super goofy solution 😀
(defn update-in-goofy
[xs ks v]
(if (empty? ks)
(conj xs v)
(let [k (first ks)
our-context? #(and (map? %) (= k (:context %)) %)
child (some our-context? xs)]
(if child
(conj (remove our-context? xs) (update child :values update-in-goofy (next ks) v))
(conj xs {:context k
:values (update-in-goofy [] (next ks) v)})))))
(defn build-goofy-data
[data]
(reduce (fn [acc {:keys [context values]}]
(update-in-goofy acc context values))
[]
data))
;; (build-goofy-data input)
(defn solution [data]
(into [] (comp (partition-by (comp first :context))
(mapcat (fn [part]
(if (empty? (-> part first :context))
(mapv :values part)
[{:context (-> part first :context first)
:values (solution (mapv #(update % :context rest) part))}]))))
data))
(solution data)
=>
[{:context "root",
:values ["lalala1"
{:context "select-location", :values ["lalala2" "lalala3"]}
{:context "select-vendor", :values ["lalala4" "lalala5" "lalala6"]}
"lalala7"
"lalala8"]}]
@U01JYUZRS4V The problem definition is not entirely clear.
Your sample data has contexts grouped together - there are no instances of the same context being "split" by a different context.
The "root"
value is probably special and is always the first item in any :context
coll.
But what would you expect the result to be when the desired algorithm is applied to this data?
[{:context ["root" "a"] :values 1}
{:context ["root" "b"] :values 2}
{:context ["root" "a"] :values 3}]
Is it this?
[{:context "root" :values [{:context "a" :values [1]}
{:context "b" :values [2]}
{:context "a" :values [3]}]}]
Or this?
[{:context "root" :values [{:context "a" :values [1 3]}
{:context "b" :values [2]}]}]
Or something else?What I really have is a log of activities. I added the context in order to group them because one job could generate hundreds of entries.
And I thought that I could have the context groups foldable in order to make it easier to read the activity log afterwards
so yes, root is a special case, then there can be an arbitrary depth of contexts
everything needs to be rendered in chronological order
So in those two options in my message above, you need the former one, right? In that case, the solution by Martin is exactly what you need.
yes I would say the first one
and the values beneath context "b" could in turn include contexts
I'm thinking that maybe i should create the context tree first and then hook up the entries into the tree
but that would mess up chronology
Yeah, just go with the Martin's solution. :) No need to invent something else. Unless your contexts can grow larger than a stack size, but I really doubt that.
No I don't think that's a problem luckily. I'm going to try it out now.