API pentru a obtine informatii de cadru de stiva de la generator

Sambata 15 iunie 19:57:26 PDT 2013

• Mesaj anterior: API pentru a obtine informatii despre cadrul stivei de la generator
• Urmatorul mesaj: API pentru a obtine informatii despre cadrul stivei de la generator
• Mesaje sortate dupa: [data] [fir] [subiect] [autor]

Sambata, 15 iunie 2013 la 18:56, Mark S. Miller <erights at google.com> a scris:> Sambata, 15 iunie 2013 la 10:17 AM, David Bruant <bruant.d la gmail.com > a scris: > >> Le 15/06/2013 11:18, Bruno Jouhier a ecrit: >> >> Un obiect generator reprezinta un calcul care a fost suspendat. >>> Avem un API pentru a relua acest calcul (next / throw). Ceea ce lipseste este un >>> API pentru a obtine informatii despre acest calcul suspendat (ce functie, >>> unde se afla in sursa). >>> >> Deoparte, retineti ca avem deja acest tip de problema astazi cu >> se transforma bucla evenimentului. >> >>program de functii () { >> if (Math.random () <0,5) >> arunca o noua eroare („orice”); >> else >> setTimeout (calendar, Math.random () * 100); >> } >> >> setTimeout (programare, (Math.random () * 100) | 0) >> setTimeout (programare, (Math.random () * 100) | 0) >> >> Nu exista nici o modalitate de a stiti cate planificari s-au intamplat inainte de prima >> eroare aruncata si nici daca eroarea provine din prima sau a doua >> planificare initial. Si acesta este un exemplu fals de 5 linii. Se inrautateste >>>> apelat in momente diferite, adaugand alti ascultatori etc. >> Q rezolva asta cu urmele lungi ale stivei [1] (cred doar pentru promisiuni). >> S-ar putea sa merite sa ne uitam la el. >> >> >> Inapoi la problema dvs., imi fac griji ca acest tip de informatii (un apel pentru a >> obtine urmele stivei de unde a cedat ultima data generatorul cu numarul de linie) >> pot rupe partial incapsularea ceea ce nu ar fi bun pentru Securitate. >> Ma gandesc la ceva de genul: >> >> (exporturi => { >> var someCrucialInfo = // boolean >> >>if (someCrucialInfo) { >> doX (); >> randament 27; >> } >> else { >> doY (); >> randament 27; >> } >> } >> }) (aceasta); >> >> var v = this.bla (); >> var l = getLastBlaYieldLine (bla); >> // data fiind l, se poate deduce valoarea incapsulata a someCrucialInfo >> >> cc’ing MarkM pentru a-l privi, deoarece nu ma simt calificat sa evaluez >> gravitatea. >> > >Va multumim ca mi-ati atras atentia asupra acestui fir. Generatoare si multiple > intoarceri deoparte (a se vedea mai jos), am trecut peste problema de securitate inainte, dar o > recapitulare este utila. Informatiile de urmarire a stivei nu pot fi accesibile publicului > din obiectul Error, deoarece incalca incapsularea. (Nota istorica: > Cand E a intrat in prima sa revizuire de securitate, avea aceasta vulnerabilitate. Multumim > lui David Wagner pentru ca a prins-o.) In schimb, este necesar un fel de drepturi > amplificare. O interfata posibila este o functie privilegiata, > cum ar fi functia getStack la < >https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#221>, > in cazul in care > > getStack (ERR) returneaza traseu de executare . Daca nu aveti functia getStack > , nu puteti obtine stacktrace. getStack este implementat folosind un > WeakMap care asociaza erorile cu stacktraces. > > O alta abordare, in cazul in care < > http://wiki.

ecmascript.org/doku.php?id=strawman:relationships> sunt > adoptate in ES7, este de a avea o relatie care asociaza eroare obiecte cu > stacktraces. Relatia completa de citire / scriere ar fi interna >punerea in aplicare, ci o relatie care reprezinta o fateta a acestei numai citire > relatie, sa zicem @stacktrace, ar putea fi puse la dispozitie in acelasi > mod privilegiat ca getStack de mai sus. Apoi , > > err la va returna traseu de executare , aceeasi care getStack traseu de executare (err) ar > intoarcere mai sus. > > In cazul in care relatiile nu se intampla in ES7 (e prea tarziu pentru ES6) si private > simboluri fac, atunci @stacktrace ar putea fi un simbol privat. > > > > Randul sau multiple distribuite de depanare este intr – adevar , urmatoarea frontiera, si unul > care va deveni tot mai presanta ca promisiuni continua sa se prinda.> am participat la un proiect interesant, Causeway, care a explorat o parte din acest > teritoriu bine > http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html > https://code.google. com / p / Causeway / > > Desi proiectul a fost abandonat , deoarece, formatul sau urma jurnal este un > loc bun pentru a incepe, pentru a fi in masura sa sustina asa ceva in > viitor: > http: // wiki. erights.org/wiki/Causeway_Platform_Developer > http://wiki.erights.org/wiki/Causeway_Platform_Developer:_Ajax > http://wiki.erights.org/wiki/Causeway_Platform_Developer:_Promises > > >https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js > ofera, de asemenea, un anumit suport pentru formatul jurnalului Causeway. Vezi getCWStack. > > Vezi de asemenea > http://crpit.com/confpapers/CRPITV135Murray.pdf si > http://infoscience.epfl.ch/record/181543/files/EPFL_TH5533.pdf > pentru alte abordari interesante pentru depanare extinse > > > In ceea ce priveste generatoarele in mod specific, mi se pare ca, indiferent de drepturi > operatia de amplificare aplicata unui obiect de eroare pentru a obtine o stiva > urmarire, ar trebui sa se poata aplica si unei instante a generatorului pentru a obtine o >Urmarire stiva de 1 nivel care arata unde este suspendata in prezent. > Desi aceste stive generatoare de 1 nivel nu fac parte dintr-o stiva sincrona mai mare, ele fac parte din graficul general de cauzalitate pe care Causeway incearca sa il urmareasca. Ar fi interesant sa ne gandim unde ar merge acestea intr-un jurnal Causeway sau daca formatul jurnal Causeway ar trebui extins pentru a se potrivi cu acest lucru. > > > >> oh … si avem codul sursa de functii implicit cu >> Functia # toString. >> Acest tip de inferenta se poate intampla si in urmele obisnuite ale stivei de erori, dar >> necesita aruncarea unei functii care se intampla numai daca ar trebui, >> nu dupa voia apelantului. >>Desi imi dau seama acum ca oricine detine o referinta la un generator poate >> forta aruncarea unei erori si, daca nu este prinsa, genereaza o urma de stiva >> scurgand numarul liniei chiar si fara API-ul pe care il solicitati (dar ca >> ar functiona o singura data) >> >> >> Vad acest lucru ca fiind asemanator cu solicitarea unei proprietati portabile de „stiva” in >>> obiecte de eroare. Nu stiu daca este de fapt mandatat de ES6 dar se pare >>> ca toate motoarele majore JS il suporta acum. >>> >> Cred ca starea TC39 pe eroarea # stiva poate fi gasita la >>http://wiki.ecmascript.org/**doku.php?id=strawman:error_**stack <http://wiki.ecmascript.org/doku.php?id=strawman:error_stack> >> >> David >> >> [1] https://github.com/kriskowal/**q#long-stack-traces <https://github.com/kriskowal/q#long-stack-traces> >> > > > > – > Noroc, > –MarkM > – Noroc, –MarkM ————– partea urmatoare ————– Un HTML atasamentul a fost curatat … URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130615/136bb758/attachment-0001.html>

• Mesaj anterior: API pentru a obtine informatii despre cadrul stivei de la generator
• Urmatorul mesaj: API pentru a obtine informatii despre cadrul stivei de la generator
• Mesaje sortate dupa: [data] [fir] [subiect] [autor]

Mai multe informatii despre lista de discutii es-discuss