Здравствуйте, Lloyd, Вы писали:
L>Он немножко другое имел в виду: может ли он поставить брейкпоинт не в теле макроса, а на строчке в исходном коде, где он вызывается.
Здравствуйте, eao197, Вы писали:
E>Погоди, ты это сам реально проделывал?
Да. Но извратно — я в макросе поставил System.Diagnostics.Debugger.Launch()...
E>Процесс компилятора он что, постоянно в памяти висит что ли? Я так понимаю, что он запускается на весьма короткое время. Просто так не подключишься. E>Значит, нужно стартовать его под отладкой отдельно. Если так, то как узнать, в какой момент времени компилятор начнет вызывать не просто макрос Fact, а максрос Fact из нужного мне места программы, которая еще не скомпилировалась?
Этого (по крайней мере сейчас и мне) узнать не получается...
E>Или же я чего-то не помнимаю? Можно на пальцах объяснить?
Здравствуйте, eao197, Вы писали:
E>Или же я чего-то не помнимаю? Можно на пальцах объяснить?
Принцип тот же что и при отладке любой dll. В струдии прописывается путь к программе, которую нужно стартовать при отладке. В данном случае это компилятор со всеми нужными параметрами. То же самое, что при запуске юнит тестов или отладки дизайнера студии, когда нужно отлаживать саму студию.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Или же я чего-то не помнимаю? Можно на пальцах объяснить?
IT>Принцип тот же что и при отладке любой dll. В струдии прописывается путь к программе, которую нужно стартовать при отладке. В данном случае это компилятор со всеми нужными параметрами. То же самое, что при запуске юнит тестов или отладки дизайнера студии, когда нужно отлаживать саму студию.
Обалдеть.
Интересно на сколько таких отладочных сессий хватит терпения (у рядового программера) прежде чем макросы пойдут фтопку? В свое время имено из-за гемора с отладкой я перестал юзать циклы с итераторами и вещи типа for_each и перешел на классический for(int i = 0;...). Писанины не намного больше, зато хорошо видно на каких i,j,k произошел превед, и ситуацию легко снова повторить в дебаггере.
Здравствуйте, Kluev, Вы писали:
K>Интересно на сколько таких отладочных сессий хватит терпения (у рядового программера) прежде чем макросы пойдут фтопку?
Это один раз вбивается в проект dll'ки с макросами и потом всю жизнь используется. Как я уже говорил, точно так же как и с юнит тестами. А как ты думаешь писатели дизайнеров для студии живут? Отладка процессов в самой студии — обычное дело.
Впрочем, рядового программера это не будет вообще касаться.
K>В свое время имено из-за гемора с отладкой я перестал юзать циклы с итераторами и вещи типа for_each и перешел на классический for(int i = 0;...). Писанины не намного больше, зато хорошо видно на каких i,j,k произошел превед, и ситуацию легко снова повторить в дебаггере.
Никогда не испытывал проблем
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Это один раз вбивается в проект dll'ки с макросами и потом всю жизнь используется. Как я уже говорил, точно так же как и с юнит тестами. А как ты думаешь писатели дизайнеров для студии живут? Отладка процессов в самой студии — обычное дело.
Вот лично ты это дело с Nemerle в студии проделывал?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
O>И он будет работать. Не сможет скомпилить — ругнётся (причём разумно ругнётся). Сможет — прохавает.
хе, ну ты орел, ты мне приведи умножения и деления многократно номинированных/деноминированных величин.
Т.к. в дотнет невозможно инициировать генерики целыми числами, тебе придется решать эту задачу в явном виде, т.е. в параметрах типа должна храниться информация о комбинациях номинантов/деноминантов. При умножении/делении эти списки увеличиваются либо же сокращаются, причем, независимо от порядка операций, разумеется. Я немного поломал голову над этим, но не нашел иного способа как указать всевозможные комбинации для конечного числа интересующих размерностей, и с конечным "погружением" (т.е., скажем, до t^5).
Грубо говоря, надо кодировать нечто типа так:
структура простейшего типа:
public struct Val<T, N, D> { public T value; }
T — целевой тип числа,
N/D — списки типов-тагов, указывающих размерность.
//список типов
public class TypeList {
public class Node<T> : TypeList { }
}
использовать так:
TypeList.Node<T1>.Node<T2>.Node<T3>.Node...
Ну и всякие классы — таги:
public class Tags {
public class Mass {}
public class Distance {}
public class Time {}
// ...
}
сами физ-величины объявляются через using:
using velocity_int = Val<int, TypeList.Node<Tags.Distance>, TypeList.Node<Tags.Time>>;
using acceleration_double = Val<double, TypeList.Node<Tags.Distance>, TypeList.Node<Tags.Time>.Node<Tags.Time>>;
// ...
Хотя... Может быть в Nemerle и возможно будет написать кодогенератор для операций над Val<T, N, D>...
Здравствуйте, vdimas, Вы писали:
V>хе, ну ты орел, ты мне приведи умножения и деления многократно номинированных/деноминированных величин.
...
Присутствие средства для полноценного метапрограммирования сильно облегчает жизнь и помогает по другому смотреть на многие вещи. Ты, например, сейчас смотришь с позиции скалярных параметров генериков и C#. Я ничего утверждать не могу, но подозреваю, что метакод будет довольно простым, ибо сгенерить мы можем что угодно (Влад говорит, что вон даже макрос можно сгенерить в макросе).
Опять же — я попробую написать этот код (не люблю быть голословным), но не в ближайшие пару дней.
И давай умерим спесь и не будем кидаться друг в друга словечками вроде "орёл"
Здравствуйте, vdimas, Вы писали:
V>Предлагаю попробовать.
Не охота. Это чистая пенисометрия. Время убьется, а толку никакого.
V>В С++ каждая операция м/у этими типизированными величинами описывается только 1 раз. В дотнет необходимо будет описать всевозможные сочетания величин для каждой операции. Это очень большое число. Т.е., даже если автоматизировать эту задачу, и сгенерить автоматом все перестановкой, то ее решение потеряет смысл.
Макросы могут порождать новые типы. Так что реализовать эту байду точно можно. Вопрос в трудозатратах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
IT>>Принцип тот же что и при отладке любой dll. В струдии прописывается путь к программе, которую нужно стартовать при отладке. В данном случае это компилятор со всеми нужными параметрами. То же самое, что при запуске юнит тестов или отладки дизайнера студии, когда нужно отлаживать саму студию. K>Обалдеть. K>Интересно на сколько таких отладочных сессий хватит терпения (у рядового программера) прежде чем макросы пойдут фтопку? В свое время имено из-за гемора с отладкой я перестал юзать циклы с итераторами и вещи типа for_each и перешел на классический for(int i = 0;...). Писанины не намного больше, зато хорошо видно на каких i,j,k произошел превед, и ситуацию легко снова повторить в дебаггере.
Ничего особенного. После прописывания одной строчки в свойствах проекта отладка студии ничем не отличается от отладки обычного приложения. Все тот же F5 и вперед с песней.
Единственное неудобство это то что у студии нет исходиков. Но в случае с Nemerle и этой проблемы нет. Собираем компилятор с отладочной информацией и видим не только то что делает макрос но и все потроха компилятора.
Настоятельно рекомендую воздержатся от употребления падонковской лексики. Иначе в бан.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Не охота. Это чистая пенисометрия. Время убьется, а толку никакого.
Не скажи. Для меня эта задача имеет интерес, но чисто спортивный. Повод потренироваться и показать другим, что может делать Nemerle. Осталось только найти немного времени...
Ну а с точки зрения последующего использования... да, private members measuring в чистом виде.
Дарней wrote: > C>Хуже. Из VBAшного. > а приведи ка примеры, как ты это делаешь
Примерно так:
dim obj as Object
set obj = Application.ActiveChart
dim obj2 as Object
set obj2 = Aplication.ActiveSample
reactor.Process2 obj,obj2,param1,param2,param3
В реакторе происходит двойная (или тройная) диспетчеризация. Писать
таблицы уже достало.
Здравствуйте, Oyster, Вы писали:
O>Почему же? Имхо смысл есть
Смысла особого нет, так как после генерации тела макроса его нужно отдельно компилровать.
O>Я просто пробовал это сделать, и у меня как-то не получилось...
Видимо забыл о том, что макросы нужно компилировать перед использованием.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>А где написано про отладчик Nemerle, который запускается при компиляции Nemerle-кода и позволяет отлаживать раскрытие макросов и прочего?
Нда. Случай просто таки уникальный. Столько времени провести в разговорах о Немерле и не понять базовых веще.
Говорю последний раз, ибо надоело.
Макросы Немерла — это такой же код как и тот, что исполняется в рантайме. Все остальное легко выводится из этого утверждения. Нет разницы отлаживать макрос или прикладной код помещенный в DLL. Макрос — это DLL которую поднимает компилятор. Так что достаточно скомпилировать макрос в отладочном режиме и запустить компилятор из под отладчика, или банально влепить Debugging.Break()/Debug.Assert(false) и запустить компиляцию.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Если это правда, то круто!
Блин, ну, ты своими подозрениями просто убивашь на повал.
Да, мы тебя тут все развоидм. Сговорились и вешаем тебе на уши лапшу.
E>Вот только не могу понять, как же это делается...
Скачай Немерле. Скачай Сцинтилу и описанную мной поддержку для нее или Студию и поддержку для нее. Далее возьми любой из приводившихся примеров макросов. Скомпилируй его. Поставь точку останова в студии или CLR Debuger на нужной строке. Пропиши в качестве запускаемого ехе-шника ncc.exe. В качестве его командной строки файл вызвающий макрос и импорт сборки макросов (тоже описывалось не раз, хотя бы мной). Нажми F5... и вуаля.
Вместо точки останова можно влепить в коде вызов Debugger.Assert(false). Эффект будет тот же.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>Он немножко другое имел в виду: может ли он поставить брейкпоинт не в теле макроса, а на строчке в исходном коде, где он вызывается.
Тогда он полностью не умеет формулировать мысли.
Да и это вообще не вопрос. Это же просто код программы. Макрос в нем выглядит как функция или атрибут. На макросе в коде поставить точку останова нет проблем. А на атрибуте конечно нельзя, так как конструкция деларативная. Но и отлаживать там нечего. Отлаживать нужно код макроса.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
