Create QuillToolbarSelectHeaderStyleDropdownButton

Description
The alternative widget QuillToolbarSelectHeaderStyleDropdownButton for heading style is created. Also the list of available headings is expanded to H6. So the new widget supports headings H1..H6. Font sizes,line heights and spacing are updated from this link. Basically standard HTML values are used.
P.S. Also some translations (uk and ru) are updated.
Images

Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I titled the PR using Conventional Commits.
[x] I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
[ ] I have run the commands in ./scripts/before-push.sh and it all passed successfully

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
[x] No, this is not a breaking change.

Description
The alternative widget QuillToolbarSelectHeaderStyleDropdownButton for heading style is created. Also the list of available headings is expanded to H6. So the new widget supports headings H1..H6. Font sizes,line heights and spacing are updated from this link. Basically standard HTML values are used.
P.S. Also some translations (uk and ru) are updated.
Images

Checklist

[x]  I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ]  I titled the PR using Conventional Commits.
[x]  I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
[ ]  I have run the commands in ./scripts/before-push.sh and it all passed successfully

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ]  Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
[x]  No, this is not a breaking change.

Hi, I appreciate your efforts but we already did that in the dev branch, we will look into some solution don't worry we will try to merge your PR

Description
The alternative widget QuillToolbarSelectHeaderStyleDropdownButton for heading style is created. Also the list of available headings is expanded to H6. So the new widget supports headings H1..H6. Font sizes,line heights and spacing are updated from this link. Basically standard HTML values are used.
P.S. Also some translations (uk and ru) are updated.
Images

Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I titled the PR using Conventional Commits.
[x] I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
[ ] I have run the commands in ./scripts/before-push.sh and it all passed successfully

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
[x] No, this is not a breaking change.

Can you fix Ci failure by doing it aginst the latest master branch?

Besides the header styles for the new ones
We need to ask @singerdmx first because that's up this library is a port of react js so it needs to be the same otherwise quill delta will not work on quill js
And that's the whole idea behind the repo or the port

I tested this new class and it works. Qulll does not care on how many H is specified in configuration. Configuration is customizable.
Please look at this.

@freshtechtips  and @singerdmx I tested this new class and it works. See images. All headings are shown correctly. Qulll does not care on how many H is specified in configuration. Configuration is customizable.
Please look at this.

I'm not sure but I think you are right, but  can at least do it with the new class that was added before you sent this PR but to the dev branch, and now it's merged with the master

The example code which I've just took from this.
var toolbarOptions = [
  ['bold', 'italic', 'underline', 'strike'],        // toggled buttons
  ['blockquote', 'code-block'],

  [{ 'header': 1 }, { 'header': 2 }],               // custom button values
  [{ 'list': 'ordered'}, { 'list': 'bullet' }],
  [{ 'script': 'sub'}, { 'script': 'super' }],      // superscript/subscript
  [{ 'indent': '-1'}, { 'indent': '+1' }],          // outdent/indent
  [{ 'direction': 'rtl' }],                         // text direction

  [{ 'size': ['small', false, 'large', 'huge'] }],  // custom dropdown
  [{ 'header': [1, 2, 3, 4, 5, 6, false] }],  // <------------------------------ headers

  [{ 'color': [] }, { 'background': [] }],          // dropdown with defaults from theme
  [{ 'font': [] }],
  [{ 'align': [] }],

  ['clean']                                         // remove formatting button
];

var quill = new Quill('#editor', {
  modules: {
    toolbar: toolbarOptions
  },
  theme: 'snow'
});

The aim of Quill I think is to keep rich text which can be converted to HTML which in its turn supports H1...H6.

but can at least do it with the new class that was added before you sent this PR but to the dev branch, and now it's merged with the master

It seems I didn't catch what do you mean.

The example code which I've just took from this.
var toolbarOptions = [
  ['bold', 'italic', 'underline', 'strike'],        // toggled buttons
  ['blockquote', 'code-block'],

  [{ 'header': 1 }, { 'header': 2 }],               // custom button values
  [{ 'list': 'ordered'}, { 'list': 'bullet' }],
  [{ 'script': 'sub'}, { 'script': 'super' }],      // superscript/subscript
  [{ 'indent': '-1'}, { 'indent': '+1' }],          // outdent/indent
  [{ 'direction': 'rtl' }],                         // text direction

  [{ 'size': ['small', false, 'large', 'huge'] }],  // custom dropdown
  [{ 'header': [1, 2, 3, 4, 5, 6, false] }],  // <------------------------------ headers

  [{ 'color': [] }, { 'background': [] }],          // dropdown with defaults from theme
  [{ 'font': [] }],
  [{ 'align': [] }],

  ['clean']                                         // remove formatting button
];

var quill = new Quill('#editor', {
  modules: {
    toolbar: toolbarOptions
  },
  theme: 'snow'
});

The aim of Quill I think is to keep rich text which can be converted to HTML which in its turn supports H1...H6.

Sure but that's not the problem, the problem we already have restored the deleted button from the past in 2022, I restored it with fewer features, and yours contains more features, do you want to fix the conflicts or let me handle it?

the problem we already have restored the deleted button from the past in 2022, I restored it with fewer features, and yours contains more features, do you want to fix the conflicts or let me handle it?

I will appreciate you if you can do this. And I think I could not do it by myself because of Only those with [write access] to this repository can merge pull requests. Resolve conflicts button is disabled for me.

I think there are not many places of default package code which must be changed. The new widget and config are new files. It is required to update Attributes to add new ones from H4 to H6 and expand switch statements to handle new headers.

I think there are not many places of default package code which must be changed. The new widget and config are new files.
It is required to update Attributes to add new ones from H4 to H6 and expand switch statements to handle new headers. Also DefaultStyles are updated for H1...H6.

Do you want me to carry the changes to a separate PR or fetch and edit this PR? What do you prefer?

Do you want me to carry the changes to a separate PR or fetch and edit this PR? What do you prefer? if you want me to choose I would choose the first because of the too many conflicts
Please do as you feel comfortable.

Do you want me to carry the changes to a separate PR or fetch and edit this PR? What do you prefer? if you want me to choose I would choose the first because of the too many conflicts

Please do as you feel comfortable. The important thing is correct work of my app which already uses this new widget my own branch. :)

Just one thing, is the header styles always up to h6 from h1 or the developer can override it?

Did you face this bug?
https://github.com/singerdmx/flutter-quill/assets/73608287/330c66ab-2c2e-436d-bc4e-3d413ca50e38

This pull request has been moved to another, but it has a reference

Just one thing, is the header styles always up to h6 from h1 or the developer can override it?

It is fixed from H1 to H6 and then Normal. I thought it is logical. It is shown in the image I post in start topic.

Just one thing, is the header styles always up to h6 from h1 or the developer can override it?

It is fixed list from H1 to H6 and then Normal. I thought it is logical. It is shown in the image I post in start topic.

I add the ability to edit it

I add the ability to edit it

Why do think it is necessary? To place more large font somewhere in middle? Or do you mean moving only Normal options to top or bottom?

I add the ability to edit it

Why do think it is necessary? To place more large font somewhere in middle? Or do you mean moving only Normal options to top or bottom?

No, it's just one variable, which is a list that has default value, and you can change it back to previous value, it's necessary otherwise this can be considered as a breaking change

We already carried the changes of this PR, thank you


TRAN - Technical onboarding for 1st TRAN project - IoT

Describe the issue
Within the scope of understanding the kind of space that the project team needs, Jon needs to meet with them to get an idea.
Additional context

We are treating this as a "here's your space, you're on your own" level of service with the message that they will have to upgrade/migrate when they move to the SEA (which will come with more fullsome training as well as less responsibilities but more guardrails that they will need to have patterns to work with)

Definition of done

Stu [Now Julian] to ride along with Jon
Adjust expectations, training, expectation management, shared responsibility management, project management for the PO on the project (intended to be quick and lightweight)
Deploy environment into the hands of the project team

Priorities were set with the incoming TRAN projects and EDW is to be the first to be deployed.  Stuart advised TRAN on the schedule, with the EDW deploy pending and the IoT project being targeted as next priority for them

Deployment and transition tasks were completed for this TRAN IoT project.  A 'media' deployment issue associated with this IoT project has been identified and working with TRAN to resolve

iStore ticket issues to do with this project were identified with TRAN after being contacted by NCCS team.  TRAN is correcting issue post review and am waiting to verify they have the required VIP for the external public IP required (to route internally up to TRAN Azure resources using internal\private addressing).

Some additional issues that came up (see ticket #1290) were resolved, and some communication with TRAN happened so that they are more aware of what is normal learning debt around the advancement of cloud projects, and incorporating this into future planning.  This should help with easier on-boarding in the future, but should be reminded to them as future engagements happen

Closing ticket


fixes cache miss in abstract_eval_shape for bcoo dot general

This change fixes the cache miss issue when performing abstract_eval_shape for bcoo_dot_general. This was discussed in https://github.com/google/jax/discussions/15915#discussioncomment-10388492 .

Thanks! This issue also comes up in a number of other places in this file – would you like to fix those as well as part of this PR?

Regarding the CI failure: in test_bcoo_dynamic_slice we need to cast slice_sizes to a list. i.e. this: https://github.com/google/jax/blob/c33ce857847750b836b8c899c5d48c12b2842afc/tests/sparse_bcoo_bcsr_test.py#L1062
should be changed to this:
slice_sizes = rng.randint(0, shape, len(shape)).tolist()

Actually, strike that idea: what we need is to move this line to above the eval_shape call: https://github.com/google/jax/blob/c33ce857847750b836b8c899c5d48c12b2842afc/jax/experimental/sparse/bcoo.py#L2046

Actually, strike that idea: what we need is to move this line to above the eval_shape call:
https://github.com/google/jax/blob/c33ce857847750b836b8c899c5d48c12b2842afc/jax/experimental/sparse/bcoo.py#L2046

Will do! I missed some tests locally due to forgetting to install my local repo (d'oh). So will re-compile jaxlib+jax and run test suite.

You should be able to use the most recent jaxlib release along with a local install of jax via pip install -e .[cpu]

Hmm. When I do that, I'm unable to import anything from jax...
python -c "import jax; print(jax.__version__)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: module 'jax' has no attribute '__version__'

I'll see if I can pin down what is going on. Maybe mismatch in version between dev and non-dev?

Great! That seems to have fixed things on my end. I didn't see any failures in tests/sparse_bcoo_bcsr_test.py or tests/sparse_test.py

Thanks again for this! It was a tricky issue and this fix will make a lot of code more efficient.


Orientation lost after a couple of seconds fast movement.

Hi There, I'm having the issue that when I move my controllers a little bit fast (like in beatsaber) the orientation is completely lost.
I can reproduce this by just starting the PSMoveServic and the Controller config. When I go to test orientation at first it seems normal, when I move slowely it stays ok(ish) but when I move the controllers just a little bit faster the orientation is all messed up. (Pointing it physicaly forward shows on screen pointed to the right for instance)
Any idea what's going on or how to fix this?

I created a youtube clip. This is what I mean:
https://youtu.be/Bg0ufZeYCmc
All games (especialy beatsaber) are unplayable like this. Please help?! :-)

I created a youtube clip. This is what I mean:
https://youtu.be/Bg0ufZeYCmc
All games (especialy beatsaber) are unplayable like this. Please help?! :-)

This happens when only relative sensors are available in the controller, they will drift after some time.
The only PSmove controller that has "ok" absolute sensors is the PSmove controller Version 1 which uses a Magnetometer (a compass) to correct their drifting. New controllers don't have it so they drift after a while.
PSmove controllers in general don't like fast movements anyways and are not precise. For this you might get something less primitive, such as NoloVR with quicker response times.
Sadly you can't do anything about it, unless you get a earlier version of the controller. But then again, i don't think you could play BeatSaber with PSmove controller because they have slow reaction times.

Alternatively you can change the orientation filter to a less drifting filter or drift "fixer" filter.
Choose MadwickMARG orientation filter in the controller settings, seems to work better than ComplementaryMARG. At least in my testes.
Otherwise use ComplementaryOpticalARG which makes the controllers slowly orientate forward. But yea, pretty bad workarounds.


Amplify hosting doesn't appear to configure policies/origins correctly for some cases

Describe the bug
When deploying a react-static webpage with amplify, nested routes are not directly accessible (links work, but if I try to go to a nested resource directly, it doesn't work). This appears to be because CloudFront doesn't resolve index.html files in sub directories directly. The only resolution I have found so far is to make my S3 bucket public, and change the origin to the Endpoint specified in S3 (basically as described here: https://hackernoon.com/hosting-static-react-websites-on-aws-s3-cloudfront-with-ssl-924e5c134455)
To Reproduce
Steps to reproduce the behavior:

Create a dist directory with an index.html, a subdirectory (something), and something/index.html. Put distinctive values in each index.html ("Root", and "Something")
Use amplify to create a new hosting instance.
Once deployed, navigate to https://yourdomain.com/something. It should instead render the root page.

Expected behavior
The default S3/CloudFront configuration should support this standard static page setup. Ideally, if a policy can be found that still requires going through CloudFront (so we don't make the S3 bucket public), that would be ideal.
Desktop (please complete the following information):

OS: LInux (Manjaro)
Browser Firefox
Version 63

Additional context
As I understand, under the default configuration, CloudFront looks directly in S3 via API instead of website HTTP to find a file that exactly matches the request. If it doesn't find it, it uses the Default Root page, which will be the site index.html. S3, on the other hand, can look for index.html in the "directory" specified (yes, I understand S3 is just key/value, and doesn't actually have a concept of directories). The resolution described above appears to leverage this (by having CloudFront go to the http S3 endpoint directly, instead of presumably using S3 APIs...I'm guessing there, as that would explain why CF doesn't get the directory index page). This is conjecture on my part, but I think it explains what is happening. I only include it here in case this behavior with the default configs seems confusing.

@rfestag
Thanks for your feedback.
Currently the Amplify Cli's hosting category sets up the CloudFront to fetch from a private S3 hosting bucket, instead of using its public endpoint.
It's not the recommended practice to make S3 buckets public, though. We've updated the CLI so that even for the Dev setup, in which CloudFront is not used, the hosting bucket itself is still set as 'private' and only the contents in the bucket are set as 'public-read'.
I will mark this as feature request to keep track of it though.


jupyter notebook first version

issue #3
Code runs but I dont know if the numerical values are cofrrect

All the predicted parameters fall in range with the paper except for alpha which is around 0,5 in my runs and was 0.2 in paper. Although it was 0.5 in some of the simulated tests done in the paper. I wonder if this is an indication of a problem in my code


How to deploy your application using Hypernode Deploy v1 is outdated.

Article references all sort of examples and links that are outdated or no longer active.

Can confirm the following:
The link to the Docker hub  gets a 404.
The link to the Hypernode Deploy Github configuration starter template is inactive.


Add statement on various Teams clients' support for providing QoE data

Many of the specific dimensions and measure mention that they may be missing due to "Data was not reported". The best scenario as an improvement to this page would be if we could document specifically which QoE data is not expected to be reported by a given Teams client across desktop OSes, browser, iOS/Android phones, VDI, Teams phones, and 3rd-party phones.
Understanding that that is a tall ask, can we at least give a statement generally describing what kind of metrics we can expect across these clients? For example, web browsers cannot report on some OS-level metrics, and iOS/Android cannot report on wireless connection details.
Thanks!

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

ID: 1a455280-ea8e-2ddf-2965-60d9dcc0e21d
Version Independent ID: 7fb320d3-fa69-23fa-113c-53e9d2e11ada
Content: Dimensions and measurements - Call Quality Dashboard (CQD) - Microsoft Teams
Content Source: Teams/dimensions-and-measures-available-in-call-quality-dashboard.md
Service: msteams
GitHub Login: @SerdarSoysal
Microsoft Alias: serdars

Hi @dwhitney7, thank you for your feedback.
 If you have a Microsoft alias, you can link your accounts in GitHub so that a blue "Microsoft submitter" label appears to any PR's or issue you submit. Guidance on it here: https://docs.opensource.microsoft.com/tools/github/index.html
Here is the site you can use to see the mappings between GitHub and Microsoft aliases: https://repos.opensource.microsoft.com/people?q=dwhitney7
I don't have the information that you're requesting to add to the article. If you can kindly help me get that information, I can add it to the article, or you can do it by yourself by creating a Pull Request.
Please let me know how you want to proceed. Thanks!

@scanum Could you kindly close it? Thanks!


$type not included for the root object when TypeNameHandling is Auto

When I set Json.NET to serialize with TypeNameHandling set to TypeNameHandling.Auto, it correctly sets $type for child properties of an object but does not do so for the root object being serialized. Why?
Please consider the following repro:
public class Animal
{
    public Animal[] Offspring { get; set; }
}

public class Dog : Animal {}

Animal fido = new Dog
{
    Offspring = new Animal[] { new Dog() }
};

var json = JsonConvert.SerializeObject(fido,
    new JsonSerializerSettings
    {
        TypeNameHandling = TypeNameHandling.Auto
    });

The Json emitted into the json variable is:
{
    "Offspring": [{
        "$type": "MyApp.Dog, MyApp",
        "Offspring": null
    }]
}

The Json.NET Documentation says that for TypeNameHandling.Auto the behavior is:

Include the .NET type name when the type of the object being serialized is not the same as its declared type.

Should fido not have "$type": "MyApp.Dog, MyApp", like its puppy? :)

This is due to Json.NET not using a generic SerializeObject method thus the object your serializing is passed in as an object. You can however specify a type argument for the root type in one of the SerializeObject overloads which will achieve what you want.

Yup

Thanks. Would it make sense for me to try and submit a PR to make the behavior consistent with the documentation?
Alternatively, might the documentation be amended to specify this behavior more clearly?

I'm happy with the current behavior, I'd prefer to change the documentation to make it clearer how it works. Where is the documentation inconsistent?

Hi. I first have to say, thank you for Json.Net. It is awesome.
In the documentation for "TypeNameHandling Enumeration", the description for "Auto" says:

Include the .NET type name when the type of the object being serialized is not the same as its declared type.

In my example the object being serialized (fido, a Dog) is indeed not the same as its declared type (Animal) so my expectation is that the .NET type name would be included but it isn't.
Perhaps another sentence can be added saying "with the exception of the root object"?

Done https://github.com/JamesNK/Newtonsoft.Json/commit/f1587f073dcb06934738815429eb7d50fe80f50c

Thanks. Much appreciated :)


feat(oxc_parser): Port isStartOfDeclaration form tsc

What change is propsoed:
This PR ported the isStartOfDeclaration check to support better parsing of typescript's declarations.
Why the change is necessary:
This could open up opportunities to correctly handle modifiers (abstract, public, declare) of arbitrary order combined with arbitrary declaration items in typescript. For example abstract const a = 1 could be parsed by https://astexplorer.net/ and tsc would reject it at the semantic analysis stage, but not oxc currently can't handle this.
Another benefit is that now constructs likeabstract = 1 can also be correctly parsed by oxc.

Can you also fix cargo fmt?

Thank you!


Global prune 2

What are you trying to accomplish with this PR?
Add pruning by default to global deploy
How is this accomplished?
Fetch a list of global resources that are pruneable (everything that supports delete) exclude node and namespace since I can't image we'd actually want to ever prune these and then pass them as the list of resources to prune.
What could go wrong?
Worst case is that we are including something in the prune list we shouldn't

Worst case is that we are including something in the prune list we shouldn't

For sanity checking purposes, can you please post what this list actually is in the oldest and newest k8s versions we currently support?

We intentionally black list Node and Namespace. I can't really see a reason where pruning a Node is a good idea.  Pruning a Namespace is more reasonable but really dangerous.
1.11.0
/v1/PersistentVolumeClaim
/v1/PersistentVolume
admissionregistration.k8s.io/v1beta1/MutatingWebhookConfiguration
admissionregistration.k8s.io/v1beta1/ValidatingWebhookConfiguration
apiextensions.k8s.io/v1beta1/CustomResourceDefinition
apiregistration.k8s.io/v1beta1/APIService
certificates.k8s.io/v1beta1/CertificateSigningRequest
extensions/v1beta1/PodSecurityPolicy
policy/v1beta1/PodSecurityPolicy
rbac.authorization.k8s.io/v1beta1/ClusterRoleBinding
rbac.authorization.k8s.io/v1beta1/ClusterRole
scheduling.k8s.io/v1beta1/PriorityClass
storage.k8s.io/v1beta1/StorageClass
storage.k8s.io/v1beta1/VolumeAttachment
1.16.1
/v1/PersistentVolumeClaim
/v1/PersistentVolume
admissionregistration.k8s.io/v1beta1/MutatingWebhookConfiguration
admissionregistration.k8s.io/v1beta1/ValidatingWebhookConfiguration
apiextensions.k8s.io/v1beta1/CustomResourceDefinition
apiregistration.k8s.io/v1beta1/APIService
certificates.k8s.io/v1beta1/CertificateSigningRequest
node.k8s.io/v1beta1/RuntimeClass # not in 1.11
policy/v1beta1/PodSecurityPolicy
rbac.authorization.k8s.io/v1beta1/ClusterRoleBinding
rbac.authorization.k8s.io/v1beta1/ClusterRole
scheduling.k8s.io/v1beta1/PriorityClass
storage.k8s.io/v1beta1/CSIDriver # not in 1.11
storage.k8s.io/v1beta1/StorageClass
storage.k8s.io/v1beta1/VolumeAttachment


Compress space used by Metrics-Status

I think the metrics status is taking up too much space on the page.  We should show people more information for the screen real estate we are taking up. IMHO. Subject to discussion.

I've been toying with the idea of making the metrics-status page have tabs in the same way that the metrics do already. Or, having them be drop-down menus, or possibly have the results be filterable by varying fields. Either way, I definitely want to change the format - I'll get started on this as soon as I finish refactoring the endpoint.


Fix issue - shoulder buttons do not perform page up/down actions

Hi, I'm nismo from retropie forums (my nick was taken here).
There is a bug on Emulationstation that make L and R buttons to fast navigate in gamelist doesn't work.
Fieldofcows did a fix months ago and I tested without any issues.
Can you update the code to add it?
Here is the commit: https://github.com/fieldofcows/EmulationStation/commit/97f56a1c0c2e0ff70a2ca6cdaafc3b83af44e75f
Regards.

@Oberworld I think this can be closed as it's not been created properly :)

@Oberworld This is not the repo for EmulationStation for Retropie
Go here -> https://github.com/Retropie/EmulationStation
And close this PR. It has too many commits and this repo is not maintained


Error creating a new order

I disabled getalby extension and logged a user with a nsec, then when I try to create a new order I'm having this message in console asking for nip07 extension

Fixed in cd885baa118198fa907a0d6b0d67027f7d86e5eb


Digit Span tasks not working for available jsPsych versions

Hi, thanks for having these openly available! I realize both the forward and backwards digit span tasks were created for version 6.0.2, and I can't get them to run on the more recent versions. I am new to jsPsych, so I'm not sure where the compatibility issue comes from.

Hello! I've updated both the forward and backward digit spans to be
compatible with jspsych 6.3.0. However, please note that my github
repositories have a custom CSS file for making the number pad look more
aesthetically pleasing. This is found in the css folder on the
repositories. The script will still be able to run without this css file,
but the layout of the keypad will be different. Please let me know if you
have any additional questions. I'm happy to troubleshoot if you provide
more details on any encountered errors (e.g., by looking at the console log)
On Tue, Mar 8, 2022 at 2:43 PM Michelle Perdomo @.***>
wrote:

Hi, thanks for having these openly available! I realize both the forward
and backwards digit span tasks were created for version 6.0.2, and I can't
get them to run on the more recent versions. I am new to jsPsych, so I'm
not sure where the compatibility issue comes from.
—
Reply to this email directly, view it on GitHub
https://github.com/svanhedger/jspsych/issues/2, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEIH25MFAZ3RLH3YMEODX6DU66UURANCNFSM5QHJ32OQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Stephen Van Hedger, PhD
Assistant Professor
Department of Psychology
Huron University College
https://haplab.ca

Hi! Thank you so much for the update. I'm able to run the script locally on a computer, but I have tried the script in Cognition and Gorilla, and it's not working. As I'm trying to run the script, I get "The experiment failed to load" error. The culprit seems to be timeline.push(fds_adaptive).

Thanks for the additional information! The issue then is likely stemming from how the different experiment components are loaded onto those servers specifically.
I just tried playing around with cognition.run and was able to get the task working - I'll attach a screenshot of it, as well as attach an updated .txt file (which you can just paste into the 'Task Code' box). My solution was just to paste the fds_adaptive.js contents back into the script components of the index.html. Make sure you also upload the audio files, as well as the custom css file (as the screenshot shows). I'm reasonably confident that if you paste the attached .js file into Cognition, upload the digits under Stimuli, and upload the 'fds-adaptive.css' file as shown, everything should work!(url
fds_cognition.txt

)


ARP Table: hostname uses reverse DNS lookup as fallback

Arp table only relies on dhcp-leases entries to get the hostname. So when using an external DHCP server, or for IP addresses that are not assigned by DHCP, the displayed hostnames are always blank.
Features added:

if hostame is not found in the dhcp-leases, the hostname is fetched from a DNS PTR query, (using the system's DNS server).
use_dns variable can allow/disallow this behaviour (useful is someone would like to move this to a system preference)

HTH

A similar construction as used for the routes might be acceptable, putting the burden to resolve (with timeouts for everyone) isn't, so if you're up for it, please change the PR to include the option to the endpoint, either as uri part or as parameter (latter might make more sense at the moment).
For some inspiration, the following code blocks are being used in the route dialog.
https://github.com/opnsense/core/blob/745d46c4eeefb33566f5fe25024d6235846660fd/src/opnsense/mvc/app/views/OPNsense/Diagnostics/routes.volt#L62
https://github.com/opnsense/core/blob/745d46c4eeefb33566f5fe25024d6235846660fd/src/opnsense/mvc/app/controllers/OPNsense/Diagnostics/Api/InterfaceController.php#L137-L142
https://github.com/opnsense/core/blob/745d46c4eeefb33566f5fe25024d6235846660fd/src/opnsense/scripts/routes/show_routes.py#L42
ps:  removing the -n from arp would resolve in the same pass.

Hi thanks for the fast review!
You're perfectly right. I wrongly assumed that the ARP table should typically be only filled with LAN IP addresses where DNS timeout is usually not an issue for in-addr.arpa zones. But for cases where OPNsense is used mainly with  publically routables ip addresses, that obviously would create timeout issues.
Thanks for the inspiration examples (helps a LOT):  I'm gonna fix the PR to make DNS resolving optionnal, like in routes.

Here it is.
Notice that:

i used the -r as additional parameter, that triggers the Reverse DNS.
Without -r the commands behaves exactly as in the latest release.

I've added a natural sort of IP addresses (separate commit, to be easily reverted), as requested in #4185.
This is visible when using the command line:
configctl "interface list arp -r"
When using the GUI, and because Javascript sort the results, it might still be usefull, when for example sorting by Interface or Interface name.

HTH

@soif thanks, I've made some small cleanups in https://github.com/opnsense/core/commit/1548ae0eb79bde1f059f58c0a61658b5e33a0c9f before merging. The natural sort has been left out for now as it will likely lead to new tickets since it doesn't fix the complete issue.


Bug first release with --dryRun: CHANGELOG.md did not match any files

This issue still exists.  I just added the versioning to a new project in an existing workspace, and the first time I run the version, even with dry-run, it generates the error.  The CHANGELOG.md file does not exist in my project.
nx generate @jscutlery/semver:ng-add

>  NX  Generating @jscutlery/semver:ng-add

√ Would you want to enforce conventional commits? (Y/n) · true
√ Which preset would you want to use? · conventional
? Which projects would you want to version independently?
    UPDATE apps/timesheets/project.json
    UPDATE apps/timesheets-e2e/project.json
    UPDATE package.json

> ngcc --properties es2020 browser module main
> husky install

husky - Git hooks installed
up to date, audited 1861 packages in 6s

found 0 vulnerabilities

Then when I try to run the version with the short command line I get the error:
$ nx version --dry-run --project=timesheets

> nx run timesheets:version --dry-run=true

[timesheets] 🟠 No previous version tag found, fallback to version 0.0.0.
    New version will be calculated based on all changes since first co
    If your project is already versioned, please tag the latest releasts-x.y.z and run this command again.
[timesheets] 🆕 Calculated new version "0.1.0".

[timesheets] 📜 Generated CHANGELOG.md.
[timesheets] ❌ Error: fatal: pathspec 'apps\timesheets\CHANGELOG.md' did not match any files

at node_modules\@jscutlery\semver\src\executors\common\exec.js:10:34
   at ChildProcess.exithandler (node:child_process:395:5)
   at ChildProcess.emit (node:events:527:28)
   at maybeClose (node:internal/child_process:1090:16)
   at ChildProcess._handle.onexit (node:internal/child_process:302:5)

I am running this on GIT Bash on Windows.  If I create the CHANGELOG.md file, this works without error.
Originally posted by @Chowarmaan in https://github.com/jscutlery/semver/issues/458#issuecomment-1158932961

Possibly, but I have found using the GIT Bash shell, usually removes all the platform differences, for most every tool, but not all every time.  Is there something I can provide to help identify if it is something on Windows that can be addressed?

@Chowarmaan Ok I found the cause, it's when combining the first release and --dryRun option, it's not related to your operating system.

As a side note, it is not just dry-run mode though. It does error out when simply running without the CHANGELOG.md file.

I tested and if I don't pass the --dryRun option it does not output the error, so yeah to reproduce you have to pass this option and have no changelog.md file present.

The same error is happening here. Is there any indication of progress on this issue?

+1


Adopt phpdocumentor/typeresolver

https://github.com/phpDocumentor/TypeResolver (just released)
Might be useful and saves lots of code that can be maintained with a larger community.

I already use the TypeResolver, looks to me like it was only moved into a separate package

ah okay, I thought you implemented it yourself.


Upgrade chess and hats example to use ownership

opps meant to merge into feature/gamejam not master, will create another PR.


Json fields returning as string and not object

When using the neon adapter the Json fields are returning as strings and not as objects.

@taylormm Could you post some code that demonstrates the problem?
I just checked this and couldn't reproduce for either the http or WebSocket transports:
% deno repl

> let { neon, Pool } = await import('npm:@neondatabase/serverless')

> let sql = neon('postgresql://...')
> await sql`SELECT '{ "a": 12 }'::jsonb AS obj`
[ { obj: { a: 12 } } ]

> let pool = new Pool({ connectionString: 'postgresql://...' })
> await pool.query(`SELECT '{ "a": 12 }'::jsonb AS obj`)
Result {
  command: "SELECT",
  rowCount: 1,
  oid: null,
  rows: [ { obj: { a: 12 } } ],
  ...
}


Mec172x v2 headers 001

Depends on 36864.
This is the first commit of MEC172x header files located in the SoC layer. Headers are split between those common to all MEC family and MEC172x specific.

@scottwcpg  needs rebase


Add index

This PR implements issue #2556 (addSlide API).
And also, I found bug of removeSlide method around handling activeIndex with loop:true option.
The bug was also fixed by this PR.
Test is here: https://jsfiddle.net/kochizufan/aou1ajsq/

Looks good, thanks! 👍


code editor component

Clear and concise description of the problem
增加代码编写组件，语言包括但不限于javascript、sql、typescript、java...
Additional context
No response

领取一下


Mf/containers in simulator

This LGTM, @mforsyth were you planning to add anything else, otherwise, I'd like to merge this.

@wyegelwel Nope, if this looks good to you go ahead and merge!


Make first-time encounters easier for contributors

First time contributors of projects using commitlint run into our checks unprepared.
This increases friction at a point critical for every OSS project, up to the point where commit messages are lost:

https://github.com/remy/nodemon/pull/1110#issuecomment-334178055
https://github.com/GoogleCloudPlatform/cloud-trace-nodejs/pull/543
https://github.com/google/ts-style/pull/8
https://github.com/uPortal-Project/uportal-app-framework/issues/535

We should do more to make contributing as easy as possible when commitlint is used

@commitlint/template. Will prepend commit messages with example messages generated from our config. Idea snatched from https://github.com/remy/nodemon/pull/1110#issuecomment-334178055, example: lennym/commit-template. This introduces a second husky commit hook, increasing install complexity. Decide if commitlint init should set this when implemented: https://github.com/marionebl/commitlint/issues/48

commitlint restore: Let users restore commit messages that failed the tests for repeated edits. Theoretically we could even create

commitlintbot: Support commitlintbot to become the go-to tool for projects opting for linting on PR/Squashing level only. This approach moves the burden of commit conventions to project maintainers entirely.

An official GitHub integration (like commitlintbot) would be the most valuable IMO. :star:
Reading through CI logs to look for what when wrong in the commit format is not an optimal user experience.
commitlint restore and @commitlint/template both sound like nice improvements as well. :+1:

as mentioned at HH.js yesterday: one way could use a .git-commit-template.txt
Unfortunately I don't know a way to do it on repository level, so a user has to enable it manually

put the .git-commit-template.txt into the users home directory
or use git config (or git config --global) to specify a path

Here is a example for a .git-commit-template.txt: https://gist.github.com/Linell/bd8100c4e04348c7966d

:+1: for commitlintbot and squashing. The pull request level is the right place to deal with this. To me, it's the maintainer's job to groom the PR so that it fits in to the upstream repo.

Any news about commitlint restore? Is (how?) it possible to configure such a functionality at the moment?


No devices listed

When the plugin runs the discoverDevices() method. No devices get listed. Running the same exact command inside homebridge terminal, successfully logs my vacuum name.
This is all I as the plugin logs to homebridge
`
[8/22/2022, 11:10:53 AM] [WyzeRoboVac] Launched child bridge with PID 353787
[8/22/2022, 11:10:53 AM] Registering platform 'homebridge-wyze-robovac.WyzeRoboVac'
[8/22/2022, 11:10:53 AM] [WyzeRoboVac] Loaded homebridge-wyze-robovac v1.2.1 child bridge successfully
[8/22/2022, 11:10:54 AM] [WyzeRoboVac] discoverDevices(): username = 'xxxxxx', password = 'xxxx'
[8/22/2022, 11:10:54 AM] Homebridge v1.5.0 (HAP v0.10.2) (WyzeRoboVac) is running on port 45383.
`

Does your password have a space in it? Try changing it to an underscore.

My password does not have any spaces.
When I use the python scripts directly, it does work without a problem.

Is this still a problem for you?

Yes, no devices get listed

I can report the same issue.  I initially couldn't start the process (special characters in my email and password).  However single quotes seemed to solve this problem.   Code: 143, Signal: null [9/29/2022, 4:39:49 AM] [WyzeRoboVac] Restarting Process... [9/29/2022, 4:39:50 AM] [WyzeRoboVac] Launched child bridge with PID 14684 [9/29/2022, 4:39:50 AM] Registering platform 'homebridge-wyze-robovac.WyzeRoboVac' [9/29/2022, 4:39:50 AM] [WyzeRoboVac] Loaded homebridge-wyze-robovac v1.2.1 child bridge successfully [9/29/2022, 4:39:50 AM] Loaded 0 cached accessories from cachedAccessories.0E3311CA9D8B. [9/29/2022, 4:39:50 AM] Homebridge v1.5.0 (HAP v0.10.4) (WyzeRoboVac) is running on port 57104.

I am also not seeing any devices listed even after following the other recommendations here

After some debugging the issue was a space in the vacuum name on the wyze side and the py_helper called from this plugin not quoting the vacuum name. Calling the helper manually but quoting the name seemed to produce output from the script. Then removing the space from the vacuum name on the wyze side allowed everything to work as expected.

After some debugging the issue was a space in the vacuum name on the wyze side and the py_helper called from this plugin not quoting the vacuum name. Calling the helper manually but quoting the name seemed to produce output from the script. Then removing the space from the vacuum name on the wyze side allowed everything to work as expected.

The only log I see now is
[WyzeRoboVac] Initializing WyzeRoboVac platform...

I did noticed that when running the helper script getVacuumDeviceList.py, before getting the name of my vacuum, this was printed... Unknown device type detected , follow by device details about my wyze headphones.
I wonder if this is causing the problem.

having similar issues, running the python scripts from terminal lists device, but not showing under accessories.

Hey guys, I get this error, anyone know how to fix this? (Sorry i'm a newbie) : "Command failed: python3 /usr/lib/node_modules/homebridge-wyze-robovac/py_helpers/getVacuumDeviceList.py (here I have my username and password)
python3: can't open file '/usr/lib/node_modules/homebridge-wyze-robovac/py_helpers/getVacuumDeviceList.py': [Errno 2] No such file or directory

@pjrezai On what system are you installing the plugin? As I said in the README, this plugin is only supported on RPi Homebridge installations. See closed issues #3, #10, & #11. You need to search your system to discover where the py_helpers were installed and then update the config.json appropriately. Please report back here as to where you found the files to help others with the same problem. Thanks!

@pjrezai On what system are you installing the plugin? As I said in the README, this plugin is only supported on RPi Homebridge installations. See closed issues #3, #10, & #11. You need to search your system to discover where the py_helpers were installed and then update the config.json appropriately. Please report back here as to where you found the files to help others with the same problem. Thanks!

@RMCob Thanks for the response! I am using unraid docker. I fixed the the location of the py_helpers, and now this pops up: rror: Command failed: python3 /homebridge/node_modules/homebridge-wyze-robovac/py_helpers/getVacuumDeviceList.py (myusername) (mypassword)
Traceback (most recent call last):
File "/homebridge/node_modules/homebridge-wyze-robovac/py_helpers/getVacuumDeviceList.py", line 4, in
import wyze_sdk
ModuleNotFoundError: No module named 'wyze_sdk'

I am not sure if I need to install wyze_sdk? but I am not sure how to do that or have never used PYPI

@pjrezai See the Requirements section of the READ_ME for installation instructions for wyze_sdk.


Would love to see Windows 10 Universal App c# compatibility

Would love to see Windows 10 Universal App c# compatibility, current FirebaseSharp NuGet will not install because Microsoft.Net.Http targes Windows version 8.1
Also does this lib handle the new Firebase offline sync?
Thanks, love this lib.

I haven't really thought about Win10 at all - if you have a pull request please send it otherwise it will probably be a while.
Offline is not supported but there is a local cache that could be extended to support this.  I'll think about how.

Thanks for the update. Since Windows 10 is going to be released this July 29th I wanted to release an app for the launch using Firebase of course.

If you have the time doing a pull request of the changes would be the best way.
Please note that I'm in the middle of changing the API (in breaking ways) so you'll want to work with the latest code.

The code in master is starting to stabilize and an alpha was released - it is still a portable library but should be a good candidate for forking and getting to work with Win 10.


Improve webhooks

Attempt to increase parser speed avoiding manage some webhooks

Uhh, works? 😅

Sure I guess.


chore: release main

:robot: I have created a release beep boop
@openapi-generator-clients/types: 0.1.1
0.1.1 (2023-02-13)
Features

core: Support template level root dir. (9cab69a)
types: Add FileTemplateType, generator files types, extendable generator config props. (20e2a2d)
types: Add Generator / OAS / Workspace types. (939e073)
types: Add Template types. (0d082a8)
types: Scaffold types sub package. (5a571e1)
types: Use type string literal for file template type (aa64115)

Bug Fixes

types: Update entrypoints. (c4cc920)

@openapi-generator-clients/utils: 0.1.1
0.1.1 (2023-02-13)
Features

utils: Add create-file-checksum utility. (fce0d6a)
utils: Add download-git-directory utility. (4e15c05)
utils: Add resolve utilities to handle cross esm/cjs dynamic imports. (79e1606)
utils: Get-temp-dir utility. (ff3cf1b)
utils: Scaffold utils package. (851795b)

@openapi-generator-clients/config: 0.1.1
0.1.1 (2023-02-13)
Features

config: Add clients config interfaces, build options, builders. (6e134b3)
config: Add files to generator config / template config + template props defaults. (e979794)
config: Add generator-record interfaces / records. (d135123)
config: Scaffold config package (0ed5af3)
core: Support template level root dir. (9cab69a)

openapi-generator-clients: 0.1.1
0.1.1 (2023-02-13)
Features

core: Add cli entrypoint. (cde5e51)
core: Index exports. (79cb4b8)
core: Refactor and reimplement generate as core build (25b0851)
core: Scaffold openapi-generator-clients core package. (6268f33)
core: Support template level root dir. (9cab69a)
core: Temp workspace provider implementation. (be6c90c)

Bug Fixes

core: Downgrade rambdax to 8.1.0 (72c90e2)
core: Remove top level await in cli for cjs support (5c5e866)
core: Template type errors. (ed9fd1e)
core: Utilize cross cjs/esm resolve utils in build. (9d729c7)
pkg: Add directory to core package. (4ede56e)

@openapi-generator-clients/ts-generator: 0.1.1
0.1.1 (2023-02-13)
Features

generators: Add props defaults to ts-generator v1. (df50d16)
generators: Generators only need peer dependency on config package. (1a38150)
generators: Move typescript generator to ts-generator (09f4c53)
generators: Scaffold ts-generator. (ee1164f)
generators: Setup ts-generator export / dist/ (e1dbf67)
generators: Update ts-generator v1 tsconfig (1d44724)

Bug Fixes

generators: Include typings. (14fcca3)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/BradenM/openapi-generator-clients/releases/tag/%40openapi-generator-clients/types-v0.1.1 :sunflower:

:robot: Release is at https://github.com/BradenM/openapi-generator-clients/releases/tag/openapi-generator-clients-v0.1.1 :sunflower:

:robot: Release is at https://github.com/BradenM/openapi-generator-clients/releases/tag/%40openapi-generator-clients/ts-generator-v0.1.1 :sunflower:


Separate container sandbox lifecycle from that of the processes inside it

As of now, the runtime lifecycle states that there is a Start action which results in creation of a container sandbox and spawning the first process inside the container.
It would be better to separate lifecycle of the container sandbox from that of container processes.
To be more precise, I'm proposing introducing the following oci actions:

Create - This action will create a container sandbox. On Linux, this would be all cgroups and namespaces, excepting pid namespace (assuming all cgroups and namespaces were requested as part of the Spec).
Start - This action will spawn a new process in the existing container sandbox. On Linux, a new pid namespace will be created for the first process that is being spawned. Subsequent processes will run the same pid namespace.
 In the case of Linux, this will result in loss of pid namespace.
Delete - This action will delete the container sandbox.

This split will obviate the need for supporting hooks. Users are free to run hooks outside of the runtime as they please.
The existing Spec needs to be split into a Sandbox configuration and a Process configuration.
The process configuration can be reused for the Exec use-case.
FYI: This was discussed during the OCI meeting on 1/12/16 and everyone present agreed to this proposal.
We need to prototype this separation in one or more Operating Systems before requiring it in the Spec.
Input from runtime authors on non-linux platforms will be helpful here.

I'd suggest the prototype should test with usernamespaces, especially in light of bugs like this one:
https://github.com/opencontainers/runc/issues/101
Related patch: https://github.com/opencontainers/runc/pull/105/files
The init process of the container needs to be able to join a pre-created user namespace.
If this does not work, it would not possible to create any namespaces, as user namespaces require all other namespaces to be children of the user namespace.

@ashahab-altiscale: As long as user namespaces don't require a process to pin it, I don't see any issue here.

On Tue, Jan 12, 2016 at 03:13:37PM -0800, Vish Kannan wrote:

As of now, the runtime lifecycle states that there is a Start
action which results in creation of a container sandbox and spawning
the first process inside the container.  It would be better to
separate lifecycle of the container sandbox from that of container
processes.

This seems like a high-level change.  Should discussion happen on the
list 1?  There are earlier notes on this split approach in 2, as
well as some previous discussion along these lines in #226.  If we
decide to have this conversation here (instead of the list or earlier
issue), I can write up a summary of past points.

This split will obviate the need for supporting hooks. Users are
free to run hooks outside of the runtime as they please.

Yeah, if we have a separate create and exec, we can drop hooks and
close #265 3.

The existing Spec needs to be split into a Sandbox configuration and
a Process configuration.

Not necessarily.  ccon-ced (discussed in #226) wraps a runtime that
uses a single spec to do this.  To pull that off, you need a spec that
makes it easy to turn on only the functionality you want (e.g. “create
namespaces” vs. “join, [create a new PID namespace,] and exec a
process”).
 Subject: Documenting container lifecycles
 Date: Mon, 14 Sep 2015 20:47:17 -0700
 Message-ID<EMAIL_ADDRESS>

s/Support/Separate in issue title

It would be better to separate lifecycle of the container sandbox from that of container processes.

(emphasis mine)
more justification/use cases here would be useful, at the very least for posterity

This split will obviate the need for supporting hooks.

To be clear, are you suggesting removing hooks entirely from the spec?

Subsequent processes will run the same pid namespace.

It makes me pretty uneasy to have the start operation be nondeterministic - e.g. if I run two start commands simultaneously it's a race which one's process becomes PID1 (which has non-trivial implications).

On Tue, Jan 12, 2016 at 03:56:28PM -0800, Jonathan Boulle wrote:

Subsequent processes will run the same pid namespace.

It makes me pretty uneasy to have the start operation be
nondeterministic - e.g. if I run two start commands simultaneously
it's a race which one's process becomes PID1 (which has non-trivial
implications).

Yeah, -1 to having PID namespace be implicit.  If you run starts
(parallel or not) that both create PID namespaces, then they both get
to be PID 1 in their own PID namespace.  If you run a start (parallel
or not) that does not create a PID namespace, it does not get to be
PID 1.  So I don't see a problem with racing if we have explicit
PID-namespace creation.
On naming, see ‘exec’ vs. ‘start’ here in opencontainers/runc#210.

On Tue, Jan 12, 2016 at 6:52 PM W. Trevor King<EMAIL_ADDRESS>wrote:

On Tue, Jan 12, 2016 at 03:13:37PM -0800, Vish Kannan wrote:

As of now, the runtime lifecycle states that there is a Start
action which results in creation of a container sandbox and spawning
the first process inside the container. It would be better to
separate lifecycle of the container sandbox from that of container
processes.

This seems like a high-level change. Should discussion happen on the
list [1]?

This is because we're sitting in the face-2-face and working through this
presently.

On Tue, Jan 12, 2016 at 04:51:36PM -0800, Vincent Batts wrote:

On Tue, Jan 12, 2016 at 6:52 PM W. Trevor King wrote:

On Tue, Jan 12, 2016 at 03:13:37PM -0800, Vish Kannan wrote:

As of now, the runtime lifecycle states that there is a Start
action which results in creation of a container sandbox and
spawning the first process inside the container. It would be
better to separate lifecycle of the container sandbox from that
of container processes.

This seems like a high-level change. Should discussion happen on
the list [1]?

This is because we're sitting in the face-2-face and working through
this presently.

Yeah, that's fine.  But when dumping from the face-two-face into the
archives, I think you should dump into a list post, not into a new
issue (like this one).

On Tue, Jan 12, 2016 at 03:29:28PM -0800, Vish Kannan wrote:

@ashahab-altiscale: As long as user namespaces don't require a
process to pin it, I don't see any issue here.

The issue is the order in which you join or create namespaces, which
impacts permissions.  For example, an unprivileged user can join a
user namespace they created earlier, and then create a new PID
namespace underneath.  But they can't create a new PID namespace
before joining a user namespace they created (or creating a new user
namespace).  There are a number of comments to this effect in
opencontainers/runc#105, and also some notes in the “Interaction of
user namespaces and other types of namespaces” section of
user_namespaces(7).  For a command line example:
Make a new user namespace:
$ unshare --user --map-root-user sh
sh-4.3# echo $$
21171
In a different terminal, trying to create a new PID namespace and join
the user namespace fails:
$ unshare --pid nsenter --user=/proc/21171/ns/user --preserve-credentials sh
unshare: unshare failed: Operation not permitted
But trying to join the user namespace and then create a new PID
namespace succeeds:
$ nsenter --user=/proc/21171/ns/user --preserve-credentials unshare --pid sh
sh-4.3#
I think @ashahab-altiscale is just suggesting we avoid that issue by
proper namespace join/create ordering when implementing create/exec
tooling.

@wking Exactly. The order of namespace creation is important.

s/Cleanup/Stop/ but aside from that I like the idea of the split.

re: multiple "starts": based on what I've heard I don't think multiple concurrent "starts" would be allowed. I think I'm hearing that people still want a single main process in the container, which means once you've started it your only choice is to use "exec" to get a 2nd process.  Once the main proc ended then you can issue "start" again tho.

On Fri, Jan 22, 2016 at 07:11:42AM -0800, Doug Davis wrote:

re: multiple "starts": based on what I've heard I don't think
multiple concurrent "starts" would be allowed. I think I'm hearing
that people still want a single main process in the container, which
means once you've started it your only choice is to use "exec" to
get a 2nd process.  Once the main proc ended then you can issue
"start" again tho.

Is the only difference between ‘start’ and ‘exec’ whether you're
creating a new PID namespace (and optionally mounting a new /proc?) or
inheriting/joining an existing one?  It sounds like it might be, and
in that case, I'd rather just use our existing namespace create/join
schema and have a single ‘exec’ command.  Trying to bake the
distinction into two separate commands seems like more trouble than
the usability gain is worth.
Or are we just splitting commands for portability (e.g. to allow
hypervisor and microkernel systems where it's difficult/impossible for
the host to execute a new process in an existing
PID-namespace/container)?

Changing what 'exec' will do based on whether its the first call is a bit non-deterministic. Imagine I do "runc exec" thinking it'll generate a secondary proc and as such I have different management logic for it. If it turns out it ends up being the main proc (because I didn't know the main proc just died) I might end up with very different (incorrect) results than what I expected.

On Fri, Jan 22, 2016 at 08:21:45AM -0800, Doug Davis wrote:

Changing what 'exec' will do based on whether its the first call is
a bit non-deterministic.

Yeah, I think we're all on board with that being a bad idea.  I'm
suggesting changing what ‘exec’ will do based on explicit JSON
configuration (e.g. if linux.namespaces.pid.path is true or
false/unset).  That's how we handle create-or-join currently with the
“just ‘start’” approach.

+1 on splitting the init process from secondary process.
On Fri, Jan 22, 2016 at 9:52 AM W. Trevor King<EMAIL_ADDRESS>wrote:

On Fri, Jan 22, 2016 at 08:21:45AM -0800, Doug Davis wrote:

Changing what 'exec' will do based on whether its the first call is
a bit non-deterministic.

Yeah, I think we're all on board with that being a bad idea. I'm
suggesting changing what ‘exec’ will do based on explicit JSON
configuration (e.g. if linux.namespaces.pid.path is true or
false/unset). That's how we handle create-or-join currently with the
“just ‘start’” approach.
—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/specs/issues/299#issuecomment-173991635
.

What should the full UI be for this change?

cd redis-bundle/

# create the container
container create redis

# start the init process defined in the bundle
container start redis

# start additional processes
contianer exec redis -- bash

# kill the container

container kill redis

# delete the container
container delete redis

??

Yeah. That's the UI I'm thinking as well.
On Fri, Jan 22, 2016 at 12:06 PM Michael Crosby<EMAIL_ADDRESS>wrote:

What should the full UI be for this change?
cd redis-bundle/
create the container
container create redis
start the init process defined in the bundle
container start redis
start additional processes
contianer exec redis -- bash
kill the container
container kill redis
delete the container
container delete redis
??
—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/specs/issues/299#issuecomment-174032625
.

yes but I'd prefer "container stop redis" since "stop" feels like a better opposite/book-end to "start" than "kill".   Yes I know under the covers we send a kill signal, but that's a detail the end user doesn't need to know or care about.

@vishh great minds think alike ;)

On Fri, Jan 22, 2016 at 12:09:24PM -0800, Doug Davis wrote:

Yes I know under the covers we send a kill signal, but that's a
detail the end user doesn't need to know or care about.

Unless they're putting in a SIGTERM handler for a graceful exit, and
are wondering why ‘stop’ isn't triggering that ;).  So I think we do
want to be explicit about which singnals the runtime MUST use to
achieve a given action.

I'm distinguishing between runc stop <id> and runc kill <id> <signal #>

On Fri, Jan 22, 2016 at 12:06:51PM -0800, Michael Crosby wrote:

create the container
container create redis
start the init process defined in the bundle
container start redis
start additional processes
contianer exec redis -- bash

Because start/exec will use some currently-configured settings that
aren't needed at create time (e.g. config.json's process,
runtime.json's linux.namespaces.pid, and any config around mounting a
PID-specific /proc), I recommend splitting our config entries between
a create.json (only the stuff needed by ‘create’) and exec.json (only
the stuff needed by start/exec).  To give an explicit example of my
suggestion in 1 for the above, I'd have something like:
$ cat exec.json
{
"process": {
"terminal": false,
"user": {
"uid": 1000,
"gid": 1000
},
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
],
"cwd": "/",
"args": ["redis-server", "--bind", "<IP_ADDRESS>"]
},
"linux": {
"namespaces": [
{
"type": "pid"
}
]
},
"hooks": {
"prestart": [
{
"args": ["cgroup-manager", "add"]
}
]
}
}
to handle and initial:
$ container exec redis
And a:
$ cat bash.json
{
"process": {
"terminal": true,
"user": {
"uid": 1000,
"gid": 1000
},
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
],
"cwd": "/",
"args": ["bash"]
},
"linux": {
"namespaces": [
{
"type": "pid",
"path": "/proc/1234/ns/pid",
}
]
}
}
to handle a subsequent:
$ container exec --config bash.json redis
You can always write separate ‘start’ and ‘exec’ wrappers on top of an
interface like that (which would work with any OCI-compliant runtime).
Of course, with sufficient opt-out flexibility, you'd be able to write
wrappers for create, start, and exec all based on a single underlying
runtime command (which is how ccon-ced works 2).
If we go with the separate, runtime-level start/exec approach, I think
we'll have trouble adding flags for all the options like “do you want
this to go in the container cgroups?”, which you might want in some
cases, but not in others.

On Fri, Jan 22, 2016 at 12:22:17PM -0800, Doug Davis wrote:

I'm distinguishing between runc stop <id> and runc kill <id> <signal #>

If you have the latter (which I prefer), what good is the former?

What is the state of the system after a kill/stop with SIGTERM? I imagine the init process and it's children will die. What about the namespaces? Which fds will remain mounted vs being cleaned up? Can I start another init process with the same namespace fds?

On Fri, Jan 22, 2016 at 01:40:54PM -0800, Abin Shahab wrote:

What is the state of the system after a kill/stop with SIGTERM? I
imagine the init process and it's children will die.

After a SIGTERM they should all exit cleanly.  But SIGTERM is
catchable, and one person's “exitting cleanly” is anothers “not dying
fast enough”.  After SIGKILLing a container's PID 1 (assuming it has a
container-specific PID namespace), they will all be dead.

What about the namespaces? Which fds will remain mounted vs being
cleaned up? Can I start another init process with the same namespace
fds?

Everything except the PID namespace should have been created by the
‘create’ step, so you should be able to start another
PID-namespace-creating process that still uses those non-PID
namespaces (and presumably also reuses cgroups, etc.).

Re-using the sandbox should be possible, except that the sandbox might
contain some remnants from the previous run, for example filesystem.
On Fri, Jan 22, 2016 at 2:13 PM, W. Trevor King<EMAIL_ADDRESS>wrote:

On Fri, Jan 22, 2016 at 01:40:54PM -0800, Abin Shahab wrote:

What is the state of the system after a kill/stop with SIGTERM? I
imagine the init process and it's children will die.

After a SIGTERM they should all exit cleanly. But SIGTERM is
catchable, and one person's “exitting cleanly” is anothers “not dying
fast enough”. After SIGKILLing a container's PID 1 (assuming it has a
container-specific PID namespace), they will all be dead.

What about the namespaces? Which fds will remain mounted vs being
cleaned up? Can I start another init process with the same namespace
fds?

Everything except the PID namespace should have been created by the
‘create’ step, so you should be able to start another
PID-namespace-creating process that still uses those non-PID
namespaces (and presumably also reuses cgroups, etc.).
—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/specs/issues/299#issuecomment-174069791
.

I sure hope so :-)

Create - This action will create a container sandbox. On Linux, this would be all cgroups and namespaces, excepting pid namespace (assuming all cgroups and namespaces were requested as part of the Spec).

AFAIK, there are only two APIs which can be used to create new namespaces:

clone
unshare

They either create a new process or called by a process which will be a member of the new namespaces. So how can we create new namespaces without creating new processes?
And create empty cgroups dirs without putting any processes in doesn't make much sense to me, they should be attached to start stage IMHO.

See https://github.com/opencontainers/runc/pull/506   we do create a new process during create(), but we hold on to the namespaces (except PID) so that subsequent processes can reuse those other namespaces

On Mon, Jan 25, 2016 at 06:24:39AM -0800, Doug Davis wrote:

See https://github.com/opencontainers/runc/pull/506

For a more compact reference, see 1 and references to bind mounting
in “The /proc/[pid]/ns/ directory” section of 2.

@vishh do you think there are any actionable items left in this issue?  We did the create/start/delete split and you have an option to never actually start the container's process but keep adding exec processes after it is created.  Because of pid1 and the pid namespace issues on linux I don't think we will ever have a fully robust persistent sandbox on linux without higher level tooling adding to the functionality ( bind mounting namespaces and sharing between containers )


[WIP] V24.3.x rebase

Note that this PR is only open for the purpose of letting folks review the rebase before I push it to a dedicated v24.3.x branch. It will not be merged into the v24.2.x branch.

@michael-redpanda @pgellert If you folks could take a close look at the final TLS code and see if it's correct I'd greatly appreciate it. Also can one of you take a look at the TLS tests and see if the following failure is expected?
[brandonallard@fedora seastar]$ build/release/tests/unit/tls_test
Running 40 test cases...
INFO  2024-09-11 15:34:12,633 seastar - Reactor backend: linux-aio
INFO  2024-09-11 15:34:12,636 seastar - Perf-based stall detector creation failed (EACCESS), try setting /proc/sys/kernel/perf_event_paranoid to 1 or less to enable kernel backtraces: falling back to posix timer.
INFO  2024-09-11 15:34:12,636 cpu_profiler - Perf-based cpu profiler creation failed (EACCESS), try setting /proc/sys/kernel/perf_event_paranoid to 1 or less to enable kernel backtraces: falling back to posix timer.
random-seed=2246926787
Established connection
Killing server side
Got expected exception
unknown location(0): fatal error: in "test_simple_x509_client_server_client_auth_combined_cert_file": std::runtime_error: Unexpected EOF
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint
unknown location(0): fatal error: in "test_dn_name_handling": std::invalid_argument: No DH level set
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint
unknown location(0): fatal error: in "test_alt_names": std::invalid_argument: No DH level set
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint
unknown location(0): fatal error: in "test_skip_wait_for_eof": std::invalid_argument: No DH level set
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint
unknown location(0): fatal error: in "test_tls13_session_tickets": std::invalid_argument: No DH level set
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint

*** 5 failures are detected in the test module "Master Test Suite"

@michael-redpanda @pgellert If you folks could take a close look at the final TLS code and see if it's correct I'd greatly appreciate it. Also can one of you take a look at the TLS tests and see if the following failure is expected?
[brandonallard@fedora seastar]$ build/release/tests/unit/tls_test
Running 40 test cases...
INFO  2024-09-11 15:34:12,633 seastar - Reactor backend: linux-aio
INFO  2024-09-11 15:34:12,636 seastar - Perf-based stall detector creation failed (EACCESS), try setting /proc/sys/kernel/perf_event_paranoid to 1 or less to enable kernel backtraces: falling back to posix timer.
INFO  2024-09-11 15:34:12,636 cpu_profiler - Perf-based cpu profiler creation failed (EACCESS), try setting /proc/sys/kernel/perf_event_paranoid to 1 or less to enable kernel backtraces: falling back to posix timer.
random-seed=2246926787
Established connection
Killing server side
Got expected exception
unknown location(0): fatal error: in "test_simple_x509_client_server_client_auth_combined_cert_file": std::runtime_error: Unexpected EOF
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint
unknown location(0): fatal error: in "test_dn_name_handling": std::invalid_argument: No DH level set
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint
unknown location(0): fatal error: in "test_alt_names": std::invalid_argument: No DH level set
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint
unknown location(0): fatal error: in "test_skip_wait_for_eof": std::invalid_argument: No DH level set
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint
unknown location(0): fatal error: in "test_tls13_session_tickets": std::invalid_argument: No DH level set
/home/brandonallard/data/projects/seastar-rebase/seastar/src/testing/seastar_test.cc(43): last checkpoint

*** 5 failures are detected in the test module "Master Test Suite"

I figured out the test issue.  In tls-impl.cc you'll need add:
#ifndef SEASTAR_WITH_TLS_OSSL
#include <gnutls/gnutls.h>
#endif

around where the #include <boost...> stuff is

@michael-redpanda Nice! It looks like the include is missing in the v24.2.x branch as well. Will this cause any TLS issues in use? If so, do we want to fix things in the v24.2.x branch first then cherry-pick the changes here?

@michael-redpanda Nice! It looks like the include is missing in the v24.2.x branch as well. Will this cause any TLS issues in use? If so, do we want to fix things in the v24.2.x branch first then cherry-pick the changes here?

No this should only affect the GnuTLS build not the OpenSSL build so we should be ok

@michael-redpanda Nice! It looks like the include is missing in the v24.2.x branch as well. Will this cause any TLS issues in use? If so, do we want to fix things in the v24.2.x branch first then cherry-pick the changes here?

It should be fine on our v24.2.x branch, this change should only effect the GnuTLS build not the OpenSSL build

Note that adding the header resulted in a different TLS test failure. @michael-redpanda and I decided to not get gnutls working for this branch as we don't use it in RP. @michael-redpanda has a separate effort to get gnutls working in a PR he'll be upstreaming.
After compiling seastar with openSSL the following unit test error occurred;
67/80 Test #67: Seastar.unit.tls ..............................***Failed   40.58 sec
[0/1] cd /home/brandonallard/data/projects/seastar-rebase/seastar/build/release && /usr/bin/cmake -E env ASAN_OPTIONS=disable_coredump=0:abort_on_error=1:detect_stack_use_after_return=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 BOOST_TEST_CATCH_SYSTEM_ERRORS=no /home/brandonallard/data/projects/seastar-rebase/seastar/build/release/tests/unit/tls_test -- -c 2
Running 40 test cases...
INFO  2024-09-20 14:18:05,568 seastar - Reactor backend: linux-aio
INFO  2024-09-20 14:18:05,568 seastar - Perf-based stall detector creation failed (EACCESS), try setting /proc/sys/kernel/perf_event_paranoid to 1 or less to enable kernel backtraces: falling back to posix timer.
INFO  2024-09-20 14:18:05,568 cpu_profiler - Perf-based cpu profiler creation failed (EACCESS), try setting /proc/sys/kernel/perf_event_paranoid to 1 or less to enable kernel backtraces: falling back to posix timer.
random-seed=4140734661
/home/brandonallard/data/projects/seastar-rebase/seastar/tests/unit/tls_test.cc(453): fatal error: in "test_x509_client_tls13_fail": Expected exception
Established connection
Killing server side
Got expected exception

*** 1 failure is detected in the test module "Master Test Suite"
FAILED: tests/unit/CMakeFiles/test_unit_tls_run /home/brandonallard/data/projects/seastar-rebase/seastar/build/release/tests/unit/CMakeFiles/test_unit_tls_run
cd /home/brandonallard/data/projects/seastar-rebase/seastar/build/release && /usr/bin/cmake -E env ASAN_OPTIONS=disable_coredump=0:abort_on_error=1:detect_stack_use_after_return=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 BOOST_TEST_CATCH_SYSTEM_ERRORS=no /home/brandonallard/data/projects/seastar-rebase/seastar/build/release/tests/unit/tls_test -- -c 2
ninja: build stopped: subcommand failed.

@michael-redpanda is looking into this.

@michael-redpanda was able to figure out the issues and I've pushed a change with his recommended fixes.
The last unit test failure I'll be looking into is the following;
      Start 32: Seastar.unit.websocket
32/80 Test #32: Seastar.unit.websocket ........................***Failed    0.36 sec
[0/1] cd /home/brandonallard/data/projects/seastar-rebase/seastar/build/release/tests/unit && /usr/bin/cmake -E env ASAN_OPTIONS=disable_coredump=0:abort_on_error=1:detect_stack_use_after_re
turn=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 BOOST_TEST_CATCH_SYSTEM_ERRORS=no /home/brandonallard/data/projects/seastar-rebase/seastar/build/release/tests/unit/websocket_test -- -c
 2
Running 2 test cases...
INFO  2024-09-20 14:59:18,093 seastar - Reactor backend: linux-aio
INFO  2024-09-20 14:59:18,094 seastar - Perf-based stall detector creation failed (EACCESS), try setting /proc/sys/kernel/perf_event_paranoid to 1 or less to enable kernel backtraces: fallin
g back to posix timer.
INFO  2024-09-20 14:59:18,094 cpu_profiler - Perf-based cpu profiler creation failed (EACCESS), try setting /proc/sys/kernel/perf_event_paranoid to 1 or less to enable kernel backtraces: fal
ling back to posix timer.
random-seed=3497040184
/home/brandonallard/data/projects/seastar-rebase/seastar/tests/unit/websocket_test.cc(77): fatal error: in "test_websocket_handshake": critical check websocket_accept == "s3pPLMBiTxaQ9kYGzzh
ZRbK+xOo=" has failed [ != s3pPLMBiTxaQ9kYGzzhZRbK+xOo=]
f.size(): 0
f.size(): 4
/home/brandonallard/data/projects/seastar-rebase/seastar/tests/unit/websocket_test.cc(152): fatal error: in "test_websocket_handler_registration": critical check rs_frame == response_str has
 failed [TEST !=
TE]
f.size(): 0

*** 2 failures are detected in the test module "Master Test Suite"
FAILED: tests/unit/CMakeFiles/test_unit_websocket_run /home/brandonallard/data/projects/seastar-rebase/seastar/build/release/tests/unit/CMakeFiles/test_unit_websocket_run
cd /home/brandonallard/data/projects/seastar-rebase/seastar/build/release/tests/unit && /usr/bin/cmake -E env ASAN_OPTIONS=disable_coredump=0:abort_on_error=1:detect_stack_use_after_return=1
 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 BOOST_TEST_CATCH_SYSTEM_ERRORS=no /home/brandonallard/data/projects/seastar-rebase/seastar/build/release/tests/unit/websocket_test -- -c 2
ninja: build stopped: subcommand failed.

The websocket failures were from issues with the openSSL SHA1 base64 encoder when compiling with GCC. Normally the sha s3pPLMBiTxaQ9kYGzzhZRbK+xOo= should be encoded as;
73 | 33 | 70 | 50 | 4c | 4d | 42 | 69 | 54 | 78 | 61 | 51 | 39 | 6b | 59 | 47 | 7a | 7a | 68 | 5a | 52 | 62 | 4b | 2b | 78 | 4f | 6f | 3d

however, when compiling with openssl and gcc we get;
73 | 33 | 70 | 50 | 4c | 4d | 42 | 69 | 54 | 78 | 61 | 51 | 39 | 6b | 59 | 47 | 7a | 7a | 68 | 5a | 52 | 62 | 4b | 2b | 78 | 4f | 6f | 3d | 0 | ffffffbe

with openssl and llvm we get the expected encoding though. So since this isn't an issue with llvm, which is the only compiler we use for Redpanda, I'll be ignoring the test failures in GCC and continuing the rebase testing with LLVM only.

with the openSSL SHA1 base64 encoder when compiling with GCC

Can you explain? This looks like a UB/memory-safety issue to me. GCC and clang shouldn't shouldn't compute this differently. Are we passing some uninitialized buffer somewhere (in the code or test)?

I'll be ignoring the test failures in GCC and continuing the rebase testing with LLVM only

I am not sure we should ignore this given the severity of the issue. Also we want to upstream this anyway and upstream definitely cares about gcc.

I am not sure we should ignore this given the severity of the issue. Also we want to upstream this anyway and upstream definitely cares about gcc.

This effort is just applying our current changes onto master for our use.  Separate effort underway to upstream.


AWS S3 Upload - I can figure out why it doesn't work with me

I am trying to use vue-dropzone component for AWS S3 upload, here is the vue-dropzone component in the project:
<vue-dropzone
   id="dropzone"
   ref="newUploadDropzone"
   :class="'text-center'"
   :awss3="awss3"
   :options="dropzoneOptions"
   :destroyDropzone="true"
   @vdropzone-sending="sendingEvent"
   @vdropzone-s3-upload-error="s3UploadError"
   @vdropzone-s3-upload-success="s3UploadSuccess"
   @vdropzone-file-added="fileUploaded"
 >
 </vue-dropzone>

And here are the dropzoneOptions and the awss3 I used (awss3 is set dynamically by requesting the a file upload policy from the backend):
dropzoneOptions: {
  url: 'https://bucket-name.s3-us-east-1.amazonaws.com/',
  headers: {},
  thumbnailWidth: 200,
  addRemoveLinks: true,
  dictDefaultMessage: " UPLOAD ME"
},
awss3: {
  signingURL: 'https://bucket-name.s3-us-east-1.amazonaws.com/',
  headers: { },
  params: {
    key: '***',
    acl: '***',
    'X-Amz-Credential': '***',
    'X-Amz-Algorithm': '***',
    'X-Amz-Date': '***',
    'Policy': '***',
    'X-Amz-Signature': '***'
  }
}

With the previous settings I got this error as a response from AWS S3:
<Error>
  InvalidArgument
  <Message>POST requires exactly one file upload per request.</Message>
  <ArgumentName>file</ArgumentName>
  <ArgumentValue>0</ArgumentValue>
  <RequestId>0F01D682AE902DE3</RequestId>
  <HostId>WC27fBttONwueCXg38xOh2TDUmEsazhdQR/LJOP0zjb1ruhUON+JM2f36dSt9Yu8twqNFTN7I4U=</HostId>
</Error>

Then, I used the following function to add file param to the awss3 option once the vdropzone-file-added get triggered:
fileUploaded (file) {
  this.awss3.params.file = file
}

And after I still get an error as following:
<Error>
  AccessDenied
  <Message>Invalid according to Policy: Extra input fields: filepath</Message>
  <RequestId>B43BD875E19A39A5</RequestId>
  <HostId>I1UNlTbCMlexW3qt1MI8xXk4/v2ZC0yoAs4azU2+u6HtA9bXUUeN2J9YL51HvdqeFM0c3cdis6o=</HostId>
</Error>

I tried to use vdropzone-sending, but I don't know why this function isn't called like fileUploaded function:
sendingEvent (file, xhr, formData) {
  console.log('here') // Never reached
}

So what do you think? Anyway I can fix this.
Btw, here is the CORS configuration for the S3 bucket:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>DELETE</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <ExposeHeader>Location</ExposeHeader>
    <ExposeHeader>x-amz-request-id</ExposeHeader>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Thanks

I started to believe sendingEvent is only working in the normal mode, and doesn't work in AWS S3 mode.

@devahmedshendy Sorry for the late reply.

I started to believe sendingEvent is only working in the normal mode, and doesn't work in AWS S3 mode. Just tested it right now in the normal upload mode, and it works.

Thanks for mentioning this. I'll look into this.


🇲🇹 Add Malta

Fixes #319

Great work! Thanks for your first addition of a country :tada:
(Due to an ongoing big revert of a quickstatments batch with duplicated Twitter accounts it may take a few days before we do a new publication to the website, but it will come soon.)


Add top-level benchmark to the README

Rendered
Looks nice!

Maybe kind of big?

The problem with two side-by-side is mobile becomes much harder.

Nit: The subtitle is bigger than the image, I'd make the image a little bit bigger.

Side by side seems overkill

Sounds good, I widened it.

I'll merge this after the release because it also requires a fix-up step for PyPI.


[TVMC] Fix tvmc compile to extract target and target_host from --target

Enable tvmc compile --target "opencl, llvm" ... as a valid target, updates some validations and add test cases.

Removes validation to accept up to two TVM targets and set them as target and target_host

cc @gromero @jwfromm @comaniac for reviews

I'm not a reviewer, but I've took a look and it LGTM. Cheers.

Thanks @leandron @gromero.


[fix][broker] Change default behavior when ZK session expired to shutdown

Motivation
background

Once a broker's(we call it broker-1) ZK session has expired, the topics it owns will be assigned to other brokers
And the broker-1 will get a BadVersionException, then the topics will be marked fenced.
Other brokers will load up the topics
At this moment there is more than one broker who owns the same topic.

The clients who connected to broker-1 will get a fenced error.

Issue: the topics on broker-1 will not be unloaded until it restarts, so we'd better change the default behavior of the action when ZK session expires to shutdown, which will solve the issue automatically. We can set it back to reconnect after we improve the behavior to unload the topic automatically in the future.
Modifications
Change default behavior when ZK session expired to shutdown.
Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository: x

@poorbarcode The behavior is intended to prevent a temporary loss of a ZK session, to bring down an entire cluster of brokers at the same time.
In the example above, when broker-1 will be able to re-establish a session with ZK, it will get the notification that the ownership has changed.
For the semantics guarantees, there is no problem or race condition:

The ledgers where broker-1 was writing are getting fenced by the new broker that takes over
broker-1 is not able to create a new ledger (because of no zk session) and won't anyway be able to update the ledger list, since the version has already changed.

At this moment there is more than one broker who owns the same topic.
The clients who connected to broker-1 will get a fenced error.

In this case, broker1 will revalidating the lock and give up the ownership of the topic. And only the request going to broker-1 will get the wrong owner, right? Maybe we can always forward the lookup request to other brokers if the requested broker is waiting for zookeeper reconnection?

@merlimat @codelipenghui

In the example above, when broker-1 will be able to re-establish a session with ZK, it will get the notification that the ownership has changed.
For the semantics guarantees, there is no problem or race condition:

The ledgers where broker-1 was writing are getting fenced by the new broker that takes over
broker-1 is not able to create a new ledger (because of no zk session) and won't anyway be able to update the ledger list, since the version has already changed.

In this case, broker1 will revalidating the lock and give up the ownership of the topic. And only the request going to broker-1 will get the wrong owner, right? Maybe we can always forward the lookup request to other brokers if the requested broker is waiting for zookeeper reconnection?

Sure, agree with you. But there is a scenario which is not expected. Let me share a flow to you.

broker-2 lost ZK session
switch the topic's owner to broker-0.
the topic object in broker-2's memory was marked fenced, because the ledger was marked fenced first.
a. (Highlight) Issue: the object will always be in broker-2's memory, there is no mechanism to unload it so far.
b. Issue: the consumers/producers who connected to broker-2 will get a fenced error.
broker-2 connected to ZK.
switch the topic's owner to broker-2 since it is backed.
(Highlight) Issue: the consumers/producers will get a fenced error....

Agree with you, since the improvement that zookeeperSessionExpiredPolicy=reconnect, I will draft another PR to fix the issue described above. And I will close the current PR after the PR that tries to fix the issues submitted.

a. (Highlight) Issue: the object will always be in broker-2's memory, there is no mechanism to unload it so far.

This should only be while broker-2 is partitioned from ZK.

When the broker reconnects, it will discover that the ownership is lost and it will unload the topic
If indefinitely the broker-2 does not reconnect, it will keep the topic (fenced) though it will not be able to acquire more topics, so it should be ok

switch the topic's owner to broker-2 since it is backed.

Once broker-2 comes back, the ownership won't come back to broker-2 since it's already in broker-0

b. Issue: the consumers/producers who connected to broker-2 will get a fenced error.
(Highlight) Issue: the consumers/producers will get a fenced error....

The clients will get fenced error and then they will re-do the lookup and discover that a different broker is the owner

@merlimat

a. (Highlight) Issue: the object will always be in broker-2's memory, there is no mechanism to unload it so far.

This should only be while broker-2 is partitioned from ZK.

When the broker reconnects, it will discover that the ownership is lost and it will unload the topic

So far, it will not unload the topic. I will write a test to reproduce it.

switch the topic's owner to broker-2 since it is backed.

Once broker-2 comes back, the ownership won't come back to broker-2 since it's already in broker-0

After a shedding, the bundle may switch to broker-2

b. Issue: the consumers/producers who connected to broker-2 will get a fenced error.
(Highlight) Issue: the consumers/producers will get a fenced error....

The clients will get fenced error and then they will re-do the lookup and discover that a different broker is the owner

Correct, but the two issues above will lead to the issue can not be recovered.

@merlimat

a. (Highlight) Issue: the object will always be in broker-2's memory, there is no mechanism to unload it so far.

This should only be while broker-2 is partitioned from ZK.

When the broker reconnects, it will discover that the ownership is lost and it will unload the topic

So far, it will not unload the topic. I will write a test to reproduce it.

You are correct, it will be unloaded. I wrote a test in the below PR

https://github.com/apache/pulsar/pull/23018

The issue that we encountered is below, which is not the same as I described above

broker-2 is the owner of the topic.
broker-2 lost ZK session
a. the publishing is slowly, no new publishing at the moment.
switch the topic's owner to broker-0.
a. broker-0 deleted the ledger that broker-2 is writing on (there is a BK bug caused this wrong behavior )
broker-2 connected to ZK.
a. broker-2 tries to unload the topic, but the last ledger can not be closed due to the ledger's metadata has been deleted.
Once the cluster switches the topic's owner to broker-2 after a bundle shedding, the consumers/producers will get an error....

Close this PR


Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps

This suppresses a console warning in React 16.9 and will be required for React 17.x.
The console warning:
Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-async-component-lifecycle-hooks for details.

* Move data fetching code or side effects to componentDidUpdate.
* If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
* Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run `npx react-codemod rename-unsafe-lifecycles` in your project source folder.

Please update the following components: Interactive

Thanks for the PR, is the compatible version range for UNSAFE_componentWillReceiveProps React >= 16.3?

Yup, looks like it: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#gradual-migration-path

@rafrex any chance of merging this in soon? Is there anything I can do to help this move forward? Thanks!


wrong tutorial in cesiumjs.org

http://cesiumjs.org/tutorials/Geometry-and-Appearances/
RectanglePrimitive has been deprecated,but the tutorial is not updated.

I submitted a fix, it should be updated shortly.  Thanks @Senseme!


Support certbot

Describe the problem
Certbot can be used in --standalone mode when it starts it's own web server on port 80, but certbot also can use our web server in --webroot mode. But we cache files in memory and serve from memory, so challenge files, created by certbot can't be served immediately, it will be loaded after timeout so GET requests from letsencrypt will return 404.
Standalone mode: certbot certonly --standalone -d www.domain.com -d domain.com -m<EMAIL_ADDRESS>--agree-tos --no-eff-email
Webroot mode: certbot certonly --webroot -w ~/domain.com/application/static -d www.domain.com -d domain.com -m<EMAIL_ADDRESS>--agree-tos --no-eff-email
After certbot will issue new cert we can move it to our application/cert folder:
yes | cp /etc/letsencrypt/live/domain.com/fullchain.pem ~/domain.com/application/cert/cert.pem
yes | cp /etc/letsencrypt/live/domain.com/privkey.pem ~/domain.com/application/cert/key.pem

Describe the solution

When file is not found in memory it can be served from disk
Need to serve static at port 80 (balancer)

Done: https://github.com/metarhia/impress/pull/1844


Add a button for toggling hints

Current Behavior
When the player writes the full word wrongly the hint gets shown
...
What The Behavior Will Be
There will be a toggle hint button below the rebus when clicked it will show the hint (or hide it) and when writing the hint will disappear
...

I can take this issue

I made a hint button suggestion.
Open pull request: https://github.com/ollelauribostrom/rebus/pull/743


Make tutorial for designing sorting boxes

Show how to create a sorting box with the given elements and some custom basic things

German - Documentation/de/TutorialSortingBoxes.md


37 add device battery logging and settings class

Just compiling this up for a private deployment to Venu2 and Vivoactive 3 watches now.

Ok, I have started the documentation @philipabbey can you add some screen shots please.

Done, back to you for a sample dashboard widget.


Add configurable delay between input and errors highlighting

I'm not sure whether this feature request should be addressed to VS Code itself, or to particular syntax plugin authors. Anyway, this could be useful in general for all syntax plugins. Also I couldn't find if there is already a solution for this issue.
When I type some code (in my case I write Elm application), VS Code checks and validates syntax right away, after every character inputted, in a fraction of a second, and of course, the code is incorrect until I complete current statement. As a result - red underscore appears and disappears during input. Half screen flashes with red like a new year tree. That's annoying.
It would be nice to have some option to get some delay between last character inputted and error highlighting. Just a couple of seconds of delay would make life much comfortable.
Update: I think not just inputted character, but any key pressed should restart delay timer. Because, for example, you could press arrow keys to move caret around. In such case you're not inputting anything, but the delay timer should be restarted. Also I think syntax checking should be performed immediately after you do "Save" / "Save all".

Diagnostics are generated by the extension and VS Code just displays them in the UI. I think this depends on the language smartness. So, please file the issue against the extension that is generating these.


Label (sub)circuits and draw visual boxes

What is the expected behavior?
I was recently constructing some circuits and thought it would be nice to see what part of the circuit implements what. To that end I think it would be nice to have labels on the circuit drawer.
Of course it is already possible to turn a subcircuit into an opaque box through a custom instruction with label, however, I'd want to be able to inspect whatever happens inside the subcircuit.
Some examples of circuit labels are:

The curly braces and the O(sqrt(N)) of the section of Grover's algorithm that is repeated O(sqrt(N)) times in Fig 6.1 of Nielsen and Chuang.
The dashed box, highlighting & label in the following circuit

I'm mostly imagining something like the second example but with a possible label & not necessarily colored.
Would this be reasonably possible to fit in the circuit drawing? Especially drawing the box around the subcircuit may be tricky and the positioning of the label. Possibly also related to #1298 .

Are you thinking of when you draw circuits like this?
qc1 = QuantumCircuit(2)
qc2 = QuantumCircuit(2)
qc1.h(0)
qc2.cx(0, 1)
qc1 += qc2

circuit_drawer(qc1, output='mpl')

I think this would be non trivial to do as currently the drawing is based off the DAG, and the DAG has no awareness that the circuit it represents is made up of multiple subcircuits. This is because when circuits are appended, they are simply added gate by gate with no storage of the fact there were originally multiple circuits. Therefore we would have to find a way to start storing this information if we wanted to use it for drawing.

Yes, I think it would make sense to use actual circuits to identify subcircuits of the whole circuit. I have another issue up #2959 that also relates to selecting subcircuits.
Maybe instead of adding metadata and adding everything gate by gate you'd store a reference to the subcircuits instead in the DAGCircuit/Circuit class and from there it would be clear what is being referred to.

re-opened due to comment in #7192 indicating this issue may still be relevant 😄


New version: WebIO v0.8.7

Registering package: WebIO
Repository: https://github.com/JuliaGizmos/WebIO.jl
Created by: @travigd
Version: v0.8.7
Commit: a580a75b7385a43dac3d200e711da15aa0d5e69e
Reviewed by: @travigd
Reference: https://github.com/JuliaGizmos/WebIO.jl/commit/a580a75b7385a43dac3d200e711da15aa0d5e69e#commitcomment-34434348

Can I turn TagBot off for just a single repo in the org? @christopher-dG
We use Lerna to tag versions of WebIO because it insists on doing itself.


SAK-32367 Fixed a couple of help typos

Hi Adrian, changes to the /help directory are all overwritten by any changes made to the documentation on http://sakai.screenstepslive.com/s/sakai_help/ . So if you want to make changes you can email sakai-docs or comment on those pages there and it should get updated by the next release.

Ha, I had no idea whatsoever :) Only took me 5 mins, anyway, we live an learn.

Yeah no problem, I just know there will be a lot more changes pulled in from help updates (possibly even entire sections rewritten) and don't really want these to get out of sync. Don't know why we forgot at last release, need to fix an issue with the css too.


Alexa is no longer discovering any bridge devices.

All of a sudden Alexa is no longer discovering any bridge devices. Can you suggest how to figure out whats wrong? I can test the current bridge devices on the web interface and they work fine; its just Alexa that no longer sees them

What version of the bridge are you running?

v2.0.3. It turned out it had the wrong UPNP IP Address. So the issues is resolved. Thanks


No consumption recorded

Similar to https://github.com/tronikos/esphome-magnetometer-water-gas-meter/issues/6 I'm not getting any water consumption being recorded. 1" Neptune T-10 meter and EPS32 (https://www.amazon.com/dp/B0B18NK2MS) board, with ~ 20" of cabling between the ESP32 and GY-273 QMC5883L.
All three (x, y, z) fields seem to record changes when there is water flowing during calibration but I'm not getting any usage or flow values in Home Assistant. (No attempts at temperature calibration were done.)
(Screenshots taken with clothes washer running.)

logs_water-meter_logs.txt

Run a low flow water and click on calibrate. From your screenshots I see the thresholds are wrong. You should have -35 for the lower threshold and -25 for the upper threshold, i.e. +-5 points from the center point.


[BSE-524] Support Quarter Interval

Support INTERVAL_QUARTER

This is likely the wrong way to implement this. Do not add an additional type. If you notice, in order to implement this feature, you had to modify 19 files in the fork which is not going to be maintainable. TimeUnit.QUARTER is already defined and usable. The type isn't used anywhere in a meaningful way and a quarter is the exact same as 3 months.
You can very likely just simplify this entire thing by using INTERVAL_MONTH for the type and otherwise keep the interval parsing code identically.