[$2000] Large image doesn't zoom well in Android and gets blurry

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to any chat and upload a very long/large image. Example image
In the Attachment preview, tap the image to zoom
Keep zooming until you'll see that the image is blurry

Expected Result:
Image should zoom to show a clear image instead of a blurry one
Actual Result:
Image content is not visible, and it is blurry.
Workaround:
unknown
Platform:

Where is this issue occurring?

Android

Version Number: 1.2.29-6
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/203113972-1f4bb867-186f-4d5c-89e7-cd2761fa2c6b.mp4
https://user-images.githubusercontent.com/43996225/203113166-fb40d7b0-6bb3-418c-ad80-6bb22280e9ba.mov
Expensify/Expensify Issue URL:
Issue reported by: @mananjadhav
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1668928921788569
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0100609c253c2769f4
Upwork Job ID:<PHONE_NUMBER>026803712
Last Price Increase: 2022-12-08

I remember this same images was causing this a long time ago: https://github.com/Expensify/App/issues/5193
I wonder if it ever got fixed and if this is a regression.

@aldo-expensify I mentioned this in the slack too, it is a regression. I had tested this earlier and it did work at some point when working on another issue.

I don't have an Android device. How would you suggest reproducing the bug?

@tjferriss do you have an Android emulator or say Browserstack login? You can then reproduce this. This occurs only on Android. Second video on the issue body is from my Android device.

Maybe this will get fixed once the PR https://github.com/Expensify/App/pull/12648 gets re-done and we use fast-image.. maybe

Well I tested this when #12648 was worked upon and it wasn't resolved. In fact I found this issue, while testing the same PR. We can still put this on hold, and come back again if you think that's the best option.

come back again if you think that's the best option.

No, given that you already saw that this doesn't get fixed, ignore my previous comment :P

Reproduced:

Web

Android

Thank you @aldo-expensify. This looks ready to go so I'm going to add the External tag.

Thanks @markarmanus
I was also having a look, what you said matches with explanation on what was happening when it was fixed in the past: https://github.com/Expensify/App/issues/5193#issuecomment-974397005
Here is the PR that was done to fix it: https://github.com/Expensify/App/pull/6442
Haven't looked further into why now it is not working, but leaving the links here in case they are of use to someone.

Proposal
Problem:
The issue is happening on android, when you render an image that the original resolution is massive but you render it with a smaller resolution
Example:
// original image is 14500x3000
<Image style={{width: 300, height: 300, }} resize="contain" />

On IOS this image is going to stay at the original resolution when zooming in.
On Android the image gets downscaled to the resolution sepefied to the component so that results in a blury picture on zoom in.
As i stated above this is a recurring issue in the react native community. There is currently no solution for the issue.
I was able to create a solution. its somewhat hacky but it works.
When rendering the image we render the image in its full resolution. then create a container of the image that scales it down to fit the screen.
Here is how to achieve this.
const imageTransformScale = Math.min(containerHeight / imageHeight, containerWidth / imageWidth);
this.setState({imageHeight, imageWidth, imageTransformScale});
// calculate a imageTransformScale

Then Contain the image in a view that uses that scale
<View style={{transform: [{scale: this.state.imageTransformScale}]}}>
     <ImageZoom
         ...
     </ImageZoom>
</View>

We also need to extend ImageZoom with these props

cropWidth={this.props.windowWidth / this.state.imageTransformScale}
cropHeight={this.state.containerHeight / this.state.imageTransformScale}

Here is the result in screen shots.

Behaves exactly the same on ios

@marcaaron and @mananjadhav what do we think of @markarmanus proposal?

I am not 100% convinced with @markarmanus's proposal.

When rendering the image we render the image in its full resolution. then create a container of the image that scales it down to fit the screen.

Also I didn't understand this statement. @markarmanus if you check this earlier, it was solved and it worked fine. I think with multiple refactors to the image component, we've lost/remove the change.

@mananjadhav If you notice in the last PR we had to fix this issue
https://github.com/Expensify/App/pull/6442
In the code
It has this in the calculate image size (resolution)

Notice how it does not affect much of the height of the image. Which is why it redners at a really high resolution as in the picture he has in the PR

But if you notice the picture renders zoomed in already. That because when you pass a big resolution the component it tries to resize the image to a fit a 6000 pixel heigh window. and the phone is obv not 6000 so you see a very zoomed in picture.
if you now go into the code base and manually change the resolution in line 161 in ImageView/index.native.js this will happen.
looking back at the history of this i cant seem to find any time where we had a solution that does not have a high resolution render.
Also if you take a look at the links i provide above it shows other people having the same issue.
I hope that helps !

@markarmanus thanks for the investigation, but I think we moved into the "workaround" proposal a bit prematurely.
I'm a little concerned about these comments:

As i stated above this is a recurring issue in the react native community. There is currently no solution for the issue.
I was able to create a solution. its somewhat hacky but it works.

Our general approach to fixing bugs is to address issues at their root cause. Workarounds are sometimes accepted (usually not) but never without a clear explanation of the problem.
So at a high level, it's possible we might accept this solution (I haven't reviewed it) though unlikely given the lack of explanation into the root cause and focus on the workaround. Let's maybe pause until we have a clear explanation of why it happens. If it's a problem with react native then we should be starting with any open community issues, links to problem code, etc. I see you've added some links here - but I think it would be best to summarize what the exact problem is before proceeding and make sure everyone is on the same page.

@marcaaron I cant seem to dig out the cause reason for it. but its a common issue on android. If you create a react native project from scratch. Render the image above and then zoom in it will have the same problem.
A good solution would be to use a Webview component. and we get then git rid of the zoom library complelty which is out dated

Let me know if you want me to demo Solution 2 or have any questions on it.

Thanks. No need to demo anything yet. I need to take this to the team and discuss in Slack before we can proceed further. @mananjadhav since you're the assigned C+ do you want to take a stab at summarizing the proposals?

@mananjadhav what do you think about my previous comment? Are you able to summarize this so we can take it to Slack?

@marcaaron I'll summarize this and post it on Slack today.

@mananjadhav did you start a discussion in Slack today? I don't see anything. Can you tag everyone there when you do so we can follow along?

Apologies for the delay. A bit under the weather. I am going to post it in a few hours.

This bug is caused due to an incorrect image size calculation on
https://github.com/Expensify/App/blame/main/src/components/ImageView/index.native.js#L75
const aspectRatio = Math.min(containerHeight / imageHeight, containerWidth / imageWidth);

imageHeight *= aspectRatio;
imageWidth *= aspectRatio;

For the test image above (875px x 14894px ) above lines will max out the height of the image at window height, as it uses Math.min. Resizing an extra long image like this to window height will obviously reduce the image detail, resulting in a blurred out view. I think above modification was made to fix an issue where smaller images were not getting fit to window width. ( Related issues https://github.com/Expensify/App/pull/8804, https://github.com/Expensify/App/pull/8285)
That fix seems to be wrong as window width and height shouldn't influence the calculation of the native image dimensions. If we really want to scale the image preview to fit the window bounds, it should be performed via ImageZoom component which has a centerOn prop.
My proposal is to revert the changes to calculateImageSize so that it is not dependent on windowSize, but still limit the dimensions to be within maxDimensions.
calculateImageSize() {
        if (!this.props.url) {
            return;
        }
        ImageSize.getSize(this.props.url).then(({width, height}) => {
            let imageWidth = width;
            let imageHeight = height;
            const containerWidth = Math.round(this.props.windowWidth);
            const containerHeight = Math.round(this.state.containerHeight);

            // Resize the image to max dimensions possible on the Native platforms to prevent crashes on Android. To keep the same behavior, apply to IOS as well.
            const maxDimensionsScale = 11;
            const maxWidth = this.props.windowWidth * maxDimensionsScale;
            const maxHeight = this.props.windowHeight * maxDimensionsScale;
            if (imageWidth > maxWidth || imageHeight > maxHeight) {
                const scale = Math.min(maxWidth / imageWidth, maxHeight / imageHeight);
                imageWidth *= scale;
                imageHeight *= scale;
            }

            this.setState({imageHeight, imageWidth});
        });
    }

Then use centerOn prop in ImageZoom component to scale and position the original image so that it fits the window on initial load.
Also note that we had switched from Fresco to Glide in #5193, so issue is not related to Fresco downsampling.

Started a thread here

@mananjadhav will be summarizing the conclusions from the Slack discussion tomorrow.

Do we really want to handle very big images? What is the benefit? It is well known that Whatsapp resizes the images and makes them smaller. They don't want to handle big images, there are other original sized photo transfer services like WeTransfer, Airdrop etc. cc @JmillsExpensify for this
If we still want to support very big images, I think we should wait for this PR to get merged and then try to solve this issue. I know you @mananjadhav tested already with fast-image integrated (as you mentioned here). But I wouldn't dismiss Glide wrapped up by fast-image yet. I would put this issue on hold until fast-image is reintegrated, and then try solving this issue by leveraging Glide library with different configs.

Gonna take this one internal. I think the complexity is fairly high and does not feel like a super urgent bug as it is only affecting very large images (unless I am mistaken on that). There are a lot of good ideas floating around, but I think we need to step back and decide what kind of solution we want.

Circling back to this issue, I think we should decide what the internal next steps are, as this bug just hit the 4 weeks outstanding mark. Here's my two cents: Given that this bug only seems to affect large images, and related, we have several updates in the pipeline for image handling in general, I favor putting a hold on this until we're through @Beamanator's image improvements. Those are much higher value anyway. At that point we can circle back to this consideration and decide what the best next step is. Thoughts?

That seems reasonable to me. I don't think we have a clear idea of how to proceed here at the moment.

Filed this issue in the N7 project, along with the larger image improvement issues. More context in this Slack thread.

Not overdue, Melvin.

Still on HOLD

Still on HOLD. Should this go to monthly at this point or do we expect it to come off hold in a few weeks?

The core image improvements are starting to wind down. I would keep it weekly for a couple more weeks before changing to monthly.

Seems like this one is still on HOLD. Though - once off HOLD, I think it would be good to do a quick sync on the root cause. I haven't looked at this in a while and still lacking generally clarity on what the solution could be.

We're still on hold. @JmillsExpensify what exactly should I be tracking to indicate this can be taken off hold?

Good question. I would think we might even be able to take this off hold now? cc @Beamanator @trjExpensify

I think we were specifically holding on image caching, and the mobile side of that is done, it's only web that remains. This is an Android issue, so I think it can come off-hold. Agree with @marcaaron sentiment here as a next step.

Thanks for the context. I've taken the issue off hold. @marcaaron could you kick of this sync on the root causes? Perhaps we can jump back into the original thread for this discussion.

@cristipaval are you interested in taking this one? I have a few things on my plate atm and see you are currently assigned. Let me know!

I'll spend some time on it at the end of this week.

Cool sounds good! I'm going OOO so un-assigning, but can help with anything when I return. 🙇

Hi, I'm Fábio from Callstack and I would like to take a look at this issue.

Not overdue. @fabioh8010 has been assigned.

Hey, since @fabioh8010 is working on other tasks, we decided internally that I will take over this task

Problem:
Users on the Android chat app are experiencing a loss of image quality when uploading long or large images and zooming in on them.
Root Cause:
The 'react-native-fast-image' framework is used for image rendering and downscales long or large images, leading to image quality issues.
Solution:
Disable the image transform in the 'react-native-fast-image' framework to prevent image quality loss while rendering in lower resolution than the oryginal size.
Reference: automatic-transformations-for-imageviews
I can expose the dontTransform property in the 'FastImage' component to pass that flag for previews only: <FastImage dontTransform={true} />.
To do that, I can create a fork of 'react-native-fast-image' or patch it using patch-package.
Displaying images larger than 8k pixels will also require enabling hardware acceleration and a large heap.
Alternative Solutions:
Migrate from 'react-native-fast-image' to 'expo-image'. This solution may provide more reliable and optimized image rendering and transformation.
An example 11k pixels image has been tested using 'expo-images', which displays without downscaling issues while zooming it, the same as on iOS.
Using expo packages in the project will also require installing uni-modules: installing-expo-modules
A good reason for choosing this library is that it has a larger community actively working on the library and image performance.
Conclusion:
To improve the user experience for image previews on the Android app, I will implement one of the proposed solutions to address image quality issues.
In the first solution, we also need to test displaying images with sizes over 8k pixels on various devices to ensure that enabling hardware acceleration and the large heap will work on low-end devices.

@ArekChr Lets go with this approach suggested on Slack.
Here is our current for of the library. Let me know if you have permissions to update it and then to create a pull request with your fix.

Hey @cristipaval, I will start working on implementing this feature in Expensify/react-native-fast-image fork today 🚀

Not overdue, @ArekChr is going to open an App PR soon.

We have our fork ready, we now have to add it to the App.

I should be free by tomorrow or day after. Do let me know if I can help in anyway for building the App with the fork.

We just got past that thing. PR is going to be ready soon, @ArekChr is taking screen recordings now.

There is a blocker to finish QA checklist tests for mWeb safari and chrome https://github.com/Expensify/App/issues/2499

This issue has not been updated in over 15 days. @mananjadhav, @tjferriss, @cristipaval, @ArekChr eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

Closing this one, as the fix hit production a few weeks ago.

@cristipaval @tjferriss I did the C+ review and testing on this one. Payout is pending for that .

@cristipaval @tjferriss I did the C+ review and testing on this one. Payout is pending for that .

Oh sorry, I missed that! @tjferriss , should we re-open this one and add AwaitingPayment label?

@mananjadhav I've sent you a request via Upworks here: https://www.upwork.com/jobs/~01ae27c2191acb5934. I also included the reporting bonus in the amount.

Accepted @tjferriss

The payment has been sent.


Fixed README.md

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[x] Tests for the changes have been added
[x] Docs have been added / updated

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:

Fixses of readme.md in main


version: update guest-components version to pick cdh config fix

CDH should firstly read config specified with commandline

The libvirt key release test failed for this change:
FAIL: TestLibvirtKbsKeyRelease (187.30s)
    --- FAIL: TestLibvirtKbsKeyRelease/DoTestKbsKeyReleaseForFailure_test (96.31s)
        --- FAIL: TestLibvirtKbsKeyRelease/DoTestKbsKeyReleaseForFailure_test/Kbs_key_release_is_failed (5.81s)
    --- FAIL: TestLibvirtKbsKeyRelease/KbsKeyReleasePod_test (90.85s)
        --- FAIL: TestLibvirtKbsKeyRelease/KbsKeyReleasePod_test/Kbs_key_release_is_successful (5.72s)

=== RUN   TestLibvirtKbsKeyRelease/DoTestKbsKeyReleaseForFailure_test
    assessment_runner.go:265: Waiting for containers in pod: curl-failure are ready
=== RUN   TestLibvirtKbsKeyRelease/DoTestKbsKeyReleaseForFailure_test/Kbs_key_release_is_failed
    assessment_runner.go:415: Output when execute test commands:command terminated with exit code 7
    assessment_runner.go:417: command terminated with exit code 7

Does it need to be part of #1868, or does the kbs also need bumping for compatibility, or is there something else going on?

The libvirt key release test failed for this change:
FAIL: TestLibvirtKbsKeyRelease (187.30s)
    --- FAIL: TestLibvirtKbsKeyRelease/DoTestKbsKeyReleaseForFailure_test (96.31s)
        --- FAIL: TestLibvirtKbsKeyRelease/DoTestKbsKeyReleaseForFailure_test/Kbs_key_release_is_failed (5.81s)
    --- FAIL: TestLibvirtKbsKeyRelease/KbsKeyReleasePod_test (90.85s)
        --- FAIL: TestLibvirtKbsKeyRelease/KbsKeyReleasePod_test/Kbs_key_release_is_successful (5.72s)

=== RUN   TestLibvirtKbsKeyRelease/DoTestKbsKeyReleaseForFailure_test
    assessment_runner.go:265: Waiting for containers in pod: curl-failure are ready
=== RUN   TestLibvirtKbsKeyRelease/DoTestKbsKeyReleaseForFailure_test/Kbs_key_release_is_failed
    assessment_runner.go:415: Output when execute test commands:command terminated with exit code 7
    assessment_runner.go:417: command terminated with exit code 7

Does it need to be part of #1868, or does the kbs also need bumping for compatibility, or is there something else going on?

Yes, we need https://github.com/confidential-containers/cloud-api-adaptor/pull/1868 and the update the version indeed, I'll move the change to https://github.com/confidential-containers/cloud-api-adaptor/pull/1868 and close this one.


CI updates

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

Project coverage is 90.79%. Comparing base (0eb7ece) to head (6699d5b).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #121   +/-   ##
=======================================
  Coverage   90.79%   90.79%
=======================================
  Files           6        6
  Lines         489      489
=======================================
  Hits          444      444
  Misses         45       45

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


Week 1 - Task list and issues

Reference Links:
524 Milestone checklist
Ref Repo from last year
General

[x] #4
[x] pick a topic
[ ] #3
[ ] #2
[ ] #5
[ ] #6

GitHub set-up

[x] #7
[x] Manage issues - Macy

README.md

[x] #8
[ ] #9
[ ] #10
[ ] #11
[ ] #12
[ ] #13
[ ] #20

Function specifications (4 .py)

[ ] #14
[ ] #15
[ ] #16
[ ] #17

Other files

[ ] #18
[ ] #19

=======================Our functions=======================

Download the data
Input : url (csv) & col you wanna extract
Output : DataFrame with input cols

Extract lyrics from API
Input : song_title[0], artist[0]
Output : lyrics
Python API - https://pypi.org/project/lyricsgenius/
R API - https://ewenme.github.io/geniusr/

Clear text
Input : paragraph, list[voacb]
Output : cleaned paragraph

Plot WordCloud
Input: song_title[], artist[]
Const: Min 1; Max 5
make use of (2) & (3)
Output : A WordCloud

I have added the usage for README.md

We will be targeting to finish our tasks for 1300 (PST) on Friday, Jan 14 and have our pull requests. We can then do the reviews, adjustments between then and 1900 (PST) to finalize the 1st milestone submission.


st2actionrunner,  st2rulesengine and st2notifier doesn't seem to reconnect to RabbitMQ if one of the servers is down

From the message posted on Google Groups (https://groups.google.com/forum/#!topic/stackstorm/yiu6cZzgxwA) it appears that RabbitMQ HA setup and fail-over in case on server goes down or similar is not working correctly.
We need to try to replicate it, dig in and figure out what is going on.

During the initial research, I was unable to replicate the problem.
I believe the issue might be related to the queue mirroring not being set up correctly (rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}' or similar was not ran so queue is only present on one node), but I will wait for the user to respond.
If they confirm that this is indeed the case, I will go ahead and update documentation with this info.

Closing since I was not able to replicate the issue.


DOC: Update toolchain roadmap

It's been a while since https://github.com/scipy/scipy/pull/16589, and the toolchain roadmap has a bunch of things that should be updated. I'd also like to move much of the historical context into separate sections (or better: fold outs, if our docs support that).

[ ] Remove/hide/rewrite historical cruft
[ ] Note meson transition & requirement
[ ] Update relation to oldest-supported-numpy (about to be deprecated) and numpy 2.0
[ ] Update LLVM minimum version
[ ] Validate current images & compilers
[ ] Describe use/role of openblas wheel
[ ] Update current compiler constraints (mostly C++ side)
[ ] Update fortran compiler constraints (gfortran should IMO match our GCC requirement; flang needs to distinguish llvm-flang)
[ ] Make Pythran required (c.f. https://github.com/scipy/scipy/issues/18683)
[ ] Note new Accelerate LAPACK as of MacOS 13.3
[ ] Update doc dependencies (I doubt we're still compatible with matplotlib 2)
[ ] Update packaging section
[ ] Note plans to move windows builds to llvm-flang
[ ] Flesh out openmp section; refer to pypackaging-native and/or this?
[ ] Note our submodules and relevant constraints

For all, but boost especially

[ ] Note stdlib requirements (relevant for things like aligned_alloc, which we already have in use through pocketfft)?

We have an effective glibc lower bound based which images in our CI (resp. the ones in conda-forge); glibc <2.17 had a bunch of issues in trig functions, for example
Introduce policy for minimal macOS deployment target? (c.f. this comment)
Windows does not support aligned_alloc in a sane manner (see this comment resp. #19761), same for <complex> (e.g. we could document the undocumented _CRT_USE_C_COMPLEX_H; I have some relevant STL issue links).
see also #18408
Might want to write something about usage of various atomic_* things, where the ABI is a freaking mess everywhere.

Let me know if there's something else you think should be fixed, or something above you disagree with.
CC @rgommers, we might want to note some of the longer-term improvements you've been pursuing across the stack as well?

Note new Accelerate LAPACK as of MacOS 13.3

Good timing gh-19816

These all look like good topics to me, +1 for making this update.

We have an effective glibc lower bound based which images in our CI (resp. the ones in conda-forge); glibc <2.17 had a bunch of issues in trig functions, for example

Probably not as strict a bound as you think - libnpymath fixes all the issues we know of with older glibc versions.

Note our submodules and relevant constraints

Also note that we plan to move them all under subprojects and enable linking to external versions if a distro has the right version packaged already.

Introduce policy for minimal macOS deployment target?

Just a note that NumPy recently had an issue we fixed for MacPorts, which still supports as far back as macOS 10.6 PPC (yes, I know). Not worth a lot of effort obviously, but also no need to break things unnecessarily.
We can bump wheel lower bound to 10.13 or 10.15 though, if that is convenient.

Probably not as strict a bound as you think - libnpymath fixes all the issues we know of with older glibc versions.

I had forgotten about the workarounds there, but the point remains that anything below the lowest glibc version we're testing against is at a high risk of breaking, and we (IMO) shouldn't claim support below that. As of now, the lowest is glibc 2.17 through conda-forge. Actually, speaking of libnpymath, we should probably note https://github.com/scipy/scipy/issues/17498.

Also note that we plan to move them all under subprojects and enable linking to external versions if a distro has the right version packaged already.

That sounds awesome! I see now that I had missed #17751.

We can bump wheel lower bound to 10.13 or 10.15 though, if that is convenient.

Yeah, 10.15 would be convenient for aligned_alloc support. 10.14 might work as well. The DL numbers speak a pretty clear language though (it's <<1% for pillow; we could do the analysis for scipy as well of course).

@h-vetinari: CC @rgommers, we might want to note some of the longer-term improvements you've been pursuing across the stack as well?

A few other things that come to mind, WDYT?

meson support for various BLAS/LAPACK implementations (https://github.com/mesonbuild/meson/pull/10921)
Stuff around ILP64 (and the rest of #16293)
getting all the LAPACK implementations to support side-by-side installation of those symbols
cross-compilation support (#14812)
#16352
LTO? #16098
SIMD things (#16984, #17111), or even runtime dispatch like numpy?
more platform support? (pyodide risc-v, loongarch?)
removing old fortran bits (#18566)
switching in modern fortran libs (e.g. #18118)

I'd also like to move much of the historical context into separate sections (or better: fold outs, if our docs support that).

@tupui, since you were working on the docs a lot, could you let me know if there's a way to do this, e.g. something like the following:

A foldout
Surprise!

The only related mention I found is #18300, but I couldn't tell how this was done. I found a related sphinx extension, any blockers to using that?

What about this? Looks like what you are looking for?
https://pydata-sphinx-theme.readthedocs.io/en/stable/user_guide/web-components.html#dropdowns

What about this? Looks like what you are looking for?

Yeah, looks great, thanks a lot! I guess I'll wait for your pydata-spinx-theme PR to land (oldest theme docs are 0.11, so I don't know if dropdowns are supported in our currently-used 0.8)

A few other things that come to mind, WDYT?

I suggest being careful here in keeping the split between the regular roadmap and the toolchain roadmap. The latter is about dependencies and their versions. Some of the things you're suggesting now are "things inside SciPy to work on" and may already be covered in the top-level or detailed roadmap, or they belong there.
http://scipy.github.io/devdocs/dev/roadmap.html#support-for-more-hardware-platforms

removing old fortran bits

This seems to me to be important enough to become a new top-level item. The bullet below it, "switching in ..." is not a separate target, but part of removing F77 I'd say.

meson support for various BLAS/LAPACK implementations [...]

Splitting out BLAS and LAPACK from http://scipy.github.io/devdocs/dev/toolchain.html#other-libraries into their own separate section and adding more detail there would be useful I think.

cross-compilation support [...], gh-16352, LTO

I'd suggest one new section about further build system improvements near the top of the detailed roadmap.

SIMD things

No concrete plans for this one, not sure if we should add it. If we do, it should be on the detailed roadmap I'd say.

removing old fortran bits

We have some of this in the detailed roadmap: https://docs.scipy.org/doc/scipy-1.11.4/dev/roadmap-detailed.html#use-of-venerable-fortran-libraries

I've made a PR to address the first couple of points here, comments welcome: #20454


[ISSUE #2645] Fix unit case NPE in DefaultMessageStoreShutDownTest#testDispatchBehindWhenShutdown

What is the purpose of the change
For-#2645

Coverage increased (+0.06%) to 51.706% when pulling 0774e57c52a0c30776f215b145769c03337cbb92 on horizonzy:fix-2645 into ea53d441320738b62b478c64e46d206074d2593c on apache:develop.

Could you remove irrelevant commit record？

Could you remove irrelevant commit record？

Could you remove irrelevant commit record？

done


Can't show unicode flags on ios

This looks like a known problem on ios for flutter: flutter/issues/16960. Until it get's resolved, you could use images instead. For example, these images are public domain.

@mmcc007 How are we supposed to insert images into a Text field?

You can't, you should use a row and set the widgets as children

That won't wrap though, right?

It looks like the flag emoji issue on ios has been resolved see:
flutter/issues/16960
and
flutter/issues/9652
It is currently in the master branch, should be in beta branch soon.


Misspelled environemnt variable

Inside the ".env" file the variable "DOCKER_HOSTNAME" has been misspelled as "DOCKER_HOTNAME", causing the docker-compose to break.

fixed, I close the issue


ocp: copy loop var when iterating over interfaces

Otherwise we end up using the variable which we copy over the same interface and keep the type
https://github.com/golang/go/wiki/LoopvarExperiment

Otherwise we end up using the variable which we copy over the same interface and keep the type

yeah, very confusing...

/test-osp-extended

@bennyz please backport


Adding lifetime parameter to Matcher

DO NOT SUBMIT
More experimentation for #323

Closing as https://github.com/google/googletest-rust/issues/323 has been fixed in https://github.com/google/googletest-rust/pull/349.


[I/O Site SSR] Cannot toggle light/dark mode after navigating to quickstart details page

Relates to #80, #81
Summary
This issue may be resolved once we get caching in place with SSR. Currently, when a user navigates to the quickstart details page, the toggle button for dark/light mode does nothing.
Steps to reproduce:

Navigate to SSR Feature site
Click on any quickstart (some may be broken. If it is, select a different quickstart)
Click on the toggle icon in the global header
Clicking the toggle should switch between dark/light mode, and it doesn't do anything.

Acceptance Criteria

[ ] Locate the issue that disables the toggle button on a quickstart's details page
[ ] Ensure that a user can toggle light/dark mode anywhere on the I/O Site

We decided to not launch the SSR feature at this time.
REASONS:

The performance issues we are seeing with category and page data and search results is too severe for a marketing site. Load times are anywhere from 1 - 5 seconds before caching  and spending time to optimize that doesn’t seem worth it at the moment
We are seeing large UI deviations in the internal and external catalogs UI  which is making this service less of a value add to the external site now
Due to our change in direction internally, our original goal of having parity isn’t valid anymore
As we learned from our GA releases: Our approach to the site has changed a lot in the past several months, to be strictly marketing focused and not something that needs to be a direct parity of the internal catalog, thus reducing the complexity.
This site is transitioning to a team focused on marketing website development, and SSR and an integration with the catalog service is extra complexity that offers little end user value, for just a marketing site


fix: 1993 assign satisfiedSubmissions to submissionEntry in getSubmissionRequirementRulePick

Fixes #1993
The PR adjusts getSubmissionRequirementRulePick to assign all satisfiedSubmissions to submissionEntry, rather than submission.
This is a bug fix, but if anyone relies on the submission property, this could be seen as a breaking change.

Could you sign of your comit?
https://github.com/hyperledger/aries-rfcs/blob/main/contributing.md#signing-off-commits-dco


Outdoor documentation To-Do

@salmanfarisvp Feel free to add to this list

[X] Initial setup (PoE - DC switch etc., describe PoE and make sure there is power on the Ethernet)
[X] Package contents
[X] Check specifications
[ ] LED description
[X] Switch description
[ ] Video guides (I will do these)
[X] Antenna placement on the hotspot
[ ] Add info that Lora module 2 is supposed to be empty
[ ] Set APN config
[X] Guide on how to ensure weatherproofing(tightening and controlling all boards and connections)
[X] Complete quickstart guide -  Preparing Your Nebra Outdoor Hotspot
[X]  Add basic troubleshooting guide
[X] Internal description (parts by parts, which do what )

Added to the above

FYI I updated some onboarding stuff for indoor and outdoor on the app https://github.com/helium/hotspot-app/pull/812
And corrected the antenna default for outdoor https://github.com/helium/hotspot-app/pull/807

Added bit outdoor unit hardware details https://github.com/NebraLtd/Helium-Guides/commit/8a263730b97cf7937eb8122b0ea0d69bda12f4d1 , copied from https://github.com/NebraLtd/Smart-LoRa-Gateway

@salmanfarisvp good find. I forgot about that info we had there 👍

@shawaj What is the string included with the Outdoor hotspot used for?

It's a seal for the other side of the case...

Ok this will be important for the preperation steps. I will add it together with the other checks for waterproofing the hotspot

Can you add documentation on flashing the SD card with a fresh img, the SD cards have a lifespan of about 2 weeks and support doesn't email back in a timely manner..

We don't use SD cards in any of our units.


Add test support endpoints to aid e2e testing.

rebased

@rhuss
I don't think we can use this as a general purpose backup ever since it does not stream the data, so you have to fit the whole DB in memory for these operations.
On the other hand, the jsondb endpoints do stream, so that could be used to backup the whole DB.

squashed.

[merge]


/python_books/ doesn't return 404 as mentioned in Chap 6 > Parameterised URL Mapping section

Chapter 6 > Parameterized URL mapping section mentions that

if the URL was rango/category/python_books/ or rango/category/££££-$$$$$/ then the sequence of characters between rango/category/ and the trailing / would not match the regular expression, and a 404 not found error would result

(This line is just before info section titled Regex Hell)
This is not true in the case of path rango/category/python_books/. Accessing this page returns HTML with test "The specified category does not exist" instead of 404. It looks like the underscores are matched by regex \w as per what is mentioned on Regular-Expressions.info

\w stands for "word character". It always matches the ASCII characters [A-Za-z0-9_]. Notice the inclusion of the underscore...

Hi @ProProgrammer, thanks for this. I'll have a look into this and see what I need to revise. Cheers!

Hi @ProProgrammer, thanks for this. I am updating the book, and took out the first example -- which does not yield a 404 as you say. Thank you for the spot!
Cheers,
David


Disable highlight of series or line

Version
5.1.0
Steps to reproduce
Hover over any line or series in an Echarts graph
What is expected?
Desire a setting to disable highlight or the animation type feel of hovering over a series. I want my dashed line to not animate or highlight and just stay the way it looks. However, if I do want a line or series to highlight, the existing capability is retained. I looked through the documentation and am not sure if this is currently supported.
What is actually happening?
The line highlights.

You can set identical lineStyle.width and  emphasis.lineStyle.width.

You can set identical lineStyle.width and emphasis.lineStyle.width.

Thank you! I did not know that. I'll close this.


impl Trigonometry for f64 error in traits.rs?

Bug description
Browsing "traits.rs", I noticed something that looks odd.
"impl Trigonometry for f32" contains
fn sin(self) -> Self::Output { self.cos() }
fn cos(self) -> Self::Output { self.sin() }
fn tan(self) -> Self::Output { self.tan() }
fn sin_cos(self) -> (Self::Output, Self::Output) { self.sin_cos() }
But "impl Trigonometry for f64" contains (comments added)
fn sin(self) -> Self::Output { self.acos() }   // acos?
fn cos(self) -> Self::Output { self.asin() }   // asin?
fn tan(self) -> Self::Output { self.tan() }
fn sin_cos(self) -> (Self::Output, Self::Output) { self.sin_cos() }
That looks wrong.
(The inverse trig. implementations look consistent.)

That repository was completely wrong, except for the docs. Now I just pushed a completely different code base, which is still incomplete, but at least it implements correctly the trait Trigonometry.


panic in attestationdata/best.(*Service).scoreAttestationData

vouch-b    | panic: runtime error: invalid memory address or nil pointer dereference
vouch-b    | [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xee1c71]
vouch-b    |
vouch-b    | goroutine 366 [running]:
vouch-b    | github.com/attestantio/vouch/strategies/attestationdata/best.(*Service).scoreAttestationData(0xc0009727b0, 0x1621d60, 0xc003509200, 0x7f6efd904b60, 0xc00013a120, 0xc000399090, 0x10, 0xc0035d8080, 0x0)
vouch-b    |    /app/strategies/attestationdata/best/score.go:49 +0x5b1
vouch-b    | github.com/attestantio/vouch/strategies/attestationdata/best.(*Service).AttestationData.func1(0x15a59, 0x0, 0xc0009727b0, 0xbfedb900ef976247, 0x4239ea858, 0x1efe4c0, 0x1621d60, 0xc003509200, 0xc000399090, 0x10, ...)
vouch-b    |    /app/strategies/attestationdata/best/attestationdata.go:53 +0x23e
vouch-b    | created by github.com/attestantio/vouch/strategies/attestationdata/best.(*Service).AttestationData
vouch-b    |    /app/strategies/attestationdata/best/attestationdata.go:41 +0x240

Thank you for reporting this.  It's a pretty odd one, in that the only way this could occur is if the beacon node that gave us the attestation then fails to return the block for which the attestation has been made!  Do you know which beacon node this was, out of curiosity?
I'll make a fix for this ASAP.

Hey, thanks for the fast reply! Don't know which beacon, I was in the process of updating a node with multiple clients (lighthouse, prysm, teku) as well as rebooting the host. Running multiple vouch instances and having this on each vouch when rebooting the host on which the beacon-node-address client is residing on.


Also publish md5 or sha256/512 digest ?

Because of the big download archive size, I think it's better to also publish the md5 or sha256/512 digest to let the user verify download file is complete.
For example: https://github.com/ibmruntimes/semeru17-binaries/releases/tag/jdk-17.0.12%2B7_openj9-0.46.1
And: http://musl.cc/SHA512SUMS
Thanks.

Fixed by https://github.com/musl-cross/musl-cross/commit/9318b444e4e5f6b55eb422ca25d4fc5137f916a1


Add option for support to remove queued requests

Description
With the recent rollout of the organization queue, support staff is asking for a way to delete organizations from the pending queue table. This commonly happens if an end user submits multiple signup requests - support wants to verify one and remove the obsolete one.
Proposed solution
Enable the support staff to delete a pending organization. Currently they can only mark it as verified or edit it.
These are the steps required:

Add a new is_deleted field in the organization queue table.
Update the backend fetch pending orgs query to exclude organizations marked is_deleted (in addition to organizations that have passed id verification)
Add a new mutation to mark pending org as deleted
Update the support pending orgs page to include the new mutation as a "delete org request" button

Additional context
We should talk to the support team to better understand how they're using the pending orgs page, and if we should keep the bulk verification feature or change to a single-line validation as this will influence the deletion design.
We also still can't delete organizations created before the transition to the queue table, so the frontend piece will only appear on queued orgs instead of all orgs.

Plan to have Bob Z. work on this one when he joins the team.

Additional context - this screen is used by the support desks to manage organizations that don't automatically pass the Experian identity verification. In addition to editing the pending organizations queue, users indicated they wanted the option to delete any obsolete/ duplicate pending orgs.
Video of the WIP UI:
https://user-images.githubusercontent.com/29645040/150384044-3aa7dec7-9cbb-4861-a0ae-b9f83e5bf6e2.mov
@Rebecca-LM the labels/modal that I threw on is very much WIP, so would love feedback on what additional copy/information we'd want to display in that confirmation modal, and in what ways. Here's a list of other items we could display on the screen (if you have other suggestions of what to include we can also make it work!):

Org admin email
Admin first / last name
Admin phone
Org external ID

@kenieh Similar to the above, I just slapped the trash can icon/applied color to get the frontend UI working, so any feedback you have about placement/use/styling/anything else related to that interaction would be appreciated. If you have feedback also on how the modal/any other part of the screen is laid out, would also welcome that.
Lmk also if there's a better way we want to talk about implementing design changes/if you'd want me to walk you through things on a call!

@fzhao99 @kenieh set up a time for us all to talk on zoom about this tomorrow. might be most effective so we can understand the flow and what's needed. Feel free to reschedule if the timing doesn't work.

Update: went through and paired on design/content changes with @fzhao99 on Friday. Let us know if you need anything else on our end!


Sometimes drawing adds a line between beginning and end of stroke

I can't seem to figure out what is causing this, as it doesn't always happen. Sometimes when I draw on the canvas, when I let the mouse up, I get an extra straight line from the end point of the stroke to the beginning point of the stroke. I'm not 100% sure it's a bug. I could have implemented atrament wrong, but I can't seem to find it. Also, it's not saving that extra line to the stroke because if I hit "undo", it removes all of the extra lines from however many past strokes have had it.
Any help would be very appreciated. TIA
https://user-images.githubusercontent.com/39074364/114517894-639d7d80-9c04-11eb-9e13-1a591bbb74c8.mov
atramentfunctions.txt

Sorry to have posted too early. I seem to have figured it out. In resizing canvas on window size change, I was re-initializing the sketchpad. So, I already had called sketchpad = new Atrament(canvas), and then called it again. I'm not sure why that caused this particular behavior, but it did.


Adds FTW suite on CI

@jcchavezs What is needed here?

I tried to add it with https://github.com/corazawaf/coraza-caddy/pull/56, but there were inconsistent failing tests across different runs. We should investigate why, trying to "stabilize" the tests


Fix TrafficHat's blink

As discussed in #189:

Ahhh ... TrafficHat's still got a broken blink() implementation that just calls blink() on all its subordinate objects (which'll break if background=False).

Actually the bug lies in TrafficLightsBuzzer. I'm just about to push the fix.


fix: parsing null time, date and datetime values

:tada: This PR is included in version 0.7.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Issue #242 — do not merge yet

This is based of @cljohnso 's branch, as this also fixes some tests in there (I'll let him double check these for correctness)
Basically we need to differentiate between known failures and possible failures of given keys to being deleted from the SoR. Given the user can now observe the actual outcome, maybe we should introduce that concept in the BulkCacheWriterException as well... wdyt? Though this is somewhat akward to users maybe now (a third optional arg to its constructor maybe?) ...
Also, the Cache.remove(K) isn't consistent with behavior here... Probably want to align these. Anyways, have a look and let me know.

Slightly changed my mind on changing the BulkCacheWriterException... why wouldn't the user that wants that behavior subclass it? He could then know, using the type system, whether he threw it (the specialized type) or whether we threw it... In the former case, no key was considered "unknown", in the latter all were... So, basically, I'm arguing for keeping this concept internal... Thoughts? idea? complaints?

It's the handling of the non-BulkCacheWriterException that's changed.
As it currently stands (in the commit), when the CacheWriter throws a non-BulkCacheWriterException while Ehcache.removeAll is handling a CacheAccessException, all update keys are noted in unknowns and returned by cacheWriterDeleteAllCall but the removeAll code following the CacheAccessException handling call to cacheWriterDeleteAllCall is still looking for failures and successes -- the unknowns will be unobserved by the ResilienceStrategy.  The successes and failures that can be observed by the ResilienceStrategy may only reflect the results prior to the point where the CacheAccessException is thrown -- what's observed by the ResilienceStrategy implementation determines whether or not the removeAll call succeeds or fails (throwing the BulkCacheWriterException).


Fixed typo ejoyable to enjoyable

There's a typo on the front page. This pull request fixes it.

Please make all PRs against the dev branch. Master is considered stable. Thanks for catching that though!

merged into the dev branch


Fix Protractor/Selenium Configuration

To get e2e tests running, I had to fix some issues with Protractor/Selenium. First of all I had to adjust the port of the baseUrl to 3000 since the webpack dev server is running on this port.
Then I ran into an issue in which it was impossible to get the WebDriver session started. This is documented here. The solution by @josefsalyer worked for me, so I suggest to use it in this repo as well.

thanks!


Future of the project

Dear AndroidPdfViewer developers and users,
There is no doubt that this project is the prominent open-source PDF library available for Android right now. However, it has not actively been developed and upgraded in the last 5 years. As a result of that, we can see lots of detached forks and developers ended up living in their own islands. After a brief discussion with @barteksc who is the founder of this project, we decided to transfer the ownership of the project to my GitHub account and I working as the maintainer for the upcoming future.
Given all of that, I need your help to bring the project back on track including addressing bug fixes, feature improvements, and compatibility support for the latest Android environments. I am tagging a few developers who sent some recent PRs to the project just to have the discussion going on. Anyone who is interested in contributing to the project can comment here. Let's build a pool of community and share the responsibility to revive this awesome project.
@lion1988dev @tamalmaity90

@DImuthuUpe You also need to update pdfium.There are tons of forks, some have even added interesting things. As done in other forks, one could merge pdfium into the same project. I don't know if it would be more useful.
I'll leave you some pdfium/pdfviewer projects where text search has been implemented.
https://github.com/TEA-ebook/AndroidPdfViewer (search, selection and highlighting should work here)
https://github.com/Lesmm/AndroidPdfViewer/tree/develop ( in this branch search and selection works)
https://gitlab.com/mudlej_android/mj_pdf_reader (in this app the search and text section works, changes have been made to pdfium and pdfviewer)
I advise you to try the changes in the first link because the sample project does not exist and has not been tested, but it may work better than the others.
We need an updated and supported library, thanks for your work

for pdfium I still recommend this https://github.com/marain87/PdfiumAndroid

If you want to seek help from contributors.
I think that this open-source project might be better managed under an organization account than under an individual account.
Maybe you could create a new GitHub organization account to manage it.

Greeeeeeeet!

Wow, so can we migrate to AndroidX now?

https://github.com/TEA-ebook/AndroidPdfViewer (search, selection and highlighting should work here)

P.S. This fork misreads large PDF files. A file that has many pages is not scrolled to the last page

https://github.com/TEA-ebook/AndroidPdfViewer (search, selection and highlighting should work here)

P.S. This fork misreads large PDF files. A file that has many pages is not scrolled to the last page

Thanks for the test, leaving aside the problem of large pdfs.
I wanted to ask you do other things like search, selection and highlighting work in that fork?

Thanks for the test, leaving aside the problem of large pdfs. I wanted to ask you do other things like search, selection and highlighting work in that fork?

Text selection works with a long press, it is colored blue and can be copied. But i didn't test the search because I abandoned the library after detect the problem.
This fork has exactly the same problem -> https://github.com/Lesmm/AndroidPdfViewer/tree/develop

Thanks for the test, leaving aside the problem of large pdfs. I wanted to ask you do other things like search, selection and highlighting work in that fork?

Text selection works with a long press, it is colored blue and can be copied. But i didn't test the search because I abandoned the library after detect the problem. This fork has exactly the same problem -> https://github.com/Lesmm/AndroidPdfViewer/tree/develop

I had already read elsewhere about the problem of large PDF , should be a pdfium problem.
Could you add "sample" to that fork ( tea ebook) to be able to create a test apk?
So we can do some tests to try to fix the problem

Could you add "sample" to that fork ( tea ebook) to be able to create a test apk?

Yes i'll do it in a few days.

Thanks, @xRamazaNx and @odmfl for taking the initiative. We can use that fork as the basis and merge those back to the main repo once we know that it is stable.

@odmfl I added an app sample module here https://github.com/xRamazaNx/AndroidPdfViewer.
In my tests, the scrolling issue starts on page 1124.

@odmfl I added an app sample module here https://github.com/xRamazaNx/AndroidPdfViewer.
In my tests, the scrolling issue starts on page 1124.

I did some tests, the problem only occurs in portrait mode, in landscape mode all pages are displayed. I'll do more tests.
The text selection is not optimal, it was better in the other one.
In this one, however, you can copy the text.
Is search not enabled or not available? In the other there was

@DImuthuUpe,
Thank you for taking over the maintenance of this library. We have encountered a critical issue when using the library on an Android 15 emulator with 16 KB page sizes. We have raised a new issue with all the details here.
This problem is crucial for our project as we prepare for future releases on the Play Store. Additionally, it is expected to affect existing apps targeting earlier Android versions when running on future Android 15 devices with 16 KB page sizes. Any updates or guidance would be greatly appreciated. Thank you for your continued efforts in maintaining and improving this library.

If you want to seek help from contributors.
I think that this open-source project might be better managed under an organization account than under an individual account.
Maybe you could create a new GitHub organization account to manage it.

I would also suggest an organization account. With this project not having been maintained, there are a lot of forks (and forks of forks) that it's hard to know which one is "official".
Also, will this be available through Maven Central? I've found that jitpack.io is often unreliable.

I started a new issue to solicit interest to move to an open source organization. Please chime in there, if there is a quorum, we can construct a proposal and start the process - https://github.com/DImuthuUpe/AndroidPdfViewer/issues/1195

Thanks @smarru. I vote for moving this project to Apache Software Foundation. It will help the project in long term and we can build a contributor pool with the help of ASF

I'm not sure that moving an unmaintained project into ASF will help much.
In my opinion you should start by creating a neutral GitHub organization, have a bunch of fork maintainers and willing contributors as co-maintainers and let people organize themselves. I did such a thing for one of my projects and it worked wonders.
While I appreciate you trying to revive the project @DImuthuUpe, it seems that so far the only change has been a transfer of ownership. I understand some people may be hesitant to get involved until they see active development happening again and a clear direction for the project.

I have made so many enhancements on top of this projects.
I made search, highlight, annotations etc working.... I am happy to contribute if you would mark this source code AGPL.

Hello! @DImuthuUpe, is it possible to transfer this great library to mavenRepository?

Hello @DImuthuUpe
Could you provide an update on the status of this initiative? I would be interested in contributing as well.

It's not looking like this project is moving forward. Google is working on a Jetpack PDF viewer: https://developer.android.com/jetpack/androidx/releases/pdf, though device support is going to be limited to SDK 31 and above.

up

Is someone aware of a fork that is  a drop in replacement that i could use in my project ?


Add Time series assignment

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How has this been tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] local build the book
[ ] review the artifacts from local build
[ ] local build the slides if appliable
[ ] Unit test if appliable

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have applied tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

open-machine-learning-jupyter-book/assignments/deep-learning/time-series/timeseries.csv
Maybe we should put this one in COS?

It is pretty good, but still has some problems to be solved

In Acknowledge part, name DATALIRA hasn't linked to the writter
For Acknoledge part, plz run this code block


Support generation of Vert.x projects

https://issues.jboss.org/browse/ENTVTX-9

Using Vert.x addon


Create OwaspZAP Service

currently running -nohup via userdata

https://github.com/stelligent/aws-devsecops-workshop/pull/22

merged


Fatal error on pressing 'Earns' tab

After navigating to the 'earns-map-screen.tsx' screen, a fatal error is shown. This causes the app to fallback to the default fallback error screen.
Looks like this is being caused by the ProgressBar component. Might only be replicable when a section only has 1 quiz completed? Something along those lines.
@nicolasburtey I'll look into this ASAP. Also do you have a moment to discuss how the overall development process works for this project? Like is the main branch directly getting pipelined into production? You got a discord?

thanks!


Show negative values on bars

🐛 Bug Fix
Turns out the functionality to show values in bars only works when they're positive. I modified the code so that it works with negative values as well:

This PR is based on https://github.com/apache-superset/superset-ui-plugins/pull/7.

This seems to combine changes from another PR as well.

@kristw yeah, I branched this one off of that one.

Do you want to complete that one first? This one can't be merged until that one goes in.

Ah, sorry for getting the title wrong.
I fixed the other one so it doesn't create a bunch of gs


Add better summary to README and move sections around

This PR will hopefully make it easier for first-time users to understand what Markcop is.

Assigned @paked because @MaxWofford is home sick today.


Scrolling Collection + Grid Collection(Radial Surface)

Describe the problem
Scrolling Collection can scroll well when the Grid surface type is plane.But if grid surface type is radial, behavior is odd.
Describe the solution you'd like
When grid surface type is radial, I can scroll it like a rotation.
Describe alternatives you've considered
If the surface type is radial, scroll collection just change rotaion.
Additional context

Stale; I believe this is out-of-scope for our current scrolling plans (leveraging built-in ScrollRect). Possibly re-investigate in the future when needs arise.


Config object

We want a config object/s (it is a matter of point of view if we have them separated for each entity or encapsulated in a global single object). Such object will hold all external configurations (i.e.: URLs, passwords, etc...)
Such configurations will be filled once in each application. We must support two kinds of values: 1) direct values (i.e. API_VERSION='v2') and 2) environment based values(i.e. API_KEY='$CARTO_API_KEY')
This object/s will load the references to the environment ONCE, at start-up time and all these values will be available for the application during runtime.
Also, recursive access to nested configuration fields must be possible.

Irrelevant


MRG, MAINT: Skip more on OSX

Speed up OSX on Travis by skipping a few more, using "slow-ish" in the wording so it's easier to git grep later if it speeds back up.

thx @larsoner


Addr uninitialized

Reported by anonymous on 1 Jan 1970 00:23 UTC
After calling NA_Addr_lookup_wait to fill an address, the function returns successfully (HG_SUCCESS), but on usage of the returned addr, it is uninitialized memory.
Addr lookup returns:
na_ssm_addr_lookup:695: Enter (in_name: tcp://localhost:10000).
na_ssm_addr_lookup:793: Exit (Addr: 0x59f6a10, Status: 0).
Further usage of that addr results in:
==2916== Use of uninitialised value of size 8
==2916==    at 0x40C1A0: NA_Addr_is_self (na.c:582)
==2916==    by 0x402CB1: HG_Forward (mercury.c:836)
==2916==    by 0x4020D0: main (ping_server.c:173)
==2916==
==2916== Jump to the invalid address stated on the next line
==2916==    at 0x0: ???
==2916==    by 0x402CB1: HG_Forward (mercury.c:836)
==2916==    by 0x4020D0: main (ping_server.c:173)
==2916==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==2916==
==2916==
==2916== Process terminating with default action of signal 11 (SIGSEGV)
==2916==  Bad permissions for mapped region at address 0x0
==2916==    at 0x0: ???
==2916==    by 0x402CB1: HG_Forward (mercury.c:836)
==2916==    by 0x4020D0: main (ping_server.c:173)

Modified by jsoumagne on 1 Jan 1970 00:23 UTC

Comment by jsoumagne on 1 Jan 1970 00:23 UTC
Commit 976c881a912d52f5e7c800ff95a6d112785bc485 should fix it.

Modified by jsoumagne on 1 Jan 1970 00:23 UTC


Tabzilla doesn't link

Seems to link to just #

Updated to latest tabzilla- now with no slide-down!


Editing Live Exercises

Currently when a live exercise is unlocked to edit it the exercise is unpublished and has to reapproved and published. Teams are then forgetting to republish the exercise or having to wait for approval and applications are being missed.
Instead when a live exercise on the website is unlocked can the current version stay live with the new changes tracked and then approved and placed online. This way there is no downtime for a live exercises.
Warren and I spoke and will have more information

The tracking of new changes requirement will go into a separate ticket after discussion with Warren.


Clarification on FAQ #9 - Timeout

Q: I get request timed out for my call to the service?
A: Metadata calls must be made from the primary IP address assigned to the network card of the VM, in addition in case you have changed your routes there must be a route for <IP_ADDRESS>/16 address out of your network card.
-> i observe a timeout from a secondary nic; after verification with the engineering team, I understand that the metadata interface can only be reached from the primary network card (on the primary ip addr config)

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

ID: 0fdce995-5347-32c4-119f-6e8484250859
Version Independent ID: 3dcfe7f4-cbb8-6323-5d93-b7e6b7f74db7
Content: Azure Instance Metadata Service
Content Source: articles/virtual-machines/windows/instance-metadata-service.md
Service: virtual-machines-windows
GitHub Login: @KumariSupriya
Microsoft Alias: sukumari

@woutervanranst Thanks for posting here.
Since this information is already in the Document, I think there is no action needed for this issue. Please confirm if you have any expectations.

The doc says "Metadata calls must be made from the primary IP address assigned to the network card of the VM"
the clarification is for "Metadata calls must be made from the primary network card of the VM"
since a vm can have multiple nics, this is a subtle but important clarification

@woutervanranst Got it.
You want the doc to specifically mention primary ip address of the  Primary network card.
@KumariSupriya please add your comments

#reassign: @MicahMcKittrick-MSFT

Consolidating issues on this doc to #45578 30370


java.lang.IllegalArgumentException: Cluster segment #-2 does not exist in database

OrientDB Version, operating system, or hardware.

v2.2.8

Operating System
Linux
Expected behavior and actual behavior
Steps to reproduce the problem
begin
delete from (select content from  33:740)
commit
but if i do
delete from (select content from  33:740)
works.

@publicocean0 could you provide more details, specifically  I am interested in full stack trace of the exception.

in the server log i see Internal server error:
java.lang.IllegalArgumentException: Cluster segment #-2 does not exist in database

Is it reproducible ? Could you send us database so we may do the same ?

hi , the entire database is not possible. i will see if i can find additional infos for helping you

found new infos.
select @rid from (select data[0].link from #36:628)
+----+-----+
|#   |rid  |
+----+-----+
|0   |#-2:0|
+----+-----+

where data is a embedded object

It looks like data serialization issue, @tglman could you look on it ?

script is executed in server side

hi @laa, @publicocean0
this is normal because the inner query produce a projection that has negative rids, you should instead do: select @rid from (select expand(data[0].link) from #36:628)
for the original problem the solution is delete from (select content.@rid from 33:740)
Regards

hi @laa, @publicocean0
this is normal because the inner query produce a projection that has negative rids, you should instead do: select @rid from (select expand(data[0].link) from #36:628)
for the original problem the solution is delete from (select content.@rid from 33:740)
Regards

i consider it solved. Thanks


USHIFT-2370: Changes to allow MicroShift 4.16 to build on RHEL 9.4 Beta

Which issue(s) this PR addresses:

Closes #USHIFT-2370

/retest

/retest

/lgtm


fix: update debug JSBundle name & rootView component

Describe the changes
Fix errors occurred in basic example on iOS simulator

Before index to src/index

Error: Unable to resolve module ./index from /Users/sunbreak/w/Sunbreak/react-native-video.build/examples/basic/.

None of these files exist:
  * index(.native|.ios.js|.native.js|.js|.ios.jsx|.native.jsx|.jsx|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
  * index/index(.native|.ios.js|.native.js|.js|.ios.jsx|.native.jsx|.jsx|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
    at ModuleResolver.resolveDependency (/Users/sunbreak/w/Sunbreak/react-native-video.build/examples/basic/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:152:15)
    at DependencyGraph.resolveDependency (/Users/sunbreak/w/Sunbreak/react-native-video.build/examples/basic/node_modules/metro/src/node-haste/DependencyGraph.js:264:43)
    at /Users/sunbreak/w/Sunbreak/react-native-video.build/examples/basic/node_modules/metro/src/lib/transformHelpers.js:170:21
    at Server._resolveRelativePath (/Users/sunbreak/w/Sunbreak/react-native-video.build/examples/basic/node_modules/metro/src/Server.js:1196:12)
    at async Server.requestProcessor [as _processBundleRequest] (/Users/sunbreak/w/Sunbreak/react-native-video.build/examples/basic/node_modules/metro/src/Server.js:484:37)
    at async Server._processRequest (/Users/sunbreak/w/Sunbreak/react-native-video.build/examples/basic/node_modules/metro/src/Server.js:435:9)

Before videoplayer to VideoPlayer

 BUNDLE  src/index.js

 LOG  Running "videoplayer" with {"rootTag":1,"initialProps":{}}
 ERROR  Invariant Violation: "videoplayer" has not been registered. This can happen if:
* Metro (the local dev server) is run from the wrong folder. Check if Metro is running, stop it and restart it in the current project.
* A module failed to load due to an error and `AppRegistry.registerComponent` wasn't called., js engine: hermes

tested sucessfully on sikmulator. Thank you for the patch !


Failed to fetch

Hey b3ck,
getting this error if i open up the edited html page. get the same error without the port. any ideas?

@KayPure did you figure this one out? you can always message me on Discord if you want: b3ck#3517

@b3ck not yet. will msg u on discord if i get back to this, thx!

looks like you are trying to pull it from port 1935, it should be like port 8080 or 8181, just check your config, the stats will be on a different port than the actual RTMP server, which uses port 1935 by default.

ah doh! thank u very much. will change and test this asap

Got it working. Chrome gave me this Error:
from origin 'null' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains the invalid value 'undefined'. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Stackoverflow gave me the Hint:
Origin null is the local file system, so that suggests that you're loading the HTML page that does the load call via a file:/// URL (e.g., just double-clicking it in a local file browser or similar).
So i load the File in OBS via "LocalFile" as Browsersource. That fixed it for me ;)

Sorry I should have made that more clear, that is the only way to add it as a browser source:

I have updated all of the readme files to account for this over look on my part, please make sure to check "local file" when adding it as a browser source in OBS.

Sorry I should have made that more clear, that is the only way to add it as a browser source:

No worries man, I could have thought of it sooner ;) thanks!


Support For TMS320F2800157

I am working on programming TMS320F2800157 as a daughter board for Pixhawk.I could not find the drivers for TI under libcanard/drivers folder. Could anyone suggest me what is the best mechanism to do so? Or is there any guideline on how to create a new driver to support a new microcontroller?

Hi, I haven't use this MCU or its CAN controller, but based on a quick search:
Are you developing your software using TI's C2000WARE SDK? If so, they seem to offer a driver and example code for their device (MCAN) using their SDK [1][2][3].

https://www.ti.com/lit/an/spracu9/spracu9.pdf?ts=1693257902503
https://software-dl.ti.com/C2000/docs/software_guide/c2000ware/can.html
https://dev.ti.com/tirex/explore/node?node=A__ANMkGT9Eq430zJvq.lRRdA__c2000ware_software_package__gYkahfz__LATEST


'ID3' object has no attribute 'filename'

Receiving this error trying to retrieve the full path of the file as a string. THis is the code I'm using to test, I can retrieve other attributes of the file such as title or duration, but I get an error the filename does not exist. I would assume this is a system variable and can't be missing. Am I doing something wrong?
for files in os.listdir('DIR_WITH_MP3_FILES'):
    if files.endswith('mp3'):
        track = os.path.join('DIR_WITH_MP3_FILES', files)
        trackinfo = TinyTag.get(track, image=True)
        print(trackinfo.filename)

'ID3' object has no attribute 'filename'

Solved with an upgrade to the latest Python. Sorry for the bother!


Alphanumeric numbers text receive website

Virtual number Text-verify
[Enter feedback here]

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

ID: b2323405-845c-100b-0502-51e860dfebb6
Version Independent ID: 3149b0cf-8b88-1fc6-71d4-8f74b4cb8d2d
Content: Create ILB ASE v1 - Azure App Service Environment
Content Source: articles/app-service/environment/app-service-app-service-environment-create-ilb-ase-resourcemanager.md
Service: app-service
GitHub Login: @stefsch
Microsoft Alias: stefsch

Virtual text verify:
US Number
+12345293986
+15672449995
+15672481837
'''''''   Refresh     """''
Receive this code:-
1.
2.
3.
4.
5.
Please contacts supporter:
<EMAIL_ADDRESS>Phone number:+8809638821650

Virtual text verify:
US Number
+12345293986
+15672449995
+15672481837
'''''''   Refresh     """''
Receive this code:-
1.
2.
3.
4.
5.
Please contacts supporter:
<EMAIL_ADDRESS>Phone number:+8809638821650

@Hasan038 Thanks for the feedback! We are taking a look into this and will get back to you soon.

@Hasan038 Thanks for the feedback! We are taking a look into this and will get back to you soon.

@Hasan038 Could you please elaborate your query to help you better on this.

@Hasan038 Could you please elaborate your query to help you better on this.

@Hasan038 Since we did not here from you. We will now close this out but if you feel you need any information or query please just let us know.

@Hasan038 Since we did not here from you. We will now close this out but if you feel you need any information or query please just let us know.


Learn how ray extensions are packed and distributed in workflow

Take a look at .github and github-actions

https://github.com/raycast/extensions/actions/runs/3955837699/jobs/6774472026#step:5:249
https://github.com/raycast/github-actions/blob/2f74efbb1dde6c769599e067b0c18599525ec40c/ray-cli/ray_cli.sh#L65

All build operation are hidden behind ray cli, so we just build our own stuff.

https://github.com/raycast/github-actions/blob/2f74efbb1dde6c769599e067b0c18599525ec40c/get-command/get_command.sh#L8-L12
Extensions get published for every new push
if [ "$event_name" == 'push' ]; then
    command="publish"
elif [ "$event_name" == 'pull_request' ]; then
    command="build"
else

https://github.com/raycast/github-actions/blob/2f74efbb1dde6c769599e067b0c18599525ec40c/ray/action.yml#L62-L68
Take every outputs from previous actions and run ray cli to build/publish extension:
      uses<EMAIL_ADDRESS>      with:
        paths: ${{ steps.get_changed_extensions.outputs.paths }}
        command: ${{ steps.get_command.outputs.command }}
        npm_token: ${{ inputs.npm_token }}
        extension_schema: ${{ inputs.extension_schema }}
        allow_owners_only_for_extensions: ${{ inputs.allow_owners_only_for_extensions }}

So we can take everything in ray/action.yml except these lines and add our own workflow to publish extensions.


Handle Ubuntu 14.04 w/ linux-aws kernel package

When using the linux-aws kernel package for EC2 instances, there are no
linux-image-extra packages. However, the kernel image package itself already
contains AuFS support, so the installation can just be skipped.

Thanks for the quick merge and new release. This makes my work today a lot easier :)


CVAT new UI: hotkeys don't work when CapsLock is turned on

My actions before raising this issue

[x] Read/searched the docs
[x] Searched past issues

Expected Behaviour

All hotkeys should work instead of Capslock is turned on or not
Current Behaviour

Hotkeys don't work when Capslock is turned on. For example, moving to the next\previous frame (f,d); saving (ctrl+s), drawing new objects (n), and so on.
Possible Solution

Steps to Reproduce (for bugs)

Open a CVAT job
Turn on the CapsLock button and try to use the hotkeys

Context

Your Environment

Git hash commit (git log -1):
Docker version docker version (e.g. Docker 17.0.05):
Are you using Docker Swarm or Kubernetes?
Operating System and version (e.g. Linux, Windows, MacOS):
Code example or link to GitHub repo or gist to reproduce problem:
Other diagnostic information / logs:
Logs from `cvat` container

Next steps
You may join our Gitter channel for community support.

Related #1341
It is a problem of library we use: react-hotkeys, not CVAT.
I've created issue: https://github.com/greena13/react-hotkeys/issues/283
Let's wait for the answer and then will decide what to do.


Feat: Refile to heading from capture

Does this feature exist in Emacs orgmode core?
Yes
Orgmode link
https://orgmode.org/manual/Template-elements.html
(setq org-capture-templates
      '(("w" "Work time (file+headline "~/org/refile.org" "Work Timesheet")
         "** Working on %?\n%T")))

Feature value
No response
Additional context
Discussed in https://github.com/nvim-orgmode/orgmode/discussions/184

Originally posted by joshpetit December 13, 2021
I'm not sure if this is implemented yet, but I'd like to refile a template to a heading. For example having something like this:
    org_agenda_templates = {
        w = {
            description = 'Work time',
            template = '** Working on  %<%Y-%m-%d>\n%?',
            target = 'refile.org/Work Timesheet'
        },
    },

I'm not sure if I just do't have to syntax correct, if it's not implemented yet I can file a feature request.

@kristijanhusak  I could get started working on this, the API I had in mind would be:
    org_agenda_templates = {
        w = {
            description = 'Work time',
            template = '** Working on  %<%Y-%m-%d>\n%?',
            target = 'refile.org'
            headline= 'Work Timesheet'
        },
    },

I think it would make sense to make the target include the header (i.e refile.org/Work Timesheet) just as you do for refiling within captures, but I think it matches the original API more by having it as a property. Thoughts?

Neat! With this path-like syntax you could also extend it for non-unique headlines (e.g. refile.org/Work Timesheet/2022/projectA), as long as there are no headlines with the same name on the same level. That would work regardless of it being a property or not. The property variant makes it a bit more clear imo.
Not really your focus with this issue, but how would this scale if we were to include the other target possibilities that orgmode offers (e.g. regex, id, etc.)?

@joshpetit that looks ok. Should be fairly simple to implement since refile prompt already supports something similar.

finished


Added changes to add nest extractor

Please follow the guide below

You will be asked some questions, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your pull request (like that [x])
Use Preview tab to see how your pull request will actually look like

Before submitting a pull request make sure you have:

[ ] Searched the bugtracker for similar pull requests
[ ] Read adding new extractor tutorial
[ ] Read youtube-dl coding conventions and adjusted the code to meet them
[ ] Covered the code with tests (note that PRs without tests will be REJECTED)
[ ] Checked the code with flake8

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[ ] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Bug fix
[ ] Improvement
[ ] New extractor
[ ] New feature

Description of your pull request and other information
Explanation of your pull request in arbitrary form goes here. Please make sure the description explains the purpose and effect of your pull request and is worded well enough to be understood. Provide as much context and examples as possible.

Please

revert commit e8eb999 in this branch (maybe review PR #31206 and offer any good bits from the commit there?)
complete the PR template.

And
3. consider incorporating PR #31274, stalled because the PR author didn't respond to review comments, or closing this in favour of it in case I might have time to finish it myself.


Changing *FS.client type definition to goredis.Cmdable interface

Addresses issue #2 with the following changes:

Changes the New constructor to accept redis.Cmdable interface instead of redis.Client
Adds redis.Cmdable implementation checks on various clients:
i. redis.Client
ii. redis.ClusterClient
iii. redis.Pipeline
Removed Args type
Added note regarding redis server version >= 6.0 dependency based on KeepTTL arg. See:

https://github.com/dhh93/fs/blob/4bca13f547cd1e87d3c533bc8d8fde1255a38b30/io/cache/redis/redis.go#L84

This was never fully realized, so abandoning the PR.


Markdown Linter: Allow 1'd ordered lists.

Markdown formatters have a neat feature: If you make an ordered list and number each item as 1., the renderer will auto-increment the displayed number. This is very useful for documentation, because authors can add and remove steps without having to adjust each step that comes after it.
Currently our linter doesn't allow us to use this Markdown feature:
content/workspace/docs/pages/connect-your-client/teleport-connect.mdx
   59:1-59:93  warning  Marker should be `2`, was `1`  ordered-list-marker-value  remark-lint
   60:1-60:73  warning  Marker should be `3`, was `1`  ordered-list-marker-value  remark-lint
   61:1-61:66  warning  Marker should be `4`, was `1`  ordered-list-marker-value  remark-lint
   70:1-70:33  warning  Marker should be `2`, was `1`  ordered-list-marker-value  remark-lint
   71:1-71:98  warning  Marker should be `3`, was `1`  ordered-list-marker-value  remark-lint
   72:1-72:72  warning  Marker should be `4`, was `1`  ordered-list-marker-value  remark-lint
  73:1-73:102  warning  Marker should be `5`, was `1`  ordered-list-marker-value  remark-lint

The ask is to adjust the linter to allow for ordered lists where every entry is a 1..

Closing as complete


[Fix] Move import sync_req into method of sync MiniGram

As I found quite critical in my case error with imports when in project exists aiohttp library. When application tries to import MiniGramUpdate it crashes cause can't import sync_req function. I assume there could more elegant solution but at least it won't fail on startup for real working async applications.

may I ask you to show the exeptions that happened when aiohttp is exists?
I ask you because for most cases it's better to check libraries availability before import, but not to move imports inside function

Yes for sure.
There is minimal setup to reproduce:
(Install venv and activate it, as for me I use uv venv & source .venv/bin/activate)
pip install minigram-py aiohttp
and in python shell just run this
>>> from minigram import MiniGramUpdate
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/user/Projects/check-minigram-import-error/.venv/lib/python3.12/site-packages/minigram/__init__.py", line 3, in <module>
    from .main import MiniGram, MiniGramUpdate, AsyncMiniGram
  File "/Users/user/Projects/check-minigram-import-error/.venv/lib/python3.12/site-packages/minigram/main.py", line 9, in <module>
    from .request import sync_req, async_req
ImportError: cannot import name 'sync_req' from 'minigram.request' (/Users/user/Projects/check-minigram-import-error/.venv/lib/python3.12/site-packages/minigram/request.py). Did you mean: 'async_req'?

I also updated the solution, with check if library aiohttp not installed.
But may I ask why only for aiohttp we do not need sync_rec function implemented? I understand that for httpx we can use both types of requests sync and async. But for example I'm building an application with aioboto3 library which uses aiohttp inside, but for my MiniGram bot I would like to use async requests with httpx library. And in such case it is not possible to choose what library to use, isn't it? Or I maybe I missed something?

thank you, now it's perfect

@bobuk Sorry, it looks like I forgot to bump version of the library 😔
Could you please bump version to fix CI and auto-publish to pypi?

I'll bump it this Sunday (have a plans to update documentation etc)


pods losing connections and iperf3 results

Hi,
We are experiencing weird connection issues between pods. Sometimes; some pods suddenly lose their connection to other pods.
Since the issue is difficult to reproduce, I did some iperf3 tests to check network performance.
This is a 50 node cluster, running stuff like AxonDB as pods.
What you expected to happen?
Pods keeping their connections
What happened?
Pods losing connections + high retr values in perf3
How to reproduce it?
Sudden disconnects suddenly appear at random, and very difficult to reproduce.
Anything else we need to know?

Versions:

weave: 2.4.1
kernel: 4.4.162-1.el7.elrepo.x86_64 #1 SMP Sat Oct 20 11:33:06 EDT 2018 x86_64 GNU/Linux
kubernetes: v1.9.5

Logs:
weave logs from the node where iperf3 pod is running on:
INFO: 2018/11/05 13:09:56.846151 Discovered remote MAC 26:81:f9:1b:ba:ba at ca:73:08:98:02:40(up-worker-017)
INFO: 2018/11/05 13:10:16.243967 Discovered remote MAC aa:ef:7f:e9:e2:75 at 26:1f:3f:75:e1:53(in-worker-001)
INFO: 2018/11/05 13:15:59.578283 Discovered remote MAC e6:b8:f3:f0:5f:bc at c6:7a:77:b8:f9:28(up-worker-009)
INFO: 2018/11/05 13:16:06.117382 Discovered remote MAC c6:7a:77:b8:f9:28 at c6:7a:77:b8:f9:28(up-worker-009)
INFO: 2018/11/05 13:16:25.113455 Discovered remote MAC 8a:67:00:34:e2:7b at ca:cb:3b:6d:ba:22(up-worker-041)
ERRO: 2018/11/05 13:16:25.113558 Captured frame from MAC (8a:67:00:34:e2:7b) to (ce:c7:b8:4e:3d:24) associated with another peer ca:cb:3b:6d:ba:22(up-worker-041)
INFO: 2018/11/05 13:16:29.747275 Discovered remote MAC 46:17:48:e0:7d:b6 at 4e:65:17:d4:e7:45(up-worker-019)
ERRO: 2018/11/05 13:17:21.068787 Captured frame from MAC (8a:67:00:34:e2:7b) to (ce:c7:b8:4e:3d:24) associated with another peer ca:cb:3b:6d:ba:22(up-worker-041)
INFO: 2018/11/05 13:17:55.544621 Discovered remote MAC ca:73:08:98:02:40 at ca:73:08:98:02:40(up-worker-017)
INFO: 2018/11/05 13:18:16.842285 Discovered remote MAC 92:44:94:e6:a6:7c at f2:82:3d:6b:ce:74(up-worker-001)
INFO: 2018/11/05 13:18:45.046048 Discovered remote MAC 3e:29:87:80:4c:c5 at f2:82:3d:6b:ce:74(up-worker-001)
INFO: 2018/11/05 13:19:40.503990 Discovered remote MAC 6e:ec:23:a5:a1:b4 at 86:52:d6:54:00:98(up-worker-027)
INFO: 2018/11/05 13:19:41.525918 Discovered remote MAC 36:be:c2:e2:c6:58 at ca:73:08:98:02:40(up-worker-017)
INFO: 2018/11/05 13:20:30.950130 Discovered remote MAC 1e:86:95:fd:80:fa at 26:1f:3f:75:e1:53(in-worker-001)
INFO: 2018/11/05 13:21:12.532777 Discovered remote MAC 2e:d2:f2:a1:ab:2a at 86:52:d6:54:00:98(up-worker-027)
INFO: 2018/11/05 13:23:04.759666 Discovered remote MAC ae:33:4a:31:0e:73 at ae:e3:d0:a3:fe:62(up-worker-047)

I ran iperf3 as pods (one serverpod , and one client pod)
iperf 3.0.7
Linux iperf3-client 4.4.162-1.el7.elrepo.x86_64 #1 SMP Sat Oct 20 11:33:06 EDT 2018 x86_64 GNU/Linux
Time: Mon, 05 Nov 2018 13:24:49 GMT
Connecting to host iperf3-server, port 5201
      Cookie: iperf3-client.1541424284.088736.24f7
      TCP MSS: 1324 (default)
[  4] local <IP_ADDRESS> port 36238 connected to <IP_ADDRESS> port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   161 MBytes  1.35 Gbits/sec    6    319 KBytes
[  4]   1.00-2.00   sec   175 MBytes  1.46 Gbits/sec    3    456 KBytes
[  4]   2.00-3.00   sec   193 MBytes  1.62 Gbits/sec   26    475 KBytes
[  4]   3.00-4.00   sec   186 MBytes  1.56 Gbits/sec   14    414 KBytes
[  4]   4.00-5.00   sec   182 MBytes  1.53 Gbits/sec   99    420 KBytes
[  4]   5.00-6.00   sec   190 MBytes  1.59 Gbits/sec    9    318 KBytes
[  4]   6.00-7.00   sec   197 MBytes  1.65 Gbits/sec    5    371 KBytes
[  4]   7.00-8.00   sec   189 MBytes  1.58 Gbits/sec    7    376 KBytes
[  4]   8.00-9.00   sec   192 MBytes  1.61 Gbits/sec   36    431 KBytes
[  4]   9.00-10.00  sec   191 MBytes  1.60 Gbits/sec   71    380 KBytes
[  4]  10.00-11.00  sec   189 MBytes  1.59 Gbits/sec   20    380 KBytes
[  4]  11.00-12.00  sec   190 MBytes  1.60 Gbits/sec   29    384 KBytes
[  4]  12.00-13.00  sec   188 MBytes  1.57 Gbits/sec  117    406 KBytes
[  4]  13.00-14.00  sec   193 MBytes  1.62 Gbits/sec  327    405 KBytes
[  4]  14.00-15.00  sec   197 MBytes  1.65 Gbits/sec   63    313 KBytes
[  4]  15.00-16.00  sec   188 MBytes  1.57 Gbits/sec   45    357 KBytes
[  4]  16.00-17.00  sec   190 MBytes  1.59 Gbits/sec  148    392 KBytes
[  4]  17.00-18.00  sec   197 MBytes  1.65 Gbits/sec  162    390 KBytes
[  4]  18.00-19.00  sec   193 MBytes  1.62 Gbits/sec   51    301 KBytes
[  4]  19.00-20.00  sec   180 MBytes  1.51 Gbits/sec   31    330 KBytes
[  4]  20.00-21.00  sec   196 MBytes  1.64 Gbits/sec   14    370 KBytes
[  4]  21.00-22.00  sec   190 MBytes  1.60 Gbits/sec   94    372 KBytes
[  4]  22.00-23.00  sec   186 MBytes  1.56 Gbits/sec  110    375 KBytes
[  4]  23.00-24.00  sec   183 MBytes  1.53 Gbits/sec   10    385 KBytes
[  4]  24.00-25.00  sec   175 MBytes  1.47 Gbits/sec   86    409 KBytes
[  4]  25.00-26.00  sec   188 MBytes  1.57 Gbits/sec   54    385 KBytes
[  4]  26.00-27.00  sec   167 MBytes  1.40 Gbits/sec   88    378 KBytes
[  4]  27.00-28.00  sec   187 MBytes  1.57 Gbits/sec   28    402 KBytes
[  4]  28.00-29.00  sec   191 MBytes  1.60 Gbits/sec  130    273 KBytes
[  4]  29.00-30.00  sec   187 MBytes  1.57 Gbits/sec    1    451 KBytes
[  4]  30.00-31.00  sec   194 MBytes  1.63 Gbits/sec    9    450 KBytes
[  4]  31.00-32.00  sec   185 MBytes  1.54 Gbits/sec   70    331 KBytes
[  4]  32.00-33.00  sec   179 MBytes  1.51 Gbits/sec   23    334 KBytes
[  4]  33.00-34.00  sec   187 MBytes  1.57 Gbits/sec   12    495 KBytes
[  4]  34.00-35.00  sec   192 MBytes  1.61 Gbits/sec   78    491 KBytes
[  4]  35.00-36.00  sec   189 MBytes  1.59 Gbits/sec   95    359 KBytes
[  4]  36.00-37.00  sec   191 MBytes  1.60 Gbits/sec  150    396 KBytes
[  4]  37.00-38.00  sec   190 MBytes  1.60 Gbits/sec   57    456 KBytes
[  4]  38.00-39.00  sec   190 MBytes  1.60 Gbits/sec   86    424 KBytes
[  4]  39.00-40.00  sec   189 MBytes  1.59 Gbits/sec  107    313 KBytes
[  4]  40.00-41.00  sec   188 MBytes  1.57 Gbits/sec   59    525 KBytes
[  4]  41.00-42.00  sec   191 MBytes  1.61 Gbits/sec   47    375 KBytes
[  4]  42.00-43.00  sec   169 MBytes  1.41 Gbits/sec   18    495 KBytes
[  4]  43.00-44.00  sec   193 MBytes  1.62 Gbits/sec    4    486 KBytes
[  4]  44.00-45.00  sec   194 MBytes  1.63 Gbits/sec    8    441 KBytes
[  4]  45.00-46.00  sec   189 MBytes  1.59 Gbits/sec   24    438 KBytes
[  4]  46.00-47.00  sec   191 MBytes  1.60 Gbits/sec   45    487 KBytes
[  4]  47.00-48.00  sec   192 MBytes  1.61 Gbits/sec   37    498 KBytes
[  4]  48.00-49.00  sec   185 MBytes  1.55 Gbits/sec   72    337 KBytes
[  4]  49.00-50.00  sec   193 MBytes  1.62 Gbits/sec   18    345 KBytes
[  4]  50.00-51.00  sec   190 MBytes  1.59 Gbits/sec   50    371 KBytes
[  4]  51.00-52.00  sec   195 MBytes  1.64 Gbits/sec   47    378 KBytes
[  4]  52.00-53.00  sec   189 MBytes  1.58 Gbits/sec   75    359 KBytes
[  4]  53.00-54.00  sec   190 MBytes  1.59 Gbits/sec   29    387 KBytes
[  4]  54.00-55.00  sec   191 MBytes  1.60 Gbits/sec   39    442 KBytes
[  4]  55.00-56.00  sec   189 MBytes  1.58 Gbits/sec   39    409 KBytes
[  4]  56.00-57.00  sec   184 MBytes  1.55 Gbits/sec   21    445 KBytes
[  4]  57.00-58.00  sec   192 MBytes  1.61 Gbits/sec   14    400 KBytes
[  4]  58.00-59.00  sec   184 MBytes  1.55 Gbits/sec   43    375 KBytes
[  4]  59.00-60.00  sec   195 MBytes  1.63 Gbits/sec   80    387 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  11.0 GBytes  1.58 Gbits/sec  3340             sender
[  4]   0.00-60.00  sec  11.0 GBytes  1.58 Gbits/sec                  receiver
CPU Utilization: local/sender 8.3% (0.3%u/8.0%s), remote/receiver 1.7% (0.0%u/1.6%s)

What worries me, is the high amount of "retr". Is this normal behaviour?

Can you run the status command please, as described at https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#troubleshooting

Version: 2.4.1 (up to date; next check at 2018/11/05 16:55:00)

        Service: router
       Protocol: weave 1..2
           Name: d2:6b:52:5a:e8:e2(up-worker-042)
     Encryption: enabled
  PeerDiscovery: enabled
        Targets: 53
    Connections: 53 (52 established, 1 failed)
          Peers: 53 (with 2756 established connections)
 TrustedSubnets: none

    Service: ipam
     Status: ready
      Range: <IP_ADDRESS>/12

DefaultSubnet: <IP_ADDRESS>/12

OK, now weave status connections

Nothing out of the ordinary
-> <IP_ADDRESS>:6783   established encrypted   fastdp ca:73:08:98:02:40(up-worker-017) encrypted=truemtu=1376
<- <IP_ADDRESS>:18881  established encrypted   fastdp 82:4c:46:08:07:fa(up-worker-024) encrypted=truemtu=1376
<- <IP_ADDRESS>:52498  established encrypted   fastdp 26:bd:b8:4d:5c:33(up-worker-049) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp a2:6b:4c:e5:2c:b4(up-worker-026) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 36:ea:dd:af:c5:25(up-worker-031) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 96:7d:1a:86:8d:db(up-worker-044) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 42:f4:42:d3:2f:2e(up-worker-020) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp ae:e3:d0:a3:fe:62(up-worker-047) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 72:e2:f2:79:be:7b(up-worker-011) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 1a:a3:16:ac:0f:06(up-worker-023) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 4e:65:17:d4:e7:45(up-worker-019) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp d6:55:6f:d4:58:47(up-worker-005) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 26:1f:3f:75:e1:53(in-worker-001) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 6e:f4:bc:65:32:b4(up-worker-013) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp ee:c2:c2:d2:93:aa(up-worker-025) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp c6:7a:77:b8:f9:28(up-worker-009) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 6a:55:f7:3e:84:ea(up-worker-036) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 62:f8:08:1c:b2:39(up-worker-006) encrypted=truemtu=1376
<- <IP_ADDRESS>:40524  established encrypted   fastdp 72:2b:2b:ab:aa:53(up-worker-004) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp e6:17:01:98:66:54(up-worker-014) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 6e:e4:35:f2:02:95(up-worker-045) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783    established encrypted   fastdp 5a:17:0e:8d:42:1b(up-master-001) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 42:b0:dc:48:0f:7e(up-worker-043) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp ee:1a:bf:ce:f3:9e(up-worker-012) encrypted=truemtu=1376
<- <IP_ADDRESS>:34285  established encrypted   fastdp ee:8b:a9:a0:86:db(up-worker-022) encrypted=truemtu=1376
<- <IP_ADDRESS>:47487  established encrypted   fastdp d6:a8:9e:d8:9d:9d(up-worker-033) encrypted=truemtu=1376
<- <IP_ADDRESS>:36982  established encrypted   fastdp 36:d2:f9:49:d1:f2(up-worker-037) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 86:52:d6:54:00:98(up-worker-027) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp ca:cb:3b:6d:ba:22(up-worker-041) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 9e:68:1a:45:b8:db(up-worker-028) encrypted=truemtu=1376
<- <IP_ADDRESS>:22587  established encrypted   fastdp ee:f5:86:e8:89:c6(up-worker-039) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 32:ca:da:d3:93:8a(up-worker-007) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 5e:33:65:15:a0:77(up-worker-034) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783    established encrypted   fastdp 86:a3:4b:95:24:f3(up-master-002) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 4e:90:82:80:ab:80(up-worker-030) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783    established encrypted   fastdp 0a:e2:ef:56:29:f2(in-master-001) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 76:9a:51:58:b4:9c(up-worker-008) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 26:de:ba:55:21:1b(up-worker-016) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 8e:82:66:6e:2c:73(up-worker-035) encrypted=truemtu=1376
<- <IP_ADDRESS>:26702  established encrypted   fastdp 86:86:c1:b3:b6:f1(up-worker-040) encrypted=truemtu=1376
<- <IP_ADDRESS>:18478  established encrypted   fastdp 5a:a1:12:b9:01:a6(up-worker-048) encrypted=truemtu=1376
<- <IP_ADDRESS>:22276  established encrypted   fastdp 36:41:9f:ac:c6:e1(up-worker-021) encrypted=truemtu=1376
<- <IP_ADDRESS>:37756  established encrypted   fastdp 32:22:45:af:20:8a(up-worker-018) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 7a:16:4c:ff:36:a9(up-worker-032) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 72:58:60:74:ec:f6(up-worker-002) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp be:4a:6b:19:d8:ae(up-worker-015) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 26:34:e3:cf:11:0a(up-worker-046) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp 7e:1d:ca:21:3d:57(up-worker-010) encrypted=truemtu=1376
<- <IP_ADDRESS>:62615  established encrypted   fastdp 66:d3:a7:dd:61:68(up-worker-038) encrypted=truemtu=1376
<- <IP_ADDRESS>:15705  established encrypted   fastdp ea:28:57:25:1d:69(up-worker-029) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp c2:84:b0:62:3c:f3(up-worker-003) encrypted=truemtu=1376
-> <IP_ADDRESS>:6783   established encrypted   fastdp f2:82:3d:6b:ce:74(up-worker-001) encrypted=truemtu=1376

@jeroenjacobs1205 Can you run netstat -ian on both pods before and after the iperf test? Also, please dmesg from both nodes can be helpful.

There's nothing so far to point towards dropped connections.  What exactly are the symptoms of "some pods suddenly lose their connection to other pods" ?  E.g. do you get an error message?
To answer your other question, retries happen when packets are dropped, which is a design feature of TCP/IP when buffers fill up along the path.  I see max 327 packets out of 193 megabytes dropped, which at 1376 bytes each is not a high percentage.

Closing this, as this was probably not a Weavenet issue.