trn-workers

Please move trn discussion to github

[Richard <leg...@xm...>]

Hi All,

I'm still working towards an official release of trn 5.0 at the end of
2025.  I think it's more appropriate to have any discussions of trn
going forward on the discussions page for my trn repository.

<https://github.com/LegalizeAdulthood/trn/discussions>

I've created a 5.0 milestone to track what's going into that release.
I believe all the UTF-8 enhancements created by @acli have been
integrated into this release.

Thanks,

-- Richard

-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

Github CI running clean on linux/Windows

[Richard <leg...@xm...>]

Hi trn fans,

It's been a while since I poked at this code, so I came back to it
over the weekend and made the following progress:

- Github CI (continuous integration) builds running green on linux & Windows
  <https://github.com/LegalizeAdulthood/trn/actions>
- All tests are passing on Windows
- 4 tests on linux report about a leaked mock from gmock
  I've seen this occasionally at work and I believe it to be either a
  bug in gmock when a method returns a mock by shared_ptr or I'm not
  using gmock correctly in this scenario [always possible :)].
  Interestingly enough, the "leaked mock" is only reported on linux.
  For now I've suppressed the 4 tests on linux in the CI build.  The
  logic exercised actually passes, it's just marked as a failure
  because gmock complains about the "leaked" mock.
- CMakePresets.json added to simplify configure/build/test workflows
- Source files moved into subdirectories;
  Now the main directory doesn't contain a giant pile of files.
- .editorconfig support added

I think the code should be working reasonably well at this point, but
I need to do some integration testing.  In order for other people to
assist with that, I'm going to work on creating installers with CPack
next.

Then releases can start being posted to github and people can try
things out and give me feedback in an orderly manner.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

Re: trn's threading

[Eli t. B. <sou...@el...>]

Richard wrote:
> I will switch the code to use the standard OVER command at some point.
> First I need to add an "NNTP conversation" test harness mechanism to
> be able to cover the existing NNTP implementation with tests before
> making changes.

How timely. I've recently encountered a SEGFAULT in the overview code.
I'm looking a comp.mobile.android where a spammer (three of last two
hundred articles locally) is using simply ginormous References headers
and the NNTP server I use has naively merged the folded-over-29-lines
value into one entry of about 2900 bytes, well over the 1000-ish byte 
limit you could expect in days of yore.

https://www.rfc-editor.org/rfc/rfc3977#section-3.1

Says "[t]his document does not place any limit on the length of a line
in a multi-line block.  However, the standards that define the format of
articles may do so."

https://www.rfc-editor.org/rfc/rfc5536#section-2.2

Says "[c]ompliant software MUST NOT generate (but MAY accept) header
field lines of more than 998 octets.  This is the only limit on the
length of a header field line prescribed by this standard."

I think a strict reading of the BNF in 3977 supports that overview
headers fall under that 5536 limit of 998 octets, but splitting the spec
across two RFCs does complicate matters.

These articles are segfaulting for me during killfile operate-on-
References-headers-actions in trn4-p77, the acli trn fork and your trn
fork. Specifically I look for certain domain names in references and
autoselct. What I'm seeing is the long references line smash the stack.

An example backtrace looks like:

#0  0x00007c8bf3d9c061 in strlen () from /usr/lib/libc.so.12
#1  0x0000000000417a3f in dointerp (
    dest=0x6acd40 <filename> "@googlegroups.com> <d4f...@go...> <b22...@go...> <f50...@go...> <511c4858-"..., destsize=1, pattern=0x6a23a2 <killglobal+2> "/KILL",
    stoppers=0x0, cmd=0x0) at intrp.c:933
#2  0x0000000000453020 in filexp (s=0x6a23a0 <killglobal> "%p/KILL") at util2.c:92
#3  0x0000000000419f58 in open_kfile (local=0) at kfile.c:733
#4  0x0000000000418fc8 in kill_unwanted (starting=102277,    
    message=0x47d178 "Processing memorized commands...\n\n", entering=1) at kfile.c:367
#5  0x000000000041f9bf in do_newsgroup (
    start_command=0x6acca8 <nullstr> "<591...@go...> <dc4...@go...> <a41...@go...> <d4f3f15c-9a03-4c5d-a672-b435"...) at ng.c:174
#6  0x000000000045021e in input_newsgroup () at trn.c:772
#7  0x000000000044f29d in do_multirc () at trn.c:334
#8  0x000000000044ec19 in main (argc=1, argv=0x7f7fff9a2688) at trn.c:158

Elijah

trn's threading

[Richard <leg...@xm...>]

Hi Team,

So while doing a little sleuthing last night, I discovered that trn
has a bunch of support for an antiquated threading data mechanism.

rt-mt.cpp: mt_init() has XTHREAD and raw thread file support
<https://github.com/LegalizeAdulthood/trn/blob/cmake/rt-mt.cpp#L117>

They both obtain the same (binary) data, one via NNTP and the other
via a local file.  XTHREAD is an old NNTP extension that delivers
threading information in a format specific to trn.  The OVER command
obsoletes the XTHREAD and XOVER commands in NNTP as described in RFC
3977 (Oct-2006).

I'm going to drop the code that supports these binary thread files,
whether obtained through NNTP or via local files.  My local news
server doesn't support XTHREAD, but I still have threading in trn, so
it must be getting thread information via XOVER in rt-ov.cpp.

I will switch the code to use the standard OVER command at some point.
First I need to add an "NNTP conversation" test harness mechanism to
be able to cover the existing NNTP implementation with tests before
making changes.

Cheers,

-- Richard

-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

acli's tests integrated; all tests passing on Linux/Windows

[Richard <leg...@xm...>]

Hi Team,

I've integrated my changes on top of acli's UTF8 improvements and
migrated all of acli's tests to gtest.  I've added some more tests of
my own as well.

I've been building under WSL to check the linux configuration.  Trn's
code is so old that it predates linux and comes from that time in unix
history when every unix was a little bit different and POSIX system
calls hadn't yet been standardized.  Later, linux adopted a POSIX API
but deprecated some system calls like gtty/stty.

Linux also pretends to have both <termio.h> and <termios.h>, but if
you examine <termio.h> it tells you to use the <termios.h> header
instead.  So I have removed all conditionally compiled code for
gtty/stty and <termio.h> and left only the <termios.h>/MSDOS branches.
However, I think something in there was enabling raw output on MSDOS
because now I see raw ESC codes in the Windows console instead of the
codes applying effects :).  That's probably not a big deal to fix, but
I haven't fixed it yet.

Using CMake's configure_file to generate test file inputs has a nice
advantage that you can generate headers/source files from the smae
CMake variables.  That means that you can use symbolic names for test
data that should match instead of having magic values/strings that have
to be kept in sync between the test code and the test data files.
This turns out to be incredibly convenient for writing tests to cover
existing behavior in trn.  Usually when I write some covering tests
for existing behavior in trn I find a bug or two and fix it along the
way.

The cmake branch will probably be merged into master soon, now that
the build and tests are passing in both Linux and Windows.

I'm headed to Vegas this week, so probably no more progress until 2
weeks from now :)

Cheers,
-- Richard

Other progress:

- Added "string-algos.h": small, inline functions to manipulate
  character string pointers like "advance this pointer until it
  doesn't point at a delimineter character (e.g. space)".  This
  replaced a bunch of hand-written inline loops all over the code.

- Added tests to cover mimecap file parsing and documented some %
  interpolations that are applied to commands.  This isn't documented
  in the man page.  MIME type handling in unix has advanced
  considerably in the time that trn was last hacked upon; there's
  probably some considerable improvement that could be made for
  handling MIME types.

- putenv has some weird, inconsistent behavior when you try to delete
  a variable from the environment.  Trn would try to manipulate the
  environ global variable directly in order to effect a deletion, but
  this was giving me problems on Windows.  Also, documentation on both
  Windows and Linux really warns you against messing around with this
  variable directly and instead refers you to the functions
  getenv/putenv for manipulating environment variables.  Much of trn's
  code is influenced by the presence or absence of environment
  variables, so the platform-specific nature of putenv was making for
  fragile tests.  A std::function<> seam was inserted to decouple trn
  directly from the environment and allow the test code to insert a
  mock environment.  See tests/trn/mock_env.h for details of how this
  works.

- Added a submodule for vcpkg to prepare for github build/test
  workflows.

- I got a test article from a user that experienced a crash in trn,
  but haven't had a chance to see if I could reproduce the problem.
  It's from a binary newsgroup and contains a big yenc encoded body.
  There's no existing yenc support in trn and the 8-bit characters in
  the body are probably confusing it in some way.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

Linux adjustments begin...

[Richard <leg...@xm...>]

Hi Team,

Well I was able to beat up the code in WSL last night and made some
progress, but it's going to be some time before things build cleanly
on Linux due to the old habits in this code.  I think I'm going to
create a github workflow for the Windows build so I don't accidentally
break that while I work on fixing the errors while building under
WSL/Linux with cmake/vcpkg.

It's probably a good time to nail down a specific revision of vcpkg
being used as well since they just switched the boost dependency to
1.82 from 1.81.  This will most likely be done with a git submodule
attached to a specific hash for vcpkg.

I didn't realize that gtty/stty system calls weren't implemented in
linux :).  More joy to follow...

Cheers,

-- Richard

-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

acli:trn/master merged into LegalizeAdulthood:trn/master

[Richard <leg...@xm...>]

Hi Team,

Phew!  That took some effort.

Well, actually merging acli's master into my master was easy.  What
took some effort was rebasing my cmake branch onto the new master.

I still need to incorporate the tests that acli added (yay tests!).

Looking at the range of commits, I can see that acli has put quite a
bit of work into the various changes needed to support clean UTF-8
output.

So this is a good situation we're in here; acli's UTF-8 work has been
integrated, the patch for the old usenet dates (unix UTC timestamps)
has been incorporated.  Pdcurses and boost.asio have simplified the
support for Windows without having to write a bunch of Windows
specific code.

I do see some goofiness in the tests if I run them repeatedly or in a
shuffle order, so there is probably some state that isn't being reset
properly by the test fixtures.  Given the huge number of global
variables used by trn this isn't surprising.  Orchestrating that state
was done based on a 'best guess' basis since I am still learning the
various bits of code.  Still, we're in a good state and I've tried to
cover my changes with tests as best as possible in this legacy code
base.

Cheers,

-- Richard

-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

Re: NNTP/pdcurses now working on Windows [2nd try]

[Richard <leg...@xm...>]

In article <E1p...@sh...>,
    Richard <leg...@xm...> writes:

> [...]  The NNTP style used by trn is quite old,
> using non-standard extensions for facilities that are now covered by
> extensions.

I meant to say "covered by standard commands" here, but you probably
figured that out already :)

-- Richard

-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

NNTP/pdcurses now working on Windows [2nd try]

[Richard <leg...@xm...>]

[1st try was rejected for oversize image attachment]

Hi Team,

I probably have some more testing to do to verify that I haven't
broken anything, but with boost.asio and pdcurses, I have a native
Win32 version working in cmd.exe.  See attached screen shot.

Screen shot here:
<https://user.xmission.com/~legalize/trn/trn-basic-win32.png>

Not bad :).  I even have a way to test basic NNTP conversation between
trn and a mocked server.  With what I recently learned about SSL/TLS and
boost.asio I should be able to add nntps and STARTTLS support to trn
without much difficulty.

I added some more unit testing around my nntp changes and found a few
little bugs that I fixed.  The NNTP style used by trn is quite old,
using non-standard extensions for facilities that are now covered by
extensions.  It doesn't use the CAPABILITIES command at all to
identify extensions it could use.

INN (what almost everyone uses for NNTP servers these days) is very
forgiving, so these things don't result in failures, but trn should be
more properly using the CAPABILITIES command and commands that have
been standardized to replace the ad-hoc extension commands.

The curses usage on Win32 might be a little goofy; some things are
hardcoded that should probably be queried from pdcurses.

Now that I have basic NNTP on Windows, I think it's time to revisit
the Linux side of things and make sure everything is working there.
I'm going to first try with WSL since that is the most accessible to
me at the moment.

Cheers,

-- Richard

-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

NNTP and TLS progress

[Richard <leg...@xm...>]

Hi Team,

Currently the NNTP support in trn is broken on Windows.  (I am not
sure if it ever worked as written on MS-DOS, I'm not going to
resurrect a 25 yr old development environment to find out.)  How is it
broken?  Well, the existing code assumes that you can get a file
descriptor number from the socket and then do things like dup(),
read() and write() on that file descriptor.  This is an assumption
from Berkeley sockets where such things are perfectly valid, but the
assumption fails on WinSock.

To prepare for my talk this evening on using boost.asio with TCP/IP, I
hacked up some code to talk to news servers and switch to TLS after
the initial connection with the STARTTLS command, should the
capabilities report it.  The code is here:
<https://github.com/LegalizeAdulthood/asio-tcp-ip>

This is only meant to serve as an example for my talk, but will
probably serve as the basis for an asio-based library for NNTP that
will replace the existing manual socket code in trn to allow for
asynchronous communication with multiple NNTP servers as well as add
TLS support.

For testing purposes, I think I'm going to hack up a synchronous
get/put line function using boost.asio into trn and add the ability to
dump the NNTP conversation to a log file.  Then during testing I can
play back the log file into trn to validate that the conversation is
handled properly by any changes I make.

I thought about fixing the assumed read/write calls on the file
descriptor using recv/send on the socket file descriptor using
WinSock, but just like the directory enumeration it seems better to
move forward to a modern approach rather than trying to back fill a
procedural C-style approach onto the existing code.

A real NNTP client library using asio would need the following:
- Understanding of which commands can generate which status codes
- A state machine approach to the conversation
- Asynchronous operation, probably delegate all I/O to a distinct
  thread so as to not impose too much "inversion of control" onto the
  existing application's structure
- Handle timeouts from servers
- Deliver "line at a time" of data blocks to the client of the
  library.  In other words, don't force article parsing or data block
  parsing of complex command responses on the library.  Just handle
  the transport.  A library layer on top of transport could handle
  these details
- Support pipelined commands

As near as I can tell, the existing trn code does not:
- Support multiple simultaneous connections to servers
- Support command pipelining

There does appear to be some sort of "background processing" support,
e.g. trying to get ahead of the user in article/server processing
while the user is reading an article, but it's done in a manner that
is currently opaque to me.  I simply haven't studied the code in more
detail to see what's actually going on.

So my next efforts are going to be on an NNTP library as discussed
above that I can plug into trn.  That library will probably be kept as
a separate repository and just pulled into trn via a git submodule or
vcpkg dependency.  I'll try to keep the library agnostic of boost;
I've noticed that many people using asio as a base support boost.asio,
"regular asio" or the C++ networking technical specification (TS).

So things are progressing...

-- Richard

-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

Sometimes there's an advantage to skipping 10 years...

[Richard <leg...@xm...>]

Hi Team,

So I was finishing off my interpolation tests (all interpolation
characters now tested and passing and some bugs fixed!) last night when I
bumped into one of those portability problems that the elaborate Configure
scripts were attempting to address.  (I sure don't miss the early 90s
unix landscape where every vendor's unix was "the same, but different"!)

Namely, how do you iterate over directories?  For local news reading,
trn wants to change it's current directory to a newsgroups spool directory
and then iterate over the files in "." to locate articles.  (BTW, this is
an approach that doesn't scale well for a newsgroup with many articles
of which you've read most of them, but I digress.)  The MSDOS port path
of trn had a substitute implementation of POSIX opendir/readdir/closedir
in ndir.c.  However, this isn't the first time that I've seen code that
worked in DOS has different behavior under Win32.  Either that or the
DOS code never really worked; how many people were actually reading news
on DOS from a local spool directory?

Since the existing MSDOS branch code wasn't working correctly, I had
a couple choices.  I could write a C style directory iterator in the
existing ndir.cpp[*] that used the Win32 API to iterate over files in a
directory, or I could use <filesystem> from C++17.  Since the directory
iterating only happened in a single function, I opted to switch that
single function to use <filesystem> and iterate over the files using
a C++ range for loop.  A little bit of testing with my CMake generated
fake local spool containing two articles for a group and poof!  In about
15 minutes, the code was switched and working.  Since this is standard
library for C++17 I no longer need to test and configure for directory
iterating.  Nice!

The % interpolation code turned out to be a great way to boost my
understanding of the source code because it pretty much tickles
everything.  I think now I'm ready to merge my cmake branch back into
master and proceed from there doing smaller batches of commits on my
develop branch and frequently merging back to master.  My last task
before merging to master is to update the README with build
instructions for the current code and maybe depend explicitly on vcpkg
as a git submodule to prevent the dependencies from wandering forward
randomly.  At this time, the only external dependency is on GTest for
testing, but that might start changing soon.

On the cmake branch I have incorporated the patch from Olaf Seibert to
parse older format dates.  A simple test for parsedate was added to
verify the patch is working correctly.

Cheers,

-- Richard

[*] I've converted all the source files to C++ to allow me to access
C++ features even though it's still procedural C style programming.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

The best way to learn a legacy code base....

[Richard <leg...@xm...>]

...is by writing some tests for it :)

Hey there fellow dinosaurs,

One problem with hacking on trn is that it has absolutely no automated
tests for it, so you have to resort to lots of time in the debugger.
Reading the source code isn't much help either as what comments are
present don't reveal much of the design intent, but more local details
of whatever is happening at the location of the comment.  There is
also the usual input impedence related to reading someone else's code:
formatting and naming conventions deviate from your own personal
tastes, etc.

One thing trn does have going for it is the ability to tweak things to
the nth degree through external files and environment variables.

That gives us a hook into testing chunks of the code.

I used CMake's configure_file() function to create a bunch of related
text files in the build directory that act as test inputs to trn.
Using code generated from the same CMake variables I was able to set
the relevant environment variables to point at my generated files
during running of the tests.

I've now gotten to where I've got trn parsing generated news articles
in the "local news spool" (directories and files generated by CMake).
I wrote tests for every special % interpolation and now a bunch of the
ones related to article headers are passing and at least none of them
are crashing anymore :-).  Every time I work on getting one more fancy
% interpolation construct passing, I learn a little more about the
code.  This paves the way for making future changes in a safe manner.

Because some of the changes I've got in mind are pretty substantial in
terms of architecture, it's important to have a safety backstop to
catch mistakes.

This also brings up the age-old question in software: "refactor or
rewrite?".  My general long-standing opinion on this (based on some
good and bad experiences over many years) is always "refactor" with a
smidge of "rewrite".  By this I mean, trn has lots of the features I
want in a news reader, but lacks some of the features I'd like in a
news reader.  Rather than write my own news reader completely from
scratch, it's cheaper to refactor my changes into trn.  Considering
that trn has shifted maintainers several points in its lifetime given
its heritage, it's clear that the previous maintainers also though
that it was better to "refactor" their new features into existing code
than to start from scratch.

Along the way I've tried not to make sweeping code changes across all
the files.  TABs are still not expanded in source files :-).  Some
global changes happened in order to aid me in understanding the code.
File scope static variables were renamed to have 's_' prefix and
global scope variables were renamed to have 'g_' prefix in order to
more readily recognize connections to distant data when reading a
function.

I recently hit upon a design approach for the asynchronous NNTP engine
I'd like to drop into trn and I'll be prototyping this separately with
boost.asio for my Utah C++ Programmers talk next week.  I think that's
going to work out nicely and result in an asynchronous NNTP command
processor that can handle pipelining of commands as documented in the
NNTP RFC.  Reading over the RFCs relating to NNTP it's clear that some
of the "standard" features in the current NNTP spec were created after
the last time trn had any significant kind of release.

I looked over the tickets in the trn sourceforge repository and
created a couple issues in my github fork to incorporate some
fixes/changes that don't appear to have yet been integrated into the
trn source.

Cheers,

-- Richard

-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

Re: Greetings fellow dinosaurs! I'm hacking on trn...want to join me?

[Richard <leg...@xm...>]

In article <CAJ...@ma...>,
    Mike Van Pelt <mik...@gm...> writes:

> Cool!   Every time I get frustrated with "state of the art" online
> discussion group software and start to think about what I would do if
> I wrote something along the lines, I've quickly discovered that I'm
> re-inventing trn 4.0.

There are some PHPBB forums that I wouldn't mind monitoring via an
NNTP gateway.  I see that there are some RSS->NNTP gateways out there:

<https://feedbase.org/>
<http://gwene.org/>

Honestly, I have consistently found "web forums" to be so inferior to
NNTP/usenet.  I can literally read through hundreds of messages faster
in trn than I can read through one or two threads in a PHPBB style
forum.  Plus usenet/NNTP doesn't have a single point of failure like
web forums.

As I've often said, many people confuse the words "new" and "improved".

-- Richard

-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

Re: Greetings fellow dinosaurs! I'm hacking on trn...want to join me?

[Mike V. P. <mik...@gm...>]

Cool!   Every time I get frustrated with "state of the art" online
discussion group software and start to think about what I would do if
I wrote something along the lines, I've quickly discovered that I'm
re-inventing trn 4.0.

I never got trn to build under WSL, never could find those "missing
defs" and never got around to hacking replacements, but the last time
I did an "apt get" of it under WSL, I got 4.0-test77 and it works.
I've been happily using it under WSL for some time now.

On Tue, Apr 4, 2023 at 11:34 AM Richard <leg...@xm...> wrote:
>
> Hi fellow trn users aka dinosaurs,
>
> I just remembered that this list existed and I see some recent
> traffic, so I guess I'm not the only trn addict out there.
...
> - I see a message from Mike Van Pelt about attempting to build under
>   WSL with the existing Configure script.  I wonder if my CMake based
>   build would work better?  For NNTP the CMake configuration should be
>   sufficient to build.  Run?  Not sure, I haven't tried :).

Greetings fellow dinosaurs! I'm hacking on trn...want to join me?

[Richard <leg...@xm...>]

Hi fellow trn users aka dinosaurs,

I just remembered that this list existed and I see some recent
traffic, so I guess I'm not the only trn addict out there.  I posted
the below message to news.software.readers yesterday.

I see that some other people have hacked on trn lately:

- acli has added/fixed/improved UTF-8 support; this is great!
  I added an issue to my github fork to incorporate those fixes.
  <https://github.com/LegalizeAdulthood/trn/issues/2>

- I see a message from Mike Van Pelt about attempting to build under
  WSL with the existing Configure script.  I wonder if my CMake based
  build would work better?  For NNTP the CMake configuration should be
  sufficient to build.  Run?  Not sure, I haven't tried :).

Fellow adventurers are welcome!

-- Richard

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    Date: Mon, 3 Apr 2023 21:19:45 -0000 (UTC)
  Groups: news.software.readers
 Subject: I'm hacking on trn...want to join me?
      Id: <u0ffth$1u1oi$1...@ne...>
    Refs: nnrp.xmission news.software.readers:271960
---------
As near as I can tell the current "maintainer" of trn isn't.  The
official home page is on sourceforge and I don't see any activity
there for 10+ years.  The trn-4.0-test77.tar.gz distribution -- the
most recent -- was created in 02-Sep-2010.  The test76 release was
another ten years before that on 02-Apr-2001.

I may be the last user and it's somewhat of a pity/passion project :-).

I forked the code from sourceforge into github and I'm hacking on the
cmake branch.  <https://github.com/LegalizeAdulthood/trn/tree/cmake>

So far:
- Added a CMake based build
- Use vcpkg to get curses dependency (pdcurses on Windows)
- Use CMake inspection of your environment and configure_file to
  generate the config.h instead of chatty bash Configure script.
- Converted from C to C++
- Applied various automated clean-ups to the code (yay ReSharper for C++!)
- Gradually introducing more use of 'const'
- Gradually introducing use of std::string instead of C style string
- Unit tests with GTest
- Working on adding tests before making any major changes.
  - A bunch of % interpolator tests added and some minor bugs fixed
  - Using CMake to generate test local news spool data and articles
  - Will use this to verify article/newsgroup related % interpolation
  - This part is current work-in-progress
- Replace use of int with bool where appropriate
- Replace use of int with strong enum types where appropriate
- Legacy code considerations dropped; e.g. no special VMS code, no
  non-POSIX standard unix code, K&R style code modernized, no optional
  features to "save instruction and data space", etc.

General target direction:
- Replace low-level termios code with curses
- Become more "event driven" insted of mingled read/write stdio
- Decouple newsgroup/article logic from TUI to allow for GUI
- Replace synchronous NNTP/newsgroup processing with asynchronous
  processing

Vision of the final result (no particular order):
- True STARTTLS/NNTPS support
- Curses windows used to show all the various things:
  - newsgroup selection
  - article selection
  - thread selection
  - KILL files
  - etc.
- A GUI for reading news that's as convenient as the trn TUI.
- Let you manipulate the various windows like people do in vim/emacs
  allowing you to choose what is on-screen and where
- Client should be asynchronously advancing through the unread articles
  at the "speed of light" to apply scoring/threading/KILL file processing
  as far ahead as possible while you read.
- As easy to build on Windows as it is on *nix.

I mostly develop on Windows, but try to keep the #ifdef'ed linux
branches at least building by occasionally building in WSL.  A github
build workflow would help but not my immediate priority.

If you're interested in joining me for the ride, pull requests are
always welcome or drop an issue in the github repo.

I'm surprised that after all this time there is still no decent C++
library for NNTP.  The fallout from this effort may be such a library
using asynchronous I/O processing to get as close as possible to "the
speed of light" for an NNTP client.

I did a presentation on doing basic NNTP with POCO last year:
Writing a Network Client with POCO
<https://www.youtube.com/watch?v=rRR9RTUEn4k>

I'm doing another presentation next week on basic NNTP with boost.asio:
<https://www.meetup.com/utah-cpp-programmers/events/zhljbtyfcgbqb/>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
             The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

Re: trn-4.0-test77 can't find terminfo

[Peter T. <pet...@gm...>]

On Thu, Apr 7, 2022 at 8:42 PM B. Elijah Griffin <
sou...@el...> wrote:

> On Wed, 6 Apr 2022, Mike Van Pelt <mik...@gm...> wrote:
> > Since the shell account I've been using for years is going away, I'm
> > trying to build trn 4.0 on Windows Subsystem for Linux (yeah, I
> > know...) and I'm getting this error on the make:
>
> Just FYI I'm preferring the acli trn fork, which has much better MIME
> charset support. Unicode just works.
>
> https://github.com/acli/trn
>
> But I don't know if that has ever been compiled on WSL.  Traditional trn
> is probably more portable _if_ you know 1990s era porting tricks.
>
> > -------------------------------------------
> > # make
> > cc -c -O -I/usr/local/include  addng.c
> > In file included from addng.c:20:
> > term.h:171:1: error: expected identifier or ‘(’ before ‘...’ token
> >   171 | ..."Don't know how to define the term macros!"
> >       | ^~~
>
> When you ran Configure, it couldn't find your terminfo library. I belive
> it checks -lcurses and -lterminfo on C library path. You may need to add
> an additional directory to the path or change the library name. I've
> seen it sometimes available as -lncurses, but I'm guessing WSL may have
> differenr directories than regular Unix.
>
> Figure out what files that terminfo package installed and you should get
> past this. You'll need to rerun Configure with the new config.
>
> Elijah


I will check what I have in my build, but it will take booting an old box I
haven't used in quite some time.

Peter


>
>

Re: trn-4.0-test77 can't find terminfo

[B. E. G. <sou...@el...>]

On Wed, 6 Apr 2022, Mike Van Pelt <mik...@gm...> wrote:
> Since the shell account I've been using for years is going away, I'm
> trying to build trn 4.0 on Windows Subsystem for Linux (yeah, I
> know...) and I'm getting this error on the make:

Just FYI I'm preferring the acli trn fork, which has much better MIME
charset support. Unicode just works.

https://github.com/acli/trn

But I don't know if that has ever been compiled on WSL.  Traditional trn
is probably more portable _if_ you know 1990s era porting tricks.

> -------------------------------------------
> # make
> cc -c -O -I/usr/local/include  addng.c
> In file included from addng.c:20:
> term.h:171:1: error: expected identifier or ‘(’ before ‘...’ token
>   171 | ..."Don't know how to define the term macros!"
>       | ^~~

When you ran Configure, it couldn't find your terminfo library. I belive
it checks -lcurses and -lterminfo on C library path. You may need to add
an additional directory to the path or change the library name. I've
seen it sometimes available as -lncurses, but I'm guessing WSL may have
differenr directories than regular Unix.

Figure out what files that terminfo package installed and you should get
past this. You'll need to rerun Configure with the new config.

Elijah

trn-4.0-test77 can't find terminfo

[Mike V. P. <mik...@gm...>]

Since the shell account I've been using for years is going away, I'm
trying to build trn 4.0 on Windows Subsystem for Linux (yeah, I
know...) and I'm getting this error on the make:

-------------------------------------------
# make
cc -c -O -I/usr/local/include  addng.c
In file included from addng.c:20:
term.h:171:1: error: expected identifier or ‘(’ before ‘...’ token
  171 | ..."Don't know how to define the term macros!"
      | ^~~
addng.c: In function ‘new_local_groups’:
addng.c:216:2: warning: implicit declaration of function ‘termdown’
[-Wimplicit-function-declaration]
  216 |  termdown(1);
      |  ^~~~~~~~
make: *** [Makefile:113: addng.o] Error 1
-------------------------------------------

Apparently, the make can't find terminfo; this "stop the compile"
syntax error is in the #else after "#ifdef HAS_TERMLIB"

apt install tells me I already have the latest version of libtinfo6.
I also tried installing the legacy libtinfo5, to no avail.  "terminfo"
seems to be something very ancient (like trn itself) I've followed a
bunch of google links and done apt-cache search terminfo without
success.

Any ideas?

Re: some UTF-8 characters get trashed

[Nick L. <ni...@le...>]

In article <4BM...@pa...>,
Eli the Bearded <sou...@el...> wrote:
>Today someone told me there is one trn mailing list left working, so I'm
>forwarding this old post of mine from news.software.readers.

There still seem to be quite a few people use trn, though I don't know
how many of them read this list.  Thankyou from another user for taking
the time to share the change.

Nick
-- 
"The Internet, a sort of ersatz counterfeit of real life"
	-- Janet Street-Porter, BBC2, 19th March 1996

some UTF-8 characters get trashed

[Eli t. B. <sou...@el...>]

Today someone told me there is one trn mailing list left working, so I'm
forwarding this old post of mine from news.software.readers.

---8< cut---
Subject: UTF-8 "fix" for trn4-77
Newsgroups: news.software.readers
Posted: Thu,  1 Mar 2018 20:53:05 -0500 (EST)
Message-ID: <eli$180...@qz...>

I've got a utf-8 clean display environment, but reading news in trn with
utf-8 characters in them would sometimes show mangled characters. I
guessed that trn was trampling the high-bit on iso-8859-1 high-bit
control characters (0x80 to 0x9F) and did nothing for a long time.

Then I noticed that there is a switch:

       -j   forces trn to leave control characters unmolested in
            messages.

And testing that, I found that it worked to stop the utf-8 breakage.
Of course, it leaves control characters "unmolested" which is not
necessarily ideal.

This one line change, however, will "properly" defang control characters
(0x01 -> "^A", etc) while not brutalizing the high-bit stuff used by
UTF-8:

--- trn-4.0-test77/art.c.orig   2010-09-02 02:12:26.000000000 -0400
+++ trn-4.0-test77/art.c        2018-03-01 20:15:59.000000000 -0500
@ -468,7 +468,7 @@
                        outpos += 2;
                    }
                    else {              /* other control char */
-                       if (dont_filter_control) {
+                       if (dont_filter_control || (*bufptr & 0x80)) {
                            if (outputok)
                                putchar(*bufptr);
                            outpos++;

As should be clear, this does absolutely no good for you if your
environment is not utf-8 clean or if you are reading posts that are not
in utf-8.

What a tangled mess it is in artio.c (reading the article in) / art.c
(displaying the article to the user). I would not envy someone trying to
put a real character set conversion in.

Elijah
------
not sure if there is still a working trn mailing list

---cut 8<---

I've been using trn with that patch near daily since that time with no
problems from the change. I also created a patch ticket for that today:

https://sourceforge.net/p/trn/patches/6/

Maybe it can be included? Or at least more well known.

Elijah

Hello!

[Peter T. <pet...@gm...>]

 I'd like to see about making some mods to make trn play nicer when
forwarding or quoting messages containing UTF-8 and other 8-bit, multibyte
encodings. Is there any life in this project?

thanks

Re: trn4, clang, static analysis

[Thomas P. <par...@fr...>]

Le mercredi 08 avril 2009 à 11:03, d'après
Ollivier Robert <ro...@ke...> :

> Is there any interest in what I intend to do?

Yes!

-- 
Thomas Parmelan  -+-  to...@an...

Re: trn4, clang, static analysis

[Matt A. <ma...@ap...>]

On Wed, 8 Apr 2009, Ollivier Robert wrote:
>Is there any interest in what I intend to do?

I'm interested just for curiousity's sake.  (I don't have a newsfeed
anymore... I should try one of the free ones..)

>PS: 68 identified "problems" in the first run.

I think your quotes imply this, but there ARE false positives that it 
finds, too.  It has found a lot of good problems, IMHO.
(False problems should be written up as bugs against the checker.)

I've thought of running the checker against other open source things
I use, like alpine.

trn4, clang, static analysis

[Ollivier R. <ro...@ke...>]

Some of you may be aware of the kid on the block in compiler, llvm[1].
With some help from Apple, it is evolving quite rapidly and I've been
playing with it (in context of the FreeBSD project mainly).

One of the really interesting included tools is the static analyzer (dead
code assignments, null pointer deferences and so on).  It is not perfect
yet of course and false positive need to be checked for but I think it
could be useful.

I plan to run it (done) and probably publish in one way or another patches
to fix these issues.  So we are back at the fundamental question of
maintenance...

Do we still want to use SF?  Do we want something else?

Is there any interest in what I intend to do?

PS: 68 identified "problems" in the first run.
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- ro...@ke...
In memoriam to Ondine : http://ondine.keltia.net/

Re: About to unsubcribe

[Wayne D. <tr...@bl...>]

On Sat, Dec 27, 2008 at 03:03:27PM -0800, Wayne Davison wrote:
> I've changed the users and workers mailing lists to reject non-member
> postings.

Note also that anyone who wants to be able to post but does not want to
receive postings can subscribe and then turn off the mail-delivery flag
for their account.

..wayne..