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

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

VD>В режиме компиляции происходит тоже самое. В этом плане ничего не менялось. Разница только в том, что перезагрузку типов может происходить многократно (при изменении сборок, например).

Прошелся по коду в отладке еще раз. На самом деле компилятор вылетает и в режиме интеграции и в режиме компиляции. А типы из внешних библиотек грузятся все сразу — в методе ManagerClass.LoadExternalLibraries(). Баг проявился из за того, что не все используемые библиотеки были прописаны в референсах проекта:
MvcApplication4 содержит ссылку на библиотеку NNerdDinner.Domain, классы которой унаследованы от классов Entity Framework-а (System.Data.Entity). При этом в проекте MvcApplication4 ссылка на Entity Framework отсутствует.

Компилятор C# в такой ситуации отказывается компилировать проект, требуя явно прописать ссылки на все библиотеки. А компилятор Nemerle пытается подгружать типы из неизвестных (не прописанных в reference-ах) библиотек на лету во время компиляции. И тут типы грузятся не все сразу, а только по мере необходимости. А как я уже писал выше, алгоритм поиска типов в сборках написан в предположении, что все типы сборки уже загружены, поэтому здесь поиск лажает и классу ObjectQuery<T> в качестве базового прописывается этот же ObjectQuery<T> (вместо ObjectQuery). Эта циклическая ссылка и вызывает переполнение памяти.

Есть два варианта исправления:

— аналогично компилятору c# отказываться компилировать проект с отсутствующими сылками

— исправить логику поиска типа в сборке. (это метод LookupType класса NamespaceTree). И возможно придется допиливать не только это метод. Код работы с типам вызывает ощущение того, что он писался в до-генериковую эпоху, и поддержка генериков была прикручена позже и как видно не совсем корректно.

Какой вариант выбираем?

p.s. минимальный солюшн, демонсирирующий баг, прикреплен к описанию дефект на гуглкоде http://code.google.com/p/nemerle/issues/detail?id=1230 . Солюшн самодостаточен, независим от Entity Framework или других внешних библиотек.

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

Z>К сожалению пока нет шаблона для проекта. Так что придется скопировать NRails.Demo, поудалять оттуда...

Может, настала пора сделать шаблон проекта? Раз у твоего продукта первые пользователи появляются?

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

S>А как правильнее вывести сообщение об ошибке и прервать компиляцию? Util.ice выводит очень уж страшное сообщение с припиской "please report a bug to bugs.nemerle.org. You can try modifying program near this location.", что не очень то подходит в данном случае. А Message.Error() не прерывает компиляцию.
Может Message.FatalError?

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

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

VD>>Может сам попробуешь исправить? Если не выйдет, я завтра постараюсь поправить (сегодня голова не варит).

S>А как правильнее вывести сообщение об ошибке и прервать компиляцию? Util.ice выводит очень уж страшное сообщение с припиской "please report a bug to bugs.nemerle.org. You can try modifying program near this location.", что не очень то подходит в данном случае. А Message.Error() не прерывает компиляцию.

ice это если компилятор не может дальше работать и сам не понимает почему.

Message.FatalError(), емнип прерывает компиляцию.

Всем привет!

Решил написать Nemerle версию NerdDinner'а. В основном для себя, чтобы поближе с языком познакомиться. Если реализация будет близка к конечному результату, то можно будет и выложить для примера.

Так вот, столкнулся с проблемой — студия почему-то постоянно отжирает себе одно из 4х ядер процессора, как вовремя компиляции, так и вовремя разработки. Количество отъедаемой памяти при этом бытро растёт, пока компилятор не вываливается с OutOfMemoryException.

Что-либо делать в таких условиях реально сложно, тем более что языка то ещё толком не знаю.
Может подскажите, куда копать?

Забыл добавить описание системы.

Win7 32bit, 4gb ram, VS2008 SP1, версия nemerle: 1.0.0.8879

ММ>Всем привет!

ММ>Решил написать Nemerle версию NerdDinner'а. В основном для себя, чтобы поближе с языком познакомиться. Если реализация будет близка к конечному результату, то можно будет и выложить для примера.

ММ>Так вот, столкнулся с проблемой — студия почему-то постоянно отжирает себе одно из 4х ядер процессора, как вовремя компиляции, так и вовремя разработки. Количество отъедаемой памяти при этом бытро растёт, пока компилятор не вываливается с OutOfMemoryException.

ММ>Что-либо делать в таких условиях реально сложно, тем более что языка то ещё толком не знаю.
ММ>Может подскажите, куда копать?

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Так вот, столкнулся с проблемой — студия почему-то постоянно отжирает себе одно из 4х ядер процессора, как вовремя компиляции, так и вовремя разработки. Количество отъедаемой памяти при этом бытро растёт, пока компилятор не вываливается с OutOfMemoryException.

Ситуация воспроизводится?

Можно сформировать минимальный пример ее воспроизводящий?

Если да, то создай запись в багтрекере и добавть атачем туда свой проект (с описанием как его воспроизвести), ну, или опиши здесь.

Если я смогу воспроизвести ситуацию, то поправлю баг.

Да... багтрекер тут: http://nemerle.org/bugs/bug_report_page.php

Добавил: http://nemerle.rsdn.ru/bugs/view.php?id=1230

Проблема судя по всему в Entity Framework, который я использую для доступа к данным (через отдельный class library проект).
Как только я добавляю код, в котором есть доступ к данным через ObjectQuery, компилятор вешается.

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

VD>Да... багтрекер тут: http://nemerle.org/bugs/bug_report_page.php

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Добавил: http://nemerle.rsdn.ru/bugs/view.php?id=1230

ММ>Проблема судя по всему в Entity Framework, который я использую для доступа к данным (через отдельный class library проект).
ММ>Как только я добавляю код, в котором есть доступ к данным через ObjectQuery, компилятор вешается.

ОК. Если получится запустить приатаченый проект, то постараюсь поправить этот баг.

ЗЫ

Для доступа к данным, на мой взгляд, лучше использовать BLToolkit.

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Решил написать Nemerle версию NerdDinner'а. В основном для себя, чтобы поближе с языком познакомиться. Если реализация будет близка к конечному результату, то можно будет и выложить для примера.

Не сочти за рекламу А может сразу на nrails? Там из коробки будет работа с базой, тулкит и spark view engine. Плюс простая передача данных из контроллера во view. Плюс адресация экшенов в стиле MVC.Home.Index(). Вобщем многие вещи которыми nemerle может облегчить жизнь в ASP.NET MVC.

Ну я, в общем, только за. Задачу себе поставил написать NerdDinner — Nemerle Way. Если считаешь, что nrails можно уже назвать так назвать, то почему бы и нет.
Последний код брать отсюда, я правильно понимаю? http://code.google.com/p/nemerleonrails/source/checkout
Если есть какие-то тонкости в установке/интеграции, напиши плз, если не сложно.

Спасибо.

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

Z>Здравствуйте, Маслаков Михаил, Вы писали:

ММ>>Решил написать Nemerle версию NerdDinner'а. В основном для себя, чтобы поближе с языком познакомиться. Если реализация будет близка к конечному результату, то можно будет и выложить для примера.

Z>Не сочти за рекламу А может сразу на nrails? Там из коробки будет работа с базой, тулкит и spark view engine. Плюс простая передача данных из контроллера во view. Плюс адресация экшенов в стиле MVC.Home.Index(). Вобщем многие вещи которыми nemerle может облегчить жизнь в ASP.NET MVC.

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Ну я, в общем, только за. Задачу себе поставил написать NerdDinner — Nemerle Way. Если считаешь, что nrails можно уже назвать так назвать, то почему бы и нет.
ММ>Последний код брать отсюда, я правильно понимаю? http://code.google.com/p/nemerleonrails/source/checkout
ММ>Если есть какие-то тонкости в установке/интеграции, напиши плз, если не сложно.

К сожалению пока нет шаблона для проекта. Так что придется скопировать NRails.Demo, поудалять оттуда тестовые модели (Db это менеджер, его надо оставить) и миграции. Исправить строку подключения в web.config.

Если в качестве движка планируется использовать спарк — лучше поставить его интеграцию, хотя она будет считать, что код на C#. Можно и без интеграции, просто открывать шаблоны как html.

На этом все, можно создавать миграции для создания БД, модели, контроллеры, вьюхи.

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Если есть какие-то тонкости в установке/интеграции, напиши плз, если не сложно.

Еще тонкость, студия падает на mvc'шных вьюхах, решение тут: http://rsdn.ru/forum/prj.nemerle/3815128.1.aspx

Автор: Ziaw
Дата: 21.05.10

Так, базу сделал, миграцию запустил, база нормально создалась.
При компиляции пишет:
Doctor model error: System.Exception: table Doctor not found, env: 'Development'

Про остальные модели то же самое.

NRails.Development connectionstring точно обновил, так что с этим проблем не должно быть.

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

Z>К сожалению пока нет шаблона для проекта. Так что придется скопировать NRails.Demo, поудалять оттуда тестовые модели (Db это менеджер, его надо оставить) и миграции. Исправить строку подключения в web.config.

Z>Если в качестве движка планируется использовать спарк — лучше поставить его интеграцию, хотя она будет считать, что код на C#. Можно и без интеграции, просто открывать шаблоны как html.

Z>На этом все, можно создавать миграции для создания БД, модели, контроллеры, вьюхи.

Куда билдятся и на каком этапе временные классы для спарк вьюшек?
А то я вроде меняю модель внутри вьюхи, а простой build не перебилживает и из-за этого компайл тайм ошибка. Приходится полный rebuild делать.

Вообще, где лучше всего задавать такие нубские вопросы? Здесь в ветке или куда-то в другое место двинуть?

Z>Здравствуйте, Маслаков Михаил, Вы писали:

ММ>>Ну я, в общем, только за. Задачу себе поставил написать NerdDinner — Nemerle Way. Если считаешь, что nrails можно уже назвать так назвать, то почему бы и нет.
ММ>>Последний код брать отсюда, я правильно понимаю? http://code.google.com/p/nemerleonrails/source/checkout
ММ>>Если есть какие-то тонкости в установке/интеграции, напиши плз, если не сложно.

Z>К сожалению пока нет шаблона для проекта. Так что придется скопировать NRails.Demo, поудалять оттуда тестовые модели (Db это менеджер, его надо оставить) и миграции. Исправить строку подключения в web.config.

Z>Если в качестве движка планируется использовать спарк — лучше поставить его интеграцию, хотя она будет считать, что код на C#. Можно и без интеграции, просто открывать шаблоны как html.

Z>На этом все, можно создавать миграции для создания БД, модели, контроллеры, вьюхи.

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Так, базу сделал, миграцию запустил, база нормально создалась.
ММ>При компиляции пишет:
ММ>Doctor model error: System.Exception: table Doctor not found, env: 'Development'

ММ>Про остальные модели то же самое.

Т.е. в базе есть таблица Doctor, а компиляция не проходит? Странно, возможно кеширование схемы в интелисенс режиме. Билд при этом выдает ошибки в окне output?

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Куда билдятся и на каком этапе временные классы для спарк вьюшек?
ММ>А то я вроде меняю модель внутри вьюхи, а простой build не перебилживает и из-за этого компайл тайм ошибка. Приходится полный rebuild делать.

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

ММ>Вообще, где лучше всего задавать такие нубские вопросы? Здесь в ветке или куда-то в другое место двинуть?

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

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Вообще, где лучше всего задавать такие нубские вопросы? Здесь в ветке или куда-то в другое место двинуть?

Вообще, нрельсы еще не использовалась ни в одном проекте, я только начинаю сейчас проект на них Решай сам, интересно ли тебе быть первопроходцем. Со своей стороны обещаю исправлять все ошибки как можно быстрее.

Ёлки палки, я до самого низа докопал функционал доставания схемы. Повсюду кидал эксепшены, чтобы хоть какую-то дебаг информацию получать
Выходило, что при компиляции таблицы в схеме были, но тем не менее в Error List ошибка оставалась.
Так что ты прав, всё дело было в кеше интеллисенса. Есть какой-то способ его сбросить, не рестартуя студию?

Z>Здравствуйте, Маслаков Михаил, Вы писали:

ММ>>Так, базу сделал, миграцию запустил, база нормально создалась.
ММ>>При компиляции пишет:
ММ>>Doctor model error: System.Exception: table Doctor not found, env: 'Development'

ММ>>Про остальные модели то же самое.

Z>Т.е. в базе есть таблица Doctor, а компиляция не проходит? Странно, возможно кеширование схемы в интелисенс режиме. Билд при этом выдает ошибки в окне output?

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

Z>Здравствуйте, Маслаков Михаил, Вы писали:

ММ>>Вообще, где лучше всего задавать такие нубские вопросы? Здесь в ветке или куда-то в другое место двинуть?

Z>Вообще, нрельсы еще не использовалась ни в одном проекте, я только начинаю сейчас проект на них Решай сам, интересно ли тебе быть первопроходцем. Со своей стороны обещаю исправлять все ошибки как можно быстрее.

Нашёл первый баг. Когда генерируется тело Action через parametrizedMethod, то в конце ты не возвращаешь NRActionResult.
Поэтому вылезает ошибка в стиле 'cannot convert void to INRActionResult'.

я просто заменил:
..$parametrizedBody;
на:
..$(parametrizedBody.Append([<[ r; ]>]));

Теперь всё окей.

Z>Здравствуйте, Маслаков Михаил, Вы писали:

ММ>>Вообще, где лучше всего задавать такие нубские вопросы? Здесь в ветке или куда-то в другое место двинуть?

Z>Вообще, нрельсы еще не использовалась ни в одном проекте, я только начинаю сейчас проект на них Решай сам, интересно ли тебе быть первопроходцем. Со своей стороны обещаю исправлять все ошибки как можно быстрее.

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Нашёл первый баг. Когда генерируется тело Action через parametrizedMethod, то в конце ты не возвращаешь NRActionResult.
ММ>Поэтому вылезает ошибка в стиле 'cannot convert void to INRActionResult'.

ММ>я просто заменил:
ММ>..$parametrizedBody;
ММ>на:
ММ>..$(parametrizedBody.Append([<[ r; ]>]));

ММ>Теперь всё окей.

Ага ) Я тоже сегодня это нашел и исправил, только не комитил еще. Там еще баг, к каждому перегруженному методу генерится свой метод без параметров. Они конфликтуют. Это тоже просто лечится, но еще одна проблема уже совсем не простая, когда начинаешь активно менять экшены интеграция запускает этот макрос несколько раз, вобщем я еще не совсем разобрался чем и как это лечить.

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Ёлки палки, я до самого низа докопал функционал доставания схемы. Повсюду кидал эксепшены, чтобы хоть какую-то дебаг информацию получать
ММ>Выходило, что при компиляции таблицы в схеме были, но тем не менее в Error List ошибка оставалась.
ММ>Так что ты прав, всё дело было в кеше интеллисенса. Есть какой-то способ его сбросить, не рестартуя студию?

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

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

ММ>>Проблема судя по всему в Entity Framework, который я использую для доступа к данным (через отдельный class library проект).
ММ>>Как только я добавляю код, в котором есть доступ к данным через ObjectQuery, компилятор вешается.

Я кажется понял, в чем дело.

— В режиме интеграции компилятор загружает типы сборки не сразу, а по мере необходимости.
— Тип ObjectQuery[T] унаследован от одноименного, но не генерик типа ObjectQuery. ( class ObjectQuery<T> : ObjectQuery {} )
— Компилятор, загружая тип ObjectQuery[T] пытается обойти всех его предков.
— К моменту обработки родительского типа (ObjectQuery) компилятор уже загрузил информацию о типе ObjectQuery[T].
— Компилятор пытается найти тип ObjectQuery среди уже загруженных типов.
— На беду, поиск типа производится без учета параметров, только по имени, от которого отбрасывается символ ` и все, что расположено за ним. Если тип с подходящим именем найден и он единственный, то они и считается подходящим. (Такая логика допустима только в том случае, если к этому моменту будут загружены все типы всех сборок, а в режиме интеграции это условие не соблюдается)
— Количество параметров проверяется при поиске только в том случае, если найдено несколько одноименных типов. Более строгая проверка параметров откладывается на поздний этап. В коде по этому поводу есть коммент "incorrect number of args is reported later in a cleaner way" — это строка 377 файла NamespaceTree.n Но дело до этого более позднего этапа увы не доходит.
— Таким образом, в качестве родительского типа для ObjectQuery[T] используется информация о нем же.
— Далее компилятор натыкается в коде на конструкцию ObjectQuery[T].Where() и пытается найти объявление метода Where сначала с классе ObjectQuery[T] (безуспешно), а затем в базовом классе. А поскольку базовым считается тот же ObjectQuery[T], то компилятор уходит в бесконечный цикл, который сваливается по OutOfMemory.

Вот основной виновник торжества:

\ncc\hierarchy\NamespaceTree.n (363)

      public LookupType (split : list [string], args_count : int) : option [TypeInfo]
      {
        def search (cached) {
          | (x : TypeInfo) :: xs =>
            if (args_count == -1 || args_count == x.TyparmsCount)
              Some (x)
            else
              search (xs)
            
          | [] => None ()
        }
        
        match (TryPath (split)) {  <------- Поиск без учета args_count 
          | TypeInfoCache.Cached (tc) =>
            // incorrect number of args is reported later in a cleaner way 
            Some(tc);  <------- откладываем проверку
            
          | TypeInfoCache.NotLoaded (e) =>
            e.ConstructTypeInfo (Path (split), true);
           
            // incorrect number of args is reported later in a cleaner way 
            Some(e.tycon)  <------- откладываем проверку

          | TypeInfoCache.NotLoadedList as val =>
            def cached = Path (split).LoadValue (val);
            search (cached)
            
          | CachedAmbiguous (all) => search (all)

          | TypeInfoCache.MacroCall | TypeInfoCache.No
          | TypeInfoCache.NamespaceReference => None ()
        }
      }

Фикс я в принципе уже написал, выложу как завершу тестирование.
Юнит тест похоже тут не написать, т.к. ошибка проявляется только в режиме интеграции.

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

S>Юнит тест похоже тут не написать, т.к. ошибка проявляется только в режиме интеграции.

А вот это странно. Что в интеграции такого, что меняет поведение? Тут что-то не так.

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

VD>А вот это странно. Что в интеграции такого, что меняет поведение? Тут что-то не так.

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

Обычную компиляцию не дебажил, прошелся по исходникам глазками — в ManagerClass.Run() вызывается LoadExternalLibraries() и дальше по цепочке, пока не вызовется LibraryReferenceManager.LoadTypesFrom(lib), в которой все типы и прогружаются.

Провел эксперимент: Взял приаттаченный проект, открыл исходник, раскомментировал строку и сразу загрузка проца и памяти поползли вверх, пока не случился OutOfMemory. Закрыл окно с исходником, и тут же в студии вызвал Rebuld All — все нормально скомпилировалось.

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

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

VD>>А вот это странно. Что в интеграции такого, что меняет поведение? Тут что-то не так.

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

В режиме компиляции происходит тоже самое. В этом плане ничего не менялось. Разница только в том, что перезагрузку типов может происходить многократно (при изменении сборок, например).

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>Всем привет!

ММ>Решил написать Nemerle версию NerdDinner'а. В основном для себя, чтобы поближе с языком познакомиться. Если реализация будет близка к конечному результату, то можно будет и выложить для примера.

ММ>Так вот, столкнулся с проблемой — студия почему-то постоянно отжирает себе одно из 4х ядер процессора, как вовремя компиляции, так и вовремя разработки. Количество отъедаемой памяти при этом бытро растёт, пока компилятор не вываливается с OutOfMemoryException.

ММ>Что-либо делать в таких условиях реально сложно, тем более что языка то ещё толком не знаю.
ММ>Может подскажите, куда копать?

Еще один похожий случай, на этот раз с SQLite.NET: http://code.google.com/p/nemerle/issues/detail?id=1275

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

C>Еще один похожий случай, на этот раз с SQLite.NET: http://code.google.com/p/nemerle/issues/detail?id=1275

Эх. А как окружение воспроизвести?

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

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

C>>Еще один похожий случай, на этот раз с SQLite.NET: http://code.google.com/p/nemerle/issues/detail?id=1275

VD>Эх. А как окружение воспроизвести?

Ну, там проект в комментариях прикреплен.

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

S>Есть два варианта исправления:

S>- аналогично компилятору c# отказываться компилировать проект с отсутствующими сылками

S>- исправить логику поиска типа в сборке. (это метод LookupType класса NamespaceTree). И возможно придется допиливать не только это метод. Код работы с типам вызывает ощущение того, что он писался в до-генериковую эпоху, и поддержка генериков была прикручена позже и как видно не совсем корректно.

S>Какой вариант выбираем?

Тот что проще в реализации, т.е. видимо первый.

S>p.s. минимальный солюшн, демонсирирующий баг, прикреплен к описанию дефект на гуглкоде http://code.google.com/p/nemerle/issues/detail?id=1230 . Солюшн самодостаточен, независим от Entity Framework или других внешних библиотек.

Может сам попробуешь исправить? Если не выйдет, я завтра постараюсь поправить (сегодня голова не варит).

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

VD>Может сам попробуешь исправить? Если не выйдет, я завтра постараюсь поправить (сегодня голова не варит).
ok, попробую.

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

VD>Может сам попробуешь исправить? Если не выйдет, я завтра постараюсь поправить (сегодня голова не варит).

А как правильнее вывести сообщение об ошибке и прервать компиляцию? Util.ice выводит очень уж страшное сообщение с припиской "please report a bug to bugs.nemerle.org. You can try modifying program near this location.", что не очень то подходит в данном случае. А Message.Error() не прерывает компиляцию.

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

S>>А как правильнее вывести сообщение об ошибке и прервать компиляцию? Util.ice выводит очень уж страшное сообщение с припиской "please report a bug to bugs.nemerle.org. You can try modifying program near this location.", что не очень то подходит в данном случае. А Message.Error() не прерывает компиляцию.
WH>Может Message.FatalError?

Похоже оно )

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

S>>А как правильнее вывести сообщение об ошибке и прервать компиляцию? Util.ice выводит очень уж страшное сообщение с припиской "please report a bug to bugs.nemerle.org. You can try modifying program near this location.", что не очень то подходит в данном случае. А Message.Error() не прерывает компиляцию.

Z>ice это если компилятор не может дальше работать и сам не понимает почему.

В моем случае причина ошибки известна, и это не внутренняя ошибка компилятора, а ошибка во внешнем файле проекта. Поэтому тут имхо ice
(internal compiler error) не очень подходит.

Z>Message.FatalError(), емнип прерывает компиляцию.
ага, точно!

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

S>>- аналогично компилятору c# отказываться компилировать проект с отсутствующими сылками

S>>- исправить логику поиска типа в сборке. (это метод LookupType класса NamespaceTree). И возможно придется допиливать не только это метод. Код работы с типам вызывает ощущение того, что он писался в до-генериковую эпоху, и поддержка генериков была прикручена позже и как видно не совсем корректно.

S>>Какой вариант выбираем?

У тебя получилось, что компилятор теперь орет не только на использование типа из сборки которая не подключена, а на то, что не подключены сборки на которые хоть как-то (даже опосредовано) ссылаются зависимые сборки. В результате компилятор орет на полную фигню. Даже если тип никогда и ни где не используется, компилятор требует явно подключить ВСЕ зависимые сборки.

Это просто ужасно! В солюшене из тройки проектов уже просто невозможно работать.

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

VD>У тебя получилось, что компилятор теперь орет не только на использование типа из сборки которая не подключена, а на то, что не подключены сборки на которые хоть как-то (даже опосредовано) ссылаются зависимые сборки. В результате компилятор орет на полную фигню. Даже если тип никогда и ни где не используется, компилятор требует явно подключить ВСЕ зависимые сборки.

VD>Это просто ужасно! В солюшене из тройки проектов уже просто невозможно работать.

Приведи плиз пример. Я проверил пару сценариев и пока компилятор работает аналогично компилятору шарпа.

К примеру, создаю прокта, содержащий ссылку на System.Data.SqlServerCe и не содержащий ссылку на System.Data. В проекте создаю код, испльзующий SqlCeEngine (уникальный для этой сборки класс, не унаследованный от классов внешних сборок), код успешно компилируется и шарпом и немерле. Затем добавляю в проект код, испльзующий SqlCeCommand (унаследованный от DbCommand из неподцепленной сборки System.Data) и оба копилятора начинают ругаться на отсутствие сборки.

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

S>Приведи плиз пример. Я проверил пару сценариев и пока компилятор работает аналогично компилятору шарпа.

Ситуация была такая.

Есть проект в котором делается реализация интерфейса. Сам интерфейс описан в другом проекте (но это видимо не важно).

Так вот при реализации интерфейса человек оставляет публичный метод который содержит параметр с типом из другой сборки.
Далее в другом проекте создается тип реализующий интерфейс и сразу же приводится к интервейсу. Но появляется это сообщение (плюс еще меседжбокс) и ничего не работает.

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

VD>Так вот при реализации интерфейса человек оставляет публичный метод который содержит параметр с типом из другой сборки.
VD>Далее в другом проекте создается тип реализующий интерфейс и сразу же приводится к интервейсу. Но появляется это сообщение (плюс еще меседжбокс) и ничего не работает.

Попробую воспроизвести на обоих компиляторах. А вот с меседжбоксом странно — у меня он еще ни разу не выскочил.

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

VD>Ситуация была такая.

VD>Есть проект в котором делается реализация интерфейса. Сам интерфейс описан в другом проекте (но это видимо не важно).

VD>Так вот при реализации интерфейса человек оставляет публичный метод который содержит параметр с типом из другой сборки.
VD>Далее в другом проекте создается тип реализующий интерфейс и сразу же приводится к интервейсу. Но появляется это сообщение (плюс еще меседжбокс) и ничего не работает.

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

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

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

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

S>Попробую воспроизвести на обоих компиляторах. А вот с меседжбоксом странно — у меня он еще ни разу не выскочил.

Он появляется именно когда есть это сообщение и работаешь под IDE. Но это как раз ясно почему. Ты используешь FatalError, а это приводит к генерации исключения. На такой ранней стадии интеграция видимо не ожидает его и это приводит к появлению окна.

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

S>Воспроизвел. Компилятор немерле инициализирует список методов класса неленивым образом. Когда ты создаешь объект, то компилятор ищет конструктор типа, для чего поднимает все методы класса, сохраняя в своих внутренних структурах типы входных и выходных параметров. Поэтому даже если в коде и нет прямого обращения к проблемному методу, компилятор все таки до него добирается. И тут не поможет даже ленивая загрузка методов, потому что полный список методов может потребоваться для интеллисенса.

Да, похоже на то... К со жалению.

S>В аналогичной ситуации компилятор шарпа позволяет компилировать проект, если он не содержит явных вызовов проблемных методов. Проблемный метод и его сигнатура также успешно отображаются в списке интелисенса.

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

Откатывать не надо. Жить можно. Просто, конечно, в таком виде нельзя делать инсталлятор (а надо бы). Так что если можно не затягивай с исправлением. В проекте Н2 я уже обошел проблему сделав все "проблемные" методы интерналом.

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

S>В аналогичной ситуации компилятор шарпа позволяет компилировать проект, если он не содержит явных вызовов проблемных методов. Проблемный метод и его сигнатура также успешно отображаются в списке интелисенса.

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

А может в таких случаях создавать некие заглушки? Ну, чтобы загрузка не поперла рекурсивно. Если к этой заглушке будет реальное обращение, пусть генерирует ошибку.

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

VD>А может в таких случаях создавать некие заглушки? Ну, чтобы загрузка не поперла рекурсивно. Если к этой заглушке будет реальное обращение, пусть генерирует ошибку.

Я пока не понял, как внури этой заглушки понять с какой целью идет обращение к свойствам — компилируется ли реальное обращение или отображается список интелисенса.

Пофиксил баг исправив поиск типов и динамическую их погрузку из неподключенной сборки. Залил исправления в отдельный бранч — http://code.google.com/p/nemerle/source/detail?r=9533

Пока фиксил динамическую загрузку, нашел место, в котором можно безболезненно прогрузить всю неподключенную сборку. Поскольку для полностью загруженной сборки поиск типов работает в исходном виде, то изменения при таком способе исправления минимальны. Этот способ залил в другой бренч — http://code.google.com/p/nemerle/source/detail?r=9534

Первый вариант побыстрее, т.к. типы загружаются только по мере необходимости. Второй — безопаснее, т.к. требует минимальных изменений. Наверное на стадии релиз-кандидата стоит остановиться на втором варианте?

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

S>Пока фиксил динамическую загрузку, нашел место, в котором можно безболезненно прогрузить всю неподключенную сборку. Поскольку для полностью загруженной сборки поиск типов работает в исходном виде, то изменения при таком способе исправления минимальны. Этот способ залил в другой бренч — http://code.google.com/p/nemerle/source/detail?r=9534

S>Первый вариант побыстрее, т.к. типы загружаются только по мере необходимости. Второй — безопаснее, т.к. требует минимальных изменений. Наверное на стадии релиз-кандидата стоит остановиться на втором варианте?

Да. Чем проще изменения, тем больше надежды на стабильность работы. Правильно "фиксить" будем уже во второй версии. Главное поминить о проблеме.

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

S>Первый вариант побыстрее, т.к. типы загружаются только по мере необходимости. Второй — безопаснее, т.к. требует минимальных изменений. Наверное на стадии релиз-кандидата стоит остановиться на втором варианте?

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

Но это не так просто.