QSP - Версия интерпретатора в Quest Navigator

Nex Moderator 19.11.2013 17:05 (12 years ago)

newsash,
нет.

Версия интерпретатора - это версия библиотеки. Если ты имеешь в виду различия именно в коде библиотеки, то версия устанавливается Байтом в момент релиза. В классическом плеере версия библиотеки соответствует релизному состоянию. В других плеерах, если используется не-релизная версия, в том числе с модификациями, отличать библиотеку от другой по номеру версии нельзя. Если требуется отличать, то нужно завести обозначение ветки модифицированной библиотеки и указывать ревизию сборки. Номер “базовой” версии при этом останется старым.

На практике, сейчас мы имеем только один плеер (старый Андроид-плеер не в счёт, т.к. его поддержка прекращена), Quest Navigator, со своими модификациями в библиотеке, использующий “свежую” не-релизную версию. Базовая версия у него указывается верно, “5.7.0”. Для возможности различать используемые плееры и платформы, в Quest Navigator сделана функция GETPLAYER.

Используется так:

IF LCASE(GETPLAYER('platform')) = 'ios':
    ...
END

Нужно, чтобы Байт включил поддержку GETPLAYER в следующей версии библиотеки. Таким образом все плееры станут равноправными, можно будет их различать в коде игры.

IF QSPVER < '5.7.1':
    ! Старая версия классического плеера либо AeroQSP
    'Ваш плеер устарел. Обновите его до последней версии.'
    EXIT
ELSE
    ! Есть поддержка GETPLAYER
    IF GETPLAYER('player') = 'Quest Navigator':
        ! Задаём настройки, специфичные для Quest Navigator.
        ...
    END
END

N

newsash #948 19.11.2013 17:05 (12 years ago)

Nex Moderator 19.11.2013 17:05 (12 years ago)

newsash,
я уже сказал как это решается: указывается ветка развития библиотеки и номер ревизии. Ревизия считается именно по ветке, для каждой ветки свои номера ревизий. И возвращается не в QSPVER, а в параметрах выдаваемых через GETPLAYER. Именно для такой “плеерозависимой” информации и создана эта функция.

GETPLAYER('library.branch')
GETPLAYER('library.revision')

Нет никакого смысла менять формат версии основной библиотеки.

N

newsash #948 19.11.2013 17:05 (12 years ago)

Nex Moderator 19.11.2013 17:05 (12 years ago)

newsash,
как это бесполезной?

Во-первых, без неё ты не сможешь надёжным образом использовать GETPLAYER. На одном плеере GETPLAYER сработает, на другом выдаст ошибку “Неизвестное выражение”. Если знаешь версию “базовой” библиотеки, то всегда знаешь какие возможности в ней реализованы.

Во-вторых, она нужна и для использования других фич языка. Мало ли старых плееров распространилось по планете? Поставив проверку на версию библиотеки в начале игры, автор может быть спокоен, что его игра, будучи запущенной на старом плеере, корректно попросит игрока обновить плеер, а не будет вылетать с ошибкой или, ещё хуже, глючить “втихую”.

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

Я напоминаю, что функция GETPLAYER возвращает то, что ей скажет плеер, а не библиотека, то есть любые данные предоставляемые этой функцией, возвращаются так, как захочет автор плеера. Это даёт большую гибкость - нет необходимости “ковырять” библиотеку для предоставления коду игры доступа ко всякой полезной информации, доступной плееру.

И когда смотрел исходник, не заметил обработки таких параметров.

Исходник чего?

N

newsash #948 19.11.2013 17:05 (12 years ago)

Nex Moderator 19.11.2013 17:05 (12 years ago)

Nex Moderator 19.11.2013 17:16 (12 years ago)

N

newsash #948 19.11.2013 17:17 (12 years ago)

Nex Moderator 19.11.2013 18:48 (12 years ago)

N

newsash #948 19.11.2013 19:32 (12 years ago)

Nex:

Допустим. И что дальше? Какие выводы? Какое это имеет значение?

Это был ответ на фразу “Если знаешь версию “базовой” библиотеки, то всегда знаешь какие возможности в ней реализованы.”. И аргумент в пользу того, что нужно ввести различение по QSPVER не дожидаясь выпуска новой версии классического плеера, если только ты не собираешься её дождаться и выпустить Навигатор на релизной версии библиотеки (тогда да, я зря поднял шум по поводу версии).

Nex:

А какие другие варианты?

Я писал - для не-релизных ревизий библиотеки добавлять номер ревизии к номеру версии. Относительно использования QSPVER всё в порядке: при сравнении “5.7.0” < “5.7.0.694” < “5.7.1”.
Это возможно сделать сразу в следующей сборке плеера без привязки к Байту и его планам (что сейчас происходит с GETPLAYER).

Spoiler

https://github.com/Nex-Otaku/qsplib-experimental/blob/experimental/declarations.h - строка 100

#define QSP_VER QSP_FMT("5.7.0")

И есть ещё один аргумент в пользу реализации именно на QSPVER - номер ревизии относится именно к библиотеке интерпретатора, а не к плееру (к плееру - косвенно). А то, что сейчас умеет GETPLAYER - относится напрямую к плееру.

Nex Moderator 20.11.2013 04:47 (12 years ago)

Это был ответ на фразу “Если знаешь версию “базовой” библиотеки, то всегда знаешь какие возможности в ней реализованы.”

Ну и где здесь противоречие? Версия “базовой” библиотеки соответствует вполне конкретной ревизии на момент релиза. Нововведения этой версии перечисляются для соответствующего релиза. Промежуточные версии библиотеки не релизятся в классическом плеере и AeroQSP.

Что не так-то? Всё верно, знаешь версию - знаешь и то, какие к этой версии сделаны изменения. Потому и релизы библиотеки выходят не с каждым коммитом, а только по накоплению определённого количества изменений.

Я писал - для не-релизных ревизий библиотеки добавлять номер ревизии к номеру версии. Относительно использования QSPVER всё в порядке: при сравнении “5.7.0” < “5.7.0.694” < “5.7.1”.

Ты предлагаешь добавить ревизию базовой ветки. Это не решает проблему. Как ты отличишь, версию библиотеки с внесёнными мной изменениями, от версии с не внесёнными изменениями? Ведь номер ревизии базовой ветки не изменится - изменится номер ревизии моей собственной ветки. У каждой ветки свои собственные номеры ревизий, они в общем случае не упорядочены. Поэтому ревизии нужно считать именно по ветке развития. И что в таком случае делать? Запихнуть в QSPVER ещё и название ветки, а потом его оттуда извлекать, парсить строку? Зачем устраивать этот геморрой, если через GETPLAYER всё можно получить гораздо удобнее?

И есть ещё один аргумент в пользу реализации именно на QSPVER

Реализовывай хоть через яваскрипт, это всё равно никому не нужно. Библиотека должна быть настолько стабильна, насколько это возможно. Потому и вводится GETPLAYER, чтобы у разработчика плеера было больше возможностей по усовершенствованию плеера без вмешательства в библиотеку. Заводить отдельную ветку развития на каждый плеер, собранный не по релизной версии, в которую даже изменений внесено не было - крайне глупо.

GETPLAYER и SYSTEM - это “расширяемое API” плеера. Байт изначально рассчитывал дать возможность расширения функционала библиотеки разработчику плеера. Просто он не учёл, что помимо “оператора” (SYSTEM), который сделает какие-то действия, нужна ещё и “функция” (GETPLAYER), которая вернёт результат.

В этой функции, так же как в операторе SYSTEM, может быть что угодно. Да, в первую очередь она нужна для добычи той информации, которая вне библиотеки принципиально недоступна. Это то, что делает её необходимой. Но никто не мешает её использовать для прочих целей. Всё, что может понадобиться в коде игры, и чего бибилиотека не предоставит “удобным образом”, может быть реализовано в GETPLAYER. Например, туда могут быть зашиты сложные математические функции, которые Байт никогда не введёт в библиотеку. Если автор плеера считает, что это необходимо его пользователям, почему бы и нет. Или встроен вызов каких-то стандартных модулей QSP-кода (типа расширенного инвентаря), с автоматической загрузкой в квест. Или какие-то функции, восполняющие то, чего в библиотеке нехватает в данный момент, но возможно появится в будущем, типа определения текстового индекса по числовому.

Это даёт разработчику плеера большое удобство - всё что может понадобиться, он может сделать не дожидаясь годами релиза библиотеки. При этом, начиная с той версии где будет введена функция GETPLAYER, ему даже ветку библиотеки свою заводить для этого не придётся.

N

newsash #948 20.11.2013 05:55 (12 years ago)

Всё, что ты написал - это здорово. Но, по-моему, смотря в будущее ты забываешь о настоящем:

Язык QSP в Навигаторе не соответствует версии 5.7.0
Даже базовая ветка библиотеки не соответствует версии 5.7.0
Но QSPVER в Навигаторе возвращает “5.7.0”
Функции GETPLAYER никогда не будет в 5.7.0
Quest Navigator планируется как полноценная замена классическому, а не как сторонний плеер (в котором допустимы какие угодно различия с базовой библиотекой)
Итого: две несовместимых ревизии библиотеки можно отличить только по косвенным признакам (кодоизвращениями)
Вывод: нужно дать возможность различать эти ревизии методами, доступными в классическом плеере версии 5.7.0 (напрашивается QSPVER) или отложить релиз Навигатора до релиза классического плеера с функцией GETPLAYER (который может и не состояться)

Да, проблему с ветками библиотеки это не решает, это решает более важную проблему. Хотя проблему с веткой тоже можно решить, например, буквой N в конце номера версии. Поиск буквы по строке - простая операция.

Если у тебя есть другие варианты решения - предлагай. Но функции GETPLAYER в версии 5.7.0 нет и никогда не будет. Она может появиться только в следующей версии.

P.S. Я не предлагаю это, как постоянное решение. Я предлагаю это, как временную затычку существующей проблемы, других решений которой я не знаю.

Nex Moderator 20.11.2013 07:16 (12 years ago)

N

newsash #948 20.11.2013 08:28 (12 years ago)