🚀 go-pugleaf

On 27/01/2020 21:32, Maciek Godek wrote:
>> I dlaczego nie możesz uzy kompilatora C++?
> Mam wiele powodów. Ale nie tego dotyczy ten wątek.

Rozumiem, więc to kwestie religijne jednak.

>> Nie, poniewa zmiana z gcc na g++ to jaki 10 sekund, a zmiana na Lua to
>> od kilku do kilkuset godzin i zerowy sens.
> Zmiana na g++ to też zerowy sens.

Wręcz przeciwnie. To troche jak zamiana łopaty na koparkę. Też sensu 
brak jak się kopie dziurę pod kwiatek. Tylko po co wtedy komu korutyny.

> Pomijając jeszcze tę kwestię, że trzeba go jeszcze najpierw zainstalować.

To faktycznie showstopper.

> A później jeszcze zainstalować boosta.

A to już overkill. Ze dwa polecenia w konsoli to o trzy za dużo.

> I to u każdego developera, który pracuje nad tym projektem.

Nie do ogarnięcia przez IT ani tym bardziej developerów, oni się gubią 
przy byle pingu a co dopiero apt-geta użyć.

>> Użyć boosta, dorobić abstrakcję i zrefaktoryzować jak będzie po co za
>> kilka lat.
> "Dorobić abstrakcję"?

Chyba nie podziewasz się że ktoś będzie chciał używać niestandardowych 
makr wprost w kodzie w których aż roi się od śmiesznych problemów z 
okolic "zapomiałem dodać makra _START i wylatuje"?

> A nie mogę od razu użyć docelowego rozwiązania?

Możesz. Ale boost::context/coroutine nie jest jeszcze "docelowy". 
Dlatego owija się w to abstrakcję i izoluje granicę refaktoringu.

> To jest 20 linijek kodu.
> A boost ma... no, ile linijek?

Biliard. W sumie bez znaczenia. U mnie to i tak jeden #include.

>> Czy potrafisz z całą pewnością wskazać sensowną zaletę side effects
>> jakiejś implementacji vs szeroko używana bibliteka ktorej spore
>> fragmenty lądują co jakiś czas w standardzie?
> Projekt, nad którym pracuję, i tak korzysta już z tego kompilatora i jego różnych rozszerzeń.

I dlaczego tym rozszerzeniem kompilatora nia ma być g++/boost? Znowu 
religia?

> I to nie jest "side effect", tylko udokumentowane rozszerzenie języka.

Ja mówie o "[...]żeby wartości argumentów były przechowywane między 
wywołaniami, to musimy je zapisywać w zmiennych statycznych.[...]".

No to się ktoś by zdziwił w handlerze przerwania ARMa że mu się jakieś 
zmienne statyczne nadpisują w sąsiednim przerwaniu z sąsiedniego przerwania.

>> Jesteś pewny że ktokolwiek będzie uzywać *KORUTYN* w handlerach przerwań
>> na ARMie czy innym 6502? Żartujesz, powiedz proszę.
> No, ja będę. Właściwie to głównie po to opracowałem ten mechanizm.

A po co w przerwaniu korutyny? Impelemntujesz maszynę stanów? Korutyny 
są potrzebne kiedy algorytm jest złożony i nie da się go spłaszczyć bez 
poświęcenia czytelności. Masz aż tak złożone algorytmy w przerwaniach? 
Jesteś pewny że nie da się ich wyrzucić poza przerwania?

> Żeby móc sobie pisać wątki na przerwaniach.

OK, oczywisćie sprawdziłeś overheat przełaczanai stosów i zapisywania 
kontekstu rejestrów?

Zaryzykuje: a sprawdziłeś co oferuje FreeRTOS?

>  Więcej na ten temat pisałem na comp.lang.c.
> Widzisz w tym jakiś problem?

W zasadzie tak: przerwania, jak to przerwania, powinny być szybkie. 
Korutyn bym tam nie wsadzał. Szczególnei takich z okolic "workaround 
przez zmienne statyczne".

> Rzecz w tym, że zarówno wyjątki, jak i korutyny są mechanizmem transferu sterowania. Nie do końca rozumiem, jak działają wątki w C++, ani tym bardziej jak działają korutyny w C++.

Korutyny w c++ działaja tak samo jak cooperative mutitasking w C. 
Zapamiętuje się stos, rejestry i przepina na inny "fiber". Wsio. 
Technologia z lat 70 gdzieś chyba.

> Co więcej, nie interesuje mnie to do tego stopnia, żebym chciał poświęcać czas na uczenie się tego i analizę wszystkich sytuacji, w których coś może pójść nie tak.

Ależ niestety musisz. Przez ten kod na statycznych zmiennych jesteś 
zmuszony do analizy i to choelrnie cieżkiej bo masz praktycznie 
preemptive multitasking, w przerwaniach. Albo ciezka analiza albo game over.

> A Ty w dalszym ciągu nie odpowiedziałeś mi na moje pytanie. Czy będzie problem ze wznawianiem tych korutyn w przerwaniach, czy nie będzie?

Oczywiscie że odpowiedź zależy od zabyt dużej liczby czynników aby miała 
sens. Ale ponieważ mam pod ręką fusy: masz problem z przekazywaniem 
wartości pomiędzy wywołaniami i sugerujesz zmienne statyczne i pracujesz 
z przerwaniami. Co może pójść źle?

>> Bazującego feature jakiegoś kompilatora o niejasnej przyszłosci i
>> przenośności.
> Tzn. GCC jest "jakimś kompilatorem o niejasnej przyszłości i przenośności"?

Feature tego kompilatora jest o niejasnej przyszłości.

PS. Mała uwaga: coroutines wymagają *czegoś* ze stosem. kopiowania, 
podmieniania, czegokolwiek. To jest ten brakujący ficzer w implementacji.