Newsgroup: it.comp.software.newsreader
Titolo: [Un po' lungo] Problemi di Xpn 1.0.0 su piattaforme diverse

Ciao a tutti,
vorrei riportare la mia esperienza con questo ottimo newsreader:
A parte il discorso su eventuali nuove funzioni, che dipendono soltanto
dal programmatore, ho purtroppo notato che su tre piattaforme diverse
(Debian, nella versione '4.0 Etch' e Testing 'Lenny' ; Mandriva 2008.1,
Slackware 12) è straordinariamente lento all'avvio, ma solo dopo la
prima configurazione (server news, gruppi, sottoscrizione). In pratica
succede che, in qualunque modo venga avviato, prima di rendersi
disponibile trascorrono almeno 3 min... 
Modi di avvio: 
1) Mediante lancio di un collegamento ad un'applicazione
sul desktop, che punta a xpn.py, senza o con l'aggiunta di python come
comando di avvio. 
2) Mediante konsole: in questo caso il comando viene
dato o con ./xpn.py, o con python xpn.py o anche con python2.5 xpn.py.
In tutti i casi la lucetta dell'hd diventa fissa e nulla accade, fino
a quando dopo i rituali 3/4 min l'interfaccia diventa disponibile. 
Le librerie necessarie risultano correttamente installate su tutte e tre
le distro utilizzate, tanto è vero che il primo avvio (quando ancora
non è stato configurato) è quasi fulmineo. Lanciandolo da Konsole non
viene visualizzato alcun messaggio, né di errore né di informazione:
semplicemente non accade nulla fino a quando non viene caricata
l'interfaccia. I gruppi utilizzati variano da 3 a 5, alcuni anche con
11.000 articoli, pochi o molti watched non cambia. Appena caricato
funziona tutto perfettamente, ma sporadicamente si verificano blocchi,
o chiusure a volte lunghissime che rendono necessario il sigkill del
processo. 
Sottolineo che il newsreader ha ottime funzionalità, e
promette veramente bene, quindi queste non sono critiche: spero
possano servire a qualcosa.. 
Soluzioni possibili? Cappellate
dell'ambiente, su tre piattaforme diverse? Scusate la lunghezza del
post, e grazie a tutti (incoming call 4 Nemesis.. ;) ) quelli che
potranno dare anche solo indicazioni.

 potranno dare anche solo indicazioni.
Senti non credo siano problemi di librerie o altro, altrimenti XPN non
sarebbe partito affatto.
L'unica cosa che mi viene in mente è che 11000 articoli per gruppo
sono tanti. In effetti XPN è lento nello scorrere le liste degli
articoli, ed un tale numero lo può mettere in difficoltà
probabilmente.
Prova a svuotare un po' i gruppi e vedi se noti un miglioramento ...
tuttavia 3 minuti mi sembrano veramente tanti, anche per 11000
articoli.

 > Soluzioni possibili?
per curiosità ...
potresti provare a commentare (con un #) le righe
                        for article in articles.itervalues():
                            if not article.is_read:
                                unread_number=unread_number+1
nella funzione 'show_subscribed' nel file xpn.py.
Dovrebbe essere intorno alla riga 612 (il mio file è un po' cambiato,
ed ora non posso controllare nell'originale).

 nella funzione 'show_subscribed' nel file xpn.py.
Interessante :) Purtroppo nulla č cambiato...
Dopo le modifiche ho avviato ./xpn.py da konsole, e dopo circa 3 min di
attesa inutile l'ho stoppato con CTRL+C (circa 15-20 tentativi)
La finestra di riepilogo errori di xpn č stata questa (il medesimo contenuto
del file errors.dat):
Traceback (most recent call last):
  File "./xpn.py", line 3036, in <module>
    main=MainWin(options.use_home,options.custom_dir)
  File "./xpn.py", line 2963, in __init__
    self.show_subscribed()
  File "./xpn.py", line 600, in show_subscribed
    total=len(articles.keys())
  File "/usr/lib/python2.5/shelve.py", line 92, in keys
    return self.dict.keys()
  File "/usr/lib/python2.5/bsddb/__init__.py", line 252, in keys
    return _DeadlockWrap(self.db.keys)
  File "/usr/lib/python2.5/bsddb/dbutils.py", line 62, in DeadlockWrap
    return function(*_args, **_kwargs)
KeyboardInterrupt
Se puň servire...
[cut]

[cut]
Eh...scusami, non è che proprio nulla è cambiato:
ovviamente è sparito il conteggio degli articoli non letti, ma a parte
questo, il tempo di avvio resta fisso a 3 min...Troppo regolare...

 Interessante :) Purtroppo nulla è cambiato...
[...]
Hmm,
prova a commentare anche quel:
       total=len(articles.keys())
che si trova giusto sopra le righe che hai commentato nella precedente
prova, e lo sostituisci con la riga
       total=0
occhio che l'indentanzione è importante, la riga che aggiungi deve
stare alla stessa indentanzione di quella che commenti ... e non ci
devo essere tab, solo spazi.

        total=len(articles.keys())
[cut]
Sempre più interessante: credo tu abbia centrato il problema.
Il numero degli articoli letti e non letti ora appare 0, ma in
compenso l'avvio si è ridotto a 6.45 sec ;)

Crusader wrote:

Postilla: dopo i cambiamenti, passare ad un altro gruppo inchioda xpn
per almeno 1 min, se il gruppo contiene molti post (gli 11000 di cui
si diceva)...

 si diceva)...
qui impatti purtroppo con i limiti dell'algoritmo di threading, python
è comunque un linguaggio intrepretato, e il threading è comunque
tostarello da fare.
Insomma ripeto, con gruppi con molti articoli xpn in effetti va in
affanno, quindi se non è un problema prova ad impostare un purge più
frequente.
Per quanto riguarda il problema di cui sopra cercherò di farci
qualcosa.

 qualcosa.
Continua pure: il tuo prog è interessantissimo (lo trovo anche, nella
versione 0.7.0, nei repository di Mandriva 2008 :)). 
Se in qualche modo ti sono stato utile, ne sono lieto.
Have a Nice Day

 Se in qualche modo ti sono stato utile, ne sono lieto.
Grazie, ogni aiuto è sempre ben accetto :-)