Си-шарп-ствуете ли вы?

писали на сисярпе, но сейчас почти выбросили из стека.

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

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

А коллеги мои поток вешали на любое нажатие кнопки.

Зачем?

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

Всякие gedit и mousepad в Linux обычно до такого не додумались, и встают(вставали хз как сейчас) колом если попытаться открыть какой-нибудь текстовый файл на гигабайт. А была бы загрузка файла в отдельном потоке, то можно было бы легко показывать процент загрузки файла, и закрыть программу не дожидаясь конца

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

Звучит как оправдание и роспись в собственной лени и несостоятельности.

Вышеописанная проблема ставит крест на этих редакторах когда для серьезных объемов редактируемого текста. Тот же старичок mcedit прекрасно справляется.

Это очевидная проблема, не исправить её за столько лет, говорит лишь о том, что в принципе разработчикам плевать на фидбек.

писали на сисярпе, но сейчас почти выбросили из стека.

а чем заменили и какой стек технологий в общем?

Вот релевантная история. Был (и есть) один большой коммерческий проект на .Net под винду. Известная в узких кругах либа (не GUI, но работа с данными в том числе графическими). И стали кастомеры теребить, что бы дистр этой либы для Linux был. И всё, дотнетчики сдулись. Теперь есть C++ версия этой либы для Linux (и Винды как опция). Но за качество, кстати, не скажу.

Мораль? C# под линукс - баловство.

Это очевидная проблема, не исправить её за столько лет, говорит лишь о том, что в принципе разработчикам плевать на фидбек

Если тебе нужно редактировать сотни мегабайт в текстовом редакторе, то это значит, что ты что-то делаешь не так. NOTABUG WONTFIX.

Это поделье даже с полусотней не справляется, а если уж быть до конца честным, у него уже начинаются проблемы где-то на рубеже 10мб. Очевидно, что ты транслируешь и отстаиваешь глупую точку зрения и это именно то, что ты делаешь «не так».

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

Благо, есть альтернативы хотя бы.

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

И терабайтный файл должно открывать? Я так понимаю, что ты открываешь логи. А я вот считаю, что в 2020 году неструктурированные логи не должны покидать пределы временных отладочных сборок. Причем, оправданий вроде «чем же я будут это реализовывать» нет, потому что альтернативных систем логирования достаточно.

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

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

Логи в том числе, бывает просто большие текстовые файлы которые не являются логами.

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

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

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

Логи в том числе, бывает просто большие текстовые файлы которые не являются логами

И что же это может быть текстовым файлом хотя бы на десять мегабайт? Даже вся на свете документация по ядру линя в текстовом виде будет меньше десяти мегабайт.

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

А еще meld и vscode не могут сравнивать очень широкие фрагменты, например я не мог в них сравнить большой query plane от postgres, оба приложения не показывают разницу, получилось только через idea.

А еще хочу добавить про mousepad, я пользовался xfce где-то в 2010-2014 годах, mousepad легко справлялся с длинными файлами, не то что gedit. Я хотел его даже под gnome установить, но он тянет лишние зависимости. Сейчас, если очень длинных лог то пользуюсь vim.

бывает просто большие текстовые файлы которые не являются логами.

Да, я вот это в первый раз увидел, когда картинку экспортировал в Gimp в исходный код на С. Там сишный файл создался мегабайт на 30, и были проблемы с открытием такого файла в gedit по-моему.

А так всё возможно открывать огромные файлы нормально, вот парниша запилил свой редактор, открывается файл мгновенно и видна загрузка файла в фоне:

https://imgur.com/a/3k67EsG

https://youtu.be/y_m0ce1rzRI

А еще хочу добавить про mousepad, я пользовался xfce где-то в 2010-2014 годах, mousepad легко справлялся с длинными файлами, не то что gedit. Я хотел его даже под gnome установить, но он тянет лишние зависимости. Сейчас, если очень длинных лог то пользуюсь vim

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

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

есть более богоугодные причины?

Он ненужен.

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

Ну например все книги одного автора одним файлом в тексте.

Да и тут не важно что именно это за данные в тексте, важно что никто для plain текста не ставит отдельно просмотрщик и отдельно редактор, важно что никто перед тем как открыть файл не проверяет его размер, легко представить себе ситуацию когда какой-нибудь софт годами дампит ошибки в лог, и в один прекрасный день этот софт перестает работать (например так делают ide от jetbrains). Ты без задней мысли попытаешься открыть этот лог и получишь зависший редактор который еще пытается под себя задействовать все свободные ресурсы твоего пк, жадно шурша кулерами. А виной всему, собственно, ленивые авторы этого редактора, которые как попало написали редактор для тепличного случая использования.

Ну например все книги одного автора одним файлом в тексте

Зачем? Что ты будешь с этим файлом делать? Читать? Ты выдумываешь проблему из пустого места, а потом жалуешьс, что ее никто не решает.

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

С такой постановкой проблемы я согласен — для редакторов с несколькими одновременно открытыми файлами нужно предусматривать возможность отмены открытия.

Пишу код для юнити под онтопиком, полёт нормальный.

Недолго музыка играла, недолго фраер @cross_platform танцевал.

Да, это очень удобно, особенно если редактор умеет запоминать место на котором ты остановился в прошлый раз. Нет нужды скакать по файлам и директориям, ты просто открываешь один единственный файл и читаешь его, mcedit как раз такой редактор. Хотя то что принес @fsb4000 тоже судя по ролику годная вещь, жаль лишь что вряд ли этот редактор сыщет большую популярность и известность, но инфа полезная, спасибо.

Си-диез, нота на полтона выше Си.

до-диез же – C# или ре-бемоль Db в обозначениях нот. а нота си вообще B

Почему этот язык программирования именуется Си + «#»?

ну вам сразу как бы пропертарщики намекают – сижу за решёткой в темнице сырой, а вы за кроссплатформенность

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

человечество билось над задачей компилять яву в машинный код задолго до появления шарпа, но так и не добилось (с)

AOT жабы существует: баян же (Harmony) или OpenJDK (например Bazel в бинарнике 200 Мб) , или проприетарный Excelsior JET

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

и прокачка персонажей в майти кликерах где скорость атаки решает приводит к тому, что вся эта махровая асинхронщина тормозит ещё больше :)

если с малой скоростью ещё можно успеть вмешаться (тормозит как-то плавнее), то тут искусственный идиот работает как «бежать к ближайшему врагу и сдохнуть быстро», аж не успеваешь вмешаться.

начинаешь проигрывать чаще когда перс больше прокачан.

вот такой офигенный движок Unity чо. или школьники-девелоперы.

Я не слышал про многопоточные системы игровой логики.

то что ты не слышал – не означает что их нет. та же акторная модель, мультиагентное моделирование. или объектно-функционально реактивное чего-нибудь (и функциональные объекты или монады для автоматической распараллеливаемости). ну или какой-нибудь прологоерланг в качестве отдельного AI движка, но в геймдеве нечасто встретишь такое, печалька.

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

async/await и махровая асинхронщина в женской (или непоследовательной модальной не линейной темпоральной а мультивременной) логике же.

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

они пишут вот прям так как думают – а думают они непоследовательно.

и вообще, с чего ты решил что императивная мужская последовательная логика это прям верх достижений. логика любая может быть (но для качественной да, системная – так что общая картина важна – либо лучше симультанная общая и частная одновременно с Zooming UI Eagle View Раскина заходит лучше)

отсюда тормоза типичных поделий на Unity или жабаскрипте с сисярпом.

И чем сложнее эта модель, чем более она далека от потребностей реального мира — тем она красивее.

этот самолёт летать не будет – он недостаточно красив (ц)

практика мерило истины. всё мерять надо с профайлером.

миры то не реальные, логика не реальная либо её view, виртуальщина на виртуальной машине сидит и GC погоняет.

что сама индексация производится медленно, поскольку для нее нужно прочитать полностью весь файл, даже если отображается только одна строчка.

не нужно для неё читать полностью весь файл. те же mmap файлы, skip list и прочие оптимизации.

И что же это может быть текстовым файлом хотя бы на десять мегабайт?

/var/log/syslogd*

Си-диез, нота на полтона выше Си.

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

мультиагентное моделирование. или объектно-функционально реактивное чего-нибудь (и функциональные объекты или монады для автоматической распараллеливаемости). ну или какой-нибудь прологоерланг в качестве отдельного AI движка

Назови игру, сделанную на такой логике.