Alıntı (acehreli):

Benim programım = benim geliştirdiğim program = benim şuanda yapmaya çalıştığım program = aslında yapmaya çalıştığım uğraştığım ama pek bir şey beceremediğim yinede yazmaya çalışırken çok şey öğrendiğim program bile denilemiyecek hello world çıktısının gelişmişi

Yani benim programım derken görev dağılımı yaptığınızda bana yapılmasını söyldiğiniz benimde yazmaya çalıştığım kod parçaları, küçük uygulamacıklar demek istedim. Yoksa benim programım derken benim kendime yazdığım program demek istemedim. Yani o yazıda ben şuan kendi yazmaya çalıştığım programcığı yazarken başka program(cık)larla uğraşmayayım. Zaten beceriksizim çıktıya bakarım Esat Beyin üzerinde çalıştığı program parçasının çıktısını benimkinin çıktısı sanarım diye söylemiştim.
Alıntı (acehreli):

Evet çok güzel **ama stringi nasıl dstring yada dstring nasıl string yaparız **anlamadım. Eğer onlarıda anlarsam çok güzel olacak. Şablonlara çevirmeden önce şablon nedir nasıl kullanılır diye bir yazı bekliyorum sizden. Birazdan konusunu açarım.

Alıntı (acehreli):

Burdan pek bir şey anlamadım. Sanki ben size ayak bağı oldum projenin çapını küçülttüm sanıyorum. O zaman ben projeden çıkabilirim. Kendi başıma ilerler takıldığım soruları buradan sorarım. Hemde siz projenizi daha iyi ve daha hızlı yazarsınız. Türkçe'yi doğru kullanan bir kütüphanede edinmiş oluruz.

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

Alıntı (acehreli):

Evet benimde aklımda var ama böyle olursa belki yabancılarda kullanır hemde phobos kütüphanesini öğreniririm diye istedim. Evet açıklıyorum daha stringin bile tüm özelliklerini bilmiyorum :-)

Bu arada toupperT'yi vöyle yaptım ama olmadı :

dstring toupperT(dstring giriş)
{
   dstring I="I"d;
   dstring İ="İ"d;
   dstring i="i"d;
   dstring ı="ı"d;
   giriş=replace(giriş , ı , I);
   giriş=replace(giriş , i , İ);
   dstring sonGiriş = toupper(giriş);
   return sonGiriş;
}

Hata kodu ise :
'tr\string.d(27): Error: function std.string.replace (immutable(char)[] s, immuta
ble(char)[] from, immutable(char)[] to) is not callable using argument types (im
mutable(dchar)[],immutable(dchar)[],immutable(dchar)[])
tr\string.d(27): Error: cannot implicitly convert expression (giri'

Bakalım projeyi bir dbetikevine bir trilerine taşıyorum. Bir hata çıkmaz umarım. Aslında projeyi dbetikevinde geliştirip sonra trilere koysam iyi olur gibi. Çünkü siz bozuk kodun projeye girmesini istemiyorsunuz. Ama yinede svn kullanmak iyi oluyor.

Bu arada aslında sizin Türkçe locale konusunda yazdığınız fonksiyonu uni yerine şimdilik koysak çok iyi olur. Hem dchar ile yapıldığı için iyi olur. Bana da gerekiyor. Sonra Esat Bey yazdığında değiştirir.

Bu arada fonksiyona girilen ve foksiyonun döndürdüğü değer dstring mi dchar mı olacak ?

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

Alıntı (acehreli):

Kusura bakmayın ben henüz kod yazmaya başlamadım. Ekstradan bazı şeyler oldu o yüzden fırsat bulamadım bişeyler yazmaya. Fakat bu gece toUniLower_tr ve toUniUpper_tr ile uğraşıcam.

Alıntı:

Bende D nin strig tipini D.ershanede anlatılanlardan daha fazla bilimiyorum :-) . Ama çalışırken Ali hocamın daha öncede dediği gibi 'immutable char[]' ın aliası olduğunu kafamdan çıkartmıyorum. İşleri daha da kolaylaştırıyor.

Alıntı:

Evet eğer çok acilen bu fonksiyonlara itiyaç varsa buda olur.

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

'toUniUpper_tr()' ve 'toUniLower_tr()' fonksiyonlarını svn ye ekledim.

Alıntı (emre413):

Varolan fonksiyonlar tam anlamıyla işimizi görüyosa kullanılmalı bence tekrardan aynı fonksiyonu yazmak zaman kaybettirir.

Alıntı:

Kendi bilgisayarında iyice test ettikten sonra svn ye koymanda bir sakınca yok aslında. Eğer bir hata veya başka bir sorun varsa svn de ilgili değişikliğe yorum bırakırız sende yorumlara göre tekrardan düzenlemeleri yaparsın.

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

Bu projeyi yaparken phobos'tan modüller ekleyebilir miyiz? Yoksa sadece kendi fonksiyonlarımızı ve modüllerimizi mi kullanacağız? Bir de ben yazdığım kodları buraya eklesem siz baksanız sonra biri projeye eklese olur mu? Hem burda sizlerin yorumlarıyla daha az hata payı olur hem bana kolaylık olur.

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

Amatörce yazdım bir bakın olmuşsa siz eklersiniz, toupper_tr ve tolower_tr:

dstring toupper_tr(dstring giriş)
{
   dchar büyükHarf;
   dchar[] çıkış;
   foreach(dchar küçükHarf; giriş) {
       if(küçükHarf == 'i') {
           büyükHarf = 'İ';
       } else if(küçükHarf == 'ı') {
           büyükHarf = 'I';
       } else {
           büyükHarf = toUniUpper(küçükHarf);
       }
       çıkış ~= büyükHarf;
   }
   return çıkış.idup;
}

dstring tolower_tr(dstring giriş)
{
   dchar küçükHarf;
   dchar[] çıkış;
   foreach(dchar büyükHarf; giriş) {
       if(büyükHarf == 'İ') {
           küçükHarf = 'i';
       } else if(büyükHarf == 'I') {
           küçükHarf = 'ı';
       } else {
           küçükHarf = toUniLower(büyükHarf);
       }
       çıkış ~= küçükHarf;
   }
   return çıkış.idup;
}

unittest
{
   assert(tolower_tr("İIÖÜÇĞ") == "iıöüçğ");
   assert(toupper_tr("iıöüçğ") == "İIÖÜÇĞ");
}

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

Bu konunun baş tarafı şurada:

http://ddili.org/forum/thread/83

Şimdi farkettim tolower ve toupper string modülündelermiş, yani bu konuya uygun değiller yeni konu açıp oraya yazayım mı?

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

İ gibi değişkenlerin hiçbir fayda sağlamadığı düşünmüştük.

Yazılan her fonksiyonun sağlamlığı, o fonksiyonun unittest bölümünde yer alır. Böylece ileride fonksiyonda yapılan değişikliklere güvenebiliriz. unittest bölümü, "birim" düzeyinde olduğu için, fonksiyonun sağlamlığını garanti eder.

stringdeneme gibi bir dosya, unittest'e yazmayacağımız ne tür testler içerecek? Aklıma gelen bir tane: uni.d ve string.d'nin karışık kullanımlarını daha üst düzeyde içerebilir. Benim korkum, unittest'e girmesi gereken testlerin stringdeneme'ye kaçacak olması...

Proje, bir takıma ait. Esat Bey'in kodlarını neden görmeyelim? Yazdığı kodlar veya testler bizim işimize yaramayacak mı? Yararsızsa neden yazsın? Senin bahsettiğin ayrım, zaten programcıların kendi bilgisayarları oluyor. Sen kendi bilgisayarında çalışıyorsun, ben kendi bilgisayarımda. Eğer 'make' yazdığımda proje doğru derleniyorsa, fonksiyonların unittest'lerinde veya stringdeneme'de bir hata yok demektir. Rahatlıkla projeye ekleyebilirim ve diğerleri de yararlanabilirler.

Bir başka deyişle, kimse diğerleri muhattap olduğunda rahatsız olacak kod ekleyemez: kodla, make, doğruluğa güvenince 'svn commit.'

Veya: denemelerin ayrı gitmesi emek israfı olur.

trileriSürüm'ün yapmaya çalıştığı iş zaten svn'de mevcut. Farkındaysan zaten sürümler r1,..r6 diye gidiyor. Biz, ismi verilecek bir duruma geldiğinde projeyi dallandıracağız ("branch" edeceğiz) ve o dala kendimizce bir sürüm numarası vereceğiz. Bütün bu düzenek zaten varken trileriSürüm gibi bir metin dosyasını elle beslemek ayrıca zaman kaybı.

Projeye yapılan her eklemenin bir "log" bilgisinin olması da bu konuda önemli; dallandığımız an, o dallanmadan önceki 'commit'lerin log satırlarına bakıp bu sürümün hangi değişiklikleri getirdiğini görebileceğiz.

unideneme ve stringdeneme diye iki tane ayrı dosya olmasına gerek yok. Zaten uni.d ve string.d'nin aynı programda yan yana kullanılabilmelerini bekliyoruz ve en baştan eklediğim deneme.d'nin için böyle deneme kodlarını içerecek yapı mevcut. deneme.d'den başka bir dosyanın gereğini göremiyorum.

Ali

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

Fonksiyonların Türkçelerini dstring alacak şekilde ve dchar'larla uğraşacak şekilde yazalım.

Ali

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

Projeye ekleri bir svn istemcisi ile yapıyorsun ama değil mi? Başka türlü olacağını sanmıyorum çünkü Google bizim projenin sürüm denetimi için svn kullanıyor.

svn uğraşılacak bir şey değil ki. Bu sürüm konusunda eksik olan tek şey, projeye ek yaparken bir de tek satırlık açıklama eklemek. Şu anda liste şöyle görünüyor:

http://code.google.com/p/trileri/source/list

Sol tarafta sürüm numaraları ve ortada tek satırlık açıklama satırları. Bu ikisi trileriSürüm'ün eşdeğeri işte. Tek sorun, o listedeki bazı adımların açıklamaları eksik. O yüzden de projeye eklerkenki açıklama satırı önemli.

Eğer bir kodu onun programı veya benim programım diye nitelendirebiliyorsak, projeye dahil olmaması gerekir. Eğer projeye dahil oluyorsa herkese yararlıdır. A programcısının yararlı olduğunu düşünerek eklediği bir şeyi B programcısı neden yararsız bulabilir. Bunu gerçekten anlayamıyorum. (?) Çünkü gerçekten yararsız veya yanlışsa, proje sayfasında 'code review' yapılır ve negatif bir yorum bırakılır.

Eğer özel bir program da geliştiriyorsan ve bize yararı olacağını düşünmüyorsan o zaman o senin bilgisayarında kalır; bu projeyle ilgisi yoktur.

trileriSürüm'ü kaldırdığın için teşekkürler. Böylece onun içeriğini proje sitesi otomatik olarak hallediyor olacak. :)

dchar'lı sorularının nedeni, bu projenin amacının tam olarak ortaya konmamış olması. :) Ayrıca benim "Phobos'un varsayılan davranışı değiştirir" tanımım da artık yanlış olmaya başladı. Ben baştan gerçekten de onlarınkini ezen ve Türkçe davranan fonksiyonlar düşünmüştüm. Ama o ezme işini geride bıraktık: fonksiyonların ismi bile farklı. toupperT diyen Türkçe davranış alacak, toupper diyen ASCII.

Benim bir ihtiyacım var: "ali" gibi bir dizgiyi doğru olarak "ALİ" diye büyütecek bir fonksiyon. Gerçek bir ihtiyaç! :) Senin denemelerin doğrultusunda bu işin char ile zor olacağını anladık. (Aslında D'nin bu üç türünün sorunları biliniyor:

http://www.prowiki.org/wiki4d/wiki.cgi?DanielKeep/TextInD

O sayfayı çok iyi öğrenmemiz gerek ama ben daha okumadım.

Bence şimdilik dstring ve dchar güzel. Daha sonra olabildiğince şablonlara çeviririz ve kod tekrarını azaltırız da... :)

Ali

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