Вспомнились тут многочисленные вопросы по поводу вычисления функций. Большинство мало что знает про парсинг даже базового, а перспектива использования генераторов пугает.
Есть, однако, один старый но интересный алгоритм — парсер Пратта. Помимо прочих его достоинств, он еще и не требует генераторов и DSL, и может быть оформлен в виде махонькой библиотечки (понятно, с какими то ограничениями).
Вопрос, собственно, в следующем — может имеет смысл его добавить в эхотаг?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос, собственно, в следующем — может имеет смысл его добавить в эхотаг?
А вот есть у меня предложение: завести отдельный CodeJam.Extras.
Потому что как минимум у тебя и у ув. IT есть прикольные штуки, которые и не совсем вписываются в идею "библиотека, которая нужна в любом приложении", и выбрасывать их жалко.
Здравствуйте, Sinix, Вы писали:
S>А вот есть у меня предложение: завести отдельный CodeJam.Extras.
CodeJam, он и так по сути extras к фреймворку. А тут уже какой то extras к extras.
S>Потому что как минимум у тебя и у ув. IT есть прикольные штуки, которые и не совсем вписываются в идею "библиотека, которая нужна в любом приложении"
Я, честно говоря, не вижу особых проблем. Самое главное что зависимостей, что внешних, что внутренних, новых не добавляется, а лишние пару десятков килобайт в бинарнике вряд ли кому-то помешают.
Ну и по поводу вписываемости. Чем, к примеру, по вписываемости парсер CSV отличается от парсера арифметических выражений, сможешь сформулировать?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>CodeJam, он и так по сути extras к фреймворку. А тут уже какой то extras к extras.
На сейчас CodeJam — это набор компонентов, которых _не_хватает_ фреймворку. Т.е. если что-то добавляется — оно
* решает проблему до конца, а не оставляет заготовку "обработать напильником".
* по уровню качества держит планку самого фреймворка.
* не вызывает вопросов "что оно здесь вообще делает?"
Все дополнительные штуки все три пункта как правило проваливают, т.к. используются где-то в кишках инфраструктурного кода и для них все эти красявости — дело десятое по важности.
Если их все включать, то получается что-то типа классификации Борхеса.
Я такую внутреннюю библиотеку поддерживал, вышла фигня. И весь код до уровня отлично не дотянешь, и даже сохранить планку не получается. Тяжело объяснить, почему какой-то код надо вылизать до блеска, если в половине классов в проекте вообще конь не валялся.
AVK>Ну и по поводу вписываемости. Чем, к примеру, по вписываемости парсер CSV отличается от парсера арифметических выражений, сможешь сформулировать?
Ну вот их я туда же бы перекинул, кстати. И DisjointSets тоже.
Ну вот давай на примере сабжа:
S>На сейчас CodeJam — это набор компонентов, которых _не_хватает_ фреймворку.
В фреймворке, очевидно, проблема парсинга арифметики никак не решена.
S> Т.е. если что-то добавляется — оно S>* решает проблему до конца, а не оставляет заготовку "обработать напильником".
До конца невозможно решить почти никакую проблему. Возьми почти любой блок функционала что есть уже сейчас — всегда найдется что добавить.
Я, может, не очень ясно выразился. Предлагается:
1) Готовый алгоритм парсинга Пратта.
2) Для него — готовый наборчик для лексического анализа базовых вещей, необходимых для арифметики: операторы, целые, дробные числа, строковые константы, вызов функций.
3) Готовый базовый сценарий парсинга и вычисления арифметического выражения.
4) Возможно, еще готовый компилятор арифметики.
Что здесь оставляет ощущение "обработать напильником"? Можно, конечно, п. 1 и 2 сделать приватными, чтобы оно уж совсем вещью в себе было, но мне оно не кажется необходимым.
S>* по уровню качества держит планку самого фреймворка.
А кто тут предлагал плохое качество?
S>* не вызывает вопросов "что оно здесь вообще делает?"
Субъективно, однако.
S>Я такую внутреннюю библиотеку поддерживал, вышла фигня. И весь код до уровня отлично не дотянешь, и даже сохранить планку не получается. Тяжело объяснить, почему какой-то код надо вылизать до блеска, если в половине классов в проекте вообще конь не валялся.
С вылизыванием все просто. Если есть сомнения — отправляем в experimental. Парсер командной строки, к примеру, до сих пор там, потому что в качестве, да и вообще в нужности его я не уверен.
AVK>>Ну и по поводу вписываемости. Чем, к примеру, по вписываемости парсер CSV отличается от парсера арифметических выражений, сможешь сформулировать? S>Ну вот их я туда же бы перекинул, кстати. И DisjointSets тоже.
DisjointSets уже в experimental. А парсер CSV просило много народа, поэтому я считаю что он должен юыть в основной части уже сейчас. Если есть какие то вопросы по его качеству — пиши.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK>Я, может, не очень ясно выразился. Предлагается:
Да это понятно, я тож не совсем внятно написал.
Имел в виду другое: 99.9% нашей целевой аудитории эти фичи не нужны. Ну не пишет никто каждый день парсер csv/арифметики/реврайтер для expressions.
А если используют, то не в чистом виде, а в составе проверенных на реальных сценариях библиотек.
Например, тот же csv обычно дополняют таким же по API ридером, только для экселя, поверх oledb-провайдера. Потому что это следующая просьба пользователей после "мы умеем .csv".
Впихивать всё в CodeJam долго не получится. Рано или поздно часть всё равно придётся выносить. Ну, как разделили Rx и Ix в итоге.
И чтобы не тащить неиспользуемый код прицепом, хорошо бы с самого начала его вынести в отдельный пакет. Тогда у постов "добавлять или нет?" пропадёт главный довод против "я не уверен, что оно нам надо". И, соответственно, количество полезняшек в Extras должно только вырасти.
Если нет — фиг с ним, по факту перенесём, причём ничего не ломая. Type forwarding давно работает.
Здравствуйте, Sinix, Вы писали:
S>Имел в виду другое: 99.9% нашей целевой аудитории эти фичи не нужны.
Хм. Тут, видишь ли, такое дело: то что конкретная фича не нужна 99% вовсе не означает, что эти 99% пользуются одними и теми же фичами.
S> Ну не пишет никто каждый день парсер csv/арифметики/реврайтер для expressions.
Так речь не про то чтобы писать, а про то чтобы использовать. Точно так же 99% никогда не понадобятся арифметические операторы в дженериках или какой нибудь Disposable.Merge.
S>Впихивать всё в CodeJam долго не получится.
Не получится. По причине того что парсер экселя далеко за пределами разумного по объему, а использование внешнего парсера это зависимость. При этом дырку для такого я в API оставил.
S>И чтобы не тащить неиспользуемый код прицепом, хорошо бы с самого начала его вынести в отдельный пакет. Тогда у постов "добавлять или нет?" пропадёт главный довод против "я не уверен, что оно нам надо".
Не пропадет. Свалка всего чего ни попадя никому не нужна. Деление на пакеты только лишний сумбур внесет.
Ты поставь себя на место человека, который впервые CodeJam увидел. Вбивает он название в нугет, а там стадо пакетов. И если про какой нибудь CodeJam.Wpf сразу все понятно, то увидев CodeJam.Extras можно долго чесать репу.
Именно поэтому идея создавать несколько пакетов, разница между которыми нечеткая и неформальная мне кажется плохой идеей. Должна быть доступна реверсивная логика — если мне нужна такая то фича, то в каком пакете она, если она вообще есть, точно будет?
Отсюда и деление, которое до этого обсуждалось — строгое деление по зависимостям + инкубатор для кода недостаточной зрелости.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK>Не пропадет. Свалка всего чего ни попадя никому не нужна. Деление на пакеты только лишний сумбур внесет. AVK>Ты поставь себя на место человека, который впервые CodeJam увидел. Вбивает он название в нугет, а там стадо пакетов. И если про какой нибудь CodeJam.Wpf сразу все понятно, то увидев CodeJam.Extras можно долго чесать репу.
Ок, точку зрения понял. Тогда оставляем как есть, благо растащить если что не проблема.
И тогда в Contributing надо добавить раздел про Extras — что-то в духе "Мы принимаем дополнения, которые строго говоря не входят в ответственность Core-части фреймворка, велкам".
Над формулировкой подумаю на свежую голову, если есть идеи — давай
Зачем надо: чтоб больше не тратить время на дискуссии "а оно нам надо?". Один раз обсудили — хватит
Хотя лично я всё равно разбил бы. не на пакет, так на сборки. Пару раз уже наступал на грабли "всё в одной сборке", больше не хоцца.
Здравствуйте, Sinix, Вы писали:
S>И тогда в Contributing надо добавить раздел про Extras — что-то в духе "Мы принимаем дополнения, которые строго говоря не входят в ответственность Core-части фреймворка, велкам". S>Над формулировкой подумаю на свежую голову, если есть идеи — давай
Слово "фреймворк" точно не подходит. У нас принципиально не фреймворк, никакой сквозной функциональности.
S>Хотя лично я всё равно разбил бы. не на пакет, так на сборки.
Смысла ноль. Пакет инсталлируется целиком, никто потом лишние референсы руками вычищать не будет.
S> Пару раз уже наступал на грабли "всё в одной сборке", больше не хоцца.
Ну так надо делать так, чтобы этих грабель не было, но сборка была одна.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
S>>И тогда в Contributing надо добавить раздел про Extras — что-то в духе "Мы принимаем дополнения, которые строго говоря не входят в ответственность Core-части фреймворка, велкам". S>>Над формулировкой подумаю на свежую голову, если есть идеи — давай
AVK>Слово "фреймворк" точно не подходит. У нас принципиально не фреймворк, никакой сквозной функциональности.
Не, я про то, что у нас изначально получался набор методов и типов, которые органично встраиваются в общий дизайн BCL и поправляют косяки, при этом сохраняя общую идеологию.
И плюс потом стали добавляться типы, которые не решают проблемы фреймворка, а добавляют новые вещи, которых в фреймворке в принципе нет.
Вот про эту вторую часть надо задокументировать, что всё ок, её тоже берём.
Осталось только этот момент как-то внятно сформулировать, у меня сейчас с этим явно проблемы
AVK>Ну так надо делать так, чтобы этих грабель не было, но сборка была одна.
Ну вот не знаю как это сделать. В чём засада: для дополнений к фреймворку планка нереально высокая, т.к. она самим фреймворком задрана выше некуда. Это мы привыкли и не замечаем, а вот при попытке адаптировать код из STL
вылезает куча моментов, которые рядом с "родным" API смотрятся откровенно чужеродно.
Для новых вещей такого давления "вписать как будто тут и было" нет и планка по замороченности обычно значительно ниже. Ниже — не значит сам код хуже, просто не надо учитывать дикое количество нюансов типа "как называется уже существующая реализация того же" и "нет ли конфликтов с стандартным API" / гадлайнами.
Ну например, раз речь зашла про CSV: тот же namespace TableData в "core"-библиотеке смотрится странно, в public api используются nested-типы (TableDataParser.Parser), в интерфейсах есть неиспользуемые методы (ITableDataFormatter.GetValueLength), методы бросают исключения прямо в итераторах (TableDataParser.Parse()), но это всё фигня и пардон мой французский задротство. По сравнению с решаемой задачей — придирки на ровном месте, фу-фу-фу так делать.
Почему фигня? Потому что эти мелочи не имеют никакого значения, т.к. это не код уровня фреймворка. Он не будет использоваться в сотнях-тысячах мест, его можно поправить, не вредя всем клиентам, риски от выстрелившей ошибки банально ниже. Тут нет необходимости заморачиваться, время можно гораздо продуктивней потратить.
Как показывает практика, вот такой вот код надо держать отдельно, иначе раздолбайство рано или поздно переедет и в первую часть. Где оно всё-таки нежелательно
Здравствуйте, Sinix, Вы писали:
S>Ну например, раз речь зашла про CSV: тот же namespace TableData в "core"-библиотеке смотрится странно, в public api используются nested-типы (TableDataParser.Parser), в интерфейсах есть неиспользуемые методы (ITableDataFormatter.GetValueLength)
Это все артефакты старых версий. Поправить — секунда.
S>, методы бросают исключения прямо в итераторах (TableDataParser.Parse())
И что в этом плохого?
S>Как показывает практика, вот такой вот код надо держать отдельно, иначе раздолбайство рано или поздно переедет и в первую часть. Где оно всё-таки нежелательно
В данном случае "раздолбайство" просто надо поправить и не делать из этого проблемы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Это все артефакты старых версий. Поправить — секунда.
Ну блииин, пробема не в том, что поправить секунда. Проблема в том, что никто этим на практике не занимается, потому что некритично. Планка ниже, как я и говорил. Не написал бы — оно бы так и оставалось фиг знает сколько времени
S>>, методы бросают исключения прямо в итераторах (TableDataParser.Parse()) AVK>И что в этом плохого?
Я про
public static IEnumerable<DataLine> Parse([NotNull] this Parser parser, [NotNull] TextReader reader)
{
if (parser == null) throw new ArgumentNullException(nameof(parser));
if (reader == null) throw new ArgumentNullException(nameof(reader));
var lineNum = 1;
while (true)
{
var lastLineNum = lineNum;
var values = parser(reader, ref lineNum);
if (values == null)
yield break;
if (values.Length > 0) // Skip empty linesyield return new DataLine(lastLineNum, values);
}
}
Cтандартная рекомендация — валидацию аргументов делать до создания итератора. Иначе исключение бросится позже, когда по стеку уже не восстановишь причину ошибки.
S>>Как показывает практика, вот такой вот код надо держать отдельно, иначе раздолбайство рано или поздно переедет и в первую часть. Где оно всё-таки нежелательно AVK>В данном случае "раздолбайство" просто надо поправить и не делать из этого проблемы.
Ну вот не получается. Это я готов такой фигнёй заморачиваться, потому что на практике большую часть граблей оттоптал и повторно на них наступать не хочу. С остальными как? Мы ж так половину участников распугаем. Вон я бедному ув. Lexey в соседней ветке чую уже весь мозг вынес. Но там хоть по делу относительно, т.к. штука относительно часто будет использоваться. С csv смысла так упарываться нет, невыгодно получается.
Оффтоп: Да, только заметил (ага, на девятый день Зоркий Глаз...) Мы чего, серьёзно первый релиз как 1.0.0 выпускаем? По соглашениям semver/нюгета:
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
Здравствуйте, Sinix, Вы писали:
AVK>>Это все артефакты старых версий. Поправить — секунда. S>Ну блииин, пробема не в том, что поправить секунда. Проблема в том, что никто этим на практике не занимается, потому что некритично.
Нет, просто руки не дошли.
S> Планка ниже, как я и говорил.
Нет, не ниже.
S> Не написал бы — оно бы так и оставалось фиг знает сколько времени
На то code review и придумано.
S>Cтандартная рекомендация — валидацию аргументов делать до создания итератора. Иначе исключение бросится позже, когда по стеку уже не восстановишь причину ошибки.
Ну, не то чтобы совсем не восстановишь. Ну значит надо поправить.
AVK>>В данном случае "раздолбайство" просто надо поправить и не делать из этого проблемы. S>Ну вот не получается.
Надо чтобы получалось.
S> Это я готов такой фигнёй заморачиваться, потому что на практике большую часть граблей оттоптал и повторно на них наступать не хочу. С остальными как? Мы ж так половину участников распугаем.
Некого пока пугать. И качество кода с самого старта ставилось во главу угла. Иначе смысла во всем этом немного, проще своими велосипедами пользоваться.
S>Оффтоп: Да, только заметил (ага, на девятый день Зоркий Глаз...) Мы чего, серьёзно первый релиз как 1.0.0 выпускаем?
А ты какой хочешь? 0.0.1? Или 0.1.0?
1.0.0 просто стандартный шаблон appveyor сгенерил как стартовую версию.
S>Мы по-моему с API не определились местами.
С API, ИМХО, всегда будет некоторая неопределенность в нашем случае, потому что проект большей частью из API и состоит. Тащить все эти линуховые традиции с нулевыми версиями — оно смысл особый имеет?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK>Некого пока пугать. И качество кода с самого старта ставилось во главу угла. Иначе смысла во всем этом немного, проще своими велосипедами пользоваться.
Принято. Добавил в Contributing раздел "What can you contribute?" + заодно "ReSharper extensions" про ReSpeller дописал. Плиз глянь, чего не нравится — поправь без обсуждений
AVK>С API, ИМХО, всегда будет некоторая неопределенность в нашем случае, потому что проект большей частью из API и состоит. Тащить все эти линуховые традиции с нулевыми версиями — оно смысл особый имеет?
Да, оно и в semver и в устоявшейся практике давно используется. Сколько не видел свежих проектов, везде примерно один и тот же смысл у версий.
Для нас отлично подходит 0.1.0, конечно. Он же "мы уверены, что код готов к продакшну, но продвинулись не так далеко, чтобы ничего нельзя было поменять. Предложения как сделать лучше обязательны!"
Здравствуйте, Sinix, Вы писали:
S>Для нас отлично подходит 0.1.0, конечно. Он же "мы уверены, что код готов к продакшну, но продвинулись не так далеко, чтобы ничего нельзя было поменять. Предложения как сделать лучше обязательны!"
Поздновато ты сказал. 0.1.0 после кучи пререлизов 1.0.0 будет совсем не в тему.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Поздновато ты сказал. 0.1.0 после кучи пререлизов 1.0.0 будет совсем не в тему.
Ну да, я ж говорю, "только на третий день индеец Зоркий Глаз..."
Но нам ничего не мешает сделать unlist для пререлизных версий. Или оставляем как есть, на твоё усмотрение.
".
