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

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

А как насчет драйверов и ядер ОС под х86?:)

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

Ну ясно, от ответа уходишь, видимо нужно будет покупать ссд для свопа.

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

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

Нафига? Просто… см. выше, короче.

Всё вполне работает на штатном современном железе, включая смартфонное.

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

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

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

Нельзя.

Ссд от свопа мрут быстро. Или нет?

Драйвер. На JS. Дожились.

Хорошо, х86 - решето. Как насчет драйверов и ядер ОС под ARM и RISC?

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

Или нет?

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

Под эльбрус надо, вот что не решето %) RISCи тоже неплохи вроде бы по идеи...

аналогично

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

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

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

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

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

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

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

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

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

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

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

Я больше не могу.

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

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

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

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

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

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

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

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

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

чую, ты не понимаешь что такое «утечка памяти», верно?

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

нет. Не видно.

Вообще никогда не видно?

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

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

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

Ты мне так объясни что тут не так.

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

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

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

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

char *a = malloc(1);
char *b = malloc(1);
a = b;
free(a);

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

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

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

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

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

Не надо ему давать объяснения, пусть сам все ищет.

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

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

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

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

«блоки» {}

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

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

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

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

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

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

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

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

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

А в текстовых языках шаг влево - шаг вправо - RTFM.

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

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

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

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

Вот в

int *a = malloc(sizeof(int));

понятно, что malloc производится в куче. А сам указатель хранится в стеке?

да