[Edbrowse-dev] text line manager

[Edbrowse-dev] text line manager

[Karl Dahlke]

> but I'd rather get all the good things we're doing at the moment stable and
> ready for release

Oh definitely.
And to this end I have made my last substantial push,
hoping that all future changes are small bug fixes.
Then maybe in a month or two we call it a release.

This change removes any hard limit on the number of lines
in the ongoing edbrowse session, and has a new bookkeeping procedure thereof.
Garbage collection for strings / lines is described in buffers.c line 443.
The limit you will reach now is out of ram malloc failure,
which exits somewhat ungracefuly,
but is still better than a seg fault.
Actually in a large system, with large files, we could overflow the integer,
and not realize it until indexes are bad and trouble.
We need to globally use size_t instead of int when building our growing strings
and indexing arrays and so on.
Adam's right though, save that for the next version.
Nobody has overflowed an integer index yet.

Now for the warning.
I have the disclaimer in README about how I'm not responsible
if edbrowse trashes your files, and it never happened to me before,
but it did a couple of days ago.
It was my first rewrite of the text line manager,
and I edited a small file and it worked great, so being coky,
I made a small change in a large file, an important file,
without a recent backup, and saved, and the whole file was corrupted.
I was pissed!
I fixed that bug, and have been using edbrowse, and am still using it, even now,
but I would encourage you to run system backups,
and maybe even have a spare edbrowse executable around,
and then give it a whirl.
It is time for caution, but,
never up, never in.

Also a new debug level 8, that helps me debug the text line manager.
Shows each line of text that is freed.
Lots of output, so only use it on small files.
Remember, lines not in the buffer
may still have to stick around for the undo command,
then finally go away on the next undo command;
but sometimes an old line should be freed right away,
like in directory mode where there is no undo command,
or when browsing, wherein javascript side effects make undo impractical.
It's just more complicated that it first seems,
but I have db8 going now and it looks ok,
so give it a try if you dare.
My next brave moment is trying it on a database.
One thing to trash a file, another to trash an entire sql table.
Hopefully that won't happen.
And that's another venu without an undo command,
so I need to watch the text manager.

Karl Dahlke

Re: [Edbrowse-dev] text line manager

[Adam Thompson]

On Wed, Feb 05, 2014 at 06:21:16PM -0500, Karl Dahlke wrote:
> > but I'd rather get all the good things we're doing at the moment stable and
> > ready for release
> 
> Oh definitely.
> And to this end I have made my last substantial push,
> hoping that all future changes are small bug fixes.
> Then maybe in a month or two we call it a release.

Yep, as a first test I've pulled and compiled and am using it to edit this message.

> This change removes any hard limit on the number of lines
> in the ongoing edbrowse session, and has a new bookkeeping procedure thereof.
> Garbage collection for strings / lines is described in buffers.c line 443.
> The limit you will reach now is out of ram malloc failure,
> which exits somewhat ungracefuly,
> but is still better than a seg fault.
Exiting on malloc failure is perfectly fine (though would it be better/possible to just
zap the current buffer and allow the user to save other work I wonder).

> Actually in a large system, with large files, we could overflow the integer,
> and not realize it until indexes are bad and trouble.

That sounds like a rather unfortunate thing to happen (particularly if indexes
are signed and thus wrap to negative).

> We need to globally use size_t instead of int when building our growing strings
> and indexing arrays and so on.
> Adam's right though, save that for the next version.
> Nobody has overflowed an integer index yet.

Yep, though I wonder if switching to unsigned ints would be a large change.
Doing so would somewhat mitigate the situation in the meantime whilst not
breaking the bit math (at least I think it won't).

> Now for the warning.
> I have the disclaimer in README about how I'm not responsible
> if edbrowse trashes your files, and it never happened to me before,
> but it did a couple of days ago.
> It was my first rewrite of the text line manager,
> and I edited a small file and it worked great, so being coky,
> I made a small change in a large file, an important file,
> without a recent backup, and saved, and the whole file was corrupted.
> I was pissed!
> I fixed that bug, and have been using edbrowse, and am still using it, even now,
> but I would encourage you to run system backups,
> and maybe even have a spare edbrowse executable around,
> and then give it a whirl.
Generally system backups are good practice anyway,
though editing critical files without backups is something I do more than I
care to think about.

> It is time for caution, but,
> never up, never in.

As someone who runs a debian unstable system (with some experimental packages
sometimes) I totally agree with you.

> Also a new debug level 8, that helps me debug the text line manager.
> Shows each line of text that is freed.
> Lots of output, so only use it on small files.
> Remember, lines not in the buffer
> may still have to stick around for the undo command,
> then finally go away on the next undo command;
> but sometimes an old line should be freed right away,
> like in directory mode where there is no undo command,
> or when browsing, wherein javascript side effects make undo impractical.
> It's just more complicated that it first seems,
> but I have db8 going now and it looks ok,
> so give it a try if you dare.

Yep, am running with db8 out of interest.

> My next brave moment is trying it on a database.
> One thing to trash a file, another to trash an entire sql table.
> Hopefully that won't happen.
> And that's another venu without an undo command,
> so I need to watch the text manager.

Yeah that'd be... unfortunate.

In addition, I've pushed my warning squash in url.c so now it builds cleanly on
amd64 (this push was delayed for a few hours whilst debian sorted out their
dependancies in unstable which temporarily broke libcurl).
All working now though (well until the next time I run into a js bug and lose
all my work, happened a couple of days ago).
Actually, I should probably add a warning that,
when doing work in one buffer and web browsing in another,
one should save one's work before switching web pages unless one knows the site
is edbrowse-safe. This applied before,
but it was rather annoying to lose part of an assignment to someone's
over-engineered js.

Cheers,
Adam.