Metaprog: универсальная графическая среда программирования [в разработке] часть 6

Си и Метапрог с сишным бекендом хороши тем, что поначалу можно тяп-ляп, а потом уж довести до совершенства. А когда сишных возможностей перестанет хватать - обращаться к ассемблеру и тогда ограничения будут только на уровне железа.

Кстати, пример с теми диаграмками берет 120 мегабайт оперативки. Немало.

Как думаешь, гтк стоит юзать дополнительно? Фигня в том, что гтк требует вызова gtk_main и как это вязать с нуклеаром...

ну были и что. ты же понимаешь почему не имеет смысла печатать некий научный труд большими крупными буквами с красочными картинками что бы каждый новичок в чтении из детского сада смог его прочитать. почему же при написании ПО специалисты должны думать о том что бы его исходники могли прочитать школьники не осилившие даже K&R.

Это должны думать специалисты, делающие среду программирования, сам концепт, а не кодеры. Конечно же, Си делался почти 50 (!) лет назад, когда даже текстовый Си был прорывом после перфокарт и ассемблеров и глупо от него ожидать простоты и понятности на уровне игрушки. Ужасает другое: что новые языки программирования и фреймворки не стремятся быть проще, чем Си. Только все сложнее и сложнее - и для программирования, и для выполнения машиной.

https://habr.com/ru/post/427181/

Ужас!

почему то ты не пишешь в этой теме текстом написанным по слогам и с расставленными ударениями в каждом слове. да как же так ты не подумал о новичках в чтении!!!! вот точно так же и программисты не подумали об игроманах. ну твои постоянные ссылки к «игрушкам» выглядят просто комично.

видимо новые языки ориентированы на скорость разработки профессионалом а не на скорость освоения игроманами не желающими изучить элементарные вещи такие как операторы C.

Какой пример? Nuklear sdl_opengles(node_editor) у меня занимает 34 мб.

Как думаешь, гтк стоит юзать дополнительно?

Нет, зачем?

Фигня в том, что гтк требует вызова gtk_main и как это вязать с нуклеаром...

Ну в начало gtk_main воткни и все, а обработку нуклера в idle каллбек, все просто. Код для nuklear вообще можно в одной функции написать, он полностью управляется.

А когда сишных возможностей перестанет хватать - обращаться к ассемблеру и тогда ограничения будут только на уровне железа.

Сейчас асм только для ускорения особых участков кода. Для поиска новых возможностей ищут новые библиотеки или пишут сами или обращаются к ядру ОС напрямую. Для любой прикладухи у си более чем достаточно возможностей. А удобство - другой разговор.

гтк стоит юзать дополнительно?

Делать рантайм таким жирным не оправдано ради ещё одного апи. Все возможности нуклеара без особых проблем можно реализовать средствами гтк. Даже можно написать обёртку чтобы работа с гткшными объектами была похожа на работу с нуклеаром. Но это дофигища работы с очень сомнительной пользой.

новые языки программирования и фреймворки не стремятся быть проще

Язык го специально сделан проще любых других промышленно используемых. Его «отец» Брайан Керниган также является «отцом» сишки. Почти все веб фреймворки гораздо проще в реальных программах, чем всё остальное. И питон с джавой реально проще для серьёзных программ, чем сишка.

Сишка - простой язык, но писать что-то серьёзное сложно. Джава - сложный язык, но писать что-то серьёзное гораздо легче. И питон, и js - аналогично. В отличие от сишки, не нужно знать всё о рантайме чтобы писать программы для реального мира.

у автора не хватит терпения изучить джаву, он KR даже не осилил а проще C я не знаю языков.

у автора не хватит терпения изучить джаву

У ТСа давно сложилось «твёрдое» мнение о джаве, никто в ближайшее время не переубедит его в выборе инструментов. Стоять на своём он умеет.

...И утешенье лишь в одном — стоять до смерти на своём...

видимо новые языки ориентированы на скорость разработки профессионалом а не на скорость освоения игроманами не желающими изучить элементарные вещи такие как операторы C.

Как же я тогда Лабвью-то освоил?

это не новый язык а мышевозье какое то проприетарное.

ты кстати можешь как то оценить объём уже сделанных работ по разработке метапрога? например в текстовом программировании можно судить по количеству строчек кода. а у тебя как то можно оценить?

в текстовом программировании я думаю за это время система уже разрослась бы до объёмов когда ты бы оценил уже по достоинству наконец ООП.

Какой пример? Nuklear sdl_opengles(node_editor) у меня занимает 34 мб.

Со старта да, потом начинает расти до 120 мб, 315 мб итд по мере добавления нод и связей (хотя конкретной причины пока не видно). Но утечки можно найти и устранить. Вот ядро Линукс пилили черти сколько - и наконец допилили до юзабельного состояния.

Как сделать чтобы окно с редактором нод было с изменяемым размером?

В нуклеаре в примерах уже есть некое подобие редактора диаграмм, а в гтк есть?

Попробую начать с просто просмотрщика диаграмм («только чтение»).

Я подумываю над тем, чтобы асинхронные колбеки и автоматическу параллелизацию выполнения потоков данных (как в Лабвью) реализовать через pthreads. Или лучше С11 threads.h? Что думаешь?

это не новый язык а мышевозье какое то проприетарное.

Это и не «язык» программирования в текстовом понимании этого слова. И плохо в Лабвью только то, что оно пропиетарное, остальные недостатки - следствие невозможности устранить их из-за закрытости кода.

в текстовом программировании можно судить по количеству строчек кода. а у тебя как то можно оценить?

10 мегабайт лабвьюшных VI-файлов, а самих файлов около 500 (это типы и функции, ими оперирующие). Некоторые диаграммы маленькие, но есть большие и несколько огромных. Приведу наглядную аналогию: если средняя функция в текстовом коде размером с автомобиль, то мои - размером от мотоцикла до авианосца.

в текстовом программировании я думаю за это время система уже разрослась бы до объёмов когда ты бы оценил уже по достоинству наконец ООП.

А в этом и вся суть. ООП действительно реально облегчает текстовое программирование, но в визуальном-то все совсем по-другому. Мне хватает типов (typedef, почти все из них - структуры или (по-лабвьюшному) «кластера») и функций, ими оперирующих, для проекта любой сложности (Метапрог - самый сложный из моих проектов). В Лабвью есть ООП с классами, но я его не использую, а когда доводится открывать проекты, использующие его - только матом крою придурастую инкапсуляцию.

Приведу наглядную аналогию: если средняя функция в текстовом коде размером с автомобиль, то мои - размером от мотоцикла до авианосца.

В текстовом коде функции-авианосцы тоже бывают, только за них нормальный программный архитектор (если он в проекте есть) потом больно бьёт по пальцам линейкой. Потому, что написать функцию — это полдела. А потом её надо сопровождать. Зачастую намнооого дольше, чем ушло на написание.

нормальный программный архитектор (если он в проекте есть) потом больно бьёт по пальцам линейкой

скорее долго стучит носом об backspace

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

inline ф-ции не всегда так хороши. при наличии большого кол-ва точек входа код разрастётся.

Чем это плохо? Больше размер бинарника и занимаемой оперативной памяти?

Хорошо что мои метапроговские функции при трансляции инлайнятся в main.

Это пока не начали массово присылать багрепорты об ошибке в функции main.

Есть много случаев, когда код не дублируется, а функции плодят для эстетики, чтобы не было «авианосцев». Но если код дублируется, то все же думаю вкрутить возможность не только инлайнить, но и делать отдельную функцию на сишном уровне. В любом случае это неизбежно из-за рекурсивных функций, которые тупо инлайнить в main нельзя. Тут лишь проблема, что в Си выход у функции только один, а в Метапроге (как в Лабвью) выходов может быть много.

Для меня Си - как для тебя ассемблер или машинный код: при условии безупречной работы транслятора все проблемы будут решаться на уровне метапроговских графических диаграмм.

Чем node->value отличается от node.value?

О, евангелист, который ратовал за язык си, оказывается, совсем не знает даже базовых основ языка си.

Нафига ты приходишь на ЛОР с вопросами по синтаксису языка? Тебя в гугле забанили, или ты просто жырный тролль?

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

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

Автор, тебе это уже говорили, но я еще раз скажу.

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

Как создаются средства разработки? Есть предметная область, есть техническая проблема. Инженер решает свою техническую проблему, а потом понимает, что это решение можно сделать общим. В процессе работы формирует какие-то практики, систематизирует их и вырабатывает концепцию: если делать так-то и так-то, то получим такой-то результат, понятный и воспроизводимый на всех уровнях.

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

Когда человек изучает свой первый язык, он думает, как же все странно и нелогично устроено. Стараясь разобраться, он читает книги и постепенно понимает, что за каждым решением стоит огромный пласт технических проблем, с которыми это решение борется. Он может захотеть написать свой язык, и взявшись за это дело, еще быстрее поймет, насколько ситуация сложна и многогранна, когда попытается выразить свои мысли в виде кода. А потом сравнит свой язык и тот язык, на котором он пишет компилятор (интерпретатор, ватэвар) и поймет, что вся затея не имеет смысла.

По мере вникания в программирования, человек решает все более сложные задачи, которые он учится декомпозировать на отдельные элементы и понимать, как они взаимосвязаны; учится описывать логику работы с ними и логику взаимодействия, что приводит к обретению того самого систематизированного мышления. Его результатом в сочетании с практическим опытом является то, что человеку становится без разницы, на чем писать: хоть на си, хоть на питоне, хоть рисовать диаграммы в лабвью - он сделает это за минимальное число усилий в четком соответствии с пониманием того, что хочет получить.

А у тебя наоборот: каша в голове - каша в коде. И это не вина текстовых языков, которые позволяют ясно, компактно и лаконично выражать свои мысли. У тебя просто нет опыта разработки, и ты не понимаешь, какие задачи в реальности решают программисты (не кодо-макаки, а именно инженеры). Ты не можешь улучить инструменты разработки, пока не понимаешь всех их плюсов и минусов.

То, что ты продвигаешь как минус - мол, текстовые языки это ужас и непонятно - не минус. Это неконструктивное заявление, говорящее о том, что лично ты не осилил изучить ни один язык. Изучение первого языка это не столько процесс запоминания его конструкций, сколько перестройка своего мышления.

В итоге:

1) У тебя нет видения того, что ты хочешь в итоге получить. Ты сам признаешься, что у тебя нет видения «настоящего метапрога», и вместо того, чтобы сконцентрироваться на это видении и описать концепции, которые ты хочешь реализовать, ты занимаешься карго-культом, натыкивая примерчики кода на GTK. Это карго-культ в чистом виде: мысль о том, что наличие простейших примеров «языка» приблизит твою игрушку к большим взрослым средствам разработки.

3) Острый нигилизм в терминальной стадии мешает воспринимать существующие технические решения, о которых ты судишь не сам, столкнувшись в ними в реальной практике, а со слова людей на форуме.

4) Ты не можешь сосредоточиться на одной конкретной проблеме, и это есть главный корень зла, мешающий тебе вкатиться в программирование и понять наконец, что графические средства разработки общего назначения никому не нужны по причине их малой продуктивности, громоздкости и сложности восприятия. Мне особенно запали в душу твои рассуждения о «Карениной», где ты был не в состоянии уследить за простой мыслью автора и решил докопаться до конструкции поезда, сбившего главгероиню. Отсюда же нежелание гуглить самому: тебе или проще спросить, потому что ты толком не понимаешь, что тебе нужно, без дополнительных вопросов, или ты банально нахватался по верхам, и осознавать то, как работает какая-то библиотека, тебе тяжело.

Как говорится, разруха не в клозетах, а в головах. Мои слова наверняка будут звучать очень обидно, но послушай доброго совета: завязывай с флудом, закрой форум, проветри башку, а потом прочитай какой-нибудь K&R или Прату от корки до корки и реши какую-нибудь практическую задачку, которая потребует от тебя написать на Си осмысленного кода на пару тыщ строк. Потом возьми какой-нибудь Go и повтори то же самое. Через пару-тройку языков ты поймешь, что графическое программирование вне ситуаций, где используется лабвью, не нужно.

Мощь языков проявляется не в коротких примерах, а в больших системах и алгоритмов с десятками, а то и тысячами компонентов. Только с опытом приходит понимание того, зачем действительно нужно разбивать код на функции, почему важно не игнорировать предупреждения компилятора, для чего нужен валгринд и все такое.

PS: Я иногда думал, что ты тролль, но вряд ли это так, поскольку за шесть страниц любому троллю бы уже надоело развлекать самого себя. Из-за этого ситуация выглядит еще более грустно.

О, евангелист, который ратовал за язык си, оказывается, совсем не знает даже базовых основ языка си.

А откуда мне их знать? В gcc/clang нет интерактивной обучалки, а Си мне нужен всего лишь как бекенд для Метапрога. Меряться письками знаниями языков с такими как ты мне неинтересно. Лабвью я освоил вообще без чтения книг, даже к документации (хелпу) почти не обращался!

Тебя в гугле забанили

Гугление часто дает кучу ненужного мусора. Если что нужно - всегда есть ЛОР, на котором объяснят кратко, по сути и по-русски.

Нафига ты приходишь на ЛОР с вопросами по синтаксису языка?

Вопрос-ответ в этой теме гораздо удобнее, быстрее и релевантнее, чем гугление.

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

Это, конечно, хорошо, но меня интересует далеко не только клепание сайтиков. Ядра ОС, драйвера, десктопный и серверный софт, микроконтроллеры - все от «А» до «Я» должно быть с очень низким порогом вхождения. С интерактивной обучалкой вместо вызубривания синтаксиса языков по книгам.

Как создаются средства разработки? Есть предметная область, есть техническая проблема. Инженер решает свою техническую проблему, а потом понимает, что это решение можно сделать общим.

Вот у меня есть задача. Хочу свое Лабвью «со случайными числами и разработчицами».

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

Если все равно на чем писать тогда зачем кодить на медленных питонах, джавах и джаваскриптах вместо быстрого Си?

Ты не можешь улучить инструменты разработки

Я и не пытаюсь что-то там улучшать. Я создаю новый инструмент почти с нуля.

пока не понимаешь всех их плюсов и минусов.

Понимая плюсы и минусы Лабвью, хочу сделать свой опенсорсный аналог.

Изучение первого языка это не столько процесс запоминания его конструкций, сколько перестройка своего мышления.

Нет. Именно средство разработки должно подстраиваться под мое мышление, а не наборот. Лабвью моему образу мышления подходит лучше всего (из существующих решений), но меня бесит его пропиетарность и ограничения, из-за чего я и взялся за Метапрог. Прототип которого, кстати, пилю на Лабвью, а не на Си!

наличие простейших примеров «языка» приблизит твою игрушку к большим взрослым средствам разработки.

Чтоб натыкать эти примеры и они еще и работали, приходится серьезно дорабатывать транслятор и рисовалку диаграмм. Вот так постепенно и делается Метапрог. Линукс тоже делался постепенно: Линус, чтобы сделать операционку, взял за образец готовый bash и допиливал систему, чтобы заставить его работать. А в моем случае роль образца для доработки Метапрога выполняет сам Метапрог, сделанный «сам на себе». Рекурсия:)

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

Ты сам Лабвью пользовался, чтобы так утверждать? Мне вот текстовые языки пробовать доводилось, и в сравнении с Лабвью они для меня крайне неудобные и непонятные - даже Си, с которыя я более-менее знаком. Я вообще не пишу код на Си сам лично, только автоматически генерирую его из диаграмм в лабвьюшном прототипе Метапрога. Не пристало мне вручную ставить (){};, придумывать и помнить имена переменных итд.

Мне особенно запали в душу твои рассуждения о «Карениной», где ты был не в состоянии уследить за простой мыслью автора и решил докопаться до конструкции поезда, сбившего главгероиню

Поезд мне в той книге намного интереснее всего остального.

написать на Си осмысленного кода на пару тыщ строк. Потом возьми какой-нибудь Go и повтори то же самое. Через пару-тройку языков ты поймешь, что графическое программирование вне ситуаций, где используется лабвью, не нужно.

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

В общем-то, я не зря писал про воинствующее ламерство и нигилизм. Я не буду с тобой спорить - воевать с эффектом Даннинга-Крюгера контрпродуктивно и вредно для психики.

Либо ты в какой-то момент набьешь шишек и сам поймешь, что делаешь фигню, либо просто ливнешь из IT, уверившись, что тут все вокруг неблагодарные.

Можно ли в нуклеаре с SDL изменять размер окна? Не внутренних окошек, а именно внешнего. Хочу поставить рисовалку диаграмм в одно «внешнее» окно, меню «файл» и всякие настройки в другое, выбор элементов диаграммы в третье итд итп. Это возможно?

Вот сделал ты стрелочный прибор для загрузки процика и памяти - а это же графический интерфейс! Не годится, настоящие кодеры пользуются только консольным top!

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

Джава - сложный язык, но писать что-то серьёзное гораздо легче.

А точно Java сложнее? Мне почему то кажется что С.

Изменять размер окна я уже узнал как (флагами при инициализации SDL). Как теперь задать цвет фона?

Покопаться во внутренностях структуры ctx?

Ни один нормальный человек не будет делать драйвера на диаграммах.

Почему?

Со старта да, потом начинает расти до 120 мб, 315 мб итд по мере добавления нод и связей

Утечки какие то, попробуй x11_xft, я в нем нод насоздавал, 7 мб всего занимает.

Как сделать чтобы окно с редактором нод было с изменяемым размером?

Рисуй внутреннее окно размером с обычным окном.

В нуклеаре в примерах уже есть некое подобие редактора диаграмм, а в гтк есть?

Хз.

Попробую начать с просто просмотрщика диаграмм («только чтение»).

Хорошая мысль.

Я подумываю над тем, чтобы асинхронные колбеки и автоматическу параллелизацию выполнения потоков данных (как в Лабвью) реализовать через pthreads. Или лучше С11 threads.h? Что думаешь?

C11 threads на юниксах чому то не хотят поддерживать, в glibc нету их... Бери птхреадсы.

Потому. Попробуй взять обычный драйвер из ядра для какого-нибудь устройства и переделай его на лабвью. Так, чтобы он собирался без варнингов и работал, естественно.

Если твое предположение о том, что в диаграммах все будет проще, верно, то ты справишься за несколько дней и сможешь предъявить пруф своих заявлений. Но этого не произойдет, потому что драйвер - это тебе не формошлепство на гтк.

И, как выяснилось, вызов функций - это тягание данных по стекам, то есть оверхед.

Данные тягяются только если это нужно, так то компилятор конечно оптимизирует...

SDL resize window гуглил уже?) SDL_SetWindowSize(SDL_Window*, int width, int height);

Как теперь задать цвет фона?

Просто внимательно почитай примерчики и вопросы отпадут, кроме сложных.

Так, чтобы он собирался без варнингов

Тебе надо хотя бы прочитать все заголовки тем. Там есть и про варнинги и про анонимные структуры (которые, я, возможно, уже скоро заменю неанонимными).

Попробуй взять обычный драйвер из ядра для какого-нибудь устройства и переделай его на лабвью

На самом Лабвью сделать это нереально из-за того что оно не понимает непосредственно сишных структур и функций, не умеет ассемблер инлайном, не работает на Линуксе (если не выложить за это удовольствие 3000 баксов минимум) и полно других ограничений, из-за которых непригодно для программирования драйверов под Линукс. Но это все вина закрытого кода и копирастов из NI, а не графического программирования как такового.

На лабвьюшном прототипе Метапрога это сделать в принципе реально, но он глючноватый и неудобный. И вообще Метапрог сейчас находится в разработке, название темы читал? Когда он будет сделан полностью «сам на себе» и доработан - тогда драйвера на нем можно и нужно будет делать - не зря же я выбрал именно Си как бекенд!

C11 threads на юниксах чому то не хотят поддерживать, в glibc нету их...

glibc поддерживает, начиная с 2.28: https://lwn.net/Articles/761462/; остальные «юниксы», с которыми работаю (FreeBSD, illumos) - тоже, 4.2? :)

В Debian Stable к примеру ее еще нету, ну хорошо что добавили конечно, но юзать все же не стоит.

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

Тебе надо хотя бы прочитать все заголовки тем

Я читал не только заголовки, но и темы. Пришел в к выводу, что в каше из стрелочек и блоков понять ничего невозможно (что неудивительно), а песни про анонимные структуры слышатся уже месяц к ряду.

На самом Лабвью сделать это нереально

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

Я не вижу ни одного подтверждения твоим словам о пользе графического программирования, кроме того, что лично ты не осилил выучить ни один язык. Пруфов нет, ничего нет, один кривые примеры, обещания и гонор. В общем, все, что я писал в своем большом каменте.

Скорее всего ты просто не знаешь всех возможностей лабвью.

Скорее всего кто то пытается экспертничать, хотя скорее гадать, ну переставай, переставай.

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

Scirra Construct (Classic || 2 || 3)

Ты мне неинтересен.

А я тут причем? Или тебе интересно только траллировать да спамить юзая «Ряя ниасилил яву, ниасилил коншоль» итд?) Ну ясно.

Ты тут при том, что пытаешься перетянуть обсуждение в срач своими кривляниями. Никаких возражений по существу от автора не было - только голословные утверждения, а ты ему поддакиваешь. Нет, ребята, это не конструктивный диалог. Это даже не троллинг, если автор сам признается, что он не осилил.

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

песни про анонимные структуры слышатся уже месяц к ряду

Месяц? Заждался? Я делаю Метапрог сам, по свободе, так что глупо от меня требовать чего-либо (особенно скорости), не закинув мне донат в биткоинах. 1AYoK2TScSpD5bhf67mv9AxHDJ2RidRvjD

К тому же, за прошедший месяц я сделал много других плюшек, например циклы.

Я подозреваю, что ты просто не знаешь всех возможностей лабвью

Совершенно верно. Там классный графический интерфейс, с базовыми функциями (числа, строки, массивы, файлы, сеть) разобраться раз плюнуть, но все же очень не хватает интерактивной обучалки. Оказывается там есть даже асинхронные вызовы, а я и не знал что это такое пока не узнал в темах на ЛОРе.

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

Да, я при желании даже с имеющимся лабвьюшным прототипом Метапрога могу сделать простенький драйвер. Но сейчас я разрабатываю именно сам Метапрог, и сделать драйвер просто чтобы что-то тебе доказать не является наивысшим приоритетом. Тем более драйверов я еще не делал, напиши хоть вводную что делать и что инклюдить, если так хочешь это увидеть, может по свободе сделаю.

Де ты видишь кривляния, тролль?

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

У меня есть знания языков и подходов, и?