🚀 go-pugleaf

lron@easy.HIAM (Dwight Hubbard) writes:
> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>> lron@easy.HIAM (Dwight Hubbard) writes:
>[previous junk removed]
[ditto]

> Are we talking about software VM (which in my opinion is a waste of
> time) or editing files larger than physical memory (a very nice
> ability to have) adding VM just to edit files larger than memory is a
> waste.[...] The basic principles for editing a file larger than
> physical memory are quite different than writing a software VM system
> that would have to worry whether or not the system is going to crash
> if this particluar chunk of code gets swaped out.

I think we agree on the right thing to do, but maybe not on how to do
it. I'm not really interested in virtual memory for code, just for data.
Truely huge pieces of code that overwhelm the hardware need to be
overlaid anyway; the intelligence that can be added by a careful overlay
scheme will always allow it to beat software code VM.

Another poster has suggested, and I wish to promote the idea, that we
should have a library (or handler, I'm not clear on the implications of
one against the other) that captures the best available design for
software data VM, so that this facility is easily available to
programmers otherwise not capable of developing it, or with other work
to do than redeveloping the wheel.

As a checklist for what this facility should provide, an editor is a
pretty good worst case, particularly one, like emacs, that is capable of
opening multiple windows in multiple files simultaneously, and in
multiple instances of the editor running at once. You can't just work in
blocks, since the addition of text in any of the windows will change the
byte boundaries of all the blocks, and scrolling multiple, modified
windows at once in the same file (a facility of some multiple windows
editors) is going to keep any design hopping to keep up.

I guess what I want to say is that this is such a complex task that it
needs to be done well once, and made generally available, rather than
done as a compromise of the available time to devote to each product.

It doesn't have to do "magic" (capture every pointer use and resolve it
to currently in-RMA data); just provide a way to get and confirm handles
on data, with the necessary paging in and out, and shifting of bytes
within blocks, done as needed.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>