а не замутить ли нам недосимулятр?

bar · Post by **bar** » 04 Sep 2012 19:22

Перерыл я полинтернета в поисках кроссплатформенного gui-тулкита. Но все, почему-то, отказываются поддерживать win9x. Даже tcl/tk с какой-то недавней версии отказался от 9x. То есть про DOS я вообще молчу, на него все задвинули, по-моему, ещё лет десять назад.

Но кажется я высмотрел реально кроссплатформенный gui-тулкит: clutter. То есть, под чистым dos'ом-то его вряд ли удастся запустить, но во всех остальных местах он будет работать. По-крайней мере, очень похоже на это. В требованиях написан OpenGL 1.3+ (1.2+multitexturing) или OpenGL|ES 1.1 или 2.0. Судя по тому, что в Lavr'овской венде работали PBuffer'ы из CEDAR Logic, можно сделать вывод, что у него OpenGL 1.3+.

Правда это не совсем то чтоб библиотека виджетов, типа gtk, но судя по всему -- этот clutter являет собою инфраструктуру для создания виджетов. В нём и отрисовка шрифтов, и ввод-вывод, и система ивентов. И есть ещё некий Mx, который как я понимаю уже именно библиотека виджетов для clutter'а. Правда "планшетная" библиотека, что может оказаться неудобным для десктопа, но... Но всё же писать виджеты там, где есть вся инфраструктура, всё ж как-то меня больше прельщает, нежели рисовать надпись "Файл" в главном меню попиксельно из самодельных файлов с растровыми шрифтами в koi8-r/cp866/...

Теоретически выходит так, что программу базирующуюся за clutter'е можно будет запускать чуть ли не на бортовом компьютере автомобиля. По-крайней мере эти бортовые компьютеры упоминаются в педивикии напротив OpenGL|ES. При этом Android с какой-то там версии 1.x поддерживает OpenGL|ES, а MeeGo смартфоны (коих я никак не могу дождаться от Jolla) поступают ещё проще: имеют UI построенный на Clutter'е. Да, кстати OpenGL|ES где-то и в WebGL засветилась. Правда clutter на C написан, и поэтому в браузер его засунуть не удастся.

Попробую завтра поставить венду 9x и собрать в ней clutter. Посмотрим чё выйдет.

Lavr · Post by **Lavr** » 04 Sep 2012 20:32

bar wrote:Но все, почему-то, отказываются поддерживать win9x. Даже tcl/tk с какой-то недавней версии отказался от 9x.
То есть про DOS я вообще молчу, на него все задвинули, по-моему, ещё лет десять назад.

Если вы имеете ввиду меня - то не загоняйтесь и не утруждайте себя...
У меня реально бесплатного софта под 9x - хватит до моей пенсии.

Мой друг работал в фирме-провайдере и имел неограниченный доступ на границе
2000-х. И как любитель инет-серфинга, он мне столько софта накачал - на будщее...
А я его доступом по ночам пользовался, и обдуманно накачивал софт на настоящее,
приговаривая:"Настанет момент - за всё это будут бабла просить!"

Так что я под 98-й не из оригинальности или нищебродства сижу, просто
у меня рабочий процесс хорошо настроен - и не хочется это менять, повторив
всё пусть даже под ХР.

Я порой удивляюсь - смотришь - пытается человек что-то делать... А у него -
того нет, этого нет... Да он мучаеся, на мой взгляд, а не программирует!

Да и время - настало... хм... я вот гуглил бинарные редакторы... Ужосс!
Функциональность ну не сильно выше hiew... а размеры!...

После hiew я только WinHex признал полезным...

bar · Post by **bar** » 04 Sep 2012 21:55

Lavr wrote:
bar wrote:Но все, почему-то, отказываются поддерживать win9x. Даже tcl/tk с какой-то недавней версии отказался от 9x.
То есть про DOS я вообще молчу, на него все задвинули, по-моему, ещё лет десять назад.
Если вы имеете ввиду меня - то не загоняйтесь и не утруждайте себя...
У меня реально бесплатного софта под 9x - хватит до моей пенсии.

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

А во-вторых, такие "загоны" и "утруждения", по-моему полезны. Хотя бы тем, что кругозор расширяют.

Я, допустим, и знать не знал, что MeeGo имеет векторный, потенциально акселерированный железно, гуй, причём не на уровне Xgl и тому подобных, а несколько повыше. А раз так, то тем более мне интересен MeeGo. И тем более мне интересен Clutter, на котором построен MeeGo.
Хоть создатели Enlightenment и постулировали, что резвый гуй должен быть растровым, и в общем-то умудрились показать на что способен растр в таких ситуациях. Поковыряв немного ситуацию я с ними был вынужден согласиться, но меня всё равно не оставляет надежда, что вектор порвёт когда-нибудь растр. И это должно случиться, иначе в процессе непрекращающегося роста разрешения экрана, рано или поздно сгорят все DMA контроллеры, гоняя растры из ОЗУ в видяху. И никакие вентиляторы в системном блоке их не спасут. В том же e17 все красивые анимационные поведения разных элементов интерфейса были реализованы последовательной сменой png-кадров, которые умнейшим образом заранее подгружались с жёсткого диска, чтобы не дай бог анимация не взлагнула бы из-за вечно тормозящего прогресс жёсткого диска. И подгрузившись, все эти png (местами до 1024x768 размером) отправлялись последовательной стайкой через DMA контроллер в видяху. С таким подходом e17 летал на третьем пне в разрешении 800x600 и поражал тогда воображение настолько, что я достаточно долго пользовался e17 в качестве wm. Но сегодня у меня 1280x1024, а где-то в новостях проскакивало про монитор, чьи размеры пикселя неразличимы для глаза, то есть монитор на котором antialiasing -- совершенно ненужная фича. И, боюсь, уже не за горами горы дымящихся DMA-контроллеров.
Развивая оффтоп, можно ещё представить себе X-сервер, выполняющийся не на CPU, а на GPU. Но я пока не замечал подобных тенденций. Как библиотеку виджетов прокинули из клиента в некое подобие X-сервера -- это я разглядывал. А чтоб X-сервер на GPU -- не приходилось: nvidia с amd/ati, вместо того, чтобы чем-нибудь любопытным заняться, лишь письками меряются: кто больше текселов в секунду отрисует, в то время как intel со своими видяшками прочно занимает свою нишу и, наступая на пятки первым двум, ни на что больше не претендует.
И тут, на фоне всего этого серого унылого мейнстрима, только и думающего о том, какой бы ещё чип мамки снабдить персональным вентилятором, тут такая свежая струя: векторный гуй общего назначения. Никак нельзя пройти мимо.

Lavr · Post by **Lavr** » 04 Sep 2012 22:07

Ну, джентльмены, я просто предупредил, чтобы вы не грузились зазря...
Тут и по сути работы - дел хватает, чтобы ещё заморачиваться на ДОС/Венду 9х...

Я лично всегда придерживаюсь принципа, что если надо решить проблему,
а не продемонстрировать искусство преодоления трудностей, то проблему
надо решить кратчайшим и самым удобным путём.
Не оглядываясь при этом на личные принципы, любимые програмные продукты и др.

Shaos · Post by **Shaos** » 10 Sep 2012 20:22

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

bar · Post by **bar** » 10 Sep 2012 20:46

Shaos wrote:начиная от путей избегания зацикливания симулирующего алгоритма

Это по-моему не требует особых "путей". По одному биту на каждый элемент, значения которых одинаковы перед началом очередной итерации симуляции, и которые инвертируются к концу этой самой итерации.

и кончая автоматической отрисовкой непекрывающихся соединений между компонентами

Что значит "неперекрывающихся"? В смысле тех, что проходят не под компонентами? Я как-то не задумывался о том, чтобы прятать соединения под компонентами. А это надо?

Shaos · Post by **Shaos** » 10 Sep 2012 20:51

bar wrote:
Shaos wrote:начиная от путей избегания зацикливания симулирующего алгоритма
Это по-моему не требует особых "путей". По одному биту на каждый элемент, значения которых одинаковы перед началом очередной итерации симуляции, и которые инвертируются к концу этой самой итерации.
и кончая автоматической отрисовкой непекрывающихся соединений между компонентами
Что значит "неперекрывающихся"? В смысле тех, что проходят не под компонентами? Я как-то не задумывался о том, чтобы прятать соединения под компонентами. А это надо?

Это если надо будет автоматически рисовать соединения между компонентами (не вручную), то я знаю как сделать проще

P.S. А в каком порядке будет происходить твоя итерация симуляции?

bar · Post by **bar** » 11 Sep 2012 16:33

Shaos wrote:Это если надо будет автоматически рисовать соединения между компонентами (не вручную), то я знаю как сделать проще

Понял, о чём речь. И как, интересно? Мне ничего умнее проецирования на две перпендикулярные прямые (одна из которых параллельна новому соединению) в голову не приходит.

Shaos wrote:P.S. А в каком порядке будет происходить твоя итерация симуляции?

Ну если честно, я не особо вдумывался в это. То есть понятно, что проблемы определённого рода там возникнут, в том числе и проблемы типа того, что соединение должно быть в двух состояниях 0 и 1. И эти проблемы не решаются порядком обхода. Другое дело что они всплывать могут на разных этапах. Но чем это может помочь -- я не вижу. То есть если бы был какой-то более умный способ выбрать состояние для проводника, нежели "кто первый тот и папа"... Хотя да, если обход не рандомизировать принудительно, то если в схеме есть два соединённых выхода которые дают противоречивые значения для соединения, то всегда "побеждать" будет один и тот же, и определяться этот один будет, наверное, порядком добавления элементов в схему. И выглядит это не очень правильным. То есть два соединённых выхода уже выглядят неправильно, но...
Короче, если я правильно всё понимаю, порядок обхода не влияет на выбор структур данных. А раз так, то и какая на данном этапе разница?

Shaos · Post by **Shaos** » 11 Sep 2012 18:05

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

По поводу отрисовки - у каждого компонента входы располагаются слева, а выходы справа. К каждому входу пририсовываем смотрящий влево отрезок длиной, равной порядковому номеру входа - к первому длиной 1, ко второму длиной 2 и т.д. Со входами делаем тоже самое, но отрезки будут смотреть вправо. В результате у нас получается эдакая ёлочка. Теперь очень просто рисовать соединения между нужными цепями - считаем что соединения всегда состоят из трёх сегментов - вертикального, горизонтального и опять вертикального - т.е. это может быть подобие буквы П либо Ц либо нечто среднее - просто перебираем все варианты двигаясь всё дальше и дальше, находя такую отрисовку, при которой соединение не будет перекрывать никаких других компонентов и не будет лежать поверх соединений того же самого направления, причём если окажется, что мы по ходу уже пересеклись с нужной цепью то на ней и останавливаемся, ставя жирную точку в месте соединения. При этом мы добъёмся полностью автоматического соединения компонентов, расставленных вручную - выглядеть это будет примерно так:

При компиляции в C++ это превращалось вот в такой класс с методом step (один шаг симуляции):

Code: Select all

class DEBOUNCE
{
public:  //! VAR_INPUT
 BOOL	in;
 TIME	db_time;
public:  //! VAR_OUTPUT
 BOOL	out;
 TIME	et_off;
private: //! VAR
 TON	db_on;
 TON	db_off;
 SR	db_ff;
public:
 DEBOUNCE () //! CONSTRUCTOR
 {
	in	= 0;
	db_time	= 1000L;
	out	= 1;
	et_off	= 0;
 }
 int step(void) //! STEP
 {
	int o = 1;

	db_on.in = in;
	db_on.pt = db_time;
	o &= db_on.step();

	db_off.in = ~in;
	db_off.pt = db_time;
	o &= db_off.step();

	db_ff.s1 = db_on.q;
	db_ff.r = db_off.q;
	o &= db_ff.step();

	out = db_ff.q;
	et_off = db_off.et;

	return o;
 }
};

Так что у меня был как интерпретатор схемы, так и компилятор

Кстати при интерпретации можно было записывать "осциллограммы":

Теперь я хочу соорудить нечто подобное, но на си и опенсорцное

bar · Post by **bar** » 11 Sep 2012 21:27

Shaos wrote:Во-вторых, в произвольном порядке схему исполнять нельзя (будут непредвиденные задержки в распостранении сигнала и вообще неправильная работа) - перед симуляцией соединения надо упорядочить, для чего список всех доступных соединений сортируется так, что в начало списка попадают входы схемы и далее по слоям до выходов.

А. Я понял к чему это. Это если состояние выходов элемента -- функция его входов и времени, так? Про время в качестве параметра я не подумал.

И почему-то был уверен, что у нас время будет измерятся в количестве итераций симуляции. Ведь для того, чтобы все сигналы появлялись в нужной последовательности, то, при условии что произвольный элемент, в произвольный момент времени, без внешних видимых причин, может вдруг изменить состояние своих выходов... При этом условии, придётся реализовывать (или симулировать) нечто типа "на каждый элемент по real-time thread'у". Просимулировать это вполне возможно, создав очередь "будущих" событий, отсортированную по возрастанию времени до наступления этих событий. М-м-м...

[s]и переключая стеки с кода одного элемента на код другого элемента по мере наступления времени того или иного события. Это будет жёстко и круто. Торвальдс с его монолитным ядром на говно изойдётся от зависти.[/s]

Может именно для этого cedar'овский симулятор логики использует очереди событий? Я заглядывал туда, у него там, судя по всему свои события и свои очереди функционирующие вне зависимости от работы очереди gui событий.

Shaos wrote:По поводу отрисовки - у каждого компонента входы располагаются слева, а выходы справа. К каждому входу пририсовываем смотрящий влево отрезок длиной, равной порядковому номеру входа - к первому длиной 1, ко второму длиной 2 и т.д. Со входами делаем тоже самое, но отрезки будут смотреть вправо. В результате у нас получается эдакая ёлочка. Теперь очень просто рисовать соединения между нужными цепями - считаем что соединения всегда состоят из трёх сегментов - вертикального, горизонтального и опять вертикального - т.е. это может быть подобие буквы П либо Ц либо нечто среднее - просто перебираем все варианты двигаясь всё дальше и дальше, находя такую отрисовку, при которой соединение не будет перекрывать никаких других компонентов и не будет лежать поверх соединений того же самого направления, причём если окажется, что мы по ходу уже пересеклись с нужной цепью то на ней и останавливаемся, ставя жирную точку в месте соединения. При этом мы добъёмся полностью автоматического соединения компонентов, расставленных вручную - выглядеть это будет примерно так:

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

Shaos · Post by **Shaos** » 11 Sep 2012 21:46

Неа - как раз время измеряется в количестве итераций симуляции. Функция step схемы перебирает все компоненты, вызывая у них свои функции step. Просто в зависимости от порядка перебора результаты могут различаться или быть вовсе неправильными - например: имеем вход A и 3 выхода - B,C,D. Выход B подключен к входу A через один инвертор I1, выход C подключен к выходу инвертора I1 через инвертор I2, выход D подключен к выходу инвертора I2 через инвертор I3. Предположим, что мы посылаем на вход последовательность 01010101. Вот что выдаст упорядоченная симуляция (считаем, что изначально все выходы обнулены):

Code: Select all

I1=0 I2=0 I3=0 | B=0 C=0 D=0 | A=0
I1.step();I2.step();I3.step();
I1=1 I2=0 I3=1 | B=1 C=0 D=1 | A=1
I1.step();I2.step();I3.step();
I1=0 I2=1 I3=0 | B=0 C=1 D=0 | A=0
I1.step();I2.step();I3.step();
I1=1 I2=0 I3=1 | B=1 C=0 D=1 | A=1
и т.д.

А вот что сгенерит неправильная последовательность обхода:

Code: Select all

I1=0 I2=0 I3=0 | B=0 C=0 D=0 | A=0
I3.step(); // I3=!I2=1
I2.step(); // I2=!I1=1
I1.step(); // I1=!A=1
I1=1 I2=1 I3=1 | B=1 C=1 D=1 | A=1
I3.step(); // I3=!I2=0
I2.step(); // I2=!I1=0
I1.step(); // I1=!A=0
I1=0 I2=0 I3=0 | B=0 C=0 D=0 | A=0
I3.step(); // I3=!I2=1
I2.step(); // I2=!I1=1
I1.step(); // I1=!A=1
I1=1 I2=1 I3=1 | B=1 C=1 D=1 | A=1
и т.д.

Как видишь результат "симуляции" выглядит совершенно иначе из-за того что у нас имеется трёхступенчатая обратная связь - правильный сигнал доходит до выхода за три такта и если период изменений нашего входного сигнала меньше времени задержки, то могут получатся наложения и неправильная работа симуляции, а если больше - то просто 3-тактовая задержка в распостранении сигнала...

bar · Post by **bar** » 12 Sep 2012 22:24

Я может тупой очень... Но чесслово, я долго думал и очень старался. И так и не понял, как эта схема должна выглядеть. То есть во-первых, там по-моему опечатка, наверное так надо(?):

Выход B подключен к входу A через один инвертор I1, выход C подключен к выходу инвертора I1 через инвертор I2, выход D подключен к выходу инвертора I2 через инвертор I3.

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

Shaos · Post by **Shaos** » 12 Sep 2012 22:32

bar wrote:Я может тупой очень... Но чесслово, я долго думал и очень старался. И так и не понял, как эта схема должна выглядеть. То есть во-первых, там по-моему опечатка, наверное так надо(?):
Выход B подключен к входу A через один инвертор I1, выход C подключен к выходу инвертора I1 через инвертор I2, выход D подключен к выходу инвертора I2 через инвертор I3.
Но даже в таком формате, я видимо чего-то не понимаю, поскольку никакой обратной связи у меня не образуется, когда я пытаюсь это нарисовать.

Ага - поправил

Обратная связь получается если эти блоки в неправильном порядке вызывать...

bar · Post by **bar** » 12 Sep 2012 23:09

Shaos wrote:Обратная связь получается если эти блоки в неправильном порядке вызывать...

а...
Но я, кажется, понял таки о чём речь.

Shaos wrote:перед симуляцией соединения надо упорядочить, для чего список всех доступных соединений сортируется так, что в начало списка попадают входы схемы и далее по слоям до выходов. Чтобы исключать зацикливания при сортировке надо ввести ещё один параметр соединения - местоположение приёмника по горизонтали - если приёмник находится левее источника, то это трактуется как обратная связь (задержка в 1 такт на распостранение сигнала) и это соединение при сортировке игнорируется (точнее трактуется как обычный вход схемы).

Я попробую переформулировать, для проверки связи.
Все элементы мы раскидываем по непересекающимся множествам -- слоям. Слой #0 состоит из входов. Слой #N состоит из элементов, от которых длина кратчайшего пути до слоя входов равна N. Говоря путь я имею в виду путь в графе, с вершинами -- элементами схемы, и рёбрами-соединениями между элементами.
И обход оказывается таким:

Code: Select all

for(i=0; i < MAX_СЛОЙ; i ++)
   foreach element in слой(i)
        step(element)

Shaos · Post by **Shaos** » 12 Sep 2012 23:24

Ну кратчайший путь от любого слоя до входа схемы может составлять 0 если вход схемы подключается к какому-то входу компонента в слое напрямую

P.S. А зачем отдельно выделять такую абстракцию как слои? Просто компоненты упорядочены в списке и при шаге симуляции мы просто идём по списку, вызывая у каждого компонента метод step (причём компоненты внутри себя также могут содержать списки своих внутренних компонентов, у которых тоже дёргается step)