Ignore Hub Failures

Much appreciated if you could port the ignore hub failure feature from the Maven Plugin () to the Gradle Plugin.
See:
https://github.com/blackducksoftware/hub-maven-plugin/pull/4
However, please keep in mind this issue recently reported with the Maven implementation:
https://github.com/blackducksoftware/hub-maven-plugin/issues/7
Thank you,
Ville Koskela

This should be fixed in 3.3.0

Excuse me, this IS fixed in 3.3.0.

Glad to hear it!
When you have time please update the documentation:

https://github.com/blackducksoftware/hub-gradle-plugin/wiki

Also, there is page under the maven hub plugin titled "Hub-Maven-&-Gradle-Properties", it may need to be updated - or possibly renamed - as well.

https://github.com/blackducksoftware/hub-maven-plugin/wiki/Hub-Maven-&-Gradle-Properties

Thanks!

@ekerwin only up to version 3.20 of the hub-gradle-plugin appears to be in Maven Central:
http://search.maven.org/#search|gav|1|g%3A"com.blackducksoftware.integration" AND a%3A"hub-gradle-plugin"
Was the above a type-o or has it not been released yet?
Thanks,
Ville

Ville, thanks for pointing this out. For some reason, the staging repository on nexus (maven central) was only closed and not released. I've just released it manually so 3.3.0 should show up some time later today. Sorry about that!

@ekerwin I'm afraid it's still not there; in my experience it should only take 10-15 min to appear in central:
http://central.maven.org/maven2/com/blackducksoftware/integration/hub-gradle-plugin/
Can you double check your release?

Sorry about this - thanks for bringing it to our attention. We are looking in to it. We are also planning on releasing 3.4.0 possibly today, so that might also clear this up and 3.3.0 might just be a phantom release.

I've just released 3.4.0 - let's hope it shows up in maven central with no issues. It will include all 3.3.x fixes as well as some new files for the output.

It looks like 3.4.0 is available - please check that and if all is good, we can close this issue down.

Haven't heard anything - I believe 3.4.0 did fix this. Please reopen if otherwise. Thanks!


Lock request handlers

Locking access to request handlers while iterating to prevent addition/deletion to request_handlers which will throw off the iterator.
Could not build tests as conan install -o build_luna_tests=True fails with finding cpr. Error is

ERROR: Can't find a 'cpr/1.2.0@DEGoodmanWilson/testing' package for the specified options and settings

Try to build from sources with "--build cpr" parameter
If it fails, you could try to contact the package author  at 'https://github.com/whoshuu/cpr.git', report your configuration and try to collaborate to support it.

Package configuration:

Settings: arch=x86_64, build_type=Release, compiler=gcc, compiler.libcxx=libstdc++, compiler.version=4.9, os=Linux
Options: insecure_curl=False, use_ssl=True, use_system_curl=True

Committee merged into master…


Allow StorageClass to be set for pulsar-manager in the values file

Describe the solution you'd like
Have the same options for volumes in pulsar manager as we do in the broker, zookeeper, bookie...

It seems that #343 would achieve this.


Nats service port name must be tcp instead of nats when deploying in a cluster with istio

When deploying in a cluster with istio, I had to change the nats service for the installation to work.
{{- if not .Values.messagingSystem.external.enabled }}
{{- include "ocis.basicServiceTemplates" (dict "scope" . "appName" "appNameNats" "appNameSuffix" "") -}}
apiVersion: v1
kind: Service
metadata:
  name: {{ .appName }}
  namespace: {{ template "ocis.namespace" . }}
  labels:
    app: {{ .appName }}
    ocis-metrics: enabled
    {{- include "ocis.labels" . | nindent 4 }}
spec:
  selector:
    app: {{ .appName }}
  ports:
    - name: nats # <--------------- change to tcp
      port: 9233
      protocol: TCP
    - name: metrics-debug
      port: 9234
      protocol: TCP
{{- end }}

I'm not to familiar with Istio but is this because of the protocol selection? See also https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection
If so I'd honestly prefer to set appProtocol.
Are you willing to provide a patch for this?
Could you please at least verify that setting appProtocol to tcp also does the trick?
  ports:
    - name: nats
      port: 9233
      protocol: TCP
      appProtocol: tcp
``

The other port names seem to work with ISTIO out of pure luck, because we named them http and grpc :laughing: The metrics collection via eg. Prometheus should also not work for you since the port is called metrics-debug, right?

I guess we should just add appProtocol everywhere.

I did a quick test and it is working with appProtocol. I will look more into it later.

@marc-andre-julien-uqam can you please give #560 a try?


什么时候能更新一版期待

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

您好，这边会加快项目进度

能否加入该项目的开发？

？？？？？

能否加入该项目的开发？

如果有兴趣的话，欢迎给项目提PR

现在开发到什么进度了？不是说6月份放出来一版可以下载的么？


Update references and citation instructions (#4)

The reference to our newly published paper is included. The
instructions for citations anf references are updated as well.

Codecov Report
Patch and project coverage have no change.

Comparison is base (4a20faf) 100.00% compared to head (6a66d1a) 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@                 Coverage Diff                  @@
##           maintenance/v0.1.x        #6   +/-   ##
====================================================
  Coverage              100.00%   100.00%
====================================================
  Files                       5         5
  Lines                     627       627
====================================================
  Hits                      627       627

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Move SchemaMigration from ManageIQ to ManageIQ::Schema plugin

Depends on https://github.com/ManageIQ/manageiq-schema/pull/175
Fixes https://github.com/ManageIQ/manageiq/issues/16670

@Fryguy Please review

@bdunne Please add BZ link.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1552911

Gaprindashvili backport details:
$ git log -1
commit 2fdb48d1ab884915d7f825ae7ed93431198fea45
Author: Jason Frey<EMAIL_ADDRESS>Date:   Fri Mar 2 16:32:52 2018 -0500

    Merge pull request #17072 from bdunne/schema_migration

    Move SchemaMigration from ManageIQ to ManageIQ::Schema plugin
    (cherry picked from commit 02f5f6bc456708e3ddd24f52ac34a00e7b829da0)

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1553397


white font suddenly become black

Issue Type: Bug

all system level text color become black instead of white, e.g. in side bar, notification popup, menu bar and so on. since the theme is unchanged as default dark+, I cannot see the texts on the whole UI except the code (the fonts of codes are normal)
VS Code version: Code 1.28.2 (7f3ce96ff4729c91352ae6def877e59c561f4850, 2018-10-17T00:23:51.859Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 x 1992)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
15.90GB (11.43GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

hive-sql
jos
0.0.4

python
ms-
2018.9.1

@beanywang doe the problem go away if you switch themes?

@Tyriar Tried that for so many times. never work. black text are fixed and unchangeable. black text with white theme and black text with dark theme and black text with, well, any themes.
Actually, the software used to be normal on my machine, until I reseted the whole windows 10 first and then refresh the whole windows 10 secondly.
black text issue happens when I reinstall a fresh VS Code on my fresh os.
why me......

We fixed this meanwhile. You can give our preview releases a try from: https://code.visualstudio.com/insiders/

@bpasero Thanks for your jobs! How soon will this fix packed into the stable build? is there a schedule? don't really want to install an extra preview build. I may just wait for an stable update.

@beanywang in about 2 weeks

@bpasero Nice.


Add sdist in the PyPI distribution.

Let's add sdist in the PyPI distribution.
Seems like sdist will be needed for conda-forge repository.

Codecov Report

Merging #289 into master will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #289      +/-   ##
==========================================
- Coverage   93.49%   93.46%   -0.04%
==========================================
  Files          33       33
  Lines        3212     3212
==========================================
- Hits         3003     3002       -1
- Misses        209      210       +1

Impacted Files
Coverage Δ

databricks/koalas/__init__.py
88.88% <0%> (-3.71%)
:arrow_down:

Continue to review full report at Codecov.

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


implemented clear hierarchy for the footer #567

fixes #567

Add H2 footer element in all pages, including documentation ones.
use .sr-only instead

revised it


chore: Remove flutter_map attribution

Hi everyone,
The map on the Product Page has an icon similar to the Google Maps icon:

I prefer to disable it, because it's really misleading and I've clicked many times on it.

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

Project coverage is 7.04%. Comparing base (4d9c7fc) to head (4fdad4f).
Report is 262 commits behind head on develop.

Additional details and impacted files
@@            Coverage Diff             @@
##           develop   #5511      +/-   ##
==========================================
- Coverage     9.54%   7.04%   -2.51%
==========================================
  Files          325     397      +72
  Lines        16411   20884    +4473
==========================================
- Hits          1567    1472      -95
- Misses       14844   19412    +4568

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


Stats tracking

Closes #26. Closes #25.

Coverage decreased (-0.08%) to 97.696% when pulling 49e9e0b5e6e41202782e7d555963df90e47eed6a on stats into 92d3710388b39e0231a6e79e25e6905f4c08fefd on master.

TODO:

review code for correctness and code style
add documentation for the StatsServer
add mention of the StatsServer in the readme and Crawlie docs

Coverage decreased (-0.08%) to 97.696% when pulling 355a58c40c83e8bf357ad9a3f4a7ed41746b53d3 on stats into 92d3710388b39e0231a6e79e25e6905f4c08fefd on master.

Coverage decreased (-0.08%) to 97.696% when pulling b0cf085b184e0111bf1b7dc52c9f0e1f13d9b8f5 on stats into 92d3710388b39e0231a6e79e25e6905f4c08fefd on master.


[vi] Remove exec permission on markdown files

Related PR: #28447 (Remove exec permission on markdown files)

/lgtm

@sftim Could you check these PRs, and do lgtm and approve if they seems good? 😊

#28550
#28551
#28557
#28561 (This PR)

/remove-lifecycle stale

This needs an approval from the localization team. It has been dangling for too long.


Deprecate the service ports library

Since we're moving to using the ops facility for this, the change is no longer needed. We should instead look to deprecate this library.

Originally posted by @simskij in https://github.com/canonical/observability-libs/issues/73#issuecomment-2507507339

fixed by https://github.com/canonical/observability-libs/pull/116


doc: release: Add highlights of Zephyr 3.7 release

This introduces a high-level summary of the most notable changes in 3.7. This also tries to capture the same for changes since previous LTS.
The latter is 100% a proposal at this stage and far from complete. Looking for opinions from others on whether this is useful at all before spending more time trying to make it "right".

I just realized that at least PTP (Precision Time Protocol) is missing from the highlights (from my POV at least 😄).
Will likely iterate some more on the list over the next few days but also happy if a first stab gets merged as soon as folks are comfortable with it, and it can always be completed in other PRs.

I just realized that at least

Maybe you want to ping maintainers for their biggest highlights since 2.7, and then you can chose a shortlist from that?

I just realized that at least

Maybe you want to ping maintainers for their biggest highlights since 2.7, and then you can chose a shortlist from that?

In this case PTP is something recent I forgot for 3.7 proper, but yeah, good idea nevertheless :)


test(standalone): Escrow

Adds an integration test to ensure that for a single user locking governance tokens, the balance_at and total_supply of vote currency is equal. Also checks the literal value of total_supply after a second user locks, to reuse in the JS implementation test.

@savudani8 what's the conclusion from this test? Is there a bug in the parachain, or is the discrepancy that you saw earlier caused by the ts code?

@savudani8 what's the conclusion from this test? Is there a bug in the parachain, or is the discrepancy that you saw earlier caused by the ts code?

@sander2 No bug in the parachain, the issue was in the JS code


Cards and other changes

Pull Request Template
Hey there,
Thank you for contribution and walking with crea8lab in this awesome journey. Here are a few tips to help you make successful PRs

Update your local copy after you've committed your changes.
If any conflicts, resolve them accordingly.
Take screenshots of your display... how does what you've done look in the browser?
Go to your github account and send a PR from there with the screenshot attached to it.

Happy hacking

Full list of changes

[x] Added cards as per card issue.
[x] Beautified the footer (more padding on the bottom so it wouldn't look weird)
[x] Fixed the form-control dropdown since the words were getting cut off due to its height.
[x] Updated readme to add MDN documentation for HTML, CSS and JavaScript (the link was broken).
[x] Fixed font size
[x] Fixed font background in carousel for better legibility.

#64

Can we add the #hacktoberfest label to this, please?


Any way to use clappr with HTML 5 audio player

I have an audio streamming (http://servidor1.crossdigital.com.br:8058/;stream.nsv&type=mp3) and play normally with HTML 5 audio tag, but with clappr does not play, has someway to use audio tag with clappr?

Hi,
i think problem is because of the name/url path to file which does not ends with '.mp3' extension.
You should try to provide the audio/mp3 mime type in the source option using an object.
Syntax should be something like :
source : {source: 'http://servidor1.crossdigital.com.br:8058/;stream.nsv&type=mp3', mimeType: 'audio/mp3'}

Thanks, works fine!


MedplumClient improvements

Coverage decreased (-0.01%) to 95.144% when pulling c33827ff2559b287545e54dc27264a0e2e44cd06 on cody-client-tweaks into 5306ee5fa2a25ef17fc9260a5696190a466d462e on main.


Technical limitations to running this exporter remotely from the proxmox nodes

Are there any technical limitations from running this in, say, a virtual machine running on top of, or completely separately from, the proxmox cluster it's exporting metrics from? As far as I can tell, this exporter assumes it's being run on a Proxmox VE host, but it just collects metrics from an HTTP API that Proxmox exposes.
My goal would be to run this in the same k8s cluster VMs I run on top of Proxmox, rather than install this directly on my Proxmox hosts as a separate bespoke thing.

Furthering the same goal, is there any appetite for say, a helm chart to install this in a kubernetes cluster environment?

Are there any technical limitations from running this in, say, a virtual machine running on top of, or completely separately from, the proxmox cluster it's exporting metrics from

No limitations. Running prometheus-pve-exporter in its own container/pod is certainly supported.
People who like to contribute their deployments scripts are free to do so. Please start with your own repo. For a start we can link to that from the readme.


Cannot edit catalog if service template or provider has changed

If the provider or service template changes then we can't edit the catalog anymore. We can't delete the catalog either.

Any idea how we can fix the catalog?

This is probably part of a larger problem of orphaned service catalog items.  In this particular case did your underlying template get deleted.

@Fryguy I have one catalog where its template is deleted and I believe there is another catalog which still has the template but can't edit due to the error.


add documentation and Transcribe-powered prepublish script

Closes #22
Until @svozza contributed #19, Sanctuary's API was completely undocumented. It's currently partially documented. This pull request documents the rest of the API, and adds a section on types and how to read Sanctuary's type signatures.
Points of note:

The source of the documentation is index.js. README.md is now derived from the source via Transcribe.

I've included the changes to README.md for the benefit of those reviewing the pull request. I will revert these changes before merging this pull request as the file will be updated automatically with each release.

To generate README.md I ran VERSION=0.4.0 make. As a result, the line numbers to which the headings in the API section link are not correct. This will not be a problem when the file is updated as part of the v0.5.0 release process.

Several sections contain "TK" as their body. I'm working on these, and will update the pull request as I complete them.

The doctests are tested via a Unix pipeline which transforms
> S.head([1, 2, 3])
Just(1)
> S.head([])
Nothing()

into something like
assert.strictEqual(R.toString(S.head([1, 2, 3])), 'Just(1)');
assert.strictEqual(R.toString(S.head([])), 'Nothing()');

via sed, which is then piped to node for evaluation. Note that single quotes and double quotes are not interchangeable on the output lines, since each output line must exactly match the result of applying R.toString to the preceding expression.

Once this pull request and #35 have been merged I will publish v0.5.0, which several of us are eagerly awaiting. I'd love feedback on this pull request from @benperez, @Bpless, @buzzdecafe, @CrossEye, @michaelckelly, @svozza, and anyone else who's interested. :)

Wow. That is some amount of work! I will have a proper look at this in the morning and give some feedback afterwards.

Thank you, @svozza. I look forward to your feedback. :)

I'm loving all of the new documentation! Nice work!
One thing that I initially found a little confusing is that the fat arrow (=>) is used to indicate that a method on a type implicitly takes itself as the first argument. I agree that some special syntax is needed to communicate this concept to the user of the API. The only problem with the fat arrow is that it's already used in Haskell to express a class constraint. It's not a huge deal but I think that it might confuse people who are used to Haskell type signatures. Maybe
Maybe.of :: Maybe a => b -> Maybe b

could be expressed instead as something like
Maybe.of :: (Maybe a ->) b -> Maybe b

or
Maybe.of :: (Maybe a ->)* b -> Maybe b

Terrific feedback, @benperez! I was aware that the => has a different meaning in Haskell, and I agree that it's confusing to use it here for a different purpose. I did consider using brackets of some sort, but was deterred by the fact that [ and ] are already used to represent lists, { and } are already used to represent dictionaries and records, and ( and ) are already used for grouping. Seeing your examples made me realize that parentheses really do suggest optionality, which is close to the meaning we hope to convey. Furthermore the parentheses are clearly not included for grouping, which suggests to the reader they have some other meaning.
The other option which seems reasonable is to use a different arrow such as ~>. Our options are:
map :: (Maybe a ->) (a -> b) -> Maybe b

map :: Maybe a ~> (a -> b) -> Maybe b

I believe people are more likely to infer the meaning from the first option. My one hesitation is that the parentheses make the signature a bit noisy when parentheses are also required for grouping, as above.
Which of these two options do others prefer?

@benperez revealed via HipChat a fondness for the squiggly arrow (~>). I've updated the pull request to use this, as it's clearly better than the fat arrow (=>). I'm open to switching to parentheses if someone makes a compelling case.

So I've finally had a chance to read through the docs. I'm probably not the person to be giving the sort of detailed feedback @benperez has but as someone very new to this stuff I have to say the section on types is excellent, it's really clear and concise explanation of the nomenclature.
The only thing I would say is the the intro section seems a bit disjointed. It jumps straight into the types stuff when describing S.head even though the explanation of type signatures comes in the next section. That bit also sort of duplicates what's in the API docs in the section below.

The only thing I would say is the the intro section seems a bit disjointed.

I agree. I'll rework the section to briefly explain the motivation for creating the library without mentioning functors and the specifics of S.head.

I've updated the introduction. Also, all occurrences of "TK" have been replaced with documentation. :tada:

Nice!

Merging!


Evalai Leaderboard doesn't run the submission file.

Hello,
I have submitted the test set result to Argoverse 2: 4D Occupancy Forecasting Challenge leaderboard last week. But the submission has not been evaluated yet and keep submitted status for  more than 3 days.
Is there any issue on the evalai server?
Regards

Hey, sorry for the late response (somehow I didn't get a notification for this issue).
On March 21, you exceeded the maximum number of entries allowed for a day. And on March 22, there was an OOM error on my end. I have reevaluated your March 22 submission, and the server should be running fine now if you have to submit any other results!
Thanks for your patience!

Got it. Thanks your response.

@foolhard  @tarashakhurana
Hello,
I am wondering if it is possible to submit to the Argoverse 2: 4D Occupancy Forecasting Challenge leaderboard. I am attempting to upload a JSON file (approximately 30GB) and it takes about 1.5 hours to upload. However, the connection URL expires after 1 hour, preventing me from completing the submission. Could you please confirm if the test set result is indeed around 30GB, and how long it typically takes for you to upload it?
Thank you.


Pyenv is not recognised only uses system python version

Description
I have used a python 3 script for some time now to unpack macros from excel files. I have wrapped it in an npm script too:
scripts: {
  "unpack-excel": "python ./path_to_my_script/script.py"
}

The script requires python 3, but the system python version on MacOS is 2.7 which is still required for some node package installs and so on, so I use pyenv to switch between python versions, like pyenv global 3.8.2.
I had the idea of running it as a pre-commit hook, so I installed this with npx mrm lint-staged, then added it as:
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{xlsb,xls,xlsm,xla,xlt,xlam}": [
      "python ./path_to_my_script/script.py"
    ]
  }

It is called for the files but instead of recognising pyenv (/Users/username/.pyenv/shims/python), always uses the system python version (/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python).
I have no idea how to reference the python version specified through pyenv to be used in my pre-commit hook or how to control anythin in the pre commit hook's environment. Is there a way?
Environment

OS: macOS Catalina
Node.js: v12.9.1
lint-staged: v10.2.7

Nevermind, solved it with creating a ~/.huskyrc file:
# ~/.huskyrc
if command -v pyenv 1>/dev/null 2>&1; then
  eval "$(pyenv init -)"
  pyenv global 3.8.2
fi


feat(bulk-import): update bulk import icon

Resolves:
https://issues.redhat.com/browse/RHIDP-2802
Screenshot:

Thank you @debsmita1, looks good!

/lgtm
/approve


REQUEST - enable Audit only mode

Could a variable be added to enable just audit only so as to perform checks for existing systems?
---
# vars.yaml
audit_mode: true
remediate_mode: false

Then, you could do something similar to:
---
- name: "SCORED | 1.1.1 | PATCH | L1 Ensure Enforce password history is set to 24 or more passwords"
  block:
      - name: "SCORED | 1.1.1 | AUDIT | L1 Ensure Enforce password history is set to 24 or more passwords"
        assert:
            that: passwordhistorysize | int is version('24', '>=')
            fail_msg: "Password history must be configured to 24 passwords remembered and variable passwordhistorysize is set to {{ passwordhistorysize }}"
        changed_when: false
        ignore_errors: true
        register: result

      - name: "SCORED | 1.1.1 | PATCH | L1 Ensure Enforce password history is set to 24 or more passwords"
        when: ( remediate_mode | bool )
        win_security_policy:
            section: System Access
            key: PasswordHistorySize
            value: "{{ passwordhistorysize }}"
  when:
      - rule_1_1_1
  tags:
      - level1-domaincontroller
      - level1-memberserver
      - rule_1.1.1
      - patch
# ...
...

hi @FilBot3
Apologies for the delay in responding. We are releasing a separate role for the audit over the next couple of weeks.
This give the ability to run the audit in isolation checking that this remediation role is actually doing what is expected and without the need for ansible is that is a requirement.
It is almost ready so when we release will let you know any feedback will be appreciated.

Thank you for the heads up. I'll check soon.

hi @FilBot3
Thanks for closing this, this is taking slightly longer than anticipated. We are hoping to release along with a whole pipeline very shortly. As you are not the only person asking for this, we may release a beta sooner.
Thanks
uk-bolly


add fan-Out API support for encryption, checksums

Based on your proposal - keeping few things

per object, metadata, tags, and retention can be applied independently
encryption is set for the whole fan-out
checksum is applied for the whole fan-out

@klauspost - keeps the API functional name in-line with the common pattern across this SDK.


[RFC] Link Component

The Goal
Create a Link component to properly apply aria attributes and keyboard
navigation for the elements other than html a tag.
By Default, Link component renders an a tag which uses useClickable hook. As
per the nature of useClickable, it doesn't change the native link a tags
behaviour.
Key Features

Applies role: link when the element is not a native link - a tag.
Adds all useClickable features with keyboard navigation and
unstable_clickOnSpace: false.
Returns { target: "_blank", rel: "noopener noreferrer" } when isExternal.

Options

isExternal - Returns { target: "_blank", rel: "noopener noreferrer" }

API
<Link href="https://reakit.io/" isExternal>
  Link
</Link>

<Link as="span" onClick="() => window.location.href = 'https://reakit.io/'">
  Custom Link
</Link>

Complete Implementation & Example

Implementation Details -
https://github.com/timelessco/renderless-components/blob/master/src/link/Link.ts
Storybook -
https://renderless-components.netlify.app/?path=/story/component-link-reakit--default

Related WAI-ARIA resources

https://www.w3.org/TR/wai-aria-practices-1.2/#link
https://www.w3.org/TR/wai-aria-practices-1.2/examples/link/link.html
https://www.w3.org/TR/wai-aria-1.2/#link

Would be nice to take into account integration with popular React routing libraries like react-router.

Would be nice to take into account integration with popular React routing libraries like react-router.

I will experiment with routing libraries and let know the results here. Thanks.

This is a good article about "block links" which describe an issue with using <a> elements around a large block of content: https://css-tricks.com/block-links-are-a-pain-and-maybe-just-a-bad-idea/

Would be nice to take into account integration with popular React routing libraries like react-router.

@StorytellerCZ I believe this would be achievable with composition patterns already available in Reakit, no extra stuff needed for Link specifically.

The one draw back I see with a custom link component when you start rendering them as non <a> elements is that you lose browser context menu behaviour - this is definitely not an ideal UX and good be a footgun for a lot of users.

The one draw back I see with a custom link component when you start rendering them as non <a> elements is that you lose browser context menu behaviour - this is definitely not an ideal UX and good be a footgun for a lot of users.

You are correct, non <a> tag (i.e, elements with role="link") will not have the browser context & also will not accept any attributes specific to <a> tag.
As mentioned in the Note seciont here - https://w3c.github.io/aria-practices/#link
It is the responsibility of the authors to be aware of this when using a non native link element. We only provide them with the necessary aria attributes.

Would be nice to take into account integration with popular React routing libraries like react-router.

@StorytellerCZ I believe this would be achievable with composition patterns already available in Reakit, no extra stuff needed for Link specifically.

Exactly, here is an example with Next JS - https://codesandbox.io/s/nestjs-reakit-link-example-28893

Would be nice to take into account integration with popular React routing libraries like react-router.

@StorytellerCZ Here is an example with react-router - https://codesandbox.io/s/react-router-link-example-38bb6?file=/example.js

This is a good article about "block links" which describe an issue with using <a> elements around a large block of content: https://css-tricks.com/block-links-are-a-pain-and-maybe-just-a-bad-idea/
So I'd like a link component to solve this problem by:

Nested links "just work"
"Block links" have good a11y
Can still select text inside of the link
Obviously all of the UX and WAI-ARIA practices of a regular link still apply

@tom-sherman Do you think, we should handle "Block Links" ourselves ?
Solution for Block Links requires some amount of CSS with ::before which I am not sure how we can do with Reakit.
Chakra UI has a similar solution for this - Link Box
But Can still select text inside of the link is not solved.

Other than handling block links, I don't see what value a Reakit link component can have over a regular a tag.

Other than handling block links, I don't see what value a Reakit link component can have over a regular a tag.

Like Button Component, this component will set role to link for non native link tag.
Also you can pass isExternal to handle the external links and pass the respective attributes ourselves.
<Link href="https://reakit.io/" isExternal>
      Reakit
    </Link>

As already found in the RFC description.

Reakit solves browser inconsistencies regarding focus that occur with native buttons. I would personally say that without this feature there would be no point in a Reakit Button component. Because I'm not aware of any such issues with <a>s, I've never had a use case for this kind of Link component but that's not to say that other's do.

Okay I got it and yes this component doesn't do anything for the native  tag.
Like I said before

this component will set role to link for non native link tag & onClick is handled by Clickable

<span
    role="link"
    tabindex="0"
  >
    Reakit
  </span>

Kindly give me an idea on how we can solve the Block Links in Reakit


Remove outdated study

This study is not relevant anymore. t-Digest code improved since then, and comparing with KLL was not the best idea. Now we have REQ sketch, which seems to be a better candidate for comparison.

As for t-digest vs. KLL or ReqSketch comparison, we have a paper with Graham and people from Splunk. I think t-digest was not updated much since then, so I think you can point to this paper for comparison.
The upshot is that while t-digest is more accurate on well-behaved distributions, there are examples and distributions where it fails spectacularly (though these inputs are somewhat artificial). However, KLL and ReqSketch have much better update time than t-digest.

@PavelVesely you may want to comment here:
https://github.com/apache/datasketches-cpp/issues/416


i made some mistakes with my panther x2 using cmd command

i made some mistakes with my panther x2 using cmd command
i made some upload or i dont now i cant logg to my dashboard

@xxxsss666 Oh, there is not an easy way to restore.
Please submit a ticket through https://panther.global/.
the tech support team will try to fix it for you.


Chrome and detectable

He is not passing the webdriver test

Thanks for mentioning that.
Please update to the latest version.
Then try the debugging option.
from lucd.driver import Driver
driver = Driver()
chrome=driver.create_driver(debugging=True)


Add metric for interrupts during conntrack dump / garbage collection

Add a metric for counting datapath errors. This should cover all possible errors in datapath management or the datapath itself, however to allow identification of which kind of error it is, the user should mix in labels identifying the area, name and address family for the metric.
Use this metric to count the rate of errors that occur while attempting to dump the conntrack table. Curry the gauge with specific labels to identify this particular failure condition.
We can use this to determine how important it is to improve the CT map
iteration logic.
Related: #4496

This change is

test-me-please

test-me-please

test-me-please


Make docs work by putting app on cliff-effects/app, docs on cliff-effects/docs

OK, it's been a long journey. This is almost working now!
Puts the app itself at https://codeforboston.github.io/cliff-effects/app rather than just /cliff-effects. I did this so that we can put the docs at /cliff-effects/docs without the service worker interfering. This seems to be working.
I also made a static redirect page to live at /cliff-effects[/index.html]. This is working except, for some reason, /cliff-effects/ (with a trailing slash) seems to trigger a Google search in Chrome rather than just loading the redirect page. Not sure how to fix this.
I changed the documentation package from documentation to jsdoc because jsdoc has prettier output for properties and probably has better support in general. documentation was somewhat nice in that the output folder had a single HTML file at the top level, but it still had plenty of assets and that shouldn't matter anyway in this system. Finally, I added a Node script to do the post-build filesystem manipulations (this required adding the plugin fs-extra to copy a directory recursively).
I'll be interested to see whether Netlify still works - it might need an update to its config.
Let me know if this seems reasonable!

Netlify seems to still work! 🎉

This is looking awesome and deploys just fine for me! One last shot at avoid /app - @wacii : Have any ideas about how to build without needing those two separate directories?

Another alternative could be to use another repository called cliff-effects-docs, also published to GitHub pages, that includes cliff-effects at master as a submodule. Its npm scripts could automatically update the submodule before generating the docs and deploying, and we could have a cron job or something to deploy the docs every 24 hours or whatever interval makes sense.

@knod Not really. There's only so much control we have over deployments on Github Pages. And we are already pushing what it was meant for.


Prefer grep/grep_v

The following code has 3 anti-patterns:
def self.tokens(pattern)
   pattern.scan(TOKEN).reject { |token| token =~ /\A#{SEPARATORS}\Z/ }
end

This issue is to identify that enum.reject { |x| x.match? regexp } should be enum.grep_v(regexp). Same with select vs grep.
See: rubocop-hq/rubocop-ast#65

I have run a quick benchmark. Looks like grep/grep_v are not so nice, while simplifying code a bit.

Benchmark code
# frozen_string_literal: true

require 'bundler/inline'

gemfile(true) do
  gem 'benchmark-ips'
  gem 'benchmark-memory'
end

arr = ['foobar', 'foobaz', 'bazquux']

REGEXP = /foo/

def select_match(arr)
  arr.select { |e| e.match?(REGEXP) }
end

def grep(arr)
  arr.grep(REGEXP)
end

Benchmark.ips do |x|
  x.report("select.match?")  { select_match(arr) }
  x.report("grep")           { grep(arr) }
  x.compare!
end

puts "********* MEMORY *********"

Benchmark.memory do |x|
  x.report("select.match?")  { select_match(arr) }
  x.report("grep")           { grep(arr) }
  x.compare!
end

Warming up --------------------------------------
       select.match?   159.869k i/100ms
                grep    56.192k i/100ms
Calculating -------------------------------------
       select.match?      1.561M (± 6.5%) i/s -      7.834M in   5.044218s
                grep    565.201k (± 1.6%) i/s -      2.866M in   5.071747s

Comparison:
       select.match?:  1561061.6 i/s
                grep:   565201.5 i/s - 2.76x  (± 0.00) slower

********* MEMORY *********
Calculating -------------------------------------
       select.match?    40.000  memsize (     0.000  retained)
                         1.000  objects (     0.000  retained)
                         0.000  strings (     0.000  retained)
                grep   208.000  memsize (     0.000  retained)
                         2.000  objects (     0.000  retained)
                         0.000  strings (     0.000  retained)

Comparison:
       select.match?:         40 allocated
                grep:        208 allocated - 5.20x more

Kudos for checking that @fatkodima I would not have thought so. It makes some sense, because grep calls === which is =~ for Regexp. This should be optimized by Ruby... I'll write an issue (unless you'd prefer doing that yourself)?

Please, do 👍

@marcandre
So do you think it is worth implementing, due to https://bugs.ruby-lang.org/issues/17030, but making it disabled by default?
grep/grep_v can be also extended by Enumerable#{any?,all?,none?,one?} with regexp argument.

Sure. What would be worth implementing is fixing 17030 :-) IIUC, Matz is ok with optimizing this


One extra pixel at the top of the blinking cursor with Microsoft Pinyin IME

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.64.0 stable and 1.65.0-insider
OS Version: Windows 10 21H1

Steps to Reproduce:
Switch between different files, there is a probability of appearing after regenerating the cursor.
Switch Microsoft Pinyin IME and typing. See: https://github.com/microsoft/vscode/issues/142253#issuecomment-1030636769
https://user-images.githubusercontent.com/16591303/152656890-9eeeee09-4720-4561-81e6-cbc755b86db7.mp4

I could no longer reproduce after https://github.com/microsoft/vscode/commit/1dbc782ab9302333ff1b08a7fa15381835a85738 , so I believe that a left over styling was the root cause here.

\closedWith 1dbc782ab9302333ff1b08a7fa15381835a85738

This bug still exist in v1.64.2

https://user-images.githubusercontent.com/7344724/155038497-e84c9c9d-67ec-4dfb-b5e1-99fb02645040.mp4

Open vscode with dark theme
Switch IME 微软拼音(Microsoft Pinyin) from English mode to Chinese mode
Type A, S, D, then Backspace to delete them
Find one extra pixel

/verified


Add theme Yilia-plus

Hello, I Add theme yilia-plus

Dedicate a theme, continue to support！
Thanks!

Can someone take care of that

I made a comment. Could you remove the two tags with the theme name?
You can even do it on GitHub via an edit button

我发表了评论。你能用主题名称删除这两个标签吗？
您甚至可以通过编辑按钮在GitHub上执行此操作

Sure, I've deleted the theme tags

I made a comment. Could you remove the two tags with the theme name?
You can even do it on GitHub via an edit button

Sure, I've deleted the theme tags


using NLextract as source for countrywide NL

As described in #4572 the current import is broken. I've rewritten the json to use the NLextract source. It is based on the Norway CSV import, however I do not know how to configure a semicolon as the delimiter in stead of a comma.
Also I haven't tested it, so take the PR with an abundance of skepsis
closes #4572

however I do not know how to configure a semicolon as the delimiter in stead of a comma

csvsplit can be set to a semicolon see https://github.com/openaddresses/openaddresses/blob/master/CONTRIBUTING.md

@iandees Any idea why this is failing, there isn't even a log.

The database was having problems that I think I just fixed. Let's try it again...

rerun this please


Python 2.7 support

Would it be possible to support Python 2.7? I know it's almost deprecated, but there is some stuff running on it, and I can't imagine it being too hard to do using the six module...

I do like the idea of making this package 2.7 compatible. I wrote it first back before Python 3 supported the u prefix on strings and compatibility was much more of a pain. I'll see if I can get it working with 2.7 over the weekend.

Actually, I did convert it for something I needed, it was pretty easy:
https://github.com/skorokithakis/lektor-shortcodes/blob/master/lektor_shortcodes/scodes.py
Let me see if I can bundle that up in a PR.

Should be good with #5.

Now that I've sat down to do this I'm remembering all the reasons I didn't make it 2.7-compatible in the first place!
I don't want to add an external dependency like six to the package and to be honest if I uglify the code enough to make it backwards compatible I'll just never maintain it.
If you want to host a separate Python 2 version I'll be happy to add a link to it in the documentation though.

Sure, understandable. Six is not an external dependency, though, as I vendored it. That said, I also vendored your package in my Lektor plugin, so I don't want to maintain a whole other version and have to merge your changes in each time, etc. I'll just keep using this version, as it works fine for me, and hopefully Lektor will support 3 soon.

That's perfect - I'm glad you're getting use out of it.
Out of interest, are you feeding it byte strings or unicode as input? It should work fine for byte strings with just the decode_escapes() function altered and raise from patched around but I wouldn't trust it with unicode strings.

That's a good question, I'm not sure what Lektor passes. You think I should encode the strings to UTF8 first?

I've never had to use it myself so I don't understand the subtleties of how Python 2's regex package handles byte strings vs unicode strings - that's one of the reasons I'm wary of trying to maintain a 2.7-compatible package.
I'd be inclined to add a re.UNICODE flag to all the regex calls and a u prefix to every string literal and then give it only unicode strings as input.

That's only necessary if you're using things like \w, it makes re match on unicode characters as well. You're only using \s as far as I can see, so you should be fine.

Doesn't \s match on different character sets depending on whether the unicode flag is passed - ascii whitespace vs unicode whitespace?

It does, but they're few enough that I don't think anyone is ever going to notice that. Still, you're right, if you want to be 100% compatible you'd need that.

Sure, I think in 99.9% of standard use cases it would be perfectly fine. I'm more concerned about these kind of ambiguities opening up exploitation vectors if somebody is parsing untrusted user data.

Ah, fair enough, you're right.


AndroidX support

Just wanted to start this conversation.
It appears that jetifying (automatically rewriting binary) fails badly.
Anyone had luck with enabling the androidX flag?

Can not build on rn 0.60 because of this

Jetifying works for me now BTW

@simonbuerger  are you using the flag only ?

@jeveloper no, npx jetify postinstall hook

It's just been merged in #395. Thank you all for reporting


Proposal to allow passing json string configuration to pay buttons

One proposal that allows the GooglePayButton, ApplePayButton, and PayButton to accept a string which can either be the payment configuration or the payment configuration file.
#7

Hi @adxzhang1, thank you for taking a stab at this one.
I think it'd be clearer to have two different properties that clearly reflect the expectation to receive an asset or a JSON string respectively. This allows us to use clear rules to differentiate the two, instead of arbitrary conditions (eg.: a file with JSON contents many not necessarily need to include the .json extension).
I'd suggest we add a separate property (eg.: paymentConfigurationString) and control with assertions that only one of them is set at init time.
What do you think?

Hi @adxzhang1, thank you for taking a stab at this one.
I think it'd be clearer to have two different properties that clearly reflect the expectation to receive an asset or a JSON string respectively. This allows us to use clear rules to differentiate the two, instead of arbitrary conditions (eg.: a file with JSON contents many not necessarily need to include the .json extension).
I'd suggest we add a separate property (eg.: paymentConfigurationString) and control with assertions that only one of them is set at init time.
What do you think?

Hi @JlUgia, I totally agree, that would be much better!

Hi @adxzhang1, would you be willing to adapt your PR based on the conclusion above?
I've re-read the change, and we'll only need to make adjustments to the naming.
I can take it over otherwise.

Hey @JlUgia - just updated.

oh need this feature to use dynamic configuration instead of static json asset ! all check passed

@JlUgia Please consider merging this important one. We need this

@JlUgia included those changes

LGTM
Any additional thoughts @domesticmouse?

Hi @adxzhang1, apologies for the delay on this.
Here are two small suggestions (1, 2) to make things a bit more readable.
Feel free to include them in this PR, and we are ready to merge.

Closing in favor of #178 (released as version 1.1.0)


10 suggestions for improving keyvalue api

The wasmcloud:keyvalue api has several inconsistencies and spots where it could be improved. These are a few opinionated suggestions.

Don't have implementation-defined results

ListClear : may or may not delete the list
Range parameters may be open or closed, implementation-defined
The interface should be defined with clear meanings for parameters and results. The provider implementer should implement the interface spec, even if it means they have to do extra code to adapt the interface to a particular back-end.
If the spec is indeterminate, then a developer either won't use it, or they have to depend on a specific implementation, negating the value of a generic interface.

This API is not a very generic key-value store. Many of its functions are relatively unique to Redis. A "lowest-common-denominator" type of interface would more closely model a hashmap, or a btreemap if you want sorted keys.

Clear() was defined to return a String. Why not nothing?

Get returns two values: (string value + boolean exists) - replace with "struct MaybeValue { value: Option }"

Set and Del return a string (which is implemented to return the request key, which the caller already has). A cleaner result would be to return nothing (void), or, alternately, implement them to return Option with the previous value, if it existed

List methods naming consistentency:

ListDel (rename from Clear and clarify that it deletes the list after removing items),
ListItemAdd (rename from Push),
ListItemDel (rename from ListItemDelete)
ListiItemExists (new, parallel to KeyExists)

Set methods naming consistency: SetDel, SetItemAdd, SetItemDel, SetItemExists, parallel to List methods

Range improvements:

rename existing Range to ListItemRange
add range query for values: KeyRange (return range of keys), ValueRange (return range of KV pairs). For both KeyRange and ValueRange, rage start/end should be strings.

All values (including list and set items) should be type blob .(non-empty array of bytes), so keyvalue can store arbitrary data, not String, which is limited to utf-8.

All range queries should use pagination

Wondering if maybe we should make these changes, but do so under a new contract ID called wasmcloud:keyvalue:v2 ? I know there aren't many people actively using these providers in the 0.18.x space, but for consistency we should honor contract versioning given that this would be a large breaking change.
Opinion wise - I suggest we not implement anything that queries keys. There are a number of key-value stores where access to the list of available keys/keyspace is not possible. Even in Redis where it's possible, it's difficult to do without blocking the entire database (you need to use a "key cursor" rather than running the KEYScommand)

a new contract ID called wasmcloud:keyvalue:v2

yes it would need a new contract id

it's difficult to do without blocking the entire database (you need to use a "key cursor" rather than running the KEYScommand)

You need a key range request for a lot of object schemas, for example, if employees are keyed with "employee.LAST_NAME.FIRST_NAME", the way you query all employees is starting at "employees."
All range requests should be paginated. the range request api would contain a start key, optional end key, and a limit number. The limit number is just advisory - the provider can return any number up to (but not greater than) the requested limit number. The provider can set a limit number low enough to make it effectively non-blocking. Each response returns a watermark token that would be the start-value for the next range request.

Redis, IIRC, doesn't support key range queries out of the box, so the provider would actually have to create some kind of secondary index to manage this or worse, get all keys and then do the range filtering in memory in a loop.

Scratch that,  looks like you can accomplish a range query in Redis by using a match clause inside a sscan, e.g. sscan myset 0 match f*

document clarification (for a future revision of this interface):
to allow an implementation to use separate "keyspaces" for different data types, (kv, list, set, and counter), if the same key is used in different keyspaces, the results are undefined. For example, if list-add ("foo", "x") is followed by get("foo"), the get() may return a value, or None, or an Error. Another example: for the operations list-add("foo", "x"),  set("foo", "y"), list-clear("foo"), get("foo"), an implementation may return either Some("y") or None.
To accommodate separation of keyspaces, it may make sense to expand some of the existing apis:
del -> del (for kv), del_counter, del_list, del_set
contains -> contains, contains_counter, contains_list, contains_set
and add: set_counter, get_counter, because kv methods may not work to initialize the counter to a non-zero value, or to non-destructively read the value.

This issue should be in the Interfaces repo instead of wasmcloud-otp


Change tiny image used for startup checks to Ryuk image

For now we'll just upgrade the tiny image to a newer, M1 ARM friendly, version of Alpine.


Fix some errors and warning when compiling with visual studio.

This pull request fixes some issues when compiling with visual studio, including https://github.com/phs/sauce/issues/5.

Howdy!  Thanks for putting this together, let me take a look.  Offhand the only piece I find a little controversial is the third commit, maybe you could explain the problem there in more detail?
I notice also that the infrastructure in this repo is looking a little 2010.  I'm going to get it wired up with some virtualization support and build services (including one for windows) before doing anything else.  Once that lands (probably later today) hopefully you won't mind rebasing.

In that 3rd patch that test was failing because the mock allocator function for Herbie was being called before the chasis or engine functions. My thought was that the order really doesn't matter as long as Herbie ends up with the correct CoupChasis and Hybrid engine which is already verified with the other asserts in that test.

Looks like you've been busy and taken care of a couple of these! Do you still want me to rebase any of these patches?
On another topic, have you ever considered trying to add something like the assisted inject feature guice has? It would be nice to have for a project I'm working on and was thinking about trying to add it. I wondered if you had any ideas about it?
Thanks for the great library!

Yea, getting modern clang happy for OS X seems to have led me to the same spots.
I believe I also fixed the underlying issue requiring you to change the test in the 3rd commit: see if the current master works cleanly for you with MSVC.

You asked about assisted injection; I hadn't really thought about it, but if the feature fits cleanly into a header-only library that deliberately does no code generation, then groovy ^_^.

I pulled in your changes and msvc doesn't like them at all. :) I get a bunch of these compile errors
error C2951: template declarations are only permitted at global, namespace, or class scope
It looks like it has something to do with your changes to apply_variadic, don't have time to look at it at the moment though.

Ok.  I'm also trying to get appveyor happy, which is a build service that offers (my only) access to MSVC.  Hopefully whatever you're bumping into will fall out from that.

Yea, appveyor is giving me something similar.  Are these the errors you see?
https://ci.appveyor.com/project/phs/sauce/build/1.0.64/job/lw97bsblqtq6l844

Those errors from appveyor are what I was seeing.
I reverted the changed that caused that to work on the allocate_shared patch I commited and after that patch I'm not seeing the unit test failure any more. I might have misunderstood what the original failure was. Take a look and see what you think.

The original failure was the fact that the dependencies were being injected (constructed) after the thing they are injected into.  That seems counter-intuitive, but there it is.
The core issue was my choice in apply_variadic to inline the expressions that provide the dependencies into the constructor/function/method calls: arguments can be evaluated in whatever order the compiler wants (and apparently they can be evaluated after the function call itself?  That was new for me.)
Anyway, I extracted the sub-expressions to locals to force a "sequence point" in pre-C++11 lingo.  Then all the dependent side-effects (including observation by my mocks) would complete before the dependent call was ever made.
On the way I extracted some typedefs to make the template magic easier on the eyes.  I don't know yet but I guess this may be where I made MSVC angry (though my typedef is not a template, and indeed the other two compilers vouch that there are no templates within functions.)

std::allocate_shared (& alternate implementation friends) are new to me, I'll take a look at them vs. placement new.

We've seen the make/allocate _shared functions have some pretty significant performance improvements in certain scenarios. Based on the failing builds it looks like tr1 didn't have allocate_shared though. I'm also not sure if I picked the correct boost header, trying to do it from memory. I can verify that tomorow.

Well boo.  Pretty sure this is us (and a few spots in gmock as well): https://support.microsoft.com/en-us/kb/241940

Wait.  All the C2951 errors reported by appveyor are in injector.h or the vendored gmock/gmock-matchers.h, not (seemingly) apply_variadic.  Could you post a log of the warnings you're seeing (or just the sauce files with line numbers?)  Did you say you were able to rejigger something to get no warnings at all?

With the 849c9c7 patch included I'm not getting any warnings at all. It looks like all the warnings from that appveyor output is just due to the fact that the /EHsc compiler flag wasn't enabled. I do have that enabled in my project.

Interesting.  On the linked appveyor build (such as here) I'm seeing lots of error C2951: template declarations are only permitted at global, namespace, or class scope, in addition to the lack of exception semantics controlled by /EHsc.

Surely you don't mean the latest appveyor build for this PR, which errored out due to basic config not being set.

Maybe I misread your other comment. I'm seeing all of those C2951 errors when building master, essentially the same thing appveyor was reporting. I'm not seeing any compiler warnings though.
To get everything working locally I reverted your last change to apply_variadic and used the 3 patches in this pull request.  Then I had no errors or warnings.

Ok, that makes more sense.  I'll revert the latest master commit & get the appveyor config merged so we can prove that appveyor will do what you're seeing locally.
Then I'd like to try other variations of the reverted commit, since I do believe the current behavior allows the compiler to introduce subtle bugs.

Ok, offending commit reverted & appveyor config merged.  Try rebasing now.

Hello!  Since you're still out I'm tempted to pull in just your first two commits in a new PR, in an effort to get MSVC happy (& not cheat you out of the authorship.)
I'm open to working more on integration allocate_shared but since that's a different topic (not merely compiler warnings) I think it should go in a separate PR from the first two commits.

Yup that seems like a smart approach. I can push a new patch here in a minute.

Groovy, that's looking pretty good.  The linker problem probably just needs me to pass /entry:mainCRTStartup.

The missing flags appear to be in & working now, feel free to rebase.

Your commits appear in #20


Add runner for Node 20 LTS

Please check our current Issues to see if someone already reported this https://github.com/Microsoft/azure-pipelines-task-lib/issues
Environment
azure-pipelines-task-lib version: 4.3.1
Issue Description
Please provide a node20 task runner
Expected behaviour
I'd like a node20 task runner to run node 20 code.
Actual behaviour
There are runners node, node10, and node16, representing LTS releases of NodeJS.
Logs
Don't get me wrong, my code works fine. I may be misunderstanding, but I'd just like to see a node runner for each nodelts release.

I would like to see this also. As far the tasks.schema.json concerns, the execution handler Node20_1 does not exist. (While it does at agent side.)
In a task I have:
"$schema": "https://raw.githubusercontent.com/Microsoft/azure-pipelines-task-lib/master/tasks.schema.json",
"execution": {
    "Node20_1": {
      "target": "$(currentDirectory)/taskfile.js",
      "argumentFormat": "",
      "workingDirectory": "$(currentDirectory)"
    }
  }

And VSCode shows:
Property Node20_1 is not allowed.

For the curious one:
Runner updates for Node20:

https://github.com/microsoft/azure-pipelines-agent/pull/4346
https://github.com/microsoft/azure-pipelines-agent/pull/4518

task-lib update for Node20:

#1039
#962

It seems that Node20_1 is usable as this task use it already: https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/NotationV0/task.json

According to this Azure DevOps changelog it has been released even if the diff. PR are still open..
See how-to notes.

Docs look good, can't wait to use the node20 runner :)


Install.ps1 fails on v4.4.2 (IDFGH-8052)

Environment

Development Kit: none
Kit version (for WroverKit/PicoKit/DevKitC): n/a
Module or chip used:  n/a
IDF version (run git describe --tags to find it):
// v4.4.2
Build System: idf.py
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
// n/a
Operating System: Windows
(Windows only) environment type: PowerShell
Using an IDE?: No
Power Supply: n/a

Problem Description
In b28d7e6850936a9e5bbf542fa1d55adf6f9ae2f3 both  --features=${FEATURES} was added to the command to install the Python environment, and the variable was defined:
$FEATURES = (python "$IDF_PATH/tools/install_util.py" extract features "$args")

But the variable is used and not defined in https://github.com/espressif/esp-idf/blob/v4.4.2/install.ps1. I don't think this matters, since --features is an unrecognized argument in https://github.com/espressif/esp-idf/blob/v4.4.2/tools/idf_tools.py:
install_python_env = subparsers.add_parser('install-python-env',
                                           help='Create Python virtual environment and install the ' +
                                                'required Python packages')
install_python_env.add_argument('--reinstall', help='Discard the previously installed environment',
                                action='store_true')
install_python_env.add_argument('--extra-wheels-dir', help='Additional directories with wheels ' +
                                'to use during installation')
install_python_env.add_argument('--extra-wheels-url', help='Additional URL with wheels', default='https://dl.espressif.com/pypi')
install_python_env.add_argument('--no-index', help='Work offline without retrieving wheels index')

Expected Behavior
The Python environment is installed
Actual Behavior
The Python environment is not installed
Steps to reproduce

On Windows, delete the local IDF folder
Delete the local tools folder
Clone the v4.4.2 tag
Run install.ps1

Code to reproduce this issue
git clone -b v4.4.2 --recursive https://github.com/espressif/esp-idf.git esp-idf-v4.4.2
cd esp-idf-v4.4.2/
install.ps1

Debug Logs
Setting up Python environment
usage: idf_tools.py [-h] [--quiet] [--non-interactive] [--tools-json TOOLS_JSON] [--idf-path IDF_PATH] {list,check,export,install,download,install-python-env} ...
idf_tools.py: error: unrecognized arguments: --features=

Hi @AEFeinstein. Thank you for letting us know. We'll fix it soon.

Thanks!

The fix for release/v4.4 branch is available in https://github.com/espressif/esp-idf/commit/a1f03817975d29fc332e81d0420859bb8677053e and will be part of the next v4.4.3 bugfix release.
https://github.com/espressif/esp-idf/commit/5d1a51db65e2a9de71f2361d47317b4e5daf27b0 fixes the same bug for release/v4.3.

Excellent. Is there a timetable for 4.4.3?

Not at the moment, I'm afraid. Currently we are working on v4.2.4 bugfix release, next will be v4.3.4. Once these two releases are done, we'll start working on v4.4.3.

Okay. Good luck on all the releases!


[main] Upgrade to latest dependencies

Release 1.4 deps upgrade -ikvmw
/cc knative-sandbox/client-writers
/assign knative-sandbox/client-writers
Produced by: knative-sandbox/knobots/actions/update-deps
Details:
bumping knative.dev/client bb7fd73...d8ab3d5:
  > d8ab3d5 upgrade to latest dependencies (# 1658)
  > 9154f26 Fix build warning from go version upgrade (# 1657)
  > b858dab Added subpath functionality to --mount flag (# 1655)
  > 7e8a672 upgrade to latest dependencies (# 1656)
  > bb055ee Added scale-metric flag to configure metric name (# 1653)
  > 76f17f6 Upgrade Go to 1.17 (# 1654)
  > 1cb29fb upgrade to latest dependencies (# 1652)
  > 2929f38 Added flag to configure wait-window between intermediate errors durin… (# 1645)
  > 0ac405d Add timeout option to service create (# 1643)

/approve
/lgtm


Incorrect "Daily new cases per 100k" for DC (and likely others)

Below screenshots taken at 8:10pm ET 3/1/21 from https://covidactnow.org/us/district_of_columbia-dc/?s=29911850

When using the methodology at Risk levels & key metrics

Both https://api.covidactnow.org/v2/county/11001.json and https://api.covidactnow.org/v2/county/11001.timeseries.json have data up until 2/28 (238 new cases, matching above screenshots). The data also matches a 7d moving average of 123.9. They also note a population of 705749 (used below).
(238 + 0 + 0 + 112 + 100 + 48 + 369) / 7
----------------------------------------     =
              705749 / 100000

123.9
------     =
  7.1

17.6

Notice that the calculation is in agreement with the screenshotted charts, in that the 7d average of new cases is 123.9. Note that the calculation is NOT in agreement with the presented 7d average of daily cases per 100k since 17.6 != 11.9.
I don't think it has to do with newer data being available, since 2/28 is the latest available from NYT as well.
https://github.com/nytimes/covid-19-data/commit/d926226498cb9ee0c2a5053dda582f6079286574
(Cached) us-counties-recent.csv
This doesn't appear to be an issue of the time window moving forward, though I could be wrong.
(0 + 238 + 0 + 0 + 112 + 100 + 48) / 7
----------------------------------------     =
              705749 / 100000

10.1

Again, 10.1 != 11.9
Could this be due to improperly applying smoothing/prediction to the data?

Alternatively, the population could be incorrect? By my calculation that would mean using a population of 1,041,176 instead of 705,749...

@BrettBoval you were last to due issue triage work - can you help redirect?

Hey. Thanks for the ping and the detailed issue report. Going forward, we also check<EMAIL_ADDRESS>more frequently, but pinging both works.
We have code that back distributes data when there has been a reporting gap. So in the example you've given, some of those 369 cases on Feb 22 will be distributed back in time out of the averaging window. When I use 369/4 for that day's value (4 in the denominator because it has to cover that value plus three non-reporting days before), then the averages check out.

We do that backfill because localities unfortunately skip reporting days in a non-periodic manner. In this case they skipped a day over the holidays and then just reported them all in one day when they get back. If they consistently skipped weekends that would be fine (since you'd drop out a blank weekend when you gained a new blank one), but we need to do something when they vary the gaps.

Thanks for the explanation. Don't know how actively you all are doing development right now, but it would be great to add this info in some form to Risk levels & key metrics. Would also be great if I could reproduce the results - I'm blocked on knowing non-reporting days vs days with 0 cases.
How do you all make that determination? Is there a way for me to know within the API-returned json? Thanks in advance.

Hi,
regarding,

I'm blocked on knowing non-reporting days vs days with 0 cases.
How do you all make that determination? Is there a way for me to know within the API-returned json?

Admittedly, this is a problem that we don't have an elegant solution for. At the moment, we assume that "Covid is everywhere" and treat all zeros as non-reporting days. This has worked well throughout Omicron where case counts have been so high, but we may need to re-evaluate if/when case counts ever start trending towards zero.
In action, this means that,

We treat all strings of non-trailing zeros as reporting gaps to backfill over, with the exception that we do not back distribute for reporting gaps larger than seven days long.
We remove any trailing zeros from the timeseries to preserve the last non-zero reported value. If a location reports at least ten days of consecutive trailing zeros, then we treat this data as actual zeros and we no longer remove them.

I hope this is helpful, but please let me know if you have any further questions! I'm also willing to point you towards the source code that drives these calculations, too, if that would be of interest.

I'm going to mark this as closed. Let me know @akeybl if you still have questions.


No hotkeys for switching clefs

There should be some hotkeys (c & f) of which you can switch the clef head shape.

Completed in 	ae9b5e7


refactor: normalize namespace import name for @opentelemetry/api

Which problem is this PR solving?

Address comment on https://github.com/open-telemetry/opentelemetry-js/pull/1001#discussion_r419612373

Short description of the changes

Renamed all namespace import of @opentelemetry/api variable name to api.

Codecov Report

Merging #1016 into master will increase coverage by 2.58%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1016      +/-   ##
==========================================
+ Coverage   95.00%   97.59%   +2.58%
==========================================
  Files         212        7     -205
  Lines        8806      457    -8349
  Branches      796       24     -772
==========================================
- Hits         8366      446    -7920
+ Misses        440       11     -429

Impacted Files
Coverage Δ

...ages/opentelemetry-core/src/platform/node/index.ts

...ntelemetry-tracing/test/MultiSpanProcessor.test.ts

...rces/src/platform/node/detectors/AwsEc2Detector.ts

...pentelemetry-plugin-https/test/utils/assertSpan.ts

...ackages/opentelemetry-core/src/platform/node/id.ts

...opentelemetry-api/src/metrics/NoopMeterProvider.ts

packages/opentelemetry-tracing/src/version.ts

packages/opentelemetry-tracing/src/config.ts

...ackages/opentelemetry-web/src/WebTracerProvider.ts

packages/opentelemetry-plugin-grpc/src/version.ts

... and 175 more


Updating the Raspberry Pi directions

After creating your pull request, tick these boxes if they are applicable to you.

[ ] I have tested my changes against the review branch (the latest developmental version), and this pull request is targeting that branch as a base
[ ] I have tested my changes on Python 3.5/3.6

Description
raspbian already comes with sudo, and all the seperate apt-get commands weren't really necessary. also, the repositories don't work on raspbian and "make -j4" should be used on newer pi's (like the 2B, 3B, and 3B+, but not the zero or zero w)
Related issues (if applicable)
running through the steps as is appears to install a version of pip and then proceed to replace it with a newer version, is this step really necessary?

#1671 appears to have superseded this.


Stop calling function components stateless

These docs still refer to function components as "stateless function components" despite the fact that function components aren't necessarily stateless (anymore). The docs shouldn't use this outdated terminology anymore.
I left the "stateless" in the link to avoid breaking existing links to these docs but can remove if keeping links valid isn't a priority.

Sure.


[geos] update to 3.9.0

Library name: geos
New version number: 3.9.0
They fixed a few sketchy memory leaks. Nice to have those.

Solved by #16572


Implement Windows support

Still TODO:

[ ] Get cargo-compare running on Windows.

Some of the failures we're seeing are:
thread 'tests::workspace_tests::cargo_guppy::proptest_compare' panicked at 'compute_diff succeeded: failed to read `\\?\D:\a\cargo-guppy\cargo-guppy\internal-tools/benchmarks\Cargo.toml`

Caused by:
    The filename, directory name, or volume label syntax is incorrect. (os error 123)', internal-tools\cargo-compare\src\tests\proptest_helpers.rs:42:10

thread 'tests::workspace_tests::inside_outside::proptest_compare' panicked at 'compute_diff succeeded: package collision in the lockfile: packages external v0.1.0 (D:\a\cargo-guppy\cargo-guppy\fixtures\workspace\inside-outside\external) and external v0.1.0 (D:\a\cargo-guppy\cargo-guppy\fixtures\workspace\inside-outside\workspace\internal-macro\../../external) are different, but only one can be written to lockfile unambiguously', internal-tools\cargo-compare\src\tests\proptest_helpers.rs:42:10

Tagging this as "help wanted" -- I don't really use or target Windows for development so it would be good to have experienced Windows developers fix up any remaining issues.


Student list now links to student profile

Who is this PR for?
Administrators using the attendance dashbord
What problem does this PR fix?
In #1264 @alexsoble suggested adding links to the student profiles of the students in the attendance list. This would allow admins to quickly get contact info for a student
What does this PR do?
Adds links to student profile from dashboard
Screenshot (if adding a client-side feature)
Checklist

[X] Tested latest version in an Internet Explorer virtual machine? (If the PR adds Javascript.)

@alexsoble @snoopyuri Adding links to the student list was pretty simple, so if we decide that's a sensible feature (I vote yes), we can merge this any time.

@edavidsonsawyer Great! I like this feature/PR because it follows the pattern we set in the school overview of student list items being links.

Looks great in IE, let's 🚢 .

@edavidsonsawyer Looks good in prod mi amigo.


Could not find component: deployment production

I deproyed successfully with capistrano3.
But, developer tool's Console in error.
Uncaught TypeError: o is not a function
    at Object.<anonymous> (index.js:1217)
    at Object.<anonymous> (index.js:1667)
    at n (index.js:57)
    at Object.<anonymous> (index.js:1097)
    at n (index.js:57)
    at Object.<anonymous> (index.js:816)
    at n (index.js:57)
    at Object.<anonymous> (index.js:690)
    at n (index.js:57)
    at index.js:178
(anonymous) @ index.js:1217
(anonymous) @ index.js:1667
n @ index.js:57
(anonymous) @ index.js:1097
n @ index.js:57
(anonymous) @ index.js:816
n @ index.js:57
(anonymous) @ index.js:690
n @ index.js:57
(anonymous) @ index.js:178
(anonymous) @ index.js:5
n @ bootstrap:19
(anonymous) @ index.js:1
n @ bootstrap:19
(anonymous) @ Heading.js.jsx:37
n @ bootstrap:19
(anonymous) @ bootstrap:83
(anonymous) @ bootstrap:83

Uncaught Error: ReactOnRails encountered an error while rendering component: BlogApp.
Original message: Could not find component registered with name BlogApp. Registered component names include [  ]. Maybe you forgot to register the component?
    at Object.get (ComponentRegistry.js:58)
    at Object.getComponent (ReactOnRails.js:196)
    at m (clientStartup.js:135)
    at clientStartup.js:59
    at f (clientStartup.js:72)
    at v (clientStartup.js:180)
    at HTMLDocument.b (clientStartup.js:213)

I was able to connect correctly in the localhost

I think you'll need to do some debugging.
The error message means your bundles are not setup correctly, and so the message is pretty clear:
"Registered component names include [  ]."


unicode support !

unicode support

@xywf221
Unicode is already supported. All you have to do is just load a font which support your language.
Check out the commented code in the example code.
https://github.com/AllenDang/gimu/blob/master/examples/simple/simple.go


add missed properties to task.json schema

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: teh13th sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@damccorm @jtpetty hi! Can you merge this PR?


Fix invalid file usage for WinShell programs.

For some reason, fixes #430.
Needs testing on other machines to confirm.

It should close them since I am using a using statement. But for some reason it... didn't.
Again, though. Needs testing on other hardware.

But for some reason it... didn't.
Are you sure it is the case and that the bug might not be somewhere else?

So, apparently the bug might be in IMDThumbnail where the object SelectedItemStream is not disposed? https://github.com/dwmkerr/sharpshell/issues/339

So, apparently the bug might be in IMDThumbnail where the object SelectedItemStream is not disposed? dwmkerr/sharpshell#339

You did not file an issue for IMDThumbnail, but rather, IMZExtract.
I have tested all four with this change in this case. However, I will look into this.
SelectedItemStream does not affect IMDs in IMZExtract.

Addressed it just in case.


startry/SwViewCapture

SwViewCapture - A nice iOS View Capture Swift Library which can capture all content.
Language - Swift.

https://github.com/vsouza/awesome-ios/pull/2313


merge vs squash and merge vs rebase and merge

In-depth difference between these three.
When to use which
Which one is recommended to use when working on a big project in collaboration

you can do a video by the way if you want and put above image as a thumbnail (as clickbait) 😜

I will probably do a video on this in the future, but I will answer it now as I have a bit of a video queue at the moment 😂

create a merge commit will add a new commit with the merge, so in the history you will see when it was merged and all the other commits are in the history too
squash and merge will still create a new commit but all the commits in the branch will be squashed into a single commit, so the history remains super clean, then it is possible to cherry pick out features
rebase and merge will rewrite history so the commits in the PR are on top regardless of when the original commit was

More information in the GitHub docs https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges


feat: Allow underscores and hyphens in account name

#1046
Allow hyphens and underscores in account names

I think this change will break account auto provisioning in OIDC.
Have you test compatibility?

I don't use OIDC. I can get a look at the code or we can summon the folks you did recent updates on this.

@benshalev849 @dimpapac
I can see you worked on OIDC, could you give a feedback about this change's impacts ?

@RGanor I'd really enjoy if this could be merged soon, because I need to push my terraform code too and changing the name of the objects will destroy everything and recreate. I'd prefer to have the ability to use these extra characters at first.
I will do my best to double check the OIDC related code tomorrow.
(Looking at the light change in this PR and not using OIDC now I can patch my code locally meanwhile but I'd really prefer to use an official release instead)

Hey, this can break anyone that has been using OIDC groups authentication atm.
This is because now if the account OIDC created is named:
example_account
the actual account name will be:
exampleaccount
If this change will be pushed new accounts will be created  thus needing to add new permissions.
My suggestions is to add your change as a basic option that the user can toggle.
"Allow underscore in account name"
So it's on the users to choose if they want it or instead of doing it globally for everyone.

I looked at the code and updated the corresponding check on the OIDC processing section. What is involved here:

in the edit page, when submiting the account object formats the name at init, if the entered name does not match the field is marked invalid
in oidc group import, the check is done the same way in the handle_account function (updated)
in azure, it seems inconsistent to me. The code looks for a setting in Azure config. The setting is a regex entered by the admin. If it does not match, the account is not created but: if the setting is empty or it passes the regex, the create function is called. The created account is formatted according the pattern in the object model, meaning that the name provided by azure won't match the name in PDA (if I let the setting empty or set it to .*, a group named group+something will be created with the name groupsomething, If the user is in group%something, it will also be added to the same group).
in the API, no check is done either. You post an account named "group%name" and the API will create and returns "groupname".

The limitation may have been made with the idea that through the API and HTTP URIs we want to limit to characters that do not need encoding (but hyphens, underscore or even the dot don't). It's just a name in a table, so i think it's ok to allow these characters.
I can push a little farther to implement a control in the API and Azure if you want. It should be fast to write the code.
Regards

@benshalev849 yes you're right, it logs an error but changes the name. Adding such a setting can be an option.

Setting added, defaults to False

@zoeller-freinet @RGanor Thank you for your feedback on this one

Hi there!
My colleague @dimpapac is unfortunately absent at the moment, so I will respond on his behalf, since I was also a contributor on his OIDC-related PR. Your original change would indeed raise an issue to the Account auto-creating aspect of OIDC Provisioning, in its current format.
However his PR is basically an alternative to that form of OIDC Provisioning, where one can not only provision a user's associations with Accounts, but also with Domains, as well as the user's role (Administrator, Operator, User) in the Application.
His provisioning has also been implemented and merged for projects that make use of LDAP Authentication, and on top of that your change in its first manifestation would be fully functional if this provisioning were to be used.

@KostasMparmparousis Thanks for the feedback. I'm not quite sure about what you are talking about. I guess my english lacks a bit here so my answer here may not match.
First, this PR is about the Account name. I looked at @dimpapac PR (#1002) which seems to be about Users, which is not in the scope of this one. I've reviewed the OIDC current code and, though i'm not using it here, I could see what @benshalev849 's remark was about:
The automatic account provisioning just cleans out unauthorized characters from the created account name. There is no 1<>1 binding and we can run into issues like "account_A" and "account-A" and any combination of "ac-count.a" would result in the creation of the "accounta" account for all these three cases.
Although this patch wouldn't really solve it, a raw change in the allowed character would result in changing the former situation to the creation of 3 distinct accounts and messing up with ownership of domains and user's membership.
By adding a toggle option to enable this (default disabled), it should have 0 impact on existing content, unless unwisely enabled by an admin. What is your opinion ?

Your confusion is understandable, as the title only refers to users, however PR #1002  also features Domain and Account Association Autoprovisioning for Users, expanding on the current form of User-Account autoprovisioning in PowerDNS-Admin, as implemented below:
 #Gets the name_property and description_property.
            name_prop = Setting().get('oidc_oauth_account_name_property')
            desc_prop = Setting().get('oidc_oauth_account_description_property')
            account_to_add = []
	    #If the name_property and desc_property exist in me (A variable that contains all the userinfo from the IdP).
            if name_prop in me and desc_prop in me:
                accounts_name_prop = [me[name_prop]] if type(me[name_prop]) is not list else me[name_prop]
                accounts_desc_prop = [me[desc_prop]] if type(me[desc_prop]) is not list else me[desc_prop]

                #Run on all groups the user is in by the index num.
                for i in range(len(accounts_name_prop)):
                    description = ''
                    if i < len(accounts_desc_prop):
                        description = accounts_desc_prop[i]
                    account = handle_account(accounts_name_prop[i], description)
                    account_to_add.append(account)
                user_accounts = user.get_accounts()
		# Add accounts
                for account in account_to_add:
                    if account not in user_accounts:
                        account.add_user(user)

Although @benshalev849 remark is indeed correct,  our suggestion was that, by using @dimpapac 's Autoprovisioning, account ownership could remain unaffected without the need to modify your contribution's original implementation.
Concerning your feature now, a toggle switch would be the only option in order to maintain compatibility for projects that use the current autoprovisioning method.

@jbe-dw
I added two comments on the code, could you please take a look? Please also resolve the merge conflicts.

Trying to summarize:

Not affected at this time as there is currently no feature that auto-provisions accounts via these mechanisms:

Google OAuth
GitHub OAuth

Will be handled by Account.sanitize_name:

API
Microsoft Azure OAuth
OpenID Connect

For LDAP, account associations can already be auto-provisioned if the autoprovisioning Setting is enabled ("Roles Autoprovisioning" radio button "ON" on the LDAP auth tab) (code entry point). In this case, the account (name) has to exist in PDA's DB beforehand - the purported account name is used as-is for this lookup. If it does not exist, it is not created and the user is consequently not associated with the purported account. This is the mechanism that PR #1002 seeks to make usable for OIDC as well.
Please mention if something is incorrect or missing.
@KostasMparmparousis
I don't understand how PR #1002 would remove the need to add a default-off compatibility setting that allows switching additional allowed characters for account names on or off. The PR does not cover the API and Azure OAuth cases. As for OIDC, supposing that #1002 is merged in its current form, there would be two ways to autoprovision accounts via OIDC: the one that is already part of master (the code you quoted), and the one facilitated by #1002. Users of the former would still require a toggle switch for compatibility, wouldn't they?
I haven't really looked into #1002 yet, and would prefer to consider it separate from this PR here. In general, adding compatibility toggle switches should be avoided if possible, and I'm not that keen on doing it, but it seems like a pragmatic solution in this case. I imagine it should be possible to remove the switch again and expand the set of allowed characters by default without losing account associations by triggering an interactive "migration" on SSO login as a way out. Maybe something along those lines could be implemented sometime in the future.

This could have been avoided if the application just rejected names not matching the allowed characters. This is also problematic on a terraform side. Terraform compares what user request and what leaves in the API. It means that if a user provides a name with unallowed character, the API would accept to create it and silently change it. On the next run, Terraform would see that the name with the id it received upon creation is different, and would try to update it, with no real effect in PDA. The code will then always request an impossible change, without failing.
This mean that it should be better to change the behaviour to reject the names that do not match the allowed character, in all the concerned modules (GUI/API or autoprovisioning).
@zoeller-freinet concerning Azure, as I said, the name is matched again a regex that is a setting. Calling the sanitized name would break the logic. It may need a bit of work. I don't remind it well (i was on holidays) I'll have a look shortly.
I'll also review the code for both OIDC and LDAP, to be sure.

This could have been avoided if the application just rejected names not matching the allowed characters. This is also problematic on a terraform side. Terraform compares what user request and what leaves in the API. It means that if a user provides a name with unallowed character, the API would accept to create it and silently change it. On the next run, Terraform would see that the name with the id it received upon creation is different, and would try to update it, with no real effect in PDA. The code will then always request an impossible change, without failing.
This mean that it should be better to change the behaviour to reject the names that do not match the allowed character, in all the concerned modules (GUI/API or autoprovisioning).

That's right, and this should be done. But it would not mitigate the need to add a compatibility setting like account_name_extra_chars, since we should assume that there already exist PDA DB instances that contain account names that originated from Azure or OIDC, and were then bent into a different account name by PDA before storage into PDA's DB.

concerning Azure, as I said, the name is matched again a regex that is a setting. Calling the sanitized name would break the logic. It may need a bit of work. I don't remind it well (i was on holidays) I'll have a look shortly.

Based on your comment on Azure here and my study of the code, I didn't notice any additional issue based on the state of this PR right now that isn't yet handled, but I didn't use Azure OAuth so far and may be missing something. I'll await your investigation.

Hello there!

For LDAP, account associations can already be auto-provisioned if the autoprovisioning Setting is enabled ("Roles Autoprovisioning" radio button "ON" on the LDAP auth tab) (code entry point). In this case, the account (name) has to exist in PDA's DB beforehand - the purported account name is used as-is for this lookup. If it does not exist, it is not created and the user is consequently not associated with the purported account. This is the mechanism that PR #1002 seeks to make usable for OIDC as well.

First of all, i would like to comment that you are spot on in regards to the functionality of LDAP Autoprovisioning and the rationale behind PR #1002.

@KostasMparmparousis I don't understand how PR #1002 would remove the need to add a default-off compatibility setting that allows switching additional allowed characters for account names on or off. The PR does not cover the API and Azure OAuth cases.

Furthermore, you are indeed correct. PR #1002 does not cover the API and Azure OAuth cases, only OpenID Connect. However, we felt the need to jump in,  in order to clarify that as an alternative to the current implementation, PR #1002 would not be affected by the proposed feature.

As for OIDC, supposing that #1002 is merged in its current form, there would be two ways to autoprovision accounts via OIDC: the one that is already part of master (the code you quoted), and the one facilitated by #1002. Users of the former would still require a toggle switch for compatibility, wouldn't they?

Finally, your intuition is correct. The two features do need to be mutually exclusive from one another. With that in mind, when enabling OIDC autoprovisioning ("Roles Autoprovisioning" radio button "ON"), we disable the current form of OIDC Account Autoprovisioning, upon confirmation from the user who gets shown this modal.


[SEO] Using  not possible without triggering  warnings

Describe the bug
Metatags won't load correctly if you're using conditional rendering inside _app.js.
Example 1:
 const { isBrowser } = useSSR();
  return (
    isBrowser && (
      <>
        <Head>
          <meta name="viewport" content="width=device-width, initial-scale=1" />
          <title>EXAMPLE ON TITLE</title>
          <meta name="title" content="TITLE" />
          <meta name="description" content="DESCRIPTION" />
        </Head>
        <NextUIProvider theme={theme}>
          <Component {...pageProps} />
        </NextUIProvider>
      </>
    )
  );

They will load correctly (viewable inside page source & for crawlers), if you do not use useSSR() like:
Example 2:
  return (
    <>
    <Head>
      <meta name="viewport" content="width=device-width, initial-scale=1" />
      <title>EXAMPLE ON TITLE</title>
      <meta name="title" content="TITLE" />
      <meta name="description" content="DESCRIPTION" />
    </Head>
    <NextUIProvider theme={theme}>
      <Component {...pageProps} />
    </NextUIProvider>
  </>
  );

But then there's problems with SSR and getting bombed with When server rendering, you must wrap your application in an <SSRProvider> to ensure consistent ids are generated between the client and server..
I have tried adding the following to package.json as noted in https://github.com/nextui-org/nextui/issues/779 with no success:
  "resolutions": {
    "@react-aria/ssr": "^3.4.1",
    "@react-aria/table": "^3.5.0"
  },

I tried the suggestion by https://github.com/nextui-org/nextui/issues/1038#issuecomment-1435346390 with no success:
  return (
    <SSRProvider>
      <NextUIProvider theme={theme}>
        <Component {...pageProps} />
      </NextUIProvider>
    </SSRProvider>
  );

Steps to Reproduce the Bug or Issue

Use same examples as above. You can reproduce it by using useSSR(), while conditionally loading all components.
Check Page Source in your browser to see if your <meta/> can be localised.

Expected behavior
Metatags will load correctly inside Page Source and be available to e.g. Google, Facebook, LinkedIn.
Operating System Version
Windows
Browser
Chrome

Which browser are you using?

I'm having similar issues, but I'm using an embedded webview, so I can't build the project anymore as isBrowser seems to return false:
Warning: useLayoutEffect does nothing on the server, because its effect cannot be encoded into the server renderer's output format. This will lead to a mismatch between the initial, non-hydrated UI and the intended UI. To avoid this, useLayoutEffect should only be used in components that render exclusively on the client. See https://reactjs.org/link/uselayouteffect-ssr for common fixes.
    at l (/frontend/node_modules/@nextui-org/react/cjs/utils/css-transition.js:1:746)
    at div
    at Styled.div
    at p (frontend/node_modules/@nextui-org/react/cjs/progress/progress.js:1:973)
    at div
    at Styled.div
    at div
    at Styled.div

@moloch--
I also have same issue, but I didn't use any embedded webview.
I just used ProgressBar from NextUI, but this erorr just occured for me.
Warning: useLayoutEffect does nothing on the server, because its effect cannot be encoded into the server renderer's output format. This will lead to a mismatch between the initial, non-hydrated UI and the intended UI. To avoid this, useLayoutEffect should only be used in components that render exclusively on the client. See https://reactjs.org/link/uselayouteffect-ssr for common fixes.
at l (C:\account-book\client\node_modules@nextui-org\react\cjs\utils\css-transition.js:1:746)
at div
at Styled.div
at p (C:\account-book\client\node_modules@nextui-org\react\cjs\progress\progress.js:1:973)
at div
at Styled.div
at C:\account-book\client\node_modules@nextui-org\react\cjs\container\container.js:1:843
at TodayGraphBar (webpack-internal:///./src/Components/Daily/TodayGraphBar.js:17:3)
at div
at Styled.div
at C:\account-book\client\node_modules@nextui-org\react\cjs\card\card.js:1:313
at div
at TodayGoal (webpack-internal:///./src/Components/Daily/TodayGoal.js:24:3)
at div
at Daily (webpack-internal:///./src/Components/Daily/Daily.js:28:3)
at div
at Styled.div
at C:\account-book\client\node_modules@nextui-org\react\cjs\container\container.js:1:843
at div
at Main (webpack-internal:///./src/pages/main.js:80:54)
at div
at $0775ea8ea6a0565e$var$OverlayContainerDOM (C:\account-book\client\node_modules@react-aria\overlays\dist\main.js:742:55)
at $0775ea8ea6a0565e$export$178405afcd8c5eb (C:\account-book\client\node_modules@react-aria\overlays\dist\main.js:706:21)
at $0775ea8ea6a0565e$export$bf688221f59024e5
at $29383e587d62412a$export$9f8ac96af4b1b2ae (C:\account-book\client\node_modules@nextui-org\react\node_modules@react-aria\ssr\dist\main.js:25:28)
at v.disableBaseline (C:\account-book\client\node_modules@nextui-org\react\cjs\theme\theme-provider.js:1:1046)
at $704cf1d3b684cc5c$export$9f8ac96af4b1b2ae (file:///C:/account-book/client/node_modules/@react-aria/ssr/dist/import.mjs:39:37)
at MyApp (webpack-internal:///./src/pages/_app.js:29:3)
at StyleRegistry (C:\account-book\client\node_modules\styled-jsx\dist\index\index.js:449:36)
at PathnameContextProviderAdapter (C:\account-book\client\node_modules\next\dist\shared\lib\router\adapters.js:60:11)
at AppContainer (C:\account-book\client\node_modules\next\dist\server\render.js:294:29)
at AppContainerWithIsomorphicFiberStructure (C:\account-book\client\node_modules\next\dist\server\render.js:330:57)
at div
at Body (C:\account-book\client\node_modules\next\dist\server\render.js:620:21)
When server rendering, you must wrap your application in an  to ensure consistent ids are generated between the client and server.

Hey guys sorry for the delay please upgrade to V2, SSR Provider is no longer needed.


link for talk is incorrect

the link to the talk info is incorrect. it should be in the format
eg: https://pretalx.linuxtage.at/glt19/talk/ZJVDJV/
https://pretalx.linuxtage.at/glt19/talk/[UNIQUE_ID]/
the URL is passed as info of an event.
<event> ...   <url>[URL]</url> ... </event>

For this to work I had to alter the DB schema. So all DB data is lost. However, this is not too bad, because the conference data should be refreshed anyhow.