zee-devel Mailing List for Zee

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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

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.

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!

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

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



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.



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)


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



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



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).



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



Thanks, Tom.

GitHub it shall be.



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



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



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



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



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



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



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



A text editor (well, really, a text entry widget) in 37 rules:

www.vpri.org/pdf/m2010002_lobjects.pdf

-- 
http://rrt.sc3d.org



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



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)



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)



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



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




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)

zee-devel Mailing List for Zee

Experimental lightweight editor

zee-devel — Zee developers