nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 29 Mar 2024 06:57



Reply to topic  [ 235 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 16  Next
а не замутить ли нам недосимулятр? 
Author Message
Senior

Joined: 07 Aug 2006 10:18
Posts: 185
Reply with quote
Post 
Глядя на то, как Shaos планирует писать на C, я начинаю завидувать. C++ -- это всё же жесть. Я, как не имеющий пятилетнего опыта профессионального кодинга на C++, не хочу продолжать эти эксперименты -- вчера часа три дебуггером и валгриндом мучал первый набросок: http://desmond.imageshack.us/Himg29/sca ... es=landing
На ровном месте ругается валгринд про использование неинициализированной переменной, и почему, я так и не смог понять. И ладно бы он просто ругался, но иногда, судя по картинкам гейтов, они на самом деле имеют неинициализированные вершины.

Но, поскольку в CEDARLogic-таки нет ничего, что хотелось бы скипипастить, а раз так, то действительно C++ не очень-то и нужен, можно обойтись и pedantic C. И тогда, выбор GUI тулкита ограничивается gtk+-2.x. Всякие Xlib, понятно, я даже не рассматриваю.


26 Aug 2012 03:53
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Post 
Эээ... я какбэ без наездов, но Виталий пророческую байку рассказал... :wink:
VituZz wrote:
Байка в тему. Как-то несколько лет назад на куэрзете собрались несколько крутых программеров сделать для Линуха аналог известной программы N1MM - аппаратный журнал для соревнований. Долго обсуждали концепцию, инструменты, пожелания... Моё предложение пойти по пути последовательного улучшения TLFа, разумеется, показалось смехотворным таким зубрам. И что же ныне? То же, что и до :)..

_________________
iLavr


26 Aug 2012 03:59
Profile
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22422
Location: Silicon Valley
Reply with quote
Post 
bar - скажи подробнее куда глянуть, может я чего увижу...

_________________
:dj: https://mastodon.social/@Shaos


26 Aug 2012 06:21
Profile WWW
Senior

Joined: 07 Aug 2006 10:18
Posts: 185
Reply with quote
Post 
Я вычислил ту проблему. Вот есть такие объявления:
Code:
namespace geometry
{
class point : public primitive
{
public:
   point(float x = 0, float y = 0) : x(x), y(y) {}
   virtual void draw(Cairo::RefPtr<Cairo::Context> cr);
   virtual struct bbox bbox() const {
      return (struct bbox){x, y, x, y};
   }
   float x, y;
};
class line_segment : public primitive
{
public:
   line_segment(float x1, float y1, float x2, float y2) :
      p1(x1, y1), p2(x2, y2) {}
   line_segment(point p1, point p2) : p1(p1), p2(p2) {}
   virtual void draw(Cairo::RefPtr<Cairo::Context> cr);
   virtual struct bbox bbox() const {
      struct bbox ret;
      ret.x1 = std::min(p1.x, p2.x);
      ret.x2 = std::max(p1.x, p2.x);
      ret.y1 = std::min(p1.y, p2.y);
      ret.y2 = std::max(p1.y, p2.y);
      return ret;
   }
   point p1, p2;
};


А фейлящийся код -- это функа:
Code:
void library_parser::on_shape_line(float x1, float y1, float x2, float y2)
{
   geometry::line_segment l(x1, y1, x2, y2);
   gate->shape.push_back(l);
}
Которая вызывается ровно из одного места кода вот так:
Code:
      istringstream iss(cur_char_data);
      float x1, y1, x2, y2;
      char comma;
      iss >> x1 >> comma >> y1 >> comma >> x2 >> comma >> y2;
      on_shape_line(x1 + dx, y1 + dy, x2 + dx, y2 + dy);
}
Дык выяснилось, что dx, dy я не инициализировал. Точнее
инициализировал, но неинициализированными значениями. Как-то я не замечал раньше за валгриндом такой манеры. Давно не пользовался пожалуй.


27 Aug 2012 03:56
Profile
Senior

Joined: 07 Aug 2006 10:18
Posts: 185
Reply with quote
Post 
Lavr wrote:
Эээ... я какбэ без наездов, но Виталий пророческую байку рассказал... :wink:
VituZz wrote:
Байка в тему. Как-то несколько лет назад на куэрзете собрались несколько крутых программеров сделать для Линуха аналог известной программы N1MM - аппаратный журнал для соревнований. Долго обсуждали концепцию, инструменты, пожелания... Моё предложение пойти по пути последовательного улучшения TLFа, разумеется, показалось смехотворным таким зубрам. И что же ныне? То же, что и до :)..
Не, ну а что ты предлагаешь? Я думал о том, чтобы переписать CEDAR, и даже пытался это сделать. Но, с учётом того, что там надо переписывать всё -- а с учётом того, что он где-то имеет проблемы с wxWidgets в процессе сборки, значит вообще всё надо переписывать. И сейчас мне надоело переписывать cedar кусочками, и ваяя очередной кусочек думать о том как его вложить в cedar.
С теми же мьютексами и синхронизацией: ребята, по-моему, вообще с дуба рухнули писать то, что они написали. Есть ими созданная очередь сообщений, на которую подвязана вся работа программы. Они лочат эту очередь, и в течение одного лока начинают выуживать оттуда сообщения и рассылать их дальше. В процессе рассылки какой-нибудь код решает, что ему надо отправить сообщение, пытается залочить очередь, чтобы добавить туда сообщение -- а она уже залочена. Как это у них вообще работало -- я не знаю. Может мьютексы на вендовс позволяют одному треду лочить себя много раз? По науке, тут надо делать гораздо аккуратнее: залочить очередь, вынуть сообщение, разлочить очередь, обработать сообщение. Либо так: залочить очередь, вынуть все сообщения, разлочить очередь, обработать сообщения.
Я сделал по второму варианту -- и, есть у меня предположение, что непонятности в работе CEDAR вызваны именно этим: ведь семантика моего подхода несколько иная: в момент когда весь этот цикл обработки сообщений завершится в очереди могут оставаться необработанные сообщения -- те которые там появились в процессе обработки существующих.
Но если я прав, и именно это вызывает непонятности в работе -- то это же вообще ппц. Привязывать логику работы программы к тому, что сообщения будут обработаны именно в этом вызове OnIdle или OnTimer -- ну это же однозначно получать совершенно непредсказуемое поведение.

Ну вот и что можно сделать со всем этим? Сидеть и переписывать и отлаживать? Или может выкинуть ту очередь, взять систему ивентов из glib и сделать на ней? Но чтобы взять систему ивентов из glib, надо чтобы в программе были бы классы производные от Glib::Object. Да и вообще если с glib, то там всё совершенно иначе делается. Можно, конечно, перепахать CEDAR под ту архитектуру. А потом перепахивать его раз за разом, исправляя то один косяк, то другой. Мне кажется, быстрее и проще написать с нуля.


27 Aug 2012 04:17
Profile
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22422
Location: Silicon Valley
Reply with quote
Post 
можно на обычный юниксовый MessageQueue переписать...

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

_________________
:dj: https://mastodon.social/@Shaos


27 Aug 2012 07:31
Profile WWW
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Post 
bar я какбэ СОВЕРШЕННО без наездов!
Мне наоборот было очень полезно подробно прочитать твои раскопки...

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

Какой же в сраку этот С++ "кроссплатформенный ассемблер" как его постоянно
позиционируют?
Если даже между двумя близкими версиями С++ на одной платформе программу
порой невозможно перенести?
(это я про своих Билдер и MSVC++ 5.0)

А то, что ты взялся делать - для меня выглядело просто героизмом! :o
Ещё раз - я без претензий и с полным уважением... :kruto:

_________________
iLavr


27 Aug 2012 07:38
Profile
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22422
Location: Silicon Valley
Reply with quote
Post 
Кроссплатформенный ассемблер это си - и с ним то как раз всё более-менее нормально (если только будущий стандарт всё не испортит), а C++ это уже другое...

_________________
:dj: https://mastodon.social/@Shaos


27 Aug 2012 12:38
Profile WWW
Senior

Joined: 07 Aug 2006 10:18
Posts: 185
Reply with quote
Post 
Shaos wrote:
можно на обычный юниксовый MessageQueue переписать...
=)
Я никогда этой штукой не пользовался, и даже забыл про её существование. Но, да, она бы хорошо вписалась. Если, конечно, она существует в windows. Бегло погуглил -- есть какие-то сорцы датированные 2000'м годом, которые как заявлено реализуют message queue для Windows NT. Есть ещё boost::interprocess, который включает в себя кроссплатформенную реализацию очереди сообщений, которая на самом деле к POSIX message queue имеет весьма косвенное отношение, но в отзывах о boost::interprocess проскакивают фразы "pretty immature" и "hack around some missing features". Правда это относится к тому, что shared memory нельзя resize'ить, а файловый дескриптор message queue не засунуть в select: и то, и это никакого отношения к CEDAR'у не имеет.
Shaos wrote:
а вообще мьютекс можно создать так, чтобы один и тот же тред мог его лочить много раз - я с этим сталкивался на экзотических операционках для телевизионных приставок...
Судя по-всему, именно такой мьютекс и используется в wxWidgets под вендовс.
Я поначалу думал, что просто wxGTK отличается иным control-flow, скажем wxYield иначе работает -- но так я думал лишь пока на стеке между двумя фреймами функций CEDAR лочащих мьютекс я всегда видел фрейм функции wxYield или ещё какой-нибудь wxФункции. Но когда я увидел ситуацию где между двумя локами на стеке лишь функции CEDAR, то есть управление было передано напрямую, без посредства wxWidgets (и GTK), я понял что дело нечисто.


28 Aug 2012 05:56
Profile
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22422
Location: Silicon Valley
Reply with quote
Post 
Для windows есть ещё cygwin :)
Я собственноручно использовал Message Queue в 2003 году и собирал это под винду в cygwin...
P.S. Вроде бы POSIX message queue несколько отличается от чисто юниховых message queue и поэтому POSIX как-то для этого не используют...

_________________
:dj: https://mastodon.social/@Shaos


28 Aug 2012 06:17
Profile WWW
Senior

Joined: 07 Aug 2006 10:18
Posts: 185
Reply with quote
Post 
Перерыл я полинтернета в поисках кроссплатформенного 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. Посмотрим чё выйдет.


04 Sep 2012 19:22
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Post 
bar wrote:
Но все, почему-то, отказываются поддерживать win9x. Даже tcl/tk с какой-то недавней версии отказался от 9x.
То есть про DOS я вообще молчу, на него все задвинули, по-моему, ещё лет десять назад.

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

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

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

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

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

_________________
iLavr


04 Sep 2012 20:32
Profile
Senior

Joined: 07 Aug 2006 10:18
Posts: 185
Reply with quote
Post 
Lavr wrote:
bar wrote:
Но все, почему-то, отказываются поддерживать win9x. Даже tcl/tk с какой-то недавней версии отказался от 9x.
То есть про DOS я вообще молчу, на него все задвинули, по-моему, ещё лет десять назад.

Если вы имеете ввиду меня - то не загоняйтесь и не утруждайте себя...
У меня реально бесплатного софта под 9x - хватит до моей пенсии. :lol:
Ну, во-первых, убедить меня в том, что существующего софта кому-то может хватить до пенсии не удастся. Это было бы слишком хорошо, чтобы быть правдой. Как говорится: этого не может быть, потому что этого не может быть никогда. Ведь именно из-за того, что софта не хватает, если не мне, то кому-нибудь ещё, я вынужден раз в месяц или даже чаще обновлять систему. Чтоб браузер был бы достаточно новым, чтоб ядро системы было б свежим, чтоб дрова на видяху были бы со всеми распоследними патчами (а то моя видяшка не показывает всего, на что она способна, поскольку 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 со своими видяшками прочно занимает свою нишу и, наступая на пятки первым двум, ни на что больше не претендует.
И тут, на фоне всего этого серого унылого мейнстрима, только и думающего о том, какой бы ещё чип мамки снабдить персональным вентилятором, тут такая свежая струя: векторный гуй общего назначения. Никак нельзя пройти мимо.


04 Sep 2012 21:55
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Post 
Ну, джентльмены, я просто предупредил, чтобы вы не грузились зазря...
Тут и по сути работы - дел хватает, чтобы ещё заморачиваться на ДОС/Венду 9х...

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

_________________
iLavr


04 Sep 2012 22:07
Profile
Senior

Joined: 07 Aug 2006 10:18
Posts: 185
Reply with quote
Post 
bump.

Это я просто, чтобы вы не думали что я забыл про симулятор. =)
Я отвлёкся просто несколько. А сейчас вернулся к проекту, и что-то сразу пошёл спотыкаться по колдобинам: мне всё никак не придумать как лучше представлять схематику в памяти. Чтобы адресовать элементы геометрическими координатами, и при этом иметь возможность работать со схемой как с графом.

То есть дело не безнадёжно, но мысли о том как должно быть мне пока не удаётся причесать до состояния хотя бы издали напоминающее компилируемое. Пришлось даже забросить C++ и перейти к русскому языку. C++ явно не подходит для записи потока сознания.

Да, кстати, провёл небезынтересное исследование какие же существуют 2D алгоритмы для поиска коллизий между полигонами. Излагать в деталях не буду, но просто подметил такую штуку, что если в 3D варианте алгоритмы поиска коллизий излагаются в умных статьях, доступны исключительно в pdf формате, и в качестве языка изложения используют математический, то в случае с 2D, за редким исключением алгоритмы излагаются либо в псевдокоде либо даже на каком-нибудь C или Pascal'е, и нет ничего близкого к попытке обоснования работоспособности алгоритма. В общем и целом, я пришёл к выводу, что ничего проще и надёжнее, чем итерации по всем парам отрезков и проверки их на пересечение нету. Можно быстрее, можно более простым алгоритмом, но уже с потерей необходимых свойств алгоритма, иногда вплоть до полной неработоспособности, как в случае с идеей проверять каждую вершину одного объекта на предмет попадания в многоугольник другого объекта. То есть, если к поиску коллизий в 3D подход технологический (всякая там робототехника очень заинтересована), то в 2D, по-моему, никто кроме писателей маленьких аркадных игрушек не заинтересован. =)


10 Sep 2012 20:15
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 235 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 16  Next

Who is online

Users browsing this forum: No registered users and 20 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.