You can find a port of Hare to macOS, but last time I tried it it didn't work.

Le dim. 29 janv. 2023 à 10:43, Unicorn <unicorn@regrow.earth> a écrit :
>
> Hi,
>
> my understanding is that Hare will never officially support proprietary
> operating systems like macOS or Windows, so somebody from the community
> will have to create support separately if needed.
> As for what are the steps required to do so, I perhaps somebody else can
> help. :)
>
> Best,
> Edin

Thanks for the detailed analysis Umar.
I believe the patch does not carry its own weight and should be rolled back.
This is Drew's decision of course :).

Le mer. 28 déc. 2022 à 11:49, Umar Getagazov <umar@handlerug.me> a écrit :
>
> On Fri Dec 23, 2022 at 3:33 PM +03, Drew DeVault wrote:
> > This causes the link for crypto::aes to lead to /crypto/crypto/aes when
> > tested in Firefox with python3 -m http.server. *Test* your changes
> > before you send the patch, please.
>
> I noticed this conversation and thought I should chime in yet again.
>
> To ensure we're all on the same page, this is how relative URLs work[0]:

Sorry, I did test, and just redid and it works fine for me :/, either via
an http server (same cli as yours) or opening the file in a browser.
Not much time to spend on this now, but will look further.

Le ven. 23 déc. 2022 à 13:33, Drew DeVault <sir@cmpwn.com> a écrit :
>
> This causes the link for crypto::aes to lead to /crypto/crypto/aes when
> tested in Firefox with python3 -m http.server. *Test* your changes
> before you send the patch, please.

Thanks for the explanation!

Le mar. 13 déc. 2022 à 20:54, Ember Sawady <ecs@d2evs.net> a écrit :
>
> Er, in my previous email, I meant to say *(&a: *b), but the point still
> stands: we can't special-case a dereference and only drop the safety
> checks there.
>
> On Tue Dec 13, 2022 at 7:04 PM UTC, Pierre Curto wrote:
> > Yes, but then why does the match fail to see the a and b types?
>
> The first 32 bits of x are 10, so when that bit of memory is interpreted
> as a tagged union (of type z), the tag ends up being 10. This isn't the
> tag for either a or b, so neither of the match cases are taken. The

Le mar. 13 déc. 2022 à 17:59, Ember Sawady <ecs@d2evs.net> a écrit :
>
> On Tue Dec 13, 2022 at 2:25 PM UTC, Pierre Curto wrote:
> > AFAICT your conversion line 23 is invalid, as the internal representation of
> > a tagged union does not match the one for the a or b types (it has a u32 tag
> > in front I believe). Maybe the compiler should detect that.
>
> No, &a: *b is used to get around the compiler's safety checks around
> conversions - it's similar to how if you cast an array to *[*]t and do
> an out-of-bounds access, you'll get a segfault.

Yes, but then why does the match fail to see the a and b types?

Le mar. 13 déc. 2022 à 13:04, denis <denis@ecaf.be> a écrit :
>
> Hello,
>
> > Welcome to Hare!
>
> Thank you :)
>
> > This is a known issue, but easily worked around: simply add a default
> > case in your match expression, as follows.
>
> I just tried, and now everything go to the default case... So I can't
> use the struct.
>

Welcome to Hare!

This is a known issue, but easily worked around: simply add a default
case in your match expression, as follows.

```
use fmt;

type a = struct {
        i: int,
};

type b = struct {
        j: int,

Thanks for the clear explanation. Might add a comment in there to
clarify the intention.

Le jeu. 24 nov. 2022 à 14:45, Bor Grošelj Simić <bgs@turminal.net> a écrit :
>
> This is not the correct fix for #769:
>
> >               if (new->otype == O_SCAN) {
> >                       new = wrap_resolver(ctx, new, resolve_enum_field);
> This line says, hey, tell me what this enum field really is, by doing some
> calculations in local enum scope.
>
> > -             assert(new->otype == O_CONST);
> The intent of this assert is to verify that whatever the previous call

Makes sense. Making the change in check.c (check_expr_binarithm)
breaks existing code
in a few places where the right hand side is a simple int though,
e.g. https://git.sr.ht/~sircmpwn/harec/tree/master/item/rt/%2Blinux/syscalls.ha#L44

I have double checked the specifications and it does mention that both
operands must be
unsigned. OK to fix the places where this breaks?

Le jeu. 24 nov. 2022 à 15:22, Bor Grošelj Simić <bgs@turminal.net> a écrit :
>
> Rejecting this approach, see https://todo.sr.ht/~sircmpwn/hare/771#event-215318
> for explanation.

I tried both and it worked.

Le lun. 21 nov. 2022 à 15:26, Drew DeVault <sir@cmpwn.com> a écrit :
>
> On Thu Nov 17, 2022 at 5:36 PM CET, ~pierrec wrote:
> > From: Pierre Curto <pierre.curto@gmail.com>
> >
> > This helps when viewing documentation directly instead of served over HTTP.
> >
> > Signed-off-by: Pierre Curto <pierre.curto@gmail.com>
>
> Can you verify that you generated the stdlib docs and browsed around
> both with file:// and an HTTP server to test this?