Loss drives below zero for self-supervised depth estimation and training fails

Hi, unfortunately we don't have a code release for the monocular depth estimation experiments of the paper (though that code is in TF anyways so it likely isn't what you're looking for). I believe that there are Pytorch implementations of SFMLearner on Github, and using this loss should be straightforward: just delete the existing multiscale photometric loss and the smoothness term and add in AdaptiveImageLossFunction on the full-res image with:
scale_lo=0.01
scale_init=0.01
and default settings for the rest and it should work (you may need to fiddle with the value of wavelet_scale_base).
Do you suggest any other changes apart from this? I am actually testing this :)
If you call the loss in general.py, it should never go negative. The loss produced by adaptive.py is actually a negative log-likelihood, so it can go negative depending on the value of the scale parameter. Could you kindly elaborate on this? Doesn't the -log(y) yield positive values.
Example: NLL: -ln(0.5) = 0.69
How does it drive negative or do we consider the abs(l1) finally?
After adding your loss it just drives it below 0 and the training fails.
Tested your loss in YUV space on monodepth2 project.
AdaptiveImageLossFunction((3, 640, 192), torch.float32, "cuda:0", color_space='YUV', scale_lo=0.01, scale_init=0.01)
Note: Alpha and Scale are added to the optimizers. I have skipped this part here.
These were the initial settings used. Actually, the scale of final loss of monodepth with L1 is around 0.07 to 0.02 and performs well.
Test 1
Final loss = 0.85 Adaptive Loss + 0.15 SSIM + 0.001 Smoothness
Test 2: Tried different weightage as well. This setting would fail after few epochs as well.
Final loss = 0.15 Adaptive Loss + 0.85 SSIM + 0.001 Smoothness

Cool, I've gotten many requests for this SFMLearner result in Pytorch but I
don't have cycles to take care of it myself, so I'm happy to help.
Here's the part of the main paper that describes important changes:
We keep our loss’s scale c fixed to 0.01, thereby matching the fixed scale
assumption of the baseline model and roughly matching the shape of its L1
loss (Eq. 15). To avoid exploding gradients we multiply the loss being
minimized by c, thereby bounding gradient magnitudes by residual magnitudes
(Eq. 14).
Section H of the appendix goes through all the changes that were made to
the codebase:

Our unsupervised monocular depth estimation experiments use the code from
https://github.com/tinghuiz/ https://github.com/tinghuiz/ SfMLearner,
which appears to correspond to the “Ours (w/o explainability)” model from
Table 1 of [42]. The only changes we made to this code were: replacing its
loss function with our own, reducing the number of training iterations from
200000 to 100000 (training converges fast when using our loss function) and
disabling the smoothness term and multi-scale side predictions used by
[42], as neither yielded much benefit when combined with our new loss
function and they complicated experimentation by introducing
hyperparameters. Because the reconstruction loss in [42] is the sum of the
means of the losses imposed at each scale in a D-level pyramid of side
predictions, we use a D level normalized wavelet decomposition (wherein
images in [0, 1] result in wavelet coefficients in [0, 1]) and then scale
each coefficient’s loss by 2 d , where d is the coefficients level.*

So with this, looking at the code you sent me, It looks like you should do:
0.01 * AdaptiveImageLossFunction((3, 640, 192), torch.float32, "cuda:0",
color_space='YUV', scale_lo=0.01, scale_init=0.01,
wavelet_scale_base=$SOMETHING)
And then just set the final loss to be 100% this adaptive loss (no SSIM or
smoothness). I think wavelet_scale_base should be 2, but the interface for
that experiment isn't the same as what is here so try [0.5, 1, 2]. And be
sure to delete the secondary branches of the code that evaluate this loss
at multiple scales, you should only need to evaluate it at the finest scale.
On Mon, Mar 9, 2020 at 3:44 AM Varun Ravikumar<EMAIL_ADDRESS>wrote:

Hi, unfortunately we don't have a code release for the monocular depth
estimation experiments of the paper (though that code is in TF anyways so
it likely isn't what you're looking for). I believe that there are Pytorch
implementations of SFMLearner on Github, and using this loss should be
straightforward: just delete the existing multiscale photometric loss and
the smoothness term and add in AdaptiveImageLossFunction on the full-res
image with:
scale_lo=0.01
scale_init=0.01
and default settings for the rest and it should work (you may need to
fiddle with the value of wavelet_scale_base).
Do you suggest any other changes apart from this? I am actually testing
this :)
Tested your loss in YUV space on monodepth2 project.
AdaptiveImageLossFunction((3, 640, 192), torch.float32, "cuda:0",
color_space='YUV', scale_lo=0.01, scale_init=0.01)
These were the initial setting used. Actually, the scale of final loss of
monodepth with L1 is around 0.02. After adding your loss it just drives it
below 0.
Final loss = 0.85 Adaptive Loss + 0.15 SSIM + 0.01 Smoothness
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jonbarron/robust_loss_pytorch/issues/16?email_source=notifications&email_token=AAGZFNQEYEXADKKEJG3TDFDRGTCANA5CNFSM4LEF3YD2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ITQXSCA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGZFNSV2JT4IWW3LL4ZDW3RGTCANANCNFSM4LEF3YDQ
.

Thanks for the tips. Just one small note, why do we need to remove SSIM and Smoothness loss? Isn"t structural similarity and smoothing of the depth quite important?

I don't remember the TF SFMLearner code having an SSIM loss, so I'm not
sure what to make of that. But in my experiments, performance was nearly
identical / slightly better without a smoothness loss --- it only adds
value if the loss being used as the data term is falling short.
On Tue, Mar 10, 2020 at 12:07 PM Varun Ravikumar<EMAIL_ADDRESS>wrote:

Thanks for the tips. Just one small note, why do we need to remove SSIM
and Smoothness loss? Isn"t structural similarity and smoothing of the depth
quite important?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jonbarron/robust_loss_pytorch/issues/16?email_source=notifications&email_token=AAGZFNXJJ5LYRVDGQOORU2LRG2FYZA5CNFSM4LEF3YD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOMXX4A#issuecomment-597261296,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGZFNRBN666DFBDZVM2DITRG2FYZANCNFSM4LEF3YDQ
.

I will try it out. Will share my findings here. I think you missed this one!
If you call the loss in general.py, it should never go negative. The loss produced by adaptive.py is actually a negative log-likelihood, so it can go negative depending on the value of the scale parameter. Could you kindly elaborate on this? Doesn't the -log(y) yield positive values.
Example: NLL: -ln(0.5) = 0.69
How does it drive negative or do we consider the abs(l1) finally?

There's no reason for NLLs to be non-negative. If a likelihood is > 1, the
corresponding NLL will be < 0. Basic distributions like Gaussians do this,
if you set sigma to a small value. This will only happen in this code when
the scale parameter is small, but it should not be any cause for concern.
On Tue, Mar 10, 2020 at 12:41 PM Varun Ravikumar<EMAIL_ADDRESS>wrote:

I will try it out. Will share my findings here. I think you missed this
one!
If you call the loss in general.py, it should never go negative. The loss
produced by adaptive.py is actually a negative log-likelihood, so it can go
negative depending on the value of the scale parameter. Could you kindly
elaborate on this? Doesn't the -log(y) yield positive values.
Example: NLL: -ln(0.5) = 0.69
How does it drive negative or do we consider the abs(l1) finally?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jonbarron/robust_loss_pytorch/issues/16?email_source=notifications&email_token=AAGZFNXTLI6OAUS7CO4YXNLRG2JUXA5CNFSM4LEF3YD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOM3QHI#issuecomment-597276701,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGZFNT4ESZVZLQWKPRCDSLRG2JUXANCNFSM4LEF3YDQ
.

be sure to delete the secondary branches of the code that evaluate this loss
at multiple scales, you should only need to evaluate it at the finest scale.
In monodepth2 all the lower scales are upsampled to the highest scale and photometric error is applied on them.
Instead of computing the photometric error on the ambiguous low-resolution images, we first upsample the lower resolution depth maps (from the intermediate layers)
to the input image resolution, and then reproject, resample, and compute the error pe at this higher input resolution. This procedure is similar to matching patches, as low-resolution disparity values will be responsible for warping an entire ‘patch’ of pixels in the high resolution image. This effectively constrains the depth maps at each scale to work toward the same objective i.e. reconstructing the high resolution input target image as accurately as possible.

Oh sorry, the advice I was giving was for SFMLearner, which is the codebase
I did my experiments for the paper with. That advice may not apply to
Monodepth2, though I'd still try just imposing a single loss on the finest
scale.
On Tue, Mar 10, 2020 at 2:54 PM Varun Ravikumar<EMAIL_ADDRESS>wrote:

be sure to delete the secondary branches of the code that evaluate this
loss
at multiple scales, you should only need to evaluate it at the finest
scale.
In monodepth2 all the lower scales are upsampled to the highest scale and
photometric error is applied on them.
Instead of computing the photometric error on the ambiguous low-resolution
images, we first upsample the lower resolution depth maps (from the
intermediate layers)
to the input image resolution, and then reproject, resample, and compute
the error pe at this higher input resolution. This procedure is similar to
matching patches, as low-resolution disparity values will be responsible
for warping an entire ‘patch’ of pixels in the high resolution image. This
effectively constrains the depth maps at each scale to work toward the same
objective i.e. reconstructing the high resolution input target image as
accurately as possible.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jonbarron/robust_loss_pytorch/issues/16?email_source=notifications&email_token=AAGZFNUETLNXIDD64ACALKLRG2ZLHA5CNFSM4LEF3YD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEONKENQ#issuecomment-597336630,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGZFNVAK34A4JXMUAIFRFTRG2ZLHANCNFSM4LEF3YDQ
.

There's no reason for NLLs to be non-negative. If a likelihood is > 1, the corresponding NLL will be < 0. Basic distributions like Gaussians do this, if you set sigma to a small value. This will only happen in this code when the scale parameter is small, but it should not be any cause for concern.
…
On Tue, Mar 10, 2020 at 12:41 PM Varun Ravikumar @.***> wrote: I will try it out. Will share my findings here. I think you missed this one! If you call the loss in general.py, it should never go negative. The loss produced by adaptive.py is actually a negative log-likelihood, so it can go negative depending on the value of the scale parameter. Could you kindly elaborate on this? Doesn't the -log(y) yield positive values. Example: NLL: -ln(0.5) = 0.69 How does it drive negative or do we consider the abs(l1) finally? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=AAGZFNXTLI6OAUS7CO4YXNLRG2JUXA5CNFSM4LEF3YD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOM3QHI#issuecomment-597276701>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGZFNT4ESZVZLQWKPRCDSLRG2JUXANCNFSM4LEF3YDQ .

So there is no need to take abs(AdaptiveImageLoss) when loss goes negative?
I use this for HITNet.(https://github.com/google-research/google-research/tree/master/hitnet)
And set:
self.robust = AdaptiveImageLossFunction((960, 320, 1), float_dtype=torch.float32, device=0).

There's no reason for NLLs to be non-negative. If a likelihood is > 1, the corresponding NLL will be < 0. Basic distributions like Gaussians do this, if you set sigma to a small value. This will only happen in this code when the scale parameter is small, but it should not be any cause for concern.
…
On Tue, Mar 10, 2020 at 12:41 PM Varun Ravikumar @.***> wrote: I will try it out. Will share my findings here. I think you missed this one! If you call the loss in general.py, it should never go negative. The loss produced by adaptive.py is actually a negative log-likelihood, so it can go negative depending on the value of the scale parameter. Could you kindly elaborate on this? Doesn't the -log(y) yield positive values. Example: NLL: -ln(0.5) = 0.69 How does it drive negative or do we consider the abs(l1) finally? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=AAGZFNXTLI6OAUS7CO4YXNLRG2JUXA5CNFSM4LEF3YD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOM3QHI#issuecomment-597276701>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGZFNT4ESZVZLQWKPRCDSLRG2JUXANCNFSM4LEF3YDQ .

So there is no need to take abs(AdaptiveImageLoss) when loss goes negative?
I use this for HITNet.(https://github.com/google-research/google-research/tree/master/hitnet)
And set:
self.robust = AdaptiveImageLossFunction((960, 320, 1), float_dtype=torch.float32, device=0).

Do not know if this snippet helps you or not. I used it for depth estimation. For more information you can look it up here: SynDistNet
self.adaptive_image_loss = AdaptiveImageLossFunction((3, args.input_width, args.input_height),
                                                                                torch.float32, args.device, color_space='YUV',
                                                                                scale_lo=0.01, scale_init=0.01)

Do not know if this snippet helps you or not. I used it for depth estimation. For more information you can look it up here: SynDistNet
self.adaptive_image_loss = AdaptiveImageLossFunction((3, args.input_width, args.input_height),
                                                                                torch.float32, args.device, color_space='YUV',
                                                                                scale_lo=0.01, scale_init=0.01)

@yellowYuga Do not know if this snippet helps you or not. I used it for depth estimation. For more information you can look it up here: SynDistNet
from robust_loss_pytorch import AdaptiveImageLossFunction
self.adaptive_image_loss = AdaptiveImageLossFunction((3, args.input_width, args.input_height),
                                                     torch.float32, args.device, color_space='YUV',
                                                     scale_lo=0.01, scale_init=0.01)
l1_loss = (0.01 * self.adaptive_image_loss.lossfun(torch.abs(target - predicted))).mean(1, True)

In my experiment，the residual between predicted and target doesn't take abs.That means:
loss = self.robust_loss.lossfun(target - predicted).mean()
Is that correct？
（BTW,when I tested it in fitting curve y=x^2,lossfun(target-pred) is better than lossfun(abs(target-pred))）

@yellowYuga Do not know if this snippet helps you or not. I used it for depth estimation. For more information you can look it up here: SynDistNet
from robust_loss_pytorch import AdaptiveImageLossFunction
self.adaptive_image_loss = AdaptiveImageLossFunction((3, args.input_width, args.input_height),
                                                     torch.float32, args.device, color_space='YUV',
                                                     scale_lo=0.01, scale_init=0.01)
l1_loss = (0.01 * self.adaptive_image_loss.lossfun(torch.abs(target - predicted))).mean(1, True)

In my experiment，the residual between predicted and target doesn't take abs.That means:
loss = self.robust_loss.lossfun(target - predicted).mean()
Is that correct？
（BTW,when I tested it in fitting curve y=x^2,lossfun(target-pred) is better than lossfun(abs(target-pred))）

Do not minimize abs(AdaptiveImageLoss), it's totally normal for the loss to go below zero, and adding an abs() will completely break it. Adding an abs() to the input residual passed to the loss will have no effect, so you can do it if you want, but I don't see why you would (the residual is immediately squared in the loss function.

Do not minimize abs(AdaptiveImageLoss), it's totally normal for the loss to go below zero, and adding an abs() will completely break it. Adding an abs() to the input residual passed to the loss will have no effect, so you can do it if you want, but I don't see why you would (the residual is immediately squared in the loss function.

self.robust_loss.lossfun(target - predicted).mean() is correct usage of the loss function.

self.robust_loss.lossfun(target - predicted).mean() is correct usage of the loss function.


PVS Studio fixes for XAudio2Samples

Some fixes in XAudio2Samples from PVS Studio static analyzer.
Product page: https://www.viva64.com/en/pvs-studio/
How to use for free: https://www.viva64.com/en/b/0600/

Closed as too hard to follow. Will split to small fixes if have time.


fix: abort freedraw line if second touch is detected

See also: #1065
Placing a second finger on the canvas while drawing a freedraw shape results in a spike and the termination of the freedraw editing. Under normal conditions (i.e. drawing with your finger) this should not happen. This typically happens when using a pen, clicking the pen tool for the first time, and touching the canvas with your palm before touching it with the pen. In this scenario penMode does not activate before receiving the multi-touch input, resulting in the unwanted line.
The easiest way to simulate this situation is by touching the freedraw tool (i.e. not in penMode), then touching the canvas with one finger, and then, while the first finger stays on touching the canvas, touching the canvas with a second finger.

This typically happens when using a pen, clicking the pen tool for the first time, and touching the canvas with your palm before touching it with the pen. In this scenario penMode does not activate before receiving the multi-touch input, resulting in the unwanted line.

What's the scenario there. If you the touch is a mistake before you touch with a stylus, that's a different case, no?
In any case, we should ship this, but:

Maybe we shouldn't limit based on size/points, but always discard the element on second touch event?
I'm actually thinking the use case should be to solve pinch zooming creating freedraw/line elements, hence upon discarding the element we shouldn't return so as to allow for zooming. https://github.com/excalidraw/excalidraw/issues/5176
extend this to arrow/line tools, at the very least. But to some extent it affects other tools, too. Line/arrow and freedraw are affected the worst, though.

What's the scenario there. If you the touch is a mistake before you touch with a stylus, that's a different case, no?

Yes, this is the case. Not so much by mistake, but as you place your palm on the screen to draw often your hand will touch the screen before the pen, resulting in an initial spike.

Maybe we shouldn't limit based on size/points, but always discard the element on second touch event?

That was my first solution, I added the size limitation later because I thought that it may happen that you are drawing a longer, more intricate freedraw line with your finger, holding the tablet with your other hand, which accidently touches the screen when you have already drawn a longer stretch of the line. This might be a very theoretical situation, I am ok to simply discard the freedraw if a second finger touches the screen.

I'm actually thinking the use case should be to solve pinch zooming creating freedraw/line elements, hence upon discarding the element we shouldn't return so as to allow for zooming. https://github.com/excalidraw/excalidraw/issues/5176

The bigger issue with pinch zooming is not the unwanted lines, since once you are in penmode that is no longer an issue, but the accidental small zoom effects as you move your palm on the screen. Some noise filtering (i.e. discard small pinch zoom movements if in pen mode would help with that, but I think that should be handled in a different PR.

extend this to arrow/line tools, at the very least. But to some extent it affects other tools, too. Line/arrow and freedraw are affected the worst, though.

Arrows and lines are a different case. Currently if you start a line with two fingers you will enter multipoint edit mode which is a great feature (albeit I am not sure it is intended). The issue with this feature today, is that depending on the relative position of the first and second touch, sometimes this gesture works as expected, and sometimes it doesn't. I think arrows and lines should be handled in a separate PR as they require a different logic and more thinking.

@dwelle

https://github.com/excalidraw/excalidraw/issues/5176

I removed the return statement, this way you can pinch zoom with the freedraw tool active and it won't draw a line. Checking for

Maybe we shouldn't limit based on size/points, but always discard the element on second touch event?

The size limit on number of points ensures that if you are drawing a freedraw element and switch to pinch zooming without first picking up your first finger, the element you've drawn until that point will not be deleted and the zoom will be executed.

What's the scenario there. If you the touch is a mistake before you touch with a stylus, that's a different case, no?

Yes, this is the case. Not so much by mistake, but as you place your palm on the screen to draw often your hand will touch the screen before the pen, resulting in an initial spike.

That's for when you pick the tool with your finger instead of the stylus I presume. I tend to use stylus for that so it doesn't happen to me, but I get the issue.

Maybe we shouldn't limit based on size/points, but always discard the element on second touch event?

That was my first solution, I added the size limitation later because I thought that it may happen that you are drawing a longer, more intricate freedraw line with your finger, holding the tablet with your other hand, which accidently touches the screen when you have already drawn a longer stretch of the line. This might be a very theoretical situation, I am ok to simply discard the freedraw if a second finger touches the screen.
[...]
The size limit on number of points ensures that if you are drawing a freedraw element and switch to pinch zooming without first picking up your first finger, the element you've drawn until that point will not be deleted and the zoom will be executed.

Those do seem edge-casey, but ok, let's keep the heuristic for now and see how it works in practice. If it's not working great, there are other heuristics we can try, such as checking if the points are a small cluster suggesting you've been moving your finger in place a lot before placing the 2nd finger. We can also add a time element (if below certain time since creation, discard).

I'm actually thinking the use case should be to solve pinch zooming creating freedraw/line elements, hence upon discarding the element we shouldn't return so as to allow for zooming. #5176

The bigger issue with pinch zooming is not the unwanted lines, since once you are in penmode that is no longer an issue, but the accidental small zoom effects as you move your palm on the screen. Some noise filtering (i.e. discard small pinch zoom movements if in pen mode would help with that, but I think that should be handled in a different PR.

My remark wasn't related to penMode per se, but to the linked issue of drawing your hand and then panning/zooming around while the freedraw/line/arrow tool is still active.

extend this to arrow/line tools, at the very least. But to some extent it affects other tools, too. Line/arrow and freedraw are affected the worst, though.

Arrows and lines are a different case. Currently if you start a line with two fingers you will enter multipoint edit mode which is a great feature (albeit I am not sure it is intended). The issue with this feature today, is that depending on the relative position of the first and second touch, sometimes this gesture works as expected, and sometimes it doesn't. I think arrows and lines should be handled in a separate PR as they require a different logic and more thinking.

That behavior isn't intended. The whole multi-point creation flow on mobile is very bad and will need to be reworked, so we can leave that for another PR then.

I moved this.updateGestureOnPointerDown(event); to the beginning of handleCanvasPointerDown to allow pinch zoom with the freedraw tool active. I'm not sure how to test if moving updateGestureOnPointerDown to earlier in the code has any unwanted side effects.

Can't either, but I think it's safe to keep the pointer-related statements that were above the updateGestureOnPointerDown() in the same order, so let's move them above the new updateGestureOnPointerDown() position as well.

@dwelle are we good to proceed with this? I've been using this modification for a few days now and have experienced no side effects.

clicking the pen tool for the first time, and touching the canvas with your palm before touching it with the pen.

So I'm now actually checking the iPad behavior, and this PR doesn't solve the above case.
Not only do we not check for pen event:
https://github.com/excalidraw/excalidraw/pull/6440/files#diff-86963609bec6fda3d34233676d5ae33f6aa4b9bbe2758a10cd4863b704b37093R3511
But it seems that we may not even be able to handle it as the pen event isn't registered if the finger is still touching the canvas.

I'll merge this and we can improve in a follow up PR. Thanks! 🚀


Alt -/+ in terminal no longer changes text size

This was previously the official way to do it: http://help.learn.co/the-learn-ide/ide-settings/changing-the-font-size
Can these commands be hooked back up? Or are there new commands?

I was using the wrong commands. Per the article, the commands for Mac are cmd + +/-. That works fine.


Update benchmark.txt

Description
Please include a summary of the change and which is fixed.

Add A
Fix B

How has this been tested?
Please describe the tests that you ran to verify your changes.

[ ] UnitTest
[ ] Benchmark

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 90.62%. Comparing base (45e0643) to head (06bd8a0).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #598      +/-   ##
==========================================
- Coverage   90.63%   90.62%   -0.01%
==========================================
  Files         129      129
  Lines        4751     4779      +28
  Branches      776      782       +6
==========================================
+ Hits         4306     4331      +25
- Misses        288      291       +3
  Partials      157      157

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Remove unnecessary //external:extdir filegroup so that bazel build //... works again [phab:D281]

Created by shahms at 2015-05-23 00:11:23:
Remove unnecessary //external:extdir filegroup so that bazel build //... works again

zarko wrote at 2015-05-23 00:26:19:
I'm not able to reproduce this now but remember seeing it in the past. We've tried a bazel clean --expunge to no avail. Since the extdir stuff is inside the Bazel distribution, I'm suspicious about removing it, but there seems like there's something else going wrong.

schroederc wrote at 2015-05-26 15:32:56:
You need an new version of Bazel.  They made a breaking change in https://github.com/google/bazel/commit/2221860f50ccf2b77065f5e9dd02714706dbfb10.

schroederc required changes at 2015-05-26 15:33:08

shahms wrote at 2015-05-26 16:15:35:
Thanks, Cody! Sorry I missed the update.  Now to figure out how to abandon this diff ...

shahms abandoned revision at 2015-05-26 16:15:51


ExtraData configuration disappears sometimes after setting it via grinder

see

#137

closing as a sideffect of

#137


Getting an error of Could not allocate Tx

I am trying to use the sample ESP code with my ESp32 board. Using Arduino IDE.
I am using Steve as my CMS.
I am facing this error can any one please help me with this ?
[main] Begin Transaction with idTag<PHONE_NUMBER>ABCD
[MO] ERROR (Connector.cpp:597): could not allocate Tx
[main] No transaction initiated

This is my complete Arduino Code
// matth-x/MicroOcpp
// Copyright Matthias Akstaller 2019 - 2023
// MIT License

#include <Arduino.h>
#if defined(ESP8266)
#include <ESP8266WiFi.h>
#include <ESP8266WiFiMulti.h>
ESP8266WiFiMulti WiFiMulti;
#elif defined(ESP32)
#include <WiFi.h>
#else
#error only ESP32 or ESP8266 supported at the moment
#endif

#include <MicroOcpp.h>

#define STASSID "Avi"
#define STAPSK  "12345678"

//#define OCPP_BACKEND_URL   "ws://echo.websocket.events"
//#define OCPP_CHARGE_BOX_ID ""

//
//  Settings which worked for my SteVe instance:

#define OCPP_BACKEND_URL   "ws://<IP_ADDRESS>:8180/steve/websocket/CentralSystemService/"
#define OCPP_CHARGE_BOX_ID "esp-charger"

void setup() {

    /*
     * Initialize Serial and WiFi
     */

    Serial.begin(115200);

    Serial.print(F("[main] Wait for WiFi: "));

#if defined(ESP8266)
    WiFiMulti.addAP(STASSID, STAPSK);
    while (WiFiMulti.run() != WL_CONNECTED) {
        Serial.print('.');
        delay(1000);
    }
#elif defined(ESP32)
    WiFi.begin(STASSID, STAPSK);
    while (!WiFi.isConnected()) {
        Serial.print('.');
        delay(1000);
    }
#else
#error only ESP32 or ESP8266 supported at the moment
#endif

    Serial.println(F(" connected!"));

    /*
     * Initialize the OCPP library
     */
    mocpp_initialize(OCPP_BACKEND_URL, OCPP_CHARGE_BOX_ID, "My Charging Station", "My company name");

    /*
     * Integrate OCPP functionality. You can leave out the following part if your EVSE doesn't need it.
     */
    setEnergyMeterInput([]() {
        //take the energy register of the main electricity meter and return the value in watt-hours
        return 0.f;
    });

    setSmartChargingCurrentOutput([](float limit) {
        //set the SAE J1772 Control Pilot value here
        Serial.printf("[main] Smart Charging allows maximum charge rate: %.0f\n", limit);
    });

    setConnectorPluggedInput([]() {
        //return true if an EV is plugged to this EVSE
        return false;
    });

    //... see MicroOcpp.h for more settings
}

void loop() {

    /*
     * Do all OCPP stuff (process WebSocket input, send recorded meter values to Central System, etc.)
     */
    mocpp_loop();

    /*
     * Energize EV plug if OCPP transaction is up and running
     */
    if (ocppPermitsCharge()) {
        //OCPP set up and transaction running. Energize the EV plug here
        Serial.println("permit");
    } else {
        //No transaction running at the moment. De-energize EV plug
    }

    /*
     * Use NFC reader to start and stop transactions
     */
    if (/* RFID chip detected? */ true) {
        String idTag = "0123456789ABCD"; //e.g. idTag = RFID.readIdTag();

        if (!getTransaction()) {
            //no transaction running or preparing. Begin a new transaction
            Serial.printf("[main] Begin Transaction with idTag %s\n", idTag.c_str());

            /*
             * Begin Transaction. The OCPP lib will prepare transaction by checking the Authorization
             * and listen to the ConnectorPlugged Input. When the Authorization succeeds and an EV
             * is plugged, the OCPP lib will send the StartTransaction
             */
            auto ret = beginTransaction(idTag.c_str());

            if (ret) {
                Serial.println(F("[main] Transaction initiated. OCPP lib will send a StartTransaction when" \
                                 "ConnectorPlugged Input becomes true and if the Authorization succeeds"));
            } else {
                Serial.println(F("[main] No transaction initiated"));
            }

        } else {
            //Transaction already initiated. Check if to stop current Tx by RFID card
            if (idTag.equals(getTransactionIdTag())) {
                //card matches -> user can stop Tx
                Serial.println(F("[main] End transaction by RFID card"));

                endTransaction(idTag.c_str());
            } else {
                Serial.println(F("[main] Cannot end transaction by RFID card (different card?)"));
            }
        }
    }

    //... see MicroOcpp.h for more possibilities
}

@matth-x I am facing this as well after solving #244 (likely unrelated). Here are my logs:

Yes, this is related. To give a little explanation: MicroOcpp has a transaction journal, i.e. it keeps track of the most recent transactions, until they are sent to the server and then acknowledged by the server. That part can take a few hundred milliseconds, and is spread over many mocpp_loop() calls. But the sketch above keeps initiating a new transaction per main-loop iteration and consequently creating transactions much faster than they can be processed by MicroOcpp. The transaction journal caches at most 4 pending transactions per default configuration.
To fix this sketch, I would add some logic that starts only one transaction (e.g. by adding a flag and setting it false after the beginTransaction call).

Thank you so much @matth-x  and @pedro-fuoco . I got my mistake as you said I was perfoming begin trasaction too quickly which created and issue


Design how to manage and track manually authored files

https://github.com/microsoftgraph/msgraph-sdk-typescript/pull/49


Correct fields for CancelSubscription

Corrected CancelSubscription fields for current Stripe API version.

A fix for #394
https://stripe.com/docs/api/subscriptions/cancel
According to the current Stripe API in the link above, there is no "reason" field within cancellation_details any longer. This also aligns with my testing where it did not recognize the parameter.
Consider removing this struct in future versions. For now, users can leave this as None.

Replaced at_period_end with invoice_now
Added cancellation_details field
Added prorate field

Checklist

[x] ran cargo make fmt
[x] using conventional commits to hightlight user-facing fixes and features

Thanks for this, running CI


Add startup and enabled options

Help to resolve https://github.com/moove-it/sidekiq-scheduler/issues/41
Needs to rewrite README

Please squash all the commits into one.

@elpic I remove 'startup' option, because it is enough 'enabled' option for resolving #41
'enabled' option is covered by one spec, what kind of test can i write more?


[Backport 2.9] Improved validation for tolerations / affinity agent customization

Backport for https://github.com/rancher/rancher/issues/47703

Closing the backport as the main issue got deprioritized; will open backports as needed if it gets prioritized again.


[feat/IaC-8] Add mappings

Adds mappings

Mappings added successfully, stack creates as normal without errors


Is it possible to give access to other users?

I would like to give access to the web UI to other users, is that possible to do?

Hi @luiztauffer,
Yes you can create new Cognito users through the AWS console. There should be a user pool created when you deployed, called SimpleFileManagerUserPool-(SomeID). Keep in mind that when you create the user, you'll need to add them to the administrator group in order for them to be able to access files.
Let me know if you have any other questions,
Simon


added special RestRouteList with OPTIONS method handling

#4

@koyuch the most important is the BadRequestException in presenter, if you change this i will approve the PR.

but please don't merge it yet, as I will have to do some tests for this. I will add them in the evening..


make it run in babel / node envs

so we can server-side-render an application which uses get-size on the client side

This patch doesn't work for me, I still have a height of 0


Python 3.9 Wheels

Hello,
Can python 3.9 wheels be provided on the wheel distribution? I believe it is the latest stable version as of now. The current wheels have 3.6, 3.7, and 3.8 but not 3.9.
Thank you very much.

Python 3.9 wheels are now included :)


Gradlew error

Getting an error when running gradlew for an Expo app using this package. After installing the app with npm i react-native-zendesk-messaging the build fails for Android only. It appears that the Zendesk Messaging dependency isn't being linked properly.
Two things that stood out were:
> Could not find zendesk.messaging:messaging-android:2.3.0.
and
Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
Curious if there's anything in this package or if it's an Expo issue.
Checking the license for package Android SDK Build-Tools 30.0.3 in /home/expo/Android/Sdk/licenses
License for package Android SDK Build-Tools 30.0.3 accepted.
Preparing "Install Android SDK Build-Tools 30.0.3 (revision: 30.0.3)".
"Install Android SDK Build-Tools 30.0.3 (revision: 30.0.3)" ready.
Installing Android SDK Build-Tools 30.0.3 in /home/expo/Android/Sdk/build-tools/30.0.3
"Install Android SDK Build-Tools 30.0.3 (revision: 30.0.3)" complete.
"Install Android SDK Build-Tools 30.0.3 (revision: 30.0.3)" finished.
Checking the license for package Android SDK Platform 31 in /home/expo/Android/Sdk/licenses
License for package Android SDK Platform 31 accepted.
Preparing "Install Android SDK Platform 31 (revision: 1)".
"Install Android SDK Platform 31 (revision: 1)" ready.
Installing Android SDK Platform 31 in /home/expo/Android/Sdk/platforms/android-31
"Install Android SDK Platform 31 (revision: 1)" complete.
"Install Android SDK Platform 31 (revision: 1)" finished.
> Configure project :react-native-reanimated
AAR for react-native-reanimated has been found
/home/expo/workingdir/build/node_modules/react-native-reanimated/android/react-native-reanimated-70-hermes.aar
Checking the license for package Android SDK Build-Tools 31 in /home/expo/Android/Sdk/licenses
License for package Android SDK Build-Tools 31 accepted.
Preparing "Install Android SDK Build-Tools 31 (revision: 31.0.0)".
"Install Android SDK Build-Tools 31 (revision: 31.0.0)" ready.
Installing Android SDK Build-Tools 31 in /home/expo/Android/Sdk/build-tools/31.0.0
"Install Android SDK Build-Tools 31 (revision: 31.0.0)" complete.
"Install Android SDK Build-Tools 31 (revision: 31.0.0)" finished.
[stderr]
FAILURE: Build failed with an exception.
[stderr]
* What went wrong:
[stderr]
Could not determine the dependencies of task ':app:processDebugResources'.
[stderr]
> Could not resolve all task dependencies for configuration ':app:debugRuntimeClasspath'.
[stderr]
   > Could not find zendesk.messaging:messaging-android:2.3.0.
[stderr]
     Searched in the following locations:
[stderr]
       - http://<IP_ADDRESS>:8081/artifactory/libs-release/zendesk/messaging/messaging-android/2.3.0/messaging-android-2.3.0.pom
[stderr]
       - file:/home/expo/.m2/repository/zendesk/messaging/messaging-android/2.3.0/messaging-android-2.3.0.pom
[stderr]
       - file:/home/expo/workingdir/build/node_modules/react-native/android/zendesk/messaging/messaging-android/2.3.0/messaging-android-2.3.0.pom
[stderr]
       - file:/home/expo/workingdir/build/node_modules/jsc-android/dist/zendesk/messaging/messaging-android/2.3.0/messaging-android-2.3.0.pom
[stderr]
       - https://dl.google.com/dl/android/maven2/zendesk/messaging/messaging-android/2.3.0/messaging-android-2.3.0.pom
[stderr]
       - https://repo.maven.apache.org/maven2/zendesk/messaging/messaging-android/2.3.0/messaging-android-2.3.0.pom
[stderr]
       - https://www.jitpack.io/zendesk/messaging/messaging-android/2.3.0/messaging-android-2.3.0.pom
[stderr]
       - file:/home/expo/workingdir/build/node_modules/detox/Detox-android/zendesk/messaging/messaging-android/2.3.0/messaging-android-2.3.0.pom
[stderr]
     Required by:
[stderr]
         project :app > project :react-native-zendesk-messaging
[stderr]
* Try:
[stderr]
> Run with --stacktrace option to get the stack trace.
[stderr]
> Run with --info or --debug option to get more log output.
[stderr]
> Run with --scan to get full insights.
[stderr]
* Get more help at https://help.gradle.org
[stderr]
BUILD FAILED in 2m 53s
Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
See https://docs.gradle.org/7.5.1/userguide/command_line_interface.html#sec:command_line_warnings
5 actionable tasks: 5 executed
Error: Gradle build failed with unknown error. See logs for the "Run gradlew" phase for more information.

Did you repository configure in build.gradle? https://github.com/leegeunhyeok/react-native-zendesk-messaging/blob/master/docs/getting-started.md#android
maven {
  url "https://zendesk.jfrog.io/artifactory/repo"
}

I'm not sure this library will works on expo project, and I will try do a test soon

@cesaros-taxfix This library not tested on expo yet and currently not supported
I've never used an expo, but I know that need to migrate module for expo.
(isolated new module like a expo-react-native-zendesk-messaging)
Need help for migrate because it's too large scale task.

Hi,
I am getting below error while integrating zendesk version 0.1.0 with react native version 64.2
FAILURE: Build failed with an exception.

What went wrong:
Could not determine the dependencies of task ':react-native-zendesk-messaging:compileReleaseAidl'.

Could not resolve all task dependencies for configuration ':react-native-zendesk-messaging:releaseCompileClasspath'.
Could not find com.facebook.react:react-native:.
Required by:
project :react-native-zendesk-messaging

@Rakesh199122 please check this https://github.com/leegeunhyeok/react-native-zendesk-messaging/issues/14#issuecomment-1550729842

@leegeunhyeok
Have fixed it by changing from implementation "com.facebook.react:react-native" to implementation "com.facebook.react:react-native:+" inside project level build.gradle file of react-native-zendesk-messaging.


Inlined variable values affect cursor position at debug mode

Does this issue occur when all extensions are disabled?: Yes

VS Code Version:  1.63.0
OS Version: macOS Big Sur 11.4

Steps to Reproduce:

Open Settings > Features > Debug
Set Inline Values : true
create js file with any variable assignments, for example:

var arr = [1, 2, 3, 4, 5]
print(arr)

Run and Debug this code
Paste cursor at the first column second line, press left

Expected cursor position:
var arr = [1, 2, 3, 4, 5]| /*variable value*/
print(arr)

Actual cursor position:
var arr = [1, 2, 3, 4, 5] /*variable value*/|
print(arr)

Also inlined values affect text selection.

@agusakow thanks for reporting this.
I could easily reproduce this in Mock Debug.
@hediet this seems to be a regression in the interaction between selection handling and text's inline feature.
In the 1.62 October release this worked fine:

In November (1.63) this is broken:

@hediet this is still an issue in the latest Insiders.

@hediet your fix addresses only a part of the problem: now it is no longer possible to set the caret at the right end of the inline value. But it is still possible to set the caret on the left end.
The correct behavior would only allow to set the caret at right end of the last character of the regular text.

But it is still possible to set the caret on the left beginning of the inline value (this is not correct).

I think this is a duplicate of https://github.com/microsoft/vscode/issues/135955.

/duplicate #135955


Compile error

I just wanted to try this out today. Downloaded BuildTools.jar, moved it to a spigotmc folder and ran "java -jar BuildTools.jar". It does a lot of downloading and building, but eventually it ends up failing. See the last lines of the build, containing the build error below. What can I do to make it work?
[INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ craftbukkit ---
[INFO] Changes detected - recompiling the module!
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /Applications/spigotmc/CraftBukkit/src/main/java/org/bukkit/craftbukkit/command/ColouredConsoleSender.java:[50] The method isAnsiSupported() is undefined for the type Terminal
[ERROR] /Applications/spigotmc/CraftBukkit/src/main/java/net/minecraft/server/MinecraftServer.java:[593] The method restore() is undefined for the type Terminal
[ERROR] /Applications/spigotmc/CraftBukkit/src/main/java/org/bukkit/craftbukkit/util/ServerShutdownThread.java:[21] The method restore() is undefined for the type Terminal
[INFO] 3 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10.178 s
[INFO] Finished at: 2018-10-28T12:35:54+01:00
[INFO] Final Memory: 21M/559M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project craftbukkit: Compilation failure: Compilation failure:
[ERROR] /Applications/spigotmc/CraftBukkit/src/main/java/org/bukkit/craftbukkit/command/ColouredConsoleSender.java:[50] The method isAnsiSupported() is undefined for the type Terminal
[ERROR] /Applications/spigotmc/CraftBukkit/src/main/java/net/minecraft/server/MinecraftServer.java:[593] The method restore() is undefined for the type Terminal
[ERROR] /Applications/spigotmc/CraftBukkit/src/main/java/org/bukkit/craftbukkit/util/ServerShutdownThread.java:[21] The method restore() is undefined for the type Terminal
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
Exception in thread "main" java.lang.RuntimeException: Error running command, return status !=0: [sh, /Applications/spigotmc/apache-maven-3.5.0/bin/mvn, clean, install]
	at org.spigotmc.builder.Builder.runProcess0(Builder.java:673)
	at org.spigotmc.builder.Builder.runProcess(Builder.java:630)
	at org.spigotmc.builder.Builder.main(Builder.java:506)
	at org.spigotmc.builder.Bootstrap.main(Bootstrap.java:29)

It's not the last lines. It's near the top:
[ERROR] /Applications/spigotmc/CraftBukkit/src/main/java/org/bukkit/craftbukkit/command/ColouredConsoleSender.java:[50] The method isAnsiSupported() is undefined for the type Terminal

Probably something to do with the dependency. See https://jline.github.io/jline2/apidocs/reference/jline/Terminal.html#isAnsiSupported()
Check the Spigot source to see what is being imported for Terminal, and the pom.xml file for the project to see what version is specified.

Hmmmm..... I downloaded https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar to try it out.
Works for me on OS X with Java 8.
$ java -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Hmmmm, I am also on Java 8. Build 51 instead of 131, but I would be surprised if that makes the difference
$ java -version
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

It looks like Maven may be using the wrong version of the jline2 library. I would first try cleaning out the Maven cache (rm -rf ~/.m2/repository/) to see if things improve.

I tried (re)moving my ~/.m2/repository before running again. Did not help. I even checked ~/.m2/repository/jline/jline/2.12.1/jline-2.12.1.jar afterwards, and the jline.Terminal class inside DOES contain getAnsiSupported and restore methods. During the BuildTools run it must be using jline.Terminal from somewhere else, or a patched version or something?
Can I run BuildTool.jar in verbose debug mode to see its classpath for compile?
Or any suggestions of how to proceed?

Tried upgrading to java 1.8.0_192. Did not solve the problem

I found the problem. For some unknown reason (or at least I do not remember) jline-0.9.94.jar existed in my /Library/Java/Extensions folder. jline 0.9.94 did not have the getAnsiSupported and restore methods. Removing jline-0.9.94.jar from /Library/Java/Extensions helped and I can now successfully run "java -var BuildTools.jar"


⚠ Bofrost.lu has degraded performance

In 725db86, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 915 ms

Resolved: Bofrost.lu performance has improved in b6ee553.


when you uninstal then dependencies are not uninstalled ?

this leaves no room to fix the installation in case it goes southways, in my case i have to wipe all lama-ceaner piped stuff cause it conflicts with others tuff i have , so id suggest to perform uninstall in a cleaner way than just removing the code without removing dependencies, or at least give us an option to choose, now i have to waste a lot of time to remove manually
Had to use  pip uninstall -r requirements.txt -y
torch installed without cuda
Ok instaled by pip install lama-cleaner from 0, it installs wrong numpy that doesnt work and installs torch without cuda....
:\lamanew>lama-cleaner --model=zits --device=cuda --port=8080 C:\Users\BAZO\AppData\Local\Programs\Python\Python310\lib\site-packages\lama_cleaner\model\utils.py:225: UserWarning: Failed to initialize NumPy: module compiled against API version 0x10 but this version of numpy is 0xf (Triggered internally at  ..\torch\csrc\utils\tensor_numpy.cpp:68.)   def setup_filter(f, device=torch.device('cpu'), normalize=True, flip_filter=False, gain=1, separable=None): C:\Users\BAZO\AppData\Local\Programs\Python\Python310\lib\site-packages\torch\amp\autocast_mode.py:198: UserWarning: User provided device_type of 'cuda', but CUDA is not available. Disabling   warnings.warn('User provided device_type of \'cuda\', but CUDA is not available. Disabling') C:\Users\BAZO\AppData\Local\Programs\Python\Python310\lib\site-packages\torch\amp\autocast_mode.py:198: UserWarning: User provided device_type of 'cuda', but CUDA is not available. Disabling   warnings.warn('User provided device_type of \'cuda\', but CUDA is not available. Disabling')
Ok got cuda working by installing this
pip install torch==1.12.0+cu113 torchvision==0.13.0+cu113 torchaudio==0.12.0 --extra-index-url https://download.pytorch.org/whl/cu113
but now numpy is wrong
lama-cleaner --model=zits --device=cuda --port=8080 C:\Users\BAZO\AppData\Local\Programs\Python\Python310\lib\site-packages\lama_cleaner\model\utils.py:225: UserWarning: Failed to initialize NumPy: module compiled against API version 0x10 but this version of numpy is 0xf (Triggered internally at  ..\torch\csrc\utils\tensor_numpy.cpp:68.)   def setup_filter(f, device=torch.device('cpu'), normalize=True, flip_filter=False, gain=1, separable=None): 2022-10-12 01:10:36.185 | INFO     | lama_cleaner.helper:load_jit_model:44 - Load model from: C:\Users\BAZO/.cac
So... fixed this crap with    pip install numpy --upgrade

No, dependencies are not uninstalled, it's how pip works.


ctrl+left/right doesn't work correctly in vim

ctrl+left doesn't jump over words and ctrl+right erases everything to the right of the cursor
Details

Browser and browser version: Chrome 51
OS version: Ubuntu 16.04
xterm.js version: https://github.com/sourcelair/xterm.js/commit/dc17f0d02e65f06a67ea80236aee17575e501a36

Steps to reproduce

Type the following:

vim
i
abc

ctrl+left

ctrl+right

xterm uses a bit map to handle shift, alt and ctrl status. See here...

Unfortunately I won't have access to a Linux machine until tomorrow to try this out and Ctrl + ←/→ won't work here as they are used by host.
It would help if you could provide us with the code sent by xterm.js when hitting Ctrl + ← in plain bash, compared with the code in Vim (which should have applicationKeypad set to true).

The modifier state will be added to the escape sequence as the second parameter (right before the final character) like this:
← --> CSI D (normal mode with bash) or SS3 D (application mode with vim)
Ctrl+←--> CSI 1;5 D
Shift+←--> CSI 1;2 D
There is no normal/application mode distinction with a pressed modifier key, they are all sent with CSI. The '1' is there to indicate the other number as second parameter. No clue if it has any other meaning.
Btw the modifier keys are respected for all the keys listed above by xterm.
Modifier states
  Code     Modifiers
---------+---------------------------
   2     | Shift
   3     | Alt
   4     | Shift + Alt
   5     | Control
   6     | Shift + Control
   7     | Alt + Control
   8     | Shift + Alt + Control
   9     | Meta
   10    | Meta + Shift
   11    | Meta + Alt
   12    | Meta + Alt + Shift
   13    | Meta + Ctrl
   14    | Meta + Ctrl + Shift
   15    | Meta + Ctrl + Alt
   16    | Meta + Ctrl + Alt + Shift
---------+---------------------------

When I get my hand on a linux machine I can create you a complete list of the sequences.

These are the arrow key sequences (xterm treats home and end as arrow keys):
// normal mode
ARROWS = {
    'left': '\x1b[D',
    'right': '\x1b[C',
    'up': '\x1b[A',
    'down': '\x1b[B',
    'home': '\x1b[H',
    'end': '\x1b[F',
    'page up': '\x1b[5~',
    'page down': '\x1b[6~'
}
// application mode
ARROWS_CKM = {
    'left': '\x1bOD',
    'right': '\x1bOC',
    'up': '\x1bOA',
    'down': '\x1bOB',
    'home': '\x1bOH',
    'end': '\x1bOF',
    'page up': '\x1b[5~',
    'page down': '\x1b[6~'
}

// replace %s with the modifier state
ARROWS_MOD = {
    'left': '\x1b[1;%sD',
    'right': '\x1b[1;%sC',
    'up': '\x1b[1;%sA',
    'down': '\x1b[1;%sB',
    'home': '\x1b[1;%sH',
    'end': '\x1b[1;%sF',
    'page up': '\x1b[5;%s~',
    'page down': '\x1b[6;%s~'
}


Improve Delete callbacks to handle 404s and no longer unnecessarily call d.SetId("")

fixes issue #26
fixes issue #28
fixes issue #34

@pauljamescleary The docs that I link to explain:

If the ID is updated to blank, this tells Terraform the resource no longer exists (maybe it was destroyed out of band). Just like the destroy callback, the Read function should gracefully handle this case.

https://www.terraform.io/docs/extend/writing-custom-providers.html#implementing-read

@iamjarvo You may want to take a look here, as this fixes issue #34.


Duplicate entries in the excel output

Seeing duplicated entries in the power monitoring output.
@deeptis13 @nidhigarg9 @ArunSinghSSIR

Addressed PR#4 and merged in main.


[main] Upgrade to latest dependencies

Cron. -knative-prow-robot
/cc knative/networking-wg-leads
/assign knative/networking-wg-leads
Produced via:
./hack/update-deps.sh --upgrade --release v0.22
./hack/update-codegen.sh

Details:
bumping knative.dev/hack 58edbdc...b6ab329:
  > b6ab329 Add a comment to explain why we have a long wait_until_pods_running function (# 60)

/lgtm


#2041 - Issue JSON-LD has invalid Admin API documentation

cc @swcurran @ianco
The demo AliceWantsAJsonCredential.md has invalid Admin API endpoints documented.
Signed-off-by: Jean-Francois Blier<EMAIL_ADDRESS>

@ianco -- if you have time, please take a look.

The update looks good, a bunch of tests are failing so I'm trying to re-run again

Weird the code format check is failing on files that haven't been changed ...

Andrew mentioned it on the call today.  We need a PR to fix that one line, so that it won't be an issue there after.


Better error messages

basically Vyxals using pythons default error messaging and it'll help a lot if we change those to be more understandable
(created by mathcat here)

We need to check the type of all the arguments in functions that don't have overloads for some types and print out friendlier error messages using that.

I fully support this.
(To make it even harder, lets implement rust's error messages ;P)

the ideal scenario would be to have no errors, and only weird behaviour, which often suits golfing.

@razetime weird behaviour?

@razetime I can get behind weird behaviors accompanied by warnings on stderr

@razetime  Just run each character in the error message through the SBCS and execute that! :p


TVMaze: Normalise show queries with dots.

Motivation for changes:
tvmaze returns 404 when searching for series names with dots instead of spaces. When using filesystem as config for series *NIX users (most probably) uses dots instead of spaces in series names ("american.dad" vs "american dad"), and there are (probably) a very few series in tvmaze's database that's entered with the dot it ought to be better to just normalise the query format.
manipulate is of no use in this case since it can't (I couldn't at least) replace the dots in the tv-series template below.
Detailed changes:

added a replace('.' ' ') for title.

Config usage if relevant (new plugin or updated schema):
Condensed, removed outputs, this is for reproducing bug.
templates:
 rarbg-search:
    set:
      search_string: "{{ name | replace('.', ' ') }}"
    discover:
#      interval: "3 hours"
      what:
        - next_series_episodes:
            from_start: yes
            backfill: yes
      from:
        - rarbg:
            category: 41
            min_seeders: 5
  tv-series:
    plugin_priority:
      manipulate: 10
    exists_series:
      - /mnt/tv-archive/{{series_name|replace(' ','.')|replace("_", ".")}}
      - /downloads/torrents/tv
    configure_series:
      settings:
        identified_by: ep
        tracking: backfill
        qualities:
          - 720p+
      from:
        filesystem:
          path:
            - /mnt/tv-archive
tasks:
  rarbg:
    priority: 10
    domain_delay:
      torrentapi.org: 5 seconds
    set:
      path: /mnt/tv-archive/{{series_name|replace(' ','.')|replace("_", ".")|lower}}/s{{series_season|pad(2)}}
    verify_ssl_certificates: no
    template:
      - tv-series
      - rarbg-search

Log and/or tests output (preferably both):
Tests run:

Backfill search, no 404 when using "american.dad" as input.

To Do:

The problem here is not with TVMaze, is that the series parser does not normalize the name. This is an entirely different issue.
I'm closing this, please open an issue.

Yeah, I can see how that’s the case from my tests with manipulate.
So the are some other options in this case:

Adding regexp to configure_series.

Adding another phase to manipulate.

Right?

3-
set:
  series_name: {{series_name|replace('.',' ')

3-
set:
  series_name: {{series_name|replace('.',' ')}}

No dice, tried both in tv-series and rarbg-search templates.
1316458-2020-05-20 09:02:27 DEBUG    api_tvmaze    rarbg           searching lookup table using title star.trek.picard
1316569-2020-05-20 09:02:27 DEBUG    api_tvmaze    rarbg           trying to fetch series star.trek.picard from tvmaze
1316680:2020-05-20 09:02:27 DEBUG    api_tvmaze    rarbg           querying tvmaze API with the following URL: https://api.tvmaze.com/singlesearch/shows
1316825:2020-05-20 09:02:27 DEBUG    utils.requests rarbg           GETing URL https://api.tvmaze.com/singlesearch/shows with args () and kwargs {'params': {'embed': 'seasons', 'q': 'star.trek.picard'}, 'allow_redirects': True, 'timeout': 30}
1317060:2020-05-20 09:02:27 DEBUG    est_series_tvmaze rarbg           404 Client Error: Not Found for url: https://api.tvmaze.com/singlesearch/shows?embed=seasons&q=star.trek.picard
1317235-2020-05-20 09:02:27 DEBUG    est_movies    rarbg           Unable to check release for star.trek.picard S02E01, tmdb_release and movie_year fields are not defined
1317398-2020-05-20 09:02:27 DEBUG    discover      rarbg           No release date could be determined for star.trek.picard S02E01

This won't work since estimators run before set plugin.
@gazpachoking there's something weird here. It looks like the name is being normalized correctly, but series.name returns the original name and not the normalized one, as (i think) it should.

Don’t think it’s a matter of estimators since it’s the filter data itself we’re trying to modify.

I'm paging doctor @gazpachoking for some consultation. :)
I kinda forgot about this one. But I think it needs some TLC..


Get-PSDrive returns incorrect DisplayRoot property for mounted drive letters in 7.4.1

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
When running this for a network-mounted drive letter
Get-PSDrive -Name V | Select-Object DisplayRoot

The output is incorrect, because the value of the property is incorrect (padded with NULs up to some length):

The output from Windows PowerShell 5.1 is correct:

Here's the culprit:

This is linked to (the fix for) #19903
Expected behavior
Get-PSDrive -Name V | Select-Object DisplayRoot

DisplayRoot
-----------
\\pnjnas\V

Actual behavior
Get-PSDrive -Name V | Select-Object DisplayRoot

DisplayRoot
-----------
\\pnjnas\V…

Error details
No response
Environment data
Name                           Value
----                           -----
PSVersion                      7.4.1
PSEdition                      Core
GitCommitId                    7.4.1
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Visuals
No response

Does the actual property value (Get-PSDrive -Name V).DisplayRoot have the …. This just seems like how it is formatted by default rather than an incorrect value.

Does the actual property value (Get-PSDrive -Name V).DisplayRoot have the …. This just seems like how it is formatted by default rather than an incorrect value.

It does contain a bunch of NULs, see the output from Format-Hex in the screenshot above.
FWIW, my current workaround in https://gist.github.com/sba923/d0d5ad16f2b12d7785adf830b0395dc2#file-df-ps1 is as follows:
$displayroot = $psdrive.DisplayRoot
if ($displayroot.Contains([char]0))
{
    $displayroot = $displayroot.Substring(0,$displayroot.IndexOf([char]0))
}

Ah I see sorry, makes more sense now :)

Super weird I can replicate this using the official 7.4.1 release (zip from GitHub release assets) but as soon as I build a local copy of the master branch or the 7.4.1 tag then the problem goes away. I'm not sure what has happened as the PR has been merged and backported and the 7.4.1 tag works just fine when build locally.

Interesting. I also can't repro using the local build I use to prepare a PR for #19886...

This was fixed in #20793 and was backported in #20863. Please re-check v7.4.1 build and report if the issue is still there.
/cc @daxian-dbw It seems there was an unsynchronization with GitHub there.

This was fixed in #20793 and was backported in #20863. Please re-check v7.4.1 build and report if the issue is still there.
/cc @daxian-dbw It seems there was an unsynchronization with GitHub there.

@iSazonov can you please elaborate? The issue is present in the released 7.4.1 MSI...
Is your question addressing the people that were in charge of making it so that the fix would be included in the released 7.4.1?

How do I get my working sba923 fork to be aligned with 7.4.1?
Building from it currently gets me PowerShell 7.3.0-preview.3-1215-ge453c006d39a2fa57a903df2d0ea33ddd0cb43dd

Building from it currently gets me PowerShell 7.3.0-preview.3-1215-ge453c006d39a2fa57a903df2d0ea33ddd0cb43dd

Try git fetch --tags --all.

Release process is MSFT internal process. If they skipped something they will fix in 7.4.2.

This gets me:
PS> git fetch --tags --all
Fetching origin
Fetching upstream
remote: Enumerating objects: 3550, done.
remote: Counting objects: 100% (2293/2293), done.
remote: Compressing objects: 100% (96/96), done.
remote: Total 3550 (delta 2203), reused 2261 (delta 2191), pack-reused 1257
Receiving objects: 100% (3550/3550), 1.73 MiB | 3.37 MiB/s, done.
Resolving deltas: 100% (2671/2671), completed with 615 local objects.
From https://github.com/PowerShell/PowerShell
 * [new branch]          TravisEz13-block-vpack-preview -> upstream/TravisEz13-block-vpack-preview
 * [new branch]          TravisEz13-patch-1     -> upstream/TravisEz13-patch-1
 * [new branch]          TravisEz13-pmc-timeout -> upstream/TravisEz13-pmc-timeout
 * [new branch]          adityapatwardhan-patch-1 -> upstream/adityapatwardhan-patch-1
 * [new branch]          dependabot/nuget/StyleCop.Analyzers-1.2.0-beta.556 -> upstream/dependabot/nuget/StyleCop.Analyzers-1.2.0-beta.556
 * [new branch]          master                 -> upstream/master
 * [new branch]          onboarding-prIssueManagement -> upstream/onboarding-prIssueManagement
 * [new branch]          release/v7.2.18        -> upstream/release/v7.2.18
 * [new branch]          release/v7.3.11        -> upstream/release/v7.3.11
 * [new branch]          release/v7.4.1         -> upstream/release/v7.4.1
 * [new branch]          revert-19152-Webcmdlets-automatic-ContentType-PUT -> upstream/revert-19152-Webcmdlets-automatic-ContentType-PUT
 * [new branch]          source-depot           -> upstream/source-depot
 * [new branch]          spelling-workflow      -> upstream/spelling-workflow
 * [new tag]             v7.0.10                -> v7.0.10
 * [new tag]             v7.0.11                -> v7.0.11
 * [new tag]             v7.0.12                -> v7.0.12
 * [new tag]             v7.0.13                -> v7.0.13
 * [new tag]             v7.1.7                 -> v7.1.7
 * [new tag]             v7.2.10                -> v7.2.10
 * [new tag]             v7.2.11                -> v7.2.11
 * [new tag]             v7.2.12                -> v7.2.12
 * [new tag]             v7.2.13                -> v7.2.13
 * [new tag]             v7.2.14                -> v7.2.14
 * [new tag]             v7.2.15                -> v7.2.15
 * [new tag]             v7.2.16                -> v7.2.16
 * [new tag]             v7.2.17                -> v7.2.17
 * [new tag]             v7.2.18                -> v7.2.18
 * [new tag]             v7.2.3                 -> v7.2.3
 * [new tag]             v7.2.4                 -> v7.2.4
 * [new tag]             v7.2.5                 -> v7.2.5
 * [new tag]             v7.2.6                 -> v7.2.6
 * [new tag]             v7.2.7                 -> v7.2.7
 * [new tag]             v7.2.8                 -> v7.2.8
 * [new tag]             v7.2.9                 -> v7.2.9
 * [new tag]             v7.3.0                 -> v7.3.0
 * [new tag]             v7.3.0-preview.4       -> v7.3.0-preview.4
 * [new tag]             v7.3.0-preview.5       -> v7.3.0-preview.5
 * [new tag]             v7.3.0-preview.6       -> v7.3.0-preview.6
 * [new tag]             v7.3.0-preview.7       -> v7.3.0-preview.7
 * [new tag]             v7.3.0-preview.8       -> v7.3.0-preview.8
 * [new tag]             v7.3.0-rc.1            -> v7.3.0-rc.1
 * [new tag]             v7.3.1                 -> v7.3.1
 * [new tag]             v7.3.10                -> v7.3.10
 * [new tag]             v7.3.11                -> v7.3.11
 * [new tag]             v7.3.2                 -> v7.3.2
 * [new tag]             v7.3.3                 -> v7.3.3
 * [new tag]             v7.3.4                 -> v7.3.4
 * [new tag]             v7.3.5                 -> v7.3.5
 * [new tag]             v7.3.6                 -> v7.3.6
 * [new tag]             v7.3.7                 -> v7.3.7
 * [new tag]             v7.3.8                 -> v7.3.8
 * [new tag]             v7.3.9                 -> v7.3.9
 * [new tag]             v7.4.0                 -> v7.4.0
 * [new tag]             v7.4.0-preview.1       -> v7.4.0-preview.1
 * [new tag]             v7.4.0-preview.2       -> v7.4.0-preview.2
 * [new tag]             v7.4.0-preview.3       -> v7.4.0-preview.3
 * [new tag]             v7.4.0-preview.4       -> v7.4.0-preview.4
 * [new tag]             v7.4.0-preview.5       -> v7.4.0-preview.5
 * [new tag]             v7.4.0-preview.6       -> v7.4.0-preview.6
 * [new tag]             v7.4.0-rc.1            -> v7.4.0-rc.1
 * [new tag]             v7.4.1                 -> v7.4.1

The result of the build is PowerShell 7.4.0-rc.1-182-g6df3809104f009ce943e0a77440f14e9673e3239, not a 7.4.1 something.
And this issue doesn't repro with the output of that build.

Thanks to @seeminglyscience we've found the problem. The changes in the PR mentioned are definitely in 7.4.1, you can see them when decompiling the dll in the release

It uses the Span<char> that was used in https://github.com/PowerShell/PowerShell/pull/20793. When stepping through this code at runtime I noticed that ref bufferSize (ref num in decompiled code) never changed and was always the size of the span/buffer being passed in.
The docs for WNetGetConnection state for this argument

Pointer to a variable that specifies the size of the buffer pointed to by the lpRemoteName parameter, in characters. If the function fails because the buffer is not large enough, this parameter returns the required buffer size.

So this value will only be set to the length if the initial buffer wasn't large enough. With a debug build you get when building locally the code has https://github.com/PowerShell/PowerShell/blob/e453c006d39a2fa57a903df2d0ea33ddd0cb43dd/src/System.Management.Automation/engine/Interop/Windows/WNetGetConnection.cs#L29-L34 which set the buffer to 3 explicitly and not the span size so it will actually hit this logic. In a release build it will not. The fix for this is to slice the span to the first null char like in the workaround and really remove the #if DEBUG logic so we are actually testing the same code that is run in a release build.

Opened https://github.com/PowerShell/PowerShell/pull/21068

Thanks to @SeeminglyScience we've found the problem. [...] The fix for this is to slice the span to the first null char like in the workaround and really remove the #if DEBUG logic so we are actually testing the same code that is run in a release build.

Nice! Will have to live with my workaround until 7.4.2 😜

FYI problem is also present in 7.5.0-preview.1

FYI problem is also present in 7.5.0-preview.2

FYI problem is also present in 7.5.0-preview.3

FYI problem is also present in 7.5.0-preview.4

FYI problem is also present in 7.5.0-preview.5.
How come @jborean93  given that https://github.com/PowerShell/PowerShell/pull/21068 is closed?

What can I do about this?

As discussed earlier, the issue is still present in 7.5.0-rc.1.
What can I do to help getting this fixed?

I've reopened a new PR based on the original one https://github.com/PowerShell/PowerShell/pull/24600. Hopefully the pwsh team can review it and merge it in.


Lag, NPE, barrels accept a stack of soul sand (or it's duped, not sure)

Using Ender IO conduits with barrels leads to some non-intuitive results, an NPE, and lots of lag. The condiuts were placed on top of the barrels and configured to insert and extract without any filters. While this happened I saw traffic spike up as high as 150KB/s from the server to my client.
This gist shows the NPE and the full log is below if you need it. https://gist.github.com/sitedyno/6bc61974d7f0ae1c3befcf34e7ac760f#file-exception-log
Here is a video showing how I had set things up https://youtu.be/reEP5Z9V7fk
This is SF3 3.0.4 with:

EnderCore-1.10.2-<IP_ADDRESS>-beta.jar
EnderIO-1.10.2-3.1.156.jar
EnderStorage-1.10.2-<IP_ADDRESS>-universal.jar
exnihiloadscensio-1.10.2-0.1.11.jar

Thanks!

So there's a few things going on here. I have been able to replicate the lag, but neither the NPE nor the dupe.
The lag is due to lighting updates, and I have a fix in mind, just need to iron out the kinks though.

Closing this since it's so old and probably not relevant at this point.


A modify of ch05/ex5_17.cpp

remove the judge if(i == size - 1)

Thanks for your contributions, I agree with you on the improving of ex5_17.cpp.
But, ex5_14.cpp make me confused. It seems like out-of-date, maybe you should up to the latest version of the solution: https://github.com/pezy/CppPrimer/blob/master/ch05/ex5_14.cpp

Sorry, ex5_14 I modifid was out-of-date in deed. I have synchronized the fork now.


Broken link

Hi the link in the section:
Experiments are highly configurable. See the AutoML API docs for a full list of configuration settings.
does not work and returns a 404

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c3bb37d9-1c4d-5d5f-2ed6-2ef77f2cd627
Version Independent ID: 80ed0d4d-63d3-49f0-ae42-d1f132137352
Content: How to use the ML.NET automated ML API - ML.NET
Content Source: docs/machine-learning/how-to-guides/how-to-use-the-automl-api.md
Product: dotnet-ml
GitHub Login: @JRAlexander
Microsoft Alias: johalex

Thanks for the feedback, @PeterPann23! I've submitted the PR with the fix.


Service-to-service invocation fails in Kubernetes (AWS EKS)

In what area(s)?

/area runtime

/area operator

/area placement

/area docs

/area test-and-release

What version of Dapr?

1.2.x
Expected Behavior
Service-to-service invocation through HTTP in Kubernetes deployments should work with no error.
Actual Behavior
The http call returns:
{"errorCode":"ERR_DIRECT_INVOKE","message":"fail to invoke, id: my-app, err: failed to invoke target my-app after 3 retries"}

Steps to Reproduce the Problem
I'm running Dapr on Kubernetes (Amazon EKS + Fargate).
I installed it using dapr init -k --enable-mtls=false (enabling mtls causes a different issue).
dapr status -k says that everything is running and healthy.
The sidecars are successfully injected to my deployments but I have an issue with service-to-service invocation. The http call returns:
{"errorCode":"ERR_DIRECT_INVOKE","message":"fail to invoke, id: my-app, err: failed to invoke target my-app after 3 retries"}

In debug mode, the logs on a sidecar show:
time="2021-07-11T21:33:24.960099188Z" level=debug msg="try to connect to placement service: dns:///dapr-placement-server.dapr-system.svc.cluster.local:50005" app_id=api-gateway instance=deployment-api-gateway-test-5f987d4b77-fsxxp scope=dapr.runtime.actor.internal.placement type=log ver=1.2.0
time="2021-07-11T21:33:24.969458206Z" level=debug msg="error connecting to placement service: rpc error: code = Unavailable desc = last resolver error: produced zero addresses" app_id=api-gateway instance=deployment-api-gateway-test-5f987d4b77-fsxxp scope=dapr.runtime.actor.internal.placement type=log ver=1.2.0

(the issue happens in both 1.2.0 and 1.2.2)
Here are the annotations on one of my deployments:
      annotations:
        dapr.io/enabled: 'true'
        dapr.io/app-id: 'api-gateway'
        dapr.io/app-port: '3000'
        dapr.io/log-level: "debug"
        dapr.io/sidecar-liveness-probe-delay-seconds: "60"
        dapr.io/sidecar-liveness-probe-timeout-seconds: "60"

I made sure that dapr.io/app-port and containerPort are the same and extended liveness-probe as it is one of the recommended troubleshooting steps.
Service-to-service invocation works fine when I run on my local machine using dapr run and calling http://localhost:{DAPR_HTTP_PORT}/v1.0/invoke/{SERVICE_NAME}/method.
Release Note

RELEASE NOTE:

Reopening.
just checking again @djojoz, were you able to get this working?


elasticsearch.BadRequestError: unrecognized parameter node_id on tasks.list

In 8.15.1, the list function on TaskClient accepts a parameter node_id according to the docs:

node_id (Sequence[str] | None) – Comma-separated list of node IDs or names used to limit returned information.

node_id is passed as a query parameter: https://github.com/elastic/elasticsearch-py/blob/main/elasticsearch/_sync/client/tasks.py#L200
If this parameter is set, _perform_request will fail because it expects nodes not node_id:
elasticsearch.BadRequestError: BadRequestError(400, 'illegal_argument_exception', 'request [/_tasks] contains unrecognized parameter: [node_id] -> did you mean [nodes]?')

If I change the underlying call to self.perform_request to assign the query parameter to key nodes instead of node_id the request succeeds:
es_client.tasks.perform_request("GET", "/_tasks", params={"nodes":["node_id_1", "node_id_2"]}, headers={"accept": "application/json"}, endpoint_id="tasks.list", path_parts={})

but passing nodes to task.list is not accepted.
I believe this line should be changed to:
            __query["nodes"] = node_id

Alternatively the list function could be changed from using node_id to using nodes on the query parameters as well as the function parameters.

Thank you @margaretpearce for your report (and pull request)! The code you edited is generated from the Elasticsesrch specification, so I transferred the issue here. The relevant part:
https://github.com/elastic/elasticsearch-specification/blob/main/specification/tasks/list/ListTasksRequest.ts#L48-L51
If you are still interested in fixing this, you can open a pull request against this new repo. Otherwise no worries we will fix it in the coming week and this will be in elasticsearch-py 8.16.0.

Thank you for letting me know @pquentin! I gave the fix in the correct repo a shot: https://github.com/elastic/elasticsearch-specification/pull/3113


Set select2 field value as soon as page loads

I know this has been asked several times before, but I've literally been going through solutions for 4 hours and couldn't find the solution for my specific problem.
I've got a select2 select field on an Laravel blade edit view and I would like to set it's value to the data passed to the view. Passing data to the view already happens, and using the select field is no problem either, it works perfectly fine. But every single try I've been going for failed to set it. I've been messing around with a button to set the select field's value, but every modification of
$("select[name=customer]").val("1");
has failed to do this. It always transfers "?id=null". I would appreciate someone setting light on this, as I can't really continue without this. I am adding the important code parts below, if you need anything more, just reply. Thanks in advance!
Select HTML:
<label>*Customer</label>
<select class="form-control" name="customer" id="customer" style="width: 100%">
     <option></option>
</select>

Select2:
$("select[name=customer]").select2({
    allowClear : true,
    placeholder : "Choose customer",
    ajax : {
        url : "/search/autocomplete/get_customers",
        dataType : 'json',
        type : "GET",
        quietMillis : 50,
        delay : 250,
        data : function(params) {
            return {
                filter : params.term
            };
        },
        processResults : function(data) {
            return {
                results : $.map(data, function(item) {
                    return {
                        text : item.name + ' (' + item.customer_code + ')',
                        id : item.id
                    }
                })
            };
        },
        initSelection : function (element, callback) {
              var data = [];
              $(element.val()).each(function () {
                data.push({id: this, text: this});
              });
              callback(data);
        }
    }
});

Button:
<button type="button" onclick="test()">Test</button>
Function test():

function test() {
    $("select[name=customer]").val("1");
};

I have been trying several alterations of this, examples:
$("select[name=customer]").val("1");
$("select[name=customer]").val("1").change();
$("select[name=customer]").val("1").trigger("change");
$("select[name=customer]").select2("val", "1");

with the list continuing.
If I didn't provide important stuff, message me or replay please!
Best regards
Nick

This appears to be more of a usage question than a bug report or common feature request.  As we continue to keep the Select2 issue tracker geared towards these two areas, bug reports and common feature requests, we are redirecting usage questions to other communities such as the mailing list, IRC, or Stack Overflow.


Link to header files on Doxygen pages

It would be cool to link to a copy of the actual include file at the bottom of the doxygen pages, e.g.
[heading Requirements]
Header<EMAIL_ADDRESS>`#include <nudb/verify.hpp>`]

This is done


Variables in Kotlin: Android Basics with Compose - Much struggle to see some parts of the Note

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-compose-variables?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-compose-unit-1-pathway-1%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-compose-variables#1
In which task and step of the codelab can this issue be found?
The Note at the end of Data Types
Describe the problem
The parts that were intended to be highlighted are not fully visible.
Steps to reproduce?

Go to...
Click on...
See error...

Versions
Android Studio version:
API version of the emulator:
Additional information
Include screenshots if they would be useful in clarifying the problem.

Am using Dark Theme for the Android Developers website

Hi @SamuelWakoli
Thank you for writing in.
This is a known issue regarding the Dark Theme. If possible, please turn if off for now.
The responsible team is aware of the issue.
Regards.

That's great!
Thank you @johnshea


localization[zh-TW]

/* Written by Alang.lin */
(function($) {
$.timepicker.regional['id'] = {
    timeOnlyTitle: '選擇時分秒',
    timeText: '時間',
    hourText: '時',
    minuteText: '分',
    secondText: '秒',
    timezoneText: '時區',
    currentText: '現在時間',
    closeText: '確定',
    timeFormat: 'hh:mm tt',
    ampm: false
};
$.timepicker.setDefaults($.timepicker.regional['id']);
})(jQuery);

Can you provide an updated translation to the latest version? Specifically the millisecText, amNames, and pmNames.  Also if you could provide the name of the lanugage in the comments (I don't recognize the language, sorry)

millisecText: '毫秒'
amNames:'上午'
pmNames:'下午'

Added to dev branch, thanks!


Incorrect rendering of s2 cells when zoomed out

Description
Larger s2 cells are rendered as overlapping ninja stars.
Repro Steps
https://codesandbox.io/s/s2-ninja-star-bug-22tu7

The two smaller ones to the north correctly don't overlap. But the two larger ones to the south incorrectly overlap
Environment (please complete the following information):

Framework Version<EMAIL_ADDRESS>Browser Version: Chrome
OS: OSX

Fixed in 7.3.9


Fix Remove lambdas when updating menus from context in Window

References and relevant issues
Follow on from #4991
Description
Removes lambdas when updating from context during add_menu _qt_main_window.py.
Each menu function just gets layerlist and does not use a helper function anymore. Prevents any use of strings now. Not 100% this is better. There is a lot of repetition but there was previously as well. Open to change.

ping @Czaki @DragaDoncila

Hmm yeah @lucyleeow I can see what you mean about the repetition, and I don't love it. I don't personally see much issue with using the strings... even if we make them constants at the top of the file or something. Could we instead use partials to parameterize the update method with the right menu name before connecting it?

Yeah I think that is what we wanted originally and I am happy to change to that!

not sure if @Czaki has a preference

@DragaDoncila @Czaki
Okay I have used Literal and each is their own method (and avoided the previous repetition, though still a lot of repetition).
Let me know if this is okay with you, thanks!

ping @Czaki :grimacing:


[Question] Is it possible to show a content page (modal) from the bottom sheet without close it first?

Hello @paulvarache ,
First, I would like to thank you for the time and effort on this plugin, I have been using it on my first project and it works and looks fantastic for iOS and Android.
I am here to ask a question: I am using the bottom sheet to display some information and the information has some buttons that navigate to another screen (content page using modal), however, when I click the button or element it does not work. It triggers correctly the tap gesture event, however, it does not navigate to the modal screen.
This is how I want to navigate to a page (modal) from the tap event:
async void TapGestureRecognizer_Tapped(System.Object sender, Microsoft.Maui.Controls.TappedEventArgs e)
    {
        // await this.Dismiss(); if I dismiss it first it navigates OK.

        var viewModel = BindingContext as DashboardViewModel;
        if (viewModel.NavigateLocationLogsCommand.CanExecute(null))
            await viewModel.NavigateLocationLogsCommand.ExecuteAsync(null);
    }

Then on my viewmodel command I have the following line:
await Shell.Current.GoToAsync($"{nameof(InformationPage)}");
The Information Page has this property set:
Shell.PresentationMode="ModalAnimated"
I would like to navigate to that page and when the user closes it manually, return back and the bottom sheet still be open.
Any hint is always welcome.
Thanks in advance!!

Hi, thanks for your support.
Could you confirm this is happening on Android iOS or both? This would help isolating the issue

Thanks for the fast response @paulvarache
I can confirm the issue occurs on iOS only (tested on emulators and physical devices). On Android, the modal is being loaded as expected without dismissing the bottom sheet.
I'm using the package The49.Maui.BottomSheet 1.0.0-rc1
Let me know if there is any other information you need from me.
Regards,
Victor

Hi, I wasn't able to reproduce this. I managed to get a shell modalAnimated page opening from a tapgesturerecognizer within a bottom sheet.
The sheet does stay on top of the newly opened page, but that is the behaviour for bottom sheets on both Android and iOS, so it is up to the use to dismiss and show in sync with any newly opened page if needed.
Let me know if this is still an issue you have with more recent versions too as some things have changed which might help with your specific issue.
I've left an example in the sample project that opens a shell modal page if you want to check it out yourself

Hello @paulvarache , I was able to test your sample and it works partially in your sample, however, I found out the modal was not implemented correctly on the code sample you updated. With all respect and your permission, I went ahead and forked the repository and updated the sample here: https://github.com/vhugogarcia/The49.Maui.BottomSheet on the branch: modal-page
These are the changes:
https://github.com/vhugogarcia/The49.Maui.BottomSheet/commit/bdbe679cf3d0ca8ad5471631972d4d68e628d440
In summary, I removed the flyoutmenuitem since for modal we should navigate using relative urls instead of absolute with ///. Also, I updated the command to use async.
If you download my update repository and run it on iOS emulator, you will find out that when you open the bottomsheet for Modal page and then TAP on Go To Modal button from the bottom sheet, you will see that nothing happens and the Visual Studio console will report this:
The49.Maui.BottomSheet.Sample[47070:500720] [Presentation] Attempt to present <Microsoft_Maui_Controls_Platform_ModalWrapper: 0x7fd21cfba910> on <Microsoft_Maui_Controls_Platform_Compatibility_ShellFlyoutRenderer: 0x7fd21dc1b2a0> (from <Microsoft_Maui_Controls_Platform_Compatibility_ShellFlyoutRenderer: 0x7fd21dc1b2a0>) which is already presenting <The49_Maui_BottomSheet_BottomSheetViewController: 0x7fd21db86ad0>.
The49.Maui.BottomSheet.Sample[47070:500720] [Presentation] Attempt to present <Microsoft_Maui_Controls_Platform_ModalWrapper: 0x7fd21db8dac0> on <Microsoft_Maui_Controls_Platform_ModalWrapper: 0x7fd21cfba910> (from <Microsoft_Maui_Platform_PageViewController: 0x7fd21cf99040>) whose view is not in the window hierarchy.

Let me know if there is anything else I can help with to reproduce the issue.
Note: Also, if you try to show an alert from the BottomSheet it won't work.

Thanks for looking into.

Hi,
I finally got to this issue and I have hit a wall for now.
For those who are interested in the implementation details:
Displaying an Alert, Modal page or bottom sheet on iOS PresentViewController is used. This requires using the top most presented controller or iOS will not show the new Alert/Modal/Sheet.
This project simply finds the root view controller from the window. This mean it works when no alert or modal is presented.
As a fix, I will change it so it uses the top most view controller, this means sheets should work from within modals
The issue comes with Alert/Modal from a sheet. MAUI uses its own logic to find which view controller to use. If any modal is used, it walks down the list and gets the top most modal, otherwise it uses the window's root view controller.
The view controllers this project creates and presents are taken in account in MAUI's logic, meaning MAUI tries to present the Alert/Modal from a view controller that already presents the BottomSheet and iOS fails.
What I have tried:
I tried creating a new UIWindow, and displaying the sheet from there. This works, BUT iOS doesn't animate the app's UIWindow as the BottomSheet reaches the top of the display.
I tried replacing the app's RootViewController with a dummy one when presenting the sheet (or the modal's viewcontroller). This tricks MAUI into using our own ViewController instead of the default one when the sheet is opened. This works in some cases, but in other cases, iOS complains that we're trying to present a view controller from a detached view controller.
Closing the sheet before displaying alerts or navigating to a modal seems to be the only way for now.
I will open an issue on the maui repo asking about this scenario, but I can't imagine this being too much of a priority

Thanks @paulvarache for looking into the issue. And I think opening a ticket in .NET MAUI may help to solve this mystery.
And not a problem. We can in the meantime continue dismissing the bottom sheet and show a modal or so.
Really appreciate the time you put into this issue. Let me know if there is anything I can help with :)

@paulvarache Hey, I'm TJ from the Maui Team and was wondering if you opened an issue regarding this on the MAUI Repo?


remove no_std hashbrown dep

Hashbrown added several recursive deps, time to rip it out

Fun fact: hashbrown now depends on syn and whatnot, which kind of eleminates the whole purpose of nanoserde
│   ├── hashbrown v0.13.2
│   │   └── ahash v0.8.11
│   │       ├── cfg-if v1.0.0
│   │       ├── once_cell v1.19.0
│   │       └── zerocopy v0.7.34
│   │           └── zerocopy-derive v0.7.34 (proc-macro)
│   │               ├── proc-macro2 v1.0.82
│   │               │   └── unicode-ident v1.0.12
│   │               ├── quote v1.0.36
│   │               │   └── proc-macro2 v1.0.82
│   │               │       └── unicode-ident v1.0.12
│   │               └── syn v2.0.63
│   │                   ├── proc-macro2 v1.0.82
│   │                   │   └── unicode-ident v1.0.12
│   │                   ├── quote v1.0.36
│   │                   │   └── proc-macro2 v1.0.82
│   │                   │       └── unicode-ident v1.0.12
│   │                   └── unicode-ident v1.0.12
│   │       [build-dependencies]
│   │       └── version_check v0.9.4

never trust a crates.io dependency, they can brought a full rust parser into your dependency at literally any moment :D
(not a no-std user here, no opinion on what to do about it)

Gah thats not cool. Hmmm. Maybe we should just drop hashmap impl when doing no_std?

I guess that wouldn't be additive though :/

@not-fl3 looks like that was optional, got it down to

cargo +nightly tree --features "no_std, binary"

nanoserde v0.2.0
├── hashbrown v0.14.5
│   └── ahash v0.8.11
│       ├── cfg-if v1.0.0
│       ├── once_cell v1.19.0
│       └── zerocopy v0.7.34
│       [build-dependencies]
│       └── version_check v0.9.4
└── nanoserde-derive v0.2.0 (proc-macro)

--target=all still got syn etc, and Cargo alwas downloads it now, even when no-std is off.

Actually, it was not the case for 0.12 (tho 0.12 use getrandom/wasi...)
Do we really need 0.14? Is it worth downloading 6 extra fairly heavy dependencies?
--target=all do happen on the CI and cargo downloads all those dependencies no matter what features are used, so I would rather not have hashbrown from now on at all to be honest, but I am not sure if this would be very easy to do

I guess it makes more sense to make a PR to add nanoserde support for their types in hashbrown itself at this point. They already have features for serde + rykv, so seems likely they would accept it

Alright, ripped it all out now and switched to a BTreeMap for the toml parser internal representation of arrays so that it can be used with no_std

Wow, such a clever solution, a huge fan of this PR! Somehow I totally overlooked that alloc got collections!
still totally usable with no_std and we still have std::HashMap support for jsons with std!
Looks super good to me!


Add GNNLux training example in docs

We could add DataLoader usage to the example

We could add DataLoader usage to the example

Yes, but at the moment it is not straight forward.


Implement DIV_MOD_N_PACKED_DIVMOD_V1  & DIV_MOD_N_PACKED_DIVMOD_EXTERNAL_N hints

More hints are needed for integration test

Codecov Report

Merging #290 (dd910fa) into main (a72704d) will decrease coverage by 0.45%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #290      +/-   ##
==========================================
- Coverage   57.60%   57.15%   -0.45%
==========================================
  Files          45       46       +1
  Lines        5611     5655      +44
==========================================
  Hits         3232     3232
- Misses       2078     2122      +44
  Partials      301      301

Files
Coverage Δ

pkg/hints/hint_utils/bigint_utils.go
0.00% <0.00%> (ø)

pkg/hints/hint_processor.go
95.41% <0.00%> (-3.01%)
:arrow_down:

pkg/hints/signature_hints.go
0.00% <0.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Absorbed by #291


ACS should only need contributor not owner

Currently the SP is created with OWNER, we can probably just have contrbutor...
@colemickens

Agreed. I think you make them "per-sub" but fwiw, it only needs Contributor to the RG as well.

Fixed by https://github.com/Azure/azure-cli/pull/2321


playground: set new line mode to unix

fixes #182

Yeah, I think #186 is a better solution. I will close this when #186 lands.