Pleased to meet you.
The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides client accuracies typically within a millisecond on LANs and up to a few tens of milliseconds on WANs relative to a primary server synchronized to Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths, in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks.
Background information on computer network time synchronization can be found on the Executive Summary - Computer Network Time Synchronization page. Discussion on protocol conformance issues and interoperability with previous NTP versions can be found in the Protocol Conformance Statement page. Discussion on year-2000 issues can be found in the Year 2000 Conformance Statement page. Background information, bibliography and briefing slides suitable for presentations can be found in the Network Time Synchronization Project page.
Bringing up a NTP primary server requires a radio or satellite receiver or modem. The distribution includes hardware drivers for over two dozen radio clocks and modem services. A list of the particular receivers and modem drivers supported in the distribution is given in the Reference Clock Drivers page. For most popular workstations marketed by Digital, Sun and Hewlett Packard, as well as widely available Unix clones such as FreeBSD and Linux, the automatic build procedures select all drivers that run on the target machine. While this increases the size of the executable binary somewhat, individual drivers can be included or excluded using the configure utility documented in the Configuration Options page.
NTP is by its very nature a complex distributed network application and can be configured and used for a great many widely divergent timekeeping scenarios. The documentation presented on these pages attempts to cover the entire suite of configuration, operation and maintenance facilities which this distribution supports. However, most applications will need only a few of these facilities. If this is the case, the Quick Start page may be useful to get a simple workstation on the air with an existing server.
However, in order to participate in the existing NTP synchronization subnet and obtain accurate, reliable time, it is usually necessary to construct an appropriate configuration file, commonly called ntp.conf, which establishes the servers and/or external receivers or modems to be used by this particular machine. Directions for constructing this file are in the Notes on Configuring NTP and Setting up a NTP Subnet page. However, in many common cases involving simple network topologies and workstations, the file data can be specified entirely on the command line.
The most important factor in providing accurate, reliable time is the selection of modes and servers to be used in the configuration file. NTP support for one or more computers is normally engineered as part of the existing NTP synchronization subnet. The existing NTP subnet consists of a multiply redundant hierarchy of servers and clients, with each level in the hierarchy identified by stratum number. Primary servers operate at stratum one and provide synchronization to secondary servers operating at stratum two and so on to higher strata. In this hierarchy, clients are simply servers that have no dependents.
The NTP subnet in early 1998 includes 70 public primary (stratum 1) servers synchronized directly to UTC by radio, satellite or modem and located in every continent of the globe, except Antarctica (soon). Normally, client workstations and servers with a relatively small number of clients do not synchronize to primary servers. There are 106 public secondary (stratum 2) servers synchronized to the primary servers and providing synchronization to a total in excess of 100,000 clients and servers in the Internet. The current lists are maintained in the Information on Time and Frequency Services page, which is updated frequently. There are numerous private primary and secondary servers not normally available to the public as well. You are strongly discouraged from using these servers, since they sometimes hide in little ghettos behind dinky links to the outside world and your traffic can bring up expensive ISDN lines, causing much grief and frustration.
Users are requested to report bugs, offer suggestions and contribute additions to this distribution. The Patching Procedures page suggests procedures which greatly simplify distribution updates, while the Porting Hints page suggest ways to make porting this code to new hardware and operating systems easier. Additional information on reference clock driver construction and debugging can be found in the Reference Clock Drivers page. Further information on NTP in the Internet can be found in the NTP web page.


| Top |
Message Output and Debugging FunctionsMessage Output and Debugging Functions — functions to output messages and help debug applications |
| void | (*GLogFunc) () |
| void | g_log () |
| void | g_logv () |
| #define | g_message() |
| #define | g_warning() |
| #define | g_critical() |
| #define | g_error() |
| #define | g_info() |
| #define | g_debug() |
| guint | g_log_set_handler () |
| guint | g_log_set_handler_full () |
| void | g_log_remove_handler () |
| GLogLevelFlags | g_log_set_always_fatal () |
| GLogLevelFlags | g_log_set_fatal_mask () |
| void | g_log_default_handler () |
| GLogFunc | g_log_set_default_handler () |
| void | g_log_structured () |
| void | g_log_variant () |
| void | g_log_structured_array () |
| #define | G_DEBUG_HERE |
| GLogWriterOutput | (*GLogWriterFunc) () |
| void | g_log_set_writer_func () |
| gboolean | g_log_writer_supports_color () |
| gboolean | g_log_writer_is_journald () |
| gchar * | g_log_writer_format_fields () |
| GLogWriterOutput | g_log_writer_journald () |
| GLogWriterOutput | g_log_writer_standard_streams () |
| GLogWriterOutput | g_log_writer_default () |
| #define | G_LOG_DOMAIN |
| #define | G_LOG_FATAL_MASK |
| #define | G_LOG_LEVEL_USER_SHIFT |
| enum | GLogLevelFlags |
| struct | GLogField |
| enum | GLogWriterOutput |
These functions provide support for outputting messages.
The g_return family of macros (g_return_if_fail()
,
g_return_val_if_fail()
, g_return_if_reached()
,
g_return_val_if_reached()
) should only be used for programming
errors, a typical use case is checking for invalid parameters at
the beginning of a public function. They should not be used if
you just mean "if (error) return", they should only be used if
you mean "if (bug in program) return". The program behavior is
generally considered undefined after one of these checks fails.
They are not intended for normal control flow, only to give a
perhaps-helpful warning before giving up.
Structured logging output is supported using g_log_structured()
. This differs
from the traditional g_log()
API in that log messages are handled as a
collection of key–value pairs representing individual pieces of information,
rather than as a single string containing all the information in an arbitrary
format.
The convenience macros g_info()
, g_message()
, g_debug()
, g_warning()
and g_error()
will use the traditional g_log()
API unless you define the symbol
G_LOG_USE_STRUCTURED
before including glib.h
. But note that even messages
logged through the traditional g_log()
API are ultimatively passed to
g_log_structured()
, so that all log messages end up in same destination.
If G_LOG_USE_STRUCTURED
is defined, g_test_expect_message()
will become
ineffective for the wrapper macros g_warning()
and friends (see
Testing for Messages).
The support for structured logging was motivated by the following needs (some of which were supported previously; others weren’t):
Support for multiple logging levels.
Structured log support with the ability to add MESSAGE_ID
s (see
g_log_structured()
).
Moving the responsibility for filtering log messages from the program to
the log viewer — instead of libraries and programs installing log handlers
(with g_log_set_handler()
) which filter messages before output, all log
messages are outputted, and the log viewer program (such as journalctl
)
must filter them. This is based on the idea that bugs are sometimes hard
to reproduce, so it is better to log everything possible and then use
tools to analyse the logs than it is to not be able to reproduce a bug to
get additional log data. Code which uses logging in performance-critical
sections should compile out the g_log_structured()
calls in
release builds, and compile them in in debugging builds.
A single writer function which handles all log messages in a process, from all libraries and program code; rather than multiple log handlers with poorly defined interactions between them. This allows a program to easily change its logging policy by changing the writer function, for example to log to an additional location or to change what logging output fallbacks are used. The log writer functions provided by GLib are exposed publicly so they can be used from programs’ log writers. This allows log writer policy and implementation to be kept separate.
If a library wants to add standard information to all of its log messages
(such as library state) or to redact private data (such as passwords or
network credentials), it should use a wrapper function around its
g_log_structured()
calls or implement that in the single log writer
function.
If a program wants to pass context data from a g_log_structured()
call to
its log writer function so that, for example, it can use the correct
server connection to submit logs to, that user data can be passed as a
zero-length GLogField to g_log_structured_array()
.
Color output needed to be supported on the terminal, to make reading through logs easier.
To use structured logging (rather than the old-style logging), either use
the g_log_structured()
and g_log_structured_array()
functions; or define
G_LOG_USE_STRUCTURED
before including any GLib header, and use the
g_message()
, g_debug()
, g_error()
(etc.) macros.
You do not need to define G_LOG_USE_STRUCTURED
to use g_log_structured()
,
but it is a good idea to avoid confusion.
Log domains may be used to broadly split up the origins of log messages.
Typically, there are one or a few log domains per application or library.
G_LOG_DOMAIN
should be used to define the default log domain for the current
compilation unit — it is typically defined at the top of a source file, or in
the preprocessor flags for a group of source files.
Log domains must be unique, and it is recommended that they are the
application or library name, optionally followed by a hyphen and a sub-domain
name. For example, bloatpad
or bloatpad-io
.
The default log functions (g_log_default_handler()
for the old-style API and
g_log_writer_default()
for the structured API) both drop debug and
informational messages by default, unless the log domains of those messages
are listed in the G_MESSAGES_DEBUG
environment variable (or it is set to
all
).
It is recommended that custom log writer functions re-use the
G_MESSAGES_DEBUG
environment variable, rather than inventing a custom one,
so that developers can re-use the same debugging techniques and tools across
projects.
With the old g_log()
API, g_test_expect_message()
and
g_test_assert_expected_messages()
could be used in simple cases to check
whether some code under test had emitted a given log message. These
functions have been deprecated with the structured logging API, for several
reasons:
They relied on an internal queue which was too inflexible for many use cases, where messages might be emitted in several orders, some messages might not be emitted deterministically, or messages might be emitted by unrelated log domains.
They do not support structured log fields.
Examining the log output of code is a bad approach to testing it, and
while it might be necessary for legacy code which uses g_log()
, it should
be avoided for new code using g_log_structured()
.
They will continue to work as before if g_log()
is in use (and
G_LOG_USE_STRUCTURED
is not defined). They will do nothing if used with the
structured logging API.
Examining the log output of code is discouraged: libraries should not emit to
stderr
during defined behaviour, and hence this should not be tested. If
the log emissions of a library during undefined behaviour need to be tested,
they should be limited to asserting that the library aborts and prints a
suitable error message before aborting. This should be done with
g_test_trap_assert_stderr()
.
If it is really necessary to test the structured log messages emitted by a
particular piece of code – and the code cannot be restructured to be more
suitable to more conventional unit testing – you should write a custom log
writer function (see g_log_set_writer_func()
) which appends all log messages
to a queue. When you want to check the log messages, examine and clear the
queue, ignoring irrelevant log messages (for example, from log domains other
than the one under test).
void (*GLogFunc) (const gchar *log_domain
,GLogLevelFlags log_level
,const gchar *message
,gpointer user_data
);
Specifies the prototype of log handler functions.
The default log handler, g_log_default_handler()
, automatically appends a
new-line character to message
when printing it. It is advised that any
custom log handler functions behave similarly, so that logging calls in user
code do not need modifying to add a new-line character to the message if the
log handler is changed.
This is not used if structured logging is enabled; see Using Structured Logging.
log_domain |
the log domain of the message |
|
log_level |
the log level of the message (including the fatal and recursion flags) |
|
message |
the message to process |
|
user_data |
user data, set in |
void g_log (const gchar *log_domain
,GLogLevelFlags log_level
,const gchar *format
,...
);
Logs an error or debugging message.
If the log level has been set as fatal, the abort()
function is called to terminate the program.
If g_log_default_handler()
is used as the log handler function, a new-line
character will automatically be appended to @..., and need not be entered
manually.
If structured logging is enabled this will
output via the structured log writer function (see g_log_set_writer_func()
).
log_domain |
the log domain, usually G_LOG_DOMAIN, or |
[nullable] |
log_level |
the log level, either from GLogLevelFlags or a user-defined level |
|
format |
the message format. See the |
|
... |
the parameters to insert into the format string |
void g_logv (const gchar *log_domain
,GLogLevelFlags log_level
,const gchar *format
,va_list args
);
Logs an error or debugging message.
If the log level has been set as fatal, the abort()
function is called to terminate the program.
If g_log_default_handler()
is used as the log handler function, a new-line
character will automatically be appended to @..., and need not be entered
manually.
If structured logging is enabled this will
output via the structured log writer function (see g_log_set_writer_func()
).
log_domain |
the log domain, or |
[nullable] |
log_level |
the log level |
|
format |
the message format. See the |
|
args |
the parameters to insert into the format string |
#define g_message(...)
A convenience function/macro to log a normal message.
If g_log_default_handler()
is used as the log handler function, a new-line
character will automatically be appended to @..., and need not be entered
manually.
If structured logging is enabled, this will use g_log_structured()
;
otherwise it will use g_log()
. See
Using Structured Logging.
#define g_warning(...)
A convenience function/macro to log a warning message.
This is not intended for end user error reporting. Use of GError is preferred for that instead, as it allows calling functions to perform actions conditional on the type of error.
You can make warnings fatal at runtime by setting the G_DEBUG
environment variable (see
Running GLib Applications).
If g_log_default_handler()
is used as the log handler function,
a newline character will automatically be appended to @..., and
need not be entered manually.
If structured logging is enabled, this will use g_log_structured()
;
otherwise it will use g_log()
. See
Using Structured Logging.
#define g_critical(...)
Logs a "critical warning" (G_LOG_LEVEL_CRITICAL).
It's more or less application-defined what constitutes
a critical vs. a regular warning. You could call
g_log_set_always_fatal()
to make critical warnings exit
the program, then use g_critical()
for fatal errors, for
example.
You can also make critical warnings fatal at runtime by
setting the G_DEBUG
environment variable (see
Running GLib Applications).
If g_log_default_handler()
is used as the log handler function, a new-line
character will automatically be appended to @..., and need not be entered
manually.
If structured logging is enabled, this will use g_log_structured()
;
otherwise it will use g_log()
. See
Using Structured Logging.
#define g_error(...)
A convenience function/macro to log an error message.
This is not intended for end user error reporting. Use of GError is preferred for that instead, as it allows calling functions to perform actions conditional on the type of error.
Error messages are always fatal, resulting in a call to
abort()
to terminate the application. This function will
result in a core dump; don't use it for errors you expect.
Using this function indicates a bug in your program, i.e.
an assertion failure.
If g_log_default_handler()
is used as the log handler function, a new-line
character will automatically be appended to @..., and need not be entered
manually.
If structured logging is enabled, this will use g_log_structured()
;
otherwise it will use g_log()
. See
Using Structured Logging.
#define g_info(...)
A convenience function/macro to log an informational message. Seldom used.
If g_log_default_handler()
is used as the log handler function, a new-line
character will automatically be appended to @..., and need not be entered
manually.
Such messages are suppressed by the g_log_default_handler()
and
g_log_writer_default()
unless the G_MESSAGES_DEBUG
environment variable is
set appropriately.
If structured logging is enabled, this will use g_log_structured()
;
otherwise it will use g_log()
. See
Using Structured Logging.
... |
format string, followed by parameters to insert
into the format string (as with |
Since: 2.40
#define g_debug(...)
A convenience function/macro to log a debug message.
If g_log_default_handler()
is used as the log handler function, a new-line
character will automatically be appended to @..., and need not be entered
manually.
Such messages are suppressed by the g_log_default_handler()
and
g_log_writer_default()
unless the G_MESSAGES_DEBUG
environment variable is
set appropriately.
If structured logging is enabled, this will use g_log_structured()
;
otherwise it will use g_log()
. See
Using Structured Logging.
... |
format string, followed by parameters to insert
into the format string (as with |
Since: 2.6
guint g_log_set_handler (const gchar *log_domain
,GLogLevelFlags log_levels
,GLogFunc log_func
,gpointer user_data
);
Sets the log handler for a domain and a set of log levels.
To handle fatal and recursive messages the log_levels
parameter
must be combined with the G_LOG_FLAG_FATAL and G_LOG_FLAG_RECURSION
bit flags.
Note that since the G_LOG_LEVEL_ERROR log level is always fatal, if you want to set a handler for this log level you must combine it with G_LOG_FLAG_FATAL.
This has no effect if structured logging is enabled; see Using Structured Logging.
Here is an example for adding a log handler for all warning messages in the default domain:
1 2 |
g_log_set_handler (NULL, G_LOG_LEVEL_WARNING | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, my_log_handler, NULL); |
This example adds a log handler for all critical messages from GTK+:
1 2 |
g_log_set_handler ("Gtk", G_LOG_LEVEL_CRITICAL | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, my_log_handler, NULL); |
This example adds a log handler for all messages from GLib:
1 2 |
g_log_set_handler ("GLib", G_LOG_LEVEL_MASK | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, my_log_handler, NULL); |
log_domain |
the log domain, or |
[allow-none] |
log_levels |
the log levels to apply the log handler for. To handle fatal and recursive messages as well, combine the log levels with the G_LOG_FLAG_FATAL and G_LOG_FLAG_RECURSION bit flags. |
|
log_func |
the log handler function |
|
user_data |
data passed to the log handler |
guint g_log_set_handler_full (const gchar *log_domain
,GLogLevelFlags log_levels
,GLogFunc log_func
,gpointer user_data
,GDestroyNotify destroy
);
Like g_log_sets_handler()
, but takes a destroy notify for the user_data
.
This has no effect if structured logging is enabled; see Using Structured Logging.
[rename-to g_log_set_handler]
log_domain |
the log domain, or |
[allow-none] |
log_levels |
the log levels to apply the log handler for. To handle fatal and recursive messages as well, combine the log levels with the G_LOG_FLAG_FATAL and G_LOG_FLAG_RECURSION bit flags. |
|
log_func |
the log handler function |
|
user_data |
data passed to the log handler |
|
destroy |
destroy notify for |
Since: 2.46
void g_log_remove_handler (const gchar *log_domain
,guint handler_id
);
Removes the log handler.
This has no effect if structured logging is enabled; see Using Structured Logging.
log_domain |
the log domain |
|
handler_id |
the id of the handler, which was returned
in |
GLogLevelFlags
g_log_set_always_fatal (GLogLevelFlags fatal_mask
);
Sets the message levels which are always fatal, in any log domain.
When a message with any of these levels is logged the program terminates.
You can only set the levels defined by GLib to be fatal.
G_LOG_LEVEL_ERROR
is always fatal.
You can also make some message levels fatal at runtime by setting
the G_DEBUG
environment variable (see
Running GLib Applications).
Libraries should not call this function, as it affects all messages logged by a process, including those from other libraries.
Structured log messages (using g_log_structured()
and
g_log_structured_array()
) are fatal only if the default log writer is used;
otherwise it is up to the writer function to determine which log messages
are fatal. See Using Structured Logging.
GLogLevelFlags g_log_set_fatal_mask (const gchar *log_domain
,GLogLevelFlags fatal_mask
);
Sets the log levels which are fatal in the given domain.
G_LOG_LEVEL_ERROR
is always fatal.
This has no effect on structured log messages (using g_log_structured()
or
g_log_structured_array()
). To change the fatal behaviour for specific log
messages, programs must install a custom log writer function using
g_log_set_writer_func()
. See
Using Structured Logging.
void g_log_default_handler (const gchar *log_domain
,GLogLevelFlags log_level
,const gchar *message
,gpointer unused_data
);
The default log handler set up by GLib; g_log_set_default_handler()
allows to install an alternate default log handler.
This is used if no log handler has been set for the particular log
domain and log level combination. It outputs the message to stderr
or stdout and if the log level is fatal it calls abort()
. It automatically
prints a new-line character after the message, so one does not need to be
manually included in message
.
The behavior of this log handler can be influenced by a number of environment variables:
G_MESSAGES_PREFIXED
: A :-separated list of log levels for which
messages should be prefixed by the program name and PID of the
aplication.
G_MESSAGES_DEBUG
: A space-separated list of log domains for
which debug and informational messages are printed. By default
these messages are not printed.
stderr is used for levels G_LOG_LEVEL_ERROR
, G_LOG_LEVEL_CRITICAL
,
G_LOG_LEVEL_WARNING
and G_LOG_LEVEL_MESSAGE
. stdout is used for
the rest.
This has no effect if structured logging is enabled; see Using Structured Logging.
GLogFunc g_log_set_default_handler (GLogFunc log_func
,gpointer user_data
);
Installs a default log handler which is used if no
log handler has been set for the particular log domain
and log level combination. By default, GLib uses
g_log_default_handler()
as default log handler.
This has no effect if structured logging is enabled; see Using Structured Logging.
Since: 2.6
void g_log_structured (const gchar *log_domain
,GLogLevelFlags log_level
,...
);
Log a message with structured data. The message will be passed through to
the log writer set by the application using g_log_set_writer_func()
. If the
message is fatal (i.e. its log level is G_LOG_LEVEL_ERROR
), the program will
be aborted at the end of this function.
The structured data is provided as key–value pairs, where keys are UTF-8
strings, and values are arbitrary pointers — typically pointing to UTF-8
strings, but that is not a requirement. To pass binary (non-nul-terminated)
structured data, use g_log_structured_array()
. The keys for structured data
should follow the systemd journal
fields
specification. It is suggested that custom keys are namespaced according to
the code which sets them. For example, custom keys from GLib all have a
GLIB_
prefix.
The log_domain
will be converted into a GLIB_DOMAIN
field. log_level
will
be converted into a
PRIORITY
field. The format string will have its placeholders substituted for the provided
values and be converted into a
MESSAGE
field.
Other fields you may commonly want to pass into this function:
Note that CODE_FILE
, CODE_LINE
and CODE_FUNC
are automatically set by
the logging macros, G_DEBUG_HERE()
, g_message()
, g_warning()
, g_critical()
,
g_error()
, etc, if the symbols G_LOG_USE_STRUCTURED
is defined before including
glib.h.
For example:
1 2 3 4 5 |
g_log_structured (G_LOG_DOMAIN, G_LOG_LEVEL_DEBUG, "MESSAGE_ID", "06d4df59e6c24647bfe69d2c27ef0b4e", "MY_APPLICATION_CUSTOM_FIELD", "some debug string", "MESSAGE", "This is a debug message about pointer %p and integer %u.", some_pointer, some_integer); |
Note that each MESSAGE_ID
must be uniquely and randomly
generated.
If adding a MESSAGE_ID
, consider shipping a message
catalog with
your software.
To pass a user data pointer to the log writer function which is specific to
this logging call, you must use g_log_structured_array()
and pass the pointer
as a field with GLogField.length set to zero, otherwise it will be
interpreted as a string.
For example:
1 2 3 4 5 6 7 |
const GLogField fields[] = { { "MESSAGE", "This is a debug message.", -1 }, { "MESSAGE_ID", "fcfb2e1e65c3494386b74878f1abf893", -1 }, { "MY_APPLICATION_CUSTOM_FIELD", "some debug string", -1 }, { "MY_APPLICATION_STATE", state_object, 0 }, }; g_log_structured_array (G_LOG_LEVEL_DEBUG, fields, G_N_ELEMENTS (fields)); |
Note also that, even if no other structured fields are specified, there
must always be a "MESSAGE" key before the format string. The "MESSAGE"-format
pair has to be the last of the key-value pairs, and "MESSAGE" is the only
field for which printf()
-style formatting is supported.
The default writer function for stdout
and stderr
will automatically
append a new-line character after the message, so you should not add one
manually to the format string.
log_domain |
log domain, usually |
|
log_level |
log level, either from GLogLevelFlags, or a user-defined level |
|
... |
key-value pairs of structured data to add to the log entry, followed
by the key "MESSAGE", followed by a |
Since: 2.50
void g_log_variant (const gchar *log_domain
,GLogLevelFlags log_level
,GVariant *fields
);
Log a message with structured data, accepting the data within a GVariant. This version is especially useful for use in other languages, via introspection.
The only mandatory item in the fields
dictionary is the "MESSAGE" which must
contain the text shown to the user.
The values in the fields
dictionary are likely to be of type String
(G_VARIANT_TYPE_STRING). Array of bytes (G_VARIANT_TYPE_BYTESTRING) is also
supported. In this case the message is handled as binary and will be forwarded
to the log writer as such. The size of the array should not be higher than
G_MAXSSIZE
. Otherwise it will be truncated to this size. For other types
g_variant_print()
will be used to convert the value into a string.
For more details on its usage and about the parameters, see g_log_structured()
.
log_domain |
log domain, usually |
[allow-none] |
log_level |
log level, either from GLogLevelFlags, or a user-defined level |
|
fields |
a dictionary (GVariant of the type |
Since: 2.50
void g_log_structured_array (GLogLevelFlags log_level
,const GLogField *fields
,gsize n_fields
);
Log a message with structured data. The message will be passed through to the
log writer set by the application using g_log_set_writer_func()
. If the
message is fatal (i.e. its log level is G_LOG_LEVEL_ERROR
), the program will
be aborted at the end of this function.
See g_log_structured()
for more documentation.
This assumes that log_level
is already present in fields
(typically as the
PRIORITY
field).
log_level |
log level, either from GLogLevelFlags, or a user-defined level |
|
fields |
key–value pairs of structured data to add to the log message. |
[array length=n_fields] |
n_fields |
number of elements in the |
Since: 2.50
#define G_DEBUG_HERE()
A convenience form of g_log_structured()
, recommended to be added to
functions when debugging. It prints the current monotonic time and the code
location using G_STRLOC
.
Since: 2.50
GLogWriterOutput (*GLogWriterFunc) (GLogLevelFlags log_level
,const GLogField *fields
,gsize n_fields
,gpointer user_data
);
Writer function for log entries. A log entry is a collection of one or more
GLogFields, using the standard field names from journal
specification.
See g_log_structured()
for more information.
Writer functions must ignore fields which they do not recognise, unless they can write arbitrary binary output, as field values may be arbitrary binary.
log_level
is guaranteed to be included in fields
as the PRIORITY
field,
but is provided separately for convenience of deciding whether or where to
output the log entry.
log_level |
log level of the message |
|
fields |
fields forming the message. |
[array length=n_fields] |
n_fields |
number of |
|
user_data |
user data passed to |
G_LOG_WRITER_HANDLED
if the log entry was handled successfully;
G_LOG_WRITER_UNHANDLED
otherwise
Since: 2.50
void g_log_set_writer_func (GLogWriterFunc func
,gpointer user_data
,GDestroyNotify user_data_free
);
Set a writer function which will be called to format and write out each log
message. Each program should set a writer function, or the default writer
(g_log_writer_default()
) will be used.
Libraries **must not** call this function — only programs are allowed to install a writer function, as there must be a single, central point where log messages are formatted and outputted.
There can only be one writer function. It is an error to set more than one.
Since: 2.50
gboolean
g_log_writer_supports_color (gint output_fd
);
Check whether the given output_fd
file descriptor supports ANSI color
escape sequences. If so, they can safely be used when formatting log
messages.
Since: 2.50
gboolean
g_log_writer_is_journald (gint output_fd
);
Check whether the given output_fd
file descriptor is a connection to the
systemd journal, or something else (like a log file or stdout
or
stderr
).
Since: 2.50
gchar * g_log_writer_format_fields (GLogLevelFlags log_level
,const GLogField *fields
,gsize n_fields
,gboolean use_color
);
Format a structured log message as a string suitable for outputting to the
terminal (or elsewhere). This will include the values of all fields it knows
how to interpret, which includes MESSAGE
and GLIB_DOMAIN
(see the
documentation for g_log_structured()
). It does not include values from
unknown fields.
The returned string does **not** have a trailing new-line character. It is encoded in the character set of the current locale, which is not necessarily UTF-8.
log_level |
log level, either from GLogLevelFlags, or a user-defined level |
|
fields |
key–value pairs of structured data forming the log message. |
[array length=n_fields] |
n_fields |
number of elements in the |
|
use_color |
|
string containing the formatted log message, in the character set of the current locale.
[transfer full]
Since: 2.50
GLogWriterOutput g_log_writer_journald (GLogLevelFlags log_level
,const GLogField *fields
,gsize n_fields
,gpointer user_data
);
Format a structured log message and send it to the systemd journal as a set of key–value pairs. All fields are sent to the journal, but if a field has length zero (indicating program-specific data) then only its key will be sent.
This is suitable for use as a GLogWriterFunc.
If GLib has been compiled without systemd support, this function is still
defined, but will always return G_LOG_WRITER_UNHANDLED
.
log_level |
log level, either from GLogLevelFlags, or a user-defined level |
|
fields |
key–value pairs of structured data forming the log message. |
[array length=n_fields] |
n_fields |
number of elements in the |
|
user_data |
user data passed to |
Since: 2.50
GLogWriterOutput g_log_writer_standard_streams (GLogLevelFlags log_level
,const GLogField *fields
,gsize n_fields
,gpointer user_data
);
Format a structured log message and print it to either stdout
or stderr
,
depending on its log level. G_LOG_LEVEL_INFO
and G_LOG_LEVEL_DEBUG
messages
are sent to stdout
; all other log levels are sent to stderr
. Only fields
which are understood by this function are included in the formatted string
which is printed.
If the output stream supports ANSI color escape sequences, they will be used in the output.
A trailing new-line character is added to the log message when it is printed.
This is suitable for use as a GLogWriterFunc.
log_level |
log level, either from GLogLevelFlags, or a user-defined level |
|
fields |
key–value pairs of structured data forming the log message. |
[array length=n_fields] |
n_fields |
number of elements in the |
|
user_data |
user data passed to |
Since: 2.50
GLogWriterOutput g_log_writer_default (GLogLevelFlags log_level
,const GLogField *fields
,gsize n_fields
,gpointer user_data
);
Format a structured log message and output it to the default log destination
for the platform. On Linux, this is typically the systemd journal, falling
back to stdout
or stderr
if running from the terminal or if output is
being redirected to a file.
Support for other platform-specific logging mechanisms may be added in future. Distributors of GLib may modify this function to impose their own (documented) platform-specific log writing policies.
This is suitable for use as a GLogWriterFunc, and is the default writer used
if no other is set using g_log_set_writer_func()
.
As with g_log_default_handler()
, this function drops debug and informational
messages unless their log domain (or all
) is listed in the space-separated
G_MESSAGES_DEBUG
environment variable.
log_level |
log level, either from GLogLevelFlags, or a user-defined level |
|
fields |
key–value pairs of structured data forming the log message. |
[array length=n_fields] |
n_fields |
number of elements in the |
|
user_data |
user data passed to |
Since: 2.50
#define G_LOG_DOMAIN ((gchar*) 0)
Defines the log domain.
For applications, this is typically left as the default NULL
(or "") domain. Libraries should define this so that any messages
which they log can be differentiated from messages from other
libraries and application code. But be careful not to define
it in any public header files.
For example, GTK+ uses this in its Makefile.am:
1 |
AM_CPPFLAGS = -DG_LOG_DOMAIN=\"Gtk\" |
#define G_LOG_FATAL_MASK (G_LOG_FLAG_RECURSION | G_LOG_LEVEL_ERROR)
GLib log levels that are considered fatal by default.
This is not used if structured logging is enabled; see Using Structured Logging.
#define G_LOG_LEVEL_USER_SHIFT (8)
Log levels below 1<<G_LOG_LEVEL_USER_SHIFT are used by GLib. Higher bits can be used for user-defined log levels.
Flags specifying the level of log messages.
It is possible to change how GLib treats messages of the various
levels using g_log_set_handler()
and g_log_set_fatal_mask()
.
|
internal flag |
||
|
internal flag |
||
|
log level for errors, see |
||
|
log level for critical warning messages, see
|
||
|
log level for warnings, see |
||
|
log level for messages, see |
||
|
log level for informational messages, see |
||
|
log level for debug messages, see |
||
|
a mask including all log levels |
struct GLogField { const gchar *key; gconstpointer value; gssize length; };
Structure representing a single field in a structured log entry. See
g_log_structured()
for details.
Log fields may contain arbitrary values, including binary with embedded nul
bytes. If the field contains a string, the string must be UTF-8 encoded and
have a trailing nul byte. Otherwise, length
must be set to a non-negative
value.
const gchar * |
field name (UTF-8 string) |
|
gconstpointer |
field value (arbitrary bytes) |
|
gssize |
length of |
Since: 2.50
Return values from GLogWriterFuncs to indicate whether the given log entry was successfully handled by the writer, or whether there was an error in handling it (and hence a fallback writer should be used).
If a GLogWriterFunc ignores a log entry, it should return
G_LOG_WRITER_HANDLED
.
Since: 2.50


Embed your GitHub contributions calendar anywhere.
 So, why not making the GitHub contributions calendar available for being embeded in your web pages? Now you can. :tada:
Check out the dist
directory to download the needed files and include them on your page.
If you’re using this module in a CommonJS environment, you can install it using npm
or yarn
and require
it:
<!-- Include the library. -->
<script
<EMAIL_ADDRESS></script>
<!-- Optionally, include the theme (if you don't want to struggle to write the CSS) -->
<link
rel="stylesheet"
<EMAIL_ADDRESS>/>
<!-- Prepare a container for your calendar. -->
<div class="calendar">
<!-- Loading stuff -->
Loading the data just for you.
</div>
<script>
GitHubCalendar(".calendar", "your-username");
// or enable responsive functionality:
GitHubCalendar(".calendar", "your-username", { responsive: true });
// Use a proxy
GitHubCalendar(".calendar", "your-username", {
proxy (username) {
return fetch(`https://your-proxy.com/github?user=${username}`)
}
}).then(r => r.text())
</script>
Here you can see this example in action.
There are few ways to get help:
GitHubCalendar(container, username, options)
Brings the contributions calendar from GitHub (provided username) into your page.
container
: The calendar container (query selector or the element itself).username
: The GitHub username.options
: An object containing the following fields:
summary_text
(String): The text that appears under the calendar (defaults to: "Summary of pull requests, issues opened, and commits made by <username>"
).proxy
(Function): A function that receives as argument the username (string) and should return a promise resolving the HTML content of the contributions page. The default is using @Bloggify’s APIs.global_stats
(Boolean): If false
, the global stats (total, longest and current streaks) will not be calculated and displayed. By default this is enabled.responsive
(Boolean): If true
, the graph is changed to scale with the container. Custom CSS should be applied to the element to scale it appropriately. By default this is disabled.tooltips
(Boolean): If true
, tooltips will be shown when hovered over calendar days. By default this is disabled.cache
(Number) The cache time in seconds.fetch()
call.Have an idea? Found a bug? See how to contribute.
If you are using this library in one of your projects, add it in this list. :sparkles:
@pengliheng/github-report
@axetroy/react-github-calendar
github-alike-calendar
@philipwhiuk/react-github-calendar


--- layout: main --- {% capture readme %}{% include_relative README.md %}{% endcapture %} {{ readme | markdownify }} {% raw %}


/apple-touch-icon.png">
Check out what you can do with R'mate!
Get directions from anywhere right to your classroom door! No more getting lost getting around UCR!
Keep track of your classes all in one easy to access place! Once your classes schedule is in the app, it makes navigating to them easier!
Quickly find any UCR Point-of-Interest at your convience like Scotty's Market, Libraries, Food Courts, Coffee Shops, Bike Racks, and more!
Never miss another school event with up to date info on Student Development Workshops, ASUCR Events/Concerts, and Undergraduate Reasearch Opportunites!
Software Engineer/Design Director
Lead Software Engineer/Developer
Software Engineer/Database Director
Product Manager


A channel to discuss trading. For useful links and more info click the pinned messages to the right.
100 messages
Before 05-Dec-19 12:00 AM
KomodoWorld14-Mar-19 08:38 PM
will nodl.it sell it ? Or from another vendor? Very interesting
FishyGuts14-Mar-19 10:33 PM
Nodl it sells it direct www.nodl.it - I haven't talked to them about marketing it on their site as a KMD ready product, but I am going to.
Ketominer is a very responsive person.
Crabby Paddy14-Mar-19 11:46 PM
Rest In Peace you will be missed green and yellow :’(
Blockfolio has been updated. 15.3.19 you have done us well
A moment of silence for the original logo
FishyGuts14-Mar-19 11:52 PM
wait wut?

Draeth15-Mar-19 01:21 AM
@74D30 negative. Also, after you send payment and click place order, if you get an error, do not redo everything. It works fine but for some reason the payment gateway is spitting out an error. I'm working on it atm
74D3015-Mar-19 01:22 AM
I will patiently wait
Who is minting them?
Draeth15-Mar-19 01:23 AM
one of my business partners
Funkyball15-Mar-19 03:13 AM
How much qould silver coin cost?
Alright15-Mar-19 03:54 AM
@Draeth limited runs means the difference between a trinket and a "collectible"
Draeth15-Mar-19 03:56 AM
yeah
TS15-Mar-19 08:07 AM
silver coin, count me in!
CryptoNinjaa15-Mar-19 09:19 AM
Looks like we maybe moving up
101k whale bro spotted in the wild(edited)
Keppie15-Mar-19 09:25 AM
idd, macd flip aswell on the daily
CryptoNinjaa15-Mar-19 09:27 AM
Set some small sells between here and 30k lets see
Alecandro15-Mar-19 09:27 AM
Oh damn things are getting interesting here
CryptoNinjaa15-Mar-19 09:28 AM
Nice friday Komodo parabolic move cmon lol
Keppie15-Mar-19 09:30 AM
Wish i was ballsy enough to sell hehe
I always keep the eth bullrun in mind and how i sold way to early there
CryptoNinjaa15-Mar-19 09:31 AM
Jus small amounts dude.


SMART Google Forms
A Smarter of Google Forms with Autograder
Welcome to the World of Smart Forms!
We at MLXTREME plan for a better Education by enhancing
Processing Time and Improving Forms Usability.
- Automated Processing
- Saves Time by removing Manualization
- Lightning Fast Scores in Browser
Username:
Password:


| Number of Classes | Line Coverage | Mutation Coverage | Mutation Score |
|---|---|---|---|
| 6 | 89% | 62% | 78%
Killed: 31
Uncertain: 2
|
| Name | Line Coverage | Mutation Coverage | Mutation Score |
|---|---|---|---|
| AbstractSpecializedSender.java | 100% |
80% |
100%
Killed: 1
Uncertain: 0
|
| AutoRetrySender.java | 78% |
45% |
57%
Killed: 4
Uncertain: 0
|
| ContentTranslatorSender.java | 96% |
53% |
71%
Killed: 5
Uncertain: 1
|
| FallbackSender.java | 90% |
50% |
100%
Killed: 1
Uncertain: 0
|
| FillerSender.java | 94% |
55% |
71%
Killed: 5
Uncertain: 1
|
| MultiImplementationSender.java | 88% |
72% |
88%
Killed: 15
Uncertain: 0
|


Welcome to the OrientDB Studio application. If this is your first time play with the 'demo' database provided in bundle with the
official OrientDB distribution.
To Login use "reader/reader" to read records from the database, and "writer/writer" to read, create, update and delete records. To
access Server information log into a database and then click on the "Server" tab (top right). To access it you have to click on the "Refresh"
button (not your browser's refresh) under the OrientDB logo above. When prompted, provide the OrientDB Server's credentials: "root" as user
and the automatic generated password created under the OrientDB installation directory, in the file "config/orient-server-config.xml". |


Thank you for choosing to participate in our user research study on public transportation economics! We here at BusMall Inc strive to serve our passengers with the most unique shopping experience possible. As you will see, our products reflect this philosophy. Please click on the picture of the item you would be most likely interested in purchasing.


|
|||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
| Interface Summary | |
|---|---|
| AsyncOperationsObserver | |
| DiskDatabaseHelper.DiskDatabaseHelperObserver | |
| ImageDiskObserver | |
| ImageLoaderListener | |
| ImageMemoryCacherInterface | |
| ImagePrecacheAssistant.PrecacheInformationProvider | This interface must be implemented in order for the ImagePrecacheAssistant to function. |
| NetworkRequestCreator | |
| NetworkRequestCreator.InputStreamListener |
| Class Summary | |
|---|---|
| AbstractImageLoader | |
| AbstractImageLoader.Options | This class provides all the options that can be set when making loadImage calls. |
| AdvancedMemoryLRUCacher | |
| AsyncOperationsMaps | |
| BuildConfig | |
| DecodeSignature | |
| Dimensions | |
| DiskDatabaseHelper | |
| DiskLRUCacher | |
| DiskManager | Provides access to basic disk operations. |
| DisplayUtility | |
| FileEntry | |
| HashedQueue<T> | |
| ImageCacher | This class defensively handles requests from four locations: LifecycleReferenceManager, ImageMemoryCacherInterface, ImageDiskCacherInterface, ImageNetworkInterface and the AsyncOperationsMaps. |
| ImageCacher.ImageCacherListener | |
| ImageLoader | This class simplifies the task of loading images from a URL into an ImageView on Android. |
| ImageLoaderSupport | This class simplifies the task of loading images from a URL into an
ImageView on Android. |
| ImagePrecacheAssistant | This utility simplifies the process of implementing precaching in adapters for use in widgets such as ListViews and ViewPagers. Instructions: Create a new instance of this class from within adapter. Implement the methods PrecacheInformationProvider#onRowPrecacheRequestsRequired(int) and ImagePrecacheAssistant.PrecacheInformationProvider.getCount() .In the "getView" method of the adapter, call ImagePrecacheAssistant.onPositionVisited(int) , and pass in the current position. |
| ImagePrecacheAssistant.PrecacheRequest | |
| R | |
| R.attr | |
| R.drawable | |
| R.string | |
| ScalingInfo |
| Enum Summary | |
|---|---|
| AbstractImageLoader.Options.ScalingPreference | AbstractImageLoader.Options.ScalingPreference.LARGER_THAN_VIEW_OR_FULL_SIZE This option guarantees that the image being returned will be larger than the view's bounds, or it's maximum size. |
| AsyncOperationsMaps.AsyncOperationState | |
| ImagePrecacheAssistant.PrecacheRequest.UnitType | |
| ImageReturnedFrom |
| Exception Summary | |
|---|---|
| DiskLRUCacher.FileFormatException |
|
|||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |


Broadcast messages are displayed for every user and can be used to notify users about scheduled maintenance, recent upgrades and more.
곧 점검에 들어가오니 준비들 하세요.