This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-29
Channels
- # aleph (1)
- # announcements (10)
- # aws (1)
- # beginners (110)
- # calva (4)
- # cider (26)
- # clj-kondo (14)
- # cljdoc (24)
- # cljsrn (16)
- # clojure (76)
- # clojure-europe (3)
- # clojure-ireland (2)
- # clojure-italy (15)
- # clojure-nl (8)
- # clojure-spec (23)
- # clojure-sweden (4)
- # clojure-uk (92)
- # clojurescript (37)
- # cursive (19)
- # datomic (59)
- # duct (1)
- # emacs (4)
- # fulcro (7)
- # graalvm (7)
- # graphql (1)
- # hoplon (69)
- # jobs (4)
- # jobs-rus (1)
- # kaocha (2)
- # leiningen (5)
- # luminus (2)
- # pathom (8)
- # reagent (6)
- # reitit (11)
- # spacemacs (12)
- # sql (3)
- # tools-deps (9)
- # unrepl (1)
- # vim (57)
Gionno… @andrea.imparato in generale ci sono vari svantaggi relativi al principio di “least surprise”. Un reload accidentale del namespace scatena il thread (e magari lascia un thread orfano dietro). AOT compilation scatena il thread (e fallisce). Se faccio require
del tuo namespace scateno il thread. E poi, anche se non so ancora il perche’, pare che uno abbia bisogno di un do
magico per farlo funzionare 🔐
do
e` semanticamente immateriale, e` pura sintassi, non esiste che aggiungerlo o meno cambi la semantica del programma
@andrea.imparato usare un go-loop
solo per leggere e swappare atom non ha senso comunque, lo stai usando come se fosse un thread
in effetti non avevo considerato quello @reborg 🙂. Quindi se accorporo finish-processing
con handle-data
avrebbe + senso? Cioè un solo thread che fa le cose e che controlla se ha finito di farle
hmm e perchè tutte le documentazioni su go-loop
che ho visto hanno go-loop e async dentro?
@reborg è tuo questo canale? https://www.youtube.com/channel/UCH0CkLvbv6yEyrUnw9qujpQ ci sono capitato per sbaglio e mi pare che l’avatar sia lo stesso tuo 🙂
ma sei bilingue? il tuo accento inglese è perfetto!