Программу не смотрел, за оформление неуд:

• plain c
• sourceforge
• mercurial
• отсутствие нормальной системы сборки, захардкоженные пути, компиляторы, флаги и билиотеки
• отсутствие CI

И какое отношение ваши религиозные взгляды имеют к программе ТС?

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

plain c
mercurial
отсутствие CI

Это наоборот лютейшие плюсы

По поводу построения в реальном времени, стоило бы подетальнее расписать. Что, откуда, какие источники. Ну это про свое болото 😊

периодично присматриваю а-ля осцилогаф, рисуюший графики по мере поступления данных. Гнуплот и скрипты вокруг него не вытягивает.

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

Это наоборот лютейшие плюсы

Потрудись обосновать.

plain c

Просто ткну в феерическую gpEventHandle которая на плюсах сходу станет в разы короче только потому что двумерные точки можно присваивать двумерным точкам ОДНИМ выражением, а не двумя. И обменять два значения можно тоже ОДНИМ выражением вместо ТРЁХ. Да, и я прямо сейчас виду там ошибку вида

foo.x = bar.x;
foo.x = bar.y;

в которой виновата только убогость C как языка. Найдёте?

mercurial

Слева на главной есть весьма красноречивый опрос, какова цена mercurial. С практической точки зрения это значит что потенциальному контрибутору придётся тратить время на установку и изучение нового инструмента, который ему больше нигде не встретится. Что с ненулевой вероятностью приведёт к тому что он просто плюнет на отправку вам патча.

отсутствие CI

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

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

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

Просто ткну в феерическую gpEventHandle которая на плюсах сходу станет в разы короче только потому что двумерные точки можно присваивать двумерным точкам ОДНИМ выражением, а не двумя.

Так ты, гражданин, даже C не знаешь, о чем тут можно говорить?

#include <stdio.h>

typedef struct Point Point;
struct Point
{
	int x;
	int y;
};

int main(void)
{
	Point a = {.x = 1, .y = 2};
	Point b;

	b = a;

	printf("(%d, %d)\n", b.x, b.y); // (1, 2)
	return 0;
}

И обменять два значения можно тоже ОДНИМ выражением вместо ТРЁХ.

Странно, почему я могу в C обменять два значения ОДНИМ выражением, а ты нет?

int a = 1, b = 2;

swap(int, a, b);

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

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

Так ты, гражданин, даже C не знаешь

Нет, это автор не знает. А мне прямо сейчас взял и одним выражением сложил две точки. И не функцией или макросом, а оператором, как положено.

Странно, почему я могу в C обменять два значения ОДНИМ выражением, а ты нет?

Опять же, вопрос автору. А мне прямо сейчас взял и показал этот swap в стандарте.

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

Нет, это автор не знает.

Нет, это ты не знаешь. Если бы знал, ты бы написал что-то вроде:

Автор, ты что не знал, что в C можно присваивать структуры одним выражением?

Но нет, ты написал это:

которая на плюсах сходу станет в разы короче только потому что двумерные точки можно присваивать двумерным точкам ОДНИМ выражением, а не двумя.

Человек мог и в C++ написать присваивание таким образом, значило, бы это, что в этом виноват язык?

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

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

Хотя если уж тебе так кровь из носу нужно сложение векторов:

#include <stdio.h>

typedef int Point __attribute__((vector_size(8)));

int main(void)
{
	Point a = {1, 2};
	Point b = {3, 4};

	Point c = a + b;

	printf("%d, %d\n", c[0], c[1]);
	return 0;
}

Да, этого нет в стандарте, но поддерживается gcc и clang’ом, чего уже достаточно для многих. Не находишь?

А мне прямо сейчас взял и показал этот swap в стандарте.

А ты используешь только тот код, который есть в стандарте? Шаг влево, шаг вправо – расстрел? Ну, для твоих хелловорлдов, может, и сойдет, но для нормальных проектов в порядке вещей использовать сторонний код, или (о боже!) писать его самому. Хотя судя по твоим постам ты не сможешь написать даже тот жалкий макрос swap.

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

А мне прямо сейчас взял и показал этот swap в стандарте.

А ты знаешь на чем строятся новые стандарты С?

У clang вектора круче %)

typedef float float4 __attribute__((ext_vector_type(4)));
typedef float float2 __attribute__((ext_vector_type(2)));

float4 foo(float2 a, float2 b) {
  float4 c;
  c.xz = a;
  c.yw = b;
  return c.xz * a.yz * b.y;
}

У clang вектора круче %)

Я специально выбрал расширение, которое доступно и для clang, и для gcc, а то пациент начал бы визжать, мол «один компилятор, не кроссплатформенно, бегом побежал показывать!» и т.п.

А так, конечно, полностью согласен, что у clang’а это лучше реализовано. Media Molecule (или другая студия Sony) писали, что они используют это расширение для того, чтобы была возможность использовать один и тот же код, как для CPU, так и для HLSL-шейдеров.

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

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

Правильно, её нету. Это одна из причин почему язык не годится для практического применения.

А ты используешь только тот код, который есть в стандарте?

Ну, для начала, я использую код который есть. Придуманного тобой swap’а нет ни в стандарте, ни у автора, ни даже ты сам его реализацию не удосужился привести. Если бы был, наверное автор не стал бы специально его не использовать и писать каждый обмен в 3 строки (не стал бы, можешь лопнуть пытаясь доказать обратное выгораживая свой недоязычок). Но его нет, поэтому и выбора не остаётся. А в нормальных языках есть. Как и многое другое.

или (о боже!) писать его самому.

Именно что в нормальных языках занимаются написанием кода, решающего прикладную задачу, а не реализуют базовые вещи с нуля в каждом новом проекте. Вон, автор ещё реализовал пачку *toi(). Ты рад что он потратил время на это вместо разработки приложения?

Но мне проще на C + SDL и так больше fps в тяжелых случаях.

Со slovozap не согласен, но лучше бы ты взял плюсы...

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

Посмотри на Nuklear (C), Imgui (C++).

Придуманного тобой swap’а нет ни в стандарте, ни у автора, ни даже ты сам его реализацию не удосужился привести.

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

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

Базовые вещи пишутся один раз, тестируются, а потом просто используются. Зачем каждый раз писать с нуля, неосилятор #include ты наш? #include есть в стандарте, хочешь могу показать где.

Правильно, её нету.

В своем посте я показал, как использовать перегрузку операторов для векторов (о чем ты, собственно, и спрашивал). Вместо того чтобы сказать «Да, спасибо, я узнал что-то новое сегодня», ты решил незаметно «проигнорировать» ту часть.

Это одна из причин почему язык не годится для практического применения.

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

ZeGrapher

• plain c
• sourceforge
• mercurial
• отсутствие нормальной системы сборки, захардкоженные пути, компиляторы, флаги и билиотеки
• отсутствие CI

*fixed

• C++
• GitHub
• Git
• Сборка в AppImage с помощью linuxdeployqt
• Travis CI

Grab it! - https://github.com/AdelKS/ZeGrapher

Тесты делать нет ресурсов, это же сложнее всего остального. А проверять только собирается или нет, это разве CI будет?

Сложные системы сборки избегаю если возможно.

По поводу построения в реальном времени, стоило бы подетальнее
расписать. Что, откуда, какие источники. Ну это про свое болото

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

chunk 40
load 0 10000 text "pipelive1"
load 1 10000 text "pipelive2"

bind 0
mkpages -1

bind 1
mkpages -1

Вместо mkpages можно вручную все задать.

bind 0
page "Electrical Position Error"
	label 1 "(Degree)"
	figure 0 12 "Error"

page "VSI Voltage"
	label 0 "X (V)"
	label 1 "Y (V)"
	figure 15 16 "VSI"
		drawing dot 2

В этом случае источники могут быть и бинарными.

Со slovozap не согласен, но лучше бы ты взял плюсы...

Там слишком легко все можно усложнить, мне не нравится.

Посмотри на Nuklear (C), Imgui (C++).

Смотрел, но поздно уже.

А проверять только собирается или нет, это разве CI будет?

Будет.

Grab it! - https://github.com/AdelKS/ZeGrapher

Съел 100% cpu и 180M памяти на моем тестовом файле размером 250K и не отзывается.

Быстро посмотреть содержимое файла не получается. Надо выбирать столбцы, вручную зумить чтобы увидеть весь график. Default view ничего не знает про диапазоны данных из файла. Операции добавления столбцов (чтобы построить от номера сроки по X) очень медленная для такого мелкого файла из ~5000 строк.

Не для анализа численных данных эта программа.

Базовые вещи пишутся один раз, тестируются, а потом просто используются.

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

ты решил незаметно «проигнорировать» ту часть

Я проигнорировал её намеренно и демонстративно, при этом тебя пожалел. Если до тебя не дошло почему и ты настаиваешь чтобы тебя ткнули в это лицом - пожалуйста: попытка на перегрузку операторов ответить (ещё и непереносимыми) векторами может выдать либо полное бессилие в аргументах, либо абсолютное незнание программирования, и в любом случае вызывает только смех. Ты же хвастаешь своим якобы знанием C, так что, оказывается ты просто слов умных нахватался и даже не знаешь где они применимы? Строки тоже будешь ими складывать? А кватернионы перемножать?

Миллионы полезных проектов

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

И в сорджфордже нет ничего плохого.

Раскрою, пожалуй, мысль.

Тесты делать нет ресурсов, это же сложнее всего остального.

Это потому что ресурсы были потрачены на реализации *toi, swap’ы в три строчки, маллоки, strcat’ы и весь тот кошмарный сишный бойлерплейт который в нормальных языках писать просто не нужно.

А проверять только собирается или нет, это разве CI будет?

Сборка - это уже очень немало. При том что travis, например, позволяет затестироваться с gcc и clang разных версий на разных версиях убунты + ещё по желанию в макоси. А appveyor ещё и на винде, если хочется. Ещё парой строчек подключаются санитайзеры, coverage, cppcheck, valgrind и множество других приблуд, предохраняющих каждая от своего подмножества проблем.

Касательно тестов, для начала можно пойти простым путём - поднять в travis xvfb, запустить приложение, при желании сделать скриншот, при желании даже отправить ему какие-то иксовые события (наверняка есть средства тестирования GUI, но с вашим кастомным UI на SDL вряд-ли от них будет много толку).

Да, это не будет полноценным тестом, то есть корректность поведения приложения мы так не проверим. Но зато убедимся что оно не падает и не течёт (визитные карточки C), нет ругани от санитайзеров.

Сложные системы сборки избегаю если возможно.

Это вы себя, конечно же, обманываете.

Сложная система сборки - это когда есть, например, Makefile на полсотни строк из которых половину нужно переписать под мою систему, потому что у меня нет /tmp/gp, компилятор и линкер называются не gcc, заголовки SDL2 лежат не в /usr/include, а пути к библиотекам наоборот нужно указать. А если делать пакет, то нужно ещё и убрать самодеятельность в виде -O/-g флагов и вообще заменить = на ?= или += чтобы учитывались системные флаги сборки. При этом он не умеет ни инсталляции в систему, ни генерации проекта для IDE, ни отдельных Release/Debug сборок. Плюс рядом лежит ещё один такой же неработающий Makefile под другую платформу. Вот это - сложно.

А просто - это когда сказано: найди зависимости, возьми исходники, собери с этими зависимостями и установи в систему. И больше ничего. И это работает из коробки на любых платформах, умеет кросс-компиляцию, Debug/Release, DESTDIR, использует правильный компилятор, корректно поддерживает системные флаги, работает кроме gmake с bsd’шными make’ами, равно как и с модным ninja и даже msbuild, да ещё и проценты сборки показывает. Выглядит это как-то так, работает на фре и всех линуксах до которых дотянулся:

project(graph_plotter)
cmake_minimum_required(VERSION 3.15)

include(FindPkgConfig)
pkg_check_modules(SDL2 REQUIRED sdl2)
pkg_check_modules(SDL2_TTF REQUIRED SDL2_ttf)
pkg_check_modules(SDL2_IMAGE REQUIRED SDL2_image)

file(GLOB SOURCES *.c)

add_executable(graph_plotter ${SOURCES})
target_include_directories(graph_plotter PRIVATE ${SDL2_INCLUDE_DIRS} ${SDL2_TTF_INCLUDE_DIRS} ${SDL2_IMAGE_INCLUDE_DIRS})
target_link_directories(graph_plotter PRIVATE ${SDL2_LIBRARY_DIRS} ${SDL2_TTF_LIBRARY_DIRS} ${SDL2_IMAGE_LIBRARY_DIRS})
target_link_libraries(graph_plotter ${SDL2_LIBRARIES} ${SDL2_TTF_LIBRARIES} ${SDL2_IMAGE_LIBRARIES} m)

install(TARGETS graph_plotter RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)

Если прислушаетесь к голосу разума, то

To the extent possible under law, slovazap has waived all copyright and related or neighboring rights to the cmake script cited in this post.

Это потому что ресурсы были потрачены на реализации *toi, swap’ы в
три строчки, маллоки, strcat’ы и весь тот кошмарный сишный
бойлерплейт который в нормальных языках писать просто не нужно.

В начале я и не планировал, что понадобится UI. Нужна была быстрая рисовалка данных из файлов. Знакомые средства разработки были только C + SDL. Но количество возможностей разрослось и вот получилось, как часто и получается.

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

Я понял вашу мысль, можете не тратить сильно время на меня, не первый раз это все слышу. Спасибо.

Это вы себя, конечно же, обманываете.

Нет, Makefile простой и примитивный, со своими проблемами. То что его нужно переписать я и не скрываю и не считаю это за сложность, это примитивность инструмента.

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

Я бы даже добавил это к себе если бы так было угодно пользователям (в любом случае ничего не мешает сделать форк), но пока пользуются 2-3 человека (включая меня) которым я сам делаю билд, в этом направлении двигаться не планирую.

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

Так что, использование С - это только плюс!

Ну смотрите. Вы пришли за критикой, её получили и проигнорировали, причём судя по всему не в первый раз:

не первый раз это все слышу

А вот эту феерию самоубеждения что чёрное это белое просто через недельку перечитайте:

Нет, Makefile простой и примитивный, со своими проблемами. То что его нужно переписать я и не скрываю и не считаю это за сложность, это примитивность инструмента.

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

Давайте вы просто определитесь чего вообще хотите. Хотите делать мир лучше решая проблемы людей? Я сказал с чего начать. Хотите пилить в углу поделку исключительно для себя и тех 2-3 человек? Тогда непонятно с хрена ли вас интересует чьё-то мнение что вы пришли её сюда показывать - пишите хоть на 1C и собирайте брейнфаком. А если вы думали что сделаете доброе дело выложив код - то вынужден огорчить, с таким подходом это злое дело, потому что выглядит как СПО, а на деле зарепорть баг - вы не почешетесь его исправить, потому что «в этом направлении двигаться не планируете». Пришли исправление - вы его не примете, как только что продемонстрировали. Сделай фичу - «ничего не мешает сделать форк». В итоге, пользователь натолкнувшийся на ваш от*сь-код потратит больше времени и средств на решение своей задачи чем если бы он написал код с нуля.

Ну ничего. Я потратил кучу времени на gnuplot, что в итоге не принесло результата, но это же не повод считать его создателей злодеями.

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

Я даже спорить не пытаюсь, вроде бы согласился, что недостатки есть. Хотите меня убедить, что показав код я теперь обязан все исправлять и поддерживать его? Не поняв даже нужно ли это кому?

Я потратил кучу времени на gnuplot

Ссылки на твои коммиты в трекере gnuplot?

А почему бы не выложить тарболл релиза в исходниках?

Автор для мк-шек пишет, насколько я понял, какие си-ай. Блочёк завелся -> таска сделана, переходим к следующей. Как научные сотрудники. А если скрестить, получится Эдди.

Так ты, гражданин, даже C не знаешь, о чем тут можно говорить?

b = a;

А если структура немного сложнее POD? Опять ручками?

Держите меня семеро!

slovazap: А мне прямо сейчас взял и одним выражением сложил две точки.
Я:        *показываю неосилятору*
slovazap: Вы все врети!

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

Не серчай, но в этом вопросе я предпочитаю довериться программистам Sony, а не ноунейм фанатику slovazap с сайта linux.org.ru.

О, поздравляю, ты проиграл.

Я, конечно, понимаю, что тебе, как форумному воену, везде мерещится война, но для меня спор – это в первую очередь обмен опытом, и я рад, что смог научить тебя чему-то новому (тем же векторным расширениям, или тому как применять их для написания кода для CPU и GPU одновременно). Еще около 10 (десяти) таких уроков от меня, и, возможно, из тебя будет толк. Главное не отчаивайся.

Да.

На вкладке Code ссылки на картинки битые.

И список хоткеев оформить бы.