-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Debug-Experience and Readability #5
Conversation
Looks like this is one of your first PRs? Many open source maintainers prefer one PR per change, rather than mashing up five different things like this; merges are all or nothing, even if the maintainer would rather merge only some of those things. Another common beginner mistake: most maintainers don't like large formatting changes, they make it harder to see what commit changes what. Code style is also a lot more subjective than most other parts of programming, your preferences don't necessarily match the maintainers'. The usual solution is leaving it alone until something else is changed nearby. Personally I don't care too much, but other projects may be crankier. I don't have VSCode here, so I can't really test it, I'll just trust the .vscode files work. Except one thing:
Let's keep this repo in English, okay?
make.sh is supposed to create a highly optimized binary (and, judging by the mv flips ~/bin/flips, it's not really designed to work for anyone other than me - but I'm fine with removing that specific line). The unoptimized build is better created with 'make' or 'make CFLAGS=-g', I'd rather not break that. Though I'll agree it's a bit unclear.
Is there ever any reason to rename the binary? If no, configurability that nobody uses isn't really useful. Also nobody except Microsoft calls binaries 'assembly'.
Having the binary in the root directory feels more convenient to me. Also inconsistent quoting style.
Hey, I didn't know that exists. Neat. Getting those temp files out of the repo root is indeed an improvement. Though I'm not sure why the path should be configurable. A hardcoded obj/ is perfectly sufficient.
Asterisk at the name is a fairly common coding style, but I prefer it this way.
The intention is that the read8s should line up. Mine does if tab width is 2, yours requires 4. Should be spaces, they work for everyone.
Those macros are such a mess... I should've made some kind of binary stream object, except I originally wrote this thing in C where macros are easier than objects. I only switched to C++ long after I wrote that file. The ips_apply/study distinction is completely useless as well.
That looks fairly silly, but the original isn't very good either. The correct fix would be returning an error somewhere. Preferably from ips_study, instead of setting that 'scrambled' flag.
The comment block above is less tied to the other comments than they are to each other, so I prefer making that clear by having that extra linebreak.
Good idea, but if the source file is above 16MB and the target is exactly 16MB, I suspect it'll emit an instruction to truncate to 0 bytes. Better add
Inflating the line count too much harms readability more than it helps.
I'm not sure if you ran an autoformatter here or are trying to make some weird argument about my line length, but having the comments so far from the code looks pretty silly. Better add a linebreak or two in the memcmp arguments. Nontrivial PRs often get a few rounds of comments before they're merged, it's nothing unusual. Do you want me to implement most of those comments (everything except VSCode, I don't know German, and while I can guess how to make it use makefile, I can't test it), do you want to do it yourself, or do you think I'm misjudging something? |
You're totally right - this, honestly, is the first time I'm collborating using git in any way - 'til now I've been coding solo :') + // Verwendet IntelliSense zum Ermitteln möglicher Attribute. I really haven't noticed the auto-generated files contain German comments this can be fixed in just a second.
Currently I'm adding either +if [ "${MODE}" = "Debug" ]; then
+ FLAGS+=' -O0 -g'
+elif [ "${MODE}" = "Release" ]; then
+ FLAGS+=' -O3'
+fi Is there some smoother way to do that?
You sure have noticed I'm a clicky-bounty-Microsoft user - changes made to the Of course these superfluous variables can be replaced.
Looks like I messed up my editor settings - usually I have my identation set to 4 spaces instead of tab.
Understood! It's because in that case the length of the target is added to the end of the patch, right?
Point for you! Yeah - honestly I first ran an autoformatter over while (offset<sourcelen && (offset<sourcelen?source[offset]:0)==target[offset]) offset++;
I honestly don't know what comments you mean, I'm sorry 😅
Well it's actually pretty easy since I've created all configuration-files that are required.
Don't you worry, I won't get you wrong. It's real cool you're having a look at the changes I've made and you consider implementing them ^^ |
How the hell could that happen though!?
As I said, better leave make.sh alone for debug builds, it's highly tuned for optimization. All the -f in FLAGS are various optimizations; compiling twice with profile.sh in between is profiling, which is an optimization. Better call 'make' or 'make CFLAGS=-g' directly from VSCode for debug.
I prefer tab for indentation and space for alignment. Not sure how many IDEs support that.
Yes, IPSes end with the target size if the source is bigger. But we still need the 'target >= 0x01000001' check, IPS can't write beyond 16MB even if the target is bigger. While it's theoretically possible to emit a 64K-1 block of mostly unchanged data starting at 16M-1, allowing the target to be 16M+64K-2 bytes, Flips doesn't support creating such patches, it prefers you switch to BPS. And even if it was supported, 16M+64K-2 bytes is still a limit that should be checked for. (Feel free to implement that in your patcher and claim you have a feature I don't.) Not sure if Flips supports applying such a patch, either. It should, but it's untested and may be buggy.
Ah, so that's what you're doing. Yeah, then linebreaks make sense. Personally I do much of my debugging by spamming print statements all over, but making things easy for gdb is a valid concern. I'll try to limit oneliner if statements in my other projects.
My complaints in my prior comment. Someone has to fix them, your choice which of us.
That'd work if I had VSCode installed, but I don't, and I hate installing stuff if I'm not going to use it a lot. I'll just trust that you've tested them properly. |
I just fixed the indentation and the code-design itself - I think it should be right the way you want it to be like.
Okay - I've done that now in b44b4f0 and 7e0b310.
I just tried to adjust the size-restriction until I realized it'd cause bugs if a part after
To be honest this is the very first C/CPP-project I'm working on - I wouldn't even know how to print stuff to the debug-console 😂
Alright - I just fixed this in 63781b4. The auto-generated comments are now in English.
Alright - just tested it and it's working just fine! |
This PR is starting to get fairly messy. Looks good to me. I'm not completely sure if that one passes the variables you made the makefile expect, but that's better fixed in the makefile. Let's not make VSCode the only way to build Flips. (I think VSCode can call Makefiles without going via the shell, but that doesn't make any real difference.)
Yeah, that looks good.
Print spam debugging, also known as printf debugging, is a common technique in almost all languages. It works just as well in C# as C++. These parts of the PR are definitely improvements:
These improve some things, but worsen others, and as far as I can see, the sum is negative; unless you feel I'm wrong (perhaps I am), they should be reverted:
These could be improved, but are suboptimal in the current version too, I won't expect you to fix them (but you may if you want to):
Once the middle list is empty, I'll merge this and fix whatever remains in the third list. |
Aite - I think I patched everything...? |
oh right, I forgot this one. All those reversions/etc make it hard to merge, so I copypasted the good parts. Did I miss anything? |
No answer, I'll just assume everything is fine. |
This PR provides the functionality to basically debug the project, especially using Visual Studio Code, and improves the readability of libips.cpp.
I've done this while having a look at your code in order to learn more about your algorithm and for using it in my own project.
Thanks again for your great help - that's awesome, dude 😄