Michal Čihař - Blog Archives for Czech

Můj free software 7. - python-gammu

Tento zápisek bude trochu stručnější. Nevím moc co o tomto lepidlu mezi Pythonem a Gammu napsat. Prostě jsem se rozhodl psát GUI v Pythonu, protože se mi tento jazyk líbí a píše se mi v něm dobře, tak vznikla nutnost vytvořit tuto mezivrstvu.

Při psaní šlo v podstatě jenom o implementační detaily, protože základ API byl jasný – něchtěl jsem se moc odlišit od libGammu. Jediné zásadní rozhodnutí (a dodnes nejsem přesvědčen jestli bylo správné nebo špatné) bylo ukládání všech dat do slovníků. Hlavně kvůli jednodušší implementaci, ale nakonec se to ukázalo být poměrně praktické i pro použití v programu.

Možná si kladete otázku proč jsem nepoužil swig nebo jiný generátor rozhraní. Asi to je jen mojí neschopností, ale opravdu jsem nepřišel na to, jak zabalit volání libGammu pomocí swigu tak, aby to bylo méně práce než to napsat ručně.

A na závěr jedna ukázka jak snadno se to dá použít :-).

 import gammu

sm = gammu.StateMachine()
sm.ReadConfig()
sm.Init()

message = {
    'Text': 'python-gammu testing message', 
    'SMSC': {'Location': 1}, 
    'Number': '123456789',
}

sm.SendSMS(message)

Můj free software 6. - Gammu

No už se pomalu dostáváme do současnosti :-). Po dopsání KAlcatelu do relativně použitelného stavu jsem si začal uvědomovat, že aplikace pracující pouze s jedním typem telefonu, která je nerozšiřitelná, nemá moc velkou budoucnost. Tak sem se koncem roku 2002 začal porozhlížet po něčem obecnějším.V té době (a IMHO to tak stále je) připadaly v úvahu asi jeno Gammu (tehdy ještě MyGnokii) a Gnokii. Pak ještě existuje GSMLib, tam ale není zaměřen na nic jiného než AT příkazy a rozšiřitelnost je problematická.

Po vyzkoušení obou projektů a zběžném prozkoumání zdrojáků jsem se rozhodl pro MyGnokii. Kromě toho, že se na rozdíl od Gnokii rovnou komunikovalo s mým telefonem, rozhodlo interní používání unicode. Dnes s odstupem času pořád nejsem schopný říci, který z projektů je vnitřně uspořádán lépe. Gnokii má určitě výhodu ve stabilnějším API, především s ohledem na implementaci různých funkcí a předávání parametrů. Gammu je zase o něco jednodušší na používání díky předávání jen těch parametrů, které budou zpracovány (u Gnokii se vždy předává struktura obsahující pointery na všechno možné) a díky internímu unicode nejsou problémy s nabodeníčky.

Po pár prvních patchích jsem Marcina přesvědčil, že MyGnokii není nejlepší název a navrhl Gammu, které se kupodivu ujalo :-). Pak už šel vývoj poměrně rychle a kromě drobných i větších úprav pro AT kompatibilní telefony přibyla koncem roku první verze podpory pro nativní protokol Alcatelů.

Od té doby už v podstatě jenom udržuji co jsem napsal a občas implementuji nějakou drobnost, která mě na mailing listu zaujme. Většina patchů jsou však opravy různých obskurních chyb, které se projeví při používání z Wammu.

Nvidia a suspend do paměti

Už jsem ani nevěřil, že bude rozhození framebufferu po suspendu do paměti někdy opraveno, ale zdá se, že poslední ovladače to opravují. Takže konečně můžu po obnovení pracovat i na konzoli.

A nějak nechápu proč s touto verzí mají lidi tolik problémů, kromě fungující konzole jsem si žádné změny nevšiml. Teď jenom doufám, že nechválím nvidii zbytečně a oprava není způsobena přechodem na kernel 2.6.16 :-). No co hlavně že to je opraveno.

Slovník k testování

Díky pár příspěvkům u předchozího zápisku už mám verzi Anglicko-Českého slovníku připravenou pro testování na uživatelích. Tak tedy stahujte a nadávejte jak blbě jsem to udělal :-). Jak to vypadá se můžete podívat na screenshotu

Nakonec se mi podařilo z dostupných dat vytvořit celkem strukturované překlady, ale určitě to není dokonalé (hlavně u mnoha slov chybí zařazení). Každopádně za blbé překlady či zařazení nenadávejte mě, ale opravte je :-).

A pár upozornění na závěr:

  • Pro zobrazení formátování potřebujete StarDict 2.4.6, starší verze to zobrazí bez něj. Na příkazovém řádku sdcv formátování zatím nezpracuje vůbec, takže výstup bude s tímto slovníkem trochu nepřehledný.
  • Slovník zatím není automaticky generovaný, takže bude aktualizovaný jenom když ucítím potřebu ho aktualizovat (nejspíš když něco změním v konvertoru).
  • Zdojové kódy skriptu pro převod (napsané v Pythonu) jsou volně dostupné pod GNU/GPL na GitHubu .

Formátování slovníku

Kdysi dávno jsem začal vytvářet debianí balíčky GNU/FDL Anglicko-Českého slovníku pro StarDict . Od té doby se čas od času někdo ozve, že by se mu to hodilo i pro jinou distribuci. Kvůli obskurnosti která je zatím vytváří nebylo triviální to předělat tak, aby to produkovalo i něco jiného než balíčky pro Debian.

Dnes jsem se konečně rozhodl to přepsat :-). Mimo jiné se mi taky nelíbilo jak se data ve StarDictu zobrazují, takže v rámci přepisování došlo i ke změně formátu dat. A v tom jak data zobrazi je právě problém, prostě nevím jak na to, aby to vypadalo rozumně a bylo přehledné. Prozatím jsem vymyslel následující výstup, ale moc se mi to nelíbí:

ahoj

ahoy [Zdeněk Brož]
bye [Pavel Cvrček]
([hovor.]) bye-bye (pozdrav na rozloučenou) [mamm]
(typ slova) překlad (poznámka) [autor]

Všechny položky (samozřejmě až na překlad) jsou nepovinné, takže když je na stránce více různých, je to dost rozházené. V papírových slovnících jsem moc užitečné inspirace nenašel, prostě je to jiné médium a na obrazovce je více místa. Lingea Lexicon má pěkně strukturovaná data, která asi z free slovníku nikdy nedostanu, takže tam se taky nedá inspirovat. Takže poslední možnost je, že někoho tady napadne geniální řešení jak data uspořádat, tak se předveďte :-). Jediné omezení je, že formátování lze provést jen novými řádky a tím co umí Pango markup .

Převodní skript prozatím žije jen v mém Arch repository, prohlédnout si ho můžete v ArchZoomu .

Můj free software 5. - KAlcatel

KAlcatel je první můj open source projekt, který se setkal s poměrně slušným úspěchem. Jedná se o GUI pro dříve popsanou knihovnu alcasync. Kromě klasické editace údajů v telefonu umožňuje i úpravu jen v počítači a následnou synchronizaci dat.

Do programování jsem se vhrl s nadšením a buhužel téměř bez rozmyšlení architektury programu. Během pár měsíců byla na světě verze, která fungovala velmi dobře a používalo jí relativně hodně lidí. S tím se začaly objevovat požadavky na přidání podpory pro další telefony.

Nějakou dobu jsem koketoval s vytvořením pluginu pro Gnokii , ale nakonec jsem zjistil, že to v podstatě znamená přepsat program znovu a uložil jsem tuto myšlenku k ledu.

Poslední změny byly již jen kosmetické v podobě opravy kompilace s novějšími Qt a pak již vývoj umřel úplně. Ovšem myšlenka vytvořit GUI pro správu telefonu fungující i na jiných systémech než Windows mě neopustila a později se zhmotnila v podobě Wammu .

Jabber server a ukládání zpráv?

Tak přemýšlím jestli má cenu si rozběhávat vlastní jabber server. Kvůli používání několika počítačů by se mi líbilo ukládání historie na server, což je asi hlavní motivace pro úplnou kontrolu nad serverem. Bohužel to vypadá, že s podporou JEP-0136 to není moc růžové.

Pro vetšinu serverů se dá použít modul (Datasink), který to zařídí, takže to je vždy řešeno externě (a neomezí mi to výběr serveru). Raději bych něco integrovaného, ale to by se dalo přežít.

Podpora u klientů je ještě horší, snad to podporuje jenom webový JWChat. Tak nevím jestli mi to za tu námahu vůbec stojí, asi počkám, až to někdo doimplementuje do nějakého použitelného klienta…

Ach to SourceForge

Projekty na SourceForge jsou už od pátku bez CVS. Proč mi informace o výpadku připadají jenom jako naprosté mlžení a skrývání skutečného problému? Ale hlavně že to umějí popsat tak dlouhým textem…

( 2006-04-03 05:55:21 - Project CVS Service )   On 2006-03-30 the developer CVS server had a substantial system failure. Due to the implementation of the CVS service, there is a single point of failure with multiple points of recovery (there is more than one data source we could potentially recover from if there is any data loss as a result of the failure). This outage currently affects developer CVS access directly, but we have disabled tarball updates and data syncs from the developer CVS server to the anonymous pserver/ViewCVS hosts as an additional level of precaution. Our main focus since the outage was detected has been to safegaurd all data on the developer CVS server as well as possible. We are currently attempting to backup the data on the host, which is taking longer than we initially anticipated it would, but is a necessary step to fully safegaurd the host's data. Next, we are going to perform some data validation to ensure the data set appears valid. Pending successful completion of those steps, we'll reenable developer CVS access. A few days after, we'll reenable CVS tarballs and syncs to anonymous CVS. In the mean time, we're currently advancing plans for a CVS architecture change based upon the knowledge we gained during Subversion deployment to eliminate the single point of failure that developer CVS currently has, add horizontal scalability and overall service resiliance. However, we still do not have an estimate on when developer CVS services will be restored, but we have been, and currently are actively working to restore access to CVS. We appreciate your patience with us while we work to properly resolve this major outage.

( 2006-03-31 07:00:01 - Project CVS Service )   On 2006-03-30 the developer CVS server had a hardware issue that required us to take the service offline. We are actively working on this problem and hope to have it back up soon. There is not a current estimate for the duration of this outage, but when we get one, it will be posted on the site status page (this page). We currently expect this outage to last 48 hours, at minimum.

Pravdu mají ti, kteří trvdí, že takové hromadění free software na jednom serveru není dobrá věc.

Gammu v Debianu

Tak dnes konečně nastal okamžik, o který jsem již dlouho usiloval – Gammu bylo zařazeno do Debianu !

 Subject: gammu_1.05.00-4_i386.changes ACCEPTED
From: Debian Installer <installer@ftp-master.debian.org>
To: Michal Čihař <michal@cihar.com>
Date: Sun, 02 Apr 2006 06:55:39 -0700

Accepted:
gammu_1.05.00-4.diff.gz
  to pool/main/g/gammu/gammu_1.05.00-4.diff.gz
gammu_1.05.00-4.dsc
  to pool/main/g/gammu/gammu_1.05.00-4.dsc
gammu_1.05.00-4_i386.deb
  to pool/main/g/gammu/gammu_1.05.00-4_i386.deb
gammu_1.05.00.orig.tar.gz
  to pool/main/g/gammu/gammu_1.05.00.orig.tar.gz
libgammu-dev_1.05.00-4_i386.deb
  to pool/main/g/gammu/libgammu-dev_1.05.00-4_i386.deb
libgammu0_1.05.00-4_i386.deb
  to pool/main/g/gammu/libgammu0_1.05.00-4_i386.deb
Announcing to debian-devel-changes@lists.debian.org
Closing bugs: 180632 


Thank you for your contribution to Debian.

Můj free software 4. - alcatool/alcasync

Jestli mě paměť neklame, tak zhruba ve stejné době jako Wessie jsem začal s reverse engeneeringem protokolu pro synchronizaci telefonů Alcatel. Šlo to až překvapivě snadno díky logovacím schopnostem originálního software pro Windows. Bohužel tuto skvělou vlastnost již z novějších ostranili, ani nevím proč. Možná to nějak souviselo s tím jak si odkazy na můj web posílali v interních newsech :-).

Projekt se ze začátku jmenoval alcatool, ale poté co jsem zjistil, že jeden alcatool již dříve existoval, přejmenoval jsem ho na alcasync . Tento program v podstatě nikdy nebyl určen pro uživatele, ale spíš pro vývoj a odladění protokolu. Ze začátku se sestával jen z knihovny, která umožňovala základní komunikaci a jednoduchého obslužného programu. Během vývoje přibyl i interpreter který umožňoval interaktivně zadávat příkazy a skriptování, který jsem použil pro vyhledávání funkcí hrubou silou :-). Bohužel přístup k SMS v telefonu se mi stejně nepodařilo zajistit.

Nakonec se z toho vyvinula i docela použitelná command line utilita, ale hlavně knihovna, kterou pak použila grafická aplikace KAlcatel , o které se dozvíte více příště.