From Sebastian LaVine to ~sircmpwn/hare-dev
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
From Sebastian LaVine to ~sircmpwn/hare-users
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;
From Sebastian LaVine to ~sircmpwn/sr.ht-discuss
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.
From Sebastian LaVine to ~smlavine/hareimports-dev
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.
From Sebastian LaVine to ~sircmpwn/hare-dev
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]
From Sebastian LaVine to ~sircmpwn/hare-dev
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
From Sebastian LaVine to ~sircmpwn/hare-dev
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]
From Sebastian LaVine to ~sircmpwn/hare-users
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.
From Sebastian LaVine to ~sircmpwn/hare-users
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. >
From Sebastian LaVine to ~sircmpwn/sr.ht-discuss
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