Hangi Programlama Dili Kullanıldı?

Hangi Programlama Dili Kullanıldı?

Arkadaşlar ben yeni Opera kullanıcılarındanım. Doğrusunu söylemek gerekir, Opera'nın son sürümü gayet beğendim. Fakat merak ettiğim bişey var. Opera hangi dille yazıldı. birçok yere baktım ama bu konuda bişey bulamadım. beni bu konuda aydınlatabilirseniz sevinirim.Teşekkürler

"Firefox is written in c++, Opera is invented in C++"

http://en.wikipedia.org/wiki/Comparison_of_layout_engines
Opera, Kendi geliştirdiği Presto Motorunu kullanıyor.

Sadece C++ kullaniyoruz. Bazi yerlerde C kodu kullaniliyor. Bunlar genelde disaridan gelen kutuphanelerdeki "legacy" kod. Mesela zlib ve OpenSSL gibi. Opera'nin kendi kodu, C++ kodu. Ancak C++'in bircok ozelligini sonuna kadar kullanmiyoruz. Cunku bu baska platformlarda derlemeyi zorlastiriyor. Bazi elektronik aletler, kendi islemcileri yada isletim sistemleri icin ufak derleyiciler hazirliyorlar. Bu derleyiciler ISO C++ standardinin tamimini degil sadece bir kismini iceriyor (ki onu bile tam desteklemiyorlar). Bu sebeple Opera cekirdek kodu C++ ozelliklerinin yogun olarak kullanildigi bir yer degil; oldukca basit ve duz bir C++ kodu - oturup okuyabilirsiniz. Bazi platformlar C++'in bazi kutuphanelerini yada ozelliklerini kullanabiliyorlar. Ben Windows Mobile basmuhendisiyken, C++ kullanimina onem verdim. Projeye ilk basladigimizda dilin cesitli ozelliklerini kullandik. Ozaman Opera cekirdegi bazi konularda platformun C++ kullanimini etkiliyecek teknikler kullaniyordu. Bu sebeple cekirtek takimiyla fikir ayriliklarimiz oldu. Ama sonra cekirdek gerekli degisiklikleri yapti. Eski Windows Mobile kodu (Opera 9), C++ algoritmalarini kullaniyordu . Bunlarla uyumlu olmasi icin, mesela sayfa gecmislerini goruntuleyen kodta std::vector kullanimini sagladim (daha karmasik bir yapi kullanmistim, ama sonra "en fazla 10 sonuc" goruntulenecegini ogrenince vector'e donduk). Kodu 2007'de bir gece yarisi vector kullanarak yazdim (bu prototip halen kullaniliyor). Ancak sonra OOM (Out of Memory) durumlarinda sorun yasadik. C++'ta bu durumda std::bad_alloc tipinde bir exception atmamiz lazim (daha dogrusu vector kendisi bizim kontrolumuz disinda atiyor). Ancak exception destegi olmadan derliyorduk. Cozumunu bulup gerekli gecisleri saglayacak ufak kutuphaneyi de hazirladim. Bu sayede yine vector kullaniyoruz (ancak ozel bir tip) ve hafiza yetmediginde farkli bir yontemle bize bildiriyor.

Carakan, yeni JavaScript motoru, C++ ile yazildi. Sonunda calistiginiz platforma uygun makine kodu uretiyor. Eger x86 komut seti destekleyen bir platformdaysaniz, x86, eger ARM (neredeyse butun akilli telefonlar) ise ARM kodu uretiyor. Ama bunu calisirken yapiyor. Carakan'da Mini takimiyla birlikte daha once onerdigimiz farkli bir yontem kullaniliyor. Google V8'e oldukca yakin bir teknik. Zaten bu konuda yapilabilecek cok farkli seyler yok. Ozetle, eskiden biz JavaScript kodunu "yorumluyor"duk. Simdi ise "derliyoruz". Yorumlarken birsuru farkli durum var. Mesela:

var x = 1;
var y = x + x;

Durumunda, biz bunu yaklasik soyle yorumluyorduk (bu kismini aslinda acikca yazamiyorum; Firefox bu sekilde yapiyor, bizimkisi de buna cok yakin)

x nesnesini olustur
int(x) = 1
eger (x bir tam sayiysa) ve (x'e x ekledigimde bir tamsayi olursa)
 x = box(int(x) + int(x));
aksi takdirde eger (x bir double ise)
 x = box(double(x) + double(x));
aksi takdirde eger (x bir yaziysa)
 x = box(birlestir(x, x));
...

Butun bu yazdiklarin sonra yeniden makine koduna derleniyor. Bu oldukca yavas bir yontem. Ayrica artik/cop toplayici (Garbage Collector - GC) yontemimiz de biraz yavasti. Mini'de bu sorun daha barizdi (yani sunucu tarafinda). Pek te verimli olmayan algoritmamiz sebebiyle Mini sunucularinda ciddi sorunlar oluyordu.

JavaScript'te veri tipleri olmadigi icin bu sorunlar yasaniyor. Mesela C, C++, Java yada C#'ta veri tipini acikca veriyoruz. Dolayisiyla derleyici veri tipinin ne oldugunu daha onceden biliyor. Bu da derleyiciye (yada JIT derleyiciye) oldukca iyi bir firsat veriyor. Boylece yukaridaki JavaScript kodu aslinda asagidaki gibi kisa bir makine koduna donusuveriyor:

; i386
mov eax, [ebp + 4]  ; x'in hafizadaki yerinin ebp+4 oldugunu var sayalim
add eax, [ebp + 4]
; akilli derleyici ise... sal [ebp + 4], 1 yapabilir
mov [ebp + 8], eax  ; y'nin yerini ebp+8 oldugunu var sayalim

Emin degilim ama yaklasik boyle birseyler olabilir. Dedigim gibi, akilli bir derleyici "arithmetic shift left" yapabilir. Bir sayiyi sola kaydirmak demek, 2 ile carpmak demek. Bu islem genelde cok hizli gerceklesir. Ama arada hafiza referansi var (ebp+4, hafizada bir adres). Belki bir register'a alsaydik daha hizli olabilirdi.

Carakan bizim onceden kullandigimiz yorumlama yonteminin aksine, yukaridaki kisa makine koduna yakin birsey uretiyor ve kodu analiz ediyor. Ayrica GC olarak da oldukca hizli ve bilindik bir yontem kullaniyor. Ancak bu tercume, tahmin edebileceginiz gibi, bu kadar kolay olmuyor. Once bizim kodu bir defa dolasmamiz lazim. Yani bir cesit derlemek gerekli. Bu derleme sonunda biz kodun neye benzedigini yaklasik olarak goruyoruz. Sonra bunu optimize ediyoruz. Ama arada tuhaf seyler de var. Merak ederseniz onlara da girerim. Ancak bu motorlarin cogu birbirine benziyor; isterseniz Google V8 yada TraceMonkey hakkindaki seyleri de okuyabilirsiniz. Opera (Carakan) bazi seyleri daha profesyonelce yapiyor ama ben bahsedemiyorum

Gectigimiz 3 hafta boyunca Opera 10'un Windows Mobile surumunu optimize etmeye calisiyoruz. Su dakikalarda da son yamalari gonderiyorum. Yarin sabahki derleme gorucuye cikacak. Bizim platformda %12 bir artis oldu. Bu yamalarin hepsi cekirdek kodu uzerinde oldu. Yani onumuzdeki hafta cekirdek takimiyla toplantimiz olacak ve bu yamalar cekirdege gidecek. Bunlardan en ilginci gecen hafta Persembe gecesi gonderdigim bir yama. Simdi, cekirdekteki hafiza yoneticisi hafizadaki bos yerleri isaretliyor ve buldugu ilk boslugu isteyene veriyor. Buradaki bazi kontrolleri kaldirip 2'lik sayi tabaninda "binary arithmetic" yaptim ve ilk boslugu 2 islemci tikinde hesapladim. Bu degisiklik bize %8 performans kazandirdi (bazi sayfalarda %330'a cikiyor; ortalama %30 ama benim olcumlerin %8 diyor). Dolayisiyla butun Opera kullanicilarinin faydalanacagini dusunuyoruz. Ancak bazi degisiklikler cekirdek tarafindan alinmayacak diye dusunuyoruz. Masaustu bilgisayarlarda bu performans sorunlari cok belli olmuyor. Ama bir cep telefonunda yavas kisimlar acikca ortaya cikiyor. Biz bunlari inceliyoruz, istatistiki ve bilimsel veriler topluyoruz. Sonra cekirdek algoritmalarini tahtaya yaziyoruz, 3-5 kisi bu algoritmalari inceliyoruz. Elimizdeki istatistiki verilere de dayanarak optimum cozumleri buluyoruz. Bu konuda derleyicilerimize de yardimci oluyoruz. Sonucta bizim yazdigimiz C++ kodunu bir derleyici alip makine koduna ceviriyor. Yani son durak derleyici. Eger derleyiciye yeterince ipucu verirsek, onun isini kolaylastirirsak, o da kodu optimum sekilde uretiyor ve biz hizli bir kod elde ediyoruz. Acikcasi bu son haftalardaki calismalarla ilgili bir blog basligi yazmayi dusunuyordum. Eger yoneticilerim izin verirse, bazi detaylara girebilirim, ama biraz teknik bir tartisma olacak.

Originally posted by ismailp:

Merak ederseniz onlara da girerim.

Ben merak ediyorum Burada yazılanların %50'sini "sanırım böyle bir şey" diyerek okudum ama olsun.

Bu konuda ne kader detaya girip giremeyecegimi yoneticime sordum, cevabina gore bir blog post yazabilirim. Bu sirada Firefox orneginden devam edelim. Mesela:

x = "a";
y[x + x] = 1;

kodunun anlami; y'nin "aa" alanini 1'e esitle demek. Bunu yorumlamaya kalksaydik, x'in ne oldugunu bilmemiz lazimdi. x bir tam sayi, rasyonel sayi, bir boolean, yazi yada bir nesne gibi farkli tiplerde olabilirdi. y'nin tipi ise henuz belli degil(di). x, ilk basta bir yazi (string) gibi duruyor. Dolayisiyla + islemi aslinda yazi ekleme (string concatenation) olarak islenecek. Bu ifadenin sonucu (x+x) yine bir yazi olacak. Bu durumda y'nin bir string alani olmasi lazim. Eger y nesnesinin boyle bir alani yoksa, bizim bu alani eklememiz lazim. Bu durumda y'ye "aa" diye bir alan ekliyoruz ve bu alana 1 degerini veriyoruz (yapiyoruz, ediyoruz derken butun JavaScript motorlarini kastediyorum - hepsi ayni seyi yapiyor, ama farkli yontemlerle yapiyor). Burada kimin neyi nasil yaptigi onemli. JavaScript'in dinamik bir dil olmasi, yada daha dogrusu "strongly typed" olmamasindan dolayi bircok zorluklar var. Bence bu konuyu en iyi V8 acikliyor. Youtube'ta V8 videolarini izleyebilirsiniz. Surekli bunu referans gostermemin iki sebebi var; birincisi, V8 son derece guzel bir motor (kisisel gorusum, Opera'nin gorusunu bilemem), digeri de V8'in acik kodlu olusu. V8'in yazarlarinin gecmislerini de biliyorum. O da bir Iskandinav urunu; Danimarka'nin kuzeyinden, Aarhus'tan cikma bir urun.

Sadece bu konu bilgisayar muhendisligi 2. sinif derslerinden baslayip doktora tezlerine kadar uzaniyor. Ben elektronik okudugum icin bana birazcik uzak ama ogrenmek kolay.

C yada C++ gibi "stringly typed" dillerde genelde derleyici ikiye ayrilir; front-end ve back-end. Yani on yuz (front end), kodu on islemden gecirir (preprocess) ve ardindan bir AST (Abstract Syntax Tree) olusturur. Bu agac, programin ozet goruntusunu verir. Mesela:

x = y + z;

kodu, AST olusturuldugunda:

    +
  /  \
x     z

benzer bir "agac" olusturur (birebir boyle olmayabilir; derleyiciden derleyiciye de degisir). Bu agac, programin yapisini gosterir. Sonra bu agac "dolasilir". Eger mumkun bir basitlestirme/optimizasyon varsa, o yapilir. Mesela "x+x" ifadesi, 2*x olarak sadelestirilebilir, sonunda da derleyici "bunu 1 basamak sola kaydirirsam, 2 ile carpmis olurum" diyebilir (2'lik sayi tabaninda sola kaydirmak, 2 ile carpmak demektir ve cok hizli bir islemdir). Ama bu herzaman boyle olmaz elbette Mesela "string" (yazi) tiplerini sola kaydiramazsiniz. Hangi akilli iki yaziyi birbirine + ile eklemeyi dusundu ben de bilmiyorum (bence sacma) ama mesele boyle... Bu durumda veri tipinin (mesela "string"), varsa + operatoru devreye girer (yada dil bunu ne sekilde yorumlarsa artik, o fonksiyon devreye girer). Dolayisiyla, mesela:

x = "a";
y = x + x;
[code]
kodu, aslinda x'i x'in sonuna ekle demektir. Acikcasi sanal makinelerde nesneler genelde "immutable" durumundadir; yani degistirilemezler. Bir yazinin sonuna yeni bir yazi eklemek yerine sanal makine yepyeni bir nesne olusturur, eskisi cop olur ve bu iki yaziyi birbirine ekleyip yeni nesnede saklar. Yani mesela:
[code]
x = "a";
x = x + "b";

benzeri bir kod aslinda:

x = "a";
x = new string(string.concat("a", "a"));

gibi birsey olur. Yani yeni nesne, gercekten yepyeni bir nesnedir ve eski iki nesnenin birbirine eklenmesi sonunda olusur.

AST, yani soyut sintaks agaci, programin yapisi hakkinda oldukca iyi bir goruntu verir. Bu yapi ardindan bir yada daha fazla defa dolasilip optimize edilir. Optimizasyon burada bitmez. Eger bir JIT (Just in Time compiler - aninda derleyici) ortaminda, "hot spot" (mesela Sun Java HotSpot) yada tracing yapan sanal makineler bu uretilen makine kodunda en fazla islenen alanlari tesbit ederler. Bu kisimlardaki optimizasyonlar cok kazandirir. Cunku bu "hot spot" (sicak noktalar mi desek?) alanlar saniyede yuz yada belki milyonlarca defa calistirilabilir. Istatistiki olarak, programlarin cogu bir dongu icerisinde yada bir siralama (sorting) yaparlar. Bu yollarda 1 islemci tikini optimize ederseniz, sonunda 100 yada belki 1 milyon tiki optimize etmis olursunuz.

Ayrica calistiginiz platform da onemli. Rasyonel sayi islemlerinde, mesela masaustu i386 sistemlerde, 2 secenegimiz var; ya SSE komut seti yada FPU komut seti kullanilacak. Bircok sanal makine SSE kullaniyor. SSE komut seti daha basit ve ayni islemi birden fazla veri uzerinde gerceklestirebiliyor. Buna ornek, vektorel ifadeler. SSE komut seti, SIMD, yani "Tek Komut Coklu Veri" modelinde calisiyor. Bu sayede, mesela, tek bir komut ile 4 adet rasyonel sayi uzeirnden 4 islem gerceklestirilebiliyor. Bu oldukca onemli bir gelisme. Yeni komut setleri cok daha karmasik komutlari da destekliyor.

AST'ye geri donersek, bu agac tarandiktan sonra (yani on kisim, front end) isini bitirdikten sonra, uretilen AST, back-end'e (arka uc) veriliyor. Bu kisim AST optimizasyonu ve makine kodu uretiminden sorumlu. Genelde derleyici takimlarinda front-end ve back-end yazanlar ayri gruplardir. Cunku ikisi gercekten farkli alanlardir. Aralarindaki tek iletisim ise uretilen AST'dir. Back-end, uretilen AST'yi alir, mumkunse optimize eder (yukarida bahsettigim; "acabe 2 ile carpmak yerine sola kaydirsak mi?" gibi kararlari verir). Back-end, AST'yi optimize ettikten sonra son geciste (yada belki ilk geciste) makine kodu uretmeye baslar. Ornegin, + islemi icin iki adet "operand" lazim (Turkce'si nedir, gercekten bilemiyorum; terim desek...). Bu terimler zaten "evaluate" edilmis (degerlendirilmis) yapilar olur. Mesela iki tam sayi ekleme islemi icin (3 ve 5 diye dusunelim), back-end, asagidaki yapiyi dolasir ve uygun makine kodunu uretir:

x = 3;
y = 5;
z = 3 + 5;
[code]
AST:
[code]
    =
  /   \
 z      +
       /  \
      3    5

Sonunda asagidakine benzer birsey olusturabilir:

mov eax, 3
add eax, 5
mov [z], eax

Saat gec oldu ama tahminimce boyle birsey olabilir (i386).

JavaScript'te bunlara karar vermek oldukca zor. Cunku bu dilde tipler yok; x'in tam sayi mi, yazi mi, boolean mi yoksa baska bir nesne mi olup olmadigini bilemiyoruz. C ve C++ gibi "translation unit" uzerine bina edilmis bir dil olmayisindan dolayi bircok zorluklar var. Benim anlatikklarimin cogu aslinda JavaScript ile ilgili degil de daha cok "strongly typed" dillerle, mesela C, C++, Java yada C# gibi dillerle ilgili. Cunku asagidakini JavaScript'te yapabilirsiniz, ama "strongly typed" hicbir dilde yapamazinis, kod zaten derlemez, dolayisiyla makine kodu da uretilmez:

for (i = 0; i < 100; ++i) {
  if ((i & 2) == 0)
      print(i);
  else
      i = "";
}

i'nin tek tam sayi oldugu durumlarda i'yi yaz, yoksa ""'a esitle diyoruz. "" bir yazi. i'nin tipi ne? Derdimi umarim anlatabilmisimdir!

Bundan sonra bir de "cop toplama" (Garbage Collection) sorunu var! Bu islemler sonunda bazi nesneler "garbage" olabilir. Bir nesnenin cop olmasi demek, sanal makineden dogrudan yada diger nesnelerden herhangi bir referans yoksa, o nesne "cop" demektir (kullanilmiyor). Dolayisiyla toplanmasi lazim. Bu toplama islemiyle ilgili herhalde en az 20 tane akademik makale ve proje bulabilirsiniz Copleri toplrken nesnelerin "kökleri" arastirilir. Bu kokler ya sanal makine icerisindendir yada diger nesnelerdendir. Kokleri olmayan nesneler toplanacaktir. Toplanacak (yani yok edilecek) nesneler belirlendikten sonra, bu "cop toplama" donusumunden geriye kalanlar (yasayanlar) bir sonraki nesile (generation) terfi ederler; emeklilik gibi... Pek iyi bir benzetme degil ama, eger emeklilik yasiniz/prim gununuz gelmeden vefat etmezeniz, emekli olursunuz. Olmazsaniz, vefat edersiniz ve eksilirsiniz. Hos bir ornek degil, ama bu saatte aklima gelen en yakin benzetme bu. Emekli olursaniz, bir sonraki nesile terfi etmis olursunuz. Eger bu yasa kadar yasamissaniz, bundan sonra yasayabilme olasiliginiz daha yuksek demektir. Artik toplayicilarda, genelde en az iki jenerasyon vardir; yeni doganlar ve emekli olanlar. Eger bir nesne, artik toplamadan kurtulursa (yani toplanip yokedilmezse) bir sonraki jenerasyona gecer. Yeni nesilin oldugu kisim arada tamamen silinip yeniden olusturulabilir. Bu islem, sanal makinenin hafiza kullanimini duzenler ve bolunmeleri engeller - yani iyi birseydir. Dedigim gibi bu konuda cok farkli yaklasimlar var. Carakan, jenerasyonel bir toplama ile calisiyor; iki jenerasyon var - yeni nesneler ve eskiler (eski dedigimiz, son toplamadan sag kalanlar).

Çok güzel bir mesaj/yazı olmuş.Optimize konusunundaki sorularımın bir kısmı çözüldü diyebilirim. Daha merak ettiğim şeyler çok var ama işi tembelliğe bağlayıp sürekli soru sormaya gerek yok. C++ için Başlangıç seviyesi kitapları okudum, pratikleri yaptım ama zaten bunlar çoğu kişinin yaptığı/bildiği şeyler. Orta - İleri seviye kitap/kaynak önerileriniz nelerdir.

Bence once veri yapilarini ve algoritmalari iyi anlamak lazim. Bunlar oldukca basit gibi gorunse de aslinda hersey bir sekilde bu yapilar uzerine ve algoritmalar ile gerceklestiriliyor. Mesela bir web tarayici icerigi isledikten sonra bir agac olusturur. Nasil bir agac olusturacagi, bu agaci nasil dolasacagi dilden bagimsiz, matematiksel bir konudur. Burada vereceginiz kararlar, tarayicinin ne kadar hizli yada ne kadar ufak (compact) olacagi gibi sonuclar uretecek.

C++ ile ilgili benim tavsiyem forumlara bakmak, bol bol kod okumak (baskalarinin kodlarini) ve ardindan bazi seyleri tek basina, kopya cekmeden gerceklestirebilmek. Bu antrenmanlarin onemli oldugunu dusunuyorum. C++'i muhtemelen asla tamamamen super guru olarak hazmetmek mumkun degil. Eskikleri de fazlalari da cok. Bu bakimdan cok elestiri de alir zaten. Buyuk projelerin bazilarinda kod cok acik secik yazilmistir. Ornegin Microsoft SSCLI 2.0 kodunu cok severim. Kitap tavsiyem... Sutter & Alexandrescu: C++ Coding Standards. Cok ogretici bir kitap degildir, daha cok "sunu yap, bunlari yapma" gibi birsey. Ama Stroustrup: The Design and Evolution of C++ kitabi daha fazla icerige sahip. Son olarak aklima gelen, sadece STL'e odaklanmis olan, STL Tutorial and Reference Guide: C++ Programming with the Standard Template Library (bu son kitaptan emin degilim acikcasi).

Öğrenme konusunda bir sıkıntım yok. Tek sıkıntım yanlış şeyler öğrenip zaman kaybetmek. Kitaplar için teşekkürler.

Originally posted by ismailp:

Ben Windows Mobile basmuhendisiyken

Şu andaki göreviniz nedir?

---
Yazının geri kalanı hakkında yorum yapamıyorum çünkü "bir şey anladıysam arap olayım" gibi bir dumura uğramış haldeyim.

Originally posted by metude:

Şu andaki göreviniz nedir?

iPhone için Opera Mini yapımında çalıştı. Şimdi de sanırım o departmanda...

Her yerdeyim Şaka bir yana, benim görev tanımım tam belirli değil. Joker gibi oldum. "Devices" bölümü, yani masaüstü olmayan, aletler bölümü beni bırakmamaya and içmiş! Ayrıca bölüm olarak ta isim değiştirdik. Eskiden Windows Mobile bizim asıl ürünümüzdü. Bugün ise her türlü işletim sistemi için çalışıyoruz. Yani kısaca "aletlerler" bölümündeyim. Bir ay içerisinde 3 ayrı platform için proje yaptık. Şu sıralar yine bir Android ile ilgiliyim. Haftaya bir Linux var. Yandaki odada Windows CE için birşeyler yapılıyor. Piyasa güzel anlayacağınız!

@metude; herkes anlasaydı, biz işsiz kalırdık yahu Şaka bir yana, yazılımcılar için önemli konular. Derleyici (compiler) ile ilgili notların çoğunda da bahsedilir zaten; genelde bilgisayar mühendislerin çoğu da bir derleyici yazmazlar, ama bazen belirli bir konu için derleyici/yorumlayıcı yazılması gerekebilir. Onun dışında zaten ağaç yapıları bilindik matematik konuları.

@greench; sadece birkaç karakter kod yazdım iPhone için. Onu da son sürümde kullanıp kullanmadıklarını bilmiyorum!

Originally posted by ismailp:

@greench; sadece birkaç karakter kod yazdım iPhone için. Onu da son sürümde kullanıp kullanmadıklarını bilmiyorum!

Bir kaç karakter dediğin kaç bin satırdır acep

Originally posted by greench:

acep

Originally posted by 7nbitirdin:

En olumsuz ozelligi dosya indirememesi safariye aktarmasi!!!

iPhone kullanmadım ama bu sanırım Java ile ilgili bir kısıtlama, bazı cep telefonlarında da aynı şey oluyor. Telefonun doğal tarayıcısına aktarıyor.

Originally posted by metude:

iPhone kullanmadım ama bu sanırım Java ile ilgili bir kısıtlama, bazı cep telefonlarında da aynı şey oluyor. Telefonun doğal tarayıcısına aktarıyor.

iPhone'daki Opera Java tabanlı değil diye biliyorum. Apple'ın sunduğu SDK ile yapıldı. Dolayısıyla tam bir Java'dan söz etmek mümkün değil. Sınırlama Apple'ın SDK'sıyla ilgili olabilir ya da bir bug(sanmıyorum) olabilir.

off off hatta off ki ne off. Yorumlar, yazılar hepsi harika. Biz henüz okumakla yetinebiilyoruz , fazla ayak altında dolasmamak lazım.Bu konuyu takibe alayım hemen.
iyi forumlar herkeze.