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). - 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). > >
alacritty-2019081101.tgz
Description: Binary data
