Mon 26 May 2014 09:43:45 AM UTC, comment #8:
Argh... missing the word 'not' from a sentence seems to change the meaning much more drastically than omitting other unimportant words like the subject or main verb.
I meant to say "unlike most other Lua projects, Zile is not constrained by the horrid MIT license" (meaning that we can make use of gnulib without any problems).
I'm adding a task to figure out how to manage a publicly visible Zile projects list with as little maintenance overhead and syncing as possible :)
|
Mon 26 May 2014 09:35:52 AM UTC, comment #7:
How is Zile constrained by the MIT license?? The Zile projects page is here: http://libreplanet.org/wiki/GNU_Zile Maybe it should indeed be folded into the project.
|
Mon 26 May 2014 03:14:35 AM UTC, comment #6:
I suppose a long term goal should be to take advantage of gnulib where possible, since Zile is constrained by the horrid MIT license like most other Lua projects... and having an ext/gnulib/gnulib_c.so module feels like the idiomatic way to do it. And then to wrap that in a lib/gnulib.lua loader that binds everything with alien according to whether gnulib replaced a system function, or whatever.
However, it's not something I feel like tackling in the foreseeable future while I'm already juggling quite a lot of major refactorings in Zile and elsewhere. Seems like a good candidate to add to our Zile Projects page (is that maintained by us, or should we set one up somewhere and then just forward it to GSoC every year?)
|
Sun 25 May 2014 11:56:24 PM UTC, comment #5:
memrmem is not widely available AFAIK. The advantage of using copy-file is making the algorithm Someone Else's Problem, rather than replicating it in another language. What is needed in both cases is a clean way of pulling C into a Lua project; I agree that without such, it may well not be worth doing in either case here (although for pure performance, memrmem might arguably be a necessity).
|
Sun 25 May 2014 04:07:48 PM UTC, comment #4:
Is memrmem available widely enough to be worth binding?
The current MutableString:rfind algorithm seems more than adequate (memrchr to the next match of the first character and then see whether what follows is a full match)...
I haven't looked at the copy-file module yet, but I'm loathe to pull a gnulib git subproject into Lua Zile plus all the alien binding glue it would need. What is the advantage over improving the existing Lua algorithms to pick up any slack?
|
Sat 24 May 2014 09:23:36 PM UTC, comment #3:
It seems that the remaining issues to fix are:
fd19d377ef0: add and use memrmem
516d9951896: use gnulib's copy-file module to replace copy_file
I'm really puzzled by my comment #2, as a) I seem to be engaging in conversation with myself ("you"), and b) my comment #1 seems spot on: encoding-on-read was addressed in the Lua branch in commit 4bb5b42631a in early 2012, before the original report. Either way, I'm pretty sure it's no longer an issue. memmem support has also recently been added.
|
Sun 22 Dec 2013 10:30:22 PM UTC, comment #2:
I don't remember my reasoning about "fix file encoding preservation on read", but I clearly agree with it, as on deleting my old zile-stable checkout (for the latest C version), I find that I have .patch files which correspond to the last three commits you mention.
|
Tue 09 Apr 2013 11:57:04 AM UTC, comment #1:
I'm a bit puzzled by the inclusion of "a5cdea18bb2: fix file encoding preservation on read", since as far as I can tell it was already fixed long before the date of this bug report, and didn't need any C compilation.
Patch #8007 addresses commit "ce2ffe81d17: reimplement shell-command with gnulib's pipe-filter-ii", again without the need for new C (because it's in luaposix).
The other three commits remain to be addressed.
|
Tue 11 Sep 2012 12:49:37 AM UTC, original submission:
The following commits on the C branch should in principle be ported to the Lua branch:
fd19d377ef0: add and use memrmem
4fb34ecac95: use memmem
a5cdea18bb2: fix file encoding preservation on read
ce2ffe81d17: reimplement shell-command with gnulib's pipe-filter-ii
516d9951896: use gnulib's copy-file module to replace copy_file
The problem is that they all require adding C compilation back into the Zile Lua build system. But it looks as though that bullet may have to be bitten.
|