|
We need some fresh competition 
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Complain CARP
and
take part ENTER
for artisan
CARPENTER
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
|
I've been making an NES emulator for the ESP32.
I got it coded, but it's crashing into a reboot loop, and not easily debuggable on that platform.
So I've made a GFX driver for DirectX under Windows.
But in using it I discovered that my header-only library cannot be header-only. So I had to spend hours going through my rather lengthy library making CPP files. This was especially nasty where the truetype was concerned.
So I fire up the driver. It crashes on start. Turns out just getting the dimensions of the drawing surface (m_psurface->GetSize()) was causing my app to crash. Bizarre.
So I dig and I dig, and I find out that GCC is using a different calling convention to return pointers to structures from static member functions than Microsoft does. They're both STDCALL declared but GCC interprets an ambiguous rule about returning structs differently than MS. MS later seems to have clarified by indicating that static members will NOT return pointers in a register. GCC does.
So now, I had to patch a system header file (d2d1.h) to explicitly return the struct pointer from the offending methods.
Anyway, now that my GFX library is now at another major revision because of adding the CPP files to it, but at least I've got it drawing to a window.
What's cool is I can run the same code on Windows as I can on the ESP32 now.
This took me most of the day, and I have no idea how I'm going to redistribute this given the modified system header file.**
**no I can't modify a second file. The interface definitions i had to modify are used all over directX, and other headers include this one, so I was stuck.
Anyway, this was probably the most hardcore coding session I've had in awhile, even though the driver itself is about 100 lines (mostly empty)
Real programmers use butterflies
|
|
|
|
|
I love the progression from “write a simple game”
Pretty cool.
|
|
|
|
|
*sigh*
The NES is running to a point and then crashing, and my debugger isn't tracing the call. It's rendering much of a frame before it crashes, so even though there's no output yet there are signs of life.
I thought it would have been the PPU (graphics processor) because that chip is nasty to emulate.
Nope. I took the PPU out of the circuit and just ran the CPU and the main bus.
It's still crashing in the same place.
This is both good and bad, as I'm familiar with the 6502 so I should be able to find the problem, but also I can't find it yet. Unfortunately, my defensive coding has left me with a problem. It's not supposed to crash, because I'm checking for out of range addresses. But it *is* crashing. So hmmmm.
I really wish GDB wouldn't be crapping itself right here. I've debugged other points of the program fine, and I can set breakpoints. The app isn't even multithreaded (yet).
The whole point of me making the directx driver was so I could 🐘ing debug this stupid thing. It's infuriating that the debugger still isn't working after I spent the better part of the day working toward getting a debugger essentially.
Real programmers use butterflies
|
|
|
|
|
This sounds familiar 
Sometimes it happens to me too. I write a program thinking I covered all possible breakage points and, when I go debug it, it crashes and takes GDB with him. Side effects can be very nasty and naughty  .
From my limited experience, if you are checking for out of range, null and other usual checks, this usually comes down to some uninitialized variable or some math using the wrong variable/operation.
Sometime ago I spent almost one month inserting prints into a somewhat large program because whatever was wrong with it also crashed GDB. The program started fine and after e few iterations (randomly between 100 and 1000 depending on input) bam!
It ended up being both an uninitialized temporary variable and a missing dot (decimal place) in a formula that caused an unsigned int to overflow (to a smaller value than it should), that then caused the result of the next formula to be negative when it shouldn't and cascaded out of control from there. Never found out why that would crash the debugger!
Now I try to have a debug only log that prints/dump non temporary variable state to a binary file on every iteration, just in case.
My advice would be for you to start by double checking variable initializations and formulas for correctness.
Good luck
|
|
|
|
|
I found it, patched it, etc. Uninitialized callback pointers. The thing still doesn't work. It renders a couple of garbage frames and then stops. I can tell it's doing something because the garbage is patterned with NES sprites. At least that's progress,
Real programmers use butterflies
|
|
|
|
|
It seems your "cannot be header-only" problem was similar to a previous of my own I had a number of headers thirty-one to be precise Most contained templates Some did not They all relied on others from the same group The dependency #include order problem was a nightmare So I made each into separate declaration (.h) template implementation file (.impl.h) and source file (.cpp) as needed The #include order was now reasonably simple as the declarations themselves had few outside references However knowing which headers needed to be #includ'ed into each source file was a tedious affair as I relied on the compiler and linker to inform me One of my several fantasy future projects is to automate the entire process i.e. Write the original headers Press a button Bingo-Presto-Voila All the declaration implementation and source files are generated and the proper needed #include's in the correct order also magically inserted into the sources I am surprised such a tool does not exist I would happily pay a pretty penny for it as doing so would have transformed an unpleasant several week affair into one micro-second Besides the order nightmare the other motivation was to obtain fast builds What was previously an hour is now five minutes as the code now #include's only what is required for each file as informed by the build Previously I merely #include'd everything into everything I do many builds to find/fix build errors - Cheerio
|
|
|
|
|
I'm trying to do something simpler than that, if I can.
The header only approach works with many IoT projects under the Arduino framework, as there's only one cpp file - other than from included libraries which will never include your headers.
However, once you're no longer coding against Arduino, the possibility of having several cpps becomes very real and then you get symbol nightmare.
75% of GFX is templates. The trouble was the 25% that wasn't.
This is what I do now, because it makes Platform IO happy as well as satisfying other build environments:
I use /include and /src for each "project/module" i'm developing. What I mean by that is this.
GFX is a module
NES (my nintendo engine) is a module
The main project that includes both of those is itself, a module.
So it goes
myproject/include
myproject/src
myproject/lib/gfx/include
myproject/lib/gfx/src
myproject/lib/nes/include
myproject/lib/nes/src
for the overarching project "myproject"
Then, and I'm ashamed of this, but it works - I don't use CMake or Make at all (because they don't work with platformIO)
I use vscode's .vscode folder (cpp_properties.json/tasks.json/launch.json) to configure my build.
And then if I'm feeling saucy I write a shell script to run the build.
Make can take a running jump. CMake isn't any better. Besides, it wouldn't matter if I like them, since my toolchain isn't compatible with them.
Real programmers use butterflies
|
|
|
|
|
Several men are in the locker room of a golf club. A mobile phone on a bench rings and a man engages the speaker function and begins to talk. Everyone else in the room stops to listen.
MAN: Hello.
WOMAN: Honey, it's me. Are you at the club?
MAN: Yes.
WOMAN: I'm at the shopping centre now and found this beautiful leather coat. It's only $1000. Is it okay if I buy it?
MAN: Sure, go ahead if you really like it.
WOMAN: I also stopped by the Mercedes dealership and saw the new 2022 model. I really liked it.
MAN: How much?
WOMAN: $198,000.
MAN: Okay, but for that price make sure it comes with all the options.
WOMAN: Great! Oh, and one more thing, the house, the one I wanted last year is back on the market. They're asking $1.9 million.
MAN: Well, then go ahead and make an offer of $1.8m. They will probably take it. If not, go the extra $100,000 if you think it's really a pretty good price.
WOMAN: 'Okay. I'll see you later! I love you so much! You're so generous!
MAN: You're worth it. Bye!
The man hangs up. The other men in the locker room are staring at him in astonishment, with mouths wide open. The man turns and asks, "Anybody knows whose phone this is?"
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
I like it
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
I heard this one years ago, still one of the best jokes I have ever ehard 
|
|
|
|
|
One of our products uses a SmartCard and our supplier recently increased their price by ... a lot. We found another supplier, but our product couldn't read the new cards. This has been on my plate for months. I'd look at it occasionally and not get anywhere. The code was originally written by someone else (now retired) and was full of magic, undocumented numbers.
My boss and I discussed it late last week, and I told him I thought I'd have to do a rewrite to clean up the mess. Probably a couple weeks worth of work, plus another week for my testing, plus another couple of weeks of regression testing. Not a small task.
I finally wrote a small test program to read and dump out the cards just so I could learn what was actually going on. Yesterday afternoon I discovered the problem.
A single byte in one command, two ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) ing characters in the source code, were wrong for the new card. Interestingly, the changed code works correctly with the old cards as well as the new ones.
The word sheepish comes to mind  .
Software Zen: delete this;
|
|
|
|
|
It's not obvious until it is. Happens to everyone, be glad you found it. 
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Sounds like a success to me. You have saved yourself a couple weeks of work, and another few weeks of testing and regression testing!
|
|
|
|
|
Coulda had three weeks on the beach though.
|
|
|
|
|
Yeah, I'm just annoyed at my initial "Chicken Little"[^] reaction.
Software Zen: delete this;
|
|
|
|
|
Any time you delve into a codebase full of magic numbers and other completely odd idiosyncrasies, a chicken little response is appropriate.
|
|
|
|
|
That reminds me of the time I had to implement a simple system for writing magnetic cards for a security system. I was handed a reader/writer, the manual, and a few cards.
I implemented it in DCL  . I pity tha fool who had to maintain it.
|
|
|
|
|
DCL = Digital Command Language, from VAX/VMS?
I used that a lot back in the day...
Software Zen: delete this;
|
|
|
|
|
Yes. My education and early career (1983 - 2002) were all on DEC systems.
I have four OpenVMS systems here.
|
|
|
|
|
I was a developer on and the system manager for a number of VAXen in the mid-to-late 1980's, most at our local Air Force Base.
I think my worst abuse of DCL was when I wrote a preprocessor for VAX FORTRAN in DCL that reduced it to FORTRAN-77 syntax with some generated code. Good times.
Software Zen: delete this;
|
|
|
|
|
Yeah, I developered, managered, and operatored a variety of VAX and Alpha systems, in education, manufacturing, transportation, and communication fields. So many employers trusted me with full privileges, the fools.
Mostly writing in C, often accessing databases.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
