Байткодирование for.
В общем-то осталось немного для байткодирования. each, вызов функций, raise и yield. Ну ещё структуры всякие, типы, классы, переопределения операторов. Ссылание, получение элементов объектов. И парочка мелочей.
И это совсем не всё. Ведь есть ещё препроцессирование — condition compilation, импорт библиотек, темплейты, макросы.

Смотрите, как у меня реализован тип func. Так как func и proc можно переопределять, надо сделать как-то, чтобы это можно было делать. К функциями можно складывать другие фукнции, то есть, конкатенировать код. Хотя я ещё не со всем разобрался, например, с ретурнами.
Есть переменная functionname.bundle, которая содержит указатель на машинную функцию (процедуру), указатель на такие указатели и пустой int, всмысле, бесконечное целое число. Изначально можно присвоить одни инструкции для этой функции и эти инструкции будут в functionname.bundle. Есть процедура functionname и она исполняет все функции из functionname.bundle.

Ох, ну и пасту я написал...

Добавил поддержку мултисравнения.
В Лайси можно сравнивать между собой сразу несколько значений. То есть a < b < c d эквивалентно (a < b) && (b < c) && (c d).

Кстати, у меня в коде компилятора сделаны как бы ленивые вычисления не путайте, это не ленивые вычисления языка. В Лайси инструкции исполняются там, где программист написал. Не вижу смысла в реальных ленивых вычислениях. Он не считает 5 + 3, раз результат некуда записать, но когда он приравнивается в переменную, то начинает проходиться по всему выражению. Это можно увидеть в том, что в "байткоде" сначала вычисляется 3 > 1, а потом 5 > 3, а не наоборот.

Помню раньше я рвался писать Лайси-библиотеки, но компилятор совсем не был готов, я даже простые выражения не мог компилировать. Теперь ситуация получше, но библиотеки не очень хочется писать. Надеюсь, я не перегорю.
Задумал целую абстрагированную инфраструктуру по производству программ на Лайси.
В самом корне идёт Лайси как язык программирования, ниже (или выше, главное — дальше) идёт либлайси-библиотека. В эту библиотеку я собираюсь засунуть некоторые функции, такие как max, min, clamp, bigendian, littleendian, floor, round, ceil, другие и функции по управлению памятью, а так же по выводу ошибки после assert.
Затем идут библиотеки по работе с памятью и математикой. mem и math. mem включает в себя н-мерный тензор, в который можно аппендить, инсертить элементы или решейпить его дименшионы. Записывать и читать значения элементов по индексам, опционально флоатскому индексу, интерполируя значения по заданной функции; всякие ассоциативные массивы типа деревьев и хеш-таблицы и ещё чего-то. Возможно тут будут такие функции как startswith, endswith, split и всякие другие, функции для взаимодействия со строками и их разбиения, сращивания, сравнения. Но может быть это будет в liblaisi. У меня тут коды перемешались.
math это библиотека для всяких разных численных методов, но не математических движков. То есть синусы, косинусы, факториалы, умножения матриц, комплексных чисел, но не дифференцирование или интегрирование функций.

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

Всё. Пора заниматься серьёзными вещами и вводить репрезентацию как на втором пике.
Это будет сделать непросто. Во-первых, надо значительно переделать препроцессинговую часть, добавить @for, @if, @elif, @else, @end, сделать несколько препроссинговых функций, который возвращают True/False в зависимости от дефайнед ли или есть какая-нибудь функция.
Во-вторых, мне придётся частично сделать библиотеку mem, а для этого заново ввести alloc, vary и del.
В случае с repr, думаю, будет переопределяемая функция _repr_. Её можно будет определить для своего типа, получать указатель на переменную + "строковые аргументы", а возвращать mem.string.
Строковые аргументы это для форматирования. Например format("value: {x} : {02}",a,b) в первом случае даст 'x', а во-втором '02'. Таким образом можно указать _repr_ инта в первом случае выдать шестнадцатиричное число, а во втором с двумя лидирующими нулями (если число не больше).
И как раз функции hasoperator и operatorof будут давать возможность обращения к перегруженным функциям.
Я всё побаиваюсь, что LLVM или Я не сможет правильно оптимизировать возвращение или передачу больших структур, например mem.string. Всмысле не их самих, а и их контента. Ведь очевидно, что если я хочу передать mem.string в качестве аргумента или приравнять его переменной, то надо и контент скопировать, иначе можно было б просто указатель кинуть.

Кстати, недавно я осознал важность возможности переопределения таких операторов как +=, *=, %= и прочих. В C++ я жаловался, да зачем мне лишний раз переопределять, просто плюс используй, а потом приравняй. Но потом я задумался надо булевой геометрией и понял, что иногда надо применить булевую операцию на меш и сразу его изменить, а иногда нужно сохранить прошлые переменные. Например можно переопределить | и |= для условных структур мешей по разному и будет так: c = a | b; d |= e; В первом случае a и b сохранятся, а в c будет результат их юниона, а во втором случае контент d не сохранится, вместо этого юнион сразу применится на d.

Добавил пару поддержек в компилер, в особенности перегрузку функций и посыл аргументов в перемешанном порядке. Но я особо не проверял и работоспособность очень частичная.
Знаете, перегрузка функций и темпелйты это такая фигня! Ведь когда мы хотим вызвать функцию в си-подобном языке, мы на самом деле вызываем адрес. А название функции это просто константная переменная, которая содержит адрес самой функции/процедуры. А когда мы хотим вызвать несуществующую функцию, то есть либо создать её динамически (темплейт) или найти её настоящее название используя мнимное + аргументы, это уже что-то совершенно иное.
Из-за этого часть кода Иколайси сейчас в хаосе.
Но перегрузка функций необходима, чтобы, например, работала функция print. Ведь она будет вызывать функцию repr, которая перегружена для некоторых переменных некоторых библиотек, если автор библиотеки захочет.

Пока с max и min из liblaisi не разобрался. Чтобы начать нормально парсить, мне надо перевести Иколайси с pyparsing на прототип библиотеки dapa на питоне. Он уже более-менее готов, некоторые правила работают, но я всё ещё раздумываю какая архитектура там должна быть. Просто моя библиотека парсинга будет немало отличаться от pyparsing.
Тогда я смогу парсить препроцессинг не императивно, а декларативно, а вместе с ним разобраться со всякими эллипсисами.

Ещё я немного порезал стандарт Лайси, чтобы побыстрее выпустить первую работоспособную версию Иколайси и не заниматься неважными фичами.
Но что самое страшное, мне придётся в первой же работспособной версии научиться исполнять Лайси-код во время компиляции. Ну типа 5 равно 5 или не равно. Это нужно для некоторых типов. Например, в библиотеке math будет тип vec!N!, а у него настроен @assert, что если N == 0 (размер равен нулю), то будет ошибка.



>>8669
Слышь, это для тебя компилятора нет, одна нога тут, другая там, сердце слоями валяется, а череп по швам распадается.

Вот отличие между pyparsing и моим прототипом dapa, написанном на питоне. Парсилась одна и та же строка.
Тут я не уверен, стоит ли как-то ангроупить токены или что вообще с ними делать.

А может ну его. Зачем мне в инфраструктуре Лайси слой байткода? Я тут подумал, что он не нужен, лучше сразу компилировать Лайси в LLVM IR. Ведь если и подумать, то лайси-байткод почти полностью был подобен LLVM IR, там разве что тензоные инструкции были, ещё и с указателями.
Кстати, недавно у меня снова чуть не случился приступ высокоуровнезации стандарта Лайси. Я подумал, что обычные поинтеры это так боринг! Каждый раз переудалять их, следить за количеством. С шейред поинтерами всё гораздо легче. Вот тот же питон по сути и состоит из шейдер поинтер PyDecref PyIncref или как там в CPython. Конечно, я планировал, что shared ptr будет в библиотеке mem. Но тогда пользователю придётся всё время писать mem.shr<T> или shr<T>. А если сделать суффикс типа подобные звёздочке? Например &. structname& — shr<structname>. Но это же тогда в глобальных переменных придётся где-то выделять отдельную структуру под них... Не то чтобы это сложно или плохо. Просто если я буду вводить шейред поинтеры прямо в Лайси, то почему не ввести, например, вектор или ассоциативный массив? Всё-равно у меня стандартизировано обращение к куче через alloc, vary, del. Ну а там и треды можно добавить. Всё-равно обращение к куче требует локинга мьютексов, наверное.
Мне не так уж и сложно осталось всё сделать, но много. Из сложного надо продумать валидацию типов для вызова темплейтов (matrix[N][M] и matrix[M][N], например. Чтобы M и N были равны и оба были матриксами). Трудно когда приходится архитектуру расширять, ведь я всё время что-то не досматриваю.
В Лайси, кстати есть двойственность некоторых правил парсинга. То есть одни и те же правила похожи. Например, есть операнд обычный, а есть для alloc, vary и del и внутри себя они тоже могут иметь операнды, но последний тип не может иметь alloc vary или del.
Недавно я ещё понял, что операнды делятся на тензорные и скалярные. a[3:8] — тензорный, b — скалярный. Соответственно, a[5:2] + c[6:12] — тензорный операнд (типа expr). Но вот a[5:12]{+} (сумма, редюс с плюсом) уже будет скалярным.
У меня осталось ещё всего лишь 14 дней, чтобы выкатить первую настоящую версию Иколайси! Не уверен, что справлюсь, но я собираюсь справиться. Я недавно начал учиться планировать свою жизнь, пока что в небольших масштабах. Или предсказывать? В любом случае, где предсказание, там и самосбывающееся пророчество.

>>11860
>>11859
Ну ладно уже. Всё-равно видео были просто записью, не хочется писать в техподдержку.

>>11293
>BlenderCAM используй, поехавший.
Не уверен на его счёт. Думаю, мне придётся генерировать некоторые инструкции вручную.

>>12443
Незнаю, пробовал ли кто. На гитлабе всё ещё есть старый Иколайси, но у меня возникают бȯльные мысли, если подумать, что кто-то попытается использовать его хотя бы на имеющихся тестах.
Насчёт единомышленников в плане программирования это точно нет. Лайси это проявление меня. Точно не помню, почему я решил создать свой язык программирования 3 года НАЗАД, может из-за изоляционизма, может из-за NIH, а может я считал себя очень всемогущим в плане программирования (камон, работы на месяц-другой, а делаю уже 2-3 года), но скорее всего и то и другое. Но недавно я подумал и решил, что Лайси мне нужен, чтобы складывать в него и им же свои наработки.
Когда я пишу на C/C++-подобном ЯП, я в итоге тупо копирую куски наработанного кода из проекта в проект, а если создаю библиотеку, то выглядит она не лучшим образом (хотя всё-равно это облегчает всё). Кроме того, тех же возможностей C++ мне не хватит, иначе как я напишу define vec!N!<T> as class...?
Если Лайси со временем популяризуется спустя долгое время, то будет неплохо запускать не единомышленников, но фанатов/фанов/последователей.
Когда инфраструктура Лайси стабилизируется, можно будет внедрять чужие разработки на Лайси, если кто-то захочет написать библиотеку. Особенно, если библиотека маленькая или ориентированная на редкий интерфейс. Например, преобразование координат под гексы или API к какому-то редкому формату файлов.

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

Представляете, недавно захотел заснять видео Пайнфоном, а оказалось, что дефолтное приложение камеры Megapixels не умеет! ((((9((((999(
Не нашёл ничего лучше, чем начать писать своё приложение-камеру, вот разбираю video4linux https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/open.html
Только знаете, тут немного посложнее, нет просто файла для камеры, есть ещё всякие /dev/mediaX, /dev/v4l-subdevX. В пайнфоне как раз через mediaX делается. Если я правильно понял, то одно "устройство" владеет обеими камерами, то есть нельзя снимать одновременно с двух.
Кстати, незавершение начатых проектов больно бьёт по моей психике и потом я меньше занимаюсь Иколайси-Лайси! Нужно использовать волю для преодоления, ведь именно она расплавляет несуществующие стены.

Когда доделаю Иколайси, надо будет когда-нибудь в инфраструктуру добавить библиотеку camera — слой для взаимодействия с более-менее обычными камерами. Получить изображение, помигать светодиодами, получить аудио, настроить фокус, фильтры и всё такое.

Наверное так будет выглядеть math.vec по версии Laisi v0.8.
Думаю объяснять не надо, что тут написано, и так всё ясно.
Прежде чем выпускать компилятор, мне надо, чтобы такой вектор можно было запринтить.
Мне осталось ввести ещё где-то 22 фичи Иколайси (из 38, когда я начал переписывать его на C/C++-подобный язык). Но они разного размера. Если сгруппировать их, то получится, что надо ввести темплейты, классы, несколько функций препроцессинга, перегрузку операторов и функций, преобразование списковых и дикт-данных в типы, liblaisi и завершить тензорные+скалярные вычисления.
За этот месяц я почти ничего не ввёл, хотя за половину прошлого фич 15, мда. У меня много проектов, и работа, и антиработа, и новые таски, и старые таски, да и просто проекты.
Я вроде бы недавно говорил себе, ну не надо так много заданий куррентных держать, надо поменьше, а если уж держутся, то надо регулярно заниматься каждым, даже если по чуть-чуть (контекст не будет в глубокие части мозга отходить). Но чего-то не получается.
Вот за прошлый месяц мне надо было достичь трёх целей. В итоге я провалил все и только в этом месяце исполнил одну, а две другие (одна из них — Иколайси) валяются в половинчатом состоянии.
А на этот месяц у меня ещё 2 цели, хотя одну из них вроде не слишком сложно исполнить.
А ведь если бы я каждый раз, когда отдыхаю скучным отдыхом, занимался Лайси, осталось бы уже фич 10 или меньше ввести.
Кстати, некоторые фичи я вводил в компилятор, когда на питончике его писал, а теперь приходится заново вводить, лол (нет)

Ах да, я же в версию 0.8 собирюась добавить классы. Лайси это не ООП, но классы нужны для инкапсуляции. Чтобы не писать муторное normalize(vectorname), а vectorname.normalize(). Красивее.

Оуфигеть, еле скомпилировал пикрилейтед.
В итоге ввёл большую часть класса, ещё и self-тип. Можете поглядеть на LLVM IR, если поймёте что-то. Что закоментировано тоже работает, проверил.
В классах надо ещё ввести передачу self*. Потом пора будет переходить к перегрузке функций и операторов. В частости, внутри классов можно будет писать методы для перегрузки init, del, index, get, set и другие одноаргументные.
Перегружать операторы сложения, умножения и прочих двуаргументных как-то мне видится некрасивым. Лучше их писать отдельно, к тому же те же вектора math.vec надо иметь возможность складывать, у которых разные подтипы. Например vec3<ssize> и vec3<float> и написать просто template with V0(vec!N!<T0>),V1(vec!N!<T1>) func (V0 out,[V0 in0,V1 in1])...
А в случае именованных классов это же на самом деле макросы, представляющие из себя дженерики и если сделать add методом, то можно, чтобы только один тип самого себя принимался.

только заметил, что функция метода называется .m0, а не abc.m0, надо исправить

>>13061
Ок.
В последнее время он у меня просто лежит. С отключенным вайфаем заряд держит 2+ дня. Думаю, в течение пары недель всё-таки вставлю симку и начну использовать в обычном телефонном режиме.
Там ещё и тулиграм предустановлен, ну а я и не против. Хоть мессенджер и пророссийский, но во-1 что вы мне сделаете, я в другой стране, во-2 клиент с открытыми исходниками, удобно, в тетих я в другом городе что вы мне сделаете (соре за отсутствие мата я его ненавижу). Для деловых переписок подходит, если надо будет сойтись с кабанчиком где-нибудь. А ну и с гугл-картами даже в квартальном лесопарке будет сложно заблудиться.
Хотя я же когда-то делал ПО под названием nnaamapeiko, но так и оставил какую-то демку сферы с натянутыми спутниковыми снимками, лол. Надо будет когда-нибудь натянуть OSM, викимапию и те же снимки и устроить удобную навигацию. Благо, в пайнфон можно вставить очень много гигабайт SD-карты, так что теоретически можно закачать и карту половинки мира и википедию с советами по выживанию ха.

А по-хорошему надо самому научиться производить КПК. А для этого нужны процессоры, RAM, МЭМС-акселерометры, КАМЕРЫ, накопители, ну и, конечно же, дисплеи. Думаю, самое сложное здесь это процессоры/RAM и камеры. Для микроэлектроники я вижу 3 пути: кремниевые, вакуумные или органические транзисторы. Несмотря на все сложности, мне кажется, что кремниевый путь наиболее простой. Но я не то что кремний добывать, я даже выращивать кристаллы даже олова не умею. Мне надо для начала печь новую построить. Я разделяюсь между двумя путями — газовая и индукционная. Я думаю, что индукционная лучше, но у меня так мало знаний электроники, я просто не понимаю что к чему. И точно ли графитовый тигель будет разогреваться? А если пытаться выращивать кристаллы в индукционной печи, то не скажется ли магнитное поле на структуре?
В общем, наверное, надо оба варианта строить, наверняка у обоих есть свои преимущества и недостатки, которые я пока не вижу. А может даже и муфельные печи могут сюда протиснуться. Электрическая, но без лишних магнитных полей и может быть для большого объёма индукционной печи пришлось бы очень страшную электронику ставить, аж искры из глаз полетят, мда, не подумал я об этом.

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

Я слишком много на себя беру...

Опять я не сделал Иколайси. Из того, что помню, ввёл оверлоады функций и начал вводить оверлоады операторов (операторов много). Но этим я уже занимался в питоновской версии компилятора. Если думать такими темпами, то мало ли когда Иколайси выйдет. В Октябре. Или вообще в Ноябре...
Наверное это всё из-за нечто, что я пока назвал выученной ленью. Как только в каком-либо проекте я ввёл фичу, то мозг думает "О, теперь можно и отдохнуть", хотя отдых этот на самом деле очень скучный зачастую. Не знаю когда у меня началась прогрессировать данная психическая проблема.
К тому же у меня очень много проектов и просто дел. Распыление ведёт к ухудшению ситуации. Ну почему, я же и так сузил свой сектор областей деятельности до такого минимума!
Если журналюхи не наврали, то Никола Тесла говорил/писал "Когда у меня возникает задача, я набрасываюсь и набрасываюсь на неё, пока не будет решена". Ну поняли, это как вода точит орешки золотые, пока не останутся ядра чистый изумруд.
Если бы я действовал по такому принципу, то мог бы уже достичь всяких целей. Мне надо как-то прокачать свой разум?
А ну ещё я пострадываю от того, что почти не могу использовать уже готовые технологии. Например, когда чад в годоте или юнити набрасывает ассеты очень художественно и выпускают игру на миллиарды, я в своём графическом движке пытаюсь ввести скиннинг! То есть позирование, джоинты, кости эти все. Но я не знаю как вообще можно отказаться от своих низкоуровневых технологий, когда они уже есть, хоть и на таком маленьком уровне.

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

Вот я уже почти 5 лет в мире программирования, а до сих пор почти ничего не умею и не знаю. И не только в программировании.

Недавно мне дали задачу, совершенно простую для 2021-го года: сделать программу, где можно на картинке выбирать объект интерьера и будет создаваться его 3D-моделька Directed by Robert B. Weide я попросил пример поконкретнее и мы остановились на просто прямоугольных объектах типа окон, плитки или чего-то ещё
И вот я вспоминаю, что недавно игрался с фильтрами, сделал что-то типа канни фильтра, и вот никак не могу вспомнить куда я положил код свёртки.
Начинаю злиться ну как так в ПИТОНЕ нельзя просто взять и свернуть что-нибудь. Опять что ли писать эту функцию, опять проходить ошибки, я не помню где я писал эти эксперименты со свёрткой? У меня более 100 директорий с разными проектами и кодами, как мне его найти?
Даже если бы Лайси и Иколайси были бы готовы к этому моменту, то и там возникли бы проблемы со свёрткой. Во-первых, вряд ли стандартные средства Лайси позволят написать свёртку в одну строку, так как при ней используются одни и те же элементы для вычисления разных значений (ну то есть, когда сдвигается на шаг, значение в правой и нижней частях подкернельной области используется).
Хотя в таком случае логичным назревает желание потом написать в liblaisi функцию для свёртки, чтобы не велосипедить. Но если писать такую функцию, то желательно сделать возможность свёртки не только квадратных (линейных, кубических) N-dim, в общем, массивов. Что если кто-то захочет свернуть поле из шестиугольников? Надо иметь возможность взятия значений по отдельной функции, которая будет принимать координаты или я даже не знаю, что. Надо подумать над этим.

В общем, потом я вспомнил про grep и быстренько прошёлся им, ищя название функции и нашёл код, день спасён.

Но я должен был стать к нынешнему времени полубогом программирования, почему я не могу просто сказать в любой части подконтрольной зоны "Главный компьютер, сверни-ка мне картинку по ссылке https://tratata.blablabla/img.webp сначала кернелем [[-1,-1...]], а потом кернелем [[...]]", после чего ко мне подлетит квадрокоптер с дисплеем и выведет на экран полученное изображение?
Хотя я даже базовые принципы программирования не знаю и не понимаю. Что такое SOLID, зачем нужно наследование? Как проектировать большие системы и как следить за своими функциями, чтобы они выполняли только то, что надо? Я знаю только про WET и DRY, но далеко не всегда следую им.

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

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

Недавно взял себя в руки и ввёл пару фич с пикрилейтеда. Улучшил взятие члена по указателю, методы, вот это всё. А справа валидация типов при вызове темплейта.
Но это на самом деле полухалтурные фичи. Как вы видите на картинке слева, я делаю ttt tz, а потом vvv.t.t = addrof(tz). А ведь можно было взять сразу из мммюе vvv.t. Просто в аддроф-вайпер я пока не пересылаю нормальные операнды, а только операнд-имя. Надо будет это исправить.
А справа хоть и есть валидация типов, но я не смогу написать что-то типа M0(mat!N!x!M!<T>), M1(mat!M!x!X!<T>) для умножения матриц, например.

Прежде чем выпустить новый, свежий, работоспособный Иколайси в свет, надо сделать так, чтобы можно было хотя бы запринтить вектор и умножить матрицы. Ну и читать-писать файлы, естесственно. Валидация типов темплейта нужна и для io.open, так как я планирую следующие варианты аргументов: u8[], mem.string, mem.vector<mem.string>. Первый это Null-terminated string (ну мало ли), второе это просто путь ('/root/secrets/mm.jta'), а третье это путь, но вместо слешей названия директорий/файлов (['/','root','secrets','mm.jta']). К счастю швиндовс понимает линукс-пути, но всё-равно такая дискриминация слеша в линуксе (посиксе?) это странность. Из-за него я когда-то не смог при помощи mctagfs (кстати, его тоже надо переписать, чтож это) ввести тег для картинок GNU/Linux. Ну в самом деле, '/' это 47. Это ни 0, ни 1, ни 2, ни 255, ни 254, ни 253 или что-то подобное, а 47. Что не так с этим числом я не понимаю. То есть из-за какой-то глупой кодировки менять судьбу всего.

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

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

>>13786
Ну да, к сожалению наличие одной лишь только всего лишь микроинфраструктурки SIM-карт и мобильной связи уже делает устройство непригодным для личного провождения. Для анонов такое не прокатывает. Когда-то я хотел сделать себе КПК на малинке, но малинка громоздкая и мне вообще страшно ею пользоваться, она у меня как человечек, живущий в коробочке из фанеры и подающий сигналы на устройства.
Можно ещё создавать КПК на базе микроконтроллеров, ПЛИСов и отреверсенных диспелеев и камер со смартфонов, но это так сложно! Лично я до сих пор не умею подавать сигналы на шлейфы всяких этих смартфоно-камер или дисплеев. А мог бы, можно было бы попытаться отреверсить. И ведь эти устройства качественные, у них много мегапикселей и для отображения, и для съёмки, а у камер ещё и фокусная линза умеет двигаться. неизвестно сколько лет мне понадобится, чтобы достить такого уровня. Я даже просто кремний не умею добывать! Я плохо знаю электронику! Можно попробовать пропустить силан сквозь 2 пластинки из нагретого 600+ °C металла с выфрезированной канавкой. Но как нагревать? Я планировал индукционным нагреваталем для пробы. А как охлаждать сочленение к трубке, через которую подаётся силан? Жтого я не знаю...
Вокруг очень много компаний, которые гораздо моложе меня, но при этом умеют создавать сверх-предметы и супер-программы. Их секрет заключается в распределённом мышлении, они не устают, потому что пока 5 сотрудников спят, другие 5 могут работать и разрабатывать, не отвлекаясь на разные задачи.

Еженерегулярный отчёт. Я опять почти ничего не делал, хотя мне осталось реализовать ещё аж 17 фич! Когда я это сделаю... Вот такие дела, когда много тасков одновременно на человеке, но на самом деле это нытьё и я мог бы прямо сейчас взять и пойти делать Иколайси дальше.
Дев-версия Иколайси уже достаточно зрелая, чтобы пробовать в мем-вектор. Вчера попробовал и сразу баги полезли.
Но так же одной из фич является ввести в liblaisi min, max, clamp, abs, sign. Это 7 темплейтов. Для max и min по 2 темплейта, так как я решил, что когда они принимают один аргумент, то пытаются найти значение из его элементов. А когда много аргументов, то сравнивают их между собой. Реализуется это через for и multiply (бывшее @for) соответственно. Ах да, я вспомнил, что вчера придумал как изменить архитектуру, а то сейчас у меня там дуализм развёлся. Почти одинаковый код исполняется, если мне надо просто получить тип операнда и если мне надо его скомпилировать. Тип операнда нужен, например, для sizeof или alloc/vary.

Кстати, недавно я писал про электрические печи, в общем я опять полную ерунду написал. Собрал экземплярчик муфельной печи с фехралевым тэном, а она разогрелась всего лишь до 500 °C за 35 минут! Но я ещё ватой не утеплял.
Так вот, суть в том, что это неправильная муфельная печь. Надо не фехралевую спиральку по стенкам прокладывать, а графитовую плоскую спираль прямо в пол ставить. На спираль поставить тонкую теплопроводящую, но электронепроводящую и теплостойкую пластинку (из корунда, мб?), если планируется использовать графитовый тигель. Чтоб не замкнуло. Ну или тигель в стаканчик положить.
Надо бы выфрезировать такую и затестить.
Кстати, ещё один способ электрического нагрева это пропускать ток прямо через тигель, но я недавно понял, что тогда же расплавленный металл тоже начнёт проводить и уменьшит сопротивление! Да и вообще я не понимаю, а достаточно ли напряжения будет падать на тигле? Будет там какие-нибудь 0.5 Ом, значит в проводке должно быть хотя бы менее 0.1-0.2 Ом? Электроника это непонятно, конечно...

Ну и пайнфон я испытывал с симкой. Вставил, включаю: Введите пинкод (от симки). Ввожу, отправляю — ничего не происходит. Ну и ладно. А я думал, что смогу иметь доступ в интернет с любой точки города. Но, похоже, это доступно только избранными. Получается, что пайнфон может иметь 3 полезных функции — 0. Камера. 1. Запуск консольных приложений (Если ночью захотелось посчитать чего-нить, то пишешь python и там считаешь) 2. Потенциально универсальный пульт для ваших робоподобных устройств. Если для андроида пришлось бы APK как-то генерить, то с линуксом вы можете хоть на питоне ГУИ-пультик набросать и сразу же начать использовать.
Кстати, у него и экран иногда начинает высокочастотно (заметно) мигать, или так было, а уже нет. Но только при включении и постепенно проходит. А ещё меня раздражает, что его надо заряжать каждые 2 дня! Если кнопочный телефон может неделю держать заряд, то со смартфонами всё сложнее. И вроде бы ничего не мешает в 3-4 раза увеличить толщину, поставить нормальные акки, причём съемные и чтобы одним движением сменять один другим, ставя разряженный на зарядку, а пока сменяется использовать заряд из соседнего буферного миниаккумулятора (или конденсатора?). Можно было тогда и корпус делать не из PLA или нефтяных водорослей, а металла, керамики, металлокерамики. Если мешает радиосвязи, то пусть антенны выводят наружу. И они ещё ставят 3 камеры на одну сторону, но почему-то забывают про торцы. Почему там нет камер? Можно было следить за своими пользователями, даже если смартфон лежит далеко на столе. Ну, раз уже следят.
Вместо этого всё направлено на стрижку бабла, а люди хавают. И запланированное устаревание внедряют. Я однажды заметил запланированное (хотя это могло быть и случайным) устаревание в клеевом пистолете! Там при нажатии кнопки всё время протерался проводок и через несколько лет он оторвался от нагревателя так, что не припаять. А ведь был самый первый и самый лучший клеевой пистолет, после него только одна фигня.

>>13935 (и выше)
Спасибо за охрану.

Ух, недавно ввёл 1.5 фичи. Я себя случайно деморализовал, из-за чего не доввёл assert (кстати, он тоже был в питоновской версии Иколайси). Суть ассерта пока что проста — это просто вызов отдельной функции (которая будет в liblaisi), выводящей сообщение об ошибке и завершающая программу. На второй картинке вы можете видеть такое (там, кста и другая фича со структом). Только я забыл про exit, да и в приниципе у меня сломался парсинг чисел, из-за чего endl это 10, а не 0xA.
Зато на первой картинке показаны методы mem.vector, которые компилируются. Но они тоже не совершенны, так как надо делать v->elms vary T[v->length + 1] (чтобы данные инициализировались под нужный тип). Но нынешний Иколайси так не умеет.

Ну хватит про программирование. Недавно я купил себе огромную графитовую дуру и пару часов отпиливал от неё диск, который теперь надо бы выфрезировать в тэн. Только у меня не оказалось лобзика подходящего размера. Я немного обнаглел в своих возможностях. Знаете, у графита очень низкая твёрдость — всего 1-2 по Моосу. А у меня как раз валялась полосочка какой-то стали. Я взял и нарезал в ней зубья, ею же отпилил. Надо будет по такому принципу сделать коронки и инструмент для вырезания цилиндра из глухого отверстия или как это назвать? Из канавки образованной коронкой. Незнаю как называются такие инструменты. Они позволят сделать из одного круга очень много тиглей, например. Так как серединка не будет выброшена впыль.
И вообще, это крутой бизнесс-план:
0. Научиться производить всё, что производит Китай
1. Продавать на 20% дешевле.
2. ?????
3. PROFIT!
Лишить КНРовцев миски риса и кошек-жён, а тайваньцев просто зарплаты и можно будет не пытаться создавать глупые, никому не нужные игры. К тому же я ни одной (кроме самой первой, лежащей на закромах интернета) так и не довёл до конца.

Ещё я заметил ещё один дефект пайнфона, а точнее его стандартного софта Megapixels. Это камера, но позволяет она сфокусироваться только один раз за сессию. Тапаю — происходит автофокус, больше этого нельзя сделать, не запустив программу заново. Мда. А своё приложение-камеру я как начал делать, так больше и не делал. ахахаха

>>14248
>А потом кристаллизовать его обратно, причём таким образом, чтобы он принял нужную тебе форму?
Технически да, но я подразумевал обычное литьё.
Конечно, я хочу в будущем научиться и просто кристаллы корунда выращивать методом Чохральского, но это уже высокие технолгии, скорее всего там надо будет реализовать индукционный нагрев, да и вообще сложную печь построить. С механизмом выращивания.

Я НЕ УМЕЮ ПРОГРАММИРОВАТЬ!

Долго не прикасался к Лайси. Я немного алчный человек, хочу денег и иногда приходится брать больше работы, чтобы получить их. Заодно и неплохих знаний приобрёл. Говорить каких не буду, но если вы парсите и анализируете все посты с разных имиждборд, то могли уже догадаться.

Попытался снова ввести фичу "Тензорные вычисления". Вообще, я сначала хотел сделать фичу перегрузки операторов, но потом вспомнил, что там есть перегрузка оператора перечисления или как это назвать: (10:15) это [10,11,12,13,14]. Можно использовать в for: for x in (0:num) или просто для заполнения массива arr[:] = (0:30:2). А чтобы ввести перечисление, мне надо сначала ввести тензорные операции.
И вот сделал я функцию, но ввёл только частично. Больше, чем в прошлый раз. Теперь поддерживается N измерений, а не одно. На картинке видна сама операция (ar2[1:10]...) и снизу в комментах то, как оно раскладывается в компиляторе.
Но есть 2 проблемы: 0) если step (шаг) меньше нуля, то надо уменьшать соответствующий counter на нужное число и при этом в условии ставить противоположное сравнение. А для этого придётся добавить (в раскрытии выражения) переменных-флагов или ещё что-то. 1) нельзя указать x[0:], то есть stop надо указывать явно. Дело в том, что если это массив, то надо к нему взять lenof-операнд, чтобы понять, какой у него размер. Но если вы посмотрите на нижнюю операцию (с двумя измерениями, тоже уже компилируется), то там в самом левом операнде 3 постфикса-индекса. Просто последний не является частью всей этой тензорной операции, это просто индекс. И надо будет как-то сложно lenof-операнд брать.
Кстати, ещё тут можно оптимизаций всяких наделать, например, если степ это константа, а не переменная, то можно сразу выставить нужные операции. И ещё тензорные операции между простыми типами сделать при помощи LLVM-векторов, которые преобразуются в архитектурные SIMD-операции. Последнее я уже делал в питоновской версии. Но все эти оптимизации на будущее! Сейчас не время!
Мне осталось ввести ещё 14 фич.

Кстати, я ещё недавно думал и решил, что следует объеденить функционал типов T* и T[] в один T*. То есть, T* будет поддерживать и T-> (референс), и T[x] (индексация) как зижке. Просто, возможно, в будущем я больше приобъеденю mem к самому Лайси и можно будет вместо mem.vector<T> написать T[], вместо mem.HashTable<T,K>/mem.map<T,K> (не решил) T{K}, а вместо mem.shr<T> T&. Ведь же все эти вектора и шейред-поинтеры используются так часто в нормально проргаммировании!

Сайд: я снова запускал и совершенствовал свою печь, в общем люминь плавится, но сессия печи составляет где-то 2.5 часа. Результат не плохой, хотя в своей прошлой, угольно-воздушной печи делал это за 20-30 минут. Но со временем сноровка пропала, а тигли перегорели и я разучился плавить алюминий. Пробовал ещё переплавить стружку, которая у меня поднакопилась, так столко шлака образуется! Надо перемешивать чем-то, но страшно. Ведь тэн выпирает и под напряжением из сети.
И графитовую спиральку дофрезеровал (ок, приваси, го-го, пик-фотка, ориджинал-контент). Но сопротивление от конца до конца где-то 1 Ом, если не меньше. Наверное, надо отверстий наделать, образовав фермы. Чтобы в прочности сильно не потеряла, но средняя поперечная площадь уменьшилась.
Вдруг графитовый прямой нагрев окажется в некоторых областях лучше индукционки?

Пока я колупаюсь в Лайси и других штуковинах, тысячи людей по всему миру создают нейронки, генерирующие изображения! и другие крутые штуки https://habr.com/ru/company/sberbank/blog/586926/
Я вообще-то тоже хочу создать [УДАЛЕНО] на базе ██████████████████████████████████████████████████████, чтобы кое-что делать с ██████ и ███████████.
Похоже, скоро придётся дифференцироваться.

Но пока доделал тензорные вычисления (с парой оговорок, но это потом можно ввести, в последующих версиях). Как вы можете видеть на картинке, верхняя строка (только она закомменчена тут) в компиляторе раскладывается приблизительно на то, что ниже. Тут можно ввести много оптимизаций.
Осталось 13 фич. Самые сложные это 37. iterexpr ((X:Y:Z)), 36. reduce (W[X:Y:Z]{operator}) и 17. перегрузка всех операторов (как и сами операторы). Может уже пора выпускать в этом месяце Laisi v0.8 и Иколайси v1.0?????????????????????????????????????????????????!?????????????????????????????????????????????????????????????????????????????????

Я зашёл в тупик. Ввёл недавно iterexpr перечисления ((x:y:z)) в некоторой степени, но когда начал reduce, всё пошло как не надо.
Почему часть Лайси я раскрываю через другой Лайси, а часть компилирую в LLVM IR? Желательно побольше раскрывать через сам Лайси. Вот for у меня сейчас компилируется в LLVM IR, но почему бы не в лайсишный while? И вот редюс тоже надо было раскрывать через Лайси, а не пытаться комплиировать. Это же как тензорные операции, вообще-то.
Мне надо пересмотреть архитектуру компилятора. Хоть я уже много раз и разрисовывал схему работы Иколайси, как коды преобразуются, препроцессируются и компилируются, многие нюансы я не учёл и теперь у меня лапша в коде, причём отдельные макаронины расслаиваются на две в середине.
И вообще, мне уже надоедает заниматься Лайси. Я-то собираюсь доделать, это нельзя бросать. Ну, допустим до версии 0.8 + few либрариес, а потом бросить на полгодика-год, пока интерес не вернётся.
Жизненные обстоятельства не те, чтобы заниматься написанием не очень полезного софта. Я задолжал одной организации некоторую сумму денег. Правда, в тот же день вернул забыл из дома достаточно paper-бумажек взять. Но если просмотреть дальше, то видно, как миллионы людей по всему миру развиваются, пока я тукдуюсь в Лайси. Особенно, те кто родились раньше меня. Например, Илон Маск, родился очень давно и теперь в топе самых богатых миллиардеров, ещё и с ракетами что-то там интересное делает. С другой стороны, миллионы маленьких, бедных вась пупкиных даже и не осознаёт положение дел, вместо этого с кубиками какими-нибудь играют.
А я развиваюсь очень медленно, ни наук нормально не знаю, почти ничего не умею, даже собственным разумом пользуюсь неэффективно.
Вот действительно, с Иколайси надо заканчивать в этом месяце!

А если по теме смелтерсайда: я попробовал сделать устройство для дуги, в итоге чуть не взорвал аккумуляторы. Похоже, действительно для неё крайне желательна инертная атмосфера и побольше вольт. До такого мне далеко, так что индукционка или графитовый тэн ближе. Я попробовал выфрезировать новую спиральку, но из-за нескольких ошибок запорол заготовку. Хотя, даже если я сделаю такой тенчик, хотя бы на 3 Ома, к 220 вольтам его подключать нельзя. И тут выходит, что пора возвращаться к тому, что я сначала хотел сделать — линейный блок питания для индукционки. Для него мне надо только научиться наматывать трансформаторы, а для этого нужен сердечник! И за всё это время я его не добыл...

Ух, ну вы и понаписали.

Мои психические проблемы плавают. Только в последние несколько дней я смог заставить себя позаниматься Иколайси. Наверное, это бич поздней разработки Иколайси. Я почти опоздал. Скорость моих действий не поспевает за возрастом. В частности, я до сих пор пишу некоторые проекты на C/C++, так как Лайси не готов. Из-за этого приходится перебрасывать бойлерблейты из пустого в порожнее. А если бы я был умным, то уже бы давно ускорился везде.
Или может у меня на самом деле депрессия, вызванная снижением социальных контактов, а я на последних каплях держусь, так как я на самом деле сверхчеловек и просто могу.

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

Так ладно, если по смелтерсайду, то намотал какой-то трансформатор. Додолбал бывший МОТ за один день, а потом сидел наматывал проволоку. В итоге, как мне показалось, закоротило между обмоткой и сердечником (что?). Я его не разбирал и оставил на потом. Я короч решил купить в КНР блок питания, надеюсь не обманут.

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

Я до сих пор не сделал Иколайси v1.0 и Laisi v0.8. Некоторый прогресс есть, но я ещё даже не полностью перешёл на новые архитектурные нововведения. Хотя я просто перебросил обработку кода из компиляции в обработку. И ещё с Named-типами что-то там.
Я взял больше работы и теперь мне не хочется делать ни работу, ни свои проекты. Ненавижу, когда ТЗ нечёткое. Иногда бывает, что раз сделал — получил. Всё за один день. Бывает, что задание чёткое и не сложное, но растягивается на дни-недели. А бывает, что и не чёткое, и растягивается. Ещё иногда приходится использовать еретические маздай или громоздкие линукс иксы, малинка технологии.

>>14998
>Может уже пора выпускать в этом месяце Laisi v0.8 и Иколайси
Ахахаха, а я смотрю, ты до сих пор не научился ни планировать, ни предсказывать, ни проявлять волю в нужных концентрациях.
Вангую, что Иколайси v1.0 не выйдет даже в этом году.

>>15371
>Мои психические проблемы плавают
Ану пусть уплывают вниз. УСПОКОЙСЯ. Почему бы тебе просто не заткнуться? Тебе мозги даже не полоскали, а вона как спаялись.

Так-с. Я сделал чеклист, который надо выполнить перед выходом Иколайси в v0.8 Laisi.
Жаль, что Лайси проект не монетизируемый...
Несмотря на то, что я немного поменял архитектуру, в некоторых местах стало сложнее, особенно если заново. Но в некоторых полегче.
Кстати, посмотрите на what.png, вот кому придёт в голову (abc var1).b писать код таким образом? А мне приходится поддерживать даже такое написание.

Что я хотел написать в том посте, когда решил закрыть браузер, так это то, что почему в электронике ламеры? Нельзя нормально изучить электронику по книгам или гайдам, книги и гайды это просто дополнительная литература. Электронику надо изучать подробно, по полочкам, понять зависимость между током, заряжаемым конденсатор и его зарядом, как он своим напряжением отнимается от напряжения питания. Как транзисторы работают, если поля это электродинамика, то в электронике хотя бы просто зависимости смотреть надо.
Но вместо этого везде какие-то слабенькие гайды и книжечки "смарите какая схема". Та же хвалёная книга "Искусство схемотехники" это просто чушь. В первый раз пытался прочитать и мне показалось, что там чуть ли не обман написан или бред или чушь. Во второй раз понял, что имел ввиду автор, но я всё-равно бросил эту книгу. Надо подробные законы для каждого элемента понять. И не будет тогда никаких проблем, мол шум от резистора уничтожил полезный сигнал или что там бывает. Не нужно быть сверхразумом, чтобы в глазами пережигать лишние перемычки. Это как пытаться учить программирование по ответам из stackoverflow.
Гадость, короче. Науки лучше учить по методичкам, таков мой опыт. Мне надо изучить все разделы физики, чтобы лучше понять устройство этого мира на низком уровне. Только когда следует этого делать, если я сейчас пишу этот пост? Наверное, как допишу, пойду учить физику.

А чтобы понять мир на высоком уровне, надо понять главных игроков — людей. И научиться планировать. Я не понимаю, как люди планируют и высокий интеллект? Я видел в аниме, как персонаж очень легко уворачивается от ударов, которые ему пытаются нанести. Наверняка, в реальности тоже так можно с некоторыми нюансами. Есть т.н. Теория Игр, раздел математики. Хотел почитать книгу по ней, но нарвался на научпоп, где обговаривались просто несколько интересных случаев, где следует мыслить стратегически. Но этого же недостаточно! По-хорошему человек должен всё время осознавать все объекты, находящиеся вокруг него и строить планы исходя из них. Ограничения будут разве что по вычислительным мощностям. Но нет, вместо этого люди действуют по совершенно неясным паттернам, их логика не понятна, что они вообще делают, как они существуют? Как люди мыслят, что мне нужно делать, чтобы предсказать их поведение? Я даже своё поведение не предсказываю.
Тем не менее, я уже получил немного опыта и могу сказать, что чтобы доделать Иколайси, по-хорошему мне надо по 2-3 теста в чеклистах исполнять. Но я понимаю, что я этого не сделаю в связи с измененим настроения. Поэтому хорошим выбором будет до конца этого месяца в каждом из нескольких дней ввести по 10 тестов! Шаг уже неплохой, непонятно только как это исполнить.
Когда я в детстве был, то всё время делал тупо — раз и сделано. В шахматы почти всё время проигрывал.

Кстати, вы можете сдеанонить меня, но не надо пока этого делать. Чем позже — тем лучше.

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

Аааа, скоро Новый Год. Это один из немногих праздников, которые я признаю.
Успею ли я доделать Иколайси до конца этого года? Спойлер: нет
Мне осталось ввести ещё 20 тестов. Если считать в фичах, то недавно добавил одну: enum (хотя я её уже добавлял в питоновской версии Иколайси).
Несмотря на то, что тесты уже использовали готовый функционал, всё-равно пришлось кое-где допиливать. Там не работало то, там сё.
Вот, только что доделал тест test_index.lic. Хотя мне пришлось стейт-машину в одной функции сделать лолчто?. Мне стоит поучиться производству архитектур из книжек.

Ну ладно, позравляю с наступаящим Новым Годом, надеюсь у меня всё станет получше и не немного, а сильно.
Недавно я подпонял планирование, в частности, когда 2 стороны пытаются предсказать действия друг-друга.
Например X и W играют в камень-ножницы-бумага:
X: Хмм, W недавно видел камни, а его психика проста, значит он загадает камни. Я загадаю бумагу, чтобы выиграть.
W: X подумал, что я загадаю камень, значит он загадает бумагу. Тогда я — ножницы.
X: А, так W и об этом подумал, Ок, я выбираю камень.
W: Конечно же, X это предсказал. Бумага.
...
В конечно счёте, всё сводится к бесконечным итерациям, но чем дальше, тем сложнее предсказать действия противника, вероятности дробятся. Одни из выгодных шагов это начать действовать случайно, так как собьёт мысль противника.
Конечно, это и так было всем не глупым людям понятно, но мне нужно описывать знания словами, чтобы превратить в мышлебельную форму.
Так-то планирование заключается в выгодному противостоянию оппоненту, а для этого надо знать, по каким правилам оппонент существует. Если это алюминий, то ясно, что он расплавится при ~660°C нормальном давлении. Погода посложнее, нужна метеорология. А вот разум отдельного человека может стать охохох.

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

Ну ладно-ладно, это просто процесс написания Иколайси и дизайна его языка программирования Лайси. А если обернуться насквозь, то можно обнаружить, что:
Нярнонки уже давно умеют рисовать изображение по контурам и на имagебордe ████ач я увидел видео, где рисуют аниме-персонажей. Ну в принципе и что тут думать? Можно было бы обучить нейронку обводить контуры, добавить немного своей заливки цвета (надо погадать с обучением) и можно генерировать высококачественные рисунки даже просто из 3D-сцен. Персонажей нейронками, а окружение просто тун-шейдером. Кстати, тун-шейдерное тоже можно обработать нейронкой pix2pix, чтобы придать мультяшный вид.
Буду ли я этим заниматься? Было бы интересно попробовать, но у меня так много дел...
С современными технологиями и школьник может нарисовать своё аниме мультфильм. Ну, или если он японец, то даже аниме. Главное — правильно написать программу.
И вообще, что там ████████ с этим ИИ? Я предполагаю, что и человек может получить perk lol ███████████████████. Конечно, способ мышления может и значительно отличаться, но если с логикой всё в порядке, то скорость получения знаний зависит от вычислительных мощностей. В случае человека и от его индивидуального поведения

Кстати, насчёт нейронок. Ну сделал недавно я классификатор, в будущем, потенциально, лишивший нескольких людей работы или просто переведя их в другой отдел. Передал главному инженеру (?) .img-файл со всеми этими линуксами и весами. А он взял и попробовал ОТВЕРНИСЬ НЕТОВАРИЩ СИЛОВИК запустить его на десктопе! Загрузочную флешку для ARM-компьютера на обычном ПК? Чтооооо? Вот так всегда, не надо верить стериотипам. Если человек разбирается в одной узкой области (например, настройке нановолновок LazerGANson X542-L0Z2 в чётные дни весны), то это не значит, что он будет разбираться и в других областях (например в настройке любых нановолновок). Даже если вы встретите бога (!), то не удивляйтесь, если он не сможет запечь картошку. А может быть божественность это как раз наоборот узости?777? Ну да, условный бог проклятий, бог дождя, бог золота или бог нефритового стержня, но это не значит, что их сила ограничена титулом.
Что насчёт божественности и The Perk, то я как раз недавно поиграл в логическую игру Escape Simulator и вывел 3 важных урока:
0. Если меняется какая-то определённая часть в разных объектах, то не всегда надо смотреть на изменённые части, так как изменение лишь части меняет некоторые свойства всего объекта. Очень сложная загадка была Спойлер: Это где надо искать разницу между тремя молекулами
1. Иногда надо включать "детский разум". Подразумевается, что надо понизить уровень абстракции, чтобы найти фичи на другом уровне. Помните ту загадку типа 8x + 8 = 4, 2x + 0 = 1, где надо было тупо посчитать кол-во кружочков в циферках? Вот про это и оно. Это, конечно, слабенький урок, скорее напоминание, но важность тоже велика. Спойлер: Это где надо было цифры из названий химических элементов собрать
2. Не всегда надо логические операции применять, но и арифметические! На этой загадке я прям сдался и пришлось подсказку клянчить. Спойлер: Это когда надо было цены на еду сложить, а не первые цифры выбирать
Хотя арифметическая операция это очень сложная логическая, но помните же про контекст! Деньги, это то что складывается и отнимается. Арифметика!

Когда-то я тут писал, что незнаю как бы в Лайси была бы реализована свёртка в одну строчку. А это и не надо.
Есть 2 варианта:

float[10][10] convolved;
float[12][12] input;
float[3][3] kernel;

0. Через each:
x,y in each (0:10),(0:10) {
convolved[y][x] = (input[y:y+3][x:x+3]*kernel[:][:]){+};
}

1. Через лямбда-функцию (?):
convolved[:][:] = lambda (float,[usize x,usize y]) {return (input[y:y+3][x:x+3]*kernel[:][:]){+}} ((0:10),(0:10));

Ни того, ни другого в грядущей версии 0.8 не планируется.
Но как видно, each неплох, но анонимные функции полезны и в других местах коллбеки для ГУИ-элементов

2 дня пытался ввести test_import.lic, но до сих пор до конца не сделал.
Осталось только define LST import path. Это тогда, заимпортятся все библиотеки из path, а в LST будет список имён этих библиотек. Это нужно для модулей. Например, у библиотеки графического движка может быть несколько библиотек-модулей бекендов рендеров.
К тому же, у меня сломалось 2 теста. Придётся смотреть что там исправить.

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

Кстати, недавно я снова тронул свою заготовку для графитового тэна. Написал ПО, для управления станком прямо с пайнфона! Хотя оно багованное, команды копятся быстрее, чем исполняются, так как моё ПО для управления станком медленноватое. Придётся исправлять, если понадобится ещё. Всё-равно пыль всё заслоняла и нафрезировал кружочек чего-то бесформенного и хрупкого в одном месте. Легче чисто для моей заготовки нарисовать путь вручную и отправить его на фрезировку автоматически режимом.
Ещё моя концетрация была расфокусирована и мне в голову пришол образ как я в отладочном режиме управляю станком с компа далеко и что-то с бумком ломается. Да... страшновато. Может быть, в будущем я так взорву что-нибудь водород или ДВС. Но это лучше, чем себя.

А пайнфоновское ПО KDE Plasma для мобильных устройств продолжает удивлять. Недавно был тупо чёрный экран после введения пароля и входа в графическую сессию.
Я думаю, дело было так: Сверху есть выдвигающая менюшка как обычно в андроид-смартфонах и там можно изменить яркость экрана. Но её можно изменить до полностью чёрного! При этом там и само по себе иногда меняется яркость экрана (какой-то умный ночной режим?). Наверное, что-то такое и случилось до чёрного цвета.
Но это же линукс, так что я просто подлкючил клавиатуру и удалил .config

Недавно я осознал, в моей же архитектуре Иколайси слои абстрации перемешаны!
Слой парсинга напрямую обращается к слою препроцессинга (когда именованый тип или темплейты там).
Я уже где-то 5 лет программирую (поздно вошёл), а архитектуры нормальные так и не научился выдумывать. Теперь перед каждой разработкой ПО было бы неплохо сидеть, на бумажке писать. Надо научиться нормальные архитектуры, а то что я как дурак сижу?

Но в новой архитектуре, которую я придумал, тоже есть странности. Получается, и препроцессинг и большая часть парсинга находится на одном слое. Там они вызывают друг друга при темплейтировании/именованых типов и варят единый токенокод. Затем идёт второй слой абстракции, который берёт токенокод и преобразовывает снова в токенокод! Ну, ещё ошибка всякие выискивает... А надо заново преобразовывать, так как перед компиляцией всякие forы и тензорные операции (z[:][:] = x[:][:] + y[:][:]) преобразуются в while-цикл. Надо будет сделать возможность указывать, какие штуки преобразовывать в другие. То есть, векторные операции для условных интов и флоатов в вайл не надо, его можно через LLVM IR векторными операциями принять. Это когда операция большей размерности или это неэлементарный тип и каждый раз вызывается перегруженная функция.
Ну а третий слой абстракции просто компилирует токенокод в LLVM IR, а оттуда ELF, EXE, etcFF или в процесс (что я называет интерпретированием кода в процесс. Поэтому Иколайси — интерпретер-компилер оф лайси)

Ввёл почти ничего. typeof, например. Ради него и проивзодился прошлый переход на новую часть архитектуры. Когда, чтобы получить результирующий тип операнда, не его компилировать в LLVM IR.
Но всё-равно, выглядит странно. Чтобы получить тип члена, надо декларировать переменную. Бзе тайпофа не получится нормальные темплейты делать (даже liblaisiшные функции max, min, argmax, argmin).
С import я повременил. Начал писать плохой код, мотивация пропала и я перестал писать плохой код.
Чего-то там с тензорными операциями сделал. Снова ввёл, пару часов пытался решить баг, которого не существует.

И это всё, чего я добился за 3 года полудействия? Хорошо, хоть типы компилируется. Даже если без методов...

Новую архитектуру я, конечно же, сейчас вводить не собираюсь.
Но лучше бы начать программировать нормально уже сейчас. UnfoldTensorExpr следует редизайнить, учтя все необходимости. У меня, допустим, реализованы поэлементные операции между "тензорами", но это происходит только для переменных с индексами. А кроме них есть ещё SSS/iterexpr и списки. Надо заредизайнить и описать алгоритм. Ещё и анфолдинг фора заредизайнить.

У меня есть 2 основные цели — маленькая и большая. Создать Иколайси — маленькая. Не вижу в ближайшее время никаких преград для разработки Иколайси, так что это время — наилучшее. Когда я вырасту, времени на софт будет поменьше.

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

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

Зато, если понять собственный разум, то можно сделать и ██████████. Если он будет успешен, ██████ и вычислительно не сильно дорогой, то можно будет размножить ███ и поставить зарабатывать ██████. Пусть всякие ████████ рисует или картинки. Может по меньшей цене, но за риск. А потом писать ███ по моей архитектуре. А потом и саму архитектуру придумывать. Это звучит страшно, но выглядит неизбежно.

Недавно я пытался разработать ██████, а в итоге одна баночка вдребезги.
Разрабатывать это так сложно, но я кажется понял кое-что.
Очень маленькие проекты (простые скрипты, литой попрыгнучик, ручка для ящика) можно делать и в автоматическом порядке, мозг сам как-нибудь итеративно найдёт результат.
В то время как для больших проектов надо придумывать архитектуру, чертёж, темплейт, 3D-модель, XD-модель, абстрактную модель. В случае сложного ПО это архитектура, надо продумать её досконально, добавить путей для расширения и изменения. В случае машины надо сделать что-то типа чертежа, где указан список взаимозаменяемых деталей и как их характеристики влияют на характеристики других деталей. То есть, если нам нужен вал диаметром 5 мм, но в некоторых нетрущихся местах он может быть и до 10 мм, то зачем выбрасывать уже существующий ресурс, подходящий таким характеристикам? Единственное, что, машины разрабатывать лучше в специальном ПО, чтобы оно автоматически расчитывало массу, тензор/моменты инерций, габариты отдельных секций. Они могут повлиять на характеристики других деталей, например, минимальный момент сил, который может развиваться двигатель. Также в случае машин следует предусмотреть пути для дебаггинга, чтобы дебаггинг был лёгок и доступен. Пути для расширения могут понадобиться разве что в очень больших машинах или целых зданиях. В случае пректирования в общем смысле физических предметов надо ещё учитывать то, как он будет создаваться. Если надо спаять что-то в узком месте, то надо просчитать порядок действий так, чтобы паяльник поместился.
За свою жизнь я сделал где-то ноль ███████. Ноль это всё-равно, что нольдесят ноль. Нольдесят ноль это всё-равно, что нольсот нольдесят ноль. Нольсот нольдесят ноль это всё-равно, что ноль тысяч нольсот нольдесят ноль. Ноль тысяч нольсот нольдесят ноль это всё-равно, что нольдесят ноль тысяч нольсот нольдесят ноль. Нольдесят ноль тысяч нольсот нольдесят ноль это всё-равно, что нольсот нольдесят ноль тысяч нольсот нольдесят ноль. Нольсот нольдесят ноль тысяч нольсот нольдесят ноль это всё-равно, что ноль миллионов нольсот нольдесят ноль тысяч нольсот нольдесят ноль. Если X ∈ множество созданных мною ███████, то X ∈ ∅, то есть X ∈ {}, потому что это пустое множество, потому-что его количетсво элементов равно нулю или, например, нулю миллионов нольста нольдесяти нулю тысяч нольста нольдесяти нулю.

И вообще, может мне Лайси полностью исполосовать и преобразовать во что-то другое? Вот пишу это и чувствуют, что это неверное решение. Мне понравился хаскелль, но я его тольком не попробовал. Функциональный язык, красиво всё выглядит. Вряд ли Лайси смог бы стать функциональным языком. Но что в нём делает метапрограммирование? Серьёзно, почему темплейты обозначаются специальной конструкцией с кейвордом template? Почему нельзя просто взять и сделать в аргументах выбор из допустимых типов? Это было бы красивее. Но я не знаю, стоит ли избавляться от метапрограммирования. Не хочу.
Кстати, Лайси вообще нужен больше для LDI — Laisi Default Libs — набор библиотек разного назначения. Почему бы ту же math нельзя было бы сгенерировать на произвольный язык программирования условным скриптом на питоне? Взял бы, указал допустимые типы и сгенерировались бы функции max_int_int, max_int_float, max_float_int, max_float_float и все-все-все. А для C++ создался бы сразу template. Но если так уходить, то со временем эти скрипты переписывались бы и переписывались бы, образовалась бы библиотека с типами для ЯП, там операнды, типы, экспрешионы, инструкции. И получился бы просто новый ЯП. Который транслировался бы просто в LLVM IR.