הבלוג של ארתיום :: לינוקס

ייסורי בינאום ולוקליזציה בשנת 2009

מה יותר פשוט מאשר להציג תאריך ושעה בהתאם למקובל באיזור? בארה"ב תכתוב ‎6/15/2008 8:30 PM ובישראל תכתוב 15/6/2008 20:30. לא מסובך, נכון? כמובן ‎strftime‎ עושה את העבודה הנאמנה בצורה טובה. אכן, יש אופציות ‎"%x"‎ ו־‎"%X"‎ להצגת תאריך ושעה בהתאם ללוקל מקומי.

עכשיו בואו נעשה את הדרך ההפוכה: יש לנו טופס HTML בו אנחנו רוצים להציג תאריך ולתת למשתמש אפשרות לערוך אותו? במילים אחרות אני רוצה אופציה של פענוח תאריך ושעה לפי התבנית המקובלת לאיזור ובשפה הספציפיים… ואכן, יש פונקציה הפוכה ל־strftime ‏— strptime. שעושה את העבודה ההפוכה.

כמובן גם ב־C++‎ יש מקבילות std::facet מסוג: std::time_put ו־std::time_get עושות את העבודה וגם מאפשרות להשתמש ביותר מ־locale אחד בתהליך, שמאפשר, למשל לייצר טקסט שונה למשתמשים שונים בחוטים שונים. ב־C ובשירותי מערכת ההפעלה הסטנדרטיים אין כלי כזה, יש רק strftime_l ו־strptime_l הלא מתועדים ולא מוגדרים לפי סטנדרט שעושים את העבודה.

מכאן, הכל פשוט… על הנייר. במציאות המצב הרבה יותר מסובך:

הגדרות סטנדרט C++‎ של std::time_get מכילות באג לוגי שמקשה מאוד על יצירת כלים לפענוח תאריך ושעה בצורה נכונה וגם כשעובדים, הם עושים זאת בצורה חלקית — כי אין מקבילה של strptime המלאה של C.
גם API של C, מסתבר כלא תמיד עובד כמו שצריך.

לצורך ההשוואה, בניתי תכנה פשוטה, שמייצרת מחרוזת עם תאריך ושעה בעזרת כלֵי C,‏ C++‎ וספריית ICU. ולאחר מכן מפענחת אותה אם אותם הכלים. בדקתי את זה עבור מספר לוקלים. בטבלה למטה מוצגים: לוקל, שעה ותאריך כפי שמייוצרים ע"י כלים שונים והפענוח של אותם תאריך ושעה המוצגים בפורמט בינלאומי.

    en_US.UTF-8
    strftime        10/05/2009 11:36:38 PM to 2009-10-05 23:36:38
    std::facet      10/05/2009 11:36:38 PM to 2009-10-05 00:00:00
    icu::DateFormat Oct 5, 2009 11:36:38 PM to 2009-10-05 23:36:38
    he_IL.UTF-8
    strftime        05/10/09 23:36:38 to 2009-10-05 23:36:38
    std::facet      05/10/09 23:36:38 to 1909-10-05 23:36:38
    icu::DateFormat 23:36:38 05/10/2009 to 2009-10-05 23:36:38
    de_DE.UTF-8
    strftime        05.10.2009 23:36:38 to 2009-10-05 23:36:38
    std::facet      05.10.2009 23:36:38 to 2009-10-05 23:36:38
    icu::DateFormat 05.10.2009 23:36:38 to 2009-10-05 23:36:38
    en_GB.UTF-8
    strftime        05/10/09 23:36:38 to 2009-10-05 23:36:38
    std::facet      05/10/09 23:36:38 to 1909-10-05 23:36:38
    icu::DateFormat 5 Oct 2009 23:36:38 to 2009-10-05 23:36:38
    ja_JP.UTF-8
    strftime        2009年10月05日 23時36分38秒 to 2009-10-05 23:36:38
    std::facet      2009年10月05日 23時36分38秒 to 2009-10-05 23:36:38
    icu::DateFormat 2009/10/05 23:36:38 to 2009-10-05 23:36:38
    ar_EG.UTF-8
    strftime        05 أكت, 2009 IST 11:36:38  to 2009-10-05 00:00:00
    std::facet      05 أكت, 2009 IST 11:36:38  to 2009-10-05 11:36:38
    icu::DateFormat ٠٥/١٠/٢٠٠٩ ١١:٣٦:٣٨ م to 2009-10-05 23:36:38
    tr_TR.UTF-8
    strftime        05-10-2009 23:36:38 to 2009-10-05 23:36:38
    std::facet      05-10-2009 23:36:38 to 2009-10-05 23:36:38
    icu::DateFormat 05.Eki.2009 23:36:38 to 2009-10-05 23:36:38
    ru_RU.UTF-8
    strftime        05.10.2009 23:36:38 to 2009-10-05 23:36:38
    std::facet      05.10.2009 23:36:38 to 2009-10-05 23:36:38
    icu::DateFormat 05.10.2009 23:36:38 to 2009-10-05 23:36:38
    zh_CN.UTF-8
    strftime        2009年10月05日 23时36分38秒 to 2009-10-05 23:36:38
    std::facet      2009年10月05日 23时36分38秒 to 2009-10-05 23:36:38
    icu::DateFormat 2009-10-5 下午11:36:38 to 2009-10-05 23:36:38

כפי שניתן לראות:

std::facet לא מתמודד עם שעון של 12 שעות המכיל ציון AM/PM.‏
std::facet לא מוסוגל לשחזר שנה בעזרת שתי ספרות בלבד וזורק אותנו משנת 2009 ל־1909 ב־2 מתוך 9 דוגמאות.
strptime לא מצליח לשחזר שעה בכלל ו־std::facet וטועה ב־12 שעות בלוקל מצרי.יש לציין שזה באג בייצוג locale כי הפורמט המוגדר הוא ‎"%Z %I:%M:%S"‎ במקום ‎"%p %I:%M:%S"‎ — להציג איזור זמן במקום סימון AM/PM המתאים (م).

במילים אחרות… מימוש של std::facet גרוע, יש בעיות בייצוג locale באופן כללי.

עצוב שזה המצב בשנת 2009…

המשך...

נפלאות ה־Comet בשרתי האינטרנט המודרניים...

כפי שפרסמתי לאחרונה, אני עובד על תמיכה ב־Comet או HTTP Push ב־CppCMS. כאשר הכוונה לאפשרות שרת האינטרנט ליידע את הלקוח על אירוע חדש, למשל: "הגיעה מסר מידי חדש, או מחיר המניה השתנה" – למעשה להעביר אירועים ללקוח בזמן אמת.

כיצד התהליך מתבצע? הלקוח פונה לשרת עם בקשת HTTP לקבל עדכונים; והשרת, במקום לענות באופן מידי ממתין ומחזיק את הקשר פתוח. כאשר מגיע האירוע החדש, כמו עדכון מחיר המניה או הודעה חדש מחבר, התשובה נשלחת והתליך חוזר.

לא מי יודע מה מסובך כמובן זה גם תלוי ביכולת השרת להחזיק קשר HTTP פתוח למשך הרבה זמן.

אבל, מה קורה אם הלקוח סוגר את הקשר לפני שהוא מקבל תשובה? בבקשות HTTP רגילות זה אירוע נדיר והיישום בצד השרת יכול בקלות "להתעלם" ממצב כזה. ביישומי Comet זה שונה: מספיק שמישהו נכנס לאתר שמחכה לדף שמבצע בקשה מסוג זה ויוצא ממנו, הקשר לקבלת עדכונים ייסגר.

אבל מה יישום Comet אמור לעשות? תחשבו שמספר הבקשות HTTP שנסגרות לפני דיווח על אירוע מסוים יכול להיות הרבה יותר גדול ממספר התגובות הרלוונטיות בפועל. אז יישום תקין צריך לזהות ניתוקים כאלה, ולמחוק אותם מ"רשימת התפוצה שלו".

אבל מה? יישום ה־Comet בד"כ לא מדבר ישירות עם הלקוח בעזרת HTTP אלא מדבר עם שרת web בעזרת פרוטוקול סטנדרטי כמו FastCGI או SCGI. לכן, תפקידו של השרת הוא לדווח ליישום על כך שהלקוח סגר את הקשר. למעשה פרוטוקול FastCGI מגדיר במפורש דרך להפסיק בקשה מסויימת ע"י סגירת ה־socket או שליחת בקשה מיוחדת "Abord Request", כנ"ל ניתן לבצע בעזרת scgi ע"י ניתוק ה־socket.

פשוט? כן. האם זה קורה בפועל? לא ממש.

אחרי שמימשתי מערכת ניתוק הקשר ובדקתי אותה על שרת http פנימי, החלטתי לבדוק את ההתנהגות של שרתי web אמתיים: Lighttpd,‏ Nginx ו־Apache2. מה שגיליתי היה ממש לא נעים: למעט Nginx אף שרת לא מדווח על ניתוק הקשר לא מעל FastCGI ולא מעל SCGI.

לצורך דוגמה פשוטה, אני יצרתי חיבור ומיד סגרתי אותו, כך עשיתי עשר פעם.

Nginx הוא היחיד דיווח על כך ליישום FastCGI באופן מידי ואפשר לי לטפל בלקוח ש"נעלם"
Apache דיווח רק אחרי timeout ארוך של כדקה הן ב־FastCGI והן ב־SCGI.‏
lighttpd בכלל שכח מזה והחזיק קשרים פתוחים כל הזמן – יותר מזה בירידה, הוא התלונן על כך שהיישום שלי "נעלם" ולא ענה לבקשת השרת (שאין לו כבר למי להעביר אותה).

בקיצור… זה היה מאוד מאכזב. אני הייתי מוכן לקבל את זה מ־Apache שידוע כשרת שלא נועד לטפל בהרבה קשרים פתוחים, אבל Lighty? פתחתי על זה באג.

מזל שמימשתי שרת HTTP פנימי בעצמי.

המשך...

חדשות CppCMS...

לאחרונה אני עובד בענף ה־refactoring של CppCMS ומבצע שינויים גדולים. אביא כאן סקירה קצרה של השינוי שכבר נמצאות בגרסה ניסיונית:

אחד השינויים הגדולים והחשובים זה להיפתר מכל התלויות המיותרות או מגבילות. אחרי שכל השינויים יסתיימו, התלויות היחידות שיישארו הן גרסה עדכנית של Boost ו־Python לצורכי הפיתוח בלבד.

חלק מהספריות הוסרו בגלל אי תאימות לדרישות החדשות:
- libfcgi ירד כי ה־API שלו לא מאפשר גישה א־סינכרונית, במקומו, מימשתי את הפרוטוקול בעצמי על בסיס Boost.Asio.
- ספריית CgiCC ירדה בגלל האיכות הירודה שלה וחוסר יכולת סבירה לתקשר עם המפתח של אותה הספרייה הבעייתית.
כך שבגרסה הבאה, תהיה לי אפשרות להכין debים ו־rpmים בקלות…
עד היום, פיתוח מול CppCMS דרש שימוש בשרת חיצוני, למרות שיש לי סקריפט הפעלה אוטומטית של lighttpd, ‏nginx ו־Apache, עכשיו מימשתי שרתי HTTP פנימי פשוט שמקל על הפיתוח ובנוסף, עתיד יקל על שיבוץ התשתית ביישומים שדורשים ממשק web ובמערכות משובצות מחשב.

כך שכיום, CppCMS החדש תומך בשלושה ממשקים FastCGI,‏ SCGI ו־HTTP.‏
התווספה תמיכה מסודרת בלוקליזציה עם שימוש ב־std::locale, כך שתצוגת התאריכים, מספרים, מחרוזות וכד' יתבצעו בהתאם למקובל באותה שפה.
בגלל שימוש מקיף ב־Boost – ספריה בלתי תלויה בפלטפורמה, אני סוף־סוף אוכל להכריז על Windows כפלטפורמה שנתמכת באופן (חצי) רשמי.

יש עוד הרבה עבודת אינטגרציה של רכיבים שיצאו באופן זמני, כמו ניהול sessions, שינויים ב־cache, שכתוב תמיכה בטפסים ועוד.

אבל לאט־לאט ההשפעה של השינויים הארכיטקטוניים מתחילים להתבהר.

המשך...

לתמוך או לא לתמוך, זאת השאלה (ב־Win32)?

כפי שפרסמתי בעבר, אני עובד על שינויים בפנימיים עמוקים ב־CppCMS שבין השאר יאפשרו:

תמיכה באירועי צד השרת או Comet.
תמיכה בבינאום ולורקליזציה.
תמיכה ב־ABI לאחור.
ניקיון יסודי של קוד תוך הקטנה משמעותית בשימוש בספריות צד ג'.

בגלל שאני עושה שינויים כל־כך מהותיים, חשבתי, אולי להוסיף גם תמיכה בעוד פלטפורמה בנוסף לתמיכה ב־Linux,‏ FreeBSD,‏ Solaris ו־Cygwin… להוסיף תמיכה ב־Windows.

זה באמת, לא אמור להיות עד כדי כך מסובך, יצא לי כבר פעם לבנות CppCMS עבור Mingw (כמובן נאלצתי לוותר על חלק גדול מהמודולים).

אבל, בין לבנות משהו שרץ עד לפלטפורמת פיתוח אמתית יש תהום.

המשך...

דברים שלא נאמרים על Boost.

או ליתר דיוק, לא מודגשים לגביו.

http://boost.org היא אחת הספריות הפופולריות ביותר ב־C++‎, היא מהווה ל־C++‎ מה ש־JDK מהווה ל־Java, מה ש־RTL ו־‏FCL מהווים ל־FreePascal, היא מה ש־Python Standard Library מהווה ל־Python.

היא, למעשה, הספרייה שנותנת את הכלים העשירים הנדרשים לעבודה, מעבר לגרעין הקטן של השפה. בפרט:

תמיכה ב־Threads.
עבודה עם socketים.
כלי עיבוד טקסט.
ביטויים רגולריים.
עבודה עם זיכרון משותף.
ועוד.

היום, היא בהחלט מהווה דה־פקטו סטנדרט בתחום C++‎, כך שחלקים גדולים ממנה כבר נכנסו ל־STL הבא של C++‎.

יחס עם זו. יש לה חיסרון אחד עצום שבמקרים רבים לא מורגש ע"י מפתחי יישומים, אבל כן מורגש ע"י מפתחי ספריות ו־toolkitים שונים. החיסרון הוא העדר תאימות כלשהי של ABI לאחור והעדר תאימות מלאה של API לאחור.

המשך...

האם אתה מוכן לבינאום ולוקליזציה?

הכנתי שאלון קצת שמאפשר לכם לבדוק… האם אתם מוכנים לכתיבת תכנה שתהיה מוכנה להתאמה לתרבויות שונות?

אני רוצה לייצג מחרוזת, כ־char *some_text. מהו המידע שחסר לי?
יש לי מחרוזת wchar_t *text או String text ב־Java, אני רוצה לקחת את התו הראשון שלה:
```
 wchar_t c=text[0]; // C
 Char c=text.charAt(0); // Java
```
האם זהו קוד נכון?

אני כותב את הקוד הבא:

 if n==1:
     print translate("You have one aplle")
 else:
     print translate("You have %d apples") % n

מה לא בסדר בקוד הזה?

מה לא בסדר בקוד הבא:

 #include <stdio.h>
 #include <time.h>

int main()
{
        time_t now_t=time(NULL);
        struct tm *now=localtime(&now_t);
        char str_time[32];
        strftime(str_time,sizeof(str_time),"%d/%m/%y",now);
        printf("Today is %s\n",str_time);
        return 0;
}

מהו גודל הזכרון הנדרש לשמירת תו unicode בודד?
מהו גודל של wchar_t? (למתכנתי C++/C)‏?
מהי גודל של תו unicode בשפת התכנות שאתה אוהב?
מהו קידוד של מחרוזת (unicode) בשפת התכנות/toolkit שאתה אוהב?
מה הבדל בין utf-8,‏ utf-16, ‏utf-32?‏
מהו אורך התו הארוך ביותר ב־utf8?‏

בניתי ספרייה עם שתי פונקציות בלבד. מה לא בסדר בקוד הבא (שתי בעיות לפחות)?

extern Char32 to_upper_char(Char32);
void to_upper(String str)
{
        for(int i=0;i<str.size();i++)
                str[i]=to_upper(str[i]);
}

מה לא בסדר בקוד הבא:

def print_error_message(message):
    print translate("Error occured: ")+"“"+translate(message)+"”"

מה לא בסדר בקוד הזה:

<?php $rtl_langs=array("he","ar","pa"); ?>
...
<div <?php if(in_array($lang,$rtl_langs) echo 'dir="rtl"'; ?> >
...
</div>

אני רוצה לחתוך את הטקסט בצורה יפה, כך שזה לא ייחתך באמצע המילה: מה לא בסדר בקוד הבא:

// Cut nice pice of text
wstring cut_nicely(wstring const &orig,int n)
{
   if(orig.size()<=n) return orig;
   return orig.substr(orig.find_first_of(L" \r\n\t\f",n));
}

המשך...

יותר מחשבים יותר ביצועים?

כשבניתי CppCMS תמיד לקחתי בחשבון ששרת יחיד לא תמיד יוכל להבטיח ביצועים מספיק טובים של שירות web עמוס. לכן, תמיד בתכנון המערכת, לקחתי בחשבון את האפשרויות של scale up.

בהחלט, הרבה יותר קל לתכנן מערכת שרצה על מחשב בודד עם זכרון משותף עם cache נגיש בצורה יעילה ועוד. אבל, במציאות זה לא יכול להיות. מערכות שמסוגלות לעמוד בעומסים גובהים הן בסופו של דבר חייבות להיות מוכנות לפעול בצורה מבוזרת.

לאחרונה הצלחתי להשיג גישה זמנית לרשת מחשבים חזקים במיוחד: Intel עם 4 ליבות שרצים ב־2.4GHz ו־4GB של זכרון. כך יכולתי לבדוק את מנגנון ה־cache המבוזר בעובד מעל TCP/IP ולהבין כמה אני מפסיק כתוצאה מביזור:

#   Local  Distributed
1   5,500   5,500
2  11,500   9,500
3  15,200  13,500

הטבלה מציגה את מספר הדפים בשניה שהמערכת wiki שבניתי מסוגלת לספק תחת הנחה של פגיעה 100% ב־cache (בגלל אילוצי הגישה לא יכולתי לשנות את הפרמטר). מספר השרתים הוא בין 1 ל־3 ומנגנוני ה־cache הם: cache המקומי הלא־מסונכון ו־cache המבוזר המסונכרן באופן מלא.

אפשר לראות, מחשב בודד מסוגל לייצר כ5 וחצי אלפי עמודים בשניה והמספר הזה הולך וגדל בצורה קרובה ללינארית עם שימוש ב־cache מקומי (כצפוי). שימוש ב־cache המבוזר מעל TCP/IP מקטין את מהירות הכוללת של המערכת אך עדיין שיפור ביצועים נשאר קרוב ללינארי.

יש לציין שהצלחתי למלא כמחצית מרוחב הפס של רשת 1GBit.

כמובן הניסוי הוא די מלאכותי, אבל הוא נועד בעיקר לבדוק עד כמה מנגון ה־cache המבוזר הוא יעיל. אני לא מביא לכאן פרטים מדויקים של ניסוי מפני שהוא היה יותר ניסוי פנימי, אבל בסה"כ הוא נותן הבנה של סדרי הגודל של מה שהמערכת מסוגלת לספק.

המשך...

שדרוג ל־Lenny

הגיע זמן לשדרג ל־Lenny, אומנם הוא הגיע כבר לפני הרבה זמן אבל Lenny עוד לא הגיע ;). אקדים ואומר, זה היה אחד השדרוגים הפשוטים ביותר שיצא לי לעשות אי פעם.

כששדרגתי Breezy ל־Dapper השדרוג נתקע באמצע ומצאתי מערכת לא שמישה, בלי חיבור לאינטרנט, אם כי בסוף הצלחתי להחלץ מזה.
כששדרגתי Sarge ל־Etch בגלל התנגשויות חצי מהחבילות הוסרו כולל Office ו־Gnome והייתי צריך להחזירם באופן ידני, שלא לדבר על כמה פעולות אחרות שהיה צריך לעשות.
שדרוג ל־Lenny היה לפי הכתוב… פשוט לשדרג.

קודם כל עברתי על הוראות שדרוג. מי שחושב ש־apt-get dist-upgrade ועושה את העבודה טועה!

תהליך שאפשר לסכם אותו בקצרה בשני שלבים:

שדרוג aptitude לחדש.
ביצוע aptitude dist-upgrade.

אם לא תלכו כך לא תצליחו, חייבים קודם את ה־aptitude החדש.

בנוסף לבעיות הרגילות בשדרוג, היו לי עוד כמה נקודות לציון:

היה לי רק 1G פנוי במחיצת / שלא הקל על התהליך
אני משתמש גרסת vserver של הקרנל, כך שעבורו אין דרייבר nvidia כחבילה.

נתחיל בסיפור

המשך...

לא רק GCC, או הניסיון הקצר עם קומפיילר של Intel.

בד"כ אני לא נוהג לכתוב כאן הרבה על טכנולוגיות סגורות, במיוחד לכתוב דברים טובים. אבל הפעם יהיה קצת שונה. אעשה סקירה קצרה של קומפיילר של אינטל.

רקע

אף אחד לא אוהב Vendor Lock In אפילו עם מדובר במשהו טוב כמו GCC או Linux. לכן, אני מוודא כי CppCMS ירוץ גם על BSD וגם על Solaris. אבל עם קומפיילר היו לי קצת יותר בעיות. יש מעט מאוד קומפיילרים טובים והנפוץ בין כולם הוא כמובן GCC.

הרבה זמן היו לי תהיות לגבי זה, אפילו ניסיתי להתקין SUN Studio על OpenSolaris ב־Virtual Box, אבל… בינתיים Solaris לא מתנהג יפה אפילו עם GCC.

אז בסופו של דבר אחרי הרבה ייסורים והתקלויות החלטתי לעשות בדיקה ל־icc. התהליך היה מייגע, אבל בסופו של דבר קיבלתי כמה דברים ממש נחמדים שאספר עליהם כאן.

המשך...

גם לחלשים מגיע... או CppCMS במערכות משובצות מחשב.

בעיות ביצועים של מערכות web יכולות להופיע לא רק עקב עומסים כבדים אלא גם בגלל מערכות מוגבלות. פה שפות מקומפלות כמו C/C++/Pascal‎ יכולות לתת מענה מצוין. אבל כרגיל חסרים כלים: Klone זה לא הרבה יותר ממשהו דמוי PHP ברק C.‏‏ Wt הוא בנוי כמו GUI.‏ Pascal? מישהו בכלל זוכר שפה כזו ;).

לכן CppCMS יתמוך גם בצרכים של מערכות משובצות מחשב והן:

צמצום תלויות למינימום.
עבודה מהירה.
גודל קובץ ריצה מינימלי.

לכן, לקחתי CppCMS ועשיתי לו ניתוח — זרקתי את כל מנגנוני ה־cache, ביטלתי דחיסת zlib ובכל צמצמתי תלות ב־boost::iostreams, העפתי מודי עבודה מיותרים ב־embedded.

בנוסף, אם המפתח רוצה לבנות גרסת cgi אז בכלל, העפתי את כל הקוד שמטפל ב־thread-pool וכמובן גם בפרוטוקולים כמו scgi/fcgi. ובכן, התכנה הצטמצמה לגודל של 500Kb בלבד. שזה כ־10%–20% מגודל משערך PHP אופייני.

ובכך שוחררה גרסת CppCMS 0.0.4 שכוללת תמיכה במערכות משובצות מחשב.

המשך...