On Thu Nov 9, 2023 at 13:27 CST, Ember Sawady wrote:

> On Thu Nov 9, 2023 at 5:58 PM UTC, Jose Lombera wrote:
> >
> > On Thu Nov 9, 2023 at 06:18 CST, Curtis Arthaud wrote:
> >
> > > Of course, it's a WIP, so there are rough edges and
> > > performance is sometimes lacking
> > > (eg reading lines from a buffered file is slower than in Go),
> >
> > That's probably a bug[1] whose fix was never merged[2].  I think the
> > underlying code was refactored a while back and they inherited the bug.
> > You can try the test case presented in that patch, the issue it's still

On Thu Nov 9, 2023 at 06:18 CST, Curtis Arthaud wrote:

> Of course, it's a WIP, so there are rough edges and
> performance is sometimes lacking
> (eg reading lines from a buffered file is slower than in Go),

That's probably a bug[1] whose fix was never merged[2].  I think the
underlying code was refactored a while back and they inherited the bug.
You can try the test case presented in that patch, the issue it's still
observable with current HEAD hare.  It seems to be even worse with the
new implementation:

$ time ./newlines l.txt

On 2023-04-19 10:55 UTC, Drew DeVault wrote:
> Thanks!
>
> To git@git.sr.ht:~sircmpwn/hare
>    b76e834c..b0806f69  master -> master

It seems this patch was not applied (??)

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]

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.

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

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

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.

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

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>