From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by hurricane.the-brannons.com (Postfix) with ESMTPS id D3F86778A0 for ; Thu, 6 Feb 2014 03:30:01 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hn9so1470172wib.6 for ; Thu, 06 Feb 2014 03:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=rX8iPPQdpYxNvmb0ITF9sm3vbDJohmsXTtkCBeLnBvo=; b=XLYTLz54AcQWs99iDdoB4Dbk8qAn11/ydxXZowgaYD+JkOAr7ma4hpfQ6qbz40JZGu B/+7PfVixWoVxTRqxupMeEx/VCz8GZyv1WUg23krtdk5yf7oPKjTL0EgPUemGW9uf7Ua o+2f2gOasbDNwF2vRtmJ1AOj0V1y1jEkR8iN9dgPjb5nvRev5NKbuopdvR9mi/gibWQr QxaAx8HlnoMwN1S9J61NCe3b973hmlrxH46BYvqJoZcuH7W79Zdz3UoX8Wlihrj6uxLU lBmYfYSZT5337N0JKU242XnKbOo0mkQK4tbk29ctvujlEUvusH1qiBSdTUxCph5RfMSg eDjw== X-Received: by 10.194.161.136 with SMTP id xs8mr1140988wjb.56.1391686166201; Thu, 06 Feb 2014 03:29:26 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id ju6sm1684642wjc.1.2014.02.06.03.29.24 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 06 Feb 2014 03:29:25 -0800 (PST) Date: Thu, 6 Feb 2014 11:29:22 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140206112922.GT32200@toaster.adamthompson.me.uk> References: <20140105182116.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140105182116.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] text line manager X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 11:30:02 -0000 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.