submit fun challenge for 2025/ayu (fixed)

[Master-Hash]

previous attempt: GH-267

On x86 machine char is signed while on arm it's unsigned. It runs on AArch64 before this commit; so always use unsigned char explicitly is the way.

[Master-Hash]

I found that you are changing how to exhibit the solutions, which requires me to create a repo with README, then you'll create a hyperlink to my repo. I wonder if it can be a fork of this repo (aka keep this as is & add a README)

[lcn2]

I found that you are changing how to exhibit the solutions, which requires me to create a repo with README, then you'll create a hyperlink to my repo. I wonder if it can be a fork of this repo (aka keep this as is & add a README)

Let's see how it goes .. give us a bit of time to generate the framework.

UPDATE 0

We plan to generate the 2025/challenge.html page (via a 2025/challenge.md page, which in turn will be initialized by a tool we plan to use when forming a new year's set of winning entries).

So give us a bit of time to set this all up. We will keep you posted.

UPDATE 1

To form your own GitHub repo solution, feel fee to start with the 2025/auy compressed tarball, and modify the prog.c file with your solution.

[xexyl]

I found that you are changing how to exhibit the solutions, which requires me to create a repo with README, then you'll create a hyperlink to my repo. I wonder if it can be a fork of this repo (aka keep this as is & add a README)

Let's see how it goes .. give us a bit of time to generate the framework.

UPDATE 0

We plan to generate the 2025/challenge.html page (via a 2025/challenge.md page, which in turn will be initialized by a tool we plan to use when forming a new year's set of winning entries).

So give us a bit of time to set this all up. We will keep you posted.

UPDATE 1

To form your own GitHub repo solution, feel fee to start with the 2025/auy compressed tarball, and modify the prog.c file with your solution.

Fwiw it's not what I had in mind exactly but I rather like the idea. I think it's way better (so far from what I see).

I have one possible concern though (actually I don't: see below after my original thought here). That might be because (0) I haven't seen it yet; and (1) because I also have a love hate relationship with git.

In particular with the second point I would not be sure how to do this except on a fork. Problem is that it might have to be on a branch and how do we go about that with pull requests when (at least some of us - though I have seen some do it on master branch although most people also don't have many pull requests open at once) we have multiple branches?

That would be a moot point if GitHub allowed us to fork a repo more than once but unfortunately they don't.

That being said Landon has always done a brilliant job and in the case that it doesn't work right he's always changed things.

Ahhh. But now I wonder. It might not need a fork. It might be convenient for some (unfortunately) but wouldn't this work?

--

Make a new repo and just have a directory with e.g. 2025/luser/prog.c (and whatever other files)[0].

This seems now I think on it way better than what I originally thought of although in order to see that you probably would have to see both my original concerns and my ideas of what might be possible solutions (actually I was thinking it might just be somewhere in the website but as far as the concerns there are too many to list here).

Nonetheless this idea seems like it will resolve my several concerns I raised.

Once again I really appreciate your taking this seriously @lcn2 ! I do also btw hope that (and I am guessing this is the case) you will have the actual challenges in the challenges.html file too.

Also when I suggested that previous years might have challenges as well (if desired) this would make it way easier to implement as it would be only one file that would have to be created.

[0] Obviously I couldn't resist the classic joke of luser and hacker lore when in fact we are actually talking about winners!

[Master-Hash]

I found that you are changing how to exhibit the solutions, which requires me to create a repo with README, then you'll create a hyperlink to my repo. I wonder if it can be a fork of this repo (aka keep this as is & add a README)

Let's see how it goes .. give us a bit of time to generate the framework.

UPDATE 0

We plan to generate the 2025/challenge.html page (via a 2025/challenge.md page, which in turn will be initialized by a tool we plan to use when forming a new year's set of winning entries).
So give us a bit of time to set this all up. We will keep you posted.

UPDATE 1

To form your own GitHub repo solution, feel fee to start with the 2025/auy compressed tarball, and modify the prog.c file with your solution.

Fwiw it's not what I had in mind exactly but I rather like the idea. I think it's way better (so far from what I see).

I have one possible concern though (actually I don't: see below after my original thought here). That might be because (0) I haven't seen it yet; and (1) because I also have a love hate relationship with git.

In particular with the second point I would not be sure how to do this except on a fork. Problem is that it might have to be on a branch and how do we go about that with pull requests when (at least some of us - though I have seen some do it on master branch although most people also don't have many pull requests open at once) we have multiple branches?

That would be a moot point if GitHub allowed us to fork a repo more than once but unfortunately they don't.

That being said Landon has always done a brilliant job and in the case that it doesn't work right he's always changed things.

Ahhh. But now I wonder. It might not need a fork. It might be convenient for some (unfortunately) but wouldn't this work?

--

Make a new repo and just have a directory with e.g. 2025/luser/prog.c (and whatever other files)[0].

This seems now I think on it way better than what I originally thought of although in order to see that you probably would have to see both my original concerns and my ideas of what might be possible solutions (actually I was thinking it might just be somewhere in the website but as far as the concerns there are too many to list here).

Nonetheless this idea seems like it will resolve my several concerns I raised.

Once again I really appreciate your taking this seriously @lcn2 ! I do also btw hope that (and I am guessing this is the case) you will have the actual challenges in the challenges.html file too.

Also when I suggested that previous years might have challenges as well (if desired) this would make it way easier to implement as it would be only one file that would have to be created.

[0] Obviously I couldn't resist the classic joke of luser and hacker lore when in fact we are actually talking about winners!

@xexyl excuse me, is there anything I need to pay attention? I didn't get the point.

[xexyl]

I found that you are changing how to exhibit the solutions, which requires me to create a repo with README, then you'll create a hyperlink to my repo. I wonder if it can be a fork of this repo (aka keep this as is & add a README)

Let's see how it goes .. give us a bit of time to generate the framework.

UPDATE 0

We plan to generate the 2025/challenge.html page (via a 2025/challenge.md page, which in turn will be initialized by a tool we plan to use when forming a new year's set of winning entries).

So give us a bit of time to set this all up. We will keep you posted.

UPDATE 1

To form your own GitHub repo solution, feel fee to start with the 2025/auy compressed tarball, and modify the prog.c file with your solution.

Fwiw it's not what I had in mind exactly but I rather like the idea. I think it's way better (so far from what I see).

I have one possible concern though (actually I don't: see below after my original thought here). That might be because (0) I haven't seen it yet; and (1) because I also have a love hate relationship with git.

In particular with the second point I would not be sure how to do this except on a fork. Problem is that it might have to be on a branch and how do we go about that with pull requests when (at least some of us - though I have seen some do it on master branch although most people also don't have many pull requests open at once) we have multiple branches?

That would be a moot point if GitHub allowed us to fork a repo more than once but unfortunately they don't.

That being said Landon has always done a brilliant job and in the case that it doesn't work right he's always changed things.

Ahhh. But now I wonder. It might not need a fork. It might be convenient for some (unfortunately) but wouldn't this work?

--

Make a new repo and just have a directory with e.g. 2025/luser/prog.c (and whatever other files)[0].

This seems now I think on it way better than what I originally thought of although in order to see that you probably would have to see both my original concerns and my ideas of what might be possible solutions (actually I was thinking it might just be somewhere in the website but as far as the concerns there are too many to list here).

Nonetheless this idea seems like it will resolve my several concerns I raised.

Once again I really appreciate your taking this seriously @lcn2 ! I do also btw hope that (and I am guessing this is the case) you will have the actual challenges in the challenges.html file too.

Also when I suggested that previous years might have challenges as well (if desired) this would make it way easier to implement as it would be only one file that would have to be created.

[0] Obviously I couldn't resist the classic joke of luser and hacker lore when in fact we are actually talking about winners!

@xexyl excuse me, is there anything I need to pay attention? I didn't get the point.

Possibly not. This was mostly for Landon. The only part that might be relevant is the suggestion that would mean you might not need it to be a fork of the winner repo.

But that can be addressed after everything is implemented.

Apologies about the confusion!