| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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);
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Session invalidations include whether the session may be resumable.
Previously, this was not parsed by serenity. This data is now contained
in `GatewayEvent::InvalidateSession` as a boolean, which constitutes a
breaking change for users that manually handle gateway events.
Upgrade path:
Instead of pattern matching on simply the variant like so:
```rust
use serenity::model::event::GatewayEvent;
match gateway_event {
GatewayEvent::InvalidateSession => {
// work here
},
// other matching arms here
_ => {},
}
```
Instead pattern match it as a single field tuple-struct:
```rust
use serenity::model::event::GatewayEvent;
match gateway_event {
GatewayEvent::InvalidateSession(resumable) => {
// work here
},
// other matching arms here
_ => {},
}
```
|
| | |
| |
| |
| |
| | |
This change is made due to this change in documentation:
<https://github.com/discordapp/discord-api-docs/commit/32d06c360867cead6aa785ff10c437fdb2743bd6?short_path=5f625d6#diff-5f625d6c4303e22c3d6af4c8d6df28fe>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a resume is received, the heartbeat state would not be reset.
This state includes:
- whether the last heartbeat was acknowledged
- when the last heartbeat was sent
- when the last heartbeat acknowledgement was received
This resulted in the bot re-IDENTIFYing after a Resumed event was
received. To fix this issue, reset them when a Resumed event is
received.
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
A threadpool will help with giving event dispatches a threaded behaviour
while still allowing the library the ability to perform other actions,
such as receiving new events and heartbeating over the websocket client.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
`members_containing` and `members_starting_with` (#184)
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| | |
Fixes #174
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Makes the compiliation time just a bit worse
|
| | |
| |
| |
| | |
Fixes #168
|
| | | |
|
| | |
| |
| |
| | |
Since it's a fairly simple enum. Also changed `is_connecting` to be more idiomatic.
|
| | |
| |
| |
| |
| | |
`ShardRunner::recv_events` actually only receives one event, so
de-pluralize it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Improve shard logic by more cleanly differentiating when resuming, as
well as actually fixing resume logic.
For shard runners, better handling of dead clients is added, as well as
more use of the shard manager, in that the runner will now more
liberally request a restart when required (instead of sitting and doing
nothing infinitely).
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
The output in a tag may result in "username#304" instead of the correct
"username#0304".
|
| |
|
|
|
|
| |
Due to the new ShardManager, `Client::shards` would never fill, so
instead clone the `shard_runners` instance from the `ShardManager` to
the `Client`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Kind of a bad decision but due to the compiler being a meany with impl conflicts for `From<&str>` and `From<String>`, it needs to be done. Plus it removes the useless custom struct.
|
| | |
|
| | |
|
| |
|
|
| |
The shard manager will queue up shards for booting.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bitflags changed its macro codegen from creating constants to associated
constants on structs.
Upgrade path:
Update code from:
```rust
use serenity::model::permissions::{ADD_REACTIONS, MANAGE_MESSAGES};
foo(vec![ADD_REACTIONS, MANAGE_MESSAGES]);
```
to:
```rust
use serenity::model::Permissions;
foo(vec![Permissions::ADD_REACTIONS, Permissions::MANAGE_MESSAGES]);
```
|