>>27533
Ну вот QCoreApplication::processEvents() передала бы контроль чтоб обработать события, я поэтому спросил.

>>27491
Ханабира вроде на нём работала. Где-то даже помню её исходники видел.

>>27491
Бнвач, например https://github.com/stiletto/bnw - twisted+tornado+mongodb

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

>>27583
>Copyright (c) 2012, Kagami Hiiragi <kagami@genshiken.org>
Лол, тот самый? У него ведь реально какие-то наработки с ХМПП были.

Появились ли какие-нибудь идеи по дизайну плашки?

Как вариант, можно в div, где сейчас topmenu писать.

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

Или в div над постформой, затирая replymode или нет.

>>27632
С формой быстрого ответа можно сделать что-то похожее, но тогда надо придумать, как ограничить ширину tr-а, если сообщение об ошибке длинное.

> ограничить ширину tr-а, если сообщение об ошибке длинное
А, через width:min-content.

>>27630
Так там какие-то проблемы есть с тем, чтобы просто прямоугольная фитюлька в углу (например, верхнем правом) выплывала, а потом уплывала обратно через несколько секунд? >>27631 бы тоже покатило, но мы в теории можем когда-нибудь сделать настраиваемую прилипчивость верхнего меню, а эта штука всегда должна быть видна.

В целом, можно не торопиться: работа, видимо, опять встала. Она шла бы быстрее, если бы вы осилили зарегистрироваться в репозитории, лол.

>>27635
Технически нет. Но хочется увидеть пример, чтобы понять внешний вид и её оптимальные размеры относительно остальных элементов.

Мои проблемы с фитюлькой в правом верхнем углу:

1. Ассоциация с please accept cookies, пусть такое обычно в левый нижний угол пихают. Topmenu-вариант больше похож на статусную строку, хотя статус обычно снизу;
2. Сообщение релевантное содержимому формы постинга может далековато от неё оказаться. Может понадобиться переводить взгляд с левого нижнего угла экрана, где форма быстрого ответа, на противоположный. Более проблематично на большом мониторе. У topmenu-решения та же проблема, но оно во всю ширь экрана/браузера, сразу не заметить сложнее;
3. У нас сейчас документ идёт строка за строкой, кроме когда пользователь решает перетащить форму постинга, и кроме div-а с избранными нитями (Которым кто-то пользуется?). Теряется alignment.

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

BTW, вариант для быстрого ответа, как на картинке, точно совсем не подходит?

Перекат для привлечения внимания. Проблем накопилось.

Самое главное — очередное обновление проверки браузера Флярой, из-за которой периодически 403.

Ура, живой тред!
Стоит ли ожидать добавления поддержки webp?

>>27509
Так она есть, только видимо не со всеми типами компрессии. А вообще - сильно сомневаюсь что тред создан кем-то, кто будет заниматься поддержкой. Так что ничего не поменялось по факту.

>>27511
А как оно вообще может поддерживаться? Просто сделать очередной форк сделать с парой фиксов?

>>27628
Делаешь свой форк @ делаешь в нем фикс @ создаешь из него пулл-реквест в оригинальный репозиторий

Потом авторы твой реквест принимают и выкатывают попатченную версию, как-то так.

Погуглил больше про ECS.

Концепция сама существует давно и не является изобретением Unity, но уже DOTS - их термин. Она сама по себе не про производительность, а про подход к описанию игрового мира и взаимодействий в нем.

В ECS игровые объекты не наследуют кучу всего и не создаются со статичной кучей параметров и компонентов, существующих вплоть о момента удаления объекта. В ECS игровые объекты - просто entities, некие изначально пустые "сущности", играющие роль уникальных идентификаторов.

Параметры игровых объектов (например, здоровье, скорость, "прыгучесть", etc) являются самостоятельными компонентами (components), не привязанными ни к какому объекту статично. Они могут назначаться каким-либо entities, если им необходимо данное поведение/характеристика. Причем эта привязка или отвязка происходят в рантайме, что позволяет делать классные вещи в виде изменения казалось бы статичных характеристик игрового мира в уже работающих клиентах.

Системы (systems) содержат уже логику, обрабатывающую данные из компонентов. Можно думать о них, как о контроллерах. Важно то, что системы не завязаны на конкретных компонентах и entities. По крайней мере в юнити, как я понял, системы могу выбирать entities на основе привязанных к ним компонентов (entity query) и тем самым всегда работают с группой entities. Поэтому в коде много foreach :)

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

Разобрался со сценами и переходами между ними. Сцена - это некая уникальная инстанция мира. В зависимости от сложности игры может быть отдельным уровнем, может быть целым открытым миром. Или это может быть просто menu screen.

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

Персист данных между сессиями (между разными запусками игры) сложнее. Причем не потому, что надо писать в файл или работать с другими внешними сущностями. А потому что надо постоянно думать, могут ли внутренние структуры быть сериализированы. В шарпе не все так однозначно. Обычный array, например, может быть сериализирован в json, List уже нет. Хотя BinaryFormatter с ним справляется без проблем.

бамп

Стив, как дела, продвигается ли изучение?

>>25670
Забил на какое-то время. Переезды, смена работы и всё такое
Ещё как закончил курс junior programmer, у меня случился overwhelm от осознания уровня необходимых скиллов (которые нужно качать и качать 100500 лет как в олдскулл ммо), что демотивировало продолжать процесс.

Недавно появилось желание раздропнуть. Начал новый курс Creative core. Посматриваю на применения Юнити в не-игровых индустриях, изучаю какие есть наработки в AR, webrtc, нативная интеграция в мобилках и всё такое.

>>26109
ну чО, как результаты?

>>27432
Тоже любишь отчеты вкатывальщиков читать?

о, здарова, вы тоже игры делаете?

>>13482
>Потом бери игл, PiCAD или что там еще, и учись работать в нем. Не в коем случае не запускай SprintLayout, он делает очень крепкую привязку к себе синдромом утенка, пересесть с него в нормальный САПР потом будет боль и унижение, а в SL потолок поймаешь почти сразу.
EAGLE и PCAD это тоже касается - много кто с них не может слезть, а если и перелезает, то обычно на Altium Designer.
Стоит сразу брать либо OrCAD/Allegro, либо Expedition PCB.

>>23967

А что вы думаете про KiCAD ? Есть open source в open hardware ?

>>24441
Он довольно активно развивается, особенно, после того, как за него взялся ЦЕРН (а это уже серьёзно). EAGLE он уделывает целиком и полностью, и все, кто сидел на нём, перешли на KiCAD.
Если говорить о действительно серьёзных проектах, где требуется работа с высокоскоростными сигналами - считай, всё, что имеет память и высокоскоростные интерфейсы, то лучше о нём на текущий момент не задумываться и смотреть на САПР от Cadence или Mentor Graphics.

>>13850
>HAL
>CubeMX
В приличном обществе после упоминания этого указывают на дверь^W CMSIS.

>>13469 ну собсна эээ ломаный sprint layout ахуенная штука для новичка, в рунете лежит тоннами, скачать не проблема. остальные кады не интуитивны нихуя, тот же альтиум отнимает кучу времени на оформление схемы, УГО и посадочных мест. сам начинал делать простенькие платы по схемам с radiokot.ru, потом вкатился в погромирование МК AVR на сях по гайдам с avr-start.ru, а потом уже стал смешариком и умею в собственные разработки, ассемблер, FPGA, аналоговый схемач и прочие. Удачи, анон

https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Autodesk-EAGLE-Announcement-Next-steps-and-FAQ.html

Kicad for serious hardware development.
https://www.youtube.com/watch?v=z9BYvYlH5lo

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

>>27247
А давай советы 0E и 0F, раз на них тут ссылаются. Одна картинка с тремя няшками сойдет, или надо разные обязательно?

>>27250
>Одна картинка с тремя няшками сойдет, или надо разные обязательно?

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

>>27251
Ладно, держи вторую картинку.

>>27250
>>27252
Высылаю

>>27250
>>27252

Прочитал https://rakhim.org/summary-of-concurrency-is-not-parallellism-a-talk-by-rob-pike/ . КарGo-культ какой-то. Не вижу преимуществ между 100500 юзерспейсных псевдо-тредов с чем-то вроде встроенного интерпретатора

while(true){
switch(taskChunkId){
case a:
...
break;
case b:
...
break;
}
}

перед подходом, когда на задачу выделяется по треду, делающему её от и до, ну а когда переключение контекста происходит - оно всё равно происходит в основном, когда I/O идёт. В результате нет лишнего оверхеда на всякую фигню, нет лишнего оверхеда на message passing, ну а оверхэд на хранение состояния треда можно минимизировать, избавляясь от ненужных данных тогда, когда они перестали быть нужными.

А можно мне совет 0x65, пожалуйста!

>>27260
????

Кстати, ни у кого не осталось кода для поддержки ЎэбП, который когда-то постили в /d/? Или какой-нибудь новый кот для этого.

>>25770

http://ii.yakuji.moe/d/res/250303.html#251062

Упомянутая в сообщении >>20993 проблема https://trac.ffmpeg.org/ticket/7613 исправлена разработчиками FFmpeg, и предположительный срок её исправления оказался даже больше того, насчёт которого я мрачно подозревал в сообщении >>21078: не только до середины 2021 года, но даже и до февраля 2022 года поневоле пришлось дожидаться.

Дополнительные подробности я изложил в сообщениях https://t.me/ReadMithgol/476 и https://t.me/ReadMithgol/478 в Телеграме, растровые копии которых я прилагаю и тут, но только по одной (а не то итог склеивания их по вертикали, весьма вѣроятно, натолкнулся бы на препятствие >>/d/2649 при малѣйшей попытке помѣстить его на 410чан).

Второе приложение к сообщению >>26119.

На «Ычане» севодни была сделана прилипающая навигация (по аналогии с местной). Некоторым она не нравится, так что можно было бы сделать её настраиваемой (как на «4чане»).
Предлагаю сделать как на картинке. Кнопку закрепа следует взять из местного движка. Поведение у кнопки такое же, как тут в быстром ответе.
Делать, очевидно, через ӁС и надо, чтобы оно запоминало положение. По умолчанию навигация должна быть прилипающая. Скрипту достаточно просто изменять "position: sticky;" в ЦСС, я так понимаю.

Это официальный запрос.

>>27428
Почему кукла то не работает на ыче? Раньше работала и было удобно, теперь же даже менюшки в правом нижнем углу нет. Я не погромист этот ваш, не знаю как чинить. Без куклы оно и не надо же, а с куклой -- пусть будет. Верните куклу, пожалуйста.

>>27430
>Почему кукла то не работает на ыче?
Не знаю, спрашивайте у её разработчика. Это не тред поддержки куклоскрипта. «Ычан» тут ни при чём.

>>26323
Разработчики, родненькие, подайте пожалуйста хоть какой-то сигнал по вам и о статусе проекта

>>27262
Статус проекта: обглоданные кости.

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

>>27297
А в процессе слушания вещества употребляете?

>>27306

С Наступающим всех Новым годом!

>>27297
Тебе отвечает нейросеть.

>>27229
>Rails-подобного C++-фреймворка
Звучит так, что у тебя должен быть ActiveCache/ActiveObject/(другое название), который внутри вызывает, например, абстрактный ImdbAdapter. И уже на нижнем уровне должна быть реализация в виде RedisAdapter, наследующегося от ImdbAdapter.

Функция redisContext() уж точно должна быть приватной, иначе непонятно, что именно обёртка должна скрывать.

Интересно узнать, как твой Rails-подобный C++ фреймворк будет работать, в частности, какие практики из "convention over configuration" ты хочешь применить. В отличие от Ruby, язык не динамический и имеет меньше возможностей для метапрограммирования.

>>27223

Очевидные C++-модули.

>>17934

Всех приветствую. Делаю задание для шараги, нужно написать прогу которая способна сжимать и растягивать файл алгоритмом LZW. Сам алгоритм предполагает наличие начального словаря, который по ходу сжатия файла(нахождения в нём новых последовательностей байтов) расширен. То есть для того чтобы в дальнейшем растянуть файл обратно, нужно знать словарь. И вообще понять, подлежит файл растягиванию или же это просто белиберда из битов. Пока такие соображения: первые биты в сжатом файле сделать что-то типа сигнатурных, чтобы можно было сходу определить можно ли растянуть файл. И после сигнатурных битов будут биты сжатого файла, а потом будет магическое число типа как "разделитель" между файлом и словарём. Насколько хорошая идея использовать магическое число как разделитель? Или же лучше будет выделить под сжатый файл первые 4 бита как сигнатурные, где помимо метки сжатия файла будет ещё число под оффсет, как количество битов после которых заканчивается сжатый файл и будут пары ключ-значение из словаря? Или может быть лучше сделать по-другому как-то?

>>27307

>Делаю задание для шараги, нужно написать прогу которая способна сжимать и растягивать файл алгоритмом LZW.

Нахрена нужен ещё один LZ*-алгоритм, их и так как собак нерезанных.

#include <zstd.h>

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

>>27313
Вполне возможно, речь идёт не про фирму, а про университет.

>>27307 >>27314
Ну раз курсовая работа....

>растягивать файл алгоритмом LZW.
>Сам алгоритм предполагает наличие начального словаря, который по ходу сжатия файла(нахождения в нём новых последовательностей байтов) расширен. То есть для того чтобы в дальнейшем растянуть файл обратно, нужно знать словарь. И вообще понять, подлежит файл растягиванию или же это просто белиберда из битов. Пока такие соображения: первые биты в сжатом файле сделать что-то типа сигнатурных, чтобы можно было сходу определить можно ли растянуть файл. И после сигнатурных битов будут биты сжатого файла, а потом будет магическое число типа как "разделитель" между файлом и словарём. Насколько хорошая идея использовать магическое число как разделитель? Или же лучше будет выделить под сжатый файл первые 4 бита как сигнатурные, где помимо метки сжатия файла будет ещё число под оффсет, как количество битов после которых заканчивается сжатый файл и будут пары ключ-значение из словаря? Или может быть лучше сделать по-другому как-то?

Строение формата: разделить стрим, словарь и контейнер. Все числа - little endian! Файл маппится в память целиком через либу mio, дальше работаешь с std::span и структурами. Стрим состоит из заголовка стрима и стрима. Без сигнатуры. Контейнер состоит из сигнатуры, глобального заголовка, содержащего длину области контейнера и смещения областей стрима и словаря в ней ОТНОСИТЕЛЬНО КОНЦА ЗАГОЛОВКА. После следуют области, сначала область словаря, потом область стрима, потом конец файла. Ты провершь это при загрузке файла. Размеры вычислишь как разницы этих смещений.

Начальный словарь может иметь смысл хранить в отдельном файле для переиспользования, поэтому область словаря - это может быть просто CRC32-хэш от файла словаря, который при операциях надо задать явно. Также начальный словарь можно
хранить внутри контейнера или использовать захардкоденный. Поэтому сначала 1 байт перечисление. 0 - хардкод, 1 - файл, 2 - внутри. Если 0 - то инициализируем хардкодом. Если 1 - берём имя файла, добавляем ".dic" - вот и наш словарь. Проверяем наличие файла. Маппим его. Проверяем формат словаря. Поскольку задача учебная, то для твоего удобства в его редактировании это просто массив, сериализованный в BSON/bencode. Поскольку тебя проси

Сообщение слишком длинное. Полный текст.

Наткнулся при компиляции на ошибку вот в этой строчке
> typedef int Check[sizeof(A) == sizeof(int) + sizeof(bool) ? 1 : -1];
Долго думал, что это за ерунда такая, а потом как понял.
Структура А определена как
> struct A {bool b; int a;};
Оказалось, что это проверка на отключение выравнивания в структурах -fpack-struct=1.

Я просто оставлю это здесь:
https://github.com/orgs/community/discussions/49869

Тем временем олдфаги вспоминают, какой и кому подарок сделала SourceForge в начале 2010.
>>27012
>А селф-хостед вариант почему не подходит?
Для почты и жаббера нужен внешний домен, наличие которого — удовольствие порой недешёвое.
>>27017
>Почта была придумана, чтобы слать сообщения друг другу
Было бы всё так — не изобрели бы ICQ и XMPP, из-за громоздкости почты для коротких сообщений.

>>27084

То что почта морально устарела - никто не спорит. Но когда она появилась, всех перечисленных систем мгновенных сообщений просто не было. И ICQ хоть когда-то и была очень популярной системой, до сегодняшнего дня не дожила. А почта живёт и здравствует благодаря своей простоте и федеративности. Главные её недуги - это то что почти везде требуется привязка телефона и JavaScript, а self-hosted держать неудобно и затратно.

Свершилось, просветления в уму у руководства гитхаба не наступило. M$ потребовало от всех 2FA. При этом в качестве "2FA" подходят 1FA, если этот 1FA - "Passkey" (подробнее https://auth0.com/blog/our-take-on-passkeys/) от FIDO Alliance, в который входит M$. Свалить будет трудно: некоторые проекты валить не хотят "мы не для того на GitHub переходили, чтобы с него обратно валить", при этом своя инфраструктура ещё не полностью ликвидированна и можно её просто включить и с GitХапа все новые issues импортировать. Я же валю на codeberg.

>>27271
А я просто врубил OTP в keepassxc, который вполне себе опенсорсный, но тем не менее может генерировать одномоментный пароль для гитхаба и многих других сервисов. Использовать проприетарный аутентификатор со смартфона необязательно.

А ещё нужно помнить про infrastructure distrust, вы можете:
1. Создать bare репозиторий прямо у себя на диске с помощью
git init --bare
И потом пушить в него. Этот репозиторий может даже быть на отдельной флешке или жестком диске. Вы можете добавить его как дополнительный ориджин для гитхабовских репозиториев.
2. Подписывать свои коммиты с помощью gnu pg

Про infrastructure distrust можно больше узнать у Джоанны Рутковской:
https://invisiblethingslab.com/

BTW: С новым годом.

Ладно, на самом деле вот здесь:
https://www.qubes-os.org/faq/#what-does-it-mean-to-distrust-the-infrastructure
И немного здесь:
https://github.com/QubesOS/qubes-issues/issues/3958

Ладно, на самом деле вот здесь:
https://www.qubes-os.org/faq/#what-does-it-mean-to-distrust-the-infrastructure
И немного здесь:
https://github.com/QubesOS/qubes-issues/issues/3958