itayperl

There may be other use cases, but it can be a useful pattern for mixing async code into a non-async project. In the specific places where using async for some task makes sense, you would just spawn a thread with an event loop, then push work into the new loop from non-async code using run_coroutine_threadsafe.

BiDi sucks, and as an RTL language speaker you learn to live with it.

My native language is Hebrew, and we don't bother translating most technical terms to Hebrew. You end up with technical documents looking something like this:

".yadot patch a desaeler Apple .iOS 9.3 ni ytilibarenluv privilege-escalation a dnuof srehcraeser ehT"

In newspapers, where lines are typically short, you get the effect in the screenshot in question. E.g.:

   "Everyone gets a day .ni tnew eH
            .dias eh ",off tomorrow

You can't really get used to that. You actually have to read the second line sideways from the middle!

By the way, typing mixed text is even worse than reading it. You have to press alt+shift every 2-3 words to switch layout. If that's not bad enough, Office 2007 (if I'm not mistaken) introduced a 0.5-1sec lag after each keyboard layout switch. Imagine typing out an entire document like that. I lost my nerve a couple of times.

In many cases we avoid this issue by simply writing technical documents in English, but sometimes that's not an option.

Some problems I have encountered with this approach:

1. dash before include. It will cause make to ignore any errors when generating the .d files. It can be pretty difficult to figure out what went wrong. Removing the dash will show a (harmless) error message for every .d file generated, which is pretty annoying.

2. At one time a.c includes b.h and you run make. a.d is created with "a.o: a.c b.h". If at this point you add to b.h an include to c.h, the new dependency of a.o on c.h will never be updated in a.d unless you manually delete it. This can cause some pretty nasty bugs! This can be solved by adding

    -MT $*.o -MT $*.d

to the gcc command line, which causes the dep file to regenerate when one of the dependencies changes (in fact the make manual suggests a similar solution using sed). However this creates another problem: if you remove a header a.h included by a.c (and the #include line to it), a.d still depends on a.h, so make will fail looking for it until you manually delete a.d (and any other dep file depending on the removed header).

tl;dr: this solution leaves much to be desired, and can be dangerous in some conditions.