Ротация происходит в тот момент, когда приходит новое сообщение, но места в старом файле уже нет. В этом случае создаётся новый файл и новое сообщение записывается уже в него. Плюс можно настроить логер, чтобы ротация происходила в начале дня или при старте приложения.
Ротация происходит в тот момент, когда приходит новое сообщение, но места в старом файле уже нет. В этом случае создаётся новый файл и новое сообщение записывается уже в него. Плюс можно настроить логер, чтобы ротация происходила в начале дня или при старте приложения.
По поводу сжатия. Ну, во-первых, не думаю, что целесообразно делать лимиты в 1Гб при использовании сжатия :) А, во-вторых, если использовать логер в асинхронном режиме ( gQtLogger.moveToOwnThread() )то сжатие будет происходить в отдельном потоке. Тот поток, который вызвал qDebug() это никак не заденет.
Но тут есть один нюанс. В библиотеке используются сжатие встроенное в qt, а оно не умеет сжимать частями, только весь объем целиком. Поэтому перед сжатием весь файл лога должен поместиться в оперативную память. Если это 1Мб, то это не проблема. Если это 1Гб, то памяти может уже и не хватить. Так что не рекомендую использовать сжатие при больших размерах файла.
Да, асинхронный лог действительно имеет небольшую задержку, но это не влияет на точность информации об ошибках. Когда происходит вызов qDebug() или qWarning(), все метаданные фиксируются синхронно в момент вызова. Асинхронность влияет только на момент записи в файл/консоль, но не на содержимое сообщения. Это стандартный подход во всех серьёзных логгерах.
Когда это может быть проблемой:
При краше приложения последние сообщения могут не успеть записаться (для этого есть flush())
При отладке в реальном времени вывод может отставать от действий, но это какие-то доли секунды не заметные человеческому глазу.
Самое главное последовательность сообщений в логе сохраняется в любом случае.
В аду я видел эти всплывающие чаты поддержи. Ужасно бесили, до тех пор пока не занёс их в блоклист. Ни разу не встречалось какое-то адекватное, не раздражающее внедрение, которое помогло бы в работе с сайтом. Обычно они перекрывают контент или как-то моргают, отвлекая и мешая просмотру сайта.
Отличный цикл статей! Афтар пиши ещё!!! Очень жалко, что не было такого, когда я только начинал разбираться с QML. Хотя, даже сейчас, полезно было почитать и разложить все знания по полочкам. QML на сколько прост снаружи, на сколько же сложен внутри.
По моему, именно из-за уборщиц эта идея провальная. Во-первых в эти лючки постоянно будет затекать вода. Во-вторых по краям и при их открытии в них будет скапливаться мусор. Делать в полу какие-либо отверстия — бредовая идея, имхо.
Итоги эксперемента: из 100 сообщений ответило только 5 человек. Первый ответил где-то на 55-м сообщении. Один раз удалось самому с собой пообщаться, в соседних вкладках :) Демаю как хаброэффект утихнет, так это будет единственный способ общения.
Это будет зоопарк. Зашел на сайт с Flash постать плагин для Flash, зашел на сайт с Silverlight, тоже поставь плагин, и для JavaFX поставь плагин, кто еще что придумает?
Спасибо за статью! На основе вашего материала добавил поддержу Sentry в qtlogger: https://github.com/yamixst/qtlogger/blob/main/examples/sentry_example/main.cpp
Ротация происходит в тот момент, когда приходит новое сообщение, но места в старом файле уже нет. В этом случае создаётся новый файл и новое сообщение записывается уже в него. Плюс можно настроить логер, чтобы ротация происходила в начале дня или при старте приложения.
Ротация происходит в тот момент, когда приходит новое сообщение, но места в старом файле уже нет. В этом случае создаётся новый файл и новое сообщение записывается уже в него. Плюс можно настроить логер, чтобы ротация происходила в начале дня или при старте приложения.
По поводу сжатия. Ну, во-первых, не думаю, что целесообразно делать лимиты в 1Гб при использовании сжатия :) А, во-вторых, если использовать логер в асинхронном режиме (
gQtLogger.moveToOwnThread())то сжатие будет происходить в отдельном потоке. Тот поток, который вызвал qDebug() это никак не заденет.Но тут есть один нюанс. В библиотеке используются сжатие встроенное в qt, а оно не умеет сжимать частями, только весь объем целиком. Поэтому перед сжатием весь файл лога должен поместиться в оперативную память. Если это 1Мб, то это не проблема. Если это 1Гб, то памяти может уже и не хватить. Так что не рекомендую использовать сжатие при больших размерах файла.
Верно подмети. QStringView отличная штука. Но у меня есть поддержка Qt 5.9, да и где бы он был уместен в этой библиотеке я не знаю.
А где бы вы его использовали?
Qt API (QMessageLogContext и qDebug()) работают с const char* и QString, использование string_view потребовало бы постоянных конвертаций
Да, асинхронный лог действительно имеет небольшую задержку, но это не влияет на точность информации об ошибках. Когда происходит вызов qDebug() или qWarning(), все метаданные фиксируются синхронно в момент вызова. Асинхронность влияет только на момент записи в файл/консоль, но не на содержимое сообщения. Это стандартный подход во всех серьёзных логгерах.
Когда это может быть проблемой:
При краше приложения последние сообщения могут не успеть записаться (для этого есть flush())
При отладке в реальном времени вывод может отставать от действий, но это какие-то доли секунды не заметные человеческому глазу.
Самое главное последовательность сообщений в логе сохраняется в любом случае.
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
import uno
from os.path import abspath, isfile, splitext
PORT = 8100
if len(sys.argv) < 4:
print 'Usage: oreplace SEARCH REPLACE PATH'
sys.exit(0)
inputFile = sys.argv[3]
searchString = sys.argv[1]
replaceString = sys.argv[2]
localCtx = uno.getComponentContext()
localSmgr = localCtx.ServiceManager
uresolver = localSmgr.createInstanceWithContext(
"com.sun.star.bridge.UnoUrlResolver", localCtx)
ctx = uresolver.resolve( \
"uno:socket,host=localhost,port=%d;urp;StarOffice.ComponentContext" % PORT)
smgr = ctx.ServiceManager
desktop = smgr.createInstanceWithContext(
"com.sun.star.frame.Desktop", ctx)
document = desktop.loadComponentFromURL( \
uno.systemPathToFileUrl(abspath(inputFile)), "_blank", 0, tuple([]))
doc = document
if hasattr(document, 'getSheets'):
sheets = document.getSheets()
doc = sheets.getCellRangesByName(u'A1:AMJ1048576')[0]
if not hasattr(doc, 'createReplaceDescriptor'):
print 'Unknown document type'
sys.exit(1)
try:
replaceDesc = doc.createReplaceDescriptor()
replaceDesc.SearchString = searchString
replaceDesc.ReplaceString = replaceString
found = doc.replaceAll(replaceDesc)
document.store()
finally:
document.close(True)
(И не только в нем)
В конце должен остать только один…