[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: Gary V. Vaughan
Subject: Re: [Bug-zile] Incremental search is dog slow in moderately-sized files
Date: Mon, 20 Jan 2014 14:32:31 +1300

Hi Reuben,

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

> On 19 January 2014 09:16, Gary V. Vaughan <address@hidden> wrote:
>> Which continues to work on my Mac (because it fails the have_memrchr check 
>> and uses the
>> fallback implementation), but blows up spectacularly on Travis:
> I can't currently reproduce this because I seem to have a too old stdlib 
> (35), which Zile's bootstrap doesn't complain about, or issue guidance on 
> installing a newer copy of.

Right, because bootstrap only checks the additional rocks required to bootstrap 
the project... install-time checking is performed by luarocks, and runtime 
checking by std.string.require_version.  Unfortunately, the latter two don't 
give such overtly long diagnostics.

stdlib-37 was announced (twice!) on luarocks-develpers and lua-l, awaiting 
upload to the luarocks repo by Hisham.  In the mean time, it's available in the 
usual place:


>> If you had time to try out those two revision on your Linux machine, and 
>> help me figure out how
>> I screwed up the alien memrchr wrapper in the latter, that would be awesome!
> On closer inspection, one bit looks dodgy:
> return function (buf, ch, o)
>     local b = buf.buffer
>     local prev = alien.default.memrchr (
>       b:topointer (o), string.byte (ch), o - 1)
>     return prev and b:tooffset (prev) or nil
>   end
> b:topointer (o) should just be b:topointer(): the pointer's to the start of 
> the block of memory you're searching, not the start point of the search.

Good catch... I made that change and pushed it 
(https://travis-ci.org/gvvaughan/zile/builds/17248956) but it still complains 
of invalid pointers in the few new specl tests I'm migrating to.

Any further insight much appreciated!

Gary V. Vaughan (gary AT vaughan DOT pe)

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

reply via email to

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