Double checking min_split_loss in bag and out of bag

I'm interested in filtering split candidates based on their split gain out of sample, assuming a subsample less than 1. The aim is to consider only those splits where both the gain in sample and out of sample are greater than the specified minimum split loss (gamma). Can anyone provide guidance on how to achieve this?

I don't think we have a way to evaluate based on out-of-bag samples at the moment.

I think the way to do this is to simultaneously build a tree with the out-of-sample data and apply each split to it. For the new split candidates in the tree built with the sample data, evaluate gain reduction in the out-of-sample tree and choose the candidate that maximally improves in-sample, among those for which gamma is also greater than X out-of-sample.
I think this double-checking is very useful in high noise / low signal problems.

For statistical inference algorithms like gradient boosting, the standard way is simply to run cross-validation, which is reasonably effective. GBM is built upon the concept that we can stack many weak models to obtain a strong model, instead of preventing the tree from splitting, you can simply train small/shallow trees and try to prevent XGBoost from adding more trees, at least in theory this should have the similar effect as your feature request.

Yes, that's the theory behind gradient boosting and it works very well in almost all contexts. The scenario where there is an extremely low signal-to-noise ratio is different. Let me justify why I am interested in this functionality.
I am referring to datasets for stock market prediction, and as a particular example, the numerai dataset. It consists of about 5 million records and 2300 variables discretized into 5 values. The level of rank correlation (using a modified Spearman that gives more weight at the extremes) is on the order of 0.02 - 0.03.
At the same time, these predictions exhibit extreme variability. For example, changing the starting seed without changing any other parameter produces changes on the order of 15% in Spearman correlation.
In this scenario, every time a model fits signal with a weak model, that signal becomes unrecoverable later by another weak model because its level is so low that once the information is fragmented, it dissipates into noise.
That's why I believe that a double-check is very important before using ('destroying') the signal in a tree (weak model). I may be wrong, but my intuition tells me that by preserving the signal and using it only in splits that are useful in both a sample and out-of-sample double-check, better results will be achieved than by adding new trees that won't be able to extract the remaining little signal diluted in the noise.

Hi, this is the line for split enumeration on CPU https://github.com/dmlc/xgboost/blob/1450aebb74fe4ae5ed28913910cb425eb348166c/src/tree/hist/evaluate_splits.h#L304
It might take some time to get around it and enable the feature you want. We implement sampling by setting the hessian to zero, which is quite different from your feature request.


[Fuzzy select] panic when writing non standard letter

It would be awesome if fuzzy search could be made to work with languages that aren't English
If that's somehow impossible, at least handle the panic?
thread 'main' panicked at 'byte index 1 is not a char boundary; it is inside 'Б' (bytes 0..2) of `Б`',
C:\Users\Araxeus\.cargo\registry\src\github.com-1ecc6299db9ec823\dialoguer-0.10.0\src\theme.rs:599:27

Examples:

With Accent: À
Cyrilic: Б
Arabic: ش
Greek: β
Hebrew: ש

closed in favor of #181


Enable default peon task GC log and add s3 push task log implementation

Description
Peon tasks themselves are JVM processes, it’s good to expose their GC logs. This PR enables default peon task GC log and adds s3 push task GC log implementation.

This PR has:

[x] been self-reviewed.
[x] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[x] been tested in a test Druid cluster.

Very useful feature, I think it would be great of help to analyze problems in tasks.
Holistically, there're some features that I think should be included in this PR.

a configuration switch that enable task gc logging, by default it should be turned off
HDFS deep storage support, because HDFS is also a widely used deep storage
RESTful API support to get gc log files from deep storage
Web console integration(it could be implemented in a separated PR)


make sure we deserialise the serialised date from getInitialProps

Need to remember that data from getInitialProps is serialised.
I wonder if this means that the data models should only ever carry JSON basic types which are then converted when needed in rendering / logic? That could be particularly annoying with things like events, but it doesn't look like it's going to be changed soon.
We could have something like:

Prismic API
Our normalised JSON API
Converted into Dates etc

bug in prod alerting, so merging


"EXPERIENCES page": Header text and thumbnail aren't in same line on mobile size

Hide thumbnail or reduce the font size.

Resolved 76207279e226e6a27e7d1b5a4510b05dae62183b


Make it work with react 0.14.0-beta3

Great library. I'd love to use it, but I'm a react noob. I can't get this to work with my project based on relay-starter-kit, which uses react 0.14.0-beta3. For some reason, I can't get anything useful to install when I fork and upgrade the dependency. When I install via npm (there's no actual source, just the meta files like package.json).
A fix (maybe an alternative branch) would be very helpful.
Thanks!

When you install with npm, there should be a module folder which contains the code. Not the ES6 source code, but the ES5 compiled code.
I’m not sure why it shouldn’t work with React 0.14. Is there any error thrown?
There is no official changelog yet, so I won’t make changes now. But there will be an update when React 0.14 is released officially.
If you find out what causes the problems, let me know!

bump

Did someone fine out what’s wrong? The module folder should be in an npm install and be loaded.

I think the problem the user is having is when installing via npm with the path pointing to the forked repo url. Since the modules dir is not in git (is created in a task before publishing the package) it does not appear in node_modules after npm install. Also the rest of the files in .npmignore are, well, ignored as well so it only contains the package.json and some other files.
So, to sum up, it should work as is with React 0.14 (after a version bump in the peer dependencies, @ro-ka), and @boosh in your fork you need to add the modules folder as part of your git repo and push the built bundle.

So the peer dependency got bumped to 0.14.0. For me it is working… Can you confirm?

Suspect that it is working. Reopen, if not.

@ro-ka sorry for not reaching back, didn't actually use the released version until yesterday. Working fine for me! :D

Great to hear!


Add short description that only secrets from keptn-webhook-service are shown in secret selection

Add a short description e.g. on top of the page, that only secrets from scope keptn-webhook-service can be used to configure the webhook service.
This would clarify why configured secrets are not appearing in the selection list.
DoD

[ ] Bridge should provide a hint about this

See comment from this issue.  https://github.com/keptn/keptn/issues/5832#issuecomment-969038380


翻译：编辑器插件和 IDE

This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
Please ensure you adhere to every item in this list.
More info can be found at https://github.com/golang/go/wiki/CommitMessage

The PR title is formatted as follows: net/http: frob the quux before blarfing

The package name goes before the colon
The part after the colon uses the verb tense + phrase that completes the blank in,
"This change modifies Go to ___________"
Lowercase verb after the colon
No trailing period
Keep the title as short as possible. ideally under 76 characters or shorter

No Markdown
The first PR comment (this one) is wrapped at 76 characters, unless it's
really needed (ASCII art, table, or long link)
If there is a corresponding issue, add either Fixes #1234 or Updates #1234
(the latter if this is not a complete fix) to this comment
If referring to a repo other than golang/go you can use the
owner/repo#issue_number syntax: Fixes golang/tools#1234
We do not use Signed-off-by lines in Go. Please don't add them.
Our Gerrit server & GitHub bots enforce CLA compliance instead.
Delete these instructions once you have read and applied them

应该是提交到1.15的分支把?

应该是提交到1.15的分支把?

😭我改下

这个有点问题。
你的 master 分支合入 studygolang:dev.boringcrypto.go1.15 ，导致一堆改动；
应该是你在 release-branch-go1.15 修改，合入 这里的 release-branch-go1.15


testing/crypto: Supplementary test cases

Summary

the counter need to be initialized in aesctr, which
add huge block testcase in hash

Impact

aesctr could start in any counter, so we supplemented the counter value in the testcase
nsh> aesctr OK test vector 0 OK test vector 1 OK test vector 2 OK test vector 3 OK test vector 4 OK test vector 5 OK test vector 6 OK test vector 7 OK test vector 8
add new hash testcase
nsh> hash md5 huge block test success sha1 huge block test success sha256 huge block test success sha512 huge block test success

Testing
ci & crypto testing
can configure TESTING_CRYPTO_AES_CTR and TESTING_CRYPTO_HASH and execute the test cases 'aesctr' and 'hash'，at the same time support the software driver CRYPTO_CRYPTODEV_SOFTWARE

[Experimental Bot, please feedback here]
This pull request summary is too short and missing crucial information for reviewers.
Here's what needs improvement:

Summary:

Why: Be specific about WHY the counter needs initialization in aesctr. What problem does it solve? Is it a bug fix, performance improvement, or security issue?
What/How (aesctr): Explain HOW the counter is initialized now.  Provide code snippets if possible.
What/How (hash test): What does "huge block testcase" mean? What size?  What algorithm? Why is this test case necessary?

Impact:

N/A is rarely true: Even minor changes can have some impact. Think carefully!
Consider:

Does the aesctr change affect any existing behavior?
Does the new test case increase build time significantly?
Are there any compatibility concerns with older NuttX versions?

Testing:

CI is not enough: While CI is helpful, reviewers need specific evidence.
Provide:

Target architecture(s) and board(s) used for testing.
Relevant snippets from your test logs (before and after) that demonstrate the issue and the fix. Don't just paste the entire log.

Remember: A good PR description saves reviewers time and increases the chances of your code getting merged quickly!

Thank you @ThePassionate :-) Can you please provide testing logs before and after change and the instruction steps on how to repeat? :-)

Thanks, patch info has been updated. Please review again. :-)


config: use "ecmaVersion: latest"

In eslint 7.30.0, support for latest was added to "ecmaVersion". Switching to latest prevents parsing errors when linting newer syntax (e.g. nullish coalescing operators) in JS files.

cc @pbredenberg

In eslint 7.30.0, support for latest was added to "ecmaVersion". Switching to latest prevents parsing errors when linting newer syntax (e.g. nullish coalescing operators) in JS files.

Ah! Great, yesterday I saw the comment:
It would be nice to set this to something like 'latest', but you must specify a specific version

I took it for granted. Thanks for looking deeper into it.

@onebytegone do you want to do a version bump when this lands? Or do you want any testing?


apps.json fix: fwupdate is for Bangle.js 2 only

This app used to be tagged b2 only, but got both devices during the great tags->supports update: https://github.com/espruino/BangleApps/commit/a94790391a9f13ab83c9658ba48080b9d5967190#diff-70e375511009c0cb767fdc64667e148359c6d6b7b8cf4f100b7eb0e853f83529L8-R10

Argh - thanks!


Version: 0.8.1

Background
HMR
Split dev server as three phase. Is the scanning transform schedule. At scanning stage we collect should be processed file. At transform stage we pipe us file with styleX compiler. Then the schedule will
handle the result to do incremental HMR.
Adapter
It's a planning to provide separate HMR integration for the React framework.
TODO
RSD :)
CheckList

[ ] fix HMR
[x] support incremental HMR
[ ] RSD...

In v0.8.1 us plugin support incremental HMR. And other improve is remove noisy HMR tips.

As a part of this could you stop minify the dist/ code? It makes it really hard to contribute to the project


What specific feature does this offer?

Hi @oxplot , thanks for developing this program! I wanted to ask what specific feature this application affords because I can open generic .pdf files directly in inkscape and I was wondering what pdfrankenstein actually does to manipulate pdf files if it ports out to inkscape? Thanks in advance for the clarification and I like how sleek the application looks.

At the time this app was developed, Inkscape couldn't read and write back exactly what it read from a multi-page PDF — thus simply importing and exporting an arbitrary multi-page PDF was impractical. This is what this app mainly achieves.


Update Docker setup in readme

Hi @robinwhittleton, we recently had a PR to update the Docker config, which resulted in some confusion because the readme asks to call docker run to start the container. People who don't know the difference between docker run and docker start can end up using docker run repeatedly, which will try to re-create the container repeatedly when that's not necessary.
Can you update the readme to use docker create + docker start instead of docker run? Also can you try running the new Docker container to confirm I got all the updates right? Thanks!

This is where my lack of Docker knowledge shows: it’s not a technology I use particularly beyond starting a container sometimes, and this was my first attempt to actually write a Dockerfile myself.
Either way, I spun up your latest changes and am getting 500 errors. Not sure if it’s a config problem at my end or not, will spend a little time debugging.

Closed due to inactivity


OS USAGE PROBABILITY

hi there , I'm making a os series and have interest in your project named as dalloc.

Hi, it is licensed by apache 2.0 license, so feel free to use the project keeping copyright info in source files title and link to the original resource. If you'll find some bugs or decide to add some features fill free to create the issues or pull requests, i would be happy to collaborate


Update Overall Case Workflow

Overall Case workflow to be updated to include scrutiny and registration.
Requirement to be shared

@Ramu-kandimalla this was done during BNSS
See requirement here:
https://docs.google.com/document/d/1deSGCXRvb8MGchbR73eyujixLpVNOGAs4Ok6Yx7Mc08/edit#heading=h.oj9ub93wmwy8

Hi @Taherabharmal , The stage  is updated as per the document only , please find the reference
https://jam.dev/c/96329100-6352-4daf-a266-3936014b6f0d
For Evidence type hearing , stage is not updated an issue is created for the same
Reference: https://github.com/pucardotorg/dristi/issues/2305

Hi @Taherabharmal , the stage is updated as per the document please find the reference


"octopress new post" failing to generate slug with non ASCII titles on Windows

Intro: I'm Russian and I want to write posts in Russian, but I can not use octopress 3.0 to create files from command line. Also I'm using Ruby 2.0 x64 on Windows 7 x64
I tried to set encoding of command promt to be 'windows-1251' and 65001 (utf-8) with chcp, but that did not help:
> bundle exec octopress new post "тест"
octopress 3.0.0.rc.12 | Error:  incompatible encoding regexp match (UTF-8 regexp with IBM866 string)
> chcp 1251
> bundle exec octopress new post "тест"
octopress 3.0.0.rc.12 | Error:  incompatible encoding regexp match (UTF-8 regexp with Windows-1251 string)
> chcp 65001
> bundle exec octopress new post "тест"
DL is deprecated, please use Fiddle
Unfortunately, a fatal error has occurred. Please see the Bundler
troubleshooting documentation at http://bit.ly/bundler-issues. Thanks!
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/bundler-1.6.2/lib/bundler/vendor/thor/parser/arguments.rb:12:in `block in split': invalid byte sequence in UTF-8 (ArgumentError)
        from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/bundler-1.6.2/lib/bundler/vendor/thor/parser/arguments.rb:11:in `each'
        from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/bundler-1.6.2/lib/bundler/vendor/thor/parser/arguments.rb:11:in `split'
        from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/bundler-1.6.2/lib/bundler/vendor/thor.rb:344:in `dispatch'
        from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/bundler-1.6.2/lib/bundler/vendor/thor/base.rb:440:in `start'
        from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/bundler-1.6.2/lib/bundler/cli.rb:9:in `start'
        from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/bundler-1.6.2/bin/bundle:20:in `block in <top (required)>'
        from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/bundler-1.6.2/lib/bundler/friendly_errors.rb:5:in `with_friendly_errors'
        from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/bundler-1.6.2/bin/bundle:20:in `<top (required)>'
        from C:/Ruby200-x64/bin/bundle:23:in `load'
        from C:/Ruby200-x64/bin/bundle:23:in `<main>'

I'm going to assume this has been settled. If not, I'm happy to reopen it.

Still happens in Windows machine with fresh untouched octopress, but as I said before - I use StringEx#to_url to generate slugs, so does not really matter for me.


cannot read GEMS L1C file (V1.2.4)

For Qdoas v3.6.3, when browsing the GEMS spectra, the error message shows Fatal (GEMS_Set) cannot read netCDF variable 'sun_zenith_angle'

Hi, I can't reproduce the problem with my version of QDOAS 3.6.3 (on linux) and GEMS 1.4.2 input data.  Which operating system are you using?  Could you share an example input file where the problem occurs?

Hi, thanks for your reply. I am using Ubuntu 20.04.6 LTS system, Linux version 5.15.0-91-generic. Here is the google drive link of one example gems l1c file, https://drive.google.com/file/d/1bZFD0IGNjr6lAp4bXikcxqxc92xDSNss/view?usp=sharing

And here is the error message:

The order of dimensions in your example file is different from what QDOAS expects (and from the files we have here): when inspecting the file with ncdump -h, I see that sun_zenith_angle (as well as other variables) has dimensions (dim_image_y, dim_image_x), whereas the dimension order in the files we have, is (dim_image_x, dim_image_y).
I also notice that the size of the dimensions in your example file is different from number_of_columns / number_of_lines attribute values.  Is this an original GEMS L1 file, or has it been modified?

Thanks for investigating that. I download the data from the GEMS FTP server by NIER Korea. It is an original file by the processor version V1.2.4. As for the dimension differences, it may be caused by the fact that the shared example is the 44 binning version. The FTP server gives L1c file with three types, namely, original resolution, 22bin, and 4*4 bin.

Yes, the binning factor would explain the difference.  I will try to investigate what is going on, but don't have access to download
new GEMS L1C data at the moment.
Did you try the same file in QDOAS 3.6.0, or was that a different flie?  Because the problem of dimension order should have been the same with that version of QDOAS.

Yes, I was trying the same file in Qdoas 3.6.0 before. It can browse the spectra and even fit successfully for some records. Due to the memory leak issue, I then updated the software to 3.6.3 and found this spectra read issue.

Hi, I've found the cause of the bug.

At BIRA, we work with modified GEMS files where dimensions are reordered for better reading performance (reading spectra is much faster when the spectral dimension (dim_image_band) comes last.  Standard GEMS L1C data has dim_image_band as the first dimension.  QDOAS has a mode to work with original GEMS files, too, but as you discovered, this mode has bugs when reading variables without dim_image_band dimension, such as sun_zenith_angle.  I'll fix it and publish a new version of QDOAS soon.

QDOAS 3.6.0 had the same bug, but did not report all NetCDF reading errors (3.6.3 was the first version to properly handle all NetCDF reading errors...).  So reading sun_zenith_angle and similar geometric variables silently failed, but spectra were read correctly and could be processed.

Thanks for your explanation! I am looking forward to the next version of QDOAS, which will eventually solve this issue.

Hi, qdoas 3.6.10 is now available from conda.  Please let me know if it works as expected!

Hi, thanks for solving this issue. I just updated to qdoas 3.6.10 and found it works perfectly now.


error: building openblas:arm64-osx failed with: BUILD_FAILED

Host Environment

OS: [mac]
Compiler: revision

To Reproduce
Steps to reproduce the behavior:
./vcpkg install xxxx
Failure logs

Cut and paste the appropriate build messages from the console output.
Attach every failure log file mentioned in the console output.

Additional context
Add any other context about the problem here, such as what you have already tried to resolve the issue.

@sjb048, thanks for posting this issue, please provide more information so we can check your error.

trying to install blaze
error: building openblas:arm64-osx failed with: BUILD_FAILED
error: Please ensure you're using the latest port files with git pull and vcpkg update.
Then check for known issues at:
https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+openblas
You can submit a new issue at:
https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[openblas]+Build+error
Include '[openblas] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
vcpkg-tool version: 2023-03-01-538539c4e364dd6f14f5e36f6704144254845159
vcpkg-scripts version: 2256cc983 2023-03-14 (2 hours ago)

Trying to install This:
C:\Devlopment\vcpkg>.\vcpkg install thrift
warning: Starting with the September 2023 release, the default triplet for vcpkg libraries will change from x86-windows to the detected host triplet (x64-windows). To resolve this message, add --triplet x86-windows to keep the same behavior.
Computing installation plan...
with the Error:
error: building sqlite3:x86-windows failed with: BUILD_FAILED
error: Please ensure you're using the latest port files with git pull and vcpkg update.
Then check for known issues at:
https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+sqlite3
You can submit a new issue at:
https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[sqlite3]+Build+error
Include '[sqlite3] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
vcpkg-tool version: 2023-03-14-105f7f7e8a5ea10dfac9874ff9d1a6bacba5f454
vcpkg-scripts version: 20759c873 2023-03-14 (4 hours ago)

@sjb048, @luciferblaze007, could you please provide the error log?

How can I solve the following problems：
error: building openblas:x64-windows failed with: BUILD_FAILED
error: Please ensure you're using the latest port files with git pull and vcpkg update.
Then check for known issues at:
https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+openblas
You can submit a new issue at:
https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[openblas]+Build+error
Include '[openblas] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
vcpkg-tool version: 2023-03-14-105f7f7e8a5ea10dfac9874ff9d1a6bacba5f454
vcpkg-scripts version: 8875aa3cd 2023-03-22 (10 hours ago)

@luciferblaze007, I can successfully install thrift:x64-windows locally, please use command .\vcpkg install thrift:x64-windows --debug try again and put up the complete install log.
PS F:\test\vcpkg> .\vcpkg install thrift:x64-windows
Computing installation plan...
The following packages will be built and installed:
    thrift[core]:x64-windows -> 0.16.0
Detecting compiler hash for triplet x64-windows...
Restored 0 package(s) from C:\Users\test\AppData\Local\vcpkg\archives in 249.1 us. Use --debug to see more details.
Installing 1/1 thrift:x64-windows...
Building thrift[core]:x64-windows...
-- Note: thrift only supports static library linkage. Building static library.
-- Using cached apache-thrift-2a93df80f27739ccabb5b885cb12a8dc7595ecdf.tar.gz.
-- Cleaning sources at F:/test/vcpkg/buildtrees/thrift/src/dc7595ecdf-fb32ebd2bc.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source F:/test/vcpkg/downloads/apache-thrift-2a93df80f27739ccabb5b885cb12a8dc7595ecdf.tar.gz
-- Applying patch correct-paths.patch
-- Applying patch pc-suffix.patch
-- Using source at F:/test/vcpkg/buildtrees/thrift/src/dc7595ecdf-fb32ebd2bc.clean
-- Found external ninja('1.11.0').
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Fixing pkgconfig file: F:/test/vcpkg/packages/thrift_x64-windows/lib/pkgconfig/thrift-nb.pc
-- Fixing pkgconfig file: F:/test/vcpkg/packages/thrift_x64-windows/lib/pkgconfig/thrift-z.pc
-- Fixing pkgconfig file: F:/test/vcpkg/packages/thrift_x64-windows/lib/pkgconfig/thrift.pc
-- Using cached msys-mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst.
-- Using cached msys-mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst.
-- Using msys root at F:/test/vcpkg/downloads/tools/msys2/9a1ec3f33446b195
-- Fixing pkgconfig file: F:/test/vcpkg/packages/thrift_x64-windows/debug/lib/pkgconfig/thrift-nb.pc
-- Fixing pkgconfig file: F:/test/vcpkg/packages/thrift_x64-windows/debug/lib/pkgconfig/thrift-z.pc
-- Fixing pkgconfig file: F:/test/vcpkg/packages/thrift_x64-windows/debug/lib/pkgconfig/thrift.pc
-- Installing: F:/test/vcpkg/packages/thrift_x64-windows/share/thrift/copyright
-- Performing post-build validation
Stored binary cache: "C:\Users\test\AppData\Local\vcpkg\archives\ab\ab07d94efd5276529304c40681c2040b25bf9db917e1c4ec5dd9832c1f013319.zip"
Elapsed time to handle thrift:x64-windows: 1.7663466233333334 min
Total install time: 1.815017195 min
thrift provides CMake targets:

    # this is heuristically generated, and may not be correct
    find_package(Thrift CONFIG REQUIRED)
    target_link_libraries(main PRIVATE thrift::thrift thriftz::thriftz thriftnb::thriftnb)

this issue is happening in mac , since visual studio in mac doesn't have all the supported compliers

Can someone hide the distracting  thrift:x64-windows posts?
For openblas:arm64-osx

Attach every failure log file mentioned in the console output.

@luciferblaze00, Please resubmit an issue and attach the error log. This issue only discusses the issue of openblas:arm64-osx.

This issue hasn’t been updated in 3 month, if it is still an issue, please reopen this issue.


[experiment] merged lyftga/master, creating PR only to get CI to run

Codecov Report

Merging #7320 into master will decrease coverage by 0.05%.
The diff coverage is 52.71%.

@@            Coverage Diff             @@
##           master    #7320      +/-   ##
==========================================
- Coverage   64.94%   64.89%   -0.06%
==========================================
  Files         424      428       +4
  Lines       20598    20934     +336
  Branches     2281     2330      +49
==========================================
+ Hits        13378    13585     +207
- Misses       7097     7225     +128
- Partials      123      124       +1

Impacted Files
Coverage Δ

...et/assets/src/explore/controlPanels/DeckScatter.js
0% <ø> (ø)
:arrow_up:

...rset/assets/src/explore/controlPanels/sections.jsx
100% <ø> (ø)
:arrow_up:

...sets/src/visualizations/deckgl/DeckGLContainer.jsx
0% <ø> (ø)
:arrow_up:

...erset/assets/src/visualizations/deckgl/factory.jsx
0% <ø> (ø)
:arrow_up:

...et/assets/src/explore/components/controls/index.js
100% <ø> (ø)
:arrow_up:

superset/models/tags.py
90.09% <ø> (ø)
:arrow_up:

...sets/src/dashboard/containers/DashboardBuilder.jsx
0% <ø> (ø)
:arrow_up:

superset/assets/src/chart/chartReducer.js
20.33% <ø> (ø)
:arrow_up:

...ssets/src/dashboard/containers/DashboardHeader.jsx
100% <ø> (ø)
:arrow_up:

...rset/assets/src/dashboard/containers/Dashboard.jsx
0% <ø> (ø)
:arrow_up:

... and 63 more

Continue to review full report at Codecov.

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


Laboratory work #3, Alisa Karpova - 22FPL2

I have some problems with Unittests and Import style checks. Can Unittests influence Import style checks? I tried to change start.py many times but it never worked


Correct indentation and use of eventual BG

I'm just starting out, but the indentation and use of "BG" vs. "eventual BG" vs. "projected BG" doesn't look right. I may not understand the algorithm correctly, so I could be completely off-base here. Any input appreciated. Thanks!

Closing pull request so I can resubmit against the dev branch.


Add math support to the theme.

Love this theme! I am using it for my personal blog!
This should add math support to the theme.

Add a standalone katex.html partial, it imports Katex.
Add a if in the <head> section to determine whether to include the partial.
Update README.md.

Thank you very much! Unfortunately, mmark is no longer included as of Hugo v0.92.0. I had to move KaTeX to a shortcode to allow inline math rendering.


refactor(lib): simplify structure, separate packages

What's included

docs(dotenv): add public path webpack tip
fix(wpConfigs): avoid webpack merge on open path list
refactor(lib): simplify structure, separate packages
fix(wpConfigs): devServer, config watchFiles paths
fix(dotenv): apply default contextPath
test(fixtures): removeFixture, clean up

How to test

Coverage and basic unit test check

update the NPM packages with $ yarn
$ yarn test
confirm tests come back clean

...
Example

...
Updates issue/story

ongoing

Codecov Report

Merging #8 (29d3bc6) into main (6d966d1) will decrease coverage by 1.11%.
The diff coverage is 81.48%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@            Coverage Diff             @@
##             main       #8      +/-   ##
==========================================
- Coverage   84.54%   83.43%   -1.11%
==========================================
  Files           7        7
  Lines         317      332      +15
  Branches      104      108       +4
==========================================
+ Hits          268      277       +9
- Misses         43       49       +6
  Partials        6        6

Files
Coverage Δ

src/wpConfigs.js
78.08% <80.00%> (-0.05%)
:arrow_down:

src/dotenv.js
85.71% <82.35%> (-3.02%)
:arrow_down:

... and 1 file with indirect coverage changes

Continue to review full report in Codecov by Sentry.

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


remove js_util

Fixes #48

Note that platform_detect is still a blocker on wasm builds, but that's the last one after this.

Incorrect type casting at https://github.com/jezell/dart-webrtc/blob/a6a18675e48fc7d6b89aa798a18283add17a6b60/lib/src/rtc_rtp_transceiver_impl.dart#L116
Should be
_jsTransceiver.setCodecPreferences(codecs
    .map((e) => e.toMap().jsify())
    .toList()
    .toJS as JSArray<web.RTCRtpCodec>);

looks good to me. e2ee compiles fine, but runs with an error that I'm still trying to fix it.

@cloudwebrtc

Maybe this that I just pushed will fix?

I get another error, it seems that the web package can't run correctly under the web worker

when I try to print the web.window.crypto object
TypeError: null: type 'JSNull' is not a subtype of type 'JSObject'


Added Microsoft Authentication Library (MSAL) AuthenticationService

Summary
This PR improves MsaAuthenticationService by utilizing the Microsoft Authentication Library (MSAL) for Java.
Sample usage
Device code authentication
MsaAuthenticationService auth = new MsaAuthenticationService(AZURE_CLIENT_ID);
auth.setUsername(USERNAME);
auth.setDeviceCodeConsumer((deviceCode) -> {
    if (deviceCode != null) System.out.printf("%s (%s)%n", deviceCode.userCode(), deviceCode.verificationUri());
    else System.out.println("Authenticating using cached tokens...");
});
auth.login();

Username/password authentication
MsaAuthenticationService auth = new MsaAuthenticationService(AZURE_CLIENT_ID);
auth.setUsername(USERNAME);
auth.setPassword(PASSWORD);
auth.login();

SDK version bump
Since MSAL requires Java 1.8, this PR will bump MCAuthLib to Java 1.8: tycrek/MCAuthLib/blob/msal-auth-service/pom.xml#L23
This should be fine as both MCProtocolLib GeyserMC/MCProtocolLib/blob/master/pom.xml#L23 and PacketLib GeyserMC/PacketLib/blob/master/pom.xml#L23 are using Java 1.8.
Options
Developers are able to modify MSAL by passing MSALApplicationOptions to the MsaAuthenticationService constructor. For example:
MsaAuthenticationService auth = new MsaAuthenticationService(
    AZURE_CLIENT_ID, new MSALApplicationOptions.Builder().offlineAccess(true).build());

Available options:

authority
offlineAccess
scopes
tokenPersistence

Caching tokens
This PR adds MSALTokenPersistence, a custom token (de-)serializer for MSAL. This allows developers to easily cache tokens between instances of their programs. This also ensures the user is not required to re-authenticate every time the software is restarted.
Developers are free to add a custom implementation of ITokenCacheAccessAspect, as described on Microsoft's documentation for Custom token cache serialization in MSAL for Java.

Converting to draft to fix that CI failure, built locally.

Force-pushes to fix CI failures.

In my opinion, it's confusing and a bit bloat-y to have two Microsoft implementations. At least on the Geyser end, I'm open to removing the password feature from Microsoft accounts once we implement better options of saving credentials on our end.

What if the existing MsaAuthenticationService switched to using MSAL? It would be more reliable in the long run and I could also add support for username/password fairly easily.
Another benefit is that the MSAL Device Code Flow is mostly handled by the library, making it much easier for developers to implement (can confirm from my own testing). With MsaAuth, developers manually need to implement the loop/wait for the Device Code Flow to succeed in the browser. MSAL also handles refresh tokens automatically, saving that step from the developer as well (saving the refresh token to some form of cache).
Not really relevant but I was curious in the JitPack jar sizes:

GesyerMC 1.4: 46,977 bytes
This PR with MSAL: 75,843 bytes

If you could implement username and password authentication in this PR I'm happy to completely replace the old MsaAuthenticationService. The improvements meaning the developers don't need to handle the waiting for the code would be amazing, but if possible still allow that in case people need that feature.

Yep, definitely can do that. Since it is a different implementation of AuthenticationService that needs to be used differently in code, I'll drop Msa in favour of MSAL for now, unless you feel that this should be done differently.

I would keep the same class names but bump MCAuthLib's version.

Fixed username/password implementation and replaced Device Code with MSAL 👍

@rtm516 If you pass null to persistence() on MSALApplicationOptions.Builder then it will use in-memory caching. I've got nothing else to add so PR is ready to go when you are


TPLink Omada Controller

Submission Template
Please provide the following information.

Vendor Name: TPLink
Product Name: Omada Controller
Version(s) affected: Linux / Windows (all)
Status:  Affected
Update Available:  Yes
Notes: Update is Beta. Reddit:  "overwritten" vulnerable log4j with 2.15 files as potential workaround. Though that should now be done with 2.16
References:
https://www.tp-link.com/us/support/faq/3255/
https://community.tp-link.com/en/business/forum/topic/514452
https://www.reddit.com/r/TPLink_Omada/comments/rdzvlp/updating_the_sdn_to_protect_against_the_log4j/
Last Updated:  15.12.2021 (TPLink Community Reference Post)

For questions about choice for status, please see the information below.

Unknown - Status unknown.  Default choice.
Affected - Reported to be affected by CVE-2021-44228.
Not Affected - Reported to NOT be affected by CVE-2021-44228 and no further action necessary.
Fixed - Patch and/or mitigations available (see provided links).
Under Investigation - Vendor investigating status.

This product has been added to the repository, Thank you.

thx. but I did a mistake, it should be "Omada Controller" rather than "Omega Controller". Guess it does not make sense to file another issue for that?
BR Ben
-----Ursprüngliche Nachricht-----
Von: @.>
Gesendet: Donnerstag 16. Dezember 2021 5:47
An: cisagov/log4j-affected-db @.>
CC: sec488-bb @.>; Author @.>
Betreff: Re: [cisagov/log4j-affected-db] TPLink Omada Controller (Issue #80)
Closed #80.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.


MY game is not responding!

Godot version
3.3.2
System information
Windows 10, GLES2, intel hd graphics 3000, 64 bit
Issue description
so i was making a top down rpg but when i ru my game , it doesnt respond
Steps to reproduce
https://github.com/CyberBlueCodes/QFC
run scenes/world.tscn
Minimal reproduction project
No response

@CyberBlueCodes Can you reproduce this with any of the official demo projects?

Don't guess that I can do it with an demo project, but it does have a loop but it won't run infinitely, it is something that spawns skeleton within the parameters, the loop runs till the value will be under the parameters, and when I export it for Android it works fine but the skeletons don't spawn but if it runs by the editor it stops responding

It appears like this is an infinite loop:
	while not valid_position:
		skeleton.position.x = spawn_area.position.x + rng.randf_range(0, spawn_area.size.x)
		skeleton.position.y = spawn_area.position.y + rng.randf_range(0, spawn_area.size.y)
		valid_position = test_position(skeleton.position)

Yes so sorry it was a silly mistake, I got the tilesets name wrong. sorry


aws.secretsmanager.getSecretVersion doesn't mark secretString and secretBinary as sensitive

Related Slack discussion: https://pulumi-community.slack.com/archives/CRH5ENVDX/p1618397713307500
It seems that aws.secretsmanager.getSecretVersion data source doesn't mark secretString and secretBinary as sensitive attributes and they get stored in the state in plaintext rather than encrypted with the stack encryption provider.
Also if one of these attributes is exposed as a stack output or as input to another resource, it also is stored in plain in the stack output or another resource input data in the state.
import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

const config = new pulumi.Config();

const secretVersion = aws.secretsmanager.getSecretVersion({
    secretId: config.require("secretArn"),
});

export const secretString = secretVersion.then(secretVersion => secretVersion.secretString);

@pbzdyl For now, you wrap the promise with pulumi.secret to ensure it gets marked as secret.

Currently impossible to fix in the provider as it needs https://github.com/pulumi/pulumi/issues/12710


Can't wrap the Query calls in another method.

Describe the bug
Can't wrap the Query calls in another method.
How to Reproduce
We're trying to replace an existing implementation and wanted to limit the changes across the code base. So we have the following
public async Task<GraphQLResult<TQueryResult>> QueryAsync<TQueryResult>(string operationName, Func<Query, TQueryResult> query)
        {
            var gqlClient = // .. make generated client with our IHttpHandler
            // do other things we need
            var res = await gqlClient.Query(operationName, query);
            return res;
        }

The await gqlClient.Query(operationName, query); gives the following error
Source generator failed unexpectedly with exception message:
Sequence contains no matching element
   at System.Linq.ThrowHelper.ThrowNoMatchException()
   at ZeroQL.SourceGenerators.Resolver.Context.GraphQLLambdaLikeContextResolver.Resolve(InvocationExpressionSyntax invocation, SemanticModel semanticModel, CancellationToken cancellationToken)
   at ZeroQL.SourceGenerators.Generator.GraphQLLambdaIncrementalSourceGenerator.GenerateFile(SourceProductionContext context, InvocationExpressionSyntax invocation, SemanticModel semanticModel, HashSet`1 processed)
   at ZeroQL.SourceGenerators.Generator.GraphQLLambdaIncrementalSourceGenerator.<>c__DisplayClass1_1.<GenerateSource>b__0()
   at ZeroQL.SourceGenerators.Utils.ErrorWrapper(SourceProductionContext context, CSharpSyntaxNode location, Action action)
Roslyn(ZQL0001)

Expected behavior
Clearly a Source Generator issue, but I'm not sure if it is a limitation of Source Generators or if it could be supported. If it is a limitation of Source Generators then you can close this. Otherwise it would be good to support this.
Environment (please complete the following information):

Nuget package version - 6.0.0
IDE: VS Code on Mac OS
.Net Version - 6

I did something similar with the QueryInfoProvider. But you have to fetch the CallerArgumentExpression in the wrapper method else it will not work:
    public static void Query<TQuery>(Func<TQuery, object> query, [CallerArgumentExpression("query")] string queryKey = "")
    {
        var queryInfo = QueryInfoProvider.Materialize<TQuery>(query, queryKey);
    }

Also the queryKey is never set at runtime, it's important at compile time as the SourceGenerator from ZeroQL analyzes to build the query string and the query store. And retrieve the correct query string at runtime.

Theoretically, there is a way to make it work. It would require changes in analyzer and it would not look nice.
The QueryAsync would be changed like that:
public async Task<GraphQLResult<TQueryResult>> QueryAsync<TQueryResult>(string operationName, [GraphQLLambda]Func<Query, TQueryResult> query, [CallerArgumentExpression(nameof(query))] string queryKey = null!)
        {
            var gqlClient = // .. make generated client with our IHttpHandler
            // do other things we need
            var res = await gqlClient.Query(operationName, query, queryKey);
            return res;
        }

and I have a feeling that such implementation would definity get some sort of unknown WTF.

It would already help if there is a way that the analyzers capture classes implementing an interface provided by ZeroQL so libraries could implement it and read the query body from the QueryInfoProvider instead of using the generated ZeroQL client. Would have also the nice side effect to get the tooltips with the compiled query.
This would also ensure that the necessary functionality is supported like variable capturing etc.

Hmm.. Potentially the interface can be even a better way to implement it. I will have a look.

Checkout v7.0.0-.preview.1. Now it is possible to create wrappers around generated ZeroQL client. Here example:
public static async Task<T?> MakeQuery<T, TQuery, TMutation>(
        GraphQLClient<TQuery, TMutation> client,
        [GraphQLLambda]Func<TQuery, T> query,
        [CallerArgumentExpression(nameof(query))] string queryKey = "")
        where T : class
{
    var result = await client.Query(query, queryKey: queryKey);

    if (result.Errors != null)
    {
        Console.WriteLine("Errors:");
        foreach (var error in result.Errors)
        {
            Console.WriteLine(error.Message);
        }

        return null;
    }

    return result.Data;
}

Basically new implementation depends on [GraphQLLambda] attribute. Every argument with it will be parsed and converted into query on build.


Images don't get rebuilt after changes to Dockerfile

If I make changes to the Dockerfile, DockStation doesn't rebuild the image next time I start the project.
The only way to rebuild the image would be to do it myself, from the terminal, independent of DockStation.

Not sure if it might be related to #90

Duplicate #67


Support multiple curves such as secp256r1

Hyperledger Fabric uses secp256r1 curve. The keys returned as part of fabric SDK are in raw but they need conversion to hex.

This would be cool, the browser's SubtleCrypto API only supports R1


Support for TeamCity CI

I am looking at implementing support in Catch for our TeamCity build system using the team city-messages functionality. Their code can be downloaded from the jet brains site.
I was wondering if this might be a good addition to the framework for use in CI build systems?

please ignore this, just found that there is already a team city build messaging component

Sorry - I need to make it clearer that it is there - and how to get to it.
Unlike the other included reporters, the TeamCity reporter is not included in the single header version of Catch. You'll need to get the file, separately, from reporters/include/catch_reporter_teamcity.hpp and include that along side catch.hpp where you do #define CATCH_CONFIG_MAIN.

oh - and catch_reporter_teamcity.hpp must be #included after catch.hpp!


BASEURL seems not having any effect

Trying to deploy to my website's subfolder (eg. www.myserver.com/mydir/) so I have set BASEURL in .env correspondingly.
However, it seems there is no effect of doing this, not in HTML Header or in the generated links, which still looks like eg.: href="/css/master.css" - using absolute path and referencing the webserver's root, not my subfulder (/mydir/ in the example mentioned before).

To be honest, I never tested this myself. Guess there is a reason the initial creator of Photo Stream added a warning to that setting. :D I labeled this as bug for now, going to look into it once I got some spare time.

Found a way to make it work. Just add baseurl and urlto _config.yml as in the old version and it will work as expected. If you want to use the download option you should also change in line 40 of photo.html image.path to image.path | relative_url. As far as my testing has gone everything else should work correctly.

I also had this problem, and LucaDanelutti's post fixed it for me. Add baseurl: "something/" to _config.yml.  The BASEURL variable inside .env doesn't seem to get wired up to anything.

Hey everyone, thanks for all the feedback, I will try to add it to the repo soon and give that change a go myself.


Enable traffic to AWS worker network node ports from everywhere

What this PR does / why we need it: In order to enable NLBs on AWS we have to allow traffic from every client IP to the worker network. The reason for this is that NLBs (in contrast to ELBs) preserve the client IPs of the callers.
Which issue(s) this PR tackles:
More details: #242
Special notes for your reviewer:
/cc @vlerenc @mvladev
Release note:

AWS shoot clusters can now use network load balancers out of the box.

/LGTM

I am not sure why we need to add a network rule in the first place. When a Kubernetes Services is created, the Cloud Controller Manager (CMM) will pick it up and create an AWS network rule for the specific node port (see function updateInstanceSecurityGroupsForNLBTraffic), using the IP source ranges in spec.loadBalancerSourceRanges.
Could we write <IP_ADDRESS>/0 in spec.loadBalancerSourceRanges instead of inserting a aws_security_group_rule manually?

Very good point, thanks. I tried that but unfortunately I don't see any change in the security group attached to the instances.
I added .spec.loadBalancerSourceRanges=[<IP_ADDRESS>/16] and from the code you mentioned I would have expected to see a new security group rule. It didn't happen. Might this be caused by the special cloud provider config we use?

@rfranzke I guess you are right, it might be because of DisableSecurityGroupIngress=true:
https://github.com/kubernetes/kubernetes/blob/954996e/pkg/cloudprovider/providers/aws/aws.go#L544-L551
LGTM then

Thank you for digging in. Actually, I'd like it much more if the user could configure the source ranges on his own. However, the 50 rule limit somehow forces us to configure KCM/CCM this way...


[release-1.19] metadata exchange: switch to native implementation

This is an automated cherry-pick of #46067

Opened for discussion. We might want to flip the switch to off by default.

Hi @kyessenov @linsun  @hanxiaop
Historically, the metadata exchange happened after ext_authz.
This has been reordered everywhere, which broke our auth.
I was deploying this on version 1.19.4:
`apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
labels:
istio.io/rev: canary
name: metadata-exchange-after-authz-canary
namespace: istio-system
spec:
configPatches:

applyTo: HTTP_FILTER
match:
context: GATEWAY
listener:
filterChain:
filter:
name: envoy.filters.network.http_connection_manager
subFilter:
name: envoy.filters.http.ext_authz
patch:
operation: INSERT_AFTER
value:
name: istio.metadata_exchange
typed_config:
'@type': type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
config:
configuration:
'@type': type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange
vm_config:
code:
local:
inline_string: envoy.wasm.metadata_exchange
runtime: envoy.wasm.runtime.null
priority: 1
workloadSelector:
labels:
istio: ingressgateway
revision: canary
`

This would allow us to use headers to do auth routing, region routing, etc.
since upgrading, the filter chain has changed from:
> curl <IP_ADDRESS>:15000/config_dump | jq '.configs[] | select( ."@type" == "type.googleapis.com/envoy.admin.v3.ListenersConfigDump" ).dynamic_listeners[] | select( .name == "<IP_ADDRESS>_80" ).active_state.listener.filter_chains.[].filters[] | select(.name == "envoy.filters.network.http_connection_manager").typed_config.http_filters[] | .name '
 "istio.metadata_exchange" "envoy.filters.http.rbac" "envoy.filters.http.ext_authz" **"istio.metadata_exchange"** "envoy.filters.http.grpc_stats" "istio.alpn" "envoy.filters.http.fault" "envoy.filters.http.cors" "istio.stats" "envoy.filters.http.router"
to:
"istio.metadata_exchange" "envoy.filters.http.rbac" "envoy.filters.http.ext_authz" "envoy.filters.http.grpc_stats" "istio.alpn" "envoy.filters.http.fault" "envoy.filters.http.cors" "istio.stats" "envoy.filters.http.router"
Do you have any idea how I can restore this behaviour?
I'm right on the edge of what's comfortable with this filter to be honest, so I hope this isn't asking too much.


add myself to contributors

I have added myself to the contributor list in the requested JSON format.

@iamdarshshah I have updated the file name.


API Tag cloud is not visible

Now the tag cloud is commented out from the api listing page. We need to enable it and style it.

https://github.com/wso2/carbon-apimgt/pull/7654


Status bar color not changing color as specified by the style in style.xml. Avalonia 11.1.0 Android 11 API30 - Android 12 API31

Describe the bug
As said in the title, when using the following code in the styles.xml file the status bar color does not change as it's supposed to.
Instead, on Android 12 API31 the status bar remains white, even if the following line of code is applied in both MyTheme.NoActionBar and MyTheme.Main. On Android 11 API30, when specified, the status bar color changes only for the splash screen, and not for the whole application. Again, the color change is in both theme also for the Android 11 version.
Below the line I used based on documentation:
<item name="android:statusBarColor">@android:color/holo_blue_bright</item>

Here's a screenshot on Android 11 API30:

To Reproduce
Create an Avalonia.xplat project, open the styles.xml file depending on what API level you're using, try to change the status bar color.
Expected behavior
The expected behavior is for it to change color to the one specified.
Avalonia version
11.1.0
OS
Android
Additional context
No response

Use this code my friend:
Subscribe to the MainView of your event to Loaded and use this:
MainView.xaml.cs:
    private void UserControl_Loaded(object? sender, RoutedEventArgs e)
    {
        if (OperatingSystem.IsAndroid())
        {
            var insetsManager = TopLevel.GetTopLevel(this).InsetsManager;
            insetsManager.SystemBarColor = Colors.Black;
            insetsManager.DisplayEdgeToEdge = true;
        }
    }


Icon doc

Description

update icon README to describe how to use the mineral icon package
Motivation and context

the instructions that were there had the wrong import path. the import path was to the index which is not the recommended way of importing. we have to recommend that people use the direct file path way because the way we are exporting our components breaks webpack's admittedly bad tree shaking ability. so if people import the wrong way, they're going to get all the icons in their bundle whether they're using them or not.
Screenshots or videos, if appropriate

How to test

Types of changes

docs
Checklist

[x] Renders and functions properly in all supported browsers
[x] Automated tests written and passing
[x] Accessibility and inclusivity considered
[x] Rendering performance (initial load time & 60fps) and perceived performance considered
[x] Documentation created or updated

closes #215


Not able to access http://:9601/metrics in GKE cluster using k8 soketi helm.

I have installed k8 soketi via helm chart and enabled metrics and serviceMonitor
However, when I try to access my-k8-soketi-k8soketi-metrics service using url http://<IP>:9601/metrics it is not accessible via curl.
The metrics service in GKE is not having any endpoint.

Yes, this is a chart bug that will be fixed. To workaround, it requires you to set the SOKETI_METRICS_ENABLED=1 environment variable with extraEnv


prep for publishing

Prep for publishing:

switch to using package:lints
update the readme markdown badges
adjust the usage guidance in the readme a bit - highlight that people should generally be using package:http

Publishing will let us capture the above changes as well as a previous change to the pubspec repository field.

cc @bkonyi @kevmoo

LGTM, but I can't merge.

From the history, it seems like you're one of the main contributors? We should set you up w/ write access to this repo.

Yes, I wrote the package years ago :-) No idea why I never had merge permissions, but probably didn't question it as an L3 5 years ago.


JSON data has to be defined to test for errors

Robustness: json variable might be undefined.
Firefox 68-78+ (Windows, Mac) calls the success function even when page is unloading.

Thanks, but per the contributing document, this is just a built repo - the source files are in DataTablesSrc and all PRs should be sent there.
It is actually intentionally that JSON needs to be defined - currently an empty reply from the server is not considered valid for DataTables.

Thanks for your reply. Yeah, I didn’t find the original repo :)
I get that JSON needs to be defined, but it’s triggering uncaught exceptions right now, that’s why I suggested this change. I’ll make a PR on the original repo.

We've actually got that ability in the 2 branch of the DataTablesSrc repo. We probably wouldn't pull this in for the 1.x series (current master) as we are putting new feature focus into 2 now.


UriValidator isRpcMethod() and isRpcResponse(): should check for equality instead of .contains()

According to the spec, UriValidator methods isRpcMethod() and isRpcResponse() should check for equality of resource name and instance (should be 'rpc' and 'response', respectively).
The up-java implementation uses .contains() for this check, which is not quite up to spec.

Folks, feel free to question the spec if you disagree with any of it...

Wouldn't say this is about the spec, more about the java implementation? Like - do we want these methods to return true for method uris with name "warpcount" or instance names like "sensoresponset"?
In up-rust, we decided to do a strict equals-check at the moment, which is why I brought this up here to potentially get things consistent...

Fair enough. It should be "rpc." in the name so if Java is not looking for this then it is a bug for me to fix :-).

merged

@AnotherDaniel giving notice to other implementations. We love to see it. :rocket:  :rocket:  :rocket:  :rocket:


Establish a Fee Structure for Land Registration and Transfers

Define and implement a standard fee structure for land registration and transfer processes.

Hi @fishonamos can I implement this?

@fishonamos Can this be assigned to me?


Crash after login.

Crash After Login
Log
Floating point exception (core dumped)
Downloaded via AUR Package

I installed Fast-Discord in an Arch Linux VM via AUR and it worked, are you using Qt 5.15 and did you enter the correct token? Or can you run Fast-Discord with gdb and print the backtrace when it crashes?

yes, I tripled and checked the token it is correct but when I build from the source it is working I think something wrong with the AUR package.

This may have been fixed in last push, if not, can you print the backtrace when it crashes with gdb? That would be really useful.

Log
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff29296c0 (LWP 30722)]
[New Thread 0x7ffff20996c0 (LWP 30723)]
[New Thread 0x7ffff11a96c0 (LWP 30724)]
[New Thread 0x7ffff09a86c0 (LWP 30725)]
[New Thread 0x7fffea5ff6c0 (LWP 30726)]
[New Thread 0x7fffe9dfe6c0 (LWP 30727)]
[New Thread 0x7fffe95fd6c0 (LWP 30728)]
[New Thread 0x7fffe8dfc6c0 (LWP 30729)]
[New Thread 0x7fffdcdff6c0 (LWP 30730)]
[New Thread 0x7fffbffff6c0 (LWP 30731)]
[New Thread 0x7fffbf7fe6c0 (LWP 30732)]
[New Thread 0x7fffbeffd6c0 (LWP 30733)]
[New Thread 0x7fffbe7fc6c0 (LWP 30734)]
[New Thread 0x7fffbdffb6c0 (LWP 30735)]
[New Thread 0x7fffbd7fa6c0 (LWP 30736)]
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 444, resource id: 4208246, major code: 40 (TranslateCoords), minor code: 0
[New Thread 0x7fffbcff96c0 (LWP 30737)]

///------------------///

(gdb) backtrace

#0  0x000055555565c4c8 in ?? ()
#1  0x00005555555f9487 in Api::RessourceManager::getImage(std::function<void (void*)>, QString const&, QString const&) ()
#2  0x000055555565fd5a in ?? ()
#3  0x00005555555f8288 in ?? ()
#4  0x00005555555eefdc in Api::Requester::callCallbacks(Api::RequestParametersNoCb const&, void*) ()
#5  0x00005555555f1406 in Api::Requester::readReply() ()
#6  0x00007ffff6abe0d1 in ?? () from /usr/lib/libQt5Core.so.5
#7  0x00007ffff6f316d8 in ?? () from /usr/lib/libQt5Network.so.5
#8  0x00007ffff6ab12f0 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#9  0x00007ffff7978b3c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#10 0x00007ffff6a8d978 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#11 0x00007ffff6a8e483 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#12 0x00007ffff6ad4478 in ?? () from /usr/lib/libQt5Core.so.5
#13 0x00007ffff5b91c6b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#14 0x00007ffff5be8001 in ?? () from /usr/lib/libglib-2.0.so.0
#15 0x00007ffff5b8f392 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#16 0x00007ffff6ad825c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#17 0x00007ffff6a8611c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#18 0x00007ffff6a90c49 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#19 0x00005555555b8c07 in main ()

Thread 1 "fast-discord" received signal SIGFPE, Arithmetic exception.


Localized array fallbacks not working

Link to reproduction
No response
Describe the Bug
If you have a localized array of references (say 'en-US') and another locale has an empty array (say 'en-GB'), when requesting the locale with an empty array Payload will return the empty array.
Since there is no way to actually remove a locale from a record, this means the only way to correct it is to create an entirely new record and not set the value for the empty array.
To Reproduce
Create a localized field of multiple relations.
Set a relation on the fallback locale.
Set a relation on another locale and then delete it.
Request the locale with the empty field.
Payload Version
2.27.0
Adapters and Plugins
db-mongodb

Here's a patch for it.
payload-array-undefined.patch


Stop constructor for OptionsNuisance messing with its arguments

Fixes issues discussed in #3. I've also added some tests for the OptionsNuisance constructor to check for regressions and basic functionality - we should think about tests for the nuisance sampler itself as well.

Good catch ... as we were only using Tempest earlier for nuisances within a loop of soundings, I fixed it further downstream than I should have here and bounds were not being assigned by reference ... this is a better place.


[FEATURE] Documentation/Tutorial

Sorry for asking here, but i dont know how/where to ask as alternative.
Is there some documentation on how to use the editor?
A overview of functions and a hint how to use them or a  tutorial/small video showing these functions?

Methods to add/remove/move arrows (record/mouse)
Copy/paste sequences
change a holding note to a tap or vice versa
set an audio offset
set bpm changes or fermata
etc.

I found out some of these on my own but i think a reference would be very helpful!
Thanks!

Will look into in the near future

Basic guide written, still working on other pages
https://tillvit.github.io/smeditor/guide/

Thank you very much for this guide!
It helps a lot!


Use B instead of G?

One of the most common pieces of feedback I get from clients for visualizations that use the SI format is "What does G mean?" and "Why doesn't is use B for Billions?".
It's easy enough to do string replacement with something like this:
const yAxisTickFormat = number =>
  format('.1s')(number)
    .replace('G', 'B');

However, as I find myself doing this over and over in different projects, I wonder if it might be a sensible thing to build into d3-format. I thought I'd open this issue as a place to discuss ways to approach this.
Anyone else run into this issue?
Related: https://github.com/d3/d3-format/issues/71

Changing this wouldn’t be backwards-compatible, and also muddies the feature definition, which is very clearly defined  to used SI prefixes. The way for this feature to proceed is a new format directive (something other than s), which is covered by #71. So I’m closing this as a duplicate, but I’d welcome input on that issue!

Thanks!


Extend clean_intersections to return a new graph, topologically equal to the input graph, but with clusters of nodes merged into a single centroid node.

Hi @gboeing. I'm happy to put forward the first version of the new clean_intersections() method. The method now returns the simplified graph instead of just the intersection centroids.
I've added comments to the code, which hopefully will be easy to follow, but I'm happy to write down the main steps of the algorithm. The method doesn't appear to be (too) slow, but there is probably room for improvement.
There are a few nuances to look out for, e.g. when choosing between multiple geometries, but I think that the final decision was sensible.
Finally, the simplified graph can end up having a lot of nodes of degree 2 (in its undirected version). Therefore, further simplification can be achieved by removing these nodes. I'm working on this, but maybe this should be a separate method.
I'm looking forward to your input. Cheers, Pedro.

Hi @PedrosWits, when I use the new function and then apply a ox.get_undirected() on the new graph, I get an error inside the is_duplicate_edge() function. Your method seems to add osmid attributes as ndarrays instead of lists. (I have highlighted the array below for data_other)

data= {'lanes': '1', 'bridge': 'yes', 'highway': 'primary', 'oneway': True, 'geometry': <shapely.geometry.linestring.LineString object at 0x1a296900b8>, 'to': 94, 'length':<PHONE_NUMBER>6417567, 'ref': 'A695', 'from': 98, 'osmid': [5016040, 95817240], 'name': 'Derwenthaugh Road', 'maxspeed': '70 mph'}

data_other= {'lanes': ['1', '1'], 'bridge': 'yes', 'highway': ['primary', 'primary'], 'oneway': [True, True], 'from': 94, 'to': 98, 'length':<PHONE_NUMBER>676412, 'geometry': <shapely.geometry.linestring.LineString object at 0x1a29693128>, 'ref': ['A695', 'A695'], 'osmid': [[114882696, 60893148], 505407462], 'name': 'Derwenthaugh Road', 'maxspeed': ['70 mph', '70 mph']}

These values come from to same example you provided in tests.

Thanks for noticing this, @samuelduchesne. I don't think it is a ndarray, but just a nested list. I wasn't sure whether to flatten the lists when merging attributes of several candidate edges between the centroids, but now I have my answer! I wasn't sure because we lose the mapping of attributes to its prior edges, that is:
[114882696, 60893148] -> osmids or previous edge A
505407462 -> osmid of previous edge B

So, we could potentially get the previous edges back from each new edge, and reverse the clean_intersections transformation if we wanted to. But this is probably not a big deal, as we don't care about the reverse transformation, i.e. going from the cleaned intersections graph back to the original one. We just have the two graphs in memory or store them to disk.
I'll just flatten the resulting lists and submit a new commit.

I also want to do a quick speed benchmark to see how the method performs with increasing size of G.

@PedrosWits would you mind resolving the branch conflicts so we can run the CI tests?

@PedrosWits would you mind resolving the branch conflicts so we can run the CI tests?

Whooops, I'm sorry, I didn't realise this was something that I had to do. I thought I had made sure that the two master branches didn't diverge, but I guess this wasn't the case. And this right was front of me for so long.. erm.. anyway.. it should be ok now.

I also want to do a quick speed benchmark to see how the method performs with increasing size of G.

Looks like the method scales linearly with the number of nodes (code)

There's probably some room for optimisation. I'm guessing the crux is this bit here:
# We also build the reverse mapping: centroid -> osmids
centroid_elements = {i : [] for i in range(len(intersection_centroids))}
for i, osmid in enumerate(G.nodes(data = False)):
    centroid = nearest_centroid[i]
    centroid_elements[centroid].append(osmid)

But maybe that is fine for a first iteration. What do you think @samuelduchesne @gboeing?

@PedrosWits
When trying
G = ox.graph_from_address('Bandung, Jawa, Indonesia', distance=3000, network_type='drive', infrastructure='way["highway"~"trunk|primary|secondary|tertiary"]', clean_periphery=True, simplify=True)
G = ox.project_graph(G, to_crs='+proj=utm +zone=48 +ellps=WGS84 +datum=WGS84 +units=m +no_defs +south')
G = ox.clean_intersections(G, tolerance=50, dead_ends=False)
gdf_nodes, gdf_edges = ox.graph_to_gdfs(G)
G = ox.gdfs_to_graph(gdf_nodes, gdf_edges)

I receive the following error
  File "<ipython-input-6-22a16ce1b815>", line 1, in <module>
    G = ox.gdfs_to_graph(gdf_nodes, gdf_edges)

  File "C:\ProgramData\Miniconda3\lib\site-packages\osmnx\save_load.py", line 610, in gdfs_to_graph
    attribute_values = {k:v for k, v in attributes[attribute_name].items() if pd.notnull(v)}

  File "C:\ProgramData\Miniconda3\lib\site-packages\osmnx\save_load.py", line 610, in <dictcomp>
    attribute_values = {k:v for k, v in attributes[attribute_name].items() if pd.notnull(v)}

ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

I receive the following error
...
attribute_values = {k:v for k, v in attributes[attribute_name].items() if pd.notnull(v)}

Hi @schoeller, thanks for trying out the new method!
Issue:
The 'osmid' attribute for nodes in the new cleaned graph can be a list as opposed to a single value. This is because the centroids (nodes in the cleaned graph) can be composed by multiple nodes (of the original graph), each with its own osmid. Thus when the condition pd.notnull(v) is evaluated and v is a list of osmids, we get an array of booleans, instead of a single true/false value, which causes the ValueError exception.
Solution:
We can store the entire list in a separate attribute, say 'osmids', and store a single value of that list on the 'osmid' key. Does this sound reasonable @gboeing?

But other than that it looks like the method is doing the job right.

Before
After

That sounds like a good solution.

That sounds like a good solution.

Oops, that solution didn't actually work as we were iterating over every k,v pair.
A few lines below in the method gdfs_to_graph the condition (isinstance(v, list) or pd.notnull(v)), is used instead of pd.notnull(value)), and that works for cases where v is a list. Matching the two seems to solve the issue.

I'm not sure why the travis builds are failing when running conda create --name TESTENV ...:
PackagesNotFoundError: The following packages are not available from current channels:

  - geopandas[version='>=0.4']
  - rtree
  - libspatialindex==1.8
  - rtree[version='>=0.8.3']
  - libspatialindex==1.8

I've checked and the packages are available at the listed channels:
  - https://conda.anaconda.org/conda-forge/linux-64
  - https://conda.anaconda.org/conda-forge/noarch

Any ideas, @gboeing?

@PedrosWits I believe this is resulting from https://github.com/conda-forge/geopandas-feedstock/issues/53

Are there any other improvements that you'd like to see @gboeing? I can try to look for performance bottlenecks for large networks as it starts to get rather slow on networks with 10K+ nodes. But other than that, what do you think that is needed to merge this pr?

I think we're nearly there. Let me know when any final changes resulting from code review are finished and I'll take a look. Then we're just waiting on that conda-forge feedstock issue I linked above to run the tests.

I think we're nearly there. Let me know when any final changes resulting from code review are finished and I'll take a look. Then we're just waiting on that conda-forge feedstock issue I linked above to run the tests.

Great, thanks!

@PedrosWits I just re-ran the tests successfully.

Here's a summary of the changes made at the end of the first review round:

[x] New: Updated docstring and added comments
[x] Refactoring: Simplified the code by reusing ox.get_nearest_nodes and pd.apply
[x] Bugfix: The new nodes contain both the attributes osmid (single value) and osmids (list).
[x] Bugfix: Flattened the attribute osmids in the new edges (nested lists were causing issues with nx methods)
[x] Profiling: Initial benchmark shows performance issues with networks containing 10k+ nodes (which aren't very large). Further investigation is needed.

We're probably ready for a second round @gboeing . Some things to consider:

[ ] More detailed performance profiling
[ ] Routes and their corresponding distance should remain similar for the original and cleaned graphs. Is this the case?
[ ] Is the choice of geometry for the new edges adequate? It seems to be the case by looking at the plots. However, I notice many instances of new edges with length greater than the expected maximum: max length (among the candidate edges) + 2*tolerance (maximum distance of old node to its centroid, for u and v centroids). So far I haven't come up with an explanation for this.

@PedrosWits :+1: Works for me. Thanks a ton!

@PedrosWits

Routes and their corresponding distance should remain similar for the original and cleaned graphs. Is this the case?

Yes, within some tolerance they should be similar (with the distance changing only as a result of intersection centroids shifting a few meters from the original unclustered intersection points.

Is the choice of geometry for the new edges adequate? It seems to be the case by looking at the plots. However, I notice many instances of new edges with length greater than the expected maximum: max length (among the candidate edges) + 2*tolerance (maximum distance of old node to its centroid, for u and v centroids). So far I haven't come up with an explanation for this.

Yes, they're LineString objects, right? That should work fine... which makes me wonder if some other edge case isn't being caught algorithmically and might be working incorrectly in certain circumstances?

Yes, within some tolerance they should be similar (with the distance changing only as a result of intersection centroids shifting a few meters from the original unclustered intersection points.
Yes, they're LineString objects, right? That should work fine... which makes me wonder if some other edge case isn't being caught algorithmically and might be working incorrectly in certain circumstances?

Cheers, @gboeing. I think I can look into this, some point at the end of next week. I'll write some tests and let you know the results.

Hi,
I am a newbie with osmnx, can you give a code snippet explaining how to display the simplified graph starting with the following graph
G = ox.graph_from_address('Bandung, Jawa, Indonesia', distance=3000, network_type='drive', infrastructure='way["highway"~"trunk|primary|secondary|tertiary"]', clean_periphery=True, simplify=True)
Thank you very much

Hi,
I am a newbie with osmnx, can you give a code snippet explaining how to display the simplified graph starting with the following graph
G = ox.graph_from_address('Bandung, Jawa, Indonesia', distance=3000, network_type='drive', infrastructure='way["highway"~"trunk|primary|secondary|tertiary"]', clean_periphery=True, simplify=True)
Thank you very much

Hi @EricAski , have a look at the test file for a couple of examples. All you have to do really is project the graph and then call the clean method. For instance:
G  = ox.graph_from_address('Bandung, Jawa, Indonesia', distance=3000, network_type='drive', infrastructure='way["highway"~"trunk|primary|secondary|tertiary"]', clean_periphery=True, simplify=True)

G_proj    = ox.project_graph(G)
G_cleaned = ox.clean_intersections(G_proj, tolerance = 15)

Please note that the pull request has not been merged yet.

@ppintosilva just checking in quick on this PR's status?

@ppintosilva just checking in quick on this PR's status?

Hi @gboeing. I haven't had much time to work on this, but I'll try to look into it over the weekend, or early next week.

* [ ]  Routes and their corresponding distance should remain similar for the original and cleaned graphs. Is this the case?

* [ ]  Is the choice of geometry for the new edges adequate? It seems to be the case by looking at the plots. However, I notice many instances of new edges with length greater than the expected maximum: max length (among the candidate edges) + 2*tolerance (maximum distance of old node to its centroid, for _u_ and _v_ centroids). So far I haven't come up with an explanation for this.

@gboeing , so I just had a look into these two points that I've highlighted previously.
So.. I've computed the shortest paths distances for all pairs in both the original and cleaned graphs and then, for each pair, I took the absolute difference between the two.
One thing that I've noticed is that some nodes in the original graph had a shortest distant greater than 2 times the threshold, but after cleaning, they belong to the same cluster! It's obvious to me now why the second bullet point quoted above doesn't make sense. Two nodes might be close together on a straight line, and hence be assigned to the same cluster, but that doesn't imply that their shortest distance along the network, is anywhere close to that value. That obviously depends on the topology of the network. Please see example below.
So that solves that mystery. But that makes it really difficult to test for correctness. By cleaning the graph we're effectively throwing away information, so there will always be some differences between paths computed in the original vs cleaned graphs. But can we do better than just visual inspection or is that enough?

Example

The dictionary key represents the ids of the nodes in the original graph (source, target) of the shortest path.
new_edge is the ids of the nodes in the cleaned graph
value is the shortest distance difference between the two (zero in the cleaned graph because they belong to the same cluster)

(4550426634, 13800765): {'new_edge': (277, 277), 'value':<PHONE_NUMBER>0000005}

* [ ]  More detailed performance profiling

Oh, the performance test that I did previously was actually silly of me. I forgot to take out the time that took to retrieve the data from the server. As the bbox gets larger it obviously takes longer to get the data from the server. Then, the time it takes to clean the graph is actually negligible in comparison.
So these both of the issues that I've highlighted previously don't appear to be issues at all.
I think that we're in a good position to merge this PR @gboeing

@ppintosilva thanks! Can you resolve the merge conflict and I'll take a final reviewing pass then merge?

One of the travis builds (py36) timed-out. I guess there's a way to restart/re-run the build? I've noticed that this also happened in other builds, so it shouldn't be a problem with the latest commit.

@ppintosilva thanks!

@ppintosilva thanks!

@gboeing thanks for the support, patience and guidance getting this PR through! Cheers :raised_hands:

Superseded by #450


[$500] Contact Method - Red dot error message appears and then goes away

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

Version Number: <IP_ADDRESS>
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Access staging.new.expensify.com
Sign into a valid account
Click on Profile > Contact Method > Add any contact method
After adding the contact method, go to the Verify page and enter any random code (To get the error message)
Tap "Back" and then reenter the contact method page

Expected Result:
User expects that if the red dot is showing on the main contact method page, that an error message should be shown when reentering the page OR if no error message is to be shown, then no red dot message on the main contact page
Actual Result:
The red dot is shown on the main contact page but as soon as the user opens the verify code page once more, there is no sign of any error
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[x] Android: mWeb Chrome
[ ] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/93399543/5c35f570-370e-44d4-8250-4fcbff7b2432
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01c2adce8aa36e2400
Upwork Job ID:<PHONE_NUMBER>607379456
Last Price Increase: 2023-12-07

Proposal
Please re-state the problem that we are trying to solve in this issue.
Contact Method - Red dot error message appears and then goes away
What is the root cause of that problem?
When we get an error
We store this value in ONYX
What changes do you think we should make in order to solve the problem?
I think the best way to fix this is
Use useEffect or navigation event when we leave the screen like
    useEffect(
        () => () => {
            User.clearContactMethodErrors(props.contactMethod, 'validateLogin');
        },
        [],
    );

https://github.com/Expensify/App/blob/8fa65ec4de74f22f7c700eb78b4ee83eda96de58/src/pages/settings/Profile/Contacts/ValidateCodeForm/BaseValidateCodeForm.js#L157
What alternative solutions did you explore? (Optional)
NA

Proposal
Please re-state the problem that we are trying to solve in this issue
The red dot is shown on the main contact page but as soon as the user opens the verify code page once more, there is no sign of any error.
What is the root cause of that problem?
What causes the described behaviour is this code block which clears the error when the component that contains the magic code input is mounted:
https://github.com/Expensify/App/blob/8fa65ec4de74f22f7c700eb78b4ee83eda96de58/src/pages/settings/Profile/Contacts/ValidateCodeForm/BaseValidateCodeForm.js#L121-L129
What changes do you think we should make in order to solve the problem?
We have two options here, as mentioned in Expected Result:

Remove the code that clears the error on component mount and have the error persist.
Remove the red dot from the Contacts Method page item in case we want to keep the logic that clears the error.

Videos

MacOS: Chrome (Option 1 - Option 2)

Option 1

https://github.com/Expensify/App/assets/56457735/72dafa97-23e1-424f-8b6e-631c1419c75f

Option 2

https://github.com/Expensify/App/assets/56457735/5c4bcdad-5c11-4f13-8b28-5657268c9ecc

Thanks, everyone, for the proposals! I'm reviewing them

@cubuspl42 with the login page we have other BaseValidateCodeForm https://github.com/Expensify/App/blob/main/src/pages/signin/ValidateCodeForm/BaseValidateCodeForm.js

@cubuspl42 with the login page we have other BaseValidateCodeForm https://github.com/Expensify/App/blob/main/src/pages/signin/ValidateCodeForm/BaseValidateCodeForm.js

Oh, that is slightly confusing naming.

Summing up the proposals:

@namhihi237 & @ZhenjaHorbach: reasonable proposals, similar. Both edited multiple times, unless you want to start some edit timestamp investigation, I'll assume the one by @namhihi237 has precedence here as it was originally posted earlier
@ikevin127 Thanks for your proposal. It's well written, but the solution seems less direct than the ones I mentioned above

Understood!

the solution seems less direct

That's funny if we look at the first 2 proposals edit timestamps.
Anyways, to explain the reasons why I posted a proposal after the first 2 were already posted:

the first 2 proposals were posted 2-5 minutes after the issue was opened were vague on 3 fronts: RCA, the way they were written and solution wise
none of the initial proposals already posted (without later edits) took into consideration both ways to fix the bug mentioned in Expected result

I suppose some contributors use this practice where they post something very vague just to get their first in first then do a dozen edits subsequently.
Perhaps this should be brought up on Slack because it seems unfair, especially for new contributors, which have 0 chance to get their first proposals in with these kind of practices from more experienced contributors 😂

Yeah, I also don't like these edit wars.

Perhaps this should be brought up on Slack because it seems unfair, especially for new contributors, which have 0 chance to get their first proposals in with these kind of practices from more experienced contributors 😂

It's not as bad as you suggest.
Proposals are selected based on their content. Only in case of a "draw", the order of filing is taken into consideration (which is still quite often in case of the relatively simple issues).
If you had a well-written, ready proposal at a time when a proposal posted earlier was barely a stub, you can respectfully point that in the discussion, so this information is available to the C+. Don't start any kind of struggle with the contributors, though, it's about stating facts.

Yeah i think when we edit it can only make the original proposal clearer, not when posting the proposal for the first time it will be different from after editing

I approve the proposal by @namhihi237
C+ reviewed 🎀 👀 🎀

Sorry for the delay, @cubuspl42 - do you mind reviewing the last proposal & letting me know if your decision still stands?

@dukenv0307
Just so we're on the same page, would you share a video presenting the glitch you observed with the other solution?

@dukenv0307
A I see it, it's a minor delay. Seems related to the navigation, but I'm not 100% sure. It's important to note that this is also a corner case; typically, when the user is informed that they provided an invalid code, they would just fix the typo.
@Beamanator
Unless you think that this delay is worth addressing, I think we're fine with @namhihi237 proposal. Clearing the error during component unmounting feels like a reasonable solution to me.

@dukenv0307 I hear your concerns, and I partially agree with them. You mention corner cases, though.
The error should be handled locally on the page that displays the mentioned error, while we process it globally instead.
A fix by @namhihi237 is local and brings much value with a small and relatively clean change, which moves the place where we clear the error.
Your fix brings slightly more value in corner cases but is less clean, in my opinion, as it focuses on "ignoring" the error (filtering it out) based on a specific condition.
A significantly better proposal would refactor the handling of the mentioned error to be fundamentally local, but I'm not sure whether it can be done with a reasonable amount of code.
@Beamanator I think it comes down to whether we treat @dukenv0307's observations as more than corner cases.

I think let's focus for higher-level GHs and let's close this one since the proposal really isn't the best option.  this is really a pretty minor issue.

@slafortune
It seems like your actions are based mostly on the issue's impact. If so, you could've closed this issue 2 weeks ago, as the impact has been known from the beginning.
It was now in the post-proposal selection phase. It's quite late for a call like this.


lcov .gcda files in x86_64 build folder

Hi,
I'm trying to use  the lcov action to generate code coverage reports, but i'm getting this error:
Capturing coverage data from /Users/rortiz/Library/Developer/Xcode/DerivedData/roproject-fcachpkjymhnigcbynpuoxckbwyt/Build/Intermediates/roproject.build/Debug-iphonesimulator/roproject.build/Objects-normal/i386/
Found gcov version: 7.0.0
Found LLVM gcov version 3.4, which emulates gcov version 4.2
Scanning /Users/rortiz/Library/Developer/Xcode/DerivedData/roproject-fcachpkjymhnigcbynpuoxckbwyt/Build/Intermediates/roproject.build/Debug-iphonesimulator/roproject.build/Objects-normal/i386/ for .gcda files ...
geninfo: WARNING: no .gcda files found in /Users/rortiz/Library/Developer/Xcode/DerivedData/roproject-fcachpkjymhnigcbynpuoxckbwyt/Build/Intermediates/roproject.build/Debug-iphonesimulator/roproject.build/Objects-normal/i386/ - skipping!
When I checked the folder i386 he really no have the .gcda files, but in the folder /Users/rortiz/Library/Developer/Xcode/DerivedData/roproject-fcachpkjymhnigcbynpuoxckbwyt/Build/Intermediates/roproject.build/Debug-iphonesimulator/roproject.build/Objects-normal/x86_64/ the files are created.
How can I configure the lcov to get these files in x86_64 folder or configure the gcov to generate the files in the both folders when i'm testing in x86_64 platform?
Thanks!

Just to be clearer, here is the script i'm using:
lane :beta do
xctest(
workspace: "roproject.xcworkspace",
scheme: "roproject",
destination: "platform=iOS Simulator,name=iPhone 5s",
sdk: "iphonesimulator",
destination_timeout: 120,
build_settings: {
"GCC_INSTRUMENT_PROGRAM_FLOW_ARCS" => "YES",
"GCC_GENERATE_TEST_COVERAGE_FILES" => "YES"
}
)
lcov(
  project_name: 'roproject',
  scheme: 'roproject',
  output_dir: 'coverage_reports'
)

end

Try enabling "Gather coverage data" in Scheme -> Test step -> Test

Hi @xfreebird, this option is already enabled.
Looking at lcov action, looks like the script supports only i386 architecture, the path for find the files .gcda it is fixed code
def self.derived_data_dir(options)
        pn = options[:project_name]
        sc = options[:scheme]

        initial_path = "#{Dir.home}/Library/Developer/Xcode/DerivedData/"
        end_path = "/Build/Intermediates/#{pn}.build/Debug-iphonesimulator/#{sc}.build/Objects-normal/i386/"

        match = find_project_dir(pn, initial_path)

        "#{initial_path}#{match}#{end_path}"
      end

@KrauseFx Has some way to detect the architecture and replace in the end_path?
Thanks!

@rafaortiz Sorry, I'm not using the lcov action myself.

I created a pull request to we can specify the architecture in lcov
See in:
https://github.com/KrauseFx/fastlane/pull/633#1


Travis-CI needs to adapt to new repository name

Builds are not passing, because the repository's name has changed from Cortex2.0 to Cortex.

Yes. The issue is fixed. PR #171 has been merged.


What they (π δ ⮭) means on each column?

Add explanation of these on chrome store.

Hover your mouse over them. They have appropriate title properties set.


Error in JSDoc. sap.ui.unified.calendar.CalendarUtils is incorrectly named

OpenUI5 version:
latest
The JSDOc associated to sap.ui.unified.calendar.CalendarUtils has the name sap.ui.unified.calendar instead sap.ui.unified.calendar.CalendarUtils, so you can check in the API reference that there is no entry for CalendarUtils.
The associated JSDOC is:
/**
 * Calendar Utility Class
 *
 * @namespace
 * @name sap.ui.unified.calendar
 * @public
 */

But it should be:
/**
 * Calendar Utility Class
 *
 * @namespace
 * @name sap.ui.unified.calendar.CalendarUtils
 * @public
 */

I think the name tag isn't wrong in that comment, but the description itself is. The comment is meant to describe the parent namespace sap.unified.calendar. There's no separate file for that namespace, so its documentation has been placed in an arbitrary file under that namespace, here into the CalendarUtils.
The JSDoc comment for the CalendarUtils class itself can be found further down below in lines 20-24.
I leave the issue open for a fix of the description.

Yes, you're right. I'm sorry. I should get more sleep...

Never mind. The description of the package is anyhow misleading and needs to be fixed (I prepared a change already, it's waiting for review).


Not working with localforward to remote ollama server

In my setup I have a underpowered laptop where I do my coding and a beefy server to handle ollama.  The server is not on the internet, and needs to be accessed via a jump host on ssh.  I use LocalForward 11434 <IP_ADDRESS>:11434 to emulate having it locally.
For curl and other vscode plugins like Continue it appears that my ollama server is available on localhost
curl -X POST http://localhost:11434/api/generate -d '{
  "model": "codellama:13b",
  "prompt": "Write me a function that outputs the fibonacci sequence"
}'

{"model":"codellama:13b","created_at":"2024-02-06T07:24:29.612339609Z","response":"\t","done":false}
{"model":"codellama:13b","created_at":"2024-02-06T07:24:29.635149631Z","response":"if","done":false}
{"model":"codellama:13b","created_at":"2024-02-06T07:24:29.657876752Z","response":" err","done":false}
{"model":"codellama:13b","created_at":"2024-02-06T07:24:29.680659605Z","response":" :=","done":false}
{"model":"codellama:13b","created_at":"2024-02-06T07:24:29.703439665Z","response":" validate","done":false}
...

Twinny however does not appear to be compatible with this setup, and keeps insisting I should install ollama locally.

Expected behavior
Since the configuration is all about ports and urls, I'm expecting Twinny to try and use the port:host combo I set up, not any other systemcalls to ollama.
Desktop

Hey thanks for the info, this seems to be a Duplicate of https://github.com/rjmacarthy/twinny/issues/70?

Yup.  Thats a duplicate.  Did not spot since the summary/title was windows.


Abstract all crypto implementation (includes #21)

This abstracts the cryptographic implementations of symmetric crypto and
computing message digests.
This makes it possible to fully swap out openssl with something else if
that were to get implemented.
Signed-off-by: Patrick Uiterwijk<EMAIL_ADDRESS>By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the Apache License Version 2.0, as specified in the LICENSE file of this repository.

Can you add a test in CI with --no-default-features?

@jethrogb that is in #29. The problem is that we will need a crypto library to compile, and at this moment there's no other one.

Cargo features are meant to be additive. This means different parts of the dependency tree may enable different features in the same dependency and this should work as these crates intended. The implementation in #29 is not additive:
$ cargo build --features crypto_openssl,crypto_ring
...
error[E0592]: duplicate definitions with name `encrypt`
  --> src/crypto/crypto_openssl.rs:37:5

Cargo features aren't appropriate for choosing a “backend” implementation. Dependency injection using traits, like you're doing with the signing key, is the way to do it.

Closing in favor of #36


Added a GUI for face recognistion using LBPH algo

Fixes: #87
Proposed Changes

GUI for LBPH algo

Screenshots

@akshitagupta15june solved issue #87

@akshitagupta15june solved issue #87

@akshitagupta15june  one small doubt, The actual contribution will start from today right? for swoc 2021, according to the website.

@akshitagupta15june  one small doubt, The actual contribution will start from today right? for swoc 2021, according to the website.

Yes

Yes

Your pe is merged
Great work!

Your pe is merged
Great work!


Validate Credentials Before Middleware?

I have a use case in which I would ideally determine the current user before the middleware is executed. Is there a good way to do that? I keep bouncing back and forth in a chicken and egg situation when trying to authenticate my OAuth user with my ACL.

How would you know who the oauth user is if you don't run the middleware that validates the access token and fetches the user? Guess your acl has a method to set the current authenticated user somewhere

I guess that's the question... I'm trying to figure out if there is a way to manually execute the middleware in some reliable fashion. Ideally I'd do this in a service provider.
The only other option is to neuter some of my ACL's features and run everything in a custom middleware. The issue stems from the fact that the ACL lib is instantiated when the user is a guest, but they become privileged during middleware execution via OAuth.
I suppose the better way to look at this would be to delay instantiation of the ACL until a user has been authenticated, but I'm not sure that's possible either.
Closing in search of a better solution, comments still welcome.


Force LLVM to preserve value names in the same situations where we em…

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

…it them in the first place.
Fixes IRGen test failures that only arise in non-asserts builds that
we've apparently been working around in less principled ways for
the last few months.

This isn't going to be usefully tested by smoke tests because it only changes things for non-asserts builds, which we don't have any of in the bots.


Send APIs status through Sentry Bot

Creating a hook for Sentaur bot that when called with "apis" it shows status of all our APIs.
Right now it's just reading a random from from Sentry because I don't have the data created in Sentry. yet.

closing in favor of https://github.com/getsentry/eng-pipes/pull/600


Set friendly traceback language based on document locale

Adds a simple private formula friendly_traceback_set_lang to _grist_DocInfo, which sets the language based on the locale in the document settings. Updating the locale in the UI automatically updates this formula as usual, so tracebacks are always shown in the current language if possible.
The friendly-traceback library has been translated into several languages. Currently, the main other languages are Spanish, Tamil, Russian, and Hebrew. The full list of languages can always be seen at https://github.com/friendly-traceback/friendly-traceback/tree/main/friendly_traceback/locales.
Also adds a couple of other simple formulas parsed_settings and locale which are used by friendly_traceback_set_lang and may be useful for other purposes in the future.
This change was proposed and prepared by @alexmojaki

Closing it for now, can be revisited later.

Why not just merge it as is? All 3 of us seem to be happy with the current code.


node: Fix panic when node store is not initialized yet

Because node store registration happens in the background, the nodeStore
pointer can still be nil at the time the local node is updated first.
Fixes: 4a7d484af44b ("Daemon: Update Health endpoints IP on localNode.")
Fixes: #5137
Signed-off-by: Thomas Graf<EMAIL_ADDRESS>

This change is

test-me-please

test-me-please

Marked as needs-backport/1.2 as #5117 (which this fixes) is also marked that way.