date:20120704

On Tue, Jul 03, 2012 at 07:06:20PM +0400, sergio wrote:
 Есть да, у меня свой используется, причём достаточно люто с
 input = nodefault-bindings=true
 в конфиге,
 так что на на все незнакомые кнопки на консоль идёт ругань. А с этих
 тишина.

Какие-нибудь глобальные управлялки громкостью их могли заграбить
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Shell

2012-07-04 Пенетрантность Andrey Tataranovich

Ivan Shmakov - debian-russian@lists.debian.org  @ Wed, 04 Jul 2012 11:13:46 
+0700:

 IS• ${varn#PATTERN} (${varn##PATTERN}) — значение переменной varn,
 IS   за исключением наименьшей (наибольшей) /ведущей/ подстроки,
 IS   удовлетворяющей шаблону PATTERN; в частности, d=${f##*/}
 IS   равносильно d=$(dirname $f);

basename


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq8bzr02@wizzle.ran.pp.ru

Re: Несколько вопросов вразброс

09:44 Mon 02 Jul, Artem Chuprina wrote:
 Если, кстати, кто не в курсе, то рассказываю, что базу данных в любом
 случае нельзя бэкапить как те самые 3 файла.  Ну то есть нет, можно -
 если предварительно остановить сервер.  Если делать это из-под
 работающего сервера, ты гарантированно получишь битую базу в бэкапе,
 несмотря на идеально сходящуюся чексумму.  Те, кто минимально в курсе
 того, как это устроено, бэкапят исключительно результат mysqldump.

Бэкапить большую базу через mysqldump - редкостный мазохизм. Если база
на LVM, то mylvmbackup вполне хватает, чтобы бэкапить и восстанавливать
базу быстро.

-- 
WBR, Andrey Tataranovich


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120704121924.ga16...@debbox.it

Re: про ifconfig и ax.25

2012-07-04 Пенетрантность sergio


Это поведение появляется в 3.4, в 3.3 всё ok.

--
sergio.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff435b4.6030...@sergio.spb.ru

Re: про ifconfig и ax.25

2012-07-04 Пенетрантность Kirill Shilov

у меня 3.4 zen kernel. с ванильным к сожалению нет возможности проверить.
попробуй добавить в blacklist -
rose, ax25 и  netrom

2012/7/4 sergio mail...@sergio.spb.ru:
 Это поведение появляется в 3.4, в 3.3 всё ok.


 --
 sergio.


 --
 To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: http://lists.debian.org/4ff435b4.6030...@sergio.spb.ru

Re: Несколько вопросов вразброс

2012-07-04 Пенетрантность Andrey Tataranovich

Andrey Tataranovich - debian-russian@lists.debian.org  @ Wed, 4 Jul 2012 
15:19:24 +0300:

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

 AT Бэкапить большую базу через mysqldump - редкостный мазохизм. Если база
 AT на LVM, то mylvmbackup вполне хватает, чтобы бэкапить и восстанавливать
 AT базу быстро.

flush-stop-snapshot?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipe3zmlp@wizzle.ran.pp.ru

Re: Несколько вопросов вразброс

17:23 Wed 04 Jul, Artem Chuprina wrote:
Andrey Tataranovich - debian-russian@lists.debian.org @ Wed, 4 Jul 2012
15:19:24 +0300:

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

AT Бэкапить большую базу через mysqldump - редкостный мазохизм. Если база
AT на LVM, то mylvmbackup вполне хватает, чтобы бэкапить и восстанавливать
AT базу быстро.

flush-stop-snapshot?

Не совсем:

(mysql) flush tables with read lock
(shell) lvcreate --snapshot
(mysql) unlock tables
... backup ...
(shell) lvremove

--
WBR, Andrey Tataranovich

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120704135015.gb16...@debbox.it

Re: Несколько вопросов вразброс

2012-07-04 Пенетрантность Eugene Berdnikov

On Wed, Jul 04, 2012 at 04:50:15PM +0300, Andrey Tataranovich wrote:
 (mysql) flush tables with read lock
 (shell) lvcreate --snapshot
 (mysql) unlock tables
 ... backup ...
 (shell) lvremove

 Ничего не зная про mysql, :-) берусь утверждать, что если есть активные
 (незакрытые) транзакции, то это либо невозможно, либо некорректно.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120704141844.gm3...@sie.protva.ru

Re: Несколько вопросов вразброс

2012-07-04 Пенетрантность Andrey Rahmatullin

Артём Н. - debian-russian@lists.debian.org @ Tue, 03 Jul 2012 19:25:28 +0400:

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

На практике же основная проблема тестов заключается в том, что они сами
содержат ошибки и часто тестируют не то, что надо, а сколь-нибудь
серьезно покрывающий код набор тестов занимает в разы больше места, чем
сам код, содержит квадратичное по отношению к коду количество ошибок, и
выполняется до следующего Большого Взрыва, если предположить циклическую
модель развития Вселенной :-) Я почти серьезно, я такие наборы тестов
действительно писал. И тот факт, что они ловили не все ошибки, мне тоже
известен на практике.

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

Любой статически типизированный функциональный язык с нормальной
системой типов, начиная с того же Haskell или Ocaml.
АН Ocaml? Любопытно. Пожалуй, посмотрю подробнее.
АН Для него есть какая-то IDE? И как с библиотеками?
Я знаю одну IDE на все случаи жизни. Emacs.
АН И для всяких там GUI? ;-) В общем, я им не пользуюсь.
Ну да. Поскольку мои дизайнерские способности ниже средних, в отличие
от способностей в разработке поведения, я предпочитаю GUI, которые
пишут, а не рисуют. Внешний вид - дефолтный, а поведение описывается
словами.
АН Дык, внешний вид - это не картинка кнопки, а компоновка. Всё же
АН словами не опишешь. Видеть надо.
Компоновка как раз очень неплохо описывается словами. Заодно потом не
возникает типичных для мышконавозенного гуя ситуаций, когда при переводе
на русский половина надписей получается обрезанной, и в лучшем случае -
поперек, а то я у фотошопа видал, что видно нижнюю половину одной строки
и верхнюю - другой...
АН Я понимаю, что практически любой интерфейс описывается словами. :-)
АН Такой же язык. Но создавать его, описывая словами, мне кажется не
АН самой лучшей и перспективной идеей.

А зря. Если описывать его поведение словами, предварительно подуманными
головой, а визуал оставить на простенькую автоматику, то... выглядеть он
будет не шедеврально. Зато им будет удобно пользоваться. А от
интерфейса, о чем современные мышевозильцы под давлением маркетологов
обычно забывают, требуется именно удобно себя вести, а не красиво
выглядеть. Иначе непонятно, зачем он вообще нужен - если ты хочешь
красивого, выведи себе xsetroot'ом на весь экран картину Рериха, и сиди,
наслаждайся...

JAPH - это не для того, чтобы писать работающую программу :)
АН Однако, они показывают вариации синтаксиса: такой разный стиль...
Это не столько вариации синтаксиса, сколько вариации его художественного
использования. На C, кстати, я тоже такие примеры видел - скажем,
круглую программу, вычисляющую пи.
АН На C всё достаточно жёстко, если не извращаться с макросами, ассемблерными
АН вставками (вдобавок блобами) и указателями на указатели на указатели.
АН Т.е., если делать так, как предполагает язык, там такого сделать нельзя.
АН Максимум - это малопонятный из-за названий переменных однострочник (да,
или кружок).
АН Но это совершенно другое.
АН В C нет eval. :-)
АН Если подумать, конечно, есть сходства...
АН Но, что ещё важно: C, может, и не особенно хороший язык (в плане
понятности,
АН читаемости и надёжности созданного ПО), но там нет столько всего лишнего. И
АН такой кучи синтаксического сахара (без расширений, там массивы - максимум
:-D ),
АН как в Perl. Плюс, строгая модель: любой вызов - функция.
АН C прост и элегантен. :-)

Прост и элегантен, если мы говорим о языках уровня C, Pascal. Если
говорим о скриптовых - tcl. А C - это язык, сделанный практиками для
себя, и простота и элегантность его, как и у Perl, весьма умеренны.
Элегантность в жертву практичности и те, и другие приносили без
содрогания.

Вот C++ получился еще и непрактичным.

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 06:18:44PM +0400, Eugene Berdnikov wrote:
 On Wed, Jul 04, 2012 at 04:50:15PM +0300, Andrey Tataranovich wrote:
  (mysql) flush tables with read lock
  (shell) lvcreate --snapshot
  (mysql) unlock tables
  ... backup ...
  (shell) lvremove
 
  Ничего не зная про mysql, :-) берусь утверждать, что если есть активные
  (незакрытые) транзакции, то это либо невозможно, либо некорректно.
The implementation does this:
1. set the global read lock - after this step, 
insert/update/delete/replace/alter statements cannot run
2. close open tables - this step will block until all statements started 
previously have stopped
3. set a flag to block commits

If long-running statements were started prior to step 2, then the FLUSH
TABLES WITH READ LOCK command will block until they complete.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Tue, 03 Jul 2012 19:36:08 +0400:

То, что в нем объектов нет, это хорошо.
АН Это вопрос для чего.
Практически для всего. Я тоже в свое время радостно ломанулся в
ОО-программирование. Потом поумнел.
АН Но это не значит, что ООП не имеет права на жизнь.
АН Идея была такой просто и хорошей... :-(

Любая задача имеет короткое, изящное и очевидное _неправильное_ решение.

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

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

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

Re: Несколько вопросов вразброс

04.07.2012 07:37, Sergey Korobitsin пишет:
Вы бы лучше, вместо этого, почитали саму Camel Book. Она интересная,
стоит того, даже если на Perl-е вы программировать и не будете.
Что она мне даст? И будет ли это стоить потраченного времени?
Например, я хочу почитать Дейта и начал Танненбаума. Я знаю, что даже если я не
буду заниматься тем, что там описано (а в ближайшее время, кажется, не
предвидится другого), книги стоят времени. А Camel Book?

Та часть, которая делает Perl языком Perl, умышленно построена на смеси
разных
парадигм, учитывающей каждую из них. Можно сказать, что Perl не собирается
навязывать вам никаких догм.
Лари Уолл.
Это и есть главная особенность Perl. Я могу писать, как мне
вздумается.
Угу. Особенность. И одновременно главный недостаток, и причина сложности.
Хм... C++?

Это исключения (Exceptions) так ложатся на Perl, если вы не в курсе. Да
- и для страждущих объектные исключения тоже есть.
Думаю, легче перечислить то, чего там нет. Не интересовался, но не удивлюсь,
если там есть свой GUI и, вместе с ним, биндинги ко известным GUI библиотекам.

Для задач, которые можно решать на sh, этого достаточно. Ну, может, еще
IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток, и на
выходе его забирать, да еще (в случае Open3) stderr анализировать.
Не знаю, может Perl и хорош. Но Camel Book, о котором тут писали на 1000 с
копейками страниц? И тогда уж сравните с книгой KR...

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Tue, 03 Jul 2012 18:41:49 +0400:

АН Да, кстати, Пролог я не понимаю. :-(

[...]

АН И на практике: будь всё так хорошо, как вы пишите, все бы уже давно
АН писали на Прологе (по крайней мере, знали бы что это такое). :-)

Ну ведь ты же сам написал, что ты его не понимаешь. Думаешь, ты один
его не понимаешь?

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

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

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

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

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 18:50:19 +0400:

Та часть, которая делает Perl языком Perl, умышленно построена на
смеси разных парадигм, учитывающей каждую из них. Можно сказать,
что Perl не собирается навязывать вам никаких догм. Лари Уолл.
Это и есть главная особенность Perl. Я могу писать, как мне
вздумается.
АН Угу. Особенность. И одновременно главный недостаток, и причина сложности.
АН Хм... C++?

На C++ ты не можешь писать, как _тебе_ вздумается. Только как
вздумается Страуструпу.

Нифига ты не понимаешь :-)

Это исключения (Exceptions) так ложатся на Perl, если вы не в курсе. Да
- и для страждущих объектные исключения тоже есть.
АН Думаю, легче перечислить то, чего там нет. Не интересовался, но не
АН удивлюсь, если там есть свой GUI и, вместе с ним, биндинги ко
АН известным GUI библиотекам.

Разумеется, как же иначе?

Да, ты до сих пор можешь писать на C, и даже, если хорошо попросить gcc,
на KR C. Но с тех пор появилась возможность тратить свое рабочее время
более эффективно.

Re: Несколько вопросов вразброс

04.07.2012 18:33, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Tue, 03 Jul 2012 19:25:28
+0400:

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

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

содержит квадратичное по отношению к коду количество ошибок, и
выполняется до следующего Большого Взрыва, если предположить циклическую
модель развития Вселенной :-) Я почти серьезно, я такие наборы тестов
действительно писал. И тот факт, что они ловили не все ошибки, мне тоже
известен на практике.
Это я тоже успел заметить. Плюс, сложность возрастает, как разработки, так и
самого кода (тесты, всё-таки, её вносят).

Любой статически типизированный функциональный язык с
нормальной
системой типов, начиная с того же Haskell или Ocaml.
АН Ocaml? Любопытно. Пожалуй, посмотрю подробнее.
АН Для него есть какая-то IDE? И как с библиотеками?
Я знаю одну IDE на все случаи жизни. Emacs.
АН И для всяких там GUI? ;-) В общем, я им не пользуюсь.
Ну да. Поскольку мои дизайнерские способности ниже средних, в отличие
от способностей в разработке поведения, я предпочитаю GUI, которые
пишут, а не рисуют. Внешний вид - дефолтный, а поведение описывается
словами.
АН Дык, внешний вид - это не картинка кнопки, а компоновка. Всё же
АН словами не опишешь. Видеть надо.
Компоновка как раз очень неплохо описывается словами. Заодно потом не
возникает типичных для мышконавозенного гуя ситуаций, когда при переводе
на русский половина надписей получается обрезанной, и в лучшем случае -
поперек, а то я у фотошопа видал, что видно нижнюю половину одной строки
и верхнюю - другой...
АН Я понимаю, что практически любой интерфейс описывается словами. :-)
АН Такой же язык. Но создавать его, описывая словами, мне кажется не
АН самой лучшей и перспективной идеей.

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

Зато им будет удобно пользоваться. А от
интерфейса, о чем современные мышевозильцы под давлением маркетологов
обычно забывают, требуется именно удобно себя вести, а не красиво
выглядеть. Иначе непонятно, зачем он вообще нужен - если ты хочешь
красивого, выведи себе xsetroot'ом на весь экран картину Рериха, и сиди,
наслаждайся...
Построение интерфейса не сводится к его описанию.
То, как он выглядит, нельзя отделять от того, как он себя ведёт.
Красота должна тоже быть. Должен быть баланс.
Думать при построении интерфейса, естественно, надо. Но в данном случае, гораздо
проще и эффективнее видеть, что делаешь, и как это будет выглядеть. Если хотите,
считайте это быстрым прототипированием или прототипированием на лету.
А построение хорошего интерфейса - это сложная инженерная задача. К маркетингу
она имеет не очень большое отношение.
Причём, она не сводится только к минимизации движений пользователей (вы про
unix-style интерфейсы?). :-)
Минимизацией движений работника начали заниматься ещё в XIX веке (только не
помню кто). Это важно, но далеко не всё.
Лучше, вообще, дизайнер пусть занимается. :-)

АН C прост и элегантен. :-)
Прост и элегантен, если мы говорим о языках уровня C, Pascal. Если
говорим о скриптовых - tcl. А C - это

Re: Несколько вопросов вразброс

04.07.2012 00:17, Alexander Galanin пишет:
On Tue, 03 Jul 2012 19:36:08 +0400
Артём Н. artio...@yandex.ru wrote:

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

Исторические причины?

Tcl в своё время сильно раскритиковал один любитель текстовых редакторов
на лиспе: http://www.vanderburg.org/OldPages/Tcl/war/
Не буду это читать...
'Tcl was not designed to be a serious programming language. It was
designed to be a scripting language, on the assumption that a
scripting language need not try to be a real programming language.'

Но, думаю, ему поверили. :-D

Re: Несколько вопросов вразброс

04.07.2012 19:20, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 18:50:19
+0400:

Та часть, которая делает Perl языком Perl, умышленно построена на
смеси разных парадигм, учитывающей каждую из них. Можно сказать,
что Perl не собирается навязывать вам никаких догм. Лари Уолл.
Это и есть главная особенность Perl. Я могу писать, как мне
вздумается.
АН Угу. Особенность. И одновременно главный недостаток, и причина сложности.
АН Хм... C++?
На C++ ты не можешь писать, как _тебе_ вздумается. Только как
вздумается Страуструпу.
Ну, при желании...

Для задач, которые можно решать на sh, этого достаточно. Ну, может, еще
IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток, и на
выходе его забирать, да еще (в случае Open3) stderr анализировать.
Не знаю, может Perl и хорош. Но Camel Book, о котором тут писали на 1000
с
копейками страниц? И тогда уж сравните с книгой KR...

Так с момента выхода содержание KR не особо менялось, а теперь сравните
годы выпуска Camel Book и KR и вспомните, сколько всяких разных
mainstream- и не очень технологий и концепций появилось.
АН Ага. И, тем не менее, книга KR по сей день актуальна. Ну,
АН естественно, кое-что устаревает (в т.ч. немного поменялся
АН синтаксис), но в общем
Да, ты до сих пор можешь писать на C, и даже, если хорошо попросить gcc,
на KR C. Но с тех пор появилась возможность тратить свое рабочее время
более эффективно.
Опять вы о своём. Не понимаете основного: я не хочу сказать, что нужно
вернуться к C (от которого в некоторых задачах и не уходили).
Просто размер основного руководства по языку говорит о многом. И то, что оно не
меняется (не из-за смерти автора), а язык живее всех живых.
А так... Ещё есть описание libc и компилятора (с его расширениями). Вместе с KR
вполне на Camel Book потянет.

И совсем не собираюсь писать на C. Если бы это было так, то про OCaml, Haskell и
Ada я бы у вас не спрашивал.

Re: Несколько вопросов вразброс

04.07.2012 18:41, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Tue, 03 Jul 2012 19:36:08
+0400:

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

А исключения и работа с файлами
там есть. Просто она не относится к синтаксису - это вам не PHP :-)
АН Хм...
Чего хм? error/catch/return/bgerror и
open/socket/close/read/puts/seek/fconfigure/fileevent. На последнее
особенно обрати внимание - я не знаю больше ни одного языка со столь
удобным обращением с асинхронными IO-событиями.
АН Почему тогда на нём не пишут?
АН Исторические причины?
Интеллектуально-образовательный ценз :-) Чтобы воспользоваться тем же
fileevent, нужно владеть парадигмой событийно-ориентированного
программирования. Не вычитать в экзамплах пару шаблонов для виджетов,
чего худо-бедно хватает для написания стандартно-корявого гуя, а
парадигмой владеть.
В плане? Так сейчас ООП и ГУЙ предполагают и асинхронность, и событийную модель.
В чём сложности?

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 07:02:41PM +0400, Artem Chuprina wrote:
 Кстати, в процессе у меня сформулировался ответ про ОО.  ОО-парадигма
 (не обязательно, кстати, выраженная на ОО-языке) - единственная пока,
 похоже, парадигма, позволяющая решать задачи, _постановка_ которых
 _начинает появляться_ ближе к завершению стадии альфа-тестирования.
 Собственно, метод решения - ты выделяешь в предметной области сущности,
 заводишь по типу на каждую, и добавляешь поведение по мере прояснения
 задачи.

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

В такой интерпретации ясно, что если в неком языке императивный
вычислитель явно не просматривается, то и от ОО-модели этот язык не
особо выиграет.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120704163637.GA12106@kaiba.homelan

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 08:19:37PM +0400, Артём Н. wrote:
 вернуться к C (от которого в некоторых задачах и не уходили).
 Просто размер основного руководства по языку говорит о многом. И то, что оно 
 не
 меняется (не из-за смерти автора), а язык живее всех живых.
 А так... Ещё есть описание libc и компилятора (с его расширениями). Вместе с 
 KR
 вполне на Camel Book потянет.
 
 И совсем не собираюсь писать на C. Если бы это было так, то про OCaml, 
 Haskell и
 Ada я бы у вас не спрашивал.

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

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120704164818.GA14505@kaiba.homelan

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 08:34:17PM +0400, Артём Н. wrote:
  ООП имеет право на жизнь, и есть задачи, которые на нем решаются хорошо.
  Но этих задач существенно меньше, чем мест, куда его суют не по делу.
 Да, согласен.
 Однако, в идеале, неплохо бы иметь одну общую всеобъемлющую концепцию :-)
 ООП претендует (с переменным успехом) на роль таковой.

Хм. Этому теперь учат в средней школе на уроках информатики?

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120704165619.GA15001@kaiba.homelan

Re: Несколько вопросов вразброс

04.07.2012 20:56, Stanislav Maslovski пишет:
 On Wed, Jul 04, 2012 at 08:34:17PM +0400, Артём Н. wrote:
 ООП имеет право на жизнь, и есть задачи, которые на нем решаются хорошо.
 Но этих задач существенно меньше, чем мест, куда его суют не по делу.
 Да, согласен.
 Однако, в идеале, неплохо бы иметь одну общую всеобъемлющую концепцию :-)
 ООП претендует (с переменным успехом) на роль таковой.
 
 Хм. Этому теперь учат в средней школе на уроках информатики?
Понятия не имею. Я много прогуливал школу.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff4834d.1000...@yandex.ru

Re: Несколько вопросов вразброс

04.07.2012 19:02, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Tue, 03 Jul 2012 18:41:49
+0400:

АН Да, кстати, Пролог я не понимаю. :-(

[...]

АН И на практике: будь всё так хорошо, как вы пишите, все бы уже давно
АН писали на Прологе (по крайней мере, знали бы что это такое). :-)
Ну ведь ты же сам написал, что ты его не понимаешь. Думаешь, ты один
его не понимаешь?
Если был он был такой хороший, его бы понимали. Потому что, за это бы платили.
:-) И этому учили. C ничуть не проще, чем Пролог. Он просто имеет другую
парадигму. Развёрнутую на 180. У машины вывода есть свои недостатки,
ограничения и своя область применения. По какой-то совокупности причин, Пролог
не нашёл широкого применения (хотя к нему интерес то падал, то возобновлялся).

Правильность программы относительно заданных условий будет определяться
правильностью задания нелогических аксиом.
В смысле - нелогических? o.O

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

Так?

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

Если задача поставлена лучше, то обычно и парадигму можно найти получше.
Хм... Может. Но не только для этого случая применимо же..?
Т.е., вы хотите сказать, что ООП - это для снизу-вверх?
А для наоборот и сама по себе, разве концепция плоха? :-)

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 20:34:17 +0400:

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

Машина Тьюринга заняла эту нишу много лет назад, и даже
лямбда-исчислению ее не отдала. И ООП не отдаст.

А на практике наличие _одной_ всеобъемлющей концепции - это большой
минус. Что и наблюдается как с реляционной моделью в базах данных, так
и с ООП в архитектуре программ.

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

Помнится, код, переписанный с C++ на C со старательным выкидыванием всей
объектности, кроме нужной, стал на порядок компактнее, вдвое понятнее, и
давал в разы меньший результат при компиляции.
Tcl - он же функциональный по сути, зачем ему объекты?
АН Хм... Честно не знаю. Объекты, в принципе, не лишние. Но как
совмещается
АН объектный и функциональный подход..? Хотя, библиотеки-то есть...
Никогда не надо пользоваться тем, что в принципе не лишнее.
Пользоваться надо только тем, что тебе действительно нужно, и понимая,
почему именно оно, а не альтернативы.
АН Да, бритву Оккама не отменяли. :-) Но, во-первых, не всегда
АН возможно выбрать лучшую из альтернатив, потому что обе они имеют
АН взаимокомпенсирующие достоинства и недостатки, так что, ни одна из
АН них не является лучшей. Во-вторых, иногда просто недостаточно
АН информации для выбора.

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

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

Можешь. Но придется таки залезть в сишный код, если я правильно помню
ситуацию.

А исключения и работа с файлами
там есть. Просто она не относится к синтаксису - это вам не PHP :-)
АН Хм...
Чего хм? error/catch/return/bgerror и
open/socket/close/read/puts/seek/fconfigure/fileevent. На последнее
особенно обрати внимание - я не знаю больше ни одного языка со столь
удобным обращением с асинхронными IO-событиями.
АН Почему тогда на нём не пишут?
АН Исторические причины?
Интеллектуально-образовательный ценз :-) Чтобы воспользоваться тем же
fileevent, нужно владеть парадигмой событийно-ориентированного
программирования. Не вычитать в экзамплах пару шаблонов для виджетов,
чего худо-бедно хватает для написания стандартно-корявого гуя, а
парадигмой владеть.
АН В плане? Так сейчас ООП и ГУЙ предполагают и асинхронность, и
АН событийную модель. В чём сложности?

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

Я это наблюдал, грубо говоря, в виде, когда человек не может, формируя
интерфейс типа wizard, адекватно обработать какую-либо кнопку, кроме
Далее.

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

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 20:19:37 +0400:

Та часть, которая делает Perl языком Perl, умышленно построена на
смеси разных парадигм, учитывающей каждую из них. Можно сказать,
что Perl не собирается навязывать вам никаких догм. Лари Уолл.
Это и есть главная особенность Perl. Я могу писать, как мне
вздумается.
АН Угу. Особенность. И одновременно главный недостаток, и причина
сложности.
АН Хм... C++?
На C++ ты не можешь писать, как _тебе_ вздумается. Только как
вздумается Страуструпу.
АН Ну, при желании...

Ну, попробуй...

Если бы понимал, ты бы не высказывал неверных утверждений.

Для задач, которые можно решать на sh, этого достаточно. Ну, может,
еще
IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток, и на
выходе его забирать, да еще (в случае Open3) stderr анализировать.
Не знаю, может Perl и хорош. Но Camel Book, о котором тут писали на
1000 с
копейками страниц? И тогда уж сравните с книгой KR...

Так с момента выхода содержание KR не особо менялось, а теперь сравните
годы выпуска Camel Book и KR и вспомните, сколько всяких разных
mainstream- и не очень технологий и концепций появилось.
АН Ага. И, тем не менее, книга KR по сей день актуальна. Ну,
АН естественно, кое-что устаревает (в т.ч. немного поменялся
АН синтаксис), но в общем
Да, ты до сих пор можешь писать на C, и даже, если хорошо попросить gcc,
на KR C. Но с тех пор появилась возможность тратить свое рабочее время
более эффективно.
АН Опять вы о своём. Не понимаете основного: я не хочу сказать, что нужно
АН вернуться к C (от которого в некоторых задачах и не уходили).
АН Просто размер основного руководства по языку говорит о многом.

Может быть. Но явно не о том, о чем ты подумал.

Re: Несколько вопросов вразброс

04.07.2012 20:36, Stanislav Maslovski пишет:
 Я бы ещё добавил, что ОО-парадигма рождается из желания перейти от
 классической модели императивного вычислителя, как единого конечного
 автомата, к модели многих изолированных конечных автоматов, взаимодействующих
 через чётко ограниченные интерфейсы. Точно так же в электронике от паука
 на рассыпухе, пришли сначала к модульным схемам, а потом к ИС.
Ну и? Это естественный, эволюционный процесс. Разве должно быть иначе?

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff48861.3050...@yandex.ru

Re: Несколько вопросов вразброс

On Wed, 04 Jul 2012 20:34:17 +0400
Артём Н. artio...@yandex.ru wrote:

Смотря как ты собираешься её «брать и делать». Если надо собрать
несколько виджетов в кучку, то с помощью объектного расширения
snit::widget (которое, к слову, не вполне привычно, так как там не
наследование, а агрегация) можно это легко и красиво вделать. А вот
привычного по VCL/Windows::Forms/Swing пути «унаследовать класс и там
переопределить функцию OnDraw()» почти нет.

Чего хм? error/catch/return/bgerror и
open/socket/close/read/puts/seek/fconfigure/fileevent. На последнее
особенно обрати внимание - я не знаю больше ни одного языка со столь
удобным обращением с асинхронными IO-событиями.
АН Почему тогда на нём не пишут?
АН Исторические причины?
Интеллектуально-образовательный ценз :-) Чтобы воспользоваться тем же
fileevent, нужно владеть парадигмой событийно-ориентированного
программирования. Не вычитать в экзамплах пару шаблонов для виджетов,
чего худо-бедно хватает для написания стандартно-корявого гуя, а
парадигмой владеть.
В плане? Так сейчас ООП и ГУЙ предполагают и асинхронность, и событийную
модель.
В чём сложности?

Сложности в том, что этой асинхронности любители TForm1.Button1Click()
не видят, она от них скрыта под толстым слоем объектов и абстракций. В
итоге там, где хватит fileevent, лепят 10 тредов и путаются потом в
синхронизации.

--
Alexander Galanin

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120704221749.5ebdfa4299c35f8054a6c...@galanin.nnov.ru

Re: про ifconfig и ax.25

2012-07-04 Пенетрантность sergio



Если кому интересно, то это баг ifconfig'а который вызван тем, что он 
неверно определяет версию ядра из двух разрядов (3.4).


http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680204

--
sergio.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff48917.4030...@sergio.spb.ru

Re: Несколько вопросов вразброс

On Wed, 04 Jul 2012 20:13:48 +0400
Артём Н. artio...@yandex.ru wrote:

04.07.2012 00:17, Alexander Galanin пишет:
On Tue, 03 Jul 2012 19:36:08 +0400
Артём Н. artio...@yandex.ru wrote:

Это, конечно, не объясняет мотивов всех разработчиков, но некоторые вещи
на Tcl/Tk сделать настолько просто, что это не вызывает интереса. Нет
_вызова_. Например, аналог k3b пишется за пару вечеров (tkdvd,
например), поэтому у написавшего нет чувства победы. В то же время
написать его на C++/Qt сложно, и, сделав это, можно считать себя героем.

--
Alexander Galanin

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120704222324.7b69a079ce71c0f6e8bef...@galanin.nnov.ru

Re: Несколько вопросов вразброс

04.07.2012 22:14, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 20:19:37
+0400:
На C++ ты не можешь писать, как _тебе_ вздумается. Только как
вздумается Страуструпу.
АН Ну, при желании...
Ну, попробуй...
Да ну, как-то не тянет.

Впрочем,
как на шелл - это лучше на шелле же и писать. Ну, с
привлечением sed
и/или awk. perl позволяет писать совершенно третьим способом,
и вот
именно им и надо писать надежные программы на нем.
АН Эээ Каким?
use strict;
eval {...}; (не путать с eval ...)
Гы-гы... Это мне о многом говорит. :-D Нет, правда. :-D
Не вижу ничего смешного, даже краткого знакомства с Perl достаточно,
чтобы понять различие поведения для строки () и блока кода ({}).
АН Я понимаю различие. {} - выполним, строка - нет. Мне само
АН предложение нравится. :-)
Нифига ты не понимаешь :-)
АН Я-то, как-раз понимаю. :-D
Если бы понимал, ты бы не высказывал неверных утверждений.
Посмотрел для чего используют eval {}.
Т.е., чтобы отловить синтаксические ошибки на этапе компиляции (в случае с
eval - выражение просто строка, поэтому и ошибки не отлавливаются), но не
допустить выброса исключений (поскольку выражение в {} выполняется ей, как
автономная программа)?
Но всё-равно, выглядит диковато...

Для задач, которые можно решать на sh, этого достаточно. Ну,
может, еще
IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток, и на
выходе его забирать, да еще (в случае Open3) stderr анализировать.
Не знаю, может Perl и хорош. Но Camel Book, о котором тут писали на
1000 с
копейками страниц? И тогда уж сравните с книгой KR...

Так с момента выхода содержание KR не особо менялось, а теперь
сравните
годы выпуска Camel Book и KR и вспомните, сколько всяких разных
mainstream- и не очень технологий и концепций появилось.
АН Ага. И, тем не менее, книга KR по сей день актуальна. Ну,
АН естественно, кое-что устаревает (в т.ч. немного поменялся
АН синтаксис), но в общем
Да, ты до сих пор можешь писать на C, и даже, если хорошо попросить gcc,
на KR C. Но с тех пор появилась возможность тратить свое рабочее время
более эффективно.
АН Опять вы о своём. Не понимаете основного: я не хочу сказать, что нужно
АН вернуться к C (от которого в некоторых задачах и не уходили).
АН Просто размер основного руководства по языку говорит о многом.
Может быть. Но явно не о том, о чем ты подумал.
И о чём?

Re: Несколько вопросов вразброс

04.07.2012 22:23, Alexander Galanin пишет:
On Wed, 04 Jul 2012 20:13:48 +0400
Артём Н. artio...@yandex.ru wrote:

04.07.2012 00:17, Alexander Galanin пишет:
On Tue, 03 Jul 2012 19:36:08 +0400
Артём Н. artio...@yandex.ru wrote:

Чего хм? error/catch/return/bgerror и
open/socket/close/read/puts/seek/fconfigure/fileevent. На последнее
особенно обрати внимание - я не знаю больше ни одного языка со столь
удобным обращением с асинхронными IO-событиями.
Почему тогда на нём не пишут?
Пишут. Но не стоит связывать удобство программирования и популярность
языка. Можно заметить, что популярными становятся далеко не самые лучшие
инструменты.
Я знаю, потому и спрашиваю. Но иногда связь есть.
Это, конечно, не объясняет мотивов всех разработчиков, но некоторые вещи
на Tcl/Tk сделать настолько просто, что это не вызывает интереса. Нет
_вызова_. Например, аналог k3b пишется за пару вечеров (tkdvd,
например)
Вы серьёзно? o.O

поэтому у написавшего нет чувства победы. В то же время
написать его на C++/Qt сложно, и, сделав это, можно считать себя героем.
An hero? Да ну нафиг. Лучше работу сделать и быть довольным нормальными
радостями.

Re: Несколько вопросов вразброс

On Wed, 04 Jul 2012 22:26:10 +0400
Артём Н. artio...@yandex.ru wrote:

  Это, конечно, не объясняет мотивов всех разработчиков, но некоторые вещи
  на Tcl/Tk сделать настолько просто, что это не вызывает интереса. Нет
  _вызова_. Например, аналог k3b пишется за пару вечеров (tkdvd,
  например)
 Вы серьёзно? o.O

Абсолютно. Там делов-то:
set f [open |cdrecord {*}$cdrecordArgs r+]
fileevent $f readable [list handleLine $f]
…
proc handleLine {f} {
if {[gets $f line] = 0} {
if {[regexp {...(\d+)% written...} $line _ percent]} {
displayPercentOnWidget $percent
}
} else {
if {[eof $f]} {
close $f
displayFinishMessage
}
}
}

  поэтому у написавшего нет чувства победы. В то же время
  написать его на C++/Qt сложно, и, сделав это, можно считать себя героем.
 An hero? Да ну нафиг. Лучше работу сделать и быть довольным
 нормальными радостями.

Тем не менее при живом tkdvd клепают комбайны вроде k3b. С отдельными
радостями по написанию класса, реализующего функциональность fileevent,
который ещё и поломался при переходе с qt3 на qt4 (читал как-то на
опеннете страдания разработчика k3b по этому поводу).

-- 
Alexander Galanin


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120704223305.3055837bc8ac2ade2bb3e...@galanin.nnov.ru

Re: Несколько вопросов вразброс

04.07.2012 22:12, Artem Chuprina пишет:
Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 20:34:17
+0400:

Машина Тьюринга заняла эту нишу много лет назад, и даже
лямбда-исчислению ее не отдала. И ООП не отдаст.
Я про ту концепцию, которую возможно использовать на практике.

А на практике наличие _одной_ всеобъемлющей концепции - это большой
минус. Что и наблюдается как с реляционной моделью в базах данных, так
и с ООП в архитектуре программ.
Ну, по крайней мере, сейчас в большинстве случаев используется реляционная
модель... Хоть какое-то единообразие.

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

Помнится, код, переписанный с C++ на C со старательным выкидыванием
всей
объектности, кроме нужной, стал на порядок компактнее, вдвое
понятнее, и
давал в разы меньший результат при компиляции.
Tcl - он же функциональный по сути, зачем ему объекты?
АН Хм... Честно не знаю. Объекты, в принципе, не лишние. Но как
совмещается
АН объектный и функциональный подход..? Хотя, библиотеки-то есть...
Никогда не надо пользоваться тем, что в принципе не лишнее.
Пользоваться надо только тем, что тебе действительно нужно, и понимая,
почему именно оно, а не альтернативы.
АН Да, бритву Оккама не отменяли. :-) Но, во-первых, не всегда
АН возможно выбрать лучшую из альтернатив, потому что обе они имеют
АН взаимокомпенсирующие достоинства и недостатки, так что, ни одна из
АН них не является лучшей. Во-вторых, иногда просто недостаточно
АН информации для выбора.
Я видел только один вариант недостаточно информации для выбора -
незнание альтернатив.
Нет, почему же?
Незнание всех характеристик альтернатив, незнание того, как поведёт себя данная
альтернатива, незнание того насколько сильнее одна характеристика влияет на
абстрактное качество системы, чем другая. Много что возможно не знать.

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

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

Я даже скажу, где в tcl/Tk мне не хватает свойства, характерного для
объектной модели в хорошем ее исполнении. Но оно есть отнюдь не только
в объектной модели. Мне не хватало возможностей модифицировать Tk'шные
виджеты. Включая возможность строить свой на базе готовых. Оная
возможность, кстати, есть в perl/Tk. Но там как раз объектная модель, и
описание интерфейса в результате стало куда менее читабельным.
АН Т.е., используя Tcl/Tk я не могу, например, взять панельку и
АН построить на её основе свою мегапанельку, которая станет
АН равноправным компонентом? :-)
Можешь. Но придется таки залезть в сишный код, если я правильно помню
ситуацию.
Т.е., средствами языка Tcl я это сделать не могу? :-(

А исключения и работа с файлами
там есть. Просто она не относится к синтаксису - это вам не PHP
:-)
АН Хм...
Чего хм? error/catch/return/bgerror и
open/socket/close/read/puts/seek/fconfigure/fileevent. На последнее
особенно обрати внимание - я не знаю больше ни одного языка со столь
удобным обращением с асинхронными IO-событиями.
АН Почему тогда на нём не пишут?
АН Исторические причины?
Интеллектуально-образовательный ценз :-) Чтобы воспользоваться тем же
fileevent, нужно владеть парадигмой событийно-ориентированного
программирования. Не вычитать в экзамплах пару шаблонов для виджетов,
чего худо-бедно хватает для написания стандартно-корявого гуя, а
парадигмой владеть.
АН В плане? Так сейчас ООП и ГУЙ предполагают и асинхронность, и
АН событийную модель. В чём сложности?
В понимании этих предложений программистами. В результате чего они
используют некие шаблоны, не понимая, что они делают. И соответственно,
как только задача

Re: Несколько вопросов вразброс

2012-07-04 Пенетрантность Павел Марченко

04.07.2012 22:33, Alexander Galanin пишет:
 On Wed, 04 Jul 2012 22:26:10 +0400
 Артём Н. artio...@yandex.ru wrote:
 
 Это, конечно, не объясняет мотивов всех разработчиков, но некоторые вещи
 на Tcl/Tk сделать настолько просто, что это не вызывает интереса. Нет
 _вызова_. Например, аналог k3b пишется за пару вечеров (tkdvd,
 например)
 Вы серьёзно? o.O
 
 Абсолютно. Там делов-то:
 set f [open |cdrecord {*}$cdrecordArgs r+]
 fileevent $f readable [list handleLine $f]
 …
 proc handleLine {f} {
 if {[gets $f line] = 0} {
 if {[regexp {...(\d+)% written...} $line _ percent]} {
 displayPercentOnWidget $percent
 }
 } else {
 if {[eof $f]} {
 close $f
 displayFinishMessage
 }
 }
 }
Не, ну это не то...
Ведь k3b - это не такой и простой интерфейс, а здесь только обёртка над cdrecord
с прогрессом...
Реальный k3b, думаю, за пару вечеров не напишешь.

 поэтому у написавшего нет чувства победы. В то же время
 написать его на C++/Qt сложно, и, сделав это, можно считать себя героем.
 An hero? Да ну нафиг. Лучше работу сделать и быть довольным
 нормальными радостями.
 Тем не менее при живом tkdvd клепают комбайны вроде k3b. С отдельными
 радостями по написанию класса, реализующего функциональность fileevent,
 который ещё и поломался при переходе с qt3 на qt4 (читал как-то на
 опеннете страдания разработчика k3b по этому поводу).
Дык, нет библиотек что-ли, которые реализуют fileevent?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff48fa9.60...@yandex.ru

Re: zabbix внешняя проверка

4 июля 2012 г., 13:22 пользователь Korona Auto Ltd.\ Andrey N.
Prokofiev a...@korona-auto.com написал:
 День добрый. Есть скрипт для внешней проверки. Возвращает 1 или 0.
 Необходимо осуществлять внешнюю проверку каждый день в 8 утра (ни в коем
 случае не чаще). То есть 1 значение в день. Как заббиксу сие указать? Нужно
 использовать переменный интервал?

указать период проверки, по дефолту в айтемах 1-7,00:00-24:00 т.е. 7
дней в неделю 24 часа в сутки, указать что-то вроде 1-7,08:00-08:01
интервал проверки 60 сек



-- 
В смысле осмысления бессмысленного смысл тоже имеет определенную
осмысленность!!!

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 10:33:05PM +0400, Alexander Galanin wrote:
 Абсолютно. Там делов-то:
 set f [open |cdrecord {*}$cdrecordArgs r+]
 fileevent $f readable [list handleLine $f]
 …
 proc handleLine {f} {
 if {[gets $f line] = 0} {
 if {[regexp {...(\d+)% written...} $line _ percent]} {
 displayPercentOnWidget $percent
 }
 } else {
 if {[eof $f]} {
 close $f
 displayFinishMessage
 }
 }
 }

Я тебе такое и на C++/Qt за вечер напишу. Ты лучше расскажи, какой процент
функционала k3b ты этим покрыл... И расскажи, сколько нужно потом юзеру
ругаться матом, чтобы в этом Tk шрифты выглядели нормально...

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

04.07.2012 22:17, Alexander Galanin пишет:
On Wed, 04 Jul 2012 20:34:17 +0400
Артём Н. artio...@yandex.ru wrote:

Я даже скажу, где в tcl/Tk мне не хватает свойства, характерного для
объектной модели в хорошем ее исполнении. Но оно есть отнюдь не только
в объектной модели. Мне не хватало возможностей модифицировать Tk'шные
виджеты. Включая возможность строить свой на базе готовых. Оная
возможность, кстати, есть в perl/Tk. Но там как раз объектная модель, и
описание интерфейса в результате стало куда менее читабельным.
Т.е., используя Tcl/Tk я не могу, например, взять панельку и построить на её
основе свою мегапанельку, которая станет равноправным компонентом? :-)
Смотря как ты собираешься её «брать и делать». Если надо собрать
несколько виджетов в кучку, то с помощью объектного расширения
snit::widget (которое, к слову, не вполне привычно, так как там не
наследование, а агрегация) можно это легко и красиво вделать. А вот
привычного по VCL/Windows::Forms/Swing пути «унаследовать класс и там
переопределить функцию OnDraw()» почти нет.
Мда...

Re: Несколько вопросов вразброс

04.07.2012 22:17, Alexander Galanin пишет:
 Сложности в том, что этой асинхронности любители TForm1.Button1Click()
 не видят, она от них скрыта под толстым слоем объектов и абстракций. В
 итоге там, где хватит fileevent, лепят 10 тредов и путаются потом в
 синхронизации.
А fileevent, в данном случае, - не ожидающий поток?
Я понимаю, что штатный доступ к файлам производится через предоставляемое ОС
API. Но что делать, если ОС такой функциональности не предоставляет?
Остаётся либо перехват функций (малопереносимый и чреватый некоторыми
последствиями) или ожидающий поток.
Какие ещё варианты?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff490ec.7030...@yandex.ru

Re: Несколько вопросов вразброс

On Wed, 04 Jul 2012 22:47:05 +0400
Артём Н. artio...@yandex.ru wrote:

04.07.2012 22:33, Alexander Galanin пишет:
On Wed, 04 Jul 2012 22:26:10 +0400
Артём Н. artio...@yandex.ru wrote:

Абсолютно. Там делов-то:
…
Не, ну это не то...
Ведь k3b - это не такой и простой интерфейс, а здесь только обёртка над
cdrecord
с прогрессом...

Второй вечер посвящается описанию формочек и заполнению cdrecordArgs
согласно им. Но полировать потом можно до бесконечности.

Реальный k3b, думаю, за пару вечеров не напишешь.

А я написал, что «аналог», а не копия. Для меня так вообще k3b
перегружен, а достаточно было б интерфейса типа Nero Express (wizard из
трёх окошек).

Тем не менее при живом tkdvd клепают комбайны вроде k3b. С отдельными
радостями по написанию класса, реализующего функциональность fileevent,
который ещё и поломался при переходе с qt3 на qt4 (читал как-то на
опеннете страдания разработчика k3b по этому поводу).
Дык, нет библиотек что-ли, которые реализуют fileevent?

Автору k3b виднее, что их нет, раз пришлось писать свою.

--
Alexander Galanin

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120704225402.40c7707c3d7a0c40d7143...@galanin.nnov.ru

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 10:52:28PM +0400, Артём Н. wrote:
 04.07.2012 22:17, Alexander Galanin пишет:
  Сложности в том, что этой асинхронности любители TForm1.Button1Click()
  не видят, она от них скрыта под толстым слоем объектов и абстракций. В
  итоге там, где хватит fileevent, лепят 10 тредов и путаются потом в
  синхронизации.
 А fileevent, в данном случае, - не ожидающий поток?
 Я понимаю, что штатный доступ к файлам производится через предоставляемое ОС
 API. Но что делать, если ОС такой функциональности не предоставляет?

Это какая? 
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

04.07.2012 22:54, Alexander Galanin пишет:
On Wed, 04 Jul 2012 22:47:05 +0400
Артём Н. artio...@yandex.ru wrote:

04.07.2012 22:33, Alexander Galanin пишет:
On Wed, 04 Jul 2012 22:26:10 +0400
Артём Н. artio...@yandex.ru wrote:

Реальный k3b, думаю, за пару вечеров не напишешь.

А я написал, что «аналог», а не копия. Для меня так вообще k3b
перегружен, а достаточно было б интерфейса типа Nero Express (wizard из
трёх окошек).
Так а причём тут Tcl/Tk? На другом вменяемом языке это не сделать?

Re: Несколько вопросов вразброс

04.07.2012 22:54, Dmitry Nezhevenko пишет:
 On Wed, Jul 04, 2012 at 10:52:28PM +0400, Артём Н. wrote:
 04.07.2012 22:17, Alexander Galanin пишет:
 Сложности в том, что этой асинхронности любители TForm1.Button1Click()
 не видят, она от них скрыта под толстым слоем объектов и абстракций. В
 итоге там, где хватит fileevent, лепят 10 тредов и путаются потом в
 синхронизации.
 А fileevent, в данном случае, - не ожидающий поток?
 Я понимаю, что штатный доступ к файлам производится через предоставляемое ОС
 API. Но что делать, если ОС такой функциональности не предоставляет?
 Это какая? 
Я в общем случае. Возможно найти такую экзотическую или древнюю ОС, но всё-таки
имеющую ФС и многопоточность, которая не предоставляет. Вопрос-то тут, думаю, не
в непонимании концепции, а в незнании API. :-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff4925b.8000...@yandex.ru

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 10:58:35PM +0400, Артём Н. wrote:
  А fileevent, в данном случае, - не ожидающий поток?
  Я понимаю, что штатный доступ к файлам производится через предоставляемое 
  ОС
  API. Но что делать, если ОС такой функциональности не предоставляет?
  Это какая? 
 Я в общем случае. Возможно найти такую экзотическую или древнюю ОС, но 
 всё-таки
 имеющую ФС и многопоточность, которая не предоставляет. Вопрос-то тут, думаю, 
 не
 в непонимании концепции, а в незнании API. :-)

Понятно. Т.е. сферическая ОС в вакууме.
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

04.07.2012 22:59, Dmitry Nezhevenko пишет:
 On Wed, Jul 04, 2012 at 10:58:35PM +0400, Артём Н. wrote:
 А fileevent, в данном случае, - не ожидающий поток?
 Я понимаю, что штатный доступ к файлам производится через предоставляемое 
 ОС
 API. Но что делать, если ОС такой функциональности не предоставляет?
 Это какая? 
 Я в общем случае. Возможно найти такую экзотическую или древнюю ОС, но 
 всё-таки
 имеющую ФС и многопоточность, которая не предоставляет. Вопрос-то тут, 
 думаю, не
 в непонимании концепции, а в незнании API. :-)
 Понятно. Т.е. сферическая ОС в вакууме.
Угу.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff49309.2080...@yandex.ru

Re: Несколько вопросов вразброс

On Wed, 4 Jul 2012 21:48:12 +0300
Dmitry Nezhevenko d...@inhex.net wrote:

On Wed, Jul 04, 2012 at 10:33:05PM +0400, Alexander Galanin wrote:
Абсолютно. Там делов-то:
Я тебе такое и на C++/Qt за вечер напишу. Ты лучше расскажи, какой процент
функционала k3b ты этим покрыл...

Основная необходимая функциональность. Остальное — типичное скучное
гуи-приложение, которое писать не составляет никакого труда и,
следовательно, лень.

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

Аргумент из серии «а у вас зато негров линчуют!», который используется
при исчерпании аргументов по теме. Но напомню, что в свежезамороженном
тестинге веткой Tk по умолчанию является 8.5, в которой любимой для tk
haters пРоБлЕмЫ_сО_ШрИфТаМи нет, а дистрибутивы, в которой её нельзя
было выставить руками, уже не поддерживаются.

--
Alexander Galanin

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120704230244.f205519ce0585a511af89...@galanin.nnov.ru

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 11:02:44PM +0400, Alexander Galanin wrote:
Я тебе такое и на C++/Qt за вечер напишу. Ты лучше расскажи, какой процент
функционала k3b ты этим покрыл...

Основная необходимая функциональность в cdrecord и так есть. В том числе и
прогрессбар.

И как это коррелирует с крутостью Tcl/Tk и/или убогостью C++?

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

В debian stable (поддерживаемый) шрифты говно по умолчанию. Да, это 21
век.

--
WBR, Dmitry

signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

On Wed, 04 Jul 2012 22:56:02 +0400
Артём Н. artio...@yandex.ru wrote:

  Это, конечно, не объясняет мотивов всех разработчиков, но некоторые вещи
  на Tcl/Tk сделать настолько просто, что это не вызывает интереса. Нет
  _вызова_. Например, аналог k3b пишется за пару вечеров (tkdvd,
  например)
 Так а причём тут Tcl/Tk? На другом вменяемом языке это не сделать?

Да хоть в машинных кодах. Я вижу, что мысль потерялась, потому повторю:
на Tcl/Tk такая задача решается просто, даже слишком просто. Что отчасти
объясняет, почему решение не стало столь же популярным, как героически
написанный k3b.

-- 
Alexander Galanin


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120704230842.64d20c31c6c88138c4dbe...@galanin.nnov.ru

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 11:08:42PM +0400, Alexander Galanin wrote:
 Да хоть в машинных кодах. Я вижу, что мысль потерялась, потому повторю:
 на Tcl/Tk такая задача решается просто, даже слишком просто. Что отчасти
 объясняет, почему решение не стало столь же популярным, как героически
 написанный k3b.

Сферическая задача написать GUI-ный прогрессбар к cdrecord решается просто на
любом языке c любым UI тулкитом.

К k3b данная задача не имеет никакого отношения.

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

On Wed, 04 Jul 2012 22:52:28 +0400
Артём Н. artio...@yandex.ru wrote:

04.07.2012 22:17, Alexander Galanin пишет:
Сложности в том, что этой асинхронности любители TForm1.Button1Click()
не видят, она от них скрыта под толстым слоем объектов и абстракций. В
итоге там, где хватит fileevent, лепят 10 тредов и путаются потом в
синхронизации.
А fileevent, в данном случае, - не ожидающий поток?

Нет, это обёртка над select/poll.

Я понимаю, что штатный доступ к файлам производится через предоставляемое ОС
API. Но что делать, если ОС такой функциональности не предоставляет?

Значит не надо использовать ОС, которая не даёт функций для доступа к
файлам и, следовательно, не достойна называться операционной системой.

Остаётся либо перехват функций (малопереносимый и чреватый некоторыми
последствиями) или ожидающий поток.
Какие ещё варианты?

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

--
Alexander Galanin

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120704231306.a6d7c6bb1f708b87d5827...@galanin.nnov.ru

Re: Несколько вопросов вразброс

On Wed, 4 Jul 2012 22:12:07 +0300
Dmitry Nezhevenko d...@inhex.net wrote:

On Wed, Jul 04, 2012 at 11:08:42PM +0400, Alexander Galanin wrote:
Да хоть в машинных кодах. Я вижу, что мысль потерялась, потому повторю:
на Tcl/Tk такая задача решается просто, даже слишком просто. Что отчасти
объясняет, почему решение не стало столь же популярным, как героически
написанный k3b.

Сферическая задача написать GUI-ный прогрессбар к cdrecord решается просто
на
любом языке c любым UI тулкитом.

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

Вот пример решения аналогичной задачи (тоже открывается stdout и
парсится на прогрессбар):
http://galanin.nnov.ru/~al/hg/hgwebdir.cgi/utils/file/tip/ripDVD.tcl
Готов сравнить тупо по количеству строчек с «любым языком с любым
тулкитом». Например, C+GTK.

К k3b данная задача не имеет никакого отношения.

Конечно не имеет. Просто первый пришедший в голову пример.

--
Alexander Galanin

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120704232531.0579a81c4986f209a20bc...@galanin.nnov.ru

Re: Несколько вопросов вразброс

On Wed, 4 Jul 2012 22:05:14 +0300
Dmitry Nezhevenko d...@inhex.net wrote:

On Wed, Jul 04, 2012 at 11:02:44PM +0400, Alexander Galanin wrote:
Я тебе такое и на C++/Qt за вечер напишу. Ты лучше расскажи, какой процент
функционала k3b ты этим покрыл...
Основная необходимая функциональность. Остальное — типичное скучное
гуи-приложение, которое писать не составляет никакого труда и,
следовательно, лень.
Основная необходимая функциональность в cdrecord и так есть. В том числе и
прогрессбар.
И как это коррелирует с крутостью Tcl/Tk и/или убогостью C++?

Я не понимаю, какой тезис этим опровергается.

В debian stable (поддерживаемый) шрифты говно по умолчанию. Да, это 21
век.

Там ещё nano вместо vim, гном вместо icewm и Install-Recommends=true в
/etc/apt.conf. Ты используешь систему как поставилась или же всё-таки
конфигурируешь под себя? «Проблемы» со шрифтами решаются их настройкой
и/или указанием дефолтной версии Tk.

--
Alexander Galanin

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120704234028.aef5d337e4e8f16b71cc6...@galanin.nnov.ru

Re: Несколько вопросов вразброс

On Wed, 4 Jul 2012 23:40:28 +0400
Alexander Galanin a...@galanin.nnov.ru wrote:

  В debian stable (поддерживаемый) шрифты говно по умолчанию. Да, это 21
  век. 
 Там ещё nano вместо vim, гном вместо icewm и Install-Recommends=true в
 /etc/apt.conf. Ты используешь систему как поставилась или же всё-таки
 конфигурируешь под себя? «Проблемы» со шрифтами решаются их настройкой
 и/или указанием дефолтной версии Tk.

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

-- 
Alexander Galanin


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120704235847.c3da201c8bb4e6fa2a72a...@galanin.nnov.ru

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 11:40:28PM +0400, Alexander Galanin wrote:
  Основная необходимая функциональность в cdrecord и так есть. В том числе и
  прогрессбар.
  И как это коррелирует с крутостью Tcl/Tk и/или убогостью C++?
 
 Я не понимаю, какой тезис этим опровергается.

Тезис что сравнением k3b с прогрессбаром к cdrecord на tcl/tk можно
сравнивать C++/Qt с Tcl/Tk

 
  В debian stable (поддерживаемый) шрифты говно по умолчанию. Да, это 21
  век. 
 
 /etc/apt.conf. Ты используешь систему как поставилась или же всё-таки
 конфигурируешь под себя? «Проблемы» со шрифтами решаются их настройкой
 и/или указанием дефолтной версии Tk.

Наличие ручек для настройки не должно отменять разумные дефолты. То
убожество что получается вместо шрифтов после apt-get install tkabber в
дефолтном stable разумным дефолтом назвать сложно.

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 11:58:47PM +0400, Alexander Galanin wrote:
 Собственно, мне и самому не нравится проклятие со шрифтами в 8.4, но
 использовать это как окончательный победоносный аргумент — не лучшая
 идея.

Да, в текущем unstable стало таки лучше.. Даже не верится...
 
-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Несколько вопросов вразброс

2012-07-04 Пенетрантность Иван Лох

On Sun, Jul 01, 2012 at 05:26:15PM +0400, Артём Н. wrote:
 
  -30% производительности -- минимальная цена.
 Про IPC сообщениями? Они пишут, что производительность такая же, как у и 
 прямых
 вызовов.

Это из известной статьи Таненбаума, где он сам признает, что микроядерная 
архитектура
всегда даст среднюю потерю производительности около 30% на intel-совместимых 
процессорах.
Он, конечно, уверяет, что это не важно.

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120704202945.gb29...@nano.ioffe.rssi.ru

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 22:42:17 +0400:

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

Машина Тьюринга заняла эту нишу много лет назад, и даже
лямбда-исчислению ее не отдала. И ООП не отдаст.
АН Я про ту концепцию, которую возможно использовать на практике.

Теорема Геделя нам как бы намекает, что такой концепции не существует.

А на практике наличие _одной_ всеобъемлющей концепции - это большой
минус. Что и наблюдается как с реляционной моделью в базах данных, так
и с ООП в архитектуре программ.
АН Ну, по крайней мере, сейчас в большинстве случаев используется реляционная
АН модель... Хоть какое-то единообразие.

Хуже того, в большинстве случаев сейчас уже используется XML-обертка над
ORM над реляционной базой. И нет, не шибко единообразная.

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

Извини, это в некотором смысле объективный закон. Что-то вроде закона
всемирного тяготения. Не просто нет, а доказуемо не может быть.

Помнится, код, переписанный с C++ на C со старательным выкидыванием
всей
объектности, кроме нужной, стал на порядок компактнее, вдвое
понятнее, и
давал в разы меньший результат при компиляции.
Tcl - он же функциональный по сути, зачем ему объекты?
АН Хм... Честно не знаю. Объекты, в принципе, не лишние. Но как
совмещается
АН объектный и функциональный подход..? Хотя, библиотеки-то есть...
Никогда не надо пользоваться тем, что в принципе не лишнее.
Пользоваться надо только тем, что тебе действительно нужно, и понимая,
почему именно оно, а не альтернативы.
АН Да, бритву Оккама не отменяли. :-) Но, во-первых, не всегда
АН возможно выбрать лучшую из альтернатив, потому что обе они имеют
АН взаимокомпенсирующие достоинства и недостатки, так что, ни одна из
АН них не является лучшей. Во-вторых, иногда просто недостаточно
АН информации для выбора.
Я видел только один вариант недостаточно информации для выбора -
незнание альтернатив.
АН Нет, почему же?
АН Незнание всех характеристик альтернатив, незнание того, как поведёт
АН себя данная альтернатива, незнание того насколько сильнее одна
АН характеристика влияет на абстрактное качество системы, чем
АН другая. Много что возможно не знать.

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

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

Монетку брось.

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

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

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 22:24:18 +0400:

Впрочем,
как на шелл - это лучше на шелле же и писать. Ну, с
привлечением sed
и/или awk. perl позволяет писать совершенно третьим
способом, и вот
именно им и надо писать надежные программы на нем.
АН Эээ Каким?
use strict;
eval {...}; (не путать с eval ...)
Гы-гы... Это мне о многом говорит. :-D Нет, правда. :-D
Не вижу ничего смешного, даже краткого знакомства с Perl достаточно,
чтобы понять различие поведения для строки () и блока кода ({}).
АН Я понимаю различие. {} - выполним, строка - нет. Мне само
АН предложение нравится. :-)
Нифига ты не понимаешь :-)
АН Я-то, как-раз понимаю. :-D
Если бы понимал, ты бы не высказывал неверных утверждений.
АН Посмотрел для чего используют eval {}.
АН Т.е., чтобы отловить синтаксические ошибки на этапе компиляции (в случае
с
АН eval - выражение просто строка, поэтому и ошибки не отлавливаются), но
не
АН допустить выброса исключений (поскольку выражение в {} выполняется ей, как
АН автономная программа)?
АН Но всё-равно, выглядит диковато...

Неверно утверждение, что {} выполним, а строка - нет. И то, и другое
выполнимо, если попросить, и не выполнимо, если не просить. Различие,
собственно, во времени компиляции кода, и это очень существенное
различие.

Для задач, которые можно решать на sh, этого достаточно. Ну,
может, еще
IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток, и на
выходе его забирать, да еще (в случае Open3) stderr анализировать.
Не знаю, может Perl и хорош. Но Camel Book, о котором тут писали
на 1000 с
копейками страниц? И тогда уж сравните с книгой KR...

Так с момента выхода содержание KR не особо менялось, а теперь
сравните
годы выпуска Camel Book и KR и вспомните, сколько всяких разных
mainstream- и не очень технологий и концепций появилось.
АН Ага. И, тем не менее, книга KR по сей день актуальна. Ну,
АН естественно, кое-что устаревает (в т.ч. немного поменялся
АН синтаксис), но в общем
Да, ты до сих пор можешь писать на C, и даже, если хорошо попросить gcc,
на KR C. Но с тех пор появилась возможность тратить свое рабочее время
более эффективно.
АН Опять вы о своём. Не понимаете основного: я не хочу сказать, что нужно
АН вернуться к C (от которого в некоторых задачах и не уходили).
АН Просто размер основного руководства по языку говорит о многом.
Может быть. Но явно не о том, о чем ты подумал.
АН И о чём?

Может говорить о том, что язык богаче (как в данном случае). Может - о
том, что его использовать сложнее (как в случае C++). Может о том, что
язык неудачно спроектирован (возьми руководство по PHP, да впрочем, я и
про C++ то же скажу). Может просто об объеме материала - тот же Стивенс
тоже про программирование на C, и куда как толще KR, причем он не
повторяет KR, подразумевая, что тот уже прочитан. А может и просто о
словоохотливости автора.

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 22:16:01 +0400:

Я бы ещё добавил, что ОО-парадигма рождается из желания перейти от
классической модели императивного вычислителя, как единого конечного
автомата, к модели многих изолированных конечных автоматов,
взаимодействующих
через чётко ограниченные интерфейсы. Точно так же в электронике от паука
на рассыпухе, пришли сначала к модульным схемам, а потом к ИС.
АН Ну и? Это естественный, эволюционный процесс. Разве должно быть иначе?

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

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

Потому что их приткнуть либо некуда, либо незачем.

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

Все это можно сделать. Увеличение пользы где? Если у тебя
функциональная программа уже есть, то зачем тебе объект в виде
функциональной программы? Чего тебе в языке до введения объектов не
хватало?

Что же до остального... От того, что ты прячешь природу сущности за
некоторой абстракцией, ты что-то выигрываешь, но чем-то за это и
платишь. И очень не факт, что только производительностью, а не,
например, выразительной силой. У функции есть, например, операция
частичного применения, обладающая своей выразительной силой. У объекта
ее нет. Использование сопрограммы подразумевает (не для компьютера, для
другого программиста) определенный протокол взаимодействия. У объекта
он другой. Можно реализовать его с помощью сопрограммы, но это будет
менее естественно, чем воспользоваться родным, если он годится.

И так далее. В итоге ты начинаешь вносить в язык, обладающий
достаточной выразительной силой, парадигму, которая выразительную силу
языка не увеличивает, а при неаккуратном употреблении и уменьшает. А
смысл?

АН Парадигма обязательно должна быть императивной, и где я ошибаюсь?

Объект - очень слабая абстракция. В более сильных парадигмах, чем
императивная (ну хорошо, процедурная) он просто не приносит достаточно
пользы.

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

Re: Несколько вопросов вразброс

Артём Н. - debian-russian@lists.debian.org @ Wed, 04 Jul 2012 22:06:17 +0400:

АН Да, кстати, Пролог я не понимаю. :-(

[...]

АН И на практике: будь всё так хорошо, как вы пишите, все бы уже давно
АН писали на Прологе (по крайней мере, знали бы что это такое). :-)
Ну ведь ты же сам написал, что ты его не понимаешь. Думаешь, ты один
его не понимаешь?
АН Если был он был такой хороший, его бы понимали. Потому что, за это
АН бы платили. :-) И этому учили. C ничуть не проще, чем Пролог. Он
АН просто имеет другую парадигму. Развёрнутую на 180. У машины
АН вывода есть свои недостатки, ограничения и своя область
АН применения. По какой-то совокупности причин, Пролог не нашёл
АН широкого применения (хотя к нему интерес то падал, то
АН возобновлялся).

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

Правильность программы относительно заданных условий будет определяться
правильностью задания нелогических аксиом.
АН В смысле - нелогических? o.O

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

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

АН Так?

Последнее предложение неверно. Скажем так, мы верим, что математика
правильна (в том смысле, что доказанный в ней результат о некоторой
модели можно в рамках ограничения этой модели применить к реальности).
Гедель нам доказал, что ни на что, кроме веры, мы не можем тут
положиться даже на предмет ее внутренней непротиворечивости, не говоря
уж о применениях к реальности.

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

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

Если задача поставлена лучше, то обычно и парадигму можно найти получше.
АН Хм... Может. Но не только для этого случая применимо же..?
АН Т.е., вы хотите сказать, что ООП - это для снизу-вверх?
АН А для наоборот и сама по себе, разве концепция плоха? :-)

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

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

А к сверху вниз/снизу вверх ООП, опять же, перпендикулярна. Она про
другое. Можно плохо поставленную задачу решать и сверху вниз, начиная
выделение

Re: Несколько вопросов вразброс

On Wed, Jul 04, 2012 at 10:16:01PM +0400, Артём Н. wrote:
 04.07.2012 20:36, Stanislav Maslovski пишет:
  Я бы ещё добавил, что ОО-парадигма рождается из желания перейти от
  классической модели императивного вычислителя, как единого конечного
  автомата, к модели многих изолированных конечных автоматов, 
  взаимодействующих
  через чётко ограниченные интерфейсы. Точно так же в электронике от паука
  на рассыпухе, пришли сначала к модульным схемам, а потом к ИС.
 Ну и? Это естественный, эволюционный процесс. Разве должно быть иначе?

Я пытаюсь выразить простую мысль, что переход на ООП естественен и
эволюционен _только_ для _императивных_ языков. В функциональных
языках объектная модель смотрится притянутой за уши.

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

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

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

Если ты пытаешься здесь высказать, что _любая_ модульная система
функционирует в рамках ОО-парадигмы, то я тебе на это скажу, что ты
просто ещё недостаточно полно знаком с предметом.

 Парадигма обязательно должна быть императивной, и где я ошибаюсь?

Это утверждение или вопрос?

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120705005338.GA24420@kaiba.homelan

Re: Несколько вопросов вразброс

On Wed, 4 Jul 2012 23:13:58 +0300
Dmitry Nezhevenko d...@inhex.net wrote:

On Wed, Jul 04, 2012 at 11:40:28PM +0400, Alexander Galanin wrote:
Основная необходимая функциональность в cdrecord и так есть. В том числе и
прогрессбар.
И как это коррелирует с крутостью Tcl/Tk и/или убогостью C++?
Я не понимаю, какой тезис этим опровергается.
Тезис что сравнением k3b с прогрессбаром к cdrecord на tcl/tk можно
сравнивать C++/Qt с Tcl/Tk

А ты скачай исходники и посмотри, как конкретно это место реализовано в
k3b. То, что у меня было сделано в пару строк через open/fileevent, там
требует самописный класс k3bqprocess (один он занимает 2k строчек) и
развесистую иерархию классов-потомков для парсинга вывода stdout каждого
процесса.

Всё это при том, что Qt не мешает реализовать асинхронную работу
точь-в-точь как в моём примере. Но вот автор k3b такого решения не
увидел, потому что был занят наследованием и созданием тредов.

--
Alexander Galanin

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120705055628.7538df40efe4c556cdbb4...@galanin.nnov.ru

Re: Несколько вопросов вразброс