W dniu poniedziałek, 10 listopada 2014 12:01:24 UTC+1 użytkownik g...@g...com
napisał:
> W dniu poniedziałek, 10 listopada 2014 11:38:27 UTC+1 użytkownik firr napisał:
> >
> > spoko,
> > jak na razie sam nie wiem czy ten lisp/scheme mnie przekonuje, przejrzalem te
trzy posty
> > i o ole sam mowiesz ze scheme jest jezykiem prostym itp to takie proste sie
jednak nie wydaje, do tego tak naprawde ja nie lubie
> > pewnego rodzaju programowania ktore 'ciągnie'
> > troche perlem czy wyrazeniai regularnymi,
> > to scheme moze nie do konca 'ciagnie' wyrazeniami regularnymi ale tej skladni
jest tu duzo
>
> tzn. jezeli idzie o skladnie, to z jednej strony sposob budowania wyrazen
> jest bardzo jednorodny (w przeciwienstwie do wielu jezykow takich jak np. C,
> w ktorym masz duzo specjalnych konstrukcji i operatorow jak *, ++, &, []),
> a z drugiej -- ilosc podstawowych form skladniowych wynosi 6, czyli naprawde
> niewiele (dla porownania, w C masz ponad 30 slow kluczowych)
>
> jezeli idzie do perla, to zgodze sie, ze to jest jezyk skrajnie nieopisowy
> (jest duzo dziwnych znaczkow jak %,#,@,$,&,*, i kilka rodzajow nawiasow,
> ktore w zaleznosci od kontekstu maja rozne znaczenie) -- i pod tym wzgledem
> perl jest calkowitym przeciwienstwem scheme'a (i pythona)

c nie jest zbyt jednorodny, ale z tego co powyzej to owo scheme tez nie wyglada mi
wcale na cos malego i jednorodnego; z tym liczeniem slow kluczowych to przesada w c
wiekszosc tych slow to nazwy typow (ktore tak naprawde mozna by uznac za typy
blibioteczne choc wbudowane),
reszta to glownie chyba 3 slowa if for i return
- ilosc sluw kluczowych nie bardzo sie ma do architektury ducha jezyka ktora w
przypadku c jest mz bardzo skomplikowana - 'architektura ducha' scheme mi wyglada z
grubsza ani na wyraznie mniej skomplikowana ani na wyraznie bardziej, moge powiedziec
ze te niektore nieco bardziej skomplikowane wyrazenia te np gdzie wchodzi juz ta
lambda define i dalej nie wygladaja mi wcale za naturalnie

- nie wiem czy chce w to wszystko wnikac, mam ciagle problem z czasem i energią. to
zo mnie teraz glownie interesuje to piksele (zwane przezemnie programistycznym
piachem)

do góry

W dniu poniedziałek, 10 listopada 2014 12:30:08 UTC+1 użytkownik firr napisał:

> c nie jest zbyt jednorodny, ale z tego co powyzej to owo scheme tez nie wyglada mi
wcale na cos malego i jednorodnego; z tym liczeniem slow kluczowych to przesada w c
wiekszosc tych slow to nazwy typow (ktore tak naprawde mozna by uznac za typy
blibioteczne choc wbudowane),
> reszta to glownie chyba 3 slowa if for i return

no, jest jeszcze break, continue, goto, while, do, switch, case, default.
ale zgoda, to nie jest najwazniejsze.
scheme nie dostarcza takich rzeczy, jak for, while, do, switch czy return,
ale dostarcza srodkow, w oparciu o ktore mozna sobie zdefiniowac takie
wyrazenia, a takze wiele innych

zgoda, ze nie jest to calkowicie minimalistyczne. calkowicie minimalistyczny
jest rachunek lambda, ale dla wielu zastosowan jest niepratyczny, dlatego
warto go rozszerzyc przynajmniej o arytmetyke, ifa i wartosci boolowskie.

ostatnio przerabiam ksiazke "Handbook of Practical Logic and
Automated Reasoning" Johna Harrisona, ktory wprowadza w niej przyklady
w jakims wariancie MLa (chyba Caml, ale moge sie mylic). Piszac implementacje
roznych rachunkow logicznych, musi naprawde sporo miejsca poswiecic zagadnieniu
parsowania, natomiast jezeli przyjmie sie konwencje stosowania "w pelni
onawiasowanej notacji polskiej", sprawa staje sie trywialna (zas zysk
wynikajacy ze wprowadzenia wlasnej smiesznej notacji jest zaden)
[inna sprawa, ze ML ma naprawde fajny system typow, ktorego troche
w Schemie brakuje]

> - ilosc sluw kluczowych nie bardzo sie ma do architektury ducha jezyka ktora w
przypadku c jest mz bardzo skomplikowana - 'architektura ducha' scheme mi wyglada z
grubsza ani na wyraznie mniej skomplikowana ani na wyraznie bardziej, moge powiedziec
ze te niektore nieco bardziej skomplikowane wyrazenia te np gdzie wchodzi juz ta
lambda define i dalej nie wygladaja mi wcale za naturalnie

Scheme jest duzo bardziej abstrakcyjny od C. Intencja stojaca za
jezykiem C jest taka, zeby miec duza kontrole nad tym, co robi
komputer. Intencja stojaca za Schemem jest zupelnie odwrotna
-- przede wszystkim interesuje nas to, jak najlepiej opisac
dany problem.

> - nie wiem czy chce w to wszystko wnikac, mam ciagle problem z czasem i energią. to
zo mnie teraz glownie interesuje to piksele (zwane przezemnie programistycznym
piachem)

a udalo Ci sie w ostatnim czasie opracowac jakies nowe ciekawe rzeczy?

do góry

W dniu wtorek, 11 listopada 2014 01:48:52 UTC+1 użytkownik g...@g...com
napisał:
> W dniu poniedziałek, 10 listopada 2014 12:30:08 UTC+1 użytkownik firr napisał:
>
> > c nie jest zbyt jednorodny, ale z tego co powyzej to owo scheme tez nie wyglada
mi wcale na cos malego i jednorodnego; z tym liczeniem slow kluczowych to przesada w
c wiekszosc tych slow to nazwy typow (ktore tak naprawde mozna by uznac za typy
blibioteczne choc wbudowane),
> > reszta to glownie chyba 3 slowa if for i return
>
> no, jest jeszcze break, continue, goto, while, do, switch, case, default.
> ale zgoda, to nie jest najwazniejsze.
> scheme nie dostarcza takich rzeczy, jak for, while, do, switch czy return,
> ale dostarcza srodkow, w oparciu o ktore mozna sobie zdefiniowac takie
> wyrazenia, a takze wiele innych
>

te nie sa zbyt istotne, moze goto/break
(w sumie z tych slow kluczowych w c zostaja
ze dwa trzy ktore wlasnie jakby odpowiadają
opkodom minimalnego assemblera)


> zgoda, ze nie jest to calkowicie minimalistyczne. calkowicie minimalistyczny
> jest rachunek lambda, ale dla wielu zastosowan jest niepratyczny, dlatego
> warto go rozszerzyc przynajmniej o arytmetyke, ifa i wartosci boolowskie.
>
> ostatnio przerabiam ksiazke "Handbook of Practical Logic and
> Automated Reasoning" Johna Harrisona, ktory wprowadza w niej przyklady
> w jakims wariancie MLa (chyba Caml, ale moge sie mylic). Piszac implementacje
> roznych rachunkow logicznych, musi naprawde sporo miejsca poswiecic zagadnieniu
> parsowania, natomiast jezeli przyjmie sie konwencje stosowania "w pelni
> onawiasowanej notacji polskiej", sprawa staje sie trywialna (zas zysk
> wynikajacy ze wprowadzenia wlasnej smiesznej notacji jest zaden)
> [inna sprawa, ze ML ma naprawde fajny system typow, ktorego troche
> w Schemie brakuje]
>
> > - ilosc sluw kluczowych nie bardzo sie ma do architektury ducha jezyka ktora w
przypadku c jest mz bardzo skomplikowana - 'architektura ducha' scheme mi wyglada z
grubsza ani na wyraznie mniej skomplikowana ani na wyraznie bardziej, moge powiedziec
ze te niektore nieco bardziej skomplikowane wyrazenia te np gdzie wchodzi juz ta
lambda define i dalej nie wygladaja mi wcale za naturalnie
>
> Scheme jest duzo bardziej abstrakcyjny od C. Intencja stojaca za
> jezykiem C jest taka, zeby miec duza kontrole nad tym, co robi
> komputer. Intencja stojaca za Schemem jest zupelnie odwrotna
> -- przede wszystkim interesuje nas to, jak najlepiej opisac
> dany problem.
>

c jest bardzo abstrakcyjny, co do owego scheme
to ciagle ciezko mi ocenic, ale szczerze mowiac nie jestem przekonany tj nie wierze
tak jakby apriori ze problemy w scheme latwiej jest wyrazic/rozwiazac w scheme niz w
c (powazne problemy (wezmy na przyklad konkretne przykladowe problemy
1"napisanie dobrego raytracera z dobra optymalizacją" albo
2"napisanie dobrego podsystemu fizyki (zderzen itp) 2d/3d"
tak naprawde musisz rozwiazac jakby poza językiem, czy to ze bedziesz przy tym uzywac

jakiegoś jezyka (mozna wstawic dowolny) cośkolwiek tu pomoże ?

- pytanie jest poniekad otwarte bo pewnosci ze nie pomoze nie mam, ale nie wiem jak
(wiec to ze pomoze jest tylko hipotezą), sam z siebie jakos nic nie widze - na oko
wyglada po prostu na to ze te problemy musisz rozkminic i rozwiazac na pozajęzykowym
polu -- z drugiej
strony tworzenie czegos takiego obejmuje nie tylko rozkminianie ale tez i testowanie
wiec jezyk i srodowisko mogloby miec pewne znaczenie
(moze bardziej nawet srodowisko typu edytor niz sam jezyk)

koniec konców po rozpykaniu tematu (albo odpadnieciu bo czasem jest to na tyle
czasochlonne ze mozna stracic motywacje) mozna to zaimplementowac i to jest chyba
mniejsza czesc problemu, ja moge to wtedy zrobic w c
bo jest to elegancjkie, dosyc wydajne i dosyc łatwe





> > - nie wiem czy chce w to wszystko wnikac, mam ciagle problem z czasem i energią.
to zo mnie teraz glownie interesuje to piksele (zwane przezemnie programistycznym
piachem)
>
> a udalo Ci sie w ostatnim czasie opracowac jakies nowe ciekawe rzeczy?

narazie nie,

do góry

> >
> > Scheme jest duzo bardziej abstrakcyjny od C. Intencja stojaca za
> > jezykiem C jest taka, zeby miec duza kontrole nad tym, co robi
> > komputer. Intencja stojaca za Schemem jest zupelnie odwrotna
> > -- przede wszystkim interesuje nas to, jak najlepiej opisac
> > dany problem.
> >
>
> c jest bardzo abstrakcyjny, co do owego scheme
> to ciagle ciezko mi ocenic, ale szczerze mowiac nie jestem przekonany tj nie wierze
tak jakby apriori ze problemy w scheme latwiej jest wyrazic/rozwiazac w scheme niz w
c (powazne problemy (wezmy na przyklad konkretne przykladowe problemy
> 1"napisanie dobrego raytracera z dobra optymalizacją" albo
> 2"napisanie dobrego podsystemu fizyki (zderzen itp) 2d/3d"
> tak naprawde musisz rozwiazac jakby poza językiem, czy to ze bedziesz przy tym
uzywac
> jakiegoś jezyka (mozna wstawic dowolny) cośkolwiek tu pomoże ?
>
> - pytanie jest poniekad otwarte bo pewnosci ze nie pomoze nie mam, ale nie wiem
jak (wiec to ze pomoze jest tylko hipotezą), sam z siebie jakos nic nie widze - na
oko wyglada po prostu na to ze te problemy musisz rozkminic i rozwiazac na
pozajęzykowym polu -- z drugiej
> strony tworzenie czegos takiego obejmuje nie tylko rozkminianie ale tez i
testowanie wiec jezyk i srodowisko mogloby miec pewne znaczenie
> (moze bardziej nawet srodowisko typu edytor niz sam jezyk)
>
> koniec konców po rozpykaniu tematu (albo odpadnieciu bo czasem jest to na tyle
czasochlonne ze mozna stracic motywacje) mozna to zaimplementowac i to jest chyba
mniejsza czesc problemu, ja moge to wtedy zrobic w c
> bo jest to elegancjkie, dosyc wydajne i dosyc łatwe
>
>


w skrócie mowiac ja to widze tak ze aby zrobic jakis program trzeba

- rozpykac jakis problem (w jego fizycznej czy tam fabularnej istocie) - 90 % roboty
- zaimplementowac w jakims jezyku - 10 % roboty
- jest jeszcze kwestia wygody testowania/uruchamiania
- plus kwestia motywacji

nie wiem czy nie zapomnialem tu o jakims waznym punkcie, w kazdym razie o ile u mnie
te dwa srodkowe punkty pozostawiają troche do zyczenia
(uzywam gcc i drzewa folderow z plikami obj odzielnie kompilowanymi - ktory to system
z jakichs powodow jednak mnie troche wnerwia )
to i tak najwazniejsze sa pierwszy i ostatni
a przy zapewnienieu ostatniego i srodkowych pierwszy czyli tzw 'nadprogramistyczne'
rozkminianie tematu - mw tak to widze

do góry

> 'nadprogramistyczne'

* nadjęzykowe

do góry

> ze problemy w scheme latwiej jest wyrazic/rozwiazac w scheme niz w c

* ze problemy latwiej jest wyrazic/rozwiazac w scheme niz w c

(errata)

o tyle wlasnie powiatpiewam czy te inne jezyki
moga pomoc w rozwiazywaniu problemu, moga moze
pomioc troche w implementacji po jego rozwiazaniu ale w prawdziwym problemie?

te 'prawdziwe problemy' sa chyba wlasnie najgorsze

do góry

>
> w skrócie mowiac ja to widze tak ze aby zrobic jakis program trzeba
>
> - rozpykac jakis problem (w jego fizycznej czy tam fabularnej istocie) - 90 %
roboty
> - zaimplementowac w jakims jezyku - 10 % roboty
> - jest jeszcze kwestia wygody testowania/uruchamiania
> - plus kwestia motywacji
>

czyli w jszcze wiekszym skrocie

motywacja (energia/duch) -> wygoda (edytor, jezyk) -> research

ostatnio coraz czesciej zaluje ze ludzi tak duzo mowia o tym drugim etapie a tak malo
o trzecim - podobnie jest z artykulami itd (byc moze sa (mam na mysli detelistyczne
artykuly nie o programowaniu a o programowaniu czegos konkretnego) ale sa malo
populatne, trudniej
przyswajalne i ciezko je wyszukac itd

do góry

W dniu wtorek, 11 listopada 2014 10:43:39 UTC+1 użytkownik firr napisał:

> c jest bardzo abstrakcyjny,

nie zgodze sie. C stanowi lekka abstrakcje ponad maszynami von Neumannowskimi.
To ze masz takie rzeczy jak typy char, short, int i inne, ktore odpowiadaja
rejestrom maszynowym, pokazuje, w jak duzej mierze C jest zwiazany ze
specyficzna klasa maszyn obliczeniowych. To, ze masz wskazniki, pokazuje,
jak bardzo jest przywiazany do tablicowego modelu pamieci.

> co do owego scheme
> to ciagle ciezko mi ocenic, ale szczerze mowiac nie jestem przekonany tj nie wierze
tak jakby apriori ze problemy w scheme latwiej jest wyrazic/rozwiazac w scheme niz w
c (powazne problemy (wezmy na przyklad konkretne przykladowe problemy
> 1"napisanie dobrego raytracera z dobra optymalizacją" albo
> 2"napisanie dobrego podsystemu fizyki (zderzen itp) 2d/3d"
> tak naprawde musisz rozwiazac jakby poza językiem, czy to ze bedziesz przy tym
uzywac
> jakiegoś jezyka (mozna wstawic dowolny) cośkolwiek tu pomoże ?
> - pytanie jest poniekad otwarte bo pewnosci ze nie pomoze nie mam, ale nie wiem
jak (wiec to ze pomoze jest tylko hipotezą), sam z siebie jakos nic nie widze - na
oko wyglada po prostu na to ze te problemy musisz rozkminic i rozwiazac na
pozajęzykowym polu -- z drugiej
> strony tworzenie czegos takiego obejmuje nie tylko rozkminianie ale tez i
testowanie wiec jezyk i srodowisko mogloby miec pewne znaczenie
> (moze bardziej nawet srodowisko typu edytor niz sam jezyk)
>
> koniec konców po rozpykaniu tematu (albo odpadnieciu bo czasem jest to na tyle
czasochlonne ze mozna stracic motywacje) mozna to zaimplementowac i to jest chyba
mniejsza czesc problemu, ja moge to wtedy zrobic w c
> bo jest to elegancjkie, dosyc wydajne i dosyc łatwe

Ostatnio w ramach swojego projektu zajmuje sie kinematyka odwrotna.
Znalazlem metode, ktora opiera sie na dekompozycji macierzy wzgledem
wartosci osobliwych. Po poszperaniu w sieci udalo mi sie wyszukac
pakiet do obliczen numerycznych i symbolicznych dla Scheme'u.

Znalazlem w tym pakiecie odpowiednia funkcje, i okazalo sie, ze ma
ponad 400 linii. Byl przy niej komentarz (autorstwa Geralda Sussmana),
ze funkcja zostala przepisana z kodu jakiegos innego
systemu Lispowego, ktory z kolei byl przerobiona wersja algorytmu
napisanego w fortranie.

Ten kod jest dla mnie przykladem tego, jak nie nalezy pisac programow.
Napisal go Sussman -- jeden z moich najwiekszych autorytetow i wielki
propagator idei, ze programy powinny byc pisane przede wszystkim tak,
zeby dobrze sie je czytalo.

Wysoki stopien optymalizacji i czytelnosc programow to nie sa sprzeczne
cele. Wydaje mi sie, ze to raczej nasze techniki programowania sa
niedorozwiniete.

Moim zdaniem idealny program powinien stanowic zapis rozumowania,
ktory przeprowadza programista. Programista powinien wypisywac swoje
zalozenia i twierdzenia, ktore nastepnie kompilator moglby wykorzystywac
do optymalizacji kodu.

Na przyklad, programista powinien wklepac do programu to, czym jest macierz
i na czym polega mnozenie macierzy, i nastepnie okreslic, jake sa wlasnosci
poszczegolnych macierzy zdekomponowanych w oparciu o SVD, i ewentualnie
kilka twierdzen pomocniczych (np. tych, ktore posluzyly do stworzenia algorytmu
w fortranie), natomiast kompilator powinien wypluc optymalny algorytm
faktoryzujacy.

> > > - nie wiem czy chce w to wszystko wnikac, mam ciagle problem z czasem i
energią. to zo mnie teraz glownie interesuje to piksele (zwane przezemnie
programistycznym piachem)
> >
> > a udalo Ci sie w ostatnim czasie opracowac jakies nowe ciekawe rzeczy?
>
> narazie nie,

ja u siebie zauwazylem cos takiego, ze moj projekt przez wiekszosc czasu
stoi w miejscu, az w koncu cos we mnie dojrzeje i dokonam jakiegos przelomu
(i potem znow stoi w miejscu...)

do góry

W dniu wtorek, 11 listopada 2014 21:48:47 UTC+1 użytkownik g...@g...com
napisał:
> W dniu wtorek, 11 listopada 2014 10:43:39 UTC+1 użytkownik firr napisał:
>
> > c jest bardzo abstrakcyjny,
>
> nie zgodze sie. C stanowi lekka abstrakcje ponad maszynami von Neumannowskimi.
> To ze masz takie rzeczy jak typy char, short, int i inne, ktore odpowiadaja
> rejestrom maszynowym, pokazuje, w jak duzej mierze C jest zwiazany ze
> specyficzna klasa maszyn obliczeniowych. To, ze masz wskazniki, pokazuje,
> jak bardzo jest przywiazany do tablicowego modelu pamieci.
>
> > co do owego scheme
> > to ciagle ciezko mi ocenic, ale szczerze mowiac nie jestem przekonany tj nie
wierze tak jakby apriori ze problemy w scheme latwiej jest wyrazic/rozwiazac w scheme
niz w c (powazne problemy (wezmy na przyklad konkretne przykladowe problemy
> > 1"napisanie dobrego raytracera z dobra optymalizacją" albo
> > 2"napisanie dobrego podsystemu fizyki (zderzen itp) 2d/3d"
> > tak naprawde musisz rozwiazac jakby poza językiem, czy to ze bedziesz przy tym
uzywac
> > jakiegoś jezyka (mozna wstawic dowolny) cośkolwiek tu pomoże ?
> > - pytanie jest poniekad otwarte bo pewnosci ze nie pomoze nie mam, ale nie wiem
jak (wiec to ze pomoze jest tylko hipotezą), sam z siebie jakos nic nie widze - na
oko wyglada po prostu na to ze te problemy musisz rozkminic i rozwiazac na
pozajęzykowym polu -- z drugiej
> > strony tworzenie czegos takiego obejmuje nie tylko rozkminianie ale tez i
testowanie wiec jezyk i srodowisko mogloby miec pewne znaczenie
> > (moze bardziej nawet srodowisko typu edytor niz sam jezyk)
> >
> > koniec konców po rozpykaniu tematu (albo odpadnieciu bo czasem jest to na tyle
czasochlonne ze mozna stracic motywacje) mozna to zaimplementowac i to jest chyba
mniejsza czesc problemu, ja moge to wtedy zrobic w c
> > bo jest to elegancjkie, dosyc wydajne i dosyc łatwe
>
> Ostatnio w ramach swojego projektu zajmuje sie kinematyka odwrotna.
> Znalazlem metode, ktora opiera sie na dekompozycji macierzy wzgledem
> wartosci osobliwych. Po poszperaniu w sieci udalo mi sie wyszukac
> pakiet do obliczen numerycznych i symbolicznych dla Scheme'u.
>
> Znalazlem w tym pakiecie odpowiednia funkcje, i okazalo sie, ze ma
> ponad 400 linii. Byl przy niej komentarz (autorstwa Geralda Sussmana),
> ze funkcja zostala przepisana z kodu jakiegos innego
> systemu Lispowego, ktory z kolei byl przerobiona wersja algorytmu
> napisanego w fortranie.
>
> Ten kod jest dla mnie przykladem tego, jak nie nalezy pisac programow.
> Napisal go Sussman -- jeden z moich najwiekszych autorytetow i wielki
> propagator idei, ze programy powinny byc pisane przede wszystkim tak,
> zeby dobrze sie je czytalo.
>
> Wysoki stopien optymalizacji i czytelnosc programow to nie sa sprzeczne
> cele. Wydaje mi sie, ze to raczej nasze techniki programowania sa
> niedorozwiniete.
>
> Moim zdaniem idealny program powinien stanowic zapis rozumowania,
> ktory przeprowadza programista. Programista powinien wypisywac swoje
> zalozenia i twierdzenia, ktore nastepnie kompilator moglby wykorzystywac
> do optymalizacji kodu.
>
> Na przyklad, programista powinien wklepac do programu to, czym jest macierz
> i na czym polega mnozenie macierzy, i nastepnie okreslic, jake sa wlasnosci
> poszczegolnych macierzy zdekomponowanych w oparciu o SVD, i ewentualnie
> kilka twierdzen pomocniczych (np. tych, ktore posluzyly do stworzenia algorytmu
> w fortranie), natomiast kompilator powinien wypluc optymalny algorytm
> faktoryzujacy.
>
> > > > - nie wiem czy chce w to wszystko wnikac, mam ciagle problem z czasem i
energią. to zo mnie teraz glownie interesuje to piksele (zwane przezemnie
programistycznym piachem)
> > >
> > > a udalo Ci sie w ostatnim czasie opracowac jakies nowe ciekawe rzeczy?
> >
> > narazie nie,
>
> ja u siebie zauwazylem cos takiego, ze moj projekt przez wiekszosc czasu
> stoi w miejscu, az w koncu cos we mnie dojrzeje i dokonam jakiegos przelomu
> (i potem znow stoi w miejscu...)

malo to jest scisle, ja jak mowilem bardziej sie ostatnimi czasy interesuje nie
narzedziami tylko "researchem" konkretnymi rzeczami ktore mozna przy ich pomocy
zrobic (na tyle ze to ustawiczne gadanie o narzędziach mnie zaczyna lekko irytowac -
bez przesady oczywiscie, ale tak naprawde wolalbym pogadac, poczytac [w sukcesywnych
latach ] cos nie o narzedziach tylko o konkretnych 'przedmiotach' jakie tymi
narzedziami mozna wykonac -
c czy scheme to sa narzedzia, jak pisalem
wiekszosc roboty jaka musisz zrobic to jest
"przedmiotówka" nie narzędziówka i wątpie by tu scheme ci coś pomoglo

do góry