From Jose Lombera to ~sircmpwn/hare-dev
The new scanner with an internal read-ahead buffer contains an
inefficiency in which the underlying buffer is shifted left every time a
token is consumed.
Fix this by delaying the shift until an actual read-ahead from the
source IO handle is made, and only if the shift is required.
Signed-off-by: Jose Lombera <jose@lombera.dev>
---
We can observe the performance inefficiency with following simple
program that counts the newlines in a file.
use bufio;
use fmt;
[message trimmed]
From Jose Lombera to ~sircmpwn/hare-dev
On 2023-02-21 19:59 UTC, Drew DeVault wrote: > The performance of yes(1) is not of any conseqeunce. Simplicity is the > word. Yes, it makes sense. Just wondering if someone could have some use-case expecting a performant yes(1). Not my case, though.
From Jose Lombera to ~sircmpwn/hare-dev
On 2023-02-21 14:32 UTC, jgart wrote: > hi, > > v3 simplies some logic in the if statement > > --- > Makefile | 4 +++- > yes.ha | 22 ++++++++++++++++++++++ > 2 files changed, 25 insertions(+), 1 deletion(-) > create mode 100644 yes.ha > > diff --git a/Makefile b/Makefile > index c568580..298db4b 100644 > --- a/Makefile
From Jose Lombera to ~rjarry/aerc-devel
On 2023-02-20 19:19 UTC, Robin Jarry wrote: > Jose Lombera, Feb 20, 2023 at 19:17: > > I'm fine with the change to GPL. > > > > Approved-by: Jose Lombera <jose@lombera.dev> > > > > On 2023-02-20 18:59 UTC, Robin Jarry wrote: > > > Hi all, > > > > > > as you may know, aerc is currently distributed under the MIT license. > > > This prevents from shipping aerc with notmuch support always enabled > > > (notmuch being GPL). > > > > Does this mean notmuch will be enabled by default? Or will we still
From Jose Lombera to ~rjarry/aerc-devel
I'm fine with the change to GPL. Approved-by: Jose Lombera <jose@lombera.dev> On 2023-02-20 18:59 UTC, Robin Jarry wrote: > Hi all, > > as you may know, aerc is currently distributed under the MIT license. > This prevents from shipping aerc with notmuch support always enabled > (notmuch being GPL). Does this mean notmuch will be enabled by default? Or will we still have to pass `GOFLAGS=-tags=notmuch` to `make` and `make install` every time.
From Jose Lombera to ~sircmpwn/hare-dev
On Wed Feb 15, 2023 at 3:45 PM CST, Lassi Pulkkinen wrote: > > Now the `service` parameter is redundant. > > No it isn't. It's used to provide a default, whereas `addr` would > typically be user-provided. > > > In any case, none of the expectations of a valid address string format > > (whether it is hostname/IPv4/IPv6; has port/service) nor which > > service/port has priority is documented. All this should be documented > > so that they aren't just implementation details. > > This is documented on the `dial` function; that should indeed be > updated to reflect these changes. (Conspicuously, it leaves the
From Jose Lombera to ~sircmpwn/hare-dev
On Wed Feb 15, 2023 at 10:26 AM CST, Lassi Pulkkinen wrote: > Allow IPv6 without port > Allow service name in address string Is this really required? Now the `service` parameter is redundant. In any case, none of the expectations of a valid address string format (whether it is hostname/IPv4/IPv6; has port/service) nor which service/port has priority is documented. All this should be documented so that they aren't just implementation details. > > Signed-off-by: Lassi Pulkkinen <lassi@pulk.fi>
From Jose Lombera to ~sircmpwn/hare-dev
On Sat Feb 11, 2023 at 4:44 AM CST, Drew DeVault wrote: > This scanner maintains an internal read-ahead buffer for greater > efficiency of scanning operations without requiring the user to > configure their own buffered stream underneath. It also returns strings > and slices borrowed from the internal buffer, eliminating memory > allocations within scan loops. > > Implements: https://todo.sr.ht/~sircmpwn/hare/562 > Signed-off-by: Drew DeVault <sir@cmpwn.com> > --- > Leaning towards replacing all of the scan* variants with scan_* and > renaming scan_* => scan (which is the breaking change I was talking > about before).
From Jose Lombera to ~sircmpwn/hare-dev
On Fri Feb 10, 2023 at 6:04 AM CST, Drew DeVault wrote: > This scanner maintains an internal read-ahead buffer for greater > efficiency of scanning operations without requiring the user to > configure their own buffered stream underneath. It also returns strings > and slices borrowed from the internal buffer, eliminating memory > allocations within scan loops. > > Signed-off-by: Drew DeVault <sir@cmpwn.com> > --- > RFC: > > What should we do with the old scanner functions? I'm in favor of a > breaking change which replaces the old ones with the new ones (and drops > the _ in the new names), then forces users to maintain a scanner
From Jose Lombera to ~sircmpwn/hare-dev
On Fri Feb 10, 2023 at 1:39 PM CST, Bor Grošelj Simić wrote: > > I haven't investigated the reason for this, though. Probably a cyclic > > dependency or something?? > > It's actually a missing dependency that happens to be "fixed" in a rather > unlikely way when building in parallel. It is fixed by: > https://lists.sr.ht/~sircmpwn/hare-dev/patches/38885 Thanks!