Clojurians
#clojure-italy
<
2017-07-24
>

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

kors09:07:13

Ho utilizzato lightTable al mio primo approccio con Clj

kors09:07:04

Poi l'ho mollato per Intellij. Lavorando anche su altri stack l'interfaccia unica vince. Era un bel progetto però credo che abbia fatto il suo tempo.

nilrecurring14:07:55

Oh wow :smile:

reborg14:07:45

Grande! Non vedo l'ora di usarlo al posto di nodisassemble :slightly_smiling_face: quando hai alpha manda jar

bronsa14:07:45

eh vediamo, lo proporro` come talk per clojure/conj, se me l'accettano lo tengo closed source fino ad allora

bronsa14:07:23

quindi che ci sto lavorando resti in questo canale

reborg14:07:51

:zipper_mouth_face:

bronsa14:07:25

la fase alpha l'ha gia` superata, riesce a decompilare tutte le librerie che gli ho dato in pasto

bronsa14:07:52

ora sto lavorando alla macrocompaction e poi ho in mente di fare una cosa molto interessante assieme a tools.analyzer e tools.emitter

bronsa14:07:26

well, di provare a fare

reborg14:07:46

pensavo cosi' a naso che ci fossero problemi insormontabili man mano che il compilato si complicava... apparentemente no

bronsa14:07:02

beh facile non e` stato

bronsa14:07:33

la compilazione e` decisamente lossy, pero` utilizzando varie euristiche si riesce comunque a decompilare una form clojure equivalente all'iniziale

nilrecurring14:07:04

A meno di tutte le macro che non stanno in core immagino?

bronsa14:07:27

si`, l'output iniziale e` completamente inlined e macroexpanded

bronsa14:07:17

ho due fasi che cercano di riprodurre del codice humanly readable, una che prende AST e ritorna una AST "sugared", in cui transforma metodi emessi dal compilatore negli equivalenti in codice, e poi la fase di macrocompaction che cerca di fare la macroexpansion al contrario

bronsa14:07:22

in best effort, chiaramente

bronsa14:07:34

nel generale sarebbe un problema equivalente a risolvere l'halting problem

nilrecurring14:07:51

Quindi euristiche best effort

bronsa14:07:52

esempio stupido di macro impossibile da compattare: (defmacro foo [& _] 1) :)

nilrecurring14:07:28

Vero :slightly_smiling_face:

nilrecurring15:07:14

Però mi sembra già in ottimo stato, complimenti :clap:

bronsa15:07:11

son stati una decina di giorni molto intensi

reborg15:07:16

l'hai gia' puntato al jar di datomic? :smile:

bronsa15:07:03

se l'avessi fatto sarebbe abbastanza illegale, non lo confermerei di certo ;)

bronsa15:07:26

dico solo che non l'ho puntato solo a librerie

reborg15:07:48

ho visto cose che voi umani....

bronsa15:07:34

la missione di questa settimana e` cercare di unparsare il destructuring

bronsa15:07:05

il resto delle macro stock sono abbastanza triviali

reborg15:07:13

cmq complimenti saro' contento di provare quando e' disponibile (spero che ti prendano alla conj tra l'altro)

bronsa15:07:37

speriamo, ho un po' il sospetto che per le implicazioni per datomic non sia facile

reborg15:07:47

beh, se fornisci un offuscatore a corredo penso che si possano dire tutti contenti :slightly_smiling_face:

nilrecurring15:07:39

L’offuscatore è un’ottima idea per un altro talk :smile:

reborg15:07:34

uhm, mi chiedo se robe tipo i vari Java proguard non siano inutili in questo caso

nilrecurring15:07:57

Però in realtà decompilare non è illegale finchè non pubblichi i risultati, quindi è un po’ un’area grigia

reborg15:07:28

se @bronsa decompila dopo che Proguard ha passato il jar, non sono sicuro se funzia o no

bronsa15:07:55

no certamente no

reborg15:07:17

penso che offuschi il lato java, forse il decompilato contiene gibberish indecifrabile?

reborg15:07:31

cioe' (defn sfadslfjhaldkfjahdlfkjhadslfjkhafdflj [])

bronsa15:07:39

non solo quello

bronsa15:07:45

cambia proprio la struttura del bytecode

reborg15:07:37

ah, interessante, quindi potrebbe anche cambiare le performance ad esempio?

bronsa15:07:21

possibile, non ho mai usato proguard pero`

reborg15:07:07

ok, vedo se ho tempo per indagare e sfidarti a decompilare qualcosa

nilrecurring15:07:12

Ma offuscare renderebbe anche un po’ di cose utili un po’ più difficili, e.g. - stacktraces in production diventano illeggibili - repl in produzione diventa impossibile da usare perchè i nomi sono distrutti

nilrecurring15:07:19

Ovviamente dipende dallo use-case

nilrecurring15:07:28

C’è anche da dire che Datomic non ha nessuno di questi problemi

bronsa15:07:22

@reborg sono abbastanza convinto che con un minimo minimo di cambi sul bytecode stock esploda tutto

bronsa15:07:51

faccio abbastanza assunzioni sul tipo di bytecode da parsare

bronsa15:07:29

(semplicemente perche` non ho avuto tempo/voglia di renderlo robusto per bytecode non emesso da Compiler.java, non che sia una limitazione intrinseca)

reborg15:07:30

quindi anche cose del tipo direct linking potrebbero fare esplodere tutto?

bronsa15:07:40

no, tutto quello che genera Compiler.java lo supporto

bronsa15:07:44

modulo bug chiaramente