Как распределить собственные сценарии жемчуга без пользовательского модуля наверху?
При использовании буферов непосредственной памяти JVM не выполняет GC для Вас, даже если Вы испытываете нехватку непосредственной памяти.
, Если Вы звоните ByteBuffer.allocateDirect() и Вы получаете OutOfMemoryError, можно найти, что этот вызов прекрасен после инициирования GC вручную.
6 ответов
Правильный способ - сказать им: «Не делайте этого!» Я надеюсь, что они не ожидают, что они переместят exe-файл и программа продолжит работать. Это ничем не отличается.
Тем не менее, есть несколько альтернатив. Один из них - замена сценария оберткой (например, pl2bat), которая знает полный путь к настоящему сценарию. Другой вариант - использовать PAR , но для этого потребуется установить PAR и / или parl (из PAR :: Packer).
Если скрипту, который вы подготовили для клиента, нужны «специальные» модули, просто упакуйте ваши модули, как если бы вы пытались загрузить их в cpan. Затем передайте пакет клиенту, и он сможет использовать утилиту cpan для установки скрипта и модулей.
Распространите установщик вместе со сценарием. Установщик должен быть запущен с правами root, и он поместит пользовательские модули в стандартное системное расположение (/ usr / local / lib / perl5 / site_perl или что-то еще).
Я не пробовал, но Module :: Install выглядит полезным в этом отношении. Он описывается как:
Автономный расширяемый установщик модуля Perl
В качестве варианта «поместите все модули в одно место и сделайте так, чтобы ваши приложения знали об этом», который будет работать даже на нескольких компьютерах и сетях, возможно, вам стоит проверить PAR :: Репозиторий и соответственно PAR :: Репозиторий :: Клиент . Вы просто предоставите один исполняемый двоичный клиентский файл, который подключается к репозиторию (через файловую систему или https) и запускает любое из произвольного количества программ (с использованием произвольного набора модулей), предоставляемых репозиторием, который запрашивает пользователь.
. Если пользователей много, это также дает преимущество для обслуживания: просто обновите программное обеспечение, предоставленное репозиторием, и пользователи начнут использовать обновленный код для своей системы при следующем запуске программ.
Было бы здорово, если бы вы могли просто использовать пакет приложения в стиле NeXTSTEP. Поскольку вы, вероятно, не разрабатываете платформу, которая использует пакеты, вам придется обойтись.
Поместите все файлы поддержки в известное место и укажите своим исполняемым файлом на эти файлы для доступа к настройкам и библиотекам. Проще всего сделать это с помощью простого установщика.
Например, с приложением под названием foo поместите все необходимые файлы в / opt / xlyd_apps / foo , библиотеки в / opt / xlyd_apps / foo / lib , конфигурация в / opt / xlyd_apps / foo / etc и так далее. Поместите исполняемый файл в / opt / xlyd_apps / foo / bin .
На самом деле я придумал собственное решение, и мне любопытно, какой прием он вызовет.
Я написал сценарий, который читает сценарий Perl и ищет операторы "использовать / требовать". Найдя их, он проверяет, является ли модуль частью стандартной библиотеки (просматривает путь к модулю для /perl5/\d+.\d+[\d.pting+/), а затем переписывает строку use / require двумя разными способами в зависимости от использование.
Если требуется :
{
... inline the entire module here...
}
Если , используется :
BEGIN {
... inline the entire module here...
}
Если , использование имеет импорт , сразу после этого введите:
BEGIN { import Module ...imports seen... }
Я понимаю, что не работает с модулями, использующими XS, но меня это устраивало. В основном мне нужно поддерживать только чистые модули Perl.