Review logs that requires special treatment when calculating the memory states from review history

Reviews of the same card in the same day
FSRS doesn't accept interval < 1, so we need to filter out those review logs with the same date and only keep the first one.
Reviews in filtered deck when reschedule cards based on my answers in this deck is disabled.
These revlogs should be filtered out from review history.
These revlogs' review_kind is REVLOG_CRAM, so it's easy to filter out them.
Manual reset
There are two kinds of manual reset: Set Due Date and Forget. Their review_kind is REVLOG_RESCHED. But the fronter's ease (factor) is nonzero. The latter's ease (factor) is zero.
Set Due Date
These revlogs should be filtered out from review history, too. Because I think it's equal to CTRL+J (Reschedule repetition) in SuperMemo: https://supermemopedia.com/wiki/Ctrl%2BJ_vs._Ctrl%2BShift%2BR
Forget
We should remove the review logs in front of forget and forget itself. Then we need to treat the first review log after forget as the first learning, whose rating will be used to initialize the memory state.
Incomplete revlogs
Due to some legacies, The manual reset were not recorded in the old version of Anki/AnkiDroid. So we need to deal with this case via another way. Normally, the previous revlog of a REVLOG_LRN shouldn't be REVLOG_REV or REVLOG_RELRN. If so, we need to remove those revlogs. In a word, we should find out the the first REVLOG_LRN in the last successive REVLOG_LRNs
Besides, some users may use Transfer scheduling data from one card to another, which would generate more weird review history.

https://github.com/open-spaced-repetition/fsrs4anki/issues/136
https://github.com/open-spaced-repetition/fsrs4anki-helper/issues/49#issuecomment-1481246798
https://github.com/open-spaced-repetition/fsrs4anki-helper/issues/49#issuecomment-1481251371
https://github.com/open-spaced-repetition/fsrs4anki/issues/191#issuecomment-1500925132
https://github.com/open-spaced-repetition/fsrs4anki-helper/issues/56

We need to deal with it case by case. Another more convenient method is to skip these cards.
@user1823 and @Expertium, if I miss anything, please let me know.

I thought we were covering such cases in convert_to_fsrs_items() and the ported version in Anki. Is that not the case?

There are some difference between the filters in FSRS Optimizer (implemented in Pandas) and FSRS Helper (implemented in std lib).

Well, perhaps we should :-) If we have one function that deals with all of this, we'll know our inputs are safe to feed into any of our API.

Yeah. And it's tricky, because I'm not very familiar with the legacies of the system of revlogs. I will collect some cases for test.

But I don't know the structure of input from Anki. Could you give me an example?

Do you mean https://github.com/ankitects/anki/blob/3742fa9f0c3118de1c23bf27198975eea62e09bb/rslib/src/revlog/mod.rs#L36?

Yes. Is it possbile to output the review history of a card in Anki? I can write an add-on to print the review logs of a card, but it's a list of object in Python rather than Rust.

There's partial info available via card stats (assuming card id 1):
mw.col.backend.card_stats(1).revlog
To see the full Rust structure, try the above after running Anki with the following patch:
diff --git a/rslib/src/stats/card.rs b/rslib/src/stats/card.rs
index d058c2233..7884a02c9 100644
--- a/rslib/src/stats/card.rs
+++ b/rslib/src/stats/card.rs
@@ -94,6 +94,7 @@ fn average_and_total_secs_strings(revlog: &[RevlogEntry]) -> (f32, f32) {
 fn stats_revlog_entry(
     entry: &RevlogEntry,
 ) -> anki_proto::stats::card_stats_response::StatsRevlogEntry {
+    dbg!(entry);
     anki_proto::stats::card_stats_response::StatsRevlogEntry {
         time: entry.id.as_secs().0,
         review_kind: entry.review_kind.into(),

These exceptions might be better handled not in the fsrs-rs crate, but in the Anki crate, since they're Anki-specific. Anki's port of the conversion code is here: https://github.com/ankitects/anki/blob/3742fa9f0c3118de1c23bf27198975eea62e09bb/rslib/src/scheduler/fsrs/weights.rs#L98

I plan to write some temporary tests in fsrs-rs and remove them after you implement the conversion code in Anki.

That's fine if you find it easier, but it might be more efficient to add the tests directly to the anki crate if you're able to build it. Up to you though - either way works for me. :-)

https://github.com/open-spaced-repetition/fsrs-rs/blob/Test/deal-with-revlog-from-Anki/src/temporary_test.rs
You can refer to these tests.

Jarrett: There are some difference between the filters in FSRS Optimizer (implemented in Pandas) and FSRS Helper (implemented in std lib). I cannot guarantee that convert_to_fsrs_items() has handled all situations.
Damien: Well, perhaps we should :-) If we have one function that deals with all of this, we'll know our inputs are safe to feed into any of our API.

@dae, I think that there must be some differences between the optimizer and the re-scheduler. The reason:

The output of the optimizer affects the scheduling of ALL the cards. So, we should remove the revlogs that can corrupt the final weights.
The output of the re-scheduler only affects that particular card. So, we can make some clever approaches to ensure that most of the cards get rescheduled (and not skipped) and that too appropriately.

I made some comparisons of the special cases. Here is the result of my analysis.
Reviews of the same card on the same day
Should be dealt similarly in the rescheduler and the optimizer - keep only the first review and filter out the rest

Add-on code: https://github.com/open-spaced-repetition/fsrs4anki-helper/blob/a26bc62148f4c09db1c9dab508d8ea79413c0244/schedule/reschedule.py#L429-L430
Optimizer code (this repo): https://github.com/open-spaced-repetition/fsrs-rs/blob/531566c49a861d4d57e0a228a2dd3dec5616b93b/src/convertor_tests.rs#L84-L90

Reviews in filtered deck when reschedule cards based on my answers in this deck is disabled.
Should be dealt similarly in the rescheduler and the optimizer - Filter out these reviews
But, when reschedule cards based on my answers in this deck is enabled, these reviews should not be removed and treated as normal reviews.

Add-on code: https://github.com/open-spaced-repetition/fsrs4anki-helper/blob/4ddd4be62ed8478499e43bf2cecddf8a0dcb2c43/utils.py#L271-L274
Optimizer code (this repo): Couldn't find

Manual Scheduling
Should be dealt similarly in the rescheduler and the optimizer

Forget card:

Newer versions of Anki (manual revlog + Ease = 0): Remove all the reviews up to this rating

Add-on code: https://github.com/open-spaced-repetition/fsrs4anki-helper/blob/a26bc62148f4c09db1c9dab508d8ea79413c0244/schedule/reschedule.py#L403-L413
Optimizer code (this repo): Couldn't find specific code, but (partially) dealt with the following. Probably, specific code should be there to deal with cards "forgot" during a learning stage.

Older versions of Anki (no revlog, LEARN ratings seen after REVIEW/RELEARN ratings): Remove all the reviews before the last continuous group of LEARN ratings

Add-on code: https://github.com/open-spaced-repetition/fsrs4anki-helper/blob/a26bc62148f4c09db1c9dab508d8ea79413c0244/schedule/reschedule.py#L391-L401
Optimizer code (this repo): https://github.com/open-spaced-repetition/fsrs-rs/blob/531566c49a861d4d57e0a228a2dd3dec5616b93b/src/convertor_tests.rs#L54-L72
and https://github.com/open-spaced-repetition/fsrs-rs/blob/531566c49a861d4d57e0a228a2dd3dec5616b93b/src/convertor_tests.rs#L100-L116
I don't know the reason for this duplication.

Set Due Date: Filter out this MANUAL rating

Add-on code: https://github.com/open-spaced-repetition/fsrs4anki-helper/blob/a26bc62148f4c09db1c9dab508d8ea79413c0244/schedule/reschedule.py#L403-L413
Shouldn't this be review_kind instead of last_kind?
Optimizer code (this repo): Couldn't find

First review type is not LEARN / Incomplete review history
Dealt differently in reschedule & optimize.

Optimizer: Remove all such reviews
https://github.com/open-spaced-repetition/fsrs-rs/blob/531566c49a861d4d57e0a228a2dd3dec5616b93b/src/convertor_tests.rs#L74-L78

Rescheduler: Reschedule the cards which were rated Again or Reset (forget) at some point in the "known" review history but skip (don't reschedule) the rest
https://github.com/open-spaced-repetition/fsrs4anki-helper/blob/a26bc62148f4c09db1c9dab508d8ea79413c0244/schedule/reschedule.py#L382-L387
https://github.com/open-spaced-repetition/fsrs4anki-helper/blob/4ddd4be62ed8478499e43bf2cecddf8a0dcb2c43/utils.py#L296-L315
I think that the second condition could be removed if this code is moved further ahead because the reviews before the manual reset would have been removed till then.

Suspended cards
Dealt differently in reschedule and optimizer

Rescheduler: Skip these cards
https://github.com/open-spaced-repetition/fsrs4anki-helper/blob/4ddd4be62ed8478499e43bf2cecddf8a0dcb2c43/schedule/reschedule.py#L322-L324
Optimizer: It is for the user to decide.
https://github.com/open-spaced-repetition/fsrs-rs/blob/531566c49a861d4d57e0a228a2dd3dec5616b93b/src/convertor_tests.rs#L178-L182

Optimizer code (this repo): Couldn't find

Here:
https://github.com/open-spaced-repetition/fsrs-rs/blob/4df08dd304dd6521ddd0006ebed796781e71931f/src/temporary_test.rs#L61-L66

Thanks, that's helpful. I've just pushed a draft of Anki integration you can play with, and I'll try return to this tomorrow.

I think we may be ok now?

Suspended cards are excluded from review already, so that's not a problem. Users can optionally exclude them from training.
"Reviews in filtered deck when reschedule cards based on my answers in this deck is disabled.": ignored by the optimizer, and when reviewing the standard Anki review code will be used, and memory state not updated.
"First review type is not LEARN / Incomplete review history": I think this is already handled by the code that looks for the last learning entry.
The other cases are already covered.

First review type is not LEARN / Incomplete review history

According to https://github.com/open-spaced-repetition/fsrs4anki-helper/issues/16#issuecomment-1426778543, @user1823 proposed that it is better to skip only those cards whose first review kind isn't learning AND which don't have any again rating.
For example:

Do you mean the starting point should be min(last_learning_idx, first_again_idx)? For both training and review?

I think it only works for review. Maybe @user1823 has more ideas. And I think it's OK to skip them both in training and review, because these cases are very rare.

Apart from sync conflicts, the main reason this might occur is for long-term / heavy Anki users, who have removed the oldest few years of their review history to keep their collection size down & stay inside the AnkiWeb sync limits. Quite rare, but might be best to deal with.

Yeah. For these cases, we should treat the first relearning review as the first learning review.

With the current version of FSRS (python optimizer and add-on), the approach is to

FILTER OUT ALL the reviews of such cards when optimizing
KEEP ALL the reviews of such cards if they contain any Again rating when rescheduling

The rationale:

The review history is incomplete and it can corrupt the trained weights. So, it is best to skip these cards while optimizing.
When rescheduling, only these cards are affected. So, the risk of including them is not very high. But, there are two types of cards to consider:

Cards that have no Again rating in the "known" review history. If these cards are rescheduled, it can lead to problems like this:

The interval decreased from 1.04 years to just 2 days. So, we should not reschedule such cards.

Cards that have one or more Again ratings in their "known" review history.

If these cards are rescheduled without filtering out any reviews, I think that the memory states obtained are reasonable (based on personal experience). The helper add-on currently uses this approach and we can use it in Anki's implementation too.
If these cards are rescheduled after filtering out the reviews before the last rating, I am not sure what the final result would be. But, it might be reasonable as well.

.filter(|entry| entry.review_kind != Filtered)
To filter out just the CRAM revlogs, doesn't the condition need to be the following?

entry.review_kind != Filtered || entry.ease_factor != 0

(entry.review_kind != Manual && entry.button_chosen != 0) || entry.ease_factor == 0

Wouldn't this remove all the Manual ratings? Shouldn't this be the following?
entry.button_chosen != 0 || entry.ease_factor == 0
I get it that we ultimately want to remove all the MANUAL ratings but I think that currently, it is removing more ratings than those suggested by the name of the function.

entry.review_kind != Filtered || entry.ease_factor != 0

https://github.com/ankitects/anki/pull/2656#discussion_r1324290951

The main reason this might occur is for long-term / heavy Anki users, who have removed the oldest few years of their review history to keep their collection size down & stay inside the AnkiWeb sync limits. Quite rare, but might be best to deal with.

@dae, is this case (incomplete review history) dealt with in the latest beta?
I suggest using this approach to deal with such cards. But obviously, if you have a better idea to deal with them, it would be fine too.

I've changed the code in beta 2 so that a lack of learning steps no longer causes the memory state to be as if the card is new. If you have further suggestions, I'm open to them.

a lack of learning steps no longer causes the memory state to be as if the card is new

If all such cards are rescheduled, it can lead to problem like this (where the interval decreased from 1.04 years to just 2 days).

But, we also don't want to treat all such cards as new because then FSRS wouldn't work for them.
So, I suggest re-reading this comment of mine, where I have discussed the issue in a greater detail.

Once Anki no longer calculates the memory states for such cards, we will also need to figure out how to deal with such cards when they come up for review.
I didn't face this problem till now because I do my reviews on AnkiDroid where FSRS is not supported and SM-2 schedules the cards instead. But when, FSRS is the only scheduler available, we will need to make a special function for such cards. Possible options:

Use SM-2
Use the convert_states function of FSRS Scheduler (js)

https://github.com/open-spaced-repetition/fsrs4anki/blob/5a34201f4d5b3a9cc1a5da4511b6bc32b7c6e909/fsrs4anki_scheduler.js#L228-L241
https://github.com/open-spaced-repetition/fsrs4anki/blob/5a34201f4d5b3a9cc1a5da4511b6bc32b7c6e909/fsrs4anki_scheduler.js#L133-L144
For a textual description of this function, refer to https://github.com/open-spaced-repetition/fsrs4anki/wiki/How-does-the-scheduler-work%3F#calculate-memory-states

Re https://forums.ankiweb.net/t/anki-23-10-beta/34912/38 and comments above:
During inference, I think we may need to produce a memory state if the card has any reps on it, as it will be surprising to the user otherwise. If the user has cards with a truncated review history, or cards they used 'set due date' on to introduce without going through the new queue, excluding cards without learning steps would mean such cards could never have a memory state assigned, and the initial stability/difficulty would be used at each review based on the current rating, so intervals would never grow.
We could change the criteria from "must have learning" to "must have Again", but that would mean the ratings would not grow above the initial intervals until the user rates such cards Again, which will be confusing and look like a bug in FSRS/Anki. Wouldn't it be better to just use whatever review came first? In the set-due-date case that would correctly reflect what would have happened if the user had gone through the new queue, and in the truncated revlog case, the initial stability may be wrong, but is hopefully shifted back towards actual by the subsequent reviews in the history.
Regarding writing a separate function instead, that would be a bit tricky, as the current code assumes a missing memory state when a card is not new means the memory state needs to be calculated from the revlog. I think it might be simpler to try and handle such cards in the same way other cards are handled (i.e. giving them an approximate memory state). WDYT?

giving them an approximate memory state

Here is a method to convert Anki's interval and ease into FSRS's stability and difficulty: https://github.com/open-spaced-repetition/fsrs4anki/wiki/How-does-the-scheduler-work%3F#interval-to-stability

fsrs-js didn't have access to the revlog history, which we do here - do you still feel converting from SM-2 ease is safer than trying to infer the memory state from incomplete logs? No preference on my end, just curious.

There are too many complex cases for incomplete logs. It's hard to deal with those corner cases one by one. So I prefer to convert memory state from SM-2 ease and interval.

There are too many complex cases for incomplete logs. It's hard to deal with those corner cases one by one. So I prefer to convert memory state from SM-2 ease and interval.

I completely agree. With this, we can also get rid of the check for the presence of an Again rating in the known review history.
To summarise, we are going to deal with such cards in the following way:

Check if the first rating is of Learn type or not.
If the first rating is of Learn type, no issue. In this case, Anki can calculate the memory states the normal way.
If the first rating is not of Learn type, use SM-2 ease factor and interval at the first rating to estimate the memory states. Then, on subsequent ratings of the same card, update the memory states using the normal FSRS formulas.

Another question that needs to be answered:
Which interval is used in the following line of code? The interval before the first rating? Or the interval obtained after the first rating?
https://github.com/open-spaced-repetition/fsrs-rs/blob/d389762b4fd73d9b43ab3af5f4f091807ddee96f/src/inference.rs#L88
In the first case, we will obtain the memory states before the first rating, and we will have to calculate the memory states after the first rating using the regular FSRS formulas.
In the second case, we will obtain the memory states after the first rating, and we will have to calculate the memory states after the subsequent ratings using the regular FSRS formulas.
In my opinion, the first option is better because the memory states will tend to be more accurate (the earlier we can calculate the memory states, the more accurate the results will be) and it can deal with cards having no review history at the time of review (explained in the next para).
Consider the following card. I reviewed it today and it had no review history before today. Assume that I had started using native FSRS yesterday. Now, if Anki doesn't use the first approach (calculating memory states from interval and ease before the first rating), it won't be able to schedule this card.

However, I think that the interval before the first review will be available only during review (due to technical limitations). So, we might want to use a hybrid approach.

In the scheduler, calculate the memory states from interval and ease before the rating if the card doesn't have any review history (but it is not new).
In the re-scheduler, calculate the memory states from interval and ease after the first rating.

The memory state is derived when saving weights or when reviewing a card without state, so it should work as you expect.

Sorry for asking too many questions, but I want to ensure that the built-in FSRS works perfectly fine when it is released as stable. Also, because I am not comfortable in reading Rust code (especially when it is scattered across several files and repos), I can only rely on basic experimentation and such question/answers to ensure that things work fine.
To be concise, in the above comment, I asked about a review card with no review history at the time of review. Can such cards be assigned memory states with the current code? If not, I proposed a solution in the same comment.
For an example, consider the following card. What will happen when it comes for review on 12th October?

Cards without any review history don't get updated by the deck options, but when it comes time to review, the memory state is first derived from the ease factor and interval, and then that state is changed by the rating the user provided.


Video Optimization: Respect user setting

Feature Description
Since there's an opt-out on the dashboard settings screen for video optimization, we need to respect that setting when doing the transcoding in the editor.
Alternatives Considered

Additional Context

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria

Implementation Brief

[ ] Preload users/me REST API response in editor
[ ] Add new getCurrentUser method to API provider to fetch current user
[ ] In API provider, set currentUser as state (const [currentUser, setCurrentUser] = useState({});)
(we don't want to call getCurrentUser every time we need the user info)
[ ] In useTranscodeVideo, update canTranscodeFile to return false if user opted out.

I decided to see if there was an simpler way to add a check for video optimization. It felt like it would be simplier to map it a capability and pass it in with config. We don't need to get a api request here, even preloaded it adds some overhead we may not need.  Can you have a look at #6123 @swissspidy see what you think? Other explain the need for REST API request here?

@spacedmonkey The API request is needed because of #6087. The user can disable optimization via the REST API right from within the editor, which means that by simply passing it to the config it won't get the updated value after opt-out.
Screenshot:

The API request is needed because of #6087. The user can disable optimization via the REST API right from within the editor, which means that by simply passing it to the config it won't get the updated value after opt-out.

This context is extremely useful before start writing, so thanks for sharing it. Okay, if this seeming that the state of this will change within the editor, so I think that it should live in it's own provider that wraps the editor, as other compontent depend on this state. Or should storing the state be handled by #6087

I think it could work just fine in the APIProvider like we already do in the dashboard. That's why I originally proposed it like that in the ticket description. But of course there can also be a simple CurrentUserProvider, with APIProvider just providing getCurrentUser & updateCurrentUser methods

But of course there can also be a simple CurrentUserProvider, with APIProvider just providing getCurrentUser & updateCurrentUser methods

I think this makes more sense. The api provider doesn't manage any state at all at the moment and I think managing in it's own provider makes a lot of sense. Specially for FTE if we expand it.

Then let's do it that way.


Malloc error

First off, this is a fantastic script. Been doing some HDR10+ metadata retention with it. Thank you!
Now on to the issue at hand.
The script works well for most titles with HDR10+ metadata but then throws malloc errors on others. I'm not sure if anyone else is having the same experience.
I encode on a headless Ubuntu 18.04. This is the error that I just recently got:
x265 [info]: Main 10 profile, Level-5.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 3 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias  : 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-16.0 / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init    : 36000 / 18000 / 0.900
x265 [info]: tools: rd=3 psy-rd=1.00 rdoq=1 psy-rdoq=3.00 early-skip
x265 [info]: tools: rskip mode=1 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock(tC=-3:B=-3) dhdr10-info
ffmpeg: malloc.c:3830: _int_malloc: Assertion `chunk_main_arena (bck->bk)' failed.speed=0.367x

Can you mention the title the metadata is from? I have heard issues about x265 not being able to complete encodes on some.

The new Back to the Future UHD with HDR10+

The new Back to the Future UHD with HDR10+
1917

At least for 1917, there are a lot of mentions the issue is with x265. Supposedly NVENC with the metadata has no problem encoding fully.
x265 is terminating a few frames before the end, and the JSON has the same number of metadata messages as the source frame number.
I'd have to look at Back to the Future but it is possible that the same problem happens, which doesn't seem to be related to the parser.

Hmm interesting. But it seems those guys have been able to encode some frames. With me, the x265 encoder crashes with malloc errors within the first 1-2 seconds of encoding. Doesn't even start properly. It does seem to be a memory issue with x265 judging my those malloc errors. But then again for some other HDR10+ encodes, it has worked completely file. Figured I'd check in here also.
But you're right, it doesn't seem to be a problem with the parsing script itself. Guess our best bet is to wait for a fix with x265. I've compiled another ffmpeg build with x265 3.5 also. But that doesn't fix the issue either.

I'll keep the issue open until I can have a look at the new discs.

I'll keep the issue open until I can have a look at the new discs.

Thanks man. Most appreciated.

Getting the same issue with Back to the Future Part II

x265 is definitely the one crashing, but I have an idea what is going wrong.
encoded 222 frames in 8.15s (27.23 fps), 371.76 kb/s, Avg QP:32.79
free(): invalid next size (fast)`

@theweasley I've pushed a possible fix, can you test a build from master?

@quietvoid okay giving it a go now. Will report back.

@quietvoid Getting this error now with your provided build:
/lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.32' not found (required by ~/.scripts/hdr10plus_parser)`
My Ubuntu 18.04 is running GLIBC_2.27 which is the max available for 18.04. I looked online a bit and it seems you need to build the script with a lower version or?

@quietvoid Getting this error now with your provided build:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ~/.scripts/hdr10plus_parser)

My Ubuntu 18.04 is running GLIBC_2.27 which is the max available for 18.04. I looked online a bit and it seems you need to build the script with a lower version or?

Yea that's the issue with glib linked linux builds, you'd have to build your own as they're not compatible across versions.

Ahh, timely post for me.  I just got done encoding the movie 1917 and it errored 7 frames short of being complete
Video encoding returned error exit code: -1073740940 (0xC0000374)

@quietvoid okay that build worked. I've started an encode for 1917 also like the gentleman above me. This time there's no crash at the beginning so that's definitely been fixed. Now let's see if it returns any missing frames at the end.

P.S: The fix that you've implemented, does it potentially impact other titles that used to work before with your previous release?

All the tests pass, so it shouldn't affect parsing.
It's just changing the output JSON to avoid mixing the different profiles, as that's what seems to cause problems with x265.
I don't really know if it will affect playback tonemapping either.

I've created an issue at x265: https://bitbucket.org/multicoreware/x265_git/issues/574/x265-segmentation-fault-when-using-hdr10
So for now I will just add a warning when this situation happens, with an optional flag that will "fix' it.

Thanks for adding the optional flag in there to make it more graceful. Thanks for all your hard work and this excellent script. Hoping for a fix on the x265 end.

Thanks both of you.  I'll give 1917 another go now.

Fixed in new release: https://github.com/quietvoid/hdr10plus_parser/releases/tag/0.2.9

It turns out there was actually an incorrect parsing, at least for Back to the Future.
However it only seems to have affected around ~10 frames.
This has been fixed in 0.3.0.


general cleanup, PEP8, function headers, arg/return types

In-flight entertainment PR
Finished function headers and explicit typing for arguments and return values for majority of the codebase
Moved helper functions out of image_datset.py into utils/data.py
Bugfix for an issue where some images in open-images have an alpha channel, but their mode is not set to RBGA. Due to code (which has now been removed) that checked for 'A' in the image's mode attribute before converting to RGB, the alpha channel wasn't removed and training broke due to a shape mismatch.

Looks good documentation wise & defaulting to rgb conversion for images should increase the coverage/num of useable images from unexpected formats. We could log # conversion failures (if any) or percent of images that have unexpected dimensions/channels before conversion.
Also potentially worth checking any drops in image quality from PIL convert and what img formats converted would suffer that
(e.g. issue with lossy/quantized RGBA convert python-pillow/Pillow#3059)

Good points around logging and image quality. Anecdotally I haven't noticed any quality issues from RGB conversions, but definitely something to look out for.


Refactor mocha for ava

Not stuck on ava, but the goal is to use something more future focused.
Here's an example refactor https://github.com/zeit/now-client/pull/50

Could you provide a brief summary of why you think we should move off Mocha? Not opposed to something new, but I'd like to make we understand the tradeoffs before we invest time in it.

What we gain is listed here https://github.com/avajs/ava#why-ava (didn't want to rewrite it any worse lol).

Done!


On Windows 7 Ultimate SP1 (x86) with "Windows 7 Basic" or "Windows Classic" theme, Supermium window title appears in Windows 10 style rather than Windows Vista style

Is it possible to fix this bug using chrome://flags?

Yes, go to chrome://flags/#disable-windows-10-custom-titlebar and enable it.

Yes, go to chrome://flags/#disable-windows-10-custom-titlebar and enable it.

Does not help. With the "Windows 7 Basic" and "Windows Classic" color schemes, the Windows 10 style window title was and remains in Supermium.

can confirm the issue with title bar when classic or basic theme enabled (no chrome theme applied)
suggested disable-windows-10-custom-titlebar flag has no effect as well
also noticed #352 and #635 issues and absence of issue #605
as workaround that will force solid-aero-like caption buttons can suggest apply any theme with custom frame (there no such mark in CWS - some authors show it on screenshot or state in description, otherwise can be checked by installation)
as bonus you can tweak buttons by editing resources in chrome_*00_percent.pak
bonus joke with basic theme
happens when moving mouse between buttons

Windows 7 Ultimate SP1 (x64), UxTheme patched, far away from standard system
can check on clean VM a bit later

You can also use the #force-xp-theme flag.


Remove version: DominikReichl.KeePass version 2.51.1

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

URL: https://sourceforge.net/projects/keepass/files/KeePass 2.x/2.51.1/KeePass-2.51.1.msi/download
Status Code: 200
(Automated message - build 897)

Close with reason: Package still available.;


Meteor constantly failing when trying to do reverse geocode.

Here's the problem:
In the package, in geocoder.js:34 you are calling
g.reverse(lat, lng, callback);

And the geocoder waits for object and callback, in .npm/package/node_modules/node-geocoder/lib/geocoder.js:52
Geocoder.prototype.reverse = function(query, callback) {

where query is
{lat:<number>,lon:<number>}  lat: Latitude, lon: Longitude

So the correct way to call reverse geocoding is
g.reverse({lat: lat, lon: lng}, callback);

Me too. I asked on http://stackoverflow.com/q/32967078/5251833

Fixed in 0.3.8

Works!
Thanks for this quick fix :)

thanks a lot!


Linux: unable to install from source

Preamble

Issue: Unable to compile F# on Linux when following the instructions
given on the homepage https://fsharp.org/use/linux/ (Option 2: Install from source).

OS: Slackware64-current

Mono:
Mono JIT compiler version 5.15.0 (master/89ecd02722d Mon Apr 30 11:09:49 CEST 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS:           __thread
SIGSEGV:       altstack
Notifications: epoll
Architecture:  amd64
Disabled:      none
Misc:          softdebug
Interpreter:   yes
LLVM:          supported, not enabled.
GC:            sgen (concurrent by default)

F# version (branch): master

Steps to reproduce the problem

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/mono
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig

git clone https://github.com/fsharp/fsharp

make

Expected behavior
Build F# without any issues
Actual behavior
$> make
-----------
prefix=/usr/local
topdir=/mnt/data/repositories/git/fsharp/mono/../
monodir=/usr/local/lib/mono
monolibdir=/usr/local/lib/
monobindir=/usr/local/bin/
-----------
make restore
make[1]: Entering directory '/mnt/data/repositories/git/fsharp'
MONO_ENV_OPTIONS= mono .nuget/NuGet.exe restore packages.config -PackagesDirectory packages -ConfigFile .nuget/NuGet.Config
All packages listed in packages.config are already installed.
chmod u+x packages/FSharp.Compiler.Tools.4.1.27/tools/fsi.exe
chmod u+x packages/FsLexYacc.7.0.6/build/fslex.exe
chmod u+x packages/FsLexYacc.7.0.6/build/fsyacc.exe
make[1]: Leaving directory '/mnt/data/repositories/git/fsharp'
make build-proto
make[1]: Entering directory '/mnt/data/repositories/git/fsharp'
MONO_ENV_OPTIONS= msbuild /p:Configuration=Proto /p:TargetDotnetProfile=net40 src/fsharp/FSharp.Build-proto/FSharp.Build-proto.fsproj
/bin/sh: msbuild: command not found
make[1]: *** [Makefile:28: build-proto] Error 127
make[1]: Leaving directory '/mnt/data/repositories/git/fsharp'
make: *** [Makefile:24: all] Error 2

Known workarounds
None so far.
Apparently there is a dependency on MSBuild (not mentioned). But building MSBuild
does not "help", as then other issues arise. See #836  for a possible workaround,
but I cannot rely on binary packages as they are not suited to my setup. I want to
have all installed from source.
Related information
None
Others (rants)
As the documentation is wrong, this is clearly a bug (of the documentation itself)

Do you also have msbuild installed?  I think the preferred repo is https://github.com/mono/linux-packaging-msbuild, however FreeBSD uses https://github.com/mono/msbuild

MSBuild
I managed to build msbuild using the repo https://github.com/mono/msbuild. However, I had to choose a specific branch (I just guessed):  mono-2018-04. Is this the/a branch that is OK?
One problem I have is that I do not know how to properly deploy the executable msbuild, together with its DLLs, such that it can be invoked by the fsharp compilation environment. For now I just point the PATH  env var to the build directory where msbuild resides (../artifacts/mono-msbuild/).
FSharp
Unfortuanetly I'm still unable to compile fsharp. Which is the branch/tag that is the most up-to-date and is actually "buildable"?
I execute autogen.sh, followed by configure and make. The error I get when using version (tag) 4.1.34:  ../fsharp/src/scripts/scriptlib.fsx(40,39): error FS0041: A unique overload for method 'StartsWith' could not be determined based on type information prior to this program point.

../fsharp/src/scripts/scriptlib.fsx(40,39): error FS0041: A unique overload for method 'StartsWith' could not be determined based on type information prior to this program point.

This sounds familiar. Try this patch https://github.com/mono/mono/blob/master/packaging/MacSDK/patches/fsharp-path-overloads.patch

Or maybe this one https://github.com/fsharp/fsharp/pull/832/files

I finally managed to build F# from source :)
What I did:

cloned mono from https://github.com/mono/mono.git, and built [master] acc. to the instructions given (no problem)
cloned msbuild from https://github.com/mono/msbuild.git, and just called make (initially I had to use branch [mono-2018-04], but yesterday it compiled just fine on [xplat-master] (the default?)?)
cloned fsharp from https://github.com/fsharp/fsharp.git [master] and set my PATH env var to include .../msbuild/artifacts/mono-msbuild and proceeded according to the instructions given on  https://fsharp.org/use/linux/, Option 2: Install from source:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/.../mono/lib/
export PKG_CONFIG_PATH=/.../mono/lib/pkgconfig/
followed by the holy trinity ./configure && make && make install
Please comment if you're solution to install F# from source differs...

FYI I have not hit this issue on Fedora 29

This has been solved per comments above.
Note the preferred build-from-source option (with no binary package dependencies) is to build the .NET SDK from source with F# support, see "src/buildfromsource.cmd/sh"

@bsdooby are there any known to be working tags or commit-shas for msbuild? (currently trying to build fsharp-10.2.3 with mono-<IP_ADDRESS> here)


CLI does not allow any JSON except map

Describe the bug
If anything except for a JSON map is put as the parameters for any call or view cli command, this error is returned:
PositionalArgsError: Contract method calls expect named arguments wrapped in object, e.g. { argName1: argValue1, argName2: argValue2 }

The issue is that the JSON does not have to be a map to be deserialized as parameters of a function. For example, in the near-sdk-rs, serde  is used for the input parameters which allows deserializing as a map or an ordered sequence (JSON array).
So, if a method within near_bindgen is:
pub fn method(param_a: u8, param_b: String)  {..}

The parameters that would be valid are:
{"param_a":8,"param_b":"some_val"}

OR
[8,"some_val"]

but the latter is not allowed through CLI. This is very helpful when debugging quickly but also to minimize the size of the JSON being serialized and sent as input.
To Reproduce
Steps to reproduce the behavior:
Call any method with anything except map JSON, for example:
near call <account_id> method '[8,"some_val"]'
Expected behavior
A clear and concise description of what you expected to happen.
Should let the request be sent off, because the tx would succeed if done correctly
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. MacOS]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

I believe we should avoid enabling error-prone ways of interaction. We use JSON format to ease reviewing the arguments and we drop the field names, we should better use borsh.


Fix/4235 – Consistent Sorting Of Countries – Alphabetically

Description
Fixes the inconsistent sorting of country list.

on "Andere warnen", countries are sorted as provided by app config (i.e. unsorted)
on "Ihr Einverständnis", countries are sorted alphabetically

Spec: sort alphabetically.
Link to Jira
https://jira-ibs.wbs.net.sap/browse/EXPOSUREAPP-4235
Screenshots

Could you please add a simple unit test?

Added a unit test for sorting countries based on localized country names for all supported languages.


fix(export) fix serviceTemplate cache reset when export

Description
Fix error when exporting two pollers at the same time sharing the same severity

Type of change

[x] Patch fixing an issue (non-breaking change)
[ ] New functionality (non-breaking change)
[ ] Breaking change (patch or feature) that might cause side effects breaking part of the Software

Target serie

[ ] 21.04.x
[ ] 21.10.x
[x] 22.04.x
[x] 22.10.x
[x] 23.04.x (master)

Checklist
Community contributors & Centreon team

[x] I have followed the coding style guidelines provided by Centreon
[ ] I have commented my code, especially new classes, functions or any legacy code modified. (docblock)
[ ] I have commented my code, especially hard-to-understand areas of the PR.
[ ] I have rebased my development branch on the base branch (master, maintenance).

migrated from https://github.com/centreon/centreon/pull/12024


Using question-uploader causes error

Using the question-uploader component, e.g.
  {{question-uploader ident="review.upload"
    task=model
    question="Attach additional files"
    updateStore="updateStore"}}

causes an error:
 Error: <Ember._HandlebarsBoundView:ember1726> Handlebars error: Could not find component or helper named 'question-attachment-thumbnail'

Where do you see this error message? Is it in the browser JS console, or in the Rails logs?

Thanks, @rizwanreza !


Control speed of animation

Is it possible to set frames/speed of the animation in runtime?
If no, then treat it as a feature request, please :)

Never mind, I found the answer here: https://github.com/defold/extension-rive/blob/main/defold-rive/api/rive.script_api
Basically, we can create a table with the playback_rate key and pass this table as an options parameter in play_anim
To be fully satisfied I would like to have the possibility to get animation time/fps from Rive models. I guess that is not possible, but maybe I should play with it a little more to not create unnecessary issues :)


fix(10): improve correctness of sentence

By adding color_point.to_point to the code example

merged by f9840c9


Make it possible to digest-pin the iter8 install action

Is your feature request related to a problem? Please describe.
It is recommended to pin github actions by their commit hash to ensure reproduciability and enhance the supply chain security: https://michaelheap.com/ensure-github-actions-pinned-sha/. This is also something the OpenSSF Scorecard projects will notify the users about: https://github.com/ossf/scorecard.
It's currently not possible to pin the iter8-tools/iter8 action by its commit hash since the action relies on the tag to determine the version to install: https://github.com/iter8-tools/iter8/blob/master/action.yaml#L8
Describe the solution you'd like
I think a solution would be to pass the version to install as an action input parameter. This parameter could continue to default to ${{ github.action_ref }}. But people that would like to pin the action can do so while also specifying a version to install. That's similar to how e.g. the helm-kind-action works: https://github.com/helm/kind-action/blob/main/action.yml#L11
Describe alternatives you've considered
An even better solution would be automatically updating the action's default-version on every new release - although this might be challenging/annoying depending on the release process.
Additional context
I'd be happy to create a PR for the first proposed solution or help discuss the work required for the second.

The makes sense to me; I understand the need to pin to a specific SHA. Agree that your first solution would work and that the second would be better.
Would be happy to look at a PR for the first approach. And please do add what might be needed for the second.

Thank you for the feedback! I created a PR at https://github.com/iter8-tools/iter8/pull/1377. The second option is probably something that can build upon this - the only thing needed is a way to keep the default value for the version input up-to-date.
Some thoughts on that:
One option would be an auto-created commit every time a new release is created. Unfortunately, releases created by a github-action workflow can't trigger another workflow (see https://stackoverflow.com/a/69063453) so it would require setting a PAT. Actions like the chart-releaser-action seem to bump versions manually (e.g. https://github.com/helm/chart-releaser-action/commit/98bccfd32b0f76149d188912ac8e45ddd3f8695f). This could be automated using renovatebot (https://github.com/renovatebot/renovate) and its regexmanager (https://docs.renovatebot.com/modules/manager/regex/). In both cases, the downside is that the commit from which the release tag was created is not the same one that bumped the action version but the commit after that.
Personally, I quite like conventional commits so I'm a fan of https://github.com/googleapis/release-please. The created PR can update version tags in the same commit used to create a release. But switching to and enforcing conventional commits can be an annoyance in itself if not deemed necessary.
For my use case, its sufficient to be able to pin the action by digest and specify the release version manually. I will configure renovate on my end to keep the version parameter in-sync with the latest releases from this repository. So for me, option 2 isn't strictly necessary.


[Tutorial/Basic] Fix letter case of basic-functions for Jekyll

Fix

Describe why this change is necessary. If it's a bug, why did it happen?

Basic(한글) chapter is not work like we expected. So fix YAML in child files.

What did you fix via this PR? Describe it from business logic perspective.
x

Changes

Describe the code changes (links to commits or lines)
Describe the test coverage added via unit test or postman.

How Verified
(Automated Tests)

npm test (100% passed)
npm run lint (0 error/warning)

(Manual Tests)

List all test cases you have run manually
Ran Jekyll locally.

Notes

What can been done to prevent this from happening again?
List issues or things to follow-up separately.

References

What did you refer to make this change?
It is best to refer mainly to official documents.

@Haerang94 You man check this.


How to call "xxx.so" file

Dear Zappa developers,
thanks for providing such a wonderful solution to help depoly python web services to Lambda.
i am trying to use Zappa to migrate my current Django project to lambda, the problem is some of my third-party packages are not pure python (example package "levenshtein") the output file was a "xxxxxx.so" file, it works from my local but reported "Import Error" when i deploy to Lambda.
I m new to Lambda, sorry for bothering you guys, but could you please help give me some suggestions  how i can call ".so" file from Lambda?
Thanks in advance.

Maybe something like this https://github.com/Miserlou/Zappa/issues/1260 would help.


First round cleanup to enable validation from openapi

These changes are to faciliate the catalog to use the
validation from the manageiq-api-common gem along with
deriving the strong parameters from the openapi spec.

@syncrou Please review

@mkanoor if you could rebase this I can get it merged.


daily papers api

Hi, there is a free api for daily papers here: https://huggingface.co/api/daily_papers
check out the docs here: https://huggingface.co/docs/hub/en/api#paper-pages-api

Oh, I had no idea, thanks for the tip! I can just pull the paper id from the API instead of scraping the website. Much appreciated!

@AK391 Actually, is there a way to access papers from previous days? I implemented a lag of 1 day because I assumed that papers would get added throughout the day and I wanted a complete list of all the papers from each day.


Adding scene manager tutorial

GearVRf-DCO-1.0-Signed-off-by: Nola Donato<EMAIL_ADDRESS>

Will merge after lunch


Revert "tus: Fix upload not found scenario"

Reverts OdyseeTeam/odysee-frontend#1808

seeing lots of these now: Error: upload is still in process


Do we have something like Instruction.can_raise_exception()?

I'd like to know if an instruction can potentially raise an "exception" (not sure what the technically correct term is here), such as div-by-0, or segfault for memory reads/writes, etc.
Background:  When I try to remove redundant instructions after a STOKE search, we shouldn't remove anything that might have visible side-effects like raising an exception.

Ooof. Not really.
The short answer is that anything implicitly or explicitly dereferences
memory can raise sigsegv and any of the div instructions can raise sigfpe.
Also anything that Sandbox::is_unsupported() returns true for can raise
sigill. UD2 can raise sigill too.
On Wed, Feb 11, 2015 at 4:51 PM, Stefan Heule<EMAIL_ADDRESS>wrote:

I'd like to know if an instruction can potentially raise an "exception"
(not sure what the technically correct term is here), such as div-by-0, or
segfault for memory reads/writes, etc.
Background: When I try to remove redundant instructions after a STOKE
search, we shouldn't remove anything that might have visible side-effects
like raising an exception.
—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151.

Ok, that all makes sense.  Some floating point operations can also raise exceptions, no?
Do you think it would make sense to implement something like this here, or should I just have a helper method in my code (in STOKE)?

Stefan and I talked about this some earlier.   I tend to think that if
we implement this in terms of the hardware (i.e. what hardware
exceptions an instruction can cause) it should go in x64asm; but if we
implement this in terms of the sandbox signals it should go in stoke.
What do you all think?
On 02/11/2015 04:54 PM, eric schkufza wrote:

Ooof. Not really.
The short answer is that anything implicitly or explicitly dereferences
memory can raise sigsegv and any of the div instructions can raise sigfpe.
Also anything that Sandbox::is_unsupported() returns true for can raise
sigill. UD2 can raise sigill too.
On Wed, Feb 11, 2015 at 4:51 PM, Stefan Heule<EMAIL_ADDRESS>wrote:

I'd like to know if an instruction can potentially raise an "exception"
(not sure what the technically correct term is here), such as
div-by-0, or
segfault for memory reads/writes, etc.
Background: When I try to remove redundant instructions after a STOKE
search, we shouldn't remove anything that might have visible
side-effects
like raising an exception.
—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151.

—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#issuecomment-73997693.

Agreed. If it relates to the implementation of the sandbox I would put it
in stoke.
On Wed, Feb 11, 2015 at 4:56 PM, Berkeley Churchill <
<EMAIL_ADDRESS>wrote:

Stefan and I talked about this some earlier. I tend to think that if
we implement this in terms of the hardware (i.e. what hardware
exceptions an instruction can cause) it should go in x64asm; but if we
implement this in terms of the sandbox signals it should go in stoke.
What do you all think?
On 02/11/2015 04:54 PM, eric schkufza wrote:

Ooof. Not really.
The short answer is that anything implicitly or explicitly dereferences
memory can raise sigsegv and any of the div instructions can raise
sigfpe.
Also anything that Sandbox::is_unsupported() returns true for can raise
sigill. UD2 can raise sigill too.
On Wed, Feb 11, 2015 at 4:51 PM, Stefan Heule<EMAIL_ADDRESS>wrote:

I'd like to know if an instruction can potentially raise an "exception"
(not sure what the technically correct term is here), such as
div-by-0, or
segfault for memory reads/writes, etc.
Background: When I try to remove redundant instructions after a STOKE
search, we shouldn't remove anything that might have visible
side-effects
like raising an exception.
—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151.

—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#issuecomment-73997693.

—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#issuecomment-73997941.

I'd make it a static member of the sandbox just like is_unsupported().
On Wed, Feb 11, 2015 at 4:57 PM, eric schkufza<EMAIL_ADDRESS>wrote:

Agreed. If it relates to the implementation of the sandbox I would put it
in stoke.
On Wed, Feb 11, 2015 at 4:56 PM, Berkeley Churchill <
<EMAIL_ADDRESS>wrote:

Stefan and I talked about this some earlier. I tend to think that if
we implement this in terms of the hardware (i.e. what hardware
exceptions an instruction can cause) it should go in x64asm; but if we
implement this in terms of the sandbox signals it should go in stoke.
What do you all think?
On 02/11/2015 04:54 PM, eric schkufza wrote:

Ooof. Not really.
The short answer is that anything implicitly or explicitly dereferences
memory can raise sigsegv and any of the div instructions can raise
sigfpe.
Also anything that Sandbox::is_unsupported() returns true for can raise
sigill. UD2 can raise sigill too.
On Wed, Feb 11, 2015 at 4:51 PM, Stefan Heule<EMAIL_ADDRESS>wrote:

I'd like to know if an instruction can potentially raise an
"exception"
(not sure what the technically correct term is here), such as
div-by-0, or
segfault for memory reads/writes, etc.
Background: When I try to remove redundant instructions after a STOKE
search, we shouldn't remove anything that might have visible
side-effects
like raising an exception.
—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151.

—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#issuecomment-73997693.

—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#issuecomment-73997941.

That makes sense, but I don't think it does need to relate to the sandbox.  It would just be about whether the instruction can raise a hardware exception.  And we could still have a static method in the sandbox that returns true in the same cases, plus whenever the sandbox signals (e.g. unsupported things).  Does that make sense?

Yeah, that makes sense.  We should be sure to distinguish between types
of hardware instructions in the x64asm api though.  Behold the coming of
"ExceptionSet", "ExceptionSetReader", "ExceptionSetWriter".
On 02/11/2015 04:59 PM, Stefan Heule wrote:

That makes sense, but I don't think it does need to relate to the
sandbox. It would just be about whether the instruction can raise a
hardware exception. And we could still have a static method in the
sandbox that returns true in the same cases, plus whenever the sandbox
signals (e.g. unsupported things). Does that make sense?
—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#issuecomment-73998206.

If it relates to the actual behavior of the instruction when executed
directly on the hardware, then I think it should go in x64asm.
On Wed, Feb 11, 2015 at 4:59 PM, Stefan Heule<EMAIL_ADDRESS>wrote:

That makes sense, but I don't think it does need to relate to the sandbox.
It would just be about whether the instruction can raise a hardware
exception. And we could still have a static method in the sandbox that
returns true in the same cases, plus whenever the sandbox signals (e.g.
unsupported things). Does that make sense?
—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#issuecomment-73998206.

If you want to go that route, it should really be added to the spreadsheet
and everything.
On Wed, Feb 11, 2015 at 5:01 PM, Berkeley Churchill <
<EMAIL_ADDRESS>wrote:

Yeah, that makes sense. We should be sure to distinguish between types
of hardware instructions in the x64asm api though. Behold the coming of
"ExceptionSet", "ExceptionSetReader", "ExceptionSetWriter".
On 02/11/2015 04:59 PM, Stefan Heule wrote:

That makes sense, but I don't think it does need to relate to the
sandbox. It would just be about whether the instruction can raise a
hardware exception. And we could still have a static method in the
sandbox that returns true in the same cases, plus whenever the sandbox
signals (e.g. unsupported things). Does that make sense?
—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#issuecomment-73998206.

—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#issuecomment-73998482.

Ok, thanks for all the input.  I looked at the manual a bit, and I think to do this properly here would be a lot of work, so for now I'll add a small helper to STOKE that covers what I need.

Sorry for the lag. Yeah. That sounds good to me. I'm perfectly happy yo
have extended error codes beginning from 256 that describe stoke specific
error modes.
On Feb 11, 2015 6:17 PM, "Stefan Heule"<EMAIL_ADDRESS>wrote:

Closed #151 https://github.com/eschkufz/x64asm/issues/151.
—
Reply to this email directly or view it on GitHub
https://github.com/eschkufz/x64asm/issues/151#event-234401047.


[#5860] Ensure removal of SslHandler not produce IllegalReferenceCoun…

…tException
Motivation:
If the user removes the SslHandler while still in the processing loop we will produce an IllegalReferenceCountException. We should stop looping when the handlerwas removed.
Modifications:
Ensure we stop looping when the handler is removed.
Result:
No more IllegalReferenceCountException.

@trustin @Scottmitch PTAL

@mosesn basically a user can remove the handler from within a future listener / channelRead(....) while the loop is still running so we need to guard against it

@normanmaurer it seems like there's a race condition where we could enter the loop, remove the handler, then do the thing we don't want to do.  I think this is unavoidable without adding a mutex.  If that's OK, then LGTM.

@mosesn no there is no race... everything happens in the same thread. The problem is that we call fireChannelRead(...) while in the loop and also notify the handshake promise while in the for loop. This means a user could remove the handler while still in the loop.

Oh, I see.  Got it, sounds good.

@normanmaurer - line 986 we use the engine, but on line 979 we potentially call user code (which could remove the handler and thus release the engine). I wonder if we should identify all calls that may invoke user code, and if the handler has been removed bail out of the SslHandler (if we may use the engine at some later point) ... WDYT?

@Scottmitch I analysed the code and I think I fixed all the usage of the engine after it was removed. PTAL again

@Scottmitch please have a final look.

@normanmaurer - line 910 we call ctx.fireExceptionCaught(e); and then on line 911 we call setHandshakeFailure(ctx, e); which will interact with the engine ... is this safe? I still think it may be more clear (although maybe more verbose) if whenever we call user code we check the "removal" / "release" condition ... as we may forget to do this check next time we add a callback to user code.

@Scottmitch I am a bit concerned about the extra branching. Let me see what I can do...

I am a bit concerned about the extra branching

agreed but lets ensure correctness first ... and if this requires spot checks it may be better to be consistent (for reasons discussed above)

@Scottmitch actually I think I just made it "safe" without spot changes. PTAL again

@normanmaurer - lgtm. in general we will have to be careful when we make changes here ... it is not obvious that we are protecting against this.

@Scottmitch agree.. That said I think there is not much we can do about it. So let me merge this one

Cherry-picked into 4.1 (39997814bfa3ea70d5f63a7c9bacdf34c962d823) and 4.0 (4920541cce66c644c27af0954509b519f7d6acdb)


Feature/ted 1278

Codecov Report
Base: 96.33% // Head: 96.33% // No change to project coverage :thumbsup:

Coverage data is based on head (e996943) compared to base (2b455af).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #451   +/-   ##
=======================================
  Coverage   96.33%   96.33%
=======================================
  Files         106      106
  Lines        5586     5586
=======================================
  Hits         5381     5381
  Misses        205      205

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Unexpected behavior in realtime events in Flutter android app

Describe the bug
Unexpected behavior in flutter android app. in some cases realtime events on update not fired. in some cases fired with wrong data
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:

create table with rls policy

create table
  public.test (
    id bigint generated by default as identity,
    some_int bigint null,
    constraint test_pkey primary key (id)
  ) tablespace pg_default;

  BEGIN;
  ALTER POLICY "Enable read access for all users" ON "public"."test" USING ((some_int >= 1));
COMMIT;

put rows with some_int - [0, 1, 2]

run flutter app with your secrets

Future<void> main() async {
  final supabase = await Supabase.initialize(
    url: supabaseUrl,
    anonKey: supabaseAnonKey,
  );
  runApp(MyApp(supabase: supabase));
}

class MyApp extends StatelessWidget {

  final Supabase supabase;
  const MyApp( {super.key, required this.supabase});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: StreamBuilder<List<int>>(
        stream: getSomeInts(),
        initialData: const [],
        builder: (context, snapshot) {
          return const FlutterLogo();
        }
      )
    );
  }

  Stream<List<int>> getSomeInts() {
    return supabase.client.from('test').stream(primaryKey: ['id']).map((event) {
      log("event.toString():$event");
      return event.map((e) => e['some_int'] as int).toList();
    });
  }
}

you will see in log
event.toString():[{id: 2, some_int: 1}, {id: 3, some_int: 2}]

change in supbase some_int from 0 -> 3
you will see in log

event.toString():[{id: 2, some_int: 1}, {id: 3, some_int: 2}, {id: 1, some_int: 3}]

change in supbase some_int from 3 -> 0
log not fires

Expected behavior
event fires

change in supbase some_int from 1 -> 3
you will see in log

event.toString():[{id: 2, some_int: 3}, {id: 3, some_int: 2}, {id: 1, some_int: 3}]

its wrong data
Expected behavior
correct data [0,3,2]
Screenshots

System information

OS: Windows 10

Additional context
flutter doctor

Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.13.6, on Microsoft Windows [Version 10.0.19045.2251]
Android Studio (version 2022.3)

version of supabse in pubspec of flutter

supabase_flutter: ^1.10.23

device

android emulator api33_x86_64

up


Created image repeat and init functions

also added initial value for range input

Manually added bc merge was being annoying


various fixes/optimizations

Changes:

typo fix landning-page-image -> landing-page-image
set font crossorigin
preload CSS stylesheet
removing lazy loading from logo (unnecessary)

Thank you @RVA2869 !


Is the Lielamar repo offline?

Describe the bug
When trying to build 2FA, Gradle can't download certain dependencies because it can't connect to the Lielamar repo. Is it offline?
How To Reproduce
Try to build 2FA without the libraries downloaded.
Expected behavior
Every artifact resolves successfully.
Screenshots and Videos
N/A
Server Information
N/A
Additional context
I found a alternative repository for the libby library: https://repo.alessiodp.com/#/releases/, when adding that locally it works. Also for the LielsUtils you can consider adding it as a jar file in a libs directory instead.

It is offline, the new version will be compiled with all the utils from it in the plugins' files


chore: add coveralls to ci

What kind of change does this PR introduce?

add coveralls to ci
based on https://github.com/marketplace/actions/coveralls-github-action

And if you want badge, this is the change for REDME.md
# GoTrue - User management for APIs

[![Coverage Status](https://coveralls.io/repos/github/supabase/gotrue/badge.svg?branch=master)](https://coveralls.io/github/supabase/gotrue?branch=master)


Decide on sensible game completion criteria.

As of writing, games only end when all players are dead thus presumably nobody is told they won.

Games end when #players ≤ 1.


where is the documentation?

There is no documentation. And there are no comments D:

Documentation is added in README


feat(pathbase): Add support for app.UsePathBase

This is a minor change to add support for PathBase.
In cases where the API needs to use app.UsePathBase("some/path"), getting Swagger UI to conform to this path with RoutePrefix was a little involved.  This change adds a PathBase property that should be set to the same value defined in app.UsePathBase().
From there, it checks the incoming request to see if path base is defined and the PathBase property is populated.
If PathBase is populated, but the incoming request path does not contain PathBase, then Swagger UI will not be displayed.
If PathBase is populated and the incoming request path contains the same PathBase value, then Swagger UI will be displayed.
If PathBase is not populated and the incoming request does not contain a PathBase value, then the normal workflow will display the Swagger UI.

Thanks for contributing - if you'd like to continue with this pull request, please rebase against the default branch to pick up our new CI. Tests would also be required.

Thanks!  I’ll get it updated


Update KnowledgeFileUploader.tsx

Issue #, if available:
Description of changes:

Removed .text and .pptx from supported file formats in Knowledge base.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thank you for your contribution!


InfluxDB destination doesn't send reading timestamp in line protocol

destinations/influxdb.py includes some logic to massage the reading timestamp into a unix timestamp, but then doesn't include that value in the payload.

Thanks for the report! Fixed in https://github.com/pimoroni/enviro/commit/d8da4d3606c492769443e274d0a99964df8c1ea5


[WebView] Expose scalesPageToFit

iOS UIWebView has a scalesPageToFit property that scales the non-mobile web content down to fit in the web view.

I've sent a PR with this feature a couple of days ago :smile:
https://github.com/facebook/react-native/pull/1631
You can already use it in the v0.7.0-rc.2 release.

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out it's new home: https://productpains.com/post/react-native/webview-expose-scalespagetofit

I think my PR got merged a few versions ago @brentvatne. Thanks!

Oh awesome, thanks for the follow up @alvaromb!


React-intl upgrade

Summary
Upgrade react-intl to the latest 4.x version.

[x] Upgrade libs
[x] Remove depricated
[ ] Convert markdown-formated messages to use XML nodes for rich formatting
[ ] Remove custom

Ticket Link
Fixes TOLINK

Rolling into a different dependencies PR.


record_response method needs a comment

A detailed comment needed for the record_response method.

Comment added to the record_response method in the controller.


trait FromContext::from return &Self

How can I implement conversion when I need to return reference?
Maybe I don’t understand something.
struct AContext {
    data: String,
}

struct BContext {
    data: String,
}

impl juniper::Context for AContext {}
impl juniper::Context for BContext {}

impl juniper::FromContext<AContext> for BContext {
    fn from(value: &AContext) -> &Self {
        // CAN'T return reference
        &BContext {
            data: value.data.clone(),
        }
    }
}

Just normal conversion trait:
pub trait From<T> {
    fn from(T) -> Self;
}

Juniper:
pub trait FromContext<T> {
    fn from(value: &T) -> &Self;
}

Happy to take a PR!

I have looked into this a bit and I think I see why we return &Self.
For most use cases you will use the same context throughout the schema. For those situations we have this implementation:
impl<T> FromContext<T> for T
where
    T: Context,
{
    fn from(value: &T) -> &Self {
        value
    }
}

If FromContext::from returned Self rather than &Self how would you implement this method? It still has to take T by reference (&T) because the executor only has a reference to the context. We also need to be able to call this method more than once.
We could require where T: Context + Clone and then implement it with value.clone(), however then we would be cloning the context all the time which doesn't seem ideal.
Because of this I think your only option is to nest your context types:
struct AContext {
    b: BContext,
    data_unique_to_a: Something,
}

struct BContext {
    data: String,
}

impl juniper::Context for AContext {}

impl juniper::Context for BContext {}

impl juniper::FromContext<AContext> for BContext {
    fn from(value: &AContext) -> &Self {
        &value.b
    }
}

This may or may not fit your use case, but it should compile.

I think you can close this issue, OR we can look for another solution, maybe someone has a more elegant solution

I think nesting is the proper solution.


editted bio

the PHP developers category also get in b/n, so now am in php devs which is wrong am in flutter devs

@daveragos Appologies got the below inconvenience but we had to make huge change and we request every PR to follow the below rule
https://github.com/chapimenge3/codenight-developers/blob/main/CONTRIBUTING.md#making-changes
Please review and update the PR accordingly

Please review and update the PR accordingly

here #56


[OP] Fix req and reserve_space in cudnn_rnn

In CuDNN V5, the cudnnRNNBackwardWeights will add the calculated gradients to the existing value. We thus need to initialize dw to 0 when kAddTo is not used. @sbodenstein, could you help review this? Also, I'm not clear about the layout of parameters for multiple stacked LSTM layers. For a single layer, I find the layout is [flatten(i2h_weight), flatten(h2h_weight), flatten(i2h_bias), flatten(h2h_bias)], but that doesn't hold for multiple LSTM layers.

@sbodenstein Another question I have is about the reserveSpace. Currently the forward and backward API calls do not share the same reserveSpace. https://github.com/dmlc/mxnet/blob/master/src/operator/cudnn_rnn-inl.h#L122-L125, https://github.com/dmlc/mxnet/blob/master/src/operator/cudnn_rnn-inl.h#L230-L232. However, in the CuDNN manual, it mentions that The data in reserveSpace must have previously been generated by cudnnRNNForwardTraining..
I've tried to stack two RNN symbols but the backpropagation doesn't give the correct result. I'm figuring out if it is caused by the reserveSpace issue.

OK, I find that the previous problem can be solved after sharing the reserveSpace.

@sxjscience: Thank you for pointing out these bugs! Indeed, I didn't notice that cudnnRNNBackwardWeights accumulates, not writes to. Good catch.

Another question I have is about the reserveSpace. Currently the forward and backward API calls do not share the same reserveSpace.

Ah, the backward and forward temp resources are not shared (despite having the same name, kTempSpace). I see that you are solving this via cudaMalloc. Isn't this banned (#2944):

Please do not use cudaMalloc & cudaFree directly anywhere in MXNet. Use Storage::Get()Alloc(size, Context::GPU()) to allocate memory to current GPU instead.

Is this possible to do with Storage::Get()Alloc(size, Context::GPU()) instead?

Also, I'm not clear about the layout of parameters for multiple stacked LSTM layers.

See the discussion in #3197. But tl;dr: If we decide to go with this design, I can supply a Python converter that splits the parameter NDArray into its component pieces.

You are right. Let me revise it using Storage::Get. Also, I find that we may need to support giving separate weights/bias. How about letting the users give just 4 parameters for each layer? i.e i2h_weight, h2h_weight, i2h_bias, h2h_bias. We can flatten and concatenate the parameters in the forwarding and use the splitting api in the backward.

@sxjscience: That looks good. I want to run a few tests on my GPU machine tomorrow, and will let you know whether everything looks good. Then this should be merged.

How about letting the users give just 4 parameters for each layer? i.e i2h_weight, h2h_weight, i2h_bias, h2h_bias.

Does eg. 'i2h_weight' contain the weights for all layers squashed together? And this number gets quite large for lstm etc (8 for lstm).

@sbodenstein I'm thinking to push all the input-to-gate and input-hidden weights into i2h_weight and hidden-to-gate and hidden-to-hidden weights into h2h_weight. And we can let the users give 4 parameters per layer, e.g, [i2h_weight0, h2h_weight0, i2h_bias0, h2h_bias0, i2h_weight1, h2h_weight1, i2h_bias1, h2h_bias1]
I've written a wrapper for RNN in the python side, which uses this type of layout. I may PR after repeating the accuracy of the NLP task.
class RNN(object):
    """High level API for constructing stacked RNN layers.

    To use a recurrent neural network, we can first create an RNN object and use the step function
    during the symbol construction.

    Currently four types of RNN are supported and all parameters per layer are grouped into 4 matrices.
    The data layout and transition rules are similar to the RNN API in CuDNN (https://developer.nvidia.com/cudnn)
    1) ReLU RNN:
        h_t = ReLU(W_i x_t + R_i h_{t-1} + b_{W_i} + b_{R_i})

        Parameters:
            W_{i2h} = W_i
            b_{i2h} = b_{W_i}
            W_{h2h} = R_i
            b_{h2h} = b_{R_i}
    2) Tanh RNN:
        h_t = tanh(W_i x_t + R_i h_{t-1} + b_{W_i} + b_{R_i})

        Parameters:
            W_{i2h} = W_i
            b_{i2h} = b_{W_i}
            W_{h2h} = R_i
            b_{h2h} = b_{R_i}
    3) LSTM:
        i_t = \sigma(W_i x_t + R_i h_{t-1} + b_{W_i} + b_{R_i})
        f_t = \sigma(W_f x_t + R_f h_{t-1} + b_{W_f} + b_{R_f})
        o_t = \sigma(W_o x_t + R_o h_{t-1} + b_{W_o} + b_{R_o})
        c^\prime_t = tanh(W_c x_t + R_c h_{t-1} + b_{W_c} + b_{R_c})
        c_t = f_t \circ c_{t-1} + i_t \circ c^\prime_t
        h_t = o_t \circ tanh(c_t)

        Parameters: (input_gate, forget_gate, new_mem, output_gate)
            W_{i2h} = [W_i, W_f, W_c, W_o]
            b_{i2h} = [b_{W_i}, b_{W_f}, b_{W_c}, b_{W_o}]
            W_{h2h} = [R_i, R_f, R_c, R_o]
            b_{h2h} = [b_{R_i}, b_{R_f}, b_{R_c}, b_{R_o}]
    4) GRU:
        i_t = \sigma(W_i x_t + R_i h_{t-1} + b_{W_i} + b_{R_i})
        r_t = \sigma(W_r x_t + R_r h_{t-1} + b_{W_r} + b_{R_r})
        h^\prime_t = tanh(W_h x_t + r_t \circ (R_h h_{t-1} + b_{R_h}) + b_{W_h})
        h_t = (1 - i_t) \circ h^\prime_t + i_t \circ h_{t-1}

        Parameters: (reset_gate, update_gate, new_mem)
            W_{i2h} = [W_r, W_i, W_h]
            b_{i2h} = [b_{W_r}, b_{W_i}, b_{W_h}]
            W_{h2h} = [R_r, R_i, R_h]
            b_{h2h} = [b_{R_r}, b_{R_i}, b_{R_h}]
    """

@sxjscience: this looks good to me. Lets merge it, as its fixing an obvious problem.
We should involve others in the design of this symbol. There are pros and cons for all options.

@sbodenstein I agree. How about opening a discussing issue?

@sxjscience: I'm just noticing now: when you allocation the GPU memory, eg
dropout_states_ = Storage::Get()->Alloc(dropout_byte_, Context::GPU());

you don't specify which GPU device the memory should be allocated on. Is this a bug?

current device will be used if unspecified

ah ok thanks.


[BEAM-4287] Fix to use the residual instead of the current restriction on process continuations.

This is a forward fix for https://github.com/apache/beam/pull/10258 to fix Dataflow VR postcommit suite.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

R: @ehudm

R: @aaltay

Run Java PreCommit

LGTM. Not merging to give release manager a chance to review and merge.

@udim should we merge this to the 2.18 branch?


DispatchMessage, SendMessage, DefWindowProc, and PostThreadMessage are all unsound.

Sending window messages in general should be unsafe.  DispatchMessage - among others - is not.
https://github.com/rodrigocfd/winsafe/blob/06b1c08f4180e3af4fe683ef972f1f488b6aa735/src/user/funcs.rs#L100-L103
While the underlying DispatchMessage does a lot of parameter checking - including forbidding most system messages that interpret wparam/lparam as pointers by returning ERROR_MESSAGE_SYNC_ONLY - it cannot do the same for WM_USER+n or WM_APP+n messages which might interpret wparam/lparam as pointers.
For example, Microsoft's own TOOLBARCLASSNAME ("ToolbarWindow32") expects wparam to be a pointer to an array for TB_ADDBUTTONSW (WM_USER+68).  While the docs recommend using SendMessage, DispatchMessage also works, and can crash / access violation if fed an invalid pointer.  Other messages could even mutate what's pointed to, causing random memory corruption instead of a nice and clean access violation.
This means that if any middleware, library, injected DLL, etc. might ever create a window containing a toolbar on one of your threads, you can use DispatchMessage to cause undefined behavior.

SendMessage and DefWindowProc have similar issues, although there are traits involved muddying things up.  Additionally, SendMessage won't reject messages with ERROR_MESSAGE_SYNC_ONLY to my knowledge.  The traits involved are "safe" - it appears you're able to implement them to use e.g. WM::SETTEXT without any unsafe, despite the possibility of passing an invalid pointer in wparam for the string text.
PostThreadMessage at least won't dispatch to a wndproc... but I promise you that third parties will inject threads into your process (game overlays, debuggers, ...), and will treat wparam/lparam as pointers for some WM_USER+N messages.

I agree about DispatchMessage. The fact it carries a MSG – which can carry any kind of wild pointer – can be interpreted as unsoundness. Although I've never seen anyone using it instead of SendMessage, nothing forbids you from doing this.
The SendMessage itself and similar ones, however, appear fine to me with the MsgSend trait bound – which gave me a hard time implementing, since I had to go through all the messages one by one, understand what they do, and then write the specific struct to each one of them.

Feel free to reopen the issue if you discuss it.

Thing is, MsgSend isn't sealed - anyone can implement it from any crate - and can implement it incorrectly and unsoundly, without a lick of unsafe:
pub struct UnsoundMessageExample;

impl MsgSend for UnsoundMessageExample {
    type RetType = isize;
    fn convert_ret(&self, v: isize) -> Self::RetType { v }
    fn as_generic_wm(&mut self) -> WndMsg {
        WndMsg {
            msg_id: winsafe::co::WM::SETTEXT,
            wparam: 0,
            lparam: "invalid".as_ptr() as isize + 0x10000,
        }
    }
}

wnd.hwnd().SendMessage(UnsoundMessageExample)

Exact offsets may cause mere text corruption, outright failure, or success.  Convincing windows to use the pointer to properly crash the program is suprisingly annoying - I wonder if the default window controls use IsBadXxxPtr (which should be called CrashProgramRandomly).
PostThreadMessage also returns immediately before the recieving thread has a chance to handle the message, even though several MsgSend implementations own values (which get dropped) or have references (to things which could be dropped now that MsgSend no longer extends their lifetime).

(I'm also unable to reopen this issue.)

It might be sufficient to:

make MsgSend an unsafe trait
make PostThreadMessage require MsgSend + Send + Copy + 'static.

Without Copy, messages could Drop data on the sending thread before the recieving thread can access the message
Without Send, messages could contain references to !Sync such as RefCell<T> or Rc<T> that isn't thread safe to read
Without 'static, messages could contain references to things that go out of scope before the message is processed

Those are great ideas. In particular, I forgot we can have an unsafe trait, which fits this situation perfectly.
Regarding PostThreadMessage, I believe the same ideas apply to PostMessage (maybe with the exception of the Copy trait), since it also returns immediately. What do you think?

Yes, I believe all the concerns of PostThreadMessage also 100% apply to PostMessage.
Also to SendMessageCallback and SendNotifyMessage, since they can return before the message is processed.
DispatchMessage, SendMessage, and SendMessageTimeout are a bit more relaxed: they at least wait for the message to be processed - even across threads - before returning/dropping.  ("Processed" here for Send* might not mean the wndproc has returned, but it has at least called ReplyMessage, and thus "should" be done with the pointers...?).  But they should perhaps still require Sync?  Although, in practice, a message containing e.g. a Rc<String> is likely only passing the string pointer to the actual wndproc, not exposing thread-unsafe refcount mutation...

I really appreciated your feedback, thank you.