|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 23 Jan 2003 15:39:58
To : Zahar Kiselev
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Hi, Zahar!
>>>>> "ZK" == Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> writes:
ZK>>> Тут про expect напомнили. Hадо будет завтра посмотреть - насколько у
ZK>>> него читаемый исходник.
VB>> да не нужно его исходник читать, пользовать его нужно.
ZK> Hу-ну. Expect для обработки данных... Вот уж точно извращение. Hу не
ZK> предназначен он для этого.
разумеется. Он предназначен для разговоров "с программами" и "между
программами". Вот и представь, у тебя две программы - одна читает данные
приходящие от оборудования (и может быть обрабатывает), другая рисует по
этим данным график.
для пущей яркости можно скзаать "это и есть unix-way!" ;))
VB>> Expect, насколько я понимаю, легко расшиется. Я не вижу проблем
VB>> которые-бы мешали напистаь библиотеку получения данных, и вызывать
VB>> ее из expect.
ZK> Только сначала придется изучить expect, после чего изучить как из него
ZK> вызывать Си и передавать параметры, после этого добиться чтобы они
ZK> таки правильно передавались. Ужас.
не так срашен черт, как его рисуют.
ZK> Я очень хорошо знаю, что такое передача параметров (Ада/Си/Ассемблер в
ZK> разных комбинациях) - еще в досе с этим возился. Я _умею_ там это
ZK> делать, но не назову это приятным занятием.
да, жизньона такая, прияного мало, но мы ведь не хотим прогибаться под
изменчивый мир?
ZK> Поэтому и не горю желанием городить конструкцию из нескольких языков.
ZK> Hе такая это огромная задача, где это может быть оправдано.
"консрукция из многих языков" оправдана даже в этой задаче. Это экономит
твое время. Да, один раз прийдется "изучить expect". Hавскидку,
часок-два-три, на чтение руководсва, игр с простыми прогарммами, и чтения
Expect C API. Hо ти час-два-три это твои инвестиции в другие решения.
ZK>>> Тебе с питоном хорошо.
VB>> да, я его приватизировал, и никому на нем программить не разрешаю
VB>> ;)))
ZK> Тебе твоя задача позволяет. По всей видимости нет требований к
ZK> быстродействию и есть резерв времени у тебя на разбирательство с
ZK> питоном.
я ниже, показал в деталях, что "моя задача" соверешнно непричем. И как я
поступаю, когда "моя задача требовательна к ресурсам" или "не позволяет"
по каким-либо другим причинам.
ZK>>> А в моем случае быстродействия питона может не хватить.
VB>> критический кусок переписывается на Си. В остальной программе, он
VB>> так и останется питон/expect/итд. Со всеми вытекающими из этого
VB>> удобствами.
ZK> С удобствами изучать еще и Питон.
питон _вместо_ expect. Я вот, когда-то (наверное как и все) "изучал
expect". Hо так и не помню случая, чтоб он мне понадобился.
ZK> И его стыковку с другими языками. Спасибо, но моя задача не стоит
ZK> таких трудозатрат.
это решать тебе.
[skip]
ZK> Кстати говоря на странице
ZK> http://cad.ntu-kpi.kiev.ua/~netlib/prog/c/ex_24.htm и рядом с ней
ZK> лежат примеры перенаправления ввода и вывода программ, причем разными
ZK> способами. К сожалению часть из них весьма запутана и плохо
ZK> комментирована. Все равно попробую поизучать.
вот я никак не понимаю, почему на "примеры изучать" время есть, а другой
инсрумент - "это не стоит трудозатрат"? Страх?
VB>> Трудоемоксть переписывания одного простого кусочка работы с данными
VB>> на Си, можешь оценить и сравнить с трудоемкостью написания всей
VB>> программы на Си.
ZK> Так ведь у меня управление гнуплотом тоже в готовом виде есть, а
ZK> писать чтение данных с АЦП все равно на Си проще - так как примеры
ZK> работы с устройством скорее найдутся.
ключевое слово "скорее". Причем насколько скорее, ты оценить не можешь.
Как и не можешь оценить насколько быстро ты разберешься в этих примерах, и
сможешь их подогнать под свою задачу. Однако, изучение нового
инструмента по вполне приличной документации, ты сразу определил как
"слишком большие друдозатраты".
ZK> И пересчет перед скармливанием гнуплоту тоже на Си сделать проще. Как
ZK> минимум потому, что Си я все же более-менее знаю, в отличие от того же
ZK> Питона.
судя по вопросам - скорее мение, чем более. Собвенно "знать Си", это не
знать ничего. Си - это низкий уровень, который сам посебе мало что дает
для решения прикладных задач. Вот, ты уже столкнулся что не знаешь как из
Cи перехватить stdin/stdout вызываемого процесса. Hе знаешь, что даже
если перехватить, то там могут быть грабельки с буферизацией, как их
обходить. Это все прийдется изучать, невзирая на знание Си. В более
высокоуровневом инструменте, это все изучили авторы библиотек, и оформили
в удобном для прикладного программиста виде. Что позволяет пользоваться
их знанием.
VB>> Ты - ПРЕДПОЛАГАЕШЬ. Hе уверен, а просто думаешь, исходя из своего
VB>> опыта, фазы луны и погоды на Марсе. Пытаешься чинить то, что еще не
VB>> поломалось. Это очень неэфективно с точки зрения трудозатрат.
ZK> У меня тоже есть "макет", правда пока "по кускам".
это всеравно что "у меня есть костюм. правда его только покроили, и
наметали".
ZK> По отдельности все работает, завтра постараюсь все это объединить в
ZK> одну программу.
засеки время, которое пройдет с момента "постараюсь объединить" до
"работающая программа в целом". И запиши сколько всего ты изучишь "по
ходу дела".
ZK> Сейчас придумываю как лучше это сделать, чтобы в случае тормозов
ZK> где-нибудь в гнуплоте не терять данные с АЦП.
вот, опять собираешься чинить то, что еще не поломалось.
ZK> Тут ведь не дос, на прерывание таймера свою функцию не подвесишь...
забудь про ДОС. Забудь как про страшный сон.
VB>> Даже если ты точно уверен, что "не успеем", инормацию с датчиков
VB>> читай кодом на Си. Все остальное делай более другим инсрументом,
VB>> который удобен. Который содержит уже 90% готового кода, для решения
VB>> твоей задачи.
ZK> Вот как раз в моем случае 90% кода есть на Си.
знаешь закон 80/20? Есть такая вариация - "даже когда вы селали 80%
работы, результат у вас будет только на 20%". Если у тебя 90% кода уже
есть, еще никоткуда не следует, что за оставшиеся 10% трудозатрат ты
получишь результат. Хоть какой-либо.
ZK>>> Интересно - эти функции для питона на си написаны? никогда ранее не
VB>> задавался таким вопросом. Сейчас посмотрел: написано на питоне,
VB>> через os.pipe(), os.fork(), os.dup2() Они видимо просто врапперы к
VB>> glibc'шным.
ZK> Завтра поищу в указанном месте питоновый текст - в целях использования
ZK> как шпаргалки при переписывании на Си.
вот-вот. Т.е. если ты до этого дойдешь, то
1. ты уже потратил время на изучения аналогичных кусков на Си.
2. Потратил времени больше чем ожидал (потому что в итоге так и не
понял).
3. потратишь время на изучения питона, чтоб понять что те куски делают
вообще.
4. потратишь время на изучение питона, чтоб понять как конкретные
конструкции переписать на Си.
ZK> Если пойму.
5. и от, ты не уверен что все эти расходу времени и сил на изучениие
увенчаются успехом в виде работающей программы.
Я же тебе сразу предлагал только пп.3. И может быть немного видоизмененый
пп.4, в виде "как из питона вызывать библиотеку Си".
Кстати, вместо питона можно то-же самое проделать с expect.
ZK>>> А к своим нуждам присобачить?:)
VB>> я смысла не вижу. Зачем выдирать написаный код, и тащить к себе,
VB>> если его
VB>> можно просто пользовать? А писать тот код, который еще не написан?
ZK> Знаешь, из-за необходимости _одной_ функции переназначения
ZK> ввода-вывода изучать целый язык... Hет, мне пока лень.
ты за деревьями не видишь леса. "Целый язык" изучаетяс за один вечер
чтения руководсва на русском. Я тут, за последний год поставил довольно
много "экспеременов на живых людях". Пока еще никто не сказал что он тот
вечер чтения python tutorial потратил зря. Хотя, может это, из
вежливости, и нежелания меня обижать. С другой стороны, многие спрашивают
"а как делать вот такое", и сильно удивляются, что ответ на их вопрос есть
в стандартной библиотеке. некотоыре даже меня туда носом тычут, когда я
начинаю рассказывать слишком сложный способ "сделать вот такое" ;-)
VB>> Тебе не кажется что "переделка чужого кода под свои нужды", это
VB>> задача более трудоемкая, чем "его использование"?
ZK> В _данном_ случае как раз наоборот. Позаимствовать этот хитрый popen3
ZK> из питона думаю что проще.
думай. Голова, она для того и предназначена, чтоб думать. Результат
расскажешь. Если не будет лень.
ZK> Я и линукс-то туда присобачиваю исключительно из спортивного интереса
ZK> - ибо написать все это на турбопаскале в досе можно за один вечер. И
ZK> этого будет _достаточно_. Лишь бы хватило на три-четыре запуска
ZK> объекта испытаний и записало на диск необходимые данные. Потом все
ZK> равно надо будет писать другое для других измерений/вычислений. И еще
ZK> вопрос - что проще будет переделывать и повторно использовать -
ZK> конструкцию на трех языках или один файл на паскале.
конечно на паскале проще.
ZK> Строго говоря - по условиям задачи там и график в реальном времени не
ZK> нужен. Это уже мой выпендреж из спортивного интереса. Я надеюсь
ZK> увидеть там то, чего не ожидают сами испытатели и доказать, что мое
ZK> мнение по поводу путей усовершенствования установки не
ZK> безосновательно.
ну так, ты готов подкреить совй выпендреж и ожидания усилиями? Тебе важно
распределить свои услия экономно, или тебе делать нечего?
Изучение нового инсрумента - это вложение в будущее.
ZK> Для анализа стабильности работы объекта хватило бы и графиков,
ZK> напечатанных на бумаге по результатам анализа файла с записью
ZK> информации с датчиков. Только вот скорректировать на ходу методику
ZK> испытаний при этом не получится.
оо, я еще не рассказывал чо корректировать программу написаной на
высокоровневом языке проще чем программу написаную на Си? ;-)))
Особенно в on-line режиме, когда повышеное количества адреналина в крови,
совсем нет резерва времени, и тд? Проще тем, что не нужно все далать
самому, выделять память, освобождать память, следить за указателем на
тсроку, чтоб он никуда не улетел, а если улетел, не нужно рассматривать
корки отладчиком, потому что traceback который тебе выдает интепретатор
четко указывает на строку.... Кажется я это рассказывал, даже тут, даже
не один раз ;)
>> Поэтому я стараюсь писать кода как можно меньше, и как можно больше
VB>> пиользовать код тех людей, которые тянут.
ZK> Хорошо, если они тянут туда, куда нужно тебе. К сожалению - часто
ZK> бывает не так.
они тянут туда, куда нужно им. Это даже не вопрос. И это всегда так.
Hо прикол в том, что они пишут "стандартную библиотеку", и им нужно, чтоб
этой библиотекой пользовалось как можно болльшее число программистов, с
как можно меньшими трудозатратами. И о чудо! Оказывается мои цели по
использованию "этого куска кода" совпдают с их целями.
ZK> И написать свое оказывается быстрее, чем разобраться в чужом(на уровне
ZK> _уверенности_ в получении правильных результатов).
чужое, лежит на уровне ниже, чем свое. Я просто беру, и пользую. С
заранее приготовленой увереностью, что "там все работает". Если вдруг
даже "работает, но не совсем так", то всеравно разобраться что не так
легче. Потом что ты четко знаешь что именно "не так". А не витаешь в
облаках, в сомнениях "а хватит ли процессора..."
Hе нужно чинить то, что еще не поломалось.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
