Hi Reuben,
On 27 May 2012, at 20:04, Reuben Thomas wrote:
On 27 May 2012 08:37, Gary V. Vaughan <address@hidden> wrote:
I'm not sure glib is the right choice myself, as it has become pretty bloated over the years IMHO. It'd be great if we could rely on something lightweight like the nascent libposix library from gnulib, especially as that might give me the momentum to finish it :)
I'm quite happy to go this route instead, as it's less work for me. I would be happy from the user point of view with being able to install all the dependencies with LuaRocks (which looks as though it's finally getting 5.2 support, removing my one reservation about using it).
I was not aware of that... but then I'm still using 5.1 exclusively, so I wouldn't be! :)
Adding momentum to libposix would be a bonus: I'd be quite happy to add a GPLed add-on to luaposix and triple-license the whole so that you can either build a plain version under the MIT license, or build a gnulib-enhanced version under the LGPL/GPL (according to how you configure gnulib). This would consist of two bits of support:
1. Optional use of gnulib in the configure apparatus, so you get the gnulib platform-specific fixes to POSIX functions.
2. An extra C module which would inject GNU extension APIs into the posix namespace (seems fair enough rather than adding a new namespace, as the gnulib additions are specifically designed not to clash with POSIX names).
The combination of this would allow the removal in the Lua version of code such as that for copying a file, which are already replaced by gnulib functions in the C version.
That seems like a good compromise to me. However, are you conflating libposix and libgnu... libposix is the subset of gnulib preinstalled as a shim over the vendor C library. Presupposing that I've finished it, and the person who is compiling Zile/luaposix has installed it already, there's no need for additional support anywhere in the client code. You just do this:
./configure LDFLAGS=-lposix
And then, all of the gnulib POSIX API-fixing functions need not be added to any other code... they just program to the POSIX APIs, and tell the user to install libposix from gnulib before linking if their system libraries/headers are deficient in any way.
I've profiled it, and during a huge paste (20 screen-fulls of text, which took over a minute to complete with profiling on), and it seems we're spending almost all of the time inside draw_line, or more specifically calling term_addch. Which is not surprising at all.
Actually, it's a surprise to me! I thought that it was the new buffer data structure, and that older versions of C Zile were unaffected (certainly, cutting and pasting was much faster at some point in the past). More likely, somehow it wasn't calling term_addch so much, either because it wasn't updating the screen for every character, or because at some point in the even more distant past I seem to recall it had a way to add a string to the screen.
Me too... I thought it was Lua overhead!
I suppose the solution is that when the input buffer is not empty, Zile should not bother trying to update the screen at all (much like emacs) except perhaps once every 500ms or something?
Absolutely, although I wonder if it's simpler to start by optimising screen update so that each line of the screen is drawn by a single curses addstr call.
Even easier, move the screen updating calls into term_curses.c, and only update the screen when the typeahead buffer is empty. Preliminary patch to follow, which reduces the 750-line paste I profiled earlier from over 70 seconds to around 6.5 seconds.
I don't know my way around C Zile that well, so it's not obvious where the line between internal buffer updating (presumably inside ncurses API calls?) and screen updating lies... or maybe I'm not being as dumb as I think and those two are still conflated?
I'm a little confused by this: Zile's internal buffers are updated in Zile code; ncurse's (along with actual screen updates) in ncurses code, and term_curses.c is pretty much a thin shim between the two. Zile keeps no representation of the screen internally. Referring to actual functions would help my understanding, if you do want to ask anything else!
I'm the confused one :) I haven't looked around C Zile enough to talk about it sensible is all.
I'll spend a little time trying to separate the two in Lua Zile and reduce the number of screen updates when still catching up with typeahead if I can... If I can get that working, then it should be easy for you to port it back to C Zile ;)
I hope that that won't be necessary, and that we'll have a stable version of Lua Zile "soon".
If you can figure out why my patch always leaves everything but the last half-dozen lines of a large paste buffer off the top of the screen, it would be nice to roll C Zile 2.4.8 with 90% faster typeahead handling... there's room to cut that time in half again, since we really shouldn't be spending 56.8% of our time in minibuf_clear when catching up with typeahead.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
--
Gary V. Vaughan (gary AT gnu DOT org)