From strandh at labri.fr Tue Oct 17 16:25:20 2006 From: strandh at labri.fr (Robert Strandh) Date: Tue, 17 Oct 2006 18:25:20 +0200 Subject: [flexichain-devel] patches for weak pointers Message-ID: <17717.1008.421275.629645@serveur5.labri.fr> Hello, I just realized I was not on the Flexichain mailing list, which is why I haven't applied the patches. Better late than never, I guess. Thanks again! -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From brad.beveridge at gmail.com Tue Oct 24 20:26:10 2006 From: brad.beveridge at gmail.com (Brad Beveridge) Date: Tue, 24 Oct 2006 13:26:10 -0700 Subject: [flexichain-devel] A couple of flexichain questions Message-ID: I recently put an editor project on common-lisp.net (http://common-lisp.net/project/vial/). Troels contacted me and rightly asked why I didn't use Flexichain to implement my buffer (I use a linked list of strings basically). I've thought about the two methods (gap buffer vs linked list of lines), and basically the performance for either method is probably about the same for most operations. The one big place that a gapbuffer wins is when you want to treat a large section of the buffer as a read-only string. For a list of lines you need to cons up a new string, for a gap buffer (assuming it is locked), you simply need to move the gap and take a pointer into the gap buffer. I envision using this "large string" mode of the gap buffer for: - searching one huge string with CL-PPCRE - saving the buffer in one call So after all my rambling I have two questions: 1) Is it appropriate to use Flexichain in this "one large string" manner? Obviously you don't want to always convert to this form, but it is handy for running a search on the buffer and some other uses. 2) What is involved in creating a function that consolidates the data into a contiguous chunk that is suitable for creating a displaced array into? Thanks Brad From strandh at labri.fr Wed Oct 25 06:10:19 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 25 Oct 2006 08:10:19 +0200 Subject: [flexichain-devel] A couple of flexichain questions In-Reply-To: References: Message-ID: <17726.65483.50773.872386@serveur5.labri.fr> Brad Beveridge writes: > I've thought about the two methods (gap buffer vs linked list of > lines), and basically the performance for either method is probably > about the same for most operations. Probably. However, a list of strings will have very bad performance if you want to edit code with very long lines. My intention for Climacs was to eventually use a tree of flexichains. > The one big place that a > gapbuffer wins is when you want to treat a large section of the buffer > as a read-only string. For a list of lines you need to cons up a new > string, for a gap buffer (assuming it is locked), you simply need to > move the gap and take a pointer into the gap buffer. Sure. > I envision using this "large string" mode of the gap buffer for: > - searching one huge string with CL-PPCRE > - saving the buffer in one call > > So after all my rambling I have two questions: > 1) Is it appropriate to use Flexichain in this "one large string" > manner? Obviously you don't want to always convert to this form, but > it is handy for running a search on the buffer and some other uses. I think it would work pretty well. > 2) What is involved in creating a function that consolidates the data > into a contiguous chunk that is suitable for creating a displaced > array into? Well, there is an additional complication. A Flexichain is circular, so its logical beginning could be in the middle of the physical array. Aside from that, you just have to move the gap to the right place, I would think. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------