You are (probably) not the only person having to deal with the source code. If you're so egoistical that you're making it harder for everyone else by mangling two different things together, I sincerly hope you and I are never working on the same codebase together.
If you look back at my original post, my whole point is that I don't give a flying fuck how people indent their code as as long as don't have to scratch my head to figure out how they liked their tabs. Which is why tabs are annoying.
You're the Nazi here, not me. I have to figure out what your tabs mean. Gee thanks a lot.
Are there really people who get their jollies by changing the tab value to make code look different on their screens
And why should anybody pander to your bizarre fetish?
Use Unix "unexpand" and shove in tabs everywhere you want. Whack off while changing the indents; I don't care. But for the source code I have to deal with, why must I try to figure out what particular tab setting made you orgasm?
If you are truly obsessed with a 7-space indent, then go ahead and use that but don't make me have to try to guess it.
Well maybe that's going to be fixed. Let's see:
>>> from __future__ import braces
File "", line 1
SyntaxError: not a chance
PS: That's real, try it yourself
No, this just means you (and/or the people you work with) are using tabs in the wrong way.
I don't use tabs, so this does not apply to me.
But the main point is, I have seen tons of code over the past 20 years of my coding experience with this problem. The very existence of the Unix "expand" program which converts tabs to spaces per choice is concrete evidence of this.
So, since apparently most everybody uses tabs incorrectly, and there does not seem to be any point at all with using tabs instead of spaces, then why use tabs at all? Are there really people who get their jollies by changing the tab value to make code look different on their screens?
Tab (ascii 9) goes back to typewriters and teletypes and is effectively an 8 indent because terminals and printers and other devices assume it by default. So if you don't want an 8-space indent, don't use a tab. If you do want an 8-space indent, you can't assume the viewers device will treat it that why, so why bother with a tab at all?
Tabs do not work. Don't use them. Consider this, where there's a tab before the "int" and the "//" comment using the 8-space standard and the intent is to get the comments to line up. I'm using "_" instead of spaces to get around slashdot formatting grief:
If you set your editor, printer, viewer, whatever to use 4 space tabs it becomes this:
I for one am sick and tired of having to reverse engineer what some frustrated artistic genius decided to use for their tab offset. Set your editor to expand tabs to spaces to whatever you want and save everyone the grief of trying to figure out what you were trying to do, because I really don't give a damn if you use 2, 3, 4, 6 or 8 space indentation; I just don't want to have to guess my way to making your code line up.
The society which scorns excellence in plumbing as a humble activity and tolerates shoddiness in philosophy because it is an exalted activity will have neither good plumbing nor good philosophy: neither its pipes nor its theories will hold water.
- John W. Garner
So the best thing here is to keep those geosync slots in use, and not chewing up an empty slot with a dead or useless satellite. I'll have to agree with what someone else said - that de-orbit should be a published option, as well.
De-orbiting from geosync is way to expensive to be an option (too high delta-V). What they use instead is the "graveyard orbit". At the end of operational life, the satellite just does some final burns to raise its orbit by a few hundred km, where it is no longer geosynchronous but also out of the way of the geosync orbit. Satellites launched into geosync are required to have this capability.
If you meet a Croat, tell him Tesla was Serbian. If you meet a Serb, tell him Tesla was Croatian. Watch the sparks fly.
(Tesla was born in what is now Croatia, but was ethnically Serbian).
Oh so instead of IN the editor at the same time and it breaks right into the debugger? Or is it a separate step? Oh and do you have the right plugin's? Oh ding 'bad parameters passed in?', oh 'that line caused a memory overwrite', and 'thread race conditions'? Oh and a suggestion on what to fix? Oh and as you are debugging it? Oh I use these tools. Use both for *many* years. Like most linux tools they are 'almost there' but what I call 'scatter brained'.
Properly *configured* valgrind can do very well. But oh the configuration part... Most windows tools you are ready to rock after install. By default does valgrind do what you are talking about? No. Oh you need 4 different command line settings. Then it *starts* to produce useful information. Oh you need this other thing oh you run again and hopefully you have the right plugin.
By default (no arguments, out of the box) valgrind gives a description of the problem and a stack backtrace with the names of the procedures, files and linenumbers. You can tell it to also drop you into the debugger of your choice at the offending line.
The point is, your accusation "You goto valgrind and bisect issues" (exact quote) would make unfamiliar readers think that valgrind does not give the exact source code location where the errors occur and that, sir, is a flat out lie. I'm sorry that there are no weaker words for it.
I know I am going to come off as a 'shill' but MS tools rock (I am not talking about their frameworks). It is the one thing that holds me to windows these days. All those tools you mention are available in windows and usually better polished. Valgrind compaired to say using boundschecker. You goto valgrind and bisect issues, boundschecker puts you right on the offending line that they think either overwrote memory or leaked.
You're going to come off as an MS shill because you are flat out lying. Valgrind tells you exactly what line is offending.
char *p = malloc(8);
p = 42;
Let valgrind run that code and it will immediately tell you that the source filename and linenumber that p=42; is on along with a callstack backtrace. Ditto with leaked memory, reads of uninitialized memory etc.
Efficiency matters. Python is great, but you don't want to use it for embedded work.
Actually, I am currently working on an ARM based commercial embedded system that is almost entirely written in Python (on Linux).
Once you make the leap of adding external ram and flash, which you need to run Linux reasonably, using python is not really a big deal. The whole system is still only a few square cm big; you could hide it in your fist.
"Card readers? We don't need no stinking card readers." -- Peter da Silva (at the National Academy of Sciencies, 1965, in a particularly vivid fantasy)