Помойка 0

IMHO чем больше помойка тем сложнее там что-либо отрыть, огромное количество почти идентичных программок лично меня путают при поиске нужной. Своя же маленькая помоечка это всегда круто (тот же собственный рабочий стол :-) ) ктому же, если появляются вопросы по алгоритмам — вот они авторы — на форуме!

Короче, нормальная идея. Я — за.

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

2 UT:

Ну так как там, на счет иксовых виджетов?

2 LONGOBARD:

Есть смысл разместить тут твой прасер конфига. Я сам писал парсер конфига для своих проектов, и мне он кажется кривым.

Да оно, конечно, пожалуйста, вот только причешу их немного (виджеты). Только вот ты, батенька об одной вещи не подумал. Догадайся, о какой? :-) Догадался? Если человек кладет что-то более сложное, чем HelloWorld на всеобщее обозрение, то он может захотеть некоторые условия поставить на использование выложенного. Например, заЖоПоЭлить его… Ты к ентому как отнесешься?

Good Luck,

UT

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

Что-то все слишком носятся с этими лицннзиями, проще надо быть….. Ну каму есть резон заморачиваться лецензионной чистотой собранием примеров на nixp.ru?

главное — создать прецендент»

чтобы понятно было, о чём, собственно, речь :)

Я в целом идею поддерживаю, к выходным могу выложить свои иксовые заморочки с относительно подробным описанием что, где и зачем. Все равно надо было этот бардак разгребать, так хоть дополнительный стимул будет. Условие одно — код заGPLен. Ну это можно было и так догадаться… :-) Если условие приемлемо — говорите куда скинуть.

Good Luck,

UT

Куда скинуть — это у Шурупу. Надо бы хоть временное место найти. И еще, хорошо бы какое-нить пояснение с этими виджетами скинуть.

PS

ЖиПиЭл, так ЖиПиЭл, мне-то что….

Кстати, две вещи:

1. От Шурупа так ничего и не слышно.

2. Я уже выкладывал одно свое произвЕдение, http://www.nixp.ru/cgi-bin/forum/YaBB.pl?board=coding;action=display;num=1078551243

можно бросить на развод… :-)

Good Luck,

UT

брошу. Как только будет куда.

>> 1. От Шурупа так ничего и не слышно.

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

/me приехал с отдыха :) И даже траф купил (кста всем завидовать: 600 Мб за 864 р :) (пров тарифы поменял)).

Парсер — да не проблема, там всего-то хидер да реализация + пример использования. Могу доку небольшую накатать. Тока скажите куда все енто добро сувать :)

Тока вот ничего шо там классик называется FL_ConfigParser? Переименовать его или болт забить?

Тарболл с причесанным парсером (нормальное название + убран мат и комменты по типу «ща посплю и не забыть доделать енто хрень») готов. Куды лить?

ЗЫ: С днюхой меня :)

С днюхой тебя. Пили Шурупа. Он что-то делает.

Долго делает :) Да там просто предлагаю создать раздел по типу soft, где тарболльчики с сырцами и доками к ним.

Кста как нормальную доку написал или не очень понятную? Какие моменты нада прояснить?

Использование класса ConfigParser.
1)Требования к конфигурационному файлу.
Конфигурационный файл имеет следующие свойства:
Знак # означает начало комментария, все что после него в этой строке парсер игнорирует
Знак \ означает перенос строки. Пример:
строку
        very long string
можно записать как
        very \
        long string
При прасинге \ будет заменен на пробел, так что
long\
param
превратится не в longparam а в long param. Учтите это.
Регистр букв имеет значение.
В конфиге могут быть теги (парные) вида
        
                sometnig.......
        </SomeTag>
Теги могут быть вложенные (кол-во уровней вложенности неограничено). Закрытие тега обязательно. Пробелы между скобками и названием тега не допускаются.
В конфиге могут быть параметры вида:
        SomeParameter His Arg or Args
        SomeAnotherParameter: His arg(s)
Двоеточие после имени параметра необязательно.
Пустые парные теги не допускаются. Т.е. Конструкции вида
        
        </tag>
Будет понята парсером как ошибочная. Тем более что и смысла она никакого не несет :)
Параметры без аргументов также считаются ошибкой.
2)Обрабатываемые ошибки
Парсер обрабатывает только синтаксические ошибки, т.е. Ошибочными он считает только те конструкции конфига, которые не соответствуют вышеизложенным правилам. Проверка содержимого возложена на программиста.
3)Представление конфига в дереве, создаваемом парсером
Конфиг подобного синтаксиса представляет собой небинарное дерево. Я его представил как спикок из элементов следующего вида:
struct element
{
        string tag, arg;
        list < struct element > content;
};
т.е. В каждом элементе списка есть еще один список. Благодаря этому достигется неограниченное количество уровней вложенности. В данном случае во многих алгоритмах введен еще и указатель на родительский список, но я от его использования отказался за ненадобностью.
4)Использование парсера.
В Вашей программе вы должны включить хидер config_paser.h и прилинковать config_parser.o. Теперь о использовании:
пример:
        bool HasErrors = false;
        ConfigParser * parser = new ConfigParser( path );
        if ( !parser->Correct() )
                return;
        list < struct element > * tree = new list < struct element >;
        * tree = parser->GetConfigTree();
        DoSomethingWithTree (tree);
        delete tree;
        delete parser;
Теперь дерево получено, можно его обрабатывать (в данном случае в функции DoSomethingWithTree):
string tag, arg;
        list < struct element >::reference * ref = new list < struct element >::const_reference;
        while ( !tree->empty() )
        {
                * ref = tree->front();
                //Теперь обходим все дерево
                if ( !ref->content.empty() )
                {
                        //Це тег
                        if ( ref->tag == "SomeTag" )
                        {
                                //Обрабатываем его
                        }
                        else
                                cerr << "Unknown tag " << tag;
                }
                else
                {
                        //Це просто параметр  :)
                        tag = ref->tag;
                        arg = ref->arg;
                        if ( tag == "some_param" )
                        {
                                if ( !SomeParam.empty() )
                                {
                                        cerr << "SomeParammay be set only once!\n";
                                        HasErrors = true;
                                }
                                else
                                        SomeParam= arg;
                        }
                        else
                                cerr << "Unknown parameter " << tag;
                }
                tree->pop_front();
        }
        delete ref;
Вопщем в дереве логика такая: если это элемент и его content.empty() - false - то это парный тег. Если же true - то параметр. В элементе поле tag держит название тега/параметра, а arg - его аргумент. Символа \n в конце нету. Т.е. Например такая конструкция
SomeParam AndHisArg
</SomeTag>
Будет представлена так:
tag=SomeTag
arg=HisArg
content.empty() = false // это говорит о том, что это-тег.
теперь переходим в content его (т.е. Обьекту типа list::const_reference присваиваем content этого элемента).
Теперь в получеенном элементе
tag=SomeParam
arg=AndHisArg
content.empty = false //это говорит о том что это-параметр
Т.к. Пустых парных тегов быть не может (они отлавливаются на стадии проверки парсером конфига и пишется сообщение об ошибке, то отпадает необходимость в поле type структуры struct element, показывающем тип элемента (тег/параметр), т.к. content.empty() определяет это без проблем.
5) Функции.
Функция bool Correct (void) const;
Возвращает true в случае если конфиг не содержит ошибок (не нарушает условия, описанные в пункте 1).
Возвращает false в противном случае. Описания всех ошибок парсер пишет в stderr.
Функция list  GetConfigTree (void) const;
Возвращает дерево конфига. Если конфиг не корректен - то дерево пустое.

Одобрям. Кончик апача парсить предлогаешь? Или XML? Очень похоже…

Апача. Хотя по идее и XML переварит, но обрабатывать полученное дерво будет геморней.

http://www.nixp.ru/cgi-bin/forum/YaBB.pl?board=trash;action=display;num=1092051171;start=0#0

Закачал, жду подтвержения :)

2 decvar: для парсинга XML конфига парсер очень нерационален, он заточен под tag-param конфиг, по типу того что заюзан в апаче или профтпд. Для обработки XML конфига есть туча либ. Парсер мой мона использовать и для XML, но это весьма ракообразный способ.

Ну как бы вот :)

http://www.nixp.ru/cgi-bin/forum/YaBB.pl?board=trash;action=display;num=1092079960;start=0#0

2 Шуруп: 10x за помойку :)

2all: надо бы еще чего-нить туда. Виджетов :) Или еще чего-нить. decvar а как насчет твоего инсталлера?

Инсталлер будет. И кстати, теперь пАмойка официально работает. Еще будет кое что на C#. Ну и так далее, разгредаю свои запасы.