Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.tlc.cellulari.android > #111681 > unrolled thread

*NeReO* 1.3.7 - eccola!

Back to article view | Back to it.tlc.cellulari.android

Contents

  *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-15 11:24 +0200
    Re: *NeReO* 1.3.7 - eccola! Macchia <TOGLIMI_la.macchia.nera@gmail.com> - 2026-09-15 12:11 +0000
    Re: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-15 17:39 +0200
      Re: *NeReO* 1.3.7 - eccola! Macchia <TOGLIMI_la.macchia.nera@gmail.com> - 2026-09-16 07:17 +0000
    Re: *NeReO* 1.3.7 - eccola! Bingo3331 <invalid@invalid.com> - 2026-09-15 16:06 +0000
      Re: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-15 18:24 +0000
      Re: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-17 17:01 +0200
        Re: *NeReO* 1.3.7 - eccola! Bingo3331 <invalid@invalid.com> - 2026-09-17 16:20 +0000
    Re:*NeReO* 1.3.7 - eccola! BIG Umberto <user@2130706433ZX.invalid> - 2026-09-18 01:05 +0200
      LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-18 12:00 +0200
        Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! BIG Umberto <user@2130706433.invalid> - 2026-09-18 12:14 +0000
          Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-18 16:06 +0200
            Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! BIG Umberto <user@2130706433.invalid> - 2026-09-18 19:32 +0000
            Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! BIG Umberto <user@2130706433.invalid> - 2026-09-18 21:44 +0000
              Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-18 21:47 +0000

#111681 — *NeReO* 1.3.7 - eccola!

Su SourceForge (oppure aspettate l'avviso in app ;)
https://sourceforge.net/projects/nereo/files/1.3.7/

Nasce da due segnalazioni di Dave Royal sul ripristino del backup.
Una era giusta, e il difetto era piu' esteso di quanto avesse visto.

  * Il ripristino non duplica piu' filtri e identita'. Lui aveva
    notato che i filtri venivano AGGIUNTI invece che sostituiti;
    guardando il codice e' emerso che le IDENTITA' avevano lo stesso
    difetto. Il ripristino e' ora IDEMPOTENTE: ripristinare due volte
    lo stesso file lascia esattamente lo stesso stato. I filtri si
    riconoscono da nome, campo, tipo di confronto, pattern e ambito
    dei gruppi; le identita' dal nickname, che il formato di backup
    usava gia' come chiave per rilegare i server.
  * Il ripristino ora chiede come procedere: Unisci o Sostituisci. Il
    difetto vero non era "aggiunge invece di sostituire": era che
    nella stessa operazione l'app faceva TRE cose diverse (dedup su
    server e sottoscrizioni, inserimento cieco su filtri e identita',
    sovrascrittura sulle impostazioni). Nessuna delle due opzioni
    tocca server, sottoscrizioni o articoli scaricati: cancellare un
    server porterebbe via con se' i suoi gruppi e i suoi messaggi.
  * "Password errata" non copre piu' gli errori di importazione. Il
    dialogo decifrava E importava in un unico blocco protetto: un
    guasto nel secondo passo veniva annunciato come un problema del
    primo, mandando a cercare la causa sbagliata.

-- 
          .:. MCSM .:.
-> posting from PC with MesNews <-

[toc] | [next] | [standalone]

#111682

MCSM ha usato le manine per scrivere su it.tlc.cellulari.android:
> Su SourceForge (oppure aspettate l'avviso in app ;)
> https://sourceforge.net/projects/nereo/files/1.3.7/
> 
> Nasce da due segnalazioni di Dave Royal sul ripristino del backup.
> 
Test


-- 
Messaggio inviato. 
(by NeReO 1.3.7)

[toc] | [prev] | [next] | [standalone]

#111685

On 15/09/2026 , *MCSM* wrote:
> Su SourceForge (oppure aspettate l'avviso in app ;)
> https://sourceforge.net/projects/nereo/files/1.3.7/

Se qualcuno la sta già provando, la riscarichi (guardare ora post!)
La precedente 1.3.7 aveva un problemino dovuto alla fretta...

-- 
          .:. MCSM .:.
-> posting from PC with MesNews <-

[toc] | [prev] | [next] | [standalone]

#111689

MCSM ha usato le manine per scrivere su it.tlc.cellulari.android:
> On 15/09/2026 , *MCSM* wrote:
> > Su SourceForge (oppure aspettate l'avviso in app ;)
> > https://sourceforge.net/projects/nereo/files/1.3.7/
> 
> Se qualcuno la sta già provando, la riscarichi (guardare ora post!)
> La precedente 1.3.7 aveva un problemino dovuto alla fretta...
> 
Fatto 

-- 
Gerrymanderati. 
(by NeReO 1.3.7)

[toc] | [prev] | [next] | [standalone]

#111686

MCSM ha scritto:
> Su SourceForge (oppure aspettate l'avviso in app ;)
> https://sourceforge.net/projects/nereo/files/1.3.7/
> 

Ho trovato un bug ...
Se in "manutenzione"--> "intestazioni per sincronizzazione" e'
selezionato "tutti i messaggi" con determinati news server ad alta
ritenzione e determinati newsgroup non viene scaricato nessun messaggio
e si riceve l'errore "Response block exceeded the 67108864 byte limit:
aborted".
Soluzioni proposte: rimuovere il limite oppure scaricare i messaggi che
rientrano in questo limite.

Come riprodurre l'errore:
(1) Selezionando in "manutenzione"--> "intestazioni per
sincronizzazione", "tutti i messaggi"
(2) Su Astraweb sottoscrivere "alt.free.newsservers"
(3) Entrare nel newsgroup o provare a scaricare i messaggi del newsgroup
"alt.free.newsservers " da Astraweb.

L'errore si evita selezionando un limite di messaggi (per esempio 1000
in manutenzione).

-- 
Posted from 
NeReO 1.3.7
Pacchetto: org.openusenet.reader
news.astraweb.com

[toc] | [prev] | [next] | [standalone]

#111687

Bingo3331 , torturando le sue meningi, ha scritto:
> MCSM ha scritto:
> > Su SourceForge (oppure aspettate l'avviso in app ;)
> > https://sourceforge.net/projects/nereo/files/1.3.7/
> > 
> 
> Ho trovato un bug ...
....
> L'errore si evita selezionando un limite di messaggi (per esempio 1000
> in manutenzione).

Questo non è un bug! Sei tu che provi cose astruse! lol
-- 
.:. MCSM .:.
posting with NeReO 1.3.7

[toc] | [prev] | [next] | [standalone]

#111699

On 15/09/2026 , *Bingo3331* wrote:
> MCSM ha scritto:
>> Su SourceForge (oppure aspettate l'avviso in app ;)
>> https://sourceforge.net/projects/nereo/files/1.3.7/
>> 
>
> Ho trovato un bug ...
> Se in "manutenzione"--> "intestazioni per sincronizzazione" e'
> selezionato "tutti i messaggi" con determinati news server ad alta
> ritenzione e determinati newsgroup non viene scaricato nessun messaggio
> e si riceve l'errore "Response block exceeded the 67108864 byte limit:
> aborted".
> Soluzioni proposte: rimuovere il limite oppure scaricare i messaggi che
> rientrano in questo limite.
>
> Come riprodurre l'errore:
> (1) Selezionando in "manutenzione"--> "intestazioni per
> sincronizzazione", "tutti i messaggi"
> (2) Su Astraweb sottoscrivere "alt.free.newsservers"
> (3) Entrare nel newsgroup o provare a scaricare i messaggi del newsgroup
> "alt.free.newsservers " da Astraweb.
>
> L'errore si evita selezionando un limite di messaggi (per esempio 1000
> in manutenzione).

Nella 1.4 sarà (anzi *è* ) sistemato anche questo! (Test in progress)

-- 
          .:. MCSM .:.
-> posting from PC with MesNews <-

[toc] | [prev] | [next] | [standalone]

#111700

MCSM ha scritto:
> >
> > L'errore si evita selezionando un limite di messaggi (per esempio
> > 1000
> > in manutenzione).
> 
> Nella 1.4 sarà (anzi *è* ) sistemato anche questo! (Test in progress)
> 
Ok. Grazie!! :-)

-- 
Posted from 
NeReO 1.3.7
Pacchetto: org.openusenet.reader
news.astraweb.com

[toc] | [prev] | [next] | [standalone]

#111705

MCSM <despammed@mcsm.anonaddy.me> ha scritto:
> Su SourceForge (oppure aspettate l'avviso in app ;)
> https://sourceforge.net/projects/nereo/files/1.3.7/
> 

Dunque...
Gruppo it.test.
Visualizzasioni raggruppate.
Vedo una discussione "Trascrizione degli audio"  con omino e
 numero 2, ma non ho mai partecipato.
Infatti la apro (42 messaggi) ed io non ci sono infatti...
Apro l'albero della discussione e pure lí, giustamente, non ci sono.
Altra discussione, sempre su it.test, "fandanghef sii la mai AI"
 omino con numerino 2, mai partecipato.

Il motivo te lo dico io, si basa sul fatto che la mail del Barone
 è uguale a quella mia predefinita (solo la parte mail), che non
 uso ed ho impostato per occupare la voce.

Ho sempre settato quello switch di non aggiornare.
Quando replico ad una discussione, e faccio invio o annullo
 l'invio, si porta sempre al primo post della discussione, anche
 se io avevo replicato al 23esimo.

-- 
(p) Societa Cibernetica Sirio (SCS)

[toc] | [prev] | [next] | [standalone]

#111711 — LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola!

On 18/09/2026 , *BIG Umberto* wrote:
....
> Dunque...
> Gruppo it.test.
> Visualizzasioni raggruppate.
> Vedo una discussione "Trascrizione degli audio"  con omino e
>  numero 2, ma non ho mai partecipato.
> Infatti la apro (42 messaggi) ed io non ci sono infatti...
> Apro l'albero della discussione e pure lí, giustamente, non ci sono.
> Altra discussione, sempre su it.test, "fandanghef sii la mai AI"
>  omino con numerino 2, mai partecipato.
> Il motivo te lo dico io, si basa sul fatto che la mail del Barone
>  è uguale a quella mia predefinita (solo la parte mail), che non
>  uso ed ho impostato per occupare la voce.
>
> Ho sempre settato quello switch di non aggiornare.
> Quando replico ad una discussione, e faccio invio o annullo
>  l'invio, si porta sempre al primo post della discussione, anche
>  se io avevo replicato al 23esimo.

Ti copio qui sotto la risposta di Claude (lunga!)
Ti richiede anche un test, prima di intervenire...

Ho verificato entrambe sui sorgenti della 103. **Codice non toccato.**

**L'omino — Umberto ha ragione, e il codice gli dà ragione alla 
lettera.**
`reloadIdentityEmails()` costruisce `myEmails` come unione delle email 
di *tutte* le identità salvate, senza alcun legame con il server o il 
gruppo.
L'identità segnaposto è quindi attiva ovunque, e se un utente reale di 
it.test posta da quell'indirizzo ogni sua discussione diventa «una 
discussione in cui ho scritto».
Il numero 2 accanto all'omino, va detto, non sono i post suoi: è 
`repliesToMe`, le risposte ai miei post — coerente col resto, ma lui 
l'ha letto come «2 miei post»,
e in effetti quel numero non ha nessuna etichetta.

Questo caso **non si chiude stringendo il confronto**: gli indirizzi 
sono identici, nessun criterio può distinguerli.
Il rimedio *a costo zero*, subito e senza release, sarebbe quello di 
cambiare l'indirizzo di quell'identità inutilizzata con uno che non può 
esistere.
La RFC 2606 riserva il dominio `.invalid` proprio per questo, quindi 
`segnaposto@nereo.invalid` non collide con nessuno per costruzione.

**Verificando, però, è saltato fuori un difetto che Umberto non poteva 
vedere, e questo è serio.**
`eMioPost` è stata irrobustita nella 1.2.12 dopo l'audit — non cerca 
più l'indirizzo come sottostringa della riga From, lo estrae e lo 
confronta
ma **quella correzione non è mai arrivata nei tre punti che calcolano 
l'omino e `replyToMe`**: `ThreadFlatten` (albero e raggruppata) e 
`Repository` al sync usano ancora
`fromField.lowercase().contains(email)`.
Sei posti, due famiglie, tre con il criterio nuovo e tre con quello che 
l'audit aveva rimosso.
Il commento che tu stesso hai sopra `eMioPost`, scritto alla 1.2.11, 
diceva che:
"un criterio duplicato in quattro punti è esattamente il modo in cui i 
quattro punti finiscono per divergere": sono divergenti.
Conseguenze aperte oggi: `From: "umberto@suodominio.it" 
<chiunque@altrove.net>` fa scattare omino e conteggio.
E un indirizzo corto scatta dentro uno lungo (`mario@tin.it` dentro 
`supermario@tin.it`).

**Il ritorno al primo post.**
In `ArticleScreen` l'articolo mostrato sta in `var currentId by 
remember { mutableStateOf(articleId) }` — un `remember` semplice, 
seminato dall'argomento di rotta.
Spostarsi al 23° messaggio è un movimento interno allo schermo, non una 
nuova destinazione; ma andare alla schermata di risposta toglie 
`ArticleScreen` dalla composizione,
e al ritorno Navigation ripristina solo ciò che è `rememberSaveable`.
`currentId` riparte quindi da `articleId`, cioè l'articolo aperto dalla 
lista: la testa della discussione.
`ThreePaneHome` ha lo stesso schema per `selectedArticleId`, quindi se 
è questo il difetto si vede anche nei pannelli.
(Deduzione dal codice più il comportamento di Navigation-Compose.)

La sua (di BIG Umberto) precisazione sull'interruttore di aggiornamento 
è utile e scagiona il sospettato ovvio:
col sync spento la lista non cambia sotto i piedi, eppure la posizione 
si perde.
E il fatto che *invio* e *annulla* si comportino identici punta 
all'unica cosa che hanno in comune, il ritorno indietro.

NOTA:
Prima di toccare un `remember`, però, chiederei a BIG Umberto **una 
prova che può smentirmi**:
aprire il 23° messaggio, andare in una qualsiasi altra schermata e 
tornare indietro, senza rispondere.
Se salta lo stesso, la diagnosi è confermata; se salta **solo** dopo 
una risposta, la mia spiegazione è incompleta e va cercato altro.
Una correzione basata su un'ipotesi non verificata è già costata a 
questo progetto più di una consegna.

I piani per entrambi sono nel documento che ho scritto nel progetto.
In sintesi: per l'omino, rimedio `.invalid` subito e allineamento dei 
tre punti a `eMioPost` appoggiato alla prima release che esce per altri 
motivi,
perché i due casi che chiude sono di sicurezza, non di comodità;

per la posizione, la prova di BIG Umberto e poi `rememberSaveable`, con 
il rischio dichiarato da verificare (entrando in un articolo diverso si 
deve partire da quello nuovo,
non dal valore salvato).

-- 
          .:. MCSM .:.
-> posting from PC with MesNews <-

[toc] | [prev] | [next] | [standalone]

#111713 — Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola!

MCSM in date 18/09/2026 12:00 write:
> On 18/09/2026 , *BIG Umberto* wrote:
> ....
> > Dunque...
> > Gruppo it.test.
> > Visualizzasioni raggruppate.
> > Vedo una discussione "Trascrizione degli audio"  con omino e
> >  numero 2, ma non ho mai partecipato.
> > Infatti la apro (42 messaggi) ed io non ci sono infatti...
> > Apro l'albero della discussione e pure lí, giustamente, non ci sono.
> > Altra discussione, sempre su it.test, "fandanghef sii la mai AI"
> >  omino con numerino 2, mai partecipato.
> > Il motivo te lo dico io, si basa sul fatto che la mail del Barone
> >  è uguale a quella mia predefinita (solo la parte mail), che non
> >  uso ed ho impostato per occupare la voce.
> >
> > Ho sempre settato quello switch di non aggiornare.
> > Quando replico ad una discussione, e faccio invio o annullo
> >  l'invio, si porta sempre al primo post della discussione, anche
> >  se io avevo replicato al 23esimo.
> 
> Ti copio qui sotto la risposta di Claude (lunga!)
> Ti richiede anche un test, prima di intervenire...
> 
> Ho verificato entrambe sui sorgenti della 103. **Codice non toccato.**
> 
> **L'omino — Umberto ha ragione, e il codice gli dà ragione alla 
> lettera.**
> `reloadIdentityEmails()` costruisce `myEmails` come unione delle email
> di *tutte* le identità salvate, senza alcun legame con il server o il 
> gruppo.
> L'identità segnaposto è quindi attiva ovunque, e se un utente reale di
> it.test posta da quell'indirizzo ogni sua discussione diventa «una 
> discussione in cui ho scritto».
> Il numero 2 accanto all'omino, va detto, non sono i post suoi: è 
> `repliesToMe`, le risposte ai miei post — coerente col resto, ma lui 
> l'ha letto come «2 miei post»,
> e in effetti quel numero non ha nessuna etichetta.
> 
> Questo caso **non si chiude stringendo il confronto**: gli indirizzi 
> sono identici, nessun criterio può distinguerli.
> Il rimedio *a costo zero*, subito e senza release, sarebbe quello di 
> cambiare l'indirizzo di quell'identità inutilizzata con uno che non
> può
> esistere.
> La RFC 2606 riserva il dominio `.invalid` proprio per questo, quindi 
> `segnaposto@nereo.invalid` non collide con nessuno per costruzione.
> 



Ma sia io che il Barone abbiamo:
invalid@invalid.invalid
Per esattezza:
From: il barone severo ma giusto <invalid@invalid.invalid>
e
From: xxxxx <invalid@invalid.invalid>

Il test dovrebbe essere su nik+mail.



> **Verificando, però, è saltato fuori un difetto che Umberto non poteva
> vedere, e questo è serio.**
> `eMioPost` è stata irrobustita nella 1.2.12 dopo l'audit — non cerca 
> più l'indirizzo come sottostringa della riga From, lo estrae e lo 
> confronta
> ma **quella correzione non è mai arrivata nei tre punti che calcolano 
> l'omino e `replyToMe`**: `ThreadFlatten` (albero e raggruppata) e 
> `Repository` al sync usano ancora
> `fromField.lowercase().contains(email)`.
> Sei posti, due famiglie, tre con il criterio nuovo e tre con quello
> che
> l'audit aveva rimosso.
> Il commento che tu stesso hai sopra `eMioPost`, scritto alla 1.2.11, 
> diceva che:
> "un criterio duplicato in quattro punti è esattamente il modo in cui i
> quattro punti finiscono per divergere": sono divergenti.
> Conseguenze aperte oggi: `From: "umberto@suodominio.it" 
> <chiunque@altrove.net>` fa scattare omino e conteggio.
> E un indirizzo corto scatta dentro uno lungo (`mario@tin.it` dentro 
> `supermario@tin.it`).
> 




> **Il ritorno al primo post.**
> In `ArticleScreen` l'articolo mostrato sta in `var currentId by 
> remember { mutableStateOf(articleId) }` — un `remember` semplice, 
> seminato dall'argomento di rotta.
> Spostarsi al 23° messaggio è un movimento interno allo schermo, non
> una
> nuova destinazione; ma andare alla schermata di risposta toglie 
> `ArticleScreen` dalla composizione,
> e al ritorno Navigation ripristina solo ciò che è `rememberSaveable`.
> `currentId` riparte quindi da `articleId`, cioè l'articolo aperto
> dalla
> lista: la testa della discussione.
> `ThreePaneHome` ha lo stesso schema per `selectedArticleId`, quindi se
> è questo il difetto si vede anche nei pannelli.
> (Deduzione dal codice più il comportamento di Navigation-Compose.)
> 
> La sua (di BIG Umberto) precisazione sull'interruttore di
> aggiornamento
> è utile e scagiona il sospettato ovvio:
> col sync spento la lista non cambia sotto i piedi, eppure la posizione
> si perde.
> E il fatto che *invio* e *annulla* si comportino identici punta 
> all'unica cosa che hanno in comune, il ritorno indietro.
> 
> NOTA:
> Prima di toccare un `remember`, però, chiederei a BIG Umberto **una 
> prova che può smentirmi**:
> aprire il 23° messaggio, andare in una qualsiasi altra schermata e 
> tornare indietro, senza rispondere.
> Se salta lo stesso, la diagnosi è confermata; se salta **solo** dopo 
> una risposta, la mia spiegazione è incompleta e va cercato altro.
> Una correzione basata su un'ipotesi non verificata è già costata a 
> questo progetto più di una consegna.
> 
> I piani per entrambi sono nel documento che ho scritto nel progetto.
> In sintesi: per l'omino, rimedio `.invalid` subito e allineamento dei 
> tre punti a `eMioPost` appoggiato alla prima release che esce per
> altri
> motivi,
> perché i due casi che chiude sono di sicurezza, non di comodità;
> 
> per la posizione, la prova di BIG Umberto e poi `rememberSaveable`,
> con
> il rischio dichiarato da verificare (entrando in un articolo diverso
> si
> deve partire da quello nuovo,
> non dal valore salvato).
> 


Sono con discussioni raggruppate, le uniche schermate possibili sono
visualizza albero e visualizza impostazioni.
Ed aprendole non cambia nulla, resto nel messaggio visualizzato.
Faccio replica poi freccia indietro, quindi annullo la pagina e sono al
primo post.

Nelle altre 2 viste, non si sposta nulla.



Una cosa che avavo visto già un paio di versioni fa e non riuscivo a
replicare, oggi l'ho capita.

Gruppo it.test, discussioni raggruppate cellulare.
Ieri sera finito di leggere,Attivo discussioni tutte lette.
Questa nattina apro nereo, apro  il gruppo, faccio aggiorna.
Mi dice 19 messaggi nuovi.
Ma resta tutto verde.
Scrollo tutto il gruppo e sono tutti verdi.
Esco dal gruppp e rientro e compaiono i messaggi rossi.
La cosa l'avevo notata, ma non ero sicuro anche facendo: entrata gruppo,
tutti verdi aggiorna, tutti verdi, apertura discussione e uscita
discussione, che vedo i messaggi rossi.
Provo altri gruppi, ma funziona bene.
Sembrerebbe solo la prima volta.
It test di solito è il primo gruppo che guardo, non necessariamente il
colpevole.
Un dubbio è che mi sembra, di aver visto un comportamento analogo, di
aggiornamento durante la giornata, ma non ho la certezza asdoluta.


Totto verde, entro in una discussione con un mio messaggio fatto pochi
minuti prima, lo rileggo e scopro una cazzata, faccio il supersede e
invio, la discussione viene aggiornata, compare un messaggio rosso, esco
dalla discussione e compare nella lista il mio messaggio rosso.
Lo switch di blocco aggiornamenti è sempre attivo. Questo in una delle
recenti versioni.


-- 
(n) Societa Cibernetica Sirio (SCS)

[toc] | [prev] | [next] | [standalone]

#111716 — Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola!

On 18/09/2026 , *BIG Umberto* wrote:

Cuttone generale.
Potresti per cortesia fare le prove elencate in questo TXT?

https://ogy.de/zhmr
(short link ad un file txt hostato su un mio account Mega.nz)
Non volevo tediare tutt! ;)

Poi hai 2 opzioni....
1 - mi scrivi in privato
2 - riporti la tabella con i numeri richiesti qui

Grazie in anticipo per l'eventuale tua collaborazione.
NOTA: il testo è frutto di un ragionamento fatto con Claude, per 
venirne a capo!

Di nuovo grazie!
PS: se qualcun altro vuole cimentarsi è il benvenuto, eh! ;) ^^

-- 
          .:. MCSM .:.
-> posting from PC with MesNews <-

[toc] | [prev] | [next] | [standalone]

#111721 — Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola!

MCSM in date 18/09/2026 16:06 write:
> On 18/09/2026 , *BIG Umberto* wrote:
> 
> Cuttone generale.
> Potresti per cortesia fare le prove elencate in questo TXT?
> 
> https://ogy.de/zhmr

ASPETTA HO ANNULLATO LA RISPOSTA PERCHÈ VOGLIO FARE UN PAIO DI TEST SU
UN ALTRO GRUPPO ED UN ALTRO SERVER.
POI TI SPIEGO.


-- 
(n) Societa Cibernetica Sirio (SCS)

[toc] | [prev] | [next] | [standalone]

#111722 — Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola!

MCSM in date 18/09/2026 16:06 write:
> On 18/09/2026 , *BIG Umberto* wrote:
> 
> Cuttone generale.
> Potresti per cortesia fare le prove elencate in questo TXT?
> 
> https://ogy.de/zhmr

Hai 2 mail.

-- 
(n) Societa Cibernetica Sirio (SCS)

[toc] | [prev] | [next] | [standalone]

#111723 — Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola!

BIG Umberto , torturando le sue meningi, ha scritto:
> MCSM in date 18/09/2026 16:06 write:
> > On 18/09/2026 , *BIG Umberto* wrote:
> > 
> > Cuttone generale.
> > Potresti per cortesia fare le prove elencate in questo TXT?
> > 
> > https://ogy.de/zhmr
> 
> Hai 2 mail.
> 
Grazie.
Domani vedo

-- 
.:. MCSM .:.
posting with NeReO 1.4

[toc] | [prev] | [standalone]

Back to top | Article view | it.tlc.cellulari.android

csiph-web