[Toybox] [PATCH] vi: mem_block/piece_table part 2

[Jarno Mäkipää]

On Mon, Jan 20, 2020 at 2:31 AM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 1/19/20 3:21 AM, Jarno Mäkipää wrote:
> > If this proof to be too complicated, I can redesign with buffer_gap on
> > top of this.
>
> I haven't opened the vi review can of worms yet. (I haven't gotten back to the
> bc review in months. I'm trying to finish toysh.)
>
> If this is the direction you want to take, I'll apply the patches. (You seemed
> unsure so I asked for confirmation, and you didn't confirm.) My only concern is
> that Elliott has been patching your stuff, implying he's using your stuff out of
> pending. (I'm not yet.)

Yes I was and am unsure, so I wanted some pointers from you and
Elliott. Thank you for your time. Every advice has been helpful on one
way or another.

Elliott is building this out of pending, so I dont want this to be
applied if he is not ok with it. his idea of using buffer gap instead
is better for common cases, and for minimal code size and complexity
if our features are kept small.

Anyway I had fun hacking, lets wait for Elliott to reply if he thinks
it ok to apply or not.

>
> > But goals should be set up first, if aiming for mostly
> > full POSIX vi compliance I have feeling that with buffer gap some
> > features like marks are hard to implement, since lines before mark
> > changing should not effect mark position.
>
> Rule of thumb here: busybox has had a vi for coming up on 20 years, if it's
> still missing a feature it is at least possible to do with out it. (That doesn't
> mean you shouldn't do it if you want to, just that a critical mass userbase
> hasn't bothered to submit a patch implementing it yet.)
>
> > Also ability to mmap big
> > junk of data will be lost, and buffer_gap requires malloc continuous
> > region of filesize+few bytes for gap, this system I wrote could
> > fallback to loading file in page size  inmemory chunks, without
> > modifying any logic.
>
> I remind you that 32 bit mmap maxes out somewhere around 2 gigabytes, depending
> on the memory layout of the architecture in question. (Virtual address space
> within a process becomes a limiting factor.)

Yeah cant support everything on few hundred lines of code.

Jarno

>
> Define "scalability"...
>
> Rob