Re: rldicl / rldicr for 32-bit powerpc?
On Sat, 15 Jul 2023, Ken Cunningham wrote: Adding it into cctools for the standard assembler to use whenever it might be needed would be something of a project, to be sure... I think it would be highly unusual for an assembler to replace instructions for one architecture with instructions for another architecture, even when the two are related. Anything generating actual machine instructions should know what architecture it's targeting, and generate appropriate code. However, patching it into a source file that needs it on a case-by-case basis is probably a fairly trivial thing to do. Probably so, once one works out the appropriate instructions. That's not hard in principle (though trickier for the "dotted" versions), but I'm busy with other stuff right now (and don't currently have a working ppc64 machine for comparison testing). The linked code is for an emulator, and is providing a *C* implementation, not a ppc32 machine-code implementation. Fred Wright
Re: Commit Messages
On Sat, 15 Jul 2023, David Gilman wrote: I imagine this can be linted in the git local commit-msg hook. It won't stop a dedicated offender who can push directly to master but it wouldn't hurt to ship it in the macports-ports repo and promote it in the guidelines. It would be fairly straightforward to catch this in a pre-commit hook, and those apply at the time commits are created, and hence don't care about whether the commits will eventually be pushed directly or submitted as PRs. But hooks don't propagate across repos, so such a hook would only apply to users who'd explicitly installed it. Another possibility would be a receiver-side hook on GitHub, but those aren't intended for this sort of purpose, so constructing such a hook would be more complicated. Fred Wright On Sat, Jul 15, 2023 at 2:58 PM Fred Wright wrote: In recent times, commit messages failing to conform to the guidelines have been becoming more common - specifically, the failure to include a blank line after the summary. The guidelines even state briefly why this matters, though perhaps not emphatically enough. Recent offenders are: 2d9585490dc87249c189c211a228984b3a3830c7 331c484f0c10d378bcbf011fa14cb7fc0e1768be f5ce144934601cc243df6e02b2d47b7956acd335 b395f71013212e625fb96051bcc9a31aa0b5bd26 The standard git tools split a commit message into a summary (a.k.a. subject) and a body, with the first blank line being the division point. In format strings, these are %s and %b, respectively. Some third-party git tools limit the summary to the first line, so people using such tools may not even notice the error, but such tools shouldn't be the standard. The output of commands like "git log --oneline" and "git branch -v" becomes quite annoying with this error. Fred Wright -- David Gilman :DG<
Re: rldicl / rldicr for 32-bit powerpc?
Adding it into cctools for the standard assembler to use whenever it might be needed would be something of a project, to be sure... However, patching it into a source file that needs it on a case-by-case basis is probably a fairly trivial thing to do. > On Jul 15, 2023, at 11:45 AM, Sergio Had wrote: > > Well, I didn’t mean copy-pasting the patch, of course, it was just the only > relevant thing that was found. > > NodeJS uses those instructions in some procedures (either in codebase or > PPC-specific patches), and I am looking to fixing it finally for 32-bit. > On Jul 16, 2023 02:39 +0800, Fred Wright , wrote: >> >> On Sat, 15 Jul 2023, Sergey Fedorov wrote: >> >>> Is there an implementation to replace these on ppc32? >>> >>> There is some Linux version online which I found: >>> https://patchwork.kernel.org/project/kvm/patch/1403472217-22263-30-git-send-email-ag...@suse.de/ >>> But since it is a magic code, no idea if it is portable or not. >> >> You'd have to be more specific about the intended context. AFAIK, >> OSX/macOS didn't have anything like KVM until 10.10, so this specific >> patch wouldn't be relevant. >> >> Fred Wright
Re: Commit Messages
I imagine this can be linted in the git local commit-msg hook. It won't stop a dedicated offender who can push directly to master but it wouldn't hurt to ship it in the macports-ports repo and promote it in the guidelines. On Sat, Jul 15, 2023 at 2:58 PM Fred Wright wrote: > > > In recent times, commit messages failing to conform to the guidelines have > been becoming more common - specifically, the failure to include a blank > line after the summary. The guidelines even state briefly why this > matters, though perhaps not emphatically enough. Recent offenders are: > > 2d9585490dc87249c189c211a228984b3a3830c7 > 331c484f0c10d378bcbf011fa14cb7fc0e1768be > f5ce144934601cc243df6e02b2d47b7956acd335 > b395f71013212e625fb96051bcc9a31aa0b5bd26 > > The standard git tools split a commit message into a summary (a.k.a. > subject) and a body, with the first blank line being the division point. > In format strings, these are %s and %b, respectively. Some third-party > git tools limit the summary to the first line, so people using such tools > may not even notice the error, but such tools shouldn't be the standard. > The output of commands like "git log --oneline" and "git branch -v" > becomes quite annoying with this error. > > Fred Wright -- David Gilman :DG<
Re: Commit Messages
Thank you for pointing this out. This has been an annoyance for me, too. I think perhaps some contributors may be unaware of the issue due to differences in tooling or perhaps just not noticing, but I thought illustrating the problem might help. If you don’t include a blank line after the summary, in most(?) git tooling you will see the entire commit message on a single line that likely overflows the allotted UI. Example: > Pothos*: add forgotten pg compiler_blacklist_versions See: > https://github.com/macports/macports-ports/commit/936460c22e467e2da904e4da1510dc8d0a71d1c4 With a blank line after the summary (before “See:”), the above will show as intended: > Pothos*: add forgotten pg compiler_blacklist_versions When viewing commit logs, it is important for readability that summaries be succinct. Spot the problem below! > 6ff5870e1a2 py-pikepdf: update to 8.0.0 > 4804bfc7c58 qpdf: update to 11.5.0 > ff196f7ee42 sudo: update to 1.9.14p1 > beb390fb2ba TeXShop: update to 5.14 > fc485378a2e stunnel: update to 5.70 > 331c484f0c1 Pothos*: add forgotten pg compiler_blacklist_versions See: > https://github.com/macports/macports-ports/commit/936460c22e467e2da904e4da1510dc8d0a71d1c4 > 03e125ee250 Pothos: simplify via pg stub; rev-bump > 936460c22e4 Pothos*: blacklist clang < 900 > f97be86b5f9 PothosCore: rev-bump due to muparserx ABI change (Sorry to pick on commit 331c484f0c1. It was simply the first example I came across.) -Aaron
Commit Messages
In recent times, commit messages failing to conform to the guidelines have been becoming more common - specifically, the failure to include a blank line after the summary. The guidelines even state briefly why this matters, though perhaps not emphatically enough. Recent offenders are: 2d9585490dc87249c189c211a228984b3a3830c7 331c484f0c10d378bcbf011fa14cb7fc0e1768be f5ce144934601cc243df6e02b2d47b7956acd335 b395f71013212e625fb96051bcc9a31aa0b5bd26 The standard git tools split a commit message into a summary (a.k.a. subject) and a body, with the first blank line being the division point. In format strings, these are %s and %b, respectively. Some third-party git tools limit the summary to the first line, so people using such tools may not even notice the error, but such tools shouldn't be the standard. The output of commands like "git log --oneline" and "git branch -v" becomes quite annoying with this error. Fred Wright
Re: rldicl / rldicr for 32-bit powerpc?
Well, I didn’t mean copy-pasting the patch, of course, it was just the only relevant thing that was found. NodeJS uses those instructions in some procedures (either in codebase or PPC-specific patches), and I am looking to fixing it finally for 32-bit. On Jul 16, 2023 02:39 +0800, Fred Wright , wrote: > > On Sat, 15 Jul 2023, Sergey Fedorov wrote: > > > Is there an implementation to replace these on ppc32? > > > > There is some Linux version online which I found: > > https://patchwork.kernel.org/project/kvm/patch/1403472217-22263-30-git-send-email-ag...@suse.de/ > > But since it is a magic code, no idea if it is portable or not. > > You'd have to be more specific about the intended context. AFAIK, > OSX/macOS didn't have anything like KVM until 10.10, so this specific > patch wouldn't be relevant. > > Fred Wright
Re: rldicl / rldicr for 32-bit powerpc?
On Sat, 15 Jul 2023, Sergey Fedorov wrote: Is there an implementation to replace these on ppc32? There is some Linux version online which I found: https://patchwork.kernel.org/project/kvm/patch/1403472217-22263-30-git-send-email-ag...@suse.de/ But since it is a magic code, no idea if it is portable or not. You'd have to be more specific about the intended context. AFAIK, OSX/macOS didn't have anything like KVM until 10.10, so this specific patch wouldn't be relevant. Fred Wright
rldicl / rldicr for 32-bit powerpc?
Is there an implementation to replace these on ppc32? There is some Linux version online which I found: https://patchwork.kernel.org/project/kvm/patch/1403472217-22263-30-git-send-email-ag...@suse.de/ But since it is a magic code, no idea if it is portable or not.
