Newsgroup: it.comp.giochi.avventure.testuali
Titolo: se qualcuno sta ancora cercando il cd dei masterpieces...

guardate qui
http://www.lacegem.com/
ciao
S

Heyla, allora
sei ancora dei nostri!!!!
bai bai
tommaso
-- 
Inviato il mar 22 mag 2001 18:02:14 CEST da 62.110.223.218
[62.110.223.218]
http://www.neuromante.net/

 sei ancora dei nostri!!!!
più o meno... sto cercando di tornare a galla. Anzi, ho ricompilato l'ultma versione dei compilatori glulxe e
bi-platform per win32: se volete provarli, mi fate un favore, dato che non mi va di uploadarli senza una
minima verifica. In realtà a me vanno da dio, e non vedo che cosa potrei aver sbagliato dato che ho
ricompilato "straight" o quasi i sorgenti linux con cygnus, ma sapete com'è...
ecco i link
compilatore glulx-inform (output solo glulx, serve interp. glulxE o analogo per giocare):
http://www.elet.polimi.it/Users/DEI/Sections/Compeng/Stefano.Gaburri/informg621-037-win32.zip
compilatore biplatform (genera Zcode, switch -G per generare Glulx)
http://www.elet.polimi.it/Users/DEI/Sections/Compeng/Stefano.Gaburri/informbp621-037-win32.zip
ovviamente servono le librerie biplatform di Zarf. Dai Francesco, provali almeno tu... :)
ciao ciao
S

 wrote in message
3B0AA15C...@elet.polimi.it...


 non saranno un po' corti? ;-D
non so se avete notato che ho appositamente impostato il wrap a 100 caratteri
anziché 80 - che classe, che cura per i propri interlocutori!
ciao
S

 ha scritto nel messaggio
news:3B0AEC10...@elet.polimi.it...

L'ho notato e, non posso negarlo, non senza un velo di commozione.
Ciao

 Ciao
č bello che certe cose vengano apprezzate :)
ma i compilatori li avete provati? a me vanno, quasi quasi li uplodo su
gmd.de...
(strano perň che zarf sul suo sito abbia ancora la versione precedente,
evidentemente non č cambiato un tubo dalla 0.36!)
ciao
S

 gmd.de...
Te ne intendi del funzionamento interno del compilatore glulx?
Esasperato dal non poter scrivere sorgenti 100% portabili quando
devo immettere gli accenti, ho cominciato a pasticciare col sorgente
del compilatore bipiattaforma ed in un due/tre orette ho aggiunto la
possibilità di immettere qualunque carattere Latin-1 con la notazione
"@.." (mantenendo la compatibilità con il sottoinsieme specificato
per la Z-machine). Saresti disposto a dare un occhio alla modifica
(ti manderei la patch per posta)? Se mi dai il tuo benestare potrei
inviarla anche a Zarf...
Certo, è più un "hack" che un lavoro di estrema raffinatezza (2 kb
di patch in tutto), però funziona.
-- 
Matteo De Luigi
Il file ~/.signature non esiste. Il file più vicino per tipo e dimensioni
è /etc/ppp/pap-secrets . Utilizzare questo al suo posto?

 devo immettere gli accenti, 
<snip>
ma sei sicuro che non siano già supportati da glk, su cui glulx è basato? leggo
sul sito di zarf:
http://www.eblong.com/zarf/glk/glk-spec-061_2.html#beg
-----------------------------
2: Character Encoding
Glk uses the Latin-1 Unicode encoding, and keeps it holy. 
Latin-1 is an 8-bit character encoding; it maps numeric codes in the range 0 to
255 into printed characters. The values from 32 to 126 are the standard
printable ASCII characters (' ' to
'~'). Values 0 to 31 and 127 to 159 are reserved for control characters, and
have no printed equivalent. 
Glk uses different parts of the Latin-1 encoding for different purposes. 
-------------------------------------
E il Latin-1 unicode include tutte le lettere accentate, no?
comunque riparliamone, io non mi sono mai posto il problema
ciao
S

 E il Latin-1 unicode include tutte le lettere accentate, no?
Certo. Le accentate sono supportate da Glk. Semplicemente, non possono
essere inserite nel sorgente del compilatore glulx con la notazione "@..".
Se volessi scrivere "Buondì, mondo!", tale stringa verrebbe accettata
solo se la scrivessi così, con il carattere "ì". Ciò purtroppo crea
problemi se lo stesso sorgente deve essere letto, ad esempio, da un PC
e da un Mac. Se io scrivessi invece "Buond@`i, mondo!" e tentassi di
compilarlo, mi verrebbe risposto che la forma "@.." per gli
accenti non è supportata se il target è glulx.
Come Roger Firth fa notare nella pagina
http://homepages.tesco.net/~roger.firth/glulx/chars.html
attualmente l'unico modo sicuro per avere un sorgente bipiattaforma
e compatibile con più sistemi (es.  Mac e Windows)
è mettere un #ifdef TARGET_ZCODE / #ifnot / #endif attorno ad ogni
stringa che contiene accenti, scrivendo le accentate per il codice
glulx come "@@nnn" (codice numerico). Il che non è bello.
Mi sono limitato a sostituire la riga che segnalava l'errore
con del codice che cerca i due caratteri successivi alla "@"
in una tabella, comportandosi poi come se avesse trovato
da subito il carattere latin-1 corrispondente.
Ora avrebbe bisogno di essere un po' raffinata (gestione delle
condizioni eccezionali, ecc.) e troverei utile avere l'aiuto di uno
pratico del sorgente del compilatore.
Così facendo ho potuto compilare un programma che includeva
una versione "glulxificata per castrazione" [1] di "infit".
[1] L'intero corpo di LanguageToInformese rinchiuso tra
    #ifdef TARGET_ZCODE / #endif più qualche modifica qua e là.
    Nessua stringa con accenti è stata toccata.
Se vuoi possiamo continuare il discorso sui dettagli tecnici per posta.
-- 
Matteo De Luigi

 
http://homepages.tesco.net/~roger.firth/glulx/chars.html
<snip>
a parte che mi pare strano che non si riesca in nessun modo a gestire caratteri
accentati in modo omogeneo tra pc e mac (ci saranno bene degli editor con
charsets configurabili sotto mac!), secondo me la cosa migliore è scrivere un
filtro (portabile...) in perl o python che faccia il lavoro "a monte" sul codice
e possa venire invocato in un file batch prima del compilatore. In questo caso
si potrebbe addirittura definire un _altro_ set di sequenze di escape, che
verrebbero tradotte dal filtro in modo differente a seconda del target - glulx o
inform (ripensandoci, meglio sceglierne uno di default scrivendo il filtro,
poniamo, come inform2glulx). Usando la tabella indicata dal buon Roger, è una
lavoro di pochi second... mezz'orett... insomma, da poco.
Come pare l'idea? Questo filtrino secondo me potrebbe essere ben accetto dalla
comunità e servire a distribuire sorgenti portabili (vuoi impacchettando il file
insieme al filtro, vuoi generando le due versioni)
ciao
S

 insieme al filtro, vuoi generando le due versioni)
1) Se lo usiamo come script, la gente con sistemi in cui perl o python non
   sono presenti di default (es.Windows) dovrebbe installarsi un intero
   ambiente solo per uno scriptino.
2) Se l'idea è quella di farlo invocare da un file batch, c'è il problema
   dei file inclusi. Dovrebbe riconoscerli automaticamente, generare
   la traduzione dei file inclusi con nuovi nomi,ecc. Il mio lavoro
   in corso, essendo parecchio modulare, è suddiviso in una ventina
   di file .inf. Insomma, penso che l'utilizzo diventerebbe parecchio
   macchinoso.
3) Chiunque volesse rilasciare una libreria compatibile con z-code e glulx
   dovrebbe usare lo script e rilasciarne due versioni, oppure obbligare
   l'utente ad usare lo script.
4) La patch per il compilatore l'ho già fatta, la vorrei solo far
   controllare da un esperto. Lo script, al contrario, andrebbe
   scritto da zero. :)


    macchinoso.
Ora che ci penso, non è nemmeno necessario. Potrebbe funzionare come
il preprocessore del C, che crea un file gigantesco che poi dà in
pasto al compilatore vero e proprio. In questo caso penso che andrebbe
scritto in C e dovrebbe chiamarsi ipp.


    scritto da zero. :)
il problema è che così a occhio non credo che sarebbe accettata... però puoi
sempre provare a parlare con zarf o roger. 
ciao
S

 sempre provare a parlare con zarf o roger. 
Anch'io penso che al massimo potrebbe diventare una "patch non
ufficiale" rilasciata da sola. Probabilmente, però, un simile
orrore potrebbe motivare qualcuno coinvolto a scrivere del codice
migliore e ad includerlo nel sorgente principale. Se invece c'è uno
scriptino che, pur essendo un risultato subottimo, è pulito ed
è responsabilità altrui, chi si muove più per integrare la
funzionalità nel codice principale? 
Ok, stavo scherzando.
-- 
Matteo De Luigi             Fai collassare le ultime due righe
 a  eo  e  ui i@ i e o i      per ottenere il mio indirizzo.
m tt  .d .l  g  l b r . t

 funzionalità nel codice principale?
non hai tutti i torti. fai una cosa, parlane con roger, poi magari ci rimettiamo
mano insieme! Secondo me così com'è il supporto alle vocali accentate non va
bene, anche perché non vedo perché il compilatore glulx non debba riconoscere
le  sequenze di escape di z-inform, magari dopo aver settato una variabile
globale Z_ESC_SEQ o qualcosa di simile... insomma in questo (cioè ridefinendole)
mi pare che Zarf abbia un po' toppato. Così in prima impressione. E' anche vero
che non ci ho mai pensato finora. D'altronde. Oh beh.
ciao
S
PS ma scusa dato che il problema nasce dalla incompatibilità mac-pc, mi spieghi
perché ci tieni tanto? lavori forse davvero su entrambi contemporaneamente? O è
solo un motivo estetico/estatico?

 perché ci tieni tanto?
Non penso sia solo Pc-Mac
Il punto è che Dos, Win, Linux, Mac, Solaris e compagnia usano tutti quanti
chartable diverse per le accentate. Vorresti fare una versione del tuo gioco
per OGNI possibile sistema operativo?
--
Atrus di Myst =^= 
www.crises.f2s.com
"Non c'è giustizia. Ci sono soltanto io."

 per OGNI possibile sistema operativo?
ma se scrivo il sorgente con le vocali accentate sotto win (mac, solaris) e poi lo compilo
sotto win (mac, solaris), l'oggetto risultante è completamente portabile perchè se ne
occupa la macchina virtuale (interprete glulx). Quindi il problema è unicamente per chi
vuole aprire gli stessi sorgenti su macchine diverse, il che è effettivamente
un'eventualità un po' strana. Come dice roger firth:
If you're not bothered about PC/Mac cross-platform compatibility -- because you work on a
single platform and you've no intention of sharing your source code with anybody else --
use Option 1 because it's easiest to read. 
quindi il problema non riguarda assolutamente le "versioni del gioco", ma solo la
portabilità (direi quasi "visualizzabilità") dei sorgenti. E per questo dico, basta
prendere un editor in grado di interpretare differenti charsets. Oppure usare il solo PC o
Mac.
ciao
S
--questa mia fottuta cosa io la faccio dentro a questa fottuta casa

 use Option 1 because it's easiest to read.
ops, dimenticavo. L'opzione 1 consiste semplicemente nello scrivere le lettere accentate
nel codice cosě come sono.
ciao
S

 contemporaneamente? O è solo un motivo estetico/estatico?
È solo che ho voluto provare glulx e, accortomi che le accentate
nella forma "@.." (di cui i miei sorgenti e la libreria italiana
sono pieni) non erano supportate, ho curiosato nel sorgente per
vedere se era così difficile supportarle e, visto che non era poi
così difficile, le ho aggiunte. Poi mi sono detto « chissà, forse
questa modifica può servire anche ad altra gente... aspetta che
chiedo a uno pratico se mi da' una mano a ripulirla un po'». Tutto lì.


 and you've no intention of sharing your source code with anybody else --
Questa cosa non è poi tanto rara: è possibilissimo che qualcuno
rilasci sorgente senza sapere chi lo leggerà (vedi Infit).
-- 
Matteo De Luigi

 rilasci sorgente senza sapere chi lo leggerà (vedi Infit).
eh ok, occapito, ma sai che problemone... capisco per una libreria, ma il
proprio codice uno alla fine lo rilascia come cavolo vuole, nel caso. Ha voglia
roger ha dire "you absolutely must" - mica stiamo parlando delle API di Java! e
comunque non mi pare che la produzione italiana sia così frenetica da porre la
distibuzione dei sorgenti come un problema di così alta priorità...
ciao
S

 chiedo a uno pratico se mi da' una mano a ripulirla un po'». Tutto lì.
ma hai poi scritto a roger per chiedergli di includere questa modifica nella
pagina degli "inform patches"? secondo me è la soluzione migliore, senza stare a
parlare con zarf (che sbaglierò ma secondo me se la tira un po' troppino).
ciao
S

 ma secondo me se la tira un po' troppino).
Non ho mai avuto a che fare di persona con Zarf ed è da poco che
seguo raif in maniera stabile, per cui non lo conosco bene come
individuo. Supponevo per default che fosse disponibile come le altre
persone che ho contattato per segnalare bachi e proporre soluzioni
o patch. Inoltre pensavo che, anche solo per proporre una patch non
ufficiale, sarebbe stato educato segnalare la cosa all'autore originale.
Del resto, se è da parecchio tempo che bugfix abbastanza importanti
non vengono incorporati (vedi la patch per rendere unsigned l'array
alphabet[3][27]), so già in partenza che la mia non ha proprio
speranze. :)
-- 
Matteo De Luigi