From Newsgroup: comp.lang.misc

Reading Lindsay / van der Meulen [*] I stumbled across the following
transput description:

"When print is called, the mode of each item to be printed is
identified, and appropriate action taken as follows:
ints, reals, compls:
If there is not room for the item on the current line (page),
then newline (newpage) is called. Then the item is printed,
_preceded by a space_ (if not at the beginning of a line),
allowing sufficient positions to cope with the largest
permissible value of that mode."

(Emphasis by me.) I assume that describes standard behavior.

Alas, with Genie I get for example with

BEGIN
INT a = 123, b = -45678, c = 9;
INT d = max int, e = -max int, f = 0;
REAL x = 1.3, y = 456e78, z = .9;
COMPL r = d I e;
print ((a, b, c, newline));
print ((d, e, f, newline));
print ((x, y, z, newline));
print ((r, newline))
END

this output

+123 -45678 +9 +9223372036854775807-9223372036854775807 +0
+1.30000000000000e +0+4.56000000000000e +80+9.00000000000000e -1 +9.22337203685477e +18-9.22337203685477e +18

instead of, say, (mind the data-separating spacing)

+123 -45678 +9 +9223372036854775807 -9223372036854775807 +0 +1.30000000000000e +0 +4.56000000000000e +80 +9.00000000000000e -1 +9.22337203685477e +18 -9.22337203685477e +18

or, for the last line with the complex number, even

+9.22337203685477e +18 i -9.22337203685477e +18

I think such spacing would be quite useful since I noticed that in
simple, mostly test tools I want that spacing between numeric data.
And I always (have to) add 'blank' tokens anyway to make it somewhat
readable.

As a non-native speaker I'm not sure whether "preceded by _a_ space"
means all the padding spaces. I interpreted it as "a [one] space" to
separate the numbers; formatting trash like "...000e +0+4.560..."
in the example above would thus be alleviated; at least a bit.

I think, though, that indeed an additional separating space is meant
(otherwise the padding of "+123" at the start of the line above would
make no sense in the light of the quoted formulation).

Note: I'm just asking because I stumbled across the statement in the
document, and because I suffered from Genie's behavior; so I'd liked
some clarification. - The Genie docs have a lot of "deviations" from
the standard concerning transput, but this is not mentioned (presuming
that I didn't misinterpreted the Lindsey documents in the first place).

Janis

[*] https://inria.hal.science/hal-03027689/file/Lindsey_van_der_Meulen-IItA68-Revised.pdf

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 01/01/2026 11:58, Janis Papanagnou wrote:

As a non-native speaker I'm not sure whether "preceded by _a_ space"
means all the padding spaces. I interpreted it as "a [one] space" to
separate the numbers; formatting trash like "...000e-a +0+4.560..."
in the example above would thus be alleviated; at least a bit.

Your interpretation is correct. See RR10.3.3.1, which gives in
the comments the wording "a space is given and then V is output [...]"
and includes a space character in the actual code. For complex numbers,
also " i" is inserted between the real and imaginary parts.

So the A68G behaviour is [yet another] deviation, which is not
apparent in the A68G documentation. Personally, I don't greatly care;
I use the default output for numbers only for quick-and-dirty programs
[such as "PR precision = 10000 PR long long sqrt (2)"]. The official
A68 transput model is really somewhat at odds with Linux and stream-
based transput.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Kinross
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Sat, 3 Jan 2026 12:42:03 +0000, Andy Walker wrote:

The official A68 transput model is really somewhat at odds with
Linux and stream-based transput.

It was trying to come up with a common framework for coping with the
vagaries of I/O devices in the pre-Unix era.

The Unix folks came up with a much simpler model, based around simple
streams of arbitrary bytes. Various OS engineers of the time derided
it as rCLinefficientrCY, but its convenience eventually outweighed all
other considerations.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 2026-01-03 13:42, Andy Walker wrote:

-a-a-a-aSo the A68G behaviour is [yet another] deviation, which is not apparent in the A68G documentation.-a [...]

I sent a mail to Marcel suggesting to document that deviation (unless
it can be fixed easily).

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 2026-01-03 22:49, Lawrence DrCOOliveiro wrote:

On Sat, 3 Jan 2026 12:42:03 +0000, Andy Walker wrote:

The official A68 transput model is really somewhat at odds with
Linux and stream-based transput.

It was trying to come up with a common framework for coping with the
vagaries of I/O devices in the pre-Unix era.

The Unix folks came up with a much simpler model, based around simple
streams of arbitrary bytes. Various OS engineers of the time derided
it as rCLinefficientrCY, but its convenience eventually outweighed all
other considerations.

Especially the handling may get clumsy where event handler will enter
the scenery with some caveats and quirky constructs that are required
then. If someone (like me) is used to the simpler "C"/Unix-like file
processing it's needs to get accustomed to it.

The logical structure of files/books/channels, OTOH, I think is indeed
an interesting and useful option, and it's designed in a way to include
the simple "stream" processing as being just a special case of the more powerful structuring. (Probably not that important nowadays, but anyway useful.)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2