@arieldaniely אולי תשתף פעולה עם @המשיב המפתח של http://hameshiv.com/ לצורך דאטה לאימון
H
חיים שנקר
@HAIM TEPRMAN
-
הסבר | איך להשתמש בחיפוש החכם - ובקשה -
באג | גרסה 0.9.98 - באגיםהצעת שיפור חשובה לקבוע כללים מתי יש תואר הרב מתי רבי ומתי בכלל בלי שזה שרירותי לגמרי כרגע
-
באג | גרסה 0.9.98 - באגיםבאג בעדכון גירסא לתוכנה בתוכנה ניידת מהקודמת לנוכחית הוא מציג את אפשרות ההורדה של העדכון ואת אפשרות ההתקנה אבל קורס בהתקנה
וככה הסוכן שלי מדווח על זה
כותרת: Windows portable: "התקנה" משגרת בטעות את crashpad_handler.exe במקום otzaria.exe — העדכון לא מוחל וכלום לא קורהסביבה: Windows x64, גרסה ניידת (zip) 0.9.97/0.9.98 — שחזרתי גם על 0.9.98+18 וגם על גרסה קודמת.
שלבים לשחזור:
הרצה של גרסה ניידת (zip) ב-Windows.
קליטת הודעת העדכון → "הורדה" (ההורדה והחילוץ מסתיימים בהצלחה).
לחיצה על "התקנה עכשיו".
צפוים: האפליקציה נסגרת ונפתחת בגרסה החדשה (או שהתיקייה הניידת מתעדכנת במקום).מתקבל: האפליקציה נסגרת, כלום לא נפתח, והתיקייה הניידת נשארת על הגרסה הישנה. שחזור: %TEMP%\otzaria_update\otzaria\ נשאר שלם (zip חילוץ + portable.marker).
גורם שורש:
// lib/update/my_update_widget.dart:1490
File _extractedWindowsExecutable(File zipFile) {
final outDir = Directory(p.join(p.dirname(zipFile.path), 'otzaria'));
final entry = outDir.listSync().firstWhere(
(e) => e.path.toLowerCase().endsWith('.exe'), // ← أول .exe שיחזור ה-OS
);
return File(entry.path);
}
listSync() מחזיר את סדר ה-OS (ב-NTFS: אלפביתי), ולכן ה-exe שנבחר הוא:crashpad_handler.exe ← נבחר (עוזר דיווח הקריסות, מסתיים מיד)
otzaria.exe
otzaria_updater.exe
zstd.exe
אימתתי על תיקיית חילוץ אמיתית מעדכון בפועל: סדר ההחזרה הוא crashpad_handler.exe ראשון. לכן launchWindowsDetachedProcess משגר את עוזר ה-crashpad, האפליקציה נסגרת — והמשתמש רואה "לא עשה כלום".בעיה משנית (אפילו עם exe הנכון): ההעתקה שהושגה פועלת מ-%TEMP% עם ה-portable.marker שלה → היא יוצרת otzaria_data ריק וחדש צמוד إليها, והתיקייה המקורית של המשתמש אף פעם לא מוחלפת. כלומר Windows portable אינו באמת מעדכן במקום — לעומתח את דף ה-release לעדכון ידני) ו-macOS (tree-swap).
בעיה משנית 2 — ה-differential update אינו פעיל כלל: הלקוח מחפש asset בשם otzaria-update-<platform>-<arch>-<from>-<to>.zip (update_package.dart:33), אך אף release לא מכיל asset כזה — לא ב-Upstream ולא בפּוֹרק (רק otzaria-app-files-*.json). ה-step Publish differential update packages מוגדר continue-on-error: true, ולכן כשל שלו שקט — מומלץ לבדוק את הלוג שלו; סביר שהוא יוצא דרך הסניף no differential update packages were produced. תוצאה: תמיד נופלים למסלול ה-zip המלא, שמגיע ישר לבאג שלמעלה.
תיקון מוצע:
בחירה דטרמיניסטית של ה-exe — לחפש מפורשות otzaria.exe (ולא firstWhere על סיומת .exe), או לסנן exe-י עזר מוכרים (crashpad_handler.exe, zstd.exe).
ל-Windows portable: מימוש עדכון במקום דרך otzaria_updater.exe שכבר ארוז בחבילה, או לחלופין לפתוח את דף ה-release כמו Linux portable.
לתקן/לאכוף את שלב פרסום חבילות ה-differential. -
באג | גרסה 0.9.98 - באגים@צדיק-וטוב-לו ועדיין לכאורה עדיף העברי על פני הלועזי וגם נראה לי יצוא פעם אחת של הרשימה ופתירתה לעברי האמיתי אפשרי ובספרים חדשים ניתן לבדיקה [בכל אופן יש בוט אוצריא]
-
באג | גרסה 0.9.98 - באגיםלא ממש באג אבל הצעת שיפור ששנת ההדפסה של הספר תהיה שנה עברית [ או מיספור אבל לבריאת העולם לא למניינם] להרבה ראשונים יש בזה איסור גמור
אני משער שהמקור הוא ספריא אבל בתהליך יצירת הDB לא כזה מורכב להכניס סקריפט המרה
-
בקשה | הפורום עודכן בשעטו"מ לגירסה האחרונה - דווחו על באגים@הנגבי ציור שמש שנאסר הוא כמו שמציירים שמש [בפוסקים דוקא צידדו להקל אם אין קרנים - למרות שברור שלשמש עצמה אין קרניים אלא הנושא כיצד רגילים לציירה -כך צורות הע"ז של עובדי השמש - הם לא ציירו מדויק אלא כפי המקובל בזמנם כנל לימינו]
-
בקשה | הפורום עודכן בשעטו"מ לגירסה האחרונה - דווחו על באגים@ע-ה-דכו-ע בנוגע לכפתור שמש וירח נראה לי עדיף פתרונות אחרים [מסך בהיר כהה חצי חצי למשל] זה נושא הלכתי לעשות צורת שמש וכו'
-
הצעת ייעול | ייעול האינדקס עבור PDF@י.-פל. כלומר הבוט הלך לישון?
עכ"פ אני כבר לא יודע אם יהיה לי מספיק זמן לפני אלול לפתוח PR
אבל הרעיון פשוט ביסודו [אפשר לשנות במנוע לכפל חיסכון, אבל בהנחה שלא]:הבקשה היחידה מהמנוע: להוסיף כאופציה שהוא יחזיר אופסט — מיספור המילה. [עדיף אופסט תווים — חסין לשינויי טוקניזציה — אבל גם מספר מילה מספיק.] הוא כבר יודע איפה ההתאמה יושבת — הוא מחשב את זה בשביל ההדגשה — רק לא מחזיר את זה החוצה. בלי שינוי סכמה, בלי בנייה מחדש של האינדקס.
ומה שזה מאפשר גם היום, בלי שום קובץ נוסף: לסמן את המילה במדויק מהתיבות המובנות של שכבת הטקסט — ולחסוך את השלב של החיפוש המקומי [ש-pdfrx סורק את כל הספר בכל חיפוש].
ובמקרה ויש קובץ תיבות — במקום ה-OCR או הטקסט — לוקחים משם את מיקום הסימון. זה הכל: מנגנון אחד [אופסט → תיבה], שלושה מקורות [קובץ תיבות ← שכבת טקסט ← pdfrx כגיבוי]. לספרים מבוססי טקסט אין שום קובץ נוסף במאגר; קובץ התיבות נחוץ רק אם מסירים את שכבת ה-OCR או שאין שכבת טקסט מלכתחילה.
-
הצעת ייעול | ייעול האינדקס עבור PDF@otzaria-bot על "חלון או מלא": זה חלון, לא מלא — המנוע חותך עד 800 תווים סביב ההתאמה. אבל מה שחשוב הוא שכשהוא עושה את זה, הטקסט המלא של העמוד כבר אצלו [הוא קורא את השדה המלא ורק אחר כך מריץ את מחולל ה-snippet]. כלומר להחזיר גם את טווח התווים זה כמעט בלי עלות — שדה נוסף בתוצאה, בלי שינוי סכמה, בלי בנייה מחדש.
על המיפוי לפי מספר תו — מקבל, ומדדתי את המחיר: קובץ התיבות עם מפתח אופסט תווים גדל ב-20% גולמי / 53% דחוס [3.68→4.42MB, 0.67→1.03MB]. קטן, ובתמורה חסינות מוחלטת לשינויי טוקניזציה. [אם גם האינדקס עצמו יעבור לאופסטי תווים במקום מספרי מילים זה +17-19% — אבל זה רלוונטי רק להצעה הגדולה.]
שתי הצעות נפרדות, עם קריטריונים שונים:
הצעה קטנה [מה שאנחנו מבקשים עכשיו]: המנוע נשאר כמו שהוא + שדה אחד נוסף [טווח תווים בעמוד] + קובץ תיבות צד [~1MB דחוס לספר] + אופציונלי: מחיקת שכבת ה-OCR [−38% מהקובץ, 28.1→17.5MB]. מקבלים: סימון ישיר בלי סריקה מקומית בכל חיפוש, וקובץ קטן יותר. האינדקס לא נוגעים בו בכלל.
הצעה גדולה [פרויקט נפרד]: גם החלפת האינדקס בעיצוב אופסטים [מילה → אופסטים, הטקסט המלא משוחזר מהאינדקס]. מוסיף חיסכון נוסף — אינדקס של ~2MB במקום הטקסט המלא השמור. אבל זה בנייה מחדש, והמנוע שלכם שומר את הטקסט בכוונה [בשביל ה-snippets] — אז זו החלטה נפרדת לגמרי.
ובונוס לטובת ההצעה הקטנה: מאחר שהטקסט שמור בתוך אינדקס tantivy — מחיקת שכבת ה-OCR לא מסכנת כלום. ה-snippets ממשיכים לעבוד מהאינדקס; הטקסט לא תלוי בקובץ.
אז שני ה-issues נשארים: אחד להצעה הקטנה [טווח תווים + קובץ תיבות] ואחד למחיקת שכבת ה-OCR [החלטת מדיניות — פעולה נפרדת ומדעת, עם טביעת אצבע וגרסת פורמט]. ההצעה הגדולה שווה דיון משלה.
@הבל-הבלים התוסף הוא למחיקת שכבת הOCR עבור המעוניינים ויצירת קובץ תיבות מקביל - אנחנו לא רוצים לכפות מחיקת שכבתOCR ממי שלא מעוניין הרעיון מתוכנן ככה שיעבוד בכל מקרה
-
הצעת ייעול | ייעול האינדקס עבור PDF@הבל-הבלים זה היה המטרה - אבל הבוט החליט להגיב אז הסברתי
-
הצעת ייעול | ייעול האינדקס עבור PDF@Otzaria-Bot אז יש פתח לפתח תוסף שיחסוך למשתמשי PDF המון מקום
-
הצעת ייעול | ייעול האינדקס עבור PDF@Otzaria-Bot ההפרש 28.1→17.5MB הוא כולו שכבת ה-OCR, לא פונטים ולא דחיסה חוזרת. ה-PDF הזה לא מטמיע פונטים בכלל [0 קבצי פונט, ה-OCR משתמש בפונטים לא-מוטמעים], והקובץ החדש שמר את כל שאר האובייקטים בית-לבית [כולל התמונות, בלי לדחוס מחדש]. ולמה 10.6MB ולא 6.55? כי ה-6.55MB זה רק הטקסט - המילים; השכבה שבקובץ שומרת את המיקום של כל אות [זה מה שמתפרק ל-72MB]. כלומר 38% זה באמת רק המחיקה של השכבה, ואפשר לשחזר אותה בכל רגע.
על ה-23%: ההערכה התבססה על הטקסט הגולמי בלי הקואורדינטות. שכבת ה-OCR שבתוך הקובץ שוקלת 10.6MB = 38% - יותר מהתיקון שלך, לא פחות.
על המנוע: צודק, וזה בדיוק המקום. אם המנוע יחזיר מיקום מילה בתוך העמוד [אופסט], התיבה נשלפת מקובץ הצד בלי שום מעבר נוסף על הקובץ. כל השאר כבר קיים אצלכם [fragments/charRects ב-pdfrx, pagePaintCallbacks במציג] - אז זה בעצם השינוי היחיד שחייבים לעשות.
-
הצעת ייעול | ייעול האינדקס עבור PDF@otzaria-bot חושב שיש פה אי הבנה קטנה של הרעיון - אני אנסה להסביר שוב [אני לא מומחה גדול בפורמטים, אבל יש לי כבר מימוש עובד של זה אז אני מדבר מניסיון, והמספרים כאן זה מה שמדדתי בפועל על מסכת בבא בתרא - 754 אלף מילים]
הנקודה המרכזית - התיבות לא חייבות להיות בתוך הקובץ
אפשר לשמור אותן בקובץ צד [sidecar] ליד הספר - בזמן האינדוקס מחלצים פעם אחת את הקואורדינטות ושומרים אותן שם, בלי הטקסט. את קובץ התיבות אפשר לדחוס בכמה שיטות, בדקתי שלוש:
קידוד דלתא [כל תיבה כהפרש מהתיבה שכנה לה + חלוקה ב-8] - יוצא 3.68MB לספר [בערך 5 בתים למילה]
דחיסה רגילה [gzip] על הרצף - יורד ל-0.61MB [בערך 0.8 בתים למילה]
ורעיון המילון - מילון של רכיבים [רוחבים, גבהים, עמודות]. מסתבר שמילון של מלבנים שלמים לא עובד [84% מהתיבות במיקום ייחודי], אבל רכיב-רכיב כן - בספר שלם יש רק 9 רוחבים שונים ו-5 גבהים! זה יוצא 1.81MB גולמי [2.5 בתים למילה] או 0.95MB דחוס
ולמה זה חשוב? כי ה-gzip נותן את הקובץ הכי קטן [0.61MB] אבל צריך לפרוק אותו כולו לפני שמחפשים בו, ואילו המילון נשאר קטן גם בלי לפרוק - אפשר לקפוץ ישר לתיבה של כל מילה [גישה אקראית: כל מילה ברוחב קבוע של ביטים]. וזה בדיוק מה שצריך כשקוראים ישירות מהדיסק, בלי לחכות לפריקה של קובץ שלםהסימון עובד מעל התמונה שמרונדרת - בלי לגעת בשכבת הטקסט של הקובץ בכלל [ככה שאחרי זה אפשר למחוק אותה לגמרי ונשארת סריקה רגילה, תקינה - מדדתי על ה-PDF: הקובץ מתכווץ מ-28.1MB ל-17.5MB, כלומר 38% פחות]
ואז במקום שכבת ה-OCR [שגדולה] נשארים האינדקס+תיבות [שקטנים] - עם המספרים האמיתיים: שכבת הטקסט הגולמית היא 6.55MB, ואצלי יוצא אינדקס אופסטים של 2.08MB + תיבות [3.68MB גולמי, או 0.61MB אם דוחסים, או 1.81MB עם רעיון המילון]. כלומר סה"כ 5.76MB גולמי, או 2.69MB עם תיבות דחוסות, או 3.89MB עם המילון. לעומת השיטה של אוצריא [אינדקס עמודים + הטקסט המלא = 7.56MB] זה חוסך 24% במצב הנוכחי, 64% עם תיבות דחוסות, ו-49% עם רעיון המילון. ואם מחברים לזה גם את המחיקה של שכבת ה-OCR מהקובץ [38%] - הקובץ הסופי [בלי OCR + אינדקס + תיבות] יוצא בערך 27-28% פחות מהמקורי. ובתמורה מקבלים חיפוש וסימון
ומהירות החיפוש - כאן גם יש לי פלוס ענק: אצלי זה 0.4 מיקרו-שנייה לחיפוש [אחרי שהספר נטען פעם אחת, וזה לוקח 40 אלפיות השנייה], לעומת חיפוש מקומי שסורק את הטקסט של כל עמוד - בערך 5 מיקרו-שניות לעמוד. כלומר מהיר פי אלף בערך, והם משלמים את זה בכל חיפוש מחדש
ולגבי "אין ממה לבנות מחדש" - לא הזכרתי את זה קודם: מהאינדקס אפשר לשחזר את הטקסט המלא בכל רגע, גם בלי הקובץ, כולל לבנות מחדש את שכבת ה-OCR אם צריך. בדקתי את זה: 10,671/10,671 מילים [100%] משוחזרות בדיוק כמו במקור, כולל התיבות [ברמת דיוק של ±7 יחידות בקנה המידה של הסריקה - בלתי נראה]. אז הטענה הזאת לא רלוונטית - להפך, האינדקס הקטן הוא זה שמחזיר את הכל
והצעה נוספת לטווח הרחוק יותר - לתמוך בפורמט DjVu - בדקתי במקור ושם אגב אפשר כן לשמור קובץ תיבות בקובץ עצמו אבל זה מקטין את החסכון. אם ממירים PDF ל-DjVu ומורידים את שכבת הטקסט, החיסכון הוא אותו הדבר אולי מעט יותר [בגלל שהדחיסה של DjVu לסריקות הרבה יותר טובה]. אבל זה יצריך שהתוכנה תתמוך ב-DjVu
-
הצעת ייעול | ייעול האינדקס עבור PDF@י.-פל. @pcinfogmach יש לי רעיון בר מימוש לחסכון בגודל הקבצים עבור משתמשי PDF
[אפשר לבנות אותו אולי כתוסף - אבל צריך שהתוכנה תתמוך ברעיון]
הרעיון מבוסס על כך שבשביל לסמן את התוצאות בPDF יש 3 רעיונות
1 לשמור באינדקס מיקומים מדויקים [קואורדינטות]-מה שמגדיל את האינדקס מאוד
2 לשמור רק את העמוד ולהריץ חיפוש מקומי שיסמן את הטקסט [אני מניח מחוסר ידיעה שבזה אוצריא משתמשת]
3 לשמור את האופסט [מספר המילה - מה שעושים בדרך כלל לאינדקס של טקסט - אולי באוצריא עושים גם לטקסט את שיטה 2 ]אני מציע שאם האינדקס יתמוך לPDF באפשרות 3 אז יהיה ניתן אחרי האינדוקס להריץ מחיקה של הOCR חלקית ולשמור רק את התיבות ללא הטקסט בתוכם - מה שישאיר את המיספור ויאפשר סימון אבל יחסוך הרבה מקום
-
בירור | פיתוח נסיוני | ש"ס עם טקסט חי מתוך המסד@pcinfogmach מרגש - האם התהליך היה ניתן למימוש עכשיו על כל ספר למשל חידושי הריטבא - או שדרושה התאמה לכל ספר בנפרד
-
הצעת ייעול | חנות תוספים@י.-פל. אולי הפתרון להצמיד גם את האיתור [ואולי אפילו את החיפוש] - ובכל מקרה לחשוב על שפה עיצובית קצת יותר אחידה
-
הצעת ייעול | חנות תוספים@יאיר-דניאל תנסה קודם גירסא ניידתוגם אפשר לדאוג במירכוז שיהיה גדול יותר וידמה יותר לחיפוש מאשר לאיתור - אבל תנסה ונראה לי תבין מה מציק לי
-
הצעת ייעול | חנות תוספיםכתבתי -כבר הוחלט - ואם כן עדיף מרכוז
-
הצעת ייעול | חנות תוספים@יאיר-דניאל נראה לי לא הבנת את כוונתי - אני כתבתי על העיצוב החדש- שכבר הוחלט- שהחלונית של הכלים קופצת בצד - ורק הצעתי שתדמה יותר לחיפוש ולאיתור כי זה בכל מקרה חלונית דומה למדי אז בתחושה זה קצת מוזר - ניסתי את הגירסא הזאת בנויה - וככה זה מרגיש