GSirr Newbie Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: показательно все это однако   Да они просто пропалились с новыми фичами на той странице. У них секретность, типа. Зачем - не понятно. Всего записей: 13 | Зарегистр. 16-12-2006 | Отправлено: 12:47 07-08-2012

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Они сообщают, что портировали весь хелп в docwiki, и отмечают, что не собираются отказываться отказываться от старого способа доставки хелпов. Но указывают, что информация в docwiki будет всегда живой и актуальной.   Так это давно так. Правда не всегда получается.   Например в справке XE2 если открыть справку INDY 10 получаем комплект от delphi 2009 кажется. А оттуда по ссылкам.... Ну, не пробовал, а вот на справку XE (не XE2) местами проваливался.   Добавлено: Цитата: когда я себе личную  страницу редактирую - я делаю это почти единомоментно, - и это моя личная страница,   Вот-вот. Теперь представь что это ещё надо согласовать со всеми. А кто-то в отпуске был. Вернулся.. "а чего это вы тут без меня, а ? Компанию позорите??? убрать! согласовать! переделать! отчитаться! " :-D   Добавлено: PS правильно писали, надо было выкинуть DCC и всерьез уж сесть на FPC Вот чем их гипотетический LLVM'ный компилятор будет лучше ?   NIH syndrome в тяжёлой форме.   Вот хохма будет если FPC чисто ради прикола сделают компиляцию в LLVM и причем раньше Эмбов Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 13:26 07-08-2012 | Исправлено: Arioch1, 13:30 07-08-2012

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arioch1   LLVM вроде бы более наворочен в плане оптимизаций, чем FPC, ну и он не сильно привязан к какому-то языку! Вот Apple через Clang в нем все свои языки (c, c++, objC) компиляет! Вроде бы модульность компилятора позволяет легче делать в среде всякие рефакторинги - типа, парсер может в фоне прямо в среде работать.     Так что я за LLVM + PasLang))   Ну и пора уже выкинуть из RAD Studio все что на J#! Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 15:06 07-08-2012

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору как-то интересно, язык отличный, а поддержки никто дать не может. Как-то это странно.   Язык был отличный для 10-летней давности. А сейчас его дизайн 1949-го года сказывается.   Ни дженериков толком, ни анонимных функций...   Но даже на поддержке старых проектов можно жить достаточно долго и иметь потенциал сильно измениться. Как например никто уже не ждал Юникода или тех же дженериков, и вдруг!.. Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 16:22 07-08-2012

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Не, русский конечно не так развился за 1000 лет ,как английский. В смысле - не до не узнаваемости. Но мы сейчас говорим на сильно другом языке. Примерно как классический Бейсик и Basic.Net И с обратной совместимостью на 1000 лет никто особо не заморачивался. Целые куски языка выкидывали.   ----   Отличный язык можно легко развивать и поддерживать. Если это не получается, значит он уже с червоточинкой. Неплохой, пусть хороший, но на отличный уже не тянет.   "И вы вовсе не величайший из королей, а выдающийся да и только"   Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 17:01 07-08-2012

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Вот хохма будет если FPC чисто ради прикола сделают компиляцию в LLVM и причем раньше Эмбов И кстати, почему хохма?..   http://freepascal.org/future.var   А никто не пытался всерьез с дженериками работать в FPC ?   D2009 они просто были нерабочие, даже примеры из справки не работали...   В XE2 я как только пытаюсь их использовать всерьез, ловлю Internal Errors. Поневоле начинаешь верить слухам о компиляторе с дизассемблированными кусками от конкрентов, в которых никто толком разобраться не может и не хочет.   С 2009 года пилят дженерики, пилят...   Добавлено: Цитата: сравнили c бетой vs 2012   Там про военные действия вспомнили. Мне сразу затёртая цитата Сунь Цзы вспомнилась. Если нечего скрывать - притворись, что скрываешь ого-го что!   А вообще по XE2 говорили, что оченб много патчей. Ещё и Upd5 обещали.   Если у них исторически программисты успевают либо патчить текущую версию, либо делать новую - то что же было ждать от XE3 ? Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 18:34 07-08-2012

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Тут с шапкой непорядок - не отображается на каждой странице! Поправил бы кто нидь, кто знает как)   sergionn   SmartMobileStudio делали не RemObjects, от RO - Oxygene for .NET и for Java. Так что паскаль для Андроида есть)) Это плюс! Но из-за малой популярности еще нет кросс-платформенных библиотек, чтобы работало и на Delphi и на Oxygene Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 19:14 07-08-2012

sergionn Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: SmartMobileStudio делали не RemObjects я этого не писал   Дженерики в xe2 пользую, до перевода проекта с лазаря на xe2, пользовал их и там, все работало без особых проблем......   Добавлено: Цитата: Если нечего скрывать - притворись, что скрываешь ого-го что! такие маркетинговые трюки года 2 назад еще прокатили бы, а щас все, баста - на рынке программных средств выбирай не хочу, такая хрень чревата быстрым закатом системы разработки....... Всего записей: 472 | Зарегистр. 02-11-2011 | Отправлено: 19:53 07-08-2012 | Исправлено: sergionn, 19:56 07-08-2012

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору пока используешь встроенные колекции - тьфы-тьфу-тьфу.   но стоит копнуть spring4D и в их oberloade ForEach добавить свой overloaded Process от generic-класса...   В общем, в пределах своеё библиотеки они отладили, но чут ьглубже и начинается счастье. Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 09:46 08-08-2012

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору sergionn   Действительно, в whats new умилили строки "Готовимся к поддержке Win8": а как ты к ней подготовишьсяЮ, если на WinRT не пустят Desktop приложения? Придется таки отказаться от FMX! В целом, я бы на месте ЭМРО делал бы 2 вещи:   1) компилятор на базе LLVM с фронтэндом Pascal + CLang (для стройки) и все под Win32/64, OSX, iOS, и с прицелом на Android/Linux; также язык должен допускать прозрачное расширение классов ObjC и Java (для Андроида) и интероперабилити (делегаты - блоки и тп);   2) на базе FMX сделал бы отдельно кросс-платформенную RTL (практически, что-то уже есть); кросс-платформенным должен быть слой всяких системных классов (коллекции, потоки - с специфическими платформенными расширениями), слой доступа к данным, сетевые библиотеки, - почти все невизуальное! Ну и рефакторнул бы слой GUI: должен быть выбор для GUI между FMX и нативными для платформы контрольями. FMX хорош для быстрого портирования интерфейса между платформами, но для требовательных приложений (или ограниченных по ресурсам платформ) нужны биндинги к нативным контрольям. ИМхО, нативные контролья очень нужны для iOS, и не могу ничего особо сказать про Android.. А для Win8 особого выбора то и нет - или XAML, или HTML/JS, но никак не FMX. Так что native GUI - наше ВСЕ)) Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 18:16 08-08-2012

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору если такой компилятор пилить, то можно наверное сразу поддержку QT пытаться в язык вставить   И FMX будет не нужна Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 18:46 08-08-2012

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arioch1 HeMet   Поддержка QT не нужна - фактически, для GUI можно сравнить QT с FMX, правда в QT было много всего и для RTL. И FMX, и QT - это эмуляция нативных контрольев на каждой платформе, при этом QT более зрелая эмуляция. QT лучше "мимикрирует" под платформу, правильно запрашивает метрики и шрифты, в отличие от FMX. В любом случае, оба фреймвока рисуют контролья на каждой платформе самостоятельно.   От QT отказались имеено по причине того, что это в любом случае "внешний" фреймвок - и C++, и развивается другой командой, а FMX же свой и весь на паскале!     Проблема в другом - да, на WinRT можно нарисовать фейс через DirectX, и так и собираются делать (см _http://www.thomgerdes.com/2011/12/directx-applications-in-winrt.html ).     Но вот уже при эмулированном UI не получиться развиваться со скоростью платформы. Будут проблемы, как в случае iOS - когда на iphone появился Retina-экран: все приложения на нативных контрольях "автоматически" получили поддержку рендеринга на retina экранах.   Я бы ОЧЕНЬ СРОЧНО добавлял бы к FMX возможность работать с нативными платформами напрямую - использовать контролья, расширять системные классы, передавать делегатов и тп. Нужно ДРУЖИТЬ с платформой.     К сожалению, ЭМРО не смогло сформировать community что.бы обсуждать направления развития продуктов и эта фишка только упоминалась DavidI Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 11:20 09-08-2012

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Они с CLX так сделали Нет. Они не сделали поддержку QT в языке, а сделали набор классов-переходинков. Те же events остались по одному обработчику на каждое, вместо 1 publisher - many subscribers   Впрочем, вроде бы QT даже в C++ не влезает, пришлось пре-процессор делать.   Также и с ObjC вроде бы. FPC язык дорабатывает дял прямого использования, а EMB делает классы-обёртки.   Цитата: а FMX же свой и весь на паскале!   Ну да, для текущего компилятора - наверное. Но если новый делать с переработкой языка без ограничений текущего - то FMX тогда костыли для уже здорового человека.   Цитата: правда в QT было много всего и для RTL Именно. Кроссплатформные библиотеки нужны не только GUI Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 11:39 09-08-2012

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arioch1   Что мешает доработать язык Delphi? Мне очень нравятся директивы FPC по поводу диалектов языка - выглядит вполне логично платформенно-зависимый код писать на платформенном диалекте языка!     Цитата:  если новый делать     Боюсь новый компилятор делать будут, стараясь обеспечить полную совместимость с текущим языком. Разумным подходом был бы подход, аналогичный Apple: оставить в среде неколько компиляторов. Например, текущий компилятор будет компилировать все legacy приложения VCL для Win32/64. А для FMX сделать LLVM компилятор с языковыми расширениями для платформ (iOS, Android, OSX, Linux).   Цитата: Кроссплатформные библиотеки нужны не только GUI   У меня более категоричный взгляд - кроссплатформенные GUI-библиотеки ПОЧТИ НЕ НУЖНЫ, а нужны только non-visual библиотеки (потоки, БД, обработка данных XML/JSON/..., сетевые протоколы, object persistence ...). Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 11:49 09-08-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 XE3

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование