Allegro pull requests

Aye. Edgar Reynaldo over on allegro.cc is being just brilliant on this subject.

I went in expecting to get the old story of 'Just upgrade to Allegro 5', but instead I find that there is better support for ag4 now, than there was in 2011; so it would be prudent for each of us to participate on the forums there, and try to fix as much as possible in ag 4.4.3, and aim for a proper release of that.

Here is a changelog for allegro 4.4.3 over 4.4.2.

Insofar as they KB issue, I am having problems making the bug occur in any ZC build at present, including in 2.50.2. If it is a race condition as [MENTION=38582]Saffith[/MENTION] suspects, then I am unsure how to trigger it. If it is a library issue as [MENTION=42714]Gleeok[/MENTION] and I believe, then it may have been fixed--hard to tell just yet.

It would be great if all of our special needs, and out fixes, are simply in the core library though.

I have a few live topics over on allegro.cc if anyone wishes to participate in them.

Aye. Edgar Reynaldo over on allegro.cc is being just brilliant on this subject.

I went in expecting to get the old story of 'Just upgrade to Allegro 5', but instead I find that there is better support for ag4 now, than there was in 2011; so it would be prudent for each of us to participate on the forums there, and try to fix as much as possible in ag 4.4.3, and aim for a proper release of that.

Here is a [url=https://pastebin.com/JinsWu26]changelog for allegro 4.4.3 ]/url]over 4.4.2.

Insofar as they KB issue, I am having problems making the bug occur in any ZC build at present, including in 2.50.2. If it is a race condition as [MENTION=38582]Saffith[/MENTION] suspects, then I am unsure how to trigger it. If it is a library issue as [MENTION=42714]Gleeok[/MENTION] and I believe, then it may have been fixed--hard to tell just yet.

It would be great if all of our special needs, and out fixes, are simply in the core library though.

I have a few live topics over on allegro.cc if anyone wishes to participate in them.

[DP; remove]

ZoriaRPG wrote:Aye. Edgar Reynaldo over on allegro.cc is being just brilliant on this subject.

I went in expecting to get the old story of 'Just upgrade to Allegro 5', but instead I find that there is better support for ag4 now, than there was in 2011; so it would be prudent for each of us to participate on the forums there, and try to fix as much as possible in ag 4.4.3, and aim for a proper release of that.

Here is a changelog for allegro 4.4.3 ]/url]over 4.4.2.

Insofar as they KB issue, I am having problems making the bug occur in any ZC build at present, including in 2.50.2. If it is a race condition as @[URL="http://www.armageddongames.net/member.php?u=38582"]Saffith suspects, then I am unsure how to trigger it. If it is a library issue as @Gleeok and I believe, then it may have been fixed--hard to tell just yet.

It would be great if all of our special needs, and out fixes, are simply in the core library though.

I have a few live topics over on allegro.cc if anyone wishes to participate in them.

The code snippet that Saffith posted on Pure is definitely buggy:

buffer->lock++;
   if (buffer->lock != 1) {
      buffer->lock--;
      return;
   }
   // Do stuff
   buffer->lock--;

Thread 1 reads the value of lock (0)
Thread 2 reads the value of locK (0)
Thread 1 post-increments lock (now 1) and enters the critical section
Thread 2 post-increments lock (writing 1 again) and enters the critical section
Both threads decrement lock (now -1).

As with all concurrency bugs, however, even though the code is objectively incorrect, it might happen to work on some compilers on some machines, where the increment happens to be atomic; or the bug might be present but never exercised due to precise timings of context switches on some particular machine.

DarkDragon wrote:The code snippet that Saffith posted on Pure is definitely buggy:

buffer->lock++;
   if (buffer->lock != 1) {
      buffer->lock--;
      return;
   }
   // Do stuff
   buffer->lock--;

C++ is not required to compile lock++ into an atomic operation, in which case the following sequence is possible:

Thread 1 reads the value of lock (0)
Thread 2 reads the value of locK (0)
Thread 1 post-increments lock (now 1) and enters the if block
Thread 2 post-increments lock (writing 1 again) and enters the if block
Both threads decrement lock (now -1).

As with all concurrency bugs, however, even though the code is objectively incorrect, it might happen to work on some compilers on some machines, where the increment happens to be atomic; or the bug might be present but never exercised due to precise timings of context switches on some particular machine.

Wouldn't a basic statement of :

 if ( buffer->lock > 0 ) buffer->lock--; 

help there?

That way, the second thread would not touch it.

Nope. This has the exact same problem as the original code.

DarkDragon wrote:Nope. This has the exact same problem as the original code.

I'm not really sure how to make this an atomic operation that is respected in each of our various compilers, and on every architecture that we use. I think it would be different between gcc/MinGW, and MSVC, and possibly between different MSVC versions; plus it may be different from Windows to Liux and OSX (FreeBSD).

If any if you are clever-enough to know a solution, I'm all eyes. Is using std::atomic for the variable sufficient for our needs, or will that fail based on the compiler? I'm not sure at what point this was introduced as art of the cpp spec, to keep this cpp08 happy.

Which allegro file is this, BTW, so that I can post the problem on allegro.cc? ?

Right. It's one of the many things that is a lot easier to do in C++11 than C++03. I'm pretty sure Allegro already has a mutex implementation somewhere, though.

DarkDragon wrote:Right. It's one of the many things that is a lot easier to do in C++11 than C++03. I'm pretty sure Allegro already has a mutex implementation somewhere, though.

I could still use a file ref where this code lives. For some reason, my search function started to refuse to give any results on any source code, which if quite, quite, fun.

P.S. I would search the GH branch, but IIRC, GH does not permit searching branches.

Searching the build for ALL_ZC in MSVC returns nothing.

Never mind. The file is [FONT=Courier New]keyboard.c[/FONT] as a deep search with DOpus discovered.

Well, the edit post button seems to be failing. I'll post a P.S. about that below.

Here is a link to the discussion on this topic over at allegro.cc. Mates, you might want to chime in over there.
[MENTION=38500]War Lord[/MENTION] & [MENTION=1]DarkDragon[/MENTION]

I have encountered some issues on AGN today, and yesterday. The edit post button seems to fail to load the edit dialogue, and on two occasions I received an error:

You do not have permission to accesss /newreply.php on this server.

I'm posting this here, in the event that I run into it again. I'm hoping that this post goes through.

I was just going to copy over some atomic code from my own library I use and use that to fix it, but if you guys want to do it then be my guest. 😉

ZoriaRPG wrote:I'm not really sure how to make this an atomic operation that is respected in each of our various compilers, and on every architecture that we use. I think it would be different between gcc/MinGW, and MSVC, and possibly between different MSVC versions; plus it may be different from Windows to Liux and OSX (FreeBSD).

If any if you are clever-enough to know a solution, I'm all eyes. Is using std::atomic for the variable sufficient for our needs, or will that fail based on the compiler? I'm not sure at what point this was introduced as art of the cpp spec, to keep this cpp08 happy.

Which allegro file is this, BTW, so that I can post the problem on allegro.cc? ?

You can use intrinsics. std::atomic, like all of c++, is just bloated wrappers around c. Plus, allegro compiles as c code so simple is fine. For example, std::atomic:😮perator++ is the equivalent of:
_InterlockedIncrement(); on windows, or
__sync_add_and_fetch(). on gcc, etc.

DarkDragon wrote:Right. It's one of the many things that is a lot easier to do in C++11 than C++03. I'm pretty sure Allegro already has a mutex implementation somewhere, though.

Lies! Nothing in c++11 makes anything easier. Only sadness will you find. :P

Okay, challenge accepted. Please post C or C++03 code that performs an atomic increment correctly on every single standard-compliant C++03 compiler on every computer architecture in the world. I will do the same for C++11 😉

ZoriaRPG wrote:Well, the edit post button seems to be failing. I'll post a P.S. about that below.

Here is a link to the discussion on this topic over at allegro.cc. Mates, you might want to chime in over there.
@War Lord & @DarkDragon

I have encountered some issues on AGN today, and yesterday. The edit post button seems to fail to load the edit dialogue, and on two occasions I received an error:

You do not have permission to accesss /newreply.php on this server.

I'm posting this here, in the event that I run into it again. I'm hoping that this post goes through.

I pinged War Lord about this earlier in the afternoon and he is aware of the problem. I think the host has fixed the issue... for now.

Gleeok wrote:I was just going to copy over some atomic code from my own library I use and use that to fix it, but if you guys want to do it then be my guest. 😉

You can use intrinsics. std::atomic, like all of c++, is just bloated wrappers around c. Plus, allegro compiles as c code so simple is fine. For example, std::atomic:😮perator++ is the equivalent of:
_InterlockedIncrement(); on windows, or
__sync_add_and_fetch(). on gcc, etc.

Lies! Nothing in c++11 makes anything easier. Only sadness will you find. :P

Ill take your fix for now, thanks. I don't want to delve into the murky waters of this more than needed. If it turns out to need more, than it needs more, but let's try the simple fix, first.

I will also further try to convince the allegro blokes to incorporate it, or take it and expand if if they so desire. One genius telling me that we should not care about threads and that allegro was not designed to be thread-safe on 1980s architecture, is just an example of pure madness.

If for some reason it does not work on one compiler or another, we can add in compiler definitions. Yay.
[MENTION=38700]jman2050[/MENTION] Still has an allegro.cc account, and he is the one who posted the original ZC project listing there. I posted an updated listing, and I will add to it as time permits. There is some weird issue with their FTP upload, which claims to support 100MB files, but it is failing me. (I', trying to add the stable Linux build, which is 43MB in size.)

Here is the entry: https://www.allegro.cc/depot/ZeldaClassic1

If [MENTION=38700]jman2050[/MENTION] wants to go in and update his entry (here), then that would also work. Please let me know what you think of my project description and either approve, or grumble.

Allegro already has code for mutexes. I can guarantee you they will refuse to incorporate a fix that half-works on only some platforms, instead of using their own mutex implementation for some reason.

DarkDragon wrote:Allegro already has code for mutexes. I can guarantee you they will refuse to incorporate a fix that half-works on only some platforms, instead of using their own mutex implementation for some reason.

Well, again, if you want to do this, go for it. I don't understand why you and Gleeok butt heads every ten seconds these days. I don't want every stage of this to be a bicker-fest.

Butting heads where? We're bantering about C++11 but switching the whole Allegro project from C to C++11 was obviously not a serious suggestion (and there's a 0% chance the Allegro folks would accept a pull request that tries to do so).

I'm trying to give you practical advice about how to proceed in the way least likely to waste your time, based on my observations about how the Allegro folks run their ship. Obviously feel free to check with Edgar directly if you believe I am wrong.

You don't need C++, anyway. C11 added stdatomic.h and an _Atomic qualifier.

Fun fact: Mutexes is not multi-threading. Mutex locks are the opposite of multi-threading! :P Bicker!!!

DarkDragon wrote:Okay, challenge accepted. Please post C or C++03 code that performs an atomic increment correctly on every single standard-compliant C++03 compiler on every computer architecture in the world. I will do the same for C++11 😉

Bicker bicker bicker!!! Are you saying that c++11 is more widely supported than c? Bicker? Stuff, bicker. Nonsense! Bicker!!

P.S. Anyway, I guess newer gcc can use "__atomic*" prefix...? But clang uses "__sync*" ? ..Whatever. AFAICT they cover windows and unix toolchains so there's probably no issues there.

[edit] Keep in mind that the allegro.cc folks like to argue about anything and everything. At least that's what happened every time I used to stop by there. :P

Gleeok wrote:Fun fact: Mutexes is not multi-threading. Mutex locks are the opposite of multi-threading! :P Bicker!!!

Bicker bicker bicker!!! Are you saying that c++11 is more widely supported than c? Bicker? Stuff, bicker. Nonsense! Bicker!!

P.S. Anyway, I guess newer gcc can use "__atomic*" prefix...? But clang uses "__sync*" ? ..Whatever. AFAICT they cover windows and unix toolchains so there's probably no issues there.

[edit] Keep in mind that the allegro.cc folks like to argue about anything and everything. At least that's what happened every time I used to stop by there. :P

That's definitely true of the guy that's currently posting in the linked thread (he also doesn't seem to have a solid grasp of the problem we're reporting). But the guy Zoria has been talking to (Edgar; I think the main 4.4 maintainer?) sounds reasonable (fingers crossed...)

Oh, hell, I was saying c++03 or c++08 and it should be C99 or C03 something therearound. My error.

ZoriaRPG wrote:
Insofar as they KB issue, I am having problems making the bug occur in any ZC build at present, including in 2.50.2. If it is a race condition as [MENTION=38582]Saffith[/MENTION] suspects, then I am unsure how to trigger it.

I have a few live topics over on allegro.cc if anyone wishes to participate in them.

I know your super-enthused and everything, but trying to repro extremely rare cases is not a good use of time. Trust me. Especially so when Saffith was already able to repro it and trace it to a location, and there is already a proposed fix on top, with cherries even. I find a better use of time is to smoke crack and try to cut flying stink bugs in half with scissors. Those are my pomegranates you sons of bitches!!! Let's see you all try and procreate when you don't have any heads! D:

I would head over to allegro.cc, but I forgot both my password and my username...also can't remember what email I used. lol >_<
If need be I'll make a new account though.

Gleeok wrote:I know your super-enthused and everything, but trying to repro extremely rare cases is not a good use of time. Trust me. Especially so when Saffith was already able to repro it and trace it to a location, and there is already a proposed fix on top, with cherries even. I find a better use of time is to smoke crack and try to cut flying stink bugs in half with scissors. Those are my pomegranates you sons of bitches!!! Let's see you all try and procreate when you don't have any heads! D:

(Emphasis, mine.)

You don't honestly think this; right?

The only reason that I am doing this, is to try to deduce what specific events trigger the clash, and it is only using CPU cycles, not much of my actual time. If I had to invest a huge amount of time into it, then I would likely not want to do it at all.

I would head over to allegro.cc, but I forgot both my password and my username...also can't remember what email I used. lol >_<
If need be I'll make a new account though.

A new account would be wise, as they seem to invalidate accounts after a while. [MENTION=38700]jman2050[/MENTION] has an account there, but when i tried to add him to the project that I listed, it said that his account was invalid.

ZoriaRPG wrote:(Emphasis, mine.)

You don't honestly think this; right?

The only reason that I am doing this, is to try to deduce what specific events trigger the clash, and it is only using CPU cycles, not much of my actual time. If I had to invest a huge amount of time into it, then I would likely not want to do it at all.

Of course I do. I mean what I say and I say what I mean. You know what I mean? I mean, sure, I could just spray them, but then I wouldn't have acquired these deadly precision striking skills with ordinary household items. You knows what I sayin' yo?

I opened a ZC topic over on Allegro.cc here:
https://www.allegro.cc/forums/thread/616990/1031895#target

There is also this discussion on an a4a5 transition layer, that seems to be going somewhere:
https://www.allegro.cc/forums/thread/616977/1

I'm not really sure if I can access my allegro.cc account at all. None of the passwords I might have used work and there seems to be no way of resetting passwords on the site.

jman2050 wrote:I'm not really sure if I can access my allegro.cc account at all. None of the passwords I might have used work and there seems to be no way of resetting passwords on the site.

I think that your account was closed for some reason, as when I tried to add you to the second project listing, I was shown 'No such user' as an error. They probably expire accounts after N-years of non-use. You might try opening a new account with the same username, and see if you can do that. If so, then someone can fix the bindings for your account and the listing for ZC in the projects list.

[MENTION=42714]Gleeok[/MENTION]: Are you working on this? I've been waiting for an update from you.