☺
Scritto da
altg
utente che non utiene
il 2014-11-01 01:05:43.0 alle 2014-11-01 01:05:43.0
Trollate totali: 11540
> > Sento delle scosse elettriche alle gambe.
>
> Sciatica incipiente?
> Ernia al disco (intervertebrale)?
> Pheocromocitoma?
Quasi me lo scordavo:
principio di sclerosi laterale amiotrofica?
>
> Sciatica incipiente?
> Ernia al disco (intervertebrale)?
> Pheocromocitoma?
Quasi me lo scordavo:
principio di sclerosi laterale amiotrofica?
Arricchimento culturale in Svezia in corso
Ad
https://www.breitbart.com/europe/2019/01/04/patient-placed-in-quarantine-after-suspected-ebola-case-in-sweden/
The Emergency Room of a Swedish hospital was closed down Friday morning after a patient recently returned from Africa arrived vomiting blood, a possible symptom of the deadly and contagious Ebola virus.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 01:05:05.0 alle 2014-11-01 01:05:05.0
Trollate totali: 11540
> Sento delle scosse elettriche alle gambe.
Sciatica incipiente?
Ernia al disco (intervertebrale)?
Pheocromocitoma?
Sciatica incipiente?
Ernia al disco (intervertebrale)?
Pheocromocitoma?
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 01:03:27.0 alle 2014-11-01 01:03:27.0
Trollate totali: 11540
> ALTG
>
>
>
http://it.m.wikipedia.org/wiki/Kombucha 
>
> Mai sentito parlare della Kombucha??
Mai sentita, in effetti.
La forma piu` raffinata di te` che bevo io e` l'estathe`.
>
>
>
>
> Mai sentito parlare della Kombucha??
Mai sentita, in effetti.
La forma piu` raffinata di te` che bevo io e` l'estathe`.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 01:00:27.0 alle 2014-11-01 01:00:27.0
Trollate totali: 11540
> > ...di dubbia utilita`, io ne ho trovato uno utile nel gruppo di vitamine B. Ho fatto uno studio a doppio cieco con me stesso (mi sono cecato due volte) e ho verificato che non sembra un effetto placebo. Cioe` no vabbe', intendevo che ho provato a smettere e riprendere, e pare che quando non prendo la pasticca di Be-Total la mattina, verso sera mi deprimo. Al massimo un paio di sere dopo.
> >
> > L'avevo iniziato a prendere in un momento di debolezza fisica, poi ho notato che mi faceva da antidepressivo e ho continuato. Strano ma vero. Casomai provatelo. Il Be-Total ha la B6, la B12, la B3, quella roba li`, e anche una cosa che si chiama nicotinamide e il cui nome mi fa sospettare che abbia parecchio in comune con la nicotina, anche se non ci capisco un cazzo.
>
> Invece di usufruire delle ottime benzodiazepine che ti sono state prescritte ti perdi dietro alle vitamine.
Quelle erano per quand'ero affetto da GAD, che poi e` mysteriosamente sparito, lasciando gradualmente il posto a una specie di malinconia pervasiva con punte di quasi-depressione. Certo, si puo` dire che quanto meno non mi annoio, ma insieme all'ansia era venuta a mancare l'entusiasmo d'inseguire inutili grandiosi progetti tipo l'Argent o L.in.oleum. Quella pasticchina sembra aver rimesso a posto le cose, per questo mi sento di consigliarla ai depressi del forum interessati a migliorare l'umore. In teoria sono vitamine che agiscono sul metabolismo: se ne avete solo meta`, magari vi fanno avere un bolismo intero e un effetto collaterale potrebbe essere quello di cambiare i nutrienti che arrivano anche al cervello... insomma sonasega™, qualcosa del genere.
Le benzodiazepine non le consiglio a nessuno: calmano senz'altro, ma ci sono forti sospetti che influiscano permanentemente sulle capacita` intellettive... va bene, non sara` una gran perdita ma appunto per quello, vista la scarsita`, meglio non buttare via niente. E poi stando a wikipedia mi pare di capire che diano dipendenze con crisi d'astinenza peggiori di quelle da tabacco.
La B12 m'era gia` capitato di prenderla in dosi massicce, sotto forma della famosa co-carnetina B12 a base di L-carnitene e B12, ma da sole quelle due robe non mi hanno mai fatto l'effetto dell'intero gruppo B. Siccome 'sta cosa della pasticchina va avanti da circa due mesi senza perdere colpi, comincio a sentirmi giustificato a pensare che funzioni davvero, almeno con me. Vi faro` sapere se smette di funzionare.
> >
> > L'avevo iniziato a prendere in un momento di debolezza fisica, poi ho notato che mi faceva da antidepressivo e ho continuato. Strano ma vero. Casomai provatelo. Il Be-Total ha la B6, la B12, la B3, quella roba li`, e anche una cosa che si chiama nicotinamide e il cui nome mi fa sospettare che abbia parecchio in comune con la nicotina, anche se non ci capisco un cazzo.
>
> Invece di usufruire delle ottime benzodiazepine che ti sono state prescritte ti perdi dietro alle vitamine.
Quelle erano per quand'ero affetto da GAD, che poi e` mysteriosamente sparito, lasciando gradualmente il posto a una specie di malinconia pervasiva con punte di quasi-depressione. Certo, si puo` dire che quanto meno non mi annoio, ma insieme all'ansia era venuta a mancare l'entusiasmo d'inseguire inutili grandiosi progetti tipo l'Argent o L.in.oleum. Quella pasticchina sembra aver rimesso a posto le cose, per questo mi sento di consigliarla ai depressi del forum interessati a migliorare l'umore. In teoria sono vitamine che agiscono sul metabolismo: se ne avete solo meta`, magari vi fanno avere un bolismo intero e un effetto collaterale potrebbe essere quello di cambiare i nutrienti che arrivano anche al cervello... insomma sonasega™, qualcosa del genere.
Le benzodiazepine non le consiglio a nessuno: calmano senz'altro, ma ci sono forti sospetti che influiscano permanentemente sulle capacita` intellettive... va bene, non sara` una gran perdita ma appunto per quello, vista la scarsita`, meglio non buttare via niente. E poi stando a wikipedia mi pare di capire che diano dipendenze con crisi d'astinenza peggiori di quelle da tabacco.
La B12 m'era gia` capitato di prenderla in dosi massicce, sotto forma della famosa co-carnetina B12 a base di L-carnitene e B12, ma da sole quelle due robe non mi hanno mai fatto l'effetto dell'intero gruppo B. Siccome 'sta cosa della pasticchina va avanti da circa due mesi senza perdere colpi, comincio a sentirmi giustificato a pensare che funzioni davvero, almeno con me. Vi faro` sapere se smette di funzionare.
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 21:54:17.0 alle 2014-10-31 21:54:17.0
Trollate totali: 11540
> > > 1. per capire (vagamente) cosa cazzo stai facendo ho dovuto leggere l'output del disassembler che hai postato
> >
> > Ci contavo: almeno quello aiutera` a familiarizzarsi.
> >
> > > 2. firstByte e` terminologia ambigua, si chiama most significant byte
> >
> > Qui si chiama first perche` non c'e` ambiguita` dovuta all'endianness. L'endianness della memoria di lavoro e` sempre big: quello piu` a sinistra e` il primo, poi c'e` il secondo, il terzo, il quarto e, sui processori a 64 bit, quinto sesto settimo e ottavo. Quindi non e` ambiguo definirlo in termini posizionali.
>
> IMHO "first" e` comunque ambiguo, msb no.
IMHO pero` msb e` meno comprensibile. Poi per carita`, mi va bene anche MSB e probabilmente nelle istruzioni avro` l'occasione di precisare che e` quello. Tanto piu` che non avremo neanche ambiguita` come l'LSD (Least Significant Doubleword).
> > > 3. mi pare di capire che se usi il nome di un registro con la lettera maiuscola lo dereferenzi -->
il (tra l'altro chi e` che setta EDI/w?)
> >
> > Esatto, anche se io la chiamo piu` tradizionalmente indirezione. Dereferenziare e` un termine connesso al C. L'indirezione con spiazzamento zero e` marcata sinteticamente dalla lettera maiuscola.
>
> Ma usare una cosa normale tipo * o [] o ?
Lo facevo, lo feci, lo facetti, ne feci le veci. In L.in.oleum 1, si scriveva b per intendere il registro b, e [b] per intendere il contenuto della locazione puntata da b. Ma la gente si confondeva lo stesso, in compenso tutte quelle quadre mi davano sui nervi perche` non potevo scrivere [b] in un carattere solo e mi si disallineavano le istruzioni. Io ho la paturnia degli allineamenti.
Comunque mi piace il nuovo schema:
- p significa il registro p
- P significa [p], indiretto con base p e spiazzamento zero
- p.1 significa [p+1]
- p.-1 significa [p-1]
- p.1.1 significa [p+1+1] cioe` [p+2]
- eccetera...
> > > 4. se la stringa di input non fosse 4-allineata (e non vedo per quale motivo una stringa di byte dovrebbe esserlo) non solo ti fai una marea di accessi disallineati (che ammazzerebbero, ad esempio, un ARM) ma potrebbe anche causare un segfault alla fine
> >
> > La stringa di input e` per forza allineata a una boundary di 4 byte, ovvero di un'unita` per come la definisce L.in.oleum (per distinguerla dal significato tradizionalmente confuso di "word"). L'allineamento e` dovuto al fatto che L.in.oleum in nessun punto permette accessi disallineati (in effetti andrebbe a nozze con gli ARM). Semplicemente non conosce i byte: i byte sono parti interne delle unita`.
>
> Quindi se uno volesse accedere ad un file mmappato ti ci devi contorcere attorno?
Be', se ci sono sequenze non allineate e vengono lette una volta sola, non ci sarebbe altro modo che contorcersi un po'. Riconosco che e` uno svantaggio, ma del resto indirizzare la memoria in unita` piuttosto che in bytes ha molti altri vantaggi.
> > > 5. non capisco perche' il codice sia scritto in modo da essere non-efficiente e non-leggibile, se fosse leggibile l'accesso sarebbe fatto byte per byte,
> >
> > Non puoi, altrimenti hai i disallineamenti e problemi di endianness di cui sopra. L.in.oleum sacrifica l'accesso byte per byte per evitare questo genere di problemi, che lo renderebbero irrimediabilmente non portabile (se cambiasse la endianness il sorgente sarebbe da buttare). E poi gli accessi disallineati non ammazzano solo gli ARM, ammazzano anche gli Intel superscalari dal Pentium in poi, che ormai sono CISC di nome, ma di fatto funzionano meglio se li si usa in modo molto simile a un RISC.
>
> Con "ammazzano" intendevo che se lo fai ti becchi un SIGBUS, AFAIK in amd64 ottieni un degradamento delle prestazioni e basta. BTW in ARM esistono anche LDRB/LDRH/STRB/STRH.
Poi dici che non t'interessa l'assembly.
> > > se fosse efficiente il loop con gli shift sulla maschera sarebbe parzialmente srotolato (e a naso mi sa che ci sono modi piu` efficienti di manipolare stringhe su x86)
> >
> > Intrinsecamente piu` efficienti, penso di no. Se stai pensando a cazzate come rep scasb stai pensando a roba dei tempi del 386, gia` il 486 avrebbe arrancato meno con cicli estesi. Per lo srotolamento, rendo atto che sarebbe un po' piu` efficiente, ma considera che le librerie di quel gruppo sono ottimizzate piu` per compattezza che per velocita`.
>
> Questo e` il modo in cui viene implemento da gcc:
>
>
>
> a occhio mi sembra parecchio piu` efficiente.
A occhio non ci ho capito una minchia.
La prima sequenza fino al "je", esclusa la prima istruzione, e` un ciclo che rileva byte posti a zero in un buffer che comincia a rsp (suppongo sia qualcosa di locale sullo stack), poi c'e` qualcos'altro che include delle mov predicate ma che mi sembra incompleto: da nessuna parte si direbbero presenti delle istruzioni di write-back. Legge soltanto? Si puo` avere il sorgente che ha prodotto quel frammento?
> > > 6. per quale motivo i caratteri delle tue stringhe sono di 32bit quando non supporti unicode? Anche se in un futuro dovessi supportare unicode, per quale motivo scegliere l'encoding massimamente inefficiente come default?
> >
> > Perche` i processori sono piu` veloci nel manipolare dati di dimensione pari alla loro word,
>
> I processori sono anche piu` veloci a manipolare cose che stanno nella cache e moltiplicare per 4 la dimensione di tutte le stringhe non aiuta.
Vero. A dirla tutta, per ora il fatto che il compilatore funzioni a passo singolo e non usi salti corti espande anche il codice riducendone la localita`, cosa che mi secca parecchio di piu` dei dati. Certo, sono svantaggi che posso tenere presenti, ma se non voglio inserire istruzioni che accedano ai singoli bytes, non ho alternative. Per il compilatore, prima o poi magari gli faro` fare un passo aggiuntivo per scorciare i salti.
> > perche` essendo che L.in.oleum manipola bytes solo come parti di una word mantenerle in memoria a una unita` per carattere e` infinitamente piu` comodo ed efficiente, e perche` se le volessi codificare scriverei una routine apposita prima di scaricarle da qualche parte.
> >
> > Figurati che se fosse compilato su un processore a 64 bit, ogni carattere prenderebbe 64 bit, una specie di inesistente UCS-8. Ma non e` appunto un fatto di avere piu` code points, e` proprio un fatto di allineamento puro e semplice. Non esistono bytes in L.in.oleum, dai tempi della prima versione, ne` possono esistere.
>
> Mi sembra una follia.
Per come la vedo io, e` l'idealizzare una macchina semplificata che indirizza, legge e scrive unita` discrete di dimensione piu` utile del singolo byte, ECCETTO nel caso di stringhe di testo grandi e di accesso frequente e casuale. Nel qual caso, pazienza: come diceva Ford Prefect, "si fottano le oche, non ci si puo` occupare di ogni dannata cosa".
> >
> > Ci contavo: almeno quello aiutera` a familiarizzarsi.
> >
> > > 2. firstByte e` terminologia ambigua, si chiama most significant byte
> >
> > Qui si chiama first perche` non c'e` ambiguita` dovuta all'endianness. L'endianness della memoria di lavoro e` sempre big: quello piu` a sinistra e` il primo, poi c'e` il secondo, il terzo, il quarto e, sui processori a 64 bit, quinto sesto settimo e ottavo. Quindi non e` ambiguo definirlo in termini posizionali.
>
> IMHO "first" e` comunque ambiguo, msb no.
IMHO pero` msb e` meno comprensibile. Poi per carita`, mi va bene anche MSB e probabilmente nelle istruzioni avro` l'occasione di precisare che e` quello. Tanto piu` che non avremo neanche ambiguita` come l'LSD (Least Significant Doubleword).
> > > 3. mi pare di capire che se usi il nome di un registro con la lettera maiuscola lo dereferenzi -->
il (tra l'altro chi e` che setta EDI/w?)> >
> > Esatto, anche se io la chiamo piu` tradizionalmente indirezione. Dereferenziare e` un termine connesso al C. L'indirezione con spiazzamento zero e` marcata sinteticamente dalla lettera maiuscola.
>
> Ma usare una cosa normale tipo * o [] o ?
Lo facevo, lo feci, lo facetti, ne feci le veci. In L.in.oleum 1, si scriveva b per intendere il registro b, e [b] per intendere il contenuto della locazione puntata da b. Ma la gente si confondeva lo stesso, in compenso tutte quelle quadre mi davano sui nervi perche` non potevo scrivere [b] in un carattere solo e mi si disallineavano le istruzioni. Io ho la paturnia degli allineamenti.
Comunque mi piace il nuovo schema:
- p significa il registro p
- P significa [p], indiretto con base p e spiazzamento zero
- p.1 significa [p+1]
- p.-1 significa [p-1]
- p.1.1 significa [p+1+1] cioe` [p+2]
- eccetera...
> > > 4. se la stringa di input non fosse 4-allineata (e non vedo per quale motivo una stringa di byte dovrebbe esserlo) non solo ti fai una marea di accessi disallineati (che ammazzerebbero, ad esempio, un ARM) ma potrebbe anche causare un segfault alla fine
> >
> > La stringa di input e` per forza allineata a una boundary di 4 byte, ovvero di un'unita` per come la definisce L.in.oleum (per distinguerla dal significato tradizionalmente confuso di "word"). L'allineamento e` dovuto al fatto che L.in.oleum in nessun punto permette accessi disallineati (in effetti andrebbe a nozze con gli ARM). Semplicemente non conosce i byte: i byte sono parti interne delle unita`.
>
> Quindi se uno volesse accedere ad un file mmappato ti ci devi contorcere attorno?
Be', se ci sono sequenze non allineate e vengono lette una volta sola, non ci sarebbe altro modo che contorcersi un po'. Riconosco che e` uno svantaggio, ma del resto indirizzare la memoria in unita` piuttosto che in bytes ha molti altri vantaggi.
> > > 5. non capisco perche' il codice sia scritto in modo da essere non-efficiente e non-leggibile, se fosse leggibile l'accesso sarebbe fatto byte per byte,
> >
> > Non puoi, altrimenti hai i disallineamenti e problemi di endianness di cui sopra. L.in.oleum sacrifica l'accesso byte per byte per evitare questo genere di problemi, che lo renderebbero irrimediabilmente non portabile (se cambiasse la endianness il sorgente sarebbe da buttare). E poi gli accessi disallineati non ammazzano solo gli ARM, ammazzano anche gli Intel superscalari dal Pentium in poi, che ormai sono CISC di nome, ma di fatto funzionano meglio se li si usa in modo molto simile a un RISC.
>
> Con "ammazzano" intendevo che se lo fai ti becchi un SIGBUS, AFAIK in amd64 ottieni un degradamento delle prestazioni e basta. BTW in ARM esistono anche LDRB/LDRH/STRB/STRH.
Poi dici che non t'interessa l'assembly.
> > > se fosse efficiente il loop con gli shift sulla maschera sarebbe parzialmente srotolato (e a naso mi sa che ci sono modi piu` efficienti di manipolare stringhe su x86)
> >
> > Intrinsecamente piu` efficienti, penso di no. Se stai pensando a cazzate come rep scasb stai pensando a roba dei tempi del 386, gia` il 486 avrebbe arrancato meno con cicli estesi. Per lo srotolamento, rendo atto che sarebbe un po' piu` efficiente, ma considera che le librerie di quel gruppo sono ottimizzate piu` per compattezza che per velocita`.
>
> Questo e` il modo in cui viene implemento da gcc:
>
>
> 0x000000000040054b <+43>: mov rdx,rsp > 0x000000000040054e <+46>: mov ecx,DWORD PTR [rdx] > 0x0000000000400550 <+48>: add rdx,0x4 > 0x0000000000400554 <+52>: lea eax,[rcx-0x1010101] > 0x000000000040055a <+58>: not ecx > 0x000000000040055c <+60>: and eax,ecx > 0x000000000040055e <+62>: and eax,0x80808080 > 0x0000000000400563 <+67>: je 0x40054e <main+46> > 0x0000000000400565 <+69>: mov ecx,eax > 0x0000000000400567 <+71>: mov esi,0x400734 > 0x000000000040056c <+76>: mov edi,0x1 > 0x0000000000400571 <+81>: shr ecx,0x10 > 0x0000000000400574 <+84>: test eax,0x8080 > 0x0000000000400579 <+89>: cmove eax,ecx > 0x000000000040057c <+92>: lea rcx,[rdx+0x2] > 0x0000000000400580 <+96>: cmove rdx,rcx > 0x0000000000400584 <+100>: add al,al > 0x0000000000400586 <+102>: sbb rdx,0x3 > 0x000000000040058a <+106>: xor eax,eax > 0x000000000040058c <+108>: sub rdx,rbx >
>
> a occhio mi sembra parecchio piu` efficiente.
A occhio non ci ho capito una minchia.
La prima sequenza fino al "je", esclusa la prima istruzione, e` un ciclo che rileva byte posti a zero in un buffer che comincia a rsp (suppongo sia qualcosa di locale sullo stack), poi c'e` qualcos'altro che include delle mov predicate ma che mi sembra incompleto: da nessuna parte si direbbero presenti delle istruzioni di write-back. Legge soltanto? Si puo` avere il sorgente che ha prodotto quel frammento?
> > > 6. per quale motivo i caratteri delle tue stringhe sono di 32bit quando non supporti unicode? Anche se in un futuro dovessi supportare unicode, per quale motivo scegliere l'encoding massimamente inefficiente come default?
> >
> > Perche` i processori sono piu` veloci nel manipolare dati di dimensione pari alla loro word,
>
> I processori sono anche piu` veloci a manipolare cose che stanno nella cache e moltiplicare per 4 la dimensione di tutte le stringhe non aiuta.
Vero. A dirla tutta, per ora il fatto che il compilatore funzioni a passo singolo e non usi salti corti espande anche il codice riducendone la localita`, cosa che mi secca parecchio di piu` dei dati. Certo, sono svantaggi che posso tenere presenti, ma se non voglio inserire istruzioni che accedano ai singoli bytes, non ho alternative. Per il compilatore, prima o poi magari gli faro` fare un passo aggiuntivo per scorciare i salti.
> > perche` essendo che L.in.oleum manipola bytes solo come parti di una word mantenerle in memoria a una unita` per carattere e` infinitamente piu` comodo ed efficiente, e perche` se le volessi codificare scriverei una routine apposita prima di scaricarle da qualche parte.
> >
> > Figurati che se fosse compilato su un processore a 64 bit, ogni carattere prenderebbe 64 bit, una specie di inesistente UCS-8. Ma non e` appunto un fatto di avere piu` code points, e` proprio un fatto di allineamento puro e semplice. Non esistono bytes in L.in.oleum, dai tempi della prima versione, ne` possono esistere.
>
> Mi sembra una follia.
Per come la vedo io, e` l'idealizzare una macchina semplificata che indirizza, legge e scrive unita` discrete di dimensione piu` utile del singolo byte, ECCETTO nel caso di stringhe di testo grandi e di accesso frequente e casuale. Nel qual caso, pazienza: come diceva Ford Prefect, "si fottano le oche, non ci si puo` occupare di ogni dannata cosa".
Il coraggio degli asiatici
Ad
https://imgur.com/iYd5ZkJ
Cinesi salvano Gatto Selvaggio da sicuro annegamento, altro che musulmani!
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 20:46:09.0 alle 2014-10-31 20:46:09.0
Trollate totali: 11540
> > Non ci ho capito quasi una minchia. 
> > Come sarebbe non usare POST per scrivere... cosa?
>
> Ho sbagliato: era usare sempre POST, all'inizio mi stavo mettendo a parlare di metodi idempotenti, il non mi è rimasto là.
>
> > La mia Top 1 (uno e basta) per evitare hackeraggi e` sempre stata "tanto scrivo tutto io, sicche` chi deve hackerare deve prima capire come funziona tutta la baracca, mica trova gli exploit pronti".
>
> Infatti frenchi in un nanosecondo ti aveva trovato i buchi di postline
Non me li dite, tanto non ho voglia di tapparli...
ormai conviene finire tutto a martellate e poi riscriverlo in linoleum
> > Come sarebbe non usare POST per scrivere... cosa?
>
> Ho sbagliato: era usare sempre POST, all'inizio mi stavo mettendo a parlare di metodi idempotenti, il non mi è rimasto là.
>
> > La mia Top 1 (uno e basta) per evitare hackeraggi e` sempre stata "tanto scrivo tutto io, sicche` chi deve hackerare deve prima capire come funziona tutta la baracca, mica trova gli exploit pronti".
>
> Infatti frenchi in un nanosecondo ti aveva trovato i buchi di postline
Non me li dite, tanto non ho voglia di tapparli...
ormai conviene finire tutto a martellate e poi riscriverlo in linoleum
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 20:10:17.0 alle 2014-10-31 20:10:17.0
Trollate totali: 11540
> > Ai tempi in cui me n'ero occupato si fondeva con il problema dell'erronea trasmissione di certi caratteri da parte dei browser (un baco forse risalente a Mosaic) per cui conveniva trasformare in entità via Javascript tutti i caratteri non lower ASCII, e anche qualcuno lower ASCII, prima di trasmetterli al server.
>
> Succede ancora oggi con IE che non onora il page encoding quando invia i form, a meno che non gli infili tra i dati da inviare un carattere tipo snowman o pile of poo che non sta nelle tabelle caratteri non unicode.
>
> > Suppongo che oggi i browser trasmettano correttamente tutti i caratteri Unicode, e allora mi chiedo, come dev'essere fatta oggi questa igienizzazione? Col Viakal?
> >
> > Una volta che la stringa inserita in un campo INPUT o TEXTAREA o altro è ricevuta dal server, questo che deve fare per evitare iniezioni di codice o altri problemi? Convertire in entità i caratteri aventi un significato particolare in HTML, JS e PHP, e opzionalmente tutto ciò che eccede il lower ASCII per prevenire problemi di encoding?
>
> Il trasporto dal browser al server avviene solitamente mediante percent encoding fatta dal browser (enctype application/x-www-form-urlencoded). Devi trasportare la stringa ricevuta, opportunamente trattata dal framework server che si usa, possibilmente così com'è (non come sul fdt) e escapare l'output con le apposite funzioni. Se usi un db usa sempre i prepared statement. Non fidarti del client per niente che non sia il mero dato richiesto, abusa della sessione utente (praticamente tutti i framework web la mettono a disposizione). Le operazioni di scrittura non vanno fatte con metodo http POST (verificalo sempre) per evitare che un link malevolo possa eseguire operazioni non desiderate.
> Il tuo punto di partenza comunque è owasp top 10 per le vulnerabilità più diffuse e i rimedi da usare: https://www.owasp.org/index.php/Category:OWASP_Top...
Non ci ho capito quasi una minchia.
Come sarebbe non usare POST per scrivere... cosa?
La mia Top 1 (uno e basta) per evitare hackeraggi e` sempre stata "tanto scrivo tutto io, sicche` chi deve hackerare deve prima capire come funziona tutta la baracca, mica trova gli exploit pronti".
>
> Succede ancora oggi con IE che non onora il page encoding quando invia i form, a meno che non gli infili tra i dati da inviare un carattere tipo snowman o pile of poo che non sta nelle tabelle caratteri non unicode.
>
> > Suppongo che oggi i browser trasmettano correttamente tutti i caratteri Unicode, e allora mi chiedo, come dev'essere fatta oggi questa igienizzazione? Col Viakal?
> >
> > Una volta che la stringa inserita in un campo INPUT o TEXTAREA o altro è ricevuta dal server, questo che deve fare per evitare iniezioni di codice o altri problemi? Convertire in entità i caratteri aventi un significato particolare in HTML, JS e PHP, e opzionalmente tutto ciò che eccede il lower ASCII per prevenire problemi di encoding?
>
> Il trasporto dal browser al server avviene solitamente mediante percent encoding fatta dal browser (enctype application/x-www-form-urlencoded). Devi trasportare la stringa ricevuta, opportunamente trattata dal framework server che si usa, possibilmente così com'è (non come sul fdt) e escapare l'output con le apposite funzioni. Se usi un db usa sempre i prepared statement. Non fidarti del client per niente che non sia il mero dato richiesto, abusa della sessione utente (praticamente tutti i framework web la mettono a disposizione). Le operazioni di scrittura non vanno fatte con metodo http POST (verificalo sempre) per evitare che un link malevolo possa eseguire operazioni non desiderate.
> Il tuo punto di partenza comunque è owasp top 10 per le vulnerabilità più diffuse e i rimedi da usare: https://www.owasp.org/index.php/Category:OWASP_Top...
Non ci ho capito quasi una minchia.
Come sarebbe non usare POST per scrivere... cosa?
La mia Top 1 (uno e basta) per evitare hackeraggi e` sempre stata "tanto scrivo tutto io, sicche` chi deve hackerare deve prima capire come funziona tutta la baracca, mica trova gli exploit pronti".
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 19:05:59.0 alle 2014-10-31 19:05:59.0
Trollate totali: 11540
> Ai tempi in cui me n'ero occupato si fondeva con il problema dell'erronea trasmissione di certi caratteri da parte dei browser (un baco forse risalente a Mosaic) per cui conveniva trasformare in entità via Javascript tutti i caratteri non lower ASCII, e anche qualcuno lower ASCII, prima di trasmetterli al server.
>
> Suppongo che oggi i browser trasmettano correttamente tutti i caratteri Unicode, e allora mi chiedo, come dev'essere fatta oggi questa igienizzazione? Col Viakal?
>
> Una volta che la stringa inserita in un campo INPUT o TEXTAREA o altro è ricevuta dal server, questo che deve fare per evitare iniezioni di codice o altri problemi? Convertire in entità i caratteri aventi un significato particolare in HTML, JS e PHP, e opzionalmente tutto ciò che eccede il lower ASCII per prevenire problemi di encoding?
Che cos'e` il "lower ASCII"? Il vero ASCII e` a 7 bit allineati a 8. Tutto quello che supera 127 non e` piu` ASCII. Le accentate in qualsiasi codifica non sono ASCII, al massimo un ASCII esteso. Per me ehm... l'unicode non esiste sicche` non mi pongo il problema. Escapo & < > ' ", taglio tutto quello che non e` un tab un cr o un lf sotto allo spazio, e tutto quello che e` sopra 126, e chi c'e` c'e` chi non c'e` s'arrangia.
>
> Suppongo che oggi i browser trasmettano correttamente tutti i caratteri Unicode, e allora mi chiedo, come dev'essere fatta oggi questa igienizzazione? Col Viakal?
>
> Una volta che la stringa inserita in un campo INPUT o TEXTAREA o altro è ricevuta dal server, questo che deve fare per evitare iniezioni di codice o altri problemi? Convertire in entità i caratteri aventi un significato particolare in HTML, JS e PHP, e opzionalmente tutto ciò che eccede il lower ASCII per prevenire problemi di encoding?
Che cos'e` il "lower ASCII"? Il vero ASCII e` a 7 bit allineati a 8. Tutto quello che supera 127 non e` piu` ASCII. Le accentate in qualsiasi codifica non sono ASCII, al massimo un ASCII esteso. Per me ehm... l'unicode non esiste sicche` non mi pongo il problema. Escapo & < > ' ", taglio tutto quello che non e` un tab un cr o un lf sotto allo spazio, e tutto quello che e` sopra 126, e chi c'e` c'e` chi non c'e` s'arrangia.
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 18:59:49.0 alle 2014-10-31 18:59:49.0
Trollate totali: 11540
...di dubbia utilita`, io ne ho trovato uno utile nel gruppo di vitamine B. Ho fatto uno studio a doppio cieco con me stesso (mi sono cecato due volte) e ho verificato che non sembra un effetto placebo. Cioe` no vabbe', intendevo che ho provato a smettere e riprendere, e pare che quando non prendo la pasticca di Be-Total la mattina, verso sera mi deprimo. Al massimo un paio di sere dopo.
L'avevo iniziato a prendere in un momento di debolezza fisica, poi ho notato che mi faceva da antidepressivo e ho continuato. Strano ma vero. Casomai provatelo. Il Be-Total ha la B6, la B12, la B3, quella roba li`, e anche una cosa che si chiama nicotinamide e il cui nome mi fa sospettare che abbia parecchio in comune con la nicotina, anche se non ci capisco un cazzo.
L'avevo iniziato a prendere in un momento di debolezza fisica, poi ho notato che mi faceva da antidepressivo e ho continuato. Strano ma vero. Casomai provatelo. Il Be-Total ha la B6, la B12, la B3, quella roba li`, e anche una cosa che si chiama nicotinamide e il cui nome mi fa sospettare che abbia parecchio in comune con la nicotina, anche se non ci capisco un cazzo.
Vieni anche tu a fare autostop in merio oriente!!!
Ad
https://imgoat.com/uploads/cdd60ea004/183004.png
Non lasciarti scappare questa occasione più unica che rara di conoscere nuove culture e la gentilezza dei taxisti che provano a stuprarti ma a metà opera se ne pentono e ti lasciano in mezzo ad un bosco!
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 17:50:49.0 alle 2014-10-31 17:50:49.0
Trollate totali: 11540
> > > > > 1. per capire (vagamente) cosa cazzo stai facendo ho dovuto leggere l'output del disassembler che hai postato
> > > >
> > > > Ci contavo: almeno quello aiutera` a familiarizzarsi.
> > > >
> > > > > 2. firstByte e` terminologia ambigua, si chiama most significant byte
> > > >
> > > > Qui si chiama first perche` non c'e` ambiguita` dovuta all'endianness. L'endianness della memoria di lavoro e` sempre big: quello piu` a sinistra e` il primo, poi c'e` il secondo, il terzo, il quarto e, sui processori a 64 bit, quinto sesto settimo e ottavo. Quindi non e` ambiguo definirlo in termini posizionali.
> > > >
> > > > > 3. mi pare di capire che se usi il nome di un registro con la lettera maiuscola lo dereferenzi -->il (tra l'altro chi e` che setta EDI/w?)
> > > >
> > > > Esatto, anche se io la chiamo piu` tradizionalmente indirezione. Dereferenziare e` un termine connesso al C. L'indirezione con spiazzamento zero e` marcata sinteticamente dalla lettera maiuscola.
> > > >
> > > > > 4. se la stringa di input non fosse 4-allineata (e non vedo per quale motivo una stringa di byte dovrebbe esserlo) non solo ti fai una marea di accessi disallineati (che ammazzerebbero, ad esempio, un ARM) ma potrebbe anche causare un segfault alla fine
> > > >
> > > > La stringa di input e` per forza allineata a una boundary di 4 byte, ovvero di un'unita` per come la definisce L.in.oleum (per distinguerla dal significato tradizionalmente confuso di "word"). L'allineamento e` dovuto al fatto che L.in.oleum in nessun punto permette accessi disallineati (in effetti andrebbe a nozze con gli ARM). Semplicemente non conosce i byte: i byte sono parti interne delle unita`.
> > > >
> > > > > 5. non capisco perche' il codice sia scritto in modo da essere non-efficiente e non-leggibile, se fosse leggibile l'accesso sarebbe fatto byte per byte,
> > > >
> > > > Non puoi, altrimenti hai i disallineamenti e problemi di endianness di cui sopra. L.in.oleum sacrifica l'accesso byte per byte per evitare questo genere di problemi, che lo renderebbero irrimediabilmente non portabile (se cambiasse la endianness il sorgente sarebbe da buttare). E poi gli accessi disallineati non ammazzano solo gli ARM, ammazzano anche gli Intel superscalari dal Pentium in poi, che ormai sono CISC di nome, ma di fatto funzionano meglio se li si usa in modo molto simile a un RISC.
> > > >
> > > > > se fosse efficiente il loop con gli shift sulla maschera sarebbe parzialmente srotolato (e a naso mi sa che ci sono modi piu` efficienti di manipolare stringhe su x86)
> > > >
> > > > Intrinsecamente piu` efficienti, penso di no. Se stai pensando a cazzate come rep scasb stai pensando a roba dei tempi del 386, gia` il 486 avrebbe arrancato meno con cicli estesi. Per lo srotolamento, rendo atto che sarebbe un po' piu` efficiente, ma considera che le librerie di quel gruppo sono ottimizzate piu` per compattezza che per velocita`.
> > > >
> > > > > 6. per quale motivo i caratteri delle tue stringhe sono di 32bit quando non supporti unicode? Anche se in un futuro dovessi supportare unicode, per quale motivo scegliere l'encoding massimamente inefficiente come default?
> > > >
> > > > Perche` i processori sono piu` veloci nel manipolare dati di dimensione pari alla loro word, perche` essendo che L.in.oleum manipola bytes solo come parti di una word mantenerle in memoria a una unita` per carattere e` infinitamente piu` comodo ed efficiente, e perche` se le volessi codificare scriverei una routine apposita prima di scaricarle da qualche parte.
> > > >
> > > > Figurati che se fosse compilato su un processore a 64 bit, ogni carattere prenderebbe 64 bit, una specie di inesistente UCS-8. Ma non e` appunto un fatto di avere piu` code points, e` proprio un fatto di allineamento puro e semplice. Non esistono bytes in L.in.oleum, dai tempi della prima versione, ne` possono esistere.
> > >
> > > un utilizzo efficientissimo della memoria fisica
> >
> > Filiolo, che pensi di doverci mantenere, in termini di testo non compresso o non codificato (cioe` su cui devi lavorare prontamente) nella memoria di lavoro? Il database di Wikipedia?
>
> boh
Allora ricapitolo gentilmente io: quando fai lavorare il processore su del testo in memoria di lavoro in un compito che dev'essere efficiente, di solito non e` su una serie di 50 copie della divina commedia, ma su relativamente poche stringhe. Nel 99% dei casi non ha molta importanza come sono rappresentate in memoria, perche` se le stringhe sono massiccie vengono lasciate altrove, in memoria di massa o chi per lei, dove si puo` comunque scegliere la codifica piu` opportuna, inclusi vari algoritmi di compressione dal deflate in su. Dove conta il volume, il testo puo` tranquillamente prendere molto meno di 8 bit per carattere. In memoria, poco importa se ne prende 32 o 64.
> > > >
> > > > Ci contavo: almeno quello aiutera` a familiarizzarsi.
> > > >
> > > > > 2. firstByte e` terminologia ambigua, si chiama most significant byte
> > > >
> > > > Qui si chiama first perche` non c'e` ambiguita` dovuta all'endianness. L'endianness della memoria di lavoro e` sempre big: quello piu` a sinistra e` il primo, poi c'e` il secondo, il terzo, il quarto e, sui processori a 64 bit, quinto sesto settimo e ottavo. Quindi non e` ambiguo definirlo in termini posizionali.
> > > >
> > > > > 3. mi pare di capire che se usi il nome di un registro con la lettera maiuscola lo dereferenzi -->
il (tra l'altro chi e` che setta EDI/w?)> > > >
> > > > Esatto, anche se io la chiamo piu` tradizionalmente indirezione. Dereferenziare e` un termine connesso al C. L'indirezione con spiazzamento zero e` marcata sinteticamente dalla lettera maiuscola.
> > > >
> > > > > 4. se la stringa di input non fosse 4-allineata (e non vedo per quale motivo una stringa di byte dovrebbe esserlo) non solo ti fai una marea di accessi disallineati (che ammazzerebbero, ad esempio, un ARM) ma potrebbe anche causare un segfault alla fine
> > > >
> > > > La stringa di input e` per forza allineata a una boundary di 4 byte, ovvero di un'unita` per come la definisce L.in.oleum (per distinguerla dal significato tradizionalmente confuso di "word"). L'allineamento e` dovuto al fatto che L.in.oleum in nessun punto permette accessi disallineati (in effetti andrebbe a nozze con gli ARM). Semplicemente non conosce i byte: i byte sono parti interne delle unita`.
> > > >
> > > > > 5. non capisco perche' il codice sia scritto in modo da essere non-efficiente e non-leggibile, se fosse leggibile l'accesso sarebbe fatto byte per byte,
> > > >
> > > > Non puoi, altrimenti hai i disallineamenti e problemi di endianness di cui sopra. L.in.oleum sacrifica l'accesso byte per byte per evitare questo genere di problemi, che lo renderebbero irrimediabilmente non portabile (se cambiasse la endianness il sorgente sarebbe da buttare). E poi gli accessi disallineati non ammazzano solo gli ARM, ammazzano anche gli Intel superscalari dal Pentium in poi, che ormai sono CISC di nome, ma di fatto funzionano meglio se li si usa in modo molto simile a un RISC.
> > > >
> > > > > se fosse efficiente il loop con gli shift sulla maschera sarebbe parzialmente srotolato (e a naso mi sa che ci sono modi piu` efficienti di manipolare stringhe su x86)
> > > >
> > > > Intrinsecamente piu` efficienti, penso di no. Se stai pensando a cazzate come rep scasb stai pensando a roba dei tempi del 386, gia` il 486 avrebbe arrancato meno con cicli estesi. Per lo srotolamento, rendo atto che sarebbe un po' piu` efficiente, ma considera che le librerie di quel gruppo sono ottimizzate piu` per compattezza che per velocita`.
> > > >
> > > > > 6. per quale motivo i caratteri delle tue stringhe sono di 32bit quando non supporti unicode? Anche se in un futuro dovessi supportare unicode, per quale motivo scegliere l'encoding massimamente inefficiente come default?
> > > >
> > > > Perche` i processori sono piu` veloci nel manipolare dati di dimensione pari alla loro word, perche` essendo che L.in.oleum manipola bytes solo come parti di una word mantenerle in memoria a una unita` per carattere e` infinitamente piu` comodo ed efficiente, e perche` se le volessi codificare scriverei una routine apposita prima di scaricarle da qualche parte.
> > > >
> > > > Figurati che se fosse compilato su un processore a 64 bit, ogni carattere prenderebbe 64 bit, una specie di inesistente UCS-8. Ma non e` appunto un fatto di avere piu` code points, e` proprio un fatto di allineamento puro e semplice. Non esistono bytes in L.in.oleum, dai tempi della prima versione, ne` possono esistere.
> > >
> > > un utilizzo efficientissimo della memoria fisica
> >
> > Filiolo, che pensi di doverci mantenere, in termini di testo non compresso o non codificato (cioe` su cui devi lavorare prontamente) nella memoria di lavoro? Il database di Wikipedia?
>
> boh
Allora ricapitolo gentilmente io: quando fai lavorare il processore su del testo in memoria di lavoro in un compito che dev'essere efficiente, di solito non e` su una serie di 50 copie della divina commedia, ma su relativamente poche stringhe. Nel 99% dei casi non ha molta importanza come sono rappresentate in memoria, perche` se le stringhe sono massiccie vengono lasciate altrove, in memoria di massa o chi per lei, dove si puo` comunque scegliere la codifica piu` opportuna, inclusi vari algoritmi di compressione dal deflate in su. Dove conta il volume, il testo puo` tranquillamente prendere molto meno di 8 bit per carattere. In memoria, poco importa se ne prende 32 o 64.
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 17:28:19.0 alle 2014-10-31 17:28:19.0
Trollate totali: 11540
> > > 1. per capire (vagamente) cosa cazzo stai facendo ho dovuto leggere l'output del disassembler che hai postato
> >
> > Ci contavo: almeno quello aiutera` a familiarizzarsi.
> >
> > > 2. firstByte e` terminologia ambigua, si chiama most significant byte
> >
> > Qui si chiama first perche` non c'e` ambiguita` dovuta all'endianness. L'endianness della memoria di lavoro e` sempre big: quello piu` a sinistra e` il primo, poi c'e` il secondo, il terzo, il quarto e, sui processori a 64 bit, quinto sesto settimo e ottavo. Quindi non e` ambiguo definirlo in termini posizionali.
> >
> > > 3. mi pare di capire che se usi il nome di un registro con la lettera maiuscola lo dereferenzi -->il (tra l'altro chi e` che setta EDI/w?)
> >
> > Esatto, anche se io la chiamo piu` tradizionalmente indirezione. Dereferenziare e` un termine connesso al C. L'indirezione con spiazzamento zero e` marcata sinteticamente dalla lettera maiuscola.
> >
> > > 4. se la stringa di input non fosse 4-allineata (e non vedo per quale motivo una stringa di byte dovrebbe esserlo) non solo ti fai una marea di accessi disallineati (che ammazzerebbero, ad esempio, un ARM) ma potrebbe anche causare un segfault alla fine
> >
> > La stringa di input e` per forza allineata a una boundary di 4 byte, ovvero di un'unita` per come la definisce L.in.oleum (per distinguerla dal significato tradizionalmente confuso di "word"). L'allineamento e` dovuto al fatto che L.in.oleum in nessun punto permette accessi disallineati (in effetti andrebbe a nozze con gli ARM). Semplicemente non conosce i byte: i byte sono parti interne delle unita`.
> >
> > > 5. non capisco perche' il codice sia scritto in modo da essere non-efficiente e non-leggibile, se fosse leggibile l'accesso sarebbe fatto byte per byte,
> >
> > Non puoi, altrimenti hai i disallineamenti e problemi di endianness di cui sopra. L.in.oleum sacrifica l'accesso byte per byte per evitare questo genere di problemi, che lo renderebbero irrimediabilmente non portabile (se cambiasse la endianness il sorgente sarebbe da buttare). E poi gli accessi disallineati non ammazzano solo gli ARM, ammazzano anche gli Intel superscalari dal Pentium in poi, che ormai sono CISC di nome, ma di fatto funzionano meglio se li si usa in modo molto simile a un RISC.
> >
> > > se fosse efficiente il loop con gli shift sulla maschera sarebbe parzialmente srotolato (e a naso mi sa che ci sono modi piu` efficienti di manipolare stringhe su x86)
> >
> > Intrinsecamente piu` efficienti, penso di no. Se stai pensando a cazzate come rep scasb stai pensando a roba dei tempi del 386, gia` il 486 avrebbe arrancato meno con cicli estesi. Per lo srotolamento, rendo atto che sarebbe un po' piu` efficiente, ma considera che le librerie di quel gruppo sono ottimizzate piu` per compattezza che per velocita`.
> >
> > > 6. per quale motivo i caratteri delle tue stringhe sono di 32bit quando non supporti unicode? Anche se in un futuro dovessi supportare unicode, per quale motivo scegliere l'encoding massimamente inefficiente come default?
> >
> > Perche` i processori sono piu` veloci nel manipolare dati di dimensione pari alla loro word, perche` essendo che L.in.oleum manipola bytes solo come parti di una word mantenerle in memoria a una unita` per carattere e` infinitamente piu` comodo ed efficiente, e perche` se le volessi codificare scriverei una routine apposita prima di scaricarle da qualche parte.
> >
> > Figurati che se fosse compilato su un processore a 64 bit, ogni carattere prenderebbe 64 bit, una specie di inesistente UCS-8. Ma non e` appunto un fatto di avere piu` code points, e` proprio un fatto di allineamento puro e semplice. Non esistono bytes in L.in.oleum, dai tempi della prima versione, ne` possono esistere.
>
> un utilizzo efficientissimo della memoria fisica
Filiolo, che pensi di doverci mantenere, in termini di testo non compresso o non codificato (cioe` su cui devi lavorare prontamente) nella memoria di lavoro? Il database di Wikipedia?
> >
> > Ci contavo: almeno quello aiutera` a familiarizzarsi.
> >
> > > 2. firstByte e` terminologia ambigua, si chiama most significant byte
> >
> > Qui si chiama first perche` non c'e` ambiguita` dovuta all'endianness. L'endianness della memoria di lavoro e` sempre big: quello piu` a sinistra e` il primo, poi c'e` il secondo, il terzo, il quarto e, sui processori a 64 bit, quinto sesto settimo e ottavo. Quindi non e` ambiguo definirlo in termini posizionali.
> >
> > > 3. mi pare di capire che se usi il nome di un registro con la lettera maiuscola lo dereferenzi -->
il (tra l'altro chi e` che setta EDI/w?)> >
> > Esatto, anche se io la chiamo piu` tradizionalmente indirezione. Dereferenziare e` un termine connesso al C. L'indirezione con spiazzamento zero e` marcata sinteticamente dalla lettera maiuscola.
> >
> > > 4. se la stringa di input non fosse 4-allineata (e non vedo per quale motivo una stringa di byte dovrebbe esserlo) non solo ti fai una marea di accessi disallineati (che ammazzerebbero, ad esempio, un ARM) ma potrebbe anche causare un segfault alla fine
> >
> > La stringa di input e` per forza allineata a una boundary di 4 byte, ovvero di un'unita` per come la definisce L.in.oleum (per distinguerla dal significato tradizionalmente confuso di "word"). L'allineamento e` dovuto al fatto che L.in.oleum in nessun punto permette accessi disallineati (in effetti andrebbe a nozze con gli ARM). Semplicemente non conosce i byte: i byte sono parti interne delle unita`.
> >
> > > 5. non capisco perche' il codice sia scritto in modo da essere non-efficiente e non-leggibile, se fosse leggibile l'accesso sarebbe fatto byte per byte,
> >
> > Non puoi, altrimenti hai i disallineamenti e problemi di endianness di cui sopra. L.in.oleum sacrifica l'accesso byte per byte per evitare questo genere di problemi, che lo renderebbero irrimediabilmente non portabile (se cambiasse la endianness il sorgente sarebbe da buttare). E poi gli accessi disallineati non ammazzano solo gli ARM, ammazzano anche gli Intel superscalari dal Pentium in poi, che ormai sono CISC di nome, ma di fatto funzionano meglio se li si usa in modo molto simile a un RISC.
> >
> > > se fosse efficiente il loop con gli shift sulla maschera sarebbe parzialmente srotolato (e a naso mi sa che ci sono modi piu` efficienti di manipolare stringhe su x86)
> >
> > Intrinsecamente piu` efficienti, penso di no. Se stai pensando a cazzate come rep scasb stai pensando a roba dei tempi del 386, gia` il 486 avrebbe arrancato meno con cicli estesi. Per lo srotolamento, rendo atto che sarebbe un po' piu` efficiente, ma considera che le librerie di quel gruppo sono ottimizzate piu` per compattezza che per velocita`.
> >
> > > 6. per quale motivo i caratteri delle tue stringhe sono di 32bit quando non supporti unicode? Anche se in un futuro dovessi supportare unicode, per quale motivo scegliere l'encoding massimamente inefficiente come default?
> >
> > Perche` i processori sono piu` veloci nel manipolare dati di dimensione pari alla loro word, perche` essendo che L.in.oleum manipola bytes solo come parti di una word mantenerle in memoria a una unita` per carattere e` infinitamente piu` comodo ed efficiente, e perche` se le volessi codificare scriverei una routine apposita prima di scaricarle da qualche parte.
> >
> > Figurati che se fosse compilato su un processore a 64 bit, ogni carattere prenderebbe 64 bit, una specie di inesistente UCS-8. Ma non e` appunto un fatto di avere piu` code points, e` proprio un fatto di allineamento puro e semplice. Non esistono bytes in L.in.oleum, dai tempi della prima versione, ne` possono esistere.
>
> un utilizzo efficientissimo della memoria fisica
Filiolo, che pensi di doverci mantenere, in termini di testo non compresso o non codificato (cioe` su cui devi lavorare prontamente) nella memoria di lavoro? Il database di Wikipedia?
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 17:24:21.0 alle 2014-10-31 17:24:21.0
Trollate totali: 11540
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 17:14:41.0 alle 2014-10-31 17:14:41.0
Trollate totali: 11540
> > 6. per quale motivo i caratteri delle tue stringhe sono di 32bit quando non supporti unicode? Anche se in un futuro dovessi supportare unicode, per quale motivo scegliere l'encoding massimamente inefficiente come default?
> >
>
> Sono curioso di vedere come si barcamena su questa.
Figliolo, io su questi argomenti non mi barcameno.
Vi meno e basta.
> >
>
> Sono curioso di vedere come si barcamena su questa.
Figliolo, io su questi argomenti non mi barcameno.
Vi meno e basta.
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 17:14:06.0 alle 2014-10-31 17:14:06.0
Trollate totali: 11540
> 1. per capire (vagamente) cosa cazzo stai facendo ho dovuto leggere l'output del disassembler che hai postato
Ci contavo: almeno quello aiutera` a familiarizzarsi.
> 2. firstByte e` terminologia ambigua, si chiama most significant byte
Qui si chiama first perche` non c'e` ambiguita` dovuta all'endianness. L'endianness della memoria di lavoro e` sempre big: quello piu` a sinistra e` il primo, poi c'e` il secondo, il terzo, il quarto e, sui processori a 64 bit, quinto sesto settimo e ottavo. Quindi non e` ambiguo definirlo in termini posizionali.
> 3. mi pare di capire che se usi il nome di un registro con la lettera maiuscola lo dereferenzi -->il (tra l'altro chi e` che setta EDI/w?)
Esatto, anche se io la chiamo piu` tradizionalmente indirezione. Dereferenziare e` un termine connesso al C. L'indirezione con spiazzamento zero e` marcata sinteticamente dalla lettera maiuscola.
> 4. se la stringa di input non fosse 4-allineata (e non vedo per quale motivo una stringa di byte dovrebbe esserlo) non solo ti fai una marea di accessi disallineati (che ammazzerebbero, ad esempio, un ARM) ma potrebbe anche causare un segfault alla fine
La stringa di input e` per forza allineata a una boundary di 4 byte, ovvero di un'unita` per come la definisce L.in.oleum (per distinguerla dal significato tradizionalmente confuso di "word"). L'allineamento e` dovuto al fatto che L.in.oleum in nessun punto permette accessi disallineati (in effetti andrebbe a nozze con gli ARM). Semplicemente non conosce i byte: i byte sono parti interne delle unita`.
> 5. non capisco perche' il codice sia scritto in modo da essere non-efficiente e non-leggibile, se fosse leggibile l'accesso sarebbe fatto byte per byte,
Non puoi, altrimenti hai i disallineamenti e problemi di endianness di cui sopra. L.in.oleum sacrifica l'accesso byte per byte per evitare questo genere di problemi, che lo renderebbero irrimediabilmente non portabile (se cambiasse la endianness il sorgente sarebbe da buttare). E poi gli accessi disallineati non ammazzano solo gli ARM, ammazzano anche gli Intel superscalari dal Pentium in poi, che ormai sono CISC di nome, ma di fatto funzionano meglio se li si usa in modo molto simile a un RISC.
> se fosse efficiente il loop con gli shift sulla maschera sarebbe parzialmente srotolato (e a naso mi sa che ci sono modi piu` efficienti di manipolare stringhe su x86)
Intrinsecamente piu` efficienti, penso di no. Se stai pensando a cazzate come rep scasb stai pensando a roba dei tempi del 386, gia` il 486 avrebbe arrancato meno con cicli estesi. Per lo srotolamento, rendo atto che sarebbe un po' piu` efficiente, ma considera che le librerie di quel gruppo sono ottimizzate piu` per compattezza che per velocita`.
> 6. per quale motivo i caratteri delle tue stringhe sono di 32bit quando non supporti unicode? Anche se in un futuro dovessi supportare unicode, per quale motivo scegliere l'encoding massimamente inefficiente come default?
Perche` i processori sono piu` veloci nel manipolare dati di dimensione pari alla loro word, perche` essendo che L.in.oleum manipola bytes solo come parti di una word mantenerle in memoria a una unita` per carattere e` infinitamente piu` comodo ed efficiente, e perche` se le volessi codificare scriverei una routine apposita prima di scaricarle da qualche parte.
Figurati che se fosse compilato su un processore a 64 bit, ogni carattere prenderebbe 64 bit, una specie di inesistente UCS-8. Ma non e` appunto un fatto di avere piu` code points, e` proprio un fatto di allineamento puro e semplice. Non esistono bytes in L.in.oleum, dai tempi della prima versione, ne` possono esistere.
Ci contavo: almeno quello aiutera` a familiarizzarsi.
> 2. firstByte e` terminologia ambigua, si chiama most significant byte
Qui si chiama first perche` non c'e` ambiguita` dovuta all'endianness. L'endianness della memoria di lavoro e` sempre big: quello piu` a sinistra e` il primo, poi c'e` il secondo, il terzo, il quarto e, sui processori a 64 bit, quinto sesto settimo e ottavo. Quindi non e` ambiguo definirlo in termini posizionali.
> 3. mi pare di capire che se usi il nome di un registro con la lettera maiuscola lo dereferenzi -->
il (tra l'altro chi e` che setta EDI/w?)Esatto, anche se io la chiamo piu` tradizionalmente indirezione. Dereferenziare e` un termine connesso al C. L'indirezione con spiazzamento zero e` marcata sinteticamente dalla lettera maiuscola.
> 4. se la stringa di input non fosse 4-allineata (e non vedo per quale motivo una stringa di byte dovrebbe esserlo) non solo ti fai una marea di accessi disallineati (che ammazzerebbero, ad esempio, un ARM) ma potrebbe anche causare un segfault alla fine
La stringa di input e` per forza allineata a una boundary di 4 byte, ovvero di un'unita` per come la definisce L.in.oleum (per distinguerla dal significato tradizionalmente confuso di "word"). L'allineamento e` dovuto al fatto che L.in.oleum in nessun punto permette accessi disallineati (in effetti andrebbe a nozze con gli ARM). Semplicemente non conosce i byte: i byte sono parti interne delle unita`.
> 5. non capisco perche' il codice sia scritto in modo da essere non-efficiente e non-leggibile, se fosse leggibile l'accesso sarebbe fatto byte per byte,
Non puoi, altrimenti hai i disallineamenti e problemi di endianness di cui sopra. L.in.oleum sacrifica l'accesso byte per byte per evitare questo genere di problemi, che lo renderebbero irrimediabilmente non portabile (se cambiasse la endianness il sorgente sarebbe da buttare). E poi gli accessi disallineati non ammazzano solo gli ARM, ammazzano anche gli Intel superscalari dal Pentium in poi, che ormai sono CISC di nome, ma di fatto funzionano meglio se li si usa in modo molto simile a un RISC.
> se fosse efficiente il loop con gli shift sulla maschera sarebbe parzialmente srotolato (e a naso mi sa che ci sono modi piu` efficienti di manipolare stringhe su x86)
Intrinsecamente piu` efficienti, penso di no. Se stai pensando a cazzate come rep scasb stai pensando a roba dei tempi del 386, gia` il 486 avrebbe arrancato meno con cicli estesi. Per lo srotolamento, rendo atto che sarebbe un po' piu` efficiente, ma considera che le librerie di quel gruppo sono ottimizzate piu` per compattezza che per velocita`.
> 6. per quale motivo i caratteri delle tue stringhe sono di 32bit quando non supporti unicode? Anche se in un futuro dovessi supportare unicode, per quale motivo scegliere l'encoding massimamente inefficiente come default?
Perche` i processori sono piu` veloci nel manipolare dati di dimensione pari alla loro word, perche` essendo che L.in.oleum manipola bytes solo come parti di una word mantenerle in memoria a una unita` per carattere e` infinitamente piu` comodo ed efficiente, e perche` se le volessi codificare scriverei una routine apposita prima di scaricarle da qualche parte.
Figurati che se fosse compilato su un processore a 64 bit, ogni carattere prenderebbe 64 bit, una specie di inesistente UCS-8. Ma non e` appunto un fatto di avere piu` code points, e` proprio un fatto di allineamento puro e semplice. Non esistono bytes in L.in.oleum, dai tempi della prima versione, ne` possono esistere.
☺
Scritto da
altg
utente che non utiene
il 2014-10-31 01:39:08.0 alle 2014-10-31 01:39:08.0
Trollate totali: 11540
> Cosa consigliate?
Anch'io mi sono dato per titolo "utente stitico", ma scherzavo.
Ne ho fatta un barile stasera.
Anch'io mi sono dato per titolo "utente stitico", ma scherzavo.
Ne ho fatta un barile stasera.
☺
Scritto da
altg
utente che non utiene
il 2014-10-30 12:12:22.0 alle 2014-10-30 12:12:22.0
Trollate totali: 11540
> - Usa delle etichette che non si strappino/sporchino/ diventino illeggibili (No homemade).
Io allora userei pennarelli indelebili e ci scriverei sopra tutta la descrizione.
Ah, e ogni tanto anche un disegnino a piacere tanto per decorare, possibilmente non una fava schiappona.
Io allora userei pennarelli indelebili e ci scriverei sopra tutta la descrizione.
Ah, e ogni tanto anche un disegnino a piacere tanto per decorare, possibilmente non una fava schiappona.
☺
Scritto da
altg
utente che non utiene
il 2014-10-30 12:08:57.0 alle 2014-10-30 12:08:57.0
Trollate totali: 11540
> Volevano sbolognarmi 1 peso bolivariano del Venezuela per un euro. Con tanto di conferma e richiesta del manager. Che si vede non sa leggere in spagnolo.
> Bella li'
> Ma li ho fregati. Truffatori del cacchio.
> E la cassiera quando gli faccio- guardi che è del Venezuela. Mi fa. No no è un euro.
> Al che gli faccio.
> Certo c'è scritto repubblica bolivariano del Venezuela.
> Al che ha storto il naso. Ritorna dal manager.E mi fa. Ma lei è del Venezuela??
> Io - no, so solo leggere in spagnolo.
>
> Italiani ignoranti e truffatori del cazzo.
Mah, io probabilmente non ci avrei fatto caso, e avrei poi risbolognato la moneta in sostituzione di DUE euri.
> Bella li'
> Ma li ho fregati. Truffatori del cacchio.
> E la cassiera quando gli faccio- guardi che è del Venezuela. Mi fa. No no è un euro.
> Al che gli faccio.
> Certo c'è scritto repubblica bolivariano del Venezuela.
> Al che ha storto il naso. Ritorna dal manager.E mi fa. Ma lei è del Venezuela??
> Io - no, so solo leggere in spagnolo.
>
> Italiani ignoranti e truffatori del cazzo.
Mah, io probabilmente non ci avrei fatto caso, e avrei poi risbolognato la moneta in sostituzione di DUE euri.
Tua madre succhia cazzi all'inferno
Ad
http://www.vatican.va/content/vatican/en.html
Nessuno ci crede per poi affogare nella realtà subito dopo
☺
Scritto da
altg
utente che non utiene
il 2014-10-30 10:52:02.0 alle 2014-10-30 10:52:02.0
Trollate totali: 11540
> > > > > > Sissi` scherza scherza, che` poi viene fuori che era vero...
> > > > >
> > > > > In effetti ho subito scritto alla Walton Foundation,
> > > > >
> > > > > Dear Walton Family Foundation,
> > > > >
> > > > > Today I received the following email:
> > > > >
> > > > > "${messaggio_ricevuto}"
> > > > >
> > > > > It would be nice to see that there's someone who knows so closely my most intimate needs, but I don't think I am that lucky. This message is to inform you that someone is sending scam emails in your name.
> > > > >
> > > > > Thanks for your attention, and regards.
> > > > >
> > > > > ma sono breoggubado: compilato il form sul loro sito e premuto invio, non è venuta la pagina di riepilogo che normalmente viene in questi casi, "grazie per averci contattato" eccetera, ma è stato ripresentato di brutto il form.
> > > >
> > > > Ah si dice grazie? Mi pare che anynowhere dicesse "ok, non ci riprovare prima di 24 ore o si viene li` e ti si spacca dalle botte". Mi pareva piu` utile cosi`...
> > >
> > > Ho scritto a quelli veri, non ho risposto al messaggio.
> >
> > L'avevo capito.
> > Se scrivi ad anynowhere vero ti proibisce infatti di rifarlo per 24 ore.
> > Ma mi pare controllasse solo l'ip, tanto per scoraggiare un po'...
>
>
>
> > > Però che braccini corti la Walton Foundation: il loro sito è un .org, il dominio da cui proviene il messaggio il .com con lo stesso nome che punta a una parked page del registrar. Manco comprarsi anche il .com per evitare pasticci, almeno Insulae questo lo ha fatto.
> >
> > Ohe`, le fondazioni quella gente li` le fa per facciata. La verita` e` che non sono arrivati li` firmando assegni, ma perche` sono dei tirchiacci di lunga stirpe.
>
> Infatti mentre cercavo qualcosa su "Walton Family Foundation scam" è uscito un articolo che dice che i Walton non donano alla loro fondazione. Chissà su quali fondi si regge.
Io piu` che altro mi chiedo cosa faccia gente che ha piu` di 30 miliardi di dollari a disposizione con quei soldi, perche` li lasci li` parcheggiati come fossero il punteggio sul tabellone del flipper. Eccheccazzo, spendili! Per sopravvivere anche bene basta molto meno, l'eccedenza (il 99% del capitale in quei casi) va speso! Che fanno, si mettono d'accordo per evitare di spostare l'equilibrio economico? Sara` un complotto o sono semplicemente tirchi patologici?
> > Se a me, come esempio contrario, consegnassero il capitale di Bill Gates, dopo un paio di mesi sarei gia` a corto di soldi. Come? Be', probabilmente finanziando ricerche che m'interessano, tipo come rallentare l'invecchiamento, a suon di miliardi interi.
>
> Interessa anche a me. Ad esempio qualche tempo fa ho letto che da qualche anno è stato scoperto che i capelli diventano bianchi perché il follicolo produce acqua ossigenata che li decolora, e che l'enzima catalasi, scomponendo l'acqua ossigenata in acqua e ossigeno, dovrebbe impedirlo o invertirlo. Mi servirebbero informazioni su come portare la catalasi nel follicolo.
> Ho letto che il succo di cipolla contiene catalasi ed è considerato un rimedio tradizionale contro i capelli bianchi, ma sai, andare in giro lasciando una scia che odora di friggitoria...
Vabbe' ma nella mia idea di "rallentare l'invecchiamento", il fatto di non far perdere colore ai capelli sarebbe un tantino secondario. Se mi diventano brizzolati, probabilmente li faccio scolorare tutti e poi li ri-coloro rosso fuoco, che insieme alla spyder gialla e` un modo per passare inosservati.
> > > > >
> > > > > In effetti ho subito scritto alla Walton Foundation,
> > > > >
> > > > > Dear Walton Family Foundation,
> > > > >
> > > > > Today I received the following email:
> > > > >
> > > > > "${messaggio_ricevuto}"
> > > > >
> > > > > It would be nice to see that there's someone who knows so closely my most intimate needs, but I don't think I am that lucky. This message is to inform you that someone is sending scam emails in your name.
> > > > >
> > > > > Thanks for your attention, and regards.
> > > > >
> > > > > ma sono breoggubado: compilato il form sul loro sito e premuto invio, non è venuta la pagina di riepilogo che normalmente viene in questi casi, "grazie per averci contattato" eccetera, ma è stato ripresentato di brutto il form.
> > > >
> > > > Ah si dice grazie? Mi pare che anynowhere dicesse "ok, non ci riprovare prima di 24 ore o si viene li` e ti si spacca dalle botte". Mi pareva piu` utile cosi`...
> > >
> > > Ho scritto a quelli veri, non ho risposto al messaggio.
> >
> > L'avevo capito.
> > Se scrivi ad anynowhere vero ti proibisce infatti di rifarlo per 24 ore.
> > Ma mi pare controllasse solo l'ip, tanto per scoraggiare un po'...
>
>
>
> > > Però che braccini corti la Walton Foundation: il loro sito è un .org, il dominio da cui proviene il messaggio il .com con lo stesso nome che punta a una parked page del registrar. Manco comprarsi anche il .com per evitare pasticci, almeno Insulae questo lo ha fatto.
> >
> > Ohe`, le fondazioni quella gente li` le fa per facciata. La verita` e` che non sono arrivati li` firmando assegni, ma perche` sono dei tirchiacci di lunga stirpe.
>
> Infatti mentre cercavo qualcosa su "Walton Family Foundation scam" è uscito un articolo che dice che i Walton non donano alla loro fondazione. Chissà su quali fondi si regge.
Io piu` che altro mi chiedo cosa faccia gente che ha piu` di 30 miliardi di dollari a disposizione con quei soldi, perche` li lasci li` parcheggiati come fossero il punteggio sul tabellone del flipper. Eccheccazzo, spendili! Per sopravvivere anche bene basta molto meno, l'eccedenza (il 99% del capitale in quei casi) va speso! Che fanno, si mettono d'accordo per evitare di spostare l'equilibrio economico? Sara` un complotto o sono semplicemente tirchi patologici?
> > Se a me, come esempio contrario, consegnassero il capitale di Bill Gates, dopo un paio di mesi sarei gia` a corto di soldi. Come? Be', probabilmente finanziando ricerche che m'interessano, tipo come rallentare l'invecchiamento, a suon di miliardi interi.
>
> Interessa anche a me. Ad esempio qualche tempo fa ho letto che da qualche anno è stato scoperto che i capelli diventano bianchi perché il follicolo produce acqua ossigenata che li decolora, e che l'enzima catalasi, scomponendo l'acqua ossigenata in acqua e ossigeno, dovrebbe impedirlo o invertirlo. Mi servirebbero informazioni su come portare la catalasi nel follicolo.
> Ho letto che il succo di cipolla contiene catalasi ed è considerato un rimedio tradizionale contro i capelli bianchi, ma sai, andare in giro lasciando una scia che odora di friggitoria...
Vabbe' ma nella mia idea di "rallentare l'invecchiamento", il fatto di non far perdere colore ai capelli sarebbe un tantino secondario. Se mi diventano brizzolati, probabilmente li faccio scolorare tutti e poi li ri-coloro rosso fuoco, che insieme alla spyder gialla e` un modo per passare inosservati.
☺
Scritto da
altg
utente che non utiene
il 2014-10-30 10:44:57.0 alle 2014-10-30 10:44:57.0
Trollate totali: 11540
> > non si capisce un cazzo.
>
> altg -> ... -> ... -> ... -> yoda
Fra gli omissis chi c'e`?
>
> altg -> ... -> ... -> ... -> yoda
Fra gli omissis chi c'e`?
☺
Scritto da
altg
utente che non utiene
il 2014-10-30 10:41:52.0 alle 2014-10-30 10:41:52.0
Trollate totali: 11540
> non si capisce un cazzo.
Um...
Ottimo!
E` quello che volevo, cosi` nessuno potra` fare casino col mio linguaggio.
Um...
Ottimo!
E` quello che volevo, cosi` nessuno potra` fare casino col mio linguaggio.