v2.7.6 passenger module and nginx.conf issue

here is my conf:
    "nginx": {
      "repo_source" : "passenger",
      "package_name" : "nginx-extras",
      "user": "webserver",
      "init_style": "init",
      "source": {
        "modules": [
          "nginx::passenger"
        ],
        "use_existing_user" : true
      },
      "passenger": {
        "install_method" : "package",
        "ruby": "/home/webserver/.rvm/gems/ruby-2.2.2@my_rails/wrappers/ruby"
      }

while installation I do see:
STDERR: Configuration file '/etc/init.d/nginx'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation

I've checked out both version of a file, and new version that goes with passenger not correct, it has default user 'user www-data;' directive.

@dedicatted  I ran into the same issue and just solved it this am. I think you need to remove the source attribute as you want only the nginx-extras package. What tripped me up was that I had to remove both ['nginx']['install_method'] and ['nginx']['source'].
There isn't an actual bug with the cookbook, I think the documentation just needs to be improved in the passenger section of the README.
Here is my config
  "nginx" => {
    "init_style" => "upstart",
    "default_site_enabled" => false,
    "version" => "1.10.2",
    "keepalive_timeout" => "301",
    "status" => {
      "port" => "8090"
    },
    "repo_source" => "passenger",
    "package_name" => "nginx-extras",
    "passenger" => {
      "version" => "5.0.30",
      "install_method" => "package"
    }
  }

Thanks for opening this issue. Just today we merged the changes from the chef_nginx fork of this cookbook back to master here. It’s a pretty huge change set and includes over a year of active development that resulted in several major releases. I think there’s a very high chance that this issue has been resolved with that work and at this point I’m going to close this issue out. I’d encourage you to checkout the master branch and please open this issue back up if you’re still having the problem there.
Here’s the changes that were just merged in: https://github.com/chef-cookbooks/nginx/pull/435


⭐FEAT: Add grow animation to the contributor item

TODO:

When hovered over the image in contributor item , the image div should pop out or show some kind of animation
keep the animation as minimalistic as possible

I am available and eager to work on this task. Please assign me !

@aashay28 Sure thing. Assigned to you.

I have completed the task. Please review the attached video and let me know if it is feasible. If you approve, I will generate a pull request. Thank you.

@aashay28 SICK!!! That looks cool. Great work , Please raise a PR. Excited to merge this

LGTM 👍🏼
I think i could be better since it expands the card as well
minor tweaks will do the work


Add storage client

Problem:
Cannot interact with k8s storage API without using k8s api directly.
Solution:
Add generate client for storage api.
Related issue:
https://github.com/rancher/rancher/issues/20315

lgtm


New Imaging Request - required visit not enforced

When requesting a new imaging, visit is required but a user can still save without choosing a visit. See https://github.com/HospitalRun/hospitalrun-frontend/pull/2552#pullrequestreview-576596693
🐛 Bug Report
When creating a new imaging request, a user should not be able to save without specifying a visit.
To Reproduce
Go to staging https://staging.hospitalrun.io/
Create a new patient and create one visit for this patient
Create a new imaging request leaving the visit field empty
Notice you are allowed to save even though the visit is marked as required
Expected behavior
User should not be able to save a New Imaging request without selecting a visit.
Reference
See how the Patient or Type field are handled and do the same
Your Environment

node version: 6,8,10
fastify version: >=1.0.0
os: Mac, Windows, Linux
any other relevant information

@blestab  Can I be assigned to this task?

@blestab  Can I be assigned to this task?

@blestab Can I be assigned to this task?

Thank you @SamuelQZQ, Let's get #2557 out first then will assign this to you once done.

@blestab Can I be assigned to this task?

Thank you @SamuelQZQ, Let's get #2557 out first then will assign this to you once done.

Hi,
Sorry I'm getting in the way :)
"See how the Patient or Type field are handled and do the same"
In this case I don't think it's okay to manage them in the same way, with which search criteria would you do it?
I don't think it would be good to even see them all.
It would be necessary to decide with which criteria to show the visits.

Hi,
Sorry I'm getting in the way :)
"See how the Patient or Type field are handled and do the same"
In this case I don't think it's okay to manage them in the same way, with which search criteria would you do it?
I don't think it would be good to even see them all.
It would be necessary to decide with which criteria to show the visits.

Hi,
Sorry I'm getting in the way :)
"See how the Patient or Type field are handled and do the same"
In this case I don't think it's okay to manage them in the same way, with which search criteria would you do it?
I don't think it would be good to even see them all.
It would be necessary to decide with which criteria to show the visits.

Thanks @alexma01, you're not in the way at all, all ideas are welcome; Why don't you hop onto our slack and tell us more about your thoughts about this

Hi,
Sorry I'm getting in the way :)
"See how the Patient or Type field are handled and do the same"
In this case I don't think it's okay to manage them in the same way, with which search criteria would you do it?
I don't think it would be good to even see them all.
It would be necessary to decide with which criteria to show the visits.

Thanks @alexma01, you're not in the way at all, all ideas are welcome; Why don't you hop onto our slack and tell us more about your thoughts about this

Hi @blestab , Is there anything that I can help in this issue?

@bernoraj currently I'm afraid it's stuck. if you want to take it over, you're welcome to it

Sure @tehKapa , I would like to take it up.


Using KNetCompactedReplicator a System.ArgumentNullException is raised in KNetProducer

Using KNetCompactedReplicator when
https://github.com/masesgroup/KNet/blob/5ab24481744db62c8ded79b7e7ec5c5f6c0e8f74/src/net/KNet/Specific/KNetCompactedReplicator.cs#L269
is invoked it raises a System.ArgumentNullException in
https://github.com/masesgroup/KNet/blob/5ab24481744db62c8ded79b7e7ec5c5f6c0e8f74/src/net/KNet/Specific/Producer/KNetProducer.cs#L406
Originally posted by @masesdevelopers in https://github.com/masesgroup/KEFCore/issues/60#issuecomment-1694791707

The problem comes from https://github.com/masesgroup/KNet/blob/5ab24481744db62c8ded79b7e7ec5c5f6c0e8f74/src/net/KNet/Specific/Producer/KNetProducer.cs#L469 because the Dispose shall not be called there: the Callback is an input of the function, in this way it is called twice


First impressions

The WHEN/IF/THEN syntax is clean and easy to understand and the README explanation is clear and concise.
Where and how do entities like person.tom and lights.porch_sconce_lights get defined?
I'm curious about IS.  It's more than a simple equality, right? So does person.tom IS 'home' mean

Boolean property home of person.tom == True, or does it mean
Location state string of person.tom == 'home'?

Entities (anything with dot notation) are defined by home assistant - think of them like sql table references.
Your second interpretation is closer to the truth. in OttoScript  attributes are denoted by entity:attr, so it's essentially shorthand for person.tom:state == 'home'.


Support interruptible send within the Producer

First of all, thanks for taking this initiative. I like it, a lot! It is an opportunity for idiomatic (async and reactive) Kotlin integration with Kafka (coroutines and Flow included).
I wonder if we can improve this suspending function in the Producer.kt :
public suspend fun <A, B> KafkaProducer<A, B>.sendAwait(
  record: ProducerRecord<A, B>,
): RecordMetadata =
  suspendCoroutine { cont ->
    // Those can be a SerializationException when it fails to serialize the message,
    // a BufferExhaustedException or TimeoutException if the buffer is full,
    // or an InterruptException if the sending thread was interrupted.
    send(record) { a, e ->
      // null if an error occurred, see: org.apache.kafka.clients.producer.Callback
      if (a != null) cont.resume(a) else cont.resumeWithException(e)
    }
  }

Do we want to interrupt it (the thread) on the coroutine cancelation? Or, I am exaggerating, and this is not needed?
I can see that you have wrapped the poll method on the Consumer.kt in runIterruptable:
 runInterruptible(dispatcher) {
        poll(timeout.toJavaDuration())
      }

Obviously, this is a blocking function, and there is no (async) callback like in the send method on the Producer side. It was interesting to learn that the exception is of type org.apache.kafka.common.errors.InterruptException :)  But, this part is clear. It will work.
I am just trying to understand these two low-level methods at first, and how we translate them into the Kotlin Coroutines (suspension) world.

Hey @idugalic,
Yes, we absolutely can and should! Most of the code that is currently on main will probably disappear, since Consumer.kt will be replaced by the currently open PR.
Which takes care of providing guarantees in terms of committing offsets, etc. (A commitAsync will not do anything unless you also call poll. So for committing offsets in an async in the face of cancellation/interruption, you need to perform addition poll just for the commitAsync to work. That is complexity I thought should be hidden for the users.
Similarly I wanted to add a more elaborate Producer API that implements all of this correctly. Especially linking the Java interruption world to the KotlinX cancellation world, and wiring CoroutineContext is the most efficient way.
There are other methods of send that return a KafkaFuture, perhaps simply wiring Future#cancel to suspend is sufficient to make send interruptible? 🤔
Here are a couple of convenient methods to bridge KotlinX Coroutines JDK8 to KafkaFuture:
https://github.com/nomisRev/kotlin-kafka/blob/13276a48cac04d24625baa50094586b5179e1130/src/main/kotlin/io/github/nomisRev/kafka/KafkaFuture.kt#L27

For the Producer API I had something like this in mind:
interface KafkaSender<K, V> {
  fun send(records: Iterable<ProducerRecord<K, V>): Flow<RecordMetadata>
  fun sendTransactionally(records: Iterable<ProducerRecord<K, V>): Flow<RecordMetadata>
  fun transactionManager(): TransactionManager
  suspend fun <A> withProducer(action: suspend KafkaProducer<K, V>.(KafkaProducer<K, V>) -> A): A
}

I like it https://github.com/nomisRev/kotlin-kafka/blob/13276a48cac04d24625baa50094586b5179e1130/src/main/kotlin/io/github/nomisRev/kafka/KafkaFuture.kt#L27
Utilizing KotlinX Coroutines JDK8 to bridge the Futures to the coroutine suspensions looks like a good idea.
I am not super experienced with KotlinX Coroutines JDK8 library, but it looks like await is cancellable.  This might be the way going forward, we just need to take into account the NOTE (one-shot futures) below.
NOTE:

This method is intended to be used with one-shot futures, so on coroutine cancellation the CompletableFuture that corresponds to this CompletionStage (see CompletionStage.toCompletableFuture) is cancelled

Producer API (interface KafkaSender<K, V>) looks good to me. I wonder if we can merge two send methods into one?

Hey @idugalic,
I've looked into this and it's not possible to cancel a KafkaProducer#send call. The Kafka SDK immediately puts it on the buffer, and calls the callback (or Future) whenever it's been acknowledged or not.
I have build much more powerful DSL compared to the previous contract I showed here above. https://github.com/nomisRev/kotlin-kafka/pull/156. Curious if you have any thoughts or feedback!


SBOM ingestion

[ ] All tests passed. If this feature is not already covered by the tests, I added new tests.
[ ] All static analysis checks passed.
[ ] This pull request is on the dev branch.
[ ] I used gofmt for formatting the code before submitting the pull request.

I have read the CLA Document and I hereby sign the CLA

The point of this PR is part of 3 PRs that enable the command "jf sbom enrich" which takes XML/JSON of a CycloneDX SBOMs of packages/dockers, sends it to XRAY for scanning (to find vulnerabilities) and print out the input (which is xml/json cyclonedx) with vulnerabilities section that was found in XRAY. It basically uses a new API that can digest these new formats, but it still uses GraphScan and ExportGraphScan which are pre-existing APIs. That's why there are some similarities between the two.

Add description to the PR
Change the README.md to include those changes.
Add tests at tests for the new service

Added description and changed README.md to include those changes.
Regarding tests - I use similar functions to Scan just with different XRAY Api. I have not seen tests for these functions in scan service.
@attiasas


Missing dist folder in version 1.0.2

I think you forgot to publish the dist folder in version 1.0.2. Accordingly, only the readme, license and package.json are included in the dependency.

+1

It should be fixed on v1.0.4 https://github.com/danestves/lite-embed/releases/tag/v1.0.4


When the sub blocks are collapsed, the chart will display “collapsed:: true”

This is a little annoying, but if don’t collapse the sub blocks it would display correctly for now.

Please try to see if it still persists in the latest version


Hello professionals, how can I turn on the camera through matlab?

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
{ R200 / F200 / SR300 / ZR300 / D400 }

Firmware Version
(Open RealSense Viewer --> Click info)

Operating System & Version
{Win (8.1/10) / Linux (Ubuntu 14/16/17) / MacOS

Kernel Version (Linux Only)
(e.g. 4.14.13)

Platform
PC/Raspberry Pi/ NVIDIA Jetson / etc..

SDK Version
{ legacy / 2.. }

Language
{C/C#/labview/nodejs/opencv/pcl/python/unity }

Segment
{Robot/Smartphone/VR/AR/others }

Issue Description
<Describe your issue / question / feature request / etc..>

Hello professionals, how can I turn on the D435 camera via matlab?

Unlike #13546, I just want to start the D435 via matlab and have it work properly and continuously, not get a frame, can you help me with this?

If you want to stream with the RealSense MATLAB wrapper instead of getting one frame then https://github.com/IntelRealSense/librealsense/issues/2705 and https://github.com/IntelRealSense/librealsense/issues/5514 may be helpful discussions.
There is also a discussion at the link below.
https://support.intelrealsense.com/hc/en-us/community/posts/360038629154-How-to-stream-video-from-a-d435-camera-in-matlab

Hi @wenmingxiaohuo  Do you require further assistance with this case, please?  Thanks!

Case closed due to no further comments received.


[HOLD for payment 2023-06-02] [$1000] Spinner persists to magic code section once user enters email and clicks on continue

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

Action Performed:

Navigate to sing in page
Enter email and click on continue

Expected Result:
Spinner shouldn't persist to magic code section for the action taken on email section. Spinner on magic code section should only be displayed when magic code is entered and 'Sign in' button is clicked
Actual Result:
Spinner persists to magic code section
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

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

[x] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number:
Reproducible in staging?: needs reproduction
Reproducible in production?: needs reproduction
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/43996225/235268383-ed5931c7-9d74-41dd-93c3-6e7833d88896.mp4
Expensify/Expensify Issue URL:
Issue reported by: @natnael-guchima
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1682624828183479
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~012d46493c46fb789a
Upwork Job ID:<PHONE_NUMBER>452184576
Last Price Increase: 2023-05-16

Triggered auto assignment to @JmillsExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

@JmillsExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

@JmillsExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Apologies, jumping in to test this one now.

Actually not sure what's going on with this one and it's very hard to reproduce, so I'm going to take this back to Slack first.

Ok, discussed via Slack so see the linked thread for more context. Opening this one up to the community.

Proposal
Please re-state the problem that we are trying to solve in this issue.
Loading indicator show after users enter email and continue
What is the root cause of that problem?
In https://github.com/Expensify/App/blob/5e69967c90456682a94d28dd2825d773fe851c88/src/pages/signin/LoginForm.js#L207
https://github.com/Expensify/App/blob/5e69967c90456682a94d28dd2825d773fe851c88/src/pages/signin/ValidateCodeForm/BaseValidateCodeForm.js#L265
https://github.com/Expensify/App/blob/5e69967c90456682a94d28dd2825d773fe851c88/src/pages/signin/PasswordForm.js#L235
We're using this.props.account.isLoading to show the loading indicator in these components. When we call API sign-in

we update isLoading = true (show spinner)
update API response in Onyx
redirect to other screen
update isLoading = false (hide spinner)

What changes do you think we should make in order to solve the problem?
We should only open validation form when isLoading in login form is false
In beginSignIn function, I add loadingScreen: 'LoginForm' in optimistic data, then clear it in successData and failureData
In SignInPage we only allow show validation form when loadingScreen!=='LoginForm', we also update the welcome text accordingly
        const isLoadingLoginForm = this.props.account.loadingScreen === 'LoginForm';
        const showLoginForm = (!this.props.credentials.login && !this.props.credentials.validateCode) || isLoadingLoginForm
        const showUnlinkLoginForm = ... && !isLoadingLoginForm
        const showPasswordForm = ... && !isLoadingLoginForm
        const showValidateCodeForm = ...&& !isLoadingLoginForm
...
                    <LoginForm isVisible={showLoginForm || isLoadingLoginForm} blurOnSubmit={this.props.account.validated === false} />
                    {showValidateCodeForm ? (
                        <ValidateCodeForm isVisible={showValidateCodeForm && !isLoadingLoginForm} />
                    ) : (
                        <PasswordForm isVisible={showPasswordForm && !isLoadingLoginForm} />
                    )}

What alternative solutions did you explore? (Optional)
We can change isLoading value to something like loadingScreen and only show spinner in correct screen

@aimane-chnaif Thanks for pointing that out, I' updated my proposal https://github.com/Expensify/App/issues/18183#issuecomment-1539371121 a bit to cover this case

@aimane-chnaif proposal is ready for another review I think

Hey @aimane-chnaif, just bumping for C+ review of this proposal.

Following on that last comment, I wanted to give everyone on the issue a heads up that I'll be out for the rest of the week. Feel free to re-apply the Bug label if needed.

We can change isLoading value to something like loadingScreen and only show spinner in correct screen

I think my second solution can be better. Do you agree with this solution? @aimane-chnaif

Agree with you, what about adding new props like loadingScreen (loadingForm) @aimane-chnaif

can you also test if loading forever after refresh page while api call?

Here is my result:
https://github.com/Expensify/App/assets/113963320/f9b35336-a5b1-45a2-b639-0acbd099c954
https://github.com/Expensify/App/assets/113963320/f9fe7e96-7402-4b8d-8bc8-b933c09fec70

@aimane-chnaif The PR is ready for review https://github.com/Expensify/App/pull/19393. Please help take a look

Alright, let's circle back here and close the loop. @aimane-chnaif do you mind kicking off the BugZero checklist above?

In the meantime, it looks like we have the following payouts for this issue based on the PR assignment and merge.

Issue reporter: @Natnael-Guchima $250
Contributor: @tienifr $1,500
Contributor+: @aimane-chnaif $1,500

If all looks good there, then we can wrap this up in the coming days.

Alright, @aimane-chnaif I've invited you to the Upwork job. @Natnael-Guchima and @tienifr I don't think I've hired either of you before, do you mind applying for the Upwork job and I can make sure you're both paid? Thanks!

Alright, @aimane-chnaif I've invited you to the Upwork job. @Natnael-Guchima and @tienifr I don't think I've hired either of you before, do you mind applying for the Upwork job and I can make sure you're both paid? Thanks!

Applied. Thanks.

@tienifr Mind linking me your Upwork profile so I can confirm? We have a lot of proposals on the issue.

In the meantime, @Natnael-Guchima I've sent you a contract and we can get that settled tomorrow. @aimane-chnaif You're all set!

P.S. @aimane-chnaif You still owe me the BZ checklist.

@tienifr Just sent you a contract. Not sure if the other proposal is on another project, I couldn't find you on this one.

Awesome, thanks for the quick reply! Then @tienifr you should be all set with the payment on Upwork.

In the meantime, @Natnael-Guchima I've sent you a contract and we can get that settled tomorrow. @aimane-chnaif You're all set!

I have accepted the offer. Thanks Jason.

Everyone is all paid out here. We're done, thank you all!


Feature request: allow transformation of generic array-syntax in IDE helper docblocks

Larastan Version: master
--level used: max
Branch with WIP: https://github.com/jnoordsij/larastan/tree/generalise-ide-helper-type-transformer

Description
In https://github.com/nunomaduro/larastan/pull/479 a resolver was introduced to interpret docblocks like \Illuminate\Database\Eloquent\Collection|\App\Account[] $accounts as \Illuminate\Database\Eloquent\Collection<\App\Account> $accounts.
It would be useful to also accept another pattern, namely \Illuminate\Database\Eloquent\Collection|array<\App\Account> $accounts and convert this. This pattern is the result of auto-correction by PHP_CodeSniffer using my current ruleset.
In (https://github.com/jnoordsij/larastan/tree/generalise-ide-helper-type-transformer) I made a first attempt at implementing this, but it currently seems to be resolving incorrectly for some other union types. It also contains tests for both transforms.

Hello @jnoordsij! 👋🏻
The feature in #479 is not the nicest thing in the world.
Using a PHP generics compatible IDE is the sustainable solution.

@szepeviktor thanks for your quick reaction!
I totally agree, but looking at https://github.com/barryvdh/laravel-ide-helper/issues/942, it seems like support for that won't land anytime soon, so I was hoping for a workaround.

so I was hoping for a workaround.

You may get it anytime. Here we have a small community.

There is no plan to support this. It is a really old syntax. You can use the generic version instead \Illuminate\Database\Eloquent\Collection<int, \App\Account>

Update for those who find this: https://github.com/barryvdh/laravel-ide-helper/pull/1298 has been merged in the Laravel IDE helper packages, so if you use the dev-master version of this package, you can automatically update your docblocks to use the new generic notation.


Refine validation reporting

There is no Pivotal Card for this PR -- however, this is an attempt to get all the validation errors we report into a similar format so that we can expect something more specific when we reach the message column.

Yeah. Good call. Nice work.

Smart work. I like it. LGTM.


Tweak setting of USER env var

Back port of https://github.com/Homebrew/install/pull/213

Thanks for the backport, Joe!


feat: 46 multi part enumtype extraction

Summary of Changes
Currently, valid values for the enum annotations were determined only via the type string. In order to achieve a higher recognition rate of the enum annotations, the recognition of the valid values was extended to the description.
Testing Instructions

Run pytest for test_extract_valid_literals.py.
Check the results of pytest.

🦙 MegaLinter status: ❌ ERROR

Descriptor
Linter
Files
Fixed
Errors
Elapsed time

✅ PYTHON
black
2
1
0
0.6s

✅ PYTHON
flake8
2

0
0.34s

✅ PYTHON
isort
2
2
0
0.23s

❌ PYTHON
mypy
2

6
2.02s

✅ PYTHON
pylint
2

0
1.63s

✅ REPOSITORY
git_diff
yes

no
0.04s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff
MegaLinter is graciously provided by


improve UI for VectorMediasPickerActivity

This pull request adds a bunch of UI improvements in the MediasPicker activity and renames a couple of layout files for clarity.

Signed-off-by: Dillon Kanada<EMAIL_ADDRESS>

Hi @dkanada ,
Thanks for the PR. After a quick look on the changes it LGTM.
I'll check on a real device the changes this week.
For the future, do not hesitate to create several PRs for atomic feature change. For instance https://github.com/vector-im/riot-android/pull/2610/commits/da233f9d1fdba2582b91f9cf9f4633f11b812aaf should be in a separate PR.
Thanks!
Benoit

I will make sure to separate atomic changes in the future, I wasn't sure how much you wanted to get spammed with small changes at first.
By the way, the gallery placement in MediaPickerActivity is quite the headache to code around. Totally understand why it was designed that way to be fair, the camera related stuff looks like a nightmare to work with. I was trying to think of a decent fix but that activity is absolutely massive at the moment so I ended up just hiding the gallery in landscape mode. I figure if you have your phone in landscape you plan on taking a photo, not selecting a photo from the gallery.
In the future I want to delete all the preview code in MediaPickerActivity and hand the selected media off to MediaPreviewActivity for confirmation. Less duplicate code and a smaller PickerActivity.

@bmarty need to wait for my other phone to charge so I can fix the main section of this PR without affecting my non-debug instance, are there any flavors that can be installed side by side with a release version?
Also, I will remove the changes to the invite page entirely since the app is getting a redesign at some point, let me know if you want me to put those in a separate request instead. I might close this entirely depending on how the UI has changed since I last checked the development version.

There is no flavor to install several versions of the app on the same phone

Okay, all the merge issues are fixed and I think I got all the changes you requested. You should be able to try it out now without any build errors.

Okay, all the merge issues are fixed and I think I got all the changes you requested. You should be able to try it out now without any build errors.

The lint errors are fixed now and I can finally stop checking the travis logs.

Hi @dkanada ,
Thanks for the update. I wish I will have time to check your PR before the end of the week.
Benoit

Whoops, I was cleaning up my fork to fix some rebase issues.

Had to rebase to fix merge issues again, here are screenshots for the invite activity.

Hello @dkanada ,
I haven't understand well but @giomfo explained it to me. With Invite by ID you have the possibility to invite several users by providing comma separated value. I think it is not possible anymore with your PR.
That said, the current wording are not correct (should be Invite by ID(s) and same thing for the popup displayed when Invite by ID is clicked.
The US is not perfect and could be improve but we do not want to lose the possibility to invite several user at once.
Benoît

@bmarty I can add that functionality back if you want. I think it would work fine with the toolbar, still have to check though. You can already invite several users by simply going to the next page and selecting add another user as well.

removed all the FAB and validation stuff and rebased on develop


Wrap continue button in form instead of anchor

ADO-129454
Description
This PR fixes an a11y issue where a button was wrapped in an anchor tag. This causes an issues for screen reader users since it will announce the anchor tag first in focus order and then the button. Placing the button in a form instead and setting the action to the URL fixes this issue. The caveat is that as soon as we set the button type to anything (in this case submit), Tailwind's preflight styling sets the background for buttons with a set type to transparent. Explicitly setting the background color again fixes this issue.
What to test for/How to test

Pull in branch
Type npm run dev
Navigate to dashboard and click any of the links, which will open the exit beta prompt. Ensure it links to another page as expected (won't actually load if not authenticated but should redirect regardless)

Closing this as it's not necessary. Was going off the picture in the task from the a11y audit where we were still wrapping a button with an anchor tag, but that is no longer the case. We should be requesting the DS team to allow for a link to be styled like a button though. Currently when we supply an href to the Button component it doesn't take the primary styling, so we're left with essentially a basic anchor tag with link styling.


beginner trouble

can someone see what wrong?

You should ask such questions at InfluxDB Community Issues here are meant for the code repository.
Also the error suggests that, your python client is unable to connect to the Database. Make sure you are able to reach InfluxDB via your network or if it is on your laptop try a HTTP request via cURL:
curl -i -XGET http://localhost:8086/ping

or
curl -i -XGET http://IP_Address_of_your_server:8086/ping


Can't build, missing com.sleepycat.je-7.4.5 jar in Maven Central

Error on mvn install (After clean git clone of the project).

Failed to execute goal on project graph-repository-connector: Could not resolve dependencies for project org.odpi.egeria:graph-repository-connector:jar:1.1-SNAPSHOT: Could not find artifact com.sleepycat:je:jar:7.4.5 in central

Maven central has a couple of other versions: https://search.maven.org/search?q=g:com.sleepycat AND a:je

Intriguing. I see only 18.3.12, 18.1.11, 18.3.1, 5.0.73, 4.0.92 too
I've checked our code dependency analyzer and it reports we are using 18.1.11
However if I look at the output of mvn dependency:tree I see that org.janusgraph:janusgraph-berkeleyje:jar is referring to 7.4.5 . That is a component from the janusgraph community and the dependency is expressed at https://repo1.maven.org/maven2/org/janusgraph/janusgraph-berkeleyje/0.3.1/janusgraph-berkeleyje-0.3.1.pom
This is also the latest version of janusgraph
So I'm not quite sure why our 'clean' builds work - it looks like we may resolve to a much later version
Are you building from full egeria source or making use of the maven artifacts from central
We just pushed some egeria 1.0 artifacts. but they'd been held up for a while on build related issues.
In case it helps, As an alternative https://nexus.odpi.org/content/groups/public/ is the repository we are pushing snapshots too

As you mentioned a clean clone I'm trying that here again with a cleared out ~/.m2 to see if I can repro the issue.

Yeah I worked around it by adding:
<dependency>
  <groupId>com.sleepycat</groupId>
  <artifactId>je</artifactId>
  <version>18.3.12</version>
</dependency>

to the dependency management, that made the build succeed was just a bit worried that it might break something when running it all. I'm completely new to Egeria.
If I see any issues I'll downgrade it to 18.1.11. Thanks for quick reply.

Hi again,
I was able to build 'master' from a new clone & with an entirely clean .m2 (cache). I did this under linux (ubuntu 19.04 x86_64). I saw no issues with dependencies
In my log I saw:
Downloading from central: https://repo.maven.apache.org/maven2/org/janusgraph/janusgraph-berkeleyje/0.3.1/janusgraph-berkeleyje-0.3.1.pom
Progress (1): 2.2/3.3 kB^MProgress (1): 3.3 kB    ^M                    ^MDownloaded from central: https://repo.maven.apache.org/maven2/org/janusgraph/janusgraph-berkeleyje/0.3.1/janusgraph-berkeleyje-0.3.1.pom (3.3 kB at 408 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/com/sleepycat/je/7.4.5/je-7.4.5.pom
Downloading from oracleReleases: http://download.oracle.com/maven/com/sleepycat/je/7.4.5/je-7.4.5.pom
Progress (1): 1.9 kB^M                    ^MDownloaded from oracleReleases: http://download.oracle.com/maven/com/sleepycat/je/7.4.5/je-7.4.5.pom (1.9 kB at 1.3 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/janusgraph/janusgraph-lucene/0.3.1/janusgraph-lucene-0.3.1.pom

So it is picking up 7.4.5, though going to the oracle repo to find it. I've NOT explicitly defined that repo nor do we have reference to it in the pom (ie in ). 'mvn help:effective-pom' gives no hint as to where this comes from either, so I am unsure at this point where the definition is for oracleReleases
Could it be that you are unable to reach the oracle repo?
I'm using Java 8 (212 openjdk) & maven 3.6.1 - do you have something radically different?(our prereq checks mandate a minimum 8/152 and 3.5.0. Most of the team/users I know of are using macOS, some linux. Formal builds are linux, there are some windows users... though these shouldn't be factors.
Did you keep a full log? what do you see in reference to sleepycat if so?
I am concerned if we have an issue that makes it difficult for others to consume.
Feel free to raise any other issues you find getting up to speed.

Some references in https://github.com/opensourceBIM/BIMserver/issues/734 - though it only confirms the existance on the oracle rep

That oracle is not in my list (I'm via company maven proxy). So it only looks in maven central (and some internal ones).
I can confirm that if I add the oracle repo in the pom it can find the dependency.
So doing that is an option and adding the sleepycat as a managed dependency with a version that's in maven central is also working fine as far as I can tell.
Thanks again!

I'm inclined to think we should raise this issue with the JanusGraph team - overall I think it would be preferable to rely on the maven central repo than oracle. WOuld you like to raise? or else I will and can add background.

Sure: https://github.com/JanusGraph/janusgraph/issues/1621
Feel free to add something there, I don't know the project :)

Thanks. I've updated the issue there , where there is a specific dependency on oracle declared (I missed first time)

Suggest we add a doc note on this


ics export form Exchange events backup

Closing this as we are currently only planning for pst exports for exchange.


Update C++ OpenMP reduction readme

Existing Sample Changes
Description
Restructured to match new format. Fixed some formatting issues. Rewrote for clarity.
Fixes Issue#
External Dependencies
N/A
Type of change

[x] Documentation

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Command Line
[x] VSCode

@ishaghosh27 please review.
@IgorOchocki and @jimmytwei added for notices.


CI: remove MySQL installation step

Github include mysql by default nowadays

Excellent news!
Thanks a lot for the fixes.
If you have ideas on how to fix the others...


[new linter] Checkpatch C Linter

Addressing https://github.com/w0rp/ale/issues/554.
This PR adds support for the Linux kernel's C linting tool, checkpatch.

It looks like these are the tests that are failing:

/testplugin/test/test_errors_removed_after_filetype_changed.vader
/test/test_ale_lint_command.vader

I haven't touched these so I'm not sure what is causing the issue

Don't worry about those tests. They fail randomly when running in NeoVim 0.3, and I've been slowly fixing some tests like that by re-running them a few times over.

Seeing as you seem to be interested in Linux kernel development, I'd be interested to know how you've configured ALE so it works well with editing Linux kernel code. I would like to make it so ALE makes it easier for working with projects like that by default.

Thanks for the input! I'll get on these changes. Unfortunately I've never done and Linux kernel dev so I wouldn't be able to say. I'm just working on C project and our team decided to use checkpatch for linting.

Got busy and had to put this down for a while long. Thinking I'm going to close it and take another stab at it when I get time.

Sure, sounds good to me. :+1:


Multiple origins

Add support for multiple origins
with this patch, origin may be defined as one of:

a string (default '*')
a regex
a function (returning a boolean)
an array of strings

this also moves the const declaration outside of the middleware function, which is a minor performance optimization.
This PR also adds the request dependency, as it's a peer of request-promise but will not be installed by default.
Resolves #8

With an eye on keeping this library simple I'm having a hard time understanding why you wouldn't just build up an appropriate string. I suppose you want to dynamically target an origin based on a request? Not completely against merging this but maybe there's room for a dumb-as-a-doornail library (this one) and one that is on par featurewise with express cors?

I think perhaps a simpler approach may work (say, only supporting regex or string instead of arrays), but worry the implementation may be confusing for folks coming from other libs.
As for if this is necessary, I'd personally argue that it's pretty key - it's not uncommon (at least for me) to have one or both of the following setups:

Same codebase on many subdomains - in my case, users of my product cam create their own websites on a subdomain. The FE is shared by all subdomains, and they use my API to fetch content based on the subdomain. So a regex approach is critical for me, and having a lib handle the Vary header and whatnot is definitely preferable to including middleware in my codebase (if only for test separation and inheriting OSS fixes).

More common, I run staging servers on a different domain (e.g. foo.com is prod, foodev.com is staging) - I try to avoid putting anything in staging that is different than prod, but don't want to allow * origins - so either I need > 1 whitelisted domain, or I need to put env specific configs in my headers, which means staging is slightly different than prod, and my prod config is untestable outside of prod (while trivial, still scary on principle).

I realize this may be a bit more esoteric than I think it is, but for me this is a make or break feature for any cors lib - I really appreciate the simplicity of micro-cors, and don't want to tip it towards feature bloat - so let me know if this is too much of a feature and I can maintain a fork, break this functionality out to a separate module, or simplify this PR.
Thanks for the review!

I think I'm going to go with my instinct to keep it minimal. I can definitely see your points but would rather not do it here... stepping back and looking at express cors for a minute it seems unfortunate that the underlying logic isn't exposed in a more reusable way. IMO ideally there would be a universal cors library that could be wrapped for any framework. It might be a really interesting thing to see if it can be worked out with the people developing express cors (e.g. either split into two libraries or just export non-cors specific functions)? That said cors is simple enough that I might even advocate for having custom app-specific logic live as a module in my app if you're doing something complicated enough.
Thanks for the back and forth!

Was this PR closed because allowing multiple origins is too much for this library or is it because this specific implementation of multiple origins is too complicated?
I could definitely use the ability to enter an array of origin strings.
Here’s a popular answer on SO that recommends comparing to an array of origins:
https://stackoverflow.com/a/1850482

Sounds like the recommended way to do it is to have your server read the Origin header from the client, compare that to the list of domains you'd like to allow, and if it matches, echo the value of the Origin header back to the client as the Access-Control-Allow-Origin header in the response.


fix(timezone-picker): fix select overrides

Description
I needed to make the TimezonePicker disabled in the project I am working on and found that it was impossible to do it through the overrides prop. The TimezonePicker supports overriding the Select element, but the overridden props were not properly passed to the Select element.
I have now added the select overrides to the OverriddenSelect element.
Scope

[x] Patch: Bug Fix
[ ] Minor: New Feature
[ ] Major: Breaking Change

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


updated test

So user input reset is also checked

@storm1er : I think it will be better to set inputBrowser.input.val("") instead of inputBrowser.input.val(inputBrowser.badValue), because it is closest to the reality. Badvalue can be some other stuff, it is depending of the input type.

Hmmm, you're right, editing now.


feat: add cacheable directive to more queries

Just a few more routes. All articles, and the A-Z route on /artists.

I pushed another commit to support ?nocache query param always skipping the cache. This way, we have an escape hatch and can support any preview functionality that's needed.


Word counter

This is a C++ program that counts the number of words in a sentence entered by the user.

@arpitbaheti2002 Please mention issue if closed by this PR

I don't see any issue I can link with my contribution. Should I create one and link it?
I am a beginner and still struggling with understanding open source. Sorry if I understood you wrong. Hoping for your guidance on this one.

Issue #128 can be linked with this contribution.

This is not good, that person raises issue 1st, please don't repeat this. Create Issue if assigned then make pr.

Extremely sorry, I did not have any idea about this. I Won't repeat it next time.
I am creating an issue, and follow the process you asked for. Thank You.


QUIC TLS conformance updates

Updates for a few issues related to conformance in the QUIC TLS implementation.

New commit pushed addressing a pre-existing use-after-free bug that the new tests highlighted in the CIs.

There are conflicts now, please rebase.

Ping for second review?

Force pushed an update containing a trivial renumbering of the scripts only as per @hlandau suggestion.
@t8m - please reconfirm? I assume the 24-hour timer does not need to reset?

Unfortunately, as I suspected, after #21565 went in the resulting merge conflicts were significant and non-trivial to resolve.
I've now rebased and resolved all of those conflicts, but this now needs another round of reconfirmations.

@t8m - please reconfirm?

Pushed. Thanks.


added few tests for max/min/copy

Added tests for different data types supported by the primitives.

Same tests implemented in Catch2 test framework in commit 2d10acd, so closing this pull request without merging.


Running tests and flake8

Hi,
Thank you for amazing work and also for merging my latest PR!
I have a few questions regarding tests and flake8:

What's the current process for running tests? python setup.py test that is mentioned at https://django-dynamic-preferences.readthedocs.io/en/latest/contributing.html fails.
flake8 seems to be failing now as well with multiple errors. Probably it was working before but since the flake8 version isn't locked, it stopped working with the latest flake8 updates. Should we lock the version or fix the code style?
Travic CI integration seems to be broken. Anything I can do to help with it?

Thanks!

Hi there! The current way to run tests is with tox. Once you have cloned the repo, run:
pip3 install --user tox
# run tests for all combinations of python and django versions
#(this will likely fail for some combinations, as you probably don't have multiple versions of python3 installed on your system)
tox
# run tests for a specific combination (here, django 3.1 on Python 3.9)
tox -e py39-django-31

All available combinations are described in the tox.ini file, let me know if it's working for you.
Regarding flake8, I'm not surprised, I don't think I've applied linting recommendations since years. Using something like black could be aa specific combination good idea to make the code more readable and solve a few flake8 in the process.
Apparently, Travis CI for open source projects is not free anymore. We'd have to migrate to something entirely different (possibly GitHub actions? I've never used it mysel though). I'd be happy to dedicate a few hours to help if you want to work on this!

Closing because of inactivity, and we have migrated to github actions since then


Cheerio node 12

@rauchg This contains #98

supports node 0.12 and fixes #99
removes jsdom completely in favor of cheerio which allows inlining document fragments correctly and likely improves performance per #80
adds code coverage info

Breakage:
Because jsdom was exposed with inlineDocument, that method now uses a cheerio document. I can't imagine that was a very popular feature though and I don't think preserving that interface is justified since cheerio does a better job of doing what juice is supposed to do, which is just inline documents.
Note, readme need some updating at the moment

Why would we ditch the simplest signature? juice(html) ?

That one had no callback, so the signature needed to be changed anyway and since it was overloaded in an awkward way it seemed like a good opportunity to remove that in favor of the explicit methods.

Breakage:
Because jsdom was exposed with inlineDocument, that method now uses a cheerio document.

You're probably right that this wasn't a very popular feature, but we should probably bump the major version here anyway.

Oh, yeah for sure the major version should be changed here. Cheerio has different behavior anyway, that is enough in itself.

The thing is, if we're going to make breaking changes, we should aim towards simplification.
Ideally, juice has no async signature.
Want to inline remote stylesheets?
inlineStylesheets(in, (err, html) => {
  juice(html);
});

Someone can write inline-stylesheets as a module that takes <link> and turns them into <style>.
Juice just grabs <style> and inlines it. Beautiful

Why would we ditch the simplest signature? juice(html) ?

That one had no callback, so the signature needed to be changed anyway and since it was overloaded in an awkward way it seemed like a good opportunity to remove that in favor of the explicit methods.

I think default export should be a very simple sync juice(html, css) function that returns inlined html and does not do any async fetching of css or parsing of <style> tags. This is basically what juice.inlineContent() does now. I believe this is the vision @rauchg has for the project. The other functions that do inlining can still be exposed for now, but I think eventually we should remove them in favor of other projects that wrap juice and provide that functionality.

@parshap Thanks. Even better, I think the second css parameter could be accomplished by the user by just adding additional <style> element(s) to the HTML.

@rauchg

The thing is, if we're going to make breaking changes, we should aim towards simplification.
Ideally, juice has no async signature.

Agreed! Although, I think we should do this iteratively: get these improvements merged in and go from there. Frequent breaking changes are not necessarily a bad thing as long as we are diligent with major version bumps, and I think it's more important that we keep things moving and encourage contributors. Look at browserify for an example.

@parshap Thanks. Even better, I think the second css parameter could be accomplished by the user by just adding additional <style> element(s) to the HTML.

My opinion here isn't too strong, but parsing <style> seems a bit more magical than an explicit CSS argument. This gives the user more control about what styles are included. For example, you may have a <style> tag on the page that you want left alone (e.g., contains @media queries).  Instead of inline-stylesheets, the helper module would then be something like get-styles.

I feel like not providing an options argument to juice(html) is going to reduce its utility quite a bit. For example, the media query options, it isn't useful to only allow the default if you use that signature. Do you want to use juice(html, options) and any of the async utility will be skipped in that method? Then are you both in favor of leaving the others as async or are you suggesting there only be synchronize methods at all?

Options are fine. My main objection really is the duality of sync and async signatures with no control for the user on how to get those resources.

There is some control through the library being used, though I understand what you are saying. Based on how I've always used juice, I've preferred the convenience of it being able to pull in resources, but totally agreed that the code that did that needed to be pulled into another project, which is what I did here. I've split off the options for the inliner now, so if someone wanted to take advantage of that, it is still available, and likewise, if someone wants to use the synchronous methods, there is juice(), juiceDocument() and inlineContent(). I'm not sure this is ideal, but it seems like a good improvement at least over the prior version. Let me know if you have further thoughts.

@rauchg @parshap any further thoughts?

Much better now, thanks!

I don't think we have a clear understanding of what we want the future API to be, so my thought is now to keep the API as backwards-compatible as possible. I think we should leave the default export interface to be the same as it is now: juice(filePath, [options], callback), including the same stylesheet inlining behavior there is now.
Externalizing the stylesheet inlining logic is the first step towards our goal, but let's separate the tasks of 1) fixing 0.12 and landing the other improvements in this patch, and 2) coming up with a more simple and modular interface. Let's get this PR merged in so we have 0.12 fixed and a cleaner codebase to work with, while continuing discussing around the future interface.
From my perspective, this PR needs the following before getting merged in:

Revert back to the old juice() interface
Update the readme to document the changes

@jrit: I'm happy to help if you'd like to delegate either of these tasks to me (happy to let you do the work as well :)).
@rauchg: What's missing from your perspective to get this PR merged in?

@rauchg: What's missing from your perspective to get this PR merged in?

Well, I guess that answers my question! Sweet. I still think we need at least an updated readme before making a release.

I will update the readme in the next 1-2 days. Thanks both for your time and feedback.


Investigate CLI options

I was looking at other create_blank_app cli tools and the one that seemed the most promising is create_nuxt_app.
They have the following structure:
SAO
They use a tool called SAO which is a scaffolding tool. It lets you define specific generators, that can combine different parts of a scaffold together. You can then pass options to the generators to scaffold a custom project based on the user input.
I would recommend that we create seperate branches for each lib (addon that can be changed eg. CSS framework or backend). Once we have the seperate branches we can compare them with main and see which files will need to be updated.
This is their SAO generator file. It defines where to get the different parts of the project that can then be installed: https://github.com/nuxt/create-nuxt-app/blob/master/packages/create-nuxt-app/lib/saofile.js
Inside the generator file you can define actions to build the starter:
Actions
Adds files to the template
if (this.answers.ui !== 'none') {
  actions.push({
    type: 'add',
    files: '**',
    templateDir: join(frameworksDir, this.answers.ui)
  })
}

Move files from one place to another
actions.push({
  type: 'move',
  patterns: {
    gitignore: '.gitignore',
    '_package.json': 'package.json',
  }
})

Modify a file
actions.push({
  type: 'modify',
  files: 'package.json',
  handler (data) {
    return { ...data, ...pkg.load(generator) }
  }
})

Remove a file
actions.push({
  type: 'remove',
  files: 'package.js'
})

Templates
In a separate folder they have all the required files to add a specific technology or framework. While their system is a bit more simple then ours (no backend), I think we can split specific parts of our starter into smaller segments.
Lets take the backend as an example:
We could move all the files we need for the backend to work in another folder. In our case these files would be:

package.json with only the extra packages and scripts needed to run the backend
/server
/tests/server

When the developers selected with-backend these files will be copied over. The templates folder is a seperate npm package, which is installed inside the CLI package. Through this the files can be accessed.
Prompts
They have one file in which all their questions are defined: https://github.com/nuxt/create-nuxt-app/blob/master/packages/create-nuxt-app/lib/prompts.js
These questions are asked and the answers are collected. SAO comes with a custom prompt system that we can use!
Conclusion
This option for the CLI will require a rewrite of the sidebase template. We will have to decide if we want to keep a demo version of sidebase in this repo, or if we create a new repo (or use sidebase-libs), however I believe this is the best option we can take to ensure we can continue to expand sidebase!

I would also recommend we use CAC to manage our CLI, as it allows us to easily add flags and more commands in the future.

Thanks!
Other options I found are: plop, hygen, slush.
Can you also look into those and see how they compare to sao / yeoman? Maybe one of them has a fresher approach -> SAO is deprecated by the maintainer.

Plop
Plop is based on handlebars, which means that all files that may be copied over will have to be written in the .hbs type. I am not sure how hard it will be to adjust our linting and tests accordingly. @BracketJohn, do you have any infos on this?
Other then this little issue, I like their syntax a lot. From all the packages it looks the easiest to use. It also uses inquiry.js as their prompt manager, which is a very advanced and versatile package that allows you to ask users complex questions.
An example for a template file can be found here: https://github.com/ru03/plopjs-example/tree/master/plop-templates
An example for the main "build" files can be found here: https://github.com/ru03/plopjs-example/blob/master/plops/redux.js
They structure their templates folder with separate folders for every question option. These parts are then imported and used accordingly.
What I really like about this package:

Easy to learn syntax
Little setup required
Many prompt options
Well integrated bridge between 2 stable, well maintained packages (handlebars and inquiry.js)

What we need to check:

Can be use .hbs files or will that destroy our options for linting/testing

Hygen
Hygen uses a similar approach to Yeoman, in the sense that it uses its own template language to allow us to scaffold a project. There is an example at hygen-CRA, however a lot of points I mentioned with Yeoman still apply. I belive that this kind of templating system becomes hard to maintain over a longer period of time. See an example of the template file here: https://github.com/jondot/hygen-CRA/blob/master/_templates/component/new/index.js.t
However, I would say, that if we do decide to use a scaffolding system that uses this apporch I would choose hygen over Yeoman.
Reasons:

Less boilerplate and easier to setup
Easier syntax and less work to boilerplate
See more reasons here: http://www.hygen.io/docs/faq#why-should-i-use-hygen

Slush
What I noticed immediately was that the last update was done in 2015. For me this is a pretty big red flag, as it seems that this package gets little support now adays. When going through their issues I also saw reports of security vulnerabilities . These issues are also not addressed by the maintainers.
Because of these reasons I would recommend we do not go with slush!

So as discussed orally: plop seems to be the most maintained + allows us to also change code inside the files we copy easily if we want to  via variables. One last thing to checkout before deciding: Do we have to use .hbs files always or do we have the option to put in vanillas ts and js files if we do not want variable-interpolation?

So as discussed orally: plop seems to be the most maintained + allows us to also change code inside the files we copy easily if we want to via variables. One last thing to checkout before deciding: Do we have to use .hbs files always or do we have the option to put in vanillas ts and js files if we do not want variable-interpolation?

In this example here, they show how they use a .txt file as a template file. Therefore I assume other files should work as well!
https://github.com/plopjs/plop#using-a-dynamic-actions-array

My experiences with working with Plop

Even if the file is not a .hbs files handlebars will still parse it. This means that any Vue components that use {{ SOME_THING }} will need to be modified to the following:

{{{{raw}}}}
  <a>{{ statusCheck.nuxtAppVersion.toString() }}</a>
{{{{/raw}}}}

This escapes the handlebar rendering. https://handlebarsjs.com/guide/expressions.html#whitespace-control

Plop

After working with plop to bring a V1 out I can document the following experiences I had:

the default plop package, requires that we build our cli on top of their cli. Meaning that in the end we run a script on top of the plop script and just pass our plopfile.js to it. See branch https://github.com/sidebase/create-nuxt3-app/tree/add-plop-cli for current implementation. This limits us in the following ways:

Our design will always look like the plop CLI
If we ever need to add custom features, we will be limited in that sense
compiling to TS is really hard and trying to combine it into our cli is pretty exhausting (if we ever want to add more features)

What I do like about it:

It lets us define multiple generators, allowing us to later on add features such as a component generator (where component file, story and test are pre-generated to allow for a quicker workflow).
Adding new templates is not that hard

Plop has an extra package called plop-node, which is just the core functions from plop. It is without built in prompts, but therefore allows to be complied and run independently. node-plop takes a plopfile and then runs it. However you need to pass all the options to it, for it to do it correctly. I tried working with this, however there is very little documentation on how to use it correctly, especially with typescript, which has slowed down my progress. See https://github.com/sidebase/create-nuxt3-app/tree/add-cli-v1 for current implementation. And see https://github.com/plopjs/plop/tree/main/packages/node-plop for entire existing documentation on it.
The main issue I am currently facing with this implementation is how to do the file linking correctly. In order for the project to work correctly I almost need two project in one.

The CLI we build where users get prompted
The generator files and plopfile

I currently have these two seperated into the src folder (which is also compiled from ts) and the generators folder (which stays in JS). There is also the templates folder which, contains all the template files to copy over later.
Within the src/index.ts I call the node-plop function to get the plopfile and generator.
const plop = await nodePlop(`./plopfile.js`);

Which already brings me to problem one. How do I correctly link this file? As it takes in a string I am not sure how it will behave once complied etc.
Does it make sense to make two separate packages? One being the cli and the other being the generators? Then we can just import the plopfile from the other package?
The next issue I run into is the differences between commonjs and modules.
I found while running the node-plop package that I needed to add type="module" to the package.json for the project to compile correctly. However, The generator files need to export a module (https://github.com/sidebase/create-nuxt3-app/blob/add-cli-v1/packages/create-nuxt3-app/generators/sidebase.js#L1). In all the examples the generators are then imported via const generator = require('generator.js'), which throws me new errors then!
In the current implementation I get the following error when running:
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/zoey/Documents/Development/SideStream/sidebase/create-nuxt3-app/packages/create-nuxt3-app/generators/sidebase' imported from /Users/zoey/Documents/Development/SideStream/sidebase/create-nuxt3-app/packages/create-nuxt3-app/plopfile.js

SAO

Due to the fact I was struggling with these two options, I also had a look at SAO again. The most attractive part of SAO is not the package itself, but that fact that there is create-nuxt-app which uses SAO and we can use their CLI as a base on which we build ours. https://github.com/nuxt/create-nuxt-app/tree/master/packages/create-nuxt-app
This will make development a lot quicker and easier, as we won't have to reinvent the wheel. However as we mentioned above we would prefer to use plop over SAO, which I why I suggest I continue looking into it for a while.


Fix renovate config for grpc_health_probe

In #30643 we noticed that we forgot to add a file match so renovate did not update the dependency. This PR should fix that and renovate should start updating the dependency automatically.
Please ensure your pull request adheres to the following guidelines:

[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin

/test


SecurityError when storage is disabled (again)

Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
This was previously fixed in https://github.com/dfahlander/Dexie.js/issues/158 (v1.3.4)
But I am getting this error again (on Chrome 62 when disabling cookies in privacy settings).
Seems like this commit removed the try&catch when attempting to access localStorage.
Can be easily reproduced with latest Chrome (62) + fiddle  + disabling cookies.
(Using latest Dexie release 2.0.1)

Dexie has removed it's dependency of localStorage so it can't be Dexie that complains.

I ran the fiddle with cookies disabled and it seems Google Analytics code on jsfiddle was the first issue, and then some other libs that was complaining too.

Maybe fiddle wasn't the best idea for testing this since there are additional errors like you noticed.
However, I clearly see the error from Dexie aswell...
Developer tools image:

This is the line in the code where checks localStorage and causes the error: https://github.com/dfahlander/Dexie.js/blob/ffa52d1ad5b39b8316760a50459d4779a6171862/src/Dexie.js#L3187

I see! Forgot about that one ;)

@dfahlander Can this issue get some love with a fix even on the 2.x branch. The Wire app just shows a blank page because of it instead of our cookie warning page. It would be great to get this fixed in order to help our users and decrease the volume of related request to our CS team.

+1
I would also love to see this fixed in 2.x.

Thanks for fixing this. Will get this fixed in https//github.com/wireapp/wire-webapp in the morning.


SettingsInProgress Error

@nzapponi wanted to get your opinion on this before I implement anything. I have been occasionally having this error lately, basically I have an automation to arm the alarm automatically when everyone leaves and it will sometimes silently fail and added some debugging and got back to the error below. I think this may be happening because I decreased the sensor refresh time to 8 seconds (which helps a lot with other sensor-based automations so I would like to keep) so my assumption is that a sensor refresh request is clashing with the setTargetState in alarm.js call (so presumably this could happen to others too but with a refresh time like 15s its just less likely). So I am tempted to add an extra if block in the catch of setTargetState and if its a SettingsInProgress error, call setTargetState again. Of course that would potentially create an infinite loop so I was also thinking to add a simple (non-configurable) property like maxRetries or something and just use that as a simple counter so as to only re-try maybe 5 times or something.
Sound reasonable? Any concerns? I'll submit a PR if all good.
Error while setting alarm state: {
  type: 'SettingsInProgress',
  message: 'The Settings Requested are already being modified and cannot be accessed at this time',
  code: '200',
  statusCode: 409,
  props: {}
}

I created a PR which seems to work. I discovered I can reproduce the issue easily by rapidly repeatedly toggling a dummy switch I have which is used as an automation trigger to set the alarm, in other words repeatedly set the alarm state. In the real-world situations Im having I still think it might be from sensor refresh but in general seems like could be useful to have some kind of 'protection' against this bug. Cant really think of any potential negative unintended consequences, welcome your thoughts obv.

Awesome! I was wondering why it would sometimes fail silently, thanks for figuring it out!

I've been getting a lot of these after updating to the most recent version. See log below. There were many above and below this chunk.
[2/18/2022, 11:16:13 PM] [Simplisafe Alarm] Sensor refresh received an error from the SimpliSafe API: {
  type: 'SettingsInProgress',
  message: 'The Settings Requested are already being modified and cannot be accessed at this time',
  code: '200',
  statusCode: 409,
  props: {}
}
[2/19/2022, 12:40:30 AM] [Simplisafe Alarm] SimpliSafe credentials refresh was successful
[2/19/2022, 12:40:30 AM] [Simplisafe Alarm] Credentials refreshed successfully after failed request
[2/19/2022, 12:40:30 AM] [Simplisafe Alarm] SimpliSafe credentials refresh was successful
[2/19/2022, 12:40:30 AM] [Simplisafe Alarm] Credentials refreshed successfully after failed request
[2/19/2022, 12:40:43 AM] [Simplisafe Alarm] Sensor refresh received an error from the SimpliSafe API: {
  type: 'SettingsInProgress',
  message: 'The Settings Requested are already being modified and cannot be accessed at this time',
  code: '200',
  statusCode: 409,
  props: {}
}
[2/19/2022, 12:40:43 AM] [Simplisafe Alarm] SSAPI socket disconnect reason: transport close
[2/19/2022, 12:40:43 AM] [Simplisafe Alarm] SimpliSafe real time events disconnected.
[2/19/2022, 12:40:45 AM] [Simplisafe Alarm] SSAPI socket reconnect_attempt #1
[2/19/2022, 12:40:45 AM] [Simplisafe Alarm] SSAPI socket reconnected
[2/19/2022, 12:40:45 AM] [Simplisafe Alarm] SSAPI socket error: Not authorized
[2/19/2022, 12:40:45 AM] [Simplisafe Alarm] SimpliSafe real time events connection lost.   Next attempt will be in 1s.
[2/19/2022, 3:01:08 AM] [Simplisafe Alarm] SSAPI socket error: Not authorized
[2/19/2022, 3:01:08 AM] [Simplisafe Alarm] SimpliSafe real time events connection lost. Next attempt will be in 2s.
[2/19/2022, 3:01:10 AM] [Simplisafe Alarm] SSAPI socket error: Not authorized
[2/19/2022, 3:01:10 AM] [Simplisafe Alarm] SimpliSafe real time events connection lost. Next attempt will be in 4s.
[2/19/2022, 3:01:15 AM] [Simplisafe Alarm] SSAPI socket error: Not authorized
[2/19/2022, 3:01:15 AM] [Simplisafe Alarm] SimpliSafe real time events connection lost. Next attempt will be in 8s.
[2/19/2022, 3:01:24 AM] [Simplisafe Alarm] SSAPI socket error: Not authorized
[2/19/2022, 3:01:24 AM] [Simplisafe Alarm] SimpliSafe real time events connection lost. Next attempt will be in 16s.
[2/19/2022, 3:01:41 AM] [Simplisafe Alarm] SSAPI socket error: Not authorized
[2/19/2022, 3:01:41 AM] [Simplisafe Alarm] SimpliSafe real time events connection lost. Next attempt will be in 32s.
[2/19/2022, 4:02:06 AM] [Simplisafe Alarm] SSAPI socket error: Not authorized
[2/19/2022, 4:02:06 AM] [Simplisafe Alarm] SimpliSafe real time events connection lost.  Next attempt will be in 128s.
[2/19/2022, 6:04:03 AM] [Simplisafe Alarm] SSAPI request failed, request blocked (rate limit?).
[2/19/2022, 6:30:06 AM] [Simplisafe Alarm] SSAPI socket error: Not authorized
[2/19/2022, 6:30:06 AM] [Simplisafe Alarm] SimpliSafe real time events connection lost. Next attempt will be in 256s.
[2/19/2022, 6:30:10 AM] [Simplisafe Alarm] SimpliSafe credentials refresh was successful
[2/19/2022, 6:30:10 AM] [Simplisafe Alarm] Credentials refreshed successfully after failed request
[2/19/2022, 6:34:23 AM] [Simplisafe Alarm] Now listening for real time SimpliSafe events.
[2/19/2022, 6:35:43 AM] [Simplisafe Alarm] Sensor refresh received an error from the SimpliSafe API: {
  type: 'SettingsInProgress',
  message: 'The Settings Requested are already being modified and cannot be accessed at this time',
  code: '200',
  statusCode: 409,
  props: {}
}
[2/19/2022, 6:49:18 AM] [Simplisafe Alarm] Sensor refresh received an error from the SimpliSafe API: {
  type: 'SettingsInProgress',
  message: 'The Settings Requested are already being modified and cannot be accessed at this time',
  code: '200',
  statusCode: 409,
  props: {}
}

Newest version doesnt change anything about the cause of those errors, they come from pinging the API (base station) every X seconds. We cant do much about them. If you dont like the logs you can turn off debug. The other stuff in your logs indicates a lot of connectivity issues for you today, again not really under control of this plugin. It does look like the plugin is successfully reconnecting, so thats nice =)

Thanks. Yeah, if this is just debug info and not a sign of a problem (i.e. working as intended), then that's fine. I just wanted to make sure this doesn't mean something is wrong.  My sensor refresh interval is 15, which I think is the default. (I don't remember changing it.) I assume that's in seconds?


Allow writefln like ouput during CTFE.

davidl reported this on 2008-03-14T06:45:55Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=1924
CC List

bugzilla (@WalterBright)
razvan.nitu1305
shro8822
smjg

Description
char[] wrongfunc()
{
    char[] result;
    pragma(msg, result);       // fail at this line
    return result;
}
mixin(wrongfunc);

smjg commented on 2008-11-26T11:13:18Z
From the names pragma(msg) and pragma(writefln), it isn't clear at all that one's while compiling and one's while evaluating.

Better would be to name it something like "ctfeMsg" or "msgCTFE".  And perhaps writefln notation could be supported in both this and regular msg.  This won't break existing code as long as pragma(msg, string) with no further arguments is still defined to write that exact string.

clugdbug commented on 2008-11-26T08:35:34Z
Although a way of debugging CTFE functions would be very nice to have, this is definitely not a bug.

I'm changing this to an enhancement, changed title from: fail to pragma compile time constant

fvbommel commented on 2008-03-14T09:44:16Z
Your 'result' is a variable that happens not to get assigned at runtime, but the fact that it happens not to change doesn't mean it's a constant.

P.S. According to the spec it even needs to be a string literal (which I don't think is what the compiler implements, since I'm pretty sure it allows string constants constructed by templates and ctfe). But either way your code is clearly illegal.

smjg commented on 2008-11-26T08:52:17Z
I think we need separate notation for this.  Generating a compiler message while compiling a function is conceptually different from generating a compiler message while evaluating it.

shro8822 commented on 2008-11-26T10:32:42Z

pragma(writefln,"hello #%d", 1);
vote++;

davidl commented on 2008-03-15T00:23:07Z
char[] wrongfunc()
{
    char[] result="void main()";
    result ~= "{}";
    const char[] myresult= result;
    pragma(msg, myresult);       // fail at this line
    return result;
}
mixin(wrongfunc);

abc.d(6): Error: string expected for message, not 'result'

pragma here is clearly for debugging CTFE. I don't want to make it as the following

char[] getresult()
{
    char[] result="void main()";
    result ~= "{}";
    return result;
}
char[] myfunc()
{
    const char[] result = getresult();
    pragma(msg,result);
    return result;
}
mixin(myfunc);

it's way dummier for debugging CTFE, especially if i want to do only some simple inspect on some particular vars.

clugdbug commented on 2008-11-27T03:57:58Z
On second thoughts, this isn't an actual proposal. There's a genuine need, but  pragma(msg) inside CTFE is not the solution. I think we should just kill this bug, and create a new one when there's an actual proposal for how it should work.

shro8822 commented on 2008-11-26T12:43:43Z

Sorry, I was far less than clear.

writefln in all cases we use it in now executes with the code path, e.g. when the code is executed rather than generated. pragma is compile time in all cases. Seems like a good fit to me.

OTOH as long as it's not something like pragma(D9B01F73-E64A-4FA9-A2DE-C20CD24560BA) I'm not going to object to getting it!

shro8822 commented on 2008-11-27T11:11:38Z
Vote++ or rename and re-tag it.

shro8822 commented on 2008-11-26T11:17:58Z
To date, every use of writefln I've seen has been run time. So it doesn't seem particularly ambiguous at least to me,

smjg commented on 2008-11-26T12:05:59Z
(In reply to comment #7)
> To date, every use of writefln I've seen has been run time. So it doesn't seem
> particularly ambiguous at least to me,

That's because at the moment writefln can only be executed at run time.  If it (or something resembling it) becomes executable at compile time, it could just as well be either as and when compiled or during CTFE.

Having a difference between pragma(msg) and pragma(writefln) beyond what they say on the tin would be arbitrary and confusing.

razvan.nitu1305 commented on 2019-10-26T06:50:56Z
This bug report is invalid. The original reported issue is invalid since pragma cannot evaluate at compile time the value of a runtime variable.

As for the other proposed issue - the ability to print when a function is evaluated - it doesn't have to be implemented in the compiler. This can be implemented as a function in phobos.

Changing component from dmd to phobos.

Test case:

import std.stdio;

char[] wrongfunc()
{
    char[] result;
    writeln(result);
    return result;
}

void main()
{
    enum c = wrongfunc();
}

we have __ctfeWrite
also we have the -mixin=<filename> option to expand and save mixins to file specified by <filename>
Closing this


MvcUserMeta not working

The MvcUserMeta class is not loaded by the MvcLoader (see mvc_loader.php line 68).
Also, mvc_user_meta.php sets the primary key to meta_id, but it is in fact umeta_id (see https://codex.wordpress.org/Database_Description).

Thanks, would welcome a pull request. :)


Cannot specify timings in .cargo/config

Problem
Cannot specify timings option in .cargo/config
Steps

Add these to .cargo/config:[build]
timings = ['html']

Shows warning: warning: unused config key build.timings, and timings not activated.

Possible Solution(s)
Parse build.timings in .cargo/config since timings is removed from unstable in nightly cargo.
Notes
No response
Version
cargo 1.61.0-nightly (109bfbd 2022-03-17)
release: 1.61.0-nightly
commit-hash: 109bfbd055325ef87a6e7f63d67da7e838f8300b
commit-date: 2022-03-17
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1m)
os: Debian unstable (sid) [64-bit]

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"hi-rustin"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->

@weihanglo @ehuss Is this acceptable? I think I can help to add it.

Seems like a reasonable addition to me.  Roughly the things that need to be done to add this are:

Add to CargoBuildConfig
Check the value around here. I'm not sure if it should take the union of options of the config + cli, or if the CLI should override the config. Needs some thought, but since there is only 1 stable option, probably isn't too critical right now.
Add a test in the timings module.
Update the config documentation.
Update the environment variables documentation.
Add a mention of the config setting in the timings documentation.
Add a mention of the config setting in the --timings docs. See --jobs as an example of how this is done. Then rebuild the man pages.

@rustbot claim

@jerryc05 could you expand on why you are interested in this being in the config?  This seems like a transient option for me and the use case for making it more permanent in a file seems unclear.

@jerryc05 Friendly ping~
Could you share your use cases?

@epage Maybe we can close this issue now? I think there are no reasonable use cases for this config. Because it's a debugging config, we can always pass it.

I'm not quite seeing why this would be put in a starter template as it seems like you wouldn't want timings on every run but only when specifically wanting to measure a build.
If someone does come up with a reason for wanting timings on every run, we can reconsider this.  For now, I'm going to close this though as there doesn't seem to be sufficient motivation provided.


Want to write this in pure Go

This isn't really an issue, but I'm just reaching out because I want to write the LZHAM compression algorithm in pure Go and I am struggling a bit, so I was asking if you would be interested in working on this. You can check what I've done so far here (not a lot as of rn) https://github.com/amaanq/lzham-go
Cheers,
Amaan

I don't currently have time to contribute, but I am definitely interested in the result if/when you finish this.


add folia support please

Can you expand? What does this mean?
If Folia is a plugin, please provide a link t

Folia is work-in-progress server software from the folks at PaperMC which adds multithreading, with the tradeoff being plugins using the Bukkit scheduler need to be updated for compatibility. This entails adding a flag to plugin.yml and using a library like FoliaLib for scheduled tasks (without it, you'd have to make a separate release just for Folia servers).
Considering the software is 1.19-1.20.4 atm and isn't particularly useful to anyone without a large player base (as in hundreds of players), I don't see much point in adding support. Should be pretty straightforward if that changes, though.


{Doc} change title to alert how to pass array parameters

Description
Fix https://github.com/Azure/azure-cli/issues/10731
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

Doc

add to S170


Clarify RBAC is only available for Event Grid topic subscription operations

The documentation is a bit confusing and it would be good to clarify that RBAC is not supported for other than subscription operations in other than the paragraph below. It is in a place where already reading authentication and the rest of authorization documents is not quite clear. Thank you!
Built-in roles
Event Grid provides two built-in roles for managing event subscriptions. They're important when implementing event domains because they give users the permissions they need to subscribe to topics in your event domain. These roles are focused on event subscriptions and don't grant access for actions such as creating topics.

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

ID: 1dbe461e-bf0e-765b-947a-fbc80b4c72b7
Version Independent ID: 657e2535-3c8b-4875-00fc-8cadfc678adc
Content: Azure Event Grid security and authentication - Azure Event Grid
Content Source: articles/event-grid/security-authorization.md
Service: event-grid
GitHub Login: @spelluru
Microsoft Alias: spelluru

Or, specifically, that one cannot use RBAC to publish to an event grid topic. After reading through the docs I thought that I could use the "EventGrid EventSubscription Contributor" to publish messages to an event grid topic and "EventGrid EventSubscription Reader" to read off an event grid subscription. But that does not seem to be the case.

@MikePennington, Thank you for your feedback! We will review and update as appropriate.

@gmndrg Can you please point the exact line in the document: https://docs.microsoft.com/en-us/azure/event-grid/security-authorization where you feel the inconsistency
It is in a place where already reading authentication and the rest of authorization documents is not quite clear.
@MikePennington The documents mention this is only for the management operation. To publish the events you can refer to https://docs.microsoft.com/en-us/azure/event-grid/security-authenticate-publishing-clients
Azure Event Grid allows you to control the level of access given to different users to do various management operations such as list event subscriptions, create new ones, and generate keys. Event Grid uses Azure's role-based access control (RBAC).

I would add one additional sentence as follows:
Event Grid does not support RBAC for publish/subscribe operations. For these operations you must use an access key or SAS token. See https://docs.microsoft.com/en-us/azure/event-grid/security-authenticate-publishing-clients.

@MikePennington I am assigning this to the author to review it.
@gmndrg Can you please review if this needs to be updated.

Hi Mayank,
I requested this change on behalf of Mike Pennington. The document needs clarification as per the original request and Mike has pointed what would have make it clearer.. I am not the document author but the requestor of the change.
Please assign to any of the document collaborator editors for review.
Thank you,
Gia
Get Outlook for Androidhttps://aka.ms/ghei36

From: MayankBargali-MSFT<EMAIL_ADDRESS>Sent: Wednesday, July 15, 2020 5:09:42 AM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Giannina Mondragon<EMAIL_ADDRESS>Assign<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Clarify RBAC is only available for Event Grid topic subscription operations (#58908)
Assigned #58908https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F58908&data=02|01|Giannina.Mondragon%40microsoft.com|9d8d6dc1d1b845a6492d08d828af935a|72f988bf86f141af91ab2d7cd011db47|1|0|637304081840247184&sdata=H5K4Kub30d6%2Bq9N5TctKPm3NqLkayhH4mc2YaUoHuUU%3D&reserved=0 to @gmndrghttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgmndrg&data=02|01|Giannina.Mondragon%40microsoft.com|9d8d6dc1d1b845a6492d08d828af935a|72f988bf86f141af91ab2d7cd011db47|1|0|637304081840257179&sdata=XKCfkCAL%2FtZXuNW12z6mmFL862w2%2Fia3IDir7MgWRdc%3D&reserved=0.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F58908%23event-3548067947&data=02|01|Giannina.Mondragon%40microsoft.com|9d8d6dc1d1b845a6492d08d828af935a|72f988bf86f141af91ab2d7cd011db47|1|0|637304081840267176&sdata=5ZhtIz2T5kF5rt68nYBOV1gBl4ecFHd5WErONHCnZYw%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALBWI77YOM4727ZAFGTLR2LR3WE7NANCNFSM4OYTRIIA&data=02|01|Giannina.Mondragon%40microsoft.com|9d8d6dc1d1b845a6492d08d828af935a|72f988bf86f141af91ab2d7cd011db47|1|0|637304081840267176&sdata=H%2BdVmZJpp8MJJdFhvwzbw6urhLqYzEcqAEHhD6wQfl0%3D&reserved=0.

After discussing with the product team, I have added the following note at the top:
Note
EventGrid doesn't support Azure RBAC for publishing events to Event Grid topics or domains. Use a Shared Access Signature (SAS) key or token to authenticate clients that publish events. For more information, see Authenticate publishing clients.

#please-close


Code examples demonstrating the connection options

Minor nit but can the directory be renamed to connecting? I'd like to avoid any potential confusion with Kafka Connect.

Makes sense, haven't even thought about Kafka connect. Addresses both feedbacks 👍


Wheel and sdist names are not normalized according to current standards

For example, Test-Project generates the following artifacts:

Test-Project-1.tar.gz
Test_Project-1-py2.py3-none-any.whl

However, according to the current standards these should be:

test_project-1.tar.gz
test_project-1-py2.py3-none-any.whl

Specifications:

https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-file-name
https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-name-convention

Thank you! From a quick glance, the results look correct.


Transpiler eliminates classical condition for optimization_level 3

Information

Qiskit Terra version:
0.17.0.dev0+83eb665
Python version:
3.9.1 (default, Dec 11 2020, 06:28:49) [Clang 10.0.0 ]
Operating system:
Darwin

What is the current behavior?
Circuits with feed-forward logic are incorrectly transpiled for optimization levels >0
Steps to reproduce the problem
from qiskit import execute, QuantumCircuit, QuantumRegister, ClassicalRegister
from qiskit import transpile
from qiskit.transpiler import CouplingMap
from qiskit.converters import dag_to_circuit
circ = QuantumCircuit()
registers = [
            QuantumRegister(1,name='qr_data'),
            QuantumRegister(1,name='qr_anci'),
            ClassicalRegister(1,name='cr_data'),
            ClassicalRegister(1,name='cr_anci'),
            ]
for regs in registers:
    circ.add_register(regs)
circ.h(0)
circ.cx(0,1)
circ.measure(1,1)
circ.h(0).c_if(registers[3],1)
# make coupling maps
CMap = CouplingMap().from_ring(12)
CMap.add_physical_qubit(12)
CMap.add_edge(11,12)
CMap.add_edge(12,5)
CMap.make_symmetric()

def callback(**kwargs):
    print(kwargs['pass_'])
    print(dag_to_circuit(kwargs['dag']))

transpile_opts       =  {
                        'optimization_level': 3,
                        'callback': callback,
                        'coupling_map': CMap,
                        'basis_gates': ['cx', 'id', 'u1', 'u2', 'u3']
                        }
circ_transpiled = transpile(circ,**transpile_opts)
circ_transpiled.draw()

What is the expected behavior?
The condition on the last h gate is preserved when transpiler optimization level 3 is run. Looking through the output of the callback function it is dropped by the consolidate blocks pass
Suggested solutions
Examine consolidate blocks section of transpiler (identified by @mtreinish )

From a quick look through the transpiler the consolidate blocks pass is eliminating the condition on the gate in that circuit. This will only be an issue with optimization level 3 (or if you use the synthesis translation method) since we only run consolidate blocks by default in the optimization level 3 pass manager. (I've updated the title and issue to reflect this)

I looked into this briefly and I'm fairly sure this isn't a ConsolidateBlocks/Collect2qBlocks issue (even though those are the passes where the issue becomes apparent). Looking into the PropertySet in between Collect2qBlocks and ConsolidateBlocks, the conditional gate (correctly) isn't being collected into a block by Collect2qBlocks, and then is (correctly) being re-inserted in to the DAG in place by ConsolidateBlocks.
However, when re-inserting DAGNodes that weren't collected into a block, ConsolidateBlocks calls dag.apply_operation_back which looks at node.op.condition to know if the instruction to be inserted should be classically conditioned. At this point, for the conditional U2Gate, node.condition is (ClassicalRegister(1, 'cr_anci'), 1) but node.op.condition is None. Likely one of the previous passes (probably the BasisTranslator via DAGCircuit.substitute_node) incorrectly replaced the instruction without carrying over the conditional information.
Steps to remediate:

Confirm that updating DAGNode.op.condition prior to ConsolidateBlocks resolves this bug.
DAGNode.condition should be either removed, or made a simple @property fetching op.condition. (The deprecated condition kwarg on DAGNode.__init__ can be removed as well).
DAGCircuit.substitute_node should be updated to propagate the condition attribute from the to-be-replaced op to the new op. This may also be a good time to examine if substitute_node is still needed or should be removed, given that it has proven difficult to use as compared to substitute_node_with_dag ( see discussion in #5002, #5225, and https://github.com/Qiskit/qiskit-terra/pull/4915#discussion_r481152756 ) and the performance benefits it brings may no longer be meaningful for retworkx.

@kdk. I did a quick dive into this and I think there is more to it. It's true that substitute_node should be propagating the condition to the new node, but just doing that does not solve it.
The problem is in BasisTranslator and if you force set the condition in there, then both of the u2 gates get the same condition. In the above circuit, in this code,
https://github.com/Qiskit/qiskit-terra/blob/f3e2b7a5fdd6789f7b3ce8bd15de28e5561d0378/qiskit/transpiler/passes/basis/basis_translator.py#L155-L159
the u2 loaded into dag_op is repeated with the same instance of the u2. Therefore you will either get both u2's with conditions or neither. A copy.copy when assigning dag_op along with adding the condition to dag_op solves the problem.
In regards to node.condition, I like your idea of doing an @property. There are about 20 references in the code to node.condition, though there might be many more with a name other than node. So eliminating node.condition could require a lot of code changes.
And though there might be other issues with substitute_node, I don't see a reason based on this example for removal.
If you'd like me to make the changes to load the condition in substitute_node and add the @property and copy.copy, I can do that.


webdropIn PayPal Button is shown with showPayButton : false configuration in since version 3.7.0

Describe the bug
We used version 3.6.3 and in configuration showPayButton : false, because we use our own button.
When we try to update to a version above 3.6.3 it shows always at the paypal payment the "PayPal" button and payment with our own button, results in js exception.
To Reproduce
Steps to reproduce the behavior:
Use Version webdrop above 3.6.3
set const configuration = {{
showPayButton:false,
Expected behavior
Hide the paypal button and process payment like in version 3.6.3
Desktop (please complete the following information):

OS: Windows 10
Browser chrome

Hi @AlexanderSeel, and thanks for reaching out.
The PayPal flow cannot be fire triggered by calling some method (as discussed in paypal/paypal-checkout-components#522) I'm not sure how useful it could be to hide the button completely.
This was working before because it was a completely different integration which relied in a redirection instead of opening the PayPal pop up.
Could you describe you use case? Would you use the PayPal component in some other part of the page?
Cheers!

Hi @AlexanderSeel,
We've added this in version 3.16.0. Please have in consideration what I mention in the message above.
Feel free to reach out if you have more questions or ideas, cheers!

Hi,
sorry for the late response.
We integrated the flow with redirect, so with our own button we trigger the payment in the web dropin, send the response to our backend call your c# lib method, take the response and give it back to the web drop in.
The question is: Is this still possible with paypal or not?
Kind regards


Fail on failures

This PR changes two instances where cargo-generate would "fail" but exit with code 0.

Looks good to me :+1:


Enhancement: Add context provider to table

Description

Relevant Technical Choices

Testing Instructions

Additional Information:

Screenshot/Screencast

Checklist

[ ] I have thoroughly tested this code to the best of my abilities.
[ ] I have reviewed the code myself before requesting a review.
[ ] This code is covered by unit tests to verify that it works as intended.
[ ] The QA of this PR is done by a member of the QA team (to be checked by QA).

Fixes #

Closing this because of the messy commit history after squash and merge.
#485 will take care of changes.


Why grouping errors prioritize stacktraces over exception interface?

I'm not sure how to classify my problem, whether it should be a  General Support or a Bug. Sorry about that.
Context
I have two different errors with exactly the same stacktrace, the same error type but a different error message.
Error 1: ValidationError: city location is invalid,
Error 2: ValidationError: user location is invalid
raven-js version: 3.24.1
Current behaviour
These two errors are grouped together by Sentry which effectively makes Error2 invisible at the first look.
Expected behaviour
Error1 and Error 2 should be a separate error entries.
I’ve read https://docs.sentry.io/learn/rollups/#grouping-by-stacktrace and it’s clearly stated that if stacktrace is available the grouping will be based on it.
I think it’s visible in source code here: https://github.com/getsentry/raven-js/blob/d3d6f989f1c2cd94fd4216e6a0a3d0deac7cb823/src/raven.js#L1787
Why is that? Shouldn't be exception interface (type, message) first thing to check to distinguish errors?

Why is that? Shouldn't be exception interface (type, message) first thing to check to distinguish errors?

Unfortunately, it leaves too much space for inconsistencies.
If you have an error message that's not pure (eg. using dates, server responses, some payload) it may lead to thousands of events flooding users events list and we'd be unable to group them in any way.

Is that better than having thousands of different events merged together without a possibility of unmerge?

It's not an accurate statement. You can see all events that were grouped together as a separate instance. Just click on the events number, eg. - https://sentry.io/kamil-ogorek/testing-project/issues/532218039/events/

In my opinion, most people use Error type and message in a way to distinguish error between each other

You're right, but imo it's a rare case to "abstract" the errors and have the same stack with various errors. There's, unfortunately, no easy way to cover all cases and we chose the one, that's helpful to majority of people in our experience.

Closing due to inactivity. Feel free to reopen if still relevant.


Remote server CN must be cached

In the current implementation EVERY time the app tries to make a remote connection, we actually establish it and analyze the server certificate.
This is plain wrong for the connections which are blocked.
Cache key: app name, remote endpoint address

/core/pull-requests/308


Bug in cluster-add-istio.sh

The script currently says
STATE=$(ibmcloud ks cluster-get $CLUSTER_NAME -s | awk '/State:/ {print $2}')
This has to be changed to
STATE=$(ibmcloud ks cluster-get $CLUSTER_NAME -s | awk '/^State:/ {print $2}')
(note the caret), to distinguish it from the "Master State:" line which now also appears in that output.

@keshlam Thanks Joe for pointing this out. I have fixed it.


Make sure gosmee restarts if it hits error

Fixes #211

Resurrected https://github.com/instructlab/instructlab-bot/pull/226 that got closed because i deleted my local instrctlab-bot fork.