Si fuera tu, cobraria U.S. $50,000 nada mas por la molestia y el tiempo tan reducido, pero si tu producto es para una empresa mexicana, no veo porque no mejor les cobras US$10,000 (o unos solidos MX$200,000). Digo les estas dando el codigo fuente, no es usual, y es muchisimo trabajo para un mes y para un solo individuo.

I think you meant a SCSI cable (it was the USB of its day on desktops and high end workstations)

I actually now use the calculator in my iPhone (if I have to, I do a lot more mental math, especially converting Fahrenheit to Celsius). Funny though, long before I hacked my Sony PSP to learn videogame console programming, I learned to program portable devices with my TX-89...those were the days.

I turned this thing off as soon as I discovered it. It keeps the damn kernel resident in memory and turns your ram into a sort of NVRAM (at the cost of your battery). I don't care how long it takes to boot, a desktop or laptop computer must be as dead as your great-great-great grandmother when you shutdown. The one exception being the system clock (as always) and maybe a signal monitor on your NC for remote bootup (those things are tricky to get working right) It just ain't right...almost contra natura :laugh:

You know I kinda thought we Videogame developers shot ourselves in the foot with the commercialization (and then opensourcing) of powerful game engines...back in 2012. 10 years later I've only seen script kiddies think they're programmers and very lame games come to market. I'm not saying all future Shigeru Miyamoto's have to have intimate knowledge of the bare metal, but it does help to know what sinful fun you can get away with making. I have to conclude that people who love getting their hands dirty and can fix what they created...will always be the gods the computer world pray to whilst they live. A.I. replacing genius, in my lifetime, is little more than a funny joke.

Uniformity in code is simply for facilitating skimming through it. I think they call it K&R convention when you follow the function header with a newline and then a bracket '{'? Anyways I didn't before and I reformed. That and another convention about never going past 80 columns in any line so you never have to use the horizontal scroll bar (and something else, I think the ol' camel case thing) But to this day all my quick and dirty functions or variables start with my initials. I clean it up later to make it less personal (especially the really dirty names). But it almost seems religious for most C/C++ programmers that we continue to use as much short hand in our naming conventions as possible (nobody wants carpal tunnel syndrome, especially if you have to quickly debug in 'vi')

Sometimes the best coding dramas are written in the comments. (aside from some funny jokes) But sometimes a good laugh is the best way to make people remember the oddities of certain hacks or unusual algorithms. If I ever see Windows ME's source code, I'd expect to see shitfaced comments all over the people (evidence of Balmer's Peak)

Maybe I'm understanding something wrong. But to your questions:

Quote:

Or does it require the wheels to be in contact with the ground for the thrust to be nulled out?

If I am to understand correctly, the wheels spin because of the thrust of the turbines. There's no other transmission system attached to them so their speed is directly proportional to the turbines action of moving the plane forward. The conveyer built is moving backwards at that same speed, but turbine and conveyer belt are playing a tug of war as to which direction the plane should be moving.

Quote:

Assume that the wheels for some reason started spinning mid-air, would this cancel the thrust from the turbines as well, so the plane crashes?

No, wheels in the air are negligible, but I do think they do spin anyway at take off speed (unless there's some kind of brake to make them stop vibrating and fold gently into the body)

Quote:

Or are you suggesting that the thrust from the turbines are nulled out because the free running wheels are spinning around? What are the mechanism behind this canceling?

No, as in the first answer, the wheels simply provide a means (a medium) for the turbine to move the plane while on the ground. The only thing cancelling the thrust is the conveyer belt itself, using some sort of smart engine that compensates for the force of thrust (for this experiment the plane itself transmits said variable to the tarmac/conveyer belt) I could be imagining things wrong but in your scenario:

Quote:

If the conveyor belt is running at takeoff speed before the engines are started, then you fire up the engines and zip down the runway (/conveyor belt), when the plane lifts off the ground the wheels is spinning at twice the takeoff speed (unless the conveyor belt has been slowed down as the plane accelerates, to maintain the 'wheels spinning at takeoff speed).

The plane already has some thrust in order to taxi itself onto the conveyer belt. This belt is already moving at an incredible speed, backwards, with no weight. The plane would immediately be dragged in the wrong direction the moment the front wheel slips unto the belt (and probably spin and crash). Say it managed to taxi onto the already rapidly moving belt, without achieving take off speed, the belt would just yank it backwards into whate

Well if I understood correctly, the conveyer belt is meant to match the speed of the wheels even at full engine thrust. I Don't know if the wheels have a speed threshold with all that weight, one would imagine the rubber does have it's limits (heck I even bet the conveyer belt would buckle long before the jet engines go to full power) Realistically I can only imagine the most catastrophic take off (I think the wheels would be useless for landing and the huge conveyer belt tarmac, broken and in tatters). Nonetheless I would have to agree with you. But referring the original (very hypothetical) question:

Quote:

If an airplane is positioned on a conveyor belt as wide as a runway, and this conveyor belt is designed to exactly match the speed of the wheels, but moving in the opposite direction, ... Can the airplane take off?

Barring the unlikely existence of such a conveyer belt and matching powerful set of wheels, I would still say it doesn't take off. Unless convinced otherwise, it's the volume of the air flowing under the wings that matter, not the volume of air flowing through the turbines.

Could be my view is too simplistic but I imagine a plane sort of like a submarine, needing to be buoyant in much lighter fluids (air). For this to happen you need quite a volume of air flowing under the wings as opposed to over it, giving it 'lift'. Having no significant flow of air while basically staying in one place, I think, is not gonna help. Maybe you'd need a vertical vortex?

Those were the days...then I got a cold shower when I tried to revive an SGI O2...PROMs. Firmwares, bootloaders... Then I achieved Nirvana when I realized the games I compiled for the Nintendo DSi were compiled with the OS in them (Or rather the game was the operating system)

130Mb? This had better be a VR version (Maybe I'd expect 130Kb, but even then you wonder wtf is inflating it)

Lol For the time it was written it was most certainly a hack. That portion was still in C++ 98 and the pointer redirection was for a scripting language internal to the engine (to directly call any method from any class in the engine) SPI bus code...you reminded me of assembler code I found in our main Nintendo DSi Engine (we called coldbits) to directly write to the buffer of the image processor. It was not child's play but I don't think the use of the keyword asm in C++ is hackish (more like "Here be dragons" kinda warning)

Well I think all midway languages (which to me is any compiled language between FORTRAN's readability and Assembler) is that readability will always be second to performance...although that should mean that a proportional amount of comments should be added to the code (at least a full page for the dark arts). Some of the coolest code I've seen uses pointer arithmetic like hell to bypass C++ permissions (this was a videogame engine) and the only comment it had was:

/* Do not change this code or ponies will cry */

I had been tracing the source code through 7 different files when I was rewarded with a hearty laugh there. I don't know how readable it was to any other person, but since then, I knew that game engines, compilers and O.S. source code is never going to be readily accessible to just anyone (Despite our best comments). That is the nature of language, human, computer or otherwise.

I like waterfall so any last minute changes are things that will take 2 more years to add to the project. Then again clients don't exist in my line of work. :)

Well I'm not a superstitious man but I do have a lot of fun playing on them. I tell everyone that I got myself the "iPhone Cursed" (v. 13) and I'm just waiting to see what great bug is going to make it a self-fulfilling propechy :laugh:

Maybe or maybe even before... xkcd: Ballmer Peak[^]

oh my. These look like prime candidates for deletion. if the rest of the code depends on it, you might be dealing with a prime application for abortion. :laugh:

For this reason alone (just kidding, I love games) I went to videogame programming. No interaction with clients and nobody dies. But coming of age I've become more stoic about it. Civil and aeronautic engineers have a hell of a lot more lives on their shoulders...and they seem to shrug off the what ifs pretty well.

If one word equates to a single line in C... "free(allPeoplesUselessWorries);"