bug-zile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-zile] Incremental search is dog slow in moderately-sized files


From: Gary V. Vaughan
Subject: Re: [Bug-zile] Incremental search is dog slow in moderately-sized files
Date: Sun, 19 Jan 2014 14:15:10 +1300

Hi Reuben,

On Jan 19, 2014, at 1:21 PM, Reuben Thomas <address@hidden> wrote:

> On 18 January 2014 23:20, Gary V. Vaughan <address@hidden> wrote:
>> And since the error is thrown while evaluating `alien.default.memrchr` 
>> during parsing, if blows up even when wrapped in pcall (or even `if false 
>> then ... end` for that matter).
>> 
> Not sure what you mean by "during parsing":

As in the failure happens when Lua reads alien.default.doesnotexist, presumably 
while asking alien to resolve the contents of the default table, but before 
executing user code.  Try this:

  if false then print (tostring (alien.default.doesnotexist)) end

I'd argue getting nil would be more useful than the current behaviour.

>> Technically agreed, but now I've figured out how to write a brute-force 
>> reverse search in Lua with the alien APIs, I plan to avoid the nastiness of 
>> carrying a single symbol loadable C module with Zile for non-GNU platforms 
>> only.
> 
> How? Did I miss something?

 local function memrchr (buf, ch, o)
   local c = string.byte (ch)
   for i = o, 1, -1 do
     if buf[i] == c then return i end
   end
 end

where buf is an alien.array wrapping an alien.buffer, per Zile AStr 
implementation.

>  But `memrchr` is a GNU extension, so that's a can of worms...
> 
> OK, libgnu if you insist. I think building a separate libposix is a bit 
> pointless.

Not insisting, but I'd rather avoid opening the floodgates of adding gnu 
extensions to luaposix.  I still strongly advocate libposix as a shim between 
applications that stick to posix apis and libc - avoiding adding thousands of 
lines of configury and gnulib sources to every project.  But, I still have 
other things I'd much rather work on, more's the pity.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


reply via email to

[Prev in Thread] Current Thread [Next in Thread]