Cropping depth frame with opencv

Required Info

Camera Model
D435

Firmware Version
(Open RealSense Viewer --> Click info)

Operating System & Version
Ubuntu 14

Kernel Version (Linux Only)
4.4.0-31-generic

Platform
PC

SDK Version
2.40.0

Language
C++

Segment
Robot

Issue Description
I want to ignore the edges of the depth frame (since it is always occluded by the mounting). As a starting point, I was able to convert the frame to cv::Mat, crop the image.
Now I'm trying to convert the Mat back to rs2::frame and I noticed a note from @dorodnic on #2634 that frame parameters have to be explicitly specified. I found some useful example in rs-depth-filter.
auto p = ir_frame.get_profile().as<rs2::video_stream_profile>();
auto intr = p.get_intrinsics() / DOWNSAMPLE_FACTOR;
_input_ir_profile = p;
_output_ir_profile = p.clone(p.stream_type(), p.stream_index(), p.format(),
p.width() / DOWNSAMPLE_FACTOR, p.height() / DOWNSAMPLE_FACTOR, intr);

For sake of example, I want to crop out bottom 100 rows and right 20 columns in a 1280x720 frame. Do I have to recompute intrinsics for the new frame resolution? If yes, how do I recompute it for a 1180*700 frame?
Also, Is there a better approach to this?

I put together this code following the example at #2634 and I get a black image when viewing the colorized cropped image. Please help.
rs2::processing_block(
        [this](rs2::frame f, rs2::frame_source& src)
    {
        if(not m_enableCropping.get()){
            // no processing needed
            src.frame_ready(f);
            return;
        }

        // For each input frame f, do:
        const int w = f.as<rs2::video_frame>().get_width();
        const int h = f.as<rs2::video_frame>().get_height();

        // rs2::frame --> cv::Mat
        Mat image(Size(w, h), CV_16UC1, (void*)f.get_data(), Mat::AUTO_STEP);
        // Create ROI for cropping
        int startX = m_startRow.get();
        int startY = m_startColumn.get();
        int width = w - startY - m_endColumn.get();
        int height = h - startX - m_endRow.get();
        Mat ROI(image, Rect(startX, startY, width, height));

        // Get incoming frame profile
        auto p = f.get_profile().as<rs2::video_stream_profile>();
        // Get incoming frame intrinsics and scale it to new frame size
        auto i = p.get_intrinsics();
        const float sx = static_cast<float>(width) / i.width, sy = static_cast<float>(height) / i.height;
        rs2_intrinsics intr = { width, height, i.ppx*sx, i.ppy*sy, i.fx*sx, i.fy*sy, i.model,
                {i.coeffs[0], i.coeffs[1], i.coeffs[2], i.coeffs[3], i.coeffs[4]} };
        // create a profile for the new frame
        auto ouput_profile = p.clone(p.stream_type(), p.stream_index(), p.format(),
                width, height, intr);
        // allocate a frame object
        auto res = src.allocate_video_frame(ouput_profile, f, 0,
            width, height, f.as<rs2::video_frame>().get_bytes_per_pixel() * width, RS2_EXTENSION_DEPTH_FRAME);
        // copy from cv::Mat --> rs2::frame
        memcpy((void*)res.get_data(), ROI.data, width * height * 2); // 2 bytes per pixel

        // Send the resulting frame to the output queue
        src.frame_ready(res);
    });

Hi @banuprathap   Before looking at cv::mat to rs2::frame conversion, I wonder if another approach to dealing with the mounting blocking the view would be to simply set a minimum depth distance for the camera using scripting, such as 0.5 meters.  Close-range depth data representing objects close to the camera lenses, such as the mounting, should then be excluded from the depth image.
A custom setting that ignores close range detail could be defined by decreasing the value of the Disparity Shift option to increase the camera's minimum distance or by configuring a Threshold Filter post-processing filter to set a minimum and maximum depth distance.
Disparity Shift
http://sunyelee.blogspot.com/2019/10/realsense-3d.html
https://github.com/IntelRealSense/librealsense/issues/2229#issuecomment-412431623
Threshold filter
https://stackoverflow.com/questions/59054413/intel-realsense-depth-camera-d435i-noises-and-mounds

If you would prefer to continue with your current method of using cropping then I will be happy to discuss that further with you.

H

Hi @banuprathap  Can you provide more information please?  Thanks!    :)

Thresholding is not the right approach for us. The sensor is mounted in such a way that the robot's body is within the FOV. Simply disabling depth values with thresholding would not be ideal because the depth values from regions not covered by the robot body is still useful for us.
Ideally we would create a pixel mask that would set only the pixels covered by robot body to zero. Is that possible?
Cropping out the entire rows and columns of pixels is acceptable too.  Hence my initial question.

I recall a RealSense project for segmenting out from the background a particular color of a simple background surface such as a wall.  A close-up of the robot body in front of the camera might produce a similar solid-colored area that could be segemented out.
https://01.org/node/28902
https://github.com/intel/depth-camera-web-demo

Thanks for the input. I gather the suggested approach relies on RGB frame. I failed to mention we don't have access to RGB from the camera.

Whilst setting up a bounding box for XY instead of depth Z and cropping out the data outside of the bounding box can produce the results that you seek, doing so tends to be complicated.  Here is an example description of such a method:
https://github.com/IntelRealSense/librealsense/issues/2016#issuecomment-403804157
A cruder but still effective approach may be to reduce depth resolution so that the sides of the depth view are
restricted on the X plane, like the 'letterbox' when watching telvision in 4:3 format instead of 16:9 widescreen.  The image below demonstrates the same scene in 848x480 (upper) and 640x480 (lower).

Hi @banuprathap  Do you require further assistance with this case, please?  Thanks!

Case closed due to no further comments received.


Show Product Store ID Instead of Store Name in facility associated stores list when no store name is present

Current behavior

Currently, the product store list displays the store name in the list items. However, if the store name is not present, the list item appears empty or incomplete.
Expected behavior

To improve user experience, we should display the product store ID in place of the store name if the name is not available.
Steps to reproduce the issue

Open the facilities details page for any facility.
Add a product store in the facility with no store name.
Observe the empty space where the store name should be.

Screenshot

Can you handle fixing this bug by yourself?

[ ] YES
[ ] NO

Environment details

Browser:
OS:
Code Version:

Additional information

hotwax ,

i would like to handle this

@theabhishekjamle Please go ahead

Same issue exits on the Product Store filter on the Find Facilities Page.

Successfully tested the issue by creating a  ProductStore in ProductStore entity  with a productStoreId while leaving the storeName field empty. The application correctly displayed the productStoreId in the absence of a storeName.


[Bug] Form widget buttons do not work well when placed inside a container

Description
So basically formButtons inside a container inside a form does not respond well to the required fields.
Steps to reproduce the behaviour:
https://user-images.githubusercontent.com/11089579/132937404-945e1cf5-fc22-4a21-b5e8-93b65dbdc383.mov

Create a form
add an input field to it
add a container to the form
copy the form buttons to the container
set all the visible buttons to required
Add value to the input field and see that only buttons outside the container react to the invalid form logic

Important Details

Version: [Cloud / Self-Hosted vx.x]
Browser [e.g. chrome, safari]
Environment [production]

@somangshu Form buttons were meant to only work inside forms. I suggest we close this and kill form buttons / Forms and introduce their logic to buttons / containers

@somangshu closing this in favor of #3613 (deprecating form buttons)


Release 1.54 cut

Fixes #
I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

Hi Peter, can you describe what this PR is full please?

Hi Peter, can you describe what this PR is full please? Did you mean to make a PR for the main repo?

Hi, sorry about this. It's not finished yet.
In general i am thinking of adding few more versions without non-critical modules for v1.54 - to reduce overall playcanvas engine filesize
release-1.54-core - don't contains any non critical module
release-1.54-core-p - with particles
release-1.54-core-a - with animations
release-1.54-core-s - with sounds
release-1.54-core-pa - with particles and animations
release-1.54-core-ui - with UI
release-1.54-core-uipas - with UI, particles, animations, sounds
etc.
Or may be you can propose a better way to have multiple builds with different number of components / modules

Unfortunately , its unlikely that we will take on more build targets in this manner and would have  more configurable way for an end developer to specify what to include.
@mvaligursky has been looking at this but I'm not sure what their plans are long term. Personally, it would great if there was a config file or similar where I can add/remove component systems/modules from the engine to build

Please see https://github.com/playcanvas/engine/pull/4082 for more context. Ultimately we'd like to make the engine tree-shakeable, even editor projects. We have a long way to go though.

We're heading towards the solution that was started here: https://github.com/playcanvas/engine/pull/4082
It allows users to build their engine based application using tree shaking. I already tested this on our model viewer project and also some standalone examples, and even as it's not a public interface yet, it's useable as is.
Two main areas we still need to solve for the full benefits are:

scripts. Those are ES5 and not module based, and so are not compatible with tree-shaking. We might need to have a new, module based version, of scripts, or some other solution. If your project does not use ES5 scripts, this is non-issue I believe. But unfortunately, most project do use scripts.
Editor integration - we need some way to easily configure the AppOptions (https://github.com/playcanvas/engine/blob/main/src/framework/app-options.js) in the Editor, and build the editor project including the engine, using rollup or similar, to apply the tree-shaking, and only include enabled / imported engine modules.

If in the meantime you need a smaller engine, you're welcome to do a custom build, but as it was mentioned, it's not the direction we'd like to take, and have a grid of build targets.

Closing the ticket as we won't be merging this but please feel free to continue the discussion :)

We're heading towards the solution that was started here: #4082 It allows users to build their engine based application using tree shaking. I already tested this on our model viewer project and also some standalone examples, and even as it's not a public interface yet, it's useable as is.
Two main areas we still need to solve for the full benefits are:

scripts. Those are ES5 and not module based, and so are not compatible with tree-shaking. We might need to have a new, module based version, of scripts, or some other solution. If your project does not use ES5 scripts, this is non-issue I believe. But unfortunately, most project do use scripts.
Editor integration - we need some way to easily configure the AppOptions (https://github.com/playcanvas/engine/blob/main/src/framework/app-options.js) in the Editor, and build the editor project including the engine, using rollup or similar, to apply the tree-shaking, and only include enabled / imported engine modules.

If in the meantime you need a smaller engine, you're welcome to do a custom build, but as it was mentioned, it's not the direction we'd like to take, and have a grid of build targets.

Thank you.
Yes, definitely, if you manage to add module based system in the Editor - that's the only true solution.
Not sure, if this will help you, but i guess this scheme will work
global.js
window.pc = {}
button/
pc.ButtonComponentSystem = ButtonComponentSystem;
aplication.js
if (pc.ButtonComponentSystem) this.ButtonComponentSystem = new pc.ButtonComponentSystem();


(1d,P3) Enable Intl tests in ChakraCore Linux --with-intl builds

This is done (modulo tests that don't pass with ICU, but the coverage is there)


Add tsk_recover offset option

Would it be possible to provide diskimageprocessor the option to take in a value for the tsk_recover sector offset argument? Similar to the way brunnhilde can work as documented here: https://github.com/timothyryanwalsh/brunnhilde/issues/20
For disks described in that brunnhilde issue, diskimageprocessor.py (and the GUI) currently is not able to carve out files and, consequently, produce any of the brunnhilde reports.

Hi Zach! Thanks for opening the ticket. I can certainly do this in the diskimageprocessor.py and diskimageanalyzer.py scripts -- add some flags and then just specify that if you want to use them for disks where you need to pass in specific arguments to tsk_recover, to use the script on only one disk image.
Not sure how to add this to the GUI though, given that the assumption is that the source being processed could have any number of disk images in it. If you have ideas, I'm all ears!

Ah, good point, I had not taken the multiple disk capabilities of diskimageprocessor (scripts or GUI) into account. If you could add it to the scripts, it would be a big help in my workflow (which I'd be happy to share, btw) at least. It will allow me to have uniform structures for the SIPs. And if it's in the scripts only, perhaps it will be less liable to cause confusion? I agree a GUI option seems to be more trouble than it's worth, but maybe as we process an elegant solution will emerge (we can always hope!). Thanks!

Okay, sounds good! Maybe it would help if you shared a bit about your workflow? (here or through email) Then it might be a bit easier to understand the use case I'm building for. Thanks!

Hi Zach - getting around to following up on this.
I was thinking - in order to keep the multi-disk functionality, what if I added an option to pass along a CSV file with the disk image input that would specify filenames and tsk_recover options? If you had one disk, you would just make a one-line CSV with the relevant info (fs type, img type, sector offset) in consistent order as appropriate.
Does that seem like too much overhead for your use case?

Hi Tim,
Here's the basics of my workflow now: 1) acquire the image with Guymager, 2) take a photograph of the disk, 3) run Disk Image Processor in Processing mode (python script or GUI, either way would be okay) against the image, the Guymager .info file, and the photograph file, and 4) transfer the bagged SIPs to staging for preservation storage. My workaround without a sector offset argument in Disk Image Processor would be to add a step 3b where I identify the SIPs that have no files in the /data/objects/files/ directory, and then move them to a new location where I can run brunnhilde on them separately.
I like the CSV idea, especially the idea of blank cells representing an auto value. And I think it would be a good replacement for the 3b step. I'm not aware of a way to avoid a 2nd pass with tsk_recover (whether it's Disk Image Processor or just brunnhilde); that is, I can't see how to anticipate that a disk needs the sector offset for tsk_recover to work. Is it just FAT raw images? (that's not so much a question for you, just wondering out loud). So, no, I don't think it would be too much overhead. Thank you!

Hi Zach,
So I started working the direction we discussed, and then was having a hard time fitting in the functionality with the existing scope/purpose of the diskimageprocessor script. Eventually I decided to make a new script, "process_with_tsk_options.py", which you see in this dev branch. The script needs to be in the same directory as the other diskimageprocessor files after installation to work, but I have updated the install.sh script in that branch accordingly.
Unfortunately, this would mean you'd still have a bit of a workaround to do in that 3b step, but at least from there you can easily get a standard output for those disk images that require extra work, after you've done some research and know what the sector offset, fstype, and so on are.
Would you mind cloning or downloading the files from the dev branch, installing on your end, and trying it out? Looking forward to any feedback you might have (even if it's that you think I went in the wrong direction here!)

(also, I haven't yet updated the readme in that branch, but if you call the script with -h, I think the inputs should be pretty self-explanatory -- I've tried to make it as close as possible to the existing diskimageprocessor options)

Hey Tim,
Just went through the workflow using process_with_tsk_options.py for step 3b, and it worked like a charm. The thing I like about it is that it retains the structure of the bags that are created with normal diskimageprocessor.py (or GUI), which wasn't happening when I was having to resort to brunnhilde for step 3b. Every image (so far!) having a consistent structure is nice.
Maybe one other thing to note about the workflow --just to have documented in this issue, not really asking you to modify the script to address this-- is that I have to run mmls on the disk image to determine the offset value, before running process_with_tsk_options.py.
I've only run through it once, but will keep trying in the next few weeks and will let you know if anything comes up. Thanks!

Hi Zach - I'm so glad to hear it's working! Yes, I anticipated that you'd have to run mmls first (that's exactly what I did when testing here). There might be a way to automate that, but I think that's a project for another day. I'm going to go ahead and merge this branch into master and consider it the 0.7.0 release. I'm closing the ticket for now but feel free to re-open if you have any feedback frmo testing!


fix: use correct vars

Hit footgun with param order...
/// Decodes the `eip1559` parameters from the `extradata` bytes.
///
/// Returns (`elasticity`, `denominator`)
pub fn decode_holocene_extra_data(extra_data: &[u8]) -> Result<(u32, u32), EIP1559ParamError> {

yeah, or ideally the order in which these params are encoded, which is the other way around.
very bad -.-


Update shields with GitHub's new look

:clipboard: Description
GitHub on the web got a new design (as a feature preview) this morning. It includes flatter, more minimal and rounded buttons, icons, etc. and gets rid of the old gradient buttons.
I would like to request updating all shields to reflect this new look, making things look more consistent and modern. Here is a screenshot of the new UI (notice the new clone button):

Hello. We don't typically redesign our badge spec in response to GitHub (or other sites where our badges are frequently viewed e.g: NPM, PyPI, packagist, etc) changing their stylesheet. Shields badges in their current form have existed since before GitHub's current visual design and I expect they'll continue to do so after they get bored of this one too.
I'm going to leave this issue open for the moment in case anyone wants to comment on it, but in general the visual design of our badges is not tied to GitHub's UI.

I agree with Chris :+1:
It's not entirely clear from me if your ask @urmilshroff was related to the Shields.io website, a request to update to one or more of the specific badge styles (flat, flat-square, plastic, etc.) that Shields offer, a request for a new style, a request to change the default style, some combination of the above, or something else entirely :smile:

I agree with Chris :+1:
It's not entirely clear to me if your ask @urmilshroff was related to the Shields.io website, a request to update to one or more of the specific badge styles (flat, flat-square, plastic, etc.) that Shields offer, a request for a new style, a request to change the default style, some combination of the above, or something else entirely :smile:

Sorry if I wasn't clear. I was requesting to update the little badges themselves (all of them) to match the new, flatter design language of GitHub's website, so that they look consistent with the rest of GitHub's UI when placed in a repository's README.
Infact, I didn't know that there were multiple badge styles in the first place, so I guess that technically solves my problem! 😅
Thanks for letting me know, I'm closing this PR. Cheers!


iOS app

This is the first PR for the iOS app to target the main branch. It should include all changes from the mobile branch.
In addition to the changes allowing the code to be merged into the main branch, this also includes some changes compared to the current UAlbertaALTLab mobile branch:

There is a new CURRENT_DB_VERSION constant to allow triggering a copy of an updated database file from the app into the user’s writable storage when the database schema and/or content changes
do-pip-install has been ported from shell to python and has several fancy new features, such as extracting python package versions from Pipfile.lock, and removing many megabytes of django translation files that the app would never use
Use new hfst-optimized-lookup v0.0.13, and compile C/C++ code from PyPI instead of checking in copy
Add empty ‘fake’ modules for packages like foma that are not currently used on mobile due to compilation needs

Let me know if you would prefer I break those up into smaller PRs.
I will email you a copy of the migrated database file if you would like to verify that this builds and runs on your machine.

Codecov Report

Merging #975 (af0d4c8) into main (0703ad5) will decrease coverage by 1.48%.
The diff coverage is 32.23%.

:exclamation: Current head af0d4c8 differs from pull request most recent head 23934e2. Consider uploading reports for the commit 23934e2 to get more accurate results

@@            Coverage Diff             @@
##             main     #975      +/-   ##
==========================================
- Coverage   79.59%   78.10%   -1.49%
==========================================
  Files         136      140       +4
  Lines        4640     4782     +142
  Branches      610      627      +17
==========================================
+ Hits         3693     3735      +42
- Misses        820      915      +95
- Partials      127      132       +5

Impacted Files
Coverage Δ

src/mobile.py
0.00% <0.00%> (ø)

src/morphodict/runserver/mobile_run_handler.py
25.49% <25.49%> (ø)

src/CreeDictionary/API/apps.py
50.00% <33.33%> (ø)

src/morphodict/site/save_secret_key.py
88.88% <33.33%> (-11.12%)
:arrow_down:

...dict/lexicon/management/commands/sortimportjson.py
34.37% <34.37%> (ø)

...phodict/runserver/management/commands/runserver.py
56.66% <45.00%> (-23.34%)
:arrow_down:

src/CreeDictionary/API/search/runner.py
75.00% <50.00%> (-3.38%)
:arrow_down:

src/CreeDictionary/API/search/affix.py
92.18% <66.66%> (-1.47%)
:arrow_down:

src/crkeng/site/settings_mobile.py
100.00% <100.00%> (ø)

src/morphodict/site/settings.py
81.94% <100.00%> (+0.51%)
:arrow_up:

... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0703ad5...23934e2. Read the comment docs.


[stable/prometheus] add alertmanger useExistingRole support

What this PR does / why we need it:
This PR adds support for telling AlertManager that there already is a Role definition (in the relevant namespace), that it should bind to, instead of creating a new Role.
On f.ex. OpenShift - its a somewhat common practice to NOT allow the user to create Role's - only to bind to existing ones.
This allows for having a Role fitting the needs of Alertmanager pre-created - and pointing this chart at that role instead.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the Values.yaml
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

If someone could share the lint output with  me - so I can fix it pls. :(  (link above requires me to give circleci write access to all my repos on github.. total WTF)

Hey @KlavsKlavsen - thanks for the contribution!
This is the error:
Error linting charts: Error processing charts
------------------------------------------------------------------------------------------------------------------------
 ✖ prometheus => (version: "11.10.1", path: "stable/prometheus") > Chart version not ok. Needs a version bump!
------------------------------------------------------------------------------------------------------------------------

And because you're adding a feature - could you also please set the version to: 11.11.0.

/assign @xtigyro

Added README docs - also for previous useClusterRole (which was a PR for me) :) - and bumped to correct version (doh :)

/ok-to-test

/lgtm


Upgrade Bazel to 7.3.0

Bazel 7.3.0 has been released.

https://github.com/bazelbuild/bazel/releases/tag/7.3.0

Thanks for the PR. However, it seems that github action's security model for external contributions is incompatible with using remote execution, due to requiring access to secrets.
Do you need this urgently? If not, I'll try to fix this issue first.


Import Error (x1 yoga gen6)

An import error is raised when running howdy test or add
sudo howdy test

Traceback (most recent call last):
  File "/usr/bin/howdy", line 95, in <module>
    import cli.add
  File "/usr/lib/security/howdy/cli/add.py", line 11, in <module>
    from recorders.video_capture import VideoCapture
  File "/usr/lib/security/howdy/recorders/video_capture.py", line 6, in <module>
    import cv2
ImportError: libfmt.so.8: cannot open shared object file: No such file or directory
[salvocos@yogagnome ~]$ sudo howdy test
Traceback (most recent call last):
  File "/usr/bin/howdy", line 109, in <module>
    import cli.test
  File "/usr/lib/security/howdy/cli/test.py", line 9, in <module>
    import cv2
ImportError: libfmt.so.8: cannot open shared object file: No such file or directory

I've searched for similar issues already, and my issue has not been reported yet.
System info:
inxi -b
System:    Kernel: 5.15.2-arch1-1 x86_64 bits: 64 Desktop: GNOME 41.1 Distro: ArcoLinux
Machine:   Type: Convertible System: LENOVO product: 20XYCTO1WW v: ThinkPad X1 Yoga Gen 6
CPU:       Info: Quad Core 11th Gen Intel Core i7-1165G7 [MT MCP]
Graphics:  Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
           Device-2: Syntek Integrated Camera type: USB driver: uvcvideo
           Display: x11 server: X.Org <IP_ADDRESS> driver: loaded: modesetting unloaded: fbdev,vesa resolution: 3840x2400~60Hz
           OpenGL: renderer: Mesa Intel Xe Graphics (TGL GT2) v: 4.6 Mesa 21.2.5

Howdy 2.6.1

You have a broken dlib installation, reinstalling dlib and python3-dlib might work?

It seems to be a problem related to the AUR package...
Let's hope it get fixed soon.

Any updates on this?

sudo pacman -S fmt ? It is in the Extra repo: https://archlinux.org/packages/extra/x86_64/fmt/.


Add configuration for deploying other language of preview site.

nemtech/symbol-docs https://github.com/nemtech/symbol-docs/pull/553
When creating PR, it creates preview website. but /ja seems not to be deployed.
https://deploy-preview-553--nemtech.netlify.app/ja
I expected that the deploying setting is on netlify. Could someone update them for next time?

Yeah, this could be very useful. I'll investigate!

On Netlify, you can change the build command to make alldocs, which also builds the Japanese version.
This change will double the build time.

On Netlify, you can change the build command to make alldocs, which also builds the Japanese version.
This change will double the build time.

@44uk This has now been implemented, all languages are available in PR previews. Thanks for the suggestion!
And thanks @dgarcia360!

@44uk This has now been implemented, all languages are available in PR previews. Thanks for the suggestion!
And thanks @dgarcia360!


Niedhui/exp

What have you changed? (mandatory)

implement builtin funciton: exp
fix fix ScalarFuncSig::Radians args length.

What are the type of the changes? (mandatory)
Improvement
How has this PR been tested? (mandatory)
unit test
Does this PR affect documentation (docs/docs-cn) update? (mandatory)
No
Does this PR affect tidb-ansible update? (mandatory)
No
Refer to a related PR or issue link (optional)
#3275, #3683

Hi, Thanks for your contribution!
Could you please summary your changes in the PR's title?

LGTM, merged.


How to run tasks where is no behavior specification?

Hi, suhr!
I have accidentally found this repo and your code examples are great!
How did you debug tasks where is no Init and Next predicates (for example, Day 1- Day 7)?
How did you run them?

Well, I did not debug or run them. So beware of possible mistakes in the spec.


Uneven anomaly score.

Sorry, Its me again.
Is it possible for a model, to be biassed to the right side or left side of the image, in the
sense that it can give a bigger score to the defects  on the same sample, but located on the right
side vs the left, like this?
Already tried differents image sizes and aspect ratios, with no change.
The training dataset includes vertical and horizontal flip, rotation , shear, zoom, brightness augment.
The lightning comes from a led ring, and the camera is located in its centre.
(Padim resnet_18)
https://www.youtube.com/watch?v=W4-ZtpJtE5c&ab_channel=tektronix475
Thanks a lot!

If you have a bias in the training data you would get that in the model as well since padim produces an embedding for each patch. But you won't get that if you have flip and rotate in the augmentations.
If you just want to make it more probable to detect anomalies in one part of the image, I guess you could simply apply a transfer function (maybe just linear) on one part of the score_map. I.e. not changing anything in the model or training, but just interpreting the output differently.
But I'm not sure I understand your problem fully.
Cool project btw. Are you building something or is it just for trying out algorithms?

The dataset has 800 pictures augmented from a initial group of 20 images.
It seem to me, that padim gives a higer anomaly score, when the defect is located to the
right side of the sample.  In the  bad score above 12.5  padim folder linked below,
you can see that the same sample gives a lower score, if the black spot is located on the right side of the pasta sample. Inside that folder the inferred images, are sorted by score from the lower, to the higher. The 5 samples with lower score, are the ones with the black stain on the left side.
This do not happen with the anomalous images, inferred with patchcore.
In the bad score above 2.35  patchcore folder , those images appears mixed or unsorted.
with almost no difference between the ones with the spot on the right, or the left.
Wierd isnt it?
https://drive.google.com/drive/folders/1_OF6-_MNTskgPd5Sqqtm1-p4WqDu0Jhl?usp=share_link

I am trying to learn something about images anomaly detection, by doing this experiments
with various algos like yours 4 example.
The conveyor is to test the performance of the model, with a set up closer to what could be, a real life application.

Okay! Yes that's s little weird. But I think 20 initial images is a bit few. My guess is that you would get better results if you used some more

Right, I will start from a bigger number of samples.
Thanks!


Make testpachd a runnable binary

This makes testpachd runnable with bazel run //src/testing/testpachd.
It will automatically setup a pachctl context when the server is ready, and restore to whatever you had before when exiting.
Right now you can't activate auth, but in #9886 I made testpachd auth-ready, so when that is merged I will add an "activateAuth" flag to start it up with auth.
This should eliminate most of integrations' need to use k8s in their tests, which will make their tests much faster.  It's also handy for local debugging, of course.
@pachyderm/pfs review is required because I refactored a utility function to not need a *testing.T, and updated a caller in src/server/pfs/testing.
Unrelated change: while I was in here, I made the grpc validation interceptor not log a warning during health checks.

Please take another look.  @Zhang-Muyang you have to approve if you're OK with the changes from PFS's perspective, a comment saying "looks good" won't do it.


More Details Screen for an Eatery

Use other data we get from Dining API. Ability to find Eatery on Map, send email, make phone call, etc.

Maps aspect of this issue handled with #67. Postponing all other aspects for now.


docs/Enhance README to explain how to install dependencies to use mock/network

Thanks for the pull request, and welcome! The MaidSafe team is excited to review your changes, and you should hear from @ustulation (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see CONTRIBUTOR.md for more information.


Latest installer does NOT support intel 550EM chipset

Added to FreeBSD here:
https://svnweb.freebsd.org/base/head/sys/dev/ixgbe/ixgbe_type.h?revision=320688&view=markup&sortby=date

Do we make a false indication that the latest installer does support it?

Indeed you did not.  I just want to be able to run Opnsense so if I can rebuild with my own driver until 19.1, that would be ideal.

Branch with MFC for our 11.1 added here: https://github.com/opnsense/src/tree/ixgbe_next
Builds ok, good start...

Here we go, this is a 18.1.9 installer image with the kernel replaced https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-201806061946-OpenSSL-vga-amd64.img.bz2
If it works, go to System: Firmware: Packages and lock the "kernel" package to avoid removing the driver on updates. Ask back here if 18.7 is safe to upgrade... at the moment it's not so we need to figure out a way to keep you hooked. :)

Nics are now detected  and functional with the IX driver, but disk is not :(

I added the following to loader.conf.local and AHCI errors have gone away with disks working as well.  Looks like a regression since 17.X seems to work.
hint.hpet.0.clock="0"
hint.ahci.0.msi = "2"
hint.ahci.6.msi = "2"

You can add these values to System: Settings: Tunables since 18.1.6 and they are written to /boot/loader.conf directly. It's a bit better to have them in the settings for import / export.

Thanks!


Nitropy fails to connect with the Nitrokey Pro on Windows 10

Running "nitropy pro"- commands with a Pro device causes an error:

Environment:

Nitrokey tool for Nitrokey FIDO2, Nitrokey Start & NetHSM 0.4.4
Windows 10

The same error occurs with the 0.4.5 version

@daringer Hi! Can you take a moment to look at this issue? It seems to be about Windows packaging, but I might be wrong.

yes this looks like the header files are not packaged together into the windows package. But libnitrokey is also needed, is there a libnitrokey available on this system (looks like it is set via env). So assuming the lib is there and all the other bits are working, best  case wine-build/nitropy.spec.tmpl just needs an addition to datas containing the nk_headers dir...

@Niklap97 Do you remember whether you used the binary or the installer?  Can you please try again with the binary from the latest release?

@robin-nitrokey I used the binary.
Its still the same for the latest release.


ROX-11211-collector-ci-migration-images

Description
Migrate images job to Openshift CI
Checklist

[ ] Investigated and inspected CI test results
[ ] Updated documentation accordingly

Testing Performed
See above

It's a good idea to use build-collector.sh in the mounted volume; since it avoids some of the "stale builder" image issues when updating this script.
I am wondering whether something is still using build-collector.sh except the Makefile. In this case, maybe we could just bundle all this logic in the Makefile itself ?

@JoukoVirtanen Please update this PR to point to an updated commit on master.

It's a good idea to use build-collector.sh in the mounted volume; since it avoids some of the "stale builder" image issues when updating this script.
I am wondering whether something is still using build-collector.sh except the Makefile. In this case, maybe we could just bundle all this logic in the Makefile itself ?

This was actually done in a previous PR. It should not have really appeared in "Files Changed", but did because of the way this branch was created. Openshift CI can't really use the Makefile to build or run images. I don't really see any reason to change the Makefile.

There is a problem here since COLLECTOR_VERSION and MODULE_VERSION.txt are created by Dockerfile.create_bundle, but that dockerfile is not used when building collector outside of Openshift CI. That is why the images job failed. I think that is the wrong place to try to create those files. What about trying to create them in builder/build/build-collector.sh?


[Feature Request] Right stick turning on controller

Describe the feature you'd like to see added
It would be a really great QoL feature to, when using a controller, have the right stick turn your character like you managed to do with the mouse! Playing with a controller really sucks now that I've gotten to experience that lol

This would be great, took me a while to adjust to not being able to turn with right stick


Translate /blog/2022/02/16/sig-node-ci-subproject-celebrates/ page into Chinese

Translate /blog/2022/02/16/sig-node-ci-subproject-celebrates/ page into Chinese

#32267

/approve

fix all comments, thanks to check again; @tengqm

/assign

/approve

fix all comments,thanks to review again.@ydFu

remove language/en
Issues or PRs related to English language
language/fr
language/ko
language/ru
language/vi
language/zh
sig/docs

removed  language/ko

/remove-language en
/remove-language fr
/remove-language ko
/remove-language ru
/remove-language vi

/approve

/remove-label tide/merge-method-squash
/retitle [zh] Translate /blog/2022/02/16/sig-node-ci-subproject-celebrates/ page into Chinese

LGTM,Thank you for your contribution to the community!
/lgtm


settingsSync.keybindingsPerPlatform not working on version 1.59.0

Describe
I updated to version 1.59.0 on Ubuntu a few days ago, nothing happened. However, when I did it on Windows today, it shows a conflict trying to merge keybindings. I realized it was because the VSCode didn't recognize the differences between platforms when I tried to re-enable settingsSync.keybindingsPerPlatform (which was enabled at first).
Checklist

[x] This issue occur when all extensions are disabled.
[ ] Check with other platform pairs.

Steps to Reproduce:

Check that the settings settingsSync.keybindingsPerPlatform is enabled.
Add a new keyboard shortcut on Windows or Ubuntu (check if it's synced).
Go to the other machine, check syncing, and that keybinding will appear.

Expected behaviour
VSCode should respect platform-specific keyboard shortcuts.
System info

Ubuntu

Version: 1.59.0
Commit: 379476f0e13988d90fab105c5c19e7abc8b1dea8
Date: 2021-08-04T23:13:20.182Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Linux x64 5.11.0-25-generic

Windows

Version: 1.59.0 (system setup)
Commit: 379476f0e13988d90fab105c5c19e7abc8b1dea8
Date: 2021-08-04T23:13:12.822Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Windows_NT x64 10.0.19042

I've got the same problem. MacOS and Linux. 😭

settingsSync.keybindingsPerPlatform options was enabled.

I have a third PC and it runs VSCode 1.58. There's no problem in that case.

MacOS

Version: 1.59.0
Commit: 379476f0e13988d90fab105c5c19e7abc8b1dea8
Date: 2021-08-04T23:14:40.191Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Darwin x64 20.5.0

Linux

Version: 1.59.0
Commit: 379476f0e13988d90fab105c5c19e7abc8b1dea8
Date: 2021-08-04T23:13:20.182Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Linux x64 5.10.56-1-MANJARO

…And I’ve got the same problem between macOS and Windows ☹
Now that seals it, I think 😂
System Info

macOS:

VS Code:Version: 1.59.0
Commit: 379476f0e13988d90fab105c5c19e7abc8b1dea8
Date: 2021-08-04T23:14:40.191Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Darwin x64 21.0.0

OS: Monterey Beta 5 (21A5304g)

Windows:

VS Code:Version: 1.59.0 (system setup)
Commit: 379476f0e13988d90fab105c5c19e7abc8b1dea8
Date: 2021-08-04T23:13:12.822Z
Electron: 13.1.7
Chrome: 91.0.4472.124
Node.js: 14.16.0
V8: 9.1.269.36-electron.0
OS: Windows_NT x64 10.0.19043

OS: Windows 10 21H1, Build 19043.1165

@thanhph111 I think that checks second box too, then (😄+☹)

@thanhph111 I think that checks second box too, then (😄+☹)

Thanks for reminding me, checking the box is always the easy part 😆.

Also occurs for me between Windows and Mac.


Forecast

Documentation
https://bulbapedia.bulbagarden.net/wiki/Forecast_(Ability)
Generation 5 Onward:

If a Pokémon transforms into Castform, the Pokémon will remain in the same form as the target Castform, regardless of the weather.
If Castform loses Forecast or Forecast is suppressed with Gastro Acid, it will revert to its normal form and not be able to change form. If Castform regains Forecast, it will change form to match the current weather, unless it would be in its normal form in the current weather.
Role Play fails if the target has the Ability Forecast. Entrainment fails if the user has the Ability Forecast. Forecast cannot be copied by Power of Alchemy or Receiver.

Relevant Code Points
Form Reversion
Further research required.
Role Play
subscr_135.s needs to be updated to fail if the target has Forecast.

Form stuff handled implicitly


Visualizing Feature Map

Hello again, the original DGCNN paper was able to show the feature map as below.
Do you know how to construct and visualize the feature map like this?
I would like to visualize feature map for each edgeconv layer.
Thank you.

I think the feature map is generated by calculating the feature distances between a given point (depicted as the red point) and the rest of the points.
For more details, I think you should ask the author of DGCNN for help.


pre 0.8.0 flagd-proxy service does not contain managed-by label

Changes introduced in #712 do not only validate the ownership of the flagd-proxy deployment but also the service, which leads to the service not being managed further by the OFO.
This only affects installations prior to 0.8.0 with flagd-proxy enabled.
A fix for this issue is to manually label the affected resource:
kubectl label -n open-feature-operator-system svc/flagd-proxy-svc app.kubernetes.io/managed-by=open-feature-operator

@beeme1mr I personally think it's sufficient to add a warning to the 0.8.0 release for this as a breaking change, wdyt?

Does ownership have to b validated via checking for that label?
I can see in a previous version of the Service resource for flagd-proxy that it contains ownerReferences in the metadata, and the managed-by field within the selector in the spec. I'm making naive assumptions that these fields are all injected and accessible so might  not be possible, but wondering if they could be used to validate ownership instead of the label?
Eg: Older version Service resource pre- 0.8.0
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: XXXX-XX-XXTXX:XX:17Z
  name: flagd-proxy-svc
  namespace: XXXX
  ownerReferences:
    - apiVersion: apps/v1
      kind: Deployment
      name: open-feature-operator-controller-manager # <-- here
      uid: XXXXXXXXXX
  resourceVersion: "XXXX"
  uid: 689f2c91-b183-4d4f-a295-26f27402b5d6
spec:
  clusterIP: XX.XXX.XXX.XX
  clusterIPs:
    - XX.XXX.XXX.XX
  internalTrafficPolicy: Cluster
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  ports:
    - xxx
  selector:
    app.kubernetes.io/managed-by: open-feature-operator # <-- here
    app.kubernetes.io/name: flagd-proxy
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

New service resource post 0.8.0 update:
apiVersion: v1
kind: Service
metadata:
  creationTimestamp:XXXX-XX-XXTXX:XX:17Z
  labels:
    app.kubernetes.io/managed-by: open-feature-operator # <-- new / easily added manually if needed
  name: flagd-proxy-svc
  namespace: flags-system
  ownerReferences:
    - apiVersion: apps/v1
      kind: Deployment
      name: open-feature-operator-controller-manager
      uid: xxxxxx
  resourceVersion: "xxxxxx"
  uid: xxxxx xx
spec:
  clusterIP: xx.xxx.xxx.xxx
  clusterIPs:
    - xx.xxx.xxx.xxx
  internalTrafficPolicy: Cluster
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  ports:
    - xxxx
  selector:
    app.kubernetes.io/managed-by: open-feature-operator
    app.kubernetes.io/name: flagd-proxy
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

I'd personally use the ownerReference as well, but I assumed the decision to use a label has been taken on purpose.


file_writer_config and config mixed up for text_dir and tex_dir

In config.py, tex_dir is defined inside config  (config['tex_dir']), same for 'text_dir'.
But in tex_file_writer.py, l32, it is file_writer_config['tex_dir'], that is used (not config).
This is in fact a very easy fix. I thought to add it within #185.
Pining @leotrs

My question was, should we put those in config or in file_writer_config ? Imo obviously in the latter

tex_dir are set to the variable config that is local to _parse_file_writer_config. Then, all of that is set to file_writer_config on L419. So there is no problem here.
I think the only problem is ambiguity. Perhaps we should change the variable inside _parse_file_writer_config to file_writer_config throughout to avoid confusion.

I don't think you get my point.
The issue is that text_dir is contained within config, and tex_dir in file_writer_config

lolwut. They should both be in file_writer_config

Yes, but they are not see https://github.com/ManimCommunity/manim/blob/ea79842b17ccb7e0a5eb33be5edc5abb4ce60b50/manim/config.py#L125
They are both in config

But that's what I meant! The line you just cited in inside _parse_file_writer_config. So the config that is set in that line is local to that function. Once that function finishes, its return value (the local config) is set to the global file_writer_config on line 419. So I think both live in file_writer_config. (They are not overwriting the global config at any time.)
Regardless of who is right, we should change the config variable inside _parse_file_writer_config to be called file_writer_config. Could you please do that?

Regardless of who is right, we should change the config variable inside _parse_file_writer_config to be called file_writer_config. Could you please do that?

I will do that !

we should change the config variable inside _parse_file_writer_config to be called file_writer_config.

@huguesdevimeux did you push this change? If not, I can do it real quick.

@huguesdevimeux did you push this change? If not, I can do it real quick.

I didn't. Please do if you can :D

Maybe you could fix #184 at the same time

Closed by latest commit of 2s ago.


Implement per-user series limits

When a series limit is reached, samples for existing series should still
be stored, so this is treated as a partial failure.
I tried various approaches to error propagation and handling, including
more complicated ones, but went for this medium-simple approach in the
end that uses gRPC errors to communicate a series-exceeded error from
the ingester back to the distributor, still manages to only partially
fail for the affected series, and communicates the specific error back
to the user. Due to only returning the last error encountered when
writing to multiple ingesters, this may at times cover up the
series-exceeded error if there is another error afterwards.

Great!  We really need to also limit the number of series for a given metric name (as this is the easiest way to overwhelm the index) to something like 10 or 20k.  Worth doing in this PR or a different one?

Couple of relatively minor things, and one extra ask.

@tomwilkie I did everything you remarked except for the per-metric limiting yet (will do separately). Separate commit for the UserStatesConfig, sorry, squashed the other feedback when I rebased.

Thanks!  LGTM


Workaround for array syntax bug with Chart.js<v3.7

@kurkle just for my info. PR 555 requires Chart.js v3.7 will require Chartjs 3.7. If and when the PR will be merged, should this workaround removed because there will be a string dependency with 3.7? If yes, maybe makes sense to add a TODO.

@kurkle just for my info. PR 555 will require Chartjs 3.7. If and when the PR will be merged, should this workaround be removed because there will be a strong dependency with 3.7? If yes, maybe makes sense to add a TODO.

Yes that could make sense. I'm not sure at which version of the plugin should we require Chart.js v3.7, but the comment does not need to include a plugin version.


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_611axtg9s7/clone/recipe/meta.yaml:24: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_611axtg9s7/clone/recipe/meta.yaml:25: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_611axtg9s7/clone/recipe/meta.yaml:25: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_611axtg9s7/clone/recipe/meta.yaml:65: missing_description: The recipe is missing a description
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_afqlx0qlzd/clone/recipe/meta.yaml:24: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_afqlx0qlzd/clone/recipe/meta.yaml:25: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_afqlx0qlzd/clone/recipe/meta.yaml:25: missing_wheel: For pypi packages, wheel should be present in the host section
WARNING: /tmp/abs_afqlx0qlzd/clone/recipe/meta.yaml:65: missing_description: The recipe is missing a description
Errors were found


Blog post image request: technical rebranding

Related Issue
No response
Description
Currently writing a blog post about the next step in the rebranding - specifically about the renaming of our technical assets (github/npm/docker etc).
This is a lower-level technical rebranding - changing the names of our packages and containers. Something a bit fun like a cardboard box with the old name crossed out and the new name written in place?

Hi @knolleary is something like this what you had in mind?


refactor: removed //nolint:staticcheck from deprecated tags

removed //nolint:staticcheck from deprecated tags

Description

closes: #4143
Commit Message / Changelog Entry
type: commit message

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (see CONTRIBUTING.md).
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[x] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[x] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

Codecov Report

Merging #4175 (f4137f9) into main (3bd0044) will not change coverage.
Report is 1 commits behind head on main.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4175   +/-   ##
=======================================
  Coverage   78.86%   78.86%
=======================================
  Files         188      188
  Lines       12994    12994
=======================================
  Hits        10248    10248
  Misses       2317     2317
  Partials      429      429

Files Changed
Coverage Δ

modules/core/04-channel/keeper/events.go
100.00% <100.00%> (ø)


Invalid Cast exception.

You are getting an Invalid Cast Exception when trying to execute this line of code:
await Context.Guild.GetAuditLogsAsync(x).FlattenAsync()
Only when x is over the amount of existing Audit entries, At least from what I noticed. Using (2.0.0-beta2-00979)

What's the stack trace of this exception? When I implemented audit logs, I retrieved more or less all of the audit log entries for Discord API and had no issues

Here is the stacktrace:
at System.Convert.DefaultToType(IConvertible value, Type targetType, IFormatProvider provider)    at Newtonsoft.Json.Linq.Extensions.Convert[T,U](T token)    at Newtonsoft.Json.Linq.JToken.Value[T](Object key)    at Discord.Rest.ChannelCreateAuditLogData.Create(BaseDiscordClient discord, AuditLog log, AuditLogEntry entry)    at Discord.Rest.AuditLogHelper.CreateData(BaseDiscordClient discord, AuditLog log, AuditLogEntry entry)    at Discord.Rest.RestAuditLogEntry..ctor(BaseDiscordClient discord, AuditLog fullLog, AuditLogEntry model, IUser user)    at Discord.Rest.RestAuditLogEntry.Create(BaseDiscordClient discord, AuditLog fullLog, AuditLogEntry model)    at System.Linq.Enumerable.SelectArrayIterator2.ToArray()
at System.Linq.Enumerable.ToArray[TSource](IEnumerable1 source)    at System.Collections.Immutable.ImmutableArray.CreateRange[T](IEnumerable1 items)
at System.Collections.Immutable.ImmutableArray.ToImmutableArray[TSource](IEnumerable1 items)    at Discord.Rest.GuildHelper.<>c__DisplayClass24_0.<<GetAuditLogsAsync>b__0>d.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at Discord.PagedAsyncEnumerable1.Enumerator.MoveNext(CancellationToken cancelToken)
at System.Linq.AsyncEnumerable.SelectManyAsyncIterator2.MoveNextCore(CancellationToken cancellationToken)    at System.Linq.AsyncEnumerable.AsyncIterator1.MoveNext(CancellationToken cancellationToken)
at System.Collections.Generic.AsyncEnumerableHelpers.ToArrayWithLength[T](IAsyncEnumerable1 source, CancellationToken cancellationToken)    at System.Collections.Generic.AsyncEnumerableHelpers.ToArray[T](IAsyncEnumerable1 source, CancellationToken cancellationToken)
at Discord.AsyncEnumerableExtensions.FlattenAsync[T](IAsyncEnumerable1 source)    at Path in Path.cs:line 139


Update function uses Fn

The generated update function uses the Fn trait to specify its parameter. This prevents moving values from the update-closure during updating of the tracked value. Using FnOnce would be more appropriated and allows for moving captured values:
#[tracker::track]
struct Model {
   #[tracker::no_eq]
   names: Vec<String>
}

fn main() {
   let mut model = Model {
      names: vec!["Alpha".to_string(), "Beta".to_string()],
      tracker: 0,
   };

   let new_name = "Gamma".to_string();
   model.update_names(move |names|{
      names.push(new_name); // Cannot move captured value in Fn closure. Using FnOnce would allow this.
   });
}

Thanks for pointing this out! Do you want to submit a PR?

I have made a PR (#6) with that change. I've been using it in a local project and it seems to work, but I haven't done extensive testing.

Sorry that it took so long, but now a new version (that includes your PR) is out on crates.io!
I think I can close this issue now.


Update showcases.js

{
title: "Mycelial Gallery",
description:
"We are a digital gallery that supports scientific mycological research.",
preview: require("./showcase/mycelialgallery.jpg"),
website: "https://www.mycelialgallery.io",
source: null,
tags: ["nft"],
},
];

hey @Mycelialgallery it seems this commit has some errors causing the checks to fail, could you please resolve these errors? Thanks!

Closing due to inactivity + build error(s). Please feel free to recrate PR in future


ApiGateway.RestApi.binaryMediaTypes become nil

binaryMediaTypes property in api response seems String Type

Don't know if this occurs on other services but when an array only has one element it seems that ApiGateway outputs it as "element" instead of ["element"]

fixed in https://github.com/swift-aws/aws-sdk-swift-core/pull/103

Found the cause of this. The hal+json reports an array with a single value just as the value. But multiple values as an array.


chore(helm): update latest chart version of jiva, zfs and lvm

Special notes for your reviewer:
cherry-pick:#256

We might first need to update the github release workflows on main and 2.x.


Statistically unlikely for it to work

This popped up in my GitHub recommendations, so I checked it out.
So a token is being generated here
https://github.com/xHERMIS/ID-to-TOKEN/blob/115bed8e94ee3859b0138fa750f82f1a7dbf0bb5/ID to TOKEN.py#L31
And each character of a token can be either one of the 26 letters, or one of the 10 digits.
And we're generating 6+38 such characters to form one token.
This means, we have (26+10)^(6+38) different potential tokens for a given user. And only one of them is correct. If we generate and check a downright ridiculous 1 billion tokens per millisecond, then it still takes a while to crunch through all of the tokens.
https://www.wolframalpha.com/input?i=(26%2B10)^(6%2B38)%2F(10^9)+milliseconds
But wait, on average we only need to crunch through half of them before getting a hit! Well, half of that is still ≈<PHONE_NUMBER>00000000000000000000000000000 × age of the universe 💀

this shit is just bruteforcing a token

I wrote this code in my free time (I don't know what I do)

I figured as much :)
Personally, I saw a chance to teach a little bit and give you the skills required to figure out when a brute forcer could work, and when it's hopeless. (Maths can be surprisingly useful.)
Do feel free to add a disclaimer to the Readme that says something along the lines of "❗ This isn't serious. If you do run the code, you better roll a Nat 20 to have any hope of it finishing before the universe expires."

I wrote this code in my free time (I don't know what I do)

This popped up in my GitHub recommendations, so I checked it out.
So a token is being generated here
https://github.com/xHERMIS/ID-to-TOKEN/blob/115bed8e94ee3859b0138fa750f82f1a7dbf0bb5/ID to TOKEN.py#L31
And each character of a token can be either one of the 26 letters, or one of the 10 digits. And we're generating 6+38 such characters to form one token.
This means, we have (26+10)^(6+38) different potential tokens for a given user. And only one of them is correct. If we generate and check a downright ridiculous 1 billion tokens per millisecond, then it still takes a while to crunch through all of the tokens.
https://www.wolframalpha.com/input?i=(26%2B10)^(6%2B38)%2F(10^9)+milliseconds
But wait, on average we only need to crunch through half of them before getting a hit! Well, half of that is still ≈<PHONE_NUMBER>00000000000000000000000000000 × age of the universe 💀

These calculations are correct, but honestly, they can become invalid. The second part of the token is publicly available; it's the timestamp of the account creation, which you can obtain by reversing the UID. This means you'd only have to brute-force the third part, which is the cryptographic component. Now, the search space is still pretty large, around (26+10)^38, but compared to the old pool, which is 36^6 times larger. I'd say it's a decrease, still impossible though. :]


Exception when reloading Kytos related to setup failover paths

Hi,
When reloading Kytos with an EVC created in a linear,3 topology (from h1 to h3, vlan 198):
2024-08-05 13:09:18,470 - ERROR [kytos.core.napps.base] (mef_eline) NApp: <Main(mef_eline, started<PHONE_NUMBER>79296)> unhandled exception Traceback (most recent call last):
  File "/usr/local/lib/python3.11/dist-packages/kytos/core/napps/base.py", line 250, in run
    self.execute()
  File "//var/lib/kytos/napps/kytos/mef_eline/main.py", line 101, in execute
    self.execute_consistency()
  File "//var/lib/kytos/napps/kytos/mef_eline/main.py", line 129, in execute_consistency
    circuit.try_setup_failover_path()
  File "//var/lib/kytos/napps/../napps/kytos/mef_eline/models/evc.py", line 897, in try_setup_failover_path
    self.setup_failover_path()
  File "//var/lib/kytos/napps/../napps/kytos/mef_eline/models/evc.py", line 925, in setup_failover_path
    for use_path in self.get_failover_path_candidates():
  File "//var/lib/kytos/napps/../napps/kytos/mef_eline/models/path.py", line 225, in get_disjoint_paths
    paths = cls.get_paths(circuit, max_paths=cutoff,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "//var/lib/kytos/napps/../napps/kytos/mef_eline/models/path.py", line 136, in get_paths
    api_reply = requests.post(endpoint, json=request_data)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/requests/api.py", line 115, in post
    return request("post", url, data=data, json=json, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/requests/api.py", line 59, in request
    return session.request(method=method, url=url, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/requests/sessions.py", line 589, in request
    resp = self.send(prep, **send_kwargs)                                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/requests/sessions.py", line 703, in send                                                                                r = adapter.send(request, **kwargs)                                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/requests/adapters.py", line 519, in send                                                                                raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=8181): Max retries exceeded with url: /api/kytos/pathfinder/v3/ (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7ff528756fd0>: Fa
iled to establish a new connection: [Errno 111] Connection refused'))

Looks like this was accidentally closed on https://github.com/kytos-ng/mef_eline/issues/497. Reopening for confirmation cc'ing @Ktmi @Alopalao

Yes, I meant to add 498 but I added 489. This issue was not addressed.

Yes, I meant to add 498 but I added 489. This issue was not addressed.

OK. No problem, it happens. Let's keep this still open then.


Change all "blue" colors to our ODCZ color #057fa5

Change all "blue" colors to our ODCZ color #057fa5, if possible.

Actually, let's postpone this until required.


Explicitly add circularising links to unitig GFA

This is a small change to the unitig GFA output. Instead of just relying on the last character of the unitig name to indicate circularity (l for linear and c for circular), this change gives circular unitigs an explicit overlap-free link in the GFA file.
Before:
S       utg000030c      GGAACAAACTGCATTAATTC...TATCACCAGAAAAGACAGAT	LN:i:69013
a       utg000030c      0       0ab4d3ed-f533-4bfd-880c-fa1a0568443b:17-68951    +       3431
a       utg000030c      3431    1e81464e-9194-40f4-ba59-d29f9b1a7d65:33-68891    +       16745
a       utg000030c      20176   fb2dd196-c8bb-4770-b693-d02329c1dab2:1-67957     +       24

After:
S       utg000030c      GGAACAAACTGCATTAATTC...TATCACCAGAAAAGACAGAT	LN:i:69013
L       utg000030c      +       utg000030c      +       0M
L       utg000030c      -       utg000030c      -       0M
a       utg000030c      0       0ab4d3ed-f533-4bfd-880c-fa1a0568443b:17-68951    +       3431
a       utg000030c      3431    1e81464e-9194-40f4-ba59-d29f9b1a7d65:33-68891    +       16745
a       utg000030c      20176   fb2dd196-c8bb-4770-b693-d02329c1dab2:1-67957     +       24

This change is mainly to make miniasm assemblies for bacterial genomes (in which circular unitigs are common) display as circular when loaded in Bandage.
Thanks so much for this great tool (and all your others), and let me know if you have any questions!
Ryan

Thanks. As I remember, in the miniasm gfa, we only see
L       utg000030c      +       utg000030c      +       0M

but not
L       utg000030c      -       utg000030c      -       0M

I could be wrong. Haven't looked at the miniasm source code for a long time...

For edges between linear contigs in the miniasm graph, both directions are shown, e.g.:
L	utg000013l	+	utg000036l	+	60794M	SD:i:46302
L	utg000036l	-	utg000013l	-	60576M	SD:i:62899

Which is why I included both directions for the circularising links as well. But yes, it is redundant, so only including one direction would be fine too!

I see. Then you change is consistent. Thanks.


Easi 1883/email client

EASI-1883
Changes and Description

Wrote a small reusable email service
Built an interface layer to separate dependency injection from implementation

How to test this change

Install and run Mailcatcher as defined in https://mailcatcher.me/
Run unit tests
Assert that all unit tests succeed
Assert that an email is captured in your Mailcatcher web interface

PR Author Review Checklist

[ ] Met the ticket's acceptance criteria, or will meet them in a subsequent PR.
[ ] Added or updated tests for backend resolvers or other functions as needed.
[ ] Added or updated client tests for new components, parent components, functions, or e2e tests as necessary.
[ ] Tested user-facing changes with voice-over and the rotor menu

PR Reviewer Guidelines

It's best to pull the branch locally and test it, rather than just looking at the code online!
Check that all code is adequately covered by tests - if it isn't feel free to suggest the addition of tests.
Always make comments, even if it's minor, or if you don't understand why something was done.

@OddTomBrooks Also looks like there might be a failing server test. Not sure it looks related - perhaps updating the branch with main can fix it?

@OddTomBrooks , great work! I really like this approach for an email client.
Have you considered setting up mailcatcher as part of the local docker image? I believe EASI is set up that way, and it would be cleaner than everyone needing to install this manually.
EASI docker- compose


Package imports should be automatically determined during build-time

See the conversation that was started in a different pull request:
https://github.com/adobe/aem-project-archetype/pull/209/#discussion_r301188597

@jckautzmann the asteristix in the line Import-Package: javax.inject;version="0.0.0",javax.annotation;version="0.0.0",*  does already import the dependencies automatically. Therefore I'll close this issue.


Document case insensitive matching of literals

It seems the case insensitive matching of literals hasn't been documented, better do this:

[ ] Update https://pegjs.org/
[x] Update README.md

Thanks to @jtenner https://github.com/pegjs/pegjs/issues/34#issuecomment-316757006 for finding this oversight 😉

This issue can be closed. pegjs.org does have the 'i' suffix documented.

I'm keeping this open so that I remember to update the site's documentation when I get around to updating the online editor


Updating destroy to remove instances and images on non-purge destroy

\cc @jkeiser @fnichol

:+1:  Can you leave an issue out there to wait for termination of other types as well?  (Unless they already are.)

Sure, I'll throw an issue up there

Actually I'm not sure any other resources need a wait.  Most other things immediately disappear when you call :destroy


scatter_add requires dimension numbers, default value invalid

jax.lax.scatter_add(np.zeros(10), np.asarray([3, 1]), np.asarray([5., 7.]))

fails with AssertionError because of assert type(dimension_numbers) is ScatterDimensionNumbers
The following works, but there is no documentation on these parameters, so I inferred them from the tests.
dnums = jax.lax.ScatterDimensionNumbers(update_window_dims=(), inserted_window_dims=(0,), scatter_dims_to_operand_dims=(0,), index_vector_dim=1)
jax.lax.scatter_add(np.zeros(10), np.asarray([3, 1]), np.asarray([5., 7.]), dnums)

Also, it might be worth adding jax.lax.scatter with the first argument set to zeros.

Thanks for the issue report!
I'll add doc strings for these functions (we haven't gotten around to documenting all of lax yet), but essentially gather and scatter_add are direct wrappers around XLA's gather and scatter primitives, so you can refer to the XLA documentation for details. That said, I personally find their APIs too complicated. Expect us to simplify these APIs in the future.
For most gather use cases, it's probably better to use NumPy indexing syntax, which will lower to gather already.
For scatter, unfortunately we don't yet have an equivalent to the gather syntax, but we definitely plan to add some kind of update syntax that looks a lot more like NumPy indexed updates! The closest I can offer you right now is some gradient trickery that exploits the fact that scatter-add is the transpose of gather, and we do have nice indexing support for gather:
In [49]: x = np.ones((10,), onp.float32)

In [50]: y = onp.array([2, 4, 5])

In [51]: def scatter_add(f, base, updates):
    ...:     _, grad = jax.vjp(f, base)
    ...:     (out,) = grad(updates)
    ...:     return base + out
    ...:

In [52]: scatter_add(lambda a: a[y], x, np.array([7, 4, 32], np.float32)).copy()
Out[52]: array([ 1.,  1.,  8.,  1.,  5., 33.,  1.,  1.,  1.,  1.], dtype=float32)

Expect us to offer something along those lines in the future, but it won't be that exact implementation.

PR #429 adds some simple doc strings, although I'm not sure they will clarify much...
We can continue the discussion about more convenient update syntax on
https://github.com/google/jax/issues/101

Thanks!


[kotlin2cpg] Partly revert #4187

This PR partly reverts #4187. The change to CompilerAPI.makeEnvironment breaks sptests. We may want to revisit that change later as it was intented to improve performance.
With publishing this PR here locally sptests runs fine again.

How do I reproduce the breaking issue you are referring to as sptest? Let me see how this can be fixed?
This consumes too much of memory and CPU for large repo. As it tries to build the type information cache for every path that is being passed as first parameter. The list we are passing is basically path to each and every child folder of the given project folder.
Which can be also achieved by passing only the root directory.

I don't know if you have access codescience sptests but I guess you don't. On https://github.com/ShiftLeftSecurity/springboot-kotlin-webgoat the kotlin compiler completely errors out when only the root dir is given and that results in no type information at all.

@max-leuthaeuser Do you have a deadline you could set for how long you're willing to wait for an alternative fix that achieves both goals? At least we have the webgoat for Kotlin to test against while @pandurangpatil looks into a fix

Its for a running POC where the customer waits for an update. I don't know how patient this customer is, sorry. Maybe @gacevedo can say more.

And from my point of view: the optimization in https://github.com/joernio/joern/pull/4187 has never been released to the customers anyway. So we don't lose anything there. But we might lose type information now which may result in many lost findings as the broken sptests indicate. We should aim for high precision first and performance second.

So I merged this to unblock the POC. A PR to get a fixed version of the performance optimization is very welcome nevertheless.

@DavidBakerEffendi @max-leuthaeuser
I understand the importance of precision. At the same time in my humble opinion, we should have the failing use cases incorporated as unit tests. Otherwise, it becomes difficult to collaborate. This becomes very crucial while making any performance improvements. As the only way to make sure nothing is breaking is by running the unit test cases.
cc: @tuxology @fabsx00

@pandurangpatil
This is very true. We did not have a test for that in first place and relying on our internal sptests is not sufficient here as you guys do not have access. Also, these tests are only triggered once kotlin2cpg is updated internally (https://github.com/ShiftLeftSecurity/kotlin2cpg).


add FinOps-related exporters

In order to analyze cloud costs and align them with various business metrics, we would like to have a set of cost exporters. They query costs from different cloud providers and expose them as Prometheus metrics. This PR adds the following FinOps-related exporters:

AWS Cost Exporter
Azure Cost Exporter
Kubernetes Cost Exporter

PS: I am not sure about which category should I put these exporters to. Since these exporters expose cost metrics, I created a new category called FinOps. Please feel free to comment or adjust the category directly. Thanks!

Sample output of AWS Cost Exporter
Sensitive information has been masked.
# HELP aws_daily_cost_usd Daily cost of an AWS account in USD
# TYPE aws_daily_cost_usd gauge
aws_daily_cost_usd{ChargeType="Usage",EnvironmentName="sandbox",ProjectName="myproject",Publisher="<aws_account_1>",RegionName="eu-central-1"} 10.1827240691
aws_daily_cost_usd{ChargeType="Usage",EnvironmentName="sandbox",ProjectName="myproject",Publisher="<aws_account_1>",RegionName="other"} 4.258201088100001
aws_daily_cost_usd{ChargeType="Usage",EnvironmentName="prod",ProjectName="myproject",Publisher="<aws_account_2>",RegionName="eu-central-1"} 68.6121380948
aws_daily_cost_usd{ChargeType="Usage",EnvironmentName="prod",ProjectName="myproject",Publisher="<aws_account_2>",RegionName="other"} 2.6191806712
...
...

Sample output of Azure Cost Exporter
Sensitive information has been masked.
# HELP azure_daily_cost_usd Daily cost of an Azure account in USD
# TYPE azure_daily_cost_usd gauge
azure_daily_cost_usd{ChargeType="ActualCost",EnvironmentName="prod",ProjectName="myproject",ServiceName="Virtual Network",Subscription="<subscription_id_1>",TenantId="<tenant_id_1>"} 0.439500230497108
azure_daily_cost_usd{ChargeType="ActualCost",EnvironmentName="prod",ProjectName="myproject",ServiceName="VPN Gateway",Subscription="<subscription_id_1>",TenantId="<tenant_id_1>"} 4.191000368311904
azure_daily_cost_usd{ChargeType="ActualCost",EnvironmentName="dev",ProjectName="myproject",ServiceName="Azure Container Apps",Subscription="<subscription_id_2>",TenantId="<tenant_id_2>"} 0.371846875438938
azure_daily_cost_usd{ChargeType="ActualCost",EnvironmentName="dev",ProjectName="myproject",ServiceName="Service Bus",Subscription="<subscription_id_2>",TenantId="<tenant_id_2>"} 13.99512952148999
...

Sample output of Kubernetes Cost Exporter
# HELP kubernetes_daily_cost_usd Kubernetes daily cost in USD aggregated by namespace
# TYPE kubernetes_daily_cost_usd gauge
kubernetes_daily_cost_usd{namespace="ingress"} 0.9518491293125411
kubernetes_daily_cost_usd{namespace="ns1"} 1.6744666615442327
kubernetes_daily_cost_usd{namespace="ns2"} 0.7495529489062231
kubernetes_daily_cost_usd{namespace="ns3"} 1.0655696937099663
kubernetes_daily_cost_usd{namespace="kube-system"} 1.1914006049581642
...

@gluckzhang Nice, thanks! I think the "FinOps" section makes sense. If someone disagrees later, they can always move them to another section :)
Could you share some example metrics outputs of these exporters, just to make sure they are somewhat within Prometheus metrics conventions / guidelines?

@gluckzhang Oh sorry, I missed those collapsible sections, thanks! So the conventions I was referring to were https://prometheus.io/docs/practices/naming/ and https://prometheus.io/docs/instrumenting/writing_exporters. Yeah, two points that jump out to me:

Usually we'd want to have a unit in the metric name, as otherwise it's not clear what currency this is in. Here I'd expect a currency like usd or such to be part of the metric name. If the metric name is not a good place for that for some reason, putting it into a label or even (in special cases) into another time series that can be joined in on compatible labels could be an ok-ish alternative. Not sure though if there are any complications around the currency with these exporters?
Having the rest of the metric name be more descriptive (as you said) would indeed be a good idea. Think about it from the perspective of someone new to your exporter, maybe even just some casual consumer who was not involved in setting up the exporter: if they just look at the metric name, will they be confused about the exact meaning of the metric, or can they get a good understanding?

So yeah, maybe something like aws_daily_cost_usd is better. Although then I'd still have one question: is that daily cost according to a trailing/moving 24h window, or is that 24h window aligned with fixed times, so it goes up over the day and then suddenly jumps to 0 again when the next 24h period starts? Usually a moving-window approach would be more Prometheus-ish, because otherwise you also need to build your queries and dashboards in a way that they are somehow aligned to fixed-start/end 24h time windows.
Anyway, just some input from someone who doesn't have much knowledge about these exporters, would be great to learn more :)

@gluckzhang I see, thanks for the clarification! Yes, I wouldn't block adding this on the moving-window question. It's a bit of an impedance mismatch with how things are usually done in Prometheus, but with exporters there are also often external constraints leading to those kinds of situations. But maybe it also depends on how people usually want to use the data: always based on a calendar day, or on a moving window.

Yes, super agree. The feedback is very helpful, thanks! I will update the metric name, description, and documentation to reflect our discussions. Will let you know once it is ready to merge this PR :)

Hi @juliusv, FYI, I have improved the exporters based on your comments. Thank you for giving us feedback. We will keep improving the exporters in the future. Cheers!

https://github.com/opensourceelectrolux/aws-cost-exporter/pull/1
https://github.com/opensourceelectrolux/azure-cost-exporter/pull/1
https://github.com/opensourceelectrolux/kubernetes-cost-exporter/pull/1

Hi @juliusv, just in case the GitHub notification does not reach you. We have improved the exporters and now the PR is ready to be merged. Thank you :)

Thanks! :+1:


More unit tests

PR for #42

Coverage increased (+2.6%) to 92.704% when pulling 7076c3ff47d6983969b87f39376205252106f6c7 on 42 into 7fefd349547abf84bd1847cb8c3ecda09dd3c092 on master.

Coverage increased (+2.6%) to 92.704% when pulling 7076c3ff47d6983969b87f39376205252106f6c7 on 42 into 7fefd349547abf84bd1847cb8c3ecda09dd3c092 on master.

@rultor merge pls

@rultor merge pls

@amihaiemil OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge pls

@amihaiemil Done! FYI, the full log is here (took me 1min)


Consider only the 5xx responses as errors

How to categorize this PR?

/area monitoring
/kind enhancement
What this PR does / why we need it:
Consider only the 5xx responses as errors
Previously, requests with response codes other than 2xx were considered an error. That includes redirection messages and client error responses, but on this panel we'd like to focus on the server side errors.
Special notes for your reviewer:
/cc @rickardsjp @adenitiu

Release note:

Fix the error rate promql expression on the "Kubernetes Control Plane Status" Grafana dashboard, "API Server Request rates" panel.

/approve

/retest
/milestone 1.62

/milestone v1.62


Is it possible to download model and use it locally from hugginface?

Thanks for uploading the latest model for code summarization ( https://huggingface.co/Salesforce/codet5-base-multi-sum)
I need to download the model (with wget) and then set it as a cache.
When I tried to use tokenizer by tokenizer = RobertaTokenizer.from_pretrained('Salesforce/codet5-base-multi-sum'), I get the following error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/dist-packages/transformers/tokenization_utils_base.py", line 1654, in from_pretrained
    fast_tokenizer_file = get_fast_tokenizer_file(
  File "/usr/local/lib/python3.8/dist-packages/transformers/tokenization_utils_base.py", line 3486, in get_fast_tokenizer_file
    all_files = get_list_of_files(
  File "/usr/local/lib/python3.8/dist-packages/transformers/file_utils.py", line 2103, in get_list_of_files
    return list_repo_files(path_or_repo, revision=revision, token=token)
  File "/usr/local/lib/python3.8/dist-packages/huggingface_hub/hf_api.py", line 602, in list_repo_files
    info = self.model_info(
  File "/usr/local/lib/python3.8/dist-packages/huggingface_hub/hf_api.py", line 585, in model_info
    r = requests.get(path, headers=headers, timeout=timeout)
  File "/usr/lib/python3/dist-packages/requests/api.py", line 75, in get
    return request('get', url, params=params, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/api.py", line 60, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 514, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='huggingface.co', port=443): Max retries exceeded with url: /api/models/Salesforce/codet5-base-multi-sum (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1131)')))

I cannot use that way since I have a proxy and I can use only curl or wget. Each request inside python is blocked.
Could you please tell me how is it possible to download and use a cached model and tokenizer?

Hi, you can download the tokenizer and model from here: https://huggingface.co/Salesforce/codet5-base-multi-sum/tree/main. For example, you can obtain the model checkpoint using wget https://huggingface.co/Salesforce/codet5-base-multi-sum/blob/main/pytorch_model.bin.


Don't require space character in output

Should finally resolve https://github.com/googlei18n/fontmake/issues/82

r+

Thanks!


Renamed deprecated fonts.enableDefaultFonts value in nix config

Changed the deprecated fonts.enableDefaultFonts to fonts.enableDefaultPackages in nix/module.nix.
See https://github.com/NixOS/nixpkgs/commit/83793ca8980283a6f62c028ebed336b9d1bbf80f for more info.

@fufexan

This breaks my system build on NixOS 23.05 since the new option is only available in unstable. Will hyprland only support NixOS unstable now? Or can we figure out a better way to make it work on both the latest stable NixOS and on unstable? I could move to the upstreamed module instead of using the flake input module as I do now, but then I still could not build latest hyprland on stable NixOS :(

This breaks my system build on NixOS 23.05 since the new option is only available in unstable. Will hyprland only support NixOS unstable now? Or can we figure out a better way to make it work on both the latest stable NixOS and on unstable? I could move to the upstreamed module instead of using the flake input module as I do now, but then I still could not build latest hyprland on stable NixOS :(

You should consider using the native module (the one in nixpkgs) if you are on nixos stable. Hyprland, as far as I'm aware, has always targeted nixos unstable.

Looks like the wiki has been updated with a recommended way to run the development version of hyprland on NixOS stable. So I guess I should just follow that everything is good :smiley:


Homework5

What changes are you trying to make? (e.g. Adding or removing code, refactoring existing code, adding reports)
I updated homwork5 completly.
What did you learn from the changes you have made?
Was there another approach you were thinking about making? If so, what approach(es) were you thinking of?
Were there any challenges? If so, what issue(s) did you face? How did you overcome it?
How were these changes tested?
A reference to a related issue in your repository (if applicable)
Checklist

[ x] I can confirm that my changes are working as intended

HW 6 Missing.


Incorrect imports for generated files

I am unable to build a package when a proto file is included from a separate package.
src/foo/foo.proto
package foo;

message Foo
{
  optional string foo = 1;
}

protoc --go_out=src/ --proto_path=src/ src/foo/foo.proto
src/foo/foo.pb.go
// Code generated by protoc-gen-go.
// source: foo/foo.proto
// DO NOT EDIT!

/*
Package foo is a generated protocol buffer package.

It is generated from these files:
    foo/foo.proto

It has these top-level messages:
    Foo
*/
package foo

import proto "github.com/golang/protobuf/proto"
import math "math"

// Reference imports to suppress errors if they are not otherwise used.
var _ = proto.Marshal
var _ = math.Inf

type Foo struct {
    Foo              *string `protobuf:"bytes,1,opt,name=foo" json:"foo,omitempty"`
    XXX_unrecognized []byte  `json:"-"`
}

func (m *Foo) Reset()         { *m = Foo{} }
func (m *Foo) String() string { return proto.CompactTextString(m) }
func (*Foo) ProtoMessage()    {}

func (m *Foo) GetFoo() string {
    if m != nil && m.Foo != nil {
        return *m.Foo
    }
    return ""
}

func init() {
}

src/bar/bar.proto
package bar;

import "foo/foo.proto";

message Bar
{
  optional foo.Foo foo = 1;
  optional string bar = 2;
}

protoc --go_out=src/ --proto_path=src/ src/bar/bar.proto
src/bar/bar.pb.go
// Code generated by protoc-gen-go.
// source: bar/bar.proto
// DO NOT EDIT!

/*
Package bar is a generated protocol buffer package.

It is generated from these files:
    bar/bar.proto

It has these top-level messages:
    Bar
*/
package bar

import proto "github.com/golang/protobuf/proto"
import math "math"
import foo "foo/foo.pb"

// Reference imports to suppress errors if they are not otherwise used.
var _ = proto.Marshal
var _ = math.Inf

type Bar struct {
    Foo              *foo.Foo `protobuf:"bytes,1,opt,name=foo" json:"foo,omitempty"`
    Bar              *string  `protobuf:"bytes,2,opt,name=bar" json:"bar,omitempty"`
    XXX_unrecognized []byte   `json:"-"`
}

func (m *Bar) Reset()         { *m = Bar{} }
func (m *Bar) String() string { return proto.CompactTextString(m) }
func (*Bar) ProtoMessage()    {}

func (m *Bar) GetFoo() *foo.Foo {
    if m != nil {
        return m.Foo
    }
    return nil
}

func (m *Bar) GetBar() string {
    if m != nil && m.Bar != nil {
        return *m.Bar
    }
    return ""
}

func init() {
}

go build foo
go build bar
src/bar/bar.pb.go:18:8: cannot find package "foo/foo.pb" in any of:
/usr/local/Cellar/go/1.3/libexec/src/pkg/foo/foo.pb (from $GOROOT)
/Users/patrick/Code/workspace/src/foo/foo.pb (from $GOPATH)
When I change import foo "foo/foo.pb" to import foo "foo" the package will build correctly. Is this an issue with my use of the generated files or an issue with code generation? Thanks.

Any update? I'm still running a forked copy just to get code that compiles.

Ping? As is, this library is unusable.

Hi @tv42, I had this issue today. I find that using https://github.com/gogo/protobuf addresses this issue for me.
protoc --proto_path=${GOPATH}/src:. --gogo_out=. **/*.proto

This exact issue was firstly posted at least 3 years ago. Cannot believe that Google haven't solved it yet!!

@dsymonds, can you look at this?

For those stumbling across this issue while trying to figure out how to get protoc to generate useful import paths for Go (as I did)... while this issue as originally reported may have been solved, this is still a very confusing area of protoc/Go, and the docs at https://developers.google.com/protocol-buffers/docs/reference/go-generated describe a solution in the section on Packages that worked for me:

You can override the default generated package for a particular .proto using the option go_package in your .proto file.

tl;dr, I basically did this in my .proto file:
package foo;
option go_package = "bitbucket.org/dkolbly/lib/foo";

and then other .proto files importing that one wound up with the right import statement.

For those stumbling across this issue while trying to figure out how to get protoc to generate useful import paths for Go (as I did)... while this issue as originally reported may have been solved, this is still a very confusing area of protoc/Go, and the docs at https://developers.google.com/protocol-buffers/docs/reference/go-generated describe a solution in the section on Packages that worked for me:

You can override the default generated package for a particular .proto using the option go_package in your .proto file.

tl;dr, I basically did this in my .proto file:
package foo;
option go_package = "bitbucket.org/dkolbly/lib/foo";

and then other .proto files importing that one wound up with the right import statement.

Very helpful

It does not work great btw. If you use go modules then protoc will produce the file in the bitbucket.org/dkolbly/lib/foo folder (in the previous comment example).
I'm currently using the protobuf files from a rust project, and I have to manually modify them to add the go_package option every time there is a change.
This is quite hacky, but here is what I do to solve both of these problems:
for file in proto/types/*
do
    sed -i '' 's#syntax = "proto3";#syntax = "proto3"; option go_package = "github.com/mimoo/X/proto/types";#' $file
done

protoc -I proto/types --go_out=proto/types proto/types/*.proto
mv proto/types/github.com/mimoo/X/proto/types/* proto/types
rm -rf proto/types/github.com

I have this problem because I am outputting my generated protobufs in a different directory than the the one in which the proto source files live, so solutions that depend on the output path matching the import path don't work for me.
The correct solution is, at protobuf generate/compile time, to specify a the package that the compiler should use for a given input proto file. This way you can have shared protobuf files and downstream consumers organize the artifacts however they want without polluting the source files with a go_package option (which as people have pointed out is specific to the downstream use case).
It turns out there is support for such an option! It looks like:
--go_out=Mfoo/foo.proto=bitbucket.org/dkolbly/lib/foo

You can specify any number of these and they're seperated from other options with a comma, like normal.

Small precision to @dcow 's reply: --go_out=Mfoo/foo.proto=bitbucket.org/dkolbly/lib/foo:..
Notice the semicolon and point at the end to generate the file in the current folder.

Golang: because hacks with a zillion fanboys on Twitter can too impose an incredibly badly designed language on an entire industry.


[Event Hubs Client] Enable Idempotent Producer Tests

Summary
The focus of these changes is to enable the Live tests for the Idempotent Producer feature now that the service team has confirmed that it has rolled out to all Azure clouds in our test matrix.
Last Upstream Rebase
Thursday, December 3, 4:18pm (EST)

/azp run net - eventhub - tests


Persist tiles to the file system

The app should cache the downloaded tiles. That would speed up the load time.

fixed by #10