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

C>VladD2 wrote:
>> Неотносящаяся к делу фигня поскипана.
C>???

>> Где здесь говорится о том, что ХотСпот делает спекулятивный инлайнинг?
C>http://java.sun.com/products/hotspot/docs/general/hs2.html
C>

C>The Java HotSpot dynamic compiler uses runtime analysis to perform
C>inlining aggressively, yet safely. Once the Java HotSpot profiler
C>has collected runtime information about program hot spots, it not only
C>compiles the hot spot into native code, but performs extensive method
C>inlining on that code. The Java HotSpot compiler can afford to be
C>aggressive in the way it inlines because it can always back out an
C>inlining optimization if it determines that the method inheritance
C>structure has changed during runtime due to dynamic class loading.
C>...
C>
C>Furthermore, method inlining is synergistic with other optimizations.
C>Inlining produces large blocks of code which make additional
C>optimizations easier for the compiler to perform. The ability of the
C>Java HotSpot Server VM to do aggressive inlining is a key factor in
C>making HotSpot faster than current JIT and static compilers.
C>

C>Что, мне из исходников JVM цитаты приводить?

Ты читай внимательно. Там везде слова "возможно", "может быть"...

>> C>Мне не сэмплы нужны. Нужно реальное приложение, с сильным использованием
>> C>макросов.
>> Вот компилятор и есть такое приложение. Он сам на себе создается и
>> использует море макросов.
C>Компилятор языка прикладным приложением не является по определению.

А как его по-твоему назад?

И вообще, тебе нужно на код поглядеть или порассуждать об этимологии слов?
То есть, тебе "шашечки" или ехать?

>> C>Ну вот, билд-система eao197 для С++ намного удобнее ant'а. Сейчас,
>> C>правда, я пользуюсь Boost.Build v2, которая еще удобнее.
>> Серьезно? А ведь "билд-система eao197 для С++ намного удобнее ant'а"!
C>Вы понимаете, операция сравнения транзитивна.

Ну, то есть все же "билд-система eao197 для С++" реально не нужна?

>> Вообще забавный разговор выходит. Мэйк форевар, мэйк крут. Но один
>> велосипед на тему мэйка изобретает, а другой испльзует нестандарткую
>> приблуду из библиотеки.
C>Кстати, make пока по скорости еще никто не превзошел. Так что он в своем
C>роде лучший.

По чему? По скорости? Это изумительная характеристика для утилиты жапускающей другие экзешники. Да и глупость это, так как запуск процесса это еще те тормоза. А уж компилятора и подавно. Те же Ант и МСБилд умеют занружать утилиты как объекты и кешировать их.

C>А насчет "приблуды из библиотеки" — посмотрите хоть на BBv2.

Меня на 100% устраивает связка MSBuild + VS2005.
Зачем мне снова в каменный век?

C>ЗЫ: а если бы никто не изобретал велосипедов, то Ant'а сейчас не было бы...

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

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

V>А мне не очень нравится . Сам дотнет не поддерживает функциональные типы как первоклассные значения. Делегаты — это адаптер, но не представляет из себя функциональный тип. (т.е. создать экземпляр делегата — не значит создать экземпляр ф-ии).

Ошибочное мнение навеянное мышлением в фунциональном стиле. Вункцию нельзя создать. Вункция — это ее код (т.е. выражения).
Манипуляции функциями в ФЯ — это редставление для программиста. На самом деле компилятор обязан использовать некоторую технику. Вариантов тут не много. Или переписывание кода, или создание неких объектов инкамсулирующих нужные данные (в том числе ссылки на функции).

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

V>Более того, ситуация, при которой делегаты разного типа, но имеющие одинаковую сигнатуру Invoke не совместимы — это вообще нонсенс на уровне грубой ошибки проектирования (!!!). Пусть устранят эти баги, тогда функциональная часть программисткого направления станет более естественной для дотнета, и Nemerle в т.ч.

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

V>--------
V>Говорю неспроста. У самого есть черновик интерпретатора Схемы под дотнет, и исследовал более десятка вариантов имплементаций Схемы/Лиспа под Яву и дотнет. В общем, кое-какие ограничения не позволяют делать результирующий код достаточно эффективным.

Ага. Ограничения времени и мозга.
Физических ограничений нет. Погляди как делается в Немерле и в C# 3.0. Ну, а переписывание кода и инлайнинг вообще решают массу проблем.

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

E>>Это кто такое про make сказал?

VD>Напомню фразу породившую эту ветку:
VD>

C>А зачем нужен был ant, когда был make?

Ну и где здесь было сказано, что make крут и make forever?

На момент появления ant был make. Был давно и был успешно. Для него (make) было много документации, примеров использования, приблуд разных и пр. Короче, это был на 100% стандарт de-facto. А на Unix-ах в среде C-разработчиков таким и остается.

Да вот только кому-то показалось, что не так уж все хорошо и удобно с make, как хотелось бы. Думаю, что казалось так многим, но не многие пытались это дело изменить (ну еще бы, против стандарта-то идем). И не у многих, кто взялся, реально успешные результаты получились. Вот и разработчиков ant получилось.

Теперь что мы имеем с ant. Он есть давно и есть успешно. Для него (ant) много документации, примеров использования, приблуд разных и пр. Короче, на 100% стандарт de-facto... Но, стандарт для Java community. Т.к. создавался на Java и для Java.

Соответственно, кому-то показалось, что это не так уж хорошо и удобно. И некоторые попытались это дело изменить. MS, к примеру.

Так что на примере make и ant я пытался показать тебе, что новое начинает создаваться там, что существующий инструмент кого-то очень сильно не устроил. Меня не устраивал make (как и разработчиков ant) и не утраивал ant для C++ проектов. Поэтому появился mxx_ru.

Разработчиков Scala что-то в Java не устраивало. Разработчиков Nemerle так же что-то не устраивало, поэтому они свой инструмент и сделали. Хотя, я думаю, многие Lisp-оведы спросят, а нафига Nemerle со своими маросами нужен-то был?
Затем в Nemerle кого-то что-то еще не устроит. И появится что-то другое.

Это нормальный процесс развития. Для того, чтобы этот процесс шел нужно, чтобы появлялось много нового. 99% этого, вероятно, вообще не выживет, зато оставшийся 1% сделает шаг в перед. Если mxx_ru не выживет, значит судьба такая. По крайней мере затраты на свое появление и развитие он уже оправдал.

Да и не факт, что Nemerle выживет. Но затраты на свое появление, имхо, он уже оправдал.

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

V>>У самого есть черновик интерпретатора Схемы под дотнет, и исследовал более десятка вариантов имплементаций Схемы/Лиспа под Яву и дотнет. В общем, кое-какие ограничения не позволяют делать результирующий код достаточно эффективным.

VD>Ага. Ограничения времени и мозга.

При реализации интерпретатора Схемы невозможно использовать value-типы, ну никак. Ломал голову — так и не придумал. Большинство реализаций Лиспа и Схемы под дотнет имею кеш боксированных char-ов и некоего диапазона int, дабы не засорять память боксированными величинами. Т.е. боксинг там ручной, типа:

object box(int i) {
    if(i>=0 && i<1024) return buff[i];
}

Однако, реально все гораздо печальнее. Чтобы обеспечить хоть какую-то эффективность, базовый класс должен быть не System.Object, а некий свой, с виртуальными ф-иями, типа IsAtom, IsPair, IsNumber и т.д., соотв. для простых чисел надо писать свои аналоги.

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

VD>Физических ограничений нет. Погляди как делается в Немерле и в C# 3.0. Ну, а переписывание кода и инлайнинг вообще решают массу проблем.

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

VladD2 wrote:
> Ты читай внимательно. Там везде слова "возможно", "может быть"...
Во-первых, используется сильный модальный глагол "can", означающий в
этом случае, что HotSpot имеет физическую возможность это делать.

Если бы стоял "may" — было бы другое дело.

Честно говоря, мне лень искать большую красивую статью на Sun'овском
сайте, где в картинках показывается как HotSpot отслеживает логику
переходов и разбивает код на inline-домены. Может поверишь мне на слово?

> > C>Компилятор языка прикладным приложением не является по определению.
> А как его по-твоему назад?
"Назад"?

А назвать его можно инструментальным средством.

> C>Вы понимаете, операция сравнения транзитивна.
> Ну, то есть все же "билд-система eao197 для С++" реально не нужна?
Ну почему же, конкуренция всегда полезна (что бы ни думала по этому
поводу MS ).

Вот товарищи из SCons (http://www.scons.org) портируют из BBv2 систему
тулсетов, а люди из BBv2 добавляют поддержку Питона в свою систему.

> C>Кстати, make пока по скорости еще никто не превзошел. Так что он в своем
> C>роде лучший.
> По чему? По скорости? Это изумительная характеристика для утилиты
> жапускающей другие экзешники.
Нда... RTFM про BBv2, SCon и VS.

http://www.gamesfromwithin.com/articles/0506/000092.html

> C>А насчет "приблуды из библиотеки" — посмотрите хоть на BBv2.
> Меня на 100% устраивает связка MSBuild + VS2005.
> Зачем мне снова в каменный век?
Мне после BBv2 проекты Студии кажутся каменным веком. Попробуйте,
например, поддерживать систему, которая строится в ANSI/Unicode*4
конфигурации (итого 8 конфигураций в целом).

Я уж не говорю про эстонскую скорость сканирования зависимостей.