[new] x11/alacritty

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[new] x11/alacritty

Eric Augé
Hello,

This is a new port of gpu accelerated terminal emulator written in rust:
https://github.com/jwilm/alacritty

portcheck seems ok, I was not sure about adding or not the completion
or how to check for the presence of zsh / fish / bash before
installing those completions files.

also afaik this is amd64 only, but I'm not sure how to mention that in
the Makefile.
please let me know if any changes are needed and if that could makes
its way in ports?

hth,
Eric.

alacritty.port.tgz (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Brian Callahan-5
Hi Eric --

On 8/1/19 1:56 PM, Eric Augé wrote:

> Hello,
>
> This is a new port of gpu accelerated terminal emulator written in rust:
> https://github.com/jwilm/alacritty
>
> portcheck seems ok, I was not sure about adding or not the completion
> or how to check for the presence of zsh / fish / bash before
> installing those completions files.
>
> also afaik this is amd64 only, but I'm not sure how to mention that in
> the Makefile.
> please let me know if any changes are needed and if that could makes
> its way in ports?
>
> hth,
> Eric.
Thanks for this. Alacritty was on my list. Glad I don't have to do it now.

Here is an updated tarball, with some necessary and convenience tweaks:
* Reel in excess whitespace
* Make the list of cargo crates easier to read at a glance (wow that's a
long list!)
* Rearrange variables
* Sync WANTLIB

Things that are still needed:
* A comment to say why the do-install is needed. Is it that upstream
doesn't provide one?
* Missing a MAINTAINER line. Would you like to be maintainer?
* A better pkg/DESCR
* `make test' is broken. It looks like there's some missing LDFLAGS on
-L${X11BASE}/lib

~Brian


alacritty.tgz (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Stuart Henderson
On 2019/08/02 20:01, Brian Callahan wrote:

> Hi Eric --
>
> On 8/1/19 1:56 PM, Eric Augé wrote:
> > Hello,
> >
> > This is a new port of gpu accelerated terminal emulator written in rust:
> > https://github.com/jwilm/alacritty
> >
> > portcheck seems ok, I was not sure about adding or not the completion
> > or how to check for the presence of zsh / fish / bash before
> > installing those completions files.
> >
> > also afaik this is amd64 only, but I'm not sure how to mention that in
> > the Makefile.
> > please let me know if any changes are needed and if that could makes
> > its way in ports?
> >
> > hth,
> > Eric.
>
> Thanks for this. Alacritty was on my list. Glad I don't have to do it now.
>
> Here is an updated tarball, with some necessary and convenience tweaks:
> * Reel in excess whitespace
> * Make the list of cargo crates easier to read at a glance (wow that's a
> long list!)

standard is to paste from "make modcargo-gen-crates-licenses" for these,
otherwise it's hard to see what is changed in an update.

> * Rearrange variables
> * Sync WANTLIB
>
> Things that are still needed:
> * A comment to say why the do-install is needed. Is it that upstream doesn't
> provide one?

i don't think a comment is needed for this ...

> * Missing a MAINTAINER line. Would you like to be maintainer?
> * A better pkg/DESCR
> * `make test' is broken. It looks like there's some missing LDFLAGS on
> -L${X11BASE}/lib
>
> ~Brian
>

ONLY_FOR_ARCHS =        amd64
COMMENT =       cross-platform, [...]

rust ports are so funny. sure they have files for 32 and 64-bit Windows and
say "cross-platform" but it ends up ONLY_FOR_ARCHS=amd64 ...

Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Stuart Henderson
On 2019/08/03 14:13, Stuart Henderson wrote:

> On 2019/08/02 20:01, Brian Callahan wrote:
> > Hi Eric --
> >
> > On 8/1/19 1:56 PM, Eric Augé wrote:
> > > Hello,
> > >
> > > This is a new port of gpu accelerated terminal emulator written in rust:
> > > https://github.com/jwilm/alacritty
> > >
> > > portcheck seems ok, I was not sure about adding or not the completion
> > > or how to check for the presence of zsh / fish / bash before
> > > installing those completions files.
> > >
> > > also afaik this is amd64 only, but I'm not sure how to mention that in
> > > the Makefile.
> > > please let me know if any changes are needed and if that could makes
> > > its way in ports?
> > >
> > > hth,
> > > Eric.
> >
> > Thanks for this. Alacritty was on my list. Glad I don't have to do it now.
> >
> > Here is an updated tarball, with some necessary and convenience tweaks:
> > * Reel in excess whitespace
> > * Make the list of cargo crates easier to read at a glance (wow that's a
> > long list!)
>
> standard is to paste from "make modcargo-gen-crates-licenses" for these,
> otherwise it's hard to see what is changed in an update.
>
> > * Rearrange variables
> > * Sync WANTLIB
> >
> > Things that are still needed:
> > * A comment to say why the do-install is needed. Is it that upstream doesn't
> > provide one?
>
> i don't think a comment is needed for this ...
>
> > * Missing a MAINTAINER line. Would you like to be maintainer?
> > * A better pkg/DESCR
> > * `make test' is broken. It looks like there's some missing LDFLAGS on
> > -L${X11BASE}/lib
> >
> > ~Brian
> >
>
> ONLY_FOR_ARCHS =        amd64
> COMMENT =       cross-platform, [...]
>
> rust ports are so funny. sure they have files for 32 and 64-bit Windows and
> say "cross-platform" but it ends up ONLY_FOR_ARCHS=amd64 ...
>

heh, the previous submission of alacritty on ports@ said "In the process of
porting, I realized the extensive dependencies list and decided to stick
to xterm and base applications as much as possible" :-)

Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Eric Augé
In reply to this post by Brian Callahan-5
On Sat, Aug 3, 2019 at 2:01 AM Brian Callahan <[hidden email]> wrote:
>
> Hi Eric --
Hello Brian,

answers inlined.

>
> On 8/1/19 1:56 PM, Eric Augé wrote:
> > Hello,
> >
> > This is a new port of gpu accelerated terminal emulator written in rust:
> > https://github.com/jwilm/alacritty
> >
> > portcheck seems ok, I was not sure about adding or not the completion
> > or how to check for the presence of zsh / fish / bash before
> > installing those completions files.
> >
> > also afaik this is amd64 only, but I'm not sure how to mention that in
> > the Makefile.
> > please let me know if any changes are needed and if that could makes
> > its way in ports?
> >
> > hth,
> > Eric.
>
> Thanks for this. Alacritty was on my list. Glad I don't have to do it now.
>
> Here is an updated tarball, with some necessary and convenience tweaks:
> * Reel in excess whitespace
Oops :)

> * Make the list of cargo crates easier to read at a glance (wow that's a
> long list!)
> * Rearrange variables
> * Sync WANTLIB

Thanks, btw do we need to have USE_X11 ?

> Things that are still needed:
> * A comment to say why the do-install is needed. Is it that upstream
> doesn't provide one?

Hmm the documentation, mainly give you manual steps and generate a
package base for debian only, even the manpage must be copied by hand,
the Makefile provide an install target,
but it is mainly to open the dmg on os/x, so I did not find an
"install" as such and assumed,  following is the install steps from
the alacritty project:

https://github.com/jwilm/alacritty/blob/master/INSTALL.md

Additionally on OpenBSD, there is a comment on alacritty project:
"The default user limits in OpenBSD are insufficient to build
Alacritty. A datasize-cur of at least 3GB is recommended (see
login.conf)."

How should I deal with this from the port POV?

> * Missing a MAINTAINER line. Would you like to be maintainer?
yes, I can do that, I've added the line to the Makefile, ok?

> * A better pkg/DESCR
I mainly copied the headline from the project itself, the rest being
kinda "marketing'y", should I put the complete project description or
should I make a slightly modified/longer version of the short one?
something like:

"
Alacritty is a cross platform, GPU accelerated terminal emulator with
a strong focus on simplicity and performance.
It provides sane choices for defaults and requires no additional
setup. However, it does allow configuration of many aspects of the
terminal.
The software is considered to be at a beta level of readiness -- there
are a few missing features and bugs to be fixed, but it is already
used by many as a daily driver.
"
ok?

> * `make test' is broken. It looks like there's some missing LDFLAGS on
> -L${X11BASE}/lib

I've added a MODCARGO_RUSTFLAGS described in port-modules(5) and make
test runs ok now.

>
> ~Brian
HTH,
Eric.

Attached is a new version of the port (integrating Stuart comments on
crates license), ok?

alacritty.tgz (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Eric Augé
Hello,

is the updated port all ok?

Eric.

On Sat, Aug 3, 2019 at 3:31 PM Eric Auge <[hidden email]> wrote:

>
> On Sat, Aug 3, 2019 at 2:01 AM Brian Callahan <[hidden email]> wrote:
> >
> > Hi Eric --
> Hello Brian,
>
> answers inlined.
> >
> > On 8/1/19 1:56 PM, Eric Augé wrote:
> > > Hello,
> > >
> > > This is a new port of gpu accelerated terminal emulator written in
rust:

> > > https://github.com/jwilm/alacritty
> > >
> > > portcheck seems ok, I was not sure about adding or not the completion
> > > or how to check for the presence of zsh / fish / bash before
> > > installing those completions files.
> > >
> > > also afaik this is amd64 only, but I'm not sure how to mention that in
> > > the Makefile.
> > > please let me know if any changes are needed and if that could makes
> > > its way in ports?
> > >
> > > hth,
> > > Eric.
> >
> > Thanks for this. Alacritty was on my list. Glad I don't have to do it
now.

> >
> > Here is an updated tarball, with some necessary and convenience tweaks:
> > * Reel in excess whitespace
>
> Oops :)
>
> > * Make the list of cargo crates easier to read at a glance (wow that's a
> > long list!)
> > * Rearrange variables
> > * Sync WANTLIB
>
> Thanks, btw do we need to have USE_X11 ?
>
> > Things that are still needed:
> > * A comment to say why the do-install is needed. Is it that upstream
> > doesn't provide one?
>
> Hmm the documentation, mainly give you manual steps and generate a
> package base for debian only, even the manpage must be copied by hand,
> the Makefile provide an install target,
> but it is mainly to open the dmg on os/x, so I did not find an
> "install" as such and assumed,  following is the install steps from
> the alacritty project:
>
> https://github.com/jwilm/alacritty/blob/master/INSTALL.md
>
> Additionally on OpenBSD, there is a comment on alacritty project:
> "The default user limits in OpenBSD are insufficient to build
> Alacritty. A datasize-cur of at least 3GB is recommended (see
> login.conf)."
>
> How should I deal with this from the port POV?
>
> > * Missing a MAINTAINER line. Would you like to be maintainer?
> yes, I can do that, I've added the line to the Makefile, ok?
>
> > * A better pkg/DESCR
> I mainly copied the headline from the project itself, the rest being
> kinda "marketing'y", should I put the complete project description or
> should I make a slightly modified/longer version of the short one?
> something like:
>
> "
> Alacritty is a cross platform, GPU accelerated terminal emulator with
> a strong focus on simplicity and performance.
> It provides sane choices for defaults and requires no additional
> setup. However, it does allow configuration of many aspects of the
> terminal.
> The software is considered to be at a beta level of readiness -- there
> are a few missing features and bugs to be fixed, but it is already
> used by many as a daily driver.
> "
> ok?
>
> > * `make test' is broken. It looks like there's some missing LDFLAGS on
> > -L${X11BASE}/lib
>
> I've added a MODCARGO_RUSTFLAGS described in port-modules(5) and make
> test runs ok now.
>
> >
> > ~Brian
> HTH,
> Eric.
>
> Attached is a new version of the port (integrating Stuart comments on
> crates license), ok?
Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Theo Buehler-3
On Wed, Aug 07, 2019 at 09:18:31AM +0200, Eric Auge wrote:
> Hello,
>=20
> is the updated port all ok?

I could not build this with a login class staff user without bumping
ulimit -d quite a bit (I ended up doubling it). Should there perhaps be
a warning similar to the one in lang/rust?

LLVM ERROR: out of memory
error: Could not compile `alacritty`.

Caused by:
  process didn't exit successfully: `/usr/local/bin/rustc --edition=3D2018 =
--crate-name alacritty alacritty/src/main.rs --color never --crate-type bin=
 --emit=3Ddep-info,link -C opt-level=3D3 -C lto -C debuginfo=3D1 --cfg 'fea=
ture=3D"default"' -C metadata=3D34165af3ffc40356 -C extra-filename=3D-34165=
af3ffc40356 --out-dir /usr/ports/pobj/alacritty-0.3.3/build-amd64/target/re=
lease/deps -L dependency=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/targ=
et/release/deps --extern alacritty_terminal=3D/usr/ports/pobj/alacritty-0.3=
=2E3/build-amd64/target/release/deps/libalacritty_terminal-c754dfeab36402eb=
=2Erlib --extern clap=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/=
release/deps/libclap-9637bb071988a172.rlib --extern crossbeam_channel=3D/us=
r/ports/pobj/alacritty-0.3.3/build-amd64/target/release/deps/libcrossbeam_c=
hannel-f53712b3a546b2cf.rlib --extern env_logger=3D/usr/ports/pobj/alacritt=
y-0.3.3/build-amd64/target/release/deps/libenv_logger-a5dfb8ebfd133b30.rlib=
 --extern log=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/release/=
deps/liblog-be423954d857bbd9.rlib --extern serde_yaml=3D/usr/ports/pobj/ala=
critty-0.3.3/build-amd64/target/release/deps/libserde_yaml-022d6ddaeaf5d04e=
=2Erlib --extern time=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/=
release/deps/libtime-d0c34424d8a465ea.rlib --extern xdg=3D/usr/ports/pobj/a=
lacritty-0.3.3/build-amd64/target/release/deps/libxdg-eeeb620cbb933477.rlib=
 -L/usr/X11R6/lib -L native=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/t=
arget/release/build/libloading-26ba8eff14b79f78/out -L native=3D/usr/X11R6/=
lib -L native=3D/usr/X11R6/lib` (signal: 6, SIGABRT: process abort signal)
*** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:171 'do-build': @c=
d /usr/ports/pobj/alacritty-0.3.3/alacritty-0.3.3 && /usr/bin/env...)
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2777 '/usr/ports=
/pobj/alacritty-0.3.3/build-amd64/.build_done')
*** Error 1 in /usr/ports/x11/alacritty (/usr/ports/infrastructure/mk/bsd.p=
ort.mk:2447 'all')

Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Stuart Henderson
On 2019/08/10 19:33, Theo Buehler wrote:
> On Wed, Aug 07, 2019 at 09:18:31AM +0200, Eric Auge wrote:
> > Hello,
> >=20
> > is the updated port all ok?
>
> I could not build this with a login class staff user without bumping
> ulimit -d quite a bit (I ended up doubling it). Should there perhaps be
> a warning similar to the one in lang/rust?

Maybe worth adding a check to cargo.port.mk?

> LLVM ERROR: out of memory
> error: Could not compile `alacritty`.
>
> Caused by:
>   process didn't exit successfully: `/usr/local/bin/rustc --edition=3D2018 =
> --crate-name alacritty alacritty/src/main.rs --color never --crate-type bin=
>  --emit=3Ddep-info,link -C opt-level=3D3 -C lto -C debuginfo=3D1 --cfg 'fea=
> ture=3D"default"' -C metadata=3D34165af3ffc40356 -C extra-filename=3D-34165=
> af3ffc40356 --out-dir /usr/ports/pobj/alacritty-0.3.3/build-amd64/target/re=
> lease/deps -L dependency=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/targ=
> et/release/deps --extern alacritty_terminal=3D/usr/ports/pobj/alacritty-0.3=
> =2E3/build-amd64/target/release/deps/libalacritty_terminal-c754dfeab36402eb=
> =2Erlib --extern clap=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/=
> release/deps/libclap-9637bb071988a172.rlib --extern crossbeam_channel=3D/us=
> r/ports/pobj/alacritty-0.3.3/build-amd64/target/release/deps/libcrossbeam_c=
> hannel-f53712b3a546b2cf.rlib --extern env_logger=3D/usr/ports/pobj/alacritt=
> y-0.3.3/build-amd64/target/release/deps/libenv_logger-a5dfb8ebfd133b30.rlib=
>  --extern log=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/release/=
> deps/liblog-be423954d857bbd9.rlib --extern serde_yaml=3D/usr/ports/pobj/ala=
> critty-0.3.3/build-amd64/target/release/deps/libserde_yaml-022d6ddaeaf5d04e=
> =2Erlib --extern time=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/=
> release/deps/libtime-d0c34424d8a465ea.rlib --extern xdg=3D/usr/ports/pobj/a=
> lacritty-0.3.3/build-amd64/target/release/deps/libxdg-eeeb620cbb933477.rlib=
>  -L/usr/X11R6/lib -L native=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/t=
> arget/release/build/libloading-26ba8eff14b79f78/out -L native=3D/usr/X11R6/=
> lib -L native=3D/usr/X11R6/lib` (signal: 6, SIGABRT: process abort signal)
> *** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:171 'do-build': @c=
> d /usr/ports/pobj/alacritty-0.3.3/alacritty-0.3.3 && /usr/bin/env...)
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2777 '/usr/ports=
> /pobj/alacritty-0.3.3/build-amd64/.build_done')
> *** Error 1 in /usr/ports/x11/alacritty (/usr/ports/infrastructure/mk/bsd.p=
> ort.mk:2447 'all')
>

Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Eric Augé
In reply to this post by Theo Buehler-3
Hello,

On Sat, Aug 10, 2019 at 7:39 PM Theo Buehler <[hidden email]> wrote:
>
> On Wed, Aug 07, 2019 at 09:18:31AM +0200, Eric Auge wrote:
> > Hello,
> >=20
> > is the updated port all ok?
>
> I could not build this with a login class staff user without bumping
> ulimit -d quite a bit (I ended up doubling it). Should there perhaps be
> a warning similar to the one in lang/rust?

at the pre-configure target?
ok, I will send an updated port in a few after re-testing it with the
additional warning.

>
> LLVM ERROR: out of memory
> error: Could not compile `alacritty`.
>

I was wondering how to deal with that from the port POV in my first
reply to Brian:
...
Additionally on OpenBSD, there is a comment on alacritty project:
"The default user limits in OpenBSD are insufficient to build
Alacritty. A datasize-cur of at least 3GB is recommended (see
login.conf)."

How should I deal with this from the port POV?
...


> Caused by:
>   process didn't exit successfully: `/usr/local/bin/rustc --edition=3D2018 =
> --crate-name alacritty alacritty/src/main.rs --color never --crate-type bin=
>  --emit=3Ddep-info,link -C opt-level=3D3 -C lto -C debuginfo=3D1 --cfg 'fea=
> ture=3D"default"' -C metadata=3D34165af3ffc40356 -C extra-filename=3D-34165=
> af3ffc40356 --out-dir /usr/ports/pobj/alacritty-0.3.3/build-amd64/target/re=
> lease/deps -L dependency=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/targ=
> et/release/deps --extern alacritty_terminal=3D/usr/ports/pobj/alacritty-0.3=
> =2E3/build-amd64/target/release/deps/libalacritty_terminal-c754dfeab36402eb=
> =2Erlib --extern clap=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/=
> release/deps/libclap-9637bb071988a172.rlib --extern crossbeam_channel=3D/us=
> r/ports/pobj/alacritty-0.3.3/build-amd64/target/release/deps/libcrossbeam_c=
> hannel-f53712b3a546b2cf.rlib --extern env_logger=3D/usr/ports/pobj/alacritt=
> y-0.3.3/build-amd64/target/release/deps/libenv_logger-a5dfb8ebfd133b30.rlib=
>  --extern log=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/release/=
> deps/liblog-be423954d857bbd9.rlib --extern serde_yaml=3D/usr/ports/pobj/ala=
> critty-0.3.3/build-amd64/target/release/deps/libserde_yaml-022d6ddaeaf5d04e=
> =2Erlib --extern time=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/=
> release/deps/libtime-d0c34424d8a465ea.rlib --extern xdg=3D/usr/ports/pobj/a=
> lacritty-0.3.3/build-amd64/target/release/deps/libxdg-eeeb620cbb933477.rlib=
>  -L/usr/X11R6/lib -L native=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/t=
> arget/release/build/libloading-26ba8eff14b79f78/out -L native=3D/usr/X11R6/=
> lib -L native=3D/usr/X11R6/lib` (signal: 6, SIGABRT: process abort signal)
> *** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:171 'do-build': @c=
> d /usr/ports/pobj/alacritty-0.3.3/alacritty-0.3.3 && /usr/bin/env...)
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2777 '/usr/ports=
> /pobj/alacritty-0.3.3/build-amd64/.build_done')
> *** Error 1 in /usr/ports/x11/alacritty (/usr/ports/infrastructure/mk/bsd.p=
> ort.mk:2447 'all')
>

Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Eric Augé
Hello,

attached is the updated port for alacritty including a "pre-configure"
target data size check taken from the lang/rust port.
ok?

On Sat, Aug 10, 2019 at 9:14 PM Eric Auge <[hidden email]> wrote:

>
> Hello,
>
> On Sat, Aug 10, 2019 at 7:39 PM Theo Buehler <[hidden email]> wrote:
> >
> > On Wed, Aug 07, 2019 at 09:18:31AM +0200, Eric Auge wrote:
> > > Hello,
> > >=20
> > > is the updated port all ok?
> >
> > I could not build this with a login class staff user without bumping
> > ulimit -d quite a bit (I ended up doubling it). Should there perhaps be
> > a warning similar to the one in lang/rust?
>
> at the pre-configure target?
> ok, I will send an updated port in a few after re-testing it with the
> additional warning.
>
> >
> > LLVM ERROR: out of memory
> > error: Could not compile `alacritty`.
> >
>
> I was wondering how to deal with that from the port POV in my first
> reply to Brian:
> ...
> Additionally on OpenBSD, there is a comment on alacritty project:
> "The default user limits in OpenBSD are insufficient to build
> Alacritty. A datasize-cur of at least 3GB is recommended (see
> login.conf)."
>
> How should I deal with this from the port POV?
> ...
>
>
> > Caused by:
> >   process didn't exit successfully: `/usr/local/bin/rustc --edition=3D2018 =
> > --crate-name alacritty alacritty/src/main.rs --color never --crate-type bin=
> >  --emit=3Ddep-info,link -C opt-level=3D3 -C lto -C debuginfo=3D1 --cfg 'fea=
> > ture=3D"default"' -C metadata=3D34165af3ffc40356 -C extra-filename=3D-34165=
> > af3ffc40356 --out-dir /usr/ports/pobj/alacritty-0.3.3/build-amd64/target/re=
> > lease/deps -L dependency=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/targ=
> > et/release/deps --extern alacritty_terminal=3D/usr/ports/pobj/alacritty-0.3=
> > =2E3/build-amd64/target/release/deps/libalacritty_terminal-c754dfeab36402eb=
> > =2Erlib --extern clap=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/=
> > release/deps/libclap-9637bb071988a172.rlib --extern crossbeam_channel=3D/us=
> > r/ports/pobj/alacritty-0.3.3/build-amd64/target/release/deps/libcrossbeam_c=
> > hannel-f53712b3a546b2cf.rlib --extern env_logger=3D/usr/ports/pobj/alacritt=
> > y-0.3.3/build-amd64/target/release/deps/libenv_logger-a5dfb8ebfd133b30.rlib=
> >  --extern log=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/release/=
> > deps/liblog-be423954d857bbd9.rlib --extern serde_yaml=3D/usr/ports/pobj/ala=
> > critty-0.3.3/build-amd64/target/release/deps/libserde_yaml-022d6ddaeaf5d04e=
> > =2Erlib --extern time=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/target/=
> > release/deps/libtime-d0c34424d8a465ea.rlib --extern xdg=3D/usr/ports/pobj/a=
> > lacritty-0.3.3/build-amd64/target/release/deps/libxdg-eeeb620cbb933477.rlib=
> >  -L/usr/X11R6/lib -L native=3D/usr/ports/pobj/alacritty-0.3.3/build-amd64/t=
> > arget/release/build/libloading-26ba8eff14b79f78/out -L native=3D/usr/X11R6/=
> > lib -L native=3D/usr/X11R6/lib` (signal: 6, SIGABRT: process abort signal)
> > *** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:171 'do-build': @c=
> > d /usr/ports/pobj/alacritty-0.3.3/alacritty-0.3.3 && /usr/bin/env...)
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2777 '/usr/ports=
> > /pobj/alacritty-0.3.3/build-amd64/.build_done')
> > *** Error 1 in /usr/ports/x11/alacritty (/usr/ports/infrastructure/mk/bsd.p=
> > ort.mk:2447 'all')
> >

alacritty-2019081100.tgz (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Theo Buehler-3
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.

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Eric Augé
Hello,

inlined.

On Sun, Aug 11, 2019 at 11:52 AM Theo Buehler <[hidden email]> 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).
>

Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Eric Augé
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 <[hidden email]> wrote:

>
> Hello,
>
> inlined.
>
> On Sun, Aug 11, 2019 at 11:52 AM Theo Buehler <[hidden email]> 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 (25K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Stuart Henderson
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 <[hidden email]> wrote:
> >
> > Hello,
> >
> > inlined.
> >
> > On Sun, Aug 11, 2019 at 11:52 AM Theo Buehler <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [new] x11/alacritty

Theo Buehler-3
On Sun, Aug 11, 2019 at 11:30:09PM +0100, Stuart Henderson wrote:
> 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?

Yes, it is blazing fast. matthieu's test of 'cat /etc/termcap' completes
in under 0.1s while xterm uses 0.2-0.3s. It does feel way snappier than
xterm in general.

It looks like I made CPU use worse by about a factor of 2 due to using
vm.malloc_conf=CFJ. Still, ~5% is way more than it should need.

Another advantage is that contrary to xterm it is trivial to configure
thanks to a self-documenting .yml config file.

> Is this useful enough to be worth adding so much time to a bulk build?

I doubt it.

> It will likely need to be amd64-only.

Probably. Testing on other archs would need more time than I currently
have.