bugGNU Zile (Zile is Lossy Emacs) - Bugs: bug #37324, Commits to port from C to Lua


bug #37324: Commits to port from C to Lua

Submitted by:  Reuben Thomas <rrt>
Submitted on:  Tue Sep 11 00:49:37 2012  
Category: LuaSeverity: 3 - Normal
Status: NoneAssigned to: None
Open/Closed: OpenRelease: None

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Mon May 26 09:43:45 2014, 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 :)

Gary V. Vaughan <gary>
Project Administrator
Mon May 26 09:35:52 2014, 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.

Reuben Thomas <rrt>
Project Administrator
Mon May 26 03:14:35 2014, 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?)

Gary V. Vaughan <gary>
Project Administrator
Sun May 25 23:56:24 2014, 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).

Reuben Thomas <rrt>
Project Administrator
Sun May 25 16:07:48 2014, 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?

Gary V. Vaughan <gary>
Project Administrator
Sat May 24 21:23:36 2014, 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.

Reuben Thomas <rrt>
Project Administrator
Sun Dec 22 22:30:22 2013, 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.

Reuben Thomas <rrt>
Project Administrator
Tue Apr 9 11:57:04 2013, 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.

Reuben Thomas <rrt>
Project Administrator
Tue Sep 11 00:49:37 2012, 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.

Reuben Thomas <rrt>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by gary (Posted a comment)
  • -unavailable- added by rrt (Submitted the item)

    Please enter the title of George Orwell's famous dystopian book (it's a date):



    No Changes Have Been Made to This Item

    Back to the top

    Powered by Savane 3.1-cleanup1