Andrey Podkolzin podkolzzzin

Согласен! Идеальный кейс для этого примитива

Круто! Очень рад, что статья помогла.
Сможете поделится кейсом в котором пригодился? Думаю реальный кейс окажется полезен «будущим поколениям»

А, было бы интересно почитать, как пришли к такой разработке?

Несколько раз, перед необходимостью очередного допила мой, или чей-то еще воспаленный под вечер мозг предлгал эту идею. На утро, к счастью, мы никогда не приступали к такому решению.
Меня дико впечетляло как ANTLR разруливал различные сложные граничные кейсы, которые реально встречались в наших грамматиках. Вырастить свой генератор парсеров для обработки их всех потребовало бы несравнимо больше усилий. Хотя, будь я проклят, думаю у меня бы аж глаза искрили вдохновением от такой задачи первые несколько недель!

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

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

I have used SemaphoreSlim class for such purpuses.

private readonly SemaphoreSlim syncObject = new SemaphoreSlim(1);
...
      syncObject.Wait();
      try {
        // CODE YOU WANT TO DEBUG
      }
      finally {
        syncObject.Release();
      }

Во второй части обращу на это больше внимания. Спасибо

Спасибо!
Вторую часть надеюсь закончить и опубликовать в середине июня.

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

Спасибо. Гляну в эту сторону.

Спасибо за наводку.
Если по максимуму использует оперативную память, то это может для нас быть проблемой.
В 2017 году MS VS и MS SMS это 32 битные приложение, а значит мы делим с ними жалкие 3.25(по факту меньше) оперативной памяти.

Не случилось, но спасибо за наводку. Глану в этом направлении

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

Как-то в Сети не почти ничего про эту технологию. Можете рассказать или навести на правильные ссылки?

Мой тест имел кое-какую специфику, о которой я писал:
Мы храним текст построчно, а значит хотим и сохранять и вычитывать тоже построчно. К тому же при вычитке одним куском рискуем нарваться на огромный memory allocation, и нарваться на него же при сохранении, если для этого нужно склеить все строки вместе. В LiteDB есть возможность скормить IEnumerable и он отлично сохранится, и отлично вычитается. В SQLite строка в документе представляла собой строку в базе. Получается для документа в 100 строк, выполнялось 100 инсертов, что было дольше чем выполнить 1 в LiteDB.

Не очень пойму как мог бы помочь sqlite json extension. Это ведь набор функций для работы с json или я не прав?
Если это действительно всего лишь набор функций, то думаю еще бы потерял в скорости, генерируя для вставки в базу из текста json, а потом разбирая его, пусть даже последним бы и занималась SQLite. SQLite реляционная база и я ожидал от нее наибольшей производительности именно если складывать в нее реляционные данные.

Режим журналирования SQLite: PRAGMA journal_mode = OFF
Использовал по транзакции на файл.
Так же и litedb все льется одним insert'ом, что, пусть и с натяжкой, с натяжкой можно считать одной транзакцией.

Сохраняется текущее состояние без возможности undo.
Намек, что-то не очень понял. Вы про VCS?

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

Ничего себе. На этот круг ада благо еще не приходилось спускаться. Спасибо за ссылки и интересный трюк.
Буду иметь ввиду в моменты глубокого отчаяния)

Спасибо за комментарий. Сейчас проверил, breakpoint сработал отлично, но установить condition никак не получается.
В доке написано, что аргумент называется crColor.
А без аргументов становится очень тяжело трассировать что-то внятное… Возможно есть способ достать стек, но мне кажется аргументы более точно идетифицируют утекающий объект.

Пора идти за книгой по perl. Часто внутренний/внешний голос говорит, что задача хорошо решается перлом.

Да в шарпе есть очень четкий набор правил, как использовать unmanaged ресурсы.
1. Никогда не используйте unmanaged ресурсы.
2. Если никогда наступило, то оберните ресурс в класс, задачей которого будет следить за этим ресурсом. В классе должен присутствовать Dispose и финализатор/деструктор, оба освобождающие ресурс.
Обойтись одним деструктором, увы, не получится, так как в c# уж очень недерменирована его работа.

По этому принципу написаны все объекты из System.Drawing.

Про трюк с #define. В таком виде в шарпе его не провернуть. Но мне кажется он не будет корректно работать и на плюсах или си, поправьте, если ошибаюсь.
#define на плюсах это директива препроцессора, тоесть «выполняется» на этапе компиляции. А, что если вызов интересующего Вас метода происходит из подключенной dll библиотеки? Мне кажется трюк с #define не сможет поймать такой трюк, хотя мог где-то и ошибиться в размышлениях.
Есть трюк который точно сработает, он был моим последним вариантом, на случай, если вообще ничего не будет помогать:
Подменить в памяти вызовы нативной функции на свои. Когда-то читал, что так можно делать, но полного представления что-именно нужно для этого написать нету, потому рад что не пришлось спуститься на последний круг ада. Хотя если бы пришлось, то изменилось бы не так много: собрать лог, найти что не удаляется, остановить отладку в момент создания текущего объекта. Разве что лог пришлось бы собирать самому.

Кстати, была идея написать подобную тулу, но быстро испугался объема работы.
Хотя с радостью увидел бы такую фичу в каком-нибудь dotMemory и ему подобных.

Я правильно понял, у Вас была утечка памяти? Почему пришлось идти именно таким путем, а не использовать профилировщик?

А поделитесь секретом — насколько локализован был баг на небольшой площади кода? В смысле ну статический анализ смог бы найти?

А вот здесь интересно вышло. Утечек было 3:
1. Самая интенсивная. Была донельзя банальна: не вызывался Dispose объекту, который не отписывал от событий дюжину других объектов, которые оставались висеть в памяти и держать объекты, которые держали GDI-wrapping-objects.
2. Наименее интенсивная. Была в нашем коде. И думаю могла пойматься бы статическим анализатором, но боюсь кроме дельных срабатываний анализатор выдал бы еще очень много ложных срабатываний, где мог бы просто потеряться.
3. Средней интенсивности. Оказалась в коде third-party библиотеки, доступа к коду которой не оказалось. И здесь было бы не на что натравить анализатор.

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

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

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

Большое спасибо за статью. Я лишь мог подозревать, что такое должно быть возможно.
Много интересной информации о внутреннем устройстве CLR

Только созрел вопрос, ради любопытства только:

Работоспособность приведенного алгоритма была неоднократно проверена на практике (в том числе, в промышленных разработках) на различных версиях .NET и аппаратных платформах.

Если не секрет, в какой сфере получилось использовать эти навыки? Чертовски интересно услышать какой-то пример.

Люди добрые, объясните темному бедолаге зачем могут быть нужны локальные функции? Что они делают такое чего не покрывают лямбды?

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

Как минимум, ref/out параметры нельзя использовать для async методов(что даже выглядит логичным), а плодить классы для единственного приватного метода, который бы их вернул, не хочется.

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

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

Еще и чертов http-handshake от которого волосы дыбом становятся.
Не знаете, может уже появилась возможность из браузера по средствам js достучаться до udp сокетов?

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

А почему так сосредоточились на важности отображения языка программирования для файла. Я, пользуясь настольными IDE, вообще никогда об этом не задумываюсь т.к. они гарантируют правильную связку и не до конца могу представить случай, когда мне это может понадобится. Я уверен, что файл с разрешением css откроется редактором css, html — редактором html, ts — typescript и.т.д.
Где это может быть полезно? В каком случае может понадобиться изменить связку для какого-то файла отдельно?

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

Какой же хороший, черт возьми, пункт «нравственность»!

Автор статьи сделал невероятный труд!
Мы с другом с пол года назад тоже делали игру, читая статью понял, что и сами прошли 7 кругов наивности, я отлично помню как мечтал отдохнуть после выпуска, хоть и не работал над игрой каждый день, хотя был момент, когда продержался 60 дней подряд.
Мне было бы интересно с ComradMax пообщаться, а не тулить свои неупорядоченные мысли в коммент на хабре. Если интересно пишите мне, поделимся граблями на которые наступали.

Надеюсь что не разочаруюсь.
Когда-то почти год жизни потратил в SimCity3000, но она частенько вылетала, при чем зависало само сохранение, можно было перезагрузить компьютер, загрузить заново, и опять в один и тот же год она зависала.

На выходных буду строить новый город здесь.

Отличный квест. Спасибо

С 12 сдаюсь. Уже всю голову сломал.

Размер всех исходников ~184KB
Размер всех сторонних пакетов ~1180KB
Размер JS файла на выходе ~984KB