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

kaz_av


Цитата:

Кстати, один товарищь в жиплюсе сказал, что GC там (для cpu native) можно отключать.

ну вот, сразу моё весеннее обострение смягчилось

Цитата:

Вот так же и борланд, наверное, думал, когда пилил свой шарп-билдер. Где теперь этот шарп-билдер и где теперь борланд. Помянем.

не передергивай. Борланд сдох, потому что начал вбухивать бабло незнай во что, типа, покупая левые компании.
Шарпбилдер -- идея конечно, рискованная, и не очень умная, учитывая, что Delphi тогда еще котировался высоко. Умнее было бы Delphi for Java.

Цитата:

Не пойму, причём тут RO

притом, что она облизывается на Delphi community, заманивает, флиртует, но что она мне как Delphi разработчику может предложить?

Цитата:

Глупо копировать все подводные камни и костыли разросшегося монстра, и тем самым попасть в прямую зависимость от другого вендора.

лучше быть сытым, чем голодным
лучше жить в мире, чем в злобе,
лучше быть нужным, чем свободным
..а дальше вы знаете.
Притом, обязательно ли копировать? Может, хватит ума украсть? Но даже копия лучше карикатуры.


Цитата:

а вот относительно других платформ, поддержка предлагаемая дельфями есть суть отсутствие поддержки

если вы о не Win платформе для Delphi -- то конечно, начинать что-то таргетируя лишь на Андроид, или лишь на МакОсь -- это риск, не знаю, оправданный ли.
Но связываться с RemObjects Oxygene -- еще больший риск.

AlekXL

Цитата:

Шарпбилдер -- идея конечно, рискованная, и не очень умная, учитывая, что Delphi тогда еще котировался высоко

Она не просто рискованная, она идиотская. Пытаться конкурировать с владельцым языка и платформы, играя, при этом, на его поле и по его правилам.

Цитата:

но что она мне как Delphi разработчику может предложить?

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

Цитата:

ачинать что-то таргетируя лишь на Андроид, или лишь на МакОсь -- это риск, не знаю, оправданный ли.

При всей моей любви к дельфям, я не буду писать на ней под что-то кроме винды (по крайней мере до тех пор, когда это можно будет делать по человечески и приложения не будут выглядеть странными уродцами)

Цитата:

Но связываться с RemObjects Oxygene -- еще больший риск.

С паскалем вообще связываться рискованно, язык-то не популярный. Однако, сам по себе Oxygene весьма и весьма интересная штука.

kaz_av

Цитата:

Лучший, как они считают, диалект языка

вопрос, сколько помимо них так считают.

Цитата:

Нельзя сделать что-то лучше сохранив совместимость.

не скажи. Вот, гляди в Википедии(Delphi -ЯП) есть раздел Критика , — в которой первым пунктом идет проблема локальных переменных. Там пример крестовый, и, внезапно "PascalABC".
Так вот, синтаксис на этом диалекте, за исключением for/foreach может быть один в один слизан в Delphi без ломки совместимости, как и многое другое в том диалекте.
Покажи, кого нужно убить в Абракадабре за такое нововведения, — и не только я, но и ты сам пойдешь на мокрое.

Цитата:

Если всё делать как в дельфях, то это и получится вторая дельфя, а это как раз и будет история с шарп-билдером

Вот только Delphi — не Шарп, а Абра — не Микрософт.
У последнего и более здравые руководители программных подразделений, и программисты почти не криворукие, и ресурсов валом. Шансы у РО против Абры ненулевые, особенно если взять на борт FPC, её RTL+ LCL, добавив свою интеграцию с VS и с отладчиком, плюс саппорт — что важно для компаний.
В отличие от M$ у Абры не хватает сил окучить всю Delphi поляну, как мне кажется.

Цитата:

При всей моей любви к дельфям, я не буду писать на ней под что-то кроме винды

ну или порта с винды, не так ли?

Цитата:

С паскалем вообще связываться рискованно, язык-то не популярный. Однако, сам по себе Oxygene весьма и весьма интересная штука.

Интерес убивает GC. Языков с ним — вагон, в этой нише нечего делать, если только ты не распространяешь это бесплатно.
Даже у того же PascalABC я вижу больше шансов, — хотя бы потому, что у них открыт компилятор(да вообще вроде всё открыто)

AlekXL

Цитата:

вопрос, сколько помимо них так считают.

Объективно, язык более мощный нежели Delphi. Будь у RO собственная VCL, дельфу можно было бы выносить.

Цитата:

Так вот, синтаксис на этом диалекте, за исключением for/foreach может быть один в один слизан в Delphi без ломки совместимости, как и многое другое в том диалекте

Поддерживать несколько вариантов синтаксиса? Это будет не язык, а ужас-ужас.

Цитата:

Вот только Delphi — не Шарп, а Абра — не Микрософт

Это не важно, финал будт одининаковым. Любая новая фича не будет использоваться пользователями, т.к. это приведет к потере совместимости их кода. В свою очередь вендор дельфей может предложить альтернативный путь реализации некой уже реализованной в "лучшей дельфе" фичи и тем самым снова лишить её совместимости. Вот кому в здравом уме такая радость нужна? Поэтому копирование диалекта это тупиковый путь.

Цитата:

особенно если взять на борт FPC, её RTL+ LCL

А смысл? Язык-то всё равно другой.

Цитата:

ну или порта с винды, не так ли?

Порт дельфийского приложения с винды можно сделать только в том случае, если приложение портируется на OS X и использует FMX. Последний пункт меня совершенно не устраивает по причине качества.

Цитата:

Интерес убивает GC

Если на целевой платформе используется тот или иной способ автоматического управления памятью, стоит ли пытаться с этим бороться? Ради чего? На ведроиде (+JVM/DalvikVM/.NET) GC, на какаве ARC и RO спокойно задействует родные для платформы механизмы. Каким GC будет на cpu native ещё не понятно (вроде бы, это будет консервативный Boehm GC, который делали для C++. Кстати в стандарт C++ уже включён GC), но уже известно, что им можно будет рулить.

Цитата:

Даже у того же PascalABC я вижу больше шансов

Компилятор, сам по себе, никому не нужен. У ABC есть только интеграция с дотнетом, чем может похвастаться не одна сотня языков, да программы учебного курса, вот тут он и живёт.

kaz_av

Цитата:

Объективно, язык более мощный нежели Delphi

Дорогой друг, я вам наверное уже надоел, но какая нахер мощь может быть у языка со stop-the-world заиканием-мусоросборкой, с двухкратным потреблением памяти по сравнению с ручным управлением памятью? Вся эта мощь на ноль помножена! И оттого неинтересна.

Цитата:

Будь у RO собственная VCL

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

Цитата:

Это не важно, финал будт одининаковым. Любая новая фича не будет использоваться пользователями, т.к. это приведет к потере совместимости их кода. В свою очередь вендор дельфей может предложить альтернативный путь реализации некой уже реализованной в "лучшей дельфе" фичи и тем самым снова лишить её совместимости

Необязательно. Взгляните на интел: при разработке.64 -разрядного набора инструкций они унизились до копирования дизайна АМД, причем войдя к ней в патентную зависимость..
Потому что не копировать надо, а красть!
И разве помешал АМД их самопальный непризнанный 3DNow и т.п.?

Цитата:

на какаве ARC и RO спокойно задействует родные для платформы механизмы.

ну еще бы. Пупок у них развяжется запилить свой сборщик и подружить его с местным арк.
И выходит, что сам язык - разный на разных платформах, а это грех непростительный, поскольку умаляет ценность моего кода!
Чтобы избежать подобного, мы просто не используем сборщик - куски нашего кода могут работать хоть микроконтроллере, хоть в ОС реального времени, хоть на ПК.

Цитата:

Компилятор, сам по себе, никому не нужен.

а кому нужен бедный тулсет от вендора 3-го эшелона, притом платный и закрытый?

Цитата:

чем может похвастаться не одна сотня языков,

Львиная доля из к-х сишноподобные, а остальные инопланетянские до оторопи.
Моя мысль: существует огромная, неосознанно востребованная ниша паскалеподобных языков.

Вы думаете, что оксиджен живет благодаря своей "мощи", а я полагаю - это отголосок сильной потребности в паскалевидном языке и в незаполненности этой ниши. Оксиджен любят по принципу - «кому и кобыла невеста».
Вы говорите нужны фишки и отличия в языке, а я говорю это фрагментация и сектантство, а целостность и совместимость важнее.

Добавлено:

Цитата:

консервативный Boehm GC, который делали для C++.

Есть что достойно почитать об этом?

AlekXL

Цитата:

Дорогой друг, я вам наверное уже надоел, но какая нахер мощь может быть у языка со stop-the-world заиканием-мусоросборкой

Во-первых, мощь языка ортогональна использованию или не использованию GC. Во-вторых, у элементов нет GC, например, на какаве. В-третьих, на платформах с GC не использовать GC... маразм. Что будет в цпу-нативе ещё посмотрим, сейчасоб этом говорить преждевременно.

Цитата:

VCL - уникальна. И почему то никому не приходит в голову ее повторить.

Отчего же... Есть LCL, есть Qt.

Цитата:

Кстати, а оксиджене есть динамические методы с диспетчеризацией по номеру

Не распарсил.

Цитата:

Взгляните на интел: при разработке.64 -разрядного набора инструкций они унизились до копирования дизайна АМД, причем войдя к ней в патентную зависимость..

При том, что AMD сама была лицензиатом штеуда по части x86

Цитата:

Потому что не копировать надо, а красть!

Я не понимаю этого тезиса. Ну, допустим, "урали" диалект, дальше-то что с ним делать, как развивать?

Цитата:

И разве помешал АМД их самопальный непризнанный 3DNow и т.п.?

А разве помог? Видимо хорошо помог, коли от него избавились сократив до пары инструкций. Кроме того, у AMD не то положение, которое позволяло бы приводить её в пример.

Цитата:

Пупок у них развяжется запилить свой сборщик и подружить его с местным арк.

Ничего сложного в этом нет (например, FPC обеспечивает работу с указателями на, вполне себе, управляемой JVM). А вот со своим уставом лезть в чужой монастырь не правильно. У RO цель - обеспечение бесшовной интеграции с целевой платформой, поэтому и решения соответствующие. И это, кстати, их огромный плюс.

Цитата:

И выходит, что сам язык - разный на разных платформах, а это грех непростительный, поскольку умаляет ценность моего кода!

Это не так. По части модификаторов хранения (strong, weak, unretained), которые нужны для Cocoa, проблем вообще нет, т.к. на платформах с GC они ни на что не влияют и просто игнорируются.

Цитата:

а кому нужен бедный тулсет от вендора 3-го эшелона, притом платный и закрытый?

У RO кроме компиляторов есть ещё и свои инструменты доступа к БД и организации трехзвенки. Но главная их идея это бесшовная интеграция с целевой платформой, чего нет ни у одного из известных мне инструментов.

Цитата:

существует огромная, неосознанно востребованная ниша паскалеподобных языков

Миром правит мода. Паскаль не в моде, увы.

Цитата:

Вы думаете, что оксиджен живет благодаря своей "мощи"

Нет, я думаю, что элементы интересны, в первую очередь, благодаря возможности бесшовной интеграции с целевой платформой.

kaz_av



Цитата:

Во-первых, мощь языка ортогональна использованию или не использованию GC.

то есть языки нейтральны в этом отношении? Лукавите. В Яве нет средств для управления памятью, стало быть "у кошки одна дорожка"


Цитата:

При том, что AMD сама была лицензиатом штеуда по части x86

тем более! Из копиката превратиться в пример для подражания(это я AMD64).

Цитата:

А разве помог? Видимо хорошо помог, коли от него избавились сократив до пары инструкций

в своё время — быть может. 3DNow был для маркетинга больше. Главное — не повредил.

Цитата:

AMD не то положение, которое позволяло бы приводить её в пример

у АМД всё еще есть вагон патентов, долгосрочные заказы, и редкие спецы. То, что они просрали своё преимущество не иллюстративно.

Цитата:

Я не понимаю этого тезиса. Ну, допустим, "украли" диалект, дальше-то что с ним делать, как развивать?

Развивать язык так, чтобы это считалось новым стандартом, совместимым с прошлыми. Чтобы глупости вроде 0-based strings на одной платформе, 1-based на другой показались ересью.
Чтобы показать уродство сишных атрибутов, дав в дополнение соответстующий паскалю стиль..
Мало ли глупостей делает абракадабра?

Может, даже внешний компилятор для Delphi сделать, и конкурирующие обновления и фиксы для VCL/RTL/FMX, чтобы снять с крючка Абры юзеров на подписке. Чем не бизнес-план?


Цитата:

В-третьих, на платформах с GC не использовать GC... маразм

вы видите тысячу платформ, — я вижу всего две: WinApi/COM плюс POSIX/гнусь. Оно везде — в ведре, айОс или OpenWRT.
Нету платформ с ГЦ, есть свистоперделки на ГЦ, под капотом у которых один кун Кресты.
Работаешь с текстом? Работай с ICU или Uniscribe, на крестах оба. С сетью -- сишные юниксовые сокеты или WSA. Потоки -- тоже низкоуровневое всё в 2 вариантах всего. На экране либо GDI либо OpenGL. Про файловые операции промолчу.

Далее, много ли библиотек вы знаете на управляемых языках, способных с легкостью отхерачить на дисплее милллион элементов, как VirtualTreeView? Или худо-бедно, но нарисовать HTML, как это делает THmlViewer, причем потребляет при этом очень мало ресурсов? И не увидите. Со сброрщиком всё в два раза дороже.


Цитата:

элементы интересны, в первую очередь, благодаря возможности бесшовной интеграции с целевой платформой

шов с платформой есть всегда. Будь то WinApi, или JWM. Тут твоё, там чужое. Тут ты хозяин, там — гость.

Знаете, где реально нужна бесшовная интеграция? С крестоЛибами, ибо всё интересное, сложное и важное — на крестах. Я под Вынью билдером собираю PCRE и SQLIte и подобные, чтобы иметь общий менеджер памяти и при нужде по F7 перейти из паскаля сразу в кресты и посмотреть, что там творится.

Я не могу войти в АндроДалвик, да если бы и мог, не могу там ничего изменить. А вот склеится с крестовым кодом, на котором написано без малого весь фундамент, и почти всё интересное — я должен мочь.
Если мой инструмент впердоливает сборку мусора, и отказаться нельзя, то какая там бесшовная интеграция с крестами — там будет трэш, угар, и остальное.

Цитата:

Это не так. По части модификаторов хранения (strong, weak, unretained), которые нужны для Cocoa, проблем вообще нет

<устало> иногда нужен просто указатель. На кусок строки, на буфер. Немного чёрной магии ради скорости и for the greater good.
Не можем от этого отказаться.

Цитата:

Миром правит мода. Паскаль не в моде, увы.

иногда спроса нет потому, что нет и предложения.

Цитата:

А вот со своим уставом лезть в чужой монастырь не правильно. У RO цель - обеспечение бесшовной интеграции с целевой платформой, поэтому и решения соответствующие. И это, кстати, их огромный плюс

Я так не считаю. В нише JVM Ява занимает 100% пространства. Паскалю так особо ничего не светит. То же с .NET
А вот ниша натива почти пуста. Кресты — это хардкор для избранных.

Цитата:

Отчего же... Есть LCL, есть Qt.

ЛКЛ недопилен.
А вот QT — но где же тогда его экосистема? Где тучи компонент, библиотек, и всего, чем изобилует VCL даже сейчас.

Добавлено:

Цитата:

Но главная их идея это бесшовная интеграция с целевой платформой, чего нет ни у одного из известных мне инструментов.

мне не очень важно, как инструмент подстраивается под платформу. Мне важно, как инструмент подстраивается под меня. Ибо Я, программист, больше и важнее Платформы.

Соглашусь с AlekXL, если у языка нету опенсорсного компилятора и рантайма, пусть даже немного недопиленного, то в топку такой язык. Никогда точно нельзя угадать, сколько будет жить твой проект, но может статься, что и 20 лет протянет. А если РО загнутся уже через год? Что потом всю жизнь жить с компилятором, последняя версия которого выпущена два десятка лет назад и нет возможности пофиксить ни один баг?

AlekXL

Цитата:

В Яве нет средств для управления памятью, стало быть "у кошки одна дорожка"

Модель управления памятью не влияет на выразительные возможности языка. Так понятнее? К слову сказать, в языках с ручным управлением памяти реализовать, например, полноценные замыкания невозможно.

Цитата:

тем более! Из копиката превратиться в пример для подражания(это я AMD64)

Ну так что с того? Где сейчас AMD?

Цитата:

Главное — не повредил

Производители софта просто положили болт на поддержку маргинального набора инструкций. Вот тоже самое будет и со второй дельфёй с её фичами.

Цитата:

у АМД всё еще есть вагон патентов, долгосрочные заказы, и редкие спецы. То, что они просрали своё преимущество не иллюстративно

Не менее иллюстративно, чем факт лицензирования amd64 штеуду.

Цитата:

Развивать язык так, чтобы это считалось новым стандартом, совместимым с прошлыми. Чтобы глупости вроде 0-based strings на одной платформе, 1-based на другой показались ересью

Чтобы это считалось... Самому-то не смешно? Делать-то что нужно, конкретно?

Цитата:

Может, даже внешний компилятор для Delphi сделать, и конкурирующие обновления и фиксы для VCL/RTL/FMX, чтобы снять с крючка Абры юзеров на подписке. Чем не бизнес-план?

Тоесть клиент должен приобрести дельфу, чтобы иметь право пользоваться VCL/RTL/FMX, а потом ещё прикупить и внешний компилятор с набором патчей-улучшайзеров? Ты серьезно, что-ли? Нет, ТЫ СЕРЬЁЗНО???

Цитата:

вы видите тысячу платформ, — я вижу всего две: WinApi/COM плюс POSIX/гнусь. Оно везде — в ведре, айОс или OpenWRT

В ведре платформа - jvm-based, что лежит уровнем ниже никого не интересует, т.к. API системы жабское. Нравится тебе или нет, но это так. Какава тоже далеко не голый позикс, и имеет свои особенности для взаимодействия (поэтому у FPC есть для неё отдельное расширение диалекта, а в дельфях предлагается с тучей врапперов плясать).

Цитата:

Далее, много ли библиотек вы знаете на управляемых языках, способных с легкостью отхерачить на дисплее милллион элементов, как VirtualTreeView? Или худо-бедно, но нарисовать HTML, как это делает THmlViewer, причем потребляет при этом очень мало ресурсов? И не увидите. Со сброрщиком всё в два раза дороже.

Виртуальные списки потому и могут отобразить миллионы элементов, что они виртуальные. Даже в демках для WPF есть виртуальные списки. Не бином ньютона, совсем. При том, что сам WPF это лютый мегатормоз, но дело там вовсе не в GC, а в overdesign. Ну и рендер HTML тоже имеется. Я недавно узнал, что, оказывается, известный редактор векторной графики Inkscape (которым я, кстати сказать, с удовольствием пользуюсь), работающий под суровым позиксом, использующий суровую GTK и написанный на суровых сях, использует GC, тот самый Boehm GC.

Цитата:

шов с платформой есть всегда. Будь то WinApi, или JWM. Тут твоё, там чужое. Тут ты хозяин, там — гость.

Как раз нет. У языков позволяющих интегрироваться с платформой никакого разделения нет. Например, когда у дельфей был собственный .NET компилятор, она имела прекрасную бесшовную интеграцию с фреймвоком. Небыло разделения вот это дельфийские объекты, а это объекты фреймвока.

Цитата:

Если мой инструмент впердоливает сборку мусора, и отказаться нельзя, то какая там бесшовная интеграция с крестами — там будет трэш, угар, и остальное.

Бесшовная интеграция с крестами, есть только у крестов, да и то не у всех Ну правда, смешно говорить об интергации, когда вся интергация это обмен указателями да перекидывание raw bytes. И у дельфей, без жасного GC, нет никакой интеграции с крестами. C API это не интеграция, это на безрыбье и этому рады.

Цитата:

иногда нужен просто указатель. На кусок строки, на буфер. Немного чёрной магии ради скорости и for the greater good

И что, GC не позволяет иметь указатели?

Цитата:

иногда спроса нет потому, что нет и предложения

Чего же тогда с дельфей убежала куча народа в эти ваши жабы и шарпы, предложение, вроде, всегда было?

Цитата:

В нише JVM Ява занимает 100% пространства. Паскалю так особо ничего не светит. То же с .NET

JVM, как и .NET это платформы, пусть даже со своими флагманскими языками. Считать, что туда путь закрыт просто глупо, ибо означает добровольный отказ от огромного рынка.

Цитата:

ЛКЛ недопилен.

Уж в плане поддержки платформ заткнёт за пояс пару-тройку VCL.

Цитата:

А вот QT — но где же тогда его экосистема? Где тучи компонент, библиотек, и всего, чем изобилует VCL даже сейчас

Аналогично и с Qt. Кстати, для Qt есть и библиотеки и "компоненты", в том числе коммерческие. К слову сказать, плюсы с Qt это сейчас дельфя для сишников.

Цитата:

мне не очень важно, как инструмент подстраивается под платформу. Мне важно, как инструмент подстраивается под меня

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

Цитата:

Соглашусь с AlekXL, если у языка нету опенсорсного компилятора и рантайма, пусть даже немного недопиленного, то в топку такой язык.

У дельфей есть? Что? FPC? Не нужно так шутить.

kaz_av
Тем не менее, в случае смерти Эмбы, вполне реально силами небольшой команды адаптировать делфевый RTL под FPC, и подправить сам компиль, если чего не хватает.
А вот что делать, если внезапно загнется РО? Ладно с ихнего Swift с C#-ом еще есть куда соскочить. А вот для ихнего Oxygene я что то вообще никакой замены не могу вспомнить. Если пилить тот же FPC, то работы будет очень много.

Есть ли какой декомпилятор dcp файлов, я так понимаю из них можно вытащить все юниты (хедеры) фактически в текстовом виде как они были если компонент не имеет исходников, например... Нашел какой-то, но очень древний, естественно он не понимает новые файлы.

Frodo_Torbins
Не нужно себя обманывать. Было бы всё так просто, FPC давно бы уже умел собирать весь дельфийский код. А там проблем... Начиная от условной компиляции и неадекватных сообщений об ошибках, и заканчивая отсутсвием поддержки некоторых возможностей дельфей. И это только в компиляторе, про RTL и LCL можно вообще не говорить.


Цитата:

А вот что делать, если внезапно загнется РО?

Что сделал борланд, когда решил закопать интербейз? Вот-вот.

Sulphide

Цитата:

Есть ли какой декомпилятор dcp файлов, я так понимаю из них можно вытащить все юниты (хедеры) фактически в текстовом виде как они были если компонент не имеет исходников, например

dcu32int потрошит dcu.. DCP-врядли это возможно. А что нашли?
kaz_av


Цитата:

Не нужно себя обманывать. Было бы всё так просто, FPC давно бы уже умел собирать весь дельфийский код. А там проблем... Начиная от условной компиляции и неадекватных сообщений об ошибках, и заканчивая отсутсвием поддержки некоторых возможностей дельфей. И это только в компиляторе, про RTL и LCL можно вообще не говорить.

мне это кажется, или вы топите FPC, и продвигаете Oxygene?
Так или иначе, свой код, пусть с грехом пополам, я под FPC портировать могу. С оксидженом ситуация не просто хуже, она — никакая. Потому — у меня нет на него времени, сорри.

Цитата:

Кстати, для Qt есть и библиотеки и "компоненты", в том числе коммерческие

покажете? Мне хотелось бы и форум Кутистов русскоязычный и англоязычный увидеть(оба). Такой, чтоб там старожилы тусувались, вроде нашего.
--
ладно уважаемый. Мы друг друга, думаю, поняли, и разошлись несогласными. Пожалуй. достаточно.

Цитата:

DCP-врядли это возможно

В хэлпе, тем не менее:
Usage:
DCU32INT <Source file> <Flags> [<Destination file>]
Source file - DCU(DPU,DCUIL) or Package (DCP,DCPIL) file

DmitryKz


Цитата:

В хэлпе, тем не менее:
Usage:
DCU32INT <Source file> <Flags> [<Destination file>]
Source file - DCU(DPU,DCUIL) or Package (DCP,DCPIL) file

попался я, соврамши.
Sulphide

Цитата:

естественно он не понимает новые файлы

так dcu32int с исходниками. Там скорей всего пару строк поправить с номером версии. Если сумеете, в теме здесь отпишитесь.
на гитхабе https://github.com/rfrezino/DCU32INT
там вроде есть Seatle x32

AlekXL

Цитата:

мне это кажется, или вы топите FPC, и продвигаете Oxygene?

Кажется

Цитата:

Мне хотелось бы и форум Кутистов русскоязычный и англоязычный увидеть(оба).

Писал бы я на сях с кутями, наверное и показал бы На официальном сайте, впрочем, есть форум. И коммерческие компоненты под Qt. Ну а если опенсурса нужно, то можно на гитхабе поискать * for Qt.

Цитата:

так dcu32int с исходниками. Там скорей всего пару строк поправить с номером версии. Если сумеете, в теме здесь отпишитесь.
на гитхабе https://github.com/rfrezino/DCU32INT
там вроде есть Seatle x32
 

На этот я не напарывался. Отлично! Спасибо! То что доктор прописал! Конечно в том, что оно выдает руками надо будет допиливать многое, но всяко лучше чем с ноля. Типы и константы по крайней мере вообще отлично восстанавливает. Вроде ничего не надо править. Он отлично кушает даже берлинские dcp'шки. Мне просто лень руками сишные хедеры ffmpeg переводить на паскаль. Да и нюансы там есть разные. А в delphiffmpeg один китайский человек уже все перевел и все рабочее. У него есть бесплатные юниты на сайте, но они от 2.6.4 вроде ffmpeg (текущая аж 3.0.2), а учитывая, что ffmpeg жестоко ломает апи с каждым даже минорным релизом, проверять и править кучу хедеров вручную - ломает уже меня. Хотя все равно придется, но некоторые вещи можно будет просто скопипастить. )

приветствую товарищи, доброе утро.
Есть некоторая непонятка с IDE, причем практически во всех версиях, что у меня стояли начиная с XE (сейчас XE7 стоит)

На больших проектах начинает сильно тормозить IDE спустя некоторое время. Грузит полностью одно ядро и потребление процесса оперативной памяти начинает очень быстро расти примерно до 1 гига.
Причем если убрать поддержку Inline функций, то начинает тормозить все несколько позже.
Как я понимаю, глючит вероятно какой-то пакет с компонентами, но не знаю как найти виновника.
Либо есть какая то проверка по используемым модулям внутри проекта.
В больших проектах все пакеты с компонентами нужны, а в маленьких проектах глюки никак не проявляются и IDE работает днями.

Из компонентов стоит достаточно много: девки, даки различные, фастрепорт, kbm, ems import и export, realthinclient, cnpack, eurekalog, imageen и все стандартные от среды.
FileMon в моменты тормозов показывает, что среда лазит по всем компонентам (точнее по всем файлам pas) и что-то делает.

Cryogen2003

Тормоза IDE в большом проекте я тоже испытывал, что был у меня Delphi 6, что XE7. Боролся так, что закрывал все модули и работал только в одном, изменяемом.
Думается, что когда меняется код программы, среда (т.е. IDE) пытается все пересобрать, для выявления связей, типов, классов и т.д. и т.п. Вот и получается, чем больше открыто модулей, тем дольше идет обработка.

Cryogen2003
IDE Fix Pack с ускорителем компилятора стоит? Если стоит, то попробуйте убрать/отключить ускоритель, а если не стоит, то поставьте. Также стоит попробовать отключить дистилером .NET вместе с рефакторингами и проверкой синтаксиса.
Еще погоняйте свой проект в триалке Сиэтла или Берлина, они на 64-битной оси могут использовать 4 гига оперативки.

Frodo_Torbins
IDE Fix pack да, стоит. Ускоритель отключен насколько я помню. То есть пробовать тупо включить или выключить для получения результата?


Цитата:

Также стоит попробовать отключить дистилером .NET вместе с рефакторингами и проверкой синтаксиса

Это как? Не совсем понял? Возможно это мне точно надо сделать, сейчас опять начала тормозить сильно среда, и в FileMon в огромных количествах появлялись файлики NET.

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

Добавлено:
jhtiger
Я это понимаю, но как сделать так, чтобы она поменьше лазила везде. Модулей в двух моих проектах только своих 500+, а еще ведь компоненты используются

Cryogen2003
Сейчас не могу проверить, но XE7 Distiller должен уметь отключать функционал, который реализован на .NET. То есть встроенный в среду рефакторинг и проверку синтаксиса вы при этом потеряете, возможно что то еще.

Frodo_Torbins
Спасибо, попробую. Реально уже тормоза достали

Cryogen2003

Цитата:

В больших проектах все пакеты с компонентами нужны, а в маленьких проектах глюки никак не проявляются и IDE работает днями.

отключите Error Insight:
главное меню->Tools->Options->Editor Options->Code Insight

AlekXL
Спасибо, так же завтра это попробую

Cryogen2003

Если проект состоит из большого числа файлов, то я закрывал все и оставлял только тот pas файл (т.е. форму), которую разрабатывал. Так IDE не пытается все открытые формы (pas файлы) перекомпилить(проанализировать). Если стоит Castalia, то тоже будут тормоза на больших проектах.

jhtiger
Castalia давно снес, сейчас стоит взамен её CnPack. Да, скобочка у операторов тоже есть, но она вроде быстрее работает и без скобочек и выделением операторов и переменных бывает очень слонжо

AlekXL
В code insight удалил Error insight. Да, иногда не хватает, чтобы ошибки подсвечивал.
Все остальное вроде нужно, хотя могу ошибаться.
Как бы приятно, когда автоматически заканчивает код или предлагает на выбор дописать по Ctrl + Space и из-за этого остальное не отключил.
Можешь подсказать, что из этого за что отвечает


Добавлено:
Frodo_Torbins
Запустил XE7 Distiller. Вроде стало поприятнее, как убрал галочки с андроида, os x и FMX вещей. Решил что все это включу, как понадобится . Иногда чего-то делаю под робота, но это не так часто бывает.

Что еще можно отключить и для чего это нужно вообще. К сожалению попробовал погуглить, ничего нормального в виде ответов не нашел
Вот что сейчас у меня есть:

Если Андроид отключили, то GDB вам, по идее, тоже не нужен. И поищите галочку "Don't load additional .NET crap", я ее имел ввиду.
Кстати Делфи можно запускать с разными наборами настроек, за это отвечает ключ "-r". То есть можно создать на рабочем столе ярлычок для запуска Делфи с настройками для Андроида, и второй с настройками для работы.

Cryogen2003

Цитата:

Все остальное вроде нужно, хотя могу ошибаться.

Я бы отключил шаблоны "Code template completion" и может "help insight". Шаблоны имхо бесполезны, а всплывающая справка редко нужна.
Evaluation необходим, иначе при отладке исчезнут подсказки со значениями.
Сивол инсайт иногда полезен, покажет в подсказке, где идентификатор определен, но нечасто это нужно. Обычно просто переходишь к определению.О
Остальное не так влияет на скорость.

Цитата:

Да, иногда не хватает, чтобы ошибки подсвечивал.

увы, пока этот тормозной доднет не уберут и не перепишут в натив, мы будем страдать.
А еще некоторое тут защищают сборку мусора...