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 ...
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. (A
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
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 m
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 sai
Christos Zoulas wrote:
> In article ,
> Valery Ushakov wrote:
>>Alistair Crooks wrote:
>>
>>> If it comes back, it needs to be modified to use curses - the hardcoded
>>> terminal escapes for a bunch of 1970s terminals is kinda cute in a retro
>>> way; it's also kinda embarassing.
>>
>>From a ve
> [...] 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 shel
>> 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 /
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
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 wh
Date:Sun, 25 Oct 2020 19:01:18 +0900
From:Rin Okuyama
Message-ID: <09f349b6-f483-e582-d5b4-71f6b747d...@gmail.com>
| I forgot to mention in the previous message: %[oux] also fail for numbers
| larger than 1<<63:
Yes, so they do - that's a (relatively) recent regr
All,
> Some shells have its own built-in versions of printf(1).
Sure enough.
$/usr/bin/printf "%x\n" 0xc000
printf: 0xc000: Result too large or too small
7fff
pgp2jXEFLUZv3.pgp
Description: PGP signature
All,
> I forgot to mention in the previous message: %[oux] also fail for numbers
> larger than 1<<63:
>
> $ printf '%x\n' 0xc000
> printf: 0xc000: Result too large or too small
> 7fff
I am seeing something different:
$printf '0x%x\n' 0xc000
0xf
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
Hi,
On 2020/10/26 0:21, a...@100acres.us wrote:
All,
I forgot to mention in the previous message: %[oux] also fail for numbers
larger than 1<<63:
$ printf '%x\n' 0xc000
printf: 0xc000: Result too large or too small
7fff
I am seeing something different:
>> 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,
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 t
On 2020/10/25 0:26, Robert Elz wrote:
Date:Sat, 24 Oct 2020 21:40:44 +0900
From:Rin Okuyama
Message-ID:
| However, this result apparently depends on width of intmax_t. Is this
| behavior acceptable by POSIX?
Two things:
This from POSIX (actually from a d
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
t...@panix.com (Thor Lancelot Simon) writes:
>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.
mandoc fails on small hardware (l
20 matches
Mail list logo
