public class Logger extends Object
Logger objects may be obtained by calls on one of the getLogger
factory methods. These will either create a new Logger or
return a suitable existing Logger. It is important to note that
the Logger returned by one of the getLogger
factory methods
may be garbage collected at any time if a strong reference to the
Logger is not kept.
Logging messages will be forwarded to registered Handler objects, which can forward the messages to a variety of destinations, including consoles, files, OS logs, etc.
Each Logger keeps track of a "parent" Logger, which is its nearest existing ancestor in the Logger namespace.
Each Logger has a "Level" associated with it. This reflects a minimum Level that this logger cares about. If a Logger's level is set to null, then its effective level is inherited from its parent, which may in turn obtain it recursively from its parent, and so on up the tree.
The log level can be configured based on the properties from the logging configuration file, as described in the description of the LogManager class. However it may also be dynamically changed by calls on the Logger.setLevel method. If a logger's level is changed the change may also affect child loggers, since any child logger that has null as its level will inherit its effective level from its parent.
On each logging call the Logger initially performs a cheap check of the request level (e.g., SEVERE or FINE) against the effective log level of the logger. If the request level is lower than the log level, the logging call returns immediately.
After passing this initial (cheap) test, the Logger will allocate a LogRecord to describe the logging message. It will then call a Filter (if present) to do a more detailed check on whether the record should be published. If that passes it will then publish the LogRecord to its output Handlers. By default, loggers also publish to their parent's Handlers, recursively up the tree.
Each Logger may have a ResourceBundle
associated with it.
The ResourceBundle
may be specified by name, using the
getLogger(java.lang.String, java.lang.String)
factory
method, or by value - using the setResourceBundle
method.
This bundle will be used for localizing logging messages.
If a Logger does not have its own ResourceBundle
or resource bundle
name, then it will inherit the ResourceBundle
or resource bundle name
from its parent, recursively up the tree.
Most of the logger output methods take a "msg" argument. This
msg argument may be either a raw value or a localization key.
During formatting, if the logger has (or inherits) a localization
ResourceBundle
and if the ResourceBundle
has a mapping for
the msg string, then the msg string is replaced by the localized value.
Otherwise the original msg string is used. Typically, formatters use
java.text.MessageFormat style formatting to format parameters, so
for example a format string "{0} {1}" would format two parameters
as strings.
A set of methods alternatively take a "msgSupplier" instead of a "msg"
argument. These methods take a Supplier
<String>
function
which is invoked to construct the desired log message only when the message
actually is to be logged based on the effective log level thus eliminating
unnecessary message construction. For example, if the developer wants to
log system health status for diagnosis, with the String-accepting version,
the code would look like:
class DiagnosisMessages {
static String systemHealthStatus() {
// collect system health information
...
}
}
...
logger.log(Level.FINER, DiagnosisMessages.systemHealthStatus());
With the above code, the health status is collected unnecessarily even when
the log level FINER is disabled. With the Supplier-accepting version as
below, the status will only be collected when the log level FINER is
enabled.
logger.log(Level.FINER, DiagnosisMessages::systemHealthStatus);
When looking for a ResourceBundle
, the logger will first look at
whether a bundle was specified using setResourceBundle
, and then
only whether a resource bundle name was specified through the getLogger
factory method.
If no ResourceBundle
or no resource bundle name is found,
then it will use the nearest ResourceBundle
or resource bundle
name inherited from its parent tree.
When a ResourceBundle
was inherited or specified through the
setResourceBundle
method, then
that ResourceBundle
will be used. Otherwise if the logger only
has or inherited a resource bundle name, then that resource bundle name
will be mapped to a ResourceBundle
object, using the default Locale
at the time of logging.
When mapping resource bundle names to
ResourceBundle
objects, the logger will first try to use the
Thread's context class
loader to map the given resource bundle name to a ResourceBundle
.
If the thread context class loader is null
, it will try the
system class loader
instead. If the ResourceBundle
is still not found, it will use the
class loader of the first caller of the getLogger
factory method.
Formatting (including localization) is the responsibility of the output Handler, which will typically call a Formatter.
Note that formatting need not occur synchronously. It may be delayed until a LogRecord is actually written to an external sink.
The logging methods are grouped in five main categories:
There are a set of "log" methods that take a log level, a message string, and optionally some parameters to the message string.
There are a set of "logp" methods (for "log precise") that are like the "log" methods, but also take an explicit source class name and method name.
There are a set of "logrb" method (for "log with resource bundle") that are like the "logp" method, but also take an explicit resource bundle object for use in localizing the log message.
There are convenience methods for tracing method entries (the "entering" methods), method returns (the "exiting" methods) and throwing exceptions (the "throwing" methods).
Finally, there are a set of convenience methods for use in the very simplest cases, when a developer simply wants to log a simple string at a given log level. These methods are named after the standard Level names ("severe", "warning", "info", etc.) and take a single argument, a message string.
For the methods that do not take an explicit source name and method name, the Logging framework will make a "best effort" to determine which class and method called into the logging method. However, it is important to realize that this automatically inferred information may only be approximate (or may even be quite wrong!). Virtual machines are allowed to do extensive optimizations when JITing and may entirely remove stack frames, making it impossible to reliably locate the calling class and method.
All methods on Logger are multi-thread safe.
Subclassing Information: Note that a LogManager class may provide its own implementation of named Loggers for any point in the namespace. Therefore, any subclasses of Logger (unless they are implemented in conjunction with a new LogManager class) should take care to obtain a Logger instance from the LogManager class and should delegate operations such as "isLoggable" and "log(LogRecord)" to that instance. Note that in order to intercept all logging output, subclasses need only override the log(LogRecord) method. All the other logging methods are implemented as calls on this log(LogRecord) method.
| Modifier and Type | Field and Description |
|---|---|
static Logger |
global
Deprecated.
Initialization of this field is prone to deadlocks.
The field must be initialized by the Logger class initialization
which may cause deadlocks with the LogManager class initialization.
In such cases two class initialization wait for each other to complete.
The preferred way to get the global logger object is via the call
Logger.getGlobal() .
For compatibility with old JDK versions where the
Logger.getGlobal() is not available use the call
Logger.getLogger(Logger.GLOBAL_LOGGER_NAME)
or Logger.getLogger("global") . |
static String |
GLOBAL_LOGGER_NAME
GLOBAL_LOGGER_NAME is a name for the global logger.
|
| Modifier | Constructor and Description |
|---|---|
protected |
Logger(String name,
String resourceBundleName)
Protected method to construct a logger for a named subsystem.
|
| Modifier and Type | Method and Description |
|---|---|
void |
addHandler(Handler handler)
Add a log Handler to receive logging messages.
|
void |
config(String msg)
Log a CONFIG message.
|
void |
config(Supplier<String> msgSupplier)
Log a CONFIG message, which is only to be constructed if the logging
level is such that the message will actually be logged.
|
void |
entering(String sourceClass,
String sourceMethod)
Log a method entry.
|
void |
entering(String sourceClass,
String sourceMethod,
Object param1)
Log a method entry, with one parameter.
|
void |
entering(String sourceClass,
String sourceMethod,
Object[] params)
Log a method entry, with an array of parameters.
|
void |
exiting(String sourceClass,
String sourceMethod)
Log a method return.
|
void |
exiting(String sourceClass,
String sourceMethod,
Object result)
Log a method return, with result object.
|
void |
fine(String msg)
Log a FINE message.
|
void |
fine(Supplier<String> msgSupplier)
Log a FINE message, which is only to be constructed if the logging
level is such that the message will actually be logged.
|
void |
finer(String msg)
Log a FINER message.
|
void |
finer(Supplier<String> msgSupplier)
Log a FINER message, which is only to be constructed if the logging
level is such that the message will actually be logged.
|
void |
finest(String msg)
Log a FINEST message.
|
void |
finest(Supplier<String> msgSupplier)
Log a FINEST message, which is only to be constructed if the logging
level is such that the message will actually be logged.
|
static Logger |
getAnonymousLogger()
Create an anonymous Logger.
|
static Logger |
getAnonymousLogger(String resourceBundleName)
Create an anonymous Logger.
|
Filter |
getFilter()
Get the current filter for this Logger.
|
static Logger |
getGlobal()
Return global logger object with the name Logger.GLOBAL_LOGGER_NAME.
|
Handler[] |
getHandlers()
Get the Handlers associated with this logger.
|
Level |
getLevel()
Get the log Level that has been specified for this Logger.
|
static Logger |
getLogger(String name)
Find or create a logger for a named subsystem.
|
static Logger |
getLogger(String name,
String resourceBundleName)
Find or create a logger for a named subsystem.
|
String |
getName()
Get the name for this logger.
|
Logger |
getParent()
Return the parent for this Logger.
|
ResourceBundle |
getResourceBundle()
Retrieve the localization resource bundle for this
logger.
|
String |
getResourceBundleName()
Retrieve the localization resource bundle name for this
logger.
|
boolean |
getUseParentHandlers()
Discover whether or not this logger is sending its output
to its parent logger.
|
void |
info(String msg)
Log an INFO message.
|
void |
info(Supplier<String> msgSupplier)
Log a INFO message, which is only to be constructed if the logging
level is such that the message will actually be logged.
|
boolean |
isLoggable(Level level)
Check if a message of the given level would actually be logged
by this logger.
|
void |
log(Level level,
String msg)
Log a message, with no arguments.
|
void |
log(Level level,
String msg,
Object param1)
Log a message, with one object parameter.
|
void |
log(Level level,
String msg,
Object[] params)
Log a message, with an array of object arguments.
|
void |
log(Level level,
String msg,
Throwable thrown)
Log a message, with associated Throwable information.
|
void |
log(Level level,
Supplier<String> msgSupplier)
Log a message, which is only to be constructed if the logging level
is such that the message will actually be logged.
|
void |
log(Level level,
Throwable thrown,
Supplier<String> msgSupplier)
Log a lazily constructed message, with associated Throwable information.
|
void |
log(LogRecord record)
Log a LogRecord.
|
void |
logp(Level level,
String sourceClass,
String sourceMethod,
String msg)
Log a message, specifying source class and method,
with no arguments.
|
void |
logp(Level level,
String sourceClass,
String sourceMethod,
String msg,
Object param1)
Log a message, specifying source class and method,
with a single object parameter to the log message.
|
void |
logp(Level level,
String sourceClass,
String sourceMethod,
String msg,
Object[] params)
Log a message, specifying source class and method,
with an array of object arguments.
|
void |
logp(Level level,
String sourceClass,
String sourceMethod,
String msg,
Throwable thrown)
Log a message, specifying source class and method,
with associated Throwable information.
|
void |
logp(Level level,
String sourceClass,
String sourceMethod,
Supplier<String> msgSupplier)
Log a lazily constructed message, specifying source class and method,
with no arguments.
|
void |
logp(Level level,
String sourceClass,
String sourceMethod,
Throwable thrown,
Supplier<String> msgSupplier)
Log a lazily constructed message, specifying source class and method,
with associated Throwable information.
|
void |
logrb(Level level,
String sourceClass,
String sourceMethod,
ResourceBundle bundle,
String msg,
Object... params)
Log a message, specifying source class, method, and resource bundle,
with an optional list of message parameters.
|
void |
logrb(Level level,
String sourceClass,
String sourceMethod,
ResourceBundle bundle,
String msg,
Throwable thrown)
Log a message, specifying source class, method, and resource bundle,
with associated Throwable information.
|
void |
logrb(Level level,
String sourceClass,
String sourceMethod,
String bundleName,
String msg)
|
void |
logrb(Level level,
String sourceClass,
String sourceMethod,
String bundleName,
String msg,
Object param1)
|
void |
logrb(Level level,
String sourceClass,
String sourceMethod,
String bundleName,
String msg,
Object[] params)
|
void |
logrb(Level level,
String sourceClass,
String sourceMethod,
String bundleName,
String msg,
Throwable thrown)
|
void |
removeHandler(Handler handler)
Remove a log Handler.
|
void |
setFilter(Filter newFilter)
Set a filter to control output on this Logger.
|
void |
setLevel(Level newLevel)
Set the log level specifying which message levels will be
logged by this logger.
|
void |
setParent(Logger parent)
Set the parent for this Logger.
|
void |
setResourceBundle(ResourceBundle bundle)
Sets a resource bundle on this logger.
|
void |
setUseParentHandlers(boolean useParentHandlers)
Specify whether or not this logger should send its output
to its parent Logger.
|
void |
severe(String msg)
Log a SEVERE message.
|
void |
severe(Supplier<String> msgSupplier)
Log a SEVERE message, which is only to be constructed if the logging
level is such that the message will actually be logged.
|
void |
throwing(String sourceClass,
String sourceMethod,
Throwable thrown)
Log throwing an exception.
|
void |
warning(String msg)
Log a WARNING message.
|
void |
warning(Supplier<String> msgSupplier)
Log a WARNING message, which is only to be constructed if the logging
level is such that the message will actually be logged.
|
public static final String GLOBAL_LOGGER_NAME
@Deprecated public static final Logger global
Logger.getGlobal()
.
For compatibility with old JDK versions where the
Logger.getGlobal()
is not available use the call
Logger.getLogger(Logger.GLOBAL_LOGGER_NAME)
or Logger.getLogger("global")
.protected Logger(String name, String resourceBundleName)
The logger will be initially configured with a null Level and with useParentHandlers set to true.
name
- A name for the logger. This should
be a dot-separated name and should normally
be based on the package name or class name
of the subsystem, such as java.net
or javax.swing. It may be null for anonymous Loggers.resourceBundleName
- name of ResourceBundle to be used for localizing
messages for this logger. May be null if none
of the messages require localization.MissingResourceException
- if the resourceBundleName is non-null and
no corresponding resource can be found.public static final Logger getGlobal()
public static Logger getLogger(String name)
If a new logger is created its log level will be configured based on the LogManager configuration and it will configured to also send logging output to its parent's Handlers. It will be registered in the LogManager global namespace.
Note: The LogManager may only retain a weak reference to the newly
created Logger. It is important to understand that a previously
created Logger with the given name may be garbage collected at any
time if there is no strong reference to the Logger. In particular,
this means that two back-to-back calls like
getLogger("MyLogger").log(...)
may use different Logger
objects named "MyLogger" if there is no strong reference to the
Logger named "MyLogger" elsewhere in the program.
name
- A name for the logger. This should
be a dot-separated name and should normally
be based on the package name or class name
of the subsystem, such as java.net
or javax.swingNullPointerException
- if the name is null.public static Logger getLogger(String name, String resourceBundleName)
If a new logger is created its log level will be configured based on the LogManager and it will configured to also send logging output to its parent's Handlers. It will be registered in the LogManager global namespace.
Note: The LogManager may only retain a weak reference to the newly
created Logger. It is important to understand that a previously
created Logger with the given name may be garbage collected at any
time if there is no strong reference to the Logger. In particular,
this means that two back-to-back calls like
getLogger("MyLogger", ...).log(...)
may use different Logger
objects named "MyLogger" if there is no strong reference to the
Logger named "MyLogger" elsewhere in the program.
If the named Logger already exists and does not yet have a localization resource bundle then the given resource bundle name is used. If the named Logger already exists and has a different resource bundle name then an IllegalArgumentException is thrown.
name
- A name for the logger. This should
be a dot-separated name and should normally
be based on the package name or class name
of the subsystem, such as java.net
or javax.swingresourceBundleName
- name of ResourceBundle to be used for localizing
messages for this logger. May be null
if none of the messages require localization.MissingResourceException
- if the resourceBundleName is non-null and
no corresponding resource can be found.IllegalArgumentException
- if the Logger already exists and uses
a different resource bundle name; or if
resourceBundleName
is null
but the named
logger has a resource bundle set.NullPointerException
- if the name is null.public static Logger getAnonymousLogger()
This factory method is primarily intended for use from applets. Because the resulting Logger is anonymous it can be kept private by the creating class. This removes the need for normal security checks, which in turn allows untrusted applet code to update the control state of the Logger. For example an applet can do a setLevel or an addHandler on an anonymous Logger.
Even although the new logger is anonymous, it is configured
to have the root logger ("") as its parent. This means that
by default it inherits its effective level and handlers
from the root logger. Changing its parent via the
setParent
method
will still require the security permission specified by that method.
public static Logger getAnonymousLogger(String resourceBundleName)
This factory method is primarily intended for use from applets. Because the resulting Logger is anonymous it can be kept private by the creating class. This removes the need for normal security checks, which in turn allows untrusted applet code to update the control state of the Logger. For example an applet can do a setLevel or an addHandler on an anonymous Logger.
Even although the new logger is anonymous, it is configured
to have the root logger ("") as its parent. This means that
by default it inherits its effective level and handlers
from the root logger. Changing its parent via the
setParent
method
will still require the security permission specified by that method.
resourceBundleName
- name of ResourceBundle to be used for localizing
messages for this logger.
May be null if none of the messages require localization.MissingResourceException
- if the resourceBundleName is non-null and
no corresponding resource can be found.public ResourceBundle getResourceBundle()
ResourceBundle
that was either
set by the setResourceBundle
method or
mapped from the
the resource bundle name set via the getLogger
factory
method for the current default locale.
null
, then the Logger will use a resource
bundle or resource bundle name inherited from its parent.null
)public String getResourceBundleName()
getLogger
factory method,
or the base name of the
ResourceBundle set through setResourceBundle
method.
null
, then the Logger will use a resource
bundle or resource bundle name inherited from its parent.null
)public void setFilter(Filter newFilter) throws SecurityException
After passing the initial "level" check, the Logger will call this Filter to check if a log record should really be published.
newFilter
- a filter object (may be null)SecurityException
- if a security manager exists,
this logger is not anonymous, and the caller
does not have LoggingPermission("control").public Filter getFilter()
public void log(LogRecord record)
All the other logging methods in this class call through this method to actually perform any logging. Subclasses can override this single method to capture all log activity.
record
- the LogRecord to be publishedpublic void log(Level level, String msg)
If the logger is currently enabled for the given message level then the given message is forwarded to all the registered output Handler objects.
level
- One of the message level identifiers, e.g., SEVEREmsg
- The string message (or a key in the message catalog)public void log(Level level, Supplier<String> msgSupplier)
If the logger is currently enabled for the given message level then the message is constructed by invoking the provided supplier function and forwarded to all the registered output Handler objects.
level
- One of the message level identifiers, e.g., SEVEREmsgSupplier
- A function, which when called, produces the
desired log messagepublic void log(Level level, String msg, Object param1)
If the logger is currently enabled for the given message level then a corresponding LogRecord is created and forwarded to all the registered output Handler objects.
level
- One of the message level identifiers, e.g., SEVEREmsg
- The string message (or a key in the message catalog)param1
- parameter to the messagepublic void log(Level level, String msg, Object[] params)
If the logger is currently enabled for the given message level then a corresponding LogRecord is created and forwarded to all the registered output Handler objects.
level
- One of the message level identifiers, e.g., SEVEREmsg
- The string message (or a key in the message catalog)params
- array of parameters to the messagepublic void log(Level level, String msg, Throwable thrown)
If the logger is currently enabled for the given message level then the given arguments are stored in a LogRecord which is forwarded to all registered output handlers.
Note that the thrown argument is stored in the LogRecord thrown property, rather than the LogRecord parameters property. Thus it is processed specially by output Formatters and is not treated as a formatting parameter to the LogRecord message property.
level
- One of the message level identifiers, e.g., SEVEREmsg
- The string message (or a key in the message catalog)thrown
- Throwable associated with log message.public void log(Level level, Throwable thrown, Supplier<String> msgSupplier)
If the logger is currently enabled for the given message level then the
message is constructed by invoking the provided supplier function. The
message and the given Throwable
are then stored in a LogRecord
which is forwarded to all registered output handlers.
Note that the thrown argument is stored in the LogRecord thrown property, rather than the LogRecord parameters property. Thus it is processed specially by output Formatters and is not treated as a formatting parameter to the LogRecord message property.
level
- One of the message level identifiers, e.g., SEVEREthrown
- Throwable associated with log message.msgSupplier
- A function, which when called, produces the
desired log messagepublic void logp(Level level, String sourceClass, String sourceMethod, String msg)
If the logger is currently enabled for the given message level then the given message is forwarded to all the registered output Handler objects.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestmsg
- The string message (or a key in the message catalog)public void logp(Level level, String sourceClass, String sourceMethod, Supplier<String> msgSupplier)
If the logger is currently enabled for the given message level then the message is constructed by invoking the provided supplier function and forwarded to all the registered output Handler objects.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestmsgSupplier
- A function, which when called, produces the
desired log messagepublic void logp(Level level, String sourceClass, String sourceMethod, String msg, Object param1)
If the logger is currently enabled for the given message level then a corresponding LogRecord is created and forwarded to all the registered output Handler objects.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestmsg
- The string message (or a key in the message catalog)param1
- Parameter to the log message.public void logp(Level level, String sourceClass, String sourceMethod, String msg, Object[] params)
If the logger is currently enabled for the given message level then a corresponding LogRecord is created and forwarded to all the registered output Handler objects.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestmsg
- The string message (or a key in the message catalog)params
- Array of parameters to the messagepublic void logp(Level level, String sourceClass, String sourceMethod, String msg, Throwable thrown)
If the logger is currently enabled for the given message level then the given arguments are stored in a LogRecord which is forwarded to all registered output handlers.
Note that the thrown argument is stored in the LogRecord thrown property, rather than the LogRecord parameters property. Thus it is processed specially by output Formatters and is not treated as a formatting parameter to the LogRecord message property.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestmsg
- The string message (or a key in the message catalog)thrown
- Throwable associated with log message.public void logp(Level level, String sourceClass, String sourceMethod, Throwable thrown, Supplier<String> msgSupplier)
If the logger is currently enabled for the given message level then the
message is constructed by invoking the provided supplier function. The
message and the given Throwable
are then stored in a LogRecord
which is forwarded to all registered output handlers.
Note that the thrown argument is stored in the LogRecord thrown property, rather than the LogRecord parameters property. Thus it is processed specially by output Formatters and is not treated as a formatting parameter to the LogRecord message property.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestthrown
- Throwable associated with log message.msgSupplier
- A function, which when called, produces the
desired log message@Deprecated public void logrb(Level level, String sourceClass, String sourceMethod, String bundleName, String msg)
logrb(java.util.logging.Level, java.lang.String,
java.lang.String, java.util.ResourceBundle, java.lang.String,
java.lang.Object...)
instead.If the logger is currently enabled for the given message level then the given message is forwarded to all the registered output Handler objects.
The msg string is localized using the named resource bundle. If the resource bundle name is null, or an empty String or invalid then the msg string is not localized.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestbundleName
- name of resource bundle to localize msg,
can be nullmsg
- The string message (or a key in the message catalog)@Deprecated public void logrb(Level level, String sourceClass, String sourceMethod, String bundleName, String msg, Object param1)
logrb(java.util.logging.Level, java.lang.String,
java.lang.String, java.util.ResourceBundle, java.lang.String,
java.lang.Object...)
insteadIf the logger is currently enabled for the given message level then a corresponding LogRecord is created and forwarded to all the registered output Handler objects.
The msg string is localized using the named resource bundle. If the resource bundle name is null, or an empty String or invalid then the msg string is not localized.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestbundleName
- name of resource bundle to localize msg,
can be nullmsg
- The string message (or a key in the message catalog)param1
- Parameter to the log message.@Deprecated public void logrb(Level level, String sourceClass, String sourceMethod, String bundleName, String msg, Object[] params)
logrb(java.util.logging.Level, java.lang.String,
java.lang.String, java.util.ResourceBundle, java.lang.String,
java.lang.Object...)
instead.If the logger is currently enabled for the given message level then a corresponding LogRecord is created and forwarded to all the registered output Handler objects.
The msg string is localized using the named resource bundle. If the resource bundle name is null, or an empty String or invalid then the msg string is not localized.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestbundleName
- name of resource bundle to localize msg,
can be null.msg
- The string message (or a key in the message catalog)params
- Array of parameters to the messagepublic void logrb(Level level, String sourceClass, String sourceMethod, ResourceBundle bundle, String msg, Object... params)
If the logger is currently enabled for the given message level then a corresponding LogRecord is created and forwarded to all the registered output Handler objects.
The msg
string is localized using the given resource bundle.
If the resource bundle is null
, then the msg
string is not
localized.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- Name of the class that issued the logging requestsourceMethod
- Name of the method that issued the logging requestbundle
- Resource bundle to localize msg
,
can be null
.msg
- The string message (or a key in the message catalog)params
- Parameters to the message (optional, may be none).@Deprecated public void logrb(Level level, String sourceClass, String sourceMethod, String bundleName, String msg, Throwable thrown)
logrb(java.util.logging.Level, java.lang.String,
java.lang.String, java.util.ResourceBundle, java.lang.String,
java.lang.Throwable)
instead.If the logger is currently enabled for the given message level then the given arguments are stored in a LogRecord which is forwarded to all registered output handlers.
The msg string is localized using the named resource bundle. If the resource bundle name is null, or an empty String or invalid then the msg string is not localized.
Note that the thrown argument is stored in the LogRecord thrown property, rather than the LogRecord parameters property. Thus it is processed specially by output Formatters and is not treated as a formatting parameter to the LogRecord message property.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- name of class that issued the logging requestsourceMethod
- name of method that issued the logging requestbundleName
- name of resource bundle to localize msg,
can be nullmsg
- The string message (or a key in the message catalog)thrown
- Throwable associated with log message.public void logrb(Level level, String sourceClass, String sourceMethod, ResourceBundle bundle, String msg, Throwable thrown)
If the logger is currently enabled for the given message level then the given arguments are stored in a LogRecord which is forwarded to all registered output handlers.
The msg
string is localized using the given resource bundle.
If the resource bundle is null
, then the msg
string is not
localized.
Note that the thrown argument is stored in the LogRecord thrown property, rather than the LogRecord parameters property. Thus it is processed specially by output Formatters and is not treated as a formatting parameter to the LogRecord message property.
level
- One of the message level identifiers, e.g., SEVEREsourceClass
- Name of the class that issued the logging requestsourceMethod
- Name of the method that issued the logging requestbundle
- Resource bundle to localize msg
,
can be null
msg
- The string message (or a key in the message catalog)thrown
- Throwable associated with the log message.public void entering(String sourceClass, String sourceMethod)
This is a convenience method that can be used to log entry to a method. A LogRecord with message "ENTRY", log level FINER, and the given sourceMethod and sourceClass is logged.
sourceClass
- name of class that issued the logging requestsourceMethod
- name of method that is being enteredpublic void entering(String sourceClass, String sourceMethod, Object param1)
This is a convenience method that can be used to log entry to a method. A LogRecord with message "ENTRY {0}", log level FINER, and the given sourceMethod, sourceClass, and parameter is logged.
sourceClass
- name of class that issued the logging requestsourceMethod
- name of method that is being enteredparam1
- parameter to the method being enteredpublic void entering(String sourceClass, String sourceMethod, Object[] params)
This is a convenience method that can be used to log entry to a method. A LogRecord with message "ENTRY" (followed by a format {N} indicator for each entry in the parameter array), log level FINER, and the given sourceMethod, sourceClass, and parameters is logged.
sourceClass
- name of class that issued the logging requestsourceMethod
- name of method that is being enteredparams
- array of parameters to the method being enteredpublic void exiting(String sourceClass, String sourceMethod)
This is a convenience method that can be used to log returning from a method. A LogRecord with message "RETURN", log level FINER, and the given sourceMethod and sourceClass is logged.
sourceClass
- name of class that issued the logging requestsourceMethod
- name of the methodpublic void exiting(String sourceClass, String sourceMethod, Object result)
This is a convenience method that can be used to log returning from a method. A LogRecord with message "RETURN {0}", log level FINER, and the gives sourceMethod, sourceClass, and result object is logged.
sourceClass
- name of class that issued the logging requestsourceMethod
- name of the methodresult
- Object that is being returnedpublic void throwing(String sourceClass, String sourceMethod, Throwable thrown)
This is a convenience method to log that a method is terminating by throwing an exception. The logging is done using the FINER level.
If the logger is currently enabled for the given message level then the given arguments are stored in a LogRecord which is forwarded to all registered output handlers. The LogRecord's message is set to "THROW".
Note that the thrown argument is stored in the LogRecord thrown property, rather than the LogRecord parameters property. Thus it is processed specially by output Formatters and is not treated as a formatting parameter to the LogRecord message property.
sourceClass
- name of class that issued the logging requestsourceMethod
- name of the method.thrown
- The Throwable that is being thrown.public void severe(String msg)
If the logger is currently enabled for the SEVERE message level then the given message is forwarded to all the registered output Handler objects.
msg
- The string message (or a key in the message catalog)public void warning(String msg)
If the logger is currently enabled for the WARNING message level then the given message is forwarded to all the registered output Handler objects.
msg
- The string message (or a key in the message catalog)public void info(String msg)
If the logger is currently enabled for the INFO message level then the given message is forwarded to all the registered output Handler objects.
msg
- The string message (or a key in the message catalog)public void config(String msg)
If the logger is currently enabled for the CONFIG message level then the given message is forwarded to all the registered output Handler objects.
msg
- The string message (or a key in the message catalog)public void fine(String msg)
If the logger is currently enabled for the FINE message level then the given message is forwarded to all the registered output Handler objects.
msg
- The string message (or a key in the message catalog)public void finer(String msg)
If the logger is currently enabled for the FINER message level then the given message is forwarded to all the registered output Handler objects.
msg
- The string message (or a key in the message catalog)public void finest(String msg)
If the logger is currently enabled for the FINEST message level then the given message is forwarded to all the registered output Handler objects.
msg
- The string message (or a key in the message catalog)public void severe(Supplier<String> msgSupplier)
If the logger is currently enabled for the SEVERE message level then the message is constructed by invoking the provided supplier function and forwarded to all the registered output Handler objects.
msgSupplier
- A function, which when called, produces the
desired log messagepublic void warning(Supplier<String> msgSupplier)
If the logger is currently enabled for the WARNING message level then the message is constructed by invoking the provided supplier function and forwarded to all the registered output Handler objects.
msgSupplier
- A function, which when called, produces the
desired log messagepublic void info(Supplier<String> msgSupplier)
If the logger is currently enabled for the INFO message level then the message is constructed by invoking the provided supplier function and forwarded to all the registered output Handler objects.
msgSupplier
- A function, which when called, produces the
desired log messagepublic void config(Supplier<String> msgSupplier)
If the logger is currently enabled for the CONFIG message level then the message is constructed by invoking the provided supplier function and forwarded to all the registered output Handler objects.
msgSupplier
- A function, which when called, produces the
desired log messagepublic void fine(Supplier<String> msgSupplier)
If the logger is currently enabled for the FINE message level then the message is constructed by invoking the provided supplier function and forwarded to all the registered output Handler objects.
msgSupplier
- A function, which when called, produces the
desired log messagepublic void finer(Supplier<String> msgSupplier)
If the logger is currently enabled for the FINER message level then the message is constructed by invoking the provided supplier function and forwarded to all the registered output Handler objects.
msgSupplier
- A function, which when called, produces the
desired log messagepublic void finest(Supplier<String> msgSupplier)
If the logger is currently enabled for the FINEST message level then the message is constructed by invoking the provided supplier function and forwarded to all the registered output Handler objects.
msgSupplier
- A function, which when called, produces the
desired log messagepublic void setLevel(Level newLevel) throws SecurityException
If the new level is null, it means that this node should inherit its level from its nearest ancestor with a specific (non-null) level value.
newLevel
- the new value for the log level (may be null)SecurityException
- if a security manager exists,
this logger is not anonymous, and the caller
does not have LoggingPermission("control").public Level getLevel()
public boolean isLoggable(Level level)
level
- a message logging levelpublic String getName()
public void addHandler(Handler handler) throws SecurityException
By default, Loggers also send their output to their parent logger. Typically the root Logger is configured with a set of Handlers that essentially act as default handlers for all loggers.
handler
- a logging HandlerSecurityException
- if a security manager exists,
this logger is not anonymous, and the caller
does not have LoggingPermission("control").public void removeHandler(Handler handler) throws SecurityException
Returns silently if the given Handler is not found or is null
handler
- a logging HandlerSecurityException
- if a security manager exists,
this logger is not anonymous, and the caller
does not have LoggingPermission("control").public Handler[] getHandlers()
public void setUseParentHandlers(boolean useParentHandlers)
useParentHandlers
- true if output is to be sent to the
logger's parent.SecurityException
- if a security manager exists,
this logger is not anonymous, and the caller
does not have LoggingPermission("control").public boolean getUseParentHandlers()
public void setResourceBundle(ResourceBundle bundle)
bundle
- The resource bundle that this logger shall use.NullPointerException
- if the given bundle is null
.IllegalArgumentException
- if the given bundle doesn't have a
base name,
or if this logger already has a resource bundle set but
the given bundle has a different base name.SecurityException
- if a security manager exists,
this logger is not anonymous, and the caller
does not have LoggingPermission("control").public Logger getParent()
This method returns the nearest extant parent in the namespace. Thus if a Logger is called "a.b.c.d", and a Logger called "a.b" has been created but no logger "a.b.c" exists, then a call of getParent on the Logger "a.b.c.d" will return the Logger "a.b".
The result will be null if it is called on the root Logger in the namespace.
public void setParent(Logger parent)
It should not be called from application code.
parent
- the new parent loggerSecurityException
- if a security manager exists and if
the caller does not have LoggingPermission("control").Dracula Javadoc Sample, Made with Allan Im.


Here is an implementation of Chess written in Ruby. The game is played in the terminal and supports two players.
Ruby


Shipping Details
$7.99 Standard Shipping
Free Shipping (over $49)
Summary
SUBTOTAL
$55.00
SHIPPING
-
TAX
$5.00
TOTAL
$60.00
Next
Cancel


nips nips2002 nips2002-161 nips2002-161-reference knowledge-graph by maker-knowledge-mining
Source: pdf
Author: John Langford, John Shawe-Taylor
Abstract: unkown-abstract
[1] P. L. Bartlett,
[2] Thomas Cover and Joy Thomas,
[3] Ralf Herbrich and Thore Graepel, A PAC-Bayesian Margin Bound for Linear Classifiers: Why SVMs work. In Advances in Neural fuformation Processing Systems 13, pages 224-230. 2001.
[4] T. Jaakkola, M. Mella, T. Jebara,
[5] John Langford and Rich Caruana, (Not) Bounding the True Error NIPS2001.
[6] John Langford, Matthias Seeger, and Nimrod Megiddo,
[7] John Langford and Matthias Seeger,
[8] David McAllester,
[9] Yoav Freund and Robert E. Schapire,
[10] Matthias Seeger,
[11] Robert E. Schapire, Yoav Freund, Peter Bartlett, and Wee Sun Lee,
[12] J. Shawe-Taylor, P. L. Bartlett, R. C. Williamson, and M. Anthony. Structural risk minimization over data-dependent hierarchies. IEEE funsactions on Information Theory, 44(5):1926--1940, 1998.


WITNESS LIST
Administration
May 20, 2015 3:00 PM - or upon adjournment
AGAINST:
Bayless, James (State Cemetery Committee), Austin, TX
Sayers, Scott Chairmam-texas state cemetery committee (Texas state cemetery committee),
Austin, TX
ON:
Sneed, John Executive Director (State Preservation Board), Austin, TX
Registering, but not testifying:
FOR:
Hawkins, John SVP, Government Relations (Texas Hospital Association), Austin, TX
Registering, but not testifying:
FOR:
Ogle, Skip (Self), Tyler, TX
Registering, but not testifying:
FOR:
Johnson, Rob (Self), New Braunfels, TX
Registering, but not testifying:
FOR:
Patterson, T.J. (City of Fort Worth), Fort Worth, TX
ON:
Amos, Nancy Senior vice president. (Fort worth transportation authority), Fort worth, TX
Registering, but not testifying:
FOR:
Ogle, Skip (Self), Tyler, TX


-
Philip HorgerThis is a blip
And this is the text inside it.
Philip Horger -
YuriThis is another
-
YuriThis is
-
YuriThis is another HAHAHA PHILIP HAS TOTALLY EDITED THISYuri, Philip Horger
-
And this is the text inside it.


Username
{{profile.username}}
Gender
{{profile.gender | gender}}
Birthdate
{{profile.birthdate}}
Condition
{{profile.condition | condition}}
Home address
{{profile.homeAddress | unknown}}
Phone
{{profile.phone | phone}}
Email
{{profile.email | unknown}}


Test
Help Me Pick New Logo Through 3 April 2016!
I am in the process of running a logo design contest on 99designs and have created a poll with 6 of the best logo designs I've received. I would love for you to vote on the logo design. It only takes a minute.
Like Sci-Fi? Read My New Online Fiction Series.
Do you like Sci-Fi? While I finish up my next novel, I have started an online fiction series called Forbearance. Picking up from the canteen scene in Bellicose, we meet Keius Minjen, a postal marine, as he tries to survive the battle planet Guna to exact revenge and one day liberate his homeland.
Sign-up if you want me to send you news about upcoming installments of Forbearance or my other writings.
The Ten-Seven Guide assists novice players with early empire building to enhance their overall Astro Empires playing experience. The goal of this guide is to help players build ten bases in the first week, and educate players in key aspects of early game play. It is important to balance astro selection, structure building, and scouting. For the first three days player bases are immune to attack, but players need to remain focused on building proper defenses. This guide will also lightly touch on combat, which is discussed in greater detail on this site. The one-week goal provides “free” players (those who will not be upgrading) a chance to build one extra base before free account restrictions are applied.
This guide was originally written in September 2007, and validated on Ceti and Alpha. Soon after, Astro Empires started tinkering with the rules of gameplay for the first week of an account. Players were protected for the first week, then three days. At the time of this writing (May 2010), the rules protect players until tenth level. This guide was re-evaluated at the opening of the Ixion server (May 2010), although earlier attempts to update the guide were made. The original version of this guide is discussed a bit in A Ten Seven Diary; which may give new players a chance to read their future.
The important thing to remember about this guide is diligence. The rules change means players cannot be sloppy at any time. The time demands the first week are high; perhaps higher than other times.  This guide favors the “Turtle” approach, high defenses over high fleet; as novice players may be less prepared for the rigors of constant combat.
This guide does not dive into details. There are more detailed discussions of much of what is written here in other guides found on this site. Some advice here goes against popular wisdom, and the guide tries to explain why. This guide also assumes you have at least read the information provided by Astro Empires.
Astro Picking
Your First Astro. You will start on a moon, that is how Astro Empires is programmed. The ideal start astro is a Metal-3 (Rocky, Crater or Metallic) moon in Slot-1 or Slot-2. If you do not have both the quality of metal or the slot, restart your account until you do. This will take some time. If it seems you have no choice, prefer a Slot-1 or Slot-2 Metal-2 (Arid, Tundra, Gaia or Earthy) astro. The best choice is a Slot-2 Rocky for a start as it provides excellent fertility and decent solar.
Metal-3 astros (which also includes Astroids) provide the best construction/production rates, which is critical at the beginning. Metal-2 astros provide less, but they provide more space for structures. For this reason, some will advise Metal-2 astros for Research bases as they provide capacity to build your Research Labs. The first base tends to become a Research base, so you may decide keeping your Metal-2 base is acceptable.
The slot affects solar output and fertility. Slot-1 gives you the best solar energy, but Slot-2 provides a boost to fertility. The Advanced Base Guide provides a deeper discussion on why Slot-2s are the preferred choice.
Restarting accounts is a feature Astro Empires provides because players tended to delete accounts that had unacceptable astros and start over. This created a considerable amount of chaos. So, this feature provides more stability, while providing you a chance to have a decent start.
Other Astros. The Advanced Base Guide provides a recommendation of which bases to build after the first. The focus is on astros that you should seek next. It also discusses when you should prefer planets, moons or asteroids (a.k.a. Roids). In a nutshell, if you plan on upgrading, favor moons or roids. If you do not plan on upgrading, prefer Planets. Merovech, who always upgrades, prefers Roids, because it takes two terraforms to provide the same space as a Planet, and one terraform to provide the same space as a Moon; but cost of Planetary Ring defenses are ¼th that of Planets, or ½ that of Moons.
Location. Building your bases too close together is a very bad idea. Larger rivals may easily pick them off in rapid succession. Therefore, try not to have more than one base in a region. Defensively speaking, your bases need to be self-sufficient. The closest your bases should be is in adjacent regions, but even that risks your bases being attacked in short order by a dedicated opponent.
The table below lists the cost of each base, the cumulative cost of bases built that day, what econ you should have on that day to ensure you can plant those bases, and what day you should plant that base. Merovech managed to plant an extra base on Day Three on Ixion, which helped ensure he built all the bases in time.
| Base Establishment Quota | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| Bases | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| Cost | 50 | 100 | 200 | 400 | 800 | 1600 | 3200 | 6400 | 12800 |
| Total | 350 | 1200 | 4800 | 19200 | |||||
| Econ | 15 | 50 | 200 | 800 | |||||
| Level | 6.5 | 8.5 | 12.2 | 17 | |||||
| Day | 3 | 3 | 3 | 4 | 4 | 5 | 5 | 6 | 6 |
Activity Guide
Once you’ve picked your base, it is time to start building. Remember, time is essential in the first day. You want to ensure your queues are full and no time is lost. When filling your queues, you will want to balance your activities. For example, when building a Metal Refinery or Robotics Factory, pick the less expensive structure. This is the cost-effective approach to construction. This section discusses construction objectives, research objectives and production objectives.
Construction
When you get your first base going, build Metal Refineries. I suggest building three Metal Refineries before anything else. You will run out of Population and Energy, so build an Urban Structure and another Solar Plant as needed. This guide assumes you will plan your queue to include Population and Energy expansion. When you research enough Energy, you can start building Fusion Plants.
After building your first set of Refineries, built a Research Lab. Then, build a Spaceport and find a neighbor to trade with. Some will build the Spaceport first then the Lab; so it is up to you. After the Spaceport, build a Shipyard; then return to building Refineries. The chart below shows what your goals are for Day-1, Day-2, and Day-3 for your first base. This enables you to start planting new bases on Day-3. The Others column are the overall build objectives for all other bases through Day-7. You should balance your queue to meet those objectives.
| Daily Construction Quota | ||||
|---|---|---|---|---|
| Day 1 | Day 2 | Day 3 | Others | |
| Metal Refineries | 7 | 10 | 15 | 10 |
| Robotics Factory | 4 | 6 | 6 | 6 |
| Research Labs | 5 | 8 | 8 | - |
| Shipyard | 4 | 6 | 8 | 1 |
| Spaceport | 4 | 5 | 5 | 5–10 |
| Turret | - | - | 1 | 1–3 |
| Crystal Mines | - | - | - | 5–10 |
Research Labs are only built on the first base and any Research Bases during the first week. Crystal Mines are only built on astros with Crystal 2 (Roids) or Crystal 3 (Crystalline). You will experience a financial crunch as you run out of credits. Queues are your friends as you can go do other things (such as sleep) while the base constructs.
Turrets. The Base Defense Guide discusses defenses in greater detail. When you are near Tenth level, you will need defenses. This guide recommends you satisfy your requirements for Missile Turrets and build one on all bases right before you reach Tenth level. The Defenses section below discusses your needs in a bit more detail.
New Base Goals. As each base new is built, you will want to work toward the Others goal. Merovech recommends the Shipyard be built before you have to build an Urban Structure when you are above Tenth level. This reduces the likelihood of a scout-tap. Otherwise, build the Shipyard before your first Spaceport. This reduces piracy.
Research
Once you have your first Research Lab built, you should start your research. The chart below shows the end-of-day goals for research. You must build enough Research Labs to support the higher technologies. So, if you cannot research a technology during its target day, you are behind in your construction. The parenthetical number in the chart below describes the number of research labs you need to research that tech. Start by researching Energy, then add Computer and alternate between the two techs until you satisfy the Computer-2 objective.
| Daily Research Quota | ||||
|---|---|---|---|---|
| Day 1 | Day 2 | Day 3 | Day 5 | |
| Computer | 2 | 2 | 2 | 10 |
| Energy | 6 | 8 | 8 | 10 |
| Stellar Drive | 4 (5) | 4 (5) | 4 (5) | |
| Warp Drive | 1 (8) | 1 (8) | ||
| Laser | 1 | 4 | ||
| Armour | 2 | 4 | ||
| Missile |   | 1 | 6 | |
- Computer
- Computer-2 unlocks Robotics Factories. Computer-6 unlocks Command Centers, which allows you to occupy friends and neighbors.
- Energy
- Energy-2 unlocks Laser. Energy-6 unlocks Fusion Plants and Stellar Drives. Energy-8 unlocks Warp Drive. Energy-10 unlocks Shielding
- Stellar Drive
- Stellar-4 unlocks Warp Drive (with Energy-8).
- Warp Drive
- Warp-1 unlocks Scout Ships (SS) and Outpost Ships (OS).
- Laser
- Laser-1 unlocks Fighters. Laser-4 (with Energy-6) unlocks Plasma, which allows Cruisers (with Armour-10 and Shielding-2) and Plasma Turrets (with Armour-6).
- Armour
- Armour-2 helps enable Corvettes
Production
Production should focus on scouting and planting new bases. This guide recommends three units, shown below with the number of Shipyards and Research Targets.
| Unit | Shipyards | Research | Notes |
|---|---|---|---|
| Fighters (FT) | 1 | Laser 1 | Defend your Trade Routes |
| Corvettes (CV) | 4 | Laser 2 + Stellar Drive 1 + Armour 2 | Preferred scout unit |
| Outpost Ships (OS) | 8 | Warp-1 | Build new bases |
There are a couple other units that you may consider adding if you want to pick on your neighbors: Frigate and Recycler. Frigates allow you to carry Fighters that can more cheaply attack your neighbors. Recyclers allow you to recover the debris (derbs) that enhances profitability. This guide does not need these units; but Astro Empires is an economic combat simulator.
Never send a “naked” Outpost Ship. It takes hours build and send one to a decent base location. If you are scouting, you will build and send your first Corvette, then build an Outpost ship. That Corvette should be moved to the Outpost Ship’s target astro so it can help defend it. If you are not scouting (because you’re picking only Roids), then you can build and send your Outpost ship, then build and send your Corvette. The Corvette will typically beat the Outpost ship.
You should anticipate your trade routes being hit when you can build a Corvette—because your neighbors have them, too. So, before you are Corvette-capable, build a Fighter. This prevents your trade routes from being easily pirated.
Scouting
Once you have researched technologies and built the Shipyards, then build one Corvette. As this guide recommends one base per region, send it to a neighboring region. Bookmark any potential base locations (Slot-1/-2 Rocky, Crater, Metallic or Roid). You can actually scout Roids without having a Corvette; another reason why Merovech likes them. Send the Corvette to each of the regions surrounding yours. That gives you nine total regions to plant bases in. Then, just let whim take you. Make sure you pick a couple base locations in each region as your neighbors are doing the same.
Why Corvettes? Corvettes are fast combat units. Scout Ships are faster, but are not combatative.  Corvettes can be used to kill any Outpost Ships you see, unless the OS is a guild mate’s.
Trade Routes & Banking
Economy is key at all states of Astro Empires. This is an economic simulator with combat. Build one Spaceport as advised above, then build to five. Once all bases have five Spaceports, build until each has ten. This gives you ample trade routes to help your economy grow.
Who to trade with? You really have only two choices: yourself and your neighbors. Trading with yourself is a good short-term solution if you are having problems finding partners. Once you are established, slowly replace self-trades with neighbors. Until you have Prings, Merovech does not recommend trades outside your galaxy. This is because the value of a pirated route is higher for those routes, making them a more valuable target to pirates.
Banking credits is how you safeguard your credits from pillage. If you are attacked, a portion of your available credits goes to the victor. By either stashing credits in long-term research or construction projects, or by production Goods, you can prevent those credits from going to your rival. You can cancel the research or construction and spend the credits how you want. Don’t cancel goods.
Goods production is good for when you know when you need money available, such as when you know you will be planting your next base. Astro Empires lets you put in a time for completion. So, if you know you will be planting a base in eight hours, type ‘8h’ in the production field for Goods. It will provide a fairly accurate number of goods.
Defenses
Earlier, this guide shows that you need an economy of nearly 800 to build your last base. To accomplish this with the previous nine bases, your average base economy will be between 45–65. It is imperative that you defend your bases so they are not profitable to your attacker. This discourages attack at this stage of the game, as the primary focus should be on empire build.
The chart below is a variation of the one found in the Base Defense Guide, with values adjusted for technology levels found at this early stage of the game.  The chart shows what turrets are able to defend what base economy at what strength. The objective is to make a base non-profitable to an attacker. This is generally enough to discourage many attackers. The value in parenthesis is the level of economic protection given. This assumes you have no extra credits waiting to be spent.
For example, Missile Turrets-10 can defend a base with econ 22. This means that the attacker will have a net loss if he attacks a base with Missile Turrets-10 and an economy of 22 or less. Conversely, if the base economy is above 22, he will have a net profit. Overhead defensive fleet is ignored as they create derbs that can be harvested, increasing profitability.
| \ | Fighters Killed/Needed | Corvettes Killed/Needed | ||||
|---|---|---|---|---|---|---|
| Turrets | @5 | @10 | @15 | @5 | @10 | @15 |
| Laser | (13) 20/20 | (19) 40/40 | (24) 60/60 | (19) 10/10 | (27) 20/20 | (33) 60/60 |
| Missile | (15) 26/40 | (22) 52/80 | (27) 78/120 | (22) 13/20 | (31) 26/40 | (38) 39/60 |
| Plasma | (22) 52/60 | (31) 104/120 | (38) 156/180 | (31) 26/30 | (44) 52/60 | (54) 78/90 |
| Ion | (23) 56/240 | (32) 112/480 | (39) 168/600 | (32) 26/60 | (46) 66/120 | (56) 84/180 |
The chart includes the economic protection against the typical fighter drop and against the typical Corvette swarm. While the Ion Turret does not provide much more economic protection, you should take notice of the value of its weak shields. In order for a Fighter drop or Corvette swarm to crack the turret in one shot, it takes significantly more. That is, it takes twice as many Corvettes and four times as many Fighters to take the base at a profit.
Turret economic protection drops significantly beyond its listed level. So, you cannot add the Missile Turrets-15 economic protection of 27 to Ion Turret-5 economic protection of 23 to get an economic protection of 60. The actual combined economic value of that combination is 35. This is because of how Astro Empires calculates the pillage bonus.
Look to the Base Defense Guide for base defense standards. The Small Fleet Doctrine provides an approach to efficient fleet construction that is valuable after the first week.


| standard taglib implementation of the JSP Standard Tag Library |
| Examples Introduction General Purpose Conditionals Iterators Import I18N & Formatting XML SQL Functions TLV |
toString()
value of the items in the
Customers
collection.Another simple example. Similar to the previous one, except that in this case
there is no collection to iterate over. The items
attribute is
optional in the <forEach>
tag. When it is not specified,
the range attributes must be used to iterate a specific number of times over
the tag's body. In this example, we simply iterate over the integer values specified
by the range attributes.
The <forEach>
tag supports a large number of data types
for the collection of objects to iterate over. In this example, we feature the
following data types: array of primitives, array of objects, Enumeration, Properties
(Map), String (Comma Separated Values).
The iterator tag exposes a wealth of information relative to the iteration taking place. This example features some of that status information.
The iterator tags expose interface IteratorTag to allow custom tags to establish implicit collaboration. This example shows two custom tags, <even> and <odd> who take advantage of this implicit collaboration.
The <forEach> tag provides the basic iteration capabilities. <forTokens> is a specialization for the handling of Strings of tokens. Essentially the same as <forEach>, except that it only applies to Strings of tokens and that it has an extra attribute "delims" to specify the token delimiter.
JSTL exposes in its API the abstract class LoopTagSupport to facilitate the implementation of custom iterator tags that leverage the standard iteration behavior defined in JSTL. This example shows a custom iterator tag that shows all Locale objects available in the server and a custom conditional sub-tag that display the default locale.
| standard taglib implementation of the JSP Standard Tag Library |


You dont like the modules Chuck installs when creating a new project? No problem! Just specify your own module set. For example you want to use Apache / MySQL instead of Nginx / Postgres and dont like unittests and debugging stuff. Edit the config file ~/django_chuck_conf.py and add the following line
default_modules=["core", "south", "mysql", "apache", "django-extensions"]
You found one module that you want to customize? Please dont do your changes in the original code. It gets overwritten when you update to a new version of Django-Chuck.
Instead you should copy the module to another directory (e.g. ~/my_chuck_modules), modify it and tell Chuck to look there first. On Linux systems Chucks core modules are stored in /usr/share/django-chuck, on Mac OS X in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/django-chuck if you installed Python via MacPorts otherwise in /System/Library/Frameworks/Python.framework/Versions/2.7./share/django-chuck.
cp -av /path/to/old_module ~/my_chuck_modules/old_module
Afterwards edit your config file ~/django_chuck_conf.py and add the following
module_basedirs=["~/my_chuck_modules","."]
Now you can change the module to whatever you like and be sure it doesnt get erased somehow.
Note the core module must always be named core!
By overriding the core module you can even change the whole project structure to your own needs!
Of course you will have to adapt all additional modules you want to use, because the files to extend will point to wrong pathes.


The name of the car company and that of its president and CEO (a grandson of its founder Kiichiro Toyoda) are homophonous (or at least nearly homophonous)–in North American English, that is. Both [t] and [d] become flaps intervocalically after a stressed syllable.
It’s interesting though to see what people do when they want to emphasize which one of the two words were intended. According to various people I’ve polled (some of them currently taking my experimental class at the moment), one way to disambiguate is to shift stress to the last syllable and thus bleed the application of flapping.
This is an example of focus within-word focus. In his 1961 paper on contrastive accent and contrastive stress Dwight Bolinger describes another instance:
In a New Yorker cartoon a man stands upside down, with feet on the ceiling, in a psychiatrist’s office. The psychiatrist says to the man’s wife, ‘In a case of this kind, Mrs. Hall, our first concern is to persuade the patient that he is a stalagmite’ (last syllable underlined in original).
There’s a nice paper byRon Artstein that discusses the semantics of this kind of focus below he word level.
It’s conceivable though that a speaker might shift stress even in the absence of such a contrasting minimal pair, in order to clarify the spelling (or underlying form?) of a word. If this way of avoiding flapping became a regular process, it would constitute a violation of a generalization that is otherwise very robust, (the ‘two-many-solutions-problem’, see Donca Steriade’s paper on the P-Map and
Lev Blumenfeld’s 2006 thesis): Prosodically conditioned lenition-processes such as foot-internal flapping are not mirrored by hypothetical processes that would shift stress for the purpose of avoiding the lenition to apply. This is surprising under an optimality-theoretic analysis of such processes that uses the interaction of markedness and faithfulness constraints, since shifting stress would be another way to avoid the markedness-violation incurred by intervocalic post-tonic [t] or [d], so it would be easy to create a correct ranking for such a grammar. However, languages don’t ever seem to pick this solution. They either stay faithful or lenite.
So does the English strategy to emphasize the underlying (or at least orthographic) contrast between ‘Toyota’ and ‘Toyoda’ show that this generalization is not really true? Maybe not: for all we know, the stress shift observed here might be an acrobatic act that savvy users of English use to disambiguate otherwise homophonous words based on their own phonological knowledge, but not something that could ever become a regular grammatical process that could be generalized to all flapping environments.
On the other hand, maybe such a process is simply unlikely to be develop: Languages might conserve a contrast (as in languages that don’t have flapping, say British English) or lenite–but under what scenario would a language develop a stress shift that serves the purpose of avoiding a neutralization brought about by a lenition process which, however, could never be observed in the first place if there were a stress shift? Developing such a pre-emptive phonological process might simply be an unlikely scenario for a language change.
Shifting stress is different from other forms of enhancement (which one could argue are similarly pre-emptive) since it comes at the cost of changing a property that itself is contrastive in English, word-stress. Another difference might be that shifting stress does not exaggerate a tendency that is already present with the original contrast (That’s an empirical question: Could a hyper-articulated rendition of [toi!] in French at times be aspirated? Could a hyper-articulated British English rendition of [water] at times shift stress to the last syllable? It seems to me the former is much more likely than the latter, but maybe I’m wrong).
So it’s not so obvious that there is a ‘two-many-solutions’ problem in this case. Of course, this type of explanation might only be feasible in a small subset of cases in which the ‘two-many-solutions’ problem has been observed.
[some edits on February 9, 2010]


--- title: Collapsible Page Form description: A base collection of field components rendered within multi collapsible tabs. toc: true --- {% capture collapsible-page-form %}
Already a member? Log in


JUnit 4
This is a simple test to check that the JUnit 4 test runner works.
Song
Artist
My Sharona
The Knack
My Sharona
Nirvana
My Sharona
Rolf Harris
Big River
Johnny Cash
Big River
Grateful Dead
Big River
The Shaggs


Hola Mario!
Vino Rojo
So what vino rojo? Well... It's a joke. But like most jokes, it has an element of truth.
Two friends that don't even speak the same language were sitting in a bar one day...
Sounds like a joke.
The head of a large religious organization in South America and a database expert that lives in Las Vegas.
One man needed to track the membership of his organization and the other man knew how to do it.
So over a drink or two, Vino Rojo was born.
An Open Source Project to track families for Religious Organizations.
Have a Secure Place to keep the database.
To know who belongs to who. To know who did what. To know who owes what.
The rest is a little foggy....
The technical stuff...
An open source project done in Ruby/Rails to be kept in Github.
This is Hello World, my web site works.
If you are reading this, you are really lost.


{% extends 'base.html' %} {% block content %}
Hi, I'm Noah, and I'm a Sophomore at Marist College.
Usually, most of my time is absorbed by schoolwork because I took 17 credits in the fall. If I'm not doing school I'm probably doing one of the following:
For the past 2 years, I have channeled my love for filmmaking and video creation into my own YouTube channel.
It's been something that I have been able to make a small passive income from, but I enjoy doing it far beyond the money.
It's been a great outlet for me to express myself creatively and be able to grow an audience from it.
Hopefully now that the semester is over I can start to put more time into the channel.
My full-time job also revolves around YouTube. I'm the Head of Communications for a college content creator with over 125K subscribers.
I started out as an intern for him back in April 2020, and I was able to climb my way up into the Head of Communcations.
With my new position, I am in charge of all communications with brands, whether it's negotiating brand deals, time frames, sending deliverables, or sending invoices.
I love this job becuase it gives me insight into the YouTube business that I wouldn't be able to experience on my own.
I used to be a really competitive runner. In fact, I got recruited for XC/T&F at my old institution.
Once I became a college athlete, I realized that it wasn't for me, and it took the fun and passion that I once had for running.
So now that I don't run anymore, I'm beginning to make more of an effort to go to the gym. There's no excuse now for not being able to gain some weight and put on some muscle!
{% endblock %}


public class EarClipping extends java.lang.Object implements Decomposer
This algorithm operates only on simple polygons. A simple polygon is a polygon that has vertices that are connected by edges where:
This implementation does not handle polygons with holes, but accepts both Counter-Clockwise and Clockwise polygons.
The polygon to decompose must be 4 or more vertices.
This algorithm creates a valid triangulation (N - 2) triangles, then employs the Hertel-Mehlhorn algorithm to reduce the number of convex pieces.
This algorithm is O(n2).
| Modifier and Type | Class and Description |
|---|---|
class |
EarClipping.Vertex
Node class for a vertex within the simple polygon.
|
| Constructor and Description |
|---|
EarClipping() |
| Modifier and Type | Method and Description |
|---|---|
protected boolean |
contains(Vector2 a,
Vector2 b,
Vector2 c,
Vector2 p)
Returns true if the given point, p, is contained in the triangle created
by a, b, and c.
|
java.util.List<Convex> |
decompose(Vector2... points)
Performs the decomposition on the given list of polygon points returning a list of convex shapes.
|
protected boolean |
isEar(EarClipping.Vertex vertex,
int n)
Returns true if the given vertex is considered an ear vertex.
|
protected boolean |
isReflex(EarClipping.Vertex vertex)
Returns true if the given vertex is a reflex vertex.
|
public java.util.List<Convex> decompose(Vector2... points)
Decomposer
decompose
in interface Decomposer
points
- the list of pointsConvex
>protected boolean isReflex(EarClipping.Vertex vertex)
A reflex vertex is a vertex who's adjacent vertices create an an angle greater than 180 degrees (or the cross product is positive) for CCW vertex winding.
vertex
- the vertex to testprotected boolean isEar(EarClipping.Vertex vertex, int n)
A vertex is an ear vertex if the triangle created by the adjacent vertices of the given vertex does not contain any other vertices within it.
A reflex vertex cannot be an ear.
vertex
- the vertex to test for ear-nessn
- the number of verticesprotected boolean contains(Vector2 a, Vector2 b, Vector2 c, Vector2 p)
a
- the first point of the triangleb
- the second point of the trianglec
- the third point of the trianglep
- the point to test for containment


Toggle navigation
CDS
Diagnostics
Autonamous Diagnostics (network)
Manual Diagnostics (Cache)
Manuals
User
Profile
Dashboard
Logout
Manual Diagnostics
Select a code
P2516
P3437
P0091
Repair
Suggested Steps
Reload


{{eventMonth}}
{{eventDate}}
Funeral Service for
{{nameToUse}}
{{funeralHome}}
{{eventTime}} | {{eventMonth}}. {{eventDate}}
A Message from {{firstName}}'s Family
Thank you for supporting our family during this difficult time. We appreciate your condolences and invite you to join us as we celelbrate {{nameToUse}}'s Life.
Schedule of Events
-
8/23 7 p.m. | Private Family Viewing
-
8/24 4-8 p.m. | Public Visitation
- 8/25 10:30 a.m.. | Funeral Service, Internment and Luncheon to Follow
{{expandText}}


Hardware and tools¶
List of Hardware¶
| Item | Qty | Description | Vendor | Part # | |
|---|---|---|---|---|---|
| 1 | 4 | motor mount standoffs | 4-40 standoffs, 1.5” long | McMaster-Carr | 91780A120 |
| 2 | 1 | Knob | All Electronics | 226-2092-ND | |
| 3 | 4 | Enclosure standoffs | 4-40 standoff, 1.75” long | McMaster-Carr | 91780A038 |
| 4 | 4 | PCB standoffs | 4-40 standoff, 3/8” long | McMaster-Carr | 91780A509 |
| 5 | 1 | Pair of magnets | 1/2” x 1/8”, countersunk hole | K and J Magnetics | R822CS-P |
| 6 | 24 | Enclosure screws | 4-40 machine screws 1/4” long | McMaster-Carr | 91249A105 |
| 4 | Motor mount screws | 4-40 machine screws 3/8” long | McMaster-Carr | 91249A108 | |
| 7 | 1 | Set screw | 8-32, 1/4” long set screw | McMaster-Carr | 90669A190 |
| 8 | 4 | Rubber feet | Digikey | SJ5012-0-ND | |
| 9 | 2 | Motor screws | M2.6, 4 mm long | McMaster-Carr | 90353A110 |
| 10 | 2 | Magnet screws | 6-32, 3/8” long, flat screws | McMaster-Carr | 91771A146 |
| 11 | 1 | 3.3V motor | Jameco | 2158442 | |
| 12 | 1 | DC panel mount jack | MCM Electronics | 27-5867 |
Tools included in kit¶
Each kit includes an L-wrench for the set screw and mini-screwdriver. The mini-screwdriver has a reversible blade (see image below). One end has a Philips # 0 blade and the other end has a slotted 2.5 mm blade. To change between the different blades simply pull the scewdriver blade out from the handle.


SYNOPSIS
git send-email [options] <file|directory|rev-list options>…
DESCRIPTION
Takes the patches given on the command line and emails them out. Patches can be specified as files, directories (which will send all files in the directory), or directly as a revision list. In the last case, any format accepted by git-format-patch(1) can be passed to git send-email.
The header of the email is configurable by command line options. If not specified on the command line, the user will be prompted with a ReadLine enabled interface to provide the necessary information.
There are two formats accepted for patch files:
-
mbox format files
This is what git-format-patch(1) generates. Most headers and MIME formatting are ignored.
-
The original format used by Greg Kroah-Hartman’s send_lots_of_email.pl script
This format expects the first line of the file to contain the "Cc:" value and the "Subject:" of the message as the second line.
OPTIONS
Composing
- --annotate
-
Review and edit each patch you’re about to send. See the CONFIGURATION section for sendemail.multiedit.
- --bcc=<address>
-
Specify a "Bcc:" value for each email. Default is the value of sendemail.bcc.
The --bcc option must be repeated for each user you want on the bcc list.
- --cc=<address>
-
Specify a starting "Cc:" value for each email. Default is the value of sendemail.cc.
The --cc option must be repeated for each user you want on the cc list.
- --compose
-
Invoke a text editor (see GIT_EDITOR in git-var(1)) to edit an introductory message for the patch series.
When --compose is used, git send-email will use the From, Subject, and In-Reply-To headers specified in the message. If the body of the message (what you type after the headers and a blank line) only contains blank (or GIT: prefixed) lines the summary won’t be sent, but From, Subject, and In-Reply-To headers will be used unless they are removed.
Missing From or In-Reply-To headers will be prompted for.
See the CONFIGURATION section for sendemail.multiedit.
- --from=<address>
-
Specify the sender of the emails. If not specified on the command line, the value of the sendemail.from configuration option is used. If neither the command line option nor sendemail.from are set, then the user will be prompted for the value. The default for the prompt will be the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l".
- --in-reply-to=<identifier>
-
Make the first mail (or all the mails with
--no-thread
) appear as a reply to the given Message-Id, which avoids breaking threads to provide a new patch series. The second and subsequent emails will be sent as replies according to the--[no]-chain-reply-to
setting.So for example when
--thread
and--no-chain-reply-to
are specified, the second and subsequent patches will be replies to the first one like in the illustration below where[PATCH v2 0/3]
is in reply to[PATCH 0/2]
:[PATCH 0/2] Here is what I did... [PATCH 1/2] Clean up and tests [PATCH 2/2] Implementation [PATCH v2 0/3] Here is a reroll [PATCH v2 1/3] Clean up [PATCH v2 2/3] New tests [PATCH v2 3/3] Implementation
Only necessary if --compose is also set. If --compose is not set, this will be prompted for.
- --subject=<string>
-
Specify the initial subject of the email thread. Only necessary if --compose is also set. If --compose is not set, this will be prompted for.
- --to=<address>
-
Specify the primary recipient of the emails generated. Generally, this will be the upstream maintainer of the project involved. Default is the value of the sendemail.to configuration value; if that is unspecified, and --to-cmd is not specified, this will be prompted for.
The --to option must be repeated for each user you want on the to list.
- --8bit-encoding=<encoding>
-
When encountering a non-ASCII message or subject that does not declare its encoding, add headers/quoting to indicate it is encoded in <encoding>. Default is the value of the sendemail.assume8bitEncoding; if that is unspecified, this will be prompted for if any non-ASCII files are encountered.
Note that no attempts whatsoever are made to validate the encoding.
- --compose-encoding=<encoding>
-
Specify encoding of compose message. Default is the value of the sendemail.composeencoding; if that is unspecified, UTF-8 is assumed.
Sending
- --envelope-sender=<address>
-
Specify the envelope sender used to send the emails. This is useful if your default address is not the address that is subscribed to a list. In order to use the From address, set the value to "auto". If you use the sendmail binary, you must have suitable privileges for the -f parameter. Default is the value of the sendemail.envelopesender configuration variable; if that is unspecified, choosing the envelope sender is left to your MTA.
- --smtp-encryption=<encryption>
-
Specify the encryption to use, either ssl or tls. Any other value reverts to plain SMTP. Default is the value of sendemail.smtpencryption.
- --smtp-domain=<FQDN>
-
Specifies the Fully Qualified Domain Name (FQDN) used in the HELO/EHLO command to the SMTP server. Some servers require the FQDN to match your IP address. If not set, git send-email attempts to determine your FQDN automatically. Default is the value of sendemail.smtpdomain.
- --smtp-pass[=<password>]
-
Password for SMTP-AUTH. The argument is optional: If no argument is specified, then the empty string is used as the password. Default is the value of sendemail.smtppass, however --smtp-pass always overrides this value.
Furthermore, passwords need not be specified in configuration files or on the command line. If a username has been specified (with --smtp-user or a sendemail.smtpuser), but no password has been specified (with --smtp-pass or sendemail.smtppass), then the user is prompted for a password while the input is masked for privacy.
- --smtp-server=<host>
-
If set, specifies the outgoing SMTP server to use (e.g.
smtp.example.com
or a raw IP address). Alternatively it can specify a full pathname of a sendmail-like program instead; the program must support the-i
option. Default value can be specified by the sendemail.smtpserver configuration option; the built-in default is/usr/sbin/sendmail
or/usr/lib/sendmail
if such program is available, orlocalhost
otherwise. - --smtp-server-port=<port>
-
Specifies a port different from the default port (SMTP servers typically listen to smtp port 25, but may also listen to submission port 587, or the common SSL smtp port 465); symbolic port names (e.g. "submission" instead of 587) are also accepted. The port can also be set with the sendemail.smtpserverport configuration variable.
- --smtp-server-option=<option>
-
If set, specifies the outgoing SMTP server option to use. Default value can be specified by the sendemail.smtpserveroption configuration option.
The --smtp-server-option option must be repeated for each option you want to pass to the server. Likewise, different lines in the configuration files must be used for each option.
- --smtp-ssl
-
Legacy alias for --smtp-encryption ssl.
- --smtp-user=<user>
-
Username for SMTP-AUTH. Default is the value of sendemail.smtpuser; if a username is not specified (with --smtp-user or sendemail.smtpuser), then authentication is not attempted.
- --smtp-debug=0|1
-
Enable (1) or disable (0) debug output. If enabled, SMTP commands and replies will be printed. Useful to debug TLS connection and authentication problems.
Automating
- --to-cmd=<command>
-
Specify a command to execute once per patch file which should generate patch file specific "To:" entries. Output of this command must be single email address per line. Default is the value of sendemail.tocmd configuration value.
- --cc-cmd=<command>
-
Specify a command to execute once per patch file which should generate patch file specific "Cc:" entries. Output of this command must be single email address per line. Default is the value of sendemail.cccmd configuration value.
- --[no-]chain-reply-to
-
If this is set, each email will be sent as a reply to the previous email sent. If disabled with "--no-chain-reply-to", all emails after the first will be sent as replies to the first email sent. When using this, it is recommended that the first file given be an overview of the entire patch series. Disabled by default, but the sendemail.chainreplyto configuration variable can be used to enable it.
- --identity=<identity>
-
A configuration identity. When given, causes values in the sendemail.<identity> subsection to take precedence over values in the sendemail section. The default identity is the value of sendemail.identity.
- --[no-]signed-off-by-cc
-
If this is set, add emails found in Signed-off-by: or Cc: lines to the cc list. Default is the value of sendemail.signedoffbycc configuration value; if that is unspecified, default to --signed-off-by-cc.
- --suppress-cc=<category>
-
Specify an additional category of recipients to suppress the auto-cc of:
-
author will avoid including the patch author
-
self will avoid including the sender
-
cc will avoid including anyone mentioned in Cc lines in the patch header except for self (use self for that).
-
bodycc will avoid including anyone mentioned in Cc lines in the patch body (commit message) except for self (use self for that).
-
sob will avoid including anyone mentioned in Signed-off-by lines except for self (use self for that).
-
cccmd will avoid running the --cc-cmd.
-
body is equivalent to sob + bodycc
-
all will suppress all auto cc values.
Default is the value of sendemail.suppresscc configuration value; if that is unspecified, default to self if --suppress-from is specified, as well as body if --no-signed-off-cc is specified.
-
- --[no-]suppress-from
-
If this is set, do not add the From: address to the cc: list. Default is the value of sendemail.suppressfrom configuration value; if that is unspecified, default to --no-suppress-from.
- --[no-]thread
-
If this is set, the In-Reply-To and References headers will be added to each email sent. Whether each mail refers to the previous email (
deep
threading per git format-patch wording) or to the first email (shallow
threading) is governed by "--[no-]chain-reply-to".If disabled with "--no-thread", those headers will not be added (unless specified with --in-reply-to). Default is the value of the sendemail.thread configuration value; if that is unspecified, default to --thread.
It is up to the user to ensure that no In-Reply-To header already exists when git send-email is asked to add it (especially note that git format-patch can be configured to do the threading itself). Failure to do so may not produce the expected result in the recipient’s MUA.
Administering
- --confirm=<mode>
-
Confirm just before sending:
-
always will always confirm before sending
-
never will never confirm before sending
-
cc will confirm before sending when send-email has automatically added addresses from the patch to the Cc list
-
compose will confirm before sending the first message when using --compose.
-
auto is equivalent to cc + compose
Default is the value of sendemail.confirm configuration value; if that is unspecified, default to auto unless any of the suppress options have been specified, in which case default to compose.
-
- --dry-run
-
Do everything except actually send the emails.
- --[no-]format-patch
-
When an argument may be understood either as a reference or as a file name, choose to understand it as a format-patch argument (--format-patch) or as a file name (--no-format-patch). By default, when such a conflict occurs, git send-email will fail.
- --quiet
-
Make git-send-email less verbose. One line per email should be all that is output.
- --[no-]validate
-
Perform sanity checks on patches. Currently, validation means the following:
-
Warn of patches that contain lines longer than 998 characters; this is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
Default is the value of sendemail.validate; if this is not set, default to --validate.
-
- --force
-
Send emails even if safety checks would prevent it.
CONFIGURATION
- sendemail.aliasesfile
-
To avoid typing long email addresses, point this to one or more email aliases files. You must also supply sendemail.aliasfiletype.
- sendemail.aliasfiletype
-
Format of the file(s) specified in sendemail.aliasesfile. Must be one of mutt, mailrc, pine, elm, or gnus.
- sendemail.multiedit
-
If true (default), a single editor instance will be spawned to edit files you have to edit (patches when --annotate is used, and the summary when --compose is used). If false, files will be edited one after the other, spawning a new editor each time.
- sendemail.confirm
-
Sets the default for whether to confirm before sending. Must be one of always, never, cc, compose, or auto. See --confirm in the previous section for the meaning of these values.
EXAMPLE
Use gmail as the smtp server
To use git send-email to send your patches through the GMail SMTP server, edit ~/.gitconfig to specify your account settings:
[sendemail]
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpuser =<EMAIL_ADDRESS>smtpserverport = 587
Once your commits are ready to be sent to the mailing list, run the following commands:
$ git format-patch --cover-letter -M origin/master -o outgoing/
$ edit outgoing/0000-*
$ git send-email outgoing/*
Note: the following perl modules are required Net::SMTP::SSL, MIME::Base64 and Authen::SASL
SEE ALSO
git-format-patch(1), git-imap-send(1), mbox(5)
GIT
Part of the git(1) suite


Preparation time
less than 30 mins
Cooking time
30 mins to 1 hour
Serves
Serves 4
This simple, hearty, meat-free shepherd’s pie is packed full of healthy vegetables and lentils. Omit the Worcestershire sauce and Parmesan to make it a hearty vegetarian dinner.
This meal provides 416 kcal, 17g protein, 68g carbohydrate (of which 19g sugars), 6g fat (of which 2.5g saturates), 15g fibre and 1.5g salt per portion.
For the filling, heat the oil in a frying pan over a medium heat. Add the leeks and fry for 4-5 minutes, or until beginning to soften.
Add the carrots, mushrooms and garlic and continue to cook, stirring regularly, for 4-5 minutes.
Add the sage, thyme, tinned lentils, tinned tomatoes, stock and red wine and stir together until well combined. Bring the mixture to the boil, then reduce the heat until it is simmering and continue to simmer for 18-20 minutes while you make the topping.
Preheat the oven to 200C/180 Fan/Gas 6.
For the topping, bring a large saucepan of water to the boil (there’s no need to add salt). Add the sweet potato and potato and boil for 10-12 minutes. Add the cauliflower and boil for a further 8-10 minutes, or until tender.
Drain the vegetables well and return them to the pan. Add the butter, season well with salt and freshly ground black pepper, then mash until smooth. Set aside and keep warm.
Stir the Worcestershire sauce, soy sauce, chilli flakes (if using) and sugar (if using) into the filling mixture, which should have thickened during cooking. Continue to simmer for a further 1-2 minutes, adding a little water if the mixture is too dry (simmer for longer if the mixture is too watery). Season, to taste, with salt and freshly ground black pepper.
Transfer the filling mixture to an ovenproof baking dish, then spoon over the topping and spread into an even layer. If you like a crispy topping, create peaks in the mash using a fork. Sprinkle over the parmesan, if using.
Bake the shepherd’s pie in the oven for 18-20 minutes, or until the topping is golden-brown and the filling is bubbling.


You might think, ‘wait a second that doesn’t make any sense, why would anyone cause a loss, while they gain absolutely nothing in return’. I wouldn’t blame you, that’s what I originally thought. But think of the times somebody stood in your way when you were trying to be productive, whilst they didn’t gain from standing in your way.  That’s why they’re so dangerous.
Of course, there are a few distinctions to be made.  Again, Cipolla offers us 4 main categories in which humans fall.
As you can see above, you can categorize people based on their incentives in a certain situation. So, using the graph (fig. 1) we can categorize someone based on their motivations and the way they act:
- Stupid people: counterproductive, they lose something while the other party also loses something
- Helpless people: naive, they lose something while the other party gains something
- Intelligent people: contributors, they gain something while making sure the other party gains something as well
- Bandits: thieves, they gain something while the other party loses something
Here are some practical examples:
It’s important to realize that stupid people aren’t concentrated in one social category.  Just because somebody has a prize or a high function associated to their name doesn’t make them intelligent.  Not only they are stupid, but the whole system is ridiculous for rewarding these types of people.
It’s almost as if modern western society promotes status seeking, not erudition seeking.
 If they do something intelligent, they normally do it by mistake. So, if they are consistent they should be easy to avoid, once we’ve defined them. They should never, and I mean never be making decisions for a whole society.
  Actions, not words. The entrepreneur, not the rent-seeker (although some might be bandits, a lot of them are very stupid). It’s important to make sure that when we take a certain action, we can help others as well. That we are intelligent in that sense.
 Be one.


fQR Weave first real-life integration: ICTD
By today, fQR Weave - the arweave based app - have reached an agreement with ICTD, an academic center in Lebanon. With this collaboration, ICTD is going to be the first academic center in Lebanon, but even in the middle-east using blockchain technology in certificate's authentication.
What is ICTD ?
According to ICTD (International Center For Training & Developments) website:
"We are a team of academics and technicians specializing in consulting, training and quality management. We have seen an urgent need for training and development programs that will enhance the quality of training and education in various disciplines, by ensuring international standards of professionalism and reference"
ICTD Statistics:
461 Exams
6784 Students
164 Courses
153 Trainers
How ICTD Will Use fQR Weave ?
ICTD will use fQR Weave service to authenticate their students certificates on arweave blockchain (permaweb). With this integration, each certificate will have a fQR on it containing the following metadata:
Student's name
Student's Birthday
Course Name
Course Price (tariff)
Certificate Issue Date
As planned before, we have created a custom "fQR Generator" instance for ICTD, to generate their own pre-decided data-type and informations. And for sure, only ICTD verified address is able to generate fQRs which are scanned and decrypted by fQR Reader.
How Can ICTD Take fQR Weave to a higher level ?
Beside the integration of fQRs in the ICTD intern-area, this academic center - ICTD - leads, organise, and sponsor the National Robotics Competition (NRC) in Lebanon, side by side with the lebanese ministry of education. ICTD is responsible to issue and distribute the participants/winners certificates, which will have a fQR on it!


2017-18 Hydro Dynamics
2016-17 Animal Allies
2014-15 World Class
Not the Droids You are Looking For is a youth
robotics team from Pittsburgh, PA, USA. We participate in
robotics-related activities all year round. We have have won a Champion's (First, Second or Third) and Robot Performance Award at State-Level every year we have competed for seven years. We have been to world-level tournaments five times. At World-Level, we have won Innovative Solution (First), Robot Performance (Second), Programming (First), Coach Award, and been the Champion's team twice. We are the World Champion team of the 2017/18 Hydro Dymanics season. There are more than 35,000 teams globally that compete in FIRST LEGO League annually. The top 108 are invited to World Festival. One team is given the Champion's Award.
We help and
collaborate with FIRST teams as well as LEGO MINDSTORMS
enthusiasts locally and globally. Our primary goal is to encourage
other kids to learn robotics and programming, and share our love
for FIRST LEGO League. We have run workshops, demos and classes in many states for FLL Teams, libraries, museums, and schools. We founded EV3Lessons.com in 2014 and have more than 250,000 users in 175 countries. We organize the annual FIRST LEGO League kickoff for our region.
State: 3rd Place Champion's &
1st Place Robot Game
No Post-Season Invitation
State: 2nd Place Champion's &
2nd Place Robot Game
No Post-Season Invitation
State: 1st Place Champion's &
1st Place Robot Game.
International Open (Toronto): 1st Place Innovative Solution.
State: 2nd Place Champion's &
1st Place Robot Game.
Razorback Open (Arkansas): 1st Place Champion's &
2nd Place Robot Game.
State: 1st Place Champion's &
1st Place Robot Game.
World Festival (St.Louis): 1st Place Programming, Robot Game Playoffs
Global Innovation Award - Top 20 of 29,000
Coached Animatronics.
State: 1st Place Champion's &
1st Place Robot Game.
State: 1st Place Champion's &
1st Place Robot Game.


Preparation time
less than 30 mins
Cooking time
10 to 30 mins
Serves
Serves 1
Dietary
Preheat the oven to 200C/400F/Gas 6.
For the crumble topping, place the flour and butter into a food processor and pulse until the mixture resembles breadcrumbs. Stir in the crushed nuts and sugar.
For the filling, heat the sliced peach, red wine and sugar in a pan and simmer for 4-5 minutes, until the liquid is slightly reduced.
Pour the peach mixture into an ovenproof dish and top with the crumble mixture.
Bake in the oven for 8-12 minutes, or until the crumble is toasted and golden-brown.
For the lime yoghurt, place the yoghurt in a bowl and stir in the lime juice.
Serve the crumble warm in the dish with a dollop of lime yoghurt.


Doge Social Network
Home
Profile
Friends
Friends of Doge
SuchFriend
best friend
Many Friends
unknown
wow
yeah, right