Имена методов и классов могут менятся, но применая логика сохранится... То есть всегда будет старший метод, который вызывает младший, в младшем будет несколько вызовов записи чтения в\из порта (устройства).
Как бы и чем бы красивее это пропарсить чтобы в итоге получить инфу сколько для каждого метода вызывались дочерние, с каким результатом закончились итд...?
Здравствуйте, ironwit, Вы писали:
I> Как бы и чем бы красивее это пропарсить чтобы в итоге получить инфу сколько для каждого метода вызывались дочерние, с каким результатом закончились итд...?
Парсить — ручками. А переделать формат лога нельзя? ИМХО, в нём слишком много неинформативных символов.
Т.е.
<Номер строки>^<Номер предка>^<Направление передачи>^<Имя метода>^<Команда>^<Результат>
Насколько велик лог и насколько часто надо проверять данные?
Если там достаточно много данных и часто проверяются, то я бы привёл их к одному виду и залил ручками в БД в виде иерархии, а потом уже с ними работал. Можно поюзать к.-либо "виртуальную" БД.
... <<#5 — 10 DJ Rodriguez My magic carpet>>
Не восхрапи на работе, ибо храпом своим разбудишь начальника своего.
On Sat, 05 Nov 2005 08:33:29 GMT
"_spin_" <45342@users.rsdn.ru> wrote:
> Здравствуйте, ironwit, Вы писали: > > I> Как бы и чем бы красивее это пропарсить чтобы в итоге получить инфу сколько для каждого метода вызывались дочерние, с каким результатом закончились итд...? > > Парсить — ручками. А переделать формат лога нельзя? ИМХО, в нём слишком много неинформативных символов.
переделать то можно, но одно из требований — удобочитаемость > > Например, так: > 1^0^1^TIPC.ReadMomentData (04.11.05 13:58:27 859)^^ > 2^1^1^TIPC.ReadMOMMaskData (04.11.05 13:58:27 859)^^ > 3^2^1^TFT3.ExecRequest (04.11.05 13:58:27 859)^ACommand = 7^ > 4^3^1^TFT3.SinchSend (04.11.05 13:58:27 859)^^Result = 0 > > Т.е. > <Номер строки>^<Номер предка>^<Направление передачи>^<Имя метода>^<Команда>^<Результат>
та хз. надо подумать... > > Насколько велик лог и насколько часто надо проверять данные?
в ТЗ написано оперативно и ретроспективно > > Если там достаточно много данных и часто проверяются, то я бы привёл их к одному виду и залил ручками в БД в виде иерархии, а потом уже с ними работал. Можно поюзать к.-либо "виртуальную" БД.
та я тоже к БД склоняюсь... но мало ли, вдруг что умные люди посоветуют...
On Sat, 05 Nov 2005 09:57:33 GMT
"_spin_" <45342@users.rsdn.ru> wrote:
> Если время работы — не критичный параметр, то можно пойти другим путём — сразу писать в БД, а параллельно заполнять лог в удобочитаемом виде.
время очень важно. основной софт который ведет логирование желательно напрягать как можно меньше .... > > А может быть просто писать лог в XML-формате? И парсить его будет легче, да и по структуре лог очень похож на XML (открытие и закрытие тегов и проч.).
та хз... я вот думаю.. это ведь скажется на времени именно сохранения в файл, верно?
Здравствуйте, ironwit, Вы писали:
I>та хз... я вот думаю.. это ведь скажется на времени именно сохранения в файл, верно?
Разница в скорости очень маленькая, это во-первых. А во-вторых, кто мешает организовать дополнительный поток, который будет писать в файл и во входную очередь которого будет присать данные основной поток? Тогда у основного потока не будет привязки в дисковым операциям и всё будет работать ОК. А то, что запись в лог будет на доли секунды отставать от выполненных действий — не критично.
... <<#2 — 01 Xaver Fisher trio Follow me>>
Не восхрапи на работе, ибо храпом своим разбудишь начальника своего.
On Sat, 05 Nov 2005 10:22:16 GMT
"_spin_" <45342@users.rsdn.ru> wrote:
> Здравствуйте, ironwit, Вы писали: > > I>та хз... я вот думаю.. это ведь скажется на времени именно сохранения в файл, верно? > > Разница в скорости очень маленькая, это во-первых. А во-вторых, кто мешает организовать дополнительный поток, который будет писать в файл и во входную очередь которого будет присать данные основной поток? Тогда у основного потока не будет привязки в дисковым операциям и всё будет работать ОК. А то, что запись в лог будет на доли секунды отставать от выполненных действий — не критично.
не все так просто. В этом приложении уже может быть до 5-10 потоков. и из каждого потока идет логирование в свой файл. Так что нужно заводить еще по потоку на поток
Здравствуйте, ironwit, Вы писали:
I>не все так просто. В этом приложении уже может быть до 5-10 потоков.
Да хоть 30. Это не столь важно в данном случае.
I>и из каждого потока идет логирование в свой файл. Так что нужно заводить еще по потоку на поток
Можно и по потоку на каждый файл, а можно и иначе:
Поток записи в файл имеет несколько входных очередей, с каждой из которых связан файл лога. Т.е. все потоки сбрасывают логи с один поток, но каждый в свою очередь (либо в общую, но в логе указывают свой идентификатор), а поток записи просто держит несколько файлов постоянно открытыми на запись и по мере поступления данных сливает их на диск.
С другой стороны, если обновление логов может быть не непрерывным, то я бы сделал сливание логов потоку записи в файл через определённое время (секунды или имнуты). Это снизит вероятность взаимоблокировки процессов при синхронизации и разгрузит диск, т.к. запись в файл будет идти блоками, а не по одной записи.
... <<#4 — 11 Michelle Weeks The light (Main mix)>>
Не восхрапи на работе, ибо храпом своим разбудишь начальника своего.
On Sat, 05 Nov 2005 13:49:54 GMT
"_spin_" <45342@users.rsdn.ru> wrote:
> Здравствуйте, ironwit, Вы писали: > > I>не все так просто. В этом приложении уже может быть до 5-10 потоков. > Да хоть 30. Это не столь важно в данном случае. > > I>и из каждого потока идет логирование в свой файл. Так что нужно заводить еще по потоку на поток > Можно и по потоку на каждый файл, а можно и иначе: > Поток записи в файл имеет несколько входных очередей, с каждой из которых связан файл лога. Т.е. все потоки сбрасывают логи с один поток, но каждый в свою очередь (либо в общую, но в логе указывают свой идентификатор), а поток записи просто держит несколько файлов постоянно открытыми на запись и по мере поступления данных сливает их на диск. > > С другой стороны, если обновление логов может быть не непрерывным, то я бы сделал сливание логов потоку записи в файл через определённое время (секунды или имнуты). Это снизит вероятность взаимоблокировки процессов при синхронизации и разгрузит диск, т.к. запись в файл будет идти блоками, а не по одной записи.
Спасибо, чтото такое и думалось... Но это решит (точнее немного изменит функцию логирования)
а вот как ее разбирать? ... все таки переделать в xml файл... тогда его будет хуже смотреть, разве что дописать программу внешнюю для отображения xml файла...
Здравствуйте, ironwit, Вы писали:
I>Спасибо, чтото такое и думалось... Но это решит (точнее немного изменит функцию логирования) I>а вот как ее разбирать? ... все таки переделать в xml файл... тогда его будет хуже смотреть, разве что дописать программу внешнюю для отображения xml файла...
XML-файл прекрасно просматривается в IE, достаточно наглядно, попробуйте. Особенно чётко видно вложенность операций и проч.
Могу скинуть набор классов для работы с XML.
... <<DuDuLa — Трек 5>>
Не восхрапи на работе, ибо храпом своим разбудишь начальника своего.
On Sat, 05 Nov 2005 15:26:50 GMT
"_spin_" <45342@users.rsdn.ru> wrote:
> Здравствуйте, ironwit, Вы писали: > I>а вот как ее разбирать? ... все таки переделать в xml файл... тогда его будет хуже смотреть, разве что дописать программу внешнюю для отображения xml файла... > > XML-файл прекрасно просматривается в IE, достаточно наглядно, попробуйте. Особенно чётко видно вложенность операций и проч. > > Могу скинуть набор классов для работы с XML.
во, если под делфи то громадное спасибо. Кидайте прямо на ironwit_pisem.net
Завтра и просмотрю...
Posted via RSDN NNTP Server 1.9
Я не умею быть злым, и не хочу быть добрым.
Re[11]: парсер
От:
Аноним
Дата:
06.11.05 12:51
Оценка:
Здравствуйте, ironwit, Вы писали:
I>On Sat, 05 Nov 2005 15:26:50 GMT I>"_spin_" <45342@users.rsdn.ru> wrote:
>> Здравствуйте, ironwit, Вы писали: >> I>а вот как ее разбирать? ... все таки переделать в xml файл... тогда его будет хуже смотреть, разве что дописать программу внешнюю для отображения xml файла... >> >> XML-файл прекрасно просматривается в IE, достаточно наглядно, попробуйте. Особенно чётко видно вложенность операций и проч. >> >> Могу скинуть набор классов для работы с XML. I>во, если под делфи то громадное спасибо. Кидайте прямо на ironwit_pisem.net I>Завтра и просмотрю...
Дык под Delphi 7 и старше есть TXMLDocument — надстройка над MS XML. Элементарно портируется и на младшие версии Delphi (я перетаскивал его на пятерку)
Или вообще заюзай XML Binding (File->New->XML Binding), рулезная весчь.
HotLog.pas provides a multithreaded, object oriented, buffered safe and fully automated log file manager with string formating possibilites, exception describing features, and much more......
... <<DuDuLa — Трек 1>>
Не восхрапи на работе, ибо храпом своим разбудишь начальника своего.
On Sun, 06 Nov 2005 12:51:48 GMT
wrote:
> Здравствуйте, ironwit, Вы писали: > I>во, если под делфи то громадное спасибо. Кидайте прямо на ironwit_pisem.net > I>Завтра и просмотрю... > > Дык под Delphi 7 и старше есть TXMLDocument — надстройка над MS XML. Элементарно портируется и на младшие версии Delphi (я перетаскивал его на пятерку) > Или вообще заюзай XML Binding (File->New->XML Binding), рулезная весчь.
спасибо, с понедельника порою
On Sun, 06 Nov 2005 14:03:16 GMT
"_spin_" <45342@users.rsdn.ru> wrote:
> Здравствуйте, ironwit, Вы писали: > > Только что наткнулся... > > http://www.delphi32.com/vcl/5635 > > Аннотация: > >
> HotLog.pas provides a multithreaded, object oriented, buffered safe and fully automated log file manager with string formating possibilites, exception describing features, and much more......
и ретроспективно 
