Вышел Descent 0.5.4

не помню, работает ли этот лисп полностью в compile-time http://www.dsource.org/projects/dlisp/browser/trunk , но какой-то парсер на шаблонах D во время компиляции точно видел. Как бы не компилятор миниD языка.

см. также DDL http://www.dsource.org/projects/ddl

В отличие от #include он подставляет содержимое файла как string literal. Поэтому его нужно ещё в mixin положить.

Для import() много других интересных применений есть. Например, в копирайт-чекере можно так избавиться от захардкоженного копирайта:

auto ourCopyright = import("copyright.txt");

При компиляции ourCopyright станет строкой, равной содержимому файла copyright.txt. objdump показывает, что она хранится в .data.

о, не знал

только в phobos, в tango нет?

То есть получается, что если Qt переписать на D, то костыли вроде moc станут ненужными?

Если ли в метапрограммировании на D досадные ограничения?

Почему размер выходных исполняемых файлов такой большой? Есть ли какой-нибудь простой способ их уменьшить?

Можно ли слинковать c++ код откомпилированный на mingw/gcc с D кодом на DMD? Или придётся использовать DMC и переписывать код на ассемблере с AT&T на Intel?

а какое текущее состояние с рефлексией и GUI поддержкой юнит-тестов? вот в JUnit в Eclipse есть интересный запуск юнит-тестов одной кнопкой. Для Descent что-то подобное есть?

> То есть получается, что если Qt переписать на D, то костыли вроде moc станут ненужными?

это надо просто попробовать и посмотреть. moc в основном нужен для сигналов-слотов, ощущение есть, что всё можно сделать шаблонами времени компиляции.

> Почему размер выходных исполняемых файлов такой большой? Есть ли какой-нибудь простой способ их уменьшить?

как обычно, смотреть карту с map-файлами, мерять, выкидывать ненужное

> Можно ли слинковать c++ код откомпилированный на mingw/gcc с D кодом на DMD?

C можно на уровне ABI. C++ с ограничениями, см. http://digitalmars.com/d/2.0/cpp_interface.html . Ещё есть http://languagemachine.sourceforge.net/j2d.html http://languagemachine.sourceforge.net/d_to_d_translator.html где есть связка с gcc : http://languagemachine.sourceforge.net/gcc_interface.html

DMC сам состоит из открытого DMDFE http://www.dsource.org/projects/dmdfe (исходники в поставке) и закрытого бекенда.

> Можно ли слинковать c++ код откомпилированный на mingw/gcc с D кодом на DMD?

по идее, dmd file.d -c file.o должен собрать нормальный ELF/DWARF бинарник, с которым линковаться собранному g++ C++ коду. Под виндой скорее вряд ли, ибо в mingw .o файлы, а в DMD - *.OBJ и свой линкер

так что лучше взять вместо DMC LDC или gdc

> То есть получается, что если Qt переписать на D, то костыли вроде moc станут ненужными?
У разработчиков qtd есть подозрение, что да. Хотите подробности - обращайтесь лучше к ним: http://code.google.com/p/qtd/

> Если ли в метапрограммировании на D досадные ограничения?
Например, нельзя оперировать произволиными AST-деревьями. Слишком абстрактный вопрос, чтобы дать конкретный ответ.

> Почему размер выходных исполняемых файлов такой большой? Есть ли какой-нибудь простой способ их уменьшить?
Говорят, кому-то когда-то удавалось рантайм слинковать динамически. С приходом LDC этот способ должен стать простым. Сейчас же все либы линкуются статически.

> только в phobos, в tango нет?

Нужные шаблоны просто берутся из Phobos. У них зависимостей ровно 0. Только если будуте переносить модуль целиком, не забудьте выбросить юниттесты и import std.stdio;

> а какое текущее состояние с рефлексией
Есть __traits - compile-time reflection. http://www.digitalmars.com/d/2.0/traits.html
Есть ddl - introspection. http://www.dsource.org/projects/ddl

> и GUI поддержкой юнит-тестов?
В разработке. Планируется реализовать сразу после билдера в стиле ecj, используемом jdt.

>в стиле ecj

Даже для такого простого source языка как джава и dest языкак как java-bytecode этот билдер _крайне_ нетривиален и временами подглючивает, хотя его пишет не один выскокквалифицированный разрабочтик IBM - а для Д его можно ждать вечно ;)

Надо уточнить слухи. :)

С точки зрения пользователя он будет вести себя так же, как jdt, но на самом деле компилить файлы целиком. Проблемой это стать не должно:
$ wc -l algorithm.d
3431 algorithm.d
$ time dmd -o- algorithm.d

real 0m0.066s
user 0m0.057s
sys 0m0.009s

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

Нее. Вы не поняли. _Инкрементальный_ компилятор ecj (а именнов этом его за слуга) сам умно отслеживает какие файлы надо ребилдить. И делает это быстро на больших пректах. А так же быстро перестраивает список ошибок. И вот всё это уже для Д делать ой как долго.

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

Зачем Eclipse, когда есть куда более вменяемый Emacs?

Зачем emacs когда есть куда более вменяемый vim?

Пользуешь Emacs - напиши себе mode. Автор Descent предпочитает Eclipse - пишет себе плагин.

> _Инкрементальный_ компилятор ecj (а именнов этом его за слуга) сам умно отслеживает какие файлы надо ребилдить. И делает это быстро на больших пректах. А так же быстро перестраивает список ошибок.
Именно это и планируется. Собственно, в чём может быть проблема?
Виноват, думал ecj инкрементальный в пределах файла. :)

> Компилятор на Java вы не получите.
Фронтэнд уже есть. А бэкэнд на Java никто писАть не будет, т.к. есть действующие альтернативы. Я dmd запускал с ключиком -o-, означающий "не генерировать код, только разобрать файл".

Кстати, наш сотечественник(его можно найти на форуме dprogramming.ru пишет биндинг для D к Qt4, если кто то желает присоединиться - пожайлуйте туда

конечно есть - vim называется )

> Есть __traits - compile-time reflection. http://www.digitalmars.com/d/2.0/traits.html

thx, nice http://www.digitalmars.com/d/1.0/cpptod.html#typetraits

> А в D можно написать функцию аналог atoi или itoa работающую в compile-time? А mixin из файла подгрузить?

Ещё на эту тему можно посмотреть скриптовые языки, компиляторы которых реализованы на D: MiniD
http://www.dsource.org/projects/minid/ , Monster http://www.dsource.org/projects/monster

Приложения на этих языках будут частично совместимы на уровне исходников с самим D, так что возможно в самом конечном приложении делать часть на D, часть на этих скриптах. Скрипты можно откомпилировать через D в бинарник, подгружать из основного приложения через DDL

>> То есть получается, что если Qt переписать на D, то костыли вроде moc станут ненужными?

>У разработчиков qtd есть подозрение, что да. Хотите подробности - обращайтесь лучше к ним: http://code.google.com/p/qtd/

Ситуация такова что для D1 версии qtd без препроцессора не обойтись, потому что у него не хватает необходимых средств интроспекции. Для D2 ситуация лучше, но опять же не все идеально - здесь я привожу мнение второго разработчика. Она обещала подготовить Уолтеру что именно ей не хватает в reflection api чтобы реализовать qtd для D2 без moc. К сожалению у нее сейчас мало времени и я не знаю когда сигналы и слоты появятся в qtd, а у меня тоже немного времени чтобы разбираться как они работают, я никогда этим не занимался. Со своей стороны я закончил базовую поддержку виджетов и лэйаутов. То есть это единственное что сдерживает на данный момент реальное использование Qt с D. Если кто-то из присутствующих имеет желание и возможность быстро прикрутить поддержку сигналов слотов к qtd - было бы очень здорово, обращайтесь на форум на dprogramming.ru в соответствующую ветку.

Проще Gtk# + C# юзать и не изобретать велосипеды.

Вплотную когда GTK+ начнешь пользоваться поймешь что это недо-куте. Собственно проблемы с GTK меня и сподвигли заняться разработкой биндинга Qt.

> Есть другие качественные IDE под D?

vim|emacs + make + gdb - считаются? ;-)

> А зачем нужен D? То что не виртаульная машина - так это скорее минус

нужна ВМ - генери код для LLVM - в чём проблема? то, что компилируется родной код для машины - это плюс. если нужна ВМ, см. выше

тут GC в языке, а не в виртуальной машине.

скорость разработки выше, чем в С/С++, но в отличие от Python, Ruby - компилируется в код машины.

> 1.0 устиарел, 2.0 не зарелизился

чем это 1.0 устарел? а разница между 1.0 и 2.0 - больше в библиотеках

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

> а что-нибудь для работы с архивами (zip/rar) и sql там есть?

sql: http://dsource.org/projects/ddbi

другие проекты: http://dsource.org/projects/

> Обратной совместимости с с++ нету

обратная совместимость есть с C. D основан не на С++, а на C. хоть и использует некоторые идеи из C++ (и ещё примерно из десятка языков)

О, Эльдар пожалавал. Привет, респект за проект.

А можно здесь вкратце рассказать, как устроен порт?
Обёртки С++ объектов в Си с одной стороны и другие обёртки в D с другой? Что надо будет допиливать в порте, когда в qt-4.5 в очередной раз поменяют API? Что там с QtJambi, эти обёртки с обоих сторон генерируются автоматически через QtJambi? Вообще генерировать обёртки автоматически -- идея здравая, +1.

И как устроена система сборки самого Qt?
Что происходит после configure в основном дереве Qt, что такое "архитектура" в qt (mkspecs/linux-g++,linux-cxx), как в целом отрабатывает связка ./configure/qconf/qmake.conf/qmake/make, и что потом происходит при сборке своего приложения через qmake && make (вызывается компилятор ресурсов, moc, собирается всё это вместе)? \или где про этот процесс сборки можно почитать, кроме исходников??\
Может, имеет смысл делать порт на D как отдельную архитектуру в mkspecs?

>Но хочется то что бы быстро испольнимый файл строить.

диоксид внушаить, да http://talks.dprogramming.ru/index.php?topic=45.0

> А то это у вас верификатор, а не компилятор.

ну верификатор по-моему и используется как часть ecj при инкрементальной компиляции. А в D2 traits ещё получается и юнит-тест можно написать, на то, скомпилируется код корректно или нет.

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

каких именно, в каком месте? применить для этого DDL не получится?

отдельный интересный вопрос (так, реплика в воздух, вдруг кто захочет поэкспериментировать), можно ли зайти с другой стороны и применить к QtJambi вот это http://languagemachine.sourceforge.net/j2d.html

>О, Эльдар пожалавал. Привет, респект за проект.

>А можно здесь вкратце рассказать, как устроен порт? Обёртки С++ объектов в Си с одной стороны и другие обёртки в D с другой? Что надо будет допиливать в порте, когда в qt-4.5 в очередной раз поменяют API? Что там с QtJambi, эти обёртки с обоих сторон генерируются автоматически через QtJambi? Вообще генерировать обёртки автоматически -- идея здравая, +1.

Спасибо! Да биндинг состоит из двух частей, как наверное и все другие биндинги С++ либ, первая оборачивает весь API в С функции а вторая написанная на D по этим функциям воссоздает оригинальную иерархию. Для генерации биндингов используется QtJambi который парсит хидеры Qt и создает описание всей системы типов на основе которого генерируются обе обертки. Теоретически с выходом Qt4.5 ничего не поменяется, но нужно будет проапдейтить генератор и xml файлы самого QtJambi на предмет изменений Jambi 4.4-4.5. Примерно так. Как устроен Qt я слабо представляю да и я небольшой эксперт по его использованию. Насчет архитектуры в Qt - это как я понимаю платформенно зависимый код, вынесенный отдельно чтобы упростить портирование на новые архитектуры. D тут не причем, так как qtd зависит только от Qt API и следовательно в дебри лезть не нужно. Можно конечно взяться за портирование всего Qt на D но это имеет смысл опять же тогда, когда D вытеснит С++, не думаю что это произойдет скоро. Ну и когда накопится достаточное количество Qt based D кода.

Лучше спрашивай на http://code.google.com/p/qtd/ или http://talks.dprogramming.ru/index.php?topic=51.60 Я Qt не видел ни разу.

>каких именно, в каком месте? применить для этого DDL не получится?

Понятия не имею, не знаю каким боком сюда можно прикрутить DDL. Если есть желание - попробуй проверь!

>отдельный интересный вопрос (так, реплика в воздух, вдруг кто захочет поэкспериментировать), можно ли зайти с другой стороны и применить к QtJambi вот это http://languagemachine.sourceforge.net/j2d.html

Не получится. Во-первых биндинг QtJambi гораздо сложнее устроен, так как используется JNI, в D простые extern(C) вызовы. Во-вторых qtd наверное один из самых эффективных Qt биндингов, потому что в других, особенно к скриптовым языкам, .NET при вызове каждого метода происходит много ужасных вещей как поиск в хэшах и т. д. Здесь все более менее прямолинейно, хотя в связи с этим и есть некоторые проблемы. Думаю когда люди начнут пользоваться, они исправят все ошибки которые я допустил.

даёшь Волтера Брайта в модераторы ЛОРа! =)
http://dobbscodetalk.com/index.php?option=com_myblog&show=Porting-D-to-th...
http://dobbscodetalk.com/index.php?option=com_myblog&category=D+Programmi...

> Во-вторых qtd наверное один из самых эффективных Qt биндингов

ну вот хоть что-то начало меняться в плане иде