Calling for testers: scratch/gnus-decoded branch

Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Hello reckless Gnus users!

I'm working on the second half of the refactoring that broke everyone's
Gnus last time -- changing the hash tables to real hash tables, and
group names to decoded strings.

In order to prevent a repeat performance of the last patch, I have a)
been much more careful about testing this one, and b) hope I can talk a
handful of you into helping me test.

Basically you would check out a local copy of the scratch/gnus-decoded
branch, run "make" in it, BACK UP YOUR .newsrc.eld FILE, then restart
Emacs and do what you normally do in Gnus, and see if anything looks
funny. When you're tired of that, switch back to master, run "make"
again, and replace your backup .newsrc.eld file.

I'm particularly interested in testing from people who have groups with
non-ascii names -- that's really the whole crux of this issue.

Remember to back up your .newsrc.eld file! If you forget, it will be
fixable, but Gnus master won't like the decoded non-ascii group names.

Thanks!
Eric

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Hello reckless Gnus users!
>
> I'm working on the second half of the refactoring that broke everyone's
> Gnus last time -- changing the hash tables to real hash tables, and
> group names to decoded strings.
>
> In order to prevent a repeat performance of the last patch, I have a)
> been much more careful about testing this one, and b) hope I can talk a
> handful of you into helping me test.

*examines fingernails*

Re: Calling for testers: scratch/gnus-decoded branch

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> *examines fingernails*

You could maybe also ask on emacs-help.  There are people there that
have lots of time...

Michael.

Re: Calling for testers: scratch/gnus-decoded branch

[Emanuel Berg]

Michael Heerdegen wrote:

>> *examines fingernails*
>
> You could maybe also ask on emacs-help.
> There are people there that have lots of
> time...

Or ask professional computer people, in the
IT-industry! As they work 70+ hours a week they
seem to have even more time...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Emanuel Berg <moasenwood@zoho.eu> writes:

> Michael Heerdegen wrote:
>
>>> *examines fingernails*
>>
>> You could maybe also ask on emacs-help.
>> There are people there that have lots of
>> time...
>
> Or ask professional computer people, in the
> IT-industry! As they work 70+ hours a week they
> seem to have even more time...

Hey Emanuel! You don't seem busy, do you build Emacs from git? Want to
help me test the scratch/gnus-decoded branch?

Re: Calling for testers: scratch/gnus-decoded branch

[Emanuel Berg]

Eric Abrahamsen wrote:

>> Or ask professional computer people, in the
>> IT-industry! As they work 70+ hours a week
>> they seem to have even more time...
>
> Hey Emanuel! You don't seem busy, do you
> build Emacs from git? Want to help me test
> the scratch/gnus-decoded branch?

First, I'm busy. I run a bike repair shop.
It is on a DIY basis, but someone has to
maintain order and see to it every day that its
clean and tools aren't abused and end up it
their right places, clean and operational and
ready to use for the next guy. Here is a couple
of photos [1]. I don't sleep many hours
a night, believe me.

Second, while I'd love to help, I don't know
how to do it in that form. My Gnus is so
super-configured and -extended it would be near
impossible to track what and where an error
would be, if I found one. I don't even know how
to use Gnus without all that extra stuff of
mine. I'd be completely lost.

Feel free to browse my code [2] - I'm sure so
much is redundant (already there, only better)
but when I came to Gnus I had no patience doing
stuff the right way so I solved all issues,
again, DIY style. (Some of it may be good OTOH.
It always worked for me, at least.) But
probably you don't want to do that, because
I know *you* are busy!

So if you think I can contribute to the Gnus
project, rather, is there some thing that is on
the TODO list, but hasn't been done or has been
abandoned/put on hold at an early stage?
Something like that I could do, _maybe_. I make
no guarantees tho...

Keep in mind also that while I'm a decent
programmer in the engineering sense, I don't
really understand what goes on under the hood,
protocols and secure sockets and what have you.
Just tellin'.


[1] https://dataswamp.org/~incal/work-photos
[2] https://dataswamp.org/~incal/emacs-init/gnus

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Emanuel Berg <moasenwood@zoho.eu> writes:

> Eric Abrahamsen wrote:
>
>>> Or ask professional computer people, in the
>>> IT-industry! As they work 70+ hours a week
>>> they seem to have even more time...
>>
>> Hey Emanuel! You don't seem busy, do you
>> build Emacs from git? Want to help me test
>> the scratch/gnus-decoded branch?
>
> First, I'm busy. I run a bike repair shop.
> It is on a DIY basis, but someone has to
> maintain order and see to it every day that its
> clean and tools aren't abused and end up it
> their right places, clean and operational and
> ready to use for the next guy. Here is a couple
> of photos [1]. I don't sleep many hours
> a night, believe me.

I know, I was just being a jerk ;)

> Second, while I'd love to help, I don't know
> how to do it in that form. My Gnus is so
> super-configured and -extended it would be near
> impossible to track what and where an error
> would be, if I found one. I don't even know how
> to use Gnus without all that extra stuff of
> mine. I'd be completely lost.

It's the easiest kind of help I'm asking for -- just turn it on and see
if it explodes! The branch in question has to do with the encoding and
coding of group names. If you have groups with non-ascii names in
particular (accents, etc), it would be helpful just to know if they
display correctly, if you can jump to it, move articles into and out of
them, etc.

I've just pushed another commit to the branch which means you don't have
to backup your .newsrc.eld before testing the branch. I mean, you still
ought to, but the code shouldn't mess with the format of the file.

Anyway, no one has any obligation to spend time on this! It was mean of
me to single you out, it was only because you showed up in the thread :)

Eric

Re: Calling for testers: scratch/gnus-decoded branch

[Emanuel Berg]

Eric Abrahamsen wrote:

> Anyway, no one has any obligation to spend
> time on this! It was mean of me to single you
> out, it was only because you showed up in the
> thread :)

Heh, it is all good :)

Do you have a step by step list what one
should do?

I actually don't compile Emacs manually, tho
I have done it so I know how to do it, but
normally I get it from the repos. This part you
don't have to describe how to do it, just
include in the list if it needs to happen,
I mean.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Emanuel Berg <moasenwood@zoho.eu> writes:

> Eric Abrahamsen wrote:
>
>> Anyway, no one has any obligation to spend
>> time on this! It was mean of me to single you
>> out, it was only because you showed up in the
>> thread :)
>
> Heh, it is all good :)
>
> Do you have a step by step list what one
> should do?
>
> I actually don't compile Emacs manually, tho
> I have done it so I know how to do it, but
> normally I get it from the repos. This part you
> don't have to describe how to do it, just
> include in the list if it needs to happen,
> I mean.

It's fairly straightforward:

1. git clone https://git.savannah.gnu.org/git/emacs.git && cd emacs
2. git checkout scratch/gnus-decoded
3. make
4. cp ~/.emacs.d/.newsrc.eld ~/.emacs.d/.newsrc.eld.bak
5  src/emacs

Then start Gnus, and bang on it as usual. If you do have groups with
non-ascii names, focus on those.

And that's it! If you see anything unusual at all, let me know.
Otherwise, run it until you get bored, and then go back to your usual
setup.

Thanks!
Eric

Re: Calling for testers: scratch/gnus-decoded branch

[Emanuel Berg]

Eric Abrahamsen wrote:

> 1. git clone https://git.savannah.gnu.org/git/emacs.git && cd emacs
> 2. git checkout scratch/gnus-decoded
> 3. make
> [...]

It didn't get past the CC compilation of
sha512.o - probably trashing. I had to
cut power. 'free -h' tells me the RPi3 only has
99M of swap space by default, since I didn't
mess with that.

Will try again on another platform tomorrow,
God willing.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Emanuel Berg <moasenwood@zoho.eu> writes:

> Eric Abrahamsen wrote:
>
>> 1. git clone https://git.savannah.gnu.org/git/emacs.git && cd emacs
>> 2. git checkout scratch/gnus-decoded
>> 3. make
>> [...]
>
> It didn't get past the CC compilation of
> sha512.o - probably trashing. I had to
> cut power. 'free -h' tells me the RPi3 only has
> 99M of swap space by default, since I didn't
> mess with that.
>
> Will try again on another platform tomorrow,
> God willing.

Oof... well, thanks for being game.

Re: Calling for testers: scratch/gnus-decoded branch

[Emanuel Berg]

Eric Abrahamsen wrote:

>> Will try again on another platform tomorrow,
>> God willing.
>
> Oof... well, thanks for being game.

    1. git clone https://git.savannah.gnu.org/git/emacs.git && cd emacs
    2. git checkout scratch/gnus-decoded
    3. make
    4. cp ~/.emacs.d/.newsrc.eld ~/.emacs.d/.newsrc.eld.bak
    5  src/emacs

Results so far:

RPi3 Raspbian 9:
  $ ...
  $ make
  trashing (?) - 'free -h': only 99M swap

SunOS/Solaris 5.10:
  account quota 262M, but cloned emacs dir is 461M

OpenBSD 6.5:
  $ git clone https://git.savannah.gnu.org/git/emacs.git
  "Out of memory, malloc failed (tried to allocate 866440 bytes)"

  $ git clone --depth 1 https://git.savannah.gnu.org/git/emacs.git
  OK, now dir is 193M

  $ git checkout scratch/gnus-decoded
  error: pathspec 'scratch/gnus-decoded' did
  not match any file(s) known to git.

But fear not! I still have one more place to
try it :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Calling for testers: scratch/gnus-decoded branch

[Andy Moreton]

On Wed 29 May 2019, Eric Abrahamsen wrote:

> Hello reckless Gnus users!
>
> I'm working on the second half of the refactoring that broke everyone's
> Gnus last time -- changing the hash tables to real hash tables, and
> group names to decoded strings.
>
> In order to prevent a repeat performance of the last patch, I have a)
> been much more careful about testing this one, and b) hope I can talk a
> handful of you into helping me test.
>
> Basically you would check out a local copy of the scratch/gnus-decoded
> branch, run "make" in it, BACK UP YOUR .newsrc.eld FILE, then restart
> Emacs and do what you normally do in Gnus, and see if anything looks
> funny. When you're tired of that, switch back to master, run "make"
> again, and replace your backup .newsrc.eld file.

If this set of changes modifies the file format of .newsrc.eld then you
need a different strategy to ensure that users can continue to use their
gnus data on both old and new gnus.

This will be needed until all major distros have updated to use newer
emacs, and users have also updated (i.e. several years).

While modernizing the codebase is useful and welcome, user data is
important, and users will not thank you for doing a one-way "upgrade"
to their files which prevents them from using an older gnus on a
different machine.

> I'm particularly interested in testing from people who have groups with
> non-ascii names -- that's really the whole crux of this issue.
>
> Remember to back up your .newsrc.eld file! If you forget, it will be
> fixable, but Gnus master won't like the decoded non-ascii group names.

If the file data is not compatible between old and new gnus, then you
must change approach to use a new filename for the new format and allow
users to continue to use the old format on new gnus (for compatibility
with also running older gnus using the same files).

    AndyM

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Wed 29 May 2019, Eric Abrahamsen wrote:
>
>> Hello reckless Gnus users!
>>
>> I'm working on the second half of the refactoring that broke everyone's
>> Gnus last time -- changing the hash tables to real hash tables, and
>> group names to decoded strings.
>>
>> In order to prevent a repeat performance of the last patch, I have a)
>> been much more careful about testing this one, and b) hope I can talk a
>> handful of you into helping me test.
>>
>> Basically you would check out a local copy of the scratch/gnus-decoded
>> branch, run "make" in it, BACK UP YOUR .newsrc.eld FILE, then restart
>> Emacs and do what you normally do in Gnus, and see if anything looks
>> funny. When you're tired of that, switch back to master, run "make"
>> again, and replace your backup .newsrc.eld file.
>
> If this set of changes modifies the file format of .newsrc.eld then you
> need a different strategy to ensure that users can continue to use their
> gnus data on both old and new gnus.

While I agree with the spirit of this, it's not how Gnus has done things
in the past. There is a `gnus-newsrc-file-version' variable and a
`gnus-convert-old-newsrc' function precisely for changing the file
format following a code upgrade. It's also generally understood that
syncing .newsrc.eld files between machines is risky and unpredictable.
Nor does keeping two copies of the data in different formats sound very
practical -- I don't know of any elisp code that does that.

However! I do agree that this change should probably use the existing
upgrade machinery, which means it would make most sense to hold off
until Gnus ups a version tick. All the tweaking I have in mind for Gnus
will probably warrant some sort of new version, at which point the
upgrade machinery actually prompts to do the conversion, and it should
be very obvious to users that they have a new .newsrc.eld version
(though actually I don't have anything else in mind that will affect
the file format).

So I'll go back to writing non-ascii group names in the gross old
encoding, slightly disappointing as that may be...

Eric

Re: Calling for testers: scratch/gnus-decoded branch

[Tassilo Horn]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> However! I do agree that this change should probably use the existing
> upgrade machinery, which means it would make most sense to hold off
> until Gnus ups a version tick.

Isn't Gnus a part and only a part of emacs nowadays, i.e., no separate
repository anywhere?  In that case, I'd say just go ahead in master so
that it'll hit the masses with Emacs 27.  I don't think many people
switch from a newer emacs to an older one on one machine [1], or use
different emacs versions on different machines but sync their
newsrc.eld.

Bye,
        Tasslio
        
[1] Well, except people like us running the git master and have the
latest release as a fallback.  So probably it would be a good idea to
make Gnus backup newsrc.eld somewhere...

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Tassilo Horn <tsdh@gnu.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> However! I do agree that this change should probably use the existing
>> upgrade machinery, which means it would make most sense to hold off
>> until Gnus ups a version tick.
>
> Isn't Gnus a part and only a part of emacs nowadays, i.e., no separate
> repository anywhere?  In that case, I'd say just go ahead in master so
> that it'll hit the masses with Emacs 27.  I don't think many people
> switch from a newer emacs to an older one on one machine [1], or use
> different emacs versions on different machines but sync their
> newsrc.eld.

That's what I assumed.

Gnus is developed inside Emacs but it has its own version numbers,
though I'm not clear how much they're actually used now, apart from
checking if newsrc.eld is out of date, and updating it.

> Bye,
> Tasslio
>         
> [1] Well, except people like us running the git master and have the
> latest release as a fallback.  So probably it would be a good idea to
> make Gnus backup newsrc.eld somewhere...

It would be a bit tricky to just make _one_ backup -- how do I know if
nothing's been backed up yet, or if it's been backed up but the user has
then deleted the backup? I guess I'd still like to use the built-in
upgrading functions -- at the very least it's nice to prompt the user
and let them know that something's happening. Maybe I can just bump the
Gnus version for wherever it's at when Emacs 27 is released.

Re: Calling for testers: scratch/gnus-decoded branch

[Adam Sjøgren]

Eric writes:

> Basically you would check out a local copy of the scratch/gnus-decoded
> branch, run "make" in it, BACK UP YOUR .newsrc.eld FILE, then restart
> Emacs and do what you normally do in Gnus, and see if anything looks
> funny. When you're tired of that, switch back to master, run "make"
> again, and replace your backup .newsrc.eld file.

I just tried it. Here are my notes.

First start up after switching to scratch/gnus-decoded:

This line is shown as the first group the *Group* buffer:

       *: nntp+fb:feedbase.blog.københavnsskiklub 

Which is unexpected - both the "*" and the placement. I *think* that's
my only nntp-group with a non-ascii name.

None of my non-ascii nnml:-groups show up like that.

I can enter the group, and I can move it to it's rightful place in my
topic hierarchy.

After I quit Gnus and start it again, it shows up with "*" again, but
in the right place in the list of groups.

Pressing "g" doesn't make the "*" go away. Entering the group does.
Pressing "g" after quitting the group doesn't make the "*" return.

Quitting Emacs and starting it again gives the same result,
nntp+fb:feedbase.blog.københavnsskiklub appears with a "*" again.


Doing a dwdiff, this is what has changed:

In gnus-newsrc-alist∵

-("nntp+fb:feedbase.blog.k\303\270benhavnsskiklub" 3 ((1 . 140))
 ((unexist) (seen (1 . 13) 15 (17 . 22) (25 . 26) (28 . 50) (52 . 57)
 (59 . 65) (67 . 80) (82 . 103) (105 . 112) 114 (116 . 117) (119 . 120)
 (123 . 124) (128 . 140))) "nntp:fb")

+("nntp+fb:feedbase.blog.k\303\270benhavnsskiklub" 3 ((1 . 140))
((unexist) (seen (1 . 13) 15 (17 . 22) (25 . 26) (28 . 50) (52 . 57) (59
. 65) (67 . 80) (82 . 103) (105 . 112) 114 (116 . 117) (119 . 120) (123
. 124) (128 . 140))) "nntp:fb")

(i.e. moved a lot down in the file.)

In gnus-topic-alist:

-"nntp+fb:feedbase.blog.k\303\270benhavnsskiklub"

+"nntp+fb:feedbase.blog.københavnsskiklub"


-"nnml:hyskenstr\303\246de"

-"nnml:nyt\303\245rskort-2011" "nnml:nyt\303\245rskort-2012"

+"nnml:hyskenstræde" "nnml:nytårskort-2011" "nnml:nytårskort-2012"


  Hope this helps,

    Adam

-- 
 "Everything needs to change.                                 Adam Sjøgren
  And it has to start today."                            asjo@koldfront.dk

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Adam Sjøgren <asjo@koldfront.dk> writes:

> Eric writes:
>
>> Basically you would check out a local copy of the scratch/gnus-decoded
>> branch, run "make" in it, BACK UP YOUR .newsrc.eld FILE, then restart
>> Emacs and do what you normally do in Gnus, and see if anything looks
>> funny. When you're tired of that, switch back to master, run "make"
>> again, and replace your backup .newsrc.eld file.
>
> I just tried it. Here are my notes.
>
> First start up after switching to scratch/gnus-decoded:
>
> This line is shown as the first group the *Group* buffer:
>
>        *: nntp+fb:feedbase.blog.københavnsskiklub 
>
> Which is unexpected - both the "*" and the placement. I *think* that's
> my only nntp-group with a non-ascii name.
>
> None of my non-ascii nnml:-groups show up like that.
>
> I can enter the group, and I can move it to it's rightful place in my
> topic hierarchy.
>
> After I quit Gnus and start it again, it shows up with "*" again, but
> in the right place in the list of groups.
>
> Pressing "g" doesn't make the "*" go away. Entering the group does.
> Pressing "g" after quitting the group doesn't make the "*" return.
>
> Quitting Emacs and starting it again gives the same result,
> nntp+fb:feedbase.blog.københavnsskiklub appears with a "*" again.
>
>
> Doing a dwdiff, this is what has changed:
>
> In gnus-newsrc-alist∵
>
> -("nntp+fb:feedbase.blog.k\303\270benhavnsskiklub" 3 ((1 . 140))
>  ((unexist) (seen (1 . 13) 15 (17 . 22) (25 . 26) (28 . 50) (52 . 57)
>  (59 . 65) (67 . 80) (82 . 103) (105 . 112) 114 (116 . 117) (119 . 120)
>  (123 . 124) (128 . 140))) "nntp:fb")
>
> +("nntp+fb:feedbase.blog.k\303\270benhavnsskiklub" 3 ((1 . 140))
> ((unexist) (seen (1 . 13) 15 (17 . 22) (25 . 26) (28 . 50) (52 . 57) (59
> . 65) (67 . 80) (82 . 103) (105 . 112) 114 (116 . 117) (119 . 120) (123
> . 124) (128 . 140))) "nntp:fb")
>
> (i.e. moved a lot down in the file.)
>
> In gnus-topic-alist:
>
> -"nntp+fb:feedbase.blog.k\303\270benhavnsskiklub"
>
> +"nntp+fb:feedbase.blog.københavnsskiklub"
>
>
> -"nnml:hyskenstr\303\246de"
>
> -"nnml:nyt\303\245rskort-2011" "nnml:nyt\303\245rskort-2012"
>
> +"nnml:hyskenstræde" "nnml:nytårskort-2011" "nnml:nytårskort-2012"
>
>
>   Hope this helps,

That did help, thanks very much! My quick fix of a few days ago was a
little too quick. I've just added a commit to the branch that should
address this.

Thanks,
Eric

Re: Calling for testers: scratch/gnus-decoded branch

[Adam Sjøgren]

Eric writes:

> That did help, thanks very much! My quick fix of a few days ago was a
> little too quick. I've just added a commit to the branch that should
> address this.

Still got a line with:

         *: nntp+fb:feedbase.blog.københavnsskiklub 

(but at the correct position in the *Group* buffer).


  Best regards,

    Adam

-- 
 "Everything needs to change.                                 Adam Sjøgren
  And it has to start today."                            asjo@koldfront.dk

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Adam Sjøgren <asjo@koldfront.dk> writes:

> Eric writes:
>
>> That did help, thanks very much! My quick fix of a few days ago was a
>> little too quick. I've just added a commit to the branch that should
>> address this.
>
> Still got a line with:
>
>          *: nntp+fb:feedbase.blog.københavnsskiklub 
>
> (but at the correct position in the *Group* buffer).

Bah, that's annoying. Just one out of several groups with non-ascii
names? And before you try this code, all the group names are encoded in
your newsrc.eld file? Like the group above appears as
"nntp+fb:feedbase.blog.k\303\270benhavnsskiklub"?

If you restart Gnus afterwards, is the group activated normally?

Thanks,
Eric

Re: Calling for testers: scratch/gnus-decoded branch

[Adam Sjøgren]

Eric writes:

> Bah, that's annoying. Just one out of several groups with non-ascii
> names?

It's the only nntp group I have with non-ascii name.

I have several nnml groups with non-ascii names, they didn't exhibit
this problem.

E.g. "nnml:hyskenstr\303\246de".

> And before you try this code, all the group names are encoded in your
> newsrc.eld file? Like the group above appears as
> "nntp+fb:feedbase.blog.k\303\270benhavnsskiklub"?

Yes: "nntp+fb:feedbase.blog.k\303\270benhavnsskiklub"

> If you restart Gnus afterwards, is the group activated normally?

I must admit I didn't try that.


  Best regards,

    Adam

-- 
 "Everything needs to change.                                 Adam Sjøgren
  And it has to start today."                            asjo@koldfront.dk

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Adam Sjøgren <asjo@koldfront.dk> writes:

> Eric writes:
>
>> Bah, that's annoying. Just one out of several groups with non-ascii
>> names?
>
> It's the only nntp group I have with non-ascii name.
>
> I have several nnml groups with non-ascii names, they didn't exhibit
> this problem.

Okay, that's useful information. Do you have `gnus-save-newsrc-file' set
to t, and is this group saved in that file? If so, is the group name
encoded or decoded?

(I'm trying to test with feedbase.org but Gnus never succeeds in
connecting to it).

Re: Calling for testers: scratch/gnus-decoded branch

[Adam Sjøgren]

Eric writes:

> Okay, that's useful information. Do you have `gnus-save-newsrc-file' set
> to t, and is this group saved in that file? If so, is the group name
> encoded or decoded?

,----[ C-h v gnus-save-newsrc-file RET ]
| gnus-save-newsrc-file is a variable defined in ‘gnus-start.el’.
| Its value is t
| 
| Documentation:
| Non-nil means that Gnus will save the ‘.newsrc’ file.
| Gnus always saves its own startup file, which is called
| ".newsrc.eld".  The file called ".newsrc" is in a format that can
| be readily understood by other newsreaders.  If you don’t plan on
| using other newsreaders, set this variable to nil to save some time on
| exit.
| 
| You can customize this variable.
`----

I didn't know I had that set to t, but I have.

The file is empty, though?!

  $ ls -l .newsrc
  -rw-r--r-- 1 asjo asjo 0 May 30  2015 .newsrc

> (I'm trying to test with feedbase.org but Gnus never succeeds in
> connecting to it).

(Are you using nntps? There's no nntp-support on feedbase.org, only
nntps. I'm using this in my gnus-secondary-select-methods:

        (nntp "fb"
              (nntp-open-connection-function nntp-open-tls-stream) ; feedbase does not do STARTTLS (yet?)
              (nntp-port-number 563) ; nntps
              (nntp-address "feedbase.org"))

Come to think of it, Feedbase might be doing things wrong with regards
to encoding, as I didn't give it any thought.

I hope I haven't sent you out on a wild goose chase here.)


  Best regards,

    Adam

-- 
 "Everything needs to change.                                 Adam Sjøgren
  And it has to start today."                            asjo@koldfront.dk

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Adam Sjøgren <asjo@koldfront.dk> writes:

> Eric writes:
>
>> Okay, that's useful information. Do you have `gnus-save-newsrc-file' set
>> to t, and is this group saved in that file? If so, is the group name
>> encoded or decoded?
>
> ,----[ C-h v gnus-save-newsrc-file RET ]
> | gnus-save-newsrc-file is a variable defined in ‘gnus-start.el’.
> | Its value is t
> | 
> | Documentation:
> | Non-nil means that Gnus will save the ‘.newsrc’ file.
> | Gnus always saves its own startup file, which is called
> | ".newsrc.eld".  The file called ".newsrc" is in a format that can
> | be readily understood by other newsreaders.  If you don’t plan on
> | using other newsreaders, set this variable to nil to save some time on
> | exit.
> | 
> | You can customize this variable.
> `----
>
> I didn't know I had that set to t, but I have.
>
> The file is empty, though?!

It's only used if your gnus-select-method is an nntp server, and then
only for that server. I thought I remembered that your nntp server was a
secondary one, but I wanted to make sure.

> $ ls -l .newsrc
>   -rw-r--r-- 1 asjo asjo 0 May 30  2015 .newsrc
>
>> (I'm trying to test with feedbase.org but Gnus never succeeds in
>> connecting to it).
>
> (Are you using nntps? There's no nntp-support on feedbase.org, only
> nntps. I'm using this in my gnus-secondary-select-methods:
>
>         (nntp "fb"
>               (nntp-open-connection-function nntp-open-tls-stream) ; feedbase does not do STARTTLS (yet?)
>               (nntp-port-number 563) ; nntps
>               (nntp-address "feedbase.org"))

That's what I was trying to use! Hmm, maybe I was just being too
impatient (and my internet connection sucks here).

> Come to think of it, Feedbase might be doing things wrong with regards
> to encoding, as I didn't give it any thought.
>
> I hope I haven't sent you out on a wild goose chase here.)

I wouldn't think so -- there are so few non-ascii nntp group names out
there, I'm not sure what policy is. And if it worked before my changes,
it should certainly work after! I'll keep trying to connect to feedbase.

Thanks,
Eric

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Adam Sjøgren <asjo@koldfront.dk> writes:
>
>> Eric writes:
>>
>>> Okay, that's useful information. Do you have `gnus-save-newsrc-file' set
>>> to t, and is this group saved in that file? If so, is the group name
>>> encoded or decoded?
>>
>> ,----[ C-h v gnus-save-newsrc-file RET ]
>> | gnus-save-newsrc-file is a variable defined in ‘gnus-start.el’.
>> | Its value is t
>> | 
>> | Documentation:
>> | Non-nil means that Gnus will save the ‘.newsrc’ file.
>> | Gnus always saves its own startup file, which is called
>> | ".newsrc.eld".  The file called ".newsrc" is in a format that can
>> | be readily understood by other newsreaders.  If you don’t plan on
>> | using other newsreaders, set this variable to nil to save some time on
>> | exit.
>> | 
>> | You can customize this variable.
>> `----
>>
>> I didn't know I had that set to t, but I have.
>>
>> The file is empty, though?!
>
> It's only used if your gnus-select-method is an nntp server, and then
> only for that server. I thought I remembered that your nntp server was a
> secondary one, but I wanted to make sure.
>
>> $ ls -l .newsrc
>>   -rw-r--r-- 1 asjo asjo 0 May 30  2015 .newsrc
>>
>>> (I'm trying to test with feedbase.org but Gnus never succeeds in
>>> connecting to it).
>>
>> (Are you using nntps? There's no nntp-support on feedbase.org, only
>> nntps. I'm using this in my gnus-secondary-select-methods:
>>
>>         (nntp "fb"
>>               (nntp-open-connection-function nntp-open-tls-stream) ; feedbase does not do STARTTLS (yet?)
>>               (nntp-port-number 563) ; nntps
>>               (nntp-address "feedbase.org"))
>
> That's what I was trying to use! Hmm, maybe I was just being too
> impatient (and my internet connection sucks here).

Yup, it was both of those. I've managed to connect and test (and confirm
the bug), and just pushed a fix.

Re: Calling for testers: scratch/gnus-decoded branch

[Adam Sjøgren]

Eric writes:

> Adam Sjøgren <asjo@koldfront.dk> writes:
>
>> Eric writes:
>>
>> | gnus-save-newsrc-file is a variable defined in ‘gnus-start.el’.
>> | Its value is t
>>
>> The file is empty, though?!
>
> It's only used if your gnus-select-method is an nntp server, and then
> only for that server. I thought I remembered that your nntp server was a
> secondary one, but I wanted to make sure.

Ah, that explains it - no, I've been using nnnil as my
gnus-select-method for years - I want all my servers to be equal (it's
less confusing that way, besides the generally egalitarian point).

>>               (nntp-port-number 563) ; nntps
>>               (nntp-address "feedbase.org"))
>
> That's what I was trying to use! Hmm, maybe I was just being too
> impatient (and my internet connection sucks here).

Yeah, it's on my cupboard server in Denmark, so it's probably not super
fast from the US.


Eric writes:

>> That's what I was trying to use! Hmm, maybe I was just being too
>> impatient (and my internet connection sucks here).
>
> Yup, it was both of those. I've managed to connect and test (and confirm
> the bug), and just pushed a fix.

Cool!


  Best regards,

    Adam

-- 
 "Zamboni drivers, like athletes, see the Olympics as         Adam Sjøgren
  the pinnacle of their profession."                     asjo@koldfront.dk

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Adam Sjøgren <asjo@koldfront.dk> writes:

> Eric writes:
>
>> Adam Sjøgren <asjo@koldfront.dk> writes:
>>
>>> Eric writes:
>>>
>>> | gnus-save-newsrc-file is a variable defined in ‘gnus-start.el’.
>>> | Its value is t
>>>
>>> The file is empty, though?!
>>
>> It's only used if your gnus-select-method is an nntp server, and then
>> only for that server. I thought I remembered that your nntp server was a
>> secondary one, but I wanted to make sure.
>
> Ah, that explains it - no, I've been using nnnil as my
> gnus-select-method for years - I want all my servers to be equal (it's
> less confusing that way, besides the generally egalitarian point).

I wish I'd done that, back in the beginning. 

>>>               (nntp-port-number 563) ; nntps
>>>               (nntp-address "feedbase.org"))
>>
>> That's what I was trying to use! Hmm, maybe I was just being too
>> impatient (and my internet connection sucks here).
>
> Yeah, it's on my cupboard server in Denmark, so it's probably not super
> fast from the US.

Ha, no wonder! I've used it a fair bit for testing since then, hope I'm
not running up your ISP bills...

Re: Calling for testers: scratch/gnus-decoded branch

[Adam Sjøgren]

Eric writes:

> Adam Sjøgren <asjo@koldfront.dk> writes:
>
>> Yeah, it's on my cupboard server in Denmark, so it's probably not super
>> fast from the US.
>
> Ha, no wonder! I've used it a fair bit for testing since then, hope I'm
> not running up your ISP bills...

Nope, you are welcome to keep going. (The rate is flat.) The only caveat
is that the nntpd is home grown.


  Best regards,

    Adam

-- 
 "Jeg kan s'guda gøre hvad fanden jeg vil."                   Adam Sjøgren
 "Nej, du kan ej, du er 40!"                             asjo@koldfront.dk

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Adam Sjøgren <asjo@koldfront.dk> writes:

> Eric writes:
>
>> Adam Sjøgren <asjo@koldfront.dk> writes:
>>
>>> Yeah, it's on my cupboard server in Denmark, so it's probably not super
>>> fast from the US.
>>
>> Ha, no wonder! I've used it a fair bit for testing since then, hope I'm
>> not running up your ISP bills...
>
> Nope, you are welcome to keep going. (The rate is flat.) The only caveat
> is that the nntpd is home grown.

Impressive! I might not use it for protocol tests, though I'm sure
you've followed all the RFCs. :)

Re: Calling for testers: scratch/gnus-decoded branch

[Adam Sjøgren]

Eric writes:

> I might not use it for protocol tests, though I'm sure you've followed
> all the RFCs. :)

Yes, especially the "rough consensus and working code"-part.


  :-),

   Adam

-- 
 "Spelar det längre någon roll / Jag orkar inte slåss         Adam Sjøgren
  Det är bortom min kontroll"                            asjo@koldfront.dk

Re: Calling for testers: scratch/gnus-decoded branch

[Eric Abrahamsen]

Adam Sjøgren <asjo@koldfront.dk> writes:

> Eric writes:
>
>> Bah, that's annoying. Just one out of several groups with non-ascii
>> names?
>
> It's the only nntp group I have with non-ascii name.
>
> I have several nnml groups with non-ascii names, they didn't exhibit
> this problem.

Okay, that's useful information. Do you have `gnus-save-newsrc-file' set
to t, and is this group saved in that file? If so, is the group name
encoded or decoded?

(I'm trying to test with feedbase.org but Gnus never succeeds in
connecting to it.)