OT Programmazione - rolling release

[MItaly]

scusa l'ignoranza, ma per macchina di build che intendi di preciso??
giusto per curiosità!

Un PC un po' "corazzato" su cui girano le build automatizzate - night build, alcune build automatiche ad ogni modifica dei sorgenti di alcuni progetti, build "ufficiali" dei rilasci. Postavo solo perché sono riuscito a convincere tutti a dargli come nome host SIGSEGV (e come IP l'11).

[Scara95]

Unrelated: nuova macchina di build.

(l'IP è ovviamente il .11 )

lol

[Scara95]

Ma intendi Common Lisp come implementazione o Lisp in generale? Perché CL ha effettivamente molto "sapore anni '80", con diverse cose che si potrebbero evitare o fare diverse, ma se parliamo di Lisp in generale credo che di posto ce ne sia ancora eccome... effettivamente, pensandoci, probabilmente l'unico modo davvero sano di fare metaprogrammazione a livello "serio" è con un linguaggio in cui l'AST è il codice che scrivi, per cui poi possiamo discutere dei punti accidentali della sintassi o delle librerie, ma i cardini del Lisp restano abbastanza senza tempo (e macro e reader macro danno una flessibilità sintattica assurda).

Certo, in un certo senso è affascinante quello che ci si può fare, ad esempio:

(defmacro with-gensym (names &body forms)
  `(let ,(loop for n in names collect (list n '(gensym))) ,@forms))


(defmacro memoized (fname arglist &body forms)
  (with-gensym (ht f args v exists?)
           `(let ((,ht (make-hash-table :test 'equal)))
          (labels ((,f ,arglist ,@forms)
               (,fname (&rest ,args)
                   (multiple-value-bind (,v ,exists?) (gethash ,args ,ht)
                            (if ,exists?
                                ,v
                              (setf
                               (gethash ,args ,ht)
                               (apply #',f ,args))))))
              #',fname))))


(defmacro defmemo (name args &body forms)
  `(setf (fdefinition ',name) (memoized ,name ,args ,@forms)))


(defmemo fib (n)
  (cond
   ((< n 2) 1)
   (t (+ (fib (- n 1)) (fib (- n 2))))))


(fib 10000)

[MItaly]

Nuovi angoli bui del C scoperti ieri:

void f(double a[restrict static 3][5]);

questo minestrone di keyword è sintassi C99 valida
https://stackoverflow.com/a/47378817/214671

[fermat]

ma qualcuno sa spiegarmi un attimo bene quali sono i vantaggi nell'imparare typescript??

nel senso, ho visto quali sono le caratteristiche del linguaggio rispetto a javascript standard.
solo che mi pare di aver capito che cmq, prima di usarlo in un'applicazione web, bisogna convertire il codice in javascript.

quindi il vantaggio qual'è, "solo" quello di poter usare una sintassi OOP e tutte le caratteristiche aggiuntive?
oppure ho capito male e posso includere direttamente i file .ts nelle mie pagine web??

[fermat]

mi rispondo da solo.

esistono dei progetti per includere file typescript direttamente dentro a pagine html:
- https://github.com/ComFreek/ts-htaccess
- https://github.com/niutech/typescript-compile

ma da quanto ho capito è sconsigliato, in quanto typescript non nasce con questo scopo.
ma nasce per poi essere compilato in JS.

[MItaly]

TypeScript è un linguaggio che compila in JavaScript, esattamente come diversi altri linguaggi; ti dà check e feature aggiuntive a compile time, ma alla fine diventa comunque JavaScript per cui puoi deployarlo su pagine normali.

quindi il vantaggio qual'è, "solo" quello di poter usare una sintassi OOP e tutte le caratteristiche aggiuntive?

Questa affermazione si applica a qualunque compilatore: qual è il vantaggio del C, "solo" quello di poter usare una sintassi procedurale e tutte le caratteristiche aggiuntive invece di programmare in assembly?

[Scara95]

TypeScript è un linguaggio che compila in JavaScript, esattamente come diversi altri linguaggi; ti dà check e feature aggiuntive a compile time, ma alla fine diventa comunque JavaScript per cui puoi deployarlo su pagine normali.

Questa affermazione si applica a qualunque compilatore: qual è il vantaggio del C, "solo" quello di poter usare una sintassi procedurale e tutte le caratteristiche aggiuntive invece di programmare in assembly?

Assembly? Quando cos'è? Non si programma a sequenze di byte?

[MItaly]

Assembly? Quando cos'è? Non si programma a sequenze di byte?

S'è fatto anche quello...

------------------------------------------------------------------------
r70491 | mitalia | 2016-01-25 11:07:31 +0100 (lun, 25 gen 2016) | 2 lines

Patch binaria a libmingwex.a per evitare la chiamata a getenv ad ogni printf (vedi http://stackoverflow.com/q/13970675/214671); per dettagli, vedi README.printf_binary_patch

------------------------------------------------------------------------

La build originale di questo MinGW è ancora affetta dal bug descritto a http://stackoverflow.com/q/13970675/214671.

Per mantenere compatibilità sia con MSVC e con glibc in MinGW hanno introdotto una variabile d'ambiente (PRINTF_EXPONENT_DIGITS) che modifica il numero di cifre decimali da stampare di default per il formato "%f"; purtroppo, viene effettuato il lookup tramite getenv ad ogni invocazione di printf e affini, per cui le funzioni di famiglia printf diventano inaccettabilmente lente (~8x per environment"normali" e stringhe di formato semplici).

Dato che il nostro software fa uso abbastanza massiccio di printf, per ovviare all'inconveniente senza ricompilare in blocco il MinGW (cosa non banale) ho patchato direttamente i binari della libreria standard.

IMPORTANTE: ho patchato *solo* la libreria statica, le dll fornite a corredo con il MinGW hanno ancora il comportamento originario.

La funzione in causa è __mingw_pformat in libmingwex.a, in particolare a 0x1699:

    1687:	31 c0                	xor    eax,eax
    1689:	66 89 44 24 50       	mov    WORD PTR [esp+0x50],ax
    168e:	8b 84 24 88 00 00 00 	mov    eax,DWORD PTR [esp+0x88]
    1695:	89 44 24 58          	mov    DWORD PTR [esp+0x58],eax
    1699:	e8 00 00 00 00       	call   169e <___mingw_pformat+0x8e>
    169e:	85 c0                	test   eax,eax
    16a0:	74 10                	je     16b2 <___mingw_pformat+0xa2>
    16a2:	0f be 10             	movsx  edx,BYTE PTR [eax]
    16a5:	b8 02 00 00 00       	mov    eax,0x2
    16aa:	83 ea 30             	sub    edx,0x30
    16ad:	83 fa 02             	cmp    edx,0x2
    16b0:	76 0d                	jbe    16bf <___mingw_pformat+0xaf>
    16b2:	e8 00 00 00 00       	call   16b7 <___mingw_pformat+0xa7>
    16b7:	83 e0 01             	and    eax,0x1

La call in questione nella libreria ha come target l'offset 0, ma è un placeholder che viene riempito dal linker con l'indirizzo del trampolino per la getenv (motivo per cui non si può semplicemente asfaltare con dei nop, il linker li sovrascriverebbe).

La modifica effettuata è:

    1687:	31 c0                	xor    eax,eax
    1689:	66 89 44 24 50       	mov    WORD PTR [esp+0x50],ax
    168e:	8b 84 24 88 00 00 00 	mov    eax,DWORD PTR [esp+0x88]
    1695:	89 44 24 58          	mov    DWORD PTR [esp+0x58],eax
    1699:	b8 00 00 00 00       	mov    eax,0x0
    169e:	85 c0                	test   eax,eax
    16a0:	75 10                	jne    16b2 <___mingw_pformat+0xa2>
    16a2:	0f be 10             	movsx  edx,BYTE PTR [eax]
    16a5:	b8 02 00 00 00       	mov    eax,0x2
    16aa:	83 ea 30             	sub    edx,0x30
    16ad:	83 fa 02             	cmp    edx,0x2
    16b0:	76 0d                	jbe    16bf <___mingw_pformat+0xaf>
    16b2:	e8 00 00 00 00       	call   16b7 <___mingw_pformat+0xa7>
    16b7:	83 e0 01             	and    eax,0x1

La call a 0x1699 diventa una mov (per cui in eax va a finire l'indirizzo del trampolino della getenv, sicuramente diverso da zero); la je a 0x16a0 invece diventa una jne. In questa maniera, attiviamo sempre il percorso di codice relativo al caso in cui getenv restituisce NULL (che è quello che di fatto verrebbe attivato sempre). L'unica differenza è che in questo caso eax resta diverso da zero, ma viene immediatamente sovrascritto dalla call a 0x16b2 (a cui punta la jne), quindi non è un problema.

[Scara95]

Certo che ogni volta che scrivi qualcosa su mingw salta fuori qualcosa di divertente e per certi versi ridicolo