Oyster wrote:
> C>reactor.Process2 obj,obj2,param1,param2,param3
> Кстати, на C# тоже без проблем можно сделать так, чтобы для вызывающей
> стороны вызов мультиметода был абсолютно прозрачным...
И выглядеть будет изоморфно коду моей реализации.

Oyster wrote:
> C>Вот с этим и проблемы. .NET претендует на универсальную платформу, а
> C>полноценный интероп обеспечивает только в своих языках.
> Есть CLS. Хочешь стать "своим" — соответствуй CLS.
Вот только букву "C" в CLS следует читать как "C#".

> C>Стандарт может быть совершенно отдельным. Но он все равно нужен.
> Дык и начинай активные действия в этом направлении
Нафиг. CLR мне не дает практически никаких дополнительных преимуществ в
интеропе кроме общего GC по сравнению со старым добрым COM.

Дарней wrote:
>> > такой же диспатч под CLI делается без проблем и намного проще
> C>В чистом С++ оно тоже делается намного проще. Но нужен именно VBA.
> а что, по твоему "чистый С++" эквивалентно CLI по возможностям интеропа?
Примерно. В .NET большим преимуществом является только общий GC.

Здравствуйте, Cyberax, Вы писали:

C>Примерно. В .NET большим преимуществом является только общий GC.

если забыть про проблемы с классами, исключениями, массивами и строками, то ты совершенно прав Есть еще конечно проблема с написанием оберток, но эта мелочь даже не заслуживает внимания

Здравствуйте, Kluev, Вы писали:

VD>>Нескажу за рядовых, но если человек хоть раз отлаживал DLL-сборку или просто Win-DLL, то проблем не возникает вообще.
K>Просто потом это надоедает
Что надоедает? Ты вобще хоть раз DLL отлаживал?

K>и начинаешь юзать более простые вещи.
Какие?

Здравствуйте, IT, Вы писали:

IT>ЗЫ. Мне, кстати, тоже интересно, доколе народ будет заниматься охотой на ведьм? Я так понимаю, что удовольствие получается уже от самого процесса

Точно.

Возможно это такой вид аутотренинга. Веловек ищет себе причины почему это ему не нужно.

Здравствуйте, eao197, Вы писали:

>> Да, лучше перестраховаться и объявить Nemerle и его создателей врагами
>> народа, дизертирами и вредителями колхозных колосков.

E>Можешь показать цитаты, хотя бы близкие по смыслу к этому?

Прийдется показать всю твою переписку на этом форуме за исключением тех мест где ты хвалил Руби или защищал С++.

>> ЗЫ. Мне, кстати, тоже интересно, доколе народ будет заниматься охотой на
>> ведьм? Я так понимаю, что удовольствие получается уже от самого процесса
>>

E>А вот я применительно к отладке макросов во время компиляции другого не понимаю.

Хм. Осмысленный ответ на замечание ИТ.

E> Почему этого нельзя сделать путем установки точки прерывания в IDE на месте обращения к макросу в моем коде?

Опиши, пожалуйста, сценарий того как будет отрабатвать этота точка останова. Причем как можно подоробнее.

E>Ну а если чуть-чуть подумать. Преставим, что в IDE на строке своего исходника я устанавливаю точку прерывания. Запускаю компиляцию, IDE подгружает внутри себя процесс компилятора и передает ему дополнительную информацию: имя файла и номер строки с точкой прерывания. Когда компилятор доходит до этого места в процессе компиляции, он сообщает IDE об этом и позволяет IDE войти в режим отладки.

Для этого не нужно изменять комилятор. Достаточно просто создать еще один отладочный макрос который будет взводить некий флаг:

macro BreakMyCacro()
{
    Debug._dbgFlag = true;
}

module Debug
{
  intrnal bool _dbgFlag;
}

Далее в макросе написать нечто вроде:

macro MyCacro()
{
    if (Debug._dbgFlag)
    {
        _dbgFlag = false;
    }
    ...

и поставить точку останова внутрь if-а. Далее остается вписать вызов BreakMyCacro() в нужном месте объектного кода (перед не верно работающим вызовом MyCacro).

E>Компонентная, в конце-концов .NET среда или так просто, погулять вышла?

Ты тут придерашся по мелочам к Немерлу в то время как к Руби вообще нормальной ИДЕ нет. Поддержки IDE вообще очень нехватает. И уж если говорить о первоочередных фичах, то сначало нужно кмплит-ворд сделать. А такие изысканные извращения как точки отсанова времени компиляции точно можно пережит.

E> Компилятор может быть таким компонентом, который IDE подгружает в себя. IDE получает от компилятора интерфейс для управления компиляцией.

Да, в общем-то достаточно даже передать компилятору имя файла и позицию в нем. Возможно когда-то так и сделают. Только и биз этого особых проблем нет.

Так что это очередной пример охоты на ведьм. Попытка найти соринку в чежом глазу не видя бревна в собственной заднице.

E> IDE передает компилятору свой callback интерфейс. IDE дергает метод компилятора для начала компиляции с перечислением точек прерываний. Когда компилятор добирается до одной из них, он дергает callback интерфейс IDE и говорит, где и как нужно начать отладку.

Вот только незадача. Точка останова получается в прикладном коде, а ходить можно будет только по метакоду. У многих может поехать крыша.

E>Получается нормальная IDE для полноценного использования и отладки средств метапрограммирования Nemerle.

Возможно. Более того. Я тебе еще 200 фич могу напридумывать в области поддержки IDE и вообще. Но как ты понимашь, сейчас поддержка IDE вообще на уровне плинтуса (есть только подсветка кода, управление проектом и отладка). Так что кул-фичах пока что мечтать не приходится.

Кстати, из кул-фич IDE в области макросов мне бы очень хотелось бы видеть следующее:
1. При наведении курсора мыши на имя макроса (внутри выражения), чтобы о IDE показывала большой хинт с раскрытым кодом макроса. И чтобы каждый вложенный макрос был подсвечен и при наведении мышки на него чтобы можно было увидить как раскроется он.
2. При отладке чтобы можно было нажать некую пимпочку (например, выбрать пункт контекстного меню когда курсор установлен на макросе) и чтобы в редакторе появился раскрытый код макроса. При этом должно быть возможно поставить точку останова на одной из строк сгенерированной макросом.

Вот это действительно силно упростило бы разработку макросов.


E>Или такое все же принципиально невозможно?

Принципиально, возможно. Но приципиально такое возможно и без супер IDE. А нет этого потому, что нет супер IDE. Ты же спрашивал о возможностях отладки. Тебе о них и говорили.

E>

---

E>AFAIK, IDE для Smalltalk-а давно так работают. Чуть ли не с рождения.

Ага. Только вот меня от Смолтоковских IDE тошнит. Все что я видил ужасно неудобно.

Здравствуйте, eao197, Вы писали:

Д>>если очень хочется — возьми и сделай, благо исходники доступны

E>Я вот одного не пойму -- то о чем я написал для Nemerle принципиально не нужно?

Не принципиально. Но необходимости явно нет. Пока что я не испытывал проблем с отладкой макросов. Имеющихся средств достаточно.

Здравствуйте, Дарней, Вы писали:

Д>В С++ вообще никакой отладки для хитрых рекурсивных шаблонов нет, даже трассировки. И ничего, живут же люди. Или тебе просто раздуть очередного слона из мухи?

Вот именно! Мне вооще нравится ход дисскусси.
Оппонент:
— В С++ вообще нет средств отладки.
— Ага. А единственное средство отладки макросов Немерла — это печать в косоль!...
— Позвольте, макрос тот же код и его можно отлаживать просто отладчиком.
— А как же начать отладку?
— Поставить точку останова в макросе или влепить в код ассерт.
— (даже не пробуя) Это не удобно!!! Убого!!!...
— Да все ОК.
— Неужели IDE не может упростить отладку?
— Может. Но ее нет.
— А вот Смолтоке.

В общем, поиск фатальных недостатков.

Вывод просто потрясающий. Немерле это хреново, так как нет супер-кул-фич вроде точек останова времени компиляции. То ли дело Смолток. Так что будем пока что использовать С++ в котром вообще невозможна отладка метакода и Руби для которого вообще отладчика нет.

Изумительно!

Здравствуйте, Kluev, Вы писали:

K>Просто потом это надоедает и начинаешь юзать более простые вещи.

Нет. Все с точностью до наоборот. Когда надоедает юзать "простые вещи" человек обращается к макросам. Так как они способны один раз сложным образом решить проблему устранив необходимость раз за разом юзать просые вещи.

K>А через for трудно?
K>

K>// связный список. код из реального проекта
K>    FB_Curve *c, *c2;

K>// split poly-curves if need:
K>    for ( c = curves.first(); c; c = c2 )
K>    {
K>        c2 = curves.next(c);
        c->>split(); // может добавить элементы в список поэтому сначала делаем next()
K>    }

K>// tess
K>    for ( c = curves.first(); c; c = curves.next(c) )
        c->>tess();
K>

Сравни:

foreach (item in collection)
  DoWork(item);

причем вместо collection может выступать массив, коллекция, хэш-таблица, связанный список... в общем, что угодно допускющее перебор. Код всегда будет единым, понятным и кратким.

У тебя же будет каша. И это только в простом случае с foreach. А таких случаев масса. В итоге твой код бует похож на мусорную яму, а мой понятен и прост настолкь насколько это возможно.

K>Хэш таблица — аналогично, только там массив списков, не вижу никаких трудностей.

Что аналогично? Я ете показал пример кода который будет един для любого типа коллекций. С for код будет разный и громоздкий.

Неужели тут еще что-то нужно объяснять?

K> Кому трудно может написать макрос для среды который заготовки циклов в редактор вставляет. Хотя мне и руками не трудно написать, на обдумывание все равно времени гораздо больше уходит.

Ну, конечно! Как я забыл. Главно ведь по быстрее надоблить код. А там хоть трава не расти.

VD>>А зачем видить внутреннюю реализацию паттерна? Мне достаточно видеть то, что код перебирает элементы коллекции. Остальное не важно.

K>А мне важно знать номер итерации на которой произошла ошибка

Зачем? А если элементы изменят порядок? Например, в хэш-таблице порядок не детерминирован.

K>(или ID обьекта, если он есть), циклы большие обьем входных данных тоже не мальнький, а корректность никто не гарантирует. Как отлаживатся то?

Твои фобии может и имели бы смысл если бы на C# или Nemerlr было бы сложнее олаживаться чем на С++. Но все как раз наоборот. foreach не только не мешают отладке, но и упрощают ее. Ты просто гарантированно не ошибелся с индексом используя foreach. А значит и отлаживать будет нечго. Если же при переборе возникла ошибка, то она целиком и полностью зависит от состояния в этом есте и ее не трудно воспроизвести по этому состоянию.

Ну, и в конце концов никто не мешает вставить в код временный отдалчный индекс.

K>В каждый обьект уникальный ID пихать?

Каждый объект и так должен быть уникален или одинаковые объекты не должны различаться вообще. Обратное практически на 100% является ошибкой.

Короче, приведи пример и я его прокоментирую.

Здравствуйте, Cyberax, Вы писали:

C>Iron.Python (как и Jython до этого) пытается производить вывод типов,
C>в тех случаях когда это удается — вставляет готовый IL. В остальных
C>случаях использует интерпретатор.

Так проблема в том, что сам язык не очень подходит для вывода типов. Отсюда и трудности. Проще сразу ввести в язык нужные ограничения. Тогда вывод типов из шаманста становится четким алгоритмом.

А так первый же ввод/вывод и ты приплыл. Ведь никто не знает, что ты там введешь строку или число.

Изменение типов во время работы тоже приводит к проблемам. Ну, добавить метод еще моно, а удалить или изменить что-то в классе — это уже приплызд.

Здравствуйте, FR, Вы писали:

FR>Пусть так но мне хочется понять насколько велики возможности немерли. Просто если реализация очень сложна то практически можно сказать что этой возможности нет.

Что значит очень? Она достаточно сложна, чтобы не заниматься ею ради пенисометрии. Будет надо — сделаю.

Здравствуйте, eao197, Вы писали:

E>Ну-ну. Работает и пусть работает. Ты мне еще расскажи, что статическая типизация на 99% устраняет необходимость тестирования приложений. Что после успешной компиляции нужно проверить всего две вещи -- что программа успешно стартует и столь же успешно завершается. Если эти условия выполняются, значит все работает корректно.
Ты можешь не верить но когда я пишу на C# все примерно так и происходит. Я могу несколько дней долбить код без компиляции. После компиляции (как правило все компилируется сразу ибо ReSharper рулит) и устранении пары исключений (причем на C#2 и этого скорей всего не понадобится ибо генерики) все действительно работает как надо.
Чего не скажешь про С++ в котором наведенку можно ловить произвольное колличество времени.

E>Я просто хотел понять, что делать в случае, когда я вижу, что некий макрос, производящий compile-time вычисления подставляет мне в код явно не правильную константу. Причем делает это он не всегда, а один раз в некотором месте исходного кода.
Теоритически это возможно. Просто этим никто не занимался в виду того что эта возможность мягко говоря мало актуальна.
В данном случае гораздо проще создать маленькую программу и на ней отлаживатся.
Я тебе больше скажу я так отлаживал куски здорового сервера приложений. Поднимать эту дуру которая стартует черт знает сколько ради того чтобы отладить маленький кусочек у меня небыло никакого жилания. Вот я и написал маленькое консольное приложение которое цепляет только то что нужно и стартует доли секунды.

E>Я не понимал, как войти в отладку кода макроса, когда этот код работает в отдельном параллельном процессе ncc. Оказалось, что провоцируется отладка процесса компилятора путем подстановки в код макроса специальных провоцирующих отладку инструкций (вроде Assert(false)). После этого стало понятно. Напомнило, как некоторые товарищи в C/C++ код вставляли asm { int 3h; } (вроде так).
Тебе уже раз 10 сказали что это один из способов причем не самый удобный.

E>Только для этого способа, как я понимаю, нужно иметь компилируемый исходный код макроса чтобы вставить в него Assert(false) и перекомпилироваться.
А что ты без исходного кода отлаживать то будешь? Я конечно понимаю что можно отлаживать и исполняемый код... я и сам этим занимался но это такой геморой что лучше с этим не связываться.

Здравствуйте, Cyberax, Вы писали:

C>Вот только букву "C" в CLS следует читать как "C#".

Я не спорю с тем фактом, что C# позиционировался как основной язык для платформы .NET. Тем не менее, я бы не сказал, что CLS делали с оглядкой только на него. Например, сам MS также поддерживает VB.NET и C++/CLI — в них, кстати, есть фичи, отсутствующие в C#. Опять же, есть другие замечательные языки — вроде Nemerle — которые также следуют спеке CLS, но, тем не менее, предоставляют свои (и очень удобные) фичи.

C>Нафиг. CLR мне не дает практически никаких дополнительных преимуществ в
C>интеропе кроме общего GC по сравнению со старым добрым COM.

Тогда зачем разговор о CLR ведёшь вообще?

Здравствуйте, Cyberax, Вы писали:

C>И выглядеть будет изоморфно коду моей реализации.

Pre-condition: Твой код я не видел и, пока не увижу, не могу его обсуждать.

Это будет код на C# — он не будет точно таким же, но будет решать ту же задачу. Или тебе тупо важна та же реализация вплоть до точки с запятой?

Ну и интерфейс у метода можно сделать такой же, как тот, что видит VBA, естественно (а что ещё нужно вызывающей стороне?...):

void Process(object obj1, object obj2, [собственно параметры метода])
{
    //...
}

Дальше в реализации на .NET есть как минимум три варианта:

1. Тупые if по типу и вызов нужного метода внутри. Так писать неудобно и никто, естественно, как правило так не пишет.
   
2. Декларативное описание реализации для данных двух типов. Тут атрибуты и reflection, так что всё в рантайме. Зато никакого хардкодинга и максималоно упрощено добавление новой реализации.
   
3. То же, что и в п.2, но без reflection в рантайме — этот этап перенесён в compile-time. Тут можно использовать Nemerle и тоже всё будет пучком. Кстати, я думаю что тут хватит и сопоставления по образцу.

Для примеру вот простенькая реализация такого метода на Nemerle с использованием pattern-matching:

using System;
using System.Console;

public module Worker
{
    public Process(obj1 : object, obj2 : object, n : int) : void
    {
        match ((obj1, obj2)) {
            | (_ is int, _ is string) => WriteLine($"For int and string n = $n")
            | (_ is double, _ is string) => WriteLine($"For double and string n = $n")
            | (_ is string, _ is DateTime) => WriteLine($"For string and DateTime n = $n")
        }
    }
}

Worker.Process(1, "a", 2);
Worker.Process(1.1, "a", 3);
Worker.Process("a", DateTime.Now, 4);

Такой код выведет в консоль:

For int and string n = 2
For double and string n = 3
For string and DateTime n = 4

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Kluev, Вы писали:

VD>>>Нескажу за рядовых, но если человек хоть раз отлаживал DLL-сборку или просто Win-DLL, то проблем не возникает вообще.
K>>Просто потом это надоедает
WH>Что надоедает? Ты вобще хоть раз DLL отлаживал?

Неоднократно.

K>>и начинаешь юзать более простые вещи.
WH>Какие?

Обычные средства ООП, без метапрограммирования, написания собственных DSL и т.п.
Простые и хорошо обкатанные вещи не требуют танцев с бубном, и позволяют писать достаточно быстро и эфективно. т.к. все ходы и сайд эффекты хорошо изучены.

Дарней wrote:
> C>Примерно. В .NET большим преимуществом является только общий GC.
> если забыть про проблемы с классами, исключениями, массивами и строками,
> то ты совершенно прав Есть еще конечно проблема с написанием оберток, но
> эта мелочь даже не заслуживает внимания
Классы — элементарно заменяются COM-интерфейсами. Массивы, строки —
SAFEARRAY, BSTR. Исключения — HRESULT+IErrorInfo.

Единственное чего нет — это атрибуты и GC.

Здравствуйте, Cyberax, Вы писали:

C>Классы — элементарно заменяются COM-интерфейсами. Массивы, строки —
C>SAFEARRAY, BSTR. Исключения — HRESULT+IErrorInfo.

плавали, знаем, что это за трах. Рядом с CLI даже и близко не валялось.
Вот и превратилась вся твоя крутейшая C++ интероперабельность в один сплошной COM.

Здравствуйте, VladD2, Вы писали:

VD>Сравни:
VD>

VD>foreach (item in collection)
VD>  DoWork(item);
VD>

VD>причем вместо collection может выступать массив, коллекция, хэш-таблица, связанный список... в общем, что угодно допускющее перебор. Код всегда будет единым, понятным и кратким.

А если в цикле в этот же контейнер элементы добавляются/удаляются? Или нужна пара или тройка соседних элементов. К примеру есть массив точек и хотим посчитать длины сегментов. Для этого нужен i и i+1 элемент. Если углы то i-1,i,i+1. foreach подходит отнюдь не везде, а написать for у меня нет трудностей.

VD>У тебя же будет каша. И это только в простом случае с foreach. А таких случаев масса. В итоге твой код бует похож на мусорную яму, а мой понятен и прост настолкь насколько это возможно.

Давай с помощью forach ты напишешь простой и понятный код который вычисляет разность между соседними точками в массиве.

VD>Твои фобии может и имели бы смысл если бы на C# или Nemerlr было бы сложнее олаживаться чем на С++. Но все как раз наоборот. foreach не только не мешают отладке, но и упрощают ее. Ты просто гарантированно не ошибелся с индексом используя foreach. А значит и отлаживать будет нечго. Если же при переборе возникла ошибка, то она целиком и полностью зависит от состояния в этом есте и ее не трудно воспроизвести по этому состоянию.

Давай без наездов. Пример из жизни: на 1024 итерации программа падает потому, что имеет место быть самопрересечение поверхности. Что мне даст контекст? вообщем-то ничего, т.к. контекст будет находится в тех подпрограммах которые были вызваны из главного цикла. Не зная номера или индекса отлаживатся будет песня. Плавали знаем. поэтому я никогда не связываюсь с вещами типа forach, себе дороже.

VD>Каждый объект и так должен быть уникален или одинаковые объекты не должны различаться вообще. Обратное практически на 100% является ошибкой.

И что мне от этой уникальности? Если это к примеру точка из трех даблов то мне как условие в брейкпоинте ставить? p.x == 3.1414534546576576 && p.y == 5656.7878799898989 давай не будем смешить людей. i == 123 гораздо проще и лучше.

.

Здравствуйте, VladD2, Вы писали:

E>>Можешь показать цитаты, хотя бы близкие по смыслу к этому?

VD>Прийдется показать всю твою переписку на этом форуме за исключением тех мест где ты хвалил Руби или защищал С++.

А ты все же поищи. Может и найдешь. А то ведь придумывать придется.

E>> Почему этого нельзя сделать путем установки точки прерывания в IDE на месте обращения к макросу в моем коде?

VD>Опиши, пожалуйста, сценарий того как будет отрабатвать этота точка останова. Причем как можно подоробнее.

У меня сложилось впечатление, что ты увидел мой пост, сразу начал отвечать не него поабзацно, не прочитав всего сообщения целиком.

VD>Для этого не нужно изменять комилятор. Достаточно просто создать еще один отладочный макрос который будет взводить некий флаг:
VD>и поставить точку останова внутрь if-а. Далее остается вписать вызов BreakMyCacro() в нужном месте объектного кода (перед не верно работающим вызовом MyCacro).

И тебе кажется, что это не костыли?