Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Intarsi: qualche critica costruttiva

Visto che è scoppiata la polemica su Intarsi, preferisco non inserirmi nelle
questioni sollevate ma aprire un nuovo thread per dire la mia.
Innanzitutto, preciso che ho dato una letta veloce al codice contenuto nei
vari file e che quindi non voglio entrare nei dettagli dell'algoritmo (sia
la versione iterativa che quella ricorsiva). Se l'algoritmo funziona e
riconosce frasi complesse, mi fido perché per ora come ora non ho molto
tempo di studiarlo. Mi sono scaricato il file da IFItalia solo per vedere le
sue potenzialità come sistema per lo sviluppo di IF.
Come prima critica devo dare ragione a Stefano sul fatto che, allo stadio in
cui è ora, Intarsi serve a ben poco. Al contrario di Stefano (che non ha
letto il codice) però posso dire cosa c'è di sbagliato, secondo me, in
questo sistema. A parte il fatto più volte ripetuto che Intarsi è solamente
un parser, ci sono delle cose che lasciano poco spazio al successivo
sviluppo in un sistema completo per la creazione di IF. Mi riferisco in
particolar modo alla grammatica. Mi spiego con un esempio. Supponiamo che
voglia fare una AT con Intarsi. Mi devo programmare tutti gli oggetti
dell'avventura e le relazioni tra essi (e la reazione alle azioni del
giocatore) e poi aggiungere i vari elementi grammaticali (nomi, aggettivi,
ecc) nel file grammar.dat.  Sta proprio qui il problema di Intarsi, cioè
diventa incredibilmente macchinoso programmare un'AT perché si deve passare
continuamente da un file all'altro (con la possibilità che mi dimentichi di
inserire qualcosa). Qui c'è prima di tutto un problema di denominazione:
kiuhnm chiama grammatica una cosa che non è la grammatica ma semplicemente
il dizionario dell'avventura (o meglio, nel file grammar.dat ci sono sia
elementi di grammatica che di dizionario). Secondo: in tutti i moderni
sistemi di programmazione di IF, il dizionario del gioco viene costruito in
automatico mentre si programma l'avventura. Ad esempio in Inform se scrivo
Object Stanza "Una bella stanza"
    with name "bella" "stanza"
tutte le parole tra virgolette sono automaticamnte inserite nel dizionario
in fase di compilazione. Naturalmente la libreria di Inform contiene già
degli elementi di base che sono inseriti in automatico in tutte le
avventure, come gli articoli. Preciso che, anche se ho portato l'esempio di
Inform, gli altri sistemi come TADS e Hugo usano lo stesso approccio.
A questo punto vorrei sollevare un'altra questione (prendetela con il
beneficio del dubbio, visto che non ho analizzato i dettagli tecnici
dell'algoritmo). Il "significato" di una frase è riconosciuto isolando nella
frase stessa le varie sezioni (specificate nel file grammar.dat). Qui c'è
come prima cosa una confusione sul significato di sezione. Che cos'è la
sezione di una frase?? Un elemento grammaticale (ad esempio nome, aggettivo,
ecc.)?? O un elemento logico (complemento oggetto, complemento di mezzo,
ecc)?? Oppure ancora una frase intera (come nella sezione che viene chiamata
'azione' -- in questo caso penso il parser richiami ricorsivamente se stesso
per riconoscere questa azione, ma forse mi sbaglio)????
Un approccio di questo tipo genera dei problemi. Ci sono sezioni che
dipendono dal contesto mentre altre no (per dirla con la terminologia della
"Teoria dei linguaggi" non si capisce se la grammatica sia context-free
oppure no). In questo caso si vede che kiuhnm non pensava alla
programmazione di un'avventura mentre sviluppava Intarsi., perché non pensa
mimimamente a cosa ci deve fare con le frasi che ha riconosciuto. Secondo me
un approccio migliore sarebbe stato partire dal concetto di azione (che cosa
è una azione? ad ogni azione corriponde una ben determinata reazione da
parte dell'AT. Ecc.) e poi vedere come questa deve essere costruita dal
punto di vita logico e grammaticale (in corrispondenza alle azioni
definite).
Vabbè, per ora basta. Ho in mente ancora altre cose, ma forse sono stato
troppo prolisso.
Giovanni

 per riconoscere questa azione, ma forse mi sbaglio)????
Mi rendo conto che dovevo aggiungere più commenti al codice.
Intarsi a prima vista può sembrare una cacchiata, infatti tutti quelli che
l'hanno letto (tranne Mad Dog) hanno pensato di averlo capito semplicemente
dandogli un'occhiata.
Dalle domande che mi fai ho capito che sei caduto in equivoco, comunque
apprezzo veramente tanto il fatto che tu l'abbia letto.
E' inutile che io continui a rispondere passo passo alla lettera, però posso
concludere dicendo che il fatto che la "grammatica" non abbia una forma ben
delineata è proprio il punto forte di Intarsi.
E quando tempo fa dissi che non era indispensabile conoscere la grammatica
(in senso teorico), ma semplicemente saper parlare (istintivamente, quindi)
per scrivere una grammatica per Intarsi, intendevo dire proprio questo.
Se siete d'accordo, inizierò un thread dove spiegherò in modo semplice il
funzionamento d'Intarsi senza riferimenti al codice.
Prenderò un pezzo di grammatica, una frase e vi farò vedere come Intarsi si
comporta.
P.S. Quando parli di ricorsione hai ragione, però non hai capito che in
realtà parliamo di backtracking (con euristica parziale, in quanto, in
questo caso, sarebbe quasi NP-hard e inoltre lo stack fonderebbe di brutto!
:-) )

 :-) )
Ancora con questo fatto che non ho capito. La prima cosa che ho scritto è
che non ho letto il codice in dettaglio, ma ho solo cercato di capire i
concetti fondamentali. E poi ho scritto "penso che il parser richiami
ricorsivamente ...." e non "sono sicuro che il parser richiami
ricorsivamente ...".
Ciao
Giovanni

Ciao a tutti.
Mi piace l'idea della critica costruttiva. Parliamone senza darci degli
ignoranti, dei deficienti o dei "piccoli creti". :-) Il seguente messaggio č
dedicato, ma non riservato, ai programmatori che frequentano il NG. Buona
lettura.
  Mad Dog
Vediamo un attimo se e come applicare Intarsi ad un sistema di authoring di
AT, andando a intuito. E' vero che la grammatica di Intarsi č solo un
dizionario ma... MA... la grammatica č caricata in una struttura ad oggetti,
sia nella versione C che in quella Java. Ora, in particolare in quella Java,
il sistema di caricamento č flessibile ed estendibile. Il che significa che
nessuno vieta di specializzarlo in qualcosa che aggiunga tutte le
informazioni che mancano. Facciamo un esempio, prendiamo un segmento della
grammatica inclusa:
  [v.imperativo]
  {
   [transitivo]
   {
    [prendi]
    {
     "prendi"
     "raccogli"
     "acquisisci"
     "afferra"
     "impugna"
    }
  [v.infinito]
  {
   [transitivo]
   {
    [prendere]
    {
     "prendere"
     "raccogliere"
     "acquisire"
     "afferrare"
     "impugnare"
    }
Questo definisce il verbo "prendi" come sottoclasse di un generico verbo
transitivo, a sua volta sottoclasse sia di un generico verbo imperativo che
di un verbo infito. La frase di test utilizzata č:
  "ordina a Marco di prendere la tastiera bianca sulla scrivania"
Ad analisi completata, in particolare nella versione Java, si ottiene un
albero di risultato come il seguente:
[...]
  [richiedi azione]
  ordina a marco di prendere la tastiera bianca sulla scrivania
    [chiedi]
    ordina a marco di prendere la tastiera bianca sulla scrivania
    [a]
    a marco di prendere la tastiera bianca sulla scrivania
    [persona]
    marco di prendere la tastiera bianca sulla scrivania
    [azione]
    prendere la tastiera bianca sulla scrivania
      [prendere oggetto]
      prendere la tastiera bianca sulla scrivania
        [prendere]
        prendere la tastiera bianca sulla scrivania
        [oggetto]
        la tastiera bianca sulla scrivania
[...]
Come fa, a questo punto, il sistema di gioco a capire che l'azione č proprio
quella di prendere un oggetto? Con la grammatica inclusa bisogna aggiungere
un'euristica che si basi sul testo, ma se aggiungiamo qualche informazione
alla grammatica tutto diventa piů semplice:
  [v.imperativo]
  {
   [transitivo]
   {
    [prendi] @TYPE:VERB @ACTION:TAKE
    {
     "prendi"
     "raccogli"
     "acquisisci"
     "afferra"
     "impugna"
    }
  [v.infinito]
  {
   [transitivo]
   {
    [prendere] @TYPE:VERB @ACTION:TAKE
    {
     "prendere"
     "raccogliere"
     "acquisire"
     "afferrare"
     "impugnare"
    }
Al sistema di caricamento si aggiunge la logica per identificare anche una
tipologia di sezione utile al sistema di gioco, come il fatto che si tratti
effettivamente di un verbo e che, in particolare, corrisponda con la
primitiva "take". La rappresentazione ad oggetti della grammatica permette,
in modo molto semplice, di estenderla per mantere anche informazioni come
queste.
Allo stesso modo si possono indicare anche quali sezioni sono "item", quali
sono "pronoun", ecc. Serve un livello piů generico, dove si ragione per
azione e non per primitive? Bene, alla aggiungiamo le informazioni sulla
sezione "[prendere oggetto"] che la prima delle due sottosezioni č la
primitiva "take" e la seconda č l'"item" relativo.
Ottenuto l'albero dei risultati, con una grammatica estesa, l'analisi
semantica si puň basare sul semplice riconoscimento di queste informazioni.
Intarsi ha stabilito di quali sezioni si tratta, la struttura dati indica il
loro significato. Se penso al modo con cui funziona il vecchio parser del
JVenture (sě, sě... sono sempre io Regium Lepidi corp.), tutto questo gli
puň essere applicato con uno sforzo ragionevole.
Il discorso della grammatica priva o no di contesto, secondo me, non
c'entra, perchč non č il parser (o meglio, non a questo livello) che deve
risolvere il contesto, ma ciň che analizza la semantica della frase. Non so
se mi sono spiegato...
Per finire, come diceva anche Kiuhnm, nessuno vieta di "rendere"
(dall'inglese "render") la grammatica di Intarsi come risultato di
un'elaborazione a partire da un file di definizione piů completo/complesso,
che magari comprenda anche locazioni, oggeti, descrizioni, scripting e
quant'altro. Il parser di Intarsi si basa su una grammatica che segue una
certa struttura, l'importante č fornirgliela. Da dove viene e come č
ottenuta non č importante, nč deciso a priori.
Questo, dal mio punto di vista, spiega come integrare Intarsi in un sistema
piů complesso, e ne mette in risalto i pregi. E', come detto, un parser
generico che ben si sposa con qualsiasi cosa tenti di interpretare un
linguaggio naturale, senza porvi nessun limite. E scusate se č poco...
Ciao.
   Mad Dog

Lo pseudo codice è complesso quanto il codice in questo caso :-)
E' inutile che stiamo qui a discutere su cosa Intarsi possa o non possa
fare.
Capito come funziona il codice, saprete rispondervi da soli e magari mi
illustrerete aspetti ai quali non avevo minimamente pensato.
Per quanto riguarda la complessità, è difficilmente migliorabile, se non di
una costante praticamente insignificante.
Come tutti gli algoritmi di backtracking, anche Intarsi può essere
migliorato solo modificando l'euristica, ma così si compromette la sua
generalità e quindi questa strada non è percorribile (senza renderlo meno
generale, appunto).
Con Intarsi non ho voluto proporre uno strumento completo, ma un nuovo modo
per affrontare il parsing. [crocifiggiamo tutti i democoder, dai!]
Qualsiasi discorso sull'interfaccia e su come la grammatica venga
letta/modificata è completamente fuori luogo.
Nessuno vieta di buttare via Intarsi e di scrivere qualcosa di simile con in
mente l'idea di base: "programmare un parser generico con l'uso di tecniche
di backtracking [parzialmente euristico]".
Basta un piccolo sforzo di astrazione per riuscire a scindere l'idea dal
programma, no?
E comunque, secondo me, lo pseudo codice crea solo dei gran problemi. Quante
volte lo pseudo-codice era ambiguo in certi punti e, non potendo essere
compilato ed eseguito, siete stati costretti a rinunciare? (capire lo pseudo
codice sembra facile, ma, guarda caso, quando si prova a trasformarlo in
codice, sorgono i problemi...boh...forse trattasi di pura fatalità)
Il mio errore è stato quello di postarlo in ICGAT pensando che foste i primi
interessati, invece non ragionate come programmatori, ma come giocatori
(come forse è giusto che sia).
Scusatemi per il disturbo e adesso mi tolgo dai c*****i. Intarsi potete
anche bruciarlo per quel che mi riguarda.
Da ora in poi su QUESTO ng scriverò soltanto per dire:
"che bella at che hai scritto!"
"come faccio a scappare dalla casa?"
"(OT) suonerie"
o cose del genere...

 "(OT) suonerie"
Mi sembra un comportamento un po' da bambini. Ha presente,quando i bambini
litigano, frasi del tipo "non ti parlo più"?
Giovanni
PS: Capisco la delusione, per la freddezza con cui è stato accolto il tuo
lavoro. Pensa che infit è stato usato solo un anno dopo che era stata
rilasciata la libreria (e non finirò mai di ringraziare tommi caldarola per
'Zombie' - anche se non l'ho mai fatto esplicitamente).

     }
Sì, avevo pensato a qualcosa del genere, infatti nelle ultime righe della
grammatica avevo incominciato ad aggiungere qualche commento sulla struttura
utilizzata, ma niente di ben definito.
Sarebbe persino più divertente aggiungere @x a vari livelli e lasciare
gestire il tutto a un sistema di override magari basato sul contesto*, cioè
sull'albero costituito dalle sezioni attraversate fino a quel momento.
E' incredibile come la combinazione di cose estremamente semplici (se prese
singolarmente) possa esprimere una tale complessità :-)
* il termine contesto, in questo caso, è inteso in modo informatico (preso
in prestito dai metodi di compressione)
Kiuhnm

 AT, andando a intuito. 
posso dire la mia brevemente? Scusa se non commento il tuo lungo messaggio,
ma sono un po' di fretta. 
Un sistema di IF authoring necessita almeno di:
* un parser. Attenzione che questo però non deve fare solo il parsing: deve
anche, ad esempio, fornire errori specifici (sollevare eccezioni se
vogliamo) ben precisi e documentati a seconda dell'errore di parsing
sollevato. Questo è basilare per i messaggi d'errore all'utente, librerie
aggiuntive ecc.
* uno o più file di grammatica (regole sintattiche, il vocabolario non
c'entra nulla)
* un modello evoluto del mondo che permetta di gestire la visibilità degli
oggetti (scope), oggetti contenuti dentro altri (ricorsivamente), qualità
speciali come la trasparenza ecc. 
* una serie di funzioni predefinite per gestire il default dei verbi di
default con gli oggetti generici (bella questa frase)
* un sistema ad eventi: passaggio del tempo, azioni intercettabili generate
dall'utente e dal sistema, NPC, quant'altro. Reazioni (quando l'oggetto
intercetta un verbo di cui è, appunto, l'oggetto).
* infine, un linguaggio vero e proprio che racchiuda tutto ciò e permetta di
implementare la logica dei verbi utilizzabili dall'utente e/o i
comportamenti degli oggetti (due cose un po' reciproche, un po' no, dipende
dai gusti).
* opzionale: una macchina virtuale perfettamente specificata e tante
implementazioni della stessa quante sono le piattaforme che si intendono
supportare. Alternativamente, lo sviluppo di codice totalmente portabile
(impossibile di fatto, se si vogliono includere oggetti come il Game Boy
Advance, i palmari e compagnia bella - e comunque dovresti ricompilare ogni
versione, mica facile)
--------------
Ora, per introdurre innovazione nello sviluppo di IF, si possono fare due
cose:
1) prendere uno di questi aspetti e cambiarlo/migliorarlo. Esempio: librerie
aggiuntive per TADS, Inform e Hugo. in Tads per esempio puoi usare le lib.
di default oppure le World Classes che le sostituiscono completamente e
forniscono anche un nuovo modello di stato (credo, non ne sono affatto
esperto). Sono utilizzabili proprio perché alternative a un pezzo di un
sistema completo (e sono state usate con grande successo da almeno un gioco
"monstre", The Legend Lives!).
Esistono, se non erro, anche diversi parser alternativi di Inform: anche
questi sono utilizzabili perché non richiedono altro che l'inclusione di un
file alternativo a quello di default. Ovviamente è da vedere se poi sono
compatibili a livello, per esempio, di messaggi d'errore (e nota che se non
è così, va a farsi benedire la compatibilità con mille cose, tipo librerie
come scenic.h)
2) sviluppare da zero un sistema nuovo. Kent Tessman l'ha fatto con Hugo, G.
Nelson con Inform. Tads esisteva da prima ed era shareware. Ovviamente poi
esistono tutti gli altri sistemi, ma obiettivamente non sono neanche
lontanamente così completi e versatili (vedere la lista sopra per farsi
un'idea).
-----------------------------
Da questo punto di vista, e focalizzato il problema nel modo corretto
(spero), che cos'abbiamo con Intarsi? un parser (probabilmente da sviluppare
parecchio, ma questo non conta), un linguaggio (diciamo C/Java), una
macchina virtuale (la JVM). manca tutto il resto! E questo "resto" è proprio
ciò a cui facevo riferimento in un messaggio precedente.
Tirando le somme, quindi, è chiaro che è un lavoro titanico, non molto
interessante e sostanzialmente destinato al fallimento sviluppare un nuovo
sistema completo che rivaleggi con quelli esistenti (che vantano dieci o
vent'anni di contributi e testing da parte di programmatori sopraffini).  Ne
consegue che l'unico modo di rendere usabile un nuovo parser (o qualsiasi
altro componente) è implementarlo come alternativa a quello predefinito per
Inform, Tads e Hugo (usando i relativi linguaggi). E questo per mantenere la
propria sanità mentale, non certo per adeguarsi al giogo della becera massa
(che becera non è, perché il discorso che sto facendo lo conosce benissimo e
ragiona di conseguenza).
ora, la "polemica" (che io personalmente non voglio fomentare, anzi in
generale queste cose le odio) nasce dal fatto che mi pare che molti
programmatori generici, bravi quanto volgiamo, non si siano resi conto di
questo po' po' di discorso. Il fatto è che l'IF seria è una bestia
complessa, servono mesi e anni per padroneggiarne i problemi e le
caratteristiche, e questo del tutto indipendentemente dalla propria
esperienza di programmatore generico.
Detto questo, buon lavoro a tutti! E per fortuna che avevo detto che sarei
stato breve... comunque spero che ora sia tutto più chiaro, anche gli
atteggiamenti mentali.
ciao,
S
PS quando dico programmatori bravi, intendo bravi davvero... un parser in
tre giorni, eccheccacchio! complimentoni!

Appena ho visto il messaggio di Mad Dog ho subito cancellato il mio, ma a
quanto pare non ho fatto in tempo (almeno nel tuo caso).
Fai finta che non abbia scritto niente :-)))))))))))))))))

 naturalmente, sto solo cercando di smorzare i toni della polemica).
Non sono uno sprovveduto e so benissimo che il passo da Intarsi a
un'avventura testuale (anche solo dimostrativa) richiede più di 3 giorni
(richiesti da Intarsi), quindi preferisco passare da ignorante :-)
Magari Mad Dog, se ha tempo e voglia, potrà fare qualcosa del genere, ma non
guardare me...ho un programma ben più importante da terminare (importante a
livello di pane/casa/letto ==> sopravvivenza :-) ).

Come disse una volta un calciatore, "sono pienamente d'accordo a metā col
mister". :-)
Mi dispiace tanto, ma veramente tanto, ma mi rifiuto di credere che se uno
voglia scrivere un'avventura testuale in Italia debba per forza impararsi
l'Inform. Sbaglio o per TADS e Hugo non esistono grammatiche e parser in
italiano?
Sono furiosamente contrario al monopolio degli ambienti di sviluppo, per
qualsiasi tipo di applicazione. Io mi sono divertito molto di pių a giocare
all'"Apprendista stregone" che a tanti giochi sviluppati con Inform. Questo
cosa dimostra? Che, come si diceva, č scontato che la chiave stia nel
contenuto.
Detto questo, un poveretto nato in Italia, pieno di idee, che non si vuole
perdere nei meandri di Inform, che alternative ha per scrivere un'AT? Stando
a quello che dici tu, nessuna. E perchč? Perchč Inform esiste da vent'anni.
Beh... anche il COBOL esiste da vent'anni, ma a me viene un conato di vomito
tutte le volte che ne vedo un sorgente.
In seno a questo NG sono nati altri ambienti di sviluppo. Non sono
all'altezza di Inform? Sono state tute perdite di tempo? DIPENDE DAI
CONTENUTI, caro Stefano. Non č vero in assoluto, o forse lo sarā solo per
te. Ti ripeto, sono pių divertenti le avventure di Colombini che tante
schifezze fatte con Inform.
Ora, puoi immaginare un ambiente di sviluppo che supporti un modello del
mondo pių semplice, un sistema di definizione degli eventi pių semplice, uno
scripting pių semplice, e un parser come Intarsi? Io sė, a immaginarlo non
faccio nessuna fatica. Ti dirō di pių, se esistesse forse vedremmo molti pių
giochi d'avventura in giro. Giā, perchč adesso per scriverne uno bisogna
essere all'altezza della complessitā di Inform, non basta avere le idee e i
contenuti. Semplificando lo strumento, abbassi la soglia con cui un
giocatore puō diventare autore, e magari giochi di pių anche tu.
Io credo che lo spirito di Kiuhnm fosse quello di dare uno strumento in pių,
per i programmatori che bazzicano nel NG, nella speranza che qualcuno lo
raccogliesse e tentasse di usarlo per migliorare un po' le cose, Inform o
meno. Ha fatto bene. Doveva postarlo su it.comp.ia? Forse gli avrebbe dato
pių soddisfazione, ma l'applicazione pių immediata dei parser č in questo
NG.
Nessuno puō scrivere un'AT con Intarsi, ma qualcuno puō usare Intarsi per
scrivere o migliorare un ambiente di sviluppo per AT, e un giorno potrai
vedere un'AT cosė:
  >chi cazzo č questo Marco che vuole prendere la tastiera bianca?
  Marco ti risponde: "e a te che cazzo te ne frega!?"
:-) Come diceva uno spot elettorale di un po' di tempo fa, "il futuro ha
radici lontane".
Bye bye.
   Mad Dog

 tre giorni, eccheccacchio! complimentoni!
No, peccato, stavolta non sono riuscito ad arrabbiarmi....mi aspettavo
qualcosa del tipo:
"Ho letto Intarsi e ho disimparato tutto quello che ho appreso in 10 anni di
duro lavoro :-("
(chi ha guardato il grande fratello anche solo 5 minuti al giorno sa di cosa
parlo)


Eccoci, finalmente e' arrivato un esempio pratico. Dunque Intarsi puo' fare
(ha le potenzialita' per fare) questo?
f.

 (ha le potenzialita' per fare) questo?
Sintatticamente e grammaticalmente, assolutamente sě. Semanticamente,
dipende da tutto quello che č ancora da scrivere (o da integrare)... :-)
Ciao!
   Mad Dog

Sto scrivendo il thread su "come funziona Intarsi".
Un po' di pazienza....

 italiano?
guarda che non credo proprio he il buon gaburri abbia scritto questo...
credo (o almeno io ho interpretato cosi') che per scrivere un'at fruibile a
molti (e cioč usando altri strumenti oltre i piedi) necessita di alcuni
"oggetti" che non staro' a ripetere qui e su questo credo che nessuno abbia
a dubitarne...
per cui un novello autore ha 2 possibilita', scegliersi un linguaggio comune
tipo il c o il VB (come ha fatto piu' volte il BaR) e smanettarsi tutto da
solo, oppure usufruire di strumenti gia' creati per le nostre necessita'...
(inform, tads, ecc)
qualunque cosa non rientri nelle 2 sfere non č necessariamente non
accettato, ma semplicemente crea piu' problemi che altro perchč non
direttamente utilizzabile, comporta cioč molto piu' tempo leggere e
comprendere intarsi e adattarlo al proprio scopo piuttosto che imparare le
300 pagine di inform e avere uno strumento potente ma soprattutto completo!
Ovviamente parlo sempre da ignorante, cioč da uno che non ha letto intarsi e
non ha letto il manuale di inform :)
Glorfindel

 direttamente utilizzabile,
rientrano invece negli strumenti direttamente utilizzabili oggetti (come le
librerie italiane di riccardi) che vanno ad ampliare e a migliorare un
qualcosa di gia' completo...
spero di essermi spiegato,
ciao
Glorf

   Marco ti risponde: "e a te che cazzo te ne frega!?"
*aaagh*
dio ce ne scampi...

 utilizzo immediato?
siamo una piccola comunità. Piccolissima a dire il vero, vedi quanta gente
ha postato nelle ultime 2 settimane? Eccoci qui.
Come ha scritto il loro autore, le stesse librerie italiane di Inform (di
uso molto più facile e diretto) ci hanno messo _un anno_ a trovare
un'applicazione concreta... e si trattava solo di includerle in un sistema
esistente.
Mi immagino le belle sensazioni di G.R. in quell'anno... eppure adesso le
cose pian pianino si muovono. capito cosa intendo?
ciao
S
PS per Giovanni: sotto con Infit 2, ché poi c'è da perfezionare la
compatibilità con Glulx! Sotto! LAVORA!  :))

 compatibilità con Glulx! Sotto! LAVORA!  :))
Non ti preoccupare!! Ci sto lavorando. Non serve che anche tu me lo ricordi.
Tutte le volte che mi siedo davanti al computer, mi sembra di avere il
fantasma del Cordella dietro di me che mi dice "Ma quando esce Infit 2?".
Giovanni

 fantasma del Cordella dietro di me che mi dice "Ma quando esce Infit 2?".
LOL

 ha scritto nel messaggio
news:DyNw8.71697$SR5.1...@twister1.libero.it...

C'è anche il mio di fiato!
Ho tradotto "the awkening" e aspetto solo te per pubblicarlo!
Bye

 ha scritto nel messaggio
news:epDw8.73064$m41.1...@twister2.libero.it...


radici lontane".
Bene... qualcuno si dia da fare per sviluppare ulteriormente Intarsi e
poi si vedrà.
Ciao da
Vincenzo

fantasma del Cordella dietro di me che mi dice "Ma quando esce Infit 2?".
Posso aggiungermi anch'io? Altrimenti il Cordella si sente solo... :-)
Ciao da
Vincenzo

> Non è vero, esiste il modulo di Enrico Colombini in basic. 
Sigh.
Il modulo base e' *ufficialmente* obsoleto: non solo la sua struttura e' 
legata ai limiti degli home computer del 1986, ma e' legato a un 
linguaggio proprietario di cui commercialmente non esistono piu' ne' 
compilatori ne' interpreti.
Continuo a pensare se valga la pena di mettere insieme qualcosa di molto 
piu' semplice da usare, non legato a un linguaggio proprietario, 
portatile e capace di produrre eseguibili (se proprio uno ci tiene).
Tecnicamente la cosa e' molto semplice, quello che mi trattiene e':
- Mi interessa poco rifare una cosa che so gia' come fare.
- Ci sono altri strumenti in giro.
- Andrebbe a finire che cercherei di metterci dentro di tutto.
...ma soprattutto:
- Non ho voglia di scrivere il manuale!!!
   .Erix.