Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по Embarcadero RAD Studio XE2 (Pulsar)

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Открыть новую тему     Написать ответ в эту тему

data man



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Обсуждаем новые возможности и баги
Просьба писать только про Embarcadero RAD Studio XE2 (Pulsar) - по остальным версиям есть соответствующие темы.

Вопросы вареза здесь не обсуждаются !!!
См. также:


Из слишком часто повторяемых вопросов:
  1. Почему EXE такие большие - перевод статьи от Andy тут, оригинал на страницу назад.
  2. Что случилось c авто-увеличением Build Number - Объяснение на англ.. Можно отключить встроенную функцию и добавить плагин, в котором есть "старый" авто-инкремент. Например DDevExtensions от Andy. У него так же есть хороший плагин IDE FixPack

Всего записей: 1696 | Зарегистр. 13-10-2005 | Отправлено: 23:54 27-07-2011 | Исправлено: Arioch1, 16:08 25-04-2013
deks



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Frodo_Torbins
 
Тянуть dcu -   довольно смелый ход! Можно сделать проще: делать разные exe для разных архитектур процессоров, а при установке выбирать необходимую. Но это фантазии)  
 
А, возвращаясь к LLVM - я вижу самый серьезный плюс в том, что это довольно мощная технология и при этом она открытая. То есть на ее базе можно получить компилятор мирового уровня, который сможет конкурировать с ведущими игроками! Плюс коммьюнити, где можно обсуждать такие специфические штуки, как технологии компиляторов.
 
Думаю - ЭМРО останавливает от полного использования LLVM потеря "брэнда" и идентичности. LLVM каждый сможет сделать, и они превратятся только в поставщиков IDE/Code Editor.
 

Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 09:37 28-06-2012
Senpai07



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Обновился 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
 
Изменения: Подробнее...
 
Author Blog: _http://www.bitcommander.de/blog/index.php

Всего записей: 295 | Зарегистр. 05-12-2005 | Отправлено: 12:59 29-06-2012 | Исправлено: Senpai07, 13:00 29-06-2012
Arioch1



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

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

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 12:38 30-06-2012 | Исправлено: Arioch1, 12:45 30-06-2012
X11



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Если при запуске DXE2 вываливается сообщение об ошибке:
 

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

 
то что нужно сделать? Где взять этот fmx163.bpl?
 
Это сообщение появилось после установки UniDAC 4.2.7.

----------
/не мы такие, жизнь такая/

Всего записей: 3234 | Зарегистр. 24-11-2005 | Отправлено: 10:23 04-07-2012 | Исправлено: X11, 10:23 04-07-2012
Arioch1



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
А какие обновления у тебя Delphi стоят ?
 
http://www.devart.com/unidac/revision_history.html
also http://forums.devart.com/viewtopic.php?f=28&t=24412

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 10:30 04-07-2012 | Исправлено: Arioch1, 10:32 04-07-2012
X11



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Установлен Update 4
 
Добавлено:
без hotfix1
 
Добавлено:
установил upd 4.1 (hot fix1), проблема ушла

----------
/не мы такие, жизнь такая/

Всего записей: 3234 | Зарегистр. 24-11-2005 | Отправлено: 11:12 04-07-2012
deks



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

Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 11:24 04-07-2012 | Исправлено: deks, 11:44 04-07-2012
deks



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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!)

Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 20:56 05-07-2012
Eternal_Shield

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
deks

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

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

Всего записей: 758 | Зарегистр. 18-05-2009 | Отправлено: 22:07 05-07-2012 | Исправлено: Eternal_Shield, 22:08 05-07-2012
zedxxx

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

Всего записей: 1378 | Зарегистр. 14-07-2008 | Отправлено: 23:27 05-07-2012
Frodo_Torbins

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Вроде в следующей версии обещали избавится от FPC. То есть у них должен появится собственный компайлер с поддержкой ARM. Глупо было бы лепить такую поддержку на старую архитектуру. Так что новый компилятор должен появится уже в XE3.
Эх, скорее бы открытое бета-тестирование началось, чтобы все новинки собственными руками пощупать.
 
zedxxx
Будет как у FPC. Только llvm построен по модульной архитектуре из-за чего возможны дополнительные тормоза при компиляции.

Всего записей: 2296 | Зарегистр. 24-05-2007 | Отправлено: 01:02 06-07-2012 | Исправлено: Frodo_Torbins, 01:04 06-07-2012
deks



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
zedxxx
 
Да, будут появляться нативные приложения, так как llvm все-таки компилятор. Виртуальная машина, которая упоминается в связи с ним, это промежуточный слой при компиляции, код для vm является неким аналогом dcu/obj.  
 
Frodo_Torbins
 
По поводу тормознутости-не факт, это как сделать! В Xcode не тормозит особо. Ну и учтем, что сейчас у эмро несколько парсеров. Первый в иде для code completion, help insight и прочего. И второй-уже в самом компиляторе. А при модульной структуре можно держать один парсер)

Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 08:39 06-07-2012
Arioch1



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Вообще-то страшненько.
 
Еще не так дакно clang/llvm творил странное: http://blog.regehr.org/archives/482  
 
Добавлено:

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

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

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 13:32 06-07-2012
Frodo_Torbins

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Arioch1
Парсер компилятора они вроде хотели оставить тот же, что и сейчас. Тоесть изменения в языке должны быть минимальны. А что реально у них получилось можно будет увидеть уже в бетах.

Всего записей: 2296 | Зарегистр. 24-05-2007 | Отправлено: 14:40 06-07-2012
Arioch1



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
на форуме Эмбов была большая тема, что ждать от будущего.
 
там обсуждали именно что текущий компилятор не позволяет изменять язык, но в будущем тогда не получится сохранять некоторые старые фишки типа паскаль-объектов и еще чего-то.
 
подробностей не помню, но это логично в общем-то.
Сейчас Паскаль уже после дженериков провисает. Его корни из 1940-х мешают нынешним манерам использования.
Те же аннонимные функции теряют половину смысла при такой массивной обвязке...
 
Конечно, этот топик был вялым... Основной забавой форумчан было заддосить БД обсуждением освобождения объектов
 
Ну т.е. м.б. они сделают два новых компилятора - один парсер старого с кодогенератором через LLVM, а другой - полностью новый.
Но как-то сомнительно это, хоят теоретически возможно.
 
Еще интересно насколько этот кодогенератор будет быстрым. Дельфи всегда славился скоростью, правда в том числе за счёт тупого ассемблерного кода.

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 16:32 06-07-2012 | Исправлено: Arioch1, 16:35 06-07-2012
miwa

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Arioch1
Очень интерессно; а ссылкой на эту тему (что ждать от будущего) не поделитесь?

Всего записей: 455 | Зарегистр. 10-10-2004 | Отправлено: 17:45 06-07-2012
VadimLou



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
LLVM каждый сможет сделать
deks

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

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

Всего записей: 693 | Зарегистр. 22-07-2004 | Отправлено: 06:13 07-07-2012
deks



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 близка к неприемлемой.

Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 14:38 07-07-2012
Frodo_Torbins

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

Всего записей: 2296 | Зарегистр. 24-05-2007 | Отправлено: 17:29 07-07-2012
Arioch1



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

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

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

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

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

 
Зачем, если есть родной для Delphi Interbase ? ну или firebird
 
SQLite во-первых ограниченней, во-вторых политически неправильно для EMB решение.

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 12:16 09-07-2012
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по Embarcadero RAD Studio XE2 (Pulsar)


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2020

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru

Рейтинг.ru