Keil utanci - Coocox

Başlatan z, 13 Haziran 2014, 04:19:55

X-Fi

#135
Alıntı yapılan: MuratUrsavas - 19 Haziran 2014, 23:14:26
Not: Kod yönetim sisteminde benim tercihim Mercurial (Hg)'dır.

Hocam bu sözünüze istinaden size bir soru sormak istiyorum tortoisehg de .hgignore file oluşturdum bu dosya içerisine "syntax: glob" altına uzantıları ekliyorum ignore ediyor ancak sorun şu ki ben ignore etmeden bir dosyasının serverda tutulup versiyonlamaya dahil edilmemesini istiyorum bunu yapamadım.

"syntax: glob"  ve "syntax: regexp" ikisini de denedim istediğim olmadı siz nasıl yapıyorsunuz.
http://www.coskunergan.dev/    (Yürümekle varılmaz, lakin varanlar yürüyenlerdir.)

Seckin ALAN

git kullanıyorum aktif olarak
memo333, klasik tutmak çok iyi bir yöntem değil. Bence git kullanmayı öğrenmeyi dene. Özel repolar için bitbucket veya kendiniz gitolite kurabilirsiniz.

Kar taneleri ne güzel anlatıyor, birbirlerine zarar vermeden de yol almanın mümkün olduğunu.. Mevlana

MuratUrsavas

@memo333,

Aslına bakarsanız kod yönetim sistemi tamamen bir başka başlık altında uzun uzadıya konuşulması gereken bir şey. Hatta fırsat olsa bunu bir başka kitap konusu olarak hazırlamak isterdim. Bu çok önemli bir şey ve üniversitelerde mutlaka öğretilmesi gereken bir konu. Gelin görün ki üniversitelerde maalesef sahada işe yarayacak bir şey öğretildiğini görmedim. Bilmiyorum belki kıdemli bir mühendis olmamdandır, umarım bu günlerde daha iyidir diyelim. (Gerçi iş görüşmesi için gelen yeni mühendislerden anladığım kadarı ile durum hala aynı).

Kod yönetim sistemini kısaca özetlememiz gerekirse gelişimin istediğiniz her anının bir fotoğrafı çekilip bir kenara kaldırılıyor ve ekibin diğer kalanı ile paylaşılıyor. Böylece tam bir geçmişiniz oluyor ve geliştirme aşamasında geçmişe dönük bir çok şeyi takip edebiliyorsunuz.

Şu hepimizin başına gelmiştir. Proje çalışıyordur, sonra bir özellik ekleriz, bir diğerini, bir diğerini aradan bayağı zaman geçmiştir ama eklediğimizden hariç tamemen alakasız ve az göz önünde olan bir özelliğin çalışmamaya başladığını görürüz. "Ama ben buna hiç bir şey yapmadım ki? Ne ara bozmuş olabilirim?" sousu size de çok tanıdık geldi değil mi? İşte bu anda misal Mercurial ile geriye dönebilir, hangi aşamada bunu bozduğunuzu tespit edebilir, bir yama oluşturup en son sürüme birleştirebilirsiniz (merge). Yıllar sonra bile bunu böyle yaptığınızı görebilirsiniz.

@X-Fi,

"Syntax: glob" demek yok sayılacak dosyaları "dosya sistemi formatında yazacağım" demektir. "regexp" ise expression yani ifade şeklinde yazacağım demektir. Kompleks yoksayma işlemlerini bu şekilde yapabilirsiniz.

Örneğin reponun root klasöründe bulunan "kod.txt" dosyasını direkt bu ismi "Syntax: glob" satırının altına ekleyerek yapabilirsiniz. Bu commit sırasında snapshot içine o dosya alınmayacaktır. Push ettiğinizde de zaten snapshotta olmadığı için sunucuya da gönderilmeyecektir. Eğer dosyanız bir klasör altında ise Windows yerine *nix tarzını kullanarak "/" ayıracını kullanın. Eğer örneğin çıktı klasörünüzün içeriğinin tamamını yoksaymak istiyorsanız (misal "obj" klasörü) hgignore dosyanız şunun gibi olsun

syntax: glob
kod.txt
obj/**


Seçkin Bey'in de söylediği gibi Git'de çok iyi bir kod yönetim sistemidir. Mercurial ve Git (Bazaar vs) Dağıtık Kod yönetim sistemleridir ve bugünden sonra tercih etmeniz gereken sistemlerdir. SVN, CVS, SourceSafe gibi merkezi kod yönetim sistemleri yine işinizi görecekse de ileri seviyelerde karşılaşabileceğiniz bazı senaryolardan dolayı tercih etmemenizi öneriririm.

Son bir hatırlatma, illaki komut satırı kullanırım demiyorsanız mutlaka "Tortoise*" kullanmanızı tavsiye ederim. Bu şekilde hem dosya içeriklerinin tam olarak ne olması gerektiği ile uğraşmazsınız, arayüz sizin için halleder.

E3A4

Murat hocam bilgileriniz için teşekkürler.Farklı konularda birkaç sorum daha var , EB ve Arm hakkında fakat sitenizde hala sıkıntı sürmekte mailinize ulaşamadım konuyu da bölmek istemedim. Size nasıl ulaşabilirim?

AsHeS

#139
Alıntı yapılan: MuratUrsavas - 20 Haziran 2014, 10:11:04
@AsHeS,

Aynen senin kodu denedim. Kod tamamlama problemsiz bir şekilde çalıştı ve tüm listeler geldi. Sizde gelmiyor olması bahsettiğim durumlardan biri ile alakalı olabilir.

Not: Hemen bir konu yüzünden kullandığınız yazılımdan soğumayın :) Maalesef mükemmel yazılım yoktur. Sizin işinize en çok yarayan, olabildiğince en iyi vardır.
Header de değişken tanımlama yapmadım ama diyelim ki fonksiyona geçilen değişkense sıkıntı çıkarıyor. Hiçbir kod tamamlama çalışmıyor değişkeni de görmüyor kod tamamlamada.
Dediklerinizi deneyeceğim eve geçince.

Misal  abc_fon(struct  tc_coin_pulse_management_msg_s   *x)
{
     x -> msg_types. //"burada gelmiyor."
}

X-Fi

Alıntı yapılan: MuratUrsavas - 20 Haziran 2014, 11:27:06
@X-Fi,

"Syntax: glob" demek yok sayılacak dosyaları "dosya sistemi formatında yazacağım" demektir. "regexp" ise expression yani ifade şeklinde yazacağım demektir. Kompleks yoksayma işlemlerini bu şekilde yapabilirsiniz.

Örneğin reponun root klasöründe bulunan "kod.txt" dosyasını direkt bu ismi "Syntax: glob" satırının altına ekleyerek yapabilirsiniz. Bu commit sırasında snapshot içine o dosya alınmayacaktır. Push ettiğinizde de zaten snapshotta olmadığı için sunucuya da gönderilmeyecektir. Eğer dosyanız bir klasör altında ise Windows yerine *nix tarzını kullanarak "/" ayıracını kullanın. Eğer örneğin çıktı klasörünüzün içeriğinin tamamını yoksaymak istiyorsanız (misal "obj" klasörü) hgignore dosyanız şunun gibi olsun


Hocam ignore edilmiş dosyayı hala server a atamıyorum forget yaptığımda da serverdakini siliyor.

Sanırım ben size sorunu tam anlatamadım.
http://www.coskunergan.dev/    (Yürümekle varılmaz, lakin varanlar yürüyenlerdir.)

MuratUrsavas

@X-Fi,

"Ignore" etmenin amacı zaten dosyanın lokalde kalması ve sürüm kontrolüne geçmemesi, dolayısı ile sunucuya taşınmamasıdır. Yani olması gerektiği gibi çalışıyor. Ancak bir süre sonra o dosyanın takip edilmesini isterseniz de .hgignore dosyasından dosya satırını silmeniz ve kaydetmeniz yeterli. Commit yapıp push yaptığınızda son sürümde uzak sunucuda görülecektir. Ancak unutmayın eski sürümlere dönüldüğünde o dosya görülmez.

Ama sürüm takibi yapmayıp yinede dosyayı sunucuya göndereyim diyorsanız bunu başka kanallardan yapmak zorundasınız. Yine o dosya reponuzu klonlayan kişilere gitmeyecektir, sizin kullandığınız farklı kanalı kullanarak onlar erişebilir.

Ancak o farklı kanal bence çok riskli olur çünkü reponuzu da başkalarına açmış olursunuz ve risk oluşturur.

Sürüm kontrolü kullanmadan eğer büyük bir doküman paylaşacaksanız bir wiki ya da ftp sistemi kurabilirsiniz. FTP ya da dosya sistemi tavsiye etmem çünkü genellikle ekipler o bölgeleri çok hızlı bir şekilde kirletir ve bir süre sonra kullanılamaz hale getirir.

@AsHes,

Senaryoyu anladım, aynen senin dediğin gibi denedim çalışıyor aşağıdaki ekran görüntüsünde bunu görebilirsiniz.



Gördüğüm kadarı ile sizde olmamasının sebebi boşluk. x değişkeninden sonra ok işareti için boşluk bırakıyorsunuz. Bunu yapmayın,  o zaman kod tamamlama çalışmaz.

@erkanakarcay,

Soruları forumda sormanız daha iyi olur, şu an tüm forumu aktif olarak takip etmiyorum ancak burada yeni açtığınız konuların bağlantılarını verirseniz elimden geldiğince onları da cevaplamaya çalışırım. Onun dışında özel mesaj da atabilirsiniz ancak hala onaylı bir üye olmadığım için cevap veremiyorum. (Niye bu kadar uzun sürdü ona da anlam veremedim, biraz sinir bozucu).

X-Fi

Anlaşıldı hocam teşekürler. Yapmak istediğim şey, makefile kullanmadan .uvopt ve .uvproj dosyalarını serverda tutmaktı çünkü bu dosyalar IDE her kullanıldığında kayıtlar tutuyor istenmeyen bir durum oluşturuyordu.

Çözümü düşündüğüm gibiymiş iyi çalışmalar.
http://www.coskunergan.dev/    (Yürümekle varılmaz, lakin varanlar yürüyenlerdir.)

MuratUrsavas

Ben prensip olarak bu dosyaları da (proje dosyaları) sürüm kontrolünde tutuyorum. Çünkü projeye yeni bir arkadaş geldiğinde ya da bir başka bilgisayarda çalışmaya başladığımda tekrar tekrar proje oluşturmak gerekmiyor böylece. Ayrıca proje dosyaları çoğu zaman o anın doğru tanımlamalarını da içeriyorlar dolayısı ile sadece kod dosyalarını tutmak yeterli olmuyor.

Benim tavsiyem sizin de bu dosyaları takip etmenizdir (debug için kullanılan geçici dosyalardan bahsetmiyorum, yalnızca projeyi berlileyen dosyalardan bahsediyorum.)

AsHeS

#144
Alıntı yapılan: MuratUrsavas - 20 Haziran 2014, 09:52:42
Merhaba,

Struct içeriğini kod tamamlama ile göstermeme iki durumda ortaya çıkabiliyor. Birincisi complex preprocessor tanımlamaları (değişken tnaımlamanız bir #ifdef #endif içinde bulunuyorsa) ve ikincisi de parserdaki hatalı durumlar. Parser durumu projeye sağ tıklayıp "Reparse" ederek çözülebiliyor ancak preprocessor için geliştirici halen çalışmaya devam ediyor (Bkz. Ticket #11)

@AsHeS,

Bu durumun bence bir incelenmesi gerekiyor. Konuyu önce ben de bir deneyim, sorun çıkarsa EB forumlarında buna bir bakalım.

Hocam şimdi dediklerinizi denedim bütün struct tanımlamalarım (struct instance etme değil) her zaman header file da bulunur. Dediğiniz yöntemi uyguladım.Fakat fonksiyona geçilen parametre de hala parametre gelmiyordu. Değişken gönderimini eski standarda göre yaptım sıkıntı kalmadı.

static void ss(tc_led_manage_file_ptr)
struct tc_led_management_msg_s *tc_led_manage_file_ptr;
{
		struct tc_led_management_msg_s *tc_led_man_msg_file_ptr;


		while ( (uint8_t*)EMPTY != tc_read_msg_for_task(TC_LED_MANAGEMENT_TASK_ID) )
		{

		tc_led_manage_file_ptr-> //"boyle olunca problem kalmiyor ama yeni tipte maalesef gelmiyor."
		}
}


Edit: Yine bug buldum bu konuda tad vermedi Em::Blocks geliştirilmesi lazım.

MuratUrsavas

EB bence de mükemmellikten uzak. Ancak zaten kimsenin de böyle bir iddiası yok. Benim için şu anda en büyük problem preprocessor yorumlaması. Eğer o problem ortadan kalkarsa gömülü yazılıma kullandığım en iyi IDE olacak.

Eğer daha iyi olmasını istiyorsanız bulduğunuz bugları EB'nin bug sistemine girebilirsiniz. Ne kadar hızlı bir şekilde ele alındığını gördüğünüzde emin olun sizde şaşıracaksınız. Bu şekilde bulduğum ve çözülmüş onlarca bug var.

Yine de beni memnun etmiyor diyorsanız, yapılacak en iyi şey bir başka IDE kullanmak olacaktır. Daha iyisini biliyorsanız öğrenmekten memnuniyet duyarım. Alternatif her zaman iyidir.

AsHeS

#146
Alıntı yapılan: MuratUrsavas - 20 Haziran 2014, 21:49:42
EB bence de mükemmellikten uzak. Ancak zaten kimsenin de böyle bir iddiası yok. Benim için şu anda en büyük problem preprocessor yorumlaması. Eğer o problem ortadan kalkarsa gömülü yazılıma kullandığım en iyi IDE olacak.

Eğer daha iyi olmasını istiyorsanız bulduğunuz bugları EB'nin bug sistemine girebilirsiniz. Ne kadar hızlı bir şekilde ele alındığını gördüğünüzde emin olun sizde şaşıracaksınız. Bu şekilde bulduğum ve çözülmüş onlarca bug var.

Yine de beni memnun etmiyor diyorsanız, yapılacak en iyi şey bir başka IDE kullanmak olacaktır. Daha iyisini biliyorsanız öğrenmekten memnuniyet duyarım. Alternatif her zaman iyidir.

Daha iyisi kötüsü bu karşılaştırma yanlış istekler ve onların karşılanması önemli
Örneğin kendi durumumdan örnek vereyim,
1-)İç içe struct kullanımını pekçe bu sebepten kod tamamlama işimi çok kolaylaştırır zaten kendi işimde bu tip tamamlama özelliği olmayan bir IDE(zorunluluk, şirket kültürü vs..) ile çalışıyorum eve gelip aynı derdi çekmek mantıklı gelmiyor.
2-)Bütün structları header da tanımlar c dosyasında instance ederim. IDE'nin bununla derdi var diye kendi alışkınlıklarımı değiştiremem evde keyfe keder kod yazarken.
3-)#ifndef #define #endif ten oluşan header guard ı her headerda bulundururum bunun zaten istisnası bile olmaz.

Şimdi 3 ünü ele aldığımız zaman bunu başaran bir CoIDE vardı zaten kullanıyordum ama Em::Blocks ile 2.bahar denemesi yaptım ilkinde nedense arayüzü hiç sevmemiştim gayet iyi güzel derken bu struct hatası beni direkt soğuttu. Sizin önerdiğiniz reparse yöntemini 3-4 kerede tıklasam da maalesef eğer fonksiyona geçilen struct aktif oluyorsa(kod tamamlama bâbında) fonksiyon içinde tanımlanan structın ki gelmiyor. Eğer her ikisinin de tamamlaması gelinmesi isteniyorsa fonksiyona geçileni global ya da static ile dosya içerisinde global yapmak gerekiyor.
Açıkçası bug sistemine bunu ne diye gireceğimi pek bilemedim orada ki açıklamalar kısa kısa bu case i kısaca anlatmak kolay değil.
Edit:Bazen düzeledebiliyor. Bunu çözdüler mi 10 numara IDE.

memo333

Alıntı yapılan: MuratUrsavas - 20 Haziran 2014, 11:27:06
@memo333,

Aslına bakarsanız kod yönetim sistemi tamamen bir başka başlık altında uzun uzadıya konuşulması gereken bir şey. Hatta fırsat olsa bunu bir başka kitap konusu olarak hazırlamak isterdim. Bu çok önemli bir şey ve üniversitelerde mutlaka öğretilmesi gereken bir konu. Gelin görün ki üniversitelerde maalesef sahada işe yarayacak bir şey öğretildiğini görmedim. Bilmiyorum belki kıdemli bir mühendis olmamdandır, umarım bu günlerde daha iyidir diyelim. (Gerçi iş görüşmesi için gelen yeni mühendislerden anladığım kadarı ile durum hala aynı).


bu dönem üniversitede kısmi zamanlı görev aldım, durum pek iç açıcı değil, neyse..

bu git / mercurial konusunda bir iki sorum olacak: Ben kodu ne sıkılıkta yüklerim, ücretsiz ve kapalı olarak hangisi alan verir, bu konuyla ilgili ayrı bir kodlama öğrenmem gerekir mi?

Bu arada bugün ST'nin Grafik kütüphanesini derledim EM ile hiç bir sorun yok..
Gömülü Linux Notları --> http://linuxedu.xyz/

MuratUrsavas

@AsHes,

İlginç bir şekilde tüm beklentilerini sıkıntısız bir şekilde kullanıyorum. Header guard zaten EB'de dosya oluşturduğunda dahi standart olarak eklenir. İç içe struct benim de olmazsa olmazlarımdandır ve sorunsuz kullanmaktayım. Zaten senin söylediğin senaryoyu denediğimde problemsiz bir şekilde kod tamamlama çalışmıştı. Ancak sende çalışmayan küçük bir proje oluşturabilirsen bunu bende denemek çalışmıyorsa da bu hatayı düzelttirmek isterim.

@memo333,

Git Mercurial ve diğerleri bunların hiç biri normalde bir proje alanı vermezler çünkü bunlar yalnızca sistemdir. Ancak bu sistemleri kullanan servis sağlayıcılar vardır (bitbucket, github, sourceforge, google code vs gibi) Bazıları tek sistemle çalışırken bazıları birden fazla sistem sunar. Her bir servis sağlayıcının kendi şartları vardır, bunu ayrıyeten araştırmak lazım. Ancak genel olarak yükleme sıklığı gibi şartları olmaz, ya süre ya da kullanıcı sayısı sınırı olur. Genellikle bu sağlayıcılar açık kaynaklı projeleri ücretsiz barındırırlar.

Zaten kod yönetimi kullanmak için illada uzak sunucuya ihtiyacınız yoktur. Lokalde de takip ediyor olmak bir çok avantaj sağlar.

picusta

@Ashes  typedef struct seklinde denesen yine oluyor mu ?