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 <eau+o...@unix4fun.net> wrote:
>
> Hello,
>
> inlined.
>
> On Sun, Aug 11, 2019 at 11:52 AM Theo Buehler <t...@theobuehler.org> 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
