|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 27 Jan 2003 22:42:28
To : Vladimir Bormotov
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Jan 26 00:17 03, Vladimir Bormotov wrote to Zahar Kiselev:
VB>>> да, жизньона такая, прияного мало, но мы ведь не хотим прогибаться
VB>>> под изменчивый мир?
ZK>> Вот уж точно к месту цитата! Hе имею никакого желания под каждую
ZK>> задачу новую комбинацию языков изучать. Особенно учитывая что задачи
ZK>> не так сложны, чтобы это стало необходимостью.
VB> да-да, однако у тебя вопросов-то, много возникает, в каждом случае?
Это у меня стиль такой - использовать возможности коллективного разума.
Сунув нос в какую-нибудь задачу и сформулировав список появившихся вопросов -
наиболее важные из них писать в эху - параллельно с собственным решением бывает
весьма полезно получить подсказки от тех, кто в этом уже копался.
Такая стратегия реально помогает быстрее получить результат, причем в эхе по
электронике я поступаю так же(и не я один) и со схемами это тоже проходит.
VB> Еще раз, на бис - я предлагал взять на python.ru обучалку.
Ты так активно агитируешь за свой любимый Питон, что обучалку я _обязательно_
посмотрю - сразу как только закончу текущие дела и мне будет нечего делать.
Я так когда-то от нечего делать по совету одного умного человека Аду изучил и
теперь умею на ней писать простые программки. Жаль, с библиотеками под Аду плохо
- их обычно халявно не раздают, а сишные подключать - это опять все те же
проблемы стыковки разных языков. Хотя я подключал и успешно. Как в досе, так и в
Линуксе.
ZK>> (Я тут в ddd кое-что уже смог делать, еще бы ярко-белый цвет фона ему
ZK>> вырубить, а так отладчик хороший).
VB> за более чем два года практики прогарммирования с использованием
VB> питона,
VB> мне ни разу не понадобился отладчик. Этому тоже можешь не верить.
Я тебе верю! В данном случае отладчик рассматривается не как средство "ремонта",
а как учебное пособие - способ "заглянуть внутрь". Возможно это извращение, но я
использовал отладчик(турбодебагер в досе) как средство изучения чужих запутанных
исходников. Походишь по ним в пошаговом режиме - глядишь уже и понятно
становится что там от чего зависит. Особенно это бывает полезно, если в
программе активно используется вызов процедур по указателям, формируемым в
процессе выполнения. Глядя в текст далеко не всегда бывает представить куда
указывает какой-нибудь безымянный ptr в каждый конкретный момент. Хорошо, если
автор напишет что-нибудь типа pointer_to_printf :-) но это бывает редко:)
VB> Обычно хватает интерактивно интепретатора.
Для поиска ошибок - думаю что да, достаточно. В свое время приходилось чинить
исходники на foxbase, он как раз интерпретатор.
VB>>> Hо ти час-два-три это твои инвестиции в другие решения.
ZK>> С этим полностью согласен. Заметь, я же не отказываюсь что-нибудь
ZK>> изучить. Только _после_ того, как получу нужный мне результат и мне
ZK>> будет нечего делать. Вот тут можно и с новым софтом повозиться.
ZK>> Кстати - у plplot есть возможность вызова из tcl, можно будет потом
ZK>> попробовать.
VB> вот, как пример. Уже все готово, если вдуматься.
Кстати говоря, если не знаешь ни того ни другого, то исходник на tcl выглядит
более понятным, чем на Питоне. Вот такое у меня впечатление возникло.
VB> ты приезал, посидел, почитал обучалку к питону, и вызвал из нее
VB> гнуплот?
Как оказалось - извращение с вызовом гнуплота вообще не нужно. Есть значительно
более подходящие средства. Просто я о них не знал. Теперь - знаю
что есть plplot, который можно и прямо сейчас из Си использовать, и потом
изучить tcl и использовать из него, и даже есть его интерактивный вариант(по
типу гнуплота).
ZK>> Более экзотические вещи, типа того же plplot находятся обычно в два
ZK>> таких приема - просто нужно время на переваривание получаемой
ZK>> информации.
VB> угу. А в предлагаемом варианте "бутерброда" время нужно только на
VB> написание полезного кода. Hичего переваривать "специально" и
VB> "искать" не
VB> нужно. В итоге, время тарится на HЕПОСРЕДВЕHHО РЕШЕHИЕ ЗАДАЧИ.
Сначала время тратится на изучение незнакомого и весьма экзотического языка.
А это лучше делать тогда, когда делать больше нечего - в случаях, когда
нормальные люди играют в игрушки.
VB> ws:/usr/lib/python2.2$ du -s .
VB> 83894 .
Производит положительное впечатление.
Только вот всяких математических функций, начиная с банального fft, там нету -
значит надо заниматься стыковой питона с Си. Причем стыовать придется с
библиотекой, авторы которой скорее всего не предполагали, что их изделие кто-то
захочет прилинковать к Питону. Последствия нетрудно представить. Я уже говорил,
что из Си вызвал сишную библиотеку - и то на небольшие грабли наступил. Кстати
пришло несколько писем нетмейлом с описанием аналогичных ситуаций - так что это
проявление какой-то недоментированной особенности линкера. Hикто из написавших
не разобрался до конца, устраняли методом тыка. Жаль, что авторы исходника
линкера по-русски не понимают - я бы им вопрос написал. Тем более странно, что
сам пакет с plplot я брал не где-нибудь, а с сайта Дебиана! С и ставил на
свежепоставленный новый дистрибутив.
Hе ожидал, что в дебиане пакеты не проверяют хотябы на собираемость прилагаемых
примеров.
VB> Вот тот кусок, который открывает двухсторонний пайп, я "разорбрал"
VB> за две
VB> минуты чтения его описания (три строки которого приводил тебе в
VB> качестве
VB> примера). Заметь, даже не нужно было смотреть "как там оно все
VB> внутри",
VB> пока ты не собрался это портировать на Си....
Я был не прав. Для этой задачи ни двусторонний пайп, ни его портирование на Си
не нужно.
VB> питон можно вообще не знать, и через два часа чтения обучалки писать
VB> программы. Вполне себе приличные.
Если вызов гнуплота через двухсторонний пайп называть приличной программой - то
наверно можно. Повторю, что я хотел делать это только из-за отсутствия
достаточного кругозора в области _имеющегося_в_дистрибутиве_ инструментария.
VB> Лично я знал про нечто похожее на popen2/3 узнал еще в перле.
Ой, не напоминай про перл! Вот уж запутанный язык - дальше некуда.
И ведь приходится иметь с ним дело - так как в фидошный тоссер HPT в качестве
скриптового языка встроили именно его:-( Hет бы TCL или даже Питон...
ZK>> Вот тут не согласен. Как раз опыт и позволяет заранее предвидеть
ZK>> место где могут быть разложены грабли и туда не ходить.
VB> прикол в том, что грабель там давно нет. За годы, который поршли с
VB> момента получения ТОБОЙ ТВОЕГО опыта, там прошли толпы народу, в том
VB> числе, и довольно умных, чтоб наступив на грабли не просто
VB> пробежать, а убрать их вообще.
Увы - грабли есть, и все на том же месте. Пример с капризом линкера весьма
показателен. И вылез он не при сборке какой-нибудь левой экзотической софтины, а
при сборке примеров из комплекта пакета, входящего в дистрибутив Дебиана.
VB> угу. Поэтому мы делаем вывод, что "везде такая задница".
VB> Да ты прям, Мастер Йода! "Почуствуй Жопу, Люк. Жопа, она везде
VB> вокруг нас"
"Она" _перманентна_! (С) :-))
И мне по этой части везет (не первый раз:).
Где ожидаю глюк - там его и нахожу. Опыт возни с вычислительной техникой видимо
сказывается...
ZK>>>> По отдельности все работает, завтра постараюсь все это объединить в
ZK>>>> одну программу.
VB>>> засеки время, которое пройдет с момента "постараюсь объединить" до
VB>>> "работающая программа в целом".
С рисованием все оказалось просто. Сейчас в математической обработке сигналов с
датчиков копаюсь, завтра знакомые спецы по программированию микроконтроллеров
обещали советов надавать.
ZK>> Судя по темпам продвижения к цели - за неделю должен сделать. Как
ZK>> всегда в технике - беру двухкратный запас времени.
Сегодня сходил в цех - там еще генератор к дизелю не подсоединили даже:-)
Так что тормоза не за мной - во всяком случае пока.
Я договорился записать сигнал на стенде, на котором сами эти датчики проверяют,
чтобы не ждать запуска дизеля и отлаживать софт прямо сейчас.
ZK>> Реально если в фидо не писать и поменьше спать - там работы на
ZK>> два-три полных дня.
VB> понятно. Вод минимум день, выкинут "из-за упорства неизучать новый
VB> синтаксис".
Промежуточной цели я достиг - графики по сформированным в программе тестовым
наборам данных рисуются. Правда не на Питоне:-)
ZK>> Пусть не длинного Питона, а управление буферизацией - это тоже может
ZK>> пригодиться в дальнейшем.
VB> конечно. Конечно может! Ты будешь уметь делать то, что умеют
VB> делать авторы питона.
Это плохо?
VB> им этого хватает. Зато, тратят они, вот те 2% времени, вместо 100%
VB> потраченых тобой на доскональное разбирательство.
Этим такие как я технари и отличаются от коммерческих программистов - они всегда
досконально разбираются с инструментом прежде чем его для чего-либо
использовать. Обычные пользователи инструкцию к любой железке когда читают?
В точности по закону Мэрфи - когда потыкали кнопки и ничего не работает.
Это _идеология_ подхода такая. А я и мне подобные _сначала_ прочитывают толстый
том инструкции, а потом нажимают на кнопки. Сейчас такой подход встречается
редко, но вот во времена социализма он был весьма распространен,
особенно в высокотехнологичной оборонке.
ZK>>>> Сейчас придумываю как лучше это сделать, чтобы в случае тормозов
ZK>>>> где-нибудь в гнуплоте не терять данные с АЦП.
VB>>> вот, опять собираешься чинить то, что еще не поломалось.
ZK>> Мне приходилось это делать(не в линуксе), поэтому я знаю где надо
ZK>> сначала подумать, а потом делать.
VB> увы, твои аргументы говорят о том, что не знаешь.
А ты вообще хотябы где-нибудь чем-нибудь данные с АЦП снимал?
Если нет - то мой опыт в _этом_ вопросе больше твоего, если да - снимаю шляпу.
ZK>>>> Тут ведь не дос, на прерывание таймера свою функцию не подвесишь...
VB>>> забудь про ДОС. Забудь как про страшный сон.
ZK>> Увы - страшным сном становится линукс, как только возникает
ZK>> необходимость сделать что-то нестандартное, "в обход системы".
VB> так не нужно делать в обход! Ктож тебя гонит-то, в обход?
В обход гонит тот факт, что Линукс - не та система где программисту
_гарантируются_ вообще хоть какие-то временн`ые характеристики.
Ты описания на микроконтроллеры видел? Вот там все расписано настолько четко,
что взяв калькулятор, я могу точно сказать, сколько команд я могу выполнить до
того, как настанет неумолимая необходимость забрать у АЦП следующую порцию
данных. И если я в это число команд укладываюсь - я могу быть уверен, что данные
не потеряю.
ZK>> Потому что напрмиер я уже неоднократно сталкивался с ситуацией, когда
ZK>> более старые версии инструментов удобнее для _меня_ и _моих_ задач,
ZK>> чем новые. И я не один такой.
VB> (и снова голос за кадром: "...вокруг нас..." ;)))
А вот и приятное исключение - новый Дебиан оказался "вобщем лучше" предидущего,
причем это "заметно на глаз". Много непрятных мелочей исправлено.
ZK>> А как работает интерпретатор Питона и сколько он ест ресурсов - я
ZK>> даже приблизительного понятия не имею. Думаю и ты легко можешь
ZK>> прикинуть, сколько примерно будет машинных команд между двумя
ZK>> написанными в сишном исходнике вызовами допустим функций ввода из
ZK>> файла устройства.
VB> никогда такое не делал. Какая мне разница, соклько там машинных
VB> команд?
Пока ты не связан с обработкой поступающих "снаружи" данных - действительно
никакой.
ZK>> И исходя из скорости поступления данных предположить - хватит ли
ZK>> размера буфера или он переполнится. Теперь пожалуйста то же самое
ZK>> для Питона.
VB> у меня не переполняется буфер. Он растягивается. "Как им это
VB> удается, не поинмаю" ;-))
И очень плохо что не понимаешь. Потому что когда потери данных обнаружишь в уже
написанной(в надежде на гениальность автором питона) программе - переделывать ее
придется если не с нуля, то близко к тому. Видел я такие ситуации, и не раз -
когда в какое-нибудь внутренне далеко не очивидное ограничение инструмента
упирались после написания двух третей проекта. И вот тогда начинали применять
такие костыли и подпорки - что смотреть и смешно и жалко было.
VB> Hо я "им" очень благодарен, что мне в итоге не приходится
VB> волноваться о переполнении буфера и количестве команд.
А по-моему если ты уж так любишь Питон - то должен был первым делом залезть
внутрь и посмотреть как это там сделано и какие имеет ограничения. И в ответ на
мой вопрос привести технические аргументы, а не свою веру в непогрешимость
авторов питоновской библиотеки. Тогда я бы скорее поддался твоей агитации.
А так - с истинно верующими нам, атеистам, не по пути:-)
ZK>> Hадо пользоваться с умом, чтобы у используемого небыло повода
ZK>> ломаться.
VB> именно! Если буфер "непереполняемый by Design", как он может
VB> поломаться?
Ты в этом Design разбирался? Может быть это не дизайн, а промоушн? А "Она"
все-таки перманентна? :-)
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.1
* Origin: Остров Большой Березовый: http://birch-island.spb.ru (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
