Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re: This again? (Score 1) 184

Why is it fair to group POSIX-C and MISRA-C together but not different assembly languages?

Because the difference between POSIX C and MISRA C is a large pile of custom headers to define type conversions. The difference between ARM64 assembly with Neon instructions and 6502 assembly is more like the difference between C++11 and the original 1983 version of Pascal.

Comment Re:This again? (Score 1) 184

He's not even right in a pedantic way. Assembly languages are programming languages.

No, the OP is right in a pedantic way. Assembly language isn't really a language, but rather a loose collection of related languages.

As for the other poster's comment that it is basically just human-readable machine language, so is C, but nobody argues that C isn't a programming language. :-D

Comment Re:Curly braces = good. Indents = bad. (Score 1) 165


Apologies in advance for the bad font, but Slashdot stopped allowing   because of the trolls, so this was the only way to get indentation.  Ugh.  There's some irony for you.

I've used GNU indent, and it is maybe 1% of the way to a complete solution, if that.  A complete solution needs crazy things like:

* Variable weights for indentation priority between the minimum indentation of a continuation line relative to the first line and colon alignment in Objective-C
* Rules on where whitespace can and can't be inserted to correct alignment (e.g. rules like "Don't put any space between the (strong, atomic) and the subsequent type name in an Objective-C property, in such a way that they can be outweighed by other rules if it makes the line too long
* Choosing whether to indent function parameters by the standard n spaces instead of indenting to the open parenthesis if the latter approach would result in a single parameter getting split across multiple lines and the former approach wouldn't
* Closing up space between certain types of tokens (arbitrarily)
* Adding space between certain types of tokens (arbitrarily)
* Proper handling of comment markup (e.g. HeaderDoc, Doxygen, JavaDoc, etc.) with knowledge of where newlines and whitespace matter
* Ability to handle programming languages other than C and related languages

And so on.  Basically, the set of rules would likely mean that everything on the left side of the language's BNF would be a named token type, and you could specify rules regarding whether spaces could be added before or after that token type.  For example, you might write rules like this:

my-if-statement-whitespace-ruleset  {
    weight 10000;
    if.token {
        space-after: 1;
    }
}
my-if-statement-whitespace-ruleset {
    weight 10000;
    function.name {
        space-after: close-up;
    }
}

To specify that an if statement should be followed by exactly one space before the opening parenthesis, but a function should not, and any such space should be removed.

You'd also need to be able to contextually describe specific tokens like braces.  For example, if you wanted to indent the opening brace of a function by 4 and every line nested inside it by 8, you might write something like:

my-function-body-indent-rule-set {
    weight: 100;
    function.body.first-matching-child("{") {
        min-indent: [previous-line] + 4;
        child-indent: [previous-line] + 8;
    }
}

So basically, something vaguely like CSS, but with weighting instead of order-based priority, plus the ability to define fallback rules with lower priority that get used if the higher-priority rule fails because it conflicts with another rule that has higher priority (e.g. an indent rule set that uses four-character indent if the first rule set for indenting to the open parenthesis gets overruled by a maximum line length rule).

Comment Seen it First Hand (Score 1) 43

It's a shame the Cisco blog is linked second, because it's a great (yet short) read.

Since the end of last month one of my very low volume email accounts has been on the receiving end of a new spam campaign trying to give me malware. The emails I've received exactly match the emails in Cisco's graph So it's neat to see what's behind it - in this case the Necurs botnet running at full tilt.

Considering this account was receiving virtually zero spam before, it's definitely a major uptick in spam.

Comment Re:Not buying it (Score 1) 133

Sure, it could be that. But it could also be:

  • A cleaning person plugging a vacuum cleaner into the power strip on the rack instead of into the wall outlet that's on an external circuit (combined with improper power filtering in the equipment).
  • Electrical noise caused by some other crappy piece of equipment in the rack (combined with improper power filtering in the equipment).
  • Errors caused by higher operating temperature.
  • Errors caused by emissions from natural Uranium or other radioactive elements in the soil.
  • A software bug.
  • A hardware bug.

And if it happens disproportionately on one class of equipment, unless there are material differences in the amount of shielding, any one of those five is probably much more likely than cosmic rays, IMO. :-)

Comment Re:So what's the story? (Score 1) 74

Shitty person? Dude just got another job, that's all. That doesn't one make "shitty"

We haven't heard the whole story, I agree. And I think "shitty" might be a bit strong.

But from what I have heard, from one side at least, it sounds like he was "hedging his bets"--got the job at Apple and figured he'd double-dip for as long as he could. If the Apple thing didn't work out, he could come back and no one would be the wiser that he was gone.

That wouldn't be a big deal anywhere else. But in journalism? Yeah, that's a bit tacky, to say the least.

Comment Re:Curly braces = good. Indents = bad. (Score 4, Interesting) 165

Agreed. And more importantly, if you have braces, it is possible for the IDE to programmatically fix the indentation so that it is easy to read. There's absolutely no sane reason to require a programmer to use whitespace for any reason other than between tokens that would otherwise be a single token if shoved together. All other use should be superfluous, and the IDE should make it readable for you without the need for a person to do it.

And the reason braces should be in every programming language, IMO, is that it makes it easier to jump to the end of a block. When I have nested blocks in a properly braced language, I can hit percent in vi, and I'm at the end of that block. I don't have to move the cursor to the beginning of the line and laboriously hit the down arrow key a line at a time until I find a line that isn't indented as far. Therein lies the path to madness.

Want to dramatically improve the programming world in a single project? Design a meta-language for code formatting so that a set of text-based rules can enforce everybody's own quirky code formatting standards. Make it handle at least the twenty or so most popular programming languages. Then open source it under a BSD license so that the interpreter can be readily built into every IDE on the planet. Then, we can finally dispense with all of these silly programming languages that use whitespace syntactically once and for all.

Comment Re:They HAD this service? (Score 1) 49

Start shooting in RAW mode. You'll hit a terabyte before you know it. Better yet, get a 5D Mark IV and use Dual-Pixel RAW so that 5% more image data can take 100% more space. I mean, you'd think they would have used sum-difference encoding, sign-magnitude encoding (with a single-bit right rotation so the sign bit is on the right), and bitwise run-length encoding (all the top-order bits first) to make that file format efficient, but instead, they encoded the sum of the two images followed by one of the two images by itself, both using lossless JPEG. I can't imagine what they were thinking. The impact of dual-pixel RAW should have been an order of magnitude less than it is.

Slashdot Top Deals

Bus error -- please leave by the rear door.

Working...