| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Fixes links to the repo from `https://github.com/zeyla/serenity` to
`https://github.com/serenity-rs/serenity`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 062ea86d5b0d9932207636d4a44a5357b079e79a.
This change had the unintended side-effect of making tests with the
Client impossible without hitting Discord's REST API for every test
(even worse, while unauthorized).
Knowing the user's ID on creation isn't _too_ important, and what was
being done with that knowledge can be deferred to connection start.
|
| |
|
|
|
|
| |
Instead of creating different `new` functions for every bridged feature
combination, accept a struct of options. Structs can have conditional
fields, unlike functions which can not have conditional arguments.
|
| |
|
|
|
| |
Add the user ID to the client. This can be used when initializing the
framework on connection start, as well as the future voice manager.
|
| |
|
|
|
| |
The framework no longer needs the `is_bot` boolean state, since serenity
now only supports bot users.
|
| |
|
|
|
| |
Add an event in the EventHandler to be called when a shard updates its
Connection Stage.
|
| |
|
|
|
| |
Trims the token given as an argument in Client::new, which will strip
away whitespace that might occur due to including the token from a file.
|
| |
|
|
|
| |
Fix clippy lints and subsequently accept references for more function
parameters.
|
| |
|
|
|
|
|
|
|
|
| |
Calling `ShardManager::shutdown_all` will now send a message to the
shard queuer and shard monitor to shutdown. This will now cause
`Client::start_connection` to exit.
Additionally, `Client::start_connection` and related functions that call
this (e.g. `Client::start_autosharded`) now return `Ok(())` on clean
exits.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the client's close handle. This was eclipsed by the
`client::bridge::gateway::ShardManager`, which is a public interface
giving full control over connected shards owned by the instance of the
client (as opposed to the purpose of the handle which was a simple
"shutdown" signal).
Additionally, more documentation has been added to
`Client::shard_manager`, now including a sample scenario of how to
shutdown the bot after some amount of time has passed.
Upgrade path:
Refer to the documentation for `Client::shard_manager` on a sample
scenario on how to switch from the close handle to the ShardManager.
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes the following doctests for the changes introduced in commit
[f10b9d7]:
- client::Client::with_framework
- framework::standard::configuration::Configuration::disabled_commands
- framework::standard::configuration::Configuration::dynamic_prefix
[f10b9d7]: f10b9d77f0b94864fa20688e3c99de6cec7ca6f9
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| | |
The names of environment variable tokens in the examples differed, so
this makes them all use the same name.
|
| | |
| |
| |
| |
| |
| |
| | |
The Client would create two Arc's containing unique instances of a
user's given Framework, one given to the ShardManager and one kept on
the Client. This would result in the user's Framework on the Client
being set, but the other left untouched and permanently staying empty.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit is a rewrite of the client module's internals and the
gateway.
The main benefit of this is that there is either 0 or 1 lock retrievals
per event received, and the ability to utilize the ShardManager both
internally and in userland code has been improved.
The primary rework is in the `serenity::client` module, which now
includes a few more structures, some changes to existing ones, and more
functionality (such as to the `ShardManager`).
The two notable additions to the client-gateway bridge are the
`ShardMessenger` and `ShardManagerMonitor`.
The `ShardMessenger` is a simple-to-use interface for users to use to
interact with shards. The user is given one of these in the
`serenity::client::Context` in dispatches to the
`serenity::client::EventHandler`. This can be used for updating the
presence of a shard, sending a guild chunk message, or sending a user's
defined WebSocket message.
The `ShardManagerMonitor` is a loop run in its own thread, potentially
the main thread, that is responsible for receiving messages over an mpsc
channel on what to do with shards via the `ShardManager`. For example,
it will receive a message to shutdown a single shard, restart a single
shard, or shutdown the entire thing.
Users, in most applications, will not interact with the
`ShardManagerMonitor`. Users using the `serenity::client::Client`
interact with only the `ShardMessenger`.
The `ShardManager` is now usable by the user and is available to them,
and contains public functions for shutdowns, initializations, restarts,
and complete shutdowns of shards. It contains utility functions like
determining whether the `ShardManager` is responsible for a shard of a
given ID and the IDs of shards currently active (having an associated
`ShardRunner`). It can be found on
`serenity::client::Client::shard_manager`.
Speaking of the `ShardRunner`, it no longer owns a clone of an Arc to
its assigned `serenity::gateway::Shard`. It now completely owns the
Shard. This means that in order to open the shard, a `ShardRunner` no
longer has to repeatedly retrieve a lock to it. This reduces the number
of lock retrievals per event dispatching cycle from 3 or 4 depending on
event type to 0 or 1 depending on whether it's a message create _and_ if
the framework is in use. To interact with the Shard, one must now go
through the previously mentioned `ShardMessenger`, which the
`ShardRunner` will check for messages from on a loop.
`serenity::client::Context` is now slightly different. Instead of the
`shard` field being `Arc<Mutex<Shard>>`, it is an instance of a
`ShardMessenger`. The interface is the same (minus losing some
Shard-specific methods like `latency`), and `Context`'s shortcuts still
exist (like `Context::online` or `Context::set_game`). It now
additionally includes a `Context::shard_id` field which is a u64
containing the ID of the shard that the event was dispatched from.
`serenity::client::Client` has one changed field name, one field that is
now public, and a new field. `Client::shard_runners` is now
`Client::shard_manager` of type `Arc<Mutex<ShardManager>>`. The
`Client::token` field is now public. This can, for example, be mutated
on token resets if you know what you're doing. `Client::ws_uri` is new
and contains the URI for shards to use when connecting to the gateway.
Otherwise, the Client's usage is unchanged.
`serenity::gateway::Shard` has a couple of minor changes and many more
public methods and fields. The `autoreconnect`, `check_heartbeat`,
`handle_event`, `heartbeat`, `identify`, `initialize`, `reset`,
`resume`, `reconnect`, and `update_presence` methods are now public. The
`token` structfield is now public. There are new getters for various
structfields, such as `heartbeat_instants` and `last_heartbeat_ack`.
The breaking change on the `Shard` is that `Shard::handle_event` now
takes an event by reference and, instead of returning
`Result<Option<Event>>`, it now returns `Result<Option<ShardAction>>`.
`serenity::gateway::ShardAction` is a light enum determining an action
that someone _should_/_must_ perform on the shard, e.g. reconnecting or
identifying. This is determined by `Shard::handle_event`.
In total, there aren't too many breaking changes that most of userland
use cases has to deal with -- at most, changing some usage of `Context`.
Retrieving information like a Shard's latency is currently not possible
anymore but work will be done to make this functionality available
again.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The client now returns a Result in preparation of a future commit.
Upgrade path:
Handle the case of an error via pattern matching, or unwrap the Result.
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
In addition to making the threadpool used by client shards customizable
by the user, make only a single threadpool (as opposed to one per shard)
and share it across all shards.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Switch to the `parking_lot` crate's implementations of
`std::sync::Mutex` and `std::sync::RwLock`, which are more efficient.
A writeup on why `parking_lot` is more efficient can be read here:
<https://github.com/Amanieu/parking_lot>
Upgrade path:
Modify `mutex.lock().unwrap()` usage to `mutex.lock()` (not needing to
unwrap or handle a result), and
`rwlock.read().unwrap()`/`rwlock.write().unwrap()` usage to
`rwlock.read()` and `rwlock.write()`.
For example, modify:
```rust
use serenity::CACHE;
println!("{}", CACHE.read().unwrap().user.id);
```
to:
```rust
use serenity::CACHE;
println!("{}", CACHE.read().user.id);
```
|
| | |
| |
| |
| |
| |
| | |
In addition to making the threadpool used by client shards customizable
by the user, make only a single threadpool (as opposed to one per shard)
and share it across all shards.
|
| |/ |
|
| |
|
|
|
|
| |
Due to the new ShardManager, `Client::shards` would never fill, so
instead clone the `shard_runners` instance from the `ShardManager` to
the `Client`.
|
| | |
|
| |
|
|
| |
The shard manager will queue up shards for booting.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When spawning multiple shards (via an equal number of futures - one
per shard) joined on a core.run use, the very first future executed
would block forever due to a sync, blocking `monitor_shard` use. While
this defeats the purpose of tokio, this was meant to be a first step to
an async serenity implementation.
To "fix" this blocking call until a deeper async implementation is made,
spawn a new thread per tokio core (and thus per shard). This causes the
same expected behaviour, just with multiple threads like before.
|
| | |
|
| |
|
|
|
|
| |
Add a HashMap which contains the shards, keyed by the shard ID with the
value as the shard. This allows for manual interaction outside of event
handlers.
|
| | |
|
| |
|
|
| |
Also not quite sure if they goofed rustfmt or something, but its changes it did were a bit bizarre.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The framework is now moved in its entirity to the `framework` module,
with the `Framework` trait currently on its own and the builtin
implementation provided.
The builtin implementation has been renamed to "Standard".
Upgrade path:
Rename the `BuiltinFramework` import to `StandardFramework`. Instead of
importing builtin framework items from `serenity::framework`, import
them from `serenity::framework::standard`.
This is the beginning to #60. The root `framework` module (non-standard
implementation) will be built more by the time it's closed.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Removed action support from the builtin one as well, due to it adding some uneccassery complexity and it being only asked upon by one user
|
| | |
|
| | |
|