🚀 go-pugleaf

On 23.08.2021 16:04, Robert Magdziarz wrote:

>> Czasem pomaga kompilacja kodu z flagami -Wall albo -Wextra - może pomoże wskazać miejsce w kodzie, w którym jest jakieś podejrzane użycie języka.
> dzięki, spróbuję; czy polecasz jakieś inne narzędzia? (nie jestem zaawansowany w C++, na co dzień programuję w PHP).

Dołóż do listy jeszcze użycie sanitizerów:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

I koniecznie logowanie poszczególnych przetwarzania danych na 
poszczególnych etapach, to jest chyba najlepsza metoda na rzadkie 
przypadki (pod warunkiem, że wcześniej czy później uda się powtórzyć błąd).

> Jak podejść do problemu, jakiej strategii użyć? Co mogę zrobić poza asercjami? Debugowanie nie ma sensu bo błąd występuje zbyt rzadko.

valgrind

Może problem w sensie niespodziewanych wyników występuje rzadko, ale być może niewłaściwe operacje (odczyt zmiennych przed zapisem, użycie zaraz po zwolnieniu bloku, itp.) są znacznie częstsze, tylko zwykle nie dają złych objawów. Valgrind pomaga takie sytuacje wykryć. Przy okazji wpływa na upływ czasu w programie, co może zarówno utrudnić jak i ułatwić szukanie błędów związanych z wielowątkowością. W każdym razie - jego użycie nic nie boli, puszcza się to tak (Linux):

$ valgrind ./mojprogram

Są jeszcze różne fajne opcje, nie pamiętam. Ale to jedno z najzacniejszych narzędzi diagnostycznych, ever.

-- 
Maciej Sobczak * http://www.inspirel.com

On 23/08/2021 20:51, Maciej Sobczak wrote:
> valgrind [...]

W tym przypadku koniecznie --track-origins=yes

wtorek, 24 sierpnia 2021 o 10:12:13 UTC+2 Maciek Godek napisał(a):
> Zacząłbym od tego, że w momencie zapisywania pliku cache.xml tworzyłbym również plik z logami (może być nawet zapis na stderr, który byłby zrzucany do jakiegoś pliku) i wówczas, jeżeli bym zobaczył, że plik jest zepsuty, to bym sobie dogłębnie te logi przeanalizował.

Zrobiłem makro TRACE(...) ale problem jest w tym, że nie udaje mi się odtworzyć błędnego przypadku, występuje zbyt rzadko i nie wiem od czego zależy.

Pomyślełem, że skoro problem strs="" występuje tak rzadko to mogę nic nie zapisywać do cache.xml gdy wyliczone strs="". Program raz na jakiś czas będzie działał wolniej, ale będzie nadal produkował poprawne wyniki, więc nie jest to jakaś poważna wada. Chyba tak zrobię.

On 28/08/2021 21:46, Maciej Sobczak wrote:
>> automatu ale lepiej żeby nikt nie musiał nigdy do nich zaglądać.
> A czemu nie zaglądać? Bo wstyd patrzeć?

Bo miejsca na dysku szkoda.

> Przecież tam jest dokładnie to samo, co w historii commitów gita. Ten sam syf.

Jesli kto ma syf.

> Właśnie o to chodzi. Git może dać inną prezentację, ale informacja jest ta sama.

Nie jest ta sama. Ogólnie VCS dorobiły się znaczących usodkonaleń od lat 
60-tych. Może warto ponownie sprawdzić, co nowego w informtyce, wydajesz 
się być jakiś odmrożony z czasów Elvisa. Współczesne VCS pomagają w 
nawigacji zmian w kodzie źródłowym. Twóje ZIPy z porównywarką nie mają 
nawet śladowej funkcjonalnosci tego typu.

> A jak się rozpakuje zipa w osobnym katalogu, to mamy równocześnie dostępne pliki z jednego punktu w historii projektu.

A jak się zrobi checkout...

Ale moment, ludzie nie są aż tak głupi. Najzwyczajniej robią switch. 
Zajmuje to 2-3 sekundy. Albo check for modifications. Albo blame. Zależy 
co chcą znaleźć.

> Jeśli ktoś korzysta z nawigacji w IDE, to ta nawigacja działa.

Zupełnie jak w VCS.

> Jeśli w projekcie są media, to można je zobaczyć/przesłuchać.

Zupełnie jak w VCS.

> Itd. To jest komfort pracy daleko wykraczający poza tekstowy diff, nawet taki kolorowy.

Oczywisćie, to komfort daleko wykraczajacy poza pojęcie komfotu. 
Nazwałbym to mordęgą, rozpakowywanie 70 ZPIów, aby stwierdzić kiedy 
zmieniła się linika numer 10345 w pliku main.cpp. U mnie zajmuje to sekundy.

> A jak mam robić git checkout do osobnego katalogu, żeby w pełnym komforcie obejrzeć różnice (niekoniecznie tekstowe)

Na SVN oglada je bez zrzucania plików lokalnie. Zdalnie. Co powiesz na 
taką innowację z cuting edge VCS? Komfort nawet pełnieszy - jest np. 
blame. Zawze możesz sobie zrobić checkout, choć nie pamiętam, abym tego 
kiedykowleik miał potrzebę użyć w celu porównania czegokolwiek.

>, to to jest ten moment, w którym wartość dodana lokalnego gita wynosi epsilon.

Najzwyczajniej nigdy nie pracowałeś w jakimkolwiek projekcie z VCS. 
Nawet git, którego nie lubie nawet bardziej niż svn, jest <bład: 
dzielenie przez zero> lepszy od ZIPów.

> Git służy do synchronizacji zmian i tylko tam ma wartość dodaną. Jak jest jedno "repo", to git nic nie wnosi.

Nie pojmujesz jak wygląda typowy flow pracy w zespole. Nic dziwnego, że 
gadasz głupoty. Systemy kontroli wersji to nie system archiwizacji 
wersji. Tylko *kontroli*. To coś innego.

> Git ma jeszcze jedną smutną wadę. Otóż jego historia zmian ciągle rośnie (chociaż jej użyteczność wcale nie, bo zwykle potrzebne jest tylko jakieś ostatnie okno czasowe a nie całość) - a backup takiego repo staje się z czasem coraz bardziej uciążliwy.

Zastanów się jak bardzo uciązliwy jest backup repo SVN majacego 15 lat i 
30GB kodu źródłowego w trunku + ze sto tyś branchy. Czy tak bardzi 
uciążliwy, że siedzi nad tym biblion ludzi przepisujac repo na kartki, 
czy może jednak technologia ma rozwiązanie pozwalajace jakos to ogarnąć 
automatycznie i bez awari przez ten cały czas? By chyba nie myslisz, że 
ktoś to pakuje do ZIPa i nagrywa na CDki...

> Na SVN oglada je bez zrzucania plików lokalnie. Zdalnie. [...]
> Nie pojmujesz jak wygląda typowy flow pracy w zespole.

Czyli gadamy sobie na różne tematy. Od jakiegoś czasu rozważamy temat użytkowania VCS *lokalnie* i *jednoosobowo*.
Pomyliłeś dyskusje, stąd nieporozumienie.

> Systemy kontroli wersji to nie system archiwizacji 
> wersji. Tylko *kontroli*. To coś innego.

To też ciekawe rozróżnienie. Bo ja dodatkowo jeszcze odróżniam "control" od "tracking". Ale nie ma to wielkiego znaczenia przy pracy *lokalnej* i *jednoosobowej*.

> Zastanów się jak bardzo uciązliwy jest backup repo SVN majacego 15 lat i 
> 30GB kodu źródłowego w trunku + ze sto tyś branchy.

Każdy problem ma swoje rozwiązanie, odpowiednim kosztem. Pytanie, jaki problem chcemy mieć. Czasem racjonalnie można wybrać mniejszy i o tych wyborach tutaj rozmawiamy.

-- 
Maciej Sobczak * http://www.inspirel.com

On 29/08/2021 20:57, Maciej Sobczak wrote:
>> Na SVN oglada je bez zrzucania plików lokalnie. Zdalnie. [...]
>> Nie pojmujesz jak wygląda typowy flow pracy w zespole.
> Czyli gadamy sobie na różne tematy. Od jakiegoś czasu rozważamy temat użytkowania VCS *lokalnie* i *jednoosobowo*.

Dokładnie tak. Kiedy pracujesz zespole z uzyciem VCS, jego przydatnośc 
okazuje się tak duża, że stosujesz go w zyciu "prywatnym". Osobicie mam 
postawiony SVN w domu. Do małych, duperelowatych projekcików stosuje 
dokładnie te same metody pracy, co w zespole. Ułatwiają życie. Nie tylko 
mi. Kilka osób z mojego otoczenia postawiło sobie różne VCS w domu, 
wliczając to trzymanie tam prywatnych programów, list zakupów, podań do 
spółdzielni, telefonów do lekarzy. Niektórzy nawet przećwiczyli 
domowników w ich używaniu. Masz dwa wyjścia: albo to idioci, albo ZIPy 
są idityczne.

Z powodu mozliwoci stworzenia repozytorium jednym kliknieciem, nie ma 
nawet argumentu że to trudne. To trywialne. Dlaczego więcenie używać? 
Nie wszyscy są tak głupi, aby uwierzyć w "traumatyczne robienie branchy 
w SVN".

Postawienie SVNa na apache2 jest tak proste, że aż wstydliwe, choć 
trzeba poza klikaniem wciskać klawisze. Raz na parę lat. Faktycznie, 
dramat. Stworzenie repo w katalogu na dysku lokalnym to 1 kliknięcie. 
Nie ma argumentu przeciwko.

> Pomyliłeś dyskusje, stąd nieporozumienie.

To nie jest nieporozumienie. Najzwyczajniej nie rozumiesz po co komu 
VCS. Wniosek z tego: nie pracowałeś w zespole. Inaczej nawyki 
przenikneły by do częsci prywatnej. Czy to dupna aplikacja czy nastepny 
program do rysowania choinki na zaliczenie - w obu przypadkach VCS 
będzie lepszym wyborem niż idityczne ZIPy.

>> Systemy kontroli wersji to nie system archiwizacji
>> wersji. Tylko *kontroli*. To coś innego.
> To też ciekawe rozróżnienie. Bo ja dodatkowo jeszcze odróżniam "control" od "tracking". Ale nie ma to wielkiego znaczenia przy pracy *lokalnej* i *jednoosobowej*.

Tracking/conrol samego siebie jest równie ważny co tracking/control 
kolegów. Po kilku latach nie ma żadnej różnicy kto napisał daną linijkę 
kodu. Ważne, że wiadomo po co ją napisano, kiedy ją napisano i co 
zmieniono przy okazji. Ta wiedza, pod warunkiem nie posiadania "syfu", 
jest w repozytorium VCS. Ale nie ma jej w ZIPach. w ZIPach nic nie ma 
poza archiwami i skranie nieskuteczną metodą prowadzenia śledztwa.

>> Zastanów się jak bardzo uciązliwy jest backup repo SVN majacego 15 lat i
>> 30GB kodu źródłowego w trunku + ze sto tyś branchy.
> Każdy problem ma swoje rozwiązanie, odpowiednim kosztem.

Zaczynasz bredzić. Kosztem? Zastanówmy się: firma ma koszt w postaci 
sensownego NASu i backupów. W domu stosujesz ze dwa skrypty do 
automatycznego backupu repo np. na google drive. Czy tu czy tu, problem 
jest albo w jakosci hardewareowych rozwiązań, albo w sprycie usera. Oba 
mają za zadanie utrzymać kilka plików w rozsądnym stanie. Potrafimy 
utrzymywać pliki w rozsądnym stanie od lat 80, co najmniej. Ba, dostępne 
jest to dla domowego usera prawie za darmo. To jest ten "odpowiedni 
koszt" po którym wszystkim mają wypoaść pety z gęby z wrażenia jakie 
drogie jest utrzymanie w domu SVN/git/whatever?

> Pytanie, jaki problem chcemy mieć.

Posiadanie setki paczek ZIPa to *jest* problem sam w sobie. Przy nim, 
duperela jak backup repozytorium, jest nieistotna. SVN nie ma żadnych 
wad, o których w tym wątku bredzono. Ma inne, które nie padły. Wniosek z 
tego że ludzie piszą o problemach, których sami nie doświadczyli. Za to 
pojawia się ZIP, który nie ma śladu zalety, same wady i stawia się go w 
alternatywie dla roziązań milion razy lepszych, prostzych i 
funkcjonalnych. Piłeś? Nie pisz.

> Czasem racjonalnie można wybrać mniejszy

ZIPy nie są *alternatywą* do czegokolwiek. Go gówno. Oferujesz do 
zastosowań domowych gówniany sposób "kontroli" wersji i tylko mniej 
gówniany sposób "archiwizacji", mimo że argumenty o kłopotliwości 
przeciętnego VCS są najzwyczajniej zmyślonym bredzeniem osoby która nie 
ma pojęcia jak działają w praktyce, czy to dużej firmy czy przeciętnego 
Janusza programowania. ZIPy nie są alternatywą. To najgorsze gówno w 
jakie można wdepnąć jako programista. Najzwyczajneij wszytkie inne 
rozwiązania są o kilometr dalej w rozwoju i wygodzie. Uznałbym że to 
prowokacja, ale coś czuje, że nie tym razem.

2021-08-29 o 23:26 +0200, heby napisał:
> Postawienie SVNa na apache2 jest tak proste, że aż wstydliwe, choć 
> trzeba poza klikaniem wciskać klawisze.

Rozumiem, że stawiasz na apache2. Zapytam, bom ciekaw - dlaczego?
Testowałem onegdaj kilka sposobów instalacji svn, i w wariancie z
apache nie udało mi się znaleźć żadnej wartości dodanej w porównaniu do
ssh, za to trzeba męczyć się z niepotrzebnym, publicznym httpd.

No chyba, że z jakichś (innych) powodów masz już swoje PKI i we
wszelkich interfejsach uwierzytelniasz użytkowników za pomocą osobowych
x509. Czy to ten przypadek?

Mateusz

On 30/08/2021 09:26, Mateusz Viste wrote:
>> Postawienie SVNa na apache2 jest tak proste, że aż wstydliwe, choć
>> trzeba poza klikaniem wciskać klawisze.
> Rozumiem, że stawiasz na apache2.

Zależy. Adhoc - w pliku. Czasami stawiam szybkie repo do jakiegoś 
jednorazowego projektu.

> Zapytam, bom ciekaw - dlaczego?

Ponieważ mam do niego dostęp przez VPNa. I cześciowo z powodu 
przyzwyczajenia, ponieważ miałem tak "od zawsze" czyli od jakiś nastu 
lat, a kiedyś byłem zmuszo ny do pracy z tym repo bez VPNa, przez 
web-proxy. Dzisiaj nie mam racjonalnego argumentu dlaczego apache2.

> Testowałem onegdaj kilka sposobów instalacji svn, i w wariancie z
> apache nie udało mi się znaleźć żadnej wartości dodanej w porównaniu do
> ssh, za to trzeba męczyć się z niepotrzebnym, publicznym httpd.

Wiec nie ma śladu potrzeby, abyś się z tym męczył.

> No chyba, że z jakichś (innych) powodów masz już swoje PKI i we
> wszelkich interfejsach uwierzytelniasz użytkowników za pomocą osobowych
> x509. Czy to ten przypadek?

Nie, wyłacznie przyzwyczajenie. Zauważ, że nigdzie go w dyskusji nie 
preferuję. Przecięny klikacz może sobie stworzyć puste repo 1 
kliknieciem w Tortoise i pozamiatane. DAV/mod_svn/apache2 są pokazane 
tylko jako kontrast do hasła "trzeba sie namęczyć aby postawić serwer". 
Nie trzeba. O ile pamiętam to 1 apt-get, dwa pliki konfiguracyjne, ze 3 
polecenia w konsoli i bangla. Postawienie serwera svn na apache2 jest 
najtrudniejsze, ale dalej - absurdalnie proste.

2021-08-30 o 13:42 +0200, heby napisał:
> On 30/08/2021 13:20, Mateusz Viste wrote:
> > Przecież podałem: widząc edytor tekstowy o rozmiarze 400 MiB ściska
> > mnie pod żołądkiem.  
> 
> $ apt-get install kwrite
> [...] After this operation, 212 MB of additional disk space will be 
> used. [...]
> 
> To powoduje, dla odmiany, ból watroby?

No wiesz, dla kogoś kto nie ma Linuksa to w ogóle będzie kosmiczny
rozmiar, bo wyjdzie że musi doinstalować kilka GB rzeczy wszelakich :)

Najwyraźniej nie masz KDE, i package manager wlicza w te 212 MB
wszelkie jego niezbędne pliki. Sama aplikacja (kwrite) zajmuje jakieś
300 KiB. Być może Gnome ma jakiś odpowiednik, nie wiem. Ja "od zawsze"
działam pod KDE.

Mateusz

On 30/08/2021 14:50, Mateusz Viste wrote:
>> $ apt-get install kwrite
>> [...] After this operation, 212 MB of additional disk space will be
>> used. [...]
> No wiesz, dla kogoś kto nie ma Linuksa to w ogóle będzie kosmiczny
> rozmiar, bo wyjdzie że musi doinstalować kilka GB rzeczy wszelakich :)
> Najwyraźniej nie masz KDE

Dziekuję, nie przypuszczałbym.

>, i package manager wlicza w te 212 MB
> wszelkie jego niezbędne pliki. Sama aplikacja (kwrite) zajmuje jakieś
> 300 KiB.

Patrz: większośc apliakcji z Qt zajmuje kilka MB. Ale samo Qt wazy ze 100MB.

Każda apliakcja na Windowsie, bedzie miała własne Qt.

Efektem czego okienko z hello world będzie ważyło 102MB.

To już ból brzucha czy jeszcze nie?

A jak będzie ważyła 2MB na Linuxie to oznacza supremację Linuxa nad 
Windowsem, czy jeszcze nie?

A jak apt-get czasami dociągnie Qt a czasami nie to będę miał bóle 
pulsacyjne?

> Ja "od zawsze"
> działam pod KDE.

Stąd subiektywne i relatywistyczne bóle fantomowe na widok małej appki 
do pisania kodu którą dziwnym trafem używa bardzo dużo całkiem niezłych 
programistów. Może im boleści nie przeszkadzają.

2021-08-30 o 15:11 +0200, heby napisał:
> A jak będzie ważyła 2MB na Linuxie to oznacza supremację Linuxa nad 
> Windowsem, czy jeszcze nie?

Nie oszukujmy się, i bez tego sprawa jest przecież oczywista.
Powszechne użycie bibliotek współdzielonych to tylko kropla w oceanie
lepszości. Mimo tego, ktoś jest w stanie wydać notatnik dla Linuksa
o rozmiarze 400 MB. Co tam siedzi - cały system operacyjny wraz ze
sterownikami do wszystkich istniejących kart graficznych?

> Stąd subiektywne i relatywistyczne bóle fantomowe na widok małej
> appki do pisania kodu

W 2021 r. "mała apka" to 400 MB. Muszę zapamiętać, bo nie nadążam za
tym całym postępem. Boję się zapytać - gdzie zaczyna się "duża apka"?
Albo może zacznijmy od "normalnej apki", żebym miał czas się
przygotować.

Parę lat temu popełniłem to: http://atomiks.sf.net
Bardzo się wówczas przejmowałem, że przy wielkości 400 KiB mój remake
jest 2x większy od swojego pierwowzoru. Teraz widzę, że ludzkość jest
już na zupełnie innym etapie...


Mateusz

On 30/08/2021 16:02, Mateusz Viste wrote:
>> A jak będzie ważyła 2MB na Linuxie to oznacza supremację Linuxa nad
>> Windowsem, czy jeszcze nie?
> Nie oszukujmy się, i bez tego sprawa jest przecież oczywista.
> Powszechne użycie bibliotek współdzielonych to tylko kropla w oceanie
> lepszości. Mimo tego, ktoś jest w stanie wydać notatnik dla Linuksa
> o rozmiarze 400 MB. Co tam siedzi - cały system operacyjny wraz ze
> sterownikami do wszystkich istniejących kart graficznych?

Możesz sam sprawdzić. Polecam wersję portable dla windowsa, do analizy.

>> Stąd subiektywne i relatywistyczne bóle fantomowe na widok małej
>> appki do pisania kodu
> W 2021 r. "mała apka" to 400 MB.

No. To jakieś 2 promile miejsca na przeciętnym dysku. Coś koło 2gr jesli 
dobrze liczę ceny. Nie opłaca się.

> tym całym postępem. Boję się zapytać - gdzie zaczyna się "duża apka"?

Np. taki Windows. Ze 30GB tylko do tego, co Amiga miała w 512kB i to 
ROMu. I tu i tu kreski, prostokąty, obrazki, kursor myszki. Też nie 
rozumiem.

> Parę lat temu popełniłem to: http://atomiks.sf.net

Super. Ale nijak nie kojarzę aby ktoś coś mówił, że chce edytor 
pracujacy na CP/M z 48kB RAMu. Coś przeoczyłem? Już używacie komputerów 
z dyskami twardymi kupionymi w tym wieku?

Dzięki temu że nikt nie liczy pojedynczych bajtów masz apliakcję bogatą 
w ficzery i przenośną.

Jak będziesz chciał edytor w 64kB to da się go napisac, tylko nie 
będziesz go chciał używać.

> Bardzo się wówczas przejmowałem, że przy wielkości 400 KiB mój remake
> jest 2x większy od swojego pierwowzoru. Teraz widzę, że ludzkość jest
> już na zupełnie innym etapie...

Ludzkośc najzwyczajniej preferuje przenośnośc nad vendor-lockin i to 
jeden z powodów dla których taki kwrite waży 200MiB.

2021-08-30 o 16:16 +0200, heby napisał:
> Ludzkośc najzwyczajniej preferuje przenośnośc nad vendor-lockin i to 
> jeden z powodów dla których taki kwrite waży 200MiB.

Pomyliłeś się o kilkaset procent: zapomniałeś dodać bibliotek Xorg,
sterowników wszelakich, kernela Linux, narzędzi konsolowych, itd itp.
Nie bójmy się prawdy: kwrite to dobre 10 GB danych, jeśli nie
więcej. Szaleństwo.

Mateusz

On 30/08/2021 16:30, Mateusz Viste wrote:
>> Ludzkośc najzwyczajniej preferuje przenośnośc nad vendor-lockin i to
>> jeden z powodów dla których taki kwrite waży 200MiB.
> Pomyliłeś się o kilkaset procent: zapomniałeś dodać bibliotek Xorg,
> sterowników wszelakich, kernela Linux, narzędzi konsolowych, itd itp.
> Nie bójmy się prawdy: kwrite to dobre 10 GB danych, jeśli nie
> więcej. Szaleństwo.

Nareszcie! Witaj w prawdziwmym świecie Neo!

> Co złego jest w notatniku?

Za mało szpanerski. :-)
To, co najbardziej lubię w tych naszych dyskusjach, to tzw. dick-waving, czyli po polsku koncert szpanu, który się praktycznie zawsze pojawia. Niektórzy popisują się własnymi liczbami, a niektórzy cudzymi (tzn. tym, czego sami nie zrobili, ale w czym akurat chwilowo uczestniczą). Stąd te wszystkie tysiące plików, dziesiątki tysięcy linii w pliku, setki tysięcy branchów, miliony czegoś tam, wszystko w sekundę, itd. Nie ustaliliśmy jeszcze, ile kto ma komputerów w domu, ale jesteśmy blisko.
I tak za każdym razem.

Prawdą jest, że ludzie dzielą się na tych, których pasjonuje dzieło, na tych, których pasjonuje metoda oraz na tych, których pasjonuje narzędzie. I pewnie jeszcze parę podziałów jest ale te 3 są istotne teraz. Było o wyższości svna nad gitem, teraz jest o wyższości apache'a nad czymś tam, za chwilę będzie o wyższości Google Drive'a nad NASem, albo jeszcze coś. No i oczywiście, jeśli tej wyższości nie potwierdzasz, to na pewno jesteś nowy i nie masz pojęcia.

No i chyba wychodzi na to, że po prostu ci od dzieła nie dogadują się z tymi od narzędzi. Tak to widzę.

> Moja ewolucja pisania doprowadziła mnie do notatnika (kwrite) na 
> ekranie 15", tylko tak jestem w stanie skupić się na tym, co istotne. 

Skupiasz się na tym, co istotne? Szok. ;-)
Ale ekran polecam większy. To kwestia BHP.

-- 
Maciej Sobczak * http://www.inspirel.com

On 30/08/2021 20:44, Maciej Sobczak wrote:
> To, co najbardziej lubię w tych naszych dyskusjach, to tzw. dick-waving, czyli po polsku koncert szpanu

To co nazywasz szpanem jest tylko kontrargumentem do iditycznje 
argumentacje się tutaj pojawiają że cośtam wolno działa dla helloworlda. 
Ty dostrzegasz tylko kutasa, inni dostrzegną, że SVN nadaje się do 
dużych projektów. Zależy kto na co patrzy.

Równie żałosne jest szpanowanie hasłem "świat się myli, używam ZIPa a 
miast VCS bo jestem stary i taki strasznie wyważony w opiniach, że nic 
lepszego nie znalazłem".

> I tak za każdym razem.

Widocznie łajzy od "nie umiem mzrobićm brancham w svn to zrobiłem ZIPam 
bo tak gdzieś mnapisali", spotykane wszędzie na forach wszelakich, 
powtarzają się co chwilę. Dziwisz się że ktoś używający SVN na codzień 
zaczyna zielenieje ze złości na widok  bredni i kłamstw? Co odpowiesz 
komus, kto stwierdzi że klucze nie dokrecają śrubek, bo nie udało mu się 
dokręcić ani jednej, ale za to świetnie sprawdza się przecinak z młotkiem?

> Prawdą jest, że ludzie dzielą się na tych, których pasjonuje dzieło, na tych, których pasjonuje metoda oraz na tych, których pasjonuje narzędzie. I pewnie jeszcze parę podziałów jest ale te 3 są istotne teraz. Było o wyższości svna nad gitem, teraz jest o wyższości apache'a nad czymś tam, za chwilę będzie o wyższości Google Drive'a nad NASem, albo jeszcze coś.

Zdumiewające, że nawet nie pojąłeś o czym ta dyskusja. Nie o tym czy SVN 
jest lepszy czy gorsz od gita, apache wpadłu tu tylko jako kontrprzykład 
bredzenia. Dyskusja jest o oblesnych kłamstwach.

1) ludzie nie mający pojącia jak używać narzedzie, uważają że jest 
gorsze bo im nie działa(ło).

2) ludzie którzy uważają że wazniejsza jest sztuka nad narzedzie i 
imponują innym minimalizmem a'la notanik i zip, które o kant dupy 
potłuc. "Fałszywa skromność" ukrywająca przestarzałość metodyki i 
paniczny strach przed postępem.

> No i oczywiście, jeśli tej wyższości nie potwierdzasz, to na pewno jesteś nowy i nie masz pojęcia.

Wielu nowych ma większe pojęcie jak byś wydajniejszym i nie skupiać się 
na *narzędziach* bo używają tych właściwych a nie wszystki napierniczają 
młotkiem z tektury i jeszcze o zgrozo wszystkim polecają ten styl pracy.

Są ludzie którym do głowy by nie przyszło aby zrezygnować w VCS bo to 
jedno z kilku narzędzi jakich na codzień w domu i w pracy używają. Bez 
sentymwntu, miłości, pasji. Ot, narzędzie. Właśniwe do zadania. Na co 
komu gorze, bez zalet?

Nie padła ani jedna zaleta ZIPa na VCS mtóra miała by choć resztkę 
zdrowego rozsądku. Ani jedna. Same blotki. I autor tych bredni stara się 
teraz rozstawiać grupę po kontach i szufladkować ludzi do jakiś 
kategorii. Serio? SERIO?

"Szanowi hutnicy! Łatwiej by wam było jak by nie grzać tak bardzo tego 
pieca, chłodniej by było, może zamiast stali wodę wytapiajcie, jest 
chłodniejsza. A w ogóle to hutnicy dzielą się na trzy kategorie...."

> No i chyba wychodzi na to, że po prostu ci od dzieła nie dogadują się z tymi od narzędzi. Tak to widzę.

Ja to widzę że ci od narzędzi mają narzędzia a ci "od dzieła" mają cała 
teczkę młotków z tektury, ale za to potrafią nimi wyklepać dowolną 
furmankę a nie tylko jakieś samochody, mosty czy rakiety. Furmanki te są 
jednak turing-complete, więc nie różnią się niczym od rakiet.

Żeby nie było: stary jestem. Ale jeszcze nie na tyle, aby bredzić o 
wyższości zipa i potrzebie rynku dla IDE o rozmiarze 100kB. Może to 
kiedyś nastapi. Jeszcze nie teraz. Trzymam się, aby nie wpaść w taki absurd.

2021-08-30 o 11:44 -0700, Maciej Sobczak napisał:
> Ale ekran polecam większy. To kwestia BHP.

Jakieś szczegóły w tym temacie? 15" jakoś zawsze mi odpowiadało. W
sumie to i połowa tego by starczyła, ale z 15" mogę sobie dwa notatniki
postawić jeden przy drugim i to czasem przydatne jest.

Mateusz

> > Ale ekran polecam większy. To kwestia BHP.
> Jakieś szczegóły w tym temacie? 15" jakoś zawsze mi odpowiadało. W 
> sumie to i połowa tego by starczyła,

Połowa tego jest fajna jak się programuje w tramwaju. Albo w samolocie.
Ale na biurku to zwykle widuję u ludzi po dwa monitory +24". Mi pasuje jeden, nie trzeba głową kręcić, ale doceniłbym też 27".
I tak jest chyba zdrowiej dla oczu.

> ale z 15" mogę sobie dwa notatniki 
> postawić jeden przy drugim i to czasem przydatne jest.

Jak się robi systemy rozproszone, to wszystkiego jest razy N.

-- 
Maciej Sobczak * http://www.inspirel.com

2021-08-31 o 11:10 -0700, Maciej Sobczak napisał:
> Połowa tego jest fajna jak się programuje w tramwaju. Albo w
> samolocie.

Ale ja na codzień właśnie na połowie ekranu pracuję (prawej, lub
lewej). W samolocie czy pociągu też, ale to niczego nie zmienia.
Druga połowa ekranu służy ew. do trzymania okienka z svn i gcc oraz
czasem jakiejś konsoli ssh, ale to nic co koniecznie musiałoby tam być.

Połowa ekranu 15" pozwala mi na pracę z plikami o liniach długości 115
znaków. Ja tak długich linii raczej nie pisuję, a wręcz staram się by
były krótsze od 80 znaków. Tego posta zresztą też piszę właśnie na
połowie ekranu, druga w tym momencie do niczego nie służy, tylko
niepotrzebnie prąd zużywa.

> Ale na biurku to zwykle widuję u ludzi po dwa monitory +24".

Też widuję. I różne inne rzeczy widuję "u ludzi", ale co to za
argument? Ludzie to nie ja.

> Mi pasuje jeden, nie trzeba głową kręcić, ale doceniłbym też 27".

Też nie kręcę głową. Chyba, że czytając czasem usenet, ale wielkość
ekranu nie ma tu nic do rzeczy.

> I tak jest chyba zdrowiej dla oczu.

No więc mi właśnie o to całe "BHP" od początku chodzi. Jakieś normy w
tym temacie? Badania? Przepisy BHP? Tego jestem ciekaw - bo reszta to
zwyczajne przekomarzanie się o to kto jakie ma przyzwyczajenia (vide
dyskusje typu zip vs svn vs git...).

> Jak się robi systemy rozproszone, to wszystkiego jest razy N.

To przecież nie chodzi o to, ile czegoś jest. Ja mogę bez problemu mieć
i tysiąc plików naotwieranych, ale nie muszę (i nie chcę!) ich widzieć
jednocześnie. U mnie okienka potrafią nakładać się jedne na drugich, i
wybieram które chcę mieć na wierzchu alt+tabem. Myślałem, że to
powszechna sprawa.
Tak czy siak - lubię widzieć jedną rzecz i nic poza tym. Bo ja
niespecjalnie bystry jestem, i potrafię wykonywać tylko jedną czynność
w danym momencie. Jeśli widzę więcej okienek, kursorów czy migających
światełek to łatwo się rozpraszam i w efekcie nie robię nic. Być może
koledzy chwalący się wieloma ekranami wielkości kina domowego są po
prostu ode mnie inteligentniejsi (co by wiele tłumaczyło) i potrafią je
ogarnąć - tym lepiej dla nich. Ale jest jak jest i dla *moich* potrzeb
to co wcześniej opisałem jest dla mnie optymalne.

Mateusz

środa, 1 września 2021 o 13:41:15 UTC+2 Mateusz Viste napisał(a):
> 2021-08-31 o 11:10 -0700, Maciej Sobczak napisał: 
> > Połowa tego jest fajna jak się programuje w tramwaju. Albo w 
> > samolocie.
> Ale ja na codzień właśnie na połowie ekranu pracuję (prawej, lub 
> lewej). W samolocie czy pociągu też, ale to niczego nie zmienia. 
> Druga połowa ekranu służy ew. do trzymania okienka z svn i gcc oraz 
> czasem jakiejś konsoli ssh, ale to nic co koniecznie musiałoby tam być. 
> 
> Połowa ekranu 15" pozwala mi na pracę z plikami o liniach długości 115 
> znaków. Ja tak długich linii raczej nie pisuję, a wręcz staram się by 
> były krótsze od 80 znaków. 

Szczęściarz. Ja muszę pracować na ekranie 5", 
którego jedną trzecią zabiera mi klawiatura ekranowa, i jeżeli długość
linii dochodzi do 58 znaków, to już zaczyna być problemem.

2021-09-01 o 05:15 -0700, Maciek Godek napisał:
> Szczęściarz. Ja muszę pracować na ekranie 5", 

Dlaczego "musisz"?

Mateusz

środa, 1 września 2021 o 14:40:01 UTC+2 Mateusz Viste napisał(a):
> 2021-09-01 o 05:15 -0700, Maciek Godek napisał: 
> > Szczęściarz. Ja muszę pracować na ekranie 5",
> Dlaczego "musisz"? 

To miało być nawiązanie do skeczu Monty Pythona "Four Yorkshiremen" :)

Zasadniczo, piszę aplikację na telefon do pisania aplikacji na telefonie.
Oczywiście nie ma nade mną żadnego przymusu, poza "przymusem wewnętrznym"
czy też "chęcią", ale owo ograniczenie daje mi wartościową perspektywę
- korzystam z Emacsa odpalonego w aplikacji Termux (i to jest naprawdę
super, że na Androida jest coś takiego, i że można w tym budować pliki
.APK).

Poza tym mam też przećwiczoną pracę na laptopie z ekranem 12", i to też
był workflow, który się dla mnie sprawdzał - wtedy wyrobiłem w sobie taką
kulturę pracy, że mam pełnoekranowy terminal, a w nim sesję Emacsa
z ekranem podzielonym na pół - dla mnie jest ważne, żeby móc widzieć
dwie rzeczy na raz, i jak piszę na telefonie, to mi takiej możliwości brakuje.

No, ale poza tym w pracy mam dwa monitory chyba 24" + laptop z ekranem 15".
Co prawda do programowania nie widzę szczególnego zysku, ale
jak np. czytam schematy z projektami hardware'u albo jakąś bardziej
rozbudowaną dokumentację, to nigdy nie narzekam na nadmiar miejsca
na ekranach.

Inna rzecz, że jak kiedyś musiałem pisać w Visual Studio, to jeden monitor 15"
to faktycznie byłoby za mało, bo to jest zaprojektowane z myślą o dużych monitorach.

(Zresztą nawet na dwóch dużych monitorach nie pracowało mi się z tym zbyt przyjemnie)

2021-09-01 o 06:09 -0700, Maciek Godek napisał:
> Zasadniczo, piszę aplikację na telefon do pisania aplikacji na
> telefonie. Oczywiście nie ma nade mną żadnego przymusu, poza
> "przymusem wewnętrznym" czy też "chęcią", ale owo ograniczenie daje
> mi wartościową perspektywę
> - korzystam z Emacsa odpalonego w aplikacji Termux (i to jest naprawdę
> super, że na Androida jest coś takiego, i że można w tym budować pliki
> .APK).

Nic się zupełnie nie znam na pisaniu pod androida, kojarzę luźno że to
chyba Java (albo kiedyś tak było) i na tym kończy się moja wiedza.

Nie ma na to jakiegoś emulatora, który pozwalałby odpalać pisane
programy na PC?
Alternatywnie - może po ssh zalogować się z peceta na telefon aby pisać
na ekranie (i klawiaturze) PC, ale zapisując wszystko bezpośrednio na
telefonie?

Nie chcę oczywiście szukać Ci na siłę rozwiązań, ot dzielę się myślami
które mi przez głowę przechodzą, ale z pewnością masz to wszystko już
dawno przećwiczone.

Mateusz

środa, 1 września 2021 o 15:23:00 UTC+2 Mateusz Viste napisał(a):

> Nic się zupełnie nie znam na pisaniu pod androida, kojarzę luźno że to 
> chyba Java (albo kiedyś tak było) i na tym kończy się moja wiedza. 

Tak. Java, ale nie odpalana na JVM, tylko w autorskiej googlowskiej maszynie wirtualnej (Dalvik albo ART, w zależności od wersji)

> Nie ma na to jakiegoś emulatora, który pozwalałby odpalać pisane 
> programy na PC? 

Jest.

Domyślny workflow pisania apek na Androida to "Android Studio", darmowe IDE na bazie IntelliJ.
Na moim kompie było strasznie zasobożerne - przy 2GB RAM w ogóle nie dało się używać, więc dokupiłem do 4GB, i się dało "ledwo ledwo".
Pewnie gdybym miał taką wiedzę, jaką mam teraz, to bym mógł budować apki bezpośrednio z terminala, ale to też by się wiązało z dodatkowymi upierdliwościami (choćby konieczność kopiowania pliku na telefon)

Natomiast co do emulatora, to Android Studio dostarcza takie coś, tyle że z mojego doświadczenia symulowanie 10 palców za pomocą myszy jest raczej niedoskonałe

> Alternatywnie - może po ssh zalogować się z peceta na telefon aby pisać 
> na ekranie (i klawiaturze) PC, ale zapisując wszystko bezpośrednio na 
> telefonie? 

Tak też na pewno by się dało.
Tylko kwestia taka, że telefon mieści się w kieszeni albo w jednej ręce, i mam go
praktycznie zawsze ze sobą. Laptopa mam ze sobą dużo rzadziej, i nie mieści się
w jednej ręce. Ale nawet jak testowałem taki workflow, to była pewna upierdliwość
z przeskakiwaniem między urządzeniami. Jak mam jedno urządzenie, to tej
upierdliwości nie ma.

> Nie chcę oczywiście szukać Ci na siłę rozwiązań, ot dzielę się myślami 
> które mi przez głowę przechodzą, ale z pewnością masz to wszystko już 
> dawno przećwiczone. 

Tak. Sądzę, że jedną z przyczyn, dla których większość apek w Appstorze jest taka beznadziejna, to właśnie ów workflow, który oddala programistę od uzyskiwanego przez niego efektu.

> Ale ja na codzień właśnie na połowie ekranu pracuję

Przypomniał mi się stary dowcip o inżynierze, który zgłosił wniosek racjonalizatorski, że skoro nigdy nie zużywamy rysika w ołówku do końca, to można zaoszczędzić wpychając do ołówków krótsze rysiki. Nagroda.
Po jakimś czasie zauważył, że skoro i tak rysik jest krótszy, to nie ma po co marnować drewna i robić takich długich ołówków. Znowu nagroda.

> > Ale na biurku to zwykle widuję u ludzi po dwa monitory +24".
> Też widuję. I różne inne rzeczy widuję "u ludzi", ale co to za 
> argument? Ludzie to nie ja.

Chodziło mi o to, że to jest trochę taki "industry standard". Nawet w tym sensie, że jak inżynier dostał niedawno nową pracę,  zdalnie, to pracodawca po prostu przysłał inżynierowi kurierem na chatę 2x takie monitory w ogóle nawet nie pytając, czy chce je mieć. No i stoją w pudłach, bo akurat nie chciał.
Nie dziwi mnie to, bo duże firmy nie kupują sprzętu pojedynczo, tylko hurtem. I wtedy 24" jest takim samym "industry standard" jak format A4 na papier w drukarce.
Może nawet jest w tym jakiś zbieg okoliczności, bo tak się śmiesznie składa, że na monitorze 24" można wyświetlić dokument przeznaczony do druku A4 w skali 1:1. I jest to najmniejszy rozmiar monitora, który na to pozwala. Przyłóż kartkę, to zobaczysz.
Nie, nie upieram się, że wyświetlanie czegokolwiek w skali 1:1 ma jakąkolwiek wartość dodaną. Ale miało być WYSIWYG, to proszę bardzo.

> No więc mi właśnie o to całe "BHP" od początku chodzi. Jakieś normy w 
> tym temacie? Badania?

https://www.google.com/search?q=recommended+monitor+size

U mnie wylatuje systematycznie +24".

> Przepisy BHP?

Nie sądzę, bo są różne ekrany. Np. w kasie sklepowej też jest ekran.
Ale monitor 24", oddalony na odległość wyciągniętej ręki, całkiem zgrabnie wypełnia pole widzenia bez zmuszania do niepotrzebnych napięć mięśni. Mi to wszystko razem akurat pasuje.

> Tego jestem ciekaw - bo reszta to 
> zwyczajne przekomarzanie się o to kto jakie ma przyzwyczajenia

No to nie przekomarzajmy się na ten temat. Bo zaraz będzie o krzesłach i innych meblach.

-- 
Maciej Sobczak * http://www.inspirel.com

2021-09-01 o 11:13 -0700, Maciej Sobczak napisał:
> I wtedy 24" jest takim samym "industry standard" jak format A4 na
> papier w drukarce. Może nawet jest w tym jakiś zbieg okoliczności, bo
> tak się śmiesznie składa, że na monitorze 24" można wyświetlić
> dokument przeznaczony do druku A4 w skali 1:1. I jest to najmniejszy
> rozmiar monitora, który na to pozwala.

Fajnie, tylko że to nieprawda jest. Do wyświetlania dokumentów A4 w
skali 1:1 wystarczy pionowo postawiony ekran 17". Takie ekrany
widywałem zresztą u tzw. "technical writerów", kiedy - dawno temu -
zdarzyło mi się pracować w biurze. Tzn. były to normalne ekrany 17",
ale z funkcją ustawienia pionowego.

Źródłem problemu jest format dzisiejszych ekranów. 16:9 to fajna rzecz
do kina czy jakichś gier, bo zgodniejsze z naturalnym polem widzenia
człowieka, lecz do pisania podłużnych dokumentów nadaje się słabo. W
efekcie płacę za duży ekran 15.6" w laptopie, ale pożytecznie
wykorzystuję z niego tylko obszar ok. 10".

> Mi to wszystko razem akurat pasuje.

I chyba tylko taki można wyciągnąć z tego wniosek.

> No to nie przekomarzajmy się na ten temat. Bo zaraz będzie o
> krzesłach i innych meblach.

Od krzesła preferuję fotel bujany przy kominku. Ale znów - co kto lubi.

Mateusz

> Fajnie, tylko że to nieprawda jest. Do wyświetlania dokumentów A4 w 
> skali 1:1 wystarczy pionowo postawiony ekran 17".

Cały dzień wisiało mi nad głową, że ktoś to napisze...

Ale na pionowym ekranie ciulowo się ogląda filmy.
Tak, wiem, że najwyższym osiągnięciem w historii kinematografii są pionowe filmiki z TikToka, ale wciąż...

No i to nadal nieprawda jest. Bo przecież można też robić poziome dokumenty A4.

> Źródłem problemu jest format dzisiejszych ekranów. 16:9 to fajna rzecz 
> do kina czy jakichś gier, bo zgodniejsze z naturalnym polem widzenia 
> człowieka,

No wreszcie: *naturalnym polem widzenia*. I to wyczerpuje temat monitorów.

-- 
Maciej Sobczak * http://www.inspirel.com

2021-09-02 o 11:57 -0700, Maciej Sobczak napisał:
> Ale na pionowym ekranie ciulowo się ogląda filmy.

A ja, durny, myślałem że my tu sobie o programowaniu snujemy. :)

> No wreszcie: *naturalnym polem widzenia*. I to wyczerpuje temat
> monitorów.

Wniosek z tego można chyba wyciągnąć taki, że to, co robimy
(programowanie, albo szerzej - tworzenie pionowych dokumentów) jest
wbrew naszej naturze. I jak tu żyć?

Mateusz

> Wniosek z tego można chyba wyciągnąć taki, że to, co robimy 
> (programowanie, albo szerzej - tworzenie pionowych dokumentów) jest 
> wbrew naszej naturze. I jak tu żyć? 

To zależy. To, że program "wykonuje się" z góry na dół to tylko jedna z możliwych konwencji. Dlaczego stała się popularna? No nie wiem, bo np. dawno temu drukowano programy na papierze? I to jeszcze takim składanym, na krótszym boku, z dziurkowanym marginesem wzdłuż całej paczki?
Program dla szkolnej maszyny Turinga to cienka długa taśma. Może być poziomo. Albo na rolce.
Ale już program zapisany jako model w jakiejś graficznej formie bardzo naturalnie wygląda od lewej (wejścia) do prawej (wyjścia). To jest też popularna konwencja w schematach elektronicznych. Czy taki model będzie bardziej pionowy, czy poziomy, zależy od wielu czynników, ale zdecydowanie to, co mamy teraz z kodem źródłowym to chwilowa anomalia a nie ponadczasowy pewnik.

Albo wyobraź sobie, że plik źródłowy nie leci ciurkiem od góry do dołu, funkcja po funkcji, tylko np. ma osobne kolumny. I każdą funkcję w osobnym pliku (to jest nawet teraz tu i ówdzie obowiązującym standardem kodowania). Niech będzie, że tekstowe, ale w kilku kolumnach. Np. w każdej kolumnie osobno: parametry, pre-conditions, zmienne lokalne, reguły przetwarzania, post-conditions. Ładnie by to wyglądało.

To, że piszemy kod źródłowy jak by to był papier toaletowy to tylko nasza wina. Nie jest to w żadnym razie jakaś inherentna cecha programowania w ogóle.

-- 
Maciej Sobczak * http://www.inspirel.com

piątek, 3 września 2021 o 20:21:21 UTC+2 Maciej Sobczak napisał(a):
> > Wniosek z tego można chyba wyciągnąć taki, że to, co robimy 
> > (programowanie, albo szerzej - tworzenie pionowych dokumentów) jest 
> > wbrew naszej naturze. I jak tu żyć?
> To zależy. To, że program "wykonuje się" z góry na dół to tylko jedna z możliwych konwencji. Dlaczego stała się popularna? No nie wiem, bo np. dawno temu drukowano programy na papierze? I to jeszcze takim składanym, na krótszym boku, z dziurkowanym marginesem wzdłuż całej paczki?

W Europejskiej kulturze kierunek tekstu to jest "od lewej do prawej, od góry do dołu".
Są kultury, w których ten kierunek poziomy jest odwrócony, tzn. czyta się "od prawej do lewej, od góry do dołu".
Czasem też w kulturach azjatyckich można się spotkać z taką inwersją, że najpierw czyta się w pionie, a potem w poziomie, ale chyba zawsze jest "z góry na dół".

Może ma to związek z grawitacją, i z tym, że jesteśmy uczeni, że rzeczy "same z siebie" raczej ciągnie w dół, niż do góry?
 
> Program dla szkolnej maszyny Turinga to cienka długa taśma. Może być poziomo. Albo na rolce. 
> Ale już program zapisany jako model w jakiejś graficznej formie bardzo naturalnie wygląda od lewej (wejścia) do prawej (wyjścia). To jest też popularna konwencja w schematach elektronicznych. Czy taki model będzie bardziej pionowy, czy poziomy, zależy od wielu czynników, ale zdecydowanie to, co mamy teraz z kodem źródłowym to chwilowa anomalia a nie ponadczasowy pewnik. 

Stosunkowo niedawno natrafiłem na tę prezentację, przedstawiającą środowisko programistyczne jako "pochodnię w jaskini", i proponujące dość ciekawą alternatywę:

https://www.youtube.com/watch?v=Ps3mBPcjySE

> Albo wyobraź sobie, że plik źródłowy nie leci ciurkiem od góry do dołu, funkcja po funkcji, tylko np. ma osobne kolumny. I każdą funkcję w osobnym pliku (to jest nawet teraz tu i ówdzie obowiązującym standardem kodowania).

Albo że nie trzymasz programu w ogóle w plikach, tylko to są obiekty w pamięci, które ewentualnie możesz na wiele sposobów zrzutować na system plików. Hmm, brzmi jak Smalltalk albo Interlisp, albo "programowanie intencjonalne" :)

> Niech będzie, że tekstowe, ale w kilku kolumnach. Np. w każdej kolumnie osobno: parametry, pre-conditions, zmienne lokalne, reguły przetwarzania, post-conditions. Ładnie by to wyglądało. 

Nieco dawniej natrafiłem na tę "rodzinę prezentacji", skupiającą się na typografii kodu źródłowego (jak by powiedziała Debbie Reynolds, "if you've seen one, you've seen them all")

https://hilton.org.uk/presentations/beautiful-code

Ja sam nie jestem do końca przekonany. Moim zdaniem programy powinny wyglądać jak instrukcje montażu mebli z Ikei.

> To, że piszemy kod źródłowy jak by to był papier toaletowy to tylko nasza wina. Nie jest to w żadnym razie jakaś inherentna cecha programowania w ogóle.

Nie wiem, czy jak papier toaletowy.
Większość środowisk "hipertekstualizuje" programy w tym sensie, że można np. kliknąć na symbol, żeby przejść do jego definicji.
Nie spotkałem się z taką możliwością u swojego papieru toaletowego.

Ale faktycznie, "programowanie w ogóle" nie ma zbyt wielu silnie określonych cech.
Większość z nich to raczej nawyki naszych umysłów.

> W Europejskiej kulturze kierunek tekstu to jest "od lewej do prawej, od góry do dołu". 

Europejska kultura nie nakazuje używania tekstu w programowaniu. Jakoś w elektronice nie nakazała.

> ale chyba zawsze jest "z góry na dół". 
> 
> Może ma to związek z grawitacją,

Ja tam nie wiem. Ale jak idę i patrzę pod nogi albo jak jadę rowerem albo samochodem, to "konsumuję treść" na drodze w drugą stronę. I gdybym miał coś czytać na rozwiniętym papierze toaletowym, to raczej wolałbym go czytać idąc do przodu, niż do tyłu.
Czytanie z góry na dół miało sens jak się cały pergamin mieścił przed oczami. A jak ktoś ma N tysięcy linii w pliku to już ta ergonomia nie działa.

> i z tym, że jesteśmy uczeni, że rzeczy "same z siebie" raczej ciągnie w dół, niż do góry?

No właśnie. Jeśli rzeczy ciągnie w dół, np. jak coś spada za oknem, to najpierw zobaczymy ich dolny koniec a potem górny. Dlaczego nie moglibyśmy tak czytać długich tekstów?

> Albo że nie trzymasz programu w ogóle w plikach, tylko to są obiekty w pamięci,

Przecież pisałem o modelowaniu.

> Większość środowisk "hipertekstualizuje" programy w tym sensie, że można np. kliknąć na symbol, żeby przejść do jego definicji. 
> Nie spotkałem się z taką możliwością u swojego papieru toaletowego. 

Nie klikaj papieru toaletowego!

-- 
Maciej Sobczak * http://www.inspirel.com

sobota, 4 września 2021 o 20:07:26 UTC+2 Maciej Sobczak napisał(a):
> > W Europejskiej kulturze kierunek tekstu to jest "od lewej do prawej, od góry do dołu".
> Europejska kultura nie nakazuje używania tekstu w programowaniu. Jakoś w elektronice nie nakazała.

Prawda.
Kiedyś "się programowało" za pomocą kabli, a później - dziurkując karty.
Ale raczej nikt nie chciałby wracać do tych czasów, i większość osób woli pisać tekst.
I chyba jeszcze nic lepszego od tekstu nie wymyślono.
(Co nie znaczy, że się nie da.)

> > ale chyba zawsze jest "z góry na dół". 
> > 
> > Może ma to związek z grawitacją,
> Ja tam nie wiem. Ale jak idę i patrzę pod nogi albo jak jadę rowerem albo samochodem, to "konsumuję treść" na drodze w drugą stronę. I gdybym miał coś czytać na rozwiniętym papierze toaletowym, to raczej wolałbym go czytać idąc do przodu, niż do tyłu. 
> Czytanie z góry na dół miało sens jak się cały pergamin mieścił przed oczami. A jak ktoś ma N tysięcy linii w pliku to już ta ergonomia nie działa.

Tak, podobny problem jest przy pisaniu blogów i rzeczy tego rodzaju.
Kiedy pracuję nad swoim środowiskiem, to mam tam pliczek "TODO", 
na którym prawie każdego dnia wypisuję sobie listę rzeczy, którymi
chcę się zajmować.

Zawsze nowe wpisy pojawiają się na samej górze. Ale jak już się pojawią,
to kolejne linie są coraz niżej i niżej.

Wydaje mi się, że jest w tym jakaś niespójność.

> > i z tym, że jesteśmy uczeni, że rzeczy "same z siebie" raczej ciągnie w dół, niż do góry?
> No właśnie. Jeśli rzeczy ciągnie w dół, np. jak coś spada za oknem, to najpierw zobaczymy ich dolny koniec a potem górny. Dlaczego nie moglibyśmy tak czytać długich tekstów?

Może dlatego, że zbyt szybko by spadały, i nie zdążylibyśmy doczytać.
No i ktoś musiałby się wspinać na dach, żeby je dla nas zrzucać.

Mam jeszcze pewien problem z moim programem. Otóż wywołuję funkcję regex_search(line, matches, re1) i jeśli wartością line jest długi tekst arabskich znaków to dostaję "Segmentation fault" w wierszu 204 pliku regex.h:
     const __ctype_type& __fctyp(use_facet<__ctype_type>(_M_locale));
Co mam z tym zrobić?

środa, 8 września 2021 o 17:28:37 UTC+2 Robert Magdziarz napisał(a):
> Mam jeszcze pewien problem z moim programem. Otóż wywołuję funkcję regex_search(line, matches, re1) i jeśli wartością line jest długi tekst arabskich znaków to dostaję "Segmentation fault" w wierszu 204 pliku regex.h: 
> const __ctype_type& __fctyp(use_facet<__ctype_type>(_M_locale)); 
> Co mam z tym zrobić?

Najlepiej wyizolować minimalny przypadek generujący błąd i wysłać bug reporta do dostawcy tej biblioteki, upewniwszy się, że korzystasz z najnowszej dostępnej wersji.
Domyślam się, że regex_search pochodzi z biblioteki standardowej C++ - w takim przypadku raport powinien pójść do twórcy kompilatora.

Jeżeli  natomiast chcesz rozwiązać swój problem, to najprostsze, co możesz zrobić, to spróbować zmienić kompilator,
np. jeżeli używasz GCC, to użyj clang albo Visual C++, i zobacz czy to pomaga. (No i zawsze używaj raczej najnowszych wersji, bo w nich błąd mógł już zostać poprawiony)

Jeżeli nie pomaga, ale masz dostępne źródła biblioteki, to możesz spróbować zdebugować samemu.
(Tyle że biblioteki standardowe C++ są z reguły mocno "szabloniaste" i warstwy abstrakcji, przez które trzeba się przedzierać, potrafią być skuteczną barierą dla takich prób. Ja w każdym razie bałbym się iść tą drogą)

A co sądzisz o pomyśle użycia innej biblioteki regex np. boost?

czwartek, 9 września 2021 o 19:58:39 UTC+2 Robert Magdziarz napisał(a):
> A co sądzisz o pomyśle użycia innej biblioteki regex np. boost?

Można spróbować (choć typowo implementacje z boost "awansują" to biblioteki standardowej, i mogą mieć te same problemy)
Ale chyba Qt daje też swoje regexy?

czwartek, 9 września 2021 o 21:47:02 UTC+2 Maciek Godek napisał(a):
> Można spróbować (choć typowo implementacje z boost "awansują" to biblioteki standardowej, i mogą mieć te same problemy) 

funkcje boost regex wywołują std regex?

> Ale chyba Qt daje też swoje regexy?

tak, ale kompiluję do dwóch programów wykonywalnych: jeden cmd-line (bez Qt), drugi GUI (z Qt), w obu programach potrzebuje regex

piątek, 10 września 2021 o 07:56:11 UTC+2 Robert Magdziarz napisał(a):
> czwartek, 9 września 2021 o 21:47:02 UTC+2 Maciek Godek napisał(a): 
> > Można spróbować (choć typowo implementacje z boost "awansują" to biblioteki standardowej, i mogą mieć te same problemy)
> funkcje boost regex wywołują std regex?

Nie. Biblioteka boost ma dość szczegolne miejsce w C++owym ekosystemie w tym sensie, że często jest tak, że komponenty z tej biblioteki stają się składnikami biblioteki standardowej w kolejnych rewizjach standardu C++.
Dlatego jest spora szansa, że jeżeli użyjesz boost zamiast std, to efektywnie będziesz wywoływał taki sam kod.

Ale spróbować oczywiście można.

> > Ale chyba Qt daje też swoje regexy?
> tak, ale kompiluję do dwóch programów wykonywalnych: jeden cmd-line (bez Qt), drugi GUI (z Qt), w obu programach potrzebuje regex

Kwestia jest taka, czy ten program w linii komend używasz na systemie, na którym jest dostępna biblioteka Qt.
Jeżeli tak, to nie powinno być problemu - aplikacje konsolowe mogą używać składników Qt (np. kontenerów albo właśnie regexów). Szybko wyguglany przykład:

https://lubby.org/ebooks/qtconsoleapp2/qtconsoleapp2.html

Ewentualnie, jeżeli biblioteka Qt nie jest dostępna na systemie docelowym (albo nie wiesz, czy jest dostępna), możesz zlinkować z Qt statycznie, i wtedy linker wydobędzie z Qt wszystkie komponenty niezbędne do działania Twojego programu (tylko wówczas problemem może być ewentualnie rozmiar pliku wykonywalnego)

piątek, 10 września 2021 o 09:26:32 UTC+2 Maciek Godek napisał(a):
> > > Ale chyba Qt daje też swoje regexy? 
> > tak, ale kompiluję do dwóch programów wykonywalnych: jeden cmd-line (bez Qt), drugi GUI (z Qt), w obu programach potrzebuje regex
> Kwestia jest taka, czy ten program w linii komend używasz na systemie, na którym jest dostępna biblioteka Qt. 
> Jeżeli tak, to nie powinno być problemu - aplikacje konsolowe mogą używać składników Qt (np. kontenerów albo właśnie regexów). 
> rozważę to
> 
> Ewentualnie, jeżeli biblioteka Qt nie jest dostępna na systemie docelowym (albo nie wiesz, czy jest dostępna), możesz zlinkować z Qt statycznie, i wtedy linker wydobędzie z Qt wszystkie komponenty niezbędne do działania Twojego programu (tylko wówczas problemem może być ewentualnie rozmiar pliku wykonywalnego)
> ZTCW za sprzedawanie programu z linkowaniem statycznym trzeba płacić, a ja chcę używać Qt bezpłatnie i sprzedawać swój program

Udało mi się znowu wygenerować kilka razy przypadek strs=="" z wiersza poleceń. Niestety program uruchomiony pod VSCode z debugowaniem (ten sam exec i te same argumenty i te same dane wejściowe) daje strs!="".
Jak to wytłumaczyć?

wtorek, 21 września 2021 o 11:59:03 UTC+2 Robert Magdziarz napisał(a):
> Udało mi się znowu wygenerować kilka razy przypadek strs=="" z wiersza poleceń. Niestety program uruchomiony pod VSCode z debugowaniem (ten sam exec i te same argumenty i te same dane wejściowe) daje strs!="". 

Pytanie, czy udaje Ci się konsekwentnie dostawać tę sytuację dla tych samych danych wejściowychl, w tych samych okolicznościach?

(jeżeli tak, to to jest światełko w tunelu)

> Jak to wytłumaczyć?

W jednym zdaniu tak: "oprogramowanie jest skomplikowane"

wtorek, 21 września 2021 o 17:56:08 UTC+2 Maciek Godek napisał(a):
> wtorek, 21 września 2021 o 11:59:03 UTC+2 Robert Magdziarz napisał(a): 
> > Udało mi się znowu wygenerować kilka razy przypadek strs=="" z wiersza poleceń. Niestety program uruchomiony pod VSCode z debugowaniem (ten sam exec i te same argumenty i te same dane wejściowe) daje strs!="".
> Pytanie, czy udaje Ci się konsekwentnie dostawać tę sytuację dla tych samych danych wejściowychl, w tych samych okolicznościach? 

teraz mam strs=="" i z wiersza poleceń i pod debugerem

środa, 22 września 2021 o 08:19:45 UTC+2 Robert Magdziarz napisał(a):
> teraz mam strs=="" i z wiersza poleceń i pod debugerem

przepraszam, pomyłka: strs!="" i z wiersza poleceń i pod debugerem

On 22/09/2021 08:19, Robert Magdziarz wrote:
> teraz mam strs=="" i z wiersza poleceń i pod debugerem

I co jest na callstacku?

środa, 22 września 2021 o 09:28:04 UTC+2 heby napisał(a):
> On 22/09/2021 08:19, Robert Magdziarz wrote: 
> > teraz mam strs=="" i z wiersza poleceń i pod debugerem
> I co jest na callstacku?
Jak pisałem, pomyliłem się w poście: powinno być: teraz mam strs!="" i z wiersza poleceń i pod debugerem

Maciej Sobczak <see.my.homepage@gmail.com> Wrote in message:
> > Lubię proste i skuteczne narzędziaPrzy pracy jednoosobowej takimi narzędziami są zip oraz unzip. Polecam.Zwłaszcza, że oprócz historii zmian potrafią zupełnie naturalnie zrobić backup - a to jest *ważniejsze*, niż zabawa w commity.Nie, lokalny git to nie jest backup.Jednoosobowy lokalny git ma wartość co najwyżej hobbystyczną albo edukacyjną.

Nawet "jednoosobowo" używany git jest pożyteczny. Zip/unzip nie
 sprawdza się zbyt dobrze, ale to off-topic... m.i. nie ma
 możliwości śledzenia zmian, nie ma gałęzi, nie ma tego tamtego i
 jeszcze tego. Zip jako backup sprawdza się słabo (zwłaszcza
 jeżeli pliki leżą i tak na tym samym komputerze). Przy obecnych
 cenach nośników lepsze od Zip jest zwykłe copy. Oba te
 rozwiązania niepotrzebnie powielają pliki. Przykładowo program to
 20 KB kodu i 500 MB multimediów (filmik, audio, obrazki, ikonki).
 Te 500 MB nie zmienia się, ale Zip/copy tego nie zrozumie. I żeby
 było śmieszniej... raczej nie da się skompresować jeżeli były
 dobre kodeki. Ok, można np. zrobić sobie skrypt archiwizujący "co
 trzeba" - de facto to krok do zrobienia własnego systemu wersji i
 ma zapach reinventing the wheel.

Ogarnięcie git to jakieś dwie godziny. Zaletą jest brak
 konieczności musienia mieć serwera. Ale jeżeli ktoś lubi inny
 CVS, n.p. Subversion, to niech robi w tym co lubi. Podkreślam
 (wężykiem) Zip to nie CVS.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

kriters <kritersi@o2.pl> Wrote in message:
> Ale jak kto woli. Można używać notatnika a wersje kodu trzymać na odpowiednio opisanych dyskietkach.

Przebijam: na tasiemce papierowej... dziurkowanej.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Mateusz Viste <mateusz@xyz.invalid> Wrote in message:
> 2021-08-29 o 22:12 +0200, kriters napisał:> Ale jak kto woli. Można używać notatnika a wersje kodu trzymać na> odpowiednio opisanych dyskietkach.Co złego jest w notatniku? Ja tylko tego używam - zawodowo jak iprywatnie. Te wszelkie nowoczesne IDE tylko wprowadzają szumczłowiekowi w głowie. Jak patrzę na programistów działających z różnymiIDE na kilku ekranach to dziwię się, że udaje im się cokolwiek zrobić.Moja ewolucja pisania doprowadziła mnie do notatnika (kwrite) naekranie 15", tylko tak jestem w stanie skupić się na tym, co istotne.Nie, to nie prowokacja.Mateusz

Ajtam. Kwrite jest dla mięczaków, nie ma jak Emacs i Fortran.

Bardziej serio. Ctrl+space i ligatury, multikursor i makra. 
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/