| Age | Commit message (Collapse) | Author |
|---|
|
We do the actual fork as the last step, after redirecting the
standard I/O streams. This also ensures that no log messages
are shown on console _after_ forking.
|
|
We nil the internal variable, but we should not close the logger itself,
since this leads to STDERR being closed and the interpreter reopening it
for its own needs, or something like that, which ultimately leads to
the interpreter's warning appearing in console (probably due to ruby
itself reopening stderr to be able to output the messages).
If we simply nil the variable, the interpreter is content with sending
us the messages per our shenanigangs, and everything works just as
expected.
|
|
IO.write() takes an arbitrary number of argumens, that are converted to string
and joined on write. We should behave the same way.
Moreover, the returned value is the number of bytes, and this is bytesize
in modern Ruby.
|
|
|
|
Overriding (as we should do) the standard error write method when
daemonizing introduces a recursion in the logger, due to the
persistent presence of the console logger.
The solution is obviously to stop logging on console
after daemonization.
|
|
In 96d13521d the STDOUT/STDERR write overrides were replaced
by overrides to $stdout, but the second should have been to $stderr
(obviously).
|
|
Logging was broken when daemonizing, due to the logger thread being dead
after the fork. This can be solved by restarting the thread, if necessary
when setting the log file (which we conveniently do right after the fork).
|
|
|
|
|
|
|
|
|
|
While loading a plugin in the manager using #load_botmodule_file this
will remember the directory of the file that is being loaded in
@next_plugin_path. In the plugin/BotModule initialization we set the
path in plugin_path of the plugin.
This was the only solution I could find to get this information in the
plugin. It is useful because this allows the plugin to know in which
directory it is located, it can then easily access data files stored
alongside the plugin.
Some built-in plugins (see #42) use the data/rbot/templates to copy
data files on bot load (see #repopulate_botclass_directory) into the
profile directory (~/.rbot/).
|
|
also related to #41 and #6
|
|
I never saw a plugin use this feature besides wof, IRC user objects should not hold
persistent data like this, I rather have the IRC interface clean. The
general idea is a good though, especially easier per-channel, per-user
data persistence.
|
|
|
|
This is intended to make testing/mocking of the http client easier.
|
|
|
|
|
|
|
|
|
|
This modifies the karma/points plugin to ignore increment/
decrement suffixes. `--SOMETHING` is more trouble than its worth,
people will write --NAME as a signature, or paste a command
line argument, e.g. `ls --sort time` which causes issues.
I also added tests for the points plugin, the plan is
to make the plugin testing easier more "rubionic"
|
|
|
|
|
|
this removes gcount and gtime from the search plugin,
google no longer provides this information easily
|
|
|
|
This moves the logger management thread/queue to a seperate singleton.
It removes the explicit stopping/restarting of the logging thread since
the thread should behave like a daemon thread anyway.
Still needs to be tested to work in daemonize.
|
|
|
|
This makes it so the -d debug flag on the rbot
command line will always log to STDOUT, previously
it would just force the log level.
|
|
|
|
Rename and improve karma plugin
|
|
previously getimpl returned eigenclasses aswell which
always was an issue but i guess a minor change in ruby
triggered this.
|
|
Prior to this commit, rbot used a "karma" system for keeping
track of user points. This phrasing, while widespread, is
unnecessarily appropriationist.
This commit renames the plugin to a more neutral "points"
system, accomplishing exactly the same goal without using
culturally problematic language.
For more background please read: http://bit.ly/1MfLmce
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
