Alıntı (acehreli):

>

Herşey programlama ile ilgili. DNA çözümlemeyle ilgili olanaklar da standart kütüphane de bulunmalı mı? Veya kamyon şoförlerinin uyku zamanlarını düzenleyen bir kütüphane? :) İstediğimiz kadar uçabiliriz. :)

Eklenmesi taraftarı değilim ama eklenirse ne olacağını görmek isterim :-D Ben "programlama ilgili" sözcük grubu şu anlamda tanımladım. 1. Zip kütüphanesi sana ne çağrıştırıyor. Programlarken bir veriyi sıkıştırmak için kullanılan kütüphane. Doğru konabilir.
2. Dna kütüphanesi sana ne çağrıştırıyor. Aman hemen klonumuz yapılabilir. kaç kaç :-D Konulamaz. Ben kendime yeterim gibi...

Tabii insanların akıllarında çağrıştırdığı şeyler farklıdır ama bana zip programlamayla ilgisi yüksek gelirken DNA bana bioloji ile ilgisi yüksek geliyor. Yani ben zip'i programlamaya koyarken dna'yı bioloji kitabına koyarım ya siz ?

zip'in hatası http://www.digitalmars.com/d/2.0/phobos/std_zip.html burada yazıyor. Şifrelemeye desteklemiyor diyor ve bir sürü hata.

Ben standart kütüphaneyi ne için isterim ?

1. Herkes tarafından desteklenir(Bu yüzden ne belge sorunu nede hata yer alır.).
2. Kurulum gerektirmez. Hemen deneyebiliriz.
3. Uyum sorunu kesin kez olmayacak.

Diyelim D dili görsel kütüphane standartı olarak Tkinter ile gelsin(python öyle yapıyor.)

bakacağız tkinter iyi hoş kullanımı basit. Ama ne yazik ki eksik ve hatalı. Bizde standart olmasına karşın Gtk kullancağız. Ve belki daha profesyonel bir şey isteyeceğiz ve QT kullanacağız. Bu kadar basit. Gnu'yu sevenler ne için seviyor ? Seçme özgürlüğü için. Ubuntu kur gnome ile gelsin sonra kde kur. Pardus kur Kde ile gelsin sonra x-face kur. Hatta dağıtımın hiç bir şekilde destek vermediği gnome'u kur.

Ee standart ne sağladı ? Standart programı kurduğumuzda bizi çıplak bırakmadı. Kde'yi verdi al paşa paşa kullan dedi. Eğer standart olmasaydı konsol ile bir şeyler yükleyecektik ve o zamana kadar sistemin bir arayüzü olmayacaktı. Standart olmasaydı hiç bir sistem arayüzü benimsenmediği için yeterli destek verilemeyecekti.

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

Alıntı (canalpay):

>

Ben ise tam zıttını düşünmüşümdür. Hepsi programlama ile ilgili şeyler.

Herşey programlama ile ilgili. DNA çözümlemeyle ilgili olanaklar da standart kütüphane de bulunmalı mı? Veya kamyon şoförlerinin uyku zamanlarını düzenleyen bir kütüphane? :) İstediğimiz kadar uçabiliriz. :)

Alıntı:

>

Eğer şuan zip ile ilgili modül doğru düzgün çalışsaydı dkv için gereken şifreleme işini yapabilecektim.

Neden çalışmadığını merak ettim şimdi. :) Ayrıca zip sıkıştırma için...

Alıntı:

>

Şuan benim düşüncem daha etkin :-D Bir programlama dili seçerken kütüphanesinin genişliğine ve standart kütüphanesinin genişliğine bakılıyor.

Kabul ama bir yerde sınır koyulması gerek. Örneğin çeşitli XML tarayıcı kütüphaneleri var. Hangi tasarım kabul edilsin? Neden daha iyisi olacakken birisi "standart" hale getirilsin?

Alıntı:

>

D2'nin gelişimi bitecek o zaman kütüphane gelecek diyorum

Bundan şüphen olmasın. Herkes D2'nin durmasını bekliyordu. :) Ve durdu... Bundan sonra ufak tefek pürüzler giderilecek ve hatalar temizlenecek.

Alıntı:

>

Ama ne yazıkki aklıma D3 ve yeni bir macera geliyor :-)

Benim tahminim, D3'ün olgunlaşmasına daha 3-4 sene var. İstediğimiz noktada ilgilenmeye başlayabiliriz.

Alıntı:

>

Ama ikimizin programlama yapımız farklı. Ben programcının işi kolay olmalı diyorum.

Katılıyorum.

Alıntı:

>

Siz daha çok ben gerçek bir programcıyım demek istiyorsunuz(Bence.).

Ben C++ kültürünün etkisi altındayım. C++'da dil ve standart kütüphane olanakları çok dikkatle ve çok düşünülerek seçilir.

Dil; türler, deyimler, ifadeler, vs. ile kütüphane yazabilecek bir temel oluşturmalı. Bjarne Stroustrup kütüphane ile çözülebilecek hiçbir şeyi kesinlikle dile almaz. Onun bakış açısıyla; örneğin dizgiler ve eşleme tabloları dilin değil, kütüphanenin olmalıdır. (Kendisinin D için böyle söylediğini hiç bilmiyorum.)

Standart kütüphane ise o dili kullanarak algoritmalar ve veri yapılarıyla bir temel oluşturmalıdır.

Uygulamaya yönelik herhangi başka kütüphaneler de dilin ve standart kütüphanenin üstünde kurulmalıdır.

C++'ın felsefesi o.

Ama bazı insanlar da bunun fazla kısıtlayıcı olduğunu düşünüyorlar. Örneğin iş parçacıkları için standart kütüphanenin destek vermesini isterler. Veya görsel programlama için...

Her insanın ihtiyacı ve görüşü farklı olduğu için, güzel bir sınır bulmak gerek.

Yine zip örneğine dönersek, neden onun kullandığı algoritma olsun da, başka bir algoritma olmasın? (Öte yandan, std.random modülünde rastgele sayı dizileri için birden fazla algoritma var. :) )

Bu arada seninle karşıt görüşte değiliz. Ben de kullanışlılıktan yanayım ama standart kütüphanenin sınırının nerede olması gerektiğinin o kadar bilinemeyeceğini söylemek istiyorum.

Alıntı:

>

Galiba başka ülkelerde bu iki farklılığa ayrı adlar veriliyormuş. Biri coder diğeri programmer sanırım.

O terimler çok karışık ve pazarlama taktiklerinin etkisi altında. :) Örneğin hiç kimse CV'sine "programmer" yazamaz, çünkü düşük bir tanım oluyor. Onun yerine, Amerika'da programcılık mesleğinin ismi "software engineering."

Ali

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

Alıntı (canalpay):

>

zip'in hatası http://www.digitalmars.com/d/2.0/phobos/std_zip.html burada yazıyor. Şifrelemeye desteklemiyor diyor ve bir sürü hata.

Her programda hata var. Senin kullanımını engellemediği sürece kullanabilirsin. dmd forumlarındaki konuşmalara baksak hiç kullanmamamız gerek. :)

Şifrelemeyi anladım. zip programının '-e' seçeneğinden bahsediyorlar. Sıkıştırılan bilgiyi açmak için şifre kullanılıyormuş. (Ben de başlı başına bir şifreleme kütüphanesi gibi düşünmüştüm.)

Bence yine de şimdilik zip'i kullan. Şifrelemeyi sonra eklersin. Örneğin verilerin şifreleri, dosyadan okunduktan sonra program içinde çözülebilir.

Böylece kötü niyetli birisi dosyalar açıldıktan sonra programı çökerterek dosyaları da okuyamaz. (Sanırım zip'le açıldığında öyle bir tehlike var.)

Ali

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

Ben dosyaları ziplerken şifre koydurtacaktım. Sanırım bu şekilde şifresiz erişemezlerdi.Ama zipi şimdi sadece yedekletmek amaçlı kullandırtacağım.

Şifre olayını da kafamda şu şekilde tasarladım. Girişte kullanıcı adı ve şifre soracağım. O şifrelerle metindeki yazıları karıştırarak şifreli metin oluşturacağım. Yani metni şifreleyeceğim. Bunu da kullanıcının verdiği şifreyi belirli bir kural ile şifreleyeceğim. Yani geri dönüşümü olacak. Ama geri dönüşüm için şifreyi bilmek gerekecek. Eğer başka şifre yazar ise şifre doğru olmadığı için şifrelenmiş metinin saf hali açılmayacak.

Örn: şifreleme işlevim şifredeki harflerin int değerlerinin bir üstü ile yazıyor.(örnek a =1 a+1 =2 b olarak yazılacak)(Gerçekte tabiki daha gelişkin olacak.) .
Buda şu şekilde olacak:
Yazılan----------Şifre--------------metne yazılan-------şifreyi ca yazarsa okuduğu değer--------şifre na girerse okunacağı değer
can ca dbn can dbm

Gibi. Bu yüzden şifreyi bilmeden asla doğru metni elde edemeyecek.

Veri yazmak içinde şöyle bir formül var. İlk satırda yukarıdaki sisteme göre 000 yazdıracağım. Eğer şifreyi girdiğinde ilk satırdaki şifrelenmiş metni 000 okumazsa yazı yazmayacak. Yani Her türlü erişime kapalı olacak. Merak ediyorum da bu şekilde şifre kırılabilir mi ? Yani kırılabilse de çocuk oyuncağımı ? Yani şifreleme kodlarını gören her adam şifreyi kırabilir mi ? (Yoksa pro. biri kırarsa zaten bu çok çok önemli bilgi saklamak için değil.)

Olabilecek tek sorun metni açtıklarında metnin içeriğini değiştirebilir. Ama mevzu oraya kadar geldiğinde zaten adam bilgisayarına istediği zararı verebilir.

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

Büyük bir olasılıkla bu projeyi tamamladığımda şifreleme projesine başlayıp bu projeye ekleyeceğim.

Şifreleme işi nereden çıktı diyorsanız her zaman vardı. Bir veritabanında şifreleme şarttır. Yoksa dosyalarınıza erişilir. Eee düşünsenize siz özelinizi saklıyorsunuz biri geliyor sizin özelinizi okuyor. Hadi bu çok önemli değil ama biriniz siz T.C numaranızı saklıyorsunuz ve onu çaldırıyorsunuz. Yada en basitinden şifrelerinizi yazıyorsunuz ve onlar çalınıyor. Şİfreleme bence şart. Bu projenin taslağı bittiğinde ben büyük ihtimalle ona başlarım ve tekrar buna eklerim.

Ben projeyi tanımlarken dosya kaynaklı veri tabanı demiştim. Ve her veritabanının şifrelemesi vardır. Yani bu aklımda hep vardı. Ama nasıl yapabileceğim aklıma gelmedi. Bence proje sapmıyor. Ama bir bakımdan da siz haklısınız. O zaman bu projeyi bitirdiğimde şifreleyici diye bir proje daha açayım. (dokul için gerekecek.) Onda şifreleme işini devam edeyim. Sonra da bu projeyi günceller şifreleyiciyi dahil ederiz. Sınıfta şifreli_mi diye bool değişkeni koyarız. True olursa şifre açık olur. False olursa kapalı olur.(Ön tanımlı false) Sizce nasıl ?
Alıntı:

>

Her türlü şifre kırılabilir. Sanırım en büyük sorun, zaman. Yeterli zamanı olan her şeyi çözebilir. Önemli olan, anlamsız derecede uzun sürede kırılan bir şifre kullanmak. Ama ben şifreleme konularında pek bilgili değilim.

Amacım kırılması çok zor bir şifre yapıcı md5'a yada sha1'a rakip bir şey yapmak değil.

1.Sizin gibi bir kullanıcı şifreyi kırabilir mi ?
2. Benim gibi bir kullanıcı şifreyi kırabilir mi ?

Yoksa adam şifre a verir b verir hareketlerini inceler. Kesin kez çözümü bulur. Şifrenin geri dönüşümü olduğu için giriş değeri sonsuz olduğu kadar çıkış değeride sonsuz olmalı.(Yani fonksiyonun giriş değeri farklı olduğu zaman çıkış değeri de farklı. Bizde bu fonksiyona belirli sayılar vererek yaptığı işlemleri inceleyebiliriz.) Bu yüzden -bence- geri dönüşümlü şifreleyicilerin hepsi çok kolay kırılabilir. Hatta kırılmıştır.(PHP kodlarını şifrelemek için kullanılan zend'in şifreleyicisi. Arkasında koskocaman şirket var. Yinede kırılıyor. girişde çıkışta sonsuz çünkü.) (Bunların hepsi benim düşüncem. Doğru olmayabilir.)

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

Alıntı (canalpay):

>

Veri yazmak içinde şöyle bir formül var. İlk satırda yukarıdaki sisteme göre 000 yazdıracağım. Eğer şifreyi girdiğinde ilk satırdaki şifrelenmiş metni 000 okumazsa yazı yazmayacak.

İyi fikir.

Alıntı:

>

Yani Her türlü erişime kapalı olacak. Merak ediyorum da bu şekilde şifre kırılabilir mi ? Yani kırılabilse de çocuk oyuncağımı ? Yani şifreleme kodlarını gören her adam şifreyi kırabilir mi ?

Her türlü şifre kırılabilir. Sanırım en büyük sorun, zaman. Yeterli zamanı olan her şeyi çözebilir. Önemli olan, anlamsız derecede uzun sürede kırılan bir şifre kullanmak. Ama ben şifreleme konularında pek bilgili değilim.

Ama bu kütüphane için şifrenin gerektiğinden emin değilim. Gizliliği kütüphaneyi kullanan kişiye de bırakabilirsin. Örneğin senin katmanın yalnızca veriyi yazabilir. İsteyen program veriyi şifreler...

Endişem, kütüphaneni amacının sapıyor olması. Eğer olabiliyorsa, her kütüphane (ve her sınıf, her işlev, vs.) çok küçük bir işi halletmeli. İstisnaları vardır ama en az karmaşıklığı da düşününce; amacı iyi belirlemek gerekir.

Kısacası: nereden çıktı şifreleme? :) Diyelim, programımın ayarlarını hızlıca kaydedebileceğim bir kütüphane istiyorum...

Ali

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

Alıntı (canalpay):

>

Eee düşünsenize siz özelinizi saklıyorsunuz biri geliyor sizin özelinizi okuyor.

O durumda tabii ki istemem ama programın ayar dosyası gibi bir dosyada da gizlilik yoktur.

Alıntı:

>

Sınıfta şifreli_mi diye bool değişkeni koyarız. True olursa şifre açık olur. False olursa kapalı olur.(Ön tanımlı false) Sizce nasıl ?

Olur.

Veya önce şifresiz bir 'VeriTabanı' sınıfı yazılır; ondan sonra onu içeren ve bilgi giriş ve çıkışlarını şifreleyen ve şifre açan bir 'ŞifreliVeriTabanı' sınıfı yazılabilir. Bu ikincisi, son derece basit bir sınıf olarak bütün işi 'VeriTabanı''na devreder ama gizliliği sağlar. Bu durumda, dosyadaki her şey gizli olur.

Başka bir yol, bilgiyi taşıyan 'Veri' diye bir sınıf yapılabilir. Veri tabanı sınıfı, bilgiye erişme işlerini verilere yaptırır. Bir de örneğin 'GizliVeri' diye bir sınıf olursa, o veri gizli olur. Bu durumda ise, dosyadaki yalnızca gizli olan veriler gizli olur.

Başka yollar da düşünülebilir.

Benim gördüğüm, veri tabanı kavramının kendisi gizlilikle ilgili değil... O sınıf, veriyi dosyalama işleriyle ilgilenmeli. Gizlilik gibi bir konu ise o konudan sorumlu bir sınıf tarafından halledilmeli.

Ali

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

Şimdi inout yerine şablon kullanmak istiyorum. Ama sınıflar için nasıl kullanacağımı anlamadım.

class dkv(T){
   string vTAdı;
   string tAdı;
   string veri;
   string veriAdı;
   string veriYolu;
   string silmeYolu;
   string denetçi;
   int v_yarat(T vTAdı_)
   {
       string vTAdı_s=to!string(vTAdı_);
       vTAdı=vTAdı_s;

       if (exists(vTAdı_s)) {
       throw new Exception("Hata: Veritabanı zaten var");
       }
       string yaratKomutu = "mkdir "~vTAdı_s;
       system(yaratKomutu);
       return 0;

   }
}

Şimdi acaba bunu nasıl şablonlu hale getireceğim ?

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

Alıntı (acehreli):

>

Söylemeyi unuttum: Eğer sınıfın üyelerinin türünü dışarıdan almak gibi bir serbesti düşünmüyorsak, sınıf şablonundan yararlanamayız.

Nokta!(double) noktalıvirgül=new Nokta!double(1.5,5.1)

Yazmak benim için sorun değil. Zaten ileride sınıfları bilmeyenler için dkv'nin yanında dkviş(sınıfları tanımlamak için işlevleri kullanırız ve sınıfsız olarak adam projesine dahil edebilir.) dosyası verebiliriz. Zaten sınıfları bilen benden daha iyi bileceği için bir !(double) eklemek zor değil.**

'inout' için :**

dmd 2.038i yükledim(39'u çıkmış ama benim için önemli değil. sadece yapılar ile ilgili hata giderilimi var.). Evet inout olabilir ama inout'ta dönüş değeri de dchar[] olmalı. Ama ben int istiyorum. O da olmuyor.

Sizce inout yapıp dchar[] değer mi döndürmeliyim. Yoksa sınıflar ile yapmaya mı çalışmalıyım. Benim istediğim iki iş var :

1. Sınıflara üye değişkenleri string tanımladım. Başka bir değerde tanımlamam tanımlatmam.
2. Dönüş değeri int olursa harikulade olur.

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

Amaçlarımız :
1.'dchar[]' 'const' 'immutable' ve 'değişken' ile aynı işlevlerde kullanabilmek.(Nokta sınıfını hem int hem de double kullanır gibi.)
2. Sınıftaki string olarak tanımlanmış sabitleri (veri, veriAdı gibi sınıfın en başındaki tanımlılar.) string olarak kullanmak.(Yani sınıfın immutable char[] olarak tanımlanmış şeylerin türleri değişmeyecek. )

3. Ve mümkünse sınıftaki tanımlı işlevlerin dönüş değeri int olsun.

Ama sanırım sadece dchar[] için tanımlı olması yeterli. Şimdi inoutları kaldırdım.

İleride düşünürüz.

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