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

DmitryB2005

Цитата:

В поддержке предлогают качать по новой исо-образ от туда же, откуда я его и так уже качал.

А откуда качали? Можно ссылку?

Frodo_Torbins
The problem is because in x86, we can use single, double and extended float point value.

But with x64, delphi/bcb use sse to carry out the calculation, SSE use double float point value.
So, In some case, the result from x86 and x64 will not be the same.
But mostly we do not care about this, only if someone is dealing with large number of float point calculation and wants the best precision

Ru(by google):

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

Но с x64, Delphi / BCB использования SSE осуществлять расчет, SSE использовать двойные запятой с плавающей точкой.
Так, в некоторых случаях, в результате x86 и x64 не будет то же самое.
Но в основном мы не заботимся об этом, только если кто-то имеет дело с большим количеством плавать расчетной точки и хочет лучшей точности

tank0
It's not a problem, it's a feature You still can use sin(float) and fpu fsin in x64 mode instead of sin (double) and sse2.

Удалость таки поставить среду...
По симптомам от ув. deks решил перекачать образ еще раз с офф. сайта и повторить процедуру запуска установщика. На этот раз все прошло спокойно.

З.Ы. Вот и думай это после саппорта стало все ок или мне в первый раз не повезло с целостностью архива(это при том, что я iso и раром без воплей нормально распаковал и уже распакованый пробовал ставить...). Похоже автор ответа на мое обращение в поддержку таки "подпилил" iso. В пользу этого еще и фраза о том, что он занимается этой проблемой...

Вообщем всем спасибо за помощь, пойду щупать "чудо"...

DmitryB2005

Цитата:

Похоже автор ответа на мое обращение в поддержку таки "подпилил" iso.

Ага, а хэш при этом старый остался...
Вот что было для RTM:

Код: CRC32: 764AE296
MD5: DE8B9F897E2AD678643B64898470B707
SHA-1: D889082AE2EB4F1CC36649024C25A05380BD65E3

Интересный случай:
беру простенький файл Dik.dpr
-------
program Dik;
var
fErr: Text;
begin
AssignFile(fErr, 'Dik_Error.$$$');
Rewrite(fErr);
WriteLn(fErr, 'Error!');
CloseFile(fErr);
end.
-------
компилю его в x86: dcc32.exe -m Dik.dpr -e -u"...\9.0\lib\win32\release - все Ok!
А если собирать его в x64
dcc64.exe -m Dik.dpr -e -u"...\9.0\lib\win64\release,
то выдает ошибку:
F1027 Unit not found: 'System.pas' or binary equivalents (.dcu)
хотя System.pas есть в "C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\source\rtl\sys\",
System.dcu есть в "C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\lib\win64\release\System.dcu" и все пути прописаны.
Если же собирать x64, положив System.dcu в текущую папку, то компилятор выдает ошибку: F2051 Unit System was compiled with a different version of "".@DelayLoadHelper2
Похоже Embarcadero RAD Studio XE2 (Pulsar) отсюда http://forum.ru-board.com/topic.cgi?forum=35&topic=49523&start=300#lt вообще не преспособлено к сборке x64?
------------------------------------------------
Прошу прощения, все работает, только вот через батник - не всегда (мистика)

ItsJustMe
By default, xe2 use sse, not fpu for calculation.
BTW: XE2's sse code is very poor, lots of exchange between memory and xmm register(just like in x86 fpu code). Performance can be improved if EMB make full use of xmm register, decrease the exchange between memory and xmm register.

Ru(google):

По умолчанию, XE2 использования SSE, не FPU для расчета.
Кстати: SSE код XE2 является очень бедным, много обмена между памятью и XMM зарегистрируйтесь (как и в x86-код FPU). Производительность может быть улучшена, если EMB в полной мере использовать XMM регистр, снижением обмена между памятью и XMM регистр.

So we all have already realized that Delphi64 is a very low compiler. It was born more than 8 years after x64 architecture had been released. I suppose we have to be patient yet at least another 8 years more till we get a reasonable Delphi64 compiler.

ItsJustMe

At that time, I think there is no Delphi any more according to EMB's efforts.
A tool that can make everything equals to a tool that can make nothing.

Ru:

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

Цитата:

At that time, I think there is no Delphi any more according to EMB's efforts.

Прошу прощения за повтор. У меня WinXp Sp3 со всеми (последними) обновлениями. Ставил и XE2 с офф. сайта и Lite от lsuper. При открытии (создании) VCL Form Application и последующей Project->Options вылезает окно "out of memory". Остальные типы проектов открывают этот диалог без проблем. В Win7x64 проблем нет вообще при любом типе проекта. Большая просьба - может кто-нибудь поставить на WinXP SP3(чистую, не VB) ВСЕ обновления(Framework 3.5, 4.0 и т.д.), и в XE2 под этой осью попробовать Project->Options? Огромное спасибо заранее. Мучаюсь уже две недели и не могу понять, в чем тут дело. Пытался ставить WinXP SP2 без обновлений - все заработало, но как только устанавливаю обновления - опять это окно "out of memory"

Docent1
для 64 бит поправь путь к 64 битным либам/dcu

Вопрос по поводу "out of memory" снимается. Причина была в содержимом папки Styles.
Подскажите, какой номер версии у XE2?
Для XE был VER220
И еще, выложите, пожалуста dcc32.exe и dcc64 куда-нибудь(rghost). У меня по триальному ключу не поставилось.

ppkp

Цитата:

Для XE был VER220

Открываем файл System.pas и видим строчку:

Код:
const
RTLVersion = 23.00;

whitewolfs Я просто поделился тем, что нашёл. А SP решил подождать, потомучто, на мой взгляд, среда сыровата. Да и первая ХЕ-шка меня, на данный момент, устраивает...

Samogonwik

Считай, дождался!) Update 1 вышел))

А если кроме шуток, то среда как раз довольно стабильная - если под "средой" имеется ввиду IDE. Нестабильными в XE2 являются новые "куски" - x64, mac, fmx. Если не пользовать новых частей - вообще можно работать без особых проблем) Впрочем, тогда и отличий особых от XE нет, разве что DocInsight))

deks
осталось только компоненты свежие дождаться

Чего-то ругается сабж на uses DesignIntf, DesignEditors при компиляции в Win64. Может что-то другое применять надо для 64-битных компонент?

Собирал FIBPlus 7.0.15 под XE2. Непонятно:

FList: TList;
FList.List^[Index1] - в предыдущих версиях без ошибок, в XE2 ошибка "E2017 Pointer type required";
FList.List[Index1] - без ошибок, в т.ч. и XE2.

Почему? И как правильно?

Добавлено:
ppkp, в 64 пока нет designtime, только runtime (командный компилятор).

ppkp
Интересно как бы это 32-х битная IDE загрузила 64-х битные пакеты? Поэтому все делается немного иначе: в 32-х битном пакете делаются пометки, что его компоненты работают и на платформе win32, и на win64, и даже на macos32 (если ваши компоненты ее поддерживают).

AlexCoRu

Цитата:

FList: TList;
FList.List^[Index1] - в предыдущих версиях без ошибок, в XE2 ошибка "E2017 Pointer type required";
FList.List[Index1] - без ошибок, в т.ч. и XE2.

Release Notes не просто так существует, и если в него заглянути, то строчка вида:

Цитата:

The TList member FList is now of type TPointerList (it was PPointerList).

сразу ответит на все вопросы.

Frodo_Torbins

Цитата:

все делается немного иначе: в 32-х битном пакете делаются пометки, что его компоненты работают и на платформе win32, и на win64

Можно подробнее? Какие пометки?

ppkp
Подробности: http://docwiki.embarcadero.com/RADStudio/en/64-bit_Cross-Platform_Application_Development_for_Windows

Frodo_Torbins
Я прочел эту статью еще раз. Вставил аттрибут ComponentPlatformsAttribute в pas (я уже делал так до постинга)
type
[ComponentPlatformsAttribute(pidWin32 or pidWin64)]
TMyComponentEditor = class(TComponentEditor)
Но в dpk ругается на designide при 64-битной компиляции
requires
rtl, vcl, designide;
Самый простой компонент.

в бетке видел FM компонентик для проигрывания видео.
поставил c upd1, вспомнил про него, хотел поковырят да что то не найду никак..
никто не просветит куда оно делось?

з.ы.
нашел упоминание тут FMX.Layers3D.TVideo3D а так же FMX.Video.TVideoPlayer
но в палитре его нет, а в бетке был..

ppkp
Если у вас пакет типа все в одном - и рантайм, и дизайнтайм, то его придется разделить. Дизайнтайм вы компилите только для 32-х бит, но в платформы добавляете все поддерживаемое. После этого ComponentPlatformsAttribute уже должен быть не нужен. Сам я это на деле еще не пробовал, сужу по статье выше.

кто знает, есть в планах релизить компоненты FM, тот же DBGrid ?
или я что то не понимаю..

LG Team
Стринг грид в FM есть, но к БД он привязывается только с помощью лайв биндингов. Или вы о чем то другом спрашивали? Сформулируйте вопрос по четче.

LG Team
Frodo_Torbins

Учитывая, что в KSDev VGScene был DBGrid, очевидно, что принято решение использовать LiveBinding для привязки контрольев к БД. Лично я полностью одобряю - разделение на "просто" и DB-aware компоненты - это как то устарело)

Цитата:

Учитывая, что в KSDev VGScene был DBGrid, очевидно, что принято решение использовать LiveBinding для привязки контрольев к БД. Лично я полностью одобряю - разделение на "просто" и DB-aware компоненты - это как то устарело)

Все бы было здорово, если бы они не создали из лайвбиндинга монстра, покруче db-aware