-
241. Data: 2022-07-20 10:08:05
Temat: Re: Rynek pracy STM32
Od: Dawid Rutkowski <d...@w...pl>
środa, 20 lipca 2022 o 04:27:18 UTC+2 a...@m...uni.wroc.pl napisał(a):
> Janusz <j...@o...pl> wrote:
> > W dniu 2022-07-19 o?18:26, Dawid Rutkowski pisze:
> > > wtorek, 19 lipca 2022 o?16:57:56 UTC+2 Mateusz Viste napisa?(a):
> > >> 2022-07-19 o 07:44 -0700, Dawid Rutkowski napisa?:
> > >>> To jak taki fajny ten SVN, bez wad, to po co Linus pisa? gita?
> > >> To jest pytanie z serii "skoro mam traktor, to po co mi samoch?d".
> > >> svn i git to dwa VCSy, ale rozwi?zuj?ce nieco inne klasy problem?w.
> > >
> > > Tote? w?a?nie o to pytam - czym si? r??ni??
> > > I jak bardzo w og?le mog? si? r??ni? od siebie systemy kontroli wersji?
> > > Wiadomo, ?e podstawowym pytaniem jest "co si? optymalizuje?" i ?e si?
> > > nie da mie? wszystkiego (dlatego w?r?d programist?w jest tak ma?o kobiet -
jedynie
> > > kobieta z umys?em m??czyzny, typu Maria Sk?odowska, jest w stanie to
zrozumie?),
> > > no ale na ile r??nych sposob?w mo?na zrobi? to samo?
> > > Mo?e naiwnie pytam, bo w sumie te? wci?? czekam na satori - czyli zrozumienie,
> > > po co w og?le takiego oprogramowania u?ywa?, w sensie zysk?w, bo ?e koszty b?d?
to nie ulega w?tpliwo?ci.
> > Nie przejmuj si?, mnie te? nie przekona? ani on ani poprzednicy, jak
> > pracujesz sam nad kodem to i sam sobie panujesz nad kolejnymi wersjami.
> > Co innego praca zespo?owa i chyba g??wnie w takiej pracy sie to uzywa,
> > ale dla np mnie jest strasznie upierdliwe.
> >
> > >
> > > A tendencj? rozs?dnego cz?owieka jest szukanie rozwi?zywania istniej?cych
problem?w,
> > > a nie hipotetycznych (to to podczas analizy i projektu).
> > >
> > > Bo to, ?e VCS pomo?e mi w tym, ?e sobie z czym? eksperymentuj?, a potem to albo
odrzucam albo
> > > wrzucam do trunka, to mi na plaster - to samo robi si? po prostu kopiuj?c
katalog
> > > (zak?adam ?e katalog jest na tak samo chronionym komputerze w sensie
redundancji itp. co VCS).
> > > Ewentualnie mog?oby co? da?, gdybym na raz eksperymentowa? z kilkoma rzeczami,
> > > ale dla bezpiecze?stwa chcia?, by sprawdza? jedn? na raz - a potem ?eby VCS
automagicznie
> > > po??czy? mi trzy takie ga??zie w sp?jny projekt b?d?cy wersj? wyj?ciow? z
dodanymi tymi 3 nowymi funkcjonalno?ciami.
> > > Da si? tak?
> > Dostaniesz tak? kaszk? mann? ?e tydzie? b?dziesz dochodzi? co jest gdzie :)
> >
>
> 90% funkcji systemu kontoroli wersjo mozna uzystkac kopiujac katologi:
> robisz sobie glowny katalog na wersje w nim podkatalog dla kazdej
> wersji. Co w takim razie daje system kontroli wersji w sytuacji
> pojednyczego programisty:
> - oszczedniejszy zapis danych
> - mniejsze ryzyko przpadkowych bledow (np. bledna nazwa katalogu
> moze spowodowac nadpisanie starszej wersji zmiast utworzenia
> nowej)
> - wygoda: system kontroli wersji pamieta parametry ktore podales
> i moze je uzyc. Zamiast kilku polecen dla jednej logicznej
> operacji wystarcza jedno polecenie.
>
> Co do oszczedniejszego zapisu: w jedny z moich projektow repozytorium
> git-a zajmuje 65 M. Same zrodla to 25 M. Jest ok. 3000 wersji,
> co przy naiwnej metodzie "katalog na wersje" daloby rzedu 75 G
> (projekt zaczal od juz istniejacych zrodel, sporo kodu bylo
> usowane tak ze rozmiar wczesnych wersji jest podobny od obecnego).
> Dla oszczednosci miejsca zrodla moznaby kompresowac, wtedy dostane
> ok 4M, do 3000 wersji to ciagle rzedu 12 G na calosc. Przy
> skompresowaych zrodlach wiekszosc operacji wymagaloby najpierw
> dekompresji, wiec jest dodatkowa niewygoda.
>
> Zamiast katalogow mozna by pamietach diffy (roznice) miedzy
> wersjami. Wtedy powierzchia dysku do pamietania wersji
> bylaby mniejsza (ale prawie na pewno wieksza niz 40 M narzutu
> git-a), ale odtworzenie wersji byloby klopotliwe.
>
> Ja "powazniesze" projekty trzymam w systemie kontrolii wersji.
> Ale nie jestem fanatykim, kilkadzisiat (czy moze kilkaset)
> drobnych programikow jest poza system kontroli wersji.
> Jak nie robisz niczego powaznego to system kontroli wersji
> niewiele pomaga. Tzn. system kontroli wersji zacheca
> do porzadku i zmniesza opory psychiczne w stylu "czy warto
> zapamietac ta wersje" (w system kontroli wersji "koszt"
> kolejnej wesji jest maly).
>
> Jak ktos jest z natury nieporzadny to system kontroli
> wersji mu nie pomoze, taki czlowiek bedzie "walczyl"
> z systemem albo nie bedzie go w ogole uzywal. Jak
> ktos jest bardzo porzadny to moze dac sobie rade bez
> systemu kontroli wersji (zakladajac ze miejsce na dysku
> nie bedzie problemem), ale system kontroli wersji to
> wygodniejsza praca. Przecietnym ludziom system kontroli
> mocno pomaga...
A jakie są przykłady użyteczności trzymania 3000 wersji?
-
242. Data: 2022-07-20 10:20:46
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 20/07/2022 09:51, Janusz wrote:
> Bo to była maszyna stanów, czyli jedna zmienna określa stan i jest
> wielokrotnie w petli zmieniana.
Jeśli jest tylko zmieniana i nigdy nie czytana, to kompilator ma prawo w
pełni ją zoptymalizować do return 7.
Masz buga gdzie indziej, "rozwiązałeś" problem używając głupiego volatile.
-
243. Data: 2022-07-20 10:21:49
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 20/07/2022 09:55, Janusz wrote:
>> Przyjemności później. Teraz pytanie co z tym Harvardem, co miał nie
>> działać z czymśtam.
> Kodem dynamicznym
W przypadku polimorfizmu statycznego i dynamicznego, nie ma "kodu
dynamicznego", są indirect call.
Nie chcesz mi chyba powiedzieć, że cała drama o to, że pomyliłeś dwa
rózne pojęcia dynamiczności?
-
244. Data: 2022-07-20 10:52:20
Temat: Re: Rynek pracy STM32
Od: Janusz <j...@o...pl>
W dniu 2022-07-20 o 10:20, heby pisze:
> On 20/07/2022 09:51, Janusz wrote:
>> Bo to była maszyna stanów, czyli jedna zmienna określa stan i jest
>> wielokrotnie w petli zmieniana.
>
> Jeśli jest tylko zmieniana i nigdy nie czytana, to kompilator ma prawo w
> pełni ją zoptymalizować do return 7.
>
> Masz buga gdzie indziej, "rozwiązałeś" problem używając głupiego volatile.
Szkoda słów.
--
Janusz
-
245. Data: 2022-07-20 10:54:18
Temat: Re: Rynek pracy STM32
Od: Janusz <j...@o...pl>
W dniu 2022-07-20 o 10:21, heby pisze:
> On 20/07/2022 09:55, Janusz wrote:
>>> Przyjemności później. Teraz pytanie co z tym Harvardem, co miał nie
>>> działać z czymśtam.
>> Kodem dynamicznym
>
> W przypadku polimorfizmu statycznego i dynamicznego, nie ma "kodu
> dynamicznego", są indirect call.
>
> Nie chcesz mi chyba powiedzieć, że cała drama o to, że pomyliłeś dwa
> rózne pojęcia dynamiczności?
Nie to oznacza tylko tyle że w przypadku takich procków jak avr cały ten
polimorfizm jest gówno wart.
--
Janusz
-
246. Data: 2022-07-20 11:33:09
Temat: Re: Rynek pracy STM32
Od: Piotr Gałka <p...@c...pl>
W dniu 2022-07-20 o 04:27, a...@m...uni.wroc.pl pisze:
> Zamiast katalogow mozna by pamietach diffy (roznice) miedzy
> wersjami. Wtedy powierzchia dysku do pamietania wersji
> bylaby mniejsza (ale prawie na pewno wieksza niz 40 M narzutu
> git-a), ale odtworzenie wersji byloby klopotliwe.
Nigdy nie myślałem o przechowywaniu historii poszczególnych projektów.
Lata temu zrobiłem sobie system backupowania polegający na tym, że
zapisuje się zip wszystkiego, a potem codziennie zapisywane są tylko
pliki zmodyfikowane od ostatniego zapisania wszystkiego. Gdy te
codzienne pliki robią się coraz większe to któregoś dnia znów robię
zapis wszystkiego i potem codzienne znów są małe.
Odtworzenie stanu z dnia nie jest wcale kłopotliwe - rozpakowuję ostatni
cały przed tym dniem i na to rozpakowuję ten z danego dnia.
Stan będzie różnił się od faktycznego stanu z tego dnia o pliki, które w
międzyczasie były usunięte. Ale to raczej nie przeszkadza.
Mój plik wszystkiego teraz to 140M. Wszystko to tak ostatnie 20 lat.
Starsze kiedyś trafiły do 'archiwum' i wypadły z tego systemu.
Jak (po 3..5 miesiącach) te codzienne urastają do kilkunastu M to znów
robię zapis wszystkiego.
Zaletą dla mnie jest, że za jednym zamachem mam załatwione wszystkie
typy plików, które w czasie pracy modyfikuję. Nie tylko kody programów,
ale też wszystko z KiCada, PSpie'a i mnóstwo *.ods bo najczęściej w tej
formie robię sobie różne notatki czy obliczenia.
P.G.
-
247. Data: 2022-07-20 12:12:49
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 20/07/2022 10:54, Janusz wrote:
>> W przypadku polimorfizmu statycznego i dynamicznego, nie ma "kodu
>> dynamicznego", są indirect call.
>> Nie chcesz mi chyba powiedzieć, że cała drama o to, że pomyliłeś dwa
>> rózne pojęcia dynamiczności?
> Nie to oznacza tylko tyle że w przypadku takich procków jak avr cały ten
> polimorfizm jest gówno wart.
Czyli nie masz bladego pojęcia jak to działa, jednak.
Przedstawiłem Ci działajacy kod uzywajacy wywołań wirtualnych, na AVR,
używający polimorfizmu dynamicznego z metodami wirtualnymi, bez żadnych
sztuczek, goły C++.
Rozimiem, że Twoja ignorancja w temacie C++ jest już na etapie negowania
faktów?
Bo u mnie miga diodą.
-
248. Data: 2022-07-20 12:14:14
Temat: Re: Rynek pracy STM32
Od: heby <h...@p...onet.pl>
On 20/07/2022 10:52, Janusz wrote:
>>> Bo to była maszyna stanów, czyli jedna zmienna określa stan i jest
>>> wielokrotnie w petli zmieniana.
>> Jeśli jest tylko zmieniana i nigdy nie czytana, to kompilator ma prawo
>> w pełni ją zoptymalizować do return 7.
>> Masz buga gdzie indziej, "rozwiązałeś" problem używając głupiego
>> volatile.
> Szkoda słów.
Dokładnie. Szkoa słów na zrzucanie na kompilator problemów, których nie
potrafisz zrozumieć i "rozwiązujesz" używając iditycznego narzędzia
które powstało po coś zupełnie innego.
-
249. Data: 2022-07-20 12:39:01
Temat: Re: Rynek pracy STM32
Od: Cezar <c...@t...pl.invalid>
On 20/07/2022 10:33, Piotr Gałka wrote:
> W dniu 2022-07-20 o 04:27, a...@m...uni.wroc.pl pisze:
>
>> Zamiast katalogow mozna by pamietach diffy (roznice) miedzy
>> wersjami. Wtedy powierzchia dysku do pamietania wersji
>> bylaby mniejsza (ale prawie na pewno wieksza niz 40 M narzutu
>> git-a), ale odtworzenie wersji byloby klopotliwe.
>
> Nigdy nie myślałem o przechowywaniu historii poszczególnych projektów.
> Lata temu zrobiłem sobie system backupowania polegający na tym, że
> zapisuje się zip wszystkiego, a potem codziennie zapisywane są tylko
> pliki zmodyfikowane od ostatniego zapisania wszystkiego. Gdy te
> codzienne pliki robią się coraz większe to któregoś dnia znów robię
> zapis wszystkiego i potem codzienne znów są małe.
>
> Odtworzenie stanu z dnia nie jest wcale kłopotliwe - rozpakowuję ostatni
> cały przed tym dniem i na to rozpakowuję ten z danego dnia.
> Stan będzie różnił się od faktycznego stanu z tego dnia o pliki, które w
> międzyczasie były usunięte. Ale to raczej nie przeszkadza.
>
> Mój plik wszystkiego teraz to 140M. Wszystko to tak ostatnie 20 lat.
> Starsze kiedyś trafiły do 'archiwum' i wypadły z tego systemu.
> Jak (po 3..5 miesiącach) te codzienne urastają do kilkunastu M to znów
> robię zapis wszystkiego.
>
> Zaletą dla mnie jest, że za jednym zamachem mam załatwione wszystkie
> typy plików, które w czasie pracy modyfikuję. Nie tylko kody programów,
> ale też wszystko z KiCada, PSpie'a i mnóstwo *.ods bo najczęściej w tej
> formie robię sobie różne notatki czy obliczenia.
> P.G.
Zacząłem się rozpisywać na temat zalet pracy pod VCS ale w sumie jeżeli
trzymanie wszystko w plikach spełnia Twoje wymagania to po co psuć.
Ja wcześnie przerzuciłem się pierw na self-hosted SVN a po kilku latach
na Git. Głownie bo nie chciało mi się utrzymywać tego serwera z SVN a
bitbucket oferował mi cały Git za darmoszkę - włącznie z prywatnymi
repo. Kilka lat temu Github tez zaczął oferować prywatne repo za darmo
(kiedyś darmowe były tylko publiczne)
To że mogę powiedzieć po co została dorzucona dana linijka kodu jest dla
mnie wielką zaletą bo moja pamięć jest dość słaba i cięzko jest
zapamiętać "co autor miał na myśli" 5-10 lat temu.
c.
-
250. Data: 2022-07-20 13:40:36
Temat: Re: Rynek pracy STM32
Od: RoMan Mandziejewicz <r...@p...pl.invalid>
Hello heby,
Wednesday, July 20, 2022, 12:14:14 PM, you wrote:
>>>> Bo to była maszyna stanów, czyli jedna zmienna określa stan i jest
>>>> wielokrotnie w petli zmieniana.
>>> Jeśli jest tylko zmieniana i nigdy nie czytana, to kompilator ma prawo
>>> w pełni ją zoptymalizować do return 7.
>>> Masz buga gdzie indziej, "rozwiązałeś" problem używając głupiego
>>> volatile.
>> Szkoda słów.
> Dokładnie. Szkoa słów na zrzucanie na kompilator problemów, których nie
> potrafisz zrozumieć i "rozwiązujesz" używając iditycznego narzędzia
> które powstało po coś zupełnie innego.
Idźcie sobie na pl.comp.programming z tą pyskówką, bardzo proszę.
--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)