nesco, ну, учитывая, что кодогенератор это dll-ка, как я понял, пакет "портировать" суть - соблюсти старый протокол вызова кодогенератора. Собственно, и всё. Все пакеты сразу заработают, не так?

1nd1g0, Если он интерфейс кодогенератора не поменял тогда -- да

Хочется надеяться, что что бы ни получилось в итоге, оно будет документировано ещё лучше, чем предшественники. Документированность - топливо совместной работы, приманка для максимума новых потенциальных соавторов. И централизованный контроль за единой парадигмой работы всех участников, дисциплина. Чтобы не получилось как с php - полный балаган и рассогласованность, каждый сам за себя, что ты знал вчера, сегодня можешь выкинуть на помойку, кто-то что-то не документировал, реализовав, другой реализовал то-же, но по-своему т.к. не нашёл нормальной документации на прошлые реализации, третий пришёл и вообще всё это удалил как, по его мнению, не нужное. Движение есть, но в разные стороны, как в баснях Крылова.

Стандартный пакет в HiAsm5 должен стать таким-же быстрым как сейчас FTCG в 4 версии. Разве это не одна из главных задач?

Пока он достигнет наполненностью и функционалом стандартный пакет 4-й версии, то не один рак на горе свистнет

nesco, Опыт есть! Еще догоним и обгоним

nesco, это я понял, но я про само устройство кодогенерации говорю. От этого и надо отталкиваться. А 4 версия уже есть, и в отличном состоянии.

Отнюдь. Портировать в полном объеме пакет, завязанный на форматы данных, поддерживаемые только Delphi-ориентированной средой очень сложно и делать это just for fun крайне глупо и бестолково. В тоже самое время при наличии открытых исходников с минимумом документации ничто не помешает открыто распространять среду в окружении open source разработчиков и найти тех, кто поддержит идею и сможет уделять свое время развитию кроссплатформенных пакетов.

А разве FPC не Delphi-ориентированный компилятор, хотя, и кроссплатформенный, совместно со своей LCL библиотекой

А! Вот где собака порылась. Но я имел в виду именно пакет, а не среду. Или там есть определенные сложности при портировании, что-то работать потом не будет нормально

nesco, мы сейчас какой вопрос обсуждаем?

Вот и я фактически об этом и спрашивал: нельзя ли максимально отделить среду и пакеты к ней, при этом предоставив кодогенератору все требуемые интерфейсы доступа к схеме? Например, по поводу форматов: я уже предлагал (и это было частично сделано, спасибо, Dilma) дать кодогенератору доступ до свойств всех типов, поддерживаемых средой. При этом реализовать встроенную поддержку, кроме чисел/строк, также свойств типа Icon, BMP, JPG, PNG, Stream (например, встроенные редакторы свойств). А уж кодогенератор сам выбирает, как ему эти свойства запихнуть в конечное приложение.

Мы обсуждали один и тот же вопрос -- как можно портировать старый пакет Windows под новый HiAsm 5, и можно ли это вообще
На чем собран сам HiAsm 5 в этой теме абсолютно никого не волнует, зачем переводить стрелки с рядового пакета на среду, я вообще не понял
И как вообще сосгласуется Delphi-ориентированная среда (я так понимаю, что это версия HiAsm 4) с существующими пакетами Web, QT, FASM и тп

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


ответ вроже уже дан

очень сложно - значит можно.


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