Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
neon wrote:General advice on debugging... Sometimes it can be helpful to write out and walk through a higher level logic flow of what you want the code to do. This can be writing pseudo code and literally reasoning to yourself by walking through it while feeding in different scenarios.
If there's one bit of programming advice I've heard almost completely consistently from my first computer in 1983 all the way to the present, it's this. In the days of line-number BASIC and assembly language, we weren't advised to do this, we were TOLD; even by hobbyist magazines. (I still don't do it very often. ) It was flowcharts rather than pseudocode in those days, but pseudocode may be better in practice. The other thing we were told to do was "dry run" programs; basically the same thing, but with the actual code. (I do this most of the time.)
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
To print out a newline, all you do is check if the current character is an LF, and then increment row, set column to zero, and then return without printing. It's that simple!
Btw, may be unrelated, but @neon, I can't access your source repo in sour signature. How come that is?
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg
It was flowcharts rather than pseudocode in those days
Any sufficiently complicated topic I find it easier to try to visualize and walk through it away from any computer: this also applies to figuring out algorithms (*coughs* recursive paging.) So I figure perhaps write psuedo code if you feel comfortable with an understanding of the basic high level steps, just have to figure out the details; if that does not work out or you don't know the basic high level steps, stepping away from the computer--taking a break--perhaps even a few days--and when ready begin walking through it visually, graphing it out if needed. I find taking a break alone to be perhaps the most important and ironically the most useful when you get stuck. Now if we can only convince bosses that...
Btw, may be unrelated, but @neon, I can't access your source repo in sour signature. How come that is?
The repository has been kept private for years. For me its just an ongoing research endeavor. I added it to the signature just 2-3 days ago in case we make it public. I need something to convince me that it can be helpful for others if we do decide to open it. I find myself going back and fourth between wanting to keep it private or open it up for anyone interested. An argument to open it to the public is that -- regardless, it would be more helpful opened then closed anyways -- even if just for ideas. An argument for keeping it closed is that -- helpful is subjective; ideas without knowing the reasoning behind the why can be detrimental. A few days ago I considered that there was a few areas of interest that might be interesting for ideas -- hence why I added the link and started debating.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
neon wrote:Any sufficiently complicated topic I find it easier to try to visualize and walk through it away from any computer
Maybe that's what I'm doing wrong. I hardly know where my pencils and paper are these days.
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
) It was flowcharts rather than pseudocode in those days, but pseudocode may be better in practice. The other thing we were told to do was "dry run" programs; basically the same thing, but with the actual code. (I do this most of the time.)
I hardly know where my pencils and paper are these days.