Newsgroup: it.comp.software.newsreader
Titolo: [slrn] dipendenza da editor

Mi č venuto il dubbio che mi stia sfuggendo qualcosa...
Quando eseguo un followup o scrivo un nuovo post (quando mi si apre
l'editor - metapad in Windows o gedit in Linux), slrn "si spegne" ed
attende che salvi il msg.
Trovo la cosa /scomoda/ perchč magari vorrei copia/incollare del testo
preso da un altro post (cosa che riesco a fare con qualsiasi altro nr).
Nella mia niubbaggine non sono riuscito a risolvere.
Ciao (e grazie).
-- 
 /   _ _ | Xnews e la documentazione in italiano
( (/( (/ | 
http://web.lacasadialice.it/alanford/

 attende che salvi il msg.
in Linux penso che venga mandato in background (non posso verificare
adesso). prova a sospendere gedit premendo ctrl-z nel term di slrn e dai
%1 seguito da invio al prompt. quando hai fatto con slrn, vai di ctrl-z
e %2 seguito da invio per tornare a gedit.
-- 
.signature: not found

 e %2 seguito da invio per tornare a gedit.
Macché, si è /incasinato/ e ho dovuto killare... (sempre che abbia
capito bene cosa dovevo fare ^^).
Leggendo anche altri vecchi post (in realtà pensavo fosse una
limitazione della versione Windows) capisco che non è di semplice
realizzazione (credevo che usando un editor X si svincolasse come quando
lancio un link con `U').
Approfitto del tuo post per ringraziare ancora te e *k|b|s* della macro
per vedere le Face, che ora ne posso godere :o)
Ciao.


 macro per vedere le Face, che ora ne posso godere :o)
potresti goderne anche su windows... (poi avevo scoperto che esiste un
port di imagemagick; per passare dal base64 a png c'č uudeview)
-- 
.signature: not found
______________________________________________________________________
Yahoo! Mail: 6MB di spazio gratuito, 30MB per i tuoi allegati, l'antivirus, il filtro Anti-spam
http://it.yahoo.com/mail_it/foot/?http://it.mail.yahoo.com/

 preso da un altro post (cosa che riesco a fare con qualsiasi altro nr).
Questo perché altri NUA hanno, di solito, un editor interno.
Ad ogni modo, nulla vieta - su Un*x - un utente secondario (senza login)
con cui lanciare un'altra istanza di SLRN.
+++
La situazione, però, hai ragione: non è ottimale.
La soluzione sarebbe l'implementazione di un sistema di locking atomico
per le operazioni sul file newsrc, al posto dell'attuale "o tutto o
niente", che impone la presenza di una sola istanza di SLRN per utente.
Nei giorni di pioggia di un paio di anni fa avevo iniziato ad
implementare il tutto, per scontrarmi abbastanza vistosamente contro la
gestione del file newsrc all'interno di SLRN (in breve: implementare
operazioni di lettura/scrittura atomiche con locking è decisamente
banale; meno banale è convincere SLRN a rileggere il file senza far
andare a pallino la struttura dati in memoria).
Altra considerazione è che, per come funziona il locking su differenti
sistemi operativo, difficilmente questi sistemi sarebbero realmente
portabili; ergo, sicuramente funzionerebbero su Un*x, ma non potrei
garantire anche su Win32, Amiga, OS/2, etc.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

  Emmanuele.
Approfitto per ringraziarti anche della localizzazione in italiano, mi
fa sentire un tantino più a casa... :)
Ciao.



Ecco, qui mi vergogno un po' #^__^# (già stasera ho imparato che ce n'è
più d'una).
Uso `konsole' (solo perché c'è la bella icona grande ^^), quel post è
stato uno dei primi che ho letto (mi è servito da alibi per scaricare la
colpa...).
Quando posso cerco di usare gli `RPM', ne avevo trovato uno per la MDK9
(già mi sono stretto la mano da solo quando sono riuscito a compilare
prima le slang e poi slrn ^^), ma non sono riuscito a farlo andare.
Nei sorgenti di 
slrn.org
 c'è da sistemare i Makefile con i percorsi (poi
mi sembra sia impostato per la Debian) e io prorpio ancora ci devo
arrivare (leggo qualcosa alla bisogna, mi manca tutto il background, non
posso certo sperare di arrivare a dei risultati ^^).
Ma per ora mi reputo *molto* soddisfatto ;o)


 background, non posso certo sperare di arrivare a dei risultati ^^).
altra cosa strana, i sorgenti non sono impostati per una distro
particolare. è un errore che ti dà il `./configure'?
-- 
.signature: not found

 La situazione, però, hai ragione: non è ottimale.
  In effetti  mi ero spesso domandato  come mai mutt si`  e slrn no...
Non ho capito  molto circa il "locking  atomico", ma se lo  dici tu ti
credo sulla parola... ;)
-- 
Cio` che ho scritto, ho scritto.

 particolare. č un errore che ti dŕ il `./configure'?
Ehm, il `configure' non c'č:
 
http://www.slrn.org/data/slrnface-2.1.1.tar.gz
Nel README dice di aggiustare i percorsi e poi dare il `make'...
Queste sono solo le prime 5 righe (saranno un centinaio) della roba che
mi risponde se lancio il `make' senza modificare il `Makefile':
    [root@localhost slrnface-2.1.1]# make
    cc -O  -o slrnface slrnface.c -L/usr/local/lib -lcompface  -lXt -lX11
    slrnface.c:19:22: X11/Xlib.h: No such file or directory
    slrnface.c:20:27: X11/Intrinsic.h: No such file or directory
    slrnface.c:21:28: X11/cursorfont.h: No such file or directory
    slrnface.c:93: error: syntax error before "my_options"
quindi immagino che mi debba mettere a cercare dove ho la "roba"...
    [luca@localhost /]$ whereis Xlib.h
    Xlib:
e poi? #^__^#
Ciao (ma non sentirti obbligato a rispondere...^^)



e mettilo in `/usr/lib' (o chi per lei).
nota: konsole su debian non setta $WINDOWID, se č anche il tuo caso (dai
`set' al prompt), leggi `doc/Problems' di slrnface.
-- 
.signature: not found

 credo sulla parola... ;)
In pratica, si tratterebbe di rendere "atomiche" la lettura e la
scrittura del file .newsrc (quello su cui ora esiste un "lock di
sessione", che dura per tutta la vita della sessione corrente di SLRN -
per verificarlo, basta vedere che esiste il file ${HOME}/.newsrc-lock
quando SLRN è avviato); per "atomiche" intendo "indivisibili", ovvero:
la scrittura (e la lettura, se necessario) del file devono essere
operazioni fatte in un passaggio, con la garanzia che il file non cambi
da sotto il sedere mentre SLRN lo sta leggendo/scrivendo.
Questo permetterebbe di eliminare il lock di sessione, e di spostarlo
sulla singola operazione.
Il problema è che SLRN ha un meccanismo abbastanza contorto di gestione
del database interno, il che rende difficile aggiornare lo stato dei
gruppi con due sessioni aperte contemporaneamente (con risultati che
vanno dal semplice "fuori sync" al crash spettacolare).
In più, il locking dei file non è una cosa scontata per tutte le
piattaforme su cui deve girare SLRN.
Ergo, la questione è un po' più pelosa del dovuto, e il tempo scarseggia
da queste parti.


 fa sentire un tantino più a casa... :)
De nada.
Sto aspettando che Thomas rilasci la prossima release per aggiornare la
traduzione - sperando di trovare un po' di tempo.


  Ergo, la questione è un po' più pelosa del dovuto,
  Direi proprio... Ma secondo me, perlomano nel caso in questione, non
e`  poi  cosi` importante.  Una  volta  fattaci  la mano,  si  risolve
tranquillamente.
  Ben altre cose, in-vece... Ma non fa nulla.
  A risentirci in tempi piu` "rilassati"... ;)


 msgstr "Sto selezionando %s ..."
  Avrei anche una cosa sull'help, ma mi sa che chiedo troppo...
  My two cents... ;)


 login) con cui lanciare un'altra istanza di SLRN.
Stavo riflettendo su questo argomento.
Mi rendo conto di quello che dici successivamente sulle difficolta` di 
permettere a slrn di aprire due istanze contemporaneamente, ma forse 
c'e` un altro modo per ottenere il risultato voluto.
Per leggere gli altri articoli mentre si risponde e` necessario che 
l'editor sia aperto in un'altra finestra oppure che possa comunicare con 
slrn.
Il primo caso non si puo` fare perche` slrn si aspetta che l'utente gli 
dia l'ok per l'invio dell'articolo, nel secondo caso invece bisogna 
scriversi un editor customizzato per slrn.
Nota: questo modo di procedere andrebbe aggiunto all'attuale e NON 
sostituito.
Io pensavo che si potrebbe prendere la questione da un altro punto di 
vista. Se l'articolo da inviare invece di modificarlo in modalita` 
interattiva (con la conferma finale di slrn) lo modifichiamo salvandolo 
(automaticamente da slrn) come un messaggio postponed si potrebbe aprire 
l'articolo in una finestra separata permettendo ad slrn di poter 
continuare a funzionare per leggere gli altri articoli.
E' ovvio che poi per inviare il messaggio bisogna riprendere l'articolo 
postponed e dirgli di inviarlo. Questo e` da fare per ogni singolo 
articolo. Pero` non dovrebbe essere impossibile da scrivere una macro 
che invia tutti gli articoli postponed. In aggiunta si potrebbe usare 
invece della directory postponed un'altra directory (ad esempio to_send) 
dove vengono messi tutti gli articoli creati in questo modo. 
Sulla questione di aprire piu` instanze di slrn si potrebbe anche fare 
in modo che la prima possa fare quello che vuole mentre le successive 
siano in modalita` read-only cosi` da non creare nessun problema ma 
svolgerebbero benissimo il loro compito.
-- 
| Massimo ;-) -> 
http://maq.altervista.org
        |       (o_        |
|- BABYLON 5  -> 
http://babylon5.altervista.org
   |  (o-  //\   -o)  |
|- STARGATE   -> 
http://sg1screw.altervista.org
   |  (/)_ V_/_ _(\)  |
|- USSTRIBOLO -> 
http://usstribolo.altervista.org
 | POWERED BY LINUX |