מחלקת "תכנות נורמלי במערכות 'ימות'..."

[nigun]

@yossiz
אני לא יודע איך זה עובד בנוד
אבל בגו כנראה שזה אותו דבר כי אפשר לעשות לולאה שתמשיך רק אם היא מקבלת את הערך לערוץ
אבל השאלה שלי איך אתה מכניס ערכים חדשים לתהליך שרץ מהקריאה הקודמת?
בא נשים לרגע בצד את הHTTP
במקרה שיש לך אפליקציה שאתה מעביר לה ארגומנטים משורת הפקודה
ואתה מפעיל coroutine שלא ממשיך עד שהוא מקבל את הערך yield
אם תפעיל שוב את האפליקציה משורת הפקודה עם הערך yield האם התהליך הראשון ימשיך או שהוא מחכה לו בערוץ שלו הוא לא יגמר לעולם

[yossiz]

@nigun הכל רץ בתוך תהליך אחד

נדבר על גו (למרות שאני לא מכיר)
על כל callid חדש אתה מריץ את הפונקציה (coroutine, שבמקרה של GO הוא גם goroutine).
בתוך הפונקציה אתה דוחף לתוך ערוץ את המחרוזת שאתה רוצה להחזיר לימות, ואז אתה מחכה לקבל חזרה את הבקשה הבאה של ימות.
בפונקציה הראשית, על כל בקשה מהשרת אתה מחלץ מתוכו את מזהה השיחה ודוחף את הפרמטרים לתוך הערוץ המתאים לפי מזהה השיחה, זה יגרום לפונקציה הנכונה להמשיך הרצתה.
פשוט מאוד, או שאני מפספס משהו?

[yossiz]

מצו"ב דגמה פשוטה, זה אמור לעבוד (פחות או יותר).
יש המון המון מה לשפר פה, אבל אפשר לקבל את הכיוון.
חילקתי את זה ל-2 קבצים:
yemot-api-handler.js (קוד המחלקה, ניתן לשימוש חוזר)

var activeCalls = {};

module.exports = class YemotAPIHandler {
    
    constructor(callHandler) {
        this.callHandler = callHandler;
    }
    
    async handle(req, res) {
        
        var callId = req.query.ApiCallId;
        //console.log(req.query);
        var currentCall = activeCalls[callId];
        if (currentCall) {
            var returnedValue = currentCall.getRetValue(req.query);
        } else {
            console.log(this);
            currentCall = activeCalls[callId] = new yemotCall(req.query, this.callHandler);
            returnedValue = null;
        }
        var reply = await currentCall.controller.next(returnedValue);
        console.log(reply);
        return res.send(reply.value);
    }
}

class yemotCall {
    constructor(query, callHandler) {
        this.ApiCallId = query.ApiCallId;
        this.ApiPhone = query.ApiPhone;
        this.controller = callHandler(this);
    };

    read(data, replyVar) {
        this.expect = replyVar;
        return `read=${data}=${replyVar}`;
    }
    
    goToFolder(folder) {
        return `go_to_folder=${folder}`;
    }
    
    getRetValue(query) {
        if (this.expect && query[this.expect])
        return query[this.expect];
        this.expect = null;
    }
}

simple-yemot-sample.js

const express = require('express');
const app = express();
const port = 3000;
const hangupExtension = "";

const YemotAPIHandler = require("./yemot-api-handler.js");

async function* callHandler(call) {
    var input = yield call.read(`t-שלום, אתה מתקשר ממספר ${call.ApiPhone}, הקש מספר כלשהו כעת ולאחריה סולמית`, "abc");
    yield `id_list_message=t-הקשתם ${input}.`;
    return call.goToFolder(hangupExtension);
}

var apiHandler = new YemotAPIHandler(callHandler);
app.get('*', apiHandler.handle.bind(apiHandler));

app.listen(port, ()=>console.log("YemotAPIHandler started!"));

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

[WWW]

@yossiz אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

איזה מחרוזת שולחים כדי לסיים את השיחה בימות?

@nigun אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

@yossiz
שולחים את המשתמש לשלוחת ניתוק
(לא ידוע לי על דרך אחרת)

אני חושב שאפשר ככה:

print "go_to_folder=hangup";

[dovid]

@yossiz זה ממש רעיון גאוני ההלבשה של הyield. לדעתי מתכנני התחביר לא התכוונו לזה...
למימוש הזה יש לזה חיסרון במקרה שייפול השרת (זה הערה לשמה, כלומר זה אחרי הכל נפלא אבל אני מחפש ב"דוקא" למה לא לעשות את הטריק הזה). אולי יותר נורמלי לצפות מ@MusiCode לכתוב בצורה לא פונקציונלית והכל יבוא על מקומו בשלום?
הרצון לכתוב לפעמים בצורה פשוטה ודקלרטיבית במקום קודים מסובכים גורמים לנו לסחוט מהשפה תחבירים :).

[yossiz]

@dovid אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

לדעתי מתכנני התחביר לא התכוונו לזה...

כנראה בגלל זה אתה קורא לזה רעיון גאוני... אני סבור שיש לייחס את הגאונות לארכיטקטורי השפה, שלדעתי כן התכוונו לזה... (על אף שרוב הדיבורים והשימוש ב-generators הוא בקטע של iterators)

למימוש הזה יש לזה חיסרון במקרה שייפול השרת

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

טוב, אני צריך לחשוב...

עריכה: הבנתי איפה הבעיה...

[dovid]

@yossiz זה לא המצאה חדשה, זה ישן מאוד (אני מכיר את זה בC# שנים, אם כי בJS יש מימושים הרבה יותר טריקיים ומעניינים. דוקא המקרה הזה קל לביצוע גם בC# והגאונות שלו היא בך ולא בתחביר).
הבעיה היא לא טיפול בשגיאות, הבעיה היא שכל השמירה של השיחות היא במשתנה שיימחק אם הנוד יקרוס. לא שזה בעיה קשה של ממש, הייתי גאה מאוד להציג פתרון כמו שלך אבל הוא עדיין טריקי לטעמי.

[yossiz]

אה, אני רואה שלא בצדק קראתי לזה coroutine. כי יש הבדל בין generator ל-coroutine.
https://en.wikipedia.org/wiki/Coroutine#Comparison_with_generators

[dovid]

@yossiz גם coroutin אם הבנתי מה זה אומר, לא נבנה בכלל לתועלת מקרה דומה למה שהיה לנו פה.
הcoroutin אם הבנתי בא לפשט עבודה של קלאבקים כמו פרומייס, כלומר מה יקרה אחרי שזה יגמור? שורה הבאה.
אבל פה זה לא אחרי שזה יגמור. זה כשיום אחד יבוא מישהו ויגיד "טוב בא נמשיך, איפה אחזנו?" ולזה לא עשו שום תחביר, מבטיח לך...

[MusiCode]

@dovid אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

@yossiz זה לא המצאה חדשה, זה ישן מאוד (אני מכיר את זה בC# שנים, אם כי בJS יש מימושים הרבה יותר טריקיים ומעניינים. דוקא המקרה הזה קל לביצוע גם בC# והגאונות שלו היא בך ולא בתחביר).
הבעיה היא לא טיפול בשגיאות, הבעיה היא שכל השמירה של השיחות היא במשתנה שיימחק אם הנוד יקרוס. לא שזה בעיה קשה של ממש, הייתי גאה מאוד להציג פתרון כמו שלך אבל הוא עדיין טריקי לטעמי.

לא ממש בעיה.
כי משתני השיחה הם מטבעם זמניים.
את המשתנים הקבועים מאחסנים בדטה-בייס.
מה קורה אם שרת אסטריסק נופל?
אותו דבר.

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

[dovid]

@MusiCode זה לא ג'אוה אלא ג'אוה סקריפט, ובשתי השפות יש GC שעובד טוב בד"כ כך שזה לא אמור להיות בעיה.

[MusiCode]

@yossiz אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

generator הוא בדיוק החלום שלך, זה פונקציה שמפסיקה את עצמה באמצע ומחזירה ערך, ואח"כ אפשר להמשיך אותה בדיוק מהמקום שבו היא עצרה.

וואו!
אם זה מצליח לי, אני אחפש 20 הודעות שלך לעשות לייק...
(אלא אם תגיד שזה מעצבן אותך...)

@yossiz אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

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

מצויין!
אני אנסה לתקן, להוסיף כדי שזה באמת יהיה שימושי.
זה יכול לחסוך אלפי שעות של מתכנתי מערכות כ @חוקר @אני @שואף (שכבר נטש לטובת אסטריסק) ועוד...

היתרון פה לעומת אסטריסק, זה שפה המשאבים להחזקת השיחות, הוא על חשבון 'ימות'...
(עיינו כאן למי שמחובר).

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

[nigun]

@yossiz אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

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

גם אני חשבתי כך בהתחלה אבל לא הצלחתי ליישם את זה במעשי
אשמח מאוד אם תעלה לכאן קוד בנוד שמרים שרת HTTP ובסופו של דבר יש דף שכל פעם שנכנסים אליו הוא עובר לשלב הבא (בלי ווב-סוקט כמובן) או יותר פשוט בפעם הראשונה שנכנסים לדך זה מפעיל לולאה אינסופית ובפעם השניה זה מפסיק אותה

[nigun]

הנה משהו שניסיתי לבנות בזמנו ולא הצלחתי
אבל מאוד הגיוני שזה בגלל שאני לא יודע באמת איך זה עובד
אז קודם כל זה קוד מריץ לולאה עד שמתקבל הערך לערוץ כשיש קריאה לlocalhost:8000/run
אני הוספתי שישלח את הערך proc.Tomb.Kill(fmt.Errorf("Death from above"))
אחרי כמה שניות
ואז הלולאה מפסיקה

package main
import (
"fmt"
"net/http"
"log"
"time"
"gopkg.in/tomb.v2"
"github.com/julienschmidt/httprouter"
)
type Proc struct {
  Tomb tomb.Tomb
}
 func main() {

    router := httprouter.New()

    router.GET("/run", run)

    log.Fatal(http.ListenAndServe(":8080", router))
}

func run(w http.ResponseWriter, r *http.Request, ps httprouter.Params) {
proc := &Proc{}

go proc.Exec()
    time.Sleep(1000 * time.Millisecond)

  proc.Tomb.Kill(fmt.Errorf("Death from above"))

}

func (proc *Proc) Exec() {

  for {
    select {
    case <-proc.Tomb.Dying():
      return
    default:
      time.Sleep(300 * time.Millisecond)
       currentTime := time.Now().Unix()
    fmt.Println("Current Unix Time:", currentTime)
    }
  }
}

אבל כשניסיתי לשלוח את proc.Tomb.Kill(fmt.Errorf("Death from above"))
בקריאה נפרדת זה לא מפסיק את הלולאה

package main
import (
"fmt"
"net/http"
"log"
"time"
"gopkg.in/tomb.v2"
"github.com/julienschmidt/httprouter"
)
type Proc struct {
  Tomb tomb.Tomb
}
 func main() {

    router := httprouter.New()

    router.GET("/run", run)
     router.GET("/kill", kill)

    log.Fatal(http.ListenAndServe(":8080", router))
}

func run(w http.ResponseWriter, r *http.Request, ps httprouter.Params) {
proc := &Proc{}

go proc.Exec()
}
func kill(w http.ResponseWriter, r *http.Request, ps httprouter.Params) {
proc := &Proc{}
  proc.Tomb.Kill(fmt.Errorf("Death from above"))
}

func (proc *Proc) Exec() {

  for {
    select {
    case <-proc.Tomb.Dying():
      return
    default:
      time.Sleep(300 * time.Millisecond)
       currentTime := time.Now().Unix()
    fmt.Println("Current Unix Time:", currentTime)
    }
  }
}

יכול להיות שזה בגלל שאני יוצר את הערך Proc מחדש
בזמנו ניסיתי כל מיני דרכים אחרות וזה לא עבד
על המבנה של tomb אפשר לראות כאן

[nigun]

אכן זה היה הבעיה
עכשיו יצרתי את הערך בפונקציה הראשית וזה עובד מצויין

package main
import (
    "fmt"
"gopkg.in/tomb.v2"
"github.com/julienschmidt/httprouter"
    "net/http"
    "log"
    "time"
)
type Proc struct {
  Tomb tomb.Tomb
}

       func main() {
                    proc := &Proc{}

    router := httprouter.New()
   
    router.GET("/run", run(proc))
    router.GET("/kill", kill(proc))

    log.Fatal(http.ListenAndServe(":8080", router))
}

func run(proc *Proc) httprouter.Handle {
	return func(w http.ResponseWriter, r *http.Request, ps httprouter.Params) {
   go proc.Exec()

  
   	}
}
func kill(proc *Proc) httprouter.Handle {
	return func(w http.ResponseWriter, r *http.Request, ps httprouter.Params) {
 

  proc.Tomb.Kill(fmt.Errorf("Death from above"))
   	}
}

 
func (proc *Proc) Exec() {
  for {
    select {
    case <-proc.Tomb.Dying():
      return
    default:
      time.Sleep(300 * time.Millisecond)
      currentTime := time.Now().Unix()
    fmt.Println("Current Unix Time:", currentTime)
    }
  }
}

[שואף]

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

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

לאחרונה, פיתחתי שלוחה מיוחדת בניהול של הקו (כל לקוח מקבל שלוחת ניהול), שנקראת עריכת הקלטות. זה פשוט נכנס לסקריפט, ששולף לבד כל הטקסטים בעברית, ומשמיע אותם אחד אחד, ומבקש להקליט. תוך עשר דקות הלקוח מקליט כל התפריטים וההודעות. אם הוא רוצה איזה שינוי או משהו הוא נכנס מתי שהוא רוצה ומשנה, ואם אני מוסיף תפריט, אני רק אומר לו שייכנס לשלוחה ויקליט מה שחסר.
ואז, כשנכנסים למערכת, והסקריפט מגיע לדוגמא לתפריט, הוא קודם בודק בתיקייה של הפרויקט אם יש קובץ בשם "ברוך הבא למערכת", אם כן הוא משמיע את זה, ואם לא, הוא מעביר לTTS.

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

[WWW]

@שואף אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

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

לדעתי הקלושה, אתה צודק.

[MusiCode]

@WWW אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

@שואף אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

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

לדעתי הקלושה, אתה צודק.

האמת שכולכם צודקים.

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

ואחרי שראיתי איך עובד הAGI, אמרתי, חייבת להיות דרך ליישם את זה גם בימות.
והנה, היא קיימת!

[שואף]

@MusiCode אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

זיהוי דיבור חינם

??

[MusiCode]

@שואף ללקוחות שחפצים ביקרם... (לא אני).