RS
Size: a a a
2021 February 19
RS
Довольно много сервисных функций типа srcdir, projectdir и пр.
2021 February 20
RS
Одинаковые имена недостаточно, может быть конфликт экспортов.
Лучше уж интерфейсный пакет, который нужно импортить и расширять.
Лучше уж интерфейсный пакет, который нужно импортить и расширять.
АО
Ха, извиняюсь.
А можно теперь на начало, что именно хочется сделать то? Я не вчитывался в код, понял только, что это какое-то кеширование промежуточных результатов с записыванием их на диск?
А можно теперь на начало, что именно хочется сделать то? Я не вчитывался в код, понял только, что это какое-то кеширование промежуточных результатов с записыванием их на диск?
RS
Иметь возможность обернуть куски кода, которые долго считаются, но нужны при каждом запуске, неким средством для хранения
RS
И это средство должно быть простым в использовании
АО
Ага, посмотрел.
Было бы наверное хорошо сделать это в двух режимах, ленивом и активном. Чтобы можно было выбирать на входе и при необходимости принудительно синхронизировать данные с внешним хранилищем.
Было бы наверное хорошо сделать это в двух режимах, ленивом и активном. Чтобы можно было выбирать на входе и при необходимости принудительно синхронизировать данные с внешним хранилищем.
RS
АО
Хмм, я в этом случае обычно базы данных использую, но это видимо искажения профессиональные уже.
RS
Ага, посмотрел.
Было бы наверное хорошо сделать это в двух режимах, ленивом и активном. Чтобы можно было выбирать на входе и при необходимости принудительно синхронизировать данные с внешним хранилищем.
Было бы наверное хорошо сделать это в двух режимах, ленивом и активном. Чтобы можно было выбирать на входе и при необходимости принудительно синхронизировать данные с внешним хранилищем.
Не всегда. Например, у меня лежат словари в виде текста. Надо векторы для них просчитать. И эти словари меняются редко, а время вычисления векторов - несколько минут.
RS
Хмм, я в этом случае обычно базы данных использую, но это видимо искажения профессиональные уже.
Сериализация…. Зачем мне думать о структуре БД, если я могу в JLD поместить почти любой тип, включая коллекции
АО
Ну да, логично.
Я просто избегаю таких штук, потому что они плохо дружат с другими языками и даже между разными версиями.
Ха, я как-то раз делал страшное и pickle хранил в базе прямо бинарными блобом :-)
Я просто избегаю таких штук, потому что они плохо дружат с другими языками и даже между разными версиями.
Ха, я как-то раз делал страшное и pickle хранил в базе прямо бинарными блобом :-)
АО
На самом деле штука классная, спасибо.
Но в самом деле, жить в JLD такой функциональности как-то неправильно.
Но в самом деле, жить в JLD такой функциональности как-то неправильно.
АО
PersistentDict звучит правильнее.
RS
В моём конкретном случае речь идёт именно о хранении промежуточных результатов, исходники для вычисления которых всегда лежат рядом
RS
JLD сама обеспечивает интерфейс ключ-значение, поэтому могла бы и сама покрыть необходимые для Dict функции. При этом, у Julia в стандартной коллекции Dict есть метод
get(f::Function, collection, key)RS
То есть, если бы библиотеки сериализаторов для себя реализовывали стандартные интерфейсы, то PersistentDict как отдельный пакет был бы не нужен
АО
Хмммм...
А как они это сделают? collection и key выглядят как что-то достаточно произвольного типа. То есть это будет type piracy
А как они это сделают? collection и key выглядят как что-то достаточно произвольного типа. То есть это будет type piracy
RS
Collection в этом раскладе - их собственный тип
RS
Просто не получится того варианта, который я предложил как jldcache