🚀 go-pugleaf

On Wednesday, in article
     <20120926.0904.12090231snz@i-m-t.demon.co.uk>
     v$af$ppint@i-m-t.demon.co.uk ""ppint. at pplay"" wrote:

> 	- hi; in article, <20120925.1108.933182snz@twoplaces.co.uk>
> 	  simon@twoplaces.co.uk "Simon Turner" reported & commented:

[...]
> >Very odd; I've checked the source for 2.16d and it works exactly the
> >same way as GremNOS, i.e. the "current session" info passed to commands
> >like "record" is the "most recently escaped from" session, which is
> >initially set to the main command session.  If the "most most recently
> >escaped from" session ends, the marker is reset to nothing, and remains
> >that way until next time you use F10.
> 
> 	- so what on - or off - earth have i - or my computer(s) - been
> 	doing ?

I couldn't possibly comment. 8-)

> 	- the first two or three sessions were f status@gate, f report@
> 	gate & f i-m-t+@post, added at the end of autoexec.net, the fourth
> 	being ftp homepages, by keyboard; on quit<enter>-ing the completed
> 	ftp session, and <enter>-ing once more (as directed on-screen), to
> 	return to the net>, i used not to have to select an open session
> 	by s <1-3>: just <enter> gave the third (long finger) session.

Hmmm.  How did this appear from your POV?  I just tried it with GremNOS,
with the three finger commands at the end of AUTOEXEC.NET, and it opened
all three finger sessions, leaving me in the final one (the long finger,
in this case), so I had to use F10 to get back to the prompt: the F10
set the last-session marker to that third session, so once the manual
ftp session ended and I pressed <enter>, I was returned to the long
finger session.  So far, so good.  But when I ended that session by
pressing <enter> to get back to the prompt, the last-session marker was
no longer set, so pressing <enter> on its own again didn't achieve
anything.

If I put something else in AUTOEXEC.NET after the finger commands, I
started off at the command screen, but the last-session marker started
off unset and remained so after the end of the manual ftp session, so
pressing <enter> never did anything.

How did it work (in terms of what session screen you saw when) under the
old system?

> 	- hmmm. it might've been something removed/lost when richard gave
> 	us the y2k- & other-fixes version of the KA9Q/dis 'net suite (or
> 	was it initially only the fixed KA9Q/net.exe ?  - i think it was
> 	the full suite...); i moved over (? or back to*) a y2k-fixed grem-
> 	nos that i think i read incorporated his fixes and updates pretty
> 	soon after, so i mightn't've noticed the change, if it happened
> 	then.

I don't think so; Richard didn't change any of this stuff when he did
his 2.18 Y2K-compatible version.  I've checked the source code back to
2.12 from July 1993, and all of them (2.12, 2.16d, 2.18 and GremNOS)
handle moving between sessions the same way: indeed the source code
files in question (SESSION.C and MAIN.C) didn't change significantly
between 2.12 and 2.18 (and the only changes in GremNOS relate to the
TextWin versions).

I must confess I'm baffled by this, because the source code doesn't seem
to have changed at all, and yet you're seeing different behaviour...

[...]
> >I definitely think that resetting the last-session marker to the command
> >screen, rather than nothing, when the current last-session ends would be
> >a Good Thing.  I'm still thinking about whether making "s 0" return you
> >to the main command screen would be useful (if you can type "s 0",
> >you're already there!); perhaps it might be useful in scripts in a way I
> >haven't thought of yet.
> 
> 	- *g*  - i was only thinking that, if it required a session no.
> 	in order to be selectable via the last session left marker,

It doesn't: the last-session marker is actually a so-called pointer (a
variable containing a memory location) that "points to" (i.e. contains
the location of) the area of memory containing the details of the
session in question, which can as easily be the command session as any
other; when unset, it "points to" memory location 0, a special value
known as NULL, making the variable a "null pointer".  (I bet you didn't
expect to have a C programming lesson! 8-)

In reality, the main command session is genuinely session 0; it is
intentionally not displayed in the "session" list.

>       and
> 	that were the simplest and most concise method of achieving the
> 	desired objective, session no. 0 would appear always to be avail-
> 	able and possess the minor advantage of never needing to respond
> 	to the "s<enter>" poll of current active sessions - unless it be
> 	considered desirable that one could find out what had been left
> 	(invisibly) running, but had been completely forgotten about ?

The main command session is the underlying foundation of the whole
program, and is *always* running; as soon as it finishes, NET.EXE stops
running.  Having it show up in the "session" ("s") list wouldn't tell
you anything useful IMHO; but having other invisible-but-running
sessions show up in the list is indeed valuable.

A thought: one could make the last-session-marker behaviour work the way
you described above, so that when the current last-session ends, it gets
reset to the most-highly-numbered session currently running (which would
be the command session if there are no others); this would mean that
"record" will *always* work, and pressing <enter> will always take you
to a running session if there are any left.

If you wanted to set the last-session marker to the main command session
while leaving other sessions running, in order to record the command
session, "session 0" could be a special case that does just that.

The last-session marker would thus always be set to something: if it
shows up in the "session" list, it's the indicated session; if not, it's
the main command session.

I think that might actually be the best all-round solution; what does
anyone else think?

> 	- love, a ppint. off to replace my pop3 password with one i don't
> 	mind sharing - yup, it's happened again, and you did say you'd like
> 	the chance to find out what was causing the 'TOP N 0' failed: ''
> 	(after pop3 sent: top 30, and pop3 receive failed: ???) to appear.

I would indeed like to find out what causes the TOP commands to fail;
I've responded to this in e-mail (sent to punt-1 rather than mx1 to give
you a chance of receiving it).

-- 
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer