Forum libero

> Nella sezione Preferenze ora puoi darti un titolo !
> Questo comparira' sotto il tuo avatar.
>
> Mi sono preso la liberta' di assegnarne qualcuno a caso

Ad anynowhere i titoli li abbiamo dal 2003.
No, lo rammento cosi`, tanto per rompere i coglioni...

> 3. Socchiudendo vedi anche le ciglia spuntare dal di sotto. Bloccando con un dito la palpebra inferiore, dimostri che le ciglia che vedi sono quelle della palpebra superiore: quindi la visione è rovesciata.

um... oppure e` un qualche gioco della diffrazione, che ti fa credere che sia la palpebra superiore. Io non riesco a riprodurre quell'effetto. Se blocco la palpebra inferiore, blocco quel che vedo apparire dal basso.

> Perciò potrebbe essere vero (andrebbe fatto qualche schema) che i cosi si trovano all'interno dell'occhio.
> L'altra volta ci chiedevamo come mai, se fossero all'interno, si vedono cadere verso il basso, dato che l'immagine dovrebbe essere rovesciata. Può darsi che ci siano due rovesciamenti?

Puo` darsi, ma allora non saprei dove. Gli schemi dell'occhio che si trovano sulle enciclopedie illustrano la luce che entra nel cristallino ed esce producendo un'immagine (singolarmente) rovesciata sulla retina, come in una negativa fotografica. Nel caso della fotografia (classica, non su CCD come oggi) la seconda proiezione della negativa attraverso la lente del proiettore, durante lo sviluppo, ri-rovescia l'immagine proiettandola dritta. Questo lavoro, nell'occhio, lo farebbe, cosi` dicono i libri, l'area visiva primaria del cervello.

> Come si chiamano già quei cosi negli occhi? Ho fatto recentemente degli esperimenti.

Miodesopsie?

> Hai già chiesto a quelli di anynowhere cosa ne pensano?

No, prima lo porto in una condizione piu` o meno utilizzabile, almeno per esplorare come funziona, e scrivo uno straccio di tutorial di 4000 megabytes.

Magagne e ottimizzazione (piu` che altro del codice prodotto, anche se qualcosa lo fa gia`) a parte, il compilatore dovrebbe essere essenzialmente finito. Ha ereditarieta`, polimorfismo, e ora anche interfacce e metodi virtuali. A me non sembrano neanche tanto illeggibili nell'uso pratico:



E` un programmino di prova fatto per poi seguire lo sviluppo di una librerietta (dal nome nostalgico di "character generator") che scriva qualcosa con un font bitmapped. Il succo della questione dell'interfaccia e` questo qui:

p as bitmap <- Create m By n Pixels
q as characterGenerator <- Bind To bitmap Using Raster p

Fa il typecasting sul registro p, cioe` di che il registro p e` di tipo... bitmap, creandone un'istanza e dimensionandola a m x n pixels. E fin qui s'era gia` visto. La seconda riga crea invece l'interfaccia (la novita`). Casta q a characterGenerator, e poi lo "binda" (blinda la supercazzola prematurata eccetera eccetera), cioe` lo lega alla sua implementazione per bitmaps. Dice "Using Raster" perche` la classe astratta da cui discendono bitmap e canvas, i due tipi concreti di raster, e` appunto raster. Seguendo la prima riga del listato si arriva al file che definisce l'implementazione:



che a sua volta include il file che definisce l'interfaccia e qualcosa per fare un puntino sullo schermo per confermare che il metodo "Say" e` stato eseguito. La vera implementazione va al posto di quel puntino, ma devo ancora scriverla. Al di la` di quello, le parole chiave li` sono "implements" nella dichiarazione del nameset, e l'esportazione della tabella dei metodi virtuali, che lega la entry pSay della tabella dell'interfaccia all'indirizzo del metodo Say implementato sopra. Nel file dell'interfaccia:



che e` scarno e abbozzato (ha solo il metodo Say e nessuna informazione di stato) si vede la inlet "Bind To p" che alloca l'istanza dell'interfaccia, e poi la passa a un'utilita` che smista gli indirizzi dei metodi alle entries della tabella (la tabella e` composta solo da "count pSay"). In fondo, dopo un costruttore alternativo e un mutator tanto per dire, quello che conta e` il metodo virtuale Say, che infatti non e` implementato li` ma esegue un salto per puntatore a r.pSay.

Facile, no?

> > > > Non capisco con che logica dovrebbe considerarlo giusto.
> > > > Comunque m'informero' di piu'.
> > >
> > > No no non c'e` bisogno che tu t'informi meglio: hai azzeccato il punto.
> > > Non si capisce con che logica dovrebbe considerarlo giusto. E` li` il bello.
> > >
> > > Una regola per stabilire le priorita` c'e`, ed e` l'inverso dell'ordine in cui i file vengono inclusi, oppure i namespace elencati dopo la keyword "resolve". Pero` e` una regola difficile da applicare a mente, e quindi prona alle catastrofi. Pero` magari e` utile perche` c'e` da scrivere talmente poco che se c'e` qualcosa di sbagliato ci se ne potrebbe accorgere. Come dire: uno dice "resolve all" e poi va coi piedi di piombo.
> >
> > Insomma, funziona se le funzioni sono limitate e specifiche?
> > Nel caso ci sia una gran varieta', dove piu' persone ci stanno lavorando sarebbe un bel disastro. A meno che tutti seguano la medesima scrittura, forse se fossero robot le menti programmatrici, possono aggiornarsi sui cambi e usare il "resolve all" sempre.
>
> Piu` che altro funziona se il file su cui stai lavorando e` piccolo e semplice. La complessita` del resto non e` influente.

Si` insomma mica tanto, ora che ci penso. Nell'unione di tutti i namespaces, anche quel che cambia esternamente al file potrebbe rompere qualcosa. Mi sa che ci ripenso, va'... troppo pernicioso.

> > > Non capisco con che logica dovrebbe considerarlo giusto.
> > > Comunque m'informero' di piu'.
> >
> > No no non c'e` bisogno che tu t'informi meglio: hai azzeccato il punto.
> > Non si capisce con che logica dovrebbe considerarlo giusto. E` li` il bello.
> >
> > Una regola per stabilire le priorita` c'e`, ed e` l'inverso dell'ordine in cui i file vengono inclusi, oppure i namespace elencati dopo la keyword "resolve". Pero` e` una regola difficile da applicare a mente, e quindi prona alle catastrofi. Pero` magari e` utile perche` c'e` da scrivere talmente poco che se c'e` qualcosa di sbagliato ci se ne potrebbe accorgere. Come dire: uno dice "resolve all" e poi va coi piedi di piombo.
>
> Insomma, funziona se le funzioni sono limitate e specifiche?
> Nel caso ci sia una gran varieta', dove piu' persone ci stanno lavorando sarebbe un bel disastro. A meno che tutti seguano la medesima scrittura, forse se fossero robot le menti programmatrici, possono aggiornarsi sui cambi e usare il "resolve all" sempre.

Piu` che altro funziona se il file su cui stai lavorando e` piccolo e semplice. La complessita` del resto non e` influente. Comunque resta un'opzione da usare con cautela per programmatori pigri.

> > Qui siamo andati oltre: a un certo punto ho messo 'sta cosa ("resolve all") che dice vabbe', non importa in che namespace stia, io risolvo tutto. Se qualcosa lo trovo fra i file inclusi di sopra, lo considero giusto.
>
> E se lo hai con il medesimo nome in due namespaces diversi ?

Risolve quello nell'ultimo namespace incontrato o nella keyword:

resolve zuppa pesce

darebbe la precedenza a pesce::xx piuttosto che a zuppa:xx

oppure, nel caso di "resolve all", a quello del namespace dell'ultima libreria inclusa (nell'ordine in cui vengono incluse). In teoria il suo comportamento e` prevedibile, ma in pratica kabooooom lo stesso.

Comunque non so, l'ho pensato per sorgentini brevissimi dove non ci si vuol rompere le scatole a ricordare il namespace, tanto son quattro righe e una collisione sbagliata e` improbabile e facile da rilevare. Tutto sommato potrebbe anche restare, come opzione da usare con cautela. Pero` forse rimpiazzo la keyword "all", se no mi tocca proibire il namespace "all". E magari vabbe' cosi`, tanto chi e` che vorrebbe dichiarare un namespace "all"?

temo di aver appena conseguito la piu` grande vittoria dei namespace su loro stessi e sul buon senso. Per evitare di cospargere il sorgente di scope resolvers (blah::banf), ok, meglio avere qualcosa come "using". Vabbe'. Pero` anche piu` namespaces potrebbero essere risolti in un ordine prevedibile, no? Mah, vabbe'. Eh, pero` poi mi tocca scriverli tutti, se invece tenessi traccia di tutti i namespace dei file inclusi in un file um... e cosi` avevo introdotto la keyword "resolve", per esempio col namespace "string", "resolve string". Poi "resolve string heap"... "resolve string heap arc"... "resolve string heap arc file"... si` insomma sono arrivato a "resolve all".

Non so se riderci su o non documentare la funzionalita`.

> > > Quando ho iniziato la transizione del FdT a JOOQ avevo accarezzato l'idea di usare ormlite, ma certe queries mi avrebbero fatto bestemmiare in aramaico ...
> >
> > Sì, le join sono un po' un casino.
> > Io l'ho usato infatti per usare l'orm dove necessario per risparmiare tempo, e facendo le query a mano dove non era applicabile.
>
> Comunque PIViewer sara' semplicissimo: maven + ormlite + JAX-RS (jersey) + gson, con l'aggiunta di guava e fors'anche guice.
> La GUI fatevela da voi ^{webix ?} !

Annuncio con fierezza che ho capito solo GUI.