mayton2019

Но, как я понял, она про другое, про упаковку после удаления. А мне нужно, что бы просто листовые страницы B-дерева заполнялись полностью, как у ms sql с fill factor = 100. То есть, максимально плотное заполнение базы данных, когда идет просто построчная вставка.

Ты напомнил анекдот когда женщина приша к урологу и жалуется что у мужа дескыть "одно яичко ниже другого. Непорядочек.."

Вобщем перфекционизм хорош в меру. Если ты читал об организации индексов на основе B+Tree (практически везде) во всех DBMS, то ты должен был читать о том что среднее заполнение листовых блоков обычно равно 75% от размера блока. Это связано с возможностью оперативно делать insert новых ключей и значений. Если ты, используя какие-то утилиты специально выровнял заполнение блоков - то индес становится медленным для будущих вставок. Каждая вставка продуцирует операцию split (тяжелая операция) и пока не посплитятся все листы - перформанс будет плохой.

Если исходники хранит - то наверное git подходит.

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

Тяжелую задачку ты зацепил. Я не знаю есть ли в классическом Win32GDI такие функции чтоб вдоль curve печатать текст.

Но вот есть пример с печатью под произвольным углом. Попробуй ее приспособить.

https://learn.microsoft.com/en-us/windows/win32/gd...

Для exe-шников еще в 90-е создавались не архиваторы а всякие "упаковщики". Из таковых я помню UPX https://upx.github.io/

Чтобы понять async нужно в принципе понимать мультизадачность.

Есть два вида мультизадачки. Первая базируется на preemptive multitasking. Это классика на потоках (Threads). Подходит для приложений где есть нагрузка на CPU и мало I/O. Пример таких приложений - рендеринг 3Д графики. Майнинг.

И есть второй вид когда есть много I/O а нагрузка на процессор - малая и ее можно считать неизменяющейся. Как обработчик событий. Ее делают на async/await. Или еще на мультиплексированном I/O. Она подходит для веб-серверов. Яркий пример - nginx. Или системы обрабоки MQ. Сокет-серверы. Файловые серверы и прочее.

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

UPD: Fixed

Весят чет многовато даже после компрессии.

Все очень просто. Зависимость размера от ширины - квадратичная.
Это означает что размер картинки растет не линейно а в квадрате от
одного из измерений. И JPEG/WebP здесть не помогает т.к его алгоритмы
не меняютс своих свойств от размера. Обычно ты задаешь коэфф сжатия
или он берется по дефолту. Ставить более сильное сжатие нет смысла
т.к. портится качество мелких деталей. А если портить - то нахрена
увеличивать размер?

Пример такого расчета в сыром размере RBG байтов:

Разрешение FullHD 1920 x 1080 = 2073600 pix = 2073600 * 3 = 6 220 800 bytes
Тоже самое в два раза больше в поперечнике 3840х2160 = 8294400 pix = 24 883 200 bytes
Итого размер стал в 3 раза больше. Для 8К разрешения ситуация станет хуже во много раз.

Поэтому увеличивать разрешение нужно очень осторожно.

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

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

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

Вобщем верно говорят. Купи клавиатуру. Потому что трата времени и мозго-топлива на фиксацию этого аппаратного дефекта займет у тебя слишком много времени.

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

Это +16% к частоте. Даже не заметишь. А риски что будет нестабильно есть. Я-бы ничего не делал. Оставил как есть. Тем более что перформанс в играх зависит не только от памяти а еще от CPU/GPU диска.

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

Не знаю как в Го-шке. Но в сях есть два базовых подхода к работе с текстовой графикой.
Первое - это печатать управляющией символы (backspace) чтоб стирать предыдущие.
Так например работает текстовый архиватор Rar пока печатает прогресс. Все это на уровне STDOUT.

Второе - это использовать библиотеки наподобие ncurses. Это такая Rich-графика в тексте.
Можно делать красивые цветные текстовые таблицы наподобие TurboVision. И даже интерактивность.
Диалоговые окна. Edit boxes e.t.c.

Тяжелая задачка тебе прилетела. Я-бы вообще не советовал ее делать. Много ручной работы.
И эффективность решения сильно зависит от того как выглядит документ. Что там внутри?
Текст? Таблицы? Или сканированные фото.

По поводу парсинга pdf на python - вот был вопрос в стековер https://stackoverflow.com/questions/18755412/parse... можно начать с этого.

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

Какая тут схема?

Скорее всего вам это не надо. Внешний анализ заказывают банки например чтобы подтвердить что софт - безопасен и не боится эксплоитов. Из таких систем я помню платную Veracode. Она находила у нас ошибки безопасности в логгировании (!).

Вот. Из безсплатных - посмотрите SonarQube. Он работает с плагинами.

Да и очень полезно указывать конкретные теги языков. Что там у вас? 1С? Кобол? Или Лого?

Я серъезно! Почему не указываете?

Дружище. Если API не поддерживает какую-то функцию - то разработчик ее пишет сам.
Я не вижу сложности написать масочный remove на основе поиска файлов по маске
и той команды os.remove(...) которая уже есть в API. Тем более с лямбдами.

Но я-бы сказал что команда это опасная. Можно грохнуть что-то нужное случайно.

Ты мог генерить целые случайные числа в диапазоне от 100 до 500 и потом сдвигать запятую влево на 2 знака.

А вот фильтровать все которые не равны целым величинам ... эээ такое себе. Ты не получишь линейное распределение вероятностей. Короче это уже не рандом. Лохотрон.