|
|
David O'Neil wrote: Personal fave of theirs: Alan Parsons Project - Lucifer.
Love this one too!
Also on my parent's best of album 
David O'Neil wrote: PS - Here's a good New Wave collection: THE BEST NEW WAVE COLLECTION
REALLY!? THE ENGLISH VERSION OF NENA!? 
|
|
|
|
|
|
|
You might like Apocalyptica: Apocalyptica - One (Plays Metallica By Four Cellos - A Live Performance) - YouTube[^]
Basically a metal band consisting of four cellists.
Started out by covering Metallica, but they've made their own songs since their second album (and since added drums and sometimes even vocals) and grew out to be one of the more popular metal bands of today.
0x01AA wrote: and the old one
I'll take this one 
|
|
|
|
|
|
Not a fan of either.
TX6430 wrote: anything from AC/DC
A coworker used to sing Thunderstruck, but said "Sander!" instead of "Thunder!".
I thought he was just saying my name for some reason, took me months to figure out he was singing AC/DC 
|
|
|
|
|
Stupid cloud infrastructure, may a thousand elephants do their doo doos at your door. 
We haz a simple set up, SQL Server db, asp.net [5ish] server and a react Dog's Dangles front end.
We use Azure pipelines to build and deploy on Azure, where else, and all is good in the world. Each pr to main kicks off the build. 98.3% of builds are good; the others are mine.
As of Wednesday, builds go boom. All builds.
Even rebuilding previously working build go boom-boom.
Vilmos is sad; see the sad face -> 
We found the problem quickly - the version of npm has ticked over and no longer does the automagic duplicate dependencies to keep it creaking along.
I have now spent two days going through all the packages and (a) deleting the ones that are not referenced and (b) resolving dependency conflicts which required some code changes we weren't planning.
Yesterday's prod push is dead in the water and sure as heck there won't be one today.
That's it, that's the rant. Now get on with the CCC; I think the answer is LIQUID NITROGEN
veni bibi saltavi
|
|
|
|
|
Nagy Vilmos wrote: Now get on with the CCC; I think the answer is LIQUID NITROGEN
Too many letters!
Go on, push today: 16:59 on a Friday is always a good day to push to production. What could possibly go wrong?*
* Provided your mobile is de-batteryed and the land-line unplugged.
"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!
|
|
|
|
|
Finally, got the build to build in Azure and create the artifacts.
Three.
Days.
![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
veni bibi saltavi
|
|
|
|
|
|
Paid and grey
veni bibi saltavi
|
|
|
|
|
Complain and take part for artisan (9)
"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
|
|
|
|
|
Tick.
Tock.
Tick.
Tock.
"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!
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
