You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(40) |
Jun
(19) |
Jul
|
Aug
(17) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(4) |
Feb
(15) |
Mar
(59) |
Apr
(4) |
May
|
Jun
|
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(75) |
Aug
(4) |
Sep
|
Oct
(11) |
Nov
|
Dec
|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(11) |
Nov
|
Dec
(1) |
From: Reuben T. <rr...@sc...> - 2012-12-24 18:47:40
|
You can now build and install zee directly from git: luarocks build https://github.com/rrthomas/zee/raw/master/zee-git-1.rockspec Merry Christmas! -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2012-10-31 22:47:14
|
Further to this, you will need the git head of LuaRocks from https://github.com/keplerproject/luarocks, or release 2.0.10 (the current 2.0.11's make install is broken); 2.0.9, as shipped in Ubuntu quantal, may work (it has the necessary Lua 5.2 support), but anything older definitely won't, and there's quite possibly a patch somewhere since then that I rely on in one of the various packages above. |
From: Reuben T. <rr...@sc...> - 2012-10-31 22:36:26
|
Zee 0.7 is out! I hope it will be available as a rockspec soon from www.luarocks.org, but in the meantime you can go there and install LuaRocks (taking care to ./configure --lua-version=5.2), then run something like: git clone https://github.com/rrthomas/zee.git cd zee luarocks install stdlib luarocks install luaposix luarocks install lrexlib-gnu # you better be on a GNU system luarocks install alien ./bootstrap ./configure # with appropriate flags for your Lua installation make && make install On second thoughts, you may want to wait for the rock. But I will be happy to help anyone with the above steps, especially they're willing to help get a publishable recipe for developers. (Luarocks supports installation directly from VCSes, but that won't currently work with Zee because the rockspec is not checked in but generated from source, and it needs to run Zee in order to generate it.) That's it for planned Zee development for now, but I do intend both to simplify the build system (possibly avoiding the use of autotools altogether) and start adding some Zee-specific functionality, hopefully before the end of the year. Future Zee news will of course go only to the Zee list unless it happens once more to concern Zile for some reason! |
From: Reuben T. <rr...@sc...> - 2012-10-31 19:45:56
|
I've finished with Zile in Lua for now. I have not pushed a rockspec, because that requires making Zile completely relocatable, a problem I have solved for Zee, but not Zile, because the latter needs to find resources, not just Lua source files. However, I did mostly finish the implementation, so I've pushed that on the "zile-lua-rockspec" branch. In any case, a rockspec is not that useful for developers, as in order to make the actual rockspec you need to install, you already need to have built the source, for which you need to have installed the dependencies. I have added a note pointing out that you can install the dependencies with LuaRocks. All the required versions of dependencies are now released. Gary (or anyone else working on taking Zile Lua to releasability), please do ask if there's anything I can clarify. I've tried to leave things in a reasonable state (the tests and make distcheck pass), but I've undoubtedly overlooked things. -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2012-10-27 00:45:53
|
I have a rockspec for Zee which builds and installs it. Unfortunately, it doesn't run, because LuaRocks configures its packages to install in a temporary directory, and then itself moves the files elsewhere. This means that the paths hardwired into Zee are wrong when it runs. I think it's not too much of a problem to simply configure with the correct deployment paths (LuaRocks won't mind when it doesn't find any files to move), but unfortunately this looks like needing a patch to LuaRocks, as it doesn't currently make the deployment paths available in rockspecs, AFAICS. Sigh. At least once this is sorted out, writing rockspecs to drive autotools build systems should be a pretty much solved problem… -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2012-10-25 19:43:48
|
I've finished working on Zile's code. I've just pushed commits to update it to work with 5.2, removing the debugger (ldb) for now, though that shouldn't be too difficult to update too; I didn't bother since I've never found it useful. The last thing I have to do is to write rockspecs, which I'm doing in parallel with doing it for Zee, in preparation for the Zee 0.7 release (0.6 was in 2006!). At that point I'll also stop working on Zee for a while in order to focus on some other projects with rather tight deadlines, but I hope to be back before the end of the year to start implementing one or two seriously interesting things in Zee. |
From: Gary V. V. <ga...@gn...> - 2012-10-23 05:58:01
|
Hi Reuben, I'm getting married next week, so my hacking time has been (and until after my honeymoon, will continue to be) severely curtailed. In a spare hour last night, I tried to get zee and the newest lua branch up and running with an eye to rebasing zi to pick up the recent fixes. However, it is as painful as ever to build everything, even though luarocks are available, they are not ported to Mac, and only build with a lot of manual intervention. Please forgive the brain dump below. This is as much a note to myself so that I don't forget what I discovered as anything, but advice on how best to proceed, or better still patches to fix some of the problems I'm stuck on would be very welcome too :) First Zee: 1. It appears Zee requires lua 5.2, but Homebrew doesn't seem to support side-by-side 5.1 and 5.2. Which is normally fine (you can switch back-and-forth between different versions without reinstalling), except that if you have a luarocks installed over the inactive lua, it refuses to run. Looks like I need to build my own 5.1/5.2 capable dev environment, each with it's own luarocks installation unless I can figure out how to get luarocks built on 5.2 to install rocks to the lua 5.1 paths... 2. lrex-gnu picks up Apple's BSD regex.h, and ends up with unresolved symbols. I managed to download the latest release zip, and fudge the luarocks build spec to link against manually compiled gnu regex.[ch] and supporting files from gnulib to get a working lrex_gnu.so. I don't think the luarocks build specification is advanced enough to be patched so that it will ship, compile and link against those extra objects where GNU regex is not standard on the build machine. I'm also worried that without more compiler specific help (libtool?), the gnu regex symbols will leak out of lrex_gnu.so and clash with any client that wants to use it, but is also linked against it's own gnu regex objects from gnulib (or elsewhere). The gnulib build tries to fix that problem with "#define re_compile rpl_re_compile" etc for each entry point in its own config.h, but then lua and/or lrex_gnu.so fails to find the undecorated symbols at runtime and bails out with an unresolved _re_compile error - for now I've hand compiled everything and ignored the potential symbol leak issues, so I can at least require "lrex_gnu" without everything falling over :) 3. alien requires a libffi that's newer than the one shipped in the standard locations by Apple. Homebrew puts a sufficiently new one in /usr/local/opt/libffi, but it seems the only way to provide that information to the luarocks build is to pull the alien zip file down and manually compile and install it with: CPPFLAGS=/usr/local/opt/libffi/lib/libffi-3.0.11/include \ LDFLAGS=/usr/local/opt/libffi/lib luarocks make alien-0.7.0-1.rockspec Why doesn't 'luarocks install' respect CPPFLAGS/LDFLAGS? It looks like luarocks config files might be able to help with this if I can figure out how to add higher priority library and header search paths into it to make it ignore the too-old system libffi. 4. With all the hand compiled modules in place, after './bootstrap && ./configure' in zee HEAD, 'make' fails when help2man tries to run 'src/zee --help' because Mac OS doesn't have memrchr. I see you have a TODO to write a fallback... where would that live? memrchr.c -> memrchr.so in zee? An enhancement to alien? Maybe in luaposix.so? There is a nice implementation of memrchr() in gnulib already, but I don't know where to put the object for best separation of concerns and transparent calling with alien from Zee. Next up, Lua Zile: 1. Lua Zile still wants lua-5.1 and alien-0.6.1 according to loadlua.lua.in. I made a quick attempt at fixing up the sources to run with lua 5.2 and the modules I already painstakingly built for the Zee branch, but I don't really understand how to idiomatically move from 5.1 setfenv to some 5.2 equivalent. I just commented out reliance on that ldb.lua just to make progress, and in lisp.lua where I made this naive change: diff --cc src/lisp.lua index ffefb1e,ffefb1e..fbf4bf3 --- a/src/lisp.lua +++ b/src/lisp.lua @@@ -47,7 -47,7 +47,7 @@@ function Defun (name, argtypes, doc, in arglist = arglist.next i = i + 1 end -- setfenv (func, setmetatable ({current_prefix_arg = prefix_arg}, ++ debug.setupvalue (func, 1, setmetatable ({current_prefix_arg = prefix_arg}, {__index = _G, __newindex = _G})) prefix_arg = false local ret = func (unpack (args)) I'm not even sure that is equivalent, and using the debug library in the core like that feels wrong too, so I need to wrap my head around how _ENV works so that I can rewrite that section of code idiomatically when I have everything else working. 2. At this point, trying to run src/zile falls over in term_redisplay.lua with: Internal error. Please report this bug with steps to reproduce the problem /usr/local/share/lua/5.2/base.lua:475: stack traceback: [C]: in function 'error' /usr/local/share/lua/5.2/base.lua:475: in function 'assert' .../zile/src/term_redisplay.lua:35: in function 'make_char_printable' .../zile/src/term_redisplay.lua:62: in function 'draw_line' .../zile/src/term_redisplay.lua:171: in function 'draw_window' .../zile/src/term_redisplay.lua:232: in function 'term_redisplay' .../zile/src/getkey.lua:57: in function 'getkey' .../zile/src/bind.lua:157: in function 'get_key_sequence' .../zile/src/bind.lua:80: in function 'get_and_run_command' .../zile/src/main.lua:309: in function <.../zile/src/main.lua:218> [C]: in function 'xpcall' src/zile:49: in main chunk [C]: in ? 3. I need to remove all the Homebrew and manually installed lua builds and modules, and work out how to have lua-5.1 with alien-0.6.1 and lua-5.2 with alien-0.7.0 side-by-side to confirm that the new lua Zile HEAD revision still works with older libraries, and then try again with rebasing zi and lpeg syntax-highlighting branches, before make an official attempt at porting Lua Zile to Lua 5.2. I might punt on all of this at my next session, and just try things out in a Linux VM to confirm that it's all Mac OS portability issues that I can tackle gradually, before getting drawn into too much low-level work, and not getting to work on Zile for a while longer as a consequence. I've also upgraded to latest stdlib and luaposix/curses, which didn't seem to have any issues, but everything is so broken in my environment right now, I don't want to rule out any of the changes I made as being involved in one or more of the issues above. My current impression is that portability of alien and lrex_gnu in particular is held back by the luarocks build system, and a few tweaks to allow passing preferred library and header directories before calling 'luarocks install' would be a good place to start at getting things back on track. lrex_gnu is essentially Linux- (or at least glibc-) only as it stands, and needs a complete build system overhaul to have any chance of working out-of-the-box on anything without GNU regex in the system library. On 14 Oct 2012, at 07:41, Reuben Thomas <rr...@sc...> wrote: > I've done the code review of C Zee. I have a couple of things left to > integrate, in the terminal display, but the vast bulk is done. I have > a handful of other TODOs to do. Would be cool if you could commit your TODO incase I can help out on anything, or at least not start pulling in the opposite direction by mistake :) > As a bonus, I found and fixed one more inefficiency, in reading the > file: it slurped into a Lua string, then made an AStr from that. It > now reads directly into an AStr, using alien to bind read. This looks > like it ought to go in luaposix, but while it's easy to have > polymorphic arguments in Lua functions (as I have done in lrexlib for > searching AStrs directly) it's not obviously possible to have > polymorphic return types without some way of indicating what type you > want back, which will necessitate changing the interface to > read/write, e.g. by adding a flag indicating that you'd like a raw > memory block rather than a string, or perhaps even giving a > constructor function (more complicated, but more flexible). One to > think about. You're several steps ahead of me on this stuff. However, on a related note, libposix in gnulib has hit a brick wall :( ASIDE: libposix being a separate library and headers that are a subset of gnulib to act as a shim between the non-conformance system libc APIs and the full and correct POSIX APIs, such that with libposix.so (and headers) installed, everything will just work when your code is strictly POSIX API only, and you pass -L/usr/local/posix/lib -I/usr/local/posix/include -lposix to the compiler. Even so, I think this would be the cleanest solution to some of the portability concessions made in luaposix, the memrchr dependency in Zee, and to the requirement for a system GNU regex for lrex_gnu to build out of the box. I wonder whether the best way out of the current mess is to start a minimal libposix project with just enough in it to support the lua modules we need. Maybe that would start to build enough momentum to get an official version through the gnulib brick wall too. > The commits are a bunch of big gloopy messes, sorry. Tsk. Better than no commits at all though, eh? ;) > On the other hand it's pretty easy to examine the code to find useful > patches for Zile/Zi, and even if I'd separated out the commits they > wouldn't on the whole have applied cleanly: Zee is just too different. Once I have all of the above working again, I'll start to think about how to get all of Zile/Zi/Zee into a single branch, and figure out a nice way to select which flavour you want to play with, but without all the nasty branch hopping and lua version switching currently entailed! Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) |
From: Reuben T. <rr...@sc...> - 2012-10-14 00:41:59
|
I've done the code review of C Zee. I have a couple of things left to integrate, in the terminal display, but the vast bulk is done. I have a handful of other TODOs to do. As a bonus, I found and fixed one more inefficiency, in reading the file: it slurped into a Lua string, then made an AStr from that. It now reads directly into an AStr, using alien to bind read. This looks like it ought to go in luaposix, but while it's easy to have polymorphic arguments in Lua functions (as I have done in lrexlib for searching AStrs directly) it's not obviously possible to have polymorphic return types without some way of indicating what type you want back, which will necessitate changing the interface to read/write, e.g. by adding a flag indicating that you'd like a raw memory block rather than a string, or perhaps even giving a constructor function (more complicated, but more flexible). One to think about. The commits are a bunch of big gloopy messes, sorry. On the other hand it's pretty easy to examine the code to find useful patches for Zile/Zi, and even if I'd separated out the commits they wouldn't on the whole have applied cleanly: Zee is just too different. -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2012-10-10 21:36:42
|
Nearly done, now. I've given up trying to get minor modes working, i.e. getting isearch & minibuffer into the main loop. On the other hand, I've done quite a lot of work towards it: you can have more than one keymap, and term_minibuf_read is rewritten in terms of Defines. It's now a sort of alternate main loop. It's tricky but entirely possible to finish; I've simply run out of time for now. I need to get Zee out, Lua Zile buildable with release libraries, and out of here on to other projects. The final thing I'm doing is reading through all the C Zee source to extract all the remaining tricks I've used there. There are still a few good ones left un-re-exploited. -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2012-10-04 22:57:18
|
Still going! The Zee command list is now as at parity with the C version as I intend (I've left some extras in, and one or two out; nothing major). I have found some other things to do: I want to copy the C Zee docstrings where necessary (extracting every last ounce of work I did on C Zee!), and copy the C Zee keybindings (I had two sets, Emacs and CUA style). Before splitting off into a new repository, I also intend to complete some more work which could be used in Zile/Zi (Zi is Gary Vaughan's take on "Zee"), and hence which will be much more useful if it's in the same repository. In particular, I want to generalize the use of keymaps and the main loop to work with isearch and the minibuffer. I've attempted this before in Zile, but given up because of the major surgery required; in Lua Zee it's as easy as it's ever been and less dangerous if it proves tricky. There are plenty of other more revolutionary things to do, but they're correspondingly of little interest to Zile, at least, and can wait for the move to the new repo. This leaves only one interesting piece of work in C Zee which I won't be migrating, namely the rblist-based buffer structure. I have some ideas about reimplementing the buffer for editing really large files and structured data, and persistent undo history/log-structured editing, which may involve their reintroduction. So, a new estimate of several days' work to redo the keymaps/main loop. The only other work I intend to do on Zile (other than essential maintenance to the C branch, which has also occupied me for a few hours recently) is to make sure that Lua Zile works with all the latest libraries (most of which I've made or caused to have made new releases of in the last few days). In particular, I need to make it work with Lua 5.2 and alien 0.7 (which introduces minor backwards incompatibilities). Zile Lua will then NOT be up to date with all the performance enhancements now in Zee, but they *will* be available for easy backporting (or cross-porting to Zi). |
From: Reuben T. <rr...@sc...> - 2012-10-03 01:43:06
|
Still going! I have now removed all but one call to AStr's tostring method (in fact, I overlooked one last time, which is to do with displaying the popup window, which I've left in, as I believe it's acceptable, as it only ever runs tostring on portions of the popup window as wide as the terminal). In particular, the conversion of the entire buffer to a string every time it was searched is now gone. I have adapted lrexlib to work directly with buffers as promised; this should be in a new release shortly. The total code length is now 3,457 lines. This about the same as the 3,500 I claimed last time, but that was definitely wrong. Actually, the figure I gave for C Zee was wrong too: it should be 4,884 (I said 4,400). So in fact the Lua:C branch ratio is now down to 70%, the same as that for Zile. That's lucky because there's not much immediate scope for reduction. The remaining work to do before replacing C Zee with Lua Zee is to bring the command list to parity. This involves the addition of about nine mostly trivial commands (I have made one or two design changes relative to C Zee, so the result won't be identical). -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2012-09-25 14:44:44
|
Thanks, Tom. GitHub it shall be. |
From: Tom L. <to...@fi...> - 2012-09-25 13:37:04
|
On Mon, 24 Sep 2012, Alistair Turnbull wrote: > On Fri, 21 Sep 2012, Reuben Thomas wrote: > > > AFAICS, the obvious choices are SourceForge, GitHub or BitBucket for > > the host, and Git or Mercurial for the DVCS. Other options entertained > > if you argue them persuasively. > > I have a slight preference for Mercurial, because it keeps out of the way > better, but would be happy with git which I have also used. I'm a bit out > of touch with the hosting options, so I'm happy to go with whatever you > think is best. If github is damn good, that would be reason enough to use > git in my eyes. github isn't damn good as far as I can tell, but does probably have sufficient useful collaboration features that bitbucket lacks (and a higher rate of adding new ones) etc. that it's likely to kill bitbucket. My experiments with using both simultaneously haven't gone well (some part of the process created two branches side-by-side made from largely the same commits). All that, together with Mercurial's "killable features" of no one true branch model and no decent real-time chronolgical UI for viewing/working with the extra history complexity that it encourages I think overrides the extra git UI nastiness. Bear in mind however that this is coming from someone who has barely used git other than "git clone". I bet on Mercurial a long time ago, but it now looks like it was a losing bet, and I'm only slowly facing up to the new reality. Others without this mental baggage should just use git. Tom -- "Be excellent to each other." -- Bill S. Preston, Esq. and Ted "Theodore" Logan |
From: Alistair T. <ap...@go...> - 2012-09-24 18:55:46
|
On Fri, 21 Sep 2012, Reuben Thomas wrote: > AFAICS, the obvious choices are SourceForge, GitHub or BitBucket for > the host, and Git or Mercurial for the DVCS. Other options entertained > if you argue them persuasively. I have a slight preference for Mercurial, because it keeps out of the way better, but would be happy with git which I have also used. I'm a bit out of touch with the hosting options, so I'm happy to go with whatever you think is best. If github is damn good, that would be reason enough to use git in my eyes. Alistair |
From: Reuben T. <rr...@sc...> - 2012-09-23 20:46:34
|
On 12 September 2012 13:44, Reuben Thomas <rr...@sc...> wrote: > > I'll post again and make a release once I reach feature parity with > old Zee. My original estimate of two weeks looks reasonable, given > that I'm about a week in. Ha ha! To be fair, although I've not yet reached feature parity, I've got a long way with making Zee efficient, work that it should be possible to reabsorb into Zile in the shape of a completion of the work of implementing buffers in terms of blocks of memory. Specifically, I have removed all but three calls to AStr's tostring method. In the process I have bound several C functions with alien. At present this binding is GNU-dependent (because one of them is the GNU extension memrchr). The last three tostring calls are to do with regex pattern matching. I can't use the Lua interpreter's regex matcher (binding it with alien, though it might work, is dodgy, and it doesn't run backwards, which is needed for searching), but i think I can adapt lrexlib to allow it to work directly with memory buffers, by allowing it to be passed an object with a topointer method and a __len metamethod as the thing to match against. I'm now pitching this to the lrexlib maintainer. The alternative would be to write an alien binding for just GNU regex, which would be a little more work and much less generally useful, although it would then remove a dependency. Zee is now seriously faster: its test suite (admittedly much smaller than Zile's) has gone with just the last few changes from taking 17s to run to 7s, and the code is now under 3,500 lines in total (i.e. Lua, Makefile &c.) as opposed to 4,400 for C Zee, so not in the same proportion as Lua:C Zile yet, but heading there (target: <3100). -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2012-09-21 19:41:54
|
Greetings, I am very close to wanting to move the zee branch of Zile into a home of its own. Currently Zee is in a mercurial repository (a recent switch from Subversion). I chose Mercurial because I know it's popular with the other committers. However, Zile is held in a git repository. Other Zile hackers (whom I hope to interest in Zee) know git better than mercurial. Also however, Zee is currently on SourceForge, which to my mind has (despite the Allura makeover) failed to keep up with the competition. At least, as far as ease of collaborative hacking goes; it may well still be the best place to run a project with a large public presence. My experience of other systems is currently mostly github. I think github is pretty damn good. So, I'm interested in your views on a) choice of DVCS and b) choice of hosting site. Since there has been no work or interest in Zee that I'm aware of in the past few years, I think the cost of moving site, in terms of losing potential developers, is zero. But I would like to pick a site and a DVCS that as many people as possible are happy using. AFAICS, the obvious choices are SourceForge, GitHub or BitBucket for the host, and Git or Mercurial for the DVCS. Other options entertained if you argue them persuasively. -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2012-09-12 12:44:22
|
The combination of an existing implementation to work to (whose simple charm I am rediscovering) plus a test suite for the new implementation (I may yet be converted to TDD: at least I've now reached the point where I can bless every minute I spent cranking out the original test suite) is making progress at least feel rapid. The zee branch of Zile is now below the code count for the abandoned earlier mixed C/Lua version, and I've still got plenty of room to lower it (the job is not yet complete), so the ratio should at least match that of Zile's roughly 75% Lua:C. The one major head-scratcher I'm left with is what to do with the result: it has two perfectly logical homes, one as a branch of Zile, and one as a branch (or simple replacement) of Zee. There's some hope that it might be useful for a kernelization of Zile; but on the other hand its extreme simplicity might militate against that. Also, I'd like to encourage both former Zee developers to work on it, and current and former Zile hackers. Suggestions welcome. Two-way signpost: Zile: https://savannah.gnu.org/projects/zile/ Zee: https://sourceforge.net/projects/zee/ The current Zee code: http://git.savannah.gnu.org/cgit/zile.git/log/?h=zee (I notice that I've removed both the transpose functions and tranpose functions. Who knew that Emacs had tranpose functions?) I'll post again and make a release once I reach feature parity with old Zee. My original estimate of two weeks looks reasonable, given that I'm about a week in. -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2012-09-11 12:55:36
|
I took a problem with checking in a small fix as an excuse to upgrade the Zee project to upgrade it to the new SourceForge platform Allura, and to switch to Mercurial for the repository. Lua version based on up-to-date Zile Lua coming shortly. https://sourceforge.net/projects/zee/ -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2010-10-03 17:21:36
|
Well, not quite, there are some bits of C left which bind signals and various other features, and then call Lua, rather than the other way around, but it's only a few hundred lines, which will mostly be farmed out to libraries, and all the actual editor is in Lua and the C-to-Lua bridge (clue) has been burned. There remains a lot to do. 6 tests in the test suite currently fail, but they've been failing for a while now; I just didn't bother fixing them until I'd finished translating the code into Lua. The Lua itself is fairly nasty in places, in proportion as it's a direct translation from C. But before fixing all that, I need to fix the build system, which itself needs to vanish, or rather, be outsourced. First will be a new release of lrexlib, with GNU regex support (that is in fact ready to go, and should happen later this evening). Secondly, lcurses and lposix both need updating, and in the former case, I will probably adopt the project, as it seems to have been abandoned. lposix will need to be autoconfiscated to take advantage of gnulib, without which it will seriously hamper the portability of Zile, and with which it will greatly increase its own portability. I also have to add in the missing bits which I've bound by hand, not least getopt_long. After that, I'll make a first alpha release of Zile 2.4. At some point, I will also make another Zile 2.3 release, as I have accumulated some fixes and improvements; and I'd also like to return its code to the less verbose and more efficient structure member syntax rather than the accessor method syntax I adopted for the translation process (ironically, the Lua code I wrote with structure member syntax, so it now looks more like the C used to look). I think I owe it to the immense amount of work I've done on the C over the years to leave it in good shape syntactically, at least, even if it could do with a lot more structural TLC. Essentially, it's amazing quite how horrible a really rather small amount of code, written by just a few people over a few years, can end up. And I must already have spent the equivalent of several months' full-time work just improving the C. (Should anyone ever be interested, what remains to be done is: 1. Express the data structures better. I am going essentially to go back to a public interface, because the pure method-based interface I now have just looks horrible in C. I don't know whether something based on Chris Fraser's "Interfaces in C" might be better, or just allowing that public structure members are OK, and separating out the public from the private. Maybe in fact it's time to rewrite in C++ or Objective C, but after seeing how much better things have been able to get, I'm far from convinced that I've remotely reached the limits of how nicely one can do things in C. 2. A better dynamic string library (based on Lua's?) would make most of the memory allocation headaches go away (it's usually only strings that have an indeterminate scope). 3. Still, garbage collection would be nice. The rest applies to Lua Zile too: 4. The buffers should be implemented as ropes, or as two strings (as in Emacs). Either simplifies things; ropes scale better. 5. The minibuffer needs to be implemented as just another buffer, not a special-purpose event loop, which reimplements a mini-Zile (MILZ?) inside itself. 6. A proper buffer object with editing primitives is needed, so that we have a proper demarcation between core editing and derived editing functions. In Lua Zile this is particularly important so that we can re-start Zee, and have the current (intended) Zee interface and Zile's sitting on top of the same core. (This also implies separating the multi-buffer and windowing interfaces out, as Zee does not use them.) Some derived operations are used by both Zee and Zile; that's fine, as it's like the current derived methods in astr.c in C Zile: they're primitives from the point of view of Zile, but derived in astr.c. -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2010-05-10 11:40:39
|
A text editor (well, really, a text entry widget) in 37 rules: www.vpri.org/pdf/m2010002_lobjects.pdf -- http://rrt.sc3d.org |
From: Reuben T. <rr...@sc...> - 2009-11-28 20:33:00
|
The sort of thing I've talked about doing for Zee for years. Admittedly, this particular library does not have any specific ability to deal with text, but in the abstract it looks rather good. -- http://rrt.sc3d.org Imagine someone who has only ever heard music once |
From: Reuben T. <rr...@sc...> - 2009-01-10 23:35:51
|
A funny thing is happening: I have in the last six months or so been motivated (for reasons that are obscure to me) to work a lot on Zile. I have been fixing bugs, have done a lot of work on simplifying the code, added a test suite, and added a few small features. The strange thing is that for all sorts of different reasons I have gradually found myself redoing things that I've already done in Zee. The most recent example is that the testsuite, based on DejaGnu, is proving difficult to impossible to make work on several operating systems, and so I've decided to add the needed functionality to Zile to be able to run all the tests directly in Zile without needing a harness such as Expect provides. I am also coming round to the idea that I should rewrite Zile in Lua too (not Python, as I had been thinking, because Lua is much closer to Zile's spirit of portability and minimality). Unfortunately, or perhaps fortunately, almost none of the work done on Zee carries over directly. Perhaps fortunately in that it's all being rewritten in Zile. In many ways, Zile is now rather neater than Zee, as it's not in a state of internal flux; in others, Zee is a tighter, neater code-base, as so much has been removed. It's been interesting to see quite how much cruft and bad coding is left in Zile, mainly because of cut-and-paste coding, as far as I can tell. Of course, much of that may have been me in the past. As a result, it seems that the overhead due to the extra features in Zile is actually rather less than I feared. Zile still has nearly twice the LoC count of Zee, thanks to Zee's partial transformation into Lua, but that's precisely why the comparison is currently a bit skewed. I also plan to use rblists to unify string handling in Zile, though some profiling will be needed to improve things like loading times for large files, currently rather slow in Zee. There are some things I don't plan to use. Since Zile now uses gnulib, I have used a few simple C99 features such as the bool type, which gnulib provides where necessary, but I don't plan to update to C99, because ancient as that standard already is, people are still using Zile on ancient platforms that are no longer supported by GCC and hence unlikely ever to get a C99 compiler. Similarly, I don't plan to use garbage collection in Zile, as there's only really one portable collector, and it doesn't work on all platforms; in any case, as with Zee, the use of Lua with its own collector will obviate the need to collect garbage in C. Since I still use Zile, and Zee hasn't been stable enough for some time, it looks like Zee may well, for the present, be reabsorbed into Zile, but in the process I do plan (in the indeterminate future) to end up with a compact editor core on top of which Zile is built, which will effectively be Zee. Whatever the future is, it begins with Z. -- http://rrt.sc3d.org/ | impeccable, a. not liable to detection (Bierce) |
From: Reuben T. <rr...@sc...> - 2007-10-29 01:16:02
|
Looking at the Lua API calls left in Zee (I've been working on pushing more code into Lua, and using Clue so I don't need as many API calls) most of them, maybe all of them, could have been written more simply using Clue. D'oh. I could have saved quite a lot of time, I think, by writing Clue earlier. -- http://rrt.sc3d.org/ | Careful Cyclists Approaching From Right (Anon) |
From: Reuben T. <rr...@sc...> - 2007-10-25 13:54:56
|
On Thu, 25 Oct 2007, Alistair Turnbull wrote: >> Does rblist (or rbutil or rbacc) currently rely on libgc? I ask because I >> see the opportunity once most of Zee is rewritten in Lua to get rid of the >> dependency on libgc, and simply use Lua's GC. This would require more >> careful thought were rblist to rely on it. > > It does, yes. > > It could be rewritten with reference counting easily enough, but you'd > have to wrap every rblist in an object whose sole purpose was to have an > allocate/free contract. I vote against. No, sure, if it needs GC it needs GC. In that case, it needs its requirements made explicit, so I can make sure that its garbage becomes Lua garbage. -- http://rrt.sc3d.org/ | taciturn, n. a silent pot |
From: Alistair T. <ap...@go...> - 2007-10-25 13:51:45
|
On Thu, 25 Oct 2007, Reuben Thomas wrote: > Does rblist (or rbutil or rbacc) currently rely on libgc? I ask because I > see the opportunity once most of Zee is rewritten in Lua to get rid of the > dependency on libgc, and simply use Lua's GC. This would require more > careful thought were rblist to rely on it. It does, yes. It could be rewritten with reference counting easily enough, but you'd have to wrap every rblist in an object whose sole purpose was to have an allocate/free contract. I vote against. Alistair |