☺
Scritto da
altg
utente che non utiene
il 2014-10-07 14:56:36.0 alle 2014-10-07 14:56:36.0
Trollate totali: 11540
> > Ah, dimenticavo: sapete che per caso m'e` venuto anche un modo abbastanza naturale, anche se non previsto espressamente dal compilatore, per l'overloading dei metodi? Deriva dal fatto che una inlet (e` il termine che indica una routine in generale: puo` essere subroutine, funzione, metodo... a seconda di come si comporta e di come la si tratta) e` dichiarata con una signature semantica, che indica insieme alle keywords che compongono il nome della inlet anche dove stanno gli argomenti.
> >
> > Ora, queste signatures possono contenere un solo segno di "punteggiatura": il punto e virgola. Come nel caso di "Plot at m;n In Color q". Va da se` che se scrivo "Antani x" oppure "Antani x;y" ottengo due metodi diversi che hanno visualmente lo stesso nome, eccetto che per il compilatore non sono la stessa cosa, e quindi nella symbols map li risolve a due simboli diversi. Ergo, se uso dei punti e virgola per marcare il numero di argomenti, ottengo l'equivalente dell'overloading. Ma sara` carino?
>
> Ma c'è qualcosa che sia vagamente simile alla versione precedente?
Vediamo...
Le istruzioni seguono ancora la convenzione che l'operando di sinistra e` la destinazione, oltre che una delle sorgenti, di un'operazione, cioe` x = x + 1 diventa x + 1.
L'indirizzamento e` ancora n-flat, cioe` basato su locazioni numerate progressivamente ciascuna della dimensione di un unita` (e non di un byte: n-flat significa modello d'indirizzamento flat con granularita` n, in contrasto con il normale modello flat che ha granularita` di 8 bit).
Il modulo di run-time e` essenzialmente lo stesso: l'IsoKernel parser funziona come prima (eccetto l'acquisizione di un mutex per rendere possibile condividerlo in multithreading, anche se la cosa migliore in termini prestazionali resterebbe delegare il maggior numero possibile di chiamate di sistema a un singolo thread, cioe` non creare race conditions sull'IsoKernel in primo luogo).
La mappatura dei registri non e` molto diversa, i modi d'indirizzamento (diretto, indiretto a registro singolo con spiazzamento costante, immediato, e registro) sono gli stessi.
Insomma ce ne sono parecchi di punti in comune, secondo me in essenza e` ancora se` stesso, ma con una superficie esposta decisamene migliore.
> >
> > Ora, queste signatures possono contenere un solo segno di "punteggiatura": il punto e virgola. Come nel caso di "Plot at m;n In Color q". Va da se` che se scrivo "Antani x" oppure "Antani x;y" ottengo due metodi diversi che hanno visualmente lo stesso nome, eccetto che per il compilatore non sono la stessa cosa, e quindi nella symbols map li risolve a due simboli diversi. Ergo, se uso dei punti e virgola per marcare il numero di argomenti, ottengo l'equivalente dell'overloading. Ma sara` carino?
>
> Ma c'è qualcosa che sia vagamente simile alla versione precedente?
Vediamo...
Le istruzioni seguono ancora la convenzione che l'operando di sinistra e` la destinazione, oltre che una delle sorgenti, di un'operazione, cioe` x = x + 1 diventa x + 1.
L'indirizzamento e` ancora n-flat, cioe` basato su locazioni numerate progressivamente ciascuna della dimensione di un unita` (e non di un byte: n-flat significa modello d'indirizzamento flat con granularita` n, in contrasto con il normale modello flat che ha granularita` di 8 bit).
Il modulo di run-time e` essenzialmente lo stesso: l'IsoKernel parser funziona come prima (eccetto l'acquisizione di un mutex per rendere possibile condividerlo in multithreading, anche se la cosa migliore in termini prestazionali resterebbe delegare il maggior numero possibile di chiamate di sistema a un singolo thread, cioe` non creare race conditions sull'IsoKernel in primo luogo).
La mappatura dei registri non e` molto diversa, i modi d'indirizzamento (diretto, indiretto a registro singolo con spiazzamento costante, immediato, e registro) sono gli stessi.
Insomma ce ne sono parecchi di punti in comune, secondo me in essenza e` ancora se` stesso, ma con una superficie esposta decisamene migliore.
Arricchimento culturale in Svezia
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-10-07 14:47:31.0 alle 2014-10-07 14:47:31.0
Trollate totali: 11540
☺
Scritto da
altg
utente che non utiene
il 2014-10-07 14:41:24.0 alle 2014-10-07 14:41:24.0
Trollate totali: 11540
> > Ah, dimenticavo: sapete che per caso m'e` venuto anche un modo abbastanza naturale, anche se non previsto espressamente dal compilatore, per l'overloading dei metodi? Deriva dal fatto che una inlet (e` il termine che indica una routine in generale: puo` essere subroutine, funzione, metodo... a seconda di come si comporta e di come la si tratta) e` dichiarata con una signature semantica, che indica insieme alle keywords che compongono il nome della inlet anche dove stanno gli argomenti.
> >
> > Ora, queste signatures possono contenere un solo segno di "punteggiatura": il punto e virgola. Come nel caso di "Plot at m;n In Color q". Va da se` che se scrivo "Antani x" oppure "Antani x;y" ottengo due metodi diversi che hanno visualmente lo stesso nome, eccetto che per il compilatore non sono la stessa cosa, e quindi nella symbols map li risolve a due simboli diversi. Ergo, se uso dei punti e virgola per marcare il numero di argomenti, ottengo l'equivalente dell'overloading. Ma sara` carino?
>
> stai pericolosamente scivolando verso il befunge e il malbolge
Seee.... e` chiarissimo. Certo e` pur sempre assembly, cross-platform e decorato, ma checcazzo, sempre assembly, e di certo non apparira` mai come se fosse Visual Basic.
> >
> > Ora, queste signatures possono contenere un solo segno di "punteggiatura": il punto e virgola. Come nel caso di "Plot at m;n In Color q". Va da se` che se scrivo "Antani x" oppure "Antani x;y" ottengo due metodi diversi che hanno visualmente lo stesso nome, eccetto che per il compilatore non sono la stessa cosa, e quindi nella symbols map li risolve a due simboli diversi. Ergo, se uso dei punti e virgola per marcare il numero di argomenti, ottengo l'equivalente dell'overloading. Ma sara` carino?
>
> stai pericolosamente scivolando verso il befunge e il malbolge
Seee.... e` chiarissimo. Certo e` pur sempre assembly, cross-platform e decorato, ma checcazzo, sempre assembly, e di certo non apparira` mai come se fosse Visual Basic.
☺
Scritto da
altg
utente che non utiene
il 2014-10-07 14:27:53.0 alle 2014-10-07 14:27:53.0
Trollate totali: 11540
> > A me non sembra venuto male.
> > A me sembra esteticamente bello.
>
> Aspettiamo che sassofono finisca di mangiare.
Magari meglio se viene un po' dopo aver finito, per non rovinarsi la digestione.
> > A me sembra esteticamente bello.
>
> Aspettiamo che sassofono finisca di mangiare.
Magari meglio se viene un po' dopo aver finito, per non rovinarsi la digestione.
☺
Scritto da
altg
utente che non utiene
il 2014-10-07 14:26:01.0 alle 2014-10-07 14:26:01.0
Trollate totali: 11540
Ah, dimenticavo: sapete che per caso m'e` venuto anche un modo abbastanza naturale, anche se non previsto espressamente dal compilatore, per l'overloading dei metodi? Deriva dal fatto che una inlet (e` il termine che indica una routine in generale: puo` essere subroutine, funzione, metodo... a seconda di come si comporta e di come la si tratta) e` dichiarata con una signature semantica, che indica insieme alle keywords che compongono il nome della inlet anche dove stanno gli argomenti.
Ora, queste signatures possono contenere un solo segno di "punteggiatura": il punto e virgola. Come nel caso di "Plot at m;n In Color q". Va da se` che se scrivo "Antani x" oppure "Antani x;y" ottengo due metodi diversi che hanno visualmente lo stesso nome, eccetto che per il compilatore non sono la stessa cosa, e quindi nella symbols map li risolve a due simboli diversi. Ergo, se uso dei punti e virgola per marcare il numero di argomenti, ottengo l'equivalente dell'overloading. Ma sara` carino?
Ora, queste signatures possono contenere un solo segno di "punteggiatura": il punto e virgola. Come nel caso di "Plot at m;n In Color q". Va da se` che se scrivo "Antani x" oppure "Antani x;y" ottengo due metodi diversi che hanno visualmente lo stesso nome, eccetto che per il compilatore non sono la stessa cosa, e quindi nella symbols map li risolve a due simboli diversi. Ergo, se uso dei punti e virgola per marcare il numero di argomenti, ottengo l'equivalente dell'overloading. Ma sara` carino?
Vieni anche tu in gita in Africa!
Ad
https://www.ilmessaggero.it/AMP/italia/luca_tacchetto_italiano_scomparso_burkina_faso-4209268.html
Le popolazioni locali ti accoglieranno così bene che scomparirai letteralmente dal resto del mondo! Lasciati alle spalle la civiltà occidentale, gli smartphone, la ruota e il fuoco!
☺
Scritto da
altg
utente che non utiene
il 2014-10-07 13:15:00.0 alle 2014-10-07 13:15:00.0
Trollate totali: 11540
Il programmino del punto che rimbalza:
Usa l'implementazione "canvas" della classe astratta "raster". La keyword "as" fa il typecast sul registro "p", dicendogli che punta a un'istanza di canvas. In java, l'equivalente sarebbe una variabile di riferimento dichiarata come "tipo nome" ma non assegnata a un "new" qualcosa.
Un "raster" e` definito cosi`:
E gli unici metodi che implementa sono degli accessors per le dimensioni in pixels, che appunto sono le uniche cose che al momento hanno in comune canvas e bitmap, i due tipi concreti di raster. Gli altri sono signatures per metodi non implementati, che finiscono tutti in un'unica istruzione "leave" che ritorna al chiamante senza fare nulla. I campi dell'istanza sono descritti dai "count". Count e` un enumeratore progressivo: se non gli si dice diversamente, parte da zero e assegna la prima named constant a 0, la seconda a 1 e cosi` via. L'ultimo count da` la dimensione dell'istanza in unita` (cioe` in words del microprocessore).
L'implementazione "canvas", per esempio, poi implementa il costruttore "Create" cosi`:
facendo l'override della inlet "Create" nel nameset "raster", che e` esteso dal nameset "canvas" (per via della dichiarazione "nameset canvas extends raster"). Se dovesse dichiarare altri campi membri, dichiarerebbe altri count dopo "count from nSizeOfInstance" (risolta automaticamente nel nameset "raster", e la ridichiarerebbe (nel suo nameset) alla fine delle dichiarazioni "count".
Per curiosita`, canvas::Create alloca un canvassino di 1x1 pixels di default, se non viene ridimensionato, sicche` il bordo destro e inferiore sono tutti e due zero e width e height sono 1. Per ridimensionarlo c'e` canvas::SizeToByPixels (chiamato come "Size To larghezza;altezza Pixels"), oppure c'e` il costruttore alternativo canvas::CreateByPixels ("Create larghezza By altezza Pixels") che istanzia canvas e poi chiama subito (o meglio, si lascia "cadere" nel codice di) SizeToByPixels. E quello crea un canvas che inizialmente ha le dimensioni volute.
A me non sembra venuto male.
A me sembra esteticamente bello.
Usa l'implementazione "canvas" della classe astratta "raster". La keyword "as" fa il typecast sul registro "p", dicendogli che punta a un'istanza di canvas. In java, l'equivalente sarebbe una variabile di riferimento dichiarata come "tipo nome" ma non assegnata a un "new" qualcosa.
Un "raster" e` definito cosi`:
E gli unici metodi che implementa sono degli accessors per le dimensioni in pixels, che appunto sono le uniche cose che al momento hanno in comune canvas e bitmap, i due tipi concreti di raster. Gli altri sono signatures per metodi non implementati, che finiscono tutti in un'unica istruzione "leave" che ritorna al chiamante senza fare nulla. I campi dell'istanza sono descritti dai "count". Count e` un enumeratore progressivo: se non gli si dice diversamente, parte da zero e assegna la prima named constant a 0, la seconda a 1 e cosi` via. L'ultimo count da` la dimensione dell'istanza in unita` (cioe` in words del microprocessore).
L'implementazione "canvas", per esempio, poi implementa il costruttore "Create" cosi`:
facendo l'override della inlet "Create" nel nameset "raster", che e` esteso dal nameset "canvas" (per via della dichiarazione "nameset canvas extends raster"). Se dovesse dichiarare altri campi membri, dichiarerebbe altri count dopo "count from nSizeOfInstance" (risolta automaticamente nel nameset "raster", e la ridichiarerebbe (nel suo nameset) alla fine delle dichiarazioni "count".
Per curiosita`, canvas::Create alloca un canvassino di 1x1 pixels di default, se non viene ridimensionato, sicche` il bordo destro e inferiore sono tutti e due zero e width e height sono 1. Per ridimensionarlo c'e` canvas::SizeToByPixels (chiamato come "Size To larghezza;altezza Pixels"), oppure c'e` il costruttore alternativo canvas::CreateByPixels ("Create larghezza By altezza Pixels") che istanzia canvas e poi chiama subito (o meglio, si lascia "cadere" nel codice di) SizeToByPixels. E quello crea un canvas che inizialmente ha le dimensioni volute.
A me non sembra venuto male.
A me sembra esteticamente bello.
☺
Scritto da
altg
utente che non utiene
il 2014-10-07 12:48:10.0 alle 2014-10-07 12:48:10.0
Trollate totali: 11540
> > > L'unico linguaggio che conosco che ha scelto keyword e funzioni in base a lunghezza, assonanza, etc.. è stato php.
> >
> > Davvero? [citazione necessaria]
>
> http://www.i-programmer.info/news/98-languages/675...
Che delusione, e` un caso del tutto diverso: in primo luogo, aveva un motivo PRATICO per determinare la lunghezza dei nomi, e non puramente poetico nonche` estetico di gusto raffinato (come nel mio caso); in secondo luogo, a lui non andava bene avere tutti i nomi di uguale lunghezza perche` gli sarebbero venute un sacco di hash collisions.
> >
> > Davvero? [citazione necessaria]
>
> http://www.i-programmer.info/news/98-languages/675...
Che delusione, e` un caso del tutto diverso: in primo luogo, aveva un motivo PRATICO per determinare la lunghezza dei nomi, e non puramente poetico nonche` estetico di gusto raffinato (come nel mio caso); in secondo luogo, a lui non andava bene avere tutti i nomi di uguale lunghezza perche` gli sarebbero venute un sacco di hash collisions.
☺
Scritto da
altg
utente che non utiene
il 2014-10-07 10:13:37.0 alle 2014-10-07 10:13:37.0
Trollate totali: 11540
> > Package non e` male, le altre non sono sette caratteri. 
> > Pero` boh, non mi rende l'idea di un registro di nomi di simboli.
> > Mi rende l'idea di un pacchetto gia` confezionato, potrebbe essere fuorviante.
>
> In rust usano crate per indicare un modulo (o quasi, c'è pure mod ma per un'altra cosa).
Minchia, "crate" mi ricorda le cassettine con le armi di Worms (il gioco).
Comunque vedo che non sono il solo a fare l'originalone.
Comunque, per circostanziare meglio: i sorgenti qui sono tutti testuali, non c'e` roba precompilata e non vorrei che parole come module o package dessero l'idea di qualcosa di precompilato, aggiunto in forma di object code. Le istruzioni "include" sono solo rimandi ad altri file di testo col codice sorgente: "include", in pratica, dice al compilatore "adesso, se non l'hai gia` fatto in precedenza, vai a pescare questo file a partire dal percorso alla cartella delle librerie, parsalo e aggiungi il codice e i dati a quel che hai gia` nell'output".
Mentre per il namespace, si`, effettivamente e` un namespace e la cosa piu` indicativa sarebbe usare "namespace". Pero` qui e` usato anche per raccogliere proprieta` e metodi di oggetti statici (cioe` per definire una classe), sicche` quando si "estende" un namespace ereditandone metodi e simboli, si fa praticamente l'unione di due insiemi, quindi pensavo che forse riferirsi al namespace come "nameset" potrebbe sembrare piu` sensato quando ti accorgi che le cose chiamate namesets possono essere unite.
Boh.
Insomma nameset mi piace.
Se qualcuno e` riuscito a usare crate, nameset in confronto e` da signori!
> > Pero` boh, non mi rende l'idea di un registro di nomi di simboli.
> > Mi rende l'idea di un pacchetto gia` confezionato, potrebbe essere fuorviante.
>
> In rust usano crate per indicare un modulo (o quasi, c'è pure mod ma per un'altra cosa).
Minchia, "crate" mi ricorda le cassettine con le armi di Worms (il gioco).
Comunque vedo che non sono il solo a fare l'originalone.
Comunque, per circostanziare meglio: i sorgenti qui sono tutti testuali, non c'e` roba precompilata e non vorrei che parole come module o package dessero l'idea di qualcosa di precompilato, aggiunto in forma di object code. Le istruzioni "include" sono solo rimandi ad altri file di testo col codice sorgente: "include", in pratica, dice al compilatore "adesso, se non l'hai gia` fatto in precedenza, vai a pescare questo file a partire dal percorso alla cartella delle librerie, parsalo e aggiungi il codice e i dati a quel che hai gia` nell'output".
Mentre per il namespace, si`, effettivamente e` un namespace e la cosa piu` indicativa sarebbe usare "namespace". Pero` qui e` usato anche per raccogliere proprieta` e metodi di oggetti statici (cioe` per definire una classe), sicche` quando si "estende" un namespace ereditandone metodi e simboli, si fa praticamente l'unione di due insiemi, quindi pensavo che forse riferirsi al namespace come "nameset" potrebbe sembrare piu` sensato quando ti accorgi che le cose chiamate namesets possono essere unite.
Boh.
Insomma nameset mi piace.
Se qualcuno e` riuscito a usare crate, nameset in confronto e` da signori!
☺
Scritto da
altg
utente che non utiene
il 2014-10-07 09:33:08.0 alle 2014-10-07 09:33:08.0
Trollate totali: 11540
> > l'ultima per il namespace? eh? eh? e` carino nameset?
> > insieme di nomi, no? forse.
>
> che hai contro package, namespace o module?
Package non e` male, le altre non sono sette caratteri.
Pero` boh, non mi rende l'idea di un registro di nomi di simboli.
Mi rende l'idea di un pacchetto gia` confezionato, potrebbe essere fuorviante.
> > p.s. per startup ci potrebbe anche andare "default". E` il valore iniziale di un parametro del modulo di run-time, tipo come far partire lo schermo (in testo? in grafica collaborativa? in grafica esclusiva?)... di solito poi non vengono neanche usati e li scoraggio proprio, pero` hanno una loro ragion d'essere e poi fanno comodo per semplificare gli esempi.
>
> ma usare l'operatore d'assegnamento?
E` usato per le dichiarazioni di variabili thread-local, mentre quei defaults li` e` come se fossero globali gia` dichiarate e valide per tutti i threads. Forse e` meglio tenerle separate per suggerire che hanno una natura parecchio diversa da quel che, prima di entrare in una routine, e` assegnato con roba tipo "banf = B1Ah"...
> > p.p.s. a proposito di quei cosi di default, quello per impostare lo schermo si chiama "displayStatus", ma quando scelsi quel nome ero giovane e solo un po' meno coglione di ora. Mi chiedo a volte se "displayState" sarebbe meglio, insieme a tutti gli altri "status" delle varie interfacce del RTM. Non vorrei che status uno lo deridesse, ricordandogli uno status sociale o roba del genere.
>
> non dovrebbe essere displayMode?
Um... nella mia idea la modalita` del display e` decisa dallo stato di alcuni dei flag di quel campo, ma non da tutti. Flags come asyncRetrace e asyncResize passano solo all'applicazione le richieste del modulo di run-time di ridisegnare la finestra o di adattarsi a delle nuove dimensioni, ma non avrebbero a che fare con la modalita`. Insomma displayStatus e` una raccolta di flag che riguardano la cosa chiamata display.
> > insieme di nomi, no? forse.
>
> che hai contro package, namespace o module?
Package non e` male, le altre non sono sette caratteri.
Pero` boh, non mi rende l'idea di un registro di nomi di simboli.
Mi rende l'idea di un pacchetto gia` confezionato, potrebbe essere fuorviante.
> > p.s. per startup ci potrebbe anche andare "default". E` il valore iniziale di un parametro del modulo di run-time, tipo come far partire lo schermo (in testo? in grafica collaborativa? in grafica esclusiva?)... di solito poi non vengono neanche usati e li scoraggio proprio, pero` hanno una loro ragion d'essere e poi fanno comodo per semplificare gli esempi.
>
> ma usare l'operatore d'assegnamento?
E` usato per le dichiarazioni di variabili thread-local, mentre quei defaults li` e` come se fossero globali gia` dichiarate e valide per tutti i threads. Forse e` meglio tenerle separate per suggerire che hanno una natura parecchio diversa da quel che, prima di entrare in una routine, e` assegnato con roba tipo "banf = B1Ah"...
> > p.p.s. a proposito di quei cosi di default, quello per impostare lo schermo si chiama "displayStatus", ma quando scelsi quel nome ero giovane e solo un po' meno coglione di ora. Mi chiedo a volte se "displayState" sarebbe meglio, insieme a tutti gli altri "status" delle varie interfacce del RTM. Non vorrei che status uno lo deridesse, ricordandogli uno status sociale o roba del genere.
>
> non dovrebbe essere displayMode?
Um... nella mia idea la modalita` del display e` decisa dallo stato di alcuni dei flag di quel campo, ma non da tutti. Flags come asyncRetrace e asyncResize passano solo all'applicazione le richieste del modulo di run-time di ridisegnare la finestra o di adattarsi a delle nuove dimensioni, ma non avrebbero a che fare con la modalita`. Insomma displayStatus e` una raccolta di flag che riguardano la cosa chiamata display.
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-07 00:07:17.0 alle 2014-10-07 00:07:17.0
Trollate totali: 11540
> > > > > > Abbiamo presentato: riflessioni esistenzialiste di un nazifascio.
> > > > >
> > > > > È la fase dell'accettazione
> > > >
> > > > Che succedera` quando scoprira` che i termini "ariano" e "iraniano" hanno la stessa radice?
> > >
> > > Succede che lo sapevo già prima di te. A quei tempi l'Iran era popolati da bianchi.
> >
> >
>
> Somiglia a Sean Connery
E` vero, porca miseria!!
> > > > >
> > > > > È la fase dell'accettazione
> > > >
> > > > Che succedera` quando scoprira` che i termini "ariano" e "iraniano" hanno la stessa radice?
> > >
> > > Succede che lo sapevo già prima di te. A quei tempi l'Iran era popolati da bianchi.
> >
> >
>
> Somiglia a Sean Connery
E` vero, porca miseria!!
☺
Scritto da
altg
utente che non utiene
il 2014-10-06 23:55:09.0 alle 2014-10-06 23:55:09.0
Trollate totali: 11540
> > > > "imply" e` "include" sotto un altro nome: include una libreria, punto.
> > >
> > > idea orrenda.
> >
> > Perche` suona male, perche` magari fa pensare a qualcos'altro, o perche` sarebbe meglio riusare quello che tutti si aspettano, cioe` "include"? In origine avevo scelto "include".
>
> perche' la tua spiegazione per usare imply e` contorta e suona sbagliata in inglese (e in italiano) e non ha senso andare a pescare una keyword del genere per un concetto standard per cui tutti gli altri linguaggi usano include, import o use.
Oh be', son sempre in tempo a ri-cambiarla. In effetti non e` che se includo una libreria ne implichi l'uso, posso anche includerla per puro spirito sportivo e lasciarla li`. Umm... vabbe', mi hai convinto: usero` include e allunghero` tutte le altre keywords attorno...
vediamo...
imply -> include
setup -> startup
space -> nameset
l'ultima per il namespace? eh? eh? e` carino nameset?
insieme di nomi, no? forse.
p.s. per startup ci potrebbe anche andare "default". E` il valore iniziale di un parametro del modulo di run-time, tipo come far partire lo schermo (in testo? in grafica collaborativa? in grafica esclusiva?)... di solito poi non vengono neanche usati e li scoraggio proprio, pero` hanno una loro ragion d'essere e poi fanno comodo per semplificare gli esempi.
p.p.s. a proposito di quei cosi di default, quello per impostare lo schermo si chiama "displayStatus", ma quando scelsi quel nome ero giovane e solo un po' meno coglione di ora. Mi chiedo a volte se "displayState" sarebbe meglio, insieme a tutti gli altri "status" delle varie interfacce del RTM. Non vorrei che status uno lo deridesse, ricordandogli uno status sociale o roba del genere.
**Modificato dall'autore il 07.10.2014 00:03**
> > >
> > > idea orrenda.
> >
> > Perche` suona male, perche` magari fa pensare a qualcos'altro, o perche` sarebbe meglio riusare quello che tutti si aspettano, cioe` "include"? In origine avevo scelto "include".
>
> perche' la tua spiegazione per usare imply e` contorta e suona sbagliata in inglese (e in italiano) e non ha senso andare a pescare una keyword del genere per un concetto standard per cui tutti gli altri linguaggi usano include, import o use.
Oh be', son sempre in tempo a ri-cambiarla. In effetti non e` che se includo una libreria ne implichi l'uso, posso anche includerla per puro spirito sportivo e lasciarla li`. Umm... vabbe', mi hai convinto: usero` include e allunghero` tutte le altre keywords attorno...
vediamo...
imply -> include
setup -> startup
space -> nameset
l'ultima per il namespace? eh? eh? e` carino nameset?
insieme di nomi, no? forse.
p.s. per startup ci potrebbe anche andare "default". E` il valore iniziale di un parametro del modulo di run-time, tipo come far partire lo schermo (in testo? in grafica collaborativa? in grafica esclusiva?)... di solito poi non vengono neanche usati e li scoraggio proprio, pero` hanno una loro ragion d'essere e poi fanno comodo per semplificare gli esempi.
p.p.s. a proposito di quei cosi di default, quello per impostare lo schermo si chiama "displayStatus", ma quando scelsi quel nome ero giovane e solo un po' meno coglione di ora. Mi chiedo a volte se "displayState" sarebbe meglio, insieme a tutti gli altri "status" delle varie interfacce del RTM. Non vorrei che status uno lo deridesse, ricordandogli uno status sociale o roba del genere.
**Modificato dall'autore il 07.10.2014 00:03**
☺
Scritto da
altg
utente che non utiene
il 2014-10-06 20:56:18.0 alle 2014-10-06 20:56:18.0
Trollate totali: 11540
> > "imply" e` "include" sotto un altro nome: include una libreria, punto.
>
> idea orrenda.
Perche` suona male, perche` magari fa pensare a qualcos'altro, o perche` sarebbe meglio riusare quello che tutti si aspettano, cioe` "include"? In origine avevo scelto "include".
>
> idea orrenda.
Perche` suona male, perche` magari fa pensare a qualcos'altro, o perche` sarebbe meglio riusare quello che tutti si aspettano, cioe` "include"? In origine avevo scelto "include".
☺
Scritto da
altg
utente che non utiene
il 2014-10-06 20:55:03.0 alle 2014-10-06 20:55:03.0
Trollate totali: 11540
> > Ah, ho cambiato le keywords per "entail" e "preset".
> > Ho sostituito "entail" con "imply" e "preset" con "setup".
> > "imply" e` "include" sotto un altro nome: include una libreria, punto.
> > Ma mi serviva di 5 caratteri.
> > Prima mi serviva di 6, poi ho visto che allineava meglio esteticamente con 5.
> > Pero` prima avevo preso "entail" perche` l'altra che mi veniva in mente di 6 era "import", ma poi me lo confondono col Python, va a finire: gia` usa l'indentazione per delimitare i blocchi strutturali...
> > Ma e` colpa della mia idiosincrasia (o anche idiozia) degli allineamenti.
> > Comunque "imply" mi sembra carina.
> > "imply graphics canvas" suona bene: "qui e` implicato l'oggetto canvas del reparto grafico delle librerie".
>
> L'unico linguaggio che conosco che ha scelto keyword e funzioni in base a lunghezza, assonanza, etc.. è stato php.
Davvero? [citazione necessaria]
Lo dicevo che era un'idiozia... pero` va riconosciuto che il php ha avuto un certo successo.
...probabilmente perche` l'hosting col php nei primi anni 2000 costava poco o nulla, non perche` aveva le keywords assonanti.
> Potresti farti un editor di testo che allinea bene le keyword e usare parole e operatori più convenzionali.
Mah, per gli allineamenti c'e` gia`.
Anche su Windows c'e` notepad++ che lo fa.
> Come fa leksah, l'ide per haskell, che sostituisce alcune keyword e operatori con dei simboli, es. in haskell le funzioni anonime iniziano con \variabile, leksah la trasforma in λvariabile, la freccia -> diventa → e anche altri simboli, ma solo visivamente, il contenuto del file resta lo stesso.
Macche`, la mia area visiva primaria e` limitata all'ASCII.
La lambda non la vedrei.
> > Ho sostituito "entail" con "imply" e "preset" con "setup".
> > "imply" e` "include" sotto un altro nome: include una libreria, punto.
> > Ma mi serviva di 5 caratteri.
> > Prima mi serviva di 6, poi ho visto che allineava meglio esteticamente con 5.
> > Pero` prima avevo preso "entail" perche` l'altra che mi veniva in mente di 6 era "import", ma poi me lo confondono col Python, va a finire: gia` usa l'indentazione per delimitare i blocchi strutturali...
> > Ma e` colpa della mia idiosincrasia (o anche idiozia) degli allineamenti.
> > Comunque "imply" mi sembra carina.
> > "imply graphics canvas" suona bene: "qui e` implicato l'oggetto canvas del reparto grafico delle librerie".
>
> L'unico linguaggio che conosco che ha scelto keyword e funzioni in base a lunghezza, assonanza, etc.. è stato php.
Davvero? [citazione necessaria]
Lo dicevo che era un'idiozia... pero` va riconosciuto che il php ha avuto un certo successo.
...probabilmente perche` l'hosting col php nei primi anni 2000 costava poco o nulla, non perche` aveva le keywords assonanti.
> Potresti farti un editor di testo che allinea bene le keyword e usare parole e operatori più convenzionali.
Mah, per gli allineamenti c'e` gia`.
Anche su Windows c'e` notepad++ che lo fa.
> Come fa leksah, l'ide per haskell, che sostituisce alcune keyword e operatori con dei simboli, es. in haskell le funzioni anonime iniziano con \variabile, leksah la trasforma in λvariabile, la freccia -> diventa → e anche altri simboli, ma solo visivamente, il contenuto del file resta lo stesso.
Macche`, la mia area visiva primaria e` limitata all'ASCII.
La lambda non la vedrei.
Vieni anche tu a scuola in Svezia!
Ad
https://www.breitbart.com/europe/2019/01/11/swedish-journalist-teachers-have-given-up-rising-school-violence/
Qui accettiamo qualunque tipo di animale! Non facciamo discriminazioni noi! Mica siamo razzisti!!!
☺
Scritto da
altg
utente che non utiene
il 2014-10-06 17:59:54.0 alle 2014-10-06 17:59:54.0
Trollate totali: 11540
> > Facciamo progressi. 
> >
> > Questo e` il sorgentino di un programmino che sara` tra gli esempi.
> > Con tanto di syntax highlighting.
> >
> >
> >
> > E questo, se vi fidate, e` l'eseguibile risultante:
> > non ho idea se funzioni anche su WinE, ma penso che dovrebbe.
> >
> >
http://anynowhere.com/personal/dotPong.exe
>
> Ad Avira non piace sto coso, dice che contiene
>
> TR/Crypt.PACK.Gen
>
> Minimo minimo devi scrivere ad Avira perché ti depennino dai loro elenchi.
E` un fatto noto. Probabilmente l'antivirus vede roba assembly parecchio hikikomorizzata (cioe` roba da veri programmatori col cappello a tesa larga e il cinturone d'altri tempi, quelli che possono mettere a cuocere il popcorn sul dissipatore della CPU e stabilire cosa sta facendo il processore a partire dal ritmo di scoppio dei chicchi) e pensa che debba per forza essere codice virale. Oppure quelli che hanno scritto TR/Crypt.PACK.Gen hanno avuto idee simili alle mie sulla rilocazione del codice o su qualche trucco per compattarlo.
Gli scrivero` quando ne varra` la pena, per ora Linoleum 4 me lo cago solo io.
um... ah, oggi pomeriggio la notizia e` che pare che l'ereditarieta`, nelle sottoclassi, funzioni. Ho potuto sostituire il canvas a colori con la bitmap in bianco e nero e il programma gira. Fa un puntino che rimbalza senza scia (perche` il metodo "Fade" su una bitmap non puo` decrementare la luminosita` dei pixel: puo` solo farli diventare tutti neri). Entrambe le implementazioni derivano dallo "spazio" (sarebbe una classe, ma non si dice perche` non m'e` mai piaciuto il termine) chiamato raster e implementano metodi diversi. Comunque fin qui e` tutto bindind statico. Quello dinamico si farebbe con le interfacce, che pero` non sono assistite dal compilatore, ma che e` facile implementare nel runtime.
Vabbe', insomma il riassunto e` che si va avanti.
E` gia` qualcosa.
Ah, ho cambiato le keywords per "entail" e "preset".
Ho sostituito "entail" con "imply" e "preset" con "setup".
"imply" e` "include" sotto un altro nome: include una libreria, punto.
Ma mi serviva di 5 caratteri.
Prima mi serviva di 6, poi ho visto che allineava meglio esteticamente con 5.
Pero` prima avevo preso "entail" perche` l'altra che mi veniva in mente di 6 era "import", ma poi me lo confondono col Python, va a finire: gia` usa l'indentazione per delimitare i blocchi strutturali...
Ma e` colpa della mia idiosincrasia (o anche idiozia) degli allineamenti.
Comunque "imply" mi sembra carina.
"imply graphics canvas" suona bene: "qui e` implicato l'oggetto canvas del reparto grafico delle librerie".
> >
> > Questo e` il sorgentino di un programmino che sara` tra gli esempi.
> > Con tanto di syntax highlighting.
> >
> >
> >
> > E questo, se vi fidate, e` l'eseguibile risultante:
> > non ho idea se funzioni anche su WinE, ma penso che dovrebbe.
> >
> >
>
> Ad Avira non piace sto coso, dice che contiene
>
> TR/Crypt.PACK.Gen
>
> Minimo minimo devi scrivere ad Avira perché ti depennino dai loro elenchi.
E` un fatto noto. Probabilmente l'antivirus vede roba assembly parecchio hikikomorizzata (cioe` roba da veri programmatori col cappello a tesa larga e il cinturone d'altri tempi, quelli che possono mettere a cuocere il popcorn sul dissipatore della CPU e stabilire cosa sta facendo il processore a partire dal ritmo di scoppio dei chicchi) e pensa che debba per forza essere codice virale. Oppure quelli che hanno scritto TR/Crypt.PACK.Gen hanno avuto idee simili alle mie sulla rilocazione del codice o su qualche trucco per compattarlo.
Gli scrivero` quando ne varra` la pena, per ora Linoleum 4 me lo cago solo io.
um... ah, oggi pomeriggio la notizia e` che pare che l'ereditarieta`, nelle sottoclassi, funzioni. Ho potuto sostituire il canvas a colori con la bitmap in bianco e nero e il programma gira. Fa un puntino che rimbalza senza scia (perche` il metodo "Fade" su una bitmap non puo` decrementare la luminosita` dei pixel: puo` solo farli diventare tutti neri). Entrambe le implementazioni derivano dallo "spazio" (sarebbe una classe, ma non si dice perche` non m'e` mai piaciuto il termine) chiamato raster e implementano metodi diversi. Comunque fin qui e` tutto bindind statico. Quello dinamico si farebbe con le interfacce, che pero` non sono assistite dal compilatore, ma che e` facile implementare nel runtime.
Vabbe', insomma il riassunto e` che si va avanti.
E` gia` qualcosa.
Ah, ho cambiato le keywords per "entail" e "preset".
Ho sostituito "entail" con "imply" e "preset" con "setup".
"imply" e` "include" sotto un altro nome: include una libreria, punto.
Ma mi serviva di 5 caratteri.
Prima mi serviva di 6, poi ho visto che allineava meglio esteticamente con 5.
Pero` prima avevo preso "entail" perche` l'altra che mi veniva in mente di 6 era "import", ma poi me lo confondono col Python, va a finire: gia` usa l'indentazione per delimitare i blocchi strutturali...
Ma e` colpa della mia idiosincrasia (o anche idiozia) degli allineamenti.
Comunque "imply" mi sembra carina.
"imply graphics canvas" suona bene: "qui e` implicato l'oggetto canvas del reparto grafico delle librerie".
☺
Scritto da
altg
utente che non utiene
il 2014-10-05 15:52:57.0 alle 2014-10-05 15:52:57.0
Trollate totali: 11540
> 
http://www.corriere.it/esteri/14_ottobre_03/argent...
Cosi` imparano a maltrattare la Tesla Roadster, quei retrogradi che vanno su auto a scorregge e le considerano chissa` cosa.
Cosi` imparano a maltrattare la Tesla Roadster, quei retrogradi che vanno su auto a scorregge e le considerano chissa` cosa.
☺
Scritto da
altg
utente che non utiene
il 2014-10-05 15:39:22.0 alle 2014-10-05 15:39:22.0
Trollate totali: 11540
> > Facciamo progressi.
> >
> > Questo e` il sorgentino di un programmino che sara` tra gli esempi.
> > Con tanto di syntax highlighting.
> >
> >
> >
> > E questo, se vi fidate, e` l'eseguibile risultante:
> > non ho idea se funzioni anche su WinE, ma penso che dovrebbe.
> >
> >http://anynowhere.com/personal/dotPong.exe
> >
> > Fa rimbalzare un puntino bianco che lascia una lunga coda che si dissolve, tra i bordi di una finestra massimizzata. La sintassi mi piace com'e` venuta. E` anche oggettizzata: usa il costruttore canvas::Create (il riferimento all'oggetto risultante e` caricato nel registro puntatore primario p ) piu` vari metodi e getters. Il codice che reagisce al flag "asyncRetrace" gestisce il ridimensionamento della finestra quando si sposta la taskbar, e l'area disponibile cambia.
>
> Funziona anche su wine.
Buono a sapersi.
> Sulla sintassi devi spiegarci cosa fanno le frecce,
La freccia -> ("out of") lega un contesto a una funzione.
La freccia <- ("comes from") ritira un valore di ritorno.
Mi manca da fare delle tabelle per i metodi. Per ora, se si applica un approccio a oggetti, bisogna stupidamente legare i metodi all'oggetto (che contiene solo dati), perche` sono separati. Ovviamente e` un abbozzo, e non ci vuole molto, pero` devo ancora decidere come fare esattamente.
> perché alcune variabili hanno here,
"here" dichiara variabili locali, tutto li`.
Cioe` quelle che stanno nello stack frame.
> cosa fa '>
Sono confronti senza segno ("maggiore senza segno di"). Siccome i dati elementari in Linoleum sono untyped, devi dirgli se considerare il valore con o senza segno. Confrontare le coordinate attuali del puntino (m;n) con i margini destro e inferiore della finestra permette di far leva sul complemento a due (i valori negativi sono considerati enormi) e controllare tutti e quattro i bordi insieme con due confronti soli.
> e se m > 1 e n > 1 sono degli if senza if.
No, sono degli shift binari. Dividono per due le dimensioni della finestra ricavando il punto di mezzo, a cui vengono lasciati (m;n) che poi vengono consoderate le coordinate attuali del puntino. Cosi` il puntino parte al centro.
> >
> > Questo e` il sorgentino di un programmino che sara` tra gli esempi.
> > Con tanto di syntax highlighting.
> >
> >
> >
> > E questo, se vi fidate, e` l'eseguibile risultante:
> > non ho idea se funzioni anche su WinE, ma penso che dovrebbe.
> >
> >
> >
> > Fa rimbalzare un puntino bianco che lascia una lunga coda che si dissolve, tra i bordi di una finestra massimizzata. La sintassi mi piace com'e` venuta. E` anche oggettizzata: usa il costruttore canvas::Create (il riferimento all'oggetto risultante e` caricato nel registro puntatore primario p ) piu` vari metodi e getters. Il codice che reagisce al flag "asyncRetrace" gestisce il ridimensionamento della finestra quando si sposta la taskbar, e l'area disponibile cambia.
>
> Funziona anche su wine.
Buono a sapersi.
> Sulla sintassi devi spiegarci cosa fanno le frecce,
La freccia -> ("out of") lega un contesto a una funzione.
La freccia <- ("comes from") ritira un valore di ritorno.
Mi manca da fare delle tabelle per i metodi. Per ora, se si applica un approccio a oggetti, bisogna stupidamente legare i metodi all'oggetto (che contiene solo dati), perche` sono separati. Ovviamente e` un abbozzo, e non ci vuole molto, pero` devo ancora decidere come fare esattamente.
> perché alcune variabili hanno here,
"here" dichiara variabili locali, tutto li`.
Cioe` quelle che stanno nello stack frame.
> cosa fa '>
Sono confronti senza segno ("maggiore senza segno di"). Siccome i dati elementari in Linoleum sono untyped, devi dirgli se considerare il valore con o senza segno. Confrontare le coordinate attuali del puntino (m;n) con i margini destro e inferiore della finestra permette di far leva sul complemento a due (i valori negativi sono considerati enormi) e controllare tutti e quattro i bordi insieme con due confronti soli.
> e se m > 1 e n > 1 sono degli if senza if.
No, sono degli shift binari. Dividono per due le dimensioni della finestra ricavando il punto di mezzo, a cui vengono lasciati (m;n) che poi vengono consoderate le coordinate attuali del puntino. Cosi` il puntino parte al centro.
☺
Scritto da
altg
utente che non utiene
il 2014-10-05 15:24:22.0 alle 2014-10-05 15:24:22.0
Trollate totali: 11540
Facciamo progressi.
Questo e` il sorgentino di un programmino che sara` tra gli esempi.
Con tanto di syntax highlighting.
E questo, se vi fidate, e` l'eseguibile risultante:
non ho idea se funzioni anche su WinE, ma penso che dovrebbe.
http://anynowhere.com/personal/dotPong.exe
Fa rimbalzare un puntino bianco che lascia una lunga coda che si dissolve, tra i bordi di una finestra massimizzata. La sintassi mi piace com'e` venuta. E` anche oggettizzata: usa il costruttore canvas::Create (il riferimento all'oggetto risultante e` caricato nel registro puntatore primario p ) piu` vari metodi e getters. Il codice che reagisce al flag "asyncRetrace" gestisce il ridimensionamento della finestra quando si sposta la taskbar, e l'area disponibile cambia.
**Modificato dall'autore il 05.10.2014 15:24**
Questo e` il sorgentino di un programmino che sara` tra gli esempi.
Con tanto di syntax highlighting.
E questo, se vi fidate, e` l'eseguibile risultante:
non ho idea se funzioni anche su WinE, ma penso che dovrebbe.
Fa rimbalzare un puntino bianco che lascia una lunga coda che si dissolve, tra i bordi di una finestra massimizzata. La sintassi mi piace com'e` venuta. E` anche oggettizzata: usa il costruttore canvas::Create (il riferimento all'oggetto risultante e` caricato nel registro puntatore primario p ) piu` vari metodi e getters. Il codice che reagisce al flag "asyncRetrace" gestisce il ridimensionamento della finestra quando si sposta la taskbar, e l'area disponibile cambia.
**Modificato dall'autore il 05.10.2014 15:24**
NON DIRMELO SE LO SAI MA SE NON LO SAI SAPPILO
Ad
http://sallo.it
LO SAI? Allora NON fa per te. NON LO SAI? Allora non ti serve.
☺
Scritto da
altg
utente che non utiene
il 2014-09-19 22:34:34.0 alle 2014-09-19 22:34:34.0
Trollate totali: 11540
>
>
E` l'emozione di essersi fatto vedere in TV facendo una stronzata come comprare per primo l'ifon 6. La seconda stronzata era consequenziale.
>
E` l'emozione di essersi fatto vedere in TV facendo una stronzata come comprare per primo l'ifon 6. La seconda stronzata era consequenziale.
☺
Scritto da
altg
utente che non utiene
il 2014-09-18 23:00:22.0 alle 2014-09-18 23:00:22.0
Trollate totali: 11540
> > > > > > Una volta finitolo, come pensi di diffonderlo e invadere il mondo?
> > > > >
> > > > > Il povero L.in.oleum 1 e` sempre stato attraente, ma a forza di disfarlo e rifarlo nelle versioni successive ho scoraggiato tutti dall'usarlo, cosa che non mi stupisce ma che non considero un peccato, visto che cosi` ho potuto migliorarlo senza espanderlo a forza di rattoppi incoerenti in stile PHP. Quindi la strategia per diffonderlo una volta finito si riassume in: pubblicalo su anynowhere, aggiorna o lascia che qualcuno aggiorni l'articolo su wikipedia, attendi che si diffonda e LASCIALO STARE.
> > > >
> > > > Accompagnalo almeno con due righe in cui giuri che si tratta di una versione definitiva e le successive saranno mere migliorie retrocompatibili.
> > >
> > > L'avevo gia` giurato per la versione 1, non sarei credibile.
> >
> > La versione 1 non poteva essere retrocompatibile, a meno che non ci sia stata una versione 0.
>
> Uff ho scritto un'insensaggine, è meglio che vada a dormire.
Non e` grave. Um... magari poi potrei anche provare a ri-giurarlo, puo` darsi che se la ribevan... che riesca anche a mantenere, stavolta.
> > > > >
> > > > > Il povero L.in.oleum 1 e` sempre stato attraente, ma a forza di disfarlo e rifarlo nelle versioni successive ho scoraggiato tutti dall'usarlo, cosa che non mi stupisce ma che non considero un peccato, visto che cosi` ho potuto migliorarlo senza espanderlo a forza di rattoppi incoerenti in stile PHP. Quindi la strategia per diffonderlo una volta finito si riassume in: pubblicalo su anynowhere, aggiorna o lascia che qualcuno aggiorni l'articolo su wikipedia, attendi che si diffonda e LASCIALO STARE.
> > > >
> > > > Accompagnalo almeno con due righe in cui giuri che si tratta di una versione definitiva e le successive saranno mere migliorie retrocompatibili.
> > >
> > > L'avevo gia` giurato per la versione 1, non sarei credibile.
> >
> > La versione 1 non poteva essere retrocompatibile, a meno che non ci sia stata una versione 0.
>
> Uff ho scritto un'insensaggine, è meglio che vada a dormire.
Non e` grave. Um... magari poi potrei anche provare a ri-giurarlo, puo` darsi che se la ribevan... che riesca anche a mantenere, stavolta.
☺
Scritto da
altg
utente che non utiene
il 2014-09-18 22:14:07.0 alle 2014-09-18 22:14:07.0
Trollate totali: 11540
> > > Una volta finitolo, come pensi di diffonderlo e invadere il mondo?
> >
> > Il povero L.in.oleum 1 e` sempre stato attraente, ma a forza di disfarlo e rifarlo nelle versioni successive ho scoraggiato tutti dall'usarlo, cosa che non mi stupisce ma che non considero un peccato, visto che cosi` ho potuto migliorarlo senza espanderlo a forza di rattoppi incoerenti in stile PHP. Quindi la strategia per diffonderlo una volta finito si riassume in: pubblicalo su anynowhere, aggiorna o lascia che qualcuno aggiorni l'articolo su wikipedia, attendi che si diffonda e LASCIALO STARE.
>
> Accompagnalo almeno con due righe in cui giuri che si tratta di una versione definitiva e le successive saranno mere migliorie retrocompatibili.
L'avevo gia` giurato per la versione 1, non sarei credibile.
> >
> > Il povero L.in.oleum 1 e` sempre stato attraente, ma a forza di disfarlo e rifarlo nelle versioni successive ho scoraggiato tutti dall'usarlo, cosa che non mi stupisce ma che non considero un peccato, visto che cosi` ho potuto migliorarlo senza espanderlo a forza di rattoppi incoerenti in stile PHP. Quindi la strategia per diffonderlo una volta finito si riassume in: pubblicalo su anynowhere, aggiorna o lascia che qualcuno aggiorni l'articolo su wikipedia, attendi che si diffonda e LASCIALO STARE.
>
> Accompagnalo almeno con due righe in cui giuri che si tratta di una versione definitiva e le successive saranno mere migliorie retrocompatibili.
L'avevo gia` giurato per la versione 1, non sarei credibile.