הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
שוחררה גרסה מקדימה של Boost.Locale 3.
שלום,
שוחררה גרסה מקדימה של Boost.Locale
- מדריך: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html
- תיעוד מפורט: http://cppcms.sourceforge.net/boost_locale/html/index.html
- הורדה: https://sourceforge.net/projects/cppcms/files/boost_locale/
חדש בגרסה:
- התווספה תמיכה במנגנוני לוקליזציה מרובים:
- ספריית ICU - ברירת מחדל
- תמיכה בסיסית של הספריית הסטנדרטית של C++ עם שיפורים.
- POSIX 2008 API (כמו strftime_l)
- Windows API.
התמיכה הזו מאפשרת להשתמש בכלי לוקליזציה בסיסיים גם ללא ספריית ICU הכבדה.
- שיפורים משמעותיים בממשק וניהול לוקלים
- תיקוני ביצועים עובר ICU
- שיפורים בעבודה עם UTF-8
- תיקונים בתמיכה ב־UTF-16
ועוד.
קיימת תמיכה ב:
- מערכות הפעלה: Linux, FreeBSD, OpenSolaris, Windows, Cygwin, (בקרוב גם Mac OS X).
- מהדרים (קומפיילרים) gcc (גרסאות 3.4 עד 4.5), Intel 11, MSVC9, SunCC 5.10/stlport
אמת המרה על רמת התמיכה בלוקליזציה
כפי שחלק מקוראי הבלוג אולי יודעים, אני עובד על ספריית Boost.Locale שאני מקווה תשולב ב־Boost בעתיד.
הספריה נותנת בין השאר תכונות חשובות כמו: תרגום מחרוזות, הצגת תאריכים, מספרים, חלוקת הטקטס לתווים, מילים, מיון לפי סדר אלף־בית וכד'.
כדי לאפשר תמיכה נאותה בכל המרכיבים האלה, אני משתמש בספרית ICU שנותנת את כל הדרוש, למעט API שמתכנת C++ שפוי יכול להשתמש בו.
למרות ש־ICU היא ספריה מצוינת, יש לה גם לא מעט חסרונות:
- גודל הספרייה שמכילה את כל הנתונים הוא כ־12 מ"ב! זה בד"כ מאוד בעייתי עבור סביבות משובצות מחשב.
- ביצועים - היא לא מצטיינת בהם, למשל יצירת תאריך או מספר לוקחת עד פי 10 יותר זמן בעזרת פונקציות ICU השוואה לפונקציות כמו strftime.
לכן, החלטתי להוסיף ל־Boost.Locale מנגנונים שיאפשרו לעבוד עם התמיכה הבסיסית בלוקליזציה שנמצאת בכל מערכת הפעלה או ספריה סטנדרטית.
למרות שכמעט בכל מערכת הפעלה יש פונקציות כמו setlocale, strcoll או strftime הן לא מתאימות לי כי הן אינן מאפשרות לעבוד עם מספר לוקלים שונים באותו תהליך בצורה בטוחה.
אבל עדיין, יש לי שלוש אופציות:
- שימוש בספריית C++ הסטנדרטית שמכילה את מרבית הדברים הנדרשים.
- שימוש ב־API של POSIX 2008 שמגדיר אוסף פונקציות כמו newlocale, strftime_l או strcoll_l במערכות תואמות POSIX (למעשה, ה־API הזה נתמך בלינוקס ובמק).
- שימוש ב־Win32 API שנותן פונקציות די עשירות כמו GetDateFormat, CompareString וכד' שנותנות תמיכה רצינית בלוקליזציה.
כמובן פה ושם צריך לסדר דבר או שניים כמו MSVC שלא מכיר בשמות לקול כמו en_US.UTF-8 ולא תומך ב־UTF-8, לעשות התאמות פה ושם להבדלים בין לינוקס ומק במימוש של API של לוקליזציה וכד'.
עד כאן זה נראה מבטיח, אבל מסתבר שרק על הנייר...
- libstdc++ של GCC לא תומך בלוקליזציה בשום מערכת הפעלה מלבד Linux (לא שזה חדש, בגלל זה הוספתי את שתי האופציות הנוספות).
- מסתבר שב־Mac OS X (וגם ב־FreeBSD) פונקציה strcoll שבורה לחלוטין, כך הוא לא יודע לסדר a < ç < d או אפילו a < C < d כפי שזה מתבקש בשפה בטבעית.
- ב־Solaris פונקציות towupper ו־towlower לא ממש מתחשבות בלוקל (למשל בלוקל טורקי i הופכת ל-"İ" ולא ל־"I" ב־upper case)
בגדול... עצוב ומעצבן, אבל... טוב שיש לנו ICU וטוב שלפחות לינוקס וחלונות מספקים API שעובד בצורה סבירה (אם כי ממש לא מושלמת).
שוחררה גרסת בטא שניה של CppCMS
שוחררה גרסת בטא שניה של CppCMS. השינויים כוללים בין השאר:
- שיפורי ביצועים משמעותיים, בפרט בעבודה עם FastCGI, כך שהביצועים שלו לא נופלים מאלו של SCGI.
תיקוני באגים חשובים, ביניהם:
- תיקוני באגים בהעלאת קבצים
- בעיות שליחת תגובת HTTP במערכות אסינכרוניות.
- בעיות בייצוג מספרים ב־JSON.
התווספו דוגמאות נוספות, בפרט עבודה עם JSON ו־Comet.
אבל, אחד הדברים החשובים בעיניי בגרסה הזו, הוא לאו דווקא עצם שחרור הגרסה הנוספת, אלא מעבר הקהילה ישירות לגרסה 1.x.x של CppCMS בזכות שיפורים רבים שהוכנסו לתוכה, למעשה, רוב המשתמשים הפעילים ברשימת התפוצה של CppCMS משתמשים בגרסה החדשה, למרות שהיא עדיין נחשבת לגרסת בטא.
ואללה Vala!
כבר לא מזמן שמתי לב על פרויקט Vala של Gnome... אבל רק עכשיו יצא לי לנסות את הגרסה העדכנית שלו לעומק (גרסה 9.2).
כשקראתי בפעם הראשונה על Vala התגובה הייתה: "It is too good to be true".
- שפה מקומפלת ורצה בצורה טבעית (ללא זבל של VM ו־JIT) שזה אומר שהיא לא צורכת הרבה משאבי CPU.
- שפה שמשתמשת ב־GC פשוט (שימוש ב־reference counting במקום GC אמתי). מדוע זה טוב? כי יש לך דטרמיניסטיות ו־destructors - שזה אומר שהיא לא צורכת הרבה זיכרון.
- תמיכה ב־RAII שכל־כך חסר לי שפות כמו Java או C#.
ובנוסף לכל:
- הם הרוויחו ישירות SDK מאוד עשיר של Gnome. כי כל מה שמבוסס על GObject בא בצורה טבעית ל־Vala.
- הם הרוויחו תמיכה בפלטפורמות רבות בכלל שהם בחרו כשפת ביניים את C, כך שרוב העבודה הקשה הם משאירים למהדרי C (שיש בשפע החל מהדרים חזקים כמו gcc עד מהירים וקלילים כמו tcc).
לטעמי, שפה כמעט מושלמת לפיתוח יישומיים יומיומיים.
למעשה, היום ל־C++ יש מספר חלופות מצומצם שנותנות יכולות דומות עם פישוט של השפה עצמה: D, Vala, ו־FPC. (אני לא מדבר על Java או C#/Mono כי הם בכלל בליגה אחרת)
שפת D היא בעלת פוטנציאל גבוהה ביותר מכולם, אבל אני אישית חושב שעבודה עם Garbage Collection מקשה על הרבה דברים. היא מפרידה בין שני סוגי המשאבים: זיכרון וכל השאר (שהם הרבה יותר יקרים) כמו קבצים, נעילות, קשרי רשת פתוחים ועוד, שכן דורשים ניהול דטרמיניסטי. כך שאני חושב שעובדה עם Reference Counting נותנת מענה ל־95% מהמקרים, והשאר, נפתרים בקלות עם מעט תחכום.
Pascal בעייתית מהרבה בחינות, כולל ניהול משאבים ידני, העדר RAII וגם GC ועוד הרבה דברים שהופכים אותה מזדנבת מאחורי הטכנולוגיות המודרנית (עידו, זאת דעתי, אתה יכול להסכים או לא להסכים אתה).
עכשיו, על הנייר, נראה ש־Vala לקחה את הטוב ביותר מהרבה שפות
- מ־C היא לקחה ה־ABI הפשוט וקלות חיבור עם שפות אחרות, בסה"כ מדובר ב־C!
- מ־C++ היא לקחה את RAII, לקחה את ה־Destructors.
- מ־C# היא לקחה את OOP ואת הקלות של הכתיבה כך אפשר מהר ובקלות להיכנס לפיתוח.
אז החלטתי להסתכל לעומק
ציפו לי מספר אכזבות:
- Vala לא תומכת ב־Overloading בדיוק כמו ש־C לא תומך. ההיגיון מאחורי הוא די פשוט: הם רוצים שקוד C שנוצר יהיה שימושי גם מחוץ ל־Vala, קרי יישום של GTK יוכל להשתמש במחלקות שבמקור כתובות ב־Vala וזאת טענה מאוד חזקה שאני מוכן לקבל.
החריגות (Exceptions) ב־Vala הן ממש לא חריגות כפי שאנחנו מכירים אותם ב־C++ או ב־Java - הן לא מחלקות. אי אפשר ליצור היררכיה של חריגות, למשל DiskError שיורש מ־IOException והוא בתורו יכול יורש מ־Exception הבסיסי.
החריגות הן למעשה צירוף של תחום (domain) קוד ומחרוזת המייצגת את השגיאה, כך למשל כדי להציג חריגה שדיברנו עליה אנחנו מייצרים errordomain IOError בתוכו אנחנו בוחרים סוגים כמו
DISK_ERRORשהוא פרמטר של החריגה, וכמובן גם טקסט. מבחינה זו, היה יותר נכון לקרוא להן Error Code מאשר חריגה במובן הקלסי.נכון שזה מכסה 95% מכל המקרים, אבל זה כן מייצר בעיה כשאתה רוצה להעביר מידה יותר מורכב (אם כי זה נדיר).
התיעוד עדיין לוקה בחסר הן מבחינת השפה עצמה והן מבחינת הספריות (אני צריך לפנות כל פעם לתיעוד GTK של C כדי להבין מה מתודה מסוימת עושה).
לפחות בשלב זה, אתה חייב לדעת C, כי לפעמים, כן קוראות שגיאות קומפילציה ברמת C, במיוחד עם ספריות חסרות או גרסאות לא תואמות.
אבל בגדול: שפה מהירה מאוד, פשוטה, בעלת SDK מאוד עשיר ואני צופה לה עתיד מעניין.
סיכום
היום Vala היא עדיין לא שפה מוכנה ל־Prime Time, אלא אם אתם מוכנים להיות בודקי הבטא שלה, מצד שני אם אתה יודע C ומכיר Gtk מספיק טוב, אתה תוכל להסתדר בקלות אתה.
היום מספר שפות יחסית מהירות ומתאימות לפיתוח יישומי Destkop: C, C++, D, C#, Java, Pascal ו־Vala. אני בהחלט רואה ב־Vala פוטנציאל גבוהה (כמובן לצידה של C++).
שוחררה גרסת בטא ראשונה של CppCMS 1.x.x
בשעה טובה, אחרי כשנה של פיתוח שוחררה גרסת בטא חדשה של CppCMS (הורדה), מעבר לשינויים מעמיקים ושכתוב מחצית מהקוד שהוסיפו תכונות מתקדמות רבות כמו תמיכה מובנית ב־Comet, היא מביאה את CppCMS לשלב תפיסתי אחר - בשלות פיתוחית.
כשהפרויקט התחיל, היה קשה מאוד להרים משהו עובד מבלי להיעזר בכמות עצומה של ספריות צד ג' ולהתחשב בנזק התחזוקתי והתפיסתי הן יגרמו לי בהמשך. אבל בלעדיהן לא הייתי מצליח להרים פרויקט כפישהו היום. אחרי ניסיון שצברתי יכולתי לשכתוב חצי מהמערכת כדי להגיע למצב בו היא נמצאת היום.
אז היום, הייתי מגדיר את CppCMS 1.x.x כגרסת תיקון גדולה לכל הטעויות התכנוניות שעשיתי בגרסאות הראשונות של CppCMS ושיפורים מהותיים שיכלו להיכנס לעקבות התיקונים האלה.
- הכנסתי event-loop מרכזי שמנהל את כל המערכת ומאפשר הרצת יישומי comet אסינכרוניים. דבר שדרש ממני להפתר מספריות כמו libfcgi ו־cgicc (וטוב שכך).
- בניתי מערכת שיודעת לשמור על ABI יציב בין הגרסאות
- העפתי את Boost שהופך תחזוקת ABI לסיוט מתמשך
- הוספתי תמיכה טבעית בפלטפורמות רבות בפרט ב־Windows ובקומפיילר MSVC.
ועוד, ועוד ועוד: רשימת השינויים העיקריים.
במילים אחרות... זאת בהחלט הגרסה המשמעותית ביותר מאז הבטא הראשונה של הפרויקט שוחררה.
יש עוד דרך ארוכה לגרסה יציבה, אבל אני מקווה שלקראת סוף 2010 תחילת 2011 היא תשוחרר.
קישורים
- הורדה
- הוראות בניה
- רשימת התיעוד המלאה (התיעוד עדיין חלקי)
- תיעוד מפורט - Doxygen.
