Вот пишут, что

You can also assume that pointer types are atomic

https://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html

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

А __int128 быстрее или медленнее чем 64-битное?

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

В данном случае это чтоб работали факториалы и числа Фибоначчи на как можно больших числах.

Да не нужно это никому. Это же просто демки. Кстати, если раньше еще можно было понять, что на этих диаграммах происходит, то пример с числами Фибоначчи, там вообще ничего не понятно. Куча блоков с символом «>», мешанина какая-то.

Значительно.

Не стоит завязываться на это все же.

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

Но лучше подобные контейнеры сделать создаваемыми пользователем, штука полезная, можно и сделать контейнер с подсчетом ссылок int rc; что бы удалять значения по их заканчиванию.

Замедлится ли код, если все переменные сделать atomic? Нужно чтоб параллельные треды не конфликтовали при, скажем, перезаписи указателя или структуры.

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

Еще немного, и ты изобретешь GIL

метапрог = убогая скриптуха

На дне живет питон, который медленнее пхп.

metaprog, когда наконец твой транслятор научится не высирать все в мейн? Как валгриндом-то пользоваться?

Гы-гы-гы, котечка на что-то обиделся, опять самозабанился.

Фибоначчи, выглядит она так: https://i.postimg.cc/D0W8v7XZ/image.png

Господа, вот даже не соц. опрос, а просто опрос. Ответьте, если можете.

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

Циклом:

proc fib n {
    lassign {0 1} a b
    while {$n > 0} {
        lassign [list $b [expr {$a + $b}]] a b
        incr n -1
    }
    return $a
}

puts [fib [gets stdin]]

Простая рекурсия:

proc fib n {
    expr {$n < 2 ? $n : [fib [expr {$n - 1}]] + [fib [expr {$n - 2}]]}
}

puts [fib [gets stdin]]

Хвостовая рекурсия:

proc fib n {
    proc fibt {a b n} {
        expr {$n <= 0 ? $b : [tailcall fibt [expr {$a + $b}] $a [incr n -1]]}
    }
    fibt 1 0 $n
}

puts [fib [gets stdin]]

ЗЫ: Метапрог, почему у тебя на входе схем всегда константы? З0 версия метапрога, а до сих пор не осилил ввод с консоли?

ЗЫЫ: Метапрог, давай посчитай с помощью метапрога милллионное число Фибоначчи, моя убогая скриптуха посчитала за приемлемое время. Печатать его сюда не буду, потому что оно настолько огромно, что столько атомов в видимой вселенной нет.

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

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

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

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

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

На третьем питоне за примерно 13 секунд на моей древней машинке

У меня тоже не слишком свежее железо, на питоне 11 секунд, на тикле замерять не стал, там явно больше минуты. Код на питоне такой:

def fib(n):
    a, b = 0, 1
    while n > 0:
        a, b = b, a + b
        n -= 1
    return a

print(fib(1000000))

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

На C тоже есть «biginteger»: gmp

Для Visual Studio C есть форк: https://github.com/BrianGladman/mpir , так что это не только для gcc решение…

https://wandbox.org/permlink/cTAgfBWejfhFPHi7

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

На C тоже есть «biginteger»: gmp

Вон же Метапрогр утверждает, что в метапроге легко и просто использовать Сишные библиотеки. Пусть покажет, насколько это легко и просто.

Ты на Си написал, а не на метапроге, как просили.

Ты на Си написал, а не на метапроге, как просили.

Да, посмотрим как метапрог сможет использовать сишные библиотеки. Но просто сменить типы с __int128 на mpz_t и операторы на функции должно быть не так сложно.

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

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

должно быть не так сложно

Так ведь и редактор графов сделать должно быть не так сложно. И кодогенерация из графа тоже не должна быть сложной.

Давно меня не было. Ну что там у нас, ага, многотиповый тип, переключатель,СУВТ.

Собственно за пол года ничего не изменилось, когда там метапрог на самом себе?

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

самозабану его ручного клоуна

А это кто тогда?

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

Собственно за пол года ничего не изменилось, когда там метапрог на самом себе?

С дивана, конечно, легко судить как все медленно. Это ж ведь не делать самому, со стороны всегда виднее, так ведь?

На лабвью я вот сделал, но это не так уж и просто как кажется с дивана.

Открыть много окон SDL2/nuklear в параллельных потоках одного процесса

Версия 31

Подробности в заголовке

Похоже новая ипостась.

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

Версия 31

Подробности в заголовке

доработка транслятора для трансляции циклов, включающих в себя жесткие последовательности

Т.е трансляция циклов, включающих в себя «мягкие последовательности» до этого нормально работала?

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

Ты просто вдумайся. Это поделие пилится уже ДВА года, а в нем до сих пор глюки с элементарными циклами.

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

Лучше сначала видео мне запишите

Чем картинки не устраивают? Так и трансляцию можно не понять. На вход подается struct { size_t len; T *p; }; без преувеличений, я думаю это все что нужно понимать.

цирк уже сворачивается

Каждый раз проигрываю! https://youtu.be/hMM5bZu5KEs?t=14

Ничего заменять не нужно будет, метапрог гибкий. Мат.Операторы это функции принимающий на вход std::variant<short,int,float,...>, можно просто добавить в этот variant новый тип mpq_t из gmp, и в диаграммах Мат.Операторов добавить ветку в switch которая новый тип будет обрабатывать. В итоге можно будет сменить только тип входных чисел ака констант.

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

По сути есть тот же DOM, состоит он из СУВТ, при этом кастомные компоненты описываются двумя способами:

• С помощью компоновки СУВТ
• С помощью immediate отрисовки через nuklear, этот способ более гибкий, но в скорости разработки совсем не уступает первому, плюс удобно биндить данные

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

metaprog, ты опять прячешься от неудобных вопросов? Повторюсь: почему у тебя спустя два года разработки до сих пор глючат циклы?

А почему питон существует уже 30 лет, а все еще не может в многопоточность, тормозит, и постоянно стектрейсит? Наверное без каких то «сакральных знаний» все же не получится сделать нормальный язык?

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

Трансляции как раз таки более понятные, но вы почему-то на этот раз не приложили их.

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

А почему питон существует уже 30 лет, а все еще не может в многопоточность, тормозит, и постоянно стектрейсит? Наверное без каких то «сакральных знаний» все же не получится сделать нормальный язык?

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

В метапроге появилась лучшая концепция построения gui,

которая

позволит

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

С дивана, конечно, легко судить как все медленно. Это ж ведь не делать самому, со стороны всегда виднее, так ведь?

Так ты выложил свой продукт в открытый доступ, открыл тему в открытом доступе. Следовательно - имею право.

Я это уже годы слышу

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

Она уже существует и позволяет.

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

Это было бы визуальное построение интерфейсов. В метапроге этого нет, и не будет.

Только нужно еще приложения сделать для демонстрации

Сделать можно и ос на асемблере, это не значит показать преимущество асемблера в написании ОС.

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

Налицо явный спад активности в темах и интереса к ним.

Сейчас посмотрите эту схемку по ссылке и посмотрите код на тикле. Во что вы быстрее сможете вьехать?

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

Даже не имея представления о том, что есть «Числа Фибоначчи», приложив усилия можно разобраться в логике того, что написано.

В логике кубиков с стрелками я разобраться лично не могу. Потому что я не знаю что они значат.

Ему бы для начала таблицу сделать «Иконка квадратная» - это, «Иконка треугольная» - это.

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

Лучшая концепция построения гуя - это всякие дизайнеры

Нет, плюс сложности с динамикой - Современные погроммисты (комментарий)

Сделать можно и ос на асемблере, это не значит показать преимущество асемблера в написании ОС.

А то я не знал, преимущества я уже называл, скорость разработки и простота. Qt, Gtk, wxWidgets не дадут тебе так просто описывать интерфейс, опциональную реактивность, и удобную привязку данных к шаблону который можно запустить в foreach каком нибудь.

Нет, плюс сложности с динамикой - Современные погроммисты (комментарий)

Частный опыт и мнение, имеет право. Но выдавать за пруфы, чей-то личный опыт в виде комента на лоре, это конечно обсёр.

скорость разработки и простота.

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

За 2 года имеет недочат, сам кривой метапрог который глючит и лагает, будильник. Даже представить сложно как вы добились такой выдающиеся скорости, простоты и эффективности (нет).

Частный опыт и мнение, имеет право. Но выдавать за пруфы, чей-то личный опыт в виде комента на лоре, это конечно обсёр.

Ты просто нулевый и не понимаешь очевидных вещей, зачем ты вообще пытаешься спорить? Как ты например будешь через редактор форм привязывать компоненты к данным? А даже если привяжешь (как именно не представляю) то все равно редактор будет бесполезен если компонент активно меняется в зависимости от данных, и ты все равно не сможешь увидеть как он себя поведет.

Собственно что твоё утверждение, что моё - практикой не подтверждается.

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