Newsgroup: it.hobby.lotto
Titolo: Standard, una prima idea

Cerchero' di essere conciso e completo
Dalla discussione fin'ora avvenuta mi sono fatto alcune idee:
1) e' necessario l'uso di un file che contenga i parametri necessari
ad intepretare il file dell'archivio
2) il numero dei file di archivio deve essere libero
Possiamo pensare ad un file di definizioni tipo il Win.ini: supponiamo
che abbia estensione .dfa (definizioni archivio)
*********File dell'archivio********
1) non deve contenere (almeno per ora) commenti, marcatori o altro che
non siano le righe di estrazione 
2) tutte le ruote sulla stessa linea
3) informazione sulla ruota nel file .dfa (ruote implicite)
4) le estrazioni in un file di archivio devono essere consecutive,
altrimenti va diviso in piu' file
FORMATO FILE ARCHIVIO
nessun commento iniziale
ogni riga e' cosi' formata:
3 caratteri vuoti (per usi futuri)
3 caratteri di numero indice dell'estrazione
1 car separatore indice-giorno
2 car giorno estrazione
1 car separatore intra-data
2 car mese estrazione
1 car separatore intra-data
4 caratteri anno di estrazione
1 car separatore anno - numeri
*2+1 caratteri numero a due cifre estratto piu' separat. intra-numero
*2+1 caratteri numero a due cifre estratto piu' separat. intra-numero
*2+1 caratteri numero a due cifre estratto piu'separat. intra-numero
*2+1 caratteri numero a due cifre estratto piu' separat. intra-numero
*2+1 caratteri numero a due cifre estratto piu' separat. estratto-info
*5 caratteri per informazioni aggiuntive su ogni singolo estratto
(corrispondenza 1 a 1 con gli estratti, sono possibili 256 codici,
spazio bianco se nessuna informazione)
*1 car separatore cambio ruota
a seguire per tutte le ruote si ripete la parte con gli *
dopo l'ultima ruota il separatore di cambio ruota viene sostituito con
un separatore di fine ruote
FORMATO FILE DEFINIZIONI (.DFA)
1)il file deve essere interpretato e gestito dai programmi
2) siccome si puo' prevedere che ogni porgramma vi mettera' le
informazioni che piu' gli aggradano si puo' pensare ad una sezione
"Generale" definita nello standard ed ad una sezione "Custom" libera 
3) il significato dei codici di affidabilita' vengono definiti dallo
standard e non del file .dfa
il file verrebbe scritto come segue: i commenti si spiegazione sono
con //
{Generale}
[comuni]
ordinamento= crescente //ordine delle estrazioni nei file
riempimento=" "//carattere di riempimento per i numeretti
[files]
nomefile, ordine_caricamento, numero indice prima estrazione, anno
prima estrazione [, numero indice ultima estrazione, anno ultima
estrazione], [ quantita' estrazioni], [ordinamento]
// siccome il file e' di estrazioni consequenziali la data finale e'
//opzionale
//una riga del genere per ogni file da caricare
//[ordinamento] sovrascrive quello della sezione [comuni]
// al posto dei numeri indice si possono usare le date
[separatori]
indice-giorno="carattere " //carattere di separazione tra apici
intra-data="carattere "
anno-numeri="carattere "
intra-numeri="carattere"
estratto-info="carattere"
cambio-ruota="carattere"
fine-ruote="carattere"
//"carattere" puo' assumere anche il valore NULL che indica la
//mancanza si separatore
[codifica]
set-ASCII="latin1" // o altro set
coded= // 0 oppure 1 se gli estratti sono codificati
type_cod= // tipi di codifica da definire, attualmente si potrebbe
//definire lo "short ascii" in cui il numero e' codificato con un solo
//carattere (funzioni chr e ord del pascal)
[ruote]
stringa_ruote= indice_inizio, anno_inizio, [data_inizio]
// stringa che contiene le ruote separate da virgole poi un segno =
// quindi la "data di inizio" da cui valgono quelle ruote
//possono esserci piu' stringhe di ruote
//l'ordine delle ruote nella stringa e' lo stesso delle estrazioni nel
//file di archivio
{Personale}
// sezioni utili per i vari programmi 

...ben acectti commenti suggerimenti e....
bocciature
Saluti a tutti 
Victor

io uso file ad accesso casuale per diverse ragioni (affidabilità e maggiore
velocità di lettura del codice)
se vi va di creare un archivio standard compatto basta inserire x caratteri
per la data, l'estrazione dell'anno e volendo anche il giorno, ed infine 50
Caratteri Ascii ad esempio il numero aumentato di 127 unità per evitare di
utilizzare i primi 17 caratteri (che creerebbero problemi).
Ovviamente un file Txt utilizzabile da qualsiasi piattaforma
a presto
Davide Greco    
dav...@tin.it

La mia idea invece e' questa:
- avere un tracciato unico in formato .txt, ed
   ognuno se lo "importa" come serve al suo linguaggio
   di programmazione:
Prima posizione, Tipo record, fisso "E".
4 caratteri: Anno
2 caratteri: Mese
2 caratteri: Giorno
3 caratteri: Numero estrazione nell'ambito dell'anno
5 numeri da due caratteri x ogni ruota, a partire da Bari,
   fino a Venezia;
Fra tutti i singoli campi, un separatore, per es. "#".
Tutti gli altri fronzoli possono essere inseriti a volonta'
nei propri archivi, ma non in questo generico.
Ciao, Pasquale Fusco

Un bel di' Victor scrisse:
V> 1) e' necessario l'uso di un file che contenga i parametri necessari
V> ad intepretare il file dell'archivio
Why!?
Secondo me non e' assolutamente necessario: lo standard e' quello, e cosi'
lo si fa.
Hai mai visto un .ini per i jpg, gif, png...?? :-)
V> 2) il numero dei file di archivio deve essere libero
V> 
no. Deve essere standard.
O tutto in uno, o diviso.
Ma si decide tutto!
Lo standard deve impedire qualsiasi tipo di personalizzazione! :-)
V> 1) non deve contenere (almeno per ora) commenti, marcatori o altro che
V> non siano le righe di estrazione 
ottimo! niente robaccia!
V> 2) tutte le ruote sulla stessa linea
no, questo no.
Stiamo parlando di un file leggibile.
E allora leggibile lo facciamo: andiamo a capo quando e' ora (ogni ruota)
ecc.
Se vogliamo poi un file standard compresso, allora ogni numero e' un
byte (che e' anche molto piu' veloce accedervi).
V> 3) informazione sulla ruota nel file .dfa (ruote implicite)
informazioni sulle ruote da nessuna parte.
Le ruote sono definite al di fuori, mentre definisci lo standard.
V> 4) le estrazioni in un file di archivio devono essere consecutive,
V> altrimenti va diviso in piu' file
ed aggiungo dalla piu' vecchia alla piu' nuova.
Il resto non lo commento perche' non sono d'accordo :-)
-- 
"Meno ti diverti a far parte di un comitato, piu' ti sara' fatta pressione
perche' ci entri", seconda legge della ComitatoDinamica
-- 
Emanuele Cesena
em...@iol.it
          occhio all'antispam NOSPAM!
http://www.geocities.com/SiliconValley/Grid/8879

Victor ha scritto:
V>  1) e' necessario l'uso di un file che contenga i parametri necessari
V>  ad intepretare il file dell'archivio
non dovrebbero stare nella definizione del formato?
se sono parametri, allora non è più tanto standard, ma liberamente modificabile
Ribadisco poi che per i molti appassionati che sanno un po' di basic o di
pascal sarebbe una complicazione notevole.
V>  2) il numero dei file di archivio deve essere libero
in che senso?
V>  3 caratteri vuoti (per usi futuri)
V>  3 caratteri di numero indice dell'estrazione
così ci facciamo solo 1000 estrazioni, mentre sono già più di 6000
almeno 4 cifre
V>  1 car separatore indice-giorno
V>  2 car giorno estrazione
a che servono i separatori se la struttura è fissa?
Ciao
Marco
-- 
Chi porta un notevole contributo in un qualsiasi campo e ci rimane abbastanza
a lungo, diventa un ostacolo al progresso in quel campo in proporzione diretta
all'importanza del proprio contributo. (Prima legge di Jones)
 

Ema da TIN ha scritto:
V>> 2) tutte le ruote sulla stessa linea
EdT>  no, questo no.
EdT>  Stiamo parlando di un file leggibile.
EdT>  E allora leggibile lo facciamo: andiamo a capo quando e' ora (ogni ruota)
EdT>  ecc.
questo lo capisco, ma se manteniamo un estrazione su un'unica riga diventa
molto più semplice effettuare diverse manipolazioni usando i programmini delle
textutils: è vero che quasi nessuno li conosce, ma si potrebbero fare degli
script batch che fanno il tutto.
Ad esempio:
- estrarre dall'archivio solo alcune ruote
- aggiungere un nuova ruota
separare le ruote con 'a campo' non rende molto più leggibile il tutto se non
ci metti anche il nome della ruota: dopo 6 o 7 cinquine di soli numeri non sai
già a che ruota sei. 
EdT>  Se vogliamo poi un file standard compresso, allora ogni numero e' un
EdT>  byte (che e' anche molto piu' veloce accedervi).
questa smania di efficienza non la capisco (forse perchè non ho mai fatto un
programma per il lotto....)
Forse qualcuno di voi che ha fatto programmi mi può rispondere:
- fate le analisi sui file o copiate i dati in memoria?
- perchè non caricate l'archivio in memoria e fate lì le elaborazioni?
- siete poi così sicuri che l'accesso casuale a file sia così efficiente in
questo caso?
- un'operazione di lettura non legge mica solo gli X byte che uno richiede, ma
si legge tutto un cluster. E se il file dell'archivio è frammentato? alè! le
testine del disco ballano la samba...
Ciao
Marco
-- 
L'ottimista proclama che viviamo nel migliore dei mondi possibili.
Il pessimista teme che sia vero.
(Teorema del Cardinale)



Qualcosa del genere e' gia' piu' accettabile.
A parte quei tipi di separatori che complicano la digitazione,
sarebbe meglio lo spazio come separatore.
Poi, passiamo al conteggio dei bytes:
4+2+2 (anno, mese, giorno o viceversa) 	= 8 caratteri
3 (numero del concorso o estrazione)		= 3 caratteri
50 + 9 (gli estratti + i delimitatori) ammesso
che gli estratti vengano memorizzati su di
una stessa linea				= 59 caratteri ( 1 )
o
50 (estratti) ammesso che gli estratti
vengano memorizzati su 10 righe verticali	= 50 caratteri ( 2 )
Nel conteggio non vengono considerati i
caratteri delle ruote, le quali si suppongono
essere ordinate da BA a ... VE.
Quindi: (n.b. 6778 sono il tot. delle estrazioni dal 1871)
( 1 ) 70 caratteri x 6778 = 474.460 caratteri = 948.920 bytes
( 2 ) 61 caratteri x 6778 = 413.458 caratteri = 826,916 bytes
Quasi un mega di dati mi sembra un po' troppo
(la cosa comunque e' soggettiva), certamente non credo
che si possa avere chiarezza e snellimento dell'archivio.
Ma siccome l'idea di questo standard e' la chiarezza e
la facilita' dell'immissione degli estratti, l'ASCII e' l'ideale.
Una domanda:  :)
Ma x la ricerca, la statistica, ed eventuali tecniche
previsionistiche, A COSA SERVE LA DATA ?
Se non ci sara'  risposta, presumo che essa non
serve a nulla; quindi potrebbe essere altro spazio
risparmiato.
Saluti.
A.GALENO


anche io non la capisco, ho fatto programmi per il lotto e credo che
usando le giuste tecniche la lettura da file non comporti problemi.
cmq quasi nessuno la pensa cosi', in effetti ho visto programmi lotto
stranamente lenti, credo si tratti di uso di tecniche sbagliate.
Ciao!
Victor

Hai mai visto un .ini per i jpg, gif, png...?? :-)
forse l'essempio e' calzante: di formati gif e jpeg ne esistono molte
versioni, le informazioni per poterli leggere sono in parte codificate
nello standard , in parte scritte all'inizio del file (se ben
ricordo), addirittura i gif sono in pratica degli eseguibili. Il file
dei parametri sarebbe una specie di header.
Ciao!
Victor

a che servono i separatori se la struttura è fissa?
per averre una struttura che puo' essere letta sia come campi fissi
che delimitati (cmq nel file dei parametri e' previsto anche il valore
null per il separatore)
Ciao
Victor

Un bel di' Marco Pozzato scrisse:
MP> questo lo capisco, ma se manteniamo un estrazione su un'unica riga diventa
MP> molto più semplice effettuare diverse manipolazioni usando i programmini delle
MP> textutils: è vero che quasi nessuno li conosce, ma si potrebbero fare degli
MP> script batch che fanno il tutto.
ok, ma se uno vuole lo script non puo' riscriversi l'archivio esattamente
come uno che lo vuole nel suo formato??
MP> separare le ruote con 'a campo' 
di grano!? :-))))
scusa... riprendiamo il discorso serio:
MP> separare le ruote con 'a campo' non rende molto più leggibile il tutto se non
MP> ci metti anche il nome della ruota: dopo 6 o 7 cinquine di soli numeri non sai
MP> già a che ruota sei. 
MP> 
come no... scusa: non sapete contare fino a 10??
12 righe nello schermo, ossia da una data ad un'altra, per avere perfetta
visione di tutte e 10 le ruote in un'estrazione, ci stanno anche
per chi usa Windows in 320x200 con Accesso Facilitato che ingrandisce
9 volte lo schermo!
Mentre con tutto in una riga, non hai tutto sott'occhio... per non
parlare della scomodita' (per me che uso il vi) di scrivere cose lunghe
tutte di fila! :-)
Fra parentesi... perche' il tuo bell'emacs non va a capo dopo il 72°
carattere?? :-)))
EdT>>  Se vogliamo poi un file standard compresso, allora ogni numero e' un
EdT>>  byte (che e' anche molto piu' veloce accedervi).
MP> 
MP> questa smania di efficienza non la capisco (forse perchè non ho mai fatto un
MP> programma per il lotto....)
MP> 
eh eh eh... :-)))
MP> Forse qualcuno di voi che ha fatto programmi mi può rispondere:
MP> - fate le analisi sui file o copiate i dati in memoria?
le copio in memoria.
MP> - perchè non caricate l'archivio in memoria e fate lì le elaborazioni?
le copio in memoria.
MP> - siete poi così sicuri che l'accesso casuale a file sia così efficiente in
MP> questo caso?
non ho idea di cosa sia l'accesso casuale.
So che in Basic si distingue tra accesso per input/output/append/random,
ma non vado oltre i primi 3 :-)
MP> - un'operazione di lettura non legge mica solo gli X byte che uno richiede, ma
MP> si legge tutto un cluster. E se il file dell'archivio è frammentato? alè! le
MP> testine del disco ballano la samba...
MP> 
embe?? Con un file formattato non balla la samba allo stesso modo??
ma veniamo al bello: preferisci leggere da yun file con un
 	fwrite (&estrazione, 1, 54);
oppure con uno:
	for (i=0; i<50; i++)
	   fscanf( "%d", &estrazione.numero[i]);
per non parlare dei problemi che creano tutti i vari '|' ed amenicoli
vari :-))
bye! :-)
-- 
"A volte l'uomo inciampa nella verita', ma nella maggior parte dei casi si
rialzera' e continuera' per la sua strada", commento di Churchill sull'Uomo


Rispondo volentieri per non far cadere questa
mia idea.
Premessa: il file da me ipotizzato non deve
servire per uniformare i propri metodi
di sviluppo, ma deve esere la base 'unica'
di partenza a cui tutti possono accedere facilmente,
e usarlo successivamente,
nelle proprie applicazioni come meglio crede.
1 - Anno, mese e giorno, - e non viceversa -.
    La data e' indispensabile poiche' puo' essere
    considerata la "Chiave di accesso principale"
    nei files ad accesso diretto;
2 - E' piu' importante la data che il numero
    della estrazione; ma tant'e' ..
3 - Tutte le ruote di una estrazione devono
    stare sulla stessa riga, altrimenti si fa'
    un torto a quelli che devono usare i
    successivi archivi ad accesso diretto:
    questi sarebbero costretti a ripetere la
    data per ogni ruota.
4 - I separatori servono per poter "importare"
    facilmente i dati nei linguaggi strutturali
    del tipo Access, Foglio elettronico, SQL;
    se non li mettissimo, faremmo un torto a
    chi usa questi tipi di archivi.
5 - E' vero che la chiarezza dei dati litiga,
    in questo caso, con lo spazio su disco e di memoria,
    ma non perdiamo di vista che questo file,
    - almeno come l'ho inteso io -, deve essere
    solo di partenza (v. premessa).
6 - La tua giusta preoccupazione sono i separatori
    poiche' pensi alla digitazione.
    Io sono andato un po' oltre: i dati non
    si dovrebbero piu' digitare.
    Infatti io li prendo dalle
    pagine Web di Televideo Rai, li scarico in
    formato .txt, e li do in pasto ad uno stupidissimo
    programma che li manda nei miei archivi.
    Un'azione comune che potremmo fare e' di
    richiedere a Televideo se ci tiene le ultime
    10 o 12 estrazioni e non solo le ultime 2.
Ciao, Pasquale Fusco

Un bel di' Victor scrisse:
V> forse l'essempio e' calzante: di formati gif e jpeg ne esistono molte
V> versioni, le informazioni per poterli leggere sono in parte codificate
V> nello standard , in parte scritte all'inizio del file (se ben
V> ricordo), addirittura i gif sono in pratica degli eseguibili. Il file
V> dei parametri sarebbe una specie di header.
V> 
gia' forse ho preso l'esempio peggiore che potevo trovare...
pero' l'header nei file grafici serve perche' possono essere codificati
secondo modalita' grafiche diverse... le estrazioni del lotto
invece non hanno "piu' modalita'" :-)
-- 
"Gli esperti di calcio non fanno mai tredici", osservazione di Malipieri



http://www.geocities.com/SiliconValley/Grid/8879
questi esperti...

Ema da TIN ha scritto:
MP>> textutils: è vero che quasi nessuno li conosce, ma si potrebbero fare degli
MP>> script batch che fanno il tutto.
EdT>  ok, ma se uno vuole lo script non puo' riscriversi l'archivio esattamente
EdT>  come uno che lo vuole nel suo formato??
sì, ma l'idea è di costruire riutilizzando programmi già fatti, senza scrivere
ogni volta del nuovo codice.
EdT>  come no... scusa: non sapete contare fino a 10??
dipende....dopo un po' di righe perdo il conto... :-(
EdT>  Fra parentesi... perche' il tuo bell'emacs non va a capo dopo il 72°
EdT>  carattere?? :-)))
primo perchè gli ho detto di andare a capo al 78°, secondo perchè mi trovo
tanto bene con la console a 116 colonne :-)
MP>> - un'operazione di lettura non legge mica solo gli X byte che uno richiede, ma
MP>> si legge tutto un cluster. E se il file dell'archivio è frammentato? alè! le
MP>> testine del disco ballano la samba...
MP>> 
EdT>  embe?? Con un file formattato non balla la samba allo stesso modo??
sì, il discorso era riferito a chi legge i singoli byte per andare svelto,
senza rendersi conto che, leggendo 50 byte, il SO legge cmq tutto un cluster
(4KB o magari 32KB)
 
EdT>  ma veniamo al bello: preferisci leggere da yun file con un
EdT>   	fwrite (&estrazione, 1, 54);
EdT>  oppure con uno:
EdT>  	for (i=0; i<50; i++)
EdT>  	   fscanf( "%d", &estrazione.numero[i]);
decisamente meglio il secondo: è molto più chiaro quello che stai facendo.
Sono convinto che certe ottimizzazioni non pagano: in certi casi è meglio
scrivere del buon codice leggibile e riutilizzabile e affidarsi
all'elettronica per l'efficienza.
EdT>  per non parlare dei problemi che creano tutti i vari '|' ed amenicoli
EdT>  vari :-))
ma si tratta di una routine che scrivi una volta nella vita.
Ciao
MArco
-- 
La natura e' fantastica. Un miliardo di anni fa non avrebbe mai sospettato
che noi avremmo portato gli occhiali, eppure ci ha fatto le orecchie.
(Milton Berle)

Pasquale Fusco ha scritto:
PF>  6 - La tua giusta preoccupazione sono i separatori
PF>      poiche' pensi alla digitazione.
PF>      Io sono andato un po' oltre: i dati non
PF>      si dovrebbero piu' digitare.
PF>      Infatti io li prendo dalle
PF>      pagine Web di Televideo Rai, li scarico in
PF>      formato .txt, e li do in pasto ad uno stupidissimo
PF>      programma che li manda nei miei archivi.
č esattamente la stessa cosa che ho pensato io.
sotto linux č relativamente semplice:
- si imposta un job che al giovedě e alla domenica scarica la pagina 661
(l'ultima estrazione). Dopodichč lo scaricamento della pagina č automatico, al
primo collegamento, viene presa.
- un programmino semplice, elimina i fronzoli e aggiorna l'archivio.
- un altro scriptino spara l'archivio aggiornato su un sito web a dispozione
di tutti.
Se avanzo un po' di tempo mi ci metto.


>"Gli esperti di calcio non fanno mai tredici", osservazione di Malipieri
DG> 
DG> questi esperti...
DG> 
eh eh eh... allora vedo che le leggete... :-))
-- 
"Quando tutto va bene, qualcosa andra' male", seconda legge di Chisholm
"Corollari
  1- Quando non puo' andar peggio di cosi', lo fara'
  2- Se le cose sembrano andar meglio, c'e' qualcosa di cui non stiamo
     tenendo conto"


.. prima o dopo mi attrezzero' con Linus !
Mi piace il job che parte e fa tutto da solo !
Ciao. Pasquale Fusco

Un bel di' Marco Pozzato scrisse:
EdT>>  ok, ma se uno vuole lo script non puo' riscriversi l'archivio esattamente
EdT>>  come uno che lo vuole nel suo formato??
MP> 
MP> sì, ma l'idea è di costruire riutilizzando programmi già fatti, senza scrivere
MP> ogni volta del nuovo codice.
MP> 
vabbe'... come volete :-)
(io comunque resto dell'idea di andare a capo!) :)
EdT>>  come no... scusa: non sapete contare fino a 10??
MP> dipende....dopo un po' di righe perdo il conto... :-(
MP> 
suvvia... :-)
EdT>>  Fra parentesi... perche' il tuo bell'emacs non va a capo dopo il 72°
EdT>>  carattere?? :-)))
MP> 
MP> primo perchè gli ho detto di andare a capo al 78°, secondo perchè mi trovo
MP> tanto bene con la console a 116 colonne :-)
MP> 
ok, ma 78 non sono un po' troppe?? Aggiungi anche solo un quoting, senza
il nome davanti, e sei gia' oltre le 80 :-)
Ma 116 colonne da terminale!? :-)
EdT>>  ma veniamo al bello: preferisci leggere da yun file con un
EdT>>   	fwrite (&estrazione, 1, 54);
EdT>>  oppure con uno:
EdT>>  	for (i=0; i<50; i++)
EdT>>  	   fscanf( "%d", &estrazione.numero[i]);
MP> decisamente meglio il secondo: è molto più chiaro quello che stai facendo.
MP> 
MP> Sono convinto che certe ottimizzazioni non pagano: in certi casi è meglio
MP> scrivere del buon codice leggibile e riutilizzabile e affidarsi
MP> all'elettronica per l'efficienza.
MP> 
mah, contento te! :-)
Io preferisco di gran lunga la prima: perche' una CPU deve stancarsi
a leggere dei numeri in ASCII e convertirli, quando possiamo darglieli
gia' comodi?? :-)
EdT>>  per non parlare dei problemi che creano tutti i vari '|' ed amenicoli
EdT>>  vari :-))
MP> ma si tratta di una routine che scrivi una volta nella vita.
MP> 
vabbe', anche tutto quello che dico io lo scrivi una sola volta nella vita...
Bye :-)
-- 
"Finche' si morde un lupo, pazienza. Quel che secca e' quando si morde una
pecora", legge di Joyce


.. prima o dopo mi attrezzero' con Linus !
Io prenderi in considerazione anche Charlie Brown... :-)
Ciao
P.S.: Scusa, non ho resistito...!
--
Riccardo
email: 
r.c...@iol.it

Ciao. Pasquale Fusco
Accùra co' 'sti "job"! ;))
Ciao!
MagoPeppe
ICQ 9759626
"La fortuna è donna e va battuta". (Machiavelli)
Staff Tecnico MPO & NuovaCornucopia
Home page:
http://dreamlink.net/magopeppe
ATTENZIONE: il mio indirizzo email cambierà dal 16 Giugno 1999.
Togli levaccà per contattarmi via email.

P.S.: Scusa, non ho resistito...!
Scusate anche me!


Ema da TIN ha scritto:
EdT>  Ma 116 colonne da terminale!? :-)
EdT>  
yes, sure! :-)
rpm -i SVGATextMode*.rpm
vi /etc/TextConfig
et voilà
EdT>  Io preferisco di gran lunga la prima: perche' una CPU deve stancarsi
EdT>  a leggere dei numeri in ASCII e convertirli, quando possiamo darglieli
EdT>  gia' comodi?? :-)
mica si stanca la CPU, mi stanco io a ottimizzare il codice, a modificarlo
quando cambia il formato...
Ciao
Marco
-- 
Se qualcosa puo' andar male, lo fara'. (Legge di Murphy)

Pasquale Fusco ha scritto:
PF>  ... prima o dopo mi attrezzero' con Linus !
PF>  Mi piace il job che parte e fa tutto da solo !
già.
Sicuramente si può fare anche sotto Windows, solo che occorre mettersi a
scrivere codice su codice, credo. Sotto linux hai tanti bei mattoncini già
pronti per l'uso, basta assemblarli, al limiti programmi qualche piccolo tools
e poi incolli il tutto in uno script.
Di una facilità e semplicità sconvolgente quando lo sai fare...
ma quando lo sai fare? :-))
Ciao
Marco 
-- 
Una qualsiasi autorizzazione sarà concessa solo quando nessuno di coloro che
la concedono potrà essere incolpato in caso di fallimento, e tutti coloro che
la concedono potranno vantarsi in caso di successo. (Regola di Roger)

 scrisse nei seguenti NG: it.hobby.lotto:
MP> Ema da TIN ha scritto:
EdT>>  Ma 116 colonne da terminale!? :-)
EdT>>  
MP> yes, sure! :-)
MP> 
MP> rpm -i SVGATextMode*.rpm
MP> vi /etc/TextConfig
MP> 
MP> et voilą
MP> 
temo molto: non so :-)
EdT>>  Io preferisco di gran lunga la prima: perche' una CPU deve stancarsi
EdT>>  a leggere dei numeri in ASCII e convertirli, quando possiamo darglieli
EdT>>  gia' comodi?? :-)
MP> mica si stanca la CPU, mi stanco io a ottimizzare il codice, a modificarlo
MP> quando cambia il formato...
MP> 
vabbe'... mi sa che vi lascero' 'sti benedetti separatori, senno' il
f.s. non lo si vede giammaipiu' :-)
-- 
"La crema sale in cima. Anche la feccia", legge di Wellington sul Potere
