libthai wordbreak revamp

หลังจากทำ double-array trie ตัวใหม่ ไปแล้วอาทิตย์ก่อน ก็กลับเข้าถ้ำอีกรอบ เพื่อลงมือยกเครื่องโค้ดตัดคำใน libthai ใหม่ จุดประสงค์ก็คือ ต้องการโค้ดที่สะอาดๆ และแยกพจนานุกรมออกจากโค้ด เพื่อให้ปรับแต่งได้อย่างอิสระ

แต่ต้องบอกว่า ปัญหาเรื่องตัดคำนี้ ผมเองไม่เคยสนใจมาก่อน และตอนที่ตั้งโครงการ libthai ก็คิดไว้ว่าจะชวนคนที่เคยคุยกันเรื่องแนวคิดของไลบรารีภาษาไทยอย่างพี่สัมพันธ์ หรือ อ. พฤษภ์ มาร่วม ก็พอดีว่าอ๊อทซึ่งร่วมตั้งโครงการด้วย ได้เสนอเอาโค้ดของ cttex ของพี่ฮุ้ยมาใช้ พร้อมทั้งอาสาลงมือทำเอง จนสามารถใช้การได้ และกลายเป็นส่วนที่มีประโยชน์ที่สุดของ libthai ในช่วงที่ผ่านมา ไม่ว่าจะเป็นการสนับสนุนการตัดคำใน Qt, Pango, Firefox และทำให้ libthai เป็นที่รู้จักมากขึ้น จนล่าสุดสามารถผลักดันเข้า Ubuntu และ Debian ได้ และการเป็นที่รู้จัก ก็ทำให้ได้ feedback เข้ามามากมาย โดยที่ได้ยินบ่อยที่สุดก็คือส่วนตัดคำนี่แหละ ซึ่งผมเองก็คิดเห็นเมือนเขาหลายอย่างเหมือนกัน และเขียนลง TODO list ไว้นานแล้ว ว่า "ยกเครื่องตัดคำใน libthai" แต่ก็ค้างคามาหลายปี จนเพิ่งมีเวลาว่างกลับมาดู

ด้วยความที่ไม่เคยคิดว่าจะทำมาก่อน ก็ต้องศึกษา paper ที่มีเสียก่อน ก็ไปรื้อกรุเอกสารเก่าที่เก็บไว้ ได้บทความของพี่สัมพันธ์มาอ่าน เอามาปะติดปะต่อกับแนวคิดของงานอื่นๆ ที่เคยได้ฟังมา แล้วก็ทดลองเขียนอยู่ 2-3 แบบ คิดเองเพิ่มเข้าไปบ้าง ทดลองไปมาจนคิดว่าได้แบบที่คิดว่าเหมาะที่สุดละ

เท้าความก่อนว่า การตัดคำไทยด้วยพจนานุกรม (ขอข้ามยุคการตัดคำด้วยกฎไป) สามารถวิเคราะห์ได้หลายระดับ ซึ่งทำให้ได้คุณภาพการตัดคำที่ต่างกัน เริ่มจากในระดับ lexical analysis ธรรมดาแบบ longest matching, การหา optimum แบบ maximal matching, การวิเคราะห์ไวยากรณ์เชิงสถิติด้วย n-gram, การวิเคราะห์ feature ด้วย machine learning อย่าง winnow (คล้ายๆ neural net แบบย่อมๆ) ไปจนถึงเทคนิค unsupervised learning ก็มีคนวิจัยกันมาแล้ว

สำหรับ libthai ที่เอาไว้ใช้ตัดบรรทัดหรือหาจุดหยุดเคอร์เซอร์ทีละคำแบบทันกาล (real-time) ในโปรแกรมประยุกต์ทั่วไป คงไม่ต้องการความถูกต้องแม่นยำมากขนาดที่จะใช้หลักสถิติหรือ machine learning แต่ขอให้ทำงานเร็วเข้าไว้ ผมจึงเริ่มจาก longest matching ตามบทความของพี่สัมพันธ์ก่อน แต่ก็คิดว่า เพื่อให้ได้ความถูกต้องเพิ่มขึ้น น่าจะลองขยับขึ้นมาที่ maximal matching ด้วย

บทความพี่สัมพันธ์ แม้จะเขียนไว้นานแล้ว (ป่านนี้พี่เขาอาจปรับปรุงแนวคิดไปไกลกว่านั้นมากแล้ว) แต่เป็นจุดเริ่มต้นที่ดี เพราะสรุปแนวคิดที่จำเป็นไว้ครบ คือการเดินด้วย trie, การ backtrack, การ recover จากบริเวณ error โดยเท่าที่ดูโค้ดเดิมของ libthai ก็จะเห็นเค้าของแนวคิดนี้ ซึ่งลักษณะการหาคำตอบจะเป็น longest matching

แต่เมื่อคิดต่อยอดเป็น maximal matching ก็จะเห็นอาการของ search problem ที่ต่างออกไป โดย longest matching จะเป็น depth-first search ถ้าจะปรับเป็นการหา optimum แบบ maximal matching (คือพยายาม match คำในพจนานุกรมให้มากที่สุด ซึ่งผลคือจะได้จำนวนคำน้อยที่สุด ต่างกับ longest matching ที่เป็นการพยายาม match คำปัจจุบันให้ยาวที่สุด โดยไม่ได้พิจารณาทั้งข้อความ ซึ่งอาจจะไม่ได้จำนวนคำน้อยที่สุด) ก็เพียงแต่วิ่งแบบ breadth-first เท่านั้น ซึ่งดูจะลงตัวมากๆ กับปัญหาการตัดคำ เพราะบริเวณกำกวมโดยปกติจะแบ่งเป็นช่วงๆ ทำให้ search graph มีการ merge เป็นช่วงๆ ไม่มี explosion เหมือน search problem ทั่วไป และสามารถตัดแนวคิดเรื่อง backtrack limit ที่แฝงใน depth-first search ตามบทความพี่สัมพันธ์ได้

ในอีกทางหนึ่ง ก็ไปคุยกับวีร์ที่ทำ textbreak framework เพื่อฟังแนวคิดด้วย แต่ทางนั้นเหมือนทำ framework ที่ล้วงลึกลงมาในกลไกการตัดคำ โดยตัดสินเลือกคำตอบด้วย shortest path ใน DAG (directed acyclic graph) เลยทีเดียว แต่โค้ดที่ผมเขียน ไม่ได้มีการสร้างกราฟจริงขนาดนั้น เป็นแต่จัดการ search pool และเก็บคำตอบที่ดีที่สุดขณะใดขณะหนึ่งเท่านั้น

เพื่อให้ครบ ก็ศึกษาโค้ด swath ของคุณไพศาล (TLWG version) ที่เป็นเครื่องมือตัดคำที่โอเพนซอร์สอีกตัวหนึ่งด้วย แต่ดูเหมือนว่าจะไม่ได้เน้น optimization สักเท่าไร คือพยายามสร้างการตัดคำที่เป็นไปได้ทั้งหมดก่อน แล้วเลือกคำตอบเอาตามกำหนด ว่าจะเป็น longest หรือ maximal matching ดูแล้ว น่าจะเป็นการพัฒนาเพื่อเปรียบเทียบนโยบายต่างๆ ของการตัดคำมากกว่า แต่ทั้งนี้ ยังไม่ได้ดูเวอร์ชันที่คุณไพศาลพัฒนาต่อเอง ซึ่งอาจมีการปรับปรุงไปมากกว่านี้แล้ว แต่โดยสรุปก็คือ คงไม่ใช้แนวคิดของ swath เช่นกัน

สรุปว่าได้ libthai word break ตัวใหม่ที่ตัดคำแบบ maximal matching อยู่ใน branch datrie_wbrk-branch ของ libthai CVS ตอนนี้พยายามทดสอบ-ปรับแก้อยู่ ไว้พร้อมเมื่อไรค่อย merge เข้า trunk เพื่อแทนที่โค้ดเดิม

Pluto Demotion

เข้าถ้ำต่ออีกหลายวัน (ไว้ค่อยเล่า) จนได้ยินข่าวทางทีวีเกี่ยวกับดาวพลูโต ที่ถูกปลดจากความเป็นดาวเคราะห์แล้ว เลยแว้บออกมาตามข่าวซะหน่อย

เห็นเขาเถียงกันมานานแล้ว เรื่องคุณสมบัติความเป็นดาวเคราะห์ (planet) ของพลูโต เพราะมันมีขนาดเล็กมาก แถมยังมีวงโคจรที่อยู่ต่างระนาบกับดาวเคราะห์ดวงอื่น อีกทั้งยังซ้อนเหลื่อมกับวงโคจรของดาวเนปจูนอีกด้วย แต่มีข่าวเรื่องการถกเรื่องนี้ทีไร ก็ไม่เห็นครึกโครมเหมือนครั้งนี้ จน สพฐ. ถึงกับประกาศความพร้อมที่จะแก้ตำราเรียนเลยทีเดียว

อ่าน ข่าว /. เมื่อวานซืน ซึ่งชี้ต่อไปยัง ข่าว AP Wire, ข่าว BBC และ ข่าว MSNBC ก็พอจะสรุปความได้ว่า เนื่องจากมีการค้นพบดาวบริวารของดวงอาทิตย์เพิ่มขึ้น โดยล่าสุดที่มีการรับรองคือ 2003 UB₃₁₃ ซึ่งได้ชื่อเล่นว่า Xena และเคยถูกเรียกเป็นดาวเคราะห์ดวงที่สิบ หรือ ดวงที่สิบสอง) และยังมีรอจ่อคิวอีกราว สิบสองดวง ในแถบไคเปอร์ (Kuiper Belt) โดยที่ก้อนวัตถุเหล่านี้ มีขนาดไล่เลี่ยกับพลูโต (Xena มีขนาดใหญ่กว่าพลูโตเล็กน้อย) การค้นพบวัตถุเหล่านี้ จึงเร่งให้ต้องตัดสินความเป็นดาวเคราะห์ของพลูโต ก่อนที่จะจัดประเภทให้กับดาวบริวารที่พบใหม่

ผลก็คือ มีการร่างข้อเสนอต่อสหภาพดาราศาสตร์สากล (International Astronomical Union หรือ IAU) หลายครั้ง เพื่อ ให้นิยามดาวเคราะห์ และการประชุมของนักวิทยาศาสตร์ทั่วโลกที่เช็กเมื่อวานซืน ก็เป็นการพิจารณาร่างข้อเสนอนี้เป็นรอบสุดท้าย ซึ่งผลการลงมติก็คือ ร่างข้อเสนอผ่านการเห็นชอบ และพลูโตก็ถูกตัดออกจากทำเนียบดาวเคราะห์เรียบร้อย เพื่อไปเป็นหัวขบวนของบริวารชนิดใหม่ของดวงอาทิตย์ เรียกว่า ดาวเคราะห์แคระ (dwarf planet) โดยมีการกำหนดนิยามของดาวเคราะห์ (planet) ว่าต้องมีคุณสมบัติต่อไปนี้:

• โคจรรอบดาวฤกษ์ และไม่ได้เป็นดวงจันทร์บริวารของดาวเคราะห์อื่น
• มีมวลมากพอที่จะสร้างแรงโน้มถ่วงในตัวเองให้เกิด สมดุลไฮโดรสแตติก จนมีรูปร่างเกือบกลม
• มีแรงโน้มถ่วงมากพอที่จะ เก็บกวาดวัตถุอื่น ที่ผ่านเข้ามาในวงโคจร

จากนิยามนี้ (โดยเฉพาะข้อสุดท้าย) ทำให้พลูโตตกทำเนียบดาวเคราะห์ไป รวมทั้งแนวคิดเรื่องการนับดาวเคราะห์เพิ่มเป็น 12 ดวงที่เคยมีการเสนอก่อนหน้านี้ (และมีแนวโน้มจะเพิ่มเป็น 24 ดวง และอีกมากในอนาคต) ก็มีอันตกไปด้วย โดยพลูโตจะกลายเป็นวัตถุต้นแบบของบริวารกลุ่มใหม่ของดวงอาทิตย์ คือ ดาวเคราะห์แคระ (dwarf planet) [ไม่ใช่ดาวเคราะห์น้อย (asteroid)] โดยมีคุณสมบัติเหมือนดาวเคราะห์ในสองข้อแรก ต่างที่ข้อสุดท้าย ที่จะไม่เก็บกวาดวัตถุอื่นในวงโคจร

เป็นอันว่า ขณะนี้ ระบบสุริยะถือว่ามีดาวเคราะห์แปดดวง และดาวเคราะห์แคระอีกสี่ดวง ซึ่งดาวเคราะห์แคระสี่ดวงนี้ ได้แก่ พลูโต (Pluto), แครอน (Charon), ซีรีส (Ceres) และ 2003 UB₃₁₃

สำหรับ แครอน ซึ่งเป็นดวงจันทร์บริวารของพลูโตนั้น สามารถนับเป็นดาวเคราะห์แคระ (ไม่ใช่ดวงจันทร์) ได้ เพราะมีขนาดโตพอที่จะไม่ได้โคจรรอบพลูโตจริงๆ แต่ทั้งสองดวงโคจรรอบจุดศูนย์กลางมวลของทั้งคู่ เหมือนคู่เต้นรำที่จับมือกัน แล้วหมุนไปรอบๆ มือที่จับนั้น ทำให้ในรอบแรกของการกำหนดนิยามดาวเคราะห์ใหม่ แครอนถูกยกระดับเป็นดาวเคราะห์หนึ่งในสิบสองดวง แต่ก็ถูกปลดมาเป็นดาวเคราะห์แคระพร้อมกับพลูโต

ส่วน ซีรีส ซึ่งเป็นดาวเคราะห์น้อยที่ใหญ่ที่สุดในแถบดาวเคราะห์น้อยระหว่างวงโคจรของดาวอังคารและดาวพฤหัสบดี ก็มีคุณสมบัติเพียงพอที่จะเป็นดาวเคราะห์แคระเช่นกัน โดยเป็นดาวเคราะห์น้อยดวงเดียวที่มีรูปร่างเกือบกลม ส่วน 2 Pallas ซึ่งใหญ่เป็นอันดับสองนั้น มีมวลไม่มากพอที่จะมีรูปร่างกลมได้

และ 2003 UB₃₁₃ ซึ่งมีชื่อเล่นว่า Xena (เพื่อให้เข้ากับ "ดาวเคราะห์ X" ที่เคยมีการพูดถึงกันก่อนหน้านี้หลายปี) นั้น ขนาดใหญ่กว่าพลูโตเล็กน้อย วงโคจรรีมาก และทำมุมเอียงกับระนาบวงโคจรของโลกมากถึง 44 องศา

สมาคมดาราศาสตร์ไทย ก็มี รายงานพิเศษ เรื่องนี้ด้วย

Double-Array Trie got KISSed

เข้าถ้ำมาอาทิตย์เศษ เพื่อเริ่มกระบวนการรื้อโค้ดตัดคำใน libthai (คิดว่าจะไม่มีโอกาสได้ทำซะแล้ว) โดยขั้นแรกคือการแยก dictionary ออกมาจากซอร์สโค้ด จึงเริ่มจากเขียน Double-Array Trie ขึ้นมาใหม่ หลังจากที่เคยเขียน midatrie (multi-index double-array trie) เป็น C++ ไว้ที่เนคเทค (LGPL-2.1) ก็เอามาเขียนใหม่เป็นภาษา C และพยายามใช้หลัก KISS (Keep it Simple, Stupid) เข้าไว้

เหตุที่เขียนใหม่ แทนที่จะทำ C wrapper ก็เพราะมีหลายประเด็น ที่เกิดขึ้นระหว่างวิจัยและพัฒนา midatrie ที่เห็นควรตัดทิ้ง ได้แก่:

• virtual memory: ในขณะที่เขียน midatrie นั้น หน่วยความจำในเครื่อง PC ขนาด 8 MB นี่ก็นับว่าหรูแล้ว ในขณะที่ฐานข้อมูลที่จะใช้มีขนาดใหญ่ จึงใช้วิธีอ่านเข้ามาทีละส่วนตามการใช้งาน ซึ่งสุดท้าย ก็ได้เป็นรูปแบบคล้ายๆ virtual memory ในระบบปฏิบัติการ ซึ่งผลก็คือ trie ที่ได้ จะทำงานช้ากว่าการโหลดเข้าหน่วยความจำเต็ม ซึ่งมีมากพอแล้วในสมัยนี้ อีกทั้งขอบเขตปัญหา ถ้าฐานข้อมูลไม่ได้ใหญ่ขนาด NLP ที่ซับซ้อน การโหลดเข้าหน่วยความจำก็ไม่ควรจะเปลืองเกินไป
• ส่วนขยายของ trie ที่มีการลดขั้นตอน เช่น ใน key ที่เป็น substring ของ key อื่น จากที่ paper ของ Aoe ชี้ไปหา tail ที่ว่างเปล่าแล้วเก็บข้อมูลในนั้น ในแล็บก็เกิดแนวคิดที่จะลัดขั้นตอน ด้วยการเก็บข้อมูลใน double-array เลย โดยไม่ต้องชี้ไปที่ tail ซึ่งผลก็คือ ทำให้เกิดกรณีพิเศษขึ้น จากเดิมที่มีแต่ boolean ว่าเดินได้หรือไม่ได้ ก็มีกรณีที่สามให้จัดการในที่ต่างๆ ซึ่งขยายวงไปถึงการออกแบบโครงสร้างโปรแกรมใหม่ ให้มีชนิดที่มาใช้แทน boolean อีกด้วย ซึ่งทั้งหมดนี้ เห็นว่าไม่คุ้มกับขั้นตอนเล็กๆ น้อยๆ ที่ประหยัดลงได้
• utility routine: เมื่อเขียนโค้ด C++ แบบไม่ใช้ STL ไปมากๆ เข้า (ในขณะนั้น มาตรฐาน ISO C++ ยังอยู่ระหว่างการร่าง และ STL หรือแม้แต่การสนับสนุน template ยังไม่ได้มีในคอมไพเลอร์ต่างๆ) ก็จะมี utility class เพิ่มเข้ามาเรื่อยๆ ทั้งที่ใช้ใน midatrie เอง และที่ใช้ในโปรแกรมอื่นในโครงการเดียวกัน การเปลี่ยนมาใช้โครงสร้างข้อมูลแบบ C ง่ายๆ ทำให้สามารถตัดโค้ดพวกนี้ออกไปได้ (libpenknife++ ก็ไม่ต้องใช้เลยด้วยซ้ำ!)

นอกจากนี้ ยังมีทางเลือกให้ตัดสินใจอีก คือกลุ่มของอาจารย์ Aoe ได้พัฒนาโครงสร้าง two-trie และ link trie เพิ่มเติม โดยเขียนเป็น paper อีกสองฉบับใน IEEE แต่หลังจากที่อ่านแล้ว link trie ใช้กับโครงสร้างข้อมูลที่มีความสัมพันธ์ระหว่างคำ ไม่เกี่ยวกับที่จะใช้ ส่วน two-trie (การใช้ prefix trie กับ suffix trie ประกอบกัน เพื่อใช้ trie ตัวที่สอง compress suffix) นั้น มีจุดบอดเกี่ยวกับการเชื่อมโยงระหว่าง prefix node กับ suffix node เพราะเมื่อโครงสร้าง double-array มีการ relocate เพื่อหาที่ว่างใหม่ จะทำให้ index ของ suffix node เปลี่ยน และ link ก็จะขาดไปเลย เป็นจุดบอดที่เคยพบและขบคิดเมื่อหลายปีก่อน จนกระทั่งตัดสินใจเขียนเมลไปปรึกษาอาจารย์ Aoe ก็ปรากฏว่า ท่านก็ยอมรับว่ามีปัญหา แล้วก็ได้ paper เกี่ยวกับ link trie มาอ่านแทน (เป็นฉบับร่าง ซึ่งวันก่อน vee ช่วยหาฉบับจริงมาให้อีกที) และมารอบนี้ ก็ลงมือคิดใหม่อีกครั้ง ก็ไม่พบวิธีแก้ที่ง่ายและไม่เสียเวลาวิ่งค้นเลย

สรุปว่ากลับมาที่โครงสร้าง double-array + tail อีกครั้ง ซึ่งน่าจะเหมาะเจาะที่สุดละ

นั่งเขียนไปทดสอบไป ตอนนี้ก็เริ่มทำงานได้ละ มีการเปลี่ยนฟอร์แมตของแฟ้มด้วย เพราะไม่ต้องใช้ virtual memory แล้ว ทำให้เรียงข้อมูลชิดกันได้เต็มที่ ประหยัดเนื้อที่ได้อีก

โค้ดอยู่ที่ TLWG CVS ชื่อมอดูลคือ software/datrie ก็อาจ check out ได้โดย:

 
  cvs -d :pserver:anonymous@linux.thai.net:/home/cvs     co software/datrie

ชอบความเรียบง่ายของภาษา C ด้วยแฮะ เทียบกับ C++ อาจจะใช้ภาษา C ต่อไปเรื่อยๆ :-)

Frozen around

แช่แข็งกันติดๆ เริ่มจาก Debian เริ่ม freeze essential toolchain ก่อนที่จะทยอยประกาศ freeze แพกเกจชุดอื่นๆ ต่อไป เพื่อเริ่มเข้าสู่กระบวนการ release etch เดือนธันวา

ส่วน GNOME ก็ ปล่อย GNOME 2.16.0 Beta 2 (2.15.91) แล้ว ซึ่งหมายถึงการเข้าสู่ช่วง string freeze โดยข้อความในโปรแกรมจะอยู่นิ่งๆ ให้นักแปลได้กระหน่ำแปลให้ครบ

แช่แข็งกันหมด แต่ทำไมฉันนั่งปาดเหงื่อซ่กๆ - -'

Please Check Your Weather

กรุณาตรวจสอบข้อมูลรายงานอากาศในเขตของท่าน เป็นประกาศใน GNOME devel announce list เพราะเขาจะลบตำแหน่งที่ตั้งที่ไม่มีรายงานอากาศในช่วงครึ่งปีที่ผ่านมา ออกจาก gweather applet

สำหรับประเทศไทย หากคุณพบว่าคุณอยู่ในพื้นที่ต่อไปนี้ (คัดมาจาก รายการที่จะลบ) แต่ว่าได้รับรายงานสภาพอากาศของเขตของคุณผ่าน gweather applet (เข้าใจว่า evolution ก็ใช้ข้อมูลชุดเดียวกัน) กรุณาแจ้งให้เราทราบ:

Removing VTUC Chaiyaphum
Removing VTBC Chanthaburi
Removing VTCR Chiang Rai
Removing VTCS Mae Sariang
Removing VTBS Chon Buri
Removing VTSD Chumphon
Removing VTBG Kanchanaburi
Removing VTUB Mukdahan
Removing VTUP Nakhon Phanom
Removing VTUN Nakhon Ratchasima
Removing VTPN Nakhon Sawan
Removing VTSN Nakhon Si Thammarat
Removing VTUM Nong Khai
Removing VTBJ Phetchaburi
Removing VTPS Phitsanulok
Removing VTBI Prachin Buri
Removing VTBP Prachuap Khirikhan
Removing VTUR Roi Et
Removing VTUS Sakon Nakhon
Removing VTSA Satun
Removing VTSH Songkhla
Removing VTPU Uttaradit

รหัสตัวอักษรสี่ตัวที่มาก่อนชื่อเขต คือรหัสสนามบิน ซึ่งสำหรับบางเขต เช่น สงขลา ผมเข้าใจว่าส่วนใหญ่จะใช้ข้อมูลจากสนามบินอื่นในเขต เช่น หาดใหญ่ กันอยู่แล้ว

ฟู่.. เขตผม (ขอนแก่น) รอดตัว การล้างบางครั้งใหญ่นี้ เป็นการปลดเปลื้องภาระของนักแปลไปได้เยอะโขอยู่ รวมทั้งตอนโหลดกล่องโต้ตอบปรับแต่ง gweather applet ก็จะใช้เวลาลดลงด้วย :-)

ขอบคุณ

ขอขอบคุณ คุณหน่อย ผู่หย่อนสตางค์ลงหมวกคนล่าสุด ขอบคุณช้าไปหนึ่งอาทิตย์ คงไม่ว่ากันนะคร้าบ

น่าเสียดายกับ Speed Net Club จุ้ยเซียนเหลาชาวโอเพนซอร์ส ที่ต้องปิดตัวลง แต่ได้ข่าวว่างานใหม่ของคุณหน่อยจะมีความมั่นคงขึ้น ในขณะที่ยังคงเผยแพร่โอเพนซอร์สอยู่เหมือนเดิม ขอให้เจริญก้าวหน้ายิ่งๆ ขึ้นไปนะครับ :-)

libthai 0.1.6, debian doc-base

ไม่ได้ blog ไปหนึ่งอาทิตย์เต็มๆ เพราะพยายามทำ libthai ตัวใหม่อยู่ โดยในรุ่นนี้ มีการแก้ compiler warning พร้อมๆ กับแพกเกจต่างๆ ที่ upload ขึ้น debian เนื่องจาก buildd ของ debian มันช่วย build package ในแพลตฟอร์มอื่นนอกเหนือจาก i386 ที่เรา upload ให้โดยอัตโนมัติ ทำให้พบ portability issue จำนวนหนึ่ง ก็เอามาแก้ ซึ่งสำหรับ libthai เอง ไม่ได้มี portability issue อะไรมากมาย นอกเสียจาก warning เล็กๆ น้อยๆ เรื่อง signed/unsigned กับขาด header file

แต่การเปลี่ยนแปลงที่เห็นได้ชัดที่สุดในรุ่นนี้ คงเป็นเรื่อง auto-generated document โดยใช้ doxygen ก็นั่งตกแต่ง comment ในฟังก์ชันต่างๆ ให้อยู่ในรูปแบบที่เหมาะสม และย้ายเนื้อหา manpage ที่คุณพูลลาภเคยเขียนไว้ เข้ามารวมด้วย แล้วก็ใช้ doxygen สร้างเอกสาร HTML และ manpage ในคราวเดียว และในระหว่างที่ตรวจแก้ ปรากฏว่าพบฟังก์ชันที่ขาดหาย ก็เขียนเพิ่มเข้าไปด้วย

แล้วก็ได้เป็น libthai 0.1.6 พร้อมทั้ง แปะประกาศ ที่ LTN Devel Webboard ด้วยเมื่อเช้าวานนี้

หลังจากนั้น ก็ลุยเคลียร์ OSS glossary กับทีมแปลที่ห้อง #tlwg ต่อ ตามที่นัดกันไว้ จนถึงเย็น

เลิกประชุม เจียะปึ่งแล้ว ก็มานั่ง build debian package ให้กับ libthai โดยคราวนี้ ทำความสะอาดแพกเกจเพิ่มเติมอีกหน่อย พร้อมทั้งเพิ่มแพกเกจ libthai-doc เพื่อติดตั้งเอกสาร HTML ด้วย เสร็จแล้วก็เมลติดต่อ sponsor

ยังไม่เคยพูดถึงเรื่องระบบเอกสารของ debian.. ความจริงแล้ว debian policy ได้กำหนดที่อยู่ของเอกสารต่างๆ ของแพกเกจไว้ที่ /usr/share/doc/package ใครติดตั้ง debian package เสร็จ จึงมักได้พึ่งพาอาศัยไดเรกทอรีนี้ในการเริ่มทำงาน โดยในนั้นจะมีแฟ้มพวก README ของ upstream, README.Debian, examples ฯลฯ ให้ตั้งต้นใช้งาน ซึ่งสำหรับหลายๆ แพกเกจ มักจะมีข้อมูลเพียงพอสำหรับคนที่ยังไม่เคยใช้งานมาก่อน เมื่อประกอบกับความสะดวกของ apt และ debconf ที่ช่วยกำหนดค่าเริ่มต้นต่างๆ ให้ ทำให้การลองเล่นซอฟต์แวร์ต่างๆ ใน debian เป็นเรื่องสนุกสนานมาก

แต่นอกเหนือจากนั้น ก็ยังมี document ในแบบ man page และ info page ตามปกติ เอาไว้ใช้อ่านรายละเอียดของคำสั่งหรือฟังก์ชัน ซึ่งที่หน้า QA ของเดเบียน จะมีการเชิญชวนคนในชุมชนมาช่วยกันเขียน man page ให้กับแพกเกจที่ยังขาด โดยระบบตรวจคุณภาพของแพกเกจจะลิสต์แพกเกจดังกล่าวโดยอัตโนมัติ

แล้วก็ยังมีหลายแพกเกจ ที่แยกแพกเกจ *-doc ออกมาต่างหาก โดยอาจจะเป็นเอกสาร HTML หรือ PDF อะไรก็ตามแต่ โดยไม่ติดตั้งกับระบบปกติ ให้ลงต่างหากเอาถ้าต้องการ

จากความหลากหลายของรูปแบบเอกสารนี้ debian มีวิธีจัดการให้สามารถเรียกดูและค้นหาได้ทั้งหมด ผ่านระบบเอกสารกลางที่เรียกว่า doc-base โดยให้ทุกแพกเกจที่มีเอกสาร ไปลงทะเบียนกับ doc-base ไว้ จากนั้น จะมี front-end ที่มาอ่านเอกสารที่ลงทะเบียนไว้ทั้งหมด โดยบาง front-end อาจมีการแปลงรูปแบบให้เป็น HTML ได้ด้วยถ้าทำได้ ซึ่งตอนนี้ มี front-end อยู่สามตัว คือ dhelp, dwww และ doc-central ซึ่งทั้งสามตัว เตรียมให้ดูด้วยเว็บเบราว์เซอร์ทั้งหมด ซึ่งเรียงตามลำดับขนาดแพกเกจจากเล็กไปใหญ่ ก็จะเริ่มจาก doc-central, dhelp แล้วก็เป็น dwww แต่ dhelp ดูจะน่าใช้ตรงที่ไม่ต้องใช้ web server ก็ดูได้ โดยแค่เปิดไฟล์ในเครื่องดูก็เป็นอันเสร็จ (แต่ถ้ามี จะ search ผ่าน CGI ได้) ส่วนอีกสองตัว ต้องใช้ web server โดย dwww สามารถ convert เอกสารรูปแบบอื่นเป็น HTML ก่อนเปิดใน web browser ได้ด้วย

นั่นคือ integration อีกอย่างหนึ่งของ debian ซึ่งอาจจะครอบคลุมกว้างกว่าระบบ scrollkeeper และ yelp ของ GNOME หรือระบบที่คล้ายกันของ KDE

และ libthai-doc ก็ได้ register ตัวเองเข้ากับ doc-base ของ debian ด้วย :-)