On Thu, Mar 14, 2024 at 11:35:15PM +0100, Olliver Schinagl wrote: > On 14-03-2024 01:50, Elliott Mitchell wrote: > > On Wed, Mar 13, 2024 at 09:43:06AM +0100, Olliver Schinagl wrote: > >> > >> The actual code of course has nothing to do with the perl script, as you > >> right full say 'I know nothing of perl', as does probably most of the > >> development community by now. Which is sad for perl, but 'it is what it > >> is'. > >> > >> In no way was there any ill intent. I just wanted my kernel tree bump > >> for the realtek target, and didn't want to install, learn etc perl to > >> try things out. Sorry for that on my part. > > > > The real problem here is you made two critical errors in your handling > > of this. > > But we're only talking textual strings, English language. Maybe I came > up with nearly similar sounding things because a) English is not my > native language and b) I've seen this before 'somewhere on the internet. > So re-using your 'code' is a bit of a stretch. Or are you suggesting I > am plagarizing everybody with these words I am writing right here? They > where all used too. ChatGPT could have been used. Your code in itself, I > didn't use, or look at really.
The fact that the same goof appeared in both is strongly suggestive it was copied, rather than being manually typed in. True, could be were both thinking `git rebase` when it was typed, but it is very suspicious. Those messages aren't that large of a portion of the script. Whereas the harm done by getting the script in quickly is quite large. > > The biggest difference between the two isn't the language choice, but > > the overall designs. Your shell script is essentially replicating the > > actions a human at a shell might take to perform the task (more or less > > precisely the actions suggested by the original source). As such you > > likely recognize all the commands used in the script. > > And that is exactly the point. Human's have to read the script, humans > have to understand the script. Readability (in this case, more on this > later) is the biggest and most crucial part, as readability (by humans) > goes nearly hand-in-hand with maintainability. Whereas due to better design, mine will likely last rather longer before needing maintenance. > > The real reason everyone was having a hard time understanding my script > > was not that it was written in Perl. > Yes it was :p perl syntax is godawful :) and adds a layer of complexity > around, what in the end are, shell commands. And that's the partial also > a problem in my opinion. Many people do not know perl, readability > becomes an issue, and thus also maintainability. Yes, someone can argue > the same for shell scripts and its tricky syntax hacks. Though I pride > myself (and thank shellcheck a lot) for attempting to write as readabile > scripts as possible. Perl heavily copies features and capabilities from shell scripting, but Perl itself is not a shell-scripting language. If you're thinking of it as shell-scripting then, yes it will be confusing. Further it really does have some major quirks. At least it didn't fundamentally change the language and library between v2 and v3... > > Since `git fast-import` is a direct interface to Git's back-end, the > > working tree doesn't need to be modified to operate. This also means > > mine is *much* faster and can create precisely tailored commits. > Ah, but! ... here I go drudging about maintainabiility again. Others in > the future will also look at it and go like 'hmm, what is this for, and > why the complexity' ... Anyone needing to figure out how the scripts work will need a fair bit of familiarity with Git. Being able to get good results really does need some deep familiarity with Git's structures, at which point `git fast-import` isn't a big step further. > > I had been estimating the shell script would be 2-4 orders of > > magnitude slower than my Perl script. I now see the flaw in this belief. > > I had been operating on the assumption the shell script was doing a > > roughly comparable job to the Perl script. Turns out the shell script > > *strictly* targets the kernel configuration files. Whereas the Perl > > script targets *all* kernel-related files. > > If I/we took an oversight, due share. But the script looks at any file > (or directory) that has the kernel version suffix. If you look at the > realtek tree, you'll config files, but also all the other usual suspects > and also some hidden in some subdirectories. So what 'all' files are you > referring too that are not part of this pattern and where overlooked? No, it does not. It looks at "target/linux/<board>/" for anything matching the kernel version. It only looks deeper in the tree for "config-<oldversion>". While presently nothing besides the configuration is deeper in the tree, it isn't at all unlikely for such to be added in the future. > > The patches don't get nearly as much press as the kernel configuration > > files, but they actually have more influence than the configuration. As > > someone who has in fact found bugs in the OpenWRT kernel patches, they > > seem just as valid for this treatment as the configuration. > Are you talking about patches-5.15 etc? The script should be covering > that, I tested it as such. Can you share how/what bug you found? See above. You catch "target/linux/<board>/patches-<oldversion>". It will miss "target/linux/<board>/<device>/patches-<oldversion>". This isn't yet used, but seems entirely likely in the future (or something else "*-<oldversion>"). -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
