Здравствуйте, dr.Chaos, Вы писали:

G>>WinForms и WPF не для одного и того же. Хотя сходные задачи на них вполне можно решать.
DC>Т.е. таки нет одной православной всеми любимой библиотеки которые все используют и все довольны?
Ну такого вообще не бывает. Разные задачи — разные быблиотеки. И часто бывает так что частично пересекаются по функционалу.

G>>>>До сих пор в линуксе нету нормальной компонентной модели (как COM в винде), до сих пор везде велосипеды.
DC>>>До D-Bus-а COM-у как раком до Москвы.
G>>Ну и где этот DBus?
DC>Не поверишь — везде. А если серьёзено на него опираются все современные решения.
Я как-то не эксперт по решениям на Linux, можешь парочку известных привести и как они на DBus опираются.

G>>"как правило почти идентичны" — без комментариев.
DC>Т.е. возражений нет?
У меня нет, а вот фраза в кавычках выше как раз и является доказательством "велосипедности" конфигов многих программ под *nix

Здравствуйте, fddima, Вы писали:

F>Здравствуйте, Demandred, Вы писали:

D>>Ну вот тут ты не совсем прав. Программу под net1 использующую WinForms, не так то просто пересобирать под net3.
D>>Мы как то с нет1.1 переводили проэкты на нет2.0. Много чего переписывать пришлось.
F> А мне мало что переписывать пришлось. Небольшие правки и всё, и то 99% из них — только что бы избавиться от варнингов.

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

Здравствуйте, gandjustas, Вы писали:

G>>>Например библиотеки обработки изображений.
C>>К примеру?
G>Ну сам нагугли.
К примеру?

C>>DBUS, который сейчас стал стандартом для шин сообщений. И он НАМНОГО удобнее того, что есть в COMе.
G>Ну в COM вообще нету шины сообщений. Можно MSMQ для этого использовать.
G>Я говорю именно про компонентный подход.
А что, COM — это единственный вариант для компонентного подхода?

C>>Как раз CORBA — это международный стандарт, вообще-то.
G>И где этот стандарт? Его что-то подозрительно мало поддерживают, слегка устарел он.
Так COM уже давно deprecated.

C>>В Линуксе есть augeas, который лёгким движением руки превращает почти любой конфиг в красивое DOM-дерево.
G>Да нет, меня как раз обратная операция интересует — из красивого дерева в "почти любой конфиг". Чтобы они также красиво выглядел, а то админ полезет в текст конфига и умрет от ужаса.
Не умрёт. Они обычно интуитивно понятны, да ещё и с комментариями.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:

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

C>>>DBUS, который сейчас стал стандартом для шин сообщений. И он НАМНОГО удобнее того, что есть в COMе.
G>>Ну в COM вообще нету шины сообщений. Можно MSMQ для этого использовать.
G>>Я говорю именно про компонентный подход.
C>А что, COM — это единственный вариант для компонентного подхода?
Да вот и не знаю даже.

C>>>Как раз CORBA — это международный стандарт, вообще-то.
G>>И где этот стандарт? Его что-то подозрительно мало поддерживают, слегка устарел он.
C>Так COM уже давно deprecated.
И что? Используется он поактивнее того же CORBA.

Здравствуйте, gandjustas, Вы писали:

G>>>Ну в COM вообще нету шины сообщений. Можно MSMQ для этого использовать.
G>>>Я говорю именно про компонентный подход.
C>>А что, COM — это единственный вариант для компонентного подхода?
G>Да вот и не знаю даже.
Вот именно. DBUS сейчас де-факто стал стандартом для локального RPC. Причём он настолько гибкий, что используется на всём — от сотовых телефонов (Palm Pre, Nokia N900) до суперкомпьютеров.

G>>>И где этот стандарт? Его что-то подозрительно мало поддерживают, слегка устарел он.
C>>Так COM уже давно deprecated.
G>И что? Используется он поактивнее того же CORBA.
И что? DBUS зато развивается и его _удобно_ использовать.

Здравствуйте, Sheridan, Вы писали:
g>> И самое смешное — конфиги. Каждая программа имеет свой формат и свой парсер.
S>Формата всего два: xml и option=value. Причем второй намногочаще встречается. Исключения конечно есть, но они оправданы.
Угу. Понятно. И как у нас устроено это value? Ну, то есть я догадываюсь, что, к примеру, числа скорее всего представляются в десятичной нотации, но не удивлюсь, если большинство (но не все) то софты поддерживают восьмеричную и шестнадцатиричную нотации.
Также догадываюсь, что в некоторых конфигах есть поддержка переноса длинного value на другую строку, в других — нет. В некоторых от порядка option ничего не зависит; в других — будет зависимость.
А вот как, к примеру, должна записываться дата — ума не приложу. Каким из озарённых стандартами вариантов будет пользоваться программа X?

Так что формат конфига — штука непонятная.

Здравствуйте, Sinclair, Вы писали:

S>Так что формат конфига — штука непонятная.
И наконец в какой он кодировке — тоже совершенно неясно.

Здравствуйте, gandjustas, Вы писали:

G>Ну такого вообще не бывает. Разные задачи — разные быблиотеки. И часто бывает так что частично пересекаются по функционалу.
Ну так и зоопарк "велосипедов" в итоге везде и вызван он вовсе не особенностями Винды/Юниха/Линуха.

G>Я как-то не эксперт по решениям на Linux, можешь парочку известных привести и как они на DBus опираются.
Используют его как RPC, при чём это позволяет регулировать права доступа используя PolicyKit. Используется действительно повсеместно, т.к. он прост, быстр и удобен.

G>У меня нет, а вот фраза в кавычках выше как раз и является доказательством "велосипедности" конфигов многих программ под *nix

А смысл добавлять в парсер возможность работать с вещественными числами в E+ записи, если я их никогда не планирую записывать? Кроме того конфиги изобилуют комментариями и примерами, и рассчитаны на то, что будут читаться человеком. Кроме того, почему парсеры должны быть идентичными? Ну сбацать для такого парсера грамматику для lex/yacc дело вообще минутное. Какой-то пример ИМХО надуманный. Кроме того есть спец тулзы типа augeas.

Здравствуйте, Sinclair, Вы писали:

S>>Формата всего два: xml и option=value. Причем второй намногочаще встречается. Исключения конечно есть, но они оправданы.
S>Угу. Понятно. И как у нас устроено это value? Ну, то есть я догадываюсь, что, к примеру, числа скорее всего представляются в десятичной нотации, но не удивлюсь, если большинство (но не все) то софты поддерживают восьмеричную и шестнадцатиричную нотации.
Хм. А зачем тебе шестнадцатеричные числа в конфигах в любом месте?

S>Также догадываюсь, что в некоторых конфигах есть поддержка переноса длинного value на другую строку, в других — нет. В некоторых от порядка option ничего не зависит; в других — будет зависимость.
S>А вот как, к примеру, должна записываться дата — ума не приложу. Каким из озарённых стандартами вариантов будет пользоваться программа X?
S>Так что формат конфига — штука непонятная.
Так на _практике_ (которая от теории отличается) проблем с форматом конфигов не возникает. А если нужно ими нестандартно программно манипулировать — берём augeas и не мучаемся. На нём, кстати, будет построена следующая версия RedHat'овских тулзов для менеджмента.

Здравствуйте, Cyberax, Вы писали:

C>В Линуксе есть augeas, который лёгким движением руки превращает почти любой конфиг в красивое DOM-дерево.

Интересная штука, спасибо.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Demandred, вы писали:

D>> S>Чем проще реализация, тем больше клонов — это верно для любой оси.
D>> S>И зачастую функционал не одинавков, а похож.

D>> Это велосипеды...
D>> Там только недоделки и глюки разные, а функционал почти идентичен
S>Примеры?

Да любой линукс софт возьми, куча аналогов и ни один не доделан...

D>> D>> А сколько из этих поделок доведены до нормального уровня качества?
D>> S>Я не знаю что ты считаешь "нормальным" уровнем качества. Меня например устраивает все.
D>> Для голодного негра и буханка хлеба лучшая еда в мире
S>Ты так и не сказал ничего про свое определение нормальности.
S>Я слушаю.

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

D>> D>> S>Приведи примеры. А также погугли по кейвордам bugtrack, patch и diff
D>> D>> И что? Выводит кучу ссылок и ни одной по теме.
D>> S>Выводит кучу ссылок на багтраки к софту, в которых народ помогает решать баги. Что опровергает твое утверждение "...мнит себя гением и переписывает весь софт..."
D>> Хорошо, не все, но многие так делают.
S>Приведи примеры форкания активно развивающихся проектов с отзывчивыми авторами.
S>Форкаются лишь те проекты, которые забросили, либо авторы которых забивают на все претензии.

Это поэтому полно разных KDE, гномов и тому подобного, на что там авторы забили?

Здравствуйте, Cyberax, Вы писали:

C>>>Как раз CORBA — это международный стандарт, вообще-то.
G>>И где этот стандарт? Его что-то подозрительно мало поддерживают, слегка устарел он.
C>Так COM уже давно deprecated.

Кто тебе сказал?

Здравствуйте, hattab, Вы писали:

C>>>>Как раз CORBA — это международный стандарт, вообще-то.
G>>>И где этот стандарт? Его что-то подозрительно мало поддерживают, слегка устарел он.
C>>Так COM уже давно deprecated.
H>Кто тебе сказал?
Microsoft, ещё несколько лет назад

Здравствуйте, dr.Chaos, Вы писали:

G>>Я как-то не эксперт по решениям на Linux, можешь парочку известных привести и как они на DBus опираются.
DC>Используют его как RPC, при чём это позволяет регулировать права доступа используя PolicyKit. Используется действительно повсеместно, т.к. он прост, быстр и удобен.

Где конкретно используют?А то ты уже в 5 раз на этот вопрос пространными фразами типа "Используется действительно повсеместно" отвечаешь.
Повсеместно это где? Названия систем?

G>>У меня нет, а вот фраза в кавычках выше как раз и является доказательством "велосипедности" конфигов многих программ под *nix

DC>А смысл добавлять в парсер возможность работать с вещественными числами в E+ записи, если я их никогда не планирую записывать? Кроме того конфиги изобилуют комментариями и примерами, и рассчитаны на то, что будут читаться человеком. Кроме того, почему парсеры должны быть идентичными? Ну сбацать для такого парсера грамматику для lex/yacc дело вообще минутное. Какой-то пример ИМХО надуманный. Кроме того есть спец тулзы типа augeas.

Вот всем заняться нечем бацать для такого парсера грамматику для lex/yacc

Здравствуйте, Cyberax, Вы писали:

C>>>Так COM уже давно deprecated.
H>>Кто тебе сказал?
C>Microsoft, ещё несколько лет назад

Пошутили они

C> S>Также догадываюсь, что в некоторых конфигах есть поддержка переноса длинного value на другую строку, в других — нет. В некоторых от порядка option ничего не зависит; в других — будет зависимость.
C> S>А вот как, к примеру, должна записываться дата — ума не приложу. Каким из озарённых стандартами вариантов будет пользоваться программа X?
C> S>Так что формат конфига — штука непонятная.

C> Так на _практике_ (которая от теории отличается) проблем с форматом конфигов не возникает. А если нужно ими нестандартно программно манипулировать — берём augeas и не мучаемся. На нём, кстати, будет построена следующая версия RedHat'овских тулзов для менеджмента.

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

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

Здравствуйте, Mamut, Вы писали:

C>> Так на _практике_ (которая от теории отличается) проблем с форматом конфигов не возникает. А если нужно ими нестандартно программно манипулировать — берём augeas и не мучаемся. На нём, кстати, будет построена следующая версия RedHat'овских тулзов для менеджмента.
M>На практике возникают проблемы с тем, что для каждого конфига приходится заново выучивать формат этого конфига. Которые могут быть очень похожи, но при этом отличаться в досадных мелочах.
Можешь вспомнить, когда оно в последний раз тебе доставило проблем больше, чем на пару минут RTFMа?

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

Здравствуйте, Demandred, Вы писали:

D>Где конкретно используют?А то ты уже в 5 раз на этот вопрос пространными фразами типа "Используется действительно повсеместно" отвечаешь.
D>Повсеместно это где? Названия систем?

Зайди на FreeDesktop.org и почитай, сколько их новых технологий на нём основанно, и сколько сторонних проектов его используют.

D>Вот всем заняться нечем бацать для такого парсера грамматику для lex/yacc
Хм.. А тебя кто-то заставляет?

C> А смысл добавлять в парсер возможность работать с вещественными числами в E+ записи, если я их никогда не планирую записывать? Кроме того конфиги изобилуют комментариями и примерами, и рассчитаны на то, что будут читаться человеком. Кроме того, почему парсеры должны быть идентичными? Ну сбацать для такого парсера грамматику для lex/yacc дело вообще минутное. Какой-то пример ИМХО надуманный. Кроме того есть спец тулзы типа augeas.

Потому что единый API. Потому что не надо каждый раз изобретать новый парсер только для себя. Потому что 90% конфигов в любом случае предсавляют собой пары ключ-значение, иногда во вложеных друг в друга блоках. Для оставшихся нестандартных конфигов можно и свой парсер написать

C> C>> Так на _практике_ (которая от теории отличается) проблем с форматом конфигов не возникает. А если нужно ими нестандартно программно манипулировать — берём augeas и не мучаемся. На нём, кстати, будет построена следующая версия RedHat'овских тулзов для менеджмента.

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

C> Можешь вспомнить, когда оно в последний раз тебе доставило проблем больше, чем на пару минут RTFMа?

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


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

C> Ну так обычный XML, какие проблемы-то?

Почему такого нет в Линуксах? Это, помимо удобства администраторам, было бы удобно и девелоперам тоже — потому что унифицированый API лучше, чем каждый раз придумывать парсер для собственного формата.