On 20.07.2022 16:57, heby wrote:
> On 20/07/2022 15:45, JDX wrote:
>>> Tak. TortoiseSVN. Integruje się z powłoką windowsa i masz je "pod
>>> prawym przyciskiem myszki", również w Total Commanderze.
>
>> No właśnie, i dlatego wszystko spod znaku Tortoise to dla mnie gówno.
>
> A konkretnie dlaczego?
No właśnie ze względu na menu pod prawym klawiszem. Nie znoszę tego,
podobnie jak i Windows Explorera. VCS w postaci wtyczki do IDE też
niezbyt do mnie przemawia, aczkolwiek jest to rozwiązanie lepsze od
Tortoise*. W każdym razie ja lubię mieć VCS-a jako oddzielny programik
ze swoim własnym oknem.

do góry

On 21/07/2022 04:43, JDX wrote:
>>> No właśnie, i dlatego wszystko spod znaku Tortoise to dla mnie gówno.
>> A konkretnie dlaczego?
> No właśnie ze względu na menu pod prawym klawiszem.

A, czyli to kwestia gustu.

> Nie znoszę tego,
> podobnie jak i Windows Explorera.

Menu pod prawym działa w Total/Double Commander. 99% ludzi jakich znam,
pszących pod Windowsem, używa tego softu (TC/DC), również komercyjnie,
podzas programowania poważnych rzeczy.

To na tyle dobre, że jest i na Linuxie, RabbitCVS.

Ok, przyjmuje do wiadomości, choć przyznam że oglądając inne narzedzia,
takie jak perforce p4v, tęsknię za tortoise.

do góry

W dniu 2022-07-20 o 22:45, heby pisze:
> On 20/07/2022 21:57, Janusz wrote:
>>>> Informatyce, nie w programowaniu, nigdzie nie twierdziłem że jestem
>>>> programistą.
>>> To bardzo wiele wyjaśnia.
>> No to teraz ładnie przeproś :)
>
> Zaraz po tym jak określisz dlaczego dynamiczny polimorfizm działa na
> moim Harvardzie.
A w którym miejscu napisałem że nie może? tylko że w tym wykonaniu nie
różni się on niczym od osobnych funkcji na każdy typ zmiennej, jedynie
zapis jest prostszy.

--
Janusz

do góry

On 21/07/2022 09:20, Janusz wrote:
>> Zaraz po tym jak określisz dlaczego dynamiczny polimorfizm działa na
>> moim Harvardzie.
> A w którym miejscu napisałem że nie może?

Tutaj:

On 19/07/2022 18:35, Janusz wrote:
>> Jak to zaprząc do realizacji różnych funkcji przez każdą kopię (nie
>> wiem jak to się nazywa) tego templates.
> Ale na avr-ze to nie pójdzie bo ten procek nie wykonuje programu z ram-u
> (architektura Harvard) więc żadnej kopi nie uruchomi.

Co prawda dotyczy to statycznego, ale tym gorzej dla Ciebie.

do góry

W dniu 2022-07-21 o 09:28, heby pisze:
> On 21/07/2022 09:20, Janusz wrote:
>>> Zaraz po tym jak określisz dlaczego dynamiczny polimorfizm działa na
>>> moim Harvardzie.
>> A w którym miejscu napisałem że nie może?
>
> Tutaj:
>
> On 19/07/2022 18:35, Janusz wrote:
> >> Jak to zaprząc do realizacji różnych funkcji przez każdą kopię (nie
> >> wiem jak to się nazywa) tego templates.
> > Ale na avr-ze to nie pójdzie bo ten procek nie wykonuje programu z ram-u
> > (architektura Harvard) więc żadnej kopi nie uruchomi.
>
> Co prawda dotyczy to statycznego, ale tym gorzej dla Ciebie.
Co gorzej, odpowiedz na pytanie, czy avr wykona program z ramu?

--
Janusz

do góry

Janusz <j...@o...pl> napisał(a):
>> Jak to zaprząc do realizacji różnych funkcji przez każdą kopię (nie wiem
>> jak to się nazywa) tego templates.
> Ale na avr-ze to nie pójdzie bo ten procek nie wykonuje programu z ram-u
> (architektura Harvard) więc żadnej kopi nie uruchomi.

O jakie konkretnie szablony Ci chodzi? Te z C++ polegają na tym, że
kompilator tworzy kilka wersji jednej funkcji. Są normalnym kodem i na AVR
będą siedzieć we Flashu a nie RAM-ie. Nie ma dynamicznie generowanego kodu w
czasie działania programu.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

W dniu 2022-07-21 o 13:09, Grzegorz Niemirowski pisze:
> Janusz <j...@o...pl> napisał(a):
>>> Jak to zaprząc do realizacji różnych funkcji przez każdą kopię (nie
>>> wiem jak to się nazywa) tego templates.
>> Ale na avr-ze to nie pójdzie bo ten procek nie wykonuje programu z ram-u
>> (architektura Harvard) więc żadnej kopi nie uruchomi.
>
> O jakie konkretnie szablony Ci chodzi? Te z C++ polegają na tym, że
> kompilator tworzy kilka wersji jednej funkcji. Są normalnym kodem i na
> AVR będą siedzieć we Flashu a nie RAM-ie. Nie ma dynamicznie
> generowanego kodu w czasie działania programu.
>
No właśnie o tym cały czas piszę :) nic te szablony czy polimorfizmy nie
dają w np zmniejszeniu ilości kodu. Przejrzystości też nie.

--
Janusz

do góry

Janusz <j...@o...pl> napisał(a):
> No właśnie o tym cały czas piszę :) nic te szablony czy polimorfizmy nie
> dają w np zmniejszeniu ilości kodu. Przejrzystości też nie.

Zmniejszają kod źródłowy, wynikowy oczywiście nie.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

W dniu 2022-07-21 o 13:36, Grzegorz Niemirowski pisze:
> Janusz <j...@o...pl> napisał(a):
>> No właśnie o tym cały czas piszę :) nic te szablony czy polimorfizmy
>> nie dają w np zmniejszeniu ilości kodu. Przejrzystości też nie.
>
> Zmniejszają kod źródłowy, wynikowy oczywiście nie.
>
No właśnie, przy małych prockach z małymi zasobami jest to istotna wada.
Dlatego cały czas piszę że nie da się jednej miary przykładać do
wszystkiego, środowiska z dużych maszyn nijak sie mają do małych
procków, ale herby zaraz na mnie nakrzyczy że jestem betonem i jest
inaczej :)

--
Janusz

do góry

W dniu 2022-07-21 o 12:53, Janusz pisze:
> W dniu 2022-07-21 o 09:28, heby pisze:
>> On 21/07/2022 09:20, Janusz wrote:
>>>> Zaraz po tym jak określisz dlaczego dynamiczny polimorfizm działa na
>>>> moim Harvardzie.
>>> A w którym miejscu napisałem że nie może?
>>
>> Tutaj:
>>
>> On 19/07/2022 18:35, Janusz wrote:
>>  >> Jak to zaprząc do realizacji różnych funkcji przez każdą kopię (nie
>>  >> wiem jak to się nazywa) tego templates.
>>  > Ale na avr-ze to nie pójdzie bo ten procek nie wykonuje programu z
>> ram-u
>>  > (architektura Harvard) więc żadnej kopi nie uruchomi.
>>
>> Co prawda dotyczy to statycznego, ale tym gorzej dla Ciebie.
> Co gorzej, odpowiedz na pytanie, czy avr wykona program z ramu?
>

Janusz,
sorry, ale dzielnie bronisz pozycji nie do obrony.

Kluczowe słówko: 'bo'.
Kwestia nie wykonywania z RAMu była użyta tylko jako wytłumaczenie
dlaczego do głównej tezy, że program wygenerowany z templates nie
pójdzie w avr.
Chodzi o prawdziwość/nie prawdziwość tej głównej tezy a nie użytego
argumentu za nią.

Skojarzenie....
Kiedyś (+- 1990) potrzebowaliśmy aby 8751 'wykonywał' program ze swojego
RAMu (128 bajtów).
Zrealizowaliśmy to jako interpreter programu pisanego w opracowanym
przez nas języku na bazie języka Forth (opiera się na odwrotnej notacji
Polskiej).
Interpretacja pojedynczego rozkazu średnio zajmowała 10us (rozkaz
maszynowy zajmował 1us).

Oczywiście brat napisał ten interpreter ale wszystkie programy w tym
Forth pisałem ja. Czyli każdy z programów musiał być zapisany na mniej
niż 128 bajtach (no bo jeszcze stos procesora i dane).

To były programy do programowania poszczególnych GALi różnych
producentów (każdy rozmiar GALa * każdy producent to osobny program) i
do programowania poszczególnych EEPROMów szeregowych (I?C, SPI,
microWire i kilku innych).
W ten sposób załatwiliśmy to, że mogliśmy rozszerzać gamę programowanych
elementów bez konieczności upgradeowania oprogramowania (w tamtym czasie
konkurencyjne programatory wymagały w tym celu odesłania do producenta).

Bardzo dokładnie musiałem panować nad RAMem - gdy program ładował
pierwszy blok danych do programowania to zazwyczaj niszczył swój
początek. Rozmiar używanego w danym programie bloku danych dobierałem
tak, aby zniszczenie nie sięgnęło głównej pętli.
Liczba bajtów potrzebna na stos procesora zależała od treści mojego
programu (ile zagłębień pętli) i uwzględniałem to w poczatkowym
ustawieniu wskaźników.

Wiem, że już kiedyś na p.m.e to pisałem, ale siła skojarzenia z "nie
wykonuje programu z ram-u".
P.G.

do góry