What's new in 1.0.0-beta10
------------------------
* InterlockedOperations.Initialize and Update methods
* StringExtensions.Unquote methods
* Add defaultValue parameter to all Min/MaxByOrDefault overloads
* Additional overloads for Algorithms.EqualRange/UpperBound/LowerBound
* Memoize extended up to 8 arguments
* Thread safety for disposables
* AssemblyExtensions.GetAssemblyDir/Path improvements
* Move all string related functions to separate namespace CodeJam.Strings
* Enumerable.Index renamed to WithIndex. IndexItem implements equality stuff
* XNodeExtensions.OptionalXxxValue renamed to XxxValueOrDefault
* Fn<T>.Identity/IdentityConverter renamed to Self/SelfConverter
* TupleStruct renamed to ValueTuple
* Performance optimization
* Refactoring
* Fixes and code cleanup
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Такой вопрос: если я в CodeJam.Main InternalsVisibleTo("CodeJam.Experimental") добавлю — ничего не поломается?
У нас же сейчас нет ещё строгой подписи?
Некритично абсолютно, пока нужно только чтобы internal class PlatformDependent не дублировать.
Если поломается — просто подключу этот класс в experimental как ссылку — тот же эффект будет.
Здравствуйте, AndrewVK, Вы писали:
S>>У нас же сейчас нет ещё строгой подписи? AVK>Есть.
Ага, тогда просто включу файл как ссылку, чтоб не возиться с InternalsVisibleTo.
IT>Как это может помешать?
Так в InternalsTo надо полное строгое имя писать емнип. Если Snk на билд-сервере и в гитхабе отличаются (так делают почти всегда, если не сделано у нас — надо бы поменять) — надо вводить дополнительный conditional symbol "собираем на билд-сервере" и в зависимости от него закидывать нужный public key.
И ещё такая нескромная просьба: я обычно свой публичный код тестами сопровождаю, новый метод, если добавляется, надо тоже покрывать.
Если некогда — просто напиши, чтоб я это дело вручную не отслеживал
Конкретно где вылезло: перегрузка CodeExceptions.ArgumentOutOfRange с одним from.
Неправильное сообщение "$"The value of '{argumentName}' ({value}) should be greater than {fromValue}".
Оно ж >= проверяет
Уже поправил, скину пожже.
UPD О, перегрузку надо вообще выпилить, у нас же для этого ValidIndex есть.
Здравствуйте, Sinix, Вы писали:
S>И ещё такая нескромная просьба: я обычно свой публичный код тестами сопровождаю, новый метод, если добавляется, надо тоже покрывать. S>Если некогда — просто напиши, чтоб я это дело вручную не отслеживал
Ты про Unquote? Просто забыл. Я обычно тоже добавляю, за исключением методов, которые просто синтаксический сахар — инфиксная форма, методы для замены конструкторов и т.п.
S>Конкретно где вылезло: перегрузка CodeExceptions.ArgumentOutOfRange с одним from. S>Неправильное сообщение "$"The value of '{argumentName}' ({value}) should be greater than {fromValue}". S>Оно ж >= проверяет
Тут тесты не спасли бы, ИМХО.
S>UPD О, перегрузку надо вообще выпилить, у нас же для этого ValidIndex есть.
ValidIndex по смыслу не подходит. Там надо было просто > 0. Т.е. это та же проверка диапазона, но с одной границей. Возможно стоит этот кейс даже отдельным методом оформить — GreaterThanZero\GreaterThanOrEqualToZero.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Sinix, Вы писали:
S>Так в InternalsTo надо полное строгое имя писать емнип. Если Snk на билд-сервере и в гитхабе отличаются (так делают почти всегда, если не сделано у нас — надо бы поменять)
А смысл? CAS все равно почти что помер, а больше причин секретить ключ нет. И я, кстати, релизные версии сам собираю, на своей машине. Те что на билд-сервере публикуются только в местном фиде.
Теоретически надо бы настроить сборку по тегу релиза (appveyor такое умеет) и автоматичный паблиш в nuget.org, но у меня руки не доходят, а больше на просьбу никто не откликнулся.
S> — надо вводить дополнительный conditional symbol "собираем на билд-сервере" и в зависимости от него закидывать нужный public key.
Да не надо никаких символов. Просто заменять snk. Проблема в том, что хранить ничего на appveyor нельзя, можно только из интернета доставать. А как это сделать секурно, не храня никаких секретов в репе — я ХЗ.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
S>>Так в InternalsTo надо полное строгое имя писать емнип. Если Snk на билд-сервере и в гитхабе отличаются (так делают почти всегда, если не сделано у нас — надо бы поменять)
AVK>А смысл? CAS все равно почти что помер, а больше причин секретить ключ нет.
А те, кто окончательно помешан на этом деле такие вещи пересобирают у себя со своими собственными ключами.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты про Unquote? Просто забыл. Я обычно тоже добавляю, за исключением методов, которые просто синтаксический сахар — инфиксная форма, методы для замены конструкторов и т.п.
Не, я там написал, про CodeExceptions.ArgumentOutOfRange.
S>>Оно ж >= проверяет
AVK>Тут тесты не спасли бы, ИМХО.
Спасли бы — я для ассертов сообщение проверяю, причём не копирую — пишу по памяти, падает, сравниваю. Почему так:
Сообщение тоже входит в публичный контракт ассерта. Как обычно, я это узнал сложным путём — в режиме дикого аврала с раздачей всем причастным и непричастным надо было исправить ошибку только по логу. Как оказалось, срабатывал другой ассерт, из-за копипасты выдававший не то сообщение. Запомнилось хорошо
AVK>ValidIndex по смыслу не подходит. Там надо было просто > 0. Т.е. это та же проверка диапазона, но с одной границей. Возможно стоит этот кейс даже отдельным методом оформить — GreaterThanZero\GreaterThanOrEqualToZero.
Ага, протупил вчера. Надо было на все проверки смотреть, а не на одну.
В итоге
// Былоprivate static void ValidateIndicesRange(int from, int to, int count)
{
Code.InRange(from, nameof(from), 0);
Code.InRange(to, nameof(to), 0);
if (to > count)
throw CodeExceptions.Argument(nameof(to), $"The {nameof(to)} index should not exceed the {nameof(count)}");
if (to < from)
throw CodeExceptions.Argument(
nameof(from),
$"The {nameof(to)} index should be not less than the {nameof(from)} index");
}
// Сталоprivate static void ValidateIndicesRange(int from, int to, int count)
{
Code.InRange(from, nameof(from), 0, to);
Code.InRange(to, nameof(to), from, count);
}
Скину ближе к вечеру — коммит делал поверх добавленного в experimental кода, его пока рано заливать.
Почему не оформить отдельным методом: вот не встретился мне пока типовой юз-кейз, для которого надо бросать OutOfRange с проверкой только снизу (или только сверху). А вот косяков типа того что выше, когда только половину проверки записали — вот это сколько угодно.
AVK>А смысл? CAS все равно почти что помер, а больше причин секретить ключ нет. И я, кстати, релизные версии сам собираю, на своей машине. Те что на билд-сервере публикуются только в местном фиде.
Угу, сам strong naming походу всё.
Но пока он живой, у strong name есть одно маааленькое преимущество, писал вот тут
strong name позволяет (с некоторыми оговорками) однозначно идентифицировать сборку. По крайней мере, пока разработчик не сделал закрытый ключ открытым и не настрогал тонну разных сборок с одним и тем же assembly name
Ну, т.е. пока у нас ключ не выложен в паблик, левый релиз подкинуть значительно сложнее. Для целевой аудитории (aka кговавый энтерпрайз) — эт точно полезно.
AVK>Теоретически надо бы настроить сборку по тегу релиза (appveyor такое умеет) и автоматичный паблиш в nuget.org, но у меня руки не доходят, а больше на просьбу никто не откликнулся.
А, ну я честно не хочу отвлекаться, т.к. даже то что наобещал пока не успеваю. Как скину (в процессе) — попробую.
S>> — надо вводить дополнительный conditional symbol "собираем на билд-сервере" и в зависимости от него закидывать нужный public key.
AVK>Да не надо никаких символов. Просто заменять snk.
Ну так ключ из snk надо в InternalsVisibleTo писать. И если snk другой — строка в InternalsVisibleTo тож меняться должна.
Проблема в том, что хранить ничего на appveyor нельзя, можно только из интернета доставать. А как это сделать секурно, не храня никаких секретов в репе — я ХЗ.
Угу, поищу способ, если возьмусь за настройку.
Если нам не помогут, то мы тоже никого не пощадим.
