AVK Selected

Товарищ SergASh начал обсуждение, поскольку некропостинг — отдельным топиком.


Тема ассертов довольно объёмная и как всегда, надо начинать с самого начала. Т.е. с

Зачем нужны ассерты?

    class Sample
    {
        public Sample(int sampleCount)
        {
           SampleCount = sampleCount;
        }

        public int SampleCount { get; private set; }

        public Action<string> SampleCallback { get; set; }

        public void Run<T>(T value) where T: class
        {
            for (int i = 0; i < SampleCount; i++) // (0)
            {
                SampleCallback(value.ToString()); // (1), (2)
            }
        }
    }

    // Usage
    static void UsageSample()
    {
        var sample = new Sample(10)
        {
            SampleCallback = x => Console.WriteLine(x)
        };

        // ...
        // Some code
        // ...

        sample.Run("Hello!");
    }

Здравствуйте, Sheridan, Вы писали:

S>Напомню, с чего всё началось. Началось всё с того, что я предположил дальнейший путь повышения производительности софта, в связи с скорым (?) достижением железом потолка, будет прокладываться в сторону распараллеливания.
Тут есть ещё такой момент. Описанный, ЕМНИП, у Кнута.
Возьмём какую-нибудь простую задачку. Например, сортировку массива.
Есть десятки алгоритмов, построенных для однопоточных реализаций. Есть несколько алгоритмов, которые построены для многопоточных.
Возьмём экстремальный пример: предположим, у нас есть неограниченное количество "ядер" — вычислителей, каждый из которых может выполнять простую операцию типа compare-and-swap за одну стадию.
Длина массива — N. За какое минимальное количество стадий мы можем отсортировать массив?
Внезапно выясняется, что у современной математики нет способа решения таких задач. Для небольших количеств ядер (<10) нам известны оптимальные конфигурации процессорной сети — полученные, собственно, прямым перебором.

Буду краток.

HgLab -- написанный на .NET сервер Mercurial с поддержкой Push/Pull, браузер исходников, управлятор группами и пользователями и (в будущем) многое другое интересное (Merge Request'ы, поиск по коду, Issue Tracking, Deployment Tracking).

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

Draft spec for records and pattern-matching in C#
https://roslyn.codeplex.com/discussions/560339

Сабж. Ещё подробности.

Если коротко — ранний билд VS с поддержкой всего, что наобещали на //build/, включая RyuJIT, ef7 и asp.net vNext.

Сборка очень ранняя, требуется ставить на "чистую" машину без установленной ранее VS (читай — лучше не рисковать и использовать для экспериментов виртуалку).

Из того, что точно будет интересно пощупать — интегрированный в VS roslyn compiler + c# 6 со всеми плюшками типа someVal?.ToString() ?? "".

Демонстрация возможностей linq2db по созданию таблиц в БД и изменению данных в них

Один весьма известный и уважаемый в узких кругах исследователь взял на себя труд глянуть по диагонали отдельные части реализации иксов и подготовить об этом презенташку для очередной конференции по новым компьютерным технологиям и защите компьютерных программ: http://media.ccc.de/browse/congress/2013/30C3_-_5499_-_en_-_saal_1_-_201312291830_-_x_security_-_ilja_van_sprundel.html

Для тех, кому лень смотреть и делать выводы... Пара цитат из презентации:

"GLX is a horrible demotivator! 80,000 lines of sheer terror."

и

"In the past
couple of months I've found 120 bugs there, and I'm not close to done."

речь о 120 security багах, если кто не понял. После такой внезапности, xorg-разрабы решили (видимо впервые за все время существования проекта) просканить свой код хоть каким-нибудь статанализатором. Им под руку попался http://cppcheck.sourceforge.net/...

Здравствуйте, Аноним, Вы писали:

А>Мне кажется второй способ более простой и удобнее для чтения отладки и т.п.
А>Есть ли какая-то эффективность у 1го способа или это уже можно считать как устаревший подход ?

На нынешнем этапе развития науки и техники устаревшим считается скорее второй подход.

Во всех трех вариантах:

1) Begin/End-методы,
2) обертка Task.FromAsync над ними, упомянутая TK
и
3) синхронные сетевые вызовы в теле таски,

непосредственно вызовы и ожидания ответов действительно происходят в потоках из IO-пула. Но вариант №3 потребляет _еще_один_ поток, в дополнение к уже потребляемым IO-потокам. Т.е. в общем случае требует в два раза больше потоков (=> в два раза больше памяти) и рано или поздно упрется в лимит на их число.

Преимущества первых двух вариантов над третьим особенно хорошо видны, если принудительно ограничить размер ThreadPool-а:

[c#]
class Program
{
const int CallCount = 30;

Сергей, добрый день.

Что ж, я в принципе разобрался со всеми сложностями и напастями, что мне встречались и теперь могу рассказать, что же у меня получилось.
На текущий момент, у меня готов первый вариант, из тех, что я описывал, т.е. практически всю работу на себя берет WCF (правда в .Net 4.5 работа так или иначе идет с использованием WIF, но от вас лично не потребует ни строчки кода для WIF — разве что вы начнете делать какие-то кастомные расширения).

Для начала, чтобы у нас было единое понимание того, что происходит, позволю себе небольшое описание процесса (см. картинку):

0. Пользователь вводит свои UserName и Password (U/P)
1. Клиент пытается подключиться к WCF Service используя переданные ему U/P. Однако, инфраструктура WCF, анализирует указанные ей настройки и выясняет, что от нее требуется работать по Federation протоколу, а это значит, что вместо прямого обращения WCF Service...

Это загадка, которую я недавно публиковал на Twitter и давал коллегам на работе. Пока что её отгадал только один человек — Mads Torgersen (причём почти сразу).

Напишите валидную C# программу, которая содержит следующую последовательность токенов:

? null :

и которая остаётся валидной, если мы уберём токен null из этой последовательности, т.е. оставим

?      :

	Пояснения
	* Валидная программа — это программа, которая компилируется без ошибок. Она может быть как приложением (.exe), так и библиотекой классов (.dll). * Комментарии, части строковых литералов, имена регионов, текст в пропущенных секциях (#if false) и т.д. не являются токенами. * Части токенов не являются токенами (например, символ `:` в выражении `foo::bar` или `?` в выражении `foo ?? bar` не являются токенами) * Runtime поведение программы несущественно. То, что оно может измениться при удалении токена null, также несущественно.