bug-zile
[Top][All Lists]
Advanced

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

Re: [Bug-zile] Running bleeding-edge github Zile [WAS Re: Problems gener


From: Gary V. Vaughan
Subject: Re: [Bug-zile] Running bleeding-edge github Zile [WAS Re: Problems generating manpage]
Date: Wed, 30 Jul 2014 15:12:01 +0100

Hi Stefan,

On Jul 29, 2014, at 10:40 PM, Stefan Husmann <address@hidden> wrote:
> Am 29.07.2014 um 14:45 schrieb Gary V. Vaughan:
>> Yes, the github mirror is sometimes slightly ahead of the official savannah 
>> repository, and is much more prone to breakage that will force you to do a 
>> fresh git checkout from time to time if I rewrite history as I fix things 
>> before pushing to the official savannah repo. In this case you picked up 
>> some changes I added to test moving the former `zile.Array` into stdlib as 
>> `std.array` where it can be useful to other projects... although I've since 
>> renamed that module to `std.vector` in github stdlib.
>> 
>> From here you have a couple of options to get going:
>> 
>>   1. You are very welcome to try bleeding edge zile and report any problems 
>> you find, which I'll fix as quickly as possible.  Unfortunately you'll need 
>> to update to the latest git version of stdlib too in this case.  I've just 
>> pushed another commit to github zile to catch up with the most recent 
>> upgrades to github stdlib.  I've also tested all of these together this 
>> morning, and everything appears to be working well here.
>> 
>>   2. If you don't want to fiddle with setting up a separate package.path for 
>> bleeding edge stdlib, or you're worried about breaking other Lua programs by 
>> overwriting the stable stdlib in the main package tree, you should use the 
>> savannah git repo for Zile, which works with stdlib v40.
>> 
>> Apologies for the dust and scaffolding while I'm making the current round of 
>> improvements to the infrastructure.
>> 
>> If there's anything else I can help with, please feel free to post again to 
>> the mailing list.
> 
> I will go for 2. for now, but when I got more familiar with lua and luarocks 
> (which seems to be down at the moment), I will prbably step up to 1.

That's great, thanks for being willing to help out here :)

Luarocks.org does seem to go through some occasional downtime of a few days 
here and there, but with the latest LuaRocks sources alpha releases, the main 
rocks repository has moved to rocks.moonscript.org.  I'll make some time to 
improve the installation instructions for all my Lua packages that explain how 
to configure your luarocks binaries to pull rocks from there instead.

  
https://github.com/keplerproject/luarocks/blob/570e29f921cf37d01eaf2af8d0e61f794917aed6/src/luarocks/cfg.lua#L216


> For the record, I managed to build zz and zemacs successfully after switching 
> off the "-j3" compile option globally on my system. This may slow down other 
> compile runs, but I do not care.

Excellent!

I'm surprised about the -j3 issue though, having fixed something similar with 
the docs directory recently.  I must have missed it in the logs you put on 
hastebin.  If you have time, please send me the relevant line numbers from that 
log, or paste just the relevant lines in a reply to this email (whichever is 
easiest), and I'll see if I can figure out how to fix it.

> Thanks for your help and the warm welcome.

Thank you for you interest in Zile!  Always happy to have more users on board 
:-)

I have a lot of plans for Zile, just as soon as I can finish my upgrades to 
stdlib.  Not least of which is to separate UI from system interface - something 
I've wanted for a long time is an editor where I can run the file management on 
a server, and the interface on my laptop (in addition to running both on the 
same machine), and then writing a GTK+ or QT UI as an alternative to the curses 
interface for fast remote editing...

If you're interested in this sort of thing, there's an out of date roadmap of 
sorts (in that some of it is done or underway by now, and that there are other 
things now missing from it) here:

    https://www.gnu.org/software/soc-projects/ideas-2014.html#zile

> For now, I pushed a PKGBUILD to the AUR[1] to make zile3 more pupular among 
> Arch Linux users.
> 
> [1] https://aur.archlinux.org/packages/zile-git/

That's great, and much appreciated.  Thanks also for building the supporting 
packages.  I think you can remove some of the zile-git dependencies though:

  - you forgot to depend on Lua :-o
  - acl shouldn't be needed;
  - gc is definitely not require (though it was for the earlier C 
implementation of Zile);
  - gpgme isn't required by Zile itself, nor the vanilla build process (not 
sure if it's required by Arch during fetching?);
  - ldoc is only required at make time to generate the html api docs;
  - lua-socket is not used by Zile (although one of the other make-time 
dependencies might pull it in?);
  - ncurses is not a Zile requirement, but it is missing from Arch's lua-posix 
package dependencies;
  - specl is only a make-time requirement (for verifying Zile meets its 
specifications), but the package itself is missing from AUR at the moment.

Cheers,
-- 
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]