On 2019/08/11 22:45, Eric Auge wrote: > Re, > > attached is the updated the port: > - added a pkg/README explaining basic config template location and how > to disable the "lstat(2) polling" and prevent another "default config" > CPU overhead trigger. > - left the pre-configure target ulimit check (as I did not find how to > do pre-fetch).
The earliest you can do such a check is pre-extract. > - updated PLIST. > - tested it. > > ok? > > > On Sun, Aug 11, 2019 at 1:51 PM Eric Auge <[email protected]> wrote: > > > > Hello, > > > > inlined. > > > > On Sun, Aug 11, 2019 at 11:52 AM Theo Buehler <[email protected]> wrote: > > > > > > On Sun, Aug 11, 2019 at 07:05:00AM +0200, Eric Auge wrote: > > > > Hello, > > > > > > > > attached is the updated port for alacritty including a "pre-configure" > > > > target data size check taken from the lang/rust port. > > > > ok? > > > > > > I would prefer the ulimit check to happen before the dependencies are > > > downloaded, but that will need a suggestion from somebody who knows the > > > cargo module better than me. I'm not sure the cargo module needs such a > > > check by default, for instance, ripgrep and exa do just fine with the > > > defaults. > > > > agreed, as it is my first port I was wondering and asked for advices, > > pre-fetch target would be preferred then, correct? > > > > > > > > I am not going to use this port, as it is quite CPU hungry (~10-13% when > > > just idling at the shell prompt) and for some reason it lstats its > > > config file more than 10 times a second. > > > > I am currently using it, idling at the shell prompt takes 0.5 - 1% on > > mine (x1c5), noticed the lstat "poll" seems ugly indeed... but you can > > disable it in the config file ("live_config_reload: false"), however > > it seems it's the "default" behaviour. > > I could also "pre"-tune a little bit the default behaviour in the > > provided .yml template configuration or a package README to indicate > > those elements? > > > > Another set of errors appears with "cursor themes" and you might need > > "xcursor-themes" package (to remove the constant attempt to open a non > > existent file), should I add it as a necessary dependancy? > > > > Compilation is quite heavy and long..., however I got curious of the > > "super fast terminal" claim, I don't really know rust nor graphic > > related code, another part is the large number of "rust" dependencies, > > but again new to the rust "ecosystem" and testing... > > > > in any case, it was a good practice to experience port contributions > > and i wanted to avoid recompilation, so binary package could be handy > > and updating it will be easy if it improves. > > it still does have some sporadic refreshing problems that are not > > clearly identified ( i have to open an issue on their project ) and > > happens only from time to time. > > > > I was using xterm -u8 and then rxvt-unicode (urxvtd and urxvtc) which > > are my fallback, in case i grow unhappy of alacritty. > > > > I can provide an updated port attempting to mitigate those identified > > problems, would that be ok? > > > > > > > > Nevertheless, the port looks good to me now and if more experienced > > > porters think this is ok portswise, I'm ok with importing this -- I > > > certainly would not want to build this on a slower machine (it takes a > > > whopping 45 minutes to build on my x280). > > > So the claimed advantage is that it's super fast, but actually it uses way more cpu than probably any other terminal emulator in the tree except cool-retro-term? Is this useful enough to be worth adding so much time to a bulk build? It will likely need to be amd64-only.
