filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (10/01/89)
I have been working on some patches to rrn. The base version of rrn that I'm
working from claims to be rn patchlevel 40, with the rrn patches applied to it.
What is rn patch 40? All the ftp sites seem to have rn patchlevel 39. I
grabbed ucbvax:/pub/rrn.39.tar.Z; the local version differs only slightly, in
files common.h, rcln.c and respond.c. At the end of this message are shortened
diffs of those three files, local copy vs. ucbvax patchlevel 39 sources.
Would someone please confirm that the changes represent patchlevel 40 and that
it's a valid patch...
The patches I'm working on improve rrn's use of NNTP, improving both user
speed and network bandwidth requirements. I would like to know how to
dispose of them when they are complete -- send to comp.sources.unix, Larry
Wall, whoever the current Keeper of NNTP is, or what? Someone please mail
me some guidance on this.
Also, this rrn suffers from an annoying bug, which I seem to remember
seeing mention of a patch for, but cannot find anything about: When joining
a new group, if there is an ancient (Expires:) message followed by a large
number of expired messages, rrn will catch up the entire group rather than
finding the first existing article. We had another rrn version, unfortunately
sans source, that did not do this. Watching the NNTP stream, it appears to
be giving up after several HEADs fail consecutively. Is there a patch for
this? Where can I find patches, if any, later than the original rn->rrn
diffs?
Thanks in advance. Diffs of ucbvax:39 vs. local:40 follow...
In common.h, all occurences of ".UUCP" were removed;
In rcln.c,
***
! *(rcline[ngnum] + rcnums[ngnum] - 1) = rcchar[ngnum];
---
! {
! char c = rcchar[ngnum];
! *(rcline[ngnum] + rcnums[ngnum] - 1) = c;
! }
In respond.c,
***
if (chdir(spool)) {
! #else not SERVER
if (chdir(spool) || chdir(ngdir)) {
- #endif SERVER
printf(nocd,ngdir) FLUSH;
---
if (chdir(spool)) {
! printf(nocd,spool) FLUSH;
! #else
if (chdir(spool) || chdir(ngdir)) {
printf(nocd,ngdir) FLUSH;
+ #endif /* !SERVER */
***
if (chdir(spool)) {
! #else not SERVER
if (chdir(spool) || chdir(ngdir)) {
- #endif SERVER
printf(nocd,ngdir) FLUSH;
---
if (chdir(spool)) {
! printf(nocd,spool) FLUSH;
! #else
if (chdir(spool) || chdir(ngdir)) {
printf(nocd,ngdir) FLUSH;
+ #endif /* !SERVER */
Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112
@ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months]
R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (10/09/89)
In article <47.filbo@gorn.santa-cruz.ca.us> I wrote: >I have been working on some patches to rrn. The base version of rrn that I'm >working from claims to be rn patchlevel 40, with the rrn patches applied to it. >What is rn patch 40? All the ftp sites seem to have rn patchlevel 39. [...] I received exactly one reply on this, pointing me to decwrl, jpl-devvax and one other site, to get PL 41. So far so good... >The patches I'm working on improve rrn's use of NNTP, improving both user >speed and network bandwidth requirements. I would like to know how to >dispose of them when they are complete -- send to comp.sources.unix, Larry >Wall, whoever the current Keeper of NNTP is, or what? Someone please mail >me some guidance on this. Apparently NOBODY has anything to say on this. Is rrn considered completely dead in light of nn? Does nobody care about local net bandwidth? How about the occasional >remote< rrn user? >[I thought I heard of a patch for this, but can't find it: if you join a >group which has a large gap between a single "Expires" article and the next >real article, rrn skips the entire group. We had an rrn that didn't do >this, but the source was lost. The NNTP stream makes it seem that rrn tries >several HEAD commands and gives up when they fail. WHERE can I find a patch >for this, or any other patches to the original rn->rrn diffs?] Nothing at all on this, either. Would one of the news "gurus" at least mail me that they >DON'T< know so that I can give up gracefully? Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112 @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945
brian@ucsd.Edu (Brian Kantor) (10/09/89)
The author of 'rn', Larry Wall, has publicly stated that he isn't going to do any more work on 'rn'. Rather, he is (in his limited free time) in the process of writing a new news reader. Perl grew out of that effort. My guess is when/if this new newsreader is available, it'll blow all the others out of the water. In the meantime, I know of no one collecting patches or taking maintenance responsibility for 'rn'. It is essentially a mature product with a few minor bugs. Or maybe you can consider it an orphan, if that makes you feel better. I suspect that if you were to publish bugfixes in comp.sources.bugs, or put them out somewhere for FTP retrieval, people would be grateful. But I doubt you'll ever see any more official patches for 'rn'. - Brian
jw@pan.UUCP (Jamie Watson) (10/10/89)
>I received exactly one reply on this, pointing me to decwrl, jpl-devvax and one >other site, to get PL 41. So far so good... Hmmm. I just checked, and I have rn at patchlevel 40. I don't recall seeing a patch 41; was there one posted that I missed? If so, does anyone (preferably in Europe) have a copy of it that they could send me? Thanks, jw
karl@ficc.uu.net (Karl Lehenbauer) (10/12/89)
In article <10049@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes: >The author of 'rn', Larry Wall, has publicly stated that he isn't going >to do any more work on 'rn'. Rather, he is (in his limited free time) >in the process of writing a new news reader. Perl grew out of that effort. >In the meantime, I know of no one collecting patches or taking >maintenance responsibility for 'rn'. It is essentially a mature >product with a few minor bugs. Or maybe you can consider it an orphan, >if that makes you feel better. rn is showing its age a bit. PL40 came out years ago. If there is a patch 41, somebody please mail it to me. I have been doing a bit of hacking on rn, myself. For example, sitenames are hardcoded to tag a .UUCP on the end, which is definitely wrong. Also, the Configure stuff screws up on Sys V/386 because it thinks it understands that readdir() is there but it isn't actually compatible. The method rn uses for backtracking to determine the current directory doesn't work properly by default if you're over a network like OpenNET where this is a sort of node prequalifier. Finally, if your uname or hostname gives a wrong answer, rn will use them even if you tell it not to (and it may not always ask, either). (Oh yeah, some minor things, too, like Pnews doesn't know about alt groups, so it doesn't have something quite pithy enough to say about them when you're trying to post to alt, like it does for 'most everything else.) Is anyone else working on rn? I would like to coordinate updates with them if so. I would be willing to produce a new patch for rn. Would anybody use it? Should I try to get lwall's blessing, or what? -- -- uunet!ficc!karl "The last thing one knows in constructing a work is what to put first." -- Pascal
epsilon@wet.UUCP (Eric P. Scott) (10/12/89)
rn PL 41 may be a false alarm... dec's "41" file is really a mislabeled 40. The jpl copies are divergent (you don't want them--stick with ones from backbone sites). Look for some rn patches here soon. Note that the rrn patches distributed with nntp 1.5.6 include some rn bug fixes mixed in with the clientlib interfacing. -=EPS=-
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/15/89)
In article <10049@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes:
: The author of 'rn', Larry Wall, has publicly stated that he isn't going
: to do any more work on 'rn'. Rather, he is (in his limited free time)
: in the process of writing a new news reader. Perl grew out of that effort.
Well, sort of. It actually grew out of trying to do distributed configuration
management using the news system. I needed something to navigate around
the articles and print out reports, and awk wasn't up to it, so...
But 'tis true the new one will be prototyped in perl, at least.
And 'tis also true that I'm not working on the old rn any more. People told
me that the innards were too, um, "intricate", and they were right. Rn is
a trifle organic. (But then again, so's your brain!)
: My guess is when/if this new newsreader is available, it'll blow all
: the others out of the water.
I guess I can fool some of the people all of the time... :-)
: In the meantime, I know of no one collecting patches or taking
: maintenance responsibility for 'rn'. It is essentially a mature
: product with a few minor bugs. Or maybe you can consider it an orphan,
: if that makes you feel better.
Let's say it's been kicked out of the house. But the dirty laundry keeps
coming back.
: I suspect that if you were to publish bugfixes in comp.sources.bugs, or
: put them out somewhere for FTP retrieval, people would be grateful. But
: I doubt you'll ever see any more official patches for 'rn'.
I suspect you're right.
Larry Wall
lwall@jpl-devvax.jpl.nasa.govnews@laas.laas.fr (USENET News System) (10/24/89)
In article <10049@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes: | The author of 'rn', Larry Wall, has publicly stated that he isn't going | to do any more work on 'rn'. Thanks Larry, for rn! | In the meantime, I know of no one collecting patches or taking | maintenance responsibility for 'rn'. It is essentially a mature | product with a few minor bugs. Or maybe you can consider it an orphan, | if that makes you feel better. | | I suspect that if you were to publish bugfixes in comp.sources.bugs, or | put them out somewhere for FTP retrieval, people would be grateful. I assume that there are many sites that run rn/rrn. If so, we should post patchs to rn/rrn in comp.sources.bugs in order to iron out those "minor bugs." I've found a number for rrn's script files: basically annoyances that can be gotten around, but why reinvent the wheel each and every time. Cheers to all, Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph If all else fails, try: SOBEK@FRMOP11.BITNET sobek@eclair.Berkeley.EDU =============================================================================== Upon the instruments of death the sunlight brightly gleams. -- King Crimson
tower@bu-cs.BU.EDU (Leonard H. Tower Jr.) (10/28/89)
In article <457@laas.laas.fr> ralph@laas.laas.fr (Ralph P. Sobek) writes: || In the meantime, I know of no one collecting patches or taking || maintenance responsibility for 'rn'. It is essentially a mature || product with a few minor bugs. Or maybe you can consider it an orphan, || if that makes you feel better. || || I suspect that if you were to publish bugfixes in comp.sources.bugs, or || put them out somewhere for FTP retrieval, people would be grateful. | |I assume that there are many sites that run rn/rrn. If so, we should |post patchs to rn/rrn in comp.sources.bugs in order to iron out those |"minor bugs." I've found a number for rrn's script files: basically |annoyances that can be gotten around, but why reinvent the wheel each |and every time. It would be really nice if one person became the unofficial 'official' maintainer of rn, and: - either started issuing patchs from patchelevel 40 or incremented the version number and started a new patch series. - interface with Stan Barber to coordinate rrn/rn. It might be wise to start from rrn and insure it builds properly for either NNTP or spool based news systems. Could those of you who have expressed interest, talk via e-mail and decide who should do this. Consider: - who has the most time to devote to rn maintenance. - who has the most experience with the rn code. - who has the best computing facilities. - who has the most stable job situtation and net access. Good luck with keeping ego's out of the discussion. ;-} I have most of the ad hoc patches saved, and be willing to mail them to the designated maintainer. thanx -len