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
sudden6
left a comment
There was a problem hiding this comment.
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?
zugz
left a comment
There was a problem hiding this comment.
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_equalthat 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
nullptrwas 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.
sudden6
left a comment
There was a problem hiding this comment.
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 <notifications@github.com>:
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).
|
sudden6
left a comment
There was a problem hiding this comment.
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? |
There was a problem hiding this comment.
Use `backticks` for symbol names.
There was a problem hiding this comment.
Add "." at the end (or remove it from all the others).
There was a problem hiding this comment.
Remove extra () around returned expression.
* add global friend_connection status callback, used for group rejoining * stop leaving groups on killing tox
This change is