aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
| * Add some docs to `BanOptions`acdenisSK2017-10-301-0/+1
| |
| * Fix shard shutdown via ContextZeyla Hellyer2017-10-294-8/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the shard shutdown via the Context. This works by setting a "shutdown" field on the Shard struct as being true, indicating that the Shard has shutdown. The Shard Runner detects this and requests a shutdown from the Shard Manager. The ideal solution here would be to add a "Shutdown" variant to serenity::gateway::ConnectionStage, but that would be a breaking change, so we instead need to opt for adding a new struct to gateway::Shard. The Shard Manager has also been updated to only attempt the shutdown of a shard if it doesn't already know for certain that it shut itself down, which avoids an error logged saying that there was an error sending a shutdown message to its Shard Runner. When all shards have been shutdown (for most bots, this will only be one), the Shard Manager will end and the Client will stop its operations, returning thread control to the user.
| * Fix #206 (#207)Uninteresting Account2017-10-292-11/+28
| |
| * Fall back to `str::parse` if `parse_username` failsacdenisSK2017-10-241-3/+4
| |
* | Fix Help-Commands to list all eligible commands in DMs. (#212)Lakelezz2017-11-041-1/+1
| |
* | Fix Client's framework setZeyla Hellyer2017-11-031-2/+2
| | | | | | | | | | | | | | 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.
* | `deserialize_i32` -> `deserialize_u8`acdenisSK2017-11-031-1/+1
| |
* | Redo client internals + gatewayZeyla Hellyer2017-11-0314-881/+1717
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Make the Client return a ResultZeyla Hellyer2017-11-0318-67/+126
| | | | | | | | | | | | | | | | 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.
* | Make `Command::aliases` publicacdenisSK2017-11-031-1/+2
| |
* | Fix framework Args testsZeyla Hellyer2017-11-011-71/+71
| | | | | | | | | | The tests were left untouched after a breaking change, resulting in them failing.
* | Fix audit logs a bitacdenisSK2017-11-014-42/+93
| |
* | Add a fallback to `RoleId::from_str` as wellacdenisSK2017-10-241-7/+8
| |
* | Remove unwrapsacdenisSK2017-10-242-2/+2
| |
* | Merge v0.4.2acdenisSK2017-10-2414-35/+409
|\ \
| * | Fall back to `str::parse` if `parse_username` failsacdenisSK2017-10-241-3/+4
| |/
| * Fix User::has_roleZeyla Hellyer2017-10-241-1/+5
| | | | | | | | | | | | | | | | | | Fix the return value of the function by properly checking whether the user has the role in the given guild. The function made the erraneous mistake of simply checking if the given guild had the role by Id, not whether the _member in the given guild_ had the role by Id.
| * Add a debug impl for `DispatchError`acdenisSK2017-10-231-0/+25
| | | | | | | | | | | | Why this was hand-made instead of derived is because of `CheckFailed`'s content, which is mostly `Command` not also deriving `Debug`; except that even `Command` has a trouble maker that would force us to do this hand-made anyway, `checks`. Fixes #204
| * Properly update emojis, fix shard retries, fix csLakelezz2017-10-233-6/+22
| | | | | | | | | | | | | | * If a guild's emojis are being altered, Serenity will straight up use the new `HashMap` instead of just extending. If `connect()` returns an `Err`, it will retry connecting. Cleaned up `help_command.rs`.
| * Add "zero-copy" parsingacdenisSK2017-10-212-1/+83
| |
| * Fix clippy warningsMei Boudreau2017-10-191-17/+14
| |
| * Fix shard connectionZeyla Hellyer2017-10-191-29/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes shard connections by removing the Default implementation for Shards. This was because when instantiating a Shard, `..Default::default()` syntax was used, which calls the `Default` implementation of the struct and moves the necessary values over to the overlying instantiation. When using `..Default::default()` syntax, all values in the Default implementation are instantiated, even ones that could be deemed unnecessary. For example, in the following sample code: ```rust struct Foo { x: bool, y: bool, } impl Default for Foo { fn default() -> Self { Self { x: true, y: true, } } } // ... let foo = Foo { x: false, ..Default::default() }; ``` `Foo::x` will still be instantiated in the Default implementation despite a value being set in the user's instantiation of Foo. This causes WebSocket client instantiation to be invalid in the Default instantiation, because the WebSocket instantiated has no base URL, causing an error to be returned. This commit resolves this issue by simply not having a Default implementation - due to the fact that a default implementation will never be valid and successful - and instead set all values in `Shard::new`. Notes: This issue surfaced with commit fcc4e2ce2e523248ed33c9f4853d3485cbc9b6e6 (PR #195). Closes #203.
| * Deprecate some text-only Channel methodsZeyla Hellyer2017-10-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some methods on `model::Channel` are only for text channels. Methods on Channel should be applicable to all channel types. Deprecates the following methods on `model::Channel`: - `create_reaction` - `delete_message` - `delete_reaction` - `edit_message` - `message` - `messages` - `reaction_users` - `say` - `send_files` - `send_message` - `unpin`
| * Re-export parking_lot::{Arc, Mutex} from preludeZeyla Hellyer2017-10-191-0/+1
| | | | | | | | | | | | These two types are used in public APIs, and so by re-exporting them it makes it easier for the user to use them without needing to depend on `parking_lot` themselves.
| * Implement changing a role's position (#201)Ken Swenson2017-10-193-0/+59
| |
| * Add a missing breakacdenisSK2017-10-181-0/+1
| |
| * `assert` -> `assert_eq`acdenisSK2017-10-181-2/+2
| |
| * Add `PartialEq` impls and doc tests to `Args`acdenisSK2017-10-181-1/+154
| |
| * Use the underlaying integer value of a `ChannelType` variantacdenisSK2017-10-171-1/+1
| |
| * defer to `delete_message` if there's just one message to deleteacdenisSK2017-10-162-4/+8
| |
| * Use update syntax for Shard (#195)Edward Yang2017-10-161-22/+29
| |
| * Hash and do equality on just the id for `User`acdenisSK2017-10-151-1/+17
| |
* | Remove `on_` prefix to EventHandler tymethodsZeyla Hellyer2017-10-2214-131/+131
| | | | | | | | | | It was voted that the `on_` prefix is unnecessary, so these have been dropped.
* | Remove setting of the afk field in shardsZeyla Hellyer2017-10-192-27/+16
| |
* | Change CreateEmbed::field{,s} to not take buildersZeyla Hellyer2017-10-185-111/+57
| | | | | | | | | | | | | | | | | | Change the `field` and `fields` methods on `builder::CreateEmbed` to not accept a `CreateEmbedField` builder. The embed field builder realistically only had (and most likely, only will) have one optional argument, so the parameters may as well be on `CreateEmbed::field`.
* | Slightly improve performance of buildersZeyla Hellyer2017-10-1822-243/+229
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Builders would keep a `serde_json::Map<String, Value>`, which would require re-creating owned strings for the same parameter multiple times in some cases, depending on builder defaults and keying strategies. This commit uses a `std::collections::HashMap<&'static str, Value>` internally, and moves over values to a `serde_json::Map<String, Value>` when it comes time to sending them to the appropriate `http` module function. This saves the number of heap-allocated string creations on most builders, with specific performance increase on `builder::CreateMessage` and `builder::CreateEmbed` & co.
* | Fix some compilation feature targets, fix lintsZeyla Hellyer2017-10-174-3/+8
| |
* | Change `features` fields to be a Vec<String>Zeyla Hellyer2017-10-143-30/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When Discord adds new features, the Feature enum will not be able to serialize the new values until updated, causing the entire Guild deserialization to fail. Due to the fact that these features can be added at any time, the `features` vector on Guild and PartialGuild have been changed to be a `Vec<String>`. Upgrade path: Instead of matching on variants of Feature like so: ```rust use serenity::model::Feature; for feature in guild.features { if feature == Feature::VipRegions { // do work with this info } } ``` Instead opt to check the string name of the feature: ```rust for feature in guild.features { if feature == "VIP_REGIONS" { // do work with this info } } ```
* | Update to account for changes made in 0.4.1acdenisSK2017-10-1422-194/+434
|\|
| * Feature-flag extern crates behind their nameZeyla Hellyer2017-10-141-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An issue with modifying what features enable compilation of what crates was possible due to crates being feature-flagged behind a module name instead of their own name. Instead of writing cfg features for crates as: ```rust \#[cfg(feature = "utils")] extern crate base64; ``` Write the feature name as its own name: ```rust \#[cfg(feature = "base64")] extern crate base64; ``` This way, crates can simply have compilation enabled in the project's features section in the `Cargo.toml` file.
| * Add try_opt macro for substituteMei Boudreau2017-10-123-12/+13
| |
| * Optimize Member::rolesMei Boudreau2017-10-121-21/+11
| |
| * Help-features display `Aliases` and list information for `Aliases`. (#190)Lakelezz2017-10-121-60/+80
| |
| * Fix clippy lintsZeyla Hellyer2017-10-1120-99/+102
| |
| * Make `has_correct_permissions`, `has_correct_roles` and ↵Lakelezz2017-10-102-3/+3
| | | | | | | | `has_all_requirements` public. (#188)
| * Add an iterator for `Args`acdenisSK2017-10-101-9/+33
| |
| * Add some docs to `Args`acdenisSK2017-10-101-0/+4
| |
| * Variety of methods to search for `Member`. (#187)Lakelezz2017-10-101-12/+218
| |
| * Reset shard heartbeat state on resumeZeyla Hellyer2017-10-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Make the client threadpool user-customizableZeyla Hellyer2017-10-094-15/+38
| | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-22 01:20:07 +0000