ЯДРО на LabVIEW (описание)

Делись идеей, получай поддержку и критику!
AndreyDmitriev

Activity Professionalism Tutorials Gold Black
VIP
VIP
Сообщения: 1326
Зарегистрирован: 03 фев 2010, 00:42
Награды: 6
Версия LabVIEW: 6.1 - 2024
Откуда: Германия
Благодарил (а): 1 раз
Поблагодарили: 36 раз
Контактная информация:

Re: ЯДРО на LabVIEW (описание)

Сообщение AndreyDmitriev »

Vitekkz88 писал(а):
PeyNikola Сегодня, 02:49
Естественно, на первых порах конвертер будет не идеален и автоматизирован слабо. Но чтоб более эффективно понять что делает С код будет достаточно.
И на первых и на вторых и на десятых порах.Лет 10 до ума доводить будете,дай бог чтоб справились.
Для кого инструмент предназначен?Кого Вы видите в качестве конечного пользователя?
Про эффективное понимание Си-кода: если это будут проекты типа "Hello World!" либо простая сортировка или несложный алгоритм поиска элементов - то тут может что-то получиться. Отнюдь, Си-шные проекты более объемные,обилие mutex-ов и функций работы с памятью. Вот такие проекты имеет смысл представлять структурно. Какие у Вас идеи на этот счет?
Я так полагаю, PeyNikola делает это с прицелом взять исходники Линукса и прогнать их через конвертер, чтобы получить графический код с сэкономить кучу времени.
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5458
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: ЯДРО на LabVIEW (описание)

Сообщение IvanLis »

Я лет 10 назад занимался синтаксическим анализом и разбором Pascal-е подобных языков.
Но у меня цели иные были, нужно было представить ПО в виде графа и рассчитать значения качественных показателей при наличии исходников.
И то там много различных заморочек было, но какой ни какой результат был получен, правда реальные проекты парсились минутами.
1.jpg
2.jpg
4.jpg
3.jpg
Я в плане того, что ничего нереального нет, все зависит от затраченного ресурса.
Аватара пользователя
Vitekkz88

Activity Silver Автор
expert
expert
Сообщения: 1100
Зарегистрирован: 21 янв 2014, 15:45
Награды: 3
Версия LabVIEW: 12,13,14
Откуда: Томск
Контактная информация:

Re: ЯДРО на LabVIEW (описание)

Сообщение Vitekkz88 »

AndreyDmitriev 8 минут назад
Я так полагаю, PeyNikola делает это с прицелом взять исходники Линукса и прогнать их через конвертер, чтобы получить графический код с сэкономить кучу времени.
Вспомнился мне отрывок из "12 стульев",когда Остап в д.Васюки про шахматные турниры рассказывал.
Смотрите сами:
Проекты аналогичны по амбициозности,время-затратам и конечным результатам.Но,как справедливо заметил IvanLis,
ничего нереального нет, все зависит от затраченного ресурса.
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
AndreyDmitriev

Activity Professionalism Tutorials Gold Black
VIP
VIP
Сообщения: 1326
Зарегистрирован: 03 фев 2010, 00:42
Награды: 6
Версия LabVIEW: 6.1 - 2024
Откуда: Германия
Благодарил (а): 1 раз
Поблагодарили: 36 раз
Контактная информация:

Re: ЯДРО на LabVIEW (описание)

Сообщение AndreyDmitriev »

Vitekkz88 писал(а):
AndreyDmitriev 8 минут назад
Я так полагаю, PeyNikola делает это с прицелом взять исходники Линукса и прогнать их через конвертер, чтобы получить графический код с сэкономить кучу времени.
Вспомнился мне отрывок из "12 стульев",когда Остап в д.Васюки про шахматные турниры рассказывал.
Смотрите сами:
Проекты аналогичны по амбициозности,время-затратам и конечным результатам.И,как справедливо заметил IvanLis,
ничего нереального нет, все зависит от затраченного ресурса.
Это так, но в данном случае если всё делать в одиночку, то и жизни может не хватить.
Можно, кстати, написать Линусу Торвальдсу и пообщаться с ним на эту тему. Он по крайней мере одну систему написал, и может посоветовать что-нибудь дельное (впрочем может и просто послать - он довольно жёсткий в общении бывает)

Ещё следует поразмышлять, почему собственно линукс написан не на плюсплюсах. Почитайте вот здесь.

В очень далёком будущем, я верю, операционные системы будут разрабатываться на визуальных языках, которые постепенно вытеснят текстовые (лет 50-70 точно пройдёт, а может и все сто). Ну а пока надо довольствоваться тем что есть. Вначале визуальный язык должен стать языком общего назначения пригодным для написания ОС. Если вы попытаетсь вначале разработать язык, а потом ОС, то план этот практически утопический - вам нужна команда, сравнимая с командой NI (или больше) и много лет работы.
Аватара пользователя
Vitekkz88

Activity Silver Автор
expert
expert
Сообщения: 1100
Зарегистрирован: 21 янв 2014, 15:45
Награды: 3
Версия LabVIEW: 12,13,14
Откуда: Томск
Контактная информация:

Re: ЯДРО на LabVIEW (описание)

Сообщение Vitekkz88 »

AndreyDmitriev 3 минуты назад
...если всё делать в одиночку, то и жизни может не хватить...
...нужна команда, сравнимая с командой NI (или больше) и много лет работы.
Эти истинны автору на заметку.
Я уже приводил пример с Simulik,повторюсь еще раз:
Vitekkz88 21 окт 2014, 20:48
в Simulink(графическое дополнение к MatLAB),по-моему с 2008-го года, есть встроенный HDL-кодер. Казалось бы - это крутая примочка для ПЛИС-разработчиков.А вот не такая уж и крутая на самом деле. Не знаю ни одного разработчика ПЛИС,который рисует серьезный проект в Simulink,генерит код(описание) по модели и с успехом заливает всё это дело в кристалл. Какие-то отдельные части проекта можно так сделать...да и то,эти части ручками на VHDL проще самому написать. И по сей день MathWork пилят этот кодер и допиливают,чтобы мог Simulink-модель более-менее адекватно и оптимально транслировать в VHDL-код. Очень сомневаюсь,что в MathWork над такой задачей новатор-энтузиаст работает.
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
AndreyDmitriev

Activity Professionalism Tutorials Gold Black
VIP
VIP
Сообщения: 1326
Зарегистрирован: 03 фев 2010, 00:42
Награды: 6
Версия LabVIEW: 6.1 - 2024
Откуда: Германия
Благодарил (а): 1 раз
Поблагодарили: 36 раз
Контактная информация:

Re: ЯДРО на LabVIEW (описание)

Сообщение AndreyDmitriev »

IvanLis писал(а):Я лет 10 назад занимался синтаксическим анализом и разбором Pascal-е подобных языков.
Но у меня цели иные были, нужно было представить ПО в виде графа и рассчитать значения качественных показателей при наличии исходников.
О, дискуссия возвращается в нормальное русло.
У меня вот какой вопрос - как по вашему мнению (прежде чем я достану с полки VI Analyser toolkit)-должны ли параллельные конструкции увеличивать цикломатическую сложность инструмента? С одной стороны вроде как не должны, но если рассматривать цикломатическую сложность как интегральный показатель сложности, то вроде как должны.
Какова будет общая цикломатическая сложность, если мы имеем две вот такие конструкции:
Изображение
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5458
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: ЯДРО на LabVIEW (описание)

Сообщение IvanLis »

Все это формальные оценки и не всегда отражают действительности.
Это примерно как оценивать труд программиста по количеству строк написанного текста :crazy: .
(мы вообще ничего не заработаем :haha: )
AndreyDmitriev писал(а):должны ли параллельные конструкции увеличивать цикломатическую сложность инструмента? С одной стороны вроде как не должны, но если рассматривать цикломатическую сложность как интегральный показатель сложности, то вроде как должны.
Должны, даже по математике получается, что добавление одного узла в граф, тянет за собой два ребра. А соответственно цикломатическая сложность возрастет на 1.
И чем больше связей (ребер), тем показатель выше.
AndreyDmitriev писал(а):Какова будет общая цикломатическая сложность, если мы имеем две вот такие конструкции
По логике 8, но это при условии, что графы не имеют совместных истока и стока (начала и конца).
AndreyDmitriev

Activity Professionalism Tutorials Gold Black
VIP
VIP
Сообщения: 1326
Зарегистрирован: 03 фев 2010, 00:42
Награды: 6
Версия LabVIEW: 6.1 - 2024
Откуда: Германия
Благодарил (а): 1 раз
Поблагодарили: 36 раз
Контактная информация:

Re: ЯДРО на LabVIEW (описание)

Сообщение AndreyDmitriev »

IvanLis писал(а):Все это формальные оценки и не всегда отражают действительности.
Это примерно как оценивать труд программиста по количеству строк написанного текста :crazy: .
Зато можно меряться цикломатической сложностью :D

Я на досуге проверю в анализаторе - что он там считает. Я тоже за сложение.

Я это к тому, что мне так кажется, что в Лабвью можно вполне комфортно работать с повышенной цикломатической сложностью. Учебник учит, что если цикломатическая сложность какого-либо модуля возрастает выше определённой величины, то надо разделять модули на более мелкие. (Мак-Кейб: Для каждого модуля, либо ограничивай цикломатическую сложность до оговоренного предела, либо предоставляй запись, поясняющую, почему ограничение должно быть превышено.) В текстовых языках роекомендуется ограничить сложность до 10-15. Любопытно посмотреть на лабвьюшные инструменты, которые имеют такую сложность или выше - насколько комфортно с ними работать. Взять даже пример выше - даже если у нас будет четыре подобные конструкции в инструменте - это вполне нормальный пример, а вот сложность уже будет аж 16.
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5458
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: ЯДРО на LabVIEW (описание)

Сообщение IvanLis »

AndreyDmitriev писал(а):В текстовых языках роекомендуется ограничить сложность до 10-15. Любопытно посмотреть на лабвьюшные инструменты, которые имеют такую сложность или выше - насколько комфортно с ними работать. Взять даже пример выше - даже если у нас будет четыре подобные конструкции в инструменте - это вполне нормальный пример, а вот сложность уже будет аж 16.
В текстовых языках как правило потоки, выполняющиеся параллельно, разносят в разные модули (иначе вообще не разберешься), что снижает сложность.
В LabVIEW, в силу компактности и наглядности, наоборот удобнее все держать на одной БД. А это сразу увеличивает цикломатическую сложность.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Проекты»