On 23 May 2012, at 20:56, Reuben Thomas wrote:
On 22 May 2012 18:36, Gary V. Vaughan <address@hidden> wrote:
Seeing that we haven't chatted for quite some time, I wondered if you had time to fill me in on where you are at in respect of Zile, and any roadmap details you want to share?
Nothing has changed (and in fact, I've simply been working on other projects, rather than overwhelmed). I have one more, trivial, patch to port from C (adding a constant empty estr), and then it's time to rewrite the buffer code using alien for direct byte array manipulation.
Cool. Looking forward to it :)
My only other different thought is that I am not sure ctypesgen/mork is going to be a robust solution for automatic interfacing to libraries on a wide range of systems: it's just asking too much of an ad hoc C parser to parse arbitrary system headers. I was thinking instead of using gobjectintrospection.
Unless gobjectintrospection has improved substantially in the last 6 months or so, it is barely portable at all - full of Linuxisms and gccisms. I managed to get it compiled with gcc on most of the architectures I care about, but it took quite a lot of hacky patches to get that far, so it's still a bit crashy. And there was no way in hell to get it working with the vendor compilers.
Having said that, the guys working on it are pretty smart, so assuming they have access to Unices other than GNU/Linux, maybe it's in better shape than when I last wrestled with it (and lost!)...
There are only hints of suitable curses bindings:
https://live.gnome.org/Vala/Documentation
You mean this? https://github.com/pavouk/lgi
Well, they are listing some of the architectures I struggled with on that page (mips in particular), so maybe those gobject-introspection woes are just a bad memory these days. :) It will be interesting to see how you get on with that work.
but the other functions that we need for file management &c. should be findable in glib. Using glib should have other advantages, and though it will naturally reduce portability slightly, I think it's in line with trying to reduce the amount of work we do by relying on other GNU packages; in any case, glib is pretty widely ported!
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 :)
On my side, I noticed last week that C Zile has the same interminable slowness as Lua Zile if you paste a large block of text into it... which is actually good news, because it means the slowness is algorithmic and not intrinsic to Lua :-) I might see if I can find a way to speed that up, so that I can get back to adding syntax highlighting to Zi... unless you have a plan in mind for addressing that already?
I don't. I hope that profiling will show where the bottleneck is;
See attached screenshot.
I have found and fixed one or two performance bugs very simply in the past, and take it as a good sign that the code is getting simpler on the rare occasions where (re-)optimisation is necessary! Feel free to have a go.
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. 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?
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'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 ;)
Cheers,
--
Gary V. Vaughan (gary AT vaughan DOT pe)