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

[nigun]

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

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

print "go_to_folder=../";

ואז בממשק של ימות מגדירים את השלוחה שינתק?

כן

אגב, לא הבנתי מה בדיוק רצית לעשות בקוד ה-GO שהבאת למעלה, אבל מימוש של coroutine הוא אפילו יותר טבעי ב-GO מאשר ב-JS. לכאורה אפשר לעשות מחלקה שעושה את השימוש בימות ממש טבעי וזורם.

בקוד למעלה
ניסיתי לשאול האם אפשר להרוג תהליך שכבר רץ מקריאה קודמת
אז לצורך הדוגמה בניתי שרת HTTP שקריאה לlocalhost:8000/run מפעילה את הפונקציה run(foo)
(אין ל פונקציה כזאת כרגע זה כדי לתת הדגמה של הפעלת תהליך)
וכיון שזה קריאה א-סינכרונית אני לא צריך להישאר בדף כדי שפונקציה תמשיך לרוץ
אבל אם הפונקציה היא אינסופית או שרצה להרבה זמן
אני רוצה דרך לשלוט עליה עם קריאה נפרדת
למשל להרוג את התהליך אחרי שעה
אז רציתי שיהיה אופציה בסגנון של קריאה ל localhost:8000/kill
שמפעילה את הפונקציה kill(foo)
ובעברית "להרוג את תהליך foo"
אבל הבעיה היא שאי אפשר להשפיע על התהליך מהקריאה הקודמת ע"י קריאה בשם של התהליך (foo)
אמנם אם אני מקבל בשעת ההפעלה את הPID של התהליך אז אני יכול להרוג אותו ע"י קריאה לPID
(לכאורה אני יכול להחליט בהפעלה מה הPID כדי שאני אוכל לגשת אליו אחר כך
ואם לא אפשר לקבל אותו בהפעלה ולשמור אותו איפה שהוא
אבל כל זה נוגע להריגת התהליך אבל להמשיך הפעלה לאותו תהליך זה כבר משהו אחר

[MusiCode]

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

@MusiCode מה שאתה צריך הוא מימוש של coroutines.

משהו כזה:

var activeCalls = {};

function router(req, res) {
    var callId = getCallId(req);
    var currentCall = activeCalls[callId];
    if (currentCall) {
        var returnedValue = extractValue(req);
    } else {
        currentCall = activeCalls[callId] = Call();
        returnedValue = null;
    }
    var reply = currentCall.next(returnedValue);
    return res.send(reply.value);
}

function* Call() {
    yield playfile("file");
    var f = yield read("file", 1, 5, ...);
    yield goToFolder("/7/" + f);
    yield hangup();
}

אני לא מצרף מימוש של playfile, read, gotofolder, hangup כי אין לי מושג איך ה-API של ימות עובד. אבל כל אחד מפונקצייות אלו אמור להחזיר את המחרוזת שצריך להשיב למערכת ימות

אם זה אמיתי, זה מדהים!...
לא הבנתי, מה זה קורוטין?
אפשר הסבר?

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

[yossiz]

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

לא הבנתי, מה זה קורוטין?
אפשר הסבר?

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

ב-JS, עושים פונקציה כזאת עם התחביר: function*
העצירה והחזרת ערך מתבצעת על ידי מילת המפתח yield.
הרצת הפונקציה לא באמת מריצה אותה אלא מייצרת אובייקט מסוג generator. אפשר לקרוא generator.next כדי להריץ את השלב הבא של הפונקציה. generator.next מחזירה אובייקט בעלת 2 חברים {value: xxx, done: true/false}.

טוב, אידך פירושא זיל גמור...

אני מנסה להבין את הקוד, אבל כמו שאמרתי,

אני בנוד מלפני כמה ימים...

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

צריך איזו חבילה לזה?

לא
בעזה"י אעלה עוד מעט דוגמת hello world שעובד.

[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]

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

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

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