forum.clarionlife.net

Нет ли у кого простого и проверенного интерпретатора бейсика, в крайнем случае клариона в исходных кодах на С?

Ситуация следующая: надо чтобы одинаково работало как в моей задаче на кларионе, так и в чужом приложении на линукс.

Скачал несколько вариантов, но

Есть исходник Clarion на asm

А в чём сучность задачи, которую надо на васике?

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

Если есть другая идея, окромя дать клиенту в руки интерпретатор, буду рад выслушать.

Прицепите VBScript, python или еще что то.

0. Собственно, клиенту надо давать проблемно-ориентированный язык, а не вариант Basic. Типа как в 1С.
Мож, разработать? О какой области идёт речь?

1. Интересный вопрос - как интерпретатор должен взаимодействовать с программой, в т.ч. на Кларион
Надо как-то передавать данные на входе и принимать на выходе ...

2. У меня скрипты сейчас отлаживаются ( и исполняются) в Кларион, для web-приложения транслируются (программой на Python) в javascript
и там используются. В принципе, исходники готов подарить, и того и другого, хотя там ногу сломишь. А ещё есть Qt WebKit, можно Web-приложения и из Windows юзать (невостребовано, но тестовое приложение есть).

3. Javascript, конечно, vbscript сейчас не популярен. Ещё jQuery и jQuery UI - и таки да, можно в принципе. Но см. пункт 0, о приёме данных и возврате результатов). Собственно, приём не проблема, просто добавить данные в JSON в начало программы

3. Язык Lua не имеет GUI, но может интерпретировать скрипты и встраиваться в другие приложения. Может, оно ?

4. Python кроссплатформен и реализован для всех разумных платформ, даже для Raspberry Pi. В том числе для Windows, Linux и Android, гуглить слово Kivy...

Yufil писал(а): 0. Собственно, клиенту надо давать проблемно-ориентированный язык, а не вариант Basic. Типа как в 1С.
Мож, разработать? О какой области идёт речь?

Клиент привык работать с экселем и хочет что-то похожее или с минимальным переучиванием. Это критичное условие.
Ближе бейсика ничего не вижу

Да и не стоит оно того, разработки отдельного языка, да ещё с интерпретатором под две платформы сразу. Это очень маленький кусок большого проекта.

Yufil писал(а): Интересный вопрос - как интерпретатор должен взаимодействовать с программой, в т.ч. на Кларион
Надо как-то передавать данные на входе и принимать на выходе ...

Элементарно. Делов-то, через специальные функции возвращающие значения переменных. Я давным давно писал интерпретатор клариона, ещё под CDD. Но он в столь дальних архивах, что проще написать заново. Да и портировать его на C...

Yufil писал(а): Python кроссплатформен и реализован для всех разумных платформ, даже для Raspberry Pi. В том числе для Windows, Linux и Android, гуглить слово Kivy...

Если уж ничего другого не останется...


Всем спасибо, буду думать.

Yufil писал(а): Язык Lua не имеет GUI, но может интерпретировать скрипты и встраиваться в другие приложения. Может, оно ?

4. Python кроссплатформен и реализован для всех разумных платформ, даже для Raspberry Pi. В том числе для Windows, Linux и Android, гуглить слово Kivy...

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

Нет, оба языка являются интерпретаторами. Сам алгоритм может существовать в виде текстовой строки (видимо, лежит в БД и зашифрована) и исполняться на ходу. В Питоне это, например, функция eval - принимает строку, может вернуть выражение/объект/функцию/класс, а потом всё это дело можно исполнить.

Yufil писал(а): Сам алгоритм может существовать в виде текстовой строки

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

И двоичный код можно дизассемблировать и разобрать.

Yufil писал(а): И двоичный код можно дизассемблировать и разобрать.

Можно. Но на то существуют методы защиты. Цель не сделать невскрываемый вариант, цель сделать так, чтобы это было не очень просто. А подменить стандартную длл своей с протоколированием не догадается только идиот.

Ну, пока я ехал на работу, с ходу увидел несколько вариантов.
1. оформить алгоритм в виде модуля, оттранслировать его в байткод (на автомате при первом вызове) и приложить к программе именно байткод.
2. оформить алгоритм в виде модуля, оттранслировать его в C и (см. выше)
3. сделать модифицированный интерпретатор, чтобы генерировал и исполнял модифицированный байт-код, тогда наши программы будут исполнять, а чужие - фигу.
Но боюсь, что коллегам-Кларионистам это не интересно...

Yufil писал(а): у, пока я ехал на работу, с ходу увидел несколько вариантов.

Увы. Варианты 1 и 2 полностью не удовлетворяют условию клиента "возможность самостоятельно модифицировать алгоритм"
Вариант 3 довольно интересен, как инструкция к размышлению.

Yufil писал(а): 3. сделать модифицированный интерпретатор, чтобы генерировал и исполнял модифицированный байт-код, тогда наши программы будут исполнять, а чужие - фигу.
Но боюсь, что коллегам-Кларионистам это не интересно...

Ну, если это будет интерпретатор с Клариона....