Надеюсь, баг-репорт отправили? Ссылочку можно?

Да, конечно. Уж свой-то "фреймворк" точно будет без единого бага

Нет, конечно. Какой смысл отправлять баг-репорт версии, которая 1.5-2 года назад устарела? По-моему, они там уже все баги с F0 позакрывали, т.к. видел там недавно довольно длинный список баг-репортов и пулл-риквестов, который почти полностью был закрыт.
Но тут уже выбор: либо использовать чужую библиотеку и матюкаться каждый раз, как авторы поломают API (а раз прецедент был, уже доверия нет), переписывая абсолютно все свои поделки под новое API, либо городить свое, где все будет надежно.
Я выбираю второй вариант.

В своем проще: никому пулл-риквесты слать не надо. Просто закрыл баг, и сделал коммит.

Да, это часть фреймворка.
Не самая большая.

Главное в нём RTOS с промежуточным софтом.
Главное в RTOS - это отладочные возможности и диагностика.
Главное в отладке - это разнообразие и быстрота отладочных каналов и инструментов анализа на PC.
Поэтому у меня в обязаловку всегда есть либо UART со скоростью не менее 1,5 Мбита в сек, либо USB FS/HS с не менее чем с 2-я виртуальными COM портами, либо Ethernet, либо канал RTT через SWD.
В директории VT100 у меня расположен монитор VT100 с псевдографическим меню.
Этот монитор работает через драйвера и он многозадачный.
Т.е. в одном терминале через com порт можно открыть один монитор , в другом окне терминала через другой com порт открыть другой монитор, и еще через интернет telnet открыть третиий и т.д.
Таким образом можно построить на PC многооконную отладку где сразу видеть в реальном времени листин лога, регистры периферии, выпонять настройки, работать с Shell RTOS и проч.
И это только один из путей или одна из технологий отладки имеющаяся в моем фреймворке.

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

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

AlexandrY, почем матлаб брали? Академическая версия или полноценная?
Интересно просто, во сколько обойдется удовольствие сменить octave на матлаб (пока, правда, не возникало никаких задач, требующих именно матлаба, но есть кое-какие прелести в wavelet-тулбоксе, аналог которому я полгода писать буду, и симулинке). У нас лет 15 назад пара человек даже нарисовали в матлабе свой фреймворк для обработки спектров, да забили на это дело и перешли в более удобный IDL.
Сам матлаб я видел лет 7 назад последний раз, да и то версия какая-то урезанная была (хотя вроде бы линуксовая ничем от вендузячьей не должна отличаться).

Ну да. есть там ошибки. Я их правил тоже. Правда не то, чтобы ошибки. Скорее функционал наращивал. А затем оборачивал в классы на Си++) Это же бесплатно, чего требовать?


Вас понял! Спасибо! Очень интересно!

Ну, и какому клиенту вы продадите железку с "чиста-канкретной" командной строкой?? Лет надцать назад может кто-нибудь и купился бы, но сейчас...

Вам не кажется, что еслиб было так, то 90% техники сегодня было б не с гуем, а командной строкой?? Подумайте еще раз, создается впечатление, что вы живете в своем мире конца 80х на XT или AT286.
ЗЫ. Кстати, в так вам ненавистной винде командная строка тоже есть и сам иногда пользуюсь ей и bat-файлами...

Тема свелась в холивару ртос\не ртом гуй/не гуй.
А про, собственно, ГЛАВНУЮ причину сложности (так сказать, "источник сложности") все забыли

Сообщение отредактировал Укушенный воблой - Jan 16 2017, 21:03

Перепробовал разные варианты. Скольки-то там ядерный смартфон лежит без дела, а компактный джавафон прижился.


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


Ну я продавал. Человеку было нужно, через конфиг-файлы у меня все было готово, GUI front-end городить долго и дороже. Заказчика устроил мой вариант.


Думаю, 90% пользователей GUI в силу разных обстоятельств даже не пытались серьезно работать в командной строке и сравнивать производительности CLI и GUI.


BAT-файлы, конечно, вещь, но с командной строкой NIX-систем это сравнить невозможно.

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

И самое главное - даже и не будут пытаться..
ЗЫ. какая командная строка, если сейчас тенденция программы "писать" путем тыканья в кнопки и "галочки", вот уж где я не согласен с гуем, так это в программировании, ибо создать граф. форму и растыкать виджеты мышкой - это удобно, но программу писать - это уж клавиатура и текстовый редактор, конечно, с подсветкой синтаксиса, разумеется..

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

Вот поэтому если делать только для своего потребления, получается довольно просто: ни с GUI не надо заморачиваться, ни документацию бешеную писать. Да даже можно баги не исправлять, зная о них.

P.S. Насчет GUI я уже последние лет 5-6 использую веб-морды для всего и вся (в рамках разумного, конечно; если через веб-морду нельзя, делаю какой-нибудь элементарный просмотрщик картинок на openGL или устраиваю конвейер). Повсеместная поддержка браузерами вебсокетов добавила удобства: теперь запросы воистину стали асинхронными и нет нужды чрезмерно нагружать линию поллингами по 10-30 раз в секунду! Остается только проблема с трансляцией видео: НЯЗ, до сих пор ничего, кроме mjpeg'ов (а то и вообще обновления картинки по таймеру), не придумали. Я пробовал через вебсокеты работать — очень медленно получается, т.к. нужно в base64 изображение передавать и жабоскриптом декодировать.
Возможно, следующая реализация вебсокетов будет поддерживать передачу бинарных файлов, а браузеры позволят эти файлы непосредственно отображать. Ну или хотя бы браузеры перестанут течь при приеме mjpeg'ов. И будет счастье.

>Главная причина сложности любой программы — сам программист, который пытается из нее невесть что >универсальное сделать.

Вы давно из песочницы вылезли? Полагаю, что и не вылезали.

Программа - это данные + алгоритмы, как сказал классик.
Данные - это физические параметры, систематизированные (структурированные) наилучшим способом для конкретной задачи.
Алгоритмы - это приближение к физической реальности нашего способа установления взаимосвязей.

Все это, в совокупности, определяет сложность моделирования физического мира через призму нашего примерного описания/понимания его.

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

Оч. простая реализация алгоритма X на java - из нумерологии.
Сообразите, что да как:

Arrays.fill(isP, true);
isP[1] = false;
for (int i=2; i*i < N; i++)
if (isP[i])
for (int j=i*i; j < N; j+=i)
isP[j] = false;

Вот это пять!

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


Нет! Здесь как раз тоже удобно форму описать, используя API графической библиотеки. Это оперативнее по той же причине, которую вы назвали выше, говоря о командной строке.

А пайпы на что? Зачем мучиться с gui, если можно через пайп в gnuplot данные передавать? И будет наглядное отображение. Аналогично с логанализатором: сохраняем данные в файл, потом требующийся кусок рисуем гнуплотом, а на выход выдаем анализ по соответствующему протоколу.

GUI на все случаи жизни — неправильный подход. Неюниксвейный. UNIX-way — это одна утилита под одну задачу. Объединяем толпу утилит в конвейер, и получаем счастье. Мелкомягкие же придумали плодить сущности. В итоге в каждой программе свой GUI, своя проверка правописания, своя подсветка синтаксиса, свои виджетобиблиотеки и т.д., и т.п.

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


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