[Top][All Lists]

[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: Reuben Thomas
Subject: Re: [Bug-zile] Incremental search is dog slow in moderately-sized files
Date: Sun, 19 Jan 2014 08:49:08 +0000

On 19 January 2014 01:15, Gary V. Vaughan <address@hidden> wrote:
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

> if false then print (tostring(alien.default.doesnotexist)) end
> print (tostring(alien.default.doesnotexist))
/home/rrt/local/lib/x86_64-linux-gnu/lua/5.2/alien_c.so: undefined symbol: doesnotexist
stack traceback:
    [C]: in function '__index'
    stdin:1: in main chunk
    [C]: in ?

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

You lost me again at "before executing user code". All that's happening is that alien.default is a userdata, and its index method is raising an error. I agree that getting nil would be more useful, though.

 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

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

Oh right, I hadn't missed that, I thought you meant something involving less Lua and more alien!
>  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.

If libposix had already attracted enough work to be released, I might agree, but it hasn't.
 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.

Eh? It's supposed to be a library! You don't add it to every project!

reply via email to

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