» Вопросы по Embarcadero RAD Studio XE2 (Pulsar)

deks
Скорее всего так и будет: http://wiert.me/2012/06/05/some-links-on-the-delphi-compiler-and-the-llvm-compiler-infrastructure-project/

Frodo_Torbins

Это было бы закономерное решение! Кстати, учитывая наличие С++ фронт-энда у llbm (clang), поддержка билдера для иос появится почти сразу)) ну и самое крутое продолжение - это прикрутить к llbm бэкенд для win32/win64. Получится хорошее решение: и С++, и Дельфи сразу для os x, iOS, win32/64! Не говоря уже о потенциальной возможности ObjectiveC для win-было бы забавно, хотя без Framework особого смысла нет, а Apple вряд ли даст лицензию на API)) хотя API в деле Оракла против Гугла признано не имеющим патентной охраны!) Интересно, был бы рынок для Objective-C для Win с прицелом на разработчиков, которые портируют приложения с OSX/iOS на Win?)

А вот с андроидом предстоит возня: нужен бэкенд, который будет генерировать код для java vm! Хотя RemObjects справились с этим)

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

Цитата:

Что случилось c авто-увеличением Build Number - Объяснение на англ.. Можно отключить встроенную функцию и добавить плагин, в котором есть "старый" авто-инкремент. Например DDevExtensions от Andy.

Подскажите как настроить формирование "старого" номера билда, а то я что-то в DDevExtensions 2.5 не нахожу настройки формирования Build Number , понедельник наверное влияет.

Frodo_Torbins

Основной плюс модульности - это возможность работы фронтэнда во время редактирования. Типа, при запуске проекта на выполнение все изменившиеся файлы уже "разобраны", остается только генерировать код и линковать. Это довольно быстро, к тому же при современном железе и объемах ОЗУ - быстродействие не так критично.. Главное, чтобы оставалось разумное время "отклика" системы. А из плюсов LLVM - возможность использовать серьезные наработки других компаний)

deks
Мне еще нравится их открытость и бесплатность. По идее можно будет спокойно встроить их бекэнд в свой инсталятор вместе с набором "dcu-шек", и компилить/оптимизировать свою прогу под конкретный проц пользователя прямо во время установки.
В этом случае дотнетчики потеряют еще один аргумент в пользу своего монструозного фреймворка

Frodo_Torbins

Тянуть dcu - довольно смелый ход! Можно сделать проще: делать разные exe для разных архитектур процессоров, а при установке выбирать необходимую. Но это фантазии)

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

Думаю - ЭМРО останавливает от полного использования LLVM потеря "брэнда" и идентичности. LLVM каждый сможет сделать, и они превратятся только в поставщиков IDE/Code Editor.

Обновился Object Inspector Expert Beta 4 (flicker and icon fixes)
_http://www.bitcommander.de/blog/index.php/2012/01/01/oi-rev/
_http://www.bitcommander.de/files/201206252B551263/ObjectInspectorExpertBeta4.exe

Изменения: [more]
- Filter edit images are now taken from an IDE package (should be less error prone than copying them from the Tool Palette)
- Left filter edit image indicates now that there is a dropdown menu
- Rewritten HotCommands and DescriptionPane visibility code (old version caused flicker when entering a Caption for example)
[/more]

Author Blog: _http://www.bitcommander.de/blog/index.php

Цитата:

LLVM - я вижу самый серьезный плюс в том, что это довольно мощная технология

ЗАбавно, что Portable.Net был заментно раньше но так и не получил признания, возможно потому что не заявил себя как общий фреёмворк нигде кроме технических документво и все прошли мимо. LLVM появился позже и обогнал его нафиг.
Или может это случилось потому, что Яблокам понадобился OpenGL ? Как они WebKit раскрутили, так и LLVM

Добавлено:

Цитата:

А вот с андроидом предстоит возня: нужен бэкенд, который будет генерировать код для java vm!

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

Если при запуске DXE2 вываливается сообщение об ошибке:


Код: Запуск программы невозможен, так как на компьютере отсутствует fmx163.bpl. Попробуйте переустановить программу.

А какие обновления у тебя Delphi стоят ?

http://www.devart.com/unidac/revision_history.html
also http://forums.devart.com/viewtopic.php?f=28&t=24412

Установлен Update 4

Добавлено:
без hotfix1

Добавлено:
установил upd 4.1 (hot fix1), проблема ушла

X11

Это сообщение появляется, когда какой-то пакет устанавливался в бинарном виде, и был линкован со свежим обновлением FMX (16.3 - это u4.hf1). Способ "победить" такую ошибку - сделать "build" из исходников этого пакета, чтобы он "слинковался" с "правильным" пакетом FMX. Ну или поставить именно то update, который хочет пакет!

upd: ожидаемо) и да, u4.hf1 для fmx лучше ставить - много багов вылечено!

Frodo_Torbins

Omfg: только накануне говорили о llvm, а тут новости - _http://www.itwriting.com/blog/5966-embarcadero-adopts-open-source-clang-for-future-c-versions.html

Для с++ будет использоваться clang + llvm, а Эмро сосредоточиться только на IDE и frameworks. Для дельфей будет аналогично, по всей видимости!)

П.с: Эмро! почему ж цена за IDE такая конская?! Смотрите на jetbrains)) ждем снижения цен на хе3!)

deks

Цитата:

Для дельфей будет аналогично, по всей видимости!)

Не по всей видимости, а 100%-но Некоторое время будет существовать 2 компилятора: старый и новый. Потом старого пристрелят и похоронят на Луне, но, думаю, раньше XE4 нового компиля ждать не стоит =/

Может глупость спрошу, но всё же: с этим новомодным llvm будут получаться нативные приложения (на всех заявленных платформах) или всё будет работать через некую виртуальную машину и соответственно, безбожно тормозить?

Вроде в следующей версии обещали избавится от FPC. То есть у них должен появится собственный компайлер с поддержкой ARM. Глупо было бы лепить такую поддержку на старую архитектуру. Так что новый компилятор должен появится уже в XE3.
Эх, скорее бы открытое бета-тестирование началось, чтобы все новинки собственными руками пощупать.

zedxxx
Будет как у FPC. Только llvm построен по модульной архитектуре из-за чего возможны дополнительные тормоза при компиляции.

zedxxx

Да, будут появляться нативные приложения, так как llvm все-таки компилятор. Виртуальная машина, которая упоминается в связи с ним, это промежуточный слой при компиляции, код для vm является неким аналогом dcu/obj.

Frodo_Torbins

По поводу тормознутости-не факт, это как сделать! В Xcode не тормозит особо. Ну и учтем, что сейчас у эмро несколько парсеров. Первый в иде для code completion, help insight и прочего. И второй-уже в самом компиляторе. А при модульной структуре можно держать один парсер)

Вообще-то страшненько.

Еще не так дакно clang/llvm творил странное: http://blog.regehr.org/archives/482

Добавлено:

Цитата:

А при модульной структуре можно держать один парсер)

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

Для классической Delphi - трахайтесь с убожеством на J#

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

на форуме Эмбов была большая тема, что ждать от будущего.

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

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

Конечно, этот топик был вялым... Основной забавой форумчан было заддосить БД обсуждением освобождения объектов

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

Еще интересно насколько этот кодогенератор будет быстрым. Дельфи всегда славился скоростью, правда в том числе за счёт тупого ассемблерного кода.

Arioch1
Очень интерессно; а ссылкой на эту тему (что ждать от будущего) не поделитесь?

Цитата:

LLVM каждый сможет сделать

deks

Цитата:

LLVM каждый сможет сделать

Что-то никто не может за RemObjects повторить столь удачный компилер и интеграцию в VS. Хотя там тоже всё открыто. Было бы так просто не покупали бы RemObjects. Но видимо посчитали трудозатраты и решили - проще купить...

Arioch1

Про парсер: ситуация с парсером внутри студии давно требовала решения! Логично ж делать единый парсер для всех фич IDE (refactorings, completion, всякие insight, formatting, я б еще API добавил для доступа аддонов к объектам программы или сделал внутреннюю бд на SQLite), и парсер для компилятора. А тут как раз смена компилятора)) Надеюсь-они таки решаться!

Ну и llvm благодаря ставке apple на него (они дрогнули gcc) очень стремительно развивается, во всяком случае, в части clang, iOS, os x.

VadimLou

Наверное, говоря о "простоте" я имел ввиду компании, занимающиеся поставкой компиляторов и сред. А РемОбджектов не покупали, просто лицензировали! А отсутствие собственного решения Эмро для .net вызвано нежеланием терять фокусировку на своем рынке (нативные решения), имхо, просто сил не хватило. Действительно, проще было лицензировать, благо рынок паскаля для .net совсем мелкий!)

С тех пор дельфи немного укрепились и чувствуют себя лучше, так что Эмро может предпринять более решительные шаги! надеюсь, благодаря интеграции llvm можно бистро получить современный компилятор для нескольких платформ (а для iOS и os x - аналогичный компилятору от вендора платформы). Единственное, что очень расстраивает в политике Эмро - это безальтернативное использование FireMonkey. Лучше б предлагали возможность использования другого GUI (нативного платформе), и в спокойном режиме допиливали б свою обезьяну. Со временем обезьяна станет Qt но для Паскаля, да) Но пока скорость работы на iOS близка к неприемлемой.

deks
Так вроде уже сейчас все желающие могут использовать нативный интерфейс на эпловских платформах. Просто поддержки со стороны IDE не будет. Кстати кто-нибудь представляет себе как ее организовать? Мне кажется что это получится что то типа MCK для KOL. В принципе, если бы дизайнер форм в делфи имел открытый апи, то уже бы наверно существовало несколько наборов компонент для создания нативных интерфейсов под маки и айфоны.

Цитата:

а ссылкой на эту тему (что ждать от будущего) не поделитесь?

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



Добавлено:

Цитата:

Лучше б предлагали возможность использования другого GUI (нативного платформе)

Кому лучше ? Двум с половиной чистым яблочникам ? Для них есть XCode/FPC
А виндовым программистам какое счастьею от нативной Кокойи, которую они не смогт отлаживать ?
Тут нужна именно библиотека, кросс-компилирующаяся с Винды на Яблоко. И нативные яблочные интерфейсы на винде эмулировать... боюсь сил Эмбы на такое не хватит.

Добавлено:

Цитата:

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

А что тебе не хватает? был CLX, есть тот же KOL и другие API-проекты.
Думаю, он достаточно открытый. Вот только не вижу я возможности на винде использовать нативные интерфейсы МасОси. А значит, пока вся среда не заработает нативно под Маком - делать узко-яблочную нативную библиотеку бессмысленно.

Тем более - две разных библиотеки, мод MacOS и под iOS

Добавлено:

Цитата:

или сделал внутреннюю бд на SQLite

Зачем, если есть родной для Delphi Interbase ? ну или firebird

SQLite во-первых ограниченней, во-вторых политически неправильно для EMB решение.

deks

Цитата:

А отсутствие собственного решения Эмро для .net

Так был же уних свой компилер (D2007 dccil.exe). Наверное посчитали что накладно будет его и дальше тянуть. А ещё ранее был у них проект delphi for java. Даже какие-то демки показывали. Но тогда с саном не смогли лицензии утрясти - заглохло. Теперь выходит неродные платформы отдали на откуп RemObjects.

Бум надеяться llvm создаст в этом вопросе здоровую конкуренцию.

А не так как эти:
http://code.google.com/p/llvm-pascal/

ну там вроде был .Net 1 и компилятор и библиотека, вроде толком его на .Net 2 не перенесли

Цитата:

Кому лучше ? Двум с половиной чистым яблочникам ? Для них есть XCode/FPC
А виндовым программистам какое счастьею от нативной Кокойи, которую они не смогт отлаживать ?

Виндовым программерам может придти в голову мысль написать клиент для своей системы на ipad/Mac - вполне здравая мысль. Длоя такой разработки всяко нужен нативный Mac (без него деплой на устройства практически невозможен). Вот на эту аудиторию и ориентируется Эмро, причем ауждитория хорошая. Беда в том, что эмуляция интерфейса (FMX) работает сносно на Mac (но не идеально), и проблемно на iOS. Я был бы рад, если бы появилась возможность делать более производительный GUI на iOS.

Frodo_Torbins


Цитата:

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

Вообще нет никакой документации по использованию нативных для платформы решений с XE2. Что-то было для OS X, а про iOS - темный лес.. Да, есть инфа про FPC, но я почти уверен - FPC будет заменен в XE3. То есть нужно решение для нативного доступа, которое поддерживается Эмро.

Arioch1


Цитата:

внутреннюю бд

Не принципиально. Я про API доступ к Abstract Syntax Tree - было бы полезно. APIU может быть или DataSet-оприентированным (с возможностью SQL запросов) или просто API)

как можно в коде определить это релиз или дебаг версия приложения?