LINUX.ORG.RU

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

 , , ,


2

3

FAQ

0. Где отсутствующие примеры и пункты FAQ? Как вообще читать эти темы?

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

10. Примеры выдают варнинги при компиляции (у кое-кого еще и сегфолтятся)

Это из-за того, что парсер инклюдов разворачивает всё (в том числе структуры и указатели) до примитивных типов. Если версия гтк отличается от моей - возможны отличия в анатомии структур и сегфолты из-за этого. Эта проблема будет решена, но позже.

11. Как выглядит факториал в графическом представлении?

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

(пока что на Лабвью)

Примеры

Находятся в прошлых темах. Компилировать исходники нужно так:

gcc ./test.c -o ./test $(pkg-config --cflags --libs gtk+-3.0)

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

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

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

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

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

Прототип чата:

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

Показывалка языка локализации через seltocale (кстати, у кого что показывает?)

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

Прототип чата с прокруткой:

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



Последнее исправление: CYB3R (всего исправлений: 10)

Ответ на: комментарий от Deleted

Для запуска чего, нищебродина недоразвитая? Скомпилированного кода? Так это зависит от бэкэнда - NodeJS, обычный браузерный ES6, RN или CHIP-8. В CHIP-8, если что, вообще 4 килобайта архитектурно заложено, больше никак не получится. Для запуска самого компилятора? Пофиг вообще. В любом случае меньше этих ваших бомжвью. Но, в отличие от бомжвью, он будет открытым, кроссплатформенным и доступным отовсюду с любого современного браузера.

rebforce
()
Ответ на: комментарий от liksys

У тебя есть стрелочный индикатор использования оперативной памяти. На нем можно видеть крупные утечки памяти.

metaprog
() автор топика
Ответ на: комментарий от metaprog

Нафига? Ты много драйверов и ядер ОС за свою жизнь написал, дурилка картонная? И не напишешь с таким подходом никогда. А у меня вот драйвер самописный есть под медиатековский последовательный порт. На JS, на базе WebUSB, да. Сейчас в вялотекущем режиме пилю под квалкоммовский диагностический.

Просто надо не быть необучаемым днищем, и всё станет возможно. А этот ваш x86, надеюсь, скоро вообще в топку истории отправится.

rebforce
()
Ответ на: комментарий от rebforce

Просто надо не быть необучаемым днищем, и всё станет возможно. А этот ваш x86, надеюсь, скоро вообще в топку истории отправится.

Конечно, конечно. Вместе с устаревшим тисипиайпи.

Deleted
()
Ответ на: комментарий от rebforce

Ну пока у тебя лишь одни фантазии, в отличие от ОПа, так что оценить ничего нельзя.

Deleted
()
Ответ на: комментарий от metaprog

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

Или нет?

У меня своп на ссд уже лет 5, вроде все ок.

Deleted
()
Ответ на: комментарий от liksys

Вот запустил ты, допустим, текстовый редактор, а он на каждое нажатие кнопки на 100 мб ОЗУ жрет больше. Уже будет заметно на стрелочном индикаторе. Значит есть утечка.

Есть идея. Запилить стрелочный прибор для более подробного мониторинга процессов в целом и выбраного процесса по-отдельности. Есть же в природе двухстрелочные приборы? Два таких: на память и на процессор, в каждом по две стрелки: система в целом и выбраный процесс по-отдельности. PID процесса можно задавать как в механическом кодовом замке https://ru.wikipedia.org/wiki/Кодовый_замок

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

metaprog
() автор топика
Ответ на: комментарий от Deleted

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

metaprog
() автор топика
Ответ на: комментарий от metaprog

Ну я тоже выключаю в последнее время, его вполне хорошо мне заменяет zram.

Deleted
()
Ответ на: комментарий от metaprog

английский вместо русского

украинского же как на диаграммах.

iluha16
()
Ответ на: комментарий от metaprog

Запилить стрелочный прибор для более подробного мониторинга процессов в целом и выбраного процесса по-отдельности

ты что серьёзно собрался мониторить утечки памяти этой ерундой сделанной just for fun

Вот запустил ты, допустим, текстовый редактор, а он на каждое нажатие кнопки на 100 мб ОЗУ жрет больше. Уже будет заметно на стрелочном индикаторе. Значит есть утечка.

я пад столом ржу ни магу пиши ещё

iluha16
()
Ответ на: комментарий от metaprog

Большая часть этих проблем от того что графические интерфейсы пишут в тексте в толстых и глючных фреймворках.

Не-а. GUI объективно сложнее CLI. Кстати, хоть сами фреймворки и «написаны в тексте», но дизайн окон делается как раз графическими инструментами.

hobbit ★★★★★
()
Ответ на: комментарий от metaprog

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

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

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

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

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Ну так в main валгринд тоже может увидеть что утечки есть. И в сишных подфункциях, используемых в main.

metaprog
() автор топика
Ответ на: комментарий от iluha16

ты что серьёзно собрался мониторить утечки памяти этой ерундой сделанной just for fun

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

metaprog
() автор топика
Ответ на: комментарий от ossa

Понимаю. Когда в процессе крупные утечки памяти, это видно в диспетчере задач по чрезмерному использованию ОЗУ.

metaprog
() автор топика
Ответ на: комментарий от metaprog

в диспетчере нет. в диспетчере видно только потребление ресурсов процессом. Если в процессе выделили гигабайт памяти, это не значит, что это утечка, это значит что в процессе выделили гигабайт памяти. Этот гигабайт может и «утечь», а может и нет.

ossa ★★
()
Ответ на: комментарий от ossa

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

metaprog
() автор топика
Ответ на: комментарий от metaprog

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

iluha16
()
Ответ на: комментарий от metaprog

Чрезмерное использование ОЗУ - это не очень эффективное использование памяти. Размытое понятие, может значить много чего.

А утечки памяти - когда malloc (realloc...) вызвал, а free для этого участка памяти не сделал. И программа «потеряла» указатель на не освобождённый участок памяти.

Вот примитивнейший пример утечки памяти:

char *a = malloc(1);
char *b = malloc(1);
a = b;
free(a);
Здесь «утёк» один байт памяти. Без специальных инструментов эту утечку не отследить. Здесь free освобождает 2-ю область в куче (heap), а указатель на 1-ю область потерян для программы. Но менеджер памяти из ОС всё отслеживает и обязательно освободит после закрытия программы. И как тебе уже 100 раз твердили, если на этапе компиляции нельзя однозначно определить «время жизни» области памяти, никакие «для каждого malloc свой free» не помогут если и malloc, и free находятся в теле if'ов или ещё более хитро «спрятаны».

Кстати, из-за подхода «всё в main» все локальные переменные будут «жить» всё время что работает программа. Это как раз пустая трата гигабайтов оперативы.

arturianec100
()
Ответ на: комментарий от iluha16

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

У меня есть цель софт делать, а не учиться. Готовые бинарники, а не сферические знания в вакууме. Лабвью мне позволяет делать софт, но ограниченность и закрытость бекенда вынуждают меня делать Метапрог ему на замену.

metaprog
() автор топика
Ответ на: комментарий от metaprog

У меня есть цель софт делать, а не учиться

Ящитаю, это надо вынести дисклеймером во все посты.

liksys ★★★☆
()
Ответ на: комментарий от arturianec100

А можно ли прибивать локальные переменные как только они станут ненужными? Если нет, в Си есть еще «блоки» {}, в них тоже можно запихивать локальные переменные, чтобы уничтожались по ненадобности. Или нет?

metaprog
() автор топика
Ответ на: комментарий от liksys

Я не был до конца уверен, что правильно всё понимаю. Меня бы поправили в случае если бы я ошибся.

arturianec100
()
Ответ на: комментарий от metaprog

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

Если они в куче - да, если на стеке - нет.

«блоки» {}

Как раз в том числе для этого. Удачи в вычислении области видимости переменной, особенно в здоровенных «паутинах», а не маленьких декомпозированных схемках. Я про то, что это «сизифов труд». Вместо монструозного main лучше выделять всё в свои сишные функции и КАЖДУЮ функцию объявлять inline. Тогда оверхеда никакого не будет и не будешь бороться с проблемами которых ни у кого нету.

arturianec100
()
Ответ на: комментарий от metaprog

У меня есть цель софт делать, а не учиться

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

arturianec100
()
Ответ на: комментарий от arturianec100

Если они в куче - да, если на стеке - нет.

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

Удачи в вычислении области видимости переменной

В бекенд всегда вкрутить успеем. Главное - наконец-то перенести хотя бы фронтенд (рисовалку) «саму на себя» и подключить других непосредственно к разработке.

metaprog
() автор топика
Ответ на: комментарий от arturianec100

Когда учишься в процессе создания

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

metaprog
() автор топика
Ответ на: комментарий от liksys

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

metaprog
() автор топика
Ответ на: комментарий от metaprog

ну в стэке это когда пишешь просто int a. а вот если int *a = malloc(sizeof(int)); значит в heap это вроде по русски как раз куча наз-ся. аргументы ф-ции (int main(int argc, char **argv): в данном случае argc и argv) тоже живут в стэке. по выходу из ф-ции (return) stack pointer получает значение которое было до вызова ф-ции и как следствие память занимаемая переменными хранящимися в стэке освобождается.

iluha16
()
Ответ на: комментарий от arturianec100

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

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

iluha16
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.