LINUX.ORG.RU

Метапрог-прототип 34 + СУВТ по логическому типу

 , , ,


0

3

Следующая тема:

Метапрог-прототип 42

Подпишусь в поддержку Столлмана Bitcoin-кошельком из первой темы про Метапрог:

Metaprog Project supports Richard Matthew Stallman. Shame to SJW, Big Tech and Big Media. We need to get rid of them or Big Money will enslave us. It is do or die! Stay straight, RMS!

Подпись:

H/3cqHl7HGdAQd9K/io474IbLYlIKi/8R6pw1Vbpz0oTN4kihI5YO4dIdZo2VRdJbSp8kWmtWgC5TRTs0MkBIAo=

Подробности:

Движение отмены Столлмана (комментарий)

Следующая версия:

www.linux.org.ru/forum/development/16219448

Скачать:

https://mega.nz/file/6VJCEboQ#N3pu86bqI31Jp15aHWt6l-FIkY_RUws0CZK9aMcvxZo

В версии 34 исправлен тот же баг что и в 33, но другим способом, так как багфикс из версии 33 вызывал другие баги.

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

К выпуску версии 32 неожиданно обнаружилось, что СУВТ может иметь переключатель логического типа. То есть, можно задавать типы на значения «да» и «нет». Никаких изменений для этого вносить с 31 версии не пришлось, надо лишь задавать в определении СУВТ типы по значению СУВТ 0 на «нет» и 1 на «да». Из изменений - некоторые исправления багов (например, с кодогенерацией структур и операций над структурами под указателями), а также экспериментальная фича отрисовки канваса через dll-вызов окошка на SDL, за подробностями обращаться к MOPKOBKA или kote4ka в Метапрог онлайн.

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

В версии 30 - исправление бага с сишной трансляцией циклов с регистрами. Теперь их значение берется на сишном уровне не напрямую, а через промежуточную переменную. Это позволило реализовать алгоритм вычисления чисел Фибоначчи, где есть непосредственная передача данных между разными регистрами. Метапрог-схема находится в меню обучение - примеры - Фибоначчи, выглядит она так:

https://i.postimg.cc/D0W8v7XZ/image.png

Для сравнения - тот же алгоритм на LabVIEW:

https://i.postimg.cc/CLqz9L0r/image.png

Сишная трансляция:

https://pastebin.com/Z8rzvZpQ

Сравнение с тем же алгоритмом на «аналоге» Метапрога с бекендом на python говорит само за себя:

Metaprog здорового человека (комментарий)

В версии 29 - крупные изменения системы типов. «Встроенных» типов, вытягиваемых через меню «структуры», больше нет, все они теперь представлены в стандартной библиотеке. В особенности изменения коснулись числовых типов: теперь такие типы как число, дробь, целое, знаковое и беззнаковое представлены как многотиповые из соответствующих типов. Например, беззнаковое - многотиповой из 8, 16, 32, 64 и 128-разрядных беззнаковых, целое - многотиповой из знакового и беззнакового, число - многотиповой из целого и дробного. Теперь такие типы можно обрабатывать как многотиповые, поступая с числами разных типов по-разному.

В версии 28 переключатель (аналог сишного switch) работает с многотиповым типом. Выполнение схемы происходит только на ветке, соответствующей поданному на переключатель типу. Ветвление происходит не в рантайме (как в случае СУВТ), а при кодогенерации - не соответствующие поданному типу ветки не генерируются. Теперь осталось сделать цикл по структуре.

В версии 27 добавлена удобная возможность создать новую подфункцию, не останавливая весь прототип. Кнопка блоки - новая подфункция.

Также обнаружилась (но пока не исправлена) проблема с терминалом счетчика повторений цикла в цикле по условию - пока что не используйте его!

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

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

В версии 25 исправлена трансляция сложных рекурсивных структур с СУВТ.

В версии 24 был исправлен баг транслятора, проявившийся в версии 23: на некоторых схемах (например, отправки данных по TCP) код, отвечающий за поток данных, «вливающийся» в ветки с условиями, мог сгенерироваться после кода самого условия.

В версии 23 исправлен еще один баг с упаковкой проектов, а также баг трансляции условных схождений.

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

В версии 21 наконец-то добавлена корректная трансляция схем, содержащих рекурсии. Как пример можно привести схемы из репозитория «разработка интерфейса на нуклеар+» (можно скачать через Метапрог онлайн). В этой схеме отрисовка элементов интерфейса основана на СУВТ (структура условного выбра типа). В этой СУВТ возможны такие элементы интерфейса, как текстовый лейбл, текстовое поле, кнопка и (самое интересное) - линия из элементов интерфейса. В последнем случае происходит рекурсивный вызов функции, обрабатывающей массив из тех же СУВТ элементов интерфейса.

Предыдущая версия:

Метапрог-прототип 19 + API на СУВТ + ускорение трансляции



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

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

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

Ну это уже как ОП решит.

paramon
()
Последнее исправление: paramon (всего исправлений: 1)
Ответ на: комментарий от paramon

IDE != полноценный язык. Транслятор в сишку == паразитирование на сишке.

Следуя вашей же логике, у раста тоже может появиться компилятор на расте, поэтому он не является скриптухой. Гошечка тоже не является скриптухой, потому что у гошечки компилятор написан на гошечке.

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

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

IDE != полноценный язык

Про то и речь.

Транслятор в сишку == паразитирование на сишке

А это не будет транслятором, это будет редактором.

Следуя вашей же логике, у раста тоже может появиться компилятор на расте, поэтому он не является скриптухой.

Нет, он скриптуха еще и из за трейтов, и различных ограничений.

Гошечка тоже не является скриптухой, потому что у гошечки компилятор написан на гошечке.

Тоже самое, только тут еще и GC.

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

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

Царь не дает четкого определения. Скриптухой он называет все, что ему субъективно не нравится.

Тоже самое, только тут еще и GC.

GC не превращает язык в скриптуху.

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

Але, царь ратует за ограничения.

Наоборот, с чего ты взял то?

Что до трейтов - это никак не противоречит его определению.

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

Царь не дает четкого определения.

Не скриптуха: Развитая система типов + Управление компилирующей средой включая метапрограммирование + Отсутствие райнтайм привязок + Нормальная кодогенерация.

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

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

paramon
()
Последнее исправление: paramon (всего исправлений: 4)
Ответ на: комментарий от paramon

Наоборот, с чего ты взял то?

С того самого, о чем ты следом написал.

Развитая система типов + Управление компилирующей средой включая метапрограммирование + Отсутствие райнтайм привязок + Нормальная кодогенерация.

Первое и последнее вообще субъективщина. В плюсах есть рантайм. Плюсы - скриптуха.

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

По этому определению питон (сюрприз) является скриптухой. Что интересно, метапрог при этом не является скриптухой, в то время, как по царскому «определению» он самая галимейшая скриптуха как есть.

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

Не-скриптуха - когда компилируется в бинарь

То что для питона есть компилятор я думаю ты и так знаешь, но он и для баша есть, там правда транслятор в С, но бинарник на выходе имеется, и что, баш теперь не скриптуха? Не работает твое определение.

paramon
()
Последнее исправление: paramon (всего исправлений: 1)
Ответ на: комментарий от paramon

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

Все отлично работает, если включить башку.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

Питон собирается по сути в самозапускающийся архив.

Я не про упаковщики говорю, Nuitka переводит Python в С++, bash транслятор тоже самое делает, только не помню его название.

Есть еще GraalVM, если еще не позволяет, то скоро позволит компилировать JavaScript, Ruby, Python, но тут не точно, я не интересуюсь этой темой.

paramon
()
Последнее исправление: paramon (всего исправлений: 3)
Ответ на: комментарий от paramon

На мой вкус принципиальной разницы нет. Это прожеванный libpython. Но на самом деле это вполне себе компиляция. Курить проекции Футамуры до просветления. Формальные определения не содержат никакого требования к рантайму. Все, что царь себе там нафантазировал - его личные заскоки.

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

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

Надо понимать, что все эти проекты - частные случаи. Царское «определение» - это крайность, которая отрицает любой рантайм. Формальное определение от умных людей утверждает, что компиляция есть компиляция, и пофигу, что там в рантайме.

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

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

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

---------------------------------

Это прожеванный libpython.

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

Можно написать интерпретатор сишки и в таком случае она превратится в скриптуху.

Так сишка и есть скриптуха по царю, нормальная сишка это именно gcc + gnu c, и то она не позволяет в метапрограммирование, но хотя бы не мешает рантаймами.

Можно сделать компилятор для подмножества питона, не используя libpython, и он станет чисто компилируемым.

Но по царю скриптухой он не перестанет быть, а вот по википедии перестанет.

Хотя уже сейчас питон трудно назвать скриптухой (по википедии), вроде бы компилируется в байткод, java тоже так делает, но считается компилируемой а не скриптовой.

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

Используя LLVM выше плюсов скакануть нельзя

А что ты понимаешь под «скакануть выше плюсов» в данном контексте? Что конкретно нельзя сделать?

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

Нет, он скриптуха еще и из за трейтов

Трейты-то тут при чём?

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

Управление компилирующей средой включая метапрограммирование

В Си нет (ну если макросов не считать, это не Си, это препроцессор). Си — скриптуха!!!

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

bash транслятор тоже самое делает, только не помню его название.

SHC?

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от paramon

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

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

Тот же царь сначала гнал на кресты, признавал только сишечку. Потом он осилил некоторое подмножество крестов, и случилось чудо — кресты перестали быть скриптухой.

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

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 3)
Ответ на: комментарий от hobbit

Что то новое придумать не так то уж и просто %) Проблема не в том что чего то не хватает, а в том что Rust не прыгнет выше С++, зачем такой язычек нужен?

paramon
()
Последнее исправление: paramon (всего исправлений: 3)
Ответ на: комментарий от paramon

C# скорее всего так же компилируется, да многие язычки…

Нет.

Так сишка и есть скриптуха по царю, нормальная сишка это именно gcc + gnu c

Совсем поехал.

Но по царю скриптухой он не перестанет быть, а вот по википедии перестанет.

Из чего легко увидеть, что царь невменяем.

вроде бы компилируется в байткод

Вот именно потому что у тебя Python == Java из-за байткода, ты на пару с метапрогом и несешь бред. Стоит только чуть-чуть набрать знаний в голову - и всякие цари не понадобятся.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от hobbit

Вот! Вот это почти точное определение. Удобное. Для царя, исходя из его вкусовщины. Для других (в частности, меня) оно нелепо и неинформативно, поскольку сваливает в одну кучу разные вещи. Тот же царь сначала гнал на кресты, признавал только сишечку. Потом он осилил некоторое подмножество крестов, и случилось чудо — кресты перестали быть скриптухой.

@paramon, @metaprog: итак, истинное определение скриптухи по царю. Скриптухой является то, что не осилил царь.

@hobbit: ты случайно не в курсе, где можно посмотреть на гитхаб царя, например? Он чем-то вообще занимается, или просто сидит и теоретизирует своим бредом?

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

О, уже?

История текущего репозитория начинается в 2010-м, когда Rust перестал быть личным проектом. И там с первых коммитов компилятор уже развивался на Rust. В 2011 они окончательно выбросили bootstrap-компилятор на OCaml, и с тех пор, чтобы собрать компилятор Rust, нужен компилятор Rust.

Он все также использует LLVM?

Ну да. А с чего бы ему с LLVM уходить?

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

Молодцы какие. Вполне самодостаточный язык.

А с чего бы ему с LLVM уходить?

Чтобы перестать быть скриптухой по царю)))

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

Вот именно потому что у тебя Python == Java из-за байткода, ты на пару с метапрогом и несешь бред.

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

итак, истинное определение скриптухи по царю. Скриптухой является то, что не осилил царь

Он подробно разбирает почему язычек является скриптухой, можно его и попросить если он появится на ЛОРе. Всякие дарты, жаваскрипты он знает, хоть и скриптуха.

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

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

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

Ты не додумывай

А чего мне додумывать. У вас одно определение противоречит другому. И да, я правильно понимаю, что LLVM+CLang - это тоже скриптуха?)))

Он подробно разбирает почему язычек является скриптухой

Еще бы он делал это объективно, а не в соответствии со своим манямирком - было бы здорово.

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

я разработчик микрософт

Окей, поржем, никаких проблем.

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

У вас одно определение противоречит другому.

Ну я написал как отличить скриптуху от нескриптухи, никакие части там друг другу не противоречат. Если тебе кажется странным что x86+libpython это все еще скриптуха, то это не противоречие...

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

Входит. И как это чему то противоречит? Можно считать это бредом, но по царю Python является скриптухой, как и должно быть. Вообще бессмысленно на эту тему спорить, я вот так понимаю скриптуху, и все, считаю что это очень удобно и понятно.

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

Вы давайте это… логику не включайте, тут и без логики провалы в релизах.

Меж тем, в одном интересном бложике, некто из обсуждения выше уже в паре последних статей говорит о том что у с++ нет будущего, и обсуждает проект llvm и clang в копроэпитетах. Кто же станет новой вайфу после с++…

abcq ★★
()
Последнее исправление: abcq (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Ты тоже забавный.

LLVM «заточен» под C++ примерно в той же степени, как x86 «заточен» под C. Либо ты понимаешь, о чём речь, и тогда это просто попытка потроллить. Либо не понимаешь, и тогда в свете того количества докладов, которые ты смотришь, это печально,

i-rinat ★★★★★
()
Ответ на: комментарий от fsb4000

Кстати, ткнул в середину, где-то около 23:17. Докладчик говорит об erratum в процессорах Intel, где со старым микрокодом условные переходы Jcc и смерженные op-Jcc вызывают глюки, если они пересекают или касаются границы в 64 байта, а с новым микрокодом такие инструкции просто тормозят. И отдельно упоминает, что граница относится к «таргету», а не к самому представлению инструкции. Возможно, он что-то другое имел в виду, но я бы понял jump target как адрес, на который происходит переход.

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от paramon

Мало ли что ты там считаешь. Есть формальное определение. Оно работает. А есть бредни царя и ваши с ТСом маня-фантазии. Тут нечего понимать.

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

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

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

Свою позицию я тебе объяснил, что тебе еще надо? Что бы я передумал? Так твое мнение в этом треде имеет нулевую ценность, можешь не стараться, скомпилированный питон для меня всегда будет убогой gil-скриптухой, а вот рассказать почему так всегда могу.

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

Да он всегда про это писал. Его цель улучшить С++, о чем тоже был пост, правда он еще лет 5 назад (не помню) говорил что будет делать убийцу сишки...

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

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

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

У меня его нету.

Просто если у тебя за душой нет ни одного проекта

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

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

Ну, показывай, раз достаточно.

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Если совет исходит из царя это ценный совет, если из ликсуса то это бесполезный совет. Все просто.

Ликсус выдает советы не разбираясь в теме, говорит например что на СУВТ надо забить (хотя это ценная штука которая в метапроге вообще важна, как указатель в С), перейти на Go (о его проблемах я уже писал), итд, это все уже разбиралось 1000 раз, перечитай если хочешь.

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

Чтобы судить о моих советах, достаточно попробовать им следовать.

Ну ты попробуй сначала нормально расписать какой план создания антиметапрога должен быть, типо надо взять Go, для GUI - Qt, для хранения диаграмм SuperProtoSaveBuf итд.

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