Вышел XYZCommander 0.0.3 (http://xyzcmd.syhpoon.name/), третий релиз нового консольного файлового менеджера для *nix систем, написаного на языке Python и, кроме библиотеки urwid (http://excess.org/urwid/), не использующего внешних зависимостей. Исходные тексты проекта распространяются в рамках лицензии LGPL.
<img src="http://www.opennet.me/opennews/pics_base/25038_1263762022.jp... align=right></img>Основные возможности:
- Интеграция с Python окружением: настройки приложения можно менять "на лету" через консоль управления; все конфигурационные файлы представляют собой скрипты на языке Python, для упрощения используется специальный набор конфигурационных функций;
- С помощью системы конфигурирования можно настраивать собственные действия, переопределять операции (alias), создавать внутренние команды, а также изменять управляющие комбинации клавиш;
- Система плагинов позволяет расширять функциональность без модификации ядра приложения;
- Возможность создавать собственные фун...URL: http://xyzcmd.syhpoon.name/
Новость: http://www.opennet.me/opennews/art.shtml?num=25038
>все конфигурационные файлы представляют собой скрипты на языке PythonКто придумал, что это удобно? Давайте уж тогда вообще без конфигурационных файлов - вон исходники, правь если хочешь.
Ну почему же, для этого были специальные функции, упрощающие конфигурирование. Настолько уж непонятна строка типа, let("skin", "seablue", sect="xyz") ? Это ж вам не хаскель.
>Ну почему же, для этого были специальные функции, упрощающие конфигурирование. Настолько уж
>непонятна строка типа, let("skin", "seablue", sect="xyz") ? Это ж вам
>не хаскель.для этого были *созданы* специальные функции
>Настолько уж непонятна строка типа, let("skin", "seablue", sect="xyz")Дело не столько в непонятности, сколько в удобстве.
[xyz]
skin = seablue
Гораздо наглядней и никаких лишних знаков. Но главное, рано или поздно такие "конфигурационные файлы" превращаются в полноценные скрипты вида if (mode = i) let("skin", skins[i].get()). И чем тогда конф. файл отличается от исходников? Хватит, уже и так сплошные shell-скрипты в /etc.
Вообще изначально так и было, формат только другой, соорудил кучу парсеров. Но по мере развития проекта оказалось что изначально запланированной их функциональности недостаточно, вот и стал перелезать на подобие eDSL. Писать парсер на все случаи жизни тоже смысла не видел, кроме того, питоновые скрипты позволили организовать безболезненное изменение настроек на ходу.
>питоновые скрипты позволили организовать безболезненное изменение настроек на ходу.Осталось понять, конфигурационные файлы - они для пользователя или для автора?
Пользователи, не способные разобраться в несложном конфиге в целевую аудиторию не входили.
>Пользователи, не способные разобраться в несложном конфиге в целевую аудиторию не входили.ага, в целевую аудиторию, значит, входили хомячки, не осилившие shell!
>ага, в целевую аудиторию, значит, входили хомячки, не осилившие shell!Разработчик, что либо осиливший, волен выбирать сам целевую аудиторию по своему желанию или настроению. Никто не запрещает делать что-то полезное для аудитории, которой труднее что-либо осиливать.
В этом и преслесть творчества, что сам решаешь, для кого и что делать. А тем, у кого с осиливанием проблемы, например шелл осилить могут, а вот самостоятельно более-менее полезное творение создать, уже не осиливают, - тем приходится все время ждать, кто же для них наконец захочет что-либо сделать. Не говоря уже о тех, кто даже шелл и конфиги осилить не могут.
Вы наверно уже забыли, про курсы для бухгалтеров под DOS.
Где обязательным пунктом были уроки РАБОТЫ с Norton CommanderНе будет юзер, да и программер тоже, ни хрена делать... Своих проблем хватает.
Что именно они не будут делать?
И каких именно из юзеров вы имеете в виду? Тут речь шла о разных категориях юзеров.И вообще, при чем здесь DOS и Norton Commander?
Вы считаете, что если для конфигурационных файлов непременно не создать специальный язык, то они по-вашему никак не могут быть "для пользователя"?Чтобы подобное утверждать, вам нужно вначале доказать, что конструкции, используемые в конфигурационных файлах.
> И чем тогда конф. файл отличается от исходников?
А почему, собственно конф файлы непременно должны отличаться от исходников. Вы видимо просто плохо представляете, что такое вообще формальные языки, если видите принципиальные различия. И находитесь просто под влиянием каких-то стереотипов, сильно ограничивающих ваше мышление.
Кроме того, ответ находится в вашей же собственной фразе. "Тупые" и примитивные конф файлы обычно делаются, когда именно хотят скрыть от пользователя ИСХОДНИКИ. И когда хотят ограничить пользователя в возможностях настройки, чтобы они по каждому случаю платили разработчикам. А это опенсурс. "Сурс" - это как раз "исходники" по аглицки, если вы не знаете.
> Осталось понять, конфигурационные файлы - они для пользователя или для автора?
И наконец. Что мешает автору делать программу для себя? Кто в его проекте главный? Абстрактный пользователь или сам автор? Или может быть такой горе-критик, как вы?
Значит у автора получилась вот такая вот библиотека для файлового менеджера. И не просто шаблонный файловый менеджер. И то, что ему удалось обойтись минимумом зависимостей, это только огромные плюсы.
В творчестве правил нет.
Проекты, в которых авторы слишком стараются все подряд угодить в ущерб свой собственной индивидуальности и собственному творческому началу, неизбежно утрачивают качество и выраждаются в тупую кучу функционала, которая формируется исключительно под влиянием рынка.
>> Чтобы подобное утверждать, вам нужно вначале доказать, что конструкции, используемые в конфигурационных файлах.... Что эти конструкции никак нельзя использовать для конфигурации.
>> Гораздо наглядней и никаких лишних знаков. Но главное, рано или поздно такие "конфигурационные файлы" превращаются в полноценные скрипты вида if (mode = i) let("skin", skins[i].get()). И чем тогда конф. файл отличается от исходников? Хватит, уже и так сплошные shell-скрипты в /etc.Превращаются в ПОЛНОЦЕННЫЕ скрипты, говорите? Какой ужас! Этого никак нельзя допускать!
А вообще вам лучше в Виндовс. Там не то что "полноценные", там даже НЕ"полноценные" скрипты считаются признаком дурного тона. Там все мышкой настраивать приходится в основном. Представляете, какое достижение прогресса!
А для чуть более сообразительных там есть такое чудо - Total Commander. Там действительно конф файлы настоящие и правильные, как и положено.
И чтобы хоть немного расширить функционал с помощью такого гениального изобретения, как плагины, там придется написать такое количество ИСХОДНИКОВ, что сразу становится понятно, чем же "правильные" конф файлы должны отличаться от "полноценных" исходников.
Осюда вывод. Основное назначение конфигурационных файлов - это не вызывать комплексы НЕПОЛНОЦЕННОСТИ у пользователей, при попытке настраивать программу. И вообще желательно, чтобы они отбивали само желание ее настраивать без привлечения разработчика. А сама настройка должна производиться исключительно с помощью "полноценных" исходников.
>вам лучше в Виндовс
>горе-критик
>находитесь просто под влиянием каких-то стереотипов, сильно ограничивающих ваше мышлениеКажется я наступил кому-то на больную мозоль.
>Вы видимо просто плохо представляете, что такое вообще формальные языки, если видите принципиальные различия.
Ага, то есть с тезисом, что такие конфигурационные файлы = исходники Вы уже согласны? Тогда не надо их называть конфигурационными файлами, вот и всё.
"Моя программа опен-сурс, писал для себя, кому надо - ковыряйтесь в исходниках". Что ж, такая позиция имеет право на жизнь, хотя это похоже на раздачу хлама бездомным.
Да ради Бога, никто ж не заставляет пользоваться ;)
Кому будет интересно, тот разберётся в конфигах.
>Да ради Бога, никто ж не заставляет пользоваться ;)
>Кому будет интересно, тот разберётся в конфигах.Или найдет что-то более соответствующее своим хотелкам, и это будет чаще.
>Кажется я наступил кому-то на больную мозоль.И кому же по-вашему мнению больнее? Хотите сказать мне? Ну пускай будет так, если вам от этого станет легче.
>>Вы видимо просто плохо представляете, что такое вообще формальные языки, если видите принципиальные различия.
>
>Ага, то есть с тезисом, что такие конфигурационные файлы = исходники Вы уже согласны? Тогда не надо их называть конфигурационными файлами, вот и всё.Вы утверждали и утверждаете, что конфы никак нельзя считать исходниками. Я спросил вас почему их нельзя считать исходниками? И даже дал вам кое-какие подсказки. Из которых вам удалось сделать единственный вывод, что якобы по-вашему я заявлял о "равенстве" того и другого.
Или что вы подразумевали под отношением "="? Может быть что-то другое? Возникает предположение, что вы не только не понимаете, что такое формальные языки, и в частности, что такое исходники, но и плохо представляете, что же такое равенство. Или что вы там имели в виду.
Ах ну да, вы же защищаете интересы "обычных" пользователей. К которым видимо и себя самого относите. С вашей нелюбовью к "полноценным скриптам", как вы сами выразились.
Так вот. Умение пользоваться формальными языками (хоть конфами, хоть скриптами) - это тоже определенный пользовательский уровень. Хотя бы даже умение в них ориентироваться на интуитивном уровне, не обязательно знать какие-то там теории.
Есть например пользователи, которые вообще мышкой не могут научиться никак пользоваться и в окошках и кнопках постоянно путаются, не то что в каких-то файлах и языках. Вам уже много раз сказали, что этот проект предназначен для более способных пользователей, а вы все продолжаете доказывать что-то.
>"Моя программа опен-сурс, писал для себя, кому надо - ковыряйтесь в исходниках".
>Что ж, такая позиция имеет право на жизнь, хотя это похоже на раздачу хлама бездомным.Ковыряться в исходниках или не ковыряться - это вообще зависит от качества самих исходником. А не от того, как они называются. Или вы не видели таких конфов, в которых тоже приходится ковыряться, но которые при этом не считаются "полноценными скриптами" (в вашем понимании). Скорее всего не видели, потому что судя по всему вы пользуетесь софтом только с тривиальными конфами, за которые вы так и радеете.
Хотя если, как мы это выяснили, вы толком не представляете ни что такое исходники, ни что такое равенство, можно вообще сделать вывод, что вы плохо представляете то, о чем сами говорите и что пытаетесь доказать.
>"Моя программа опен-сурс, писал для себя, кому надо - ковыряйтесь в исходниках".
>Что ж, такая позиция имеет право на жизнь, хотя это похоже на раздачу хлама бездомным.По крайней мере становится понятна ваша позиция.
Вы "опенсурс" считаете "раздачей хлама бездомным" только потому, что боитесь, что вам придется "ковыряться" в чем-то чуть более абстрактном, чем кнопки на экране или тривиальные конфиги.И это видимо один из основных ваших критериев в оченке полезности софта, хоть свободного, хоть проприетарного.
Человек просто заблудился или просто пришел потролить, ибо
>>>"Моя программа опен-сурс, писал для себя, кому надо - ковыряйтесь в исходниках".Это фундаментальный принцип СПО.
>Вы "опенсурс" считаете "раздачей хлама бездомным"Я не говорил про весь опенсурс. Только про то, что "на тебе, Боже, что мне негоже".
>И это видимо один из основных ваших критериев в оченке полезности софта
И это видимо один из основных моих критериев в оценке УДОБСТВА софта.
Вообще, такое чувство что в дискусии участвуют трое - я, Вы и ещё некто в Вашем воображении, чьи слова и качества Вы мне постоянно пытаетесь приписать.
>>Вы "опенсурс" считаете "раздачей хлама бездомным"
>
>Я не говорил про весь опенсурс. Только про то, что "на тебе, Боже, что мне негоже".Хм. Вот точно те слова, где вы это говорили.
>"Моя программа опен-сурс, писал для себя, кому надо - ковыряйтесь в исходниках". Что ж, такая позиция имеет право на жизнь, хотя это похоже на раздачу хлама бездомным.
Сначала вы формулируете это как "писал для себя" а потом вдруг "что мне негоже". Т.е. уже как минимум вы противоречите сами себе.
А если не как минимум, то тут наблюдается очередное подтверждение того, что вы не понимаете сами, о чем говорите.
Вот, например, сравните простую формулировку, до которой вы так и не додумались.
Конфигурационные файлы - это такие файлы, которые хранят конфигурацию.
Все очень просто. Язык, формат, сложность конфигурации - это все параллельные понятия. Например, в Мозилле конфигурационных файлов куча, в разных форматах. И текстовые, и бинарные. Так что сами разработчики с трудом разбираются. Хорошо это или плохо - другой вопрос. Факт в том, что все это самые настоящие конфигурационные файлы по определению.
А теперь почитайте, что вы сами пишете о конфигурационных файлах. Чего только не написали, но до такой простой сути, то конфы - это всего лишь файлы хранящие конфигурацию, каким угодно способом, для кого и для чего угодно, вы до этого додуматься никак не смогли.
Вот я вам сразу и сказал, что вы плохо понимаете, о чем сами говорите. Будете снова пытаться утверждать, что это не так?
Потом, что вы написали про исходники. Попробуйте сформулировать, что вы понимаете под исходниками. Наверняка снова запутаетесь.
А раз вы не понимаете, что такое исходники, т.е. эти самые "сурсы", то как вы понимаете, что такое "Опенсурс"?
О чем собственно вся и речь. И вся изначальная суть ваших претензий в том, что вам просто что-то не удобно. И пытаетесь вывести из вашего неудобства, что это якобы вообще не правильно, что вам неудобно. И еще возмущаетесь, что вам порекомендовали пользоваться Виндами.
>И это видимо один из основных моих критериев в оценке УДОБСТВА софта.
То что вам все это УДОБНО, именно так, как вы написали, это и так всем понятно.
Но понимаете, есть люди, которым удобнее по-другому, не так, как вам. Например им удобнее "полноценные скрипты", как вы сами выразились. Вот именно для них и сделан данный проект. Вам же уже это не первый раз объясняли. А вам видимо подойдет что-то другое. И в чем суть ваших претензий? Что существует нечто, удобное другим, но неудобное вам?
>Вообще, такое чувство что в дискусии участвуют трое - я, Вы и ещё некто в Вашем воображении, чьи слова и качества Вы мне постоянно пытаетесь приписать.
Какие это я слова вам приписывал, если вы сами все сказали? Я всего лишь делаю выводы из ваших слов. Имею полное право.
>>> Чтобы подобное утверждать, вам нужно вначале доказать, что конструкции, используемые в конфигурационных файлах.
>... Что эти конструкции никак нельзя использовать для конфигурации.Легко - В конфигурационных файлах НЕ ДОЛЖНО быть : переменных, условных выражений, ветвлений и неопределённости.
Только константы. А = 1, B = 2, С = "ABC", D = 3.14159265, всё!!!Логика работы и взаимодействие между системой и человеком есть суть - программа.
>Легко - В конфигурационных файлах НЕ ДОЛЖНО быть : переменных, условных выражений,
> ветвлений и неопределённости.
>Только константы. А = 1, B = 2, С = "ABC", D = 3.14159265, всё!!!Слишком однобоко. Конфиг может иметь и условные выражения и переменные, но при этом не быть программой.
Пример на пальцах.
dbname = "dbase"
if hostname == "home":
host = "localhost"
else:
host = "db.example.org"dsn = "postgresql://project@" + host + "/" + dbname
В этом языке есть... эээ... ну, скажем так, и переменные (правда, задаваемые только раз, как в pure functional языках, я глупый и забыл правильное слово). Есть ветвления и простые операторы (==, !=, <, >, and, or и not). Есть оператор конкатенации строк и простые арифметические операторы. Но это не программа (в полноценном смысле).
Такой конфиг можно разобрать программно и преобразовать как вздумается. Про него всегда известно как и в каких случаях он что будет делать, он всегда может быть вычислен (не зациклится, ничего), всегда можно проверить что он возвращает правильные значения и т.д..
Но не дай Его Макароннешейство, кто-то добавит в этот конфиг команду goto или функции и возможность их использовать (и рекурсивно вызывать)...
Но, да, есть такое правило: http://en.wikipedia.org/wiki/Rule_of_Least_Power
И вот оно имеет суть что все эти if'ы и прочие операторы и навороты нужны только если они и правда _действительно_ нужны. А не просто «чтобы круто было». Если можно обойтись более простым языком — нужно использовать его.
Да что им объяснять. Люди в принципе не понимают, что такое формальные языки и формальные системы. Вы им еще краткий курс лямбда-исчисления и комбинаторной логики прочитайте.Просто находятся под влиянием своих стереотипов на основе своих познаний каких-то частных случаев. И думают, что известные им реализации - это единственно возможные и единственно применимые.
Еще один...>> Чтобы подобное утверждать, вам нужно вначале доказать, что конструкции, используемые в конфигурационных файлах, <...> никак нельзя использовать для конфигурации.
>Легко - В конфигурационных файлах НЕ ДОЛЖНО быть : переменных, условных выражений, ветвлений и неопределённости.Это что? Новый закон? Закон pavlinux'а о конфигурационных файлах.
Для таких вот "грамотеев" я уже привел определение прямо выше.
Конфигурационные файлы - это такие файлы, которые хранят конфигурацию.
Значит, по-вашему, в конфигурации всего перечиленного вами никак НЕ ДОЛЖНО быть .
>Только константы. А = 1, B = 2, С = "ABC", D = 3.14159265, всё!!!
Т.е. это по-вашему именно константы, но никак не переменные.
А что же такое по вашему переменные?
И их там по-вашему вообще в принципе не может быть? Или они там все-таки бывают, но их там быть НЕ ДОЛЖНО?Пример конфигурации Мозиллы я тоже привел выше.
>Логика работы и взаимодействие между системой и человеком есть суть - программа.
А эта фраза вообще к чему?
>>Только константы. А = 1, B = 2, С = "ABC", D = 3.14159265, всё!!!
>Т.е. это по-вашему именно константы, но никак не переменные.
>А что же такое по вашему переменные?Странно, но я почему-то понял Павла. Понял именно то, что он хотел выразить, а не то, что Вы захотели увидеть.
Он имел ввиду допустимость
А = 1, B = 2, С = "ABC", D = 3.14159265но недопустимость
A = B-1, B = 140/70, C= "A"+"BC", D = 22/7То есть, должны быть константные правые части "присваивания". Именно там он (и я) считаем недопустимыми использование переменных в конфигурационных файлах, хотя эта фишка и повышает гибкость.
P.S. Кончайте тавтологию :(
Третий "грамотей". Ну-ну.>Странно, но я почему-то понял Павла. Понял именно то, что он хотел
>выразить, а не то, что Вы захотели увидеть.Как же вы его могли не понять, если вы с ним одинаково мыслите.
>Он имел ввиду допустимость
>А = 1, B = 2, С = "ABC", D = 3.14159265
>
>но недопустимость
>A = B-1, B = 140/70, C= "A"+"BC", D = 22/7То есть вы вместе с ним считаете, что А=1 это обязатетельно константа, а А=В+С никак константой быть не может. Ну я понял, что от так считает, а теперь еще и вы.
>То есть, должны быть константные правые части "присваивания". Именно там он (и я) считаем недопустимыми использование переменных в конфигурационных файлах, хотя эта фишка и повышает гибкость.
Ну и почему вы считаете что нельзя? Вы так и не объяснили.
По вашему, вообще получается нельзя в конфах использовать вычисления. А если понадобится, то только предварительно на бумажке.
И что такое "константная часть присваивания"? Если уж речь идет о присваивании.
Теперь мы судя по всему уже имеем новый закон pavlinux'a-slavaz'a для конфигурационных файлов.
>P.S. Кончайте тавтологию :(
Попробуйте еще объяснить, что такое по-вашему тавтология, если уж произнесли это слово, и почему у меня здесь именно тавтология по-вашему.
>В конфигурационных файлах НЕ ДОЛЖНО быть : переменных, условных выражений, ветвлений и неопределённости.А про неопределенность это он вообще здорово загнул. Это получается, что в других языках неопределенность допустима, и только для конфигов особо надо оговаривать, что она недопустима.
Если отвлечься от "формальных" языков, от стоит вспомнить, что конфии должны быть ЛЕГКО понятны ЧЕЛОВЕКУ. Для пользовательской программы, в том числе - тому, кто питона (или еще какого языка) в глаза не видел. Так вот, для этого в конфиге не должно быть сложных конструкций - к примеру, только присваивание и конатенация, никакаой арифметики, IF и тому подобного - просто потому, что это "с первого взгляда" не охватить.
Второй вариант (IMHO, предпочтительный) - делить конфигурационные СКРИПТЫ, писаные на каком-нибудь полноценном языке, и конфиги, в которых лежат ЗНАЧЕНИЯ, используемые скриптами и головной программой.
Я снова отталкиваюсь от определения. Конфигурационный файл - это файл, который хранит конфигурацию.Просто как от самого простого и очевидного. Каждый, конечно, может для себя принять за основу свое собственное.
>Если отвлечься от "формальных" языков, от стоит вспомнить, что конфии должны быть ЛЕГКО понятны ЧЕЛОВЕКУ.
Прежде чем отвлекаться от формальных языков и систем, следует задать себе вопрос, а зачем от этого следует отвлекаться? Или, насколько целесообразно от этого отвлекаться? Или даже, к чему может привести упорное желание при работе с какой-либо автоматикой забывать, что это прежде всего формальная система?
Тогда как одни люди стараются что-то понять или освоить. Другие упорно стараются дискредитировать результаты исследований и практик в области формализации, и превратить формальные системы и четкие определения, обратно в нечто туманное и неопределеное.
Я вовсе не призываю на абсолютно все смотреть формально и "четко". Но если такие результаты получены, это просто глупо не уметь пользоваться ими по непосредственному назначению.
Дело снова в том, что "понятность" - это опять таки желательное свойство любых языков, а не только конфигов. Ктоме того, у каждого свои собственные критерии понятности, которые в общем случае очень и очень трудно определить. Или вы знаете какие-то общие критерии понятности, относящиеся абсолютно ко всем?
>Для пользовательской программы, в том числе - тому, кто питона (или еще какого языка) в глаза не видел. Так вот, для этого в конфиге не должно быть сложных конструкций
Распространеная ошибка. Путать такие принципиально разые вещи, как СЛОЖНОСТЬ и ПОНЯТНОСТЬ. Вот как раз языки, в которых стараются обходиться только "понятными" конструкциями, на таких языках и получаются самые сложные и громоздкие формулировки и большие тексты. И наоборот. Так что здесь все тоже не все так просто, как вам кажется.
> - к примеру, только присваивание и конатенация, никакаой арифметики, IF и тому подобного - просто потому, что это "с первого взгляда" не охватить.
Так вам нужна именно понятность с первого взгляда или понятность при многократном использовании? Если с первого взгляда не понятно, то можно просто ПОПЫТАТЬСЯ ПОНЯТЬ. Если такие люди, у которых это неплохо получается. Остальным общая рекомедация НЕ ТРОГАТЬ, и обращаться к разработчикам или администраторам.
Вы считаете, что людям, у которых проблемы с абстрактным мышлением, такие вещи, как присваивание и конкатенация (не их названия, а именно эти синтаксические конструкции), будут более понятны, чем банальное ветвление и арифметика.
Только с одним присваиванием возникает куча ньюансов, которые сильно зависят от реализации языка.
И мы это можем легко наблюдать по вышерасположенным высказываниям некоторых грамотеев, которые за всю их практику так и не разобрались, что такое переменные, константы и присваивание.
>Второй вариант (IMHO, предпочтительный) - делить конфигурационные СКРИПТЫ, писаные на каком-нибудь полноценном языке, и конфиги, в которых лежат ЗНАЧЕНИЯ, используемые скриптами и головной программой.
Ну любой язык или ситему можно разделить на какие-то части по каким-то критериям. При чем здесь именно конфиги?
Из приведенных высказываний по поводу того, как же следует правильно делать конфиги, пока никто из высказавшихся так и не смог четко определить, чем же по его мнению конфиги отличаются от всех остальных файлов. Хотя такие отличия есть, но именно эти отличия упорно каждый раз от них ускользают. И приводят всего лишь свои собственные критерии понимания формальных конструкций. Но не конфигурационных файлов.
Так в чем же суть самих конфигов и конфигураций? Не понимаете - тогда лучше доверьтесь разработчику. Хотя некоторые разработчики это тоже не понимают, но хотя бы этом случае интуитивно действую по шаблонам. И проблем от этого бывает гораздо меньше, чем от пользователей, привыкших к "понятным" с их точки зрения интерфейсам.
Следует ли разработчикам потакать желаниям таких пользователей, которые сами не могут четко СФОРМУЛИРОВАТЬ (однокоренное со словом "формальный"), чего они хотят. Точнее желаниям потакать можно и даже нужно, но для этого как раз и есть ГРАФИЧЕСКИЕ ИНТЕРФЕЙСЫ. А ФОРМАЛЬНЫЕ СИСТЕМЫ лучше использовать по их прямому назначению, а не ради облегчения комплексов неполноценности перед "полноценными" языками.
Опять таки, тоже есть чисто управленческий смысл создавать более примитивные языки для всяких там "быдлокодеров" и "быдлоадминов", как это сейчас модно говорить. Чтобы скидывать на них большое количество черновой и рутинной работы. Но это тоже совсем другой угол зрения, и конфиги с этой точки зрения тоже ничем от других файлов или языков не отличаются.
>В творчестве правил нет.
>
>Проекты, в которых авторы слишком стараются все подряд угодить в ущерб свой
>собственной индивидуальности и собственному творческому началу, неизбежно утрачивают качество и выраждаются
>в тупую кучу функционала, которая формируется исключительно под влиянием рынка.Верно, я от таких идей и отталкивался в общем-то.
Вообще я любитель пописать парсеры, ваял их раньше на каждый чих, вот и внутри проекта используется честный LR(1) парсер для разбора выражений, создающих предикаты для файловых объектов, эти выражения получились довольно гибкими и удобными и очень широко используются внутри и, собственно, снаружи (в конфигах), здесь действительно тот случай, когда имело смысл облегчить задачу.
Но конфиги, в целом, естественным образом мигрировали с самописных парсеров на питоновский, что, на мой взгляд, явилось большим выигрышем по всем направлениям, разве что стали более многословными.
А кто придумал, что нет? Какая принципиальная разница? Или вам нужно исключительно regedit?
>>все конфигурационные файлы представляют собой скрипты на языке Python
>Кто придумал, что это удобно? Давайте уж тогда вообще без конфигурационных файлов - вон исходники, правь если хочешь.Я считаю, что это UnixWay-но :). И таки да, удобно, можно конечно прикручивать парсер YAML, но зачем, если программа уже на Python?
> Я считаю, что это UnixWay-но :).Это Linux-way'но. Добавить сложности там, где ее не надо. А Unix-way он, все же, KISS.
Не знаю кто это придумал, но руки бы ему не мешало оторвать.И проблема не в языке или в чем-то. Проблема в том что конфиг ВНЕЗАПНО оказывается (тадам!) ТЬЮРИНГ-ПОЛОН. Я, надеюсь, все понимают что это значит и к чему это ведет, например, попытки (правильно) сделать GUI-конфигуратор?
А если он не на Питоне, а, все же, на его ограниченном подмножестве (ну, скажем, набор строк foo.bar = True и простые if'ы с ограниченными условиями), то это так и надо объявлять. Но, казалось бы, зачем это все это тогда, если даже в самом питоне, в стандартных либах, есть готовые модули для работы с конфигами?
Так что, господа разработчики, пожалуйста (ПОЖАЛУЙСТА!), оставьте Тьюринг-полные конфиги там, где они нужны. Тому же GNU Emacs, например, или, там, почтовым обработчикам.
P.S. Что творится в конфиге сабжа не смотрел. Но не верю я что там что-то такое есть.
> например, попытки (правильно) сделать GUI-конфигуратор?(На всякий случай) С болью вспоминающим о regedit.exe¹ даю другую задачку. Автоматическая правка конфигов, например. Т.е. sed(1)/awk(1) уже _принципиально_ не способны обработать такое, только если частный случай когда повезет и нужное место будет.
В итоге, когда программа (скажем, расширяющая возможности) хотела бы и могла бы сама добавить себя в конфиг может его угробить. Вот и вся разница.
____
1) Offtopic: А что плохого в реестре? Только не в вендовой дряни, а в общем смысле — некой единой системе хранения (хорошо продуманной, разумеется) конфигурационных данных. Которая покрывает запросы добрых 90% программ (а GNU Emacs хранит конфиг как ему надо, потому что там это обосновано). Даже аналог procfs (etcfs) покроет требования доброй половины конфиговых запросов, и это с учетом того что в VFS Linux файл не может, увы, быть одновременно и директорией.
>1) Offtopic: А что плохого в реестре? Только не в вендовой дряни,
>а в общем смысле — некой единой системе хранения (хорошо продуманной,
>разумеется) конфигурационных данных. Которая покрывает запросы добрых 90% программ (а GNU
>Emacs хранит конфиг как ему надо, потому что там это обосновано).
>Даже аналог procfs (etcfs) покроет требования доброй половины конфиговых запросов, и
>это с учетом того что в VFS Linux файл не может,
>увы, быть одновременно и директорией.Да, в принципе, ничгео плохого, если не пытаться засунуть в этот же реестр всех, влючая Emacs. И если обеспечить:
1) интфрументы работы (аналоги тех же grep/awk)
2) простой экспорт нужных кусков
3) возможность версионироания с просмотров diff'ов
4) обозримость конфига (открыв конфиг, мы видим не один параметр, и даже не один уровень - а достаточно много).
5) надежность работы, в том числе - возможность выковырять живые куски из битого конфига
6) не деградирующую со временем производительность.
7) простоту написания/изменения человеком (и т.ч. - без gui).Если есть желание - можем обсудить это дело подробнее, было бы неплохо что-то такое сваять...
Что плохого в реестре? Попытка все подвести под единый язык и единый формат. Человеческая практика еще со времен попыток построить Вавилонскую Башню показала, что универсальных языков и форматов не существует, а только хуже получается.>Да, в принципе, ничгео плохого, если не пытаться засунуть в этот же реестр всех, влючая Emacs. И если обеспечить:
>1) интфрументы работы (аналоги тех же grep/awk)
>2) простой экспорт нужных кусков
>3) возможность версионироания с просмотров diff'ов
>4) обозримость конфига (открыв конфиг, мы видим не один параметр, и даже
>не один уровень - а достаточно много).
>5) надежность работы, в том числе - возможность выковырять живые куски из
>битого конфига
>6) не деградирующую со временем производительность.
>7) простоту написания/изменения человеком (и т.ч. - без gui).Вот и получаем, что проще все оставить в текстовых файлах. И просто сделать хорошую систему разграничения доступа и полномочий. Но здесь тоже бесполезно искать универсальный набор правил. Достаточно соблюдать иерархичность и модульность.
Хотя компиляция в какие-то бинарные форматы, в принципе допустима, если удается внятно обосновать, зачем это нужно. Только, повторюсь, бесполезно пытаться изобрести единый текстовый и бинарный формат на все случаи жизни. Эта задача сродни попыткам изобрести вечный двигатель.
Не, ну если доброй половине софта хватит вообще key=value, то почему бы эту часть /etc не причесать под одну гребенку?Только не в мерзостном виде аля gconf, а чем-то хорошем, типа /sys. Чтобы "бинарности" (ну, понимаете о чем я, думаю) там было не больше чем в текстовом файле на ext3.
А где не подходит - то, разумеется, не делать глупостей и не запихивать. И, вроде как, все хорошо становится.
>Не, ну если доброй половине софта хватит вообще key=value, то почему бы эту часть /etc не причесать под одну гребенку?Потому что ответ вы уже сами дали ниже.
>Только не в мерзостном виде аля gconf, а чем-то хорошем, типа /sys.
Предложите такой способ на все случаи жизни "причесать под одну гребенку", чтобы гарантированно при этом не получить очередную "мерзость". Или вы думаете, что глупые разработчики заранее планировали, "создатим-ка мы такую мерзость". Нет, также как и вы с горячим энтузиазизмом хотели "причесать все под одну гребенку".
Текстовы файлы - это уже и есть "под одну гребенку".
>Чтобы "бинарности" (ну, понимаете о чем я, думаю) там было не больше чем в текстовом файле на ext3.
Нет, я не понимаю о чем вы. Попробуйте поточнее сформулировать свои мысли в контексте тех реалий, которые существуют в вычислительной технике и формальных системах, а не в виде смутных образов, существующих в вашем сознании. Только судя по вашим представлениям, скорее всего запутаетесь.
>А где не подходит - то, разумеется, не делать глупостей и не запихивать. И, вроде как, все хорошо становится.
Не подходит что и куда? Не запихивать что и куда? Автоматика так не понимает, оно не человек, с ней на других языках "говорить" нужно.
большой плюс -- практически нет зависимостей.
попробовал как-то я на чистую freebsd 6.x поставить mc -- устал ждать, пока все зависимости подтянутся. успел пообедать и пива выпить.
>большой плюс -- практически нет зависимостей.
>попробовал как-то я на чистую freebsd 6.x поставить mc -- устал ждать,
>пока все зависимости подтянутся. успел пообедать и пива выпить.Ну и по функциональности конечно до mc пока далеко ;) Хотя буду стараться и в будущем ничего лишнего не вносить.
>Ну и по функциональности конечно до mc пока далеко ;) Хотя буду
>стараться и в будущем ничего лишнего не вносить."cd ~" внесите. не самое лишнее :)
Просто "cd" как раз так и действует ;)
>Просто "cd" как раз так и действует ;)ну а смысл? если нельзя сделать "cd ~/work"
>>Просто "cd" как раз так и действует ;)
>
>ну а смысл? если нельзя сделать "cd ~/work"Вообще да, надо доделать.
>большой плюс -- практически нет зависимостей.
>попробовал как-то я на чистую freebsd 6.x поставить mc -- устал ждать, пока все зависимости подтянутся. успел пообедать и пива выпить.http://mc.linuxinside.com/cgi-bin/dir.cgi Облегченный форк. В свое время выручил меня, когда МЦ понадобился на сервере, где у меня не было почти никаких прав. Мейнстримовый МЦ вместе со всеми зависимостями локально собрать тогда не получилось.
>Вышел XYZCommander 0.0.3 (http://xyzcmd.syhpoon.name/), третий релиз нового консольного файлового менеджера для *nixна кой нужен ещё один файловый менеджер?
в то время, как с таким большим трудом удаётся отучать виндо-хомячков от поделия mc, пишутся «аналоги»!
ведь в *nix есть два богатейших shell-а: bash(+readline+completion) и zsh(+все его прибабахи).
на кой?!
Какая тут связь?
>Какая тут связь?между чем и чем в моём посте вам связь не ясна?
Зачем нужен еще один файловый менеджер?
Ответ ниже, здесь http://www.opennet.me/openforum/vsluhforumID3/63006.html#95
>на кой нужен ещё один файловый менеджер?+1
в винде я понимаю - без них неудобно
а в никсах то зачем?
"Одно из величайших преимуществ открытых систем - богатство выбора: выбора использования, выбора установки, выбора реализации." (с)
>"Одно из величайших преимуществ открытых систем - богатство выбора: выбора использования, выбора
>установки, выбора реализации." (с)«эту бы энергию, да в мирных целях».
>>на кой нужен ещё один файловый менеджер?
>
>+1
>в винде я понимаю - без них неудобно
>а в никсах то зачем?а меня ломает регулярно набивать pwd или ls, чтобы понять где я сейчас нахожусь и что меня окружает. Хочу, понимаешь панельку видеть со сводной инфой.
>>>на кой нужен ещё один файловый менеджер?
>>
>>+1
>>в винде я понимаю - без них неудобно
>>а в никсах то зачем?
>
> а меня ломает регулярно набивать pwd или ls, чтобы понять где
>я сейчас нахожусь и что меня окружает. Хочу, понимаешь панельку видеть
>со сводной инфой.постоянное «cd+pwd+ls» — это-то и есть «стиль файлового менеджера» (то, что (в таком количестве) абсолютно излишне для продуктивной работы с файлами в «shell-стиле»).
да, для работы в таком стиле, файловый менеджер — единственно приемлемое решение. тут не поспоришь.
поспорить можно об эффективности выполнения аналогичных задач в разных «стилях».
> трудом удаётся отучать виндо-хомячков от поделия mc,Ты или слишком молод или слишком стар. Про deco слышал ?
а мс это не вин-хомяки а дос-хомяки ( аля нортон )И вин хомяки это тотал командер как правило ... и Ехплорер
так что камень тебе нужно пускать в огород нау и дельфина ...
>> трудом удаётся отучать виндо-хомячков от поделия mc,
>Ты или слишком молод или слишком стар. Про deco слышал ?я много про что слышал. а двухпанельный файловый менеджер в своё время под свм-370 так даже и писал (будучи зачарован идеей norton commander-а (идеей, не внешним видом — pc вживую увидел не скоро)).
>а мс это не вин-хомяки а дос-хомяки ( аля нортон )
>И вин хомяки это тотал командер как правило ... и Ехплорерв сортах хомячков я не такой большой специалист.
>так что камень тебе нужно пускать в огород нау и дельфина ...
и не подумаю. для людей, у которых мышекликанье уже на уровне рефлексии, подобные штуки весьма пользительны.
>>Вышел XYZCommander 0.0.3 (http://xyzcmd.syhpoon.name/), третий релиз нового консольного файлового менеджера для *nix
>
>на кой нужен ещё один файловый менеджер?Ну мне нужен, и чё?
>в то время, как с таким большим трудом удаётся отучать виндо-хомячков от
>поделия mc, пишутся «аналоги»!В чем профит от отучения?
>ведь в *nix есть два богатейших shell-а: bash(+readline+completion) и zsh(+все его прибабахи).
>На кой нужен трамвай, когда есть лисапед? То что shell и файловый менеджер это разные классы программ вас не смущает?
>>на кой нужен ещё один файловый менеджер?
>Ну мне нужен, и чё?текст, на который отвечаете, прочитать удосужились? если нет, повторяю: я спрашивал «на кой», а не «кому». «кому» — я и так прекрасно понимаю…
>>в то время, как с таким большим трудом удаётся отучать виндо-хомячков от
>>поделия mc, пишутся «аналоги»!
>В чем профит от отучения?скорость работы (в т.ч. с файлами).
>>ведь в *nix есть два богатейших shell-а: bash(+readline+completion) и zsh(+все его прибабахи).
>На кой нужен трамвай, когда есть лисапед? То что shell и файловый
>менеджер это разные классы программ вас не смущает?меня смущает тот ход мыслей, в результате которого может зародиться идея: «а не написать ли мне ещё один файловый менеджер?»
не знаю, что там вы подразумеваете под «классами», но shell-ы вполне себе заточены под задачи управления файлами.
>>В чем профит от отучения?
>скорость работы (в т.ч. с файлами).А ежели ему не натЬ скорость? Ежели ему натЬ ну скажем "наглядность"? Ы?
Да и вообще странный ты тип - "их энергию да в мирные цели", "зачем нежен еще один XYZ" - ты мир отрытого кода тоько сегодня утром откыл? Так я тебя быстро введу в крс дела - тут _каждый_ волен делать что ему нравится. Заметь - не тебе, а ему самому.
Впрочем ты в свою очередь волен проповедовать что "шелл наше всё" (ога раз ты 360\370 застал расскажи как чудовишно хорош был грёбанный JCL ;) ну и прочие радикальные дела.PS: Автору продуГда - посмотри как конфиги сделаны в Джанге ... на мой цвет - самое оно, помедитируй может перетянешь к себе?
Так конфиги в джанге как раз самый что ни на есть питон, с импортами, try/except'ами и прочими делами. У меня не сильно отличается, частично ими я и вдохновлялся :)
Ну я ж чесно предупредил что на мой цвет :)И кстати единственное что не проффесионалов в них смущало так это необходимость запятой в описании тупла, типа:
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.load_template_source',
)Всё остальное воспринималось вполне себе "влёт" :)
(Правда комментарии были на великомогучем, и таки - были :)
>Всё остальное воспринималось вполне себе "влёт" :)
>(Правда комментарии были на великомогучем, и таки - были :)Когда разработчик слишком начинает прислушиваться к советам, что и как нужно делать, то это может только говорить о несамостоятельности разработчика. И такие проекты очень быстро вырождаются в мусор.
С другой стороны. Если разработчик сам знает, что нужно делать, и делает, то что знает, не боясь ошибаться - всегда найдутся те, кому это понравится и будет полезным. Поэтому тем, у кого есть способности что-либо творить, о чужом мнении нужно думать в последнюю очередь. А что было ошибкой, а что нет, и с какой стороны лучше разбивать яйца - это тоже лучше решать самостоятельно.
И, наконец, те кто всегда точно знают, как по их мнению было бы лучше, но сами сделать не в состоянии, а только другим оценку дают - ценность подобных оценок в лучшем случае бывает чуть менее, чем нулевая.
Но хуже всех - боты спамяшие банальностями на форумах и мешающие реальным пиплам общаться :)
>Но хуже всех - боты спамяшие банальностями на форумах и мешающие реальным пиплам общаться :)Вы хотите сказать, что сказанная "банальность" помешала вам казаться таким "реальным", как вы пытались.
Ну что ж, плохим "танцорам", которые пытаются казаться, всегда мешают какие-то... "банальности". Поэтому они обычно и советуют другим, как правильно "танцевать", заверяя в своей "реальности". О чем, собственно, и была речь.
>Когда разработчик слишком начинает прислушиваться к советам, что и как нужно делать,
>то это может только говорить о несамостоятельности разработчика. И такие проекты
>очень быстро вырождаются в мусор.Это всего лишь значит, что разраб реализовал всё, что хотел, детище его устраивает полностью; а дальше просто разраб реализовывает пожелания пользователей, чисто for fun.
>С другой стороны. Если разработчик сам знает, что нужно делать, и делает,
>то что знает, не боясь ошибаться - всегда найдутся те, кому
>это понравится и будет полезным.а также найдутся те, кому не нравится, кто сочтёт какую-либо фичу чрезмерной, лишней и вообще не *NIX-way.
Если продукт не для себя или для узкого междусобойчика, то мнение и этой группы несогласных пользователей стоит учитывать.> Поэтому тем, у кого есть способности
>что-либо творить, о чужом мнении нужно думать в последнюю очередь. А
>что было ошибкой, а что нет, и с какой стороны лучше
>разбивать яйца - это тоже лучше решать самостоятельно.Моё мнение: если есть конфликт, то нужен компромисс в виде опции. То есть, пусть пользователи сами решают, хотят они видеть ту или иную фичу или нет. В некоторых специфичных случах нужно принимать решение самостоятельно, это беспорно (например, какая опция должна быть включена по умолчанию :) ). Но чаще нужно просто идти навстречу пожеланиям, дабы повысить интерактивность между разработчиками и пользователями.
>И, наконец, те кто всегда точно знают, как по их мнению было
>бы лучше, но сами сделать не в состоянии, а только другим
>оценку дают - ценность подобных оценок в лучшем случае бывает чуть
>менее, чем нулевая.Нет, такие люди могут быть хорошими психологами, социологами или просто толковыми тестерами. Их мнение очень ценно, лучше спросить мнения об новой фиче или об новом внешнем виде у таких пользователей, чем у других таких же как ты разработчиков, ибо у разрабов могут быть одинаково "замылены глаза", а свежие и неожиданно "прямые" решения могут приходить со стороны.
По теме: хорошая новость. Не питонист, так бы попробовал подмочь :)P.S. Автор XYZкоммандера, на Си не пишете? ;)
Писал когда-то, сейчас совсем почти не приходится, а жаль ;)
>Писал когда-то, сейчас совсем почти не приходится, а жаль ;)Это Слаффка так в миднайт переманивает... :)
>Это всего лишь значит, что разраб реализовал всё, что хотел, детище его устраивает полностью; а дальше просто разраб реализовывает пожелания пользователей, чисто for fun.Об этом я уже написал здесь http://www.opennet.me/openforum/vsluhforumID3/63006.html#54
Только существует принципиальная разница между реализацией чужих пожеланий, следствием самореализованности, и зависимостью от чужого мнения, следствием сомнений в себе.>а также найдутся те, кому не нравится, кто сочтёт какую-либо фичу чрезмерной, лишней и вообще не *NIX-way.
Это тавтология сказанного мной. Так к кому нужно прислушиваться по-вашему? К тем, кому нравится, или к тем, кому не нравится? Если и те и другие будут в любом случае, что бы разработчик не делал. И если всегда можно найти тех, кому понравится, то зачем вообще обращать внимание на тех, кому не нравится.
>Если продукт не для себя или для узкого междусобойчика, то мнение и этой группы несогласных пользователей стоит учитывать.
Это зависит от того, как создатель себя позиционирует прежде всего по отношению к себе. Вопрос, а нужно ли быть для тех, кто с тобой не согласен, если всегда можно найти согласных если хорошенько поискать. А еще лучше даже вообще не тратить усилия на поиски согласных, поскольку если достичь согласия с самим собой, то согласные сами находятся без усилий.
>Моё мнение: если есть конфликт, то нужен компромисс в виде опции. То есть, пусть пользователи сами решают, хотят они видеть ту или иную фичу или нет.
Конфликты в творчестве - это либо результат внутреннего конфликта разработчика, либо внутреннего конфликта тех "критиков", которых раздражает сам факт существования чего-то, что их не устраивает. И вместо того, чтобы искать или самим создавать они призываются создателей выгибаться под чужие нужды.
Страх перед возможными ошибками или конфликтами - это и есть показатель внутренней неуверенности создателя.
>В некоторых специфичных случах нужно принимать решение самостоятельно, это беспорно (например, какая опция должна быть включена по умолчанию :) ). Но чаще нужно просто идти навстречу пожеланиям, дабы повысить интерактивность между разработчиками и пользователями.
Проще предоставить им возможность самим реализовывать свои пожелания, не жертвую своим творчеством. А я уже сказал в самом начале, что это достигается самореализацией. Зависимость от мнения нереализованных людей только усилит неудовлетворенность всех сторон.
>Нет, такие люди могут быть хорошими психологами, социологами или просто толковыми тестерами.
Психология и социология - это всего лишь инструмент (в случае, если не являются сами объектом творчества). И могут быть использованы как для самореализации, так и для оправдания своего текущего положения.
Может быть они и хорошие психологи и социологи, но свои способности в этих направлениях они обычно используют (обычно подсознательно и без умысла, хотя не всегда) для самооправданий и для того, чтобы превратить (это тоже неосознанное желание как правило) творческих людей в себе подобных, чтобы те их не так раздражали.
>Их мнение очень ценно, лучше спросить мнения об новой фиче или об новом внешнем виде у таких пользователей, чем у других таких же как ты разработчиков, ибо у разрабов могут быть одинаково "замылены глаза", а свежие и неожиданно "прямые" решения могут приходить со стороны.
Все в мире ценно. Вопрос на каком месте каждая ценность должна стоять.
Лично для вас мнение других очень ценно. Это очевидно.Разница в том, что творческие люди обычно изнутри чувствуют, что чем лучше они реализуются, тем больше будет от них пользы. Хотя часто испытывают сомнеия правильно ли они поступают. Пока наконец, наслушившись чужих советов, не понимают, что самое ценное им удавалось сделать, когда они поступали по-своему.
Остальные же упорно пытаются извлечь собственную выгоду из чужой выгоды. И постоянно испытавют страх, что их не оценят.
>Их мнение очень ценно, лучше спросить мнения об новой фиче или об новом внешнем виде у таких пользователей, чем у других таких же как ты разработчиков, ибо у разрабов могут быть одинаково "замылены глаза"Еще раз, я говорил о том, что лучше вообще ни у кого не спрашивать мнения, а вы говорите о том, у кого его лучше спрашивать - совершенно разные вещи.
Это лишний раз подтверждает вашу зависимость от чужого мнения. Вы просто не представляете, как можно действовать иначе. И пытаетесь все время вычислить, у кого же "глаза замылены" меньше. Поскольку собственным доверяете меньше всего.
>а свежие и неожиданно "прямые" решения могут приходить со стороны.
Решения вообще могут прийти откуда угодно, даже от противников. Хотя лучшие решения приходят как правило изнутри. Если эту способность постоянно развивать.
Только еще раз, решения - это одно, а мнеия по поводу этих решений - совсем другое. Даже если источник и мнений, и решений, один и тот же.
>>>В чем профит от отучения?
>>скорость работы (в т.ч. с файлами).
>
>А ежели ему не натЬ скорость? Ежели ему натЬ ну скажем "наглядность"?nautilus-ы всякие не лучше ли подойдут в плане наглядности?
>Да и вообще странный ты тип - "их энергию да в мирные
>цели", "зачем нежен еще один XYZ" - ты мир отрытого кода
>тоько сегодня утром откыл? Так я тебя быстро введу в крс
>дела - тут _каждый_ волен делать что ему нравится. Заметь -
>не тебе, а ему самому.
>Впрочем ты в свою очередь волен проповедовать что "шелл наше всё" (ога
>раз ты 360\370 застал расскажи как чудовишно хорош был грёбанный JCL
>;) ну и прочие радикальные дела.не припоминаю брудершафтов, потому рискну оставить сей пассаж безответным.
>текст, на который отвечаете, прочитать удосужились? если нет, повторяю: я спрашивал «на кой», а не «кому». «кому» — я и так прекрасно понимаю…И чё? Выпендреж владения литературным русским языком аж зашкаливает, типографика и все дела, только смысл в предложении отсутствует, да и шифт в начале предложения подводит, что не фраза то пустышка в фантике.
В общем мне нужна эта программа, а на "кой" она мне нужна, вам должно быть фиолетово.
А если это не так, то это хороший повод для очередного заработка вашего психоаналитика.>скорость работы (в т.ч. с файлами).
Эй птичка полетели туда, там столько вкусного... /Крылья, ноги, хвост/
Скорость работы зависит напрямую от привычки, если я/ты/он/она привык пользоваться 20 лет двухпанельными файловыми менеджерами, то мне/тебе/ему/ей удобней и быстрей работать в нём.
>меня смущает тот ход мыслей, в результате которого может зародиться идея: «а не написать ли мне ещё один файловый менеджер?»mc слишком глючный, благо в 4.7 много что поправили (спасибо ребятам кстати), при этом написан на С, врубаться в "тоны кода" на С придется долго.
На Python получить приемлемый результат тупо быстрее, и такие мысли, как видно, приходили не только ко мне, и автор этой программы оказался менее ленивым чем я, за что ему отдельное спасибо.
>не знаю, что там вы подразумеваете под «классами», но shell-ы вполне себе заточены под задачи управления файлами.
shell заточен под, а файловый менеджер под конкретную задачу работы с файлами, а узкоспециализированный инструмент всегда выигрывает у широкопрофильного, в решении той самой узкой задачи для которой он предназначен, так что ваша байка о превосходстве оболочек над файловыми менеджерами, работе с файлами, не более чем ваша байка.
>>текст, на который отвечаете, прочитать удосужились? если нет, повторяю: я спрашивал «на кой», а не «кому». «кому» — я и так прекрасно понимаю…
>
>И чё? Выпендреж владения литературным русским языком аж зашкаливает, типографика и все
>дела, только смысл в предложении отсутствует, да и шифт в начале
>предложения подводит, что не фраза то пустышка в фантике.
>В общем мне нужна эта программа, а на "кой" она мне нужна,
>вам должно быть фиолетово.
>А если это не так, то это хороший повод для очередного заработка
>вашего психоаналитика.о! какие знакомые потоки фамильярности и личных выпадов! (не на лор ли я попал?)
>>скорость работы (в т.ч. с файлами).
>Скорость работы зависит напрямую от привычки, если я/ты/он/она привык пользоваться 20 лет
>двухпанельными файловыми менеджерами, то мне/тебе/ему/ей удобней и быстрей работать в нём.«удобство» — да, чисто субъективный критерий. «скорость работы» — гораздо объективней.
>>меня смущает тот ход мыслей, в результате которого может зародиться идея: «а не написать ли мне ещё один файловый менеджер?»
>
>mc слишком глючный, благо в 4.7 много что поправили (спасибо ребятам кстати),
>при этом написан на С, врубаться в "тоны кода" на С
>придется долго.эх ма, про то и речь веду. есть ведь, есть эффективные средства работы с файлами! зачем от добра добра искать?
>>не знаю, что там вы подразумеваете под «классами», но shell-ы вполне себе заточены под задачи управления файлами.
>
>shell заточен под, а файловый менеджер под конкретную задачу работы с файлами,
>а узкоспециализированный инструмент всегда выигрывает у широкопрофильного, в решении той самой
>узкой задачи для которой он предназначена вот тут не соглашусь — в вопросе что считать комбайном, а что специлизированным инструментом.
>так что ваша байка о
>превосходстве оболочек над файловыми менеджерами, работе с файлами, не более чем
>ваша байка.ну какая ж это «байка»? history+completion+мета-подстановки — это объективная реальность, данная всем желающим их использовать в ощущениях.
>о! какие знакомые потоки фамильярности и личных выпадов! (не на лор ли я попал?)Надо было сначала понять куда попал, а уж потом писать "первонах" и получать за это заслуженные "похвалы".
>«удобство» — да, чисто субъективный критерий. «скорость работы» — гораздо объективней.
Пруф на замеры скорости?
>а вот тут не соглашусь — в вопросе что считать комбайном, а что специлизированным инструментом.
Фиолетово в крапинку на ваше согласие.
>ну какая ж это «байка»? history+completion+мета-подстановки — это объективная реальность, данная всем желающим их использовать в ощущениях.
А что шелл уже отсутствует в двухпанельных файловых менеджерах и не имеет той же истории и дополнения команд?
>>скорость работы (в т.ч. с файлами).Нету скорости работы, как так, так и с файлами. Есть высокая скорость выполнения _типичных_ (привычных) задач, для решения которых нормальные пацаны пишут скрипты/программы, а не насилуют консоль.
>>>скорость работы (в т.ч. с файлами).
>
>Нету скорости работы, как так, так и с файлами.ваше слово против моего (улыбка)?
>Есть высокая скорость
>выполнения _типичных_ (привычных) задач, для решения которых нормальные пацаны пишут скрипты/программы,
>а не насилуют консоль.для типичных задачек скрипты/программы — это явный перебор. однострочников в history для мелких задачек более чем достаточно.
>ваше слово против моего (улыбка)?Не, слово _большинства_ против вашего, ага. Меньшинства, как показывает история, такие большие затейники...
>для типичных задачек скрипты/программы — это явный перебор. однострочников в history для мелких задачек более чем достаточно.
У пользователей не бывает типичных задачек, решаемых однострочником. Этим они отличаются от админов.
>>для типичных задачек скрипты/программы — это явный перебор. однострочников в history для мелких задачек более чем достаточно.
>
>У пользователей не бывает типичных задачек, решаемых однострочником. Этим они отличаются от
>админов.ах, да-да-да, простите. как я мог забыть про «сферических пользователей в вакууме».
спешу вас разочаровать: для меня лично такого понятия не существует.
как не существует и понятий «пользователь-программист», «пользователь-администратор», «пользователь-домохозяйка».
для меня лично все они — пользователи. просто пользователи.
>спешу вас разочаровать: для меня лично такого понятия не существует. как не существует и понятий «пользователь-программист», «пользователь-администратор», «пользователь-домохозяйка».Пользователь-домохозяйка не расстроилась из-за того, что для вас её нет.
>для меня лично все они — пользователи. просто пользователи.
Зачем вам такое длинное слово. Есть слово короче - ку.
>>Вышел XYZCommander 0.0.3 (http://xyzcmd.syhpoon.name/), третий релиз нового консольного файлового менеджера для *nix
>
>на кой нужен ещё один файловый менеджер?
>в то время, как с таким большим трудом удаётся отучать виндо-хомячков от
>поделия mc, пишутся «аналоги»!
>ведь в *nix есть два богатейших shell-а: bash(+readline+completion) и zsh(+все его прибабахи).
>
>на кой?!Не нравится! Не пользуйся!
>>на кой нужен ещё один файловый менеджер?
>Не нравится! Не пользуйся!(не надо меня заклинать («не нравится! не нравится!»), я не змея, на такие вещи не ведусь.)
эх, если б всё так просто было. на уровне личных предпочтений…
а может всетаки змея? :)вообще странно, вот вы все доброхоты все хотите "направить энергию в мирное русло", но почему ж вам не в домёк что челу просто по кайфу писать именно аналог mc, а не очередной драйвер к ядру линукса. Как вы хотите его заставить писать то что надо вам? Меня так например никто не заставит писать то что мне не в кайф. Ну за денежку разве что :)
>а может всетаки змея? :)змей-искуситель? может быть, может быть.
>вообще странно, вот вы все доброхоты все хотите "направить энергию в мирное
>русло", но почему ж вам не в домёк что челу просто
>по кайфу писать именно аналог mcвдомёк, вдомёк! ещё как вдомёк! вот объясните, каким образом вы (или автор обсуждаемого велосипеда) пришли к этому своему «по кайфу»?
только не рассказывайте, пожалуйста, что с детства мечтали написать клон midnight commander-а, не поверю.
скорее, задача сложилась и оформилась под влиянием (в том числе) и мнения окружающих. так чем плохо в таком случае моё брюзжание? глядишь, и повлият в нужную сторону!вот соберутся сто человек и скажут автору xyzcommander-а: не нужно это, одумайся, мужик! не клепай ещё один велосипед, обрати внимание на другие задачи, что не доделаны. благо много их, и на всех хватит.
и что вы думаете, таки не одумается?
Только тот, кто сам ничего не создает, может думать, что человечество один раз изобрело "велосипед" в истории - и все. Ну и посмотрите на первые "велосипеды". И сравните их с современными.А как насчет улучшений, модернизаций. Почему тогда по-вашему существует столько разных моделей и производителей "велосипедов"?
Кроме того, те кто сами создавать не в состоянии, не понимают также, что во время создания альтернативных реализаций обычно делается много побочных изобретений, которые потом могут применяться совершенно в разных проектах, и из которых в конечном итоге и собирается что-то принципиально новое.
>скорее, задача сложилась и оформилась под влиянием (в том числе) и мнения окружающих.
То, что складывается под влиянием и мнением окружающих, обычно и бывает самого низкого качества.
>так чем плохо в таком случае моё брюзжание? глядишь, и повлият в нужную сторону!
Вряд ли оно на что-то повлияет. Разве что все увидят в вашем лице еще одного сильнозависимого от чужого мнения, который просто не представляет, как можно что-то делать, не глядя на мнение окружающих.
>вот соберутся сто человек и скажут автору xyzcommander-а: не нужно это, одумайся, мужик!
А автор возьмет, да и проигнорирует, то что ему скажут 100 человек. И только выиграет от этого. Вот прикол-то будет. Потому что когда 1 делает, не то что 100, а 1000 или 10000 говорят, как нужно правильно, но сами сделать не в состоянии.
>не клепай ещё один велосипед, обрати внимание на другие задачи, что не доделаны. благо много их, и на всех хватит. и что вы думаете, таки не одумается?
Он "клепает" не "еще один велосипед", а еще одну реализацию "велосипеда". Те кто сами создавать не в состоянии, обычно разницу не понимают.
Ну не понравилась ему реализация существующих, вот он и решил по своему сделать. У него есть такая свобода выбора в отличии от тех, кто может только ездить на "велосипедах", созданных другими и жаловаться, что не так сделали. И ждать, что может быть когда-нибудь кто-нибудь сделает так, как они хотят.
уважаемый! вы, надо понимать и есть автор обсуждаемой программы?
если так и есть, то давайте я вам вкратце сформулирую свою точку зрения:велосипедами в контектсте этого треда я рассматриваю не файловые менеджеры как таковые, а новые реализации shell-ов.
они есть, эти shell-ы. bash и zsh — наиболее развитые и продвинутые велосипеды.
а файловые менеджеры — это нечто вроде дополнительных колёсиков к имеющимся двум, а то и трём.да, есть люди, которым не так важна эффективность работы, сколь наглядность.
да, есть люди, которым вообще с файлами нафиг не нужно иметь дело. лишь очень изредка.вот для вышеупомянутых узких категорий пользователей файловые менеджеры просто необходимы.
как яркие игрушки для младенцев.но вот пользователь подрастает, пора бы отучаться ему от ярких кубиков.
и если у ребёнка мозг открыт для нового, сознание чисто и готово к принятию реального мира, то взрослому человеку, приученному к ярким кубикам, расставаться с ними ой как тяжело!
ох, с каким же скрипом отрывается он от бесконечно щёлканья — мышкой, в случае графического файлового менеджера, или enter/home/enter, в случае cli-менеджера!
s/рассматриваю/называю/
>уважаемый! вы, надо понимать и есть автор обсуждаемой программы?
>если так и есть, то давайте я вам вкратце сформулирую свою точку зрения:Гениально!
А вы надо понимать, не иначе как Билл Гейтс собственной персоной! Ж)))>велосипедами в контектсте этого треда я рассматриваю не файловые менеджеры как таковые, а новые реализации shell-ов. они есть, эти shell-ы. bash и zsh — наиболее развитые и продвинутые велосипеды.
Не надо так примитивно оправдываться. Вот как вы до этого написали.
>не нужно это, одумайся, мужик! не клепай ещё один велосипед, обрати внимание на другие задачи,
Из чего следует, что под "велосипедом" вы как раз и имели в виду "файловые менеджеры как таковые".
>а файловые менеджеры — это ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
Это вы все тоже пишете для самооправданий. Суть была гораздо проще.
Вы высказали мнение, что "переизобретать велосипеды" это плохо.
Я высказал мнение, что это хорошо, хоть в прямом, хоть в переносном смысле. И привел аргументы выше, на которые вы возражения найти не смогли.А если вы считаете, что файловые менеджеры - такое по-вашему зло, так вам же сказали, ну не пользуйтесь. А когда еще и программы писать научитесь вместо того, чтобы других учить, то никогда файловые менеджеры не пишите.
Я вот, например, файловых менеджеров не пишу и не пользуюсь. Хотя ничего дурного не вижу. в том, что человек взял и решил написать свою собственную альтернативу уже существующим.
Учебники по их эффективному использованию есть?
>Учебники по их эффективному использованию есть?advanced bash-scripting guide (есть и перевод). для начала. man bash, man readline. и практика, практика, практика.
про zsh ничего внятного не скажу. не пользуюсь за ненадобностью.
Учебник по эффективным методам решения задач с помощью инструмента, а не учебник по самому инструменту. Учебник по строительству дома, а не руководство по молотку, гвоздям, доскам, пиле, ножовке и т. д. Есть?
>Учебник по эффективным методам решения задач с помощью инструмента, а не учебник
>по самому инструменту. Учебник по строительству дома, а
>не руководство по молотку, гвоздям, доскам, пиле, ножовке и т. д.
>Есть?того, про что вы спрашиваете, в природе не встречал.
свою собственную методику работы каждый, наверно, пишет для себя лично.
тут, пожалуй, как с программированием. изучаете инструмент, кирпичики, а уж как с помощью них решать свои задачи — …хотя… можете заглянуть, например, в раздел http://linuxforum.ru/index.php?showforum=90
наверняка что-нибудь полезное почерпнёте.p.s. давно вот подумываю в блоге что-то подобное замутить. некое «деление опытом». вскорости не обещаю. поглядывайте иногда, если что: sash-kan.blogspot.com
>того, про что вы спрашиваете, в природе не встречал.А на этом (знания списка и методов достижения целей с помощью известных инструментов) , знаете ли, и строится подбор инструментов для решения задач, дабы достичь определённую цель.
>свою собственную методику работы каждый, наверно, пишет для себя лично.
Ага. Методика называется "хождение по граблям".
>тут, пожалуй, как с программированием. изучаете инструмент, кирпичики, а уж как с помощью них решать свои задачи — …
Ага, выучить молоток, а потом бегать с ним в надежде что-нибудь (и идеале всё) забить, даже если никто не просил.
>в то время, как с таким большим трудом удаётся отучать виндо-хомячков от поделия mc, пишутся «аналоги»!То есть вы их прямо отучаете. Они не хотят отучаться, а вы отучаете, догоняете и снова отучаете.
И яростно боретесь с разработчиками, которые мешают вам отучать других.
Вместо того, чтобы просто не пользоваться файловыми менеджерами и самостоятельно использовать преимущества, которые могла бы дать вам командная строка, если бы вы не тратили столько энергии на борьбу с инакомыслящими.
Вот уж действительно, «эту бы энергию, да в мирных целях». См. ниже.
А я вот знаете ли, сам файловыми менеджерами не пользуюсь, но юзеров приучаю. И не только я один так поступаю. Представляете, какое святотатство?
Меньше потом хлопот с пользователями. И подобные файловы менеджеры с минимальными зависимостями, в этом деле как нельзя кстати. Особенно для удаленных хостингов, как замена веб-интерфейса консолью по SHH.
Кстати, вопрос к автору. Как у него с поддержкой SHH?
Особенно в комплекте с разными там питоновскими штучками по автоматическому выкидыванию лишних библиотек и сжатию исходников. Очень перспективное направление может получиться по поддержке удаленных пользователей.
>
>Кстати, вопрос к автору. Как у него с поддержкой SHH?
>Особенно в комплекте с разными там питоновскими штучками по автоматическому выкидыванию лишних
>библиотек и сжатию исходников. Очень перспективное направление может получиться по поддержке
>удаленных пользователей.Имеется в виду SSH? Если да, то никакой особенной поддержки нет, просто можно логиниться удалённо и там запускать программу как любую другую консольную. Так работает. Про сжатие исходников, честно говоря, не слышал.
>Имеется в виду SSH? Если да, то никакой особенной поддержки нет, просто можно логиниться удалённо и там запускать программу как любую другую консольную.
>Так работает. Про сжатие исходников, честно говоря, не слышал.Да чисто механически неправильно набрал аббревиатуру. Причем дважды. Ж)
Конечно, специальную поддержку SSH лучше не вводить, чтобы не увеличивать зависимоти. Лучше следить, чтобы не было проблем при прозрачной работе по SSH.
Я лишь хотел сказать о потенциале применения - удаленная поддержка пользователей в условиях изолированных программных окружений с минимальным количеством подключаемых библиотек.
Также в таких окружениях часто жестко лимитируется количество используемой памяти, как оперативной, так и энергонезависимой.
Хотя я и не сторонник преждевременных оптимизаций. Особенно на начальных стадиях проекта. Важнее максимально выдеживать чистоту концептуальных моделей и наименьшую возможную связность компонетов. Кладя в жертву по необходимости скорость работы и количество используемой памяти. Потом гораздо проще будет оптимизировать, если действительно понадобится.
А вот задача максимальной изоляции непривилигированных пользователей - это как раз напрямую зависит от общей чистоты проекта.
Что же касается лимитов, то тут лучше учитывать, что по мере развития техники, эти лимиты все более и более смягчаются, и многие оптимизации, которые в начале пошли в ущерб "чистоте", потом оказываются просто ненужными, а вот обратно "вычистить" проект гораздо сложнее, чем потом оптимизировать более "чистый".
Я намеренно выражался максимально обощенно, поскольку давать советов в чужом проекте не особо хочется. И многие приведенные соображения могут показаться банальными опытному разработчику, но именно новички на этом и попадаются.
Основная цель рассуждений - это противовес тем высказываениям, зачем нужен еще один файловый менеджер, когда и другие есть. Другие может и есть, а хорошо спроектированных мало.
И типа, "зачем мне нужны файловые менеджеры, если я такой крутой, и знаю кучу всяких там шеллов". ("И при этом хочу тривиальные конфиги" См выше.) Для поддержки пользователей, вот зачем. Если таковые имеются, и не один в собственном соку своей крутости варишься.
И качественные консольные приложения являются в этой области хорошей альтернативой всяким навороченным веб-интерфейсам. Веб-интерфейсы обычно тянут за собой сложную кучу различных технологических звеньев, как на клиентской, так и на серверной стороне.
>>Имеется в виду SSH? Если да, то никакой особенной поддержки нет, просто можно логиниться удалённо и там запускать программу как любую другую консольную.
>>Так работает. Про сжатие исходников, честно говоря, не слышал.
>
>Я лишь хотел сказать о потенциале применения - удаленная поддержка пользователей в
>условиях изолированных программных окружений с минимальным количеством подключаемых библиотек.Да, наверно минимум зависимостей сделаем одной из главных политических линий.
>Также в таких окружениях часто жестко лимитируется количество используемой памяти, как оперативной,
>так и энергонезависимой.С этим сложнее, памяти он кушает побольше чем тот же мц, на десктопе это незаметно, а в более других ситуациях может быть серьёзнее.
>Потом гораздо проще будет оптимизировать, если действительно понадобится.
>
>А вот задача максимальной изоляции непривилигированных пользователей - это как раз напрямую
>зависит от общей чистоты проекта.
>
>Что же касается лимитов, то тут лучше учитывать, что по мере развития
>техники, эти лимиты все более и более смягчаются, и многие оптимизации,
>которые в начале пошли в ущерб "чистоте", потом оказываются просто ненужными,
>а вот обратно "вычистить" проект гораздо сложнее, чем потом оптимизировать более
>"чистый".Поэтому то я и не сильно беспокоюсь на этот счёт, хотя конечно стараюсь придерживаться разумных пределов
>И типа, "зачем мне нужны файловые менеджеры, если я такой крутой, и
>знаю кучу всяких там шеллов". ("И при этом хочу тривиальные конфиги"
>См выше.) Для поддержки пользователей, вот зачем. Если таковые имеются, и
>не один в собственном соку своей крутости варишься.
>
>И качественные консольные приложения являются в этой области хорошей альтернативой всяким навороченным
>веб-интерфейсам. Веб-интерфейсы обычно тянут за собой сложную кучу различных технологических звеньев,
>как на клиентской, так и на серверной стороне.Да и просто, есть сила привычки, я, например, по максимуму стараюсь использовать консольные приложение, просто привык и мне так удобнее, оттого и писал, собственно проект
>Да, наверно минимум зависимостей сделаем одной из главных политических линий.По прежнему не хочу давать советов.
Лишь скажу, то что выяснил на собственном трудном опыте. Хотя возможно вы это и без меня уже знаете.В своих поисках оптимальных решений, я выяснил, что просто ставить цель в виде минимизации зависимостей оказывается еще не достаточно. Крайне важно учитывать еще и характер зависимостей.
Поучительным здесь может быть история многочисленных фреймворков на Руби. Когда-то RubyOnRails (не без влияния которого кстати создавался питоновский Django) считался очень модульным и легковесным по сравнению с существовавшими тогда монстрами на java. Однако в последствии ROR сам был подвергнут сильной критике, и теперь уже сам считается монстром. А разработчики фреймворков теперь уже похоже соревнуются, кто из них создаст наиболее легкий и слабозависимый проект.
Это конечно все отдельная тема разговора, могу лишь привести на вскидку заметку из неплохого блога одного рубиниста. Он выделяет два вида связности - coupling and cohesion.
"Why coupling is always bad / Cohesion vs. coupling" http://www.hokstad.com/why-coupling-is-always-bad-cohesion-v...Хотя с позиций абстрактной математики и декларативного программирования это все выглядит гораздо прозрачнее.
>Да и просто, есть сила привычки, я, например, по максимуму стараюсь использовать консольные приложение, просто привык и мне так удобнее, оттого и писал, собственно проект
Это не просто сила привычки. Это скорее верная интуиция и не стоит это недооценивать.
Дело в том, что консоль имеет более эффективные математические модели, чем оконные системы. С точки зрения представления и обработки абстрактных данных. А следовательно, более эффективные и емкие реализации пользовательского интерфейса. Правда ценой понятности для пользователей с менее развитым абстрактным мышлением.
А о разнице между сложностью и понятностью я уже писал здесь в постах при обсуждении конфигурационных файлов.
Существует распространенное заблуждение, что якобы оконные, а тем более графические оконные интерфейсы, являются значительным техническим прогрессом по сравнению с консольными и потоковыми.
На самом деле это совершенно не так. Технический прогресс всего лишь позволил создавать более интуитивно понятные, имеющие аналогию с физическими объектами, но и более ресурсоемкие оконные интерфейсы. Однако близость к физической интерпретации делает "графику" на самом деле менее выразительной для абстрактных данных и логической обработки.
Консольные и потоковые интерфейсы имеют с этой точки зрения огромное преимущество. И могут быть реализованы на более "слабой" аппаратуре без потери всей их мощи. Потому они давно и использовались, а не потому что они якобы устаревшие. Кроме того, после волны ажиотажа вокруг "графики", все постепенно возвращается на круги своя.
Поэтому можно в этом направлении продолжать спокойно совершенствоваться и не бояться при этом "устареть". И это особенно актуально с развитием вычислительной техники все более в сторону мобильных устройств. В сторону сочетания вычислительной мощи и физической неприхотливости и абстрактности интерфейсов.
Что же касается привычек, то это наоборот, привычки обычно мешают освоить консоль как пользователям, так и разработчикам. Вернуться к "графике" можно в любой момент, вопрос - зачем.
Мужчина, если вы оспариваете, что>[xyz]
>
>skin = seablueэто на порядок читабельнее, чем
> let("skin", "seablue", sect="xyz")
вам необходимо заниматься чем-то, не требующим никакого общения с пользователями. Подозреваю, что на читабельность вашего кода другими разработчиками вы смотрите с таким же дружелюбием?
>Мужчина, если вы оспариваете, чтоприведите мне то место, где я по-вашему оспаривал, что
[xyz]
skin = seablueчитабельнее, чем
let("skin", "seablue", sect="xyz")
А Ctrl+O оно может?
Для меня это самая главная вещь в файловых менеджерах.
Нет, Ctrl+O к сожалению пока не умеет, но в планах на будущее есть.
О, блин, опять холивар...
Нужно-не_нужно - рассудит время.
Мне представляется, что, если тут можно свою функциональность добавлять - то это оч-чень даже забавно.
В конце-концов - "JustFor Fun" $)
Во! Предлагаю формализовать (в хорошем смысле слова) способы подключения в пакет новых скриптов.
>Во! Предлагаю формализовать (в хорошем смысле слова) способы подключения в пакет новых скриптов.import <module_name>
В Питоне уже подключение новых скриптов формализовано.
Или вам Far'a c Total Commander'ом с их ужасными плагинами.
>Или вам Far'a c Total Commander'ом с их ужасными плагинами.толстовато..
>Или вам Far'a c Total Commander'ом с их ужасными плагинами."А пуркуа бы и не па?"
Схема прекрасно себя зарекомендовавшая. FireFox, Chrome, emacs... Да мало ли примеров "модульноых" решений функциональности?
Питон, опять же :)А что касается "двухпанельных файловых менеджеров"... Так ведь удобно же! Вот только не говорите мне, что на память помните содержание всех системных каталогов, или что вам удобно просматривать многометровые листинги ls.
О чем именно вы говорите? Так играючи ставя в один ряд FireFox, Chrome, emacs и Питон. Интересно по какому признаку.Вы хотите сказать, что я что-то имел против модульности? Особенно с учетом того, что я писал о модульности чуть выше. Интересно было бы узнать, что такое "модульность" в вашем понимании.
А то до вас уже некоторые пытались точнее сформулировать мысли в дискуссии о конфигурационных файлах (см. выше), но у них ничего не получилось.
Поэтому тоже хотелось бы поточнее узнать, что конкретно вы имели в виду в ваших невнятных и обрывочных рассуждениях.
P.S. На всякий случай. Если так не было понятно. Я пропустил слово.
>>Или вам Far'a c Total Commander'ом с их ужасными плагинами.Или вам *мало* Far'a c Total Commander'ом с их ужасными плагинами.
Спасибо за прогу, пока до mc конечно не дотягивает, но время покажет.
Опа, во FreeBSD уже! Быстро работают.
>Опа, во FreeBSD уже! Быстро работают.Ага, уже и в арч залили тоже )
А потому что все наши - и автор, и maintainer и коммиттер :)
А каким образом он умудряется так кошмарно тормозить? При входе в большую директорию тупит пару секунд ворочая диском - такое чувство, что рекурсивный find делает.
Кроме того, не видно какая кнопка подсвечена в диалогах. В целом начинание хорошее - помойку под названием mc давно пора заменить чем-то более модульным, но эти явные ляпы надо исправить.
>Кроме того, не видно какая кнопка подсвечена в диалогах. В целом начинание
>хорошее - помойку под названием mc давно пора заменить чем-то более
>модульным, но эти явные ляпы надо исправить.А вот с этим непонятно. На активной кнопке установлен курсор, всё должно работать.
>А вот с этим непонятно. На активной кнопке установлен курсор, всё должно
>работать.Курсора не видно. Выделив все в терминале таки заметил - обычный шрифт - темно-синее на сером, выделение - черное на сером. Увидеть невозможно. Выделяй всю кнопку инвертированием цветов. В чекбоксах такой же ужас, только там черный и темно-серый на сером. Темно-серый от черного почти не отличается.
>>А вот с этим непонятно. На активной кнопке установлен курсор, всё должно
>>работать.
>
>Курсора не видно. Выделив все в терминале таки заметил - обычный шрифт
>- темно-синее на сером, выделение - черное на сером. Увидеть невозможно.
>Выделяй всю кнопку инвертированием цветов. В чекбоксах такой же ужас, только
>там черный и темно-серый на сером. Темно-серый от черного почти не
>отличается.А можно скриншот, ОС и терминал какой узнать? Лучше на мыло, чтоб здесь не спамить. syhpoon AT syhpoon.name
Спасибо
>А можно скриншот, ОС и терминал какой узнать? Лучше на мыло, чтоб
>здесь не спамить. syhpoon AT syhpoon.nameЛень на мыло, сорри.
http://i082.radikal.ru/1001/ad/82a3b4e18325.png
Это FreeBSD 8.0, rxvt-unicode (aterm выглядит также).
Вот это в xterm, я так понимаю должно выглядеть так:
http://s55.radikal.ru/i149/1001/53/efbcc950ef6d.pngНа самом деле у меня своя цветовая схема и там foreground равен светлосерому, без нее фон курсора белый, но все равно плохо видно. Лучше действительно подсвечивать всю кнопку явно заданными цветами.
>Лень на мыло, сорри.
>http://i082.radikal.ru/1001/ad/82a3b4e18325.png
>Это FreeBSD 8.0, rxvt-unicode (aterm выглядит также).
>Вот это в xterm, я так понимаю должно выглядеть так:
>http://s55.radikal.ru/i149/1001/53/efbcc950ef6d.png
>
>На самом деле у меня своя цветовая схема и там foreground равен
>светлосерому, без нее фон курсора белый, но все равно плохо видно.
>Лучше действительно подсвечивать всю кнопку явно заданными цветами.Да, должно выглядеть как в xterm, сделаю кнопку более контрастной.
>А каким образом он умудряется так кошмарно тормозить? При входе в большую
>директорию тупит пару секунд ворочая диском - такое чувство, что рекурсивный
>find делает.Пока он считывает весь список файлов в память, на следующий релиз запланирована оптимизация как раз по этому поводу.
>Пока он считывает весь список файлов в память, на следующий релиз запланирована
>оптимизация как раз по этому поводу.Т.е. рекурсивно?! Если так, надо не оптимизировать, а руки отрывать. Вход в директорию не должен быть медленнее ls -l, а в идеале вообще ls (т.е. даже без stat'ов, в панели все равно только список файлов показывается без атрибутов, а для stat'ов нужен простой кэш, чтобы не читать их каждый раз при перемещении курсора).
>>Пока он считывает весь список файлов в память, на следующий релиз запланирована
>>оптимизация как раз по этому поводу.
>
>Т.е. рекурсивно?! Если так, надо не оптимизировать, а руки отрывать. Вход в
>директорию не должен быть медленнее ls -l, а в идеале вообще
>ls (т.е. даже без stat'ов, в панели все равно только список
>файлов показывается без атрибутов, а для stat'ов нужен простой кэш, чтобы
>не читать их каждый раз при перемещении курсора).Не рекурсивно, просто на каждый файл создаётся VFS объект, с которыми потом происходит дальнейшая работа.
>Не рекурсивно, просто на каждый файл создаётся VFS объект, с которыми потом
>происходит дальнейшая работа.Видимо это и тормозит, потому что заход в директорию, содержащую 1800 директорий уже занимает около секунды, даже без чтения диска.
>>Не рекурсивно, просто на каждый файл создаётся VFS объект, с которыми потом
>>происходит дальнейшая работа.
>
>Видимо это и тормозит, потому что заход в директорию, содержащую 1800 директорий
>уже занимает около секунды, даже без чтения диска.Безусловно, не зря же я говорил про оптимизацию. Сейчас это просто стандартный питоновский список. Хочу заменить его на нечто вроде ленивого списка, чтоб читал и создавал объекты только по мере необходимости. Кроме выигрыша в скорости также получаем выигрыш по памяти.
Блин, не думал что питон столько времени тратит на создание 2k объектов.
>Блин, не думал что питон столько времени тратит на создание 2k объектов.
>Ну даже mc не моментально входит в каталоги с большим количеством файлов, а тут уж прйдётся только такими окольными путями оптимизировать.
>Ну даже mc не моментально входит в каталоги с большим количеством файлов, а тут уж прйдётся только такими окольными путями оптимизировать.Вот окольными путями здесь лучше не надо. А то получится то, о чем уже шла речь выше про оптимизацию.
Уже существует достаточное количество хорошо зарекомендовавших себя паттернов, связанных с разделением данных и представлений.
Тем более, в двухпанельном редакторе интерфейс достаточно фиксированный.
Общая суть - не создавать структуры, которые _безусловно_ отражаются на объекты в другой системе. А создавать только такие структуры, которые манипулируют исключительно объектами, явно участвующими в процессах разрабатываемой системы. В любом случае это будет вызывать усложнение. Вопрос, на каком уровне обобщения. Частности и конкретика - это тоже конечно очень хорошо, только этого слишком быстро станет очень много.
Всякое там кеширование еще захочется вставить и пошло-поехало все это между собой перевязывать. А сложность растет комбинаторно, если не предпринимать мер по развязке подсистем.
Пользователям, вечно жалующимся на скорость, все равно никогда не угодите и впечатление на них никогда не произведете, потому что они всегда лучше знают, как надо было делать. А вот проглядеть изящные решения очень легко, если слишком торопиться с оптимизацией. А обратно откатывать - пользователи еще сильнее жаловаться начнут, что их любимый функционал убрали.
>[оверквотинг удален]
>
>Всякое там кеширование еще захочется вставить и пошло-поехало все это между собой
>перевязывать. А сложность растет комбинаторно, если не предпринимать мер по развязке
>подсистем.
>
>Пользователям, вечно жалующимся на скорость, все равно никогда не угодите и впечатление
>на них никогда не произведете, потому что они всегда лучше знают,
>как надо было делать. А вот проглядеть изящные решения очень легко,
>если слишком торопиться с оптимизацией. А обратно откатывать - пользователи еще
>сильнее жаловаться начнут, что их любимый функционал убрали.Ну собственно ленивая вычитка как раз один из таких известных паттернов, когда есть большое количество данных но одновременно отображается только небольшое их подмножество, и вычитывать файлы по мере надобности вполне приемлемое решение, оно никак не повлияет на внешний функционал но существенно увеличит скорость входа в каталоги с большим количеством файлов.
Этот тикет у меня чуть ли ни с первой версии висит ещё :)
Попробуем еще рассуждать от противного.Был, знаете ли, раньше один такой мыслитель и практик по имени Противный. Его именем потом и назвали этот вид рассуждений.
Кроме того, следует всегда иметь в виду, что "противно" - от слова "против". А вовсе не от слова "уродливо", как это многие воспринимают. Поэтому если кому-то противны вы и то, что вы делаете, из этого вовсе не следует, что у вас какие-то проблемы. Скорее это проблемы у него, что он не может ужиться с тем, что вы что-то делаете по-своему. Что вы что-то делаете против его мнеия и при этом хорошо себя чувствуете.
Поэтому многие спешат поставить знак равенства между противным и уродливым. Однако если спешить с каждым соглашаться, как раз скорее всего уродство и получится.
Так вот, рассуждения от Противного.
Насколько ценнее станет ваша разработка, если она научится быстро открывать каталоги. И будет иметь тривиальные и примитивные конфиги. Таких приложений и так очень много. Насколько они ценны?
В том-то и дело, что это очень хорошо и давно известно, как сделать так, чтобы каталоги быстро открывались, и чтобы конфиги были понятны любому чайнику, при условии, что он понимает о чем приложение (а то еще бывает и так, что конфиги понятны, а приложением все равно пользоваться не умеют).
Потому большинство в первую очередь это и реализуют.
Однако, если это известно, как делать, значит это можно сделать в любой момент. Стоит ли с этим спешить, чтобы кому-то понравиться.
Не лучше ли сосредоточиться на том поиске и понимании того, в чем ваша уникальность и в чем ваше преимущество. При понимании этого и при РЕАЛИЗАЦИИ собственных преимуществ и талантов, все остальное достигается без особых усилий.
Чем больше ваш проект будет набирать известности, тем больше будет появляться тех, кто будет заявлять, что у вас что-то не так.
Поэтому каждый раз, когда слышите упреки, важно успеть вспомнить, зачем вообще вы все делаете. Ради кого. Обязаны ли вы кому-то.
С другой стороны, если функционалом программы является, по сути, навигация по каталогам, и есть явное узкое место, почему бы его не убрать? И это совсем не потакание или ещё что, нельзя же заняв круговую оборону сидеть и принимать в штыки любое предложение со стороны пользователей ( я не про конфиги :), только ради принципа что разработчику виднее. Я прислушиваюсь к пожеланиям, но стараюсь фильтровать по собственным критериям ценности.
Это не мой проект. Я лишь привел альтернытивные критерии по отношению к банальным критериям потребительской полезности и функциональности.>С другой стороны, если функционалом программы является, по сути, навигация по каталогам,
Если целью является создание именно средство для навигации по каталогам, тогда все конечно уже решено.
Если целью является создание более абстрактного интерфейса для облегчения полу-ручных операций типа "источник-назначение", для работы с абстрактными _парами_ объектов и в качестве логического продолжения абстраткных потоковых моделей и композиций автоматов, на базе которых построены утилиты и консоль Юникса. Тогда лучше не спешить с определением, где именно может возникнуть узкое место.
Отправной точкой в любом случае является интерфейс пользователя. Иначе зачем вообще нужны эти две панели. Вопрос к чему этот интерфейс планируктся прикладывать. Просто к файловой системе? Однако ФС сама по себе является абстрактной моделью данных.
В качестве примера можно привести Far и Total Commander. Потенциал применения там гораздо шире, чем просто файловая система. Однако изначальная сильная привязанность к конкретным API, а не к моделям, вызывает такие муки с плагинами. Хотя некоторым эти плагины кажутся верхом совершенства.
>и есть явное узкое место, почему бы его не убрать?
Если это не вызывает внутренних противоречий, то почему бы не убрать, да.
>И это совсем не потакание или ещё что, нельзя же заняв круговую оборону сидеть и принимать в штыки любое предложение со стороны пользователей ( я не про конфиги :),
Тут все очень просто. Если это идет против собственных желаний создателя, то это будет ни что иное, как потакание. Если это идет в согласии с собственными желаниями, то значит данному пользователю повезло.
А оборона в любом случае подразумевает нападение. Если создатель в себе уверен, то на него очень накладно нападать, даже если он не пытается обороняться.
>только ради принципа что разработчику виднее.
Вы считаете это плохим принципом? Значит вы не уверены в собственном вИдении. Тогда лучше вооружиться принципом полезности, до тех пор пока собственное вИдение окончательно не сформируется. В этом нет ничего постыдного, поскольку очень немногие этого на самом деле достигают.
>Я прислушиваюсь к пожеланиям, но стараюсь фильтровать по собственным критериям ценности.
А как можно сформировать собственные критерии ценности, если прислушиваться к чужим пожеланиям. Ценности и формируются из желаний. Чужие желания - чужие ценности.
Я всего лишь привел критерии для понимания собственной _самостоятельности_ в принятии решений. Есть проекты, которые движутся преимущественно ПОЖЕЛАНИЯМ пользователей. Есть проекты, которые движутся преимущественно ПОЖЕЛАНИЯМИ создателей.
Я не утверждаю, что одно чем то лучше или хуже другого. Однако это принципиальный показатель, как разработчик позиционирует себя по отношению к себе и к своему творчеству.
Вопрос именно в том, насколько создатель не боится и не стесняется поставить собственные желания во главу угла в собственном творении.
Еще раз, здесь нет никаких руководств к действиям. Это всего лишь критерии к самопониманию и пониманию своего творчества.
А также кое-какие идеи, которые ни к чему не обязывают.
