"MQL5 Algo Forge'a Geçiş (Bölüm 2): Birden Fazla Depo ile Çalışma" makalesi için tartışma - sayfa 2
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
İyileştirme sürecinde, yalnızca MetaEditor ve web arayüzünü kullanarak bazı ilkel dallanma stratejilerinin birkaç iterasyonunu gerçekleştirmeyi denemenizi öneririm.
Harici araçlar kullanmadan 3. madde şu anda imkansız. Dolayısıyla, 2. noktanın site üzerinden yapılabiliyor olması bunu kolaylaştırmıyor, çünkü bu bir çıkmaz sokak.
Bu tartışmada yeni bir şey söylemedim - tüm bunları birkaç ay önce zaten bildirmiştim. Şimdi 1. ve 2. noktaları açıklayan bir makale var, ancak her nasılsa 3. nokta makalede yer almıyor (3. nokta mantıklı bir devam olmasına rağmen).
Madde 3 eksik çünkü farklı özelliklerin dallarının her zaman aynı değil, farklı isimlere sahip olduğu yaklaşımı tercih ediyorum (sonraki). Sizin yaklaşımınızla, next'in neden kaldırılması gerektiği benim için açık değil? Anlam olarak main/develop paketindeki develop dalına benziyor ve özellikleri sırayla eklerken her yeni özellik üzerinde çalışmak için kullanılıyor.
Birkaç gün beyin fırtınası yaptıktan sonra, en azından "bozuk" dosyalar listesini doldurmanın bir yolunu bulmayı başardım.
Evet, bir keresinde ortak depoyu tüm derlenmiş dosyalardan temizlemek için bir betik de denedim, ancak kısa sürede gereksiz olduğu ortaya çıktı. Dosya farklılıklarıyla ilgilenmek için web arayüzünü kullanmadığımdan, içeriği orada göstermemeleri benim için önemli değildi. Yani "bozuk" dosyaların listesini bulmak mümkün, ama neden? Tüm dosyaların ME (UTF-16 LE kodlu) tarafından oluşturulduğu zaten biliniyorsa, README.md, .gitignore ve diğer birkaçı hariç tüm depo dosyalarım bunlar.
Renat, bana tüm kaynakları UTF-8'e dönüştürmenin mantıklı olup olmadığını söyleyebilir misin yoksa ME sadece UTF-16 LE'ye odaklanmaya devam edecek mi? Sanırım yeni yapıların dallarında veya başka bir yerde UTF-8'e geçişten bahsediliyordu, ama belki de öyle görünüyordu?
ME'de yeni bir dosya oluşturdum (Yeni Sınıf), bu yüzden hemen UTF-8'de oluşturuldu.
Sizin yaklaşımınızla, bir sonraki dalı neden sileceğinizi anlamıyorum.
Ben her zaman bir dalı, daha yüksek kararlılık seviyesine sahip bir dalla tamamen birleştirildikten hemen sonra silerim. Bu bir alışkanlık ve eminim çok faydalı bir alışkanlıktır.
Tamamen teknik düzeyde, bir dalı yeniden oluşturmak genellikle bir üst commit (bir sonraki commit'in üst commit'i) şeklinde oldukça somut bir fark yaratır. Bazen bu kritik değildir ve yalnızca commit grafiğinin kullanılabilirliğini etkiler, bazen de yeniden oluşturmadan yapamazsınız.
[Düzenle]
Genel olarak, yerel depodan dalları kaldırabilmenin gerekli olduğunu savunmayı garip buluyorum. Git'in dallanma modelinin en önemli özelliği olduğu ve Git'in sık sık dal oluşturma, silme ve birleştirme işlemlerini teşvik ettiği düşünüldüğünde.
Dosya farklılıklarıyla ilgilenmek için web arayüzünü kullanmadığımdan, içeriği orada göstermemeleri benim için önemli değildi.
Ben de web arayüzünü çok nadiren kullanıyorum. MetaEditor'da Git düğmelerini de kullanmıyorum. Windows için Git Bash'e bakıyorum - doğrudan terminalde - bu benim için yeterli ve kullanışlı.
Yani "bozuk" dosyaların listesini öğrenebilirsiniz, ama neden?
Bozuk dosyaların listesini bilmek onları düzeltmek için. Diff'e bakabilmek için onları düzeltmek için.
Diff ne içindir? [otomatik çevirmen için sorunlara neden olan önemsiz bir cümleyi sildim].
Bunların hepsinin ME tarafından oluşturulan dosyalar olduğu zaten biliniyorsa (UTF-16 LE kodlamasında)
Bunu birkaç ay önce test ettim. Sihirbaz UTF-8 (normal, bozuk olmayan dosyalar) oluşturur. MT4 sihirbazı bile normal dosyalar oluşturur. Bu testler sırasında, sihirbazdan bir kez bile "bozuk" bir dosya almayı başaramadım.
Bazen işlem yapmadan önce dosyaları bu komut dosyasıyla kontrol ederim. Ve ortaya çıktığı gibi, hiçbir şey için değil - normal dosyaların aniden kodlamayı değiştirdiği durumlar vardı. Belki de panodan bir şey ekledikten sonra, emin değilim. Kiril alfabesinin orada olması pek olası değil - yorumlarda bile kullanmayı uzun zaman önce bıraktım.
Kiril alfabesi neredeyse hiç yoktu - yorumlarda bile kullanmayı uzun zaman önce bıraktım.
Görünüşe göre yanılmışım. Bunu UTF-8 kodlaması ile .mq5 dosyasına ekledim:
// Kiril alfabesive dosyayı kaydettikten sonra kodlama "UTF-16 LE BOM" olarak değişti.
MetaEditor'un hatası gibi görünüyor. Kiril karakterleri ekledim ve dosyayı Notepad++ kullanarak kaydettim ve kodlama UTF-8 olarak kaldı.
Ayrıca dalların yerel depodan kaldırılabilmesi gerektiğini savunmayı da garip buluyorum. Git'in dallanma modelinin en önemli özelliği olduğu ve Git'in sık sık dal oluşturma, silme ve birleştirme işlemlerini teşvik ettiği göz önüne alındığında.
Bu yüzden ben de ana dallarla birleştikten sonra dalların silinmesinden yanayım. Sadece silme işleminden sonra yeni fiş için yeni bir dal değil de aynı isimle bir dal oluşturulduğunu ilk defa duyuyorum.
Diff izlemenin amacı nedir?
Evet, bu çok gerekli bir şey. Ben de aktif olarak kullanıyorum ama sadece VS Code'da. Ve orada, garip bir şekilde, "kötü" kodlamaya sahip dosyalara bakmama rağmen orada hiçbir çökme olmuyor.
Daha önce hiç böyle bir şeyle karşılaşmamıştım. Bu da oldukça beklenmedik bir durum. Belki de normal dosyaların bozulması, aynı dosyalarla çalışmak için farklı ME yapılarının aynı anda kullanılmasından kaynaklanıyordu? Bilmiyorum...
Taahhüt geçmişine baktım, iki ay önce eklenen dosyalar gerçekten de UTF-8 kodlamasına sahip ve üç ay önce eklenen dosyalar hala UTF-16 LE. Görünüşe göre o sıralarda bir yerde UTF-8 kodlamasına geçiş yapılmış.
Sanırım yanılmışım. Bunu UTF-8 kodlaması ile .mq5 dosyasına ekledim:
ve kaydettikten sonra dosya kodlaması "UTF-16 LE BOM" olarak değişti.
MetaEditor'ün hatası gibi görünüyor. Kiril karakterleri ekledim ve dosyayı Notepad++ kullanarak kaydettim ve kodlama UTF-8 olarak kaldı.
Rusça harfleri ekledikten ve dosyayı kaydettikten sonra kodlamanın UTF-8'den UTF-16 LE'ye değiştiğini onaylıyorum. Tüm Rusça harfler kaldırılır ve kaydedilirse, hala UTF-16 LE olarak kalır.
MetaEditor'ün hatası gibi görünüyor.
İşte UTF-8, Kiril alfabesi ve Git uyumlu hale getirebileceğiniz bir kanıt:
https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea
Tek yapmanız gereken MetaEditor'dan dosya kodlamasını değiştirmemesini istemektir.