Newsgroup: it.lavoro.informatica
Titolo: UI: prima o poi doveva succedere.

Mi chiedono - finalmente aggiungo - cosa significherebbe costruire un supervisore per impianto di risalita sotto Linux. Dico finalmente, perché sono anni che dico: ci si potrebbe pensare.

Problema mio: mancanza di esperienza; io sotto linux ci ho sviluppato applicazioni web (Python + CherryPy + Js), qualcosa, ma poco, con QTCreator.

Ho sviluppato le cose più prestanti e graficamente efficienti sotto Windows in C#. Lo so, esiste C# e il progetto Mono per Linux, e mi dicono sia pure ben portabile, però non l'ho mai impiegato.



Ecco, sondaggio: se voi da zero, oggi, doveste costruire un supervisore per impianto (leggi: no interfaccia web), cosa impieghereste d'istinto?



-- 

Ciao!

Luca


 Ecco, sondaggio: se voi da zero, oggi, doveste costruire un supervisore per impianto (leggi: no interfaccia web), cosa impieghereste d'istinto?



C++ lato server (Linux), C++(QT)/Java/C#/Delphi/Python (client Windows), 

C++(QT)/Java/Python (client Linux). Se si opta per un client web di 

monitoraggio, JavaScript (magari con WebSocket) + mare di librerie UI.



-- 

4ndre4

"The use of COBOL cripples the mind; its teaching should, therefore, be 

regarded as a criminal offense." (E. Dijkstra)

"Ora, questo "Delta11" non è nulla di più di uno scemo del 

villaggio[...]" - 
http://goo.gl/1nrkkX



 C++(QT)/Java/Python (client Linux).



Dimenticavo Lazarus (
http://www.lazarus-ide.org/
) che forse e` l'opzione 

migliore lato client Linux.



 monitoraggio, JavaScript (magari con WebSocket) + mare di librerie UI.



L'idea di un client web di monitoraggio è interessante, e la tengo da conto. Tendenzialmente in un supervisore 1) non si usa un'architettura client/server e 2) ancor meno un'architettura web, per una questione di velocità di presentazione dei dati (devi pensare potenzialmente a un minimo di una decina di aggiornamenti al secondo). 

Python - mi pare sia chiaro - è al momento il mio linguaggio di riferimento, ma non sono molto soddisfatto delle librerie grafiche; oggi come oggi, dovessi fare un'UI senza pensare al resto, oltre tutto cross-platform, penserei a QTCreator...

Credo si capisca che sono piuttosto confuso. Alla fine, forse, un'architettura client/server (serve scritto in Python e UI con QT) non è così da buttare, anzi.



-- 

Ciao!

Luca


 L'idea di un client web di monitoraggio è interessante, e la tengo da conto. Tendenzialmente in un supervisore 1) non si usa un'architettura client/server e 2) ancor meno un'architettura web, per una questione di velocità di presentazione dei dati (devi pensare potenzialmente a un minimo di una decina di aggiornamenti al secondo). 





Scusa, ma che se ne fa un utente di 10 aggiornamenti al secondo?


per una questione di velocità di presentazione dei dati (devi pensare 

potenzialmente a un minimo di una decina di aggiornamenti al secondo).



"presentazione dei dati" e "decina di aggiornamenti al secondo" non 

vanno nella stessa frase. Avere dei dati aggiornati 10 volte al secondo 

non serve ad alcun utente, anche perche` nessun umano sarebbe in grado 

di reagire prontamente a un qualsiasi evento che si presenti in un 

intervallo cosi` breve.



 Scusa, ma che se ne fa un utente di 10 aggiornamenti al secondo?



Niente :)





Eh caro il mio vecchio, si vede che di automazione non ne capisci un cazzo.

Vedi te se quando muovi manualmente un asse non ti serve un 

aggiornamento di quel tipo sulla quota corrente.

Se non sai di cosa sto parlando non importa, magari rifletti sul fatto 

che su certe questioni non ne sai un cazzo.






Il decimo di secondo è gestibile da un umano che è concentrato su un 

compito preciso. Per dire, prova a vedere se le coordinate che ti fa 

vedere un tornio su cui operi manualmente non è importante che siano 

aggiornate con quella frequenza e magari più alta.

Pirla.




 Eh caro il mio vecchio, si vede che di automazione non ne capisci un cazzo.



Sei tu che non hai capito un cazzo di quel che si sta dicendo, 

purtroppo. Dieci aggiornamenti al secondo NON servono a nessun utente, 

servono alle macchine. E` diverso. Ti lascio perdere, per il tuo bene, 

perche` al solito finirai per incararti sparando cazzate che non riesci 

a difendere.



 Pirla.



LOL :) Risposta da culo dolorante, come al solito. Che idiota, mamma mia.





Peccato che sei all'estero.






Lascia lascia, come sempre.



c++ sicuramente,per l'affidabilità

Ma sta anche al programmatore saper gestire bene un linguaggio complesso 

come c++.

Questo d'istinto,poi in pratica vedrei i requisiti,cosa ho a 

disposizione o no,che programmatori ho (cosa conoscono,ecc..) e 

probabilmente altre cose che ora non mi vengono in mente.




 Ecco, sondaggio: se voi da zero, oggi, doveste costruire un supervisore per impianto (leggi: no interfaccia web), cosa impieghereste d'istinto?



non so cosa faccia nel dettaglio un "supervisore per impianto", se deve 

comunicare con dei sensori/attuatori, se deve lavorare in real time, se 

ha dei processi asincroni, se ha una interfaccia utente o se ha un po' 

tutte di queste cose.

ad ogni modo mi pare una scelta di tipo architetturale prima che di 

linguaggio, questione quest'ultima che riterrei addirittura irrilevante. 

voglio dire, quel "no interfaccia web" mi sembra un tantino frettolosa 

come specifica.






 Ecco, sondaggio: se voi da zero, oggi, doveste costruire un supervisore per impianto (leggi: no interfaccia web), cosa impieghereste d'istinto?



D'istinto C++/Qt o C++/wxWidgets.

Pero' ho solo una vaga idea di cosa sia "un supervisore per impianto", 

per cui potrei aver detto una fesseria.


 c++ sicuramente,per l'affidabilità



Sembri un venditore porta a porta del c++. Tutti i linguaggi moderni sono affidabili almeno quanto il c++. E se vogliamo parlare di affidabilita', caso mai la differenza la fanno le metodologie di sviluppo.


 aggiornamento di quel tipo sulla quota corrente.



Mai sentito dire che un essere umano possa interpretare 10 aggiornamenti visuali al secondo. Avrai degli studi da mostrarci immagino, o parli a vanvera?



Inoltre si parlavi di supervisori di impianto. Immagino che non ci sia un unico numerino che cambia 10 volte al secondo, ma svariati output che mutano continuamente. Ovviamente questo rende ancora piu' ridicola la tua affermazione.


 Idiota, io automazione l'ho fatta per anni.



Anche sviluppo web immagino, eppure non ne capisci una cippa.


 anni che dico: ci si potrebbe pensare.



Hai valutato Lazarus?



Ciao

  Francesco



Questa non l'ho capita. Cosa cambierebbe se fosse in Italia?







No, i linguaggi moderni hanno quasi tutti un gc.

Questa e una grana bella e buona  per i sistemi con tempi critici.




Madame Damentami <mdd...@nomail.address> ha scritto:


si incontrerebbero in un vicolo per pestarsi ben bene a vicenda,

poi sorreggendosi a vicenda vanno a bere una pinta di birra insieme :-D









A parte che non e' detto che sia un problema, anzi. In ogni caso ci sono gc e gc, e ognuno hai i suoi molteplici parametri.



Ed allora perché non fanno in java (esempio) un sistema in real time per 

controllare una centrale nucleare,o per la centralina di aeroplano, o 

per il controllo di sala operatoria tramite computer (alcuni esempi).

Chissà,tanto e' la stessa cosa,proponigli di usare java,cosi mi faccio 4 

risate.

Il gc e' solo una parte del problema.

La macchina java e' ben piu complessa di una macchina C o C++ (o anche 

COBOL)

E piu strati di sw ci sono meno controllo si ha,e la probabilità di 

bachi aumenta.





Per finire per i novellini java che credono che il gc (visto che l'ho 

tirato in ballo) risolva i loro problemi e  anche se ha poco  a che fare 

con la discussione lo faccio lo stesso:





while (<cond>) { //java - in caso di errori la classe ftp lancia 

l'eccezione FTPExcpt e solo quella

	try {

		ftp f=new ftp(<address>);

		.... // usa ftp

		ftp.close(); // chiude la connessione

	}

	catch (FTPExcpt e) {

		System.err.println(e.msg());

		// l'eventuale errore viene ignorato

	}

}





Questo codice java e' buggato





Invece in  C++



while(<cond>) { //C++ - in caso di errori la classe ftp lancia 

l'eccezione FTPExcpt e solo quella

	try {

		ftp f(<address>);

		....   // usa ftp

	}

	catch(const FTPExcpt& e) {

		std::cerr << e.msg() << std::endl;

		// l'eventuale errore viene ignorato

	}

}



A parte il close mancante ma non necessario questo codice C++ non e' 

buggato.





Codici cosi buggati in java ne ho visti tanti.

Si vede che fanno pessimo insegnamento di java.

Ma il problema e' il linguaggio in quanto scarica sull' utente della 

classe la gestione della risorsa (la connessione ftp)

Invece in C++ il problema della risorsa (sempre la connessione ftp)  sta 

al progettista della classe come giustamente deve essere.
















 al progettista della classe come giustamente deve essere.





https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html




Studia e aggiornati prima di cianciare a vanvera.










Quell'esempio che ho fatto era codice reale,di un applicativo (non fatto 

da me) che poi ho corretto.

In una connessione ssh dopo un loop di 40 connessioni (doveva farne un 

migliaio) il processo scoppiava.

Non ho bisogno di leggere quell'artico,conosco le problematiche di java 

(buggato per design) sulla gestione delle risorse.
















Eh ma se non capisci quel che si scrive che vuoi da me.

Un supervisore fa tante cose, tra le tante che può fare c'è anche la 

movimentazione manuale di parti di impianto (es durante le manutenzioni, 

le calibrazioni o altro), e ci sono parti di impianto tipicamente 

appunto le movimentazioni via asse (singolo o interpolato) su cui per 

l'appunto ci si concentra per bene e le quote si devono aggiornare in 

fretta, anche con quella frequenza li.

Ma si può pensare anche a fasi di calibrazione di processi dove ti viene 

riportato un grafico che rappresenta un andamento che è necessario 

visionare con aggiornamenti di quella frequenza, es: la coppia che un 

albero applica al serraggio di qualcosa. L'operatore di turno ha bisogno 

di avere l'andamanento più preciso possibile.

Se no ti sa, tasi, dai.





Nein, di striscio, molto d più il backend.

Lo sviluppo web non può piacere a gente che non è masochista, io non 

sono masochista, i problemi che arrivano mi bastano e avanzano...

I cazzilli puramente tecnologici che stanno dietro ad uno sviluppo che è 

tutto tranne che maturo, è tempo che non mi affascinano più.





Ma per piacere, al massimo lo batterei ad un triathlon di rutti, 

scoregge e bestemmie. Nulla di più, non ne vale la pena.






 (buggato per design) sulla gestione delle risorse.



Non e' un articolo sulle problematiche di Java, scimunito. E' una caratteristica del linguaggio che non conosci. Studia e ripassa.



E' perfettamente inutile che la smeni con frasi ad effetto del tipo "l'andamanento più preciso possibile", "aggiornare in fretta", eccetera eccetera.



E' perfettamente inutile perche' tutti sanno che un essere umano non puo' gestire input con frequenze di quel tipo. Lo sanno anche i sassi che certe quantita' e tempistiche (10 input al secondo ad esempio) l'essere umano non puo' gestirle. E quindi possono essere presentate in batch su intervalli di tempo percepibili dall'occhio. Questa e' l'ABC dell'informatica, caro mio.



Ovvero, che il cursore in una griglia Excel ci impieghi 1 millisecondo oppure 10 per muoversi, NON CAMBIA ASSOLUTAMENTE NULLA. 



Ma leggi quello che la gente scrive prima di fare interventi kamikaze come questo!


 tutto tranne che maturo, è tempo che non mi affascinano più.



Non e' che una cosa non e' matura se non la capisci. Non funziona cosi'.


 Codici cosi buggati in java ne ho visti tanti.



sei un programmatore ricercato in team d'eccellenza, vedo.




Stampa e tienilo come promemoria.




 per impianto (leggi: no interfaccia web), cosa impieghereste d'istinto?



go with go ;) 



-- 

Massimiliano Adamo








Mi sai che tu hai capito bene una cosa

Non è che i bachi non si fanno,è il baco by design che avevo accennato.

Perchè è un baco by design,alle risorse ci deve pensare il progettista 

della classe,sia a crearle,sia a distruggerle.

E smettila di dare del deficiente agli altri,come se non sapessi che 

occorre usare finally.

L'esempio del baco by design l'ho postato io,mica sono cosi deficiente 

da non sapere la soluzione.














Non ero in quei team.




 Non ero in quei team.



chissà che quei bug fossero proprio opera tua. sicuramente vista la

presunzione/arroganza di autopromuoverti a correttore di altri non

conoscendo (per tua stessa ammissione) il linguaggio, ne saresti ben

capace.




 Scusa, ma che se ne fa un utente di 10 aggiornamenti al secondo?



Ci sono situazioni in cui devi avere aggiornamenti molto veloci. Attenzione, non sto dicendo che TUTTE le variabili devono essere aggiornate 10 volte al secondo.



-- 

Ciao!

Luca


 intervallo cosi` breve.



OK, visto che mi fate in due la domanda, mi spiego in modo un po' più diffuso.



Partiamo da un principio: la frequenza di aggiornamento dell'UI di un supervisore è legata al tipo di impianto che stai trattando e a cosa vuoi aggiornare. Non ha senso aggiornare frequentemente i dati di un supervisore da container per campo eolico o fotovoltaico, perché primo i dati, fatti salvi gli allarmi, non variano con grande frequenza, secondo spesso il container non è presidiato, per cui nessuno vedrebbe nulla.



Ci sono impianti viceversa che necessitano di frequenze di aggiornamento variabili a seconda di cosa stai guardando  (il quantum viene definito a livello progettuale). 



Lo scopo di frequenze di visualizzazione molto alte non è legato all'intervento. Come giustamente hai rilevato, l'essere umano non avrebbe il tempo di intervenire in modo efficace, ed ecco perché normalmente la logica è a bordo macchina, con due scopi: la macchina deve girare, pur con le penalizzazioni del caso, anche senza supervisore; il tempo di intervento a fronte di situazioni eccezionali deve essere immediato.



La frequenza di campionamento alta ha scopo di presentare immediatamente all'operatore ciò che sta accadendo; tempi di ritardo di mezzo secondo o un secondo sono inaccettabili, soprattutto se gli eventi avvengono in cascata.



Ti faccio un esempio specifico. Giusto ieri ero in su impianto di risalita a fare test. In questo caso frequenze di aggiornamento elevate hanno senso:

- nella visualizzazione di allarmi e protezioni intervenute; dal momento che in questo caso si parla di sequenze di eventi che accadono, la scheda a bordo macchina ha un buffer tampone interno che viene riempito; cura del supervisore è scaricare questo buffer nel più breve tempo possibile, perché è inefficace che la sequenza sia ancora in fase di aggiornamento lato supervisore quando l'impianto è già fermo;

- nella visualizzazione delle curve di frenata; un arresto rapido impiega due secondi: son 20 campioni per fare la curva di decelerazione, con una base tempi molto stretta; anche qui vale la storia del buffer e dello scarico che ho raccontato per le protezioni;

- nella visualizzazione dei proximity in stazione; negli ammorsamenti automatici la vettura, nell'arco di tutta la sua presenza in stazione, viene monitorata; in particolare, ci sono un certo numero di punti di passaggio, controllati con sensori di prossimità, che hanno corrispondenza con un insieme di strumenti (led) nel sinottico nel supervisore; qui la frequenza di campionamento è importante perché, soprattutto in fase di decelerazione o di accelerazione (si passa da 6 m/s a 0,5 m/s e viceversa in poco tempo) si corre il rischio di perdere un passaggio vettura; come puoi immaginare si tratta di pochi dati, stiamo parlando di una o due dword i cui bit vanno spacchettati, ma con frequenza di campionamento elevata.



-- 

Ciao!

Luca.


 quei dieci aggiornamenti al secondo e ti credero`. 



Secondo me la vedi sbagliata. Non è l'operaio che deve reagire velocemente alla macchina, è la macchina che deve reagire velocemente all'operaio, anche nella visualizzazione lato supervisore (fa parte della macchina nel suo complesso). Pensiamo a una regolazione di velocità: io operaio agirò su un bel manopolone che mi consente la regolazione fine; ebbene, il mio interesse è avere il feedback di ciò che ho fatto il prima possibile.



-- 

Ciao!

Luca


 non so cosa faccia nel dettaglio un "supervisore per impianto", 



Nell'impianto costituisce l'interfaccia evoluta nei confronti dell'operatore; deve consentire a impianto fermo la sua configurazione / predisposizione e, a impianto in movimento, la visualizzazione di ciò che accade e la possibilità di qualche - limitato - intervento.



-- 

Ciao!

Luca


 per cui potrei aver detto una fesseria.



Di fatto per il front-end potrebbe essere interessante proprio il QTCreator che citavo, che ha una libreria sconfinata e un'ottima portabilità.



-- 

Ciao!

Luca


 Inoltre si parlavi di supervisori di impianto. Immagino che non ci sia un unico numerino che cambia 10 volte al secondo, ma svariati output che mutano continuamente. 



Vedi la mia risposta a Andrea.



-- 

Ciao!

Luca




 Hai valutato Lazarus?



Me l'ha citato Andrea. Pur avendo suscitato il mio interesse - sarebbe un bel tuffo nel passato, nella libreria sta ancora fieramente a prender polvere il Grogono e ho lavorato in Pascal fino alla prima versione di Delphi - lo valuterò, ma non vorrei aggiungere il necessario ri-studio del linguaggio alle complessità che già ci sono. 



-- 

Ciao!

Luca




 Questa e una grana bella e buona  per i sistemi con tempi critici.



A me più di tanto non ha mai dato problemi; anche perché, come dice un mio caro amico, i tempi di GC vanno tenuti da conto, in fase progettuale!



;-)



-- 

Ciao!

Luca








 complessità che già ci sono. 



In se e per se l'object pascal è abbastanza pulito da essere ripreso in fretta.



Luca posso scriverti in privato per un consiglio?



Ciao

  Francesco


 Ecco, sondaggio: se voi da zero, oggi, doveste costruire un supervisore per impianto (leggi: no interfaccia web), cosa impieghereste d'istinto?



Dando per scontato che sotto linux siano disponibili i driver per 

interfacciarsi agli apparati, penso che la situazione migliore sia usare 

le librerie Qt.



Queste librerie possono essere usate con vari linguaggi: ovviamente con 

il c++ con cui sono scritte, ma anche con il python e recentemente anche 

con Go.



Hanno inoltre il vantaggio di essere portatili e girano sotto windows, 

linux, osx e anche android, iOs, windows phone...



e per finire su svariati dispositivi embedded...





Recentemente l'ho vista citata nei credits software del mio player 

blu-ray Sony....









Certamente. Sempre otluca _AT_ yahoo _DOT_ it. Poi multiplexo io... :-)



-- 

Ciao!

Luca


 Ci sono situazioni in cui devi avere aggiornamenti molto veloci. Attenzione, non sto dicendo che TUTTE le variabili devono essere aggiornate 10 volte al secondo.



a 10 fps comincia ad essere una buona animazione per una gif.



ad ogni modo aggiornare una interfaccia dieci volte al secondo non è

proprio un problema: il problema solitamente è riuscire ad ottenere i dati

con quella frequenza. un banale sensore di temperatura e umidità non

è così scontato che ti risponda in meno di 100 ms, per dire.






Il mio esempio era per fare notare una problematica dell'uso del gc,non 

la non conoscenza del linguaggio.

Mi spiace che tu e l'altro non abbiate capito quello che ho scritto.




 portabile, però non l'ho mai impiegato.



Il runtime in quanto tale funziona molto bene, te lo dico per esperienza personale, sia per applicazioni Web che di altro tipo. Secondo me però avresti due problemi: da un lato la maggiore complessità e possibile lentezza dell'ambiente "managed" (comune anche alla JVM), dall'altro per la UI la scelta migliore è il GTK+ che non è amichevole o completamente affidabile. Purtroppo i binding per Qt sono in perenne stato di sviluppo e il resto (wxWidgets in particolare) è incompleto, obsoleto o inaffidabile.



m.


 occorre usare finally.



Come potrei non darti del deficiente, sei un essere buffo e strampalato. Non c'e' bisogno di chiuderle nel finally, lo vuoi capire o no? Apri quel cazzo di link che ti ho postato.




Mi ricordo che bus di campo industriali facevano girare informazioni con 

un refresh intorno ai 10 ms, per informazioni intendo i valori correnti 

di punti di I/O sia digitali che analogici distributi per l'impianto. La 

disponibilità di quei valori al supervisore non cambia molto visto che 

lo stesso supervisore spesso è un nodo che fa farte della rete 

attraversata dal bus di campo.








Adesso non c'e bisogno del finally,mi sa che lo strampalato sei tu

L'unica eccezione dove si puo fare a meno del finally e' quando si è 

sicuri che la classe non lancia eccezioni o usa come risorse solo la 

memoria centrale (ma se usa una risorsa che non sia la memoria centrale 

è difficile che non lancia eccezioni).

Tutti gli altri casi  è praticamente un obbligo (se si vuole fare buona 

programmazione almeno dal punto di vista di java) usare il finally.

E questo comporta anche una bella cosa,dichiarare gli oggetti fuori dal try



Es:

	ftp f=null;

	try {

		f=new ftp(...);

		...

	}

	catch(...) {

	}

	finally {

		if (f != null)

			f->close();

	}



Il che significa dichiarare un oggetto in uno scope che non gli compete 

(il suo vero scope dovrebbe essere il blocco try) e la sua dichiarazione 

non è una costruzione (e' un pointer null).



In C++:



	ftp f(...);



oppure usando i pointer:

	std::unique_ptr<ftp> f(new ftp(...));



La dichiarazione è anche l'inizializzazione

Questo facilita la manutenzione e la chiarezza del codice.






















In java non c'è l'equivalente dello using in c#?

https://msdn.microsoft.com/en-us/library/yh598w02.aspx


Li lo hanno fatto apposta per questo.






 non è una costruzione (e' un pointer null).

Obietterei che l'unica competenza di un blocco try-catch e' solo quella 

di gestire le eccezioni. Cosa diversa dallo scope, infatti se dichiari 

la variabile nel blocco try ne limiti lo scope a quel blocco impedendone 

l'utilizzo nel blocco finally o altrove.

Prendi ad esempio:

       ftp f=null;

       try {

           f=new ftp(...);

           ...

       }

       catch(...) {

       }

       return f;

Va da se' che la responsabilita' di gestire la risorsa f vada gestita 

altrove.





Lo using, per quanto ne sappia io, e' solo una sintassi per limitare 

l'esistenza di una risorsa al blocco using. In java e' stata introdotta 

l'interface AutoCloseable che grosso modo ha la stessa funzionalita' 

dell'utilizzo di un interfaccia IDisposable in un blocco using.





Il try e' ovvio che serve per gestire le eccezioni, e' comunque uno scope




 E questo comporta anche una bella cosa,dichiarare gli oggetti fuori dal try



NONEEEE. Sei un imbecille presuntuoso, e questo e' ormai assodato. Infatti, se avessi aperto quel link avresti scoperto che si puo' fare nel seguente modo:



try (Ftp f = new Ftp()) {

  f.quelloCheVuoi();

}



e f non e' dichiarato fuori dal try.



Bello,cosi hai le risorse non chiuse

Non chiami neanche la close e la disconnessione la fa quanto interviene 

il gc



Ma forse volevi farlo cosi:



try (Ftp f = new Ftp()) {

	f.quelloCheVuoi();

	f.close();

}



ma anche questo e' buggato,in caso di exception non viene fatta la close 

(la farà il solito gc quanto interviene)



Non hai ancora capito che il finally ci vuole ?









Se Ftp implementa AutoCloseable e il close è appunto chiamato nel metodo 

che implementa l'interfaccia, allora quella forma di try (senza finally) 

è equivalente ad avere il close nel finally.

Pari pari a quello che ho linkato su msdn per c#.

Certo è che bisogna che ci scrive le classi implementi AutoCloseable 

nel modo corretto e bisogna pure che chi usa la classe si ricordi di 

adoperare quella forma "particolare" di try.






 (la farà il solito gc quanto interviene)



la tu testa è buggata.

sono dieci messaggi che ti parlano del meccanismo dell'AutoCloseable e

te ancora non hai capito una beneamata sega.

e poi ti atteggi anche a quello che deve correggere i bug degli altri. 

ignorante e presuntuoso per me sei proprio il profilo di programmatore che

riempie i programmi di arrosti, altro che.





Che abbia uno scope e' indubbio, ce l'hanno anche gli if, il try non e' 

mica il figlio della schifosa da stare senza scope. io parlavo proprio 

di responsabilita', in quanto questo avevo capito dal tuo post. Se 

avessi frainteso, scusami. Pero' spiegati.


 Non hai ancora capito che il finally ci vuole ?



Studia.



Se e' autoclosable va bene,ma non tutte le classi sono cosi



Occorre ereditare dall' interface AutoCloseable ed e' da java7





Purtroppo quando si manutiene un sw non sempre si puo fare (o voglia) di 

un porting su un java piu recente e correggere le classi.

Se poi sono fatte da altri (nel senso reperite da internet) e' ancora 

piu dura.







Come se tutte le classi ereditassero da autocloseable

Ma fammi il piacere.

Motivo in piu,visto che hanno messo una toppa,per avere ragione.



 un porting su un java piu recente e correggere le classi.

Posso capire le reticenze a migrare a Java8, ma a java7 non mi sono mai 

accorto di problematiche particolari.

Va da se' che la responsabilita' della risorsa rimane di chi la 

utilizza, per cui implementazioni particolari dovranno occuparsi di 

invocare esplicitamente close(). Ma questo vale per qualsiasi 

linguaggio, o no?






 Ma fammi il piacere.



perché dovrebbero implementarla tutte le classi? la implementano le 

classi che la devono implementare, cioè quelle che hanno risorse da 

rilasciare esplicitamente.

d'altra parte tu dai per scontato che la tua classe c++ rilasci 

automaticamente le risorse, ma se non implementa il distruttore col 

piffero che le rilascia...





Ma in c++ chi le usa non serve che adoperi una sintassi particolare 

perché il distruttore sia chiamato, se non ricordo male viene chiamato 

sempre e subito quando la variabile esce dal suo scope.

Invece in java e c# il distruttore lo chiama il gc qundo gli gira (a 

meno di forzamenti particolari) e altri metodi "surrogati" chiamati 

all'uscita dello scope vengono chiamati automaticamente solo se chi usa 

la classe adopera la sintassi appropriata (il try "paricolare di java o 

lo using in c#).

Da questo punto di vista quindi il c++ è più sicuro by design.




 Occorre ereditare dall' interface AutoCloseable



Non per forza. In java 8 puoi usare questo trick:



Foo foo = new Foo();

try (Autocloseable _ = foo::close) {

  foo.do();

}


 sempre e subito quando la variabile esce dal suo scope.



viene chiamato sempre quando viene distrutta l'istanza. se l'oggetto

lo allochi dinamicamente con new *non* viene distrutto quando esce dallo

scope. 

tu dirai: ma io quelle classi non le alloco dinamicamente. bene, ma allora

non è grazie ad una maggior sicurezza "by design" ma a degli accorgimenti

di programmazione, esattamente come in java o c#. se l'istanza è nello

stack hai la gestione automatica, se è nell'heap no; dite pure quello che

vi pare ma per la gestione della memoria non è la stessa cosa, considerato

che qui c'è gente che si vanta di usare il c++ perché così ha modo di

spaccare il capello in quattro.


 sempre e subito quando la variabile esce dal suo scope.



A mia memoria, in C++ devi invocare delete su un oggetto perché tutto il processo di liberazione delle risorse avvenga; vero questo, se dimentichi di invocare un delete il tuo baldo oggetto non viene eliminato. 



De facto, 'by design' il garbage collector ti mette al riparo da tutto questo; non solo, ci sono meccanismi (in C# l'interfaccia IDisposable) che ti consentono di controllare la distruzione degli oggetti.



-- 

Ciao!

Luca


 comodita' di un gc. Altrimenti non avrebbe senso la sua esistenza.



Esiste per permettere ad eserciti di scimmie di fare gli operai 

dell'informatica.








Nel mondo reale con sw da manutere e che sono installati da vari clienti 

non si fa un porting di major version ogni volta che ad oracle li viene 

lo sghiribizzo di buttarne fuori una.


















Bello, una nuova future introdotta da java8 per mettere una pezza ad un 

baco by design del linguaggio.

Ma proprio una pezza e'










In C++ qualunque classe che abbia risorse da rilasciare (compresa la 

memoria) ha un distruttore

Se non lo avesse sarebbe un baco del progettista della classe non del 

linguaggio.

Ed è cosi da quando è nato il linguaggio.

Non c'e bisogno di inventarsi future come finally o autocloseable per 

sopperire ad un baco by design del linguaggio stesso.







Qualcuno che capisce finalmente.

In java (non conosco c# per cui non ci entro) sta (a meno di 

autocloseable che comunque e' recente) all'utilizzatore della classe 

chiamare l'apposito metodo che rilascia le risorse.

Con tutti i problemi che comporta.

Non e' certo la stessa cosa del c++ dove la responsabilità sta al 

progettista della classe e solo a lui.

In C++ l'utente della classe (a meno di usare direttamente new ma spero 

che nessuna lo faccia  da ben prima di C++11) non si deve preoccupare di 

chiamare il sopracitato metodo

Ci pensa il distruttore.












 Ma proprio una pezza e'



Non e' stata introdotta per venire in aiuto di try-with-resources ma semplicemente un trick che si puo' fare con le Lambda. Altra caratteristica del linguaggio che evidentemente non conosci neanche di striscio.



Eh si che qualche messaggio fa ti vantavi di conoscere il linguaggio.



E' una tecnica di progettazione che a meno di strati di livello basso 

nessuno usa piu da ben prima di C++11.

In C++11 hanno ufficializzato il tutto con l'introduzione di shared_ptr 

e unique_ptr.





Ed è una tecnica che non si usa piu da anni,ben prima di C++11 a meno di 

strati di livello basso di una classe.

Quello che il gc fornisce e' solo un falso senso di sicurezza

Infatti in java,visto che poi ci pensa il gc,ci si puo dimenticare (ed 

accade in sw reali)  che il gc interviene quando vuole lui e se la 

memoria e' abbastanza grande come in un normale pc praticamente solo 

alla terminazione del processo.

Su c# non discuto,non è un linguaggio che conosco.




 linguaggio.



in java qualsiasi classe che abbia una risorsa da chiudere / rilasciare

implementa l'interfaccia AutoCloseable. 

se non la implementasse sarebbe un baco del progettista della classe e non

del linguaggio.



Da java7





Una buona regola di design dice che lo scope di una variabile deve 

essere il piu ristretto possibile.




 alla terminazione del processo.



ROTFL, e' incredibile come ti dai la zappa sui piedi da solo. 



Si, puo' succedere infatti che la old generation non venga neppure reclamata, risparmiando cosi' tempo e prestazioni. E cosa ci sarebbe di male?



EPIC FAIL!!



Sei in altro spara cagate?




Ma aspetta un attimo, come è stato detto e me ne ero dimenticato, in c++ 

quello che allochi con new lo devi deallocare a mano con delete.

Quindi in c++ se ti dimentichi di fare il delete il distruttore non 

viene chiamato e rimani fregato.

Che si fa in C++11 di diverso dal new e delete?







Certamente,ma e' una pratica che non si usa piu da anni (da ben prima di 

c++11)



Da c++11 si usa unique_ptr o shared_ptr.







Si puo sapere dove avrei scritto di diverso da quello da scritto in 

altri thread ?





Cosa e',la battuta del gg ?









Sei un linguaggio e- troppo facile entrano anche cani e porci ad usarlo.

Gente che farebbe meglio ad andare a zappare,farebbero un favore 

all'umanità con qualcosa di utile.





Al di la' di questa tautologia, io parlavo di responsabilita'. Ti faccio 

un esempio, cosi' forse mi riesco a spiegare.



Url url = new Url("
http://pippo.com
")

InputStream input = url.openStream();



Indipendentemente dallo scope, e' evidente o no che la responsabilita' 

di chiudere input non e' di url anche se l'ha aperto?


 lo sghiribizzo di buttarne fuori una.

Ci mancherebbe.





E' sufficiente Closeable. Con java 6 il compilatore ti da un warning 

resource-leak, compilando a java 7 il warning sparisce.



Il tuo è un gran Epic Fail. Invece di parlare forse dovresti prima padroneggiare le basi del linguaggio.



E' una tecnica primitiva in quanto possibile fonte di errori e 

dimenticanze da parte dell'utente della classe.

Perfino il comitato di C++11 ha aborrito,dopo che da anni altre tecniche 

furono consolidate,tecniche del genere.

Infatti ha ufficializzato le classi unique_ptr e shared_ptr per i 

pointers (gli oggetti sullo stack non hanno mai avuto problemi del 

genere fin dalla nascita del linguaggio).

In java per default non e' cosi.

Se ricordo bene,tu conosci Python,e se è cosi mi confermi che come perl 

pur usando tutti e due il gc usano il metodo del reference countig per 

sapere quando un oggetto e' da distruggere

Una sorta,in gergo C++,di shared_ptr.

In java non e' cosi,l'oggetto viene solo marcato da distruggere e il 

thread del gc quando interviene fa le apposite pulizie.

In pratica in C++,perl e Python la distruzione e' deterministica,in java no.

Ed ecco che quando occorre chiudere risorse limitate come una 

connessione di rete la responsabilità ricade sull'utilizzatore della classe.

Ma non si vede il motivo di questo se persino un linguaggio come C++ che 

puo essere usato per scopi piu disparati implementa,attraverso la 

libreria std per i pointers e attraverso il linguaggio stesso per gli 

oggetti sullo stack, la tecnica della distruzione deterministica.

In pratica in java hanno fatto il lavoro a meta,si sono "dimenticati" 

che come risorse non esiste solo la memoria centrale.

Quando se ne sono accorti si sono inventati la clausola finally pero 

scaricando sull'utente della classe la responsabilità del loro rilascio.

E recentemente,visto che il lavoro di finally è fatto a metà (la 

responsabilità rimane dell'utilizzatore) si sono inventati l' autoclosure.

Ma il danno oramai era fatto.

Java è semplicemente l'esempio che la perfezione umana non esiste.

In fondo anche C++ ha dovuto fare i conti con idiosincrasie del C.


















Ovvio,hai confermato quello che ho scritto se non te ne sei accorto.




Da me (java6) non ho avuto nessun warning

Questo lo ricordo bene.

Evidentemente la classe ssh (il problema reale risolto era una 

connessione ssh) non implementava Closeable.










Uso java da piu di 10 anni

E ne ho viste di tutti i colori.

Magari non mi sono aggiornato,visto che java non mi interessa piu di 

tanto,delle ultimissime novità, ma questo non significa che non lo conosca.














Mai vantato di questo

Java è per me e un linguaggio che uso qualche volta per lavoro  ma 

personalmente non lo userei mai.

Ma se non sono aggiornato sulle ultime future non significa che non lo 

conosco.

PS. le lamba function ci sono anche in C++

Ma lo sai che in java ci sono pure i generics una pallida imitazione dei 

template C++ visto che continui a rompere i ciufoli ?

Oppure tu consci java al 100% ?

Se si buon per te,a me non interessa.

In java oramai faccio solo manutenzione di codice non scritto da me.

L'ultimo applicativo java che ho scritto sono oramai 7 anni fa.

Se ti vuoi leggere una bella digressione sui distruttori chiamati in 

modo deterministico leggiti la mia risposta al dott. Gagliardelli.






 Mai vantato di questo



eccalallà. 



una recente ricerca dell'università di ponte a niccheri ha dimostrato qualunque

cosa scriva enoquick prima o poi dichiarerà di non averla mai scritta.



come scrisse qualcuno: discutere con lui è come giocare a scacchi con un 

piccione: potresti essere il più grande giocatore di scacchi del mondo, 

ma il piccione continuerà a rovesciare tutti i pezzi, scagazzerà sulla scacchiera 

e camminerà impettito andando in giro con aria trionfante.



Vedi ragazzo mio,continui a fare illazioni su illazioni.

Java è buggato by design come ho ampiamente dimostrato

Non è arroganza,sono fatti dimostrati.

Che poi abbiano in futuro cercato di mettere delle toppe non toglie 

nulla al mio scritto.

Leggiti anche tu la mia risposta data al Dott. Gagliardelli.




 Vedi ragazzo mio,continui a fare illazioni su illazioni.



poero grullo.



Tutto li quello che sai dire ?




 Non è arroganza,sono fatti dimostrati.



Da chi? Da enoquick? ROTFL.



I due approcci hanno vantaggi/svantaggi ampiamente documentati. Non e' vero che la soluzione che usa il reference counting e' piu' sicura e da vantaggio rispettoo all'altra. Ci sono situazioni in cui va meglio, e altre in cui sposta l'onere della gestione sul programmatore.










Spiega meglio, cosi magari questa volta mi metto a ridere io

Ma non preoccuparti, il sottoscritto non ti insulterà come tu hai fatto 

con me.




 con me.



Sei tu che insulti con la tua disonesta' intellettuale.






Va be,facciamo pace

Abbiamo discusso abbastanza.




 C'e anche da dire che comunque sta alla responsabilita del programmatore



Ecco appunto.






La probabilità di un errore del genere e' quasi 0.




 La probabilità di un errore del genere e' quasi 0.



Parola di enoquick.








Assolutamente.

La prova e' che avendo a che anche con perl errori di questo tipo per me 0.

Non me ne sono mai capitati.




 Non conosco Clojure per mettermi a discutere su come implementa il gc



Non implementa alcun GC, si affida a quello che gli mette a disposizione l'host, ovvero la JVM nel nostro caso.






Non ho elementi per giudare Clojure

Ma mettendolo in ballo non vedo cosa abbia a che fare con java.





Mark & clean

Correzione.