The input adapter streams were input streams yielding either binary or
character data that could be constructed from a variable data source.
The stream would take care not to destroy the underlying data
source (i.e. not close it if it was a stream), so similar to with
FILE-PORTIONs, but simpler.
Unfortunately, the implementation was quite inefficient: They are
ultimately defined in terms of a function that retrieves the next
character in the source. This only allows for an implementation of
READ-CHAR (and READ-BYTE). Thanks to cl/8559, READ-SEQUENCE can be used
on e.g. FILE-PORTION, but this was still negated by a input adapter
based on one—then, READ-SEQUENCE would need to fall back on READ-CHAR or
READ-BYTE again.
Luckily, we can replace BINARY-INPUT-ADAPTER-STREAM and
CHARACTER-INPUT-ADAPTER-STREAM with a much simpler abstraction: Instead
of extra stream classes, we have a function, MAKE-INPUT-ADAPTER, which
returns an appropriate instance of FLEXI-STREAM based on a given source.
This way, the need for a distinction between binary and character input
adapter is eliminated, since FLEXI-STREAMS supports both binary and
character reads (external format is not yet handled, though).
Consequently, the :binary keyword argument to MIME-BODY-STREAM can be
dropped.
flexi-streams provides stream classes for everything except a stream
that doesn't close the underlying one. Since we have already implemented
this in POSITIONED-FLEXI-INPUT-STREAM, we can split this functionality
into a new superclass ADAPTER-FLEXI-INPUT-STREAM.
This change also allows addressing the performance regression
encountered in cl/8559: It seems that flexi-streams performs worse when
we are reading byte by byte or char by char. (After this change mblog is
still two times slower than on r/6150.) By eliminating the adapter
streams, we can start utilizing READ-SEQUENCE via decoding code that
supports it (i.e. qbase64) and bring performance on par with r/6150
again. Surely there are also ways to gain back even more performance
which has to be determined using profiling. Buffering more aggressively
seems like a sure bet, though.
Switching to flexi-streams still seems like a no-brainer, as it allows
us to drop a lot of code that was quite hacky (e.g. DELIMITED-INPUT-
STREAM) and implements en/decoding handling we did not support before,
but would need for improved correctness.
Change-Id: Ie2d1f4e42b47512a5660a1ccc0deeec2bff9788d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8581
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
this is for a... party
Change-Id: Ida5e0effb071ac39194cabec507eef58de2bf279
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8506
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Autosubmit: grfn <grfn@gws.fyi>
This is a little late, but whatever
Change-Id: I06a28c2c81f1653576a15d3aec2658d356d219d5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8505
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Autosubmit: grfn <grfn@gws.fyi>
Something in recent nixpkgs made things a little ... less bold. This
makes them more bold again. It looks vaguely correct after.
Change-Id: I6fc60cc1ec2d21d193f46f4d80998f041941add0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8488
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Tailscale just works better out of the box than Zerotier, and its
clients aren't unfree.
Change-Id: Ie35ef1adde0edbe923992b02e6b636269a96a81e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8482
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
some telegram channels do not allow embedding of messages, but do
allow a preview to be shown on twitter. this preview is just embedded
in the html, and can be scraped out if no message was found.
technically this preview also contains image links, but they are to
very low resolution, thumbnail-style images so i decided not to
include them here.
Change-Id: Ifb89f9fbde8140d577a5ee3af6e60b04232e53e3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8480
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
we don't need these and they add a bunch of unnecessary deps.
Change-Id: I88a30ec8443090a2c61934b35848bea6f1d9597a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8479
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: tazjin <tazjin@tvl.su>
Add a cabal file and move into subdir.
Use MyPrelude & fix a few linter warnings.
Change-Id: I19d5ba47be789fc24f8e02ee8721f73c706ae3e9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8465
Reviewed-by: Profpatsch <mail@profpatsch.de>
Autosubmit: Profpatsch <mail@profpatsch.de>
Tested-by: BuildkiteCI
* Satisfy new assert that the corresponding shell needs to be enabled
via programs.* if it is as the login shell of at least one user.
* //users/tazjin: “Address” removal of hardware.video.hidpi option.
* //3p/gerrit: update fetch sha256
Change-Id: Id0988a0ea7f393d6b7848a7104fc3526ee1177f4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8407
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
* //users/wpcarro/avaSystem: disable hidpi
Recent changes have made nixpkgs adopt the position that hidpi
optimization can't be done generically and at the very least needs to
know a specific DPI number to optimize for. In addition to knowledge
of the display(s) in question (i.e. wpcarro needs to do this) the
issue <https://github.com/NixOS/nixpkgs/issues/222805> can give
guidance as to how to restore the desired hidpi look and feel.
Change-Id: Ia4b079a06dcb710050619f350cd0655216b4a42f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8345
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: wpcarro <wpcarro@gmail.com>
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Starting with 1.18.1 we no longer need to pass an extra flag to work
around the log4j CVE, so baseJvmOpts can be empty.
Change-Id: I6d6c5a366ecbb499b2e3945db81ca0a8b2e2dcbf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8332
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
