-
Notifications
You must be signed in to change notification settings - Fork 57
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
chore: generic change to reduce the number of compilation warnings #2696
Conversation
You can find the image built from this PR at
Built from dc59888 |
You can find the image built from this PR at
Built from dc59888 |
0735440
to
c2a6bb3
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.
Oh that's reaally nice! Thanks so much!
Just added a couple questions
@@ -312,13 +311,13 @@ proc startMaintainingSubscriptions(wf: WakuFilter, interval: Duration) = | |||
|
|||
wf.maintenanceTask = setTimer(Moment.fromNow(interval), maintainSubs) | |||
|
|||
method start*(wf: WakuFilter) {.async.} = | |||
method start*(wf: WakuFilter) {.async, base.} = |
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.
just to understand, why do we need the base
pragma?
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.
For proper inheritance I think?
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.
Thanks for the comments @gabrielmer , @SionoiS !
This change actually comes from a compiler warning, where it stated that it was deprecated to use non-base methods (I can't remember the precise message.)
waku/waku_filter_v2/client.nim
Outdated
try: | ||
await connection.writeLP(filterSubscribeRequest.encode().buffer) | ||
|
||
let respBuf = await connection.readLp(DefaultMaxSubscribeResponseSize) | ||
let respDecodeRes = FilterSubscribeResponse.decode(respBuf) | ||
if respDecodeRes.isErr(): | ||
trace "Failed to decode filter subscribe response", servicePeer | ||
waku_filter_errors.inc(labelValues = [decodeRpcFailure]) | ||
return err(FilterSubscribeError.badResponse(decodeRpcFailure)) | ||
|
||
let response = respDecodeRes.get() | ||
|
||
if response.requestId != filterSubscribeRequest.requestId: | ||
trace "Filter subscribe response requestId mismatch", servicePeer, response | ||
waku_filter_errors.inc(labelValues = [requestIdMismatch]) | ||
return err(FilterSubscribeError.badResponse(requestIdMismatch)) | ||
|
||
if response.statusCode != 200: | ||
trace "Filter subscribe error response", servicePeer, response | ||
waku_filter_errors.inc(labelValues = [errorResponse]) | ||
let cause = | ||
if response.statusDesc.isSome(): | ||
response.statusDesc.get() | ||
else: | ||
"filter subscribe error" | ||
return err(FilterSubscribeError.parse(response.statusCode, cause = cause)) | ||
except CatchableError: | ||
let errMsg = "exception in waku_filter_v2 client: " & getCurrentExceptionMsg() | ||
trace "exception in waku_filter_v2 client", error = getCurrentExceptionMsg() | ||
waku_filter_errors.inc(labelValues = [errMsg]) | ||
return err(FilterSubscribeError.badResponse(errMsg)) |
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.
wouldn't it be better for the try
block to be more scoped?
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.
wouldn't it be better for the
try
block to be more scoped?
Yes, you are absolutely right! I tried to apply that in 06546bb
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.
Such a good clean-up. Amazing!
@@ -31,7 +31,7 @@ import | |||
../testlib/wakucore, | |||
../testlib/wakunode | |||
|
|||
procSuite "WakuNode - Store": | |||
procSuite "WakuNode - Store Legacy": |
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.
ah thanks I totally forgot about renaming tests!
try: | ||
await node.wakuFilter.start() | ||
except CatchableError: | ||
error "failed to start wakuFilter", error = getCurrentExceptionMsg() |
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.
You don't like the catch:
macro?
try: | |
await node.wakuFilter.start() | |
except CatchableError: | |
error "failed to start wakuFilter", error = getCurrentExceptionMsg() | |
let catchable = catch: await node.wakuFilter.start() | |
if catchable.isErr(): | |
error "failed to start wakuFilter", error = catchable.error.msg |
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.
@SionoiS We would need better a valueOrCatch macro... hm, due I don't think catch works together with valueOr template.
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.
@SionoiS We would need better a valueOrCatch macro... hm, due I don't think catch works together with valueOr template.
Yes it's unfortunate, otherwise this would be possible
(catch: await node.wakuFilter.start()).isOkOr:
error "failed to start wakuFilter", error = error.msg
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.
@SionoiS We would need better a valueOrCatch macro... hm, due I don't think catch works together with valueOr template.
Yes it's unfortunate, otherwise this would be possible
(catch: await node.wakuFilter.start()).isOkOr: error "failed to start wakuFilter", error = error.msg
Well we can add! I may do it somewhere.
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.
You don't like the
catch:
macro?
Well, I "don't like" maybe because I don't fully understand it xD
To me, it sounds a bit more verbose the traditional approach but I'll give it another glance ;P
@@ -312,13 +311,13 @@ proc startMaintainingSubscriptions(wf: WakuFilter, interval: Duration) = | |||
|
|||
wf.maintenanceTask = setTimer(Moment.fromNow(interval), maintainSubs) | |||
|
|||
method start*(wf: WakuFilter) {.async.} = | |||
method start*(wf: WakuFilter) {.async, base.} = |
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.
For proper inheritance I think?
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.
This is Spartaaa!!!! ... I would say so after our greek tour, but I better say: It is amazing and very needed PR. Special thank for the depricate net lib warning elimination!
try: | ||
await node.wakuFilter.start() | ||
except CatchableError: | ||
error "failed to start wakuFilter", error = getCurrentExceptionMsg() |
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.
@SionoiS We would need better a valueOrCatch macro... hm, due I don't think catch works together with valueOr template.
06546bb
to
13921f1
Compare
Description
Simple but long (sorry for that) PR that aims to reduce the number of compilation warnings.
async: (raises:[..])
pragmare
is deprecated