Wpisy z tagiem: wtf

Dziś szlifowałem jeszcze trochę Richtrisa, sprzątałem kod, dorzucałem kilka optymalizacji itd. Jedną z finalnych czynności było ustandaryzowanie nomenklatury, coby pasowało do opracowywanego Fairtrisa — buildy o nazwie PAL Extended wymieniłem na EUR. Skoro buildy zmieniły nazwę, to dla wersji europejskiej zmieniłem też nazwę pliku wykonywalnego, z pal ex.exe na eur.exe.

Mam ja na pulpicie trochę skrótów do miejsc i plików związanych z tymi projektami, w tym skróty do plików wykonywalnych. Skoro zmieniła się nazwa jednego z nich, musiałem edytować skrót i zmienić ścieżkę pliku, do którego się odnosi. Zmieniłem i… powłoka się popsuła. Zamiast ikonki pliku wykonywalnego, skrót posiadał ikonkę białej kartki (ikonka domyślna). Wnerwiała mnie, więc trzeba było coś z nią zrobić.

Pierwszy pomysł — zresetuję system, cache ikonek się przebuduje, będzie git. Zresetowałem i dupa — dalej biała kartka. Ubiłem eksplorer, uruchomiłem ponownie, żadnych zmian. Skorzystałem więc z Google, znalazłem kilka porad. Poważny serwis, jakaś ogólnoświatowa pomoc techniczna, serwis duży, wygląda, że ogarnięci ludzie go prowadzą, więc porady najpewniej są fachowe. I ta porada dotyczyła usunięcia pamięci podręcznej ikon, czyli pliku %LocalAppData%\IconCache.db i reset kompa. Brzmi sensownie — cache się usunie, po restarcie system go zbuduje na nowo, będzie git. Zrobiłem jak sugerowali — usunąłem ten plik, zresetowałem kompa i k...a mać, zepsuło mi powłokę jeszcze bardziej:

Pamięć podręczna ikon się nie odbudowała, backupu brak. W końcu to cache, plik tymczasowy, niby nieważny, a jednak. Teraz kartka się nie wyświetla, bo już nic się nie wyświetla — wszystkie skróty szlag trafił, zostały tylko etykietki. Mało tego, ikonek teraz brakuje również w oknie eksploratora plików i niektórych na pasku zadań (Edge np.).

Co teraz zrobić?! Jak to naprawić?!

Pierwsze co, skorzystałem z narzędzi do skanowania i naprawy systemu — SFC i DISM — ale nic to nie dało. Kombinowałem, naprawiałem, resetowałem kompa kilka razy, ale nic, ikonek jak nie było, tak nie ma. Spróbowałem ręcznie przywrócić ikonki, czyli dla każdej z nich PPM, właściwości, zmień ikonę, zapisz itd. — no nie da się, bo okno właściwości skrótu nie chce się otworzyć! :D

Ostatecznie napisałem na Discordzie do znajomka od klocków, potwierdził że ma tę samą wersję i build systemu oraz że ma taki plik na dysku. Podesłał mi go, wkleiłem go do odpowiedniego katalogu. Ikonki w eksploratorze pokazały się od razu po przeklejeniu pliku, a te na pulpicie i innych miejscach po restarcie systemu.

Konkluzja

Jeśli wam się ikonka któregoś skrótu nie wyświetla poprawnie, to niech was ręka boska broni dotykać pliku IconCache.db, a tym bardziej go usuwać — to nie jest zwykły cache. Po pewnym czasie system sobie taki wadliwy skrót sam poprawi — już kiedyś miałem taki przypadek i po ~kilku dniach samo się naprawiło. Jeśli jednak chcecie coś z systemu wywalić, to lepiej róbcie backupy i punkty przywracania, żebyście nie musieli później kombinować i tracić czasu na naprawy. A już na pewno nie wierzcie w to, co jakiś randomowy znawca zza oceanu pisze w popularnym artykule, nawet jeśli serwis wygląda na poważny i profesjonalny.

Ale mi dzisiaj JS napsu krwi. Faktycznie to piszę w TS, ale feature jest JSowy - wynika z engine.

Jest sobie coś takiego jak Promise. Fajne, fajne. Nieco zrypana monada, ale da się z tym żyć - (w zasadzie to trzeba).
Zrypane jest to, że do map i flatMap używana jest jedna metoda then.

console.log("started");
const myObj = {a:"works", dżem: (x)=>{console.log('did not expect that');} };
const p1 = new Promise( (res, reject) => 
	setTimeout(() => res(myObj), 1000)
);
p1.then ( x => console.log(x.a));

Kod powyżej powinien wyświetlić started, a po chwili works - nic dziwnego.
Zmieńmy tylko nazwę metody dżem na then i działanie programu się cokolwiek zmienia.

console.log("started");
const myObj = {a:"works", then: (x)=>{console.log('did not expect that');} };
const p1 = new Promise( (res, reject) => 
	setTimeout(() => res(myObj), 1000)
);
p1.then ( x => console.log(x.a));

Teraz nie wyświetli się napis works (wcale!!!) - natomiast automagicznie wywoła się metoda myObj.then.

Wiedziałem, że w metodzie Promise.then możemy przemapować rezultat na jakiś inny typ (jak map), albo zwrócić kolejny Promise i wtedy będzie działać klasyczne łączenie monad (jak flatMap/bind).
Ale okazuje się, że to niecała prawda.
Otóż wcale nie trzeba zwrócić Promise, aby łączenie przez odpowiednik flatMap zadziałało. Wystarczy, że zwrócimy obiekt, który zupełnie przypadkiem(!!!) ma metodę o nazwie then.
I wtedy łapie się on jako Thenable (w TS jest to oznaczone jako PromiseLike) i... cały mechanizm rusza sam. Jest to ewidentnie celowe (feature) , ale dla kogoś przyzwyczajonego do Nominal typing i normalnych monad mocno nietypowe. Straciłem ze 2 godziny zanim zrozumiałem co się dzieje.

Structural typing: ty how do you do złamany!