Но для того, чтобы было более понятно, подсказки вставлю поясняющие.Цитата:
Сообщение от wal79
Вид для печати
Но для того, чтобы было более понятно, подсказки вставлю поясняющие.Цитата:
Сообщение от wal79
Хм, совсем непонятно, о чем идет речь.Цитата:
Сообщение от wal79
Вроде бы по всем свойствам переменная OUT+, состояние которой показывается в просмотрщике эквивалентна переменной current, которая всегда отображается как 0. Не могу придумать между ними разницы, по которой вторая могла бы быть виртуальной.
Почему Вы ищете между ними разницу. Они обе виртуальные, они играют роль связи и не более того. Потому что, они не энергонезависимые, на них нет ссылки из визуализации или откуда то еще. Они нужны только лишь для связи внутри макроса и все. Поэтому компилятор в реальности эти переменные не создает для прибора. Поэтом то Вы и видите всегда 0 в просмотрщике. Но по Вашему недоумению понимаю, что нужно еще предпринять какие-то разъяснительные шаги в лоджике.Цитата:
Сообщение от anthrwpos
Можете ещё какими-нибудь словами мысль выразить?Цитата:
Сообщение от wal79
Термин "inline функция", полагаю, подразумевается из C/C++. Но совершенно непонятно почему вы напираете на слово inline.
Дело в том, что в этих языках наличие или отсутствие модификатора inline не влияет на результат программы.
Иными словами, inline функция и точно такая же не-inline будут работать совершенно одинаково, а сам признак inline это лишь подсказка компилятору, влияющая на скорость работы программы, но не на результат.
Вообще говоря, подставляет ли компилятор код макроса каждый раз или компилирует макрос единожды -- не так важно для пользователей ОЛ.Цитата:
Сообщение от wal79
Вот вы говорите, что компилятор встраивает тело в код, но это совершенно ничего не даёт, т.к. сам факт встраивания никак не влияет на результат работы результирующей схемы.
Можно сделать встраивание одним образом, а можно и другим.
В классическом (C, LISP) понимании, "макрос" существенно отличается от "функции" тем, что его аргументы вычисляются после подстановки самого макроса.
Например, макрос в C после подстановки внезапно может сослаться на объявленную вне макроса переменную (просто по имени), а функция (в том числе inline) так не может.
Или так:
Поэтому интересна семантика макросов, а не детали реализации компилятора.Код:#define MUL(x, y) x*y
int inline mul(int x, int y) {
return x * y;
}
...
MUL(2+2, 2); // вернёт 6, т.к. 2+2*2 (сначала подстановка макроса, а потом вычисление)
mul(2+2, 2); // вернёт 8, т.к. mul(4, 2) == 4*2 == 8 (аргументы функции вычисляются до начала её работы)
Например, сейчас нигде толком не описано как происходят вычисления ОЛ схем. От входов к выходам? От выходов ко входам? Макрос вычисляется "весь целиком" или только те выходы, которые реально понадобились? Выходы вычисляются "одновременно" или только в те моменты как понадобились?
Расскажите, пожалуйста, в какой литературе используется такая терминология.Цитата:
Сообщение от anthrwpos
В C, C++, LISP, Scala понятие макроса и функции кардинально отличаются от того, что вы тут пишете.
Прежде чем жонглировать понятиями макроса-функции разберитесь с самими понятиями: https://ru.wikibooks.org/wiki/%D0%9B...BE%D1%81%D1%8B, http://alenacpp.blogspot.ru/2005/01/blog-post_28.html и т.д.
2 бага (1.9.141.11543):Цитата:
Сообщение от wal79
Баг №1
1. Создаём макрос (2 входа, 1 выход)
2. Сохраняем проект. Исходное состояние: проект пустой, но наверху есть вкладка редактора макроса.
3. Переключаемся на редактирование макроса.
4. Нажимаем "добавить выход"
5. Переключаемся на основную схему. Важно: до переключения ничего не делать. Только переключиться
6. Сохраняем проект.
7. Добавляем макрос на полотно.
Результат: макрос добавился с одним выходом
Ожидается: должно быть 2 выхода, т.к. на шаге 4 был добавлен.
Вообще говоря, странно, что при изменении количества входов-выходов макроса требуется сохранять проект.
Баг №2
0. Берём схему, использующую макрос.
1. Добавляем выход к макросу
2. Удаляем выход у макроса
3. Сохраняем проект.
Результат: ошибка "выделенные элементы были модифицированы, требуется их заменить".
По факту же, ничего не изменилось, значит и ошибка лишняя.
Если под вмешательством подразумевается "посмотреть и одобрить", то в этом какая-то логика есть.Цитата:
Сообщение от wal79
А вот переподключать вручную -- немного странно.
Если вы говорите про "сигнатуры функций", то напомню как в C / ST работают подобные действия. Там функцию можно вообще полностью удалить и написать заново. Если сигнатура подойдёт, то всё заработает само собой. Если же сигнатура не совпадёт (например, добавился 1 аргумент), то достаточно будет в вызывающем месте добавить этот самый аргумент и всего делов. Иными словами, изменение сигнатур не требует ходить, удалять и переписывать с нуля все места, где был вызов функции.
Проект одномоментно был сильно перекроен возникающие ошибки игнорировались, проект на симуляцию не запускался и, по-видимому, несколько ошибок наложившись друг на друга дали такой эффект.Цитата:
Сообщение от wal79
Сейчас проявилась новая проблема, хотя ранее я ее не замечал ошибки со стеком. Сегодня загружаю V3.2 - "Внутренняя ошибка код 2 обращение к стеку". Пробую V3.1 - "Стек пуст" В версии V3 ошибок нет.
Стал удалять макросы по одному, затем нажимая отмена. Удалил макросы ErrCatch ошибка исчезла. Начал отмену ошибка не вернулась.
Заметил, что если подсвеченный красным макрос, который был изменен скопировать, а затем вставить, вставляется копия макроса неподсвеченная красным. Может быть сдесь прошел глючок?
ЗЫ: последнее обновление установил.
Вы все конечно красиво расписали. На деле не совсем так. Нет того "умного" принятия решения о модификации макроса, о котором Вы говорите. Если Вы говорите, что пользователям нет нужды знать как компилятор обрабатывает тот или иной фрагмент схемы, то тем более зачем им тогда знать как работает анализ схемы.
С багом 1 соглашусь. При сохранении проекта изменения в макросе должны были примениться.
Про баг 2 уже сказал, что нет "умного" принятия решения. Вы описываете то, что хотели бы видеть. Таких хотелок Вы не представляете сколько у меня есть по лоджику. У меня сжатые сроки и абсолютное отсутствие человекоресурсов. Поэтому что есть, то есть.
Вполне может быть источником ошибок (я про выделенное). Учту при следующем разборе багов.Цитата:
Сообщение от RomX
А что вы подразумевали-то под словом "inline"?Цитата:
Сообщение от wal79
Вот тут я не соглашусь.Цитата:
Сообщение от wal79
Вы что, предлагаете, что "надёжный программно-аппаратный комплекс ОЛ-ПР" работает "как-то автомагически"?
Приведу пример:
Чему равно y?Код:int x = 2;
int y = x + x * x;
Разумеется, пользователю важно знать чего ожидать от программы. Программу же не наобум пишут, а с примерным представлением того, как она должна работать.
Так вот: y может быть равно 6, а может и 8.
При этом, ответ не зависит от того компилируется выражение в машинные коды или оно вычисляется интерпретатором.
Результат определяется именно тем, "как хотел создатель языка", а уж как реализован конкретный компилятор (на C, на Java, или ещё как) пользователей волнует в последнюю очередь.
В языках C, C#, Java и прочих явно оговорены правила вычислений выражений.
Эти самые правила никогда не ссылаются на "регистры процессора", "машинный код", "адреса памяти", ведь правила на то и правила, чтобы объяснять суть происходящего.
Вот в выражении x + x * x приоритет операции умножения выше, поэтому выражение эквивалентно выражению x+(x*x).
При этом, компилятор может хоть как это выражение вычислять.
Например, компилятор может использовать специальную инструкцию FMA (fused-multiply-add), которая за одну операцию вычислит именно это выражение.
Вот пример в случае C# (выдержка из спецификации C# 3.0):
Вложение 32888
Так и в случае с ОЛ.
Пользователям важно знать по каким правилам должны работать схемы ОЛ.
Сказать, что "вся текущая реализация ОЛ это одно большое правило", конечно, можно, но это бесполезно.
Пользователям ОЛ важно уметь предсказывать результат программы "в уме" и без использования ОЛ. Поэтому и объяснение того, "как должны работать ОЛ схемы" (== спецификацию ОЛ языка) желательно описывать без привлечения фраз в духе "ОЛ загружает значение в стек, поэтому тут получается 2, а не 3". Да какая разница стек или регистр?
По-хорошему, должно быть более-менее стройное и простое объяснение в духе "результат работы ОЛ схемы будет неотличим от результата, полученного таким-то алгоритмом", а при этом сама программа ОЛ может использовать те оптимизации, которые удобны авторам.
PS. По-моему, вы путаете путаете понятие "спецификация" и "реализация".
Вы подходите со стороны программиста. Лоджик изначально создавался с позиции схемотехника. Понятно, что с некоторыми оговорками, которые уже не раз обсуждались.Цитата:
Сообщение от Владимир Ситников
потому что изменения одной из них, отображаются в просмотрщике, а другой - нет.Цитата:
Сообщение от wal79
Вставлю скрин еще раз иллюстрирующий непонятность.Вложение 32860
Переменная OUT+ 1 в макросе и 1 в графе значение
Переменная current 0.0762 в макросе и 0 в графе значение.
И?Цитата:
Сообщение от wal79
Ответьте на вопрос прямо. Действительно считаете, что пользователям ОЛ (в том числе схемотехникам) нет никакой нужды в том, чтобы уметь предсказывать поведение схемы?
Ясно. Вас смутило что там 1. Когда Вы добавляли Q1 в просмотрщик на тот момент выход имел видимо значение 1. Вот Вы его и видите. Вас должна была смутить "серость" строк таблицы, которая как раз говорит о недоступности переменных.Цитата:
Сообщение от anthrwpos
Конечно пользователь должен понимать как создавать схему. Но Вы гребете все под свой уровень ,что не верно.Цитата:
Сообщение от Владимир Ситников
Предлагаю в этой ветке спор уже закончить. Все же ветка создана для сбора багов. За баги, о которых Вы сообщили спасибо, будем работать над ними.
Таки нет, оно не постоянно 1, а отражает реальную динамику этой переменной. Это получается, баг?=)Цитата:
Сообщение от wal79
Я не нашел по вашим ссылкам, в чем мое определение макроса расходится с описываемым там.Цитата:
Сообщение от Владимир Ситников
Вы пишете:Цитата:
Сообщение от anthrwpos
Цитата:
Сообщение от anthrwpos
^^^ Это какой-то бред. Вы говорите про адреса, неизменные участки кода и т.п.Цитата:
Сообщение от anthrwpos
Вот как на основании ваших определений можно понять какая физически разница между макросом и функцией?
В LISP описании говорится очень ясно, и без адресов участков кода:
Цитата:
https://ru.wikibooks.org/wiki/%D0%9B...BE%D1%81%D1%8B : от функций макросы отличаются способом вычисления, которое проходит в два этапа: получение нового выражения (раскрытие макроса) и вычисление этого выражения.
Переменная Q1 создается в редакторе макросов специально для отладочных целей. Она только на чтение. В реальном проекте ее конечно не существует. Поэтому изменения значения выходов в редакторе макросов видны, но задать свое значение нельзя. Что касается переменной current, к примеру, она не существует ни в проекте ни в редакторе макросов конечно же (зачем?). Поэтому изменения значения Вы не видите. Как current, так и переменная выхода Q1 доступны только для чтения, поэтому они "серые". Как я уже говорил, раз появляются сомнения, значит я со своей стороны к примеру уберу возможность добавления в просмотрщик виртуальных переменных.Цитата:
Сообщение от wal79
Как я уже говорил, давайте прекратим в этой ветке обсуждать это.Цитата:
Сообщение от Владимир Ситников
Не знаю, как вы, а программер меня отлично понял и дал исчерпывающий ответ)Цитата:
Сообщение от Владимир Ситников
И тоже я не нашел критической разницы. По сути написано то-же что и у меня но другими словами.Цитата:
В LISP описании говорится очень ясно, и без адресов участков кода:
Кстати да, чтобы не засорять тему, если хотите продолжить, создавайте отдельную.
Вобщем, понятно. Это не баг, а так и должно быть.Цитата:
Сообщение от wal79
Но на будущее было бы неплохо, чтобы и "виртуальные переменные" можно было бы видеть таким образом)
Задумайтесь над тем, как определяется "является ли что-то багом или нет".Цитата:
Сообщение от wal79
Является багом, значит "результат ОЛ не соответствует ожидаемому". Это самое ожидаемое должно откуда-то возникать.
И тут вы говорите, что "описание правил вычисления ОЛ схемы" пользователям не нужно, т.к. они просто схемотехники, и им без разницы как вычисляется схема, лишь бы ОЛ не падало.
Я не просто так в этой теме вопросы задаю про "правила вычисления". Они имеют самое прямое отношение к тому, что считается багом, а что нет.
Вот в 1.9.141.11543 взяли и поменяли подход работы с макросами:
Что значит эта самая "прозрачность"? О какой "неправильной логике работы речь"? Как раз на подобные вопросы обычно и отвечает спецификация (которой у ОЛ нет, т.к. схемотехникам пофиг). При этом, в спецификации зачастую приводятся примеры, показывающие пограничные случаи.Цитата:
Релиз 1.9.141
Убрана "прозрачность" макроса при анализе схемы
Рассмотренный ранее сценарий работы фрагмента кода как в макросе, так и просто в схеме отменен за неправильностью логики работы.
Вы настаиваете на том, что единственный способ понять "что вернёт схема" это "запустить в ОЛ". Что ж. Печально. Это означает то, что так и будут ошибки выявляться (или вообще не выявляться) точечно типа "на такой-то схеме линия задержки снова не так работает", а "простосхемотехники" будут по-прежнему брюзжать, что "в нормальных схемных редакторах вообще без обратных связей/линий задержки обходятся".
Наоборот тогда виртуальные переменные не следует разрешать добавлять в список, потому что их нельзя отследить, их не существует.Цитата:
Сообщение от anthrwpos
Печально это звучит или нет, но Вы верно сказали что на 100% удостовериться в правильности работы следует запустить симулятор. Именно такие требования и ставились. Я понимаю Ваше желание понять специфику работы. Обратные связи преподнесли в свое время много сюрпризов, о которых не задумывались при разработке лоджике, да и не только обратные связи. Исторически лоджик рос, не знаю даже какое слово будет звучать более правильно, спонтанно что ли... Смысл я надеюсь понятен, иначе разъяснить не могу. Спецификации нет, это факт. Да что там, справки по сути толковой нет, только краткая справка и далеко не по всем функциям лоджика. Работаем над этим. Больше сказать нечего.Цитата:
Сообщение от Владимир Ситников
В той схеме, о которой мы говорим вы пытаетесь линию задержки превратить в обратную связь. Вот вы создали макрос, назначение которого просто задержать сигнал на цикл. Вы используете этот макрос в схеме, зацикливая его. И логично что вы увидите двойную задержку.Цитата:
Сообщение от Владимир Ситников
Владимир, посмотрите описание Inline функций в языках интерпритаторах (например в iDev-OS).
Кстати, программисты-Британцы, кипятком писают от возможности вставлять Inline функции, и с огромным удовольствием делают строку кода бесконечной длинны. (а для программистов-русских совершенно запутанную программу)
И?Цитата:
Сообщение от Project M
Т.е. inline func в смысле iDev-OS это лишь "безымянная функция". Разумеется, к ОЛ это никак не относится, т.к. ОЛ макросы именованные и т.п.Цитата:
http://www.noritake-itron.com/Web/it...s/Top_Cmd.html
The commands which require a function as a parameter ie IF, RUN, INT and KEY can have the function code embedded inside the commands by enclosing the required code in square brackets.
This allows you to reduce the number of lines of code for simple functions and where the function is unlikely to be used elsewhere.
wal79 рассказал, то основополагающая методология разработки ОЛ -- спонтанная, и никакие спецификации не нужны. Поэтому и не нужно объяснять что значат "прозрачные макросы", "inline макросы", "линия задержки", "обратная связь", "виртуальные переменные" и далее по списку.
Просьба обсуждение перенести в другую ветку.Цитата:
Сообщение от Владимир Ситников
Хватит уже флудить ,вас же просили!!!Цитата:
Сообщение от Владимир Ситников
Очень интересное признание. Т.е. делали так как кому на ум взбредет. Не солидно как-то все это.Цитата:
Сообщение от wal79
Господа овеновцы, найдите наконец толкового исполнителя для разработки адекватной среды для ПР. XXI век на дворе.
Разработчик, во первых указал что не знает какое слово подобрать, поэтому не стоит передергивать и самостоятельно делать выводы как делался лоджик. Продукт делался от обратной связи тех кто с ним продолжительное время работает и сделал ни один проект для производства. Когда же сделали попытку послушать всех любопытствующих, со своими представлениями о IDE, так и пошли критические ошибкиЦитата:
Сообщение от Вольд
Если в стане разработчиков разброд и шатания, то другого результата и быть не может.Цитата:
Сообщение от capzap
Нет у разработчиков четкой идеологии и представления о предмете.
есть хорошая статья по поводу изолированности разработчиков, от таких как Вы https://habrahabr.ru/company/retailrocket/blog/336430/, жаль что модераторы не придерживаются такого принципаЦитата:
Сообщение от Вольд
Эта статья для разработчиков и про разработчиков OL. ;)Цитата:
Сообщение от capzap
А связывать меня с проблемами в OL просто смешно. Это бред сивой кобылы.
Наконец нашли виновного в проблемах ОЛ!Цитата:
Сообщение от Вольд
:):rolleyes:;)
внимательно ознакомтесь с моим постом, для тех кто в танке даю ключевые слова:Цитата:
Сообщение от Вольд
изолированность - разработчик не должен сидеть здесь на форуме и по каждой хотелке принимать какие то активные действия, если она пройдет все барьеры, то до него должны довести планы реализации этой хотелки
таких как Вы не относится персонально к кому либо
виновны все кто пытается пропихнуть свою хотелку не задумываясь к каким последствиям это может привести, результат уже виден одного такого действия
Для одного разработчика хорошо работают одни подходы, для 7-и разработчиков другие, для 49 тоже другие, а 343 совсем другие. Спонтанно ли рос ОЛ или ещё как -- не так важно.Цитата:
Сообщение от capzap
Предлагается, всё-таки в данной ветке обсуждать "Фичи и баги OWEN Logic". Выстраивание процесса в крупной компании к данной теме не относится.
Я поднимал вопрос о "составлении спецификации на вычисление схем" т.к.:
1) Линии задержки, обратные связи и макросы являются стабильным поставщиком "непоняток" при работе с ОЛ
2) Слова представителей ОВЕН весьма туманны. "Убрана прозрачность макросов", "у вас вместо линии задержки получилась обратная связь" и так далее.
На мой взгляд, спецификация может с одной стороны снимать вопросы "почему схема работает, а как заворачиваю половину в макрос, то перестаёт", и с другой служить документацией. Если честно, меня удивляет, что нет описания алгоритма по которому вычисляется ОЛ схема. Постоянно звучат слова "промышленность", "надёжность", а как вычисляется схема никто не знает и всех устраивает режим "как карта ляжет".
Так же, наличие спецификации позволит искать ошибки на уровне этой самой спецификации. Сейчас можно лишь гадать как ОЛ производит вычисления. Было бы описание -- можно было бы придумывать контрпримеры.
Судя по словам wal79, описание алгоритма вычисления схемы либо вообще не в планах, либо не в приоритете. Ну и ладно.
На всякий случай, вышеописанное ^^^ напрямую относится к "багам ОЛ". Например, оно пересекается с
Цитата:
Сообщение от Релиз 1.9.141
Не путайте "корреляцию" (correlation) и "причинную связь" (causation). Если знаете о критических ошибках, то пишите их в эту тему. Как раз тема для этого и существует. А обтекаемые формулировки "пошли критические ошибки" и "каким последствиям это может привести, результат уже виден одного такого действия" незачем сюда писать.Цитата:
Сообщение от capzap
Предлагаю озвучить все ники не пишущие в этой теме про фиксы и баги, чтоб это было объективно,а не попытка заткнуть рот оппонентуЦитата:
Сообщение от Владимир Ситников
Каждый думает в меру своего развития. Что я подразумевал под спонтанностью. Первоначально были предъявлены определенные требования к продукту ОЛ. Согласно этим требованиям была разработана архитектура приложения. Требования были просты и задачи перед продуктом ставились простые. УвидевЦитата:
Сообщение от Вольд
положительную реакцию пользователей впоследствии стали ставиться все более накрученные требования. Политика была направлена на обратную связь от пользователей. Да, курс продукта менялся, иногда даже слишком кардинально. Иногда доходило до кардинальной переработке архитектуры и знаний о предметной области. И до сих пор мое мнение не изменилось насчет обратной связи. Что продукт прежде всего должен учитывать желание рынка, пользователей. Конечно вы должны понимать что кардинальные перемены в архитектуре влекут за собой баги. Проблема ОЛ в том что он выходит на рынок сырой, так сказать с пылу жару. Вы можете критиковать разработчиков как угодно. Может лоджику далеко до каких-то других продуктов конкурентов. Но этот продукт имеет немаловажный плюс: реактивность обратной связи пользователей. Лоджик создавался как продукт в котором легко создавать алгоритмы простой и средней тяжести. Такое было одно из требований. Поэтому многие вещи скрыты от пользователей. Можете дальше ругать лоджик и разработчиков на чем свет стоит. Понятно, что всем не угодишь.
Ваше желание противоречит одному из требований: макрос должен себя вести также как в редакторе в режиме симуляции. Это касается макросов с ЛЗ, потому что если их нет, то и говорить не о чем, я думаю вы это и так понимаете. Так вот, Для выполнения этого требования при встрече макроса на своем пути анализатор вычисляет его полностью один раз. Алгоритмы те же самые что и у схем проектов. Логика проста. Но в чем преимущества ЛЗ? В том что они выполняются в высоком приоритете. Именно это дает эффект выполнения обратной связи, которую задумал пользователь. Так вот, если вы задумали какой-то алгоритм обернуть в макрос, то нужно понимать, что это "закрытый" будет алгоритм, что он будет вычисляться как отдельная схема. Надеюсь, понятно разъяснил.Цитата:
Сообщение от Владимир Ситников
Давайте уже на этой разъяснительной ноте остановимся.
Ну, на самом деле, противоречия тут нет.Цитата:
Сообщение от wal79
Противоречие есть с другим.
С тем, что анализатор схемы считает макрос функцией, а макрос с лз или обратной связью таковым не является.
Так же, как не является функцией любая схема "помнящая" своё состояние.
Вот поэтому он ("анализатор") и паникует, обнаружив "обратую связь вокруг функции", и подставляет вместо неё ещё одну лз.
Вариант "прозрачности", с сохранением однозначности работы схемы и макросов в схеме и в отдельном редакторе, есть, но он требует другого подхода к макросу. Это не функция, а схема, вставленная в "главную" схему (макроэлемент, объединяющий множество элементов и связей, имеющий условное графическое изображение), и для анализа всей схемы необходимо его каждый раз вставить целиком, после чего уже анализировать полную схему на наличие возможных неоднозначностей и "обратных связей" без лз.