On Mon, 9 Aug 2021 07:56:15 -0600, rbowman wrote:
>
> Back when a 1 GB hard drive was huge, the choice between Vim and Emacs
> was a no-brainer. iirc Vim was 1.6 MB, Emacs was 25 MB. It looks like
> gVim has porked up to 2.7.

The on my first PC 1995 had 1300 MB. In late 1997 I split it between
Windows 95 (850 MB) and installed Linux (rest including swap space). No
space for a GUI. May be I could had installed Xfce or something. But the
CD, which came as bonus on a magazine, only had KDE, and I was a bloody
n00b not even knowing what KDE is.
--
Andreas

On 08/10/2021 02:33 AM, jak wrote:
> Il 09/08/2021 15:56, rbowman ha scritto:
>> Back when a 1 GB hard drive was huge, the choice between Vim and Emacs
>> was a no-brainer. iirc Vim was 1.6 MB, Emacs was 25 MB. It looks like
>> gVim has porked up to 2.7.
>
> No. Further back. When a hard drive was huge if greater than 30MB.

What am I ever going to do with all this disk space? There is a
corollary of Moorse's Law that pertains to executable and data bloat.

On 11/08/2021 04:12, rbowman wrote:
> On 08/10/2021 02:33 AM, jak wrote:
>> Il 09/08/2021 15:56, rbowman ha scritto:
>>> Back when a 1 GB hard drive was huge, the choice between Vim and Emacs
>>> was a no-brainer. iirc Vim was 1.6 MB, Emacs was 25 MB. It looks like
>>> gVim has porked up to 2.7.
>>
>> No. Further back. When a hard drive was huge if greater than 30MB.
>
> What am I ever going to do with all this disk space?  There is a
> corollary of Moorse's Law that pertains to executable and data bloat.
>
That has actually returned to haunt me. My NAS that has all the data is
a linux box with lots of spinning rust, but my user devices are laptops
Pis stupidPhones and a desktop pc all equipped with SSD's that are
almost entirely read only devices. And virtually empty.

But I cant get a 30GB drive.

--
There is something fascinating about science. One gets such wholesale
returns of conjecture out of such a trifling investment of fact.

Mark Twain

On 2021-08-11, rbowman <bowman@montana.com> wrote:

> On 08/10/2021 02:33 AM, jak wrote:
>
>> Il 09/08/2021 15:56, rbowman ha scritto:
>>
>>> Back when a 1 GB hard drive was huge, the choice between Vim and Emacs
>>> was a no-brainer. iirc Vim was 1.6 MB, Emacs was 25 MB. It looks like
>>> gVim has porked up to 2.7.
>>
>> No. Further back. When a hard drive was huge if greater than 30MB.
>
> What am I ever going to do with all this disk space? There is a
> corollary of Moorse's Law that pertains to executable and data bloat.

s/Moorse's/Parkinson's/

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana

Il 11/08/2021 18:52, Charlie Gibbs ha scritto:
> s/Moorse's/Parkinson's/

Moore's

On 2021-08-11, jak <nospam@please.ty> wrote:

> Il 11/08/2021 18:52, Charlie Gibbs ha scritto:
>
>> s/Moorse's/Parkinson's/
>
> Moore's

True, but I figured I'd used up my nitpicking allowance.

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana

Il 12/08/2021 18:37, Charlie Gibbs ha scritto:
> On 2021-08-11, jak <nospam@please.ty> wrote:
>
>> Il 11/08/2021 18:52, Charlie Gibbs ha scritto:
>>
>>> s/Moorse's/Parkinson's/
>>
>> Moore's
>
> True, but I figured I'd used up my nitpicking allowance.
>

Do not worry. The culprit is rbowman and his bad habit at the fishing.
XDD

On 08/12/2021 12:32 PM, jak wrote:
> Il 12/08/2021 18:37, Charlie Gibbs ha scritto:
>> On 2021-08-11, jak <nospam@please.ty> wrote:
>>
>>> Il 11/08/2021 18:52, Charlie Gibbs ha scritto:
>>>
>>>> s/Moorse's/Parkinson's/
>>>
>>> Moore's
>>
>> True, but I figured I'd used up my nitpicking allowance.
>>
>
> Do not worry. The culprit is rbowman and his bad habit at the fishing.
> XDD

Man, you don't want to know about the rest of my bad habits...

Le 10-08-2021, Andreas Kohlbach <ank@spamfence.net> a écrit :
> On Mon, 9 Aug 2021 07:56:15 -0600, rbowman wrote:
>>
>> Back when a 1 GB hard drive was huge, the choice between Vim and Emacs
>> was a no-brainer. iirc Vim was 1.6 MB, Emacs was 25 MB. It looks like
>> gVim has porked up to 2.7.
>
> The on my first PC 1995 had 1300 MB. In late 1997 I split it between
> Windows 95 (850 MB) and installed Linux (rest including swap space). No
> space for a GUI. May be I could had installed Xfce or something. But the
> CD, which came as bonus on a magazine, only had KDE, and I was a bloody
> n00b not even knowing what KDE is.

I don't remember kde being available so soon. At this time the most
beautiful and heavy WM I heard about was enlightenment. For the others
which didn't have a powerful computer, there was fvwm which as very
light.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Il 09/08/21 06:19, rbowman ha scritto:
> On 08/08/2021 07:11 PM, Jeff-Relf.Me@. wrote:
>> Bowman:
>>> I'm not a power user of the VS editor but
>>> 35 years later it seems to lack the features of Brief.
>>
>> My macros & extensions to Visual Studio 2019:
>> http://Jeff-Relf.Me/Macros.HTM
>>
>> In Visual Studio, I'm editing a small, recently opened
>> text file.
>> AutoRecover is turned off.
>>
>> For that, it's consuming 1.8 gigabytes of RAM, and growing
>> rapidly;
>> occasionally, it drops back down to "just" 1.2 gigabytes.
>>
>> Just now, it disappeared from the task manager altogether,
>> showing up again only after ReStarting the task manager.
>>
>> Every time I debug my app, memory usage goes up,
>> briefly topping 2 gigabytes, _after_ exiting the
>> app/debugger.
>> Hmmm... it's a memory leak, apparently.
>>
>> I ReStarted Visual Studio, now it's consuming 186 megabytes,
>> no more memory leaking.
>>
>> "while(1);" borks Visual Studio, apparently.
>>
>
> It would tend to do that. Even a more complex while
> statement that doesn't have any natural points where it will
> block will try for 100% of the cpu. At least now it only
> ties up one core.

It is not selfevident to me why an infinite loop should be
supposed to eat up RAM ...
CPU time maybe yes, but why high RAM consumption ?

Recursion of calls to procedures consumes RAM (even if on
many compilers that don't let grow limitlessly automatic
memory, but the stack has a maximum size and then the
overflow kills badly the process : the stack overlaps and
collide with read only data, with "code", with areas
belonging to other processes, seg-faulting, etc).

To produce similar leaks, I think (I'm just saying an
opinion, not a truth) some conditions might operate :

an infinite recursion of calls to procedures that have a
very limited (or negligible) stack signature (i.g. no
parameters passed, maybe not even a return value) and
internally performing some heavy "dynamic allocation, i.g.
by specialized constructors or else).

also routines that works on objects encapsulating arrays
that assume to pass By Value (not by pointer or reference),
when called in nested mode, will need to copy large amount
of data, in dynamic ram.

Or even some mis-written or generated "destructors" that
don't clean-up properly dynamically allocated objects (i.g.
bad string allocators in programming manipulating a lot of
rw strings). Or both.
A memory leak can have a lot of fathers and mothers. But,
imho, not a simple infinite loop in itself.

If i think sth like this

String A = "";
while (1)
A &= "x";

the memory usage would explode, sure, depending on the
placement of the chained string A ....

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)