Модули

Управление пространством имен относится к возможностям языка, позволяющим сделать имена в модуле доступными в других модулях. Связанные концепции и функциональные возможности будут подробно рассматриваться далее.

Модули могут содержать подмодули, в которых вложен тот же синтаксис module ... end. Их можно использовать для введения отдельных пространств имен, что может быть полезно для организации сложных баз кода. Обратите внимание, что каждый module вводит собственную область, поэтому подмодули автоматически не наследуют имена от своего родительского модуля.

Рекомендуется, чтобы подмодули ссылались на другие модули внутри охватывающего родительского модуля (включая последний), используя относительные квалификаторы модуля в операторах using и import. Относительный квалификатор модуля начинается с точки (.), что соответствует текущему модулю, а каждый последующий символ . ведет на родительский модуль текущего модуля. За ним должны следовать модули, если необходимо, и в итоге — фактическое имя, к которому нужно получить доступ. Все элементы разделяются символом ..

Рассмотрим следующий пример, где подмодуль SubA определяет функцию, которая затем расширяется в своем одноуровневом модуле:

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

Однако это работает через загрузку кода и поэтому действует только в том случае, если модуль ParentModule находится в пакете. Рекомендуется использовать относительные пути.

Обратите внимание, что при вычислении значений также важен порядок определений. Рассмотрим

где модуль Sub пытается использовать переменную TestPackage.y до того, как она была определена, поэтому у него нет значения.

По аналогичным причинам невозможно использовать циклическое упорядочение.

Загрузка больших модулей может занимать несколько секунд, поскольку для выполнения всех операторов в модуле часто требуется скомпилировать значительный объем кода. Для сокращения этого времени Julia создает предварительно скомпилированные кеши модуля.

При загрузке модуля с помощью оператора import или using автоматически создаются и используются предварительно скомпилированные файлы модуля (иногда называемые «файлами кэша»). Если файлов кэша еще нет, модуль будет скомпилирован и сохранен для повторного использования в будущем. Чтобы создать эти файлы, не загружая модуль, можно также вызвать Base.compilecache(Base.identify_package("modulename")) вручную. Результирующие файлы кэша будут сохранены во вложенной папке compiled в папке DEPOT_PATH[1]. Если в вашей системе ничего не изменилось, эти файлы кэша будут использоваться при загрузке модуля с помощью оператора import или using.

В предварительно скомпилированных файлах хранятся определения модулей, типов, методов и констант. В них также могут храниться специализации методов и созданный для них код, но обычно для этого разработчик должен явно добавить директивы precompile или выполнить рабочие нагрузки, вызывающие принудительную компиляцию во время сборки пакета.

Однако если вы обновите зависимости модуля или измените его исходный код, модуль будет автоматически перекомпилирован при использовании оператора using или import. Зависимостями являются импортируемые модули, сборка Julia, включаемые файлы или явные зависимости, объявленные с помощью функции include_dependency(path) в файлах модуля.

Для зависимостей файла изменение определяется путем анализа того, является ли время модификации (mtime) каждого файла, загруженного с помощью include или явно добавленного с помощью include_dependency, неизменным или равным времени модификации, усеченному до ближайшей секунды (для систем, которые не могут копировать mtime с точностью в долях секунды). Также учитывается, совпадает ли путь к файлу, выбранный логикой поиска в require, с путем, по которому был создан файл предварительной компиляции. Кроме того, принимается во внимание набор зависимостей, уже загруженных в текущий процесс. Эти модули не будут перекомпилированы, даже если их файлы изменятся или исчезнут, чтобы исключить возникновение несовместимости между работающей системой и кешем предварительной компиляции. Наконец, принимаются во внимание изменения в любых настройках времени компиляции.

Если известно, что предварительная компиляция модуля небезопасна (например, по одной из причин, описанных ниже), необходимо поместить функцию __precompile__(false) в файл модуля (обычно в верхнюю часть). В результате функция Base.compilecache выдаст ошибку, а оператор using или import загрузит модуль непосредственно в текущий процесс и пропустит процедуры предварительной компиляции и кеширования. Это также предотвращает импорт модуля любым другим предварительно скомпилированным модулем.

Возможно, вам потребуется быть в курсе некоторых особенностей поведения, присущих созданию добавочных общих библиотек и требующих внимания при написании модуля. Например, внешнее состояние не сохраняется. Чтобы учесть этот момент, следует явным образом отделить шаги инициализации, которые должны осуществляться во время выполнения, от шагов, которые могут происходить во время компиляции. Для этого Julia позволяет определить функцию __init__() в модуле, которая выполняет любые шаги инициализации, которые должны происходить во время выполнения. Эта функция не будет вызываться во время компиляции (--output-*). По сути, можно предположить, что она будет выполнена ровно один раз за все время существования кода. Конечно, при необходимости вы можете вызвать ее вручную, но по умолчанию считается, что эта функция работает с состоянием вычислений для локального компьютера, которое не нужно — или даже не следует — фиксировать в скомпилированном образе. Функция будет вызвана после загрузки модуля в процесс, в том числе если он загружается в процесс добавочной компиляции (--output-incremental=yes), но не будет вызвана, если модуль загружается в процесс полной компиляции.

В частности, если вы определите функцию function __init__() в модуле, Julia вызовет функцию __init__() сразу после загрузки модуля (например, с помощью операторов import, using или require) во время выполнения в первый раз (т. е. функция __init__ вызывается только один раз и только после выполнения всех операторов в модуле). Поскольку функция вызывается после полного импорта модуля, функции __init__ подмодулей или других импортированных модулей вызываются перед функцией __init__ охватывающего модуля.

Два типичных применения функции __init__ — это вызов функций инициализации среды выполнения внешних библиотек C и инициализация глобальных констант, которые предусматривают использование указателей, возвращаемых внешними библиотеками. Например, предположим, что нужно вызвать библиотеку C libfoo, для которой требуется вызвать функцию инициализации foo_init() во время выполнения. Предположим, что также следует опередить глобальную константу foo_data_ptr, которая будет хранить возвращаемое значение функции void *foo_data(), определенной библиотекой libfoo. Эта константа должна быть инициализирована во время выполнения (не во время компиляции), поскольку адрес указателя будет меняться в каждом выполнении. Это можно сделать, определив в модуле следующую функцию __init__.

Обратите внимание, что вполне возможно определить глобальный объект внутри функции типа __init__. Это одно из преимуществ использования динамического языка. Сделав объект константой в глобальной области, можно гарантировать, что тип известен компилятору, и позволить ему генерировать более оптимизированный код. Очевидно, что любые другие глобальные объекты в модуле, который зависит от foo_data_ptr, также должны быть инициализированы в функции __init__.

Константы, связанные с большинством объектов Julia, которые не создаются с помощью ключевого слова ccall, не нужно помещать в функцию __init__: их определения могут быть предварительно скомпилированы и загружены из образа кешированного модуля. К ним относятся сложные выделяемые в куче объекты, такие как массивы. Однако любую подпрограмму, возвращающую необработанное значение указателя, следует вызывать во время выполнения, в противном случае предварительная компиляция выполнена не будет (объекты Ptr превратятся в нулевые указатели, если только они не скрыты внутри объекта isbits). Сюда входят возвращаемые значения функций Julia @cfunction и pointer.

Ситуация со словарными типами и типами наборов или вообще со всем, что зависит от вывода метода hash(key), намного сложнее. В общем случае, когда ключами являются числа, строки, символы, диапазоны, выражения Expr или композиции этих типов (через массивы, кортежи, наборы, пары и т. д.), предварительная компиляция выполняется без проблем. Однако для некоторых других типов ключей, таких как Function или DataType, и универсальных определяемых пользователем типов, для которых не определен метод hash, резервный метод hash зависит от адреса памяти объекта (через его идентификатор objectid) и, следовательно, может меняться в каждом выполнении. Если у вас есть один из этих типов ключей или если вы не уверены, в целях безопасности можно инициализировать этот словарь в функции __init__. В качестве альтернативы можно использовать словарный тип IdDict, который специально обрабатывается в рамках предварительной компиляции, чтобы его можно было безопасно инициализировать во время компиляции.

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

Ниже приводятся другие известные потенциальные сценарии сбоя:

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

Ниже перечислено еще несколько моментов, на которые следует обратить внимание.

Иногда во время разработки модуля целесообразно отключить добавочную предварительную компиляцию. Включать или отключать предварительную компиляцию модуля можно с помощью флага командной строки --compiled-modules={yes|no}. Когда Julia запускается с установленным флагом --compiled-modules=no, сериализованные модули в кеше компиляции игнорируются при загрузке модулей и зависимостей модулей. Более детальный контроль обеспечивается параметром --pkgimages=no, который подавляет только хранение машинного кода во время предварительной компиляции. Функцию Base.compilecache по-прежнему можно вызывать вручную. Состояние этого флага командной строки передается скрипту Pkg.build для отключения автоматического запуска предварительной компиляции при установке, обновлении и явной сборке пакетов.

Некоторые сбои предварительной компиляции можно также отладить с помощью переменных среды. Если задать JULIA_VERBOSE_LINKING=true, это может помочь устранить сбои при компоновке общих библиотек скомпилированного машинного кода. В документации для разработчиков в руководстве Julia есть раздел, посвященный особенностям внутреннего устройства Julia, в главе «Образы пакетов», где можно найти более подробные сведения.