mayton2019

Прошу прощения за внезапный UP.

Но мне задали вопрос про Forth. Я увлекся и тут меня (Остапа) понесло.
Вобщем я начал читать и листать всякую инфу по форту. Первое впечатление - полный бардак
в стандартах. Нет никакого общего понимания что такое вообще язык Форт. По крайней
мере я для себя понял что форт - это просто набор слов (words) каждое из которых либо число
либо слово которое вызывает вычисления. Больше реально ничего не регламентировано.
И я так понимаю что Форт-еров это вообще не парит. Они такие себе либеральные оптимисты.
Судя по конференциям средний возраст Форт-иста - далеко за 70 лет. Дедушки с бородами...

По поводу компиллятора и транслятора. Ничего пока непонятно. Целевая платформа
- не всегда x86 а всякое редкое железо. И тренироваться могу пока на GForth который
кое-как работает но не хватает слов. И YForth который крашится в segfault сразу
на моем Linux x64. Остальные я пока не пробовал.

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

На главный вопрос автора - и я ответить не могу. Не знаю является или нет. И я не знаю является
ли он вообще ЯЗЫКОМ. МОжет он как Lisp - просто идея. Он просто настолько широк что
определение языка его сужает.

Надеюсь я никого не отвлек своим спичем от важных дел.

Ты правильно тегировал тему с SQL-Injection. Но ее наличие надо доказать.
Например - взять и вставить какой-то код в ячейку и попробовать воспроизвести.
Одних страхов - недостаточно.

Я видел пакет iwatch. Кажется пытался где-то его применить. Он слушает слишком много событий. Там буквально каждый чих в файловую систему будь то просмотр директорий или атрибутов вызывает шквал событий и их надо грамотно буферизировать и фильтровать.

В идеале вы должны поставить свой ФТП-root под версионный контроль. Например под git. И делать чисто технический коммит на каждое событие изменения файла.

Проблема в том что в такой много-пользовательской среде как ФТП трудно выделить атомарную часть изменения чтобы обозвать ее коммитом. Если 2 пользователя одрновременно пишут в 2 файла в ФТП - это нормальное действие с точки зрения файлового сервака. И в этот момент трудно принять решение где-же собсно
был коммит. Мы полюбому будем фиксировать в коммитах недописанные тела файлов. Вот в чем проблемка.

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

Проверьте делает ли ФТП временное расширение для файла во время записи или обновления. Это важно.

Ну если вы занимаетесь застройками по всей стране - то тогда и делайте карту страны. Зачем вам Африка или Антарктида. Товарищ выше верно пишет - что гео-фотки это самые ресусоемкие. И никто их не хранит одной картинкой. Да и GoogleMap тоже использует структуры наподобие QuadTree чтобы просто их отрисовать. И это нормально.

Можно разослать всем письмо о плановых затаскиваниях в домен. Дескыть всем явится с десктопом в час Х в админскую комнату. По плану. По 5 человек в день. А кто не явился - закрыть им доступ к сети по мак-адресу. Прибегут потом.

Обычно такие системы строят не на основе БД а на основе системы сообщений (messageMQ). Это - более современный и рациональный подход. Не бот долбит БД а MQ уведомляет бота о каком-то событии.

Варианты. Можно преобразовать JSON в JSON-Lines (где каждая строчка - это независимый JSON документ представляющий строку таблицы).

Потом загрузить это в spark dataframe

Using Scala version 2.12.15 (OpenJDK 64-Bit Server VM, Java 11.0.17)
Type in expressions to have them evaluated.
Type :help for more information.

scala> val df1 = spark.read.json("/tmp/emp.json")
df1: org.apache.spark.sql.DataFrame = [_corrupt_record: string]

И имея фрейм либо сохранить в CSV либо подключить драйвер JDBC записать прямо в базу.

Еще во фреймворке Pandas есть опции загрузки из JSON. Но я сам не спец в пандасе поэтому
точно как сделать не скажу.

Вот. Еще я помню где-то писал утилиту чтоб произвольные JSON конвертить в JSON-lines.

Короче способов - масса. Беда как обычно в вопрошающем. Что он готов для этого установить
и что выучить.

Те которые на 100Гб можно подарить детям на игрушки. А для больших (несколько терабайт) - моешь посмотреть SMART информацию (как советуют выше).

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

Но, как я понял, она про другое, про упаковку после удаления. А мне нужно, что бы просто листовые страницы 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 по отдельности.

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

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