[DEM]

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

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

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

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

[DEM]

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

[zamtmn]

Тогда стоит забить на lazarus и копать нативные питоновые гуи библиотеки. Взаимодействие через консоль в данном случае тоже неудобно. имхо

[gomer]

или забить на питон

[DEM]

Нее
Все будет нормально, я уже с консолью разобрался уже разобрался...

[Cosinus]

Я так понял, всем пофиг на http://forum.dwg.ru/showpost.php?p=1...&postcount=695. А там уже есть готовые питоновские классы-сортаменты на двутавры, швеллера и уголки, которые выдают не только данные из сортамента, но и для рисовалки профилей.

Сообщение от gomer или забить на питон

В свое время я перелопатил С++, С#, Java, VB, Matlab (и его клоны). Если считать ql^2/8 - пофигу какой язык выбирать. Но рано или поздно придется перемножать матрицы или собственные значения искать или ещё чего такого, и тогда надо самим писать функции, ибо под эти языки бесплатных библиотек-считалок я не знаю. Под питон они есть - scipy, и это одна из причин, почему я на него и перешел. Под питон есть те же графические библиотеки, что и под С++ (wx, qt, gtk). Сляпать окошко с кнопками и менюшками на порядок легче чем в С++. Освоить питон, умея программировать на вышеупомянутых языках, можно за вечер. Если у кого есть свои наработки на других языках - перевести их на питон достаточно просто, есть даже конвертеры типа vb2py. Так же и код на питоне можно потом перетарить в С++, если кто захочет увеличения скорости .

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

[zamtmn]

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

Cosinus
Думаю вы плохо искали, открытых математических библиотек на с\с++ всяко больше чем на питоне.
И ненадо путать - то что запускается EXE вовсе не значит что код не открыт

[DEM]

Cosinus
Блин мне то не пофиг, я ребятам и обьясняю, что есть библиотека и что тем кто будет дальше разрабатывать программы будет довольно удобно пользоваться данной библиотекой...
Просто те кто говорит, о том что надо делать программы в Опен Офисе или Экселе, не вполне понимают что лучше иметь одну оболочку которая может рабоать с консольными приложениями, чем закрыть всего лишь один из вопросов, которые легко решаются в ОО или MS....
Ладно у мну тут вроде с консолью получилось, завтра выложу пример как можно будет отправлять и получать сообщения в консоли Питона...

Вот не большой пример общения Лазаря и Питона....
В принципе сейчас пока работает все еще с ключами запуска....
Сейчас разбираюсь с тем как заставить Питон работать в консоли и общаться с Лазарем....
Папку распаковать в APP, реагирует на команды 0, 1, 2

zamtmn

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

[zamtmn]

DEM
а что за проблемы с консолью питона? приложил "универсальную" обертку для консольных команд (вернее ее зачаток), там есть пунктик для питона (твой module1.py), вобъешь путь к интерпретатору в параметрах - все должно работать, попробуй. Только я не совсем понял как у тебя парамеитры передаются, -u:1 или -u1, сделал по первому варианту, если что отредактируй dem.ps

зы
там всё также как в #706, только добавлена возможность передачи параметров в параметрах комстроки и обертка над ping для проверки работы этой передачи
бинарник для win_x64

[DEM]

zamtmn
Фишка в том что стандартные методы работы Лазаря со сторонними приложениями основаны на методе TProcess, у меня сейчас так и работает, запускает приложение Питона с определенными ключами -u(в данном случае 1 ключ, их может быть и больше), отработав приложение отправляет команды(вернее все что было выведено в консоли Print, считывает наша программа).
Этот вариант не устраивает с одной стороны тем что прога каждый раз запускается, как только нам надо от неё, чтой то получить, хотелось бы чтобы это происходило постоянно, то есть мы просто отправляли команды, а программа их обрабатывала и выводила Print, результат мы считывали и все....
В общем более подробнее тута
Твоя обертка почему то не срабатывает.....
Говорит вбей путь к интерпритатору, я это делаю а она не срабатывает, повторяет сообщение....
Тот параметр что я говорил, это ключ который считывает Питон, если у тебя прога работает по иному принципу, то пусть она хотя бы просто запускает Питон, ему потом в командной строке можно дать задание на выполнение модуля в любой папке....

[zamtmn]

DEM
Ты не на том форуме спрашиваешь, спроси лучше тут http://freepascal.ru/
У меня тоже через TProcess, указать надо не просто путь, а путь включая интерпретатор.
т.е. с:\путь\к\питону\интерпретатор.exe (если нужны какиенибудь ключи - их тоже указать с:\путь\к\питону\интерпретатор.exe -ключ)
для запуска сформируется команда с:\путь\к\питону\интерпретатор.exe module1.py -u:1 (если нужны какиенибудь ключи - с:\путь\к\питону\интерпретатор.exe -ключ module1.py -u:1)

[DEM]

Разобрался все работает, но похоже работает так же как у меня через TProcess а не постоянно программа запущенна....

[zamtmn]

>>Разобрался все работает, но похоже работает так же как у меня через TProcess а не постоянно программа запущенна....
что значит также? она отрабатывает питоновский модуль и все
Чтоб работало "бесконечно" будет тотже TProcess, но внутри питон модуля нужно зациклить input и ждать команды от оболочки + эти команды както отрабатывать. в оболочке нужно организовать какиелибо контролы с посылкой команд в TProcess.
Но повторяю консоль для такой логики работы - самое неудачное решение, т.к. передаются только текстовые данные и нет возможности пошарить в очереди команд вперед и выбрать только нужные данные, остается только последовательно из нее читать.
Возможно имеет смысл оставить консоль для простого обмена текстовыми данными, а для работы с интерфейсом организовать в оболочке очень упрощенный аналог виндовой очереди событий и экспортировать функции для работы с ней в модуль. Хотя это тоже муть еще та. Вообще идея "постоянно программа запущенна...." не правильна имхо

[DEM]

Быстродействие будет по больше, я так думаю....

[zamtmn]

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

[DEM]

zamtmn
Ну это мое субъективное мнение....

#------------------------------------------------------------------------------- # Name: module1 # Purpose: # # Author: DEM # # Created: 07.01.2013 # Copyright: (c) DEM 2013 # Licence: <your licence> #------------------------------------------------------------------------------- #!/usr/bin/env python def combo(): print(1) print(2) print(3) print(4) def raschet(): X = eval(input("X: ")) Y = eval(input("Y: ")) print(222) while (1): quest = eval(input("Command: ")) if quest == raschet: raschet() if quest == combo: combo() if quest == "": print('NO command: ')

Просто я думал примерно о такой структуре проекта на Питоне да и на всех остальных языках....
Можно было бы сделать еще обработчик который позволил бы выполнить любую команду Питона...
Грубо говоря, консоль дожидается команды и обрабатывает её....
В принципе это влияет на быстродействие и на поток данных который выгружается(хотя с потоком у TProctcc все нормально есть ограничение, но оно обходится)....
Ну и подход с возможностью общения с консолью помог бы работать с Досовскими прогами, которые так некоторые хвалят...
Грубо говоря у нас появился бы удобный инструмент работы с подобными консольными программами....

[Дима_]

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

[DEM]

Дима_
НУ значится я тебя немного не правильно понял....
Можно будет input с задержкой делать как сделал zamtmn
Вот кстати у меня получилось, с Html событие нажатия на кнопку выдернуть....
Теперь осталось с комбобоксами разобраться....
НУ и посмотреть что делать с Undo/Redo

[Дима_]

Сообщение от DEM Вот кстати у меня получилось, с Html событие нажатия на кнопку выдернуть.... Теперь осталось с комбобоксами разобраться....

мне в x64 негде посмотреть - скомпилируй на x86...

[DEM]

Так он вроде и для 86 должен подойти....
ДА там все тоже самое что у тебя, только в memo выводится....
Сейчас с комбобоксами разбираюсь, и еще нужен простой редактор html страничег....

[Дима_]

Сообщение от DEM и еще нужен простой редактор html страничег....

если простой то notepad++ + в опере можно подправить исходный код и не сохраняя "обновиться".