Фичи и баги OWEN Logic

[wal79]

А что вы подразумевали-то под словом "inline"?


Вот тут я не соглашусь.

Вы что, предлагаете, что "надёжный программно-аппаратный комплекс ОЛ-ПР" работает "как-то автомагически"?

Приведу пример:

int x = 2;
int y = x + x * x;

Чему равно y?
Разумеется, пользователю важно знать чего ожидать от программы. Программу же не наобум пишут, а с примерным представлением того, как она должна работать.
Так вот: y может быть равно 6, а может и 8.
При этом, ответ не зависит от того компилируется выражение в машинные коды или оно вычисляется интерпретатором.
Результат определяется именно тем, "как хотел создатель языка", а уж как реализован конкретный компилятор (на C, на Java, или ещё как) пользователей волнует в последнюю очередь.

В языках C, C#, Java и прочих явно оговорены правила вычислений выражений.
Эти самые правила никогда не ссылаются на "регистры процессора", "машинный код", "адреса памяти", ведь правила на то и правила, чтобы объяснять суть происходящего.
Вот в выражении x + x * x приоритет операции умножения выше, поэтому выражение эквивалентно выражению x+(x*x).
При этом, компилятор может хоть как это выражение вычислять.
Например, компилятор может использовать специальную инструкцию FMA (fused-multiply-add), которая за одну операцию вычислит именно это выражение.

Вот пример в случае C# (выдержка из спецификации C# 3.0):
Снимок экрана 2017-08-29 в 12.28.25.png

Так и в случае с ОЛ.
Пользователям важно знать по каким правилам должны работать схемы ОЛ.
Сказать, что "вся текущая реализация ОЛ это одно большое правило", конечно, можно, но это бесполезно.

Пользователям ОЛ важно уметь предсказывать результат программы "в уме" и без использования ОЛ. Поэтому и объяснение того, "как должны работать ОЛ схемы" (== спецификацию ОЛ языка) желательно описывать без привлечения фраз в духе "ОЛ загружает значение в стек, поэтому тут получается 2, а не 3". Да какая разница стек или регистр?
По-хорошему, должно быть более-менее стройное и простое объяснение в духе "результат работы ОЛ схемы будет неотличим от результата, полученного таким-то алгоритмом", а при этом сама программа ОЛ может использовать те оптимизации, которые удобны авторам.


PS. По-моему, вы путаете путаете понятие "спецификация" и "реализация".

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

[Владимир Ситников]

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

И?

Ответьте на вопрос прямо. Действительно считаете, что пользователям ОЛ (в том числе схемотехникам) нет никакой нужды в том, чтобы уметь предсказывать поведение схемы?

[wal79]

И?

Ответьте на вопрос прямо. Действительно считаете, что пользователям ОЛ (в том числе схемотехникам) нет никакой нужды в том, чтобы уметь предсказывать поведение схемы?

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

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

[Владимир Ситников]

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

Задумайтесь над тем, как определяется "является ли что-то багом или нет".
Является багом, значит "результат ОЛ не соответствует ожидаемому". Это самое ожидаемое должно откуда-то возникать.

И тут вы говорите, что "описание правил вычисления ОЛ схемы" пользователям не нужно, т.к. они просто схемотехники, и им без разницы как вычисляется схема, лишь бы ОЛ не падало.


Я не просто так в этой теме вопросы задаю про "правила вычисления". Они имеют самое прямое отношение к тому, что считается багом, а что нет.
Вот в 1.9.141.11543 взяли и поменяли подход работы с макросами:

Релиз 1.9.141
Убрана "прозрачность" макроса при анализе схемы
Рассмотренный ранее сценарий работы фрагмента кода как в макросе, так и просто в схеме отменен за неправильностью логики работы.

Что значит эта самая "прозрачность"? О какой "неправильной логике работы речь"? Как раз на подобные вопросы обычно и отвечает спецификация (которой у ОЛ нет, т.к. схемотехникам пофиг). При этом, в спецификации зачастую приводятся примеры, показывающие пограничные случаи.

Вы настаиваете на том, что единственный способ понять "что вернёт схема" это "запустить в ОЛ". Что ж. Печально. Это означает то, что так и будут ошибки выявляться (или вообще не выявляться) точечно типа "на такой-то схеме линия задержки снова не так работает", а "простосхемотехники" будут по-прежнему брюзжать, что "в нормальных схемных редакторах вообще без обратных связей/линий задержки обходятся".

[wal79]

Задумайтесь над тем, как определяется "является ли что-то багом или нет".
Является багом, значит "результат ОЛ не соответствует ожидаемому". Это самое ожидаемое должно откуда-то возникать.

И тут вы говорите, что "описание правил вычисления ОЛ схемы" пользователям не нужно, т.к. они просто схемотехники, и им без разницы как вычисляется схема, лишь бы ОЛ не падало.


Я не просто так в этой теме вопросы задаю про "правила вычисления". Они имеют самое прямое отношение к тому, что считается багом, а что нет.
Вот в 1.9.141.11543 взяли и поменяли подход работы с макросами:

Что значит эта самая "прозрачность"? О какой "неправильной логике работы речь"? Как раз на подобные вопросы обычно и отвечает спецификация (которой у ОЛ нет, т.к. схемотехникам пофиг). При этом, в спецификации зачастую приводятся примеры, показывающие пограничные случаи.

Вы настаиваете на том, что единственный способ понять "что вернёт схема" это "запустить в ОЛ". Что ж. Печально. Это означает то, что так и будут ошибки выявляться (или вообще не выявляться) точечно типа "на такой-то схеме линия задержки снова не так работает", а "простосхемотехники" будут по-прежнему брюзжать, что "в нормальных схемных редакторах вообще без обратных связей/линий задержки обходятся".

Печально это звучит или нет, но Вы верно сказали что на 100% удостовериться в правильности работы следует запустить симулятор. Именно такие требования и ставились. Я понимаю Ваше желание понять специфику работы. Обратные связи преподнесли в свое время много сюрпризов, о которых не задумывались при разработке лоджике, да и не только обратные связи. Исторически лоджик рос, не знаю даже какое слово будет звучать более правильно, спонтанно что ли... Смысл я надеюсь понятен, иначе разъяснить не могу. Спецификации нет, это факт. Да что там, справки по сути толковой нет, только краткая справка и далеко не по всем функциям лоджика. Работаем над этим. Больше сказать нечего.

[Вольд]

Исторически лоджик рос, не знаю даже какое слово будет звучать более правильно, спонтанно что ли...

Очень интересное признание. Т.е. делали так как кому на ум взбредет. Не солидно как-то все это.

Господа овеновцы, найдите наконец толкового исполнителя для разработки адекватной среды для ПР. XXI век на дворе.

[capzap]

Очень интересное признание. Т.е. делали так как кому на ум взбредет. Не солидно как-то все это.

Господа овеновцы, найдите наконец толкового исполнителя для разработки адекватной среды для ПР. XXI век на дворе.

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

[wal79]

Очень интересное признание. Т.е. делали так как кому на ум взбредет. Не солидно как-то все это.

Господа овеновцы, найдите наконец толкового исполнителя для разработки адекватной среды для ПР. XXI век на дворе.

Каждый думает в меру своего развития. Что я подразумевал под спонтанностью. Первоначально были предъявлены определенные требования к продукту ОЛ. Согласно этим требованиям была разработана архитектура приложения. Требования были просты и задачи перед продуктом ставились простые. Увидев
положительную реакцию пользователей впоследствии стали ставиться все более накрученные требования. Политика была направлена на обратную связь от пользователей. Да, курс продукта менялся, иногда даже слишком кардинально. Иногда доходило до кардинальной переработке архитектуры и знаний о предметной области. И до сих пор мое мнение не изменилось насчет обратной связи. Что продукт прежде всего должен учитывать желание рынка, пользователей. Конечно вы должны понимать что кардинальные перемены в архитектуре влекут за собой баги. Проблема ОЛ в том что он выходит на рынок сырой, так сказать с пылу жару. Вы можете критиковать разработчиков как угодно. Может лоджику далеко до каких-то других продуктов конкурентов. Но этот продукт имеет немаловажный плюс: реактивность обратной связи пользователей. Лоджик создавался как продукт в котором легко создавать алгоритмы простой и средней тяжести. Такое было одно из требований. Поэтому многие вещи скрыты от пользователей. Можете дальше ругать лоджик и разработчиков на чем свет стоит. Понятно, что всем не угодишь.

[wal79]

Задумайтесь над тем, как определяется "является ли что-то багом или нет".
Является багом, значит "результат ОЛ не соответствует ожидаемому". Это самое ожидаемое должно откуда-то возникать.

И тут вы говорите, что "описание правил вычисления ОЛ схемы" пользователям не нужно, т.к. они просто схемотехники, и им без разницы как вычисляется схема, лишь бы ОЛ не падало.


Я не просто так в этой теме вопросы задаю про "правила вычисления". Они имеют самое прямое отношение к тому, что считается багом, а что нет.
Вот в 1.9.141.11543 взяли и поменяли подход работы с макросами:

Что значит эта самая "прозрачность"? О какой "неправильной логике работы речь"? Как раз на подобные вопросы обычно и отвечает спецификация (которой у ОЛ нет, т.к. схемотехникам пофиг). При этом, в спецификации зачастую приводятся примеры, показывающие пограничные случаи.

Вы настаиваете на том, что единственный способ понять "что вернёт схема" это "запустить в ОЛ". Что ж. Печально. Это означает то, что так и будут ошибки выявляться (или вообще не выявляться) точечно типа "на такой-то схеме линия задержки снова не так работает", а "простосхемотехники" будут по-прежнему брюзжать, что "в нормальных схемных редакторах вообще без обратных связей/линий задержки обходятся".

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