LabVIEW Portal

AndreyDmitriev писал(а):Я ни в коем случае не утверждаю, что линукс хуже, но "точка вхождения" в более-менее профессиональное пользование у этой ОС куда как выше чем у Windows, уж извините.

С этим полностью согласен, начиная работать в Linux, постоянно плевался и вспоминал DOS с его командной строкой.
Но тут речь шла о операционной системе, а при желании можно сделать сборку, интегрировав в нее и другой необходимый софт. Так что можно сказать, что будет установлено "из коробки".

По поводу плясок с бубном...
Был у меня старый добрый Dell Latitude C640, все с той же NVidia.
Ubuntu 6, пришлось уговаривать в командной строке пару дней, что бы она мне хоть что-нибудь показала. Благо это было на уровне экспериментов, а не основная ОС. Ubuntu 7.04 стала уже без проблем. С 9 версии, Ubuntu стала основной ОС, а Windows вспомогательной. С 10 версии, вообще ни каких проблем с установкой устройств не замечал, есть нюансы в подключении некоторой периферии, типа МФУ или графических планшетов. Но это уже больше исключение, чем правило, в том числе это касается и NVidia.

Да и установка сейчас организована на достаточном уровне (исключения и здесь конечно есть), в некоторых случаях даже на много удобнее чем в Windows. Особенно когда необходимы сторонние библиотеки, то могут возникнуть трудности с устранением всех зависимостей (например matcad14). В Ubuntu, как правило все устанавливается через специализированный центр или менеджер, главное знать список репозиториев, а зависимости как правило отслеживаются и подтягиваются автоматом.

Андрей

кто ясно мыслит - ясно излагает.

Мне кажется товарищи спецы, упущен из внимания тот
фактор, что механически неподвижные запоминающие устройства,
в последнее время активно вытесняют механически подвижные
магнитные и оптические, и за 5-10 лет, думаю, вытеснят совсем.
Это не может не сказаться на построении новых ОС и
новых "файловых структур" и доступа к ним
совершенно на других принципах.

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

А как же SSD?

я имел в виду, что может со временем исчезнуть
такое понятие как зарузка и загрузчик

mzu2006 писал(а): как человек зарабатывающий на жизнь и текстовым и графическим программированием скажу: однозначного ответа нет. Использование конкретной технологии определяется не только удобством (все более менее удобные), ценой или открытостью. Например, мне кажется неочевидной мотивация делать открытую систему, кладя в её основу систему с закрытым исходным кодом ( ).

Си вроде как то же закрыт, если быть точнее: компилятор и библиотеки (правда не все), то же самое и с ЛВ. Так в чем же разница???

gcc и GNU libc полностью открыты + существует ANSI С/С++ стандарт на код. Этим постом я хотел скорее показать призрачность мотивации ОП.

> я имел в виду, что может со временем исчезнуть такое понятие как зарузка и загрузчик

Любопытное предположение. Я, кстати, выше неправильно понял кто кого вытесняет.

mzu2006 писал(а):gcc и GNU libc полностью открыты + существует ANSI С/С++ стандарт на код. Этим постом я хотел скорее показать призрачность мотивации ОП.

гцц - это отдельная песня. стандарт анси си тут вообще не причем. Расшифруй.

А объясните смысл данного ядра? То есть оно поддерживает ФС, драйвера(сеть, звук, видео) и всё на LabVIEW писать будите? Не лучше бы написать LabVIEW интерпретатор для какой либо ОС, можно даже на уровне модуля ядра это сделать на примере linux?

Данил писал(а):А объясните смысл данного ядра? То есть оно поддерживает ФС, драйвера(сеть, звук, видео) и всё на LabVIEW писать будите? Не лучше бы написать LabVIEW интерпретатор для какой либо ОС, можно даже на уровне модуля ядра это сделать на примере linux?

1. Смысл верный.
2. А что делать потом с интерпретатором?

3. Думаю над следующими инструментами:
А. Конвертер С -> G
Си-шные файлы обрабатываются, снимается конструкция программы, по которой затем, создаются VI-шки посредством VI Script.
Естественно, на первых порах конвертер будет не идеален и автоматизирован слабо. Но чтоб более эффективно понять что делает С код будет достаточно.
Б. Компилятор G
Что является компилятором и где в файлах он размещается? Сам "LabVIEW.exe" или какие-нибудь библиотеки отсюда: "..\LabVIEW 20,,\resource\" ?
Замечал что в штатных Vi есть функция Call Library Function со ссылкой "LabVIEW": Про компилятор что-то написано здесь http://www.labviewportal.org/viewtopic.php?f=87&t=5877
Есть ещё получается виртуальная машина LLVM. Где она в файлах? Или это правильнее рассматривать как единое целое LLVM?
Описание LLVM: http://habrahabr.ru/post/47878/ https://ru.wikipedia.org/wiki/Low_Level_Virtual_Machine

4. Кто-нибудь может описать архитектуру среды разработки, назначение директорий и файлов LabVIEW? Кто что знает.
Состав LV: 4.1) Компилятор, 4.2) LLVM, 4.3) редактора диаграмм и панелей, 4.4) RunTimeEngine, ...

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

6. Выкладывала ли NI когда-нибудь свои исходники LabVIEW (части исходников)?

7. Linux. Может быть у кого-нибудь возникала идея собирать и контролировать сборку ОС, состав и конфигурацию модулей, управлять процессом компиляции с помощью LabVIEW?
Далее можно было бы двигаться дальше: создавать модули в LabVIEW и прикручивать их к ОС. Постепенно приближаться к идее переписывать родные компоненты ОС, что бы придти к той же ОС только "пропущенной" через LabVIEW - не без вставок кода других языков.

Данил писал(а):Доброго всем дня.
Подумал над такой не сложной вещью, как написать свой компилятор своего языка, похожего на G, называть пока его как-то не берусь. Идея следующая, превращать графически представленную программу в код gnuc.

PeyNikola писал(а): 3. Думаю над следующими инструментами:
А. Конвертер С -> G
Си-шные файлы обрабатываются, снимается конструкция программы, по которой затем, создаются VI-шки посредством VI Script.
Естественно, на первых порах конвертер будет не идеален и автоматизирован слабо. Но чтоб более эффективно понять что делает С код будет достаточно.
Б. Компилятор G

Коллеги, да вы просто нашли друг друга!

Какой смысл от твоего сообщения? если он на форуме фигурирует и я отвечаю после него в данной теме?

PeyNikola писал(а):Какой смысл от твоего сообщения? если он на форуме фигурирует и я отвечаю после него в данной теме?

Это как бы намёк на то, что вы оба нашли довольно странные точки приложения своих усилий - один из вас хочет написать компилятор C->G, а второй G->C. Уже одно это - забавно.
Оба эти проекта - довольно неслабые сами по себе (даже если оставить в стороне ОС).
Однако знания ваши представляются мне весьма поверхностными (я могу судить об этом лишь косвенно по фразам типа "Замечал что в штатных Vi есть функция Call Library Function со ссылкой "LabVIEW"") и недостаточными для качественной проработки хотя бы спецификации (не говоря уже об архитектуре) проекта подобного масштаба.
Если это не так и у вас просто такой стиль изложения мыслей и вопросов, то извините заранее.

PeyNikola Сегодня, 02:49
Естественно, на первых порах конвертер будет не идеален и автоматизирован слабо. Но чтоб более эффективно понять что делает С код будет достаточно.

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

PeyNikola Сегодня, 03:22
Какой смысл от твоего сообщения? если он на форуме фигурирует и я отвечаю после него в данной теме?

Я Вам встречный вопрос задам: Какой смысл от данной темы?
Получается примерно так: "У меня есть идея создать транслятор С->G!Какие предложения по реализации???".
Пока у Вас всё на уровне сырой идеи.Больше демагогии,чем дела. Сделайте небольшой шаг самостоятельно. Продемонстрируйте транслятор С-G на самой простой программе(один цикл с парочкой мат.операций).Вы же предложили реализацию транслятора:
Си-шные файлы обрабатываются, снимается конструкция программы, по которой затем, создаются VI-шки посредством VI Script.
Тогда будет пища для обсуждения - а пока вилами по воде писано.