3,794 karma · joined April 29, 2015
[0]: http://github.com/buserror/simavr [1]: https://github.com/buserror/simavr/blob/master/doc/simavr_ca...
Demo is in C, but it shouldnt be too hard to add bindings for other languages.
This is very fresh paint, it had a demo of "one" in one of my other program, so I do expect the odd issue!
I bought GraphicConverter [1] a zillion years ago, and I just upgraded to their v11, and so I paid them probably more than I've ever paid any other software -- BUT, they always come up with a list of improvement 5 pages long, and I've been using that stuff on/off for 20+ years.
I have no problems pushing money their way, I know where that money is going ultimately. It certainly doesn't go in shareholder or marketing drone's pocket.
However, any 'new' customer will not let themselves be trapped. It's happening with Adobe Photoshop and stuff, where they've been skinning their customer base for years, but quite frankly who would now as a new potiential customer decide to shackle themselves to that? I know quite a few people who will use inferior tools JUST so they don't have to hook up to Adobe blood-suck.
Say Adobe Lightroom. Super product, but updates started to slow down and slow down and WOW now look it's all ONLINE baby for a price. I bought all updates until LR6, but now I know it's a lot cheaper to archive my machine with LR6 in a corner and use it for my photo edit than switching to the 'super value online thingy' for $$$/year. I don't use it that much to want that, and next time I want to use it, it actually might be incompatible with /whatever is in my chain of hardware/ anyway.
I'm sad to say Sketchup is doing this, if they had a $100 upgrade price every year or so, I'd pay happily -- however here's lies the other main problem: these companies don't WANT to invest in R&D enough to have a 'valid' reason to have a new major version every 12-18 months, they actually think people will just keep paying.
Well guess what, perhaps some people will, but no NEW people will. In the case of sketchup, whatever the marketing blurbs have spattered about, NOTHING IS NEW for like 10 years, I mean, they try to add 'hooks' here and there, but the main program is exactly the same, same bugs for that long. I suspect the devs who know how to do matrix multiplication have long left after google dumped the product, and they are now left with a handful of webheads.
Do I want to pay for that?
Hmm wait until I clean the coffee off the front my t-shirt.
I wrote applications that were shipped on millions of computers in the 90s and I didn't have to make hard choices for building, the debug version were quicker to build sure, but the Release versions weren't a chore to make, and I was often building PPC/68k/debug/release in one go.
Also, this is a ridiculous defence of autoshit stuff. It hasn't been needed for well over 20 years, it's only purpose is self propagation where "oh I need autoconf blah because otherwise I can't build everywhere" where there is so much standardisation these days that there are MOSTLY TWO choices for nix systems. Not only that but it fails* all the time, on embedded for example; it doesn't 'save' and give you portability, it just gives you a false assurance that you are doing 'the right thing' by using it, while it's broken is many other ways.
More often than not, you can replace all that garbage with a 1/2 page Makefile. Who the hell needs to check wether the compiler /works/ or strdup /exists/ and all that idiocy. Or add dependencies for stuff while 'pkg-config' exists anyway. Who the hell actually /needs/ 'libtool' when there's about (perhaps) 3 ways of making a shared library on a unix system? And who the hell want or have the time to go and debug some stupid arcane 'm4' file to fix the weird problems that comes up?
Disclaimer: I build embedded distros for fun and profit, I deal with that stuff /all the time/ and most of my 'compile time' for distros is not even spent actually 'compiling' stuff, it's spent in the 'configure' stage, and 90% of my time fixing portability problem isn't in the code, it's in the autoshit stuff that somehow breaks in some new, interesting way.
Whatever people will say, I still miss these "one pass" compilers, they were amazing and peaked with CodeWarrior, the best development suite, ever, in my nearly 40 years experience.
Nowadays we see autoshit "configure" stuff and compilers like gcc (some) or clang (oh my frigging GOD!!) trawl their way slowly and painfully thru the most simple projects without even support for plain basic stuff like automatic precompiled headers.
Wow look, we've NEARLY got Link Time Optimization working (took decades), in 2020 whoohoo, I'm so delighted. I could compile hundred of thousands of lines of light C++ or (better) plain C 25 years ago on a much, MUCH slower machine, with an simple editor that used the compiler lexer output so you had highlighting, real indexing it was 'just there' and always right, and always blinding fast.
I'm pretty sure we are way worse than we were 20 years ago for tooling. I'm sure some people will disagree, these people haven't seen CodeWarrior chew thru hundreds and hundreds of files in seconds.
I really wish it worked as I like the lean&mean&precise approach they've been using!
Guess what? I never bought a smartwatch, instead, I bought a whole collection of real watches, some vintage, some modern, some expensive, some cheapos and I love accessorising with them. Must have 20 of them by now.
The "crown" of my collection is a Bulova Spaceview in 18K gold. It's the nerd's nerd watch, it has A TRANSISTOR in it, a resonator, it 'humes' a 360hz faint hum, and was made in 1964 before Quartz was invented; that movement was onboard the Apollo missions. And that watch has no 'face' so all you see is the innards with the tuning fork in the middle, and a pair of tiny coils around it. </orgasm>
it's really a GREAT way to enjoy R/C flying. No motor (some glider have fold out props that can be handy tho) and you can fly for HOURS using just the lift from the slope, it's amazing to try to 'park' the glider alongside you and try to keep it motionless, it's as close to anti-gravity as I'll ever taste!
Also, buy 3M tape, gorilla glue, and have your repair kit handy at the back of the car for the times where the wind is a little bit too fierce for your reflexes :-)
If you want a bit of a taster, download "Picasim" for your phone/tablet, it's really really good for training. No affiliation, just a very nice sim for the "sport".
Right after the shower, you'll get super warm, even in winter. You're system just gets going to equalise your temperature.
Also, you'll be woken up no dithering about in a stupor until your coffee kicks in, it definitely gives you a kick in the backside to get going, so even just for that, it's worth it in my opinion.
And, I never get cold. I can work outside in a t-shirt in winter (UK winter) without feeling any cold.
Just leave the brain do it's job, don't read as it's a marathon, take breaks, think about that bits you've just read that was interesting, then promptly forget about it. You'll forget the details, but not the backbone of it.
Details don't matter in the end. Quite frankly the idea of knowing /by heart/ the name of the greek goddess blah blah blah he uses as an example would bore me solid. Worse, anyone knowing it and telling me about it would bore me solid :-)
(never fails to amuse me)
Picking up an arduino and 'waste' a couple of days making LED blink can be fantastically relaxing too.
I don't know if any of these suggestions will help, but perhaps you should pick up a hobby, something that is not too taxing and is still rewarding. It can but doesn't have to be tech related either. For me it was Photography, and I do a lot of landscape photography to this day -- but it could be anything, perhaps these days I would pick Archery (field archery is a super way to 'zen' out).
The idea is to get back the feeling of doing something you enjoy, and it doesn't requires weeks of setup or zillions of hours of practice to enjoy yourself.
If your company is cool with it, perhaps negotiate a 4 day week, and take that one day for yourself to really unwind. Don't stare at the TV tho, so the thing you enjoy, and go out and do it.
But ultimately, what I suggest is that in the future you watch over your work/life balance. Take care of yourself!
Sometimes I see <xxx> has died and it's clearly technology related, and I will click the link, and discover that this person was great even if I never knew their names, and I feel enriched.
I certainly wouldn't feel enriched being led to a basketball website.
I think this article is very, very simplistic. All of it relates to a 8 bits CPU that is 40+ years old.
I switched to HLL as soon as I could get my hand on a compiler, namely, UCSD Pascal at the time! Then the Pascal, then to C and then myriads of other languages. I covered 6502, Z80, 68k (all of them, to 68040), PowerPC (all of them from 601 prototypes to G5s), ARMs (more than I can count) and x86s (same).
True to be told, the assembly language I started with /helped a LOT/ with be becoming an efficient developer; a developer who understand what 'code' is being generated when he writes an expression, a statement, a loop, and one who understands what the runtime implication are for most of the 'sugar coating' HLL gives.
However, starting (a bit) with the 68k, then even more so with the PowerPC, it became pretty much impossible to write /from scratch/ an assembly equivalent that was QUICKER than the compiler generated code. That was 20+ years ago. DRAM latency happened, pipelining happened and SIMD happened.
Today, hand writing assembly is pretty much stupid on modern CPUs. Given the register files, timings, shadow registers, bus latencies etc etc the compiler will ALWAYS be better because there is so much criteria to think about when generating code...
I'm not saying that having the knowledge is not useful; the best use of assembly is to write some code il HLL, one that is supposed to be super-mega-critical-quick, then disassemble it and see how it looks. More often then not, you can't make it better than it is in situ -- most of the time you will gain is to prepare your data better, align it better etc etc -- basically, 'hinting' the compiler to do a better job. You can do serious code butchery like that, without a hint of assembler [0].
But really, I haven't written any assembly for /performance reasons/ in 15 years, and that was Altivec on PowerPC.
For 8 bits, it's all smooth as butter, but the article also doesn't take into account the massive progress in compilers; I'm the author of SimAVR [1] and I've seen my load of generated code for that CPU, and the GCC toolchain is /very hard to beat/ by hand these days.
[0]: critical audio loop on one of my old PCI card driver, converting float<->int, applying gain etc while using the register file to the max, and making most use of the pipelining of the G4 (at the time) https://gist.github.com/buserror/0a3a69cca927b8da6c9c7ee1605... -- note, the inner loop was generated by a script that was doing the cycle calculations (!)
No need to respond to the rest of your post, as you didn't bother reading mine anyway. Go back to hunting stationary target with 50mm rounds, it's perfect, you'll never find the carcass anyway.
Also, one of the biggest improvement in hunting cartridges are the 'wads' which used to be plastic, and now are wool or fiber, in any case, biodegradable -- the steel cartridges don't have these as they need a 'cup' to protect the barrels as the shots go out, so you leave big pieces of plastic all over, to be ingested by /other/ wildlife, potentially.
So no real perfect solutions so far; Legally you can't shoot lead anywhere near waterways so we have to use steel, but for example last year I shot a duck, fair an square, nowhere near "out of range" -- this was a 'dead duck' -- we looked for it for 20 minutes to discover it had gone to ground and was NOT dead, it had been broadsided, but some pellets had gone thru the poor bird, and some of the pellets were in the feathers, because they didn't have the energy.
As much as I like hunting my supper -- and I hunt to fill the freezer so I don't ever have to buy chickens -- I really hate to be in that situation where I inflicted undue pain for no reason other than some city environmentalist (who probably sit at his desk all day) making wide ranging decisions like this.
It's going to be difficult to find a metal as "good" as this job as lead; I would love for steel to work really, perhaps we could somehow devise a 'steel shell around a lead pellet' -- that would allow 1) killing power 2) protection for lead leakage and 3) loads of time to use magnets to recover it from pretty much anywhere... I realise a good part of the energy of lead hitting a target it when it splatters, and the steel shot won't do that, but it ought to be better...?
Anyway, that evening we had duck, and we toasted the duck; unsuitable apology as it is.
So I'm a bit 'branded' -- mind you, I still stopped developing for Mac a long while back now. At the time when the company tech was made by bearded cool people for Doctors and Lawyers to the time the company tech is made by Doctors and Lawyers for bearded 'cool people' with a latte :-)
It was the time when Apple APIs went completely overboard in the amount of code required to do /anything/; OpenDoc was incredible in it's complexity; but even something like OpenTransport was fantastic amount of work to do anything simple -- especially compared to BSD sockets!
AppleScript was another one, being 'scriptable' was a lot of work, but being 'recordable' was a complete nightmare, and implementing the most complex language clauses was borderline suicide, the 'whose' clauses were amazing in their complexity for a feature absolutely nobody would use.
But, still, I miss Classic -- I think there was a lot of good that was thrown with the bath water when OSX arrived; sure, the underlying got a serious upgrade, but the user interface and anything associated got a serious downgrade, to this day really. I think the modern Finder is abhorrent, the Classic Finder was a beauty of consistency and ease of use in comparison. Yeah sure you got a couple of gadgets, that's it.
I always thought that the 'creator codes' and other use of that four character sequence system was a great feature. It was gradually lost with osx.
Fun fact: All compilers for Mac had language extensions to deal with four character sequences, like 'AbCd' in C would be an integer with ('A'<<24)|('b'<<16)|('C'<<8)|'d'. Beats 0xdeadbeef and 0xcafef00d!
It's mostly bash. And a bit of C for tools. Works on ARM, whatever really, as long as there is a kernel and a toolchain.