Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#136: 2014-01-21 11:09:27 ЛС | профиль | цитата
Вот еще, мимоходом... Как бы предложение для ТС про подумать над этим.
Вообще-то, мой скрин выглядит так:
recursivesort.png
И мне представляется, что текст на мультике несколько улучшает мое "так очевидней некуда"

Мoй MultiElementEx.ini выглядит так:
#ini
[About]
Version=1.0
Author=Dilma

[Type]
Class=MultiElementEx
Info=Вложенная схема
View=Name,16

[Property]
Mode=Standard - имитация компонента MultiElement, Dynamic - поддержка динамических массивов, OnlyOnce - создание копии схемы при вызове любого метода и уничтожение её при завершении работы этого метода|4|0|Standard,Dynamic,OnlyOnce
Name=Условное обозначение на схеме|2|MX?

И в коде есть "заглушка" с этим свойством Name.
((Про что, кстати говоря, я постоянно забываю, выкладывая коды))
Что мне представлялось бы правильным:
  • Чтобы вместо иконки можно было ставить текст (без кодовых напрягов)
  • Чтобы текст можно было делать и многострочным.
  • Чтобы размер элемента определялся не только количеством точек, но и размерами "изображения". Текстом - в частности. Ну типа - минимально объемлющий и то, и другое
С масштабированием текста, вроде бы - проблем быть не должно

карма: 9

0
файлы: 1recursivesort.png [11.2KB] [1873]
Разработчик
Ответов: 26113
Рейтинг: 2126
#137: 2014-01-21 11:24:34 ЛС | профиль | цитата
Galkov писал(а):
И в коде есть "заглушка" с этим свойством Name

И где эта "заглушка"
А что будет, если иконку #main поставить внутри мультика, она появится или нет Многие, кстати, используют иконки внутри контейнеров.
карма: 22

0
Ответов: 9906
Рейтинг: 351
#138: 2014-01-21 12:17:38 ЛС | профиль | цитата
Не, ну чего спрашиваешь-то
Он же компилироваться с таким INI не будет
Пока в поля класса это свойство не влепишь. Которое там никому нафиг не нужно.

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

Классика: ты работаешь снизу вверх. Ты собираешь схему из элементов, которые есть в палитре. Хорошо, собрал предметно заточенный, и бесконечно полезный мультик.
Эта парадигма разработки в нашей среде вылизана довольно хорошо.
Почему бы и не поставить иконку...

А теперь попробуй быть "системным архитектором". Очень важно: "не отнести себя к системным архитекторам" а побыть им на самом деле.
В этом случае ты должен работать сверху вниз. Собственно, вниз уже могут работать и твои коллеги.
И ты рисуешь схему верхнего уровня.
Ты фантазируешь. Ты сочиняешь на лету семантику для объектов, из которых состоит "генеральная схема".
Ты их еще не полностью придумал, а отличать их друг от друга уже надо. Честное слово -- графическое рисование иконок тут не очень к месту.

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

Вторую парадигму -- мы тоже должны поддерживать.
Вот чего я себе возомнил

Слушай, nesco -- на схеме выше, мне реально было проще имя набрать, чтобы мои мозги про него начали думать иначе, чем про другие мультики.
Правда, я хотел Merge написать, а не Mrg -- так ни лизэ у глечек
карма: 9

0
Ответов: 1841
Рейтинг: 369
#139: 2014-01-22 01:41:33 ЛС | профиль | цитата
Ну что же, многие идеи мне нравятся.
На днях надо бы собрать свой ToDo список из предложенных идей.

Насчёт инструмента.
Решил таки оставить Лазарус, уж очень подходит он под этот проект.
Сейчас занялся подбором реализации отладки проекта.
Тут есть два варианта, и какой из них выбрать, ещё не знаю...
В общем:
1) Сборка проекта с отладочной информацией: в этом случае размер файла составляет 15+ мегабайт, на производительность не влияет, зато в случае ошибки, мы на месте получаем всю необходимую информацию которая попадёт в файл Trace.log
Пример Trace.log с бесконечной рекурсией

Program exception!
Exception class: Exception
Message: Unknown Run-Time error : 202
Stacktrace:
$000000000042DA58 TEST, line 65 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas
$000000000042DA5D TEST, line 66 of unit1.pas

2) Сборка проекта с отладочной информацией в отдельном файле (*.dbg).
В этом случае, размер проекта значительно меньше - 2 мегабайта без сжатия, но в случае ошибки, мы получаем вот такую информацию:
Пример Trace.log с бесконечной рекурсией

Program exception!
Exception class: Exception
Message: Unknown Run-Time error : 202
Stacktrace:
$000000000042DA58
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
$000000000042DA5D
Далее, тот кто будет разбираться, достаёт файл с отладочной информацией (придётся к каждому релизу хранить), и с помощью не хитрых телодвижений, используя возможности GNU GDB:
gdb -symbol тут_собственно_файл_с_отладочной_информацией.dbg
info line *0x000000000042DA58 //достаём строку с ошибкой
получим:
Reading symbols from D:PCSySDesktopTest/project1.dbg...done.
(gdb) info line *0x000000000042DA58
Line 66 of "unit1.pas" starts at address 0x42da58 <TEST+8>
and ends at 0x42da5d <TEST+13>.
(gdb)
карма: 1
1
Голосовали:LastLeader
Ответов: 316
Рейтинг: 21
#140: 2014-05-02 15:56:27 ЛС | профиль | цитата
Как обстоят дела с проектом?
карма: 1

0
Ответов: 1841
Рейтинг: 369
#141: 2014-05-11 07:31:04 ЛС | профиль | цитата
LastLeader писал(а):
Как обстоят дела с проектом?

Временно заморозил.
Весь проект переносится на Qt 5.x(С++11).
Несмотря на кажущуюся стабильность и простоту Lazarus/FPC, будущее у данных проектов очень спорное...

Краткий обзор +/- инструментов изученных мной.

Плюсы FPC(Lazarus):
1) Относительно удобный и простой синтаксис Object Pascal, Delphi;
2) Кроссплатформенность включая IDE;
3) Лицензия GNU GPL, GNU LGPL;
4) Статическая линковка по умолчанию(всё с собой) и небольшой размер бинарника;

Минусы FPC(Lazarus):
1) Кроссплатформенность на уровне кучи ifdef'ов;
2) Отладчик кране плохо реализован на некоторых платформах;
3) Стремление сообщества повторить функционал Delphi 1 в 1;
4) Куча ошибок в реализациях кросс-возможностей;
5) Отсутствие нормальных статических/динамических анализаторов;
6) Крайне медленное развитие возможностей стандартных библиотек(FPC) и синтаксиса, т.к. сообщество не особо большое, да и отсутствует финансовая поддержка;
7) Имеющаяся документация не охватывает всех возможностей FPC/Lazarus;
8) Негативное отношение общественности к Delphi и ему подобных реализаций (в будущем аукнется);
9) Крайне малая востребованность инструмента на рынке, что отталкивает потенциальных пользователей и разработчиков;

----------

Плюсы Qt 5.x(cpp11):
1) Отлаженный и вылизанный фреймворк Qt с огромными возможностями;
2) Большое сообщество;
3) Отличная документация;
4) Стандартизированный и развивающийся ЯП - C++;
5) Кроссплатформенность на очень высоком уровне, включая: IDE, отладчик, профилировщик;
6) Активное развитие фреймворка с учётом актуальных технологических новшеств;
7) За будущее проекта можно не волноваться;
8) Множество статических/динамических анализаторов;
9) Активное развитие компилятора GCC;
10) Умные оптимизации кода на уровне компилятора;
11) Потенциальная возможности переноса базовых реализаций на мобильные платформы в будущем;
12) Лицензия GNU LGPL или GNU GPL;
13) Крайне положительное отношение общественности к Qt и C++;
14) Встроенный инструмент юнит тестов;
15) Встроенный инструмент удобного создания локализации;
16) Из коробки: OpenGL, аппаратное ускорение, работа с базами данных, webkit (в дальнейшем WebEngine на основе Chromium),...;
17) Очень удобно рисовать прямоугольники
18) Личное развитие и дополнительный опыт разработки на C++ и Qt, что даёт дополнительную мотивацию как разработчику проекта, так и присоединившимся;
19) Уже имеется возможность компиляции Qt приложений прямо на мобильных платформах (пока только Android, С4Droid если что);
20) Ещё очень много ++)

Минусы Qt 5.x(cpp11):
1) Порог вхождения C++; //Хотя по мне, он более логичен чем тот же Delphi
2) Динамическая линковка по умолчанию;
2.1) Очень просто решается сборкой Qt libs с определёнными ключами.
В итоге, получаем статическую сборку с умной линковкой только требуемых Qt libs, размером в 5mb (upx: 3mb);


За Qt будущее //Хотя тут я перегнул, web-технологии догоняют
Вот так.
карма: 1
0
Гость
Ответов: 17029
Рейтинг: 0
#142: 2014-05-11 11:55:00 правка | ЛС | профиль | цитата


Редактировалось 2 раз(а), последний 2017-06-14 22:24:46
карма: 0

0
Ответов: 316
Рейтинг: 21
#143: 2014-05-12 19:01:28 ЛС | профиль | цитата
CriDos писал(а):
Весь проект переносится на Qt 5.x

Больше никуда не будет переносится? То я рассчитываю на твой проект в этом году
карма: 1

0
Ответов: 1841
Рейтинг: 369
#144: 2014-05-13 07:15:18 ЛС | профиль | цитата
LastLeader писал(а):
Больше никуда не будет переносится?

А больше и некуда

Mono(который .NET) - сырой до мозга костей, который ещё и зависимость имеет.

GTK - это вообще странная штука, недоQtшный запутанный фреймворк (из коробки кодить на C, можно и на C++ или PyGTK...)

WxWidgets - в большей степени GUI фреймворк с фиговой документацией.

Интерпретируемые ЯП - дополнительные грабли с GUI(прикручивать WxWidgets или ещё чего); возможные проблемы с производительностью, а это дополнительные нативные либы прикручивать, которые на C/C++ и тд и тп...

Java - Практически как и предыдущий вариант, но получше с производительностью. Также грабли с GUI в виде Swing или wxWidgets.
Ну и нужны дополнительные тесты, т.к. эта штука довольно хитро потребляет память, в общем, дополнительные риски.

Самый олдскульный вариант:
Разделить весь проект на 2 абстракции.
Высокоуровневые классы и низкоуровневые...
Запилить один раз высокоуровневые классы, и потом долго и нудно писать низкоуровневые для каждой платформы
Ещё и на описание и проектирование API для взаимодействия нужно будет потратить огромное к-во времени.
В общем, бред

В итоге, получаем 2 варианта: Qt и Lazarus, которые реализовали олдскульный вариант
Тут у них из коробки: IDE, отладчик, кросс-классы и тд. и тп.
Но Qt я посчитал хоть и хорошим инструментом, но сложным для данного проекта и решил остановиться на Lazarus.
Жаль конечно потраченного времени, но зато меня теперь не терзают смутные сомнения с выбором инструмента, как это было с Lazarus.

У Qt очень амбициозные планы по захвату мира! *злобные смех*
В будущем ожидается охват как можно большего парка ОСей, что даёт дополнительные возможности для развития проекта.
карма: 1
0
Ответов: 4628
Рейтинг: 749
#145: 2014-05-13 11:43:54 ЛС | профиль | цитата
CriDos писал(а):
Минусы Qt 5.x(cpp11):
Предположу, главный минус тут только один (тот же, что и в официальном HiAsm 5): ровно 2 с половиной человека, могущих и желающих писать его на C. Не могу гарантировать, что на Delphi их будет больше, но, как минимум, те люди, которые активно в разное время работали над пакетом Delphi, остались не у дел.
карма: 26

0
Главный модератор
Ответов: 2999
Рейтинг: 396
#146: 2014-05-13 12:49:59 ЛС | профиль | цитата
«Кто хочет - ищет возможности, а кто не хочет - ищет оправдания».
Для действительно желающего, язык не имеет значения. Любую систему программирования можно освоить, так как все они построены на одном принципе: логике.
карма: 6
Дорогу осилит идущий. Install/Update HiAsm.NET
0
Ответов: 4628
Рейтинг: 749
#147: 2014-05-13 12:53:20 ЛС | профиль | цитата
Не спорю. Но для выполнения конкретной задачи должна быть личная мотивация.
карма: 26

0
Ответов: 1841
Рейтинг: 369
#148: 2014-05-13 15:56:33 ЛС | профиль | цитата
Netspirit писал(а):
его на C

C++
Ну а с остальным у меня тоже уже есть решение.
Будет поддержка плагинов, причём расширенная
Т.е. можно будет реализовать даже свой редактор GUI, или же изменить/заменить стандартные элементы/свойства среды.
Плагины будут в скриптовом варианте, дабы можно было без дополнительных действий перенести на другую ОСь.

Netspirit писал(а):
главный минус тут только один (тот же, что и в официальном HiAsm 5): ровно 2 с половиной человека, могущих и желающих писать его на *чём_угодно*

Главный минуc HiAsm 5 это то, что я потратил пол дня что бы найти все зависимости, и скомпилировать этот HiAsm 5, ещё и проблемы были с Designer
Я понимаю Автора.
На тот момент нельзя было точно сказать, какой фреймворк лучше/хуже и что будет в будущем.
И Qt в то время нужно было собирать самому, что крайне сильно влияет на порог вхождения.

Почему я выбрал Lazarus или тот же Qt?
Всё работает из коробки. Т.е. стянул Qt из репозитория со всеми зависимостями, открыл в отличной IDE проект без поисков, гугления и другой фигни, нажал Build - вуаля, готово.
Ещё проще на Win ОСях. Скачал, поставил, открыл, собрал.
Главная особенность задумки - всё должно быть просто.

Netspirit писал(а):
над пакетом Delphi, остались не у дел.

Тут к сожалению, я ничего не могу поделать...
Мне это решение тоже не очень просто далось, но нужно адаптироваться к реалиям, иначе бешеная скорость развития технологий пролетит и не заметит... HiAsm
------------ Дoбавленo в 15.56:
Хотя есть ещё Embarcadero RAD Studio...
Но мне даже страшно представить проект на основе этого проприетарного решения, состоящего вдоль и поперёк из кучи баго-фич, которые никогда не фиксятся(судя по отзывам).
Думаю что они не долго продержатся с таким то отношением к клиентам.
карма: 1
0
Ответов: 4628
Рейтинг: 749
#149: 2014-05-13 17:59:44 ЛС | профиль | цитата
Я пользуюсь Delphi 2007. Баги, вероятно, фиксятся. Только в новых версиях (судя по частоте их выхода). А покупать каждый раз не все могут.
Ещё настораживает ихнее желание усидеть на нескольких стульях: делают упор на гибрид ужа с ежом, чтобы реализовать единый код для iOS, Android (native) и других платформ. Для чего (как я понял с их конференции по Delphi XE5) они хотят внести значительные изменения в сам язык, а также выкинуть все платформозависимые фишки. Например, не будет возможности работать со строками как с массивом символов. Для этого будет куча хелперов.
Уберут необходимость ручного уничтожения объектов (включат сборщик мусора). Предполагаю, эта же участь в дальнейшем ждет и встроенный ассемблер и свободную манипуляцию памятью.
Уже сейчас пустая форма в юникодных версиях весит от 1.5 Мб.
Таким образом любимое Delphi скатывается в УГ. Вся надежда на FPC и старый добрый Delphi 7-2007.

карма: 26

0
Ответов: 316
Рейтинг: 21
#150: 2014-05-13 19:11:53 ЛС | профиль | цитата
Netspirit писал(а):
Вся надежда на FPC и старый добрый Delphi 7-2007.
Вся надежда на Hiasm

Недавно болтали с Муз-Тв о недостатках реализации Hiasm 4. Во первых, кодогенератор завязан на графической оболочке и толком без графики с им ничего не сделаешь. То-ест с Hion(на) не можно нормально отправить sha на сборку, нужны всякие костыли делать. Во вторых, нет возможности динамического изминения графической оболочки из элементов, как пример один элемент зависит от второго и нельзя например заблокировать на панели инструментов (после перетаскивания на форму первого) второго элемента или показать какую-то индикацию на основной панели (количество занимаемой памяти элементов в обработчике... процесс передачи или сборки...)
Пришло в голову что у элемента должен быть еще одно описание кроме исходников, доп файлик который говорит что делать графике при определенных действиях с элементом.
Кто-что об этом думает?
карма: 1

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)