Fork me on GitHub
#clojure-italy
<
2017-11-02
>
richiardiandrea00:11:34

@gianluca.scacco sembra che non sia stato "portato"

richiardiandrea00:11:42

per cui non puoi usarlo

richiardiandrea00:11:58

e' Clojure-only praticamente

gscacco06:11:52

@richiardiandrea grazie. In effetti il messaggio di errore è chiaro.

gscacco09:11:14

buongiorno a tutti

reborg10:11:23

Puzzle del giorno: (transduce (map inc) - 0 (range 10)) 55 (invece di -55). Qualcuno vuole cimentarsi? 🙂

bronsa10:11:12

(completing -) :)

reborg10:11:49

Devo veramente metterci "escluso @bronsa" tutte le volte? 🙂

bronsa10:11:17

non ho spiegato perche` pero`!

reborg10:11:25

vero... ENIGMA

reborg11:11:26

Leggevo questo ieri http://numba.pydata.org/numba-doc/dev/developer/architecture.html . Non sarebbe carino averlo in clj? Che sappia io c'e' solo qualche esperimento del 2014 in giro poi non se n'e' fatto piu' niente.

bronsa11:11:55

intendi clj -> llvm o altro?

reborg12:11:11

piu' la parte di ottimizzazione. Se f e' annotata (ad esempio), il bytecode prodotto viene analizzato, i tipi estratti durante il primo utilizzo e una versione ottimizzata prodotta in automatico. La versione ottimizzata puo' essere su LLVM (come numba). Oppure il bytecode riscritto per la jvm.

bronsa12:11:06

e` piu` o meno quel che fa truffle/graal

bronsa12:11:19

servirebbe un'implementazione per clojure

reborg12:11:51

mmmh, interessante, ci do un ocio

bronsa12:11:36

comunque Hotspot dovrebbe già fare quell'ottimizzazione IIRC

reborg12:11:47

Anche se non metto i type hint? Perche' lo scopo sarebbe fare type inference

bronsa12:11:25

no, Hotspot non rimuove reflection

bronsa12:11:17

se ho capito quel che stai pensando, si può fare con invokedynamic

reborg13:11:58

facciamo che se capisco cosa sto pensando ti faccio un fischio 🙂

reborg13:11:53

quel docs su numba usa un'architettura affascinante per analizzare python vm (= bytecode), effettuare type inference e scrivere LLVM bytecode che viene utilizzato da quel punto in poi. La parte di type inference e' interessante, perche' mi permetterebbe di scrivere clj ottimizzato senza type hints. Tutto in teoria. Non sono sicuro che ci sia vantaggio ad usare LLVM VS bytecode ottimizzato per la JVM. non ho be presente come funziona invokedynamic. E' equivalente a riscrivere una porzione non ottimizzata del bytcode per chiamare l'overload corretto sui tipi?