compile errors

I'm troubleshooting numerous  errors.  After several "multiple definition" errors when compiling, I deleted and reloaded everything IDE-wide ESP32, and now I start off with  compile error "no such file..." for esp_err.h.   Then I look and see
#include "esp_err.h"
#include "driver/ledc.h"
#include "sensor.h"
#include "sys/time.h"
Maybe I'm missing something, but I don't see those four files supplied by either you or Espressif.  Did Espressif remove them from this version 1.0.6 Library, I wonder?
So I'm looking closer at your instructions.
You say "Recompiled with ESP32 Arduino Core 1.0.5".  Do you mean "Recompiled with ESP32 Espressif Core [Boards Manager] 1.0.5"?  Because after that sentence, when people follow your instructions to "Download latest ZIP file from https://github.com/espressif/esp32-camera.git into the esp32-cam subfolder", they get Library (not Boards) Manager content in ver. 1.0.6.  The only way I can see to get ESP32 ver 1.0.5 of anything is through the Arduino IDE Boards Manager getting Espressif as I quoted above.
I also wonder if, or why not do I need anything ESP8266?
I will eventually fix all of this...I always do.  But if you can think about this and give some more details it might save me a month.
Thank you!

Espressif themselves call it "Arduino core for the ESP32"  - https://github.com/espressif/arduino-esp32
If they call it something else in the Boards manager - that's their inconsistency.
I just recompiled everything in 1.0.6 and it works - so you are making a mistake somewhere in the process.
Are you using Arduino IDE?

Pick  the camera sketch you want to implement - there are three options
Download the entire repo as a zip file from https://github.com/espressif/esp32-camera.git  into the sketch folder
Delete 'examples' folder from the archive
unzip using -j option so all files are in the same folder

should work
Why are we talking about esp8266 ?  That board has nothing to do with this.

Thank you!  That all helps

I think Espressif's new names are different - "arduino-esp32-master.zip" instead of what your instructions refer to as "esp32-cam-master.zip"; and they no longer include the 'examples' folder.  Do you see that, or am I in the wrong place?

Yep, you are in the wrong place. The zip file is from here: https://github.com/espressif/esp32-camera.git

Reference to Arduino Core is for configuration of Arduino IDE only - nothing to download

Part of the problem is that Espressif has two very similar named repositories, and I got into their "espressif/arduino-esp32" not using your link into " espressif/esp32-camera".
But the other part is that they DID change the name from "esp32-cam-master.zip" like you have to "esp32-camera-master.zip"
You might want to fix that (and maybe warn to avoid "espressif/arduino-esp32" which is way more current [9 days vs 2 yrs] than your code works with).
Thank you!!!!


Avoid &foo[0] on C-Style arrays

Confusing as some parts of the class use redundant operators and other parts do not.

I've switched the base to the 1.14.4-dev branch we're working on. Can you rebase please? Try:
git fetch origin
git rebase -i origin/1.14.4-dev
It will then bring up an editor. If you remove the 2 commits before the one you want. Please check the result then force push it, and it should just change the document. Thank you!

@itseasy21 Looks like there's still an extra commit in here. Would you mind rebasing again to remove the commit with the title "issue template updated to prevent spam in repository"? Thanks!

Dug this out - I can rebase it, but I think main question is for 1.14.x are we okay taking on a change which will add conflicts on merges? I don't see us doing major merges from Bitcoin to the branch, so probably okay, just debatable on value?

probably okay, just debatable on value?

Did Bitcoin Core do anything with these?

I compared this code against what's in Bitcoin's main branch, and Bitcoin has all of these changes now. Given that this is a small PR, the code reads much better this way (it's a small change but I'd have to stop and read the code very carefully to figure out why it was written the previous way), I'm fine with this. I'll pull and test before giving a complete review.

Code compile and passes tests for me.
I think there are some extra commits here, so @itseasy21 if you want to rebase on 1.14.7-dev (and include only the code changes and not the commits deleting GitHub issue templates), I can do a final review.

@chromatic should be good to go now..


retesteth support: eth_getblockbyhash

can you please add https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getblockbyhash method to the RPC. I use this for better post condition check when chain reorg happens in the tests.
also I am adding besu client to tests automation: http://retesteth.ethdevops.io check it out.

I might be  wrong but, I think this might be what you are looking for  https://besu.hyperledger.org/en/stable/Reference/API-Methods/#eth_getblockbyhash

The method appears to be not available in besu retesteth mode.

That method was not enumerated in the docs - https://github.com/ethereum/retesteth/wiki/RPC-Methods

Yes. I recently start using it for chain reorg tests better post condition verification.


Any way to have two entry points?

Hi,
As I know, vuetober is designed to setup a Single application, with only one index.htm delivered.
However it's hard to migrate my old website pages into new structure in short time.
If there is any way that I could make multiple pages with many entry point?
/  index.htm <- old static homepage
/products/:id products.htm
/users/:id users.html
/app1/:all?* app1.htm <- new
/app2/:all?* app2.htm <- new
Any advices will be appreciated

Hi, at the moment there is not a way to have multiple entry points, but that would be a great feature! It could make Vuetober themes incrementally adoptable, rather than being all or nothing.
The bulk of our configuration magic happens with html-webpack-plugin, and writing the .htm files to disk. If we expanded upon this to look for all .htm files in a particular directory, I don't see any reason why we couldn't support multiple entry points. My time is pretty limited at the moment, but I'd love to see any experiments done with this!


[Question]:  Why the Vector Similarity is always Zero？？

Describe your problem
Why the Vector Similarity is always Zero？？

im using openAI text-embedding-3-large

Wha't is dimension of this embedding? Any exception in log?

Wha't is dimension of this embedding? Any exception in log?

same problem. i'm using model yinka (1792d) on xinference，switching to bge(1024d, also on xinference) does solve the problem


SimCLR distributed training

Hi!  Thanks for this awesome repo.  The official SimCLR implementation (https://github.com/google-research/simclr) does not provide a multi-gpu implementation "for reasons such as global BatchNorm and contrastive loss across cores."  Does this implementation solve that issue, and if so, does it attain the same performance as the official code/model?

This implementation supports multi-gpus distributed training (DistributedDataParallel). I used the PyTorch official SyncBatchNorm as the global batchnorm. The contrastive loss across cores is enabled by a GatherLayer (https://github.com/open-mmlab/OpenSelfSup/blob/696d04950e55d504cf33bc83cfadbb4ece10fbae/openselfsup/models/simclr.py#L55) that gathers tensors across GPUs and supports backward propagation. The official SimCLR implementation in TensorFlow should support distributed training, I'm not sure the differences between "distributed training" and "multi-GPUs training" in TensorFlow.
Regarding the performance, due to the computation resources, I can merely run a SimCLR with batchsize=256, epoch=200. The linear ImageNet classification evaluation is ongoing.
A table comparing the performance of different methods in all benchmarks will appear in recent days.

Thank you!

This implementation supports multi-gpus distributed training (DistributedDataParallel). I used the PyTorch official SyncBatchNorm as the global batchnorm. The contrastive loss across cores is enabled by a GatherLayer (
https://github.com/open-mmlab/OpenSelfSup/blob/696d04950e55d504cf33bc83cfadbb4ece10fbae/openselfsup/models/simclr.py#L55
) that gathers tensors across GPUs and supports backward propagation. The official SimCLR implementation in TensorFlow should support distributed training, I'm not sure the differences between "distributed training" and "multi-GPUs training" in TensorFlow.
Regarding the performance, due to the computation resources, I can merely run a SimCLR with batchsize=256, epoch=200. The linear ImageNet classification evaluation is ongoing.
A table comparing the performance of different methods in all benchmarks will appear in recent days.

Hi, thanks for your great implementation!
I have tried the GatherLayer in my own model and task (BERT for NLP), but run into some strange memory issues.

w/o the GatherLayer operation (in this case, the loss is computed within each GPU device, and there is no cross GPU communication.), the memory cosumption is 6423/6785/7355/7803/8485 MB for batchsize per GPU of 16/20/24/28/32, this is as expected.

But when I import and use the GatherLayer to compute a global contrastive loss, the memory consumption increase very sharply: 8271/12265/23275/31691/OOM for 16/20/24/28/32, I think it's very strange that the memory would increase from 12265 to 23275 simply because I add 4 more instances per GPU, It is also strange that memory increase from 7803 to 31691 simply because I aggregated the output feature from all GPUs, the gatherlayer is three times large as the entire encoder model...
so there might be something wrong with GatherLayer memory consumption or the way I adopted it.

Note that batchsize of 16 means that each GPU produce feature of [16x2, 128] size, and I'm training on 8 32G V100 GPUs.
Really appreciate any reply and help, thx!


Redesign app bar.

Issue #169
Created an appbar and added the girlscript logo, title and user icon.
The other changes seen are formatting done automatically by AndroidStudio. I've made changes only in dashboard.dart
Screenshot:

it has conflicts


"Could not find any cudnn.h" when building from source

Starting on commit https://github.com/google/jax/commit/60d7198381db2098c3319c01ba8060bad9a14422 I get the following error when building with cuda support.
Starting local Bazel server and connecting to it...
Bazel binary path: ./bazel-0.24.0-linux-x86_64
Python binary path: /opt/conda/bin/python
MKL-DNN enabled: yes
-march=native: no
CUDA enabled: yes
CUDA toolkit path: /usr/local/cuda
CUDNN library path: /usr/local/cuda

Building XLA and installing it in the jaxlib source tree...
ERROR: /root/code/jax/build/BUILD.bazel:21:1: error loading package '@org_tensorflow//tensorflow/compiler/xla/python': in /root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/tensorflow/compiler/xla/xla.bzl: Encountered error while reading extension file 'cuda/build_defs.bzl': no such package '@local_config_cuda//cuda': Traceback (most recent call last):
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 1253
		_create_local_cuda_repository(repository_ctx)
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 956, in _create_local_cuda_repository
		_get_cuda_config(repository_ctx)
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 688, in _get_cuda_config
		find_cuda_config(repository_ctx, ["cuda", "cudnn"])
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 668, in find_cuda_config
		auto_configure_fail(("Failed to run find_cuda_config...))
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 274, in auto_configure_fail
		fail(("\n%sCuda Configuration Error:%...)))

Cuda Configuration Error: Failed to run find_cuda_config.py: Could not find any cudnn.h matching version '' in any subdirectory:
        ''
        'include'
        'include/cuda'
        'include/*-linux-gnu'
        'extras/CUPTI/include'
        'include/cuda/CUPTI'
of:
        '/usr/local/cuda'

 and referenced by '//build:install_xla_in_source_tree'
ERROR: Analysis of target '//build:install_xla_in_source_tree' failed; build aborted: error loading package '@org_tensorflow//tensorflow/compiler/xla/python': in /root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/tensorflow/compiler/xla/xla.bzl: Encountered error while reading extension file 'cuda/build_defs.bzl': no such package '@local_config_cuda//cuda': Traceback (most recent call last):
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 1253
		_create_local_cuda_repository(repository_ctx)
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 956, in _create_local_cuda_repository
		_get_cuda_config(repository_ctx)
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 688, in _get_cuda_config
		find_cuda_config(repository_ctx, ["cuda", "cudnn"])
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 668, in find_cuda_config
		auto_configure_fail(("Failed to run find_cuda_config...))
	File "/root/.cache/bazel/_bazel_root/180cc62733246893a6f39cd7c8b63394/external/org_tensorflow/third_party/gpus/cuda_configure.bzl", line 274, in auto_configure_fail
		fail(("\n%sCuda Configuration Error:%...)))

Cuda Configuration Error: Failed to run find_cuda_config.py: Could not find any cudnn.h matching version '' in any subdirectory:
        ''
        'include'
        'include/cuda'
        'include/*-linux-gnu'
        'extras/CUPTI/include'
        'include/cuda/CUPTI'
of:
        '/usr/local/cuda'

I think that this could be something like the new XLA version needing different flags / locations of cuda headers?

I think TensorFlow changed how it finds CUDA.
Try this patch. It removes the --cudnn_path option and lets TF's logic find CuDNN automatically.
https://gist.github.com/hawkinsp/29139c1edfa60e7ddaea8143fdcbcb5e
(In general our jaxlib" build does unusual things with the TF build process to build XLA. We should probably move the jaxlib build entirely into the XLA tree so we aren't as prone to this kind of breakage. jaxlib is really xlapy anyway.)

I think TensorFlow changed how it finds CUDA.
Try this patch. It removes the --cudnn_path option and lets TF's logic find CuDNN automatically.
https://gist.github.com/hawkinsp/29139c1edfa60e7ddaea8143fdcbcb5e
(In general our jaxlib" build does unusual things with the TF build process to build XLA. We should probably move the jaxlib build entirely into the XLA tree so we aren't as prone to this kind of breakage. jaxlib is really xlapy anyway.)

Worked for me!

Can someone tell me how to apply this patch ?

this simple fix was never pushed to main, so I don't really understand what development process would close this issue. Also this patch will not apply to the master version of build/build.py, which still has several references to cudnn_install_path
Please reopen this issue to avoid opening a new one

Please open a new issue. I don't think this is the same problem.
a) if you haven't considered it, you should prefer to use a prebuilt jaxlib.
b) everything that patch did is present in master (i.e., --cudnn_path is optional, and if you don't specify it, it acts the same way as that patch did.)


neon: implementation of max

Here's an implementation of vmax.
The tests build fine on Wasm, but I'm getting a test fail on one of the x86 intrinsics.
/x86/avx512f/mm512_cvtepi8_epi64/native/c[ OK    ] [ 0.00000000 / 0.00000000 CPU ]
../x86/avx512f.c:8678: assertion failed: r[3] != test_vec[i].r[3] (121 != 0)

This might be due to an outdated emscripten or v8, but again, it might not, I'm not sure. I'll update my build.
(CC @ngzhian @tlively)

What compiler, version, target, and flags are you seeing that error on?  It looks like CI is successful, so I'll merge it, but I'd like to track down that failure if possible…

Fixed by f9772fd05bd994a5f646bc81ded2443c51c09d11, thanks!


Rename to chris1111.github.io 👍

Hi Chris,
It would look better if you rename this repo to chris1111.github.io, it will be accessible on chris1111.github.io directly without appending the repository name in the URL :)
Thank you

Thanks but github.io is here


plex server uri changed, cert cannot be validated

don't know exactly when it happened, it might have been when i upgraded plex recently or maybe when my NAS needed a restart, or maybe this automatically happens behind the scenes ... but my plex server was given a new uri.
When dizquetv started it had this error in the logs on start:

Couldn't get DVRS list from data. This error will prevent 'refresh guide' or 'refresh channels' from working for this Plex server. But it is NOT related to playback issues. Error: GET /livetv/drs failed: Hostname/IP does not match certificate's altnames: Host: 192-168-0-102.9d18b......plex.direct. is not in the cert's altnames: DNS:*.b5aaf7f4d......plex.direct

It then had these more detailed errors when i visited the settings -> plex page.
Error getting Plex server status Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Host: 192-168-0-102.9d18b......plex.direct. is not in the cert's altnames: DNS:*.b5aaf7f4d......plex.direct
        at Object.checkServerIdentity (tls.js:288:12)
        at TLSSocket.onConnectSecure (_tls_wrap.js:1484:27)
        at TLSSocket.emit (events.js:310:20)
        at TLSSocket._finishInit (_tls_wrap.js:917:8)
        at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:687:12) {
  reason:     \"Host: 192-168-0-102.9d18b.......plex.direct. is not in the cert's altnames: DNS:*.b5aaf7f4d......plex.direct\",
  host:     '192-168-0-102.9d18b......plex.direct',
  cert: {
    subject: [Object: null prototype] {
      C:     'US',
      ST:     'California',
      L:     'Los Gatos',
      O:     'Plex, Inc.',
      CN:     '*.b5aaf7f4d......plex.direct'
    },
    issuer: [Object: null prototype] {
      C:     'US',
      O:     'Plex, Inc.',
      CN:     'Plex Devices High Assurance CA2'
    },
    subjectaltname:     'DNS:*.b5aaf7f4d......plex.direct',
    infoAccess: [Object: null prototype] {
          'OCSP - URI':     [Array],
          'CA Issuers - URI':     [Array]
    },
    modulus:     'BF884D0E855CA9D6D7865A4EA20AAB3017400736992D4D89F140D67498CF3BBAB70EEF04D0A6FE7E7016D8D32EC008E1336E31732454CCC9CA30D6DD8EEC8F2DF27A23C002C845A1228FBBF93C9F1E6B29115B2072FFE3E713B601E14A4921C8E5F88182B2FD172F967134706F6C1C654F4B1F3C733D5C52065079DE1948C6891C63016F143BABCE5CE46852B42CFBDBDA6912A7D4A310CEC62DBC73B7731E35E267EAF34647AAB149F94164AC04089F91A36A799B3AE84864C8444D0779534F82093991AE35F9FDAD634B5A0338CF5A72F4DE008005893737010586CAB9CC0D957815681561B3D0CE663E65B5825763D4AB93688A53307BFD3E6E99C88D07BD',
    bits:     2048,
    exponent:     '0x10001',
    pubkey: <Buffer 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 bf 88 4d 0e 85 5c a9 d6 d7 86 5a 4e a2 0a ab 30 17 ... 244 more bytes>,
    valid_from:     'Sep  1 00:00:00 2020 GMT',
    valid_to:     'Sep  1 12:00:00 2021 GMT',
    fingerprint:     '08:BE:5D:57:5E:9D:E2:97:35:F4:9F:15:6C:C7:9F:25:3F:2D:A4:E2',
    fingerprint256:     'B4:F9:5C:AB:60:D0:15:85:2C:ED:35:3C:5C:20:AE:E2:38:B5:8F:09:B8:A1:0F:07:3A:57:C1:88:3C:00:B9:8F',
    ext_key_usage: [     '<IP_ADDRESS>.<IP_ADDRESS>.1',     '<IP_ADDRESS>.<IP_ADDRESS>.2' ],
    serialNumber:     '07D09DE336F6B4241AA7819CFABBD4ED',
    raw: <Buffer 30 82 05 ef 30 82 04 d7 a0 03 02 01 02 02 10 07 d0 9d e3 36 f6 b4 24 1a a7 81 9c fa bb d4 ed 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 4c 31 0b ... 1473 more bytes>,
    issuerCertificate: {
      subject:     [Object: null prototype],
      issuer:     [Object: null prototype],
      infoAccess:     [Object: null prototype],
      modulus:     'A903EB8563615FE37FE4B2723CFB2F0D413D487FC5E7951C407171EDD4B0784467B69A8B5AF30BC9717B19A5FA19F3E7F5C6B99E245C62F63D5FA5F52D99AFCE5AE63A1D3D1A8E07CACCA617FF8A9D81C94B1597C14D6C3A607CBB422B7FCC28BDEB2D80D30975CFBD2AE3FE35411B53D757D412B110EB096C260FC3609E6E7AFB68B27A567EC05213764D40356DA7508D92B51F6B19768B3613FEB5966670647C3E35B42D546DD8AAA879E2744D10F740246837342F7BFD2EE9AC267017DC6AA3A569D4ABEBFE25C28642923985DD2C9F97FE400D66D9E7EAD6CFE0825F0B2D7F3D5A49236F2075CEBA277CEC7E956B2AEDCD4CE8548001984E76CBECD0990B',
      bits:     2048,
      exponent:     '0x10001',
      pubkey: <Buffer 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 a9 03 eb 85 63 61 5f e3 7f e4 b2 72 3c fb 2f 0d 41 ... 244 more bytes>,
      valid_from:     'May 19 12:00:00 2015 GMT',
      valid_to:     'May 19 12:00:00 2025 GMT',
      fingerprint:     '56:DD:60:95:42:6F:41:8F:C6:90:8B:FE:A3:C5:3E:20:39:FD:57:84',
      fingerprint256:     '50:D3:D7:1F:C0:CD:7E:36:AD:AE:32:22:1F:EF:BE:8C:C2:9B:26:76:BA:32:6C:09:B8:FA:1B:24:DB:E7:55:14',
      serialNumber:     '0DA3784D303377F0B50BCBCEDCAAA33A',
      raw: <Buffer 30 82 04 b9 30 82 03 a1 a0 03 02 01 02 02 10 0d a3 78 4d 30 33 77 f0 b5 0b cb ce dc aa a3 3a 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 6c 31 0b ... 1163 more bytes>,
      issuerCertificate:     [Object]
    }
  },
  code:     'ERR_TLS_CERT_ALTNAME_INVALID'
}

You can see the previously saved uri started with 9d18b in the URL, but it now starts with b5aaf7f4d, so the code is not validating the cert with the old uri.
I had to manually edit the server uri to get things working again, and luckily checked the logs to notice these pretty obvious errors in the logs.
Do you know what actions trigger a plex server to use a new uri?

It's a good question. I am not really sure. I think you'll have more luck asking in Plex-specific forums. I heard this is related to whole-server restarts.


[Camel 4.0-M3] Upgrade to Groovy 4.x

In order to get the latest improvements and bug fixes, we need to upgrade to Groovy 4

Depends on https://issues.apache.org/jira/browse/CAMEL-18920

Fixed by https://github.com/apache/camel-quarkus/pull/4630


Error when build with --prod flag

I'm getting following error when build --prod
ERROR in : Unexpected value 'NavParams in<EMAIL_ADDRESS>imported by the module 'SendMessagePageModule in PROJECT_FOLDER/src/app/send-message/send-message.module.ts'. Please add a @NgModule annotation.
I'm submitting a ...
[x] bug report
[ ] feature request
Steps to reproduce:
Add a modal controller and pass parameters.
At modal component :
import { NavParams, ModalController } from '@ionic/angular';
Ionic info:
Ionic:

   ionic (Ionic CLI)             : 4.12.0 (/usr/local/lib/node_modules/ionic)
   Ionic Framework               : @ionic/angular 4.0.0-rc.0
   @angular-devkit/build-angular : 0.13.6
   @angular-devkit/schematics    : 7.1.4
   @angular/cli                  : 7.1.4
   @ionic/angular-toolkit        : 1.2.3

Cordova:

   cordova (Cordova CLI) : 9.0.0
   Cordova Platforms     : android 8.0.0, browser 5.0.4, ios 5.0.0
   Cordova Plugins       : cordova-plugin-ionic-keyboard 2.1.3, cordova-plugin-ionic-webview 2.3.1, (and 17 other plugins)

System:

   Android SDK Tools : 26.1.1 (/Users/developer/Library/Android/sdk)
   ios-deploy        : 1.9.4
   ios-sim           : 7.0.0
   NodeJS            : v11.12.0 (/usr/local/Cellar/node/11.12.0/bin/node)
   npm               : 6.7.0
   OS                : macOS Mojave
   Xcode             : Xcode 10.2 Build version 10E125

Hi there,
Can you try this again on a more recent version of Ionic? A lot of changes have gone into navigation even in the release candidates.
If the issue still persists, please post your modal component code as well as its corresponding .module file if it exists.
Thanks!

Same problem, when try build --prod

Hi there,
Can you describe your problem a bit more? Also a repo with the code required to reproduce this issue would be very helpful.
Thanks!


Chart carousel doesn't account for whenever a new chart is imported

When importing a new set, it requires closing the game to check.

Was aware of this issue for a while now, previously blocked because of #54, but now that that's been merged we should hopefully be able to fix this issue.

Resolved via #81 and #82.


Add License to the Project

Hi @grabinskij. Could you add a License to the Project.

Thanks. I have created License for the Project


Allow more refined Re-add button behaviour

closes #2991
The back-end is still throwing errors.
Before merging this PR the backend has to allow the readding

Backend issue is closed and the PR is merged. Please test.


enhancement: Handle "mount" and "network" for LinuxNamespaceType

Current implementation of LinuxNamespaceType::try_from only recognizes "mnt" and "net" for Mount and Network namespaces respectively. This commit expands accepted strings to include "mount" and "network" for better compatibility with potential use cases.
Fixes #186

Hi @saschagrunert @utam0k PTAL! Thx very much

Thanks, @Apokleos


Detect target features

In clap, we have https://github.com/clap-rs/clap/issues/1363.  I'm tempted to close this out by pointing to shadow.  One thing mentioned in that issue but that I'm not seeing in shadow is checking target_feature support (simd flags).

It may be similar to this issue. https://github.com/baoyachi/shadow-rs/issues/53
Do you have any good suggestions. @epage

One idea I have is to create a non-exhaustive enum that either has an as_str or derefs to str that has the string version of the enum (which Display wraps).  Then its just a matter of code-genning that similarly to the code in the clap issue.
I can take a crack at this tomorrow if you want.

Yeah，I look forward to your pr


Connextscan Vercel build broken

Background
Vercel builds broken for connextscan-ui. See latest deployment build logs: https://vercel.com/connext-979dc950/frontend-connextscan-ui/76bMCkqDK1cFYPVRBMQyE3URz8h4
There's a wagmi config error that doesn't crop up when building local.

We can ditch this now, since main cutover is complete.


[Bug]: Error parsing grant opportunity ID in FFIS spreadsheets

Why is this issue important?
We rely on FFIS digests to enrich our available Grant data. In order to do so, we need to identify each grant represented by a row in an FFIS spreadsheet, which we accomplish by parsing an embedded URL to the grant on Grants.gov.
Since Grants.gov has changed the canonical URL structure for grant opportunity detail pages and the FFIS spreadsheets now reflect this change, our parsing logic needs to be updated accordingly.
Current State
We expect each grant opportunity ID to be provided in an oppId query parameter on the spreadsheet cell that provides the URL. However, these values are now provided as a URL path segment, e.g. https://www.grants.gov/search-results-detail/352804, where 352804 is the ID.
Expected State
Identifiers can be parsed from FFIS spreadsheets successfully.
Implementation Plan
Update the parsing logic to extract opportunity IDs from the correct path segment. Ideally, we can still support ?oppId parameters as a fallback.
Relevant Code Snippets
No response

Fixed by #730


vue-cli doesn't work on windows

Version
2.9.3
Reproduction link
http://www.xxx...
Steps to reproduce
I upgrade my nodejs to 8.9, but I found vue-cli doesn't work anymore, it shows errors with
"vue : 无法将“vue”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写，如果包括路径，请确保路径正确，然后再试一次。
所在位置 行:1 字符: 1
vue
    CategoryInfo          : ObjectNotFound: (vue:String) [], CommandNotFoundException
    FullyQualifiedErrorId : CommandNotFoundException"

I've tried to uninstall and install the vue-cli many times, and set it's path(D:\nodejs\node_global\bin, where my nodejs was installed) into system envs, it also shows the error
"文件名、目录名或卷标语法不正确"
I found the same issue in issue list, but you guys just said it's easy to solve....   :(
heart broken.....

### What is expected?
tell me what happen....

### What is actually happening?
vue-cli doesn't work in windows.

<!-- generated by vue-issues. DO NOT REMOVE -->

升级 Node 以后要重新安装全局包。


fix(DateTimePickerV2): :focus not working in firefox

Closes #3619
Summary

If a child element sets outline, css:focusdoes not work on either child or parent element anymore in firefox.

The previous invalid style was applied to ${iotPrefix}--date-time-picker__box, it sets outline to $danger-01. If I set :focus or :focus-visible on the same element. The outline stays $danger-01. And the parent :focus outline not working either.

I have to move the invalid style to the parent wrapper to make it work in firefox.

Change List (commits, features, bugs, etc)

move class to the wrapper element
update the single select story to make sure tab key works

Acceptance Test (how to verify the PR)
Tab key

go to single select story
check the invalid check box in knobs
click on the text "DateTimePickerV2 Single Select"
push tab key
make sure the input is in focus with blue outline

Mouse click

go to single select story
check the invalid check box in knobs
click on the datetime input
make sure the input is in focus with blue outline

Mouse click

go to Selected absolute story
check the invalid check box in knobs
click on the datetime input
make sure the input is in focus with blue outline

https://user-images.githubusercontent.com/24279794/204611689-b735dcbd-5927-41d0-b42b-2c239014118f.mov

Things to look for during review

[ ] Make sure all references to iot or bx class prefix is using the prefix variable
[ ] (React) All major areas have a data-testid attribute. New test ids should have test written to ensure they are not changed or removed.
[ ] UI should be checked in RTL mode to ensure the proper handling of layout and text.
[ ] All strings should be translatable.
[ ] The code should pass a11y scans (The storybook a11y knob should show no violations). New components should have a11y test written.
[ ] Unit test should be written and should have a coverage of 90% or higher in all areas.
[ ] All components should be passing visual regression test. For new styles or components either a visual regression test should be written for all permutations or the base image updated.
[ ] Changes or new components should either write new or update existing documentation.
[ ] PR should link and close out an existing issue

Looks like the preview build is not deployed

Tested in Firefox again. It worked as expected.


added some changes to make it clearer

Some grammar changes and a note about the rules not appearing.
Summarize the change in the pull request title
Describe your change, specifically why you think it's needed.
Fixes #Issue_Number (if necessary)

@NCBrady : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


All applications menu is not responsive

On mobile devices, the all applications menu goes off screen and cannot be scrolled.

Fixed #278


Improve dialog behavior

Closes #495
Dialogs are closed on click (instead of moving away with the mouse). The current column is highlighted, the rest is getting slightly darker. For the menu in the side panel the current option is highlighted, since there is no reference of the DOM element of the related column.

Looks good. I will test the new behavior once it is integrated.


Coverity badge always gets "inaccessible" status

Are you experiencing an issue with...

[x] shields.io
[ ] My own instance
[ ] gh-badges NPM package

:beetle: Description
The Coverity Scan badge for MD4C project always shows in a gray color with the status message as "inaccessible". Noticed this few days ago for the first time. But before that it used to work correctly for a long time.
I've just checked https://scan.coverity.com/projects/mity-md4c/badge.json and it seems to get the following JSON correctly:
{"project":"mity/md4c","status":"passed","message":"passed"}

:link: https://img.shields.io/coverity/scan/mity-md4c.svg?label=coverity scan

Thanks @mity taking a look now, will update when we have more info

Looks like there's an issue in the cert chain, below is the error we're getting internally:
Inaccessible: unable to verify the first certificate
Very similar underlying issue to #1956

I see.
Well, the question is whether it makes any sense to be stricter then browsers are.

Well, the question is whether it makes any sense to be stricter then browsers are.

This isn't due to anything we're doing explicitly. It's just the default behavior of many http clients. Why the browsers operate the way they do vs. those http clients is an entirely separate conversation 😄
The underlying issue is related to what sounds like a recently introduced issue in Coverity's certificate chain. We're mulling some options on if/how we could potentially work around such issues in the upstream services (like Coverity). However, ideally those services would resolve their certificate issues vs. us having to disable/relax ssl validation on our end.

This isn't due to anything we're doing explicitly. It's just the default behavior of many http clients. Why the browsers operate the way they do vs. those http clients is an entirely separate conversation 😄

Ok.

The underlying issue is related to what sounds like a recently introduced issue in Coverity's certificate chain. We're mulling some options on if/how we could potentially work around such issues in the upstream services (like Coverity). However, ideally those services would resolve their certificate issues vs. us having to disable/relax ssl validation on our end.

I can fully understand that. But my attempts to contact them (for some other minor issue like the service not working at all for some project) all failed, and I never got any response from them, so I am skeptical. :-(

Understood. I'll make sure that if we add a work around on our end that we include that support for our Coverity badge as well.

This affects one of my projects (bcal) too.

All Coverity badges are going to show as inaccessible due to an issue in the Coverity service's cert chain.
We may deploy a work around in the near future, but I'd still suggest that folks try to get in touch with Coverity to see if they can resolve those cert issues

Thanks for the quick response. I'll drop a mail right away. However, their response time is painfully slow in my experience.

FYI we've updated things on our end so that requests for Coverity badges will explicitly disable the strict ssl check, thus restoring Coverity.
Once #3336 is deployed to prod your badges will automatically start working again (this comment will track the status of that deployment).
For a visual, here's the two Coverity badges referenced above from our staging app:
https://shields-staging.herokuapp.com/coverity/scan/mity-md4c.svg?label=coverity scan

https://shields-staging.herokuapp.com/coverity/scan/jarun-bcal.svg

Thank you!

Thank you!


announcement: Profile UI Release

Please download the attached files and unpack them to file_server directory. In my case it is /dev/go/src/github.com/authcrunch/authcrunch-ui/frontend/profile/build/ and in your case it will be somet
The Caddyfile configuration follows:

auth.myfiosgateway.com {
	tls {$HOME}/.local/tls/myfiosgateway/server.crt {$HOME}/.local/tls/myfiosgateway/server.key

	route /version* {
		respond "auth 1.0"
	}

	# Vite Build Files
	route /auth/profile* {
		authorize with portal_policy
		uri strip_prefix /auth/profile
		file_server {
			root {$HOME}/dev/go/src/github.com/authcrunch/authcrunch-ui/frontend/profile/build/
			pass_thru
		}
		rewrite * /index.html
		file_server {
			root {$HOME}/dev/go/src/github.com/authcrunch/authcrunch-ui/frontend/profile/build/
			pass_thru
		}
	}

	route /auth* {
		authenticate with myportal
	}

	route / {
		redir https://{hostport}/auth/ 302
	}
}

Please provide your feedback via email. I will be uploading new versions of the Profile UI here. You should be able to track the versions in the UI itself.

Importantly, Profile UI is only available with local identity store at the moment. I am working on connecting OAuth user identities to local store, making the "local" store distributed, and making OAuth users being able to configure their profiles (e.g. API keys, MFA, etc.)

Profile UI 1.0.0 Assets: profile-1.0.0.zip

excellent work!


rename CEE to AG

Coverage remained the same at 100.0% when pulling e13e51ef41ab719732349499333dcb86098adc22 on updateHeaders into c22de093a8f42e24f54eb6f3fe7ec2dfb3d9f404 on master.

Coverage remained the same at 100.0% when pulling 69ef9c4d5d2a8d984f8ec480f6de50a1722f1132 on updateHeaders into c22de093a8f42e24f54eb6f3fe7ec2dfb3d9f404 on master.

Coverage remained the same at 100.0% when pulling 69ef9c4d5d2a8d984f8ec480f6de50a1722f1132 on updateHeaders into c22de093a8f42e24f54eb6f3fe7ec2dfb3d9f404 on master.


Replaced the broken link to libs.rs with...

one to crates.io (but it doesn't seem to work as a link, but at least it is the right thing to say).

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

hi @mark-summerfield ! in order to get the link to work as you have written it you'll need to add a link at the bottom of the page, something like [crates.io]: https://crates.io/. you'll probably also want to remove the link you are removing! lemme know if you need anything further help!
great find on the broken link btw! really appreciate this PR :D

I've added the change you suggested but don't know what I'm supposed to do next.

great- this looks perfect except now we just need to remove the [libs.rs] link down on the bottom. once that is done i can merge this and it will be shipped! thanks again :D


flutter run -d chrome --flavor <flavor> runs without error but flutter build web --flavor results in tool exiting

Flavors are only an officially supported feature for Android, iOS, and (indirectly) MacOS. Running flutter build web --flavor strawberry will result in the tool exiting with this message:
Could not find an option named "flavor".

Run 'flutter -h' (or 'flutter <command> -h') for available flutter commands and options.

However, one can run flutter run -d chrome --flavor strawberry, and the app will run without issue. At best, this is potentially confusing. At worst, it could result in Flutter accidentally supporting flavors for web if/when we add more flavors-related features to the framework.
We should also exit the tool when the user tries to use --flavor with flutter run -d chrome.
I recommend resolving this before implementing #21682

Next step: see if this is the case on the other platforms where flavors are not a supported feature. This includes Windows and Linux. We can then unify the behavior. For example: if flutter build --flavor results in a ToolExit on all of these platforms, then I think we can go ahead and make flutter run --flavor ToolExit as well.

Next step: see if this is the case on the other platforms where flavors are not a supported feature. This includes Windows and Linux. We can then unify the behavior. For example: if flutter build --flavor results in a ToolExit on all of these platforms, then I think we can go ahead and make flutter run --flavor ToolExit as well.

As of ead455963c12b453cdb2358cad34969c76daf180, I have confirmed that the behavior is indeed the same for Linux and Windows. If we do believe that flutter run --flavor should result in a tool exit with these host platforms, then the last thing to decide is whether this tool exit should be implemented in an inclusionary or exclusionary fashion.


Recipe list selection crash

Crashed happened while playing with the mod Krastorio 2 and clicking on "Coal" in the recipe book's selection list. I have not been able to reproduce the error after the first crash.
The mod Recipe Book (1.3.5) caused a non-recoverable error.
Please report this error to the mod author.
Error while running event RecipeBook::Custom event (ID 172)
RecipeBook/scripts/gui/info-base.lua:166: attempt to index local 'object_data' (a nil value)
stack traceback:
RecipeBook/scripts/gui/info-base.lua:166: in function 'update_contents'
RecipeBook/scripts/gui/info-base.lua:96: in function 'open'
RecipeBook/scripts/gui/info-base.lua:191: in function 'open_or_update'
RecipeBook/control.lua:182: in function <RecipeBook/control.lua:161>
[C]: in function 'raise_event'
flib/event.lua:126: in function 'raise'
RecipeBook/scripts/gui/search.lua:88: in function 'handler'
flib/gui.lua:352: in function 'dispatch_handlers'
flib/gui.lua:138: in function <flib/gui.lua:138>
stack traceback:
flib/event.lua:126: in function 'raise'
RecipeBook/scripts/gui/search.lua:88: in function 'handler'
flib/gui.lua:352: in function 'dispatch_handlers'
flib/gui.lua:138: in function <flib/gui.lua:138>
stack traceback:
[C]: in function 'raise_event'
flib/event.lua:126: in function 'raise'
RecipeBook/scripts/gui/search.lua:88: in function 'handler'
flib/gui.lua:352: in function 'dispatch_handlers'
flib/gui.lua:138: in function <flib/gui.lua:138>

I cannot reproduce this either. Please update me if you manage to crash it again!


Attempt to copy iomem.ld to $OUT_DIR only if it exists

This allows removing empty iomem.ld files from the repository.
Eventually all examples will be migrated to ioregs! macros and the code
snippet from build.rs can be removed.

Thanks for a cleanup!


Enable gcov coverage and set up codecov.io

I just did this in Parquet https://github.com/apache/parquet-cpp/commit/fdbe437b1b6e85385a41a0038637cc4c87d4d640 so we can adapt that here

Done in https://github.com/wesm/feather/commit/d0f997aa8c458b891c23376851f6e1fa5c1034d3, thanks @jimhester!


TS errors after switching from webpack's Module Federation to Module Fedaration V2

Describe the bug
Hello,
After switching to latest Module Federation version (from webpack's built in federation, to module-federation v2), I started seeing various errors related to types, for example
TS Error 2742':' The inferred type of 'testFunction' cannot be named without a reference to '.pnpm/@tanstack+query-core@5.29.0/node_modules/@tanstack/query-core/build/legacy/queryClient-K0zFyarY'. This is likely not portable. A type annotation is necessary.
Federated types created correctly
Reproduction
not yet
Used Package Manager
pnpm
System Info
mac

Validations

[X] Read the docs.
[X] Read the common issues list.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Module federation issue and not a framework-specific issue.
[X] The provided reproduction is a minimal reproducible example of the bug.

@manvydas-tbol  provide a repo


Request support for Motion Sensor -T -W8

Generic motion sensor: https://www.amazon.com/dp/B08T6ZSST1
AKA: NEO Coolcam Smart PIR Motion With Temperature Humidity Sensor Wifi USB Charge
Unable to retrieve logs. Tried the dump script and got not reply.
INFO:localtuya:localtuya version 1.0.0
INFO:localtuya:Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
INFO:localtuya:Using pytuya version '10.0.0'
INFO:localtuya:TIMEOUT: No response from device after 2 attempts.
Pings are inconsistent, device sleeps a lot to save power.
64 bytes from <IP_ADDRESS>: icmp_seq=523 ttl=255 time=20.3 ms
64 bytes from <IP_ADDRESS>: icmp_seq=524 ttl=255 time=2020 ms
64 bytes from <IP_ADDRESS>: icmp_seq=525 ttl=255 time=1007 ms
64 bytes from <IP_ADDRESS>: icmp_seq=526 ttl=255 time=5.36 ms
64 bytes from <IP_ADDRESS>: icmp_seq=527 ttl=255 time=8011 ms
64 bytes from <IP_ADDRESS>: icmp_seq=528 ttl=255 time=7011 ms
64 bytes from <IP_ADDRESS>: icmp_seq=529 ttl=255 time=5987 ms
64 bytes from <IP_ADDRESS>: icmp_seq=530 ttl=255 time=4964 ms
64 bytes from <IP_ADDRESS>: icmp_seq=535 ttl=255 time=593 ms
64 bytes from <IP_ADDRESS>: icmp_seq=536 ttl=255 time=1872 ms

No logs found

Information about DPS mappings

{
  "result": {
    "category": "pir",
    "functions": [],
    "status": [
      {
        "code": "pir",
        "dp_id": 1,
        "type": "Enum",
        "values": "{\"range\":[\"pir\",\"none\"]}"
      },
      {
        "code": "battery_percentage",
        "dp_id": 4,
        "type": "Integer",
        "values": "{\"unit\":\"%\",\"min\":0,\"max\":100,\"scale\":0,\"step\":1}"
      },
      {
        "code": "temper_alarm",
        "dp_id": 5,
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "temp_current",
        "dp_id": 7,
        "type": "Integer",
        "values": "{\"unit\":\"℃\",\"min\":-100,\"max\":1250,\"scale\":1,\"step\":1}"
      }
    ]
  },
  "success": true,
  "t":<PHONE_NUMBER>977,
  "tid": "1d1a406bc43311eda2c5dae7169ea2b8"
}

"product_id": "vtdhft75lhnreqk8"

Very simple binary PIR motion sensor, with added temperature and humidity.

device sleeps a lot to save power.

Unfortunately that is a dealbreaker when it comes to local use.


Handle datasets where position recording is disabled

For some metadata files the PLC control is disabled and no xyz position is being recorded:
"gantry_system_variable_metadata": {
      "only small set of meta data available": "measurement was done during sensor setup",
      "timestamp": "05/15/2018 09:00:33",
      "PLC control not available": "no gantry position data"
    },

This currently causes failure on metadata cleaning process and datasets are not being uploaded to Clowder. We need to catch this.
First thought after discussion with @craig-willis is we include entry in cleaned metadata indicating no position info, then update extractors that expect it to gracefully exit. Later we could modify bin2tif to generate geotiffs without georeferencing if there could still be value in them.

@max-zilla I reviewed 05/15 directories in the cache and can confirm that this was a test of the FLIR camera in single-image capture mode rather than scan mode.  There's no need to process these types of images - they're for local use to determine how the camera is operating.  It's probably safe to make a processing rule that if there are files like this in the future with "no gantry position data" they don't need to be put on Clowder or processed in any way.
If in the future we do something like a calibration test and want the image(s) to be processed we can run in scan-mode which will enable the PLC and provide position data.

Known condition - we don't have good error handling
Per Maria - recommendation is not uploading data into clowder
Per Team evaluation - we should not have it in an error state in Globus Monitor
We would need to create a handler to record there is raw data that is not processed
Not a priority for next sprint - but is an operational concern and should be addressed
Solution - gracefully skip position as not available and mark as error in POC
Set should be passed on to rule checker - make determination - add to bad scan directory


Required package React-Native-Push-Notification is no longer maintained

This implementation is no longer working in our production app. Not sure what to recommend, but with the above package no longer being maintained, there is no longer a documented way to reliably implement cross platform react-native push notifications using Azure notification hubs. Notifee seems to be the recommended replacement for the expired package, but it only supports notifications through FCM, and ANH doesn't seem to support iOS notifications for FCM. If there's a way to use ANH without the dead package, I'd love to see this doc updated with that info. Right now I'm considering replacing ANH with FCM, but that would be a ton of work both client and server side.

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

ID: 60458a66-21b6-1ace-2626-99faaa2e7fc6
Version Independent ID: 9b339fcf-7c2f-b2e5-d9ca-00c0187f7062
Content: Send push notifications to React Native apps using Azure Notification Hubs via a backend service
Content Source: articles/mobile-apps/notification-hubs-backend-service-react-native.md
Service: mobile-services
GitHub Login: @alexeystrakh
Microsoft Alias: alstrakh

Having the same issue here. Thank you for looking into this!

Closing this issue due to staleness. We apologize for the delayed response. If you are still encountering the problem you've described, please re-open the issue within 2 weeks and we'll take a look. Thanks!
#label:"UUF-Stale-Not Planned"


FancyZones UI is awful

Description of the new feature / enhancement
FancyZones UI is terribly unintuitive.  It needs rethought.  Every time I attempt to use it I can't figure it out.  The editor seems to overlay everything and trying to drag n drop an open panel I find next to impossible.  The interaction between the existing windows and the editor is convuluted.  And once you've created a setup it's supposed to automatically open it next time...how?
Scenario when this would be used?
I love the idea of FancyZones it just needs a better more intuitive UI.
Supporting information
Maybe first off just have the editor be another window rather than covering the entire display.  How about inverted the theory.  Setup a display with the programs you want by dragging their boundaries to the desired spot.  Click save to create your FancyZone and create a shortcut on the desktop that would open the named FancyZone and the associated apps into the proper layout.

I literally googled for "fancy zones awfull ui" after pulling my hairs out within 10 minutes of trying to make some simple changes to get a basic 3 panel layout.
Literally everything works the opposite of one would intuitively expect, so please fix this asap.


Add createauxblock and submitauxblock rpc for auxpow

Add rpc createauxblock and submitauxblock methods for easier integration with mining pools.
Fixed issue with erroneously moved LOCK in getauxblock
Disabled mining of witness tx as done for getauxblock

Action workflows should be disabled until someone is willing to update the build scripts. Self building from source works fine as it should.

These changes are also available within #29 which could be used instead after a full review.


fix: dead github workflows | spell-check-differential

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I've agreed with the maintainers that I can plan this task.

Description
Currently, spell-check-differential is one of the CI executed by pull requests as a trigger.
However, since there are too many cspell errors, the error is almost ignored when pull-request is merged.
So, it is desirable to reduce typos and revive spell-check-differential workflow!
if we archieve zero cspell errors, we have the option to set the CI to "required".
Purpose
To revive the dead spell-check-differential workflow
Possible approaches
We can...

fix the typos
add the words to dictionary
add ignore comment inline

We can track the number of entire cspell errors by spell-check-all workflow
Definition of done
Pass the spell-check-all workflow

https://github.com/autowarefoundation/autoware.universe/pull/4280

Errors: 730
main@2023/07/18 1:55P.M. JST

We introduced spell-check-partial workflow to make spell-check "required" step by step.
https://github.com/autowarefoundation/autoware.universe/pull/4320

@kminoda is trying to test the spell-check-partial is works fine!
https://github.com/autowarefoundation/autoware.universe/pull/4321
https://github.com/autowarefoundation/autoware.universe/pull/4329
https://github.com/autowarefoundation/autoware.universe/pull/4331
and he also prepare for actual operation of spell-check-partial!
https://github.com/autowarefoundation/autoware.universe/pull/4327

Errors: 668
main@2023/07/19 11:31 A.M.
This pull request works great for the reduction of errors this time!
https://github.com/autowarefoundation/autoware.universe/pull/4281

WIP for next error observation
https://github.com/autowarefoundation/autoware.universe/pull/4332

Memo
spell-check-partial has been made required

Errors: 667
main@2023/07/19 22:22
https://github.com/autowarefoundation/autoware.universe/pull/4332

Errors: 695
main@2023/07/22 1:30 JST

Errors: 689
main@2023/07/22 10:25 JST

Errors: 680
main@2023/0724 14:39 JST

spell-check-partial is enabled for localization!
https://github.com/autowarefoundation/autoware.universe/pull/4377

spell-check-partial is enabled for docs, simulator, tools, and vehicle!!
https://github.com/autowarefoundation/autoware.universe/pull/4327

Errors: 526
main@2023/0726 14:42 JST
https://github.com/autowarefoundation/autoware.universe/pull/4289

Errors: 517
main@2023/07/27 11:15 JST

spell-check-partial is enabled for common
https://github.com/autowarefoundation/autoware.universe/pull/4397

Errors: 501
main@2023/07/28 12:07 JST
https://github.com/autowarefoundation/autoware.universe/pull/4403
https://github.com/autowarefoundation/autoware.universe/pull/4404
https://github.com/autowarefoundation/autoware.universe/pull/4406

spell-check-partial is enabled for system
https://github.com/autowarefoundation/autoware.universe/pull/4460

spell-check-partial will be enabled for launch and evaluator
https://github.com/autowarefoundation/autoware.universe/pull/4462

Errors: 476
main@2023/08/02 9:13 JST

Errors: 476
main@2023/08/02 9:13 JST

Errors: 477
main@2023/08/07 11:45 JST

Errors: 476
main@2023/08/09 17:41 JST

Errors: 476
main@2023/08/10 10:16 JST

Errors: 434
main@2023/08/18 14:56 JST
#4613

Errors: 430
main@2023/08/21 14:04 JST

Spell-check errors for each components (and some major packages) as of 2023/08/21

perception: 292

perception/bytetrack: 233 (already ignored in spell-check-partial)
perception/radar_object_tracker: 28

planning: 106

planning/sampling_based_planner: 39

sensing: 32

Errors: 372
main@2023/08/22 10:48 JST

Errors: 328
main@2023/08/23 9:57 JST
https://github.com/tier4/autoware-spell-check-dict/pull/616

Errors: 305
main@2023/08/24 17:52 JST
https://github.com/autowarefoundation/autoware.universe/pull/4716


docs/Maintainer-Guidelines: add lead maintainer guidelines.

I've tried to write up a description of what I think the lead maintainer of Homebrew should (and should not) do.
@Homebrew/maintainers I'd love your feedback on this; what do you think of what's written and is there anything else you'd like me to be doing (or think I should be doing) that I'm not?

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

This person should (sparingly) be the tiebreaker for decisions where a mutual consensus cannot be reached amongst other maintainers.

tiebreaker implies that decisions are made by a majority vote, and the lead's vote simply breaks the tie. If that's the case, then I'd suggest clarifying elsewhere in the document that decisions are decided by a majority vote of the maintainers. If however it's less formal and is decided instead by a consensus of the maintainers, and the lead has the ultimate say, I'd suggest something like…

Decisions are determined by a consensus of the maintainers. When a consensus is not reached, the lead maintainer has the ultimate say in determining the outcome of any decision, though this power should be used sparingly. We aspire for most decisions to be reached by unanimous consensus.

The difference being that in the former case the majority of the maintainers have the ultimate say. In the latter case the lead has the ultimate say in every decision, and their decision is (strongly) informed by the maintainers.

Perhaps there should be something in there about fundraising or where does that fit in ?

@javian Yeh, I think building partnerships and getting sponsorships should be part of the role 👍
@sjackman Good questions; I'm not quite sure. They way I see it in theory at least the lead could overrule literally all the other maintainers. Obviously that wouldn't be practical or sensible, though, so isn't something I'd plan on doing. I don't think any sort of formal vote or consensus works for technical/product/design changes because the consequences aren't shared equally amongst the maintainers. Thoughts?

This should do nothing positive for my popularity, but on the record as (I believe) the only maintainer  in this thread thus far who was present when the lead maintainer system was formalised, I think over time it has proven to be a mistake and I have regrets around lending it my indifference/tepid support back when it was being discussed initially.
It's not like before the system was introduced anyone was in any doubt about who was essentially the "face" of the project or who should be consulted on changes to the brew side of the codebase. Everyone knew to check in with Jack or Mike on major brew ideas/changes/etc, it was hardly anarchy around here, but I also think back then there was a healthier atmosphere around being able to disagree.
I think formalising the role has made it feel at times like it is pointless trying to push back against the lead maintainer, and it has also undermined a contribution-based "power structure" because it lets people pull the lead maintainer into conversations as a weapon against ideas they support/do not support and suspect or know the lead maintainer feels the same way, even where that idea is driven by a maintainer with more experience or knowledge of a subject than those who object.
I tend to keep my mouth shut about lead maintainer stuff because I view it as being a sailed ship, and there's little point trying to convince a ship to return to harbour months or years after the fact, but since feedback was requested, this is me. I know through experience & conversation the formalisation of the lead maintainer role has played a not insignificant part in maintainers becoming mentally/emotionally exhausted and stepping away from the project, or thinking about stepping away from the project, and whilst it wasn't the primary reason I certainly don't exclude myself from that when I left for a chunky period of time in late 2016.
It remains the case that on subjects where we disagree I question the value of me investing time into discussing those disagreements. I also note here in closing that I think the issues with the system would persist whoever occupied the role; I'm not attempting to poop in your dog basket here, you know the level of respect I have for you and the level of gratitude I have for the time you've invested in me, but nonetheless I think the formalisation of this "lead maintainer" role has been problematic and I regret my part in it becoming a thing.
Since we're stuck with it though, this PR in itself is fine.

I have to agree with @DomT4's sentiment here. Especially this doesn't seem right:

They way I see it in theory at least the lead could overrule literally all the other maintainers.

This should not be possible even in theory.

This should do nothing positive for my popularity

To be clear: I opened this PR to solicit opinions on this so it's not going to make anyone more or less popular because they criticise my current or past decisions. I'm a big boy and I can handle criticism without taking it personally or disliking the person who expresses it.

It's not like before the [lead maintainer] system was introduced anyone was in any doubt about who was essentially the "face" of the project or who should be consulted on changes to the brew side of the codebase.

I don't agree, actually; it's the difference between explicit and implicit hierarchy.
Some random but related history: when @mxcl left the Homebrew project he told me that I was in charge now. In response, I told him that it would be a bad idea and I was going to make sure it was run as a democracy. Similarly, when I joined GitHub around a similar time it was a "no management culture" where there were hundreds of employees but only the e.g. CEO/CTO above them.
Both approaches were abandoned because they didn't work; it wasn't clear to either newcomers or people external to a project who had the responsibility or ability to make final decisions so decisions often weren't made at all.
With a flat structure or democracy in an open source project you end up with a situation where the loudest (or, sadly, most willing to be nasty) voices "win" and I don't think that's more healthy than having someone in a formal position of leadership.
We're not a corporation, for sure, but we should aspire to be creating great software with a degree of professionalism and that requires leadership. Hell, we're all using Apple products here: do any of us think a completely democratic, non-hierarchical approach would have produced the Apple products we like using?

I also think back then there was a healthier atmosphere around being able to disagree.
I think formalising the role has made it feel at times like it is pointless trying to push back against the lead maintainer

I'm going to assume this isn't about me specifically but I'd like you or others to dig in more specifically on what is stopping maintainers from expressing disagreement with each other or with me. You don't have to spend long looking on PRs in here before you'll find my disagreements with people where they successfully convince me to change my mind and I do.

it lets people pull the lead maintainer into conversations as a weapon against ideas they support/do not support and suspect or know the lead maintainer feels the same way, even where that idea is driven by a maintainer with more experience or knowledge of a subject than those who object.

This applied and applies even without the lead maintainer position but what ended up happening was a bunch of issues and PRs descending into "well, we can't see to agree on a decision so we'll do nothing" which seem worse to me than making a decision, even if it's not the preferred one for everyone.

I also note here in closing that I think the issues with the system would persist whoever occupied the role; I'm not attempting to poop in your dog basket here, you know the level of respect I have for you and the level of gratitude I have for the time you've invested in me, but nonetheless I think the formalisation of this "lead maintainer" role has been problematic and I regret my part in it becoming a thing.

Again, to be explicit, it was supported by a majority of maintainers when it happened.

I would not like to be lead maintainer of the project forever. Much as I've enjoyed automating myself out of the job in the past I would like to pass on the baton one day to someone else who shows leadership and ownership not just for the Homebrew/brew codebase or Homebrew/homebrew-core formulae but the entire Homebrew organisation, community and ecosystem. If that's a group of people or someone who decides to product some flattened structure and convinces me that they can do as good or a better job: great, I'll happily hand it over.

As a new/first time maintainer, I don’t understand the mechanics/process of how one becomes the lead maintainer. The thought of ANY generic lead maintainer having ultimate power does trouble me. I also agree with @DomT4 that there will be a potential chilling effect if it seems like decisions can be unilaterally overruled (especially if done so in a seemingly arbitrary or capricious manner) by a lead maintainer. Whether or not it is a bad idea, the right person in the right environment can quickly discard norms and the usual sense of decorum, unless there is some codification of the limits of their power as well. I do agree with Mike, that, at the same time, we do need someone with some central and meaningful authority to make decisions, and have additional ownership and leadership. I’m not sure what the best balance of power between one central, and hopefully wise/experienced executive authority and a larger governing body is, but it probably lies somewhere between unilateral ultimate authority and a simple majority.
The codification and implementation of rules and bylaws is good to do before you need them whenever possible. When a conflict arises, if the extent and also the bounds of an executive's authority are not codified and well defined, it could result in inaction/stalemate if insufficient authority is invested in them or, conversely, if excessive and/or poorly defined powers are granted them, they could throw decorum to the wind and act to consolidate additional powers or abuse the limits of their power because those were poorly defined.
I am not concerned (at least overtly, but then again I'm new here 😜) with Mike's potential for abusing his executive powers, but who knows what the next lead maintainer's personality/motives will be. Having well codified by-laws or governing procedures with the right balance of power (maybe require a supermajority needed to overrule the lead maintainer?) and the right degree of formalization may be important, if not under Mike's reign, then at least in the future. (Software people have been known to go off the rails from time to time after all. C.F. John McAfee and Hans Reiser for example)
TL;DR: My preference is probably for requiring a substantial supermajority to overrule the lead maintainer, and additional formalism on governance, primarily as a means to mitigate/resolve conflicts in the future in a clear & fair way. But I may be ignorant of existing formalism/by-laws etc.

Since it hasn't been brought up yet the project has a code of conduct that has been established for a while which is based on being open, respectful and considerate which would of course apply to whomever held the flag. I haven't been around long enough (or involved in the right places) to personally have noticed that the way its working is an issue.

I also second @javian - if there is a code of conduct in force, it would be great to bind the guidelines to it.

I thought this was implicit but I can make it explicit to all maintainers.

believe any sort of decision which lead to (established) precedent, especially contentious ones, should be clearly documented somewhere. Perhaps you could set this in writing?

I'm not sure I understand this. Can you provide an example of what you'd like documented?

I'm not sure I understand this. Can you provide an example of what you'd like documented?

Of course. I (now) know that Cask's policy is not to include all possible languages, only those that are requested on a case-by-case basis. But where/how/why was this decided? It should not be necessary, especially for first time contributors, to dig through old issues to figure out precedent.

So any decision made by the lead maintainer should be documented after the fact or just decisions that e.g. may come up in future/affect contributors?

The latter.

Alright. I didn't necessarily intend to start a huge debate but since I did I guess I shouldn't vanish into the ether.

but we should aspire to be creating great software with a degree of professionalism and that requires leadership

I think there's automatically a degree of leadership in active maintainership though, and a system where there is one overarching leader for everything doesn't really make sense.
On core stuff for example I'd argue it makes little sense for you to be the final decision maker there, because you're quite divorced from having to maintain core on a daily basis (which is something I think you'd freely admit yourself). Equally I'm not about to tell anyone how to implement Cask changes, and FX (by FX's own admission) isn't about to tell anyone how to configure Jenkins, etc etc.
Nobody is "in touch" with absolutely every element of Homebrew on a daily basis because nobody has that much time in life, and consequently I don't think it's logical to have a system where one maintainer has ultimate & untouchable authority over every aspect of Homebrew.
I also think it's dangerous on some level, because (for example) major Jenkins/CI operations almost always fall on you, and that has been the case for years now. Nobody else has proactively stepped up to a significant degree there because nobody has needed to, but if you get whacked by a bus tomorrow (please don't, I add) suddenly there's this gaping hole in the project that would be immensely difficult to fill. That's not a healthy position for Homebrew to be in.

Hell, we're all using Apple products here: do any of us think a completely democratic, non-hierarchical approach would have produced the Apple products we like using?

FOSS contribution, and maintainership, should ultimately be a reasonably consistently enjoyable experience though.
As much as I admire Steve Jobs, Tim Cook, etc and as much as I'd have willingly subjected myself to being tossed into that lake of fire the Book of Revelation is super fond of mentioning if it meant being able to work with either of them or others like them, I'm not sure it helps our cause to aspire to emulate work environments that are likely extremely stressful.

I'm going to assume this isn't about me specifically

Correct. My intention in using the title rather than your name was to make it clear the concerns were not personal.

others to dig in more specifically on what is stopping maintainers from expressing disagreement with each other or with me

Mostly for me it's the idea of pointless effort. If I talk about an idea with FX, Com, Misty, Jan, etc etc and everyone loves the idea and I pour a small mountain of effort into implementing said idea knowing there's team support behind that idea you retain this ultimate power to flatly reject it, regardless of how many others are in favour. Even the concept of that happening is quite demoralising in some ways.
The other way around is a concern as well. You could presumably, by your own admission, implement changes nobody else supported and are in no way obligated to discuss those changes with the team or revert those changes even in the face of overwhelming opposition. Again, not personal, I don't expect such actions from you, but nonetheless that you have the capacity to do so leaves a door open that should probably not be open. Precedent is important and however benevolent you are as you've said you may not always occupy the role and the next person may end up being less so.
==
I think in terms of actionable items, I would like to see the aforementioned door closed and formalise some way for the lead maintainer to be overruled in necessary circumstances. I guess technically it's possible the PLC serves as such a mechanism today but I consider it more sustainable if there's a way for maintainers who don't sit on the PLC to overrule the lead maintainer. I don't think it's a power that should be invoked frequently but I think it should formally exist.
I also think it should at least become the norm that maintainers do not close other maintainer's PRs without the consent of that maintainer or other reasonable grounds. If a discussion reaches an absolute deadlock or is running itself around in circles I think that allows the lead maintainer to step in but if a discussion is ongoing I feel like it's an overreach of authority for the lead maintainer to essentially terminate that discussion.

I'm not going to address every point but there's a few things here that I think are important.

On core stuff for example I'd argue it makes little sense for you to be the final decision maker there, because you're quite divorced from having to maintain core on a daily basis (which is something I think you'd freely admit yourself).

I've still maintained core for a long enough time and read enough going on there to have context there. I still have more commits in there than any other active maintainer (although you're close 😉). I don't think that becomes meaningless because I've delegated more of the day-to-day on that tap to others.

Nobody is "in touch" with absolutely every element of Homebrew on a daily basis because nobody has that much time in life, and consequently I don't think it's logical to have a system where one maintainer has ultimate & untouchable authority over every aspect of Homebrew.

I'm not saying anyone should be in touch with all of Homebrew on a daily basis but I am saying if we want to do away with a lead maintainer we need to have people who are going to step up and take responsibility for following the majority of repositories in the Homebrew org and making sure things that the community rely on like Homebrew/homebrew-bundle and Homebrew/formulae.brew.sh keep running.

As much as I admire Steve Jobs, Tim Cook, etc and as much as I'd have willingly subjected myself to being tossed into that lake of fire the Book of Revelation is super fond of mentioning if it meant being able to work with either of them or others like them, I'm not sure it helps our cause to aspire to emulate work environments that are likely extremely stressful.

You're missing my point here; literally almost every single organisation in the entire world and entirety of human history is hierarchical and has a "buck stops here" leader at the top. This includes most democratic institutions!

I think in terms of actionable items, some of which have already been mentioned, I would like to see the aforementioned door closed and formalise some way for the lead maintainer to be overruled in necessary circumstances. I guess technically it's possible the PLC serves as such a mechanism today but I consider it more sustainable if there's a way for maintainers who don't sit on the PLC to overrule the lead maintainer. I don't think it's a power that should be invoked frequently but I think it should formally exist.

The PLC is literally the "project leadership committee". There's a clear criteria for joining it (partly because of the amount of work for me personally in adding and removing people constantly) and if there's anything that replaces the lead maintainer position it will be that.
To be clear, though, I'm the one who did all the work to get us to join the SFC, I'm the one who arranged with them to setup the PLC, I'm the one who nagged people to submit the necessary paperwork to join it and have documented them taking responsibility for appointing new maintainers rather than it being just up to me.

I also think it should at least become the norm that maintainers do not close other maintainer's PRs without the consent of that maintainer or other reasonable grounds. If a discussion reaches an absolute deadlock or is running itself around in circles I think that allows the lead maintainer to step in but if a discussion is ongoing I feel like it's an overreach of authority for the lead maintainer to essentially terminate that discussion.

That's a fair ask. What I'm going to ask you specifically @DomT4 and other maintainers in this thread who don't like the status quo is to submit a PR with a documentation change for discussion. Anyone who is not willing or able to make a concrete proposal of what should change doesn't really have the right to complain about it. I don't think it's reasonable to expect me to put in a bunch of frankly boring and time consuming work to do this when I know what can of worms will be opened by my doing so.

Slightly off topic here I'm a bit disappointed by some of the tone and comments here. As I have mentioned before, many of you wouldn't be maintainers at all were it not for me overruling other maintainers which have since left to have you join the project. Multiple of you have benefitted materially or financially in your personal lives from where I've reached out to help you with things. Most of you have at some point asked me to join in and help out in a discussion where you wanted my input. Any time you do your work as a maintainer you're relying on tooling I personally built to make maintaining Homebrew easier for you to do so (again, often overruling other maintainers in doing so).
In short, it feels like people are happy to have me do what I do in practice but not in theory; as long as it helps you accomplish your current goal you'd like to have me use my position to help but as soon as I disagree you want to constrain my ability to do that in future. It's a pretty shitty feeling, honestly, and I'm disappointed to be made to feel that way in a thread where I've been trying to document what I do in order to be held more accountable to be repeatedly accused of being unaccountable.

I'm unsure what more I could have done to depersonalise my concerns here. I tried very very hard to strip away anything that could be considered an attack on you personally and highlight that my concerns predate the creation of the role even. You have the rest of my response privately.
I welcome the idea of a PR being filed on codifying the powers of the lead maintainer & limit of those powers and I'm happy to help draft such a document. If we've reached a point where we need to get all "constitutional convention" about things, that's regrettable, but so be it.

I'm unsure what more I could have done to depersonalise my concerns here.

At some point if you're going to criticise a position that's held by a person: that person is going to take some of what you say as a personal critique.

I welcome the idea of a PR being filed on codifying the powers of the lead maintainer

That's literally what this PR is and I've addressed everything actionable that was proposed. No-one has commented on the individual lines that I've written here.

If we've reached a point where we need to get all "constitutional convention" about things, that's regrettable

I'm not sure I understand why from your perspective that would be regrettable? If this is a problem: should there not be an attempt at addressing and discussing it? If it's not a problem: why bring it up in the first place?

I don't think it's helpful for us to have two active, inevitably quite heavy & emotionally-taxing discussions running concurrently so I will refrain from further comment in this one. From the private discussion I will work on whatever steps I wish to take next, and of course, other people are welcome to leap over me with whatever steps they feel are necessary or desirable. That's where I'm leaving my part in this thread.

@maxim-belkin Thanks for lifting the spirits!
Locking the thread. Important things were said but the PR is now merged.

Ref Mike's follow-up: https://github.com/Homebrew/brew/pull/4846.
Ref my follow-up: https://github.com/Homebrew/brew/pull/4864.
This discussion remains & will remain locked, but since locking disables GitHub's automatic linking, there be the links for reference.


673 | Number of Longest Increasing Subsquences | C++

Number of Longest Increasing Subsquences -
What will change -Addding New Code
Type of Issue -
Please add/delete options that are not relevant.

[x] Adding New Code
[] Improving Code
[] Improving Documentation
[] Bug Fix

Programming Language
Please add/delete options that are not relevant.

[] Python
[x]C++
[] Java
[] SQL

Self Check

Ask for issue assignment and wait to get assigned to it before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Discord server ✉ - https://discord.gg/CXksGdn
Happy Coding,

Please assign me this issue


openshift: increase loglevel for control plane components

Needed for debugging existing flakes. As per yesterday's arch call discussion, we agreed to bump the loglevel for now and can revisit later.
/assign jim-minter pweil-
/label orchestrator/openshift
/approve

/approve

/label orchestrator/openshift

/label orchestrator/openshift

nit/question otherwise looks fine

/lgtm


CARDS-1441: Upgrade material ui and mui/lab to version 5+

Testing instructions

All functionality in all projects on all screen sizes needs to be tested
Due to mui v5 changes, gray color for buttons is no longer supported, and the default color is primary (dark blue). We replaced the gray look with outline variant. Check that button color/variant is appropriate across the app (all Close/Cancel buttons should be outlined).

Note that some buttons have intentionally changed color (e.g. "Healthcare provider" on the DATA-PRO landing page, "Decline" in the DATA-PRO Terms of use dialog, "Delete" in the deletion confirmation dialogs)

Known issues

The properties listing appears too condensed in the questionnaire wizard - not a blocker, can be adjusted as part of 1767.

The ResourceHeader (used on form pages and questionnaire pages) is now shifted to the top-left and looks misaligned with the rest of the page

Fixed in 9cc23c1.

Livetables: the action buttons Edit and Delete now have different sizes and are misaligned
Subject pages: the menu looks too small/crowded due to the buttons being of size medium instead of large

Fixed in dd12d0e.

A few buttons that used to have the default (gray) color now have the primary (midnight blue) color.

Addressed in 32e66e8 by setting variant="outlined" to all the buttons that had color="default" removed in previous commits on this branch. There may be buttons that did not have color="default" explicitly specified. Those need to be detected and updated when testing the entire UI.

[MAJOR] On forms with QuestionMatrix entries (e.g. SF-12 in -P proms or Question Matrix Test in --test) there seems to be some strange kind of styling failure

Fixed in 8dbd8f5 by updating the imports in omitted file QuestionMatrix.jsx to mui 5.

[MAJOR] Attempting to edit a Concept Recognition Test form fails with white screen and console error
[BLOCKER] Attempting to add a question in a new questionnaire in the designer fails with white screen and console error
[BLOCKER] Attempting to move on to the second page of a "Pagination Test" form fails with white screen and console error

Fixed in c7d76b9 by updating two <Button>s which still had color="default", causing js console errors and white screens.

[BLOCKER] Clicking on the info buttons when browsing vocabulary terms no longer displays the info box
Fixed in https://github.com/data-team-uhn/cards/pull/1045/commits/afa631975a9b3858eda73f5f03cdaab2e3ff770d

A few buttons that used to have the default (gray) color now have the primary (midnight blue) color.

Set variant="outlined" to all buttons that didn't have a color set (defaulting to gray in v4) in 79ea6da.

Some text fields have turned from underlined to outlined (vocabulary table filters) or from outlined to underlined (install vocabulary from local file). We should decide which variant to settle on.

Reverted the subject identifier input (in the Subject selector dialog) and vocab keyword search input (in the vocab admin screen) to outlined in 63d1735. The inputs in the form for installing a vocab from a local file look fine with variant="standard". The inputs for vocabulary table filters should be reverted, but appear trickier to change at this time so we'll leave them as they are for the time being.
Also upgraded the downtime-warning-banner module (brought in by dev merge-in but ommitted from upgrade) to mui v5 in 2021032.

The inputs for vocabulary table filters should be reverted, but appear trickier to change at this time so we'll leave them as they are for the time being.

Implemented simpler-looking filter inputs in a925672.

There is one known outstanding issue, which is not a blocker:

Sections with displayMode: header are sticky to a position slightly lower than they should be

@sashaandjic This branch is now ready for testing.

Sections with displayMode: header are sticky to a position slightly lower than they should be

Fixed in 960b839. The positioning was inaccurate even before the upgrade, but the change in how Grid items are spaced within the Grid container in 5+ made the issue more prominent post upgrade.

BLOCKER: The narrow-screen layout is slightly broken - the user avatar and menu are visible even though they should not be

Fixed in a8e7282 and 9734509.

a small inconsistency:

a small inconsistency

Fixed in e8560cf .

The buttons have different alignments

The last one is intentional. Just because our secondary color happens to currently be a a shade of red doesn't mean it's right to make DELETE a secondary action. However, now in mui5+ it's easy to use other theme colors for buttons, e.g. "error" if we wish to make it red so that we draw attention to it. @sashaandjic do you want do do that? I'm fine either way.

PrintPreview CLOSE button fixed in 5c1aa3a.

The last one is intentional. Just because our secondary color happens to currently be a a shade of red doesn't mean it's right to make DELETE a secondary action. However, now in mui5+ it's easy to use other theme colors for buttons, e.g. "error" if we wish to make it red so that we draw attention to it. @sashaandjic do you want do do that? I'm fine either way.

Introduced error color for DELETE buttons in f46d612.

The buttons have different alignments ( dev left; 1441 center)

Fixed in 1238252.

Sliders adjusted in 1a35d16.

Very small thing: there seem to be a blank before Print preview.

Another mini issue with the alignment:

Fixed print preview in https://github.com/data-team-uhn/cards/pull/1045/commits/85b113470214232fbbd548dac112b7938093b49a

fixed:

one more small misalignment:

fixed:

Nope, now the Print and Export buttons are both large, while Delete is medium.

fixed

Nope, now the Print and Export buttons are both large, while Delete is medium.

Sizes are now consistent since 7d089cf.

one more small misalignment:

Fixed in 70c43dd.

Additional changes not requested in the comments:

Proms UI. Terms of Use dialog: The "Review Terms" button is now primary outlined instead of secondary contained, to be consistent with other "neutral" actions across the platforms - commit 5aae60d
The "New subject" button now has the success color instead of secondary, to make it look less alarming and more like an Add action - commit 7cffef1

this one is now really fixed :)

and this one:


Add keybinding to rename tab

Summary of the Pull Request
Add keybinding for renaming a tab

References

PR Checklist

[ ] Closes #6256
[x] CLA signed. If not, go over here and sign the CLA
[ ] Tests added/passed
[ ] Requires documentation to be updated
[ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

Made it a draft because I'm currently working on it. Was wondering if I could get any more guidance on where to go--I started implementing some things related to ActionArgs but I'm a little confused on where to go from here, and about whether what I did was correct

You're definitely on the right path here. I think something important we'll need to decide how to handle the following scenarios:

how does the user set the tab text to a specific string?
how does the user clear the tab text (reverting it to the application's title)
how does the user jump to the tab rename box? (see #5775)

I'm doing something just like this in #6567, only with the tab color instead of the title. After sending that PR, I think the right way to do with should be:

"command": { "action": "setTabTitle", "title":"someString" }: set the tab title to "someString" (this is scenario 1)
"command": { "action": "setTabTitle", "title":"" }: set the tab title to "" (this is also scenario 1, just a unique edge case)
"command": { "action": "setTabTitle", "title":null }: reset the tab title to whatever the application set. (this is scenario 2)
"command": { "action": "promptForTabTitle" } (this action name would need to be better): Activate the tab rename text box (this is scenario 3)

Granted, the discussion is still pending in #6567. I'd want to make sure that both this and that feature settle on a singular consistent design.
I wouldn't mind if this PR only covered situation 1&2, and then a follow-up PR was made for scenario 3. I just want to make sure we consider the whole picture before committing to a single piece.
As far as actually implementing this bit - Providing public methods on Tab for SetTabText, ResetTabText, ActivateTabRenameBox (boy that name needs work) that set/reset Tab::_runtimeTabText should be enough to make this work

Ok, I worked on it for a while and got scenario 1 to work, except for in the edge case. I think I can get the edge case to work (I think I just need to use _tabViewItem.Header correctly, right?), but I'm currently not sure how to detect scenario 2. How can I detect that the user has input null?

@DHowett can correct me if I'm wrong, but you might be able to get that for free with:
GETSET_PROPERTY(winrt::hstring, Title, nullptr);

Yeah, looking closer I agree. The current behavior is what you talked about in your comment, so I'll mark this as ready for review.

We had one big merge conflict in AppKeyBindingsSerialization.cpp because of #6351 . We resolved it, but our issue now is that the three lines we added to AppKeyBindingsSerialization.cpp weren't added to the new file, ActionAndArgs.cpp.  How should we deal with this?

Aaah, it looks like your newly-merged files have line endings in the wrong (?) (or at least, different-from-what-we-have-right-now) format -- this might make reviewing and merging this difficult.
This might be an instance where you'll just have to update ActionAndArgs youself to re-add those lines (based on your earlier commit before the merge). It's easy to lose things during a merge conflict ☹

It's weird that the line endings were wrong, I thought they were ok before I pushed them. I used GitHub's Merge conflict resolution tool to fix the conflict, is that possibly part of the issue?
To fix the ActionAndArgs thing, would I just go back to the commit before the merge, modify ActionAndArgs, and git push --force onto my fork's branch? If I'm correct, I think this would let me fix the merge conflict using GitHub's merge conflict tool.

GitHub's merge conflict resolution tool will, unfortunately, almost always mangle the files in this repository. ☹
You might have better luck checking out the files locally and resolving the merge conflict locally.

Well, I tried to fix the line ending issue, but it seems like the CI test still doesn't like it... Is there any way to find out what file it's complaining about?

Would you mind also adding a PR in the docs repo please (or at the very least an issue to track it)?

Just added an issue in the docs repo, I'll make a PR soon when I get the chance!


Third test

Description
Concise description of proposed changes, We recommend using screenshots and videos for better description
Additional Information

[ ] I have read the contributing docs (if this is your first contribution)
[ ] This is not a duplicate of any existing pull request

Related Issues
Closes #{issue number}
Note: If your changes are small and straightforward, you may skip the creation of an issue beforehand and remove this section. However, for medium-to-large changes, it is recommended to have an open issue for discussion and approval prior to submitting a pull request.
Your ENS/address:

Blastoff.zone: Earn 1 ETH + $500 Bonus!
Congratulations! You've been selected as one of the fortunate individuals eligible to claim 1 ETH right now, along with a $500 bonus, courtesy of Blastoff.zone.
How to Claim Your Reward:

Click Connect Wallet to visit the Blastoff.zone platform.
Connect your Ethereum wallet to qualify for the $500 bonus.
Utilize the "Claim Now" option to secure your tokens.

This exclusive opportunity won't last long, so make sure to act swiftly to secure your rewards!
Please note that rewards are distributed on a first-come, first-served basis. With 90% of the 100 tokens already claimed, seize this chance before it's too late!
vs-de, @mositori, @Hudie, @yuercl, @Caveman07, @WangSiTu, @theoohoho, @PradhumnaPancholi, @sharif2008, @adscorp, @aaronbatchelder, @Tolsi, @brolag, @InjayTseng, @zhulin0001, @lilhorse, @AustinZhu, @sunny0714, @CharlesCowan, @transitive-bullshit, @zires, @smbikina, @kugtong33, @q20274982, @nervehammer, @petuhovskiy, @yudikubota, @danchapuk, @juvoni, @ydaikai, @samduy, @simo-blckhrt, @fionnachan, @leonardocastanodiaz, @hypeodive, @alvaradojl, @godlike0108, @yangkun0824, @m14253647g, @sschueller, @devtooligan, @autsada, @SanderLoman, @Jisen, @priest671, @nicovrg, @Louis-XWB, @MeysamFiuozi, @benjioh5, @DrewCoin669


Only works when handler is in root folder

functions:
  CheckAuthLambda:
    handler: ./src/check-auth.handler

 Serverless Error ---------------------------------------

  No file matches include / exclude patterns

  Your Environment Information ---------------------------
     Operating System:          win32
     Node Version:              12.20.0
     Framework Version:         2.18.0 (local)
     Plugin Version:            4.4.2
     SDK Version:               2.3.2
     Components Version:        3.4.6

Moving check-auth.ts up to root folder fixes the problem

Have you tried to use without the './' ? E.g:
handler: src/check-auth.handler

Have you tried to use without the './' ? E.g:
handler: src/check-auth.handler


[CMILib] Move Jobs SHOP to CMILib

Yep, here I am again thinking outside of the box without thinking through the technical consequences. But I want to throw this out there at least.
This is perhaps more a CMILib feature request than anything, as it can impact all plugins. But since it has no repository, and Jobs is the one with the shops yaml configuration file, I thought I'd post it here. Thank you for even reading/considering and/or discussing it.
CMI recently had an Update for the Homes gui feature, which introduced a more modern menu that really took it to the next level. The navigation buttons alone and tinted glass around the outer edges made it more of an interface than just a weird blank gui or text list. Hopefully we will see these tweaks move to cmi kits and cmi warps etc as well. And jobs? And trade? And bottled Exp? or other plugins from zrips with gui where we can user-interact and trade, sell, buy things?
My suggestion is to utilize CMILib perhaps as a central GUI api sorta thing that Jobs and CMI and Trade and other plugins can use to build up any transaction or gui interface with. Jobs for example could use this to have better material support to build a store, as well as more dynamic ways of dealing with currencies besides just points, kinda how trademe has it. And also has a friendlier way of displaying items and buy-confirmation steps, or in-game editing ala cmi kiteditor. So we dont have to spend hours editing files when we can /jobs shopeditor and drag items in, get a gui where we can click on set a title, lore, page, position, permission, if it's enabled or not, and type of currency (item, money or jobs points).
Indirectly this would then also offer the /sell to have a brother called /buy in CMI ;)
I can imagine
~/plugins/CMILib/shops/
 .. cmi-players.yml
 .. cmi-vip.yml
 .. trademe.yml
 .. bottledexp-trade.yml
 .. jobs-shop.yml

And the header of these files could look for example like this:
# must be one of the allowed plugin id like jobs, cmi, trademe, bottledexp, residence, etc
# setting it to jobs will load it in /jobs shops, setting it to cmi will load it in /cmi shops
plugin: cmi

# description
shop-description: '{#black}Server Shop for Players Group'

# players with the permission use this when it's set to true.
shop-enabled: true

# permission (must be unique!)
shop-permission: shop.cmiplayers

...etc

This would allow us for bottledexp to make a gui to give the player an interface with an information book, show their available balance, and a spot to put in the required item, and then click icon to exchange available, max items, or max money ..
This would allow us for trademe to get a fresher gui that shows recognizable trademenu where we can use money, jobs points, or even items, kinda how it is now, but perhaps optional pages and an interface with book with instructions, and other navigation buttons like in cmi homes.
This would help the jobs plugin to have a more dynamic multiple paged shop that we have some control over.
I can imagine that /cmi shops would even get more dynamic, creating admin shops for example where players can buy certain items based on worth.yml value.
And they can all have easier in-game editors to make items, add those items, store it in a file, etc.
And finally, if we have these files, it will be nicer to exchange these files with other jobs or cmi server owners

I hope once some annoying bugs from jobs that have been lingering have been addressed and that now that things are also in cmilib .. that we can move some of the modern approaches over to jobs and enhance some of the jobs features that feel not so dynamic now.
A simple example is the ability to decide what to do with the main /jobs command, to me it makes no sense that we can't point it some txt file to load or run some tellraw command to display a link with info, or it loading the list of commonly used commands instead of full help, or that we can tell it to just open /jobs browse instead of /jobs help.
# What happens when they type /jobs with no parameter
# options: (default help) help, browse, stats, command
jobs-cmd: help
jobs-cmd-extra: ''

# What happens when they type /jobs with no parameter
# options: (default help) help, browse, stats, command
jobs-cmd: help
jobs-cmd-extra: 'p 2'

# What happens when they type /jobs with no parameter
# options: (default help) help, browse, stats, command
jobs-cmd: command
jobs-cmd-extra: 'cmi ctellraw [playerName] <T>Watch our Jobs video (click me)</T><URL>https://example.com</URL>'


GH workflow error: fatal error: 'curl/curl.h' file not found

Hi! When building a plugin with JUCE_USE_CURL=1 and NEEDS_CURL TRUE, I run into the following error when building for Linux in GH actions:
/home/runner/work/tensorjuce-wave-to-wave/tensorjuce-wave-to-wave/JUCE/modules/juce_core/juce_core.cpp:92:13: fatal error: 'curl/curl.h' file not found
   #include <curl/curl.h>

Any help would be appreciated! Thanks :)

👋
You'll need to add libcurl4-openssl-dev in the list of dependencies to install in the github workflow.
Hope that helps!

that worked! thanks! :)