Newsgroup: it.comp.lang.c++
Titolo: PyConUno

Ciao a tutti,
questo weekend sono stato a PyConUno, la prima conferenza italiana su
Python. "E a noi che c'e'..." direte voi.
In realta' volevo riallacciarmi a un paio di thread di qualche tempo
fa. Prima di tutto ci ho incontrato parecchi frequentatori vecchi e
attuali - soprattutto vecchi - di questo newsgroup: Alex Martelli,
Andrea Griffini, Antonio Cuni, Manlio Perillo... caso mai qualcuno si
domandasse cosa fanno ora :-) In secondo luogo e' stato molto
piacevole incontrare un gruppo cosi' vasto di persone in gamba con le
quali scambiare opinioni ed esperienze.
A maggior ragione spiace che la comunita' che si era formata intorno a
questo newsgroup si sia cosi' sfilacciata, anche per colpa di Alex e
dei suddetti ;-)
Ciao,
Nicola


peccato che la scelta sia (mi pare di capire) Python vs. C++ :(
ciao.

 peccato che la scelta sia (mi pare di capire) Python vs. C++ :(
Beh, non e' necessario che sia cosi'. Alcuni hanno effettivamente
"abbracciato" Python abbandonando il C++, altri li hanno affiancati.
Se e' vero che esiste una ampia famiglia di applicazioni dove Python
e' indubbiamente piu' efficace, questo non vuol dire che il C++ sia da
buttare, ne che tutti i programmatori in gamba d'Italia si occupino
solo di Python :-)
Ciao,
Nicola

 Nicola
ciao!

 invece del C++, così tanto per avere qualche riferimento
Per esempio tutte le applicazioni che fanno manipolazioni sofisticate
di stringhe. In C++ non e' un incubo come in C, ma e' certamente
dietro Python in termini di praticita'.
Ciao,
Nicola

 Nicola
ciao!

 solo di Python :-)
Lo spero proprio! Certo che gioverebbe a questo NG che i tuoi amici ed
exfrequentatori ritornassero ogni tanto a fare capolino da queste
parti...
ciao.

di stringhe.
Non c'era già il Perl per questo? :-P ghghgh...

parti...
Ha giovato in passato a molti la presenza di quelle persone, ma il
problema è che, tra off-topic vari e quello lì che chiede come
disegnare una finestra in Visual C++ e quell'altro che non sa come
allocare un char*, il livello delle discussioni in un ng come questo
(non vale solo per questo ng) scende molto spesso al di sotto della
soglia minima che susciti interesse nei cosiddetti "esperti".
E' un peccato, ma forse la qualità delle domande è un riflesso diretto
del mercato del lavoro, in cui non ci si sforza di studiare
continuamente (cosa che il mestiere del programmatore impone almeno in
via teorica), ma ci si limita ad arrabattarsi tra conoscenze
approssimate e acquisite, bene che vada, 10 anni prima.
In Italia, conoscete il C e lavorerete come programmatore C++;
conoscete il C++ e non necessariamente lavorerete come programmatore
C++.

 Non c'era già il Perl per questo? :-P ghghgh...
Leggi meglio: ho scritto *applicazioni*, non *accrocchi* ;-)
Ciao,
Nicola

 C++.
Senza contare che se vi va bene vi divertite, ma non e' certo da
programmatori che farete carriera.
Ciao,
Nicola

 livello di uno all'anno.
Però attenzione alla differenza tra "leggere" e "studiare". Dubito che la 
seconda cosa possa essere fatta in metro. Probabilmente solo se uno già 
conosce bene l'argomento allora riesce a leggere un libro di approfondimento 
in metro.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 in metro.
Ah, beh, studiare e' ormai qualcosa che riesco a fare solo se ci sono
dirette esigenze di lavoro :-(
Ciao,
Nicola

 invece del C++, cosě tanto per avere qualche riferimento
Ciao, guarda io non ho lo spessore di Nicola o altri di questo NG, 
quindi potrei dire una cavolata, anche perchč non conosco Python perň 
con il C++ ad esempio manca il supporto nativo alla programmazione 
multi-thread, bisogna ricorrere librerie (per quanto ne son non 
standard) o addiruttura chiamare direttamente le API, lo stesso codice 
puň quindi puň non essere supportato su un compilatore (o perchč non ci 
sono le librerie specifiche per quel compilatore) o un sistema operativo 
(perchč ha API diverse), si esce dallo standard C++ e questo per me 
rappresenta un problema. Ormai con le CPU multi-core dobbiamo scrivere 
codice "parallelo" e con il C++ lo faccio ma comincio a sacrificare (o 
per ignoranza mia o per carenza del linguaggio) lo standard.
Secondo me questo č un limite (forse mio, ma...) che comincia a pesare, 
mentre da quello che ho letto Python... č piů moderno sotto tanti 
aspetti. Al di la della prestazione pura, perchč secondo me l'efficienza 
č ancora dalla parte del C/C++.

 programmatori che farete carriera.
Infatti io sono un pentito che quando ha dovuto scegliere si è dato 
all'oleodinamica... Ho studiato informatica e poi vista l'esperienza dei 
miei amici (comunque sottopagati) mi sono dato alla progettazione 
meccanica, che almeno nella mia terrra (l'Emilia Romagna), paga molto di 
più. Fortuna che ogni tanto riesco a scrivere qualche s/w per lavoro...
Ciao.

 è ancora dalla parte del C/C++.
Secondo me sul piano concreto questo e' meno un problema di quanto
sembri, pero' e' vero che bisogna fare delle scelte: ACE?
Boost.Threads? Meccanismi nativi, che spesso sono drammaticamente C
oriented?
Tra l'altro, se mi si passa il gioco di parole, il solo fatto che
questo sia percepito come un problema costituisce un problema che va
affrontato. Per fortuna nel caso dell'esempio specifico qualcosa si
muove ed e' molto probabile che nella prossiva versione dello standard
ci saranno primitive di threading; resta pero' da vedere quando queste
saranno effettivamente disponibili a ciascun programmatore nel suo
ambiente di sviluppo.
Ciao,
Nicola

 approssimate e acquisite, bene che vada, 10 anni prima.
Non penso, *ai fini della nostra discussione* che centri molto il
mercato del lavoro.
Chi usa il C/C++ si divide in: studenti/neofiti, chi ci lavora e si
"specializza" nel campo suo proprio (embedded, grafica eccetera), e i
superesperti.
Sarebbe sbagliato fondare ad esempio un: it.comp.lang.learn.c++, o
it.comp.lang.c++-advanced? Così ad ciascun NG si avrebbe il livello
che si merita :)
Ciao.

 Soviet
Coloro che sanno devono condividere info. E' ovvio nel tempo che si
vuole, e si può, dare. Così l'utenza si allarga.
Mi sa che ripeto quello detto più dietro: che gioverebbe a questo NG
che i soliti noti ritornassero ogni tanto a fare capolino da queste
parti.
Ciao.

Leggi meglio: ho scritto *applicazioni*, non *accrocchi* ;-)
Touché :-)

seconda cosa possa essere fatta in metro.
E' verissimo. E' cosě vero che alla fine in metro io riesco a leggere
e capire l'argomento al momento, ricevendone la cosiddetta
infarinatura. La cottura vera avviene a casa (tempo permettendo) con
la tastiera, lo schermo e gli esercizi col compilatore. Il problema č
quando (come mi accade spesso) torno a casa tardi dal lavoro, passano
i giorni e la farina la lascio tutta per terra :-)

programmatori che farete carriera.
Ahimè.

 Andrea Griffini
!!!
6502/Fatal Rage!!! =)
--
Pan/SpinningKids & FatalRage (in demo-version per l'occasione) 

 che si merita :)
Onestamente in italia non ne vedo la necessita' =)
Non mi sembra che ci siano problemi di traffico qui, anzi si accettano (al 
contrario dei gruppi internazionali) anche occasionali offerte di lavoro, e 
si alternano risposte base e risposte avanzate...
Se tutti gli esperti si spostassero altrove, il newsgroup base perderebbe 
parecchio.
--
Marco 

che si merita :)
Non si tratta di "meritare" nulla. Aprire un nuovo ng e seguirlo non
costa nulla in termini economici e di capacità di lettura, quindi una
differenza del genere sarebbe la benvenuta.

 Marco
Per me è vero l'esatto contrario, vista la carenza di discussioni
sarebbe meglio allargare il tema trattato dal newsgroup, ad esempio
parlando anche di varie librerie (boost, gtk, qt, wxWidget, ecc..). In
fin dei conti in iclp non sono così snob e direi che quanto a traffico
e interesse ce ne è più che su questo newsgroup.

 programmatori che farete carriera.
Eddai, non esagerare... c'e' una bella differenza tra probabilita' zero e 
impossibilita'! =)
--
Marco 

 ciao.
Per me non e' affatto cosi' (almeno per il momento). Io uso ancora
molto il C++, sia perche' devo mantenere tonnelate di codice scritto
negli anni e sia perche' anche nei nuovi progetti ora ha preso per me
il posto dell'assembler quando si tratta di andare a lottare con i
cicli
macchina. L'accoppiata Python / C++ (tramite sip) a me pare molto
molto interessante; e' possibile paritre con la leggerezza e la
pulizia
sintattica python per poi subentrare solo dove necessario con
classi C++ (e il passaggio e' graduale e indolore, si possono
addirittura subclassare in python classi C++ importate con sip).
Quello che invece mi manca e' pero' il tempo per seguire attivamente
usenet.
Andrea

e interesse ce ne è più che su questo newsgroup.
Perché Python è più facile da usare del C++ e quindi raccoglie
sicuramente più proseliti.

 differenza del genere sarebbe la benvenuta.
Comunque l'idea di aprire dei sottogruppi più mirati, non sembra
piacere molto...
Ciao.

 addirittura subclassare in python classi C++ importate con sip).
sip? Mi spiegheresti meglio? Non conosco molto il Python...
Sperendo di non andare troppo OT...
ciao

 con tutti i crismi e un software non debba subire lo stesso processo.
E' esattamente ciò di cui mi lamento sempre anch'io. Quello che succede nella 
mia piccola esperienza di programmatore autonomo è paragonabile a quello che 
succederebbe se il futuro acquirente di un appartamento (o il suo 
intermediario) potesse dire la sua su come vuole che sia realizzato il 
palazzo...



Io non trascurerei la documentazione dei sorgenti quasi mai presente
(doxygen cosa sei?) e quelle figure che stanno in azienda da una vita,
che hanno visto il prodotto nascere e crescere e se non ci sono loro
dovendo metterci mano son dolori...

 quali si può imparare tanto.
Grazie di aver messo anche il mio nome ma temo di non meritarmelo dato che la 
mia conoscenza del C++ è abbastanza superficiale.


piacere molto...
Come lo sai?


wrote:

http://directory.fsf.org/Python-SIP.html



Grazie. Noto che realizzare il "front-end" in python e il core del
programma in c++ diventa sempre più comune.
Ciao.

programma in c++ diventa sempre più comune.
In realtà si dovrebbe ricorrere al C++ solo se strettamente
necessario. In Python si può svolgere benissimo gran parte dei
compiti, è un linguaggio completo (e per certi versi più ricco del
C++).

dovendo metterci mano son dolori...
La questione non è tanto la documentazione dei sorgenti (che pure è
importante, ma è il male minore in questo caso) quanto l'analisi vera
e propria e la fase di progettazione. "Progettare", questa parola
oscura che non tutti conoscono e che in pochi sanno realizzare in
concreto è importantissimo al fine di costruire fondamenta robuste e
che non lascino crollare il software miseramente al minimo stress. I
sistemi software crollano perché non vengono progettati a dovere; per
fare un esempio, è come se anziché tirare giù il progetto di un
palazzo, studiarlo per non farlo cadere, si cominciasse a mettere giù
mattoni e poi ci si ingegnasse tutto il tempo per mantenerlo e non
farlo cascare. Il problema del software è che, al contrario del
palazzo, si può tirare giù e riscrivere senza lo stesso impatto
commerciale e sociale. Poi in realtà l'impatto nella riscrittura di un
sistema informativo c'è sempre, ma si è quasi sempre troppo miopi per
vederlo. In Italia vedo sempre più spesso codice scritto coi piedi,
lavori artigianali fatti di pezze su pezze, la cui manutenzione fa
venire i brividi al malcapitato di turno e dalla quale lo stesso cerca
di liberarsi al più presto cedendo la patata bollente alle mani di
altri malcapitati (quasi sempre consulenti sottopagati). Si va avanti
così finché si può. E' una vergogna.

 ...ad libitum.
Quello che non capisco e' com'e' che non sono ancora milionario.
Comunque se c'e' bisogno sono qui, eh? ;-)
Ciao,
Nicola

 unica FAQ *per tutti* non basta.
Prima di tutto un fatto incontrovertibile: col poco traffico che c'e'
su questo newsgroup non c'e' alcuna speranza che il GARR accetti di
spezzettarlo in piu' newsgroup.
In secondo luogo il problema non e' la distinzione principianti/
esperti; un newsgroup come questo *deve* avere anche uno scopo
didattico, ci mancherebbe. Il problema deriva caso mai dal fatto che
molto spesso i principianti mostrano di non aver fatto alcuno sforzo o
quasi prima di postare sul newsgroup e di non essersi neanche posti il
problema se la loro domanda e' in tema nel newsgroup o meno.
Ciao,
Nicola

 diverso dal C++.
La differenza dipende dal fatto che tendenzialmente chi si dedica a
Python lo fa per una scelta esplicita, e questo fa si che in genere ci
sia un atteggiamento positivo, di voglia di sbattersi.
Al contrario per parecchi la scelta del C/C++ (sic!) e' una scelta
passiva e questo evidentemente porta piu' spesso ad un atteggiamento
net-maleducato; Chi si e' gia' sbattuto si rompe, e chi la voglia di
sbattersi ce l'ha ne paga le conseguenze.
Ciao,
Nicola

 Comunque se c'e' bisogno sono qui, eh? ;-)
"Hmmm... mi sa che tu costi troppo" (cit.).

 - Sono compilabili almeno con g++ ed un altro compilatore.
buona idea!
ciao.

sul C++
Sono io che sto diventando dislessico: avevo inteso che quel "aprire"
si riferisse a nuovi ng, invece tu indendevi aprire in senso lato
questo ng a nuovi argomenti e su questo sono d'accordo. Concordo sul
fatto che aprire altri ng non avrebbe successo.

 programmatori che farete carriera.
Esatto: e personalmente aggiungo che ci si diverte anche sempre di meno.
Almeno questo nella mia esperienza
 
Ciao,
Marco

 A parte che a me j2ee fa schifo "in toto", [...]
Parentesi su J2EE. Spezzo una lancia perché questa tecnologia la vedo
abbastanza bistrattata un po' ovunque:
Io lavoro come consulente presso il cliente (una società di dimensioni
medio-grandi) dove J2EE è utilizzato pesantemente.
Personalmente non lo trovo così male, benché mi piaccia lavorare con
linguaggi diversi da Java per passione mia personale.
Noi ci abbiamo fatto e stiamo facendo cose carine (anche con i web
services). Credo che alla fine la percezione di una tecnologia dipenda
anche da come si è costretti a lavorare con essa e in quale ambiente
si lavora. Io fortunatamente lavoro a fianco di persone che questa
tecnologia la conoscono bene, hanno le idee chiare, progettano in modo
corretto e i sistemi vengono su bene. Quando riesci a sfruttare una
tecnologia nel modo migliore (o ti ci avvicini), è difficile
disprezzarla, con tutti i difetti che ha. J2EE è veramente molto
potente e non riesco ad immaginare una piattaforma, oggi, che possa
competere con essa. Ho scoperto con piacere Ruby On Rails, vorrei
trovare il tempo di studiarmelo, anche se a naso mi sembra piuttosto
acerbo. Sul lato .NET conosco poco e niente e dovrei onestamente
approfondire.

 è ancora dalla parte del C/C++.
Non è una tua opinione, è un dato di fatto. Non a caso i programmatori
Python quando hanno bisogno di performance isolano le sezioni critiche e
le riscrivono in C o in C++ (comunque con un considerevole risparmio di
tempo rispetto a fare tutto in C o in C++).
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 sia un atteggiamento positivo, di voglia di sbattersi.
Non solo: diciamo che essendo una tecnologia meno mainstream facciamo
anche molta più propaganda in gruppi correlati, con il risultato che si
incuriosisce gente. 
Inoltre va detto che un utente di basse skills è facile che riesca a
fare qualcosa che lo interessa in Python, mentre in C++ deve prima fare
molta gavetta prima di affrontare compiti 'interessanti'.
Per dire io il primo script Python che ho visto (e all'epoca non
conoscevo Python) era sostanzialmente un aggeggio per misurare il
throughput di una connessione di rete. Mi erano state chieste alcune
dritte perchè all'epoca tiravo parecchio su socket posix (e Python offre
un'interfaccia abbastanza fedele, ma senza tutti i problemi di gestione
di memoria e buffer).
È una roba che uno butta su in pochissimo e senza sostanziale tempo di
debug. Poco tempo dopo mi sono scritto un set di script che mi generava
a partire da alcuni dati un sito web. Pochi pomeriggi di lavoro. In C++
penso che sarebbe stato un trauma, fra trovare librerie per parsare
HTML, output elaborato, regex, manipolazione di stringhe, dicevo solo
per trovare le librerie e buttare su i makefile probabilmente ci sarebbe
andato altrettanto.
Per cui alla fine molti non tecnici imparano a remare navigando. 
Eppure spesso pongono domande facili, ma che danno luogo a discussioni
interessanti.


processi e programmazione asincrona, sarebbe meglio per tutti.
Questa è una cosa già sentita, ma mi permetto di non essere d'accordo.
Anche se ci sono contesti in cui i processi e la programmazione
asincrona sono la scelta migliore (ed effettivamente l'ho constatato),
ci sono ugualmente contesti in cui il multithread è indispensabile (o
almeno mi sembra tale, poi sono pronto a ricredermi). Quello che posso
dire è che le mie applicazioni multithread funzionano bene e non mi
hanno mai dato problemi; personalmente evito di creare condizioni
"bloccanti", ma uso ad esempio code di messaggi per far comunicare tra
loro i thread. Non ho mai sperimentato deadlock di alcun tipo.
Sinceramente non ci vedo tutta questa terribile e inutile complessità,
anzi. Tra parentesi: a ma dà un po' fastidio quando la gente comincia
a sparlare dei thread e a proporre metodi alternativi solo per moda
(ovviamente non sto parlando di te! intendiamoci), solo perché
qualcuno più esperto suggerisce di fare così. Bisognerebbe
sperimentare sempre per conto proprio e capire qual è la soluzione più
adatta...

 
CUT ALL
ciao
Soviet

 adatta...
Come ti dicevo, ci sono fior di casi in cui i thread sono utili. Il
problema è che IMHO non dovrebbero essere 'la prima scelta'. Semmai si
dovrebbe vedere se sono indispensabili, e solo in questo caso usarli.
Altrimenti fare con altro.
Fra le altre varie cose il codice multithread che usa i thread quasi
come fossero processi, risulta *estremamente* più efficiente sui
processori moderni, per dire, perchè è più cache friendly.
Invece molti 'nuovi' crescono a pane e Java dove in buona sostanza la
rpima cosa che ti viene sbattuta in mano sono i threads (e in se di roba
asincrona per Java ce ne è, solo che in pochi la conoscono e la usano).


 volatile, boh)
No. Non si tratta di parole chiave. Si tratta di librerie. Purtroppo non
sono completamente convinto che il linguaggio più facile con cui fare
queste cose sia C++. 
Comunque i due casi da te indicati sono esempi di programmazione
asincrona. Tipicamente si tratta di trasformare in non bloccanti le
operazioni di I/O e gestirle in modo asincrono. Tuttavia oggetti come
Twisted ti mettono in un mondo asincrono dove gestisci tutto con eventi
e callback (ed errback, se qualcosa va storto). Io quello ho in mente.
Qualcosina (ma in confronto a Twisted è un giocattolo) lo puoi vedere in
RealBasic. 
Per C++, come dire, puoi cominciare a lavorarci con asio e farti un
idea. In se la cosa non è concettualmente difficile (anzi). Devi solo
imparare a vedere le cose in un altro modo. Io ho iniziato molto presto
a vedere roba asincrona, per cui ormai mi viene abbastanza naturale
'vederle', ma è tutto li il fatto. 
Complessivamente fai più fatica a visualizzare quello che stanno facendo
i thread (dove ci sono a tutti gli effetti più 'PC', mentre in un
modello asincrono puro c'è *sempre* solo un unica istruzione in
esecuzione).


asincrona per Java ce ne è, solo che in pochi la conoscono e la usano).
Eh eh, infatti, ma anche perché un'applicazione Java è MT (purtroppo)
per definizione.

 
Sicuro?
A livello applicativo, è interessante il confronto tra PostgreSQL e MySQL 
(che, se non prendo un abbaglio clamoroso, è multi thread):
http://tweakers.net/reviews/657/6
MySQL è più veloce di PostgreSQL, eppure non scala.
Riguardo la questione della cache, poi, Nicola Musatti al Python ha fatto 
un intervento interessante durante un mini talk di Nicola Larosa su 
Twisted e la programmazione asincrona.
Saluti  Manlio Perillo

 Twisted e la programmazione asincrona.
Se c'è qualche link, leggo volentieri. Siccome Nicola legge, immagino
possa indirizzarmi. Sfortunatamente io a Pycon non c'ero (e infatti non
ci siamo incontrati :P) per motivi universitari,


MySQL è più veloce di PostgreSQL, eppure non scala.
Humm... si rischia di andare OT, ma la cosa mi incuriosisce.
Che intendi per "non scala"? Lavorando tutti i giorni con MySQL (e con
PostgreSQL in misura minore), la cosa mi interessa. Personalmente, ho
utilizzato MySQL per applicazioni anche molto complesse, con decine di
milioni di recordo sotto e faceva il suo lavoro abbastanza bene.

 sotto e faceva il suo lavoro abbastanza bene.
La questione dello scaling era solo una curiosità dato che, se non 
sbaglio, PostgreSQL è multi processo mentre MySQL è multi thread.
P.S.
Questo messaggio non avevo intenzione di inviarlo, dato che OT.
Volevo salvarlo ma ho premuto il menù sbagliato :).
Questo anche per rispondere ad Enrico, dato che il messaggio contiene 
troppi elementi soggettivi.
Saluti  Manlio Perillo


http://tweakers.net/reviews/649/7
Sì, della superiorità di Pg rispetto a MySQL sento parlare spesso ed è
il motivo per cui, già in passato, ne avevo considerato l'utilizzo, ma
c'era l'impedimento di cygwin di mezzo per cui ho rinunciato. Quando
Pg ha avuto il suo bel binario per Windows ho cominciato a usarlo per
cose serie. Purtroppo, visti gli strumenti di sviluppo che uso per i
gestionali (Delphi, in particolare) non ho un buon supporto per questo
DB ahimé, mentre per MySQL è eccezionale (uso i driver dbExpress di
CoreLab). 
Riguardo il tema specifico della scalabilità, rimango comunque
perplesso, perché personalmente ho visto lavorare MySQL in contesti
abbastanza estremi, con un discreto numero di accessi contemporanei e
qualche decina di milioni di record di database. Non si è piegato poi
così tanto sotto il peso.

 esecuzione).
capito
grazie
Soviet

 
E' un framework scritto in Python.
Saluti  Manlio Perillo

mmm, purtroppo non č l'I/O il settore che mi premerebbe di piů.
Azz... in generale, I/O significa programmazione :-)

 Azz... in generale, I/O significa programmazione :-)
sicuramente è il campo più classico dove l'elaborazione 
asincrona è più utile.
In una risposta a Mc Osten Franchi spiegavo in che senso mi 
serviva poco (più che altro ho incontrato qualche caso in cui 
delle routine di solo calcolo mi occupavano il programma per 
tempi fastidiosamente lunghi, e quindi avrei voluto al limite 
rendere non bloccanti giusto quelle procedure di calcolo 
numerico per non bloccare l'intera interfaccia).
con questo chiudo l'OT su python (e mi scuso dello stesso)
ciao
Soviet

 numerico per non bloccare l'intera interfaccia).
Attenzione però: il modello asincrono (e qui vale sia per C++ che per
altro) non è che automagicamente salva la vita. Mi spiego: se la tua
routine impiega 10 secondi per essere eseguita e sei single thread,
quella routine ci impiegherà comunque 10 secondi.
In quei 10 secondi l'interfaccia non è attiva (a meno che internamente
il tuo ambiente non le dedichi un thread separato).
Il modello asincrono ti permette di mettere 'in fila' in modo automatico
le varie operazioni e lasciare che vengano eseguite una dietro l'altra.
Per esempio questo è molto comodo su un server di rete. Ma anche su un
programma GUI 'normale'.
Se hai un'azione lunga o la spezzetti (e i pezzetti li leghi in modo
asincrono), oppure la distacchi in un thread (o in un processo) e
ritorni il risultato in modo asincrono.
+---------+ event  +----------------------+ notify
| RunLoop |--------| Very Long Action...  |----------+
+---------+        +----------------------+ finished |
     |                                               |
     +-----------------------------------------------+
 
 
+---------+  e1  +------+ 
| RunLoop |------| Very |
+---------+      +------+
 | | | | |         | finished_1
 | | | | +---------+
 | | | | e2              +------+
 | | | +-----------------| Long |
 | | |                   +------+
 | | |                      |  finished_2     
 | | +----------------------+       
 | |                     
 | | e3              +------+                                
 | +-----------------| Long |                 
 |                   +------+                 
 |                      |  finished_2         
 +----------------------+                     
 
 
                    event vla finished                   
      - - - - - - - - - - - - - - - - - - - - - - -
      |                                           |
                                                  __________
+-----V---+  event   +---------------------+     /          \
| RunLoop |----------| detach thread /fork |     | Observer |     
+---------+          +---------------------+     \__________/
    |                   |   ||                        A
    +-------------------+   ||                        
        return              ||                        |
                    +------------------+             
                    |+----------------+|              |
                    ||Very Long Action||- - - - - - - -     
                    |+----------------+|  notify finished   
                    +------------------+     
 
Nel secondo caso il computer 'risponde' a te al più ogni n millisecondi
(dove n è il tempo del più lungo segmento). Nell'ultimo caso ritorna
subito (ma la CPU resta impegnata e lo scheduling è fatto dall'OS).
Nel secondo caso in pratica stai 'manualmente' gestendo una qualche
forma di scheduling, ed è scomodo ed error prone.
Io personalmente userei la terza alternativa, se l'azione è davvero
lunga. Altrimenti non me ne curerei e rimarrei alla prima.
</IT>


 si rischia di andare OT, ma la cosa mi incuriosisce.
Non si era deciso di aprire un poco il NG?
Poi io in passato ho usato anche Access con tabelle da un milione di 
record e sono sopravissuto. Sapendo i limiti delle cose si riescono 
anche a sfruttarli (a volte).
-- 
mai più senza: 
http://www.genux.com/scheda.asp?idprod=47974
la cultura è importante: 
http://www.libreriadellautomobile.it

 record e sono sopravissuto.
Anch'io posso dirlo. Da quel che ho visto, Access, checché ne dicano
in giro, si è comportato sempre egregiamente anche con basi di dati
molto grosse. Poi, certo, nel progettare un db destinato a contenere
milioni di record, non è ovviamente la mia prima scelta.

 milioni di record, non è ovviamente la mia prima scelta.
Access vuole dire poco o nulla, però :)
Tipicamente conta il backend. Intendi dire su file mdb o usando come
backend SQLServer? (nel secondo caso, bella forza :P).
Per il resto fino a che le relazioni sono abbastanza semplici e quasi
tutto è fatto principalmente in sola lettura, anche mdb se la cava. 



Io direi di partire da ACE: 
http://www.cs.wustl.edu/~schmidt/ACE.html
Soprattutto perche' e' in quell'ambito che e' nata l'infrastruttura
teorica cui generalmente si riferiscono tutto. *Il* libro e' POSA2:
http://www.cs.wustl.edu/~schmidt/POSA/POSA2/
Ciao,
Nicola

 Access vuole dire poco o nulla, però
Ovviamente si parlava del Jet Engine. Se devo usare un front end io uso 
SQL Server !! L'ho usato per nascondermi dalle problematiche di driver 
di Oracle, con mia grande gioia devo dire.


 libreria multithread portabile, allora sarà 'standard'.
Ni. Non e' un problema di *sintassi* del linguaggio, ma e' certamente
anche un problema di *semantica* del linguaggio, in soldoni garantire
di aver definito vincoli adeguati a supportare l'accesso concorrente
alla memoria, ovvero consentire l'implementazione corretta delle
primitive di sincronizzazione. I documenti scritti da chi si sta
occupando di definire il multithreading in C++0x sono decisamente
interessanti, anche se un po' ostici. Se siete interessati il posto
migliore per orientarsi e' questo: 
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2228.html
Ciao,
Nicola

>
ciao & danke
Soviet_Mario

 Ovviamente si parlava del Jet Engine. 
Avevo immaginato, ma si sa mica mai :)
Ripeto, sbaglio o era quasi tutto in lettura e con poca scrittura
concorrente?


 li abbia scritti ad hoc ! !
Veramente la seconda. Ma con TextMate si fa presto (semmai ero un po'
fuso e non sono certo che siano consistenti o chiari).


 
http://www.cs.wustl.edu/~schmidt/POSA/POSA2/
Di ACE c'è chi mi ha parlato molto bene e chi molto male. Tipicamente
sono però concordi sul fatto che non sia particolarmente facile da usare
:)
Per cui cercavo di consigliare qualcosa di più piccolino.
Il libro è nella mia wishlist da tempo, ma sfortunatamente non avrei
tempo di leggerlo in questi tempi. Mi sa che gli aumenterò la priorità.
:P (ultimamente mi sono piantato su Analysis Patterns di Fowler che pur
essendo interessantissimo è come dire... diciamo che mi stanco presto di
leggerlo).


 primitive di sincronizzazione.
Quello che voglio dire è che non è necessario modificare il
*linguaggio*. In teoria si può fare aggiungendo una libreria.
Di librerie multithread in C++ ce ne sono tante, e in generale
funzionano bene (io personalmente ho usato i thread di Qt e i posix
threads).
Se hai dei papers specifici, li leggerò volentieri (nel link che hai
postato fa un elenco immenso di roba, non saprei bene da dove cominciare
:) )


 Veramente la seconda. 
azz, la seconda che ho detto ....
Che dire, sei molto disponibile !
ciao
Soviet


 postato fa un elenco immenso di roba, non saprei bene da dove cominciare
Forse quello piu' in tema e' questo: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2138.html
Ciao,
Nicola

 concorrente?
Ovviamente non c'era nessuna scrittura concorrente. Access e accesso 
concorrente non vanno d'accordo. Lo usavo come immenso repository di 
log, con un poco di tabelle di configurazione di vari macchinari 
industriali.
L'altro mito da sfatare è che i vari windows sia instabili. Se non 
installi cagate, cosa normale in un impianto industriale, impossibile 
sui miei PC personali :-), tendono ad avere degli uptime invidiabili.


 personali :-), tendono ad avere degli uptime invidiabili.
Su questa invece sono perfettamente d'accordo.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 Non capisco questa affermazione che come l'hai detta è certamente falsa.
Tecnicamente forse, se vuoi farti del male anche. Il sistema di lock 
del Jet Engine è ridicolo, e avere più processi che scrivono sulla 
stessa tabella vuol dire andare a cercare guai. Di persone che si sono 
ritrovati con i file mdb corrotti ne ho conosciuti tanti. Almeno questa 
è la mia esperienza fino agli anni 2000, se le cose sono cambiate non 
lo so, ma ne dubito. Anche la necessità di dovere fare la 
compattazzione piuttosto spesso è un altro fattore abbastanza 
fastidioso.
Comunque quello di usare una engine embedded, come di fatto è il Jet 
Engine, per fargli fare il db server, come dall'altra parte usare un 
server db come SQL Server o Oracle per avere un "banale" archivio 
locale usato da una singola applicazione, sono cose che si vedono 
abbastanza spesso.
Ho visto intense riunioni progettuali che portavano ad architetture di 
cacca per avere trascurato dettagli simili. Masturbatorie discussioni 
sul pattern singleton per poi perdersi ad usare lo strumento sbagliato.


 Comunque quello di usare una engine embedded, come di fatto è il Jet Engine,
Embedded in che senso? Se intendi che è linkato all'applicazione che lo usa 
allora anche questo è palesemente falso.


 
E rino: il JET è proprio linkato all'applicazione che lo usa! Non in 
modo statico se è questo che intendi: tecnicamente si tratta di un 
server COM in-process che dietro tutte le sigle è una dll linkata 
dinamicamente al tuo processo.

 processo.
Sarà così ma l'applicazione comunica con il motore attraverso l'SQL e quindi 
continuo a non vedere la differenza.


 
SQL è solo una delle possibili interfaccie tra applicazione e engine. 
Sia JET che svariati DB server possono usare SQL come interfaccia.
La differenza è che nel caso si un DB server l'engine stà su un processo 
distinto dall'applicazione (il server) o addirittura su una macchina 
distinta. Se hai più applicazioni "client", il server rimane comunque 1 
solo.
Viceversa con JET il server non esiste ma il codice dell'engine gira nel 
processo del/dei client: se hai più client che accedono allo stesso mdb, 
hai più "copie" del codice JET in esecuzione nei vari processi client.
Comunque direi che ormai siamo parecchio OT...
Ciao
GM

 [...]
Perdonatemi, non sapevo cosa stavo facendo... ;-).
Non volevo causare una sotto discussione totalmente OT.
Saluti  Manlio Perillo

 più "copie" del codice JET in esecuzione nei vari processi client.
Ok, capito, grazie.


backend SQLServer? (nel secondo caso, bella forza :P).
E dai su, non facciamo i sofisticati :-) Lo sappiamo che Access č un
front-end usabile anche con SQL Server, ma cosa c'entra?
Si parlava di database utilizzato e per "Access" si intende ovviamente
il motore Jet.

concorrente?
Quale applicazione reale ha quasi tutto in lettura e poca scrittura
concorrente?



Un semplice CMS, ad esempio.
Saluti  Manlio Perillo

ritrovati con i file mdb corrotti ne ho conosciuti tanti.
Confermo la triste verità. La concorrenza con i db file-based (e non
DBMS transazionali con tanto di gestore della concorrenza) è un vero
inferno. Io ho sperimentato gli stessi problemi con Paradox, parimenti
file-based e parimenti suscettibile di corruzione degli indici come se
nulla fosse...

anche sul WEB 
Ahem... Jet? su WEB?... 

nella mia esperienza i guai sono quasi certi.
Confermo (purtroppo).

continuo a non vedere la differenza.
La differenza è che anziché pasticciare in N (i client) sui dati,
coordinandosi con dei lock robusti come la ricotta, ci pasticcia uno
solo (il server) in maniera controllata.

 Ahem... Jet? su WEB?...
Sì, o per lo meno la stringa di connessione che si usa da ASP è la stessa che 
si usa con ADO in locale. Ma probabilmente, come è stato già precisato, lì 
interviene il server WEB a sistemare le cose.


 Ahem... Jet? su WEB?...
Basta usare la programmazione asincrona, e ti eviti un sacco di problemi 
(non solo con Jet, ma in generale).
Saluti  Manlio Perillo

 Forse quello piu' in tema e' questo:
 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2138.html
Me lo leggo, grazie!


Basta usare la programmazione asincrona, e ti eviti un sacco di problemi 
Io intendevo dire che Jet non mi sembra il motore migliore per
applicazioni Web (ho sempre visto usare MySQL, per esempio).

 concorrente?
Log o stato interno. Una sola applicazione scrive il "suo" log, tutto 
il mondo vuole sapere cosa sta succedendo.


 Comunque direi che ormai siamo parecchio OT...
Comunque è uno dei thread più voluminosi degli ultimi tempi questo.
Una sintomo che forse è meglio aprire l'NG, tanto a chi non interessava 
avrà già fatto il suo "kill thread".


 concorrente?
Manlio ti ha fatto l'esempio di un CMS. 
 Ma in generale una qualunque applicazione in cui si consulti una banca
dati: tipicamente pochi (eventualmente uno solo) la modifica e gli altri
la consultano e basta.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 applicazioni Web (ho sempre visto usare MySQL, per esempio).
In ambiente Microsoft usare SQL Server non è male. Scala bene, ci sono 
ottimi strumenti di amministrazione per utonti giusto per partire, ma 
se sei bravo hai comunque in mano strumenti potenti per forzarlo alla 
tua volontà. Poi con l'ultima versione puoi creare stored procedure in 
qualsiasi lingaggio NET (quindi anche IronPython volendo), e in un 
certo senso hai adesso un'infinità di modi per farti male veramente*.
Per esempio le poche volte che ho usato Oracle ho bestemmiato per la 
mancaza di uno strumentino per utonti giusto per partire. Questo fino a 
che non ho trovato uno simptatico strumentino freeware di cui adesso 
non ricordo il nome.
*
Come test sul nuovo SQL Server mi sono fatto una funzione per fare 
delle ricerche nei campi testuali con le espressioni regolari. Giusto 
per fare delle SELECT con qualcosa di meglio di un LIKE. 
Incredibilmente ci vogliono 5 minuti di orologio per costruirsi questa 
estensione.
-- 
mai più senza: 
http://www.genux.com/scheda.asp?idprod=47974
la cultura è importante: 
http://www.libreriadellautomobile.it

 Su questa invece sono perfettamente d'accordo.
Circa.
Se stai sviluppando un applicazione custom per PC industriali, va tutto 
bene.
Se stai sviluppando software in bundle con uno strumento, che vada su PC 
industriali o su PC fuffa come quelli che ciascuno di noi usa per sviluppare 
poco cambia.
Anni fa m'e' capitato parecchie volte di ritrovarmi con errori dovuti ad 
update successive alla data di pubblicazione del setup che inibivano 
l'installazione di componenti obsolete rimosse dai nuovi setup (proprio 
riguardanti JET).
A semplificare le cose, il cliente riportava i messaggi d'errore nella 
lingua del suo sistema operativo: il cinese.
--*PaN!* 

 avrà già fatto il suo "kill thread".
Si, questo sub-thread e' completamente fuori argomento. D'altro canto
non sono particolarmente turbato da thread come questo, che partono in
tema e poi divagano, perche' chi li legge sa di cosa si parla e puo'
sempre decidere di smettere di seguirli. Il vero problema e' aprire il
newsgroup e trovare cinquanta messaggi di principianti MFC.
Ciao,
Nicola

 *linguaggio*. In teoria si può fare aggiungendo una libreria.
Pare che la libreria di cui parli non sia esprimibile in termini di C++ 
standard, e a riguardo c'e' stata una lunga ed estenuante discussione (che 
ho seguito da osservatore) su CLC++M qualche mese fa.
Se non erro, il tutto dipendeva dal fatto che nello standard non esiste 
nessuna clausola che vincoli la sequenzialita' di operazioni che non abbiano 
effetti l'una sull'altra (questo per permettere ottimizzazioni necessarie in 
molti altri ambiti).
--
Marco 

 molti altri ambiti).
Infatti. Il problema non e' tanto la disponibilita' di librerie per il
multi-threading su tutte le piattaforme, quanto il fatto che su
ciascuna piattaforma si appoggiano alle primitive e soprattutto alle
garanzie che trovano, cosa che puo' facilmente portare a sottili
differenze semantiche.
La difficolta' sta nel definire un insieme di garanzie universale che
pero' non stravolga quello che c'e' sulle piattaforme di uso comune (e
possibilmente anche su quelle piu' esoteriche), come base sulla quale
costruire un insieme di primitive standard e su quelle una libreria
piu' "user-friendly".
Ciao,
Nicola

 newsgroup e trovare cinquanta messaggi di principianti MFC.
Kill, kill, Kill. In più il consiglio vivo di postare sull'NG adatto.
Su it.comp.lang.python faccio "kill" su tutti i post su QT o WX e GTK.


 applicazioni Web (ho sempre visto usare MySQL, per esempio).
Sicuramente non lo č ma č l'unico gratuito che si trova spesso compreso negli 
spazi WEB e se il cliente vuole quello allora quello si usa. :-)
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 newsgroup e trovare cinquanta messaggi di principianti MFC.
Quoto.


 spazi WEB e se il cliente vuole quello allora quello si usa. :-)
Certo, ma ti confesso che sulla mia esperienza vedo che quasi tutti gli
spazi web gratuiti o giù di li danno semmai MySQL. Pure il mio (buon e
non troppo caro) hosting da MySQL [ ma lo ho scelto lo stesso perchè mi
davano pure Python e Ruby ].
Per quello che devo farci il costo aggiuntivo di Pg sarebbe stato
eccessivo. 


 spazi web gratuiti o giů di li danno semmai MySQL.
Gratuito? Cioč compreso nel prezzo base? Non mi č capitato. In ogni caso č un 
discorso sterile. Io cerco appunto di tenermi il piů possibile neutrale per 
poter cambiare motore all'occorrenza con il minimo sforzo possibile.


  Cioè compreso nel prezzo base? Non mi è capitato.
Se per gratuito intendi a costo 0, per esempio altervista ti da proprio
MySQL.
Se per gratuito intendi nel costo base, trovi queste soluzioni per
esempio da aruba. Ma ribadisco, praticamente tutti gli hosting
linux+apache+php offrono anche MySQL.
Lasciando stare che di PHP non me ne faccio nulla e tollero a mala pena
MySQL.


 esempio da aruba.
No, su Aruba si paga a parte, anche se poco.


 No, su Aruba si paga a parte, anche se poco.
Allora hanno cambiato. A me nel pacchetto base l'ultima volta che ho
sottoscritto con loro lo davano. 


[...]Pure il mio (buon e non troppo caro) hosting 
Quale (se posso)?

discorso sterile.
Hai provato 
eapps.com
 ?

 sottoscritto con loro lo davano.
Sei sicuro? Io li seguo da parecchi anni e con il pacchetto base non era mai 
compreso MySQL. Invece lo era sempre Jet/MDB. Ora addirittura (grazie a 
Windows 2003 server!) hanno tolto anche il supporto agli EXE CGI. :-(


[...]tollero a mala pena MySQL.
Hummm... sono poche le volte che ci si puň confrontare per bene su
Usenet, quindi ti chiedo (e senza alcun intento di polemica,
intendiamoci) il perché non lo tolleri cosě tanto.
Io uso MySQL (l'ho usato nelle versioni 3.x e 4.x ma era un
giocattolino a confronto del piů nuovo 5.x) tutti i giorni e mi
soddisfa abbastanza, anche se ammetto che a volte mi mancano le
caratteristiche di Oracle (che uso dal cliente).
Cos'č che non tolleri, nello specifico?

 Hai provato 
eapps.com
 ?
A parte il fatto che non sto cercando un provider per me ma sono i clienti che 
hanno già i loro spazi e io mi devo adeguare. Comunque i prezzi di 
eapps.com
 
sono ben più alti di quelli base di Aruba, non c'è paragone. E' ovvio che a 
quelle condizioni sia offerto anche MySQL e altri servizi aggiuntivi. Anzi, 
Aruba lo offre a molto meno.


sono ben più alti di quelli base di Aruba, non c'è paragone.
Ah non sapevo, non conosco Aruba. In particolare conosco eApps perché
consente di mettere in piedi delle applicazioni J2EE e ha un'ottima
console di gestione.

 Windows 2003 server!) hanno tolto anche il supporto agli EXE CGI. :-(
Ad ogni modo poco cambia. Alla fine sono comunque gli hosting più usati.


 console di gestione.
Io uso Site5. Ma in effetti per un cliente *non* suggerirei mai Aruba.
Sicuramente non gli hosting base. Come dicevo ne avevo uno, spesso era
giů, il supporto scadente.
Il mio nuovo provider (che costa circa 6 dollari al mese) mi da support
24/24 7/7, non lo ho ancora visto giů (se non per le manutenzioni, e mi
avvisano svariati giorni prima, e anche li sono solo poche ore).
Č tutta un'altra cosa. 


 Quale (se posso)?
Site5. Scelto perchč a 5.5 $ (adesso mi pare poco di piů) mi danno
Python, Ruby on Rails, Perl etc etc etc. Tra l'altro sono
'specializzati' in soluzioni su ROR, per cui il supporto č eccellente.
Inoltre hanno un'ottima console e parecchie features interessanti
(versioning sul sito, etc etc etc).


 Cos'è che non tolleri, nello specifico?
Il fatto che sono abituato (bene) con Postgres.
Inoltre posso dirti che MySQL non mi da fiducia. Alcune uscite degli
sviluppatori mi hanno fatto mettere le mani nei capelli. Inoltre per un
db server IMHO la cosa più importante è la correttezza e la stabilità.
Per cui non condivido come approccio quello di fare prima un prodotto
veloce e poi di pezzarlo.


sviluppatori mi hanno fatto mettere le mani nei capelli. 
Cioč? che hanno detto?

 Cioè? che hanno detto?
mi associo nella domanda
ciao

 Forse quello piu' in tema e' questo: 
http://www.open-std.org/jtc1/sc22/wg21/do
cs/papers/2006/n2138.html
TY. Preso.


 un prodotto veloce e poi di pezzarlo.
Questo è il punto centrale, riportato nel confronto complessivo tra MySQL e
PostgreSQL che ho scritto:
Confronto tra MySQL e PostgreSQL
http://www.teknico.net/devel/myvspg/index.it.html
-- 
Nicola Larosa - 
http://www.tekNico.net/
Sul lavoro per essere pagata e stimata quanto un uomo, una donna deve
essere intelligente ed efficiente almeno il doppio, ma per fortuna questo
non è difficile. -- Anonima, citata da Paolo Marchiori, Maggio 2006

 un prodotto veloce e poi di pezzarlo.
Ho anche scritto un confronto complessivo tra MySQL e PostgreSQL:
Confronto tra MySQL e PostgreSQL
http://www.teknico.net/devel/myvspg/index.it.html
-- 
Nicola Larosa - 
http://www.tekNico.net/
Sul lavoro per essere pagata e stimata quanto un uomo, una donna deve
essere intelligente ed efficiente almeno il doppio, ma per fortuna questo
non è difficile. -- Anonima, citata da Paolo Marchiori, Maggio 2006
-- 
Posted via a free Usenet account from 
http://www.teranews.com

 
http://groups.google.it/group/it.comp.lang.python/msg/2e012e61542f81eb
Grazie. Questo cercavo, ma non me lo trovavo.
O forse quello che avevo letto era un post simile di Valentino. Mi
pareva fosse su iclp e non su un blog, comunque.
Per cui ho omesso la risposta. :)
