Sorun dizge çevrimlerinde, sysinfo çalışmazken SYSINFO’nun çalışması bunu ispatlar nitelikte.

http://sudrap.org/paste/text/827/

Çıktısı ise şöyle:

QUERY QUOTE BANLIST SYSINFO
QUERY QUOTE BANLiST SYSiNFO

Görüldüğü gibi locale’e çağrıldıktan sonra işin rengi değişiyor ve hataya neden oluyor. Eğer dizge işlemlerini ascii olarak yorumlatırsak sorun çözülür. Kodda strncase, strcase, toupper gibi yerele bağlı işlemler var, bunun yerine glib fonksiyonları olan g_ascii_* kullanabiliriz. Aşağıdaki yama sorunu çözer.

http://sudrap.org/paste/text/812/

Xchat’in gerçekten garip çevrimleri var. Örnekle,  /banlist yazdığımız zaman kod içindeki statik objeye bakarak  /quote mode %s +b olarak çeviriyor ve işin eksik tarafı gettext desteğinin olmaması.

İyi muhabbetler.

GNOME 2.26

GNOME’un yeni kararlı sürümü serisi 2.26.x çıktı. Çıktığı gibi Pardus’a geldi

Değişiklikler için: http://live.gnome.org/RoadMap

İyi günlerde kullanınız.

burak@pardus cp $ grep -i i gr
i
İ
burak@pardus cp $ grep -i  İ gr
burak@pardus cp $

Yukarıda görüldüğü gibi, büyük i harfinde grep hatalı çalışıyor. Elimden düşmeyen bu programın hatalı olması beni rahatsız etti. Zamanımın boşluğundan yararlanarak bu hatayı düzeltmeye karar verip kaynak kodlarını incelemeye başladım. Yapı olarak basit, ama karmaşık bir kodlaması var. Sonradan eklenen yamlardan mı bilmiyorum, kodları çok düzensiz. Bazı blokları simetrik değil. Böyle olması işimi zorlaştırdı tabi. Tahmini birkaç yeri değiştirdim ve başarızı oldum. Saatte geç olunca bıraktım. Bugün tekrar inceleyeyim dedim ve hatayı buldum. Sorun glibc kütüphanesinden kaynaklanıyor. wchar fonksiyonlarına(iswupper,tolower,toupper…vs) birisi Türkçe öğretmemiş. Birçok zaman hatalı dönüyor.  Hatalı satıra hacky bir kod yazıp sorunu çözdüm.

— src/grep.c.orig    2009-01-12 03:27:25.000000000 +0200
+++ src/grep.c    2009-01-12 22:50:36.000000000 +0200
@@ -1760,11 +1771,18 @@
}
else
{
-          if (iswupper((wint_t)wc))
-        {
-          wc = towlower((wint_t)wc);
-          wcrtomb(keys + i, wc, &cur_state);
-        }
+          if(wc == L’İ’)
+            wc = L’i';
+          else if (wc == L’I')
+            wc = L’ı’;
+          else
+          {
+            if (iswupper((wint_t)wc))
+            {
+              wc = towlower((wint_t)wc);
+              wcrtomb(keys + i, wc, &cur_state);
+            }
+          }
}
i += mbclen;
}

Bilgisayar başından kalksam bile, beynim sanki kod yazıyor. Yolda yürürken aklıma fikirler geliyor. Uykudan uyanınca parlak filirlerim oluyor. Kendimi adaşmışlığımın göstergesi mi? Hiçbir fikrim yok.

Bugün derinlerde kalan lastfm hesabıma girdim. Tavsiyelerine uydum ve sonuç mükemmel. Ne sevdiğimi biliyor bu. Ben onu sevdim, o da beni. Aşkımızın devamı için rhythmbox’un lastfm eklentisini açtım, kullancı adımı ve şifremi girdim ve çalıştı. Buraya kadar normal. Bundan sonrası beni kızdıran taraf. Rhythmbox ile bir şarkıyı sevdim diyemiyordum. O düğmeye tıklayınca rhythmbox kapanıyor, şarkının en güzel yeride bitiyordu. Bu durumu birkaç kez yaşayınca, kafamın kayışı koptu.

Bu durumu ne yapıp edip düzeltmeliydim. İşine koyuldum, gnome bugzillayı karıştırdım yama yok. Yama olmayınca kendi yamamı kendim yapmaya karar verdim. Ama nereden başlamalıydım? Binlerce satır kod içinde nerede bu sorunlu satır(lar). Programcılık yeteneğim ile yeri görebiliyordum ama o bile yetmiyor. Kara günlerimde beni hiç yanlız bırakmayan, eski dostum “gnu debuggeri” bir anda anımsayaverdim. İlk önce rhythmbox paketini debugging yapabilmeye uygun hale getirdim. Sonra gnu rhythmbox sürecine gnu debuugeri yapıştırdım. Artık elimdesin rhythmbox. Sorunlu aşamaya geldiğimde, rhythmbox kapannadan gdb hatayı fısıldıyıverdi. Elimle koymuş gibi buldum.

#0  0xb6836373 in strlen () from /lib/libc.so.6
#1  0xb461b68a in handle_xmlrpc_response (source=0x92ad138, body=0×0, entry=0xa09dba0) at rb-lastfm-source.c:2135
#2  0xb4619d18 in http_response_cb (session=0×9226178, req=0xa0bc0b0, user_data=0xa247be8) at rb-lastfm-source.c:1297
#3  0xb7d700b1 in ?? () from /usr/lib/libsoup-2.4.so.1

sorun strlen() fonksiyonunda. “Sanırım hatalı bir dizge var?” diye düşündüm. http_response_cb -> handle_xmlrpc_response çağırıyor buna göre. body değikeni NULL olması burada göze batıyor.  Sorunlu kodlar rb-lastfm-source.c dosyasında. O dosya ile biraz boğuştum. libsoup’tan kaynaklanıyor sanırım, 2.2.,2.4 sürümleri için koşullu derlemeleri var. İlginç yerlerde var, örnekle satır 2069 da

static void handle_xmlrpc_response (RBLastfmSource *source, const char *body, RhythmDBEntry *entry)
{
/* nothing */

}

tanımlanmış. Ne oluyoruz? ( mantıklı birşey, koşullu derlemeler var.)

Beni kızdıran satır, birkaç satır altta kalmış

soup_xmlrpc_parse_method_response (body, strlen (body), &v, &error);

işte bu. Ah buldum seni. Burada boş olan dizinin boyutunu almaya çalışıyor. Bende dizi boş olursa 0 a dön diye bir koşul ekledim. Sorun kalmadı.

soup_xmlrpc_parse_method_response (body, (body == NULL) ? 0 : strlen (body), &v, &error);

Bu kadar basit işte. Daha zorlarını bulmıştum. Açıkçası bu işin bu kadar kolay olacağını sanmıyordum. Şimdi last.fm zevkini çıkartıyorum. Kendi yamam ile daha bir zevkli oluyor.

Hmm, bu arada blogum bakımsız kalmış, temasıda eksimiş. Birşeyler yapmak gerek. Hadi yatayım saat 3:15 olmuş.

Başka bir sıkıştırma yöntemi ise gzip. gzip GNU Zip in kısaltılmış halidir. Birçok paket, kodlar bu biçimde dağıtılır. Bir bütün olması için tar arşivlemesi ardından gzip sıkıştırması yapılır. Onun içindir ki “.tar.gz” ile biter. Deneğimizin gzip sıkıştırması ile

Açık haldeki dosya 227.4MB (açık hal)
tar arşivlemesi ile 238.7MB (linux.tar)
gzip sıkıştırması ile 53.5MB (linux.tar.gz)
Başka bir sıkıştırma türü ise bzip2. gzip’e göre daha verimlidir. Deneğimizde

Açık haldeki dosya 227.4MB (açık hal)
tar arşivlemesi ile 238.7MB (linux.tar)
gzip sıkıştırması ile 53.5MB (linux.tar.gz)
bzip2 sıkıştırması ile 42.1MB (linux.tar.bz2)
Daha iyisi yok mu. Elbette var. Bu sıkıştırma yönetimini PiSi paketleri kullanıyor. LZMA sıkıştırması. Nadiren kullanılır. Görmemiş olabilirsiniz. Tahmin edeceğiniz gibi tar arşivleme biçimi, ardından LZMA sıkıştırması. “tar.lzma” şeklinde olacaktır.

Açık haldeki dosya 227.4MB (açık hal)
tar arşivlemesi ile 238.7MB (linux.tar)
gzip sıkıştırması ile 53.5MB (linux.tar.gz)
bzip2 sıkıştırması ile 42.1MB (linux.tar.bz2)
lzma sıkıştırması ile 35.3MB (linux.tar.lzma)

Bu paketler nasıl sıkıştırılır,açılır? Bilindir tar komutu var.Birçok sıkıştırma yöntemi ile bağlantı kurabiliyor(bz2,gz,lzma…). Dokümanlara bakarsanız çok uzun olduğunu görürsünüz. Uzun göründüğüne bakmayın, çok kolaydır.
(-z) –> gzip işlemleri
(-j) –> bzip2 işlemleri
(-Y) –> lzma işlemleri için.
(-v) –> verbose –> detaylı çıktı
(-f) –> file –> dosya
(-x) –> extract –> açma !!!
(-c) –> compress –> sıkıştırma.

açma-sıkıştırma için genel argümanlar: -v -f için kesin
açmak için ek olarak: -x
sıkıştırmak için ek olarak: -c
biçimler: -z , -j gibi (sadece tar ise bir şey yok.)

bundan yola çıkarak
linux.tar dosyasını açmak için: tar -xvf linux.tar
linux.tar.gz dosyasını açmak için: tar -zxvf linux.tar.gz
linux.tar.bz2 dosyasını açmak için: tar -jxvf linux.tar.gz2
linux.tar.lzma dosyasını açmak için: tar -Yxvf linux.tar.lzma

linux.tar olarak arşivlemek için: tar -cvf linux.tar <yol>
linux.tar.gz olarak sıkıştırmak için: tar -zcvf linux.tar.gz <yol>
linux.tar.bz2 olarak sıkıştırmak için: tar -jcvf linux.tar.gz2 <yol>
linux.tar.lzma olarak sıkıştırmak için: tar -Ycvf linux.tar.lzma <yol>

<yol> mu arşiv adı mı daha önce geleceğini karşıştırabilirsiniz. “f” argümanı file olduğunu hatırlayın. Bundan sonra dosya tanımlanıyor.
Sıkıştırma işlemlerinde iki tane programın çalıştığını görebilirsiniz.

LZMA algoritması ile iyi sıkıştırılmış paketlerimiz olsa da kotalı adsl için tatmin edici bir sonuç değil. Bu sorun “delta” paketleriyle çözülmüş(!) ama ortada paket yok! Uzun zamandan beri kafamı kurcalıyor bu paketler. Baktım ortada paket yok. Bende kolları sıvadım ev yapımı “delta pisi” paketleri için.

PiSi Delta paketlerini oluşturmak için pisi komutu var.

pisi delta oldpackage newpackage

olarak tanımlanmış. Kullanımı gayet basit.

İlk şanslı paket kernel.

eski paket: kernel-2.6.18.8-86-71.pisi –> 13.6 mb (pardus 2007.2 sürümünde)

yeni paket: kernel-2.6.18.8-86-88.pisi –> 13.6 mb (pardus 2007.3 sürümünde)

PiSi delta paketi

pardus kernel # pisi dt kernel-2.6.18.8-86-71.pisi kernel-2.6.18.8-86-88.pisi
Paketler çalışma dizinine yazılıyor.
Creating delta PiSi package between kernel-2.6.18.8-86-71.pisi kernel-2.6.18.8-8
Bitti

delta paket: kernel-71-88.delta.pisi –> 6.5 mb

Burada %52.2 varan değişim yapılabiliyor.

Diğer bir paket ise openoffice. Pardus un gelmiş geçmiş en büyük paketlerinden birisi 70mb boyutunda

eski paket: openoffice-2.2.1-45-41.pisi –> 65.0 mb (2007.2)

yeni paket: openoffice-2.3.0.5-49-47.pisi –>70.7 mb (2007.3)

delta paket: openoffice-41-47.delta.pisi –> 59.6 mb

yanlış okumadınız 182kb. Delta paketleri ile inanılmaz boyutlarda sıkıştırma yapabiliyoruz. Buradaki bir önceki pakete göre değişim %15.7

Birbirine çok benzeyen kernel paketinde oransal olarak %52.2 fark var. Farklı çekirdek derlenmiş modülleri çalıştırmak neredeyse imkansız olan bir sistemde, %52.2 hiç yabana atılmayacak kadar büyük bir başarıdır. Öte yandan birbirine hiç benzemeyen iki openoffice paketi arasında %15.7 lik bir oran var.