Здравствуйте, Ikemefula, Вы писали:
I>>>RX не годится ?
VD>>Если бы он годился бы для всех случаев, то в MS не стали бы в срочном порядке "изобретать" async/await и прикручивать его к C#.
I>
I>Хорошо, что не все немерлесты растеряли способности к адекватным объяснениям.
Что неадекватного ты усмотрел? Это же не я бегаю по форумам C# в темах где упоминается async/await спрашиваю: "Зачем МС делает async/await? Чем RX не годится?".
I>>>tt чем не подходит ?
VD>>Под "tt" ты T4 — генератор текста, имеешь в виду? VD>>Тем же чем RX. Не является удовлетворительным решением для многих случаев.
I>Такой ответ я и сам могу придумать. Меня интересуют конкретные подробности, а не очередной лозунг.
Тебе примеры нужны? Ну, так формулируй вопросы корректно. Примеров много. Вот недавно тебе дали ссылку на разницу между решением на T4 и макросах. Но это чисто количественная разница.
Главное преимущество макросов заключается в том, что они работают во время компиляции и могут взаимодействовать с компилятором. Это позволяет узнать детали кода, и даже (при необходимости) изменить его.
Но ты никогда ничего не поймешь пока не попробуешь Немерл в деле.
Так что если тебе нужны ответы на вопросы, а не повод по плеваться, то просто найди себе интересную задачу и попробуй ее решить.
>>сравнивать какой-нить BMW X5 с Ford T. Тоже конечно машина, но вот ездить на ней как-то не очень удобно
I>Неужели на Немерле нельзя написать более толковый генератор тавтологий ?
А где здесь тавтология?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>"сутки простоя какой-нить большой команды из-за того что кто-то сломал всё совсем уже могут выйти очень дорого"
I>>"Там разработчики сами релизят то что у них на винчестере лежало"
I>>Не ясно, на что уходит неделя, если обычно релиз выкатывается за пару часов с документацией и прочей дрянью
VD>И где же в приведенных цитатах хоть упоминание CVS или VSS?
VD>Сдается мне, что данная догадка высосана из пальца.
Сдаётся мне, что при грамотном VCS и тд нет необходимости релизить то, что лежит на локальном венике, нет простоев из за того, что ктото чтото сломал.
Здравствуйте, VladD2, Вы писали:
I>>Основное время уходит на всякие активности которые не автоматизируются. Например тфс не умеет перезапускать сам себя и продолжать билд.
VD>Так выкинь ТФС.
Здравствуйте, VladD2, Вы писали:
I>>Хорошо, что не все немерлесты растеряли способности к адекватным объяснениям.
VD>Что неадекватного ты усмотрел? Это же не я бегаю по форумам C# в темах где упоминается async/await спрашиваю: "Зачем МС делает async/await? Чем RX не годится?".
Твой ответ как в анекдоте "Где мы находимся ? На воздушном шаре" и потому однозначный неадекват.
I>>Такой ответ я и сам могу придумать. Меня интересуют конкретные подробности, а не очередной лозунг.
VD>Тебе примеры нужны? Ну, так формулируй вопросы корректно. Примеров много.
hi_octane почему то смог объяснить без лозунгов, вот ведь незадача, да ?
VD>Главное преимущество макросов заключается в том, что они работают во время компиляции и могут взаимодействовать с компилятором. Это позволяет узнать детали кода, и даже (при необходимости) изменить его.
"дважды два — четыре !" т.е. снова неадекват
VD>Так что если тебе нужны ответы на вопросы, а не повод по плеваться, то просто найди себе интересную задачу и попробуй ее решить.
Я сюда и пришел за задачами, а не за твоими лозунгами.
I>>Неужели на Немерле нельзя написать более толковый генератор тавтологий ?
VD>А где здесь тавтология?
Тебе понадобилась аналогия в виде сравнения древнего форда с современным БМВ для того, что бы сказать простую вещь, что новое лучше старого. Т.е. твоя фраза по смыслу эквивалентна фразе "хорошее лучше плохого", с учетом твоей же аналогии естественно.
P.S. hi_octane своими сообщениями про применения Немерла целиком полностью компенсирует твой неадекват.
P.P.S. Сделай отдолжение — не пиши мне ничего в ответ, хотя бы в этой теме ?
Я наверное неясно выразился. Тем опусом я хотел подчеркнуть лишь то что принятый у нас подход, при котором от момента коммита, до момента когда клиент запускает у себя обновлённую версию проходит неделя, обоснован экономически. И одна из составляющих этого обоснования — это очень большая цена одной ошибки. Другие подходы которые я там перечислил — у нас не используются вовсе, но в других условиях они вполне оправданы. Используемая система контроля версий — второстепенна.
Здравствуйте, hi_octane, Вы писали:
_>Я наверное неясно выразился. Тем опусом я хотел подчеркнуть лишь то что принятый у нас подход, при котором от момента коммита, до момента когда клиент запускает у себя обновлённую версию проходит неделя, обоснован экономически. И одна из составляющих этого обоснования — это очень большая цена одной ошибки. Другие подходы которые я там перечислил — у нас не используются вовсе, но в других условиях они вполне оправданы. Используемая система контроля версий — второстепенна.
Ну это уже понятнее. Так а что входит то в эту неделю ? Ты хоть приблизительно скажи, я с целью для себя интересуюсь, а не потроллить.
Здравствуйте, Ikemefula, Вы писали:
VD>>Так выкинь ТФС.
I>Ты про энтерпрайз когда нибудь слышал ?
Ага. А ты слышал, что есть люди что живут вообще без продуктов от MS?
Ентерпроайз не ентерпрайз — без разрицы. Если у вас нет сборки продукта в один клик, то вы уже накосячили. Если вам мешает ТФС, то выкиньте его на фиг. Есть много других решений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Сдаётся мне, что при грамотном VCS и тд нет необходимости релизить то, что лежит на локальном венике, нет простоев из за того, что ктото чтото сломал.
Тебе надо чаще придерживать то что тебе сдаётся. У людей ведь может быть куча предпосылок для своих решений. Лучше ведь спросить, а не домысливать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>Сдаётся мне, что при грамотном VCS и тд нет необходимости релизить то, что лежит на локальном венике, нет простоев из за того, что ктото чтото сломал.
VD>Тебе надо чаще придерживать то что тебе сдаётся. У людей ведь может быть куча предпосылок для своих решений. Лучше ведь спросить, а не домысливать.
Ты уже показал пример, как не надо домысливать в случае с ТФС. Спасибо, в таких советах я не нуждаюсь.
Здравствуйте, VladD2, Вы писали:
I>>Ты про энтерпрайз когда нибудь слышал ?
VD>Ага. А ты слышал, что есть люди что живут вообще без продуктов от MS?
Ты не уходи от темы, про энтерпрайз слышал ?
VD>Ентерпроайз не ентерпрайз — без разрицы.
Есть разница и очень большая.
>Если у вас нет сборки продукта в один клик, то вы уже накосячили. Если вам мешает ТФС, то выкиньте его на фиг. Есть много других решений.
Кто тебе сказал что у нас чего то нет ? Нужно сильно стараться, что бы попутать билд с релизом. Можешь, кстати, развить тему, как на немикрософтовских технологиях баги сами ассайнятся, фиксятся, контрибутятся и тд и тд.
I>Ну это уже понятнее. Так а что входит то в эту неделю ? Ты хоть приблизительно скажи, я с целью для себя интересуюсь, а не потроллить.
Просмотр (code review) всего закоммиченного кода, тесты у нас на симуляторе, тесты у заказчика на реальном потоке данных, с логгированием "виртуальных" ответов (реальные ответы делает текущая система). Потом анализ тех отчётов по быстродействию, которые прога собрала пока была у заказчика, ну и в заключении официальная писанина — "выложили версию такую-то, по таким-то тестам всё ок, по таким-то ок, параметры такие-то в утверждённых пределах, о чём репорты приложены, и т.п.". Что можно распаралелено, но, например, review и тесты оказалось лучше не параллелить. И самое страшное — если хоть один косяк прошёл за ревью и вылез на каких-то тестах, то всё сначала
Здравствуйте, hi_octane, Вы писали:
_>Просмотр (code review) всего закоммиченного кода, тесты у нас на симуляторе, тесты у заказчика на реальном потоке данных, с логгированием "виртуальных" ответов (реальные ответы делает текущая система). Потом анализ тех отчётов по быстродействию, которые прога собрала пока была у заказчика, ну и в заключении официальная писанина — "выложили версию такую-то, по таким-то тестам всё ок, по таким-то ок, параметры такие-то в утверждённых пределах, о чём репорты приложены, и т.п.". Что можно распаралелено, но, например, review и тесты оказалось лучше не параллелить. И самое страшное — если хоть один косяк прошёл за ревью и вылез на каких-то тестах, то всё сначала
Ужас! Вы на оборону работаете или на космос?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А> А что там, собственно, такого сложного? Я не про наследование грамматик говорю, а про динамические расширения в заранее заданных точках.
Надо сесть и сделать. Это всегда сложно .
Вообще-то там уже не совсем PEG получается. Там для разбора операторов еще TDOP (ака Pratt) должен быть прикручен. Чтобы можно было операторы декларировать удобнее (с приоритетами и левой рекурсией).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_>>>>6) Задачи, которые на C# принято считать требующими кодогенераторов или отдельных программ. У нас например в процессе компиляции макрос лезет по сети и вытягивает оттуда JavaScript, а потом лезет по всему проекту, и в нужных местах корректирует код (не какие-то генерённые файлы обновляет, а разбирает и корректирует писанный людьми код), в соответствии с тем JavaScript. Чтобы такое повторить на C# — убиться надо. I>>>А что за задачу вы решали таким образом ? _>>Связь с монструозной прогой на стороне клиента.
I>Шота мне кажется вы изобрели уже давно известную технологию Какого характера изменения что вносятся скриптом ? Почему нельзя это заменить на инжекцию депенденсов ?
Примерно такая последовательность:
1) Объявляются интерфейсы, прикручиваются к классам
2) В классах создаются методы которых нет
3) Подставляются реализации в те методы которые уже есть, но делают throw NotImplementedException, оставляются реализации методов которые есть и делают что-то реальное.
4) В самом последнем проходе, те методы которые остались throw NotImplemented, например потому что ни в JavaScript ни в коде реализации для них не оказалось, намеренно превращаются в ошибки компиляции, чтобы ни один NotImplemented не попал случайно в релиз. Здесь и ниже по ветке есть ещё немного
, и кроме того, я уверен, хороший программист всегда найдёт способ выкрутиться. До нас эту же работу делали ацки сильные хлопцы на C++, и эту же задачу решали. #define'o'кодинг там у них был ацкий, или может ещё что, главное работало. Но на Nemerle это получилось красиво, и как-то легко.
I>Сильно спорно. По моему разумению основное время уходит на всякие косяки и нестыковки технологий. Скажем ORM сильно чаще является узким местом, нежели язык C#. Или тот же WCF.
Согласен. Но из этого логично следует что чем больше гибкость у языка, тем меньше времени ты тратишь на стыковку нестыкуемого. ORM вообще возникли как переходник между ограничениями языков программирования и ограничениями баз данных. И основная фишка за счёт которой они упрощают C#-код — это как раз IL-эмиттинг, postsharp-ление, либо текстовая кодогенерация. Совпадение или таки нехватка возможностей языка?
Здравствуйте, hi_octane, Вы писали:
I>>Ну это уже понятнее. Так а что входит то в эту неделю ? Ты хоть приблизительно скажи, я с целью для себя интересуюсь, а не потроллить. _>Просмотр (code review) всего закоммиченного кода, тесты у нас на симуляторе, тесты у заказчика на реальном потоке данных, с логгированием "виртуальных" ответов (реальные ответы делает текущая система). Потом анализ тех отчётов по быстродействию, которые прога собрала пока была у заказчика, ну и в заключении официальная писанина — "выложили версию такую-то, по таким-то тестам всё ок, по таким-то ок, параметры такие-то в утверждённых пределах, о чём репорты приложены, и т.п.". Что можно распаралелено, но, например, review и тесты оказалось лучше не параллелить. И самое страшное — если хоть один косяк прошёл за ревью и вылез на каких-то тестах, то всё сначала
Спасибо. Я только не понял, почему вы эту процедуру называете релизом Э
Здравствуйте, hi_octane, Вы писали:
_>4) В самом последнем проходе, те методы которые остались throw NotImplemented, например потому что ни в JavaScript ни в коде реализации для них не оказалось, намеренно превращаются в ошибки компиляции, чтобы ни один NotImplemented не попал случайно в релиз. _>Здесь и ниже по ветке есть ещё немного
, и кроме того, я уверен, хороший программист всегда найдёт способ выкрутиться. До нас эту же работу делали ацки сильные хлопцы на C++, и эту же задачу решали. #define'o'кодинг там у них был ацкий, или может ещё что, главное работало. Но на Nemerle это получилось красиво, и как-то легко.
Здравствуйте, VladD2, Вы писали:
VD>Кроме того есть специальный вид макросов — лексерные макросы. Им вместо PExpr в качестве параметра (единственоно) передается подветка дерева теокено. Такие макросы могут сами отпарсить дерево токенов, а стало быть разбирать синтаксис сильно отличающийся от синтаксиса немерла. Единственно ограничение синтаксис должен удовлетворять правилам свертки токенов.
На эти макросы я сам недавно наткнулся совершенно случайно. Еще не эксперементировал. Вот и хотел узнать, как лексер определяет границу этого самого токена.
macro @from(token : VToken)
{
// parsing token ...
}
// usingdef x = from Lorem() ipsum + 42 dolor % 3 sit {"bla bla"} amet, consectetur adipisicing elit;
def y = 1;
Как лексер понимает где кончается токен?
Извини, что назвал его парсером, после пега о лексере не думаю вообще.
Мы собираем инфу от торговых площадок, перерабатываем её, считаем аналитику, индикаторы всякие, скармливаем решателям для подбора параметров торговых стратегий, и потом всё это раздаём назад. Так что если и притянуть космос за уши, то максимум через то что в случае косяка в релизе они там стоимость спутника за секунду просадят и даже не заметят что что-то пошло не так
I>Спасибо. Я только не понял, почему вы эту процедуру называете релизом Э
Как-то исторически сложилось, что пока все эти этапы не пройдены, считается что рабочей новой версии нет. Не "rebuild all" же релизом считать. А как правильно?
