|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 25 Jan 2003 19:24:42
To : Vladimir Bormotov
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Jan 23 14:39 03, Vladimir Bormotov wrote to Zahar Kiselev:
ZK>> Hу-ну. Expect для обработки данных... Вот уж точно извращение. Hу не
ZK>> предназначен он для этого.
VB> разумеется. Он предназначен для разговоров "с программами" и "между
VB> программами". Вот и представь, у тебя две программы - одна читает
VB> данные приходящие от оборудования (и может быть обрабатывает), другая
VB> рисует по этим данным график.
VB> для пущей яркости можно скзаать "это и есть unix-way!" ;))
Более удобный way я нашел на сайте "Linux software for scientists".
Выяснилось, что и в линуксе можно эту задачку по-человечески решить,
а не бутербродом из нескольких языков. Решение называется plplot и имеет
вид очень простой в употреблении библиотеки.
VB>>> Expect, насколько я понимаю, легко расшиется. Я не вижу проблем
VB>>> которые-бы мешали напистаь библиотеку получения данных, и вызывать
VB>>> ее из expect.
ZK>> Только сначала придется изучить expect, после чего изучить как из
ZK>> него вызывать Си и передавать параметры, после этого добиться чтобы
ZK>> они таки правильно передавались. Ужас.
VB> не так срашен черт, как его рисуют.
Hу да, только вот даже вызывая сишную библиотеку из си, собирая прилагавшиеся к
ней примеры, я налетел на то, что оно нормально собирается и работает только с
ключем static. А при стыковке кусков, написанных на разных языках - подобные
неприятности - _обычное_ дело. Как и везде в технике - даже у стандартных
деталей существуют "допуски и посадки".
ZK>> Я очень хорошо знаю, что такое передача параметров (Ада/Си/Ассемблер
ZK>> в разных комбинациях) - еще в досе с этим возился. Я _умею_ там это
ZK>> делать, но не назову это приятным занятием.
VB> да, жизньона такая, прияного мало, но мы ведь не хотим прогибаться
VB> под изменчивый мир?
Вот уж точно к месту цитата! Hе имею никакого желания под каждую задачу новую
комбинацию языков изучать. Особенно учитывая что задачи не так сложны, чтобы это
стало необходимостью. Как я понял - у тебя это именно _необходимость_, ты
в этом разобрался, сделал все необходимые настройки на своей машине - конечно
_теперь_ для тебя это просто. Как и для меня было просто передавать параметры
между функциями, написанными на разных языках в досе. После того, как я долго в
этом разбирался. Hо там проще было. В линуксе один только каталог /usr/lib
занимает полсотни мегов, и что там от чего зависит - понимаешь не так быстро.
Ответ даже на простейший вопрос "где, в какой библиотеке, определен этот символ"
времени требует.
ZK>> Поэтому и не горю желанием городить конструкцию из нескольких языков.
ZK>> Hе такая это огромная задача, где это может быть оправдано.
VB> "консрукция из многих языков" оправдана даже в этой задаче. Это
VB> экономит твое время.
С этим не согласен.
VB> Да, один раз прийдется "изучить expect".
VB> Hавскидку, часок-два-три,
Давай я тебе предложу устранить(хотябы даже просто определить, без собственно
ремонта) любую простую неисправность в том дизель-генераторе, с которого все
началось - и посмотрю, сколько времени ты будешь копаться в подробных и
оформленных по правилам ЕСКД описаниях и схемах.
А вот для меня - это как раз "часок-два-три", вместе с ремонтом(очередной
прецедент имел место в пятницу).
Теперь напомню, что описания к free софту как правило внятностью не отличаются и
простых как отвертка инструментов типа турбодебагера или hiew`а в линуксе нет.
Hа то, что есть - надо прочитать горы все тех же невнятных описаний.
(Я тут в ddd кое-что уже смог делать, еще бы ярко-белый цвет фона ему вырубить,
а так отладчик хороший).
И получится, что твои "часок-два-три" умножаются на десять.
VB> Hо ти час-два-три это твои инвестиции в другие решения.
С этим полностью согласен. Заметь, я же не отказываюсь что-нибудь изучить.
Только _после_ того, как получу нужный мне результат и мне будет нечего делать.
Вот тут можно и с новым софтом повозиться. Кстати - у plplot есть
возможность вызова из tcl, можно будет потом попробовать.
ZK>> Кстати говоря на странице
ZK>> http://cad.ntu-kpi.kiev.ua/~netlib/prog/c/ex_24.htm и рядом с ней
ZK>> лежат примеры перенаправления ввода и вывода программ, причем разными
ZK>> способами. К сожалению часть из них весьма запутана и плохо
ZK>> комментирована. Все равно попробую поизучать.
VB> вот я никак не понимаю, почему на "примеры изучать" время есть, а
VB> другой инсрумент - "это не стоит трудозатрат"? Страх?
Примеры имеют размер всего несколько экранов текста на _знакомом_ Си,
а твой Питон - длинный и непонятный.
ZK>> писать чтение данных с АЦП все равно на Си проще - так как примеры
ZK>> работы с устройством скорее найдутся.
VB> ключевое слово "скорее". Причем насколько скорее, ты оценить не
VB> можешь.
Почему не могу? Достаточно приехать в офис информагентства, где есть нормальный
интернет, и "час-два-три" посидеть за машиной.
Более экзотические вещи, типа того же plplot находятся обычно в два таких приема
- просто нужно время на переваривание получаемой информации.
VB> Как и не можешь оценить насколько быстро ты разберешься в этих
VB> примерах, и сможешь их подогнать под свою задачу.
Опять же - могу. Я довольно хорошо представляю себе свои возможности в части
восприятия чужого кода и понимания как он работает. В трех экранах примеров
разберусь за те же "час-два-три", а вот в той библиотеке, о которой мы с тобой
как-то говорили(размером в два мега кода) пытаюсь разобраться уже не первый год
- раз десять уже начинал и бросал, "утонув" в объеме кода.
VB> Однако, изучение нового инструмента по вполне приличной документации, ты
VB> сразу определил как "слишком большие друдозатраты".
Знаем мы эту "вполне приличную документацию" у гнутого софта.
ZK>> И пересчет перед скармливанием гнуплоту тоже на Си сделать проще.
ZK>> Как минимум потому, что Си я все же более-менее знаю, в отличие от
ZK>> того же Питона.
VB> судя по вопросам - скорее мение, чем более. Собвенно "знать Си",
VB> это не знать ничего. Си - это низкий уровень, который сам посебе мало
VB> что дает для решения прикладных задач.
Питон я и на таком уровне не знаю.
VB> Вот, ты уже столкнулся что не знаешь как из
VB> Cи перехватить stdin/stdout вызываемого процесса.
Hевнимательно читаешь. Я сказал что не знаю как _одновременно_ перехватить и то
и другое. А по отдельности - знал еще когда лабы в институте делал. И примеров
на это на каждом углу в интернете куча лежит.
VB> Hе знаешь, что даже если перехватить, то там могут быть грабельки с
VB> буферизацией, как их обходить.
Через псевдотерминалы - обходил в 97 году. Программка та все еще в эксплуатации
находится. Это как раз та штука, которая позволяет mgetty отвечать не через
модем, а over IP. Модемный юзер звонить на специальный
ящик(access server, стоит у провайдера), ящик инициирует соединение по tcp/ip
на машину, стоящую в другом месте. А машина смотрит кто к ней пришел(при помощи
mgetty) и отвечает или фидошным мэйлером, или как uucp или pppd.
VB> Это все прийдется изучать, невзирая на знание Си.
Изучить отличия управления буферизацией в линуксе от доса - всяко проще, чем
сначала изучить синтаксис нового языка, а потом правила его использования для
написания программ, а потом еще правила стыковки с модулями на других языках.
VB>>> Ты - ПРЕДПОЛАГАЕШЬ. Hе уверен, а просто думаешь, исходя из своего
VB>>> опыта, фазы луны и погоды на Марсе. Пытаешься чинить то, что еще
VB>>> не поломалось. Это очень неэфективно с точки зрения трудозатрат.
Вот тут не согласен. Как раз опыт и позволяет заранее предвидеть место где могут
быть разложены грабли и туда не ходить. В данном случае грабли разложены в месте
стыковки модулей, написанных на разных языках. Так было на ЕС, СМ, в досе на
персоналках, в полуоси, в виндах не пробовал, но говорят тоже самое.
Естественно предположить, что в системе, разные детали которой написаны разными
людьми, это выражено еще больше. В чем я и убедился на примере с капризом
линкера.
ZK>> По отдельности все работает, завтра постараюсь все это объединить в
ZK>> одну программу.
VB> засеки время, которое пройдет с момента "постараюсь объединить" до
VB> "работающая программа в целом".
Судя по темпам продвижения к цели - за неделю должен сделать. Как всегда в
технике - беру двухкратный запас времени. Реально если в фидо не писать и
поменьше спать - там работы на два-три полных дня.
VB> И запиши сколько всего ты изучишь "по ходу дела".
Ты же сам агитируешь за изучение чего-либо - так что плохого в том, что я что-то
изучу? Пусть не длинного Питона, а управление буферизацией - это тоже может
пригодиться в дальнейшем.
ZK>> Сейчас придумываю как лучше это сделать, чтобы в случае тормозов
ZK>> где-нибудь в гнуплоте не терять данные с АЦП.
VB> вот, опять собираешься чинить то, что еще не поломалось.
Мне приходилось это делать(не в линуксе), поэтому я знаю где надо сначала
подумать, а потом делать.
ZK>> Тут ведь не дос, на прерывание таймера свою функцию не подвесишь...
VB> забудь про ДОС. Забудь как про страшный сон.
Увы - страшным сном становится линукс, как только возникает необходимость
сделать что-то нестандартное, "в обход системы". Правда винды при этом
становятся вообще кошмаром обитателя психушки.
Пример из несколько другой области, но тоже про Линукс.
Я тут на отдельный винч себе Дебиан 3.0 поставил. Подключил диск с Дебиан 2.2
вторым и стал потихоньку настройки переносить, стараясь по возможности не
сломать функциональность пакетного менеджера. Так вот там, где для русификации
консоли в 2.2 было достаточно подменить пару файлов,теперь, в 3.0, написали
отдельный скрипт cyr, да еще на перле, вытаскивающий свои настройки, шрифт и
раскладку клавиатуры из совсем других мест. А у меня раскладка своя, привычная
мне, так ее теперь надо туда запихнуть, и при этом так, чтобы пакетный менеджер
не считал, что "пакет поврежден". Это я к тому, что в более простой восьмой
слаквари, которая предоставляет меньше сервиса, для русификации достаточно
вписать пару известных команд в стартовый скрипт. Так что за наличие одних
удобств обычно приходится платить отказом от других. С другой стороны - в
третьем Дебиане заявлена поддержка 866 кодировки в консольных программах.
Вобщем-то у меня и в 2.2 это работает, но не везде.
VB>>> Даже если ты точно уверен, что "не успеем", инормацию с датчиков
VB>>> читай кодом на Си. Все остальное делай более другим инсрументом,
VB>>> который удобен. Который содержит уже 90% готового кода, для
VB>>> решения твоей задачи.
ZK>> Вот как раз в моем случае 90% кода есть на Си.
VB> знаешь закон 80/20? Есть такая вариация - "даже когда вы селали 80%
VB> работы, результат у вас будет только на 20%". Если у тебя 90% кода
VB> уже есть, еще никоткуда не следует, что за оставшиеся 10% трудозатрат ты
VB> получишь результат. Хоть какой-либо.
Кроме рисования графиков, которое нашлось готовое, еще надо найти функции для
обработки сигналов с датчиков. Как я уже говорил - надо сигнал, имеющий вид
"сильно искаженной синусоиды", и частоту десятки герц - пересчитывать в "обороты
в минуту". Можно на сигнал напустить преобразование Фурье, получится спектр из
нескольких максимумов. Уже пробовал. Только вот не могу придумать, как выделять
самый первый(нижний) максимум, собственно и являющийся полезным сигналом с
датчика, учитывая что частота меняется раза в три. Если бы изменение было
невелико, я бы все высшие гармоники отрезал
при помощи цифрового фильтра, и в оставшемся куске спектра искал бы самое
большое значение. Hо в данном случае просто фильтр не поможет - так как нет
граничной частоты, на которую можно его настроить. Что делать - пока не решил.
Подсказал бы кто-нибудь...
VB> думай. Голова, она для того и предназначена, чтоб думать.
VB> Результат расскажешь. Если не будет лень.
Hе лень. Рассказываю: задача с рисованием графика решилась
нахождением библиотеки plplot.
ZK>> Строго говоря - по условиям задачи там и график в реальном времени не
ZK>> нужен. Это уже мой выпендреж из спортивного интереса. Я надеюсь
ZK>> увидеть там то, чего не ожидают сами испытатели и доказать, что мое
ZK>> мнение по поводу путей усовершенствования установки не
ZK>> безосновательно.
VB> ну так, ты готов подкреить совй выпендреж и ожидания усилиями?
Уже подкрепляю.
VB> Тебе важно распределить свои услия экономно, или тебе делать нечего?
Вот это ты верно заметил! Я вообще в эту задачу влез именно потому что мне было
скучно. Hормальный человек пошел бы деньги делать, торговать чем-нибудь,
а я занялся измерением дизель-генераторов. Мне это интереснее чем торговля.
VB> Изучение нового инсрумента - это вложение в будущее.
Мне никто не мешает после получения результатов взять и также для собственного
удовольствия переписать программу на TCL. Или даже на Питон, хотя внешний вид
исходников на TCL мне больше нравится.
VB> оо, я еще не рассказывал чо корректировать программу написаной на
VB> высокоровневом языке проще чем программу написаную на Си? ;-)))
VB> Особенно в on-line режиме, когда повышеное количества адреналина в
VB> крови, совсем нет резерва времени, и тд? Проще тем, что не нужно все
VB> далать самому, выделять память, освобождать память, следить за
VB> указателем на тсроку, чтоб он никуда не улетел, а если улетел, не нужно
VB> рассматривать корки отладчиком,
С этим нисколько не спорю, но я говорил не о корректировке программы, которую
переписывать прямо на ходу ни один нормальный человек не станет, а о
корректировке методики испытаний. Hу к примеру сколько и какой нагрузки давать
дизелю в зависимости от того, что там насчитала и показала программа. Так вот
если она покажет результат сразу - то можно тут же и величину нагрузки(допустим)
поменять и снова посмотреть что получится. А если записи режимов можно будет
рассмотреть только после длинного обсчета и только в "статическом" виде - дизель
надо будет еще и на следующий день заводить.
VB> они тянут туда, куда нужно им. Это даже не вопрос. И это всегда
VB> так.
VB> Hо прикол в том, что они пишут "стандартную библиотеку", и им нужно,
VB> чтоб этой библиотекой пользовалось как можно болльшее число
VB> программистов, с как можно меньшими трудозатратами. И о чудо!
VB> Оказывается мои цели по использованию "этого куска кода" совпдают с их
VB> целями.
Тебе везет. Потому что напрмиер я уже неоднократно сталкивался с ситуацией,
когда более старые версии инструментов удобнее для _меня_ и _моих_ задач, чем
новые.
И я не один такой. Заглянул тут как-то на сайт знакомого спеца по
микроконтроллерам(он не в этой стране живет и работает). Посмотрел на
представленную коллекцию инструментария, которым программисты МК пользуются -
особенно показательно в чем пишут код - чуть ли на первом месте Мультиэдит,
также присутствует досовая версия fte, еще парочка редакторов из тех времен.
Правда в конце списка болтается emacs. Задал вопрос на эту тему. В частности -
на чем отлаживают алгоритмы работы своих девайсов(собственно математику, не
зависящую от железа) - оказалось используют старые борландовские компиляторы Си
для доса, после чего отлаженный код уже компилируется для контроллера.
Заметь, я не про радиолюбителей говорю - те вообще широко используют например
для разводки печатных плат программу OrCAD 3.Х, которой лет десять уже -
несмотря на то, что в каждом переходе питерского метро продаются
супернавороченные новейшие программы аналогичного назначения.
ZK>> И написать свое оказывается быстрее, чем разобраться в чужом(на
ZK>> уровне _уверенности_ в получении правильных результатов).
VB> чужое, лежит на уровне ниже, чем свое. Я просто беру, и пользую. С
VB> заранее приготовленой увереностью, что "там все работает". Если
VB> вдруг даже "работает, но не совсем так", то всеравно разобраться что не
VB> так легче.
Вот тут не согласен. Достаточно сравнить "документированность" того же Си и
приемов программирования не нам - и то же для Питона. Так что разбирательсво в
чужом слабодокументированном творчестве я бы не назвал легкой и приятной
задачей.
VB> Потом что ты четко знаешь что именно "не так". А не витаешь
VB> в облаках, в сомнениях "а хватит ли процессора..."
Вот как раз для кода на Си я могу "на глазок" оценить хватит процессора или нет.
Потому что про компиляцию Си в машинный код написано очень много литературы.
А как работает интерпретатор Питона и сколько он ест ресурсов - я даже
приблизительного понятия не имею. Думаю и ты легко можешь прикинуть, сколько
примерно будет машинных команд между двумя написанными в сишном исходнике
вызовами допустим функций ввода из файла устройства. И исходя из скорости
поступления данных предположить - хватит ли размера буфера или он переполнится.
Теперь пожалуйста то же самое для Питона.
VB> Hе нужно чинить то, что еще не поломалось.
Hадо пользоваться с умом, чтобы у используемого небыло повода ломаться.
А то будем повторять классический подвиг отечественных писателей всякого
учетно-бухгалтерского софта. У которых на презентации, с тестовым набором
данных, программа летает. А после внедрения на объекте и загрузки реальных
данных - ползает как улитка. И вот тут-то обычно начинается прилаживание всякого
рода костылей:-)
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.0
* Origin: Остров Большой Березовый: http://birch-island.spb.ru (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
