Bonkers Transexual Pseudo-Hacker.


Last active a month ago


Last active 6 months ago


Last active 6 months ago
View more

Recent activity

Re: On setting env vars by default a month ago

From Autumn Orr to ~autumnull/haredo

On 10 May 2024 23:03:28 BST, Coutinho de Souza <srht-n2c9ebas@onemoresuza.com> wrote:
>As of now, the only way to avoid the default environment variables is by
>setting them to another value. However, there are some cases in which
>the variable being unset is desirable.

can't you just use unset(1) ? it's in posix shell

Re: Usage of positional arguments 4 months ago

From Autumn! to ~autumnull/haredo

On 1/27/24 00:43, Coutinho de Souza wrote:
> Using haredo in the meantime, I've realized that there's already a way
> to achieve what I was proposing with passing the arguments as
> environment variables, by simply doing this: :)

glad to hear

> But perhaps, the used shell could be overridden? By doing so, it would
> allow shell specific functionality --- e. g., bash's arrays, ksh's regex
> ---, while also guarantying which shell is being used, since `sh` is
> usually a symlink to another shell.

the reason that 'sh' is used is to make the build scripts as portable as 
possible, so that it doesn't rely on non-standard shell behavior

Re: Usage of positional arguments 4 months ago

From Autumn! to ~autumnull/haredo

> 2. Being unable to overwrite the positional arguments array --- "${@}"
>     --- outside of functions, which is the only way of ensuring that some
>     output is correctly escaped on POSIX, since there are no arrays like
>     in Bash.
> So I ask: is the design of using the positional arguments directly here
> to stay?
> Because if not, the values on "${1}", "${2}" and "${3}" could have the
> same treatment as the defined environment variables[1], like `${HARE}`
> or `${CC}`, that is, they could be something like `${HAREDO_*}`. "${3}",
> for instance, could become `${HAREDO_TMPFILE}`.

i don't know enough about posix shell to understand what you're talking

Re: [PATCH] update for stdlib bufio/memio and sort 6 months ago

From Autumn! to ~autumnull/treecat-dev

Actually now that I'm back at my computer I've applied the patch and it 
seems to pass all the tests just fine (after a small unrelated change).



Re: [PATCH] update for stdlib bufio/memio and sort 6 months ago

From Autumn to ~autumnull/treecat-dev

>Any ideas where I could go looking around to find its cause?
thanks for pointing it out. this is almost certainly due to a change in the fmt:: format string syntax. i'm away from my computer at the minute but i would start looking at updating the uses of fmt:: functions.


Re: New release? 6 months ago

From Autumn! to ~autumnull/haredo-devel

> I had to export a corrected PATH to get ./bootstrap.sh install to work[0]. I
> am not sure if that is an issue in the bootstrap script.
> [0]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55929/diffs#7a4796522f9fb4de4542e829a82eee0b86bf84dd_25_24
Interesting. I'm not sure why that is. If you change line 6 of 
bootstrap.sh from "bin:$PATH" to "$PWD/bin:$PATH" does that help? If so 
I can change that upstream.

I suppose it's not the end of the world either way.


Re: Sharing Variables between .do Files 6 months ago

From Autumn! to ~autumnull/haredo

> I've being playing around with `haredo` and being finding it awesome!
Nice, thanks for saying so :)

> I was wondering the following:
> 1. Would there be any other way of achieving this variables sharing?
The way you've listed is the best way I know of. Since the environment 
variables carry down to child processes, you can get away with just 
sourcing env.sh in the .do files that you intend to call as top-level 
targets, but that's the only improvement.

> 2. Should I be thinking differently on how to work with haredo? Perhaps
>     this sharing could be replaced with a more idiomatic construction?

Re: New release? 6 months ago

From Autumn! to ~autumnull/haredo-devel

I've now pushed 1.0.4 tag, lmk if any problems.


Re: [PATCH harec] type_store: allow unbounded arrays with undefined member size 8 months ago

From Autumn! to ~sircmpwn/hare-dev

so, my main reasons for this were:

marking up C-style array pointers with more useful information, as bgs 
and then secondly it just seems unnecessary to forbid it. this patch 
just makes it so that the restriction of "you can't instantiate a type 
of undefined size" is only applied where necessary. in fact honestly 
e.g. *[4]opaque could be allowed too, since it's not doing any harm as a 
pointer, and that would remove the special case for just bounded array 
pointers. i hadn't really considered that part when i sent this patch.

the nice thing about pointers is that they're just an address to the 
start of an item, so you don't have to care about the size of the item, 
and the type checking rules for pointers can ignore undefined size --