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

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

Модерирует : 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

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

sergionn

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Marco C:
While on iOS Delphi uses the same tricks of the platform tool (Xcode), the situation will be very different on Android. How many tools offer a native solution, with Google pushing application developers towards the Dalvik VM? The Delphi community will have some interesting times ahead.
 
т.е. получается что они все-таки пилят android версию на основе ndk, как и намекал бровин в вебинаре.
Теперь интересно: вот у них есть есть llvm компилер для arm - здесь все почти ok, а как быть с кодегеном для x86 андорида, ведь он 32-битный, а у emb вроде как какие то проблемы с llvm на 32 битах, какие мнения господа?

Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 19:12 29-07-2013 | Исправлено: sergionn, 19:13 29-07-2013
HeMet

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

Цитата:
т.е. получается что они все-таки пилят android версию на основе ndk, как и намекал бровин в вебинаре.

А на чём ещё они должны были пилить, если трубят на каждом углу, что их инструменты генерят код для процессора, а не ВМ?

Цитата:
а как быть с кодегеном для x86 андорида, ведь он 32-битный, а у emb вроде как какие то проблемы с llvm на 32 битах, какие мнения господа?

Где можно прочитать про эти проблемы?

Цитата:
Просто реально, это Эмбе нужно доказывать, что они зачем-то нужны LLVM'у, а не наоборот.

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

Всего записей: 212 | Зарегистр. 05-09-2007 | Отправлено: 19:38 29-07-2013
Arioch1



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Кстати, о финалайзерах... и некоторых идиотских оптимизациях....
 
Как вы думаете, какой великий смысл  
1) финализировать строковые **константы**
2) не инициализировать модули, входящие в BPL, которые используются основным EXE
 
надо будет завтра на XE4u1 проверрить, а пока насладитесь эффектами Xe2u1hf5
 
http://rghost.ru/47754697
 
Добавлено:

Цитата:
они все-таки пилят android версию на основе ndk

кто-то когда-то сомневался? у них были другие варанты? в приемлемый timeframe "пофиксить 10% багой ху4 на айфоне, потом за два месяца написать и зарелизить андроид" ?
 
и ты ещё забыл Android/MIPS
 
Добавлено:

Цитата:
положил бы на доказывание кому-то, что ты не верблюд

 
вот они обоюдно и положили. Вопрос зачем вообще было публиковать остается открытым (впрочем и на вопрос тоже всем положить).
 
а да, кстати, а лицензия-то на эти патчи какая?

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 19:49 29-07-2013
sergionn

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
HeMet, Arioch1
трубят, не трубят, сомневался-не сомневался, не в этом суть, все были домыслы, умозаключения, сейчас есть почти оф.подтверждение, И вопрос в ДРУГОМ:
у емб нет llvm кодегена для x86, а для x64 есть, и вот в чем вопрос:
Мне важно ПРЕДПОЛОЖИТЬ: их решение для андроида будет компилить в нативный x86 для intel atom или нет?

Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 20:07 29-07-2013 | Исправлено: sergionn, 20:18 29-07-2013
HeMet

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

Цитата:
у емб нет llvm кодегена для x86, а для x86 НЕТ, вот в чем вопрос:

Не понял...

Цитата:
Вопрос зачем вообще было публиковать остается открытым (впрочем и на вопрос тоже всем положить).

От них не убудется.

Всего записей: 212 | Зарегистр. 05-09-2007 | Отправлено: 20:20 29-07-2013
sergionn

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

Цитата:
Не понял...  

поправил....
 
А интерес мой связан в связи с этой штуковинной:
_http://hi-tech.mail.ru/review/misc/Lenovo_K900-rev.html
и особенно ее ценой, - похоже, что intel взялся за ум, и демонстрирует реальное стремление,
к завоеванию мобильного рынка, снижением цены на чипы, разработкой РЕАЛЬНо конкруентноспособных процев:
_http://www.3dnews.ru/news/653162, и ведь у Интел мощности то поболее будут, нежели у многих контрактных производителей arm чипов........  
В отличии от ms, которые нюх потеряли конкретно, и пуляют свои ресурсы в совершенно левом направлении,
и даже не планируют снижение цены на свою операционку в долгосрочной перспективе, а не одноразовых акций.....

Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 21:17 29-07-2013 | Исправлено: sergionn, 21:29 29-07-2013
Arioch1



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
до сих пор от них не убывалось только пользоваться чужиМ, а не открывать своё. Непонятно...
 
Проверил на Xe4u1 - вроде в win32 больше константы не убивают.
todo: win64....
 
 
 
Добавлено:

Цитата:
И еще вопрос -- если record , содержащая , скажем, динамический массив, размещается в стеке, то должно ли зануляться ее содержимое? Потому как под XE3 64-bit не зануляется..

 
сделай test case - код, что ты ожидаешь и что наблюдаешь
 
 
Добавлено:

Цитата:
у емб нет llvm кодегена для x86, а для x64 есть

у эмб вообще нет кодегена для llvm
наоборот, они взяли llvm, чтобы не писать свой кодеген, а использовать чужой.
 
по той же причине я не думаю, что в FPC кто-то всерьёх будем заниматься переходом на LLVM. Ибо свой кодеген у них и так етсь и сейчас когда в Delphi туман и брожение им только не хватало себе то же самое устроить, чтобы с Паскаля все окончательно разбежались
 
Вот пример: http://free-pascal-general.1045716.n5.nabble.com/Using-LLVM-with-FPC-td3199368.html
"Ну кто-то занмиался, но мы подумали что у нас есть лучше дела ,чем догонять веечно изменяющийся LLVM"
 
Вот еще пример: http://code.google.com/p/llvm-pascal/
 
Вот ещё суровый сургутский парень решил вызывать компиляторы llvm из Дельфи: https://github.com/runaum
 
Было бы это кому-то надо - давно бы дописали.

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 21:51 29-07-2013
sergionn

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Arioch1
опять куча домыслов, буквоедство, чтение текста под левым углом, видимо чтобы выглядеть умным, но ни капли сути........

Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 00:25 30-07-2013 | Исправлено: sergionn, 00:59 30-07-2013
AlekXL



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

Цитата:
 
по той же причине я не думаю, что в FPC кто-то всерьёх будем заниматься переходом на LLVM.

это верно. Причины же : никто это не оплатит.
 

Цитата:
 
у эмб вообще нет кодегена для llvm
наоборот, они взяли llvm, чтобы не писать свой кодеген, а использовать чужой.  
странно, если бы он был, "Кодеген для LLVM". LLVM и есть кодеген.
 
sergionn

Цитата:
у емб нет llvm кодегена для x86, а для x64 есть

странные умозаключения. Я думаю, когда эмба пилила x64 C++ они взяли не только LLVM, они взяли CLANG целиком, и его кастомизировали. Судя командной строке. Да и язык C++11 многократно сложнее парсить, чем Delphi.
 
Что важнее,  у эмбы уже есть генератор Паскаль->LLVM мета-код. Немного напильника, и LLVM заработает везде.
 
 

Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 01:04 30-07-2013
Arioch1



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
sergionn
на белиберду вообще трудно чем-то конкретным ответить, так что скажи спасибо и на домыслах.
 
AlekXL

Цитата:
странно, если бы он был, "Кодеген для LLVM"

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

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 01:34 30-07-2013
sergionn

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
AlekXL, Arioch1
да причем тут умозкалючения, и белиберда причем тут clang вообще, да запилили они c++ на clang,
да есть у них (и не только у них) pascal->llvm ir, ведь компилируют же армовский релиз на нем!  
Возможно я неправильно выразился, периначу:
Сейчас emb имеет конечно решение по генерации финального arm кода из паскаля, на основе llvm, НО не имеет такового для x86-32, а имеет только для С++ x86-64 через clang. Вопрос:
Поскольку emb делает свое решение не через dalvic-vm, а нативно через ndk, где генерируется непосредственно машинный нативный arm код,
как вы думаете, к моменту выхода Андроида, будет ли у emb решение по
ГЕНЕРАЦИИ нативного кода для Intel Atom x86 для андроида? Т.к. сейчас его нет, видимо потому, что ответил allen bauer на мой вопрос про сроки llvm под win:
 
LLVM is our current go-to solution for the ARM target. It's not without
its own brand of complications, mostly centered around proper debug
information. LLVM generates DWARF debug information, however there is
no standard DWARF mechanism to represent many Delphi specific
items/types. Mainly things like properties, events, variants, strings,
etc... don't have analogs in DWARF. Likewise, building a full-fidelity
debugging solution is a lot of painstaking effort. DWARF allows for
vendor-specific extensions, however that doesn't mean that existing
tooling knows or understands those extensions. All that work has to be
"invented" and produced. It's not as simple as it may seem at first
blush. Sure, we were able to produce ARM code from Delphi in relatively
short order, however the downstream effort is still a large endeavor...
RTL, frameworks, debugging, linking...

Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 01:37 30-07-2013 | Исправлено: sergionn, 01:50 30-07-2013
Arioch1



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

Цитата:
Немного напильника, и LLVM заработает везде.

Немного напильника - это поддержка ABI на платформе (а в Линуксе сборка одних исходников с разными версиями и настройками GCC приведет к разному ABI), поддержка ADP для отладки, поддержка RTL и FMX с учётом всего этого. Плюс три семейства процессоров с множеством вариаций в основно из них. Плюс гораздо больше видеокарт, чем на Wintel. В общем - пилить им до второго пришествия хватит.
 
Добавлено:
Кстати, никтo не пробовал Triple City на андроид смартофнах где памяти не так чтобы очень много? Например Sony WT19i. Игрушка (примитивная в общем, как раз для FMX) периодически выжирала всю память и зависала на пару минут. И хороо если отвисала.
 
Так что что бы там маркетологи не праздновали, у меня осталось сильное впечатление, что NDKшные программы в Андроиде будут как DOSовские в винде. Да, жить будут, но чтобы они жили хорошо и дружелюбно к остальной системе и нативным (для ОС) программам - нужно будет сиииильно постараться. Поживём - увидим, конечно. Вдруг XE5 будет гениальной системой...

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 01:37 30-07-2013
sergionn

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

Цитата:
Плюс три семейства процессоров с множеством вариаций в основно из них.

я так понял что это проблемы llvm..........

Цитата:
Плюс гораздо больше видеокарт, чем на Wintel.

а вот это уже другая история - тут они точно нифига до ума не доведут, придется все свои дополнения делать, а учитывая что весь почти код работы с 3d контекстом спрятан в fmx под implementation - то это почти mission impossible...........

Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 01:43 30-07-2013
Arioch1



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

Цитата:
ак вы думаете, к моменту выхода Андроида, будет ли у emb решение по  ГЕНЕРАЦИИ нативного кода для Intel Atom x86 для андроида?

 
Думаю, что нет. По двум причинам.
 
1) если бы они могли - они бы сделали это не на LLVM, а на старом компиляторе, как для настольно-ноутбучной MacOS 10
2) если бы они могли - им бы начальство сказало "вы хренью не занимайтесь! сколько процентов андроидного рынка у MIPS+Intel вместе? и чтобы получить этот процент вы собираетесь потратить еще год ???" и на этом весь этото проект был бы сразу же убит.
 
Почему они даже для iOS Simulator не сделали LLVM-компилятор?  
А ведь там это было бы и проще и полезнее! но - не сделали.
 
Точно так же если им вдруг моча ударит делать x86/Android, то и делать его надо будет на манер уже отработанного x86/iOS

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 01:53 30-07-2013 | Исправлено: Arioch1, 02:15 30-07-2013
sergionn

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

Цитата:
Точно так же если им вдруг моча ударит делать x86/Android, то и делать его надо будет на манер уже отработанного x86/iOS

так и в чем сложность тут:
для отладочной версии, где у них возникли сложности описанные бауэром, делают на своем, старом неоптимизированном, но быстром компилере,
а для релизной версии - под llvm, все как и в сценарии с ios. Пор моему логично?

Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 02:00 30-07-2013 | Исправлено: sergionn, 02:03 30-07-2013
Arioch1



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

Цитата:
я так понял что это проблемы llvm

кодогенерация - да.
 
А вот создание бинарной отладочной информации, приспособление к незнамо скольким вариациям версий и настроек GC++ (а ядро линукса наскольоко знаю пока clang'ом не собирают) наконец просто сборка и запаковка в apk нескольких разных бинарников под почти одинаковые платформы...  
 
хрен его знает, увидим через пару месяцев, что у них получится
 
Но - за исключением Кайликса - они пока не разу не выходили на базар.
 
Основа - жесткий wintel. Да, новый инструкции, новые интерфейсы - но при жестко заданной и требуемой основе. Ну и результат - появление x64 (ассемблер до сих пор не исправили, надеюсь хоть двойной вызов искючений убрали) и SSE хрен знает когда. А также постоянное отставание от "последних писков моды" Microsoft UI
Далее - Java Builder. Жестко заданный и контролируемый sun'ом рантайм.
Delphi for .Net - жестко заданный .Net 1.x. Перезда на 2.0 не пережила.
Delphi for MacOS - жестко и однообразно контролируемая среда, ещё меньше разнообразия, чем у Wintel. И постоянные жалобы на отставание от X-Code
 
Что осталось ? Kylix. Вот это была попытка делать программы для разношерстного сброда всех красноглазых китайцев планеты. Но только все кто ее делал - уже почти наверняка давно уволились. Кроме того совместимость со стандартными механизмаи была... не на высоте насколько помню. Примерно как "в этом году все обычно делают так - и мы будем так. Что, по правилам надо бы проверить параметры системы и приспособиться к ней или потребовтаь установки нужных библиотек? да ну нафиг, и так сойдет"
 
В общем, за пределами десятка моделей телефонов из белого списка (и максимум трёх версий прошивок для каждого) - будут самые разнообразные глюки который ВСЕ будут убиваться в QC c "can't reproduce"
 
 
Добавлено:

Цитата:
для отладочной версии, ... релизной версии

 
Нет, не так. Повторяю. Раздел идет не по "отладочная/релизная" а по "arm/x86"
Теоретически я допускаю Android x86 на базе dcc32, но практически я тут самый чёрный пессимист.
 
Они с 2009 года не могут сделать в Дельфи рабочих дженериков!  
Они с 2011 года не могут сделать работающий Win64 ассемблер
 
А сейчас им надо вхреначить в старый компилятор все изменения языка, которые они ввели в xe4: строки, Free мутирующий во FreeAndNil и хрен знает, что ещё.  
 
И это будут делать люди, которые в релиз выпускают код (как в документации, так и в RTL) ни разу никем не запускавшийся! За полгода вместо обычного года на разработку новой версии! При полном отсутствии регрессионных тестов (в дженериках XE4 появляются баги, которых не было в XE3)
 
У меня нету цензурных слов, чтобы - если исключить фею с волшебной палочкой - что должно родиться в итоге.
Доживём если до XE7 - будем оптимистами. А пока повода для оптимизма что-то не видно.

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 02:03 30-07-2013
sergionn

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

Цитата:
В общем, за пределами десятка моделей телефонов из белого списка (и максимум трёх версий прошивок для каждого) - будут самые разнообразные глюки который ВСЕ будут убиваться в QC c "can't reproduce"

боюсь ты погорячилcя, будет работать в пределах ЛИЧНЫХ телефонов и планшетов 3-х разработчиков, ведь на ноутах с гибридным видео fmx до сих пор, спустя 3-релиза глючит.....
 
К тому же, разработчики андроида изначально не рекомендуют использовать ndk без особых на то оснований, только если это нельзя сделать на sdk,
эх...........

Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 02:14 30-07-2013 | Исправлено: sergionn, 02:37 30-07-2013
Arioch1



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
вот мой тебе совет. Найди слабенький андроидный телефон - типа wt19i или слабее.
 
найди десяток разных верси triple city от 1.00 и до какая там последняя
 
и поиграйся.
 
Одна игра - не статистика, конечно. Но если я и раньше не очень понимал как будут драться заресурсы (ту же оперативку) дальвик и линукс, то на****сь с зависаниями и вылетами примитивной (как нароочно под FMX) игры (а переключиться в другую программу нельзя - NDK-жных чужеродов Андроид отстреливает не задумываясь и им почти всгда приходится перезапускаться с нуля. Но.... зависшая игрушка себя сохранить не може и будет отстрелена без сохранения состояния)... Вот тут тот случай, что прелести NDK лучше один раз увидеть самому...
 
Уж лучше бы они в win8 лезли imho...
 
Кстати та самая игрушка была на google Play (когда он отличался от маркета) в виде флэш-апплета (и другие игрушки тоже) - работала как часы!

Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 02:20 30-07-2013 | Исправлено: Arioch1, 02:22 30-07-2013
AlekXL



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

Цитата:
Немного напильника - это поддержка ABI на платформе (а в Линуксе сборка одних исходников с разными версиями и настройками GCC приведет к разному ABI), поддержка ADP для отладки, поддержка RTL и FMX с учётом всего этого
это не преувеличение , часом? Конечно, линукс можно собрать множеством способов, но, право же, не думаю, что существует какая-та серьезная бинарная несовместимость. Поддержат RHEL/CentOs,  Debian/Ubuntu - и достаточно.
 

Цитата:
. Плюс гораздо больше видеокарт, чем на Wintel. В общем - пилить им до второго пришествия хватит.  
это проблема драйверов , а не FMX. Должна там быть совместимость, иначе не было бы под эти платформы игрушек.
 

Цитата:
Так что что бы там маркетологи не праздновали, у меня осталось сильное впечатление, что NDKшные программы в Андроиде будут как DOSовские в винде. Да, жить будут, но чтобы они жили хорошо и дружелюбно к остальной системе и нативным (для ОС) программам - нужно будет сиииильно постараться
Это что, далвик считать нативом?! Мы такое не покупаем..
 

Цитата:
а учитывая что весь почти код работы с 3d контекстом спрятан в fmx под implementation - то это почти mission impossible...........
Если пишешь игру, пиши на крестах. FMX - бизнес платформа, там редко когда нужен реальный 3D.
 
 
Цитата:
им бы начальство сказало "вы хренью не занимайтесь! сколько процентов андроидного рынка у MIPS+Intel вместе? и чтобы получить этот процент вы собираетесь потратить еще год ???" и на этом весь этото проект был бы сразу же убит.  
И правильно. Нефиг денюжки на ерунду тратить. Под Intel есть гораздо более совершенная ОС. С кучей программ, и без далвика.
 

Цитата:
Почему они даже для iOS Simulator не сделали LLVM-компилятор?  
А ведь там это было бы и проще и полезнее! но - не сделали.  

потому что не нужно. Симулятор все равно слишком сильно отличается от устройства. Так что полная аутентичность не нужна.
 

Цитата:
Точно так же если им вдруг моча ударит делать x86/Android, то и делать его надо будет на манер уже отработанного x86/iOS
вопрос , если , а главное когда ударит.. Перетаскивать Wintel компилятор под ЛЛВМ -- задача важная, хоть и не первоочередная. Стало быть, когда перетащат, то все, старый Intel компилятор пойдет в утиль везде, на всех платформах.
 

Цитата:
А вот создание бинарной отладочной информации, приспособление к незнамо скольким вариациям версий и настроек GC++ (а ядро линукса наскольоко знаю пока clang'ом не собирают) наконец просто сборка и запаковка в apk нескольких разных бинарников под почти одинаковые платформы...  
 

все это преувеличение. Разве линукс лежащую под андроид собирают c существенно разными настройками? Не думаю. Никому этот гемор с бинарной совместимостью не нужен.
 
 
Цитата:
Но - за исключением Кайликса - они пока не разу не выходили на базар
А древние киликс приложения, говорят, по-прежнему работают на новых системах... Так какого ты пугаешь нас всякой бинарной несовместимостью?

Цитата:
Вдруг XE5 будет гениальной системой...
Мы все понимаем, что таковой она не будет.. Мы лишь надеемся, что она не будет откровенно плохой.
 

Цитата:
А вот создание бинарной отладочной информации, приспособление к незнамо скольким вариациям версий и настроек GC++

а как отладочная инфа соотносится с вариациями GCC? Думаю, никак. С ядром? Полагаю, никак. Отладочная инфа просто помогает интерпретировать дизассемблированный код, его контекст... И большая(системная) часть работы уже сделана за них.  
 

Цитата:
В общем, за пределами десятка моделей телефонов из белого списка (и максимум трёх версий прошивок для каждого) - будут самые разнообразные глюки  
Но это скорее будет характеризовать качества Операционной системы, нежели качества Delphi. Это одна из фундаментальных задач ОС -- обеспечивать абстракцию интерфейсов оборудования.  
 
Хотя, если будет здесь провал, то именно эмба потеряет деньги. Но не думаю, что все так плохо. Андроид нов, но Линукс не нова. Детские болезни в основном должны быть уже преодолены.
 
А, как мы знаем, Дельфи будет по сути игнорировать андроид в телефоне, общаясь напрямую с Линуксом. Совместимость будет, конечно, хуже, чем у так называемых "нативных"приложений, но не очень намного
 
sergionn

Цитата:
для отладочной версии, где у них возникли сложности описанные бауэром, делают на своем, старом неоптимизированном, но быстром компилере,
а для релизной версии - под llvm, все как и в сценарии с ios. Пор моему логично?
с точки зрения менеджера. Не дай Бог, такое будет. Релизы тоже надо отлаживать.
 

Цитата:
Вот тут тот случай, что прелести NDK лучше один раз увидеть самому...  
да, надо посмотреть. Наверное, они сделают java обертку, белую и пушистую, пристрелить которую монитору системы будет не комильфо.. А она возми, да и загрузи нативный контрол, FMX. Мальчик Адрюша в растерянности:"ни богу свечка, ни черту кочерга".
 

Цитата:
Уж лучше бы они в win8 лезли imho...  
там их никто же ждет(M$). И никому эта вынь не нужна.
 
 
 
 
 

Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 04:43 30-07-2013
Arioch1



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

Цитата:
Поддержат RHEL/CentOs,  Debian/Ubuntu - и достаточно.

я в данном случае говорю про Android NDK, а как его какие ромоделы собирают я хз
и даже официалы вполне могут для моделей разного года менять ключи, ifdef'ы и т.д.
 

Цитата:
там их никто же ждет(M$). И никому эта вынь не нужна.

А гугл ну пряяям заждался!
 
Доля 4% и растёт. И ближе к естественному рынку Дельфи. И меньше программ. А вот на гугломаркете придётся оооочень сильно потолкаться локтями. И помогать нам в этом будет Дельфи "не упала и ладно".
 

Цитата:
пристрелить которую монитору системы будет не комильфо

Как раз в 4.3 ввели ещё одну меру борьбы против таких молодых да наглых...
 

Цитата:
Отладочная инфа просто помогает интерпретировать дизассемблированный код, его контекст... И большая(системная) часть работы уже сделана за них.  

Угу, дизассемблированный код... инфа должна определить как в любом месте кода получить доступ к тем или иным локальным переменным или вызвать ту или иную функцию. И все вариации ABI (конвенция вызовов, выравнивание данных) напрямую на том отражаются. При том, что многие фишки Delphi просто не могут быть описаны в "стандартной" информации и требуют расширений.
 

Цитата:
А древние киликс приложения, говорят, по-прежнему работают на новых системах...  

Угу, в виртуальных машинах. Я как раз слышал, что там настолько жёсткие зависимости на старые версии системных библиотек, что на новых оно летает только с бубнами и на одном крыле.
Т.е. в сисадмина, который допиливает линукс, чтобы старая программа продолжала работать, я верю. А в домохозяйку, которая ткнув в кнопку на маркете получает инструкции "получите root, скачайте отсюда системнфый библиотеки, скомпилируйте стакими-то  ключами..." - нет.
 
Впрочем даже если бы Кайликс был лучшей средой 20 века, все равно - это *единственный* их опыт такого рода и он давно в прошлом.
 

Цитата:
Это одна из фундаментальных задач ОС -- обеспечивать абстракцию интерфейсов оборудования.    
Она и обеспечивает - пишите как положено, и Дальвик все запустит. А требовать от Жальвика абстрагирование выходящего на уровень Линукс NDK - это как требовать Дельфи, чтобы она обеспечивала контроль типов у raw pointers.
 

Цитата:
Разве линукс лежащую под андроид собирают c существенно разными настройками?

Хрен его знают. Чистопородный линуксы стараются  разделить ядро и userland. Каждое собирается со своими настройками, но в большинстве сручаев независимо друг от друга. И потому можно (в принципе) запускать одну и ту же систему на разных ядрах и наоборот.
Насколько NDK привязан именно к ядру сказать не могу. Но то, что мне  пока не попадалось сборки драйвера "под официальное ядро" - это факт. Либо люди ухитряются собрать всё ядро сами, либо "берите что дают". В общем, зоопарк андроидов огромен и EMBT хочет выйти за предеы java-песочниццы в реальный и разнообразный мир "bare metal". Не знаю точно что у них получится ,но по крайней мере QC Can't reproduce они могут на отделную кнопку выносить для удобства.
 

Цитата:
Симулятор все равно слишком сильно отличается от устройства.

и потому сделаем яму ещё ширше! правильный подход, чё!
Только что же вас тогда огорчает идея Сергиона о разных компиляторах под Андроид?
 

Цитата:
Это что, далвик считать нативом?

Для железа - нет. Для ОСи - да.
 

Цитата:
 Под Intel есть гораздо более совершенная ОС

QNX ??? *_*
 
 
Добавлено:

Цитата:
Цитата: И еще вопрос -- если record , содержащая , скажем, динамический массив, размещается в стеке, то должно ли зануляться ее содержимое? Потому как под XE3 64-bit не зануляется..    
 
 сделай test case - код, что ты ожидаешь и что наблюдаешь

 
AlekXL ? о чем речь-т ошла, сделай демку plz

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

Страницы: 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

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


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

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru