-
Notifications
You must be signed in to change notification settings - Fork 287
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
conferences saving #1156
conferences saving #1156
Conversation
0f10df1
to
faf64f4
Compare
Codecov Report
@@ Coverage Diff @@
## master #1156 +/- ##
========================================
+ Coverage 83.2% 83.3% +<.1%
========================================
Files 82 82
Lines 14685 14827 +142
========================================
+ Hits 12225 12354 +129
- Misses 2460 2473 +13
Continue to review full report at Codecov.
|
ad35c68
to
4ff673e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 13 of 13 files at r2, 4 of 4 files at r3, 6 of 6 files at r4, 2 of 2 files at r5, 1 of 1 files at r6, 1 of 1 files at r7, 1 of 1 files at r8, 4 of 4 files at r9, 1 of 1 files at r10, 3 of 3 files at r11, 3 of 3 files at r12, 2 of 2 files at r13, 1 of 1 files at r14, 1 of 1 files at r15, 1 of 1 files at r16.
Reviewable status: 0 of 1 approvals obtained (waiting on @iphydf and @zugz)
toxcore/group.h, line 461 at r4 (raw file):
* * @param status Result of loading section is stored here if the section is handled. * @return true iff section handled.
document rest of the parameters?
toxcore/group.c, line 2937 at r13 (raw file):
uint32_t len = SAVED_CONF_SIZE_CONSTANT + g->title_len; bool found_self = false;
why do we need this flag? is id_equal
that expensive to call? If you want to keep this code I'd expect a comment explaining the reason for the existence of this flag.
toxcore/Messenger.c, line 3263 at r4 (raw file):
bool messenger_load_state_section(Messenger *m, const uint8_t *data, uint32_t length, uint16_t type, State_Load_Status *status) {
add assertions for non-null parameters m, data, status
?
toxcore/state.c, line 108 at r3 (raw file):
void host_to_lendian_bytes16(uint8_t *dest, uint16_t num) {
I'm not sure if we want to document preconditions for functions, but I would add an assert(dest != nullptr);
here
toxcore/state.c, line 116 at r3 (raw file):
void lendian_bytes_to_host16(uint16_t *dest, const uint8_t *lendian) {
same
toxcore/tox.c, line 607 at r6 (raw file):
{ if (data == nullptr) { return;
add a log message, because loading to a nullptr
was probably not intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 7 files at r17.
Reviewable status: 0 of 1 approvals obtained (waiting on @iphydf, @zugz, and @sudden6)
toxcore/group.h, line 461 at r4 (raw file):
Previously, sudden6 wrote…
document rest of the parameters?
Done.
toxcore/group.c, line 2937 at r13 (raw file):
Previously, sudden6 wrote…
why do we need this flag? is
id_equal
that expensive to call? If you want to keep this code I'd expect a comment explaining the reason for the existence of this flag.
Done.
toxcore/tox.c, line 607 at r6 (raw file):
Previously, sudden6 wrote…
add a log message, because loading to a
nullptr
was probably not intended?
This behaviour on null is documented in the API, so we'd best leave it.
toxcore/Messenger.c, line 3263 at r4 (raw file):
Previously, sudden6 wrote…
add assertions for non-null parameters
m, data, status
?
Generally we don't do this in non-API functions in toxcore. I'd rather conform to that style.
toxcore/state.c, line 108 at r3 (raw file):
Previously, sudden6 wrote…
I'm not sure if we want to document preconditions for functions, but I would add an
assert(dest != nullptr);
here
As above.
toxcore/state.c, line 116 at r3 (raw file):
Previously, sudden6 wrote…
same
As above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 2 of 7 files at r17, 1 of 2 files at r19, 1 of 1 files at r21, 1 of 2 files at r23, 1 of 1 files at r24.
Reviewable status: 0 of 1 approvals obtained (waiting on @iphydf)
toxcore/tox.c, line 607 at r6 (raw file):
Previously, zugz (zugz) wrote…
This behaviour on null is documented in the API, so we'd best leave it.
ok
toxcore/Messenger.c, line 3263 at r4 (raw file):
Previously, zugz (zugz) wrote…
Generally we don't do this in non-API functions in toxcore. I'd rather conform to that style.
ok then
toxcore/state.c, line 108 at r3 (raw file):
Previously, zugz (zugz) wrote…
As above.
ok
toxcore/state.c, line 116 at r3 (raw file):
Previously, zugz (zugz) wrote…
As above.
ok
Are these CI fails because of this PR or did they exist before? |
* Tuesday, 2018-10-30 at 11:13 -0700 - sudden6 <[email protected]>:
Are these CI fails because of this PR or did they exist before?
The tsan failure is a long-standing problem. The Cirrus failure was due
to a complaint about this PR (it didn't like a variable being used only
for an assertion) which I've now fixed. At the time of writing it's
failing again, but that's just because the tcp test intermittently fails
(another long-standing problem).
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 5 of 7 files at r17.
Reviewable status: 0 of 1 approvals obtained (waiting on @iphydf)
This change creates groups on startup of Core. We need this once TokTok/c-toxcore#1156 is merged to load existing groups.
This change creates groups on startup of Core. We need this once TokTok/c-toxcore#1156 is merged to load existing groups.
This change creates groups on startup of Core. We need this once TokTok/c-toxcore#1156 is merged to load existing groups.
This change creates groups on startup of Core. We need this once TokTok/c-toxcore#1156 is merged to load existing groups.
* Prepare for TokTok/c-toxcore#1156 to be merged * Restore known groupchats from chatlist
@iphydf Your lgtm seems to block this PR, what is your current state with this? |
docs/minpgc.md
Outdated
on start-up (e.g. starting windows for them), and by not automatically killing | ||
groups on closing the client. | ||
Clients needs to support this by understanding that groups may exist on | ||
start-up. Clients should call tox\_conference\_get\_chatlist to obtain them. A |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use `backticks`
for symbol names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
toxcore/Messenger.h
Outdated
@@ -796,6 +796,9 @@ uint8_t *messenger_save(const Messenger *m, uint8_t *data); | |||
|
|||
/* Load a state section. | |||
* | |||
* @param data Data to load |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add "." at the end (or remove it from all the others).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
toxcore/group.c
Outdated
return false; | ||
} | ||
|
||
return (group_kill_peer_send(g_c, groupnumber, g->peer_number) == 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove extra () around returned expression.
* add global friend_connection status callback, used for group rejoining * stop leaving groups on killing tox
This change is