Recompilați și reîncărcați automat șabloanele de dietă în fundal în modul de dezvoltare · Problemă
Comentarii
Copiați linkul Citat răspuns
s-ludwig comentat 1 iunie 2014
În timpul dezvoltării, un sistem de urmărire a sistemului de fișiere ar putea fi utilizat pentru a monitoriza modificările fișierelor din șabloanele de dietă care alcătuiesc aplicația. Fiecare șablon de dietă, în loc să fie compilat static în aplicație, va fi apoi compilat ca o bibliotecă partajată separată/DLL și încărcat și descărcat dinamic, după cum este necesar.
Textul a fost actualizat cu succes, dar s-au întâlnit aceste erori:
etcimon comentat 1 iunie 2014
Ar putea fi posibil să aveți o bibliotecă separată pentru compilarea șabloanelor de dietă într-un format .d și generarea informațiilor de dub, astfel încât un proiect vibe.d să poată face referire la ele ca o dependență.?
s-ludwig comentat 1 iunie 2014
Acest lucru ar fi cu siguranță posibil (pur și simplu writeToFile („somefile.d”, dietStringParser! (.));), Dar nu ar rezolva această problemă specială, deoarece aplicația ar trebui totuși reluată și repornită în acest caz.
s-ludwig comentat 1 iunie 2014
Dacă nu vrei să folosești DUB doar ca instrument pentru construirea bibliotecii dinamice. În acest caz, suportul discutat pentru pachetele cu un singur fișier ar fi util.
etcimon comentat 1 iunie 2014
Văd unde ajungi. Abordarea mea a fost aceea de a face repornirea serverului mai puțin dăunătoare, dar reîncărcarea șabloanelor de dietă ca obiect partajat în timpul rulării ar putea face bine. În proiectarea mea actuală a unui manager de configurare, mă întreb dacă serverul ar putea fi repornit fără a închide procesele (pentru a reconstrui rute și ascultători).
MartinNowak comentat 4 iunie 2014
Voi încerca să lucrez la asta, deoarece este o vitrină bună pentru bibliotecile partajate.
Ce înseamnă în timpul dezvoltării și ce proces ar monitoriza sistemul de fișiere, dub?
Cealaltă problemă este că randarea folosește șabloane, deci este puțin dificil să transmiteți argumentele printr-un indicator de funcție.
s-ludwig comentat 5 iunie 2014
Cu siguranță ar fi minunat, de fapt am auzit acest argument de nenumărate ori, că D a fost rău din cauza acestei creșteri a timpului de răspuns și că oamenii ar prefera să rămână cu limbajul lor interpretat dinamic.
„În timpul dezvoltării”, aș spune, ar trebui să însemne doar un fel de switch opt-in, probabil folosind -version =. Utilizarea -debug = ar avea avantajul că ar putea fi specificată direct pe linia de comandă DUB, dar asta nu ar fi bineînțeles foarte curat semantic.
Pentru monitorizarea sistemului de fișiere, watchDirectory * ar putea fi utilizat direct din cadrul procesului vibe.d. Construirea șabloanelor individuale se poate face folosind DUB prin generarea unui pachet fals cu proiectul vibe.d ca dependență pentru a obține toate setările de construire.
În ceea ce privește problema șablonului, chiar dacă modifică ușor semantica, cred că utilizarea unui parametru Variant [] pentru a transmite argumentele, similar cu ceea ce se făcea pentru renderCompat, ar trebui să fie de obicei bine.
* În prezent, acest lucru este implementat doar pentru driverul win32, dar aș putea investi ceva timp pentru ca acesta să ruleze și în driverul libevent.
zhaopuming comentat 29 iunie 2014
Deci, acest mecanism este foarte asemănător cu mecanismul de replică al lui Martin:-) Sperăm că într-o zi vom putea avea dub repl la fel ca lein repl în Clojure.
Și pentru un caz mai general, putem face acest mecanism să funcționeze pentru alte părți ale aplicației, astfel încât, atunci când fiecare parte este modificată, va fi compilată la cald și reîncărcată.
Despre couse, înainte de aceasta trebuie să definim o parte sau o unitate funcțională. Ca referință, vert.x are un concept de „vârf” care încapsulează o unitate funcțională și fiecare comunică între ele printr-un Eventbus, utilizând mesaje. Acest lucru se comportă foarte mult ca modelul de actor al lui Erlang/Scala. Avem deja toate instrumentele pentru suportul modelului de actor în vibrație, așa că, odată ce îl transformăm într-un model mai oficial, putem face această recompilare/reîncărcare la cald pe acești actori/unități. Atunci dieta temlată ar fi doar un caz special al unui actor (care se numește direct).
s-ludwig comentat 29 iunie 2014
Ceea ce mi-e teamă este că generalizarea acestui lucru la modulele D obișnuite face prea ușor pentru oameni să pășească pe propriile picioare, de exemplu, schimbând aspectul datelor de anumite tipuri. Java are mult mai multe posibilități de a detecta astfel de situații datorită reflectării detaliate a timpului de rulare, dar o aplicație D fie ar fi doar blocată, fie ar produce o ieșire greșită.
zhaopuming comentat 30 iunie 2014
Vrei să spui aspectul datelor pentru mesaje? poate avem nevoie de o altă unitate în loc de module D, care este o unitate de cod sursă. Modulul vert.x este ca un plugin și fiecare modul are propriul proiect, modulele comunicând numai prin mesaje (JSON). Cadrul de joc are o abordare similară. Acestea sunt sisteme de plugin-uri de execuție pentru reîncărcare la cald.
s-ludwig comentat 30 iunie 2014
Problema la care mă gândeam este când permiteți unei componente să își refolosească vechea memorie după ce a fost reîncărcată, ceea ce ar fi cea mai eficientă abordare, dar ar fi predispus la erori de corupție a datelor silențioase atunci când, de exemplu, un aspect struct s-a schimbat reîncărcați. Dacă, pe de altă parte, componenta ar trebui să înceapă de fiecare dată cu o stare curată, problema respectivă ar dispărea și transmiterea mesajelor ar trebui să fie mai bine *. Cu toate acestea, acest lucru ar însemna că componentele nu pot depinde de starea reciprocă, ceea ce deschide o mulțime de potențial pentru probleme de nivel înalt.
Poate o abordare hibridă, în care fiecare componentă are șansa de a serializa în mod explicit starea sa înainte de a coborî și apoi obține acea blob serializat de date când pornește data viitoare pentru a-și restabili starea. Încă lasă potențialul unei stări pierdute în liniște, dar cel puțin permite posibilitatea de a face o reîncărcare fără probleme.
BTW, există Cmsed by @rikkimax, care acceptă reîncărcarea componentelor. Nu sunt sigur dacă folosește vreo formă de transmitere a mesajelor sau un alt machanism în timpul rulării sau pur și simplu permite partajarea memoriei între componente.
În general, cred că arhitectural ar fi cea mai bună soluție pentru a menține această funcționalitate într-un cadru separat, fie unul de nivel superior precum Cmsed, fie unul complet generic (unul care este compatibil cu vibe.d, desigur) - pentru că ar trebui să fie posibil să îl separați și să evitați fluirea caracteristicilor în vibe.d în sine (există deja o mulțime de funcționalități care ar fi mai bine în Phobos, de exemplu). Reîncărcarea șabloanelor, pe de altă parte, ar fi doar un ajutor pentru dezvoltare și nu ar face parte din arhitectura generală.
* Dacă componenta A importă un modul din componenta B care definește o struct și apoi această structură este trimisă de la componenta A la componenta B, este încă posibil să obțineți aspecte de date incompatibile dacă A decide să schimbe aspectul struct după o reîncărcare. Deci, pentru a atenua acest lucru, ar fi necesar să urmăriți dependențele dintre componente și să reîncărcați simultan toate componentele afectate.
rikkimax comentat 30 iunie 2014
Cmsed nu acceptă încă reîncărcarea șabloanelor ext. în timpul rulării încă. Acest lucru este în mare parte din starea cadrului meu de actori Dakka. Deocamdată nu poate apela metode pe alte noduri. Dar aceasta nu este următoarea mea țintă, ci cealaltă. Actualul este actori singleton, da îngrozitor, dar hey grozav pentru clasele de controlor.
Politicile pe care urma să le folosesc erau destul de simple:
- Actualizări șablon:
- Cod regenerat
- După codul regenerat pentru schimbarea șabloanelor sau rutelor
- Recompilați șabloanele corespunzătoare
- Opriți nodurile anterioare
- Porniți noi noduri