Pull to refresh

Comments 17

Милота. Не хватает разве что возвращения многомерных массивов SQL-запросами.
Хот релоад без костылей в коде:
https://github.com/tockins/realize

к примеру
Есть и другие.
С остальными подходами есть один нюанс: они все требуют перезапуска приложения. Мой подход работает без перезапуска
Я уважаю ваш труд. Но вы же не пишете без ошибок? Паники — ваши постоянные друзья будут. Т.е. просто вручную придется запускать опять )
Ну, строго говоря, panic в веб-обработчике будет просто отдаваться клиенту как 500 ошибка. Вам нужно посадить panic в отдельной горутине, чтобы приложение вышло. В большинстве случаев, в моей практике, паники все-таки происходят локализовано и не роняют приложение, даже во время разработки.

В свое время я так же создал живое обновление кода для Перла, в связи с чем открыл для себя erlang...

Не вижу кода, который выгружает предыдущую версию. Когда именно это происходит?

Предыдущую версию выгрузить в go нельзя

Блин — а я так надеялся, что можно сделать gouchdb :S
Ну т.е. много раз такое не сделать, иначе ресурсы закончатся в системе. Процесс придется перезагружать.

Да. Перезагружать процесс периодически все равно будет нужно, если вы захотите поменять значение константы, добавить новый тип и многое другое :).

Почему нельзя сделать парент процесс, который всего лишь рутер соединений и форкнутые процессы обработчики и форкать его каждый раз когда файлы меняются?


Парент процесс будет держать соединение и отправлять его в новый форк, Старый форк соединения принимать не будет и будет по мере заканчивания очереди отрубаться чисто сам. Примерно так и работает mod_php mod_python и иные (только там фактически форк на каждый запущенный скрипт).

Да можно, конечно, только весь смысл hot swap кода заключается в том, что полная перекомпиляция не требуется и соответственно время цикла сохранил-подождал_пока_скомпилится-проверил сокращается и благодаря этому ускоряется разработка и дебаг. Ваша же идея описывает "плавный рестарт" и нужна в продакшене, а во время разработки она ничего не ускоряет

Я писал подобный Вашему релоадер на Python. Основная проблема с которой я столкнулся это не загрузка нового, а выгрузка старого — по-крайней мере с JIT Python это не работает верно. Дело в том, что GC там удаляет "когда посчитает нужным". В итоге нужно обходить все локали и удалять их, но появляется другая проблема — закрытие соединений и файлов. И вот так раз за разом идет куча ликов.
Помимо этого проблема с форсированной загрузкой из файла, а не из прекомпилированного кода тоже появляется. Помимо этого reload(module) работает неконсистентно, то есть его вообще надо не использовать, а нельзя, иначе импорт эррор.


Я понимаю, что это Питоновские заморочки, но более стабильного метода я не вижу. С форком просто плавный переход от бывшей машины к новой.

Как-то стремновато будет выглядеть monkey patching в production коде?


Как-то использовал эту прекрасную либу, но только для того, чтобы делать stub'ы в структурах, при использовании которых хотел избежать интерфейсов.

В продакшен-коде такое использовать ни в коем случае нельзя

Люди, используйте go install вместо go build при разработке.


go install кэширует скомпилированные пакеты и сохраняет их в папке $GOPATH/pkg, то есть перекомпиляция будет происходить только при изменении отдельного пакета, а не всех, как это работает с go build.


Для веб-разработки, конечно, удобно использовать какой-то перезагрузчик, который следит за изменением файлов в проекте. Рекомендую использовать этот — https://github.com/cortesi/modd


Мой файл конфигурации modd:


**/*.twig.html {
    # gost это простой сервер для отдачи статических файлов: https://github.com/vwochnik/gost
    # можно использовать вместо него обычный python -m http.server
    daemon +sigterm: cd public && gost
}

**/*.go {
    # запускаем компиляцию приложения
    prep: go install ./cmd/webapp-main

    # запускаем приложение, полный путь к нему будет $GOBIN/webapp-main
    # где $GOBIN по-умолчанию $GOPATH/bin
    daemon +sigterm: webapp-main
}

Это не тоже самое, что написал автор поста, но при таком подходе не нужно описывать множество правил для патчинга функций.

Only those users with full accounts are able to leave comments. Log in, please.