beeforpork

> #define NO_BITS ((uint16_t)-1)

Haha! :-)

Shoot. Just as I was just constructing the perfect murder story.

C'mon guys, it means 'cromulent', of course.

préciser = to precise

I like that. :-) Or maybe 'precisify'.

No, this is misinterpretation and too absolute a conclusion. The truth is not found in extremes. Protection is about reducing viral load -- it is useful even without fully eliminating viral load. A cloth facemask does get damp when you breathe through it, ergo some of your exhaled water (= infection carrier) got caught. An N95 mask catches a lot more. You need a bit of viral load to get infected, so whatever reduces viral load will help.

It is dangerous to immediately conclude that aerosol transmission makes masks security theater. They do not, they do help a lot.

What is the license for this code?

Universe? What a limited view!

(1) 大人気 (おとなげ, otonage) - maturity

(2) 大人気 (だいにんき, daininki) - very popular

That's indeed a problem there. I was there for a walk on a cold and windy day. After walking for a while, we wanted to go back, and it turned out horrible, because back was against the wind, and there is nowhere to hide from the wind. Sure, you will not leave civilisation here, but trees would help.

They probably don't plant any because when they finally do decide to build a new residential quarter, they'd also have to fight against tree savers. And probably there's a regulation that for each tree you fell, you need to plant a new one. So better not plant too many trees without good reason...

Hehe, yes, I am sure.

Mine was 800€. To pay this, you need to be a coffee nerd, but I think it is absolutely the most important thing to get consistency and satisfaction. I use an inherited antique ceramique (no plastique) pour over filter and do not feel it has any drawbacks.

I will try Tetsu's technique.

So how extremely could I exploit this? Could I write a program entirely in C, compile it with the D compiler, and use D's unit test framework? That would be insane (very good insane, obviously).

> Human -> Huperson

Haha, that's good one, I love it! :-)

(Although 'human' comes from Latin and has nothing to do with Germanic 'man', but these details are never part of such a discussion, so let's ignore them.)

When do people realise that 'homo sapiens' is sexist (and maybe offensive to LGBT* people!!)? It must be renamed to 'persona sapiens'!

Citing from the 'About' page:

> This site is dedicated to questioning conventional thinking in fitness, nutrition, healthcare, human nature, human potential, and more. I hope to be your source for a level-headed, game-changing approach to health. ...

And I hope to help you decide whether the article may be worth reading.

According to the specs, the supercaps may also fail within 10 to 20 years due to lifetime issues. They do not last forever and have a significantly lower lifetime than normal caps.

I've actually opted for batteries for very small currents (µA range) because the battery lifetime is about the same as supercap lifetime, so why bother with a charging circuit?

Two batteries would be nice. Or a battery plus a (normal) cap backup that lasts a week or so (or at least the time it takes to change the battery).

Yes, as others said.

What's more: you could also interpret the typical stack based execution in machine code as a special CPS style execution: only the order is strictly LIFO so that the continuations can be allocated on the stack. I.e., the continuation object for a function call is simply the function call's stack frame. Everything is there: 'contuation address' is in there: the return address, i.e., the 'ret' instruction, which is just a computed branch in the end, implements the invocation of the continuation, and it passes it the return value as a parameter. Sure, the compiler does need to be careful about the stack pointer manipulation, but the analogy is close enough. This can very easily be changed to a heap-based allocation of 'stack frames'. The compiler can also optimise and do some continuation allocations on the stack when it knows it will run out of lifetime after the call, or on the heap, just by the right setup of the frame pointer. And the compiler may even do tail call optimisations from this, so even with CPS, you get O(1) memory usage if the code is recognised to allow that.

Even more, if the heap is compressed, and a heap allocation is as easy as incrementing a pointer, then the stack pointer could be reinterpreted to point to the end of the continuation heap (careful with deallocations in this case, of course), so just a heap and no stack, the runtime system would not even need more pre-defined registers than a normal stack based execution and instructions that implicitly increment the stack pointer could be used to fill the next continuation object -- it would look exactly like constructing a stack frame.

It's all connected.

Why do you need the versioning_trigger on 'INSERT' also? There is no original row to archive in this case, or what does this do?

> ... but you sometimes have to search or look at more than one man page to find what you are looking for.

Well, yes, that's one of the problems. I am saying the docs are unintuitive, and now you are confirming that.

For 'git init --bare', I look into 'git-init' and search for '--bare'. That's what I do, that's intuitive to me. And that's not where the info is. Is all I am saying.

> git init --bare

Aha, '--bare': what does that do? I always just type 'git init'.

Let me do a little git bashing, OK? Sorry for this, but it so nicely documents my initial problems with git when I started a few years back. And it still occasionally (like right now) makes me shake my head in disbelief:

> man git-init

Searching for --bare gives me:

> --bare

> Create a bare repository. ...and how GIT_DIR is set...

You don't say!!

I search for other occurrences of 'bare' in that man page, but after skipping those in the synopsis and the help text, it says:

> Pattern not found

So bare = bare. Tautological documentation. It's all obvious, right?

What --bare really does is to put what git would normally put into the '.git' subdir into '.'. I tried what it does, that's how I found out.

Git is great, but please never claim that it is intuitively documented.

No, please! Have your blood checked for vitamin D levels, then ask a doctor what to do.

I am not a doctor. You are not a doctor. 'There was another study' is a terrible way to self-medicate. Consequently, 'look up the studies yourself' is bad advice for self-medication.

If you do not have a deficiency, you can severely damage your health by taking high doses, like destroying your kidneys. I guess that happens because those kidneys need to wash out all the crap you feed your body that it doesn't want nor need.

5000 IU is not a low dose and should only be taken if you have a diagnosed vitamin D deficiency.

Those are two different things:

For 'char has 8 bits': the bitwidth is 'implementation defined' in C. If you know your target architectures, you can assume it's 8 bits, because it's indeed a question of portability.

For 'int must not overflow': this is 'undefined behaviour' in C. You must not do it, regardless of what you know about your target architectures, because this is a language level prohibition.

This is the trap with 'undefined behaviour': it has nothing to do with portability, but it is a language level definition.

I.e., if the C std says it's 'undefined', it is not to be avoided for portability reasons (hardware, assembler), but it must not be used, end of story. The portability stuff is called 'implementation defined' in C, not 'undefined behaviour'. The problem is that the compiler can (and will!) exploit undefined behaviour rules. E.g., the following code is officially broken (and not just on weird hardware, but everywhere, as defined by the C std):

  int saturated_increment(int i)
  {
      if ((i + 1) < i) { /* if it overflows, do not inc */
          return i;
      }
      return i + 1;
  }

The compiler may (and many will) remove the whole if() block, because i+1<i is trivially false, because int cannot overflow (says the C standard).

As one can imagine, when compilers started exploiting this, a lot of discussion about sensibility followed. And gcc added -fwrapv among other things.

(And the code would be fine if 'unsigned' was used in stead of 'int', because this is only a problem of signed ints.)

Funny how US media write 'Pfizer' and EU media write 'Biontech'. Patriotism, probably. Or for Reuters, maybe Brexit!? What's it usually called in Asian, South American, or African media?

'Pfizer/Biontech' or 'Biontech/Pfizer' is just too long!

> What the hell? I can’t believe I spent time for this. It’s just elevator music.

Is it not wonderful to find out by some hacking that elevator music is broadcast via UDP in the hotel? It's a fantastic project for a hotel room!

I'd love to compare a bird song in Finnish with the English one. Will it be clearly different with only one harmonic?

As I said, it will get super-ugly, and it has not been done (in any language with more than 1 user), I think. Why? Because you will want an error class for a whole tree of classes you define, and it is not so trivially clear how that should look like. A simple 'bottom' (i.e., 'null') works. But e.g. you have 'Expr' for your expressions and you want 'ExprError' to be your error class for that that subclasses all 'Expr' and is a superclass of bottom. Now when you define 'ExprPlus' and 'ExprMinus' and 'ExprInt' and so on, all subclasses of 'Expr', you still want 'ExprError' to be a subclass of those to indicate an error. That is the difficult part: how to express exactly what you want? How does the inheritance graph look like? At that point, languages introduced exceptions. And after that: generic error classes: 'Optional<Expr>' and 'Error<Expr>', etc., without a global 'bottom'. This forces you to think about an error case: you cannot just return ExprError from anything that returns Expr, but you need to tell the compiler that you will return 'Optional<Expr>' so the caller is forced to handle this somehow.

What you want is a 'bottom' class (as opposed to 'top' = Object), not null. Essentially, a class that subclasses everything to indicate some problem. Look at how 'null' works: the class of 'null' (whether it can be expressed in a language or not) is a subclass of anything you define, so you can assign 'null' to any variable of any class you define. This is how 'bottom' works, if you want it as a class. But you already recognise that this is not really what you want: you want specialised sub-classes representing errors of specific classes you defined, which are all superclasses of a global bottom class.

Such a system can be done, but it is probably super ugly and confusing. The usual answer instead is: exceptions, i.e., instead of instanciating an error object, throw an exception (well: you do instanciate an error object here...). That works, but if overdone, you get programming my exception, e.g., when normal error conditions (like 'cannot open file') are mapped to exceptions instead of return values.

The usual answer to that problem then is to use a special generic error class that you specialise for your type, the simplest of which is 'Optional' from which you can derive 'Optional<MyType>'. You can define your own generic type 'Error<MyType>', with info about the error, of course. I think (please correct me if I am wrong), this is currently the state of the art of doing error handling. It's where Rust and Haskell and many other languages are. I've seen nothing more elegant so far -- and it is an ugly problem.

> Tony Hoare apologized for inventing the null reference: I call it my billion-dollar mistake.

Have we learned nothing? Many languages without NIL/Nil/nil/null/NULL existed already when Golang was born.

And this attempt to heal the damage hurts, too:

> “make the zero value useful” philosophy

This is like instead of programming by exception (Java), it's programming by ignorance (of errors).

I like a few things about Golang (handling of numeric literals, for example), but not this thing.

> There’s a good chance you’re totally disconnected from the programming scene.

That made me grin -- 'the programming scene'. What a club!

Julia is such a wonderful language. There are many design decisions that I like, but most importantly to me, its ingenious idea of combining multiple dispatch with JIT compilation still leaves me in awe. It is such an elegant solution to achieving efficient multiple dispatch.

Thanks to everyone who is working on this language!

Is there scientific proof that a bronze die makes better pasta? The myth is repeated here that it boosts 'sauceability'. Even if the die roughs up the pasta (why does only bronze do this?), I cannot imagine how this could make a difference after cooking.