Error exporting YoloX model to ONNX

I was trying to do onnx export of yolox model - but i got an error.
The script that I used is:
python tools/deployment/pytorch2onnx.py
configs/yolox/yolox_s_8x8_300e_coco.py
work_dirs/yolox_s_lite/latest.pth
--output-file output.onnx
--input-img demo/demo.jpg
--dynamic-export
--show
--verify
--simplify
But then I get this error:
File "/data/ssd/files/a0393608/work/code/github/openmmlab/mmdetection/tools/deployment/pytorch2onnx.py", line 330, in
normalize_cfg = parse_normalize_cfg(cfg.test_pipeline)
File "/data/ssd/files/a0393608/work/code/github/openmmlab/mmdetection/tools/deployment/pytorch2onnx.py", line 218, in parse_normalize_cfg
assert len(norm_config_li) == 1, 'norm_config should only have one'
AssertionError: norm_config should only have one
This is because yolox doesn't have input Normalization. I worked around that by providing a dummy normalization. But then I got another error.
File "/data/ssd/files/a0393608/work/code/github/openmmlab/mmdetection/mmdet/models/detectors/base.py", line 169, in forward
return self.onnx_export(img[0], img_metas[0])
File "/data/ssd/files/a0393608/work/code/github/openmmlab/mmdetection/mmdet/models/detectors/single_stage.py", line 169, in onnx_export
*outs, img_metas, with_nms=with_nms)
File "/user/a0393608/work/apps/miniconda3/envs/edgeai-mmdetection/lib/python3.7/site-packages/mmcv/runner/fp16_utils.py", line 186, in new_func
return old_func(*args, **kwargs)
File "/data/ssd/files/a0393608/work/code/github/openmmlab/mmdetection/mmdet/models/dense_heads/base_dense_head.py", line 492, in onnx_export
bboxes = self.bbox_coder.decode(
File "/user/a0393608/work/apps/miniconda3/envs/edgeai-mmdetection/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1178, in getattr
type(self).name, name))
AttributeError: 'YOLOXHead' object has no attribute 'bbox_coder'
Environment
sys.platform: linux
Python: 3.7.11 (default, Jul 27 2021, 14:32:16) [GCC 7.5.0]
CUDA available: True
GPU 0,1,2,3: RTX A4000
CUDA_HOME: /usr/local/cuda
NVCC: Build cuda_11.1.TC455_06.29190527_0
GCC: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
PyTorch: 1.10.0+cu111
PyTorch compiling details: PyTorch built with:

GCC 7.3
C++ Version: 201402
Intel(R) Math Kernel Library Version 2020.0.0 Product Build 20191122 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v2.2.3 (Git Hash 7336ca9f055cf1bfa13efb658fe15dc9b41f0740)
OpenMP 201511 (a.k.a. OpenMP 4.5)
LAPACK is enabled (usually provided by MKL)
NNPACK is enabled
CPU capability usage: AVX512
CUDA Runtime 11.1
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86
CuDNN 8.0.5
Magma 2.5.2
Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CUDA_VERSION=11.1, CUDNN_VERSION=8.0.5, CXX_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/c++, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -DEDGE_PROFILER_USE_KINETO -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_VERSION=1.10.0, USE_CUDA=ON, USE_CUDNN=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON,

TorchVision: 0.11.0a0+972e9af
OpenCV: 4.5.4
MMCV: 1.4.2
MMCV Compiler: GCC 7.5
MMCV CUDA Compiler: 11.1
MMDetection: 2.20.0+ff9bc39

@mathmanu, Hi, you could try with our new deployment toolkit mmdeploy and yolox is supported for three backends.

Hi @RunningLeon, I tried mmdeploy and the onnx export worked. However it would be nice if it works from mmdetection itself - no need for an additional dependency.

Adding the following to the class YOLOX in mmdetection/mmdet/models/detectors/yolox.py enables the onnx export. May be it's worth adding since it's a popular model.
def onnx_export(self, img, img_metas=None, **kwargs):
    img_metas = img_metas[0] if isinstance(img_metas, (list,tuple)) else img_metas
    assert isinstance(img_metas, dict)
    assert isinstance(img, torch.Tensor)

    is_dynamic_flag = False
    # get origin input shape as tensor to support onnx dynamic shape
    img_shape = torch._shape_as_tensor(img)[2:]
    if not is_dynamic_flag:
        img_shape = [int(val) for val in img_shape]
    img_metas['img_shape'] = img_shape
    img_metas = [img_metas]
    return self.simple_test(img, img_metas, **kwargs)

def simple_test(self, img, img_metas, **kwargs):
    if torch.onnx.is_in_onnx_export():
        feat = self.extract_feat(img)
        return self.bbox_head.simple_test(feat, img_metas, **kwargs)
    else:
        return super().simple_test(img, img_metas, **kwargs)

Hello, thank you for sharing your code, but I added code under this class and still can't use torch 2onnx. Can you post your complete code?

Thank u very much

YOLOX does not use image normalization, so a minor change is needed in tools/deployment/pytorch2onnx.py in function parse_normalize_cfg() as shown below.
def parse_normalize_cfg(test_pipeline):
    transforms = None
    for pipeline in test_pipeline:
        if 'transforms' in pipeline:
            transforms = pipeline['transforms']
            break
    assert transforms is not None, 'Failed to find `transforms`'
    norm_config_li = [_ for _ in transforms if _['type'] == 'Normalize']
    assert len(norm_config_li) <= 1, '`norm_config` should only have one'
    norm_config = norm_config_li[0] if len(norm_config_li)>0 else dict(mean=0.0, std=1.0)
    return norm_config

With these two changes, onnx export of YOLOX should work.

very thank u share u code,I successfully used it to export the onnx model today. I wish you a happy Chinese New Year in advance.

@RunningLeon now that it has been verified, could you perfect it and add it to mmdetection?

@RunningLeon now that it has been verified, could you perfect it and add it to mmdetection? YOLOX is one of the best models in mmdetection interms for accuracy and embedded friendliness - so this will be quite useful.

@mathmanu Hi, as mentioned before. You could use mmdeploy.

@mathmanu， Hi, good to know. Deployment feature in mmdetection would be deprecated eventually. Strongly suggest to use mmdeploy.

@mathmanu
Hello, have you tried to use the yolox onnx model exported by your code to predict with OpenCV DNN? Let me refer to it https://github.com/hpc203/yolox-opencv-dnn This code places the exported model, but there is an error reading error: opencv (4.5.4) XXX error (- 215: assertion file) axes getIntvalue(axes.size()-1)<=dims. size in fuction 'Cv::dnn::dnn4_ v20211004:onnximporter::parseUnsqueeze

@RunningLeon 很感谢你们开发的mmdeploy 但是他在安装时一定需要git 来拉取子模块（好像是这样），但我的工作限制并不允许我这么做，您有什么好的方法帮助我安装mmdeploy吗，非常感谢！！

I have checked the accuracy from the exported yolox onnx model using onnxruntime and it was good.
But I have not used OpenCV DNN.

Maybe you can try to deploy it on OpenCV. After all, the hardware is not so advanced. I will try to solve this problem. If I solve it, I will share it with you at the first time

@RunningLeon 很感谢你们开发的mmdeploy 但是他在安装时一定需要git 来拉取子模块（好像是这样），但我的工作限制并不允许我这么做，您有什么好的方法帮助我安装mmdeploy吗，非常感谢！！

@Cursky You can refer to the doc to manually install git submodules of mmdeploy

very thank u share u code,I successfully used it to export the onnx model today. I wish you a happy Chinese New Year in advance.
Refer to the above method，I convert onnx with postprocess， but it‘s error！

python deployment/pytorch2onnx.py /data/shanshaojie/models/biandian_v3/yolox_001/yolox_s_8x8_300e_coco.py /data/shanshaojie/models/biandian_v3/yolox_001/best_bbox_mAP_epoch_289.pth --output-file /data/shanshaojie/models/biandian_v3/yolox_001/nr_merge_only_xmbhyc_yolox_s640x640_e001_e289.onnx --verify --shape 640 640
Traceback (most recent call last):
File "deployment/pytorch2onnx.py", line 346, in
skip_postprocess=args.skip_postprocess)
File "deployment/pytorch2onnx.py", line 171, in pytorch2onnx
img_list, img_metas=img_meta_list, return_loss=False)[0]
File "/home/shanshaojie/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py", line 727, in _call_impl
result = self.forward(*input, **kwargs)
File "/home/shanshaojie/project/mmdetection/mmdet/core/export/model_wrappers.py", line 57, in forward
if isinstance(scale_factor, (list, tuple, np.ndarray)):
IndexError: too many indices for array
dets dimension is error

@jiesonshan  Hello, did you modify the code according to mathmanu's method? I can export onnx model after modifying according to his method, but I can't carry out DNN reasoning. You can check it again.

@jiesonshan Hello, did you modify the code according to mathmanu's method? I can export onnx model after modifying according to his method, but I can't carry out DNN reasoning. You can check it again.

thank you，I modified the code using mathmanu's method，I convert two onnx，it is onnx with postprocess and without postprocess， onnx without postprocess‘s result is correct，but onnx with postprocess bboxes is error， scores is  consistent.

@Cursky , thank you! I modified the code according to mathmanu's method. I convert two onnx models, one with post-processing and the other without post-processing, without post-processing's result is correct. but post-processing's bboxes is error, post-processing's scores is correct.

I added these two paragraphs as mentioned above, but I still got the same error.
@mathmanu @Cursky
python tools/deployment/pytorch2onnx.py configs/yolox/yolox_s_8x8_300e_coco.py work_dirs/yolox_s_8x8_300e_coco/epoch_30.pth --output-file work_dirs/yolox_s_8x8_300e_coco/yolox_s.onnx --input-img demo/demo.jpg --verify --simplify --dynamic-export --shape 640 640
File "/home/jiangxiaowei/anaconda3/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1130, in getattr
raise AttributeError("'{}' object has no attribute '{}'".format(
AttributeError: 'YOLOXHead' object has no attribute 'bbox_coder'

@VJoer i'm having the same issue.

@VJoer i'm having the same issue.
Maybe you could try this

As MMDeploy already supports YOLOX https://github.com/open-mmlab/mmdeploy. MMDet will no longer maintain the feature of YOLOX ONNX export. Please use MMDeploy and create an issue if you still have questions about that.

@mathmanu @Cursky Refer to the above method，I convert onnx with postprocess， but it‘s error！
python deployment/pytorch2onnx.py /data/shanshaojie/models/biandian_v3/yolox_001/yolox_s_8x8_300e_coco.py /data/shanshaojie/models/biandian_v3/yolox_001/best_bbox_mAP_epoch_289.pth --output-file /data/shanshaojie/models/biandian_v3/yolox_001/nr_merge_only_xmbhyc_yolox_s640x640_e001_e289.onnx --verify --shape 640 640
Traceback (most recent call last): File "deployment/pytorch2onnx.py", line 346, in skip_postprocess=args.skip_postprocess) File "deployment/pytorch2onnx.py", line 171, in pytorch2onnx img_list, img_metas=img_meta_list, return_loss=False)[0] File "/home/shanshaojie/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py", line 727, in _call_impl result = self.forward(*input, **kwargs) File "/home/shanshaojie/project/mmdetection/mmdet/core/export/model_wrappers.py", line 57, in forward if isinstance(scale_factor, (list, tuple, np.ndarray)): IndexError: too many indices for array
dets dimension is error， How can I do it? Thank you

how to do solve it ?
@jiesonshan

YOLOX does not use image normalization, so another minor change is needed in tools/deployment/pytorch2onnx.py in function parse_normalize_cfg() as shown below.
def parse_normalize_cfg(test_pipeline):
    transforms = None
    for pipeline in test_pipeline:
        if 'transforms' in pipeline:
            transforms = pipeline['transforms']
            break
    assert transforms is not None, 'Failed to find `transforms`'
    norm_config_li = [_ for _ in transforms if _['type'] == 'Normalize']
    assert len(norm_config_li) <= 1, '`norm_config` should only have one'
    norm_config = norm_config_li[0] if len(norm_config_li)>0 else dict(mean=0.0, std=1.0)
    return norm_config

With these two changes, onnx export of YOLOX should work.

I doubt that the dict(mean=0.0, std=1.0) lacks one additional arg to_rgb=False. Without this arg, mmdet will perform cv2.BGR2RGB operation.


fix: 避免zstack参数含有中文,未编码导致请求失败

这个 PR 实现什么功能/修复什么问题:
避免zstack参数含有中文,未编码导致请求失败
是否需要 backport 到之前的 release 分支:

release/2.10.0

/area region
/cc @swordqiu @yousong

Codecov Report

Merging #4097 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #4097   +/-   ##
======================================
  Coverage    6.89%   6.89%
======================================
  Files         507     507
  Lines       85490   85490
======================================
  Hits         5894    5894
  Misses      79096   79096
  Partials      500     500

Flag
Coverage Δ

#aFlag
6.89% <ø> (ø)
:arrow_up:

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 04f9cca...04e7f12. Read the comment docs.

/lgtm

/lgtm

/approve


Fix mobile files

@thebearjew thanks for finding this :)

Merging without Circle since this fixes a break.


Create CrdtEntityDescriptor, FieldValueInterpreter, etc.

These classes will be used by CrdtEntity (still a stub) to support entity definitions.
A rough sketch for how to use the field value interpreters with CrdtEntity is in the kdoc for it. Be warned: the sketch is very rough.

Overall comment, for serialization/deserialization, shouldn't we be taking a look at kotlinx.serialization?
It uses plain-ole data classes with an annotation processor, and generates Visitor pattern objects behind the scenes that don't need reflection and which can be wired up to any wire-format you desire: json, proto, asn1, etc. it decouples the wireformat.

I do plan to incorporate kotlinx.serialization, but for primitives in entity fields I thought it more straightforward to directly manage their serialization themselves. But the reasoning behind using data class everywhere is exactly so we can incorporate kotlinx.serialization easily for more involved structures. E.g. FieldValue will likely be serialized using it.


[KYUUBI #6583] PySpark support operation cancel

:mag: Description
Issue References 🔗

This pull request fixes #6583
Background and Goals
Currently, kyuubi cannot perform operation level interrupts when executing Python code. When it is necessary to cancel an operation that has been running for a long time, the entire session needs to be interrupted, and the execution context will be lost, which is very unfriendly to users. Therefore, it is necessary to support operation level interrupts so that the execution context is not lost when the user terminal operates.
Describe Your Solution 🔧
Refer to the implementation of Jupyter Notebook and let the Python process listen to Signel SIGINT semaphore, when receiving a signel When SIGINT, interrupt the current executing code and capture KeyboardInterrupt to treat it as cancelled
Types of changes :bookmark:

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Test Plan 🧪
Behavior Without This Pull Request :coffin:
Behavior With This Pull Request :tada:
Related Unit Tests

Checklist 📝

[x] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

Codecov Report
Attention: Patch coverage is 0% with 12 lines in your changes missing coverage. Please review.

Project coverage is 0.00%. Comparing base (aaef76c) to head (c2b63f9).
Report is 11 commits behind head on master.

Files
Patch %
Lines

.../kyuubi/engine/spark/operation/ExecutePython.scala
0.00%
12 Missing :warning:

Additional details and impacted files
@@          Coverage Diff           @@
##           master   #6612   +/-   ##
======================================
  Coverage    0.00%   0.00%
======================================
  Files         677     677
  Lines       41902   41919   +17
  Branches     5721    5722    +1
======================================
- Misses      41902   41919   +17

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

@pan3793 @iodone Can you help review this PR？

thanks for raising this PR, could you add UT?
@yoock

thanks for raising this PR, could you add UT?
@yoock

This UT relies on the Python environment, which is quite difficult, and I noticed that the previous Python PR did not have a corresponding UT
@turboFei

Please check https://github.com/apache/kyuubi/blob/master/kyuubi-server/src/test/scala/org/apache/kyuubi/engine/spark/PySparkTests.scala @yoock

UT added @turboFei

Seems the UT not pass:
https://github.com/apache/kyuubi/actions/runs/10454051665/job/28948676893?pr=6612

the UT does not pass in my local env.
also cc @pan3793  and @cfmcgrady @iodone to review.

thanks, merged to 1.10.0 and 1.9.3

Oh, credit to @yoock, I did not notice the author field when merging PR with script.


Sample Project-'JSONNSDataExtension.swift' File error 'Use of undeclared type 'Data''

Just download from github,open CognitiveServices.xcodeproj file with Xcode 7.3.1 ,JSONNSDataExtension.swift  File error 'Use of undeclared type 'Data'':extension Data {

It seems because the version of Swift i used(2.2) ,i have rewrite with Swift 2.2 ,now it can run...

Yes, it's written for Swift 3.0

Everything prior this commit should run fine in previous versions of Swift and Xcode:
https://github.com/DanilaVladi/Microsoft-Cognitive-Services-Swift-SDK/tree/84a7723ead047d7bf246309193dfd20436fe05a1

Thanks


Change name of plugin

to "Login by Auth0"
and description to use the word "Login" as the first word to test if this is how WP plugin discovery works or not.

A new plugin was submitted (pending review) to test name changing.

ready for next release.


Update user signup

Refactor user sign up to hooks
Redirects user to thank you screen after signup

Might be good to add a hook to expose user data in the future. Something like this: https://github.com/CollActionteam/CollAction/blob/master/Frontend/src/providers/UserProvider.tsx
Other components could use that to get access to the userdata.


Logic testcases

Improve quality and comprehensiveness of test cases, focused on the Logic components.

Should be complete enough to merge now. Note that there were some modifications to non-test files in the the most recent commit (446c8b9). ParserUtil was modified because certain checks for appropriateness were not trimming the input as you would expect. We consider this a bug and hence can be changed during the feature freeze.

Should be complete enough to merge now. Note that there were some modifications to non-test files in the the most recent commit (446c8b9). ParserUtil was modified because certain checks for appropriateness were not trimming the input as you would expect. We consider this a bug and hence can be changed during the feature freeze.

Note: after tracing code, we have determined that the input is trimmed by ArgumentTokenizer before it is passed to ParserUtil in practice; so there is no external change in features. However we still keep the change, since it is a case of improving the defensiveness of code.


Added WebAssembly

This resolves #1942
Checklist before opening this PR (put x in the checkboxes)

[x] This PR does not contain plagiarism

don’t copy other people’s work unless you are quoting and contributing it to them.

[x] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

Is it fine? @iamNoah1

@CathPag @caniszczyk @JasonMorgan @iamNoah1 @jihoon-seo @seokho-son

Thanks for your contribution, @arunkarthicknm. We are currently working our way through our backlog. This is on our to-do list, but there are a few terms that need to be reviewed before yours. Thanks for your patience!

Sure @CathPag

Hi @arunkarthicknm, it's been a couple of weeks since we've seen any activity on this PR, and I wanted to check-in. Please don't hesitate to ask if you have any questions or need further clarification on any of the points I've raised. We're here to help.

Agreed with @nate-double-u  on the suggested changes.  If no objections I'll noodle on some recommended wording for the content.

No objections, please noodle 🙂

What is the status here? @nate-double-u

@hlipsig, you were working on a review, but had some issues around how best to provide the feedback. Did we land on a best practice?

@nate-double-u @hlipsig my suggestion would be to add suggestions via the suggestion feature so that they can easily be added (committed) through the web ui. And also as the author is not responsive anymore we should just go on and make the suggested changes ourselves. What you think @nate-double-u, wanna take over? Or @arunkarthicknm wants to follow up?

I'm happy to take it over. @hlipsig, I'm also happy to work with you to get your suggestions in, I'd hate for you to have done work that didn't get considered 🙂


TNT-46700 Add proxy configuration

Description
Adding a new option to the SDK config: proxyAgent: ProxyAgent
This ProxyAgent from the undici library, which now contains the default node fetch implementation starting with node 18.2, allows SDK users to configure a Proxy for the SDK fetch calls. The user implementation of this will vary due to the change in the default node implementation. For node 16.8+ users, the proxy agent is passed into the options argument as a dispatcher during fetch calls. This functionality will not work out of the box for versions of node older than 16.8, as undici fetch does not support node versions older than that. I will outline implementation options for specific versions in the testing section.
Related Issue

Ticket: TNT-46700
Motivation and Context

How Has This Been Tested?
I manually tested this by setting up a local proxy, instantiating a TargetClient with different Node versions, and checking if a connection to the proxy was made during getOffers calls. Here is how I was able to do that with different node versions:

for node versions >= 18.2, this works by just specifying the proxyAgent in the TargetClient options
for node versions between 16.8 and 18.1, this works by overriding the fetchApi with undici.fetch in addition to specifying the proxyAgent. That is because undici.fetch is not the default fetch for node for these versions.
for node versions less than 16.8 and greater than 14 I was not able to connect to the proxy. This is due to a bug in Node 16 with node-fetch and http-proxy-agent. If we go with the approach in this PR, I will do further research on how to get a proxy to work for these versions and document the solution.
for node 14, the proxy works with node-fetch and http-proxy-agent by passing in a custom fetchApi to the TargetClient options.

The setup for each of these can be found in packages/target-nodejs-sdk/demo/proxy-test/proxy_demo.js.
Due to the difference in implementation of fetch between different node versions, unit testing this would require a lot of creativity or discontinuing support for Node 14.
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Coverage: ?%. Remained the same when pulling 4f4d13c0ed8bfe2d89a9f350d46f3a7529ed1ecb on ericfichtel:TNT-46700 into a6e4f77471a3dfa55c18c91c6fb759bcb1cb638a on adobe:main.

Coverage: 92.388% (-0.1%) from 92.502% when pulling 4f4d13c0ed8bfe2d89a9f350d46f3a7529ed1ecb on ericfichtel:TNT-46700 into a6e4f77471a3dfa55c18c91c6fb759bcb1cb638a on adobe:main.

@jasonwaters The idea is to make it simple for customers to configure a proxy, similarly to what we already have in the Java SDK with a simple configuration, instead of requiring fetchApi to be overriden, which is not that straightforward.
Undici is the unerlying fetch implementation starting with Node v18.2, however the ProxyAgent was not included in Node, and thus has to be pulled in from the standalone undici module.
Judging from this comment however, they have decided to support proxy via env vars directly in Node, but this was just 3 weeks ago, so it will take at least several months till it's released and supported in a future Node release. Considering this, maybe it does make sense to just provide a workaround with fetchApi override in a separate documentation section, rather then actually implementing ProxyAgent support, since the proper way of setting a proxy will change once again in an upcoming Node version..
Let's discuss with the team on Monday, meanwhile maybe Eric could test out the workaround with fetchApi override with ProxyAgent and add it to the demo app.. wdyt @jasonwaters @ericfichtel ?

@jasonwaters @ericfichtel In case we decide to support ProxyAgent, we can list undici as an optional peer dependency, which only customers that need to set a proxy would need to add to their projects, so the main Node SDK doesn't need to depend on it.

Yes I think we should simply document how to do this by passing in a fetch implementation with a proxy configured.
We added proxy functionality to Java SDK because it was not possible to pull off in another way. But I think it better to be less prescriptive in JavaScript and simply expect a fetch implementation to be passed in -- configured with or without a proxy. Maximum freedom for users.

looks good @ericfichtel !


Sudo required - refinements

Inclusion of sudo for completeness

:+1:

@gilleyj great! Can you update package.json with dependency and version bump?

I made min0rz change to addres https://github.com/till/nukify/issues/2

The sudo requirement should be replaced with a buff3r 0v3rrun expl0itz

:+1: :cupid:

Merged/rebase locally.


zopfli: 1.0.1 -> 1.0.2

Zopfli 1.0.2 was released last May. It includes patches that were manually added to the Nix derivation. These are not needed anymore.
This was build with useSandbox and could ran on NixOS.

@GrahamcOfBorg build zopfli

Success on x86_64-linux (full log)
Attempted: zopfli
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2
shrinking /nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2/bin/zopflipng
shrinking /nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2/bin/zopfli
shrinking /nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2/lib/libzopfli.so.1.0.1
shrinking /nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2/lib/libzopflipng.so.1.0.0
strip is /nix/store/1hi76hr87bd1y1q1qjk0lv8nmcjip1c8-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2/lib  /nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2/bin
patching script interpreter paths in /nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2
checking for references to /build in /nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2...
/nix/store/vw03kjxdg5sn34f1q1hfy2gs62iyzk92-zopfli-1.0.2

Success on x86_64-darwin (full log)
Attempted: zopfli
Partial log (click to expand)
Scanning dependencies of target zopfli
[ 95%] Building C object CMakeFiles/zopfli.dir/src/zopfli/zopfli_bin.c.o
[100%] Linking C executable zopfli
[100%] Built target zopfli
installing
post-installation fixup
strip is /nix/store/qfxcr8c4fg7lkybrny9n2sb77bmippdx-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/vypq57q8nhg7nn62d9jhj5ybylpbfqpa-zopfli-1.0.2/lib  /nix/store/vypq57q8nhg7nn62d9jhj5ybylpbfqpa-zopfli-1.0.2/bin
patching script interpreter paths in /nix/store/vypq57q8nhg7nn62d9jhj5ybylpbfqpa-zopfli-1.0.2
/nix/store/vypq57q8nhg7nn62d9jhj5ybylpbfqpa-zopfli-1.0.2

Success on aarch64-linux (full log)
Attempted: zopfli
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2
shrinking /nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2/lib/libzopflipng.so.1.0.0
shrinking /nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2/lib/libzopfli.so.1.0.1
shrinking /nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2/bin/zopflipng
shrinking /nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2/bin/zopfli
strip is /nix/store/zrs21zqcchgyabjf4xfimncdq16njizc-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2/lib  /nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2/bin
patching script interpreter paths in /nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2
checking for references to /build in /nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2...
/nix/store/4iziyvmvhcwnd3yr5vcy8b88d1nvdipr-zopfli-1.0.2

:tada:


Optimise expanding areas

Use containment. Push stuff onto the GPU.

This is a nice-to-have for V1. Performance isn't too bad.


Create Doc Corrections

The Docs are located outside GitHub but as I was requested to submit a pull request I've done it here

The docs are in this repo, look in the views directory


GIF File Support in Chat ?

New issue checklist

[x] I have read all of the README, documentation, and FAQ.
[x] I have reviewed the contributing guidelines. Confirmation: ____
[x] I have searched existing issues and this is not a duplicate.

General information

Library version(s):
iOS version(s):
Devices/Simulators affected:
Reproducible in the demo project? (Yes/No):
Related issues:

Bug report
Expected behavior
Actual behavior
Steps to reproduce
Crash log? Screenshots? Videos? Sample project?

Does JSQMessagesViewController, supports sending and receiving GIF files ? Does it show animated GIF in Chat view?

Thanks for submitting an issue. Let's track it together on #1853. 😃

Thanks @ThillaiganeshChan !
We'll track this feature request at #1869


Improve wording of protobuf warning in Makefile

This fixes #4110.

LGTM.

I think this is green enough to merge now


Update zr_input_output_power_test.

Update OPR value when interface is in down state to -40dBm
Update OPT range to -6 to -10 dbm

Pull Request Functional Test Report for #2776 / 0fc9ff391f72056b003bbb717d8e3de13d8653fe
No tests identified for validation.
Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 53.035%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1730

Relevant Lines:
3262

💛  - Coveralls


Build fixes

I had to make these changes to build with cmake 3.8.2 and gcc 7.1.1
The CMakeLists change is a reverting of a previous change. I'm not sure why the change was made but it failed for my version of cmake. I believe EQUAL is the wrong comparator for strings. It should be STREQUAL.
I suppose the header shadowing issue could be fixed by fiddling with include ordering, but this works for me.

@stelleg Does this need to go into the deppart branch or can this go in the master branch?

@lightsighter deppart, I'm not having these issues in master or stable

@stelleg Even if it's not strictly needed in master, I'd prefer if it went there.  Can you try it out on the master branch and make sure it works ok?  Thanks.

@streichler it wouldn't do anything on master. One file changed only exists in deppart and the other file already is fixed.
Should we not be opening issues/PR's for deppart?

Note to self: Drink coffee, then try to think.  :)
Yeah, the interval_tree thing definitely should be fixed in deppart, but we haven't (intentionally) made any cmake changes in deppart, so I'm surprised there's a difference there and will go hunting for its source.
More generally, issues/PRs for deppart are welcome, but given that it won't fold into master for a few more weeks at least (and not into stable for a few months), anything that can be fixed upstream in master (or in some cases the dma branch) should be.

Sorry for the delay on this, but I was able to determine that the cmake issue was just because we were about a week behind on the master->dma->deppart merges.  I pulled the corresponding master changes through and I believe that removes the need for any cmake-changes specific to deppart.
For the realm header file change, I just cherry-picked it from your branch.  :)
So @stelleg , I believe this request can be closed, but I want to let you weigh in first.

@streichler sounds good to me


Some steps are missing in the documentation to executue kafka sample

Description:
When executing the sample in this doc https://docs.wso2.com/display/SP400/Sample+0001%3A+Receiving+and+Publishing+Events+via+Kafka+Transport  , some steps are missing.
Suggested Labels:
We need to start zookeeper node using bin/zookeeper-server-start.sh config/zookeeper.properties and kafka server node using bin/kafka-server-start.sh config/server.properties before start a worker node. It should be mentioned in the documentation.

Updated the docs with kafka info https://docs.wso2.com/display/SP400/Sample+0001%3A+Receiving+and+Publishing+Events+via+Kafka+Transport


Add browser and module field support to package.json processing

This PR fixes #2433 by introducing a new option, packageJsonEntryNames, which allows specifying a list of ordered entries which the compiler should look for when resolving Node modules. The default is the single entry "main".
When compiling for the web, however, we would pass in a list of "browser", "main" which tells the compiler to look for a "browser" entry before checking the "main" entry.
This also allows people who want to consume packages that instead rely on es2015:main or esnext:main to include those too in the order of precedence they prefer.

I signed it!

The PR itself looks good - a flag can be added later for CLI usage.
@anmonteiro Do you have any idea how prevalent the browser field advanced usage form is? https://github.com/defunctzombie/package-browser-field-spec#replace-specific-files---advanced
That's been my largest hangup on this to date.

Interesting. I didn't know about the advanced usage of the browser field.
I have no idea how prevalent it is, but my intuition would be to solve that as needed.
This PR introduces basic support for it,  and we can build on it later.

@dimvar LGTM. We'll continue to iterate on this in future PRs.

OK, I'll import and submit the PR internally.


Сategory cards improvements

Yes, infinite loop in the background, but we have no choice. DevTools profiler says it has almost no performance impact

DevTools profiler says it has almost no performance impact

infinite loop in the background

Maybe later I'll implement this using events, but not for now

will reopen when rewrite using MutationObserver

will reopen when rewrite using MutationObserver

Roger that

@SunsetTechuila Don't get mad about me please. I still haven't had time to open up my laptop

Don't get mad about me please

Np, we all work for free here, so we have no obligations to anyone

Don't get mad about me please

Np, we all work for free here, so we have no obligations to anyone

but we all have that aim to help someone who chose to trust us.
that's how we can make this society better.


feat: support passing mutiple files in a single flag

This is useful when the target files need to pass as parameters. Such as:
apiVersion: argoproj.io/v1alpha1
kind: ClusterWorkflowTemplate
metadata:
  name: library-validation
spec:
  templates:
  - name: kubeconform
    inputs:
      parameters:
        - name: target
          default: "."
    container:
      args:
        - "{{inputs.parameters.target}}"
      command:
        - /kubeconform
      image: ghcr.io/yannh/kubeconform:master

With this PR, users could pass multiple files like this:
        - name: yaml-check
          depends: clone
          templateRef:
            name: library-validation
            template: kubeconform
            clusterScope: true
          arguments:
            parameters:
              - name: target
                value: "config/manager,config/rbac"

Not sure I am following, isn't this supported like this?
$ kubeconform -summary fixtures/valid.yaml
Summary: 1 resource found in 1 file - Valid: 1, Invalid: 0, Errors: 0, Skipped: 0
$ kubeconform -summary fixtures/valid_version.yaml
Summary: 1 resource found in 1 file - Valid: 1, Invalid: 0, Errors: 0, Skipped: 0
$ kubeconform -summary fixtures/valid.yaml fixtures/valid_version.yaml
Summary: 2 resources found in 2 files - Valid: 2, Invalid: 0, Errors: 0, Skipped: 0

This feature supports the following command:
kubeconform -summary fixtures/valid.yaml,fixtures/valid_version.yaml

The point is that we could pass multiple files in a single string. This is friendly when we use it in a Kubernetes YAML file.

I think I understand the need, but it seems to be more due to a limitation in the tooling you use to call Kubeconform... There is already a way to have kubeconform validate multiple files, and I'm not too keen on adding a different way to accommodate restriction in a third-party tool... sorry, but thanks for the contribution :bow:


Remove redundant constraints take 2

Fixes #705
Reviewer checklist

[ ] Test coverage: stack test --coverage
[ ] Public API documentation: stack haddock
[ ] Style conformance: stylish-haskell

It might be worth it to move the code I added in Step.Step to a different module, but I would like a review now that focuses on the changes to the tests.

@ttuegel Yep, you are exactly right. I somehow convinced myself that those were right, but they were obviously not. The problem was that I tried to be cute with Function.& and accidentally reversed the implication of the predicate, thus making it Pre → ⌈L ∧ φ⌉ ∧ P which turns out to be true pretty often.
Additionally, @virgil-serbanuta was correct: we only have the Just False case for Unsat, so I needed to negate the predicate anyway.
I rebased/force push-ed the new version which looks a lot better now, I think (no change needed to other tests, added a test that is failing on master but working here; can you think of other tests I should add?).
@virgil-serbanuta also had an interesting idea I am inclined to take on: what if we change evaluate (this tricked me since it returns Maybe Bool but it only really returns Nothing or Just False) to be more precise? For example, we could add some argument that specifies whether we want to prove something's always true or always false and it would negate the predicate itself if needed...?


Framework not found FirebaseFirestoreInternal

Description
Framework not found FirebaseFirestoreInternal
Linker command failed with exit code 1 (use -v to see invocation)
Reproducing the issue
No response
Firebase SDK Version
10.24.0
Xcode Version
15.2
Installation Method
CocoaPods
Firebase Product(s)
Firestore
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

  - FirebaseFirestore (10.24.0):
    - FirebaseCore (~> 10.0)
    - FirebaseCoreExtension (~> 10.0)
    - FirebaseFirestoreInternal (= 10.24.0)
    - FirebaseSharedSwift (~> 10.0)
  - FirebaseFirestoreInternal (10.24.0):
    - abseil/algorithm (~> 1.20240116.1)
    - abseil/base (~> 1.20240116.1)
    - abseil/container/flat_hash_map (~> 1.20240116.1)
    - abseil/memory (~> 1.20240116.1)
    - abseil/meta (~> 1.20240116.1)
    - abseil/strings/strings (~> 1.20240116.1)
    - abseil/time (~> 1.20240116.1)
    - abseil/types (~> 1.20240116.1)
    - FirebaseAppCheckInterop (~> 10.17)
    - FirebaseCore (~> 10.0)
    - "gRPC-C++ (~> 1.62.0)"
    - gRPC-Core (~> 1.62.0)
    - leveldb-library (~> 1.22)
    - nanopb (< 2.30911.0, >= 2.30908.0)

Hi @huangzishan37, have you tried to clean build your project and restart Xcode? Also, may I know if you're using use_frameworks in your Podfile?

Hi @huangzishan37 ,
Could you please share your pod file?

Hi @huangzishan37, have you tried to clean build your project and restart Xcode? Also, may I know if you're using use_frameworks in your Podfile?

I have tried to clean build my project, and also restart Xcode, but it still failed. I'm not using 'use_frameworks' in my Podfile

Hi @huangzishan37 ,
Could you please share your pod file?

platform :ios, '13.0'
use_modular_headers!

inhibit_all_warnings!

target 'XXX' do

  pod 'Firebase', '~> 10.24.0'
  pod 'FirebaseCore', '~> 10.24.0'
  pod 'FirebaseMessaging', '~> 10.24.0'
  pod 'FirebaseAnalytics', '~> 10.24.0'
  pod 'FirebasePerformance', '~> 10.24.0'
  pod 'FirebaseCrashlytics', '~> 10.24.0'
  pod 'FirebaseRemoteConfig', '~> 10.24.0'
  pod 'FirebaseFirestore', '~> 10.24.0'

end

Fixed that via pod 'FirebaseFirestoreBinary', '~> 10.24.0'
is this correct?

Since Firebase 9.0, use_frameworks! or use_frameworks! :linkage => :static has been required in Podfiles.
Using  'FirebaseFirestoreBinary', '~> 10.24.0' may be a workaround for now, but is not guaranteed to continue to work in future releases.

use_frameworks! :linkage => :static

Can I specify a separate library with use_frameworks! :linkage => :static?, rather than setting it globally?"

Hi @huangzishan37, use_frameworks! can be set at either the root of the Podfile or per target. It cannot be set per dependency.
platform :ios, '13.0'

use_frameworks! # set globally for all targets in podfile

inhibit_all_warnings!

target 'XXX' do

  use_frameworks! # set just within a target

  pod 'Foo'

end


content is not render by using markdown

I installed this plugin, but found that the generated category page do not render the post content correctly.
my post file is a markdown, is there any idea how to enable this function?

+1 for markdownify
thank you


fix getMe() exception

Currently executing getMe request returns an exception (it tries to use message object for the returned data).

Thanks!


Update download location

Update README to the new download location: https://cloud.redhat.com/openshift/create/local

Already captured in: #1982


Loading Downloaded zip data into Python Notebooks

I've downloaded zip files of CFD hourly data from OANDA via the Quantconnect site and placed them in the Data/cfd directory of the Lean repo. My directory structure looks like this:
├── cfd
│       ├── daily
│       │   └── xauusd.zip
│       ├── hour
│       │   ├── spx500usd.zip
│       │   ├── us2000usd.zip
│       │   ├── us30usd.zip
│       │   └── xauusd.zip

I tried to load the data in my notebook via
spx500 = qb.AddCfd("SPX500USD")
us30 = qb.AddCfd("US30USD")
us2000 = qb.AddCfd("US2000USD")
xauusd = qb.AddCfd("XAUUSD")

And to get a Dataframe of values
# Gets historical data from the subscribed assets, the last 360 datapoints with daily resolution
h1 = qb.History([xauusd.Symbol], datetime(2014,1,1), datetime.now(), Resolution.Daily) #Daily)
# Plot closing prices from "SPY"
h1.index

And as a result I got nothing:
Index([], dtype='object')

What am I doing wrong?

Please define the Market:
xau = qb.AddCfd("XAUUSD", Resolution.Minute, Market.Oanda)

The default market for CFD is Market.FXCM, so Lean looks for CFD data in Lean/Data/cdf/fxcm instead of Lean/Data/cdf/oanda.


Leaderboards w/ Github pages

Can navigate to something like index.html or a specific leaderboard after turning the feature on in the repo Settings and setting the directory to /docs.
To update the html files to get the most recent leaderboards: python3 create_leaderboards.py

Terrific. I added game count and flag.


Update and make public proto files for the identity API

Created by: @bayegan Oct 27 2021 at 20:11 CET
Last updated: Jul 19 2022 at 10:54 CET
ClickUp ID: IK-1700
Use the Buf Schema Registry (BSR) to update and make pubic IndyKite's proto files for the
identity API:
Background
Buf's long-term goal is to enable Schema-Driven Development: a future where APIs are defined consistently, in a way that service owners and clients can depend on.
Defining APIs using an IDL provides a number of benefits over simply exposing JSON/REST services, and today, Protobuf is the most stable, widely-adopted IDL in the industry. However, as it stands, using Protobuf is much more difficult than using JSON as your data transfer format.
Buf is building tooling to make Protobuf reliable and easy to use for service owners and clients, while keeping it the obvious choice on the technical merits. Your organization should not have to reinvent the wheel to create, maintain, and consume Protobuf APIs efficiently and effectively. We'll handle your Protobuf management strategy for you, so you can focus on what matters.
Acceptance criteria:
Before GO SDK can be made public, go through IndyKite's proto files:
Ensure public readiness in terms of:
BSR compliance
Consistency
Documentation
Code convention
Cleanup
Error handling
Obsolete code
Mark as experimental
Use https://buf.build/ to generate and check code
Follow the guideline to writing doc with examples.
https://blog.golang.org/godoc
https://developpaper.com/how-to-write-a-godoc-go-document-on-a-large-scale/
Publish proto messages on buf.build registry (
Ensure auto-generate proto files
Detect breaking changes
For more information, listen to the last 5 minutes of this recording:

Commented by: @bayegan Feb 16 2022 at 21:52 CET
@andskaal : @marvinkite might have done a good chunk of this task already


Driver.Context is returning Null exception using Appium 1.6.4 and 1.6.3.

Could you please help me out in finding out how to get the context.

Is there is any solution how to switching context for windows using appium 1.6.4 .When tries to get context it throws an exception.I need to test hybrid app using windows automation with appium

Unfortunately we don't support context switching with the Edge webdriver.  It's an active conversation we're having with them but no timetable we can share at this point.


ESP32-P4 USB TUSB DEVICE (IDFGH-14285)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
I have tried to get the examples from https://github.com/espressif/esp-idf/tree/v5.3.2/examples/peripherals/usb/device running on the ESP32-P4. None seem to work. I have used USB DP pin 50 and DM pin 49 and connected them to a laptop USB HOST. Are these pins correct?
Is TUSB using the right peripheral? I am bit confused how many and what type of peripherals the P4 has. It seems there are also GPIO24+25 pins 52+53 and GPIO26+27 pins 55+56 some sort of USB related.
These docs are probably wrong https://github.com/espressif/esp-idf/blob/master/examples/peripherals/usb/README.md
They refer to DP pin 51 DM 50. Pin 51 is vcca from the datasheet and not DP!
Tried the examples with release 5.3.1 and master branch, no success.
I am using this board ESP32-P4-NANO.
Thanks for any advice.

Figured it out, is was a wrong power configuration on the USB header.


When using multiple before templates, do not require the type present in a single before template to be present for all matches

As seen on:

https://github.com/openrewrite/rewrite-testing-frameworks/pull/520

The AssertEqualWithMessage rule from Picnic's EPS contains a number of different before templates, each with different argument types.

https://github.com/PicnicSupermarket/error-prone-support/blob/75a9786f8ff6fc4b514610e3d2447551002f2e40/error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/TestNGToAssertJRules.java#L417-L478

The now generated preconditions with 1.19.1 require the type from just one of those before templates to be present for all before a match.
            return Preconditions.check(
                    Preconditions.and(
                        new UsesType<>("java.util.Map", true),
                        new UsesMethod<>("org.testng.Assert assertEquals(..)", true)
                    ),
                    javaVisitor
            );

Ideally we adjust the preconditions such that the UsesType Map is either optional, or fully absent, unless that's present on all before templates.

Interesting! I wasn't aware of this possibility. I think we should then indeed skip the UsesType unless all before templates have it. Is that the only thing that needs to be changed to make these Refaster recipes wirk?

I haven't explored this yet, but I think that's the only change indeed. Note that the input template here as a mix of primitives and classes; any adjustments would need to account for that, but I think it ought to be straightforward. I've asked the team to have a look.


[Bug] [dao] Project entity shouldn't use != in equals function

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
Project.java entity use != instead of equals to compare id, whose type is Integer, which may cause a problem when id is not in the range of -128 ~ 127:
    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (o == null || getClass() != o.getClass()) {
            return false;
        }

        Project project = (Project) o;

        if (id != project.id) {
            return false;
        }
        return name.equals(project.name);

    }

JVM only caches the Integer object between -128 and 127, and will create a new object for other numbers:
jshell> Integer a = 127
a ==> 127

jshell> Integer b = 127
b ==> 127

jshell> a == b
$3 ==> true

jshell> Integer b = 128
b ==> 128

jshell> Integer a = 128
a ==> 128

jshell> a == b
$6 ==> false

What you expected to happen
When id is not in the range of -128 ~ 127, the comparation of projects can get a correct result.
How to reproduce
Create two Project entity p1 and p2 with the same name, set the id to the new Integer(128), and call the p1.equals(p2), which will get the false.
Anything else
No response
Version
dev
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

due to we have @Data annotation in class Project and it have build-in ``, I think we can directly remove method equals and hashCode, WDYT?

due to we have @Data annotation in class Project
https://github.com/apache/dolphinscheduler/blob/efedc9a53ca0704d366d1c88254bf93b4f717963/dolphinscheduler-dao/src/main/java/org/apache/dolphinscheduler/dao/entity/Project.java#L32
and it have build-in equals and hashCode, I think we can directly remove method equals and hashCode, WDYT?

The original logic only compares with id and name. If we remove the equals and hashCode functions and rely on the function generated by the @Data annotation, I’m not sure whether this way will cause some problems elsewhere.

could you see where use the pojo and test whether we can directly remove the custom equals? IMO I think we can remove it, but need double-check about it

Okay, I will investigate where the pojo is being used. If it's acceptable to remove the original logic, I will delete it.

Okay, I will investigate where the pojo is being used. If it's acceptable to remove the original logic, I will delete it.

cool


Support split stderr/stdout when running shell commands

For Swift support, we'll be using swift package show-dependencies --format json to parse dependencies.
However, this command sometimes prints certain warnings, making the JSON output unparseable.
This PR exposes an option to SharedHelpers.run_shell_command to be able to split stdout and stderr, so that the command's output is always parseable.

This is an example
warning: 'csqlite': ignoring declared target(s) 'CSQLite' in the system package
warning: 'swiftgen': 'swiftgen' dependency on 'https://github.com/kylef/Stencil.git' conflicts with dependency on 'https://github.com/stencilproject/Stencil.git' which has the same identity 'stencil'. this will be escalated to an error in future versions of SwiftPM.
{
  "identity": "tuist",
  "name": "tuist",
  "url": "/home/dependabot/dependabot-core/tmp/tuist/tuist",
  "version": "unspecified",
  "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist",
  "dependencies": [
    {
      "identity": "apollo-ios",
      "name": "Apollo",
      "url": "https://github.com/apollographql/apollo-ios.git",
      "version": "1.0.5",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/apollo-ios",
      "dependencies": [
        {
          "identity": "sqlite.swift",
          "name": "SQLite.swift",
          "url": "https://github.com/stephencelis/SQLite.swift.git",
          "version": "0.13.3",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/SQLite.swift",
          "dependencies": [
            {
              "identity": "csqlite",
              "name": "CSQLite",
              "url": "https://github.com/stephencelis/CSQLite.git",
              "version": "0.0.3",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/CSQLite",
              "dependencies": [

              ]
            }
          ]
        },
        {
          "identity": "inflectorkit",
          "name": "InflectorKit",
          "url": "https://github.com/mattt/InflectorKit",
          "version": "1.0.0",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/InflectorKit",
          "dependencies": [

          ]
        },
        {
          "identity": "swift-collections",
          "name": "swift-collections",
          "url": "https://github.com/apple/swift-collections",
          "version": "1.0.4",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/swift-collections",
          "dependencies": [

          ]
        },
        {
          "identity": "swift-argument-parser",
          "name": "swift-argument-parser",
          "url": "https://github.com/apple/swift-argument-parser.git",
          "version": "1.2.2",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/swift-argument-parser",
          "dependencies": [

          ]
        }
      ]
    },
    {
      "identity": "swift-argument-parser",
      "name": "swift-argument-parser",
      "url": "https://github.com/apple/swift-argument-parser.git",
      "version": "1.2.2",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/swift-argument-parser",
      "dependencies": [

      ]
    },
    {
      "identity": "swift-docc-plugin",
      "name": "SwiftDocCPlugin",
      "url": "https://github.com/apple/swift-docc-plugin.git",
      "version": "1.1.0",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/swift-docc-plugin",
      "dependencies": [
        {
          "identity": "swift-docc-symbolkit",
          "name": "SymbolKit",
          "url": "https://github.com/apple/swift-docc-symbolkit",
          "version": "1.0.0",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/swift-docc-symbolkit",
          "dependencies": [

          ]
        }
      ]
    },
    {
      "identity": "swift-log",
      "name": "swift-log",
      "url": "https://github.com/apple/swift-log.git",
      "version": "1.5.2",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/swift-log",
      "dependencies": [

      ]
    },
    {
      "identity": "swift-tools-support-core",
      "name": "swift-tools-support-core",
      "url": "https://github.com/apple/swift-tools-support-core.git",
      "version": "0.5.2",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/swift-tools-support-core",
      "dependencies": [
        {
          "identity": "swift-system",
          "name": "swift-system",
          "url": "https://github.com/apple/swift-system.git",
          "version": "1.1.1",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/swift-system",
          "dependencies": [

          ]
        }
      ]
    },
    {
      "identity": "combineext",
      "name": "CombineExt",
      "url": "https://github.com/CombineCommunity/CombineExt.git",
      "version": "1.8.1",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/CombineExt",
      "dependencies": [

      ]
    },
    {
      "identity": "queuer",
      "name": "Queuer",
      "url": "https://github.com/FabrizioBrancati/Queuer.git",
      "version": "2.1.1",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Queuer",
      "dependencies": [

      ]
    },
    {
      "identity": "anycodable",
      "name": "AnyCodable",
      "url": "https://github.com/Flight-School/AnyCodable",
      "version": "0.6.7",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/AnyCodable",
      "dependencies": [

      ]
    },
    {
      "identity": "zipfoundation",
      "name": "ZIPFoundation",
      "url": "https://github.com/weichsel/ZIPFoundation.git",
      "version": "unspecified",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/ZIPFoundation",
      "dependencies": [

      ]
    },
    {
      "identity": "swifter",
      "name": "Swifter",
      "url": "https://github.com/httpswift/swifter.git",
      "version": "unspecified",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/swifter",
      "dependencies": [

      ]
    },
    {
      "identity": "keychainaccess",
      "name": "KeychainAccess",
      "url": "https://github.com/kishikawakatsumi/KeychainAccess.git",
      "version": "4.2.2",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/KeychainAccess",
      "dependencies": [

      ]
    },
    {
      "identity": "cryptoswift",
      "name": "CryptoSwift",
      "url": "https://github.com/krzyzanowskim/CryptoSwift.git",
      "version": "1.6.0",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/CryptoSwift",
      "dependencies": [

      ]
    },
    {
      "identity": "checksum",
      "name": "Checksum",
      "url": "https://github.com/rnine/Checksum.git",
      "version": "1.0.2",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Checksum",
      "dependencies": [

      ]
    },
    {
      "identity": "stencil",
      "name": "Stencil",
      "url": "https://github.com/stencilproject/Stencil.git",
      "version": "0.14.2",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Stencil",
      "dependencies": [
        {
          "identity": "pathkit",
          "name": "PathKit",
          "url": "https://github.com/kylef/PathKit.git",
          "version": "1.0.1",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/PathKit",
          "dependencies": [
            {
              "identity": "spectre",
              "name": "Spectre",
              "url": "https://github.com/kylef/Spectre.git",
              "version": "0.10.1",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
              "dependencies": [

              ]
            }
          ]
        },
        {
          "identity": "spectre",
          "name": "Spectre",
          "url": "https://github.com/kylef/Spectre.git",
          "version": "0.10.1",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
          "dependencies": [

          ]
        }
      ]
    },
    {
      "identity": "graphviz",
      "name": "GraphViz",
      "url": "https://github.com/SwiftDocOrg/GraphViz.git",
      "version": "0.2.0",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/GraphViz",
      "dependencies": [

      ]
    },
    {
      "identity": "stencilswiftkit",
      "name": "StencilSwiftKit",
      "url": "https://github.com/SwiftGen/StencilSwiftKit.git",
      "version": "2.9.0",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/StencilSwiftKit",
      "dependencies": [
        {
          "identity": "komondor",
          "name": "Komondor",
          "url": "https://github.com/shibapm/Komondor.git",
          "version": "1.1.3",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Komondor",
          "dependencies": [
            {
              "identity": "packageconfig",
              "name": "PackageConfig",
              "url": "https://github.com/shibapm/PackageConfig.git",
              "version": "1.1.3",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/PackageConfig",
              "dependencies": [

              ]
            },
            {
              "identity": "shellout",
              "name": "ShellOut",
              "url": "https://github.com/JohnSundell/ShellOut.git",
              "version": "2.3.0",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/ShellOut",
              "dependencies": [

              ]
            }
          ]
        },
        {
          "identity": "stencil",
          "name": "Stencil",
          "url": "https://github.com/stencilproject/Stencil.git",
          "version": "0.14.2",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Stencil",
          "dependencies": [
            {
              "identity": "pathkit",
              "name": "PathKit",
              "url": "https://github.com/kylef/PathKit.git",
              "version": "1.0.1",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/PathKit",
              "dependencies": [
                {
                  "identity": "spectre",
                  "name": "Spectre",
                  "url": "https://github.com/kylef/Spectre.git",
                  "version": "0.10.1",
                  "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
                  "dependencies": [

                  ]
                }
              ]
            },
            {
              "identity": "spectre",
              "name": "Spectre",
              "url": "https://github.com/kylef/Spectre.git",
              "version": "0.10.1",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
              "dependencies": [

              ]
            }
          ]
        }
      ]
    },
    {
      "identity": "swiftgen",
      "name": "SwiftGen",
      "url": "https://github.com/SwiftGen/SwiftGen",
      "version": "6.5.1",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/SwiftGen",
      "dependencies": [
        {
          "identity": "yams",
          "name": "Yams",
          "url": "https://github.com/jpsim/Yams.git",
          "version": "4.0.6",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Yams",
          "dependencies": [

          ]
        },
        {
          "identity": "commander",
          "name": "Commander",
          "url": "https://github.com/kylef/Commander.git",
          "version": "0.9.2",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Commander",
          "dependencies": [
            {
              "identity": "spectre",
              "name": "Spectre",
              "url": "https://github.com/kylef/Spectre.git",
              "version": "0.10.1",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
              "dependencies": [

              ]
            }
          ]
        },
        {
          "identity": "pathkit",
          "name": "PathKit",
          "url": "https://github.com/kylef/PathKit.git",
          "version": "1.0.1",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/PathKit",
          "dependencies": [
            {
              "identity": "spectre",
              "name": "Spectre",
              "url": "https://github.com/kylef/Spectre.git",
              "version": "0.10.1",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
              "dependencies": [

              ]
            }
          ]
        },
        {
          "identity": "stencil",
          "name": "Stencil",
          "url": "https://github.com/stencilproject/Stencil.git",
          "version": "0.14.2",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Stencil",
          "dependencies": [
            {
              "identity": "pathkit",
              "name": "PathKit",
              "url": "https://github.com/kylef/PathKit.git",
              "version": "1.0.1",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/PathKit",
              "dependencies": [
                {
                  "identity": "spectre",
                  "name": "Spectre",
                  "url": "https://github.com/kylef/Spectre.git",
                  "version": "0.10.1",
                  "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
                  "dependencies": [

                  ]
                }
              ]
            },
            {
              "identity": "spectre",
              "name": "Spectre",
              "url": "https://github.com/kylef/Spectre.git",
              "version": "0.10.1",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
              "dependencies": [

              ]
            }
          ]
        },
        {
          "identity": "stencilswiftkit",
          "name": "StencilSwiftKit",
          "url": "https://github.com/SwiftGen/StencilSwiftKit.git",
          "version": "2.9.0",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/StencilSwiftKit",
          "dependencies": [
            {
              "identity": "komondor",
              "name": "Komondor",
              "url": "https://github.com/shibapm/Komondor.git",
              "version": "1.1.3",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Komondor",
              "dependencies": [
                {
                  "identity": "packageconfig",
                  "name": "PackageConfig",
                  "url": "https://github.com/shibapm/PackageConfig.git",
                  "version": "1.1.3",
                  "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/PackageConfig",
                  "dependencies": [

                  ]
                },
                {
                  "identity": "shellout",
                  "name": "ShellOut",
                  "url": "https://github.com/JohnSundell/ShellOut.git",
                  "version": "2.3.0",
                  "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/ShellOut",
                  "dependencies": [

                  ]
                }
              ]
            },
            {
              "identity": "stencil",
              "name": "Stencil",
              "url": "https://github.com/stencilproject/Stencil.git",
              "version": "0.14.2",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Stencil",
              "dependencies": [
                {
                  "identity": "pathkit",
                  "name": "PathKit",
                  "url": "https://github.com/kylef/PathKit.git",
                  "version": "1.0.1",
                  "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/PathKit",
                  "dependencies": [
                    {
                      "identity": "spectre",
                      "name": "Spectre",
                      "url": "https://github.com/kylef/Spectre.git",
                      "version": "0.10.1",
                      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
                      "dependencies": [

                      ]
                    }
                  ]
                },
                {
                  "identity": "spectre",
                  "name": "Spectre",
                  "url": "https://github.com/kylef/Spectre.git",
                  "version": "0.10.1",
                  "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
                  "dependencies": [

                  ]
                }
              ]
            }
          ]
        },
        {
          "identity": "kanna",
          "name": "Kanna",
          "url": "https://github.com/tid-kijyun/Kanna.git",
          "version": "5.2.7",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Kanna",
          "dependencies": [

          ]
        }
      ]
    },
    {
      "identity": "xcodeproj",
      "name": "XcodeProj",
      "url": "https://github.com/tuist/XcodeProj.git",
      "version": "8.10.0",
      "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/XcodeProj",
      "dependencies": [
        {
          "identity": "aexml",
          "name": "AEXML",
          "url": "https://github.com/tadija/AEXML.git",
          "version": "4.6.1",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/AEXML",
          "dependencies": [

          ]
        },
        {
          "identity": "pathkit",
          "name": "PathKit",
          "url": "https://github.com/kylef/PathKit.git",
          "version": "1.0.1",
          "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/PathKit",
          "dependencies": [
            {
              "identity": "spectre",
              "name": "Spectre",
              "url": "https://github.com/kylef/Spectre.git",
              "version": "0.10.1",
              "path": "/home/dependabot/dependabot-core/tmp/tuist/tuist/.build/checkouts/Spectre",
              "dependencies": [

              ]
            }
          ]
        }
      ]
    }
  ]
}

Using the new output, the first two lines are skipped, so we can actually parse the JSON.

I'm now thinking maybe it's not worth polluting the signature of this method just for this. I could also filter out the "warning lines" manually. Thoughts?

I'm now thinking maybe it's not worth polluting the signature of this method just for this. I could also filter out the "warning lines" manually. Thoughts?

I think this approach is fine and simpler than filtering out the warnings manually.

Yeah, long term we'll run into this again I expect with other package managers, so having a systemic fix rather than filtering out individual warnings seems more sustainable over time.
Long term, I'd actually think we'd want to always separate stderr/stdout and let the caller decide what they want, but maybe I'm missing a reason not to do that?
I realize today we'd not do that for backwards compatibility/risk of breakage reasons, but is there a reason we wouldn't want to migrate everything towards this split approach over time?

After having a second look at this, I think it should be fine to completely switch over to Open3.capture3, so I went ahead and did that.
For now the default is to merge streams, to keep things compatible, but we should probably change the default to not merging streams (ignoring stderr), and only pass the flag when really necessary (one example of where it's necessary is when running certain git commands that write expected output to stderr instead of stdout, like git branch --remotes --contains <sha>).
As @jeffwidman, this same issue has bitten us before.
Does anybody have issues with this approach? If not, I'll rebase & squash and then ship this.

On second thought, one potential issue with the new approach is if some usage is checking something like output.start_with?("some string"). If the previous output had some warnings, now they will be returned at the beginning and break that.
This is similar to the motivation to not use @landongrindheim's suggestion at https://github.com/dependabot/dependabot-core/pull/7496#discussion_r1247168102.
Overall, the safest solution is probably to keep things completely unchanged when stdout_to_stderr is set, so I will revert to the original approach unless anybody has objections.


Shadow Map Start

For #2594
Here is basic shadow mapping for glTF models, with some debug helpers.The major areas to work on next are fixing aliasing, getting shadow commands based on the light frustum, cascades/automatic light frustum fitting, support for terrain and primitives, and otherwise addressing the TODO's I left in the code.

How do you open a pull request like this without a screen shot :smile:?

The blue lines represent the light volume.
The actual shadow map is on the bottom right.

Looks good to me so far. I don't have any comments yet. I will about how this fits into the engine when it gets to that point.
@pjcozzi Do you want to do a review?

Yes, will check this out tonight.

@lilleyse consider breaking #2594 into Short-term and Long-term sections and add things like "Write tests", "reference doc", etc.  Also feel free to remove anything already there that is now irrelevant.

Great start, @lilleyse!  That's all my comments.

Updated.

Good start!


Debugging MS Teams Custom Tab on Android device via remote debugging.

Element inspector doesn't work. I can select it (ctrl+shift+c) navigate on target element, but on click nothing happens. Also click event on desktop doesn't work at all, but if I try to click on mobile device all works fine.
Environment:
Microsoft Edge version: 87.0.664.57
Microsoft Teams App version: 1416/<IP_ADDRESS>0120802
Android version: 10

Document Details

ID: 423e15ae-4f85-e6b4-05a0-e1c3a1c2d448
Version Independent ID: e8d1d135-b095-dbf7-f3b2-28feace8934e
Content: Get Started with Remote Debugging Android Devices - Microsoft Edge Development
Content Source: microsoft-edge/devtools-guide-chromium/remote-debugging/index.md
Product: microsoft-edge
Technology: devtools
GitHub Login: @MSEdgeTeam
Microsoft Alias: msedgedevrel

Hi @AndreyButyrchik! Thank you so much for sending the Microsoft Edge DevTools team your feedback. Based on feedback from you and others, we found this bug when remote debugging Android devices and have a fix available in Microsoft Edge version 89. To unblock yourself immediately, try using Microsoft Edge Beta which is currently on version 89. Definitely let us know how that goes for you!
You can also send feedback to the Microsoft Edge DevTools team via the Feedback icon in the DevTools.


Update logrus to v1.0.1

Updates logrus to v1.0.1 and fixes the vendor case sensitivity issue. This issue is being fixed in parallel with many other projects to prevent future vendoring errors.
See https://github.com/sirupsen/logrus#logrus-

@dmcgowan needs a little rebase :)

@dmcgowan if you can rebase and solve the conflict we can have this PR get in

@dmcgowan this is blocking the upcoming libnetwork vendoring due to the change (https://github.com/moby/moby/pull/34272) which was merged.

Pushed an update. This change is a lot bigger than it should be. The vendor was pretty out of sync compared to what is used by moby and swarmkit. I have updated the needed packages to match. If the changes cause issues, that is another issue since upgrading this vendor downstream will be using these versions....

@dmcgowan looks like there is still missing dependencies PTAL

Update, not sure how latest CI error would be related
I changed the vendors to exclude any potential functional changes in the update. I would encourage the maintainers of this project to update the vendored versions. As is, the out of date vendors makes importing libnetwork riskier as it has not been tested with the versions of the packages it is likely to be used with in Docker and SwarmKit.

LGTM

Tried to vendor the same runc of moby and the latest moby master but hit some extra dependency issue:
go build -tags experimental -o "bin/dnet" ./cmd/dnet
vendor/github.com/docker/docker/daemon/cluster/convert/config.go:5:2: cannot find package "github.com/docker/swarmkit/api" in any of:
        /go/src/github.com/docker/libnetwork/vendor/github.com/docker/swarmkit/api (vendor tree)
        /usr/local/go/src/github.com/docker/swarmkit/api (from $GOROOT)
        /go/src/github.com/docker/swarmkit/api (from $GOPATH)
vendor/github.com/docker/docker/daemon/cluster/convert/service.go:11:2: cannot find package "github.com/docker/swarmkit/api/genericresource" in any of:
        /go/src/github.com/docker/libnetwork/vendor/github.com/docker/swarmkit/api/genericresource (vendor tree)
        /usr/local/go/src/github.com/docker/swarmkit/api/genericresource (from $GOROOT)
        /go/src/github.com/docker/swarmkit/api/genericresource (from $GOPATH)
vendor/github.com/docker/docker/daemon/cluster/convert/swarm.go:10:2: cannot find package "github.com/docker/swarmkit/ca" in any of:
        /go/src/github.com/docker/libnetwork/vendor/github.com/docker/swarmkit/ca (vendor tree)
        /usr/local/go/src/github.com/docker/swarmkit/ca (from $GOROOT)
        /go/src/github.com/docker/swarmkit/ca (from $GOPATH)
vendor/github.com/docker/docker/daemon/cluster/convert/config.go:6:2: cannot find package "github.com/gogo/protobuf/types" in any of:
        /go/src/github.com/docker/libnetwork/vendor/github.com/gogo/protobuf/types (vendor tree)
        /usr/local/go/src/github.com/gogo/protobuf/types (from $GOROOT)
        /go/src/github.com/gogo/protobuf/types (from $GOPATH)
vendor/github.com/docker/docker/api/types/registry/registry.go:7:2: cannot find package "github.com/opencontainers/image-spec/specs-go/v1" in any of:
        /go/src/github.com/docker/libnetwork/vendor/github.com/opencontainers/image-spec/specs-go/v1 (vendor tree)
        /usr/local/go/src/github.com/opencontainers/image-spec/specs-go/v1 (from $GOROOT)
        /go/src/github.com/opencontainers/image-spec/specs-go/v1 (from $GOPATH)
vendor/github.com/opencontainers/runc/libcontainer/configs/config.go:10:2: cannot find package "github.com/opencontainers/runtime-spec/specs-go" in any of:
        /go/src/github.com/docker/libnetwork/vendor/github.com/opencontainers/runtime-spec/specs-go (vendor tree)
        /usr/local/go/src/github.com/opencontainers/runtime-spec/specs-go (from $GOROOT)
        /go/src/github.com/opencontainers/runtime-spec/specs-go (from $GOPATH)

Thanks @fcrisciani .... Lets use https://github.com/docker/libnetwork/issues/1899 to track this change and get this PR merged asap so that vendoring can happen in moby.


Integrate fideslog with fidesctl

Implement the fideslog SDK in fidesctl

Dependent on ethyca/fideslog#6 to be complete before completing this


Bring back the multi-lingual greeting to the home page

Feature Suggestion

In the past, the home (back than the catalog page) had a multi lingual welcome message to greet the user with different languages and greetings depending on the time of the day. That gave Backstage a nice playful touch! But it also confused some users, causing it to be removed from the catalog page in #5483.
For the new home page (#5416), we should (optional) bring that feature back.

Possible Implementation

Implement a component that shows the message. The home page header might have to be extended to show components instead of strings for the title. The code for the message itself is still in the repo - but unused.
Context

Yep for sure it should be available for voluntary inclusion at least right? :)


Rename package directory

element-data-loader to element-interface

Hi @CBroz1, if you agree, this pull request is ready to be merged.  Thank you.


forgejo: 1.21.2-1 -> 1.20.6-1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for forgejo is: A self-hosted lightweight software forge
meta.homepage for forgejo is: https://forgejo.org
meta.changelog for forgejo is: https://codeberg.org/forgejo/forgejo/releases/tag/v1.20.6-1
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.20.6-1 with grep in /nix/store/fid8zk6fzsf871a6vciqzapnsf73b2p4-forgejo-1.20.6-1
found 1.20.6-1 in filename of file in /nix/store/fid8zk6fzsf871a6vciqzapnsf73b2p4-forgejo-1.20.6-1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
forgejo

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/fid8zk6fzsf871a6vciqzapnsf73b2p4-forgejo-1.20.6-1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A forgejo https://github.com/r-ryantm/nixpkgs/archive/7fe8606aea90411f2165e7164a5adf891c4da69c.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/7fe8606aea90411f2165e7164a5adf891c4da69c#forgejo

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/fid8zk6fzsf871a6vciqzapnsf73b2p4-forgejo-1.20.6-1
ls -la /nix/store/fid8zk6fzsf871a6vciqzapnsf73b2p4-forgejo-1.20.6-1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

forgejo

Maintainer pings
cc @emilylange @urandom2 @bendlas @adamcstephens for testing.

We don’t want this :)

I don't think so. Question is: Is an automatic downgrade like this ever appropriate, or can this be considered a bug in @r-ryantm?


Plural correction of danish translation

Cron Expression
0 3 * * 0,5,6
Expected Output
"Kl 03:00, på søndage, fredage, og lørdage"
Actual Output
"Kl 03:00, på søndag, fredag, og lørdage"
I think this translation might be wrong. The first two days are definite singular, but the last day is plural. You therefore might get the impression that the cron runs only on this 'søndag' (sunday), this 'fredag' (friday) but on all 'lørdage' (saturdays).
@rmja

Can the translations just be updated? (here)

@bradymholt  Consider this test:
    it("0 3 * * 4,5", function () {
      assert.equal(
        cronstrue.toString(this.test?.title as string, { locale: "da" }),
        "Kl 03:00, på torsdage og fredage"
      );
    });

The issue is that in Danish, we use different endings on the day of week depending on whether we mean "next Thursday" in singular og "next and following Thursdays".
My initial pr added an "e" to the end of the dow name by simply modifying commaOnlyOnX0 from ", på %s" to ", på %se", eg.:
"mandag" -> "mandage"
"tirsdag" -> "tirsdage"
That works for a single dow, but as soon as we add more weekdays this of cause fails, because each of the days needs the "e" in the end. The pr only adds the e to the last dow.

Oh wow, this is a very specific variation with Danish it seems.  Is there any way to change the translation so that it is more generic to account for both variations?  Outside of that, the only other way I can think to handle this is to add daysOfTheWeekPlural (here) (or something similar) and pull from those when needed.  But, I think Danish would be the only translation to use this.

@Lars-Sommer How about "Kl 03:00, på enhver søndag, fredag, og lørdag" or similar. That would remove the need for the plural weekday.

@Lars-Sommer How about "Kl 03:00, på enhver søndag, fredag, og lørdag" or similar. That would remove the need for the plural weekday.

I think that would be a good alternative 👍


doc for 43_tabular.learner

I'm not a mentor but I think there are some points that might need to improve in this PR.
I see there are 9 files changed. Normally if you want to docment for 43_tabular.learner, I think there should have only one .ipynb file, one .py file and one .HTML file.
I think we should only commit these 3 files for the PR.
You can check out my note about useful commands that I use during this document sprint. https://gist.github.com/dienhoa/547664c51940906556a15a08cef70e54
Thanks for participating!

I'm not a mentor but I think there are some points that might need to improve in this PR.
I see there are 9 files changed. Normally if you want to docment for 43_tabular.learner, I think there should have only one .ipynb file, one .py file and one .HTML file.
I think we should only commit these 3 files for the PR.
You can check out my note about useful commands that I use during this document sprint. https://gist.github.com/dienhoa/547664c51940906556a15a08cef70e54
Thanks for participating!

Thank you for the feedback. Yes, I see other PRs only have 3 files changed. Not sure what Im doing wrong. Will take a look. Btw, Im using colab, not sure that's creating the difference.

Try to run nbdev_build_doc with the only corresponding file: nbdev_build_docs —fname {path the to file}. then running nbdev_clean_nbs.
For the README, I also have modification but I don't add it to the commit

Thank you. I am doing nbdev_build_docs —fname {path the to file} already . I might have caught my mistake I ran nbdev_clean_nbs first followed by the other two. Will see what the mentors advise.

A few nits, please bring back the README file. It also seems like extraneous CSS's and whatnot were brought in and/or deleted. Please try and fix this

Understand there should be only three files committed (.ipynb, .py, .html of the nbs I edited). In my case, I was wondering how can I rectify this? Thanks a lot

https://stackoverflow.com/questions/39459467/remove-a-modified-file-from-pull-request

@moarshy one small nit and then we can merge, we have 2x the number of TabularModel and tabular_learner's. Please pick one to keep 😉

@muellerzr r u ok with this? :)

Thanks! Great work!


[test] port GpuDirectCudaCheck to tiger

Will fix UES-567

Codecov Report

Merging #972 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #972   +/-   ##
=======================================
  Coverage   91.86%   91.86%
=======================================
  Files          80       80
  Lines       10481    10481
=======================================
  Hits         9628     9628
  Misses        853      853

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 169ab2d...5efc76a. Read the comment docs.


Bewitchment InGameHudMixin crash

Mod Name
Bewitchment
Mod Homepage
https://modrinth.com/mod/bewitchment
Minecraft version
1.20.1
Describe the bug
Game crashes in survival mode
Steps to reproduce

Install mod and dependencies
Create survival world
Crash

Alternatively:

Install mod and dependencies
Create creative world
Observe everything works fine
Switch to survival
Crash

Logs
https://gist.github.com/Fiibii853/ea7cb250a428fe05ee9c812957a9e801
Additional context
I believe this is the same issue as https://github.com/Sinytra/Connector/issues/769 which was mistakenly marked as a duplicate of https://github.com/Sinytra/Connector/issues/765, which was fixed in beta 35

This is on forge 47.1.3


Jordan/2183 fix page network block loading

Closes #2183
Description:

show a loading block if there are no blocks loaded yet

Thank you! 🚀

For contributor:

[ ] Added entries in CHANGELOG.md with issue # and GitHub username
[ ] Reviewed Files changed in the github PR explorer
[ ] Attach screenshots of the UI components on the PR description (if applicable)
[ ] Scope of work approved for big PRs

For reviewer:

[ ] Manually tested the changes on the UI

Transactions should start on 0 or have a loader too

Transactions should start on 0 or have a loader too

you mean on new blocks as they come in?

you mean on new blocks as they come in?

yes, when you're first redirected to the Network page

the first thing you'll see is the screenshot above. are you saying when new blocks come in, the transaction count can be delayed?

he means (I think) the transaction count (first row third column) should also either show a loader or a "0"


"sample from the prior" vs "sample from generative model'

I'm trying to understand how to sample from the prior and how this contrasts to sampling from a "generative model'.
Do I interpret the example from the documentation correctly?
# define joint distribution p(s, m, x, y)
@model gdemo(x, y) = begin
    s ~ InverseGamma(2,3)
    m ~ Normal(0,sqrt(s))
    x ~ Normal(m, sqrt(s))
    y ~ Normal(m, sqrt(s))
    return x, y
end

# this samples from p(x,y)
g_prior_sampler = gdemo()
g_prior_sampler()

# this samples p(x|y=-3.4)
c = sample(gdemo(missing, -3.4), NUTS(5000, 0.65))

Based on this I played around with the second example:
# define p(s, m, [x_1, ..., x_n])
@model gdemo2(x) = begin
    s ~ InverseGamma(2,3)
    m ~ Normal(0, sqrt(s))
    for i in eachindex(x)
        x[i] ~ Normal(m, sqrt(s))
    end
    return x
end

# sample from  p(s, m, x)
g_prior_sampler2 = gdemo2()
g_prior_sampler2()   # -> ERROR: MethodError: no methods matching keys(::Symbol)
# I guess the error is because the length of x in not defined.
# However passing the length as extra parameter does not resolve this.

# sample from p(s, m, [x_1, x_2, x_3])  (that's also sampling from the prior)
c = sample(gdemo2([missing, missing, missing]), NUTS(5000, 0.65))
# -> works :)

# sample from p(s, m, [x_1, x_2] | x_3=2.2)
c = sample(gdemo2([missing, missing, 2.2]), NUTS(5000, 0.65))
# -> ERROR: MethodError: no methods matching (::Colon)(::Int64, ::Base.OneTo{Int64})

The last case would be very useful in applications with missing data.
(probably related to #446.)

You can fix the first case by passing in a default vector type for x, as below:
@model gdemo2(x=repeat(Union{Missing, Float64}[missing], 3)) = begin
    s ~ InverseGamma(2,3)
    m ~ Normal(0, sqrt(s))
    for i in eachindex(x)
        x[i] ~ Normal(m, sqrt(s))
    end
    return x
end

This allows Turing's compiler to infer both type and length for x.
As to your last example: I thought I remembered that we removed support (see #651) for vectors that are of type Union{Missing, Float64}, like what you have here: [missing, missing, 2.2]. There was a lot of conversation on this at #544, as well.
@mohamed82008 do you remember adding this back in? I can't seem to find it anywhere but I have a possibly false memory of you building this after #651.

Thanks a lot! That works nicely.
More fundamentally, could someone confirm or correct if my probabilistic interpretations (see comments in the code example) are correct?
I'd be help to clarify this in the documentation.

No, the mixed missing case is not in there.

More fundamentally, could someone confirm or correct if my probabilistic interpretations (see comments in the code example) are correct?

Yes, I believe that's correct -- but could someone else confirm that? @yebai @xukai92
I think it's worth adding those comments and clarifying this behavior to the documentation, I think they're a very helpful way to think about things. Would you mind if I put something similar to your comments in the documentation?

I think that would be very helpful. For someone like me coming from statistics it is not exactly clear what sampling from the "generative model" means (also the ML community seems to use different
definitions: https://en.wikipedia.org/wiki/Generative_model). Also "sampling from the prior" could be interpreted more narrow than what the current implementation is capable of.
That's the summary of my understanding:

Sampling from a unconditional distribution. This could be the whole joint distribution p(a, b, c, d) or a marginal of  it, e.g. p(a,b) = \int p(a, b, c, d) dcdb.
This case is currently covered with
prior_sampler = model()
prior_sampler()

if model defines a return value and your trick in case we have  vectors.
Alternatively, we can simply use sample by setting all arguments to missing.

Sampling from a conditional distribution. For example p(a, b | c=1.1, d=2.2), or if we assume d is a vector p(a, b, [d_2, d_4]  | c=1.1, [d_1 = 3.1, d_3=3.3] ).
For conditioning we need a sampler (HMC, ...), so it must be used via  sample (with the current caveat that missings are not allowed in arrays).

Because both cases are covered by sample, it might be a good idea to remove the special "prior sampling" method.
Let me know if I can help you with the documentation.

More fundamentally, could someone confirm or correct if my probabilistic interpretations (see comments in the code example) are correct?

Yes, I believe that's correct -- but could someone else confirm that? @yebai @xukai92

@scheidan I can confirm the interpretation is correct. While "generative model" mostly refers to the "prior" in the ML community, but this terminology a bit abused in my opinion. I think the unconditional / conditional distribution terminology is more accurate and easier to work with.
Regarding "missing" data, we do want to support it in the future. It would be great to have some more concrete discussions on possible use cases first.

I agree with Hong's comments.
Regarding

Regarding "missing" data, we do want to support it in the future. It would be great to have some more concrete discussions on possible use cases first.

For the example you provided
# sample from p(s, m, [x_1, x_2] | x_3=2.2)
c = sample(gdemo2([missing, missing, 2.2]), NUTS(5000, 0.65))
# -> ERROR: MethodError: no methods matching (::Colon)(::Int64, ::Base.OneTo{Int64})

Are you trying to impute the missing data via sampling from p([x_1, x_2] | s, m) during the sampling of p(s, m | x_3=2.2)?

Are you trying to impute the missing data via sampling from p([x_1, x_2] | s, m) during the sampling of p(s, m | x_3=2.2)?

Yes exactly, that's just another way to look at it, because
p([x_1, x_2] | s, m) * p(s, m | x_3=2.2) = p(s, m, [x_1, x_2] | x_3=2.2).
As soon I have time I will provide some more explicit use-cases.

Yes that's the same equation I was following. So the decision here is whether or not to provide a "default missing data imputation mechanism" as this? I guess the answer for now is no and we'd like to ask users to do this more explicitly after they obtain the chain.

The guide is a hopefully a little clearer on this now. Does anyone have anything else they think I should put in there or anything that should be expanded on a bit more?

Thanks, looks great!
In the section "Sampling from an Unconditional Distribution (The Prior)" it should be mentioned, that we must have a return statement of all variables we whish to sample.

I think that addresses all the action items here. Do we want to keep this issue open regarding missing values?

Closed in favour of #774


Undo: allow undo to be switched off

Fixes #452 by simply putting an if condition around the history interaction in setHTML.
Adds an example page that disables the undo manager.

Bunch of unit test failures but they don't appear to be related to this change -- are these known failures?

@nedrocks Yeah, unfortunately it's a long story. See #454 for an unsatisfactory fix for the unit tests

LGTM!


Issue with kociemba

I have issue when installing Kociemba library, i type pip install in cmd and it says this error to me, can someone help me?
https://prnt.sc/xlbbe7
https://prnt.sc/xlbaut
https://prnt.sc/xlba4x
https://prnt.sc/xlb7md

I fixed it, just downloaded Kociemba from other source than pip.

I fixed it, just downloaded Kociemba from other source than pip.


No support for .Net Frameork

So move to a modern framework, ok, Linux it is

Linux is a good choice for .NET Core.

By dropping support for .NET Framework we lose all of our 3rd party controls and that raises the pain point to where we can replace Windows desktops with Linux

Duplicate of https://github.com/aspnet/EntityFrameworkCore/issues/18141