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

[Gary V. Vaughan]

Hi Reuben,

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

> On 20 January 2014 01:32, Gary V. Vaughan <address@hidden> wrote:
>> 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:
>> 
>>    http://raw.github.com/rrthomas/lua-stdlib/release/stdlib-37-1.rockspec
>> 
> OK, I've installed that.

Cool.  Pity Hisham is away at the moment, v36 went up in under an hour.... and 
then disappeared again not long after due to the LuaRocks install bug it 
tickled.  I'll wait a few more days, and ping him incase it slipped through the 
cracks.

> By the way, now that a) there are quite a few programs using stdlib (at least 
> of ours!) and you've started making definite backwards-incompatible changes, 
> might it be time to adopt semantic versioning? Even if (so far) we can't 
> actually use it.

Agreed in principle.  In practice, I have no plans to break anything else (the 
std.foo_ext -> std.foo, various modules to container or object derivatives, and 
getopt -> optparse being the whole of it), and even managed to change std.list 
back to a v35 compatible interface... so, any future breakage can be considered 
a bug.  If I do have to break something in future, then I'll definitely move to 
semantic versioning though.

> As to building zile from your github repo; I did ./bootstrap && ./configure, 
> and then:
> 
> $ make
>   ZLC      lib/zmacs/commands.lua
>   GEN      doc/zz.1
>   GEN      doc/dotzmacs.sample
>   GEN      doc/dotzz.sample
> /home/rrt/local/bin/x86_64-linux-gnu/lua: 
> /home/rrt/local/share/lua/5.2/zile/zlisp.lua:41: module 'std.io_ext' not 
> found:No LuaRocks module found for std.io_ext [[...]]
> 
> Why is it trying to load modules from my installed zile???

That can only be LUA_PATH or package.path munging somewhere along the line.  I 
can't see anything weird in the Makefiles, and can't reproduce here.  Do you 
have anything in LUA_INIT/LUA_INIT_5_2?  I've made a start at resetting those 
two at any point where I also set LUA_PATH, but I could easily have missed an 
instance.

If you can find a recipe to reproduce it, please file a bug at Savannah, and 
I'll work on a fix.

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

signature.asc
Description: Message signed with OpenPGP using GPGMail