Newsgroup: it.comp.os.dibattiti
Titolo: Memoria di un Programmatore

In fondo se la memoria sia segmentata o paginata non me ne importa un
fico secco. Cio che mi interessa veramente non sono i processori o i
S.O., ma le architetture software.
Quello che oggi offrono i sistemi CPU+S.O. non sono pensati da
programmatori. Per esempio la gestione della memoria dello stile o
tutto o niente.
I task hanno spazio di indirizzamento separato, mentre i thread no. I
programmatori hanno bisogno dei PaperoTask, no di quelle cose
obsolete. 
Un PaperoTask deve avere uno spazio di indirizzamento separato da
quello dei PaperoTask logicamente correlati, e uno comune a tutti per
le comunicazioni inter-Papero. Cosa diversa dalle comunicazioni
interprocesso. Io programmatore devo decide chi fa parte del pool di
PaperoTask, mentre nei Task chiunque potrebbe accedere ad un'area di
memoria coindivisa (in file mappato in memoria in NT, qualcosa di
simile suppongo in Unix).
Pero' i PaperoTask devo coindividere facilmente le variabili nel
*segmento* di memoria coidiviso. Cosi' come succede nei thread, dove
non mi metto a cipollare con gli indirizzi per sapere dove il
compilatore mettera' la variabile intera pippo, fondamentale nel mio
sistema.
E poi la gestione delle corse. Nei thread (in NT almeno) ci sono le
sezioni critiche, che pero' non ci sono tra task. Uno se la deve
smazzolare da solo con mutex vari, cosa cretina visto che il lavoro
noioso deve farlo il S.O. e non il programmatore.
Ogni PaperoTask deve potere indirizzare almeno 4Gb di roba, se ne ho
voglia. Cosa che posso fare nei task, ma non nei thread. E ogni
PaperoTask deve avere il suo stack, cosa non *esattamente* vera nei
thread.
Insomma, che sia segmenta o paginata infondo non mi interessa un gran
che. Mia opinione (e quindi Papera) e' che i S.O. di mia conoscenza
non permettono al programmatore di fare bene il suo lavoro. Il motivo
e' che non gli forniscono validi strumenti (i task e i thread).
++++
PaperoTask e non PaperoThread, perche' i task hanno quasi tutto cio'
che voglio. Manca una condivisione della memoria diversa da quella
possibile nei sistemi che conosco, qualcosa di ben piu' sofisticato
della eriditarieta' tra processi, e qualche oggetto kernel di
sincronizzazione di piu' agevole utilizzo. 
Peccato che NT sia piu' orientato ai Thread che ai Task. Pero' una
coda dei messaggi per ogni Thread e' una prova che anche altri
programmatori si sono poste le mie stesse domande. 
-- 
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

noioso deve farlo il S.O. e non il programmatore.
L'OS non puo` sapere quali sono le regioni critiche.
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

Davide Quack wrote:
[SNIP]
Bevuta troppa birra a cena? Hai passato la domenica sul computer e 
questo e' uno sfogo?
;)
ciao

 noioso deve farlo il S.O. e non il programmatore.
Forse vi sono problemi in cui il modo di risolvere le sezioni
critiche non e` banale o generalizzabile, tipo il problema
(classico) dei lettori-scrittori (o dei 5 filosofi...).
Nel caso dei lettori-scrittori la classica sezione critica
mutex puo` bastare, ma e` inefficiente, dato che piu` lettori
possono leggere "insieme", mentre gli scrittori devono si essere
in mutex, rispetto a se stessi ed ai lettori.
Inoltre potrebbero esservi dei problemi di priorita`...
Insomma mi pare che per fare le cose "bene" serva molto
piu` di un buon OS... :-)
bye,
-- 
  Piergiorgio Sartor

 piu` di un buon OS... :-)
ben detto... solo il programmatore puoi decidere come risolverli.
--
ciao, Mirco.
ICQ number   : 51640305
(get ICQ : 
http://www.mirabilis.com
)

L'OS non puo` sapere quali sono le regioni critiche.
Il S.O. deve rilasciarmi sezioni critiche interprocesso. In realta se
le funzioni asm di interlockinterchange (o quel che n.d.p.) sono
realmente atomiche potrei supplire alle mancanze del S.O.
Ho gia' tutto, e non lo sapevo :-(


piu` di un buon OS... :-)
Tutti queste problematiche sono gia' state risolte nei DB. Anzi i DB
hanno anche una coerenza tramite il transaction-commit-rollback che di
solito i programmatori non mettono nei loro programmi.
Alla fine l'architettura con la maggiore attrazione gravitazionale e'
il mega DB (leggevo a fagiolo le notizie di Informix 2000 e Oracle 9
su cluster *economici* Linux n.d.p.) con le tue belle applicazioni che
metto li i loro dati.
Ultimamente ho scoperto ODBC, e credo che non tocchero' piu' per un
bel pezzo mia altri modi di accedere ai DB. Sia chiaro ODBC ha
un'interfaccia penosa, ma le funzionalita' con un buon DB server sono
assolutamente incredibili (altro che pinzallecchere di Oracle con le
stored procedure in Java richiamabili da codice C n.d.p.)
Insomma, serve ben piu' di un buon OS, serve un buon DB.


 stored procedure in Java richiamabili da codice C n.d.p.)
?
Saluti.

stored procedure in Java richiamabili da codice C n.d.p.)
Ma sei il papero, o una sua mutazione troll? :-)
O non hai mai lavorato con i DBMS?
Ciao,
 P.
+++ Boing Boom Tschak

>?
??


O non hai mai lavorato con i DBMS?
Tu ci hai mai lavorato?
Credi che io dovrei considerare Oracle un buon DB per le emerite
c**ate che dicono i commerciali Oracle? Tu segui le mode? Io seguo il
mio sentire perche' preferisco sbagliare di testa mia.
Credi che una Stored Procedure sia piu' Stored Procedure se scritta in
Java? E su questo ho discusso lungamente con la mia amica (davanti ad
una pizza, e altri amici che parlavano del grande frittella).
Java nei DB e' un'emerita cazzata, e sarebbe ora che qualcuno lo
dicesse. I DB relazionali sono cosa profondamente diversa dai DB ad
oggetti. Nei DB relazionali un ottimo linguaggio per scrivere Stored
Procedure potrebbe essere il Lisp, non certo un qualsiasi linguaggio
OO.
Diro' di piu', l'utilizzo dei cursori che puo' fare con una cosa cosi'
obsoleta come il C, ODBC e un buon debugger non sono nemmeno pensabili
con oggetti grezzi come le Stored Procedure o i cursori alla VB.
Venendo dal VB e dalle SP ho dovuto ammettere la mia ignoranza, e
imparare a rispettare il lavoro degli anziani (anche se come
interfaccia ODBC e' pessima).


con oggetti grezzi come le Stored Procedure o i cursori alla VB.
Non ci ho capito una fava. Volevo solo dire che per applicazioni
gestionali mi sembra molto strano non usare le transazioni, se c'e'
chi lo fa suppongo che avra' valutato i rischi a cui va incontro. Se
ci sono dei DB senza supporto per le transazioni (MySQL, se non erro)
vuol dire che non vanno bene per applicazioni transazionali (2+2..)
Per quanto riguarda Java e le stored procedure non ci vedo nulla di
male, e' un buon linguaggio di programmazione usato spesso a mo' di
prezzemolo, se ci sono dei motivi per cui credi non sia adatto nelle
stored procedure per favore spiegaceli piu' chiaramente.


 ??
E' che non capisco quel che stai dicendo.
Saluti.

 Insomma, serve ben piu' di un buon OS, serve un buon DB.
...anche se il boom di internet ha spinto tantissimo
questo tipo di applicativi.
bye,
-- 
  Piergiorgio Sartor

imparare a rispettare il lavoro degli anziani 
In realta', gli anziani stanno ben alla larga da ciofeche come ODBC...
Obelix e anche JDBC, ovviamente...
 

Al mondo non esisto solo i DB...
Come semantica e come filosofia sono un esempio interessantissimo.
Viene gestita la concorrenza, l'integrita' referenziale e il sistema
rimane sempre in uno stato coerente (cosa piu' forte di uno stato
*solido*).
Non importa che tu usi o no i DB. Non conoscere i DB penalizza il modo
di pensare di un Papero.


male, 
Peggio per te.
Se non capisci che un recordset non ha *niente* a che fare con le
istanze degli oggetti dei comuni linguaggi OO, io non posso farci
niente.
Considera un record come un oggetto, e non capirai mai la *verita'*.
Pensa ad un record come a una linea in uno spazio multidimensionale e
tutto acquistera' una sua coerenza. Un Olap Server e' semplicemente un
oggetto che lavora su superfici o volumi.
Il linguaggio per DB deve catturare questa essenza. Deve con una
semantica semplice e chiara permettermi di gestire con estrema
facilita' linee e vettori multidimensionali.
Il che si traduce nella gestione di tabelle e cursori a run-time, ma
questo e' un dettaglio implementativo.
dim a, c as vector(string, int, int)
dim b as point(string, int, int)
set a = select Nome, Eta, CirconferenzaPanza from guru_table
set c = (Papero, NULL, NULL)
b = a intersection c
   set b.coordinata2 -= 10
E mi sono tolto 10 anni in modo semplice con tre righe di codice
semplici da capire anche per un paperotto piccolo piccolo.
Semplici, ma non semplicistiche.
P.S.
In una semantica ad oggetti un vector e' un contenitore di point.
Stop. Un vector vuoto non possiede punti.
Nella visione algebrica paperizzata un point e' anche un vector
degenere, e allo stesso tempo un vector e' un insieme di point.
Un vector vuoto non e' un vector, non e' nulla.
++++
Un DB come oggetto e' qualcosa di discutibile.
Come algebra pura diventa pure affascinante.


E' che non capisco quel che stai dicendo.
Qualcosa in particolare?
Se non specifichi ...


 Se non specifichi ...
Forse non ha capito nulla (come me).

 Se non specifichi ...
Le stored procedure devono poter essere scritte con qualsiasi linguaggio
supportato
dall'OS. Stando a quando dice Peter Spiro l'intenzione di Microsoft (che nel
caso di SQLServer
coincide con la sua....) è quella di consentire l'uso di stored procedure
scritte in qualsiasi linguaggio
supportato da COM/DCOM, dal Common Language Runtime ed anche con SP invocate
via SOAP.
Saluti.
PS. IBM sul suo DB2/400 già consente la scrittura di SP con qualsiasi
linguaggio ILE. Ma OS/400
è nato con il concetto del Common Language Runtime. Quelli di IBM saranno
folli (OS/2 ed AIX ad esempio)
ma sulle cose serie sono imbattibili.
Saluti.

 ma sulle cose serie sono imbattibili.
Curiosità mia... OS/2 l'hanno suicidato ma AIX cos'ha che non va
Pila... che sta ancora sbavando come un cane al ricordo dell' RS/6000 a
24 processori a forma di doppio monolite di 2001 Odissea nello spazio
(Ci starebbe da Dio nel mio salotto)....

 niente.
Conosco la differenza tra db relazionali e OO, grazie.
Mi sembra quasi che tu abbia tirato fuori la questione
dell'object-relational mismatch. Ma qui c'e' un equivoco, si parlava di
stored procedure, tu hai detto che Java per le stored procedure in un db
relazionale e' una cazzata. Ora io voglio solo capire perche'.
Java e' OO e ci scrivi tutte le procedure che ti pare, puoi scriverle
costruendo un'elegante gerarchia di classi, oppure "abbassarti" al
livello di un linguaggio puramente procedurale, ma tutto cio' non ha
importanza, la stored procedure deve eseguire un compito, che c'entra
con la natura del linguaggio se questo puo' effettivamente svolgere quel
compito?
Allora per favore dimmi che male c'e' a farlo in Java piuttosto che in
un qualsiasi altro linguaggio procedurale oppure OO. Non ne vale la pena
(cioe' basta una cosa molto piu' semplice di Java)? Inefficente?
Instabile? Problemi con la VM?
Puo' darsi, ma io ci vedo anche dei vantaggi, legati semplicemente al
fatto che Java e' un buon linguaggio. Per esempio nella gestione delle
eccezioni.
Tutto qua. Ah, credo che anche DB2 di IBM supporti le stored procedure
in Java. Tutti li' a far cazzate?

 di pensare di un Papero.
Mi par giusto, anzi doveroso! :-)
Comunque una nota: nei concetti della programmazione ad oggeti
esistono i cosiddetti "pattern", che rappresentano soluzioni
a problemi quali la mutua esclusione, lettori-scrittori, factory,
etc., etc., etc.
E` quindi chiaro come queste cose NON debbano essere supportate
dall'OS, se non con elementi base (mattoncini LEGO), ma siano
gia` implementate in qualche libreria sparsa per l'universo internet.
bye,
-- 
  Piergiorgio Sartor

Curiosità mia... OS/2 l'hanno suicidato ma AIX cos'ha che non va
Che lo "suicideranno" per far spazio a Linux.
Saluti.

Che lo "suicideranno" per far spazio a Linux.
Che idiozia. Almeno per un po' di anni IBM non ha nessuna intenzione
di fare una cosa simile.


 di fare una cosa simile.
Non conosci  i tizi del marketing IBM. Quelli sono capaci di tutto.
Saluti.

Non conosci  i tizi del marketing IBM. Quelli sono capaci di tutto.
Pero` vedo cosa fanno i loro sviluppatori, e vedo cosa fanno quelli di
SGI.


in Java. Tutti li' a far cazzate?
E allora? Perche' una cosa e' sponsorizzata da IBM diventa
automaticamente buona? Novell ha inserito una Java Machine nel Kernel.
Questo impedira' magicamente a Novell di perdere quote di mercato?
In questo senso la cosa migliore l'ha fatta la Microsoft che non ha
inseguito la moda di Java come panacea dei mali del mondo, e in SQL
Server 2000 pare inserira' la variabile di tipo table.
Il team di sviluppo di SQL Server, per mia gioa, e' molto
tradizionalista.


esistono i cosiddetti "pattern",
I Pattern sono sempre esistiti. Un tempo si chiama "buon senso", in
altri tempi "proverbi e/o leggende", e in altri ancora "vox populi".
In tempi recenti si chiamava "esperienza".
L'OO si e' appropriata di qualcosa di non suo.
++++
Poi un giorno qualcuno ha fatto una cattedrale a Madrid che andava
contro il "buon senso" ma che stava in piedi lo stesso. Giusto per
dire che i pattern non sono scienza esatta.


supportato dall'OS. 
Un conto sono le esigenze commerciali. Un conto sono le esigenze di
chi con i DB ci lavora sul serio. A parte forse SQL Server 2000 che
potrebbe arrivare alla decenza, e Oracle 9i che non conosco, quel che
ho visto come linguaggi per SP, era semplicemente inadatto.


In realta', gli anziani stanno ben alla larga da ciofeche come ODBC...
Tu hai alternative. Io no. Trovami un altro modo di parlare con mySQL
da NT.


Server 2000 pare inserira' la variabile di tipo table.
MS non ha inseguito Java solo perche' si e' inciampata cercando di
farlo. Ora si e' rialzata e riprende la corsa, quindi aspettati pure
stored procedure in C# prima o poi.


ho visto come linguaggi per SP, era semplicemente inadatto.
Tks. Dovresti cercare di guardare verso i DB seri...
Obelix

da NT.
No, io non ho alternative. Io ho un DB solo. Solo che chi lo ha fatto
*sapeva come farlo*. punto.
Obelix

 tradizionalista.
Spiro sembra il generale confederato con quel barbone alla Lee.....
Saluti.

automaticamente buona?
Hem, no, e' il contrario:per definizione, e' buona ogni cosa di IBM
che IBM affossa...
Obelix

Che lo "suicideranno" per far spazio a Linux.
Neanche se viene qui Dio Padre Onnipotente a controfirmarmelo
col sangue.
Leonardo scettico blu
Microsoft Outlook: R: Re: R: Re: R: Re: R: cosa vuoi replicare oggi?

da NT.
Non c'e' un kit di sviluppo? Qualcosa del tipo
	rsResult = new MySQLQuery(SQLID_conn, szQuery);
	printf("<TABLE>");
	while(rsResult->notEmpty)
	{
		printf("<TR><TD>%s</TD></TR>%s", rsResult->szaField[2],
 				HTMLCRLF);
	}
	printf("</TABLE>\n";
Leonardo


 wrote in message
news:3a03b8d2...@news.seven.it...

Cioe', intendi che quelle che invece vendono bene sono solo le
cagate...???...
--
Bye
Gianluca Zanelotto
Ducati ST2 "Red Devil"

 cagate...???...
Oh... Credevo che in base ad anni di onorato servizio presso la MS te ne
fossi reso conto, ormai...
Saluti,
Fabio Alemagna

col sangue.
In IBM girano voci di un AIX per IA64 per la meta' del prossimo anno.
Altre voci dicono che il suddetto AIX dovrebbe essere free.
Ciao
Francesco

cagate...???...
Si, infatti sono forti sui prodotti per NT... 
Obelix

 wrote in message
news:3a049aa9...@news.seven.it...

Obelix, fatene una ragione, OS/2 era una cagata pazzesca.
Saluti.

 col sangue.
Uno che ci lavorava e che č stato spostato ad altro incarico (Linux)
assieme al 50% personale AIX basta?
Saluti.

assieme al 50% personale AIX basta?
Non mi sembra chiamarlo "suicidio". A meno che vogliano aixare Linux
(contro chi, poi).
Leonardo


 (contro chi, poi).
Contro chi non lo so.
Sarà OT però oggi mi sono divertito tanto ma tanto quando
IBM Italia insieme ai capoccioni di Rochester ha dovuto capitolare
ammettere l'esistenza di un baco di OS/400 V4R5 grosso come una casa che ha
messo in chiaro una cosa sconvolgente: il test di OS/400 V4R5 è stato fatto
su installazioni con massimo di 50 utenti concorrenti. Il tutto per la gioia
di chi ha speso miliardi per il loro ferro e per il loro software.
Spero che usino lo stesso criterio per lo sviluppo di Linux.
Saluti.

Obelix, fatene una ragione, OS/2 era una cagata pazzesca.
Sai, ho appena avuto un video di un Texas Rodeo fra NTe Os2...
indivina chi ha perso?? Te ne mandero' una copia in JPG...
Obelix

 Obelix, fatene una ragione, OS/2 era una cagata pazzesca.
sara`... ma almeno quello adesso funziona e anche bene... e`
xcaso invidia la tua?
--
ciao, Mirco.
ICQ number   : 51640305
(get ICQ : 
http://www.mirabilis.com
)

Tks. Dovresti cercare di guardare verso i DB seri...
Con il budget aziendale a mia disposizione e' probabile/possibile che
mi scriva nel mio tempo libero un debugger per windows. Figurati tu
che possibilita' ho di confrontarmi con DB seri.


Spiro sembra il generale confederato con quel barbone alla Lee.....
Non so chi sia costui. Io conosco solo Soukup Delaney per il suo
(ottimo) "Inside SQL Server 7". Il fatto che nel libro si dica
espressamente che il team si sia posto il problema di una estensione
ad oggetti del DB, e che si sia preferito lasciare perdere mi ha fatto
un ottima impressione. 


stored procedure in C# prima o poi.
La portata delle visioni *logiche* del C# e' *giusta*, ma cio' non
toglie che per me ha ottime probabilita' si essere un fiasco. Chi
dovrebbe cannibalizzare? Non puo' competere con la potenza espressiva
del C++, con la storia del C, con le tradizioni del VB (bistrattato a
torto), con le infinite librerie matematiche del Fortran, con il
codice passato del Cobol, e con la (finta) indipendenza di Java.
Chi dovrebbe usare C#?
Chi ha bisogno del C#?
E' come rendere NT un S.O. console based. 
Una follia filosofica.
++++
Cio' non toglie che la standardizzazione da parte della UE del C# e'
qualcosa che apprezzo molto.


Chi dovrebbe usare C#?
Nessuno, ovviamente. E' solo VaporWare per diminuire la penetrazione
di java...
Obelix

Bel sistemone, proprio da enterprise....
Ma tu credi proprio a Del Giovane?? 
Obelix

che possibilita' ho di confrontarmi con DB seri.
Parecchie. Ci sono un *sacco* di richieste di programmatori che
operino in ambito 'serio'...
Obelix

SQL
Anche PostgreSQL :-(
Infatti mi sto scrivendo un convertitorino pSQL -> MySQL allo scopo.


 di chi ha speso miliardi per il loro ferro e per il loro software.
Bel sistemone, proprio da enterprise....


Non c'e' un kit di sviluppo?
Ho scoperto che il dump di mySQL e' semplicemente una serie di create
table e insert row. Idea geniale (tralasciando che mancano le chiavi
referenziali).
Naturalmente lo standard SQL del dump mi sembra molto mySQL e poco
SQL, quindi bisogna lavorare di notepad.


 Ma tu credi proprio a Del Giovane??
Ho avuto la sventura di possedere anch'io un V3R2 per un annetto.....


SQL, quindi bisogna lavorare di notepad.
Anche i dump di Oracle sono come MySQL...
Solo M$ SQL server non ho mai visto una utility ufficiale (M$) che faccia un
dump in ascii...
-- 
Sidewinder  
---------------------------------------------------------------------
/*
 *     Please skip to the bottom of this file if you ate lunch recently
 *                             -- Alan
 */
	-- from Linux kernel pre-2.1.91-1
---------------------------------------------------------------------

Ho avuto la sventura di possedere anch'io un V3R2 per un annetto.....
????
Obelix

operino in ambito 'serio'...
Sono gia' depresso adesso a dovere perdere tempo con realta' italiane
quotate in borsa che usano mySQL perche' i DB decenti puzzano.
Dovere programmare in RPG potrebbe portarmi a fare azioni insane.
++++
I vantaggi di essere un Papero anonimo sono anche che posso parlare
male dei clienti aziendali senza che questi chiedano (e ottengano
n.d.p.) la mia testa ai miei boss.


Dovere programmare in RPG potrebbe portarmi a fare azioni insane.
Ad esempio, potresti scoprire che ti piace...
Obelix

Infatti mi sto scrivendo un convertitorino pSQL -> MySQL allo scopo.
Se i due DB hanno dei driver ODBC limitati a fare un bridge.
Tra l'altro avrebbe il vantaggio di funzionare anche con Oracle, DB,
SQL Server, Informix, e qualsiasi cosa accetti una connessione con un
driver ODBC (cioe' anche Excel e cose similari n.d.p.)
++++
MySQL ce l'ha, e mi sembra strano che pSQL non l'abbia. Se ti sa
fatica lavorare potresti addirittura usare Access come front end su
una macchina remota, e fare il programma a colpi di clic.


dump in ascii...
Onestamente non ho mai provato ad aprire con notepad un backup di SQL
Server. Davo per scontato che fosse binario. Ci provero' comunque.


Se i due DB hanno dei driver ODBC limitati a fare un bridge.
Ce l'avrebbero, ma la conversione e' tutto sommato banale.
pg_dump [opzioni] | psql2mysql | mysql test &
e la cosa va.


Ad esempio, potresti scoprire che ti piace...
E' piu' probabile che mi porti a cambiare mestiere.
Cosa che di per se non sarebbe necessariamente un male.


E' piu' probabile che mi porti a cambiare mestiere.
E' buffo sentire cose del genere riguardo a uqalcosa che non hai mai
fatto.... ascarso spirito di avventura, eh??
Obelix

fatto.... ascarso spirito di avventura, eh??
Ho visto anche un poco di RPG e COBOL nella mia vita.
E non e' stata una esperienza cosi' esaltante.


E non e' stata una esperienza cosi' esaltante.
E' perche' non l'hai fatta col team giusto...
Obelix

E' perche' non l'hai fatta col team giusto...
Su quello hai molto ragione.
Ma che sia il Cobol che attira i deficienti? Ccon rispetto parlando
per te n.d.p.)
Battuta a parte il nuovo ASP+ della Microsoft supportera' il Cobol
come linguaggio di script. Presumo che glelo abbiano chiesto in tanti.
