efaref

> Despite being an obvious usability hole, this has never been fixed.

You can now change the prefix for your recipes by setting the .RECIPEPREFIX special variable (https://www.gnu.org/software/make/manual/html_node/Special-V...).

That being said, with a properly configured editor I've actually found that TAB is an ideal character for the recipe prefix.

The refusal of so many people in this industry to learn a pretty simple and incredibly fundamental tool frustrates me no end.

I guess this article could be worse: the number of times I see people reimplement poorly thought out clones of make and present them as the new thing that everyone should use is just absurd.

I'm searching mostly C code. I'm in the src directory, so there's nothing there except the source code.

It's a proprietary codebase, but it consists of around 500MB of mostly C and C++ files and their headers. There are a few other files (makefiles, a few perl/python scripts).

It seems an order of magnitude slower to me:

    $ time grep -r some_token .
    real	0m0.467s
    user	0m0.252s
    sys 	0m0.215s

    $ time ag some_token
    real	0m2.948s
    user	0m0.112s
    sys 	0m3.083s

(Both run twice to ensure the disk cache was warm).

Am I doing something wrong?

You're right. Powerpoint has the advantage of being good enough, and ubiquitously available (for people with Office, which is pretty much everyone).

It's weird, but I really do remember IE4 being great.

Even that's an unnecessary complication. The code solution should read like the spec, so that if someone comes along later to make FizzBuzz depend on some other set of constraints, they know what to do.

The compiler can optimize away the duplicate tests. That's its job.

How about you show me how comfortable you are with python by coding up a quick binary tree implementation?

SMS-based 2FA is also a dream when you can glance at your wrist and then type the code in.

I'm really going to miss the NHS when the tories have finished dismantling it. :(

Sometimes you have to work on spec.

Some people are really good at bullshitting their way through stuff. You need to make them actually do stuff to discover they flounder.

And since you can't have them do anything meaningful in an interview (there isn't enough time), anything you ask them to do will be a silly "programming puzzle".

Well, I guess you could start your own company. You could even hire anyone who comes in the door claiming to be able to code, although what you'll do with a dozen people who can't even FizzBuzz is beyond me.

The solution to buy-to-leave is surely extremely high taxation on properties left empty (and I'm talking "10% of market value" levels of taxation, enough to obliterate any possible returns on investment).

If by "well documented" you mean "lots of people have whinged about it at great length", then I guess you're right. It's also a "tried and tested" method, too, so it's got that going for it.

I think if you approach them correctly (like the author suggests), then actually they're fine for their intended use. (Not perfect, but this is the real world, nothing's perfect).

If you can't cope with scrawling some pseudocode on a whiteboard because that's "too much pressure" then you're going to really struggle when a deadline looms and we "absolutely must get this code out to the customer by Friday because a $50M contract is on the line."

For something that claims to "grok" URLs, using "://" as part of the logo seems to be misunderstanding how URLs (are supposed to) work.

According to RFC3986, URIs (the proper name; URLs are a kind of URI) are correctly of the form:

    <scheme>:<scheme-specific-part>

For some schemes, the <scheme-specific-part> may contain a <hierarchical-part>, the format for which is:

    //<authority>[/<path>] | <path>

So it's only hierarchical URIs with a defined authority that have the (admittedly iconic) "://" in them.

I know most people identity URIs as having that sequence in them, but these are all valid URIs:

    mailto:bob@example.com
    sip:bob@example.com
    tel:+18005550123
    file:/path/to/file

I'm not saying I expect everyone to understand these subtleties, but people who claim to grok URLs ought to.

And a password can change. If someone works out how to mimic my biometrics, what do I do?

I did. Look at the second line of the macro expansion.

The problem with solutions like this is that they break the abstraction of using algebraic notation for calculations. We're conditioned to expect calculations to be written in algebraic notation, and indeed one of the original selling points of C is that it lets you express calculations in that form. To undo that is a massive shame.

The calculation itself absolutely MUST look like this:

    a + b

While maybe it's not too bad for simple addition, think of compound expressions with multiple terms.

I just tried this, and GCC6 does indeed optimise this correctly:

    0000000000400560 <maybe_overflow>:
      400560:	01 f7                	add    %esi,%edi
      400562:	70 03                	jo     400567 <maybe_overflow+0x7>
      400564:	89 f8                	mov    %edi,%eax
      400566:	c3                   	retq   
      400567:	31 c0                	xor    %eax,%eax
      400569:	c3                   	retq

The API for those is equally insane (they replace the arithmetic operation). See my sibling comment for a more reasonable proposal.

A comment below reminded me of these: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins..., which are close, but have an insane API as they replace your arithmetic operations with ugliness.

I think they can be fixed with sensible macros, though:

    #define ADDITION_WOULD_OVERFLOW(a, b) \
      ({ typeof((a) + (b)) __r; __builtin_add_overflow((a), (b), &__r); })

Hopefully the compiler would optimise:

    if (ADDITION_WOULD_OVERFLOW(a, b))
    {
       return 0;
    }
    return a + b;

to only do the addition once.

Am I the only one who thinks that writing

    if (x + y < x)

is utterly insane? It completely breaks the abstraction of algebra that's being used in the language. Much better would be:

    if (ADDITION_WOULD_OVERFLOW_INT(x, y))
    {
       ...
    }

This is (a) far easier to read, and (b) more likely to be more correctly implemented as something like:

    #define ADDITION_WOULD_OVERFLOW_INT(a, b)            \
        (((a) > 0 && (b) > 0 && (b) > INT_MAX - (a)) ||  \
         ((a) < 0 && (b) < 0 && (b) < INT_MIN - (a)))

For bonus points you could write this as part of the compiler support library to derive the types and limits automatically, or even define it as part of the compiler. Why do GCC/clang not have:

    __builtin_addition_would_overflow(a, b)

?

Whilst nowhere near as bad as black lung, RSI and lower back pain caused by sitting all day are real things. Programming isn't without its own physical risks.

You could have used CBOR for many of those things (http://cbor.io/).

Why don't you publicly insult them all and find out?

For science, of course.

I think vanilla accounts automatically get the battle chest version, which is expanded to included the previous expansion during each expansion. It looks like the battle chest includes everything up to Pandaria, now.

https://eu.battle.net/shop/en/product/world-of-warcraft

:help :v will tell you:

:[range]v[global]/{pattern}/[cmd] Same as :g!.

Where:

:[range]g[lobal]!/{pattern}/[cmd] Execute the Ex command [cmd] (default ":p") on the lines within [range] where {pattern} does NOT match.

So :v/error/d will delete all lines that don't contain the string "error".

You only have to look at long-term trends to see what nonsense that is.

Since you mentioned milk, let's use that. In the UK, in 1914, a pint of milk cost 1d, and the average wage was 16s 6d for a standard 58 hour working week.

That's an average wage of 198 pints of milk per week, or 3.4 pints of milk per hour.

In 2016, a pint of milk is 45p. The minimum wage is £7.20, or 16 pints of milk per hour. If you buy your milk in four-pint bottles (economies of scale not available in 1914), your wage doubles to 32 pints of milk per hour, a nearly 10-fold increase on a hundred years ago, and you're only working two-thirds of the amount of time per week, too!