Здравствуйте, AlexCab, Вы писали:
AC>Предположим, есть проект на N2, большой, много DSL, много участников. Были внесены изменения в один из DSL,ошибка проявилась по всему проекту. Какова цена исправления ошибки с сохранением изменений(по сравнению с использованием библиотек)?
По всему проекту?
Замечательно.
Эту ошибку с вероятностью 99% найдет тот кто ее сделал. До коммита. Ибо куча тестов покраснеет.
В худшем случае первый же тестер.
Соответственно будет известно, в какой правке ошибка.
Цена исправления минимальна.
Твой КО.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: AC>>Предположим, есть проект на N2, большой, много DSL, много участников. Были внесены изменения в один из DSL,ошибка проявилась по всему проекту. Какова цена исправления ошибки с сохранением изменений(по сравнению с использованием библиотек)? WH>По всему проекту? WH>Замечательно. WH>Эту ошибку с вероятностью 99% найдет тот кто ее сделал. До коммита. Ибо куча тестов покраснеет. WH>В худшем случае первый же тестер. WH>Соответственно будет известно, в какой правке ошибка.
Ok.
WH>Цена исправления минимальна.
Возможно ты имел ввиду цену поиска(выявления) ошибки?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
WH>>Цена исправления минимальна. AC>Возможно ты имел ввиду цену поиска(выявления) ошибки?
Нет. Если ошибка найдена в тот же момент, когда ее посадили, цена ее исправления минимальна.
Ибо все данные об изменениях еще в кэше головного мозга разработчика.
Такие ошибки обычно правятся, не приходя в сознание.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: AC>>Возможно ты имел ввиду цену поиска(выявления) ошибки? WH>Нет. Если ошибка найдена в тот же момент, когда ее посадили, цена ее исправления минимальна. WH>Ибо все данные об изменениях еще в кэше головного мозга разработчика.
Об изменениях им внесённых, да. Об том почему внесённые им изменения дают ошибку вне его части кода, и как это исправить, нет.
И вот что ему делать, изменения необходимо внести, но это приводит к множеству ошибок в других местах? Как узнать что и как исправлять?
Ещё сценарий:
Тот же проект, на это раз изменение семантике одного из DSL, например незначительные изменение в логике работы какого ни будь оператора(с целью рефакторинга к примеру).
Всё собралось без ошибок. Всё работает, кроме некоторых кусков кода, программисты которых не любят внимательно читать документацию и/или предпочитают использовать метод научного тыка.
То есть высока вероятность возникновения сайдэфектов(вроде тех что возникают из-за глобальных переменных).
Как ты планируешь с подобным "бороться"?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Об изменениях им внесённых, да. Об том почему внесённые им изменения дают ошибку вне его части кода, и как это исправить, нет. AC>И вот что ему делать, изменения необходимо внести, но это приводит к множеству ошибок в других местах? Как узнать что и как исправлять?
Точно так же как и с любым другим кодом.
Садится и анализирует что сломалось.
После чего чинит.
Не понимаю в чем ты видишь трудности.
AC>Ещё сценарий: AC>Тот же проект, на это раз изменение семантике одного из DSL, например незначительные изменение в логике работы какого ни будь оператора(с целью рефакторинга к примеру). AC>Всё собралось без ошибок. Всё работает, кроме некоторых кусков кода, программисты которых не любят внимательно читать документацию и/или предпочитают использовать метод научного тыка. AC>Как ты планируешь с подобным "бороться"?
То же самое можно сказать про библиотечный код.
Но в случае с ДСЛ при обнаружении таких проблем можно сделать анализатор кода который на все места не правильного использования выдаст ошибку или предупреждение.
С библиотекой такой фокус не пройдет.
AC>То есть высока вероятность возникновения сайдэфектов(вроде тех что возникают из-за глобальных переменных).
Ничего общего.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Точно так же как и с любым другим кодом. WH>Садится и анализирует что сломалось. WH>После чего чинит. WH>Не понимаю в чем ты видишь трудности.
В том что анализировать придётся генерированный код, который будет мягко говоря путаным(из-за концепции N2 "не важно во что оно скомпилируется" и эволюции).
WH>То же самое можно сказать про библиотечный код. WH>Но в случае с ДСЛ при обнаружении таких проблем можно сделать анализатор кода который на все места не правильного использования выдаст ошибку или предупреждение. WH>С библиотекой такой фокус не пройдет.
Библиотеки можно тестировать, что трудней писать(тесты или анализатор)не знаю, спорить не буду. Подумай, может быть есть решение лучше.
AC>>То есть высока вероятность возникновения сайдэфектов(вроде тех что возникают из-за глобальных переменных). WH>Ничего общего.
Изменения в одном DSL влияют на другие DSL основанные на/использующие первый(как изменение глобальной переменной влияет на результат функций её использующих), разве это не побочные эфекты.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>В том что анализировать придётся генерированный код, который будет мягко говоря путаным(из-за концепции N2 "не важно во что оно скомпилируется" и эволюции).
Это не так сложно как ты думаешь.
Поверь тому, кто его анализировал.
В любом случае обычно сразу ясно, где косяк. Даже не заглядывая в генерируемый код.
AC>Библиотеки можно тестировать, что трудней писать(тесты или анализатор)не знаю, спорить не буду. Подумай, может быть есть решение лучше.
ДСЛи точно так же можно тестировать.
Но кроме тестов можно еще и анализ написать который бует проверять код который пишет пользователь ДСЛ.
Библиотеки такое не могут.
AC>Изменения в одном DSL влияют на другие DSL основанные на/использующие первый(как изменение глобальной переменной влияет на результат функций её использующих), разве это не побочные эфекты.
Изменения в одной библиотеке влияют на другие библиотеки, основанные на/использующие первую (как изменение глобальной переменной влияет на результат функций её использующих), разве это не побочные эффекты.
Пожалуйста, не путай зависимость одного кода от другого и глобальное состояние.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Это не так сложно как ты думаешь. WH>Поверь тому, кто его анализировал. WH>В любом случае обычно сразу ясно, где косяк. Даже не заглядывая в генерируемый код.
Допилите — узнаем
AC>>Изменения в одном DSL влияют на другие DSL основанные на/использующие первый(как изменение глобальной переменной влияет на результат функций её использующих), разве это не побочные эфекты. WH>Пожалуйста, не путай зависимость одного кода от другого и глобальное состояние.
D'oh
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, vdimas, Вы писали:
T>>Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ? Я вот не смог объяснить, потому там и по сей день string.split.
V>Если объемы данных невелики, то пойдет string.split, если же велики — то только оперативная обработка.
Именно из за объемов данных был выбран string.split, поскольку он рвёт любой другой парсер в хлам.
"оперативная обработка" — я не понял этот термин — если это полноценный парсер, то он нужен только в том случае, если не хватит возможностей string.split. Даже так — если проблемы со string.split превысят определенный порог.
Здравствуйте, AndrewVK, Вы писали:
T>>Тут самое интересное начинается. Есть ДСЛ для организации всяких импортов ?
AVK>По странному стечению обстоятельств мне в ближайшее время предстоит спроектировать такой DSL.
Здравствуйте, FragMent, Вы писали:
FM>В графическом виде ты получишь: FM>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а FM>2. Отсутствие diff FM>3. Отсутствие version control FM>4. Сотни связей для сложного блока. FM>5. Слабую интеоперабельность между различными тулзами (только не надо про edif )
По-моему, ты таки путаешь графический дизайн с неизвестным внутренним представлением с дизайном с известным, текстовым, но с адаптацией под графические средства. Например, в описание объекта могут входить желаемые экранные координаты, номер слоя, и тому подобное.
Я не работал плотно с САПР и не знаю, делает ли такое кто-то, но теоретически оно беспроблемно допустимо.
А что плохого в сотнях связей для сложного блока, если он действительно сложный?
FM>Повторюсь. Цифровая схемотехника очень быстро упёрлась в ограничение графического представления и в настоящий момент полностью перешла на текстовый формат.
Они друг другу не противоречат.
FM>Аналоговый дизайн еще использует графическое представление, но активно исследует возможности ухода от него.
Вопрос, наверно, больше в выборе оптимального для всех САПР стандарта описания? Каждое конкретное запихнуть в текст будет несложно.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, FragMent, Вы писали:
FM>>В графическом виде ты получишь: FM>>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а FM>>2. Отсутствие diff FM>>3. Отсутствие version control FM>>4. Сотни связей для сложного блока. FM>>5. Слабую интеоперабельность между различными тулзами (только не надо про edif )
N>По-моему, ты таки путаешь графический дизайн с неизвестным внутренним представлением с дизайном с известным, текстовым, но с адаптацией под графические средства. Например, в описание объекта могут входить желаемые экранные координаты, номер слоя, и тому подобное. N>Я не работал плотно с САПР и не знаю, делает ли такое кто-то, но теоретически оно беспроблемно допустимо.
Нет, не путаю. Просто перечислил возможные проблемы. Их можно разделить на две группы.
1. Проблема формата хранения схемы (п. 1, 2, 3, 5)
2. Проблема работы с графическим представлением (п. 4).
N>Например, в описание объекта могут входить желаемые экранные координаты, номер слоя, и тому подобное. N>Я не работал плотно с САПР и не знаю, делает ли такое кто-то, но теоретически оно беспроблемно допустимо.
В теории — да. А на практике получается следующее. Имеется некая схема, тебе нужно вставить новый блок между старыми.
Для этого придется раздвинуть старые блоки, разместить новый символ, изменить соединения, если между старыми блоками еще остались связи, провести их мимо нового блока. В результате любая система version control не будет иметь смысла, поскольку за изменениями визуального представления не видно сути. N>А что плохого в сотнях связей для сложного блока, если он действительно сложный?
1. Та же самая ситуация со вставкой нового блока. Раздвигаем старые блоки и случайно закорачиваем две из сотен связей. Очень легко упустить этот момент, особенно если у связей нету имен.
2. Допустим есть глобальная связь, которая идет во множество блоков (например какой-нибудь clock). Нужно проверить все входы к которым эта связь подключена. В текстовом варианте, ты запускаешь поиск по файлам и легко видишь все вхождения. В графическом режиме ты подсвечиваешь нужную связь и обнаруживаешь, что она представляет собой ломанную линию с множеством ответвлений.
Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.
FM>>Повторюсь. Цифровая схемотехника очень быстро упёрлась в ограничение графического представления и в настоящий момент полностью перешла на текстовый формат.
N>Они друг другу не противоречат.
Не противоречат, но по факту в современной цифровой схемотехнике используют vhdl, verilog, а не schematic capture.
Все что я выше описывал — это поиск причин post factum. Как только появилась возможность синтезировать схемы из HDLs,
цифровики стройными рядами двинулись в этом направлении.
FM>>Аналоговый дизайн еще использует графическое представление, но активно исследует возможности ухода от него.
N>Вопрос, наверно, больше в выборе оптимального для всех САПР стандарта описания? Каждое конкретное запихнуть в текст будет несложно.
Нет. Чуть выше в том посте я описал, что имею в виду (синтез аналоговых схем из формул и язык verilog-a (не путать c verilog) для моделирования
аналоговых блоков на более высоком уровне).
А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая).
Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.
P.S. Я не противник графического представления. Более того, мне с графикой приходится работать больше, чем с текстом. Просто vdimas выбрал не очень удачный пример для демонстрации преимуществ графического dsl.
Здравствуйте, VladD2, Вы писали:
VD>Берем книгу дракона, глядим... Ба да там ни TDOP Пратта, ни PEG Форда нет. Ну, с PEG еще можно понять. Ему не так много лет (хотя базе уже лет 40, не меньше). Но TDOP — это 1974 год.
VD>А где доценты материал для курсов берут? Да из кнжек, что купили на Озоне, и из того пиара, что валит из-за всех дыр.
Конспироложество в чистом виде. Доцент не берет материал, ему ставят задачу, какой материал читать студентам. Т.е. Грамматики, BNF + LR-парсеры. Всё, приехали, у доцента выбора нет.
Почему доценту ставят такую задачу. Надо понимать, что такое система образования. В этом частном аспекте она работает таким образом — если широко используется скажем gcc, то студентов нужно готовить таким образом, что бы они понимали весь мат-бекграунд который стоит за gcc.
То есть, обязательный минимум именно этот бекграунд. То есть, внимание — не конкретные алгоритмы, методики, техники — а весь матбекграунд.
Абсолютно такой же подход например с случае с высшей математикой — конкретный инженер не использует 95% знаний которые даются в вузовском курсе. Но это вовсе не значит, что не надо давать эти 95% процентов.
В этой математике есть точно такие же как ты, которые орут, что де не надо давать весь этот мусор, дескать достаточно научить студента считать интеграл или преобразования фурье конкретным методом.
Теперь про TDOP пратта.
Для него нет необходимости делать специальные курсы и тд — любой студент, который освоил обычный top down и operator precedence сможет освоить и Пратта без каких либо эксцессов. И то и другое есть в книге дракона. Математика она вообще разивается в отрыве от прикладных областей, на то она и математика.
Здравствуйте, fmiracle, Вы писали:
T>>Так и думают теоретики. Практики понимают, что задача сводится к импорту данных кастомера и импортируют даже ничего не зная про CSV. Собтсвенно string.split это однозначно доказывает.
F>Ну да. Ничего не зная про некоторый формат Х, они делают импорт из другого формата, лишь частично совпадающего с указанным, и гордо называют это "импорт из Х".
Идейка гораздо проще — парсинг в импорте дело однозначно второстепенное. Самое главное это сам импорт, это просто чудовищный workflow по трудозатратам и важности он на порядки превосходит парсинг.
Здравствуйте, VladD2, Вы писали:
AVK>>Да без проблем могу привести. Только непонятно, чем это тебе поможет...
VD>Это уже лучше. Только это все еще очень поверхностное описание интерефейса модели. А нужна конкретика. Опиши зачем нужны эти сущности. Каковы между ними связи...
Да какая фиг разница? У разных сущностей разные связи. В системах учета предприятий гвоздем является документ (даже если для него нет соотв. твердой копии). Документ описывает "исходник" некоей бизнес-операции. Система выполняет вычисления по внутренним регистрам на основании "исходников". Связь м/у регистрами и первичкой в общем случае многие ко многим. Самые популярные связи в самих документах — это master-detail, где реляция 1:oo, master предствляет из себя сам документ и к нему один или несколько списков detail. Но точно такая же связь со справочными данными рассматривается уже как просто отсылка к справочнику, а не master-detail. Связи м/у документами — аналогично, это просто связи, от 1(null):1(null) вплоть до oo:oo. Пожалуй, на этом особенности бизнес-логик, пляшущих от документов, заканчиваются. Остальное вполне стандартное, присущее не только системам с эмуляцией документооборота: необходимо реляционную модель в базе выворачивать "наоборот" в граф объектов, чтобы получать навигационную ОО-модель из реляционной.
VD>Ну, и в двух словах опиши что же делала та замечательная простыня кода. Ведь она явно делала что-то не сложное. Да? Там что-то откуда-то удалялось. Вот и объясни: что, откуда, зачем и по каким правилам.
Абсолютно неважно. Там просто навигация по связанным объектам, проверка бизнес-условий, выборка во временные коллекции для следующего этапа алгоритма и т.д. Ничего военного технологически и ничего интересного с прикладной т.з. В итоге, кол-во интересующих операций — ровно 4: CRUD. Остальные прикладные операции — это просто операции более высокого уровня на основе базовых.
Здравствуйте, AndrewVK, Вы писали:
AVK>Дернуть из конфигурации 1С код — будет примерно то же самое.
Не совсем. Я точно такой же код предпочитал писать на VB, чтобы не приводить к типизированным интерфейсам. Код получался немного чище. В этом смысле VB — неплохой DSL. ))
Аналогично язык 1С.
Здравствуйте, Tanker, Вы писали:
T>Именно из за объемов данных был выбран string.split, поскольку он рвёт любой другой парсер в хлам.
Это не совсем так. Вот что сам МС пишет:
Performance Considerations
The Split methods allocate memory for the returned array object and a String object for each array element. If your application requires optimal performance or if managing memory allocation is critical in your application, consider using the IndexOf or IndexOfAny method, and optionally the Compare method, to locate a substring within a string.
If you are splitting a string at a separator character, use the IndexOf or IndexOfAny method to locate a separator character in the string. If you are splitting a string at a separator string, use the IndexOf or IndexOfAny method to locate the first character of the separator string. Then use the Compare method to determine whether the characters after that first character are equal to the remaining characters of the separator string.
In addition, if the same set of characters is used to split strings in multiple Split method calls, consider creating a single array and referencing it in each method call. This significantly reduces the additional overhead of each method call.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, FragMent, Вы писали:
V>>А взять сложную схему с многообразием технологий (а не только одну булевскую логику)... я с трудом представляю как разбираться в принципиальной схеме без графического представления. Ты банально не поймешь принцип работы схемы, если там кол-во элементов перевалит за единицы десятков. Если же я не прав, просьба привести примеры, где бы в тексте разнообразная электроника смотрелась бы лучше. (Может я и не прав и сильно отстал за последние годы, когда уже не занимаюсь этим). FM>Ну вот посмотри скриншот схемы, сгенерированной из верилога. Слишком много связей и понять, что происходит, сложно. А ведь это еще не самый тяжелый случай.
Ну вижу много связей. Вижу лишь слабость инструмента. Почему не произведено группрование связей по шинам? ТАм будет всего 2-3 шины (разрешение скриншота не позволяет сказать точно), и порядка десятка отдельных управляющих концов. полнейший примитив, если правильно представить в графике. Сложные схемы начинаются от полусотни цифровых и от несколькьких сотен аналоговых элементов и от десятков шин.
Кстати, а можно посмотреть на соответствующий этой схеме исходный код?
V>>Одна цифровая логика? FM>Да, учитывая что цифра сейчас самый распространенный тип дизайна.
Учитывая распространенность мобильных, обычных проводных сетевых технологий, встроенных жжидкокристаллических и т.д. — ты сильно заблуждаешься. Просто тебе из подвала не видно.
FM>>>С аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты.
V>>Есть примеры достаточно сложных схем в текстовом виде с адаптивными фильтрами, умножителями (сигналов и частот), ФАПЧ и т.д.? FM>Странно, что тебя нужно убеждать, что декларативное лучше императивного FM>Из чего больше понятно, что происходит с сигналом? FM>Из формулы или из схемы?
Я бы взял чуть другую схему для бОльшей добротности, но не суть.
FM>И если будет нормальный инструмент позволяющий переводить формулы в схемы с гибкой настройкой конфигурации (тип фильтра, power/area/noise margin etc) с учетом используемой технологии, то вполне им вполне можно будет пользоваться для ускорения дизайна.
Можно. Но только в узких рамках заранее заготовленных кирпичиков, увы. Точно так же как в графике можно строить на заранее заготовленных кирпичиках. Но если их не хватает — определять их самим. Покажи мне как в тексте определить свой, достаточно сложный кирпичик? Я уже 3-й пост подряд прошу показать пример на языке для аналоговых схем.
FM>В графическом виде ты получишь: FM>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а
Для того и существуют взаимные экспорты в разные популярные форматы.
FM>2. Отсутствие diff
Почти все форматы таки текстовые и даже вполне читабельные.
FM>3. Отсутствие version control
См. предыдущий пункт.
FM>4. Сотни связей для сложного блока.
Это от неумения готовить графику. Пример тут показывает это неумение: http://svenand.blogdrive.com/archive/16.html
Вместо трех шин развели обычную грязь. Такая же грязь будет в коде.
FM>5. Слабую интеоперабельность между различными тулзами (только не надо про edif )
Это у тебя опять же от незнания. Давно устоялось относительно малое число стандартов файлов в этой области.
FM>Повторюсь. Цифровая схемотехника очень быстро упёрлась в ограничение графического представления и в настоящий момент полностью перешла на текстовый формат.
Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто.
FM>Аналоговый дизайн еще использует графическое представление, но активно исследует возможности ухода от него. У меня половина блоков имеют дополнительное описание на аналоговом варианте HDL под названием verilog-a (очень удобно для ускорения моделирования).
Я таки не увидел для сравнения соответствующую аналоговую схему и текстовое описание, чтобы можно было всерьез сравнивать.
Здравствуйте, FragMent, Вы писали:
FM>Для этого придется раздвинуть старые блоки, разместить новый символ, изменить соединения, если между старыми блоками еще остались связи, провести их мимо нового блока. В результате любая система version control не будет иметь смысла, поскольку за изменениями визуального представления не видно сути.
Суть см. по нетлисту.
N>>А что плохого в сотнях связей для сложного блока, если он действительно сложный? FM>1. Та же самая ситуация со вставкой нового блока. Раздвигаем старые блоки и случайно закорачиваем две из сотен связей. Очень легко упустить этот момент, особенно если у связей нету имен.
Для этого надо двигать элементы из режима прокладки связей, что есть "сам себе злобный буратино". Иначе их закоротить никак. Ну и после трассировки выдаст ошибку, не боись.
FM>2. Допустим есть глобальная связь, которая идет во множество блоков (например какой-нибудь clock). Нужно проверить все входы к которым эта связь подключена. В текстовом варианте, ты запускаешь поиск по файлам и легко видишь все вхождения. В графическом режиме ты подсвечиваешь нужную связь и обнаруживаешь, что она представляет собой ломанную линию с множеством ответвлений.
А всего-то надо попросить вывести список всех пинов всех компонент, подключенных туда. Это многократно удобнее поиска по всем файлам.
FM>Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.
Враки.
N>>Они друг другу не противоречат. FM>Не противоречат, но по факту в современной цифровой схемотехнике используют vhdl, verilog, а не schematic capture.
Это если цифровая схемотехника "сама в себе" и собрана из готовых кирпичиков (или вентилей). А если требуется эти кирпичики разрабатывать с 0-ля — то увы.
FM>Все что я выше описывал — это поиск причин post factum. Как только появилась возможность синтезировать схемы из HDLs, FM>цифровики стройными рядами двинулись в этом направлении.
Да пожайлуйста. Для цифровых подзадач вполне пойдет. Как когда-то процессоры заменили автоматику и вместо разработки автоматики стали писать программы на процессора на других языках. Только это не отменяет этапа разработки схемы даже на основе процессора со всей требуемой обвеской, когда процессор управляет некоим реальным блоком вместо автоматики. Все-равно конечную схемы на основе процессора без графики не представить, хоть тресни. Пусть даже в нем "унутре" сколь угодно сложная программа. Даже возьми материнки современных компов или любые платы раширения. Я периодически взглядываюьс в разводку и расположение и могу тебя заверить, что там ручками доводилось обязательно как первое, так и второе. Но в тексте это на сегодня невозможно ни в одном из тулзов. Получается, что де-факто компьютерные платы таки разрабатывают в графике? Просто ты работаешь в другом направлении.
N>>Вопрос, наверно, больше в выборе оптимального для всех САПР стандарта описания? Каждое конкретное запихнуть в текст будет несложно. FM>Нет. Чуть выше в том посте я описал, что имею в виду (синтез аналоговых схем из формул и язык verilog-a (не путать c verilog) для моделирования FM>аналоговых блоков на более высоком уровне).
С аналоговыми упираемся в отображение "формул" на конкретную схему. Слово "конкретное" — ключевое. А если я хочу сами схемы пробовать/варьировать?
FM>А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая). FM>Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.
А что за САПР-ы были?
FM>P.S. Я не противник графического представления. Более того, мне с графикой приходится работать больше, чем с текстом. Просто vdimas выбрал не очень удачный пример для демонстрации преимуществ графического dsl.
Я выбрал из своего опыта. Как раз делал довольно много микропроцессорных плат и для радиосвязи и для самолетных блоков. Не вижу там даже близко сценария работы "text-only", т.к. микрпроцессор всегда чем-то управляет и от чего-то получает сигналы и полно всякой обвязки. И никто не показал пока в реальной жизни "text-only" кроме FPGA или аналогичных сугубо цифровых самодостаточных микросхем.
Но даже расположи эти сугубо цифровые схемы на плате. Пусть автоматом. Зато мы потом берем и измеряем мощность*длину/ширину питающих соединений, полученных де-факто после размещения и разводки (даже если они автоматические). Уже кое-где требуется кондеры вставлять по питанию, а кое-где увеличивать их емкость. И вот уже появляются новые элементы в схеме или меняются номиналы имеющихся, что влечет за собой изменение их размеров и заход на новую итерацию размещения и разводки. В голом тексте это вообще никак не работает.
)
