W dniu 2014-11-22 06:41, Pszemol pisze:
> Ano tu jest to wyjaśnione - przyczyna dla której Android wymaga
> dużo więcej pamięci do szybkiej pracy jest znowu Java i garbage collection:
> http://www.quora.com/How-come-the-iPhones-1-GB-RAM-i
s-touted-to-be-able-to-compete-with-more-than-2-GB-R
AM-of-Android-phones/answers/7061202
>
>
> Dopiero Android z 3G ramu na pokładzie będzie pracował tak szybko
> jak iPhone z 1G ramu - a mniej kostek pamięci to mniej prądu z baterii!

Widać, jak niechlujnie pisane są programy w dzisiejszych czasach.
Potrzebne są gigabajty, żeby użyć jakichś prostych aplikacji, które
mogłyby się spokojnie zmieścić w megabajtach.


--
MN

do góry

"Marcin N" <m...@o...pl> wrote in message
news:54702897$0$2844$65785112@news.neostrada.pl...
> W dniu 2014-11-22 06:41, Pszemol pisze:
>> Ano tu jest to wyjaśnione - przyczyna dla której Android wymaga
>> dużo więcej pamięci do szybkiej pracy jest znowu Java i garbage
>> collection:
>> http://www.quora.com/How-come-the-iPhones-1-GB-RAM-i
s-touted-to-be-able-to-compete-with-more-than-2-GB-R
AM-of-Android-phones/answers/7061202
>>
>>
>> Dopiero Android z 3G ramu na pokładzie będzie pracował tak szybko
>> jak iPhone z 1G ramu - a mniej kostek pamięci to mniej prądu z baterii!
>
> Widać, jak niechlujnie pisane są programy w dzisiejszych czasach.
> Potrzebne są gigabajty, żeby użyć jakichś prostych aplikacji, które
> mogłyby się spokojnie zmieścić w megabajtach.

Wiesz co Ci powiem - zawsze mi mówiono że Java jest nieefektywna
i że ten cały wychwalany przez nielubiących wskaźników w C/C++
mechanizm automatycznego zarządzania pamięcią jakoś tam działa
ale niezbyt efektywnie - więc nie jest to dla mnie nowością, że coś
co wykorzystuje Javę nie będzie efektywne, będzie rozrzutne jeśli
chodzi o pamięć czy inne zasoby procesora...
Co mnie zszokowało to jak dowiedziałem się JAK BARDZO jest to
nieefektywne i jak bardzo marnotrawne. Spodziewałem się czegoś
na kształt 10-20% a nie że stosunek całej pamięci procesora do tej
używanej części ma być jak 4:1 czy nawet jak piszą 8:1 aby to szybko
działało... To jest dla mnie po prostu tak absurdalne że wręcz śmieszne.

do góry

On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <P...@P...com>
wrote:

>"Marcin N" <m...@o...pl> wrote in message
>news:54702897$0$2844$65785112@news.neostrada.pl...
>> W dniu 2014-11-22 06:41, Pszemol pisze:
>>> Ano tu jest to wyjaśnione - przyczyna dla której Android wymaga
>>> dużo więcej pamięci do szybkiej pracy jest znowu Java i garbage
>>> collection:
>>> http://www.quora.com/How-come-the-iPhones-1-GB-RAM-i
s-touted-to-be-able-to-compete-with-more-than-2-GB-R
AM-of-Android-phones/answers/7061202
>>>
>>>
>>> Dopiero Android z 3G ramu na pokładzie będzie pracował tak szybko
>>> jak iPhone z 1G ramu - a mniej kostek pamięci to mniej prądu z baterii!
>>
>> Widać, jak niechlujnie pisane są programy w dzisiejszych czasach.
>> Potrzebne są gigabajty, żeby użyć jakichś prostych aplikacji, które
>> mogłyby się spokojnie zmieścić w megabajtach.
>
>Wiesz co Ci powiem - zawsze mi mówiono że Java jest nieefektywna
>i że ten cały wychwalany przez nielubiących wskaźników w C/C++
>mechanizm automatycznego zarządzania pamięcią jakoś tam działa
>ale niezbyt efektywnie - więc nie jest to dla mnie nowością, że coś
>co wykorzystuje Javę nie będzie efektywne, będzie rozrzutne jeśli
>chodzi o pamięć czy inne zasoby procesora...

Nonsens. Trzeba umiec programowac. Niestety, mlodzi miszczowie
klawiatury nie maja zielonego pojecia jak pisac programy w systemach
wyposazonych w garbage collector

A.L.

do góry

On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <P...@P...com>
wrote:

>"Marcin N" <m...@o...pl> wrote in message
>news:54702897$0$2844$65785112@news.neostrada.pl...
>> W dniu 2014-11-22 06:41, Pszemol pisze:
>>> Ano tu jest to wyjaśnione - przyczyna dla której Android wymaga
>>> dużo więcej pamięci do szybkiej pracy jest znowu Java i garbage
>>> collection:
>>> http://www.quora.com/How-come-the-iPhones-1-GB-RAM-i
s-touted-to-be-able-to-compete-with-more-than-2-GB-R
AM-of-Android-phones/answers/7061202
>>>
>>>
>>> Dopiero Android z 3G ramu na pokładzie będzie pracował tak szybko
>>> jak iPhone z 1G ramu - a mniej kostek pamięci to mniej prądu z baterii!
>>
>> Widać, jak niechlujnie pisane są programy w dzisiejszych czasach.
>> Potrzebne są gigabajty, żeby użyć jakichś prostych aplikacji, które
>> mogłyby się spokojnie zmieścić w megabajtach.
>
>Wiesz co Ci powiem - zawsze mi mówiono że Java jest nieefektywna
>i że ten cały wychwalany przez nielubiących wskaźników w C/C++
>mechanizm automatycznego zarządzania pamięcią jakoś tam działa
>ale niezbyt efektywnie - więc nie jest to dla mnie nowością, że coś
>co wykorzystuje Javę nie będzie efektywne, będzie rozrzutne jeśli
>chodzi o pamięć czy inne zasoby procesora...
>Co mnie zszokowało to jak dowiedziałem się JAK BARDZO jest to
>nieefektywne i jak bardzo marnotrawne. Spodziewałem się czegoś
>na kształt 10-20% a nie że stosunek całej pamięci procesora do tej
>używanej części ma być jak 4:1 czy nawet jak piszą 8:1 aby to szybko
>działało... To jest dla mnie po prostu tak absurdalne że wręcz śmieszne.

To jest fragment dyskusji na temat jezyka Swift:

Garbage collection: It's likely that Apple considered that ARC was
good enough in most situations, and it makes interoperability with
Objective-C (compatibility in terms of memory management) much easier
to handle. Still, this would give me trouble. Lack of proper garbage
collection means more memory bugs to hunt down.

JEzyk Swift (podobnie jak Objectiwe C) MA odsmiecacz, konkretnie
implementacje zwana "reference counting". Ma sie to tak do
wspolczesnych odsmiecaczy jak woz drabiniasty do Mercedesa. To jest
wynajazek spzred 30 lat.

Jednoczesnie, jak pisza wyzej, brak porzadnego odsmeicacza kreuje
problemy z wyciekaniem pamiei ("memory leaks") i skutkuje zwiekszonymi
kosztami i czasem niezbednym na zrobienie i pzretestowanei aplikacji.
Generalnie, gospodarka pamiecia w systemach bez GC jest mniej
efektywna niz w systemach z GC i skutkuje aplikacjami wymagajacymi
wiecej pamieci.

Zapewne dlatego wsztsko w Apple jest drozsze. Podbnie jak drozszy
bylby stol robiony heblem i krajzegoa w porownaniu ze stolem zeobionym
przy pomocy automatycznych obrabiarek

Wspolczesne GC (zwlaszcza w javie) dostarczane sa w wersji "parallel".
Oznacza to ze GC moze byc wykonywany w osobnym watku, "w tle"
aplikacji. W koncu, gdy pzrecietny procesor ma 4 "cores" tzreba je
jakos wykorzystac.

A.L.

do góry

A.L. <a...@a...com> wrote:
> On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <P...@P...com>
> wrote:
>
>> "Marcin N" <m...@o...pl> wrote in message
>> news:54702897$0$2844$65785112@news.neostrada.pl...
>>> W dniu 2014-11-22 06:41, Pszemol pisze:
>>>> Ano tu jest to wyjaśnione - przyczyna dla której Android wymaga
>>>> dużo więcej pamięci do szybkiej pracy jest znowu Java i garbage
>>>> collection:
>>>> http://www.quora.com/How-come-the-iPhones-1-GB-RAM-i
s-touted-to-be-able-to-compete-with-more-than-2-GB-R
AM-of-Android-phones/answers/7061202
>>>>
>>>>
>>>> Dopiero Android z 3G ramu na pokładzie będzie pracował tak szybko
>>>> jak iPhone z 1G ramu - a mniej kostek pamięci to mniej prądu z baterii!
>>>
>>> Widać, jak niechlujnie pisane są programy w dzisiejszych czasach.
>>> Potrzebne są gigabajty, żeby użyć jakichś prostych aplikacji, które
>>> mogłyby się spokojnie zmieścić w megabajtach.
>>
>> Wiesz co Ci powiem - zawsze mi mówiono że Java jest nieefektywna
>> i że ten cały wychwalany przez nielubiących wskaźników w C/C++
>> mechanizm automatycznego zarządzania pamięcią jakoś tam działa
>> ale niezbyt efektywnie - więc nie jest to dla mnie nowością, że coś
>> co wykorzystuje Javę nie będzie efektywne, będzie rozrzutne jeśli
>> chodzi o pamięć czy inne zasoby procesora...
>> Co mnie zszokowało to jak dowiedziałem się JAK BARDZO jest to
>> nieefektywne i jak bardzo marnotrawne. Spodziewałem się czegoś
>> na kształt 10-20% a nie że stosunek całej pamięci procesora do tej
>> używanej części ma być jak 4:1 czy nawet jak piszą 8:1 aby to szybko
>> działało... To jest dla mnie po prostu tak absurdalne że wręcz śmieszne.
>
> To jest fragment dyskusji na temat jezyka Swift:
>
> Garbage collection: It's likely that Apple considered that ARC was
> good enough in most situations, and it makes interoperability with
> Objective-C (compatibility in terms of memory management) much easier
> to handle. Still, this would give me trouble. Lack of proper garbage
> collection means more memory bugs to hunt down.
>
> JEzyk Swift (podobnie jak Objectiwe C) MA odsmiecacz, konkretnie
> implementacje zwana "reference counting". Ma sie to tak do
> wspolczesnych odsmiecaczy jak woz drabiniasty do Mercedesa. To jest
> wynajazek spzred 30 lat.
>
> Jednoczesnie, jak pisza wyzej, brak porzadnego odsmeicacza kreuje
> problemy z wyciekaniem pamiei ("memory leaks") i skutkuje zwiekszonymi
> kosztami i czasem niezbednym na zrobienie i pzretestowanei aplikacji.
> Generalnie, gospodarka pamiecia w systemach bez GC jest mniej
> efektywna niz w systemach z GC i skutkuje aplikacjami wymagajacymi
> wiecej pamieci.
>
> Zapewne dlatego wsztsko w Apple jest drozsze. Podbnie jak drozszy
> bylby stol robiony heblem i krajzegoa w porownaniu ze stolem zeobionym
> przy pomocy automatycznych obrabiarek
>
> Wspolczesne GC (zwlaszcza w javie) dostarczane sa w wersji "parallel".
> Oznacza to ze GC moze byc wykonywany w osobnym watku, "w tle"
> aplikacji. W koncu, gdy pzrecietny procesor ma 4 "cores" tzreba je
> jakos wykorzystac.

Czy autor tych słów na ktore się tu powołujesz jest dla Ciebie jakimś
autorytetem?
Bo nie przytoczyłeś źródła tej wypowiedzi - może autor nie wie o czy mówi?

Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna pamięć
w moich programach nie wycieka...

Mam pewne przeczucie na podstawie pracy w innych językach programowania
gdzie nie deklaruje się rozmiaru/typu zmiennej ani nie alokuje się dla niej
specyficznego obszaru w pamieci RAM (ale brak bezposredniego doswiadzczenia
w Javie) ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
korzystanie z zasobow pamieci...

Jezykiem Swift chetnie sie zainteresuje.

do góry

Pszemol wrote:

> Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna pamięć
> w moich programach nie wycieka...

i to by było na tyle jeśli chodzi o Twoje doświadczenie. Jeszcze się
musisz dużo nauczyć

--
mst <at> gazeta <.> pl
"-Mam lęk gruntu! -Chyba wysokości?
-Wiem co mówię. To grunt zabija!" T.Pratchett

do góry

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:m4qg6j$v7i$...@d...me...

>Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna pamięć
>w moich programach nie wycieka...

Wpisz to sobie w CV.

do góry

On Sat, 22 Nov 2014 17:12:51 +0000 (UTC), Pszemol <P...@P...com>
wrote:

>A.L. <a...@a...com> wrote:
>> On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <P...@P...com>
>> wrote:
>>
>>> "Marcin N" <m...@o...pl> wrote in message
>>> news:54702897$0$2844$65785112@news.neostrada.pl...
>>>> W dniu 2014-11-22 06:41, Pszemol pisze:
>>>>> Ano tu jest to wyjaśnione - przyczyna dla której Android wymaga
>>>>> dużo więcej pamięci do szybkiej pracy jest znowu Java i garbage
>>>>> collection:
>>>>> http://www.quora.com/How-come-the-iPhones-1-GB-RAM-i
s-touted-to-be-able-to-compete-with-more-than-2-GB-R
AM-of-Android-phones/answers/7061202
>>>>>
>>>>>
>>>>> Dopiero Android z 3G ramu na pokładzie będzie pracował tak szybko
>>>>> jak iPhone z 1G ramu - a mniej kostek pamięci to mniej prądu z baterii!
>>>>
>>>> Widać, jak niechlujnie pisane są programy w dzisiejszych czasach.
>>>> Potrzebne są gigabajty, żeby użyć jakichś prostych aplikacji, które
>>>> mogłyby się spokojnie zmieścić w megabajtach.
>>>
>>> Wiesz co Ci powiem - zawsze mi mówiono że Java jest nieefektywna
>>> i że ten cały wychwalany przez nielubiących wskaźników w C/C++
>>> mechanizm automatycznego zarządzania pamięcią jakoś tam działa
>>> ale niezbyt efektywnie - więc nie jest to dla mnie nowością, że coś
>>> co wykorzystuje Javę nie będzie efektywne, będzie rozrzutne jeśli
>>> chodzi o pamięć czy inne zasoby procesora...
>>> Co mnie zszokowało to jak dowiedziałem się JAK BARDZO jest to
>>> nieefektywne i jak bardzo marnotrawne. Spodziewałem się czegoś
>>> na kształt 10-20% a nie że stosunek całej pamięci procesora do tej
>>> używanej części ma być jak 4:1 czy nawet jak piszą 8:1 aby to szybko
>>> działało... To jest dla mnie po prostu tak absurdalne że wręcz śmieszne.
>>
>> To jest fragment dyskusji na temat jezyka Swift:
>>
>> Garbage collection: It's likely that Apple considered that ARC was
>> good enough in most situations, and it makes interoperability with
>> Objective-C (compatibility in terms of memory management) much easier
>> to handle. Still, this would give me trouble. Lack of proper garbage
>> collection means more memory bugs to hunt down.
>>
>> JEzyk Swift (podobnie jak Objectiwe C) MA odsmiecacz, konkretnie
>> implementacje zwana "reference counting". Ma sie to tak do
>> wspolczesnych odsmiecaczy jak woz drabiniasty do Mercedesa. To jest
>> wynajazek spzred 30 lat.
>>
>> Jednoczesnie, jak pisza wyzej, brak porzadnego odsmeicacza kreuje
>> problemy z wyciekaniem pamiei ("memory leaks") i skutkuje zwiekszonymi
>> kosztami i czasem niezbednym na zrobienie i pzretestowanei aplikacji.
>> Generalnie, gospodarka pamiecia w systemach bez GC jest mniej
>> efektywna niz w systemach z GC i skutkuje aplikacjami wymagajacymi
>> wiecej pamieci.
>>
>> Zapewne dlatego wsztsko w Apple jest drozsze. Podbnie jak drozszy
>> bylby stol robiony heblem i krajzegoa w porownaniu ze stolem zeobionym
>> przy pomocy automatycznych obrabiarek
>>
>> Wspolczesne GC (zwlaszcza w javie) dostarczane sa w wersji "parallel".
>> Oznacza to ze GC moze byc wykonywany w osobnym watku, "w tle"
>> aplikacji. W koncu, gdy pzrecietny procesor ma 4 "cores" tzreba je
>> jakos wykorzystac.
>
>Czy autor tych słów na ktore się tu powołujesz jest dla Ciebie jakimś
>autorytetem?
>Bo nie przytoczyłeś źródła tej wypowiedzi - może autor nie wie o czy mówi?
>
>Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna pamięć
>w moich programach nie wycieka...
>

To jeszcze ciekawe jakie to sa programy

>Mam pewne przeczucie na podstawie pracy w innych językach programowania
>gdzie nie deklaruje się rozmiaru/typu zmiennej ani nie alokuje się dla niej
>specyficznego obszaru w pamieci RAM (ale brak bezposredniego doswiadzczenia
>w Javie)

Java jest akurat jezykiem silnie typowanym. Czy w C/C++ deklaruje sie
GDZIE w pamieci zmienna bedzie ulokowana? Jakos sobie nie przypominam.

> ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
>korzystanie z zasobow pamieci...
>

Niby dlaczego? Pamiec w Javie alokuje sie tak samo jak w C++. Czas
zycia obiektu w Javie kontroluje sie pzrez referencje - jak dlugo jest
referencja do obiektu, tak dlugo nei bedzie on "odsmiecony". Znane sa
techniki programwoania gdzie obiektow sie nei zwalnia (to znaczy,
zachowuje sie referencje), a trzyma zbior obiektow do pozniejszego
wykorzystania. Co parwda, takie techniki stosowano w czasach Javy 1.1,
teraz sa juz niepotzrebne.

Bez odsmiecacza nei da sie efektywnie napisac w miare skomplikowwnego
programu. Gdy w pewnym momencie mamy zaalokowane, powiedzmy, 1000
obiektow i tworaz one skomplikowany graf zaleznosci, reczena
dealokacja ani nie am sensu ani szans na powodzenie. Zwlaszcza jezeli
taka struktuar tworzona jest dynamicznie


Zreszta, C++ tez ma "proteze" odsmiecacza - patrz "smart pointers" w
bibliotece Boost. Powszechnie tez stosowany jest pzrez programistow
C++ odsmiecacz zwany Boehm garbage collector. Biblioteka taka

A.L.

do góry

"A.L." <a...@a...com> wrote in message
news:ifm17a961q00ft2i33ag4otoe0jl4d84nl@4ax.com...
>>Czy autor tych słów na ktore się tu powołujesz jest dla Ciebie jakimś
>>autorytetem?
>>Bo nie przytoczyłeś źródła tej wypowiedzi - może autor nie wie o czy mówi?

Zero komentarza?

>>Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna
>>pamięć
>>w moich programach nie wycieka...
>
> To jeszcze ciekawe jakie to sa programy

Głównie jest to embedded computing (nie pecety).

>>Mam pewne przeczucie na podstawie pracy w innych językach programowania
>>gdzie nie deklaruje się rozmiaru/typu zmiennej ani nie alokuje się dla
>>niej
>>specyficznego obszaru w pamieci RAM (ale brak bezposredniego
>>doswiadzczenia
>>w Javie)
>
> Java jest akurat jezykiem silnie typowanym. Czy w C/C++ deklaruje sie
> GDZIE w pamieci zmienna bedzie ulokowana? Jakos sobie nie przypominam.

Na pecetach pewnie nie deklaruje się zwyczajowo, choć też można.
Ale na innych platformach często chcesz wiedzieć która zmienna
w której kostce siedzi bo np. ta kostka ma podtrzymanie bateryjne
a druga go nie ma...

>> ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
>>korzystanie z zasobow pamieci...
>
> Niby dlaczego? Pamiec w Javie alokuje sie tak samo jak w C++.

Jasne. Są pointery/wskaźniki do fizycznej pamięci operacyjnej :-)

> Czas
> zycia obiektu w Javie kontroluje sie pzrez referencje - jak dlugo jest
> referencja do obiektu, tak dlugo nei bedzie on "odsmiecony". Znane sa
> techniki programwoania gdzie obiektow sie nei zwalnia (to znaczy,
> zachowuje sie referencje), a trzyma zbior obiektow do pozniejszego
> wykorzystania. Co parwda, takie techniki stosowano w czasach Javy 1.1,
> teraz sa juz niepotzrebne.

W technice embedded unika się dynamicznej alokacji pamięci
i związanej z nią fragmentacją wolnej pamięci - to są urządzenia
które mają pracować bez restartu/resetu miesiącami, latami
i nic tam nie może się samo w czasie używania "bałaganić"
ani śmiecić żeby trzeba było śmieci zbierać...

Ale oczywiście smartfone nie zawsze można tak zakwalifikować.
Tym dzisiejszym smartfonom bliżej pecetowi niż komputerom embedded.

> Bez odsmiecacza nei da sie efektywnie napisac w miare skomplikowwnego
> programu. Gdy w pewnym momencie mamy zaalokowane, powiedzmy,
> 1000 obiektow i tworaz one skomplikowany graf zaleznosci, reczena
> dealokacja ani nie am sensu ani szans na powodzenie. Zwlaszcza jezeli
> taka struktuar tworzona jest dynamicznie

Ilość obiektów rzędu 1000 jest nieogarnięcia dla jednego człowieka, ale
dla komputera nie stanowią takie liczby obiektów żadnego problemu...
Co jest ważniejsze aby ogarnąć strukturę danych programu i stworzyć
jako programista mechanizmy którymi komputer za nas będzie tymi
obiektami zarządzał.

> Zreszta, C++ tez ma "proteze" odsmiecacza - patrz "smart pointers" w
> bibliotece Boost. Powszechnie tez stosowany jest pzrez programistow
> C++ odsmiecacz zwany Boehm garbage collector. Biblioteka taka

Bibliotek różnych i środowisk można dołożyć tysiące i zmienia to
jedynie punkt widzenia dla aplikacji która z biblioteki korzysta...
Ani nie masz gwarancji że ktoś zrobi alokację pomijając bibliotekę
ani nie masz gwarancji że sama biblioteka nie ma jakiegoś robala.

Ale chyba oddaliliśmy się nieco od tematu głównego...
Sugerujesz może że inicjujący ten wątek cytat ma błędy?
Z czymś się nie zgadzasz? Może podsumowałbyś ze swojej strony?

do góry

Pszemol wystukał, co następuje:

>> Widać, jak niechlujnie pisane są programy w dzisiejszych czasach.
>> Potrzebne są gigabajty, żeby użyć jakichś prostych aplikacji, które
>> mogłyby się spokojnie zmieścić w megabajtach.
>
> Wiesz co Ci powiem - zawsze mi mówiono że Java jest nieefektywna
> i że ten cały wychwalany przez nielubiących wskaźników w C/C++
> mechanizm automatycznego zarządzania pamięcią jakoś tam działa
> ale niezbyt efektywnie - więc nie jest to dla mnie nowością, że coś
> co wykorzystuje Javę nie będzie efektywne, będzie rozrzutne jeśli
> chodzi o pamięć czy inne zasoby procesora...
> Co mnie zszokowało to jak dowiedziałem się JAK BARDZO jest to
> nieefektywne i jak bardzo marnotrawne. Spodziewałem się czegoś
> na kształt 10-20% a nie że stosunek całej pamięci procesora do tej
> używanej części ma być jak 4:1 czy nawet jak piszą 8:1 aby to szybko
> działało... To jest dla mnie po prostu tak absurdalne że wręcz śmieszne.

Borze... Ty na prawdę jesteś ignorantem... primo - java to nie jvm; po wtóre
- głupie ARC jest i w obj-c i w swifcie. Coś dzwoni, nawet wiesz że może to
być kościół... a może jednak krowi dzwonek

do góry