subject:"stderr"

Re: stderr

2008-12-01 Пенетрантность Alexey Pechnikov

Hello!

В сообщении от Monday 01 December 2008 10:22:32 Stanislav Kruchinin написал(а):
 Если системы компьютерной алгебры для вас обязательно визуальные пакеты,
 в которых надо куда-то пощелкать, то вы не имеете представления о
 предмете разговора. Программы для Maxima, Octave и Mathematica могут быть
 написаны в текстовом редакторе. Алгоритм, который использовали разработчики
 пакета, обычно указан в документации. Кроме того, в хороших системах
 реализовано несколько алгоритмов и можно самому выбирать, какой именно
 используется.

Разработка мат. модели более-менее сложного физпроцесса требует многих месяцев 
или лет работы. 
Создание программы - несколько недель. Но неправильная реализация схемы расчета 
или неявные 
округления (скажем, использование float вместо double в целях оптимизации) 
могут привести к выводу 
о некорректности модели и потребовать сложных и затратных натурных 
экспериментов. К примеру, 
использование программно сгенерированного случайного шума убило немало работ 
-  разработчики выч. 
пакетов обманывают и используют стандартный алгоритм генерации случайных 
чисел, который на самом 
деле выдает коррелированную последовательность, но, чтобы это узнать, надо 
задуматься и посмотреть 
двумерный спектр. Двумерный спектр также лучше посчитать честно, поскольку 
здесь критичны ошибки 
округления (маткад, к примеру, достаточно правдиво показывает низкочастотные 
гармоники, но дальше 
выводит полную ахинею). Не уверен, что хоть один из перечисленных вами пакетов 
способен 
сгенерировать хотя бы двумерный случайный шум с распределением Гаусса и 
заданным радиусом 
корреляции. К примеру, распределение 1000 х 1000 микрон в выч. пакетах запросто 
моделируют как 100 
х 100 отсчетов. Но если прикинуть радиус корреляции оптических неоднородностей 
в исследуемой среде 
(речь может идти, в частности, о полимеризации фотополимера в когерентном 
свете), скажем, 5 микрон, 
и посчитать минимально достаточное кол-во отсчетов в масштабе одной 
неоднородности, выясняется, что 
необходимое число отсчетов на порядок больше интуитивно понятного и на 
реализации модели в 100 х 
100 отсчетов никакой физики увидеть невозможно в принципе. Но часто студенты, 
не понимая этого, 
твердят, что мол считали в маткаде (или ему подобных) и ошибиться не могли - 
они даже не видят 
физики процесса, а только программный пакет с менюшками и окошками графиков. 
Да, готовый алгоритм 
для решенной задачи можно завернуть в модуль расширения к одной из программных 
систем, но даже и в 
этом случае вы узнаете не больше, чем знает об этой задаче разработчик 
алгоритма, а уж каких-то 
научно новых результатов и в глаза не увидите. 

Best regards, Alexey.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-12-01 Пенетрантность Иван Лох

On Mon, Dec 01, 2008 at 05:23:55AM +0300, Stanislav Kruchinin wrote:
Иван Лох wrote:

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

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

Гипергеометрические функции больших аргументов и эллиптические функции
комплексного аргумента IMHO просто использовать нельзя. В первом случае она
просто тупо считает все с float, во-втором, тоже какая-то фигня.

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

Ну в этом случае как-раз многие через MathLink свои модули на C цепляют.

А проблема IMHO в том, что физиков и чистых математиков лиспу (и
функциональным
языкам, вообще) ни хрена не учат. Как и многие я учил лисп по пакетам
максимы,
и, будь у меня под рукой Математика, просто забил бы на все это. В
Математике же
есть целый ряд процедурных костылей для неграмотных. Их все и используют. Это
как javascript -- хороший язык на котором 98% пишут как на бейсике. Раньше
люди
хоть смотрели на вольфрамовские пакеты и пытались учиться, теперь же они в
своей массе прекомпилированы.

Да. С IT-образованием у нас вообще катастрофа: не то что функциональному
программированию, даже процедурному на обычном C нормально не учат.

Как раз С и/или фортран знают почти все. Соответственно в Математике
программируют посредством For и/или Do.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-12-01 Пенетрантность Иван Лох

On Mon, Dec 01, 2008 at 10:22:32AM +0300, Stanislav Kruchinin wrote:
 Mathematica могут быть написаны в текстовом редакторе. Алгоритм, который 
 использовали разработчики пакета, обычно указан в документации. Кроме 
 того, в хороших системах реализовано несколько алгоритмов и можно самому 
 выбирать, какой именно используется.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-30 Пенетрантность Иван Лох

On Sun, Nov 30, 2008 at 06:55:35AM +0300, Stanislav Kruchinin wrote:
Ориджин это сила. Именно с ним в экспериментальную физику и химию пришла
инновационная идея: если положение экспериментальной точки не удоветоряет
требованиям исследователя -- ее просто удаляют или передвигают.

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

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

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

Просто на нее ориентируются, как на лидера. Лично я не вижу ничего
плохого в идее
Macsyma-без-лиспа-которую-мы-запустим-на-любом-дерьме-и-возмем-за-это-бабки.
Я конечно же не имел в виду Macsyma, т.к. знаю, что она была создана
раньше (в конце 60-х) и являлась скорее примером для подражания, которому
следовали те же Mathematica и Maple. Насколько мне известно, то сами
создатели Macsyma настаивали на ее коммерциализации, а руководство MIT
просто перехватило у них инициативу. Ее бы так или иначе закрыли и
продали.

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

В данном случае речь идет о современных попытках создания системы
компьютерной алгебры с открытыми исходниками, сопоставимой с Mathematica
по широте возможностей (например, Maxima, open source форк версии Macsyma
от 1982 года).

Maxima и есть слепок Macsyma в момент приватизации. Шелтер раздавал ее много лет
со своего ftp, не имея на это никаки прав. Его преследовали, но из-за
немыслимого
бардака с правами на систему он выкручивался. Maxima и сейчас лучше Математики.
Посмотришь на офис Wolfram Research в Урбане, и думаешь, что там такая толпа
народу
делает? Оболочку с Motif на qt переписывают... Лет десять назад я читал статью
с самыми нелепыми ошибками Математики. Прошло 5 версий, а воз и ныне там.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-30 Пенетрантность Stanislav Kruchinin

Иван Лох wrote:

On Sun, Nov 30, 2008 at 06:55:35AM +0300, Stanislav Kruchinin wrote:

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

В этом есть горькая правда.

В данном случае речь идет о современных попытках создания системы
компьютерной алгебры с открытыми исходниками, сопоставимой с Mathematica по
широте возможностей (например, Maxima, open source форк версии Macsyma от
1982 года).

Maxima и есть слепок Macsyma в момент приватизации. Шелтер раздавал ее много
лет со своего ftp, не имея на это никаки прав. Его преследовали, но из-за
немыслимого бардака с правами на систему он выкручивался. Maxima и сейчас
лучше Математики. Посмотришь на офис Wolfram Research в Урбане, и думаешь,
что там такая толпа народу делает? Оболочку с Motif на qt переписывают... Лет
десять назад я читал статью с самыми нелепыми ошибками Математики. Прошло 5
версий, а воз и ныне там.

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-30 Пенетрантность Иван Лох

On Sun, Nov 30, 2008 at 06:11:36PM +0300, Stanislav Kruchinin wrote:

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

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

А проблема IMHO в том, что физиков и чистых математиков лиспу (и функциональным
языкам, вообще) ни хрена не учат. Как и многие я учил лисп по пакетам максимы,
и, будь у меня под рукой Математика, просто забил бы на все это. В Математике же
есть целый ряд процедурных костылей для неграмотных. Их все и используют. Это
как javascript -- хороший язык на котором 98% пишут как на бейсике. Раньше люди
хоть смотрели на вольфрамовские пакеты и пытались учиться, теперь же они в
своей массе прекомпилированы.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-30 Пенетрантность Stanislav Kruchinin

Иван Лох wrote:

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

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

А проблема IMHO в том, что физиков и чистых математиков лиспу (и функциональным
языкам, вообще) ни хрена не учат. Как и многие я учил лисп по пакетам максимы,
и, будь у меня под рукой Математика, просто забил бы на все это. В Математике же
есть целый ряд процедурных костылей для неграмотных. Их все и используют. Это
как javascript -- хороший язык на котором 98% пишут как на бейсике. Раньше люди
хоть смотрели на вольфрамовские пакеты и пытались учиться, теперь же они в
своей массе прекомпилированы.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-30 Пенетрантность Alexey Pechnikov

Hello!

В сообщении от Monday 01 December 2008 05:23:55 Stanislav Kruchinin написал(а):
Да. С IT-образованием у нас вообще катастрофа: не то что функциональному
программированию, даже процедурному на обычном C нормально не учат.

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

Best regards, Alexey.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-30 Пенетрантность Stanislav Kruchinin

Alexey Pechnikov wrote:

В сообщении от Monday 01 December 2008 05:23:55 Stanislav Kruchinin написал(а):

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

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

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-29 Пенетрантность Иван Лох

On Fri, Nov 28, 2008 at 10:27:08PM +0300, Stanislav Kruchinin wrote:
Исчезающе малая? Лично я вижу очень много попыток переписать под
свободной лицензией то или иное проприетарное ПО. Примеров масса: Origin,
Mathematica и даже (стыдно сказать) Microsoft Office.

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

Что же касается Математики, то это очень плохой пример. Это система была
задума как Macsyma-без-лиспа-которую-мы-запустим-на-любом-дерьме-и-возмем-за
это-бабки и в точности достигла своей цели. Учитывая, что lisp Максимы был
общедоступен, то дело было не хитрое. А максиму MIT отобрал у профессоров,
которые ее писали, закрыл, и продал. Теперь нам рассказывают сказки о том, что
это математику переписывают под свободной лицензией.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-29 Пенетрантность Alexander Danilov

Artem Chuprina пишет:

Alexander Danilov - debian-russian@lists.debian.org @ Fri, 28 Nov 2008
23:13:21 +0900:

ПК Кстати с чем мы сравниваем?

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

AD Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не
AD флейма для, а опыта ради. Просто мне до сих пор встречались
AD сложные случаи, но они были из разряда лобовая атака, то
есть
AD если попытаться загнать в listbox несколько тысяч строк, то
тормоза
AD конечно будут, но виноват разработчик, а если переделать
форму, то
AD и миллионы можно увидеть, причём без особого напряжения.

Ну, например, поле ввода с дополнением по справочнику.

AD И какие тут сложности?

Виджет такой на tcl/tk сделай. С configure и т.д. Формочку-то
нарисовать нетрудно, но мне таких полей надо сильно не одно.

AD Делал, без configure правда, но как раз со справочником. По F1
AD вызывался, хотя надо было бы в combobox завернуть наверно. А в
AD gridplus2 ничего такого нет?

Без configure и я могу. Мне полноценный виджет, пожалуйста.

И не на C. С задействованием библиотеки на C я тоже могу, но очень уж
муторно.

AD Ну сейчас это не очень муторно, snit умеет создавать правильные
AD виджеты, с configure.

Ты пробовал? А разрабатывать этот виджет по этой схеме на наладоннике?
С интел-несовместимым процессором? И как ощущения?

Пробовал, конкретно этот виджет нет, но на наладоннике ipaq/zaurus.
Ощущения как обычно, на наладоннике вообще разрабатывать не удобно, но на
zaurus удобнее , чем на ipaq :)

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-29 Пенетрантность Stanislav Kruchinin

Иван Лох wrote:

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

А я и не утверждал, что ее именно переписывают под свободной лицензией. Просто
на нее ориентируются, как на лидера. Лично я не вижу ничего плохого в идее
Macsyma-без-лиспа-которую-мы-запустим-на-любом-дерьме-и-возмем-за-это-бабки.
Я конечно же не имел в виду Macsyma, т.к. знаю, что она была создана раньше (в
конце 60-х) и являлась скорее примером для подражания, которому следовали те же
Mathematica и Maple. Насколько мне известно, то сами создатели Macsyma
настаивали на ее коммерциализации, а руководство MIT просто перехватило у них
инициативу. Ее бы так или иначе закрыли и продали.

В данном случае речь идет о современных попытках создания системы компьютерной
алгебры с открытыми исходниками, сопоставимой с Mathematica по широте
возможностей (например, Maxima, open source форк версии Macsyma от 1982 года).

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-28 Пенетрантность Alexander Danilov

Artem Chuprina пишет:

Alexander Danilov - debian-russian@lists.debian.org @ Wed, 26 Nov 2008
21:59:57 +0900:

ПК Кстати с чем мы сравниваем?

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

AD Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не
AD флейма для, а опыта ради. Просто мне до сих пор встречались
AD сложные случаи, но они были из разряда лобовая атака, то есть
AD если попытаться загнать в listbox несколько тысяч строк, то тормоза
AD конечно будут, но виноват разработчик, а если переделать форму, то
AD и миллионы можно увидеть, причём без особого напряжения.

Ну, например, поле ввода с дополнением по справочнику.

AD И какие тут сложности?

Без configure и я могу. Мне полноценный виджет, пожалуйста.

И не на C. С задействованием библиотеки на C я тоже могу, но очень уж
муторно.

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-28 Пенетрантность Artem Chuprina

Alexander Danilov - debian-russian@lists.debian.org @ Fri, 28 Nov 2008
23:13:21 +0900:

ПК Кстати с чем мы сравниваем?

Ну, например, поле ввода с дополнением по справочнику.

AD И какие тут сложности?

Без configure и я могу. Мне полноценный виджет, пожалуйста.

И не на C. С задействованием библиотеки на C я тоже могу, но очень уж
муторно.

AD Ну сейчас это не очень муторно, snit умеет создавать правильные
AD виджеты, с configure.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

The last good thing written in C was Franz Schubert's Symphony number 9.
-- Erwin Dieterich

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-28 Пенетрантность Alexey Pechnikov

Hello!
Ну вы же со своей стороны видите, и можете сказать об этом. Они не в курсе,
потому что им не хватает квалификации.

Предположение ничем не обоснованное.

Нужно отслеживать и увольнять таких
людей.

Кто будет отслеживать и увольнять? И, кстати, за что? Мне не доводилось даже
слышать о таком пункте
в должностных обязанностях - писать качественный код.

Причиной этого является плохое образование исполнителей, а не
бизнес-модель.

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

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

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

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

Есть масса
примеров хороших closed source программ, ставших образцами для
подражания в open source. Вспомните тот же BitKeeper, distributed VCS,
по образу и подобию которой были созданы Git, Mercurial и прочие.

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

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

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

Сам факт открытия исходников не приведет к их улучшению. Чтобы это
произошло, надо чтобы данный исходный текст заинтересовал человека более
профессионального, чем разработчики продукта. Никто не обещает, что это
точно произойдет, как с рецензируемой научной статьей, существует лишь
некая вероятность. Ни в closed, ни в open source нет механизма,
заставляющего обеспечивать необходимое качество. По большей части все
зависит от самих исполнителей.

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

Best regards, Alexey.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-28 Пенетрантность Stanislav Kruchinin

Alexey Pechnikov wrote:

Hello!

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

Предположение ничем не обоснованное.

Эта фраза была адресована конкретному человеку, который описал выше свою
ситуацию, а не вам. Он на это ничего не возразил.

Нужно отслеживать и увольнять таких
людей.

Кто будет отслеживать и увольнять? И, кстати, за что? Мне не доводилось даже слышать о таком пункте
в должностных обязанностях - писать качественный код.

Руководитель проекта. Вообще, в УК есть статья за халатность, но она действует
только в случаях причинения серьезного ущерба. Если человек хорошо относится к
своему делу, то он будет писать хороший код, не зависимо от того, грозит ли ему
какое-то наказание или нет, закрытый исходник у его программы или открытый.

Причиной этого является плохое образование исполнителей, а не
бизнес-модель.

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

Вы просто работали с плохими людьми и в плохих конторах, вот вам и кажется, что
коммерческий софт пишут идиоты, а open source пишут только светочи. Open source,
скажу я вам, в значительной степени делается теми же профессиональными
программистами в свободное от работы время. Например, проектом OpenBSD никто не
занимается full time, кроме Тео де Раадта.

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

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

Evaluation и demo версии уже отменили? Контракты на поддержку и внедрение ПО
(свободное оно или нет) на взаимовыгодных условиях никто не запрещает заключать.
Просто должен быть выбор, тогда производитель не будет наглеть.

Есть масса
примеров хороших closed source программ, ставших образцами для

подражания в open source. Вспомните тот же BitKeeper, distributed VCS,
по образу и подобию которой были созданы Git, Mercurial и прочие.

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

Исчезающе малая? Лично я вижу очень много попыток переписать под свободной
лицензией то или иное проприетарное ПО. Примеров масса: Origin, Mathematica и
даже (стыдно сказать) Microsoft Office.

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

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

Re: stderr

2008-11-28 Пенетрантность Alexey Pechnikov

Hello!

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

Предположение ничем не обоснованное.

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

Кто будет отслеживать и увольнять? И, кстати, за что? Мне не доводилось
даже слышать о таком пункте в должностных обязанностях - писать
качественный код.

Руководитель проекта. Вообще, в УК есть статья за халатность, но она
действует только в случаях причинения серьезного ущерба. Если человек
хорошо относится к своему делу, то он будет писать хороший код, не зависимо
от того, грозит ли ему какое-то наказание или нет, закрытый исходник у его
программы или открытый.

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

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

Вы просто работали с плохими людьми и в плохих конторах, вот вам и кажется,

Не нужно тыкать пальцем в небо.

что коммерческий софт пишут идиоты, а open source пишут только светочи.
Open source, скажу я вам, в значительной степени делается теми же
профессиональными программистами в свободное от работы время. Например,
проектом OpenBSD никто не занимается full time, кроме Тео де Раадта.

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

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

Evaluation и demo версии уже отменили? Контракты на поддержку и внедрение
ПО (свободное оно или нет) на взаимовыгодных условиях никто не запрещает
заключать. Просто должен быть выбор, тогда производитель не будет наглеть.

Даже смешно. К примеру, меня интересуют возможности энтерпрайз версии СУБД
оракл - много я узнаю,
опробовав их бесплатную версию?

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

Исчезающе малая? Лично я вижу очень много попыток переписать под свободной
лицензией то или иное проприетарное ПО. Примеров масса: Origin, Mathematica
и даже (стыдно сказать) Microsoft Office.

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

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

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

Продукция Apple -- это типичный пример исключения из законов спроса и
предложения. Если продукт инновационный (или, по крайней мере,

Re: stderr

2008-11-26 Пенетрантность Artem Chuprina

Alexander Danilov - debian-russian@lists.debian.org @ Wed, 26 Nov 2008
21:59:57 +0900:

ПК Кстати с чем мы сравниваем?

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

AD Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не
AD флейма для, а опыта ради. Просто мне до сих пор встречались
AD сложные случаи, но они были из разряда лобовая атака, то есть
AD если попытаться загнать в listbox несколько тысяч строк, то тормоза
AD конечно будут, но виноват разработчик, а если переделать форму, то
AD и миллионы можно увидеть, причём без особого напряжения.

Ну, например, поле ввода с дополнением по справочнику.

AD И какие тут сложности?

Без configure и я могу. Мне полноценный виджет, пожалуйста.

И не на C. С задействованием библиотеки на C я тоже могу, но очень уж
муторно.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Think of C++ as an object-oriented assembly language.
-- Bruce Hoult ([EMAIL PROTECTED])

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-26 Пенетрантность Alexander Danilov

Artem Chuprina пишет:

Alexander Danilov - debian-russian@lists.debian.org @ Tue, 25 Nov 2008
23:10:51 +0900:

ПК Кстати с чем мы сравниваем?

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

AD Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не
AD флейма для, а опыта ради. Просто мне до сих пор встречались
AD сложные случаи, но они были из разряда лобовая атака, то есть
AD если попытаться загнать в listbox несколько тысяч строк, то тормоза
AD конечно будут, но виноват разработчик, а если переделать форму, то
AD и миллионы можно увидеть, причём без особого напряжения.

Ну, например, поле ввода с дополнением по справочнику.

AD И какие тут сложности?

Делал, без configure правда, но как раз со справочником. По F1 вызывался, хотя
надо было бы в combobox завернуть наверно. А в gridplus2 ничего такого нет?

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-25 Пенетрантность Alexander Danilov

Victor Wagner пишет:

On 2008.11.25 at 01:22:27 +0900, Alexander Danilov wrote:

Artem Chuprina пишет:

ПК Кстати с чем мы сравниваем?

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

Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не флейма для, а
опыта

С точки зрения количества телодвижений Tcl проигрывает shell-у.
Я тут как-то недавно переписывал билдсервер с (cygwinовского) bash на
(activestate) tcl, так объем кода вырос в раз несколько, а

функциональность возросла не то чтобы сильно.

На некоторых классах задач он проигрывает perl (в частности за счет
-wc и -T у последнего).

Но есть подозрение, что читабельность по сравнению и с bash и perl возросла,
так?
Да, лаконичным Tcl на назовёшь.

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

Был тут у меня пару лет назад случай, когда 6-мегабайтный массив данных
несколько десятков тысяч раз не по делу конвертировался между двумя
внутренними представлениями. Все-таки прозрачные для программиста
dual-representation объекты - не всегда rules.

Отловил только полезши в tclsh с дебаггером. А исправил - переставив
местами две строчки (правда, в своем C-шном расширении, реализовывавшем
мой собственный тип объектов).

Здесь тоже соглашусь, Сишный API простым не назовёшь, хотя dual-representation
объекты чаще всего rules.

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

Листбоксы там прямо скажем неудачные. Если что посложнее, так надо
Tktable брать. Вот там как раз и миллионы можно.

Нет, Tktable тоже большие объёмы переваривает на важно, хотя лучше того же listbox'a, значительно
лучше. Для очень больших объёмов данных, лучше всё таки изменить алгоритм работы пользователя, ну а
если это невозможно, то проще сделать frame с накиданными в него виджетами и scrollbar сбоку, чтобы
с помощью оного scrollbar'а подменять или значения -textvariable для виджетов из frame, или
переменных, на которые -textvariable ссылается, это уж как удобней будет. Я такое 10 лет назад
делал, только на perl/tk, так как с тиклем плохо ещё был знаком. Так вот в таком варианте прокрутка
получается очень быстрая, если данные загрузить в массив. Если ещё немного времени потратить, можно
сделать добавление/удаление строк в frame при изменении его размера.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-25 Пенетрантность Alexander Danilov

Artem Chuprina пишет:

Alexander Danilov - debian-russian@lists.debian.org @ Tue, 25 Nov 2008
01:22:27 +0900:

ПК Кстати с чем мы сравниваем?

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

AD Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не
AD флейма для, а опыта ради. Просто мне до сих пор встречались
AD сложные случаи, но они были из разряда лобовая атака, то есть
AD если попытаться загнать в listbox несколько тысяч строк, то тормоза
AD конечно будут, но виноват разработчик, а если переделать форму, то
AD и миллионы можно увидеть, причём без особого напряжения.

Ну, например, поле ввода с дополнением по справочнику.

И какие тут сложности?

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-25 Пенетрантность Victor Wagner

On 2008.11.25 at 23:09:38 +0900, Alexander Danilov wrote:

У tktable есть опция -command, которая позволяет в нем данные не
хранить. Вот с этой опцией, да с продуманным бэкэндом хранения - можно и
миллионы. И это гораздо проще чем нижеописанное, а по смыслу - то же
самое. И удаление-добавление строк при ресайзе Хоббс уже за нас
написал.

с помощью оного scrollbar'а подменять или значения -textvariable для
виджетов из frame, или переменных, на которые -textvariable ссылается,
это уж как удобней будет. Я такое 10 лет назад делал, только на perl/tk,
так как с тиклем плохо ещё был знаком. Так вот в таком варианте прокрутка
получается очень быстрая, если данные загрузить в массив. Если ещё
немного времени потратить, можно сделать добавление/удаление строк в
frame при изменении его размера.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-25 Пенетрантность Alexander Danilov

Victor Wagner пишет:

On 2008.11.25 at 23:09:38 +0900, Alexander Danilov wrote:

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-25 Пенетрантность Artem Chuprina

Alexander Danilov - debian-russian@lists.debian.org @ Tue, 25 Nov 2008
23:10:51 +0900:

ПК Кстати с чем мы сравниваем?

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

AD Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не
AD флейма для, а опыта ради. Просто мне до сих пор встречались
AD сложные случаи, но они были из разряда лобовая атака, то есть
AD если попытаться загнать в listbox несколько тысяч строк, то тормоза
AD конечно будут, но виноват разработчик, а если переделать форму, то
AD и миллионы можно увидеть, причём без особого напряжения.

Ну, например, поле ввода с дополнением по справочнику.

AD И какие тут сложности?

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

А еще следует потребовать, чтобы программисты, перед тем, как писать код,
внимательно прочли спецификацию: с сыром - это чизбургер.
Игус в [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-24 Пенетрантность Покотиленко Костик

В Суб, 22/11/2008 в 00:17 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 21 Nov 2008
22:23:11 +0200:

Ну, к авторам The Gimp и другие претезнии есть. Например, то, что в
Script-Fu garbage-collection не собирает объекты IMAGE, CHANNEL и тому
подобные. Их приходится уничтожать явно.

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

Думаю, что и с GUI у них было то же самое - не сумели understand,
и стали reinvent. Poorly.

Кстати, большая часть тех вкусностей, которая отличала Gtk времен
gimp 0.9 от современных ему тулкитов потом куда-то делась, задавленная
тяжестью Gnome HIG.

ПК Сам GTK инструмент хороший, не без претензий конечно, НО тяжесть и
ПК ресурсоёмкость програм - это следствие малого количества времени
ПК затраченного разработчиками программ на ОПТИМИЗАЦИЮ.

ПК К примеру, была задача организовать TreeView с ~4 миллиона строк и ~30
ПК колонок, нужен был поиск. База в dbf ~3Гб. Представляю сколько памяти бы
ПК зажрала прога и как бы она тупила если всё держать в TreeStore с
ПК прокруткой и поиском. В итоге сделал поиск по индексу, а часть
ПК результата помещался в TreeView, который был размером количества строк,
ПК которое влазит на экран, прокрутка к TreeView не привязана, и при
ПК прокрутке, сдвинутый список заливался в TreeStore.

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

Я тоже у себя в программе к такому подходу пришел. Но я к нему пришел
от кривизны, глючности и недостаточной функциональности TreeView.
Т.е. разделение на model, view и controller у них вменяемое, но ни
вменяемого готового view, ни вменяемого готового model нет.

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

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

Мою задачу можно было красиво решить написав свой Model и может быть
View.

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

Не хочешь делать в ручную, переходи на C#$%^, потом будешь жаловаться,
что программа что-то делает, а что не понятно и как влиять на это не
понятно тоже.

--
Покотиленко Костик [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-24 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 24 Nov 2008
13:33:37 +0200:

Я тоже у себя в программе к такому подходу пришел. Но я к нему
пришел от кривизны, глючности и недостаточной функциональности
TreeView. Т.е. разделение на model, view и controller у них
вменяемое, но ни вменяемого готового view, ни вменяемого готового
model нет.

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

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

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

ПК Не хочешь делать в ручную, переходи на C#$%^, потом будешь
ПК жаловаться, что программа что-то делает, а что не понятно и как
ПК влиять на это не понятно тоже.

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

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Historically, languages designed for other people to use have been
bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those
that were designed for their own creators: C, Perl, Smalltalk, Lisp.
-- Paul Graham

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-24 Пенетрантность Покотиленко Костик

В Пнд, 24/11/2008 в 15:19 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 24 Nov 2008
13:33:37 +0200:

Я тоже у себя в программе к такому подходу пришел. Но я к нему
пришел от кривизны, глючности и недостаточной функциональности
TreeView. Т.е. разделение на model, view и controller у них
вменяемое, но ни вменяемого готового view, ни вменяемого готового
model нет.

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

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

Так что как таблица типа Excel TreeView не катит, она просто для этого
не предназначена. Для этого надо писать что-то своё, или выдрать
откуда-нибудь, например из Gnumeric'а или Evolution (как-то пытался, но
не смог).

Сам факт того, что эти вещи более менее нормально реализованы в том же
Gnumeric говорит о тот что тулкит очень мощный, но дописывать своё под
задачу иногда надо.

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

О чём и речь.

--
Покотиленко Костик [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-24 Пенетрантность Покотиленко Костик

В Пнд, 24/11/2008 в 16:09 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 24 Nov 2008
14:46:44 +0200:

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

ПК Так что как таблица типа Excel TreeView не катит, она просто для этого
ПК не предназначена. Для этого надо писать что-то своё, или выдрать
ПК откуда-нибудь, например из Gnumeric'а или Evolution (как-то пытался, но
ПК не смог).

ПК Сам факт того, что эти вещи более менее нормально реализованы в том же
ПК Gnumeric говорит о тот что тулкит очень мощный, но дописывать своё под
ПК задачу иногда надо.

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

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

Это правда. Хотя с чем сравнивать... В винде тоже не всё так хорошо, на
сколько я видел...

Кстати с чем мы сравниваем?

P.S. Мощный != Укомплектованный :)

--
Покотиленко Костик [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-24 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 24 Nov 2008
14:46:44 +0200:

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-24 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 24 Nov 2008
15:58:50 +0200:

ПК Это правда. Хотя с чем сравнивать... В винде тоже не всё так хорошо, на
ПК сколько я видел...

ПК Кстати с чем мы сравниваем?

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

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

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Functional programming is like describing your problem to a
mathematician. Imperative programming is like giving instructions to
an idiot.
-- arcus, #scheme on Freenode

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-24 Пенетрантность Alexander Danilov

Artem Chuprina пишет:

ПК Кстати с чем мы сравниваем?

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

Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не флейма для, а
опыта
ради. Просто мне до сих пор встречались сложные случаи, но они были из разряда
лобовая атака, то есть если попытаться загнать в listbox несколько тысяч
строк,
то тормоза конечно будут, но виноват разработчик, а если переделать форму, то и
миллионы можно
увидеть, причём без особого напряжения.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-24 Пенетрантность Victor Wagner

On 2008.11.25 at 01:22:27 +0900, Alexander Danilov wrote:

Artem Chuprina пишет:

ПК Кстати с чем мы сравниваем?

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

Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не флейма для, а
опыта

На некоторых классах задач он проигрывает perl (в частности за счет
-wc и -T у последнего).

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

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-24 Пенетрантность Artem Chuprina

Alexander Danilov - debian-russian@lists.debian.org @ Tue, 25 Nov 2008
01:22:27 +0900:

ПК Кстати с чем мы сравниваем?

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

AD Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не
AD флейма для, а опыта ради. Просто мне до сих пор встречались
AD сложные случаи, но они были из разряда лобовая атака, то есть
AD если попытаться загнать в listbox несколько тысяч строк, то тормоза
AD конечно будут, но виноват разработчик, а если переделать форму, то
AD и миллионы можно увидеть, причём без особого напряжения.

Ну, например, поле ввода с дополнением по справочнику.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-23 Пенетрантность Stanislav Kruchinin

Alexander Danilov wrote:

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

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

Еще раз: открытые (или закрытые) исходные тексты не гарантируют качества
кода. Утверждение о том, что программы с открытыми исходными текстами по
определению более качественны -- это признак фанатизма. Есть масса примеров
хороших closed source программ, ставших образцами для подражания в open
source. Вспомните тот же BitKeeper, distributed VCS, по образу и подобию
которой были созданы Git, Mercurial и прочие.

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

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

Сам факт открытия исходников не приведет к их улучшению. Чтобы это произошло,
надо чтобы данный исходный текст заинтересовал человека более профессионального,
чем разработчики продукта. Никто не обещает, что это точно произойдет, как с
рецензируемой научной статьей, существует лишь некая вероятность. Ни в closed,
ни в open source нет механизма, заставляющего обеспечивать необходимое качество.
По большей части все зависит от самих исполнителей.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-23 Пенетрантность Alexander Danilov

Stanislav Kruchinin пишет:

Alexander Danilov wrote:

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

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

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

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

хороших closed source программ, ставших образцами для подражания в open
source. Вспомните тот же BitKeeper, distributed VCS, по образу и подобию
которой были созданы Git, Mercurial и прочие.

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

Такими темпами прилёт того дятла, что уничтожит цивилизацию, увидит даже моё
поколение.
Я уже давно склоняюсь к мысли, что надо выдавать лицензию, на право разработки ПО, ну и
использования его (в смысле допуск к компьютеру) в том числе.

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

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-22 Пенетрантность Alexander Danilov

Stanislav Kruchinin пишет:

Покотиленко Костик wrote:

К сожалению, мы в меньшинстве. И для многих задач альтернатив
gtk/qt-приложениям просто нет.

Самому написать без ошибок и так как хочется слабо?

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

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

обратная связь и обеспечение качества -- это основные проблемы. Никакой
дисциплины ума, каждый идиот мнит себя безгрешным творцом. Отвечать на
bug reports и feature requests словами don't cry, code -- это глупость
и свинство, по-моему.

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-22 Пенетрантность Stanislav Kruchinin

Alexander Danilov wrote:

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

Бред. Исходных код коммерческого продукта закрыт, и какие там глюки - никто
не знает.

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

Если недобросовестного(или дебила) коммерческого разработчика можно и
заставить что-то сделать - то только закрыть явно вылезший глюк, но как он

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

Вы как-то очень предвзято относитесь к коммерческим программистам. О
последствиях закрытия багов должны знать сами разработчики, если они понимают,
что делают. Опять же, это зависит от их профессионализма, а не от открытости
исходных текстов. В довольно сложных программных системах (Cisco IOS, JunOS)
постоянно находят и исправляют те или иные ошибки, и ничего, работают же.

Еще раз: открытые (или закрытые) исходные тексты не гарантируют качества кода.
Утверждение о том, что программы с открытыми исходными текстами по определению
более качественны -- это признак фанатизма. Есть масса примеров хороших closed
source программ, ставших образцами для подражания в open source. Вспомните тот
же BitKeeper, distributed VCS, по образу и подобию которой были созданы Git,
Mercurial и прочие.

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

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-22 Пенетрантность Alexander Danilov

Бред. Исходных код коммерческого продукта закрыт, и какие там глюки -
никто

не знает.

А для самих разработчиков коммерческого продукта код тоже закрыт? Глюки

Открыт, а толку? Ведь им ник то не скажет, что код - дерьмо.

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

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

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

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

Вы как-то очень предвзято относитесь к коммерческим программистам. О
последствиях закрытия багов должны знать сами разработчики, если они
понимают, что делают. Опять же, это зависит от их профессионализма, а не
от открытости исходных текстов. В довольно сложных программных системах
(Cisco IOS, JunOS) постоянно находят и исправляют те или иные ошибки, и
ничего, работают же.

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

Еще раз: открытые (или закрытые) исходные тексты не гарантируют качества
кода. Утверждение о том, что программы с открытыми исходными текстами по
определению более качественны -- это признак фанатизма. Есть масса
примеров хороших closed source программ, ставших образцами для
подражания в open source. Вспомните тот же BitKeeper, distributed VCS,
по образу и подобию которой были созданы Git, Mercurial и прочие.

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

Всегда есть возможность исправить собственными силами - то есть самому
или

нанять другого разработчика.

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

Значит это не те деньги.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-21 Пенетрантность Konstantin Matyukhin

2008/11/20 Stanislav Kruchinin [EMAIL PROTECTED]:
 Покотиленко Костик wrote:
 Отвечать на bug reports и feature requests словами
 don't cry, code -- это глупость и свинство, по-моему.
Don't cry, buy.

-- 
С уважением,
Константин Матюхин

Re: stderr

2008-11-21 Пенетрантность Victor Wagner

On 2008.11.20 at 23:17:05 +0300, Stanislav Kruchinin wrote:

Покотиленко Костик wrote:
К сожалению, мы в меньшинстве. И для многих задач альтернатив
gtk/qt-приложениям просто нет.

Самому написать без ошибок и так как хочется слабо?

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

Да не в тулкитах дело. Тулкитов-то полно. В приложениях.

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

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

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-21 Пенетрантность Иван Лох

On Fri, Nov 21, 2008 at 02:17:05PM +0300, Victor Wagner wrote:
Самому в одиночку написать целый тулкит, аналогичный по возможностям
тому, в который вложены десятки тысяч человеко-часов? Конечно слабо. А

Да не в тулкитах дело. Тулкитов-то полно. В приложениях.

Вы наверняка знаете как появился Gtk+ Люди писали The GIMP и им по целому
ряду причин потребовалось сделать с Motif нечто, что его коммерческая
лицензия не позволяла. И они написали свой тулкит (вдвоем). Если бы они
его начали писать сейчас, то стали бы писать по другому IMHO. А тогда
единственным свободным тулкитом была Athena (и, с оговорками Tk). И Gtk+
стал светом в темном царстве ;-} При всех его недостатках.

Первое, что надо написать заново - это, конечно, браузер. Беда в том,
что количество стандартов, которые при этом надо поддержать, совершенно

И количество нарушений стандарта...

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

Есть вещи которые понять невозможно. Например, то почему они не используют
libxml2 и libxslt а плодят свои немерянные глюки.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-21 Пенетрантность Victor Wagner

On 2008.11.21 at 15:20:38 +0300, Иван Лох wrote:

Думаю, что и с GUI у них было то же самое - не сумели understand,
и стали reinvent. Poorly.

Кстати, большая часть тех вкусностей, которая отличала Gtk времен
gimp 0.9 от современных ему тулкитов потом куда-то делась, задавленная
тяжестью Gnome HIG.
необозримо. И почему-то у обоих существующих движков (webkit и gecko)
архитектура через такой задний проход сделана, что даже в отрыве от тулкита
ими воспользоваться не получится.

Это я как раз могу понять. Начать с того, что оно libxml, а не libsgml.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-21 Пенетрантность Иван Лох

On Fri, Nov 21, 2008 at 03:56:51PM +0300, Victor Wagner wrote:
On 2008.11.21 at 15:20:38 +0300, Иван Лох wrote:

Они хоть понимали, что писать скриптер надо на схеме. Уже что-то. Теперь там
скриптер на перле наваляли.

Есть вещи которые понять невозможно. Например, то почему они не используют
libxml2 и libxslt а плодят свои немерянные глюки.
Это я как раз могу понять. Начать с того, что оно libxml, а не libsgml.
Ну так написали бы libsgml. Или использовали два разных парсера. js-engine
сумели же отделить. Зло не в том, что их творчество глючит, а в том, что оно
не reusable в большей части. Все в куче.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-21 Пенетрантность Victor Wagner

On 2008.11.21 at 16:25:16 +0300, Иван Лох wrote:
  Это я как раз могу понять. Начать с того, что  оно libxml, а не libsgml.
 Ну так написали бы libsgml. Или использовали два разных парсера. js-engine
 сумели же отделить. Зло не в том, что их творчество глючит, а в том, что оно
 не reusable в большей части. Все в куче. 

Ну в этом и действительно зло. Кстати, заметная часть претензий к Gtk -
тоже из этой серии. Оно немодульно, авторы многих gtk-изделий не
понимают где проходит граница между gtk и gnome etc.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-21 Пенетрантность Victor Wagner

On 2008.11.21 at 16:25:16 +0300, Иван Лох wrote:

Они хоть понимали, что писать скриптер надо на схеме. Уже что-то. Теперь там
скриптер на перле наваляли.

Не-а, не понимали. Им Столлман сказал, что Схема это круто, они и
поверили. Но так и не поняли ПОЧЕМУ Схема это круто. В результате все
испортили своей реализацией с неполноценной garbage collection. Поэтому
народ вместо того, чтобы массово переучиваться на схему стал писать
альтернативные скриптеры на перле, питоне etc.

Потому что нормально писать в функциональном стиле на языке без сборки
мусора невозможно.

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-21 Пенетрантность Покотиленко Костик

В Чтв, 20/11/2008 в 23:17 +0300, Stanislav Kruchinin пишет:
Покотиленко Костик wrote:
К сожалению, мы в меньшинстве. И для многих задач альтернатив
gtk/qt-приложениям просто нет.

Самому написать без ошибок и так как хочется слабо?

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

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

Отвечать на bug reports и feature requests словами don't cry, code
-- это глупость и свинство, по-моему.

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

--
Покотиленко Костик [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-21 Пенетрантность Покотиленко Костик

В Птн, 21/11/2008 в 15:56 +0300, Victor Wagner пишет:
On 2008.11.21 at 15:20:38 +0300, Иван Лох wrote:

Думаю, что и с GUI у них было то же самое - не сумели understand,
и стали reinvent. Poorly.

Сам GTK инструмент хороший, не без претензий конечно, НО тяжесть и
ресурсоёмкость програм - это следствие малого количества времени
затраченного разработчиками программ на ОПТИМИЗАЦИЮ.

К примеру, была задача организовать TreeView с ~4 миллиона строк и ~30
колонок, нужен был поиск. База в dbf ~3Гб. Представляю сколько памяти бы
зажрала прога и как бы она тупила если всё держать в TreeStore с
прокруткой и поиском. В итоге сделал поиск по индексу, а часть
результата помещался в TreeView, который был размером количества строк,
которое влазит на экран, прокрутка к TreeView не привязана, и при
прокрутке, сдвинутый список заливался в TreeStore.

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

--
Покотиленко Костик [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-21 Пенетрантность Artem Chuprina

Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 21 Nov 2008
22:23:11 +0200:

Думаю, что и с GUI у них было то же самое - не сумели understand,
и стали reinvent. Poorly.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-20 Пенетрантность Покотиленко Костик

В Срд, 19/11/2008 в 22:24 +0300, Victor Wagner пишет:
 On 2008.11.19 at 19:42:05 +0200, chaos wrote:
 
   Собственно злит больше всего имено это - то что в процессе якобы
   нормальной работы вываливаются сотни сообщений о программистских
   ошибках, которые в любом нормальном проекте были бы сочтены фатальными,
   и требующими исправления ASAP.
  
  Лично для меня подобные весёлости послужили просто ещё одним поводом 
  постепенно отказаться от GTK всех масте. Или хотя-бы свести их 
  использование 
  к минимуму.
 
 К сожалению, мы в меньшинстве. И для многих задач альтернатив
 gtk/qt-приложениям просто нет.

Самому написать без ошибок и так как хочется слабо?

-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-20 Пенетрантность Stanislav Kruchinin


Покотиленко Костик wrote:

К сожалению, мы в меньшинстве. И для многих задач альтернатив
gtk/qt-приложениям просто нет.


Самому написать без ошибок и так как хочется слабо?



Самому в одиночку написать целый тулкит, аналогичный по возможностям тому, в 
который вложены десятки тысяч человеко-часов? Конечно слабо. А разве кому-то 
нет? Нет уж, если вы поддерживаете продукт, то нужно отвечать за свои ошибки. С 
коммерческих программистов по крайней мере спросить за качество можно, они за 
это деньги получают, а в open source обратная связь и обеспечение качества -- 
это основные проблемы. Никакой дисциплины ума, каждый идиот мнит себя безгрешным 
творцом. Отвечать на bug reports и feature requests словами don't cry, code 
-- это глупость и свинство, по-моему.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

stderr

2008-11-19 Пенетрантность Иван Лох

On Tue, Nov 18, 2008 at 12:13:21PM +0300, Victor Wagner wrote:
Ублюдки, разрабатывающие Gtk почему-то обожают всякий хлам на stderr
писать. Хотя GUI-шная программа по хорошему счету туда ничего писать не
должна. Если проблема заслуживает внимания пользователя, надо выводить
диалоговое окно, если нет, то если пользователь специально не попросил,
вообще ругаться не надо.

Да ладно. Вот fvwm не смог иконку найти. Выкинули ее из пакета, а ссылка
прописана. Он, что должен message box вывести на пол экрана? Или, вообще,
проигнорировать? Оба варианта мне кажутся нелепыми. Или может быть надо ему
свой файл диагностики создать? Который потом ни за что не найдешь.

stderr лучшее место для ошибок и предупреждений. Его легко перенаправить,
он не грохнется вместе с приложением. Поэтому множество программ туда и пишет.
Предупреждения GTK и GDK стандартизованы. Неужели grep -v отменили?

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-19 Пенетрантность Victor Wagner

On 2008.11.19 at 18:42:44 +0300, Иван Лох wrote:

Да ладно. Вот fvwm не смог иконку найти. Выкинули ее из пакета, а ссылка
прописана. Он, что должен message box вывести на пол экрана? Или, вообще,

Должен. Может один message box со списком всех предупреждений,
выданных в процессе чтения конфига, но должен. Потому как непорядок.
А то в .xsession-error юзер не заглянет до тех пор, пока жареный петух
куда-нибудь не клюнет.

проигнорировать? Оба варианта мне кажутся нелепыми. Или может быть надо ему
свой файл диагностики создать? Который потом ни за что не найдешь.

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

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

Только для программы, имеющей управляющий терминал. Для демона - syslog.
А для gui - ну в gui и надо показывать.

он не грохнется вместе с приложением. Поэтому множество программ туда и пишет.
Предупреждения GTK и GDK стандартизованы. Неужели grep -v отменили?

Предупреждения GTK и GDK иногда забивают нахрен свободное место на
диске. Например, с Gimp такое случалось.

И вообще, когда программа просто в процессе визуализации выводит 20
сообщений вида bla-bla-bla ASSERTION FAILED - что это программа делает в
дистрибутиве??!! Тем более в stable?

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

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-19 Пенетрантность Artem Chuprina

Victor Wagner - debian-russian@lists.debian.org @ Wed, 19 Nov 2008 19:06:25
+0300:

Ублюдки, разрабатывающие Gtk почему-то обожают всякий хлам на stderr
писать. Хотя GUI-шная программа по хорошему счету туда ничего писать не
должна. Если проблема заслуживает внимания пользователя, надо выводить
диалоговое окно, если нет, то если пользователь специально не попросил,
вообще ругаться не надо.

VW Должен. Может один message box со списком всех предупреждений,
VW выданных в процессе чтения конфига, но должен. Потому как непорядок.
VW А то в .xsession-error юзер не заглянет до тех пор, пока жареный петух
VW куда-нибудь не клюнет.

Меня устраивает нынешнее поведение.

VW Файл диагностики для интерактивной программы должен включаться только по
VW явной просьбе пользователя. Когда он собрался багу ловить и багрепорт
VW писать.

Бат хау? Особенно если она вызывается через менюшку или просто
запускается при логине, как ssh-agent или gpg-agent (да, они, блин,
интерактивны - в том смысле, что умеют вывести пользователю запрос
пассфразы)?

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

VW Только для программы, имеющей управляющий терминал. Для демона - syslog.
VW А для gui - ну в gui и надо показывать.

Нихачу.

VW И вообще, когда программа просто в процессе визуализации выводит 20
VW сообщений вида bla-bla-bla ASSERTION FAILED - что это программа
VW делает в дистрибутиве??!! Тем более в stable?

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

Ну вот как раз повод писать матерный багрепорт.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Психология - это наука о плохих контактах (С)энта

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: stderr

2008-11-19 Пенетрантность chaos

В сообщении от 19 ноября 2008 18:06 Victor Wagner написал(a):

 Предупреждения GTK и GDK иногда забивают нахрен свободное место на
 диске. Например, с Gimp такое случалось.

 И вообще, когда программа просто в процессе визуализации выводит 20
 сообщений вида bla-bla-bla ASSERTION FAILED - что это программа делает в
 дистрибутиве??!! Тем более в stable?

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

Лично для меня подобные весёлости послужили просто ещё одним поводом 
постепенно отказаться от GTK всех масте. Или хотя-бы свести их использование 
к минимуму.

-- 
Куда не влекут способности, туда не толкай.
-- Я.Коменский

Re: stderr

2008-11-19 Пенетрантность chaos

В сообщении от 19 ноября 2008 18:29 Artem Chuprina написал(a):

  VW Только для программы, имеющей управляющий терминал. Для демона -
 syslog. VW А  для gui - ну в gui и надо показывать.

 Нихачу.

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

-- 
В свои 20 лет он знал 9 операционных систем и ни одной женщины.

Re: stderr

2008-11-19 Пенетрантность Victor Wagner

On 2008.11.19 at 19:42:05 +0200, chaos wrote:

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

К сожалению, мы в меньшинстве. И для многих задач альтернатив
gtk/qt-приложениям просто нет.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: перенаправление stderr в tcsh

2002-07-15 Пенетрантность darkman

On Fri, 12 Jul 2002, Anton I. Karpov wrote:

 Добрый день.

 В bash перенаправление stderr делается при помощи 2куда_надо
 А вот с tcsh пока разобраться не могу. Никто не пробовал?

Судя по ману отдельно stderr нельзя, :-(((
а вот stdout+stderr - 

-- 
   Alexandr Darkman
---
ISP IC Group, Chief System Administrator, ADL220-RIPE


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÅ stderr × tcsh

2002-07-13 Пенетрантность Anton I. Karpov

Добрый день, [EMAIL PROTECTED]

В ответ на ваше сообщение от 6:21 13.07.2002 
по теме: перенаправление stderr в tcsh было написано: 
OPP Найди статью Tom Christiansen Why shouldn't I program in csh?
OPP It is available for anon FTP from convex.com in /pub/csh.whynot

Сервер есть, статьи нет.

OPP Там заодно и ответ на вопрос найдёшь.

Сам разобрался. Все не так страшно, как описывалось в некоторых доках
по bash.

-- 
Anton I. Karpov
e-mail: [EMAIL PROTECTED]
icq:27857813


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÅ stderr × tcsh

2002-07-12 Пенетрантность Anton I. Karpov

Добрый день.

В bash перенаправление stderr делается при помощи 2куда_надо
А вот с tcsh пока разобраться не могу. Никто не пробовал?

-- 
Anton I. Karpov
e-mail: [EMAIL PROTECTED]
icq:27857813


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

59 matches

Mail list logo