This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-09
Channels
- # aleph (21)
- # architecture (5)
- # boot (25)
- # cider (1)
- # cljs-dev (115)
- # clojure (59)
- # clojure-brasil (3)
- # clojure-dev (4)
- # clojure-italy (20)
- # clojure-nl (2)
- # clojure-portugal (6)
- # clojure-russia (12)
- # clojure-spec (43)
- # clojure-uk (37)
- # clojurescript (76)
- # datomic (123)
- # emacs (3)
- # graphql (2)
- # hoplon (5)
- # jobs-discuss (1)
- # jobs-rus (4)
- # keechma (7)
- # lein-figwheel (13)
- # leiningen (7)
- # lumo (2)
- # off-topic (17)
- # om (6)
- # onyx (26)
- # parinfer (19)
- # planck (2)
- # re-frame (80)
- # reagent (9)
- # ring (1)
- # spacemacs (45)
- # testing (1)
- # vim (28)
Buondì
Domandaccia: so che esistono repeat
e repatedly
ma è tanto brutto usare un reduce
su un range?
Mi spiego meglio: leggo da un socket, il primo byte che mi arriva mi dice quanti elementi devo deserializzare dopo
mettiamo che ho 3 Integer da deserializzare: [3 0 0 0 1 0 0 0 2 0 0 0 3]
attualmente uso appunto un reduce
(datemi un attimo e vi fornisco un esempio)
(def b
(-> [3 0 0 0 1 0 0 0 2 0 0 0 3]
byte-array
java.io.ByteArrayInputStream.
java.io.DataInputStream.))
(let [size (.readByte b)]
(reduce
(fn [acc _]
(conj acc (.readInt b)))
[]
(range size)))
scusate l'indentazione
l'alternativa sarebbe:
(repeatedly (int (.readByte b)) #(.readInt b))
sicuramente più carina ma non so...
@mdallastella sceglierei quella che e' piu' leggibile ma qui c'e' un'altra differenza: repeatedly
ritorna una lazy seq e quindi ha un comportamento assai diverso da reduce
la documentazione di repeatedly
dice che consente side-effects
si, non dico di no..la mia osservazione e' diversa...volevo dire che dipende anche da come hai impostato il resto del codice e come vuoi effettuare la read...lazy or non lazy
silly example:
boot.user=> (def t1 (take 10 (repeatedly #(println "tst"))))
#'boot.user/t1
boot.user=> t1
tst
tst
tst
tst
tst
tst
tst
tst
tst
tst
(nil nil nil nil nil nil nil nil nil nil)
quindi la read la faresti lazy (il che pero' vuol dire che se nel frattempo ti chiudono il reader l'`InputStream` sei fregato)
io su I/O ci vado sempre non-lazy
@richiardiandrea quindi meglio il reduce
Mi scusassero, arrivo tardi sul thread. Lazy VS non-lazy dipende da come comunicano client-server. Se i chunk si scambiano una volta ogni tanto, allora puoi aprire lo stream sul socket, leggere e chiudere (qui sopra manca (.close b)
). Se i chunk sono continui, allora ti conviene tenere aperto e creare una lazy-seq dei chunk in arrivo. La tua app diventa reactive a quel punto.