I have a work laptop by Apple Computer, a 2017-ish MBP with a loathsome Touch Bar. Since day one I noticed very slow new and closed Safari tabs. And it got only worse with time ten to fifteen seconds of non-responding browser. Funny enough, it was only if I had and active input on a page. Otherwise everything is fine (not).

Earlier this year I overclocked upgraded my personal macbook to 16 inches 32 gigabytes Core i9. Expectedly enough I expected that Safari will be fast again with this ridiculous config, but in reality it was opposite of nice.

Only recently I compared facts (old macbook didn't have this kind of problem, and generally non-touchbar macbook don't have it), and finally found the root of the problem: you have to remove tabs previews from Touch Bar. When there are too many of them, any change of this list becomes too heavy for the Touch Bar, and it slows down the whole browser. In the end, I didn't really need those previews, I always have 30+ tabs and they become small lines. No use.

Solution: go to menu item "View" — "Customise Touch Bar", and remove the default set of widgets (backwards-forwards arrows, which are simply not needed when you have awesome touchpad, and actually tabs list). The moment you remove it, all tabs will be sanic.exe fast.

You can thank me for this advice by buying my album on Bandcamp.

On our way to Saona island we also visited pseudo-old city of Altos de Chavón. Point is this city was built from 1976 to 1992, but looks as if Columbus personally laid the city. Mixed impression, honestly. The city doesn't have a general idea. However, this lack of uniformity opens an unexpected advantage: a huge ton of beautiful textures and patterns underfoot and around.

I haven't had a proper vacation since 2015 (if not counting those I spent on university exams and St. Petersburg ethnographic trips), that last time was in Bulgaria, in Sunny Beach which lies between Burgas and Varna. That city was a slightly more european than Yevpatoria and Gursuf that I'd been many times before. That's why that city didn't enrich my cultural and ethnographic baggage.

All subsequent vacations, as I mentioned before, I spent in St. Petersburg, and quite naturally it resulted in my relocation to this city.

Nevertheless, one should have a proper rest, because burnout isn't a myth and always sneaks up unnoticed. Thus strategic decision was made: next vacation should be at sea. My cherished dream was Dominican Republic — don't know why, pretty photographs maybe like in that old Bounty ad.

And this is exactly what happened. I found a good adults only-hotel (didn't mean really, but cool) with nice and not very crowded beach. It turned out to be Punta Cana city (Bavaro area). During this vacation I found a new passion — papaya and basically spent the entire vacation quite hedonistically and just a little bit snobbish.

Hospitality crew finally came back to Saint Petersburg after a long break. Whiney, London Elektricity, MC Dynamite and other folks set the heat on four stages.

Red perches showed everything to everyone once again.

_{+88 photographs without commentaries.}

So apparently I'm gonna be officially shooting photographs of Red Snapper concert this Saturday at Erarta Museum. Concert report will be up on Sunday.

As they say — please stand by.

Upd: done.

Makoto, Spectrasoul, London Elektricity, Metrik and Dynamite MC including our own stars like Tapolsky, Sunchase and Vera Sue. It's illegal to miss that.

_{+160 photographs without comments.}

Say you did the following

and proceeded to your business, but the timer fired once or even not a single time. Why? It's because your timer object has been eaten by garbage collector, and when DispatchSourceTimer is deinited, it (obviously) stops itself. It's worth reminding that GC is triggered when scope closes, in our case — after async block fired. Therefore, if you want to regularly run certain task, you should store reference to timer object in a global storage, which would live as long as you want, but not the GC. It's also recommended to wrap access to this storage with synchronous serial queue to avoid shameful race conditions.

By the way, there might be an opposite situation: timer wouldn't destroy when you destroy all references to it. The reason is timer handler might have a strong reference to some object or self. In order to ensure it wouldn't happen, explicitly specify [weak self] in timer handler header.