Метапрог-прототип, версия 7 + графические диалоги на Метапроге

Я уже говорил, что на каждое заявление про стектрейсы буду требовать конкретики. О каких ошибках идёт речь? Что тебе вылетало?

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

И выбразываются они значительно реже, чем стектрейсы в питонософте

Сам считал? А количество сегфолтов в тырпрайзном софте, который люди вынуждены писать на С++03? Просто подумай, что вообще лучше: segmentation fault, core dumped или информативный стектрейс питона?

А давай, ты ещё заодно наконец объяснишь, что же такого плохого в ООП?

какие-то ошибки в классах и методах.

Я так понял, ошибки в них бывают только из-за того, что ООП, ведь да?

«сделанная, когда не было»

Принято.

трудно догадаться?

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

они должны
должны

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

ты хоть понимаешь, что такое вообще стектрейс и кордамп?

Вот! Правильный вопрос. metaprog, расскажи нам, что это?

Видно нравится людям стектрейсы ловить там, где Си не скомпилируется

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

ТС у нас пока что не знает таких страшных слов как «строгая типизация» и «слабая типизация», у него в голове пока что есть только «статическая типизация», а раз статика, значит 400% защита от ошибок.

Теперь будильником можно пользоваться

test@debian-test:/home/test/mmmm$ ./test 
будильник на 156:230
^C
test@debian-test:/home/test/mmmm$ ./test 
будильник на 16:80
^C
test@debian-test:/home/test/mmmm$ ./test 
будильник на 131:0
^C
test@debian-test:/home/test/mmmm$ ./test 
будильник на 144:131
^C
test@debian-test:/home/test/mmmm$ ./test 
будильник на 96:96

б-будильник

на мертвопроге

Ну всё, теперь ТС ответит, что к МЕРТВОпрогу он отношения не имеет, а мысль про «все в одну функцию» пролетит мимо его сознания.

А помимо типизации там еще отлов ошибок через errno. И система типов C никак тебе даже не намекнет, в каком месте нужно этот errno проверять…

Вот, например,

FILE* fptr;
 fptr = fopen("non-existent-file.txt","r");
 fscanf(fptr,"%d", &num);

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

./a.out                                                                                                    [1]    11558 segmentation fault (core dumped)  ./a.out

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

ЭТО ПРОТОТИП!!!111

Это как с проверкой на пустоту блоков в генерируемом коде. Похоже, в метапроге/labview тупо тяжело добавить лишнее условие для проверки, хотя в текстовых ЯП это занимает полминуты…

Да пофигу на его ответы. Просто наблюдаем за потугами и ловим лулзы.

даже в прототипе можно было хотя бы пробелы у строк откусить с обоих сторон :) Это, кстати, про вопрос ошибок и их обработку.

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

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

Дык это надо маны по нуклеару курить, для метапргеров это зашквар

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

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

Есть? Какие?

на мертвопроге

К нему я отношения не имею.

На вопрос отвечай. Как ты будешь обрабатывать непредвиденные ошибки, если корка бесполезна, а стектрейсов в рантайме нет?

Есть?

Есть

Какие?

мне за тебя демку нуклера посмотреть?

Как ты будешь обрабатывать непредвиденные ошибки

Ошибки должны обрабатываться в условиях, как тут с выделением памяти: https://postimg.cc/hQVLBcHp

а стектрейсов в рантайме нет

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

мне за тебя демку нуклера посмотреть?

Скачать Метапрог и вкрутить в будильник проверку на вводимые числа.

И донат закинуть не забудьте.

Кстати, я заметил, что у тебя ВСЕ сообщения по крайней мере за последний месяц (подозреваю, что и за полгода) только в темах про Метапрог и Мертвопрог, с перерывами только на доносы.

Это ассерты. Как ты будешь обрабатывать ошибки, деления на ноль, например?

В чистой сишке писать сложно. Задача Метапрога - сделать программирование на уровне Си простым.

В функцию деления можно вставить проверку на ноль.

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

В функцию деления можно вставить проверку на ноль.

Кто то тут ЕМНИП скулил про быстродействие и про тчо С выбран потому что он самый быстрый…

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

Во все сишные библиотеки ты тоже вставишь проверки?

в функцию деления можно вставить проверку на ноль.

У тебя же там поддержка текстовых мат. выражений планировалась. Ну вот я написал что-то вроде (x1+x2)/(y1+y2) в метапрог-диаграмме текстом, метапрог прямо это выражение вставил в код сишки, и никакой проверки на 0 нету

Нет. В обертки над ними или постепенно переделывать библиотеки на Метапроге.

В обертки над ними

И-и-и, ты изобрел абстракции :D

Есть хорошие абстракции и плохие. Хорошие это всякие врапперы, для использования которых почти не требуется мозг. А плохие это все эти ваши дурацкие деревья и прочий заумный МАТАН, и ООП.

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

И почти не требуются вычислительные ресурсы.

А плохие это все эти ваши дурацкие деревья и прочий заумный МАТАН, и ООП.

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

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

А как собираешься такое обрабатывать ты? Переложить это на программиста? Тогда получается такая же хрень, что и с Цэ, твои жгутики и квадратики не делают это проще.

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

ты изобрел абстракции :D

Ты не понимаешь! сувт это не абстракции! они в ассемблере всего в 1 строчку!!11

А осилите там с котечкой вдвоём? Это не такая уж и тривиальная задача

А давай, ты ещё заодно наконец объяснишь, что же такого плохого в ООП?

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

Для начала надо осилить Метапрог «сам на себе», а дальше уже приложится.

Только проверки на ифах

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

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

Ты же только что сказал, что

Только проверки на ифах

Какие ещё тогда исключения? Ты собрался взять худшее из обоих подходов, что ли?

«Исключения» на ифах.

Твоя фраза — бред. По крайней мере, в рамках устоявшейся общеупотребляемой терминологии.

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

Про клей (я дозвонился, спасибо тебе за повод:-))

Как правило они не любят неразьемных соединений, ставят на смазку + мехзажим. Смазки разные, зависит от вакуума, на средний вакуум Apezon N и Томфлон.

Клей тоже есть CrystalBond, типа термоклея - если прогреть до 180 то можно разобрать, а потом ацетоном оттереть начисто.

Сейчас товарищ не в Москве, вернётся в начале марта, если чего он готов проконсультировать более детально.

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

Понял-принял, спасибо. Чиркну, когда нужна будет подробная инфа.