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

Submitter:  Reuben Thomas <rrt>
Submitted:  Tue 11 Sep 2012 12:49:37 AM UTC
   
 
Category:  Lua Severity:  3 - Normal
Status:  None Assigned to:  None
Open/Closed:  Closed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 27 Sep 2020 03:35:35 PM UTC, comment #9: 

Closing: I won't be trying to resurrect the Lua port.

Reuben Thomas <rrt>
Group administrator
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 :)

Gary V. Vaughan <gary>
Group administrator
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.

Reuben Thomas <rrt>
Group administrator
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?)

Gary V. Vaughan <gary>
Group administrator
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).

Reuben Thomas <rrt>
Group administrator
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?

Gary V. Vaughan <gary>
Group administrator
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.

Reuben Thomas <rrt>
Group administrator
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.

Reuben Thomas <rrt>
Group administrator
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.

Reuben Thomas <rrt>
Group administrator
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.

Reuben Thomas <rrt>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-27 rrt Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code