Pagina 9 di 10 primaprima ... 7 8 9 10 ultimoultimo
Visualizzazione dei risultati da 81 a 90 su 95

Discussione: OT Programmazione - rolling release

  1. #81
    Quote Originariamente inviata da fermat Visualizza il messaggio
    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).

  2. #82
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,549
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    Unrelated: nuova macchina di build.

    (l'IP è ovviamente il .11 )
    lol
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

  3. #83
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,549
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    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:
    codice:
    (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)
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

  4. #84
    Nuovi angoli bui del C scoperti ieri:
    codice:
    void f(double a[restrict static 3][5]);
    questo minestrone di keyword è sintassi C99 valida
    https://stackoverflow.com/a/47378817/214671

  5. #85
    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??

  6. #86
    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.

  7. #87
    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?

  8. #88
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,549
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    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?
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

  9. #89
    Quote Originariamente inviata da Scara95 Visualizza il messaggio
    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:

    codice:
        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 è:

    codice:
        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.
    Ultima modifica di MItaly; 11-03-2018 a 17:35

  10. #90
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,549
    Certo che ogni volta che scrivi qualcosa su mingw salta fuori qualcosa di divertente e per certi versi ridicolo
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.