~lattis

Japan

https://mochiro.moe

~lattis/muon

Last active 16 days ago
View more

Recent activity

Re: [PATCH] Implement version_compare method for string 16 days ago

From Stone Tickle to ~lattis/muon

Looks good to me!  Thanks for this.

Stone

Re: [PATCH] Implement version_compare string method 16 days ago

From Stone Tickle to ~lattis/muon

> Is this an issue with how I am calling interp_error? Or is this possibly a bug in the error messaging?

Ah yes, I re-read your patch, and you aren't calling interp_error
properly.  The second argument to interp_error should be the id of the
AST node where the error occurred.  You passed the id of the method's
receiver object (rcvr), which in the case of your test happens to
actually refer to an AST node (but not the right one). In the case of
your other project, there happens not to be an AST node with the same
object id, so an out-of-bounds assert fires.

Currently inside a function you can either call interp_error with the
`args_node` that you are handed, or, if a specific argument is at fault,
you can do `an[0].node` to get the node of that argument.  This usually
means that support functions also need to get passed an `err_node`, i.e.

Re: [PATCH] Implement version_compare string method 17 days ago

From Stone Tickle to ~lattis/muon

> Okay, good idea. This is pushing my limits of C fanciness :D. I should
> be able to take your example and expand on it.

You can do it!

> Oops, yeah that seems bad. I'll add that as a test case, and add the other
> operators.

Just to clarify, you don't have to match the strange
`'1.2.3'.version_compare('!1.2.3!') > == true` behavior, I was just
pointing out something odd.  I have found quite a few of these things
since I started working on muon.

> Is it okay for string_version_compare to live in functions/string.c

Re: [PATCH] Implement version_compare string method 17 days ago

From Stone Tickle to ~lattis/muon

> This does not implement comparing versions with pre-release or build tags.
> That is something I would like to get to eventually, but I thought it best
> to get feedback on current approach before I continued further on that.

Thanks!  I think it is OK to leave that stuff for later.

> +struct version {
> +	long major, minor, patch;
> +};
> +

I forgot to mention in the CONTRIBUTING.md, but usually integer types
with specific widths are preferred.  E.g. you should probably use
uint32_t for major, minor, patch.  You already ensure that the parsed

Re: [PATCH] Minor changes 18 days ago

From Stone Tickle to ~lattis/muon

Looks good, thanks!

Stone

Re: I've been working on a fork for the past two weeks a month ago

From Stone Tickle to ~bl4ckb0ne/boson

> boson is more of a "I have some spare time this week end" kind of
> project, and I don't have much spare time these days.

I totally get that, I just happened to not be so busy at work lately.

> I think the best would be to rename your fork and make it public.

Gotcha!  I renamed it to muon, and published it here:
https://git.sr.ht/~lattis/muon

I'm not sure exactly how our goals align.  I want to run meson without
python as a basic qualification. I also don't need language support for
anything other than C (and maybe C++, for external tools like tracy[1]).

I've been working on a fork for the past two weeks 2 months ago

From Stone Tickle to ~bl4ckb0ne/boson

Hello,

For awhile now, I've been thinking of re-implementing meson in C.  The
python dependency incurred by any project using meson is unfortunate and
unnecessary.  I put this idea off though, as I have other things to work
on, that is until I saw this project featured on sourcehut!

I thought it was really cool that someone else was taking it upon
themselves to do something that I didn't know anyone else cared about.
I immediately cloned the repo and tried to build one of my projects.  It
didn't work :^).  "That's okay, I'm sure I can fix this" I thought...
"I'll just send a little patch" I thought...

I got bitten by the implementation bug though, and here we are

[PATCH] ensure argv passed to getopt is NULL terminated 1 year, 5 months ago

From Stone Tickle to ~emersion/mrsh-dev

This has two fixes, 1: in push_frame allocates an extra array
element, and uses calloc instead of malloc to ensure that element is
NULL.  2: in argv_dup, enough memory is allocated but, the last element
is left uninitialized.  By using calloc instead, the last element is
guaranteed to be NULL.

I also added a test for this, although it does not always fail since it
relies on undefined behavior.
---
 builtin/set.c    | 2 +-
 shell/shell.c    | 2 +-
 test/args.sh     | 6 ++++++
 test/meson.build | 1 +
 4 files changed, 9 insertions(+), 2 deletions(-)
[message trimmed]

Invalid read in mrsh_getopt getopt.c:13 1 year, 5 months ago

From Stone Tickle to ~emersion/mrsh-dev

Hi, I sent some messages about this on ##emersion, but I wanted to
reiterate here, since it looks like that channel is not very active.

While working on the read patch, I happened to run mrsh on my macbook
and noticed a bug.  Specifically, if I have a script like this:

#!/bin/mrsh
while getopts "a" opt; do
  do_something
done

And run it like this:

$ ./script.sh -a

[PATCH] make read return 1 when an EOF is encountered 1 year, 5 months ago

From Stone Tickle to ~emersion/mrsh-dev

For instance:
echo "hi" | read arg
should have an exit code of >0 per the POSIX spec

- a test was also added
---
 builtin/read.c   |  7 ++++++-
 test/meson.build |  1 +
 test/read.sh     | 17 +++++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 test/read.sh

diff --git a/builtin/read.c b/builtin/read.c
index d014969..a0ce82e 100644
[message trimmed]