[DEM]

Родилась идея, о создании бесплатного аналога программ Арабат, Кристал, Вест и отдельных модулей НормКада....
Данный проект можно сделать с открытыми исходниками а разработку его вести на основе ГитХаба или Google Code....
В качестве языка программирования предлагаю принять VB.net т.к. он все таки победил в теме....
Можно было конечно принять матерный, но к сожалению, тогда придется проект делать закрытым, и исходники хранить на флешках в защищенных от доступа детей местах...
Прошу высказывать свои пожелания и предложения к данному проекту...

PS. Прошу всех кто согласен участвовать в проекте отписаться в личку....

Список участников:
DEM
bargool
RrRR
ябс
Cosinus
swell{d}
Akim_1989
Djur
Ratmir
Yasnogor
P1@t0n
GradRusStroy
gabidullin

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

[Meknotek]

Сообщение от Akim_1989 Есть же PyQt, который как я понял под лицензией GPL, то есть бесплатный.... Или я что-то не догоняю http://ru.wikipedia.org/wiki/PyQt

Дело не в том что "нет GUI". GUIев полно, включая Tkinter, который вообще в стандартной поставке идет. Вопрос только в том, что многим неудобно "прописывать" интерфейс непосредственно в коде, хочется "визуального редактора" по типу Delphi

[ETCartman]

Сообщение от Meknotek что многим неудобно "прописывать" интерфейс непосредственно в коде, хочется "визуального редактора" по типу Delphi

прописывать интерфейс в коде можно, тем более когда есть генератор кода. но 80 процентов написания программ - изменения. Если вы хотите поменять интерфейс программы - вам придется писать все заново. А в RAD вы это сделаете просто и быстро .

[Akim_1989]

Боюсь показаться делетантом. Но это очень похоже на Delphi

[DEM]

ETCartman
Та не ну не скажи, я в AutoIT по быстрому в слепую ваяю окошки...
И ничего переписывать не надо заново если, что то меняется...
Иногда даже старые использую заготовки....
Та быстрее получается, правда я тогда обычно забываю удалять всякие библиотеки перед компиляцией....
От этого файлы немного увеличиваются в объеме...
А вообще экзешники получаются обычно до 1 Мб безо всяких DLL и т.д.
Запускаются на всех компах, не считая Маков и Линуксов на борту...

[zamtmn]

Отвечаю на личное сообщение про скрещивание питона с лазарем тут, вдруг кто чтото дельное присоветует

Встроенной поддержки питона в лазаре и лазаря в питоне на данный момент нет и наврятли будет. Я такими вопросами не задавался, но встречал пару решений:
http://code.google.com/p/python4delphi/ (для delphi, но говорят работает и с lazarus\fpc)
http://wiki.freepascal.org/Developin...es_with_Pascal
Про их качество и удобство ничего сказать не могу. Естественно в общем случае можно всё запускать как сторонний процесс и разбирать результаты.
Также в лазарусе есть свой довольно легко интегрируемый инструмент - PascalScript. Это недавно появивфийся форк проекта http://www.remobjects.com/ps.aspx

Если будет решено завязаться на питон, то придется завязаться и на C/C++ т.к. именно эта связка проработана и имеет большую поддержку опенсорсного сообщества. Придя на какойнить програмерский форум и сказав "кто поможет зделать X на питон+с" гораздо вероятней получить поддержку, чем сказав "помогите допилить Y на лазарусе". Второй вариант ничего кроме флуда не вызовет.

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

ps. еще забыл про тулкиты для расчетных модулей (на питоне, паскале, бейсике и разных вариантах матерного), которые обеспечивают легкость чтения исходных данных и формирования результатов внутри этих модулей

[Meknotek]

Сообщение от ETCartman прописывать интерфейс в коде можно, тем более когда есть генератор кода. но 80 процентов написания программ - изменения. Если вы хотите поменять интерфейс программы - вам придется писать все заново. А в RAD вы это сделаете просто и быстро .

Я Вам так скажу - "гибкость кода" относится и к интерфейсу. Как я уже выше писал, вместе с PyQt часто импользуют QtDesigner. В "дезайнере" создается .ui файл, который по сути - XML-описание интерфейса. В программе на Python Вы просто загружаете этот файл и "прописываете" действия элементам интерфейса. После этого можете менять интерфейс как захотите в том же QtDesigner. Если пользуете другой "кодогенератор" - сгенерированный код трогать не надо. Его надо подключать/импортировать.

Сообщение от zamtmn Если будет решено завязаться на питон, то придется завязаться и на C/C++ т.к. именно эта связка проработана и имеет большую поддержку опенсорсного сообщества. Придя на какойнить програмерский форум и сказав "кто поможет зделать X на питон+с" гораздо вероятней получить поддержку, чем сказав "помогите допилить Y на лазарусе". Второй вариант ничего кроме флуда не вызовет.

"Завязываться" на что-то одно смысла нету никакого. Я бы больше озаботился:

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

Для этого есть:
- обмен текстовыми файлами с вызовом соответствующей программы
- сокеты
- RabbitMQ и подобные системы

[программеры-мы]

Сообщение от zamtmn Пофиг что на чем написано (естественно кроме экстримальных вариантов типа таблички в экселе - она пусть и остается табличкой)

Offtop: Это Великая сермяжная правда...
95% расчетов перекрываются одним листиком экселя...или чем-то подобным
Кстати, это в основном для строителей будет сказано..... две программки, написанные, вроде бы как бы Нитонисе перекрывают 50% всех расчетов в железобетоне...

[zamtmn]

ETCartman

Если вы хотите поменять интерфейс программы - вам придется писать все заново. А в RAD вы это сделаете просто и быстро .

Вносить изменения в наформошлепаный интерфейс - то еще удовольствие... ИМХО идеальный интерфейс это нечто формируемое автоматически на основе требуемых входных данных, т.е. не отдельное формошлепаное окошко для разных вариантов расчета, а некий универсальный инспектор по типу автокадовской панели свойств - единый на всё

Meknotek

Для этого есть:

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

edit:
программеры-мы

Offtop: Это Великая сермяжная правда...

Я скажу больше - 100% расчетов перекрываются calc.exe (или СASIO - на вкус и цвет) - и что с того?

[andsan]

Раз уж зашел разговор о Python. Кто нибудь пробовал скрестить Python и Excel с помощью надстройки DataNitro. По описанию получается почти как с VBA.

[Meknotek]

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

Я все же предполагал взаимодействие между собой "новых" программ написанных специально обученными людьми из списка поста #1 , т.е. изначально следующих определенным спецификациям. Естественно ко всему (уже существующему) "прикручивать" код для взаимодействия может оказаться малость неудобно/трудоемко. Хотя отдельные программы вполне достойны и такого.

Сообщение от zamtmn Я скажу больше - 100% расчетов перекрываются calc.exe (или СASIO - на вкус и цвет) - и что с того?

давайте зайдем еще дальше - 100% расчетов перекрываются карандашом и бумагой все, расходимся?

[программеры-мы]

Offtop: Ясень пень. Что из этой затеи ничего не получится, но читать интересно....
Я, Господа, отдал все что было у меня не нужного.
Нужное приберегу - такие вещи здесь никто и никогда не выкладывал.
Сваливаю......и прощения просим, если что было не так...

[zamtmn]

Нитонисе

Нужное приберегу - такие вещи здесь никто и никогда не выкладывал.

Ну и правильно, как показывает практика - выложенные нужные вещи не всегда такими являются, а прибереженные "нужные" и вовсе никому не нужны уже по определению

[программеры-мы]

Offtop: Возвращение блудного попугая

Сообщение от zamtmn как показывает практика - выложенные нужные вещи не всегда такими являются,

Offtop: Мусолили на форуме одну тему. Долго мусолили никто ума дать не мог...это иногда здесь бывает в отсутствие Главспецов. Пришлось раскачаться и написать.... "мучался", "мучался", "жабился","жабился",но все таки выложил в надежде на "коменты".
"Коменты" не последовали.
Вывод. Вы, абсолютно, правы,..... то что кажется мне ценным, на самом деле "дерьмо". И - наоборот.

[gomer]

Сообщение от andsan Кто нибудь пробовал скрестить Python и Excel

в Calc уже все скрещено

[andsan]

Сообщение от gomer в Calc уже все скрещено

А Вы сами то пробовали запустить Python в Calc?

[gomer]

Сообщение от andsan А Вы сами то пробовали запустить Python в Calc?

возможно там какой то урезанный диалект, но да, это работает, посмотрите примеры, входящие в дистрибутив опен офис

[andsan]

Написать функцию и вствить в ячейку все равно не получится. А вот с DataNitro похоже можно (в Excel).

[DEM]

программеры-мы
Да посмотрели мы на твои программы, практически все с ошибками, ты и моменты Опус считать не умеешь, Q*L^2/8 это для шарнирно опертой балки....

Сообщение от zamtmn Если будет решено завязаться на питон, то придется завязаться и на C/C++ т.к. именно эта связка проработана и имеет большую поддержку опенсорсного сообщества. Придя на какойнить програмерский форум и сказав "кто поможет зделать X на питон+с" гораздо вероятней получить поддержку, чем сказав "помогите допилить Y на лазарусе". Второй вариант ничего кроме флуда не вызовет. Вообще я думаю тут надо не с "платформой" определяться а с форматом взаимодействия "графического" хост приложения в котором будут задаваться исходные данные и визуализироваться результаты расчетов и самими "расчетными" модулями. Пофиг что на чем написано (естественно кроме экстримальных вариантов типа таблички в экселе - она пусть и остается табличкой) Т.е. есть главная программа, есть расчетные модули, есть некие файлы описания взаимодействия на основе которых главная программа формирует интерфейс для ввода исходных данных, затем формирует собственно файлы исходных данных, скармливает их модулям и принимает и визуализирует результаты.

Посмотрев, что делает Питон если сделать один экзешник, можно тут (Meknotek ты уж меня извини, но выглядит убого, и ты не виноват в этом, многие программисты говорят, что вообще из затеи делать отдельные экзешники для Питона, получается фигово)......
Так вот модулей, придется делать довольно много, и если каждый будет объемом по 10 Мб, да еще и состоять из кучи файлов, это будет мягко говоря не зерГуд.....
По сути я предалагаю сделать некий кастрированный вариант Питона, который можно будет копировать на комп без установки через инсталяцию....
Опять же с окошками и визуальными модулями проще будет работать, для модулей которым нужны формы, будет создаваться файл в котором будет описано окно, и что на нем должно быть(я такое на AutoIT сделать за пару часов, экзешник который будет читать данные о диалоговом окне из ini файла)......
Я так думаю на Лазарус можно будет сделать тоже подобный вариант.....
Просто нужна именно оболочка, которая могла бы скармливать данные Питону, и получать их обратно....
Может быть сделать это на VB.NET или еще на чем нибудь, просто в связи с тем, что программы на Питоне будут в сборнике, надо придумать как сделать чтобы они работали, не устанавливая Питон....
В общем надо прорабатывать варианты....

[Дима_]

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

Правильно - нужна оболочка скармливающая и получающая данные, перед тем как ее писать - вначале нужно проработать формат данных (с "передачей" проще - самое простое и всем понятное - набором строк, а уж распознает их модуль без проблем - хоть по порядку, хоть по ключевым заголовкам, хоть и то и другое одновременно, с "возратом" посложнее - надо придумать что в каком виде передавать - ихмо тоже проще всего строками - но надо прописать формат "условных обозначений"). Вот когда формат будет готов, то и можно будет подумать о создании DSL на основе хоть питона, хоть бейсика, хоть PHP, хоть лиспа, хоть просто парсинга математических формул - да хоть всех вместе - на любителя, но не раньше, а для "пробы" (ну и можно оставить, потом для особых "любителей") общаться с любыми exe скриптами - не нужно циклится на питоне или бейсике - это абсолютно неважно на кого будет похож синтаксис, надо выстроить "суть" языка - и плясать от нее - какая прагмида, какой диалект подойдет больше.

[zamtmn]

DEM
На картинках _статический_ интерфейс и соответственно статические входные данные. Сложность вызывают случаи когда данные динамические - например задать количество проемов и для каждого определить какието параметры (это сферическо-вакуумный пример, я с строительными расчетами не сталкиваюсь) т.е. когда интерфейс меняется от введенных данных.
В данном случае ИМХО удобно было бы задавать параметры прямо на чертеже - т.е. пользователь видит перед собой специально подготовленный вместе с расчетом dxf - выделяет нужные блоки и меняет их "атрибуты", выборка этих "атрибутов" скармливается отчету, затем результаты расчета также вставляются в нужные атрибуты.