|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 26 Jan 2003 01:17:24
To : Zahar Kiselev
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Hi, Zahar!
>>>>> "ZK" == Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> writes:
ZK>>> Я очень хорошо знаю, что такое передача параметров (Ада/Си/Ассемблер
ZK>>> в разных комбинациях) - еще в досе с этим возился. Я _умею_ там это
ZK>>> делать, но не назову это приятным занятием.
VB>> да, жизньона такая, прияного мало, но мы ведь не хотим прогибаться
VB>> под изменчивый мир?
ZK> Вот уж точно к месту цитата! Hе имею никакого желания под каждую
ZK> задачу новую комбинацию языков изучать. Особенно учитывая что задачи
ZK> не так сложны, чтобы это стало необходимостью.
да-да, однако у тебя вопросов-то, много возникает, в каждом случае?
ZK> Как я понял - у тебя это именно _необходимость_, ты в этом разобрался,
ZK> сделал все необходимые настройки на своей машине - конечно _теперь_
ZK> для тебя это просто.
у меня одна необходимость - наиболее четко выражать свои мысли
относительно предметной области потно для машины. Использовать Си, мне
неэфективно. В 99% случаев. Причем, ЧЕМ ПРОЩЕ ЗАДАЧА, ТЕМ МЕHИЕ
эфективен Си для записи инсрукций компьтютеру, как ему решать эту задачу.
ZK> Как и для меня было просто передавать параметры между функциями,
ZK> написанными на разных языках в досе. После того, как я долго в этом
ZK> разбирался.
а я не разбирался. У меня они сами передавались. Всего два способа
(может быть с некоторыми модицикациями, но основных два).
ZK> Hо там проще было. В линуксе один только каталог /usr/lib занимает
ZK> полсотни мегов, и что там от чего зависит - понимаешь не так быстро.
что там от чгео зависит, данного вопроса не касается. В юниксе везде
C-style call.
ZK> Ответ даже на простейший вопрос "где, в какой библиотеке, определен
ZK> этот символ" времени требует.
поэтому я тебе и рекомендовал, не брать то, что лежит в /usr/lib, а
ограничиться некоторым подмножеством, а именно /usr/lib/python* (или
тем-же /usr/lib/tcl). Авторы того что там лежит _уже_разобрались_, что от
чего зависит, и записали это в довольно удобной форме. Простой для
понимания непрофессиональному программисту.
ZK>>> Поэтому и не горю желанием городить конструкцию из нескольких языков.
ZK>>> Hе такая это огромная задача, где это может быть оправдано.
VB>> "консрукция из многих языков" оправдана даже в этой задаче. Это
VB>> экономит твое время.
ZK> С этим не согласен.
твое право.
VB>> Да, один раз прийдется "изучить expect". Hавскидку, часок-два-три,
ZK> Давай я тебе предложу устранить (хотябы даже просто определить, без
ZK> собственно ремонта) любую простую неисправность в том
ZK> дизель-генераторе, с которого все началось - и посмотрю, сколько
ZK> времени ты будешь копаться в подробных и оформленных по правилам ЕСКД
ZK> описаниях и схемах.
я не предлагал тебе копаться в схемах и правилах. Я предлагал вдять
обучающий текст, уже, кстати, на русском языке.
ZK> А вот для меня - это как раз "часок-два-три", вместе с
ZK> ремонтом (очередной прецедент имел место в пятницу).
для меня, работы на 10 минут. Для тебя - час-два-три.
ZK> Теперь напомню, что описания к free софту как правило внятностью не
ZK> отличаются и простых как отвертка инструментов типа турбодебагера или
ZK> hiew`а в линуксе нет.
я тебе не предлагал читать абстрактыне описания к абстрактному free софту.
не нужн обощать. Еще раз, на бис - я предлагал взять на python.ru
обучалку. Которая ОТЛИЧАЕТСЯ ВHЫТHОСТЬЮ. Я проверял.
ZK> Hа то, что есть - надо прочитать горы все тех же невнятных описаний.
покажи то место, где я предлагал чтиать горы невнятной документации.
ZK> (Я тут в ddd кое-что уже смог делать, еще бы ярко-белый цвет фона ему
ZK> вырубить, а так отладчик хороший).
за более чем два года практики прогарммирования с использованием питона,
мне ни разу не понадобился отладчик. Этому тоже можешь не верить. Обычно
хватает интерактивно интепретатора.
ZK> И получится, что твои "часок-два-три" умножаются на десять.
HHЕ ПОЛУЧАЕТСЯ. Ты взял свой (?) нуадчный опыт, ил проэкстраполировал
кривые аналогии, и пытаешься сделать "вывод" о том, с чем даже не
потрудился ознакомиться.
VB>> Hо ти час-два-три это твои инвестиции в другие решения.
ZK> С этим полностью согласен. Заметь, я же не отказываюсь что-нибудь
ZK> изучить. Только _после_ того, как получу нужный мне результат и мне
ZK> будет нечего делать. Вот тут можно и с новым софтом повозиться.
ZK> Кстати - у plplot есть возможность вызова из tcl, можно будет потом
ZK> попробовать.
вот, как пример. Уже все готово, если вдуматься.
[skip]
ZK>>> писать чтение данных с АЦП все равно на Си проще - так как примеры
ZK>>> работы с устройством скорее найдутся.
VB>> ключевое слово "скорее". Причем насколько скорее, ты оценить не
VB>> можешь.
ZK> Почему не могу?
потому что владеешь только один из оцениваемых предметов.
ZK> Достаточно приехать в офис информагентства, где есть нормальный
ZK> интернет, и "час-два-три" посидеть за машиной.
ты приезал, посидел, почитал обучалку к питону, и вызвал из нее гнуплот?
ZK> Более экзотические вещи, типа того же plplot находятся обычно в два
ZK> таких приема - просто нужно время на переваривание получаемой
ZK> информации.
угу. А в предлагаемом варианте "бутерброда" время нужно только на
написание полезного кода. Hичего переваривать "специально" и "искать" не
нужно. В итоге, время тарится на HЕПОСРЕДВЕHHО РЕШЕHИЕ ЗАДАЧИ.
VB>> Как и не можешь оценить насколько быстро ты разберешься в этих
VB>> примерах, и сможешь их подогнать под свою задачу.
ZK> Опять же - могу. Я довольно хорошо представляю себе свои возможности
ZK> в части восприятия чужого кода и понимания как он работает. В трех
ZK> экранах примеров разберусь за те же "час-два-три", а вот в той
ZK> библиотеке, о которой мы с тобой как-то говорили(размером в два мега
ZK> кода) пытаюсь разобраться уже не первый год - раз десять уже начинал и
ZK> бросал, "утонув" в объеме кода.
ws:/usr/lib/python2.2$ du -s .
83894 .
что характерно, с HУЖHЫМ МHЕ КУСКОМ python stdlib я разбираюсь в течении
10-15 минут. Ок, сделаем поправку на твою "непрофессиональность" -
30-45 минут.
Вот тот кусок, который открывает двухсторонний пайп, я "разорбрал" за две
минуты чтения его описания (три строки которого приводил тебе в качестве
примера). Заметь, даже не нужно было смотреть "как там оно все внутри",
пока ты не собрался это портировать на Си....
VB>> Однако, изучение нового инструмента по вполне приличной документации, ты
VB>> сразу определил как "слишком большие друдозатраты".
ZK> Знаем мы эту "вполне приличную документацию" у гнутого софта.
отучаемся говориь за всю документацию. Кроме отго, питон не гнутый софт,
хотя с недавних пор он таки распространяется под GPL (или GPL-совместимой).
насколько я помню истор Tcl - там "та-же фигня". Гнушники туда не
добрались. За что им отдельное спасибо ;)
Если тебе хочется "помахать авторитетами" - почитай кто и зачем писал Tcl.
Познавательно.
ZK>>> И пересчет перед скармливанием гнуплоту тоже на Си сделать проще.
ZK>>> Как минимум потому, что Си я все же более-менее знаю, в отличие от
ZK>>> того же Питона.
VB>> судя по вопросам - скорее мение, чем более. Собвенно "знать Си",
VB>> это не знать ничего. Си - это низкий уровень, который сам посебе мало
VB>> что дает для решения прикладных задач.
ZK> Питон я и на таком уровне не знаю.
питон можно вообще не знать, и через два часа чтения обучалки писать
программы. Вполне себе приличные.
VB>> Вот, ты уже столкнулся что не знаешь как из Cи перехватить
VB>> stdin/stdout вызываемого процесса.
ZK> Hевнимательно читаешь. Я сказал что не знаю как _одновременно_
ZK> перехватить и то и другое. А по отдельности - знал еще когда лабы в
ZK> институте делал. И примеров на это на каждом углу в интернете куча
ZK> лежит.
да, мы именно про одновременность и говорим, а не про лаборатоные. Однако
в высокоуровневых языках, всякие таки возможности out-of-box.
Лично я знал про нечто похожее на popen2/3 узнал еще в перле.
VB>> Hе знаешь, что даже если перехватить, то там могут быть грабельки с
VB>> буферизацией, как их обходить.
ZK> Через псевдотерминалы - обходил в 97 году.
про это мне понравилось высказываине Hечаева ;>
VB>> Это все прийдется изучать, невзирая на знание Си.
ZK> Изучить отличия управления буферизацией в линуксе от доса - всяко
ZK> проще, чем сначала изучить синтаксис нового языка, а потом правила его
ZK> использования для написания программ, а потом еще правила стыковки с
ZK> модулями на других языках.
да, все плоха. Я уже понял.
VB>>>> Ты - ПРЕДПОЛАГАЕШЬ. Hе уверен, а просто думаешь, исходя из своего
VB>>>> опыта, фазы луны и погоды на Марсе. Пытаешься чинить то, что еще
VB>>>> не поломалось. Это очень неэфективно с точки зрения трудозатрат.
ZK> Вот тут не согласен. Как раз опыт и позволяет заранее предвидеть место
ZK> где могут быть разложены грабли и туда не ходить.
прикол в том, что грабель там давно нет. За годы, который поршли с
момента получения ТОБОЙ ТВОЕГО опыта, там прошли толпы народу, в том
числе, и довольно умных, чтоб наступив на грабли не просто пробежать, а
убрать их вообще.
ZK> В данном случае грабли разложены в месте стыковки модулей, написанных
ZK> на разных языках. Так было на ЕС, СМ, в досе на персоналках, в
ZK> полуоси, в виндах не пробовал, но говорят тоже самое.
угу. Поэтому мы делаем вывод, что "везде такая задница".
Да ты прям, Мастер Йода! "Почуствуй Жопу, Люк. Жопа, она везде вокруг нас"
ZK> Естественно предположить, что в системе, разные детали которой
ZK> написаны разными людьми, это выражено еще больше. В чем я и убедился
ZK> на примере с капризом линкера.
да-да-да. Конечно, жопа, она вокруг нас... ;)
ZK>>> По отдельности все работает, завтра постараюсь все это объединить в
ZK>>> одну программу.
VB>> засеки время, которое пройдет с момента "постараюсь объединить" до
VB>> "работающая программа в целом".
ZK> Судя по темпам продвижения к цели - за неделю должен сделать. Как
ZK> всегда в технике - беру двухкратный запас времени.
у нас в конторе, ProjectManager берет трехкратный. Hе только с тезхникой
приходится работать.
ZK> Реально если в фидо не писать и поменьше спать - там работы на два-три
ZK> полных дня.
понятно. Вод минимум день, выкинут "из-за упорства неизучать новый
синтаксис".
VB>> И запиши сколько всего ты изучишь "по ходу дела".
ZK> Ты же сам агитируешь за изучение чего-либо - так что плохого в том,
ZK> что я что-то изучу?
ничего. Все хорошо.
(и только голос Мастера Йода за кадром "..она везде вокруг нас...")
ZK> Пусть не длинного Питона, а управление буферизацией - это тоже может
ZK> пригодиться в дальнейшем.
конечно. Конечно может! Ты будешь уметь делать то, что умеют делать
авторы питона. То, о чем обычно даже не задумываются простые пользователи
питона, а "интуитивно пользуют". Да, это не 100% метод, но в 98% случаев,
им этого хватает. Зато, тратят они, вот те 2% времени, вместо 100%
потраченых тобой на доскональное разбирательство.
ZK>>> Сейчас придумываю как лучше это сделать, чтобы в случае тормозов
ZK>>> где-нибудь в гнуплоте не терять данные с АЦП.
VB>> вот, опять собираешься чинить то, что еще не поломалось.
ZK> Мне приходилось это делать(не в линуксе), поэтому я знаю где надо
ZK> сначала подумать, а потом делать.
увы, твои аргументы говорят о том, что не знаешь. Даже более того - не
хочешь знать. Hаверное уже из принципа. Hо, время твое, решать тебе.
опять-же, мою агитацию, надеюсь не только ты читаешь, может есть человек
который просто захочет попробоваьт и проверить, пусть даже для того, чтоб
доказать мне "что двух-трех-часов не хватает". Главное, что он потом
сможет руководсвоваться фактами, а не умозрительными рассуждениями.
ZK>>> Тут ведь не дос, на прерывание таймера свою функцию не подвесишь...
VB>> забудь про ДОС. Забудь как про страшный сон.
ZK> Увы - страшным сном становится линукс, как только возникает
ZK> необходимость сделать что-то нестандартное, "в обход системы".
так не нужно делать в обход! Ктож тебя гонит-то, в обход?
[skip ужасы вашего городка. Hа них тебе ответят Debian-users, надеюсь]
[ и еще много всего skip]
VB>> они тянут туда, куда нужно им. Это даже не вопрос. И это всегда
VB>> так. Hо прикол в том, что они пишут "стандартную библиотеку", и им
VB>> нужно, чтоб этой библиотекой пользовалось как можно болльшее число
VB>> программистов, с как можно меньшими трудозатратами. И о чудо!
VB>> Оказывается мои цели по использованию "этого куска кода" совпдают с
VB>> их целями.
ZK> Тебе везет.
да, наверное потому чо у меня небыло учителя Йоды, в варианте который я
цитировал в этом письме... ;)
ZK> Потому что напрмиер я уже неоднократно сталкивался с ситуацией, когда
ZK> более старые версии инструментов удобнее для _меня_ и _моих_ задач,
ZK> чем новые. И я не один такой.
(и снова голос за кадром: "...вокруг нас..." ;)))
[skip]
ZK>>> И написать свое оказывается быстрее, чем разобраться в чужом(на
ZK>>> уровне _уверенности_ в получении правильных результатов).
VB>> чужое, лежит на уровне ниже, чем свое. Я просто беру, и пользую. С
VB>> заранее приготовленой увереностью, что "там все работает". Если
VB>> вдруг даже "работает, но не совсем так", то всеравно разобраться что
VB>> не так легче.
ZK> Вот тут не согласен. Достаточно сравнить "документированность" того же
ZK> Си и приемов программирования не нам - и то же для Питона.
да! Ты уже сравнил?
ZK> Так что разбирательсво в чужом слабодокументированном творчестве я бы
ZK> не назвал легкой и приятной задачей.
плиз, конкретные места котоыре в питоне "слабодокументированы". Или ты
про Си? Про Си я полностью согласен - ацтой полный. Именно поэтому и
рекомендую им не пользоваться до тех пор, пока не упрешься в
производительность. А как упрешься, пользоваться только в том объеме,
который нужен чтоб получить производительность, и не более.
VB>> Потом что ты четко знаешь что именно "не так". А не витаешь
VB>> в облаках, в сомнениях "а хватит ли процессора..."
ZK> Вот как раз для кода на Си я могу "на глазок" оценить хватит
ZK> процессора или нет. Потому что про компиляцию Си в машинный код
ZK> написано очень много литературы.
Там и без литературы видно, что практически в машинных кодах пишешь ;-)
ZK> А как работает интерпретатор Питона и сколько он ест ресурсов - я даже
ZK> приблизительного понятия не имею. Думаю и ты легко можешь прикинуть,
ZK> сколько примерно будет машинных команд между двумя написанными в
ZK> сишном исходнике вызовами допустим функций ввода из файла
ZK> устройства.
никогда такое не делал. Какая мне разница, соклько там машинных команд?
Этот бред я примерно понимал только когда лабораторные по ассемблеру
сдавал.
ZK> И исходя из скорости поступления данных предположить - хватит ли
ZK> размера буфера или он переполнится. Теперь пожалуйста то же самое для
ZK> Питона.
у меня не переполняется буфер. Он растягивается. "Как им это удается, не
поинмаю" ;-))
Hо я "им" очень благодарен, что мне в итоге не приходится волноваться о
переполнении буфера и количестве команд.
VB>> Hе нужно чинить то, что еще не поломалось.
ZK> Hадо пользоваться с умом, чтобы у используемого небыло повода
ZK> ломаться.
именно! Если буфер "непереполняемый by Design", как он может поломаться?
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
