Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-09-08

Channels

#clojure
<
2022-09-08
>
Rambabu Patina08:09:19

Hi, I am trying to implement promises using promesa. My requirement is to call the method which returns promise on button click event, but getting some errors (i.e 'Invalid expression [object Promise]'). The button onclick code is 

(button/ui-button
            {:appearance "primary"
             :isDisabled (not enabled?)
             :onClick
               #(comp/transact!
                   this
                   [(save-config!)
                    (p/let [(send-event! :settings {:p1 "test"})])
                    (close-dialog!)]
                   {:optimistic? false})}
            (tr "Save"))
The method is 
(defn send-event! [settings]
          (p/promise
           (js/console.log
            {:message "Settings data: "
             :state settings})
           (helper/sendEvent
            constants/key
            constants/event
            (clj->js settings))))
So on button click event the promise needs to be resolved then close the window. Please suggest what I am missing. Your help is greatly appreciated. Thanks

delaguardo08:09:47

isn’t (p/let [(send-event! :settings {:p1 "test"})]) needs to have a binding var?

Rambabu Patina09:09:04

Though I added, same error

Daniel Tan10:09:40

you're trying to comp a promise object

Daniel Tan10:09:06

why not just use p/let instead of comp

Rambabu Patina10:09:13

We are using fulcro comp/transact to handle transaction processing.

Rambabu Patina10:09:10

It is existed code and needed. Can we invoke both on button click event?

Daniel Tan11:09:11

i would probably wrap the whole thing in a plet

theasp17:09:28

Hi all, does anyone have a suggestion for a directed graph library with toposort other than weavejester.dependency? I'm having performance issues, toposort of50k dependencies (only integers) takes 800s

p-himik17:09:11

Interesting... wonder what the graph looks like in your case as I tried it with 30k of items where each child can have at most 2 parents, and on some real data it finished under a second or two.

jpmonettas17:09:02

there is also clojure.tools.namespace.dependency , not sure about performance or if it works with integers, had only used it with symbols

hiredman17:09:53

when you checkout loom you might also look at https://github.com/Engelberg/ubergraph

hiredman17:09:54

weavejester.dependency is a fork of https://github.com/stuartsierra/dependency, the readme of which says "I originally developed this library to support namespace dependency tracking in https://github.com/clojure/tools.namespace, where it is still included under the name clojure.tools.namespace.dependency."

theasp17:09:46

Thanks guys, I'll check those out

theasp17:09:54

I'll see if I can extract the data and put it somewhere

hiredman17:09:55

what is the direction? does {0 #{1 3 2}} mean 0 depends on 1 3 and 2, or that 1 3 and 2 depend on 0?

borkdude17:09:26

At a job we used jgrapht because of performance reasons, it has topo sort too

p-himik18:09:08

@U488CTM1V Ah, my bad with that performance comment - I misremembered. My experiments have initially started with weavejester/dependency but I ended up using aysylu/loom. No recollection of the reason for the switch though... But thanks for the data, still curious to poke around.

theasp18:09:24

@U0NCTKEV8, yeah 0 depends on 1 2 3

andy.fingerhut18:09:06

topological sort has linear time algorithms, so 800 sec sounds for an in-memory graph, even with 50k dependencies, sounds like they might not have implemented the linear time algorithm for topological sort.

andy.fingerhut18:09:47

There was a time years ago when the latest released version of tools.namespace implemented an algorithm that could be exponential time, depending upon the "shape" of the dependencies, and I submitted a PR (merged in years ago) that made it linear time.

hiredman18:09:24

yeah, and it would be possible that improvement didn't make it to the independent libraries

theasp18:09:04

2022-09-08T18:28:12.993Z INFO [sacctsync.migrate.plan:109] - Building migration plan, this can take a very long time                                                                         
2022-09-08T18:28:15.602Z DEBUG [sacctsync.migrate.plan:91] - Dependency graphs built in 00:02.608                                                                                            
2022-09-08T18:28:16.035Z DEBUG [sacctsync.migrate.plan:105] - Topo-sort lists built in 0.424180627                                                                                           
2022-09-08T18:28:16.425Z DEBUG [sacctsync.migrate.plan:82] - Plan actions built in 0.389160914                                                                                               
2022-09-08T18:28:16.426Z INFO [sacctsync.migrate.plan:114] - Building migration plan complete: 3.43s

theasp18:09:10

with ubergraph 🙂

theasp18:09:54

800s to 0.5

jpmonettas18:09:15

Nice, I guess you can remove this can take a very long time

FiVo20:09:43

Is there a sorted-map/sorted-set implementation that supports iterating over the keys in order with a seek operation. So something like 

(defprotocol SortedIterator
  (first [this])
  (next [this])
  (seek [this k]))
where first and next have the usual meanings and seek skips to the next key that is at least k . The guarantees should be that next and seek take at most O(log N) and that if there are m keys visited in ascending order that it should be amortized O(1 + log(N/m)). I looked at https://github.com/clojure/data.avl but that doesn't seem to give me the amortized guarantee.

Alex Miller (Clojure team)20:09:26

the new IDrop stuff in 1.12.0-alpha1 could be used to make (drop n) do what you're calling seek (so reuses an existing clojure api)

Alex Miller (Clojure team)20:09:35

if something like persistent-sorted-sort or any other such data structure wanted to implement it (we did not do that for the built-in sorted set/map)

FiVo21:09:21

@U0NCTKEV8 With that implementation I also run into the issue that once I have sliced, I can't slice again.

hiredman21:09:34

are you sure data.avls split operation isn't basically what you need?

FiVo21:09:15

it will give a O(log N) guarantee, but it won't give me the amortized guarantee of O(1) if I want to visit every key in order.

FiVo21:09:56

The problem essentially arises when you interleave seek and next operations.

hiredman21:09:48

next is disj (nth ... 0)

hiredman21:09:00

seek is split-key, first is first

hiredman21:09:17

(nth ... 0) might be faster than first

FiVo21:09:23

Yes I agree. But will potentially the disj not be log N every time?

hiredman21:09:22

all three will be log n if believe

hiredman21:09:04

I guess next would be 2log n if you do first and disj both

ghadi20:09:45

look at subseq in core

ghadi20:09:10

which subseq makes use of

ghadi20:09:30

(there's also rsubseq)

FiVo20:09:42

Yes I am aware of subseq , but I won't be able to call subseq again on the resulting seq .

Cora (she/her)21:09:44

if I want to use core types in a protocol what should I use for vectors and hashmaps and sets?

Cora (she/her)21:09:32

clojure.lang.IPersistentMap and clojure.lang.IPersistentVector and clojure.lang.IPersistentSet?

Alex Miller (Clojure team)22:09:10

yes, those are the best interfaces denoting the persistent data structures (but as they are not types you control, be somewhat careful)