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

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

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

nigun

@MusiCode
כמה שתשכלל את הAPI לא תקבל את האופציות שיש לך בחיבור ווב-סוקט
למשל השמעת הודעה/מוזיקה תוך כדי שפעולה מתבצעת
יש לי מערכת כזו כרגע שפעולות לוקחים 2-4 שניות ולפעמים אפילו 8 שניות
ואני שוקל לשכתב הכל לאסטריסק בגלל זה
@שואף
לא הבנתי למה הסקריפט באסטריסק יותר מהיר מאשר בימות?
אם אתה בודק בזמן אמת אז זה אמור להיות אותו דבר
ואם אתה בודק כשנכנס למערכת
עם המחלקה שMusiCode רוצה לבנות
זה אמור להיות פשוט יותר

MusiCode

@yossiz נתתי 20 לייקים...

זהו סיימתי משהו בסיסי.

הנה הדוגמא:

index.js

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

const YemotExtension = require('./yemot_api/YemotExtension.js');

/*
	http://localhost:3000/r?ApiCallId=9m8u98b97yb87t76t76rt&ApiPhone=0504123456&ApiDID=0773137770&ApiRealDID=0773137770&ApiExtension=1/1
*/

const $extension = new YemotExtension();

$extension.set_function( function * ($call) {
	
	let $data = [
		{type: "file", data: "000"},
		{type: "text", data: "זה טקסט"}
	];
	
	let $input = yield $call.read($data);

	$data = [
		{type: "number", data: $input}
	];

	yield $call.id_list_message($data);
	
});

app.get('/r', ($req, $res) => $extension.run($req, $res));

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

קבצי הליבה:

yemot_api/YemotApiFunctions.js

/*
	המודול הזה, מכיל את המודול הבסיסי עם הפונקציות לתקשר עם ימות
*/

const default_options = {

	//all
	val_name: undefined,

	//tapp
	re_enter_if_exists: false,
	max: '*',
	min: 1,
	sec_wait: 7,
	play_ok_mode: 'Number',
	block_asterisk: true,
	allow_zero: true,
	replace_char: '**',
	digits_allowed: undefined, // ['1', '14']
	amount_attempts: undefined, // 1
	read_none: false,
	read_none_var: undefined,

	//voice
	lang: 'he-IL',
	allow_tap: false,

	//rec
	record_folder_move: undefined,
	record_file_name: undefined,
	record_ok: true,
	record_hangup_save: false,
	record_attach: false
};

const default_options_keys = Object.keys(default_options);

const data_type = {

	'file':'f',
    'text':'t',
    'speech':'s',
	'digits':'d',
	'number':'n',
	'alpha':'a'
};

module.exports = class YemotApiFunctions {
    
    constructor() {

        this.value_num = 1;
    }

    read($data, $mode = 'tap', $options = {}) {

		$options = this._make_read_options($options);
        let $data_str = this._make_read_data($data);
		let $res;
		
		if(typeof $data != 'object') {
			throw new Error('Data is undefined');
		}

		switch($mode) {

			case 'tap':
				$res = this._make_tap_mode_result($data_str, $options);
				break;

			case 'voice':
				//...
				break;

			case 'rec':
				//...
				break;

			default:
				throw new Error('mode parameter is Invalid');
			
		}
		
        this.expect = $options.val_name;
        return $res;
    }

    goToFolder(folder) {
        return `go_to_folder=${folder}`;
    }

    id_list_message($data) {

        return 'id_list_message=' + this._make_read_data($data);
    }

    credit_card() {
        // ...
    }

    routing_yemot($phone) {
        return 'routing_yemot=' + $phone;
    }

    routing() {
        //...
	}

	// === === === === === === === === === === === === === ===
	
	_make_read_options($options) {

		default_options_keys.forEach((value) => {

			if(!$options[value]) {

				$options[value] = default_options[value];
			}
		});

		return $options;
	}

    _make_read_data($data) {

		let $res = '';

		let i = 1;

		$data.forEach((value) => {

			$res +=  i > 1? '.':'';

			$res += data_type[value.type] + '-';

			$res += value.data;

			i ++;
		})

		return $res;
	}
	
	_make_tap_mode_result ($data_str, $options) {

		let $res;

		$res = `read=${$data_str}=`;

		if(!$options.val_name) {

			$options.val_name = 'val_' + this.value_num;
			this.value_num ++;
		}

		$res += $options.val_name + ',';

		$res += $options.re_enter_if_exists?'yes,':'no,';

		$res += $options.max + ',';

		$res += $options.min + ',';

		$res += $options.sec_wait + ',';

		$res += $options.play_ok_mode + ',';

		$res += $options.block_asterisk?'yes,':'no,';

		$res += $options.allow_zero?'yes,':'no,';

		$res += $options.replace_char + ',';

		$res += $options.digits_allowed?$options.digits_allowed.join('.'):'' + ',';

		$res += $options.amount_attempts?$options.amount_attempts:'' + ',';

		$res += $options.read_none?$options.read_none:'' + ',';

		$res += $options.read_none?$options.read_none:'';

		return $res;

	}
}

yemot_api/YemotApiCall.js

const YemotApiFunctions = require('./YemotApiFunctions');

module.exports = class YemotApiCall extends YemotApiFunctions {

    constructor(callHandler) {
        super();
        this.controller = callHandler(this);
    }

    get_return_value() {
        if (this.expect && this.query[this.expect]) {
			
			let r = this.query[this.expect];
			this.expect = null;
			return r;
			
		} else {
			return null;
		}
        
    }
    
    set_user_vars($query) {

		if(!$query.ApiCallId || !$query.ApiPhone
			|| !$query.ApiDID ||  !$query.ApiRealDID
			|| !$query.ApiExtension) {
				
			throw new Error('Missing parameters');
		}

		this.ApiCallId = $query.ApiCallId;
		this.ApiPhone = $query.ApiPhone;
		this.ApiDID = $query.ApiDID;
		this.ApiRealDID = $query.ApiRealDID;
		this.ApiExtension = $query.ApiExtension;
		this.query = $query;

		if($query.ApiEnterID) {

			this.ApiEnterID = $query.EnterID;
		}

		if($query.ApiEnterIDName) {

			this.ApiEnterIDName = $query.EnterIDName;
		}

		if($query.hangup) {

			this.hangup = $query.hangup;
		}

	}

}

yemot_api/YemotExtension.js


const YemotApiCall = require('./YemotApiCall');

module.exports = class YemotExtension {
	
	constructor () {

		this.active_calls = {};
		
	}
	
	run ($req, $res) {

		let $call_id = $req.query.ApiCallId
		
		let $current_call = this._get_current_call($call_id);
		
		$current_call.set_user_vars($req.query);
		
		let $returned_key = $current_call.get_return_value();
		
		let reply = $current_call.controller.next($returned_key);

		if(reply.done || $req.query.Hangup) {

			this._remove_current_call($call_id);
		}
		
		return $res.send(reply.value);
	}
 
	set_function (controller_function) {
		
		this.controller_function = controller_function;
	}

	_get_current_call ($call_id) {
		
		let $current_call = this.active_calls[$call_id];
		
		if ($current_call) {
            return $current_call;
        } else {
            $current_call = this.active_calls[$call_id] = new YemotApiCall(this.controller_function);
			return $current_call;
        }
	}

	_remove_current_call($call_id) {

		delete this.active_calls[$call_id];
	}
}

yossiz

@MusiCode תודה רבה
עוד לא עברתי על הקוד, אבל מה זה כל הדולרים ? בהשפעת PHP?

MusiCode

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

yossiz

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

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

MusiCode

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

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

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

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

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

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

מי שינהל את זה, יהיה אירוע בכל פעם שהמשתמש נכנס.

הנה הקונץ:

await new Promise(function fn(resolve) {
	event.once(call_id, () => {
		resolve();
	});
});

הקוד נחסם עד לאירוע שמודיע: "המשתמש חזר!".

event.emit(call_id);

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

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

זה נורא? סביל? לא בעיה?

מדובר על (נכון לעכשיו) בין 20 ל 300 משתמשים.

פתקא טבא וחג שמח.

yossiz

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

כי בסוף אני מנסה כיוון אחר

מעניין, כי אני התחלתי בכיוון זה... כתבתי טיוטה של מחלקה שבנויה על promises ו-async/await, אח"כ חשבתי שזה נראה יותר מדי ספגטי (אולי כי לא השתמשתי ב-event אלא ישר קראתי resolve מתוך ה-handler של הבקשה מימות), לכן שיניתי כיוון ל-yield שהיה קוד יותר נקי (בעיני, אם כי זה קצת שטיקי).
מה היתרון בשבילך ב-promises?

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

השאלה מה לגבי זיכרון.

לפום ריהטא, למה שיהיה הבדל בין yield ל-promise בנוגע לזיכרון? לגבי שניהם לא נראה לי שזכרון אמור להיות בעיה.

MusiCode

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

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

כי בסוף אני מנסה כיוון אחר

מעניין, כי אני התחלתי בכיוון זה... כתבתי טיוטה של מחלקה שבנויה על promises ו-async/await, אח"כ חשבתי שזה נראה יותר מדי ספגטי (אולי כי לא השתמשתי ב-event אלא ישר קראתי resolve מתוך ה-handler של הבקשה מימות), לכן שיניתי כיוון ל-yield שהיה קוד יותר נקי (בעיני, אם כי זה קצת שטיקי).
מה היתרון בשבילך ב-promises?

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

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

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

y.get('/', async (call) => {
	let r = await call.run();
	console.log(call.call_id, r);
	call.res.send('הנה, גמרנו');
});

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

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

השאלה מה לגבי זיכרון.

לפום ריהטא, למה שיהיה הבדל בין yield ל-promise בנוגע לזיכרון? לגבי שניהם לא נראה לי שזכרון אמור להיות בעיה.

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

הרצתי 1,000 קריאות. זה תפס בערך 40 מ"ב זיכרון (לפי מנהל המשימות Win7, מקווה שאני קורא אותו נכון).

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

MusiCode

@yossiz הנה זה לבינתיים.
https://github.com/MusiCode1/yemot-router/
הרעיון שזה (ניסה) לרשת את ראוטר של אקספרס.

זה יצא עקום מאוד...
אבל זה עובד.

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

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

עריכה 2: זה לא עוזר...
לא פתר את הבעיה.

עריכה 3:

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

let myModule = function() {

	const router = express.Router();
	Object.setPrototypeOf(express.Router, myModule);

	router.function = function(params) {
		
	};
	return router;
};

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

כך אני חושב יש הרבה יותר שליטה, מאשר לריב עם this (ניסיתי לשכנע את this להתאתחל עם הפונקציה אקספרס.ראוטר.
יואו! איך שהוא נפגע...).

קצת הגיגים:

אני מתחיל להבין, למה לJS יש כ"כ הרבה מעריצים.

אני מתלהב מאוד מהרעיון של א-סינכרוניות, שרק עכשיו למדתי להכיר.
קח פונקציה, תריץ אותה, קח עוד אחת, תריץ אותה ו-
תחרות: מי שמגיעה ראשונה - מנצחת!

לא עוד הסרבול שבלעשות פקודות בזו אחר זו.

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

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

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

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

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

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

השאלה מה יקרה, אם פתאום אחד ידרוש עיבוד ארוך.
שם באמת השרת ייתקע...
לכן אולי קראתי, שJS לא מיועד לחישובים מסובכים).

yossiz

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

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

לא כל כך הבנתי מה אתה מתכוון. אולי דוגמה יעזור.

אגב, אני חייב לומר, האב טיפוס שלך, היה גאוני!

ישבתי לפרק ולנסות לשנות (סורי, הייתי חייב...), ואז הבנתי כמה כל דבר היה במקום!

תודה על המחמאה (למרות שאני לא בטוח שהוא במקום...)

אפ' שאפשר לקבל את התוצאה מהפונקציה ישירות...

לא הבנתי למה הכוונה

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

בעצם כל await הוא כזה. אפשר לעשות timeout (במימוש שלך שמבוסס על promises זה יותר קל. במימוש שלי אני לא יודע כרגע איך הייתי מוסיף timeout).

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

גם כאן לא כל כך הבנתי את השאלה, אולי דוגמה יעזור

MusiCode

@yossiz

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

function * generetor (call) {

	//...
	yield call.function();
	//...
	other(call);
	//...
}

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

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

שוב, אתה כבר יכול להוריד מגיט https://github.com/MusiCode1/yemot-router/
וגם מ npm, הנה: npm i yemot-router.

תחומים - פורום חרדי מקצועי

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

index.js

yemot_api/YemotApiFunctions.js

yemot_api/YemotApiCall.js

yemot_api/YemotExtension.js