» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

kaz_av

Цитата:

А результат, по окончании, выкладывать будешь?

Буду. Сейчас сезон по работе, много запросов. Думаю через пару месяцев версия на JAVA заменит версию на Delphi. Осталось не так много, просто некогда заниматься

Возможно просто как то выложу основную часть на JAVA для сравнения. Разница заметна даже невооруженным взглядом

SuPriTo

Цитата:

Если бы выбирать си# или Delphi Prism я бы выбрал Delphi Prism, но ее перестали поддерживать.

Так ведь не перестали. Кислород живет и здравствует. Развивается. Недавно они новую версию выпустили.

NickNNN

Цитата:

Возможно просто как то выложу основную часть на JAVA для сравнения. Разница заметна даже невооруженным взглядом

Было бы здорово. Для наглядности лучше не придумаешь.

Цитата:

Было бы здорово. Для наглядности лучше не придумаешь.

а смысл - и так все очевидно

sergionn

Цитата:

а смысл - и так все очевидно

Судя по топику, видно далеко не всем.

kaz_av

Цитата:

Когда это было, в 79-м году, кажется?

Нет, еще вполне себе на границе 80-90х.

Когда там Apple на Objective С переползать начала?

И Первые 2(две) версии windows на pascal писались.
оттуда и модель вызова в win-функциях.

MS перестала развивать свой Quick Pascal после картельного сговора с Borland, в обмен на TurboBasic.
Borland тогда и радовалась еще, наивные..

Добавлено:
kaz_av

Цитата:

Так в чем же дело? Delphi Prism назывался ремобжектовый кислород. RemObjects Oxygen - стоит дешевле чем дельфя

И хоститься в VS, которая нравится многим(отмазка-"мопед не мой", я только констатирую).

Цитата:

А в Xamarin как у них?

Родной UI. Если использовать Xamarin.Forms, то ещё и кросс-платформенный. Не знаю, как сейчас, но по опыту одного проекта (разрабатывал не я), он был лагучим, бажным и позволял делать только более-менее стандартные вещи.

iOS 64-bit Release Plans
http://forms.embarcadero.com/RADiOS64Webinar
я не понял а зачем вебинар проводить?
Будут "объяснять" почему они не успели к 1 февраля сделать поддержку ios 64bit?
или будет, но через одно место - и этим хитрым манипуляциям будут учить на вебинаре....
И как я понял 64Bit for OSX видимо в xe8 точно не будет!?

Добавлено:

Цитата:

Если использовать Xamarin.Forms,

ну вот не нравиться мне, что при установке xamarin аппа мне еще немаленький mono runtime на девайс прилетает...

Добавлено:
kaz_av
опять спрошу - а как там sugar, что уже может?

Alexey_Gawrilow

Цитата:

Нет, еще вполне себе на границе 80-90х.

Точно, судя по вики System 6 (1988) была последней версией где использовался паскаль. Потом переписали на C++. В общем, это все равно "дела давно минувших дней..."


Цитата:

И хоститься в VS, которая нравится многим(отмазка-"мопед не мой", я только констатирую).

Для яблочников там теперь своя IDE есть. Жаль, что они от интеграции с MonoDevelop отказались, лично мне студия жутко не нравится

sergionn

Цитата:

ну вот не нравиться мне, что при установке xamarin аппа мне еще немаленький mono runtime на девайс прилетает...

Немаленький это сколько?


Цитата:

опять спрошу - а как там sugar, что уже может?

Мало чего может Не приоритетное направление похоже, зато теперь его можно использовать с любым из элементов (кислород/водород/серебро) без дополнительной лицензии на кислород.

Цитата:

Немаленький это сколько?

ааа! не помню! стер тестовый апп уже.
но вроде больше чем fmx

sergionn

Цитата:

но вроде больше чем fmx

У меня есть игруля на ведроиде Bus Simulator. Написана на C# под Mono, использует Unity. Я сейчас apk'шку посмотрел, так там libmain.so и libmono.so весят всего 4 метра. Есть правда еще libunity.so на 10 метров, но это к рантайму явно не относится. Плюс в ассетах еще 6 метров dll'ей (сборок), из которых 4 метра вытягивают явно относящиеся к mono. В итоге получается около 8 метров, в данном случае, для рантайма. Хотя, возможно, всё зависит от количества используемых сборок. Вот еще нашлось.

Цитата:

И как я понял 64Bit for OSX видимо в xe8 точно не будет!?

Они из-за этого выбросили clang для Win32, сами объяснили на закрытом форуме

kaz_av

Цитата:

только её и оттуда (там, где молодую поросль динозавры вытаптывать не успевают) уже давно выдавливают шарп с вебом.

Хорошо если хоть с вэбом.
А не как попытался "аутсорсер"(долгая история) у нас - теже яйца - вид с боку: просто C#+WinForms.
Безо всякого обоснования - других "девелоперов" нет. dotNet'чики хоть дешевые.
И подтверждаю - нанимал недавно, и наняли, толька взяли не что хотели, а что было - иначе край.

kaz_av
запустил тестовый апп (release) xamarin:
Mono Shared Runtime - 20,36Mb
Сам тестовый апп (часы + чекбокс) - 3,56Мб (внутри apk - 5.21Mb)

Тестовый апп fmx xe7upd1
на девайсе показывает - 9,29мб
На диске в каталоге бин сам apk - 6,6Mb внутри apk - 22 мб

Тестовый апп Unity 4.6 UI кнопочки и тп.

Сам apk 14,7Mb
Внутри 37,5Mb
на устройстве - 31,6Mb


Добавлено:

Цитата:

Они из-за этого выбросили clang для Win32, сами объяснили на закрытом форуме

не понял, так что именно OSX (не ios) 64бита будет?

Цитата:

не понял, так что именно OSX (не ios) 64бита будет?

"I am sorry to announce that WIN32 using clang went on hold as soon as iOS64
became the focus......"

Это цитата.

Цитата:

Это цитата.

понятно, значит скорее нет чем да

Добавлено:
NickNNN

Цитата:

Разница заметна даже невооруженным взглядом

расскажи пару моментов, особенно интересует работа с UI в Android - мне показалось, что там голову можно сломать от обилия вариантов привязок и расположений - и как результат неоднозначность полученного результата?

Цитата:

"I am sorry to announce that WIN32 using clang went on hold as soon as iOS64
became the focus.

враньё, считаю. Тянут время. Единственное препятствие для Clang-32 -- это отсутствие реализации SEH на этой платформе.

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

--

Цитата:

"I am sorry to announce that WIN32 using clang went on hold as soon as iOS64
became the focus.

Это вообще нормальный английский? Не большой я специалист по инглиш граммар, но это "as soon as" вообще по смыслу не вяжется.

Доброго времени суток.
Есть в наличии лицензия на фастрепорт 4. На сайте доступна для скачивания fr_team4_15_13_d20s.exe
в описании (Embarcadero RAD Studio XE 6 ) для XE7 не вижу официальной версии фастрепорта 4.
Смогу ли я поставить без багов эту версию фастрепорта на XE7 ? Или разработчики забросили её?

Цитата:

Смогу ли я поставить без багов эту версию фастрепорта на XE7 ? Или разработчики забросили её?

сможешь, если не полный нуб.

Цитата:

сможешь, если не полный нуб.

это хорошо, так как дев экспресс 14.1.2 как не пытался, так и не смог на XE7 влепить.

kaz_av

Цитата:

Судя по топику, видно далеко не всем

Ой ладно! У чела траблы с FMX.. неудивительно. Графическая часть на далвике конечно будет быстрее. А остальная часть -- медленнее, если вообще там скорость имеет значение.

Такова фишка натива -- скорость там, где она нужна

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

Добавлено:
kURSKoBL

Цитата:

это хорошо, так как дев экспресс 14.1.2 как не пытался, так и не смог на XE7 влепить

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

----
А по поводу Castalia -- что там есть такого, чего нет в cnWizards?

Цитата:

I am sorry to announce that WIN32 using clang went on hold as soon as iOS64
became the focus.

Я сожалею, что пришлось отложить использование clang в WIN32, т. к. в нашем фокусе появилась необходимость поддержать iOS64. Вольный конечно же перевод.

Цитата:

Это лень и экономия ресурсов, всего-то лишь.

скорее так и есть


Цитата:

Это вообще нормальный английский? Не большой я специалист по инглиш граммар, но это "as soon as" вообще по смыслу не вяжется.  

нормальный, вяжется

Цитата:

Единственное препятствие для Clang-32 -- это отсутствие реализации SEH на этой платформе.

Я не всё привел, дальше пишут что для вынь32 хотели использовать clang 3.5 а для 64 нужен сейчас 3.3, а для iOS 3.5 не годится, отложили до осени как то так

Цитата:

Я сожалею, что пришлось отложить использование clang в WIN32, т. к. в нашем фокусе появилась необходимость поддержать iOS64.

не "так как", а "когда", вероятно. Такая идиома в у пиндосов, оказывается -- в словаре посмотрел.
---
Они и билдер-64 под вынь не обновляют вроде.
Вот что пишут LLVM девы:

Цитата:

[we] believe that those individuals and organizations will contribute back their work if they do not want to have to maintain a fork forever (which is time consuming and expensive when merges are involved).

Further, nobody makes money on compilers these days, but many people need them to get bigger goals accomplished: it makes sense for everyone to work together

Они видно не предполагали, что Бракодело ни скомиттит свой форк, ни поддерживать его не станет.

---
интересно, а какие форматы символьной отладочной информации поддерживаются под Win32 отладчиком? Только свой? Или может, DWARF или MS PDB?

Вот у меня было: XE6+devexpress 13+fast 4
сейчас поставил XE7+devexpress 14+fast 4

перекомпилировал экзешник своей программы, чтобы внешний вид стал такой же как и был - пришлось убрать все галочки с NativeStyle, я так понимаю в XE7 добавили это свойство и стали всем по умолчанию раздавать?
И второй вопрос. XE6 в Release мой экзешник весил 12.6 мб
После первой перекомпиляции в XE7 стал весить 14мб, после того как я убрал галочки то стал весить 32мб.

даже теперь через 7zip сжимается только до 10мб, раньше до 3.5мб

спрашивается, что это было? Снятие галочек добавило дофига каких-то библиотек в исполняемый файл?

нашёл, среда по умолчанию добавила поддержку скинов. очистил, стало снова 14мб.

AlekXL

Цитата:

Такова фишка натива -- скорость там, где она нужна

Ты, похоже, снова о своем больном... Я бы хоть раз пенял на скорость натива. И про далвик уже можешь забыть, т.к. ART это самый настоящий натив. Абракадабрин аргумент о cpu native более не актуален, причем не только для ведроида т.к. у винфон теперь тоже AOT только на стороне стора.

Цитата:

Цитата:
Судя по топику, видно далеко не всем

Ой ладно! У чела траблы с FMX.. неудивительно. Графическая часть на далвике конечно будет быстрее. А остальная часть -- медленнее, если вообще там скорость имеет значение.

Такова фишка натива -- скорость там, где она нужна

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

Агитировать за переход на JAVA никого не буду. Достаточно попробовать сделать коммерческое приложение чтобы понять возможности инструмента. Приложение со списком на и 1 кнопкой коммерческим не считаю.

Вот основные проблемы, с которыми столкнулся при разработке программы на Delphi:

1. Отсутствие ActionBar, невозможность сделать нормальное меню и навигацию (В JAVA есть по умолчанию). Можно конечно изворачиваться и написать все самому, может быть будет и похоже. "Препятствий" нет никаких

2. "Замечательная" работа листания вкладок. Может кому-то покажется что это и сойдет, у меня другое представление о нормальной работе. В итоге пришлось выносить кнопки листания влево-вправо на верхнюю панель. Как работает листание в JAVA думаю говорить не нужно

3. При маленькой ширине экрана вкладки прячутся и сжимаются пропорционально, на них не видно ничего. Забил, оставил как есть. Как нужно достаточно глянуть любой пример JAVA, SlidingTabs например

4. Глюк с утечкой памяти при создании/удалении окон. Пришлось переделывать всю логику программы + кога создано все что есть возникают артефакты интерфейса. В QC сказали что на 4.4 работает все замечательно, а остальным не повезло

5. Скорость работы визуальной части оставляет желать лучшего.

6. Для списков так и не получилось сделать свою разметку содержимого. В JAVA в качестве разметки можно передать любой Layaout.

В общем больше я на Delphi в мобильном сегменте делать ничего не буду. А под винду считаю одним из лучших инструментов на сегодня

kaz_av


Цитата:

Я бы хоть раз пенял на скорость натива. И про далвик уже можешь забыть, т.к. ART это самый настоящий натив. Абракадабрин аргумент о cpu native более не актуален, причем не только для ведроида т.к. у винфон теперь тоже AOT только на стороне стора

не является нативом фреймворк со сборкой мусора. В мечтах твоих только.

Проблема не в JIT и не в байт-коде(хотя и в них тоже), а в сборщике. Я об этом писал, я заострял на этом внимание. И наглядно показал его слабость в ситуации с ограниченными ресурсами.
Это ты о своем больном.
NickNNN

Цитата:

В общем больше я на Delphi в мобильном сегменте делать ничего не буду

ты сам себе выстрелил в ногу, когда взялся за FMX. Сделал бы броузерный интерфейс, или 100% кастомный.

Цитата:

Приложение со списком на и 1 кнопкой коммерческим не считаю

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

Цитата:

больше я на Delphi в мобильном сегменте делать ничего не буду

..означает лишь, что ничего сложнее средней бизнес-логики на мобиле ты делать не собираешься.
Ибо если бы намеревался Апп высшей лиги, то затраты на интерфейс, повторяюсь, были бы неважны, а преимущества натива -- очевидны.
--
Думается, вскоре рынок насытится такими средними поделиями, которые оптимально делать на Яве. Сложный же софт для мобильника и особенно планшета -- можно писать только на крестах .. или Delphi

AlekXL

Цитата:

не является нативом фреймворк со сборкой мусора.

Наличие сборщика мусора ортогонально понятию натива. Матчасть подтяни.


Цитата:

Проблема не в JIT и не в байт-коде(хотя и в них тоже), а в сборщике.

На колу мочало - начинай сначала. Без меня, на этот раз.

kaz_av

Цитата:

Наличие сборщика мусора ортогонально понятию натива. Матчасть подтяни.

можешь повторять это заклинание. Быстрее от этого GC не станет.
Нативность -- это прежде всего близость к центральному процессору, прямая возможность работать с памятью. Коль этого нет в JAVA и .NET , то и говорить не о чем.
Проблема не в том, что присутствует сборщик, проблема, что сборщику нет альтернативы вэтих языках.


Цитата:

На колу мочало - начинай сначала. Без меня, на этот раз

да уж обойдемся без твоей "евангелизации" и "нефанатизма"