Информация в http://qt1l.sourceforge.net/wiki/index.php/About
частично устарела и не соответствует целям группы 2.

BW писал(а):
Прошу огласить основные направления планируемого развития.
Цитата:

Я таки считаю, что делать свой интерпретатор занятие мало осмысленное на начальном этапе.
Лучше взять готовый - JavaScript, Python, Lua и заложится на возможность в дальнейшем добавлять/менять конкретные интерпретаторы.
Т.е. сделать интерфейс для их встраивания, как это сделано в IE, Open Office,  PostgreSQL, FastReport и ряде других современных систем.

Аргументы разработку своего:
1) Полный контроль над языком
2) Полный контроль над реализацией
3) Это интересно.

Аргументы против:
1) Большинство из разработчиков весьма смутно представляют процесс компиляции/интерпретации.
2) Разработка языка требует хорошо знать и понимать теоретические основы структуры языков программирования, иметь хорошие знания в нескольких языках программирования, хорошо понимать конкретную специфику (подо что создаётся язык и почему не подходят существующие). Сильно сомневаюсь, что кто-то из разработчиков удовлетворяет этим качествам.
3) При разработке нового языка очень просто в него заложить некоторые допущения, которые потом могут оказаться неверными, и затормозить его развитие, а в конечном итоге и вовсе похоронить язык (ярчайший пример PL/1 в котором было очень мног фичь от IBM360-370 для которой он разрабатывался). Т.к. в случае qt1L интерпретатор это ядро - то ошибки в его дизайне негативно скажутся на всей системе.
4) Существующие языки довольно неплохо оптимизированы по всем параметрам - чтобы добиться сравнимого нужно потратить довольно много сил и времени.
5) Для нового языка придётся все библиотеки писать с нуля.
6) Для нового языка придётся с нуля писать документацию.
7) Придётся создавать сообщество пользователей, обучать, объяснять...

Мы уже пишем - и ничего - все довольны.

Tonal писал(а) 29. Февраля 2008 :: 10:54:

Ваши программы наверное предназначены для пользователей.
Наша же задача дать инструмент оперирования данными для публики ориентированной не на программинг, а на экономические расчеты. Вот у этой публики я так думаю нет никакого желания учить английский и сидеть со словарем, пытаясь подобрать удобочитаемый английский эквивалент переменной "ВаловаяПрибыль" или "АктУстановкиХарактеристикТовара", разбираться что такое #include <QtGui> и почему в этой строке используется маалок вместо аллока..

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

trdm писал(а) 29. Февраля 2008 :: 11:54:

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

Что разрабатывать-то собрались?
Цитата:

Тогда всё проще - выбирается какая-нибудь VM (например того же QtScript, Python-а или та же LLVM).
Потом рисуется транслятор с нужного синтаксиса в неё - и всё.
Транслятор делается с помощью Flex+Bison, ANTLR, или чего-то подобного.
Т.е. Вы довольно быстро получаете рабочий интерпретатор и трудитесь только над "выстраданными пожеланиями"

В чём проблемы?

В Python привязка к OLE есть довольно хорошая, для QtScript придётся свою городить.
В Python-е есть интерфейсы отладчика и профилятора, а также стандартные модули в поставке.
Сборка мусора есть практически в любой современной VM - кстати реализация её тоже не тривиальная задача для новчка.
Обмен информацией можно осуществлять или по сокетам через тот же xml-prc или по Dbus-у.

Что такое "обеспечения цепочек прохождения событий" я не понял.
В чём проблемы с "способ подвязки к событиям объектов" тоже.
Т.к. с 1С близко не знаком.
Но есть подозрение, что это какие-то специальные виды замыкания и очередей выполнения, а это и в python-е и в JavaScript существует явно - т.е. довольно просто выражается через стандартный синтаксис и примитивы.

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

trdm писал(а) 12. Марта 2008 :: 15:41:

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

Например, выложил бы в одном месте BNF языка, список проблем, "выстраданные пожелания", текущее положение вещей.

А то получается:
- Ребята подключайтесь!
- к чему?
- К разработке крутой системы!
- А что делать то?
- Да все и так знают, но проблем много.
- А какие проблемы?
- Да всякие.
- А конкретно.
- Очень сложные.

Nick писал(а) 13. Марта 2008 :: 07:55:

Неправда, я на все вменяемые вопросы старяюсь ответить.
Правда не всегда есть ответы.
А грамматика языка есть у всех, кто серьезно работал с проектом опенконф.

trdm писал(а) 13. Марта 2008 :: 09:51:

Имхо, дело именно в этом. Уважаемый trdm просто сам еще до конца не знает, что будет нужно, какие команды, как они должны работать. При этом в процессе разработки могут меняться условия и т.д. Поэтому и нет четкого ответа.
З.Ы. Я лично решил пойти другим путем
З.З.Ы. Блин, почти угадал 

Salimbek писал(а) 13. Марта 2008 :: 10:11:
что нужно я знаю, правда в минимальной конфигурации. мы же все этими коммандами пользуемся...
если бы не знал, это был бы чистой воды склероз...

Salimbek писал(а) 13. Марта 2008 :: 10:11:
вот это ты верно подметил...

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

sn175 писал(а) 13. Марта 2008 :: 12:04:

Вообще ХВАТИТ советов .
Хотите обсуждать подобное, заведите собственную ветку.
Направление работ и инструменты выбраны, дальнейшие попытки сбить
с толку команду будут считаться саботажем и караться....
меры буду выбирать в зависимости от настроения...
Уважайте свободу выбора, тогда и к вам будут относиться с уважением...
если мы решили расшибить себе лоб выбранным способом, это наше решение...

Кстати, sn175 тебе сюда: http://skmproject.my1.ru/publ/1
Ты там найдешь "родственную душу", обожающую питон руби...
сори, ошибочка...

Tonal писал(а) 16. Марта 2008 :: 07:49:

Вполне закономерное ошущение...
Просто прощупываю остовы системы. Когда голова уже болит от одной проблемы, переключаюсь на другие.
Tonal писал(а) 16. Марта 2008 :: 07:49:

а вот это очень слабое место, мое или проекта вцелом...
Пишется то на ГПЛ-ной QT. А там для начала модуль АктивКуТе отсутствует...

Блин, вот за что ценю профи, за то что у них всегда есть что сказать!
За ссылки спасибо, ОГРОМНОЕ.
О СОМ я имею предсталение, была мысля использовать ATL, только вот поряскал по интернету в поисках рускоязычной литературы, нифига не нашел, плюнул и сейчас ставлю 6-й МСДН с двух дисков, возможно там найдется ответ на некоторые вопросы...

trdm писал(а) 16. Марта 2008 :: 15:28:

ATL не собирается в мингве.
Насчёт того, входит ли он в состав студии-экспресс я сильно сомневаюсь.
Так что если не хочешь траблов с лицензиями - ATL только на посмотреть.

А насчёт DBus - я же говорил, что он есть и под винду и под них, и интегрирован в Qt - так что тут трудностей никаких нет.
Разработка поддержки для него сейчас даст опыт в разработки такой поддержки вообще без лишнего гимороя (как с COM).
И позволит понять как вообще строить подобные сопряжения.
Хотя, конечно COM сильно более востребован.