Автоматично перекомпілювати та перезавантажувати шаблони дієт у фоновому режимі в режимі розробки · Випуск

Коментарі

Копіювати посилання Цитувати відповідь

s-Людвіг прокоментував 1 червня 2014 р

Під час розробки засіб перегляду файлової системи міг використовуватись для моніторингу змін файлів у шаблонах дієт, що складають додаток. Кожен шаблон дієти, замість того, щоб статично компілюватися в програмі, потім компілюється як окрема спільна бібліотека/DLL і динамічно завантажується та вивантажується за потреби.

Текст успішно оновлено, але виявлені такі помилки:

etcimon прокоментував 1 червня 2014 р

Можливо, можна створити окрему бібліотеку для компіляції шаблонів дієт у формат .d та генерування дублірувальної інформації, так що проект vibe.d може посилатися на них як на залежність?

s-Людвіг прокоментував 1 червня 2014 р

Це, безумовно, було б можливим (просто в основному writeToFile ("somefile.d", dietStringParser! (.));), Але це не вирішило б цієї конкретної проблеми, оскільки в цьому випадку програму все одно потрібно було б перезавантажити та перезапустити.

s-Людвіг прокоментував 1 червня 2014 р

Якщо ви не маєте на увазі використовувати DUB просто як інструмент для побудови динамічної бібліотеки. У цьому випадку обговорена підтримка однофайлових пакетів стане в нагоді.

etcimon прокоментував 1 червня 2014 р

О, я розумію, куди ти потрапляєш. Мій підхід полягав у тому, щоб зробити перезапуск сервера менш шкідливим, але перезавантаження шаблонів дієт як спільного об’єкта під час виконання могло б зробити добре. У моєму поточному дизайні менеджера конфігурацій мені також цікаво, чи можна перезапустити сервер, не закриваючи процеси (для відновлення маршрутів та прослуховувачів).

МартінНовак прокоментував 4 червня 2014 р

Я спробую над цим попрацювати, оскільки це хороша вітрина для спільних бібліотек.
Що означає під час розробки та який процес контролюватиме файлову систему, дубль?
Інша проблема полягає в тому, що рендер використовує шаблони, тому трохи складно пересилати аргументи через покажчик на функцію.

s-Людвіг прокоментував 5 червня 2014 р

Це, безумовно, було б чудово, я насправді неодноразово чув цю аргументацію, що D було погано через збільшення часу обороту, і що люди воліли б залишатися при своїй динамічній інтерпретованій мові.

"Під час розробки", я б сказав, це мало означати якийсь перемикач, який, можливо, використовує -version =. Використання -debug = мало б ту перевагу, що його можна було б вказати безпосередньо в командному рядку DUB, але це, звичайно, було б не дуже чисто семантично.

Для моніторингу файлової системи watchDirectory * можна використовувати безпосередньо з самого процесу vibe.d. Побудова окремих шаблонів може бути виконана за допомогою DUB шляхом генерації фіктивного пакета за допомогою проекту vibe.d як залежності для отримання всіх налаштувань збірки.

Що стосується проблеми шаблону, навіть якщо це трохи змінює семантику, я думаю, що використання параметра Variant [] для пересилання аргументів, подібне до того, що робилося для renderCompat, як правило, повинно бути нормальним.

* Наразі це реалізовано лише для драйвера win32, але я міг би витратити трохи часу, щоб це також запустити у вільному драйвері.

zhaopuming прокоментував 29 червня 2014 р

Отже, цей механізм дуже схожий на механізм repl Мартіна:-) Сподіваємось, одного разу ми також можемо мати dub repl так само, як lein repl у Clojure.

А для більш загального випадку, чи можемо ми змусити цей механізм працювати для інших частин програми, щоб, коли кожна частина модифікується, вона була гаряче скомпільована та перезавантажена.

Звичайно, перед цим нам потрібно визначити частину або функціональну одиницю. Як посилання, vert.x має концепцію `` вершини '', яка інкапсулює функціональний блок, і кожен з них спілкується між собою через шину подій, використовуючи повідомлення. Це дуже поводиться як модель актора Ерланга/Скали. Ми вже маємо всі інструменти для підтримки акторської моделі у віб, тому, як тільки ми зробимо це більш офіційним шаблоном, ми можемо зробити цю гарячу перекомпіляцію/перезавантаження на цих акторах/одиницях. Тоді дієтичний темп був би лише особливим випадком актора (який називається безпосередньо).

s-Людвіг прокоментував 29 червня 2014 р

Я просто боюся, що узагальнюючи це на звичайні модулі D, людям стає занадто легко наступати на ноги, наприклад, змінюючи макет даних певних типів. Java має набагато більше можливостей виявляти такі ситуації завдяки детальному відображенню часу роботи, але програма D може або просто вийти з ладу, або вивести неправильний результат.

zhaopuming прокоментував 30 червня 2014 р

Ви маєте на увазі макет даних для повідомлень? можливо нам потрібен інший блок замість модулів D, який є джерелом вихідного коду. Модуль vert.x схожий на плагін, і кожен модуль має свій власний проект, модулі спілкуються лише повідомленнями (JSON). Ігровий фреймворк має подібний підхід. Це системи виконання плагінів для гарячого перезавантаження.

s-Людвіг прокоментував 30 червня 2014 р

Проблема, про яку я думав, полягає в тому, що ви дозволяєте компоненту повторно використовувати свою стару пам'ять після його перезавантаження, що було б найбільш ефективним підходом, але було б схильним до помилок мовчання даних, коли, наприклад, макет структури змінився після перезавантажити. Якщо, з іншого боку, компонент повинен починати з чистого стану кожного разу, ця проблема зникає, і передача повідомлень повинна бути в основному нормальною *. Однак це означало б, що компоненти можуть не залежати від стану один одного, що відкриває багато можливостей для проблем на високому рівні.

Можливо, гібридний підхід, коли кожен компонент отримує можливість явно серіалізувати свій стан перед тим, як зайти, а потім отримує цю серіалізовану крапку даних під час запуску наступного разу, щоб відновити свій стан. Все ще залишає потенціал для тихо втраченого стану, але, принаймні, дає можливість зробити перезавантаження безперебійною.

До речі, є Cmsed by @rikkimax, який підтримує перезавантаження компонентів. Я не впевнений, що він використовує будь-яку форму передачі повідомлень або інший механізм виконання або просто дозволяє обмінюватися пам’яттю між компонентами.

Взагалі, я думаю, що в архітектурному плані було б найкращим рішенням зберегти цю функціональність в окремій структурі, або більш високого рівня, як Cmsed, або повністю загальної (такої, що сумісна з vibe.d, звичайно) - тому що вона повинна можливо відокремити його та уникнути повзучості функцій у самому vibe.d (вже існує багато функціональних можливостей, які було б краще на Фобосі, наприклад). З іншого боку, перезавантаження шаблону було б просто допоміжним засобом для розробки і насправді не було б частиною загальної архітектури.

* Якщо компонент A імпортує модуль із компонента B, який визначає структуру, а потім ця структура надсилається з компонента A у компонент B, все одно можна отримати несумісні макети даних, якщо A вирішить змінити макет структури після перезавантаження. Отже, щоб пом'якшити це, було б потрібно відстежувати залежності між компонентами та перезавантажувати всі уражені компоненти одночасно.

rikkimax прокоментував 30 червня 2014 р

Cmsed ще не підтримує перезавантаження шаблонів ext. під час виконання ще. Це головним чином із стану мого акторського фреймворку Dakka. Поки що він не в змозі викликати методи на інших вузлах. Але це не моя наступна мета, а інша. Поточні актори-одинаки, так жахливо, але чудово для класів контролерів.

Політика, яку я збирався використовувати, була досить простою:

  • Оновлення шаблону:
    • Код регенеровано
  • Після регенерації коду для зміни шаблонів або маршрутів
    • Перекомпілюйте відповідні шаблони
    • Зупинити попередні вузли
    • Запустіть нові вузли