subject:"Re\: Функционал и интерфейс"

Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
13:50:42 +:

И на каждое выделение памяти. Вверх по всему стеку вызовов.

ПК Если не увлекаться вызовом malloc() inline, а каждый объект
ПК делать набор функций create, destroy и т.д. то это не много и
ПК оправдано. Кстати, разделяя функционал от интерфейса и выделив
ПК библиотеку, так даже проще.

Любая попытка выделить память может закончиться неудачей. И называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во всех
книжках по C++ - что будет, если ошибка произойдет в момент, когда
память выделена под _часть_ подобъектов?

ПК Если ты программист Си - решать тебе что будет.

ПК Что значит успело выделиться? Само оно не выделяется, по крайней
ПК мере в Си.

На примере gtk.

Как ты создаешь композитный виджет? Создаешь внутренние, и делаешь им
add. По очереди. Если у тебя обломалость по недостатку памяти создание
второго внутреннего виджета, ты перед возвратом должен только прибить
внешний. А вот если обломался его add, то удаления внешнего для
освобождения памяти внутреннего недостаточно - он же не добавился. Надо
его destroy вручную. И так с каждым.

Нет, тут тоже
существует обходной маневр. Ценой определенной дисциплины организации
функций, пары-тройки макросов для поддержки оной дисциплины и нескольких
дополнительных строчек на каждое выделение.

ПК Так и получается когда программист не знает как оно
ПК работает. Тогда да, и само выделяется, и выслеживать надо.

А, ты предпочитаешь просто забить на утечки памяти? Здравствуй, Mozilla
firefox... Они, видимо, тоже. В результате его больше трех суток без
перезапуска держать, гм, не рекомендуется.

ПК Мне, например, не нравится как такие ситуации отработал
ПК spamassassin написанный на perl. Смотри тред OOM-Killer. С
ПК perl'ом даже OOM-Killer не справился.

А это - проблема, перпендикулярная. Если тебе в сишной программе
понадобилась память - ты ее точно так же будешь запрашивать.

ПК Один раз, потом верну ошибку назад по стеку, там пусть решают что
ПК делать.

А там пожмут плечами и начнут следующую итерацию главного цикла. В
которой снова запросят память...

ПК У Perl'а своя ниша, и он хорош пока от туда не вылазит.

Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что
C из своей ниши вылазит...

ПК Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
ПК клиентские, десктопные приложения, и т.д.

То-то у меня ipw2200 не работает больше полутора суток, firefox через
неделю работы приходится прибивать kill -9, потому что на штатное
завершение ему получаса не хватает, а у тебя snmpd жрет 10% CPU...

Но почему драйвера пишут на C и почему криптографию пишут на ассемблере
с сишной обвязкой, хотя бы можно обосновать. Рантайм от более серьезных
языков там действительно слишком тяжел. А все остальное - не от
большого ума.

Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
это бывает оправдано...)

ПК А это как?

command
if [[ $? == ... ]]; then
...
fi

И т.п. Это если как писать. Если когда оправдано - вместо пайпов
использовать временные файлы, потому что классический sh умеет вернуть
код только последней команды в пайпе, успех завершения остальных
проверить невозможно. В bash или zsh можно, но тоже очень
небесплатно... (На самом деле сейчас придет Чеусов и скажет, что на
классическом sh тоже можно - но ты попроси его тогда этот код показать,
он у него, кажется, есть...)

ПК Иногда приходится и так писать. Спорить не буду, на perl' было бы легче.

На перле, кстати, тоже иногда подобные танцы приходится устраивать. По
счастью, редко.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Хакинг и кракинг ульев с последующим чавкингом мёда, безусловно, является злым
розыгрышем. Особенно с точки зрения пасечника.
-- http://knjazna.livejournal.com/44647.html?thread=630375#t630375

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-23 Пенетрантность Покотиленко Костик

Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
15:53:25 +0200:

ПК На самом деле в приличных проектах от эффективности
ПК управления памятью зависит всё. Если это управление от тебя
ПК не зависит, от тебя уже мало что зависит.

Посмешил. Вот приличные проекты, где от эффективности
управления памятью (в разумных пределах) ничего не зависит, мне
попадались. А чтобы всё - ни одного. Как минимум, потому что
если проект таков, что там что-то зависит от управления памятью,
то от алгоритмов обработки данных, в этой памяти лежащих, и
логики принятия решений по распихиванию в память зависит куда
больше.

Кстати, хинт: если твоя сишная программа работает в линуксе из-под
непривелигированного юзера, управление памятью от тебя уже не зависит...

ПК Мы что про разные управления памятью говорим?

Нет. Я просто смотрю на шаг дальше. Когда зависит от управления
памятью - речь идет об управлении _физической_ памятью.
Непривелигированный процесс к управлению физической памятью в линуксе
никто не допустит. Так что от его автора в управлении _интересной_
памятью ничего не зависит. Ну, почти ничего...

ПК Не понимаю, можно подробнее? Что такое _интересная_ и _физическая_
ПК память и как ими можно управлять из-под root'а?

Если не понимаешь, то лучше возьми назад свои вышепроцитированные слова,
и давай лучше на этом закончим... Интересная - это та, от эффективности
управления которой что-то зависит. Физическая - это, натурально, RAM, в
противовес виртуальной, которая в линуксе в лучшем случае RAM+swap, в
промежуточном - virtual RAM :-) + virtual swap, а в худшем вообще не
существует (т.е. malloc(2) завершится успешно, а при попытке туда
написать тебе пришлют sig11). У рута на хост-системе есть возможность
запросить именно физическую память, а у обычного пользователя или у
процесса в виртуалке - нету... А от эффективности управления
виртуальной памятью в твоем процессе, извини, не зависит почти ничего.

Не, немножко зависит. За что _знающие_ люди perl и недолюбливают.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Win-юзеры - это типа Win-модемов и Win-принтеров: такие же юзеры, но попроще,
без мозгов и памяти на борту.
http://www.livejournal.com/~dottedmag/158509.html

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Пнд, 23/03/2009 в 18:26 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
13:50:42 +:

И на каждое выделение памяти. Вверх по всему стеку вызовов.

Любая попытка выделить память может закончиться неудачей. И
называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во всех
книжках по C++ - что будет, если ошибка произойдет в момент, когда
память выделена под _часть_ подобъектов?

ПК Если ты программист Си - решать тебе что будет.

ПК Что значит успело выделиться? Само оно не выделяется, по крайней
ПК мере в Си.

На примере gtk.

Вопрос интересный:
void gtk_container_add(...);
void gtk_box_pack_start (...);
void gtk_table_attach(...);

Ни одна не возвращает результат. Варианта 2: либо добавление не требует
выделения ресурсов и обломов быть не может, либо таки об ошибке мы и не
узнаем. Прям сейчас не скажу как именно оно работает, но на практике у
меня таких обломов не встречалось. Если, конечно, добавлять то, что
заведомо реально добавить.

С другой стороны, даже если добавление обломается, ты об этом узнаешь
через вывод GTK-WARNING:... что при тестировании вылазит сразу.

А, ты предпочитаешь просто забить на утечки памяти?

Ни в коем случае.

ПК Один раз, потом верну ошибку назад по стеку, там пусть решают что
ПК делать.

А там пожмут плечами и начнут следующую итерацию главного цикла. В
которой снова запросят память...

Это вопрос логики, просто на perl'е проверки вообще суть не популярная,
если они там хотя бы есть в достаточном количестве.

ПК У Perl'а своя ниша, и он хорош пока от туда не вылазит.

Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что
C из своей ниши вылазит...

ПК Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
ПК клиентские, десктопные приложения, и т.д.

Молодец, перечислил все 3 корявые программы на Си :)

Я тебе на это скажу так: высокоуровневым/скриптовым языкам легко/быстро
учиться, на них легко/быстро написать первую версию. Их программисты
очень часто этим и ограничиваются. А когда начинаешь дорабатывать,
писать обработки различных ситуаций, тогда сложность и затраченное время
уравнивается.

Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
это бывает оправдано...)

ПК А это как?

command
if [[ $? == ... ]]; then
...
fi

ПК Иногда приходится и так писать. Спорить не буду, на perl' было бы легче.

На перле,

Re: Функционал и интерфейс

2009-03-23 Пенетрантность Покотиленко Костик

В Пнд, 23/03/2009 в 18:56 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
15:53:25 +0200:

ПК Мы что про разные управления памятью говорим?

Мы про разное говорили. Я не знал, что в линуксе можно голую память
заказать, задач таких ни разу не было.

Я говорил о удобстве в Си управлять сложно связанными структурами.

Не, немножко зависит. За что _знающие_ люди perl и недолюбливают.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 23 Mar 2009
18:43:52 +0200:

И на каждое выделение памяти. Вверх по всему стеку вызовов.

Любая попытка выделить память может закончиться неудачей. И
называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во всех
книжках по C++ - что будет, если ошибка произойдет в момент, когда
память выделена под _часть_ подобъектов?

ПК Если ты программист Си - решать тебе что будет.

ПК Что значит успело выделиться? Само оно не выделяется, по крайней
ПК мере в Си.

На примере gtk.

ПК Вопрос интересный:
ПК void gtk_container_add(...);
ПК void gtk_box_pack_start (...);
ПК void gtk_table_attach(...);

ПК Ни одна не возвращает результат. Варианта 2: либо добавление не
ПК требует выделения ресурсов и обломов быть не может, либо таки об
ПК ошибке мы и не узнаем. Прям сейчас не скажу как именно оно
ПК работает, но на практике у меня таких обломов не встречалось. Если,
ПК конечно, добавлять то, что заведомо реально добавить.

Мое мнение о том, что реально добавить, с мнением автора библиотеки
может и не совпасть... Ну, не знаю, конкретно в gtk, может, и
гарантированно добавляет без ошибок. Но в питоне оно у меня ухитрялось
отваливаться. Ага, по assert'у. Типа мы ошибок не возвращаем, если
что не так - мы рушим нах всю программу. Тоже, конечно, вариант. Так
firefox и падает.

ПК С другой стороны, даже если добавление обломается, ты об этом узнаешь
ПК через вывод GTK-WARNING:... что при тестировании вылазит сразу.

Судя по количеству срача, которое сыплет в исходный терминал firefox,
его авторы научились обходить эту проблему :-)

ПК Один раз, потом верну ошибку назад по стеку, там пусть решают что
ПК делать.

А там пожмут плечами и начнут следующую итерацию главного цикла. В
которой снова запросят память...

ПК Это вопрос логики, просто на perl'е проверки вообще суть не
ПК популярная, если они там хотя бы есть в достаточном количестве.

Не на перле, а у криворуких программистов. На C они тоже не любят
ничего проверять. Это типа сложно...

ПК У Perl'а своя ниша, и он хорош пока от туда не вылазит.

Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что
C из своей ниши вылазит...

ПК Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
ПК клиентские, десктопные приложения, и т.д.

ПК Молодец, перечислил все 3 корявые программы на Си :)

Нет, первые 3, пришедшие в голову, так, чтобы более-менее покрывали
приведенные тобой категории.

ПК Я тебе на это скажу так: высокоуровневым/скриптовым языкам
ПК легко/быстро учиться, на них легко/быстро написать первую
ПК версию. Их программисты очень часто этим и ограничиваются. А когда
ПК начинаешь дорабатывать, писать обработки различных ситуаций, тогда
ПК сложность и затраченное время уравнивается.

Не надо мне на это так говорить. Я - пробовал. Конкретно на перле. Ни
разу не уравнивается. Разница, конечно, становится поменьше - за счет
того, что скриптик на прям щас на перле пишется и выполняется быстрее,
чем для сишного кода запустится текстовый редактор :-). Но все равно на
порядок. Десятичный.

Ты на sh тоже как на C пишешь? (Там, впрочем, если писать

Re: Функционал и интерфейс

2009-03-23 Пенетрантность Покотиленко Костик

Покотиленко Костик - debian-russian@lists.debian.org  @ Mon, 23 Mar 2009 
18:49:33 +0200:

 ПК Я говорил о удобстве в Си управлять сложно связанными структурами.

А...  Так вот.  В C сложно связанными структурами управлять неудобно.

И, кстати, можно проиграть в производительности даже перлу, не говоря
уже о лиспе.  Домашнее задание: сообразить, где прячется потенциальный
проигрыш, и как это лечат.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Вам правду резать или кусочком?
Кнышев


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Вто, 24/03/2009 в 00:04 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 23 Mar 2009
18:43:52 +0200:

И на каждое выделение памяти. Вверх по всему стеку вызовов.

ПК Если не увлекаться вызовом malloc() inline, а каждый объект
ПК делать набор функций create, destroy и т.д. то это не много и
ПК оправдано. Кстати, разделяя функционал от интерфейса и
выделив
ПК библиотеку, так даже проще.

Любая попытка выделить память может закончиться неудачей. И
называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во
всех
книжках по C++ - что будет, если ошибка произойдет в момент,
когда
память выделена под _часть_ подобъектов?

ПК Если ты программист Си - решать тебе что будет.

ПК Что значит успело выделиться? Само оно не выделяется, по крайней
ПК мере в Си.

На примере gtk.

ПК Вопрос интересный:
ПК void gtk_container_add(...);
ПК void gtk_box_pack_start (...);
ПК void gtk_table_attach(...);

ПК Один раз, потом верну ошибку назад по стеку, там пусть решают что
ПК делать.

А там пожмут плечами и начнут следующую итерацию главного цикла. В
которой снова запросят память...

Не на перле, а у криворуких программистов. На C они тоже не любят
ничего проверять. Это типа сложно...

ПК У Perl'а своя ниша, и он хорош пока от туда не вылазит.

Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том,
что
C из своей ниши вылазит...

ПК Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
ПК клиентские, десктопные приложения, и т.д.

ПК Молодец, перечислил все 3 корявые программы на Си :)

Нет, первые 3, пришедшие в голову, так, чтобы более-менее покрывали
приведенные тобой категории.

На perl'е я боюсь 3-х хороших не вспомню. Я их наверно просто не знаю.

Не надо мне на это так говорить. Я - пробовал. Конкретно на перле. Ни
разу не уравнивается. Разница, конечно, становится поменьше - за счет

Re: Функционал и интерфейс

В Птн, 20/03/2009 в 00:56 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
23:00:22 +0200:

Ну и там прочее по мелочи - а что у нас не освободится, если вылетит
ошибка вот тут?

Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free() было бы
совсем хреново. Но с ними - просто хреново, а не хорошо. Ну разве
что
слаще репы не едал...

ПК У меня такое бывает редко, а когда бывает - заварю чаю и почитаю
ПК кто кого освобождает а кто кого нет, сравню с кодом и всё готово,
ПК делов-то 20 минут.

Начнем с того, что ты вынужден тратить время и, главное, внимание, на
то, чтобы этих ошибок не допустить.

ПК Это культура программирования, _этому_ учиться надо.

Это не культура программирования. Это культура обхода ограничений языка
C. В лучшем случае. Выполнение работы, которую машина может сделать
лучше, культурой программирования называть не следует.

Слушай, давай на примерах? А то как-то размыто. Я буду рад признать, что
Си неэффективен, если наглядно покажешь.

А потом - ты valgrind на свои программы часто натравливаешь?

ПК Ни разу не натравливал. Хотя было несколько таких затыков, что я
ПК уже начал искать инструменты такого рода, и нашёл, в том числе и
ПК valgrind. Но воспользоваться ими не успел, во всех случаях на
ПК следующий день, отдохнувши поглядев, всё нашлось.

А ты натрави. Имеешь шанс узнать что-нибудь интересное...

Наверняка узнаю некоторое количество неучтённых мелочей. Крупные leaks
видно сразу, а те того может и не стоят.

И на каждое выделение памяти. Вверх по всему стеку вызовов.

Если ты программист Си - решать тебе что будет. Мне, например, не
нравится как такие ситуации отработал spamassassin написанный на perl.
Смотри тред OOM-Killer. С perl'ом даже OOM-Killer не справился.

ПК Мне нравится с годами углубляться в один и тот же язык, чем
ПК с каждым годом изучать их больше. На Си можно сделать всё,
ПК а тебе видимо приходится слазить с Тикля иногда.

ПК Вопрос удобства можно обсудить, очень интересно.

Это не мне, это Печникову приходится слазить. А я под задачу
подбираю наиболее удобный инструмент.

ПК Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда
ПК shell. Perl, конечно, было бы круто знать, что иногда
ПК использовать вместо shell, но мне лень его изучать, я на Си не
ПК на много медленее напишу.

Если писать на перле как на C, то да, на C ненамного медленнее
получится. Вот только те, кто изучает не языки, а программирование,
на перле пишут по-другому. Как на перле :-) И C сразу начинает
отставать если не в сотни раз, то в десятки уж точно.

ПК В это мне тяжело въехать.

Тяжело въехать в перловый способ программирования, тяжело понять любой
способ программирования, отличный от однажды выученного, или тяжело
поверить, что однажды выученный не является единственным?

1. Я не говорил, что на Perl ничего не писал, просто ничего серьёзного
не писал. А в способ я въехал.
2. Способ программирования в основном от языка не зависит, и нет, не
тяжело понимать новые, даже нравится, если видно где они эффективнее.
3. Я не в религиозном кружке чтобы просто так поверить в то или иное.

У Perl'а своя ниша, и он хорош пока от туда не вылазит.

Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
это бывает оправдано...)

А это как?

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Птн, 20/03/2009 в 00:47 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
22:41:42 +0200:

Как только ты на C выбираешь достаточно высокий уровень, ты
немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить
за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других
виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и
всех
потомков одной командой.

После чего в памяти навечно остаётся висеть какой-нибудь pixbuf,
используемый в каком-нибудь image. Поскольку понадеялись на
gtk_widget_destroy и документацию к gtk_image_new_from_pixbuf на
предмет освобождения памяти перечитывать не стали.

ПК Баги есть везде. Э про это не знаю, pixbuf'ом практически не
ПК пользовался.

Этот баг у них фичей зовется. В смысле - документирован, а не
исправлен...

Баги, конечно, есть везде. Но вот их количество в разных местах
различно. В больших проектах, написанных на C, помимо неизбежных для
всех языков ошибок в логике программы есть еще туча ошибок в глупостях
типа управления памятью.

ПК И это понятно, сначала научитесь управлять памятью, потом управляйте.

ПК На самом деле в приличных проектах от эффективности управления памятью
ПК зависит всё. Если это управление от тебя не зависит, от тебя уже мало
ПК что зависит.

Посмешил. Вот приличные проекты, где от эффективности управления
памятью (в разумных пределах) ничего не зависит, мне попадались. А
чтобы всё - ни одного. Как минимум, потому что если проект таков, что
там что-то зависит от управления памятью, то от алгоритмов обработки
данных, в этой памяти лежащих, и логики принятия решений по распихиванию
в память зависит куда больше.

Мы что про разные управления памятью говорим?

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Тихон Тарнавский

В Птн, 20/03/2009 в 00:43 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
22:37:50 +0200:

Мне нравится с годами углубляться в один и тот же язык, чем с каждым
годом изучать их больше. На Си можно сделать всё, а тебе видимо
приходится слазить с Тикля иногда.

на асме тоже

ПК На асме нет как таковых понятий библиотек, без чего тяжко...

Ну почему нет? Понятия - есть. Библиотек на чистом асме вроде бы нет,
обвязка всегда сишная. А понятия - есть...

Надо сказать, в старые и даже в чем-то добрые времена библиотеки тоже
были. Вымерли за непереносимостью.

ПК Сложно там с библиотеками, потому и говорю что нет.

Можно сишную позвать :-) Можно, впрочем, и перловую :-)

Я б на это посмотрел! Главный цикл на Asm'е вызывающий перловые
процедуры :-)

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

On Fri, 20.03.2009 11:52:03 , Покотиленко Костик wrote:
 В Птн, 20/03/2009 в 00:56 +0300, Artem Chuprina пишет:
  Любая попытка выделить память может закончиться неудачей.  И называется
  она malloc() или create - рояля не играет.  Ну, с точностью еще до
  классических грабель объективизации конструкции, описанных во всех
  книжках по C++ - что будет, если ошибка произойдет в момент, когда
  память выделена под _часть_ подобъектов?
 
 Если ты программист Си - решать тебе что будет. Мне, например, не
 нравится как такие ситуации отработал spamassassin написанный на perl.
 Смотри тред OOM-Killer. С perl'ом даже OOM-Killer не справился.
 
В ситуации, описанной в том треде, oom-killer пристрелил не того, кого
надо было. При чёт здесь перл?

-- 
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Птн, 20/03/2009 в 12:35 +0200, Тихон Тарнавский пишет:
On Fri, 20.03.2009 11:52:03 , Покотиленко Костик wrote:
В Птн, 20/03/2009 в 00:56 +0300, Artem Chuprina пишет:
Любая попытка выделить память может закончиться неудачей. И называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во всех
книжках по C++ - что будет, если ошибка произойдет в момент, когда
память выделена под _часть_ подобъектов?

В ситуации, описанной в том треде, oom-killer пристрелил не того, кого
надо было. При чёт здесь перл?

Есть предположение, что он таки прибивал треды spamassassin'а, тот
просто успевал наплодиться. Эти предположения основаны на логике работы
oom-killer, по ней spamassassin был первый кандидат.

И, в любом случае, spamassassin не отрабатывал как нужно невозможность
выделить память, у тупо повторял попытки, без задержек.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
11:52:03 +0200:

Ну и там прочее по мелочи - а что у нас не освободится,
если вылетит ошибка вот тут?

Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free()
было бы совсем хреново. Но с ними - просто хреново, а не
хорошо. Ну разве что слаще репы не едал...

ПК У меня такое бывает редко, а когда бывает - заварю чаю и
ПК почитаю кто кого освобождает а кто кого нет, сравню с кодом
ПК и всё готово, делов-то 20 минут.

Начнем с того, что ты вынужден тратить время и, главное,
внимание, на то, чтобы этих ошибок не допустить.

ПК Это культура программирования, _этому_ учиться надо.

Это не культура программирования. Это культура обхода ограничений
языка C. В лучшем случае. Выполнение работы, которую машина может
сделать лучше, культурой программирования называть не следует.

ПК Слушай, давай на примерах? А то как-то размыто. Я буду рад
ПК признать, что Си неэффективен, если наглядно покажешь.

C эффективен. В своей узкой нише. Гораздо более узкой, чем сложилось
исторически.

А потом - ты valgrind на свои программы часто натравливаешь?

А ты натрави. Имеешь шанс узнать что-нибудь интересное...

ПК Наверняка узнаю некоторое количество неучтённых мелочей. Крупные
ПК leaks видно сразу, а те того может и не стоят.

Если только лики, и программа уровня hello world - то да, может, и не
стоят...

И на каждое выделение памяти. Вверх по всему стеку вызовов.

ПК Если ты программист Си - решать тебе что будет.

Не вопрос. Но существует только один приемлемый способ решения -
аккуратно очистить все, что успело выделиться до этого момента. В
случае с C - вручную отследив, что же успело выделиться. Нет, тут тоже
существует обходной маневр. Ценой определенной дисциплины организации
функций, пары-тройки макросов для поддержки оной дисциплины и нескольких
дополнительных строчек на каждое выделение.

ПК Вопрос удобства можно обсудить, очень интересно.

Это не мне, это Печникову приходится слазить. А я под задачу
подбираю наиболее удобный инструмент.

ПК В это мне тяжело въехать.

ПК 1. Я не говорил, что на Perl ничего не писал, просто ничего серьёзного
ПК не писал. А в способ я въехал.
ПК 2. Способ программирования в основном от языка не зависит, и нет, не
ПК тяжело понимать новые, даже нравится, если видно где они эффективнее.
ПК 3. Я не в религиозном кружке чтобы просто так поверить в то или иное.

ПК У Perl'а своя ниша, и он хорош пока от туда не вылазит.

Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что
C из своей ниши вылазит...

Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
это бывает оправдано...)

ПК А это как?

command
if [[ $? == ... ]]; then
...
fi

И т.п. Это если как писать. Если когда оправдано - вместо пайпов

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
11:54:08 +0200:

Как только ты на C выбираешь достаточно высокий уровень, ты
немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти
(почистить за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других
виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его
и всех
потомков одной командой.

ПК Баги есть везде. Э про это не знаю, pixbuf'ом практически не
ПК пользовался.

Этот баг у них фичей зовется. В смысле - документирован, а не
исправлен...

ПК И это понятно, сначала научитесь управлять памятью, потом управляйте.

Посмешил. Вот приличные проекты, где от эффективности управления
памятью (в разумных пределах) ничего не зависит, мне попадались. А
чтобы всё - ни одного. Как минимум, потому что если проект таков, что
там что-то зависит от управления памятью, то от алгоритмов обработки
данных, в этой памяти лежащих, и логики принятия решений по распихиванию
в память зависит куда больше.

ПК Мы что про разные управления памятью говорим?

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Пришел в гости математик, почитать новую рукопись. Вычитал из нее трех
героев напрочь, и ушел.
Gimli on #arda

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Птн, 20/03/2009 в 16:32 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
11:52:03 +0200:

Ну и там прочее по мелочи - а что у нас не освободится,
если вылетит ошибка вот тут?

Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free()
было бы совсем хреново. Но с ними - просто хреново, а не
хорошо. Ну разве что слаще репы не едал...

Начнем с того, что ты вынужден тратить время и, главное,
внимание, на то, чтобы этих ошибок не допустить.

ПК Это культура программирования, _этому_ учиться надо.

Это не культура программирования. Это культура обхода ограничений
языка C. В лучшем случае. Выполнение работы, которую машина может
сделать лучше, культурой программирования называть не следует.

C эффективен. В своей узкой нише. Гораздо более узкой, чем сложилось
исторически.

А потом - ты valgrind на свои программы часто натравливаешь?

А ты натрави. Имеешь шанс узнать что-нибудь интересное...

Если только лики, и программа уровня hello world - то да, может, и не
стоят...

И на каждое выделение памяти. Вверх по всему стеку вызовов.

ПК Если ты программист Си - решать тебе что будет.

Что значит успело выделиться? Само оно не выделяется, по крайней мере в
Си.

Так и получается когда программист не знает как оно работает. Тогда
да, и само выделяется, и выслеживать надо.

Один раз, потом верну ошибку назад по стеку, там пусть решают что
делать.

ПК Вопрос удобства можно обсудить, очень интересно.

Это не мне, это Печникову приходится слазить. А я под задачу
подбираю наиболее удобный инструмент.

ПК В это мне тяжело въехать.

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Тихон Тарнавский

В Птн, 20/03/2009 в 16:35 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
11:54:08 +0200:

Как только ты на C выбираешь достаточно высокий уровень, ты
немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти
(почистить за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других
виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь
его и всех
потомков одной командой.

ПК Баги есть везде. Э про это не знаю, pixbuf'ом практически не
ПК пользовался.

Этот баг у них фичей зовется. В смысле - документирован, а не
исправлен...

ПК И это понятно, сначала научитесь управлять памятью, потом управляйте.

ПК На самом деле в приличных проектах от эффективности управления
памятью
ПК зависит всё. Если это управление от тебя не зависит, от тебя уже мало
ПК что зависит.

Посмешил. Вот приличные проекты, где от эффективности управления
памятью (в разумных пределах) ничего не зависит, мне попадались. А
чтобы всё - ни одного. Как минимум, потому что если проект таков, что
там что-то зависит от управления памятью, то от алгоритмов обработки
данных, в этой памяти лежащих, и логики принятия решений по распихиванию
в память зависит куда больше.

ПК Мы что про разные управления памятью говорим?

Не понимаю, можно подробнее? Что такое _интересная_ и _физическая_
память и как ими можно управлять из-под root'а?

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org  @ Fri, 20 Mar 2009 
11:56:15 +0200:

   ПК Сложно там с библиотеками, потому и говорю что нет.
  
  Можно сишную позвать :-)  Можно, впрочем, и перловую :-)

 ПК Я б на это посмотрел! Главный цикл на Asm'е вызывающий перловые
 ПК процедуры :-)

Да чего там смотреть-то?  Та же подготовка стека, тот же call...  Только
call к функции из libperl, а так, в общем, от обращения к open(2) ничем
не отличается...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

User Guide:
Тыц ПЫЩЬ button!


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

On Fri, 20.03.2009 13:50:42 , Покотиленко Костик wrote:
 В Птн, 20/03/2009 в 16:32 +0300, Artem Chuprina пишет:
  Покотиленко Костик - debian-russian@lists.debian.org  @ Fri, 20 Mar 2009 
  11:52:03 +0200:
   ПК У Perl'а своя ниша, и он хорош пока от туда не вылазит.
  
  Не вопрос.  Она у него даже малость поуже, чем у C.  Проблема в том, что
  C из своей ниши вылазит...
 
 Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
 клиентские, десктопные приложения, и т.д.
Успешно пишут != своя ниша.

-- 
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Alexey Pechnikov

Hello!

On Friday 20 March 2009 17:45:17 Покотиленко Костик wrote:
Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
клиентские, десктопные приложения, и т.д.

Веб-сайт или программа с GUI на чистом С? Возможно, но безумно трудоемко.
Так что успех весьма сомнительный. Демона можно на чем угодно написать.
Вот разве что драйвера остаются.

Конечно не на чистом. С использованием библиотек написанных в конце
концов на чистом.

Знакомьтесь - тикль. Качественная и компактная библиотека, написанная на
чистом С. Легко позволяет создавать сетевые приложения, демоны, веб-системы, а
также GUI.

Кстати, зачастую библиотеки для С++ переплюнут по размеру интерпретаторы
многих скриптовых языков, притом работают хуже - медленнее из-за тучи
конструкторов/деструкторов и огромной вложенности вызовов, к тому же большой
объем кода приводит к низкому его качеству.

P.S. в личку то зачем?

Извиняюсь, но по умолчанию в поле ответа у вас стоит личный адрес вместо
адреса рассылки (интересно, зачем бы это). Обычно жму ответить в рассылку, но
вот попутал.

Best regards.

Re: Функционал и интерфейс

2009-03-19 Пенетрантность Alexey Pechnikov

В Срд, 18/03/2009 в 19:35 +0300, Alexey Pechnikov пишет:
Hello!

Еще есть ненулевое время на открытие сокета, обработку заголовков
запроса, ожидание свободного процесса из пула процессов для вычислений и
проч.

Да, но это уже ботаника, без измерений нечего тут сказать.

Вам гугл за неуплату отключили? :-)

Совершенно неверно. Для SATA дисков, если не ошибаюсь, эффективная
очередь равно примерно 4, а для SCSI и вовсе около 20. Контроллер диска
может переставлять команды в очереди так, чтобы требовалось минимальное
кол-во перемещений головки.

Это NCQ на сколько я понял. Хорошая вещь, что бы сделать более
последовательным набор параллельных запросов. Где тут логика? Или я
всё-таки чего-то не понимаю, у SATA винтов головки независимо читают?

Пример - нужно нам прочитать сколько-то блоков в 100 запросах. Если
планировщик очереди получает все 100 запросов сразу и может их выполнить в
один оборот диска, это будет в примерно в 100 раз быстрее, чем когда вы
отправляете каждый запрос после завершения предыдущего.

Давай продолжим в треде Скорость чтения с диска последовательно одним
процессом VS параллельно несколькими

Для SSD дисков и вовсе параллельное чтение заложено в
архитектуре.

Про это в Инете не нашёл, можно ссылку?

Посмотрите сколько чипов памяти стоит в SSD дисках. Каждый чип работает
независимо, так что все лимитируется лишь контроллером.

В пределах оптимальной очереди команд для диска и при помощи кэша ФС
каждый из параллельных процессов чтения будет работать не медленнее, чем
если бы он был единственный. То есть запуск N процессов чтения увеличит
производительность в N раз при оптимальной нагрузке (линейно). Понятно,
что при возрастании нагрузки линейной зависимости уже не будет.

Как раз наоборот. Больше параллельных процессов пытающихся прочитать -
меньшая линейность чтения, NCQ, конечно как-то сгладит... Кто-нибудь
располагает результатами тестов?

Утилиты для измерения io performance есть в дебиане. Возьмите и проверьте.

Ерунда. Что вы будете держать в общей памяти - кэш всего жесткого диска?

Нет. Буферы запросов и ответов, чтоб большие потоки по пайпам не гонять
туда-сюда.

Ха.

Данные обрабатываемого запроса в других процессах/потоках никому просто
не нужны. А с диском/сетью/БД лучше работать пулам процессов, как уже
рассмотрено выше. А насчет общей памяти - от этого решения уже и многие
СУБД отказываются. В результате использования shared memory тот же оракл
масштабируется намного хуже терадата. PostgreSQL так же использует shared
memory, что приводит к различным проблемам. Я уж не говорю про сложность
такого решения.

Ссылки на обсуждения можно посмотреть? Любая вещь используемая не по
назначению имеет свойство превращаться в грабли...

На обсуждение чего, простите? У всех названных продуктов есть веб-сайты, где
вы можете найти документацию и обсуждения.

Я считаю, что глупо думать, что раз apache2 так устроенна то это
наиболее оптимальный вариант.

Я не знаю, как устроен apache2.

Так вот во многих приложениях их настоящая архитектура -
это пережиток прошлого, который дорого переделать.

Ага, например, архитектура жестких дисков :-) Или живите с ней, или ставьте
себе SSD, что сейчас уже возможно сделать.

Best regards.
--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-19 Пенетрантность chaos

On 18 March 2009 17:08:20 Покотиленко Костик wrote:
 В Срд, 18/03/2009 в 16:31 +0300, Artem Chuprina пишет:
  Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
15:03:57 +0200:
 Ну так как, пробовать будем?

 Неа.

 Если посмотреть выше, то речь шла о демонах, а не парсерах
 текстовых файлов. Или Вы считаете их равнозначными задачами?

 Есть у меня и демоны на тикле, например, собирают и обрабатывают
 данные с цисок и других АТС. Написать то же самое на С большая
 работа (на тикле используются события для прослушивания множества
 сокетов, а на С придется создавать отдельные потоки), потому и не
 предлагаю как тестовую задачу (притом демоны умеют держать в
 in-memory SQLite database те данные, которые не удалось записать в
 persistent database), не говоря уж о реализации самой логики
 обработки.

 Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в
 которых соответствующие примитивы.
   
Вообще говоря, есть libevent, с помощью которой на Си событийно
писать проще. Но вообще прикладуху на Си писать не интересно, борьба
с языком(слишком низкоуровневый) и развивается паранойя при
использовании каждого указателя.
 
   ПК Прикол в том, что уровень языка Си выбирается программистом
  посредством ПК выбора библиотек нужных уровней. На libc конечно тяжело
  прикладуху ПК писать. Выбор за тобой, а не за языком, используй glib,
  gtk+, или что ПК тебе больше подходит для конкретной задачи.
 
   ПК Как я уже писал, на Си легко работать с объектной моделью, не
  сложнее ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка -
  ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
  ПК высокого уровня ограничивают тебя высотой своего уровня.
 
  Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
  получаешь высокоуровневый подъязык с неудобным синтаксисом и
  ... правильно, все равно заботой о распределении памяти (почистить за
  тобой все равно никто не сможет).

 В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
 потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
 потомков одной командой. Так что это дело инструментов, а GTK+ и кстати
 glib это умеют.

  Таким образом, у тебя в любом случае неудобный синтаксис и в любом
  случае распределение памяти.  Ты от них уйти не можешь.

 Чем вдруг?

  При языке высокого уровня же ты можешь вынести в отдельную библиотеку
  то, что таки да, надо сделать на C (хинт: вообще-то бОльшую часть работы
  с низким уровнем и на них можно сделать достаточно эффективно - тот же
  бинарный протокол на tcl реализовать в разы проще, чем на C).

 Мне нравится с годами углубляться в один и тот же язык, чем с каждым
 годом изучать их больше. На Си можно сделать всё, а тебе видимо
 приходится слазить с Тикля иногда.

на асме тоже

Re: Функционал и интерфейс

Hello!

On Thursday 19 March 2009 01:28:20 Artem Chuprina wrote:
AP Alexander Danilov недавно высказывал желание сделать аналог SQLite на
одном из AP функциональных языков. Имхо не лучшая идея с точки зрения
эффективности, AP предпочитаю на С низкоуровневые вещи делать (ну может
еще и ностальгия у меня AP по С, не буду отрицать). Ну если напишет -
посмотрим :-)

Эээ... А где ты в задаче написания _аналога_ SQLite обнаружил низкий
уровень?

SQLite использует встроенную виртуальную машину:

Each instruction in the virtual machine consists of an opcode and up to five
operands named P1, P2 P3, P4, and P5. P1, P2, and P3 are 32-bit signed
integers. These operands often refer to registers. P2 is always the jump
destination in any operation that might cause a jump. P4 may be a 32-bit
signed integer, a 64-bit signed integer, a 64-bit floating point value, a
string literal, a Blob literal, a pointer to a collating sequence comparison
function, or a pointer to the implemantation of an application-defined SQL
function, or various other things. P5 is an unsigned character normally used
as a flag. Some operators use all five operands. Some use one or two. Some
operators use none of the operand

Или для вас работа с регистрами процессора это задача для скриптового языка?

Best regards.

Re: Функционал и интерфейс

Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
11:19:57 +0300:

AP Alexander Danilov недавно высказывал желание сделать аналог SQLite на
одном из AP функциональных языков. Имхо не лучшая идея с точки зрения
эффективности, AP предпочитаю на С низкоуровневые вещи делать (ну может
еще и ностальгия у меня AP по С, не буду отрицать). Ну если напишет -
посмотрим :-)

Эээ... А где ты в задаче написания _аналога_ SQLite обнаружил низкий
уровень?

AP SQLite использует встроенную виртуальную машину:

AP Each instruction in the virtual machine consists of an opcode and up to
five
AP operands named P1, P2 P3, P4, and P5. P1, P2, and P3 are 32-bit signed
AP integers. These operands often refer to registers. P2 is always the jump
AP destination in any operation that might cause a jump. P4 may be a 32-bit
AP signed integer, a 64-bit signed integer, a 64-bit floating point value, a
AP string literal, a Blob literal, a pointer to a collating sequence
comparison
AP function, or a pointer to the implemantation of an application-defined SQL
AP function, or various other things. P5 is an unsigned character normally
used
AP as a flag. Some operators use all five operands. Some use one or two. Some
AP operators use none of the operand

AP Или для вас работа с регистрами процессора это задача для скриптового
языка?

1. often refer to registers не означает, что они там работают с
регистрами процессора. Это и не для C, прямо скажем, задача. Это
только на ассемблере.

2. Соответственно, если делать такую же машину на нормальном
функциональном языке, оно тоже будет often refer to registers. Но ...

3. И наконец, зачем при создании _аналога SQLite_ на функциональном
языке реализовать эту самую виртуальную машину? Это когда его пишут на
C, эту машину надо делать. А в функциональном, скорее всего, нужные
возможности предоставлены языком.

Разумеется, эмуляция ассемблерного кода на хаскеле будет работать
медленнее оригинала. Возможно - намного медленнее. А вот реализация
той же функциональности...

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
-- Phil Greenspun
Including Common Lisp.
-- Robert Morris

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Срд, 18/03/2009 в 22:01 +0400, Степан Голосунов пишет:
Покотиленко Костик cas...@meteor.dp.ua writes:
В Срд, 18/03/2009 в 16:31 +0300, Artem Chuprina пишет:
Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
потомков одной командой.

Баги есть везде. Э про это не знаю, pixbuf'ом практически не
пользовался.

Так что это дело инструментов, а GTK+ и кстати
glib это умеют.

Таким образом, у тебя в любом случае неудобный синтаксис и в любом
случае распределение памяти. Ты от них уйти не можешь.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Срд, 18/03/2009 в 20:52 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
17:08:20 +0200:

Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

ПК В GTK+, создаёшь виджет окно, напихиваешь туда кучу других
ПК виджетов, потом делаешь gtk_widget_destroy() на окно, и
ПК освобождаешь его и всех потомков одной командой. Так что это дело
ПК инструментов, а GTK+ и кстати glib это умеют.

Не, мужик, сделать gtk_widget_destroy() ты все равно вынужден вручную.
Что накладывает довольно специфические требования на то, как пишется
функция, дабы не забыть это сделать ни по какой ветки, не говоря уже о
том, чтобы не сделать это ненароком дважды.

Про ненароком опустим...

Ну и там прочее по мелочи - а что у нас не освободится, если вылетит
ошибка вот тут?

У меня такое бывает редко, а когда бывает - заварю чаю и почитаю кто
кого освобождает а кто кого нет, сравню с кодом и всё готово, делов-то
20 минут.

ПК Чем вдруг?

Синтаксис излишне многословен. Сокращать, конечно, можно, но помнить,
под каким сокращением у тебя что живет, все равно надо. На NULL на
каждый чих проверить тоже все равно надо (ну, при хорошем дизайне -
через один чих).

Не через один, а один раз на каждый неподвластный вход. А все
подвластные входы не должны давать неожиданностей, этому время уделять
надо, оно окупается.

При языке высокого уровня же ты можешь вынести в отдельную библиотеку
то, что таки да, надо сделать на C (хинт: вообще-то бОльшую часть работы
с низким уровнем и на них можно сделать достаточно эффективно - тот же
бинарный протокол на tcl реализовать в разы проще, чем на C).

ПК Мне нравится с годами углубляться в один и тот же язык, чем с каждым
ПК годом изучать их больше. На Си можно сделать всё, а тебе видимо
ПК приходится слазить с Тикля иногда.

ПК Вопрос удобства можно обсудить, очень интересно.

Это не мне, это Печникову приходится слазить. А я под задачу подбираю
наиболее удобный инструмент.

Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда shell.
Perl, конечно, было бы круто знать, что иногда использовать вместо
shell, но мне лень его изучать, я на Си не на много медленее напишу.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Чтв, 19/03/2009 в 09:07 +0200, chaos пишет:
 On 18 March 2009 17:08:20 Покотиленко Костик wrote:
  В Срд, 18/03/2009 в 16:31 +0300, Artem Chuprina пишет:
   Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
 15:03:57 +0200:
  Ну так как, пробовать будем?
 
  Неа.
 
  Если посмотреть выше, то речь шла о демонах, а не парсерах
  текстовых файлов. Или Вы считаете их равнозначными задачами?
 
  Есть у меня и демоны на тикле, например, собирают и обрабатывают
  данные с цисок и других АТС. Написать то же самое на С большая
  работа (на тикле используются события для прослушивания множества
  сокетов, а на С придется создавать отдельные потоки), потому и не
  предлагаю как тестовую задачу (притом демоны умеют держать в
  in-memory SQLite database те данные, которые не удалось записать в
  persistent database), не говоря уж о реализации самой логики
  обработки.
 
  Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в
  которых соответствующие примитивы.

 Вообще говоря, есть libevent, с помощью которой на Си событийно
 писать проще. Но вообще прикладуху на Си писать не интересно, борьба
 с языком(слишком низкоуровневый) и развивается паранойя при
 использовании каждого указателя.
  
ПК Прикол в том, что уровень языка Си выбирается программистом
   посредством ПК выбора библиотек нужных уровней. На libc конечно тяжело
   прикладуху ПК писать. Выбор за тобой, а не за языком, используй glib,
   gtk+, или что ПК тебе больше подходит для конкретной задачи.
  
ПК Как я уже писал, на Си легко работать с объектной моделью, не
   сложнее ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка -
   ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
   ПК высокого уровня ограничивают тебя высотой своего уровня.
  
   Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
   получаешь высокоуровневый подъязык с неудобным синтаксисом и
   ... правильно, все равно заботой о распределении памяти (почистить за
   тобой все равно никто не сможет).
 
  В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
  потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
  потомков одной командой. Так что это дело инструментов, а GTK+ и кстати
  glib это умеют.
 
   Таким образом, у тебя в любом случае неудобный синтаксис и в любом
   случае распределение памяти.  Ты от них уйти не можешь.
 
  Чем вдруг?
 
   При языке высокого уровня же ты можешь вынести в отдельную библиотеку
   то, что таки да, надо сделать на C (хинт: вообще-то бОльшую часть работы
   с низким уровнем и на них можно сделать достаточно эффективно - тот же
   бинарный протокол на tcl реализовать в разы проще, чем на C).
 
  Мне нравится с годами углубляться в один и тот же язык, чем с каждым
  годом изучать их больше. На Си можно сделать всё, а тебе видимо
  приходится слазить с Тикля иногда.
 
 на асме тоже

На асме нет как таковых понятий библиотек, без чего тяжко...

-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Степан Голосунов - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
23:55:33 +0400:

Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
потомков одной командой.

Баги есть везде. Э про это не знаю, pixbuf'ом практически не
пользовался.

СГ В высокоуровневых языках подобных багов часто нет в принципе. А на C
СГ их обычно много, и их последствия - весьма тяжкие.

Вот, кстати, в гимповской библиотеке для Scheme ... ага, картинки не
попадают под garbage collection. Ага, gtk'шные :-)

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Покотиленко Костик - debian-russian@lists.debian.org  @ Thu, 19 Mar 2009 
20:29:36 +0200:

   Мне нравится с годами углубляться в один и тот же язык, чем с каждым
   годом изучать их больше. На Си можно сделать всё, а тебе видимо
   приходится слазить с Тикля иногда.
  
  на асме тоже

 ПК На асме нет как таковых понятий библиотек, без чего тяжко...

Ну почему нет?  Понятия - есть.  Библиотек на чистом асме вроде бы нет,
обвязка всегда сишная.  А понятия - есть...

Надо сказать, в старые и даже в чем-то добрые времена библиотеки тоже
были.  Вымерли за непереносимостью.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Лень оправдывает средства


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
20:19:52 +0200:

Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
потомков одной командой.

ПК Баги есть везде. Э про это не знаю, pixbuf'ом практически не
ПК пользовался.

Этот баг у них фичей зовется. В смысле - документирован, а не
исправлен...

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Вам правду резать или кусочком?
Кнышев

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Чтв, 19/03/2009 в 23:25 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Thu, 19 Mar 2009 
 20:29:36 +0200:
 
Мне нравится с годами углубляться в один и тот же язык, чем с каждым
годом изучать их больше. На Си можно сделать всё, а тебе видимо
приходится слазить с Тикля иногда.
   
   на асме тоже
 
  ПК На асме нет как таковых понятий библиотек, без чего тяжко...
 
 Ну почему нет?  Понятия - есть.  Библиотек на чистом асме вроде бы нет,
 обвязка всегда сишная.  А понятия - есть...
 
 Надо сказать, в старые и даже в чем-то добрые времена библиотеки тоже
 были.  Вымерли за непереносимостью.

Сложно там с библиотеками, потому и говорю что нет.

-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
20:44:07 +0200:

Ну и там прочее по мелочи - а что у нас не освободится, если вылетит
ошибка вот тут?

Начнем с того, что ты вынужден тратить время и, главное, внимание, на
то, чтобы этих ошибок не допустить.

А потом - ты valgrind на свои программы часто натравливаешь?

ПК Чем вдруг?

ПК Не через один, а один раз на каждый неподвластный вход.

И на каждое выделение памяти. Вверх по всему стеку вызовов.

ПК А все подвластные входы не должны давать неожиданностей, этому
ПК время уделять надо, оно окупается.

Не должны не значит не дают... Впрочем, это уже мелочи.

При языке высокого уровня же ты можешь вынести в отдельную
библиотеку то, что таки да, надо сделать на C (хинт: вообще-то
бОльшую часть работы с низким уровнем и на них можно сделать
достаточно эффективно - тот же бинарный протокол на tcl
реализовать в разы проще, чем на C).

ПК Мне нравится с годами углубляться в один и тот же язык, чем с
ПК каждым годом изучать их больше. На Си можно сделать всё, а тебе
ПК видимо приходится слазить с Тикля иногда.

ПК Вопрос удобства можно обсудить, очень интересно.

Это не мне, это Печникову приходится слазить. А я под задачу
подбираю наиболее удобный инструмент.

ПК Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда
ПК shell. Perl, конечно, было бы круто знать, что иногда использовать
ПК вместо shell, но мне лень его изучать, я на Си не на много медленее
ПК напишу.

Если писать на перле как на C, то да, на C ненамного медленнее
получится. Вот только те, кто изучает не языки, а программирование, на
перле пишут по-другому. Как на перле :-) И C сразу начинает отставать
если не в сотни раз, то в десятки уж точно.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Ошибка в мигель-ДНКазе
-- Mike Novikoff in 1127957...@p73.f133.n5020.z2.ftn

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Чтв, 19/03/2009 в 23:23 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
20:19:52 +0200:

Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
потомков одной командой.

ПК Баги есть везде. Э про это не знаю, pixbuf'ом практически не
ПК пользовался.

Этот баг у них фичей зовется. В смысле - документирован, а не
исправлен...

И это понятно, сначала научитесь управлять памятью, потом управляйте.

На самом деле в приличных проектах от эффективности управления памятью
зависит всё. Если это управление от тебя не зависит, от тебя уже мало
что зависит.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Чтв, 19/03/2009 в 23:32 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
20:44:07 +0200:

Ну и там прочее по мелочи - а что у нас не освободится, если вылетит
ошибка вот тут?

Начнем с того, что ты вынужден тратить время и, главное, внимание, на
то, чтобы этих ошибок не допустить.

Это культура программирования, _этому_ учиться надо.

А потом - ты valgrind на свои программы часто натравливаешь?

Ни разу не натравливал. Хотя было несколько таких затыков, что я уже
начал искать инструменты такого рода, и нашёл, в том числе и valgrind.
Но воспользоваться ими не успел, во всех случаях на следующий день,
отдохнувши поглядев, всё нашлось.

После какого-то такого случая, я написал простенький профайлер, обёртку
для malloc и free с модулем статистики. Использую её в задачах, где сам
не уверен где какие узкие места. Снимай статистику и хоть в rrd пиши.

ПК Чем вдруг?

ПК Не через один, а один раз на каждый неподвластный вход.

И на каждое выделение памяти. Вверх по всему стеку вызовов.

Если не увлекаться вызовом malloc() inline, а каждый объект делать
набор функций create, destroy и т.д. то это не много и оправдано.
Кстати, разделяя функционал от интерфейса и выделив библиотеку, так даже
проще.

ПК А все подвластные входы не должны давать неожиданностей, этому
ПК время уделять надо, оно окупается.

Не должны не значит не дают... Впрочем, это уже мелочи.

При языке высокого уровня же ты можешь вынести в отдельную
библиотеку то, что таки да, надо сделать на C (хинт: вообще-то
бОльшую часть работы с низким уровнем и на них можно сделать
достаточно эффективно - тот же бинарный протокол на tcl
реализовать в разы проще, чем на C).

ПК Вопрос удобства можно обсудить, очень интересно.

Это не мне, это Печникову приходится слазить. А я под задачу
подбираю наиболее удобный инструмент.

Если писать на перле как на C, то да, на C ненамного медленнее
получится. Вот только те, кто изучает не языки, а программирование, на
перле пишут по-другому. Как на перле :-) И C сразу начинает отставать
если не в сотни раз, то в десятки уж точно.

В это мне тяжело въехать.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
22:37:50 +0200:

на асме тоже

ПК На асме нет как таковых понятий библиотек, без чего тяжко...

Ну почему нет? Понятия - есть. Библиотек на чистом асме вроде бы нет,
обвязка всегда сишная. А понятия - есть...

Надо сказать, в старые и даже в чем-то добрые времена библиотеки тоже
были. Вымерли за непереносимостью.

ПК Сложно там с библиотеками, потому и говорю что нет.

Можно сишную позвать :-) Можно, впрочем, и перловую :-)

Но главное - можно сделать и так.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

When C++ is your hammer, everything looks like a thumb
-- Latest seen from Steven M. Haflich, in c.l.l

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
22:41:42 +0200:

Как только ты на C выбираешь достаточно высокий уровень, ты
немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и
всех
потомков одной командой.

ПК Баги есть везде. Э про это не знаю, pixbuf'ом практически не
ПК пользовался.

Этот баг у них фичей зовется. В смысле - документирован, а не
исправлен...

ПК И это понятно, сначала научитесь управлять памятью, потом управляйте.

Посмешил. Вот приличные проекты, где от эффективности управления
памятью (в разумных пределах) ничего не зависит, мне попадались. А
чтобы всё - ни одного. Как минимум, потому что если проект таков, что
там что-то зависит от управления памятью, то от алгоритмов обработки
данных, в этой памяти лежащих, и логики принятия решений по распихиванию
в память зависит куда больше.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

There's no sense in being precise, when you don't even know what
you're talking about.
-- John von Neumann

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
23:00:22 +0200:

Ну и там прочее по мелочи - а что у нас не освободится, если вылетит
ошибка вот тут?

Начнем с того, что ты вынужден тратить время и, главное, внимание, на
то, чтобы этих ошибок не допустить.

ПК Это культура программирования, _этому_ учиться надо.

А потом - ты valgrind на свои программы часто натравливаешь?

А ты натрави. Имеешь шанс узнать что-нибудь интересное...

И на каждое выделение памяти. Вверх по всему стеку вызовов.

ПК Вопрос удобства можно обсудить, очень интересно.

Это не мне, это Печникову приходится слазить. А я под задачу
подбираю наиболее удобный инструмент.

ПК В это мне тяжело въехать.

Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
это бывает оправдано...)

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

If a `religion' is defined to be a system of ideas that contains
unprovable statements, then Godel taught us that mathematics is not
only a religion, it is the only religion that can prove itself to be
one.
-- John Barrow

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

On 17 March 2009 20:33:32 Alexey Pechnikov wrote:
 Hello!

 On Tuesday 17 March 2009 21:06:58 Alexander GQ Gerasiov wrote:
   Есть у меня и демоны на тикле, например, собирают и обрабатывают
   данные с цисок и других АТС. Написать то же самое на С большая работа
   (на тикле используются события для прослушивания множества сокетов, а
   на С придется создавать отдельные потоки), потому и не предлагаю как
   тестовую задачу (притом демоны умеют держать в in-memory SQLite
   database те данные, которые не удалось записать в persistent
   database), не говоря уж о реализации самой логики обработки.
 
  Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
  соответствующие примитивы.

 Обращаю ваше внимание на постановку задачи:
 Никаких внешних библиотек не используем, только встроенные средства.

 Не говоря о том, что за Qt на сервере сразу надо убивать из рогатки по
 рецепту Остапа Бендера.

Это уже вопрос религии. QtCore не значит иксы.

Re: Функционал и интерфейс

On 17 March 2009 20:44:05 Покотиленко Костик wrote:
 В Вто, 17/03/2009 в 21:33 +0300, Alexey Pechnikov пишет:
  Hello!
 
  On Tuesday 17 March 2009 21:06:58 Alexander GQ Gerasiov wrote:
Есть у меня и демоны на тикле, например, собирают и обрабатывают
данные с цисок и других АТС. Написать то же самое на С большая работа
(на тикле используются события для прослушивания множества сокетов, а
на С придется создавать отдельные потоки), потому и не предлагаю как
тестовую задачу (притом демоны умеют держать в in-memory SQLite
database те данные, которые не удалось записать в persistent
database), не говоря уж о реализации самой логики обработки.
  
   Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
   соответствующие примитивы.
 
  Обращаю ваше внимание на постановку задачи:
  Никаких внешних библиотек не используем, только встроенные средства.

 Постановка с подковыркой, заведомо выиграет C# со встроенным MFC
 или .Net или что там у них сейчас.

  Не говоря о том, что за Qt на сервере сразу надо убивать из рогатки по
  рецепту Остапа Бендера.

 Только за GLib убивать не стоит, за QtCore наверное тоже.

Потому как такая-же библиотека как и все остальные.

Re: Функционал и интерфейс

On 17 March 2009 21:00:54 Alexey Pechnikov wrote:
Hello!

On Tuesday 17 March 2009 21:44:05 Покотиленко Костик wrote:
Обращаю ваше внимание на постановку задачи:
Никаких внешних библиотек не используем, только встроенные средства.

Постановка с подковыркой, заведомо выиграет C# со встроенным MFC
или .Net или что там у них сейчас.

Ошибаетесь. У меня под рукой дебиан как минимум на x86 и arm архитектурах
есть. Потому речь и шла о чистом С, что он кроссплатформенный - тикль,
понятно, тоже, как следствие.

И, кстати, MFC это враппер для Windows API, а не библиотека алгоритмов.
Библиотека алгоритмов для C++ это STL, которую сделали в Silicon Graphics,
насколько мне помнится.

Не говоря о том, что за Qt на сервере сразу надо убивать из рогатки по
рецепту Остапа Бендера.

Только за GLib убивать не стоит, за QtCore наверное тоже.

Стоит. За использование C++ с огромными перегруженными библиотеками.

Вопрос исключительно религиозный. Perl, php, и прочая перегружены не меньше,
только не C++, а каждый своим. про тикли я пожалуй промолчу.

по вашей логике за libmagick10 тоже убивать надо (хотя её могут использовать
какие-то сайты или сервисы для обработки изображений) потому как тянет за
собой libgtk2.0-0, перегруженный куда больше чем qt

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 22:49 +0300, Alexey Pechnikov пишет:
Hello!

On Tuesday 17 March 2009 22:19:12 Покотиленко Костик wrote:
Если изменить архитектуру так:
- один процесс принимает все соединения с одной стороны, и общается с
несколькими процессами выполняющими вычисления (SSI, PHP, etc) в
количестве равном количеству ядер
- процессы выполняющие вычисления читают данные через процессы работы с
дисками (по одному на каждый физический диск), выполняют обработку,
отдают результат главному, тот клиенту
- процессы работы с дисками обрабатывают чтение запись и всё.

С такой архитектурой на 4-х ядрах и 2-х винчестерах при любом количестве
клиентов будет 7 процессов.

И что, магическое число 7 принесет удачу серверу? :-)

Предложенная вами архитектура не годится. Хотя бы потому, что 1 слушающий
процесс всегда будет узким местом.

Не будет. Его задача состоит только в том чтобы делать read() на сокет
клиенты и write() на сокет процесса выполняющего вычисления, потом
обратно, и так по кругу для всех клиентов. Нагрузка около нуля.

Далее, операции чтения с диска могут
выполняться параллельно многими процессами (есть кэш диска плюс кэш
операционной системы). И для записи даже для SATA-диска размер очереди
команд,
равный 1, далеко не оптимум, а для SAS дисков тем более.

Вопрос конечно спорный. Скажу только, что если не принимать во внимание
кэш ФС то в один момент времени один винт может обрабатывать равно один
запрос, поэтому чтение одним процессом может быть производительнее,
особенно если его очередь постарается сделать чтение более
последовательным.

Насчёт кэша. Как вариант можно делать несколько процессов на диск, или
кэшировать прям в процессе.

Хотя стой, не надо плодить процессы и встраивать кэш. В любом случае
один процесс читающий последовательно будет не медленее чем два
параллельно. Кэш ФС тут помощник как в первом случае так и во втором.

Если я не прав, давайте обсудим.

А еще есть рэйд-
контроллеры, которые дополнительно оптимизируют дисковые операции, в т.ч. за
счет своего кэша.

Ну, если нужен рэйд, кто мешает.

Не говоря уже о бессмысленности создания бутылочного горла
между читающими и вычисляющими процессами.

Не знаю, на сколько это узкое горло, но если перейти от сокетов/пайпов к
общей памяти или от процессов к нитям с общей памятью, этот вопрос точно
отпадёт.

Не пытайтесь угадать - чтобы
создать эффективную архитектуру, нужно знать теорию и уметь ее применять. А
уж
что касается работы с оборудованием, так тут еще требуется набор неочевидных
компромиссов, если необходимо обеспечить поддержку, к примеру, разных типов
дисков.

Я не пытаюсь угадать, я пытаюсь размышлять.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Hello!

Предложенная вами архитектура не годится. Хотя бы потому, что 1
слушающий процесс всегда будет узким местом.

Еще есть ненулевое время на открытие сокета, обработку заголовков запроса,
ожидание свободного процесса из пула процессов для вычислений и проч.

Далее, операции чтения с диска могут
выполняться параллельно многими процессами (есть кэш диска плюс кэш
операционной системы). И для записи даже для SATA-диска размер очереди
команд, равный 1, далеко не оптимум, а для SAS дисков тем более.

Совершенно неверно. Для SATA дисков, если не ошибаюсь, эффективная очередь
равно примерно 4, а для SCSI и вовсе около 20. Контроллер диска может
переставлять команды в очереди так, чтобы требовалось минимальное кол-во
перемещений головки. Для SSD дисков и вовсе параллельное чтение заложено в
архитектуре.

Насчёт кэша. Как вариант можно делать несколько процессов на диск, или
кэшировать прям в процессе.

В пределах оптимальной очереди команд для диска и при помощи кэша ФС каждый из
параллельных процессов чтения будет работать не медленнее, чем если бы он был
единственный. То есть запуск N процессов чтения увеличит производительность в
N раз при оптимальной нагрузке (линейно). Понятно, что при возрастании
нагрузки линейной зависимости уже не будет.

Не говоря уже о бессмысленности создания бутылочного горла
между читающими и вычисляющими процессами.

Ерунда. Что вы будете держать в общей памяти - кэш всего жесткого диска?
Данные обрабатываемого запроса в других процессах/потоках никому просто не
нужны. А с диском/сетью/БД лучше работать пулам процессов, как уже рассмотрено
выше. А насчет общей памяти - от этого решения уже и многие СУБД отказываются.
В результате использования shared memory тот же оракл масштабируется намного
хуже терадата. PostgreSQL так же использует shared memory, что приводит к
различным проблемам. Я уж не говорю про сложность такого решения.

Я не пытаюсь угадать, я пытаюсь размышлять.

Размышления строятся на основе фактов, а не на догадках.

Best regards.

Re: Функционал и интерфейс

chaos - debian-russian@lists.debian.org @ Tue, 17 Mar 2009 17:21:03 +0200:

Перл бы еще рассказал, с какими аргументами была вызвана функция, что
позволило бы найти ошибку гораздо быстрее.

ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.

Для фундаментальных задач хороши инструменты, от которых ты, подозреваю,
в лучшем случае название слышал...

c Для начала тогда было бы не плохо определить, что это за задачи
c такие, которые относятся к разряду фундаментальных. И тут желательно
c не субъективное восприятие отдельной личности (потому как в этом
c случае будет всё ну очень растяжимо) а некоторая принятая
c классификация.

Фундаментальные - это, например, проверка теорий возникновения Вселенной.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Save the environment. Create a closure today.
-- Cormac Flanagan

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Hello!

On Wednesday 18 March 2009 13:35:31 Artem Chuprina wrote:
   Для фундаментальных задач хороши инструменты, от которых ты,
 подозреваю,  в лучшем случае название слышал...

  c Для начала тогда было бы не плохо определить, что это за задачи
  c такие, которые относятся к разряду фундаментальных. И тут желательно
  c не субъективное восприятие отдельной личности (потому как в этом
  c случае будет всё ну очень растяжимо) а некоторая принятая
  c классификация.

 Фундаментальные - это, например, проверка теорий возникновения Вселенной.

Для таких задач нет и не может быть готовых инструментов. А те, что есть, 
строятся на множестве допущений, да еще зачастую не обозначенных явно. 
Например, зачастую оценивают динамику радиуса корреляции в среде, исходя из 
физически обоснованного допущения о гауссовом распределении начальных 
неоднородностей, при том, что начальное распределение создают с помощью 
компьютерного датчика случайных чисел, которое на большом распределении 
коррелировано (sic!), но отнюдь не гауссово. Для получения адекватных 
результатов нужно получить характеристики начальных неоднородностей изучаемой 
среды и сгенерировать аналогичное распределение, что и в двумерном случае 
требует много времени и проверки результата. Так что все, начиная от фурье-
преобразований, приходится кодировать самостоятельно, учитывая все ограничения 
своей физической модели и требуемую точность.

Best regards.

Re: Функционал и интерфейс

On 18 March 2009 12:35:31 Artem Chuprina wrote:
 chaos - debian-russian@lists.debian.org  @ Tue, 17 Mar 2009 17:21:03 +0200:
 Перл бы еще рассказал, с какими аргументами была вызвана функция,
 что позволило бы найти ошибку гораздо быстрее.
  
ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.
  
   Для фундаментальных задач хороши инструменты, от которых ты,
   подозреваю, в лучшем случае название слышал...

  c Для начала тогда было бы не плохо определить, что это за задачи
  c такие, которые относятся к разряду фундаментальных. И тут желательно
  c не субъективное восприятие отдельной личности (потому как в этом
  c случае будет всё ну очень растяжимо) а некоторая принятая
  c классификация.

 Фундаментальные - это, например, проверка теорий возникновения Вселенной.

Это как-то не определение классификации, а просто пример, не более того.

Re: Функционал и интерфейс

chaos - debian-russian@lists.debian.org @ Wed, 18 Mar 2009 12:55:55 +0200:

Перл бы еще рассказал, с какими аргументами была вызвана функция,
что позволило бы найти ошибку гораздо быстрее.

ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.

Для фундаментальных задач хороши инструменты, от которых ты,
подозреваю, в лучшем случае название слышал...

Фундаментальные - это, например, проверка теорий возникновения Вселенной.

c Это как-то не определение классификации, а просто пример, не более того.

Определения тут давать бессмысленно. Не математика. Всегда найдется
пограничный случай.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Все события вымышлены, после чего искажены.
-- lj user=mcdowns

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Alexey Pechnikov - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
14:17:05 +0300:

    Для фундаментальных задач хороши инструменты, от которых ты,
  подозреваю,  в лучшем случае название слышал...
 
   c Для начала тогда было бы не плохо определить, что это за задачи
   c такие, которые относятся к разряду фундаментальных. И тут желательно
   c не субъективное восприятие отдельной личности (потому как в этом
   c случае будет всё ну очень растяжимо) а некоторая принятая
   c классификация.
 
  Фундаментальные - это, например, проверка теорий возникновения Вселенной.

 AP Для таких задач нет и не может быть готовых инструментов. А те, что
 AP есть, строятся на множестве допущений, да еще зачастую не
 AP обозначенных явно.  Например, зачастую оценивают динамику радиуса
 AP корреляции в среде, исходя из физически обоснованного допущения о
 AP гауссовом распределении начальных неоднородностей, при том, что
 AP начальное распределение создают с помощью компьютерного датчика
 AP случайных чисел, которое на большом распределении коррелировано
 AP (sic!), но отнюдь не гауссово. Для получения адекватных результатов
 AP нужно получить характеристики начальных неоднородностей изучаемой
 AP среды и сгенерировать аналогичное распределение, что и в двумерном
 AP случае требует много времени и проверки результата. Так что все,
 AP начиная от фурье- преобразований, приходится кодировать
 AP самостоятельно, учитывая все ограничения своей физической модели и
 AP требуемую точность.

А я не утверждал, что есть готовый инструмент с функцией проверить
теорию.  Я утверждал, что инструменты, применяемые для этих задач - это
несколько более другие инструменты, нежели известные Костику...

Ну и эта...  Уж физики-то могут себе позволить _настоящий_ ДСЧ...  Он у
них все равно есть, и какие-то датчики туда все равно заведены...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

HTTP тоже не каждый дятел может сделать. Только дятлы об этом обычно не знают.
Victor Wagner в b9td98$d8...@wagner.wagner.home


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Hello!

On Wednesday 18 March 2009 14:39:49 Artem Chuprina wrote:
 Ну и эта...  Уж физики-то могут себе позволить _настоящий_ ДСЧ...  Он у
 них все равно есть, и какие-то датчики туда все равно заведены...

Любой эксперимент, в т.ч. численный, должен быть воспроизводим. Программная 
реализация (через прямое-обратное фурье) работает с любым случайным шумом на 
входе и, следовательно, условие воспроизводимости соблюдается. Аппаратная 
реализация, снимающая микропараметры среды, дает принципиально 
невоспроизводимый результат - даже в той же лаборатории с тем же образцом 
микрохарактеристики среды изменяются с течением времени.

Best regards.

Re: Функционал и интерфейс

Alexey Pechnikov - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
14:53:21 +0300:

  Ну и эта...  Уж физики-то могут себе позволить _настоящий_ ДСЧ...  Он у
  них все равно есть, и какие-то датчики туда все равно заведены...

 AP Любой эксперимент, в т.ч. численный, должен быть
 AP воспроизводим. Программная реализация (через прямое-обратное фурье)
 AP работает с любым случайным шумом на входе и, следовательно, условие
 AP воспроизводимости соблюдается. Аппаратная реализация, снимающая
 AP микропараметры среды, дает принципиально невоспроизводимый
 AP результат - даже в той же лаборатории с тем же образцом
 AP микрохарактеристики среды изменяются с течением времени.

Никто, в общем, не мешает записывать использованную последовательность...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Голова не может думать.  Там кальций, а не кремний.
 -- (С)энта


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Hello!

On Wednesday 18 March 2009 15:15:32 Artem Chuprina wrote:
  AP Любой эксперимент, в т.ч. численный, должен быть
  AP воспроизводим. Программная реализация (через прямое-обратное фурье)
  AP работает с любым случайным шумом на входе и, следовательно, условие
  AP воспроизводимости соблюдается. Аппаратная реализация, снимающая
  AP микропараметры среды, дает принципиально невоспроизводимый
  AP результат - даже в той же лаборатории с тем же образцом
  AP микрохарактеристики среды изменяются с течением времени.

 Никто, в общем, не мешает записывать использованную последовательность...

Результат численного эксперимента не должен зависеть от исходного 
распределения с заданными макропараметрами (скажем, задаем радиус корреляции 
исходных неоднородностей, амплитуду и гауссов закон распределения). Так что 
работать с одной и той же последовательностью нельзя, наоборот, требуется 
создать некоторое множество начальных распределений и на всех прогнать 
эксперимент. Если численная модель верна, то при тех же макропараметрах среды 
любое начальное распределение должно приводить к одинаковому результату.

Best regards.

Re: Функционал и интерфейс

В Срд, 18/03/2009 в 13:34 +0300, Alexey Pechnikov пишет:
Hello!

Предложенная вами архитектура не годится. Хотя бы потому, что 1
слушающий процесс всегда будет узким местом.

Еще есть ненулевое время на открытие сокета, обработку заголовков запроса,
ожидание свободного процесса из пула процессов для вычислений и проч.

Да, но это уже ботаника, без измерений нечего тут сказать.

Далее, операции чтения с диска могут
выполняться параллельно многими процессами (есть кэш диска плюс кэш
операционной системы). И для записи даже для SATA-диска размер очереди
команд, равный 1, далеко не оптимум, а для SAS дисков тем более.

Совершенно неверно. Для SATA дисков, если не ошибаюсь, эффективная очередь
равно примерно 4, а для SCSI и вовсе около 20. Контроллер диска может
переставлять команды в очереди так, чтобы требовалось минимальное кол-во
перемещений головки.

Для SSD дисков и вовсе параллельное чтение заложено в
архитектуре.

Про это в Инете не нашёл, можно ссылку?

Насчёт кэша. Как вариант можно делать несколько процессов на диск, или
кэшировать прям в процессе.

В пределах оптимальной очереди команд для диска и при помощи кэша ФС каждый
из
параллельных процессов чтения будет работать не медленнее, чем если бы он был
единственный. То есть запуск N процессов чтения увеличит производительность в
N раз при оптимальной нагрузке (линейно). Понятно, что при возрастании
нагрузки линейной зависимости уже не будет.

Не говоря уже о бессмысленности создания бутылочного горла
между читающими и вычисляющими процессами.

Ерунда. Что вы будете держать в общей памяти - кэш всего жесткого диска?

Нет. Буферы запросов и ответов, чтоб большие потоки по пайпам не гонять
туда-сюда.

Данные обрабатываемого запроса в других процессах/потоках никому просто не
нужны. А с диском/сетью/БД лучше работать пулам процессов, как уже
рассмотрено
выше. А насчет общей памяти - от этого решения уже и многие СУБД
отказываются.
В результате использования shared memory тот же оракл масштабируется намного
хуже терадата. PostgreSQL так же использует shared memory, что приводит к
различным проблемам. Я уж не говорю про сложность такого решения.

Я не пытаюсь угадать, я пытаюсь размышлять.

Размышления строятся на основе фактов, а не на догадках.

Я считаю, что глупо думать, что раз apache2 так устроенна то это
наиболее оптимальный вариант. Есть пословица: Бог создал мир на 7 дней,
потому что ему не приходилось думать о проблемах обратной
совместимости. Так вот во многих приложениях их настоящая архитектура -
это пережиток прошлого, который дорого переделать.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
15:35:59 +0300:

AP Любой эксперимент, в т.ч. численный, должен быть
AP воспроизводим. Программная реализация (через прямое-обратное фурье)
AP работает с любым случайным шумом на входе и, следовательно, условие
AP воспроизводимости соблюдается. Аппаратная реализация, снимающая
AP микропараметры среды, дает принципиально невоспроизводимый
AP результат - даже в той же лаборатории с тем же образцом
AP микрохарактеристики среды изменяются с течением времени.

Никто, в общем, не мешает записывать использованную последовательность...

AP Результат численного эксперимента не должен зависеть от исходного
AP распределения с заданными макропараметрами (скажем, задаем радиус
AP корреляции исходных неоднородностей, амплитуду и гауссов закон
AP распределения). Так что работать с одной и той же
AP последовательностью нельзя, наоборот, требуется создать некоторое
AP множество начальных распределений и на всех прогнать
AP эксперимент. Если численная модель верна, то при тех же
AP макропараметрах среды любое начальное распределение должно
AP приводить к одинаковому результату.

Импоссибл. Потому что точность вычислений ограничена по определению.
Равно как и точность статистики. Оно может приводить только к
_близкому_ результату. И при _близких_, а не _совпадающих_
макропараметрах - тоже.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Will write code that writes code that writes code that writes code for
money.
-- on comp.lang.lisp

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Срд, 18/03/2009 в 21:32 +0900, Alexander Danilov пишет:
 Alexander GQ Gerasiov пишет:
  На Tue, 17 Mar 2009 20:37:53 +0300
  Alexey Pechnikov pechni...@mobigroup.ru записано:
  
  Hello!
 
  On Tuesday 17 March 2009 19:33:16 Yuri Kozlov wrote:
  Ну так как, пробовать будем?
  Неа.
 
  Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
  файлов. Или Вы считаете их равнозначными задачами?
  Есть у меня и демоны на тикле, например, собирают и обрабатывают
  данные с цисок и других АТС. Написать то же самое на С большая работа
  (на тикле используются события для прослушивания множества сокетов, а
  на С придется создавать отдельные потоки), потому и не предлагаю как
  тестовую задачу (притом демоны умеют держать в in-memory SQLite
  database те данные, которые не удалось записать в persistent
  database), не говоря уж о реализации самой логики обработки.
  
  Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
  соответствующие примитивы.
  
 
 Вообще говоря, есть libevent, с помощью которой на Си событийно писать проще.
 Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком 
 низкоуровневый)
 и развивается паранойя при использовании каждого указателя.

Прикол в том, что уровень языка Си выбирается программистом посредством
выбора библиотек нужных уровней. На libc конечно тяжело прикладуху
писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что
тебе больше подходит для конкретной задачи.

Как я уже писал, на Си легко работать с объектной моделью, не сложнее
чем на C++ или другом языке. Надо тебе крупноузловая сборка -
пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
высокого уровня ограничивают тебя высотой своего уровня.

-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Иван Лох - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 15:58:11 +0300:

  Импоссибл.  Потому что точность вычислений ограничена по
  определению.  Равно как и точность статистики.  Оно может приводить
  только к _близкому_ результату.  И при _близких_, а не _совпадающих_
  макропараметрах - тоже.

 ИЛ Не. Имеется в виду, что решение должно сходиться к одной точке.  А
 ИЛ не к близкой к ней ;-}

_Сходиться_ - не вопрос.  Вопрос в том, что _точное_ значение этой
точки получить все равно невозможно принципиально.  Равно как и _точные_
значения макропараметров распределения.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Курицца - не пицца. (Итальянская пословицца)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
15:03:57 +0200:

   Ну так как, пробовать будем?
   Неа.
  
   Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
   файлов. Или Вы считаете их равнозначными задачами?
   Есть у меня и демоны на тикле, например, собирают и обрабатывают
   данные с цисок и других АТС. Написать то же самое на С большая работа
   (на тикле используются события для прослушивания множества сокетов, а
   на С придется создавать отдельные потоки), потому и не предлагаю как
   тестовую задачу (притом демоны умеют держать в in-memory SQLite
   database те данные, которые не удалось записать в persistent
   database), не говоря уж о реализации самой логики обработки.
   
   Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
   соответствующие примитивы.
   
  
  Вообще говоря, есть libevent, с помощью которой на Си событийно писать 
  проще.
  Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком 
  низкоуровневый)
  и развивается паранойя при использовании каждого указателя.

 ПК Прикол в том, что уровень языка Си выбирается программистом посредством
 ПК выбора библиотек нужных уровней. На libc конечно тяжело прикладуху
 ПК писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что
 ПК тебе больше подходит для конкретной задачи.

 ПК Как я уже писал, на Си легко работать с объектной моделью, не сложнее
 ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка -
 ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
 ПК высокого уровня ограничивают тебя высотой своего уровня.

Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

Таким образом, у тебя в любом случае неудобный синтаксис и в любом
случае распределение памяти.  Ты от них уйти не можешь.

При языке высокого уровня же ты можешь вынести в отдельную библиотеку
то, что таки да, надо сделать на C (хинт: вообще-то бОльшую часть работы
с низким уровнем и на них можно сделать достаточно эффективно - тот же
бинарный протокол на tcl реализовать в разы проще, чем на C).

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

The Eclipse Platform is an open and extensible platform
for anything and yet nothing in particular.
 -- apt-cache show eclipse-platform


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Alexander Danilov - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
23:05:50 +0900:

Ну так как, пробовать будем?
Неа.

Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
файлов. Или Вы считаете их равнозначными задачами?
Есть у меня и демоны на тикле, например, собирают и обрабатывают
данные с цисок и других АТС. Написать то же самое на С большая работа
(на тикле используются события для прослушивания множества сокетов, а
на С придется создавать отдельные потоки), потому и не предлагаю как
тестовую задачу (притом демоны умеют держать в in-memory SQLite
database те данные, которые не удалось записать в persistent
database), не говоря уж о реализации самой логики обработки.
Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в
которых
соответствующие примитивы.
Вообще говоря, есть libevent, с помощью которой на Си
событийно писать проще.
Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком
низкоуровневый)
и развивается паранойя при использовании каждого указателя.

ПК Прикол в том, что уровень языка Си выбирается программистом посредством
ПК выбора библиотек нужных уровней. На libc конечно тяжело прикладуху
ПК писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что
ПК тебе больше подходит для конкретной задачи.

ПК Как я уже писал, на Си легко работать с объектной моделью, не сложнее
ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка -
ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
ПК высокого уровня ограничивают тебя высотой своего уровня.

Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

AD Кстати, Tcl - это сишная библиотека хорошего качества, рекомендую. :)

Кстати, да.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Голова не может думать. Там кальций, а не кремний.
-- (С)энта

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Срд, 18/03/2009 в 16:31 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
15:03:57 +0200:

Ну так как, пробовать будем?
Неа.

Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
соответствующие примитивы.

Вообще говоря, есть libevent, с помощью которой на Си событийно писать
проще.
Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком
низкоуровневый)
и развивается паранойя при использовании каждого указателя.

Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
потомков одной командой. Так что это дело инструментов, а GTK+ и кстати
glib это умеют.

Чем вдруг?

Вопрос удобства можно обсудить, очень интересно.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Срд, 18/03/2009 в 23:05 +0900, Alexander Danilov пишет:
 Artem Chuprina пишет:
  Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
  15:03:57 +0200:
  
 Ну так как, пробовать будем?
 Неа.

 Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
 файлов. Или Вы считаете их равнозначными задачами?
 Есть у меня и демоны на тикле, например, собирают и обрабатывают
 данные с цисок и других АТС. Написать то же самое на С большая работа
 (на тикле используются события для прослушивания множества сокетов, а
 на С придется создавать отдельные потоки), потому и не предлагаю как
 тестовую задачу (притом демоны умеют держать в in-memory SQLite
 database те данные, которые не удалось записать в persistent
 database), не говоря уж о реализации самой логики обработки.
 
 Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
 соответствующие примитивы.
 

Вообще говоря, есть libevent, с помощью которой на Си событийно писать 
  проще.
Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком 
  низкоуровневый)
и развивается паранойя при использовании каждого указателя.
  
   ПК Прикол в том, что уровень языка Си выбирается программистом посредством
   ПК выбора библиотек нужных уровней. На libc конечно тяжело прикладуху
   ПК писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что
   ПК тебе больше подходит для конкретной задачи.
  
   ПК Как я уже писал, на Си легко работать с объектной моделью, не сложнее
   ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка -
   ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
   ПК высокого уровня ограничивают тебя высотой своего уровня.
  
  Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
  получаешь высокоуровневый подъязык с неудобным синтаксисом и
  ... правильно, все равно заботой о распределении памяти (почистить за
  тобой все равно никто не сможет).
  
  Таким образом, у тебя в любом случае неудобный синтаксис и в любом
  случае распределение памяти.  Ты от них уйти не можешь.
  
  При языке высокого уровня же ты можешь вынести в отдельную библиотеку
  то, что таки да, надо сделать на C (хинт: вообще-то бОльшую часть работы
  с низким уровнем и на них можно сделать достаточно эффективно - тот же
  бинарный протокол на tcl реализовать в разы проще, чем на C).
  
 
 Кстати, Tcl - это сишная библиотека хорошего качества, рекомендую. :)

:-D

-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

On 18 March 2009 13:36:11 Artem Chuprina wrote:
chaos - debian-russian@lists.debian.org @ Wed, 18 Mar 2009 12:55:55 +0200:
Перл бы еще рассказал, с какими аргументами была вызвана
функция, что позволило бы найти ошибку гораздо быстрее.

ПК Не спорю. Этот инструмент хорош, но не для фундаментальных
задач.

Для фундаментальных задач хороши инструменты, от которых ты,
подозреваю, в лучшем случае название слышал...

c Для начала тогда было бы не плохо определить, что это за задачи
c такие, которые относятся к разряду фундаментальных. И тут
желательно c не субъективное восприятие отдельной личности (потому как
в этом c случае будет всё ну очень растяжимо) а некоторая принятая
c классификация.

Фундаментальные - это, например, проверка теорий возникновения
Вселенной.

c Это как-то не определение классификации, а просто пример, не более
того.

Определения тут давать бессмысленно. Не математика. Всегда найдется
пограничный случай.

Именно.
Это говорит как минимум о том что понятие изначально не определено, и
пользоваться им в спорных ситуациях не имеет смысла, так как только больше
запутает и совершенно не внесёт ясности.

Re: Функционал и интерфейс

On 18 March 2009 15:58:42 Alexander GQ Gerasiov wrote:
Tue, 17 Mar 2009 22:00:54 +0300

Alexey Pechnikov pechni...@mobigroup.ru wrote:
Hello!

Постановка с подковыркой, заведомо выиграет C# со встроенным MFC
или .Net или что там у них сейчас.

Ошибаетесь. У меня под рукой дебиан как минимум на x86 и arm
архитектурах есть. Потому речь и шла о чистом С, что он
кроссплатформенный - тикль, понятно, тоже, как следствие.

И, кстати, MFC это враппер для Windows API, а не библиотека
алгоритмов. Библиотека алгоритмов для C++ это STL, которую сделали в
Silicon Graphics, насколько мне помнится.

Не говоря о том, что за Qt на сервере сразу надо убивать из
рогатки по рецепту Остапа Бендера.

Только за GLib убивать не стоит, за QtCore наверное тоже.

Стоит. За использование C++ с огромными перегруженными библиотеками.

Кто огромный перегруженный? QtCore? Ну-ну.
GLib - вообще объектный но на Си =\

Re: Функционал и интерфейс

On 18 March 2009 15:03:57 Покотиленко Костик wrote:
 В Срд, 18/03/2009 в 21:32 +0900, Alexander Danilov пишет:
  Alexander GQ Gerasiov пишет:
   На Tue, 17 Mar 2009 20:37:53 +0300
  
   Alexey Pechnikov pechni...@mobigroup.ru записано:
   Hello!
  
   On Tuesday 17 March 2009 19:33:16 Yuri Kozlov wrote:
   Ну так как, пробовать будем?
  
   Неа.
  
   Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
   файлов. Или Вы считаете их равнозначными задачами?
  
   Есть у меня и демоны на тикле, например, собирают и обрабатывают
   данные с цисок и других АТС. Написать то же самое на С большая работа
   (на тикле используются события для прослушивания множества сокетов, а
   на С придется создавать отдельные потоки), потому и не предлагаю как
   тестовую задачу (притом демоны умеют держать в in-memory SQLite
   database те данные, которые не удалось записать в persistent
   database), не говоря уж о реализации самой логики обработки.
  
   Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
   соответствующие примитивы.
 
  Вообще говоря, есть libevent, с помощью которой на Си событийно писать
  проще. Но вообще прикладуху на Си писать не интересно, борьба с
  языком(слишком низкоуровневый) и развивается паранойя при использовании
  каждого указателя.

 Прикол в том, что уровень языка Си выбирается программистом посредством
 выбора библиотек нужных уровней. На libc конечно тяжело прикладуху
 писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что
 тебе больше подходит для конкретной задачи.

 Как я уже писал, на Си легко работать с объектной моделью, не сложнее
 чем на C++ или другом языке. Надо тебе крупноузловая сборка -
 пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
 высокого уровня ограничивают тебя высотой своего уровня.

а меня вот почему-то не ограничивают... что я делаю не так?

Re: Функционал и интерфейс

Hello!

On Wednesday 18 March 2009 16:23:08 Artem Chuprina wrote:
   Импоссибл.  Потому что точность вычислений ограничена по
   определению.  Равно как и точность статистики.  Оно может приводить
   только к _близкому_ результату.  И при _близких_, а не _совпадающих_
   макропараметрах - тоже.

  ИЛ Не. Имеется в виду, что решение должно сходиться к одной точке.  А
  ИЛ не к близкой к ней ;-}

 _Сходиться_ - не вопрос.  Вопрос в том, что _точное_ значение этой
 точки получить все равно невозможно принципиально.  Равно как и _точные_
 значения макропараметров распределения.

В физике всегда подразумевается ошибка измерения. К примеру, я беру полимер с 
начальными (собственными тепловыми) неоднородностями в 2 мкм, радиус 
корреляции которых измерен с точностью 0,5 мкм. Предложенная мною система 
уравнений, которую необходимо подтвердить экспериментально, в определенных 
условиях обещает разгон этих неоднородностей до 10 микрон в тонком слое 
(можно также рассматривать разрешение в линиях на миллиметр, если целью будет 
запись изображения). А вот при численном счете для двумерной диффузионной 
модели 2000х2000 отсчетов при 10-ти отсчетах на микрон может потребоваться 
использовать числа типа double (а float недостаточно), хотя результат нужно 
знать с точностью до 0,5 микрон. Более того, математика подсказывает, что 
столько отсчетов на микрон нам не нужно (теорема Котельникова), однако 
выбранная схема численного счета накладывает более жесткие ограничения.

Если уравнения составлены верно и ограничения численной схемы выполняются, то 
я получу значение итогового радиуса корреляции с допустимой для меня 
погрешностью численного счета (погрешность это максимально возможное 
отклонение от истинного результата) и погрешностью указания начальных 
условий (влияние которых на значение результата может быть измерено при 
многократном запуске численного счета с разными начальными условиями), которое 
согласно моим ожиданиям будет равно экспериментально измеренному с точностью 
0,5 микрона :-) 

Best regards.

Re: Функционал и интерфейс

Hello!

Да, но это уже ботаника, без измерений нечего тут сказать.

Вам гугл за неуплату отключили? :-)

Для SSD дисков и вовсе параллельное чтение заложено в
архитектуре.

Про это в Инете не нашёл, можно ссылку?

Утилиты для измерения io performance есть в дебиане. Возьмите и проверьте.

Ерунда. Что вы будете держать в общей памяти - кэш всего жесткого диска?

Нет. Буферы запросов и ответов, чтоб большие потоки по пайпам не гонять
туда-сюда.

Ха.

Я считаю, что глупо думать, что раз apache2 так устроенна то это
наиболее оптимальный вариант.

Я не знаю, как устроен apache2.

Так вот во многих приложениях их настоящая архитектура -
это пережиток прошлого, который дорого переделать.

Best regards.

Re: Функционал и интерфейс

Иван Лох - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 17:33:13 +0300:

   ИЛ Не. Имеется в виду, что решение должно сходиться к одной точке.  А
   ИЛ не к близкой к ней ;-}
  
  _Сходиться_ - не вопрос.  Вопрос в том, что _точное_ значение этой
  точки получить все равно невозможно принципиально.  Равно как и _точные_
  значения макропараметров распределения.

 ИЛ Точное значение -- это какое-нибудь трансцендентное число? Тогда
 ИЛ нет, конечно. Но обеспечить _наперед заданную_ точность можно на
 ИЛ любом распределении. Если мы, конечно, в нужную долину попали.

В вероятностной-то модели?  Ну, за время, сравнимое с возрастом
Вселенной (а на задачах про Вселенную и немало его превосходящее) -
да...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

НИИ требуются:
1. Кто бы мог подумать.
Кнышев.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Покотиленко Костик - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
17:08:20 +0200:

Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

Ну и там прочее по мелочи - а что у нас не освободится, если вылетит
ошибка вот тут?

ПК Чем вдруг?

ПК Вопрос удобства можно обсудить, очень интересно.

Это не мне, это Печникову приходится слазить. А я под задачу подбираю
наиболее удобный инструмент.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Творить - не делать! (c)Элхэ Ниеннах

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Hello!

On Wednesday 18 March 2009 20:42:25 Artem Chuprina wrote:
ИЛ Точное значение -- это какое-нибудь трансцендентное число? Тогда
ИЛ нет, конечно. Но обеспечить _наперед заданную_ точность можно на
ИЛ любом распределении. Если мы, конечно, в нужную долину попали.

В вероятностной-то модели? Ну, за время, сравнимое с возрастом
Вселенной (а на задачах про Вселенную и немало его превосходящее) -
да...

Зависит от того, какую схему счета выберете и на каком количестве отсчетов
моделировать будете. Многие вещи довольно легко моделируются на современных
персоналках - экспозиция фотоматериалов в двумерном случае, к примеру. В
многомерном пространстве ситуация сложнее, потому обычно мерность уменьшают
насколько возможно аналитическими преобразованиями и разными допущениями. Но
вот задачи из теории струн (минимум 5 измерений) в более или менее поддающееся
численному счету 4-х мерное пространство компактифицировать нельзя. А уж если
все 10 или 11 измерений рассматривать... Вероятно, Большой адронный коллайдер
это самый дешевый способ моделирования для физики сверхвысоких энергий (и,
соответственно, многих измерений).

Best regards.

Re: Функционал и интерфейс

Hello!

On Wednesday 18 March 2009 20:52:44 Artem Chuprina wrote:
  ПК Мне нравится с годами углубляться в один и тот же язык, чем с каждым
  ПК годом изучать их больше. На Си можно сделать всё, а тебе видимо
  ПК приходится слазить с Тикля иногда.

  ПК Вопрос удобства можно обсудить, очень интересно.

 Это не мне, это Печникову приходится слазить.  А я под задачу подбираю
 наиболее удобный инструмент.

Alexander Danilov недавно высказывал желание сделать аналог SQLite на одном из 
функциональных языков. Имхо не лучшая идея с точки зрения эффективности, 
предпочитаю на С низкоуровневые вещи делать (ну может еще и ностальгия у меня 
по С, не буду отрицать). Ну если напишет - посмотрим :-)

Best regards.

Re: Функционал и интерфейс

Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
21:27:19 +0300:

ИЛ Точное значение -- это какое-нибудь трансцендентное число? Тогда
ИЛ нет, конечно. Но обеспечить _наперед заданную_ точность можно на
ИЛ любом распределении. Если мы, конечно, в нужную долину попали.

AP Зависит от того, какую схему счета выберете и на каком количестве
AP отсчетов моделировать будете.

_Зависит_ от требуемой точности. По условию. Схема счета
предполагается выбранной с умом, естественно. То есть если не
оптимальная, то близко к тому. А вот все остальное определяется
требуемой точностью...

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Рюкзак не пересобирают, рюкзак укладывают! (c)Руна

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
21:32:38 +0300:

ПК Вопрос удобства можно обсудить, очень интересно.

Это не мне, это Печникову приходится слазить. А я под задачу подбираю
наиболее удобный инструмент.

AP Alexander Danilov недавно высказывал желание сделать аналог SQLite на
одном из
AP функциональных языков. Имхо не лучшая идея с точки зрения эффективности,
AP предпочитаю на С низкоуровневые вещи делать (ну может еще и ностальгия у
меня
AP по С, не буду отрицать). Ну если напишет - посмотрим :-)

Эээ... А где ты в задаче написания _аналога_ SQLite обнаружил низкий уровень?

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Save the environment. Create a closure today.
-- Cormac Flanagan

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 00:05 +0300, Alexey Pechnikov пишет:
Hello!

On Monday 16 March 2009 20:48:44 Покотиленко Костик wrote:
Про потребляемую память забываем.

И яркий пример тому тот же spamassassin. Он одновременно может только 5
потоков обрабатывать, как написано в документации, unless you know what
you're doing.

А что, все программы на С умеют работать с тысячами потоков? Интереснее
работа
с событиями в тикле, к примеру, когда не требуется плодить тучу потоков, чтоб
одновременно снимать данные, скажем, с десятка цисок.

Это вопрос больше алгоритмов, и меньше языков. На языках более высокого
уровня такое тяжело сделать компактно.

Вы правы, когда говорите, что
- нет смысла экономить килобайты и мегабайты памяти, когда речь идёт о
ПО работающем с единственном экземпляре, т.к. память дешёвая;
- нет смысла оптимизировать тысячи и сотни тысяч MIPS'ов в процедуре,
которая выполняется раз в относительно большой период времени, т.к. Вы
сэкономите не больше секунды.

И в чем заключается экономия?

Например, работа со строками на С без использования специальных библиотек
значительно менее эффективна, чем в скриптовых языках. Попробуйте написать
программу на С, которая по обработке регекспов обгонит перловый скрипт.

Ну, возьмем другой пример - сжатие/распаковка данных. Лично я предпочитаю
делать расширения к SQLite, чтобы можно было пользоваться как из тикля, так и
из шелла, в данном случае используем системную zlib, в итоге получаем:
$ cat compress.c |wc -l
120
И это с комментариями и инструкциями по сборке! И в моем полном распоряжении
эффективный инструмент, доступный как из программы, так и в консоли. Плюс
SQLiteMan, написанный С++, и некоторые другие проекты пользуются этим и
другими модулями, при том, что я при написании кода могу совершенно не
беспокоиться, на чем будет сделано клиентское приложение. Вот это и есть
эффективность (оптимизируем именно то, что нуждается в оптимизации) плюс
повторное использование кода. Ваши же десятки и сотни килобайт кода, который
годится только для одного вашего проекта, никто и читать не станет, проще
заново написать.

Хорошее решение то, что работает.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
19:04:24 +0200:

Демоны почему-то чаще всего пишут не на скриптовых языках.

Ошибаетесь. Большинство написанных в последние несколько лет
демонов как раз
скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас
же очень много
написано на скриптовых языках.

Проверил список демонов на одной из машин
snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog,
klog,
mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind и
еще
несколько других - все не скриптовые.
Единственный найденный скриптовый - xen

ПК spamassassin тоже скриптовый, но это его минус, причём большой.

Минус его не в этом. Сделать ту же обработку на C у тебя, может, и
получится, но шансы, что она окажется быстрее, близки к нулю. Потому
что perl заточен ровно под задачи этого класса, и производительность
_этих_ операций в нем вылизана гораздо лучше, чем это сможешь сделать ты
за ограниченное время.

ПК Ты прав, не по тому пути они пошли, но их уже не догнать.

Кто они? Админы?

ПК Разработчики SA.

А куды им бечь? Не анализировать письмо от слова совсем?

ПК Пойми в чём тут дело? С perl и python всегда так.

ПК downloading servers from
http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x
ПК Traceback (most recent call last):
ПК File /usr/bin/pyzor, line 8, in ?
ПК pyzor.client.run()
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line 1003,
ПК in run
ПК ExecCall().run()
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line 184,
in
ПК run
ПК self.servers = self.get_servers(servers_fn)
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line 409,
in
ПК get_servers
ПК servers.read(open(servers_fn))
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line 117,
in
ПК read
ПК self.append(pyzor.Address.from_str(line))
ПК File /var/lib/python-support/python2.4/pyzor/__init__.py, line 458,
ПК in from_str
ПК fields[1] = int(fields[1])
ПК IndexError: list index out of range

Вот с python - да, сам регулярно вслух удивляюсь. Вроде бы язык не
способствует неаккуратности, а поди ж ты... А с perl - нет.

ПК Всё дело в том, что сильно высокие языки много от программиста
ПК скрывают, упрощают ему жизнь так сказать. Он по этому и не знает,
ПК что мир реально сложнее устроен.

Вот тут у меня как раз опыт противоположный. Программист на языке более
высокого уровня гораздо чаще имеет дело как раз с ошибкой мир устроен
сложнее. В отличие от программиста на более низком уровне, которому от
полученной ошибки до как в этом месте устроен мир настолько длинный и
сложный путь, что обработать он ее не может, и потому жухает нах.

ПК По этому - чуть шо, получаем какую-то ругань, никому, кроме
ПК потенциального хакера не полезную. По ней же ничё не скажешь, кроме
ПК версии python.

Ну почему ничё? Хотя у перла, как мне кажется, обычно с руганью
лучше, но и тут, в общем, можно сказать, что именно слетело. Нету в
fields второго элемента. На C ты в этом месте, вероятно, получил бы
сегфолт. Ну или (если бы сегфолт вылетел в твоих тестах и ты бы
закрылся от него проверкой) невнятное сообщение мама, тут чего-то не
хватает.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Юзер упорствует в хождении по граблям. Образовавшиеся шишки он считает
трудовыми мозолями. (С)энта

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Hello!

On Tuesday 17 March 2009 13:44:05 Покотиленко Костик wrote:
 Хорошее решение то, что работает.

Т.е. mysql-demon в KDE4 хорошее решение? И spamassassin тоже хорошее 
решение - так что же вы его выше так ругали? 

Примерно так же можно сказать - хорошая еда, которая пахнет. А пахнет розами 
или помоями вам, как видно, все равно...

Best regards.

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 14:15 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
19:04:24 +0200:

Демоны почему-то чаще всего пишут не на скриптовых языках.

Проверил список демонов на одной из машин
snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog,
klog,
mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind
и еще
несколько других - все не скриптовые.
Единственный найденный скриптовый - xen

ПК spamassassin тоже скриптовый, но это его минус, причём большой.

ПК Ты прав, не по тому пути они пошли, но их уже не догнать.

Кто они? Админы?

ПК Разработчики SA.

А куды им бечь? Не анализировать письмо от слова совсем?

ПК Пойми в чём тут дело? С perl и python всегда так.

ПК downloading servers from
http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x
ПК Traceback (most recent call last):
ПК File /usr/bin/pyzor, line 8, in ?
ПК pyzor.client.run()
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line
1003,
ПК in run
ПК ExecCall().run()
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line
184, in
ПК run
ПК self.servers = self.get_servers(servers_fn)
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line
409, in
ПК get_servers
ПК servers.read(open(servers_fn))
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line
117, in
ПК read
ПК self.append(pyzor.Address.from_str(line))
ПК File /var/lib/python-support/python2.4/pyzor/__init__.py, line
458,
ПК in from_str
ПК fields[1] = int(fields[1])
ПК IndexError: list index out of range

Не спорю. Этот инструмент хорош, но не для фундаментальных задач.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 15:20 +0300, Alexey Pechnikov пишет:
Hello!

On Tuesday 17 March 2009 13:44:05 Покотиленко Костик wrote:
Хорошее решение то, что работает.

Т.е. mysql-demon в KDE4 хорошее решение? И spamassassin тоже хорошее
решение - так что же вы его выше так ругали?

Примерно так же можно сказать - хорошая еда, которая пахнет. А пахнет розами
или помоями вам, как видно, все равно...

Ребята, которые запхнув mysql-demon в KDE4 решили свою узкую задачу, так
сказать не затрачивая драгоценного времени программиста на придумывание
чего-то более подходящего, т.к. память и MIPS'ы дешёвые.

Поскольку в мире бесплатного ПО претензии предъявлять не этично, Вам
остаётся либо убедить их исправить положение, либо исправить самому.

А мне остаётся только радоваться, что пока такое не произошло с Гномом,
на котором сижу я.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 21:47 +0900, Alexander Danilov пишет:
Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
19:04:24 +0200:

[skip]

Сегфолт он скорее всего получил бы совсем не здесь и потом бы долго удивлялся,
что-то программа свалилась на ровном месте, где никаких указателей нет.
Ошибки при работе с памятью обычно вылезают на поверхность за много
километров от места взрыва.
В этом, я считаю, особая прелесть работы с памятью напрямую, тут отладчик
зачастую бессилен помощь.

Решал много проблем такого рода, не так уж и сложно. Идёшь по пятам
аномалий и приходишь к источнику, и, дебагер тут может быть помощником.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org  @ Tue, 17 Mar 2009 
14:42:23 +0200:

  Перл бы еще рассказал, с какими аргументами была вызвана функция, что
  позволило бы найти ошибку гораздо быстрее.

 ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.

Для фундаментальных задач хороши инструменты, от которых ты, подозреваю,
в лучшем случае название слышал...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Это неправильный шелл. В нем дают неправильный перл. (С)энта


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-17 Пенетрантность chaos

On 17 March 2009 17:15:16 Artem Chuprina wrote:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Tue, 17 Mar 2009 
14:42:23 +0200:
   Перл бы еще рассказал, с какими аргументами была вызвана функция, что
   позволило бы найти ошибку гораздо быстрее.

  ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.

 Для фундаментальных задач хороши инструменты, от которых ты, подозреваю,
 в лучшем случае название слышал...

Для начала тогда было бы не плохо определить, что это за задачи такие, которые 
относятся к разряду фундаментальных. И тут желательно не субъективное 
восприятие отдельной личности (потому как в этом случае будет всё ну очень 
растяжимо) а некоторая принятая классификация.

Re: Функционал и интерфейс

Hello!

On Tuesday 17 March 2009 19:33:16 Yuri Kozlov wrote:
  Ну так как, пробовать будем?

 Неа.

 Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
 файлов. Или Вы считаете их равнозначными задачами?

Есть у меня и демоны на тикле, например, собирают и обрабатывают данные с 
цисок и других АТС. Написать то же самое на С большая работа (на тикле 
используются события для прослушивания множества сокетов, а на С придется 
создавать отдельные потоки), потому и не предлагаю как тестовую задачу (притом 
демоны умеют держать в in-memory SQLite database те данные, которые не удалось 
записать в persistent database), не говоря уж о реализации самой логики 
обработки.

А в той задаче, что я предлагал выше, есть как минимум несколько неочевидных 
вещей, без знания которых ваша реализация на С будет работать намного хуже 
тиклевской. Например, реализовать с нуля эффективный хэш с текстовыми 
ключами далеко не так просто, как кажется. И стоит в задаче с парсером лога 
указать, к примеру, 100 параметров командной строки, как ваша реализация 
станет весьма медленной (и уверен, вы бы и не подумали об этом, в то время как 
создатели tcl подумали за вас). Есть и другие подводные камни. В итоге 
написать на С код приличного качества требует кучу времени даже в том случае, 
когда вы знаете, как это сделать. Когда-то я встраивал в свои С++ приложения 
несложный интерпретатор, но после перехода с perl на tcl все приложения делаю 
на tcl, при необходимости реализуя некоторые модули на C (и смог забыть С++, 
как страшный сон). В свое время мне довелось писать на С для 
микроконтроллеров, так вот, написать код  и обеспечить стабильную работу 
прошивки на С, которая работает со встроенной флэшью, GPS и GSM-модулями, 
потребовало несколько недель (в те времена используемый data-канал GSM был 
очень неустойчив, но это отдельный разговор). На тикле можно написать 
эквивалентную функциональность за пару дней.

Best regards.

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 18:15 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Tue, 17 Mar 2009 
 14:42:23 +0200:
 
   Перл бы еще рассказал, с какими аргументами была вызвана функция, что
   позволило бы найти ошибку гораздо быстрее.
 
  ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.
 
 Для фундаментальных задач хороши инструменты, от которых ты, подозреваю,
 в лучшем случае название слышал...

Это не продуктивный стиль общения.

-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 20:37 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Tuesday 17 March 2009 19:33:16 Yuri Kozlov wrote:
   Ну так как, пробовать будем?
 
  Неа.
 
  Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
  файлов. Или Вы считаете их равнозначными задачами?
 
 Есть у меня и демоны на тикле, например, собирают и обрабатывают данные с 
 цисок и других АТС. Написать то же самое на С большая работа (на тикле 
 используются события для прослушивания множества сокетов, а на С придется 
 создавать отдельные потоки),

Кто тебе такое сказал? Если за последнюю пару лет ничего не изменилось
то в Линуксе осталось несколько ситуаций блокирующих программу, это
работа с диском и штатный DNS резолвинг, может ещё чего.

А работа с пайпами и сокетами в любом количестве сто лет может
производиться без блокировок одним процессом.

  потому и не предлагаю как тестовую задачу (притом 
 демоны умеют держать в in-memory SQLite database те данные, которые не 
 удалось 
 записать в persistent database), не говоря уж о реализации самой логики 
 обработки.
 
 А в той задаче, что я предлагал выше, есть как минимум несколько неочевидных 
 вещей, без знания которых ваша реализация на С будет работать намного хуже 
 тиклевской. Например, реализовать с нуля эффективный хэш с текстовыми 
 ключами далеко не так просто, как кажется. И стоит в задаче с парсером лога 
 указать, к примеру, 100 параметров командной строки, как ваша реализация 
 станет весьма медленной (и уверен, вы бы и не подумали об этом, в то время 
 как 
 создатели tcl подумали за вас). Есть и другие подводные камни. В итоге 
 написать на С код приличного качества требует кучу времени даже в том случае, 
 когда вы знаете, как это сделать.

Приличное качество на любом языке требует кучу времени.

  Когда-то я встраивал в свои С++ приложения 
 несложный интерпретатор, но после перехода с perl на tcl все приложения делаю 
 на tcl, при необходимости реализуя некоторые модули на C (и смог забыть С++, 
 как страшный сон). В свое время мне довелось писать на С для 
 микроконтроллеров, так вот, написать код  и обеспечить стабильную работу 
 прошивки на С, которая работает со встроенной флэшью, GPS и GSM-модулями, 
 потребовало несколько недель (в те времена используемый data-канал GSM был 
 очень неустойчив, но это отдельный разговор). На тикле можно написать 
 эквивалентную функциональность за пару дней.
 
 Best regards.
-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 17:21 +0200, chaos пишет:
On 17 March 2009 17:15:16 Artem Chuprina wrote:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
14:42:23 +0200:
Перл бы еще рассказал, с какими аргументами была вызвана функция, что
позволило бы найти ошибку гораздо быстрее.

ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.

Для фундаментальных задач хороши инструменты, от которых ты, подозреваю,
в лучшем случае название слышал...

Для начала тогда было бы не плохо определить, что это за задачи такие,
которые
относятся к разряду фундаментальных. И тут желательно не субъективное
восприятие отдельной личности (потому как в этом случае будет всё ну очень
растяжимо) а некоторая принятая классификация.

Моя версия на вскидку:
- серверные приложения, демоны, пример:
- spamassassin
- системные приложения, пример:
- init-скрипты
- агенты по сбору счётчиков от munin-node вместе с ним

Дополняйте.

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Hello!

On Tuesday 17 March 2009 21:06:58 Alexander GQ Gerasiov wrote:
  Есть у меня и демоны на тикле, например, собирают и обрабатывают
  данные с цисок и других АТС. Написать то же самое на С большая работа
  (на тикле используются события для прослушивания множества сокетов, а
  на С придется создавать отдельные потоки), потому и не предлагаю как
  тестовую задачу (притом демоны умеют держать в in-memory SQLite
  database те данные, которые не удалось записать в persistent
  database), не говоря уж о реализации самой логики обработки.

 Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
 соответствующие примитивы.

Обращаю ваше внимание на постановку задачи:
Никаких внешних библиотек не используем, только встроенные средства.

Не говоря о том, что за Qt на сервере сразу надо убивать из рогатки по рецепту 
Остапа Бендера.

Best regards.

Re: Функционал и интерфейс

Hello!

On Tuesday 17 March 2009 21:14:37 Покотиленко Костик wrote:
Есть у меня и демоны на тикле, например, собирают и обрабатывают данные с
цисок и других АТС. Написать то же самое на С большая работа (на тикле
используются события для прослушивания множества сокетов, а на С придется
создавать отдельные потоки),

Кто тебе такое сказал? Если за последнюю пару лет ничего не изменилось
то в Линуксе осталось несколько ситуаций блокирующих программу, это
работа с диском и штатный DNS резолвинг, может ещё чего.

А работа с пайпами и сокетами в любом количестве сто лет может
производиться без блокировок одним процессом.

Между теорией на практикой в теории нет никакой разницы, а на практике -
наоборот. Тот же apache вовсе не случайно для каждого соединения отдельный
поток создает. Так что сначала попробуйте, прежде чем советовать.

Best regards.

Re: Функционал и интерфейс

Hello!

On Tuesday 17 March 2009 21:44:05 Покотиленко Костик wrote:
  Обращаю ваше внимание на постановку задачи:
  Никаких внешних библиотек не используем, только встроенные средства.

 Постановка с подковыркой, заведомо выиграет C# со встроенным MFC
 или .Net или что там у них сейчас.

Ошибаетесь. У меня под рукой дебиан как минимум на x86 и arm архитектурах 
есть. Потому речь и шла о чистом С, что он кроссплатформенный - тикль, 
понятно, тоже, как следствие.

И, кстати, MFC это враппер для Windows API, а не библиотека алгоритмов. 
Библиотека алгоритмов для C++ это STL, которую сделали в Silicon Graphics, 
насколько мне помнится.

  Не говоря о том, что за Qt на сервере сразу надо убивать из рогатки по
  рецепту Остапа Бендера.

 Только за GLib убивать не стоит, за QtCore наверное тоже.

Стоит. За использование C++ с огромными перегруженными библиотеками.

Best regards.

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 21:33 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Tuesday 17 March 2009 21:06:58 Alexander GQ Gerasiov wrote:
   Есть у меня и демоны на тикле, например, собирают и обрабатывают
   данные с цисок и других АТС. Написать то же самое на С большая работа
   (на тикле используются события для прослушивания множества сокетов, а
   на С придется создавать отдельные потоки), потому и не предлагаю как
   тестовую задачу (притом демоны умеют держать в in-memory SQLite
   database те данные, которые не удалось записать в persistent
   database), не говоря уж о реализации самой логики обработки.
 
  Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
  соответствующие примитивы.
 
 Обращаю ваше внимание на постановку задачи:
 Никаких внешних библиотек не используем, только встроенные средства.

Постановка с подковыркой, заведомо выиграет C# со встроенным MFC
или .Net или что там у них сейчас.

 Не говоря о том, что за Qt на сервере сразу надо убивать из рогатки по 
 рецепту 
 Остапа Бендера.

Только за GLib убивать не стоит, за QtCore наверное тоже.

-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Вто, 17/03/2009 в 21:38 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Tuesday 17 March 2009 21:14:37 Покотиленко Костик wrote:
   Есть у меня и демоны на тикле, например, собирают и обрабатывают данные с
   цисок и других АТС. Написать то же самое на С большая работа (на тикле
   используются события для прослушивания множества сокетов, а на С придется
   создавать отдельные потоки),
 
  Кто тебе такое сказал? Если за последнюю пару лет ничего не изменилось
  то в Линуксе осталось несколько ситуаций блокирующих программу, это
  работа с диском и штатный DNS резолвинг, может ещё чего.
 
  А работа с пайпами и сокетами в любом количестве сто лет может
  производиться без блокировок одним процессом.
 
 Между теорией на практикой в теории нет никакой разницы, а на практике - 
 наоборот.
  Тот же apache вовсе не случайно для каждого соединения отдельный 
 поток создает. Так что сначала попробуйте, прежде чем советовать. 

Ничего случайно не бывает.
В случае с apache, на мой взгляд, дело в архитектуре.

Грубо говоря, Apache с одной стороны читает с диска, с другой пишет с
сокет. Работа с сокетом может производиться без блокировок, с диском
нет, следовательно один процесс много клиентов не потянет, начнутся
лаги. С другой стороны только один процесс может слушать порт (80), он
может делать accept() и потом fork() передавая установленное соединение
потомку. Ждать 5 соединений и потом делать fork() не вариант.

Если изменить архитектуру так:
- один процесс принимает все соединения с одной стороны, и общается с
несколькими процессами выполняющими вычисления (SSI, PHP, etc) в
количестве равном количеству ядер
- процессы выполняющие вычисления читают данные через процессы работы с
дисками (по одному на каждый физический диск), выполняют обработку,
отдают результат главному, тот клиенту
- процессы работы с дисками обрабатывают чтение запись и всё.

С такой архитектурой на 4-х ядрах и 2-х винчестерах при любом количестве
клиентов будет 7 процессов.

-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Hello!

On Tuesday 17 March 2009 22:19:12 Покотиленко Костик wrote:
 Если изменить архитектуру так:
 - один процесс принимает все соединения с одной стороны, и общается с
 несколькими процессами выполняющими вычисления (SSI, PHP, etc) в
 количестве равном количеству ядер
 - процессы выполняющие вычисления читают данные через процессы работы с
 дисками (по одному на каждый физический диск), выполняют обработку,
 отдают результат главному, тот клиенту
 - процессы работы с дисками обрабатывают чтение запись и всё.

 С такой архитектурой на 4-х ядрах и 2-х винчестерах при любом количестве
 клиентов будет 7 процессов.

И что, магическое число 7 принесет удачу серверу? :-)

Предложенная вами архитектура не годится. Хотя бы потому, что 1 слушающий 
процесс всегда будет узким местом. Далее, операции чтения с диска могут 
выполняться параллельно многими процессами (есть кэш диска плюс кэш 
операционной системы). И для записи даже для SATA-диска размер очереди команд, 
равный 1, далеко не оптимум, а для SAS дисков тем более. А еще есть рэйд-
контроллеры, которые дополнительно оптимизируют дисковые операции, в т.ч. за 
счет своего кэша. Не говоря уже о бессмысленности создания бутылочного горла 
между читающими и вычисляющими процессами. Не пытайтесь угадать - чтобы 
создать эффективную архитектуру, нужно знать теорию и уметь ее применять. А уж 
что касается работы с оборудованием, так тут еще требуется набор неочевидных 
компромиссов, если необходимо обеспечить поддержку, к примеру, разных типов 
дисков.

На практике потребуется пул процессов для обработки запросов и очередь (чтобы 
не создавать слишком много процессов обработки в пике нагрузки), а для 
выполнения блокирующих/потенциально опасных операций и длительных вычислений 
отдельные пулы внешних процессов (например, пулы соединений с БД) - так, в 
частности, работает AOL Server.

Best regards.

Re: Функционал и интерфейс

2009-03-17 Пенетрантность DamirX

В Втр, 17/03/2009 в 21:06 +0300, Alexander GQ Gerasiov пишет:
 Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
 соответствующие примитивы.
Ну, вообще говоря, интерпретаторы скриптовых языков (хотя они уже и не
такие уж интерпретаторы), обычно содержат средства обращени к С-шным
функциям. А в случае если библиотека популярная/полезная - то она бывает
весьма тесно интегрирована с языком (примеры имеются).
Учитывая вышесказанное, получается, что программер на С пишет клей между
библиотеками и логику приложения, который на скриптовых языках писать
проще и приятнее.

--
Damirx



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Alexey Pechnikov

В Птн, 13/03/2009 в 21:49 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Fri, 13 Mar 2009 
 19:56:06 +0200:
 
  Вот, навскидку назвал, и 
  это несмотря на то, что вы привели список _консольных_ утилит в 
 основном.
  
  Просто для информации: к любой консольной утилите (у которой есть 
 stdin
  и stdout) веб-морду можно приделать как два пальца об асфальт.
  
 Осталось только узнать зачем.
   
ПК Вот-вот.
   
ПК Плохая практика: прога с CLI + фронтенд
ПК Хорошая практика: прога с CLI -- либа -- прога с GUI
   
   То, что ты назвал плохой практикой - unix way, и тот факт, что эта
   практика - плохая, требует обоснования.  Нет, я не утверждаю, что
   браузер - достаточно хороший гуй, а HTTP - достаточно хороший протокол,
   чтобы тыкать их во _все_ дырки...  Фронтенд совершенно не обязательно
   должен работать по HTTP...
   
   Ну и да, по ходу дела ты, по сути, записал в плохую практику
   практически все клиент-серверные решения.  Начиная с SMTP и HTTP :-)
 
  ПК Не так. Не путай клиент-серверное решение и IPC с фронтендом :). Разница
  ПК очевидна:
 
  ПК 1. IPC: связь нескольких процессов в пределах одной машины
 
  ПК 2. клиент-серверное решение: связь нескольких процессов работающих на
  ПК разных машинах
 
 Это разделение уже изрядно условно.  Так, во-первых, я хожу к
 IMAP-серверу своего ноутбука вне зависимости от того, на том же ноутбуке
 у меня гнус или на совершенно другой машине.
 
 Во-вторых, и к нему, и к заведомо удаленному IMAP'у основной почтовки я
 хожу ... правильно, по IPC.  Этот IPC транслируется на удаленный хост
 посредством ssh, но и gnus, и imapd видят пайпы к локальному процессу.
 Точнее, emacs и imapd видят пайпы, а гнусу безразлично, пайп там или
 сокет, он видит вообще буфер.
 
 Я уж молчу про erlang (как язык) и прочие средства кластерной работы.  У
 них, я извиняюсь, задача _заключается в_ том, чтобы не было разницы, на
 одной машине оно выполняется или на разных.
 
 Ну и да, еще можно вспомнить про системы виртуализации и отношение их с
 лицензиями на софт :-)  А они даже у микрософта учитывают разницу между
 виртуальной и физической машиной.

Не могу не согласится. Чем более развиты становятся эти элементарные
способы взаимодействия, тем тоньше грань между ними.

Это если смотреть на вопрос в принципе. А если подойти с мыслью о
оптимальности, производительности и безопасности то окажется, что одни
способы целесообразнее использовать для одного рода взаимодействия
(локальный IPC), другие для другого (удалённый).

Как тут любят цитировать: инструмент используемый не по назначению имеет
свойство превращаться в грабли.

Вообще хочу сразу оговориться:
- я не против скриптовых языков
- я не против текстовых протоколов
- я не против любых других универсальных методов

однако следует понимать, что:
- универсальных методов не бывает :). Для каждой задачи хорош свой
метод: ограничено время для написания функционала - используй скриптовый
язык, нужна производительность и компактность - используй язык более
низкого уровня. 
- то же касается и других универсальных методов, например, трюки с IPC:
проброс пайпа на другую машину и т.п. Это хорошо, так как быстро, но
даже тут много нюансов, лично сталкивался.
- на счёт текстовых протоколов всё гораздо загадочнее для меня. Дело в
том, что протоколы отличаются от тех же скриптов тем, что
разрабатываются они, грубо, один раз, а используются везде и большим
количеством людей.

Преимущество текстового протокола только в том, что его более удобно
читать человеку, а недостатков гораздо больше. Читать бинарные данные и
парсить текст - это несоизмеримо разные процедуры в плане
производительности.

Можно даже сказать, что людям написавшим текстовый протокол всего лишь
не хватило сил написать два вида преобразований, потому как остальные
затраты соизмеримы:
- команды удобовоспроизводимые человеком - бинарный протокол
- бинарный протокол - удобочитаемый (и заметьте настраиваемый, а не
такой как есть) вывод

Пару слов о глюках связанных с пробросом ввода вывода через различные
туннели: дело в том, что в данном случае вовликаются дополнительные
буферы промежуточных (родительских) каналов связи, которыми тяжело
управлять. Пример:

$ progA | ssh u...@host progB

progA записывает каманду в вывод, команда улетает мгновенно в буфер ssh,
в случае простого протокола, без подтверждения доставки progA будет
считать команду доставленной, хотя на самом деле это ещё не так. Кроме
того часто тяжело заставить команды приходить раздельными порциями.

  ПК 3. фронтенд: использование функционала программы с одним интерфейсом в
  ПК другой программе с другим интерфейсом посредством чего-либо, в том числе
  ПК и IPC.
 
  ПК Во вменяемых ресурсах по написанию программ так и написано: функционал
  ПК нужно отделять от интерфейса. Это для многих сложно, но на то есть свои
  ПК причины, и от того есть много преимуществ.
 
  ПК В проектах, где следуют такому принципу, фронтендами редко пахнет, так

Re: Функционал и интерфейс

Hello!

On Monday 16 March 2009 13:06:13 Покотиленко Костик wrote:
однако следует понимать, что:
- универсальных методов не бывает :). Для каждой задачи хорош свой
метод: ограничено время для написания функционала - используй скриптовый
язык, нужна производительность и компактность - используй язык более
низкого уровня.

Время ограничено _всегда_. Понимаете, физиологические процессы необратимы,
поэтому бесконечного времени на одну задачу у живого существа не будет
никогда.

Второй вариант страшный, пока первый раз не сделаешь. Подойдёт для
частого сбора сотен показаний.

Дальше, если скармливать нужные счётчики и выводить их за один проход -
можно обрабатывать теоретически неограниченное количество счётчиков за
проход без дополнительных расходов.

Дольше, если превратить этот код в демон, можно значительно сократить
расходы связанные с частым сбором.

Тот же самый демон намного быстрее написать на скриптовом языке. Существенная
разница в производительности будет только на этапе загрузки, что для демона
несущественно в принципе. Зато отладка будет намного эффективнее, не нужно
перекомпилировать под разные архитектуры и проч. Так что вот как раз демон
писать на С не имеет смысла. Как вы думаете, почему в /etc/init.d/ лежат
шелловские скрипты?..

Best regards.

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Alexey Pechnikov

В Пнд, 16/03/2009 в 14:15 +0300, Alexey Pechnikov пишет:
Hello!

Второй вариант страшный, пока первый раз не сделаешь. Подойдёт для
частого сбора сотен показаний.

Дольше, если превратить этот код в демон, можно значительно сократить
расходы связанные с частым сбором.

Глупость века?

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

Hello!

On Monday 16 March 2009 14:28:11 Михаил Миронов wrote:
 Демоны почему-то чаще всего пишут не на скриптовых языках. 

Ошибаетесь. Большинство написанных в последние несколько лет демонов как раз 
скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас же очень много 
написано на скриптовых языках. 

 И скажите,
 неужели Вы думаете, что в /etc/init.d лежат сами исполняемые файлы
 демонов???

За счет того, что демон запускается шелловским скриптом, теряется единственное 
преимущество - скорость запуска.

Best regards.

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Alexey Pechnikov

Hello!

On Monday 16 March 2009 15:06:08 Михаил Миронов wrote:
 Проверил список демонов на одной из машин
 snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog, klog,
 mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind и еще
 несколько других - все не скриптовые.
 Единственный найденный скриптовый - xen

Давайте у меня посмотрим. Системные сервисы вещь консервативная, так что 
оценим рабочий софт.

PostgreSQL, pound - бинарные. Впрочем, PostgreSQL для совместимости, новые 
версии софта работают с SQLite, который уже не демон.

6 экземпляров AOLServer (встроенный интерпретатор тикля), два из них управляют 
набором пулов внешних процессов (в каждом из которых запущен интерпретатор 
тикля).

Плюс набор тиклевских демонов для сбора статистики с АТС.

Best regards.

Re: Функционал и интерфейс

В Пнд, 16/03/2009 в 14:38 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Monday 16 March 2009 14:28:11 Михаил Миронов wrote:
  Демоны почему-то чаще всего пишут не на скриптовых языках. 
 
 Ошибаетесь. Большинство написанных в последние несколько лет демонов как раз 
 скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас же очень 
 много 
 написано на скриптовых языках. 

Время покажет плюс это или минус.

  И скажите,
  неужели Вы думаете, что в /etc/init.d лежат сами исполняемые файлы
  демонов???
 
 За счет того, что демон запускается шелловским скриптом, теряется 
 единственное 
 преимущество - скорость запуска.
 
 Best regards.
-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

В Пнд, 16/03/2009 в 15:06 +0300, Михаил Миронов пишет:
 Alexey Pechnikov пишет:
  Hello!
  
  On Monday 16 March 2009 14:28:11 Михаил Миронов wrote:
  Демоны почему-то чаще всего пишут не на скриптовых языках. 
  
  Ошибаетесь. Большинство написанных в последние несколько лет демонов как 
  раз 
  скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас же очень 
  много 
  написано на скриптовых языках. 
  
 
 
 Проверил список демонов на одной из машин
 snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog, klog,
 mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind и еще
 несколько других - все не скриптовые.
 Единственный найденный скриптовый - xen

spamassassin тоже скриптовый, но это его минус, причём большой.

-- 
Покотиленко Костик cas...@meteor.dp.ua


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
12:06:13 +0200:

ПК $ progA | ssh u...@host progB

ПК progA записывает каманду в вывод, команда улетает мгновенно в буфер
ПК ssh, в случае простого протокола, без подтверждения доставки progA
ПК будет считать команду доставленной, хотя на самом деле это ещё не
ПК так.

Если она так думает в локальном случае, ее автора пора лечить :-) Никто
никому никогда не гарантировал мгновенной доставки в случае с локальным пайпом.

ПК Кроме того часто тяжело заставить команды приходить раздельными
ПК порциями.

Это тоже от сети не зависит.

Потому что тогда не будет способа воспользоваться
функционалом :-)

Так вот, у классической юниксовой CLI-программы интерфейс рассчитан на
юникс-юзера. Который ближе к разработчику, чем к энд-юзеру. И тем
самым просто является таким же API, что и у библиотеки.

ПК Ну нет же. Разные они, если подробно разобраться. Учитывая
ПК вышесказанное, API - для низкоуровнего (производительного и компактного)
ПК программирования,

Преждевременная оптимизация - корень всех зол. (c) кто-то из великих.

ПК CLI - для юникс-юзера и скриптов (по быстрому на коленке).

ПК На пример, для сбора счётчиков правил iptables можно использовать
ПК обёртку вокруг iptables -nvL | iptables-save типа:

ПК iptables-save | grep условие | cut -d -fI

ПК или такую конструкцию на Си:

ПК ...
ПК struct ipt_entry *ipt_e;
ПК char *target;

ПК for(ipt_e=iptc_first_rule(chain_name, ipt_h); ipt_e;
ПК ipt_e=iptc_next_rule(ipt_e, ipt_h)) {

ПКif(!ipt_e) {
ПКprintf(iptc_first_rule(): returned NULL pointer\n);
ПКreturn(NULL);
ПК}

ПКif(!условие) continue;

ПКtarget=iptc_get_target(ipt_e, ipt_h);

ПКprintf(Source IP: %s/%s (iface: %s), Destination IP: %s/%s (iface: %
ПК s), Target: %s, Counters: %llu bytes, %llu packets\n,
ПК x_strcpy(inet_ntoa(ipt_e-ip.src)),
ПК x_strcpy(inet_ntoa(ipt_e-ip.smsk)),
ПК ipt_e-ip.iniface,
ПК x_strcpy(inet_ntoa(ipt_e-ip.dst)),
ПК x_strcpy(inet_ntoa(ipt_e-ip.dmsk)),
ПК ipt_e-ip.outiface,
ПК target,
ПК ipt_e-counters.bcnt,
ПК ipt_e-counters.pcnt
ПК );

ПК }
ПК ...

ПК Первый вариант делается за 5 минут, подойдёт для не частого сбора
ПК небольшого числа счётчиков.

ПК Второй вариант страшный, пока первый раз не сделаешь. Подойдёт для
ПК частого сбора сотен показаний.

Я бы уже задумался о том, что узкое место такой системы - не в сборе
показаний...

ПК Дальше, если скармливать нужные счётчики и выводить их за один проход -
ПК можно обрабатывать теоретически неограниченное количество счётчиков за
ПК проход без дополнительных расходов.

Это как раз автомагически получается с iptables -L. На C тебе для этого
придется громоздить изрядную конструкцию (фактически, разрабатывать
половину перла). Оно окупится? У меня есть сомнения...

Но если этот человек может алгоритмизовать некоторый набор
своих действий - он поручает его программе, и API для этого у него уже
есть.

ПК Да, но это тоже, что и бегать в чугунных сапогах.

Результаты профайлинга предъяви, да?

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Попрошу благородного дона не обобщать с утра пораньше! (С)энта

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
14:36:44 +0200:

Демоны почему-то чаще всего пишут не на скриптовых языках.

Ошибаетесь. Большинство написанных в последние несколько лет демонов как
раз
скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас же очень
много
написано на скриптовых языках.

Проверил список демонов на одной из машин
snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog, klog,
mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind и еще
несколько других - все не скриптовые.
Единственный найденный скриптовый - xen

ПК spamassassin тоже скриптовый, но это его минус, причём большой.

Минус его в том, что он умеет больше, чем следует :-) Отчего нередко
употребляется там, где следовало бы отшить супостата на этапе
SMTP-сессии. Или тогда же пометить как спам, не анализируя содержимого
письма вообще.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Рассмотрим этот вопрос под другим гуглом...
-- http://vitus-wagner.livejournal.com/319313.html

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Тихон Тарнавский

В Пнд, 16/03/2009 в 14:40 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
12:06:13 +0200:

ПК $ progA | ssh u...@host progB

ПК Кроме того часто тяжело заставить команды приходить раздельными
ПК порциями.

Это тоже от сети не зависит.

Потому что тогда не будет способа воспользоваться
функционалом :-)

Преждевременная оптимизация - корень всех зол. (c) кто-то из великих.

ПК CLI - для юникс-юзера и скриптов (по быстрому на коленке).

ПК На пример, для сбора счётчиков правил iptables можно использовать
ПК обёртку вокруг iptables -nvL | iptables-save типа:

ПК iptables-save | grep условие | cut -d -fI

ПК или такую конструкцию на Си:

ПК ...
ПК struct ipt_entry *ipt_e;
ПК char *target;

ПК for(ipt_e=iptc_first_rule(chain_name, ipt_h); ipt_e;
ПК ipt_e=iptc_next_rule(ipt_e, ipt_h)) {

ПК if(!ipt_e) {
ПК printf(iptc_first_rule(): returned NULL pointer\n);
ПК return(NULL);
ПК }

ПК if(!условие) continue;

ПК target=iptc_get_target(ipt_e, ipt_h);

ПК printf(Source IP: %s/%s (iface: %s), Destination IP: %s/%s (iface: %
ПК s), Target: %s, Counters: %llu bytes, %llu packets\n,
ПК x_strcpy(inet_ntoa(ipt_e-ip.src)),
ПК x_strcpy(inet_ntoa(ipt_e-ip.smsk)),
ПК ipt_e-ip.iniface,
ПК x_strcpy(inet_ntoa(ipt_e-ip.dst)),
ПК x_strcpy(inet_ntoa(ipt_e-ip.dmsk)),
ПК ipt_e-ip.outiface,
ПК target,
ПК ipt_e-counters.bcnt,
ПК ipt_e-counters.pcnt
ПК);

ПК }
ПК ...

ПК Первый вариант делается за 5 минут, подойдёт для не частого сбора
ПК небольшого числа счётчиков.

ПК Второй вариант страшный, пока первый раз не сделаешь. Подойдёт для
ПК частого сбора сотен показаний.

Я бы уже задумался о том, что узкое место такой системы - не в сборе
показаний...

Уже окупилось. На системе где так работает после таких оптимизаций прогу
передающую счётчики в snmpd в top'е не видно, а snmpd иногда до 10% CPU
тратит. Следующим шагом, там от snmp откажусь в пользу самописного
демона, проблема иссякнет.

ПК Да, но это тоже, что и бегать в чугунных сапогах.

Результаты профайлинга предъяви, да?

Есть конкретный пример? С профайлингом на Ваш любимый скриптовый
язык...

--
Покотиленко Костик cas...@meteor.dp.ua

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс

On Mon, 16.03.2009 16:02:07 , Покотиленко Костик wrote:
В Пнд, 16/03/2009 в 14:40 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
12:06:13 +0200:

ПК $ progA | ssh u...@host progB

ПК Кроме того часто тяжело заставить команды приходить раздельными
ПК порциями.

Это тоже от сети не зависит.

Потому что тогда не будет способа воспользоваться
функционалом :-)

ПК Ну нет же. Разные они, если подробно разобраться. Учитывая
ПК вышесказанное, API - для низкоуровнего (производительного и
компактного)
ПК программирования,

Преждевременная оптимизация - корень всех зол. (c) кто-то из великих.

ПК CLI - для юникс-юзера и скриптов (по быстрому на коленке).

ПК На пример, для сбора счётчиков правил iptables можно использовать
ПК обёртку вокруг iptables -nvL | iptables-save типа:

ПК iptables-save | grep условие | cut -d -fI

ПК или такую конструкцию на Си:

ПК ...
ПК struct ipt_entry *ipt_e;
ПК char *target;

ПК for(ipt_e=iptc_first_rule(chain_name, ipt_h); ipt_e;
ПК ipt_e=iptc_next_rule(ipt_e, ipt_h)) {

ПКif(!ipt_e) {
ПКprintf(iptc_first_rule(): returned NULL pointer\n);
ПКreturn(NULL);
ПК}

ПКif(!условие) continue;

ПКtarget=iptc_get_target(ipt_e, ipt_h);

ПКprintf(Source IP: %s/%s (iface: %s), Destination IP: %s/%s
(iface: %
ПК s), Target: %s, Counters: %llu bytes, %llu packets\n,
ПК x_strcpy(inet_ntoa(ipt_e-ip.src)),
ПК x_strcpy(inet_ntoa(ipt_e-ip.smsk)),
ПК ipt_e-ip.iniface,
ПК x_strcpy(inet_ntoa(ipt_e-ip.dst)),
ПК x_strcpy(inet_ntoa(ipt_e-ip.dmsk)),
ПК ipt_e-ip.outiface,
ПК target,
ПК ipt_e-counters.bcnt,
ПК ipt_e-counters.pcnt
ПК );

ПК }
ПК ...

ПК Первый вариант делается за 5 минут, подойдёт для не частого сбора
ПК небольшого числа счётчиков.

ПК Второй вариант страшный, пока первый раз не сделаешь. Подойдёт для
ПК частого сбора сотен показаний.

Я бы уже задумался о том, что узкое место такой системы - не в сборе
показаний...

ПК Да, но это тоже, что и бегать в чугунных сапогах.

Результаты профайлинга предъяви, да?

Есть конкретный пример? С профайлингом на Ваш любимый скриптовый
язык...
Вы бы ESR-а всё-таки почитали, а то Артёму тут уже приходится
некоторые места своими словами пересказывать и те же цитаты приводить,
которые там уже приведены.

--
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Функционал и интерфейс