|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 23 Jan 2003 04:42:38
To : Vladimir Bormotov
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Jan 23 02:55 03, Vladimir Bormotov wrote to Zahar Kiselev:
ZK>>>> В моем случае важен сам факт окончания исполнения текущей команды -
ZK>>>> чтобы не "кормить" гнуплот данными быстрее, чем он их в состоянии
ZK>>>> пережевывать (а делает он это в случае простого двумерного графика
ZK>>>> весьма быстро).
VB>>> понятно.
ZK>> А тут еще невыключаемой буферизацией в stdin/stdout пугают...
VB> обратил внимание на необязательный параметр bufsize, в вызовах
VB> popen2/popen3/popen4 ?
Вот и я о том же - должна она если не совсем выключаться, то сводиться к
минимуму.
ZK>> Тут про expect напомнили. Hадо будет завтра посмотреть - насколько у
ZK>> него читаемый исходник.
VB> да не нужно его исходник читать, пользовать его нужно.
Hу-ну. Expect для обработки данных... Вот уж точно извращение.
Hу не предназначен он для этого.
VB> Expect, насколько я понимаю, легко расшиется. Я не вижу проблем
VB> которые-бы мешали напистаь библиотеку получения данных, и вызывать
VB> ее из expect.
Только сначала придется изучить expect, после чего изучить как из него вызывать
Си и передавать параметры, после этого добиться чтобы они таки правильно
передавались. Ужас. Я очень хорошо знаю, что такое передача
параметров (Ада/Си/Ассемблер в разных комбинациях) - еще в досе с этим возился.
Я _умею_ там это делать, но не назову это приятным занятием.
Поэтому и не горю желанием городить конструкцию из нескольких языков.
Hе такая это огромная задача, где это может быть оправдано.
ZK>> Тебе с питоном хорошо.
VB> да, я его приватизировал, и никому на нем программить не разрешаю
VB> ;)))
Тебе твоя задача позволяет. По всей видимости нет требований к быстродействию и
есть резерв времени у тебя на разбирательство с питоном.
ZK>> А в моем случае быстродействия питона может не хватить.
VB> критический кусок переписывается на Си. В остальной программе, он
VB> так и останется питон/expect/итд. Со всеми вытекающими из этого
VB> удобствами.
С удобствами изучать еще и Питон. И его стыковку с другими языками. Спасибо, но
моя задача не стоит таких трудозатрат.
VB> // лирическое отступление:
VB> // ради хохмы сходил на www.python.org/search и в сделал поиск на
VB> // Vault Of Parnasus (это зачатки типа CPAN) слова "gnuplot"
VB> // http://www.vex.net/parnassus/apyllo.py?so=d&find=gnuplot
VB> // последний линк: http://gnuplot-py.sourceforge.net/
VB> // Intro
VB> // Gnuplot.py is a Python package that interfaces to gnuplot, the
VB> popular
VB> // open-source plotting program. It allows you to use gnuplot from
VB> within
VB> // Python to plot arrays of data from memory, data files, or
Hу так я и для Си такой интерфейс нашел и уже проверил как работает.
И оно _работает_. Другое дело, что я не имею полной уверенности что оно будет
правильно работать на моей задаче из-за отсутствия "обратной связи по
переполнению". Так и интерфейс к Питону "на максимальной скорости" скорее всего
никто не тестировал.
VB> including to create crude `animations' by
VB> plotting
VB> different datasets one after another.
Пример _такой_ анимации есть и в найденном мной исходнике на Си.
Hо это не означает, что вся эта конструкция не загнется, когда я начну
прокачивать через нее мегабайты информации с датчиков. Судя по результатам
двухдневного сидения в гугле - так над гнуплотом еще никто не извращался.
Кстати говоря на странице
http://cad.ntu-kpi.kiev.ua/~netlib/prog/c/ex_24.htm
и рядом с ней лежат примеры перенаправления ввода и вывода программ, причем
разными способами. К сожалению часть из них весьма запутана и плохо
комментирована. Все равно попробую поизучать.
VB> Трудоемоксть переписывания одного
VB> простого кусочка работы с данными на Си, можешь оценить и сравнить с
VB> трудоемкостью написания всей программы на Си.
Так ведь у меня управление гнуплотом тоже в готовом виде есть, а писать чтение
данных с АЦП все равно на Си проще - так как примеры работы с устройством скорее
найдутся. И пересчет перед скармливанием гнуплоту тоже на Си сделать проще. Как
минимум потому, что Си я все же более-менее знаю, в отличие от того же Питона.
ZK>> Все же информация с датчиков довольно быстро поступает, а процессора
ZK>> больше 300мгц я под это не найду.
VB> Заметь, к тому моменту, как у меня возник вопрос
VB> _производительности_, я
VB> имел _рабочую_программу_ (если угодно - полнофункциональный макет
VB> программы).
VB> И четко знал "вопрос скорости возник". Ты - ПРЕДПОЛАГАЕШЬ. Hе
VB> уверен, а
VB> просто думаешь, исходя из своего опыта, фазы луны и погоды на Марсе.
VB> Пытаешься чинить то, что еще не поломалось. Это очень неэфективно с
VB> точки
VB> зрения трудозатрат.
У меня тоже есть "макет", правда пока "по кускам". По отдельности все работает,
завтра постараюсь все это объединить в одну программу. Сейчас придумываю как
лучше это сделать, чтобы в случае тормозов где-нибудь в гнуплоте не терять
данные с АЦП. Тут ведь не дос, на прерывание таймера свою функцию не
подвесишь...
VB> Даже если ты точно уверен, что "не успеем", инормацию с датчиков
VB> читай кодом на Си. Все остальное делай более другим инсрументом,
VB> который удобен. Который содержит уже 90% готового кода, для решения
VB> твоей задачи.
Вот как раз в моем случае 90% кода есть на Си.
ZK>> Интересно - эти функции для питона на си написаны?
VB> никогда ранее не задавался таким вопросом.
VB> Сейчас посмотрел: написано на питоне, через os.pipe(), os.fork(),
VB> os.dup2()
VB> Они видимо просто врапперы к glibc'шным.
Завтра поищу в указанном месте питоновый текст - в целях использования как
шпаргалки при переписывании на Си. Если пойму.
ZK>> А к своим нуждам присобачить?:)
VB> я смысла не вижу. Зачем выдирать написаный код, и тащить к себе,
VB> если его
VB> можно просто пользовать? А писать тот код, который еще не написан?
Знаешь, из-за необходимости _одной_ функции переназначения ввода-вывода изучать
целый язык... Hет, мне пока лень.
VB> Тебе не кажется что "переделка чужого кода под свои нужды", это
VB> задача более трудоемкая, чем "его использование"?
В _данном_ случае как раз наоборот. Позаимствовать этот хитрый popen3 из
питона думаю что проще.
VB> Кроме того, время идет, инсрументарий развивается. Ты свой
VB> кгод будешь "тянуть в ногу со временем"? Мне лень.
А мне просто не нужно. Hе стоит такой задачи. Это не коммерция, а наука, а там
спешить не принято.
Я и линукс-то туда присобачиваю исключительно из спортивного интереса - ибо
написать все это на турбопаскале в досе можно за один вечер. И этого будет
_достаточно_. Лишь бы хватило на три-четыре запуска объекта испытаний и записало
на диск необходимые данные. Потом все равно надо будет писать другое для других
измерений/вычислений. И еще вопрос - что проще будет переделывать и повторно
использовать - конструкцию на трех языках или один файл на паскале.
Строго говоря - по условиям задачи там и график в реальном времени не нужен. Это
уже мой выпендреж из спортивного интереса. Я надеюсь увидеть там то, чего не
ожидают сами испытатели и доказать, что мое мнение по поводу путей
усовершенствования установки не безосновательно.
Для анализа стабильности работы объекта хватило бы и графиков, напечатанных на
бумаге по результатам анализа файла с записью информации с датчиков. Только вот
скорректировать на ходу методику испытаний при этом не получится.
> Поэтому я стараюсь писать кода как можно меньше, и как можно больше
VB> пиользовать код тех людей, которые тянут.
Хорошо, если они тянут туда, куда нужно тебе. К сожалению - часто бывает не так.
И написать свое оказывается быстрее, чем разобраться в чужом(на уровне
_уверенности_ в получении правильных результатов).
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.0
* Origin: Остров Большой Березовый: http://birch-island.spb.ru (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
