Подчистил всё связанное с сборкой в CJ, теперь тормоза / глюки в студии должны уйти.
Perftests убрал из солюшна, будут в отдельном SLN.
Заодно поправил расположение проектов, перевёл на flat tree (все проекты лежат по пути .\ProjName\ProjName.csproj, группировка проектов задаётся в солюшне).
Если есть ещё реквесты по CJ — пишите, постараюсь сделать.
UPD. А, да. Чисто технически у нас теперь нет препятствий для поддержки всякой экзотики типа .net 2.0 / netstandard 2.1 etc. Тесты и сборка должны прожевать без проблем.
Здравствуйте, Sinix, Вы писали:
S>UPD. А, да. Чисто технически у нас теперь нет препятствий для поддержки всякой экзотики типа .net 2.0 / netstandard 2.1 etc. Тесты и сборка должны прожевать без проблем. .NET 2.0 готов.
Здравствуйте, Sinix, Вы писали:
S>Подчистил всё связанное с сборкой в CJ, теперь тормоза / глюки в студии должны уйти.
S>Perftests убрал из солюшна, будут в отдельном SLN.
А когда будут то ?
Если есть время / желание — сделаешь скрипт, который будет тесты nunit под net 3.5 запускать? У нас как выяснилось, и 3.5 по факту под 4.0 запускаются.
У меня руки пофиксить не дошли. Скрипт для существующих сборок в build\buildscripts, что у appveyor установлено на машине — см https://www.appveyor.com/docs/windows-images-software/#test-runners
Здравствуйте, _NN_, Вы писали:
S>>Perftests убрал из солюшна, будут в отдельном SLN. _NN>А когда будут то ?
Через неделю-две, хочу их обновить и техдолг по ним закончить.
Некритично, т.к, народ особо перфтесами не увлекается.
Здравствуйте, IT, Вы писали:
IT>Ещё бы от туплов избавиться.
Андрей выше написал, мы их добавили только для старых FW. Если мешают — давай сценарий, подумаю. Про netstd 1.6 помню, попробую.
Здравствуйте, Sinix, Вы писали:
S>Андрей выше написал, мы их добавили только для старых FW. Если мешают — давай сценарий, подумаю. Про netstd 1.6 помню, попробую.
Они и для старых не нужны. Мы не предоставляем никакого API, где-бы использовались туплы. Исключительно для внутреннего пользования, как я понял просто поиграться кому-то хотелось. Выкинуть нафиг и не нужно будет тащить зависимую сборку для любых фреймворков.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sinix, Вы писали:
S>>https://github.com/rsdn/CodeJam/issues/48
IT>Это protected internal. Стоит ли вообще трогать и вводить out параметр? Как я понимаю смущает Try в названии метода?
Уже не актуально.
Обсудили, что такие методы назвать надо с Try**.
Забыл закрыть.
S>>https://github.com/rsdn/CodeJam/issues/47
IT>Это я вообще не понял. Почему? Кто сказал?
Тогда стоит назвать, хотя бы, TryGetConvertExpression.
Методы возвращающие null без какого-либо указания это источник ошибок.
Проверенно на опыте.
S>>https://github.com/rsdn/CodeJam/issues/46
IT>То же самое. Мне, например, как раз интересен API, который принимает null и его нормально обрабатывает.
Очень подозрительный метод расширения, который умеет принимать this как null.
А если в коде вызывается как статический метод, то зачем он метод расширения.
В любом случае, возвращаемый null это стопроцентный источник будущих ошибок.
S>>Что делать бум? Оставляем как есть / меняем? IT>Нафиг. Какие-то странные претензии. Хотя бы обостнование какое-нибудь услышать. А то опять получается — мои предпочтения круче твоих предпочтений.
Стиль кода подразумевает не возвращать null если это не указано в название метода.
Или это не так ?
Здравствуйте, _NN_, Вы писали:
IT>>Нафиг. Какие-то странные претензии. Хотя бы обостнование какое-нибудь услышать. А то опять получается — мои предпочтения круче твоих предпочтений. _NN>Стиль кода подразумевает не возвращать null если это не указано в название метода.
Стиль это и есть предпочтения. Такие же как и утверждение, что возвращение null — это стопроцентный источник ошибок. Оно как бы да и как бы нет.
В данном конкретном случае мы имеем дело с ExpressionTree, внешней, не нами разработанной структурой данных, где null — это валидное значение. Не ошибка передачи параметров или возвращаемых значений, а вполне себе нормальная ситуация. ET состоит из кучи других ET, в свою очередь состоящих из множества других, среди которых частенько бывает и null. Подгонять эту конкретную ситуацию под "стиль" не вижу смысла.
Что касается "расширения, который умеет принимать this как null", то у нас там таких строковых расширений мильён и маленькая тележка.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
S>>Что делать бум? Оставляем как есть / меняем?
IT>Нафиг. Какие-то странные претензии. Хотя бы обостнование какое-нибудь услышать. А то опять получается — мои предпочтения круче твоих предпочтений.
Здравствуйте, IT, Вы писали:
IT>Они и для старых не нужны. Мы не предоставляем никакого API, где-бы использовались туплы. Исключительно для внутреннего пользования, как я понял просто поиграться кому-то хотелось. Выкинуть нафиг и не нужно будет тащить зависимую сборку для любых фреймворков.
В кишках Memoize и в SuffixTreeBase используются. Основная проблема с SuffixTreeBase, там тюпл в protected member выставлен.
Если кто уберёт — можно будет тюплы только в таргетинге (для 3.5) оставить.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
IT>>>Нафиг. Какие-то странные претензии. Хотя бы обостнование какое-нибудь услышать. А то опять получается — мои предпочтения круче твоих предпочтений. _NN>>Стиль кода подразумевает не возвращать null если это не указано в название метода.
IT>Стиль это и есть предпочтения. Такие же как и утверждение, что возвращение null — это стопроцентный источник ошибок. Оно как бы да и как бы нет.
Основная проблема в том, что не всегда есть проверки.
Возможно и expr.Item1 никогда не будет null, но никто не проверяет.
private static void Init()
{
var expr = ConvertBuilder.GetConverter(null, typeof(TFrom), typeof(TTo));
_expression = (Expression<Func<TFrom,TTo>>)expr.Item1;
var rexpr = (Expression<Func<TFrom,TTo>>)expr.Item1.Transform(e => e is DefaultValueExpression ? e.Reduce() : e);
_lambda = rexpr.Compile();
}
IT>В данном конкретном случае мы имеем дело с ExpressionTree, внешней, не нами разработанной структурой данных, где null — это валидное значение. Не ошибка передачи параметров или возвращаемых значений, а вполне себе нормальная ситуация. ET состоит из кучи других ET, в свою очередь состоящих из множества других, среди которых частенько бывает и null. Подгонять эту конкретную ситуацию под "стиль" не вижу смысла.
IT>Что касается "расширения, который умеет принимать this как null", то у нас там таких строковых расширений мильён и маленькая тележка.
Думаю, тогда можно это решить аннотацией вида
Не спорю что, скорее, всего проблемы и никогда не будет,
Однако код получается хрупким. Достаточно поменять немного GetConverter и получим NRE там, где не ждали.
protected internal virtual LambdaExpression TryGetConvertExpression(Type from, Type to)
{
var li = GetConverter(from, to, false);
// Тут проверям 'li'return li == null ? null : (LambdaExpression)ReduceDefaultValue(li.CheckNullLambda);
}
public Expression<Func<TFrom,TTo>> GetConvertExpression<TFrom,TTo>()
{
var li = GetConverter(typeof(TFrom), typeof(TTo), true);
// А тут забыли проверить 'li'return (Expression<Func<TFrom,TTo>>)ReduceDefaultValue(li.CheckNullLambda);
}
public Func<TFrom,TTo> GetConverter<TFrom,TTo>()
{
var li = GetConverter(typeof(TFrom), typeof(TTo), true);
// Забыли проверить 'li' сноваif (li.Delegate == null)
{
var rex = (Expression<Func<TFrom,TTo>>)ReduceDefaultValue(li.CheckNullLambda);
var l = rex.Compile();
Schemas[0].SetConvertInfo(typeof(TFrom), typeof(TTo), new ConvertInfo.LambdaInfo(li.CheckNullLambda, null, l, li.IsSchemaSpecific));
return l;
}
return (Func<TFrom,TTo>)li.Delegate;
}
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_NN>>.NET 2.0 готов.
S>Если есть время / желание — сделаешь скрипт, который будет тесты nunit под net 3.5 запускать? У нас как выяснилось, и 3.5 по факту под 4.0 запускаются. S>У меня руки пофиксить не дошли. Скрипт для существующих сборок в build\buildscripts, что у appveyor установлено на машине — см https://www.appveyor.com/docs/windows-images-software/#test-runners
Здравствуйте, Sinix, Вы писали:
S>Основная проблема с SuffixTreeBase, там тюпл в protected member выставлен. S>Если кто уберёт — можно будет тюплы только в таргетинге (для 3.5) оставить.
Если нам не помогут, то мы тоже никого не пощадим.
