Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implements changes to allow developers more control about event handling #2854

Open
wants to merge 122 commits into
base: next
Choose a base branch
from

Conversation

TheCataliasTNT2k
Copy link

Adds Framework::dispatch_automatically
Makes client::dispatch::update_cache_with_event public, so it can be called manually by developers

@github-actions github-actions bot added framework Related to the `framework` and `framework::standard` modules and/or the `command_attr` crate client Related to the `client` module. labels Apr 28, 2024
TheCataliasTNT2k added a commit to RuDrocsid/poise that referenced this pull request Apr 28, 2024
TheCataliasTNT2k added a commit to RuDrocsid/poise that referenced this pull request Apr 28, 2024
TheCataliasTNT2k added a commit to RuDrocsid/poise that referenced this pull request Apr 28, 2024
Copy link
Member

@GnomedDev GnomedDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dislike update_cache_with_event becoming public, as it's quite internal. If you could make a nicer API for this that doesn't require making internal modules public, that would resolve this.

@TheCataliasTNT2k
Copy link
Author

TheCataliasTNT2k commented Apr 30, 2024

The only thing in this method I really care about, is to get the returned values.
I do not really want to copy this function to get the FullEvent objects to use them in my library. If this can be achieved in any other way (while not losing the cache functionality) I am happy.

@cheesycod
Copy link
Contributor

This would be useful for me as well

@GnomedDev GnomedDev force-pushed the next branch 3 times, most recently from 7ad183d to 52f2822 Compare May 14, 2024 20:34
@GnomedDev GnomedDev force-pushed the next branch 3 times, most recently from 8d52f25 to 68e5e62 Compare May 28, 2024 14:58
GnomedDev and others added 14 commits June 9, 2024 22:33
…erenity-rs#2646)

This avoids having to allocate to store fixed length (replaced with normal
array) or fixed capacity (replaced with `ArrayVec`) collections as vectors for
the purposes of putting them through the `Request` plumbing.

Slight behavioral change - before, setting `params` to `Some(vec![])`
would still append a question mark to the end of the url. Now, we check
if the params array `is_empty` instead of `is_some`, so the question
mark won't be appended if the params list is empty.

Co-authored-by: Michael Krasnitski <42564254+mkrasnitski@users.noreply.github.com>
These are unnecessary. Accepting `impl Into<Arc<T>>` allows passing either `T` or `Arc<T>`.
This trades a heap allocation for messages sent along with thread
creation for `Message`'s inline size dropping from 1176 bytes to 760
bytes,
…l models (serenity-rs#2656)

This shrinks type sizes by a lot; however, it makes the user experience slightly
different:

- `FixedString` must be converted to String with `.into()` or `.into_string()`
  before it can be pushed to, but dereferences to `&str` as is.
- `FixedArray` must be converted to `Vec` with `.into()` or `.into_vec()`
  before it can be pushed to, but dereferences to `&[T]` as is.

The crate of these types is currently a Git dependency, but this is fine for
the `next` branch. It needs some basic testing, which Serenity is perfect for,
before a release will be made to crates.io.
…enity-rs#2668)

This commit:

- switches from `u64` to `i64` in `CreateCommandOption::min_int_value` and
`CreateCommandOption::max_int_value` to accommodate negative integers in
Discord's integer range (between -2^53 and 2^53). Values outside this
range will cause Discord's API to return an error.
- switches from `i32` to `i64` in `CreateCommandOption::add_int_choice` and
`CreateCommandOption::add_int_choice_localized` to accommodate Discord's
complete integer range (between -2^53 and 2^53). Values outside this
range will cause Discord's API to return an error.
This cache was just duplicating information already present in `Guild::members`
and therefore should be removed.

This saves around 700 MBs for my bot (pre-`FixedString`).

This has to refactor `utils::content_safe` to always take a `Guild` instead
of`Cache`, but in practice it was mostly pulling from the guild cache anyway
and this means it is more likely to respect nicknames and other information,
while losing the ability to clean mentions from DMs, which do not matter.
`Embed::fields` previously had to stay as a `Vec` due to `CreateEmbed` wrapping
around it, but by implementing `Serialize` manually we can overwrite the
`Embed::fields` with a normal `Vec`, for a small performance hit on
serialization while saving some space for all stored `Embed`s.
Simply missed these when finding and replacing.
This uses the `bool_to_bitflags` macro to remove boolean (and optional boolean)
fields from structs and pack them into a bitflags invocation, so a struct with
many bools will only use one or two bytes, instead of a byte per bool as is.

This requires using getters and setters for the boolean fields, which changes
user experience and is hard to document, which is a significant downside, but
is such a nice change and will just become more and more efficient as time goes
on.
GnomedDev and others added 17 commits June 9, 2024 23:28
This has to be on the next branch as reqwest is exposed in a couple
places.
This announcement was missed (around August 2022) and probably the cause
of a lot of the disconnections.
The documentation was never updated after serenity-rs#2662 removed the user cache.
This field is documented as nullable but that isn't reflected in the
model. I also took the opportunity to replace the Option<Vec> with a
default Vec.
This was mistakenly removed in serenity-rs#2278 and wasn't caught because of the
wildcard pattern in the match.
Users should realistically be checking the permissions themselves, or
handling the HTTP error from Discord.

This removes any cases where permission checking inside the library is
broken because of Discord's changes or due to oversights.

This also changes the documentation on the prune functionality, this was
recently changed to also require `MANAGE_GUILDS` as well as
`KICK_MEMBERS`.
This isn't needed anymore because simd-json has been removed on `next`.
@TheCataliasTNT2k
Copy link
Author

TheCataliasTNT2k commented Jun 10, 2024

I can not really create a better API, because I need to update the cache.
Do you have any suggestions?
(I will resolve the conflicts when all changes are approved.)

I dislike update_cache_with_event becoming public, as it's quite internal. If you could make a nicer API for this that doesn't require making internal modules public, that would resolve this.

Already did the rebase (or rather just moved my commits to the new HEAD).

Makes client::dispatch::update_cache_with_event public, so it can be called manually by developers
@cheesycod
Copy link
Contributor

Any updates on this?

@TheCataliasTNT2k
Copy link
Author

I don't think so 🤷
I am just using a fork which has everything I need, which is rejected by the maintainers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client Related to the `client` module. framework Related to the `framework` and `framework::standard` modules and/or the `command_attr` crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.