~jlombera

Recent activity

Re: Testimonials from Hare users 22 days ago

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

Re: Testimonials from Hare users 22 days ago

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

Re: [PATCH hare] bufio: remove scanner inefficiency 7 months ago

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 (??)

[PATCH hare] bufio: remove scanner inefficiency 9 months ago

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]

Re: [PATCH hautils v3] yes: new command 9 months ago

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.

Re: [PATCH hautils v3] yes: new command 9 months ago

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

Re: Relicensing aerc to GPL 9 months ago

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

Re: Relicensing aerc to GPL 9 months ago

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.

Re: [PATCH hare] net::dial: Fix address parsing 9 months ago

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

Re: [PATCH hare] net::dial: Fix address parsing 9 months ago

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>