La versione volatile e’ stranamente piu’ lenta. Forse sto facendo qualcosa di brutto?

(defn powerset [coll]
  (let [cnt (count coll)
        bits (Math/pow 2 cnt)]
    (loop [i 0 r1 (transient [])]
      (if (< i bits)
        (recur
          (inc i)
          (loop [j 0 r2 (transient [])]
            (if (and (< j i) (< j cnt))
              (recur (inc j)
                     (if (bit-test i j)
                       (conj! r2 (nth coll j))
                       r2))
              (conj! r1 (persistent! r2)))))
        (persistent! r1)))))

quanto piu' lenta?

da 51 µs a 275 µs

mi aspettavo che togliendo laziness di mezzo fosse gia’ un vantaggio (for VS loop) poi ho aggiunto transient VS vector ma rimane lentina

for traversa chunked

e usa unchecked int math

domandina su specs & co

con Kafka e simili, anche se io aggiungo dei nuovi fields, eventi vecchi non li avranno

quindi in un certo senso la spec dovra' o: - aggiungere automaticamente questi nuovi fields con dei valori di defaults - mettere tutti i nuovi fields come optional

il problema grosso di questa cosa e' che e' moolto complicato scrivere dei test per vedere che non stai scazzando, e si rompe solitamente in prod/staging

un altra opzione che sarebbe interessante e' aggiungere dei meta-data per dire quando un field e' stato aggiunto, e poi magari non trattarlo come required se l'evento e' piu' vecchio

non so se qualcuno ha fatto una roba del genere, e/o se e' possible pero'

@andrea.crotti puoi fare un middleware che converte tutti gli eventi vecchi allo schema più recente? In questo modo puoi scrivere diverse spec (una per ogni schema) e poi fare dei property tests (con test.check o l’equivalente per spec) per verificare che il tuo middleware ti ritorna sempre un evento che conforma all’ultima spec

in generale no, migrazioni di questo tipo sono rare

perche' proprio in Kafka in general gli eventi sono immutabili

stavo provando qualcosa di questo tipo https://github.com/AndreaCrotti/spec-migration-fun/blob/master/src/spec_migration_fun/core.clj

che potrebbe in teoria anche funzionare, usando spec-tools che permette di usare solo maps per manipolare le specs

Si spec-tools lo trovo abbastanza necessario per lavorare con le spec. Comunque io con “migrazione” intendevo a lato applicativo (i.e. il “core” dell’applicazione non vede nient’altro che gli eventi all’ultimo schema), assumevo già che lo storage fosse immutabile

Ah si ok 👍

Dopo qualche altra modifica la mia poc funziona

Magari è difficile definire il timestamp dell added-at però

Dato che sarebbe quello in cui fai il deployment in teoria

ma uno non potrebbe aggiungere una :version su ogni evento che specifica secondo qualche schema dev’essere validato?

Mah il timestamp ha l'abbiamo

La version sarebbe più complicato da mette

ok, quindi puoi lavorare incrementalmente con spec-v1, spec-v2 etc? (timestamp o version)

In teoria si ci penso un attimo

qualcuno sa di un modo facile per tracciare tutti i forms da un particolare namespace?

per esempio per debuggare un test particolarmente stronzo, si fa per perfino fatica a capire dove si pianta

sarebbe comodo vedere qual e' l'ultima sexp valudata prima che si pianta tutto

ho provato con clojure.tools.trace, ma servirebbe qualcosa di piu' nucleare per farlo su tutto il progetto in un colpo solo

devo provare qualche magia con https://github.com/philoskim/debux magari

Puoi provare con clojure.core/*loading-verbosely* true, almeno vedi che namespace tenta di caricare

se hai lein, metti :global-vars {*loading-verbosely* true} in project.clj

ah ok provo

purtroppo debuggare problemi con kakfa topologies e' un delirio

con la libreria di test in http://github.com/FundingCircle/jackdaw adesso e' 1000 volte meglio ma sto per l'appunto migrando questo progetto a jackdaw

quindi sono ancora all'eta della pietra in confronto come tooling