This is the real fix for infinite-wait on send() problem that was attempted
in commit f0127e9d, but caused other issues. Thanks Deuce.

This reverts commit f0127e9d.

This change was "wrong-headed" per Deuce and broke JS sends on
blocking sockets. Thanks for the help.

This fix for inifinite-wait on send() likely led to the infinite
BinkIT errors/log messages that led to commit 4dd32231.

The real fix for this problem (which can block all other timed
events from running), would be a Socket.poll() on the socket before
send in binkp.js.

Updated the SlyEdit documentation for version 1.81 (forgot yesterday).  Also updated the default SlyEdit.cfg to use the English dictionary (for spell check).

See merge request !224

Updated the SlyEdit documentation for version 1.81 (forgot yesterday).  Also updated the default SlyEdit.cfg to use the English dictionary (for spell check).

SlyEdit: No more control characters needed in the color configuration files

See merge request !222

Good Time Trivia: Hosted inter-BBS user scores (via JSON DB) is now possible.

See merge request !221

Update registration page for closed and newuser password systems

See merge request !219

DD Message Reader: Fixed bug startup mode for scanning all groups for un-read messages to you where the reader was bringing up personal email instead.

See merge request !220

DD Message Reader: Fixed bug startup mode for scanning all groups for un-read messages to you where the reader was bringing up personal email instead.

De-duplication wasn't working

A periodic (e.g. weekly) digest of high scores posted to SYNCDATA
will allow BBSes to have an accurate list of global high scores
without requiring the retention of several years of SYNCDATA messages.

Also, made the necessary changes to allow:
'jsexec minesweeper.js export' (for testing, primarily)

When posting an exception report, post from sysop if user.alias is undefined.

Incremented revision to 2.15 (though there were no game-play changes).

Fix issue #457

May as specify that .asc and .msg are text too, though no known reason why
CRLF EOLs may be more desireable.

js_open() sets the rval for the context (e.g. to JSVAL_TRUE), so we need to set
it back to JSVAL_FALSE for failure conditions. Otherwise, the methods always
return true even upon (save-msg) failure.

If nodeX/node.cnf has the wrong node number, the [R] flag would be cleared from
the wrong node upon automatic configuration reload. This likely fixes the issue that Keyop is reporting in #synchronet

This is a new trivia door, Good Time Trivia, written in JavaScript

See merge request !217

This is for weird embedded systems where RTS is not supported by
the communications channel, but is actually controlling something
else (TX, Bootloader update mode, etc).

DD message area chooser only: Bug fixes for numeric input in lightbar mode and number of posts in traditional mode

See merge request !216

Eric Oulashin authored 2 years ago and Rob Swindell committed 2 years ago

DD message area chooser only: Bug fixes for numeric input in lightbar mode and number of posts in traditional mode

@anonymouspage reported it broken in !212.

Reported by @anonymouspage, closes !211
Clean up  formatting in the touched functions while we're here.

Message area chooser only: Made use of the 'posts' property for the number of messages (without vote headers)

See merge request !215

Eric Oulashin authored 2 years ago and Rob Swindell committed 2 years ago

Message area chooser only: Made use of the 'posts' property for the number of messages (without vote headers)

My hub (1:218/700) is currently having what appears to be a TCP/IP
connectivity issue that was resulting in infinite "Send failure"
log messages and "We got an M_EOB, but there are still N files pending M_GOT"
log messages.

I first added better socket-send failure detection (checking return value of
sendCmd() and sendData() where needed) and then noticed that failure to send
a file was not detected (the sending.file.position is advanced even if
sendData() fails), so now handling that condition too.

Also added more diagnostics around socket-send failures (is socket writable?)
in this particular case, the socket is not writable and socket-send is
returning 0.

This adds a Ctrl-A code in the notification subject, so needs latest
postmsg.cpp or that Ctrl-A code will end up in your email/inbox too
(not really supported or stripped when sent over POP/SMTP).

We may want Ctrl-A sequences in the telegram subject, but not in the message
subject

Will notify the sysop via email and telegram when a new user account has
been created. For Morpheus (MORPHEUS)

... unless a comma is actually required.

Somehow, new users on Vertrauen *still* manage to answer "Yes" to both the QWK
Networking account questions, accidentally creating a QWKnet account that's
not useful for normal BBS user activities. So print a very clear "alert" style
message making it even-more clear that the account they are creating will ONLY
be useful for QWK Networking activities.

This Coverity reported issue was previously resolved (incorrectly) with
commit 0c441424 which also introduced a bug that ate all the unexpected
cursor position report characters (causing issue #304).

The correct fix was to compare the response length against the buffer size
minus one, to leave room for the NUL terminator.

While fixing this and issue #304, I noticed that this function was using the
response length ('rsp') as both the state machine state and string length,
which didn't work right if a nearly-matching report/response was received:
the x/y values would have been stripped from the response before stuffing
in the keyboard input buffer. So a bit of a refactor here using a proper
state machine variable.

Unexpected characters received (maybe typed by the user) were supposed to
be stuffed in the keyboard input buffer using ungetstr(), but the input string
was cleared rather than NUL-terminated before logging the expected character
and calling ungetstr(), so nothing (a blank string) was logged and nothing was
stuffed in the keyboard input-buffer in this case. Just an off-by-one bug.

This should fix issue #304. Thanks to Keyop and Nelgin for their persistence
in reporting and testing (in #synchronet at irc.synchro.net).

I didn't look closely enough at which write() call I was instrumenting.
This is now more useful, though I think we already found the root-cause
based on different log output ("Unexpected ansi_getxy response").