From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by hurricane.the-brannons.com (Postfix) with ESMTP id 8AEB1783FF for ; Wed, 5 Feb 2014 15:21:47 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta13.westchester.pa.mail.comcast.net with comcast id Nd881n0071ei1Bg5DnME9z; Wed, 05 Feb 2014 23:21:14 +0000 Received: from eklhad ([107.5.36.150]) by omta24.westchester.pa.mail.comcast.net with comcast id NnME1n00X3EMmQj3knMEZB; Wed, 05 Feb 2014 23:21:14 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Wed, 05 Feb 2014 18:21:16 -0500 Message-ID: <20140105182116.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391642474; bh=+zDAN/zQiGNTm6Ztihgt2Q0V7x5QSL7Q2IKE8kbd6so=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=QrURvWvs2iR+RTCQ5sriXk41ejuL6Oaq9b+JAKhjTChUMPp5ubk3WpWjIw+VW+EkX RX2xOSOsSmTchwLilQXJ9Ae4EBy2mw7gqYcIqZ9pvV+kEap2Sbi2LVNgGfqZS5euiB 72p0V8KWnCCd8aHy3T7Kcz811BwNffag6hN3pZpvdX8cgwHqzuQi3efeU7Nkg0ykP6 wGcWCPISJ73kgYYvkIVzvC9im3C5lD2flyDN4qHD9znkwz6CdiyVl5MvgllqheSqNb WUt7Cdysx2e+pO4XdKY3FKWfbFLH3zmMD9BGc5LsfEHdi4Ufy88YUjQRFRHk8XrIc0 pBREVxoYiYgWQ== Subject: [Edbrowse-dev] text line manager X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Karl Dahlke List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:21:47 -0000 > 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