video-* plugins: stim parameter name change and tests

These are the changes from @mgorenstein's pull request (#1171), merged into this branch so that I could also update the documentation and example HTML files with the new parameter name.
I also added tests to each of the plugin test files to make sure that (1) the plugin files are calling the registerPreload function, and (2) the parameter name that is used in that function exists in the plugin (to catch the stimulus/sources name error that was preventing video preloading before).

The easiest way I could think of to test whether an incorrect parameter name was used in jsPsych.pluginAPI.registerPreload was to modify jspsych.js so that it produces a console warning if the parameter in the preloads list is undefined, and then detect this console warning in the test. This test is working, i.e. it fails when jsPsych.pluginAPI.registerPreload uses a parameter name that doesn't exist in the trial object and passes when stimulus is used as the parameter name.

I couldn't get the jest.spyOn() function to work for spying on jsPsych.pluginAPI.registerPreload. I thought that this would work:const preload_spy = jest.spyOn(jsPsych.pluginAPI, 'registerPreload'); //... set up and run video trial expect(preload_spy).toHaveBeenCalled(); But this always fails, saying that preload_spy was not called. I kept this in the code but commented out the expect line to make the tests pass. @jodeleeuw any ideas/suggetions?

Also @jodeleeuw I realize that this sort of testing isn't quite what you meant in this comment, but figured this was the quickest way to see if I can get the preload tests working. I can test this in a different way and move the tests somewhere else if you prefer. I think including preload tests somewhere will be useful for #1258.

I wonder if the reason that .spyOn isn't working is because the plugin file is loading before the spy is created. The registerPreload method is called when the plugin is loaded for the first time. I believe in most of the tests we load the plugin file before running the test. Maybe for this test we need to load jsPsych, set up the spy, and then load the plugin.

@jodeleeuw yep that was it - fixed the tests now. Thanks!
Is this ok to be merged?


megalodon input, which file?

Hi,
I was just wondering which megalodon output file I should use as input.
I have tried mappings.bam, modified_bases.5mC.bed, mod_mappings.bam and per_read_modified_base_calls.db, but I always get Error in guess_methy_source(element$file) : Format not recognised..
Cheers

You need the tab-delimited output from megalodon which can be produced either by adding --write-mods-text when running or using the megalodon_extras per_read_text modified_bases command after running megalodon.
https://nanoporetech.github.io/megalodon/file_formats.html#per-read-modified-bases
Thanks for asking the question, I will add this into the documentation for future releases.


Contribute a brief guide on how to isolate cpu core(s)

Resolves: CAS-687

To be honest, I haven't tried to render the updated gitbook so I'm not sure how it will look like. Hopefully not bad.


Feature request: Support for Native Desktop applications

Use case scenario:

application packaged as .EXE
application uses ANE native extension

Right now only mobile projects are supporting ANEs.

This feature would be awesome as we want to automate building our extendedDesktop (with ANE) as exe-package file. Was there some progress on this topic, is it scheduled, or do you have a sort-of-hack using a recent gradlefx installation?

No progress has been made on this topic and currently it isn't scheduled yet.
If you're looking for a workaround, then the solution proposed in this thread might be helpful: http://support.gradlefx.org/discussions/questions/3577-how-can-i-build-and-create-ane-package-with-gradlefx

Many thanks for your quick response. Correct me, if I'm wrong, your proposed workaround targets "compiling the ane" but I need to "compile an exe including the ane", so "extension" vs "application". So, your workaround is not applicable, at least from my current point of view, please correct me if I'm wrong.

I think it does apply to your usecase, since both endpoints (ane extension or exe application) need to be compiled with the ADT compiler, which is being used in the example.
The major difference lies in the arguments which you provide to adt. For an exe application it will be "-target native" instead of "-target ane"

Thanks, seems you have uncovered my unknowingness :), if easily possible, I'm going to share my solution.

Hi, just to wrap up this topic, for everybody having the same problem:
I got around this issue without having to build my own packaging command by injecting the needed command line parameters into an 'air' target:

I misused the TSA configuration to inject the target:
tsa = config.timestampServer+"" "-target" "native"

I misused the fileOptions within the air target description to inject the extdir:
fileOptions = ["-extdir", "libs"]

and - the installer is built :-)

For anyone who is interested my solution was to shamefully drop using gradlefx and use only gradle + javaexec for packaging:
https://github.com/vpmedia/cryptopp-ane/blob/master/tester/build.gradle (package_exe .. not sure this one is working but you can get the idea)


[iOS] Images loaded by file are loading cropped and rotated

Loading images by file seem to be loading as a cropped square, by the top of the image, and then rotated -90 degrees.   Tested on multiple iOS devices, as well as on an android device- only iOS seems to have this issue.
Using the Camera Plugin, I am seeing the image thumbnail show this way.  However when I revert to an older commit, 3581b3ae85d30c5677445e0072c81d1f32280270, the issue seems to go away. Looks like it's not a camera issue however, since images previously saved, are fine on this commit.
Flutter Doctor
[✓] Flutter (Channel master, v0.11.7-pre.47, on Mac OS X 10.14.1 18B75, locale en-US)
    • Flutter version 0.11.7-pre.47 at /Users/eric/Sdk/flutter
    • Framework revision 5385132c6b (10 minutes ago), 2018-11-16 16:53:59 -0800
    • Engine revision c02dd8f935
    • Dart version 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

[✓] Android toolchain - develop for Android devices (Android SDK 28.0.3)
    • Android SDK at /Users/eric/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /Users/eric/Library/Android/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.1, Build version 10B61
    • ios-deploy 1.9.4
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 22.2.1
    • Dart plugin version 171.4424
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[!] VS Code (version 1.29.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension not installed; install from
      https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[✓] Connected device (2 available)
    • SM T550        • df7be8621e58ec4f                         • android-arm • Android
      7.1.1 (API 25)
    • INN-005 (Eric) • caa370a312151f827f2d9fff2329411035e4a351 • ios         • iOS
      12.1

! Doctor found issues in 1 category.

Can confirm, experiencing the same issue on iOS in conjunction with camera.
Other images seem to be fine.

@Attict See https://github.com/btastic/flutter_native_image for a workaround. Seems to work fine for me.

Are you still seeing this? I think this was fixed recently.

Nope, this is fixed!  Thanks :)


LibTerm crashing after new update

I updated to LibTerm 5.0, and now it crashes whenever I open it.

Same for me.
Iphone 6, ios 12.3.1

Crash log file if thats helpfull:
LibTerm-2019-09-14-125237.txt

this is my crash report:
LibTerm-2019-09-13-164100.txt

Thank you! That is happening on iOS 12. I fixed the crash and a new update is coming soon. Sorry guys.

It's now fixed


Error event in flash fallback

HTML5 video tag has error events.
But I couldn't find any "error event" handle codes in a flash fallback.
Do you have any plan to develop such as error events handling?
https://github.com/johndyer/mediaelement/blob/master/src/flash/htmlelements/VideoElement.as#L217

I found this PR.
https://github.com/johndyer/mediaelement/pull/871

@Jinkwon Can you test 3.x-dev branch to see if this issue has been properly addressed, please?

Closing this issue since no answer has been posted in more than 2 weeks. If you'd like to reopen this, let us know. Thanks!


New assessment list

Code-review checklist

Documentation

[ ] Interfaces describe how other programmers would use them.
[ ] Code that is not obvious has documentation describing why
that code is the way it is.

Fix any console errors from your code, then it looks good.


in some cases test failure seen as [object Object]

In some cases, which need to be investigated yet, the test fails and instead of stacktrace the following text is shown:
[object Object]

fixed in a few iterations, finally landed in 2.0.0


added linePlusBarChart dispatcher type - renderEnd fix #55

This PR is probably created in error - merge commit already submitted as part of issue #55

Thanks @james-cordeiro for your help. I've been pretty slammed this days.


feat(Plugins): remove gcs connector

Remove GCS connector from plugins.
Changes
Please list / describe the changes in the codebase for the reviewer(s).

Remove references to gcs app
Delete models & write "delete migration"

How/what to test
A few words about what needs to be tested, along with specific testing instructions if needed.
Screenshots / screencast
If relevant, please add some screenshots or a short video.

Yes, that's kinda weird, it should only be one @pvanliefland

Remark: There are no GCS buckets in demo & production so we can safely ignore the use case of handling of the catalog migration


Effect on convolution of padding point clouds

Greetings @HuguesTHOMAS , in my extension of KPConv for partial point cloud completion it is necessary for the point clouds to be padded (via duplicating certain random existing points) in order for them to have a specific number of points.
I am doing this after the grid subsampling preprocess step of the current implementation. My question is: do you believe this will affect the feature extraction of the kernel point convolutions negatively  in any way?

Hi @no-materials,
Yes, padding point cloud will have an effect on the feature extraction, if you do not handle them properly. A point that appears two times, will count two times in the feature extraction process. If you want to negate this effect, you have to assign these new duplicates a feature equal to zeros. In that case, they will be "invisible" for the convolution, exactly like the shadow points that we already use.
Another thing is that having two points with the exact same position is not a good idea. Some of the operations in our network are based on distance and the gradient of distance is not defined when distance is equal to zero. This can lead to NaN values in the features. I would advise to add a small random noise to your duplicates so that you avoid any problem like that.
Best,
Hugues

I see! Thanks for the heads up!


StreamExt: add chunks and try_chunks

I love this crate a lot because of its wonderful api and elegant implement. I really need chunks and try_chunks method for StreamExt, which is missing in this crate. So I forked this repo, and added them. And I wonder if this could be merged.
The codes are mainly from futures-rs with some changes:

Remove Sink and FusedStream related things
Remove references to TryStream
Rename type parameter St to S
fix size_hints as mentioned here
rewrite some inline docs to fit futures-lite and changes above

Thanks a lot for your reviewing this :)

usize::div_ceil is stable since 1.73, while rustc in CI/msrv is 1.60.

I don't think this is the right API to expose in futures-lite, as it seems somewhat opinionated and allocation-heavy. Maybe an array_chunks-type API would be better, but that probably can't be done safely at the current MSRV.
So I don't think we should have this API. Thanks anyways!


[GH Permissions] I need permission to push to repo

What you are trying to do...
Try out a quick fix for some issues surfacing while working on tt-mlir before raising a proper tt-metal issue.
Who needs permissions...
Me, TT employee, Kristijan Mitrovic.
Optional screenshot etc...
kmitrovic@bgd-lab-09:/proj_sw/user_dev/kmitrovic/work/tt-metal$ git push --set-upstream origin kmitrovic/fix
remote: Permission to tenstorrent/tt-metal.git denied to kmitrovicTT.
fatal: unable to access 'https://github.com/tenstorrent/tt-metal.git/': The requested URL returned error: 403

please file a IT/TTDesk issue for access


Issues with network connection lost

Hi, I'm trying to setup carla-autoware integration environment.
but, There seem to be an issue with connection between carla and autoware.
In the video I upload, you can see that network connection lost when I launch autoware.
also there was an issue with ROS when I first launched autoware universe. (but i don't have any log about the error).
The weird thing is that there's no problem in another PC although I installed autoware in the same way.
Thanks for any help.
environment:
CPU : i7 10700F
GPU : RTX 3070 Ti
RAM : 32GB
OS : Ubuntu 20.04 LTS
ROS version : Galactic
Python version : 3.8.10
video
log

Sorry, never seen such an error.
try to check if autoware.universe work without the bridge first. try to planning simulator (first tutorial for autoware).

Thanks for a comment. It was a matter of hub setting,


Removed oracle.cert

Removed oracle-cert.cer as requested in #250

Thanks. Tested with windows_2016.json template and guest additions could be installed.


Patch CVE-2023-46316 for traceroute

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[ ] Ready to merge

Summary

Bump package version to 2.1.3 to fix CVE-2023-46316
Change Log

Bump version to 2.1.3
Lint spec
Update cgmanifest entry for the package

Does this affect the toolchain?
NO
Associated issues

#xxxx

Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-2023-46316

Test Methodology

Pipeline build id: xxxx

PR check build failed for unrelated reason (missing CredScan exception we've just added in #6697). Package builds and tests look good, overriding the check and merging.

Auto cherry-pick results:

main :white_check_mark: -> https://github.com/microsoft/CBL-Mariner/pull/6701

Auto cherry-pick pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=449119&view=results


Zappa Certify: BadRequest -Unable to associate certificate with CloudFront

Zappa Certify BadRequest Errors:  Unable to associate certificate with CloudFront
Context
Recently transferred a domain from GoDaddy to AWS. I have generated a certificate and put this in the zappa settings json file.
Python 2.7
Expected Behavior
Should certify the domain
Actual Behavior
Certifying domain minnidesign.com..
Updating domain name!
Oh no! An error occurred! :(

==============

Traceback (most recent call last):
  File "/home/JamesPeters/FlowersDiana/venv/local/lib/python2.7/site-packages/zappa/cli.py", line 2489, in handle
    sys.exit(cli.handle())
  File "/home/JamesPeters/FlowersDiana/venv/local/lib/python2.7/site-packages/zappa/cli.py", line 473, in handle
    self.dispatch_command(self.command, stage)
  File "/home/JamesPeters/FlowersDiana/venv/local/lib/python2.7/site-packages/zappa/cli.py", line 577, in dispatch_command
    manual=self.vargs['manual']
  File "/home/JamesPeters/FlowersDiana/venv/local/lib/python2.7/site-packages/zappa/cli.py", line 1741, in certify
    route53=self.stage_config.get('route53_enabled', True)
  File "/home/JamesPeters/FlowersDiana/venv/local/lib/python2.7/site-packages/zappa/core.py", line 1801, in update_domain_name
    "value" : certificate_arn}
  File "/home/JamesPeters/FlowersDiana/venv/local/lib/python2.7/site-packages/botocore/client.py", line 253, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/home/JamesPeters/FlowersDiana/venv/local/lib/python2.7/site-packages/botocore/client.py", line 557, in _make_api_call
    raise error_class(parsed_response, operation_name)
BadRequestException: An error occurred (BadRequestException) when calling the UpdateDomainName operation: Unable to associate certificate arn:aws:acm:us-east-1:_________:certificate/57cd____-__________________ with CloudFront. This error may prevent the domain name minnidesign.com from being used in API Gateway for up to 40 minutes. Please ensure the certificate domain name matches the requested domain name, and that this user has permission to call cloudfront:UpdateDistribution on '*' resources.

Steps to Reproduce

zappa certify

Your Environment
argcomplete==1.8.2 asn1crypto==0.22.0 awscli==1.11.123 base58==0.2.4 boto3==1.4.4 botocore==1.5.40 certifi==2017.4.17 cffi==1.10.0 chardet==3.0.4 click==6.7 colorama==0.3.7 cryptography==2.0 docutils==0.13.1 durationpy==0.4 enum34==1.1.6 Flask==0.12.2 future==0.16.0 futures==3.1.1 hjson==2.0.7 idna==2.5 ipaddress==1.0.18 itsdangerous==0.24 Jinja2==2.9.6 jmespath==0.9.3 kappa==0.6.0 lambda-packages==0.16.1 MarkupSafe==1.0 passlib==1.7.1 placebo==0.8.1 pyasn1==0.2.3 pycparser==2.18 pynamodb==3.1.0 pyOpenSSL==17.2.0 python-dateutil==2.6.1 python-slugify==1.2.4 PyYAML==3.12 requests==2.18.1 rsa==3.4.2 s3transfer==0.1.10 six==1.10.0 toml==0.9.2 tqdm==4.14.0 troposphere==1.9.4 Unidecode==0.4.21 urllib3==1.21.1 Werkzeug==0.12 wsgi-request-logger==0.4.6 zappa==0.43.1
{     "staging": {         "app_function": "__init__.app",         "aws_region": "ap-southeast-2",         "profile_name": "default",         "s3_bucket": "zappa-g8dee1e1c"         "domain": "minnidesign.com",         "certificate_arn": "arn:aws:acm:us-east-1:_________:certificate/57cd____-__________________"     } }

Is it possible that arn:aws:acm:us-east-1:_________:certificate/57cd____-__________________ isn't actually a certificate for minnidesign.com?

I am experiencing similar problem. @JimiPedros what's the status of your certificate, isn't it in "pending validation" perha[s?

@pavel64-sutyrin Did you find out what was the issue? I'm experiencing the same thing, I hope I don't need to move everything to us-east-1

The requirement that the certificate is in us-east-1 is a cloudfront one, but other than that you can have everything else somewhere else.

Just to complement above previous discussions @danielfranca since I already faced this issue:
As jneves said AWS CloudFront requires ACM certificates to be in N.Virginia (us-east-1) in order to be used by it. Now you only are required to use CloudFront for you API endpoint only if using API Gateway in 'EDGE-optimized' mode. 'REGIONAL' type APIs do not make use of CloudFront and therefore can make use of a certificate created in the same region.

So I just tried using the REGIONAL configuration / type of my zappa deployed API and then tried making the certification process outlined in the Zappa documentation (where it is stated that the certificate should be in us-east-1) and as expected failed.
However you are able to use a regional (same region that is) certificate with a REGIONAL API and this capability is offered by the similar to Zappa Serverless Framework (a plugin of the framework to be precise). I suppose this is a matter of implementation? A feature not yet implemented for Zappa?

@aralmpa so, as it is not implemented by Zappa, am I required to have everything on us-east-1?
I tried the same approach, setting the endpoint to regional, creating the certificate in the same region... and it failed

@danielfranca If I understood jneves's answer correctly, for EDGE-optimized types of API, you only need the certificates to be in N. Virginia - everything else can be wherever you want.

I thinking I got in a certificate hell, if there's such thing
I have attempted to create certification using zappa, but kept getting the message
botocore.errorfactory.BadRequestException: An error occurred (BadRequestException) when calling the CreateDomainName operation: Unable to associate certificate arn:aws:acm:us-east-1:111111:certificate/xxxxxxxxxxxx with CloudFront. This error may prevent the domain name xxxx.com from being used in API Gateway for up to 40 minutes. Please ensure the certificate domain name matches the requested domain name, and that this user has permission to call cloudfront:UpdateDistribution on '*' resources.
I cheked to see if the zappa role was missing the cloudfront:UpdateDistribution permission, and it was... so I thought "maybe that is it"
So, I added the cloudfront:UpdateDistribution to the zappa permissions... simulated the command through the simulator... working fine
but still getting the same message
so, I tried manually attach the certifiate with the API Gateway, set the route53... blabla... started getting a forbidden message on the endpoint through the domain name
tried to create manually a cloudfront distribution, with the certificate on it... still not working
I said, f***** this shit, let me move everyting to us-east-1 and start over
Then I deleted the domain from the CF distribution, undeployed everything, changed the S3 bucket and region to us-east-1 and re-deployed it to us-east-1, which works fine and the project is accessible now from the API GW url
Now back to the certificate
Tried to delete the certificate, and it doesn't let me to do it, stating that it is associated to a CF distribution... that was deleted already.
I thought that I probably just had to wait a bit... and here I am 3 hours later, getting the same error every time I try to delete the certificate
I also tried to certifiy via zappa with this same old certificate, and got the same error, again
when calling the CreateDomainName operation: Unable to associate certificate arn:aws:acm:us-east-1:11111:certificate/xxxxxx with CloudFront. This error may prevent the domain name blablabla.com
I also have tried adding extra_permissions on Zappa settings file:
"extra_permissions": [{
"Effect": "Allow",
"Action": ["cloudfront:UpdateDistribution"],
"Resource": "*"
}],
No success
I decided to go for another subdomain, so I created the certificate for it, updated the ARN and domain on the zappa settings
And again getting the same error, so I guess my error is somewhere else, not related to the region/domain
Not idea where else to look
I'll try it again Tomorrow

Sorry to hear that you are having so much hard time @danielfranca  - I just tried deploying an example with domain certification support through Zappa and it worked smoothlessly.
So I followed these steps:

zappa deploy dev (with regular zappa_settings.json - nothing needed for now)
Go to AWS ACM (N. Virginia) create the certificate and make sure it is issued normally
add in zappa_settings.json the following
[a) certficate_arn: arn from step 2 b) domain: example.com c) route53_enabled: true (assuming you have AWS as your domain's DNS)]
zappa certify dev

A regular message appears after this like:
Certifying domain example.com.. Created a new domain name with supplied certificate. Please note that it can take up to 40 minutes for this domain to be created and propagated through AWS, but it requires no further work on your part. Certificate updated!
Then everything seems to be working right - I am able to access my app through the domain.
Note that my deployment stack is in Ireland whilst my certificate in N. Virginia.
Note No2: I used admin rights for all this so it might be an indication that permissions might be at fault in your case - I ll try again with required permissions only.
Maybe there is something else in your stack? Did you try a different flow from the above-described?
A third Note: the Route53 A record was not deleted when I undeployed the stack - not sure if this should be also be part of the clean up process

damn, I have changed my credentials to an Admin one, and it worked!
So, it was permission related, but not the UpdateDistribtution one, I guess

Extra permissions is for the execution role, not the one deploying. I think that may have confused you.On 11 Mar 2020 10:10, Daniel França<EMAIL_ADDRESS>wrote:damn, I have changed my credentials to an Admin one, and it worked!
So, it was permission related, but not the UpdateDistribtution one, I guess
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

Yes it make sense that this confusion happened. The user (or in some other cases  the role) that is doing the certify needs to have the UpdateDistribution permission (at least I assume others as well) and the permissions of this user do no relate at all with the extra permissions of the execution role that refer to the rights of the executing function created by Zappa.
It seems that the error that danielfranca faced is identical with the original reported in the issue so I would say if @danielfranca can confirm that the previous user he was using did not had the appropriate rights (especially the UpdateDistribution) we can pretty much safely say that we have found the cause of this issue. Zappa certify seems to be working fine.


Sharing Report

I have a customer who has their own PowerBI Premium license.  I am sharing a report with one person at that organization who then wants to share report with others at that organization.  They share the link which was given to them so anyone in there organization with link can click and request access to report.  However, the user gets message, report is not available.  They never get the option to request access to report.  How do I get around this issue without having to know all 10 thousand employees who need to see this report created by my company.

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

ID: eee97d20-cca2-c705-0429-6debab9f9a32
Version Independent ID: 40334cca-f3c1-e8a8-7df2-e53e78ecfb40
Content: Request or grant access to dashboards or reports - Power BI
Content Source: powerbi-docs/collaborate-share/service-request-access.md
Service: powerbi
Sub-service: powerbi-service
GitHub Login: @maggiesMSFT
Microsoft Alias: maggies

Hi, @rwatty -- I can check and get back to you. In the meantime, I recommend asking in the Community, https://community.powerbi.com/.

Thanks for your comment, @rwatty . This looks like a support request or product question rather than documentation feedback. You might find a solution in the Power BI Community, at https://community.powerbi.com. If not, you can get support by going to https://support.powerbi.com.


Acurracy is pretty low

face bounding detections are inaccurate and cannot able to extract features from some images, and why the models are downloading everytime
try to fix this

Hi, it's not the best face detection implemented here. It can happen that it does not detect a face. The models should only download ones. The code is checking the hash of the model in case it is changed and then downloads again. Something is happening with your downloaded model if the models are downloaded again everytime.
I just updated to Python 3.9. Maybe check again.


Document how to use deployer generate dedicated-cluster in  the creation proces of new clusters

Context
The template configuration files in config/cluster/templates, the:
├── aws
├── common
│   ├── support.secret.values.yaml
│   └── support.values.yaml
└── gcp
    └── cluster.yaml

Can  now be used through the deployer to auto-generate specific files for new clusters on AWS and for new clusters and an initial hub on GCP.
Proposal

[ ] Document how these templates, together with the deployer generate dedicated-cluster command can be used to make the process of adding a new cluster easier.
[ ] Update or remove existing documentation like https://infrastructure.2i2c.org/hub-deployment-guide/deploy-support/configure-support/#create-a-support-values-yaml-file-in-your-chosen-cluster-folder as this is now replaced by the command completely.

Ref: https://github.com/2i2c-org/infrastructure/issues/1917

Useful feedback from @pnasrat  about this one:

We need to document it

Originally posted by @pnasrat in https://2i2c.slack.com/archives/C01GLCC1VCN/p1677843574698329?thread_ts=1677772541.271159&cid=C01GLCC1VCN
"I think in general having templated config and tooling makes sense to reduce operational work, I had to comment out the terraform generation as I had already done that
Features that would have been useful - skipping a step (eg provisioning for terraform/eksctl), a flag allowing overwriting a cluster.yaml,
This means integration with new cloud providers might ideally look like doing once manually with a test providers, write up manual steps, and writing deployer code necessary to do - a  test create/destroy with deployer and create the actual community cluster"

I updated the top comment to only cover the documentation part of the generator command as the command has been already extended to account for more providers (GCP and AWS currently). Also, I opened https://github.com/2i2c-org/infrastructure/issues/3294 as a follow-up to the comment above

Ask @sgibson91 if she can pair with @GeorgianaElena on this one.

Document how these templates, together with the deployer generate dedicated-cluster command can be used to make the process of adding a new cluster easier.

This was actually solved by #3878 that standardized all three providers in the same document -> https://infrastructure.2i2c.org/hub-deployment-guide/new-cluster/new-cluster/

Update or remove existing documentation like https://infrastructure.2i2c.org/hub-deployment-guide/deploy-support/configure-support/#create-a-support-values-yaml-file-in-your-chosen-cluster-folder as this is now replaced by the command completely.

This is the bit missing ⬆  from considering this task done.


Bug: wan6 forwards not working without wan firewall zone

wan6 forwards are not working without wan firewall zone, which essentially leaves wan6 useless and IPv6 as non-existent in openwrt, any fix?

IPv6 port forwards are unsupported by the underlying firewall framework.


pl.diffmap show and save issue

I noticed that pl.diffmap interacts differently with the show and save options than most of the other plotting functions. Namely, if both show and settings.autoshow are true, pl.diffmap saves but does not show. Most of the other functions will both save and show.
I looked in the code a bit and it looks like this is because other plotting functions use utils.savefig_or_show versus pl.diffmap has some custom plotting logic (I assume because pl.diffmap allows multiple plots to be generated by passing a list to components).  Changing:
if not settings.autosave and show: pl.show()

to just:
if show: pl.show()

should make pl.diffmap more consistent with the other plotting functions.

Thank you, this obviously makes sense. I'll first merge another update on plotting functions and then get back to this.

Fixed it: https://github.com/theislab/scanpy/commit/22511ee048f0277f61f40554a4bc6f76aaf4bc1c
Thanks again! :smile:


Clean up recently opened items

Issue Type: Feature Request
There's a command in VS Code to clear recently opened items, but I wish there was a way to clean it. I.e. remove references to files and folders/projects that no longer exists, but keep the rest.
It's for example annoying to still see folders I opened several weeks ago, that no longer exists on my disk. I think VS Code should clean this up automatically, but if not, there would at least be great with command I could run to do it.
VS Code version: Code 1.37.0 (036a6b1d3ac84e5ca96a17a44e63a87971f8fcc8, 2019-08-08T02:33:50.993Z)
OS version: Windows_NT x64 10.0.17134

Hit ctrl + shift +p
Type Remove from history
Hit enter
clean it up

@pramit-marattha Um...

That only seem to cover files
Doing that for every file and project that no longer exists would be very finicky and annoying
This was not a question...

Possible duplicate of #49056


Notebook for Creating Cutouts with Astrocut

This notebook checklist has been made available to us by the the Notebooks For All team.
Its purpose is to serve as a guide for both the notebook author and the technical reviewer highlighting critical aspects to consider when striving to develop an accessible and effective notebook.
The First Cell

[x] The title of the notebook in a first-level heading (eg. <h1> or # in markdown).
[x] A brief description of the notebook.
[x] A table of contents in an ordered list (1., 2., etc. in Markdown).
[x] The author(s) and affiliation(s) (if relevant).
[ ] The date first published.
[x] The date last edited (if relevant).
[x] A link to the notebook's source(s) (if relevant).

The Rest of the Cells

[x] There is only one H1 (# in Markdown) used in the notebook.
[x] The notebook uses other heading tags in order (meaning it does not skip numbers).

Text

[x] All link text is descriptive. It tells users where they will be taken if they open the link.
[x] All acronyms are defined at least the first time they are used.
[x] Field-specific/specialized terms are used when needed, but not excessively.

Code

[x] Code sections are introduced and explained before they appear in the notebook. This can be fulfilled with a heading in a prior Markdown cell, a sentence preceding it, or a code comment in the code section.
[x] Code has explanatory comments (if relevant). This is most important for long sections of code.
[x] If the author has control over the syntax highlighting theme in the notebook, that theme has enough color contrast to be legible.
[x] Code and code explanations focus on one task at a time. Unless comparison is the point of the notebook, only one method for completing the task is described at a time.

Images

[x] All images (jpg, png, svgs) have an image description. This could be

[x] Alt text (an alt property)
[x] Empty alt text for decorative images/images meant to be skipped (an alt attribute with no value)
[x] Captions
[x] If no other options will work, the image is decribed in surrounding paragraphs.

[x] Any text present in images exists in a text form outside of the image (this can be alt text, captions, or surrounding text.)

Visualizations

[x] All visualizations have an image description. Review the previous section, Images, for more information on how to add it.

[x] Visualization descriptions include

[x] The type of visualization (like bar chart, scatter plot, etc.)
[x] Title
[x] Axis labels and range
[x] Key or legend
[x] An explanation of the visualization's significance to the notebook (like the trend, an outlier in the data, what the author learned from it, etc.)

[x] All visualizations and their parts have enough color contrast (color contrast checker) to be legible. Remember that transparent colors have lower contrast than their opaque versions.

[ ] All visualizations convey information with more visual cues than color coding. Use text labels, patterns, or icons alongside color to achieve this.

[ ] All visualizations have an additional way for notebook readers to access the information. Linking to the original data, including a table of the data in the same notebook, or sonifying the plot are all options.

The Notebook Validation check is failing with this message: jupyter_client.kernelspec.NoSuchKernel: No such kernel named roman-cal.
I developed this notebook in the Roman Science Platform, which could be the source of the error. I'm not sure how to resolve it.

@snbianco: you don't need to resolve that error. The CI doesn't test from inside the platform, so it will always give that error.

A general comment to consider looking into the warnings package to see if we can suppress the astropy warnings. We do want to make sure they are not indicative of bigger issues, though, and to address them if needed, but for the notebook should probably not have so many extra warning messages.

Also, it would be good to have both the fits and asdf cutouts be the same area to demonstrate that nothing is different between the two.

Just pushed changes to suppress the warnings and change the parameters for the ASDF cutout to match the FITS cutout.

I just realized this hasn't been merged yet but is part of deliveries for Roman B15.
Is there any reason why we shouldn't merge at this point?

@cmurray-astro let us know that the Roman mission office wants to wait until after the next round of tests happening in early October. We will have to check out the notebook on ops RSP for the demos.

I'm not sure if we can wait til October- this notebook is a deliverable for B15 which is due September. I'll include Claire in the email chain to get some clarity.

There is nothing stopping us from, e.g., going into RSP and checking out the notebook in the user's local environment for running the demo. This conversation was about when the notebook would appear automatically for ALL users in RSP.  That shouldn't impact the ability to create test instructions, or run the demo, I would think.

Since it's demo-only, we could start off the demo with the notebook already available in the user's RSP working directory.

@tddesjardins likely has better insights than Claire about RMO's motivation for not merging. As I understand it, Sam is correct; since the astrocut notebook wasn't a part of the original RSP plan, they're hesitant to add it during the testing phase.


History+namespace patch

OK, I had to create this separate PR (which includes the same additions from the history-patch). This allows for multiple instances of Imagelightbox. What is missing, is the required CSS. I think that's it.

"resetting" (rethinking)


Configure Azure Pipelines

This pipeline configuration builds the application and produces a build for the Release configuration.

mistake


Typescript error: no exported member 'MomentModule'

Hi
I have installed angular2-moment and i seem to be getting an error:
angular2-moment has no exported member 'MomentModule' ?
Thanks

When i look at the version i get from npm and i open index.ts it does not have and export for "module" as per the source code here - is the latest version published to npm?

Ok so i resolved the initial issue by installing the latest version on npm using @1.0.0-beta.1
However now i have the issue of index.js does not export DateFormatPipe?

Hi, simply import it like this:
import { MomentModule } from 'angular2-moment/module';

Also see #68 if you are using AoT


Plugin Ideas / Enhancements

This will be an on-going list

Remind me

Would require ability to have the bot schedule an event to run at some point in the future

~Imager using google image search~
RSS feed
Twitch stream announcer

User blacklist


Definition for Governed Role Policies: Non-registered Ledger Reader is not a definition

Hi, I just noticed in the Governance framework that the definition "Governed Role Policies: Non-registered Ledger Reader" is not really a definition like the others:
"The CANdy Ledger is publicly available and can be queried and read by any....."
As you can see the others all start by the term to define and the verb to be:
The CANdy Governing Board, referred to as the 'Board' in this framework, is
A Board Member is
A Trustee is
Steward is an Indy role
An Endorser is
A Registered Entity is

@marcodrompre - since we have transitioned the CANDy Governance Framework to the ICCS repo and made changes there, is this issue still relevant?


Remove & inline markdown-toolbar-element dependency

In the MarkdownEditor, we are using markdown-toolbar-element to power basic formatting tools (bold, italics, etc). However, this is a custom element and not a React component, so this strategy comes with some complications.
The way we are using the element is by rendering it with display: none and then calling .click() on the underlying elements. This is really hacky but it's necessary because the markdown-toolbar-element package doesn't expose the underlying logic at all.
In addition to the hackiness, the dependency is problematic because it performs side effects (registering custom elements) on import, so we have to conditionally require the dependency in a useEffect callback to avoid calling browser APIs during server-side rendering. This mix of require and import confuses transpilers and occasionally breaks things in unexpected and hard-to-debug ways (for example, see this Slack thread).
To get around this issue, I tried using require() inside a useEffect instead (pull request). This fails due to a known bug in the JavaScript engine that causes a segmentation fault.

So to resolve both the hackiness of this approach and the issues with SSR/unit tests, I've decided to remove the dependency altogether and inline the logic instead. The downside to this is that we are duplicating the logic in that dependency when the whole point of the dependency was to help remove duplication, but there are many upsides.
While inlining this logic, I've tried to make as few changes as possible in order to reduce risk. This means that I left some refactoring opportunities on the table for future work - I've only made the following changes:

Removed all code relating to custom elements, turning the entire thing into a hook instead
Removed the insertText function in favor of using our much more robust syntheticallyChangeInput strategy. This required changing the logic inside formatting functions a bit to avoid directly passing around / mutating the HTMLTextareaElement instance.
Replaced the logic inside expandSelectionToLine with the getSelectedLineRange util, since this was an easy and simple win for removing duplication
Renamed some functions, arguments, and types

An even better solution would be to extract all the logic that's shared between the PVC and PRC Markdown editors into a new common behavior dependency. This could include formatting, list editing, file handling, etc... But this is not something that I have the capacity for at the moment, and I don't want to delay this fix as it's actively blocking work on downstream teams.
Screenshots
There are no visual changes.
Merge checklist

[ ] Added/updated tests
[ ] Added/updated documentation
[ ] Tested in Chrome
[ ] Tested in Firefox
[ ] Tested in Safari
[ ] Tested in Edge

Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.

Work looks great, but there appears to be some issues with act() in the tests that are failing with the changes.

I think my definition for taskListStyle was wrong and that's causing the failures. The act warnings aren't new (if I remember right).

we should be leaning into web components more within Primer React as we do with Primer View Components

I have to disagree with you there. I think the web components pattern works well with PVC, but the same cannot be said for React. While web components technically can be used within React, they come with so many downsides that it's just not worth it.
Specifically looking at this markdown-toolbar-element, here are a few of the problems I've encountered:

The buttons inside the toolbar don't use the PRC Button component. In fact they can't, because web components can't use React components inside. This means that we can't make the toolbar buttons look consistent with the rest of React buttons. They will never be able to access the React theme or reuse the base components.
The toolbar manages its own focus zone. But PRC already has tools for managing focus zones (like the useFocusZone hook). It's impossible to override the built-in focus functionality so we cannot make useFocusZone work with this toolbar.
The toolbar is incompatible with SSR because it auto-registers itself on import. We could fix this by providing a register function that gets called in the client, but it will never be fully compatible with SSR because web components are rendered client-side.
If we want to programmatically perform formatting actions on the editor in React code, the only way to do so is by simulating a click event on the corresponding toolbar button. This is ugly and difficult to maintain. An example of this is binding keyboard shortcuts to the input.
None of the internal logic is exposed through the element, so we can't reuse any of it.
The element doesn't public any TypeScript types, so we had to define them in PRC.

While some of these problems are fixable, most are not because they stem from a fundamental incompatibility between web components and React components. They just don't work well together because they align with two very different styles of web architecture.
I think sharing the logic code is great and we should definitely do that as much as possible. But React components should be allowed to handle their own rendering the way they want, using React patterns and React components internally. The logic code should be purely logic code - it shouldn't come with rendered baggage.
As we as a company start to move in a React-first direction, it just doesn't make sense to be trying to make web components fit here. We should try to make it as easy as possible to share logic between our different component systems, and web components don't do that.

I also think as behaviors get more complex they’ll start to take the shape of web components more and more

I don't think this is necessarily the case. As behaviors get more complex, tying them into rendered components feels like an antipattern. Having a simple behavior tied to a component is one thing, but complex behaviors should be as extensible and customizeable as possible.

In my ideal world, the PVC and PRC implementations of the Markdown editor would share no rendered components at all, but would share as much of the underlying logic as they possibly can (ie, formatting tools, file handling, suggestions filtering, etc). This way the React implementation can be rendered purely using React, gaining all of the advantages that React provides without any hacky workarounds to use the shared logic.

The buttons […] means that we can't make the toolbar buttons look consistent with the rest of React buttons. They will never be able to access the React theme or reuse the base components.

Yeah there’s work to do here to get React to utilise native CSS which is being worked on. The hope is certainly that these will end up using the same themes and same base components.

The toolbar manages its own focus zone. But PRC already has tools for managing focus zones (like the useFocusZone hook). It's impossible to override the built-in focus functionality so we cannot make useFocusZone work with this toolbar.

The useFocusZone hook is specific to React but should move to be a shared primitive which both will use. There’s work happening in web standards to have a new element represent a focus group and we should align our work to this.

The toolbar is incompatible with SSR because it auto-registers itself on import. We could fix this by providing a register function that gets called in the client, but it will never be fully compatible with SSR because web components are rendered client-side.

The Markdown toolbar component doesn’t do any client side rendering IIRC, the tags can be rendered by any server. The client side bundle needs specific client side code just like react does with react-dom. This should be reasonably straightforward to deliver for Primer as we do on GitHub. If there are issues around delivering this we should get them fixed; this is all standard JavaScript so everything should be interoperable and if it fails to be we should remediate that.

If we want to programmatically perform formatting actions on the editor in React code, the only way to do so is by simulating a click event on the corresponding toolbar button. This is ugly and difficult to maintain. An example of this is binding keyboard shortcuts to the input.

There’s lots of ways to solve this! We should explore them!
Just like other behaviours, shortcut binding should be handled consistently between platforms we have.

None of the internal logic is exposed through the element, so we can't reuse any of it.

Right. Let’s fix that to make sure it is reusable. We own both repositories so we can get this done in a reasonable time frame.

The element doesn't public any TypeScript types, so we had to define them in PRC.

The components are written in typescript and have declared types: https://github.com/github/markdown-toolbar-element/blob/e48fbc5b8aec1f0451325b616d45f1324cdbce36/src/index.ts#L2. Perhaps there’s an error in the publish or perhaps typescript is misconfigured? We should look into this because this is definitely imminently solvable.

I think sharing the logic code is great and we should definitely do that as much as possible. But React components should be allowed to handle their own rendering the way they want, using React patterns and React components internally. The logic code should be purely logic code - it shouldn't come with rendered baggage.

It’s great that we’re in agreement here! Our web components including markdown toolbar render very little and are very nicely composable. Web components are just standard JavaScript so should work fine with any framework.

As we as a company start to move in a React-first direction, it just doesn't make sense to be trying to make web components fit here. We should try to make it as easy as possible to share logic between our different component systems, and web components don't do that.

We aren’t moving in a React-first direction and even if we were web components are still a great fit for sharing logic between different component systems which is exactly why we’re looking more into doing exactly that.

I don't think this is necessarily the case. As behaviors get more complex, tying them into rendered components feels like an antipattern. Having a simple behavior tied to a component is one thing, but complex behaviors should be as extensible and customizeable as possible.

We’re in agreement here! Components should be extensible and customisable. This is about how we deliver patterns and technology choices matter very little here.
Again I think any specific issues with the markdown toolbar element should be resolved, and we should work to ensure we can share as much as possible between our two platforms to ensure consistency. I think it’d benefit us greatly here to talk about just the specific issues with markdown toolbar element so we can resolve those and move forward productively!

Thanks @keithamus for your thoughts here and I appreciate your perspective. Just for posterity sake, this code approach was discussed more broadly in this Slack Convo with @mattcosta7 and @dgreif.
Disclaimer: The following is my POV and what I would want from the perspective of a React developer.
I agree with @iansan5653 stated points on this and he did an incredible job breaking down why he choose this solution. Web Components and React Components work together for simple tasks from my experience, but requiring them to work together and blocking this Pull Request seems like the wrong approach to me. My team has attempted to use some web components features in the past, but we found that having more control over the components in React were easier to use, customize and test than using the Web Component primitives. We have also removed all (or most) of the web components in our project. Offering extensibility in the React code for features we will be using feels like the right approach and the approach I believe most React developers will prefer. I think having to access imperative DOM APIs to interact with Web Component and needing refs to interact with the DOM nodes directly is not a great experience and not an experience that I would be happy using.
Blocking this PR will also continue requiring some repos to have a dependency on @primer/react and a @primer/react *canary release. The component exists in PRC now as a drafts component, but it breaks our tests (which is what this PR ultimately resolves).
I feel strongly that we should have reasonable expectations on what we require for developers to share their components upstream to PRC. The ask here, to me, seems like a high bar for @iansan5653 to assess and re-work (if we decide this is the best approach) as someone that is not a core contributor to the Primer React or Web Component repositories. Teams that are in need of this component requested this port from @iansan5653's team. Which he has graciously done with this work. I think to continue fostering teams to share their React components for other teams to enjoy, we need to find a balance of making the barrier to entry much easier.
I've personally not seen great experiences or examples of Web Components and React paradigms working well together and I believe that is 100% ok. I will argue that having shared React components that are accessible, easy to build and quickly shareable in this repository or others supersedes requiring them to work with both React and Web Component.

Mostly just adding some commentary to a few points in the comments above since I was tagged here

I don’t think we want to do this for several reasons. Chiefly being that we should be leaning into web components more within Primer React as we do with Primer View Components, because they offer us useful tools within the browser environment.

Conceptually, I agree with this, however the support for web components in react is just not really that good yet. Most of these shortcomings can be worked around, but not very idiomatically.  React 19+ should fix this, assuming React releases it on that release. React 17 is still the most commonly used version at github, with the same flaws as React 18 from these tests.
I guess the important question is - do we ship this knowing we unblock some use-cases now or hold off, keeping those trying to use these features blocked until the underlying issues are resolved?

Moving away from sharing dependencies will cause inconsistencies across the two design systems. You mention sharing logic in behaviours, I think that’s definitely the plan - but I also think as behaviours get more complex they’ll start to take the shape of web components more and more, so we’ll have to address it there too.

Agreed there, but also not sure it's worth blocking progress here for the time being, until someone can pick that work up?

The issues you mention around specifics of markdown toolbar sound imminently fixable. We should address those so we can continue to use this component.

I don't think, given the issues we can't yet address (theming, for one) that sounds like a path forward here - without the workarounds mentioned which don't seem worth it to me on the surface

Issues around compiler tool chains sound interesting. Could you detail the specific issues you’re having here? It sounds like something that needs to be addressed in our tool chain.

I think the majority of issues here lie in the fact that primer bundles a commonjs build that attempts to require its dependencies, some of which are esm only builds - leading to runtime errors that can't be rectified just in the toolchains.  Primer/react could modify its build system to bundle the dependencies it relies on or stop shipping any commonjs (preferable I think), but I'm not aware of what the deprecations plan would ideally look like there.
The other issues around calling window.customElement.define() in module scope (where window is not defined in non-browser environments) are more easily fixed by enforcing some kind of registration that isn't in a side effect, and/or ensures that typeof window !== undefined before attempting to access it here.  Generally, I'd suggest both together

Yeah there’s work to do here to get React to utilise native CSS which is being worked on. The hope is certainly that these will end up using the same themes and same base components.

While this does seem like a goal that's understood as necessary, I'm curious what the timeframe is for this.  Weeks to months sounds likelier than days to weeks (I don't believe there's ongoing work towards this yet, but maybe it is).

Web components are just standard JavaScript so should work fine with any framework

except the many cases where they don't work with react well out of the box, or where they require very non-idiomatic escape hatches to work with.  Maybe we need to implement a react friendly wrapper, and still hope to not run into the issues that need code that just isn't react friendly.

The element doesn't public any TypeScript types, so we had to define them in PRC.

It looks like it does define types, but it doesn't define JSX.Element types, so needs to have them manually written.  The library could define these (and probably should if usage in react is expected)
I think @Lukeghenco  sums up a lot of my thoughts here well with the sentiments of:

Offering extensibility in the React code for features we will be using feels like the right approach and the approach I believe most React developers will prefer. I think having to access imperative DOM APIs to interact with Web Component and needing refs to interact with the DOM nodes directly is not a great experience and not an experience that I would be happy using.

We should probably try to provide this level of support for web components used in react, however I think that will require a good deal of effort to do well, while providing an idiomatic way to interact with them (that's also typesafe)

I feel strongly that we should have reasonable expectations on what we require for developers to share their components upstream to PRC.

I think we might be at a good place to consider this a reasonable path, for now, even if we accept that we might need to re-work some of this later.  That seems to be what the 'drafts' in prc are for. quick iteration, learning and eventual refining

I've personally not seen great experiences or examples of Web Components and React paradigms working well together and I believe that is 100% ok.

It can happen, but agreed it is not the norm, and not something that just works.  This is a failing of react more than anything, but a reality we need to accept some for the time being.   We're also limited by our other react technical choices (theming for one) and until those underlying issues are handled, some latitude to work around them while maintaining productivity seems reasonable

Thanks @mattcosta7 for your thoughtful responses to both me and @keithamus concerns here.
My biggest concern here is this being a blocked PR for reasons I worry it shouldn't be blocked for. I think the solution is a good enough solution for now and I think it is very likely to assume this components internal workings will change a lot in the next weeks/months.
As for this comment:

This is a failing of react more than anything, but a reality we need to accept some for the time being.

I am glad that React is working to improve the interoperability experience with web components though, since they are here to stay as good or bad as that might be depending on your POV of them being standardized as a web standard. I think that React improving this is a win for everyone in web development though.

Can we please focus on the specific issues we're currently facing, so they can be remediated? Definitely don't want to block anyone but I cannot see what this is fundamentally solving.

@keithamus there are two fundamental issues here:
First is the immediate issue, that markdown-toolbar-element calls DOM APIs at the top level. This breaks any rendering outside the browser (ie, server side rendering) because the browser APIs will not be available yet. I see the following solutions - feel free to propose another if you can think of one:

:x: Wait to import the file until after the React component has mounted in the real browser environment, using a require() call inside a useEffect in the component. This is what PRC is doing right now and it is breaking builds because of the mix between require and import. This breaking is understandable considering the two shouldn't be mixed.
:x: Use the same strategy as (1) but use import() instead. This doesn't work because import() causes segmentation faults in the v8 runtime.
Move the import to the top-level (as your pull request does) and change the strategy for registering elements in the markdown-toolbar-element source. The only way I can see this working is if markdown-toolbar-element starts exporting some kind of a register() function that contains all the DOM API calls. Then we would call that register() function where we are calling require() today (in useEffect).
Remove the markdown-toolbar-element dependency as this PR does.

Only (3) and (4) are actually viable options here, so we are either going to need to merge this PR or make breaking upstream changes to the markdown-toolbar-element.

There is another less immediate issue at hand here, which is that the markdown-toolbar-element isn't really working for us in the first place. The way it's actually being used in the MarkdownEditor component is by rendering it as display:none and programmatically 'clicking' the buttons so that we can access the formatting functionality:
https://github.com/primer/react/blob/9eaa37e98b8cd12a0b953f190bcbff0f26a3dd22/src/drafts/MarkdownEditor/_FormattingTools.tsx#L26-L74
This is defeating the entire purpose of a web component, which is that it renders content to the DOM - it would be much cleaner to have a markdown-formatting behaviour library from which we could import all of these functions.
Why we are doing this is a bit more complicated to explain but it comes down to wanting to use React components in React components. We initially did try (for a long time) to render the toolbar as a toolbar but ran into a myriad of issues that prevented this from working, all of which stem from the fact that the toolbar and its buttons are too different from the corresponding React components. It's far easier to just render a set of IconButton components and manage their focus with useFocusZone than is is to make markdown-toolbar-element look and act like a React component.

So that's why I opened this PR. Option (4) not only avoids breaking changes upstream, it also cleans up this hacky code.

Thanks for outlining this @iansan5653. We're actively discussing this and we'll get back shortly.
I think solution 3 should be workable without making breaking changes to either codebase, as the code will run safely client side and server side can be stubbed out if we need to run server side.
The concerns we have with solution 4 is that it may introduce more technical debt with duplicate code which is why we're hesitant to merge.

I think solution 3 should be workable without making breaking changes to either codebase, as the code will run safely client side and server side can be stubbed out if we need to run server side.

I'm interested to see what this might look like as a non-breaking change. From my admittedly limited understanding of SSR, I'm not sure if this is as simple as "don't register unless the window object is defined" or if it's more like "wait to register until the window object is defined". First is definitely easy, second might be more challenging.

From an SSR perspective, adding a simple typeof window !== 'undefined' guard should be sufficient. However, that won't solve the fact that the markdown-toolbar-element currently executes with side-effects, and thus cannot be tree-shaken. This means bundles in dotcom that do not need toolbar element will carry it as extra weight that is not needed. We would need to add a register() function to allow tree shaking, which would be a breaking change on the web component package. I think tree shaking is a valid reason for a breaking change here, so maybe that's the right path forward?

I think the best approach may be as I described in #2353 - which is to have a client side bundle that can pull in these dependencies:

We may want to move all web component definitions to a central file; github/github could de-duplicate these imports as it already imports them via PVC or via direct imports.

Would the PRC consumer be responsible for the conditional loading?

To me that would be the most sensible idea. It’s highly likely that consumers of PRC are already building a client side bundle with client side only code such as polyfills. Also likely they aren’t bundling for server side as it’s not super compelling to do so.

Would the PRC consumer be responsible for the conditional loading?

To me that would be the most sensible idea. It’s highly likely that consumers of PRC are already building a client side bundle with client side only code such as polyfills. Also likely they aren’t bundling for server side as it’s not super compelling to do so.

I don't think it's a common approach to making consumers bundle separately for those environments, where possible not to, and might lead to some friction in doing so.
A separate import of like
import "@primer/react/custom-elements" could be added somewhere, and handle it's own type of loading, otherwise consumers will need to either accept a bundlesize hit for web components they don't care about, or need to know which custom-elements to import where.
It does sound like those provide a bit of a rough way to interact with, vs having the import in primer code directly, handling environments gracefully and making this an experience consumers don't need to consider
I'm also wonder whether there's potential namespacing issues (because web-component namespacing isn't a thing) and this isn't just consumed internally.  What do consumers who have a md-toolbar or whatever already on the page do?  How do we warn them they have something defined already that isn't expected here?

I've opened an issue in https://github.com/github/markdown-toolbar-element/issues/68 where we can discuss strategies for resolving this problem with the element itself.

Just wanted to follow-up on this PR after some of the discussions on Slack today to see if we're aligned on next steps 👀
It seems like there might be a chance that the underlying require() issue from 35.9.0 is addressed with the new bundling approach we have. If so, that should unblock the existing implementation while we figure out the best approach for this stuff.
In terms of next steps then, what do folks think of:

Investigate if the v35.11.0 RC addresses the initial require() issue
If so, no further action needed to unblock package updates
Either way, it seems like we need to investigate on the PRC side an alternative to import(). It seems like option 3 from https://github.com/primer/react/pull/2339#issuecomment-1252429578 was the next best path to try?


Warn when ordered is used with allow

An attempt at resolving #997, are there other scenarios we should explicitly warn about for ordered?

Can this be implemented on the MessageExpectation#ordered method (by checking if type == :stub) instead?  That would automatically cover any uses of ordered when added to a stub using the legacy syntax or via RSpec::Mocks.allow_message.

Possibly, there's a large amount of indirection going on in this lot it was hard to determine the best place, I might give that a go another day (its 2330 here and that's -2 from my normal timezone, lol flying)

Been a while but I finally refactored this @myronmarston, turns out your solution was much simplier

LGTM, merge when green (+ add a changlog entry).


chore(main): release 3.65.0

:robot: I have created a release beep boop
3.65.0 (2024-09-13)
Features

icons: Update Lucide to https://github.com/lucide-icons/lucide/releases/tag/0.441.0 (5d51b02)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v3.65.0
:sunflower:


feat: sync repos under staging folder to individual repos

Signed-off-by: Bird<EMAIL_ADDRESS>Pre-Checklist
Note: please complete ALL items in the following checklist.

[x] I have read through the CONTRIBUTING.md documentation.
[x] My code has the necessary comments and documentation (if needed).
[x] I have added relevant tests

Description
sync repos under staging folder to individual repos
Related Issues
close #1333
Anything else
@daniel-hutao
Please setup GH_PAT repo SECRET according to https://github.com/BetaHuhn/repo-file-sync-action/discussions/31#discussioncomment-674804
(Or we can use github app to generate tokens, ref: https://github.com/marketplace/actions/repo-file-sync-action#token)
New Behavior (screenshots if needed)

@aFlyBird0 remember to update .github/sync-staging-repo.yml after #1337 and #1338 merged.


Update http4s-circe, http4s-dsl, ... to 1.0.0-M38

Updates

org.http4s:http4s-circe
org.http4s:http4s-dsl
org.http4s:http4s-ember-client
org.http4s:http4s-ember-server

from 1.0.0-M37 to 1.0.0-M38.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.http4s" }
}]

labels: library-update, early-semver-pre-release, semver-spec-pre-release, commit-count:1

Superseded by #150.


[TS migration] Migrate 'IOUEditRequestReceipt' page to TypeScript

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/32000
PROPOSAL: https://github.com/Expensify/App/issues/32000#issuecomment-1911955763
Tests

Same as QA step

[x] Verify that no errors appear in the JS console

Offline tests

Same as QA step
QA Steps

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

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

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

iOS: mWeb Safari

Android: mWeb Chrome

iOS: Native

Android: Native

MacOS: Desktop

MacOS: Chrome / Safari

Hi @codinggeek2023 can you fix ts check, lint and do a PR author checklist?

@codinggeek2023 hi I will review it today, can you also fill the PR Author Checklist?

@codinggeek2023 there is still typescript check failing and also a lint

@codinggeek2023 MediaStream is a Web API where torch not exist https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/getCapabilities to fix that you can do 'torch' in capabilities

@codinggeek2023 Added some comments to help resolve issues

Also please read through TS_STYLE.md doc, especially the part about compose function (that it is deprecated in TS files). Thank you!

@codinggeek2023 Check how it was refactored here, this should be pretty helpful!

Did it help? @codinggeek2023

@codinggeek2023 Started reviewing today. A couple things.

You need to add test steps to verify that the affected components still work as expected.
Please fix merge conflicts.

@codinggeek2023 kind bump 🙂

@codinggeek2023 I've took a look at your problem and here are my suggestions that could help:

Inside withWritableReportOrNotFound.tsx update type MoneyRequestRouteName to include typeof SCREENS.MONEY_REQUEST.STEP_SCAN.

type MoneyRequestRouteName =
    | typeof SCREENS.MONEY_REQUEST.STEP_WAYPOINT
    | typeof SCREENS.MONEY_REQUEST.STEP_DESCRIPTION
    | typeof SCREENS.MONEY_REQUEST.STEP_TAX_RATE
    | typeof SCREENS.MONEY_REQUEST.STEP_TAX_AMOUNT
    | typeof SCREENS.MONEY_REQUEST.STEP_SCAN;

Inside  IOURequestStepScan index.native.tsx remove report from withOnyx hoc, it's not necessary because component get report from withWritableReportOrNotFound HOC.

Update IOURequestStepScan types.ts file - remove report field from the type.

Inside IOURequestStepScan index.tsx and index.native.tsx update IOURequestStepScanProps, you need to pass screen route to WithWritableReportOrNotFoundProps type.

type IOURequestStepScanProps = IOURequestStepOnyxProps & WithWritableReportOrNotFoundProps<typeof SCREENS.MONEY_REQUEST.STEP_SCAN>;

All of the above suggestions should help with typing of IOURequestStepScan + withWritableReportOrNotFound HOC. Make sure to test the functionality after updates.
Besides that I see there are some minor TS/lint issues which should be easy to resolve, but let me know if you have any problems with it.

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

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

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/4160319/581fd4b4-f252-4064-be4e-86e4b6ac54e0

MacOS: Desktop

@codinggeek2023 Typecheck is failing, please have a look

Good idea! There are conflicts now. Can you please resolve it. I can generate a build then

Build is ready, what are next steps here @codinggeek2023 @MonilBhavsar ? Need any help?

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/MonilBhavsar in version: 1.4.63-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 1.4.63-21 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


[docs] Website: Introduce Blogging Platform

\cc @DevExpress/testcafe-docs
A part of DevExpress/testcafe-gh-page-assets#19

Let's wait till DevExpress/testcafe-gh-page-assets#19 is merged - tests should pass then.

@testcafe-build-bot \retest

oh, link - not line

The post is a draft BTW - just to make it all build okay.


Avoid duplicate assessment section recorded events

If the state is the same, we could avoid recording a assessment section recorded event since it would say the same thing.
Trello Card

I'm raising this PR as a potential solution to duplicate events, however I don't think it's necessarily a good idea, would be interested in thoughts:

The timeline is no longer accurate.
We lose a record of when notes are changed (i.e. the form is resubmitted) but the state is the same.

I did think about doing something more intelligent where in the case of the state staying the same, we find the existing timeline event and update the time on it, however again this feels like we're messing with an audit log.


PEAR-2102: Fix for Mutation Frequency - "Mutated Gene" facet card button does not extend to correct length

Description
Checklist

[N/A] Added proper unit tests
[N/A] Left proper TODO messages for any remaining tasks
[N/A] Scanned for web accessibility with aXe, and mitigated or documented
flagged issues

Screenshots/Screen Recordings (if Appropriate)

perfect! best PR ever! can't wait for it to be available to the world! 👍


BUG: Remove slangs on website and replace it with slang

Description
The word 'slangs' looks strange in plural, so 'slang' as singular should be used. Replace all occurrences of 'slangs' on the website to 'slang'.
Check in the hero.jsx component in the src folder for the related page.
Screenshots

will you assign this to me? Ill take care of it.


Multiple keywords are added

I don't know why but when I add keywords from Google Search console discover they can sometime get added multiple times (they are also displayed multiple times on the discover time and I can't just select one, it's all or nothing)
example:

For me it was showing an error when adding existing keywords, easy in case its just a keyword or two. Too much when its a long list of 100+ keywords and ending up with error that is bigger than the window itself.

+1


Storing mapping from names to group indices into Regex

The main goal I wanted to achieve is to get rid of creation HashMap that storing group name to group index mapping every time when creating a new instance of Captures.
Now this map is stored directly into Regex. For Regex::Dynamic it is stored as HashMap and for Regex::Native it is stored as sorted vector Vec<(&'static str, usize)>, where the first element of the tuple is the group name, and the second element is group index.
This change doesn't add backward incompatible changes, but changes lifetime parameters for some structs, like Captures<'r, 't>, where 'r refers to Regex instance.
Also, this PR is lacking documentation updates and I'm not sure about the correctness of lifetime parameters (I think we can reduce counts for some structs), so please consider this request more like a draft.
@BurntSushi what you think?

@defuz I like it. It kind of makes me wonder why I didn't do it this way initially---recreating a hashmap on each match seems a little crazy! My best guess is that I thought it'd be nice to not create the hash map if we didn't need it (e.g., never ask for captures or don't have any named groups), but compatively speaking, one (usually small) hashmap seems pretty nominal to me. Regardless, we could lazily build it once using interior mutability, but I don't think that's necessary.
With all that said, this is undoubtedly breaking and backwards incompatible. You're pretty much guaranteed this when you add a lifetime parameter to a public type, because any downstream use of that type now requires specifying the additional lifetime. (Unless, of course, lifetime elision kicks in.) In this case, I doubt there would be many breaking changes since one rarely utters the types you've changed explicitly, and instead they're usually inferred.
What do you think of keeping this PR open and putting it on the 1.0 milestone? There is already at least one other breaking change cooking (#151), so I like the idea of batching them all up to reduce churn in the ecosystem.
In any case, thank you!

I think one thing this makes impossible is keeping captures around after the regex has gone out of scope, but that seems a little weird to me.

@BurntSushi

You're pretty much guaranteed this when you add a lifetime parameter to a public type because any downstream use of that type now requires specifying the additional lifetime.

You're right, I was too optimistic about backward compatibility. :)

What do you think of keeping this PR open and putting it on the 1.0 milestone?

This sounds reasonable to me.

I think one thing this makes impossible is keeping captures around after the regex has gone out of scope, but that seems a little weird to me.

Yes, this is the price for the fact that we do not create HashMap every time. Although, we can simply clone it every time when we create Captures.
Moreover, I think we can use Vec<(&str, usize)> instead of HashMap<String, usize> for Regex::Dynamic, so that we can get rid of dynamic dispatch into SubCapturesNamed and Captures::name. And binary search is much faster than a hashmap for small collections.

@defuz Sounds good to me. Moving the HashMap into Regex seems like an obvious win, but I'd strongly recommend setting up some micro-benchmarks before going further than that. :-)
N.B. This branch will need to be rebased before 1.0 because of changes I'm making. I'll ping you then or I can do it! Thanks!

I think this improvement can be added backwards compatibly with Rc instead of borrowing.

@pczarn Probably we will need Arc, since Regex and Captures are Send/Sync.
@BurntSushi I thought that if this is a backward incompatible change, can we go further? We can separate features of Captures between the two structures Captures and NamedCaptures:
impl Regex {
    ...
    pub fn captures<'t>(&self, text: &'t str) -> Option<Captures<'t>> { ... }
    pub fn named_captures<'r, 't>(&'r self, text: &'t str) -> Option<NamedCaptures<'r, 't>> { ... }
    ...
}

impl Captures<'t> {
    // Like today, but there are no more field `named` and methods `names` and `iter_names`
}

struct NamedCaptures<'r, 't> {
    regex: &'r Regex,
    captures: Captures<'t>
}

impl<'r, 't> NamedCaptures<'r, 't> {
     fn captures(&self) -> &Captures<'t> { ... }
     fn name(&self, name: &str) -> Option<&'t str> { ... }
     fn iter(&self) -> SubCapturesNamed<'r, 't> { ... }
}

The main thing that we are doing here is moving methods name and iter_named from Captures to new NamedCaptures. This solution offers the most flexibility:

Captures is not dependent on Regex, like today, but loses methods name and iter_named
NamedCaptures is depended on Regex (lifetime 'r) and allows you to work with names, borrowing them from Regex.

@defuz I am honestly not a huge fan of increasing the API surface. IMO, there are already too many methods with too many decisions that the caller needs to make. I would be fine with an Arc for now. (And nice catch about Rc. It is important for Regex to be Sync!)

I made some updates:

Add use of Arc, so Captures no longer dependent on Regex
Fix #168
Make rebase

The problems that I see now:

Documentation about lifetimes should be updated
It makes sense to add NamedGroups::Empty variant to avoid useless copying of Arc<HashMap<...>> in a case when the regular expression does not have the named group.

@BurntSushi what you think?
I also do not quite understand the reason of duplicate original, cap_names and named_groups fields of Program inside Exec struct. Can we store these fields directly in the Exec?

@defuz Lookin' pretty good! I had some nits, and I would like to leave out breaking changes so that we can get the Arc stuff merged now.

I also do not quite understand the reason of duplicate original, cap_names and named_groups fields of Program inside Exec struct. Can we store these fields directly in the Exec?

Hmm, I don't think any of those fields are in the Exec struct? In my multi branch, I've moved cap_names to the Insts type, and would probably also move named_groups there.
There may be some other refactoring to be done here, but I'd prefer holding off because my multi branch is going to mess around with it in quite a big way. (To support matching multiple regexes and reporting overlapping matches in a single pass.)

@BurntSushi Perhaps we can release fixes for lifetimes before 1.0? According to RFC 1105 (API evolution) generalizing of function is minor change:

The type of an argument to a function, or its return value, can be generalized to use generics, including by introducing a new type parameter (as long as it can be instantiated to the original type).
...
Introducing generics in this way can potentially create type inference failures, but these are considered acceptable per the principles of the RFC: they only require local annotations that could have been inserted in advance.

@defuz Right, but we're not just changing function parameters. It's adding a new lifetime parameter to a public type. In theory, it's possible to add a new type parameter if we give it a default, but you can't do that with lifetime parameters.
My goal is to march towards 1.0 so that we can fix these and other issues. Hopefully it happens in the next couple months.

@BurntSushi Oh, you're totally right, it seems that I'm blindness to incompatible changes. :(
I reverted backward incompatible changes but keep renaming of the lifetimes and clarifying in the documentation. Now everything looks good to me -- let me know if you have any comments.

@defuz This looks exquisite! Really nice work! As soon as CI comes back this is good to merge. Thank you. :-)


(BKR-607) Remove tar dependency for AIX

Prior to this commit, Beaker installed -- and removed -- tar as
a dependency of the puppet-agent package on AIX. This dependency
has been removed from puppet-agent.
This commit removes the logic to install and remove the tar rpm
from AIX. It also updates the rpec test for remove_puppet_on
on AIX to remove the expectation that tar would a dependency.

woo, code removal!  :100: pts to you, sir!

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1742/
Test FAILed.

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1745/
Test FAILed.

wow, you are seeing all the crazy corner fail cases.  Third time's the charm

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1746/
Test PASSed.


Supported applications

Hi there,
Based on the below line:
"The same add-in and business logic works across desktop (Outlook on Windows and Mac), web (Office 365 and Outlook.com), and mobile."
Does it mean that the Outlook Web App (OWA) is not supported for Exchange 2013 & 2016 mailboxes ?
I do see the Add-In button in the OWA, but it does not behaviour as the manifest dictates.  It seems to always look for a functions.js file.

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

ID: 3b2e062e-1a7a-1861-bf20-c23ac64d0d37
Version Independent ID: ae2d1395-2a87-1bda-00fb-1b30f8e27b66
Content: Outlook add-ins overview - Office Add-ins
Content Source: docs/outlook/outlook-add-ins-overview.md
Product: outlook
Technology: add-ins
GitHub Login: @o365devx
Microsoft Alias: o365devx

My mistake.  Looks like OWA is part of Office on the web.


Do you have a plan to add I2S interface for Audio function?

The makecode arcade manual saids "(only) DAC or PWM" is supported for Audio interface.
I am curious if you have a plan to add I2S interface.

@mmoskal

We have currently no plans to do that, though I agree it would be a nice addition.

Closing old issues.