Newsgroup: it.comp.os.linux.software
Titolo: Slang

Il file .slrnrc e' in Slang. Se do vi .slrnrc giustamente
non lo capisce e non mi evidenzia il linguaggio.
Non so se Vi=Elvis lo farebbe, pero' Mc, cioe' mcedit lo
fa, ma a patto che trovi l'estensione .sl.
Allora io, astutissimo;-)  ho fatto il link:
.
slrnrc.sl
 -> .slrnrc  e cosi', dando mcedit .
slrnrc.sl
,
lo prende e, specie per i commenti, e' tutta un'altra
cosa: molto meglio!
Sapete un modo per evitare estensioni o link, e
specialmente se c'e' per Vi?
-- 
Saluti, Dalet

 non lo capisce e non mi evidenzia il linguaggio.
e` un file di testo semplice; Slang č una libreria che niente ha a che
vedere con i file di configurazione.
Forse ti manca l'attivazione della sintassi in VI (:syntax on).
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Forse ti manca l'attivazione della sintassi in VI (:syntax on).
Ho Elvis, non Vim e mi sembra di poter scegliere solo
tex, html, hex, man per la sintassi senza estensione.
Invece un file .c me lo colora tutto, gli basta leggere
l'estensione.
-- 
Saluti, Dalet

 specialmente se c'e' per Vi?
non farti del male, installa vim e vivi felice.
ciao,
 Emmanuele.

 parole riservate.
lui ha ragione, tu torto.
.sl è un programma scritto con il linguaggio stack-based delle S-Lang;
slrnrc è un file di configurazione che prende in prestito alcune keyword
ma *non* è un programma S-Lang valido.
ciao,
 Emmanuele.

non farti del male, installa vim e vivi felice.
Si': Vim sulla Deb me l'ha evidenziato, m'e' bastato dare
syntax on come m'aveva postato the_Abstract, e approfitto
per ringraziare anche lui.
-- 
Saluti, Dalet

ma *non* è un programma S-Lang valido.
OK, io questo S-Lang non lo conosco neppure... TNX per le info.
-- 
Saluti, Dalet

 sai Slrn non e' molto diffuso
Scherzi?

 OK, io questo S-Lang non lo conosco neppure... TNX per le info.
è il linguaggio interpretato messo a disposizione dalle librerie S-Lang,
che permette di scrivere macro per i programmi che usano queste
librerie, come Jed (editor) e SLRN.
ha addirittura binding per usare le GTK+ e scrivere macro con
interfaccia grafica.
ciao,
 Emmanuele.

Ralph Hinkley wrote:

più che poco diffuso, ormai è nearly-abandoned.  thomas schultz non ha
più tempo, e segue usenet sempre meno.  in più, slrn non supporta
neanche utf-8 - cosa che mi ha costretto ad abbandonarlo.
un vero peccato.
ciao,
 Emmanuele.

un vero peccato.
Si', e mi sa che lo mollo anch'io... ma una macro che mi dici
nell'altro post (le ho appena intraviste) non potrebbe guarirlo?
-- 
Saluti, Dalet

 nell'altro post (le ho appena intraviste) non potrebbe guarirlo?
c'è la possibilità di scrivere un filtro per ogni articolo, far passare
il testo del post attraverso iconv e sostituire l'articolo prima di
visualizzarlo.  probabilmente ammazza la velocità, e devi sapere in
anticipo il charset di partenza e di arrivo - ovvero devi avere una
console impostata con ISO 8859-15 e non in UTF-8.
non è impossibile scriverne una - e forse esiste già da qualche parte o
si può prendere qualcosa di simile e riadattarla; al momento, non ho
installato slrn né un newsserver in locale, quindi non posso
materialmente scriverla.  se serve una mano, mi ricordo ancora qualcosa.
:-)
ciao,
 Emmanuele.
+++
[1] lo scrivo qui perché so che l'autore di XPN legge gli articoli su
icol.* ;-)  seriamente, nemesis: dovresti prenderti uno spazio con cvs o
(meglio) svn e un bug tracing system degno di questo nome, così posso
lamentarmi in maniera costruttiva.  ah: e butta nel cesso nntplib: fa
schifo, dovrebbe essere portata fuori e abbattuta con un colpo alla nuca.

se serve una mano, mi ricordo ancora qualcosa.
TNX! chissa' col tempo che io non ci provi.
Ma penserei piuttosto, visto che son pochissimi gli
articoli in utf8, a qualcosa tipo M r per rot13.
-- 
Saluti, Dalet

(che Emmanuele ha già nominato nel post a cui rispondi)
Si', difficile e da studiarci parecchio, ma molto
interessante, TNX.
Quello che pero' non mi spiego e' perche' son stati
scritti in utf8 se poi non si riesce a leggerli in quel
formato... o almeno: io non ci son riuscito.
-- 
Saluti, Dalet

 formato... o almeno: io non ci son riuscito.
Semplice: in UTF-8 risolvi tutti i problemi di encoding che si hanno con
gli altri charset
Enrico

 schifo, dovrebbe essere portata fuori e abbattuta con un colpo alla nuca.
e che uso al suo posto? me la scrivo io? Twisted resto ancora dell'idea
che non è una alternativa ... a parte il fatto che ami ci vorrebbe
troppo tempo per impararlo.

 troppo tempo per impararlo.
scriverla tu sarebbe una buona opzione; strappala da SLRN e infilaci il
supporto per il main loop delle GLib.  non è complicato: è una state
machine per gestire le risposte del server. :-)
ciao,
 Emmanuele.

 machine per gestire le risposte del server. :-)
Di nuovo, niente C solo pure Python. La soluzione migliore sarebbe
"sbloccare" nntplib, ma non conosco abbastanza bene GTK per farlo.

 mainloop delle GLib.
Scusate un attimo, ma scrivere un thread che si occupa di scaricare i
messaggi tramite nntplib cos'ha che non va come soluzione?
Enrico

Enrico " Henryx " Bianchi wrote:

che un thread non permette di aggiornare l'UI in un altro thread, a meno
di non fare i salti mortali con thread_enter() e thread_leave() per
marcare le sezioni critiche nel codice dell'interfaccia.
in generale, ritengo che l'usare i thread con interfacce grafiche dotate
di un main loop proprio sia un errore grossolano. purtroppo pare che
oggidì, quando ti insegnano a programmare, quando arrivano alle GUI ti
mettono in mano i thread; esattamente come se io vendessi delle lupare
spacciandole per attrezzi per fare sesso virtuale.
le gtk+ hanno un main loop scritto ottimamente; se devo gestire
eventi su un socket tramite polling, io uso quello - non un thread -
dato che mi garantisce che il mio poll() sarà trattato nella stessa
coda di eventi usata dall'interfaccia grafica, evitando di bloccarla.
ciao,
 Emmanuele.

 messaggi tramite nntplib cos'ha che non va come soluzione?
Nulla, se non fosse per il fatto che sono una capra con i thread. In
effetti la parte che scarica la lista dei gruppi è lanciata proprio in
un thread esterno ... ma il codice me lo ha scritto Valentino
(Volonghi). :-)
-- 
Death is the greatest kick of all. That's why they save it for last.
 
 |\ |       |HomePage   : 
http://nem01.altervista.org
 | \|emesis |XPN (my nr): 
http://xpn.altervista.org

 coda di eventi usata dall'interfaccia grafica, evitando di bloccarla.
OK, il tuo ragionamento mi convince ... ma come si fa ad integrare le
chiamate ad nntplib nel main_loop di GTK?
Dovrei usare qualcosa tipo gobject.idle_add ... ma non mi è ben chiaro
come.
-- 
Se dimagro un po' mi sento ancora un bell'uomo. (Pippo Marchioro)


 marcare le sezioni critiche nel codice dell'interfaccia.
Dipende da come sviluppi la cosa. Personalmente metterei un oggetto
contenitore in mezzo (quelli che in Java vengono chiamati Bean), in modo
che, una vota che il thread ha finito le sue operazioni, sincronizzi i
dati contenuti nelle tabelle dei gruppi e dei messaggi (insomma,
utilizzerei una tecnica simile ai semafori tra thread)
Enrico

 come.
è questo il problema. :-)
se fosse in C, aprirei una connessione con un GIOChannel usando il file
descriptor del socket tra te e il NNTP server, e per ogni evento in
ingresso sul canale di comunicazione farei il parse della linea di testo
appena arrivata: se si tratta di una linea di controllo del server,
emetterei un segnale in funzione del codice della linea di controllo
(e.g. "article-follows") e aggiornerei l'UI in funzione del segnale.
questo però richiederebbe la scrittura di una nntplib usando le GLib -
un po' come la mia libreria per i server DICT che uso nel dizionario.
questo si può fare direttamente in python, prendendo parte del codice
dall'attuale nntplib e modificando il ciclo di
connessione/disconnessione per tenere conto dei GIOChannel, e il ciclo
principale che modifica lo stato in funzione delle risposte del server
dovrebbe emettere dei segnali.
una cosa ancora più a basso livello, ma che dubito si possa fare in
python, sarebbe scriversi una GSource che, preso il socket della
connessione, faccia il polling delle linee ogni volta che il main loop
esegue uno spin; un po' come le GDK  (e che Cthulhu mi perdoni
il termine) "slurpano" gli eventi X.  questa l'ho messa in pratica una
volta per leggere gli eventi da un device messo a disposizione dal
kernel 2.4 (prima che arrivasse un event layer degno di tal nome);
soluzione un po' macellaia, ma è quella che si integra meglio con
l'architettura.
ciao,
 Emmanuele.

 utilizzerei una tecnica simile ai semafori tra thread)
il problema sono quelli che usano Java. *grin*
se l'event loop non funziona usando i thread, allora ti troverai con
l'interfaccia che si blocca mentre aspetta che il tuo thread si
sincronizzi; se sei fortunato, e hai fatto le cose per bene con sezioni
critiche corte e sincronizzazioni rapide, allora non lo noterai. 
purtroppo, non va sempre così di lusso, e non appena le sincronizzazioni
impiegano sufficiente tempo per essere concluse, ecco che noterai
piccoli "blocchi" nell'interfaccia.
se usi java, la cui libreria base è priva di un event loop sensato,
allora sei costretto ad usare i thread; ci sono librerie per altri
linguaggi, come GLib per C o i reactor per Perl, che ti permettono di
evitare i thread e i grattacapi che ne conseguono.
ciao,
 Emmanuele.

 se fosse in C, aprirei una connessione con un GIOChannel usando il file
[....]
OK, ho capito che non ci ho capito quasi nulla, sarà il jet-leg (ma
anche no) comunque salvo tutto e mi ripropongo di ritornarci con calma.
:-)
-- 
I'm gettin' out of here. The doctors and nurses are all crazy.
