hbyteswp.h current master and develop branches

[atncsj6h]

The current preprocessor logic prevents using the byteswap bultins when NO_ASM_BYTESWAP is set to 1.

IMO the correct sequence should be something along the lines of :

#if defined( HAVE_BYTESWAP_H )
   do nothing 
#elif defined( HAVE_SWAP_BUILTINS )
  use the builtins
#elif !defined( NO_ASM_BYTESWAP )
  use the RYO asm
#else 
  use c 
#endif

Happy New Year to everybody!

enrico

P.S. a simple "unifdef -DNO_ASM_BYTESWAP -B hbyteswp.h" command will show what I mean.

[Fish-Git]

NO_ASM_BYTESWAP is only defined if and only if: the build architecture is not x86, and the system byteswap.h header is not found. That is to say, only when both conditions are true (not x86 architecture and system byteswap header not found) is NO_ASM_BYTESWAP ever defined.

But it appears you are wanting to use builtins on non-x86 build architectures even when the system byteswap.h header is not found? Is that correct?

While that certainly seems reasonable, I'm more interested in why your non-x86 build architecture is unable to locate the byteswap.h system header! It seems to me that is the bug that needs to be fixed!

[atncsj6h]

Hi Fish,

But it appears you are wanting to use builtins on non-x86 build architectures even when the system byteswap.h header is not found? Is that correct?

that' s correct

While that certainly seems reasonable, I'm more interested in why your non-x86 build architecture is unable to locate the byteswap.h system header! It seems to me that is the bug that needs to be fixed!

I am on APPLE big sur, and APPLE does not provide byteswap.h ( and never did )

enrico

[Fish-Git]

Fixed by commit 8b20ae3acbeeab5cb30182b39e217cbcedd96998.

Closing.

[wrljet]

Fish,

What is causing these extra commits? Such as:

Merge branch 'develop' of https://github.com/SDL-Hercules-390/hyperion into develop

Bill

[Fish-Git]

What is causing these extra commits? Such as:

Merge branch 'develop' of https://github.com/SDL-Hercules-390/hyperion into develop

Someone (i.e. ME!) forgetting to do a git pull to merge recent updates (commits) into one's local repository (to bring it current) before committing ones own changes. When that happens, ones local repository becomes "out of sync" with the remote, preventing one from being able to push their commit. Instead, one must first do a pull to merge the remote repository's commit into ones local repository and then push the results to the remote (which, due the commits being applied "out of sequence" in ones local repository, causes a "merge" to occur when one pushes their commit).

I don't know what git client you personally use, but I use TortoiseGit (a GUI git client) and its commit log illustrates what has actually happened when such a situation occurs:

As you can see, you actually made your commit and pushed it to the remote before I committed my changes to my local repository. (i.e. I failed to do a 'pull' to merge your changes into my local repository before I committed my own changes to my local repository).

As a result, after I did my commit (without doing a pull first), my local repository got "out of sync" with "reality" (with the remote). So when I eventually did my pull (to bring your changes into my local), your commit ended up being committed physically after my own commit, when in actuality it should have been the exact opposite. (Your commit was actually made logically before my commit, not after!)

Thus when the push occurred (to push my changes to the remote), git had to basically temporarily undo your commit so that it could then apply my commit, and then afterwards, merge your commit back into the repository again to keep everything in sync.

As I said, it's me basically being forgetful/lazy, forgetting to always do a pull before committing my own changes to my local repository (to ensure my local repository matches the remote before I make my own commit). Sorry!

No damage occurs whatsoever. It's actually not that big of a deal. It's something that occasionally happens when there are multiple people working with the same repository. Such occurrences can still nevertheless occur even when one is careful to always do a pull beforehand:

1. You have uncommitted changes you want to commit.
2. You properly do a pull beforehand to bring your local repository current with the remote.
3. You commit your changes to your local repository.
4. You try pushing your commit to the remote, but...
5. Git complains that your local doesn't match the remote!
6. So you do yet another pull and discover yet another commit (that someone pushed just a split second ago) that your local didn't have (which is then added to your local repository too, but physically after your commit instead of before it).
7. You finally try your push again, and this time it works okay, but of course results in git having to do an automatic "Merge commit" in order to get the commits back into their proper sequence.

Does that make sense?

[Fish-Git]

Thus when the push occurred (to push my changes to the remote), git had to basically temporarily undo your commit so that it could then apply my commit, and then afterwards, merge your commit back into the repository again to keep everything in sync.

Actually, what I think actually happens is, git creates a temporary internal "merge branch" anchored at the point immediately prior to your commit (since that's what my local looked like when I made my local commit), commits my changes to that temporary branch, and then afterwards, automatically "merges" that temporary branch back into the main branch.

That is to say, I don't think it does an "undo" of your commit before it commits my changes. Rather it simply creates an internal branch and commits my changes to that temporary branch and then automatically merges the changes in that temporary branch back into the main branch. That's what I think is actually happening.

But the idea is the same: it needs to juggle things around so that the commits get applied to the repository in the correct sequence.

[wrljet]

Fish,

Yes, it makes sense now that you've explained it. I'm one of those oldtimers who still doesn't get git.  :-)

I will give TortoiseGit a try. I've been trying to do most of my commits via command line in *Nix, after having GitHub Desktop (for Windows) goof up the permission bits a few times.

Bill

[Fish-Git]

I will give TortoiseGit a try.

If, after installing it, you need any help with configuring it or using it, let me know. I've been using it for years.

[Fish-Git]

p.s. It also helps to have a good visual comparison tool installed too, such as ExamDiff Pro. When you do, viewing commits becomes trivially easy. (and fun!)  I learn a lot by reviewing other people's commits.

It also makes it much easier to review your own changes before you commit them too. I personally couldn't imagine doing any type of serious software development without having something like ExamDiff Pro installed. I mean that seriously. It's a tool that IMO should be in every programmer's tool box.

I can help you with setting it up (configuring it) too. With its plethora of options it can be quite intimidating to the first time user. Getting the toolbar (and a few default comparison options) set up right is essential IMO. Once you have that set up, 99% of what you normally do is either just a simple double-click or a click of a toolbar button.

[wrljet]

Fish,

p.s. It also helps to have a good visual comparison tool installed too, such as ExamDiff Pro. When you do, viewing commits becomes trivially easy. (and fun!) I learn a lot by reviewing other people's commits.

I've been using WinMerge since Jesus was a small boy. But it's not all that actively developed/supported anymore.

Bill