Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет dibr ([info]dibr)
@ 2007-03-06 20:59:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Всякая фигня
    У нас опять начались дежурства вокруг алмазодобывающей системы - а значит, раз в несколько дней я буду проводить ночь на работе, а день - делать вид что отсыпаться. А ещё - у меня кончились темы. Поэтому сейчас - немного "лытдыбра" :-)

    Программистов - давить!
    Я не программист - в том смысле, что не занимаюсь программированием профессионально (и потому имею право не знать C++ и обходиться классическим, необъектным Си, а также активно использовать подход "а вот тут выделим памяти побольше, и нам хватит навечно"). Поэтому когда написанная мной (на Borland C++ Builder) программа для снятия спектров начала что-то уж слишком часто падать (с чем-то типа "invalid pointer use") - полез, естественно, искать ошибки у себя. Ну, или в крайнем случае - в той dll-ке, что шла с монохроматром и через которую я осуществляю с ним взаимодействие.
    Исследование показало, что программа падает не потому что что-то не так у меня, и не потому что разработчики монохроматора что-то напутали в dll-ке. Исследование показало, что программа падает при попытке нарисовать при помощи борландючего Chart Control график, содержащий точки, имеющие численное значение более нескольких тысяч. Подчеркиваю: не "более нескольких тысяч точек", а "точки, численное значение абсциссы которых больше нескольких тысяч". То есть, при отрисовке графика, состоящего из константы 1111 - всё нормально, а из константы 11111 - программа падает (проверялось именно что заменой переменных на константы в том месте где отрисовывался график, содержимое графика нигде в программе, разумеется, не используется). Причем "чистый" проект, созданный в целях отладки и содержащий такой же chart - падать даже и не думал.
    Я - не программист, и мне надо чтобы работало, пофиг как - кроме меня эту конкретную программу никто (активно) использовать не будет. Поэтому проблема была "решена" нормировкой абсциссы на максимальное значение - теперь я вывожу в график нечто от 0.0 до 1.0, и ничего не падает - но загадка тем не менее осталась. Как можно написать графикопостроительный контрол так, чтобы он устойчиво падал на больших числах (с плавающей точкой, с вашего позволения)?

    Впрочем, с программистами Jobin Yvon (это производители другого монохроматора) - тяжело тягаться даже мне. Они смогли написать программу, которой в принципе даже удобно пользоваться (за исключением некоторых интуитивно-понятных моментов, типа сохранения результатов через правый клик по белому прямоугольнику в углу таблицы с данными, и отказ сохряняться через "file / save as"), и которая даже умеет запоминать несколько "конфигураций эксперимента" в виде xml-файлов (реально умеет, я сам внутрь смотрел). Вот только при попытке загрузки сохраненной конфигурации - с высокой вероятностью падает, если не падает - считывает корректно не все параметры, а при удачном стечении обостоятельств ("неудачная" конфигурация, сохраненная по умолчанию) - устойчиво падает сразу после запуска.
    Впрочем, их я как раз понять могу - судя по всему в качестве "платформы для разработки" у них использовался встроенный язык Microcal Origin (если не путаю название), а если даже у борланда бывают столь интересные глюки, то уж у математического пакета, который зачем-то припахали для задач управления... в-общем, Женька - не ходи в программисты, их все ругают, в том числе тестеры :-)))


    ...А с микрософта, оказывается, можно скачать халявные версии вижуалбэсика, вижуалсипипи, вижуалдодиеза (С#) и вижуалжэпипи (J++, что бы это не означало). На до-диез мне переучиваться, пожалуй, поздновато (хотя - может быть я зря так считаю?), а вот сипипи я сейчас качаю, и на пробу попробую попробовать. Вдруг оно есть хорошо и удобно - для всяких мелких GUIёвых программмок, крупных мне не надо?...

    А ещё - купил себе полуботинки китайского брэнда HEROTANK. Я, наверное, извращенец - но даже увидевши на коробке явно героического вида танк, я сильно не сразу вспомнил о существовании английского слова Hero, и навязчиво думал о какой-то, извините, херотени в плане этого херотанка.
    Обувка, впрочем, оказалась совсем не "херо-", а вполне удобной и прочной. Не знаю насчет танковости, но нитками прошито именно то что должно быть прошито нитками, а подошва состоит из подошвенного материала, а не из кубиков воздуха, скрепленных слоем пластика - что не может не радовать :-)

    А на сегодня всё, и всем кто ложится спать - спокойного сна :-)


(Добавить комментарий)


[info]starcat13@lj
2007-03-06 16:08 (ссылка)
Ну Builder - это глюкало ещё то :(

(Ответить)


[info]natali_42@lj
2007-03-06 17:56 (ссылка)
Ты ярый фанат китайской промышленности - даже удивительно. Что так тебя в их продукции привлекает?

(Ответить) (Ветвь дискуссии)


[info]dibr@lj
2007-03-06 18:18 (ссылка)
[поочередно разглядывая надписи на мыши, клавиатуре, и подвернувшейся под руку звуковухе] вовсе нет. Я ничего не имею против малазии, сингапура, или ещё какой-нибудь кореи. Да хотя бы и России - если бы у нас что нибудь кроме нефти умели бы делать. Но на практике среди "недорогого и неплохого" почему-то чаще других попадается китай, поэтому может казаться что "мне нравится китайская промышленность".

А вот например фотоаппарат и основной объектив у меня - made in japan, и я этим фактом вполне доволен. И предыдущий фотик - тоже made in japan.

А тебя-то чем китайцы не устраивают?

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2007-03-13 15:14 (ссылка)
Я очень люблю китайцев, это вы мне не пришьете! :)

У тебя постоянно промелькивают сообщения то про часы, то про фонарики, то про стельки какие-нибудь из ближайшего газетного киоска. Я в детстве тоже очень любила всякие вещичики - яркие и пластмассовые - как раз то, что видно в витрине этих киосков ребенку. Это сейчас видно только журналы да газеты... Но ты, похоже, очень внимательно исследуешь все витрины? :)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2007-03-14 17:29 (ссылка)
Кстати, в общем-то угадала ;-) На китайские детские игрушки (брелки, фонарики-мигалки, прочую подобную фигню) я часто заглядываюсь - поскольку нередко оказывается, что эти самые брелки-мигалки можно использовать как "источник вдохновения", как источник диодов и прочей мелочёвки, а иногда - даже и по прямому назначению ;-) Так что - нижний ряд витрин газетных киосков мне до сих пор однозначно более интересен, чем верхний. На верхнем - пресса, нафиг она мне... а вот на нижнем... :-)

(Ответить) (Уровень выше)


[info]sleeping_owlet@lj
2007-03-06 18:16 (ссылка)
Это не это, и то не то... Смотри, скоро в тестера превратишься такими темпами ;)

(Ответить) (Ветвь дискуссии)


[info]dibr@lj
2007-03-06 18:23 (ссылка)
Nah. "Все мы - бета-тестеры Микрософт", но я этого избегаю со всей старательностью: дома, например, до сих пор проверенная годами 2000 винда - и даже об ХР пока не задумываюсь, не говоря уже о висте :-)

...а в кармане - два проверенных годами винтажных телефона алкатель. Поскольку бета-тестером современных цветных глюкал я уже побывал - и по результатам молоденькая нокиа 6100 уволена из кармана (с должности "говорильного аппарата") и назначена на должность GPRS-модема (там её глюкофичи пофиг), а на её место принят опять же проверенный временем алкатель :-)

(Ответить) (Уровень выше)

Оффтопик
[info]dibr@lj
2007-03-08 07:08 (ссылка)
Женька, с 8 марта тебя!!! И - счастья, наверное - ибо это, что ни говори важно :-)))

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Оффтопик
[info]sleeping_owlet@lj
2007-03-08 14:54 (ссылка)
Спа-си-бо! :))

(Ответить) (Уровень выше)


[info]jeltz@lj
2007-03-06 23:02 (ссылка)
Не узнаю Вас Дмитрий Борисович!

А где же запал молодости? Кто в детстве хачил stdio.h? Вполне очевидно как горе-программеры могут добиться падения на больших числах! Всего-то навсего в борландючем Chart Control может быть проверка на числовое значение абсциссы, после чего управление идёт по слегка разным веточкам кода. В принципе, достаточно вообще иметь совсем небольшой кусок кода который выполняется _только_ если значение абсциссы велико (или наоборот мало). Зачем такая проверка нужна - не суть. А сценарий очень простой - где-то рушится куча (наиболее вероятный, но не единственный вариант). После этого в одной веточке кода это сходит с рук, а в другой всё с грохотом падает. Проверить это можно SoftIce'ом или другим отладчиком который покажет наличие ветвления после проверки значения абсциссы. Буквально 5-10 бессонных ночей в отладчике и дело в шляпе :)

Особое внимание обрати на то, что вполне возможно кучу (или какой-нибудь другой ресурс выделяемый "per process") разрушаешь ты сам. Потому что, как ты сам проверил, "чистый" проект не падает. Еще полезно погонять разные софты выслеживающие порчу (типа dmalloc, valgrind). Еще полезно иметь ввиду, что обычно после качественного траблшутинга оказывается, что проблема была обусловлена целым комплексом взаимодействующих багов. Такую ситуацию я называю: "баг на баге сидит и багом погоняет". Часто вообще одни баги сглаживают последствия других, в результате чего отдельные багфиксы только ухудшают ситуацию.

А неужели в твоей работе никак нельзя слезть с мелкософта? В других осях (типа линуха) тоже багов хватает, но там с ними легче бороться, imho...

(Ответить) (Ветвь дискуссии)


[info]dibr@lj
2007-03-07 02:48 (ссылка)
Особое внимание обрати на то, что вполне возможно кучу (или какой-нибудь другой ресурс выделяемый "per process") разрушаешь ты сам.

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

А неужели в твоей работе никак нельзя слезть с мелкософта? В других осях (типа линуха) тоже багов хватает, но там с ними легче бороться, imho...

У меня нет уверенности, что win-подсистема в линуксе (а та самая dll-ка, идущая в комплекте с монохроматором - она писана под винду, и даже умеет выкидывать небольшое управлятельное окошко) более предсказуема, чем сама винда. А программки, графики не требующие, я и так cygwin'овским gcc собираю - и всё работает :-)

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

Впрочем, про "неисправную мышь для ком-порта" я уже писал :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312@lj
2007-03-07 04:13 (ссылка)
"разные ветки кода (зачем???)"

Борманы - те еще затейники. В досовском турбопаскале было очень интересное цельночисленное умножение 32-битных чисел - каждый раз (в рантайме!) проверялся тип процессора (<=286 или >=386), и вызывалась соответствующая умножалка. С синусами/косинусами было еще страшнее...

(Ответить) (Уровень выше)


[info]unreal_undead@lj
2007-03-07 05:17 (ссылка)
Если мозги не сильно завязаны на C++ - ИМХО вполне стоит попробовать #. По крайней мере с памятью там всё явно попроще.

(Ответить) (Ветвь дискуссии)


[info]dibr@lj
2007-03-07 17:27 (ссылка)
Мозги на ++ вообще не завязаны - я ж говорю, я плюсы считай вообще не знаю :-) Интересно, насколько он более/менее чем С++ пригоден для разработки приложений "в стиле вижуалбейсика/дельфи/билдера", и насколько прост для начального освоения (знание классического Си наличествует)...

(Ответить) (Уровень выше)


[info]sk_mobile@lj
2007-03-07 16:12 (ссылка)
для простеньких гуевых программок хорош perl+tk (ActiveState perl, например) :)
а если уж си, то для гуи могу посоветовать http://www.fltk.org/, уж лучше чем всякие MFC-ATL...

(Ответить) (Ветвь дискуссии)


[info]dibr@lj
2007-03-07 17:35 (ссылка)
для простеньких гуевых программок хорош perl+tk

Ой нет, только не перл :-) Пробовал я его изучить - мои мозги этого не переносят :-)

а если уж си, то для гуи могу посоветовать http://www.fltk.org/

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

(Ответить) (Уровень выше)

Язык для интефейса.
[info]kergudu@lj
2007-03-07 17:15 (ссылка)
Писать новичку интерфейс на С++ - это из разряда "Как потратить много времеми и сделать (почти) ничего". Как бывший борландист-сионист-плюсовик, затем борландист-дельфинист, затем мелкософто-сионист, и наконец си-шарпец (си-шарпун?) ответственно заявляю, что писать на сишарпе гораздо приятнее чем на чистых плюсах. И пашти таже самая дельфя.

(Ответить) (Ветвь дискуссии)

Re: Язык для интефейса.
[info]dibr@lj
2007-03-07 17:38 (ссылка)
А, то есть там ничего не изменилось за все эти годы - и писать интерфейс всё так же весело как и когда-то? Жаль - я-то не терял надежду, что микрософт рано или поздно сделает Си в стиле билдера/делифи/вибейска :-)

Тогда к черту С++, попробую C#. Не вибейсик же, в самом деле, для rapid application development использовать :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Язык для интефейса.
[info]kergudu@lj
2007-03-07 18:11 (ссылка)
Да, все также. Несколько улучшений есть, типа формы можно ваять стандартным дизайнером, но MFC и ныне там. И навряд ли ситуация для плюсов в микрософтовом мире улучшится. Основное направление сейчас - managed code, особенно для прикладников. А плюсы, по моему мнению, начинают свой путь вслед за ассемблером.

В той же самой студии-экспрессе почти весь интерфейс является managed code, т.е. написан на каком-нибудь .NET языке. Поэтому грузится медленно :)))

(Ответить) (Уровень выше)