~smlavine

~smlavine/hareimports-dev

Last active 30 days ago

~smlavine/public-inbox

Last active 3 months ago

~smlavine/err-announce

Last active 3 months ago

~smlavine/ascii-breakout

Last active 5 months ago

~smlavine/omnavi

Last active 6 months ago

~smlavine/tmp-devel

Last active 6 months ago

~smlavine/tmp-announce

Last active 6 months ago

~smlavine/pre-push-devel

Last active 10 months ago

~smlavine/pre-push-announce

Last active 10 months ago

~smlavine/navipage-announce

Last active 11 months ago
View more

Recent activity

stdlib link in todo tracker a day ago

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

Re: Possible Bug found using strings 6 days ago

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;

Re: Per project git page? 15 days ago

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.

Idea on how to deal with enums and build tags 30 days ago

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.

[PATCH harec v2] Fix segfault on not enough params for variadic function call 30 days ago

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]

Re: [PATCH harec] Fix segfault on not enough params for variadic function call 30 days ago

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

[PATCH harec] Fix segfault on not enough params for variadic function call 30 days ago

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]

Re: crazy idea (Hare scripting?) a month ago

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.

Re: crazy idea (Hare scripting?) a month ago

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.
>

Re: Showing git commit sign status on logs a month ago

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