Re: Proposal to drop MKCATPAGES
Date:Sun, 25 Oct 2020 16:22:33 -0400 From:Thor Lancelot Simon Message-ID: <20201025202233.ga15...@panix.com> | Was the Australian machine kre mentioned one of those bizarre dual-68000 | designs that ran two CPUs in lockstep to handle non-restartable | instructions? No. It had memory management implemented in the memory boards, rather than by something near the CPU - all addresses on the bus (VME, or something close to it) were virtual, the memory boards responded to an access if they contained a page with a mapping that matched the address on the bus. It used address space ids so every mapping for every page didn't need to be updated every time there was a context switch (just the current process id on every memory board). Needless to say the memory was very slow (LOTS of wait states). The processor was a 68020 I believe (though there might have been some 68010 versions at one stage). No caching. I was (fortunately) not involved in the software for it, beyond some hardware testing, so I'm not sure which underlying system it started from. It did all work, but was horribly slow (the systems tended to also have some "normal" memory that worked only for the kernel, and was physically addressed, and much faster). kre ps: I heard of those dual cpu 68000 systems too, but also never saw one. "lockstep" was not quite right though, I believe, one cpu ran a cycle (or a few) behind the other, so when the first one faulted, the other could avoid executing the faulting instruction until after the cause of the fault (that is, assuming it was a missing page) was fixed. Actually quite clever.
Re: Proposal to drop MKCATPAGES
Date:Tue, 27 Oct 2020 02:54:48 + From:David Holland Message-ID: <20201027025448.ga27...@netbsd.org> | So the example should be changed to | | lam file1 -S $'\n' file2 file3 file4 | | ? If you s/should/could/ then yes. What ought be used right now I am less certain of. kre
Re: Proposal to drop MKCATPAGES
On Tue, Oct 27, 2020 at 06:10:10AM +0700, Robert Elz wrote: > | (after all, sed has something similar) > > Yes, but its needs are different, as it can read all of that > from a file, not just from the arg list. True. > | I made it specifically recognize only \n and \t (and not \\ or > | anything else) to minimize the chances of it breaking anything. > > Given that we now have (since at least NetBSD 8) the ability to > easily generate any of these chars from the shell, I wouldn't > go adding magic support for them in anything that doesn't already > have that, at least for processing arg strings. So, I'd prefer > it if you abandoned that patch. Reasonable enough. So the example should be changed to lam file1 -S $'\n' file2 file3 file4 ? Someone(TM) should add $'' to csh and tcsh; it seems handy and doesn't conflict with anything. -- David A. Holland dholl...@netbsd.org
Re: Proposal to drop MKCATPAGES
Date:Mon, 26 Oct 2020 15:52:45 + From:David Holland Message-ID: <20201026155245.ga29...@netbsd.org> | I was thinking in lam itself, like this: Oh, in that case I misunderstood. | (after all, sed has something similar) Yes, but its needs are different, as it can read all of that from a file, not just from the arg list. | I made it specifically recognize only \n and \t (and not \\ or | anything else) to minimize the chances of it breaking anything. Given that we now have (since at least NetBSD 8) the ability to easily generate any of these chars from the shell, I wouldn't go adding magic support for them in anything that doesn't already have that, at least for processing arg strings. So, I'd prefer it if you abandoned that patch. kre
Re: Proposal to drop MKCATPAGES
On Mon, Oct 26, 2020 at 05:39:30PM +0700, Robert Elz wrote:
> | Also if inserting newlines is an intended use case, I kinda think it
> | ought to accept \n in there, which it currently doesn't.
>
> That would be "C string quoting" which is $'\n' which isn't yet in POSIX
> but should be coming sometime, it is supported by most (Bournish) shells
I was thinking in lam itself, like this:
(after all, sed has something similar)
I made it specifically recognize only \n and \t (and not \\ or
anything else) to minimize the chances of it breaking anything.
Index: lam.1
===
RCS file: /cvsroot/src/usr.bin/lam/lam.1,v
retrieving revision 1.14
diff -u -r1.14 lam.1
--- lam.1 26 Oct 2020 04:09:32 - 1.14
+++ lam.1 26 Oct 2020 04:12:48 -
@@ -91,6 +91,9 @@
This option may appear after the last file.
(A capitalized version appearing before the last file is not carried
over past the last file.)
+Instances of the sequences "\en" and "\et" are replaced with hard
+newlines and tabs, respectively.
+(No other escapes are recognized.)
.It Fl t Ar c
The input line terminator is
.Ar c
Index: lam.c
===
RCS file: /cvsroot/src/usr.bin/lam/lam.c,v
retrieving revision 1.8
diff -u -r1.8 lam.c
--- lam.c 4 Sep 2011 20:28:09 - 1.8
+++ lam.c 26 Oct 2020 04:12:48 -
@@ -74,6 +74,7 @@
static char*gatherline(struct openfile *);
static void getargs(char *[]);
static char*pad(struct openfile *);
+static const char *getseparator(const char *arg);
int
main(int argc, char *argv[])
@@ -128,7 +129,7 @@
switch (tolower((unsigned char) *c)) {
case 's':
if (*++p || (p = *++av))
- ip->sepstring = p;
+ ip->sepstring = getseparator(p);
else
error("Need string after -%s", c);
S = (*c == 'S' ? 1 : 0);
@@ -216,6 +217,50 @@
return (lp);
}
+static const char *
+getseparator(const char *arg)
+{
+ size_t i, j;
+ int seen;
+ char *p;
+
+ seen = 0;
+ for (i = 0; arg[i] != '\0'; i++) {
+ /*
+* React only specifically to \n and \t; leave
+* anything else alone.
+*/
+ if (arg[i] == '\\' && (arg[i+1] == 'n' || arg[i+1] == 't')) {
+ seen = 1;
+ }
+ }
+ if (!seen) {
+ warnx("blah");
+ return arg;
+ }
+
+ /* sufficient: length of result is at most strlen(arg) - 1 */
+ p = malloc(strlen(arg));
+ if (p == NULL) {
+ err(1, "malloc");
+ }
+ for (i = j = 0; arg[i] != '\0'; i++) {
+ if (arg[i] == '\\' && arg[i+1] == 'n') {
+ p[j++] = '\n';
+ /* skip the \\ */
+ i++;
+ } else if (arg[i] == '\\' && arg[i+1] == 't') {
+ p[j++] = '\t';
+ /* skip the \\ */
+ i++;
+ } else {
+ p[j++] = arg[i];
+ }
+ }
+ p[j] = '\0';
+ return p;
+}
+
static void
error(const char *msg, const char *s)
{
--
David A. Holland
dholl...@netbsd.org
Re: Proposal to drop MKCATPAGES
Date:Mon, 26 Oct 2020 03:49:16 + From:David Holland Message-ID: <20201026034916.ga29...@netbsd.org> | Also if inserting newlines is an intended use case, I kinda think it | ought to accept \n in there, which it currently doesn't. That would be "C string quoting" which is $'\n' which isn't yet in POSIX but should be coming sometime, it is supported by most (Bournish) shells these days, but there are differences in some of the more esoteric features (like exactly what should happen with a \u (or \U) which insert a unicode code point, when the current locale is not a utf-8 locale. Some shells, including ours, simply insert the UTF-8 for that code point, others attempt to convert to the current locale encoding of the same character). We cannot convert \n in "" quoting, as \ in "" is defined to mean something (to "be special") only when the following character is \ $ ` " or an actual newline. All other sequences \x are simply two characters, \ and x (which is also what \\x produces). This is the way the original Bourne sh did it, and is absolutely set in stone (surrounded by reinforced concrete, wrapped in a layer of solid diamond) now. On the other hand, for $'' quoting (C style strings) \ followed by something for which there is no specified meaning is reserved (unspecified results) so in that one there is room for future expansion. kre
Re: Proposal to drop MKCATPAGES
On Mon, Oct 26, 2020 at 01:33:22AM +0700, Robert Elz wrote: > | (what are the odds that anyone > | on a slow machine will ever look at lam(1)?) > > I must admit that I'd never looked at lam(1) - on any speed of machine. > > But when I did just now, just for the thrill of it, I see ... > [...] > The proverbial someone should fix that. Fixed. Also if inserting newlines is an intended use case, I kinda think it ought to accept \n in there, which it currently doesn't. > just from that man page read, I suspect that perhaps that -s should > also be -S (but that's speculation). Indeed. Someone changed it a while ago without apparently having read thoroughly enough. -- David A. Holland dholl...@netbsd.org
Re: Proposal to drop MKCATPAGES
On Oct 25, 16:22, Thor Lancelot Simon wrote: } On Sun, Oct 25, 2020 at 03:45:56PM -0400, Mouse wrote: } > } > I once had an hp300 with all of 5M of RAM. Years ago, when I had it } > running, thorpej told me it was quite possibly an instance of the } > slowest machine then supported by NetBSD. (Amusingly, at the same time } > I had an alpha that he said was possibly an instance of the fastest.) } } I think -- with the possible exception of the 725 or 730 if anyone ever } made them work, they were very hard to get going even with 4.3! -- the } Sun 2/50 is likely the slowest machine that ever ran NetBSD. I don't think } we support any 68010-based HP300 models, though I am not entirely sure. } } Was the Australian machine kre mentioned one of those bizarre dual-68000 } designs that ran two CPUs in lockstep to handle non-restartable } instructions? I've heard about them but never seen one. If I recall correctly (30 year old memories here), Apollo did that, but I haven't seen/touched one of those in about 30 years. It also had an interesting file system / networking trick where you could do ///... to get at files on a different machine. }-- End of excerpt from Thor Lancelot Simon
Re: Proposal to drop MKCATPAGES
Date:Sun, 25 Oct 2020 15:45:56 -0400 (EDT) From:Mouse Message-ID: <202010251945.paa14...@stone.rodents-montreal.org> | Wasn't the /725 slower, or am I misremembering? Never saw one, so can't compare, but it is hard to imagine that DEC would go build something even slower than a 730. And, to consolidate messages: wrt "\ " in shells: mo...@rodents-montreal.org said in a different message (same Subject): | That depends on the shell in use. It does, but we shouldn't be using csh examples without being very clear that is what they are. kre
Re: Proposal to drop MKCATPAGES
Den 2020-10-25 kl. 17:29, skrev Joerg Sonnenberger: On Sun, Oct 25, 2020 at 11:41:16AM -0400, Mouse wrote: Of course groff's even slower, but mandoc is faster -- than groff, at least, dunno about heritage nroff. Is there a noticeable delay with mandoc even on our slowest supported hardware? It might very well be fine. Last time I tried measuring it, it took less than 2s to render gcc.1, the by-then largest (by far) man page of all. On what hardware? tls's "slowest supported hardware"? (What _is_ the current "slowest supported hardware"?) Physical VAX, but don't know the details. Now we're completely off-topic, but that would be the 730. It does just over 0.1 MIPS. It was extremely slow > 20 years ago when I last tried one. -- R
Re: Proposal to drop MKCATPAGES
On Sun, Oct 25, 2020 at 03:45:56PM -0400, Mouse wrote: > > I once had an hp300 with all of 5M of RAM. Years ago, when I had it > running, thorpej told me it was quite possibly an instance of the > slowest machine then supported by NetBSD. (Amusingly, at the same time > I had an alpha that he said was possibly an instance of the fastest.) I think -- with the possible exception of the 725 or 730 if anyone ever made them work, they were very hard to get going even with 4.3! -- the Sun 2/50 is likely the slowest machine that ever ran NetBSD. I don't think we support any 68010-based HP300 models, though I am not entirely sure. Was the Australian machine kre mentioned one of those bizarre dual-68000 designs that ran two CPUs in lockstep to handle non-restartable instructions? I've heard about them but never seen one. Thor
Re: Proposal to drop MKCATPAGES
> [...] To merge the lines from four > different files use >lam file1 -s "\ >" file2 file3 file4 > which cannot be right, [...]. More likely a string containing just > a newline is what is wanted, in which case the '\' MUST be omitted. That depends on the shell in use. In two quick tests I just did, csh on 1.4T and 5.2 does indeed use quoted-backslashed-newline, as in the example you quote, to get a newline into the command line. (Okay, my 1.4T and 5.2 derivatives, but I havean't hacked on csh on either of them, except for whitespace cleanup and, for the 1.4T version, for switching to 64-bit time_t.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal to drop MKCATPAGES
>> Physical VAX, but don't know the details. > Do we support the 11/730 - if there's any unix running 32 bit (or > wider) system that's well known, and slower, I've never heard of it. Wasn't the /725 slower, or am I misremembering? I do recall that, back when I was at McGill, we had a /780, two /750s, and either a /730 or a /725. The last, when it was decommissioned, we went through the cards for, looking for the CPU. (I learned, much later, that it was a bitslice design, with no single localized CPU.) We found a Z-80 (I think it was probably driving the console tape) and, only half jokingly, suggested that it was a Z-80 running a VAX emulator. I once had an hp300 with all of 5M of RAM. Years ago, when I had it running, thorpej told me it was quite possibly an instance of the slowest machine then supported by NetBSD. (Amusingly, at the same time I had an alpha that he said was possibly an instance of the fastest.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal to drop MKCATPAGES
Date:Sun, 25 Oct 2020 17:29:02 +0100 From:Joerg Sonnenberger Message-ID: <20201025162902.ga112...@bec.de> | Physical VAX, but don't know the details. Do we support the 11/730 - if there's any unix running 32 bit (or wider) system that's well known, and slower, I've never heard of it. (For 16 bit systems the pdp 11/23 probably wins hands down). kre ps: the "well known" is because there was, in the dark ages, a 68k based system in AU that would have given the 11/730 some decent competition, but almost no-one has ever heard of it.
Re: Proposal to drop MKCATPAGES
Date:Sun, 25 Oct 2020 01:38:16 + From:David Holland Message-ID: <20201025013816.ga28...@netbsd.org> | (what are the odds that anyone | on a slow machine will ever look at lam(1)?) I must admit that I'd never looked at lam(1) - on any speed of machine. But when I did just now, just for the thrill of it, I see ... [...] To merge the lines from four different files use lam file1 -s "\ " file2 file3 file4 which cannot be right, that would be equivalent to lam file1 -s "" file2 file3 file4 and if that's what was intended, it would make much more sense to just write that. More likely a string containing just a newline is what is wanted, in which case the '\' MUST be omitted. The proverbial someone should fix that. I still have no real idea what lam actually does, and am far to lazy to go experiment and find out, but just from that man page read, I suspect that perhaps that -s should also be -S (but that's speculation). kre
Re: Proposal to drop MKCATPAGES
On Sun, Oct 25, 2020 at 11:41:16AM -0400, Mouse wrote: > >> Of course groff's even slower, but mandoc is faster -- than groff, > >> at least, dunno about heritage nroff. Is there a noticeable delay > >> with mandoc even on our slowest supported hardware? It might very > >> well be fine. > > Last time I tried measuring it, it took less than 2s to render gcc.1, > > the by-then largest (by far) man page of all. > > On what hardware? tls's "slowest supported hardware"? (What _is_ the > current "slowest supported hardware"?) Physical VAX, but don't know the details. Joerg
Re: Proposal to drop MKCATPAGES
>> Of course groff's even slower, but mandoc is faster -- than groff, >> at least, dunno about heritage nroff. Is there a noticeable delay >> with mandoc even on our slowest supported hardware? It might very >> well be fine. > Last time I tried measuring it, it took less than 2s to render gcc.1, > the by-then largest (by far) man page of all. On what hardware? tls's "slowest supported hardware"? (What _is_ the current "slowest supported hardware"?) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal to drop MKCATPAGES
On Sat, Oct 24, 2020 at 08:35:47PM -0400, Thor Lancelot Simon wrote: > Of course groff's even slower, but mandoc is faster -- than groff, at > least, dunno about heritage nroff. Is there a noticeable delay with > mandoc even on our slowest supported hardware? It might very well be > fine. Last time I tried measuring it, it took less than 2s to render gcc.1, the by-then largest (by far) man page of all. Joerg
Re: Proposal to drop MKCATPAGES
dholland-t...@netbsd.org (David Holland) writes: >Also, if we do have a platform where it's too slow and anyone actually >cares, We spend more for HTML pages without a viewer in base. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Proposal to drop MKCATPAGES
On Sun, Oct 25, 2020 at 02:03:43AM +0100, Kamil Rytarowski wrote: > I bet that cat(1) is always faster, but I consider myself as the only > regular (at all?) user of these pages at least since since 6.x and > nobody caring. Also, if we do have a platform where it's too slow and anyone actually cares, the right answer is really not to spend a gob of disk space generating all the pages in advance (what are the odds that anyone on a slow machine will ever look at lam(1)?) but to teach man about caching. That is: I agree, fire away. -- David A. Holland dholl...@netbsd.org
Re: Proposal to drop MKCATPAGES
On 25.10.2020 02:35, Thor Lancelot Simon wrote: > On Sun, Oct 25, 2020 at 02:13:47AM +0200, Kamil Rytarowski wrote: >> >> I recall catpages to used in 80286 UNIX (Coherent) and the catpages are >> probably just applicable for such constrained environments that cannot >> host any text formatters. > > The issue was the speed of the text formatters. I vividly recall on > the 11/750 waiting multiple seconds for nroff to chew through man > pages before I could read them. > > Of course groff's even slower, but mandoc is faster -- than groff, at > least, dunno about heritage nroff. Is there a noticeable delay with > mandoc even on our slowest supported hardware? It might very well be > fine. > I bet that cat(1) is always faster, but I consider myself as the only regular (at all?) user of these pages at least since since 6.x and nobody caring. > Thor > signature.asc Description: OpenPGP digital signature
Re: Proposal to drop MKCATPAGES
On Sun, Oct 25, 2020 at 02:13:47AM +0200, Kamil Rytarowski wrote: > > I recall catpages to used in 80286 UNIX (Coherent) and the catpages are > probably just applicable for such constrained environments that cannot > host any text formatters. The issue was the speed of the text formatters. I vividly recall on the 11/750 waiting multiple seconds for nroff to chew through man pages before I could read them. Of course groff's even slower, but mandoc is faster -- than groff, at least, dunno about heritage nroff. Is there a noticeable delay with mandoc even on our slowest supported hardware? It might very well be fine. Thor
Proposal to drop MKCATPAGES
I propose to drop the support for MKCATPAGES=yes. catpages are preformatted .txt files that happen to contain manual pages and are cat(1)able. Over the past more than 5 years, I was the only person reporting any fallout and fixing the regressions in the MKCATPAGES=yes build failures. I'm going to switch to dynamic manual pages formatting through mandoc(1) as superior, allowing to tune the behavior of the display. This proposal is driven by a request of a user to implement MANWIDTH. If we would want to support MANWIDTH we would need to rearrange the order of detection of the manual pages (similar to what did FreeBSD), but I consider it not worth the complexity. I recall catpages to used in 80286 UNIX (Coherent) and the catpages are probably just applicable for such constrained environments that cannot host any text formatters. signature.asc Description: OpenPGP digital signature
