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). >
