מאמרים בנושא ‏תכנה ומחשבים‏.

התקנת תמיכה ב־LaTeX בעברית בהפצה מודרנית

ב־יום שני, 11 באוקטובר 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, תכנה ומחשבים, LaTeX ועברית; ‏0 תגובות

אחת הבעיות להתחיל לעבוד עם LaTeX בעברית זה להתקין את התמיכה בו. לכן, רשמתי רשימת הערות להתקנה של תמיכה בעברית בהצפה מודרנית.

שימו לב, תתקינו בבקשה הפצת texlive ולא tetex, ההפצות המודרניות כמו Debian ו־Ubuntu באות כבר עם texlive.

שלבים בקצרה:

  1. הסירו ivritex אם מותקן
  2. התקינו texlive אם לא מותקן
  3. התקינו culmus-latex-0.7
  4. התקינו biditex

בפירוט

  1. אם חבילת ivritex מותקנת במחשב שלכם, הסירו אותה ותמחקו ספרית ‎.texmf בספריית הבית שלכם (שימו לב ל־"." שבתחילת שם הספריה).

  2. התקינו LaTeX אם הוא לא מותקן, וודאי כי אתם משתמשים בחבילת texlive. בגדול tetex גם עובד אבל צפו בעיות.

    וודאו כי יש לכם פקודות mktexlsr ו־updmap-sys (ניתן לבדוק אם פקודת which). אם לא התקינו את החבילות המתאימות.

  3. הורידו את הגרסה האחרונה של culmus-latex (נכון לעכשיו 0.7) מפרויקט ivritex. להורדה כאן.

    שימו לב, אתם לא צריכים חבילת src אלא culmus-latex-XX.tar.gz שמכילה את את הגופנים המוכנים מראש. פרוס אותה והרץ

    make install
    

    בתור root או בעזרת sudo.

  4. בדוק ש־LaTeX בעברית עובד ע"י הרצה קומפילציה של דוגמה בחבילת culmus-latex, בתיקיית examples בצורה הבאה:

    latex culmus-ex.tex
    dvips culmus-ex.dvi
    ps2pdf culmus-ex.ps
    

    ובדיקת קובץ pdf שנוצר (בדקו שרואים עברית), כמו כן כדאי לבדוק כי pdflatex עובד ע"י הרצת

    pdflatex culmus-ex.tex
    

BiDiTeX 0.0.9 - כש־ABI נשבר

ב־יום ראשון, 10 באוקטובר 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, פיתוח, תכנה ומחשבים, LaTeX ועברית; ‏4 תגובות

שוחררה גרסת biditex החדש 0.0.9.

שינויים:

  • התאמה לגרסה ‎0.19.x של FriBiDi
  • תמיכה בנוסחאות המוגדרות ע"י \[ ו־\].

הסיבה: ספריית fribidi שברה את ה־ABI ואת ה־API שלה בלי לעדכן נכון את הגרסה ותיעוד, מה שגרם לי לא מעט כאב ראש ויצירת גרסת BiDiTeX חדשה.

שימו לב, אם biditex נשבר בצורה לא ברורה או לא מתפקד בצורה מוזרה, תורידו בבקשה חבילה עדכנית, או תקמפלו אותו מחדש מול גרסת fribidi עדכנית ‎0.19.x, הגרסאות שקומפלו עם fribidi הישן לא יעבדו לכם.

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

להורדה כרגיל, באותו מקום: http://sourceforge.net/projects/biditex/files/

יצירת מספרים אקראיים עם ‎/dev/urandom וכמה קל ליפול בפח

ב־יום חמישי, 16 בספטמבר 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, פיתוח, תכנה ומחשבים; ‏7 תגובות

רובינו מכירים את ‎/dev/urandom הנפלא שמאפשר לייצר מספרים אקראיים בטוחים מבחינה קריפטוגרפית במהירות רבה.

למשל, אנחנו רוצים ליצור session-id חדש, מה קל יותר? פונים ל־‎/dev/urandom ומקבלים בשפע.

אבל כשבפועל השתמשתי בו ליצירת session-ids בגודל של 16 בתים, גיליתי... הוא מאוד אטי... הצלחתי לייצר משהו כמו 1,100 כאלה בשנייה, לא הרבה. התחלתי להתחכם, יצרתי מספר אחד להתחלה, הוספתי לו כמה שדות כמו זמן, מספר, לקחתי לו איזה md5 ואז זה עבד יפה וגם מהר (למרות שהמספרים האלה לא באים באותה איכות כמו שיכולתי לקבל אותם מ־‎/dev/urandom.

יום אחד בהיר הסתכלתי בקוד של Boost.UUID וראיתי שבקוד שלו, במקום להשתמש בפונקציות סטנדרטיות ופשוטות כמו std::ifstream או fopen פותחים את הקובץ ישירות עם open של מערכת ההפעלה וקוראים אותו עם read. מוזר, עשיתי בדיקה קצרה ו... זה קיבלתי 110,000 מפתחות של 16 בתים בשנייה במקום 1,100 - הבדל של שני סדרי גודל!

מה קורה פה?

אחרי מחקר קצר גיליתי ש:

FILE *f=fopen("/dev/urandom","r");
setbuf(f,0);
char buf[16];
fread(buf,1,16,f);
fclose(f);

עובד מהר מאוד, אבל אם מוחקים את השורה השנייה setbuf(f,0)‎ מגלים שהוא הופך לאטי להחריד.

הסבר: ביטל של buffer פנימי בעזרת setbuf()‎, גורם לכך, שכל פניה לקריאה מהקובץ מתבצעת בדיוק במספר הבתים שביקשנו. אבל, כאשר buffer מוגדל, הספרייה הסטנדרטית מבצעת תחכום ומנסה לקרוא כמה שיותר (למעשה 4K) ובפועל במקום לקרוא מ־‎/dev/urandom ‏ 16 בתים, היא קוראת 4096...

מוסר השכל: אם אתה פותח ‎/dev/urandom תמיד וודא שאתה לא משתמש ב־buffering בספריה שלך!

שוחררה גרסה מקדימה של Boost.Locale 3.

ב־יום שישי, 10 בספטמבר 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, פיתוח, תכנה ומחשבים, C++‎‏, Unicode, Boost‏; ‏0 תגובות

שלום,

שוחררה גרסה מקדימה של 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

אמת המרה על רמת התמיכה בלוקליזציה

ב־יום ראשון, 5 בספטמבר 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, C++‎‏, Unicode, Boost‏; ‏0 תגובות

כפי שחלק מקוראי הבלוג אולי יודעים, אני עובד על ספריית 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 שעובד בצורה סבירה (אם כי ממש לא מושלמת).

העמוד הבא

העמוד הבא

דפים

נושאים