On the issue tracker <https://todo.sr.ht/~sircmpwn/hare>, the stdlib
label filter link is [0]. But to not filter for the easy label as well,
it should just be [1].


[0]: https://todo.sr.ht/~sircmpwn/hare?search=status%3Aopen%20label%3A%22easy%22%20label%3A%22stdlib%22
[1]: https://todo.sr.ht/~sircmpwn/hare?search=status%3Aopen%20label%3A%22stdlib%22

The clue to your problem can be found in the documentation for
strings::fromutf8 (emphasis mine):

> // Converts a byte slice into a string, aborting the program if the bytes
> // contain invalid UTF-8. **The return value is borrowed from the input.** To handle
> // errors without aborting, see [[try_fromutf8]] or [[encoding::utf8]].
> fn fromutf8(in: []u8) str;

This can be fixed by two ways. 1) Poorly, by simply removing the `defer
free(buffer)` line, or 2) duplicating the string and then freeing it:

	use fmt;
	use io;
	use strings;

On Sun Jun 19, 2022 at 5:29 PM EDT, Numeral wrote:
> Side note, I am new to mailing lists. Is it etiquette to
> * Always attach public key

No, most people don't. You can if you want to though.

> * Reply to both the original sender and the mailing list?

Yes, as it's possible they aren't subscribed to the list.

I had the idea, what if the way we did it was that we count module level
enums declared in files with certain builds tags, only in files with the
same build tags? I think this makes sense as this is the way that it
will actually be interpreted by the build driver.

By this I mean: Suppose three files, foo.ha, bar+tag.ha, and baz+tag.ha.
An enum called "strings" is defined in bar+tag.ha. It is interpreted as
being an enum in baz+tag.ha, but interpreted as the stdlib module in
foo.ha.

This is obviously a bit more complicated, but I think it's correct and
removes any need for the -T option.

Does this make sense? Let me know what you think.

As shown by this minimal test case:

fn foo(a: int, v: int...) void = void;

export fn main() void = {
	//foo(0); // << okay
	foo(); // harec segfaults
};

Signed-off-by: Sebastian LaVine <mail@smlavine.com>
---
v1 -> v2:
- Check for !param->next instead of param->type->array.members
 src/check.c | 2 +-
[message trimmed]

On Sat Jun 4, 2022 at 6:59 AM EDT, Bor Grošelj Simić wrote:
> > @@ -1211,7 +1211,7 @@ check_expr_call(struct context *ctx,
> > 	}
> > }
> >  
> > - if (param && fntype->func.variadism == VARIADISM_HARE) {
> > + if (param && param->type->array.members && fntype->func.variadism ==
> > VARIADISM_HARE) {
> > 	// No variadic arguments, lower to empty slice
>
> You've found the right place for a fix, but the fix is not correct.
> param->type may not be an array, and reading param->type->array.members isn't
> valid in that case. I think what we really want to check here is that the param
> we're looking at is the last one, so perhaps condition like

As shown by this minimal test case:

fn foo(a: int, v: int...) void = void;

export fn main() void = {
	//foo(0); // << okay
	foo(); // harec segfaults
};

Signed-off-by: Sebastian LaVine <mail@smlavine.com>
---
 src/check.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
[message trimmed]

On Thu Jun 2, 2022 at 10:33 PM EDT, John Gabriele wrote:
> On Thu, Jun 2, 2022, at 9:47 PM, Sebastian LaVine wrote:
> >
> > Perhaps you would be interested in the work that achaninja has done:
> >
> > https://acha.ninja/blog/memory-safeish-hare/
>
> Thanks for the link. Note though, I like Hare the way it is! It is a
> nice little gem. I was interested in hearing about what folks think
> of a high-level counterpart to Hare -- a language distinct from
> Hare.

I think Lua is pretty much built for this purpose, right? I don't have
much experience with it personally, though.

On Thu Jun 2, 2022 at 9:08 PM EDT, John Gabriele wrote:
> On Thu, Jun 2, 2022, at 8:47 PM, Vlad-Stefan Harbuz wrote:
> > On Fri, 3 Jun 2022, at 01:34, John Gabriele wrote:
> >> Well... what do you think of the idea of a high-level scripting version 
> >> of Hare? Dynamically-typed, GC'd, and with a built-in hashmap type. 
> >> Implemented in Hare, with seamless integration with Hare.
> >
> > I think this idea, regardless of its usefulness, is quite antithetical to
> > Hare's values, so it doesn't have much connection to the existing
> > language or community.
>
> Oh, certainly antithetical. That would be the whole point --- the other
> side of the coin, as it were.
>

On Tue May 31, 2022 at 2:48 PM EDT, Hanna wrote:
> Not sure if this is something that would be desirable, probably not given it 
> hasn't been added. However, I was wondering if there's any reason for not
> showing whether or not commits are signed on git.sr.ht, similar to other forges
> such as Gitea, Gogs, GitHub, etc. To be specific I'm talking about showing
> something that shows commits are "verified" such as on GitHub[0]. Where it
> shows that a commit is signed by a PGP/GPG key that has an email that matches
> the commit author. It's a very niche feature, but I've always liked it.
>
> [0]: https://transpri.de/i/d5me6woo.png


There is a ticket open for this: https://todo.sr.ht/~sircmpwn/git.sr.ht/170