Newsgroup: it.comp.os.linux.software
Titolo: slrn bug?

Uso slrn 0.9.7.4 con tutte le patch ufficiali disponibili. Ho visto la
nuova snapshot ma nel readme non parla del problema che riscontrato,
vabbe` la provero` lo stesso.
Il bug si verifica quasi sempre alla pressione di tasti ben precisi,
ovvero:
- entro in un ng (uno a caso)
- apro un messaggio
- uso la freccia a destra
- premo f per rispondere al messaggio
A questo punto slrn crasha quasi sempre soprattutto se il messaggio ha
linee lunghe che rimangono visibili dopo avere premuto nel tastierino
la freccia a destra.
Non mi sembra di aver letto nulla riguardo a questo bug, e` un
problema solo mio oppure capita anche a qualcun'altro?
-- 
Massimo  ;-)  | EMail: 
q-con...@iol.it
 * ICQ: 37930285
--------------> 
http://digilander.libero.it/MaQ
  BABYLON5  --> 
http://digilander.libero.it/babylon5
  *TRIBOL*  --> 
http://digilander.libero.it/usstribolo

  la freccia a destra.
Parli di 'linee lunghe': forse non hai abilitato il "wrapping"
nell'editor di slrn. Controlla se in /etc/news/slrn.rc (o dir simile)
hai queste righe:
% editor per i messaggi del ng
set editor_command "vim -c 'set tw=72 nobackup' +%d '%s'"
(se vuoi usare vim come editor)
Spero ti aiuti a risolvere.
Ciao,
	Ennio.
-- 
[Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo.    \\?//
 Fa' qualche cosa di cui non sei capace!"   (diceva Henry Miller) ]    (°|°)
                                                                        )=(

 problema solo mio oppure capita anche a qualcun'altro?
Sulla ML di SLRN non ne ho mai sentito parlare...
Ad ogni modo, mi servirebbero:
	- versione delle libslang
	- utilizzo (news o spool?)
	- terminale utilizzato (console o emulatore sotto X? e quale?)
Se riesci, prova a far passare SLRN attraverso strace, e manda 
il dump in caso di crash (solo le ultime linee, così evito il macello...
:-))
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 il dump in caso di crash (solo le ultime linee, così evito il macello...
select(4, [3], NULL, NULL, {10, 0})     = 1 (in [3], left {9, 470000})
read(3, "\33", 1)                       = 1
select(4, [3], NULL, NULL, {1, 0})      = 1 (in [3], left {1, 0})
select(4, [3], NULL, NULL, {10, 0})     = 1 (in [3], left {10, 0})
read(3, "O", 1)                         = 1
select(4, [3], NULL, NULL, {1, 0})      = 1 (in [3], left {1, 0})
select(4, [3], NULL, NULL, {10, 0})     = 1 (in [3], left {10, 0})
read(3, "C", 1)                         = 1
select(4, [3], NULL, NULL, {0, 0})      = 0 (Timeout)
write(1, "\33[9;1H\33[1m\33[37m\33[44m\33[K\n\33[K\n\33[K\n"..., 264) = 264
select(4, [3], NULL, NULL, {10, 0})     = 1 (in [3], left {7, 940000})
read(3, "f", 1)                         = 1
stat("/home/m/.followup", {st_mode=S_IFREG|0600, st_size=1116, ...}) = 0
open("/home/m/.followup", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
fstat(5, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4021a000
stat("/home/m/.signature", {st_mode=S_IFREG|0644, st_size=214, ...}) = 0
open("/home/m/.signature", O_RDONLY)    = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=214, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4021b000
read(6, "Massimo  ;-)  | EMail: q-continu"..., 4096) = 214
read(6, "", 4096)                       = 0
close(6)                                = 0
munmap(0x4021b000, 4096)                = 0
write(5, "Newsgroups: it.comp.os.linux.sof"..., 1692) = 1692
close(5)                                = 0
munmap(0x4021a000, 4096)                = 0
rt_sigprocmask(SIG_BLOCK, [INT QUIT TSTP TTIN TTOU WINCH], [], 8) = 0
ioctl(3, SNDCTL_TMR_STOP, {B38400 opost isig icanon echo ...}) = 0
close(3)                                = 0
write(1, "\33[?9l\33[38;1H\33[44m\33[K", 20) = 20
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
La chiusura di slrn avviene subito dopo che premo "f" per rispondere
al messaggio seguendo la procedura descritta in precedenza. L'errore
l'ho ricavato dal comando strace provando a rispondere al tuo
messaggio.


 +++ killed by SIGSEGV +++
Sembrerebbe un problema di scrittura sul terminale.
Può darsi che sia proprio un problema di slang + konsole...



Io non ho il wrapping attivato, e non succede nulla lo stesso. 

 problema solo mio oppure capita anche a qualcun'altro?
Che si sia qualche bug per via di combinazione di tasti io ne sono sicuro,
gia' due volte slrn e' entrato in loop infinito a seguito della pressione
accidentale di piu' tasti.
Purtroppo non so quali tasti ho premuto e non ho mandato un bug-info al
programmatore di slrn :(
cmq ora faccio piu' attenzione ai tasti premuti, in modo da informare 
chi di dovere con la massima precisione :) 

 installato.
Problema risolto! Ho scaricato da rpmfind l'ultima versione della
slang la 1.4.5, l'ho installata, ho creato un link simbolico ed il
problema e` sparito. Ora slrn non crasha piu`, almeno dalle prime
prove che ho effettuato. Domani daro` in pasto il pc a Eugy che se lo
spupazzera` per bene e se ci sono ancora problemi sono sicuro che li
trovera`. :)
Pero` strano perche` nel changelog delle slang non mi pare di aver
visto nulla che potesse riguardare un simile problema... boh... forse
il pacchetto 1.4.4 della SuSE era bacato?
Prima di aggiornare avevo provato anche con xterm al posto di Konsole
ma il problema si e` ripresentato. Quindi mi sento di escludere che
dipenda dal terminale.
Grazie per i consigli e la pazienza. :)


 Grazie per i consigli e la pazienza. :)
Ma ti pare...


 come un unico spool.
Eccellente. Esattamente cio` che servirebbe.


 slrn... quasi quasi faccio uno studio di fattibilita`.
Ti risparmio lo studio... :-)
Sarebbe possibile riscrivendo l'intero SLRN: le funzioni generiche sono
comunque troppo agganciate alle librerie slang. Bisognerebbe esportare
tutte le funzioni logiche assegnate ai newsgroup in una libreria a
parte, e scriversi differenti front-end, come fanno adesso per alcune
applicazioni scritte usando le GTK+.


 adesso per alcune applicazioni scritte usando le GTK+.
Da come ne parli sembra un'impresa. Se solo avessi piu` tempo libero.
:)
Hmmm... proprio in questi giorni ho trovato un piccolo bug: posso fare
il postponed di un articolo usando nel nome di file alcuni spazi, ma
quando vado a rieditarlo con vim non ce la faccio a causa degli spazi.
Questo succede quando non imposto nulla nella variabile editor_command
del file di configurazione. Per farlo funzionare correttamente devo
impostare:
set editor_command "vim +%d '%s'"
Cosi` funziona e va bene, pero` sarebbe preferibile che nelle
impostazioni standard sia gia` a posto.
Ma il +%d non mi funziona, indaghero`...
Un'ultima cosa. Sai se c'e` un modo, senza modificare i sorgenti,
per impostare di default il nome del file dei messaggi postponed a
subject+data? Si puo` fare da slrn? Negli hook non ho visto nulla che
possa aiutare. Temo che dovro` farlo da vim ma non lo conosco granche`
bene.


 bene.
Non credo si possa fare con una macro, ma non ne sono sicuro.
Sto ravanando nei sorgenti, per aggiungere un `postponed_format' che
permetta di creare un nome di file di default, con la possibilità di
usare una stringa formattata (ad esempio, %h per hostname, %y per anno,
%m per mese, etc). Potrebbe essere utile anche per altre cose, e,
infatti, era da un po' che volevo mettermi a scriverla...


 infatti, era da un po' che volevo mettermi a scriverla...
Ehm, come al solito mi sono lasciato prendere un po' la mano, ed ho
fatto qualcosa in più... ^^;;;
Ho aggiunto la variabile `postpone_file_format', che permette di creare
un modello di default, ad esempio:
	set postpone_file_format "article-%u_%Y%m%d_%T"
che viene espanso:
 
	%u:	username
	%Y:	anno (4 cifre)
	%m:	mese (2 cifre)
	%d:	giorno (2 cifre)
	%T:	ora (HH:MM:SS)
ed in più, ci sono:
 
	%h:	hostname
	%H:	ora (24)
	%M:	minuti
	%S:	secondi
[ma ho intenzione di aggiungere altri codici per l'espansione], che è,
se non ho sbagliato, la cosa che volevi fare tu.
+++
Dato che la funzione mi piaceva, l'ho messa a disposizione di SLRN, e ho
aggunto la possibilità di fare un lavoro del genere:
 
	% salva i post e i follow-up in base alla data (anno-mese)
	set save_posts "News/My_Posts-%Y%m"
 
	% salva le reply via mail in base alla data (anno-mese)
	set save_replies "News/My_Replies-%Y%m"
il tutto senza "rompere" all'indietro le configurazioni attuali (ovvero,
il resource file può rimanere esattamente così com'è).
In questo modo, posso far fare a SLRN lo stesso lavoro che faccio con
mutt (archivio la posta in uscita per data), e alleggerisco il lavoro
che deve fare mutt quando apro la mia outbox di SLRN.
+++
A questa, va aggiunta la patch per collassare i sotto-thread, che ho già
messo online e già inviato a Thomas...
La patch attuale per il file_format la metto online stasera: intanto,
vedrò se riesco ad aggiungere altri codici di espansione utili.


 infatti, era da un po' che volevo mettermi a scriverla...
Rispondo qui anche per il messaggio successivo.
Non so come ringraziarti!!! E' bastato chiedere e la patch e` arrivata
subito. :)
Purtroppo pero` ho trovato qualche problema. Lasciami provare ancora
un po` e poi ti mando un feedback completo. L'ho applicata all'ultima
snapshot.


 snapshot.
Infatti, ho dovuto fare un paio di correzioni che non ho ancora messo
online, perché sto facendo un po' di test `in casa'... Comunque, manda
pure, così vedo se ci sono cose che non ho visto, e correggo prima di
mandarla a Thomas.


 [2002-09-23 19:55]:
Trovato: era un'incomprensione tra me e strcat.
Metto online la versione aggiornata...


 correggo prima di mandarla a Thomas.
Ho gia` visto la nuova versione, che e` migliore della precedente, ma
ho notato ancora dei problemi. In pratica vengono ignorati tutti i
caratteri che non sono i codici per la formattazione. Anzi li mette
solo ad inizio stringa e poi basta. Ho guardato i sorgenti e ho capito
cosa non va. Ti mando in mail la micro patch (e' una sola riga ^^;).


 differente.
Allora, l'unica è scriversi un piccolo parser in Perl che faccia il
lavoraccio. Come base, c'è Cleanscore...
Una cosa intelligente da fare, sarebbe esportare le funzioni di
Cleanscore in un modulo Perl (SLRN::Score, abbinato, magari, a
SLRN::Config)... Se avrò un po' di tempo, vedrò che si può fare.
