Newsgroup: it.hobby.lotto
Titolo: Per i programmatori

Ciao, come siamo a millenium bug, con i vostri programmini ?
Ho sentito dire che per i programmi scritti in C, ci siano dei problemi
anche con altre date..........dato che io sto ancora utilizzando ( il mai
abbastanza osannato ) Lottovelox per dos ( scritto in c cosi' dice il
librettino).....come si comportera' ?
Gbc.....appena riesco a capire cosa devo scaricare per il tuo prg
NMlotto......lo scarico.
claudio
http://www.enjoy.it/users/~claudio/

Un bel di' Claudio Veneziani scrisse:
CV> Ciao, come siamo a millenium bug, con i vostri programmini ?
CV> 
senza offesa, ma cosa sai del Millenium Bug??
Io dico niente!!
Si dice, comunque (diavolerie), che molti programmi avranno il prob.
dell'anno 2000 in quanto considerano solo le ultime 2 cifre della data,
ma come puo' un prog. del lotto fare questo, visto che tratta (di solito)
estrazioni dal 1871!?!?!?
E poi perche' i programmi in C!?!? Il C e' piu' fesso!?!? :-))
ah ah!
-- 
"Il potere logora chi non ce l'ha", teorema di Andreotti sugli Equilibri
Politici
-- 
Emanuele Cesena
ami...@iol.it
 :)	Occhio all'antispammer NOSPAZ!!
http://www.geocities.com/SiliconValley/Grid/8879

estrazioni dal 1871!?!?!?
vabbe'.......ma mica sono un programmatore io, tu lo sei ?
Mi ripeto, c'entra qualcosa il problema del millenium bug ?
E mi ripeto anche qui........ho letto ( se non bastera' telefonero al
giornale che ha sparato la notizia e mi faro' passare l'addetto) che i
programmi in C avranno problemi anche in altre date......dato che io di prg
non so nulla e men che meno di problemi di quel genere, chiedo se c'e'
qualcuno che ne sa piu' di me.....se ce e vuole conferire bene, altrimenti
bene lo stesso.
Si puo' pretendere forse che tutti si sia prodighi nel divulgare il proprio
sapere ?
claudio
http://www.enjoy.it/users/~claudio/


sapere ?
i problemi che si possono incontrare, possono essere causati o dagli
applicativi (programmi) o dai sistemi operativi e/o dai Bios dei pc.
In genere il bug dell'anno 2000 viene causato principalmente dagli
applicativi che utilizzano 2 cifre per l'anno, ma come diceva Emma in
genere i programmi del lotto (almeno i più decenti), dovendo già gestire
anche date precedenti al 1900, essi già utilizzano la data a 4 cifre.
Altre date che potrebbero creare problemi sono verso il 2038 per alcuni
sistemi Unix; 2040 per sistemi Macintosh, 2042 per gli IBM 370,il 2044
per MS-Dos e altre date successive... spero proprio che quando si
arriverà a quelle date, tutto il software odierno sia già stato
completamente rimpiazzato!
Per quanto riguarda il Lottovelox II per Dos, non ha nessun problema per
il bug dell'anno 2000, però essendo un software uscito fuori produzione,
nel caso vengano fatte modifiche al gioco del lotto, per tale versione
non si prevederanno Patch. :-(
Mi fa piacere che ci sono ancora persone che lo utilizzano con
soddisfazione, ma man mano le richieste dei clienti sono cresciute e ho
dato come risposta il "Lottovelox II Pro" che potendo sfruttare i 32 Bit
ha molta più potenza!
Accenno solo ad alcune cose (scusate la pubblicità):
- Poter condividere gli archivi (estrazioni, sistemi,...) in rete locale
(LAN)
- Poter sviluppare sistemi fino a 90 numeri e fino alle decine
- Sistemi Integrali, Condizionati, Ridotti N-x, Ortogonali, Ortogonali
asimmetrici (misti) ...
- Molti tipi di statistiche
- Dinamica: permette di vedere in una griglia grafica, la situazione di
una combinazione in ogni estrazione esaminata
- Multigiocate
- Aggiornamento estrazioni tramite files scaricati da Internet
- Interfaccia grafica personalizzabile
- ecc.
Come al solito, dico che resto a disposizione di chi ha dei suggerimenti
da fare, nel limite del possibile li cercherò di aggiungere nella Patch
successiva.
Ciao
P.S. con questo mio messaggio, voglio porgere una mano verso Claudio
Veneziani in modo da cancellare le polemiche precedenti, spero che da
qui in poi il clima delle discussioni sia molto pacato e amichevole.
--
Alessandro Pulvirenti
ale...@cedss.it



E poi perche' i programmi in C!?!? Il C e' piu' fesso!?!? :-))
Il problema del C esiste veramente, perchè il valore conservato in time_t
sarà troppo grande per essere conservato nell'apposita variabile (Questo
perchè la funzione calcola il tempo a partire, mi sembra, dal 1970). Il
problema si avrà dopo le ore 3:14:07 del 19/01/2038.
Le funzioni da che usano time_t sono:
char ctime(const time_t  *time);
double difftime(time_t time2, time_t time1);
struct tm * gmtime(const time_t  *timer);
struct tm * localtime(const time_t  *timer);
time_t time(time_t  *timer);
time_t mktime(struct tm  *timeptr);
int    stime(time_t  *tp);
Ciao, Alessandro
-----------------------------------------
Revel Team
http://come.to/RevelTeam
-----------------------------------------

 wrote in message
7d1lov$8co$1...@fe1.cs.interbusiness.it...


qui in poi il clima delle discussioni sia molto pacato e amichevole.
esiste un news dove si dovrebbe parlare di lotto, vediamo di utilizzarlo.
claudio
http://www.enjoy.it/users/~claudio/

problema si avrà dopo le ore 3:14:07 del 19/01/2038.
questa e' una risposta...........grazie,
il resto per me e' troppo :-))
claudio
http://www.enjoy.it/users/~claudio/

Io invece per quelle date spero proprio di esserci :))))


altro banco) !!!:-))))))))))
certo! lui copiava sempre! e quella si è stancata di fare i compiti
anche per lui! :-))
Ciao
--
Alessandro Pulvirenti
ale...@cedss.it

Ciao,


Un bel di' Revel scrisse:
R> Il problema del C esiste veramente, perchè il valore conservato in time_t
R> sarà troppo grande per essere conservato nell'apposita variabile (Questo
R> perchè la funzione calcola il tempo a partire, mi sembra, dal 1970). Il
R> problema si avrà dopo le ore 3:14:07 del 19/01/2038.
R> 
premesso che, molto probabilmente, a quel tempo time_t non sara' piu'
di 32 bit o quanto e', ma di 128 minimo (e basterebbe quindi una ricompilazione),
grazie per la new!! Non usero' il time_t nel mio emamail :-)
Ciao ciao!
-- 
"Per quanto nascosta sia una pecca, la natura riuscira' sempre a trovarla.",
principio di Benedict (corollario 9 alla legge di Murphy)


>Io dico niente!!
CV> 
CV> non mi offendo mica.......e' per questo che lo chiedo, altrimenti me ne
CV> stavo zitto.
CV> 
ok, bene. 
CV> vabbe'.......ma mica sono un programmatore io, tu lo sei ?
dipende :-)
CV> Mi ripeto, c'entra qualcosa il problema del millenium bug ?
secondo me il millenium bug e' una bella pubblicita' messa in giro
da qualche baldo cretino (opinione personale) :-)
ciao ciao!
-- 
"In un'organizzazione gerarchica, piu' alto e' il livello, maggiore e' la
confusione", legge di Dow


da qualche baldo cretino (opinione personale) :-)
e invece NO!
per esempio, io nei primi anni '90 feci alcuni programmi che volevano la
data nel formato corto (gg/mm/aa), me lo richiedevano i clienti, dato
che l'usanza era quella e mi dovevo adeguare!
sfortunatamente quelli programmi si sono rivelati molto longevi... nel
senso che li continuano ad utilizzare, io li ho avvertiti che nel 2000
quei programmi non funzioneranno più (ho fatto delle prove).
Sfortunatamente non hanno programmi con cui rimpiazzarli e io sono molto
occupato :-((
Ciao
--
Alessandro Pulvirenti 
ale...@cedss.it
sito Lottovelox: 
http://www.cedss.it/lottovelox/
(chi non sa ridere... non è una persona seria! :-)
        _    _____
       /__/      __||)
=|:-)><>     |___
      \      \_____||)
       *

grazie per la new!! Non usero' il time_t nel mio emamail :-)
il problema non ha molta importanza quando il valore viene calcolato in
memoria, dato che basta reindirizzare la funzione ed č tutto fatto!
Il problema č complesso, quando invece si parla di date conservate negli
archivi su disco, lě č molto piů difficile utilizzare un valore piů
grande (in Bytes) dato che lo spazio dedicato a ogni campo (variabile) č
fisso!  e per cambiarlo, si dovrebbe esportare tutto l'archivio in un
formato che prevede maggiori Bytes per le date!
Ciao
--
Alessandro Pulvirenti 
ale...@cedss.it
sito Lottovelox: 
http://www.cedss.it/lottovelox/
(chi non sa ridere... non č una persona seria! :-)


>>>>> "Ema" == Ema da TIN <su...@NOSPAMgeocities.com> writes:
Ema> secondo me il millenium bug e' una bella pubblicita' messa in
Ema> giro da qualche baldo cretino (opinione personale) :-)
Ema> 
Ema> ciao ciao!  -- "In un'organizzazione gerarchica, piu' alto e' il
Ema> livello, maggiore e' la confusione", legge di Dow -- Emanuele
Ema> Cesena 
ami...@iol.it
 :) Occhio all'antispammer NOSPAZ!!
Ema> 
purtoppo il millenium bug è un problema molto serio.   Ci sono in giro
una  montagna   di  macchine   che   sono state  progettate  anni  fa,
risparmiando sui numeri, che  quindi memorizzano gli  anni solo con le
ultime 2 cifre.
Non  solo programmi  per  Personal  Computer, ma  anche programmi  per
grandi   mainframe, per  i  sistemi  bancari, delle assicurazioni,  in
apparecchiature elettroniche  di vario tipo (comprese le biomedicali),
nei programmi di controllo delle centrali di ogni tipo.
Programmi scritti  anche  decenni  fa,  lunghissimi, in   chissà quali
linguaggi, avendo lasciato chissà dove i listati.  Come si fa a sapere
se e in  che punto uno  di questi apparati ha  un simile problema?  si
apre e   si guarda dentro, ma   hai  voglia a  esaminare  tutto questa
roba...:-(  Magari apparecchiature di cui   non esistono nemmeno più i
manuali, per le  quali i progettisti/programmatori sono pensionati  da
un pezzo...
Per fortuna già da tempo si sta lavorando per controllare e correggere
il problema nei limiti del possibile, ma quello che succederà la notte
del 31 dicembre 1999 nessuno lo può sapere.
Non ci resta che aspettare....:-)
Ciao
Marco
-- 
"Il senno di poi e' una scienza esatta"

Un bel di' Alessandro Pulvirenti scrisse:
AP> e invece NO!
AP> per esempio, io nei primi anni '90 feci alcuni programmi che volevano la
AP> data nel formato corto (gg/mm/aa), me lo richiedevano i clienti, dato
AP> che l'usanza era quella e mi dovevo adeguare!
AP> 
Fessi loro, ed un po' pure tu :-))
Suvvia, lo sa anche mamma M$ che la visualizzazione e' ben diversa dal
salvataggio dei dati... :)
La data la salvi nel formato che vuoi, quindi con gli anni magari a 16 bit,
e poi la visualizzi come ciascuno preferisce! :-)
AP> sfortunatamente quelli programmi si sono rivelati molto longevi... nel
AP> senso che li continuano ad utilizzare, io li ho avvertiti che nel 2000
AP> quei programmi non funzioneranno più (ho fatto delle prove).
AP> 
si arrangeranno!
AP> Sfortunatamente non hanno programmi con cui rimpiazzarli e io sono molto
AP> occupato :-((
AP> 
a pagamento, se vuoi, glieli rifaccio io (se sono in grado) :-))
bye!
-- 
"In a world without walls and fences, who needs Windows and Gates?"
-- 
Emanuele Cesena
ami...@iol.it
 :)	Occhio all'antispammer NOSPAZ!!
http://www.geocities.com/SiliconValley/Grid/8879

Un bel di' Alessandro Pulvirenti scrisse:
AP> Il problema č complesso, quando invece si parla di date conservate negli
AP> archivi su disco, lě č molto piů difficile utilizzare un valore piů
AP> grande (in Bytes) dato che lo spazio dedicato a ogni campo (variabile) č
AP> fisso!  e per cambiarlo, si dovrebbe esportare tutto l'archivio in un
AP> formato che prevede maggiori Bytes per le date!
AP> 
certo! Vabbe'... poca roba... non lo vedo quel gran problema... il
piu' e' avere i sorgenti dei programmi... se non li hai, hai voglia!! :-))
Ciao ciao!
-- 
"1. Cerca di sembrare terribilmente importante", dal decalogo di Spark per
il giovane manager


Un bel di' "Marco Pozzato" scrisse:
MP> Non  solo programmi  per  Personal  Computer, ma  anche programmi  per
MP> grandi   mainframe, per  i  sistemi  bancari, delle assicurazioni,  in
MP> apparecchiature elettroniche  di vario tipo (comprese le biomedicali),
MP> nei programmi di controllo delle centrali di ogni tipo.
MP> 
complimenti non solo a chi li ha programmati, ma anche ai fessi che li
hanno acquistati!
Suvvia... sono affaracci loro, dovevano pensarci per tempo! :-)
Nei miei programmi la data arriva fino al 65535 d.C, oppure fino al
32676 se ho bisogno degli anni avanti Cristo... e non cred che 16
bit siano uno spreco... :-)
MP> Non ci resta che aspettare....:-)
MP> 
io aspetto, privo di preoccupazioni :-)
Bye!
-- 
"Col tempo, ogni posizione tende ad essere occupata da un membro che e'
incompetente a svolgere quel lavoro", corollario di Peter


>>>>> "Ema" == Ema da TIN <su...@NOSPAMgeocities.com> writes:
Ema> complimenti non solo a chi li ha programmati, ma anche ai fessi
Ema> che li hanno acquistati!  Suvvia... sono affaracci loro, dovevano
Ema> pensarci per tempo! :-) Nei miei programmi la data arriva fino al
Ema> 65535 d.C, oppure fino al 32676 se ho bisogno degli anni avanti
Ema> Cristo... e non cred che 16 bit siano uno spreco... :-)
C.V.D.
Il senno di poi è una scienza esatta.
proprio così.
Tu, hai imparato  sui loro sbagli,  è facile criticare.  Ma quando  ho
iniziato a programmare io,  usavo un  glorioso  C-64 con 39Kb di  ram,
adesso posso anche scialare in 160MB :-)
Loro  dovevano risparmiare su tutto,  e nussuno a  quei si sarebbe mai
posto   il  problema dell'anno 2000....poi   ingegneria  del software,
information hiding erano parole sconosciute.
MP> Non ci resta che aspettare....:-)
MP> 
Ema> io aspetto, privo di preoccupazioni :-)
mhhh, chissà se la centrale telefonica con cui  ti colleghi a internet
è Y2k compliants...:-)))


Un bel di' "Marco Pozzato" scrisse:
MP> C.V.D.
MP> Il senno di poi è una scienza esatta.
MP> proprio così.
MP> 
yes!
MP> Tu, hai imparato  sui loro sbagli,  è facile criticare.  
io ho imparato ragionando... dei loro sbagli non sapevo nulla finche'
i giornali (e non e' tanto) non hanno iniziato a rompere con il
millenium bug :-)
Eppure programmavo gia' da tempo... da tempo... :-)
MP> Ma quando  ho
MP> iniziato a programmare io,  usavo un  glorioso  C-64 con 39Kb di  ram,
MP> adesso posso anche scialare in 160MB :-)
MP> 
beh... avevi anche molte meno estrazioni :-DDDD
Ema>> io aspetto, privo di preoccupazioni :-)
MP> 
MP> mhhh, chissà se la centrale telefonica con cui  ti colleghi a internet
MP> è Y2k compliants...:-)))
MP> 
mi informero' :-)
-- 
"In un'organizzazione gerarchica, piu' alto e' il livello, maggiore e' la
confusione", legge di Dow
