Gün 3 - Mayıs 29, "Keynote", Andrei Alexandrescu

(Ali'nin yorumu: Bu konuşma çok güzeldi. Ses getireceğinden eminim. Özellikle, üstü kapalı olarak C++'ın sonunda açıkça geride kalacağını da belirtmiş oluyor çünkü Stroustrup 'statif if'e kesinlikle karşı.)

Andrei'nin konuşması ilginç başladı: "Türden bağımsız programlamayı (generic programming) artık bırakmamız gerekiyor" gibi bir sözle başladı ("Generic programming must go").

Şunları söylüyor:

Açık yararlarına rağmen, generic programming esnek olmayabilir (fazla "ridgid"dir.)

Dört adet isimli aralık çeşidi olduğuna göre, türden bağımsız programlamaya karşı hareket ediyoruz: InputRange, ForwardRange, BidirectionalRange, RandomAccessRange.

Bir de şu sabit kavramları tanımladık: hasLength, isInfinite, hasSlicing, hasMobileElements.

"İsim" üzerine odaklansak, şunları tanımlamak gerekirdi: InputRangeWLength, ForwardRangeWLength, BidirectionalRangeWLength, RandomAccessRangeWLength, InputRangeInfinite, ForwardRangeInfinite, BidirectionalRangeInfinite, RandomAccessRangeInfinite, RandomAccessRangeWSlicing, RandomAccessRangeWLengthWSlicing, RandomAccessRangeInfiniteWSlicing, ...

(Bu noktada şimdilerde üzerinde çalıştığı bellek ayırma modülünü (std.allocator) yazarken karşılaştığı konulara geçti.)

Bellek ayırma konusunda şu kavramlar var:

Memory allocation is high-vocabulary
◦ alignment
◦ (dynamically) aligned allocation
◦ rounding up/quantization
◦ in-place expansion
◦ reallocation
◦ contiguous vs. non-contiguous
◦ ownership
◦ resolving internal pointers
◦ deallocation
◦ per-instance state vs. monostate
◦ thread-local vs. shared

Bunların bütün kombinasyonlarına karşılık isimler bulmak saçma olurdu.

Descartes'a gönderme yapıyor: Tüm bildiklerinizi bir kenara bırakın. Şimdi, bellek ayıran koddan ne beklediğimizi düşünelim: Tabii ki allocate()...

Önerisi: Tasarımlarımızı içgözlem (introspection) üzerine kuralım.

Ve tabii allocate()'in yanında bir de 'hizalama birimine' (alignment) ihtiyacımız var.

En basit bellek ayırıcı, bir göstergeyi ilerletmektir. ("Push the pointer" dediği saydam (13/32)).

Şimdi bu bellek ayırıcıya yeni beceriler eklemeye başlıyor: 1'den farklı hizalama birimi, vs.

Sonra birisi başaramazsa diğeri kullanılan iki ayırıcılı FallbackAllocator'ı gösteriyor. (17/32)

FallbackAllocator'ta ilginç bir noktaya değiniyor: null'la karşılaştırmak yerine '(r.length != n)' karşılaştırmasını yapmasının nedeni, kullanıcı 0 bayt ayırmak istediğinde başarılı olmamızın gerekmesiymiş.

Yeni bir temel işleme ihtiyacımız var: "owns()" (ayırıcıya bellek parçasının sahibi olup olmadığını sorabilmemiz için).

Ana ayırıcı (yani, P) owns()'u ve deallocate()'i sunabilir ama ikincil ayırıcının (yani, F) owns()'u sunması gerekmiyor.

static if'i kullanarak bu tür davranışlara isim vermekten kurtulduğunu söylüyor. P ve F'nin ne sunduklarına bağlı olarak istediğimiz davranışı isimlendirme gereği duymadan elde ediyoruz.

Bu noktada üzerinde çalıştığı modülün belgesine gidiyor:

http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html

Bundan sonra adım adım tasarım üzerinde duruyor. 'static if' çok yararlı, vs.

reallocate()'in işleyişi sırasında gereken crossAllocatorMove() üzerinde duruyor (yani, belleğin birincil ve ikincil ayırıcılar arasında geçirilmesi gereği).

Burada D ile övünüyor: Diğer dillerde bu işlemleri kaç satırda yapabilirsiniz?

Belirli büyüklüğe göre "küçük" veya "büyük" ayrımı yapan Segregator'ı tanıtıyor.

Saydam 26/32: İçgözleme dayanan tasarım alt parçalardan üst parçalar oluşturmaya yol açıyor.

• Türden bağımsız programlama başarısız olmuştur.

• Kavramlar (concepts) başarısız olmuştur.

• İçgözlem kullanın

• 'static if' ile mantıksal ifadeler kurun

Concepts'in sorunu, herşeye ad vermenin gerekmesiymiş. Kendisi bu çalışma sırasında aydınlanmış ve mutlu. :)

Kod da şuradaymış:

https://github.com/andralex/phobos/tree/allocator/std/experimental/allocator

Saydam 29/32: Herkese soru: Farklı tür ayırıcılardan (Region, HeapBlock, vs.) oluşan diziyi nasıl tasarlardınız? Yeni ayırıcı nasıl eklenirdi? Güzel bir soru: Bu diziyi nerede tutardınız? (Yani, ayırıcı dizisini nerede ayırırdınız?)

Şöyle çözmüş (30/32):

• Çağrı yığıtında bir ayırıcı kur

• Onu kullanarak dizi için bellek ayır

• İlk ayırıcıyı oraya taşı

• vs.

Özet (31/32):

• Türden bağımsız programlama yeterince esnek değildir

• Onun yerine içgözleme dayanan tasarım öneriyor

• Yalnızca gereken parçaları sunun, gerisini yeteneklere bağlı olarak sunun

• İçgözlemi kullanarak küçük parçalardan büyük parçalar oluşturun

(32/32):

Derleme zamanındaki içgözlem + CTFE (derleme zamanında işlev işletme) + mantıksal ifadeler + static if = KAZANÇ.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Gün 3 - Mayıs 29, "Why I Love D: An Undergrad Experience", Erich Gubler

(Chuck'ın öğrencisi, okul projelerinde D'yi nasıl kullandığının ve ne yararlar gördüğünün hikayesini anlatacak. Güz döneminde mezun olacakmış.)

Chuck tanıtıyor: İlk olarak C++ ile başlamış, Chuck'ın dersinde D'yi tanımış.

---

Asıl amacım, moral yükseltmek olacak.

D'nin olanaklarını nasıl keşfettiğime de odaklanacağım.

Deneyimli D'ciler bu konuşmadan pek bir şey almayacaklardır ama alabilirler de.

Herşey Chuck'la başladı. Önce C#, C++, Java filan öğreniriz. Chuck, fonksiyonel programlama dersine ML'i anlatmakla başlar. Sonra D'yi öğrendik ve çok sevdim.

Sanal makine projemi D'ye geçirmeye karar verdim.

Walter'a ve Andrei'ye teşekkür ediyorum.

D'yi sevdiren ilk gözlemlerim:

• Ayrı ayrı .h ve .cpp dosyaları yazma gerekmemesi çok hoş geldi. D'ye geçtiğimde modül kavramını çok beğendim.

• Artık gösterge kullanmak zorunda değildim.

• İsim alanı işlecine gerek yoktu. (C++'taki :: işleci.)

Sonuçta, C++'tan D'ye geçirme işlemi çok kolay oldu.

Enumlar çok yararlıydı: string ve enum değeri arasındaki dönüşümler başka dillerde çok zahmetlidir. switch deyimi, hash table, vs. kötü çözümlerdir. D'de ise derleme zamanındaki olanakları kullanarak basitçe ve hızlıca çözüyoruz. r.to!string çok kolay.

Evet, D süper...

Hocamızın önerdiği bir değişiklik, D'nin olanakları sayesinde çok kolayca çözüldü.

D'nin standart kütüphanesinden sonra başka kütüphaneleri beğenmiyorum. C++'ta her zaman için başka kütüphaneler aramam gerekiyor. İnternette 'd' ile değil, 'dlang' ile aratmak çok daha iyi sonuç veriyor.

Üç hafta önce bir işe girdim. Benden test kodu yazmamı istediler. Testleri csv (comma separated value) olarak kaydedebildik. İnternette aratınca da önceden haberim olmayan std.csv modülünü keşfettim. Bu modülden haberim bile yoktu. Harika!

Derleyicimi yazarken std.getopt modülünden de çok yararlandım. İlk projedeki GNU getopt kolay değildi. switch deyimleri hataya açıktır.

D'ye yeni başlayan arkadaşıma std.getopt'u gösterdiğimde "bu kadar kolay olamaz; hile sayılmalı" dedi.

Şimdi basit bir program yazalım...

(Andrei araya giriyor: "std.getopt, benim ilk yazdığım büyükçe modüllerden birisiydi. Perl'de de buna benzer bir modül vardır. D'de de yapabilmeliydim.")

getopt yardım ekranını da otomatik olarak halleder.

İnsanlar Python'u hızlı geliştirme için tercih ediyorlar. getopt da aynı hızı veriyor.

Derleyicime kanallarla loglama (logging with channels) olanağı da ekledim.

D'nin derleme zamanı olanakları müthiş.

CV'mde iyi görünsün diye veritabanı projemi C++'ta yazdım. getopt'un yaptığını C++'ta yapmak zordu.

Standart kütüphanede yavaş olanaklar olabilir... Sorun değil çünkü daha sonradan gerektikçe hızlandırabiliriz.

D'nin standart kütüphanesindeki varsayılan ayarlar çok doğru.

(Walter'a gönderme yapıyor: Walter, doğru araç seçiminin önemini gösteren şeyler söylemiş.)

(Chuck araya giriyor: Erich bir derste derleyici yazarken, başka bir derste de benzeri bir proje yazıyordu. İkisini birden bitirebilmesi büyük aşamadır.)

(Erich yanıt veriyor: İkisini C++'ta yazmak zorunda kalsaydım bitiremezdim.)

D'nin araçları da çok yararlı. rdmd çok kullanışlı. rdmd, C++'taki yaz+derle+çalıştır döngüsünü unutturdu.

Son olarak birim testlerine geçeceğim. dmd'nin -unittest ve -main seçenekleri tek modülü test etmeyi çok kolaylaştırıyor.

(Walter araya giriyor: Oraya bir de -cov seçeneği eklemelisin.)

Sözleşmeli programlamanın beklenmedik bir yararı, 'invariant' olanağı ile geldi: Eklediğim invariant bloğunun işletilmesi ile 10 dakika içinde aradığım hatanın kaynağını buldum.

Son görüşlerim: Gelişmeden korkmamalıyız. Yeni olanaklar gelince eski kodları dönüştürme konusunda yardım edebiliriz.

STL C++ için büyük bir adımdı. D'nin standart kütüphanesinin o derece büyük bir adım olduğunu görüyorum.

D kullandığım tek dil. Betik için, hız için, hep onu kullanıyorum.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Haber: DConf 2016, Berlin'de Sociomantic'te yapılacakmış.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

>

Andrei'nin konuşması ilginç başladı: "Türden bağımsız programlamayı (generic programming) artık bırakmamız gerekiyor" gibi bir sözle başladı ("Generic programming must go").

Bu biraz ilginç geldi. Bugün türden bağımsız (generic) programlama bir çok dilde mevcut ve kullanılıyor. Ali, sence burada bahsedilen generic programlamanın tamamen bırakilması mı, yoksa generic programlamanın çıkış amacına (türden bağımsız olması) bakıldığında isteneni tam olarak veremediği mi?

Ayrıca jenerik programlama Phobos içinde oldukça sık kullanılan bir teknik. Acaba bu düşünce doğrultusunda Phobos kütüphanesinde bir takım değişiklikler bekleyebilir miyiz?

Alıntı (acehreli):

>

Descartes'a gönderme yapıyor: Tüm bildiklerinizi bir kenara bırakın. Şimdi, bellek ayıran koddan ne beklediğimizi düşünelim: Tabii ki allocate()...

Önerisi: Tasarımlarımızı içgözlem (introspection) üzerine kuralım.

Bu konu hakkında bilgin varsa biraz daha açabilir misin? İç gözleme dayalı tasarım derken kastedilen tam olarak nedir?

Alıntı (acehreli):

>

Haber: DConf 2016, Berlin'de Sociomantic'te yapılacakmış.

Bu habere sevindim :)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (zafer):

>

Bu biraz ilginç geldi.

E, keynote sunumlarının biraz da uç fikirler ve yepyeni düşünceler getirmesi beklenir. :)

Alıntı:

>

Bugün türden bağımsız (generic) programlama bir çok dilde mevcut ve kullanılıyor.

Şüphesiz ve D bu konuda çok üstün. (Benim hiç bilmediğim başka dillerde daha iyileri de varmış galiba ama bildiğim C++'la karşılaştırıyorum.)

Alıntı:

>

Ali, sence burada bahsedilen generic programlamanın tamamen bırakilması mı, yoksa generic programlamanın çıkış amacına (türden bağımsız olması) bakıldığında isteneni tam olarak veremediği mi?

Konuşma ilerledikçe Andrei'nin aslında bunu biraz da pazarlama sloganı olarak söylediği ortaya çıktı. :) Benim anladığım iki mesaj şu:

• C++'a eklenmesi uzun zamandır beklenen ama iyi bir yolu bulunmadığı için eklenemeyen concepts'in (ev concepts light'ın) çözüm olmayacağını söyledi. Bu konu, D'de şablon kısıtlaması adıyla çözülüyor. Dolayısıyla, aslında D'dekinin de biraz eksik kaldığını söylemiş oldu.

• 'static if' çok yararlı bir olanak.

O iki mesaja bakınca ben kendi adıma üstü kapalı da olsa doğrudan C++'a karşı bir mesaj gördüm. Çünkü C++ hâlâ concepts bulmaya çalışıyor ve Bjarne Stroustrup Andrei'nin kendisine yakıştıramadığını söylediği bir tavırla 'static if'in C++'a eklenmesinin düşünülmemesi gerektiğini söyledi. Uzun bir cümle oldu. :) Yani, Bjarne Stroustrup, "'static if', üzerinde durulmaması gerekecek kadar yanlış bir fikirdir" gibi bir makale yazmıştı (başka yazar(lar)ı da var).

Ben de her D sunumumda 'static if'in yararını anlattıktan sonra "'static if' C++'a eklenmeyecek" diyerek o makalenin bağlantısını veriyorum: http://isocpp.org/files/papers/ adresindeki "document N3613".

Özetle, Andrei şunları söyledi:

• Belirli bir algoritmanın UzunlukBilgisiVeren_ElemanlarıReferansOlan_ForwardRange gerektirdiğini söylemek yerine, 'static if'ten ve derleme zamanında mantıksal ifadelerden yararlanarak duruma göre davranmalıyız.

Tabii bunların hepsini de bitirmeye çalıştığı std. allocator'daki deneyimleri üzerine söyledi.

Alıntı:

>

Ayrıca jenerik programlama Phobos içinde oldukça sık kullanılan bir teknik. Acaba bu düşünce doğrultusunda Phobos kütüphanesinde bir takım değişiklikler bekleyebilir miyiz?

Phobos'ta değişiklik olmayacak çünkü Phobos zaten bahsedilenleri uyguluyor. :) Bundan sonra daha farkında olacağız.

Örneğin, Phobos'ta yukarıdaki gibi çok uzun isimli şablon kısıtlama isimleri yok. Olsa olsa beş aralık ismi var ve bir çok birbirinden bağımsız hasLength() gibi başka kıstaslar var.

Alıntı:

>

İç gözleme dayalı tasarım derken kastedilen tam olarak nedir?

Bir şablonun __traits, std.traits, vs. gibi derleme zamanı olanaklarını kullanarak elindeki türün becerilerini anlaması ve ona göre derlemesi (veya davranması).

Bu arada, bütün (çoğu?) sunum DConf'ın sitesine konuldu. Konuşmacıların sayfalarında 'Slides'a tıklayınca geliyor:

http://dconf.org/2015/talks/alexandrescu.html

Alıntı:

>

Alıntı (acehreli):

>

Haber: DConf 2016, Berlin'de Sociomantic'te yapılacakmış.

Bu habere sevindim :)

Kızım liseyi bitirdi. Oğlumun okula gitmesine de bir kaç sene var. Dolayısıyla, yaz ayları dışında da Türkiye'ye gelebileceğim. Yani, seneye Berlin'de görüşürüz! :D

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Gün 1 - Mayıs 27, Liran Zvebel, "Using D for Implementing a Large Scale Primary Storage System"

Liran, D'den nasıl yararlandıklarını anlatıyor. Weka.io bir İsrail firması; 20 kişilik startup firmalarında çoğu programcı D kullanıyor. İşleri, büyük ölçekli veri saklama (storage system). Kesintisiz hizmet vermek zorundalar ve çok hızlı olmaları gerekiyor.

120K satırlık D kodları var.

Kullandıkları dilin etkin olması şartmış ve büyük boyutlu projeye uygun olması gerekliymiş. Sunucuları birden fazla coğrafi noktada bulunuyor.

Daha önceden şunu yapıyorlarmış: C dili. XML'e dayalı kod üretiyorlar.

Ürünün yönetimi Python ile yapılıyormuş. Python'un küçük projelere uygun olduğunu farketmişler. Proje büyüyünce sorunlar başlamış. Hele, veri saklama gibi bir konuda Python'un teste uygun olmadığını görmüşler.

Şimdi yalnızca D kullanıyorlar. Herşey kullanıcı ortamı programı (user space). Çok az kernel modülleri de var.

Fiber ve 'reactor' tasarımları kullanıyorlar.

Bellek kullanımı konusunda çok hassas olmak zorundalar. Bir kere veri gelmişse, kesinlikle başka bir yere taşınmıyor veya kopyalanmıyor. Herşey çok hızlı ve gecikme (latency) yok. Dolayısıyla, veriyle ilgili kodlarda çöp toplayıcı kullanılmıyor.

Hata ayıklama olayı böyle bir sistemde çok zor oluyor çünkü loglamaya kalksanız çok kısa sürede log dosyaları doluyor. Hatanın oluşmasını bekleseniz geç kalmış oluyorsunuz.

Hata açıklayıcı kullanamıyoruz, dosyaya loglayamıyoruz, vs.

Trace (izleme) konusunda D'den yararlanmışlar. @notrace gibi bir kullanıcı niteliği ile bazı işlevleri hiç izlemiyorlar bile. Loglamayı çok etkin hale getirmişler.

Herşey çok hızlı gerçekleşiyor ve sihir gibi hallediliveriyor. :)

Hata oluşuyor, trace sistemimiz bilgiyi veriyor, programcı hatayı gideriyor.

(Sürekli olarak hızdan (efficiency) bahsediyor.)

Program çalışırken onunla etkileşen başka bir program sayesinde programcı programın çalışmasını izleyebiliyor. Her tür bilgiyi alabiliyorlar.

Programcı grubumuz yıllarca tekrar tekrar RPC sistemleri yazmışızdır. Otomatik olarak kod üretiyoruz, sync/async, vs. hep otomatik halledilmiş oluyor.

D'nin bir özelliğinden çok yararlanıyoruz (static foreach).

Fiberlerden çok yararlanıyoruz.

Veri yapılarımız çöp toplayıcı kullanmıyor.

Typedef çok yararlı bir olanak! Umarım siz de projelerinizde yararlanıyorsunuzdur...

Bu konuşmayı dinleyen büyük firmalar varsa, hepinize D'den yararlanmanızı öneririm. Bana D'yi öneren Kent Beck olmuştu. Size mesajım şudur: D harika.

Başka bir yararı, C++'ı gösterdiğimiz programcılar kısa kodları bile anlayamayabiliyorlar. D'yi gösterdiğimizde ise çok okunaklı ve anlaması kolay oluyor.

Şimdi de sorunlara geçelim...

Çöp toplayıcı. Sürekli olarak çalışması ve gecikmesinin (latency) olmaması gereken programlar çöp toplayıcı kullanamazlar. 1 milisaniyeden fazla duraksayamayız. Standart kütüphane çöp toplayıcıyı kullandığımızı varsaydığından standart kütüphaneyi de kullanamıyoruz.

Eşleme tablosu, dinamik dizi, map, filter, vs. kullanamıyoruz.

İkinci sorunumuz, derleme: Bütün projeyi birden derlemek olanaksız çünkü dmd 30G bellek kullanıyor ve çok uzun sürüyor. dmd işlemcinin tek çekirdeğinde işliyor.

C++ bu konuda daha iyi çünkü ccache gibi çözümler kullanılabiliyor. D için henüz böyle bir şey yok.

400 dosyamız var. Birisine dokunduğumuzda yaklaşık olarak 200 dosyanın baştan derlenmesi gerekiyor. Çok büyük projelerin desteklenmesi isteniyorsa D'nin bu konuyu çözmesi gerek.

Diğer derleyiciler: gdc bizim kodumuzu doğru derlemiyor. (Fiber vs. konuları.)

ldc bizim kodu derlerken kendisi göçüyor.

Bu yüzden dmd kullanmak zorundayız.

(Andrei bu noktada soruyor:) Package'lardan yararlandınız mı? Derleme konusunda yararı olabilir... Liran yanıtlıyor: Package'ları da düşünmüştük ama henüz denemedik.

(Walter soruyor:) .di dosyalarından yararlanıyor musunuz? Liran'ın yanıtı: Hayır.

dmd'nin ürettiği assembly hızlı değil. Yakında gdc konusunu çözmeyi umuyoruz.

Başka bir sorun, tamsayıların kullanış olabilmeleri:

int'ten küçük tamsayılarla çalışırken kod hoş olmuyor. Örneğin, hep tür dönüşümü yapmak zorunda kalıyoruz çünkü ara işlemler hep 'int' türünde oluyor. (Ali'nin notu: Bu, C'den gelen bir davranıştır.)

(Andrei araya giriyor ve tamsayı durumunun neden böyle olduğunu açıklıyor:) 1) C kodunu kopyaladığımızda ya doğru işlemeli ya da hiç derlenmemeli. 2) Her ne kadar mantıksız durumlar olsa da, şimdiki dönüşüm kuralları basit; karmaşıklaştırmak daha kötü olurdu. O yüzden bu konuda değişiklik beklememeliyiz.

(Walter da ekliyor:) Bu durum geçmişte çok tartışıldı. Neyse ki 'value range propagation' olanağımız var ve sonucun örneğin ushort'a sığacağının garantili olduğu durumlarda cast'e gerek kalmıyor. Evet, 'value range propagation'ı geliştirebiliriz.

Özet:

Bir seneden uzun bir süredir D kullanıyoruz.

Çoğu programcımız D'yi çok seviyorlar. Yaptığımız herşey şablon... C++'ta bunu yapmak çok zor olurdu. Ya hataya düşerdiniz ya da kodunuzu bir kaç ay sonra bile anlayamazdınız.

D'yi kullanabilmek için çok altyapı geliştirdik. Meyvalarının yeni yeni almaya başladık.

Kötü taraf: Bizimki kadar büyük bir proje yavaş derleniyor.

Yazdığımız bazı kodları açabiliriz. Güçlü D programcılarıyla çalışmaya açığız. Bizim bulduğumuz çözümler camiaya sunulabilir.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli:1433001282):

>

Özetle, Andrei şunları söyledi:

• Belirli bir algoritmanın UzunlukBilgisiVeren_ElemanlarıReferansOlan_ForwardRange gerektirdiğini söylemek yerine, 'static if'ten ve derleme zamanında mantıksal ifadelerden yararlanarak duruma göre davranmalıyız.

Tabii bunların hepsini de bitirmeye çalıştığı std. allocator'daki deneyimleri üzerine söyledi.

Doğrusunu söylemek gerekirse hiç bir şey anlamadım :) Sanırım C++ dünyasına oldukça uzak olduğum için bu konuşmaların arkasında yatan sebepleri çok anlamıyorum. Örneğin şu static if meselesinin neden bu kadar üzerinde durulduğunu anlamıyorum. Doğrusu ben D'yi sadece D olduğu için seven birisiyim.

Alıntı (acehreli:1433001282):

>

Kızım liseyi bitirdi. Oğlumun okula gitmesine de bir kaç sene var. Dolayısıyla, yaz ayları dışında da Türkiye'ye gelebileceğim. Yani, seneye Berlin'de görüşürüz! :D

Umarım, tüm çabalarım bu yönde.

Alıntı (acehreli:1433001282):

>

İkinci sorunumuz, derleme: Bütün projeyi birden derlemek olanaksız çünkü dmd 30G bellek kullanıyor ve çok uzun sürüyor. dmd
işlemcinin tek çekirdeğinde işliyor.

Bu konu benide üzüyor. Evdeki 2GB belleğe sahip Windows(32bit) bilgisayarımda basit bir vibe.d projesini derleyemiyorum. Çünkü işlem bitmeden bellek bitti hatası alıyorum :(

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Kayıtlarda konuşmaların başladığı noktaları belirlemişler:

http://forum.dlang.org/thread/sujyaurgyfumoiimixmx@forum.dlang.org

Bağlantılarda iki hata varmış; düzeltiyorum:

Day 1:
Brian Schott: https://youtu.be/ep5vDQq15as
Liran Zvibel: https://youtu.be/-OCl-jWyT9E?t=3720
David Nadlinger: https://youtu.be/-OCl-jWyT9E?t=7251
Amaury Sechet: https://youtu.be/-OCl-jWyT9E?t=10189
Walter & Andrei AUA: https://youtu.be/-OCl-jWyT9E?t=14477

Day 2:
Chuck Allison: https://youtu.be/AH35IxWkx8M?t=182
Lightening Talks:
Jonathan Crapuchettes: https://youtu.be/AH35IxWkx8M?t=4088
Adam Ruppe: https://youtu.be/AH35IxWkx8M?t=4477
Lionello Lunesu: https://youtu.be/AH35IxWkx8M?t=4929
Erik Smith: https://youtu.be/AH35IxWkx8M?t=5357
Walter Bright: https://youtu.be/AH35IxWkx8M?t=5896
Mihails Strasuns https://youtu.be/AH35IxWkx8M?t=8031
Andy Smith: https://youtu.be/AH35IxWkx8M?t=15825
Jonathan Davis: https://youtu.be/AH35IxWkx8M?t=19410
Mark Isaacson: https://youtu.be/AH35IxWkx8M?t=23056
Andrei Alexandrescu: https://youtu.be/AH35IxWkx8M?t=23056
Open Mic / Q+A: https://youtu.be/AH35IxWkx8M?t=27449

Day 3:
Andrei Alexandrescu: https://youtu.be/oA1exjdEIWw?t=44
Adam Ruppe: https://youtu.be/oA1exjdEIWw?t=4350
Joseph Wakeling: https://youtu.be/oA1exjdEIWw?t=7617
John Colvin: https://youtu.be/oA1exjdEIWw?t=12105
Atila Neves: https://youtu.be/oA1exjdEIWw?t=16190
Erich Gubler: https://youtu.be/oA1exjdEIWw?t=19178

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (zafer):

>

static if meselesinin

Aslında çok basit bir konu ama dediğin gibi, gerekler ancak işin içine girmeye başladıkça görülüyor. Başka hangi dillerde bunun gibi bir olanak olduğu sorulmuş ve C++ üzerine güzel bir örnek verilmiş. Bir algoritma tamsayılara veya kesirli sayılara göre örneğin daha hızlı veya daha doğru sonuç verecek biçimde farklı gerçekleştirilebiliyor olabilir:

http://stackoverflow.com/questions/1717976/are-there-other-languages-besides-d-with-static-if

Burada da bulunsun diye, bir de aralıklardaki yararını hatırlayalım. Eleman değerlerini çarpan bir aralığımız olsun (not, bu işlemi 'map!(a => a * 2)' diye de gerçekleştirebiliriz):

import std.range;
import std.algorithm;

/* Elemanları belirli bir sayıyla çarpar. (Basit olsun diye, çarpan
* değeri 'int' yapalım.) */
struct Çarpıcı(R)
   if (isInputRange!R)
{
   R aralık;
   int değer;

   @property bool empty() const
   {
       return aralık.empty;
   }

   @property auto front() const
   {
       return aralık.front * değer;
   }

   void popFront()
   {
       aralık.popFront();
   }
}

auto çarp(R)(R aralık, int değer)
{
   return Çarpıcı!R(aralık, değer);
}

void main()
{
   auto dizi = [ 1, 2, 3 ];

   assert(dizi.çarp(10).equal([ 10, 20, 30 ]));
}

Amacımıza ulaştık: Zincirleme aralık işlemlerinin arasına istediğimiz noktaya '.çarp(a)' gibi bir ifade yerleştirebiliyoruz.

Ancak, aşağıdaki gibi indeksleyemeyiz çünkü opIndex'i tanımlamadık çünkü bunu ancak RandomAccessRange aralıkları sağlayabilir:

   auto çarpılan = dizi.çarp(10);
   assert(çarpılan[1] == 20);    // <-- DERLEME HATASI
// Error: no [] operator overload for type Çarpıcı!(int[])

static if'in yararı burada görülüyor: Eğer R bir ForwardRange ise save() de tanımlayabiliriz ve eğer bir RandomAccessRange ise opIndex() de tanımlayabiliriz:

struct Çarpıcı(R)
   if (isInputRange!R)
{
// ...

   static if (isForwardRange!R) {
       auto save()
       {
           return aralık.save;
       }
   }

   static if (isRandomAccessRange!R)
   {
       auto opIndex(size_t i)
       {
           return aralık[i] * değer;
       }
   }

   // Benzer biçimde, hasLength, vs.'ye göre başka işlevler de eklenebilir
}

Çok kolay.

Not: Geçen gün bu işlemleri tanımlamanın çok daha kolay bir yolunu farkettim. alias this burada da kullanılabiliyor ve biz yalnızca değiştirdiğimiz işlevleri tanımlamakla yetiniyoruz:

struct Çarpıcı(R)
   if (isInputRange!R)
{
   R aralık;
   int değer;

   // Doğrudan aralık'a iletilen işlemler bunun tarafından zaten hallediliyor:
   alias aralık this;

   @property auto front() const
   {
       return aralık.front * değer;
   }

   static if (isRandomAccessRange!R)
   {
       auto opIndex(size_t i)
       {
           return aralık[i] * değer;
       }
   }
}

Alıntı:

>

basit bir vibe.d projesini derleyemiyorum. Çünkü işlem bitmeden bellek bitti hatası alıyorum :(

Şimdi baktım: '--build-mode=singleFile' seçeneği ile daha az bellek kullanılıyormuş (ama daha uzun sürüyormuş). Ne yazık ki şuradaki kişiye yaramamış:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/20659/

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Esas başlığın dışına çıkmamak adına bence son mesajdan itibaren yeni bir konu açmalıyız yada bunu taşımalıyız.

Örnek çok güzel ve kullanılan tekniklerde öyle, doğrusu aralıklar ve opIndex gibi konularda çok tecrübem yok, benim için merakla incelenecek güzel bir kod bloğu.

Alıntı:

>

> dizi.çarp(10).equal([ 10, 20, 30 ])
> ```

>

Mesela yukarıdaki kod aslında çarp(dizi, 10); şeklinde olabiliyor sanırım? Konuya çok hakim olmayanlar için ilk yazım biraz kafa karıştırıcı.

-- 
[ Bu gönderi, <http://ddili.org/forum>'dan dönüştürülmüştür. ]