From Jose Lombera to ~sircmpwn/hare-users
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
From Jose Lombera to ~sircmpwn/hare-users
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
From Jose Lombera to ~sircmpwn/hare-dev
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 (??)
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>